Slashdot Mirror

← Back to Stories (view on slashdot.org)

GPU Gems

Posted by timothy on 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.

116 comments

  1. Gems? by Kenja · · Score: 0, Offtopic

    And here I thought this was about making jewelry out of your old video card.

    --

    "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    1. Re:gems? by gauchopuro · · Score: 0, Redundant

      Thar's gold in them thar cards!

    2. Re:Gems? by WormholeFiend · · Score: 1

      I read that headline as Germs, so for a few fractions of a second, my caffeine-deprived brain thought, "whaaaa?! video viruses!?!?!"

    3. Re:gems? by NanoGator · · Score: 3, Funny

      "no wonder high end cards are expensive!"

      My gf's ex bought her a Diamond video card for their anniversary. I was warned that that little joke was only funny the first time.

      --
      "Derp de derp."
  2. gems? by lawngnome · · Score: 4, Funny

    no wonder high end cards are expensive!

  3. you can get it cheaper at.... by millahtime · · Score: 4, Insightful

    Get it cheaper here

    --
    Evolution or ID?
  4. Yawn... by AKAImBatman · · 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.

    --
    Javascript + Nintendo DSi = DSiCade
    1. Re:Yawn... by walbourn · · Score: 1

      I'm thinking that we should already have games that are raytraced.

      Why bother? All that computational power is being put to use dealing with the real challenges of interactive real-time 3D games: collision, animation, physics, AI.

    2. Re:Yawn... by Anonymous Coward · · Score: 4, Interesting

      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.

    3. Re:Yawn... by bradkittenbrink · · 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.

    4. Re:Yawn... by gr8_phk · · Score: 2, Informative
      "I'm thinking that we should already have games that are raytraced."

      google for rtChess.

      The ray tracing engine has since seen a 40% performance boost and has added photon mapping and scales nicely with more CPUs - I just haven't written a game with it since. I don't think a GPU implementation will be much faster. nVidia seems to think they make general purpose processors now - HAH what a laugh.

    5. Re:Yawn... by sandwichmaker · · Score: 1

      Stop yawning and start reading. http://graphics.stanford.edu/papers/rtongfx http://graphics.stanford.edu/papers/tpurcell_thesi s/ http://graphics.stanford.edu/papers/photongfx

    6. Re:Yawn... by Viking+Coder · · Score: 4, Informative

      Two points:

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

      Second, they already are doing raytracing on the GPU. Purcell 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 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.

      --
      Education is the silver bullet.
    7. Re:Yawn... by Short+Circuit · · Score: 1

      He's talking about offloading the raytracing to the GPU. AFAIK, collision, physics and AI aren't dealt with there. (Animation is iffy...you could do some of it on the GPU, but, AFAIK, most is still done on the CPU.)

      --
      tasks(723) drafts(105) languages(484) examples(29106)
    8. Re:Yawn... by hawkstone · · Score: 3, Informative

      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, 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.)

    9. Re:Yawn... by Ark42 · · Score: 1

      1 million rays per second on a high-end CPU does not seem all that impressively useful for games. It may get you about 320x240 at 13fps, which is not good at all for games. Hardly real time. For 640x480 at 60fps you need closer to 18 million rays per second. That would qualify as realtime. So I take it that means memory needs to get about 20 times faster then it is today. Thats going to be a while.

      --
      Morphing Software
    10. Re:Yawn... by Speare · · Score: 2, Informative
      Ray tracing can be done in real time today, at around a million rays per second on a P4-class host CPU.

      I fail to see how one million rays per second is "real time" for most images people associate with ray-tracing. Even at one ray per pixel, you're limited to a single 500x500 image per second. But the value of ray tracing is the recursion: one ray hits an object, and anywhere between 2 and 200 rays result (counting for any subsequent recursions, lights and diffusions).

      Your budget: 1000000 rays per second. Take a guess at an average of 10 rays per resulting pixel including all recursion, and you're down to a paltry 100x100 pixels at 10fps. You fail on all metrics of expected quality: poor fidelity, poor resolution, and poor framerate. Even on faster CPUs, you haven't made up the difference for what users want to see.

      --
      [ .sig file not found ]
    11. Re:Yawn... by Ann+Coulter · · Score: 2, Informative

      There are serious investigations into making cache optimized algorithms. For example, the matrix transposition and array index bit reversal algorithms have been investigated in two papers. Also, Bailey's 4-step and 6-step FFT algorithms are also cache efficient. The latter example shows that a complex algorithm such as a FFT can be made cache efficient with the sacrafice of only a few extra computations. Perhaps it would be prudent to use a hybrid ray-tracer/polynomial renderer to section each portion of the screen into regions that will only access a particular portion of memory. In fact, texture mapping is a lot like that. But I propose that we section the geometry into sections that are localized in memory. This will require more computation in the form of checking which ray goes where but it might be possible to create a viable ray tracer/polygon renderer that produces images of ray tracing caliber. By polygon renderer I mean the renderers that we currently use in gaming.

      Some references about cache efficiency.

    12. Re:Yawn... by Anonymous Coward · · Score: 0

      I didn't say it was nice ray-tracing, just that you could do it in real time with limited resolution and limited bounces.

    13. Re:Yawn... by Anonymous Coward · · Score: 1, Insightful

      Right. It's not useful for games, which is why few if any games use real-time ray tracing yet.

      With another 10X performance improvement, that may change. But my point is, the 10X improvement is going to have to occur on the memory side, not the CPU and GPU side where it usually happens.

    14. Re:Yawn... by AKAImBatman · · Score: 1

      I have read. That's why I'm complaining.

      --
      Javascript + Nintendo DSi = DSiCade
    15. Re:Yawn... by AKAImBatman · · Score: 1

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

      Because current methods are getting too complex. The shear number of details in writing a modern 3D engine is daunting, even to an experienced 3D coder. A raytracer would allow you to hit a big reset button and go back to times that were simpler. As a bonus, quality could eventually be taken much farther than today's polygon/shader methods.

      And, photon mapping and similar techniques are much more sophisticated than raw raytracing.

      Raw raytracing is rarely done as raw raytracing. Texture engines such as bump mapping, photon mapping, highlighting, reflection, etc. are often applied. Hell, raytracing invented most of these engines. The difference is that many of these features can be planned for by an artist rather than a coder. A few clicks in their design tool, and the artist replicates what used to take a coder weeks of work. This streamlines the process and reduces the time it takes to get the product out the door.

      --
      Javascript + Nintendo DSi = DSiCade
    16. Re:Yawn... by Anonymous Coward · · Score: 0

      You're complaining because you're the typical, ill-informed, whiny bitch that represents most of what Slashdot is today.

    17. Re:Yawn... by AKAImBatman · · Score: 1

      I'll grant you that I haven't spent too much time investigating all the new shader languages. However, I have poked at Cg, and it simply wasn't general purpose enough to meet the needs of a high performance raytracer. For maximum performance, a general purpose, real-time raytracing engine would need to be able to reprogram and reuse all of the card's pipelines, not just the vertex shader.

      --
      Javascript + Nintendo DSi = DSiCade
    18. Re:Yawn... by Minna+Kirai · · Score: 2, Funny

      Has anyone told you that your choice of nickname is distracting? The real Ann Coulter has a very limited range of output that can be trivially replicated by Markovian string techniques. This leads most readers to skip over anything under her name, because the content is entirely predictable.

    19. Re:Yawn... by |/|/||| · · Score: 1
      Collision, physics, AI, and animation are all dependent on transformations, which can now be done quickly by the GPU.

      However, raytracing still requires the same transformations, so GPUs as they work now are no more useful for physics, etc. than a raytracing GPU. In fact, with per-pixel shading, modern GPUs practically *are* raytracers.

      Can someone point out exactly what differentiates a per-pixel polygon shader from a raytracing engine from a practical point of view? I'd be interested to know.

      --
      [javac] 100 errors
    20. Re:Yawn... by Anonymous Coward · · Score: 0

      You're complaining because you're the typical, ill-informed, whiny bitch that represents most of what Slashdot is today.

      Speaking of typical Slashdotters...

    21. Re:Yawn... by NothingToSeeHere · · Score: 2, Informative

      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.

      Actually, AFAIK the opposite is true.
      Raytracers scale very nicely with geometric complexity: O(log n). So as the virtual environments continue to grow, raytracing should gain popularity over scan conversion. Have a look at this - that's 50 million triangles raytraced at 4-5 fps!

      Most of the current interactive raytracing is still done on parallel computers or PC clusters, but there are a lot of optimizations that can be combined to achieve interactivity even on a single CPU. And hardware architectures are underway as well...

    22. Re:Yawn... by Adruab · · Score: 1

      I'm not sure why no one has mentioned gpgpu.com (been posted on slashdot before). They have real time ray tracers based on GPU processing. I'm pretty sure that most people doing generic stream processing on a GPU have done so without the behest of nvidia. The only thing they've said is that their chip is a super scalar design, which is true. If you want to see real uses of crazy graphics take a look at the million particle demo (gdc 2004 paper I think), and see if you can implement that in real time on a CPU just as fast. For Ray tracing, I don't think GPUs will really out pace CPUs. However there are plenty of other uses for a semi-specialized highly parallel chip besides raytracing.

    23. Re:Yawn... by NothingToSeeHere · · Score: 3, Interesting

      I realize 250 Mtriangles/sec aren't quite the 380 stated by ATI for their current generation GPU (Radeon 9800 Pro), but the paper I linked to is from 2001.
      The hardware raytracing site has a nice video of their FPGA-based system rendering about 187 million triangles at about 15 - 40 fps (512x384, 90MHz FPGA).

    24. Re:Yawn... by AKAImBatman · · Score: 1

      In fact, with per-pixel shading, modern GPUs practically *are* raytracers.

      Which is basically my problem with current cards. Programming them has become exceedingly complex because they stick to a polygon/raster model instead of simply declaring rays outright.

      --
      Javascript + Nintendo DSi = DSiCade
    25. Re:Yawn... by mikael · · Score: 1

      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.

      To match the quality of anti-aliased triangle rendering, you need at least 4 samples per pixel. Then you need to support full-screen resolutions (2048x1536). To be officially real-time, you need at least 15 frames/second, if not the full 60/80 that most games provide now.
      That would give you a budget requirement of at least 200 million rays/second. However, most outdoor scenes need a ray depth of seven to be indistinguishable from a photograph (Looking through the windows of a house for example). So, you'd need to increase this requirement to 1 billion rays/second to completely achieve this goal (although not all surfaces are partially transparent). Remember that level designers would want to use all the possible visual effects including multiple mirrors/volumetric fog.

      To some extent 3D API's already do two-level ray tracing through surface reflections/transparency. For a 3D API to support ray-tracing in hardware, you wouldn't have to change much. First level rays are achieved through standard triangle rasterisation. But to achieve full ray-tracing, you would need to have a fragment program that could handle as many as (antialiasing level)^(ray tracing depth) reflection/refraction calculations and triangle-ray intersection tests per pixel -assuming the worst case, a room full of mirrors.

      You can define triangles using combinations of texture coordinates/vertices and ID numbers, so memory space isn't that difficult (128 bytes for three vertices/texture coordinates + material/texture ID). However, you then have to test every generated ray against every other triangle. Octrees/BSP's can help but that still adds another magnitude to the requirement.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    26. Re:Yawn... by AKAImBatman · · Score: 2, Interesting

      Remember the three magic words to making high speed 3D graphics work: "Cheat like hell" I'd actually done some research into this area not so long ago (most of which I can't remember) and I found that about 95% of calculations can be stored in lookup tables, or calculated once for all rays. I don't remember all the details of my evil plan (I really need to start writing this stuff down) but I had pivoted the calculations in such a way as to make multiple, pipeline friendly passes.

      The first stage or two got most of the predictable calculations out of the way, Most of these were length calculations for all objects within the bounding area. These calculations were then reused in the next step where the rays were actually cast. Since most of the info had been precalculated at an O(objects) performance, the number of computations for the O(rays) operation was reduced. I think I left myself with a multiplication or two, plus a square root from a lookup table. Obviously the algorithm assumed that the number of spatial objects within the bounding area was significantly less than the number of rays being cast. (A fair assumption in raytracing.)

      In the end, the point was to not only precalculate as much as possible, but to also avoid any unnecessary jumps in the code. By making the entire algorithm as linear as possible, I planned to make full use of a super-deep pipeline like those present in GPU and DSP chips. The performance results of such a pipeline would put a modern Pentium IV to shame. In the end, I gave up for want of a programmable graphics card. Cg was brand new, and my current NVidia GeForce 2 wasn't programmable enough for experimentation.

      Antialiasing is difficult, but not insurmountable. I don't know if my algorithm would have been fast enough to allow a 4x antialias pass, but I'm not sure it's relevant. If a raytracing standard were deployed to developers today, some games would take advantage of it. These games would then drive the development of better hardware designs for raytracing. Even if the idea flopped, the only risk would be in writing a new set of drivers for a GPU.

      --
      Javascript + Nintendo DSi = DSiCade
    27. Re:Yawn... by Adruab · · Score: 1

      Heh, my bad it's www.gpgpu.org.

    28. Re:Yawn... by mikael · · Score: 1

      I had a go some time back. The camera rays were pre-calculated. A bounding box was calculated for each triangle in image space. These were ordered by starting row and column. Lists of the possibly visible triangles were maintained as the image space was scanned. Groups of geometry had bounding spheres. I was getting around 15 seconds/frame.

      However, there seem to be many open source real-time ray-tracing projects going on:

      OpenRT, with it's own FAQ. This project seems to have several games written for it.

      Rearview is another game-engine based on ray-tracing

      There's also the Avalon Project. There was also an article discussing the use of SSE Instructions. The Source code to a demo is available at RAVI-Demo. Other projects include RealStorm.

      It certainly seems to be an active area.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    29. Re:Yawn... by captaineo · · Score: 2, Interesting

      Ray tracing does seem to have some on-paper theoretical advantages, but I've always found that it's a render time killer for my scenes. While the asymptotic running time of ray tracing is good, the coefficient is so much higher that "polygon splatting" has won every time so far.

      You also need to consider that the O(log N) figure for ray tracing does not include the cost of building a ray-acceleration data structure, and it also assumes the entire scene fits in RAM. Polygon splatting is O(N), but the coefficient is much smaller, and RAM requirements are much less. Depending on how your scene is organized, and how much you can cull, you may be able to get more like O(log N) behavior from a scanline renderer.

      Also, if you think of "N" not as geometry elements but as output pixels, ray tracing is O(N^2) whereas I claim that scanline rendering scales at somewhat less than O(N^2), because you don't need to shade each and every screen-space sample. (look at how PRMan works for an example of this).

    30. Re:Yawn... by hawkstone · · Score: 1

      Ah, yes, things have probably progressed pretty quickly in this arena. The vertex shaders are not nearly as flexible and powerful as the pixel shaders. A common technique is to draw a single quadilateral across the entire framebuffer, and with the right mapping every pixel will be visited once in the fragment (pixel) program. This fragment program is where you write the raytracer.

      (Simplified concept, of course, but you get the point.)

    31. Re:Yawn... by AKAImBatman · · Score: 2

      I had a go some time back. [snip] I was getting around 15 seconds/frame.

      I never said it was easy. :-) You have to carefully limit your rays as much as possible. With extremely complex scenes, you may even have to render only some of the pixels for each frame. However, things get much better when you get to the GPU. Most of today's cards have at least two pipelines. Some even have 16! Now raytracing is a highly parallel operation, and GPUs tend to have very deep pipelines with excellent floating point support. Combine the two with a properly tuned ray tracer, and the results should be fantastic!

      Oh, and I remember one more thing. I was planning to time limit a frame rendering as if it was a hard real time system. The rays would be cast in a wide pattern so that if time ran out, most of the scene would already exist. Pixels from the previous frame could plug the hole.

      It certainly seems to be an active area.

      Indeed. I myself have been trying to figure this out since the days of the original Pentium. It wasn't until about 2 years ago, however, that someone actually broke the barrier and built the first realtime ray tracer. It was pixelated as all get out, but it worked. Its most interesting feature was all the curved geometry that it was capable of. The graphics were so pretty that I would have liked to see a game despite its limitations.

      I think that the future really is ray tracing. Time will tell.

      --
      Javascript + Nintendo DSi = DSiCade
    32. Re:Yawn... by obelixn13 · · Score: 2, Insightful

      Many of the 'pretty' effects that come with raytracing such as reflections and highlights are easily approximated in most games using cheap hacks, eg environment and normal mapping.

      We have become so used to these in games now, that I dare say if you did produce a real-time raytracer you would be hard-pushed to explain to the average gamer what was so cool about it.

      The bar has been raised significantly since ray-tracing was first presented in the 70s. And we've long since started looking beyond what raytracing can deliver, eg soft shadows, colour bleeding, subsurface scattering etc.

      As a lighting model, its a very blunt instrument mathematically - most /.ers probably remember writing their own for some undergraduate assignment a long time ago ;).

    33. Re:Yawn... by AKAImBatman · · Score: 1

      Look here and I think you'll understand what's so cool about it. A hint: it's all about the geometry. :-)

      --
      Javascript + Nintendo DSi = DSiCade
    34. Re:Yawn... by AKAImBatman · · Score: 1

      This video is also very interesting. It should be entitled, "how to make one's jaw drop". =D

      --
      Javascript + Nintendo DSi = DSiCade
    35. Re:Yawn... by Anonymous Coward · · Score: 0

      Ann Coulter is more intelligent than you are.

    36. Re:Yawn... by NothingToSeeHere · · Score: 1

      Shark still looks fake... ;-)

    37. Re:Yawn... by KewlPC · · Score: 1, Interesting

      The difference is that, with pixel shaders, you aren't necessarily tracing rays of light.

      A per-pixel polygon shader is just that: a small program that gets run for every pixel of that polygon on the screen. That says absolutely nothing about what lighting method is used.

      Now, that pixel shader can do raytracing, but simply being a pixel shader doesn't mean that raytracing is being done. The pixel shader could instead do shadow mapping or something.

      Raytracing is just what it sounds like: you literally trace the path of the light rays in the scene. As you can imagine, this process is very computationally expensive, which is why it isn't done often. Major Hollywood VFX firms have only recently begun to put it into limited use.

      A much faster method, and the method that is used in pretty much every game (with exceptions being Doom 3, HL2, Far Cry, and some other recent or soon-to-be-released games that use some variant of shadow mapping or shadow volumes), is to just calculate the relation of the polygon's normal to the light's direction, and increase or decrease the brightness of the polygon based on that. In other words, the more a polygon is angled away from the light source, the darker it is. If it faces completely away from the light, then it is completely in shadow.

      To get shadows in those games, the shadows are usually just faked. Black polygons on the ground directly under the object, etc.

      The method used for VFX in most movies to date is called shadow mapping. Basically, with this method you render (at least) two images for every frame: one from the light's position (the shadow map), and one from the camera's position. For the image taken from the light's position, which is grayscale, you base each pixel's brightness on how far away it is from the light, so that the brighter it is the closer it is to the light. No tracing of light rays takes place, just some distance calculations. Then, when you render the image from the camera's position, you just calculate each pixel's corresponding location in the shadow map, and use that to determine whether the pixel is in the light or in shadow, and color it accordingly. Again, no tracing of light rays is done, just distance calculations and such.

      Even in games like Doom 3 and Half Life 2 ray tracing is not done. While it might be possible to do low-quality raytracing on a GPU, the quality would probably be so low that you'd get better looking results from some other method.

      I hope this answers your question.

    38. Re:Yawn... by SuiteSisterMary · · Score: 1

      Remember that those shiney Pixar movies you see generally don't bother with ray-tracing (I think Finding Nemo did a little bit of it; the previous ones didn't) because, as has been said, you can get 'good enough' using rules-of-thumb and hacks, most of the time.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
    39. Re:Yawn... by Viking+Coder · · Score: 1

      [M]any of these features can be planned for by an artist rather than a coder.

      That's naive in the extreme. A coder will always have to be involved. If for no other reason than for optimizing performance, which is honestly no easier than writing a "modern 3D engine" as you described it.

      Now, if your point is that dog-slow rendering is "better" than fast rendering, then pick your fight elsewhere. But don't blame the GPU for being fast, especially since it is now just as capable of high-accuracy rendering and the full richness of a software raytracer!

      [Raytracing capabilities] streamlines the process and reduces the time it takes to get the product out the door.

      Which is why Pixar and Dreamworks do it. Oh, wait, they don't do it. Maybe that's because it doesn't streamline the process, and it doesn't reduce the time it takes to get the product out the door. Unless you somehow think that those people are wasting tens of millions of dollars with an inefficient process?

      Face it, polygons are the way to go.

      And even if polygons weren't the way to go, GPUs are definitely the way to go for all computer graphics (raytraced or not). End of story.

      --
      Education is the silver bullet.
    40. Re:Yawn... by Viking+Coder · · Score: 1

      simply wasn't general purpose enough to meet the needs of a high performance raytracer

      You don't know what you're talking about. Reread the specs, and go and read the Purcell papers that people keep pointing you to. And learn what a stream processor is, so maybe you can understand why the mathematics actually are general purpose enough to meet those needs. Just because you don't understand the capabilities doesn't mean that they don't exist.

      not just the vertex shader

      They're using pixel shaders to do ray-triangle intersections, i.e. all of the card's pipelines. Do your homework, before you start criticizing the work of an entire industry.

      --
      Education is the silver bullet.
    41. Re:Yawn... by AKAImBatman · · Score: 1

      Now, if your point is that dog-slow rendering is "better" than fast rendering, then pick your fight elsewhere. But don't blame the GPU for being fast, especially since it is now just as capable of high-accuracy rendering and the full richness of a software raytracer!

      What am I blaming the GPU for? I just want to reprogram it and make everyone's lives easier. Sure, the scene will need to be optimized by a coder who understands, but the artist should be capable of deciding what effects will work and which won't. Simply relying on the coder to create those effects AFTER modeling is done is an inefficient process at best. At worst, it makes the coder spend a lot of time on creating effects that are inherent in a Ray Tracing engine.

      And even if polygons weren't the way to go, GPUs are definitely the way to go for all computer graphics (raytraced or not). End of story.

      Again, I love the GPU. When did I EVER say that I wanted it to go away? I simply want to reprogram it for use as a Ray Tracer instead of a polygon rasterizer. The way I see it, those deep, parallel pipelines and texture units are EXACTLY what the RT Doctor ordered.

      Yeash. If you're going to crucify me, at least do it for what I said, not what I didn't say.

      --
      Javascript + Nintendo DSi = DSiCade
    42. Re:Yawn... by AKAImBatman · · Score: 1

      And learn what a stream processor is, so maybe you can understand why the mathematics actually are general purpose enough to meet those needs.

      It's not about whether the GPU can do the math or not. It's about whether the GPU is programmed to do the math for raytracing or not. Many RayTracing engines have twisted OpenGL a bit to get their ray tracing operations done. Which is fine since it gives them a performance boost. But this boost is insignificant compared to what could be achieved with dedicated GPU drivers. Ever notice how games tend to get slightly faster and better every time you install a new set of NVidia drivers? This is due to NVidia optimizing the GL code. The GPU hasn't changed, nor has its onboard memory. Merely the algorithms to produce the graphics have changed.

      They're using pixel shaders to do ray-triangle intersections, i.e. all of the card's pipelines. Do your homework, before you start criticizing the work of an entire industry.

      Because, you know, the pixel shaders are the ONLY programs running through the GPU. *sigh*

      You know, you might try calming down and having an intelligent conversation here.

      --
      Javascript + Nintendo DSi = DSiCade
    43. Re:Yawn... by Viking+Coder · · Score: 1

      AKAImBatman: "Gee, thanks Viking Coder for telling me about GPGPU and the Purcell paper."

      Viking Coder: "No problem, AKAImBatman."

      It's about whether the GPU is programmed to do the math for raytracing or not.

      This is a nonsense statement. I'm sorry, but it really is. That's like saying that, "the CPU is programmed to do the math for raytracing or not."

      I understand your argument, in that back in the day, a generalized CPU needed an FPU to do mathematics operations that the CPU could do in software... ...but what you're missing is that the GPU is exactly that missing piece of a CPU that you're looking for, designed for massively parallel applications like graphics.

      Hell, I don't even know why you're arguing with me. You said, "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." I've gone to great length to demonstrate to you that you're beeing lazy, since you didn't realize that it already was capable of doing raytracing - and a bunch of people have done it!

      But this boost is insignificant compared to what could be achieved with dedicated GPU drivers.

      Say something to back this up. This is your opinion, and it happens to be dead wrong. Go read articles on GPGPU, and read up on stream processing. The memory access and the order of operations is totally sufficient for raytracing, and no, graphics drivers aren't going to make a "significant" boost over and above the enhancement from moving from CPU to GPU.

      Because, you know, the pixel shaders are the ONLY programs running through the GPU. *sigh*

      *sigh* back at you. When you're doing advanced shading (like per-pixel lighting, or such things as ray-tracing, or treating the GPU like a generalized stream processor), the pixel shaders are doing all of the heavy lifting. It's like tsk'ing me for not mentioning the calculations that the chips on your SOUNDBLASTER can do towards getting better frames per second, when you're playing a game. They're insignificant, compared to the video processing.

      You know, you might try reading articles that people take the time to tell you about.

      --
      Education is the silver bullet.
    44. Re:Yawn... by Viking+Coder · · Score: 1

      I simply want to reprogram it for use as a Ray Tracer instead of a polygon rasterizer.

      SOMEONE ELSE HAS ALREADY DONE IT.

      How many times do I have to say this?

      Timothy Purcell at Stanford University did it two years ago.

      So stop wishing 'if it were only possible' to do something that people have already done. Read my link, and if you want to be polite, thank me for showing you where to find exactly the kind of information that you were complaining didn't exist.

      --
      Education is the silver bullet.
    45. Re:Yawn... by Mindcry · · Score: 1

      another poster mentioned memory bandwidth as a bottleneck... the bandwidth between an agp card and the cpu has even less bandwidth, and the amount of memory on graphics cards is usually well below system ram, making the process nto really seem like the best way to do things currently...

    46. Re:Yawn... by Viking+Coder · · Score: 2, Insightful

      This is like saying "Programming CPUs has become exceedingly complex because they stick to a 'floating-point' model instead of declaring vectors outright."

      I'm not even asking you to do it from scratch yourself - borrow liberly from people like Purcell, and from GPGPU.org, and from BrookGPU and from other stream-processing-on-GPU sources.

      When you say that you want a new "driver," I think you should really consider using a wrapper layer like BrookGPU - or just figure out how to do things the way Purcell did them. Don't get frustrated by the complexity. I'm not frustrated by the complexity of SSE2 instructions - I just use a compiler that takes care of that for me. Or I use a wrapper layer like the Intel Performance Primitives. I think you need to do the same.

      --
      Education is the silver bullet.
    47. Re:Yawn... by AKAImBatman · · Score: 1

      the bandwidth between an agp card and the cpu has even less bandwidth, and the amount of memory on graphics cards is usually well below system ram, making the process nto really seem like the best way to do things currently...

      The necessary geometry and graphics for RayTracing works out to pretty much the same cost as polygon stuff (sometimes even smaller). Given that today's cards have 64-128MB of RAM, the memory on the card is not the issue. The bandwidth can be an issue, but no more than today's graphics. It takes a significant amount of AGP bandwidth to pump the textures and polygons to the card in the first place. Then the memory bandwidth on the card has to be enough to feed 2-16 GPU pipelines.

      The GPU is very similar to a DSP chips in that it has very deep pipelines. A single jump instruction could result in a flush of one or more pipelines, thus stalling the processor. As a result, jump instructions are avoided at all costs. There has been some difficulty in modifying traditional ray tracing algorithms to avoid jump instructions. However, I (and many other graphics wizards) have been over the algorithms and it does appear that streaming ray tracer should be possible.

      --
      Javascript + Nintendo DSi = DSiCade
  5. The Gems books are classics... by tcopeland · · Score: 4, Interesting

    ...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 stuff the articles from Game Programming Gems II was very helpful.

    --
    The Army reading list
    1. Re:The Gems books are classics... by superpulpsicle · · Score: 1

      Yeah so many slashdot articles have come up with good books, good engines, free engines. After so many failed attempts, I always get no result in the end.

      Either this stuff is impossible to document, or it just plain changes too fast.

  6. Perlin by happyfrogcow · · Score: 3, Funny

    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!?

    1. Re:Perlin by Anonymous Coward · · Score: 0

      arbitrary bits of Perl

      Glancing at some sample code, I was under the assumption that all Perl was arbitrary.

  7. Where would we be without shaders by 192939495969798999 · · Score: 3, Interesting

    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!

    --
    stuff |
  8. Also Check Out... by th1ckasabr1ck · · Score: 3, Informative

    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..

  9. Forget nVidia or ATI... by bennomatic · · Score: 0, Offtopic
    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!

    --
    The CB App. What's your 20?
    1. Re:Forget nVidia or ATI... by Anonymous Coward · · Score: 0

      What's your point?

    2. Re:Forget nVidia or ATI... by Anonymous Coward · · Score: 0

      Point? This is /.! You don't need no steeeenking point!

    3. Re:Forget nVidia or ATI... by BokanoiD · · Score: 1

      You'd be surprised what people still get done with these specs. keep an eye on C64.sk for example to see some demo's. Being able to code to the bare metal certainly has it's advantages over todays videocards.

  10. That was not funny at all by Anonymous Coward · · Score: 0

    That's got to be the worst joke I've heard on /. in a loooong time.

    1. Re:That was not funny at all by happyfrogcow · · Score: 1

      That's got to be the worst joke I've heard on /. in a loooong time.

      Thank you! I'll be here all week! Enjoy your stay, be sure to tip your waitress.

    2. Re:That was not funny at all by glib909 · · Score: 1

      You're saying this about a joke that doesn't involve "In Soviet Russia ..." or "I for one welcome our ... overlords?"

      Personally, I for one welcome our new non-recycled format joke overlords.

      --
      Suudsu, that stuff is G-E-W-D.
    3. Re:That was not funny at all by Anonymous Coward · · Score: 0

      Personally, I for one welcome our new non-recycled format joke overlords.

      Yeah. Imagine a Beowulf cluster of them!

    4. Re:That was not funny at all by Anonymous Coward · · Score: 0

      bama gal

  11. brings to mind an old question I once had. by tloh · · Score: 3, Interesting

    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.

    --
    Stay sentient. Don't drink bad milk.
    1. Re:brings to mind an old question I once had. by kemapa · · Score: 2, Informative

      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.

      While it would probably be possible to use a GPU for general purpose number crunching, I believe it would make the GPU unable to send a signal to your monitor at the same time.

      I asked the same question back in the days of RC5-64 and I was told that it was not feasible for just that video signal reason. I was told I would not be able to use my video card while it was crunching.

      Correct me if I am wrong, though!

    2. Re:brings to mind an old question I once had. by man_ls · · Score: 1

      The readback rate on AGP is abysmially slow. That's why it's only for graphics cards.

      It's got an amazingly high downstream rate, GBps, but reading back from the card can be as low as 256 KB/sec in some models.

      Far too slow to do any kind of processing on a high-bandwidth stream at a time, although the circuitry of a GPU (matrix optimizations) would be useful in crypto, the rate at which data could be returned from the card would choke the stream, and the buffer would fill up, and you'd start losing data.

    3. Re:brings to mind an old question I once had. by DoctorDeath · · Score: 1

      Why do you think there was such a frenzy over terrorists stealing Playstation2s and Xboxs? They were afraid of the computing power of of one these high end gaming systems being used to provide cheap powerful computing solutions against us.

      --
      Sig temporarily out of service.
    4. Re:brings to mind an old question I once had. by adamofgreyskull · · Score: 1

      If you could utilise the GPUs of 2/3/4 PCI video cards, leaving your AGP card of choice to cope with the monitor, would that work?

      I have my doubts(but love playing devil's advocate), the overhead of managing everything may well negate any benefit of farming out work to the other cards. It would also shift the bottle-neck to the various communication channels, by increasing the traffic between components I guess.

      Not to mention the effort inherent in setting something like that...

    5. Re:brings to mind an old question I once had. by BoogieChile · · Score: 1

      One thing it could be very handy for is compression. Video compression is, of course, the first thing that springs to mind, but I guess other types of compression could work too, as long as there is a data path back out of the GPU, to the hard drive or wherever else you want that compressed data to go.

      For applications like that, the back channel isn't that much of an issue, because the data coming out of the process is so very much smaller, ie - a lot of data is being thrown away in the GPU

      Conversely, on the way in, the data is big. I capture video at 922x576, 25 fps from a dedicated TV card using Huffyuv - a lossless codec, and I get about 7.3 MB per second of data going into the capture file. That works out to about half a gig per minute. If I was to use no compression, it balloons out to about 25 MB/sec

      Then I use VirtualDub to run it through a filter or two, resize it with a biCubic transfer and compress it with xVid - With a 1 Gig Duron, the data's going in at about 750 KB per second, getting processed at about 1.8 frames per second and then going back out at (get this) 50 BYTES per second.

      If, instead my graphic card could up that by a factor of fifty rather than just sitting there (mostly) idle, I think it'd be great - no more waiting an HOUR to render down a 4-minute clip. If , instead of going TV-card->processor->hard drive it went TV-card->GPU(compress)->processor(filter)->hard drive, the recording could be done all in one hit.

      By the way - I can get an hour's worth of video into just under 75 MB and it's still quite watchable - About par with slightly older VHS tapes.

  12. Links by Anonymous Coward · · Score: 1, Informative

    http://graphics.stanford.edu/papers/rtongfx
    http://graphics.stanford.edu/papers/tpurcell_thesi s/
    http://graphics.stanford.edu/papers/photongfx

    (And not a karma whore in sight.)

  13. 386 emulator for GPU by Anonymous Coward · · Score: 1

    can someone just write an 80386 instruction set emulator for my nvidia graphics card so I can have a dual proc x86 system?

  14. Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 2, Interesting

    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.

    --
    Loading...
    1. Re:Hmmm,. I wonder if it is very nVidia centric? by ardor · · Score: 2, Insightful

      Cg is still very useful if you intend to develop cross-platform shader-driven graphics apps. Plus, its also API-independent, which makes it the only viable alternative to rewriting all shaders for each API if you are about to write some API-independent graphics code. Remember, GLSL support is still not widespread. Heck, even the ARB FPrograms arent supported on cards older than a radeon9500/geforceFX. If you do not want to develop half a dozen of different codepaths, use Cg.

      --
      This sig does not contain any SCO code.
    2. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      It is ridiculous, imho, to claim that something has value as being API dependent when it is HARDWARE dependent (which is much, much worse.) If you're going to learn something (the purpose of this book) and GLSL is out and available for use, use it. If you're looking to put code into production, you're not going to want to use Cg in any case unless you can say "you MUST use nVidia hardware to run my application."

      --
      Loading...
    3. Re:Hmmm,. I wonder if it is very nVidia centric? by ardor · · Score: 1

      Dude, I'm using Cg. And i do have a RADEON 9600 PRO. Wow, am I using some magic? Or is it using the OpenGL ARB vertex/fragment program extensions? So much for your hardware dependence.

      --
      This sig does not contain any SCO code.
    4. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      Dood,apparently you're not aware that Cg optimizations (when producing HLSL or vertex/fragment programs) are HEAVILY nVidia focused and tend to produce rather poor code for the Radeon series (even, mysteriously, when converting to HLSL which has the same syntax, hmmm?) Ergo, calling it hardware independent is ridiculous.

      In any case, the nVidia Cg compiler produces much more inefficient code than you would get from the HLSL compiler; ergo, if you're actually interested in producing games, learn GLSL/OSL and learn HLSL. Pick one to work with first. No reason at all to use Cg because in a production environment you wouldn't in any case.

      --
      Loading...
    5. Re:Hmmm,. I wonder if it is very nVidia centric? by The+boojum · · Score: 1

      I've looked over this book and I'm planning on getting a copy of it, even though I prefer vendor-neutral API's (and use ATI hardware myself) when I actually do real-time stuff. From what I've seen, yes, most of the pieces of example code are Cg or nVidia oriented. The concepts are pretty universal however, and shouldn't be too difficult to adapt.

    6. Re:Hmmm,. I wonder if it is very nVidia centric? by PixelSlut · · Score: 1
      Fine, but this isn't a production environment. These are examples in a book. Your original statement is absolutely ridiculous.
      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.
      This is the dumbest thing anyone has said about this book. The book is bad because you disagree with their choice of shading language? Hardware shaders are not complex things, and if you know anything at all about even one of them (HLSL, Cg, or GLSL) then you can look at source by any other one and understand what's going on. The point of this book was to show some cool ideas for stuff that can be run using hardware pipeling programs. If the gems themselves sucked, then fine.. but their choice of implementation language has absolutely no impact on whether the gems suck, so I think you're just blowing smoke out of your ass and trying to talk trash about NVIDIA. If I was a moderator on Slashdot, I'd mark you down for trolling.
    7. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      Yes, the book is bad because it purports to be a book about 'GPU programming' "Gems", when it should be titled "Cg Programming" with a little mention of other shader languages for consideration. Talk about dumb...

      --
      Loading...
    8. Re:Hmmm,. I wonder if it is very nVidia centric? by ardor · · Score: 1

      Currently GLslang is not an interesting option due to the fact that almost no drivers support it yet.
      HLSL, well, I dont use D3D, so its of no use for me.
      Cg is a valid choice I have if i want my shader code to work on my ti4400 and on my radeon9600. The only other option is to rewrite ALL shaders for both cards, which is a real pain in the ass (especially the fragment shader on the ti4400, which has to be constructed with NV texture shaders + register combiners). Fortunately, the ARB vertex programs are supported on both cards.
      Another option would be to rely solely on ARB vertex/fragment programs. Use Cg to create the ARB program code, optimize the code by hand, and there you go.
      However, I wonder if there is somebody who created an ATI profile. Since Cg is open source, it should be possible.

      --
      This sig does not contain any SCO code.
    9. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      I'm not particularly anti Cg; however, what is it that you actually use it for? In house tools or applications, no problem using it imho. Public applications and commercial games? It is a bad choice afaic.

      My original complaint about the book is that a book is being published which purports to be a guide to programming GPUs and yet rather than use GLSL or HLSL it uses a private corporations shading language.

      It is like someone producing a book on C++ and making Microsoft friendly examples rather than maintaining no conflict of interest.

      --
      Loading...
    10. Re:Hmmm,. I wonder if it is very nVidia centric? by PixelSlut · · Score: 1
      No, you're wrong. It's not about Cg programming. It's about the underlying algorithms and techniques. They had to choose languages to implement the techniques in, and it apparently happens to be the language you don't like. Oh, "boo hoo" for you!

      This is a Gems book, written by numerous people. These people tell the editor, "Yeah, I have a cool GPU technique that would make a good 'gem' for the book." and they say, "Okay, give us an implementation." and that happens to be in either HLSL or Cg.

      The fact is, there were a few options they had for how to implement the code. They could have implemented in Cg, GLSL, HLSL, or any number of assembly languages. If they used GLSL, they would ensure that nobody but 3Dlabs Wildcat users could test out any of the code at the time of publication. If they used the assemblies, they would ensure that nobody could just look at the code and understand what was going on. So using any high-level language is a superior choice over this. It just seems that they didn't pick the one that is your favorite, so you're whining like a little bitch.

      If you see a book that claims to be about game programming, and it's written in C++.. then is that book about game programming in C++? Some other guy comes along and says, "That book should be called 'Programming games in C++'". Is he right, or is he a whiny little bitch because he doesn't like C++?

    11. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      Actually, the guy who comes along and says "It should be called Programming games in C++" is correct. You seem to think it is pedantic to believe that many book titles seem to be misleading (even if only somewhat.)

      As for why they used Cg, surely you're not stupid enough to believe they just 'picked one', or (from reading your post) perhaps you are. Do you know who the author works for? Do you know what company pushes Cg? It isn't some 'conspiracy theory' but it IS a conflict of interest given that it VERY explicitly claims to be (1)a Gems book when it isn't actually part of that series, and not even from the same publisher (A little misdirection there) and (2)the book purports to be about programming your GPU when it is actually (I looked through it at B&N the other day and the samples [especially regarding optimization tricks] are VERY nVidia-centric) about how to write Cg. This doesn't make it a poor book, but it is certainly deceptive. FFS, if this was a Microsoft book title, people would be going nuts on Slashdot.

      As for no one being able to use GLSL, you're obviously not very knowledgeable regarding GLSL. For instance, you can use GLSL with ATI cards as of 6 months ago. Early support was pretty damn sketchy, but 4.5+ Catalyst drivers are pretty good. Another example of your ignorance is that nVidia themselves have released drivers which support GLSL.

      Perhaps you should (1)learn how to discuss your differences in a more adult manner and (2)spend the 30 seconds on google to validate some of your more ridiculous assertions.

      Have a nice day :). Great name by the way. I'm sure it is quite indicative of your personality.

      --
      Loading...
    12. Re:Hmmm,. I wonder if it is very nVidia centric? by PixelSlut · · Score: 1
      Actually, the guy who comes along and says "It should be called Programming games in C++" is correct. You seem to think it is pedantic to believe that many book titles seem to be misleading (even if only somewhat.)
      I guess we'll just have to disagree on this one, because I think a book can be written about a topic that is not the language used to implement the topic of discussion. I don't believe every book needs to advertise on the title what language they use to implement the thing they're interested in discussing. I don't see anything wrong with it when a book does say "Doing such and such in C++", but usually those books are very interested in the details of implementing the topic in that language. There isn't a great deal of implementation detail differences between GLSL, HLSL, and Cg. Yes, I'm absolutely aware of who the authors work for and I'm not naive in thinking that they did not pick the language because of that association with NVIDIA. But I just don't give a shit about that because the information that's contained in the book is so easily applicable to any other shading framework. I just think it's ridiculous to trash the book because you don't like the language. But I find it more likely that you just don't like NVIDIA for some fanboy sort of reason, and make silly remarks and assumptions for those reasons.
      are VERY nVidia-centric) about how to write Cg
      No, you're just wrong here. I own this book and have read it. It is not about the Cg language, but it uses it. It does not even contain a chapter on syntax for Cg or HLSL. There isn't even a fucking appendix chapter about language-specific details. You're just full of shit here, I'm sorry. If you buy David Eberly's "Game Physics" book, it includes source that is written in C++, but it does not teach you C++, nor does it try to. It is about game physics, not about the language.
      given that it VERY explicitly claims to be (1)a Gems book when it isn't actually part of that series
      Which series do you mean? You probably mean the "Game Programming Gems" series, which is published by Charles River Media. But they don't own the concept of a "gem" book, and in fact they were not the first ones to do that. There was a series before that called "Graphics Gems" that was published by Academic Press.
      As for no one being able to use GLSL, you're obviously not very knowledgeable regarding GLSL. For instance, you can use GLSL with ATI cards as of 6 months ago. Early support was pretty damn sketchy, but 4.5+ Catalyst drivers are pretty good. Another example of your ignorance is that nVidia themselves have released drivers which support GLSL.
      I'm well aware of the level of support by both NVIDIA and ATI, and so far I'm not fully satisfied by either of them yet, although I am very optimistic that support will improve shortly. I've been working a little bit with the beta drivers from NVIDIA, and they're not too bad at all, but they're not fully there yet. ATI had support for GLSL before NVIDIA, but theirs is farther behind NVIDIA's right now. 3Dlabs was the first to have drivers (for obvious reasons, being that they designed the language) and they are the only ones who have really robust, fully-implemented drivers. We have worked with the GLSL implementations from all three at work, so I'm enough aware of the quality levels of the three that I feel comfortable making statements about them. That aside, at the time the book was being written then certainly 3Dlabs was the only vendor who had working GLSL drivers. It doesn't matter what level ATI and NVIDIA have now, the book isn't being written now.
      Perhaps you should (1)learn how to discuss your differences in a more adult manner and (2)spend the 30 seconds on google to validate some of your more ridiculous assertions. Have a nice day :). Great name by the way. I'm sure it is quite indicative of your personality.
      It's a little amusing to see you claim I'm discussing things in a less than adult manner, then see you turn around and try to make some sort of insult based upon my username. :)
    13. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1
      I guess we'll just have to disagree on this one, because I think a book can be written about a topic that is not the language used to implement the topic of discussion. I don't believe every book needs to advertise on the title what language they use to implement the thing they're interested in discussing. I don't see anything wrong with it when a book does say "Doing such and such in C++", but usually those books are very interested in the details of implementing the topic in that language. There isn't a great deal of implementation detail differences between GLSL, HLSL, and Cg. Yes, I'm absolutely aware of who the authors work for and I'm not naive in thinking that they did not pick the language because of that association with NVIDIA. But I just don't give a shit about that because the information that's contained in the book is so easily applicable to any other shading framework. I just think it's ridiculous to trash the book because you don't like the language. But I find it more likely that you just don't like NVIDIA for some fanboy sort of reason, and make silly remarks and assumptions for those reasons.

      Assmasher - What an assinine comment. I think a book can be written about a topic that is not the language used to implement the topic of discussion. What this has to do with our discussion I don't know because you seem to think I have a problem with the fact that the book uses Cg to implement ideas, I do not. I have a problem with the fact that the book is presented as a Gems series type of book, written by an nVidia employee, entirely written using Cg rather than an open shader language such as GLSL, and because the title makes it sound like it is vendor neutral when it is anything but.

      are VERY nVidia-centric) about how to write Cg

      No, you're just wrong here. I own this book and have read it. It is not about the Cg language, but it uses it. It does not even contain a chapter on syntax for Cg or HLSL. There isn't even a fucking appendix chapter about language-specific details. You're just full of shit here, I'm sorry. If you buy David Eberly's "Game Physics" book, it includes source that is written in C++, but it does not teach you C++, nor does it try to. It is about game physics, not about the language.

      Assmasher - First, I'm not wrong, and I'm not surprised that you won't admit to what an objective and neutral reader would acknowledge, that the book is very nVidia centric unnecessarily. You're pedantry is even more apparent when you can't keep yourself from using profanity in a simple discussion. What exactly am I full of shit for? I asserted that it is nVidia centric, it OBVIOUSLY is. You can argue whether that is bad or not, but you can't argue that it isn't accurate.

      given that it VERY explicitly claims to be (1)a Gems book when it isn't actually part of that series

      Which series do you mean? You probably mean the "Game Programming Gems" series, which is published by Charles River Media. But they don't own the concept of a "gem" book, and in fact they were not the first ones to do that. There was a series before that called "Graphics Gems" that was published by Academic Press.

      Assmasher - Surely you found it obvious that I was referring to that series, yes? More pedantic behavior? Of course they don't own the CONCEPT of a gem book, just like George Lucas doesn't own the CONCEPT of a war amongst the stars, but you sure can't go selling things with the phrase Star Wars on them without arousing suspicion.

      As for no one being able to use GLSL, you're obviously not very knowledgeable regarding GLSL. For instance, you can use GLSL with ATI cards as of 6 months ago. Early support was pretty damn sketchy, but 4.5+ Catalyst drivers are pretty good. Another example of your ignorance is that nVidia themselves have released drivers which support GLSL.

      I'm well aware of the level of support by both NVIDIA and ATI,

      Assm

      --
      Loading...
    14. Re:Hmmm,. I wonder if it is very nVidia centric? by PixelSlut · · Score: 1

      I think a book can be written about a topic that is not the language used to implement the topic of discussion. What this has to do with our discussion I don't know because you seem to think I have a problem with the fact that the book uses Cg to implement ideas, I do not.

      You gave every indication before that you thought this book's content was not valuable, and it seemed that your reasoning was simply because it was written in Cg. From a previous post:

      lol... Why did they bother to use Cg at all? There are books on HLSL and OSL that are more valuable than this one.

      I don't know if we're talking about different things or what now, because much of what I was arguing (originally, before I got frustrated and off topic; for that, I'm sorry) was based upon these statements. The other books that are about HLSL or GLSL are more valuable if what you're trying to do is learn how to write vertex and fragment shaders. For example, the OpenGL Orange Book is the best book if you want to learn how to write GLSL, and it's additionally very good for demonstrating some example shaders. But I don't think you could ever claim that it's a "gem" style book.

      I have a problem with the fact that the book is presented as a Gems series type of book

      How would you have presented it? It's a series of mostly independent ideas that can be roughly grouped together in sections. The Game Programming Gems books are the same.

      written by an nVidia employee, entirely written using Cg rather than an open shader language such as GLSL, and because the title makes it sound like it is vendor neutral when it is anything but.

      Okay, yeah. You're right. Although I hate to defend them on this particular count, because I do agree with you here, I can't help but point out that the book has an extremely obvious, fairly large NVIDIA logo on the cover, so I don't understand why it's that big of a surprise. :)

      But, more importantly than that is that the sort of people this book is aimed at probably don't care that much. If they know anything at all about programming the 3d pipeline with vertex and fragment shaders, the NVIDIA-centric approach is a pretty insignificant thing to overcome. The fact is that in production environments, you end up writing the same shaders multiple times for the major vendors (ATI and NVIDIA at least) anyway, even when you're writing in a supposedly neutral language like HLSL.

      My complaint in the previous message was not really in that you were calling it NVIDIA-centric, but that you seem to say that the book is about writing Cg, and it is not. That's why I say you're wrong and point out that nowhere in the book do they ever discuss the syntax of Cg, which they most certainly would do if they were trying to teach you Cg. My quote in that section of my last post should have removed the part about NVIDIA-centricity, but I was lazy and didn't do that. Sorry.

      Assmasher - Actually the ATI drivers are pretty good, don't know about nVidia's drivers but I wouldn't expect them to work their tails off to kill Cg for you.

      Some of the things we were working on had problems on the ATI drivers, and other things had problems on the NVIDIA drivers. Overall, I feel that both of them are beta quality but my feeling is that NVIDIA's will be superior in the long run. The main reasoning for this is because NVIDIA has a pretty sophisticated compiler system in the driver that has a single optimizing backend compiler, and three front-end compilers for the different highlevel languages. I think gcc does something similar to this, but I'm not positive since I've never really looked at their code. But since the three shader languages are not complicated in themselves, so I think the backend is the main important thing. With this new framework, GLSL is likely to perform just as well as Cg or HLSL, once the remaining kinks are worked ou

    15. Re:Hmmm,. I wonder if it is very nVidia centric? by Assmasher · · Score: 1

      Good points, I guess I wasn't very clear in the beginning that what I didn't like about the book was the (imho) feel that they were intentionally making the book sound vendor neutral and part of the 'gems' series. It has value, just as Shader X does, as a reference for shading in general (because ideas are not language specific.) I'm sure it does have use, I just took issue with the presentation of the book as such.

      --
      Loading...
    16. Re:Hmmm,. I wonder if it is very nVidia centric? by PixelSlut · · Score: 1
      Good points, I guess I wasn't very clear in the beginning that what I didn't like about the book was the (imho) feel that they were intentionally making the book sound vendor neutral and part of the 'gems' series. It has value, just as Shader X does, as a reference for shading in general (because ideas are not language specific.) I'm sure it does have use, I just took issue with the presentation of the book as such.
      Yeah, I understand. But at the same time, from their perspective as publishers and writers, it would be a poor move to put Cg or NVIDIA in the title of the book for a few reasons. If it makes it too obvious that it's NVIDIA-centric, too many people would think that it's only useful for NVIDIA hardware. Furthermore, if the title implied that the book was about the Cg language, we would have a lot of people complaining that the book says it's about writing in Cg, but doesn't have any information on the language itself, only complicated examples. So I guess there's no perfect solution here. They're damned if they do, and they're damned if they don't. :)

      But I also don't think they tried to imply that they were part of "the gems series", because like I said before, there are already at least two existing 'gems' series. There was Graphics Gems by AP Professional, then Game Programming Gems by Charles River Media. I don't see any reason why they can't begin a new 'gems' series for shader development. Like the original review said (I think it was this review), shaders are really the perfect things to make into a 'gems' style book or series.

  15. correction: 1ray x 500x500 x 4fps by Speare · · Score: 1

    (Math correction: 1ray per pixel would be 500x500 pixels at 4fps.)

    --
    [ .sig file not found ]
  16. I think you're wrong by roystgnr · · Score: 2, Insightful

    Or, at least you're wrong about modern programmable GPUs; you might have been right about the first generations of 3D cards.

    See this paper for some examples which not only use the GPU simultaneously for graphics and number crunching, but which use the graphics to give real-time output of computational fluid results.

    The only remaining problem I remember is that the bandwidth to current video cards is very asymmetric, which is fine for video games that just push a lot of data to the video card but not so good for numerical physics that also wants to ask for a lot of data back. I think at least one of the new PCI-Extended/Express/X/whatever standards is supposed to fix this.

    1. Re:I think you're wrong by Minna+Kirai · · Score: 1

      you might have been right about the first generations of 3D cards.

      But regarding the first generation of 3D cards, the question is irrelevant- because those cards had NO 2D output ability, so you always had a separate 2D card running anyhow.

  17. GPGPU.org by Hortensia+Patel · · Score: 1

    Try GPGPU.org - "General-Purpose Computation Using Graphics Hardware". Useful clearinghouse for this sort of thing.

  18. B&N? Ripoff! by TastyWords · · Score: 3, Informative

    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 Results and BookPool

    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 the listing from Froogle (just in case you haven't used it yet)

  19. X Windows is your friend by billstewart · · Score: 1
    If you've got a fast machine with a high-end GaM3Rz GPU, you've probably got an older machine lying around which was your former cutting-edge game platform. So fire it up with X Windows, and let your apps run on your fast machine where you've got the GPU, assuming you've got some kind of Unix OS on the fast machine (Linux, *bsd, etc.) (This trick is unlikely to work if you're running Windows on the fast machine - most of the solutions like VNC, Carbon Copy, etc. are likely to require you to be running the video screen. If your fast machine is running Unix and the slow one is running Windows, that's ok - you can use VNC on both, or run Cygwin X Windows on the slow machine, or just use ssh to run text sessions on the fast machine.)

    Alternatively, if you've got a PCI video card around, put it in your fast machine as a second monitor.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  20. Raytraced Nethack? by billstewart · · Score: 1
    Nethack is open source, so you _could_ add raytracing to it, but I'm not sure that it'd buy you that much :-)

    You hit the Umber Hulk -more-
    His pixels shimmer gracefully -more-
    The Umber Hulk hits -more-
    You die -more-
    You leave a good-looking corpse

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  21. Followup volumes will deal with OGPU gems, by dpbsmith · · Score: 1

    Cheka gems, NKVD gems, MVD gems and KGB gems.

    Cue "in Soviet Russia" jokes...

    --

    "How to Do Nothing," kids activities, back in print!

  22. Re:Perlin noise URL right here by fprog · · Score: 0

    Dupe!

    Of course, you can find it dude, it's right here or here.

  23. Perlin Performance by andr0meda · · Score: 1


    Ken Perlin actually sang a song at SIGGRAPH 2002 before he presented his "Improving Noise" paper, and didn't even fail to be funny, sadly I can't find the text anymore, but it was hillarious. This guy manages to bring technical stuff to a tired audience and getting the whole crowd to laugh with his witty lyrics, on the subject of something as interesting as noise.

    Ken Perlin is also the guy who has brought together much of the talent that is responsible for the ongoing success of Pixar. I guess you could say he has a no(i)se for noise that makes the difference.

    --
    With great power comes great electricity bills.