Standard PS2 framebuffer size?

[Teasy]

Of course it exists

Well you can hardly blame me for asking, nobody ever really ackowledged its excistence before you AFAIR. Or if they did they never mentioned exactly what it was.

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...)

Could you be more specific there? How wide is the bus and how fast?

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).

But just because something's compressed that hardly means you then have no bandwidth limits. Bandwidth still counts surely, especially when comparing systems texturing power.

 

[PC-Engine]

Also Falalada said that the PS2 JPEG compression argument that everyone likes to use as a defense agains S3TC isn't valid in realworld situations because it's hardly trivial and no games have used it so far.

 

[randycat99]

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.

Why would you be moving textures "back"? All this is is just a mainpool of texture in main memory and you are sending chunks of it (duplicate copies, in your words) into the video buffer. Once it is done in there, it is flushed. The mainpool remains intact as long as it is needed for the level, as I imagine.

If you could address textures in main memory, obviously there would be no need for streaming and caching. You would be limited by the speed and latency of the main memory, though. It's just a design choice. If you can't have (or it isn't feasible to have) your entire main memory running like your video subsystem, then you are left with a caching/streaming strategy from main memory to a video buffer that *does* run at video memory like speeds. ('scuse my primitive lingo)

 

[archie4oz]

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..

Well any PowerPC is really just an implimentation of a common core (e.g. 60x, 750, 7400, 7450, 40x, 44x, etc...). Gekko is basically a 750 implimentation (using a 750CX/CXe as a starting point). The cache is pretty much the same (aside from Load Q, Store Q, and DMA Q, write-gather pipe, and some FX cache enhancements (similar to those in the 7455 caches)...

 

[randycat99]

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

Oops! I don't know how I came about typing that. Yes, I certainly do mean "someone". No offense intended.

 

[PC-Engine]

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.

Ok I finally remember now, the IBM guy said there was more L2 cache, 256K to be exact so in my original statement what I meant to say was that it has more L2 cache than the PPC750cx core 8)

 

[randycat99]

I thought the Mac versions already come with the 256k L2.

 

[PC-Engine]

 I sure don't think a 485 Mhz G3 alone could pull off 12 GFLOPs all by itself.

Not even the worlds fastest single core vector microprocessor at that time (NEC SX-6) could do 12 GFLOPS.

 

[mech]

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.

Why would you be moving textures "back"? All this is is just a mainpool of texture in main memory and you are sending chunks of it (duplicate copies, in your words) into the video buffer. Once it is done in there, it is flushed. The mainpool remains intact as long as it is needed for the level, as I imagine.

If you could address textures in main memory, obviously there would be no need for streaming and caching. You would be limited by the speed and latency of the main memory, though. It's just a design choice. If you can't have (or it isn't feasible to have) your entire main memory running like your video subsystem, then you are left with a caching/streaming strategy from main memory to a video buffer that *does* run at video memory like speeds. ('scuse my primitive lingo)

Read my post again. I said you have to duplicate textures - but this can be avoided if you move the textures back and forth, which consumes bandwidth but frees up memory.

You wouldn't be limited to the speed of main memory if the video system could address both the local cache/frame buffer and the main memory.

 

[randycat99]

Not even the worlds fastest single core vector microprocessor at that time (NEC SX-6) could do 12 GFLOPS.

That's what I thought, as well. You don't know the beginning of how long I argued with one guy on a forum elsewhere about that.

 

[randycat99]

Read my post again. I said you have to duplicate textures - but this can be avoided if you move the textures back and forth, which consumes bandwidth but frees up memory.

I suppose if you really need the space...otherwise I would just let it sit to save on copy, delete, and rewrite resources.

You wouldn't be limited to the speed of main memory if the video system could address both the local cache/frame buffer and the main memory.

I intended to say that the video process itself would/could get stalled whenever you did try to access textures directly from main memory (which was the whole point of avoiding the streaming-to-local-buffer scenario, right?).

 

[Teasy]

Maybe that guy was talking about Flipper's HW T&L unit thinking that it was part of Gekko and adding Gekko's GFLOP's to the HW T&L units GFLOPS? Just a guess.

 

[randycat99]

Certainly that is a possibility. I recall even discussing that very premise, but when a person has their mind made up, there's no budgin' them. They were hellbound to believe that the Gecko with just a PPC750 could pull off 12 GFLOPs which summarily trumped the 6.2 of the EE.

What was all the more humorous was that this guy would bash the PS2 simply because it utilized vector units (and the other 2 consoles were therefore superior since they did not rely on vector units), but now we come to find out that there is indeed a SIMD implementation in the Gecko, as well. (You see, this guy was all hot over the Xbox at the time, but then rapidly switched interests to the GC when the tech hype of that console started to wind up.)

 

[archie4oz]

256K to be exact so in my original statement what I meant to say was that it has more L2 cache than the PPC750cx core

Well technically an L2 isn't part of a CPU 'core'... Anyway, 256KB is standard for the 750CX/CXe (I've got an iBook with a 750CXe), 512KB in the 750FX...

 

[PC-Engine]

Certainly that is a possibility. I recall even discussing that very premise, but when a person has their mind made up, there's no budgin' them. They were hellbound to believe that the Gecko with just a PPC750 could pull off 12 GFLOPs which summarily trumped the 6.2 of the EE.

The only official GFLOPS number came from Nintendo. IIRC it was ~ 13 GFLOPS total for the cpu + TnL. On PS2 since the TnL is done on the cpu side, it's fair to compare the 13 GFLOPS to the 6.2 for the EE since the GS is just a rasterizer and doesn't factor into the total GFLOPS rating.

 

[randycat99]

Isn't that where "reasonable" comparisons can get dicey? Comparing a hardware T&L number (presumably with every hardware feature running at once) with generic vector unit-derived T&L? It really straddles the line between the contributions of a hardware GPU (typically very high values) and that of general processor units. Does this really indicate that the GC is twice as powerful as the PS2 in use or are there other circumstances to consider? Would anyone venture to say that GC T&L is as much as 2x the power of Xbox T&L, then? Just my 2 cts.

 

[PC-Engine]

Well IMO comparing GFLOPS isn't really dicey. Most people on this board use it to derive TnL power so if you're comparing restrictly TnL performance it's a valid measurement IMO. IIRC there were some threads in here talking about the number of polys that can be transformed with a certain GFLOPS rating.

Anyone here know the math to calculate polygon transform rate using a GFLOPS rating?

Edit: Of course all of this is under the assumption that the numbers given out by SONY and Nintendo were not from their marketing departments

 

[Fafalada]

Geez, what happened to this thread, I went to sleep and...
Anyway

Marc,
I am pretty sure MGS2 frame buffers are 24bit. Dithering becomes most noticeable in low contrast, lots of gradient look without excessive pixel detail variations (which MGS2 pretty much fits Imo). And I haven't really noticed any signs of it. Coupled with 16bit Z you get to just over 2mb(640x448 buffers). Closer to 1.8 if they used half height front buffer (I think they do, not sure right now).

32MB's @ 60fps requires 32*60 = 1920 MB/s or about 160% of the available bandwidth.

True, but you'll be memory limited long before you could start sending 32mb down the bus. (assuming you're not sending the same texture over and over ).
Not to mention that kind of hypotetical situation would require all your textures to be "mip level 0" only, and all of them to be visible at the same time. Which would in effect imply that the result would look like pixelated mess, or you'd be using some odd 100 or so texture layers on every pixel.
Hypotethically speaking, of course

But since we're on subject of theory, let's push this all the way. Using entire memory for textures, at 60hz, your total texture pool would be 32mb + ~5/10mb assuming IPU running at its theoretical peak alongside, outputting 16/32bit texels.
At 30hz, the pool would be ~42mb with IPU@16bit, so we'd actually be able to stuff the entire texture pool down the GIF bus, as silly as the idea itself is. 8)

Don't forget that on the PS2, depending on how you use the textures and in what order, some textures will have to be sent across the bus several times...

As far as I'm concerned, cache trashing is indicative of poorly setup rendering engine. Realistically you should see very little to none of it if you do things properly, particularly with a predictable setup where you control everything like on PS2.
Also, multiple fetches of same texel blocks will happen on GC just as well if you aren't paying attention to your data flow.

Main RAM won't stay in one state for the whole second!

Assuming you don't pass through loading areas, it almost definately will. Dynamic loading from external devices is often not really applicable (depends on the game type) and even when it is, it's not a trivial matter to handle without compromising performance of the application.

 

[Zeross]

On page 3 :

Maybe that guy was talking about Flipper's HW T&L unit thinking that it was part of Gekko and adding Gekko's GFLOP's to the HW T&L units GFLOPS? Just a guess.

The only official GFLOPS number came from Nintendo. IIRC it was ~ 13 GFLOPS total for the cpu + TnL. On PS2 since the TnL is done on the cpu side, it's fair to compare the 13 GFLOPS to the 6.2 for the EE since the GS is just a rasterizer and doesn't factor into the total GFLOPS rating.

On page 2 :

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.

I'm feeling useless sometimes

 

[ERP]

Hey I wasn't suggesting that 1.2GB/s was a big limitation, I was just correcting someone elses numbers.

By enlarge I think the biggest problem on PS2 has been Sony's focus on high polygon counts, It's all they ever talk about in there developer presentrations, and I think it's filtered down to developers.

On all platforms developers have to make choices that basically tradeoff raw measurable performance (tri rates/fill rates) with image quality, on PS2 I think that those tradeoffs are more in the developers face, and they start earlier on the sliding scale. When the technical people are making decisions on how the engine will work it's much easier to justify 40% more polygons than it is to justify unknown improvements in image quality.

And no I'm not saying all PS2 developers fall into this trap.