On 11/02/17 06:36 AM, gregory hainaut wrote: > > On GLX side, I can explain some crashes (didn't debug all neither fail) > and I suspect there are related to the previous report. > > At the context creation a glthread dispatcher is created and the *TLS* > variable u_current_table is set with the new gl marshal function. > If deprecated non-VBO functions are detected > (glBegin/glVertexPointer/... and others horror from the previous > century), the code will disable glthread. > > 1/ thread will be deleted > 2/ u_current_table will be set to the original value > > However u_current_table is local to a thread. So a single thread will > get the correct dispatcher table. Remaining threads will keep the > previous marshal thread. If a glthread function is called without the > thread behind, then BOOM.
If I understand correctly, this scenario can only happen if the application takes advantage of the GLX_MESA_multithread_makecurrent extension. I wonder if we shouldn't just stop advertising that extension with glthread enabled. Actually, I wonder how well GLX_MESA_multithread_makecurrent works regardless of glthread. I suspect the assumption of a 1:1 correspondence between threads and contexts is quite widespread in the Mesa code. Case in point, the piglit test glx@glx-multithread-texture has been failing forever with radeonsi, though it passes with llvmpipe. Are there any real world applications which require GLX_MESA_multithread_makecurrent, or at least get a significant benefit from it? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
