New threads API index different then context after an eglMakeCurrent.

Bug #1258579 reported by Brandon Schaefer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mesa (Ubuntu)
New
Undecided
Chris Halse Rogers

Bug Description

Say you have 2 threads A/B.

Thread A:
Starts running application, does an eglBindAPI(OPENGL), so the threads API index is 2
eglMakeCurrent(context) <--- The contexts API is 2
<renders stuff>
<start to swtich over to thread B>
eglMakeCurrent(EGL_NO_CONTEXT, EGL_NO_SURFACE) ... etc.

Thread B:
New thread created. Defaults the API index to OPENGL_ES. So the threads API index is 0.
eglcurrent.c:149: t->CurrentAPIIndex = _eglConvertApiToIndex(EGL_OPENGL_ES_API);

eglMakeCurrent(context) <--- The contexts API index is 2

--The Problem--
When it gets down to _eglBindContextToThread, it uses the contexts API index. So it binds the context to index 2, and returns TRUE.
On the next eglSwapBuffers, it does an _eglGetCurrentContext(), which uses the threads API index, which is 0. This returns an EGL_NO_CONTEXT (0x0), causing EGL_BAD_SURFACE, causing lots of other fun problems after. Mainly, after this happens, no rendering is possible.

_eglBindContextToThread:459 uses:
   apiIndex = (ctx) ?
      _eglConvertApiToIndex(ctx->ClientAPI) : t->CurrentAPIIndex;

To get the api index.

_eglGetCurrentContext:
   return t->CurrentContexts[t->CurrentAPIIndex];

So possibly, when a context is bound to a thread it should check if the threads api index != context api index, if so then set the threads api index to the contexts api index.

Changed in mesa (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)
Revision history for this message
Chris Halse Rogers (raof) wrote :

So, reading the spec (specifically, section 3.7), I believe the current mesa behaviour is wrong and you should be perfectly able to eglMakeCurrent(context). Indeed, it looks like you should even be able to call SwapBuffers on thread 2 even without making a context current there.

However, I don't think the proposed solution is correct, either; as I read the spec we actually need the the context (and surface) to have a reference to their own API index, separate to the thread's API index - you can have multiple contexts of different APIs active on a same thread.

To the mesa devel lists!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.