DavidGraham
Veteran
Good video that explains the limitations of the hardware rasterizer inside modern GPUs, and it's effect on supporting high polygon count.
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:
Validation checks for BuildRaytracingAccelerationStructure 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.
Ray-tracing validation has no effect on ray query–based ray tracing from compute or pixel shaders.
- 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.
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 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.So that means if I select DirectSR in a game instead of DLSS I'm Actually selecting DLSS ? (I have a NV card)
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 ?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.