Many GL errors in system log with Gnome 3.28

[Marcello Blancasio]

Accelerating Gnome 3.28 in RHEL 7.6 with VirtualGL works fine, excepted some GL errors found in /var/log/messages.

This message is issued once, at the beginning:

  journal: driver/gl/gl/cogl-texture-driver-gl.c:494: GL error (1285): Out of memory

then this one:

  journal: driver/gl/cogl-buffer-gl.c:87: GL error (1281): Invalid value

and a lot ot these two kinds:

  journal: driver/gl/cogl-clip-stack-gl.c:463: GL error (1281): Invalid value

  journal: driver/gl/cogl-framebuffer-gl.c:157: GL error (1281): Invalid value

As I monitored message log with tail -f , I noticed that those last two kinds of messages are issued when some screen update occur (e.g. when caret blinks inside a gnome-terminal window).

Regards.

[DRC]

Do these errors occur without VirtualGL? Please test both locally, with
GPU acceleration, and using the software OpenGL implementation in your X
proxy.

Did these errors start occurring recently (for instance, due to a system
update)?

Do these errors occur with multiple underlying OpenGL stacks (for
instance, nVidia and AMD)?

As near as I can figure, the errors are being triggered by the following
OpenGL functions:

> journal: driver/gl/gl/cogl-texture-driver-gl.c:494: GL error (1285):

glTexImage2D() or glGetTexLevelParameteriv()

> journal: driver/gl/cogl-buffer-gl.c:87: GL error (1281): Invalid value

glGenBuffers()

> journal: driver/gl/cogl-clip-stack-gl.c:463: GL error (1281):
Invalid value

glDisable (GL_STENCIL_TEST)

> journal: driver/gl/cogl-framebuffer-gl.c:157: GL error (1281):
Invalid value

glViewport()


I can't conceive of any reason why VirtualGL would be causing those
errors. Once VirtualGL redirects the rendering context to a Pbuffer on
the 3D X server, it steps out of the way. The errors are much more
likely to be due to an application bug (in this case, a COGL bug) or a
bug in the underlying OpenGL stack. However, do perform the diagnosis I
suggested above, and if it indicates that the bugs are indeed isolated
to VirtualGL, then send me more information about the specific
configuration that triggers them, and I can try to reproduce.

[Marcello Blancasio]

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.

[DRC]

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?

[Marcello Blancasio]

Thanks for looking into this. I'll test the patch and let you know.

--
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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/340151ed-049b-516b-b535-c3b273d4cb14%40virtualgl.org.

[Marcello Blancasio]

Sorry for the late reply.

I've tried the patch you suggested and the problem looks fixed, indeed.

Thank you again.

[DRC]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/0b12dee6-82f8-0284-a837-c3fb6f66a2eb%40gmail.com.