ssh forwarded glx returns "Error: couldn't find RGB GLX visual or fbconfig" against older servers

Bug #384001 reported by Joakim Plate on 2009-06-05
48
This bug affects 7 people
Affects Status Importance Assigned to Milestone
X.Org X server
Confirmed
Medium
mesa (Ubuntu)
Low
Unassigned

Bug Description

After upgrading to Jaunty 9.04 from Hardy remote glx rendering (over ssh or just network) against older servers is not working anymore.

Currently i've only tested against two X servers:
X-Win32
Mac OSX Leopard X11 Server

Both of which works fine on the same machine when rebooted into Hardy (still available on another partition)

glxinfo outputs:
> name of display: localhost:10.0
> Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
> Error: couldn't find RGB GLX visual or fbconfig

xdpyinfo outputs that i have SGI-GLX and GLX extension, will attach the full output later.

I suspect that newer glx client side libs must be needing something not provided by the older servers.

Let me know what other types of logs that are of interest

[lspci]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)
     Subsystem: AOPEN Inc. Device [a0a0:062d]

---
Architecture: i386
DistroRelease: Ubuntu 10.04
DkmsStatus: Error: [Errno 2] No such file or directory
MachineType: AOpen i965GMx-IF
Package: mesa (not installed)
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-22-generic root=UUID=0f9b4a48-eec1-46c2-a350-078a0eed0034 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Tags: lucid lucid
Uname: Linux 2.6.32-22-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare video
dmi.bios.date: 12/11/2007
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: i965GMx-IF
dmi.board.vendor: AOpen
dmi.board.version: 558EX10I690
dmi.chassis.type: 3
dmi.chassis.vendor: AOpen
dmi.chassis.version: i965GMx-IF
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd12/11/2007:svnAOpen:pni965GMx-IF:pvrAO00001JW:rvnAOpen:rni965GMx-IF:rvr558EX10I690:cvnAOpen:ct3:cvri965GMx-IF:
dmi.product.name: i965GMx-IF
dmi.product.version: AO00001JW
dmi.sys.vendor: AOpen
glxinfo:
 Error: couldn't find RGB GLX visual or fbconfig
 name of display: localhost:10.0
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-22-generic

Joakim Plate (elupus) wrote :

This is the glxinfo from an intrepid system (which happens to have NVIDIA drivers installed)

display: localhost:10 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbo se)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
    GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,
    GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,
    GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGI_swap_control, GLX_ARB_create_context, GLX_NV_float_buffer,
    GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float,
    GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB,
    GLX_NV_present_video, GLX_NV_multisample_coverage
GLX version: 1.2
GLX extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_ARB_get_proc_address
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI Mobility Radeon X1400
OpenGL version string: 1.2 (2.0.6471 Release)
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_multitexture, GL_ARB_point_parameters,
    GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map,
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_window_pos, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
    GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array,
    GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap,
    GL_SGIS_texture_lod

4 GLX Visuals
   visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
 id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 0 32 0 r . . 8 8 8 8 2 32 8 16 16 16 16 2004364842 97656505 1 None
0x24 24 tc 0 32 0 r y . 8 8 8 8 2 32 8 16 16 16 16 909327152 809329520 None
0x25 8 pc 0 0 0 c . . 0 0 0 0 2 32 8 16 16 16 16 0 0 None
0x26 8 pc 0 0 0 c y . 0 0 0 0 2 32 8 16 16 16 16 0 0 None

Joakim Plate (elupus) wrote :

Was abit unclear.. The above data is from Intrepid System with an X-Win32 Server

Here follows a glxinfo from the broken jaunty system with it's own local X Server (i skipped the OpenGL extensions as i'm very sure this is a GLX problem)

name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group

Joakim Plate (elupus) wrote :

Actually looking at this i think I know the problem.. The older server doesn't support GLX_SGIX_fbconfig..

Could the fallback to older methods in jaunty be broken?

Joakim Plate (elupus) on 2009-07-17
affects: ubuntu → mesa (Ubuntu)
James Willcox (snorp) wrote :

I can confirm the same behavior with Leopard 10.5.7. Very annoying :/

Joakim Plate (elupus) wrote :

Nice to know i'm not alone. I wonder if this is a Ubuntu specific problem. Perhaps it should be reported upstream?

Bryce Harrington (bryce) wrote :

Can you reproduce it on Karmic? If so, we may be able to send it upstream.

Changed in mesa (Ubuntu):
status: New → Incomplete
Joakim Plate (elupus) wrote :

I've reproduced same thing on Karmic. Identical issue.

Bryce Harrington (bryce) wrote :

Thank you for verifying it still occurs on Karmic. Please execute the following command in a terminal after reproducing the issue, and it it will automatically gather debugging information needed for forwarding this bug upstream:

  apport-collect 384001

(You may need to install the python-launchpadlib package from the universe repository. Additionally, when prompted to give apport-collect permissions for Launchpad you will need to give it at least the ability to "Change Non-Private" data as it will be adding information to your bug report.)

Changed in mesa (Ubuntu):
status: Incomplete → New
status: New → Incomplete

Architecture: i386
DistroRelease: Ubuntu 9.10
MachineType: AOpen i965GMx-IF
Package: mesa (not installed)
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-8-generic root=UUID=0f9b4a48-eec1-46c2-a350-078a0eed0034 ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=en_US.UTF-8
ProcVersionSignature: Ubuntu 2.6.31-8.28-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090829.00413d87-0ubuntu0tormod2
 libdrm2 2.4.12+git20090825.ce6c68dc-0ubuntu0tormod3
 xserver-xorg-video-intel 2:2.8.1+git20090829.7c48c21b-0ubuntu0tormod
 xserver-xorg-video-ati 1:6.12.99+git20090829.39dfac41-0ubuntu0tormod
Uname: Linux 2.6.31-8-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 12/11/2007
dmi.bios.vendor: Phoenix Technologies, LTD
dmi.bios.version: 6.00 PG
dmi.board.name: i965GMx-IF
dmi.board.vendor: AOpen
dmi.board.version: 558EX10I690
dmi.chassis.type: 3
dmi.chassis.vendor: AOpen
dmi.chassis.version: i965GMx-IF
dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd12/11/2007:svnAOpen:pni965GMx-IF:pvrAO00001JW:rvnAOpen:rni965GMx-IF:rvr558EX10I690:cvnAOpen:ct3:cvri965GMx-IF:
dmi.product.name: i965GMx-IF
dmi.product.version: AO00001JW
dmi.sys.vendor: AOpen
fglrx: Not loaded
glxinfo:
 Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
 Error: couldn't find RGB GLX visual or fbconfig
 name of display: localhost:10.0
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.31-8-generic

Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Joakim Plate (elupus) wrote :
Changed in mesa (Ubuntu):
status: Incomplete → New
tags: added: apport-collected
Joakim Plate (elupus) wrote :

I ran that command from a ssh terminal that exhibited the problem, assume that is what you wanted?

Bryce Harrington (bryce) wrote :

Thanks

Changed in mesa (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Hiroki Nagai (nagai-hiroki) wrote :

I think I bumped into the same bug when conncecting freenx server on Jaunty from nx client elsewhere.

$ glxinfo -display :1001
name of display: :1001.0
Xlib: extension "Generic Event Extension" missing on display ":1001.0".
Error: couldn't find RGB GLX visual or fbconfig

$ xdpyinfo -display :1001 | grep GLX
    GLX
    SGI-GLX

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: mesa
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcVersion: Linux version 2.6.28-15-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009
Uname: Linux 2.6.28-15-generic i686
UserGroups:

XorgConf:

glxinfo:
 name of display: localhost:10.0
xkbcomp:

Bryce Harrington (bryce) on 2009-09-02
tags: added: jaunty
Bryce Harrington (bryce) on 2009-09-02
description: updated

If I ssh to a remote box, and I try to run 'glxinfo' on the remote system, it fails unless I explicitly force indirect mode via LIBGL_ALWAYS_INDIRECT.

The problem is that without LIBGL_ALWAYS_INDIRECT set, glx_direct gets set to true in glxext.c:

---
glx_direct = (getenv("LIBGL_ALWAYS_INDIRECT") == NULL);
glx_accel = (getenv("LIBGL_ALWAYS_SOFTWARE") == NULL);

   /*
    ** Initialize the direct rendering per display data and functions.
    ** Note: This _must_ be done before calling any other DRI routines
    ** (e.g., those called in AllocAndFetchScreenConfigs).
    */
   if (glx_direct && glx_accel) {
      dpyPriv->dri2Display = dri2CreateDisplay(dpy);
      dpyPriv->driDisplay = driCreateDisplay(dpy);
   }
   if (glx_direct)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);
---

Then in AllocAndFetchScreenConfigs(), we get our visuals and fbconfigs via:
      getVisualConfigs(dpy, priv, i);
      getFBConfigs(dpy, priv, i);

but then they get thrashed by:
      if (psc->driScreen == NULL && priv->driswDisplay)
         psc->driScreen = (*priv->driswDisplay->createScreen) (psc, i, priv);

which is driCreateScreen in drisw_glx.c and ends up doing:
   psc->configs = driConvertConfigs(psc->core, psc->configs, driver_configs);

which results in psc->configs being set to NULL which is causing GetGLXPrivScreenConfig to return GLX_BAD_VISUAL and thus causing glxinfo to bail.

glxinfo creates a context that allows direct rendering, and libGL is capable of doing direct rendering (through drisw). I think it is a reasonable behavior. To get indirect rendering, you can specify -i when executing glxinfo.

As for driConvertConfigs, it should not return NULL normally. It returns NULL when the original psc->configs and driver_configs have no config in common. Can you check what's in the original psc->configs?

You miss the point. This isn't about glxinfo, this is about *ALL* glx applications. glxinfo is just an example.

You said, "glxinfo creates a context that allows direct rendering" ... but direct rendering is not available because the client is remote from the server. In older versions of mesa (6.5 for sure, not sure through when), it would detect when remote and use indirect. This behavior seems to have reverted.

Now, when remote, it tries to use drisw, but it results in an empty set of visuals and fbconfigs as described by the codepath in my initial report.

I see your point. I guess the old behavior is simply because there was no swrast_dri.

As for swrast_dri, it has _direct_ access to the (pure software) OpenGL pipelines, and is thus chosen for direct rendering. The fact that xserver is remote is not taken into consideration. I am not sure which behavior is desired/correct though. Other people should have better answer than me.

The empty visual/fbconfig list you saw might be some other bug. That's why I would like to know the original value of psc->configs. I can run glxgears from a remote machine under "ssh -X" just fine, and it uses swrast_dri. My remote machine runs mesa 7.5.1.

Created attachment 29991
glxinfo.txt

Here's glxinfo's output when run as a local client.

numvisuals was 800 before calling into drisw to prune them, and it looks the same as the output from the remote host when forcing INDIRECT.

Created attachment 29992
no empy configs

Do you have a nvidia card on your local machine?

driConvertConfigs filters out any visual/fbconfig that has no matching DRI configs. It could be that nvidia report visuals/fbconfigs that none of them matches DRI configs (the matching rule is strict).

The patch (against git master) makes the conversion fail in such case and skips the failing DRI screen. It should hopefully skip swrast_dri in your case.

Can you help verify it? I don't have any machine with nvidia cards.

Yes, I have an nVidia card on this machine, but it also happens when I have an ATI card on the server machine. The vendor card information is abstracted away and we just query information straight from our OpenGL.framework, so the drivers are not directly involved.

Even if you had an nVidia card, that wouldn't help unless you were running OSX as well.

Can you tell me or point me to a spec that details the matching rule? We just generate a series of configurations based on the reported details from OpenGL.framework, but it's possible that we are missing a few or can add a few others for compatability with drisw

http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/GL/visualConfigs.c

I'll test the patch and let you know.

There is no spec on the rules. The visuals/fbconfigs reported by the server are converted to __GLcontextModes in mesa. You can have a look at driConfigEqual in src/glx/x11/dri_common.c.

I had a quick look at the link you gave. It might be maxPbufferWidth/maxPbufferHeight that fails the matching test. But there is no point to adjust the two fileds (maybe some others) only to pass the test.

Excellent. With that patch in place, we end up with AIGLX rather than erroring out. Looks good to me.

Any comment on the patch? IMO, the issue is a general one that can be seen on XQuartz and other non-DRI based X servers.

(In reply to comment #10)
> Any comment on the patch? IMO, the issue is a general one that can be seen on
> XQuartz and other non-DRI based X servers.

From my experience working on a similar problem with the Cygwin/X DDX, I think the real problem is that the config matching code expects to exactly match bindToTexture and maxPbuffer with a value of -1 (don't care), hence if these are actually set to report our capabilities, no configs remain after the attempt find the common configs.

Your patch to fall back to indirect if we can't find any common configs makes sense, but I don't actually think that should be happening.

(In reply to the bug title)

It's currently a policy in libGL to use swrast in preference to indirect, unless forced, and swrast is direct (Comment #3)

It would be nice if for Xservers which can only do indirect acceleration, there was a way to cause local clients to automatically use the indirect path, but I'm not sure how that could be done cleanly.

(In reply to comment #11)
>
> It would be nice if for Xservers which can only do indirect acceleration, there
> was a way to cause local clients to automatically use the indirect path, but
> I'm not sure how that could be done cleanly.

I might not be understanding the issue correctly, but you can build GLX to only support indirect rendering. Basically, the code needs to build without -DGLX_DIRECT_RENDERING. With configure, this is --disable-driglx-direct.

(In reply to comment #11)
> From my experience working on a similar problem with the Cygwin/X DDX, I think
> the real problem is that the config matching code expects to exactly match
> bindToTexture and maxPbuffer with a value of -1 (don't care), hence if these
> are actually set to report our capabilities, no configs remain after the
> attempt find the common configs.
> Your patch to fall back to indirect if we can't find any common configs makes
> sense, but I don't actually think that should be happening.
IMO, driConfigEqual is doing great. It should look for exact match. I think GLX_DONT_CARE is only assigned to those attributes that are not common to visual and fbconfig. It is so that driConfigEqual can work without caring a __GLcontextModes is from a visual or a fbconfig.

In the patch, driConvertConfigs fails only when _none_ of the configs reported by the server has a matching dri config. It should be quite safe. But I am also starting thinking that it should fail if _any_ of the configs reported by the server has no matching dri config...

> (In reply to the bug title)
> It's currently a policy in libGL to use swrast in preference to indirect,
> unless forced, and swrast is direct (Comment #3)
But only in some sense. It is hard to say which interpretation is desirable.

> It would be nice if for Xservers which can only do indirect acceleration, there
> was a way to cause local clients to automatically use the indirect path, but
> I'm not sure how that could be done cleanly.
A config runs with reduced performance when GLX_CONFIG_CAVEAT reports GLX_SLOW_CONFIG. It is not about direct or indirect though.

(In reply to comment #12)
> I might not be understanding the issue correctly, but you can build GLX to only
> support indirect rendering. Basically, the code needs to build without
> -DGLX_DIRECT_RENDERING. With configure, this is --disable-driglx-direct.
The question is, when libGL.so is compiled with direct rendering support, how to decide if direct rendering is viable at runtime? The connection to xserver may be remote or local. The configs from xserver and dri driver may or may not match. How do they affect the decision?

After upgrading to Ubuntu Jaunty 9.04 from Hardy remote glx rendering (over ssh or just network) against older servers is not working anymore. This is still a problem in current git (or atleast in current xorg-edgers repo)

I've tested against two X servers, verified from other sources:
X-Win32
Exceed (third party that I can't be 100% on it's validity)
Mac OSX Leopard X11 Server

All of which works fine on the same machine when rebooted into Hardy using older xorg stack

glxinfo outputs:
> name of display: localhost:10.0
> Xlib: extension "Generic Event Extension" missing on display "localhost:10.0".
> Error: couldn't find RGB GLX visual or fbconfig

xdpyinfo outputs that i have SGI-GLX and GLX extension.

I suspect that newer glx client side libs must be needing something not provided by the older servers.

I've reported this bug on launchpad "https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/384001" where also logs are available about the issue.

Though I'd take it upstream since that bug report seems to be stalled.

Changed in xorg-server:
status: Unknown → Confirmed

Thought i'd just mention that same bug occurs with nvidia binary drivers as x server, and jaunty/karmic as client.

I've mentioned it to nvidia, but since the bug is in the client, i suspect the best they can do is work around it for their own server.

Omer Akram (om26er) on 2010-02-01
Changed in mesa (Ubuntu):
status: Confirmed → Triaged

I too had this same error, but I found a workaround. Set the environment variable 'LIBGL_ALWAYS_INDIRECT=yes' and then try running the program.

Example: -
  administrator@artemis:~$ glxinfo
  name of display: localhost:11.0
  Error: couldn't find RGB GLX visual or fbconfig

  administrator@artemis:~$ LIBGL_ALWAYS_INDIRECT=yes glxinfo
  name of display: localhost:11.0
  display: localhost:11 screen: 0
  direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
  server glx vendor string: NVIDIA Corporation
  server glx version string: 1.4
  server glx extensions:
      GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig,
  ...
  ...
  ...

Works both through NX and SSH tunnelling.

Joakim Plate (elupus) wrote :

doesn't work here on jaunty. could your nvidia drivers i suppose. will test lucid when i get the time.

Joakim Plate (elupus) wrote :

tested on lucid, not working there either. X-Win32 server with lucid as the client over ssh.

(In reply to comment #14)
> The question is, when libGL.so is compiled with direct rendering support, how
> to decide if direct rendering is viable at runtime? The connection to xserver
> may be remote or local. The configs from xserver and dri driver may or may not
> match. How do they affect the decision?
>

I don't think there is a simple way to decide. One way to answer this is to change glxext.c from:

   if (glx_direct)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

to:

   if (glx_direct && !glx_accel)
      dpyPriv->driswDisplay = driswCreateDisplay(dpy);

and see if people complain :-(

It will mainly affect developers who usually explicitly set LIBGL_ALWAYS_SOFTWARE. Also wiki's won't have to be updated because they usually instruct people to set the envvar.

Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi elupus,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 384001

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 384001 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/384001

Changed in mesa (Ubuntu):
status: Triaged → Incomplete
tags: added: needs-retested-on-lucid-by-june
Joakim Plate (elupus) wrote :

Sure will do, tested it a while back on lucid beta 1 i think and was still and issue. Maybe all the backporting/reverting of xorg might have fixed it.

apport information

description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Joakim Plate (elupus) wrote :

glxinfo output identical to before..

name of display: localhost:10.0
Error: couldn't find RGB GLX visual or fbconfig

Bryce Harrington (bryce) on 2010-05-14
tags: added: karmic lucid

*** Bug 28415 has been marked as a duplicate of this bug. ***

Just wanted to add a note to confirm that this still exists under lucid.

Setting the LIBGL_ALWAYS_INDIRECT variable does work around this, both through remote X and neatx.

Another workaround I have found is to either remove or chmod 000 /usr/lib/dri/swrast_dri.so and /usr/lib32/dri/swrast_dri.so - it looks like neither of these existed on hardy. With these files inaccessible, glx apps work properly via remote X and neatx.

I hope this helps to narrow this one down...

Joakim Plate (elupus) wrote :

The LIBGL_ALWAYS_INDIRECT change does not work on jaunty atleast. But it didn't work on my previous test on lucid either. I still think that is only applicable for people that have nvidia binary drivers installed.

Changed in xorg-server:
importance: Unknown → Medium
Charlie Kravetz (charlie-tca) wrote :

Thank you for the supporting documents. Thanks also for confirming this issue in Ubuntu 10.04. There should be enough information for the developers to begin work to resolve this issue.

Changed in mesa (Ubuntu):
status: Incomplete → Confirmed

More users are complaining about this... ping...

1) To further document "lots of people affected by this" (and I'm well aware I haven't gotten off my posterior to fix this either):

SuSE brought this up last year[1] and ended up shipping with this patch[2] (a band-aid):

- if (glx_direct)
- dpyPriv->driswDisplay = driswCreateDisplay(dpy);
+// if (glx_direct)
+// dpyPriv->driswDisplay = driswCreateDisplay(dpy);

[1] http://<email address hidden>/msg06684.html
[2] https://bugzilla.novell.com/show_bug.cgi?id=469280

2) Bear in mind that making the visuals match exactly merely allows the software renderer to be used, it doesn't allow indirect GLX (check your GLX server strings carefully).

LIBGL_ALWAYS_INDIRECT is quite a pain, (more so for XDMCP sessions). In my experience client-side rendering is what most people want if the display is remote. If the network load is too heavy for client-side the render load will very likely be too heavy for the software rasterizer. (And apps can use display lists to alleviate the network load.)

Changed in xorg-server:
importance: Medium → Unknown
sebbu (sebbu) wrote :

The workaround (LIBGL_ALWAYS_INDIRECT=yes) works on ubuntu 10.04 (lucid) for my windows vista sp2 X server (XMing), as the log shows.

System is a fresh OVH installation, with xorg & glxgears just installed after apt-get update.

Changed in xorg-server:
importance: Unknown → Medium
Alasdair Allan (aa-astro) wrote :

Confirmed that this still affects Ubuntu 10.04 Server, forwarding onto a Mac OS X 10.6 system. However the

% setenv LIBGL_ALWAYS_INDIRECT yes

work around before running the affected application seems to resolve the problem.

Whereas direct rendering means that application can access the GPU hardware directly without communication with the X server first via Mesa, indirect rendering means that the GLX protocol will be used to transmit OpenGL commands and the X server will do the real drawing. Direct rendering is faster as it does not require change of context into X process of course, although in both cases rendering is done on the GPU if acceleration is present.

*** Bug 24590 has been marked as a duplicate of this bug. ***

Changed in xorg-server:
status: Confirmed → Invalid
Bryce Harrington (bryce) on 2011-11-15
Changed in xorg-server:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.