 |
forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
 Posted: Fri Dec 24, 2004 5:30 am Post subject: GIF_FIFO instead of DMA |
 |
|
I've found a nice article at http://www.research.scea.com/research/pdfs/RGREEN_procedural_renderingGDC2001.pdf , which says in chapter 3, that you can use GIF_FIFO to write data to the GS without DMA. Searching in the PCSX2 sources (http://www.pcsx2.net/downloads.php) reveals the address. Now I can use it like this:
| Code: |
#define GIF_FIFO ((volatile u128 *)0x10006000)
*GIF_FIFO = gifTag;
*GIF_FIFO = otherData;
|
I've timed the starsim demo like this:
| Code: |
#define T0_COUNT ((volatile unsigned int*)0x10000000)
#define T0_MODE ((volatile unsigned int*)0x10000010)
*T0_MODE = 0; // stop counting
*T0_COUNT = 0; // reset counter
*T0_MODE = 128 + 2; // start (128) + counting bus clocks / 256
for (int i = 0; i < 50; i++) {
// code to profile
}
int count = *T0_COUNT;
nprintf("us: %i\n", (int)(((float)count)*(256000.0/147456.0)));
|
and the DMA version needs 45 ms, but writing to GIF_FIFO, without constructing the rectangle list in memory first, needs only 42 ms. If you have much precalculated data, the DMA method may be faster (especially if you run code in the Scratchpad (see chapter 7 in the Sony article), while the DMA transfer runs), but if you always need to calculate every point, writing to the GIF_FIFO may be faster and easier to code. What do you think?
But in the article from Sony it is not recommended to use GIF_FIFO, because it can be changed in future versions of Playstation. How can I setup the memory map myself or is there a syscall or something else to query the memory map? |
|
| Back to top |
|
 |
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Fri Dec 24, 2004 7:42 am Post subject: |
|
|
| I would imagine that the main advantage of using dma would be the ability to do something else during the transfer, instead of just feeding the fifo. |
|
| Back to top |
|
|
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
| Posted: Fri Dec 24, 2004 7:57 am Post subject: |
|
|
| ooPo wrote: | | I would imagine that the main advantage of using dma would be the ability to do something else during the transfer, instead of just feeding the fifo. |
but in programs, which calculates all GS commands every time again, I can't see any advantage writing it first to memory and then using DMA. With DMA you need to flush the cache anyway, so I don't think there is any speed advantage. But perhaps I'm wrong, I'm a beginner in PS2 developing. |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Fri Dec 24, 2004 9:06 am Post subject: |
|
|
Has nothing to do with PS2, a dma controller is there to help move data from one place to another, so you dont have to sit in a tight loop doing read/writes, but instead doing other stuff, like calculating the necessary matrixes for the next frame or whatever. besides eventually you will move away from writing straight from EEmem to GIF and let the VIF1 and VU1 do that job.
You know that you can write to uncached mem btw ? so no need to flush, there are also ways to flush only the parts that you actually touched, wich is faster than using the syscall.
_________________
Kung VU |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Fri Dec 24, 2004 9:19 am Post subject: |
|
|
| As an aside, is the GIF_FIFO what the dma controller uses when you actually send data to the gif? Are there other fifos available for other devices? |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Fri Dec 24, 2004 9:25 am Post subject: |
|
|
| The speedup with DMA comes from not waiting on the GS. If you make a tight loop of storing values to the fifo that is long enough, you'll eventually outpace the GS and have to wait to send more data. By putting all the data in memory and then using DMA, the DMA controller does the waiting instead of the CPU. |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Fri Dec 24, 2004 6:02 pm Post subject: |
|
|
| ooPo wrote: | | As an aside, is the GIF_FIFO what the dma controller uses when you actually send data to the gif? Are there other fifos available for other devices? |
GIF Fifo isnt really documented in detail, it could be a memmapped dma register, that when gets written to the dmac takes the value and sends it to GIF.
_________________
Kung VU |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Sat Dec 25, 2004 1:51 am Post subject: |
|
|
| I meant more of when you send data via dma to the gif, it actually sends it to the gif_fifo itself. |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Sat Dec 25, 2004 4:04 am Post subject: |
|
|
Uhm yes GIF has a 256 byte FIFO that the dmac writes the data to, its all in the GS manual.
SIF0/1/2 also has a FIFO wich is shared, dont remember the size.
VIF1 also has a FIFO ( anyone remember VIF_NOP to flush FIFO ? ) 256 byte ( 16 qwords ).
there are other FIFO's aswel like the MemoryFIFO..
But now back to the xmas food.. laters.
_________________
Kung VU |
|
| Back to top |
|
|
Shine
Joined: 03 Dec 2004
Posts: 728
Location: Germany
|
| Posted: Tue Dec 28, 2004 3:18 pm Post subject: |
|
|
| blackdroid wrote: |
GIF Fifo isnt really documented in detail, it could be a memmapped dma register, that when gets written to the dmac takes the value and sends it to GIF. |
At least I've found the address documented in the eeuser_e.pdf at page 23. But if you write to fast to the GIF_FIFO, the internal buffer (16x16 qwords) can overflow, with the result that additional writes are ignored. I've written a small assembler function, which checks this and with which you can write all GS registers very easy without DMA transfer or thinking about how to setup the right GIF tag:
| Code: |
.globl SetGSReg
#------------------------------------------------------------------------
# void SetGSReg(u16 reg, u64 data);
#------------------------------------------------------------------------
.align 7
.ent SetGSReg
SetGSReg:
# wait for empty FIFO
lui v1, 0x1000
lui a3, 0x1f00
ori v1, v1, 0x3020
nop
WaitF: lw v0, 0x0000(v1)
and v0, v0, a3
nop # filling with nops to avoid
nop # "Loop length is too short for r5900."
nop # warning
bne v0, zero, WaitF
nop # branch delay slot command
# load GIF tag: 0x000000000000000e 1000000000008001: NLOOP=1, EOP=1, NREG=1, REGS0=GIF_AD
li v1, 0x000e
lui v0, 0x1000
dsll32 v0, v0, 0
ori v0, v0, 0x8001
pcpyld v1, v1, v0
# load GIF_FIFO (0x10006000) register
lui v0, 0x1000
ori v0, v0, 0x6000
# save GIF tag
sq v1, 0x0000(v0)
# save reg and data
pcpyld v1, a0, a1
sq v1, 0x0000(v0)
jr ra
nop
.end SetGSReg
|
Of course, this is not a good idea, if you want to show millions of triangles, but I've changed the starsim program and drawing the stars 50 times needs only 55 ms, so it is fast enough for simple applications and the code is much easier to understand without all the optimizations for newbies like me :-) |
|
| Back to top |
|
|
blackdroid
Joined: 17 Jan 2004
Posts: 564
Location: Sweden
|
| Posted: Tue Dec 28, 2004 8:13 pm Post subject: |
|
|
yes 16x16 usually gets rounded to 256 bytes :)
you know that your "simple" code essentially skips one giftag and 3 register writes for dealing with a dma send :)
num qwords -> dma_channel_qwc_register
start addr -> dma_channel_madr_register
kick -> dma_channel_ctrl_register
but I guess testing stuff by writing to the FIFO eliminates a potiential dma error.
that being said, the dmac on the ps2 is bloody easy.
_________________
Kung VU |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
