GPU Gems 2 70
| GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation | |
| author | Matt Pharr, Randima Fernando (Editors) |
| pages | 814 |
| publisher | Addison-Wesley Publishing |
| rating | 9 |
| reviewer | Martin Ecker |
| ISBN | 0321335597 |
| summary | The second installment in NVIDIA's GPU Gems series shines with more "gems" on real-time graphics and general-purpose computation on GPUs. |
The book is divided into six parts, each dealing with a different aspect of GPU programming. Compared to the first book, more emphasis is put on the quickly evolving area of general-purpose computation on GPUs, an area that is commonly known as GPGPU (General Purpose GPU; for more information see http://www.gpgpu.org). To my knowledge, this is the first book to contain so much information related to this relatively new field. In particular, three of the six parts of the book are about GPGPU and its applications. The first three parts, however, are about real-time computer graphics.
The first part of the book contains 8 chapters on photo-realistic rendering that mostly deal with how to efficiently render a large number of objects in a scene, which is a necessity for rendering convincing natural effects, such as grass or trees. Two chapters in this part of the book discuss geometry instancing and segment buffering, two techniques to render a large number of instances of the same object, and another chapter focuses on using occlusion queries to implement coherent hierarchical occlusion culling, which is also useful in scenes with high depth complexity.
Other interesting topics in this part of the book include adaptive tessellation of surfaces on the GPU, displacement mapping - an extension to the popular parallax mapping used in some current games - that allows to render realistic bumps on a simple quad, and terrain rendering with geometry clipmaps. Geometry clipmaps can be used to render large terrains almost completely on the GPU. They were first introduced in a SIGGRAPH 2004 paper by Frank Losasso and Hugue Hoppe, and the algorithm is discussed in detail by Arul Asivatham and Hoppe himself in chapter two of this book. This technique will most likely find wide application in next generation games.
Part two of the book consisting of 11 chapters deals with shading and lighting. I found chapter 9 by Oles Shishkovtsov on deferred shading in the soon-to-be-released computer game S.T.A.L.K.E.R. quite interesting. The game features a full deferred shading renderer, which is probably a first for a commercial game. In his chapter Oles describes some of the tricks used and some of the pitfalls encountered while developing that renderer. Also highly interesting is Gary King's chapter on computing irradiance environment maps in real-time on the GPU. These dynamically created irradiance maps can be used to approximate global illumination in dynamic scenes.
Furthermore, this part of the book has chapters on rendering atmospheric scattering, implementing bidirectional texture functions on the GPU, dynamic ambient occlusion culling, water rendering, and using shadow mapping with percentage-closer filtering to achieve soft shadows.
The third part of the book consists of 9 chapters on high-quality rendering. Most chapters in this part deal with implementing high-quality filtering in fragment shaders. For example, there is an interesting chapter on filtered line rendering and another chapter on cubic texture filtering. In chapter 23 NVIDIA also provides interesting insights into the inner workings of their Nalu demo, which was the release demo for the GeForce 6 series that displays an animated mermaid underwater. In particular, the chapter describes the techniques used to implement the mermaid's hair. Finally, Simon Green of NVIDIA presents his GPU-only implementation of improved Perlin Noise.
Whereas the first three parts of the book cover techniques for real-time computer graphics, the three final parts deal exclusively with GPGPU. Since GPUs nowadays offer a high level of programmability and because of their wide-spread use in commodity PCs, GPUs can be used as a cost-efficient processor for general computation in addition and parallel to the CPU.
Efficient usage of the GPU for general computation, so that conventional CPU implementations can be outperformed, requires special care when mapping algorithms to the highly parallel architecture of the GPU pipeline. Part four of the book mostly deals with exactly this and represents an introduction to the fantastic field of GPGPU. The 8 chapters of this part first describe the general streaming architecture of GPUs, with one chapter going into the details of the architecture of the GeForce 6 series in particular, and then move on to show how to map conventional CPU data structures and algorithms to the GPU. For example, textures can be regarded as the GPU equivalent to CPU data arrays. There is also a chapter on how to implement flow-control idioms on the GPU and a chapter on optimizing GPU programs.
The 6 chapters of part five of the book are on image-oriented computing and describe a number of GPGPU algorithms for performing global illumination computations, for example by using radiosity, on the GPU. There is also a chapter on doing computer vision on the GPU, which I found to be quite exciting. Because of its high parallelism, the GPU can be used to do the tedious tasks of edge detection and marker recognition required in computer vision in a very efficient manner, thus elevating the CPU to do other tasks in the meantime. James Fung, the author of this chapter, is also involved in an open source project called OpenVIDIA (see http://openvidia.sourceforge.net) that is all about GPU-accelerated computer vision. he final chapter in this part of the book explains how to perform conservative rasterization, which is important for some GPGPU algorithms to achieve accurate results.
The final part of the book has 6 chapters that present GPGPU techniques to perform a variety of simulation and numerical algorithms on the GPU. One chapter shows how to map linear algebra operations onto the GPU and develops a GPU framework to solve systems of linear equations. In other chapters the GPU is used for protein structure prediction, options pricing, flow simulation, and medical image reconstruction. These chapters show good examples of how the GPU can be used for non-graphics-related tasks. Furthermore, Peter Kipfer and Rüdiger Westermann present algorithms for efficient sorting on the GPU. Since sorting is such an important building block of many higher-level algorithms, it is important to have an efficient implementation for GPGPU algorithms.
The book contains many illustrations and diagrams that visualize the results of certain techniques or explain the presented algorithms in more detail. All images in the book are in color, which is definitely advantageous for a graphics book. In my opinion, the excellent quality and also the quantity of images and illustrations is one of the strongest points of this book compared to other graphics books.
The book also comes with a CD-ROM with supplemental material, videos, and demo applications to some chapters. Most of the applications include the full source code, which makes it easy to experiment with the techniques presented in the book. Note that most of the applications run on Windows only and many of them require a shader model 3.0 graphics card, such as a GeForce 6600 or 6800. The latest ATI cards, such as the X800, are not sufficient for running some demos because they only support shader model 2.0.
I highly recommend this book to any professional working as graphics or game developer. It is a valuable addition to my library of graphics books and I will come back to a number of articles in the near future. The focus on GPGPU in the second half of the book is a welcome addition and we can expect to see more and more non-graphics-related applications make use of the processing power in today's GPUs.
Martin Ecker has been involved in real-time graphics programming for more than 10 years and works as a game developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net.You can purchase GPU Gems 2 - Programming Techniques for High-Performance Graphics and General-Purpose Computation from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
GLIDE (Score:2)
Re:GLIDE (Score:3, Interesting)
From a developer standpoint, I enjoyed GLIDE a lot more then OpenGL, and multitudes more then Direct3D. I believe it didn't stick, simply because, unlike the other two, it didn't progress much, and Creative made sure it wasn't a general hardware API.
Re:GLIDE (Score:3)
Uh... you're going to have to explain this one.
Re:GLIDE (Score:1)
Uh... you're going to have to explain this one.
Weird... GLIDE was 3DFX's proprietary API. All I can think of is that Creative made a GLIDE wrapper for their TNT2 cards. It was bad. Very bad.
Re:GLIDE (Score:3, Interesting)
Re:I love dead links (Score:4, Informative)
Re:I love dead links (Score:3, Informative)
Parallel Processing (Score:1)
Re:Parallel Processing (Score:2)
Audio processesing using the GPU (Score:5, Interesting)
Re:Audio processesing using the GPU (Score:3, Informative)
Re:Audio processesing using the GPU (Score:3, Informative)
Re:Audio processesing using the GPU (Score:2)
Re:Audio processesing using the GPU (Score:5, Interesting)
My prediction: In the future, people will use their graphics cards for graphics
In the very near term, GPUs have so much more vector processing power, that people say "hmm, we could use the GPU for x"... But, the GPU is *not* a general purpose processor, and doing general "programming" for it isn't going to be a good use of it.
GPU's are very powerful, so if you could bring a product/app to market within the next couple of years, you would have a performance advantage. But only for a little while.
In the long term: The Cell processor has, on each CPU, 8 vector units. According to a quick google search, each one is a 32 GFLOPS vector processor... So, thats sort of like 256 GFLOPS of processing power available. A current NVidia GPU is more than 32, but a lot less than 100 GFLOPS. You don't really have "256 GFLOPS" available for any given task, because the processors are independent... You might be able to use one of the Cell vector units as a replacement for your "graphics card", but it won't be as special purpose as your graphics card is, so each GFLOP will get you less in terms of actual graphics goodness... And, they're independent, and although graphics is very parallelizable, no real world problems comes even close to being 100% parallelizable. Witness the dismal results of SLI rendering.
Cell looks awesome, but when we can hold the real thing in our hands, I wouldn't be surprised if it didn't live up to its hype, (but I wouldn't be surprised if it did, either). My prediction for Cell is: the processor exists and is everything they say it is, which is just a PowerPC-based CPU with 8 attached decently powerful vector units... the whole concept of "automatic distributing computing" is probably not worth paying attention to.
OK, this long post turned into an ad for Cell I think, but I am very psyched about it.
A summary: You can use your graphics card for non-graphics processing, and you will have a performance advantage while doing it for a little while. In the long term, Cell or something like it will be the main CPU in your computer, and it will be much better for non-graphics-based vector processing than a GPU, and better for some kinds of graphics processing (raytracing, non-realtime, etc), but not for the current "standard" (raster-based graphics).
Re:Audio processesing using the GPU (Score:2)
SLI actually provides a very significant performance increase over a single GPU solution. In actual applications (HL2, S.T.A.L.K.E.R.), an SLI configuration gains approximatly 90% over a single GPU. This is not a "marginal" win.
Re:Audio processesing using the GPU (Score:1)
i know for a fact it will not live up to anywhere near the hype.
Re:Audio processesing using the GPU (Score:2)
No you will never format rows in Word using a GPU. But if you are into scientific processing it would seem a reasonable investment. Even if CPUs eventually take back the dominance you'll have a
Re:Audio processesing using the GPU (Score:2)
I understand exactly what they are, it's my job.
But, look at the numbers: Current GPUs are around 60 GFLOPS tops. The ATI hardware going into the new xbox is 48GFLOPS.
Now tell me how a general purpose CPU is going to compete with that?
Calling the Cell a "general purpose CPU" is not really correct. A Cell chip is *a* general purpose (PowerPC) CPU and *8* very capable 32 GFLOPS vector CPUs on the same die. It's not like a
Coprocessors and "array processors" -- feh! (Score:3, Interesting)
I guess we are stalled with a minor improvement with the Pentium 3, and step backward per clockrate with the Pentium 4 an
Yes, but... (Score:4, Insightful)
I mean really, even the review contained so many domain specific terms it was hard to follow. Still, I can't imagine this as being a requirement for game programmers. Certainly many games utilize the features within on PC's, but the majority of the games today aren't made for PC's. And the majority of programmers on a game dev team don't deal with the game's renderer.
Sure, it might be good to have, and much of the parellel processing practices will translate to consoles, but required?
Re:Yes, but... (Score:2)
What makes games on the PC for instance require a lot more power is it is NOT the only application running on the machine AND the multitudes of abstraction needed to give a consistant programming interface.
Re:Yes, but... (Score:2)
Re:Yes, but... (Score:2)
This book, and review, is obviously for people who have a some amount of prior experience with 3d graphics programming. Thus both may assume that the reader knows those domain specific terms.
If the reader doesn't, then it is the readers task to look up their meaning.
Re:Yes, but... (Score:1)
But you're right that only the graphics team needs to worry about shaders, unless (as discussed in the review) other areas start to use the GPU for
Re:Yes, but... (Score:2)
There are 3 things that could make the things you could do with a GPU much, much cooler:
1) Spawning vertices from within in GPU program.
2) Vertices interacting with each other (cloth, eg)
3) Persisting the results of vertex ops without the horrible memory bottleneck.
Now, all of those you'll be able to do with the next-gen of consoles... not on the GPU, but with the multi-core processors.
I'm not saying that current GPU prog
Better graphics = more realistic games right? (Score:4, Funny)
Re:Better graphics = more realistic games right? (Score:4, Insightful)
Re:Better graphics = more realistic games right? (Score:1)
Re:Better graphics = more realistic games right? (Score:1)
Slight clarification (Score:5, Informative)
The first commercial game that I know of to use a full deferred shading engine was Shrek for the Xbox, which was released in Fall 2001.
I also worked on an unannounced PC game in 2003 that had a fully deferred shading (lighting) renderer. Alas, that title was cancelled.
Deferred Shading on the PC is not very practical on pre-shader model 2.0 hardware, though possible I'm sure. The Xbox allows direct access to the register combiners, exposing more than 2x the fragment processing power than DX8 / Shader 1-1.3 on the PC.
Re:Slight clarification-Bus-ted. (Score:2)
The AGP/PCIe bus is not really the issue with Deferred (embedded DRAM is, but that's another story). The PC's video cards holds all the rendered attributes and accumulated light values in render targets on the card. Those render targets are then read back as textures in subsequent passes. Data is not sent back to PC across the bus as the CPU doesn't get involved. Render Target Changes (among other things) are
Re:Slight clarification (Score:5, Informative)
The entire reason behind doing deferred shading (in games) is that lighting computations per-pixel--especially when you start using HDR--are extraordinarily expensive. Deferring the shading of these fragments until you are sure they will be visible saves the GPU a ton of work.
To briefly explain what deferred shading is (for those who aren't graphics programmers)... Deffered shading is a technique where you lay down the entire scene in two passes. The first pass renders the entire scene but with all color writes disabled. This allows modern cards to draw data at about 2x the normal rate (plus you can generally avoid any shading--except those that do depth replacement--which provides an additional speed increase to this pass). The second pass is then rendered using the full / normal technique. The benefit is that since the depth buffer has already been filled, the staggering amount of graphics hardware devoted to rejecting fragments that are hidden is used to full advantage. This allows for some serious speed increases, especially if the shading of visible surfaces is very complex.
The downside of this technique (and maybe what the parent was trying to get at) is that if your shaders are not particularly complex, than this technique is really not much of a win... In fact it can be slower than standard one-pass solutions in that respect.
Re:Slight clarification (Score:4, Interesting)
Sort of. You're right about the value proposition, but regarding hardware, here is an example:
One most important thing that is needed during the shading pass is to obtain the fragments position in the space you are working in. This usually means getting it's X,Y and Z values and transforming them into a space such as view space. On PC video cards, you can't read Z info from the Z-buffer (really would be nice), so you have to store it off somewhere. On a DX9 card such a Radeon 9600 you usually write out the Z to a separate render target using 32F format. On a DX8 card such as a Geforce 3, there is no support for float render targets, in fact nothing beyond 8888 and x555/x565 formats is supported. At lot more work is needed to get the fragment's position, and you have fewer pixel shaders ops to do it in.
You are not entirely right in saying that Deferred shading saves computations by eliminating overdraw, and yes fast-Z rejection on subsequent passes is a big help. Yes, overdraw is saved, but your lighting costs now directly turned into fill, and it is possible to have situations that are worse than forward (traditional) shading. The biggest benefit of Deferred shading IMHO is that you separate out attribute rendering from lighting. Other benefits include complete per-pixel lighting and normal mapping for the scene, and the visual consistency across the entire scene.
As an example, if you are going to render a character using forward shading, and there are several point lights that might impact the character, at each frame you need to determine which lights can impact the character and select a shader (or multi-pass) that supports all N number (and types) of lights.
With deferred shading, you just render out the character's attributes (albedo, position, normal, specular info, whatever) to buffers (DX9 multi-render targets are a big help). Then, in the lighting passes, you project the volume affected by the light into 2d screen space and render a ligthing shader into that volume. The shader looks at each fragment and calculates the light influence on that fragment and accumulates it (separately for diffuse and specular usually). Repeat for each light in the scene. The upshot is that the amount of fill/pixel shader needed is dependent upon the projected area affected by the light. The possible downside is that many of the fragments in that area may be in front or behind the light volume, in which case the lighting calculation is performed on a pixel that's the light doesn't impact (it just accumulates zero light).
For large numbers of small, dynamic lights, deferred can be a huge win. For static lighting it could also be a win. It all really depends on what the game is doing. There are other aspects of Deferred that are different or more difficult such as alpha-blending, but a full discussion is outside the scope of this forum.
How inclusive is the book? (Score:4, Interesting)
Re:How inclusive is the book? (Score:2)
I believe the next ATI card is supposed to support Shader model 3.0, so you should be okay in the near-term.
Re:How inclusive is the book? (Score:1, Insightful)
Re:How inclusive is the book? (Score:1)
The book also has a chapter written by a couple of guys from Apple summarizing their experiences with making their code work on both ATI and nVidia cards -- if you're interested in supporting both, this chapter alone might justify buying the book.
Re:How inclusive is the book? (Score:1)
Quartz Composer on MacOS 10.4 (Score:3, Interesting)
It's a visual programming environment that lets you hook together "patches" that create, control, and present audio and video. You can include GL-slang kernels as well. Also, since MacOS X 10.4's Core Image will recompile GL shader language into Altivec code if the GPU isn't up to the task, it adds a lot of flexibility as to when you're okay using the shader language. You can synchronize audio effects with real-time video effects, and hook up iSights, still images, MIDI sound, audio input, mix them all together on the CPU and GPU, and present some stunning effects. I'm certainly going to be checking this book out to see if it helps with this sort of endeavor.
I don't want to Slashdot anyone's site, since most people working on it are just publishing their creations on personal blogs, but a few google searches can turn up some really fantastic visual effects people have created in the couple weeks it's been out.
Here is Apple's intro to the subject:
http://developer.apple.com/documentation/Graphics
and, specifically,
http://developer.apple.com/documentation/Graphics
FFT's on GPU's? (Score:3, Interesting)
Re:FFT's on GPU's? (Score:4, Interesting)
Not as high as I would expect, but I expect this will increase over time.
Re:FFT's on GPU's? (Score:1)
a wiki would be helpful (Score:1)
Are there any wikis out there that contain these sorts of GPU tricks?
Cool Ambient Occlusion Algorithm (Score:1)
But what's especially cool is the chapter is available for free download on the GPU Gems 2 [nvidia.com] sit
Open Graphics Project (Score:1)
Please close your italics tag (Score:2, Funny)
LAME GPUs (Score:2)
Re:LAME GPUs (Score:1, Informative)
If the GPU had high-speed direct access to main memory - ironically, the kind of architecture that those crappy low-end integrated graphics subsystems use - then this problem would go away, but currently th
Re:LAME GPUs (Score:2)
science (Score:2)
If anyone has any information on this, I would be very interested to hear (or perhaps other har