Everyones entitled to their own opinions as long as it's constructive!
Thanks for all the positive feedback guys! ^__^
Anyway I had some brain farts elseewhere that I needed to put down here before they vanished into thin air!
IMHO, I think a market for realtime REYES will likely happen before interactive GI hardware. Long cinematic shaders are here to stay for a while and will eventually move over to the realtime market...why mess around with vertex and pixel shaders when you can just use one shader in REYES and get true displacement mapping, great motion blur and depth of field!?
There's a very good chance that the PS3 will be a fully programmable software renderer, a massively parallel, general purpose vector machine designed to eat polygons and shaders for breakfast! As triangle sizes decrease and approach the pixel sizes, REYES pipelines would make more and more sense. And with the flexible hardware, I believe multiple pipelines could be supported, e.g. OpenGL ES and REYES, i.e. OpenGl to get devs started quickly with something familiar and play with REYES later! Similar to the experiment on this Imagine stream processor, comparing Reyes and OpenGL on the same hardware,
http://graphics.stanford.edu/papers/reyes-vs-opengl/
The way I see it is that both the APUs and Pixel Engines can run 32bit flops/ops and as such can run REYES shaders, Vertex shaders and Pixel Shaders but the APUs and Pixel Engines (Salp) are optimised for granularity. You would be able to setup the APU sandboxes and allocate APUs to form custom pipelines and then rasterizes with the pixel engines. When using OpenGL, the pixel engines would rasterize as usual but when using REYES, they would rasterize/process/shade the micro-polygons?
In the above article it demonstrates that the biggest performance hit is when dicing/ splitting and shading. There's plenty of powerful APUs on the CPU to take care of the dicing and the simple, programmable but ultra high filrate (several tens of GPixel/sec) Salc/Salps could take care of shading the micro-polygons. They would have the 'buffer/TMUs' for ultra fast access to textures and also not forgeting the eDRAM. Also if the PUs on the GPU and CPU have L1/L2/L3 cache, they could also act as TMUs for the APUs to reduce latencies for vertex shading etc. Overall that would make a very rounded graphics architecture, no?
IMHO, I also believe this patent would give some idea on the structure of the kind of development environment to expect for PS3/ Cell. The E3 '04 Cell presentation regarding a content creation pipeline that described the realtime OS, Middleware, Tools, Movies, Games, Physics, Database, Sound, Simulation etc. look remarkably like the patent diagrams below. It's middleware and at the heart of it is a realtime kernel, a highly tuned thread manager/ scheduler OS. It forces a certain structure to coding, I presume to provide abstraction and optimise parallelism. It's highly tuned when compiled for multi-threading across multiple processors and would suit Cell nicely?
System and method for leveraging independent innovation in entertainment content and graphics hardware
http://www.beyond3d.com/forum/viewtopic.php?t=16229&highlight=ps3+tool
Well...end of brain dump...back to Halo2, HL2 and MP2...you gotta luv sequels!
