I run: LIBGL_DEBUG=verbose glxinfo a number of lines such as this are reported: libGL: OpenDriver: trying /usr/lib32/dri/fglrx_dri.so _NO_ 64-bit libraries are on the search path; i.e. there is _NO_ attempt to load fglrx_dri.so from /usr/lib64/dri. As a result, direct rendering is disabled and 3d performance is nonexistent. I symlinked /usr/lib64/dri/fglrx_dri.so to /usr/lib32/dri/fglrx_dri.so as a test. X can now find and load the module, and I get > 10,000 fps from glxgears. _Big_ difference. It appears that there is a bug somewhere that prevents X from searching the 64-bit library paths when trying to load fglrx. Reproducible: Always
Which ati-drivers version is this about?
x11-drivers/ati-drivers-8.34.8 . I know this is in the experimental branch, but previous driver versions dp not build on my system.
*** Bug 173080 has been marked as a duplicate of this bug. ***
*** Bug 177735 has been marked as a duplicate of this bug. ***
Since my bug 177735 was marked as duplicate, note that this does not appear to be related to 32-bit vs. 64-bit with the 8.35.5 build of the ati-drivers. See: http://www.thinkwiki.org/wiki/Problems_with_fglrx#Perpetual_Mesa_GLX_Indirect_on_Debian
ati-drivers put the variable LIBGL_DRIVERS_PATH in these files (64 and 32 bits) /etc/env.d/04ati-dri-path-amd64 /etc/env.d/04ati-dri-path-x86 the problem is the LIBGL_DRIVERS_PATH value in i04ati-dri-path-amd64 is overwritten with 04ati-dri-path-x86. U can fix the problem deleting 04ati-dri-path-x86 or commenting the line in the file. PD: sorry for mi english.
(In reply to comment #6) > ati-drivers put the variable LIBGL_DRIVERS_PATH in these files (64 and 32 bits) > > /etc/env.d/04ati-dri-path-amd64 > /etc/env.d/04ati-dri-path-x86 > > the problem is the LIBGL_DRIVERS_PATH value in i04ati-dri-path-amd64 is > overwritten with 04ati-dri-path-x86. Not if you use a sufficiently recent version of portage (for env-update) or eselect (for eselect env update). The variable is marked "colon-separated", meaning the entries *should* be joined in /etc/profile.env without overwriting each other. If this does not happen for you, please check if it still fails after rerunning env-update and/or upgrading eselect to latest ~arch (older versions of eselect had a bug here, and in some cases "eselect opengl ...." ends up running "eselect env update" for you, which breaks stuff if it's an older eselect). Removing the -x86 file will break accelerated opengl for 32 bit applications, so please try to find out what the actual problem is and fix that instead. People hitting this: please check if LIBGL_DRIVERS_PATH is set correctly (should have both the 32 and 64 bit libdirs in it). If it's not set correctly: tell me the contents of the env.d files installed by ati-drivers, and check if rerunning env-update (and sourcing /etc/profile afterwards) fixes things.
I'm confused by the previous postings, as they relate to this issue. In my previous comment #5, I link to a page which I followed. It suggested that I *add* /usr/X11R6/lib/modules/dri, and create a soft link: ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri >echo $LIBGL_DRIVERS_PATH /usr/lib/dri It is lost on me, then, as to why having a softlink in the folder /usr/X11R6/lib/dri works. Where is this path getting set, why is the driver using it? > set | grep X11 CONFIG_PROTECT='/usr/share/X11/xkb /usr/kde/3.5/share/config /usr/kde/3.5/env /usr/kde/3.5/shutdown /usr/share/config' e
(In reply to comment #8) > I'm confused by the previous postings, as they relate to this issue. In my > previous comment #5, I link to a page which I followed. That is the url " http://www.thinkwiki.org/wiki/Problems_with_fglrx#Perpetual_Mesa_GLX_Indirect_on_Debian" right? Did you notice the "Debian" in that url? The paths used by gentoo's Xorg install are quite different from the ones debian seems to be using, so if you add various symlinks that make some sense on a debian system you may end up causing *extremely* confusing bugs on a gentoo system. I would like you to remove all such symlinks before I spend any time trying to figure out what bug you are hitting. > It suggested that I > *add* /usr/X11R6/lib/modules/dri On recent systems gentoo does not have a /usr/X11R6, except possibly as a compatibility symlink to /usr. Please do not follow any instructions including /usr/X11R6 in paths: they do not apply to a current gentoo system. They may apply if the compatibility symlink is in place (which is not necessarily the case) or if you replace /usr/X11R6 with /usr by hand. > and create a soft link: > ln -s /usr/lib/dri/fglrx_dri.so /usr/X11R6/lib/modules/dri > > >echo $LIBGL_DRIVERS_PATH > /usr/lib/dri > > It is lost on me, then, as to why having a softlink in the folder > /usr/X11R6/lib/dri works. Where is this path getting set, why is the driver > using it? For x86 or other non-multilib systems: If you are using mesa libGL looks in /usr/lib/dri for drivers by default. If you are using ati's libGL it looks for drivers in /usr/X11R6/lib/modules/dri by default. As mentioned above /usr/X11R6 is a symlink to /usr if it exists, so the path becomes /usr/lib/modules/dri. It would be ugly, but you could create a symlink there and ati's libGL would find its drivers. On multilib systems (like amd64 systems) we have a problem. The 64 bit ati libGL looks for its drivers in /usr/X11R6/lib64/modules/dri, which collapses to /usr/lib64/modules/dri. The 32 bit ati libGL looks in /usr/X11R6/lib/modules/dri, so in /usr/lib/modules/dri. On some multilib systems lib64 and lib are different directories, former holding 64 bit libraries and latter 32 bit libraries. However on (at least recent) gentoo systems 32 bit libraries go in /usr/lib32 and /usr/lib and /usr/lib64 are the same thing (one a symlink to the other). So we cannot use the default location on amd64. Fortunately there is a way to override the search path: the env var LIBGL_DRIVERS_PATH overrides the location libGL looks for drivers. Both mesa and ati's libGL listen to this variable. So if we set it, we have to include the location mesa's drivers are installed, or mesa breaks. For simplicity ati-drivers sets it to *only* the location mesa searches, and installs ati's drivers there. Notice the above description relies on two things that are probably different on gentoo systems than on debian systems: /usr/X11R6 being absent or a symlink instead of a directory, and the multilib libdirs being lib32 vs lib64/lib instead of lib32/lib vs lib64. While throwing some weird symlinks in like you're doing may make things work on x86 or on amd64 in 64bit or 32bit mode only, the instructions for a non-gentoo system simply will not completely work, and they make it very hard for others to debug things. So *please* **please** do not do that. So again: - remove any extra links you added. - possibly remerge ati-drivers, if you're not sure what you added/removed. - eselect opengl set ati - env-update - log out and back in to make sure environment changes take effect Then tell me what still breaks.
(In reply to comment #7) > > Not if you use a sufficiently recent version of portage (for env-update) or > eselect (for eselect env update). The variable is marked "colon-separated", > meaning the entries *should* be joined in /etc/profile.env without overwriting > each other. If this does not happen for you, please check if it still fails > after rerunning env-update and/or upgrading eselect to latest ~arch (older > versions of eselect had a bug here, and in some cases "eselect opengl ...." > ends up running "eselect env update" for you, which breaks stuff if it's an > older eselect). > > Removing the -x86 file will break accelerated opengl for 32 bit applications, > so please try to find out what the actual problem is and fix that instead. > > People hitting this: please check if LIBGL_DRIVERS_PATH is set correctly > (should have both the 32 and 64 bit libdirs in it). If it's not set correctly: > tell me the contents of the env.d files installed by ati-drivers, and check if > rerunning env-update (and sourcing /etc/profile afterwards) fixes things. > Yep, upgrading from 1.0.7 to eselect 1.0.9 fixed the variable, now the variable points to both paths LIBGL_DRIVERS_PATH="/usr/lib64/dri:/usr/lib32/dri"
I offer my humble apologies. I am unclear on what exactly I changed on my system, but I undid the changes that I wrought as per comment #5 and comment #8, and my system seems to be behaving correctly. It appears that I may have been confusing myself with using a bash shell via sudo inside of an existing X session. In such cases, it fails to connect to the drivers, and depending on which tool you're using doesn't report that failure, but rather just reports "direct rendering" No. Removing myself on CC list.
I'm not sure what has changed, but in the time since I reported this bug it has been fixed. At least on my system. Because of a few issues, I ended up reinstalling my system with Gentoo 2007.0 and using the new 8.35.5 driver release. Everything appears to be functional at this point, no ugly hacks required. Good job! I'll leave this bug open for now in case some people are still having issues, but I think it is resolved and should probably be closed.
I'm closing this, reopen if this is still an issue after the following steps (repeating myself for people who find this later with a bugs search) - remove any symlinks and other hacks you added manually - eselect opengl set ati - env-update (should not be required if you're on 1.0.9 eselect, but never hurts) - log out and back in
