I was working on a legacy swrast changeset based off of this change point: ----- commit 27bf37ba05b69ebf6f373d1637a26b4839265921 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Mon Mar 16 15:08:04 2015 -0700 nir/peephole_select: Allow uniform/input loads and load_const Shader-db results on HSW: ----- and was able to run tests on Piglit. I then updated my local repository to the latest canonical head ----- commit d64adc3a79e419062432cfa8d1cbc437676a3fbd Author: Michel Dänzer <michel.daenzer@amd.com> Date: Thu Mar 26 11:32:59 2015 +0900 radeonsi: Cache LLVMTargetMachineRef in context instead of in screen Fixes a crash in genymotion with several threads compiling shaders concurrently. ----- and although things compiled as normal, I began seeing the following: [@ piglit]$ LD_LIBRARY_PATH=/home/sebald/local/lib:/usr/local/lib64 bin/gl-1.0-pixelzoom libGL error: unable to load driver: nouveau_dri.so libGL error: driver pointer missing libGL error: failed to load driver: nouveau libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast GLSL not supported. PIGLIT: {"result": "skip" } in which the messages about swrast_dri.so and swrast are new. The message "GLSL not supported." is also new. When I use the compiled swrast_dri.so driver in an application I see the same messages above sans the "GLSL not supported." message. The application does graphics, but exactly what it is using I'm not sure if swrast is purportedly unable to load. I looked through the changeset entries for something suspicious, but I'm not knowledgeable enough about the organization of the code and there were 50+ changesets in the past week or so.
This sounds like a regression, the normal response here is: can you bisect? (Also make sure you build in a clean environment, sometimes left-overs from previous runs can wreak havoc.)
Looks like no driver is loaded. Try using LIBGL_DEBUG=verbose it should tell you where your system is looking to load them from. For example: $ LIBGL_DEBUG=verbose glxinfo | grep direct
[@ mesa]$ LIBGL_DEBUG=verbose glxinfo | grep direct libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so libGL error: dlopen /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: nouveau_dri.so libGL error: driver pointer missing libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so direct rendering: Yes The "direct" appears in red font. Well, that does look like whatever is attempting to load the driver (more below) is searching in the wrong place (or not, don't know). So thanks. I would delete the one in /usr/lib64/dri (would have helped me realize why the driver isn't working), but I don't want to potentially make other applications have problems. I am right in the middle of bisecting the git repository. I've found I have to wipe the repository clean and reclone (then repeat the bisect) before building. "make clean" alone doesn't seem to cause the problem once a working build is done... OK, done. The end of the bisect process appears below, but I think this may be operator error. After seeing the changeset summary and diff hunks I thought to reinstall the build because this is the context/dispatch level. The Piglit tests worked after the install. I was probably running an up-to-date driver build with an old "context core", for lack of better phrase, i.e., incompatible. Please close the bug report. git bisect bad 4bdbb588a9d385509f9168e38bfdb76952ba469c is the first bad commit commit 4bdbb588a9d385509f9168e38bfdb76952ba469c Author: Brian Paul <brianp@vmware.com> Date: Fri Mar 13 11:43:44 2015 -0600 mesa: reimplement dispatch table no-op function handling [snip] :040000 040000 777bdcea2e079fba557c2d366394231415bf807b 554fed5df2816d6eb3c024bec6e27fe69ac1a492 M src
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.