Sorry for the late reply.
I've tried the patch you suggested and the problem looks fixed, indeed.
Thank you again.
On 26/08/2019 09:35, Marcello Blancasio wrote:
Thanks for looking into this. I'll test the patch and let you know.
On 22/08/2019 08:27, DRC wrote:
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]
<mailto:[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
<https://groups.google.com/d/msgid/virtualgl-users/340151ed-049b-516b-b535-c3b273d4cb14%40virtualgl.org?utm_medium=email&utm_source=footer>.
--
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/0b12dee6-82f8-0284-a837-c3fb6f66a2eb%40gmail.com.
