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

[Dave Airlie]

On 13 February 2017 at 19:07, Michel Dänzer <michel at 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 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?

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.