I think you're overstating that GSCube was very successful even in its intended application. From what I've read, less than 20 were ever made and it wasn't long before they were sent back to Japan where they were destroyed. It allegedly took several minutes to upload the results from the GSCube to the attached server, which defeated the purpose of having real time rendering. Which, if true, shows how much of a hacked together effort this was. And I wonder if it would have competed well against a hypothetical similar effort from a rival like nVidia and if that simply didn't happen due to lack of interest and demand rather than Sony holding an intrinsic advantage for this application.
There's also claim that they were sold at a tremendous loss. All of this information is taken from here: http://assemblergames.com/l/threads/gscube-information.18036/#post-271056
Still it's kind of moot; even if it was great for movie previews (which could be useful with very specific criteria, like high polygon count but low shading quality) that alone doesn't support the argument that something like it would have been well suited for PS3.
GS had really serious limitations that I don't think you're really addressing this. function mentioned a big one, lack of decent texture compression. Culling is a little more debatable, we could argue the suitability of keeping that largely in the vertex shading domain (the VUs) although I think there's a reason other GPUs haven't done this and the problem (percentage of polygons that need to be culled geometrically) would have gotten worse with resolution scaling.
But I'd say that the entire shading model had real intrinsic limitations. Not just because of lack of blend operations but because the precision/dynamic range was of the values was limited to 8-bits per component. You could really do that many blend passes before quantization noise ruined the image quality. And the way the eDRAM-based framebuffer is used for intermediate value storage is inefficient compared to the register model other GPUs have followed. The bandwidth needed to perform RMWs from eDRAM almost certainly resulted in more power consumption than bandwidth needed to update SRAM based registers, especially when accounting for forwarding in the ALUs. With the SRAM based register files in GPUs the intermediate operations don't have to be coherent in screen space and can manage better than GS can with aggregating many small polygons over the same shader, where GS has to update 4x2 or 8x2 blocks in eDRAM vs other GPU shaders typically working in 2x2 quads.
I'm sure there's also a very real bandwidth/power overhead in having to resubmit triangles for multi-pass, and some inefficiencies on the VU (Cell SPU?) side keeping the GS FIFOs full.
The lack of implicit texture caching/requirement to load textures into the eDRAM almost certainly would have resulted in a lot of needless redundancy in textures loaded to different eDRAM tiles. The solution to this, making the tiles larger, would have needed more ALUs per tiles and would have exasperated the aforementioned screen-space coherency problem.
Then there's the lack of many other features that improved efficiency like early/hierarchical depth testing, which were already features in the PS3 console generation.
No matter how you slice it 512MB of eDRAM is enormous for the 1080p targets GSCube was designed for. Even if we would have been looking at an 8xGS with 256MB of eDRAM instead for something targeting PS3 that still would have been a tremendous amount of eDRAM for the time and I doubt it would have been economical. 1GB of RDRAM would have also been fairly expensive.
For its generation, you could say GS was a decent architecture. You could also say Flipper and NV20A were, each having different strengths and weaknesses and being very different from GS. But I can't agree that it would have been competitive moving forward by simply brute force scaling any of these upwards like GSCube did.
Last edited:
