CODEWITHSUNDEEP
qtopenglqt5
DrPepperJo
DrPepperJo

Reputation: 722

OpenGL context sharing delay between threads

I have a very simple Qt/OpenGL setup, where my GUI thread can request texture upload in a worker thread. The worker thread is signaling back as soon as the texture is available and the GUI thread can then work with it.

Unfortunately, it seems like sometimes it takes up to ~50ms for the texture to be fully available for sharing in the GUI context. In this case, a part of the bound texture appears black. Introducing a waiting timer effectively solves the problem, but naturally slows down the processing. There is no obvious pattern to the required waiting time, so I was wondering if there was a way to find out if a texture is in fact ready to be bound in the shared context.

My setup looks as follows:

Early in the application I make sure the globalShareContext is available by calling

QCoreApplication::setAttribute( Qt::AA_ShareOpenGLContexts );

In the worker thread I create a context and hook it to the globalShareContext

QOpenGLContext context;
context->setShareContext( QOpenGLContext::globalShareContext() );

I then use one of the QOpenGLTexture's upload functionality to move the texture data to the GPU and eventually bind it in the GUI thread.

Upvotes: 2

Views: 602

Answers (1)

derhass
derhass

Reputation: 45332

Unfortunately, it seems like sometimes it takes up to ~50ms for the texture to be fully available for sharing in the GUI context.

You have a couple of issues here

  1. The GL works asynchronously. The fact that some GL command retunrs does not imply that all the effects of that command have already be realized (quite the contrary, usually). So you do not know when you can report to your other thread that texture is ready.
  2. Since the GL works asynchroously, it might wait for other GL commands to queue up before executing them. This means the acutal texture upload might be delayed infinitely

A quick&dirty fix would be to add a glFinish() command after the texture upload, which will force the GL to process all the commands which are still in the queue and block the calling thread until completion.

However, a much better solution are OpenGL Sync Objects.

Upvotes: 2

Related Questions