Ray Tracing NURBS Surfaces using CUDA Erik Valkering

Ray Tracing NURBS Surfaces using CUDA
Master’s Thesis (Version of 2nd February 2010)
Erik Valkering
Ray Tracing NURBS Surfaces using CUDA
THESIS
submitted in partial fulfillment of the
requirements for the degree of
MASTER OF SCIENCE
in
COMPUTER SCIENCE
by
Erik Valkering
born in Limmen, the Netherlands
Computer Graphics and CAD/CAM group
Department of Mediamatics
Faculty of Electrical Engineering, Mathematics and Computer Science
Delft University of Technology
Delft, the Netherlands
www.ewi.tudelft.nl
c 2010 Erik Valkering.
Cover picture: The ducky scene ray traced by CNRTS with shadows and reflections.
Ray Tracing NURBS Surfaces using CUDA
Author:
Student id:
Email:
Erik Valkering
1328913
[email protected]
Abstract
This thesis presents CNRTS, a CUDA-based system capable of ray tracing NURBS-surfaces,
directly. By coarsely subdividing the NURBS-surfaces in a preprocessing step, a more tight
bounding volume hierarchy is generated which can be traversed first, thus heavily reducing the
number of ray-patch intersection tests. Additionally, the smaller leaf-nodes provide better initial
seed-points, which allows the root-finder to converge more quickly. For scene-traversal, two
approaches have been investigated, a packet-based traversal scheme, employing a shared stack
implemented using the GPU’s fast on-chip memory. The second approach uses an optimized
single-ray traversal scheme, in which the scene-traversal and root-finding are separated from each
other, to help maximize the utilization during root-finding. The single-ray approach turns out to
be up to 3× faster than the packet-based approach.
Furthermore, a hybrid approach has been used in tracing primary rays, by employing the
rasterizer. Besides that only one ray-patch intersection test is required per ray, the initial seedpoints provided by the rasterization are very close. Using the hybrid approach, the performance
will generally be increased. However, an artifact-free rendering is not always guaranteed, due to
tessellation.
Thesis Committee:
Chair/supervisor:
Committee Member:
Committee Member:
Committee Member:
Prof.dr.ir. F.W. Jansen, Faculty EEMCS, CG, TU Delft
Dr. W.F. Bronsvoort, Faculty EEMCS, CG, TU Delft
Ir. J. Blaas, Faculty EEMCS, CG, TU Delft
Dr. A. Iosup, Faculty EEMCS, PDS, TU Delft
Preface
High-quality visualization of Non-Uniform Rational B-Spline (NURBS) surfaces, mostly found in
industrial designs (such as cars, airplanes, ships, etc.), is usually performed through rasterization,
after a costly preprocessing phase, in which the NURBS-model is converted to a triangular representation. In order to represent highly curved areas, the triangulation must be very fine. As a
consequence, a lot of triangles will be generated in areas with high curvature. This results in a long
preprocessing time, in which lots of triangles are generated.
In this thesis, a solution will be presented, which avoids the expensive preprocessing step, and
works directly with the NURBS-data. By employing the ray tracing algorithm, the resulting visualization will always appear smooth, regardless of the viewing distance. Because the original
NURBS-data is used for visualization, the memory requirements are very low. Furthermore, the ray
tracing system is fully implemented using CUDA to exploit the processing power of recent GPUs.
I would like to thank a number of people who have been a great help and support in realizing
this thesis. First of all, I would like to thank my supervisor Erik Jansen for the many interesting
discussions which kept me motivated and for providing really helpful advice on how to improve this
report.
Next, I would like to thank Jorik Blaas for all those clever ways on how to debug my software. I
would also like to thank Menno Kuyper for always be willing to help me to test my software on his
computer, despite of the many system crashes I have caused.
And last but not least, I would like to thank my parents, Bert and Ellen, for their continuous
support, in every possible way, and giving me the opportunity to study Computer Science.
iii
Contents
Contents
v
List of Figures
1
Introduction
1.1 Rasterization . . . . . . . . . . .
1.2 Ray Tracing . . . . . . . . . . . .
1.3 General-Purpose GPU computing
1.4 Structure of this thesis . . . . . .
I
Background
2
NURBS Basics
2.1 Definition . . . . . . . .
2.2 Cox-de Boor Recurrence
2.3 Knot-vector . . . . . . .
2.4 Convex Hull . . . . . . .
2.5 Knot-insertion . . . . . .
2.6 Surfaces . . . . . . . . .
2.7 Derivative . . . . . . . .
3
4
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
12
12
14
14
NURBS Ray Tracing
3.1 Scene Traversal . . . . . .
3.2 Packet-Based Ray Tracing
3.3 Ray-Patch Intersection . .
3.4 Adaptive subdivision . . .
3.5 Evaluation Schemes . . . .
3.6 Overview . . . . . . . . .
3.7 Discussion . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
19
19
22
26
32
33
NURBS Ray Tracing on the GPU
4.1 GPU Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Hybrid Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
37
43
v
C ONTENTS
5
CUDA
5.1 Massive Multi-threading Architecture
5.2 Memory Hierarchy . . . . . . . . . .
5.3 Launching a kernel . . . . . . . . . .
5.4 Debugging . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
II Development
45
45
46
48
48
51
6
System overview
53
6.1 Primary-ray Accelerator subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Ray Tracer subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7
Preprocessing
63
7.1 Subdivision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Root-Finder Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8
Kernel details
8.1 Inter-kernel Communication . . . .
8.2 Root-finding . . . . . . . . . . . . .
8.3 Surface Evaluation . . . . . . . . .
8.4 Primary-ray Accelerator subsystem .
8.5 Ray Tracer subsystem . . . . . . . .
8.6 Kernel-launch configurations . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
III Results
9
Results
9.1 Experimental Setup
9.2 Image Quality . . .
9.3 Performance . . . .
9.4 Analysis . . . . . .
9.5 Discussion . . . . .
69
69
72
72
74
77
86
89
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
91
91
93
97
104
109
10 Conclusions and Future Work
111
10.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Bibliography
vi
113
List of Figures
1.1
1.2
1.3
1.4
1.5
1.6
2.1
2.2
2.3
2.4
2.5
2.6
3.1
3.2
3.3
NURBS-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tessellation of a NURBS model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A model of the VW Polo from different viewpoints. The car remains perfectly curved,
even from the shortest viewing distance, thanks to the direct ray tracing of NURBS. . .
Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance statistics for the CPU and GPU. . . . . . . . . . . . . . . . . . . . . . .
Simplified processing model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fine-tuning a NURBS-curve (a): By specifying different weights (b) and through the
knot-vector (c,d). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example B-Spline basis-functions: constant (a), linear (b), quadratic (c) and cubic (d).
Example of polynomial segments of a cubic NURBS-curve. . . . . . . . . . . . . . .
~
Strong convex hull property: for u ∈ [ui , ui+1 ), C(u)
is in the triangle ~Pi−2~Pi−1~Pi (a) and
~
~
~
~
in the quadrilateral Pi−3 Pi−2 Pi−1 Pi (b). . . . . . . . . . . . . . . . . . . . . . . . . . .
Knot-insertion: knot inserted at t = 0.5. . . . . . . . . . . . . . . . . . . . . . . . . .
NURBS-surface example: Utah Teapot consisting of 32 bi-cubic patches. The patches
are visualized using a red and green color mapping for the parametric u and v direction,
respectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
1
2
.
.
.
.
2
3
4
5
. 10
. 11
. 12
. 13
. 13
. 14
3.4
3.5
3.6
3.7
3.8
Six levels in a Bounding Volume Hierarchy. . . . . . . . . . . . . . . . . . . . . . . .
Newton’s Iteration: each subsequent point is closer to the root. . . . . . . . . . . . . .
Plane representation for a ray for which |d~x | > |d~y | and |d~x | > |d~z | holds, results in a
plane rotated about the z-axis and a plane perpendicular to it (a) and for a ray for which
it does not hold, the resulting plane will be rotated about the x-axis (b). The cyan line
represents the ray and the yellow plane is the first plane ~p1 = (~n1 , d1 ). . . . . . . . . .
Example of a NURBS-curve with exemplary associated bounding volumes. . . . . . .
Flatness criterion based on the normals of a sub-patch. . . . . . . . . . . . . . . . . .
Splitting a sub-patch into two sub-patches obtaining two control-point grids. . . . . . .
Procedure to fix a crack in the tessellation. . . . . . . . . . . . . . . . . . . . . . . . .
Evaluating the NURBS basis-functions. . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
4.2
4.3
Multiple stages in the ray tracer of [PBMH05]. . . . . . . . . . . . . . . . . . . . . . . 36
Stackless BVH traversal encoding example. . . . . . . . . . . . . . . . . . . . . . . . . 37
Hybrid Ray Tracing phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
vii
. 18
. 20
.
.
.
.
.
.
21
23
24
25
25
31
L IST OF F IGURES
4.4
4.8
4.9
Overview of the algorithm stages and their relation to stages in the extended graphics
pipeline. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
uv-texturing using midpoint of parameter range (uniform subdivision: 2 × 2). Figure 4.5a shows the corresponding uv-texture. Figure 4.5b to Figure 4.5d show the result
for up to two, three, and four iterations, respectively. . . . . . . . . . . . . . . . . . .
uv-texturing using control point mapping (uniform subdivision: 2 × 2). Figure 4.6a
shows the corresponding uv-texture. Figure 4.6b to Figure 4.6d show the result for up
to two, three, and four iterations, respectively. . . . . . . . . . . . . . . . . . . . . . .
Figure 4.7a, Figure 4.7b view-independent uv-texturing vs. Figure 4.7a, Figure 4.7c
view-dependent uv-texturing (max. iterations: 10, subdivision: uniform, 4 × 4). Figure 4.7d is the difference between the initial values of both methods. . . . . . . . . . .
Artifacts which are handled correctly. . . . . . . . . . . . . . . . . . . . . . . . . . .
Artifacts which cannot be handled correctly. . . . . . . . . . . . . . . . . . . . . . . .
5.1
5.2
Thread blocks and their mapping to the multiprocessors. . . . . . . . . . . . . . . . . . 46
Memory Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1
6.2
System overview of the rendering core of the CNRTS . . . . . . . . . . . . . . . . . . . 53
Schematic overview of the rasterization phase of the Primary-ray Accelerator. The output provides some cues for finding the exact intersection-point: the left rasterized image
contains the patch-ids and the right rasterized image contains the uv-values encoded in
red for u-parameter range and green for v-parameter range. . . . . . . . . . . . . . . . . 54
The ray’s direction is derived from the viewing parameters. In here, a denotes the fieldof-view. By setting the image-plane’s distance d from the camera equal to 1, the position
in the image plane is easily converted to world-coordinates. . . . . . . . . . . . . . . . . 55
Artifacts appear when using the Primary-ray Accelerator solely. In Figure 6.4a, backgroundpixels appear instead of the surface. By forwarding all background-pixels to the Ray
Tracer, this artifact will disappear. Figure 6.4b shows some gaps, appearing in-between
two surfaces. Figure 6.4c shows an artifact which cannot be detected using the algorithm, the only solution is to tessellate more fine. . . . . . . . . . . . . . . . . . . . . . 57
The ray tracing algorithm separated into different CUDA-kernels. The CPU part coordinates the algorithm by launching the kernels successively. The inter-kernel data
propagation through global-memory is visualized by dashed lines, whereas the arrows
indicate the flow/dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Separation of image-space into tiles: instead of applying the ray tracing algorithm onto
the entire image, it is now applied successively to each tile. The tiles are visualized
using different shades of grey, the pixels are separated by dashed lines. . . . . . . . . . . 59
Implementing recursion for CUDA using a stack. . . . . . . . . . . . . . . . . . . . . . 60
Lifetime of a primary-ray processed by the Primary-ray Accelerator and the Ray Tracer.
A primary-ray is spawn by rasterizing the tesselation; a fragment is further processed by
the primary-ray accelerator’s root-finder; a hit may skip the ray tracer’s traversal and
root-finder and immediately continue by casting a shadow ray; misses and background
pixels are traced conventionally by the ray tracer;whereafter they are processed further
by casting a shadow ray; shading is applied for non-blocked shadow-rays; and finally
reflection and refraction rays are spawn and traced recursively. . . . . . . . . . . . . . . 62
4.5
4.6
4.7
6.3
6.4
6.5
6.6
6.7
6.8
7.1
7.2
7.3
viii
. 39
. 40
. 40
. 40
. 42
. 43
Overview of subdivision results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
The NURBS-surface is converted into smaller Bézier-patches. . . . . . . . . . . . . . . 64
Bounding boxes of a BVH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.1
8.2
8.3
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
9.10
9.11
9.12
9.13
9.14
Memory layout of a stack inside global-memory. This stack is for 4 threads and has a
maximum depth of 3. The exemplary “virtual” stack of thread 2 shows the mapping of
threads and stack-levels to global-memory addresses. . . . . . . . . . . . . . . . . . . . 70
Arrangement of data for a cache inside shared-memory. This example uses an array of
3 elements for each thread, and a block size of 4 threads. . . . . . . . . . . . . . . . . . 73
Mapping of pixels to threads. This example uses an image-resolution of 16 × 16, a tilesize of 4 × 4, and a block-size of 2 × 2. The tiles are visualized using a shade of grey,
the blocks are separated by black lines, and the pixels are separated by dashed lines. . . . 87
Test scenes used. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
teapot-scene: accelerator (left), full hybrid (middle), standard ray traced (right) . . . .
head-scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This image shows a close-up of the ducky-scene: hybrid (left), and normally ray traced
(right). It seems that the hybrid method can sometimes introduce artifacts, when zooming in too close. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Killeroo-closeup-scene rendering with a increasing miniterations-value. The images
correspond to the miniterations-values in Table 9.4. . . . . . . . . . . . . . . . . . . .
Average speedup of primary rays w.r.t. reference implementation (packet-based, no
caching, no acceleration). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Average speedup of shadow rays (level 0) w.r.t. reference implementation (packet-based,
no caching). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Average speedup of reflection rays (level 1) w.r.t. reference implementation (packetbased, no caching). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Average speedup of refraction rays (level 1) w.r.t. reference implementation (packetbased, no caching). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Durations of the variants using the 8800M test-system, as a function of the number of
patches. The red line shows the curve corresponding to a logarithmic function fitted to
the data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Durations of the variants using the GTX 295 test-system, as a function of the number of
patches. The red line shows the curve corresponding to a logarithmic function fitted to
the data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Number of BVH-nodes visited. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amount of time spent idle of total durations for each thread. . . . . . . . . . . . . . .
Frequencies of the average number of rays participating in the root-finding. . . . . . .
. 95
. 95
. 96
. 96
. 97
. 99
. 100
. 100
. 101
. 102
.
.
.
.
102
104
107
108
ix
Chapter 1
Introduction
In the field of CAD/CAM1 , designs are often modeled using curved, smooth-looking free-form
surfaces. In modeling industrial designs such as cars, airplanes, ships, etc. the surface-type of
choice is the Non-Uniform Rational B-Spline (NURBS) surface (Figure 1.1). This type of surface
is favored, because it provides local and intuitive control, has a very compact representation and is
very well suited for a large number of problems.
Figure 1.1: NURBS-model
In current CAD/CAM software, when visualizing a model, the curved surface is first tessellated
into a polygonal mesh in order to obtain a tight approximation of the surface (Figure 1.2). Such
a tessellation usually results in many polygons, taking up lots of memory. After the model has
been tessellated, the original continuity is lost, zooming in on the tessellated model will reveal this.
Besides memory requirements, the tessellation preprocessing step also takes some time. For complex
models found in the automobile industry for example, this can take up to a whole day making it not
very suitable for rapid prototyping [AGM06].
1.1
Rasterization
Usually, these polygon meshes are rendered using rasterization. Basically, this method first projects
the objects to a two-dimensional image plane, after which the algorithm determines for each pro1 Computer
Aided Design/Computer Aided Manufacturing
1
1. I NTRODUCTION
(a) Original NURBS-model
(b) Tessellated NURBS-model
Figure 1.2: Tessellation of a NURBS model.
jected object, which pixels of the image plane will be occupied by it. By taking the depth of the
objects into account, the pixels will be given the color of the closest object for that pixel. While
this method enables easy visualization of the model, it does not handle physically-correct lighting
effects, such as shadows, reflections, refractions, etc. which are often needed in industrial prototyping. In order to include these effects, several methods have been devised to approximate them.
Reflections, for example, can be obtained by first generating a texture onto which the environment
surrounding the object is projected (usually using a spherical or cubical texture). During rendering,
reflection is applied by following the reflection-vector to obtain the reflection-texel from the environment map. However, since only the environment is stored in the texture, self-reflection cannot be
simulated using this method. Furthermore, since the rendering time of the rasterization method is linear in the number of polygons, eventually the models become too complex, and cannot be visualized
interactively anymore. Although rasterization, when implemented on graphics hardware, quickly
generates images having reasonable quality, the effects necessary to obtain a realistic visualization
are non-trivial and methods to simulate them usually produce very rough approximations.
1.2
Ray Tracing
An alternative to rasterization is visualization using the ray tracing algorithm [WH80]. The relatively
simple algorithm, compared to rasterization, implicitly embeds all these effects in a physicallycorrect way. Although this algorithm is computationally much more expensive, it is logarithmic
in the number of objects. Therefore, increasing the tessellation-complexity will have less impact
on the performance when compared to rasterization. Moreover, by using ray tracing, the resulting
pixel values can even be computed directly without the intermediate tessellation step. In this way,
the original model can be used instead, reducing memory requirements, and increasing the detail
(Figure 1.3).
Figure 1.3: A model of the VW Polo from different viewpoints. The car remains perfectly curved,
even from the shortest viewing distance, thanks to the direct ray tracing of NURBS.
The algorithm is actually quite simple. Instead of projecting each geometrical object to the two2
General-Purpose GPU computing
Figure 1.4: Ray Tracing
dimensional image plane, this algorithm works the other way around. For each pixel in the image
plane, the color is determined by “shooting” a primary ray originating from the camera (the eyes of
the viewer) passing through that pixel and finding the closest intersection with an object from which
the color is obtained. These primary rays “look” into the scene and try to find an object it sees. If
no object crosses the path of the ray, the ray will leave the scene non-intersected and the color of the
corresponding pixel will be set to a default background color. This primary intersection stage will
result in an image equivalent to the rasterization algorithm, and is known as Ray Casting.
If the ray does intersect an object, the lighting of the primary intersection is computed by spawning several secondary rays originating from the intersection point of the corresponding object: for
each light-source in the scene a shadow ray pointing to this light-source; one reflection ray pointing to the mirror-reflection direction from a shiny surface; and one refraction ray, with a direction
into the surface of the object (in case of a (semi)transparent surface). The shadow rays are used to
determine if the primary intersection is illuminated by the light-sources. If any object happens to
block the path of a shadow ray, the light of the corresponding light-source will not reach the primary
intersection and will not contribute to the illumination of it. The other secondary rays are further
traced recursively to compute secondary intersections which may contribute in the final lighting for
the primary intersection. These secondary intersections will again spawn rays and the process is
continued recursively until a certain traversal-depth has been reached or the color converges. This
process can be seen in Figure 1.4.
Although the generated images by the Ray Tracing algorithm are much more realistic than the
images generated by the Rasterization algorithm, the cost for generating them however, is very high.
Algorithm 1 shows the basic ray tracing algorithm, which is executed for each pixel. As can be
drawn from the algorithm, the complexity of a basic ray tracer depends on the total number of pixels
N in the image plane, the number of geometrical objects M in the scene and the traversal-depth D for
each ray and can be described as O(NM D ). Later will be shown, how this complexity can be reduced
to O(N log(M)D ), by introducing an acceleration structure which reduces the number of intersection
computations to a relatively small subset of the objects in the scene.
1.3
General-Purpose GPU computing
In the last few years the potential numerical performance of graphics processing units (GPUs) has
grown dramatically. Modern GPUs usually offer multiple processor cores running in parallel. Furthermore the available memory bandwidth is usually also very high, typically 60 GB/s or more. This
high memory bandwidth is needed to keep the cores busy. Figure 1.5 gives the potential numeri3
1. I NTRODUCTION
Algorithm 1 Ray Tracing algorithm
Require: Ray R, Traversal-depth d
Ensure: Color C of ray
1: C ← Default background color
2: if R intersects an object in the scene then
3:
O ← Nearest object intersected by R
4:
for all light-source L in the scene do
5:
S ← Shadow-ray originating from Land pointing to O
6:
if S intersects no object then
7:
C ← C + Apply illumination model(L, O)
8:
end if
9:
end for
10:
if d ≤ maximum traversal-depth D then
11:
{Ri } ← Secondary reflection and refraction rays
12:
C ← C + ∑i Ray Trace(Ri , d + 1)
13:
end if
14: end if
15: return C
cal performance of both the latest GPU and CPU families. The potential numerical performance
is expressed in GFLOPS2 . The main reason of the fast evolution of modern GPUs is that they are
specially designed for compute intensive and highly parallel computation.
(a) Floating-Point Operations per Second
GT200
G92
G80
G71
= GeForce GTX 280
= GeForce 9800 GTX
= GeForce 8800 GTX
= GeForce 7900 GTX
(b) Memory Bandwidth
G70
NV40
NV35
NV30
= GeForce 7800 GTX
= GeForce 6800 Ultra
= GeForce FX 5950 Ultra
= GeForce FX 5800
Figure 1.5: Performance statistics for the CPU and GPU.
A typical CPU has a very large cache memory and a very deep pipeline. The cache memory
is required to hide long memory latencies; the pipeline is required to hide complicated arithmetic
2 Giga
4
FLoating-point Operations Per Second
General-Purpose GPU computing
operations. So the latency for most operations on a CPU is very short. But usually a CPU only offers
a couple of fixed and floating point arithmetic and logical units (ALUs). So the number of operations
that can be done in parallel is very limited. In other words a CPU is not really suitable for highly
parallel computation.
Modern GPUs do not have very large data caches or very deep pipelines. Most of the transistors
on the chip are devoted for data processing. The simplified processing model of a typical CPU and
GPU is given in Figure 1.6.
(a) CPU
(b) GPU
Figure 1.6: Simplified processing model.
A GPU is very well suitable for applications/algorithms that require the same set of operations
for each data element. Because the same set of operations is performed for each element there is a
lower requirement for sophisticated flow control; and because it is executed on many data elements
and has high arithmetic intensity, the memory access latency can be hidden with calculations instead
of big data caches.
But using this large amount of potential numerical performance can be tricky. A typical GPU
can only be programmed in special development environments using special programming languages
(such as Microsoft’s HLSL, OpenGL GLSL, NVIDIA Cg) and complicated (texture) memory fiddling. Furthermore, no recursion is supported, due to the lack of a stack. In other words, it involves a
high learning curve. However, more recently several GPGPU3 -languages have been devised in order
to help the programmer to focus on the parallel problem, instead of all the stages in the graphics
pipeline. These languages allow to program in a familiar language such as c or c++. The tools then
generate code that run as shaders using the graphics pipeline (BrookGPU, Sh, RapidMind, CUDA).
The latter of these languages, CUDA, is used throughout this thesis, and will be discussed in more
detail in Chapter 5.
Ray tracing is an inherently parallel and highly compute intensive operation. Therefore, the
GPU should be exploited as much in order to speed up the visualization process. However, due to
the divergent nature of the algorithm, it’s hard to keep all processor cores busy at all times. Some
rays may require more intersection tests, while others are already finished. By employing a ray
tracing algorithm which maximizes the number of active cores in addition with a fast intersection
test, these problems can be overcome. In addition, a hybrid rasterization/ray tracing approach is
taken in accelerating the ray tracing of primary rays.
3 General-Purpose
GPU
5
1. I NTRODUCTION
1.4
Structure of this thesis
This thesis will continue with part I, which focuses on the existing literature. In Chapter 2, the
mathematical basics for NURBS and their algorithms will be given. Then, in Chapter 3, existing
techniques are described for ray tracing NURBS-surfaces. Next, in Chapter 4, this discussion will
extend to GPU-implementations. Finally, Chapter 5 will discuss the CUDA architecture, which is
used in this thesis.
Part II of this thesis will present the CNRTS, the ray tracing system developed for this thesis.
Chapter 6 will give a brief overview of the system’s architecture. Next, Chapter 7 will describe the
preprocessing steps required prior to visualization. And finally, Chapter 8 will give a more in-depth
description of the system.
The final part of the thesis, part III, will discuss the results achieved with the system described in
part II. Chapter 9 will discuss the methods used to evaluate and analyze the system, and Chapter 10
will conclude this thesis, by summing up the most important observations, and giving some hints on
how the system can be further improved.
6
Part I
Background
7
Chapter 2
NURBS Basics
In geometric modeling, the two most common methods of representing curves and surfaces are
implicit equations and parametric functions [PT97]. While both forms have advantages over each
other, the parametric form is the preferred method to represent free-form surfaces in computer aided
geometric design, due to its intuitive geometrical properties. In parametric form, the coordinates of
a surface-point are represented separately as an explicit function of two independent parameters


x(u, v)
S(u, v) =  y(u, v)  ,
z(u, v)
(u, v) ∈ [a, b] × [c, d].
Thus, ~S(u, v) is a vector-valued function of the independent variables, u and v. For many types of
free-form surfaces, the domain is normalized to let 0 ≤ u, v ≤ 1, in order to simplify computations[PT97].
The most used type of parametric free-form surface is the Non-Uniform Rational B-Splinesurface or NURBS-surface. Before going into the details of this surface type, the NURBS-curve
is discussed first, which is easily extended to a surface. Section 2.1 will start with some mathematical definitions about NURBS.
2.1
Definition
Geometrically, a NURBS-curve is defined by a set of control-points, along with a weight for each
control-point, and a knot-vector. The control-points roughly specify the shape of the curve (see
Figure 2.1a). The shape of the resulting curve can be fine-tuned in several ways: by including
more control-points around an existing control-point, the curve will be drawn towards the cluster
of control-points. However, this will require more storage for representing the curve, since more
control-points are needed in order to obtain the desired shape. Alternatively, by specifying a weight
for each control-point, the curve can be pulled towards the control-point by increasing this weight
(see Figure 2.1b). Decreasing this value will push the curve away from the control-point. Using
weights instead of extra control-points, a more compact representation of the curve is obtained. More
important, using the weights, the required geometry can be specified very precisely, without them
it is impossible to represent basic shapes such as circles, arcs and other conic sections. Therefore,
using NURBS it is possible to specify analytical shapes as well as free-form shapes. Finally, the
knot-vector is used to fine-tune the shape of the curve (Figure 2.1c, Figure 2.1d). The knot-vector
will be discussed in Section 2.3. The power of a NURBS-curve lies in the fact that its complexity
is independent on the number of control-points. Instead, it depends on its degree. Therefore, a
NURBS-curve can be adjusted locally without changing the shape of the entire curve.
9
2. NURBS BASICS
P
P
2
P
3
P
P
2
P
3
P
5
P
2
3
P
5
5
w =1
P
P
1
P
P
P
6
2
w = 10
1
2
P
0
(a)
P
2
w = 0.1
4
P
P
6
P
1
P
4
P
0
(b)
6
4
0
0
(c)
1
(d)
Figure 2.1: Fine-tuning a NURBS-curve (a): By specifying different weights (b) and through the
knot-vector (c,d).
~
Mathematically, a NURBS-curve C(t)
is a piecewise rational function defined by a set of n control~
points {Pi } along with their weights {wi }, its degree p (or its order p + 1), and a non-decreasing
sequence {t0 , ...,tn+p } called the knot-vector on the domain [t p ,tn ]:
n−1 ~ p
~
~ = ∑i=0 wi Pi Ni (t) ≡ D(t) ,
C(t)
p
w(t)
∑n−1
i=0 wi Ni (t)
(2.1)
or more compact as:
n−1
~ h (t) =
C
∑ ~Pih Nip (t) ≡
~D(t), w(t) ,
(2.2)
i=0
p
where the Ni (t) functions are the B-Spline basis-functions (discussed in Section 2.2). The {~Pih }
control-points embed their weights using a homogeneous space-coordinate, by multiplying each coordinate with the weight wi and appending the weight to the control-point: ~Pih ≡ (wi~Pi , wi ). To obtain
~ h (t) only needs to be divided by its homogeneous
the corresponding curve-point as in Equation 2.1, C
coordinate w(t).
In the special case of all weights equaling one, the equation reduces to:
n−1
~ =
C(t)
∑ ~Pi Nip (t).
(2.3)
i=0
2.2
Cox-de Boor Recurrence
The B-Spline basis-functions, or blending-functions, in Equation 2.1 are used to smoothly blend
together the control-points of the curve. They are derived from a knot-vector (Section 2.3) using the
Cox-de Boor Recurrence formula [dB72, Cox72]:


if p = 0and t ∈ [ti ,ti+1 ),

1
p
if p = 0and t ∈
/ [ti ,ti+1 ),
(2.4)
Ni (t) = 0
h
h
i
i

p−1

 t−ti Nip−1 (t) + ti+p+1 −t Ni+1
(t) otherwise.
ti+p −ti
ti+p+1 −ti+1
Here, Ni0 (t) are step functions equal to zero except in the interval [ti ,ti+1 ). For the basis-functions of
higher degree, they are linear combinations of two lower-degree basis-functions (Figure 2.2). In the
case the numerator and the denominator are both zero, the convention is used that 00 ≡ 0.
10
u
Knot-vector
(a)
(b)
(c)
(d)
Figure 2.2: Example B-Spline basis-functions: constant (a), linear (b), quadratic (c) and cubic (d).
2.2.1
Local support
Following the dependencies of the recurrence, the following triangular structure appears:
p
Ni (t)
p−1
p−1
Ni (t) Ni+1 (t)
p−2
p−2
p−2
Ni (t) Ni+1 (t) Ni+2 (t)
..
.
Ni0 (t)
0 (t)
Ni+1
0 (t)
Ni+2
0 (t) · · · N 0 (t)
Ni+3
i+p
p
p
0 , therefore N (t) is
As can be seen, basis-function Ni (t) depends on basis-functions Ni0 (t) · · · Ni+p
i
zero if t ∈
/ [ti ,ti+p+1 ). This means that each control-point Pi has local support on the curve on the
domain [ti ,ti+p+1 ), moving the control-point does not change the shape globally.
2.3
Knot-vector
The knot-vector determines the resulting basis-functions and thus the shape of the NURBS-curve. A
knot-vector ~t consists of a non-decreasing sequence of n + p + 1 real numbers, the so-called knots,
where n is the number of control-points of the corresponding curve, and p is the degree of that curve:
~t = {t0 ,t1 , · · · ,tn+p } .
(2.5)
These knots “tie together” the polynomial pieces of the basis-functions (Figure 2.3). Each successive
pair of knots represents a parametric interval [ti ,ti+1 ) called a knot-span. Knot-spans may be empty,
increasing a knot’s multiplicity (the number of successive knots which are equal). At a knot of
p
multiplicity k, a basis-function Ni (t) is C p−k continuous, i.e. p − k times differentiable. Obviously,
p
within a non-empty knot-span, a basis-function Ni (t) is C∞ continuous, since in that region the basisfunction is defined by only one single polynomial. In the special case of a knot ti having multiplicity
p
p
p, the only non-zero basis-function is Ni (t), with Ni (ti ) = 1. Therefore, the curve interpolates the
control-point ~Pi at t = ti .
There are basically three flavors of knot-vectors: periodic, non-periodic, and non-uniform. The
periodic knot-vectors have equidistant knots. Curves using periodic knot-vectors result in having the
endpoints coincide, obtaining a closed shape. For example, a periodic knot-vector for a curve with
n = 4 control-points and degree p = 3 could be:
~t = {0, 1, 2, 3, 4, 5, 6, 7} .
Non-periodic knot-vectors also have equidistant knots, except for the first and last knots, having a
multiplicity of p + 1. As a result, the curve interpolates both endpoints. For example, a non-periodic
11
2. NURBS BASICS
Figure 2.3: Example of polynomial segments of a cubic NURBS-curve.
knot-vector with n = 7 control-points and degree p = 2 could be:
~t = {0, 0, 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.5, 0.5} .
Non-uniform knot-vectors provide more flexibility as they allow each knot-span to vary. For example, a non-uniform knot-vector with n = 9 control-points and degree p = 2 could be:
~t = {0, 0, 0, 0.5, 0.5, 0.75, 2, 2, 2.5, 2.5, 2.5} .
Finally, a very special knot-vector is the non-periodic knot-vector for which n = p + 1. These
knot-vectors result in basis-functions mathematically equivalent with Bernstein-polynomials, which
are used by the well-known Bézier-curves [BM99]. For example, the following knot-vector results
in a cubic Bézier-curve:
~t = {0, 0, 0, 0, 1, 1, 1, 1}
2.4
Convex Hull
A very useful property of B-Spline basis-functions is the partition of unity which states:
i
∑
p
N j (t) = 1
for all t ∈ [ti ,ti+1 ).
(2.6)
j=i−p
Which is proved easily by expressing the sum in terms of lower-degree basis-functions. For the full
proof I refer to [PT97].
Combined with the local support property (Section 2.2.1), the following statement can be made,
known as the strong convex hull property: if t ∈ [ti ,ti+1 ), then C(t) is contained within the convex
hull of the control-points ~Pi−p , ..., ~Pi . This property is shown in Figure 2.4.
2.5
Knot-insertion
Another basic ingredient for many other algorithms is knot-insertion, in which a knot is inserted in
an existing knot-vector without changing the shape of the curve [PT97]. However, since the size
of the knot-vector is always equal to n + p + 1, an extra control-point needs to be added (or the
degree needs to be incremented, but this modifies the shape of the curve). Furthermore, the existing
control-points need to be modified in order to preserve the shape of the curve.
When inserting a knot t ∈ [ti ,ti+1 ), the local support property (Section 2.2.1) states that only
p
p
basis-functions Ni−p (t)..Ni (t) are non-zero. Therefore, the computation of the new control-points
can be restricted to only these. The following scheme transforms the old control-points {~P0 , ..., ~Pn }
12
Knot-insertion
(a)
(b)
~
Figure 2.4: Strong convex hull property: for u ∈ [ui , ui+1 ), C(u)
is in the triangle ~Pi−2~Pi−1~Pi (a) and
in the quadrilateral ~Pi−3~Pi−2~Pi−1~Pi (b).
~ 0 , ..., Q
~ n+1 } (Figure 2.5):
to the new ones {Q


~Pk
~
Qk = (1 − αk )~Pk−1 + αk ~Pk

~
Pk−1
k ≤ i− p
i− p < k ≤ i
otherwise,
where
αk =
t − tk
.
tk+p − tk
Figure 2.5: Knot-insertion: knot inserted at t = 0.5.
13
2. NURBS BASICS
2.6
Surfaces
A NURBS-curve is easily generalized to a NURBS-surface ~S(u, v), by defining ~S(u, v) as a grid
of n × m control-points {~Pi j } along with their weights {wi j }, the degrees p and q, and two sets
of basis-functions for each parametric direction, together with their knot-vectors {u0 , ..., un+p } and
{v0 , ..., vm+q }:
h
i
q
n−1
~ p
∑m−1
~D(u, v)
j=0 ∑i=0 wi j Pi j Ni (u) N j (v)
~S(u, v) =
n−1
q
≡
,
(2.7)
p
m−1
w(u, v)
∑ j=0 ∑i=0 wi j Ni (u) N j (v)
or analogous to Equation 2.2:
"
m−1 n−1
~h
S (u, v) =
∑ ∑
j=0
#
~Pihj Nip (u)
q
N j (v) ≡ ~D(u, v), w(u, v) .
(2.8)
i=0
which needs to be divided by its homogeneous coordinate w(t) in order to obtain the surface-point.
The domain of the surface is then being defined as [u p , un ] × [vq , vm ]. Just like the parametric domain
of a NURBS-curve is divided into spans, the parametric domain of a NURBS-surface is divided into
rectangular areas called patches (Figure 2.6). The patches are defined by each combination of the
non-empty spans between the two parametric directions.
Figure 2.6: NURBS-surface example: Utah Teapot consisting of 32 bi-cubic patches. The patches
are visualized using a red and green color mapping for the parametric u and v direction, respectively.
2.7
Derivative
The availability of the partial derivatives of a NURBS-surface is very important for many algorithms,
such as finding the roots, determining the normal at a point on a surface, computing the curvature,
etc. In this section, a very simple analytical formula is given for the derivative of a NURBS-curve,
which is then extended to the partial derivatives computation of a NURBS-surface.
14
Derivative
The first-order derivative of a NURBS-curve is obtained by applying the quotient rule to Equation 2.1:
0
~ 0 ~
~ 0 = w(t)D(t) − D(t)w(t) ,
(2.9)
C(t)
w(t)2
where
n
n
~D(t)0 = ∑ wi~Pi Nip (t)0 ,
i=0
and
p
Ni (t)0 =
p
w(t)0 = ∑ wi Ni (t)0 ,
i=0
p
p
p−1
p−1
Ni (t) −
Ni+1 (t) .
ti+p − ti
ti+p+1 − ti+1
(2.10)
A proof for Equation 2.10 can be found in [PT97, Pro05].
The first-order partial derivatives of a NURBS-surface follow by applying the quotient rule to
Equation 2.7:
~ u (u, v) − ~D(u, v)wu (u, v)
w(u, v)D
,
S~u (u, v) =
w(u, v)2
~ v (u, v) − ~D(u, v)wv (u, v)
w(u, v)D
S~v (u, v) =
,
w(u, v)2
(2.11)
(2.12)
where
m
~ u (u, v) =
D
"
n
∑ ∑
#
p
wi j ~Pi j Ni (u)0
q
N j (v),
m
wu (u, v)
=
j=0 i=0
m
~ v (u, v) =
D
∑
"
n
n
∑ ∑
#
p
wi j Ni (u)0
q
N j (v),
j=0 i=0
#
∑ wi j ~Pi j Nip (u) N qj (v)0 ,
j=0 i=0
"
m
wv (u, v)
=
"
n
∑ ∑
#
p
wi j Ni (u)
q
N j (v)0 .
j=0 i=0
15
Chapter 3
NURBS Ray Tracing
As we discussed in Chapter 1, rasterization of the tessellation is not very memory-friendly, requires
a long preprocessing time, and does not provide the desired realism. Furthermore, it will become a
very slow visualization for too complex scenes. Although ray tracing solves these last two problems,
it still depends on the quality of the tessellation.
Alternatively, the original NURBS-surface can be ray traced directly, by employing a root-finder
to find intersections between a ray and the original mathematical representation of the NURBSsurface (Section 3.3.1). This method, while being more expensive, leads to an always exact visualization of the surface without any artifacts, independent of the view point. Additionally, since the
surface does not need to be converted into a triangular mesh, the tessellation step can be avoided,
resulting in a shorter start-up time and lesser memory requirements.
Before we discuss the ray-patch intersection algorithm, we start with some BVH-based methods
to traverse through the scene more efficiently.
3.1
Scene Traversal
A naive implementation of the basic ray tracing algorithm will test every object for an intersection
during ray traversal, resulting in many costly computations. Already since the very beginning of
ray tracing, several ray traversal acceleration data structures have been developed, in order to reduce
this number of ray/object intersection tests. The first one ever used in ray tracing was the bounding
volume hierarchy (BVH) [WH80], after which many other more efficient data structures have been
used, such as uniform grids, octrees, kd-trees, etc. In 2001, Havran investigated these data structures
in his PhD. thesis, and concluded the kd-tree as the most efficient, and the BVH as the least efficient
[Hav01].
More recently, the bounding volume hierarchy has gained more popularity, due to its simpler
traversal algorithm, lesser memory requirements and being more appropriate for dynamic scenes
[WBB08, WBS07, LYTM06]. Furthermore, BVHs built according to the surface area heuristic
[MB90] seem to be quite competitive to kd-trees, when traced using packets of rays (Section 3.2)
[WBS07].
The Bounding Volume Hierarchy, or BVH, is a hierarchical scene partitioning datastructure. It
differs from spatial partitioning techniques (uniform grid, kd-tree, etc.) in that it partitions objects
as opposed to space.
In general, a BVH starts with a root-node, holding a bounding volume corresponding to the
entire scene (usually a sphere or a bounding box). The children of the root-node, and in general of
every internal-node1 , partition their parent’s objects by holding a bounding volume of a subset of
1A
node with children is called an internal-node.
17
3. NURBS R AY T RACING
(a) Level 0
(b) Level 1
(c) Level 2
(d) Level 3
(e) Level 4
(f) Level 5
Figure 3.1: Six levels in a Bounding Volume Hierarchy.
Algorithm 2 Traverse-BVH
Require: Ray R, BVH-Node N
Ensure: Object O
1: if R does not intersect the BV of N then
2:
return null
3: end if
4: if N is leaf-node then
5:
return Object of(N)
6: end if
7: for all child C do
8:
O ← Traverse-BVH(R,C)
9:
if O is not null then
10:
return O
11:
end if
12: end for
their parent’s objects. Finally, a node without children is called a leaf-node, which wraps a single
object and holds a bounding volume of it. Figure 3.1 shows an example of BVH built from a scene.
3.1.1
BVH Traversal
The basic ray traversal algorithm is modified by first testing for an intersection with the BVH. A ray
missing the bounding volume of the root-node implies a ray missing the entire scene and is therefore
discarded. Otherwise the ray is tested against the bounding volume of the child-nodes, and the ray
is traversed further through the nodes the ray intersects, if any. This process continues recursively
until the traversal reaches a leaf-node, where the basic algorithm is executed. Algorithm 2 shows the
modified traversal using a BVH as the acceleration datastructure.
Using this method, many costly ray/object intersection tests will be avoided, since rays will
terminate early when missing a bounding volume. On average, a ray traverses the tree until a leaf is
reached or the ray is early terminated, because the ray misses all bounding volumes. Since the depth
of the tree is logarithmic in the number of objects in the scene, traversing the scene is now of order
O(logn), instead of O(n).
3.1.2
BVH Construction
A careful construction of the BVH-tree is very important. Because the BVH determines how a
ray traverses the scene, a badly constructed BVH will result in many ray/bounding box-intersection
tests. For other meshes with no additional hierarchical information, the construction of the BVH
is non-trivial. The BVH is usually constructed by recursively partitioning the scene objects using
18
Packet-Based Ray Tracing
a split plane determined by some heuristic. Traditional heuristics determine the splitting plane to
be the midpoint of the bounding box’ axis with the longest extent (spatial median) or the midpoint
through the median of the objects when sorted along the axis with the longest extent (object median).
Although the spatial or object median methods lead to a very efficient construction algorithm, the
BVH-traversal efficiency is generally not very high. A better way to determine where to partition the
scene is by using the Surface Area Heuristic. This algorithm chooses from a set of splitting planes,
the one with the lowest cost based on the surface area and number of primitives of the children.
More information about this algorithm can be found in [GS87, MB90].
3.2
Packet-Based Ray Tracing
In [WSBW01], a modified version of the standard ray tracing algorithm is presented, which is called
the RTRT system. By paying close attention to the coherence among the rays, a performance increase
of an order of magnitude is achieved by tracing packets of rays in parallel.
A kd-tree datastructure is used to accelerate the ray traversal. Since the traversal algorithm is
relatively simple to implement, the complexity of the code is reduced so the compiler can optimize
the generated code.
A traditional ray tracer will trace all rays sequentially. However, since there is a lot of coherence among primary rays and to a somewhat lesser degree among shadow rays, the same memory
locations will be accessed multiple times for rays that intersect the same primitive. In order to remedy this, multiple rays are grouped together to form a packet of rays. Now the whole packet is
traced simultaneously. This way, the memory is only accessed once for the whole packet, instead of
separately for each ray.
During traversal a packet has three choices: traverse the left child, the right child or both. Although the rays inside the packet are coherent, it is not guaranteed that they all will traverse the
same child. Therefore some rays get disabled when traversing the non-intersecting child. This way,
unnecessary calculations will be avoided.
By using SIMD instructions, the packets can be traversed, intersected and shaded in parallel.
Since the major bottle-neck in Ray Tracing is the memory bandwidth [WSBW01], it is necessary
to exploit the caches as much as possible. By aligning the data to the cache lines, every data item can
be fetched by loading one cache line. Items larger than the cache line width, are split over multiple
cache lines and padded to half the width. In order to minimize the bandwidth requirements, only
data needed for the actual computation is kept together. In this way, loading data is avoided that
will not be used. Another problem is the relative high latency for accessing the main memory. By
prefetching the data, instead of fetching it on demand, the data will be available instantly when they
are needed.
3.3
Ray-Patch Intersection
The most important part of a NURBS Ray Tracer is the intersection test between a three-dimensional
ray and the surface, since this test determines if the corresponding pixel should be colored using the
surface or not. Normally, such a test would be trivial since a lot of fast analytical intersection tests
are available for standard primitives, such as triangles, quadrilaterals, etc. However, for NURBSsurfaces, this is less obvious.
Algebraic methods Several approaches exist for computing an intersection between a ray and
a NURBS-surface. Algebraic methods have been devised for the intersection of a ray and a bicubic parametric surface [Kaj82]. While this method computes the exact intersection, it requires
the computation of the roots of a polynomial of 18th degree. Solving such a polynomial will be
19
3. NURBS R AY T RACING
very expensive. Furthermore, this method will be applicable to bi-cubic surfaces only and not to
NURBS-surfaces.
Subdivision Another approach is on-the-fly subdivision [BBLW07]. By repeatedly subdividing
the NURBS-patches, the mesh will converge to the actual surface. Due to the coherence among
rays, same patches will be subdivided in exactly the same way. By paying attention to the coherence
among these rays, the subdivision-cost can be amortized over a “packet” of rays. When the subdivision is sufficiently close to the limit surface, the Ray Tracer can use standard tests to compute the
intersection.
Numerical methods The third approach is a numerical method to approximate the intersection,
known as Newton’s Iteration, or the Newton-Rhapson method [PTVF97]. This method uses a very
simple algorithm to iteratively find better approximations of the roots of non-linear functions. A
nice property of the algorithm is, that in each subsequent iteration, the error of the approximation
decreases quadratically, roughly meaning that in each iteration the number of correct digits are doubled. Additionally, the algorithm only requires the previous approximation, to compute the next
approximation, thus keeping memory requirements low. The algorithm depends on the function, its
derivative, and an initial guess. For this initial guess, it is very important to be close enough to the
exact solution in order for the method to converge towards the correct root.
This method will be explained in more detail in Section 3.3.1. Obtaining suitable initial guesses
for NURBS-surfaces will be discussed in Section 3.4.
3.3.1
Newton-Rhapson Method
The general idea is to start with the initial guess and compute the tangent line that approximates the
function at that point Figure 3.2. The x-intercept of this tangent line will typically be closer to the
root, than the initial guess. Now this process can be repeated to obtain closer approximations to the
root of the function:
f (xn )
(3.1)
xn+1 = xn − 0
f (xn )
x
xn+1
xn
Figure 3.2: Newton’s Iteration: each subsequent point is closer to the root.
However, we are dealing with a ray/NURBS-surface intersection, therefore the standard algorithm needs to be extended. The approach taken by [MCFS00] is discussed in here. The ray
20
Ray-Patch Intersection
~ where ~o denotes the ray’s origin and d the direction, is represented as the intersection of
~r = ~o + λd,
two orthogonal planes ~p1 = (~n1 , d1 ) and ~p2 = (~n2 , d2 ), where the ~ni are orthogonal vectors of unit
~ The di , the planes distances to the world’s origin, are given by di =~ni ·~o,
length, perpendicular to d.
with ~o denoting the ray origin. The plane equations are setup by:

(d~y ,−d~x ,0)


q
if |d~x | > |d~y | and |d~x | > |d~z |
d~2 +d~2
~n1 = (0,d~ x,−d~y )
z
y


 qd~2 +d~2
y
z
(3.2)
otherwise,
~ −1
~n2 =~n1 × d~ · |d|
(3.3)
d1 =~n1 ·~o
(3.4)
d2 =~n2 ·~o.
(3.5)
The first plane equation results in a plane with a normal lying in the xy-plane or the yz-plane, depending on the largest magnitude of the components of the direction of the ray Figure 3.3.
(a)
(b)
Figure 3.3: Plane representation for a ray for which |d~x | > |d~y | and |d~x | > |d~z | holds, results in a
plane rotated about the z-axis and a plane perpendicular to it (a) and for a ray for which it does not
hold, the resulting plane will be rotated about the x-axis (b). The cyan line represents the ray and the
yellow plane is the first plane ~p1 = (~n1 , d1 ).
To find the intersection of a surface ~S(u, v) and a ray, we have to find the roots of:
~
~R(u, v) = ~n1 · S(u, v) + d1 .
~n2 · ~S(u, v) + d2
(3.6)
Geometrically, this can be interpreted as the distance from the evaluated surface-point to the ray.
~R(u, v) becoming zero indicates that this distance becomes zero, hence an intersection point is found.
The iteration will be continued until one of the following termination criteria is met:
1. If the distance to the real root falls below some user defined threshold ε, then an intersection
point is found, i.e.
~
R(un , vn ) < ε
Since the obtained intersection point is an approximation, it will definitely not lie along the
ray. Therefore, to obtain the ray parameter λ, the point is projected onto the ray:
~
λ = (~S(u, v) −~o) · d.
(3.7)
21
3. NURBS R AY T RACING
2. Whenever the iteration takes us further away from the root, the computation will be aborted,
assuming divergence.
~
R(un+1 , vn+1 ) > ~R(un , vn )
3. A maximum number of iteration steps has been performed, also indicating divergence.
Whenever none of the criteria is met, the algorithm continues with a next iteration by updating the
(u, v) values. However, since we are dealing with a bi-variate function, Equation 3.1 cannot be
employed. Instead, the iteration step is extended to a two-dimensional problem, given by:
un+1
un
=
− J −1~R(un , vn )
(3.8)
vn+1
vn
where J is the Jacobian matrix of ~R containing the partial derivatives:
J=
~n1 · ~Su (u, v) ~n1 · ~Sv (u, v)
~n2 · ~Su (u, v) ~n2 · ~Sv (u, v)
(3.9)
One problem which may occur, is that the Jacobian matrix turns out to be singular, making it impossible to compute the inverse. This may happen for example at non-regular areas of the surface
(i.e. where the normals are zero). Therefore, in the case of a singular Jacobian, the (u, v) values are
perturbed with some small random values. Algorithm 3 gives an overview on how to compute the
intersection between a ray and a NURBS-surface, given an initial-guess value (u, v).
The core part of the algorithm, the so-called iteration, heavily depends on the evaluation of a
surface-point together with its partial-derivatives. Several algorithms exist for efficient evaluation of
surface-points and partial-derivatives.
3.4
Adaptive subdivision
The first step required for a direct NURBS Ray Tracing implementation is the creation of a Bounding
Volume Hierarchy (Section 3.1.2). Normally, a leaf of a BVH bounds multiple primitives. Since the
cost for the intersection test between a ray and a triangle2 is relatively low compared to that of
traversing the BVH, it is clever to group multiple primitives. However, when ray tracing NURBSsurfaces, this cost is very high, therefore, it is generally not a very good idea to group multiple
NURBS-surfaces into a single BVH-leafnode. Instead of each BVH-leafnode bounding multiple
surfaces, the surface is refined and for each sub-patch, a new child node is created bounding the
convex hull of the sub-patch, as in [MCFS00]. Besides a reference to the corresponding surfacepatch, these leaf-nodes also contain an initial-guess parameter value, for the Newton’s Iteration rootfinder (Section 3.3.1). This initial guess value is defined as the center of the parametric interval of the
sub-patch’s parametric domain. By increasing the number of leaf-nodes for a surface, the parametric
interval becomes smaller, and a better initial guess value is obtained (Figure 3.4). Additionally, by
increasing the number of leaf-nodes per surface, the number of intersection tests for rays missing
the surface is reduced, because the bounding volume is more tight when using many small bounding
volumes. In other words, rays will be culled away before the costly intersection test takes place. In
order to construct a bounding volume hierarchy from the subdivision, the leaf-nodes are sorted along
the axis with the greatest extent. The first half of the leaf-nodes becomes the first child node, and the
second half the second child. Methods for constructing a subdivision will now be discussed.
2 Or
22
any other primitive for which a very efficient intersection test exists
Adaptive subdivision
Algorithm 3 The Newton Root-Finder
Require: u, v
Ensure: λ, u, v
1: error prev ← ∞
2: uinitial ← u
3: vinitial ← v
4: for i = 1 to MAX_ITERATIONS do
~S ← EvaluateSurface(u, v)
5:
~
~R ← ~n1 · S + d1
6:
~n2 · ~S + d 2 7:
error ← ~R1 + ~R2 8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
if error < ε then
return λ
end if
if error > error prev then
return ∞
end if
error prev ← error
J ← ComputeJacobian
if singular(J)
then
u
u
(uinitial − u) · random([0, 1])
←
+ 0.1
v
v
(vinitial − v) · random([0, 1])
else
u
u
←
− J −1~R
v
v
end if
end for
return ∞
Figure 3.4: Example of a NURBS-curve with exemplary associated bounding volumes.
3.4.1
Recursive subdivision
One very simple method to subdivide a surface is to recursively split each surface-patch in the center
of the parametric domain and the sides of the domain, resulting in four sub-patches. These new
patches determine the knot-span used for evaluation.
Since there is no spatial relation between the control-points of the surface and its parametric
domain, sampling in such a uniform way will not necessarily result in a uniform distribution of the
23
3. NURBS R AY T RACING
sample points on the surface. For example, the subdivision could fail to represent highly curved
areas of a surface if the sampling density is too low. A simple solution is to increase the sampling
density, in order to refine such curved areas. However, this will unnecessarily increase the number
of polygons in flat areas of the surface. A better solution is to adaptively determine the sampling
density in different areas of the surface. This way, highly curved areas will automatically be sampled
more dense than less curved areas.
The uniform method is easily transformed into an adaptive version. Instead of using a fixed
recursion depth, extra criteria can be included to determine whether or not a (sub-)patch needs more
subdivision.
Normal based criteria
[Abe05] samples the normals ~ni of the sub-patch at eight different locations (Figure 3.5a) and then
uses the following criterion to stop the subdivision for that sub-patch [Abe05]:
7
∏~ni ·~ni+1 ≈ 1.
i=1
The dot-product between two nearly-identical vectors is approximately equal to one3 . In other
words, the surface is considered flat if the normals are all approximately equal. However, this method
is not always successful in capturing curved areas as Figure 3.5b indicates.
(a) The blue circles mark the positions where normals will be(b) The normals taken may satisfy the flatness criterion, but the
evaluated.
peak in the middle of the spline is not recognizes properly.
Figure 3.5: Flatness criterion based on the normals of a sub-patch.
Straightness based criteria
A more thorough approach is taken by [Pet94], however their method operates directly on the
control-point grid instead of the surface itself. A straightness-test is applied to every row and column of the control-point grid. The straightness-test return true if all points in the row (or column) are
co-linear. However, this test alone is not sufficient. If the surface is twisted, the rows and columns
could be straight, but the surface is nevertheless heavily curved. Therefore, a final check is made to
determine if the corners are co-planar.
To split the sub-patch, a refinement step is applied using the Oslo algorithm [CLR80, BBB87].
This algorithm modifies the knot-vector of the non-straight direction by adding p (or q) new knots
3 It
24
is assumed that |~ni | = 1.
Adaptive subdivision
at the parametric center of the sub-patch. Then, using this new knot-vector, the control-point grid
is updated by adding control-points corresponding to these new knots. Using such a refinement
operation, the shape of the surface remains unchanged. However, since p (or q) new knots are
inserted, the new control-points corresponding to these knots touch the surface. Thus, two separate
sub-patches are obtained along with their control-points (Figure 3.6).
Figure 3.6: Splitting a sub-patch into two sub-patches obtaining two control-point grids.
During the subdivision, two adjacent sub-patches with different subdivision depths introduce
cracks in the surface (Figure 3.7a) if the subdivision is used as a tessellation. In order to fix this,
the surface points corresponding to the corners of the crack are projected onto the straight line
(Figure 3.7b).
(a) Crack introduced by different subdi-(b) Fixed crack by projecting the corvision depths.
ners onto the straight line.
Figure 3.7: Procedure to fix a crack in the tessellation.
3.4.2
Direct subdivision
Yet another method for subdivision, particularly well suited for ray tracing, is described in [MCFS00],
in which the refinement scheme is based on the curvature of each patch. Each patch is refined according to a heuristic approximating the curvature of that patch.
The heuristic operates on the iso-curves4 and takes three measures into consideration: the maximum curvature of a curve-segment corresponding to a knot-span, the length of that curve-segment,
and a bound on the deviation of the curve-segment from its linear approximation. The measure for
the maximum curvature ensures that no multiple roots are found when finding an intersection between a ray and the surface (recall that this method is intended for ray tracing). The measure for the
length of a curve-segment makes sure that the initial-guess values are close enough, especially for
large patches. The first two measures result in the following heuristic value:
~
~
n1 = C1 × max[ti ,ti+1 ) {curvature(C(t))}
× arclength(C(t))
[ti ,ti+1 ) .
4 Iso-curves
are the curves on a surface with a fixed u value or a fixed v value.
25
3. NURBS R AY T RACING
The third measure determines the number of segments that needs to be generated and is approximated
by:
q
~
n2 = C2 × arclength(C(t))
[ti ,ti+1 ) .
Combining the previous two heuristics, the heuristic value that determines the number of knots n to
insert into the knot-span is determined by n1 × n2 :
3/2
~
~
n = C × max[ti ,ti+1 ) {curvature(C(t))}
× arclength(C(t))
[ti ,t
i+1 )
.
The C constant is a fineness constant and can be determined empirically.
Since the maximum curvature and the arc length are hard to compute, their values are heavily
estimated, which usually results in a too fine refinement rather that too coarse. However, the computation is much faster compared to the exact functions. Furthermore, the constant C can be used to
fine-tune the subdivision.
The final heuristic (after replacing many functions by their estimates) becomes:
n =C×
maxi−p+2≤ j≤i |~A j | × (ti+1 − ti )3/2
.
( 1 ∑ij=i−p+1 |~V j |)1/2
p
where
~ ~
~V j = p Pj − Pj−1 ,
t j+p − t j
~ ~
~A j = (p − 1) V j − V j−1 .
t j+p−1 − t j
The full derivation of the estimated maximum curvature and arc length functions can be found in
[MCFS00].
The actual subdivision takes place in two subsequent steps. In the first step, the heuristic is
applied to determine the number of knots that needs to be inserted into the non-empty knot-spans.
The number of knots that needs to be inserted into each knot-span of the u direction is determined by
applying the heuristic to each row of the control-point grid. Per knot-span, the maximum of all rows
for this knot-span is used as the number of new knots. This is repeated for the v direction, but now
for every column. After the numbers have been determined, the new knots are inserted uniformly
distributed over the knot-span. As a final step, each patch is converted into a Bézier-patch by setting
the multiplicity of the internal knots to p and q for the u and v parametric directions, respectively.
In the second step, the new control-point grid is computed from the new knot-vectors by using
a method similar to knot-insertion (Section 2.5). While it is not important for this step to be fast (in
the case of ray tracing it is only done once in a preprocessing phase), the actual implementation will
not be discussed here an can be found in [MCFS00].
3.5
Evaluation Schemes
When evaluating a point on a NURBS-curve or surface, it is important to note, that not every basisfunction needs to be computed. Since t lies in exactly one knot-span, only one zero-degree basisfunction is non-zero. Consequently, only two basis-functions of degree one are non-zero. In general,
only p + 1 basis-functions of degree p are non-zero. In the following scheme, these non-zero basisfunctions are emphasized:
26
Evaluation Schemes
Algorithm 4 EvaluateSurface
Require: spanu , spanv , Pi j , p, q,
u ∈ [uspanu , uspanu +1 ), v ∈ [vspanv , vspanv +1 ) .
Ensure: ~S, ~Su , ~Sv
1: Nu [0..p], Nderivu [0..p] ← EvaluateBasisFunctionsAndDerivativesu
2: Nv [0..q], Nderivv [0..q] ← EvaluateBasisFunctionsAndDerivativesv
3: ~
Sh = (~S, Sw ) ← ~0
~u h = (S~u , Su,w ) ← ~0
4: S
h
S~v = (S~v , Sv,w ) ← ~0
for i = spanu − p to spanu do
for j = spanv − q to spanv do
~Sh ← ~Sh + ~Ph Nu [i − (spanu − p)]Nv [ j − (spanv − q)]
ij
h
h
~
~
9:
Su ← Su + ~Pihj Nderivu [i − (spanu − p)]Nv [ j − (spanv − q)]
h
h
10:
S~v ← S~v + ~Pihj Nu [i − (spanu − p)]Nderivv [ j − (spanv − q)]
11:
end for
12: end for
13: ~
S ← Sw−1~Sh
−1 )S−1
~u ← (S~u − ~SSu,w
14: S
w
−1 )S−1
~v ← (S~v − ~SSv,w
15: S
w
16: return ~
S, ~Su , ~Sv
5:
6:
7:
8:
p
p
p
p
p
· · · Ni−p (t) · · · Ni−3 (t) Ni−2 (t) Ni−1 (t) Ni (t)
..
.
2 (t) · · · N 2 (t) N2 (t) N2 (t) N2 (t)
· · · Ni−p
i−3
i−2
i−1
i
1 (t) · · · N 1 (t) N 1 (t) N1 (t) N1 (t)
· · · Ni−p
i−3
i−2
i−1
i
0 (t) · · · N 0 (t) N 0 (t) N 0 (t) N0 (t)
· · · Ni−p
i−3
i−2
i−1
i
p
p
Ni+1 (t) Ni+2 (t) · · ·
2 (t) N 2 (t) · · ·
Ni+1
i+2
1 (t) N 1 (t) · · ·
Ni+1
i+2
0 (t) N 0 (t) · · ·
Ni+1
i+2
For efficient evaluation, this is a very important fact: instead of multiplying and summing up all n
control-points, actually only p + 1 control-points are involved in the computation. Thus Equation 2.2
becomes:
a
~ h (t)[t ,t ) =
C
a a+1
∑
~Pih Nip (t)
i=a−p
and for a surface, becomes:
b
~Sh (u, v)[u ,u ),[v ,v ) =
a a+1
b b+1
∑
"
a
∑
#
~Pihj Nip (u) N qj (v)
j=b−q i=a−p
Basis-function cache Algorithm 4 simultaneously evaluates a point on a NURBS-surface along
with its partial derivatives, by first computing the basis-functions in both parametric directions and
storing them in a basis-function cache [AGM06]. Then, the computed basis-functions are multiplied
with the corresponding control-points and added to the result.
Directly evaluating the basis-functions using Equation 2.4 is not very efficient. At first, many
higher-degree basis-functions depend on the same lower-degree basis-function, resulting in repeated
27
3. NURBS R AY T RACING
Algorithm 5 EvaluateBasisFunctionPowerBasisForm
Require: t, p,
* P ← αp
* D←0
for i = p − 1 to 0
* D ← D∗t +P
* P ← P ∗ t + αi
endfor
return (P, D)
computations for these lower-degree basis-functions. Secondly, many computations of the basisfunctions are actually unnecessary, since they depend on basis-functions whose active domain (where
the basis-function is non-zero), does not contain the evaluation parameter value and are therefore
zero for that value. Finally, a recursive implementation of this algorithm, when compiled, is not very
efficient, since the basis-functions are evaluated many times and thus many function calls are issued,
which cannot be in-lined by the compiler, resulting in poor performance.
3.5.1
Power-basis Form Evaluation
One possibility to avoid the recursion in Equation 2.4 is to convert the recursive basis-functions into
power-basis form as in [Abe05].
The power-basis form of a basis-function is defined as:
p
N(t) = ∑ αit i
i=0
Using Horner’s scheme [PTVF97] the polynomial and its derivative can be evaluated very efficiently with linear time complexity:
p
N(t) = ∑ αit i
i=0
= α0t 0 + α1t 1 + · · · + α p−1t p−1 + α pt p
= t(· · ·t(t α p + α p−1 ) · · · + α1 ) + α0
| {z }
linear in p
For each knot-span, a set of basis-functions in power-basis form is evaluated as well as their
derivatives. The power-basis coefficients αi are obtained in a preprocessing step by a polynomial
expansion of Equation 2.4. For full details I refer to [Abe05].
Algorithm 5 evaluates the basis-function and its derivative simultaneously using only multiplyadd5 operations.
Although the power-basis form enables a very efficient evaluation of a basis-function and its
derivative, it does require some preprocessing. Additionally, there is a lot of redundancy in the
generated coefficients, since a polynomial is maintained for each knot-span for each basis-function,
while these are derived from the knot-vector which uses much less memory. Finally, a rather bad
property of polynomials in power-basis form is that the evaluation is numerically unstable if the
coefficients vary greatly in magnitude [FR87].
5 Some hardware architectures (e.g. GPUs) are able to perform a multiply operation followed by an add operation in a
single combined multiply-add instruction.
28
Evaluation Schemes
3.5.2
Direct Evaluation
Although there are efficient iterative algorithms available for the original Cox-de Boor recurrence
Equation 2.4, their complexity is still quadratic in the degree of the curve as opposed to the linear
complexity of the power-basis form method. However, they are numerically stable, which is a very
important property for the numerical root-finder (Section 3.3.1).
Observing the computation of all p-degree basis-functions (Equation 2.4) for t ∈ [ti ,ti+1 ), it
becomes clear there is a lot of redundancy in the computation of them:
t − ti−p
ti+1 − t
p−1
p−1
p
Ni−p (t) +
N
(t)
(3.10)
Ni−p (t) =
ti − ti−p
ti+1 − ti−p+1 i−p+1
t − ti−p+1
ti+2 − t
p
p−1
p−1
Ni−p+1 (t) =
Ni−p+1 (t) +
N
(t)
(3.11)
ti+1 − ti−p+1
ti+2 − ti−p+2 i−p+2
..
.
ti+p − t
t − ti−1
p
p−1
p−1
Ni−1 (t) =
N (t) +
N (t)
(3.12)
ti+p−1 − ti−1 i−1
ti+p − ti i
ti+p+1 − t
t − ti
p−1
p−1
p
(3.13)
Ni (t) +
N (t)
Ni (t) =
ti+p − ti
ti+p+1 − ti+1 i+1
p
p
The last term of basis-function N j (t) and first term of basis-function N j+1 (t) contain the same factor:
p−1
Qj =
N j+1 (t)
t j+p+1 − t j+1
Note that for the first term of Equation 3.10 and the last term of Equation 3.13 this factor is zero,
p−1
p−1
since Ni−p (t) = Ni+1 (t) = 0 for t ∈ [ti ,ti+1 ).
Now, let:
α j = t − ti+1− j
β j = ti+ j − t
Equations 3.10-3.13 are then:
"
p
Ni−p (t) = α p+1
p−1
Ni−p (t)
#
"
p−1
Ni−p+1 (t)
#
+ β1
α p+1 + β0
α p + β1
" p−1
#
" p−1
#
Ni−p+1 (t)
Ni−p+2 (t)
p
Ni−p+1 (t) = α p
+ β2
α p + β1
α p−1 + β2
..
.
#
"
#
p−1
p−1
Ni−1 (t)
Ni (t)
+ βp
α2 + β p−1
α1 + β p
"
#
" p−1
#
p−1
Ni+1 (t)
Ni (t)
p
Ni (t) = α1
+ β p+1
α1 + β p
α0 + β p+1
"
p
Ni−1 (t) = α2
Algorithm 6 (named “Inverted Triangle”-method in [PT97]) simultaneously evaluates the basisfunctions and their derivatives by reusing the previously computed values. Since terms resulting in
a division by zero are not computed anymore, the algorithm requires no special treatment of such
cases.
29
3. NURBS R AY T RACING
Algorithm 6 EvaluateBasisFunctionsDirect
Require: i, t ∈ [ti ,ti+1 ), p.
Ensure: N[0..p], D[0..p]
1: N[0] ← 1
2: for j = 1 to p do
3:
α j ← t − ti+1− j , β j ← ti+ j − t
4:
RN ← 0, RD ← 0
5:
for k = 0 to j − 1 do
6:
Q ← α N[k]
j−k +βk+1
7:
N[k] ← RN + βk+1 Q
8:
RN ← α j−k Q
9:
D[k] ← p(RD − Q)
10:
RD ← Q
11:
end for
12:
N[ j] ← RN
13:
D[ j] ← pRD
14: end for
3.5.3
Division-free Evaluation
The iterative method described in Section 3.5.2 does not require preprocessing, and the additional
storage is even zero (excluding the knot-vector, which is always needed). However, this method
contains division-operations, which are costly compared to basic operations such as multiply and
addition. Another very fast, yet simple and memory-efficient, iterative approach is presented in
[AGM06], for evaluating NURBS-curves and surfaces. Their method requires very little preprocessing, and the data resulting from it takes up only but a small amount of memory.
By carefully investigating the Cox de-Boor recurrence from Equation 2.4, one can see that a
lot of constants are involved. By rewriting the equation, the constant part of the equation can be
separated out:
ti+p − t
t − ti
p−1
p−1
N (t) +
N (t)
ti+p−1 − ti i
ti+p − ti+1 i+1
1
−1
p−1
p−1
(t − ti ) Ni (t) +
(t − ti+p ) Ni+1 (t)
=
ti+p−1 − ti
ti+p − ti+1
p
Ni (t) =
p−1
= [a (t − ti )] Ni
p−1
= [at + c] Ni
p−1
(t) + [b (t − ti+p )] Ni+1 (t)
p−1
(t) + [bt + d] Ni+1 (t).
The resulting equation was rewritten in such a way, that evaluation of a basis-function requires
only three multiply-add instructions and one multiply instruction, given that the depending basisfunctions of lower degree are known:
p−1
[at + c] N
| {z } i
multiply-add
p−1
(t) + [bt + d] Ni+1 (t)
| {z }
multiply-add
|
|
30
{z
multiply-add
{z
multiply
}
}
Evaluation Schemes
Where the constants can be precomputed in a preprocessing step:
p
ai =
p
1
ti+p−1 − ti
p
p
bi =
p
ci = −ai ti
−1
ti+p − ti+1
p
di = −bi ti+p
A slightly different approach is taken for computing all required basis-functions. Figure 3.8
shows the dependencies and evaluation order of the basis-functions. All basis-functions of degree
higher than zero depend on two lower-degree basis-functions. Furthermore, the outer basis-functions
depend on only one basis-function.
(a)
(b)
Figure 3.8: Evaluating the NURBS basis-functions.
Algorithm 7 simultaneously evaluates the basis-functions and their derivatives [AGM06].
Algorithm 7 EvaluateBasisFunctionsDivisionFree
Require: i, t ∈ [ti ,ti+1 ), p.
Ensure: N[0..p], D[0..p]
1: N[0] ← 1
2: for j = 1 to p do
j
3:
D[ j] ← p(ai N[ j − 1])
j
j
4:
N[ j] ← (ai t + ci )N[ j − 1]
5:
for k = j − 1 down to 1 do
j
j
6:
D[k] ← p(ai−( j−k) N[k] − bi−( j−k) N[k + 1])
j
j
j
+(bi−( j−k)t + di−( j−k) )N[k + 1]
end for
j
D[0] ← p(−ai− j N[ j])
8:
9:
10:
11:
j
N[k] ← (ai−( j−k)t + ci−( j−k) )N[k]
7:
j
j
N[0] ← (ai− j t + ci− j )N[ j]
end for
3.5.4
De Boor’s Algorithm
De Boor’s algorithm takes a very different approach in evaluating the points on a NURBS-curve
or surface. Instead of first computing the basis-functions, and using them in a second stage by
multiplying them with the control-points, it operates directly on the control-points.
31
3. NURBS R AY T RACING
Geometrically, it is identical to repeatedly inserting knots (Section 2.5) until the knot has a
multiplicity p. The curve-point is then equal to the control-point (after refinement) interpolated
by the curve at the knot. However, instead of computing each time all new control-points of the
refinement, the algorithm limits itself to a subset of the refinement.
Algorithm 8 shows the De Boor’s Algorithm for evaluating a NURBS-curve at t.
Algorithm 8 De Boor’s Algorithm
Require: t ∈ [ti ,ti+1 ), p.
~
Ensure: C(t)
1: if t 6= ti then
2:
s←0
3: else
4:
s ← multiplicity(ti )
5: end if
6: h ← p − s
7: for j = 1 to h do
8:
for k = i − p + j to k − s do
j
9:
αk ← tk+p−t−tj+1k −tk
~P j ← (1 − α j )~P j−1 + α j ~P j−1
k
k k−1
k k
end for
12: end for
p−s
13: return ~
Pi−s
10:
11:
To extend the algorithm to a surface-evaluation, observe the following (from Equation 2.8):
"
#
m−1 n−1
p
h
h
~S (u, v) = ∑ ∑ ~Pi j N (u) N q (v).
i
j=0
j
i=0
For a fixed j this becomes:
n−1
~qhj (u) =
∑ ~Pihj Nip (u).
i=0
Therefore, evaluation of ~Sh (u, v) can be done by first applying De Boor’s Algorithm q times on the
iso-v-curves, and then applying it one more time to the curve defined by:
m−1
~Sh (u, v) =
∑ ~qhj (u)Nip (v).
j=0
This results in a numerically very stable algorithm for computing NURBS-surface points. However,
it does require the temporary storage of 2q surface-points.
3.6
Overview
In summary, NURBS-surfaces can be ray traced directly using a modified version of the basic ray
tracing algorithm by including the following steps:
• In a preprocessing step:
1. Subdivide the surface to obtain better initial-guess values for the root-finder, and to reduce the number of intersection tests (Section 3.4).
32
Discussion
2. Construct a bounding volume hierarchy containing these initial-guess values from the
subdivision from the previous step. After the bounding volume hierarchy is generated,
the subdivision can be discarded (Section 3.1.2).
• During ray tracing:
1. Traverse the bounding volume hierarchy using a packet-based BVH traversal scheme
(Section 3.2).
2. When reaching a leaf-node, use root-finding to obtain the intersection-point (Section 3.3.1).
3. From all obtained intersection-points, take the closest w.r.t. the ray, and use that intersectionpoint for further shading computations, and as a spawning point for secondary rays.
3.7
Discussion
The direct ray tracing of NURBS-surfaces poses an exciting challenge. Ray tracing itself is already
a very expensive algorithm, combining it with NURBS-surface support will make it only more complex. However, the many advantages over standard rasterization and tessellation-based ray tracing
are worthwhile to investigate an efficient implementation. At first, the reduced pre-processing time
is a huge improvement, making interactive prototyping a lot easier. Secondly, as a consequence of
using direct ray tracing of NURBS-surfaces, the required data, including preprocessed data, will be
very compact, making it possible to ray trace very geometrically complex surfaces. Thirdly, exact representation makes it possible to zoom-in while preserving the model’s smoothness: never
will a linear approximation become visible (as opposed to the rasterization-based method and the
tessellation-based ray tracing method). Finally, the benefits of ray tracing alone are the accurate
optical phenomena, such as shadows, reflections and refractions.
In order to improve the performance of the ray tracer, efficient algorithms need to be employed
for finding the intersections. The Newton-Rhapson method proves to be a very good candidate for
this, due to its quadratic convergence rate and low memory requirements. By subdividing the surface
in a preprocessing step, not only the surface is better approximated by the corresponding bounding
volume hierarchy, but the smaller sub-patches also provide better initial-guess values.
For evaluation of the surface-points and their partial-derivatives, multiple algorithms are available. While the power-basis form provides a very simple method for evaluation, the memorybandwidth required for it is rather high. Also, its stability decreases for increasing degrees. Whereas
the direct form is more memory-friendly, as it does not rely on any preprocessed data. However, it
performs divisions, which are very costly. The division-free method on the other hand is relatively
memory-friendly and does not perform divisions at all, and is supposedly the fastest yet available
according to the literature [AGM06]. The last method, the de Boor’s algorithm is definitely not
memory-friendly, as it requires a huge amount of registers. However, the method is very robust.
Clearly, each method has its own advantages and disadvantages. However, due to the low memoryrequirements of the direct and division-free methods, they are worthwhile for investigation on GPU.
33
Chapter 4
NURBS Ray Tracing on the GPU
Recently, graphical processing units (GPUs), originally only meant for rasterization-based graphics rendering, are being “misused” for other, general-purpose computations. With the increasing
programmability of commodity GPUs, these chips are capable of performing more than the specific
graphics computations for which they were originally designed. They are now capable coprocessors,
and their high speed makes them useful for a variety of applications [OLG+ 07]. As of now, NVIDIA
GPUs are being used to accelerate computations for computational fluid dynamics, finance, physics,
life sciences, signal processing, and many other non-graphics areas.
However, due to the limited memory of GPUs and streaming architecture, some extra challenges
need to be tackled, when trying to exploit the raw processing power of modern GPUs for ray tracing.
This chapter will discuss recent developments in GPU Ray Tracing, and even more recent, NURBS
Ray Tracing on the GPU.
4.1
GPU Ray Tracing
Due to the parallel nature of the ray tracing algorithm (Section 1.2), researchers have long been
trying to exploit the huge performance of GPUs. The first steps were taken with The Ray Engine
[CHH02]. The ray tracer used the programmable shader pipeline of the GPU to compute all rayprimitive intersections. While the GPU was able to quickly compute the intersections, streaming
the data to the GPU quickly became the bottleneck. This bottleneck in turn was avoided by moving
all computations to the GPU [PBMH05]. However, this implementation required multiple rendering
passes to ray trace a scene. One pass computed the eye rays, while a second pass traverses a uniform
grid, a third pass computes the intersections, and the fourth pass shades the result. This process is
shown schematically in Figure 4.1. Although the memory transfers were heavily decreased, they still
were not able to outperform CPU-based ray tracers. Due to limited shader size and no branching
support, many CPU-controlled rendering passes were necessary to traverse, intersect and shade the
rays.
4.1.1
GPU Scene Traversal
kd-Tree Traversal
Also the implementation of kd-tree traversal has been researched. Since a stack is rather difficult
to implement on a GPU, several methods have been devised to overcome this problem. [FS05] presented two methods for stackless traversal of a kd-tree on GPU, namely kd-restart and kd-backtrack
[FS05]. Although their methods are better suited for the GPU, the high number of redundant traversal
steps leads to relative low performance. By adding a short stack, [HSHH07] improved the kd-restart
35
4. NURBS R AY T RACING ON THE GPU
Figure 4.1: Multiple stages in the ray tracer of [PBMH05].
method [HSHH07]. They achieved a performance of 15.2M rays/s for the Conference scene (appr.
280k triangles). [PGSS07] presented a CUDA-based stackless packet traversal algorithm by using
ropes, pointers to adjacent nodes [PGSS07]. Their traversal algorithm does not need to be restarted
and is able to instantly continue the traversal starting from the corresponding node, resulting in
a performance of 16.7M rays/s. However, their implementation requires six ropes for each node,
increasing the memory requirements by a factor of 4, limiting the support to only medium-sized
scenes. Additionally, even though optimized for the GPU architecture, it can still not utilize the full
power of modern GPUs.
4.1.2
Stackless BVH Traversal
Although the kd-tree allows for fast scene traversal, the memory requirements are relatively high.
Since the GPU has limited memory, the size of supported scenes for kd-trees is limited. However,
BVHs generally require only 25% to 33% of memory compared to kd-trees, and compared to the
stackless kd-tree traversal even 10% [PGSS07].
[TS05] presented a stackless traversal algorithm for the BVH which allows for efficient GPU
implementations [TS05]. By storing the BVH tree in depth-first order, the tree is traversed in fixedorder. Therefore, no explicit reference needs to be kept for child-nodes. However, a ray could miss
a node, and traversal needs to continue starting from another part of the tree. By including skippointers in the nodes, traversal can continue instantly from these other nodes (Figure 4.2). Although
they outperformed both regular grids and the kd-restart and kd-backtrack [FS05] variants for kdtrees, their method is not as fast as the stackless kd-tree traversal [PGSS07].
4.1.3
Shared-Stack BVH Traversal
Although the BVH implementation of [TS05] does not depend on a stack, it uses a fixed-order
traversal. The disadvantage of this is that many nodes, as well as primitives, will be tested for
36
Hybrid Ray Tracing
Figure 4.2: Stackless BVH traversal encoding example.
intersections even if they fall behind other primitives that will be traversed later. This leads to
many redundant tests. [GPSS07] use an ordered, view dependent traversal, thus heavily improving
performance for most scenes. However, since the traversal is ordered, a stack needs to be maintained.
By tracing the rays in packets, the cost for this stack can be reduced, by amortizing it over the whole
packet. By targeting their ray tracer at CUDA-enabled GPUs, several features can be exploited to
implement this shared stack. The shared memory space of the GPU’s multiprocessors is used to
keep this stack. Access to this data area is as fast as accessing the local registers on the chip.
Their algorithm begins by traversing the hierarchy with the packet. Only one node is processed at
a time. If the node is a leaf, the rays simply compute the nearest intersection with the geometry in it.
If the processed node is not a leaf, the two children are loaded. The rays then intersect both children,
to determine the traversal order based on the first intersected child. If the front-most child happens
to lie behind an already intersected primitive, the child is considered as not being intersected. The
next node is then collectively selected as the child-node which is front-most for the gross part of the
rays. If any ray intersects the other child first, that child is “scheduled” by pushing it on the stack. If
both children were missed, or if a leaf was processed, the next node is popped from the stack and its
children are traversed. The algorithm terminates, if the stack is empty.
The results show that the BVH-based GPU ray tracer is competing with the stackless kd-tree ray
tracer [PGSS07] with a performance of 16M rays/s for the Conference scene. Using a preprocessing
step, a special ray/triangle intersection test can be performed, which results in a performance increase of 20%. Using this optimization, their ray tracer even reaches 19M rays/s. Although kd-trees
have long been regarded as the preferred acceleration datastructure for ray tracing, their novel BVH
traversal algorithm is easier to implement and uses less live registers, resulting in a higher utilization
(63% compared to 33% for [PGSS07]). Using their implementation, they were even able to ray
trace the 12.7 million triangle POWER PLANT scene at 1024 × 1024 image resolution with 3 fps,
including shading and shadows. The BVH required only 230 MB, and therefore fits easily in GPU
memory.
4.2
Hybrid Ray Tracing
Standard ray tracing uses an acceleration datastructure to reduce the complexity for a ray-scene
intersection test from O(n) to O(log n), where n is number of primitives. While this datastructure
reduces the number of intersection tests dramatically, still a significant amount of time is spent for
the traversal of this datastructure.
Another approach is hybrid ray tracing, where the GPU is used to rasterize the scene to obtain
the intersections of the primary rays, after which this ray casted scene is further processed by the
standard ray tracing algorithm (implemented on CPU or GPU), to include secondary effects such as
reflections, refractions, shadows, etc. (Figure 4.3). Additionally, GPU shadow-maps can be used to
avoid the intersection tests for the shadow-rays [BBDF05].
Interestingly, hybrid ray tracing is more beneficial to NURBS scenes than to triangle-based
37
4. NURBS R AY T RACING ON THE GPU
(a) Rasterization phase of the hybrid algorithm.
(b) Ray tracing phase of the hybrid algorithm.
Figure 4.3: Hybrid Ray Tracing phases.
scenes. Since the NURBS intersection test is extremely expensive compared to simple triangle
intersections, every unnecessary intersection test avoided is worth much more compared to classical triangle tests. The following subsections discuss some hybrid techniques which accelerate the
primary ray intersection stage of a NURBS ray tracer.
4.2.1
Extended Graphics Pipeline
[PSS+ 06] propose a conceptual extension of the standard triangle-based graphics pipeline by an
additional intersection stage. They first generate a very rough approximation of the surface by subdividing the NURBS-surface patch. The convex hulls of this subdivision are then rendered using
standard rasterization. In the fragment shader they include an intersection stage to compute the
exact intersection values between the rays and the surface, after which the fragments are shaded
[PSS+ 06]. Figure 4.4 shows a schematic overview of the extended graphics pipeline.
In order to reduce the number of ray/NURBS intersection tests, they employ some kind of early
ray termination, similar to the early-z test. Their method requires the primitives to be sorted front-toback, before being uploaded to the GPU. Before computing the ray/NURBS intersection, the depth
value of the convex hull coming from the rasterizer is compared against the current value in the
depth-buffer. If the convex hull lies behind the already computed pixel, the corresponding surface
will also lie behind it, therefore the fragment/ray will be discarded and a costly intersection test can
be skipped. Otherwise, the exact depth is obtained from the intersection, and the depth-buffer is
updated accordingly.
Usually, the early-z test can be employed for planar primitives (such as triangles etc.), which
heavily increases performance. This test compares the depth value coming from the rasterizer with
the value in the depth-buffer, so that the entire fragment shader stage can be skipped if this fragment
is behind another. However, the exact intersection for the NURBS-surface is determined during the
fragment shader stage, consequently, the precise depth value can only be obtained using the fragment
shader. Therefore, the fast early-z test cannot be employed in this case. However, it is implemented
manually in the fragment shader to prevent the costly intersection tests. Test results show that this
manual implementation does not decrease performance that much compared to a hardware early-z
implementation [PSS+ 06]. Therefore, the benefit for the early ray termination is still very high.
To obtain the intersection between the ray and the surface, Newton’s Iteration root finding
method (Section 3.3.1) is used in combination with de Boor’s method (Section 3.5.4). Three different techniques are used to obtain an initial guess for the (u, v)-values.
The first technique follows the approach of [MCFS00], by using multiple bounding volumes
38
Hybrid Ray Tracing
Figure 4.4: Overview of the algorithm stages and their relation to stages in the extended graphics
pipeline.
per surface-patch. However, instead of using axis-aligned bounding boxes (AABBs), the bounding
volume is the convex hull of a sub-patch itself and contains as initial-guess value the midpoint in the
parameter range of the convex hull. An additional advantage compared to the AABBs, is that the
smaller convex hulls approximate the surface better, so less rays will miss the surface.
For the second technique, called uv-texturing, the patch is further subdivided as in the previous
method. But instead of using the midpoint as initial-guess, the parameter values correspond to the
vertices of the convex hull, which are interpolated to obtain a closer initial guess. This method can
be further optimized into a view-dependent method (technique three), by using the vertex shader to
compute the intersection of the ray and the vertex to obtain exact (u, v)-values for the vertices, which
again will be interpolated afterwards, resulting in an even closer initial guess. The test results show
that the number of iterations is reduced when using the view-dependent variant. However, they do
not provide a comparison with the view-independent variant with respect to speed.
Figure 4.5 and Figure 4.6 compare the number of required iterations for the intersection finder
to converge. As can be seen, the uv-texturing method converges very fast, whereas the midpoint
method requires several additional iterations. Figure 4.7 compares the view-independent method
with the view-dependent method. It can be seen, that the view-dependent method requires less
iterations in order to find the intersection.
Furthermore, using an adaptive subdivision, a coarser mesh can be generated globally, while
locally, in very curved areas, the mesh can be subdivided a bit further. This will automatically
determine the correct subdivision depth, which results in a maximum performance for the rasterizer.
Additionally, since curved areas are subdivided further, less iterations are required, increasing the
performance even more.
Their implementation is able to rasterize the bi-cubic NURBS-teapot consisting of 32 patches
each uniformly subdivided 4×4 times (12698 triangles for the convex hulls), with a frame rate of 36
frames per second at a resolution of 1280×1024.
While they are able to quickly rasterize NURBS-surfaces, their method does not include sec39
4. NURBS R AY T RACING ON THE GPU
ondary effects, such as shadows, reflections, refractions, etc. Furthermore, they are not able to fully
exploit the coherence among rays, since the rays are processed independently in parallel using the
fragment shaders. Using CUDA, this coherence could be exploited better, and a full-fledged ray
tracer could be built. However, this is not the goal of the authors, since they proposed a conceptual
extension to the standard graphics pipeline, to support the NURBS surface as a primitive.
(a)
(b)
(c)
(d)
Figure 4.5: uv-texturing using midpoint of parameter range (uniform subdivision: 2×2). Figure 4.5a
shows the corresponding uv-texture. Figure 4.5b to Figure 4.5d show the result for up to two, three,
and four iterations, respectively.
(a)
(b)
(c)
(d)
Figure 4.6: uv-texturing using control point mapping (uniform subdivision: 2 × 2). Figure 4.6a
shows the corresponding uv-texture. Figure 4.6b to Figure 4.6d show the result for up to two, three,
and four iterations, respectively.
(a) Surface
(b) Number of iterations for
view-independent
(c) Number of iterations for
view-dependent
(d) Difference
Figure 4.7: Figure 4.7a, Figure 4.7b view-independent uv-texturing vs. Figure 4.7a, Figure 4.7c
view-dependent uv-texturing (max. iterations: 10, subdivision: uniform, 4 × 4). Figure 4.7d is the
difference between the initial values of both methods.
40
Hybrid Ray Tracing
4.2.2
GPU/CPU Hybrid
As in the method of [PSS+ 06] in Section 4.2.1, [ABS08] use a hybrid approach by rasterizing a
coarse mesh using the GPU and then computing the exact intersections in a second stage. However,
whereas [PSS+ 06] use the convex hull of a subdivided NURBS-patch as input for the rasterization
phase, the subdivision itself is used instead to obtain a more tight approximation of the surface. Also,
the intersection stage is performed on the CPU as opposed to the GPU requiring costly GPU-CPU
memory transfers. During the intersection stage, they employ the fast NURBS evaluation algorithm
(Section 3.5.3), together with the Newton Iteration to obtain the exact intersection [AGM06].
Two variants are employed in their method. The first one, called id-processing, uses only the
id of the triangle/surface for further processing. However, since no (u, v) values are available, an
additional function call is required to obtain those values. The second method, called uv-processing,
uses the vertices’ (u, v) values. These values are interpolated in turn by the rasterizer to obtain
an initial guess for the Newton Iteration. However, since an additional buffer is needed to hold
the interpolated (u, v) values, more memory needs to be transferred from GPU-memory to CPUmemory. Comparing this variant to the view-dependent uv-texturing-approach [PSS+ 06], there are
several advantages. Since the vertices of the subdivided mesh lie exactly on the surface, the precise
(u, v) values are already known, whereas [PSS+ 06] require additional intersection tests using the
vertex shader to obtain these values.
Although using the subdivision directly fits the NURBS-surface better than using the convex hull
as in [PSS+ 06], their method suffers from some artifacts. Rays that intersect the surface, but miss
the tessellated silhouette, will not appear in the rasterized output, whereas standard ray tracing does
include them (Figure 4.8a). In order to counter this artifact, they include a test in the intersection
stage, to determine if a ray/pixel needs to traverse the entire scene, or it can depend on the hit
reported by the rasterizer. Due to the mentioned artifact, every background pixel in the rasterization
output therefore needs to be ray traced using a packet-based BVH ray tracer, in order to produce a
correct result. While many background-pixels will actually be rays that do not intersect the surface,
this check will incur some overhead. However, this overhead is relatively low, since no (or very few)
NURBS intersection tests needs to be performed.
Another artifact that may occur is when the rasterized output contains a hit where the ray traced
output does not, or hits another surface (Figure 4.8b). Therefore, an additional check, after the
intersection test is used, to determine if the intersection test succeeded. If not, the standard ray
tracing algorithm is used as well.
Although their artifact-handling fixes the majority of incorrect rasterized silhouettes, it is still
incapable of correctly ray tracing (self-)intersecting surfaces (Figure 4.9a). Luckily, this artifact
is avoided when tessellating not too coarsely. However, not mentioned by their paper, since the
tessellation is an approximation, the surface at the silhouette can be missed by the rasterizer. Therefore, if another surface is behind the missed surface, additional artifacts will occur, resulting in a
tessellated-looking silhouette (Figure 4.9b).
The test results show that using the hybrid approach, 20-70% of the costly NURBS-intersection
tests can be avoided. Normally a ray would intersect multiple surfaces, but using the z-buffer the
number of surfaces is reduced to only one (except for the artifact-handling). Interestingly, although
uv-processing starts with a better initial guess, the cost for obtaining these guesses is very high since
an additional data buffer needs to be transferred. Therefore, their id-processing variant outperforms
the uv-processing variant.
Their implementation is able to ray cast the bi-cubic NURBS-teapot consisting of 32 patches subdivided over 12698 triangles, with a frame rate of 8.0 frames per second at a resolution of 512×512.
Using a dual 3.0GHz quad-core processor, they reach 25.5 frames per second for uv-processing, and
41.7 frames per second for id-processing.
Although only primary rays are traced, this implementation is easily extended to a full-fledged
41
4. NURBS R AY T RACING ON THE GPU
(a) A primary ray missing the tessellation, but hitting the surface.
(b) A primary ray r hitting a triangle ts from a tessellated surface while missing the original (parent) surface s.
Figure 4.8: Artifacts which are handled correctly.
ray tracer, by simply shooting more rays in the intersection stage. However, these secondary rays
will not be traced as efficiently as the primary rays.
4.2.3
Comparison
For the teapot scene, [PSS+ 06] reach 47M rays/s, whereas [ABS08] reach 11M rays/s (id-processing,
using 8 threads). However, this comparison is not fair, since different hardware is used in both implementations as well as a different approach. Furthermore, the scenes are very different actually. The
subdivision is performed differently, and another viewpoint is chosen for the camera. Nevertheless,
the features can be compared. Whereas [PSS+ 06] rasterize the convex hull in order to produce an
artifact-free result, [ABS08] rasterize the tessellation of the subdivision, introducing some possible
artifacts. However, a convex hull requires more primitives to process, slowing down the rasterization
stage, on the other hand, this is not the bottleneck. Using a tessellation also approximates the surface better, but more important, it provides more accurate initial-guess values. Using the convex hull,
the best initial-guess values one can get are obtained by using view-dependent uv-texturing. This
requires additional intersection tests during the vertex shader stage, slowing down the ray tracing
process. The tessellated method implicitly uses view-dependent uv-texturing, since the vertices of
the triangles lie exactly on the surface. The tessellation method also guarantees only one intersection
test, except for some cases when an artifact is detected, where additional standard ray tracing is required. Using the convex hull, an intersection could be in front of the current front-most intersection
according to the depth-buffer. Therefore, several intersection tests can be needed to obtain the correct intersected surface. However, this consequence can be minimized by first sorting the primitives
front-to-back. Furthermore, the method by [PSS+ 06] is fully implemented using the programmable
42
Discussion
(a) A packet of rays r1..4 intersecting the wrong surface t j . The
altered shape tis of the surface s causes objects in the shaded
area to be drawn instead of culled and vice versa (if rays origin
in the opposite direction)
(b) A primary ray hitting the front surface, but missing the tessellation. In the back the ray does hit the tessellation, however,
this will result in a wrong hit.
Figure 4.9: Artifacts which cannot be handled correctly.
shader pipeline. Therefore, due to the parallel nature of the fragment processing units, coherence of
initial values for the Newton Iteration between neighboring pixels/rays is difficult to exploit, only the
caches can be used to exploit localness in memory fetches. The method of [ABS08], traces rays in
packets, and therefore can profit from the coherence. Table 4.1 shows a comparison of the features
for both hybrid methods.
4.3
Discussion
For ray tracing NURBS-surfaces, the GPU BVH ray tracer in Section 4.1.3 can be employed. It
allows an efficient traversal of the bounding volume hierarchy (derived from the subdivision of the
NURBS-surface) by including a shared-stack per ray-packet. Together with the Ray-Patch intersection routine (Section 3.3.1), and the evaluation schemes in Section 3.5, an efficient implementation
should be possible.
Hybrid Ray Tracing is an interesting method for accelerating the primary intersection stage,
which avoids the entire traversal stage. Although ray tracing will eventually outperform rasterization
as the complexity increases, this is usually not the case for ray tracing NURBS-surfaces, as the
43
4. NURBS R AY T RACING ON THE GPU
Feature
Artifact-free
Initial Mesh
Intersection Tests/Ray
Early ray termination
uv-Texturing
View-dependent
GPU/CPU Intersection stage
coherence exploitation
[PSS+ 06]
Yes
Convex Hull
≥1
Yes (manually)
Yes
Yes (vertex shader)
GPU
Little (through caches)
[ABS08]
No (rare)
Tessellation
1 (non-missed intersections)
Yes
Yes
Yes
CPU
Yes (through packets)
Table 4.1: Comparison of features for both hybrid methods.
rasterized mesh is only a rough approximation of the NURBS-surface, therefore, the complexity can
be kept modest, resulting in a fast rasterization. But more important, since many triangles are being
culled by the rasterization pipeline, through frustum culling, early-z culling, viewport culling, etc.,
the average number of intersection tests is reduced to only a few per ray. Most of the time requiring
just only one intersection test, as most of the other triangles are culled away.
Two different approaches are employed for hybrid ray tracing. [PSS+ 06] implemented the entire
ray tracer using vertex and fragment shaders, whereas [ABS08] used the CPU for computing the
exact intersections. For the former method, the intersection tests take place during rasterization
by using the fragment shader for computing the intersections. Since all fragments are processed
independently by the GPU, little attention is paid to coherence among the rays, except for the caches.
The main bottleneck in the latter is the expensive GPU-CPU memory transfer, especially for the
u/v processing variant, since it requires the transfer of an additional buffer for the (u, v) values.
Furthermore, the resulting (u, v) buffers use RGBA data, therefore adding some amount of overhead.
However, recent GPUs support integer textures, which will heavily decrease the required bandwidth.
As mentioned in their paper [ABS08], implementing the intersection stage on GPU, all memory
transfers can be avoided. In combination with the packet-based GPU BVH traversal, a performance
gain can be expected.
Finally, a second major difference between the two approaches lies in the rasterized mesh.
Whereas [PSS+ 06] use the convex hull to ensure an artifact-free result, [ABS08] rasterize the refinement itself. Although some artifacts may occur by using the tessellation, the z-buffer guarantees
that at most one intersection test is required for every pixel, except for surface boundaries, where a
ray can miss the surface, as opposed to [PSS+ 06], where several intersection tests may be needed per
pixel. Furthermore, almost all artifacts are correctly handled in the second intersection stage. The
artifacts that can not be handled result from (self-)intersecting surfaces, which should not happen in
reality. Additionally, since a tessellation is used, less primitives are generated, but more important,
the tessellation results in a view-dependent uv-texturing approach for free, whereas [PSS+ 06] require additional intersection computations in the vertex shaders. Using view-dependent uv-texturing
is currently the most efficient method, which converges very fast to the root.
Therefore, a NURBS ray tracing system should be possible to be fully implemented on GPU
by using a hybrid approach for casting primary rays and falling back on GPU BVH ray tracing for
missed intersections and secondary rays, such as shadows, reflections, refractions, etc.
44
Chapter 5
CUDA
With the introduction of the G80-architecture, NVIDIA has made a big step forward towards generalpurpose computing using GPU hardware. The Compute Unified Device Architecture, or CUDA, is
a general-purpose parallel computing hardware/software architecture. By choosing the well-known
C-language as the basis for their architecture, any programmer familiar with this language, can
immediately start developing parallel software. In addition, their programming language, C for
CUDA, has some of the C++ features, including polymorphism, operator overloading, and function
templates.
This chapter will briefly discuss the CUDA architecture, how it can be used to build highly
parallel software, and which obstackles need to be faced.
5.1
Massive Multi-threading Architecture
CUDA GPUs contain a number of multi-threaded streaming multiprocessors (SMs), each capable
of executing SIMD-groups of threads concurrently. Each SM contains 8 cores, together with a
scheduler which creates, manages, and executes concurrent threads in hardware with zero scheduling
overhead.
In contrast to SIMD software for CPUs, in which 4 instructions are executed in parallel, CUDA
applications launch a massive number of lightweight threads which are executed in parallel in a
streaming fashion. All threads form a grid, which is divided into user-defined blocks (Figure 5.1a).
Each block is assigned to a specific multiprocessor. Therefore, threads of the same block will always
execute on the same multiprocessor. Groups of 32 threads, called a warp, are executed physically in
parallel in SIMD-fashion. Additionally, each thread executes independently with its own instruction
address and register state1 . As long as all threads in a warp execute the same instruction, the warp
achieves maximum utilization. Otherwise, it is serially executed in two (or more) parallel groups.
Furthermore, to hide memory latencies, warps are time-sliced by a hardware scheduler with zero
schedule-overhead. The thread blocks are enumerated and distributed to the available multiprocessors, which allows for a highly scalable system (Figure 5.1b). Finally, CUDA-GPUs supporting SLI,
can be linked together to increase the performance even further. However, each GPU needs to be
controlled using a separate thread, and data is not shared between GPUs, therefore, all data need to
be uploaded twice. Nevertheless, by using SLI, the performance can be doubled in theory.
1 NVIDIA
refers to this as SIMT, for single-instruction, multiple-thread.
45
5. CUDA
(a) Hierarchical overview of CUDA threads.
(b) A device with more multiprocessors will automatically execute a kernel grid in less time than a device with fewer multiprocessors.
Figure 5.1: Thread blocks and their mapping to the multiprocessors.
5.1.1
Predicated execution
Sometimes, a thread may decide not to execute a branch, while other threads belonging to the same
warp do execute that branch. Such a warp will usually be split into as many thread-groups as required
to enable a parallel execution of each group. However, when the branch contains only a small
number of instructions, the compiler might decide to predicate the instructions. Threads which did
not execute the branch will be deactivated, and thus skip the instruction.
5.2
Memory Hierarchy
There are five different types of memory available for use. The GPU’s main memory, named globalmemory, is very big, but the latency is very high. The global-memory is shared among all running
threads, and even between kernel invocations. Each thread also has a private portion of this globalmemory, called local-memory. Although it’s optimized for efficient data transfers, it has the same
latency as the global-memory, making it very slow in some situations. The texture-memory, is a special read-only portion of the global-memory which can be read using special texture-fetch functions.
The advantage of using texture-memory, is that the texture-unit, which executes the fetches, caches
its incoming data. Therefore, frequently accessed data is likely to appear in the cache, so a read from
global-memory can be avoided. The latency to this cache is as fast as the access to a register. In
addition, the texture-unit provides filtering functionality, to normalize values, interpolate values, etc.
There is also a portion of global-memory, which is much alike the texture-memory: the constantmemory. It has some restrictions though, as being very small (only 64 kB), and has no filtering
support. Finally, each multiprocessor has on-chip memory of 16 kB, called the shared-memory. As
with the cache, the latency of this memory equals that of a register access. This memory is divided
among the active blocks running on a multiprocessor. The threads in a block can all access the same
shared data, however they cannot access the shared data of other blocks. The amount of shared46
Memory Hierarchy
Figure 5.2: Memory Hierarchy.
memory a block is given, is determined by the total amount of shared-memory which is reserved by
a kernel. Figure 5.2 illustrates the different types of memory.
5.2.1
Coalescing
Due to the wide memory bus, memory transactions always occur by fetching 32, 64, or 128 contiguous bytes simultaneously. Therefore, global memory bandwidth is used most efficiently when the
simultaneous memory accesses by threads in a half-warp (either the first 16 threads, or the last 16)
can be coalesced into a single memory transaction of 32, 64, or 128 bytes. In order to assist in coalescing, data is sometimes arranged as a structure of arrays (SOA), instead of an array of structures
(AOS). In this way, the data for each member is clustered, and can be fetched using a single memory
transaction.
5.2.2
Prefetching
The texture-unit also provides an implicit prefetching function. When fetching data from address X,
the texture-unit will automatically prefetch the data on addresses X-1 and X+1. If the thread, or any
other thread executed by the same multiprocessor, will read from a neighboring address, the data
will already be available and can be fetched directly from the cache.
47
5. CUDA
5.2.3
Bank conflicts
The data of the constant- and shared-memory are physically arranged into 16 memory-banks. As
long as the threads in a half-warp do not read or write from the same memory-bank, there will
be no conflicts. In case of a conflict, the memory-transactions will be performed serially for the
number of distinct conflicts. However, a read from the same address (broadcast), will not result in a
bank-conflict.
5.3
Launching a kernel
A kernel is defined in C for CUDA, which is an extension to the C-language. For example, the
well-known saxpy-operation can be defined as follows:
Listing 5.1: Example CUDA-kernel: saxpy
1
2
3
4
5
6
7
8
__global__ void saxpy (float *s , float a ,
{
int id_x = ( threadIdx .x + blockIdx .x
int id_y = ( threadIdx .y + blockIdx .y
int id
= id_x + id_y * ( blockDim .x
float *x , float *y)
* blockDim .x );
* blockDim .y );
* gridDim .x)
s[ idx ] = a * x[ idx ] + y[ idx ];
}
This kernel first computes its unique identifier, based on its position in the grid. threadIdx is a
vector containing the x and y location of the thread inside the block. blockDim gives the dimensions
of every block. blockIdx represents the location of the block inside the grid. And gridDim gives
the dimensions of the grid, in blocks.
After having computed the identifier, the x input element is read from global memory, multiplied
with the a-factor, and added to the y input element, also from global memory. Finally, the result
is written back to global memory. The code in Listing 5.2 launches a grid of 4 × 4 blocks, each
containing 1024 threads.
Listing 5.2: Example of launching CUDA-threads
1
2
3
4
... memory allocations , and variables defined elsewhere
dim3 grid (4 , 4);
dim3 block (32 , 32);
saxpy <<< grid , block > > >( output_s , a , input_x , input_y );
5.4
5.4.1
Debugging
Emulation
The nvcc compiler driver provides an option to generate binary code which can be executed by the
CPU, using the device emulation mode. Normally, it would not be possible to specify breakpoints
when the application is being executed by the GPU. However, using this mode, CUDA-applications
can be debugged, as if they were normal CPU-applications. Unfortunately, the emulation is not
100% accurate. Whereas the GPU can execute 32 threads physically in parallel, the emulation mode
cannot. Therefore, additional synchronization points need to be set, in order to obtain the same
48
Debugging
results. Finally, the emulation mode runs very slowly. Nevertheless, to find bugs, the emulation
mode is a very nice addition to the CUDA Toolkit.
Two other emulators which were available, are Barra [CDP] and GPUocelot [Dia09, DKK09].
Those emulators do not require a different compilation mode. Instead, they temporarily replace the
CUDA-Runtime, in order to intercept all instructions. Their goal is to provide a 100% accurate ,
and much faster emulation. However, at the time of writing this thesis, the emulators were not yet
capable of emulating applications designed for the CUDA 2.3 runtime. Nevertheless, an eye should
be kept on these emulators.
5.4.2
Hardware breakpoints
When running Linux, breakpoints can be set to running CUDA-applications, using the cuda-gdb debugger (an extension to gdb). However, no X-Server may be running on the GPU which is currently
being debugged, making it very difficult to visualize the output. Although it is possible to run the
X-Server on another computer in the network, it is generally recommended to have a second GPU
in the computer.
Unfortunately, the debugger did not work very well for the ray tracing system, probably because
the generated code was very complex.
49
Part II
Development
51
Chapter 6
System overview
In this chapter, the CUDA NURBS Ray Tracing System (CNRTS) is presented: a GPU-based implementation of the recursive ray tracing algorithm capable of direct ray tracing of NURBS-surfaces.
Besides primary-rays, the system is also able to cast shadow rays, reflection rays, and refraction rays
up to any desired depth. Additionally, the system features an acceleration subsystem for speeding-up
the casting of primary-rays. Finally, the system requires very little preprocessing, and the amount of
used memory is kept to a minimum.
The system heavily depends on auxiliary datastructures. These datastructures are computed only
once in a preprocessing step, and are then fed into the core of the system, which uses it for rendering.
The next chapter will discuss the preprocessing phase. This chapter only provides a global overview
of the system, the implementation details will be provided in Chapter 8.
Rendering Core The rendering of NURBS-surfaces is handled by the core of the CNRTS. It is
composed of two subsystems, namely the Primary-ray Accelerator and the Ray Tracer. The first
subsystem accelerates the primary intersection stage of the ray tracing system by limiting the number
of ray/surface intersection tests to a single test1 . Additionally, it accelerates the convergence of
the root-finder by providing more accurate initial-guess values. The Ray Tracer subsystem then
performs the classical recursive ray tracing algorithm, by tracing secondary-rays, including shadows,
reflections and refractions. Figure 6.1 gives a high-level overview of the architecture of the core of
the CNRTS. Both subsystems are executed entirely on the GPU with only a minimal amount of
coordination by the CPU.
Figure 6.1: System overview of the rendering core of the CNRTS
6.1
Primary-ray Accelerator subsystem
A hybrid technique is employed to accelerate the tracing of primary-rays. The efficiency of the
standard rasterization pipeline is exploited to limit the number of intersection tests and to obtain a
1 As
will be seen later, there are some cases in which this number can be slightly higher.
53
6. S YSTEM OVERVIEW
good starting point for the root-finder. Since the intention was to create an OS-independent system,
OpenGL is chosen as the graphics API. However, the system is easily modified to use DirectX
instead.
6.1.1
Rasterization
Based on the ideas by [ABS08, PSS+ 06, BBDF05], the Primary-ray Accelerator subsystem removes
the necessity for the traversal of an acceleration data structure by first rasterizing a coarse tessellation
of the NURBS-model. However, instead of just using the standard rendering pipeline (Section 1.1)
output, a vertex-shader and fragment-shader are employed to generate a customized output.
The tessellation is obtained from a refinement of the NURBS-model using the method described
in [MCFS00]. Before rasterization begins, two custom attributes are added to each vertex: a patchidentifier uniquely identifying the NURBS-surface and the span locations in the corresponding knotvectors; and the uv-parameter value of the NURBS-surface corresponding to the face-corner. The
tessellation is generated in a preprocessing step and is discussed in Section 7.1.
During rasterization, the rasterization-unit will interpolate the vertices’ uv-parameter values providing a weighted average closely approximating the surface’ uv-parameter corresponding to the
pixel’s true intersection-point2 . Pixels containing a rasterized primitive, will provide a good starting
point for finding the exact intersection-point: the patch-identifier identifies the NURBS-surface and
spans3 , and the uv-parameter value provides a good initial guess-value for the root-finder to find the
exact intersection-point. Pixels containing a background-value either do not contain a surface, or
missed the surface due to too coarse tesselation. Figure 6.2 shows schematically the rasterization
phase of the Primary-ray Accelerator.
Figure 6.2: Schematic overview of the rasterization phase of the Primary-ray Accelerator. The
output provides some cues for finding the exact intersection-point: the left rasterized image contains
the patch-ids and the right rasterized image contains the uv-values encoded in red for u-parameter
range and green for v-parameter range.
6.1.2
Traversal-less Ray Casting
As soon as the rasterization step completes, the actual ray tracing can begin. However, instead
of immediately applying the entire recursive algorithm, only the primary rays are traced without
spawning secondary rays, resulting in a ray casted image.
Normally, in order to find out which object is front-most w.r.t. the viewer, all the objects in
the scene need to be traversed, or part of the scene when using an acceleration datastructure (see
2 The
patch-identifier however, does not require interpolation, since it’s constant across the entire surface patch.
However, if the rootfinder happens
to fail in finding an intersection-point, then the pixel can be “repaired” by the Ray Tracer, as will be seen next (Section 6.1.4
and Section 6.2). In the case the rootfinder reports an intersection, it cannot be repair, and the incorrect surface will appear in
the result.
3 There are some cases in which the rasterized output incorrectly identifies the surface.
54
Primary-ray Accelerator subsystem
Figure 6.3: The ray’s direction is derived from the viewing parameters. In here, a denotes the fieldof-view. By setting the image-plane’s distance d from the camera equal to 1, the position in the
image plane is easily converted to world-coordinates.
Section 3.1). However, we actually already know nearly certain which object is front-most: the
patch-identifier resulting from rasterization identifies the surface closest to the viewer along the ray
being processed (see the left rasterized image in Figure 6.2). Thus, only one intersection test is
required.
So all that’s left to be done is computing the intersection based on the data output by the rasterizer.
The shading computations are deferred to the ray tracer subsystem. The interpolated uv-parameters
resulting from the rasterization are a perfect candidate for an initial-guess value for the root-finder
(see the right rasterized image in Figure 6.2).
6.1.3
Primary-ray setup
In order to use the rasterization output as input for the ray caster, the pixel positions need to be
mapped to primary-rays in such a way, that when the tessellation would be ray traced, the exact
same output should be obtained.
Figure 6.3 shows how the camera is positioned w.r.t. the image-plane. The mapping is derived
from the pixel position in the image plane, and the viewing parameters used for rasterization. Algorithm 9 shows the pseudo-algorithm to compute the ray from the pixel location and the viewing
parameters.
55
6. S YSTEM OVERVIEW
Algorithm 9 Computation of a primary-ray
Require: pixel location x, y, image plane resolution width and height, camera position eye, camera
focal point f ocus, camera up-vector up, and field-of-view a.
Ensure: ray origin O, and ray direction D.
1: O ← eye
2: D ← f ocus − eye
3:
stepx ←
4:
stepy ←
tan 12 a
1 width
2
tan 21 a
1 height
2
D ← D + (stepx · (x − 21 width + 12 )) · (D × up)
6: D ← D + (stepy · (x − 21 height + 12 )) · up
5:
6.1.4
Artifacts
While the Primary-ray Accelerator enables fast ray casting for NURBS-surfaces, it does not guarantee that the resulting output will always be correct. There are three types of artifact which can
appear, from which two of them can be fixed by the system.
The first type of artifact is related to the root-finder being skipped, due to a background-pixel in
the rasterization output. There are two cases in which this will happen: either the ray does not intersect any surface-patch and vanishes into the background; or the ray does intersect a surface-patch,
but due to a too coarse tessellation, it won’t show up in the rasterization. While the former is correct,
the latter produces an incorrect result, making the tessellation apparent in the result (Figure 6.4a).
Since both cases produce a background-pixel, it is not possible to differentiate between them.
The second type of artifact which could occur happens when the root-finder diverges. Again,
there are two cases in which this can happen: either the ray does not intersect any surface-patch,
but the rasterization output reported a hit; or the ray intersects another surface-patch than the one
reported in the rasterization output. Obviously the former is correct, but the latter will produce gaps
appearing in the result as can be seen clearly in Figure 6.4b.
Both types of artifacts are easily handled by the system by forwarding background-pixels, and
diverged pixels to the Ray Tracer subsystem in order to fix potential incorrect results. A disadvantage
of this method is that correctly computed pixels will have to be computed twice.
A third possibility leading to an incorrect result is a too coarse tessellation which doesn’t show
up in the rasterization. Whereas this will be handled correctly for background-pixels, it will not be
in the case of another surface lying behind the too coarse tessellated surface: this surface will be
intersected by the ray, and thus an incorrect intersection-point will be returned. This appears clearly
in the tesselation of the teapot (Figure 6.4c). While the former two types of artifacts are fixable by
forwarding them to the Ray Tracing subsystem, this type of artifact is not. Since a valid intersectionpoint is returned by the root-finder, it is not possible to determine if it was the front-most. However,
by using a not too coarse tessellation, these artifacts will occur rarely.
6.2
Ray Tracer subsystem
The heart of the rendering core is the Ray Tracer subsystem, which performs the full-blown recursive
ray tracing algorithm. Apart from tracing secondary-rays, it also handles the artifacts described in
Section 6.1.4 by retracing the primary-rays that either missed the tessellation (background-pixels) or
diverged during the root-finding phase.
The Ray Tracer subsystem follows the methods described in [MCFS00]. A BVH is constructed
from a refinement of the NURBS-model, in which each leaf-node represents a flat enough sub-patch
56
Ray Tracer subsystem
(a) Detectable corners appear due to a too (b) Gaps appear due to the tessellation. (c) Undetectable corners appear due to a too
coarse tessellation.
coarse tesselation.
Figure 6.4: Artifacts appear when using the Primary-ray Accelerator solely. In Figure 6.4a,
background-pixels appear instead of the surface. By forwarding all background-pixels to the Ray
Tracer, this artifact will disappear. Figure 6.4b shows some gaps, appearing in-between two surfaces. Figure 6.4c shows an artifact which cannot be detected using the algorithm, the only solution
is to tessellate more fine.
of a NURBS-surface. The subdivision is generated in a preprocessing step which will be discussed
in Section 7.1. The scene is traversed using a packet-based BVH-traversal scheme. The NewtonRhapson method Section 3.3.1 is adopted to obtain the ray/NURBS-surface intersections.
The implementation details will follow in Chapter 8.
6.2.1
Kernel separation
The first problem arising in mapping the ray tracing algorithm to GPU is that CUDA does not
have native support for recursive function calls. This problem could be overcome, by rewriting the
algorithm to an iterative version and using the shared-memory of CUDA to implement a stack to
push the spawned rays onto. While this may seem to be reasonable, it enforces us to write the entire
algorithm as a single complex kernel. However, an increase in kernel complexity, generally leads
to an increase in the number of used registers. This will reduce the occupancy of the kernel. And
if no more registers are available, it will result in lots of slow local-memory transfers. Additionally,
it is less likely the CUDA-compiler will do a good job in optimizing a complex kernel. Finally,
most CUDA GPUs have a limit on the maximum execution time of a kernel. Therefore, merging
all traversal steps, will increase the kernel’s execution time, and eventually will result in program
crashes.
Instead I have put the different ray tracing-steps into multiple CUDA-kernels. A single kernel
for tracing primary/secondary rays, another kernel for tracing shadow-rays and yet another kernel
for applying shading. The kernels propagate information to each other through the global-memory.
A per-pixel ray-stack is used on which reflection and refraction rays are pushed to, and popped from
when tracing secondary rays (Section 8.1.1). To store the intermediate intersection data required
by the shader, a hitdata-buffer is used, containing the intersection-point, the surface-normal, the
material-id, etc. (Section 8.1.2). A thin layer of CPU-code is used to coordinate the algorithm,
by launching the different CUDA-kernels (Algorithm 6.1). Figure 6.5 schematically shows this
separation.
57
6. S YSTEM OVERVIEW
Figure 6.5: The ray tracing algorithm separated into different CUDA-kernels. The CPU part coordinates the algorithm by launching the kernels successively. The inter-kernel data propagation through
global-memory is visualized by dashed lines, whereas the arrows indicate the flow/dependencies.
6.2.2
Tiling
Another problem that occurred during implementation was the amount of required memory for the
temporary buffers, i.e. the ray-stack and hitdata-buffer. For a maximum recursion-depth of 3, at a
resolution of 1024 × 1024, this results in 128 MB to be allocated for the ray-stack, and yet another
60 MB for the hitdata-buffer, totalling 188 MB (the derivation of these numbers can be found in
Section 8.1.1 and Section 8.1.2). When comparing this number to other types of allocation (such
as NURBS-data, BVH-data, image-buffers, etc.), it seems to be a rather high percentage of the total
allocated memory. Although modern GPUs are capable of allocating such an amount of memory,
these temporary buffers should not dominate the total amount of available memory, as it should
actually be reserved for read-only data such as NURBS-data, BVH-data, textures, etc. What’s even
worse, is that the buffers could even prove a potential bottleneck: since the amount of memory
required for the buffers is proportional to the image-resolution, increasing this resolution eventually
will fail the allocation of them4 .
The solution to this problem is to divide the image-space in evenly-sized rectangular pixelblocks, called tiles. Instead of applying the ray tracing algorithm onto the entire image, it is now
applied successively to each tile. Each tile is given an attribute tileIdx5 , a two-dimensional index
specifying the block position in image-space (analogous to the blockIdx and threadIdx parameters
for position in grid and block, respectively). Based on the tileIdx, together with the threadIdx,
the corresponding pixel location is computed, and accumulated with the color value from the shader.
4 A full-hd resolution of 1920 × 1080 with a maximum recursion depth of 3 would require 372 MB, solely for the
temporary buffers.
5 In CUDA-terms, this would have been gridIdx.
58
Ray Tracer subsystem
Figure 6.6: Separation of image-space into tiles: instead of applying the ray tracing algorithm onto
the entire image, it is now applied successively to each tile. The tiles are visualized using different
shades of grey, the pixels are separated by dashed lines.
Figure 6.6 schematically shows this separation into tiles.
The main advantage of this method, is that it does not depend on the image-resolution anymore.
Ray tracing an image with a maximum recursion-depth of 3 and a tile-size of 256 × 256 will always
result in a temporary-buffer size of 11.75 MB, which is only a small fraction of the available GPU
memory compared to the 188 MB when not using tiles.
6.2.3
Indirect recursion
Figure 6.5 suggests an iterative rewrite of the recursive ray tracing algorithm. However, for the sake
of simplicity, and since the CPU can’t possibly become a bottleneck in this system, I’ve chosen to
leave it recursive. In this way, the structure of the classical recursive ray tracing algorithm can be
found literally in the CPU-part of the system.
Listing Algorithm 6.1 shows the CPU-code which coordinates the ray tracing algorithm. The
raytrace-function is called and given a tileIdx which represents the current tile being processed.
It then launches the castRays CUDA-kernel, which performs the primary or secondary ray-traversal
step (including the root-finding and spawning of reflection- and refraction-rays). It then loops over
all lights and performs the casting of shadow-rays, by launching the castShadowRays CUDAkernel. Subsequently, it applies shading based on the intersection obtained from the castRaysand castShadowRays-kernels, by launching the computeShading CUDA-kernel. And finally, for
the recursion-step, the reflection- and refraction-rays are traced by calling the raytrace-function.
While recursively calling the raytrace-function, a stackpointer is provided from which the location
of the pushed ray is derived. In order to mimic a depth-first traversal of the ray-hierarchy, in which
the reflection-ray is spawned before the refraction-ray, the refraction-ray should be pushed before
the reflection-ray. Therefore, in the first recursive call, the stackpointer is increased, to let it point
to the top of the stack. Section 8.1.1 will provide more details about the ray-stack. Figure 6.7a and
Figure 6.7b illustrate how the stack is populated during the execution of the algorithm.
59
6. S YSTEM OVERVIEW
(a) The ray-hierarchy corresponding to a maximum recursion-depth of 3. Each ray spawns two rays: a reflection-ray and a
refraction-ray.
(b) The state of the stack while casting a ray corresponding to every node in the ray-hierarchy of Figure 6.7a.
Figure 6.7: Implementing recursion for CUDA using a stack.
Listing 6.1: CPU-code for the Ray Tracer subsystem
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
60
void raytrace ( int2 tileIdx , int depth = 0, int stackpointer = 0)
{
castRays <<< gridDim , blockDim > > >( tileIdx , stackpointer );
for (int i = 0; i < light_count ; i ++)
{
castShadowRays <<< gridDim , blockDim > > >( tileIdx , i );
computeShading <<< gridDim , blockDim > > >( tileIdx , i );
}
if ( depth < maxRecursionDepth )
{
/* Trace reflection-rays */
raytrace ( tileIdx , depth + 1, stackpointer + 1);
/* Trace refraction-rays */
raytrace ( tileIdx , depth + 1, stackpointer );
}
}
Summary
6.2.4
Shading
As a final step, shading is applied by the shader, only if the shadow-ray caster informs us that the
surface-point is illuminated by the light-source.
For the shading computation, a simplified Phong Illumination model is employed. For each pixel
the following formula is used to compute the light intensity:
Ip =
(ka IL + kd (L · N)IL + ks (R ·V )α IL ).
lights
∑
In this formula, I p amounts for the light intensity per intersection-point, ka the ambient reflection
constant, kd the diffuse reflection constant, ks the specular reflection constant, and α is a shininess
constant. Furthermore, IL is the light-source’s intensity.
This formula is computed for each spawned ray, and summed to obtain the final intensity for
the pixel. Since this intensity can be greater than 1, the value is scaled by a global intensity scaling
factor.
6.3
Summary
Figure 6.8 basically shows the path from a primary-ray up to the final pixel. A primary-ray is spawn
by rasterizing the tesselation; a fragment is further processed by the primary-ray accelerator’s rootfinder; a hit may skip the ray tracer’s traversal and root-finder and immediately continue by casting a
shadow ray; misses and background pixels are traced conventially by the ray tracer;whereafter they
are processed further by casting a shadow ray; shading is applied for non-blocked shadow-rays; and
finally reflection and refraction rays are spawn and traced recursively.
61
6. S YSTEM OVERVIEW
Figure 6.8: Lifetime of a primary-ray processed by the Primary-ray Accelerator and the Ray Tracer.
A primary-ray is spawn by rasterizing the tesselation; a fragment is further processed by the primaryray accelerator’s root-finder; a hit may skip the ray tracer’s traversal and root-finder and immediately
continue by casting a shadow ray; misses and background pixels are traced conventionally by the
ray tracer;whereafter they are processed further by casting a shadow ray; shading is applied for nonblocked shadow-rays; and finally reflection and refraction rays are spawn and traced recursively.
62
Chapter 7
Preprocessing
Using a separate program, a Wavefront OBJ file containing a NURBS-model is read, parsed, and
converted to the required format. Afterwards, the NURBS-data is preprocessed to obtain the bounding volume hierarchy for the traversal, the tesselation for the rasterizer, and the Cox-de Boor items
for the evaluation, which is then uploaded to the rendering core. This chapter describes the preprocessing phase of the program, and how the rendering core expects its data to be arranged.
7.1
Subdivision
Good performance, as well as an accurate result, is realized by a carefully subdivided NURBSmodel. Both the ray caster and the ray tracing subsystems depend on it. To ensure a close enough
linear approximation to the real surface, the NURBS-surface is first refined by inserting new knots
into the knot-vectors. By adding new knots, new control-points can be computed, which represent
exactly the same surface, but the convex-hull of the new refined surface also becomes closer to the
true surface. Therefore, by adaptively determining how many knots to insert and where, a new
refined mesh is obtained which can be used for tessellation and BVH generation.
The heuristic from [MCFS00] is employed for each u knot-span and corresponding column in
the grid (or row, in case of the v knot-vector). The maximum value for this heuristic, applied to each
row in the column, determines the number of knots to insert in the knot-span. This is repeated for
each knot-span for both knot-vectors. As a final step the NURBS-surface is converted to Bézierpatches by setting the multiplicity of each internal knot in the new knot-vectors to the degree of the
surface. The new control-grid is updated by computing the new control-points (Figure 7.2).
Figure 7.1: Overview of subdivision: the two subsystems both depend on the subdivision of the
NURBS-model.
63
7. P REPROCESSING
Figure 7.2: The NURBS-surface is converted into smaller Bézier-patches.
7.1.1
Tessellation
The ray caster subsystem depends on a tessellation in order to rasterize the NURBS-surface to obtain
good starting values for the numerical root-finder. This tessellation is directly derived from the
subdivision of the surface. The tessellation consist of a set of quadrilaterals each corresponding to a
sub-patch. The corners of each quadrilateral map to the corners of the corresponding Bézier-patch.
Each vertex contains a surface-identifier, a span-identifier, and an initial-guess uv-parameter.
7.1.2
BVH generation
The bounding volume hierarchy is easily constructed from the refined control-grid. From each subpatch (corresponding to the new non-empty intervals in the refined knot-vectors), a bounding box is
computed. Since the sub-patches are Bézier, the convex-hull is just the convex set of control-points
corresponding to the sub-patch. The bounding box is now simply the minimum, respectively the
maximum of these control-points (component-wise).
To generate the parent nodes higher up in the tree, the set of leaf-nodes are sorted along the axis
of longest extent, and split in halve (object median). A new internal node is generated and is set
as the parent of these two sets. This process continues recursively until a set of leaf-nodes contains
only one leaf-node Figure 7.3.
7.1.3
Memory Layout
BVH Nodes
The BVH nodes are arranged depth-first, as an array of structures to allow efficient access using the
parallel-read operation (Section 8.5.2). The array is stored in a texture bound to a single large piece
of linear-memory. As can be seen in Listing 7.1, each node contains two child-pointers and two
AABB for the corresponding children. To ensure the structure is correctly aligned to 16 bytes, two
extra floats are padded.
64
Subdivision
Figure 7.3: Bounding boxes of a BVH.
Listing 7.1: Definition of the BVHNode-struct
1
2
3
4
5
6
7
8
struct __align__ (16) BVHNode
{
int
child [2];
float
aabb_left [3][2];
float
aabb_right [3][2];
float
padding [2];
};
Leaf-nodes
The leaf-nodes contain other data, than the internal BVH nodes. Therefore, a separate structure
defines the leaf-nodes, which are actually just nurbs-patches. A nurbs-patch contains a reference to
its parent surface, its corresponding knot-spans, and an initial-guess value. Additionally, an extra
AABB is added to increase performance during traversal, as will be described in Section 8.5.2.
Listing 7.2 shows the definition of the NURBSPatch-struct.
65
7. P REPROCESSING
Algorithm 10 Cox-deBoor-items precomputation
Require: Knot-vector knot, n, degree
1: cdbitems ← []
2: for d = 1 to degree do
3:
for i = n − 1 to degree − d step − 1 do
1
4:
cdbitem[0] ← knot[i+d]−knot[i]
5:
6:
7:
8:
9:
10:
11:
−1
cdbitem[1] ← knot[i+d+1]−knot[i+1]
cdbitem[2] ← −cdbitem[0] · knot[i]
cdbitem[3] ← −cdbitem[1] · knot[i + d + 1]
append(cdbitems, cdbitem)
end for
end for
return cdbitems
Listing 7.2: Definition of the NURBSPatch-struct
1
2
3
4
5
6
7
8
9
struct __align__ (16) NURBSPatch
{
int
surface_id ;
int
span_id ;
float2
uv ;
float
float
aabb [3][2];
padding [2];
}
7.2
Root-Finder Data
The root-finder depends heavily on the evaluation algorithm, which in turn requires the availability
of the NURBS-surface data. Depending on the used evaluation scheme (Section 3.5), additional data
may be required.
7.2.1
Basis-function data
Two evaluation schemes have been tested, namely the “inverted-triangle”-method, and the divisionfree method. While the former does not require any preprocessing, the latter depends on the precomputed Cox-deBoor-items. The computation of these items is fairly straightforward. For each surface,
these items are computed row-wise. Algorithm 10 gives the pseudo-code for computing the items.
7.2.2
Memory layout
NURBS-surface data
The root-finder heavily depends on information describing the NURBS-surface, such as the degrees,
control-points, knot-vectors, etc. The probability of two coherent rays hitting the same NURBSsurface, and therefore accessing the same data, is rather high. Therefore, the texture-memory is an
ideal candidate for storing the NURBS-data. Frequently accessed surface-data will appear in the
texture-cache, resulting in very fast fetch-times.
66
Root-Finder Data
For packet-based traversals, the performance can be increased, by choosing a layout that minimizes the fetch-time. For this, the data is arranged as an array of structures. In this way, the data can
be fetched very efficiently by a single instruction using a parallel-read.
For non-packet-based traversals, the AOS-approach is still beneficial over an SOA-approach,
since reading a member will result in a pre-fetch of neighbouring members, which again will reduce
the fetch-times. Furthermore, for the primary-ray accelerator, it could even be less efficient to store
the surfaces as a SOA. At first, there is totally no spatial relation between the surfaces and the storage
of them, and second, because the primary-ray accelerator only performs a single intersection test.
Because the data for the control-points and the knot-vectors are variable-sized, they cannot be
included in the nurbs-surface data directly, and are therefore stored in two separate textures: one
for the control-points, and another for the knot-vectors. These textures will be discussed in the next
subsections.
Listing Listing 7.3 shows the definition of the structure describing the NURBS-surface.
Listing 7.3: Definition of the NURBSSurface-struct
1
2
3
4
5
6
7
8
9
10
11
struct __align__ (16) NURBSSurface
{
int n_u ;
int n_v ;
int degree_u ;
int degree_v ;
int offsetControlPoints ;
int offsetKnotVector_u ;
int offsetKnotVector_v ;
int material_id ;
};
Control-points
CUDA provides a very optimized way for accessing texture data by exploiting the two-dimensional
spatial coherence. However, in order to benefit from this efficiency, the control-points are required
to be stored into a rectangular texture. Since the sizes of the control-point grids may differ, a lot of
“empty” areas will appear in the texture.
Instead, the control-points of all surfaces are combined in a texture bound to a single large piece
of linear-memory. The control-points are stored in row-major order. The rows of a surface are concatenated to the texture to form an indexible array. The index of the first control-point is stored into
the NURBSSurface-struct and is used to find the corresponding control-points (ListingListing 7.3).
Knot-vectors
The knot-vector data is stored similarly to the control-point data. Using a single large texture both
the knot-vectors are concatenated and appended to the texture. The starting index for each knotvector is stored into the NURBSSurface-struct and is used to find the corresponding knot-vector
(ListingListing 7.3).
Cox-deBoor items
The Cox-deBoor array is stored similarly to the control-point data. Using a single large texture both
arrays are concatenated and appended to the texture. The starting index for each array is stored into
the NURBSSurface-struct and is used to find the corresponding knot-vector (ListingListing 7.3).
67
7. P REPROCESSING
Material data
Since there is no relationship between the spatial position of two surfaces having two distinct materials and the memory addresses of those materials, little advantageous can be expected by arranging
the materials as a structure of arrays. Furthermore, while shading a pixel, every data-item of the
material will be accessed successively. Therefore, the material-data should be clustered to allow
prefetching (Section 5.2.2).
By creating a texture containing an array of material-structures, the data can be fetched most
efficiently. Listing Listing 7.4 shows the definition of the structure describing a material.
Listing 7.4: Definition of the Material-struct
1
2
3
4
5
6
7
8
9
68
struct __align__ (16) Material
{
float3 diffuse ;
float3 specular ;
int
shininess ;
float reflectance ;
float transparency ;
float refraction_index ;
};
Chapter 8
Kernel details
This chapter will discuss all the implementation-specific details for the rendering core. First, all data
structures will be described, which are used for inter-kernel communication. Then, the root-finder
will be discussed, which will be used by the primary-ray accelerator subsystem as well as the ray
tracer subsystem. Finally, the kernel-launch configurations are discussed, including the mapping of
rays to threads.
8.1
8.1.1
Inter-kernel Communication
Ray-stack
To get around CUDA’s absence of support for recursive function calls, a ray-stack is used. Instead
of stepping recursively into the ray tracing function to trace reflection- and refraction-rays, the rays
are pushed onto the ray-stack, and traced further during subsequent kernel-launches. Each kernellaunch starts by popping one secondary ray from the ray-stack, which is traced and possibly spawns
two more rays.
The stack is implemented in global-memory as a structure of arrays (Section 5.2.1) containing
stack-data for every thread. Each array maps to exactly one stack-level holding the data for each
thread for that level. Figure 8.1 shows the memory layout of a stack for 4 threads using a stackdepth of 3. Reading from as well as writing to memory laid out like that, results in efficient coalesced
transfers (Section 5.2.1).
Usually each thread maintains its own stack-pointer, since some rays will hit a surface and spawn
rays, while others will not. Instead, each ray traverses the same path in the ray-hierarchy, and
pushes two dummy-rays onto the stack whenever it does not spawn secondary rays. In this way, all
threads can share the same stack-pointer. The dummy-ray can be identified by setting the x-value to
+∞. When popping a ray, an x-value of +∞ indicates it’s a dummy-ray and the thread should not
participate in the traversal.
The definition of the structure can be found in listing Listing 8.1. The amount of memory in
bytes required for allocating the ray-stack containing 8 float-arrays, is given by:
kRayStackk = width · height · (depth + 1) · 32
where width and height represent the image-resolution, and depth equals the maximum recursiondepth. The depth + 1 factor equals the maximum stack-size, and is one larger than the maximum
recursion depth, since the ray-hierarchy is traversed depth-first.
69
8. K ERNEL DETAILS
Figure 8.1: Memory layout of a stack inside global-memory. This stack is for 4 threads and has a
maximum depth of 3. The exemplary “virtual” stack of thread 2 shows the mapping of threads and
stack-levels to global-memory addresses.
Listing 8.1: Definition of the RayStack-SOA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
struct RayStack
{
struct
{
float *x;
float *y;
float *z;
} o;
struct
{
float *x;
float *y;
float *z;
} d;
float * opacity ;
float * refraction_index ;
};
__constant__ RayStack rayStack ;
8.1.2
Hitdata-buffer
The hitdata-buffer is used to propagate intermediate results from the ray caster to the shader. These
include, among others, the coordinates of the intersection-point, the surface-normal corresponding
to that intersection, the distance along the ray causing that intersection, etc.
The buffer is arranged in global-memory as a structure of arrays in order to hide the transfer
latency (Section 5.2.1). The definition of the structure can be found in listing Listing 8.2. The
amount of memory in bytes required for allocating the hitdata-buffer containing 13 float-arrays
and 2 int-arrays, is given by:
kHitDataBufferk = width × height × 60
70
Inter-kernel Communication
where width and height represent the image-resolution.
Listing 8.2: Definition of the HitDataBuffer-SOA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
struct HitDataBuffer
{
float *t;
struct
{
int * surface_id ;
int * span_id ;
} patch_id ;
struct
{
float *x;
float *y;
float *z;
} s;
struct
{
float *x;
float *y;
float *z;
} normal ;
struct
{
float *x;
float *y;
float *z;
} d;
float *u;
float *v;
float * opacity ;
};
__constant__ HitDataBuffer hitDataBuffer ;
8.1.3
Image-buffer
After shading is applied to each ray, its resulting color is accumulated to the corresponding pixel
in the image-buffer. This buffer is not explicitly allocated by CUDA1 , but is acquired by mapping
an OpenGL Pixel Buffer Object (PBO) into the address-space of CUDA. The buffer is arranged as
successive quadruples containing floats for the red, green, blue, and alpha channels, respectively.
When mapped, the buffer can be accessed as an ordinary float4-array.
After the rendering is finished, the buffer is unmapped, and displayed on screen. Listing Listing 8.3 shows the code required for initialization of the image-buffer and Listing 8.4 shows the code
for rendering.
1 However, when the goal of ray tracing is solely offscreen-rendering, i.e. in order to output a ray traced video, the buffer
must be allocated by CUDA.
71
8. K ERNEL DETAILS
Listing 8.3: Initialization of the image-buffer.
1
2
3
4
5
6
7
8
9
/* Allocation of image-buffer */
size_t size = width * height * sizeof( float4 );
glGenBuffers (1 , & pboID );
glBindBuffer ( GL_PIXEL_PACK_BUFFER , pboID );
glBufferData ( GL_PIXEL_PACK_BUFFER , size , 0, GL_DYNAMIC_DRAW );
glBindBuffer ( GL_PIXEL_PACK_BUFFER , 0);
/* Registration to CUDA */
cudaGLRegisterBufferObject ( pboID );
Listing 8.4: Usage of the image-buffer.
1
2
3
4
5
6
7
8
9
10
11
12
13
8.2
/* Mapping into address-space of CUDA */
cudaGLMapBufferObject ((void **)& imageBuffer , pboID );
/* Rendering */
...
/* Unmapping */
cudaGLUnmapBufferObject ( pboID );
/* Blitting */
glBindBuffer ( GL_PIXEL_UNPACK_BUFFER , pboID );
glDrawPixels ( width , height , GL_RGBA , GL_FLOAT , 0);
glBindBuffer ( GL_PIXEL_UNPACK_BUFFER , 0);
Root-finding
The root-finder basically implements a slightly modified version of the Newton-Rhapson algorithm
described in Section 3.3.1. Normally, when the uv-parameter leaves the surface-domain, the rootfinder should report an intersection-miss. However, it appeared that sometimes for surfaces which
actually do contain a valid intersection-point, the uv-increment becomes too large during the first
iteration, which causes the parameter to leave the surface-domain too soon. The root-finder will
stop searching too early, and reports a miss. To prevent this faulty early-termination, a minimum
iteration-count is incorporated to prevent such events. This extra minimum is also applied to the
criteria in which the error increases. The results will show (Section 9.2.2), that the quality of the
output is increased, while the performance is not affected (if will actually increase a little).
Usually, a binary-search is performed to compute the knot-intervals from the uv-parameters.
However, we already have this information: both the rasterization and the BVH provides us these
data from the patch-identifier. From the span-id and the knot-vector, the patch-domain is derived
which is used inside the root-finder. When the uv-parameter leaves the patch-domain, the span-id is
updated according to the new location on the surface. If the uv-parameter leaves the surface-domain,
the root-finder will exit (only after the minimum number of iterations has been reached).
8.3
Surface Evaluation
Algorithm 4 is used for evaluation of the surface-point and its partial-derivatives. An important
optimization has been added however. Since the basis-functions (Section 3.5) are accessed very
frequently, both during basis-function evaluation, as well as during the computation of the tensor72
Surface Evaluation
Figure 8.2: Arrangement of data for a cache inside shared-memory. This example uses an array of 3
elements for each thread, and a block size of 4 threads.
product, storing them in the local-memory will be rather slow. While local-memory may suggest
that it’s on-chip memory, it’s actually not. Local-memory is located in the DRAM, and although the
accesses are implicitly coalesced, they still have a very high latency. Therefore, a software-managed
cache has been implemented which will now be described.
8.3.1
Software-managed Cache
In order to minimize these latencies, a cache is implemented in shared-memory (Section 5.2). For
a block of threads, some shared-memory is reserved in which these arrays reside. To prevent bankconflicts, each thread in a half-warp needs to access a different location. Therefore, the per-thread
array-elements have a stride equal to the number of threads in the block, which is always a multiple
of the width of a half-warp (Figure 8.2), in this way bank-conflict are avoided entirely. Listing 8.5
shows an example of a software-managed cache using the shared-memory.
Listing 8.5: Software-managed Cache
1
2
3
4
5
__shared__ float N[ BLOCKSIZE * elements ];
float element_0 = N[ BLOCKSIZE * 0 + THREAD_IDX ];
float element_1 = N[ BLOCKSIZE * 1 + THREAD_IDX ];
float element_2 = N[ BLOCKSIZE * 2 + THREAD_IDX ];
...
8.3.2
Basis-function evaluation
From the different evaluation schemes described in Section 3.5, only the direct and the division-free
methods have been implemented. The power-basis method was not chosen, because it requires a lot
of preprocessing, and does not result in a very stable evaluation method. The de Boor’s algorithm
requires too much registers and has also been skipped.
73
8. K ERNEL DETAILS
8.4
Primary-ray Accelerator subsystem
8.4.1
Rasterization
Usually, rasterization is directly output to the frame-buffer and displayed on screen. However, we
need to obtain the resulting output, since it needs further processing. The OpenGL Framebuffer
Object (FBO) extension, provides a highly efficient mechanism for redirecting the rasterization to a
virtual frame-buffer. The FBO is a collection of attachable OpenGL buffer objects containing one
or more render-buffers to which the rasterization is output, a depth-buffer, stencil buffer, auxiliary
buffers, etc. Also, textures can be attached to the FBO to enable direct render-to-texture support.
This system uses an FBO containing a render-buffer for the data and additionally a depth-buffer to
enable proper depth ordering of the fragments.
Recall from Section 6.1.1, that each vertex gets some custom attributes. These attributes correspond to the surface-patch and the uv-parameter of the vertex. Since a single render-buffer is used to
store the rasterization, the format of the custom attributes need to match, which is not the case (uvparameters are floating-point and patch-identifier contains integer data). Therefore, the integer data
is converted to floating-point data by performing a type cast on the binary data2 . Due to numerical
round-off errors, interpolating all attributes will result in an incorrect patch-identifier. Therefore, a
custom GLSL-shader is employed which only interpolates the uv-parameters, but leaves the patchidentifier data untouched. Listing 8.6 and Listing 8.7 shows the shader programs which are used to
obtain the correct result. The extra flat keyword denotes an attribute which will not be interpolated
by the rasterization-unit, the resulting fragment will receive the value of an arbitrary vertex contained
in the primitive.
Listing 8.6: Vertex shader
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#extension EXT_gpu_shader4 : enable
attribute vec4 attr_data ;
varying vec2 uv ;
flat varying float surface_id ;
flat varying float span_id ;
void main (void)
{
gl_Position
uv
surface_id
span_id
}
2 For
74
=
=
=
=
ftransform ();
attr_data . xy ;
attr_data .z;
attr_data .w;
example, the integer value 0x3f800000 would be converted to the floating-point value 1.0.
Primary-ray Accelerator subsystem
Listing 8.7: Fragment shader
1
2
3
4
5
6
7
8
9
10
#extension EXT_gpu_shader4 : enable
varying vec2 uv ;
flat varying float surface_id ;
flat varying float span_id ;
void main (void)
{
gl_FragColor = vec4 ( uv .x , uv .y , surface_id , span_id );
}
After rasterization has been completed, the render-buffer can be read by the ray caster. Unfortunately, CUDA currently does not support direct access to render-buffers. Therefore, an OpenGL
Pixel Buffer Object (PBO) is used to copy the data from the render-buffer to the PBO. Although this
requires another copy, the transfer is from GPU-memory to GPU-memory, which is very fast. After
copying, the data is made available to CUDA by mapping the PBO into the address-space of CUDA.
Instead of allocating a new buffer for this PBO, the image-buffer is used (Section 8.1.3).
8.4.2
Ray Casting
There are two ray casting kernels, one for the Primary-ray Accelerator subsystem, and another for
the Ray Tracer subsystem. In this section, the former is discussed, which can be seen in Listing 8.8.
It starts by reading the corresponding data-item from the rasterization buffer. If the surface-identifier
value happens to be equal to zero, a background pixel has been identified, and no intersection needs
to be found. A non-zero value however, indicates a surface-patch, consequently a ray should be cast
for this pixel.
Since we already have a surface-patch candidate, we avoid the need for traversal of the scene.
We can immediately try to find an intersection using the data from the rasterization.
Although the Ray Tracer subsystem should spawn secondary rays, it turns out to be more efficient
to immediately spawn them. The reason is that if we would let the ray tracer spawn the rays, it would
depend on the hitdata, which is read from global-memory. This will heavily stall the execution of the
ray tracing kernel. As we already have all required data, i.e. the intersection-point, surface-normal,
material-properties, etc., we can just as easy compute the reflection and refraction ray here. This will
increase the performance in a later stage, since now only the intersection-distance has to be read to
determine if the pixel can be skipped.
After having obtained an intersection, or if the ray was skipped since the rasterization reported a
background-pixel, the hitData-record is written to global-memory through the hitData-buffer.
75
8. K ERNEL DETAILS
Listing 8.8: Ray Casting kernel (Primary-ray Accelerator)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
template<bool spawnRays >
__global__ void castRay ( int2 tileIdx , float4 * framebuffer )
{
:: tileIdx = tileIdx ;
float4 data = framebuffer [ OFFSET_SCREEN ];
HitData hitData ;
hitData .t = FLOAT_INFINITY ;
/* Skip background-pixels */
if ( __float_as_int ( data .z) != 0)
{
Ray ray = fromPixel ( X_SCREEN , Y_SCREEN );
NURBSPatch nurbsPatch ;
nurbsPatch . uv = make_float2 ( data .x , data .y);
nurbsPatch . surface_id = __float_as_int ( data .z) - 1;
nurbsPatch . span_id = __float_as_int ( data .w);
float2 uv_min ;
float2 uv_max ;
fetchPatchDomain ( nurbsPatch , & uv_min , & uv_max );
rootFinder (ray , nurbsPatch , uv_min , uv_max , hitData );
if ( spawnRays )
{
Ray reflectionRay = ray . reflect (& hitData );
rayStack . push (& reflectionRay , stackpointer + 1) ;
Ray refractionRay = ray . refract (& hitData );
rayStack . push (& refractionRay , stackpointer + 0) ;
}
}
__hitDataBuffer__ . write (& hitData );
}
Parallel intersection test
Normally, when taking a SIMD-approach to ray-tracing, the scene is traced packet-based using a
small packet-size (usually 2x2 rays). Often, four pixels in a block refer to the same patch which
can then be intersected by at best four rays in parallel with only one call to the intersection routine.
Occasionally, the rays intersect different patches. The intersection routine is then called for each
distinct patch in the SIMD-packet.
However, due to CUDA’s SIMD-width of 32 threads, the ray caster in this system uses a much
larger packet, increasing the likeliness of the rays intersecting different patches. Calling the intersection routine for each distinct patch will result in many calls, in which only a small amount of
rays will actually be testing the patch for an intersection. Hence, for a CUDA-based ray-tracer,
employing such a method will decrease the multiprocessor’s utilization heavily.
Because all dependent NURBS-data is located in texture-memory, such as the knot-vectors,
control-grids, etc., it is possible for different rays to access different surface-patches. Therefore,
the intersection test will be called only once for each thread, maximizing the utilization.
76
Ray Tracer subsystem
8.5
Ray Tracer subsystem
8.5.1
Ray Casting
The castRay-kernel implements the majority of the ray tracing algorithm. It starts by constructing a ray if it’s casting a primary-ray, otherwise it simply pops a previously spawned reflection- or
refraction-ray from the ray-stack (Section 8.1.1). It then traverses the scene using either the packetbased traversal scheme or the single-ray traversal scheme, which will be described in the next subsection. After traversal, the hitData-record is written to global-memory through the hitData-buffer.
Finally, the reflection- and refraction-rays are spawned. Once again, regarding the stack-pointer, the
reflection-rays are pushed “above” the refraction-rays.
In order to assist nvcc in optimizing as much as possible, the complexity of the code is reduced
by using a templated function. Using templates, parts of the code can be enabled or disabled during
compile-time. The primaryRay-flag indicates we are casting primary-rays, so we should not pop
from the stack, but instead construct the ray in-place. One could argue this is less efficient, since it
increases the complexity of the code. However, it turns out that popping of rays is quite expensive
compared to constructing primary-rays, due to the global-memory latency. The same applies for the
spawnRays-flag, which is used to enable or disable the reflection- and refraction-rays.
Listing Listing 8.12 shows the ray casting kernel for the ray tracing subsystem.
Listing 8.9: Ray Casting kernel (Ray Tracer)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
template<bool primaryRay , bool spawnRays >
__global__ void castRay ( int2 tileIdx , int stackpointer )
{
:: tileIdx = tileIdx ;
HitData hitData ;
hitData .t = INF ;
Ray ray ;
if ( primaryRay )
ray = fromPixel ( X_SCREEN , Y_SCREEN );
else
rayStack . pop (& ray , stackpointer );
traverseRay (ray , hitData );
hitDataBuffer . write (& hitData );
if ( spawnRays )
{
Ray reflectionRay = ray . reflect (& hitData );
rayStack . push (& reflectionRay , stackpointer + 1) ;
Ray refractionRay = ray . refract (& hitData );
rayStack . push (& refractionRay , stackpointer + 0) ;
}
}
8.5.2
Packet-based Traversal
For the packet-based traversal scheme, the method from [GPSS07] is used which is described in
Section 4.1.3, with some additions specific for NURBS-ray tracing. It can be beneficial for all
threads to exit as early as possible. Non-participating packets for example, may skip the entire
77
8. K ERNEL DETAILS
traversal algorithm. This decision is made by performing a parallel-reduction prior to the traversal
(Section 8.5.2).
Shared-memory stack
In a packet-based traversal each ray traverses the hierarchy in exactly the same order. Therefore,
the stack required to push nodes onto, can be shared by the rays. This stack is implemented by
pushing node addresses to an array in shared-memory. By reserving 24 integers for this array, scenes
consisting of up to 16,777,2163 sub-patches can be traversed, which should be enough.
Each thread maintains its own local stack-pointer. Popping elements from the stack is then
simply done by decrementing the pointer and returning the value from the shared-memory array
corresponding to this pointer. Pushing to the stack requires some synchronization however, since
only one thread is allowed to write to the shared-memory if all threads want to write to the same
location, which is the case. To prevent potential read-after-write hazards, a barrier is set before
pushing the new value. For the same reason, after the data has been written, another barrier is set.
Afterwards, the stack-pointer is incremented for each thread.
Listing 8.10 shows a code-fragment of how the shared-memory stack can be used to push a
data-item onto the stack, and pop it from the stack afterwards.
Listing 8.10: Shared-memory stack
1
2
3
4
5
6
7
8
9
10
11
__shared__ int stack [ STACK_SIZE ];
int stack_pointer = 0;
/* Pushing an element to the shared-stack */
__syncthreads () ;
if ( THREAD_IDX == 0) stack [ stack_pointer ] = data ;
__syncthreads () ;
stack_pointer ++;
/* Popping an element from the shared-stack */
data = stack [-- stack_pointer ];
View-dependent ordered traversal
As in [GPSS07], a view-dependent ordered traversal scheme is used, which increases performance
for most scenes. A packet traverses the hierarchy, collectively deciding which child to traverse first.
This decision is slightly altered however. Inactive rays (rays which do not intersect the current node)
should not affect the decision-making of the algorithm, therefore the following modified formula is
used to determine which child should be visited next:
i = (t0 6= ∞) + 2 · (t1 6= ∞)
where t0 is the intersection distance for the AABB of the left child, and t1 is the intersection distance
for the AABB of the right child. For each ray, this value is computed and the index is used to set
the ith element in a shared-memory array to true, for which each four values are initialized with
the value false. Consequently, the values of this array determine which children need a visit. If the
fourth element is true, or the second and third element are both true, both children need a visit.
Otherwise, the left child only needs a visit if the second element is true, the right child if the third
is true, and no children if the first element is true (which denotes an inactive ray).
3 Assuming
78
a balanced tree.
Ray Tracer subsystem
The other decision is to determine which child needs to be visited first if the packet will visit
both:
j = 2 · (t0 > t1 ) − (t0 6= t1 )
j will result in −1 if for this ray the left child is closer than the right child, +1 if the right child
is closer, and 0 if the ray is inactive. All these values are summed, and the resulting value decides
which child will be visited next.
Parallel Reduction
A frequently used data-parallel primitive in parallel software is the parallel reduction (or parallel
sum), in which an array of data-elements is “summed” using an associative operation (i.e. addition,
multiplication, maximum, minimum, etc.). Usually, performing a reduction operation on an array of
data requires n steps, for an array of size n. However, with the availability of a parallel multiprocessor, this operation can be performed very efficiently. Using a tree-based approach, in which each
node (thread) computes the partial sum of its two children (array elements), an array of n elements
can be summed in log2 n steps.
Using this primitive, also functions such as all and any can be implemented, simply by using the
and resp. or operators. Using these functions, a predicate can be tested for all threads to be true, or
at least one thread in case of the any operation.
Listing 8.11 shows a code-fragment of how the parallel reduction is used to sum the 64 integer
values in deciding which child should be visited first. Since CUDA-threads are executed in SIMDgroups of 32 threads, called warps, no synchronization is required during the reduction steps, as long
as the size of the array does not exceed 64 elements.
Listing 8.11: Parallel-sum
1
2
3
4
5
6
7
8
9
10
11
12
13
14
__shared__ int data [64];
data [ THREAD_IDX ] = decision ;
__syncthreads () ;
/* Reductions */
if ( THREAD_IDX < 32) data [ THREAD_IDX ] +=
if ( THREAD_IDX < 16) data [ THREAD_IDX ] +=
if ( THREAD_IDX < 8) data [ THREAD_IDX ] +=
if ( THREAD_IDX < 4) data [ THREAD_IDX ] +=
if ( THREAD_IDX < 2) data [ THREAD_IDX ] +=
if ( THREAD_IDX < 1) data [ THREAD_IDX ] +=
__syncthreads () ;
data [ THREAD_IDX
data [ THREAD_IDX
data [ THREAD_IDX
data [ THREAD_IDX
data [ THREAD_IDX
data [ THREAD_IDX
+ 32];
+ 16];
+ 8];
+ 4];
+ 2];
+ 1];
decision = data [0];
Parallel Memory Fetching
A highly optimized parallel algorithm to obtain data which is shared among all threads in the block,
is the parallel-read algorithm. The algorithm is used to transfer a block of data from global-memory
(or texture-memory) to shared-memory in an efficient way: by letting each subsequent thread read
a subsequent data-element. Using this algorithm, a block of memory can be read using only one
instruction as long as the number of data-elements does not exceed the number of threads in the
block.
The efficiency lies in the coalescing of the memory-accesses: each thread accesses a subsequent
address. Therefore, the memory controller can transfer the memory line-by-line exploiting the band79
8. K ERNEL DETAILS
width of the memory-bus. Furthermore, a thread does not have to wait for the read to complete
before reading the next data-element, since all data are read at once.
Packet-based Root-finding
The Primary-ray Accelerator subsystem fetches its data directly through the texture-unit, allowing
the rays to simultaneously intersect different patches. The Ray Tracer subsystem on the other hand,
traverses the scene packet-based. While processing a leaf-node, all rays in a packet always call the
intersection routine using the same patch.
Since all rays access the same data, they can be fetched efficiently using parallel-read operations
(Section 8.5.2) and transferred to shared-memory. Although the data-fetches are already cached by
the texture-unit, using the parallel-transfer operations, the memory is accessed much more efficiently.
Extra Leaf-node Ray-AABB intersection test
If a packet visits a leaf-node because only a single ray intersects it (or a few rays), the other “nonactive” rays in the packet pay the price for the packet-based traversal. Normally, this is not that big
of a deal, since ray/primitive intersection tests are very cheap for basic primitives (i.e. triangles).
However, now the other rays also have to participate in the root-finding. There is a possibility some
rays converge or diverge more slowly than the rays that were actually intersecting the node. This
will unnecessarily stall the traversal. Also, a ray could already have obtained an intersection which
is more close than the intersection with the AABB of the to-be-tested leaf-node. In that case, the
intersection test even becomes unnecessary.
By simply inserting an additional, repeated ray/AABB intersection test right before the rootfinder, these situations can be avoided, reducing the total number of intersection tests and stalls.
Listing 8.12 shows the total packet-based traversal algorithm.
80
Ray Tracer subsystem
Listing 8.12: Packet-based Traversal-function
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
__device__ void traverseRayPacket (const Ray &ray , HitData & hitData )
{
if (all < BLOCKSIZE >(! ray . participating () ))
return;
SharedStack < MAX_STACK_DEPTH > stack ;
int nodeIndex = 0;
for (;;)
{
if ( IS_LEAF ( nodeIndex ))
{
__shared__ NURBSPatch nurbsPatch ;
fetchNURBSPatch ( nurbsPatch , nodeIndex );
fetchSharedEvaluationData ( nurbsPatch );
if ( ray . participating () &&
ray . intersectAABB ( nurbsPatch . aabb , hitData .t) != INF )
rootFinder (ray , nurbsPatch , hitData );
if ( stack . empty () ) break;
stack . pop ( nodeIndex );
}
else
{
__shared__ BVHNode bvhNode ;
fetchBVHNode ( bvhNode , nodeIndex );
float t0 = INF ;
float t1 = INF ;
if ( ray . participating () )
{
t0 = ray . intersectAABB ( bvhNode . aabb [0] , hitData .t);
t1 = ray . intersectAABB ( bvhNode . aabb [1] , hitData .t);
}
/* Set the flag for which child needs a visit (or both)
M[0] == true --> No children intersected
M[1] == true --> Only left child intersected
M[2] == true --> Only right child intersected
M[3] == true --> Both children intersected */
__shared__ int M [4];
if ( THREAD_IDX < 4) M[ THREAD_IDX ] = 0;
__syncthreads () ;
M [( t0 != INF ) + 2 * ( t1 != INF )] = 1;
__syncthreads () ;
if (M [3] || M [1] && M [2])
{
/* -1 == prefer left,
* 1 == prefer right,
* 0 == no preference */
bool go_left = sum < BLOCKSIZE >(2*( t0 > t1 ) - ( t0 != t1 )) < 0;
stack . push ( bvhNode . child [ go_left ]) ;
nodeIndex = bvhNode . child [1 - go_left ];
}
else if (M [1])
{
nodeIndex = bvhNode . child [0];
}
else if (M [2])
{
nodeIndex = bvhNode . child [1];
}
else
{
if ( stack . empty () ) break;
stack . pop ( nodeIndex );
}
}
}
}
81
8. K ERNEL DETAILS
8.5.3
Single-ray Traversal
Although the packet-based scheme allows for an efficient traversal, it results in more leaf-nodes
visited per ray. Therefore, when processing a leaf-node, the likeliness of a ray not intersecting that
leaf-node is much higher than for single-ray traversal. As a consequence, the number of rays in a
block actively participating in the root-finding, will be much lower than for single-ray traversal.
On the other hand, the packet-based traversal scheme will not lead to warp-divergence, since each
ray in a packet follows the exact same traversal path. Single-ray traversal however, does lead to heavy
warp-divergence. Some rays for example, may execute the root-finder, while others are traversing
the BVH. A warp containing traversing and root-finding rays, cannot be executed simultaneously.
Therefore, such warps will be executed in two subsequent steps: the first executing a traversal step,
disabling the root-finding threads. The second step will execute the root-finder, and disables the
other threads. However, since a root-finding step is very expensive, the inactive threads will have to
wait very long, before they can continue, resulting in a very low utilization.
Another traversal scheme has been implemented, based on the quite recent optimized single-ray
traversal scheme from [AL09]. Their method separates the root-finding from the traversal. Although
warps still may diverge during traversal, they will join right after all rays have found a candidate leafnode, so that all threads will participate in the root-finding, maximizing the utilization. Listing 8.13
shows the single-ray traversal algorithm.
82
Ray Tracer subsystem
Listing 8.13: Single-ray Traversal-function
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
__device__ void traverseSingleRay (const Ray &ray , HitData & hitData )
{
if (! ray . participating () )
return;
LocalStack < MAX_STACK_DEPTH > stack ;
stack . push (0) ;
int nodeindex ;
while (true)
{
if (! traverseSingleRayNextNode (ray , hitData , nodeIndex , stack ))
return;
NURBSPatch nurbsPatch ;
nurbsPatch . surface_id = fetchSurfaceID ( nodeIndex );
nurbsPatch . span_id = fetchSpanID ( nodeIndex );
nurbsPatch . uv = fetchUV ( nodeIndex );
float2 uv_min ;
float2 uv_max ;
fetchPatchDomain ( nurbsPatch , & uv_min , & uv_max );
fetchNURBSPatch ( nurbsPatch , nodeIndex );
if ( ray . intersectAABB ( nurbsPatch . aabb , hitData .t) != INF )
rootFinder (ray , nurbsPatch , hitData );
}
}
__device__ void traverseSingleRayNextNode (const Ray &ray , HitData & hitData , int & nodeIndex ,
LocalStack & stack )
{
if ( stack . empty () ) return false;
stack . pop ( nodeIndex );
for (;;)
{
if ( IS_LEAF ( nodeIndex )) return true;
float t0 = ray . intersectAABB ( bvhNode . aabb [0] , hitData .t);
float t1 = ray . intersectAABB ( bvhNode . aabb [1] , hitData .t);
int M = ( t0 != FLOAT_INFINITY ) + 2 * ( t1 != FLOAT_INFINITY );
if (M == 3)
{
int go_left = t0 < t1 ;
stack . push ( fetchChildIndex ( nodeIndex , go_left ));
nodeIndex = fetchChildIndex ( nodeIndex , 1 - go_left );
}
else if (M == 1)
{
nodeIndex = fetchChildIndex ( nodeIndex , 0) ;
}
else if (M == 2)
{
nodeIndex = fetchChildIndex ( nodeIndex , 1) ;
}
else
{
if ( stack . empty () ) return false;
stack . pop ( nodeIndex );
}
}
}
83
8. K ERNEL DETAILS
8.5.4
Shadow-ray Casting
The castShadowRay-kernel is almost equal to the castRay-kernel, except for some simplifications.
Listing 8.14 shows the CUDA-kernel .
Ray generation
Because the shadow-ray is simply a ray originating from the light-source’s origin pointing to the
intersection-point, the construction of such a ray is rather trivial. First, the t-parameter is read from
the hitData-buffer to determine if we need to cast a shadow-ray. If it indicates a surface-point,
the corresponding surface-point and normal is read from the hitData-buffer. In order to prevent
self-intersection, the surface-point is slightly offset along the surface-normal, before the ray is constructed. If no shadow-ray needs to be cast, the ray is explicitly set to non-participating, to enable a
packet-based traversal.
Traversal
Whereas in ray casting the front-most intersection is required, in shadow-ray casting any intersection
will suffice. Consequently, the traversal can be aborted when the root-finder reports an intersection.
Nevertheless, due to the packet-based traversal, a ray must continue traversing the scene until all
rays have obtained an intersection, which is constantly checked using a parallel reduction.
Inter-kernel communication
Since the surface is unimportant, only a boolean indicating intersection or no intersection will suffice.
Therefore, very little global-memory transfers are required to update the hitdata-buffer. Infact, only
the t-parameter needs to be overwritten to indicate a non-illuminated surface-point. Because multiple
light-sources are supported, setting this t-parameter to ∞ would break the system: when casting a
shadow-ray for a second light-source, this parameter would indicate that there was no intersection
at all. Therefore, the shadow-ray caster negates the t-parameter in case of an occluder. The shader
can easily detect this value by allowing only positive values (and rejecting the value ∞). When
processing a shadow-ray, the absolute value is taken from the t-parameter, ∞ values will be skipped,
and any other values will result in casting a shadow-ray.
Finally, the shadow-ray caster is not recursive and hence does not require a stack to push rays
onto, again reducing global-memory transfers.
84
Ray Tracer subsystem
Listing 8.14: Shadow-ray Casting kernel
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
__global__ void castShadowRay ( int2 tileIdx , int stackpointer , int lightIndex )
{
:: tileIdx = tileIdx ;
HitData hitData ;
hitDataBuffer . read_t (& hitData );
if (all < BLOCKSIZE >( hitData .t == INF )) return;
Ray shadowRay ;
if ( hitData .t != FLOAT_INFINITY )
{
/* reset the t-value negated by a previous shadow-ray */
hitData .t = fabs ( hitData .t);
hitDataBuffer . read_s (& hitData );
hitDataBuffer . read_normal (& hitData );
Light light ( lightIndex );
shadowRay .o = light . pos ;
hitData .s += hitData . normal * epsilonSelfIntersection ;
shadowRay .d = hitData .s - shadowRay .o;
normalize ( shadowRay .d);
shadowRay . init () ;
hitData .t = shadowRay . distance ( hitData .s);
}
else
{
shadowRay . set_nonparticipating () ;
}
/* Traverse shadow-ray packet */
traverseShadowRay ( shadowRay , hitData );
hitDataBuffer . write_t (& hitData );
}
8.5.5
Shading
The computeShading-kernel is fairly straightforward and is really just the lighting-model written as
CUDA-code.
85
8. K ERNEL DETAILS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
__global__ void computeShading ( int2 tileIdx , int lightIndex , float4 * outputBuffer )
{
:: tileIdx = tileIdx ;
float3 color = make_float3 (0.0 f , 0.0f , 0.0 f);
HitData hitData ;
hitDataBuffer . read_t (& hitData );
if ( hitData .t == INF ) return;
hitDataBuffer . read_hitData (& hitData );
float3 L = environment . light [ lightIndex ]. position - hitData .s;
normalize (L);
float3 R = math :: reflect (L , hitData . normal );
normalize (R);
float LdotN = dot (L , hitData . normal );
float RdotV = LdotN > 0.0 f ? dot (R , hitData .d) : 0.0 f;
int material_id = MATERIAL_ID ( hitData . patch_id . surface_id );
color += hitData . opacity * sceneParameters . environment_ambient ;
color += hitData . opacity * MATERIAL_DIFFUSE ( material_id ) * max (0.0 f , LdotN );
color += hitData . opacity * MATERIAL_SPECULAR ( material_id )
* pow ( max (0.0 f , RdotV ) , MATERIAL_SHININESS ( material_id ));
outputBuffer [ SCREEN_OFFSET ] += make_float4 ( color , 1.0 f);
}
8.6
Kernel-launch configurations
It is not required for the different kernels to share the same block-size. Obviously, the packet-based
ray casting kernels should match their packet-size, since they trace their scene packet-wise. The
other kernels however, are not packet-based and therefore do not necessarily benefit from having the
same block-size as the ray casters. Furthermore, due to the lesser complexity of the generated binary
code for the Primary-ray Accelerator, the register usage is lower than the other ray casting kernels.
Therefore, a larger block-size could possibly result in a performance increase. In the results-section
of this thesis, different block-sizes are examined and a conclusion is drawn on what block-size is
ideal for which kernel (Section 9.1.2).
8.6.1
Pixel/Thread mapping
Which pixel, and consequently which rays, will be assigned to which thread depends on the chosen
block-sizes, as well as the size of the tiles. All pixels are distributed over several tiles and mapped
to a CUDA-grid. Each tile, or grid, is divided into equal-sized groups of pixels which are mapped
to a CUDA-block. Finally, each CUDA-block contains the threads executing the kernel. Figure 8.3
gives a schematic overview of the mapping for an example using an image-resolution of 16 × 16, a
tile-size of 4 × 4, and a block-size of 2 × 2.
For the kernels the mapping from pixel to thread is not very interesting. What is interesting, is
the inverse-mapping, which computes the pixel-position in image-space for a thread, based on the
threadIdx, blockIdx, and tileIdx. Using the pixel-position, the primary-ray can be setup. Also,
86
Kernel-launch configurations
Figure 8.3: Mapping of pixels to threads. This example uses an image-resolution of 16 × 16, a tilesize of 4 × 4, and a block-size of 2 × 2. The tiles are visualized using a shade of grey, the blocks are
separated by black lines, and the pixels are separated by dashed lines.
using the same indices, the offsets can be computed for data-buffer such as the image-buffer, the
hitdata-buffer, the ray-stack and, as will be seen later, the datastructures in shared-memory.
Rather trivial, the positions and offsets are given by:
tilex
= threadIdxx + blockIdxx · blockDimx
tiley
= threadIdxy + blockIdxy · blockDimy
imagex
imagey
blocko f f set
tileo f f set
imageo f f set
= tilex + tileIdxx · tileDimx
= tiley + tileIdxy · tileDimy
= threadIdxx + threadIdxy · blockDimx
= tilex + tiley · tileDimx
= imagex + imagey · imageDimx
the tileDim and imageDim variables represent the tile-size and image-size, respectively.
87
Part III
Results
89
Chapter 9
Results
In this chapter, the runtime performance of the CUDA NURBS Ray Tracing System, described in
previous chapters, will be examined. In Section 9.1, the procedure will be described how the system
is tested. Section 9.2 will discuss the impact of several parameters on the quality of the resulting
renderings. Section 9.3, will present the performance statistics, which is used to compare against
other implementations. Then, Section 9.4 will investigate where the bottleneck is located, and where
improvements might me possible. This chapter will conclude with a discussion about this system,
comparing it with existing systems, and suggesting possible improvements.
9.1
Experimental Setup
In the tests, the two different traversal algorithms are being investigated, namely packet-based traversal and single-ray traversal (described in Chapter 8). For each algorithm, a scene is rendered without
acceleration, using the standard ray tracer, and with acceleration, using the hybrid ray tracer. Finally,
every kernel is compiled and tested with caching and without caching (described in Section 8.3.1).
In total, 8 different variants will be tested: packet, packet_cache, single, single_cache, hybridpacket,
hybridpacket_cache, hybridsingle, and hybridsingle_cache. For these variants, 6 kernels are produced: accelerator, accelerator_cache, packet, packet_cache, single, and single_cache. Additionally,
each kernel will be further fine-tuned to determine a good blocksize/occupancy ratio (Section 9.1.2).
9.1.1
Testing Platforms
Two platforms have been used for obtaining the test-results. The first one is the slightly outdated
NVIDIA GeForce 8800M GTX mobile GPU. The second one is the NVIDIA GeForce GTX 295,
which has some nice improvements compared to the other. Not only is the per-multiprocessor occupancy higher due to the higher register count, but also more threads are processed physically concurrent, since the number of multiprocessors is 30 per GPU. Unfortunately, to exploit both GPUs, the
system must support SLI (Section 5.1), which it doesn’t. Table 9.1 summarizes the most important
differences between the two platforms/architectures.
9.1.2
Fine-tuning
When hand-optimizing a kernel, it is important that three goals are kept in mind: first, divergence
should be minimized by determining a good block size. Second, the occupancy should be maximized, in order to exploit the parallelism of the GPU. And third, memory latencies should be avoided
by reducing the local-memory usage.
91
9. R ESULTS
Release Date
Compute Capability
CUDA Cores
Core Clock (MHz)
Memory Clock (MHz)
Maximum Memory (MB)
Memory Interface
Mem. Bandwidth (GB/s)
GFLOPS
Operating System
CUDA Driver
CUDA Toolkit
8800M GTX
19 November 2007
1.1
96
500
800
512
256-bit
51.2
360.0
Linux: Ubuntu 9.04
2.3
2.3
GTX 295
January 8, 2009
1.3
480 (240/GPU)
576 MHz
1998 (999/GPU)
1792 (896/GPU)
896-bit (448-bit/GPU)
223.8 (111.9/GPU)
1788.48 (894.24/GPU)
Windows Vista x64
2.3
2.3
Table 9.1: Testing platforms. The entries in bold denote the statistics per GPU. Since SLI is currently
not supported, the performance is limited to only one GPU.
The block size also impacts occupancy. Although choosing a very small block size increases
coherence, it will also decrease the occupancy. For kernels with a relatively large, fixed sharedmemory use, the shared-memory will become the limiting factor. As the block size decreases, more
block will be necessary to maximize the occupancy, however this will not be possible when the total
amount of shared-memory required isn’t available. Regarding the third goal, increasing the maximum number of registers a kernel may use, will lower the local-memory usage, since too much used
registers will be spilled to the slow local-memory (which is located in global-memory). However,
when using too many registers, the occupancy (goal one) will decrease.
Therefore, a balance must be found between the block size, and the maximum number of registers. Additionally, the dimension of the block will also influence the coherence among rays. However, it looks like square-shaped blocks do not imply the maximum coherence as preliminary tests
have shown. Therefore, also the block dimension must be determined.
Determination of the best, most general options In order to determine which blockdim/maxregcountcombination is best, every reasonable combination is tried and the performance is measured for
several scenes. Per scene, the ratio of the best combination and every other combination is computed to provide a normalized performance indication for all blockdim/maxregcount-combinations.
Then, the averages are computed for each combination, which is then sorted. By choosing the
blockdim/maxregcount-combination with the highest ratio, a kernel will be generated which deviates the least from the optimum blockdim/maxrregcount for an average scene.
Chosen options Table 9.2 gives the resulting blockdim/maxregcount-combinations used in the rest
of this report. While the accelerator favors square-shaped block sizes, which is as expected since no
real divergence can occur, the other kernels do not.
9.1.3
Test scenes
Several NURBS-scenes have been used to produce the results in this chapter. Table 9.3a lists some
simple scenes containing only a few surfaces/patches. The degree varies from 1 to 5. Figure 9.1a
shows the images corresponding to the scenes.
92
Image Quality
8800M
Uncached
Cached
Accelerator
Packet
Single
Accelerator
Packet
Single
dim
16 × 8
2 × 32
1 × 64
(
16 × 8 if d < 7
16 × 4 otherwise
2 × 32
2 × 32
regs
64
32
40
occ
17%
33%
25%
GTX 295
dim
regs
32 × 8
64
1 × 64
64
1 × 64
80
occ
25%
25%
19%
64
17%
8×8
92
13%
64
64
17%
17%
1 × 64
1 × 64
86
94
13%
13%
Table 9.2: Chosen compiler-options. “dim” denotes the block dimension, “regs” denotes the maximum number of registers a kernel is allowed to use. “occ” denotes the occupancy of the kernel using
these parameters, with a maximum degree of 3.
The scenes in Table 9.3b depict some well-known scenes often used for comparison. All scenes
are of degree 3. Figure 9.1b shows the images corresponding to the scenes.
And finally, Table 9.3c shows some scenes with increasing number of patches. All scenes are of
degree 3. Figure 9.1c shows the images corresponding to the scenes.
9.2
Image Quality
This section will discuss the impact of several parameters on the quality of the resulting renderings.
9.2.1
Hybrid Artifacts
This subsection discusses some scenes rendered using the hybrid technique, of which some were
rendered correctly, and others were rendered with noticeable artifacts.
Figure 9.2 shows three renderings of the teapot scene. The left image shows the scene after it
has been processed by the accelerator. Although there are some very tiny artifacts, they are hardly
visible. Therefore, the teapot does not really require any further processing for the primary rays.
Obviously, accelerator-artifacts are related to the fineness chosen for the scene, however, it does show
that as long as no secondary rays and shadow rays are required, the accelerator alone is sufficient.
Although the teapot-scene can be rendered properly using the accelerator, other scenes cannot
be rendered without noticeable artifacts. Figure 9.3a shows three renderings of the head-scene, in
which the accelerator clearly fails to produce an artifact-free result. Apart from the “holes” in the
model, which are caused by the linear approximation having a small offset from the surface, the
model suffers from an incorrect tessellation. In this scene, not every control-point interpolates the
surface, therefore, the tessellation will be far off from the surface at the domain boundaries, since
the convex-hull is used for tessellation. Fortunately, these artifacts are all handled correctly by the
ray tracer, which fixes these erroneous pixels.
Figure 9.3b, on the other hand, shows the same scene from a different view-point. In this view, a
strange gap appears in the chin. Because the curvature of the surface around the chin is very high, the
tessellation becomes too coarse to represent a smooth surface. To represent this part of the surface,
a very high fineness would be required, which increases the size of the BVH as well. Ultimately,
the artifact will become visible again when zooming in too close. Since the rasterization provided
the accelerator the wrong surface, the ray tracer is not able to check if the accelerator converged
correctly. Therefore, the hybrid result still contains this incorrect surface.
93
9. R ESULTS
cornellbox
5
19
33
158
1-2
5776
14
5777
6452
0.13s
5.5 kB
631.8 kB
291.9 kB
100.00%
Fineness
Surfaces
Patches
Control-points
Degree
BVHNodes
BVH Depth
Quads
Vertices
Preprocessing time
NURBS data
BVH data
Tessellation data
Screen fill
head
2
4
508
969
2-5
10745
14
10746
16556
0.25s
21.0 kB
1.2 MB
685.3 kB
35.60%
ducky
2
5
124
602
2-5
11246
15
11247
13977
0.25s
15.5 kB
1.2 MB
612.5 kB
27.30%
(a) Scenes containing several surfaces.
Fineness
Surfaces
Patches
Control-points
Degree
BVHNodes
BVH Depth
Quads
Vertices
Preprocessing time
NURBS data
BVH data
Tessellation data
Screen fill
teapot
5.55
4
32
358
3
13089
15
13090
14444
0.28s
9.2 kB
1.4 MB
655.9 kB
21.16%
killeroo-lowres
1.03
89
11532
17181
3
104248
18
104249
184669
2.76s
372.1 kB
11.1 MB
7.23 MB
14.10%
killeroo-highres
0.79
89
46128
56625
3
130952
18
130953
330891
3.98s
1.1 MB
14.0 MB
12.1 MB
14.10%
killeroo-closeup
0.79
89
46128
56625
3
130952
18
130953
330891
3.98s
1.1 MB
14.0 MB
12.1 MB
92.30%
(b) Benchmark scenes for comparison with other systems.
Fineness
Surfaces
Patches
Control-points
Degree
BVHNodes
BVH Depth
Quads
Vertices
Preprocessing time
NURBS data
BVH data
Tessellation data
Screen fill
94
teapot-13
5.55
4
32
358
3
13089
15
13090
14444
0.28s
9.2 kB
1.4 MB
655.9 kB
28.50%
teapot-23
5.55
32
256
2864
3
104719
18
104720
115552
2.52s
72.9 kB
11.2 MB
5.1 MB
28.70%
teapot-33
5.55
108
864
9666
3
353429
20
353430
389988
6.52s
245.8 kB
37.8 MB
17.3 MB
28.20%
teapot-43
5.55
256
2048
22912
3
837759
21
837760
924416
16.15s
582.6 kB
89.5 MB
41.0 MB
28.10%
(c) Scenes containing many surfaces.
Table 9.3: Test scenes used for the results.
teapot-53
5.55
500
4000
44750
3
1636249
22
1636250
1805500
32.28s
1.1 MB
174.8 MB
80.1 MB
28.60%
Image Quality
(a) Scenes containing several surfaces. From left to right: cornellbox, head,
ducky.
(b) Benchmark scenes for comparison with other systems. From left to right: teapot, killeroo-lowres,
killeroo-highres, killeroo-closeup.
(c) Scenes containing many surfaces. From left to right: teapot-1x1x1, teapot-2x2x2, teapot-3x3x3, teapot-4x4x4, teapot-5x5x5.
Figure 9.1: Test scenes used.
Figure 9.2: teapot-scene: accelerator (left), full hybrid (middle), standard ray traced (right)
95
9. R ESULTS
(a) Fixable artifact in the head-scene: accelerator-only (left), hybrid (middle), ray traced reference (right).
(b) Non-fixable artifact in the head-scene: accelerator-only (left), hybrid (middle), ray traced reference (right)
Figure 9.3: head-scene
Figure 9.4: This image shows a close-up of the ducky-scene: hybrid (left), and normally ray traced
(right). It seems that the hybrid method can sometimes introduce artifacts, when zooming in too
close.
96
Performance
min. #iterations
3
2
1
0
Frame rate (FPS)
2.2
2.5
2.6
1.9
Quality of result
Correct
Few holes
Small holes
Long Gaps
Table 9.4: Different epsilon values.
Figure 9.5: Killeroo-closeup-scene rendering with a increasing miniterations-value. The images
correspond to the miniterations-values in Table 9.4.
Zooming in on the eye in Figure 9.4 will reveal the tessellation, which is not fixable using hybrid
ray tracing. Nevertheless, when viewed from some distance, the hybrid result appears correct.
9.2.2
Min-iterations switch
Sometimes, the root-finder may incorrectly return a miss, for example if the iteration jumps out of
the patch’s domain. However, sometimes this already happens during the first iteration. Usually,
it’s only the first iteration that tends to have a somewhat larger uv-increment, therefore, the system
includes an extra parameter, which pushes the uv-parameter back into the patch’s domain as long as
the minimum number of iterations has not yet been reached.
Although less iterations should be preferred, it seems to increase performance a bit when specifying a minimum of one iteration.
9.3
Performance
In this section the performance of the ray tracing system will be examined. The different variants
will be investigated to determine which variant performs the best on average. Finally, the system
will be compared against existing NURBS ray tracing systems.
9.3.1
Primary Rays
As can be seen clearly from Table 9.5 and Table 9.6, as well as Table 9.7, the single-ray variant
almost always outperforms the packet-based variant, using both architectures. What’s interesting,
is that the uncached version of the single-ray variant is not much slower than its cached brother,
which is only about 14-17% faster on average (Figure 9.6). On the GTX 295 architecture however,
it is actually faster without the cache (for standard ray tracing). On the other hand, the packet-based
variant does benefit from the cache, increasing the average performance with 30-53% for 8800M
and 27-37% for GTX 295.
97
9. R ESULTS
Scene
cornellbox
cached
ducky
cached
head
cached
Standard (ms)
Packet Single
163.89 129.13
27.90
21.06
116.26 117.44
20.84
23.73
449.43 288.38
89.44
47.42
260.20 240.77
71.88
49.76
517.43 406.29
112.22 67.52
291.03 309.22
82.94
63.71
Accelerator
0.91+16.75
0.84+4.71
0.91+14.21
0.84+3.94
0.95+31.25
0.87+6.86
0.95+26.28
0.87+6.29
2.11+44.17
0.89+8.89
2.11+36.96
0.89+8.05
Hybrid (ms)
Packet/Total
22.36/40.02
4.64/10.20
16.42/31.54
4.11/8.90
265.66/297.86
50.19/57.92
169.63/196.87
30.93/38.09
345.66/391.94
81.26/91.05
224.68/263.76
49.88/58.82
Single/Total
28.28/45.94
5.05/10.61
20.34/35.46
4.99/9.77
231.65/263.86
44.98/52.71
223.94/251.18
37.93/45.09
323.85/370.13
62.77/72.56
261.91/300.98
49.91/58.85
Table 9.5: Timings in milliseconds for the primary rays of some small scenes per variant. The
hybrid section shows two durations: the first one denotes the duration for tracing rays which were
missed during acceleration. The second duration denotes the total duration for hybrid ray tracing
(acceleration+ray tracing). The accelerator is separated into rasterization+acceleration. The bold
items are the timings from the GTX 295 test-system, the other timings are from the 8800M testsystem.
This suggests that the majority of execution-time is spent somewhere else, where the use of cache
is not possible. In Section 9.4 the variants will be investigated more thoroughly.
9.3.2
Secondary Rays
Observing the diagrams in Figure 9.7, Figure 9.8, and Figure 9.9, it becomes clear that for secondary
rays, the single-ray variant is again superior to the packet-based variant. While the diagrams for
shadow-rays show that the use of cache is even more beneficial in the case of the 8800M test-system,
all other diagrams suggest there is little advantage in using the cached variant above the uncached.
This is generally a good sign, as future architectures may allow more threads to run concurrently.
In order to maximize the occupancy, the shared-memory use should be kept to a minimum. In this
case, no cache would be used, hence this cannot become a limiting factor.
9.3.3
Scene size
A first look at the results of the massive teapot scenes (Table 9.7) reveals a logarithmic relation
between the number of BVH-nodes in a scene and the time to render (Figure 9.10 and Figure 9.11).
Although this is characteristic for ray tracing systems in general, the results of the killeroo-models
(Table 9.6) seem to suggest that the performance of the ray tracing system is not directly related to
the number of BVH-nodes. The high-resolution model, which contains a lot more control-points and
BVH-nodes, does not perform worse than the low-resolution model; sometimes it even outperforms
the low-resolution model. This might be explained by the fact that the increase in the number of
BVH-nodes does not create a new level in the BVH. However, it does create smaller leaf-nodes,
decreasing the number of intersection-tests returning a miss.
When comparing the durations of the accelerator for the low-resolution and the high-resolution
killeroo-model scenes, as well as the massive teapot scenes, it becomes clear that the number of
98
Performance
Scene
teapot
cached
killeroo-lowres
cached
killeroo-highres
cached
killeroo-closeup
cached
Standard (ms)
Packet Single
231.57 142.96
60.53
34.76
140.89 117.75
40.31
35.78
727.55 245.16
120.16 41.41
451.56 206.45
81.26
45.37
809.36 229.85
120.60 41.58
499.88 191.16
85.00
42.85
324.34 326.97
61.39
44.88
227.17 253.88
45.74
47.69
Accelerator
0.86+19.25
0.85+5.28
0.86+14.83
0.85+4.85
4.68+22.19
1.82+5.96
4.68+17.20
1.82+6.10
7.09+23.21
4.90+6.13
7.09+17.85
4.90+5.83
9.47+58.37
4.91+11.01
9.47+43.43
4.91+8.30
Hybrid (ms)
Packet/Total
121.29/141.40
32.88/39.01
92.25/107.93
21.49/27.19
206.60/233.46
41.26/49.04
165.47/187.35
28.23/36.15
231.71/262.00
41.56/52.58
169.37/194.30
30.44/41.16
168.00/235.84
32.77/48.69
139.63/192.53
28.59/41.80
Single/Total
129.17/149.28
30.43/36.55
106.99/122.67
25.03/30.73
198.97/225.84
35.12/42.90
169.29/191.17
31.29/39.20
194.05/224.35
35.43/46.45
156.62/181.55
30.62/41.35
190.09/257.93
30.11/46.03
165.26/218.16
27.33/40.53
Table 9.6: Timings in milliseconds for the primary rays of the benchmark-scenes per variant. The
hybrid section shows two durations: the first one denotes the duration for tracing rays which were
missed during acceleration. The second duration denotes the total duration for hybrid ray tracing
(acceleration+ray tracing). The accelerator is separated into rasterization+acceleration. The bold
items are the timings from the GTX 295 test-system, the other timings are from the 8800M testsystem.
Packet
Single
Packet
Single
3.0
2.0
2.5
1.5
2.0
3.02´
1.5
2.40´
2.11´
1.0
2.32´
2.79´
2.18´
2.06´
1.0
1.92´
2.38´
1.72´
1.82´
2.02´
1.37´
1.53´
0.5 1.00´
0.5 1.00´
Standard
Uncached
Standard
Cached
Hybrid
Uncached
(a) 8800M
Hybrid
Cached
Standard
Uncached
Standard
Cached
Hybrid
Uncached
Hybrid
Cached
(b) GTX 295
Figure 9.6: Average speedup of primary rays w.r.t. reference implementation (packet-based, no
caching, no acceleration).
99
9. R ESULTS
Packet
Single
Packet
2.0
2.5
2.0
1.5
1.5
2.85´
1.0
2.24´
2.18´
1.0
1.94´
1.25´
1.58´
0.5
0.5
Single
1.00´
1.00´
Standard
Uncached
Standard
Cached
Standard
Uncached
(a) 8800M
Standard
Cached
(b) GTX 295
Figure 9.7: Average speedup of shadow rays (level 0) w.r.t. reference implementation (packet-based,
no caching).
Packet
Single
Packet
Single
2.5
2.0
2.0
1.5
1.5
2.36´
2.22´
1.0
2.69´
2.59´
1.0
1.27´
0.5
1.40´
1.00´
0.5
Standard
Uncached
Standard
Cached
(a) 8800M
1.00´
Standard
Uncached
Standard
Cached
(b) GTX 295
Figure 9.8: Average speedup of reflection rays (level 1) w.r.t. reference implementation (packetbased, no caching).
100
Performance
Packet
Single
Packet
2.5
2.5
2.0
2.0
1.5
2.83´
2.74´
1.0
1.5
2.93´
2.66´
1.0
1.29´
0.5
Single
1.00´
0.5
Standard
Uncached
1.27´
1.00´
Standard
Cached
Standard
Uncached
(a) 8800M
Standard
Cached
(b) GTX 295
Figure 9.9: Average speedup of refraction rays (level 1) w.r.t. reference implementation (packetbased, no caching).
Scene
teapot-1x1x1
cached
teapot-2x2x2
cached
teapot-3x3x3
cached
teapot-4x4x4
cached
teapot-5x5x5
cached
Standard (ms)
Packet
Single
276.02 197.52
54.23
30.98
161.62 148.36
36.42
32.59
497.88 250.74
82.14
41.74
317.40 220.85
56.35
44.96
698.79 292.41
100.92
46.78
505.26 277.16
80.88
52.37
925.00 348.83
128.80
58.36
654.11 345.03
98.98
62.14
1037.69 350.81
161.27
57.39
798.94 348.87
125.80
68.86
Accelerator
0.89+17.77
0.87+5.52
0.89+13.36
0.87+5.55
4.66+26.31
1.67+5.70
4.66+19.74
1.67+4.92
12.46+25.25
9.41+5.48
12.46+19.11
9.41+4.83
28.17+26.53
39.68+6.35
28.17+20.89
39.68+6.97
43.94+27.05
89.45+8.27
43.94+20.95
89.45+8.54
Hybrid (ms)
Packet/Total
143.13/161.79
27.00/33.39
81.49/95.74
19.13/25.54
209.74/240.71
38.21/45.59
150.71/175.12
29.83/36.42
279.60/317.31
41.31/56.19
193.85/225.43
36.93/51.16
343.61/398.30
51.11/97.13
276.56/325.61
45.36/92.01
298.20/369.19
56.73/154.45
270.19/335.08
59.35/157.34
Single/Total
165.68/184.34
28.63/35.01
116.45/130.70
24.85/31.26
225.97/256.94
37.91/45.28
192.33/216.74
36.27/42.86
263.72/301.42
41.76/56.64
229.09/260.67
40.69/54.93
287.33/342.02
53.39/99.42
268.93/317.99
43.01/89.66
287.21/358.20
47.17/144.89
274.00/338.89
48.88/146.87
Table 9.7: Timings in milliseconds for the primary rays of the large scenes per variant. The hybrid
section shows two durations: the first one denotes the duration for tracing rays which were missed
during acceleration. The second duration denotes the total duration for hybrid ray tracing (acceleration+ray tracing). The accelerator is separated into rasterization+acceleration. The bold items are
the timings from the GTX 295 test-system, the other timings are from the 8800M test-system.
101
9. R ESULTS
800
340
æ
300
æ
300
800
æ
600
æ
700
280
æ
250
æ
500
260
600
æ
æ
500
400
240
æ
200
æ
1.0 ´ 106
500 000
æ
æ
1.5 ´ 106
æ
300
220
400
æ
æ
æ
700
320
900
350
æ
æ
æ
1000
1.0 ´ 106
500 000
(a) packet, nocache
1.5 ´ 106
1.0 ´ 106
500 000
æ
(b) single, nocache
1.5 ´ 106
1.0 ´ 106
500 000
(c) packet, cached
1.5 ´ 106
(d) single, cached
Figure 9.10: Durations of the variants using the 8800M test-system, as a function of the number of
patches. The red line shows the curve corresponding to a logarithmic function fitted to the data.
æ
æ
æ
160
æ
æ
120
65
55
æ
140
100
50
æ
120
60
æ
55
æ
æ
45
æ
80
50
æ
100
æ
45
40
60
æ
80
æ
æ
40
500 000
æ
500 000
1.0 ´ 10
6
1.5 ´ 10
(a) packet, nocache
6
1.0 ´ 106
1.5 ´ 106
æ
æ
(b) single, nocache
500 000
1.0 ´ 106
1.5 ´ 106
(c) packet, cached
æ
500 000
1.0 ´ 106
(d) single, cached
Figure 9.11: Durations of the variants using the GTX 295 test-system, as a function of the number
of patches. The red line shows the curve corresponding to a logarithmic function fitted to the data.
Direct evaluation
Division-free evaluation
Teapot
4.9
4.7
Killeroo-highres
4.5
4.3
Head
3.0
2.8
Table 9.8: Performance in FPS for different evaluation methods. The results were obtained using the
cached single-ray ray tracer on the 8800M test system.
control-points in a scene or the number of patches does not influence the performance at all, which
is actually quite obvious, since each pixel contains up to one patch to find a root. The rasterization however, is influenced by the number of patches, since it’s linear in the number of sub-patches.
Therefore, the performance is independent on the number of control-points as long as the rasterization is fast enough. An interesting detail, is that starting with the teapot-3x3x3 scene, the GTX
295-test-system using the standard uncached single-ray variant begins to outperform every other
hybrid variant. Starting with the teapot-5x5x5 scene, it even outperforms the rasterization phase,
making the hybrid approach obsolete. However, I doubt the maximum rasterization throughput has
really been reached, since that part was not fully optimized yet, especially since the 8800M should
perform worse.
9.3.4
Surface-Evaluation Scheme
As it turned out, the direct evaluation method in slightly faster than the division-free evaluation
method, which is clearly visible in Table 9.8.
102
1.5 ´ 106
Performance
Scene
cornellbox
head
ducky
teapot
killeroo-lowres
killeroo-highres
killeroo-closeup
teapot-1x1x1
teapot-2x2x2
teapot-3x3x3
teapot-4x4x4
teapot-5x5x5
P
7.5/34.6
3.1/13.2
4.0/18.3
5.4/24.5
4.6/20.5
4.9/20.5
3.7/19.2
5.5/28.2
4.3/21.4
3.5/18.7
2.8/15.4
2.8/15.5
Standard
P+S
3.0/16.7
2.0/8.7
2.6/11.6
3.5/17.3
3.0/13.6
2.2/13.4
2.9/12.4
4.2/20.5
1.8/14.7
1.7/12.2
3.0/10.0
2.9/10.1
P+S+1
1.8/10.1
0.7/3.2
1.0/4.9
1.3/6.5
1.0/4.9
0.5/5.0
1.0/2.9
1.6/8.0
0.6/4.8
0.6/3.8
1.8/3.2
1.7/3.2
Hybrid
P
26.0/59.8
4.8/15.0
6.5/22.0
8.7/30.1
6.6/23.0
6.2/20.7
5.9/20.4
9.0/33.3
6.6/24.1
5.1/17.2
3.9/10.2
2.2/6.1
Table 9.9: Overview of the performance of the ray tracing system. The numbers represent the
performance in frames per second. P denotes the primary rays, S denotes the shadow rays (level 0),
and 1 denotes the level-1 secondary rays (reflection+refraction+shadow). The bold entries denote
the frame rates for the GTX 295 test-platform.
9.3.5
Preferred variant
Based on the observations in the previous subsections, Table 9.9 gives an overview of the performance data of the system using the overall-best variants. In here, the single-ray implementation
using the cache has been selected as the preferred variant for standard ray tracing on the 8800M test
platform, and the uncached version on the GTX 295 platform. For hybrid ray casting, the cached
version of the packet-based implementation has been selected, for both test platforms.
9.3.6
Comparison
Table 9.10 and Table 9.11 give a comparison with two other existing CPU-based direct NURBS ray
tracing systems, described in [AGM06, ABS08]. Both systems implement the division-free evaluation method described in Section 3.5.3, and employ a packet-based scheme for scene-traversal. In
addition, the system described in [ABS08] implements the hybrid method described in Section 4.2.2
and has a variant which uses 8 cores in parallel. Both systems use SIMD to execute 4 rays in parallel,
per core. The performance of the 8800M test platform seems to outperform the single-core variants
of the systems. Although the frame rate of the teapot-scene of the system described in [AGM06]
is much higher than in [ABS08], the frame rate for the high-resolution killeroo scene is the same.
Furthermore, the impact of the number of patches, as well as the screenfill is much higher for the
CPU-based systems, than for the GPU-based system (CNRTS), suggesting the system is better suited
for massive models.
The GTX 295 platform performs much better, with a speedup of 4-5×. However, the CPU-based
ray tracing system is still much faster when using 8 cores, although the frame rate is not much higher
for the killeroo-scene. For hybrid ray tracing, the ID-processing variant of the CPU-based ray tracing
system is much faster than the GPU-based system, while the uv-processing variant is comparable.
103
9. R ESULTS
CNRTS
Scene
teapot
killeroo-lowres
killeroo-highres
killeroo-closeup
5.0/24.5
4.6/20.5
4.9/20.5
3.7/19.2
[AGM06]
1 core
7.2
3.8
3.3
1.5
[ABS08] (Standard)
1 core
8 cores
5.2
34.2
3.3
22.4
-
Table 9.10: Primary-ray frame rate comparison of several existing systems for standard NURBS ray
tracing. The bold entries denote the frame rates of the GTX 295 test platform. The selected variants,
are the single-ray cached variant for the 8800M platform, and the single-ray uncached variant for
the GTX 295 platform.
CNRTS
1 core
Scene
teapot
killeroo-lowres
killeroo-highres
killeroo-closeup
9.0/30.1
6.6/23.0
6.2/20.7
5.9/20.4
8.0
5.9
-
[ABS08] (Hybrid)
8 cores
ID-processing u/v-processing
41.7
25.5
30.8
22.1
-
Table 9.11: Primary-ray frame rate comparison of several existing systems for hybrid NURBS ray
tracing. The bold entries denote the frame rates of the GTX 295 test platform. The selected variant,
for both platforms, is the packet-based cached variant.
(a) Packet-based
(b) Single-ray
Figure 9.12: Number of BVH-nodes visited.
9.4
Analysis
In this section, the variants are compared and analyzed to identify areas with room for improvement.
9.4.1
Traversal
The total number of BVH-nodes visited by each ray during traversal, is different for each variant.
Figure 9.12 gives a visualization which compares the number of nodes visited per ray for the teapotscene. It’s clear that each ray in the same packet visits the same number of nodes. Also, Figure 9.12b
indicates that the maximum number of visited nodes using the single-ray variant is much smaller than
the packet-based variant.
104
Analysis
cornellbox
head
ducky
teapot
killeroo-lowres
killeroo-highres
killeroo-closeup
teapot-1x1x1
teapot-2x2x2
teapot-3x3x3
teapot-4x4x4
teapot-5x5x5
Single
14.6M (181.2k)
4.2M (1.5M)
2.9M (943.7k)
2.6M (1.1M)
2.2M (932.2k)
2.2M (952.0k)
8.3M (602.1k)
2.9M (1.2M)
3.6M (1.4M)
4.6M (1.8M)
4.3M (1.5M)
5.9M (2.3M)
Packet
19.6M (181.3k)
9.9M (2.7M)
8.5M (1.9M)
7.8M (2.1M)
14.1M (2.6M)
15.3M (2.7M)
12.9M (902.8k)
6.8M (2.3M)
14.1M (3.4M)
25.7M (4.3M)
34.6M (5.1M)
51.0M (6.3M)
Table 9.12: Total number of visited BVH nodes for every scene. The numbers between curly brackets
denote the number of visited nodes when using hybrid ray tracing.
Table 9.12 lists the cumulative number of visited nodes for each scene, comparing the singleray variant and the packet-based variant, as well as their hybrid versions. It is evident, that for every
scene, the packet-based variant visits a lot more nodes than the single-ray variant. Note that zooming
in on a model, reduces the number of visits for the packet-based variant (compare killeroo-highres
and killeroo-closeup). This is of course caused by the fact that zooming in on the model, will enlarge
the bounding-boxes from the packet’s perspective. Consequently, less surface-area of the boundingbox will be intersected by the packet’s volume, resulting in fewer intersected nodes. Although the
screenfill is higher, it turns out to be more efficient for packet-based traversal (observe the smaller
execution time in Table 9.6). The single-ray variant on the other hand, requires much more node
visits for the close-up scene.
Also observe, that for increasing BVHs (teapot-scenes), the number of visited nodes for the
packet-based variant increases rapidly w.r.t. the single-ray variant. This is easily explained by the
fact that the increase in number of nodes in the hierarchy, combined with the same screenfill used
(zoomed to fit the screen), will shrink the size of the bounding-boxes, again from the perspective of
the rays. Therefore, the opposite is expected of zooming in on the scene, namely, that the number of
visited nodes increases. This is confirmed by the table.
9.4.2
Root-finding
Table 9.13 shows statistics about the root-finder. Although the number of visited nodes is much larger
for the packet-based variant, than the single-ray variant, the total number of intersection tests and
iterations is roughly the same. This is caused by the extra Ray-AABB intersection test performed
just before the root-finder stage. However, the execution times per iteration actually differ a lot.
Although both variants use caching to keep the computed basis-functions, the packet-based variant
performs much better.
First, during a root-finding call, every ray in the packet, when participating in the root-finding,
will test against the same surface-patch. Therefore, the data-coherence will be perfect: each thread
requires the exact same data. Moreover, since the data is first transferred to the shared-memory,
which acts again as a software-managed cache, the memory-latencies will be completely hidden.
The single-ray variant will fetch its data through the texture-unit. Although this will be cached
as well, it proves to be more efficient to put it into shared-memory. Furthermore, since the rays may
105
9. R ESULTS
Packet
Single
Accelerator
Packet (Hybrid)
Single (Hybrid)
Intersection tests
Cumulative
123,042
119,408
55,382
16,790 (72,172)
16,745 (72,127)
Iterations
Cumulative Average
313,993
2.6
304,833
2.6
92,201
1.7
44,049
2.6
43,923
2.6
Newton-iteration
Cumulative Average
9.0 · 109
28,589
22.6 · 109
74,210
9
1.1 · 10
12,328
1.3 · 109
29,749
3.0 · 109
68,060
Table 9.13: Root-finder statistics for the teapot-scene (cached). The Newton-iteration numbers denote durations in GPU clock-cycles.
fetch different surface-patches, the memory-coherence will be much less than the packet-based variant. Also, because the data may be scattered in the texture, fetches will result in uncoalesced accesses
the first time, which is very inefficient. The packet-based variant even has one extra advantage, in
that the data will be fetched coalesced by all threads cooperatively.
Unfortunately, for the packet-based variant, the single-ray variant will eventually win for other
reasons, which will be investigated in the next subsection.
9.4.3
Utilization
Apart from root-finding being a very expensive computation, a poor utilization of the multiprocessors
will make it perform even worse. Ideally, all cores of a multiprocessor should be executing, to reach
the full potential. However, this is not always the case. During packet-based traversal, some rays may
intersect a leaf-node, and others do not, in which case only a subset of the packet will be participating
in the root-finding. The other cores are shut-down for a moment, until every ray’s root-finder-call
has finished executing, after which all rays in the packet continue their execution. Generally, the
utilization refers to that of a warp. However, since we are traversing packet-wise, the utilization now
covers all warps in the packet. In the worst case, if only one ray is active, the entire packet will be
blocked until that ray is done. Unfortunately, this is the price we have to pay for the advantage of
having a fast shared-stack and a very efficient node/patch fetch implementation. Figure 9.13a shows
a visualization of the total idle-time per pixel for the teapot-scene rendered using the packet-based
variant (using caching). As can be seen, a large portion of the execution-time the threads are idle.
This is the major reason for the packet-based traversal for being rather slow, regarding the brute
horsepower of the GPU.
The single-ray variant on the other hand, does not suffer from these restrictions, since the traversal happens separately. As a consequence, during the root-finding phase, all rays will be active (apart
from the rays which did not intersect a leaf-node), maximizing the multiprocessor’s utilization. However, some rays may finish earlier (either successful or not) than some other rays in the same warp,
which causes the already finished rays will have to wait for the entire warp to finish. Therefore,
also the single-ray variant suffers from some under-utilization. Although this under-utilization is restricted to only one warp and will not affect other warps. Finally, rays in the single-ray variant may
have already traversed the entire BVH, while other threads in the same warp are still busy. Note, that
this will never occur using the packet-based variant, where idle-time is caused by a minority of rays
intersecting a leaf-node. Figure 9.13b gives a visualization of this idle-time. Finally, Figure 9.14
shows a histogram of the average utilization during root-finding. The image clearly shows that most
of the time, only a very small subset of rays is active, which causes the high idle-time in the other
image.
106
Analysis
(a) Packet-based (Cached)
(b) Single-ray (Cached)
(c) Packet-based (Hybrid+Cached)
(d) Single-ray (Hybrid+Cached)
Figure 9.13: Amount of time spent idle of total durations for each thread.
107
9. R ESULTS
8000
6000
4000
2000
0
5
10
15
20
25
30
35
Figure 9.14: Frequencies of the average number of rays participating in the root-finding.
9.4.4
Low-level Profiling
An easy way to obtain statistics about running CUDA-kernels, is by enabling the CUDA-profiler.
Running CUDA-applications will then automatically generate a log-file containing low-level information for each kernel-launch. Among these measurements are: running time for a kernel, occupancy, number of divergent branching warps, etc. By using the CUDA-profiler, some insight may be
gained about kernels, and why some perform less than expected.
Branching warps
Table 9.14 lists the collected information about main kernel for each variant based on the rendering
of the teapot-scene. A high difference in the number of warp-branches is revealed, which is caused
by the difference in traversal of each variant. When traversing the BVH packet-based, the set of
visited nodes is the union of the set of nodes which would be visited when traversing each ray
separately. Therefore, much more nodes will be visited in the packet-based variant than the singleray variant, depending on the coherence of the rays in the packet. The coherence is likely to drop,
due to the much larger packets (64 rays). The possibility that rays will hit different BVH-nodes will
therefore be much larger than when using smaller packets such as 2x2 packets which is usually the
case ([AGM06, ABS08]). Because each extra visited node requires an extra traversal step, extra code
will be executed, resulting in more branches. The difference in the number of instructions executed
confirms this.
The difference in the number of branching warps between the single-ray variants is explained by
the fact that their block-sizes differ. Therefore, threads will execute differently depending on their
corresponding rays.
Diverging warps
During packet-based traversal, most branches never will be divergent, because the entire packet
decides the order of traversal, causing the entire warp to follow the same execution path. However,
there will always be branches which will cause divergence. Some rays for example, may take longer
to find an intersection while root-finding, causing the warp to diverge, leading to warp serialization
(which is confirmed by the table). Additionally, rays may skip the root-finder entirely, if it misses
the sub-patch’s bounding-box.
The single-ray variant on the other hand, does not share a common traversal path, and therefore
may diverge during traversal. Since the traversal is separated from the root-finder, the divergence is
kept to a minimum. Nevertheless, it is still larger than the packet-based variant.
108
Discussion
GPUTime (ms)
occupancy (%)
branching warps
divergent warps
instructions +/warp serialize
local load
local store
Nocache
Packet
Single
308
216
33
25
1.189.939
664.956
36.775
45.486
9.6M
6.9M
780k
21k
1.591.277 1.431.112
4.253.364 5.066.636
Cache
Packet
Single
190
168
17
17
1.189.939 527.565
36.775
35.816
9.4M
5.4M
820k
19k
4.574
67.343
40.152
320.800
Table 9.14: CUDA profiling data for the CNRTS-kernels (based on the teapot-scene).
Warp serialization
Whereas the number of divergent warps of the single-ray variant (uncached) is much higher than
for packet-based, the number of warp serializes is a lot smaller (37×). Warp serialization is caused
by bank-conflicts to either the shared-memory or the constant memory. Since the number of visited
nodes for packet-based is larger, this number will be larger.
Local-memory accesses
The effect of using cache is very evident in the table. The number of local loads/stores is heavily
reduced for the cached variants, which is obvious since the caches avoid local memory transfers.
9.5
Discussion
Standard Ray Tracing Although nowadays packet-based ray tracing is considered to be the preferred way of ray tracing on CPU-architectures (and actually also on GPU-architectures), the singleray implementation seems to perform much better on GPU. At first, the rather large packet-size,
enforced by the 32-wide SIMD-architecture, causes the packets to be less coherent compared to
CPU-implementations. On the CPU, these packets are usually much smaller, since the SIMD-width
is 4. As a consequence, the overall efficiency will be much lower on GPU, as less rays will participate
in the root-finding.
While a naive single-ray implementation will suffer heavily from ray divergence, the implementation used in here tries to avoid these under-utilization problems as much as possible. By separating
the traversal from the root-finder, the divergence only affects the traversal stage. Under-utilization
occurs only if some rays belonging to a warp have not yet returned, either successful or unsuccessful. As soon as all rays return, the warp enters the root-finding stage, in which each ray will try to
find an intersection (except those for which no leaf-node was found during traversal). Therefore, the
utilization during root-finding, which is the most expensive operation in the system, in much higher
than the packet-based implementation.
Hybrid Ray Tracing Although the accelerator phase is very fast, the additional ray tracing phase
necessary to fix the small number of artifacts, takes up the majority of the total hybrid rendering
time (Table 9.5, Table 9.6). Therefore, the benefit of using a GPU/CPU-hybrid is rather low and less
than expected. Looking at the processing time required to fix the relatively small amount of pixels, it
seems that the system does not scale very well over the number of rays. For highly complex scenes,
hybrid ray tracing becomes actually slower than standard ray tracing (Table 9.7).
109
9. R ESULTS
Furthermore, not always the same quality is guaranteed as standard ray tracing. Some artifacts
may appear, due to wrong tessellations, which cannot be handled by the ray tracer (Figure 9.3b).
However, because the total number of pixels that require a repair is generally very low, the
accelerator could act as a very fast “low-detail” method to navigate through the scene.
Caching While the use of a cache does improve the performance of the 8800M architecture, it
is less obvious for the GTX 295 architecture. For the primary rays, using standard single-ray tracing, the use of cache even decreases performance a little (Figure 9.6). However, for shadow- and
secondary-rays, the speedup becomes more apparent (Figure 9.7, Figure 9.8, and Figure 9.9).
Although the difference is not that big for the GTX 295 architecture, it shows there is some
improvement when using a cache. Furthermore, since the cache is implemented using the sharedmemory, the occupancy is lowered, suggesting that the performance increase would be much bigger
when the same occupancy could be maintained.
The upcoming Fermi architecture has an hierarchical caching system built-in. This would make
the software-managed cache obsolete. Nevertheless, for “older” architectures, the cache proves to
be worthwhile.
Basis-function evaluation Although [AGM06] presented their method as the best performing
evaluation scheme on SIMD-architectures, using CUDA their division-free basis-function evaluation method perform slightly worse than the direct evaluation-method described in [PT97]. Since
a lot of preprocessed data needs to be fetched to evaluate a set of basis-functions, the advantage of
not having to compute a division diminishes, whereas the direct evaluation-method only requires
the knot-vector data. Therefore, the advantage of using the division-free method above the direct
evaluation-method is very small.
Preprocessing Although the focus of this thesis was not on efficient ways to generate BVHs, the
timings in Table 9.3 show that the preprocessing time is usually under a second up to a few seconds
for moderately complex scenes, which is not very high. Nevertheless, this might be improved even
further by generating the BVH on the GPU also.
Supported scenes Table 9.3 shows that the system is capable of ray tracing scenes containing
4000 patches. Obviously, more complex scenes are supported which is only limited by the available
GPU-memory.
The maximum degree the system can handle is limited by the available shared-memory. When
using the uncached variant, virtually any degree is supported. Of course, the intersection-time will
increase also.
Time-complexity While standard rasterization is linear in the number of objects, ray tracing isn’t.
Table 9.7, together with Figure 9.10 and Figure 9.11 clearly show a logarithmic increase in rendering
time, in which the single-ray implementations appear to converge to a constant rendering time.
The linear nature of the rasterization algorithm becomes apparent in the hybrid ray tracing results
in Table 9.7. It can be seen that the rasterization time increases much faster than the ray trace time.
However, eventually, the rasterization time will be too high, making it unusable for interactive ray
tracing.
110
Chapter 10
Conclusions and Future Work
Ray Tracing is by no doubt a very expensive algorithm. For regular planar primitives, such as triangles, quadrilaterals, polygons, etc. the difficulty generally lies in the traversal of the acceleration
datastructure, since computing an intersection between a ray and a primitive is computationally
cheap to implement. However, when ray tracing NURBS-surfaces, the bottleneck has shifted to the
intersection computation, which is very expensive to compute. Furthermore, due to the incoherent nature of the ray tracing algorithm, it is very difficult to provide the GPU with homogeneous
workloads since rays may take longer to compute.
In this thesis we have presented a system capable of ray tracing NURBS-surfaces with shadows,
reflections, and refractions up to any depth, and fully implemented on the GPU using CUDA. By
separating the traversal from the root-finder, a single-ray implementation was able to outperform the
generally-preferred packet-based implementation.
Contrary to the common believe that GPUs are not suitable for ray tracing, due to their streaming
SIMD-architecture, the results suggest the crossing-point is being reached between CPUs versus
GPUs, in favor of GPUs. Although the system currently does not yet outperform the 8-core CPUimplementation from [ABS08], it does leave the 1-core implementation far behind. And the long
idle-times suggest that there is plenty of room for improvement.
Although using a hybrid approach increases performance, it does not perform as expected. Looking at the processing time required to fix the relatively small amount of pixels, it seems that the
system does not scale very well over the number of rays. Because artifacts may remain, and rasterization times can become larger than standard ray tracing, it is doubtful that hybrid ray tracing will
remain beneficial in the future. It could act however as a very fast “low-detail” method to navigate
through the scene.
10.1
Future Work
Trimming Although the system is able to ray trace virtually any NURBS-model, it does not yet
have support for trimming curves, which is commonly used in industries to ease the design of complex models. Without trimming curves, surfaces with holes are very difficult to model. The surface
will have to be wrapped around the hole, resulting in many patches. The availability of support for
trimming curves would therefore be a great addition to the system.
SLI Currently, the ray tracing system is limited to use only a single GPU. Therefore, the 295GTX’s
full potential is far from being reached. By adding support for multiple GPUs in an SLI configuration, the ray tracing performance can be doubled theoretically. However, since the GPUs do not
share their memory-spaces, all data needs to be uploaded twice.
111
10. C ONCLUSIONS AND F UTURE W ORK
Persistent Threads More recently, [AL09] have taken a total different approach towards ray tracing on GPUs, by using “persistent threads”. Instead of mapping each thread to a screen-pixel, they
let the threads fetch unprocessed rays from a ray-pool. If a thread finishes processing its ray, it
fetches the next ray from the pool. In this way, all threads will be kept busy, heavily increasing the
utilization.
Another benefit from this approach is, that now only rays will be processed that were spawned
previously. Currently, all pixels will be traced, but terminated rays will exit earlier. The hybrid
approach could benefit from this as well, as there are usually few rays which need to be repaired.
Fermi Last but not least, the upcoming new architecture by NVIDIA looks very promising. Apart
from the brute horsepower, it contains some nice new features, very useful for ray tracing. The builtin cache hierarchy, will automatically increase performance for much processes in the ray tracer.
The possibility to run different kernels concurrently sounds very interesting, and opens new ways to
improve today’s state of the art.
112
Bibliography
[Abe05]
O. Abert. Interactive Ray Tracing of NURBS Surfaces by Using SIMD Instructions
and the GPU in Parallel. Master’s thesis, University of Koblenz-Landau, 2005.
[ABS08]
O. Abert, M. Bröcker, and R. Spring. Accelerating Rendering of NURBS Surfaces by
Using Hybrid Ray Tracing. 2008.
[AGM06]
O. Abert, M. Geimer, and S. Muller. Direct and Fast Ray Tracing of NURBS Surfaces.
In Proc. IEEE Symposium on Interactive Ray Tracing 2006, pages 161–168, 18–20
Sept. 2006.
[AL09]
Timo Aila and Samuli Laine. Understanding the efficiency of ray traversal on gpus. In
Proceedings of the Conference on High Performance Graphics 2009, pages 145–149,
New York, NY, USA, 2009. ACM.
[BBB87]
Richard H. Bartels, John C. Beatty, and Brian A. Barsky. An introduction to splines for
use in computer graphics and geometric modeling. Morgan Kaufmann Publishers Inc.,
San Francisco, CA, USA, 1987.
[BBDF05] S. Beck, AC Bernstein, D. Danch, and B. Fröhlich. CPU-GPU Hybrid Real Time Ray
Tracing Framework. 2005.
[BBLW07] C. Benthin, S. Boulos, D. Lacewell, and I. Wald. Packet-based Ray Tracing of CatmullClark Subdivision Surfaces. Technical report, Scientific Computing and Imaging Institute, 2007.
[BM99]
W. Boehm and A. Müller. On de Casteljau’s algorithm. Computer Aided Geometric
Design, 16(7):587–605, 1999.
[CDP]
Sylvain Collange, David Defour, and David Parello. Barra, a Parallel Functional
GPGPU Simulator.
[CHH02]
N.A. Carr, J.D. Hall, and J.C. Hart. The ray engine. In Proceedings of the ACM
SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, pages 37–46. Eurographics Association Aire-la-Ville, Switzerland, Switzerland, 2002.
[CLR80]
Elaine Cohen, Tom Lyche, and Richard Riesenfeld. Discrete b-splines and subdivision techniques in computer-aided geometric design and computer graphics. Computer
Graphics and Image Processing, 14:87–111, 1980.
113
B IBLIOGRAPHY
[Cox72]
M.G. Cox. The numerical evaluation of b-splines. IMA Journal of Applied Mathematics, 10:16, 1972.
[dB72]
C. de Boor. On calculating with B-splines. J. Approx. Theory, 6(1):50–62, 1972.
[Dia09]
G. Diamos. The Design and Implementation Ocelot’s Dynamic Binary Translator from
PTX to Multi-Core x86. 2009.
[DKK09]
G. Diamos, A. Kerr, and M. Kesavan. Translating GPU binaries to tiered SIMD architectures with Ocelot. 2009.
[FR87]
R.T. Farouki and V.T. Rajan. On the numerical condition of polynomials in bernstein
form. Computer Aided Geometric Design, 4:191–216, 1987.
[FS05]
T. Foley and J. Sugerman. KD-tree acceleration structures for a GPU raytracer. In
Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graphics hardware, pages 15–22. ACM New York, NY, USA, 2005.
[GPSS07]
J. Gunther, S. Popov, H. P. Seidel, and P. Slusallek. Realtime Ray Tracing on GPU with
BVH-based Packet Traversal. In Proc. IEEE Symposium on Interactive Ray Tracing RT
’07, pages 113–118, 10–12 Sept. 2007.
[GS87]
Jeffrey Goldsmith and John Salmon. Automatic creation of object hierarchies for ray
tracing. IEEE Comput. Graph. Appl., 7:14–20, 1987.
[Hav01]
V. Havran. Heuristic Ray Shooting Algorithms. Czech Technical University. PhD thesis,
Ph. D. dissertation, 2001, 2001.
[HSHH07] D.R. Horn, J. Sugerman, M. Houston, and P. Hanrahan. Interactive kd tree GPU raytracing. In Proceedings of the 2007 symposium on Interactive 3D graphics and games,
pages 167–174. ACM Press New York, NY, USA, 2007.
[Kaj82]
J.T. Kajiya. Ray tracing parametric patches. In Proceedings of the 9th annual conference on Computer graphics and interactive techniques, pages 245–254. ACM New
York, NY, USA, 1982.
[LYTM06] C. Lauterbach, S.E. Yoon, D. Tuft, and D. Manocha. RT-DEFORM: Interactive ray
tracing of dynamic scenes using BVHs. In Proceedings of the 2006 IEEE Symposium
on Interactive Ray Tracing, pages 39–45. Citeseer, 2006.
[MB90]
J.D. MacDonald and K.S. Booth. Heuristics for ray tracing using space subdivision.
The Visual Computer, 6(3):153–166, 1990.
[MCFS00] W. Martin, E. Cohen, R. Fish, and P. Shirley. Practical Ray Tracing of Trimmed
NURBS Surfaces. JOURNAL OF GRAPHICS TOOLS, 5(1):27–52, 2000.
[OLG+ 07] J.D. Owens, D. Luebke, N. Govindaraju, M. Harris, J. Kruger, A.E. Lefohn, and T.J.
Purcell. A Survey of General-Purpose Computation on Graphics Hardware. In Computer Graphics Forum, volume 26, pages 80–113. Blackwell Synergy, 2007.
[PBMH05] T.J. Purcell, I. Buck, W.R. Mark, and P. Hanrahan. Ray tracing on programmable
graphics hardware. In International Conference on Computer Graphics and Interactive
Techniques. ACM Press New York, NY, USA, 2005.
[Pet94]
114
John W. Peterson. Tesselation of nurb surfaces. In Paul S. Heckbert, editor, Graphics
Gems IV, pages 286–320. Academic Press, 1994.
[PGSS07]
S. Popov, J. Gunther, H.P. Seidel, and P. Slusallek. Stackless KD-Tree Traversal for
High Performance GPU Ray Tracing. In Computer Graphics Forum, volume 26, pages
415–424. Blackwell Synergy, 2007.
[Pro05]
Jana Procházková. Derivative of b-spline function, 2005.
[PSS+ 06]
H. F. Pabst, J. P. Springer, A. Schollmeyer, R. Lenhardt, C. Lessig, and B. Froehlich.
Ray Casting of Trimmed NURBS Surfaces on the GPU. In Proc. IEEE Symposium on
Interactive Ray Tracing 2006, pages 151–160, 18–20 Sept. 2006.
[PT97]
L.A. Piegl and W. Tiller. The Nurbs Book. Springer, 1997.
[PTVF97]
William H. Press, Saul A. Teukolsky, William T. Vetterling, and Brian P. Flannery.
Numerical Recipes in C. CAMBRIDGE UNIVERSITY PRESS, 1997.
[TS05]
N. Thrane and LO Simonsen. A comparison of acceleration structures for GPU assisted
ray tracing. Master’s thesis, 2005.
[WBB08]
I. Wald, C. Benthin, and S. Boulos. Getting rid of packets-Efficient SIMD single-ray
traversal using multi-branching BVHs. In Interactive Ray Tracing, 2008. RT 2008.
IEEE Symposium on, pages 49–57, 2008.
[WBS07]
Ingo Wald, Solomon Boulos, and Peter Shirley. Ray tracing deformable scenes using
dynamic bounding volume hierarchies. ACM Trans. Graph., 26(1):6, 2007.
[WH80]
T. Whitted and N.J. Holmdel. An Improved Illumination Model for Shaded Display.
Communications, 1980.
[WSBW01] I. Wald, P. Slusallek, C. Benthin, and M. Wagner. Interactive Rendering with Coherent
Ray Tracing. In Computer Graphics Forum, volume 20, pages 153–165. Blackwell
Synergy, 2001.
115

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project