[snprbob86]

Most modern high-end offline rasterizers aren't forward renderers, or deferred renders, _or_ ray tracing. No, they are typically radiosity renderers: http://en.wikipedia.org/wiki/Radiosity

Put simply is that ray-tracing is a per-screen pixel ray which is quite good at glossy surfaces with predictable lighting and plastic appearance. Radiosity, on the other hand, simulates actual light photons/waves. It is slower and more computational intensive, but it produces far more realistic results. In particular, it is good at lighting/shadowing, and is more directly applicable to rendering non-plastic surfaces, including sub-surface scattering (like flesh or hair).

All that said, REAL modern renderers, are wacky hybrid of every technique :-P

[shader]

You're right, I forgot about the radiosity - but couldn't that still be split up to multiple cores per frame? i.e. simulate one "bundle" of photons per core, and then presuming that you're not too badly i/o bound, you should be able to do some sort of map/reduce. Each would generate a separate scene of light, and you would add them all together to make the final frame.

[snprbob86]

Yes, it can made data parallel, but not nearly as easily as ray-tracing. Ray tracing is easily parallelized by dividing the screen into sub renders. Each box renders a different NxM segment of the final image. This approach doesn't work for radiosity because each patch is dependant on the computations of other patches.

The primary trick used to parallelize radiosity is to partition the scene spatially. Treat the virtual polygons which separate the rooms as light absorbers. When the room is finished with all of the available light, send the light absorber across the bus as light emitters to the other processes rendering the other rooms. Iterate back and forth until the light absorbers absorb under a threshold of light.