Cell and RSX : their relationship.

Status
Not open for further replies.
Re: Cell and RSX : there relationship.

Shifty Geezer said:
Huh?! How can you say XB360 is better set up for CPU+GPU combo partnership rendering? The MEMEXPORT function allows communication across the system RAM, whereas PS3 has a dedicated 35 GB/s from CPU to GPU for passing data between. I rate it very much the opposite and PS3 is better setup for combo processing.

Who says that MEMEXPORT goes to system RAM and cannot go directly into the CPU?

Xenos has direct access to XCPU's L2 cache, remember? Xenos is XB360's memory controller.

We know practically nothing about MEMEXPORT so...

In terms of bandwidth, we know that PS3 has the advantage between CPU and GPU, but in this specific respect, that's all we know.

Jawed
 
Also on the side makes one wonder if the PS3 was originally going to be NUMA, since the supposed Cell GPU would have been able to access XDR just fine.

NUMA? I've seen this word before. What is NUMA?
 
mckmas8808 said:
Also on the side makes one wonder if the PS3 was originally going to be NUMA, since the supposed Cell GPU would have been able to access XDR just fine.

NUMA? I've seen this word before. What is NUMA?

It means non-unifed memory architecture, but that's what PS3 is now.

What I meant to say there was UMA, not NUMA. :p
 
Out of curiosity, which chip is more expensive, the cell or the RSX. I ask to get price comparison of a dual cell system vs. the current one.
 
ralexand said:
Out of curiosity, which chip is more expensive, the cell or the RSX. I ask to get price comparison of a dual cell system vs. the current one.

RSX should be more expensive. It's got more transistors (by a good bit), if nothing else.
 
xbdestroya said:
ralexand said:
Out of curiosity, which chip is more expensive, the cell or the RSX. I ask to get price comparison of a dual cell system vs. the current one.

RSX should be more expensive. It's got more transistors (by a good bit), if nothing else.
Thanks, so a dual cell solution would have probably been cheaper.
 
> "Thanks, so a dual cell solution would have probably been cheaper."

And less powerful at doing graphics, along with not having Nvidia's software advantage, and the familarity that developers have in working with Nvidia's hardware.
 
Re: Cell and RSX : there relationship.

Jawed said:
Who says that MEMEXPORT goes to system RAM and cannot go directly into the CPU?

Xenos has direct access to XCPU's L2 cache, remember?
No, I forget! Thanks for setting me right. I'll need to re-examine what we know about MEMEXPORT/ I though it was a case of marking internal material in the GPU for export to RAM for the CPU to obtain.
 
Edge said:
> "Thanks, so a dual cell solution would have probably been cheaper."

And less powerful at doing graphics, along with not having Nvidia's software advantage, and the familarity that developers have in working with Nvidia's hardware.

Dont the developers have to learn Cell *anyway*? :?:
 
blakjedi said:
Edge said:
> "Thanks, so a dual cell solution would have probably been cheaper."

And less powerful at doing graphics, along with not having Nvidia's software advantage, and the familarity that developers have in working with Nvidia's hardware.

Dont the developers have to learn Cell *anyway*? :?:

It would be different though learning it as a CPU than as a graphics chip, especially considering that the 'visualizer' would not have been exactly the same as Cell anyway. With NVidia's tools and support, they can basically hit the ground running in that regard. A Cell GPU + Cell CPU probably would have become a pretty nightmarish situation for developers, especially when contrasted to Microsoft's provided environment.
 
Let's re-couch the question into sub-divisions that make more sense. First let's separate the bandwidth consumers and the computation consumers...

Bandwidth consumers:
- Z buffer
- Frame buffer
- Textures
- Models

Questions:
- Can the Z or Frame buffers be placed in the Cell's memory by the RSX? This may be answered by finding out if the G70 can place these in a PC's ram using Turbo Cache.
- Textures and Models will definately work from the Cell's memory, but how much of a bandwitdh savings is this? On a PC (in the most common scenario) the Models are streamed from PC ram through the AGP or PCI-E bus, so nothing new there.
- How much GDDR3 memory will go unused if the textures and models are kept on the Rambus memory? With the Z and Frame buffer consuming ~32MB (1080p, 16bit HDR) there is 224MB with nothing to do.

To realize any substantial benefits from the RSX <-> Cell bandwidth the Z and Frame buffers need to be split between the memory pools.

Computation consumers:
- Geometry generation: CPU
- Vertex shading: Works well on either, but if the CPU does this then the 8 vertex shaders on the RSX are sitting idle.
- Rasterization: GPU
- Pixel shading/Texturing: GPU
- ROP (Z compare, color blending, ect): GPU
- Post render filtering (HDR->24 bit, AA downsample, ect): Either can calculate this, but it's not all that costly.

Is there anything I missed?
 
richardpfeil said:
- Can the Z or Frame buffers be placed in the Cell's memory by the RSX?

NVidia and Sony have said that RSX can render to anywhere in memory, including the XDR. I presume that includes the zbuffer too.

A question I'd like to add. If a dev was very very adamant to have MSAA and HDR simultaneously in their PS3 game, assuming RSX does not offer this, would it be possible to pass the frame out to Cell for HDR processing and then back to RSX for MSAA? Theoretically and then from a performance POV? (Although the latter would depend on the game, undoubtedly).

Kirk has already mentioned HDR as being possible on the SPEs - so can RSX take the frame back and perform MSAA on it subsequently?

Also curious if NVidia/Sony will be providing any tools/libraries for easing any such use on Cell - it seems to be a big point for them in interviews, so I'm wondering if that'll translate into dev support and so forth for it.

And any of the devs here want to comment generally on Cell<->RSX wrt to graphics? Too early to say?
 
xbdestroya said:
blakjedi said:
Edge said:
> "Thanks, so a dual cell solution would have probably been cheaper."

And less powerful at doing graphics, along with not having Nvidia's software advantage, and the familarity that developers have in working with Nvidia's hardware.

Dont the developers have to learn Cell *anyway*? :?:

It would be different though learning it as a CPU than as a graphics chip, especially considering that the 'visualizer' would not have been exactly the same as Cell anyway. With NVidia's tools and support, they can basically hit the ground running in that regard. A Cell GPU + Cell CPU probably would have become a pretty nightmarish situation for developers, especially when contrasted to Microsoft's provided environment.

Maybe. Its all about applying API's to hardware anyway... If Nvidia was involved with SOny for the last two years you would think that they would KNOW CELL inside out and put their graphics expertise to use and come up with something for Cell... or maybe they did and they said "um we have something better."
 
Where would the cell store the info when its working on it ?


What I don't get is say cell is doing hdr .

So the rsx needs to do its work and save the buffer and final image in its ram , then send it to the cell which will need to store the scene in its own ram to work on it . Then send it back to the rsx to put on the screen ?

Wouldn't that a ) use a crap load of bandwidth and b)create a pretty big delay in the image being put on the screen
 
That all depends on how fast Cell can process it. 1 megapixel (720p) at 16 bytes per pixel (what other gubbins is needed like Z and stencil?) is 16 megabytes a frame - no bandwidth whatsoever. Into RAM, into Cell (in tiny little packets of 64 kb at a time to fit on SPEs, with 128kb SPE code and 64 kb buffer for next packet), then straight back to RSX without going through RAM.

That's assuming coherant data. I'm clueless as to how HDR is really rendered but recent rumblings suggest it's very different to conventional rendering, so data may need to be fetched from different area for different objects.
 
jvd said:
So the rsx needs to do its work and save the buffer and final image in its ram , then send it to the cell which will need to store the scene in its own ram to work on it . Then send it back to the rsx to put on the screen ?

Well along with what Shifty has said - does it have to go to RAM before going to Cell? Can RSX pass data to Cell directly?

Even if you had to store in RAM and then send to Cell, overall you're likely saving memory bandwidth if HDR is bandwidth intensive (since for the computational side of that op you'd then be eating SPE-to-LS bandwidth rather than RSX-to-memory).
 
Titanio said:
jvd said:
So the rsx needs to do its work and save the buffer and final image in its ram , then send it to the cell which will need to store the scene in its own ram to work on it . Then send it back to the rsx to put on the screen ?

Well along with what Shifty has said - does it have to go to RAM before going to Cell? Can RSX pass data to Cell directly?

Even if you had to store in RAM and then send to Cell, overall you're likely saving memory bandwidth if HDR is bandwidth intensive (since for the computational side of that op you'd then be eating SPE-to-LS bandwidth rather than RSX-to-memory).

RSX and Cell can in theory communicate directly without going though RAM.
 
Yes but where will the cell chip hold the final image to do hdr on it ?

That is a big image . The cell would need to tile it from some where

not to mention that lighting has to be done together with all the other stepps . It really can't be done after the fact.
 
Lots of speculation for now. The only thing we do know is that cell CAN perform Gpu tasks and more than likely will. It is still a mystery (for us patzers..) what the performance of 1 SPE will be.
 
Status
Not open for further replies.
Back
Top