Allows Vulkan spec constants as attribute arguments.

[danbrown-amd]

Fixes #3092

[github-actions[bot]]

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

[danbrown-amd]

Why was SpirvEmitter::addDerivativeGroupExecutionMode() written that way? It seems to me that it wouldn't be that difficult to provide enough context to find the original attribute in the AST so the method wouldn't need to scan the previously emitted instructions.

Of course, since there's no access to specializations at compile time, there's no way to ensure the best choice of execution mode with spec constants anyway. However, in some cases partial information would be sufficient to rule out one of them. If both are possible, maybe pick one and issue a warning?

[s-perron]

Why was SpirvEmitter::addDerivativeGroupExecutionMode() written that way?

It was implemented that way because that was the HLSL spec implemented for DXIL. See Thread Groups and Quads. I don't mind if we diverge from it when there are specialization constants. We just need to document it.

If both are possible, maybe pick one and issue a warning?

That is a reasonable idea. Longer term, we could try to add explicit attribute that apply to the entry point that would override the guess.

[s-perron]

/AzurePipelines run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).