Page 8 of 18 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 180

Thread: More Radeon Power Management Improvements

  1. #71
    Join Date
    May 2009
    Posts
    39

    Default

    Quote Originally Posted by nanonyme View Post
    If I wanted low profile to be used by default on boot, what would be the preferred location to set it?
    In Arch Linux I did the following:

    http://wiki.archlinux.org/index.php/Ati#Early_KMS_start

    and added line

    Code:
    echo low > /sys/class/drm/card0/device/power_profile
    in file
    Code:
    /etc/rc.local
    I don't know if the first step has any effect other than getting the right resolution earlier, but it's still nicer that way. And I use the kernel from

    http://gtklocker.tiven.org/radeon-repo/x86_64/

  2. #72
    Join Date
    Dec 2007
    Posts
    2,323

    Default

    Quote Originally Posted by Ivaldi View Post
    Oh, thank you. This key information hasn't spread far enough, AFAICS.

    FYI, some power consumptions tests (KMS, Xorg with radeon driver from yesterdays git snapshot, one head enabled, no relevant CPU load):

    default: ~144W
    auto: 127..132W
    high: 137..141W
    mid: 128..131W
    low: 100..103W (pretty close to normal idle state with fglrx)
    low (with both heads enabled): 118..121W (also close to fglrx w/ multihead)

    My naive conclusion is that "auto" mode is not aggressive enough or doesn't get enough information to control efficiently. But I am sure you know better.
    As noted in the page I linked, "auto" only lowers the clock when on battery and when the screen is blanked. To dynamically raise and lower the clocks, you can enable the dynpm method, but you will likely experience problems until that is sorted out better.

  3. #73
    Join Date
    May 2008
    Posts
    343

    Default

    Quote Originally Posted by Ivaldi View Post
    default: ~144W
    auto: 127..132W
    high: 137..141W
    mid: 128..131W
    low: 100..103W (pretty close to normal idle state with fglrx)
    low (with both heads enabled): 118..121W (also close to fglrx w/ multihead)

    My naive conclusion is that "auto" mode is not aggressive enough or doesn't get enough information to control efficiently. But I am sure you know better.
    My understanding is that auto switches only between high and mid (as long as the screen is on at least) so when in your case the auto rate is the same as the mid rate that sounds like as good as it gets. It will not switch to low because low is not working so well for everybody ATM.

  4. #74
    Join Date
    Feb 2010
    Posts
    22

    Default

    Quote Originally Posted by tormod View Post
    My understanding is that auto switches only between high and mid (as long as the screen is on at least) so when in your case the auto rate is the same as the mid rate that sounds like as good as it gets. It will not switch to low because low is not working so well for everybody ATM.
    Not sure auto even switches anything when AC is on.
    Here with 2.6.35rc4 + drm-radeon-testing, GPU is running at full blast as long as power is plugged.

    On the other hand, "dynpm" was working really great with 2.6.34 mainline and was very efficient but now there's noticeable flickering / micro-freezes on every state change, maybe due to additional memory reclock and/or voltage tweaking...

  5. #75
    Join Date
    Dec 2007
    Posts
    2,323

    Default

    "auto" only changes the clocks when switching from battery to ac and vice versa (mid <-> high) and when the monitors blank (low).

  6. #76
    Join Date
    Feb 2010
    Posts
    22

    Default

    Quote Originally Posted by agd5f View Post
    "auto" only changes the clocks when switching from battery to ac and vice versa (mid <-> high) and when the monitors blank (low).
    OK for the battery/ac switch. However, closing the lid doesn't seem to change the clocks (checking through ssh).

    Besides, "dynpm" still introduces lots of flicker and micro-freezes, but doesn't always bring the clocks up when needed (HD playback, thus jerky). glxgears alone seems to trigger reclocking.
    Is dynpm still regarded as experimental by now ?

  7. #77
    Join Date
    Dec 2007
    Posts
    2,323

    Default

    Quote Originally Posted by dmfr View Post
    OK for the battery/ac switch. However, closing the lid doesn't seem to change the clocks (checking through ssh).
    It will if your desktop environment blanks the screen when you close the lid. The dpms reclocking happens when all the monitors are in the dpms off state. It also depends on what power states are specified in your bios. Some cards only have one or two states for example.

    Quote Originally Posted by dmfr View Post
    Besides, "dynpm" still introduces lots of flicker and micro-freezes, but doesn't always bring the clocks up when needed (HD playback, thus jerky). glxgears alone seems to trigger reclocking.
    Is dynpm still regarded as experimental by now ?
    The engines have to be idle and the CPU cannot be accessing vram when changing the clocks. To avoid flicker, you need to change the clocks during the vblank period (this is nearly impossible with dualhead as the vblanks may never line up). Changing the clocks requires a certain amount of time depending on how long it takes the plls to lock. As such, if the reclock gets scheduled too close to the end or outside the vblank period, you need to reschedule it. It's even harder with two clocks (engine and memory). They should be scheduled separately to make sure they can be done in the vblank period; right now they are not.

    The pm code has to take the cp lock, wait for the engines to be idle, turn off the crtc mem requests, and unmap all vram mmaps when it's going to reclock. When this happens, new command buffers cannot be sent to the GPU; that's what causes the stalls. The flickering is caused by overrunning the vblank period during the reclock.

    Deciding when to dynamically reclock is also tough. Right now we just look at the number of queued command buffers, but ideally, you'd have some intelligence as to what operations are happening and how much bandwidth you'd need from memory and the engine to complete the requested command buffer smoothly. If you miss the vblank window, you need to reschedule the reclock which means the clocks may be running slower than you'd ideally want.

    Unfortunately, it's very complex to get right.

  8. #78
    Join Date
    Feb 2010
    Posts
    22

    Default

    Thanks a lot for the detailed explanation, though a bit off my knowledge.

    That may explain why dynpm was smooth when the engine clock alone was tweaked.
    For now i'll stick to profile=auto.

  9. #79
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Uhm, since you're AMD/ATI, don't you have info about how fglrx solves this?

  10. #80
    Join Date
    Dec 2007
    Posts
    2,323

    Default

    Yes, piles and piles of code that touches just about everything.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •