First yes, Pixar has the patents, they've already killed Exluna's Entropy a few years ago.
Second, PRMan isn't just fast, in fact it is a quite slow renderer when you try to do simple things like rendering a sphere or a single texture mapped character. It only becomes faster than other renderers as you increase scene complexity to hideous levels, add heavy displacements and a good amount of film quality motion blur and render it at high resolutions. The entire renderer has been designed with such complexity in mind.
Compared to a GPU-accelerated approach, PRMan is dead slow.
The problem with micropolygon-based rendering is that it is a very complex approach, which is hard to accelerate in hardware.
The basic workflow is like this:
- Bound all primitives and test bounding box size; if it's too big, split the primitive in two and put them back in the queue; if the bounding box isn't visible, throw the primitive away.
- Once all primitives are bound, they are diced into micropolygons totally independently. Each micropolygon is usually smaller then a pixel, and the resulting tesselated primitive is called a grid.
- Grids are shaded independently, first displacement is evaluated, then other shaders.
- After shading the grid is busted into individual micropolygons for the hiding routine: bounding, visibility test, and then sampling (this is the nice AA part, using stochastic sampling). Each pixel's every sample location point will store the color, opacity and depth for the micropolygons there.
- After all micropolygons are visibility tested, samples are composited together to get final pixel colors.
This also results in a couple of problems, apart from speed and fast displacement/motion blur.
Visible sample data is huuuuuge. Even a 64*64 bucket can consume dozens to hundreds of megabytes of data, sometimes studios have to lower the bucket (tile) size to 32*32 or even smaller. Transparent objects take a loooong time to render (typical case: particle smoke/fire/blood effects).
As far as I can see it's a pipeline that has several points where random memory access is a must - unlike traditional hardware rendering approaches. This is a significant problem that can not be overcome in today's GPUs.
Getting the SPEs to work on such a REYES renderer will be probably too slow, once again because of memory issues. But I'm no expert at this part so I'll leave it to the resident coders to evaluate the issues...
