The RSX memory bandwidth really bugs me

[Crossbar]

I've said this before but something that bugs my mind is the fact that the evaluation toolkits has a 7800 GTX graphics card with 256 bit bus and 512 MB GDDR3 DRAM. This will in the final devkit be replaced with the RSX coupled to 256 MB GDDR3 DRAM.

How can you get the same performance out of that when doing for example AA and other memory intense operations? Yes the RSX will be connected to cell over the fast FlexIO bus compared to a crippled PCIE, but Ken has said the cell will not do the graphics, and to me it does not make sense to waste valuable cell cycles for dumb AA logic as well. The rendering buffers will not be in XDR DRAM, I am sure about that.

I think there is some fast memory hidden somewhere in connection to the RSX, which Ken has not revealed yet to us. Rendering two 1080p screens with AA at an acceptable framerate sucks up quite some bandwidth. When I am doing the math on this, it does not add up with the current spec.:duh:

And besides, the final dev kit can hardly have less performance than the evaluation tool kit, unless they have throttled down the card in someway, but that does not make sense either, especially since nvidia has declared that the RSX will have better performance than the 7800 GTX card. How can it achieve this with half the memory bandwidth? The frame buffer is also an area where 360 clearly outperforms the PS3 current spec, that bugs me as well.

The fast frame buffer memory of the PS2 is one of the main reasons to why it has managed to stay competetive to the later consoles of the previous generation. It seems to be a winning formula performance/cost wise, why give it up?

Sony has a history of using EDRAM in PS2 and PSP, in the PS2 the EDRAM has lately been replaced with some DRAM strapped right on to the logic circuitry as a mean of cost reduction. I wonder if Ken has some DRAM of that kind in mind for the RSX?

Please help me get peace of mind :tardbang:

[julps31]

Couldn't the RSX have both embeded RAM and the external RAM? That would be a great memory configuration but I don't know how much the added memory would effect the price. Maybe we wouldn't need a high memory capacity since the memory bandwidth should take care of the decreased capacity (5MB maybe?). I'm the last person to ask though lol.

[frosty]

i've heard many people talk about cell helping in the gfx department, devs and such, but as for it doing AA and the like, not so sure. i'm pretty sure that there is some sort of embedded memory to help rsx out, like you said, 1080p x2 is quite a daunting task, esp. when 60 fps is thought to be a standard frame rate for ps3. I think we have only seen the tip of the iceberg when it comes to rsx. patience, crossbar. next month will tell all.

[RzrWire]

I've said this before but something that bugs my mind is the fact that the evaluation toolkits has a 7800 GTX graphics card with 256 bit bus and 512 MB GDDR3 DRAM. This will in the final devkit be replaced with the RSX coupled to 256 MB GDDR3 DRAM.

I don't have the time to flip through all the possible threads but cpiasminc or xbdestroya had discussed this in an earlier thread. The evaluation toolkits and the final devkits will always have more memory for the graphics card than the actual console itself. This goes for all consoles in general. I can't remember the exact details as to why developers need the extra memory, but maybe one of them can chime in and post the link or repost their answers again.

[Lekko]

I always thought they needed the extra memory because they're most likely going to be running innefficient code and need to debug it and run other things in addition to the actual game code, but I dunno, I'm not a coder.

[cpiasminc]

How can you get the same performance out of that when doing for example AA and other memory intense operations? Yes the RSX will be connected to cell over the fast FlexIO bus compared to a crippled PCIE, but Ken has said the cell will not do the graphics, and to me it does not make sense to waste valuable cell cycles for dumb AA logic as well.
In the devkits, I'm pretty sure the GPU and VRAM are also underclocked. So the actual aggregate bandwidth to the RAM is not as high as you think, and similarly, the throughput of the GPU is fairly lower compared to what RSX will do. Yes the bandwidth is greater than that of the final console, but you'll be fillrate limited long before you're bandwidth limited. There's probably also the fact that you've got that slow PCI-E bus. Having more texture memory means that you'll probably have to hit the bus less often to upload textures and miplevels. With an API covering up the darn thing, the developer no longer explicitly controls those transfers, anyway.

I'm lost as to where you got the connection to CELL doing AA? Things like AA and HDR and AF are all facets of the render process. They're not just something you "do" per se. You can't separate it from the rendering process, although you can try to fake AA various ways in a post-process, but even that has to have the majority of its stages done at the GPU.

Of course you're not going to render with CELL -- it's not a rasterizer and there's no way in hell you'd be able to cover up the latencies of texture accesses as well as a GPU can. Pre-processing some vertex data to simplify the render chain is about what you'll do. Things like software skinning and software shadow volume extrusion and so on...

Rendering two 1080p screens with AA at an acceptable framerate sucks up quite some bandwidth.
It's also something that won't happen. Until some sort of dual-monitor LAN party thing (to forgo splitscreen play) becomes mainstream, the dual-1080p-out is a completely useless feature. Certainly no early game will ever make use of it.

Couldn't the RSX have both embeded RAM and the external RAM?
There will never be a day when eDRAM can be produced in quantities such that eDRAM alone is enough. Any and all devices that have eDRAM will also require access to an external memory block.

Maybe we wouldn't need a high memory capacity since the memory bandwidth should take care of the decreased capacity (5MB maybe?).
There's been about a dozen threads on this, and the fact is that this is never true. Nothing substitutes for capacity and nothing substitutes for bandwidth.
For instance dual 1920x1080x32bit with 2x MSAA supported without need for any esoteric tiling scheme requires 32 MB of eDRAM. There is absolutely no way around that. 32 MB of eDRAM in a console that needs to sell for under $400 is enough to drive even Microsoft into bankruptcy.

The evaluation toolkits and the final devkits will always have more memory for the graphics card than the actual console itself. This goes for all consoles in general. I can't remember the exact details as to why developers need the extra memory, but maybe one of them can chime in and post the link or repost their answers again.
Usually it's the CPU main memory that is higher, not the graphics card. The only real reason why the VRAM is larger in this case simply has to do with the type of RAM and how they manage getting a wider bus. The reason the CPU needs more memory is pretty simple. In testing phases and debugging phases, everything takes up more memory because code will be augmented with all sorts of extra junk so that data can be reported back to the PC that you're running off of. Memory allocations will be padded for bounds checks, calculations will be copied onto the stack so that the debugger can step through them, network packets will constantly be constructed during the debug phases and when breakpoints are hit and so on. Everything will tie back to the location in the codebase where things will actually occur... All so we can see what's going on.

[julps31]

Couldn't the RSX have both embeded RAM and the external RAM?

There will never be a day when eDRAM can be produced in quantities such that eDRAM alone is enough. Any and all devices that have eDRAM will also require access to an external memory block.I know EDRAM wouldn't be enough alone. I was wondering if the RSX could have both external RAM with eDRAM.

Maybe we wouldn't need a high memory capacity since the memory bandwidth should take care of the decreased capacity (5MB maybe?).

There's been about a dozen threads on this, and the fact is that this is never true. Nothing substitutes for capacity and nothing substitutes for bandwidth.
For instance dual 1920x1080x32bit with 2x MSAA supported without need for any esoteric tiling scheme requires 32 MB of eDRAM. There is absolutely no way around that. 32 MB of eDRAM in a console that needs to sell for under $400 is enough to drive even Microsoft into bankruptcy.And when I was writing this I was wondering if the PS3 could have eDRAM in addition to the 256MB of external memory. And I was actually refering to the memory capacity of the eDRAM when I said the bandwidth would make up for the low capacity (x-box 360 has 10MB eDRAM..PS3/5MB eDRAM-5MB lower than 360=lower capacity). So this 5MB of eDRAM would be better than just the 256MB of external RAM by itself.

[jaxmkii]

I don't have the time to flip through all the possible threads but cpiasminc or xbdestroya had discussed this in an earlier thread. The evaluation toolkits and the final devkits will always have more memory for the graphics card than the actual console itself. This goes for all consoles in general. I can't remember the exact details as to why developers need the extra memory, but maybe one of them can chime in and post the link or repost their answers again.
Extra ram needed for debuging software

[cpiasminc]

I know EDRAM wouldn't be enough alone. I was wondering if the RSX could have both external RAM with eDRAM.
Well, that's what I was saying with the second sentence. As long as you've got eDRAM, having both is an absolute given.

And when I was writing this I was wondering if the PS3 could have eDRAM in addition to the 256MB of external memory. And I was actually refering to the memory capacity of the eDRAM when I said the bandwidth would make up for the low capacity (x-box 360 has 10MB eDRAM..PS3/5MB eDRAM-5MB lower than 360=lower capacity). So this 5MB of eDRAM would be better than just the 256MB of external RAM.
That's what I was talking about too, and the answer is still "Absolutely not." If you don't at least have the capacity in eDRAM to hold your framebuffers, having the eDRAM does near diddly squat for you no matter how fast it is. The 10 MB in Xenos is enough to hold a 1080p framebuffer with a little bit left over (which is basically why rendering in 1080 on 360 will require tiling). Which means that for PS3 to do the same with dual 1080p (and require tiling), it needs at least 20 MB (24 would be preferable). 32 MB is required if no tiling scheme is supported and you still want to have MSAA. 48 MB if you're also going to be storing the Z-buffer in there. 24 MB is enough for both frame and compressed Z-Stencil with 2x MSAA, no tiling, for dual 720p. It's also enough for dual 1080p w/ no tiling and no AA (leaving basically no room for tiling should you want to support AA).

That's also why you've probably heard me mention that MS should have just bucked up and popped for 12 MB of eDRAM in Xenos, so that you at least wouldn't require tiling at 720p w/ AA enabled.

Simple reason why the speed of eDRAM won't make up for capacity is this. Say I'm rendering at 1080p, which means that my framebuffer is 8 MB minimum, and I have 5 MB of eDRAM, I've got to break up my work into tiles. Once I'm done with a tile, it has to get copied into a main framebuffer in VRAM so I can make room for the next tile since I obviously have too little space in eDRAM to hold more than one. So no matter what, I still end up doing framebuffer reads and writes through the external bus because the eDRAM is too small. Now if the queueing of geometry from the CPU is perfectly subdivided against the tiles, I can minimize the number of times I hit the external bus which may save me a little something. However, a perfect solution is fundamentally impossible, and there are still certain things that you can't cheat your way out of because of the fact that rendering is not order-independent, so you'll probably end up hitting that bus more often for framebuffer reads than writes, but either way, it's the slow external bus that's going to be limiting you.

At least if the eDRAM is big enough to hold a framebuffer, everything can happen entirely in eDRAM and the external bus to VRAM is never used for framebuffer operations. Even being too small to support multiple samples for AA but having enough room for a single copy plus some extra for tiles is good enough since you at least are doing all work on your rendertargets within eDRAM.

[lip2lip]

is there any external resource that explains the advantage of z-buffer over compressed z-stencil in the frame buffer that someone may know of? I am not to clear on this, I am thinking ps4 7 years from now may have 32 meg edram, so I would like to shed a light on what it means exactly...

[cpiasminc]

My bad on the wording. Z-buffers on modern hardware are usually always combination Z-stencil (just that the "Z" part of it is almost always used whereas it's entirely possible to have a game that never uses the "stencil" feature). It is possible, though to separate out the Z and stencil into two separate buffers with some GPU microcoding, but why you'd want to, I don't know. Most GPUs aren't documented heavily enough that you could even try this, though.

There's basically no performance hit to using compressed vs uncompressed, and this was true even on hardware as old as the original Xbox, and the 2:1 compression of the Z-Stencil buffer happens to be lossless. Nice thing if you don't have eDRAM to save a little touch of bandwidth. However, if you want to transfer direct copies of the depth buffer for some kind of software manipulation, an uncompressed buffer would at least be directly readable without the need for any decoding process.

[lip2lip]

thanks. you know rsx has large cache, its just not used for frame buffer. I have no idea how effectively it will be used though

[julps31]

That's what I was talking about too, and the answer is still "Absolutely not." If you don't at least have the capacity in eDRAM to hold your framebuffers, having the eDRAM does near diddly squat for you no matter how fast it is. The 10 MB in Xenos is enough to hold a 1080p framebuffer with a little bit left over (which is basically why rendering in 1080 on 360 will require tiling)....Thanks for the explanation CP... :thumbl:

[Crossbar]

Thanks everyone for trying to ease my frustration!
In the devkits, I'm pretty sure the GPU and VRAM are also underclocked. So the actual aggregate bandwidth to the RAM is not as high as you think, and similarly, the throughput of the GPU is fairly lower compared to what RSX will do. Yes the bandwidth is greater than that of the final console, but you'll be fillrate limited long before you're bandwidth limited. There's probably also the fact that you've got that slow PCI-E bus. Having more texture memory means that you'll probably have to hit the bus less often to upload textures and miplevels. With an API covering up the darn thing, the developer no longer explicitly controls those transfers, anyway..
Sounds reasonable.

Rendering two 1080p screens with AA at an acceptable framerate sucks up quite some bandwidth. It's also something that won't happen. Until some sort of dual-monitor LAN party thing (to forgo splitscreen play) becomes mainstream, the dual-1080p-out is a completely useless feature. Certainly no early game will ever make use of it.I hope you are wrong on this because I really would like to play motostorm on two screens, perhaps not two 1080p screens right from the start, but nevertheless two screens would definitely add to the experience compared to the distorted images on a split screen.

There will never be a day when eDRAM can be produced in quantities such that eDRAM alone is enough. Any and all devices that have eDRAM will also require access to an external memory block.
......
For instance dual 1920x1080x32bit with 2x MSAA supported without need for any esoteric tiling scheme requires 32 MB of eDRAM. There is absolutely no way around that. 32 MB of eDRAM in a console that needs to sell for under $400 is enough to drive even Microsoft into bankruptcy.
Yes, this seems to be common knowledge, I wonder if it's a yeild issue or that there is to small quantities to pay back the process development costs. I guess this can also be caused by that the evolution of the DRAM process and logic process are going in different directions. This might mean that the 360 GPU will never be merged into a single die, I guess we'll find out after a few years.

What do you think of about this "chip on chip" approach Sony has taken in it's cost reduction effort of the PS2?

http://www.sony.net/SonyInfo/IR/info/Semiconductor/2005/qfhh7c000007vr3i.html

This would not be as powerful as 360 EDRAM with dedicated logic for AA, filtering etc. but it would sure as hell add a lot of bandwidth as you could clock such an internal bus fairly high and keep latency low as the signal lines will be short compared to the RAM located on the PCB.

I wonder if this would be a viable mean to add another let say 32 MB DRAM on a separate 128 bit bus in same package as the RSX?

[Smokey]

so ps3 will struggle to output 2x1080p this is how ive read this, not real good at this stuff. but an excellent read people.

[Clixx]

so ps3 will struggle to output 2x1080p this is how ive read this, not real good at this stuff. but an excellent read people.
It would depend on on how detailed the game is. If you look at benchmarks for
GTX 512 you'll see that it can output 1600x1200 (area-wise almost 1080p)
4xAA & 8xAF at around 80FPS for some games. If RSX is indeed 32-pipe GPU it's
possible that it would be able to output 2X1080p at 40-60 FPS.

[F089/H]

WOuld It be possible to use like say an HD and use it as RAM?*Snort*

I mean I'm still geting closer to it just being all burned to HD...:(

[cpiasminc]

This would not be as powerful as 360 EDRAM with dedicated logic for AA, filtering etc. but it would sure as hell add a lot of bandwidth as you could clock such an internal bus fairly high and keep latency low as the signal lines will be short compared to the RAM located on the PCB.

I wonder if this would be a viable mean to add another let say 32 MB DRAM on a separate 128 bit bus in same package as the RSX?
Well, the larger the DRAM is, the larger your addressing multiplexors and corresponding delays get. While clocking a DRAM to 550 MHz is no big deal when it's on a stand-alone chip package, it's going to be pretty hard to bring the latency down as the size of the DRAM gets larger. Still, it won't be any real majorly bad latency compared to that of external RAM.

That and when the chip is on the same package, you can cheaply make a bus much wider than 128-bit. Really, 128-bit won't provide a significant enough improvement in total bandwidth over external VRAM. You could easily do a 512-bit bus on package and see something more interesting.

WOuld It be possible to use like say an HD and use it as RAM?*Snort*

I mean I'm still geting closer to it just being all burned to HD...
Ummmm.... what? If you're suggesting dumping the raw uncompressed frame captures to disk, no hard drive in the world is fast enough to do that with HD streams. You'd at least need a multilayer RAID setup.

[Leedogg]

Ummmm.... what? If you're suggesting dumping the raw uncompressed frame captures to disk, no hard drive in the world is fast enough to do that with HD streams. You'd at least need a multilayer RAID setup.
ahhh man that means no hd advance for Playstation 3 lol.

[Sephiroth_VII]

The HDD is to slow for frame proccesing. It could however, be used for caching, or installing games.

Speeds:

1. RAM
2. HDD
3. Optical discs(fx. Blu-ray)

[Crossbar]

This would not be as powerful as 360 EDRAM with dedicated logic for AA, filtering etc. but it would sure as hell add a lot of bandwidth as you could clock such an internal bus fairly high and keep latency low as the signal lines will be short compared to the RAM located on the PCB.

I wonder if this would be a viable mean to add another let say 32 MB DRAM on a separate 128 bit bus in same package as the RSX? Well, the larger the DRAM is, the larger your addressing multiplexors and corresponding delays get. While clocking a DRAM to 550 MHz is no big deal when it's on a stand-alone chip package, it's going to be pretty hard to bring the latency down as the size of the DRAM gets larger. Still, it won't be any real majorly bad latency compared to that of external RAM.

That and when the chip is on the same package, you can cheaply make a bus much wider than 128-bit. Really, 128-bit won't provide a significant enough improvement in total bandwidth over external VRAM. You could easily do a 512-bit bus on package and see something more interesting.True, a wider bus scales the bandwidth faster, but I was thinking more along the lines that if you have a second pool of memory that was at least as fast (perhaps twice as fast) as your main memory. You could theoretically access them in parallel, perhaps letting you do some post-processing on one buffer while rendering the next frame to the next buffer if the graphics logic is arranged to let you do that.

Maybe I am out in the blue here. I just can't accept the current memory setup of the RSX. When looking at PS2, GC, PSP and 360 they all have fast VRAM and they all have huge benefits from it. We'll hopefully get this sorted out in february.

[OmniCloud]

Who the hell are you guys...Are all of you like computer programmers and technicians? LOL...

Anyway, from what I've read, I've gathered that even though the Evaluation Kits have double the Ram of the actual PS3, a LOT of other factors will come into play and ultimately, the PS3 will definitely outperfrom the earlier kits. Right? One question though, I picked up that this generation Xbox had a lot more Ram than PS2, but PS2 had a faster "Frame-buffer" or something like that. Is that the reason we see some games on PS2 look incredible and you wonder how in the world they did it? (ZOE2, GoW, GT4, MGS3, SotC) while Xbox has games that look like they belong on a High-end PC. (Halo 2, Fable, KOTOR, Doom3, Ninja Gaiden) Why are the graphics so different in those 2 sytems? And in the end, will the PS3 really outperform 360? I know the demo's are really amazing and more impressive than anything I've seen on 360. But some are saying they won't be able to look that pretty for another 2 years, or 360 launch titles were launched so they'll compete with PS3 this year.

[xbdestroya]

Who the hell are you guys...Are all of you like computer programmers and technicians? LOL...

Anyway, from what I've read, I've gathered that even though the Evaluation Kits have double the Ram of the actual PS3, a LOT of other factors will come into play and ultimately, the PS3 will definitely outperfrom the earlier kits. Right? One question though, I picked up that this generation Xbox had a lot more Ram than PS2, but PS2 had a faster "Frame-buffer" or something like that. Is that the reason we see some games on PS2 look incredible and you wonder how in the world they did it? (ZOE2, GoW, GT4, MGS3, SotC) while Xbox has games that look like they belong on a High-end PC. (Halo 2, Fable, KOTOR, Doom3, Ninja Gaiden) Why are the graphics so different in those 2 sytems? And in the end, will the PS3 really outperform 360? I know the demo's are really amazing and more impressive than anything I've seen on 360. But some are saying they won't be able to look that pretty for another 2 years, or 360 launch titles were launched so they'll compete with PS3 this year.

One of the primary distinctions between the PS2 and the XBox graphically is that the XBox's GPU supports hardware texture and lighting whereas the Graphics Synthesizer does not. Right off the bat this gives the chip inside the XBox a distinct advantage, and is why initial XBox games tended to look as good as they did in comparison to PS2 games. Indeed the chip was very similar to the chips going into top desktop PCs at the time, and just the similarities to the PC in general are what made games look both similar to PC games and easy to port back and forth between the two platforms.

PS2 had a much steeper learning curve for developers, and it's recent visuals have only been achieved by the fact that unlike in XBox, where everything had to go through an API layer, with PS2 developers are able to code to and access the hardware. Thus a number of things have managed to come out of the top developer houses that honestly no one could have predicted would occur when PS2 launched years ago. By the way the reason the PS2 has the faster frame buffer is due to it's eDRAM.

[cpiasminc]

By the way the reason the PS2 has the faster frame buffer is due to it's eDRAM.
Yeah, that's also why, in spite of the fact that the PS2 didn't have a whole lot of features or couldn't do much in one pass (you really didn't want to do more than single texturing per pass), it was very capable with whole frame-buffer blends so framebuffer accumulation became your bread and butter.

All the same, framebuffer accumulation is not a good idea on Xenos or any other modern GPU architecture simply because the per-pixel cost has gone way up as opposed to the PS2, and also because the relative speed of of the GPU with respect to the CPU is much lower. Also, even aside from that, the bandwidth to and from eDRAM is greater on the PS2 than on the 360.

[overclocked]

The geek in me still hopes for that they changed the GDDR3 MC of RSX and added an XDR MC instead. But likelyhood that has happend is zero honstly.
I dont remember the numbers but someone could fill them in of how much VramBW there would be in that case.

[overclocked]

Who the hell are you guys...Are all of you like computer programmers and technicians? LOL...

Anyway, from what I've read, I've gathered that even though the Evaluation Kits have double the Ram of the actual PS3, a LOT of other factors will come into play and ultimately, the PS3 will definitely outperfrom the earlier kits. Right? One question though, I picked up that this generation Xbox had a lot more Ram than PS2, but PS2 had a faster "Frame-buffer" or something like that. Is that the reason we see some games on PS2 look incredible and you wonder how in the world they did it? (ZOE2, GoW, GT4, MGS3, SotC) while Xbox has games that look like they belong on a High-end PC. (Halo 2, Fable, KOTOR, Doom3, Ninja Gaiden) Why are the graphics so different in those 2 sytems? And in the end, will the PS3 really outperform 360? I know the demo's are really amazing and more impressive than anything I've seen on 360. But some are saying they won't be able to look that pretty for another 2 years, or 360 launch titles were launched so they'll compete with PS3 this year.

If you take ZOE2(best ex of the one you named) witch is exactly the prime example of what can be done with fast EDram. Particles in mass, alphablending esp loves this feature. You can almost say they had more than was needed for PS2 in terms of the wide 2560-bit(?) interconnect. I honestly dont know if any game even have come close to use all that BW but in case ZOE2 is probably the one. Ataris Transformers and in my mind one of the best looking games if not the best on a overall technical scale has lots of that too but with incrediable enviroments also. A game that i recommend to anyone thats missed it!

[Darkon]

The geek in me still hopes for that they changed the GDDR3 MC of RSX and added an XDR MC instead. But likelyhood that has happend is zero honstly.
I dont remember the numbers but someone could fill them in of how much VramBW there would be in that case.

In terms of bandwidth that wouldn't make much of a difference

[cpiasminc]

In terms of bandwidth that wouldn't make much of a difference
Yep. Only a difference of 3.2 GB/s (25.6 GB/sec as opposed to 22.4 GB/s). Latency is a little better, so practical bandwidth as a fraction of theoretical might be a little better, but when you're already on that kind of scale, it won't be huge.

Though that is assuming that the width of the bus and the quantity of memory is the same as on CELL's side. The GPU side could afford a wider bus, so if you went as high as four controller channels (128-bits) with XDR, you'd get double the bandwidth. Doubt that's feasible, though, as 4 controller channels means at minimum, 8 DRAM devices, which is extra costly even if the DRAMs are smaller.

Either way, it's too late... unless PS3 is due out around the end of 2007. Redesigning the memory controller means scrapping RSX and re factoring, going through another tapeout and ramping production all over again -- which is a minimum 9 month-long cycle.

[xbdestroya]

Yeah I think when folk like me and Overclocked ask for XDR on RSX, we're going for the bandwidth afforded by the smaller pin-count required by XDR. At least that's what I know I'm after! Even though the many smaller modules as opposed to the few larger modules would present a possible cost barrier like you said CPi. Well in any event I don't think any of us expect it at this point. Still it would have been a nice usage of XDR in that system.

[Crossbar]

A while ago I thought Barbarian at B3D leaked a partial solution to my concern about the RSX memory bandwidth. Mintmaster elaborated that the buffers Barbarian talked about could mean the RSX would be able to work with S3TC compressed textures and decompress the data on the fly so to say when the data was needed.
That would effectively reduce the bandwidth needed for those textures with the degree of compression, i.e. 8 times compression -> 1/8 of the original bandwidth, 4 times -> 1/4 etc.
But this would only apply to texture fetches, so I guess the impact would not be that big since a lot of bandwidth is needed for post-processing.

But, if they also could write to compressed data on the fly by using some sort of write through buffer containing logic which compressed the data, it would have a much larger impact IMO. It would make very efficient usage of the GDDR3 memory and reduce the bandwidth requirements significantly. It would be a very neat and smart solution with clever transistor usage instead of a brute force big memory and big bandwidth solution. A typical clever console design IMO.

However, Barbarians buffer gospel was shot dead by another developer in the know, nAo I believe, so that explanation was also effectively killed, therefore the RSX bandwidth continues to bug me.

If there is nothing new about the RSX memory usage than what was presented at E3, I think it is safe to say that the PS3 system will not rely as much on post-processing as the 360 can and will. The PS3 may have other capabilities that make up for that, but we just don't know yet. :shrug:

[cpiasminc]

Mintmaster elaborated that the buffers Barbarian talked about could mean the RSX would be able to work with S3TC compressed textures and decompress the data on the fly so to say when the data was needed.
That would effectively reduce the bandwidth needed for those textures with the degree of compression, i.e. 8 times compression -> 1/8 of the original bandwidth, 4 times -> 1/4 etc.
This is basically simply a matter of actually supporting DXT/S3TC compressed textures. There's nothing new about that, and all PC video cards have been doing this for quite some time. PS3 and Xbox360 will both be doing this much and that was known from the start. PS2 didn't suport it in hardware, though PSP does. However, in PSP's case, the texture is compressed in VRAM, but it gets shoved into the texture cache uncompressed.

As you say, though, this only applies to texture fetches, which doesn't have much meaning for framebuffer reads and writes. The framebuffer is always uncompressed because you can't afford a quality loss as this is the image that people actually see on screen. The Z-buffer is typically 2:1 compressed, but the Z-buffer is lossless compressed unlike compressed textures. The Z-compression technique is not applicable elsewhere because it specifically takes advantage of certain aspects of what is actually stored in that type of buffer.

But, if they also could write to compressed data on the fly by using some sort of write through buffer containing logic which compressed the data, it would have a much larger impact IMO.
Well, this is pretty much the idea behind Marco's (nAo) alternate colorspace where he works in a separate luminance-chrominance space (apparently Luv, which is what SGI has been using for HDR storage for a number of years) instead of RGB. While it has a shader instruction cost for converting back and forth, he can get an HDR framebuffer using the same bandwidth as a regular 32-bit framebuffer. Trading a few shader instructions for bandwidth proved to be a win for their project, though it's not necessarily guaranteed that it will be.

However, Barbarians buffer gospel was shot dead by another developer in the know, nAo I believe, so that explanation was also effectively killed, therefore the RSX bandwidth continues to bug me.
What was shot down was not about the support for compressed textures, but certain things implied about the size of the RSX texture cache. In particular, that thing about DXT1 textures guaranteed to fit inside the cache.

[Darkon]

Hey Cpia I’ve been wondering have you found out why that psp kit Sony send to your dev house had foot pedal ?

And you already have the reference kit ?

[overclocked]

Yep. Only a difference of 3.2 GB/s (25.6 GB/sec as opposed to 22.4 GB/s). Latency is a little better, so practical bandwidth as a fraction of theoretical might be a little better, but when you're already on that kind of scale, it won't be huge.

Though that is assuming that the width of the bus and the quantity of memory is the same as on CELL's side. The GPU side could afford a wider bus, so if you went as high as four controller channels (128-bits) with XDR, you'd get double the bandwidth. Doubt that's feasible, though, as 4 controller channels means at minimum, 8 DRAM devices, which is extra costly even if the DRAMs are smaller.

Either way, it's too late... unless PS3 is due out around the end of 2007. Redesigning the memory controller means scrapping RSX and re factoring, going through another tapeout and ramping production all over again -- which is a minimum 9 month-long cycle.

Didnt mean the same as Cell´s interface cause thats different, but you got what i meant a little later there. I remembered something along the lines of 50~GB so thats the correct one.

Other factors esp when not so much was known about Cell or that PS3 would be NUMA i think most thought that the system would have around that BW. There was many other factors aswell but when i saw how Cell was build it was very clear that UMA was out of the question.

Would still be awesome if they had got that BW to Vram alone from XDR and im leaning towards the relative late involment with nVidia is to "blame" for it.
Theres also cost but i dont know how cheaper it is to go vith GDDR3 instead.
They already use it so it must be either. Cause they could "probably" changed Cells MC to GDDR3 if cost was the issue and left the "IBM" Cells with the interface we have now for servers etz.

[Darkon]

Didnt mean the same as Cell´s interface cause thats different, but you got what i meant a little later there. I remembered something along the lines of 50~GB so thats the correct one.

Other factors esp when not so much was known about Cell or that PS3 would be NUMA i think most thought that the system would have around that BW. There was many other factors aswell but when i saw how Cell was build it was very clear that UMA was out of the question.

Would still be awesome if they had got that BW to Vram alone from XDR and im leaning towards the relative late involment with nVidia is to "blame" for it.
Theres also cost but i dont know how cheaper it is to go vith GDDR3 instead.
They already use it so it must be either. Cause they could "probably" changed Cells MC to GDDR3 if cost was the issue and left the "IBM" Cells with the interface we have now for servers etz.

That's crock of shit if anyone is here to blame it would be Sony but unlike you people here i'm not expecting RSX bandwidth issue to be that big of a problem.

Edit

Last time i checked Nvidia announced they where working or at least in talks with Sony ( they never made that clear ) like 3 years ago

[Crossbar]

What was shot down was not about the support for compressed textures, but certain things implied about the size of the RSX texture cache. In particular, that thing about DXT1 textures guaranteed to fit inside the cache.
Yes, but I thought this implied the "on the fly" decompression was killed, as it seemed to depend on the internal buffer, but I guess that is not the case.

To bad the S3TC compression quality is so bad, but isn't that dependant on how you implement it? I mean the larger part of the texture you analyse the better you could do the compression. S3TC decompression must of course be a fairly simple algorithm to allow it to be done in a fast way, but there may be more than one way to compress the image, but it may be costly in either time or transistors.

I mean if there wasn't more than one way to create an S3TC compressed image from a single original, there wouldn't be a market for this tool.
The PS3 version of Optix Image Studio adds support for PS3 format 32-bit RGBA8888 images, direct editing and conversion for S3TC compressed textures (DXT1 - 5) and support for PS3 DDS files.
http://ps3.ign.com/articles/684/684400p1.html

At least not for the "(DXT1 - 5)" part, if it was just one way to do an S3TC compression, it could be a plug-in to just any image editor.

By the way does anyone know what a "32-bit RGBA8888 image", which mentioned in the article, is?

[cpiasminc]

Hey Cpia I’ve been wondering have you found out why that psp kit Sony send to your dev house had foot pedal ?
Yeah. Sony intends at some point to include a software profiler (akin to the PS2's performance analyser, but not a separate machine) built into the debug tools, and the analysis would be triggered by the foot pedal. For now, at least, you can set up the debugger to take screenshots when the footpedal is pressed.

And you already have the reference kit ?
The PS3 kit? No PS3 projects here... at least none that I'm aware of. Last I heard, there isn't even a PS3 project being done anywhere in this part of the state, so nobody has seen one yet.

To bad the S3TC compression quality is so bad, but isn't that dependant on how you implement it? I mean the larger part of the texture you analyse the better you could do the compression.
Uh... no. There's no analysis of any sort like that involved with S3TC. You simply take a 4x4 block and encode it based on the numerical range covered within that block and quantized values within that range.
Example --
Say for instance within the 16 pixels in a 4x4 block, my min alpha is 10, and my max alpha is 66. I assume that every alpha value is within the list of [10,18,26,...66], which is a list that evenly subdivides the range from 10 to 66 into 8 parts. Then the alphas for these 16 pixels in the block are stored as indices to whatever alpha in that table happens to be the closest. Since there are only 8 entries in the table, this index can be stored as a 3-bit value. So by storing my min alpha, and my max alpha (16 bits) and storing the 3-bit indices to the alpha table for the 16 pixels (48 bits), I've got alpha information for 16 pixels stored in a nice 64 bits (2:1 compression).

All DXT compression works pretty much in a way like this one, there are simply differences in the detail per component. DXT1 has 1-bit uncompressed alpha. DXT3 has uncompressed 4-bit alpha. DXT5 has compressed alpha (using the subdivided range method like the one above). All 3 of them compress the color info in a way similar to what's mentioned. Part of what makes it fast in hardware is that hardware texture sampling often involves getting the nearest 2x2 tile and interpolating. In S3TC formats, 4x4 blocks are stored as a contiguous 8/16 bytes, so there's less random access.

The fact that it always does work the same, and always produces the same results is why it the compression ratio and quality is consistent.

Although it is true that when using DXT textures on the PSP, one of the things you had to do was swap the alpha and color sections of the data for a given block as opposed to how they're stored for PC or Xbox compressed textures. Normally the alpha section of the block is after the color section, and PSP wanted them the other way around.

if it was just one way to do an S3TC compression, it could be a plug-in to just any image editor.
As it so happens, that's actually true. The statement is probably more to do with supporting those formats within that tool assuming it does other things that are actually special.

By the way does anyone know what a "32-bit RGBA8888 image", which mentioned in the article, is?
Uncompressed 32-bit texture. "8888" refers to 8 bits for each component.

[overclocked]

That's crock of shit if anyone is here to blame it would be Sony but unlike you people here i'm not expecting RSX bandwidth issue to be that big of a problem.

Edit

Last time i checked Nvidia announced they where working or at least in talks with Sony ( they never made that clear ) like 3 years ago

I cant say for certain untill we know more but ALL indications is that nVidia was pretty late in the game if we compare with ATI and their involement in the 360.
You can draw similar semantics to XeCpu and Cell as an example but the other way around.
The Sony/NV-deal as far as the public know now and to my understanding is that they were just talking about providing software tools etz as various other things like 3Gphones and other devices.

Lastly im not seeing it as a big problem but IF its because of time-constrains witch i belive then its just sad they didnt approach eachother earlier.

[Darkon]

Yeah. Sony intends at some point to include a software profiler (akin to the PS2's performance analyser, but not a separate machine) built into the debug tools, and the analysis would be triggered by the foot pedal. For now, at least, you can set up the debugger to take screenshots when the footpedal is pressed.


The PS3 kit? No PS3 projects here... at least none that I'm aware of. Last I heard, there isn't even a PS3 project being done anywhere in this part of the state, so nobody has seen one yet.

:laugh: ..who the heck came up with this .......:laugh:

[Darkon]

I cant say for certain untill we know more but ALL indications is that nVidia was pretty late in the game if we compare with ATI and their involement in the 360.
You can draw similar semantics to XeCpu and Cell as an example but the other way around.
The Sony/NV-deal as far as the public know now and to my understanding is that they were just talking about providing software tools etz as various other things like 3Gphones and other devices.

Lastly im not seeing it as a big problem but IF its because of time-constrains witch i belive then its just sad they didnt approach eachother earlier.

What indications? ATI's pr BS ? News flash for you buddy 360 was a rush job itself http://pc.watch.impress.co.jp/docs/2005/1227/kaigai231.htm and yet it’s still is a pretty balanced console .

[xbdestroya]

I cant say for certain untill we know more but ALL indications is that nVidia was pretty late in the game if we compare with ATI and their involement in the 360.

There are indications that NVidia and Sony may have started working with each other not too long after ATI and Microsoft got together. This article here (http://money.cnn.com/2003/08/27/commentary/game_over/column_gaming/?cnn=yes) is from 2003, and discusses NVidia's possible overtures towards Sony.

Now, obviously we didn't hear much out of them in between then and the announcement at the end of 2005, but they were working together in some industry groups, and if nothing else even if they did get together 'last minute,' I think it's safe to say they at least kept in touch throughout that time, and Kutaragi and his crew had at the minimum a contigency plan already set for what they would do with one of NVidia's chips, and what that chip would resemble.

Anyway we'll see soon enough what the deal is, but the mystery behind RSX goes quite some ways back I believe.

[xbdestroya]

That's crock of shit if anyone is here to blame it would be Sony but unlike you people here i'm not expecting RSX bandwidth issue to be that big of a problem.

Well, it's hard to say whether it'll be a 'problem' or not, but when comparing the 360 and PS3 architectures, I have to say that the eDRAM's potential to absord bandwidth-heavy operations does stand out in comparison to the PS3. Maybe it won't be a big deal, or maybe devs will simply ignore AA to an extent (AA really doesn't matter for many people anyway - me included). But at the same time I think when Overclock Crossbar and I wish that RSX had access to more bandwidth, we do so because it helps assure us that devs will have access to a wide range of development options that might otherwise be constrained.

[megadrive]

I too am bothered by PS3's apparent lack of high graphics subsystem bandwidth.

some years ago, I thought Sony would extend the Graphics Synthesizer architecture and have even more EDRAM and graphics memory bandwidth like the GSCube.

the original version of the GSCube has sixteen GS I-32 chips for rendering.
GS I-32s were Graphics Synthesizers with 32 MB EDRAM instead of the 4 MB in PS2's GS.

16x of these special GS' gave GSCube 512 MB of embedded graphics memory and a combined graphics bandwidth of ~755 GB/sec -- not counting the 2 GB of Rambus main memory (128 MB * 16) and main memory bandwidth of ~50 GB/sec. that's from 2000 and I thought PS3 would go beyond those figures, using only a few dies instead of 32 dies.

It'll be interesting to see what Sony and Nvidia have come up with in the final PS3 which has changed greatly from earlier concepts.

[frosty]

Man, didn't know GS cube had that much in it. I have faith in Sony and Nvidia especially when it comes to GFX. Nvidia is at the top of the PC line and delivered the best console GFX this generation, and Sony has to prove they are the superior system this gen in order to justify the price tag (by the time PS3's are available worldwide and are no longer sold out, 360 will be due in for a price cut.) so I don't expect to be dissapointed.

[overclocked]

There are indications that NVidia and Sony may have started working with each other not too long after ATI and Microsoft got together. This article here (http://money.cnn.com/2003/08/27/commentary/game_over/column_gaming/?cnn=yes) is from 2003, and discusses NVidia's possible overtures towards Sony.

Now, obviously we didn't hear much out of them in between then and the announcement at the end of 2005, but they were working together in some industry groups, and if nothing else even if they did get together 'last minute,' I think it's safe to say they at least kept in touch throughout that time, and Kutaragi and his crew had at the minimum a contigency plan already set for what they would do with one of NVidia's chips, and what that chip would resemble.

Anyway we'll see soon enough what the deal is, but the mystery behind RSX goes quite some ways back I believe.

I just have this "gut-feeling" that Ken-san is sooo proud :honor: and saw nvidia as a enemy first also because of Xbox. I think they did want to do it all by itself but as the hardware has been so advancing i think they realized they just didnt could chance with an own solution now because of competition from MS.
Its clearly there is only two companies upp to the task right now but i would hope that the extra time we will see between the launches has had an effect
on the final product...:thumbl:
Also its a closed box and you design/code around the streghts not weakness spots of the hardware but still, still..... :crazy2:

Would still be funny and shocking if RSX is indeed something different and new.
As i said even if it was slower it would be more interesting to read about, god how geeky that is.. :help:

[cpiasminc]

and saw nvidia as a enemy first also because of Xbox. I think they did want to do it all by itself but as the hardware has been so advancing i think they realized they just didnt could chance with an own solution now because of competition from MS.
There were some indications from various conference calls among both companies that Sony was evaluating outside sources ranging from nVidia and ATI to Toshiba, 3DLabs, PowerVR, SGI, etc. as well as an in-house part. In nVidia's quarterly conference call that immediately followed the announcement that nVidia would be in the PS3, Jen-Hsun pretty clearly said that Sony was evaluating nVidia as a hardware provider something like a year and a half prior to the announcement.

[overclocked]

There were some indications from various conference calls among both companies that Sony was evaluating outside sources ranging from nVidia and ATI to Toshiba, 3DLabs, PowerVR, SGI, etc. as well as an in-house part. In nVidia's quarterly conference call that immediately followed the announcement that nVidia would be in the PS3, Jen-Hsun pretty clearly said that Sony was evaluating nVidia as a hardware provider something like a year and a half prior to the announcement.

The keyword being "evaluating" IMO. I dont think any companys including the above has the expertise nVidia has and ATI.
Many including me was relived when finding out it was nVidia.

I think it would been better if they hade tied the contract a year earlier or so and started then . Just my opinion.
:cheers:

[cpiasminc]

Yeah, that's probably true. I think between choosing ATI and nVidia, ATI might have been able to do a better job with power consumption (just as a trend), whereas nVidia seems to do better on raw power and feature-richness. They'd already been using licensed SGI tech forever (PS1, PS2, PSP), and there's a lot you can do with SGI's technology -- the main thing is that nVidia and ATI already did a lot with it.

[Sephiroth_VII]

Since this is not a portable system, who cares about power consumption? It's not like we'll all be logging our PS3's around, playing on the subway while attached to a car battery, isn't exactly my taste... If you're worrying about the powerbill... Well, let's just say that the PS3 will be expensive in more ways than one...

[VG Aficionado]

Since this is not a portable system, who cares about power consumption? It's not like we'll all be logging our PS3's around, playing on the subway while attached to a car battery, isn't exactly my taste... If you're worrying about the powerbill... Well, let's just say that the PS3 will be expensive in more ways than one...Unless significant power consumption entails heat issues in a small, closed case.

[sif]

Well if that is the case and power draw is not an issue, then MS should not be having problems with cooling and the giant PSU. Fact is that these consoles have to be powerful, quiet, small and cool. Not an easy compromise. Anyway Cell (at 3.2GHz) draws about half the power that Xenon does (80W>~40W).

http://forums.e-mpire.com/showthread.php?t=50899&highlight=cell+running+cool

[overclocked]

Yeah, that's probably true. I think between choosing ATI and nVidia, ATI might have been able to do a better job with power consumption (just as a trend), whereas nVidia seems to do better on raw power and feature-richness. They'd already been using licensed SGI tech forever (PS1, PS2, PSP), and there's a lot you can do with SGI's technology -- the main thing is that nVidia and ATI already did a lot with it.

SGI been so sucked up or absord by the companies you mentioned earlier that theres little left in them as you say and all their tech is shared trough other companies. I think that last sentence of yours summed it up very nicely with how it is now. :smoke:

[megadrive]

here's a quote from Ken Kutaragi at ISSCC in '99 about the then-unnamed
PS2 graphics chip (Graphics Synthesizer)

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=18301015


Sources describe the graphics chip as a fairly conventional graphics processor, but implemented on a grand scale. "Our target is a crazy level in bandwidth, pixel rate, design rules and transistor count," said Kutaragi. "It's a very, very cutting edge chip."

[overclocked]

Unless significant power consumption entails heat issues in a small, closed case.

Thats very true. Thing is with the 360 the exhaust is so warm that it equals my electric mini-element almost(you know a sucker with a big fan that blows very hot air in ONE direction). Hehe pretty funny actually now when i think of it. :lol:

[cpiasminc]

Thats very true. Thing is with the 360 the exhaust is so warm that it equals my electric mini-element almost(you know a sucker with a big fan that blows very hot air in ONE direction). Hehe pretty funny actually now when i think of it.
I'm reminded of the original commercials where people talked about how much power and how loud the original GeForceFX cards were, and nVidia decided to poke fun self-deprecatingly by putting out that video with the FX cards being used as hair dryers and leaf blowers and wind tunnels and so on.

It's just funny that the 360's fan exhaust is actually hot enough and strong enough that it really could be a hair dryer. While the convex shape of the PS3 is decent for circulating air within the case, the problem is that the only places you can put vents means that the airflow is perpendicular to the axis where the case is convex (meaning you gain nothing for it).

[overclocked]

Its really scary cause im being serious about the temps. In sweden its REALLY cold now and i live on bottom floor but what about summer time when it gets freeking hot. I wonder if *it* can be a reason my SKU havent failed a single time plus that i have it very spacy(free) and *if* systems will start to mailfunction.

Edit
In the room it stands the temp was up by about 3-4 degrees Celsius after 3 hours of Kameo, think pretty big room now also. Not a bedrom type!

[megadrive]

Yeah, that's probably true. I think between choosing ATI and nVidia, ATI might have been able to do a better job with power consumption (just as a trend), whereas nVidia seems to do better on raw power and feature-richness. They'd already been using licensed SGI tech forever (PS1, PS2, PSP), and there's a lot you can do with SGI's technology -- the main thing is that nVidia and ATI already did a lot with it.


if we can even say that PS1 had SGI tech in it at all, it was totally bastardized SGI tech. PS1 GPU had no Z-buffer, no perspective correct textures, no filtering. with the lack of z-buffer (and maybe other things I can;t articulate) PS1 did not even render proper polygons.

I wished that PS1 graphics had been based on Namco's Evans & Sutherland based graphics system used in the System 22 arcade board
(240,000 true z-buffered, textured, gourad shaded, lit polygons/sec in 640x480)

it's probably truer that PS2 GS used some SGI tech, as did PSP.

PS3 RSX is completely SGI tech because most of Nvidia's tech is SGI.

[xbdestroya]

Since this is not a portable system, who cares about power consumption? It's not like we'll all be logging our PS3's around, playing on the subway while attached to a car battery, isn't exactly my taste... If you're worrying about the powerbill... Well, let's just say that the PS3 will be expensive in more ways than one...

Like others have said it's really the heat issues with PS3 that are the issue, not the electric bill. Though I will add on to what Cpi said by saying that this last gen, NVidia's desktop parts actually run a fair bit cooler than all of ATI's high end parts, even with the fact that NVidia is still on 110nm on the high-end and ATI is on 90nm. But that's really neither here nor there, as the Xenos is a decently cool running chip. The chip inside PS3 will ideally be similarly cool running.

[overclocked]

here's a quote from Ken Kutaragi at ISSCC in '99 about the then-unnamed
PS2 graphics chip (Graphics Synthesizer)

http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=18301015

Its a unique hardware chip and im thrilled about it still because its so fundamentally different.

[overclocked]

Like others have said it's really the heat issues with PS3 that are the issue, not the electric bill. Though I will add on to what Cpi said by saying that this last gen, NVidia's desktop parts actually run a fair bit cooler than all of ATI's high end parts, even with the fact that NVidia is still on 110nm on the high-end and ATI is on 90nm. But that's really neither here nor there, as the Xenos is a decently cool running chip. The chip inside PS3 will ideally be similarly cool running.

Is it reasonably to give it about(RSX) 45-60 and then lets say 50 for Cell and then memory also. Wonder how XDR fares against GDDR3?
About the Cell numbers as i trully as you know think its along the lines of 40-50(max) i just think about Mr ex Alpha engi on B3D that knows all, dont he.. :duh:

[cpiasminc]

it's probably truer that PS2 GS used some SGI tech, as did PSP.
In the case of PS1, it wasn't the GPU that got the lion's share of licensed SGI tech. It was the CPU. While that's still true of PS2 and PSP (they're both fairly ordinary MIPS R5900 and R4000 CPUs plus vector units), the GS and GE got some attention as well.

NVidia's desktop parts actually run a fair bit cooler than all of ATI's high end parts, even with the fact that NVidia is still on 110nm on the high-end and ATI is on 90nm. But that's really neither here nor there, as the Xenos is a decently cool running chip. The chip inside PS3 will ideally be similarly cool running.
Hopefully... We'll see if 90 nm SOI does something for it. The ideal range to be shooting for is still pretty much in the upper end (or a few notches above) of laptop GPU power, which is something Xenos does achieve, even if XeCPU doesn't. Presumably, CELL is in that kind of TDP range, so we'll have to see where RSX stands yet.

[Darkon]

There were some indications from various conference calls among both companies that Sony was evaluating outside sources ranging from nVidia and ATI to Toshiba, 3DLabs, PowerVR, SGI, etc. as well as an in-house part. In nVidia's quarterly conference call that immediately followed the announcement that nVidia would be in the PS3, Jen-Hsun pretty clearly said that Sony was evaluating nVidia as a hardware provider something like a year and a half prior to the announcement.

Dang i would have loved if they went with Imagination Tech but I suppose Nvidia would be a better choice since they can supply Sony with excellent tools

And how the heck is 3D Labs still around

Edit

speaking of playstations gpu Didn't Sony consider using NV1 ( i believe ) ? or was it sega ?

[xbdestroya]

Is it reasonably to give it about(RSX) 45-60 and then lets say 50 for Cell and then memory also. Wonder how XDR fares against GDDR3?
About the Cell numbers as i trully as you know think its along the lines of 40-50(max) i just think about Mr ex Alpha engi on B3D that knows all, dont he.. :duh:

Well to be fair, the Realworldtech numbers did imply a higher power envelope than the numbers I started that thread out with, so there's still mixed information out there. Doubtless Cell will run cooler than the XeCPU, but the question's still up in the air about just how much cooler. I'm stepping out right now (so can;t analyze at the moment) but I think we went towards some more conservative number later on in that thread. Aaron raised some valid points, so I guess we'll just have to see what the deal is with our own eyes. Granted I think his own original high-end estimates are way too high though, so kind of meeting halfway.

I'm still hoping also for some thermal numbers to be released in the midst of all this Cell server activity.

[overclocked]

Well to be fair, the Realworldtech numbers did imply a higher power envelope than the numbers I started that thread out with, so there's still mixed information out there. Doubtless Cell will run cooler than the XeCPU, but the question's still up in the air about just how much cooler. I'm stepping out right now (so can;t analyze at the moment) but I think we went towards some more conservative number later on in that thread. Aaron raised some valid points, so I guess we'll just have to see what the deal is with our own eyes. Granted I think his own original high-end estimates are way too high though, so kind of meeting halfway.

I'm still hoping also for some thermal numbers to be released in the midst of all this Cell server activity.

Yeah there were some others also i think esp about the EIB if i remember but did we get over 50?
About A ex its more his attitude to many on the boards that dont know much and i never liked asslicking people just because they have "some" status, no treat your netpals like you want to be treated yourself.
And most important HAVE FUN! :cheers:

[Miyahon]

oh dear god i believe you found a next gen bottleneck.

[cpiasminc]

And how the heck is 3D Labs still around
They're owned by Creative now. And they still have some life in the workstation video card arena with the Wildcat cards.

Well to be fair, the Realworldtech numbers did imply a higher power envelope than the numbers I started that thread out with, so there's still mixed information out there.
They did base some bit on the original research design that preceded the PPE which was a 13 FO4 stage delay design that was meant to ramp way up in clock without giving a damn about power consumption. The DD1 PPE started with an actively managed, lower leakage derivation of that, but it also stretched the pipeline and shrunk the stage delay to 11 FO4.

Though, I haven't heard of any sort of further analysis of that depth since the news of a DD2 PPE.

[megadrive]

Dang i would have loved if they went with Imagination Tech but I suppose Nvidia would be a better choice since they can supply Sony with excellent tools

And how the heck is 3D Labs still around


3D Labs has made a name for itself in recent years with the P10 and P20 VPUs used in the Wildcat cards.



speaking of playstations gpu Didn't Sony consider using NV1 ( i believe ) ? or was it sega ?

it was Sega that was concidering using the NV2, a chip which was never released as far as anyone knows. Sega was concidering NV2 for use in a console that would be either an alternative to releasing the Saturn or as a replacement to the Saturn, in face of strong 3D competition from Playstation and Nintendo64.

The NV1 from 1995 was one of the earliest 3D accelerator chips for PCs. It was used mainly in the Diamond EDGE 3D card, which was a multi-media card since NV1 was a multi-media chip because it processed 3D, 2D, audio and I/O. several Saturn games were ported to the NV1 / Diamond EDGE 3D and Saturn controllers could be plugged directly into Diamond EDGE 3D cards.

Nvidia's absence in 1996 from the PC graphics industry after NV1 of 1995 and before the NV3 (Riva 128) of 1997 is most likely because of the failed NV2 project funded largely by Sega. because of this, competitors like Rendition, 3Dfx and PowerVR had a chance to get a foothold on the PC graphics industry.

however, because Sega invested in Nvidia, about 7 million dollars, and because of the failure of NV2, Nvidia would come back very strong in 1997 and 1998. they replaced their chief technical officer with David Kirk, who turned the company around with NV3 ~ Riva 128. in a sense, Nvidia's success including being selected for Xbox GPU and later PS3 GPU, could be traced back to Sega's investment in Nvidia, and Nvidia bouncing back from near-oblivion because of the NV2.






Playstation's GPU was always an internal Sony design. I don't know of Sony going to anyone else for graphics. maybe they consulted with NAMCO though because there was a driving desire to get
Ridge Racer arcade class graphics into a console. although the Playstation 3D hardware was nowhere near as powerful as the 3D chipset in the System 22 hardware that powered Ridge Racer, Sony co-operated with Namco on a low-cost arcade board based on Playstation called the System 11 which was first used in the fighting game Rave War, better known as Tekken.

edit: I remembered something else. there were rumors, just rumors no solid concrete proof, that Sony was concidering Videologic's Highlander Project for the PlayStation2. nothing ever came if it though....it was a actually pretty worthless rumor that Sony would use PowerVR. The Highlander itself though was very real. it was the codename for Videologic's 2nd generation PowerVR graphics and multi-media chip family. it ended up that Sega, not Sony, would use a 3D-only version of Highlander, the PowerVR2DC, in their next console, the Dreamcast. the Highlander for PCs was the PMX1 chip, better known as PowerVR250 used in the Neon250 cards, which came out too late to give Videologic graphics dominance, but the 3D only part was very successful because of Dreamcast and the NAOMI family of arcade boards.

[megadrive]

okay here is pretty much the only known history of the Sega-Nvidia partnership and the NV2.

if all of this had not happened, there might not have been any more Nvidia and certainly no RSX for PS3.

http://www.firingsquad.com/features/nv2/page4.asp


NVIDIA NV2 Report

We wanted to know the answer to a gamer's question: What the heck was the NV2?

After a few "little birdies" flew in our window, we were able to piece together a detailed account of NVIDIA NV2, the chip that predated the RIVA 128. This is the chip that Sega originally commissioned for its next-generation console, the Dreamcast. The NV2 is the chip that was NVIDIA's greatest fiasco.

The Beginning
In our History of NVIDIA article we hypothesized that Sega started a relationship with NVIDIA only after having spent some time porting games over to the NV1. This was a mistake -the connection traces further back than that.

To begin our story, we need to go all the way back to the Sega Saturn. The Saturn used a Sega-developed graphics chip that was considered by most of the world to be dreadful. The geometric primitive was a four-vertex polygon (not three). As a result, triangles on the Saturn had to be represented by a degenerate quad with two vertices existing at the same location.

Developers hated quads and wanted something better, namely triangles. With the Sony PlayStation handily killing the Sega Saturn at retail, Sega decided that it needed to partner with a company with 3D graphics experience for its next-generation console.


background

Quad Texture Maps, bad

1995: The launch of the NV1

As we mentioned in our History of NVIDIA article, the NV1 was NVIDIA's first chip and was considered to be ahead of its time in many regards. Specifically, the NV1 was novel in that it integrated audio and I/O processing on a single chip along with video. While integrated solutions may not have been appealing on the PC, this was perfect for the console, as a highly integrated part would keep costs low.

Sega hoped that it could get NVIDIA to tweak the NV1's 3D architecture for its console needs, allowing the company to take advantage of the chip's low-cost graphics with integrated audio and I/O processing. A high level deal was made between NVIDIA and Sega of Japan involving approximately 7 million dollars in investment capital.

Interestingly enough, the upper management at Sega had been so mesmerized by the possibilities of integration that the deal was signed before the NV1 was actually released to retail, before Sega even knew what NVIDIA's idea of 3D was.


More quads!

The NV1 was technologically superior to other chips of that era from two perspectives: audio and I/O. Unfortunately, the quadratic texture maps were not so appealing, and outside of NVIDIA, no one believed in quadratic texture maps -not even Sega.

The NV1 used forward-rendered quads, which was essentially what the Saturn had done, and was exactly what developers hated most about the Saturn. Now NVIDIA was trying to convince Sega that it was still a good approach. The tech demos of round spheres always looked nice, but in real-world games, working with quadratic texture maps was horrendous. Even simple things such as collision detection become very difficult.

Back to the storyline
At this time (1995-1996), NVIDIA was still a fledgling startup with approximately 30 employees and NVIDIA's Chief Technical Officer, Curtis Priem, was enamored by quadratic texture maps. As CTO, he made quadratic texture maps the standard at NVIDIA.

Shortly after executives at Sega and NVIDIA had signed the deal, Sega programming legend Yu Suzuki entered the scene. Although the original contract had already been signed at high-levels, the arcade manufacturing groups had a great deal of influence over what chip was going to be used in the next console, but despite their power, the AM groups did not see the console as their core market or concern. While Sega had its ups and downs in the home market competing against the likes of Nintendo and later Sony, its arcade division traditionally did very well. Indeed, although Capcom's Street Fighter II was the most popular arcade game in the world since Pac-Man, Sega's Virtua Fighter actually had a lead in Japan for a short time.

Suzuki-san, head of Sega's flagship AM2 division, assigned one of his best graphics people to interface with NVIDIA in the US. Although we do not have this engineer's name, we know that he had previously interfaced with Real3D in the past, and, from outside reports, had an exceptional understanding of 3D graphics techniques and rendering pipelines. Most importantly, he knew exactly what the AM software development groups at Sega needed in a graphics chip, namely triangles.

Meetings were held to discuss the rendering primitive for the NV2. Sega pushed for real triangle acceleration to be included in the NV2, but NVIDIA did not comply. NVIDIA insisted that time was better allocated developing the quadratic texture map portion of the NV2 and adapting existing triangle-based development tools such as 3D modelers to QTMs.

AM2 gives up

The End of the NV2

Just say no to triangles

Despite Sega of America's and the AM2 representative's best efforts, NVIDIA remained adamant on using quadratic texture maps and refused to concentrate on triangle primitives. In the end, our sources tell us that NVIDIA may have eventually agreed to support better acceleration for triangles, but by then, Sega of Japan had already begun to distance itself from NVIDIA, and Sega's US team was quietly told "not to worry about the NVIDIA thing anymore."

As a Japanese company, Sega could never kill a deal, for there was a need to maintain honor and face. These cultural elements can be seen today when top Japanese executives choose to demote themselves after poor earnings reports, or when disappointing employees are "transferred" to small offices and given no assignments rather than fired. The expectation is that the shame alone will lead the employee to quit himself.

Pico?
NVIDIA was relegated to this similar position. Sega told NVIDIA that they were still contracted to provide a chip for Sega, but that it was not going to be used in its next generation console. The plan was to use the chip in a less demanding multimedia consumer product, probably the next-generation Sega Pico.

The Sega Pico, as some of you may not know, was a kid's educational toy targeted for children, 2-8 years old. It was a stylus and tablet that connected to the TV and used cartridges as its media. The Pico had such great titles as "Magic Crayons", "Richard Scarry's Huckle Lowly's Busiest Day Ever", and even a few Disney titles. Basically, NVIDIA was most likely delegated to work on a glorified See 'n Say.

The death of NV2

What was the actual performance of the NV2? The truth will never be known. When the first silicon came back, it didn't work. NVIDIA respun the chip a few more times, but it soon became clear that the chip had more than just minor problems. With such dismal results, the NV2 team eventually called it quits. To the best of our knowledge, the NV2 never existed as a working product.

The Sega Aftermath

Sega Black Belt

Real3D and 3dfx
With the collapse of the NVIDIA deal, Sega started looking for another partner and eventually hooked up with Real3D, then a subsidiary of Lockheed Martin. This seemed like a good match as Sega had worked with Real3D on the development of the Model 2 arcade machine, and would later work together again on the Model 3. The console chip would likely have been at the same performance level or just slightly below Real3D's PC chip, the Intel i740.

The console was codenamed "Black Belt". Sega reasoned that casual gamers could get a "white belt" gaming system such as a PC, but real gamers would want something better, a "black belt" system.

Although there were discussions between Real3D and Sega, Real3D never made any silicon for the Black Belt. 3dfx had beaten Real3D by offering better performance and a more robust feature set. Officially, Real3D stated that the business model for the console market did not create a win-win situation with Sega as it did in the high-end arcade market.

Sega awarded 3dfx with the chip contract. The console's Black Belt name remained even after the graphics chip was to be replaced by a variant of the 3dfx Voodoo2.

3dfx, NEC, and VideoLogic
While Sega of America was working on the 3dfx-based console, Sega of Japan was tasked with the development of a parallel console powered by NEC/VideoLogic's PowerVR chipset, codenamed Katana. The teams were told that the "winner" wouldn't necessarily be the machine with the best performance. It would be the one which would have games up and running more quickly.

The contest would became an exercise in futility as Sega of Japan and NEC eventually struck a deal to use the PowerVR chip before the two consoles were actually ready to be compared. Black Belt engineers insisted that their 3dfx-powered system would have won the race.

After walking through the entire PC 3D graphics industry, Sega finally found its chip. Fortunately for Sega, the PowerVR Series 2 chip, which NEC and VideoLogic had been co-developing for some time, turned out to be a most impressive chip for the console, with exciting features such as texture compression and deferred rendering. The PowerVR-based console was presented to the AM groups who gave it the green light: the Dreamcast was born.

3dfx later sued Sega, NEC and VideoLogic, alleging that Sega deliberately mislead 3dfx to gain access to confidential technologies before choosing to go with NEC and VideoLogic. 3dfx, Sega, NEC, and VideoLogic eventually reached a settlement out of court.

The Aftermath at NVIDIA

Changes
Jen-Hsun Huang, NVIDIA's CEO, was disappointed by everything that had led to the collapse of the Sega deal. As CEO, he remained an active participant in meetings and was intimate with the technical decisions made at NVIDIA. He knew something had to change.

The failure of the NV2 prompted Huang to pick up David Kirk as Chief Scientist, who had previously been with software developer Crystal Dynamics. David Kirk essentially became the Gary Tarolli of NVIDIA, and turned NVIDIA around by combining the company's 3D knowledge with his game development experience.

Success
NVIDIA was reborn, and after the success of the NV3, or RIVA 128, the entire company would quickly discard ties to its blemished past. The rest of course, is history.

In retrospect, considering the magnitude of the failure of the NV2 it's no surprise that NVIDIA has never publicly disclosed the project. Still, the details of this incident only underline how much of a transformation NVIDIA has undergone. Five years ago, NVIDIA made mistakes that could have killed other companies, and today NVIDIA is a leader in its industry with no signs of slowing down. NVIDIA went from being a reject for the Sega Pico to the developers of the NV20 and the Microsoft Xbox.



a part from the article 'History of Nvidia'
http://www.firingsquad.com/features/nvidiahistory/page3.asp


NVIDIA's Console Chip

NV2
NVIDIA's financial savior came in the form of a video game console, more specifically, a Sega video game console. Through the NV1, NVIDIA had established a strong working relationship with Sega. The chip promoted sales of Saturn accessories and Sega programmers were somewhat familiar with quadratic surfaces after having ported a small number of games for the NV1. Most importantly, Direct3D was a non-issue because many of the Japanese console developers were ready and willing to use the unconventional technology of quadratic surfaces if it brought additional performance.

Sega funded a significant portion of the research on the NV2 and it is reasonable to suggest that NVIDIA might not exist it its capacity today if it were not for Sega's support of the NV2. Unfortunately, Sega eventually dropped the NV2 to give the Dreamcast a better future through an easier programming environment. Sega ended up going to 3dfx and later to PowerVR for the graphics technology in the Dreamcast. Little else is known about the NV2 story and the timing of events. Despite limited success of the NV1 and failure of the NV2, NVIDIA was not ready to quit.


roll on RSX......

[xbdestroya]

Megadrive - thanks for that retrospective man! That was great stuff. I love 'histories' reminding us of how we've gotten to where we are today. I knew NVidia had a disaster in the way of NV2, but I think that's the most in-depth analysis of it I've ever read. But I am glad that Jen-Hsun has been hands-on active in this throughout NVidia's life, because it raises my hopes that Ken and Jen saw eye to eye when thet finally determined to use the NVidia IP for RSX.

PowerVR, the myth, the legend... I had an Evil Kyro II card at one point. It's pretty wild that this technology which should by all accounts sweep the graphics industry continues to dissapoint. Hopefully someone will execute on the vision one day.

@Cpi: Thanks for those points on the Realworldtech DD1 power analysis, I certainly didn't catch that. Always happy for anything that starts scaling us back down closer towards that ~40+ wattage figure again.

[megadrive]

off-topic:


no prob, Xbdestroya.

although that was a good history on Nvidia and the NV2 project, it doesn't give a full history of the developments of prospect Sega consoles or Saturn upgrades
and the only main mistake that I could see is that they said NV2 was being concidered for Dreamcast -- that's not quite the case. it was concidered for a Sega console for the 1996 timeframe, but not Dreamcast specifically. Dreamcast was started in 1996 after NV2 was dead.

[Crossbar]

if it was just one way to do an S3TC compression, it could be a plug-in to just any image editor.
As it so happens, that's actually true. The statement is probably more to do with supporting those formats within that tool assuming it does other things that are actually special.
I do not think that is correct, there is one way decompress, but several ways to do the compression. Not really that strange if you give it a second thought, if the storage format of the compression forces you to distort some pixels you could always decide which pixel to give the least distortion, and from that you could go on and on to make different conditions based on different calculated average values based on the pixel positions within the texture and either iterate until the conditions are fulfilled or have a very clever algorithm to achieve them.
Like many modern image compression algorithms, S3TC only specifies the method used to decompress images, allowing implementers to design the compression algorithm to suit their specific needs. The early compression routines were not optimal, and although since greatly improved, hindered early adoption of S3TC by developers. The nVidia GeForce 1 through to GeForce 4 cards also used 16 bit interpolation to render DXT1 textures, which resulted in banding when unpacking textures with color gradients. Again, this created an unfavorable impression of texture compression, not related to the fundamentals of the codec itself.http://en.wikipedia.org/wiki/DXT5#Codecs

[lips]

cell does not need a large memory bandwidth. Think about the nature of that video games require on program code, and you will realize it.

[xbdestroya]

You'll notice the thread deals with RSX's memory bandwidth Lips, not Cell's.

[Crossbar]

The RSX fog is slowly starting to disappear. Here are a few comments from Barbarian at B3D.
RSX can texture from both Vram and main ram, but texturing from main ram is twice slower. Output is always to Vram as far as I know.
As far as I know the latency can be hidden by the hardware threading, but the pixel shaders have to use half the registers (compared to shaders when texturing from vram) otherwise there will be a performance degradation. It seems registers are shared between all hardware threads and more threads are needed to hide longer latencies, hence less registers available per thread.
I think this is interesting information. I looks like the RSX may be able to render textures from main memory and video memory at the same time.

I'm not sure I understand how more threads help hide latencies, I thought GPUs generally were good at hiding latencies by deep pipellines and prefetching. Barbarian seems to mean that the RSX will not be able to switch between hardware threads in the same way as the PPE can, instead you reserve a number of registers per thread and by that you maintain the register integrity manually. Maybe the hardware threading also helps maxing out the available bandwidth?

If the above is true there are almost unlimited possibilities of how to setup the RSX RAM usage and unlimited ways to tune the system to best use the aggregate bandwidth of both the XDR and GDDR3 memory. This will take some time to master that's for sure.

The statement "texturing from main ram is twice slower" fits pretty well with the official information available.

RSX flex I/O read bandwidth from CELL is 15 GB/s
XDR bandwidth is 25.6 GB/s
GDDR3 bandwidth is 22.4 GB/s

22.4 / 2 is 11.2 GB/s which is not much lower than the theoretical read bandwidth of 15 GB/s. Or maybe they have increased the GDDR3 speed a little bit?

[version]

Barbarian help for me, rsx will be a miltithread gpu
from nvidia patent from 2004

http://web.axelero.hu/varga1973/rs.JPG
http://web.axelero.hu/varga1973/rs2.JPG

[Crossbar]

Barbarian help for me, rsx will be a miltithread gpu
from nvidia patent from 2004

http://web.axelero.hu/varga1973/rs.JPG
http://web.axelero.hu/varga1973/rs2.JPG
Does the G70 have this setup?

[version]

this gpu(in pantent) with unified shaders, g70 not

[saxdawg00]

I think this is interesting information. I looks like the RSX may be able to render textures from main memory and video memory at the same time....
At the 36:50 mark of the pre-E3 2005 press conference, Jen-Hsun Huang confirmed this. "512MB of Graphics Render Memory" (35:33) , "....RSX can render pixels to anywhere in system memory....
It's funny, I still see non-believers stating that PS3 has only 256MB of vram. I wonder how customised RSX will be in regards to how it sends/receives data to be executed by Cell and also data that needs to be stored/retrived in the XDR half of system memory.

[version]

yes render from anywhere, but 22+25/2 about 35gb/sec very poor
ps2 has 48gb/sec

[Crossbar]

At the 36:50 mark of the pre-E3 2005 press conference, Jen-Hsun Huang confirmed this. "512MB of Graphics Render Memory" (35:33) , "....RSX can render pixels to anywhere in system memory....
It's funny, I still see non-believers stating that PS3 has only 256MB of vram. I wonder how customised RSX will be in regards to how it sends/receives data to be executed by Cell and also data that needs to be stored/retrived in the XDR half of system memory.
Yeah, I know that piece, but I am quite sure he didn't state that it could render simultanously from both GDDR3 and XDR RAM by using hardware threads in the GPU. Right???

@version: I couldn't see from those pictures the patent concerned unified shaders, do you have a link to the full patent?
I found the thread control unit interesting and the fact the shaders seemed to be organized in quads, which seems to fit the G70.

[version]

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6987517.WKU.&OS=PN/6987517&RS=PN/6987517

[cpiasminc]

I do not think that is correct, there is one way decompress, but several ways to do the compression. Not really that strange if you give it a second thought, if the storage format of the compression forces you to distort some pixels you could always decide which pixel to give the least distortion, and from that you could go on and on to make different conditions based on different calculated average values based on the pixel positions within the texture and either iterate until the conditions are fulfilled or have a very clever algorithm to achieve them.
Well, okay, in fairness, it certainly is true that you can skew the values stored so that when decoding, there will be a different interpolation table and the results may look a little better or worse. You can weight your searches and what not, but you're still going to be building around the concept of an interpolation table. The things you were suggesting before about analyzing a larger part of the image is not a part of the process. No matter what, the scale and scope of the compression is always 4x4 blocks.

Also, the big deal about the tool's S3TC support was not about importing or exporting, but that you could edit and modify the image in compressed form.

cell does not need a large memory bandwidth. Think about the nature of that video games require on program code, and you will realize it.
Aside from xbd mentioning that this is about RSX, what the hell are you thinking here? If anything, the nature of CELL as a design means it needs bandwidth to function efficiently. The more execution resources and more hardware thread contexts you support, the more bandwidth you need. I don't know where you get the idea that games are an inherently low bandwidth class of software.

It's funny, I still see non-believers stating that PS3 has only 256MB of vram.
Ummm... it DOES only have 256 MB of VRAM. If you render to contexts in main memory, you're still writing in main memory, not VRAM. Accessibility doesn't make the XDR a VRAM block anymore than Cell accessing the GDDR makes it a block of main memory.

[saxdawg00]

Ummm... it DOES only have 256 MB of VRAM. If you render to contexts in main memory, you're still writing in main memory, not VRAM. Accessibility doesn't make the XDR a VRAM block anymore than Cell accessing the GDDR makes it a block of main memory.
gotcha, but there have been some folks that are implying that RSX can only read/write to the 256 GDDR3.

[Crossbar]

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6987517.WKU.&OS=PN/6987517&RS=PN/6987517
Thanks version, :thumbl:

However, I can't find any connection to unified shaders in the patent.

I think I recognise this as Nerve's or Xb's patent about somekind of reuse of fixed function units within the GPU, but the multi-threading part is certainlý there.

We may have a match of thís patent and the RSX, I find this encouraging!!!!