... looks like a long way to a racing game :-)

Is it just the crappy Youtube quality, or does the performance of that demo really suck that hard? Very disappointing if these guys can't get any faster than that on such (theoretically) potent hardware.

Really? I would have thought the stream-based processing concept would allow some interesting scaling tricks for raytracing. Or are you referring to the terrible memory access architecture (which I can see being a massive problem if coherency tricks are not exploited well)?

[edit] Never mind, hplus0603 ninja-answered my question [smile]

If your scene is small-ish, you can use all the SPUs for ray tracing. However, if your scene is real-size, the local memory on the SPU isn't enough.

The sad part about Linux on PS/3 is that:
1) You only get access to 256 MB (because the other 256 MB is a bank shared with graphics)
2) You don't get access to the 3D hardware, only a "dumb" 2D frame buffer

If you could use some features of the 3D hardware (say, blitting), you could do really cool things!

Now if the PS3 architecture is ill-suited to raytracing, it makes me wonder how well one of those 80-core intel chips would handle raytracing. (The intel chips are not yet release of course - still a few years down the road, if they ever do come out).

The problem isn't having enough CPU core time to throw at it. The problem is keeping memory throughput high enough. Raytracing has very nasty memory access patterns which thrash the living hell out of current CPU cache architectures, and generally strangle the memory bus. Special considerations for this must be made.

There are some coherency patterns which can be exploited to try and control the memory access patterns, but they only generally work on first-order rays, so anything with reflections, dynamic light, etc. (i.e. the stuff we want to use raytracing for in the first place) is not going to benefit much.

We are most likely to see performant raytracing appear on a GPU-style architecture with a dedicated memory bus and massive parallelization (i.e. not just separate cores running different blocks of the image, but parallel processing on many scales all the way down to SIMD-style operations). It is not yet clear whether or not current GPUs will be able to hybridize sufficiently to do both scanline rasterization and practical raytracing on single hardware, but definitely expect RTRT (and, far more importantly, RTGI) to appear from the video card people, not the CPU people.

As Sneftel alluded to, an ASIC is also a strong option, but the expense and difficulty of marketing such a product are immense, so chances are we will not see any such ASIC product for consumer use. There have been some academic efforts in this direction (i.e. SaarCOR's project) but frankly they made some poor decisions up-front and will probably never have a marketable product. I haven't heard anything from them in years, so it's thoroughly possible that they're already gone.

I also noticed that the performance didn't seem that great, especially since they had to connect three machines. If we assume that a "typical game model" is 15K polys (which is an absurd figure), then their model is around 1.125 million. 1 million or so polys is doable by RSX in realtime at full speed, while still doing HD and shading and everything.

RTRT's got a long road ahead.

Very bad example scene/object has been chosen. Similar effects have been accomplished years ago using fixed-function pipeline. Since PS3 is a gaming platform, you`ll rarely see the cars from such a small distance. Besides, the current shader techniques are more than adequate qulity for this type of effect.

They could have demonstrated some other effect (that is hard to do on current generation of gfx cards) or some extremely complex scene which would make current graphics crawl, but a car ?

Maybe next time.