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

[Gregory Hainaut]

Hum, I need to check it. I think I disabled EGL because I didn't have
latest waffle on my Debian (and Nvidia didn't support fully EGL back
then).

However, I forgot to say that a fair number of piglit tests are based
on GL1 direct call. (typically to draw a rectangle without a VBO). All
those tests will disable glthread in the middle. In the current state,
piglit is far from ideal to test glthread. Maybe CTS could help to
increase the coverage. I will give it a shot.

Gregory

On 2/13/17, Marek Olšák <maraeo at gmail.com> wrote:
> 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
>