Questions about PS2

The actual devs will be able to give you a more detailed explantion, but not only can you do that on ps2, but you pretty much must, if you want to use the most of it.
Yet, that's not multipass. It's just memory management.
Multipass is when you draw more than a single texture on the same poly. Think: Detail mapping, where a tiled high-frequency texture is overlayed on top of a larger low frequency one, or think lightmapping on quake, where you have the diffuse texture overlayed by the lightmap, or think of a terrain renderer, where a tiled grass texture transitions to another tiled dirt texture based on vertex weights. To achieve those effects, you either need your rasterizer to be able to use more than one texture at once, which ps2 can't, or you need to draw multiple polys on top of each other for every new texture you might need. What has been clarified here, is that ps2's architecture gives devs room to do that eficiently, avoiding redundant transforms. But it's all up to the dev to devise and implement.

 

Geometry is stored in main memory and chunks dma'ed into VU (1 usually) memory for transformation. Upload (and sometimes downloads) from EDRAM had several paths, the best being DMA, throughout a frame, a lot of textures would be sent up to EDRAM.
In a PS2 the DMA unit was effectively the CP (Control Processor), you built the DMA list to move the geometry and 'shader' program to VU, whilst textures were uploaded, so that when the GS did its thing, all the data was where it should be. DMA programming was the most vital part of a PS2 renderer and we often built quite powerful tools to help us find/fix bugs.

 

Geometry is not stored in GS ram. It's stored in main memory. GS is only pixels. Geometry data lives in main mem, passes through VU to get animated and ends up as triangular splats of pixels in GS mem. Data flow is one-way. Main mem -> VU mem -> GS mem -> TV. Reading back data from the GS to anywhere else is very rare. Like, you could that for screen shots or maybe primitive GPGPU. But, that's it.

You bring up an important issue that I left out. 4 mb is not a lot of space. After the front, back and z buffers, there's not much room for textures in there. So, the EE would need to coordinate DMAing textures into GS ram at the same time that it was piping geometry through the VU. When I said the GS could switch textures in a couple of cycles, I was talking about textures that are already in GS ram. Getting the textures there takes a bit of time. But, if all of the texture you need for an object are already there, switching between them is trivial. I don't remember what the DMA bandwidth for textures from main mem -> GS mem was. But, it was pretty high. So, you could cycle a lot of textures through the GS EDRAM every frame.

"Multipass" means rasterizing the same triangles multiple times. Early hardware could barely do anything in a single pass. So, we had to do multipass a lot. These days hardware can do a huge amount in a single pass. So, multiple passes are rarely needed any more.

The VU1 only has 16k of RAM for code, incoming data from the EE, working set data and outgoing data to the GS. That's not a lot. So, you might only have 2k of room to place outgoing transformed polys going to the GS. However, once you've done the transform work and formatted it for DMA to the GS, it's pretty trivial to go back over that pre-formatted buffer and tweak it to send it a second time. So, you could keep the positions the same and modify the UVs for a second pass with a different texture super-cheap.

Drawing a single model will probably require more that 2kbytes of polys. So, it would require drawing the model in lots of little chunks. But, each chunk only needs to be transformed once and it's triangles can be rasterized multiple times if the model wants to use multiple textures. You don't need to push the whole scene through the VU multiple times.

 

EDRAM is GS's working memory. It reads from it for texturing and Z-tests when rasterizing polys, and the results from that are written into it. How much of that memory is used for each thing, in what formats, and how many times data from it is shuffled around is up to the dev.

 

Technically there's another 16KB of memory for code, right? So-labeled "micro mem."

 

You are correct.

 

Yes. When I said "splats" I was just being clear about the triangles being pixels in the framebuffer --as opposed to being verts and indices.

I know there was a read-back path because we used it to save screen shots.

While working on a image post-processing system for the PS2, at one point I had this effect sorta running on the GS just as a fun experiment. Here's a modern equivalent. Not a good idea in reality because the numeric precision was so bad. As I said, very primitive.

Yep

Yep

Yep. No problem.

 

Sonys biggest mistake with the PS2 was not getting the tools right before launch. Or indeed any reasonable time after that. If at all.
There was no real incentive to push the hardware because everything would sell reasonably well because of the insanely big user base. Everyone "knew" what it could do so a false floor or level of normal was created. Thus the machine was hardly ever pushed. Even the games that did dare to push the envelope hardly scratched the surface, being content to do a few things right and mostly be mediocre games otherwise.

The EE had an on-die macro block decompressor with insanely high throughput, much higher than would have been ever needed for playing a DVD. The intent was of course to decompress textures for games on the fly.
No one to my knowledge ever utilized that feature. With MIP mapping and decent culling the texture throughput per frame would never need to go above a few megabytes, when the frame itself was only one megabyte. Most likely it should have been less had 16 bit textures been used.
Huffman decompression was done by the CPU and VU´s for textures but why use precious time for that, when there is much better hardware with higher compression sitting right there?!

Geometry on the PS2 was meant to be synthesized. That much is clear from what Kutaragi said early on before release. The geometry was meant to be largely dynamic, instanced and generated on the fly. If that had been done more throughly PS2 games would have looked a hell of a lot better.
The MIP level could have been set for inclined surfaces or whole objects with approximately the same surface inclination towards the screen to avoid shimmer. Culling could have been done more effectively, and the triangles could have been generated to the right size to avoid thrashing the cache if too small and have texture jumping if too large, etc.

Doing stuff like that of course would have meant that the game would have been harder to port to other less advanced platforms. But who cares if the install base is so large?!
The real answer is I suppose that the computer industry is the most conservative, stiff and dogmatic of all the branches of engineering when it comes down to it. Double up for game programmers.

 

Lazy devs.

 

Lazy devs.

 

No, overworked frightened devs. And sometimes also fanboy devs (surprisingly often).

 

In real life you have to probably halve that number. But that is still more than enough for a buffer of 1 megabyte.
Most games just fills up the buffer with the main set of large textures (character, ground. etc.) and only changes a few texture during rending. leaving much of the bandwidth wasted (actually huge bandwidth considering frame buffer was on die).

 

If true thats kinda crazy and sad at the same time

 

I already did. You are correct but for real world use you have to take the throughput down a notch. halving it is not too pessimistic. But 8 Mb is still more than enough for one frame. Texels should preferably be kept larger than pixel size to not get fighting. But that's what MIP mapping is for.
And of course they used multipass in all the Jak games. That's the only way to achieve the effects seen in those games.