Standard PS2 framebuffer size?

[Zeross]

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

Oh this is something I wanted to ask, so frame buffers and the Zbuffer on the GS don't have to be the same depth ? I was just wondering because I think that on an Nvidia card you can not dissociate the two : 32 bit color depth mean 32 bit ZBuffer and there is no way to force 32 bit rendering with a 16 bit ZBuffer (while it was possible on G400 i think).

Another question there isn't a stencil buffer on the GS, is there ? I know you can emulate stencil buffer easily but why didn't Sony include a stencil buffer feature directly ? I mean there is a 24bit ZBuffer mode on the GS with 8bit unused it would have been smarter to use these bits for stenciling, like Nvidia does.

 

[Squeak]

And automatic CLUT is possible, of course, however it would look easily several times worse than automatic S3TC.

I can’t imagine why that should be. Isn’t S3TC after all basically just 2 bit CLUT in 4*4 squares?
My guess would be that the quality would be better because you could customise the compression to the texture.

 

[Thowllly]

Oh this is something I wanted to ask, so frame buffers and the Zbuffer on the GS don't have to be the same depth ? I was just wondering because I think that on an Nvidia card you can not dissociate the two : 32 bit color depth mean 32 bit ZBuffer and there is no way to force 32 bit rendering with a 16 bit ZBuffer (while it was possible on G400 i think).

I know you didn't ask me, but yes; the frame buffer and the Z buffer does not have to be the same depth.

Another question there isn't a stencil buffer on the GS, is there ? I know you can emulate stencil buffer easily but why didn't Sony include a stencil buffer feature directly ? I mean there is a 24bit ZBuffer mode on the GS with 8bit unused it would have been smarter to use these bits for stenciling, like Nvidia does.

Would have cost more transistors to implement. The last 8 bit doesn't get wasted; you can use them to store 8 or 4 bit textures. (The GS has extra texture modes for just that purpose)

 

[Zeross]

I know you didn't ask me, but yes; the frame buffer and the Z buffer does not have to be the same depth.

Would have cost more transistors to implement. The last 8 bit doesn't get wasted; you can use them to store 8 or 4 bit textures. (The GS has extra texture modes for just that purpose)

Thanks
when I was looking for that info I found this :

To use the pixel storage format for the frame buffer and the Z value storage format for the Z Buffer in combination, both the formats must belong to the same group.

Group1 : PSMCT32, PSMCT24, PSMCT16S, PSMZ32, PSMZ24, PSMZ16S

Group2 : PSMCT16, PSMZ16

Didn't know that GS used special addressing mode not to lose space using 24 bit format though.

All of this came from a discussion with a friend who was arguing that the PS2 with it's incredible fill rate (especially with no texture) a powerful vertex engine (ability to generate the shadow volume with VU instead of using the CPU) and an on chip ZBuffer was really the most suited console for Volumetric Shadows using stencil buffer (with a 2.4Gpixel/s fillrate shadow volumes passes could be really fast). Theorically speaking his reasoning seems good but if it's true why aren't more games (at least one !) using these kind of shadows on the PS2 if the hardware is there.

 

[marconelly!]

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

Faf, it could be that it's 24 bit. Now that I think about it, it does look way better than those dithered to hell 16 bit games of old and the dithering is very rarely visible and precisely only in the lowest contrast situations.

Here's what it says on the MGS2 doc disk:

Frame buffer: 2MB (1MB x double buffer)
Z-Buffer: 1MB
Texture cache: 1MB

So that would mean Z buffer is also 24 bit, then? Also, I assume that by 'double buffer' they mean front + back buffer, correct?

Theorically speaking his reasoning seems good but if it's true why aren't more games (at least one !) using these kind of shadows on the PS2 if the hardware is there.

Shadow volumes are tricky method to implement properly from what I understand. Silent Hill 3 definitely uses them, and apparently Faf's racer too

 

[Fafalada]

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

I know, I just needed an excuse to blab about the other numbers.

Anyway, I tend to agree with the rest of your assesment. Early on everyone was somewhat bombarded with polygon talk (I've listened to my share of it too, remember what I told you about our initial car polycounts) and you know how hard it is to do any design changes in limited amount of time.
Coupled with various other early misconceptions, the results seen in many games were kinda predictable.

Zeross,
buffer format mixing doesn't stop there either, you can have frame/texture in Z formats too
Anyway, stencil or alpha channel combiner logic separate from RGB channels would still come handy - why it isn't there only GS designers could answer exactly.
As for volumes, titles with their global/large scale application in shadow rendering have been practically non existant regardless of platform so far - most of them are yet to come out (Halo2, D3, SilentHill3 etc.).
Much as it's easy to whip up a tech demo with shadow volumes, large scale use is a much more complex problem that didn't even have viable solutions on older hw.
But to answer your question, I'd agree with your friend, PS2 is extremely efficient with volume rendering in my experience

Marc, yeah, double buffer would be that. They probably also include effect buffers in there.

 

[Squeak]

I know this has nothing to do with the current topic in this tread, but I thought it would be a little excessive to start a new one, just for one simple (maybe) question.

Today I had my first go on Starfox ADV. and it really is a strikingly beautiful and technically accomplished game, however the one specific effect that impressed me the most was the grass.
IMO this replaces Halos grass as the best looking ever in a videogame. How did they do it?
Now I know that the Fox model has furshading, that from what I understand involves layering multiple textures with a little space between then, like an onion, until you have 3d fur.
But I don’t believe the same technique could be applied to large fields of grass, wouldn’t that completely kill fillrate? The other thing is that it doesn’t look multilayered, even when you in some places encounter longer straws of grass (done with the same technique) they look completely solid although a bit aliased. I have seen a very similar technique used in that Pirates game on PS2, although not done to anything near the same extent, that further enhances my theory that the grass isn’t done with "furshading" as the PS2 doesn’t like to many texture layers, but then how is it done? Any ideas?

 

[marconelly!]

They probably also include effect buffers in there.

Hmm, how big are the effect buffers? What and how are they used for, exactly?

 

[Grall]

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?

Teasy,

You have the PS2 architecture somewhat confused it seems. The system isn't arranged sequentially with the RDRAM in one end and the GS in the other like you drew in ascii on page 2. The bus to the GS is *separate* from the main memory interface. The memory bus actually terminates at the 10-channel DMA controller, from then on it's the EE's internal 128-bit, 150MHz bus that takes over. The different "paths" one hears about are just different inputs to that *separate* bus. It doesn't mean there's actually 3x1.2GB/s accessible to the GS, because there isn't. One path is from RDRAM, another's from one of the vector units' dedicated memory I believe. The last I can't remember, either Faf will say in a reply, or you can go look it up in Ars Technica's blackpaper on the PS2...

Point is, the EE can generate vertex data and send that straight to the GS for rendering, this does not consume any main memory bandwidth, unless the EE needs to touch memory to read polygon models, level data or such for transformation of course. Suppose you're generating all your data dynamically on-chip on VU1 using the dedicated path to the GS, then you'd have an equivalent aggregate b/w of 4.4GB/s, with 3.2GB RDRAM bandwidth left for the CPU/FPU and VU0.

Okay, if I screwed up explaining this, I'd prefer if you'd shoot me gently please.


*G*

 

[Tagrineth]

I know this has nothing to do with the current topic in this tread, but I thought it would be a little excessive to start a new one, just for one simple (maybe) question.

Today I had my first go on Starfox ADV. and it really is a strikingly beautiful and technically accomplished game, however the one specific effect that impressed me the most was the grass.
IMO this replaces Halos grass as the best looking ever in a videogame. How did they do it?
Now I know that the Fox model has furshading, that from what I understand involves layering multiple textures with a little space between then, like an onion, until you have 3d fur.
But I don’t believe the same technique could be applied to large fields of grass, wouldn’t that completely kill fillrate? The other thing is that it doesn’t look multilayered, even when you in some places encounter longer straws of grass (done with the same technique) they look completely solid although a bit aliased. I have seen a very similar technique used in that Pirates game on PS2, although not done to anything near the same extent, that further enhances my theory that the grass isn’t done with "furshading" as the PS2 doesn’t like to many texture layers, but then how is it done? Any ideas?

Pull out the hi-def scanner and zoom in on some grass.

It's basically exactly the same technique - in fact, you're right, the fill-rate does drop dramatically... doing that, you get more slowdown than anywhere else in the entire game!

 

[archie4oz]

The bus to the GS is *separate* from the main memory interface. The memory bus actually terminates at the 10-channel DMA controller, from then on it's the EE's internal 128-bit, 150MHz bus that takes over.

One minor little quibble... The memory bus technically terminates at the memory controller (which is a client on the main bus). The DMA controller is basically another client that can read and write to and from various devices on that bus (SIF, GIF, VIFs, IPU, SPR). Think of it as a pigeon-hole stuffer...

 

[Fafalada]

Hmm, how big are the effect buffers?

There's no standard size you could attribute to that, it's entirely up to each individiual application. In some cases there may even not be any at all, as well as they may be massive in other cases.
Also, the good thing is that many effects can have their buffers time shared with other "main buffers" you allocated for texture/frame etc. For example, some effect may be drawn towards end of the frame, without the need for any texture data so it perhaps use the transient texture buffer when it starts to draw.

What and how are they used for, exactly?

Er, this could be a potentially endless answer - it's really up to the imagination of the user what you'll do.
But for some obvious uses, offscreen reflection rendering, dynamic offscreen shadow/light map generation, stencil buffer, various accumulation buffers etc.

Grall,
nicely summed up. All I'd add is the importance of several inputs - the point is your different data inputs don't need to stall one another as they do if you only use one path (which is the easy way out that most people used to date).

Speaking of memory layout, ARam (afaik at least) connects directly to DSP, other units don't have direct access to it. GPU-CPU aren't serially connected to the memory either. Memory controller is on Flipper, and it serves both GP and CPU parts with separate paths.

Squeak,
I haven't played SFA, so I couldn't say anything about the grass in there. However, the fur 'shader' breaks down when rendering longer hair, so unless it's short grass it probably wouldn't work too well.
Just a note though - while it's fillrate heavy, the shader uses concentric geometry layers so you're rendering a lot of polys, not texture layers.

 

[Teasy]

Grall

I think you might have mis-understood my comments and little crappy diagram Unless I just mis-understood you of course.

Because what you seem to be describing it what, roughly, I already said. I know that the bus from the EE to the GS is seperate from the main memory bus. I was just saying that if it was required to send 1.2gb of data from main memory to the GS it would not only use up the bandwidth of the EE to GS bus but also 1.2gb of the bandwidth of the main mem to EE bus. I also know that the EE could generate data and send it straight to the GS without neccesarilly needing to touch the main memory bandwidth. My diagram was extremely rough, but from what I know and what you just said it does seem to be correct in a basic way. Perhaps I just wasn't being clear with the diagram. I'll be more clear to stop any possible confusion.

Legend:

---------- = 3.2gb/s Main mem bus
............ = 1.2gb/s EE to GS bus

PS2 diag:

32 mb main memory----------EE............GS

BTW, on path three. So this doesn't actually give extra bandwidth? Its basically a single 1.2gb/s bus to GS but with multiple inputs from different parts of EE?

Thanks for trying to help and I await your reply if I've completely mis-understood your post.

 

[andypski]

And automatic CLUT is possible, of course, however it would look easily several times worse than automatic S3TC.

I can’t imagine why that should be. Isn’t S3TC after all basically just 2 bit CLUT in 4*4 squares?
My guess would be that the quality would be better because you could customise the compression to the texture.

Your guess would be wrong.

S3TC almost always looks better than 8 bit CLUT textures - the key is spatial coherency. Having 256 colours to distribute over a large image is not a good solution because over the whole image there is typically a large variation of colour. S3TC takes advantage of the fact that within small blocks of an image colours tend to be closely correlated. The larger the texture becomes the more S3TC tends to be better than 8-bit CLUT.

In addition to looking better it also gets twice as much compression, which is a bonus.

 

[Squeak]

And automatic CLUT is possible, of course, however it would look easily several times worse than automatic S3TC.

I can’t imagine why that should be. Isn’t S3TC after all basically just 2 bit CLUT in 4*4 squares?
My guess would be that the quality would be better because you could customise the compression to the texture.

Your guess would be wrong.

S3TC almost always looks better than 8 bit CLUT textures - the key is spatial coherency. Having 256 colours to distribute over a large image is not a good solution because over the whole image there is typically a large variation of colour. S3TC takes advantage of the fact that within small blocks of an image colours tend to be closely correlated. The larger the texture becomes the more S3TC tends to be better than 8-bit CLUT.

In addition to looking better it also gets twice as much compression, which is a bonus.

As far as I’m aware, nothing stops you from breaking PS2 textures up into smaller chunks, that could be 4-bit CLUT (I seem to remember that 4-bit is the lowest the PS2 can go, so you wouldn’t get quite the compression of S3TC, but then you could save elsewhere, by varying the size of the blocks or even cutting the texture with subdivision, where it has natural colour boundaries to avoid that blocky 'compression look').
In fact, I’ve read, that to get the best results from the GS, you have to break textures up, to avoid thrashing in the 8kb pixel-unit texture buffer.

 

[andypski]

As far as I’m aware, nothing stops you from breaking PS2 textures up into smaller chunks, that could be 4-bit CLUT

To break the textures up you will need to reorganise your meshes - you obviously now can't just apply a single texture over the model, but have to retesselate the geometry along the appropriate texture boundaries. Since you also now cannot perform texel interpolation across the boundaries there is some inter-dependence of content between the texture sections (basically you will need to be careful to avoid noticeable seams).

To achieve roughly equivalent quality in the general case you could split the texture down to 8x8 blocks each with its own palette (actually this would somewhat exceed the quality of S3TC overall because all the palette entries can be unique, rather than derived implicitly from endpoints). Of course the compression in real terms (storage footprint) is not strictly equivalent because an 8x8 region of a S3TC texture is 256 bits, and the palettised version is 768 bits (including the palette). We can reasonably discount the palette storage from a rendering point of view since it is stored on-chip instead of in memory, so it only has an effect in that it needs to be transferred over to the chip.

(Note that while we can ignore this from the rendering standpoint it is still worth consideration that this implies that you could be transferring up to 3X the amount of total data over the bus when texturing using this method).

You do make a good point that you could save unnecessary splits with an intelligent routine that adaptively subdivides the texture to get good quality compression. How much splitting this would save on real textures would need to be a subject for intensive study, for which I unfortunately do not have the time (it would be an interesting project)

The main issues as I see them are with ease of use, and possible losses of rendering efficiency. On many architectures it would be significantly less efficient to break the geometry down to small batches to accommodate this sort of intensive texture decimation. With PS2 this may not be the case - I don't know how far you can take micro-management of the rendering environment before it seriously impacts your overall system performance. I would, however, have thought that the performance characteristics of this sort of solution would be rather unpredictable (seemingly being some function of the number of pixels rendered at any time with each texture sub-image).

By contrast using a single DXTC compressed texture should have relatively predictable performance, and always be pretty efficient except in pathological cases.

Cheers
- Andy.

 

[Laa-Yosh]

As far as I’m aware, nothing stops you from breaking PS2 textures up into smaller chunks, that could be 4-bit CLUT (I seem to remember that 4-bit is the lowest the PS2 can go, so you wouldn’t get quite the compression of S3TC, but then you could save elsewhere, by varying the size of the blocks or even cutting the texture with subdivision, where it has natural colour boundaries to avoid that blocky 'compression look').
In fact, I’ve read, that to get the best results from the GS, you have to break textures up, to avoid thrashing in the 8kb pixel-unit texture buffer.

Any art department would make their programmer collegues disappear incredibly fast for doing that. I mean gone without a trace.

 

[Fafalada]

S3TC is 8bit/texel too when you want alpha
8bit Clut doesn't start visibly breaking down until sizes over 256, and then it still takes specific image types (gradient heavy photo images usually do the trick).
Anyway, I have my own opinions in regards to use of photographic material in texture work, but this comes down to opinions alone, so I won't debate it.

To break the textures up you will need to reorganise your meshes - you obviously now can't just apply a single texture over the model

The artists I've worked with tend to like using multiple textures per model regardless, even at some points where Imo they wouldn't need to. Though I would guess this depends on people's background, as well as tools they mostly used. But still, I'd say stuff like wrapping up entire character in one texture is just very oldschool way of doing things.

Not that I agree with idea of breaking textures down as small as suggested in above post though that's pushing it.
The 8x8 blocks would both reduce performance, overcomplicate implementation and the only result would be 50% MORE memory use and marginally improved texture quality.
I'd say as far as tradeoffs go, that one is very bad
But, if you consider it worth to sacrifice performance for texture compression, it's possible to decompress actual S3TC aboard GS. It takes some 3 passes or so, but that's all there is to it. And it actually saves memory.

Speaking of splitting things, I do know some developers are forcing page buffer size on the texture artists. (mainly as means to improve rendering performance) Though that's still big enough dimensions in 4/8bit to be manageable by hand.

 

[andypski]

S3TC is 8bit/texel too when you want alpha

Yes, but that's with independent alpha.

If you have an 8-bit CLUT with 32 bit palette entries (including alpha in the palette) the compression quality will generally suffer because of the connection of alpha with colour - you may need to duplicate entries with the same colour to support different levels of transparency. Not a very good solution.

8bit Clut doesn't start visibly breaking down until sizes over 256, and then it still takes specific image types (gradient heavy photo images usually do the trick).

We could certainly debate this extensively, but then it is a tricky subject, and too complex for quick evaluation. S3TC was designed in order to provide generally better image quality than palettised textures in half the storage space, while also being superior from a hardware implementation point of view. There are types of images that will still compress visually better with CLUT, but they are relatively rare.

The artists I've worked with tend to like using multiple textures per model regardless, even at some points where Imo they wouldn't need to. Though I would guess this depends on people's background, as well as tools they mostly used. But still, I'd say stuff like wrapping up entire character in one texture is just very oldschool way of doing things.

I agree - I was using a very simple example to ease the explanation.

Not that I agree with idea of breaking textures down as small as suggested in above post though that's pushing it.
The 8x8 blocks would both reduce performance, overcomplicate implementation and the only result would be 50% MORE memory use and marginally improved texture quality.
I'd say as far as tradeoffs go, that one is very bad

Yes - and that's the point. Although it is possible to achieve the same quality as S3TC with 4bit CLUT textures it would seem to be a poor application of effort. A better solution would probably be to use 8 bit CLUT and just work around natural sub-divisions in the model, since by limiting the area of the model that is represented by the texture you will generally cut down on the amount of the colourspace you have to represent. Working within the limitations of the format, and designing the content appropriately around those limitations, will probably produce better results than jumping through hoops trying to emulate a capability that's not directly supported.

[edit] - typo

 

[Fafalada]

If you have an 8-bit CLUT with 32 bit palette entries (including alpha in the palette) the compression quality will generally suffer because of the connection of alpha with colour - you may need to duplicate entries with the same colour to support different levels of transparency.

I agree, and this isn't a very common texture use anyhow. Multibit alpha mostly comes handy for certain specific texture types where you need almost no color and practically all alpha.

S3TC was designed in order to provide generally better image quality than palettised textures in half the storage space, while also being superior from a hardware implementation point of view.

Well, imo the quality is mostly determined by the size factor. If 8bit Clut quality could be had at 4bits/texel, I'd gladly take that and would never miss any other compression at all. But as things are, you're often faced with decision of resolution vs. degraded 4bit look - if PS2 games used 8bit exclusively, there would have never been a texture color argument to begin with. But as things are, 4bit is prevalent in many games.

A very good example of that is DC. 2x2VQ has more quantization artifacts then either 8bit Clut or S3TC, but it still looks comparable enough, and comes at 2bits/texel, giving you a rather nice size/quality ratio.

Working within the limitations of the format, and designing the content appropriately around those limitations, will probably produce better results than jumping through hoops trying to emulate a capability that's not directly supported.

Well, as I've said there are methods of 'emulating' other formats that don't require as drastic approaches. Obviously they still aren't free though, and what would actually be usefull may depend on application.
But considering few apps choose to even utilize IPU decompressor which tends to be quite usefull, it's hard to expect you'd see people embracing alternative methods quickly either.