DMAC/VIF limitation ?

[Shazz]

Hello folks,

I'd like somebody to explain me this behavior following...

Context:
I build a VIF DMA packet which contains :
- the matrix using UNPACK VIF code
- the vertices XYZ2 data,m RGBAQ color data and textures coordinates ST using classic UNPACK VIF code

To maximise the VU usage, I sent in each GIF TAG 1 triangle (9 regs : 3x(RGBAQ + ST + XYZ2)) and I loop 28 times using the NLOOP register.

So basically I'm sending to the VU microprogram :
- 2 QW (Matrices)
- 28*3 (GS registers)
--------------------------
256 QW

I'm sending them uisng the DMAC chained mode and path 1 obviously.

So why 28 looping times ??? Because after it freezes... as it seems this 256 QW per pass seems a limit. (and 256 is never a random value :P)

I was thinking of a memory issue, I tried using the SPR and normal EE memory.. same result
I tried to cut the DMA packet using two DMA CNT tags to transmit the data in two blocks, same result

I tried to send 12 REGS within the GIF TAG isntead of 9 (2 triangles, no RGBAQ data) and so NLOOP was divided by 2 but same result, so basically NLOOP*NREGS shoud be lower than 256 (incluiding other QW sent like matrice...)



But I did not find this limitation anywhere, as it is not a DMAC limitation (2^16 QW limit if I'm not wrong), is it :
- a UNPACK vif code limitation ?
- a VIF limitation ?
- a bug in my code ?

Thanx :D

[Saotome]

i had the same problem recently :)
its because the vifpacket has a limit of 256 QW. but if you want to send 256 QW the NUM field of the packet should be 0, cause its only 8bit wide (0=256). so if you set the NUM to 256 it overflows into (/is OR'ed with) the VIF-CMD field and so the command is not what it should be anymore.

[Shazz]

Arg !!!! On my schema I saw that the NUM field was 16 bits wide but I missed that is was impossible !!! Yep only 8 bits !!! (hum yep 16+16+8 != 32 !)

Ok so it should work if I split the data in two sequential VIF packets so.. Hum, I thought I already tried... need to check !

Thx Saotome (again :D)