Thomas Hellström wrote:
Hi, Erdi!

I have been testing the ring-buffer quite extensively since there is an option in the unichrome X driver to use it for 2D acceleration and for XvMC mpeg. I and other people have had some problems with short hangs and above all total screen confusion (sometimes recoverable) every once in a while.

The short hangs seems to be related to the fact that the command regulator stops short of the last buffer segment while the code not waiting long enough to detect the stop. This is a very rare occurence. I also added a DRMWRITEMEMORYBARRIER() here to make sure write-combined data was flushed to AGP memory. I'm not sure this is the right way to do it or whether this is even necessary.

The other problem is the rewind code. It seems to fail about every 200th rewind or something, but not consistently, and I can find no pattern in wether it fails when the jump command is issued using PCI or from the AGP buffer. However, I tried to modify the code so that the jump command was always issued from the AGP buffer and still got occasional fails. What seems to happen is that bad data is sent to the decoder or that a buffer segment is skipped. Finally I replaced the jump code with a via_cmdbuf_reset and via_cmdbuf_start call, and suddenly everything worked well. Unfortunately, this has to wait for command buffer completion.

So my question is how exactly does that jump command work? From the code I could see you modified the buffer end and then made a jump command to / (from ?) that end address.
I do not know how the jump command is supposed to work either. I wrote the code by studying a part of VIA's windows driver code and lots of experimentation. I mostly tested with 3D and the CN400 (Unichrome/Pro), which maybe why it failed with 2D and the CLE266. The CN400 will block the CPU until the previous register write has completed while the CLE266 will just clobber it.


Will the command regulator automatically wraparound when it reaches the buffer end? In that case it would be possible to alter the code to fill the buffer completely and never use the jump / rewind command.
The rewind code changes the end buffer register to force the command regulator to wrap to the beginning. The trick is to make sure that it stops after it has wrapped, which is why every buffer write prefills the current end of buffer with a pause command. The write buffer code will then replace the previous pause command will a jump command. It also checks whether the command regulator has already reached the pause location before it updates the buffer, in which case it will have to restart it through PCI.


I'll attach a patch for my latest stop / start version that seems to be working OK, but that suffers from that it has to stop DMA to restart it at buffer end.


Best regards
Thomas.


------------------------------------------------------------------------

I am in the process of moving and have things packed up and no internet connection at home now. Will check it out after I have settled down in my new place next month.



------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to