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

Isaac Richards ijr at po.cwru.edu
Fri Jul 2 10:50:47 EDT 2004


On Friday 02 July 2004 07:59 am, Doug Larrick wrote:
> Which one?  I think you're not understanding what I've done here.
> There's a usleep that waits after I launch the thread, to avoid a race
> for s_glsync_good.  Then there's the usleep in the sync thread's loop
> itself, which is critical so the player threads have a time window in
> which to acquire the sync_mutex lock.  This loop (after "Loop forever in
> this thread") repeats once per vertical refresh (16667 usec for 60 Hz).
>   For roughly 14667 usec of this loop, it holds the mutex while sleeping
> inside glXWaitVideoSyncSGI.  When this returns, we know we're in
> vertical retrace.  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.

> > It may be a slightly cleaner workaround to send a message to the main UI
> > thread to tell it to do something with GL after playback has ended, or to
> > spawn off a class + thread that can receive a similar message.  Still
> > have a thread 'using' GL that way, and it'd not change any of the current
> > logic. Thoughts?
>
> The "thread 'using' GL" has to do an operation once per video refresh.
> And it needs to be tightly synchronized to video playback -- I'm
> concerned that sending an inter-thread message is too high-latency (and
> more importantly, variable-latency) to do any good here.  I don't think
> the main UI thread is suitable.

Ah, didn't realize it had to be active.

> 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 also thought about launching an external program that talks to OpenGL
> and communicates with mythfrontend via a pipe (essentially emulating the
> old nVidia vsync), but that seems fragile.
>
> > 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.

Isaac


More information about the mythtv-dev mailing list