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.
How frustrating... I'd like to investigate all possiblities for getting some sort of synchronization information out of the hardware as this would seem to address your problem more directly & would hopefully keep the VIA driver looking more like the other drivers.
At very worst, there is the technique of adding a tiny little blit command to write a timestamp (ie 32bit color) to a piece of offscreen memory. Processes waiting for certain events should be able to poll the timestamp without holding the lock. Better would be to have the hardware blit or write back to a piece of system memory. You're still stuck with polling unless there is some IRQ (any IRQ) that can be enlisted for synchronization.
Keith
------------------------------------------------------- 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
