Brief inquiry on PS2 GS capabilities.

[JesusClownFox]

Hello! I've been following disucussions on the B3D forums for a while now, but I've been meaning to pose this question for clarification, after reading the many technical threads on this board. Anyway, knowing that practically every other component on the PS2 is a custom-suited general-purpose processor with great flexibilities, how does the Graphics Synthesizer compare? Are its capabilties as vague as the rest of the system? Is it just a plain old rasterizer and nothing more? I've heard that all it can really do is alpha, but I'm also assuming that it has hardcoded support for [perspective-correct] texture-mapping and Z-buffering as well.

Many thanks in advance!

 

[Paul]

GS is fast fast fast in bandwidth, can draw more polygons than EE can throw at it, and has a monster fillrate.

Lacks DRAM(only 4mb), lacks native compression, also lacks many features.

The GS was designed in a time when it was all about fillrate and bandwidth though.. and for what it was, Sony did a decent job.

 

[JesusClownFox]

Right, I know that it was designed to be a fillrate beast, and that it can draw geometry and its lighting calculations very quickly, but in terms of features, can it natively do texture-mapping and Z-buffering?

 

[Paul]

Texture mapping is not native as fillrate drops in half when it's turned on. It does have a Z buffer yes.

 

[ERP]

Texture mapping is not native as fillrate drops in half when it's turned on. It does have a Z buffer yes.

In what way does that make it none native? Yes it textures at half the speed it draws none textured poly's but it's definitely a hardware feature.

The GS is a very basic rasterizer, in some ways it's featureset is sub Voodoo2, but it does do most of the basic operations, texturing mipmapping, bi/trilinear texturing, Z buffering etc.

It attempts to make up foir the lack of features with raw fillrate.

 

[JesusClownFox]

Edit: Nevermind, thanks ERP.

 

[MrWibble]

Um... since when did a feature not being free make it "not native" ?

Native would (at least in my book) be feature which are built in, and can be achieved in a single operation.

 

[Paul]

In what way does that make it none native? Yes it textures at half the speed it draws none textured poly's but it's definitely a hardware feature.

I think what I mean by 'native' is just different than what other people think basically.

 

[Panajev2001a]

Texture mapping is not native as fillrate drops in half when it's turned on. It does have a Z buffer yes.

In what way does that make it none native? Yes it textures at half the speed it draws none textured poly's but it's definitely a hardware feature.

The GS is a very basic rasterizer, in some ways it's featureset is sub Voodoo2, but it does do most of the basic operations, texturing mipmapping, bi/trilinear texturing, Z buffering etc.

It attempts to make up foir the lack of features with raw fillrate.

Mip-mapping... I would believe you if I did not have too many PS2 coders swearing at its implemetation in "obscure unt arcane ways".

In some ways I find neat the idea that the machine uses 16 Pixel Engines ( 16x0 ? Yes, we may define it that way ) when it is no texturing to be done ( great for Shadow Volumes, transparencies heavvy effects [think FFX's Aoens], opaque and translucent overdraw, etc... ) and for texturing switches to a 8x1 configuration.

 

[Squeak]

To me it seems odd that the engineers who made the GS chose not to allocate more internal bandwidth for texture. Out of the 48Gb/s there is only 9.6Gb/s available for textures, the rest (38.4Gb/s) is for Z and screenbuffer read and write.

I don't think 9.6Gb/s is bad for its time, it just seems obvious to me, that texture bandwidth should have first priority, and the more the better.
The "cinematic" effects made easier by large screenbuffer bandwidth is nice, but if textures look bad, it doesn’t really matter how much blur and how many reflection maps you can do.

Sony must have known that texture bandwidth would be one of the first areas competitors would try to hammer them, therefore it puzzles me why they chose such a relatively small width of bus, when apparently they could have had so much better.

I know Gamecube has slightly better texturebandwidth, around 10Gb/s IIRC and 5Gb/s for Z and renderbuffer. I also know that xboxs final cache, before the texture units is 8Kb (same as PS2), but I don't know Gamecubes texturecache size, neither NV2as bandwidth or level 2 tex.cache size, so it's hard to even make a rough guess about what really is the norm, and how much is actually needed for frame and Z buffer in a modern GPU.

I guess the question I'm really asking, is if the GS is bottlenecked at the eDRAM to texture cache bus?

 

[Deadmeat]

...

To me it seems odd that the engineers who made the GS chose not to allocate more internal bandwidth for texture. Out of the 48Gb/s there is only 9.6Gb/s available for textures, the rest (38.4Gb/s) is for Z and screenbuffer read and write.

Do not try to make any sense out of GS architecture. I tried...

I don't think 9.6Gb/s is bad for its time, it just seems obvious to me, that texture bandwidth should have first priority, and the more the better.

GS didn't need more text bandwidth, it needed an external texture RAM sitting next to GS.

Sony must have known that texture bandwidth would be one of the first areas competitors would try to hammer them, therefore it puzzles me why they chose such a relatively small width of bus, when apparently they could have had so much better.

You are giving too much credit to SCEI engineers, GS is basically a quick & dirty hack job, stitching together 8 PSX1 GPU cores to deliver the fillrate demanded by Kutaragi Ken.

GS = an 8-way PSX1 GPU SLI
SPU2 = two PSX1 SPUs in one chip.

I guess the question I'm really asking, is if the GS is bottlenecked at the eDRAM to texture cache bus?

No, it is bottlenecked by an eDRAM block too small for the job.

 

[Panajev2001a]

The only thing I can agree with you Deadmeat is that there are some things that were kept intentionally similar to facilitate the GS running PSOne games: I found ti interesting how the GS wants Vertices in Fixed-Point format ( while it automatically converts them back to FP for Triangle Set-up ).

 

[Lazy8s]

Paul:

The GS was designed in a time when it was all about fillrate and bandwidth though..

I don't see that the focus of finding a good balance has ever been so different, and back in that time (and earlier), even, there were still designs that took a less brute approach.

 

[ERP]

Mip-mapping... I would believe you if I did not have too many PS2 coders swearing at its implemetation in "obscure unt arcane ways".

I said nothing about the quality of the solution.
The issue is the setup for mip mapping, not the GS side, it's just that pretty much every piece of hardware, since voodoo 1 and a lot before have done it for you. You basically have to compute or fudge the parameters. Usually it ends up being the latter.

 

[Squeak]

Re: ...

I guess the question I'm really asking, is if the GS is bottlenecked at the eDRAM to texture cache bus?

No, it is bottlenecked by an eDRAM block too small for the job.

Then how come GC gets by fine, with only one megabyte for textures, and xbox with even less (256Kb?)?

You are probably going to mention texture compression now, but keep in mind that it's very rare, that we see even 4bit high-res textures on PS2, after all a 512x512x4 would only take up 131Kb.
No chain is stronger than its weakest link, and in most texturecompression schemes, decompression has to take place before the final cache, so the bus between L2 and L1 texture cache could potentially become the limitation for texel throughput.

 

[marconelly!]

I don't think 9.6Gb/s is bad for its time, it just seems obvious to me, that texture bandwidth should have first priority, and the more the better.
The "cinematic" effects made easier by large screenbuffer bandwidth is nice, but if textures look bad, it doesn’t really matter how much blur and how many reflection maps you can do.

As other said, the problem lies more in the low amount of memory (main RAM is the bigger problem actually, as that is where the textures are stored). They obviously had to cut somewhere, and RAM was expensive.

On the other hand, many people enjoy that type of visuals. It's was just something different than what PC at the time could offer (or Dreamcast for that matter) and it's also obvious that with some effort you can get good looking textures out of the machine as well.

 

[Deadmeat]

...

Then how come GC gets by fine, with only one megabyte for textures, and xbox with even less (256Kb?)?

GC :
1. Keeps only one frame buffer onchip, while "pushing out" the front frame buffer to external video memory.
2. S3TC
3. GPU has a direct control of external video memory.

Xbox :
1. Has an onchip Z-buffer compression.
2. DXTC(Same as S3TC)
3. GPU has a direct control of external video memory.

An ideal GPU configuration is an internal back frame + z-buffer, and an external front frame buffer + texture memory. Compare above to the GS

GS :
1. Must keep all three buffers onchip(eats 3.5 MB out of 4 MB)
2. Has no texture compression.
3. Has only 512K available for texture buffer.
4. Has no external memory.
5. A developer must continually upload new texture into texture buffer inside the GS before sending polygons.

 

[Squeak]

As other saids, the problem lies more in the low amount of memory (main RAM is the bigger problem actually, as that is where the textures are stored). They obviously had to cut somewhere, and RAM was expensive.

But GC and DC? Higher resolution textures with "only" respectively 24 and 16Mb RAM?
And again, as the majority of PS2 games use mostly 4bit CLUT, other kinds of texturecompression (S3TC and 2x2VQ) wouldn’t have an advantage, if we are talking about the resolution of the textures only.

I found ti interesting how the GS wants Vertices in Fixed-Point format ( while it automatically converts them back to FP for Triangle Set-up ).

I know the EE can handle compressed geometry (3 bytes for single vertice), but what about the GS? From what you are saying it sounds like it.

 

[Lazy8s]

marconelly!:

As other saids, the problem lies more in the low amount of memory

If you were to give it more memory but left the bandwidth and other designs the same, I don't see how that would turn its situation around so much. If it were the case, you'd expect there'd be PS2 games out there with a better balance of RAM allocation for textures that would sit up there with the best textured Xbox games (from a technical standpoint).

(main RAM is the bigger problem actually, as that is where the textures are stored).

Well, the conflict (which causes compromise on PS2 that even DC doesn't suffer) of balancing image buffer space with texture cache in GS display memory would have to be addressed too for optimal results.

it's also obvious that with some effort you can get good looking textures out of the machine as well.

True. You can get good looking cinematic-type effects with some effort from the more PC-like systems, too.

 

[Guden Oden]

To me it seems odd that the engineers who made the GS chose not to allocate more internal bandwidth for texture. Out of the 48Gb/s there is only 9.6Gb/s available for textures

Only? 9.6 is more than say, a GF3 Ti500, has for its entire framebuffer. Considering the basic architecture with 8 textured pixels/clock (2 clocks, if you want trilinear afaik), it's entirely sufficient. Whatever could it use more for anyway?

It's already got a 2560-bit memory interface, isn't that enough for you?

I don't think 9.6Gb/s is bad for its time

Not bad for its time? It's a totally, overwhelmingly class-leading device for its time and you say it's not BAD? The thing went on sale in 2000, was there anything even remotely similar in consumer space? No.

it just seems obvious to me, that texture bandwidth should have first priority, and the more the better.

I don't know what I'm missing, but it must be something. Assume 16-bit textures, bilinear filter * 8 pipes = 64 bytes/clock * 150MHz (actually a little less but whatever), that's under 9GB/s, well within the available bandwidth. And, we know PS2 games rarely ever use 16-bit textures because actual devs working on the thing have posted here and said as much! What would it possibly use more than the current available bandwidth for, 32-bit textures it doesn't have room to store, nor the need for? Also, it'd be unlikely (to say the least) that the chip would need to fetch 4 unique texel samples for each pixel. Real-world texture b/w would likely be far less.

The "cinematic" effects made easier by large screenbuffer bandwidth is nice, but if textures look bad, it doesn’t really matter how much blur and how many reflection maps you can do.

But it's already got sufficient texture b/w for the task, so why worry?

Sony must have known that texture bandwidth would be one of the first areas competitors would try to hammer them

It's got over nine and a half gigs of texture b/w ALONE. The on-chip memory already makes it rediculously fast at just about any framebuffer operation. Bandwidth is most likely the least of Sony's worries.

when apparently they could have had so much better.

Yeah, because all their opponents SO out-bandwidth Sony, get outta here! Come on now, give them some cred for frig's sake. 48 gigs, can't mess with that. There's nothing on the market right now, four years and counting after PS2's release, that offers higher aggregate numbers. You could pull a Nvidia and factor in compression of course, but that'd be cheating...

I guess the question I'm really asking, is if the GS is bottlenecked at the eDRAM to texture cache bus?

Uh, why would it be? Don't really know if the GS can be described as being bottlenecked anywhere internally, it's pretty fast for what it does.