Optimising VIF transfers

[Shazz]

Hello,

I've got a question about VIF->GIF DMA packets optimisation, currently I'm sending to the VU a bunch of 4 vertices geometry information (ST RGBAQ XYZ2)*4 after the TEX01 texture information

So I was wondering, why only 4 ? As I'm using Triangle strips, why not sending in one paquet 40 vertices and associated data ? I've got 16Kb to fill !

But as I need to fill the NREGS register, it only permits me to send 16 different GIF registers so how can I send 40*3+1 = 121 regs in one packet ? Should I resend a GIF tag/PRIM each 16 regs ?

And is it obvious that this is better to send few large VIF packets after having computing all geometry information than lots of "small" ones but non blocking and doing MIPS computation within dma sends...

Hope I'm clear enough...

Code: Select all

        *((u64*)p_data)++ = DMA_CNT_TAG( 14 );

        // VIF_CODE(CMD,NUM,IMMEDIATE)
        *((u32*)p_data)++ = VIF_CODE( VIF_STCYL,0,0x0404 );

        *((u32*)p_data)++ = VIF_CODE( VIF_UNPACK_V4_32,14, 4);  //14 blocks 4*u32, starting at index 4

        // GIF_TAG(NLOOP,EOP,PRE,PRIM,FLG,NREG)
        // GS_SETREG_PRIM(prim, iip, tme, fge, abe, aa1, fst, ctxt, fix)
        *((u64*)p_data)++ = GIF_TAG( 1, 1, 1, GS_SETREG_PRIM( GS_PRIM_PRIM_TRISTRIP,
                                              1, 1, 0, 0, 0, 0, 0, 0 ), 0, 13  );
        *((u64*)p_data)++ = (u64)(0x5125125125126);             
 // NREGS : XYZ2 RGBAQ ST XYZ2 RGBAQ ST XYZ2 RGBAQ ST XYZ2 RGBAQ ST TEX01 from right to left
...

[Saotome]

the NREG registers in REGS are repeated NLOOP times. so actually you just need to write "XYZ2 RGBAQ ST" once into REGS and set NLOOP to 40 and send your 40(x3) values.
you can find this on page 143 in the EE user's manual ("5.4 REGLIST Mode")

[Shazz]

Yeeeh you're right, how I missed that ?

And for the TEX01 register how can I pass it only one time as it is part of sub PRIM registers ?

[blackdroid]

you can send giftags directly to gif via vif, so in your vifstream you could start with VIF[DIRECT] and then the GIF tags you want, then continue with VIF[MPG]/VIF[UNPACK]

[emoon]

This is usually good when you want to set "renderstates".
change alpha/active texture/turn off zbuffer testing/etc

.emoon

[Shazz]

Eh eh during the Iradium party last weekend I have decided to write a 64K based on my former VU code...

Speaking about that I had some issues with the PBDemolib, especially with the TextureUpload. I had to rewrite mien as if you use the TextureUpload for example at each frame to make a kind of 2D effect (modifying a bitmap buffer and send it as a texture) it was freezing (probably a pb of memory allocation, I wrote a textureupload using the same buffer and not doing sprAlloc each time... ) so emoon, I'd like to have your feedback...

But thinking about it, I saw that raizor, emoon, jar were using the renderTargets to code some kind of blur and radial effects but I really did not understand anything of how it is working....

Can anybody explain me how it works and the things behind ???

Thanks

[blackdroid]

you render to some offplace in vram by setting the fbp, then you change the fbp to your "normal" frame buffer and use the rendered offplace as texture and draw it.

or maybe you are really wondering about the builtin frame blur in the pcrtc ?

[Shazz]

hum, coming back to the DIRECT vif code... I've got a problem with it :

Code: Select all

        ///////////////////////////////////////////////////////////////////////////
        // send DIRECT giftag using path 2 with texture settings

        *((u64*)p_data)++ = DMA_CNT_TAG( 2 );
        // VIF_CODE(CMD,NUM,IMMEDIATE)
        *((u32*)pChain)++ = VIF_CODE( VIF_NOP, 0, 0 );
        *((u32*)p_data)++ = VIF_CODE( VIF_DIRECT, 0, 2);
        *((u64*)p_data)++ = GIF_TAG( 1, 1, 0, 0, 0, 1 );
        *((u64*)p_data)++ = 0x6;
        
        *((u64*)p_data)++ = PbTextureGetTex0( p_texture );
        *((u64*)p_data)++ = 0;  // 0 : only lower is significant

        ///////////////////////////////////////////////////////////////////////////
        // Build the data we need to send to the vu1

        *((u64*)p_data)++ = DMA_REF_TAG( (u32)&final_matrix, 4 );
        *((u32*)p_data)++ = VIF_CODE( VIF_STCYL,0,0x0404 );
        *((u32*)p_data)++ = VIF_CODE( VIF_UNPACK_V4_32, 4,0 );
        
        ///////////////////////////////////////////////////////////////////////////
        // Add giftag and vertex data

        *((u64*)p_data)++ = DMA_CNT_TAG( 1+(10*LOOPSIZE) );
        *((u32*)p_data)++ = VIF_CODE( VIF_STCYL,0,0x0404 );
        *((u32*)p_data)++ = VIF_CODE( VIF_UNPACK_V4_32, 1+(10*LOOPSIZE), 4 );

        *((u64*)p_data)++ = GIF_TAG( LOOPSIZE, 1, 1, GS_SETREG_PRIM( GS_PRIM_PRIM_TRIANGLE,
                                          1, 1, 0, 0, 0, 0, 0, 0 ), 0, 10 );
        *((u64*)p_data)++ = (u64)(0x5125125126);
       ...

The first block using the DIRECT VIF code makes the screen to freeze... what's wrong ?

[Saotome]

maybe a typo?

Code: Select all

*((u32*)pChain)++ = VIF_CODE( VIF_NOP, 0, 0 ); 
*((u32*)p_data)++ = VIF_CODE( VIF_DIRECT, 0, 2);

shouldn't the "pChain" be a "p_data"?

[Shazz]

Copy/paste will kill me...
But why the hell this NOP is needed ? to have data aligned on qw ?)

NOP.... nop nop nop...

but it works now :D thanks..