Gamecube/PS2/Xbox stuff... again

[function]

I think overall the GC was clearly a more capable system compared to the PS2, I think it's interesting that people are even debating

There's at least one very highly regarded developer who did optimisation work on both who thinks the PS2 is more powerful.

GC made some nice looking games, and I prefer the "look" of GC games to PS2, but I have no problem with the PS2 being more powerful in lots of ways.

 

[see colon]

GC made some nice looking games, and I prefer the "look" of GC games to PS2, but I have no problem with the PS2 being more powerful in lots of ways.

I don't know why more people can't see it this way. Why is it inconceivable to some that Nintendo built a system with modest specs that was easy to work with and achieved good results easily, while Sony made a powerhouse that required a lot more work to untap it's potential.

 

[Exophase]

I don't know why more people can't see it this way. Why is it inconceivable to some that Nintendo built a system with modest specs that was easy to work with and achieved good results easily, while Sony made a powerhouse that required a lot more work to untap it's potential.

And why is it so inconceivable that fill rate and GFLOPs aren't an exhaustive measure of capability? I don't have a problem admitting that it's more powerful in some ways, but you said it's more powerful in every way which is ludicrous. If some areas are very powerful but are heavily bottlenecked by other areas than can you still say it's the more powerful design? Balance is extremely important.

Look at a late era Pentium 4 vs a contemporary Athlon64. On paper you could say the P4 has a much higher peak FLOPs rate, even much higher rate for something like integer adds, larger L2 cache, and so on. Would you want to say that it has much higher performance, or even higher "specs"? Most would consider that inappropriate and misleading.

 

[Blazkowicz]

PS2 has some crazy fillrate (16 ROPs?) and an impossibly fast 4MB memory, I think this allows motion blur by brute force and some other effects (though some of those effects would be done less "wastefully" by pixel shaders or Gamecube's TEV)

 

[Shifty Geezer]

PS2 has some crazy fillrate (16 ROPs?) and an impossibly fast 4MB memory, I think this allows motion blur by brute force and some other effects

Precisely. PS2 was designed to draw one effect at a time and layer them with multipass rendering. It's such a different approach to GC, it's ludicrous to try and compare the two platforms on specs. I'm reminded of a Top Gear race across London using bicycle, powerboat, car, and public transport. How do you determine which is the best solution on the specs of those systems? You don't! You just look at the outcomes.

 

[Exophase]

PS2 has some crazy fillrate (16 ROPs?) and an impossibly fast 4MB memory, I think this allows motion blur by brute force and some other effects (though some of those effects would be done less "wastefully" by pixel shaders or Gamecube's TEV)

Yeah, but it only has 8 pipelines that can texture. Which means its TMU:ROP ratio is basically 1:2 which is an odd balance even for its time, when 3D accelerators were already moving to 2:1 texels to pixels. The ALU ratio was also low even for its time, with only a very simple set of operations on a single texture.

Having a wide array of pixel pipelines meant it had to work in 8x2 or (I think?) 4x2 blocks, so there was a lot of waste around the edges of primitives, especially smaller ones. It further wasted fillrate by lacking the early-Z Gamecube and XBox had. And having to do multipass meant you ate into the triangle setup budget, further diminishing any advantage there.

But yeah, it was good for post-processing effects that worked in huge rectangles, so long as you can spare the VRAM for it...

 

[see colon]

And why is it so inconceivable that fill rate and GFLOPs aren't an exhaustive measure of capability? I don't have a problem admitting that it's more powerful in some ways, but you said it's more powerful in every way which is ludicrous. If some areas are very powerful but are heavily bottlenecked by other areas than can you still say it's the more powerful design? Balance is extremely important.

It isn't just fill and GFLOPS, it's bandwidth, it's a more flexible polygon pipeline, it's audio, storage media, and (dare I open this can of worms again) system memory. Even the GPU has more embedded memory. If you can find any metric by which the PS2 doesn't out spec the GameCube, please tell me.

Again, I'm not discounting the achievements of GC. I think it did hold up well and over achieved many of it's perceived shortcomings, but that doesn't mean that PS2 didn't have great looking games that lived up to it's potential either. There are 4 or 5 games that output 1080i, for example, and while some people might point out that they aren't rendered at full resolution, they are still higher res than GameCube games. There are certainly games that benefited from the larger storage medium. Or used it's extra processors to great effect. Or had digital surround sound,

The point is, there are games on PS2 that achieved things that weren't possible on GameCube.

 

[Goodtwin]

I dont really see memory as a strong point for PS2 compared to GC. GC has good S3TC texture compression, so even ignoring the 16MB of A-ram, the 24MB of main memory in the GC would be capable of holding higher res textures. We have already concluded that the A-ram was rather limited, but it could still be used to cache assets before they are actually needed, allowing the main memory to swap in those assets much faster than the PS2 could ever stream them off the disk. Obviously a portion of the PS2's memory is used for assets not needed for the frame being rendered, it has to bring them in before they are needed.

The GC is just a more modern design. Its like comparing a 300 Gflop GPU from 2004 to one manufactured in 2009. There is an abundance of tech that doesnt improve the ratings on the spec sheet, but instead improve actual game performance. Things like early Z dont change the theoretical fillrate, but it does drastically impact the games fillrate performance. Same goes with the S3TC texture compression, it doesnt change the memories capacity or bandwidth, but in game it does make a significant improvement, larger textures that use less bandwidth. L2 cache may not change the CPU's theoretical performance, but it makes a big difference in the real world.

Resolution was hard capped by Nintendo. The GPU itself was capable of rendering higher than 480p, but Nintendo capped the video output to 480p.

 

[swaaye]

Surely the framebuffer was too small for 720p too though? I mean 2 MB....

 

[Goodtwin]

I dont think they actually rendered to that 2MB of memory, but used it only for the Z buffer. Im pretty sure they were rendering to the main memory. I could be wrong on this, they might hold the Z-buffer and back buffer in the 2MB of edram, and then copy out to the main memory for the front buffer.

 

[AlNom]

Would have had to do software tiling I suppose. The 2MB was designed to hold ~640x480* 24-bit depth/Z + 24-bit colour target (RGB8 or ARGB6).

*or around 720x485 if you were to go by strict storage amount.

 

[Goodtwin]

Would have had to do software tiling I suppose. The 2MB was designed to hold ~640x480* 24-bit depth/Z + 24-bit colour target (RGB8 or ARGB6).

*or around 720x485 if you were to go by strict storage amount.

There it is. Is there any reason tiling wouldnt be an option? It still seems like I read some where that GC and Wii's video output hardware was the limiting factor.

 

[HTupolev]

There it is. Is there any reason tiling wouldnt be an option?

Performance and sanity.

(And available video output options, probably.)

 

[Goodtwin]

Performance and sanity.

(And available video output options, probably.)

Does tiling eat up a lot of performance? There is no question the hardware wasnt going to be making any demanding 3d games in 720p, the hardware was sweating with 480p at times, I am pretty sure Metroid Prime 3 wasnt true 480p widescreen, but something like 460p.

 

[see colon]

There it is. Is there any reason tiling wouldnt be an option? It still seems like I read some where that GC and Wii's video output hardware was the limiting factor.

Beyond the fact that it would be fillrate limited in most cases, tiling requires framebuffer alpha, and because GC/Wii can only output 24bit, if you are using 8bit for your alpha you are only getting 16bit color. That's why Cube and GC games end up with more banding. Using FSAA also makes the back buffer too large for the 2MB buffer, so games would have to drop color depth and tile to remove jaggies, and that's why so few games used it.

 

[Grall]

Surely the framebuffer was too small for 720p too though? I mean 2 MB....

IIRC, GC's framebuffer eDRAM was 2.25MB to account for PAL resolutions.

 

[Exophase]

It isn't just fill and GFLOPS, it's bandwidth, it's a more flexible polygon pipeline, it's audio, storage media, and (dare I open this can of worms again) system memory. Even the GPU has more embedded memory. If you can find any metric by which the PS2 doesn't out spec the GameCube, please tell me.

I said it in an earlier post already, the CPU is a lot better at general purpose code that isn't highly data regular. I mean, if you want to pull out paper specs that don't mean anything, you could cite peak integer operations or independent loads/stores per second or something. But you really can't ignore the big difference in cache hierarchy. EE's 16KB and 8KB L1 caches are only 2-way set associate, very meager compared to Gecko's 32KB + 32KB 8-way L1 caches + 256KB L2 cache.

As for your other points:

The bandwidth numbers Sony came up with don't really make sense, since they add together peak color/depth RMWs with peak texture loads, but you can only get half the former if texturing is enabled. Both GC and PS2 claim the same texture memory/clock bandwidth, and GC has a higher GPU clock so it actually wins there. The framebuffer bandwidth is really just another side of the arguments around fillrate, they're synonymous (I don't know how much bandwidth GC's FB eDRAM has but I'm sure it's just enough to do 4 pixels/sec with RGBA + depth instead of 16 like PS2)

For the main RAM, PS2 put its controller on the CPU side while GC put it on the GPU side, so they trade advantages there, with PS2 having 2.4GB/s peak bandwidth to RAM vs GC having 1.2GBs, while GC has 2.6GB/s bandwidth to the GPU vs 1.2GB/s for PS2. IMO, GC makes the better tradeoff here, since that bandwidth is more easily utilized filling the texture buffer (which both have to do). And on the CPU side the L2 cache absorbs a lot of the bandwidth difference.

When you mention audio, let's be clear that you're talking about output format and not processing - where a small number of games had DTS. If you look at audio acceleration, PS2's SPU2 is little more than two PS1 SPUs together. At 48 voices/48KHz you'd be looking at about 35 cycles per sample for Gamecube's DSP which is almost certainly enough to do a lot more than PS2's per-sample capability, even when you factor in ADPCM (which in practice would only go to a small buffer at a rate of far less than 1:1 input to output cycles). And of course the DSP is more flexible. PS2 has the IOP as well, but it's not as if it's an additive effect; what it'd naturally be used for (sequencing instruments on and off) is overkill for it.

I'll give you storage space, that's an easy win for PS2. I won't give you system memory. There is simply some persistent state that needs to be in RAM but doesn't have to be accessed tremendously. For an extreme example, look at the stuff that'll get saved in the memory card.

Beyond the fact that it would be fillrate limited in most cases, tiling requires framebuffer alpha, and because GC/Wii can only output 24bit, if you are using 8bit for your alpha you are only getting 16bit color. That's why Cube and GC games end up with more banding. Using FSAA also makes the back buffer too large for the 2MB buffer, so games would have to drop color depth and tile to remove jaggies, and that's why so few games used it.

What makes you think tiling requires framebuffer alpha?

You don't need dest alpha if you can avoid multipass over the part you need alpha, which with TEV you probably often could.

 

[see colon]

What makes you think tiling requires framebuffer alpha?

You don't need dest alpha if you can avoid multipass over the part you need alpha, which with TEV you probably often could.

I suppose you could tile without alpha, but there isn't any hardware support for tiling on GC so it would all be done in software. I always assumed that destination alpha would use the least amount of resources, since you have the hardware doing some of the work. Regardless, if you are are going to use FSAA, you have to drop color to 16bit (no alpha) to fit in the backbuffer or tile with a performance penalty, possibly using alpha to assist and dropping to 16bit.

 

[Exophase]

I suppose you could tile without alpha, but there isn't any hardware support for tiling on GC so it would all be done in software. I always assumed that destination alpha would use the least amount of resources, since you have the hardware doing some of the work. Regardless, if you are are going to use FSAA, you have to drop color to 16bit (no alpha) to fit in the backbuffer or tile with a performance penalty, possibly using alpha to assist and dropping to 16bit.

I'm still not seeing the connection between tiling and destination alpha, or FSAA for that matter, maybe I'm missing something you could explain? In what way does destination alpha save work?

I think destination alpha is primarily useful if you need multipass to calculate alpha. I don't know for sure but I expect multipass and tiling are both worse on GC than they could be on PS2 since presumably there's no way to save T&L so it has to be repeated, while PS2 can fairly cheaply interleave at least two passes on a per-primitive basis, although you still pay the triangle setup cost repeatedly. But PS2 relies on it far more than GC does. I doubt tiling was very seriously considered for either system.

So PS2 is more likely to need destination alpha. If you want RGB888 color anyway it's moot, since there's no packed 24-bit framebuffer mode. So yes, if you need destination alpha on GC you're stuck with fewer bits per component, but on the other hand, you end up with a smaller framebuffer footprint. And if you don't need destination alpha you again end up with a smaller framebuffer footprint. So there's disadvantages and there's advantages to the different framebuffer formats.

 

[see colon]

I'm still not seeing the connection between tiling and destination alpha, or FSAA for that matter, maybe I'm missing something you could explain? In what way does destination alpha save work?

If you are composing you frame using chunks, you'd need to have cut outs where the other chunks go. Unless you are composing and downsampling the image 100% on the CPU, in which case you wouldn't need alpha, but you are doing work on the CPU.

If you use FSAA, your backbuffer is going to be too large for the 2ish MB, so you have to tile. If you have to tile.