Support NVAPI shader intrinsics in DXIL

vkd3dopen enhancementNvidia

HansKristian-Work/vkd3d-proton#2420 · opened 2025-03-27 by Saancreed · updated 2026-10-16 · 10 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 and CONTROL Resonant (in the latter, the lack of support for this feature disables Ultra RT preset)
- Already implemented on top of SPV_NV_cluster_acceleration_structure in dxil-spirv only
- Will require some extra device and command list extension interfaces in vkd3d-proton and dxvk-nvapi to be fully exposed and usable by Windows applications, proof of concept available and verified to work with CONTROL Resonant is here: https://github.com/Saancreed/vkd3d-proton/tree/nvapi-extras; https://github.com/jp7677/dxvk-nvapi/tree/d3d12-extras
- Part of upcoming DXR 2.0 and SM 6.10 specs, so I expect to see some kind of equivalent cross-vendor EXT Vulkan/SPIR-V extensions in the future for this as well
RTX Character Rendering, a.k.a. Linear Swept Sphere DXR extension
- Currently used by The Witcher 3 Remastered
- Could be implemented on top of SPV_NV_linear_swept_spheres
- Will require some extra device and command list extension interfaces, unless some major hackery is performed to stuff them into existing RTAS methods
- 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~~ (switched to SM 6.9 SER), games based on NvRTX fork of Unreal Engine (like Black Myth: Wukong), The Witcher 3 Remastered (queries for support, usage not verified yet), 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
- Already implemented on top of SPV_NV_shader_invocation_reorder with all required parts of dxil-spirv, vkd3d-proton and dxvk-nvapi already in place
- Currently hidden behind DXVK_NVAPI_D3D12_NV_SHADER_EXTN=1 environment variable
- Current implementation has known shortcomings related to usage of hit objects in Phi ops; they'll need to be resolved before we expose it by default
Triangle object positions DXR extension
- Currently used together with NvHitObjects by 007 First Light, unfortunately it wants specifically NV_EXTN_OP_HIT_OBJECT_GET_TRIANGLE_OBJECT_POSITIONS opcode that we can't implement with what we have today (see below)
- Most of 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
- NV_EXTN_OP_HIT_OBJECT_GET_TRIANGLE_OBJECT_POSITIONS, an opcode specific for interaction between this feature and SER hit objects, does not have any equivalent on SPIR-V side when using SPV_KHR_ray_tracing_position_fetch together with SPV_NV_shader_invocation_reorder. There is OpHitObjectGetIntersectionTriangleVertexPositionsEXT in SPV_EXT_shader_invocation_reorder, but we can't migrate NVAPI SER opcodes to that because we'd lose support for NV_EXTN_OP_HIT_OBJECT_MAKE_HIT and NV_EXTN_OP_HIT_OBJECT_GET_CLUSTER_ID

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.

Kkaankaraoglu 2026-09-27 github

@Saancreed Tested your RTXMG branches with CONTROL Resonant (3669870). The Ultra ray tracing preset and path tracing depend on RTX Mega Geometry in the game. With stock Proton those options are greyed out. With these builds they unlock and the game runs well with them enabled.

Setup

RTX 5090, NVIDIA 615.71.09 (open kernel module), CachyOS, kernel 7.2.7
proton-cachyos 11.0-20260703 (SLR) with the vkd3d-proton and dxvk-nvapi DLLs swapped for:
- Saancreed/vkd3d-proton nvapi-extras @ d9df3232
- jp7677/dxvk-nvapi d3d12-extras @ 99f629d4
Launch options: PROTON_LOG=1 DXVK_NVAPI_LOG_LEVEL=info %command%

Result

Ultra preset with Indirect Lighting (path tracing) on, 4K, DLSS Performance.
~16 minute session from a saved game, no crash, no device lost, no visual glitches noticed. I didn't test starting a new game, where others have reported crashes on 615 drivers with Indirect Lighting on.

Relevant log lines:

info:nvapi64:DXVK-NVAPI v0.9.2-96-g99f629d NVAPI gcc 16.2.0 x86_64 release (CONTROLResonant.exe)
info:vkd3d-proton:vkd3d_instance_init: vkd3d-proton - build: d9df3232e62f795.
info:nvapi64:<-NvAPI_D3D12_GetRaytracingCaps (3/NVAPI_D3D12_RAYTRACING_CAPS_TYPE_CLUSTER_OPERATIONS: Supported): OK
info:nvapi64:<-NvAPI_D3D12_GetRaytracingMultiIndirectClusterOperationRequirementsInfo: OK
info:nvapi64:<-NvAPI_D3D12_RaytracingExecuteMultiIndirectClusterOperation: OK

No partitioned TLAS calls appear in the log, so this only exercised the cluster operation path.
The log also has ~6.7k err:vkd3d-proton:d3d12_command_allocator_Reset: There are still 1 pending command lists awaiting execution lines. I haven't compared against stock vkd3d-proton, so I can't say whether they're related.

Happy to test further builds or grab a full log.

SSaancreed 2026-09-27 github

Cool, thanks for checking. This more or less matches my own observations made on my Ada GPU. One more thing I'm curious about with Blackwell is the impact on performance and VRAM usage; in theory the feature should improve the former a little, and the latter… more than a little, but it depends on how the game uses Cluster RTAS below the Ultra setting. Would be great if you could compare my branches to stock Proton on non-Ultra RT and checked how support for RTXMG affects perf and VRAM.

Ttybautf 2026-09-30 github

About the "RTX Character Rendering / Linear Swept Spheres" item: the issue says no application is known to use it, but The Witcher 3 5.0 ("Remastered", Steam 292030) appears to.

The game has a "path-traced hair" option (PTHairQualityMode in [Rendering/RT/PathTracer]). In bin/config/r4game/user_config_matrix/pc/graphics.xml it is gated by these tags:

enableIfHairWorks;enableIfPT;enableIfPTHair;enableIfRTHairworksSupported;enableIfLinearSweptSpheresSupported

Under Proton the option stays greyed out, with HairWorks and path tracing both enabled. The log shows why:

info:nvapi64:<-NvAPI_D3D12_GetRaytracingCaps (6/NVAPI_D3D12_RAYTRACING_CAPS_TYPE_LINEAR_SWEPT_SPHERES: Unsupported): OK
info:nvapi64:<-NvAPI_D3D12_GetRaytracingCaps (1/NVAPI_D3D12_RAYTRACING_CAPS_TYPE_OPACITY_MICROMAP: Supported): OK

The driver side is there: vulkaninfo lists VK_NV_ray_tracing_linear_swept_spheres (revision 1).

System

RTX 5080, driver 615.71.09 (open kernel modules), kernel 7.2.8-1-cachyos
GE-Proton11-7, DXVK-NVAPI v0.9.2, vkd3d-proton 9c108b4 (nanomatters/vkd3d-proton-salkim) + the RTAS patch discussed in #3226
HideWineExports=Y in the prefix, needed for 5.0 to expose DLSS/RT at all under Wine (ValveSoftware/Proton#607)

Why it matters

Without LSS the only hair option with path tracing is classic HairWorks, which is expensive: at 4K, path tracing, DLSS Performance, turning HairWorks off goes from 34 to 44 fps here. I have not tried forcing PTHairQualityMode in the settings file.
I'm able to test a branch or provide logs.

SSaancreed 2026-09-30 github

Right, I'm already aware of this, just forgot to update the list in the initial message.

Jjp7677 2026-10-03 github

For completeness:

The Witcher 3 Remaster (5.00c), Steam ID: 292030:

dxil-spirv: NVAPI opcode 114 not supported. (NV_EXTN_OP_RT_COMMITTED_IS_LSS)
dxil-spirv: NVAPI opcode 106 not supported. (NV_EXTN_OP_RT_COMMITTED_LSS_OBJECT_POSITIONS_AND_RADII)
dxil-spirv: NVAPI opcode 104 not supported. (NV_EXTN_OP_RT_LSS_OBJECT_POSITIONS_AND_RADII)

This branch should take care of the op codes: https://github.com/jp7677/dxil-spirv/pull/7 and allows it to start. Note that a lot more is needed in VKD3D-Proton and DXVK-NVAPI to really support path traced hairworks.

007 First Light (1.2.2), Steam ID: 3768760:

dxil-spirv: NVAPI opcode 99 not supported. (NV_EXTN_OP_HIT_OBJECT_GET_TRIANGLE_OBJECT_POSITIONS)

This branch adds a no-op for that op code https://github.com/jp7677/dxil-spirv/pull/8 and also allows it to start. See the commit log why we can't do better.

Both titles currently wont start with DXVK_NVAPI_D3D12_NV_SHADER_EXTN=1 when those op code are not implemented in DXIL-SPIRV.