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

Thread: Open ATI Driver To Receive PowerPlay Push?

Hybrid View

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

    Default Open ATI Driver To Receive PowerPlay Push?

    Phoronix: Open ATI Driver To Receive PowerPlay Push?

    Besides the Radeon DRM improvements (and Radeon HDMI KMS audio) to be found in the Linux 2.6.33 kernel, there is more to be thankful for this holiday season when it comes to the open-source support. Up to this point when it comes to power management for ATI's kernel mode-setting support the work (Radeon DRM Power Management Moves Along) has been largely done by RafaĆ? MiĆ?ecki, an independent open-source developer...

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

  2. #2
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    Just to clarify this information has been available for r1xx-r5xx/rs6xx/rs740 for years now (since atombios.h was released). This adds the table definitions for r6xx/r7xx/rs780/rs880.

  3. #3
    Join Date
    May 2009
    Posts
    75

    Default

    Quote Originally Posted by agd5f View Post
    Just to clarify this information has been available for r1xx-r5xx/rs6xx/rs740 for years now (since atombios.h was released). This adds the table definitions for r6xx/r7xx/rs780/rs880.
    So why can't we overclock and/or change fan speeds on the older (r300-r500) harware then? Is it the ttm not being optimized, gpu acceleration not being optimized or powerplay code not being complete?

  4. #4
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    Quote Originally Posted by barbarbaron View Post
    So why can't we overclock and/or change fan speeds on the older (r300-r500) harware then? Is it the ttm not being optimized, gpu acceleration not being optimized or powerplay code not being complete?
    There's no power management infrastructure to hook into and no one's written the code to do it.

  5. #5
    Join Date
    May 2008
    Posts
    598

    Default

    WOW! This is incredible!

    Were you saving this for Christmas on purpose?

    I've say it is worth it though.

    Didn't we get glxgears for R600 for Christmas last year?

  6. #6
    Join Date
    Sep 2009
    Location
    Edinburgh, UK
    Posts
    53

    Default

    Quote Originally Posted by Louise View Post
    WOW! This is incredible!

    Were you saving this for Christmas on purpose?

    I've say it is worth it though.

    Didn't we get glxgears for R600 for Christmas last year?
    Last year we got first hardware accelerated triangles.

  7. #7
    Join Date
    Aug 2009
    Posts
    122

    Default

    Quote Originally Posted by agd5f View Post
    There's no power management infrastructure to hook into and no one's written the code to do it.
    isn't it possible to create some interface, based on sysfs, to control clocks/fan speed?

  8. #8
    Join Date
    Dec 2007
    Posts
    2,360

    Default

    Quote Originally Posted by netkas View Post
    isn't it possible to create some interface, based on sysfs, to control clocks/fan speed?
    It's possible, but it's still a lot of work. Besides, just exposing clocks to users does not ultimately save much power or give a good user experience. There are a lot of factors to consider:

    - Bandwidth. Do I have enough memory bandwidth in this power state to properly feed all active displays as well as the drawing engine? Not enough bandwidth can cause drawing stalls or glitches and blanking or flickering of the displays.

    - Frequency. Is the current clock rate high enough to finish the current operations within an acceptable time window? Often, it's a better user experience and saves more power to bump the GPU to a higher power state than you might think so the operation finishes sooner. Set it too low and performance will suck.

    - Thermal/fan controllers. These are 3rd party chips connected via i2c. Drivers need to be written for each of these chips before they can be used. Then you need to wire them up to some interface so you can access the information. There are existing drivers for some of these chips, but we need to write a radeon i2c algo module to expose the radeon i2c buses so they can be used by other drivers. This in itself is a fair amount of work.

    - Power mode changes. This needs to be done during the blanking period or when the displays are off to avoid visual glitches. Often the latencies required make it hard or impossible to fit this into a vblank period.

  9. #9
    Join Date
    Dec 2008
    Posts
    166

    Default cross kernel madness

    Quote Originally Posted by agd5f View Post
    There's no power management infrastructure to hook into and no one's written the code to do it.
    I bet that the cross kernel madness is one of the main reason. To follow kernel abstraction, the DRM would have to include a power management abstraction which works on Linux and BSD. That abstraction will be easy to design with firmware loading but with power management, design is brought to a whole new level...

    The cross-kernel thing is turning to a kludge. Better drop kernel abstraction, switch to GNU GPLv2 (I would go GNU Affero GPLv3 for GPU drivers), and code directly on Linux APIs and internal structures. BSD coders are smart enough to code drivers that will fit cleanely their kernel, since all the knowledge will already be available in Linux.

  10. #10
    Join Date
    May 2008
    Posts
    598

    Default

    I seriously don't mean to start a flame war, but why are desktop users using BSD?

    Don't people use BSD for its firewall?

Posting Permissions

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