Ray Tracing on Programmable Graphics Hardware (RSX)?

I kind of lost hope that this sort of thing would ever happen back at SIGGRAPH 2001. A few minutes in discussion with David Kirk, and the moment I spoke my mind that a transition to raytracing hardware would be a necessity in the long run, he pretty much blew his top and screamed bloody murder at me as if I'd shot his wife or something. All in all, leading to his evangelizing the idea that shader hardware will ultimately evolve to the point where it will do everything that ever needs to be done from raytracing to helping you lose weight.

In any case, it's not really wrong on nVidia's part to want to perpetuate the same IP they've been pouring so much money into, but an attitude like that makes me wonder if an nVidia buyout of the saarcor IP wouldn't be one meant to squelch the concept in the same way Alpha was bought out in order to kill it.

ATI's Orton took a more rational approach in my mind. He at least admitted that there would necessarily have to be some sort of paradigm shift, if not to raytracing specifically. He at least seems to think something will subsume both raytracing and rasterization. Maybe someday we'll do everything volume rendered, but I think I'll wait for video cards with 512 GB of RAM first.

 

If Cell can do almost real-time raytracing, that's fine, but in PS3 you have a GPU too. Will there be anything RSX can help in the process?

 

i think the RSX can help on the texture mapping, texture filtering, etc. when the CELL used on ray tracing .

 

I guess this could be done. When they are able to port their system to a different chip (cell) in 2 weeks, it should be possible to involve RSX as well ?
Looking at the RPU chip cell could do the ray traversal and RSX the rest maybe...that prototype has at least a few similarities to the PS3 architecture...

Required memory is not listed though.

 

I would be relatively easy to use RSX to shade a scene like in a common deferred shading scheme (but this time CELL would be working on the first pass, not the GPU), too bad it would be easy only if CELL stops its per pixel work after first hit..

 

I severly doubt Cell will be raytracing games, even if possible, as there'd be nothing less for actual game content other than visuals! But ray-traced extras might become common occurence, with a SPE dedicated to adding true reflections perhaps to a scene conventionally rendered on RSX.

Plus, I'll wait and see just how 'realtime' this is, though 20 fps full-scene renders might comfortably be got up to 60 fps on some limited surfaces.

Also, great news they got it working in 2 weeks. Can't be THAT hard to write for Cell.

 

Raytracing will use SPEs primarily with little to no intervention from PPE, so if you are comfortable with PS2-level in-game behaviour, I suppose PPE can handle that game content. Anyway getting over 30 fps and mem usage will be bigger issues so I don't argue how it's useful for games in terms of reality.

 

Would it be PS2-level? It's clocked 10x higher, and between the PPE and it's VMX unit, it should more than match the functionality of the PS2 mips core and one VU, no?

Of course, this relates to all scenarios where all the SPEs are used for graphics tasks, not just raytracing. I agree that (general) RT in games is highly unlikely.

 

well, since I wasnt even aware of such technology back in 2001, I didnt have the chance to lose hope

perhaps Sony will force the issue and themselves partnet with or buy out Saarcor. one thing I will say about Ken, he is a visionary, and is not afraid to have new ideas.

the very fact that Saarcor has ported their technology to Cell is an eye-opener, and gives me hope that a major advance will happen for the PS4 generation - since they're beginning to work on this more seriously with Cell even before the PS3 generation has started, I think a major advance could happen within 7 years in time for PS4, if not then PS5. still a long way away, but no long the infinite, distant future

nevermind my ramblings, just woke up and have no coffee in the house today, so what ive said is probably an incoherent mess

 

Too bad that Nvidia or Ati will probably either ignore it or squelch it because with there resources they could greatly accelerate the the project.

Each of cells spu's also have vastly greater memory bandwith and possibly greater or equal Flops as the RPU. Though that doesn't account for the posibilty of the hardwired functions in the RPU.

 

nAo - what about storing N hits, each in a separate tile sized texture, then rendering the tile N times with these textures as input (Nth hit to 1st) and blending results? Something a little different would have to be done for surface to light rays...

The most interesting thing about raytracing to me is how dynamic scenes/animation are handled. (I couldn't help noticing how skimpy the saarcor videos were in regards to animation).

IIRC saarcor is using a static kD tree for scene geometry and tracing a separate kD tree, rebuilt every frame, for the dynamic stuff.

I'm not saying I have any better ideas, but this falls down if lots of things are moving around. It also doesn't really address the issue of what to include in the dynamic kD tree. How do you decide whether a dynamic element (character, water surface, foliage moving in the wind) no longer needs to be animated (AI + physics -> skinning, etc...)? I guess you could trace against bounding boxes for dynamic elements and lazily animate on bounding box hits, but ... I dunno, I just haven't heard anything that convincingly addresses the problem.

 

About the same as a cold day in hell. Sony's history with devkits is such that you'd think their ultimate goal is to make writing a hello world program a headache.

Okay, I'm exaggerating, but you get the idea. Sample code that proves helpful is not something that's within their range of comprehension. Nor is it in their capacity to consider using examples in documentation.

 

Well apparently they're going to make the Ducks demo available in the Fall for developers It's a start..(presumably it will be of some use for some devs - that demo was pretty sophisticated).

 

I think you may be wide of the mark. This was the case with PS2, which was by all accounts a farce, but what we're hearing regards PS3 development is a different story. eg. The SDK comes with the LOD demo source code, which includes collision physics, fluid physics, cloth physics (including receiving damage), rendering stuff. Then there's a lot of work being put into the software, middleware takeup, and so forth. I'm not a dev with access to Sony's support so can't comment first hand, but what I'm hearing doesn't sound too shabby.

 

I certainly hope that's the case, but I won't see a devkit for another couple of months most likely, so I can't say for sure.

 

RT would be a very nice and computationally realistic replacement for shadowmaps. The basic implementation (simple ray intersection checking) should be rather cheap with a processor like Cell, but even realistic softshadow umbra and pen umbra should be possible.
For reflections, cubemaps are ridiculously more efficient and produces very acceptable result for realtime applications.

 

In my experience with raytraced shadows in offline CG, they've ALWAYS been slower than shadow maps. And it's not as easy to make them soft edged, you'll have to trace more rays for that which makes it even slower.

Dunno about realtime implementations though...

 

But shadowmaps still has huge issues with aliasing, even with really high resolutions and perspective SM are very difficult to get to work well AFAIK.