Gamecube's memory bandwidth

[MistaPi]

The biggest drawback of PS2 as I understand it is that it has just 4MB high bandwidth video memory (eDRAM). Games developers can use the system memory to store textures but to the system memory has just 3.2GB/s of bandwidth and will then reduce performance by doing so.
I was then reading about GCN and its graphic chip has 3MB of eDRAM (with less bandwidt than PS2), 2MB for Frame/z buffer and 1MB for texture cache. To store textures it has a 24MB external memory with only 2.6GB/s bandwidth.
Does not this put the GCN in a even worst situation than PS2 regarding memory bandwidth? What im I missing?

 

[Grall]

You're missing quite a lot by only looking at raw numbers and not knowing the specifics of the underlying architecture.

GC's main and on-chip memory (1T-SRAM) has an incredibly low access time. Literally ten times faster than standard DRAM. Thus, fetching data from RAM is accomplished very efficiently, making it easy to utilize as much as possible of those 2.6GB it has available. This is a lot more difficult on PS2 and XB due to the peculiarities of DRAM.

GCs texture cache also stores compressed textures, which gives it a virtual bandwidth that is 4-6x greater than its actual physical bandwidth. You can flag some frequently used textures to stay permanently in the cache so they won't have to be fetched over and over, while you let other textures use the chip's virtual texturing feature which means you don't fetch ALL of a texture if only a corner of it actually shows up on-screen.

When simply comparing numbers like you do it's easy to come to conclusions that may have no bearing whatsoever on reality. A bit like thinking a 2000HP diesel dump-truck would outmatch a standard family sedan speed-wise simply because its engine is so much more powerful.

There are many other factors that has to be considered, and even so it's not neccessarily true you'd come to any real conclusion. All current consoles have strengths and weaknesses compared to the others, even if their raw numbers might be smaller than the competition.

*G*

 

[MistaPi]

Thanks for enlighten me Grall

 

[mr]

Hi MistaPi,

I highly recommend the search button of this very board as it is saturated with technical information regarding PS2 and GC on this topic.

 

[Squeak]

The one thing I never fully understood about the PS2s texturing issues is the complaints about the 1.2Gb EE to GS bus.
If your running 60 fps then you have 20 Mb per frame, but of course that would come down to some 15 Mb under real world conditions and from that you have to subtract maybe 5-7 Mb for geometry depending on the game and if you are using strips to compress, you end up with some 10 Mb for textures alone.
A normal frame is roughly 1Mb big of which almost all of the screen space has to be filled with textures.
So you have 1Mb frame buffer for which you have approximately 10Mb to fill with.
Now I know there is some rendering time lost on rendering nonvisible polygons but shouldn’t that be made up for by the fact that normally a lot of the textures are tiled?
How can 10Mb not be enough for one 1Mb frame?

Some years ago, I think about the time of Voodoo 2 or 3 there was a 3D card called Starfighter, made by a now closed Intel company, Real 3d.
It, like the PS2 only had 4Mb for a framebuffer and nothing more. It relied solely, on the then new AGP port for texture streaming directly from main memory.
The textures were of equal or better resolution to that of other cards at the same price, at that time.
I once saw Quake II running on a Starfigter equipped machine and the textures were of comparable quality to a TNT2.
Why can’t PS2 use some similar technique? It has double the bandwidth (AGP 4x) and much higher fillrate, faster memory and a very strong DMAC (for lining up textures), It should be able to do much better than it is now.


Also a little thing I’ve been wondering about: I read the interview with John Carmack on Beyond 3d ( http://www.beyond3d.com/interviews/carmackdoom3/ ) where he explains about the rendering technique in Doom III, where the scene is first rendered in untextured geometry to get the upper z-values right and then later some other passes with base texture, lightmabs, bumpmabs and so on. This way a lot of texture fillrate is saved, similarly to the PowerVR tile based culling.
Why can’t a similar technique be implemented on the PS2? It would fit the machine very well because you could do the first untextured pass for very little cost due to the PS2s high fillrate when drawing untextured polygons.
I know there must be some hitch, because otherwise someone would have done this a long time ago, I just cant see why it isn’t doable.

 

[Tagrineth]

10MB for textures isn't that big, cutie. Unreal Tournament 2003, for one, at the HIGHEST possible setting, uses close to 128MB for textures alone (IIRC).

There are other games which also use more than a meagre 10MB. A great, ancient, and simple example of this is Quake III: Arena on PC - at max settings it completely chokes on a Voodoo2 (8MB texture memory), one step below and your frame rate doubles. Texture thrashing.

And one thing you forgot about the Intel Starfighter. Yes it only had 4MB for framebuffer. Yes it used AGP texturing. Yes it looked just as good as the 16MB cards of the day.

But it was SLOW.

And no, PS2 doesn't have "double the bandwidth" - From the EE to the GS is 1.2GB/sec as you already pointed out. AGP4x provides 1.06GB/sec. Not that big a difference.

I actually thought of that myself two years ago. But the problem is really simple: After your Z pass, you have to store the finished Z buffer, and you can't just 'turn off' the Z-buffer for the second pass. It burns memory. In the past video cards have needed as much memory as they could possibly get, so only now it's becoming feasible, and it's virtually required for DOOM3's shadowing method...

 

[BenSkywalker]

A great, ancient, and simple example of this is Quake III: Arena on PC - at max settings it completely chokes on a Voodoo2 (8MB texture memory), one step below and your frame rate doubles. Texture thrashing.

To expand slightly, the Voodoo2 when running Quake3 couldn't even run the highest texture settings(Q3 has 512x512 textures) not to mention it was stuck in 16bit. Despite those, it still had serious performance issues. Another example was the GeForce 32MB boards running QDM9(IIRC- the one Rev used for Quaver) where the 32MB boards couldn't handle the texture load and had serious thrashing at the highest settings, 64MB boards had significantly higher minimum framerate. And Quake3 is a game that is over three years old, 10MBs is nothing for textures by today's standards.

 

[Tagrineth]

A normal frame is roughly 1Mb big of which almost all of the screen space has to be filled with textures.
So you have 1Mb frame buffer for which you have approximately 10Mb to fill with.
Now I know there is some rendering time lost on rendering nonvisible polygons but shouldn’t that be made up for by the fact that normally a lot of the textures are tiled?
How can 10Mb not be enough for one 1Mb frame?

Another thing, I don't understand your reasoning at all. What IS your point? Yes the frame buffer will be 1MB, but what bearing will that have on texture space?

Back to the Quake3 example, the map with textures that could choke a 32MB card... I'm sure that would happen even when the frame doesn't exceed ~2MB (640x480x32).

 

[phat]

A normal frame is roughly 1Mb big of which almost all of the screen space has to be filled with textures.
So you have 1Mb frame buffer for which you have approximately 10Mb to fill with.
Now I know there is some rendering time lost on rendering nonvisible polygons but shouldn’t that be made up for by the fact that normally a lot of the textures are tiled?
How can 10Mb not be enough for one 1Mb frame?

Another thing, I don't understand your reasoning at all. What IS your point? Yes the frame buffer will be 1MB, but what bearing will that have on texture space?

Squeak's talking about textures _per frame_. He's reasoning that the PS2 has enough bandwidth to transfer 10MB of textures to the GS per frame in practical situations, and that that should be plenty for a 1MB frame buffer. 10MB per 1MB frame allows you to draw ten texels per pixel. With good LOD handling, mip-mapping, and occlusion culling, you should rarely need to overdraw that much. Sounds reasonable to me...

Phat.

 

[Fafalada]

The one thing I never fully understood about the PS2s texturing issues is the complaints about the 1.2Gb EE to GS bus.

As most misconceptions about console hardware, they tend to be generated by public opinion, so there's not much to understand

Ben,
10mb tends to be rather a lot when it represents ~1/3+ of your available graphics memory(PS2), or ~1/2+ as on GC. Only on XBox you could argue it's "not much" even though it's still not dismissively little.
PCs are a different scope memory wise, different standards apply.

But, if you want to generalize the way you guys always like to do with fillrate, in 640x480, 10mb at just 8bit/texel would theoretically be enough for 6xoverdraw with 6texels/pixel.

 

[BenSkywalker]

Faf-

10mb tends to be rather a lot when it represents ~1/3+ of your available graphics memory(PS2), or ~1/2+ as on GC.

And it still is a small amount by today's standards. I understand what you are saying, but the poster was asking about how can 10MB worth of texture not be enough for a frame buffer that takes up 1MB. I was simply trying to illustrate that even using a small frame buffer 10MBs isn't much at all, even if it is workable.

But, if you want to generalize the way you guys always like to do with fillrate, in 640x480, 10mb at just 8bit/texel would theoretically be enough for 6xoverdraw with 6texels/pixel.

And using 512x512x32 you can fit ten textures in to 10MB w/out TC

 

[archie4oz]

And it still is a small amount by today's standards.

On what, a PC?

And using 512x512x32 you can fit ten textures in to 10MB w/out TC

Yeah but why would you want to? (unless each one *needs* to display 262144 unique values possible in them)

 

[Guest]

how much is Xbox, GC and even DC texture per frame compared to PS2?

 

[Fafalada]

And using 512x512x32 you can fit ten textures in to 10MB w/out TC

Question that begs to be asked though, why would anyone want to use raw 32bit only, on a console?
Which is what original poster was referring to - on consoles, 10mb would be somewhere between "fair" and "a lot" depending on the hardware.

 

[Guest]

Question that begs to be asked though, why would anyone want to use raw 32bit only, on a console?

To push the graphics envelop further?

 

[archie4oz]

To push the graphics envelop further?

Sure, on the back of your game box! I'd say probably more than 90% of the time you'd be just wasting space with a raw 32-bit texture on a console...

 

[BenSkywalker]

Archie-

On what, a PC?

Yes, and even on the Box it isn't that much.

Yeah but why would you want to?

Just trying to illustrate how easy it is to chew up 10MBs, that's why I had the at then end of the sentence

 

[Squeak]

10MB for textures isn't that big, cutie. Unreal Tournament 2003, for one, at the HIGHEST possible setting, uses close to 128MB for textures alone (IIRC).

Surely that isn’t for a single frame but for the whole level or area in the game?
To fill an entire screen with 128Mb (or even 32Mb) worth of textures you would have to do something deliberately crazy like doing multiple layers of 1024 x 1024, 32bit alphablended textures.

And one thing you forgot about the Intel Starfighter. Yes it only had 4MB for framebuffer. Yes it used AGP texturing. Yes it looked just as good as the 16MB cards of the day.

But it was SLOW.

The games I tried on a Starfighter equipped machine (500Mhz PII) ran at completely normal speed at 800 x 600.

And no, PS2 doesn't have "double the bandwidth" - From the EE to the GS is 1.2GB/sec as you already pointed out. AGP4x provides 1.06GB/sec. Not that big a difference.

The Starfighter had AGP2x or 532Mb/sec. so PS2 has over double of that, that’s what I meant

how much is Xbox, GC and even DC texture per frame compared to PS2?

I would like to know that to. It wouldn’t surprise me if they were all around the same number but the GC and xbox had just been utilised better so far.

And using 512x512x32 you can fit ten textures in to 10MB w/out TC

And isn’t that enough, if its only one frame? If I take a random screenshot from, say UT 2003 i cant see more than 5 - 6 unique large textures.

 

[BenSkywalker]

[/quote]To fill an entire screen with 128Mb (or even 32Mb) worth of textures you would have to do something deliberately crazy like doing multiple layers of 1024 x 1024, 32bit alphablended textures.[/quote]

No, you really don't. Using Sacrifice as an example you have three texture layers(base, light, detail or Dot3) under normal conditions. Character textures go up to 256x256x32, that's not bg or sky, simply characters(and those aren't one texture per character, each body segment has its own texture). You can have over fifty characters on screen at once. If you had no texturing at all for any of the background, you would still chew up over 20MBs worth of textures. For the backgrounds, on top of the three texture layers there are also 'scars' which include both burn marks from spells and blood from kills. You can end up with five texture layers easily over everything in the game. I'm not using some bleeding edge game here either, Sac came out back in 2K. The game won't even allow you to turn the texture detail up unless you have a 64MB gfx board, it still shows improvement running 128MB too.

And isn’t that enough, if its only one frame? If I take a random screenshot from, say UT 2003 i cant see more than 5 - 6 unique large textures.

So multiply that by three or four to figure how many are actually being used(overdraw), and don't forget to factor in the amount of layers the game is using. IIRC UT2K3 hits four-five layers regularly.

 

[Fafalada]

Character textures go up to 256x256x32

Surely you aren't telling me people make opaque maps in 32bit -_- I mean I know in PC world people are downright trying to waste memory as much as possible, but that's bordering on the absurd...

If you had no texturing at all for any of the background, you would still chew up over 20MBs worth of textures.

And the actual amount of texels accessed (with mipmaps and all) is closer to 1/10th of that. (1/30th if you are willing to believe 3dlabs PR ) - which is what is relevant for what Squeak brought up - per frame texture access.