Bug 89823

Summary:	[swrast] driver loads but complains then fails to work in Piglit which shows GLSL message
Product:	Mesa	Reporter:	Dan Sebald <daniel.sebald>
Component:	Other	Assignee:	mesa-dev
Status:	RESOLVED INVALID	QA Contact:	mesa-dev
Severity:	normal
Priority:	medium	Keywords:	regression
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Dan Sebald 2015-03-30 08:35:15 UTC

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.

Comment 1 Kai 2015-03-30 10:51:09 UTC

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

Comment 2 Timothy Arceri 2015-03-30 21:24:39 UTC

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

Comment 3 Dan Sebald 2015-03-30 23:04:00 UTC

[@ 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.