View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000610 | channel: elrepo/el7 | nvidia-x11-drv | public | 2015-12-09 09:28 | 2016-07-14 13:58 |
Reporter | prefect | Assigned To | pperry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Summary | 0000610: nVidia driver can't do remote OpenGL anymore | ||||
Description | With the updated X server from 7.2 (CentOS 7.1 CR), indirect GLX is disabled by default. This doesn't combine well with the nvidia driver. The problem seen by the user is that they can no longer ssh to another machine and run an OpenGL application, which was previously a commonly used feature by us. Output of glxinfo: libGL error: failed to load driver: swrast X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 3 (X_GLXCreateContext) Value in failed request: 0x0 Serial number of failed request: 27 Current serial number in output stream: 30 You can also see this behaviour by using the Mesa client libGL: LD_LIBRARY_PATH=/usr/lib64 glxinfo name of display: :0 libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast X Error of failed request: GLXBadContext Major opcode of failed request: 153 (GLX) Minor opcode of failed request: 6 (X_GLXIsDirect) Serial number of failed request: 46 Current serial number in output stream: 45 With nouveau no such problem exists, presumably because it's doing software rendering? Reenabling iglx in the X server restores functionality, but that's not obviously trivial to implement with gdm (at least not to me). Other than enabling iglx via a slightly grim wrapper script for Xorg, any suggestions as to a workaround? | ||||
Additional Information | kernel-3.10.0-327.el7.x86_64 nvidia-x11-drv-352.63-1.el7.elrepo.x86_64 xorg-x11-server-Xorg-1.17.2-10.el7.x86_64 | ||||
Tags | No tags attached. | ||||
Reported upstream | |||||
|
If I understand correctly, this appears to be a result of the updated Xorg server (1.17.2) in EL7.2. I note the following in the nvidia documentation: ftp://download.nvidia.com/XFree86/Linux-x86_64/352.63/README/xconfigoptions.html Option "AllowIndirectGLXProtocol" "boolean" There are two ways that GLX applications can render on an X screen: direct and indirect. Direct rendering is generally faster and more featureful, but indirect rendering may be used in more configurations. Direct rendering requires that the application be running on the same machine as the X server, and that the OpenGL library have sufficient permissions to access the kernel driver. Indirect rendering works with remote X11 connections as well as unprivileged clients like those in a chroot with no access to device nodes. For those who wish to disable the use of indirect GLX protocol on a given X screen, setting the "AllowIndirectGLXProtocol" to a true value will cause GLX CreateContext requests with the direct parameter set to False to fail with a BadValue error. Starting with X.Org server 1.16, there are also command-line switches to enable or disable use of indirect GLX contexts. -iglx disables use of indirect GLX protocol, and +iglx enables use of indirect GLX protocol. +iglx is the default in server 1.16, but as of this writing it is expected that in the next major release -iglx will be the default. The NVIDIA GLX implementation will prohibit creation of indirect GLX contexts if the AllowIndirectGLXProtocol option is set to False, or the -iglx switch was passed to the X server (X.Org server 1.16 or higher), or the X server defaulted to '-iglx'. Default: enabled (indirect protocol is allowed, unless disabled by the server). So the feature appears to be behaving as described in the documentation, hence not a bug in our packaging of the nvidia driver. |
|
Yes, I think you're entirely right. Your packaging is just grand, and I should be taking this up with Redhat and nvidia. I think I was just confused by nouveau and the VMware driver not suffering from this issue, but that still makes it an nvidia driver issue and not your packaging. |
|
OK, marking as Not A Bug as I'm agreed this is due to updated Xorg Server defaults. The workaround would appear to be to start Xorg with -iglx |
|
This bug was filed against RHEL7, but there was a recent xorg-x11-server update to RHEL6.8 that addressed this issue including workarounds so I'm including it here for reference. I don't know if this issue has been similarly addressed in RHEL7. https://rhn.redhat.com/errata/RHBA-2016-1402.html Updated xorg-x11-server packages that fix one bug are now available for Red Hat Enterprise Linux 6. X.Org is an open source implementation of the X Window System. It provides the basic low-level functionality that full-fledged graphical user interfaces are designed upon. This update fixes the following bug: * The X server update in Red Hat Enterprise Linux 6.8 included two behavior changes relative to version 6.7. By default, the X server did not listen for connections over TCP, and refused indirect GLX contexts. This update restores the defaults to those of version 6.7. In addition, it adds the "+iglx", "-iglx" options to explicitly control indirect GLX context support: "+iglx" to allow creating indirect GLX contexts, "-iglx" to disallow it. The default behavior is to allow creating indirect GLX contexts. To control indirect GLX contexts when using a display manager like GDM that does not allow arbitrary modification to the X server's command line, use the "AllowIndirectGLX" option in the ServerFlags section of xorg.conf: Section "ServerFlags" Option "AllowIndirectGLX" "on" # or "off" EndSection |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-12-09 09:28 | prefect | New Issue | |
2015-12-09 09:28 | prefect | Status | new => assigned |
2015-12-09 09:28 | prefect | Assigned To | => pperry |
2015-12-09 13:02 | pperry | Note Added: 0004591 | |
2015-12-09 14:27 | prefect | Note Added: 0004592 | |
2015-12-09 15:23 | pperry | Note Added: 0004593 | |
2015-12-09 15:23 | pperry | Status | assigned => resolved |
2015-12-09 15:23 | pperry | Resolution | open => no change required |
2016-07-14 13:58 | pperry | Note Added: 0004819 |