<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><pre>On 11/02/17 06:36 AM, gregory hainaut wrote:
><i> 
</i>><i> On GLX side, I can explain some crashes (didn't debug all neither fail)
</i>><i> and I suspect there are related to the previous report.
</i>><i> 
</i>><i> At the context creation a glthread dispatcher is created and the *TLS*
</i>><i> variable u_current_table is set with the new gl marshal function.
</i>><i> If deprecated non-VBO functions are detected
</i>><i> (glBegin/glVertexPointer/... and others horror from the previous
</i>><i> century), the code will disable glthread.
</i>><i> 
</i>><i> 1/ thread will be deleted
</i>><i> 2/ u_current_table will be set to the original value
</i>><i> 
</i>><i> However u_current_table is local to a thread. So a single thread will
</i>><i> get the correct dispatcher table. Remaining threads will keep the
</i>><i> previous marshal thread. If a glthread function is called without the
</i>><i> thread behind, then BOOM.
</i>
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 <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">glx at glx-multithread-texture</a> 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?</pre></blockquote><div><br></div><div>Hello,<br><br><br></div><div>Yes you're right. I just found out yesterday that it was related to GLX_MESA_multithread_makecurrent.<br>I did a small patch to not kill glthread when direct GL1 code is used. It avoid the crash but it is far<br>from robust. You could imagine situation where 1 thread uses dispatcher function and another<br>use std serial call (of course without any sync of glthread). Now if you use only modern GL<br>(that will always use glthread), it might work. Note: Piglit is working as both thread will restore<br>the standard dispatch function.<br><br></div><div>Feral said that they tried the extension but a gl dispatcher was faster. Googling a bit I found<br>Eric's initial mail. So it seems to be used. Extension isn't published on Kronos, so usage likely<br>remain confidential. Potentially glthread will be as fast as GLX_MT on cairo. But you're right, <br></div><div>I don't see the point to support both at the same time.<br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><pre>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.</pre></blockquote></div><div><br></div><div></div><div>Actually glx-multithread-texture is pass with glthread (nouveau)<br></div><div><br></div><div><br></div><div>As a quick summary:<br>* there are now only 2 minors fail on piglit with my latest patches  (sent to Marek)<br></div><div>* I have a pending patch to allow asynchronous PBO transfer<br>* Now that piglit is crash free I will give a try to both glxgear and glmark. Hopefully they will be both good.<br></div><div><br></div><div>Gregory<br></div></div>