On Tue, 4 Jun 2002, Jos� Fonseca wrote: > Leif, > > As I was restructuring part of the DMA submission code I realized that > there is a fault in the NO_BATCH_DISPATCH path. You don't guarantee > that the card doesn't stop at any momment because you've chosen not > check if a change in the last buffer continuation flag is sucessful or > not, and wait for idle & restart if not. This means that in _every_ > wait loop we have to account for possibility of the card to stop in > result of that (this include e.g., _wait_ring, but many others).
I'm checking for idle (but not waiting) on each commit by way of the do_dma_flush. If the card is idle, a new pass is started. If it has almost caught up to the tail but the card's not idle yet, it'll be seen on the next commit or in freelist_get. I don't think there's a fault here, it's just a different approach. My thinking was: how do you determine if moving the end of list flag was successful? You'll end up needing a wait loop to see if the card passes the previous tail (which can often be only one descriptor away from the new tail). That wastes CPU cycles, decreases concurrency, and increases the chance of the card going idle before the next commit (by finishing the ring). Maybe we could assume that if the head is a certain number of descriptors behind the previous tail, the card will continue on and not go idle -- that would reduce the need for a wait loop to situations where it's likely the card will go idle. Of course, if the draw engine locks up, then the card will stop, so there's really 3 possibilities: running, finished, or locked. > I tried to make quick fix to this, but it didn't solve anything (I can > reproduce the bug everytime I want by runing TO - a Mod to UT), so I > stopped trying to concentrate on what I was doing before. I just wanted > to tell you because you're probably looking at that too. > > Regarding the restructuring I'm doing, is basically a simplification to > bring more closely what I had previously in mind. I'm making the RING_* > macros to commit the buffers immediately, and the DMA_* macros to fire > up one buffer (also commiting immediately). The DMAADVANCE macro already does commit one buffer immediately if NO_BATCH_DISPATCH is set. I guess I'll have to wait and see what you had in mind here. BTW, I hadn't gotten to making pseudo-DMA work with the new path yet, but I think we should have that for debugging. > After seeing this problem I'm not sure if it won't be better to wait > for idle when commiting a buffer to ring too late, because this would > allow to assume that the card is either running or finished, and would > lessen the chances of bugs. See my comments above. > This is gonna take some days, but I'll come back with a diff for you to > comment as soon as I have it running minimally. OK, I'm going to take a break from the drm and wait to see your changes. I'm going to take a look at 2D accel. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ 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
