Tim Smith wrote: > 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...
I can't believe this. The ring is there specifically so that you don't have to worry about the fifo. It's a big buffer between you & the hardware - the hardware drains the ring at it's pace & you fill it at yours. Also note that you can tell the ring to fire off a big (64k or more) buffer of commands sitting elsewhere in agp space. That might be tens of thousands of fifo slots for a single write to the ring tail register. I'm still scratching my head... Keith _______________________________________________________________ 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
