Bug 90817 - swrast fails to load with certain remote X servers
Summary: swrast fails to load with certain remote X servers
Status: REOPENED
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: 10.5
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-02 13:16 UTC by Tom Hughes
Modified: 2015-07-23 19:58 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output of glxinfo run locally on the X server (21.11 KB, text/plain)
2015-06-02 13:17 UTC, Tom Hughes
Details
Output of glxinfo run remotely without patch (21.58 KB, text/plain)
2015-06-02 13:17 UTC, Tom Hughes
Details
Patch to loosen checking of visuals (3.04 KB, patch)
2015-06-02 13:19 UTC, Tom Hughes
Details | Splinter Review
Output of glxinfo run remotely with patch (10.41 KB, text/plain)
2015-06-02 13:19 UTC, Tom Hughes
Details
Patch to loosen checking of visuals (2.95 KB, patch)
2015-06-28 18:46 UTC, Tom Hughes
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Hughes 2015-06-02 13:16:52 UTC
When using a remote X connection to an older machine using NVidia drivers (not Nouveau) the swrast driver fails to load and indirect rendering is used instead which is very slow in some applications. The error reported is:

  libGL error: No matching fbConfigs or visuals found
  libGL error: failed to load driver: swrast

After doing some debugging it appears that the problem is that mesa is deciding that none of the GLX visuals offered by the server are compatible with any of the modes supported by swrast but I suspect it is being rather more strict than is necessary so that, for example, the fact that all the server visuals advertise support for a pbuffer and none of the swrast visuals include one cause all matches to fail.

I am attaching the output of glxinfo run locally on the server machine, and run remotely with swrast failing to load.

I am also attaching a patch that I made to relax some of the tests, which enables at last some visual to match, along with the output of glxinfo from the remote machine with the patch applied.
Comment 1 Tom Hughes 2015-06-02 13:17:28 UTC
Created attachment 116240 [details]
Output of glxinfo run locally on the X server
Comment 2 Tom Hughes 2015-06-02 13:17:49 UTC
Created attachment 116241 [details]
Output of glxinfo run remotely without patch
Comment 3 Tom Hughes 2015-06-02 13:19:10 UTC
Created attachment 116242 [details] [review]
Patch to loosen checking of visuals
Comment 4 Tom Hughes 2015-06-02 13:19:37 UTC
Created attachment 116243 [details]
Output of glxinfo run remotely with patch
Comment 5 Jon Turney 2015-06-27 12:18:35 UTC
Something like this is also needed when the server is XWin on Cygwin/MinGW using WGL, where the set of fbConfigs comes from the native driver and don't match swrast's expectations.
Comment 6 Jose Fonseca 2015-06-28 12:34:52 UTC
I too have been bit with SW rast problems.  Even with local X server, when using e.g., NVIDIA proprietary drivers.

Concerning the patch, a few comments:

- the change for the __DRI_ATTRIB_BIND_TO_TEXTURE_TARGETS case looks alright

- for the other cases you need to take in consideration GLX_DONT_CARE

- you should make helpers (like scalarEqual), instead of repeating the same code on multiple cases; or at least you should collapse multiple cases together

- please post to mesa3d-dev , so people more familiar with the code comment.
Comment 7 Tom Hughes 2015-06-28 18:17:26 UTC
Happy to try and improve the patch.

I admit to having been a bit confused by the whole GLX_DONT_CARE thing when I was originally looking at this though because as I understand it config represents a set of capabilities being advertised by the server and I don't understand what it means for the server not to care - presumably that means it's happy to support any value of that feature that the client chooses to use?
Comment 8 Tom Hughes 2015-06-28 18:46:47 UTC
Created attachment 116768 [details] [review]
Patch to loosen checking of visuals

Here's an updated patch that attempts to address those comments.
Comment 9 Tom Hughes 2015-06-28 19:39:06 UTC
I just looked, and there doesn't seem to be a mesa3d-dev list - did you mean mesa-dev? This bug is assigned there anyway, so presumably they are seeing all these comments...
Comment 10 Jose Fonseca 2015-07-23 15:01:06 UTC
Fix pushed as f3728a16c9c6a02fc1f44b8069b0060e2358f22e. Thanks.
Comment 11 Jose Fonseca 2015-07-23 19:58:24 UTC
It looks there were some problems with the patch.  Reopening.


bug/show.html.tmpl processed on Jan 24, 2017 at 07:04:20.
(provided by the Example extension).