Game development presentations - a useful reference

Ray-Tracing Validation at the Driver Level | NVIDIA Technical Blog
February 26, 2024
For developers working on Microsoft DirectX ray-tracing applications, ray-tracing validation is here to help you improve performance, find hard-to-debug issues, and root cause crashes.

Unlike existing debug solutions, ray-tracing validation performs checks at the driver level, which enables it to identify potential problems that cannot be caught by tools such as the D3D12 Debug Layer. Warnings and errors are delivered straight from the driver to the application with a callback, where they can be processed through existing application-side debugging or logging systems.

Ray-tracing validation reports certain error conditions occurring within DispatchRays and BuildRaytracingAccelerationStructure calls that can lead to hard-to-debug faults or corruptions.

For example, an application might build a new ray-tracing pipeline for the next frame and update the shader binding table (SBT) that is still in use for the current frame. This could lead to a potential fault on missing entries in the SBT in the current frame. Ray-tracing validation reports an UNKNOWN_ENTRY_FUNCTION error along with error-specific details, guiding you to the root cause of the fault.

Validation checks for DispatchRays include the following:

  • Unexpected SBT record shader type, like encountering a miss shader entry when expecting a hit group.
  • SBT references a shader that is not part of the pipeline.
  • Out-of-bounds SBT entry.
  • Shader payload type mismatch, when the invoked shader expects a type different than that passed to TraceRay.
  • Maximum trace depth exceeded.
  • Stack overflow.
Validation checks for BuildRaytracingAccelerationStructure include the following:

  • Performance warnings for inefficient acceleration structures.
  • Excessive degenerated triangle use in re-fittable, bottom-level ASs. This may lead to poor performance.
  • Bad vertex data, such as NaNs and large numbers.
  • Ill-conditioned geometry or instance transforms.
  • Incomplete source acceleration structures used for refitting, copying or TLAS builds. Likely an app-side issue with proper syncing between AS operations.
  • Vertex, OMM, or DMM input index out-of-bounds check.
  • Altered flags between AS build and refit.
Ray-tracing validation has no effect on ray query–based ray tracing from compute or pixel shaders.
 
Last edited by a moderator:

DirectX Innovation on Display at GDC 2024


Introducing DirectSR

We’re thrilled to announce DirectSR, our new API designed in partnership with GPU hardware vendors to enable seamless integration of Super Resolution (SR) into the next generation of games. Super Resolution is a cutting-edge technique that increases the resolution and visual quality in games. DirectSR is the missing link developers have been waiting for when approaching SR integration, providing a smoother, more efficient experience that scales across hardware. This API enables multi-vendor SR through a common set of inputs and outputs, allowing a single code path to activate a variety of solutions including NVIDIA DLSS Super Resolution, AMD FidelityFX™ Super Resolution, and Intel XeSS. DirectSR will be available soon in the Agility SDK as a public preview, which will enable developers to test it out and provide feedback. Don’t miss our DirectX State of the Union at GDC to catch a sneak peek at how DirectSR can be used with your games!

So basically what people have been hoping MS to do - provide a plug-in architecture where the vendor specific implementations can hook into. Really looking forward to see how this plays out.
 
So that means if I select DirectSR in a game instead of DLSS I'm Actually selecting DLSS ? (I have a NV card)

That’s my guess. But it probably won’t be called DirectSR in game menus just like raytracing isn’t called DXR. It’ll probably just be called something generic like Resolution scaling with a percentage slider or Performance/Balanced/Quality presets.
 
So that means if I select DirectSR in a game instead of DLSS I'm Actually selecting DLSS ? (I have a NV card)
Not how I would hope it works.
Hope in the UI you choose implementation, and DirectSR uses the selected DLL.
So DirectSR is giving you the api contract and fallback (FSR).

I'd rather be able to choose between XeSS & FSR for example
 
Alan Wake 2: A Deep Dive into Path Tracing Technology (Nvidia account required)

RT: Overdrive in Cyberpunk 2077 Ultimate Edition - Pushing Path Tracing One Step Further
 
Didn’t know CP2077 overdrive is using a separate world space irradiance cache in addition to the ReSTIR reservoirs. Will be interesting to see if/how CDPR’s enthusiasm for path tracing and the Nvidia partnership will carry over to their future projects given the engine switch to UE5. Based on the UE5 talk I’m not sure Nvidia is making a sufficiently strong case for Epic to consider mainlining their ReSTIR stuff. They didn’t discuss the issues with direct lighting a Nanite gbuffer using a lower fidelity BVH scene and overall it seems like a minor improvement over hardware Lumen GI.
 
@trinibwoy It will be interesting to see CDPR's use of UE5 for sure, but there's always the option that they basically don't use lumen and roll their own ray-tracing/GI. UE5 gives you a lot, but you have the option to fully customize any part of the engine that you want. They don't strike me as a company that will kind of roll with the out-of-box experience.
 
Didn’t know CP2077 overdrive is using a separate world space irradiance cache in addition to the ReSTIR reservoirs. Will be interesting to see if/how CDPR’s enthusiasm for path tracing and the Nvidia partnership will carry over to their future projects given the engine switch to UE5. Based on the UE5 talk I’m not sure Nvidia is making a sufficiently strong case for Epic to consider mainlining their ReSTIR stuff. They didn’t discuss the issues with direct lighting a Nanite gbuffer using a lower fidelity BVH scene and overall it seems like a minor improvement over hardware Lumen GI.
The entire selling point of ReSTIR/RTXDI is path traced direct lighting for primary views. If you can't use the algorithm in the presence of virtual geometry without introducing serious shadowing artifacts (poor acceleration structure) or high data structure cost then how much value do you think you're getting out of it ?
 
Then i guess virtual geometry will just die. What is the value of an engine which cant do basics like reflections, GI, AO etc.? Alan Wake 2 is using Mesh-Shading and properly supports ReSTIR. Maybe Epic could start to opimize their unoptimized engine a little bit...
 
Back
Top