Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 62

Thread: Open ATI Driver To Receive PowerPlay Push?

  1. #11
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by sylware View Post
    Many do: MacOS.

    The big issue here is that MacOS is a proprietary and closed fork of Darwin which is a BSD. MacOS has many improvements that Dawin has not...
    This is a part of the root of the BSD/GNU GPL flamewar.
    "Thanks" to the BSD license, apple can improve and close the code witout publishing it. MacOS is closed and proprietary. With the GNU GPL, fairness (open source) is protected, enforced: you cannot close the code. It allows us to go after optimal code.
    Most of GNU GPL coders are looking to have an *optimal* open source OS installed on systems. The GNU GPL helps towards that goal, but is not a silver bullet.
    Regarding the GPUs drivers, since they are BSD, apple can rip that code, share secrets with nvidia/AMD/intel... in order to keep the optimal code for MacOS crippling the open source version (they did it for NTFS support for instance).
    I do remenber BSD advocates saying that no company will be able to have a better proprietary fork of a BSD OS. They were wrong.
    So what you want is to rip out the close source drivers from MacOSX and install the open source drivers?

    Doesn't the 3D work very well out of the box with Mac?

  2. #12
    Join Date
    Dec 2008
    Posts
    166

    Default

    Quote Originally Posted by Louise View Post
    So what you want is to rip out the close source drivers from MacOSX and install the open source drivers?

    Doesn't the 3D work very well out of the box with Mac?
    AFAIK, it does not.

    "Ripping closed source" means reverse engineering the closed source driver. That's what the people of the nouveau project are doing on the nvidia Linux driver. All that because nvidia refuse to publish the hardware programming manual of their GPUs. This is a gigantic loss of time. I would not be surprised if some companies with an interest of slowing down GNU/Linux on the desktop are behind all this.

    Remember: the target is to have by default open source OS installed on systems with optimal code driving your hardware.

  3. #13
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by sylware View Post
    AFAIK, it does not.

    "Ripping closed source" means reverse engineering the closed source driver. That's what the people of the nouveau project are doing on the nvidia Linux driver. All that because nvidia refuse to publish the hardware programming manual of their GPUs. This is a gigantic loss of time. I would not be surprised if some companies with an interest of slowing down GNU/Linux on the desktop are behind all this.

    Remember: the target is to have by default open source OS installed on systems with optimal code driving your hardware.
    Yes, but then why use BSD? I mean, Linux and BSD use the same user space applications, I guess from a desktop users point of view they should fell the same?

  4. #14
    Join Date
    Dec 2008
    Posts
    166

    Default

    Quote Originally Posted by Louise View Post
    Yes, but then why use BSD? I mean, Linux and BSD use the same user space applications, I guess from a desktop users point of view they should fell the same?
    I was told: "in order to run in BSD kernels" (with all the risks it does imply). The result is a cross kernel kludge. I was *violently* forbidden to provide GNU GPL code for those drivers on AMD and NVIDIA project.

    I don't mind, I will code other drivers more fitted to the Linux kernel (license wise and code wise). We can share hardware programming knowledge but code will be different.

    What I can do, is take their code from a certain point, re-license under GNU GPL and obliterate cross-kernel code. It is *not* like closing the code: aka the ultimate treason.

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

    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.

  6. #16
    Join Date
    Dec 2008
    Posts
    166

    Default

    Quote Originally Posted by agd5f View Post
    - 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.
    Hu? Bridgman told me on IRC that from r7xx it's done through the ATOM bios?

  7. #17
    Join Date
    Jun 2008
    Location
    Italy
    Posts
    74

    Default

    @agd5f

    Thanks for exposing these problems and thoughts behind the code. It's quite interesting.

  8. #18
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by sylware View Post
    Hu? Bridgman told me on IRC that from r7xx it's done through the ATOM bios?
    The thermal chip information is stored in atombios data tables on all chips. R6xx and R7xx have built in fan/thermal controllers, however, not all oems use them. You still need driver code to actually query the thermal information.

  9. #19
    Join Date
    Aug 2009
    Posts
    122

    Default

    Quote Originally Posted by agd5f View Post
    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.
    In case to give users full access to clocks/fan/temps only 3rd item is needed, for things like - preventing overheating, overclocking, power saving (I/user can get 2d clocks from atombios with help of RBE and use it)

  10. #20
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by netkas View Post
    In case to give users full access to clocks/fan/temps only 3rd item is needed, for things like - preventing overheating, overclocking, power saving (I/user can get 2d clocks from atombios with help of RBE and use it)
    You need all of them for a decent user experience.

Posting Permissions

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