Re: [AD] Porting Allegro to the PS2

[Joshua Walker <halkun@xxxxxxxxxx>]

> > So a typical chain is CPU -> VU1 -> VU2 -> VIF -> GIF -> GS
>
>
> Hmm, I didn't actually do graphics programming on the PS2, but I
> thought VU2 did not have access to the GS and VU1 not have
> access to VU2.
Oops they are called VU0 and VU1...
actuallay all the computing devices: CPU, VU0, VU1, and the IPU (texture 
mananager) have a VIF so they can talk directly to the GS. The chain I 
doscribed above is *usally* how a polygon gets renderd. CPU makes a 
polygon request, VU1 put the ploygon packet togeather, VU2 does the 
matrix stuff and shadeing, VIF puts it into the GS Queue. The GIF grabs 
it from the queue and "kicks" it to the GS for clipping and display 
(automatic) The VUx units are little 300mhz Microcomputers themselves 
with 16k for VU0 and 64k for VU1. (They have no direct access to main 
RAM, the CPU has to push data to it to "load" them) after that they are 
pretty automatic. The CPU can intervene in the VU0 via a coprosser 
command, but the VU1 runs pretty much all by itself unless VU0 tells it 
to stop. To load VU1 you *have* to put go CPU -> VU0 -> VU1 and it 
doesn't work backwards. The only output VU1 has is the VIF that goes to 
the GS.

> Still, none of that will be very useful for Allegro.  I'd
> investigate the possibility of providing Allegro with a
> framebuffer in system RAM and uploading that as a texture every
> frame -- IIRC the PS2 has very good DMA speeds... on our PS2
> project we were swapping all of our textures (10-15Mb I think)
> in and out at 30fps.  This also allows easy reading from the
> screen, since it's just a virtual framebuffer in system memory.

There is a device called the IPU that's resonable to texture management. 
But the problem is that I can't use the GS to write to textures in 
system ram. I will have to use software woutines to draw plygons then 
use the IPU to pipe the video data to the GS. I can't use the GS to make 
plygons anymore. GS is a one-way street, It can't write the normal 
system ram and the only way to get info out of the GS is to ask to see 
if a particular pixel is in a particular coordindnate in the vewable 
window. Here's a little issue. The in the GS's video memory, you can set 
up mutiple colordepths at the *same time* (For example 70% of the 
textures in the spiderman videogame used 4-bit textures, but each 
texture had a 24-bit color look up table. I can display with the GS a 
32bit (24 bit color-8 bit alpha) picture on the same screen with the 8 
bit textures without raising/dropping the colordeph. I also can rotate 
the palette on the 8 bit texture without messing up any other 8 bit 
textures, unless they are using the same Color Lookup Table. (I guss you 
can assume the video memory is 1024x1024x32bpp, but you will start 
loseing video resolution the more 32bpp textures you feed it. The 
ability to use mutiple 8 bit textures with diffrent Color look up tables 
saves *ALOT* of video memory. (I've only got 4 meg)

Now I'm sure I've totaly confused you. The GS isn't a render, it also a 
mini-computer with preprogrammed routines for primitive 
drawing/clipping. After you feed it data, the only way to get it back is 
in the form of a picture on your screen.


-Joshua