Forgot your password?
typodupeerror
AMD Graphics Open Source Linux

AMD Overhauls Open-Source Linux Driver 126

Posted by Soulskill
from the added-support-for-individual-tree-leaf-motion-and-rump-physics dept.
An anonymous reader writes "AMD's open-source developer has posted an incredible set of 165 patches against the Linux kernel that provide support for a few major features to their Linux graphics driver. Namely, the open-source Radeon Linux driver now supports dynamic power management on hardware going back to the Radeon HD 2000 (R600) generation. The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been a major limiting factor for open-source AMD users where laptops have been warm and there is diminished battery power. The patches also provide basic support for the AMD Radeon HD 8000 'Sea Islands' graphics processors on their open-source Linux driver."
This discussion has been archived. No new comments can be posted.

AMD Overhauls Open-Source Linux Driver

Comments Filter:
  • Yay AMD (Score:5, Insightful)

    by Noishe (829350) on Wednesday June 26, 2013 @01:21PM (#44115471)

    This is a great step in the right direction. Hopefully it's not the last step.

    • Re:Yay AMD (Score:5, Insightful)

      by fuzzyfuzzyfungus (1223518) on Wednesday June 26, 2013 @01:23PM (#44115505) Journal

      This is a great step in the right direction. Hopefully it's not the last step.

      AMD's penurious financials do make me nervous; but their strategic change in favor of *gasp* actually working to integrate support for their product into the kernel development process proper seems to be sincere and ongoing. Slower moving than one would like; but since they began their course-change, they've kept it up.

  • Good guys AMD (Score:5, Insightful)

    by Reliable Windmill (2932227) on Wednesday June 26, 2013 @01:23PM (#44115495)

    I'm excited about getting the upcoming Kaveri. APUs are the way to go unless you have needs that call for huge CPU or GPU power, and I think AMD is definitely leading the innovation here. It's a nice bonus if I will be able to run Linux with good graphics acceleration as well.

    • Re:Good guys AMD (Score:5, Interesting)

      by jkflying (2190798) on Wednesday June 26, 2013 @01:51PM (#44115759)

      Personally, I'm excited about HUMA and what it will mean for scientific computing. The second half of this year will be exciting!

    • Re:Good guys AMD (Score:5, Interesting)

      by Belial6 (794905) on Wednesday June 26, 2013 @03:22PM (#44116629)
      I have to agree. My son's laptop with an A10 processor beats both mine and my wife's laptops with i5. They all cost about the same amount. My laptop is fine for most tasks, but fails at gaming. My son's A10 handles every game he has tried without problem. There may be some that won't run well on it, but until we find one that doesn't, anything more would be wasted money.
  • by snarfies (115214) on Wednesday June 26, 2013 @01:26PM (#44115531) Homepage

    Per http://stallman.org/to-4chan.html [stallman.org]:

    "Regarding graphics accelerators for PCs, ATI mostly cooperates with the free software movement, while nVidia is totally hostile. ATI has released free drivers.

    However, the ATI drivers use nonfree microcode blobs, whereas most of nVidia's products (excepting the most recent ones) work ok with Nouveau, which is entirely free and has no blobs.

    Thus, paradoxically, if you want to be free you need to get a not-very-recent nVidia accelerator.

    I wish ATI would free this microcode, or put it in ROM, so that we could endorse its products and stop preferring the products of a company that is no friend of ours."

    This sort of thing gets discussed quite a bit on 4chan's technolo/g/y board. Also, installing Gentoo.

    • by fuzzyfuzzyfungus (1223518) on Wednesday June 26, 2013 @01:35PM (#44115631) Journal

      Blobs are definitely not ideal; but I've never really understood the distinction between people who put them in ROM and people who require them to be loaded at initialization time(as long as they aren't assholes about redistribution: if Distro X is legally unable to distribute firmware.bin and I have to go to your site, download the Windows driver, and then chop it open to get firmware.bin, just to get an unaltered copy of your firmware to run with your device, I'm going to be pissed).

      Both approaches involve exactly the same binary firmware blob, one just stores it on comparatively expensive, board-space-consuming, flash ROM and one stores it on system mass storage.

      Firmware that is open is better than either; but closed firmware that is handled behind the curtain on the card seems no better than closed firmware that is supplied to the card during startup(again, assuming proper redistribution terms and proper driver support for that aspect of initializing the device).

      • by greg1104 (461138)

        There are a few types of overhead involved in firmware distribution, and making that part of your system software pushes that work toward open source communities in a way they resent. If you look at things like Debian's policy [debian.org], none of these blobs fit their guidelines. That means those firmware blobs go into their non-free repository. That wart is annoying enough that people regularly try to eliminate it altogether [machard.org]. All of that means some of the overhead manufacturers are saving by not having flash on t

        • by jkflying (2190798)

          The entire point of firmware being upgradable is that it is... well... upgradable. Not only that, but different versions of firmware may be required for different versions of software. This way it is much easier to ensure compatibility, because the driver has the firmware baked into it.

          • by greg1104 (461138)

            Much easier for who though? It's certainly easier for manufacturers to move all their firmware issues so the OS has to deal with them. But the cost of doing that work is being pushed toward kernel developers and packagers. Whether the end result is better or worse is complicated, but that's not why people like Stallman complain. What you can't argue with is that it's frustrating for a Linux kernel developer to spend time chasing down a bug that's actually inside of the firmware blob, or in the part of t

          • by icebike (68054) on Wednesday June 26, 2013 @03:03PM (#44116453)

            The entire point of firmware being upgradable is that it is... well... upgradable. Not only that, but different versions of firmware may be required for different versions of software. This way it is much easier to ensure compatibility, because the driver has the firmware baked into it.

            If it were firmware, I would be in agreement.

            The objection to binary blobs, that are simply loaded into the device as firmware is sort of short sighted,
            in that it punishes vendors that actually plan in a method of upgrading their products with new firmware.

            But by and large, that isn't the issue here.
            Far to many of these blobs are loaded loaded into main memory and run as a process under the operating system,
            free to do just about anything.

            If blobs were ONLY firmware, they could run ONLY on the device, and could be loaded once at installation time.
            Very few fall into this category. (Some wifi chips do load this way upon every boot).

            Far too many remain running in main memory.

            • If blobs were ONLY firmware, they could run ONLY on the device, and could be loaded once at installation time. Very few fall into this category. (Some wifi chips do load this way upon every boot).

              Even when a firmware blob runs only on the device I would expect it to be loaded every time the device is reset, particularly for a WiFi chip. If you want the blob to be persistent you must add a local Flash to the WiFi subsystem, which increases the BOM cost. And at the very low price in WiFi this is just not acceptable anymore, the chipmaker would sell nothing. So there's no such local storage (except for a minimum bootloader maybe, and that could be in the chip in ROM) and the chip will load it's executa

      • by r1348 (2567295)

        Storing the binary firmware on the user's PC makes it way easier to be updated.

      • by Anonymous Coward

        That's because you're a poo poo head.

      • by Boltronics (180064) on Wednesday June 26, 2013 @09:53PM (#44119237) Homepage

        Yes, this is my opinion exactly. I recently blogged about this exact issue, and why I think the FSF, RMS, Trisquel, etc. all treat it differently - and I don't think it's a good enough reason.

        https://systemsaviour.com/2013/06/16/why-i-will-not-back-fsfs-guidelines-for-free-software-distributions/ [systemsaviour.com]

        I'll point out for Slasdot readers that, in the case of the radeon driver, it loads microcode into the card - not a huge firmware blob. The FSF just refers to microcode as firmware, so does not distinguish between them. The microcode is between 2K and 31K, depending on the model of the device. If running Debian GNU/Linux with the firmware-linux-nonfree package installed, these microcode files should be located under /lib/firmware/radeon.

    • by Bill, Shooter of Bul (629286) on Wednesday June 26, 2013 @01:36PM (#44115639) Journal

      I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software. Same code, just different home.

      • by TubeSteak (669689) on Wednesday June 26, 2013 @02:03PM (#44115867) Journal

        I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software.

        Licensing and distribution.

        Anything that's in hardware has already dealt with the issues of licensing and distribution.
        Closed source software represents and entirely different beast for free software distribution.

      • by icebike (68054)

        I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software. Same code, just different home.

        If that was what was being discussed it wouldn't be an issue.

        If your closed source firmware actually ran on the card that would be fine. Load it once on boot and
        it can only run in the Video card's GPUs, and interaction between it and the OS are somewhat
        more controllable.

        But take for example the Radeon driver (the so called open source one). It takes almost a meg of
        main memory. The closed source one takes even more memory. Its running all the time that
        your system is up.

        Clearly its not just firmware we are

        • But take for example the Radeon driver (the so called open source one). It takes almost a meg of main memory. The closed source one takes even more memory. Its running all the time that your system is up.

          Clearly its not just firmware we are talking about here.

          The main memory aspect is taken up by the open source driver code. The firmware blob goes straight to the hardware.

      • by LourensV (856614) on Wednesday June 26, 2013 @03:55PM (#44116935)

        I don't understand why simply putting the closed source firmware on the card suddenly makes it ok for free software. Same code, just different home.

        Back in the days of the Open Graphics Project [wikipedia.org] (since defunct, although Timothy N. Miller [binghamton.edu] is still working in this area and the mailing list [duskglow.com] is still active for those interested in the subject), we had several discussions about the borders between Free software, open firmware, and open hardware.

        As I understood the FSF's position at that time, the point is that if the firmware is stored on the host, it can be changed, and frequently is (i.e. firmware updates). Typically, the manufacturer has some sort of assembler/compiler tool to convert firmware written in a slightly higher level language to a binary that is loaded into the hardware, which then contains some simplistic CPU to run it (that's how OGD1 worked anyway). So, the firmware is really just specialised software, and for the whole thing to be Free, you should have access to the complete corresponding source code, plus the tools to compile it, or at least a description of the bitstream format so you can create those. This last part is then an instance of the general rule that for hardware to be Free software-friendly, all its programming interfaces should be completely documented.

        If the code is put into ROM, it cannot be changed without physically changing the hardware (e.g. desoldering the chip and putting in another one). At that point, the FSF considers it immutable, and therefore not having the firmware source code doesn't restrict the user's freedom to change the firmware, since they don't have any anyway. The consequences are a bit funny in practice, as you noted, but it is (as always with the FSF) a very consistent position.

        We (of the OGP-related Open Hardware Foundation, now also defunct; the whole thing was just a bit too ambitious and too far ahead of its time) argued that since hardware can be changed (i.e. you can desolder and replace that ROM), keeping the design a secret restricts the users freedom just as well. So, we should have open hardware, which would be completely (not just programming interfaces, but the whole design) documented and can therefore be changed/extended/repaired/parts-reused by the user. The FSF wasn't hostile to that idea, but considered it beyond their scope. Of course, any open hardware would automatically also be Free software-friendly.

        I tend to agree that in practice, especially if there are no firmware updates forthcoming but it's just a cost-savings measure, loading the code from the host rather than from a ROM is a marginal issue. Strictly speaking though, I do think that the FSF have a point.

        • In practice, that translates into a question of whether the firmware resides on a flash memory or ROM device. If it's on flash, it's alterable and updatable, but typically, the flash would contain firmware that is independent of the system software that resides on the main computer, and just has code that would cause the device to respond to the commands it is given. So whether it's on flash or ROM would make no difference in that sense.

          In the real world, when is flash used, and when is ROM used? When

    • Re: (Score:2, Insightful)

      by unixisc (2429386)

      Per http://stallman.org/to-4chan.html [stallman.org]:

      "Regarding graphics accelerators for PCs, ATI mostly cooperates with the free software movement, while nVidia is totally hostile. ATI has released free drivers.

      However, the ATI drivers use nonfree microcode blobs, whereas most of nVidia's products (excepting the most recent ones) work ok with Nouveau, which is entirely free and has no blobs.

      Thus, paradoxically, if you want to be free you need to get a not-very-recent nVidia accelerator.

      I wish ATI would free this microcode, or put it in ROM, so that we could endorse its products and stop preferring the products of a company that is no friend of ours."

      This sort of thing gets discussed quite a bit on 4chan's technolo/g/y board. Also, installing Gentoo.

      I won't comment on his liberated firmware blob comment, or the stupidity of his suggestion of putting it in ROM (and calling it a circuit), but why does RMS insist on calling the company ATI, when it's been acquired, merged & digested by AMD?

  • Thank God. (Score:4, Interesting)

    by intermodal (534361) on Wednesday June 26, 2013 @01:27PM (#44115553) Homepage Journal

    My laptop ran ridiculously hot on the open-source until I got the closed-source drivers to install properly. Let's hope the fix means default installs of Ubuntu won't melt your igloo.

  • In 4 to 5 months I'll be replacing my laptop and I would LOVE to have better graphics performance but the stability and power saving of my intel's integrated & merely adequate GPU's will probably be the deciding factor. Of course by then AMD is going to have to compete with Haswell too...
    • by icebike (68054)

      In 4 to 5 months I'll be replacing my laptop and I would LOVE to have better graphics performance but the stability and power saving of my intel's integrated & merely adequate GPU's will probably be the deciding factor. Of course by then AMD is going to have to compete with Haswell too...

      The thing is, on new machines, your chip set will probably still be able to run proprietary drivers.
      The opensource drivers for AMD generally apply only to the older chips sets.

  • Maybe there's a boat load of trade secrets in the closed source drivers, but I'd imagine that this is a perfect area for patents to be used against competitors. It would seem to me that most hardware vendors would benefit from open sourcing their main drivers and documenting them lightly so that they could offload maintenance costs for smaller OSes to "the community" while relying on patent law to protect novel inventions.

    • Most likely because of IP-licensing that does not allow certain portion of their code to be open-sourced.
      • by Anonymous Coward on Wednesday June 26, 2013 @02:38PM (#44116195)

        NVidia tried that and made the mistake of saying who the IP that was the roadblock was: Sun. Sun Microsystems said "There is nothing that they have of ours that we would refuse to have open sourced". NVidia's response was to clam up and let the fanbois repeat the claim for ever more.

    • by 0123456 (636235) on Wednesday June 26, 2013 @02:49PM (#44116311)

      Maybe there's a boat load of trade secrets in the closed source drivers, but I'd imagine that this is a perfect area for patents to be used against competitors.

      You have that backwards. If their drivers are inadvertantly violating a patent owned by Joe's Patent Trolls, Inc, then making the drivers open source makes that violation much easier to spot.

      Patents are a huge disincentive to releasing open source drivers. Another issue the company I worked for had was hardware bugs, because having to put bizarre workarounds in closed source drivers was no big deal, but a bit embarrassing in open source.

    • It would seem to me that most hardware vendors would benefit from open sourcing their main drivers and documenting them lightly so that they could offload maintenance costs for smaller OSes to "the community" while relying on patent law to protect novel inventions.

      I'd rather have a manufacturer-supported, in-house, full-feature, high-performance driver than something that is left in the hands of unpaid "community members", with a driver which supports the hardware properly 10 years after the device has been on the market.

  • In which version will this be included?
    • Re: (Score:2, Informative)

      by Anonymous Coward

      I know it's difficult to click, but it says in the first sentence in the document linked first. Come on!

      ---8

      These are the radeon patches for 3.11. Some of these patches
      are huge so, it might be easier to review things here:
      http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.11-wip

      I'll send a formal pull in request in the next day or two.

      Highlights of this series:
      - DPM support (Dynamic Power Management) for r6xx-SI
      - Support for CIK (Sea Islands): modesetting, 3D, compute, UVD
      - ASPM support for R6xx-SI

    • by Jmc23 (2353706)
      Why don't you RTFA to find out? It's in the first sentence!
  • by JDG1980 (2438906) on Wednesday June 26, 2013 @01:34PM (#44115627)

    I can't help but wonder if this is related to AMD's recent console design wins, especially PS4. Up until now, there hasn't really been a strong business case for putting a lot of effort into Unix-based video drivers. But since PS4 runs on FreeBSD and uses OpenGL as its API layer, a lot of the effort that AMD put into the drivers there can probably be ported over to the Linux drivers without much trouble. The PS4 and Xbone GPUs both use AMD's standard Graphics Core Next (GCN) architecture.

    • The PS4 runs a FreeBSD kernel? Who knew...? Kind wonder why... the BSD side of the tree has code older than Adam...
      • by sconeu (64226)

        Why? Licensing.

      • by bobbomo (877614)

        The PS3 supposedly ran a modified FreeBSD as well. So between experience and licensing, it does make some sense.

    • and made it the year or Linux, say it ain't so...

    • There has no proof of any kind that PS4 is running FreeBSD or any *nix for that matter. SSYI

  • The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been a major limiting factor for open-source AMD users where laptops have been warm and there is diminished battery power.

    A compute rate that varies with temperature would seem to be a bug, rather than a feature. I don't want a GPU that does that. I need repeatable Gazebo simulations.

    • I'm not sure if that was sarcasm. If it was, ignore the following.

      Then turn off dynamic power/thermal management (e.g. Turbo Boost on Intel processors, I'm sure it has fancy marketing names on various GPUs/etc). You'll get consistent performance, at the expense of maximum possible speed.

      Such systems typically have a nominal guaranteed rate, which is all you get if you turn off this feature, keeping the hardware within the acceptable maximum continuous-load power/thermal envelope, assuming that your power/

    • It is a feature. Too hot -> fans running at full tilt -> more power consumption. Mostly for laptops, and you can turn this off in Catalyst. I wonder why you didn't know this. NVidia's GPUs and even most CPUs do this.

    • by Bengie (1121981)

      A compute rate that varies with temperature would seem to be a bug, rather than a feature.

      Only in an environment where a stable temperature is a feature, unless you think crashing is a good thing, chips can only get so warm.

    • by EvanED (569694)

      A compute rate that varies with temperature would seem to be a bug, rather than a feature.

      Read again: The inability to re-clock the GPU frequencies and voltages dynamically based upon load has been... The reclocking (or lack thereof) affects temperature, not is caused by it.

      (Though the other responses are technically accurate, I think they miss the main point of the complaint.)

    • by slamb (119285) *

      A compute rate that varies with temperature would seem to be a bug, rather than a feature. I don't want a GPU that does that. I need repeatable Gazebo simulations.

      I think they're talking about the opposite (a temperature that depends on load), which your CPU has probably been doing for a long, long time.

      But you've lost this one, anyway; modern Intel processors have Turbo Boost [intel.com], meaning the performance does indeed depend on temperature. I was scared, too, from a worst-case provisioning perspective in an

  • It's great that AMD is improving support for a lot of their hardware on Linux. In fact, as a result, my next graphics card purchase will be from AMD.

    One thing I'd like to see them address is older hardware... I have an older ATI chipset (RS600) on my laptop. It's pretty much unusable due to some severe bugs. It would be awesome if they opened up enough specifications on older cards to allow those people who still have them to fix buggy drivers since I don't expect them to go back and add in support on hardw

  • Thank Thank you.
  • by AC-x (735297) on Wednesday June 26, 2013 @08:05PM (#44118709)

    So, the announcement 6 years ago that they were fully supporting open source drivers and documentation [archive.org] is finally coming to fruition?

  • by xiando (770382) on Wednesday June 26, 2013 @08:32PM (#44118875) Homepage Journal
    I've got a HD3300 IGP and that works alright with the open source driver. Not good, but alright. Then I bought a HD7850 and tried using the latest open source drivers. By latest I mean MESA snapsot from 20130619 and all the latest pieces. It is utterly broken and useless. Scrolling in applications cause artifacts. Starting some applications (like LibreOffice) just makes X hang. There is no usable open source drivers for the latest AMD cards. Yes there is something available, but it's a broken joke you can't actually use.

    It is possible to use the open source driver to have one monitor on the HD3300 IGP and two monitors on the HD7850 without accelration on any of the monitors. Try the same setup with accelration and their driver segfaults.

    I basically bought a HD7850 because AMD claims there's a open source driver for it. When you try it you'll find that there is no such thing as a functioning open source driver for this card and cards in this family.

    The new kernel patches are probably a step in the right direction, but it won't help with the latest cards. AMD developers have in their wizdom decided to provide no 2D driver at all, instead they rely on 3D for 2D using MESA and "glamor". glamor is a buggy joke at this point and it will probably take years before that changes. I wish I could point to AMD and say "they've got great open source support" but the truth is that it's crappy at best. Intel is the only alternative if you want working free software drivers as of now.
    • Re: (Score:3, Insightful)

      by ak3ldama (554026)

      Does intel make an HD7850 counterpart? Your comment lacks a lot of perspective.

      Full prick mode: Also I wouldn't say that they claim there's a open source driver for it. It is not like they market it that way with a big sticker on the box. There are a lot of missing features yet for the whole south islands series [x.org] and there are a lot of bugs [freedesktop.org]. This is /. you should know these things.

      Nice mode again: It is one thing that your card is a year old, but you should have bought something older or done some more resea

Never ask two questions in a business letter. The reply will discuss the one you are least interested, and say nothing about the other.

Working...