[mythtv] [PATCH] Fix for crash using OpenGL vsync

John Patrick Poet john at BlueSkyTours.com
Mon Jul 5 13:49:56 EDT 2004


Doug Larrick wrote:

> Isaac Richards wrote:
>
>> On Friday 02 July 2004 07:59 am, Doug Larrick wrote:
>
> {snip}
>
>>> We release the mutex and usleep for 2000 usec, in
>>> which period any video playback thread(s) may acquire the mutex 
>>> briefly.
>>>  At the time when a playback thread is able to acquire this mutex, it
>>> knows it's (approximately) in vertical retrace.  I used the value 2000
>>> because it's around the same precision as ExAVSync tries to maintain.
>>
>>
>>
>> That's the one.  You're forgetting that the usleep(2000) is going to 
>> be sleeping for a minimum of 10ms, not 2 on most people's machines.
>
>
> Ahh yes, I thought I remembered this was changed earlier than 2.6 but 
> I see I was mistaken.  Of course, HZ has been 1024 always on Alphas 
> (my previous life) so maybe I have an excuse.  With a 10ms tick we're 
> gonna have trouble reliably getting back and forth between the two 
> threads at all.  I think I begin to see your objection here...  of 
> course, for a 2.6 kernel it's totally fine.  Suggestions?  Require 
> video card A/V sync to use a 2.6 kernel?  Use this workaround (and 
> thus enable use of nVidia card w/o crash) only if we detect a 2.6 kernel?
>
>>> Believe me, I spent almost a month trying easier approaches.  The thing
>>> is, to work around the OpenGL driver bug I discussed in my original
>>> message, I need to make these glXWaitVideoSyncSGI calls from a thread
>>> that never goes away, or the *second* attempt to start up the vsync
>>> system fails (crashes).
>>
>>
>>
>> Have you reported the bug?
>
>
> I will... need to code up a reliable reproducer.  I don't have high 
> hopes for a quick fix considering nVidia's release cycles, and 
> considering they seem to have abandoned the /dev/nvidia0 approach.  
> I'll complain about that too.
>
>>>> Also, is the GL code cleaning up after itself properly?  I'm seeing a
>>>> call to XOpenDisplay + a couple XCreate??, but nothing to get rid 
>>>> of em..
>>>
>>>
>>> The sync thread runs continuously from the start of the first video
>>> playback until the end of the world (mythfrontend exit), because it has
>>> to.  There's nothing to clean up until program exit, at which point it
>>> doesn't matter anymore. 
>>
>>
>>
>> I was more talking about the current code that's in CVS, not with 
>> your patch.
>
>
> Yes, well that's true.  Of course, due to the bug this patch is trying 
> to work around, it's gonna exit (crash) at the beginning of next 
> playback anyway :-)
>
> In a later message:
>
>> Btw, is there any way to reliably reproduce this?  I can't get it to 
>> die at all here with driver v.5336 with a GF4.
>
>
> John Poet and I both see it; I usually crash on playing back the 3rd 
> recording, he on the 2nd.  I think we're both running 2.6 kernel so 
> maybe it has to do with NTPL.  Maybe that's an argument for only using 
> this workaround if it's a 2.6 kernel.
>
>> Does calling glXMakeCurrent(disp, 0, 0) and/or DestroyContext when 
>> it's done with the GL stuff help any?
>
>
> First thing I tried :-)
>
> Though I may take your suggestion and try to do so *from the main UI 
> thread* just before shutting down the video playback thread.
>
> -Doug


Hi Doug,

Sorry I have not had a chance to try this patch until now -- been 
working on my own patch and did not want to confuse any issues.

Unfortunately, using OpenGL for vsync still gives me some grief.  It no 
longer segfaults the second or third time I "watch tv", but now the 
frontend just locks up with message like this:

vblank nvidia retrace timeout
Init found OpenGL vsync
2004-07-05 11:38:27 Video timing method: OpenGL vsync
2004-07-05 11:38:27 Refresh rate: 33366, frame interval: 33366
2004-07-05 11:38:27 waiting for prebuffer...
2004-07-05 11:38:27 prebuffer wait timed out..
2004-07-05 11:38:27 waiting for prebuffer...
2004-07-05 11:38:27 prebuffer wait timed out..
2004-07-05 11:38:27 waiting for prebuffer...
2004-07-05 11:38:27 prebuffer wait timed out..
2004-07-05 11:38:27 waiting for prebuffer...
2004-07-05 11:38:27 prebuffer wait timed out..
2004-07-05 11:38:27 waiting for prebuffer...
waiting for free video buffers timed out
waiting for free video buffers timed out
waiting for free video buffers timed out
waiting for free video buffers timed out
waiting for free video buffers timed out
waiting for free video buffers timed out

The "waiting for free video buffers timed out" continues until I kill 
mythfrontend.

I suppose it is possible that something in my patch is causing this, but 
I don't think so.  Does this make any sense to you?

Thanks for working on this.

John



More information about the mythtv-dev mailing list