No 3D acceleration after reverting to open source radeon
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No 3D acceleration after reverting to open source radeon
After using AMD's proprietary fglrx driver I tried to revert to the radeon driver. But for some reason I can not get 3D rendering to work properly for my HD7750 card. This should not be too difficult, but I am at a loss. What am I missing???
What I did:
- uninstalled the fglrx driver using --uninstall=force
- removed /etc/X11/xorg.conf
- reinstalled mesa, libdrm and xorg-server
- reenabled drm/radeon in the kernel
- removed 'nomodeset' from lilo.conf
$ uname -a
Linux shpritsz 3.9.10 #1 SMP Tue Jul 16 23:00:14 CEST 2013 x86_64 AMD Phenom(tm) II X4 960T Processor AuthenticAMD GNU/Linux
$ lspci|grep VGA
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cape Verde PRO [Radeon HD 7700 Series]
$ zgrep RADEON /proc/config.gz
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_UMS is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
$ zgrep DRM /proc/config.gz
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_UMS is not set
..
$ grep WW /var/log/Xorg.0.log
[ 25.448] (WW) Falling back to old probe method for vesa
[ 25.448] (WW) Falling back to old probe method for modesetting
[ 25.544] (WW) RADEON(0): Direct rendering disabled
$ lsmod|grep radeon
drm 228451 4 ttm,drm_kms_helper,radeon
drm_kms_helper 27663 1 radeon
hwmon 1337 4 it87,k10temp,radeon,thermal_sys
i2c_algo_bit 5319 1 radeon
i2c_core 19663 6 drm,i2c_dev,i2c_piix4,drm_kms_helper,i2c_algo_bit,radeon
radeon 747346 2
ttm 61508 1 radeon
Let me know what else I could provide, I'm sure I forgot something.
Just going on memory, you should have somethiong in there about the video driver. It's loading ati (??), radeon (good) fbdev(bad) & vesa(bad). The first one that says "Uh, I can handle this" gets to drive your video. I have a box with (ancient)OSS ati stuff and you need
driver=radeon
when describing the card. Radeon actually loads r600 or r700 or somesuch, but it's all good. Where you had 'driver=fglrx' you now need 'driver=radeon'
Also check here
ls -l /usr/lib(64)/libGL*
and see if files like libGL.so are pointing at a Mesa version or an ATI version number.
It seems that Mesa in Slackware current is not compiled with the Gallium3D radeonsi driver, which is needed for the HD7000 and HD8000 series.
You need to recompile Mesa, change the line
Then rebuilt the packe and use upgradepkg to install the new one. After that 3D acceleration should work, but since those newer chips do 2D acceleration using the GLAMOR framework I don't know if you will get proper 2D acceleration.
I will have to look into that, since it seems GLAMOR can also be used on my HD6870, but for know I can't help with that.
@TobiSGD:
I tried to rebuild mesa as per your suggestion, which should be straight forward, but there seems to be more to it. With radeonsi added, the build script fails and installs in /usr/local/lib (instead of /usr/lib64/ and /usr/lib64/xorg/modules). It seems to ignore the configure options, even when providing them on the command line. To be sure, I tried to build mesa without modifying the Slackbuild and then it works fine.
Does radeonsi depend on glamor-egl? Will continue with this tomorrow.
Looking at the Xorg.0.log, TobiSGD seems onto it. If that trail peters out, google for the errors here.
Quote:
bash-4.2$ grep AIGLX Xorg.0.log
[ 25.423] (==) AIGLX enabled
[ 25.553] (II) AIGLX: Screen 0 is not DRI2 capable
[ 25.553] (II) AIGLX: Screen 0 is not DRI capable
[ 25.582] (II) AIGLX: Loaded and initialized swrast
First I rebuilt llvm-3.3 with --enable-experimental-targets=R600, which seemed to work:
Code:
$ grep -i targets /tmp/llvm-3.3.src/config.log
TARGETS_TO_BUILD='R600 X86 Sparc PowerPC AArch64 ARM Mips XCore MSP430 CppBackend MBlaze NVPTX Hexagon SystemZ'
Then I rebuilt mesa-9.1.4 with radeonsi added to the gallium-drivers, but had to add a patch from LFS (MesaLib-9.1.4-llvm_fixes-1.patch; see attachment)
Also added the following to the configure options (I removed some of the gallium-drivers to speed up the build):
I did not add --enable-openvg and --enable-opencl (as per this thread) since openvg and opencl are not (yet) installed on my system. Mind you, I have no idea what I am doing here, I just excluded them and then the build succeeded.
That's where I got stuck. Apparently something is up with llvm.
I thought of rebuilding xf86-video-ati with --enable-glamor, but do not know how to modify the X11 build script. I am sure some one will come along to tell me how to do that.
Other things I have not yet tested are upgrading to the latest mesa-9.1.5 and xorg-server-1.14, and installing openvg and opencl. But I'd appreciate to get some pointers before the whole thing grows over my head
All suggestions very welcome!
EDIT: upgrade to mesa-9.1.5 and xorg-1.14 (packages from testing) give the same segfault.
My (weak) understanding was that llvm was only needed on really crappy (early) cards. I have an rs600 in a laptop - that benefits from llvm (theoretically, anyhow), because it has basically no vertex shader (whatever THAT is). I also have a HD4650, but that did not benefit.
If you don't get answers try phoronix.com forums, because the developers hang out there.
I upgraded to X11 1.14 (from /testing) and mesa-9.2 from git, which required an upgrade of libdrm ≥2.4.46.
And YES, this gets radeonsi loaded without segfault!
Code:
$ glxinfo |grep -i render
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE
BUT still something is missing because GL graphics display is corrupted. See attached screenshot.
Could that have something to do with this?:
Code:
$ grep -i accel /var/log/Xorg.0.log
[ 25.969] (II) Composite (RENDER acceleration)
[ 25.969] (II) RADEONSI(0): 2D Acceleration is disabled
[ 25.969] (--) RADEONSI(0): 3D Acceleration is enabled
[ 25.970] (WW) RADEONSI(0): Option "AccelMethod" is not used
You've updated libdrm, the X server, Mesa and Radeon drivers.
The only other thing that springs to mind to update is pixman. But when you update the X server, they usually bump the required versions on a lot of stuff. No harm to run ldconfig again, and then check the /usr/lib64/libGL* stuff that all the symlinks point to Mesa versions. I never trust uninstalls
You've updated libdrm, the X server, Mesa and Radeon drivers.
X server is not recompiled, just upgraded the packages. Would that suffice?
But now I have a more serious problem... to upgrade llvm to latest svn I messed up with the build script, resulting in a chown -R root:root /
I _think_ I ctrl-C'd out of it before an additional chmod got executed... I have restored ownership of stuff in /home and other personal files. Any of the system directories that I should worry about?
EDIT: using this smprms script I restored non root.root ownership. Let's hope this will do.
EDIT2: just a note for those who want to use this restore script: in my case it didn't work nicely with file names containing a dash '-'. The dash was left out in the file list it created.
X server is not recompiled, just upgraded the packages. Would that suffice?
But now I have a more serious problem... to upgrade llvm to latest svn I messed up with the build script, resulting in a chown -R root:root /
I _think_ I ctrl-C'd out of it before an additional chmod got executed... I have restored ownership of stuff in /home and other personal files. Any of the system directories that I should worry about?
EDIT: using this smprms script I restored non root.root ownership. Let's hope this will do.
Most stuff is root:root. /var/spool/mail/* is all different. If you're running servers (postfix, qmail, etc.) there will be issues. /dev may have to redone from scratch. Otherwise, you should be ok.
If you upgraded the packages, it depends on your package. Slackwrare - you may have issues as there is no dependency tracking. RPMs generally puke and refuse if the dependencies aren't right.
If you're worried, go around trying this on things
ldd /path/to/file |grep found
It lists the libs used and then checks them for ones marked "not found" The correct output is NO output. If you don't believe me, just check without the |grep command
I think Driver should be radeon not radeonsi. radeonsi is using the xorg state tracker, which is not really working.
The radeon driver is used for all radeon cards including the new HD7000+ cards with the glamor acceleration.
You may want to consort these pages for information regarding how to get "radeonsi" working fully. These are from the current "Beyond Linux From Scratch" book.
You will need to download and install Glamor-EGL from the x11 driver page and possibly build, patch, and install it by hand.
Apparently there are parts of X that need to be rebuilt to support the "glamoregl" driver as well as other portions with libmesa also such, as is this flag for the xf86-video-ati DRI driver.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.