DirectXShaderCompiler
DirectXShaderCompiler copied to clipboard
microsoft
[SPIR-V] Implement WaveMatch intrinsic support
The WaveMatch() Function was introduced in shader model 6.5 but is not yet supported by the SPIR-V backend. It should be implemented using: https://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/NV/SPV_NV_shader_subgroup_partitioned.html
Shall we add an option for DXC to specify the targeted vendor? If I'm an HLSL user targeting AMD cards, I might want to know when a feature will only be available on Nvidia, and at least have a warning.
Is "vendor" the right thing to slice on, or should it be on which extensions should be allowed?
Shall we add an option for DXC to specify the targeted vendor? If I'm an HLSL user targeting AMD cards, I might want to know when a feature will only be available on Nvidia, and at least have a warning.
I’d like to have a larger discussion about the design for something like this. I see the utility, but I wonder if there is a better way to express it (perhaps in terms of which extensions a user wants to enable)? We should also make sure whatever we do for this aligns with LLVM/Clang so that we can avoid introducing a feature that would be difficult to support in the future.
Is "vendor" the right thing to slice on, or should it be on which extensions should be allowed?
There is already a SPIR-V flag to specify the list of extension you are allowed to use.
So an tool like an engine can restrict DXC to only use the subset of extensions they decided to require for the game to run.
This flag however takes full names, no regex/wildcard like SPV_NV_*.
So a normal user might never use this, and be surprised by this accidental "vendor lock"
Yes, this issue might not be the best location to discuss this.
Right, we already support slicing on which extensions are allowed, realizing that has drawbacks and is difficult to use. Vulkan profiles will probably provide a more user-friendly way to express which capability are supported by a target environment, and is tentatively our plan for future upstream work, but it's not something we're likely to change in DXC right now, and is definitely outside the scope of this PR.
All KHR subgroup ops except for Arithmetic, Quad and Clustered are pretty much ubiquitous across all shader stages on Desktop when targetting Vulkan 1.3
Not sure you need Clustered (aka NV partitioned) ops for this?
Unfortunately I don't think there is a substitute for OpGroupNonUniformPartitionNV in core or a KHR extension at this point. As far as I can tell this is also how the split of subgroup* functions are handled in GLSL.
Ah yeah I see that you're after partitioning according to an arbitrary ballot.
There's Subgroup Clustered ops, but that partitions into sets of consecutive invocations of power-of-two, i.e 4, 8, 16