Page 1 of 2 12 LastLast
Results 1 to 10 of 81

Thread: Radeon DRM: Dynamic Power Management Updates

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,611

    Default Radeon DRM: Dynamic Power Management Updates

    Phoronix: Radeon DRM: Dynamic Power Management Updates

    The DRM pull request has yet to be submitted for the Linux 3.11 kernel and already there is another revision to the Radeon DRM kernel driver to be submitted. This latest Radeon DRM work provides additional dynamic power management fixes and some new sysfs features...

    http://www.phoronix.com/vr.php?view=MTQwNDI

  2. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Alex, two questions for ya. One related to this and one general radeon question.

    Related question: I know an AMD dev made a comment at one point that said that catalyst PM code was larger than all of Mesa totalled....lovely. What's the hopes for this code drop? I'm not really expecting almost identical power usage between radeon and catalyst after 3.11, but in your tests is it comparable at least? Not trying to bash the work, even if all this did was automatically jump between 'low' 'medium' 'high' power profiles based upon load that would still be an improvement over the status quo, so its definitely appreciated. I'm just curious what you, as the developer, would say the impact in comparison to Catalyst.

    Radeon question: So 3.10 bring us UVD, 3.11 brings us DPM, Crossfire would probably require a big rework kernel side and user-side (as far as Kernel, Mesa, and X) to make work so that really just leaves one thing in my head.... How's HDMI audio coming along? Its been disabled by default since like 3.0 or 3.2, Michael did an article about how one of the devs made Radeon do the exact same steps (as far as registers go) that catalyst does and that it worked out all the problems he was having on his test machines... did those patches ever get merged? Whats the big blocker-bug for hdmi audio enabled by default?

  3. #3
    Join Date
    Jun 2007
    Location
    .ro/.ca
    Posts
    232

    Default

    The RV770 improvement works for me. Thanks, Alex Deucher.

    As a bonus, fan speed seems to be proportional to load in the 3d_perf state - old code/firmware had it at max all the time.

  4. #4
    Join Date
    Jan 2009
    Posts
    515

    Default

    Anyone know if this fixes the flickering and UVD problems on RV730?

  5. #5
    Join Date
    Sep 2010
    Posts
    731

    Default

    Quote Originally Posted by tball View Post
    Anyone know if this fixes the flickering and UVD problems on RV730?
    It cann't.

    First is realated to tear-free rendering (which require replacing X.org..), second is related to UVD code itself. So you will have flickering GPU with UVD problems, but which consume less power and which fan work lighter.
    (Did you reported your bugs? Not about flickering unless its whole screen flickering, but about UVD?)

  6. #6
    Join Date
    Jan 2009
    Posts
    515

    Default

    Quote Originally Posted by przemoli View Post
    It cann't.

    First is realated to tear-free rendering (which require replacing X.org..), second is related to UVD code itself. So you will have flickering GPU with UVD problems, but which consume less power and which fan work lighter.
    (Did you reported your bugs? Not about flickering unless its whole screen flickering, but about UVD?)
    I don't know if you are refering to tearing, but this is not tearing. It is related to the new dpm code (I think). The flickering is coming and going, and consists of the whole screen jumping up and down.

    I don't mind the UVD problems, since it is very experimental code. But the flickering renders my desktop hard to look at for too long.

  7. #7
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by Ericg View Post
    Alex, two questions for ya. One related to this and one general radeon question.

    Related question: I know an AMD dev made a comment at one point that said that catalyst PM code was larger than all of Mesa totalled....lovely. What's the hopes for this code drop? I'm not really expecting almost identical power usage between radeon and catalyst after 3.11, but in your tests is it comparable at least? Not trying to bash the work, even if all this did was automatically jump between 'low' 'medium' 'high' power profiles based upon load that would still be an improvement over the status quo, so its definitely appreciated. I'm just curious what you, as the developer, would say the impact in comparison to Catalyst.
    Have you seen the size of the dpm patch set It should come pretty close to the closed driver savings-wise. It is pretty much on par feature-wise.

    Quote Originally Posted by Ericg View Post
    Radeon question: So 3.10 bring us UVD, 3.11 brings us DPM, Crossfire would probably require a big rework kernel side and user-side (as far as Kernel, Mesa, and X) to make work so that really just leaves one thing in my head.... How's HDMI audio coming along? Its been disabled by default since like 3.0 or 3.2, Michael did an article about how one of the devs made Radeon do the exact same steps (as far as registers go) that catalyst does and that it worked out all the problems he was having on his test machines... did those patches ever get merged? Whats the big blocker-bug for hdmi audio enabled by default?
    There were a number of monitors that would display blank screens with hdmi audio enabled by default. We fixed a number of bugs in the hdmi packet generation in the last couple of kernels so if all goes well in this cycle we can probably enable it.

  8. #8
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,934

    Default

    Quote Originally Posted by agd5f View Post
    Have you seen the size of the dpm patch set It should come pretty close to the closed driver savings-wise. It is pretty much on par feature-wise.
    I saw the mailing list messages and glanced at your branches, but no, I hadn't seriously delved into your work-- kernel coding is a bit beyond me haha.

    Quote Originally Posted by agd5f View Post
    There were a number of monitors that would display blank screens with hdmi audio enabled by default. We fixed a number of bugs in the hdmi packet generation in the last couple of kernels so if all goes well in this cycle we can probably enable it.
    Lovely glad to hear both of those bits of information. Once hdmi is enabled by default that'll basically takes care of all the big features as far as I'm concerned with Radeon. Though you devs may know of a few other features that need to handled. The work is much appreciated Alex, please send my thanks and regards along to anyone else who worked on DPM and UVD

    Are we gonna have to go through this whole legal-disaster again for future radeon cards? Or now that UVD and DPM are out there and AMD knows they are targeting open source with future products, will those two things also just now be worked as hardware-enablement happens?

    Also, just for pure curiosity's sake... What were the radeon devs doing wrong when it came to dynpm? It was a longstanding and well known issue that Dynpm couldn't complete the reclocking during vsync and therefore would flicker, and (atleast according to the arch wiki: ) also wouldn't work with multiple outputs active. How come? I'm assuming that now the correct implementation is out there in the wild that there's no legal issue preventing the devs from talking about the existing DynPM code. Were they just trying to do too much during vsync? Was Vsync not actually where the reclocking was supposed to happen? What was it?

  9. #9
    Join Date
    Jan 2009
    Location
    Vienna, Austria; Germany; hello world :)
    Posts
    642

    Thumbs up

    @agd5f:

    I'm probably again using an outdated kernel (from 4th of july) but I used dynpm for a whole day and it was annoying loud, producing lots of warmth & eating energy - thus money

    dynpm in that state may be perfectly suitable for gamers but for e.g. "normal" research work & while it's warm outside - it's not

    it's simply too loud and disturbing concentration, furthermore energy is pretty expensive here and my appartment gets warm very fast while the gpu runs as a heater

    might the fact that I'm using compiz-fusion play a role in this ?

    the gpu is also running a full speed/clocking pretty high even when working on a console window in X with compositing activated



    don't get me wrong: this is not to directly criticize your work - which I heavly appreciate - but to point out that under these consequences it's not suitable for all:

    e.g. when using the windows 7/8 catalyst driver it's significantly more silent and only clocks up that much when running games and putting full load on the gpu


    fglrx back then when I used it (last year) also was way more silent - it was noticably louder than under windows but it was still tolerable


    hope there's changes - otherwise - unfortunately the only option I had would be to use static "low" performance profile



    thanks for your hard work !

  10. #10
    Join Date
    Mar 2010
    Posts
    25

    Default

    Quote Originally Posted by kernelOfTruth View Post
    I'm probably again using an outdated kernel (from 4th of july) but I used dynpm for a whole day and it was annoying loud, producing lots of warmth & eating energy - thus money
    Umm, are you sure you're actually using the new DPM code (kernel parameter radeon.dpm=1)? dynpm is the old and useless way of doing things, dpm is the new awesome one.

Posting Permissions

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