Support NVAPI shader intrinsics in DXIL

vkd3dopen

HansKristian-Work/vkd3d-proton#2420 · opened 2025-03-27 by Saancreed · updated 2026-01-04 · 5 comments · github

SSaancreed 2025-03-27 github

Seeing as implementing support for undocumented AMD AGS shader intrinsics is something actually happening, even though it's currently not possible to encounter them on Linux without borrowing libraries shipped with AMD's D3D12 driver, it would be great to also have support for NVAPI intrinsics that already have equivalent SPIR-V extensions.

To avoid having to deal with DXBC nonsense, this feature request is limited to intrinsics that can only be reasonably used in DXIL / SM 6.* shaders. When this is done and some interface to query intrinsic support is added, dxvk-nvapi could report some intrinsics as supported for existing games/applications to take advantage of.

Current candidates for consideration, grouped into features they represent:

RTX Mega Geometry, a.k.a. Cluster Geometry DXR extension
- Currently used by Alan Wake 2
- Could be implemented on top of SPV_NV_cluster_acceleration_structure
- Will require some extra device and command list extension interfaces
- NV_EXTN_OP_RT_GET_CLUSTER_ID used by uint NvRtGetClusterID() could be translated to ClusterIDNV
- NV_EXTN_OP_RT_GET_CANDIDATE_CLUSTER_ID and NV_EXTN_OP_RT_GET_COMMITTED_CLUSTER_ID used by uint __NvRtGetCandidateClusterID(uint rqFlags) and uint __NvRtGetCommittedClusterID(uint rqFlags) respectively could be translated to OpRayQueryGetIntersectionClusterIdNV
RTX Character Rendering, a.k.a. Linear Swept Sphere DXR extension
- I'm not aware of any application currently using it
- Could be implemented on top of SPV_NV_linear_swept_spheres
- Will require some extra device and command list extension interfaces
- NV_EXTN_OP_RT_SPHERE_OBJECT_POSITION_AND_RADIUS used by float4 NvRtSphereObjectPositionAndRadius() could be translated to HitSpherePositionNV + HitSphereRadiusNV
- NV_EXTN_OP_RT_LSS_OBJECT_POSITIONS_AND_RADII used by float2x4 NvRtLssObjectPositionsAndRadii() could be translated to HitLSSPositionsNV + HitLSSRadiiNV
- NV_EXTN_OP_RT_IS_SPHERE_HIT used by bool NvRtIsSphereHit() could be translated to HitIsSphereNV
- NV_EXTN_OP_RT_IS_LSS_HIT used by bool NvRtIsLssHit() could be translated to HitIsLSSNV
- NV_EXTN_OP_RT_CANDIDATE_IS_NONOPAQUE_SPHERE and NV_EXTN_OP_RT_COMMITTED_IS_SPHERE used by bool __NvRtCandidateIsNonOpaqueSphere(uint rqFlags) and bool __NvRtCommittedIsSphere(uint rqFlags) respectively could be translated to OpRayQueryIsSphereHitNV
- NV_EXTN_OP_RT_CANDIDATE_IS_NONOPAQUE_LSS and NV_EXTN_OP_RT_COMMITTED_IS_LSS used by bool __NvRtCandidateIsNonOpaqueLss(uint rqFlags) and bool __NvRtCommittedIsLss(uint rqFlags) respectively could be translated to OpRayQueryIsLSSHitNV
- NV_EXTN_OP_RT_CANDIDATE_LSS_HIT_PARAMETER and NV_EXTN_OP_RT_COMMITTED_LSS_HIT_PARAMETER used by float __NvRtCandidateLssHitParameter(uint rqFlags) and float __NvRtCommittedLssHitParameter(uint rqFlags) respectively could be translated to OpRayQueryGetIntersectionLSSHitValueNV
- NV_EXTN_OP_RT_CANDIDATE_SPHERE_OBJECT_POSITION_AND_RADIUS and NV_EXTN_OP_RT_COMMITTED_SPHERE_OBJECT_POSITION_AND_RADIUS used by float4 __NvRtCandidateSphereObjectPositionAndRadius(uint rqFlags) and float4 __NvRtCommittedSphereObjectPositionAndRadius(uint rqFlags) respectively could be translated to OpRayQueryGetIntersectionSpherePositionNV + OpRayQueryGetIntersectionSphereRadiusNV
- NV_EXTN_OP_RT_CANDIDATE_LSS_OBJECT_POSITIONS_AND_RADII and NV_EXTN_OP_RT_COMMITTED_LSS_OBJECT_POSITIONS_AND_RADII used by float2x4 __NvRtCandidateLssObjectPositionsAndRadii(uint rqFlags) and float2x4 __NvRtCommittedLssObjectPositionsAndRadii(uint rqFlags) respectively could be translated to OpRayQueryGetIntersectionLSSPositionsNV + OpRayQueryGetIntersectionLSSRadiiNV
- NV_EXTN_OP_RT_CANDIDATE_BUILTIN_PRIMITIVE_RAY_T used by float __NvRtCandidateBuiltinPrimitiveRayT(uint rqFlags) could be translated to OpRayQueryGetIntersectionTKHR
- NV_EXTN_OP_RT_COMMIT_NONOPAQUE_BUILTIN_PRIMITIVE_HIT used by void __NvRtCommitNonOpaqueBuiltinPrimitiveHit(uint rqFlags) could be translated to OpRayQueryConfirmIntersectionKHR
Shader Execution Reordering, a.k.a. DXR HitObject extension
- Currently used at least by Cyberpunk 2077, Alan Wake 2, games based on NvRTX fork of Unreal Engine (like Black Myth: Wukong), and probably more…
- This feature is now part of upstream Unreal Engine 5.6, so it's very likely we'll have many more games using it in the future
- Could be implemented on top of SPV_NV_shader_invocation_reorder… but maybe it would be worthwhile to wait until VK_EXT_ray_tracing_invocation_reorder is published and use SPIR-V extension exposed by that instead, as we will need SER support for DXR 1.2 and SM 6.9 anyway?
- Likely will not require any extra extension interfaces, we can already check if the implementation is likely to reorder by querying extensions properties on underlying VkPhysicalDevice
- For better or worse, this interacts with two extensions above by exposing additional operations on hit objects, e.g. NV_EXTN_OP_HIT_OBJECT_GET_CLUSTER_ID / OpHitObjectGetClusterIdNV
- This is at least 19 opcodes to implement, more if we account for interactions with Cluster Geometry and LSS extensions 😩
Triangle object positions DXR extension
- I'm not aware of any application currently using it
- Could be implemented on top of SPV_KHR_ray_tracing_position_fetch
- Will likely require new device and command list interfaces to allow passing VK_BUILD_ACCELERATION_STRUCTURE_ALLOW_DATA_ACCESS_BIT_KHR to RTAS builds
- NV_EXTN_OP_RT_TRIANGLE_OBJECT_POSITIONS used by float3x3 NvRtTriangleObjectPositions() could be translated to HitTriangleVertexPositionsKHR
- NV_EXTN_OP_RT_CANDIDATE_TRIANGLE_OBJECT_POSITIONS and NV_EXTN_OP_RT_COMMITTED_TRIANGLE_OBJECT_POSITIONS used by float3x3 __NvRtCandidateTriangleObjectPositions(uint rqFlags) and float3x3 __NvRtCommittedTriangleObjectPositions(uint rqFlags) respectively could be translated to OpRayQueryGetIntersectionTriangleVertexPositionsKHR

Finally, there exists a Micro-map DXR extension but the closest SPIR-V extension it could be mapped to, SPV_NV_displacement_micromap, is probably dead and gone now that VK_NV_displacement_micromap has been deprecated and removed.

Ooscarbg 2025-04-22 github

EDIT: good resume of current NV NVAPI extensions..
also not forget the OMM NVAPI DXR extension
can be implemented via VK_EXT_opacity_micromap..
a sample using it:
https://github.com/NVIDIA-RTX/OMM-Samples
and also soon to be in DXR1.2 so I asked this OMM SDK and sample to be ported to DXR1.2 ASAP:
https://github.com/NVIDIA-RTX/OMM-Samples/issues/8

SSaancreed 2025-04-22 github

also not forget the OMM NVAPI DXR extension
can be implemented via VK_EXT_opacity_micromap..

@oscarbg If you are talking about the "force OMM 2 state" ray flag then I omitted it on purpose because I PR'ed support for it (which got merged) years ago.

And as far as I know, there is nothing else that can be implemented there using SPV_EXT_opacity_micromap, that ray flag is the only functionality exposed by that ext. Which kind of makes sense as the entire purpose of opacity micromaps is to have less shader code, not more.

Ooscarbg 2025-04-25 github

@Saancreed my fault, totally forgot it was already implemented..

Ffarnoy 2026-01-03 github

SER is part of SM 6.9 (still in preview, I think) https://devblogs.microsoft.com/directx/ser/

vkd3d-proton would need to support both the NVAPI & 6.9 opcodes, but all apps thus far have used NVAPI ones?

There's now a cross-vendor VK_EXT for it https://www.khronos.org/blog/boosting-ray-tracing-performance-with-shader-execution-reordering-introducing-vk-ext-ray-tracing-invocation-reorder

All the pieces seem to be there, it's just going to take a lot of work? Is this something a first-time contributor could tackle?

SSaancreed 2026-01-04 github

Well, yes. I have already implemented rudimentary support for NVAPI SER in dxil-spirv on top of NV extension, which mostly works with existing games when combined with my branches of dxvk-nvapi and vkd3d-proton. The First Descendant successfully uses that path, and Black Myth Wukong greatly benefits from SER and OMMs.

However, NVIDIA's recent Bonsai Diorama demo (available here) has uncovered a limitation in the current implementation, namely HitObjects cannot be used in Phi operations in SPIR-V but they can in NVAPI flavor of SER in DXIL. I haven't yet figured how to address this (my idea would be to add an analysis pass that would map hit objects created on different branches to a single pointer variable, except I'm too demotivated to actually make an attempt), but with this the implementation would be mostly complete. You still wouldn't be able to try it with Cyberpunk 2077 because it's doing naughty things, but oh well.

If you want to take a look at it, feel free to build my branches and run this demo with VKD3D_DISABLE_EXTENSIONS=VK_NV_cluster_acceleration_structure, because apparently my attempt at implementing RTXMG has another, unrelated problem (😩). Other than that, it's a matter of discussing and implementing an interface in vkd3d-proton that would expose access to NVAPI shader intrinsics, which could be used by dxvk-nvapi.

On the other hand, SER from SM 6.9 should be fairly implementable on top of EXT extension, but I believe since it's core D3D12 feature now, Hans-Kristian is simply waiting for it to be declared stable before starting work on it himself. Of course, none of the games that already launched with NVAPI SER would benefit from this unless their developers migrate them to D3D12 SER.

Launch options

VKD3D_DISABLE_EXTENSIONS=VK_NV_cluster_acceleration_structure`,x1 2026-01