[mythtv] [PATCH] Fix for crash using OpenGL vsync
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.
More information about the mythtv-dev