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 <mar...@gmail.com> wrote: > 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
