RSX/CELL versatility and DirectX10

[SOcean2forever]

For those who know, I would like to ask this question...(Again I checked the search bar again and there was no topic dedicated to it)

How well is RSX/CELL pipeline suitable for DirectX10 effects? An in-depth explanation would be very much appreciated about how the architecture can handle similar effects of the upcoming API without having the API itself.

[Bobbler]

I'm curious... what are "DirectX 10 effects" ? =p

I've yet to actually hear anything that DX10 can do that DX9 + a CPU can't (I haven't paid much attention, to be honest). But, knowing what effects are possible in DX10 and what aren't in DX9 could shed more light on it better.

Regardless, I think you'll find there is very little that can't be done with a bit of creativity when working with a fixed platform.

[Carl B]

SOcean2, I see what you're going for here, and it has been discussed before. Essentially one of the big differentitors we're talking about from DX9 to DX10 is the idea of geometry shading. Is PS3 going to be left behind in this regard? I don't think so. Or, I could easily change my tone to 'PS3 should rock' in this regard; I don't want to come across as tepid in this belief. ;)

I'm still in 'book tour' mode, so I'm going to post some answers from the Jason Doig interview that deals directly/indirectly with exactly this notion you're looking to address. Like I said this has been discussed before, and there is a good bit additional you might find written by some devs here if you do a more thorough search, but this is 'official,' and to my knowledge one of the few - if only - times an SCE rep has addressed the geometry shading issue directly, so take it to heart. (Starts halfway into the first answer)

...PSINext: With animation being one of the focus' of PSSG - and you mentioned soon physics integration as well – are we safe in assuming PSSG is in part geared towards assisting developers draw out the power of the SPEs?

Jason Doig: Oh absolutely - one of our core aims is to make as much use of the SPEs as we can ourselves, and to enable developers to make use of them as simply as possible when using PSSG. So within the PSSG framework, we've sought out any area where processing can be done on an SPE and designed PSSG to not only make use of that, but to expose the parallelism through a simple interface. This has been done right from the initial design of the system, despite initial implementations having first been done on a PC platform rather than on Cell... and indeed we still run on non-Cell platforms, as cross-platform support is another important feature for PSSG.

For the animation system we sat down and sketched out how data would flow through the system, starting with "time" entering at the top, and final positions (or other animated values) coming out at the bottom. The process of animating was split down into simple discrete blocks (for example we might have blocks to follow key frames, blend data together or apply IK) from which a complex process could be built, with data flowing cleanly between the blocks. Rather than assuming a traditional random-memory access pattern, we tried to keep all data in contiguous blocks that could be easily passed to and from the SPEs. At runtime the blocks could be running on a single SPE, or could be split between different SPEs. We have a "driver" running on the SPE during the animation processing which handles the task of keeping the data flowing, and that can also fetch whatever other memory the animation processing blocks need. We even do intelligent prefetching of data, working on the basis that an animation will need similar data from frame to frame. In this way, the developer need only write a simple processing script to perform the animation function itself, and we take care of making it run efficiently on the SPEs.

The animation system is one of the best examples of this approach, but we have also applied it to other areas as well... such as the traversal of the scene-graph itself and towards processing streams of geometry (we used to call this "Geometry Shading" but then the term was adopted elsewhere!). The geometry processing is a powerful feature we have; it adds a very flexible pre-vertex-shading stage to the graphics pipeline. Using this we can, for example, create procedural geometry on the fly. Again this is simple for a developer to make use of, and PSSG itself manages the task of pipelining the data and running the code in parallel. It's also modular, so you can connect any number of geometry processes together to create a "network" of processing stages for any given effect or situation. We even have GUI tools so that networks can be viewed or edited by an artist.

On non-Cell platforms (or if the developer decides not to allow PSSG to use SPEs for some reason?) we can run all these same processes on an "ordinary" core, and even run them multithreaded if appropriate for best performance. However, we certainly run better when SPEs are used!

PSINext: I'm happy that you brought up the 'geometry shading' aspect of PS3, as there has been ample discussion of late with regard to exactly that. We know that lighting models and particle systems make two readily understood candidates for the SPEs; when you look five years out from now, is your sense that graphics engines created for PS3 will increasingly treat SPEs and RSX as a single transparent graphics subsytem?

Jason Doig: I'm not sure how transparent it will be in other engines, but certainly with PSSG we've taken steps to put SPEs directly into the graphics pipeline. It's not completely transparent right now - you still after all have different restrictions and requirements for different stages of the pipeline. We do try to make the flow of data very easy to manage, however, even all the way back to the artist who created it, let alone the processes at runtime for rendering it. My suspicion would be that this process will continue to evolve, and we will see greater usage of the SPEs as an extension of the graphics pipeline in the future.

This should give us PS3 developers a lot of flexibility to keep up with any changes in the way CPUs and GPUs work in the PC space, where there seems to be a trend back towards unifying everything. PSSG for example, treats the interface between the geometry pipeline (usually running on SPEs) and a vertex shader in the same way as it treats the interface between the vertex shader and the pixel shader. So it's just a backward extension of the pipeline onto the main CPU, where everything is much more flexible. The two things you mention - lighting and particles - are things that we can already drop fairly seamlessly into the PSSG geometry pipeline and run on SPEs. Particle processing especially has an advantage over current GPU based techniques because of the generality of the SPE (and over a traditional CPU as well due to the speed and parallelism of Cell). Using SPEs as a front end to the GPU opens up a lot of interesting avenues and I'd be very surprised not to see people explore them.

PSINext: Addressing a more general topic, you brought up PSGL earlier as being Playstation's custom OpenGL/ES variant. When interviewing Mike Acton recently, he mentioned Cg as a framework that had some cross-SPE/RSX appeal in terms of helping to build a frameset towards approaching the PS3 architecture. Any thoughts on this?

Jason Doig: Using Cg as a language for SPE programming is a potentially good idea, because the same features that make Cg easy to compile into good code for a GPU shader unit would make it easy to compile into good SPE code. In fact, how to potentially unify programming across the shader pipeline is something we've looked at when developing PSSG, as it's a natural next step after trying to bolt SPE processing on the front of vertex shading - but currently we haven't attempted to address it. Really, that's something I'd like to see sorted out between the respective compiler folks, and all we can do is point and say: "Hey, don't these two things look like they go together?"...

(and there's of course more for ya here (http://psinext.e-mpire.com/index.php?categoryid=3&m_articles_articleid=722))

[pjbliverpool]

I have a question.

As I understand it the graphics pipeline starts with the raw vertex data in the CPU which then passes this to the vertex shaders, they do their magic and then pass the resulting triangles to the pixel shaders to do their bit (apologies for the layman explanation).

Its also my understanding that Geometry shaders plug into this (serial?) process between the vertex shaders and the pixel shaders.

Therefore the question is (assuming my assumptions above are correct), if the PS3 were to use Cell for geometry shading then would it also have to do the vertex shading on Cell aswell thus leaving the RSX vertex shaders idle? Or can work be done in vertex shaders, passed back to cell, and then passed into the RSX pixel shaders?

Or did I just get it all completely wrong? :???:

Incidentally, arn't shader model 4 and the intiger instruction set bit improvements in the pixel shader side of things? Can Cell make up for this too?

[ERP]

You're taking the whole DX10 thing far too literally.

You should be looking at what DX10 enables, and what types of performance profiles we can expect in the DX10 timeframe.
Cell can certainly generate geometry pre or post transform, with more flexibility than a Geometry shader or a Vertex shader.
On the other side of the coin RSX will never have good dynamic branching performance.

Developers will play to mechines strengths and stay away from their weaknesses it's what console development is about.

[RobertR1]

Also remember that when we see DX10 hardware become mainstream it'll be quite a bit more powerful than what we see in Xenos or the RSX. Meaning that developers will have a higher base to build from.

As ERP pointed out, the consoles have homogenous hardware throughout their life cycle so a developer can push the limits without having to compromises for the various configs in PC land. However at the rate PC's advance, they'll simply leap past consoles as usual. We strictly talking form a techincal perspective so please the cost and other factors out of it.

Ofcourse, you could also see developers with multiplatform games cater to the lowest common demoninatior. It's the exclusive games where you'll likely see the strenghts of the different platforms.

[Carl B]

Hey ERP side question for you since you're straight PC development at the moment...

What do you feel the 'ramp' is looking like in terms of increasing levels of shader branching? It seems that right now the available hardware is a bit ahead in terms of feature-set of what devs are working with, and I'm just sort of curious as to when you see dynamic branching really starting to take off.

And am I safe in assuming whatever title you're working on presently targets DX10 and Vista? :)

(not that I have insights into your launch window at all of course)

[ERP]

Hey ERP side question for you since you're straight PC development at the moment...

What do you feel the 'ramp' is looking like in terms of increasing levels of shader branching? It seems that right now the available hardware is a bit ahead in terms of feature-set of what devs are working with, and I'm just sort of curious as to when you see dynamic branching really starting to take off.

And am I safe in assuming whatever title you're working on presently targets DX10 and Vista? :)

(not that I have insights into your launch window at all of course)

Our Min Spec is still SM2.0, Dx9 and XP
Not much in the way of dynamic branching, for us. I've only vaguely trolled through our shaders, and from what I've seen we're not really doing all that much where branching would be a win.

For most developers (there will be a few who push the envelope) it's going to come down to critical mass. And available hardware where it's a definitive win.

[shuipi]

I have a question.

As I understand it the graphics pipeline starts with the raw vertex data in the CPU which then passes this to the vertex shaders, they do their magic and then pass the resulting triangles to the pixel shaders to do their bit (apologies for the layman explanation).

Its also my understanding that Geometry shaders plug into this (serial?) process between the vertex shaders and the pixel shaders.

Therefore the question is (assuming my assumptions above are correct), if the PS3 were to use Cell for geometry shading then would it also have to do the vertex shading on Cell aswell thus leaving the RSX vertex shaders idle? Or can work be done in vertex shaders, passed back to cell, and then passed into the RSX pixel shaders?

Or did I just get it all completely wrong? :???:

Incidentally, arn't shader model 4 and the intiger instruction set bit improvements in the pixel shader side of things? Can Cell make up for this too?

I belive the geometry shader should come before the vertex shader, so cell can use the SPEs to simulate that, much like the ps2 uses VU to simulate vertex shader

[Fafalada]

much like the ps2 uses VU to simulate vertex shader
PS2 uses VUs to "simulate" geometry shaders as well, but yea, you're right about the order in pipeline.

[3dcgi]

What type of algorithms do you all think would work best with VS after the GS? I know Stanford's shading language supported per-primitive groups. Does anyone know if the order was primitives before vertices?