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 [details]
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 [details] [review]
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?

(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.

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

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://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/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.)

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

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/57.