Tim Smith wrote:
> On Friday 31 May 2002 2:00 pm, Keith Whitwell scribed numinously:"
>
>>Tim Smith wrote:
>>
>>>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 was being unclear. What I mean is that you can fire off a big chunk of
> commands via (e.g.) radeon_cp_cmdbuf, and when you COMMIT_RING() the FIFO
> is empty (64 slots free), but a few microseconds later when you com back to
> do your do_cp_idle(), the card has fetched a load of stuff to work on and
> the FIFO is full. This is obviously true and I don't expect it to be news
> :-)
>
> I seem to be observing the behaviour that if, on entry to do_cp_idle() the
> FIFO is not empty already, it never will be empty and the whole thing goes
> pear shaped. Thus, if a big collection of commands is just followed by more
> commands this doesn't seem to cause a problem, but if a big collection of
> commands is followed very quickly by a cp_idle(), it goes funny. This may
> of course be Yet Another Symptom, of which I seem to have chased many :-)
OK, but the three commands you mention
RADEON_PURGE_CACHE();
RADEON_PURGE_ZCACHE();
RADEON_WAIT_UNTIL_IDLE();
all emit stuff to the ring, rather than writing to registers. If there is a
culprit, I don't think it's these three.
> Me too. Could this be a locking problem? There seem to be two contexts owned
> by the same PID in this case, and the LOCK_TEST_WITH_RETURN() macro only
> tests that the PID is the same as the currently holding PID, not the
> context.
Oh, that's interesting...
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
