Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: In-Kernel Power Management For ATI KMS

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

    Default In-Kernel Power Management For ATI KMS

    Phoronix: In-Kernel Power Management For ATI KMS

    While the Radeon R100-R500 series kernel mode-setting support appeared in the Linux 2.6.31 kernel and DRM patches pending for the Linux 2.6.32 kernel that bring KMS support for newer hardware and other improvements, the ATI KMS driver is not complete. Features such as power management need to be brought into the kernel driver (for Intel too) where they will be better off compared to the traditional DDX drivers...

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

  2. #2
    Join Date
    May 2008
    Posts
    598

    Default

    I sure hope these patches can make it into Fedora 12

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

    Thumbs up

    simply incredible

    Rafał Miłecki and all the other devs:

    thank you, thank you, thank you, thank you, thank you very much

    I can't believe how fast everything is coming together !

    great work guys !

  4. #4
    Join Date
    Jan 2008
    Location
    Radoboj, Croatia
    Posts
    155

    Default

    Quote Originally Posted by Louise View Post
    I sure hope these patches can make it into Fedora 12
    I hope that too. My fedora laptop will finally have longer battery life.

  5. #5
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    183

    Default

    Phoronix idealized a little my patches I think it sounds too optimistic

    My work prepares only basic infrastructure for PM. This doesn't do anything useful yet actually.

    Last patch which introduces sth interesting - downclocking - is considered not ready yet. I think it may even crash module, as it doesn't even check function pointer.

    As soon as these patches hit drm-next, I'm going to continue my work and prepare something really useful. Unfortunately the most complicated part is still ahead of us: determining which power state should be used in current moment. It needs measuring current load and some smart (and lucky) choosing mode. Remember that every mode has engine clock, memory clock and voltage. We have to somehow calculate all of that.

    So I don't think you should expect something "really" working soon. Especially if you keep in mind that main (much more talented and experienced) developers are still working on other parts.
    Last edited by Zajec; 09-11-2009 at 04:30 PM.

  6. #6
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    Thanks, Zajec!

    Do you know by chance something about reading out temperatures? I am very interested in that.

  7. #7
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Quote Originally Posted by Zajec View Post
    As soon as these patches hit drm-next, I'm going to continue my work and prepare something really useful. Unfortunately the most complicated part is still ahead of us: determining which power state should be used in current moment. It needs measuring current load and some smart (and lucky) choosing mode. Remember that every mode has engine clock, memory clock and voltage. We have to somehow calculate all of that.
    Isn't this something which could be lifted from the proprietary driver?

    If not the actual code, then the calculations behind it? I would guess having the cards behave the same between the two drivers would be a good idea?

  8. #8
    Join Date
    Jan 2009
    Location
    UK
    Posts
    331

    Default

    Quote Originally Posted by Zajec View Post
    Unfortunately the most complicated part is still ahead of us: determining which power state should be used in current moment.
    Will it still have the behaviour of the current radeon driver where it downclocks during DPMS power off? That one makes a huge difference even on my 4350.

    Other than that, I imagine something like cpufreq ondemand would work, if the driver had a way to detect the framerate of running apps and change the speed as appropriate.

  9. #9
    Join Date
    Dec 2007
    Posts
    91

    Default

    Quote Originally Posted by Zajec View Post
    Phoronix idealized a little my patches I think it sounds too optimistic

    My work prepares only basic infrastructure for PM. This doesn't do anything useful yet actually.

    Last patch which introduces sth interesting - downclocking - is considered not ready yet. I think it may even crash module, as it doesn't even check function pointer.

    As soon as these patches hit drm-next, I'm going to continue my work and prepare something really useful. Unfortunately the most complicated part is still ahead of us: determining which power state should be used in current moment. It needs measuring current load and some smart (and lucky) choosing mode. Remember that every mode has engine clock, memory clock and voltage. We have to somehow calculate all of that.

    So I don't think you should expect something "really" working soon. Especially if you keep in mind that main (much more talented and experienced) developers are still working on other parts.
    Well first thanks for the work, even though it's in an early stage.
    But I have a couple of things in my mind, here they are :
    As I understood it from the previous discussions here on phoronix, the really tricky part was to ensure that the down-clocking was safe.
    By safe I mean that such down-clocking can raise issue with the memory being corrupted and thus some flushing was needed.

    At the beginning you can always build rather simple heuristic to test how your set-up works. (for instance a function that follows the inverse of the temperature curves, really stupid since every state change should induce a change in the temperature as well, which in turn should trigger a new state change, etc...)
    Tuning such algorithms takes time and you only end up knowing exactly what to do (and what people want you to do) once people start to complain that your implementation is too aggressive or too lazy.

    By looking at the radeon_pm_set_state function, I see that you skipped the memory and voltage setting, isn't it a problem ? Are the frequencies of the components paired ? Or can you access the memory at every frequency from an engine at any given frequency ?
    I might try to implement some fancy idea in your radeon_pm_adjust, if it's proven to safe from the point of view of the kernel.
    Last edited by lucky_; 09-11-2009 at 05:43 PM.

  10. #10
    Join Date
    Oct 2008
    Location
    Poland
    Posts
    183

    Default

    Quote Originally Posted by whizse View Post
    Isn't this something which could be lifted from the proprietary driver?

    If not the actual code, then the calculations behind it? I would guess having the cards behave the same between the two drivers would be a good idea?
    I'm afraid AMD is too busy with other things. For example Christian is waiting for HDMI audio specs (even if under NDA) for about month already.



    Quote Originally Posted by Ant P. View Post
    Will it still have the behaviour of the current radeon driver where it downclocks during DPMS power off? That one makes a huge difference even on my 4350.
    That will be the easiest part and should be implemented as first PM operation. Detecting DPMS_OFF -> downclocking to minimum. Nothing could be easier Actually you can expect this one pretty soon (still, depends on amount on changes Alex will want to make to my patches).



    Quote Originally Posted by Ant P. View Post
    Other than that, I imagine something like cpufreq ondemand would work, if the driver had a way to detect the framerate of running apps and change the speed as appropriate.
    If driver can detect FPS, it's something I don't know about. And probably even if, we could not use this as the only parameter to choose state. I think we will need to try observe commands submissions.

    There already were some ideas posted on ML/IRC, will have to grab them all and consider.



    lucky_: will read you post tomorrow, sorry Goodnight.

Posting Permissions

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