Created attachment 60103 [details] glxinfo output with latest mesa. Starting from 8.0 Mesa is not uses videocard for OpenGL acceleration, although everything in logs shows that hardware is used. For now I've switched even to git versions of X.org consolidation, radeon, libdri, mesa and still no luck. Also, for some unknown reason, but mesa won't respect LIBGL_DEBUG env vars Here is my kernel log, glxinfo and Xorg.log:
Created attachment 60104 [details] Xorg log when using r600g driver
Created attachment 60105 [details] Kernel log
Created attachment 60106 [details] Kernel configuration I'm using.
I can confirm that this affects r300 based devices (FireGL X1) as well on ia64. Downgrading to Mesa 7.11.2 fixed the issue.
You are using the xorg state tracker rather than xf86-video-ati. Do things work correctly with xf86-video-ati? Why are you using the xorg state tracker?
(In reply to comment #5) > You are using the xorg state tracker rather than xf86-video-ati. Do things > work correctly with xf86-video-ati? Why are you using the xorg state tracker? Because xf86-video-ati won't works nice for me, I have obscure mouse cursor issue and even worse performance (5FPS in glxgears comparing to 20FPS with state tracker driver).
I've noticed different defines on 7.11.2 version and git from autogen.sh script: For example -D for glsl_lexer : 8-git -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DFEATURE_GL=1 glsl_lexer.o 7.11: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -DHAVE_LIBUDEV -DFEATURE_GL=1 -fvisibility=hidden -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -DHAVE_LIBUDEV -DFEATURE_GL=1 Maybe absense of USE_XSHM is evil issue ?
According to glxinfo and the related discussion on IRC, you're using the standalone software rendering libGL.so.1, which can't use hardware acceleration and doesn't know about LIBGL_DEBUG. You'll need to sort this out with folks knowledgeable about Gentoo. (In reply to comment #6) > Because xf86-video-ati won't works nice for me, I have obscure mouse cursor > issue [...] Now, that might warrant a bug report.
Dear Michel, looks like you didnt followed IRC discussion closely, especially today one. I've did even clean building of mesa with installation to /opt (according to wiki article in /topic of IRC channel) and the problem is still there. So please reopen bug.
As long as glxinfo says OpenGL renderer string: Mesa X11 my analysis stands.
That's why I opened that issue. Reverting mesa to 7.11 solves that.
what Michael said stands, you are using a libGL built for X11 sw rendering, nothing else you can do except fix the libGL build will affect this bug.
you'd need to attach a full build log with configure stage to see why.
Created attachment 60205 [details] Build and use log of latest mesa-git for Michel
I've published information, requested by Michel. Here is configure, build and some tests log in one file. I hope this time he won't be so fast on closing bugs :)
This is a real bug in Mesa's configure script. If you read carefully you'll notice there's no way to actually set default_driver in configure.ac, which means architectures that aren't officially blessed for DRI end up with the xlib version of libGL. There's a workaround for this in the Fedora spec file: sed -i 's/^default_driver.*$/default_driver="dri"/' configure.ac But the configure script should be fixed.
After configure.ac patch (which is now in mesa-git) I can confirm that 3D acceleration working again, also, for some reason LIBGL_DEBUG env var is respected and works as intended. So, probably it works only with DRI built libGL.
(In reply to comment #15) > I've published information, requested by Michel. I think you mean Dave, but in the future please include this kind of information in bug reports right away. (In reply to comment #16) > This is a real bug in Mesa's configure script. Yeah, sorry I jumped the gun here. > [...] there's no way to actually set default_driver in configure.ac, which > means architectures that aren't officially blessed for DRI end up with the xlib > version of libGL. I wonder if it wouldn't be better to blacklist architectures where DRI really can't work instead, if there are any. Anyway, Dave pushed a fix for this particular problem, so resolving as fixed. (In reply to comment #17) > [...] for some reason LIBGL_DEBUG env var is respected and works as intended. > So, probably it works only with DRI built libGL. Yeah, I said so in comment #8.
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.