On 13 February 2017 at 19:07, Michel Dänzer <mic...@daenzer.net> wrote: > 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?
I think glvnd also wants to disable this extension, cairo was the thing that used it but who knows what hacks have gone into other stuff. Dave. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
