Page 1 of 9 123 ... LastLast
Results 1 to 10 of 81

Thread: Radeon DRM: Dynamic Power Management Updates

  1. #1
    Join Date
    Jan 2007
    Posts
    14,357

    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,860

    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
    649

    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
    Feb 2009
    Location
    France
    Posts
    275

    Default

    Quote Originally Posted by tball View Post
    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.
    Hey, I know this problem. It was the same a few years back. Had to disable dynpm :s

  8. #8
    Join Date
    Jul 2008
    Posts
    726

    Default

    For Zacate CPUs I think this 3.11er patches are not extremly important so I go a bit OT but still kind of related:

    I read on the comments of the radeon driver that also the apus would start after boot at their minimal frequency, I think you propable only meant the gpu part, but also memory frequency was talked about. So I thought maybe that could be here a problem why I think here my gnome is a bit slower in arch here (was the same with ubuntu) as on the pc of my dad with fedora.

    So I looked into it... on my zacate machine the memory frequency is fix on 1333mhz thats normal.

    Then I thought lets test the cpus how they react to stress ^^ so I installed a cpuburn programm startet two of em... because I have two cores both take 60-70% load... so more than 1 core should be used.

    But when I then look at cpuinfo I see one core at 1600mhz and one at only 800mhz.

    Ok thought maybe I did something wrong in some powersettings or something or my thinkpad is here special so I did the same test on my also zacate htpc with fedora on it.
    So here the same.

    So I can say that at least for kernel 3.10 this seems to be a general reality.

    So my question is this behaviour that only one core gets clocked from 800 to 1600mhz normla for zacate? Or is that a bug in the 3.10er kernel or what?


    (Sorry for to much So... ^^)

  9. #9
    Join Date
    Dec 2007
    Posts
    2,328

    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.

  10. #10
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,860

    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?

Posting Permissions

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