Standard PS2 framebuffer size?

[randycat99]

Basically as I understand it the 3.2gb/s main mem bus (for PS2) goes direct to the PS2 CPU. Then there is a 1.2gb/s bus from the CPU to the GPU, so there's 2gb/s for the CPU. But because of the way its setup even if you don't use all of that 2gb/s bandwidth for the CPU you still only have that fixed 1.2gb/s bus for textures and geometry.

Well, you lost me there. I thought the memory bus was capable of something like 4.8 GB/s from memory to the various units in the EE, but the memory (essentially any operation where memory is being accessed) limits effective rates to somewhere below 3.2 GB/s. The GS is on an entirely different bus for its 1.2 GB/s, as I understand. So the 2 bandwidths are not shared, ASFAIK. I could be wrong.

On the other hand for GC even if you use less then 1.3gb/s for textures and geometry you still only have a fixed 1.3gb/s of bandwidth for the CPU. But then I think 1.3gb/s bandwidth is all GC's CPU could ever need really so..

Remember, there are all those extra hardware units on the Gecko, in addition to just the main CPU. Those alone potentially will have a bandwidth appetite that would wash that of the CPU altogether, no? My guess is that with all the "automatic" effects on, you are pretty much left at square 1 where Squeak left us.

 

[Tagrineth]

Well, you lost me there. I thought the memory bus was capable of something like 4.8 GB/s from memory to the various units in the EE, but the memory (essentially any operation where memory is being accessed) limits effective rates to somewhere below 3.2 GB/s. The GS is on an entirely different bus for its 1.2 GB/s, as I understand. So the 2 bandwidths are not shared, ASFAIK. I could be wrong.

PS2's main memory is 3.2GB/sec. It's dual-channel 16-bit PC800 DRDRAM. 2 (channels) * 400 (base clock) * 2 (byte width) * 2 (DDR) = 3200 GB/sec.

However its actual end efficiency is estimated around 70% so the EE's memory controller can only access some 2.6GB/sec.

Remember, there are all those extra hardware units on the Gecko, in addition to just the main CPU. Those alone potentially will have a bandwidth appetite that would wash that of the CPU altogether, no? My guess is that with all the "automatic" effects on, you are pretty much left at square 1 where Squeak left us.

Wrong! Gekko is a pure PowerPC CPU, nothing more.

The sound DSP, I/O controller, et al. are on Flipper And most of them use the dedicated 81MB/sec lol from the A-RAM which is more than sufficient for those tasks.

 

[marconelly!]

There is nothing stopping you from storing compressed textures in main mem to

Sure, but you will be transferring those compressed textures over 1.2GB bus anyways, so it's not like it changes anything.

 

[mech]

I think the main problem is that for the GS to use a texture, it has to be in local memory - so you can't stream directly from main RAM, you have to manually copy the texture over (making sure you've got room, etc) and then flush it out to make room for more textures. Not fun.

 

[randycat99]

Wrong! Gekko is a pure PowerPC CPU, nothing more.

Well, I was told that there was some "mystery" hardware units populating the Gecko chip along with the PPC 750 that enabled some 12 GFLOPs worth of processing. Specifically, these were to support additional graphics effects. They could just have been BS'ing me, of course. I sure don't think a 485 Mhz G3 alone could pull off 12 GFLOPs all by itself.

 

[randycat99]

I think the main problem is that for the GS to use a texture, it has to be in local memory - so you can't stream directly from main RAM, you have to manually copy the texture over (making sure you've got room, etc) and then flush it out to make room for more textures. Not fun.

Essentially, that is texture streaming, right? I don't think that is necessarily scaring anyone off, who sees the need to do it.

 

[Zeross]

Wrong! Gekko is a pure PowerPC CPU, nothing more.

Well, I was told that there was some "mystery" hardware units populating the Gecko chip along with the PPC 750 that enabled some 12 GFLOPs worth of processing. Specifically, these were to support additional graphics effects. They could just have been BS'ing me, of course. I sure don't think a 485 Mhz G3 alone could pull off 12 GFLOPs all by itself.

it's the T&L engine of the whole system that can reach a peak performance of 10.5GFlops if I'm not mistaken. Gekko itself can do 4 FP ops per cycle (2 MAC) on single precision data, geaving it a peak performance of 1.9GFlops.

 

[Teasy]

Well, you lost me there. I thought the memory bus was capable of something like 4.8 GB/s from memory to the various units in the EE, but the memory (essentially any operation where memory is being accessed) limits effective rates to somewhere below 3.2 GB/s. The GS is on an entirely different bus for its 1.2 GB/s, as I understand. So the 2 bandwidths are not shared, ASFAIK. I could be wrong.

Ok, I'll try to clear this up for you. Ok, we have 32mb of main memory. From that there is a 3.2gb/s bus that goes to the CPU. From there you have a 1.2gb/s bus from the CPU to the GPU.

So it looks like this:

32mb main ram --------- CPU --------- GPU

(----- = a mem bus).

So while the GS is on a seperate bus to the CPU and main ram it can only be fed by the 3.2gb main ram bus. Because it has no other connection to main ram. Any data coming from main ram to the GPU has to first pass over the 3.2gb/s bus to the CPU before going onto the GPU over the 1.2gb/s bus. So if you send 1.2gb of data from main ram to the GPU in a second you then only have 2gb/s bandwidth left that second on the main bus.

GameCube is like this BTW:

24mb main ram---------GPU--------CPU
!
!
!
!
16mb A-Ram

EDIT:.. hmm, for some reason that doesn't look right when its posted. The 16mb A-Ram bus should be connected directly to the GPU not to the 24mb main ram.

Remember, there are all those extra hardware units on the Gecko, in addition to just the main CPU. Those alone potentially will have a bandwidth appetite that would wash that of the CPU altogether, no? My guess is that with all the "automatic" effects on, you are pretty much left at square 1 where Squeak left us.

Gekko is just a supped up PowerPC CPU, it has some changes internally but it doesn't have any extra units and the 1.3gb/s max bandwidth is more then enough for it AFAICS (especially since its incredibly low latency ram).

 

[zurich]

Don't forget about the PS2's DMA controllers / path-3 texture upload.

 

[Teasy]

Don't forget about the PS2's DMA controllers / path-3 texture upload.

If anyone actually gives some specific info on it then I won't forget about it. But it almost seems as if this "path-3 texture upload" thing is a myth or something, or even some sort of fancy name for something non-hardware. I remember this being asked about quite a few times (to Faf ect) but AFAIR nobody ever answers about this thing. Does it excist?.. what is it?

 

[zidane1strife]

hmmm...
I thought i read not sure(in the MGS2 doc.) that some models have up to 10MBs of texture data... it doesn't seem feasible(considering there are many models and there's a background and all..) with so little b/w...
Did i read wrong?
Or is that really possible?
.... and SH3 seems to have even better texturing... how are konami dev.s doing this?

EDITED

 

[Tagrineth]

hmmm...
I thought i read not sure(in the MGS2 doc.) that some models have up to 10MBs of texture data... it doesn't seem feasible with so little b/w...
Did i read wrong?
Or is that really possible?
.... and SH3 seems to have even better texturing... how are konami dev.s doing this?

Same way Capcom and Factor 5 are pulling such unbelievable feats on the GCN, I'd wager... by really knowing the hardware in and out and working with it to find tricks that will improve efficiency and end quality.

 

[PC-Engine]

Wrong! Gekko is a pure PowerPC CPU, nothing more.

IIRC the Gecko has more L1 cache than the stand PPC core and IBM also added some extra instructions among other things.

 

[Tagrineth]

Wrong! Gekko is a pure PowerPC CPU, nothing more.

IIRC the Gecko has more L1 cache than the stand PPC core and IBM also added some extra instructions among other things.

There are a lot of PowerPC cores I never said it was any specific core.

Think!

And yes of course I knew Gekko has a number of extra gaming-specific instructions...

 

[Zeross]

Wrong! Gekko is a pure PowerPC CPU, nothing more.

IIRC the Gecko has more L1 cache than the stand PPC core

No, just as much as the 750cx core it's derived from : 32Ko I-Cache and 32Ko D-Cache both 8 way associative.

and IBM also added some extra instructions among other things.

You're right on this one, 38 new instructions, some kind of data compression, cache locking and a SIMD FPU.

 

[zurich]

Didn't IBM split the double precision 64 bit FP unit into two, single precision 32bit FP ops?

 

[archie4oz]

Don't forget about the PS2's DMA controllers / path-3 texture upload.

Does it excist?.. what is it?

Of course it exists... It's just the path from the EE main bus to the GIF. The whole deal with it simply being able to transfer data from main mem or SPRAM interleaved with data from PATH1 (VU mem1...).

All this xxx GB/s and n MB of texture stuff is rather silly though, most if not all data is compressed anyway and unpacked by various units (IPU, VIF, GIF).

Didn't IBM split the double precision 64 bit FP unit into two, single precision 32bit FP ops?

No, it's capable of DP maths. It can just function on 2 element float vectors in FPU registers much like 3Dnow! does...

 

[PC-Engine]

In other words it's not an off the shelf PPC750cx or ANY other PPC. It's a custom design. Regarding the cache, IRC an IBM guy said it had more cache..

Damn, I knew something was going to pick up on that.

Umm...I'd be pretty upset if someone called me a *thing*

 

[Zeross]

Didn't IBM split the double precision 64 bit FP unit into two, single precision 32bit FP ops?

Yep that's what I was referring under the "SIMD FPU" in my previous post

 

[mech]

I think the main problem is that for the GS to use a texture, it has to be in local memory - so you can't stream directly from main RAM, you have to manually copy the texture over (making sure you've got room, etc) and then flush it out to make room for more textures. Not fun.

Essentially, that is texture streaming, right? I don't think that is necessarily scaring anyone off, who sees the need to do it.

Well, sort of. You're having to duplicate textures this way, (unless you 'move' the textures back and forth, which is going to cost bus bandwidth), and it makes things a lot trickier. It'd be far easier to be able to address textures in main memory.