<div dir="ltr">I am employing two Mesa OpenGL contexts in a Qt5 app that are part of the same context share group, <a href="https://doc.qt.io/qt-5/qopenglcontextgroup.html">https://doc.qt.io/qt-5/qopenglcontextgroup.html</a>, in two different threads. One thread renders to an offscreen OpenGL framebuffer object. After each frame is complete the thread detaches the texture from the framebuffer object and passes it, along with an OpenGL frame sync, to the main thread for compositing with the on-screen framebuffer. This allows the application GUI to remain responsive while heavy-duty rendering is being performed. This works well with NVidia OpenGL drivers installed but not with Mesa's swrast or Mesa LLVM drivers that I built from source. Stepping into the Mesa source code I can see the thread that renders to the offscreen framebuffer object steps into OpenGL functions defined in glapi_mapi_tmp.h where every function stub is implemented as "noop<GLfunction>" where <GLfunction> is the name of the OpenGL function with the "gl" prefix removed. The functions are complete no-ops.<div><br></div><div>Is this evidence that I didn't compile Mesa correctly for concurrency or something else? The Mesa configure log indicated that I do have GLX_TLS enabled.</div><div><br></div><div>Thanks,</div><div>Michael</div></div>