Stories
Slash Boxes
Comments

News for nerds, stuff that matters

GPU Gems

Posted by timothy on Tue Jun 01, 2004 01:10 PM
from the shiny dept.
Martin Ecker writes "Following other entrants in the successful series of graphics and game programming-related "Gems" books, Randima Fernando of NVIDIA has recently released GPU Gems - Programming Techniques, Tips, and Tricks for Real-Time Graphics through Addison- Wesley. As the title indicates, GPU Gems contains a collection of tips and tricks for real-time graphics programming with graphics processing units (GPUs) that are found on modern graphics adapters." Read on for the rest of Ecker's review, and for a few more notes on the book.
GPU Gems – Programming Techniques, Tips, and Tricks for Real-Time Graphics
author Randima Fernando (Editor)
pages 816
publisher Addison-Wesley Publishing
rating 9
reviewer Martin Ecker
ISBN 0321228324
summary An excellent book containing many "gems" for real-time shader developers.

The book is intended for an audience already familiar with programmable GPUs and high-level shading languages and is divided into six parts that concentrate on particular domains of graphics programming. Each part contains between five andd nine chapters, with the entire book containing a total of 42 chapters. Each chapter was written by a different renowned expert(s) from a gaming company, tool developer, film studio, or the academic community. About half of the contributors are from NVIDIA's Developer Technology group. The chapters focus on effects and techniques that help developers to get the most out of current programmable graphics hardware. With approximately twenty pages per chapter, the contributors are able to describe various effects and techniques in-depth, as well as delve into the required mathematics.

All the shaders in the book are written in the high-level shading languages Cg and HLSL. The demo programs on the CD-ROM that accompanies the book use both Direct3D and OpenGL as graphics API, depending on the authors' preferences. Even though the shaders are in Cg and HLSL, it should be fairly straightforward for OpenGL programmers who might prefer to use the recently released OpenGL Shading Language to port the shaders, as the syntax is very similar.

The first part of the book deals with natural effects and contains chapters on rendering realistic water surfaces, water caustics, flames, and grass. Two chapters look behind the scenes of NVIDIA's Dawn demo, which shows a dancing fairy with realistically lit skin. There is also a chapter on Perlin noise (improved version) and its implementation on GPUs that was written by Ken Perlin himself.

The second part of the book concentrates on lighting and shadows. There are chapters from people at Pixar Animation Studios that describe some of the lighting and shadow techniques used in their computer-generated movie productions, as well as a chapter on managing visibility for per-pixel lighting. In the shadow department, the two predominant ways of rendering shadows in real-time, shadow mapping and shadow volumes, are discussed with possible optimizations and improvements. The chapter by Simon Kozlov on methods to improve perspective shadow maps presents some especially interesting new material on the topic.

The third part of the book covers materials and contains chapters on subsurface scattering, ambient occlusion, image-based lighting, spatial BRDFs, and how to use them efficiently in real-time, while part four describes various techniques for image processing (being used more frequently in computer games), mostly in the form of post-processing filters. The chapters presented in this section deal with various depth-of-field techniques, a number of filtering techniques using shaders, and the real-time glow effect seen in many of the newer games (especially in Tron 2.0). Not surprisingly, one of the authors of this chapter is John O'Rorke from Monolith Productions, a developer of the game. Contributors from Industrial Light & Magic introduce the OpenEXR file format used for storing high-dynamic-range image files (see openexr.org).

Part five, titled "Perfomance and Practicalities," is a collection of chapters that deal more with software engineering aspects of developing software that uses shaders. In particular, there are chapters on optimizing performance and detecting bottlenecks, using occlusion queries efficiently, integrating shaders into applications and content creation packages (in particular Cinema4D), and how to develop shaders using NVIDIA's FX Composer tool. There is also an interesting chapter on converting shaders written in the RenderMan shading language, a language for offline rendering, to real-time shaders. The chapter uses a fur shader from the movie "Stuart Little" to demonstrate this conversion. With the large increase of GPU processing power, more shaders from the offline rendering world will enter the realm of real-time graphics and it will be useful to re-use already existing resources, such as RenderMan shaders.

The final part of the book deals with a topic that has recently received a lot of attention by graphics researchers - a topic called General Purpose GPU or GPGPU programming, i.e. using the GPU for other things than rendering triangles. This part comprises chapters on performing computations, in particular fluid dynamics, on the GPU, chapters on volume rendering, and a nice chapter on generating stereograms on the GPU. As a side note, there is a website that deals exclusively with news in the GPGPU community at gpgpu.org.

The book contains a many images that show the presented effects in action, and also plenty of diagrams and illustrations that explain more complicated techniques in detail. Unlike Randima Fernando's previously released book, The Cg Tutorial, which I have also reviewed in the past on Slashdot, the book and all of its illustrations and images are printed entirely in color. The large number and high quality of the illustrations is probably one of the best features of this book that makes even the more advanced effects easily comprehensible.

The book comes with a CD-ROM that contains sample applications for most of the chapters in the book. Some of these applications include the full source code, whereas others, such as NVIDIA's Dawn demo (also described in some of the book's chapters), are included as executables only. It must be noted that all applications run exclusively on Windows, even though some of the samples that are available in source code form and use OpenGL could probably be built to run on other operating systems as well. Furthermore, about half of the samples require what Fernando and Kilgard in The Cg Tutorial call a fourth-generation graphics card to run, in particular, an NVIDIA GeForceFX card. Note that most samples that require a GeforceFX will not run on comparable ATI hardware. This comes as no surprise since GPU Gems is predominantly an NVIDIA book. It should be noted, however, that the techniques, effects, and shaders presented in the book's text are generally applicable to programmable GPUs and are equally useful when working with graphics hardware from vendors other than NVIDIA.

This is a great book that every programmer involved in game development and/or real-time computer graphics should have on his/her shelf. For the game programmer it is critical to stay up-to-date with the latest and greatest effects available with modern GPUs in order to remain competitive when creating the gaming experience. For the graphics developer, it is interesting to see how the immense processing power of current graphics hardware can be exploited in graphics applications. This book offers insight on both of these topics and more, and I highly recommend it.

A few notes from reader Akalgonov:

Reader akalgonov contributes a few more thoughts on the book:

"The sample programs and demos require shader support, Cg, OpenGL, or the latest version of DirectX to run. On the plus side, the majority of the companion topics included pre-compiled binaries (but not the runtime dynamic link libraries) or an AVI illustrating the subject in addition to the source code. While the CD contains over 600 MB of examples from the text, it provided only 23 of the 42 topics covered in the book. Since most of the articles provide an overview and references to a topic, additional material on the CD would have been beneficial.

I found the wide range of subjects quite interesting - and was refreshed that the topics actually seemed "ahead of the curve" in terms of hardware requirements. However in order to provide more subject depth, it seemed that the text could have been split into two volumes in order to expand the existing chapters with sufficient depth. As the material is just enough to get one started, the subject treatment may disappoint some readers seeking to apply the clever and unique techniques presented in the book directly or those hoping to use the book as an opportunity to learn some of the advanced features provided in a programming graphical processing unit."


Martin Ecker has been involved in real-time graphics programming for more than 9 years and works as a games developer for arcade games, and works on the open source project XEngine. You can purchase GPU Gems -- Programming Techniques, Tips, and Tricks for Real-Time Graphics from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Related Stories

[+] Developers: NVIDIA GPU Gems 3 Call for Participation 8 comments
H. writes "Following the success of GPU Gems and GPU Gems 2, NVIDIA has decided to produce a third GPU Gems volume to showcase the best new ideas and techniques for the latest programmable GPUs. If you would like to contribute to the GPU Gems series, please read the submission guidelines. The deadline for proposal submissions is Monday, December 11, 2006. If your proposal is accepted, you will receive additional time to complete the chapter." (Here are the participation guidelines.)
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • gems? (Score:4, Funny)

    by lawngnome (573912) on Tuesday June 01 2004, @01:14PM (#9305841)
    no wonder high end cards are expensive!
  • you can get it cheaper at.... (Score:5, Insightful)

    by millahtime (710421) on Tuesday June 01 2004, @01:15PM (#9305853)
    (http://millahtime.blogspot.com/ | Last Journal: Friday July 15 2005, @01:00PM)
    Get it cheaper here [textbookx.com]
    • 1 reply beneath your current threshold.
  • Yawn... (Score:2, Interesting)

    Call me when NVidia and ATI open up their specs so I can finally code that real time raytracing engine I've been dreaming of. Otherwise, you're just tweaking OpenGL or DirectX until the cows come home.

    Actually, I'm a bit surprised that the big names haven't started looking at raytracing. Sure, it has a reputation for being slow, but graphics technology has grown by leaps and bounds. Combined with about 5 billion caching and approximation tricks, and the fact that ray tracing is a highly parallel operation, I'm thinking that we should already have games that are raytraced.

    • Re:Yawn... by walbourn (Score:1) Tuesday June 01 2004, @01:23PM
      • Re:Yawn... by Short Circuit (Score:1) Tuesday June 01 2004, @01:49PM
        • Re:Yawn... by |/|/||| (Score:2) Tuesday June 01 2004, @03:21PM
          • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @04:13PM
            • Re:Yawn... by Viking Coder (Score:3) Wednesday June 02 2004, @04:18PM
          • Re:Yawn... by KewlPC (Score:2) Wednesday June 02 2004, @08:20AM
    • Re:Yawn... (Score:4, Interesting)

      by Anonymous Coward on Tuesday June 01 2004, @01:33PM (#9306089)
      Ray tracing can be done in real time today, at around a million rays per second on a P4-class host CPU. The real bottleneck is not the CPU, but memory bandwidth. It turns out that conventional PC "random-access" memory does not like to be accessed randomly, but that's exactly what a ray tracer needs to do. Memory performance has become seriously dependent on caching over the past 10-15 years, and ray tracers are about the least cache-friendly class of algorithms in existence.

      So don't look to CPU or GPU manufacturers for help with ray tracing... you want to bitch at the short-bus-riding DRAM people instead.
      [ Parent ]
      • Re:Yawn... by Ark42 (Score:2) Tuesday June 01 2004, @02:03PM
        • Re:Yawn... by Anonymous Coward (Score:1) Tuesday June 01 2004, @02:12PM
      • Re:Yawn... by Speare (Score:3) Tuesday June 01 2004, @02:04PM
      • Re:Yawn... by Ann Coulter (Score:3) Tuesday June 01 2004, @02:05PM
        • Re:Yawn... by Minna Kirai (Score:2) Tuesday June 01 2004, @03:08PM
          • 1 reply beneath your current threshold.
    • Re:Yawn... (Score:5, Interesting)

      Actually, I'm a bit surprised that the big names haven't started looking at raytracing. Sure, it has a reputation for being slow, but graphics technology has grown by leaps and bounds. Combined with about 5 billion caching and approximation tricks, and the fact that ray tracing is a highly parallel operation, I'm thinking that we should already have games that are raytraced.

      I'm not sure that's gonna happen. The fact of the matter is that current graphics hardware is fast approaching the point where raytracing will be irrelevant. The lighting algorithms that can be coded on GPUs will one day match the complexity of raytracers and you won't know the difference. The fact of the matter is that scan conversion is not actually mathematically inferior to raytracing as a rendering technique, it's just a way to quickly generate the first recursive step of the raytracer. That advantage isn't going to go away. In actuality, the end result will probably be something of a hybrid between raytracing and traditional scan conversion techniques and you won't really be able to identify it as one or the other.

      [ Parent ]
      • Re:Yawn... by NothingToSeeHere (Score:2) Tuesday June 01 2004, @03:37PM
        • Re:Yawn... by NothingToSeeHere (Score:3) Tuesday June 01 2004, @04:10PM
        • Re:Yawn... by captaineo (Score:3) Tuesday June 01 2004, @06:21PM
    • Re:Yawn... by gr8_phk (Score:3) Tuesday June 01 2004, @01:43PM
      • Re:Yawn... by Adruab (Score:1) Tuesday June 01 2004, @04:09PM
        • Re:Yawn... by Adruab (Score:1) Tuesday June 01 2004, @05:20PM
      • Raytraced Nethack? by billstewart (Score:2) Tuesday June 01 2004, @05:46PM
    • Re:Yawn... by sandwichmaker (Score:1) Tuesday June 01 2004, @01:48PM
      • Links by Anonymous Coward (Score:1) Tuesday June 01 2004, @01:53PM
      • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @02:14PM
        • 1 reply beneath your current threshold.
    • Re:Yawn... (Score:5, Informative)

      by Viking Coder (102287) on Tuesday June 01 2004, @01:49PM (#9306278)
      Two points:

      First, Why? Most people don't even make movies that are raytraced.

      Second, they already are doing raytracing on the GPU. Purcell [stanford.edu] had one working in 2002. There was a presentation on it, in a course at SIGGRAPH 2003. The GPU is maybe a little faster than the CPU, right now, for raytracing.

      "Tweaking OpenGL" is kind of like saying "tweaking the CPU", any more. It's fairly close to a generalized stream processor. And their specs already are open enough to have figured this out. Look at GPGPU [gpgpu.org] and read some more about how people are doing amazing stuff on the GPU today. No need to wait for ATI and NVidia to open up any specs - they already did. Cg and GLSlang are fully up to the task.

      And, photon mapping and similar techniques are much more sophisticated than raw raytracing.
      [ Parent ]
      • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @02:39PM
        • Re:Yawn... by Viking Coder (Score:2) Wednesday June 02 2004, @10:28AM
          • Re:Yawn... by AKAImBatman (Score:2) Wednesday June 02 2004, @11:27AM
            • Re:Yawn... by Viking Coder (Score:2) Wednesday June 02 2004, @04:04PM
    • Re:Yawn... (Score:4, Informative)

      by hawkstone (233083) on Tuesday June 01 2004, @01:54PM (#9306354)
      Open up their specs so you can write a real-time raytracer? Why can't you use Cg or HLSL like others have done? Why do you need to write to the video card directly? You have full access to the programmability of the GPU through these languages. If not, program the damned thing in their version of assembler through the DirectX or OpenGL APIs. Unless by "tweaking OpenGL or DirectX" you mean "programming the GPU", your statement seems flat-out wrong.

      Don't believe you can do it? Here's a link some projects that do real-time raytacing, radiosity, photon mapping, and subsurface scattering [gpgpu.org], all on GPUs. These GPUs are programmable without them opening up their specs.

      (The desire for them to open up their specs is for other reasons, not because they are hiding some functionality from you.)
      [ Parent ]
      • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @03:04PM
        • Re:Yawn... by hawkstone (Score:2) Tuesday June 01 2004, @07:21PM
        • Re:Yawn... by Viking Coder (Score:2) Wednesday June 02 2004, @11:25AM
          • Re:Yawn... by AKAImBatman (Score:2) Wednesday June 02 2004, @11:42AM
            • Re:Yawn... by Viking Coder (Score:2) Wednesday June 02 2004, @04:01PM
    • Re:Yawn... by mikael (Score:2) Tuesday June 01 2004, @04:25PM
      • Re:Yawn... by AKAImBatman (Score:3) Tuesday June 01 2004, @04:51PM
        • Re:Yawn... by mikael (Score:2) Tuesday June 01 2004, @06:00PM
          • Re:Yawn... by AKAImBatman (Score:3) Tuesday June 01 2004, @08:23PM
      • Re:Yawn... by SuiteSisterMary (Score:2) Wednesday June 02 2004, @10:16AM
    • Re:Yawn... by obelixn13 (Score:2) Tuesday June 01 2004, @08:58PM
      • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @09:13PM
        • Re:Yawn... by NothingToSeeHere (Score:1) Wednesday June 02 2004, @03:37AM
      • Re:Yawn... by AKAImBatman (Score:2) Tuesday June 01 2004, @09:21PM
    • Re:Yawn... by Mindcry (Score:1) Wednesday June 02 2004, @04:06PM
      • Re:Yawn... by AKAImBatman (Score:2) Wednesday June 02 2004, @04:33PM
  • The Gems books are classics... (Score:5, Interesting)

    by tcopeland (32225) * <tom.infoether@com> on Tuesday June 01 2004, @01:20PM (#9305924)
    (http://tomcopeland.blogs.com/)
    ...if only to give an appreciation for how hard it is to write 3D games/engines these days. An article on A* will start off with a paragraph or two saying "of course you know A*, and you've read the three papers on A* optimizations, so here's a fourth optimization you may not have seen before".

    A lot of the articles are practical, too, if you're working in the field. When I was fiddling with some fuzzy logic [rubyforge.org] stuff the articles from Game Programming Gems II was very helpful.
  • Perlin (Score:4, Funny)

    by happyfrogcow (708359) on Tuesday June 01 2004, @01:23PM (#9305968)
    There is also a chapter on Perlin noise (improved version) and its implementation on GPUs that was written by Ken Perlin himself.

    Wow.. there's a person behind Perlin noise? I always thought it was a random noise generator based on the chaos found in Perl programs. Thus, the noise was generated by an http client that has "gone perlin'" -- which means to crawl the web in search of arbitrary bits of Perl.

    who knew!?
  • I love how shaders have taken a very hard step and made it into a much easier step. I can tell you about the days before shaders, and doing something like fur was just unthinkable. Now, thanks to Pixar, et al. you can practically make a whole character from a shader, and not ever have to make anything but spheres with cylinders sticking out of them. I am actually anxious to see what happens when any shader can be a real-time shader!
  • Also Check Out... (Score:3, Informative)

    by th1ckasabr1ck (752151) on Tuesday June 01 2004, @01:32PM (#9306080)
    If you're interested in thsi stuff, also check out Real Time Rendering by Tomas Moller and Eric Haines. It's one of my favorites and contains an amazing amount of information..
  • Forget nVidia or ATI... (Score:1, Offtopic)

    by bennomatic (691188) on Tuesday June 01 2004, @01:45PM (#9306235)
    (http://www.tuneforge.com/)
    Does anybody remember the Commodore Vic II chip used in the C-64? 16 beautiful colors, 320x200 (monochrome) or 160x200 (four-color) modes, bitmap, character graphics and up to eight fully independent sprites!

    And don't even get me started on the clear, crisp sounds of the SID chip!

  • by tloh (451585) on Tuesday June 01 2004, @01:49PM (#9306287)
    This post reminds me of a question that I haven't thought about since High School. I was taking programming classes right around the time I was discovering the gaming phenomenon. The dizzying pace of hardware evolution at the time (still going strong as ever many would say) prompt me to ask my computer teacher if computer video hardware was designed in such a way that when graphics were not being processed, the GPU could be used for general number crunching. In other words, if it is possible to do load balancing between the GPU and the CPU. I seemed to recall reading something (possibly on /.) about someone investigating this exact thing I was wondering about so long ago. I should probably STFW, but if someone could point me in the proper direction, I would be as grateful as anyone would to have a long-irritated itch finaly scratched.
  • by Assmasher (456699) on Tuesday June 01 2004, @02:02PM (#9306470)
    (Last Journal: Saturday April 03 2004, @07:10PM)
    lol... Why did they bother to use Cg at all? Could it be because nVidia is putting this book out? Some conflict of interest? Hehe. There are books on HLSL and OSL that are more valuable than this one.
  • B&N? Ripoff! (Score:4, Informative)

    by TastyWords (640141) on Tuesday June 01 2004, @02:47PM (#9307127)
    Why does everyone insist on considering Amazon and B&N to be the only online bookstores? I have news for you folks: it's almost always cheaper to go to AddAll or BookPool and get a book cheaper including shipping than Amazon and B&N.

    In the case of this book, I've taken the liberty of making your life easier by providing you with urls which will take you directly to the price list for the book. For future reference: AddAll is a shopping 'bot, looking at thirty-six stores. AddAll [addall.com] Results and BookPool [bookpool.com]

    Now, if you insist upon paying Amazon and B&N prices, let me know. You can PayPal the money to me and I'll order the book for you from AddAll or BookPool and have it shipped to you. (Of course, I'll keep the difference. After all, you were willing to pay the extra price!) If you're willing to waste your money, I'd rather collect the waste than Amazon or B&N.

    p.s. Remember this the next time you see someone post a message saying, "it's -this price- at Amazon!"

    p.p.s.
    Here's [google.com] the listing from Froogle [google.com] (just in case you haven't used it yet)
  • Cheka gems, NKVD gems, MVD gems and KGB gems.

    Cue "in Soviet Russia" jokes...
  • Re:Gems? (Score:2)

    by WormholeFiend (674934) on Tuesday June 01 2004, @01:48PM (#9306270)
    I read that headline as Germs, so for a few fractions of a second, my caffeine-deprived brain thought, "whaaaa?! video viruses!?!?!"
    [ Parent ]
  • 8 replies beneath your current threshold.