Winograd kernels not applicable with XNACK+

[junliume]

when experimenting with b262239

[2024-04-02T00:21:40.884Z] <instantiation>:78:5: error: .amdhsa_reserve_xnack_mask does not match target id
[2024-04-02T00:21:40.884Z]     .amdhsa_reserve_xnack_mask               __sgpr_reserve_xnack_default
[2024-04-02T00:21:40.884Z]     ^~~~~~~~~~~~~~~~~~~~~~~~~~

[atamazov]

@junliume AFAICS Ilya has nothing to do with it. The Winograd solvers are inapplicable because the kernels won't work when XNACK is enabled. I recommend closing this as "won't fix".

[Kirpich30000]

I've checked the latest Winograd kernel. There are no xnack hazards in memory clauses, however xnack requires 2 additional sgprs and it doesn't fit with the current sgpr allocation. So indeed, shader doesn't support xnack.

[atamazov]

@junliume FYI The immediate reason of the build error is that target passed to the assembler does not match the argument of the .amdhsa_reserve_xnack_mask directive. Specifically, the target has "xnack+" in its name (e.g. "gfx90a:xnack+") and assembler wants that some SGPRs to be reserved for the XNACK_MASK, but the argument of .amdhsa_reserve_xnack_mask is 0.

In order to enable some asm kernels for xnack+ targets, we need to update:

• Solver(s)
• Respective asm source(s)
• AmdgcnAssemble() that performs offline assembly
• [Notice] COMGR asm path should be fine soon (I am working on it)

Of course, beforehand we need info from @Kirpich30000 about configs that can be enabled for Winograd when XNACK is ON. There are some, at least (as we've discussed with Ilya recently). Then we should evaluate the potential benefits and decide whether it is worth doing.

[atamazov]

@junliume @Kirpich30000 Some useful (but maybe outdated info) from @Slimakanzer: #1093 (comment)

[junliume]

@cderb are the inapplicable tests already disabled? It seems that CI for #2864 is still failing