[Openchrome-users] [PATCH] Re: MythTv judder: XvMCPutSurface using a lot of CPU

[Terry Barnaby]

Terry Barnaby wrote:
> Terry Barnaby wrote:
>> Terry Barnaby wrote:
>>> Hi,
>>>
>>> I am trying to track down a problem I have with MythTv under Fedora 8 
>>> using
>>> the openchrome driver and libchromeXvMC library.
>>> MythTv has a lot of juddering and glitches even though the XvMC VLD
>>> acceleration is in use.
>>> This is also present with the stock via driver and libviaXvMC library.
>>>
>>> Using the old mp2decoder XvMC test program I see that sending one
>>> frame at 25Hz uses about 12% CPU. If I modify  mp2decoder to send
>>> two frames at 50Hz (Just calling XvMCPutSurface twice with the same
>>> frame) the CPU usage shoots up to 98%. This is equivalent to
>>> MythTv outputting in BOB de-interlace mode and appears to show the
>>> same problem I have with MythTv.
>>>
>>> I guess this could be a libchromeXvMC/libviaXvMC or DRM issue.
>>> Has anyone any idaes on this ?
>>>
>>> Cheers
>>>
>>>
>>> Terry
>>>
>>>
>>> _______________________________________________
>>> openchrome-users mailing list
>>> openchrome-users at openchrome.org
>>> http://wiki.openchrome.org/mailman/listinfo/openchrome-users
>>> Main page:
>>> http://www.openchrome.org
>>> Wiki:
>>> http://wiki.openchrome.org
>>> User Forum:
>>> http://wiki.openchrome.org/tikiwiki/tiki-view_forum.php?forumId=1
>>>
>>
>> I have tracked this down a bit further.
>> The syncVideo() routine is being called from pciFlush() with doSleep = 0.
>> This is sitting in a tight loop for 20ms (I guess until the next VSYNC 
>> ??).
>> Even setting doSleep to 1 does not fix the issue as in MythTv the
>> output thread is a Realtime thread and nanosleep() is, I believe, 
>> implemented
>> as a tight loop when call from a real-time thread.
>>
>> I'm not sure of exactly the best way to fix this issue ...
>> Does syncVideo() wait for the next VSYNC period ?
>>
>> Cheers
>>
>>
>> Terry
> Hi,
> 
> The enclosed patches reduce the CPU usage while using MythTv from 98% to 
> about 40% on a Via M10K. One is for the Openchrome library and the other 
> is for the
> stock via library. These may not be the best way of curing this problem, 
> but I
> thought it might help some people or at least give a pointer to possible
> solutions.
> 
> Cheers
> 
> 
> Terry
> 
Some more info.
Although my previous patches reduced the CPU usage in MythTv, there was still
some stuttering present.
I note that if I put a return statement at the start of syncVideo(), ie don't
wait for HQV completion then MythTv works fine, ie no stuttering.
So I guess there must be some issue with waiting for HQV with MythTv. It
looks like when syncVideo() delays for 20ms or more it holds the DRI locks and
hence the MPEG decode is locked for a while leading to pre-buffering pauses.
But why is syncVideo() taking a long time ?
Note also that xine works fine, so I guess it is some MythTv/XvMC interaction
going on here ...


Cheers


Terry