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

[Marek Olšák]

On Mon, Feb 13, 2017 at 11:10 AM, Gregory Hainaut
<gregory.hainaut at gmail.com> 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?
>
>
> Hello,
>
>
> Yes you're right. I just found out yesterday that it was related to
> GLX_MESA_multithread_makecurrent.
> I did a small patch to not kill glthread when direct GL1 code is used. It
> avoid the crash but it is far
> from robust. You could imagine situation where 1 thread uses dispatcher
> function and another
> use std serial call (of course without any sync of glthread). Now if you use
> only modern GL
> (that will always use glthread), it might work. Note: Piglit is working as
> both thread will restore
> the standard dispatch function.
>
> Feral said that they tried the extension but a gl dispatcher was faster.
> Googling a bit I found
> Eric's initial mail. So it seems to be used. Extension isn't published on
> Kronos, so usage likely
> remain confidential. Potentially glthread will be as fast as GLX_MT on
> cairo. But you're right,
> I don't see the point to support both at the same time.
>>
>> I'm happy now with the implementation of this extension, I've got
>> tests for most of the issues mentioned (the one that's really missing
>> is the bind-to-new-drawable one, but I don't anticipate issues with
>> it), and cairo-gl is getting a ~35% performance improvement from it
>> and is passing cairo's threading tests other than the one that fails
>> due to non-threading-related issuse.
>
>
> Actually glx-multithread-texture is pass with glthread (nouveau)
>
>
> As a quick summary:
> * there are now only 2 minors fail on piglit with my latest patches  (sent
> to Marek)
> * I have a pending patch to allow asynchronous PBO transfer
> * Now that piglit is crash free I will give a try to both glxgear and
> glmark. Hopefully they will be both good.

Note that if you run piglit with egl/drm, it might not have glthread enabled.

Marek