No direct rendering (DRI) with Catalyst / fglrx on 14.1
 

Did a clean install of 14.1 (64-bit). My video card is a Radeon HD 7750. I could run glxgears or glxinfo and see that I had direct rendering, but wanted to see if the catalyst drivers would be better.

I knew from other threads that Catalyst 13.4 wouldn't work, so I downloaded the 13.11.b6 beta version. That built fine, even without creating the link recommended by Matt here.

However, when I try to run glxgears, glxinfo, fglxrinfo, etc., I can see that Im no longer getting direct rendering, and complaints about not being able to load swrast. Adding LIBGL_DEBUG=verbose to the command line adds the information I haven't found anything (yet) that says my card with the combination of 14.1 can't do direct rendering using catalyst, so any ideas?

FWIW, my monitors are old Princeton Graphics DPP 800's. One is connected to the DisplayPort output on the 7750 via an adapter, the second is connected to the DVI output.

1. Check and see if you Blacklisted the default kernel radeon module in the file /etc/modprobe.d/blacklist. You may need to add the line:

2. Check and see if your xorg.conf in /etc/X11 has the fglrx xorg module specified in the driver section. (Note: although you can run xorg without an xorg.conf file, with proprietary drivers it is still recommended you have this file regardless.) Running aticonfig --initial should have created this file for you.

Did the blacklisting by creating the file /etc/modprobe.d/radeon-blacklist.conf and blacklisted both radeon and radeonhd (just to be sure). Without the blacklist, X wouldn't even start with catalyst.

Strictly speaking, the aticonfig command didn't create a "Driver" section. It did create the "Device" sections which included a "Driver" line, though. My full aticonfig command was
Here's the xorg.conf file.

Those were the only parts that referenced fglrx.

One thing I haven't tried is setting nomodeset (to disable KMS) when I boot. Could that be an issue?

It shouldn't be using modeset if you have the radeon module disabled.

From my knowledge both fglrx and nvidia proprietary drivers don't use modesetting.

Also, are you using a dual-monitor setup? You should only use a single monitor during configuration, then add the second monitor through the Catalyst controls.

I know the 13.4 drivers are the official drivers while the 13.11s are BETA for these cards, but did you make any attempt prior to this to use the default xorg ati driver?

Please show us your /var/log/Xorg.0.log file and the output of 'dmesg'.

Adam

Xorg.0.log and output of dmesg.

I don't see anything in that log file that suggests any problem related to direct rendering... Which is odd.

Can you attach the full output of "LIBGL_DEBUG=verbose glxinfo"

Adam

Wait... are you using X11 as root or as a user?

If you are running as user, edit your /etc/X11/xorg.conf file and place this at the end of the file:

And then restart X11.

If you are running as root... we may need further details as to how you set up your system possibly.

Just curious, but could you please post your entire /etc/X11/xorg.conf file here so I may see it please?

First, the output of LIBGL_DEBUG=verbose glxinfo

Second, current xorg.conf:
(This was created by first deleting old xorg.conf, running "aticonfig --initial" with no dual head options, then using Catalyst Control Center ("amdcccle" run as su) to change from a cloned display, and finally manually adding the DRI section. Note that after each step - aticonfig, amdcccle, editing xorg.conf - I rebooted and checked both glxinfo and fglrxinfo, with no changes in their output.)

Should probably also note that /usr/lib64/xorg/modules/dri/swrast_dri.so exists. The "ls -l" out put is:
Also, when ever possible, I'm running as an ordinary user. When I need elevated privledges, I open a terminal window and use "su".

Does your xorg.conf have this, or anything like this, anywhere listed?

There is a Module section; it is right after the ServerLayout section. It is empty.

I added the modules listed and restarted X to see if they made a difference. They didn't.

Can you get acceleration as root?

Have you possibly added your user account to the video group?

Method of installation?
 

I had the same issue, normally I always install the Catalyst drivers by creating a slackware package however when installing using the normal method (ncurses menu, not making a package) it did work.

Please show the output of 'ldd /usr/bin/glxinfo' and then run ldd on the libGL.so file that it links against and show that output here as well. I suspect you are not using the fglrx GL library.

Adam

If the libmesa libGL.so and it's symlinks aren't replaced by the fglrx libGL.so, as well as the symlinks, it won't work at all.

Might be partway to an answer.

When the stock mesa package is installed, it links libGL.so and libGL.so.1 to libGL.so.1.2.0

When the fglrx package is installed, it installs its libGL as libGL.so.1.2 and relinks libGL.so and libGL.so.1 to the new libGL.so.1.2, leaving the original libGL.so.1.2.0 alone with nothing linked to it.

Upon a reboot, something is relinking libGL.so.1 back to the original libGL.so.1.2.0, causing the mismatch Adam suspected. If I manually link libGL.so.1 to libGL.so.1.2, everything works until the next boot/reboot.

Now the question is: what is changing the link during boot?

More than likely it was a callback feature trying to set a dependency link for a file that was a redundant symlink against itself.

What he could do is rename the fglrx installed libGL.so.1.2 to fglrx-libGL.so and create symlinks for libGL.so, libGL.so.1.2.0, libGL.so.1, libGL.so.1.2

Easily done as this with a script set both prior to install of fglrx drivers and post-install:

Run before installing fglrx.

The run post-install of fglrx.

This will dedicate the AMD fglrx libGL.so to it's own library as fglrx-libGL.so and then libmesa's libGL.so will be backed up.

Didn't really work. (I'm assuming you weren't suggesting reloading my entire system.)

I removed the fglrx package and reinstalled the mesa package.

I then entered the following command:
and got
Did
and installed the fglrx package.

After the install, my ls command returned
Did

then rebooted.

After reboot

returned

None of the other links were changed. I renamed the mesa libGL several times. As long as it had the first three letters of the name as "lib" and ended in a number (I tried libdokkalf.so.1, libdokkalf.so.1.2, and libdokkalf.so.1.2.0), after a reboot libGL.so.1 would automagically point to the new name. Renaming the mesa libGL to an improper name like FGL.renamed.libGL.so.1.2.0 and setting libGL.so.1 to point at libGL.so.1.2 would the link remain after a reboot.

At this point, I suspect the original problem is with the fglrx doinst.sh script not properly renaming libGL.so.1.2.0, but I still don't understand what keeps changing the libGL.so.1 link.

I have this same problem on my hd 7850. I would suggest you edit your /etc/rc.d/rc.local to have the line That way next time you boot it will automatically link the two files mentioned. Next time you reboot run glxinfo just to check (this worked for me). Still don't know what causes this to become undone but here at least you don't have to execute it every time you start.