any news about RSX?
- Thread starter jobboy
- Start date
And more than 8 wouldn't make sense - 16 ROPs wouldn't be an 'architectural feature' so much as a 'waste of transistors.'
Anyone remember the stat about Cell's bandwidth reading from GDDR3? I'm thinking it was pretty low and I anticipate the frame buffer will be in GDDR3. I guess I'm just less optimistic about Cell and RSX exchanging data back and forth frequently than are others here.
I agree with this part. Cell has the potential to be the main differentiator outside of bluray.
Oh. Sorry I missed it somehow.
That 'Cell to GDDR' bandwidth thing has always been a red herring though in terms of discrediting the architecture. The way the system (in that regard) is intended to work is that RSX pushes/pulls from the XDR, where Cell will make it's contribution. The framebuffer 'proper' still lies in the GDDR, but I don't think you should view the XDR as being quite so distant in terms of it's potential useage. In fact the furthering of such utility seems/is the very reason the texture cache on the RSX has been expanded.
Last edited by a moderator:
Some people have been talking about how the CELL processor could decompress textures on the fly and send them into the RSX. I'm a little confused about this technique, because I thought you would want the textures compressed as they go into the RSX because they would be processed faster.
Could someone explain how decompressing a texture first in the CELL and then feeding it into the RSX could perform better than just sending it the compressed DXT1-5 textures?
Could someone explain how decompressing a texture first in the CELL and then feeding it into the RSX could perform better than just sending it the compressed DXT1-5 textures?
The main thing I've been trying to get across is I don't see that much difference between the two systems regarding CPU and GPU cooperation. Both systems have frame buffers in a memory that won't be frequently read back by the CPU. Both can store textures in main memory. Increasing the texture cache might mean nothing other than there is more latency when fetching from XDR than when fetching from GDDR. It doesn't imply to me that Cell will be using the texture memory in anyway other than Xbox.
Well, I think the latency is exactly it with the XDR/texture cache. As for the later though, I guess we'll just have to wait and see. I'll throw my hat into the 'Cell' ring, however. The idea of Cell generating and/or working on data that RSX can later snag out of the XDR makes a fair bit of sense to me - if only because the SPEs are well suited to doing some geometry and transforms work.
Frankly there have been like ten threads on the matter scattered around here in the past, with a lot of good benefits and barriers discussed. Since I trust you've probably read most of them yourself as well, I guess we'll just have to shrug our shoulders and wait for a year or two down the line to see what ends up happening.
Still, page 9 of this IBM doc here helps to illustrate some of what may become a rather common interplay between Cell and RSX as the gen progresses:
http://publib.boulder.ibm.com/infoc...ity.pdf#search="Cell SPE geometry transforms"
SPEs are well suited for geometry and transforms work and I still wonder what PS3 would be like if RSX had no vertex shaders and all of the ALUs were dedicated to pixel work. I'm sure it was discussed and I would have liked to be a fly on the wall during those meetings. We can move on to what RSX actually is though because as you said this has been discussed many times. Although, I don't recall participating in those discussions so I figure the topic was still fair game for me. :smile:
They're talking about decompressing highly-compressed textures like JPEG(2000) images, and then feeding them as DXTCs to RSX. You won't decompress from DXTC as it's natively supported in the hardware, and would consume 4x the BW at no gains AFAIK.
Texture decompression would be slower going through Cell to RSX rather than just fetching them from RSX. You'd either feed procedurally created textures from Cell, or use the decompression method to fit more into RAM. But both are pretty thwart with difficulty as you need the whole texture available for RSX to fetch.
Shifty,
Thank you so much for explaining that concept! I did not understand what they were talking about. I'm not saying I understand it all now, but I think I have a slightly better grasp.
Basically, the idea I think you are describing is getting decompressed textures strait from SPEs and then into the RSX without having to store these newly created textures in the XDR. So the SPE gets the JPEG, it decompresses the JPEG, and then streams the data into the RSX?
However, if this is going to be slow would there be a way to have the CELL keep the RSX informed of it's progress bit by bit so the RSX would know exactly when to fetch the data? If it's faster having the RSX fetch the data from the SPEs than the SPEs sending the data to the RSX then it seems it's just a matter of timing everything right.
This is a facinating idea because it could help put more textures directly into the RSX very quickly and without filling up the XDR.
Thinking about this is really, really interesting.
Please tell me if my thinking is off here.
Thank you so much for explaining that concept! I did not understand what they were talking about. I'm not saying I understand it all now, but I think I have a slightly better grasp.
Basically, the idea I think you are describing is getting decompressed textures strait from SPEs and then into the RSX without having to store these newly created textures in the XDR. So the SPE gets the JPEG, it decompresses the JPEG, and then streams the data into the RSX?
However, if this is going to be slow would there be a way to have the CELL keep the RSX informed of it's progress bit by bit so the RSX would know exactly when to fetch the data? If it's faster having the RSX fetch the data from the SPEs than the SPEs sending the data to the RSX then it seems it's just a matter of timing everything right.
This is a facinating idea because it could help put more textures directly into the RSX very quickly and without filling up the XDR.
Thinking about this is really, really interesting.
Please tell me if my thinking is off here.
Yep.
The problem is the texture units of the GPU get a texel from of texture on demand of the pixel shaders. If that texture isn't available (in cache) it has to wait for it. If the data's in RAM, the GPU goes fetch it. If the data's compressed in RAM, it'll have to somehow tell the Cell to get the compressed texture, decompress it, and feed it to the GPU, adding massive latency.
If you want to use higher compression to fit more into RAM, it'd make more sense to have the Cell decompress the texture into RAM and the RSX read from there. And by that point, it seems to make more sense to stream textures from HDD. I expect Cell would do decompression of texture from storage and write the DXTCs into RAM. I can't see a way to have Cell aid RSX's texture speed. Howver, it is an unknown how the Cell<>RSX connection can operate regards textures. There may well be a way to have a texture in Cell that can be read by RSX, saving BW, and ideal for procedural textures.
So basically the Cell could decompress JPEG textures into DXT textures and put them into the XDR RAM for the RSX to fetch faster than the Blu-ray or HDD could stream the textures into the XDR?
My whole idea is it would be great to use some of the CELL's horsepower to in a way to at least partially get around the 512MB RAM limit of the PS3. I know it's not going to actually put more RAM in the console, but graphically speaking in general terms how much more graphical quality could such a method add to a game?
Another question I have is about the procedural textures. I have read about a few games that use them. However, I'm curious if any texture (lets just say the textures of Heavenly Sword as an example) could be broken down into a procedural task and then re-created using procedural texturing? Or do complicated and/or detailed textures require too much computational power or memory space to keep procedural texturing efficent enough to utilize in the first place?
My whole idea is it would be great to use some of the CELL's horsepower to in a way to at least partially get around the 512MB RAM limit of the PS3. I know it's not going to actually put more RAM in the console, but graphically speaking in general terms how much more graphical quality could such a method add to a game?
Another question I have is about the procedural textures. I have read about a few games that use them. However, I'm curious if any texture (lets just say the textures of Heavenly Sword as an example) could be broken down into a procedural task and then re-created using procedural texturing? Or do complicated and/or detailed textures require too much computational power or memory space to keep procedural texturing efficent enough to utilize in the first place?
Yes
Possibly very little, because you're texturing ability sin't limited to how many textures you have in RAM, but also how mcuh BW you have to feed textures into RSX. If you could stream textures over FlexIO, you'd be pretty much doubling the amount of texture BW available, so you could definitely get a marked improvement in quality.
It depends very much on the txture and the algorithms used. Realtime procedural synthesis will be limited to mathematical patterns like noise or cellular shapes, checkers, that sort of thing, though in combination they can cover quite a range of effects. There are more advanced methods that record the actions of an artist in a paint package to create a texture, and then recreate the texture by executing those actions in a graphics engine.
ProFX seems to be the leader in procedural texturing. At least they're the noisiest!
http://www.allegorithmic.com/gallery/profx_list.php?page=0
I don't know how realtime their methods are. And they only come in a Microsoft flavour too, so no good for Cell!
