| View previous topic :: View next topic |
| Author |
Message |
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
 Posted: Fri Sep 17, 2004 8:49 pm Post subject: GfxPipe |
 |
|
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...
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
 |
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Fri Sep 17, 2004 11:46 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Sat Sep 18, 2004 2:43 am Post subject: |
|
|
I have read this from Dr Fortuna website :
| Quote: | | 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. |
| Quote: | | ...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 ?
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
Drakonite
Site Admin
Joined: 17 Jan 2004
Posts: 989
|
| Posted: Sat Sep 18, 2004 2:55 am Post subject: |
|
|
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 ;)
_________________
Shoot Pixels Not People!
Makeshift Development |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Sat Sep 18, 2004 5:41 am Post subject: |
|
|
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 ?
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
Drakonite
Site Admin
Joined: 17 Jan 2004
Posts: 989
|
| Posted: Sat Sep 18, 2004 6:39 am Post subject: |
|
|
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 ;)
_________________
Shoot Pixels Not People!
Makeshift Development |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Sat Sep 18, 2004 9:00 am Post subject: |
|
|
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 ).
_________________
Kung VU |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Sat Sep 18, 2004 8:45 pm Post subject: |
|
|
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: | | 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 :
When the pipe is nearly full, the packet is sent to the DMA channel 2 (Dma02) :
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: | 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
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
TyRaNiD
Joined: 18 Jan 2004
Posts: 918
|
| Posted: Sat Sep 18, 2004 9:26 pm Post subject: |
|
|
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 ;) |
|
| Back to top |
|
|
Shazz
Joined: 31 Aug 2004
Posts: 244
Location: Somewhere over the rainbow
|
| Posted: Sun Sep 19, 2004 3:05 am Post subject: |
|
|
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)
_________________
- TiTAN Art Division -
http://www.titandemo.org |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
