Support NeoGAF

[gofreak]

http://www.graphicshardware.org/presentations/damora-cell4graphicsandviz-gh05.pdf

IBM had a keynote presentation at Graphics 2005 a couple of weeks ago titled "Cell Technology for Graphics and Visualization" - it seems like it was a pretty interesting presentation. It covers Cell generally, and programming models on Cell, and then discusses graphics on Cell, including potential uses in the presence of a GPU (which could obviously be more relevant to PS3 - though it seems to discuss purely one-way usage, from cell to a gpu).

Some of the slides in that regard:

Spotted by cho on B3D.

 

[VictimOfGrief]

yeah those are interesting... depending on how the CPU and the GPU are going to interact as far as what's passed between, Sony has a strong case for a higher grahpic achievement.

 

[dorio]

Cool, doesn't seem like that raycaster will be very useful if its only running at 30fps with that fog and nothing else going on in the scene.

 

[Culex]

Cool, doesn't seem like that raycaster will be very useful if its only running at 30fps with that fog and nothing else going on in the scene.

What?!

It's doing Raycaster at 720p with ONE cell chip without the assist of a GPU.

How is that not impressive?

 

[gofreak]

Cool, doesn't seem like that raycaster will be very useful if its only running at 30fps with that fog and nothing else going on in the scene.

Next-gen Google Maps?

In a games system, with a GPU, a lot of what the Cell is doing there could be offloaded, so you'd leave a lot more in that instance for the game on the CPU (or even more graphics stuff if you wished). To play devil's advocate in the "cell only" scenario, though, I don't think it was ever quite clarified how much the PPE is doing in that demo - if it was relatively free, you could get a good amount of "game" code running off of it (by current-gen standards - it is a 3.2Ghz core with VMX afterall).

Anyway, I'm kind of pleasantly surprised that that demo is at 30fps. We knew it was realtime, but realtime can be very liberally used with demos like this. I also wonder what clockspeed the CPU is running at to reach that framerate.

 

[Vince]

Cool, doesn't seem like that raycaster will be very useful if its only running at 30fps with that fog and nothing else going on in the scene.

Much to the contrary, I think it's hugely impressive that a CPU is outputting a raycasted image (with all the techniques used; from texture filtering - which is immensely expensive - to neater examples, such as the clouds are dynamically created with a Perlin function) at 720p with so much being rendered. For example, Cell is Multisampling the image dynamically with from 4 to 16 samples per pixel. How many CPUs can do that? How many GPUs can do that?

EDIT: Cell-Blades at at 2.8GHz.

 

[acklame]

cool stuff

 

[gofreak]

EDIT: Cell-Blades at at 2.8GHz.

Cheers, right in front of me!

Seems if rendering locally, then (7 SPEs doing raycasting/rendering), PS3's Cell would be ~14% faster. Assuming everything scales linearly with clockspeed and # of SPEs (the latter is certainly the case), in a Cell-only scenario that'd allow it to maintain that framerate and dump one of the SPEs to do something else - alongside the PPE? - if you were really so inclined toward a heavier application

 

[dorio]

Much to the contrary, I think it's hugely impressive that a CPU is outputting a raycasted image (with all the techniques used; from texture filtering - which is immensely expensive - to neater examples, such as the clouds are dynamically created with a Perlin function) at 720p with so much being rendered. For example, Cell is Multisampling the image dynamically with from 4 to 16 samples per pixel. How many CPUs can do that? How many GPUs can do that?

EDIT: Cell-Blades at at 2.8GHz.

Sure its impressive as a tech demo. But I'm only concerned with how this tech can be used in games. Maybe you can offload somethings to the gpu and then get something that's playable in games but it doesn't seem likely with what they are showing here. Maybe a heavily fogged flight sim?

 

[gofreak]

Maybe you can offload somethings to the gpu and then get something that's playable in games but it doesn't seem likely with what they are showing here.

Why not?

I think a GPU alone could handle this (well, implementation raycasting asides..I'm not well enough versed in that regard. I know it's doable with SM3.0, or at least I've seen papers on SM3.0 implementations, but I'm not sure what performance would be like). You could possibly offload it all.

If you wanted to pair a Cell with a GPU for it, you could have Cell working on the terrain generation and geometry, spitting that to the GPU for rasterisation/pixel shading (including raycasting?). If that was the case, the CPU overhead would be relatively low - the vertex work would be a breeze for Cell - and you'd have plenty left over for "a game".

I think it also very much depends on what type of game you're working on. Even disregarding the GPU, some games could probably get by just fine on a PPE (and 6SPEs at 3.2Ghz would give as good performance as 7 at 2.8Ghz, so there's another SPE for your game ).

I don't think any game is going to ignore the GPU though But that can only mean better things as far as graphics go, or a crapload more "game" - I guess it's all up to what a dev wants to do.

 

[dorio]

Why not?

I think a GPU alone could handle this (well, implementation raycasting asides..I'm not well enough versed in that regard). You could possibly offload it all.

If you wanted to pair a Cell with a GPU for it, you could have Cell working on the terrain generation and geometry, spitting that to the GPU for rasterisation (and maybe raycasting?). If that was the case, the CPU overhead would be relatively low, and you'd have plenty left over for "a game".

I think it also very much depends on what type of game you're working on. Even disregarding the GPU, some games could probably get by just fine on a PPE (and 6SPEs at 3.2Ghz would give as good performance as 7 at 2.8Ghz, so there's another SPE for your game ).

I don't think any game is going to ignore the GPU though But that can only mean better things as far as graphics go, or a crapload more "game" - I guess it's all up to what a dev wants to do.

Can you have spes doing things independently without any input from the ppe. If the gpu can handle the raycasting then you wouldn't need cell to do it in the first place. I think you can get the same results or better visually with tricks without the raycasting but I guess its interesting from a theoretical non-real world perspective.

 

[Forsete]

Very impressive stuff.

 

[gofreak]

Can you have spes doing things independently without any input from the ppe.

There's no one answer to that. It depends on the model you use. In certain models you can set them up initially with the PPE and beyond that they can take care of themselves, with a minimum of PPE intervention. So yes, your PPE could be very free to do other things (if it wasn't there'd be no point, for example, in including other logic for application code, like VMX etc.). In all models, while the SPE is executing a task, it's doing so independently (it's how things are managed when it's done that determines the level of PPE involvement..but yeah, SPEs can apparently even self multi-task and so forth)

If the gpu can handle the raycasting then you wouldn't need cell to do it in the first place.

True, although I'm not sure of the specifics of performance etc. on a GPU. But another approach could be to split it between the CPU and GPU, which would decrease the burden on the CPU while also perhaps allowing you to do other kinds of pixel shading on the GPU in addition.

 

[ThirdEye]

IBM: "Take that, Carmack!!!!"

 

[dorio]

True, although I'm not sure of the specifics of performance etc. on a GPU. But another approach could be to split it between the CPU and GPU, which would decrease the burden on the CPU while also perhaps allowing you to do other kinds of pixel shading on the GPU in addition.

Do you think you would be able to use a spe as a vertex or pixel shader and have that be completely transparent to the RSX in that it would look just like an additional pipe?

IBM: "Take that, Carmack!!!!"

I'm sure Carmack saw this during the Sony pc and I'm sure it's included with the ps3 dev kits he has.

 

[ThirdEye]

I'm sure Carmack saw this during the Sony pc and I'm sure it's included with the ps3 dev kits he has.

Why? This demo is handled by STI Design Center, not SCEI.

 

[dorio]

Why? This demo is handled by STI Design Center, not SCEI.

Looks like the same demo from E3 to me. Is it not?

 

[gofreak]

Do you think you would be able to use a spe as a vertex or pixel shader and have that be completely transparent to the RSX in that it would look just like an additional pipe?

RSX doesn't need to know where data comes from. It just reads data in and works on it. It doesn't have to know what happened to it previously. So Cell works on somethings, outputs the results, RSX reads it in, does some more work on it, or whatever. Well that's one model for collaboration between the two at least (it's what's shown in the first slide posted, pretty much). I'm not sure if it'd fit specifically in the case of parallelising ray-casting across the two - that might be trickier, if they have to work wholely independently on different parts of the screen..i.e. the GPU would always be limited to a render quality that the CPU could match and vice versa - but it'd work in a lot of others, most others in fact, since I don't think you're going to see Cell commonly doing whole rasterisation. What's more important there is that the data outputted by Cell can be used transparently by RSX - that numerically the data is treated in the same way on both chips. That's what Kutaragi was talking about when he mentioned that Cell has different rounding and cut-off modes to match those of RSX, in order that its output can be used seamlessly (from that POV) by RSX and vice versa.

I suppose one more pertinent question might be if it were transparent to developers. If devs could write one shader and allocate it to a vertex shader or SPE transparently. That might be a bit too much to ask, but it'd only become relevant if you were wanting your GPU shaders and SPEs to do be doing the same tasks. The division of tasks could be mutually exclusive though, so you just always do one thing some things on Cell, always do something else on RSX, so there'd be no extra code required so to speak.

I'm sure Carmack saw this during the Sony pc and I'm sure it's included with the ps3 dev kits he has.

Given that Sony made a point of mentioning the duckie demo would go out to developers later this year, I'd say if the terrain one was already in the kits, they'd have mentioned it

Anyway, Carmack's problem is that using the CPU for graphics like this might not port very well, so I don't think he could take advantage of it much..in some ways perhaps, but not as aggresively as if he was only dealing with PS3.

 

[Yusaku]

Hah, I remember people discrediting this demo saying it was done with 3 cells. Looks like there was two demos.

 

[Pimpwerx]

Saw this earlier this morning. 30fps on a single Cell (7-SPEs as seen in Slide 39) is quite impressive. The 8th SPE is still doing the jpeg compression since it's all software. This might have something to do with the rumors that Cell was once envisioned as a GPU (although not according to SCE sources). It's quite capable, as it's handling normal and bump-maps, as well as AA.

Now, since I'm still unfamiliar with the post-process applications here, I'm gonna ask the dumb question this time. What are the odds Cell can be used for MSAA? It looks like STI expect textures/maps and geometry to be stored in XDR, so is MSAA something that gets done in the middle of the pixel shading pipe, or is it something that can be applied to the frame buffer after the fact using Cell, splicing the screen among SPEs and applying variable MSAA like they have in the terrarin demo?

Anyway, Sony is once again the company with the most public documentation of their hardware. They were the last two gens as well. These slides they put out are very interesting to read. PEACE.

 

[dorio]

I suppose one more pertinent question might be if it were transparent to developers. If devs could write one shader and allocate it to a vertex shader or SPE transparently. That might be a bit too much to ask, but it'd only become relevant if you were wanting your GPU shaders and SPEs to do be doing the same tasks. The division of tasks could be mutually exclusive though, so you just always do one thing some things on Cell, always do something else on RSX, so there'd be no extra code required so to speak.

That would have been the best solution for me if I was a developer as it would be as simple as adding another pipe to get scalable performance by using spes. If the cpu and gpu has to act independently and sequentially, that sounds like what's currently being done now where the cpu does work and passes things on to the gpu.

 

[gofreak]

That would have been the best solution for me if I was a developer as it would be as simple as adding another pipe to get scalable performance by using spes. If the cpu and gpu has to act independently and sequentially, that sounds like what's currently being done now where the cpu does work and passes things on to the gpu.

This is true, that kind of model is still sequential, but with a boatload more appropriate power, and boatload more bandwidth, than is typically the case. That can make all the difference in terms of what you can and can't do, and there's potential for more crosstalk (CPU-to-GPU-back-to-CPU and so on, although you'd have to keep an eye on bandwidth/latency between the chips).

Now, since I'm still unfamiliar with the post-process applications here, I'm gonna ask the dumb question this time. What are the odds Cell can be used for MSAA? It looks like STI expect textures/maps and geometry to be stored in XDR, so is MSAA something that gets done in the middle of the pixel shading pipe, or is it something that can be applied to the frame buffer after the fact using Cell, splicing the screen among SPEs and applying variable MSAA like they have in the terrarin demo?

I don't think it can be done after the fact just to the framebuffer. Unless you rendered out all your samples, in which case that'd just be super-sampling. But I guess there's more than one way to skin a cat.

 

[teiresias]

Anyway, Sony is once again the company with the most public documentation of their hardware. They were the last two gens as well. These slides they put out are very interesting to read. PEACE.

Except these slides were put out by IBM.

 

[Pimpwerx]

Except these slides were put out by IBM.

O RLY?

I know that. But this is an STI product, and the chip in the Cell. And besides the spec sheet, which is already more detailed than that of the 360, there's also gonna be a flood of info on RSX really soon. They just offer the most documentation. From press releases to tech slides. They did a bunch of those tech demos at small venues prior to the PS2 launch, and we got a lot of slides then too. PEACE.

 

[cobragt3]

wow, the ps3 can do raytracing

 

[Kleegamefan]

Oh, now I see what all the :lol :lol :lol :lol :lol :lol :lol :lol :lol :lol :lol -ing sangreal was doing since the subject of my thread was already covered here :/

 

[Fafalada]

Sure its impressive as a tech demo. But I'm only concerned with how this tech can be used in games.

Not as Is, obviously.
It presents some things to think about though - if we could get a more generic raycasting implementation(height fields will only get you so far) run fast enough, there's definately some very interesting uses for it in graphics (I'm not talking about raycasting entire scenes mind you).

Btw the paper does state the benchmark settings for the demo had a visibility of 20km. While not ideal for high altitudes, I wouldn't exactly call that heavily fogged either

 

[Kleegamefan]

20Km draw distances?? (12.4 mi)....Far cry only had 3Km draw distances, amirite?

 

[mckmas8808]

Well is he right?