The patch has been integrated. For correctness, VGL now also removes GL_EXT_x11_sync_object from the list of extensions returned by glGetString() or glGetStringi(). I've seen some applications that check for the existence of an OpenGL extension, use glXGetProcAddress() to load the address of a function that that extension provides, and don't check the return value of glXGetProcAddress(). Thus, I felt it prudent to do the right thing.
On 9/11/19 3:40 AM, Marcello Blancasio wrote: > 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] > <mailto:[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 > <https://groups.google.com/d/msgid/virtualgl-users/0b12dee6-82f8-0284-a837-c3fb6f66a2eb%40gmail.com?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/ffbe6efc-147d-8406-ef8a-ca2118307505%40virtualgl.org.
