Slashdot Mirror
PS3 Linux Performs Real Time Ray Tracing
fistfullast33l writes "A video posted on You Tube shows three PS3s networked together to perform Real Time Ray Tracing. Keep in mind that PS3 Linux runs in a hypervisor, so the RSX graphics chip is not being used at all. Even more impressive, PS3 Fanboy is reporting that Linux also limits the number of SPEs to 6 at once, so not all the horsepower on each of the PS3s is being utilized. According to the You Tube Summary, IBM Cell SDK 2.0 is being used for the IBM Interactive Ray-tracer (iRT). This apparently was done by the same team that presented a tech demo at GDC 2007 of a Linux PS3 rendering a 3 million polygon scene in real time at 1080p resolution."
PS3 Fanboy is reporting that Linux also limits the number of SPEs to 6 at once
That is incorrect - Linux does not limit the SPEs - Out of the 8 available SPEs, the PS3 hardware disables 1 and one is reserved for the hypervisor leaving 6 for Linux running atop the hypervisor.
The Linux PS3 never rendered a 3 million polygons scene in real-time, it decomposed the scenes into batchs that were dispatched to blades to do the rendering and the result brought back to the PS3.
It's written clearly in the article, please read it before you post about it.
Note that the RSX (the graphics powerhouse) is not being used at all and could cut things down. Real time ray-tracing on a lower level (say 720p) may be feasible on one PS3 using both chips. You won't run your game with it (unless you render at 480p and upscale or something), but you could use it for cut-scenes or menus or other things where you don't have the overhead of traditional games processing (AI, etc.).
Also, one SPE on each console was dedicated to compressing the resulting image (to save bandwidth), and an additional SPE was used on the client to decode the images. That means there were 5 + 5 + 4 = 14 SPEs doing actual ray-tracing. That's just a hair over 2 machines if they didn't have to deal with the encoding/decoding process. Add the RSX in and this looks like it may be feasible to me (again, not for game-play where you have to run AI and such).
Still, quite cool and shows you what a PS3 is capable of in some situations.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Umm, let's take a look at what you're saying there...
know there's been some limited applications of realtime raytracing in gaming. IIRC your temple in Black & White had some in the ceiling
Umm, I think you have Radiosity confused with ray tracing.
I don't think this is very exciting, however. It's not like it has gaming applications; you need three PS3s to get it done. Wake me up when one PS3 can do realtime raytracing in-game.
Then you must not know much about computer graphics. I doubt you could have done this with the PS2 or the XBox. The fact that a next gen machine can do this is very interesting, especially in a distributed fashion over the network. Distributed computing really is the future, and may someday take place inside game consoles as well. IF you have a spare processor and your buddy doesn't, is it efficient for him to borrow your CPU time? This is definitely a discussion that is occurring in normal computing space, let alone console gaming.
Not to mention, this isn't being done with the Sony SDK. This is done using free tools available via the internet. A college student could build this for a research project if they wished. This is proving that Sony allowing people access to Linux on the machine really is working. It counters the argument of XBLA's framework being the best thing ever. In fact, they could release this code as part of the GPL for free and it wouldn't be encombered by any Microsoft system or Sony system whatsoever.
Raytracing, by definition, is not hardware-accelerated. Of course the RSX isn't being used.
Where is, if I may ask, this 'definition'?
Certainly not "free" exactly. But in general, as long as you're using a good acceleration structure and can hold everything in-core, performance is roughly O(lg N) in the number of polygons. So the speed hit going from 50k to 100k polygons would be roughly equivalent to that of going from 100k to 200k. That's where the scalability of ray tracing comes in. There's still going to be quite a difference between one big polygon and 100k of them.
You'll also find that most ray tracers exhibit the same performance variation between facing a wall and facing a full landscape. It may not be as dramatic due to the relatively high constant of proportionality for a software ray tracer vs. a GPU but it's still there. A large part of that is probably just cache performance -- you'll have a lot more cache hits facing the wall.
Reflection-wise, you've got the right idea -- there will be a decent speed hit for them. But you've got it backwards. Doing a good job of computing color bleed effects require a ray tracer which supports global illumination and that can take astronomically more rays to compute than a decent implementation of basic specular reflections. You probably need at least 100 rays/pixel or more to even have a prayer of not having any excessively noisy image. Ray tracing is a point-sampling technique which means that any time you have any sort fuzzy/soft kinds of effect like ambient occlusion, glossy reflections, soft shadows or color bleed from indirect illumination.