On Mon, Nov 27, 2023 at 08:08:40AM +0800, Benda Xu wrote:
> Hi Yiyang,
>
> Yiyang Wu <xgreenlandfor...@gmail.com> writes:
>
> > Upstream usually ships 2 version: gfx90a:xnack-, gfx90a:xnack+. Although
> > a single gfx90a should have maximum compatibility, According to [1,2],
> > compile with xnack+/xnack- may have better performance on xnack
> > enabled/disabled GPUs. Therefore we ship both the target, align with
> > upstream. gfx900 is also appended with :xnack- to align with upstream
> > default.
>
> > [1] https://llvm.org/docs/AMDGPUUsage.html#target-features
> > [2]
> > https://docs.olcf.ornl.gov/systems/crusher_quick_start_guide.html#compiling-hip-kernels-for-specific-xnack-modes
>
> So, you want to add a new ABI to gfx90a for experimental xnack feature.
> I suggest make it gfx90a with gfx90a_xnack, instead of
> "gfx90a_noxnack" for consistency the existing naming scheme.
Previously the gfx90a is appended with :xnack+ feature:
```bash
case ${gpu_target} in
gfx906|gfx908)
target_feature=:xnack-
;;
gfx90a)
target_feature=:xnack+
;;
*)
;;
esac
```
That means actually we are shipping gfx90a_xnack originally, without shipping
the xnack disabled build.
So maybe you mean adding a new ABI gfx90a_noxnack, while keeping gfx90a_xnack
as its original name gfx90a?
>
> With this minimal modification, the remaining cards such as gfx906 and
> gfx908 that support xnack could be updated incrementally.
Yes, although ROCm upstream does not ship the xnack supported build of math
libraries, for unknown reasons. There's no public documentation about this,
while some discussions exists [1]
[1] https://github.com/RadeonOpenCompute/ROCm/issues/2358
Best,
Yiyang Wu
