GfxPipe

[Shazz]

Can somebody explain me the GfxPipe method used by Vzzrzzn and Sjeep to increase the perfs beween the EE and the GS ?

Is it related to the use of the 2nd DMA path between the GS and the VIF ???

I looked at the code but it remains 'magic' for me...




I understood that instead of waiting the VBL, it sets a handler to the VBL interrupt, thanx Blackdroid ;-)

But I did not understood what this handler routine is doing...

[ooPo]

While people are looking at that pretty diagram, I'd like to know why path2 is used from the EE instead of path3 for a lot of sample code I've seen...

[Shazz]

I have read this from Dr Fortuna website :

Image data used for texturing is normally sent to the GS via path 2 or 3. Path 3 is a direct path to the GIF whilst Path 2 is through VIF1 to the GIF. There are a few additional overheads associated with sending data via Path 2 but Path 2 has the advantage of providing inherent synchronisation between texture and vertex data.

...uploading of texture data via Path 2, which is via VIF1 to the GIF. This technique is useful for synchronising the uploading of texture data with geometry that is to be rendered by VU1 over Path 1. If both the texture and the geometry are sent via VIF1 (with the texture being sent first), then it is guaranteed that the correct texture is in GSmem before the rendering of the geometry is started.

Is it the clue ?

[Drakonite]

That means that if you are running code on VU1 just after uploading textures that code is going to need, it guarentees you won't have a problem with running the code before the textures are uploaded.

For the purposes of gfxpipe, I doubt anyone is using VU1 and gfxpipe at the same time so this definately doesn't have an effect ;)

[Shazz]

okay... the DMA path is not the key (but an interesting point.... why everybody uses the path2 without using any VU rendering code ?)

But can someone explain me what differs between 'classic' GS call using DMA packets (as Dreamtime's tutorials do) and GfxPipe ????

According to Evilo (neoCD), framerate doubles using GfxPipe and Pillgen demo is quite impressive...

Is the VBL interrupt the key ?

[Drakonite]

Without seeing the code I'd bet that the slower code sits and waits for the DMA to finish, and the faster code starts the DMA then goes back to doing other things.

Just a guess really... hard to tell when I haven't looked at it much ;)

[blackdroid]

They are not using PATH2 if they did they would be sending a vif direct command and then the gif tags, ive yet to seen any code like that in dreamtime's tutorials or in vzzrzzn's "gfxpipe".

the vb interrupt certainly is not the key, when you are done sending your gif data it doesnt matter if you sit in a wait loop waiting for either a bit or an interrupt handler to kick you in the ass.

both dreamtime and vzzrzzn build a dma packet with gif tags in them and tell dmac to send it to gif ( wich is channel 2, not path 2 ).

[Shazz]

Okay... I think I understood something, gfxpipe create a DMA GIF pipe, let say a memory space of 262144 bytes (magic number ? max size of a packet ? I thought that the max size was 1 Mb... 1 Mb is maybe too much for one VBL...)

Code: Select all

createGfxPipe(&thegp, (void *)0xF00000, 0x40000);

Then each time a drawing primitive is called, the DMA tags/values are added to the pipe using a packet pointer then the pipe fill level is checked :

Code: Select all

gp_checkflush(p);

When the pipe is nearly full, the packet is sent to the DMA channel 2 (Dma02) :

Code: Select all

gp_hardflush(p);

And a new empty pipe is initialized...

So if I'm not wrong, th e stategy is to minimize DMA communication using as few as little DMA packets as possible but full of DMA GIF Tags...

Is it the clue so ???

I still don't know what are :

Code: Select all

    unsigned long *dmatadrA;    // 'pipe 1' ... base of allotted pipeline memory
    unsigned long *dmatadrB;    // 'pipe 2' ... dmatadrA + (memsize / 2)

And is this strategy not dangerous if the number of things to draw in 1 VBL is less than the pipe size ??? Maybe they call the gp_hardflush(p); by default at each VBL interrupt..have to check.... ;-)

Understanding good code is really nice... it helps a newbie like me :D

[TyRaNiD]

The idea is not as such to limit the packets but to limit waiting for dma to finish. When you dma something you potentially have to wait for that dma channel to finish transmission before you can send a new packet. The key to decent speed is basically (don't hold me to this) :

1) Build as long a list of information as possible for sending to the GIF (up to 16k QWORDS I think).
2) When you send the DMA have a second buffer and start building the next list of DMA items while the original is sending.
3) Only wait before you send the next packet, _do not_ wait after sending.

For things you do everyframe (e.g. drawing background graphics which never change) you can prebuild the list and use source chain DMA mode to just call each list of DMA items. That gives you the potential for a large drawing list and your code only has to write the one DMA CALL tag instead of copying the whole list each time.

This is from memory though, might be wrong ;)

[Shazz]

Thanx Tyranid !!!

It clearly explains the 2 pipes and why all of this....

Thanks for all guys... funny ping pong...


see you soon for another dummy question ! ;-)

I've got a plenty bags of questions ! :D (like is it possible to update parts of a texture already sent to the GS memory...eh eh)