i
i
i
i
i
i
i
i
Chapter 19
The Future
“Pretty soon, computers will be fast.”
—Billy Zelsnack
“Prediction is difficult, especially of the future.”
—Niels Bohr or Yogi Berra
“The best way to predict the future is to create it.”
—Alan Kay
“I program my home computer,
beam myself into the future.”
—Kraftwerk
There are two parts to the future: you and everything else. This chapter is
about both. First, we will make some predictions, a few of which may even
come true. More important is the second part of this chapter, about where
you could go next. It is something of an extended Further Reading and
Resources section, but it also discusses ways to proceed from here—sources
of information, conferences, programming tools, etc.
19.1 Everything Else
One yardstick of progress is how closely interactive applications can ap-
proach offline rendered images. Films such as Pixar’s Ratatouille and PDI’s
Shrek series use render farms chock full of racks of CPUs, around 3100 cores
in all, each with access to 16 GB of memory. For example, for Ratatouille,
a single frame took an average of 6.5 hours, though complex shots could
take tens of hours. One constraint is the number of primitives. Scenes
with swarms of rats have hundreds of millions of hairs in them [1093]. All
the assets—models, textures, shaders, precomputed lighting—totaled 5 ter-
abytes, all of which had to be available to the network at all times. At one
879
i
i
i
i
i
i
i
i
880 19. The Future
point, network traffic was a major bottleneck for the film Cars,notCPU
processing power [613].
Going from 300+ minutes per frame to 30 frames per second is a chal-
lenge. On one level, current games can claim levels of visual complexity
near that of Toy Story. This perhaps is not quite true, as the texture de-
tail, geometry tessellation, and amount of sampling per pixel is higher
in Toy Story than in any game. RenderMan is a microgeometry ren-
derer at heart, with each surface chopped into polygons smaller than a
pixel [31, 196]. Such fine tessellations are rarely used in interactive appli-
cations because of the cost. Effective resolution, in terms of total number
of samples taken per pixel multiplied by total number of pixels, is a mag-
nitude or two higher in films than at playable frame rates for video games.
That said, a case can be made that for some shots, at relatively low res-
olution (so that antialiasing can be used), Toy Story complexity has been
achieved.
Say that with the latest GPUs we are only a factor of 100 away from
achieving a decent frame rate at a fine level of detail and shading for most
scenes. Moore’s Law gives an acceleration rate of 2 times every 1.5 years, or,
more usefully, about 10 times every 5 years [1198]. So by this measure, we
are only a decade away from achieving this goal. Unfortunately, it does not
appear that processor speed will be the main constraint on computing in
the future. Bandwidth is increasing by only around 25% per year, a rise of
a little more than 3 times every 5 years. This makes a hundred-fold increase
take about 20 years instead of 10, as long as some other bottleneck does
not appear. Also, the goal line has moved: Ratatouille took 420 times the
computing resources that Toy Story did [613]. On one level, it is incredible
to see what has been done in the area of interactive rendering, such as
Figures 19.1 and 19.2. On another, there is still a lot more processing that
can be done.
Graphics helps sell games, and games help sell chips. One of the best
features of real-time rendering from a chipmaker’s marketing perspective is
that graphics eats huge amounts of processing power and other resources.
As discussed at the beginning of Chapter 14, hardware constraints such as
frame rate, resolution, and color depth all can grow to some extent. The
direction that is essentially unbounded is complexity. By complexity, we
mean both the number of objects in a scene and the way these objects are
rendered. Ignoring all other directions for growth, this single factor makes
graphics a bottomless pit for processing power to fill. The depth complexity
of scenes will rise, primitives will get smaller, illumination models will
become more complex, and so on. First, build a model of the place where
you are right now, down to the tiniest details, and then create shaders
that create a photorealistic rendering of that environment. Add shadows,
then glossy reflections. Now, model the surroundings with the same detail.
i
i
i
i
i
i
i
i
19.1. Everything Else 881
Figure 19.1. Realistic and artistic interactive renderings. (Image above from “Crysis,”
courtesy of Crytek [887, 1342], image below from “Okami,” courtesy of Capcom Enter-
tainment, Inc.)
i
i
i
i
i
i
i
i
882 19. The Future
Figure 19.2. How many effects can you identify? (
c
2008 EA Digital Illusions CE
AB [23].)
Then, add additional light transport paths for indirect lighting. Soon, any
real-time rendering system will be a nonreal-time system.
So, we promised some predictions. “Faster and better” is a simple one
to make. One simple possibility is that the Z-buffer triangle rasterization
pipeline will continue to rule the roost. All but the simplest games use the
GPU for rendering. Even if tomorrow some incredible technique supplanted
the current pipeline, one that was a hundred times faster and that consisted
i
i
i
i
i
i
i
i
19.1. Everything Else 883
of downloading a system patch, it could still take years for the industry
to move to this new technology. The catch would be whether the new
technology could use exactly the same APIs as the existing ones. If not,
adoption could take awhile. A complex game costs tens of millions of dollars
and takes years to make. The target platforms are chosen, which informs
decisions about everything from the algorithms and shaders used, to the
size and complexity of artwork produced. Beyond that, the tools needed
to work with or produce these elements need to be made. The momentum
that the current pipeline has behind it gives it a number of years of life,
even with a miracle occurring.
The way in which special purpose features are added to peripheral hard-
ware, which then later gets folded into the main CPU, is referred to as the
wheel of reincarnation [913]. The interesting question is whether the GPU
pipeline will evolve to perform more general algorithms by itself, will con-
tinue to complement the CPU’s capabilities, or will evolve in some other
direction entirely. There are a few foreseeable paths, along with any hybrids
among them.
If the wheel of reincarnation turns, a possible future is something along
the lines of AMD’s Fusion and Intel’s Nehalem projects [1222]. ATI and
AMD merged in the latter half of 2006. Their Fusion project and Intel’s
Nehalem look to be aimed at putting one or more CPU cores and a GPU
on the same chip. CPUs and GPUs are comparable in size, so replacing
one CPU core with a GPU makes sense. Such a design has a number of
advantages, such as lower latency and overall lower power consumption.
However, it seems aimed more at the mobile market, where small size and
lower wattage matter more.
Intel’s Larrabee project is thought to be aimed more squarely at high
performance, along with broader GPGPU-type computational functional-
ity [1221, 1256]. Larrabee appears to be a GPU with more of the feel of
a CPU that has access to texture samplers. Larrabee products may have
from 16 to 24 cores and attach to a main processor via a second generation
PCI Express bus.
Back in 2006, Intel promised 80 cores on a chip by 2011 [697]. Whether
they reach this goal or not is irrelevant. The key is that the number of
cores is only going to rise, and they will be used in interesting new ways, as
the preceding projects attest. Another Intel initiative (and AMD certainly
is aiming the same direction) is what they call terascale computing [1221,
1256], using multicore to provide a teraflop of performance and a terabyte
of bandwidth on computationally intensive problems. The GPU already
has elements that are massively parallel. One algorithm that immediately
comes to mind when the words “massive parallelism” are spoken is ray
tracing. GPGPU languages such as AMD’s CTM [994] and NVIDIA’s
CUDA [211] make writing a ray tracer that takes advantage of the GPU
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.