Originally posted by Ruse
View Post
Announcement
Collapse
No announcement yet.
How To Setup Radeon DPM On Ubuntu Linux
Collapse
X
-
under test on Debian Jessie
hi all,
I've just installed the kernel 3.11 that just landed in unstable. I activated the DPM using radeon.dpm=1 option on the kernel command line.
How can I check it is working ? I have nothing special on my syslog, and all /sys/ stuffs about the radeon have nothing that talks to me...
regards
Comment
-
Originally posted by jery View Posthi all,
I've just installed the kernel 3.11 that just landed in unstable. I activated the DPM using radeon.dpm=1 option on the kernel command line.
How can I check it is working ? I have nothing special on my syslog, and all /sys/ stuffs about the radeon have nothing that talks to me...
regards
Code:[drm] radeon: dpm initialized
Copy all files from here:
and put them in the /lib/firmware/radeon directory if you dont have them in a separately installed firmware package already.
Some info here:
Comment
-
Originally posted by gradinaruvasile View PostCheck dmesg for this line:
Code:[drm] radeon: dpm initialized
Copy all files from here:
and put them in the /lib/firmware/radeon directory if you dont have them in a separately installed firmware package already.
Some info here:
http://www.phoronix.com/scan.php?pag...tem&px=MTQyNDE
I already updated the microcode. The nonfree firmware package already contains the latest microcode.
I'll check this trace in dmesg.
Comment
-
Originally posted by jery View Posthi all,
I've just installed the kernel 3.11 that just landed in unstable. I activated the DPM using radeon.dpm=1 option on the kernel command line.
How can I check it is working ? I have nothing special on my syslog, and all /sys/ stuffs about the radeon have nothing that talks to me...
regards
For example, current Debian Testing has completely outdated 3.10 and radeon 2.33, the driver is 1,5 years old -> I get GPU hangs when I try to use 3D with default Debian packages.
3.11 also is very very old, a lot of DPM fixes landed in 3.12 drm-next. You risk to get very bad experience if you rely on Debian unstable, more over - your bug reports will have little value as possible issues might already be ressolved upstream.
Comment
-
Originally posted by brosis View PostI highly recommend you to compile your own kernel, MESA, ucode and radeon instead of using Debian packages.
For example, current Debian Testing has completely outdated 3.10 and radeon 2.33, the driver is 1,5 years old -> I get GPU hangs when I try to use 3D with default Debian packages.
3.11 also is very very old, a lot of DPM fixes landed in 3.12 drm-next. You risk to get very bad experience if you rely on Debian unstable, more over - your bug reports will have little value as possible issues might already be ressolved upstream.
Well anyway I'm not the only user of this computer so I can't break the installation too often...
And I never find a proper doc on building mesa with multiarch support !
I don't get why you say the radon driver is 2.33... I have a 7.2.0 package of xserver-xorg-video-ati.
And I don't have any hang... I just have not enough 3d frames to play the few games I play (Civ5 and WoT unde wine, a few steam games natively).Last edited by jery; 23 October 2013, 03:50 AM.
Comment
-
Originally posted by jery View PostYou're a bit rough against debian unstable packages ! They're not so old
Well anyway I'm not the only user of this computer so I can't break the installation too often...
And I never find a proper doc on building mesa with multiarch support !
I don't get why you say the radon driver is 2.33... I have a 7.2.0 package of xserver-xorg-video-ati.
And I don't have any hang... I just have not enough 3d frames to play the few games I play (Civ5 and WoT unde wine, a few steam games natively).
Multiarch mesa is really fun on Debian (NOT):
You need all the stuff you have for mesa, the i386 version installed and build with the forced CPP, CXX flags + the --enable-32-bit, --disable-64-bit flags, its quite that simple ONCE YOU SOLVED THE DAMN DEPENDENCIES:
The problem is that the debian -dev packages are mostly NOT multiarch capable on Debian: its because both amd64 and i386 versions contain the include file(s) which are identical btw. The libraries have no such issues, as they are stored in the arch-dependent lib subfolders.
The result is that you can install only one of them at once. I thrown in the towel and installed the amd64 versions and downloaded each needed 32 bit -dev package and just extracted them. Had no issues compiling.
My 32-bit configure options (really good idea to store them in a script) - note that it has LDFLAGS forced, its because for some reason the compiler wanted to use the 64 bit libs and i disabled llvm mainly because llvm isnt multiarch and im lazy to solve that as i dont see any real benefit of using it:
Code:#!/bin/bash ./autogen.sh --sysconfdir=/etc --prefix=/usr --libdir=/usr/lib/i386-linux-gnu --enable-debug \ CPPFLAGS="-m32" \ CXXFLAGS="-m32" \ LDFLAGS="-L/usr/lib/i386-linux-gnu -L/usr/lib" \ --disable-64-bit --enable-32-bit \ --enable-texture-float \ --with-gallium-drivers=r600,swrast \ --with-dri-drivers="" \ --enable-vdpau \ --enable-egl --enable-gles1 --enable-gles2 \ --enable-gallium-osmesa \ --enable-glx-tls \ --with-egl-platforms=x11,drm \ --enable-gbm \ --enable-gallium-egl \ --disable-gallium-llvm \ --enable-shared-glapi
I build the mesa deb packages with checkinstall (mesa32 for i386, because for some reason if i name both amd64 and i386 packages the same way, dpkg messes stuff up) - to circumvent the issues with files from the default system mesa packages (quite a few and cannot be uninstalled), i added all packages that my deb conflicted with to the "replaces" line - so the files in the new mesa packages will not be upgraded when a system mesa library is upgraded (because the second installed package that claims the files will keep them).
My deb creator script:
64-bit (i know i have certain i386 replaced packages, but it didnt work otherwise):
Code:#!/bin/bash fakeroot checkinstall --install=no --replaces libgles1-mesa:amd64,libgl1-mesa-dev,libglapi-mesa:amd64,libgles2-mesa:amd64,libgbm1:amd64,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:amd64,libgl1-mesa-glx:amd64,libegl1-mesa:amd64,libgl1-mesa-swx11:amd64,libegl1-mesa-drivers:amd64,libosmesa6-dev:amd64,mesa-common-dev --pkgname=mesa --pkgversion=10.0-dev-`git describe` --pkgarch=amd64 --backup=no
Code:#!/bin/bash fakeroot checkinstall --install=no --replaces libgles1-mesa:i386,libgl1-mesa-dev,libglapi-mesa:i386,libgles2-mesa:i386,libgbm1:i386,libegl1-mesa-dev,libgl1-mesa-dri:i386,libgl1-mesa-dri:i386,libgl1-mesa-glx:i386,libegl1-mesa:i386,libgl1-mesa-swx11:i386,libegl1-mesa-drivers:i386,libosmesa6-dev:i386,mesa-common-dev --pkgname=mesa32 --pkgversion=10.0-dev-`git describe` --pkgarch=i386 --backup=no --exclude=/etc/*,/usr/include/* --nodoc
Comment
-
@gradinaruvasile
Thanks a lot!
@jery
I am not rough, its cause of little manpower..
The 3.12 is developed very fast, 3.10 is ancient, 3.11 is unstable.
For one software project, its better to hold off.
For other - newer versions are more stable than older.
And some are too fast developed so that current is definately not usable, but newer has a lot of improvements but can be minefield.
This is why Debian model does not work. Which model works? Gentoo/Exherbo? Certainly not. No one. Each needs its own approach.
I just take each software project in its own nature and do what I can.
"why you say the radon driver is 2.33"
Its kernel driver version, ieCode:dmesg|grep Initialized|grep -i radeon
Comment
Comment