D-Fly writes
"Charlie Demerijian at the Inquirer got a look at some insider specs on the PS3, and says, Sony screwed up big time with the Cell processor; the memory read speed on the current Devkits is something like 3 orders of magnitude slower than the write speed; and is unlikely to improve much before the ship date. The slide from Sony pictured in the article is priceless: 'Local Memory Read Speed ~16Mbps, No this isn't a Typo.' Demerjian says when the PS3 comes out a full year after the XBox360, it's still going to be inferior: 'Someone screwed up so badly it looks like it will relegate the console to second place behind the 360.'"
This is the Inquirer, so take with a grain of salt. Just the same, doesn't sound too good for Sony or IBM.
according to my rumour-mill:
"Main memory" refers to the 256MB memory of the CPU. "Local memory" refers to the 256MB memory of the GPU. The CPU can read with ~16MB/s from this local memory, write bandwidth is ~4GB/s. So if you really need to read data from local memory, it'd be better to have the GPU render it to main memory and have the CPU read it from there instead of reading it directly from local memory.
I have to agree with Arjan.
It's the usual inquirer bullshit.
The 16MB/s is the bandwidth for Cell reading directly from RSX local memory (as opposed to something like a DMA transfer from RSX). The article makes it sound as if its the bandwidth to Cells main XDR memory.
Yeah The Inquirer article is so wrong it's laughable. I thought it was really odd too and with a little further investigation (something The Inquirer should try sometime) I came across this, which mirrors what Arjan basically said:
"It isn't at all unusual for the video memory to have incredible write speeds and painfully slow read speeds (back to the CPU that is). The reason is that in 3d graphics the video card does the actual rendering. Therefore you simply tell it "I want a blue triangle at the coordinates X,Y,Z (x3) with T texture applied". The card renders it and applies the texture from texture memory and then displays it onto the screen. You never need to read the (texture) memory, because the data contained in it is throw away (why would you need to read the texture in that you sent to the card?)
So it is perfectly normal for texture memory to be nearly write-only. As long as writing to it is extremely fast (which it is in this case according to the PP slide), that isn't a problem."
Saotome wrote:I have to agree with Arjan.
It's the usual inquirer bullshit.
The 16MB/s is the bandwidth for Cell reading directly from RSX local memory (as opposed to something like a DMA transfer from RSX). The article makes it sound as if its the bandwidth to Cells main XDR memory.
there should be a rule against posting any "articles" by the inquirer. ;)
Each SPE contains a 256 KB instruction and data local memory area (called local store) which is visible to the PPE and can be addressed directly by software.
I'm no expert on ps3(or anything else for that matter) but from what I gather, the bandwidth between cell and gpu read wise is painfully slow, BUT the bandwidth between gpu and system ram is very high.
So couldn't you simply dma from the gpu memory to cpu memory, THEN let the cell just read the memory copy.
it's been a while but if I'm right you'd be able to read at over 8gb a sec.
Just an idea, no idea if it's practical/workable. But I'd say there must be a way, cos too many ps3 games supposedly do post fx on the cell and the only way to do post fx on rsx rendered graphics would be some way of dma'ing rsx mem to cell mem. (I think.)
Kojima wrote:I'm no expert on ps3(or anything else for that matter) but from what I gather, the bandwidth between cell and gpu read wise is painfully slow, BUT the bandwidth between gpu and system ram is very high.
You are correct that the RSX has a 256bit bus split into two 128bit busses, one going to GDDR3 and the other to XDR.
So couldn't you simply dma from the gpu memory to cpu memory, THEN let the cell just read the memory copy.
it's been a while but if I'm right you'd be able to read at over 8gb a sec.
I've no idea if it is possible and/or feasible to do this, but it should be very fast. The idea is that you can store your textures in the XDR, for instance. I've seen a few devs confirm this is possible at beyond3d.com.
Just an idea, no idea if it's practical/workable. But I'd say there must be a way, cos too many ps3 games supposedly do post fx on the cell and the only way to do post fx on rsx rendered graphics would be some way of dma'ing rsx mem to cell mem. (I think.)
It's hard for me to tell if they are actually post-fx. They could be pre-fx, as you can copy from XDR to GDDR3 memory, so you just need to have the GDDR3 merge the data into the graphics scene in a clever way. That shouldn't be too hard.
It's hard for me to tell if they are actually post-fx. They could be pre-fx, as you can copy from XDR to GDDR3 memory, so you just need to have the GDDR3 merge the data into the graphics scene in a clever way. That shouldn't be too hard.
Well some of it could be pre-fx, but one example would be warhawk. The clouds are generated entirely on the cpu, so I gather the zbuffer has to be copied to the cpu some way. (Or some simple z-based shader that generates a low-res map that is sent back to main memory, sorta like you would for depth of field)
Then again they could just create a zbuffer for the clouds on the cpu and upload it as a texture.
So I'm pretty convinced it's possible. Also take fx like bloom, that would need rsx rendered framebuffer access to work and I'm pretty sure The GetAway uses that.
So hard to say either way really, but on paper at least it looks possible.
Doesn't the RSX support pixel shaders? I thought on modern pc cards post fx were done by loading up certain pixel shaders and 'rendering' with that. It already has full access to the framebuffer (since runs ON the gfx chip - no need to transfer back to cpu) and various parameters can be passed via textures on which the shader can do lookups.
Yes, standard practice on pcs is to do multi-pass postfx usually involving some shader language or other(I.e cg/glsl/hlsl) entirely on the gpu. (Some involve cpu assistece like creating and uploading a wave map texture for say a vertex shader) but there has been quite a bit of talk about post fx done on the Cell on ps3.
And if that is true, it invalidates the slashdot article completely. (Not that it has a slow read rate directly, that appears to be true, but that the ps3 is broken. My bet is the slashdot writer was just a bit too dense to understand you could circumvent the slow read speed by taking an alternate route from the rsx ram to cell ram)
