Questions about PS2

[HTupolev]

So, it's like two passes?

A single pass to a framebuffer that's twice as large.

Due to the limited size of the GS eDRAM it's possible that they had to split the framebuffer into two pieces drawn separately, but from a graphics algorithm point of view I wouldn't call that "multiple passes."

 

[Shifty Geezer]

Is there a write-up of the tech they had?

Not that I know of. I was just a shameless Snowblind groupy and they had a great forum back in the day where the devs were pretty conversational, before their acquisition and destruction at the hands of Warner. And various blanks were filled in here by our resident PS2 devs before Warner acquired and destroyed them also. Assuming that's what's happened to Fafalada, DeanoC, nAo, et al.

Top BGDA nerd-fact - BGDA's engine was mostly the work of a single person, Ezra Dreisbach, and the team that made it was very small. Considering it's an early PS2 title and that machine was a complete pig to work with, I think that speaks volumes for Ezra's coding talent. He never went on to become a Carmack though.

 

[dogen]

Not that I know of. I was just a shameless Snowblind groupy and they had a great forum back in the day where the devs were pretty conversational, before their acquisition and destruction at the hands of Warner. And various blanks were filled in here by our resident PS2 devs before Warner acquired and destroyed them also. Assuming that's what's happened to Fafalada, DeanoC, nAo, et al.

Top BGDA nerd-fact - BGDA's engine was mostly the work of a single person, Ezra Dreisbach, and the team that made it was very small. Considering it's an early PS2 title and that machine was a complete pig to work with, I think that speaks volumes for Ezra's coding talent. He never went on to become a Carmack though.

Yeah, that guy was something else.

Did you ever see powerslave or quake on the Saturn? Those were super impressive, especially quake.

Due to the limited size of the GS eDRAM it's possible that they had to split the framebuffer into two pieces drawn separately, but from a graphics algorithm point of view I wouldn't call that "multiple passes."

Right. Iirc, Gregory over at pcsx2 said they do something like that. Makes sense considering the long-standing half screen bug with those games.

 

[Liandry]

It's just a larger buffer.

Ok.

A single pass to a framebuffer that's twice as large.

Due to the limited size of the GS eDRAM it's possible that they had to split the framebuffer into two pieces drawn separately, but from a graphics algorithm point of view I wouldn't call that "multiple passes."

I'm trying to understand. But what is he difference between two pieces drawn separately and two passes? From bandwith perspective it's the same.

 

[Shifty Geezer]

Multipass rendering draws over the same pixels multiple times. Assmbling separate pieces is something else. Tile based rendering chops the whole screen up into lots of pieces (or two, in the case of XB360). You'll see GPUs that do this, and render each tile in one pass using shaders. PS2's SSAA is just rendering a large, single buffer (maybe split into two tiles) and downsizing it.

 

[Liandry]

Multipass rendering draws over the same pixels multiple times. Assmbling separate pieces is something else. Tile based rendering chops the whole screen up into lots of pieces (or two, in the case of XB360). You'll see GPUs that do this, and render each tile in one pass using shaders. PS2's SSAA is just rendering a large, single buffer (maybe split into two tiles) and downsizing it.

Yes, but for multipass you should so read/write to EDRAM for each pass, and framebyffer split for two tiles you aslo shoul do read/write for each tile.

 

[Shifty Geezer]

Multipass = read/write several times over framebuffer.
Multitiled = read/write several times over each tile using multipass rendering because that's what PS2 does.

If BGDA is using a split framebuffer, it'll be using multipass rendering on each half of it prior to combining the tiles into the final image.

 

[Liandry]

Multipass = read/write several times over framebuffer.
Multitiled = read/write several times over each tile using multipass rendering because that's what PS2 does.

Then it's like read/write for each pass, then read/write for each tile, and then again for next frame.

If BGDA is using a split framebuffer, it'll be using multipass rendering on each half of it prior to combining the tiles into the final image.

So if they use, let's say 10 passes, it will be 10 passes for each tile, and it's 20 total?

 

[Shifty Geezer]

Yes. But don't think about it being tiles, as that's irrelevant and unconfirmed. Think of it as pixels. If a screen is 640x480, 307,200 pixels, then 10 passes would be 3 million pixels in a frame. At 2xSSAA, BGDA rendered something like 900x680, 600,000 pixels. 10 passes then would be 6 million pixels drawn. But as others have pointed out, these pixels are very often overdraw rather than passes, so drawing lots of overlapping particles draws lots of pixels as well. You might draw 1.5 million pixels as complete passes, and another million per frame as overlapping fog particles (totally random figure, no idea what overdraw counts were like. But 1000 30x30 particles isn't bonkers)

 

[Liandry]

Yes. But don't think about it being tiles, as that's irrelevant and unconfirmed. Think of it as pixels. If a screen is 640x480, 307,200 pixels, then 10 passes would be 3 million pixels in a frame. At 2xSSAA, BGDA rendered something like 900x680, 600,000 pixels. 10 passes then would be 6 million pixels drawn. But as others have pointed out, these pixels are very often overdraw rather than passes, so drawing lots of overlapping particles draws lots of pixels as well. You might draw 1.5 million pixels as complete passes, and another million per frame as overlapping fog particles (totally random figure, no idea what overdraw counts were like. But 1000 30x30 particles isn't bonkers)

WOW! That's great explanation! Thank you a lot. Also have one question. Why there is so wide memory bus in GS, I just do't see any reason for that. Let's take as an example game what runs in 640x480, with 2xSSAA, 10 passes, 60 FPS, then it will be 368640000 pixes, which is a litle bit more than 25% of GS fillrate. And if i'ts 32 bit per pixel hen its only aroun 1,4 Gb of data. EDRAM have 48 GB/s. Maybe I'm wrong. Corect me if it's needed.

 

[HTupolev]

It's not 32 bits per access. You're forgetting depth, plus reading in the existing depth and color for blending.

 

[Liandry]

So it's more than 32 bits or less?

 

[Exophase]

WOW! That's great explanation! Thank you a lot. Also have one question. Why there is so wide memory bus in GS, I just do't see any reason for that. Let's take as an example game what runs in 640x480, with 2xSSAA, 10 passes, 60 FPS, then it will be 368640000 pixes, which is a litle bit more than 25% of GS fillrate. And if i'ts 32 bit per pixel hen its only aroun 1,4 Gb of data. EDRAM have 48 GB/s. Maybe I'm wrong. Corect me if it's needed.

It's sized to fit the pixel pipelines.

There are 16 pixel pipelines. Each can read 32-bit color + 32-bit depth and write 32-bit color + 32-bit depth. That's 1024-bits of read and 1024-bits of write.

Then the 512-bit texel access. That reads 16 32-bit texels. You may ask why it needs to read so many when only 8 of the pipelines are available with texturing. With bilinear filtering 4 texels actually need to be read for each pixel. But there tends to be a lot of overlap there. So it probably reads a block (4x4? 8x2?) of texels which usually covers the area the pipelines need.

Technically, the interface to eDRAM is actually 8192-bits per cycle, and the 1024-bit read, 1024-bit write, and 512-bit texture buses are facilitated through small (probably SRAM) buffers (maybe caches). This means that the eDRAM itself actually only has one bus. The buffers are needed to create multiple buses, hide DRAM latency, and smooth out extra accesses needed for things like refresh if necessary.

 

[Liandry]

There are 16 pixel pipelines. Each can read 32-bit color + 32-bit depth and write 32-bit color + 32-bit depth. That's 1024-bits of read and 1024-bits of write.

Never heard about it. But it's sounds awesome, just want to know why there is need for 1024-bit buses if only 8 pipelines can do texturing. Or all 16 can be used in pixel work?

Then the 512-bit texel access. That reads 16 32-bit texels. You may ask why it needs to read so many when only 8 of the pipelines are available with texturing.

That's true. Why it needs to reed so many, because only 8 pipelines are used for texturing.

With bilinear filtering 4 texels actually need to be read for each pixel. But there tends to be a lot of overlap there. So it probably reads a block (4x4? 8x2?) of texels which usually covers the area the pipelines need.

Also don't understand how 512-bit bus is enough if there is 4 texels per pixel?

Technically, the interface to eDRAM is actually 8192-bits per cycle

There did that number came from?

buses are facilitated through small (probably SRAM) buffers (maybe caches).

Caches also is on GS chip?

This means that the eDRAM itself actually only has one bus.

Why?

The buffers are needed to create multiple buses, hide DRAM latency, and smooth out extra accesses needed for things like refresh if necessary.

Refresh what?
Yeah, I know a lot of questions. But maybe you can give answers. Thanks also for your post!

 

[dogen]

Yes. But don't think about it being tiles, as that's irrelevant and unconfirmed. Think of it as pixels. If a screen is 640x480, 307,200 pixels, then 10 passes would be 3 million pixels in a frame. At 2xSSAA, BGDA rendered something like 900x680, 600,000 pixels. 10 passes then would be 6 million pixels drawn.

I remember reading that it actually renders to 1280x1024(or similar) buffer. So, 2x2 SSAA I guess.

 

[Shifty Geezer]

That'd be 4x SSAA.

 

[Liandry]

More questions, still want to get answers for previous.
1) How GS can read from EDRAM 9,6Gb/s texture data if it already read 19,2 Gb/s frame buffer data but it write to EDRAM 19,2 Gb/s frame buffer data? How texture data is written to EDRAM? Is EDRAM's texture bus is read/write? I thought it's only read.
2) GS have 1,2 GTexel fillrate, but if for 1 pixel you need 4 texels, does it mean what there is only maximum can be 300 MPixels? Which is 4 passes, because GS have only 1,2 GPixel fillrate. So if there is as an example 10 passes, each pass will be 120 MPixels and there shoul be 480 MTexels then? Please explain someone.

 

[Shifty Geezer]

You're still not really following the process. A pass is one screen's worth of pixels, so 300,000 pixels. Not 120 MPixels!

 

[Liandry]

Yes, my mistake. I mean if there is 1,2 Gtexel fillrate, then it's possible to make only 300 MPixels. And for 30 fps game it will be 10 MPixels per frame. Is this right calculation?

 

[Grall]

Can it be VU0, because VU1 calculates polygons?

VU1 calculates anything you like. It's a stand-alone CPU basically (if set to operate independently from EE), with some limitations IIRC like it couldn't access main RAM directly, you had to DMA into its own local memory, and may have had some gaps in its instruction set making it not ideally suited for general purpose processing. Its relatively small local memory would be a hindrance there for example, you'd have to page code in and out heavily.

I seem to remember it was fairly well-rounded overall as a processor though; Ars Technica posted a big technical exposé on the chip years and years ago now; should still be googleable if anyone's interested. Beyond vector fixed/float math, it could do boolean stuff and bit operations and such also I seem to recall. For absolute certainty you'd have to check docs, or an old dusty PS2 programmer... )

It's worth noting that around the time of PS2's unveiling, Sony PR dropped fake rumors in the media that PS2 would be embargoed from export to Iraq, because the console was supposedly so powerful that NATO was concerned Saddam Hussein was attempting to modify them into image processing/recognition systems for homegrown cruise missiles.

This was all completely fake news from what I understand, and just created to make PS2's chipset seem really powerful in the eyes of the ignorant public. In any case, you could absolutely run image processing on the vector units rather than calculate polygons. The vector units run software; they're not hard-coded for specific tasks. You can replace the software with anything you like (as long as it fits in RAM... )