DirectX Raytracing (DXR)DXR has recently been announced and many oldtime graphics programmers are obviously very interested in how this might change the future of GPU RealTime (RT) rendering. This article will be from the perspective of a Gen~3.5 render engineer and not someone currently writing production code against this new API.
API SummaryDXR presents new API for specifying 3D scene and initial rays that is passed on to the gpu hidden (device) layer to trace and have it report back results in the form of normal executing shader code . For full details check out the DXR forum post .
- "Independent" (to usercode) Rays defined by origin, direction, and min/max t.
- Executed shaders for intersection hits (miss, nearest, any)
- Executed shaders for ray generation and optional custom intersection test shaders
DX Raytracing has the potential to harmonize many of the existing and varied rendering techniques. Many current rendering subsystems try, in their own unique way, to trace and sample light, material, and geometry in the scene. Though perhaps not yet performant enough, the availability of RT raytracing could unify these sampling mechanisms either directly through raw DXR or via an engine layer. The introduction of RT raytracing also further marries offline rendering with RT (as PBR before it). Below is a list of potential shifts in how RT rendering might grown and develop with the introduction of this common API.
It is very unlikely that, in the near future, primary (from camera) rays will be raytrace due mostly to cost. Rasterization is greatly superior in performance to raytracing for some obscene level of scene complexity. Even with high scene complexity, modern render engines use various forms of occlusion testing to reduce overdraw/overtesting. Still, raytracing primary rays might have some advantages in the areas of transparency, non triangle rendering, and reduced render engine complexity.
|Primary rays from camera in red. Secondary in black. |
UbershaderAs documented in the initial DXR API there are potential issues with hit shaders and material variation [2, section 3.1] . A single call to DispatchRays may end up having rays hit multiple geometry that in scene actuality have multiple material (and therefore shader) definitions. Since the call to DispatchRays has only the specified hit shader there exists a problem with trying to represent all materials in a single hit shader (what one might call an ubershader). This problem can be overcome by mixed shader combinations, uv storage and post shading passes, or callable material shaders within hit shader.
Local Lighting Sampling
Many of the screenspace techniques developed over the last decade (ie SSAO) are about computing the potential occlusion of light by local geometry . A simple locally limited raytrace can compute caustic, emissive, specular occlusion, ambient occlusion, multi-layer inter refection. Blending high quality local light sampling with more coarse grained lighting information is already done with techniques like Screen Space Reflection (SSR) .
|Localized raytracing computes lighting in a similar but less obtuse manner than screen space tracing or voxel tracing.|
It was once hoped that raytracing would resolve the difficult technical issue that transparency affronts to rasterization . However transparency does not appear to be solved by DXR for two reasons. It is unlikely that (initially) the primary view will be raytraced. It is possible to say raytrace only the purely non opaque parts of the primary view but this would still likely be quite costly. Second, the execution order strictness on the hit any shader is undefined [2, section 4.10]; meaning that it cannot be used out of the box to perform do order independent transparency. Reording of these intersection samples would be required to correctly shade the raytrace . It might be possible instead to use hit nearest shader to find the first transparent object and then to continue to trace from there iteratively.
Scene complexity reductions (lower poly count, lower material variation) is just as desired for raytracing as rasterization . Its is not entirely obvious as to how DXR would be used to support LOD as it would need to be per ray and fully dynamic along the trace path. It could perhaps be supported through a combination of hit shaders and DXR API scene filter/masks. More complex solutions could involve regions with portals for tracing between LODs. DXR does not appear to have an out of the box LODing solution.
Level of Detail (LOD)
ShadowsPrimary shadows (ie Sun cascaded shadow maps) are likely not to be imminently replaced with raytracing as the cost would be prohibitive due to the amount of scene being traced. Soft shadows have a somewhat possible different character with raytracing than with rasterization as nearest occluder information is available. Very likely some shadow mapping will remain for the time being and will be instead be supplemented with raytraced local shadowing (especially for contact shadows).
Special RenderingDue to the optional custom intersection shader DXR implicitely supports specialized tracing. This type of specialized tracing could aid in the usage of non-polygonal (ie voxel) rendering and lend to high quality effects like fur, volumetric effects, particle rendering, and LOD occlusion .
Emissive surfaceEmissive materials have been supported in some high quality render engines for some time now. There are a range of techniques to make this type of effect work from voxel tracing to screenspace sampling to shader raytraced billboards . Now this technique can be unified when costs allow and likely integrated into the general local raytracing shader.
Light ProbesIf still required for performance, light probes can now be minimally rendered with selective rays and maxium distanced specified. Multiple probes can also be batched in a way that lends to cache coherency. Light information coming from raytraced sources can also be voxelized and then temporally and spatially propagated. In this way raytracing still acts as a harmonizing mechanism for all lighting computations even if those computations are later stored and interpolated.
Potentially Obsolete Techniques
- Secondary shadow maps (maybe)
- SSAO (likely)
- SSR (likely)
- SSO (likely)
- Caustic emulations (maybe)
Challenges for the DXR ParadigmThe DXR API specifically states that each ray is considered to be independent (when in flight) and has unique reference-able data. This makes GXR a pure raytracing API in that there is no user level access to ray hierarchy (aka coherent bundles). Given that it still remains a practical question as to if coherence mapping of rays adds any performance benefit to the raytracing process , the decision to hide ray hierarchy from userland code is likely the correct one.
There are however several downsides to this extremely simple and raw API that cannot be covered here but might be in a future article. They are simply listed below.
- Sampling has to reconstruct (texture) filtering parameters
- Hidden but perhaps leaky abstraction of performance (driver specific)
- Cache issues with user code level adaptive sampling
- Ubershader and limitations on "TraceRay" might make usage complex
- Analytical (biased) tracing might be superior for low RT performance constraints
- Unexposed but useful information is hidden
 D3D12 Raytracing Functional Spec
 DirectX forums: Getting started with raytracing
 Perceptual level of detail for efficient raytracing of complex scenes
 Bent Normals and Cones in Screen-space
 Order Independent TransparencyIn OpenGL 4.x
 Order Independent Transparency with Per-Pixel Linked Lists
 Efficient GPU Screen-Space Ray Tracing
 Sparse GPU Voxelization of Yarn-Level Cloth
 The Technology Behind the DirectX 11 Unreal Engine"Samaritan" Demo
 Coherent GPU Ray Tracing: Improving Data Locality