Announcement

Collapse
No announcement yet.

How To Setup Radeon DPM On Ubuntu Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Tyler_K
    replied
    Originally posted by brosis View Post
    Its kernel driver version, ie
    Code:
    dmesg|grep Initialized|grep -i radeon
    just a note: even easier:
    Code:
    dmesg|grep "Initialized radeon"

    Leave a comment:


  • brosis
    replied
    @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
    Code:
    dmesg|grep Initialized|grep -i radeon

    Leave a comment:


  • gradinaruvasile
    replied
    Originally posted by jery View Post
    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:

    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
    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):
    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
    32-bit (notice thenodoc option and excluded files, those are in the 64 bit package and i needed to avoid conflicts):
    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
    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.

    Leave a comment:


  • jery
    replied
    Originally posted by brosis View Post
    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).
    Last edited by jery; 23 October 2013, 03:50 AM.

    Leave a comment:


  • brosis
    replied
    Originally posted by jery View Post
    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.

    Leave a comment:


  • jery
    replied
    Originally posted by gradinaruvasile View Post
    Check dmesg for this line:
    Code:
    [drm] radeon: dpm initialized
    Dont forget the microcode, you need it for dpm.
    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
    thx.
    I already updated the microcode. The nonfree firmware package already contains the latest microcode.

    I'll check this trace in dmesg.

    Leave a comment:


  • gradinaruvasile
    replied
    Originally posted by jery View Post
    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:
    Code:
    [drm] radeon: dpm initialized
    Dont forget the microcode, you need it for dpm.
    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:
    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

    Leave a comment:


  • jery
    replied
    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

    Leave a comment:


  • asdfblah
    replied
    Originally posted by Ruse View Post
    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.



    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

    Leave a comment:


  • ogyct
    replied
    My question is, when can we expect this feature be enabled by default?

    Leave a comment:

Working...
X