On Mon, Feb 13, 2017 at 11:10 AM, Gregory Hainaut <gregory.hain...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
