How To Setup Radeon DPM On Ubuntu Linux

[asdfblah]

There are two problems:

- Oibaf's PPA is in a much worse state than it was in the time of the article got posted.
(Back in those days I could use it on my VM, on my laptop and desktop. Now X does not even load on any of those boxes. Yeah, I removed the PPA and everything related since then, but it's just sad.)
- The 3650 and other r600 cards are known to have problems. adf tried to fix these by randomly disabling features (I don't blame him), but got nothing further. The bugtracker is 10 pages long already. People trying to do everything they can but there is no solution or permanent fix which works for everyone.

https://bugs.freedesktop.org/show_bug.cgi?id=66963

I mean Alex really did everything he could, but there is some black magic involved in the r600 power management.
There is a reason why AMD just drops every GPU support after two-three years.

"Shit s?xx", as my Turkish friend would say.

Solution?
I threw out my ThinkPad and got a new Nvidia based beast. Same for my desktop, returned my 7870OC and now I have drivers (both platforms AND BSD). What a joy. (Gave away the 4850 to a friend of mine since he uses Windows 7.)

They should reverse engineer the legacy fglrx

[jery]

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

[gradinaruvasile]

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

Check dmesg for this line:

[drm] radeon: dpm initialized

Dont forget the microcode, you need it for dpm.
Copy all files from here:

http://people.freedesktop.org/~agd5f/radeon_ucode/

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?page=news_item&px=MTQyNDE

[jery]

Check dmesg for this line:

[drm] radeon: dpm initialized

Dont forget the microcode, you need it for dpm.
Copy all files from here:

http://people.freedesktop.org/~agd5f/radeon_ucode/

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

thx.
I already updated the microcode. The nonfree firmware package already contains the latest microcode.

I'll check this trace in dmesg.

[brosis]

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

I 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.

[jery]

I 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.

You'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).

[gradinaruvasile]

You'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).

The unstable repos contain the 3.11.5 kernel, quite recent stable version. Radeon 2.33 is probably the version of radeon from the 3.10 kernel. 3.11 has 2.34 too AFAIK. xserver-xorg-video-ati is indeed at 7.2 (this is the X servers driver).

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:

#!/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

To compile for both archs, you need to do a "make distclean" between the builds to make sure everything built previously is cleaned up.

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):

#!/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

32-bit (notice thenodoc option and excluded files, those are in the 64 bit package and i needed to avoid conflicts):

#!/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

Hmmm. Took me some time to figure these out. Now i have a master build script that pulls the newest commits from the git, builds the mesa (both amd64 and i386), glamor and xf86-ati .debs in one step.

[brosis]

@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, ie

dmesg|grep Initialized|grep -i radeon

[Tyler_K]

Its kernel driver version, ie

dmesg|grep Initialized|grep -i radeon

just a note: even easier:

dmesg|grep "Initialized radeon"

[jery]

so it is 2.34...

[ 4.298894] [drm] Initialized radeon 2.34.0 20080528 for 0000:01:00.0 on minor 0