[Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Michel Dänzer]

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 at 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