Graphics Reference
In-Depth Information
because they allowed amortization in different ways and provoked different mem-
ory access patterns.
Sampling is the core of physically based rendering. The kinds of design
choices you faced in this chapter echo throughout all aspects of rendering. In fact,
they are significant for all high-performance computing, spreading into fields as
diverse as biology, finance, and weather simulation. That is because many inter-
esting problems do not admit analytic solutions and must be solved by taking
discrete samples. One frequently wants to take many of those samples in paral-
lel to reduce computation latency. So considerations about how to sample over a
complex domain, which in our case was the set product of triangles and eye rays,
are fundamental to science well beyond image synthesis.
The ray tracer in this chapter is a stripped-down, no-frills ray tracer. But it
still works pretty well. Ten years ago you would have had to wait an hour for the
teapot to render. It will probably take at most a few seconds on your computer
today. This performance increase allows you to more freely experiment with the
algorithms in this chapter than people have been able to in the past. It also allows
you to exercise clearer software design and to quickly explore more sophisticated
algorithms, since you need not spend significant time on low-level optimization to
obtain reasonable rendering rates.
Despite the relatively high performance of modern machines, we still consid-
ered design choices and compromises related to the tension between abstraction
and performance. That is because there are few places where that tension is felt as
keenly in computer graphics as at the primary visibility level, and without at least
some
care our renderers would still have been unacceptably slow. This is largely
because primary visibility is driven by large constants—scene complexity and the
number of pixels—and because primary visibility is effectively the tail end of the
graphics pipeline.
Someday, machines may be fast enough that we don't have to make as many
compromises to achieve acceptable rendering rates as we do today. For example,
it would be desirable to operate at a purely algorithmic level without exposing
the internal memory layout of our
Image
class. Whether this day arrives soon
depends on both algorithmic and hardware advances. Previous hardware perfor-
mance increases have in part been due to faster clock speeds and increased dupli-
cation of parallel processing and memory units. But today's semiconductor-based
processors are incapable of running at greater clock speeds because they have
hit the limits of voltage leakage and inductive capacitance. So future speedups
will not come from higher clock rates due to better manufacturing processes on
the same substrates. Furthermore, the individual wires within today's processors
are close to one molecule in thickness, so we are near the limits of miniatur-
ization for circuits. Many graphics algorithms are today limited by communica-
tion between parallel processing units and between memory and processors. That
means that simply increasing the number of ALUs, lanes, or processing cores will
not increase performance. In fact, increased parallelism can even decrease per-
formance when runtime is dominated by communication. So we require radically
new algorithms or hardware architectures, or much more sophisticated compilers,
if we want today's performance with better abstraction.
There are of course design considerations beyond sample statistics and raw
efficiency. For example, we saw that if you're sampling really small triangles, then
micropolygons or tile rasterization seems like a good rendering strategy. However,
what if you're sampling shapes that aren't triangles and can't easily be subdivided?