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

[Doug Larrick]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20040702/3e756a38/signature.pgp