On Friday 31 May 2002 4:12 pm, Keith Whitwell scribed numinously:" > 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.
Prob'ly not. I will note that they get added to the ring again every time do_cp_idle() is called, which seems a little pointless, but no, I don't think they're the problem (unless having them there twice in a row is going to cause trouble). They were just present in the evidence for my assertion that reduced frequency of ring tail pointer use does not imply reduced use of the FIFO. > > 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... I'm going to add a trace to that macro tonight and see if anything bad is actually happening of that nature. Another thing I've noticed is that we're going to get a sequence like: 1) do_cp_idle() called (FIFO happens to be empty) 2) RADEON_PURGE_CACHE(), RADEON_PURGE_ZCACHE(), RADEON_WAIT_UNTIL_IDLE() added to ring 3) COMMIT_RING() called (FIFO is still empty) 4) wait_for_fifo() returns at once (FIFO is still empty) 5) flush_pixcache() happens (this is a register write and is immediate) 6) purge_cache, purge_zcache, wait_until_idle actually picked up and executed by the card So the *order* of things happening is actually the reverse of what's in the code. Again, I don't think this is the problem since this exact sequence is clearly happening several hundreds of times without things going funny, but I'm wondering if it might not be something else of the same nature? -- Tim Smith ([EMAIL PROTECTED]) Rhodians are a delicacy in the Plasteen System _______________________________________________________________ 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
