On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: > Keith Whitwell wrote: > > > Thomas Hellström wrote: > > > >> Hi, list! > >> > >> With display cards that have more and more hardware on them, > >> (TV-capture, mpeg decoders) etc. that can work independently of > >> oneanother, but share the same DMA engine I've find the need for more > >> than one hardware lock. > > > > > > The first question is - have you found that lock contention is > > actually a problem? > > > >> I've done a simple implementation for the mpeg decoder of the via > >> driver, but that one doesn't cover the DMA case. The question arises > >> "Why should I need to wait for DMA quiescent to check whether the > >> decoder is done with a frame, if there is no decoder data in any of > >> the pending DMA buffers"? > > > > > > But this question isn't really answered by having multiple locks - it > > sounds more like you want some sort of IRQ notification or > > timestamping mechanism. Under normal circumstances grabbing the lock > > doesn't mean waiting for DMA quiescence. > > > The typical case here: > > I want a DRI client to flip a video frame to screen, using a hardware > entity called the HQV. This is a rather time critical operation. To do > this I have to take the hardware lock. > > While this is happening, another thread is waiting for the mpeg decoder > to complete a frame. To to that, this thread needs to take the hardware > lock, wait for quiescent DMA, and then wait for the mpeg decoder to > signal idle. It might be that the DMA command queue does not even > contain mpeg data. This waiting delays the frame flip enough to create a > visible jump in the video. > > With multiple locks: > > The first thread checks the HQV lock, it is available and frame flipping > is done immediately. > > The other thread meanwhile takes the MPEG engine lock, waits until the > DMA engine has processed all MPEG commands in the command queue and then > waits for the MPEG engine to be idle. DMA might still be processing 3D > commands.
Do you not have interrupts that either signal MPEG engine idle, or just sw interrupts you can drop in the command stream? That would let you sleep waiting for them (rather than spinning, a win in itself) and you wouldn't have to hold the hardware lock. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
