Announcement

Collapse
No announcement yet.

AMD Has Massive Radeon Patch Set - Power Management!

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

  • Pontostroy
    replied
    ASUS hd6770 hang with radeon.dpm=1 in X
    drm-next 77ef8bbc87be7ad10b410247efc6d0f10676b401

    tty looks like


    With dpm T 39C, without 52C.

    radeon_pm_info
    uvd vclk: 0 dclk: 0
    power level 0 sclk: 15700 mclk: 30000 vddc: 950 vddci: 1100

    dmesg - http://pastebin.com/njw0hhtq

    Leave a comment:


  • ledti
    replied
    My HD 6870 doesn't work with the latest patches. Once KMS is enabled during boot, the screen is covered in an abundant amount of artifacts that spell doom. It works with the previous patch set (drm-next-3.11-wip-5).

    I'm using Arch with the latest mesa/ati related packages found here.

    I noticed that HomeSp's 6870 is working fine with the latest patches, so oddly enough I'm hoping that this is a true regression and not PEBKAC, as I'd not like to waste anyone's time. Is there any information that I can give that might help resolve this?

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by agd5f View Post
    I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.
    well my 7770 certainly improved and i think i found the issue of the black screen, it does work when i disconnect my HDMI tv connection and leave only my DVI monitor but with both KMS have a nasty hang at start.

    another issue is if i start with the drm-next-3.11 kernel radeonsi doesnt seem to work correctly[it spawn 1 ksoftirq per core and give hell to the CPU], i assume llvm need update, so ill compile today revision[i have 30 jun] with libdrm today git and see if persist. drm-next-wip-5 works fine tho

    Leave a comment:


  • ElderSnake
    replied
    Latest Saucy builds for Ubuntu (drm-next) indeed seems to fix UVD on the Sony Vaio (RV710 ATI), though the screen flickering is still there. Unfortunately I can't find anything untoward in the usual logs or dmesg.

    Leave a comment:


  • agd5f
    replied
    Originally posted by Ibidem View Post
    Can dpm be enabled after loading radeon via sysfs, like dynpm?
    If not, would it be possible to change that?
    I don't have any intention of supporting that. There are too many corner cases for weird interactions and for things to go wrong. Once DPM stabilizes, I'd like to deprecate the old code.

    Leave a comment:


  • HomerSp
    replied
    Originally posted by agd5f View Post
    I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.
    I just tried the new code on my 6870 and it does indeed seem to be working much better now. Thank you for fixing that, it was a deal breaker for me as the whole desktop would become unusable after a while.

    Originally posted by Ibidem
    Can dpm be enabled after loading radeon via sysfs, like dynpm?
    If not, would it be possible to change that?
    As of now I don't think that's possible, but I'd guess they will add support for that once it's more stable and thoroughly tested.

    Leave a comment:


  • Ibidem
    replied
    Can dpm be enabled after loading radeon via sysfs, like dynpm?
    If not, would it be possible to change that?

    Leave a comment:


  • agd5f
    replied
    I pushed some updated patches to my drm-next-3.11 branch that should fix the outstanding issue with NI asics and also adds a debugfs interface for tracking the current power state.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by pali View Post
    Ok, I can test something other, but I do not know that is needed for devs. Maybe devs already know this problem and do not need testing...

    I see that desktop with enabled dpm is slower than with disabled. Also all KDE4 kwin effects are very very slow. So it is really problem (and not only bad output from glxgears)
    well i read the performance adjustments come a bit later, for now is more like compatibility and features, and is still missing debug infrastructure pminfo which make it hard to check the real clocks.

    so i guess the load in the GPU is not enough to push it outside the ULP mode and probably many cores are gating off too[depending your GPU] but without pminfo i don't know how to detect it properly

    Leave a comment:


  • pali
    replied
    Originally posted by jrch2k8 View Post
    first if you even expect a reply show Xonotic or some other game because glxgears is not a benchmarks, it just says how fast you can flip and other really simple operations, in your case if your CPU downclock cuz it enter in battery profile too it will affect heavilly glxgears result and it does not put enough load on the GPU to force them UP
    Ok, I can test something other, but I do not know that is needed for devs. Maybe devs already know this problem and do not need testing...

    I see that desktop with enabled dpm is slower than with disabled. Also all KDE4 kwin effects are very very slow. So it is really problem (and not only bad output from glxgears)

    Leave a comment:

Working...
X