[spirv] AMD work graphs extension

[danbrown-amd]

Enables work graphs for SPIR-V target, based on AMD_shader_enqueue extension.
Closes #5960.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[damyanp]

@tex3d / @llvm-beanz - could you have a look at this please? Although this is tagged as a SPIR-V change, I see changes in DXIL-specific files as well as changes in generic HLSL files that aren't gated behind any spir-v ifdefs.

[s-perron]

This is my first pass. Generally looks pretty good, but it is a large PR. It would be best to separate this into smaller PRs, especially for changes that are not specific to adding workgraphs to the SPIR-V backend.

At a minimum, we should have separate PRs for:

1. Changes to the AST to enable spec constants in the attributes. This could be a change you do after the main change or before, but not with it because it affect DXIL. If there is a regression there, we want it to be a small change to make it easy to find the bug. We could check if we can change the attributes have ExprAttributesArgs.
2. Have a separate PR for the OpExecutionMode/OpExecutionModeId refactoring. That is a good change, but, again, if it caused problems, it would be hard to determine where the bug came from.
3. If you want to change the default target environment, that should be it own PR. That could be a major change for some people. If their code breaks, and they track it to this PR, it would be hard to understand why. Personally, if we change it, we will have to discuss what is should be, and it should not be based on the shader model.
4. The main change to have compute nodes. (Is that the right term?)
5. Finally another PR for the mesh nodes.

[danbrown-amd]

I agree that it's best to split up this PR. I'll eventually update the branch with the reduced work graphs extension (item 4 of your list).

[danbrown-amd]

After a glance at #7084 I'm thinking that it would take care of the second item and provide infrastructure for the first. Could you nudge someone to review it?

I'll probably drop the third item; I'm confident that the changes to CapabilityVisitor will take care of whatever issue I was trying to solve there. Mesh nodes can wait until it's been figured out what will happen with release-preview-mesh-nodes.

[Keenuts]

Hi,
I was hopping to test this using lavapipe (don't have hardware for this), but looks like they only implemented the first draft of this extensions spec, while this implements the second draft version?

-> Shall we always emit a DXC warning when emitting this extension to say this is a beta extension, and it's might not work/might change? Or is this extensions now "stable"?

[danbrown-amd]

It may not be a bad idea to add a warning. I'm not aware of any concrete plans to revise the spec but expect that will happen eventually. The current one has some limitations, one consequence of which is that passing nodes and node records to called functions is not supported. Also, validation generally has to be turned off because the spec (and therefore SPIRV-Tools) doesn't explicitly allow pointers of storage class NodePayloadAMDX to be function arguments as the entry function wrapper requires.

[Keenuts]

It may not be a bad idea to add a warning. I'm not aware of any concrete plans to revise the spec but expect that will happen eventually. The current one has some limitations, one consequence of which is that passing nodes and node records to called functions is not supported. Also, validation generally has to be turned off because the spec (and therefore SPIRV-Tools) doesn't explicitly allow pointers of storage class NodePayloadAMDX to be function arguments as the entry function wrapper requires.

Oh good to know, in that case I'd be in favor of either a warning, or gate this being a flag like -fspv-experimental-work-graphs to make it explicit this is not production ready at all.