On Thursday 30 May 2002 9:15 am, Keith Whitwell scribed numinously:"
> > I've attempted some rather pathetic rate-adaption to make everything
> > slow down when the FIFO gets full. It utterly murders performance but
> > it did prevent the lockup from occurring. I modified ADVANCE_RING to
> > take a parameter containing a Wild-Ass-Guess of how many commands were
> > being added, then to call COMMIT_RING if it got over the maximum.
> > COMMIT_RING then read the number of free FIFO slots and adjusted the
> > maximum up or down depending on how well we were doing, and started to
> > hang around for a bit if things were getting full.
>
> This seems confused (or maybe it's me?). The COMMIT_RING is the only
> thing in common use in the 3d driver that should write to the fifo, I
> think. Calling COMMIT_RING more often means that more fifo entries are
> getting used?
On the evidence of my traces, no (though I won't disclaim confusion on my
own part...). For example, I have had one or two traces where
radeon_cp_idle was called and there were (e.g) 54 slots free in the FIFO.
The FIFO wasn't really budging over all that time (possibly owing to the
AGP bus being primarily occupied with reading the status register, I dunno)
and the traces went something like (apologies for reproducing from memory):
radeon_cp_idle
radeon_do_cp_idle
radeon_do_wait_for_fifo want 64 slots
radeon_cp_do_wait_for_fifo min=54 max=54 delay=10000
** ERROR ** failed
...
radeon_cp_idle
radeon_do_cp_idle
radeon_do_wait_for_fifo want 64 slots
radeon_cp_do_wait_for_fifo min=51 max=51 delay=10000
** ERROR ** failed
...
radeon_cp_idle
radeon_do_cp_idle
radeon_do_wait_for_fifo want 64 slots
radeon_cp_do_wait_for_fifo min=48 max=48 delay=10000
** ERROR ** failed
...
radeon_cp_idle
radeon_do_cp_idle
radeon_do_wait_for_fifo want 64 slots
radeon_cp_do_wait_for_fifo min=45 max=45 delay=10000
** ERROR ** failed
...
Which is not consistent with a single slot being occupied by the single call
to COMMIT_RING that happens, but rather with 3 slots being occupied by the
three commands:
RADEON_PURGE_CACHE();
RADEON_PURGE_ZCACHE();
RADEON_WAIT_UNTIL_IDLE();
in radeon_cp_do_idle()
Also, my traces without any attempt at rate adaption contain such as:
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x100 e=0x1f0
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 64
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=496 e=736 d=0
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x1f0 e=0x2e0
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 42
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=736 e=976 d=0
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x2e0 e=0x3d0
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 14
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=976 e=1216 d=0
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x3d0 e=0x4c0
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 0
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=1216 e=1456 d=0
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x4c0 e=0x5b0
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 0
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=1456 e=1480 d=0
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x5b0 e=0x5c8
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 0
<7>[drm:radeon_ioctl] pid=1617, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
<7>[drm:radeon_cp_indirect] indirect: idx=1 s=1480 e=1496 d=1
<7>[drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x5c8 e=0x5d8
<7>[drm:radeon_cp_discard_buffer] age=1
<7>[drm:radeon_cp_indirect] commit ring
<7>[drm:radeon_cp_indirect] fifo slots: 0
(it recovered from this by the way; this happens to be near the beginning of
a real trace)
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64 slots
free to 0 in one ioctl...
...so maybe what we need is some clue as to exactly how many commands we're
about to feed it (I made Wild-Ass-Guesses about the number of commands when
we were just blasting a buffer from userspace, which may go a long way to
explaining the sucky performance), and then something to make a prediction
on how long it'll take the card to clear the FIFO based on current
performance (constantly hammering on the status register is probably not a
good way of doing this :-)
--
Tim Smith ([EMAIL PROTECTED])
"All this comes out in a Government White Paper published today under the
title of 'The Amazing Habits and Pastimes of Mrs. Amelia Dimwiddy', price
fourpence, and I thought you ought to know."
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
