Some quick questions about GS and bandwidth (PS2)

[patroclus02]

Hi,

I think I have a quite detailed knowledge about PS2 system. But I don't get some points.

- GS has 2,4Gpixels/s fill rate, and it is said to be capable of 1,2Gtexels/s. Why?? It really does not have any TMU, does it??

- Main RAM has 3,2Gb/s bandwidth. But EE internal I/O DMAC is capable of reaching only 2,4Gb/s. It controls the EE - GS transfers, so, why did I see some places info such as:
- GS has a memory bandwith of 1,2Gb/s
Also, if EE can only access RAM at 2,4Gb/s max, why is 3,2Gb/s memory bandwithd mentioned if it is not used??

Thanks so much!!

 

[Squeak]

- GS has 2,4Gpixels/s fill rate, and it is said to be capable of 1,2Gtexels/s. Why?? It really does not have any TMU, does it??

Well maybe not in the traditional PC sense, but obviously it must have some kind of texture mapping unit.
Regarding the fillrate; I think it collapses the 4x4 texturing quad into a 4x2 one, to be able to do bilinear.
AND NO! You won't be able to do point filtering at 2,4Gpixel for some reason.

- Main RAM has 3,2Gb/s bandwidth. But EE internal I/O DMAC is capable of reaching only 2,4Gb/s. It controls the EE - GS transfers, so, why did I see some places info such as:
- GS has a memory bandwidth of 1,2Gb/s
Also, if EE can only access RAM at 2,4Gb/s max, why is 3,2Gb/s memory bandwidth mentioned if it is not used??

I believe it's like this: 3.2 is the total bandwidth of the two Rambus chips 1.2 is reserved for the GIF and the rest is free for the three CPU cores to use.

 

[London Geezer]

Well maybe not in the traditional PC sense, but obviously it must have some kind of texture mapping unit.
Regarding the fillrate; I think it collapses the 4x4 texturing quad into a 4x2 one, to be able to do bilinear.
AND NO! You won't be able to do point filtering at 2,4Gpixel for some reason.

I always thought that the theoretical bandwidth is cut in half just for using textures, not becasue of Bilinear. So of course you can't point-sample at 2.4Gpixel, as soon as you use textures it goes down to 1.2Gpix...
And if i remember correctly (very unlikely) it's cut in half for each texture layer, so it would be 600Mpixel for two layers, 300Mpix for 3 and so on... But i'm sure my memory is miserably failing me...

 

[patroclus02]

But aren't all RAM transfers controlled by the EE DMAC ?? If it has 2,4Gb/s bandwidth, that shoul include the 1,2Gb for the GIF ?

Or maybe, 3,2Gb/s RAM bandwidth is for both directions, so there's only 1,6Gb/s for each direction, and thus, DMAC can handle all of it (2,4Gb/s) ?

 

[Squeak]

I always thought that the theoretical bandwidth is cut in half just for using textures, not becasue of Bilinear. So of course you can't point-sample at 2.4Gpixel, as soon as you use textures it goes down to 1.2Gpix...
And if i remember correctly (very unlikely) it's cut in half for each texture layer, so it would be 600Mpixel for two layers, 300Mpix for 3 and so on... But i'm sure my memory is miserably failing me...

Why would the bandwidth be cut exactly in half just for the extra strain of loading textures otherwise?
I believe one of the resident (now former) PS2 developers explained it once.

And the halving of fillrate for every texturelayer? I believe you got that a bit wrong. The GS only uses rendertime on the pixels you actually write to.
So if you only need to do a lot of passes on small part of the scene, you still have tonnes of fillrate left.
To the GS (unlike other GPU at the time with two TMUs per pixelpipe) is doesn't matter if all the other passes are the same model repeated or something completely different.

Besides the fillrate is there to be used. The average overdraw in a normal games is something like 4x leaving ~35 passes for the whole screen for anything else you could want.

But aren't all RAM transfers controlled by the EE DMAC ?? If it has 2,4Gb/s bandwidth, that shoul include the 1,2Gb for the GIF ?

Or maybe, 3,2Gb/s RAM bandwidth is for both directions, so there's only 1,6Gb/s for each direction, and thus, DMAC can handle all of it (2,4Gb/s) ?

I haven't been able to find any other logical answer, not even in the old PS2 dev. manuals I dug up from the depths of my HD.
I guess we have to wait until someone with more in depth knowledge sees this thread, if they can be bothered to answer that is.

 

[Guden Oden]

I always thought that the theoretical bandwidth is cut in half just for using textures, not becasue of Bilinear.

Yeah. Bilinear is free on PS2 - textures isn't. From what I seem to recall, this is because GS - and the original PS 3D hardware - had two pixel units, but only one of them capable of texturing. So hence, untextured performance = 2x textured...

And if i remember correctly (very unlikely) it's cut in half for each texture layer, so it would be 600Mpixel for two layers, 300Mpix for 3 and so on... But i'm sure my memory is miserably failing me...

Actually, GS can only do one layer of textures on a poly, but if you layer many polys to do multitexturing that way you burn fillrate by 1/(# of poly layers) just like with any other 3D hardware...

But aren't all RAM transfers controlled by the EE DMAC ?? If it has 2,4Gb/s bandwidth, that shoul include the 1,2Gb for the GIF ?

DMAC is a memory block transfer engine; it pipes data between VUs, the CPU local store, MPEG decoder, the GIF etc, but it doesn't handle ALL memory access. EE core has direct access to RAM.

GIF can pipe data from VU1 local store too and not just RAM, so that 1.2GB doesn't actually come out of anything. It's just the data rate of the physical 64-bit connection between the emotion engine and the graphics synth. Sort of like ye olde AGP4x bus in PCs (except that 'only' ran at ~1.08GB/s IIRC).

Or maybe, 3,2Gb/s RAM bandwidth is for both directions, so there's only 1,6Gb/s for each direction, and thus, DMAC can handle all of it (2,4Gb/s) ?

DRDRAM isn't bidirectional. 2.4GB/s comes from the speed of the internal 300MHz, 128-bit databus in the EE. That's the speed data can actually be delivered at from the DRDRAM memory controller to any of the internal devices of the EE...

Hope I got everything right!

 

[Megadrive1988]

Hi,

I think I have a quite detailed knowledge about PS2 system. But I don't get some points.

- GS has 2,4Gpixels/s fill rate, and it is said to be capable of 1,2Gtexels/s. Why?? It really does not have any TMU, does it??

I'll take this question even though it's already been answered in a different way.

as far as I know the 16 pixel engines / pixel-pipelines in GS do not have TMUs. it's like GS is a 16:0 architecture, meaning 16 pixel pipes, zero TMUs per pipe. a pixel engine/pipeline can be used to do texture mapping. so in that sense, it makes GS like a 8:1 architecture.

GS can do 16 untextured pixels per clock (thus ~2.4 Gpixels/s or 8 single-textured pixels per clock (thus 1.2 Gtexels/s)

I often imagined what GS would've been like if it had, say, 1 TMU per pixel engine/pipe, had loop-back and didn't have to re-send geometry every cycle/pass, and had 32 MB of external memory (of its own) connected at 3.2 GB/sec in addition to the 48 GB/sec 4 MB EDRAM.

 

[patroclus02]

32 MB of external memory (of its own) connected at 3.2 GB/sec

But, as DMAC controls RAM to GS transfers, the bandwidth is limited to 2,4Gb/s

 

[patroclus02]

But, as DMAC controls RAM to GS transfers, the bandwidth is limited to 2,4Gb/s

But now, that I think about it, if DMAc works at 300Mhz, and uses 128 bit buses, shouldn't it be able to achieve 4,8Gb/s??
Maybe not for RAM transfers, but for internal EE devices??
128 / 8 * 300Mhz = 4800 Mb

 

[Squeak]

If true, that's an awfull waste! 800Mbs would have meant a lot for the already bandwidth starved EE core.