Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: More ATI Radeon KMS Power Management Fun

  1. #11
    Join Date
    Dec 2007
    Posts
    2,372

    Default

    Quote Originally Posted by sylware View Post
    Well, you mean having a non-sysfs power management interface like all the other sub-systems. So you would have a generalized DRM interface which generates proper sysfs entries on Linux and whatever are the proper interfaces on other kernels (window,MacOS,*BSD...).
    I don't know, but does the DRM power management driver interface allow proper use of pm.h? Personnally, I doubt it. And imagining code that will cleanly fit all the other kernels power management interface at the same time... sorry I don't buy it: it will be kludgy naughty code. I don't even think it will fit the "quality requiered" to get into *BSD kernels.

    For me it's masochistic and a dangerous path.

    Let me add a layer on top of it: a generalized instrumentation framework for performance measurements that will fit the native instrumentation interfaces of all kernels?

    All that kernel abstraction stuff seems quite unreasonable, but I think you got my point.
    Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

    pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

    What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

  2. #12
    Join Date
    Dec 2008
    Posts
    166

    Question

    Quote Originally Posted by agd5f View Post
    Right now there is no exposed interface to the radeon pm stuff. It's all handled transparently within the driver. Eventually we may expose knobs which will require an interface, but as of yet, we don't.

    pm.h basically defines the interface for suspend/hibernate/resume variants which are already hooked by the drm. There's nothing in there to handle arbitrary device power states. I'm not even sure how you could in a generic manner. Consider power states for a NIC vs a GPU vs. mouse, etc. Some asics may have hw controlled clock gating. Others might manually adjust clocks or turn off power to certain blocks. There are also device specific requirements like making sure there is enough memory bandwidth before downclocking vram or not putting a PHY in a low power state while a NIC is transmitting.

    What interface would you propose that could handle arbitrary device power states with all sorts of device specific requirements? What common kernel pm interface would you recommend? I don't see one.

    pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
    But... then you tell me the minor power management state machines are coded internally in the driver.
    The end result will be:
    - the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
    - the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

    And that story will map for all the other kernel services!

    Ok, I stop there, but do not be surprised if a few people do not agree with that approach. And I don't even talk about the licensing issue. I wish you luck on that road... if one day I have brain time to join seriously AMD GPU driver coding, that will be on a parallel twin road.

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    sylware, I'm not sure what you are recommending here. If the Linux power management system doesn't handle arbitrary device power states, doesn't that essentially require the kind of split implementation agd5f was describing ?

  4. #14
    Join Date
    Jun 2008
    Location
    Italy
    Posts
    74

    Default

    sylware, you know this radeon DRM module is the Linux, and just Linux, one, right?
    Probably I just misunderstood your posts, sorry if that's the case.

  5. #15
    Join Date
    Dec 2007
    Posts
    2,372

    Default

    Quote Originally Posted by sylware View Post
    pm.h defines calbacks for the Linux major power management state machine. It would have to be implemented by the driver itself, DRM or not. And, we agree a generalized interface would be insane, that was my point.
    But... then you tell me the minor power management state machines are coded internally in the driver.
    The end result will be:
    - the major state machine not optimally dealed with because of the DRM kernel abstraction: you need a DRM major state machine that maps as good as it can to *all* kernels.
    - the minor state machines, are coupled with the major state machine... and I would not be surprised if they are exceptions in those machines based on the underlying kernel specific major state machine. Additonnaly, user level nobs would have to be coded internally for each kernel.

    And that story will map for all the other kernel services!
    You're not making sense. The interface in pm.h doesn't apply to any of the pm state in question. How would I use it for that?

    The driver handles it's internal state properly so that it will do the right thing when the higher level s/r routines are called.

    Why would the kernel version matter other than for distros that may patch in/out functionality? The radeon drm lives in the kernel and it's tied to the interfaces in the kernel.

    ???

  6. #16
    Join Date
    May 2009
    Posts
    42

    Default

    Will these patches land in 2.6.34 rc2 ?

  7. #17
    Join Date
    Jan 2009
    Posts
    191

    Default

    i pretty sure the man trying to ask you to provide some graphic happiness, you spoiling us with, to all free and non-free kernels out there simultaneously

    well, you know all this crazy talk about porting KMS\TTM stuff onto *BSD and Gallium on Windows(tm)...

    ah, those *BSD\Windows(r) people... never willing to just admit that GNU/Linux has dominated servers and is on the way to "desktop" and to accept its power and love of the brotherh^Wcommunity

    Quote Originally Posted by icek View Post
    Will these patches land in 2.6.34 rc2 ?
    i kinda second on that - is there a way to make use of those patches over then compiling specific branch from some git ?

    this is burning question for me since i've decided to order R770 card as a replacement for my old (and sold) nvidia's 7800gtx.
    it will come after a week and i'm afraid to burn it to crisps since damn thing gives away up to 250 watts ! 0_o

  8. #18
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    Quote Originally Posted by dfx. View Post
    it will come after a week and i'm afraid to burn it to crisps since damn thing gives away up to 250 watts ! 0_o
    Don't worry - 250W is not GPU power consumption (in fact it's very hard to detect it). This is power consumption of the whole testing system for sure. It was using i7, so it bumped wattage "a bit"

    To find out the power consumption of cards, look at TDPs, for example on Wikipedia.

  9. #19
    Join Date
    Jan 2009
    Posts
    191

    Default

    oh... looks like i've read it inattentively but i thought its "135.5W TDP" will somehow double with a help of hot memory...

    but it's still scary to use it knowing that it will run at full power all the time (and i never switch off this PC) and, from what i understand from here, there is still big difference with my old NV7800GTX

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

    Default

    Any chance of getting patches for 2.6.33?

Posting Permissions

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