Bug 90817

Summary:	swrast fails to load with certain remote X servers
Product:	Mesa	Reporter:	Tom Hughes <tom>
Component:	GLX	Assignee:	mesa-dev
Status:	RESOLVED MOVED	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	CC:	jfonseca, jon.turney, maraeo
Version:	10.5
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Output of glxinfo run locally on the X server Output of glxinfo run remotely without patch Patch to loosen checking of visuals Output of glxinfo run remotely with patch Patch to loosen checking of visuals

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.

Comment 12 Adam Jackson 2019-08-12 17:17:43 UTC

See also https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1648

Comment 13 GitLab Migration User 2019-09-18 17:45:05 UTC

-- 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/99.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.