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

[Gregory Hainaut]

>
> 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 <https://lists.freedesktop.org/mailman/listinfo/mesa-dev> 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.

Gregory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170213/62a4f00e/attachment.html>