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.
Created attachment 116240 [details] Output of glxinfo run locally on the X server
Created attachment 116241 [details] Output of glxinfo run remotely without patch
Created attachment 116242 [details] [review] Patch to loosen checking of visuals
Created attachment 116243 [details] Output of glxinfo run remotely with patch
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.
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.
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?
Created attachment 116768 [details] [review] Patch to loosen checking of visuals Here's an updated patch that attempts to address those comments.
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...
Fix pushed as f3728a16c9c6a02fc1f44b8069b0060e2358f22e. Thanks.
It looks there were some problems with the patch. Reopening.
See also https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1648
-- 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.