Unfortunately, I think I may know what's happening. I suspect that the
window manager is taking advantage of the GL_EXT_x11_sync_object
extension
(https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_x11_sync_object.txt).
Ugh. After years of moving in the direction of separating GLX objects
from X11 objects, now X11 objects are being married directly with
OpenGL?! Who green-lighted this?! This extension is unfortunately
implemented in a way that would not be particularly easy to interpose.
The problem is that, since the X11 sync object is created against an X
window and outside of the scope of GLX, I have no way of knowing whether
it will be used for this OpenGL extension or whether it will be used for
regular X11 functions. If it's used for both, then it's impossible for
VirtualGL to emulate the functionality of GL_EXT_x11_sync_object,
because the sync object would have to simultaneously live on both the 2D
and 3D X servers (which defeats the purpose of synchronization.)
I could interpose glGetString() and remove GL_EXT_x11_sync_object from
the OpenGL extension list, but the Mutter code doesn't seem to check for
the existence of that extension before using it. Thus, I think the best
approach is to make our interposed version of glXGetProcAddress() return
NULL if passed "glImportSyncEXT". Can you test whether the attached
patch fixes the problem?
On 8/12/19 9:55 AM, Marcello Blancasio wrote:
> Those errors does not occur without VirtualGL. I've tried both locally
> with GPU and
> with llvmpipe software renderer in X proxy.
>
> Sorry, I couldn't say if errors started after any system upgrade. I
> didn't search /var/log/messages
> for them before.
>
> I've tried with same version of Gnome (3.28) on and AMD equipped host
> and found no error there.
> But OS is Fedora 28, not RHEL7. So I'm not completely sure.
>
> I've tried to catch the first error (Out of memory) with gdb. I think
> the report is wrong:
> glGetError() returns GL_OUT_OF_MEMORY even before glTexImage2D() is
> called, so I guess
> glGetError() is just sampled at a wrong time.
>
> The call causing the error looks this one, rather:
>
> self->gl_x11_sync = meta_gl_import_sync (GL_SYNC_X11_FENCE_EXT,
> self->xfence, 0);
>
> at compositor/meta-sync-ring.c:354
>
> The the specific configuration causing this issue for me:
>
> OS: RHEL 7.6
> Video card: Quadro K600
> Driver version: NVIDIA 430.26
> Gnome version: 3.28 (gnome-shell 3.28.3)
>
> -
> Marcello.
>
--
You received this message because you are subscribed to the Google Groups
"VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/virtualgl-users/340151ed-049b-516b-b535-c3b273d4cb14%40virtualgl.org.
diff --git a/server/faker-glx.cpp b/server/faker-glx.cpp
index 02c0e7d1..812cbee2 100644
--- a/server/faker-glx.cpp
+++ b/server/faker-glx.cpp
@@ -1674,8 +1674,17 @@ void (*glXGetProcAddressARB(const GLubyte
*procName))(void)
}
if(!retval)
{
- if(fconfig.trace) vglout.print("[passed through]");
- retval = _glXGetProcAddress(procName);
+ // GL_EXT_x11_sync_object is impossible to implement in
VirtualGL.
+ if(!strcmp((char *)procName, "glImportSyncEXT"))
+ {
+ if(fconfig.trace) vglout.print("[NOT IMPLEMENTED]");
+ retval = NULL;
+ }
+ else
+ {
+ if(fconfig.trace) vglout.print("[passed through]");
+ retval = _glXGetProcAddress(procName);
+ }
}
STOPTRACE(); CLOSETRACE();
