light-loops and other core lighting operations, while a specific
Bidirectional Scattering Distribution Function (BSDF) model
implements importance sampling and probability density
evaluation. Design Garage implements a number of different
physically-based materials, including metal and automotive
paint. Some of these shaders support normal and specular maps.
While OptiX implements all ray tracing functionality of
Design Garage, an OpenGL pipeline implements final image
reconstruction and display. This pipeline performs various
post processing stages such as tone mapping, glare, and
filtering using standard rasterization-based techniques.
6. 3. image space photon mapping
Image space photon mapping (ISPM) 7 is a real-time rendering
algorithm that combines ray tracing and rasterization strategies (Figure 9). We ported the published implementation to the
OptiX engine. That process gives insight into the differences
between a traditional vectorized serial ray tracer and OptiX.
The ISPM algorithm computes the first segment of photon paths from the light by rasterizing a “bounce map” from
the light’s reference frame. It then propagates photons by
recursively ray tracing until the last scattering event before
the eye. At each scattering event, the photon is deposited into
an array that is the “photon map.” Indirect illumination is
then gathered in image space by rasterizing a small volume
around each photon from the eye’s viewpoint. Direct illumination is computed by shadow maps and rasterization.
Consider the structure of a CPU-ISPM photon tracer. It
launches one persistent thread per core. These threads process photon paths from a global atomic work queue. ISPM
photon mapping generates incoherent rays, so traditional
packet strategies for vectorizing ray traversal do not help with
this process. For each path, the processing thread enters a
while-loop, depositing one photon in a global photon array
per iteration. The loop terminates upon photon absorption.
Trace performance increases with the success of
fine-grain scheduling of programs into coherent units and
decreases with the size of state communicated between
programs. Mimicking a traditional CPU-style of software
architecture would be inefficient under OptiX because it
would require passing all material parameters between the
ray generation and hit programs and a variable iteration
while-loop in the closest-hit program. OptiX-ISPM there-
fore follows an alternative design that treats all propagation
iterations as co-routines. It contains a single ray genera-
tion program with one thread per photon path. A recursive
closest-hit program implements the propagate-and-deposit
iterations. This allows threads to yield between iterations
so that the fine-grained scheduler can regroup them.
7. SummaRY aND futuRe WoRK
The OptiX system provides a general-purpose and high performance ray tracing API. OptiX balances ease of use with
performance by presenting a simple programming model,
based on a programmable ray tracing pipeline for single-ray user programs that can be compiled into an efficient
self-scheduling megakernel. Thus the heart of OptiX is a JIT
compiler that processes programs, snippets of user-specified
code in the PTX language. OptiX associates these programs
with nodes in a graph that defines the geometric configuration and acceleration data structures against which rays are
traced. Our contributions include a low-level ray tracing API
and associated programming model, the concept of a programmable ray tracing pipeline and the associated set of
program types, a domain-specific JIT compiler that performs
the megakernel transformations and implements several
domain-specific optimizations, and a lightweight scene representation that lends itself to high-performance ray tracing and supports, but does not restrict, the structure of the
application scene graph. The OptiX ray tracing engine is a
shipping product and already supports a wide range of applications. We illustrate the broad applicability of OptiX with
multiple examples ranging from simplistic to fairly complex.
While OptiX already contains a rich set of features and is
suitable for many use cases, it will continue to be refined and
improved. For example, we (or a third party developer) can
add support for further high level input languages, i.e. languages that produce PTX code to be consumed by OptiX. In
figure 9. iSPm real-time global illumination. a recursive closest-hit program in optiX implements the photon trace.