> 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.
You're right. Unfortunately the MPEG interrupt is not functioning on the CLE266 (HW bug according to VIA). Also there doesn't seem to be a SW command stream interrupt either. Not even a command stream completion interrupt. /Thomas > > -- > 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
