Add support for SPV_KHR_ray_tracing. #2780
Conversation
|
✅ Build DirectXShaderCompiler 1.0.2901 completed (commit d4d63191e8 by @alelenv) |
There was a problem hiding this comment.
Thanks for the PR @alelenv .
Once provisional spec is ratified to final, i plan to cleanup existing NV suffixes used for various internal symbols( for ex IK_RayTracingOpNV) and generate code for KHR by default
That would be great. The compiler should by default generate SPIR-V that is compatible with core Vulkan, and generate KHR extensions as a secondary measure if necessary (since many KHR extensions end up getting into the next core Vulkan version), and only generate vendor-specific extensions as a last resort. So the default should be KHR, and -fspv-extension=<vendor-ext> should be used if the user wants to generate a vendor-specific SPIR-V. I understand the hit to backward compatibility. We should have enabled the NV extension under the -fspv-extension=SPV_NV_ray_tracing option from the beginning. That was an oversight (in this particular case, the NV extension was available so much earlier than the KHR extension, and it was not even clear whether there would ever be a KHR extension at the time).
|
✅ Build DirectXShaderCompiler 1.0.2915 completed (commit 7885bb12af by @alelenv) |
|
@ehsannas : Thanks for the review. I have updated the default to target KHR extension |
ghost
mentioned this pull request
Added support for generating SPIR-V for provisional cross vendor spec.
By default we generate code for NV extension(to preserve compatibility) and enable KHR extension using -fspv-extension=SPV_KHR_ray_tracing
Note: Opcodes for KHR extension alias with NV other than below
Added unit test and updated documentation
Once provisional spec is ratified to final, i plan to cleanup existing NV suffixes used for various internal symbols( for ex IK_RayTracingOpNV) and generate code for KHR by default
@ehsannas @jaebaek : Please review or redirect to appropriate folks
Thanks!