Slashdot Mirror

← Back to Stories (view on slashdot.org)

AMD Building New GPU Linux Kernel Driver To Unify With Catalyst Driver

Posted by Soulskill on from the playing-well-with-others dept.

An anonymous reader writes: AMD is moving forward with their plans to develop a new open-source Linux driver model for their Radeon and FirePro graphics processors. Their unified Linux driver model is moving forward, albeit slightly different compared to what was planned early this year. They're now developing a new "AMDGPU" kernel driver to power both the open and closed-source graphics components. This new driver model will also only apply to future generations of AMD GPUs. Catalyst is not being open-sourced, but will be a self-contained user-space blob, and the DRM/libdrm/DDX components will be open-source and shared. This new model is more open-source friendly, places greater emphasis on their mainline kernel driver, and should help Catalyst support Mir and Wayland.

56 comments

  1. Still not actually open by Anonymous Coward · · Score: 0

    These hardware companies will never truly make their systems open, equally able to be used by any OS written by anyone under any license.
    The reason? They want to be able to sell the same hardware in different "models" at different prices, with the difference enforced by binary blobs.

    1. Re:Still not actually open by FlyHelicopters · · Score: 5, Insightful

      That is part of it, to be sure...

      The other part is that many trade secrets lay within those binary blobs...

      It isn't just you they don't want seeing all that, nVidia is on their radar as well...

      Plus, keep in mind that some of their technology isn't theirs, cross licensing and patents protect many things in video graphics, some of it isn't theirs to release...

      ----------------

      It is at least a step in the right direction.

    2. Re:Still not actually open by Charliemopps · · Score: 2

      I suspect that their real concern is making older cards backward compatible with new features. Do you really think last years video card can't support the newest version of DirectX? Remember the Intel chips that you could upgrade by simply soldering 2 pins together? I suspect that THAT is what they are really afraid of. The mod community figuring out how to make upgrading less important.

    3. Re:Still not actually open by FlyHelicopters · · Score: 1

      Also worth nothing is that if they couldn't sell faster, fully enabled hardware for higher prices, then they'd have to sell all their hardware for higher prices.

      AMD isn't making billions like Intel is, they need the more expensive hardware to try and earn a profit. The low end is volume, not profit. :)

    4. Re:Still not actually open by 0123456 · · Score: 1

      New DX versions often require new hardware, and you can't just stick a few wires on the board to add new instructions to the graphics units.

      Besides which, Microsoft seem to have decided that they're going to force you to buy a new OS to support new DX versions in future, so who cares?

    5. Re:Still not actually open by nadaou · · Score: 1

      > Do you really think last years video card can't support the newest
      > version of DirectX?

      I'm pretty sure that DirectX support is not that important for a Linux driver.

      > Remember the Intel chips that you could upgrade by simply soldering
      > 2 pins together? I suspect that THAT is what they are really afraid of.

      And the tens, nay hundreds of lost sales that incurred?

      > The mod community figuring out how to make upgrading less important.

      Since most or many AMD graphics these days ship as part of an APU, I'm
      also pretty sure there's more to the upgrade decision than just the
      driver.

      I'd really love the Catalyst driver to improve, right now the open source
      Radeon driver is much more stable on my system but lacks full OpenCL
      support. Anything which maximizes the open part of the driver and shrinks
      the binary blob is a gain for all of us.

      --
      ~.~
      I'm a peripheral visionary.
    6. Re:Still not actually open by Anonymous Coward · · Score: 1

      AMD publishes all their low-level hardware details, but they maintain their own drivers. Catalyst is proprietary primarily for two reasons:

      1. Third-party technology is present within the driver, and AMD has no right to Free that code up.
      2. Drivers do crazy stupid tricks to maximize FPS figures, which AMD would prefer that NVidia not know.

      This is the same for NVidia's blob as well, though, except that NVidia doesn't publish documentation. (Mostly out of laziness as they don't separate trade secrets from register documentation apparently) Except, in this case, AMD wants to parcel out all of the non-proprietary stuff into the kernel, and keep their proprietary stuff in user-space.

    7. Re:Still not actually open by Wootery · · Score: 1

      Not necessarily.

      You falsely assume that drivers can necessarily be used to 'unlock' cards. It's possible that drivers can indeed do this for AMD's cards, but you'll have to provide evidence that that's the case; it's not self-evident.

    8. Re:Still not actually open by fuzzyfuzzyfungus · · Score: 2

      The question isn't really whether last year's card can support this year's features; but whether they can do so remotely adequate speed. Recent-ish cards are turing complete on their own, and nothing forbids doing some amount of work on the CPU by building that into the driver. Frame rate probably won't be pretty, though.

    9. Re:Still not actually open by Anonymous Coward · · Score: 0

      You falsely assume that drivers can necessarily be used to 'unlock' cards. It's possible that drivers can indeed do this for AMD's cards, but you'll have to provide evidence that that's the case; it's not self-evident.

      When I worked in the GPU business in the 2000s (but not for AMD), we'd read magic numbers out of the BIOS and use them to determine which features we enabled in the drivers. I'd be surprised if manufacturers aren't doing something similar today, because it's a lot cheaper than building two different chips.

      Oddly enough, in some cases we actually disabled features in the driver if it was a high-end card, because professional apps didn't need those features and disabling those units allowed us to clock the chip faster to push more pixels and vertices through.

    10. Re:Still not actually open by fuzzyfuzzyfungus · · Score: 1

      These hardware companies will never truly make their systems open, equally able to be used by any OS written by anyone under any license. The reason? They want to be able to sell the same hardware in different "models" at different prices, with the difference enforced by binary blobs.

      I'm not holding my breath for a blobless future; but architecturally that's a somewhat antique way of enforcing a restriction: a TPM, or TPM-like crypto chip costs maybe 2-3 dollars as a discrete chip in modest volumes, likely less in considerable quantity or if the necessary functions are baked into some other chip to save on packaging and board space. If you have one of those, you don't need some big binary blob driver, or even an OSS driver talking to a binary blob in userspace in order to cripple (did I say cripple? I meant 'differentiate'). A simple "model numbers and how fast they should go.txt" configuration file becomes essentially bulletproof once it's digitally signed.

    11. Re:Still not actually open by Anonymous Coward · · Score: 1

      Yes, all details about tilt-bits are kept secret in case those filthy pirates try to copy a movie directly from the graphics card's memory.

      https://www.schneier.com/blog/...

      They didn't die with Vista and this is why you'll NEVER get fully open drivers.

    12. Re:Still not actually open by Kjella · · Score: 1

      Not as long as you can disable it or set your own signatures, what TPM gives you is a chain of trust but unless your entire system enforces it where the TPM will only load a signed BIOS, the BIOS will only load a signed OS, the OS will only load signed drivers and you don't need it for remote attestation or some other proof you're running a DRM-compliant system you can just turn it off and run the hardware with any hacked up driver you want. And making a graphics card that will only work with particular unmodified signed distros where you can't compile your own kernel is a total non-starter.

      --
      Live today, because you never know what tomorrow brings
    13. Re:Still not actually open by Khyber · · Score: 2

      "The other part is that many trade secrets lay within those binary blobs.."

      Gimme a break. By now other companies have come up with the same algorithms and processes for optimal execution of specific commands on given silicon. The shit shouldn't be patentable or trade secret in the first place as it's all math.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    14. Re:Still not actually open by Khyber · · Score: 4, Insightful

      "New DX versions often require new hardware"

      And this is why OpenGL is superior, and always has been.

      At roughly 33% less power/cycle cost vs DX which requires being sent through the CPU two or three times instead of going directly to the GPU.

      Plus, OpenGL can have anything added in - you're stuck with DX features.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    15. Re:Still not actually open by Khyber · · Score: 1

      "you'll have to provide evidence that that's the case; it's not self-evident."

      Another ignorant idiot that has never heard of Omega Drivers.

      Been around for a decade plus, still unheard of.

      Wake up. We're still implementing shit DX13 will not even have.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    16. Re:Still not actually open by Anonymous Coward · · Score: 0

      But they still need the "secret sauce", by which they can get better scores on the benchmarks, such as Futuremark. And of course the GPU vendors are not cheating on them, they are just "optimizing" their drivers.

    17. Re:Still not actually open by Anonymous Coward · · Score: 0

      Like windows 7 support?

    18. Re:Still not actually open by Nikker · · Score: 1

      Something as an obfuscated driver will definitely not stop a major competitor unmasking processing units in a lab. That is what they do to their own hardware to troubleshoot, throwing the latest Nvidia or PoverVR across the same desk would be trivial. The blob will likely never go away. What ever the hardware is really capable of we may never know but any group can set up a kick starter to do the same unmasking, for the right price.

      --
      A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
    19. Re:Still not actually open by FlyHelicopters · · Score: 1

      The hardware has nothing to do with anything here...

      This is about software, not hardware...

      Physically having access to the hardware, inspecting the chip itself, that isn't new, it has been done for a long time...

      What the software does with that hardware however, is a trade secret...

    20. Re:Still not actually open by FlyHelicopters · · Score: 1

      If that was true, then driver updates wouldn't speed up games and clean up bugs.

      The turnover is so quick and new technology keeps coming out (think Eyefinity and Surround), that both companies are racing to keep up.

      If you think the secret sauce is so simple, go checkout Eyefinity and Surround. Both work, but they do it in different ways and are compatible with games differently.

      I've used both, they each have their upsides and downsides, but they do not work the same.

    21. Re:Still not actually open by Anonymous Coward · · Score: 0

      I'd be surprised if manufacturers aren't doing something similar today, because it's a lot cheaper than building two different chips.

      That is a bit of false dichotomy though, and there are other options in the middle. It is easy enough to just have the chip enable or disable, or limit clock frequency, or reduce various limits (e.g. memory, cache size, etc.) by reading an external hardware pin(s) that need to be tied to ground vs. vcc. Even if people discover they could upgrade things with a soldering iron, many will not (or will find out they are too inexperienced or clumsy to solder surface mount stuff). It doesn't require every product having a different chip.

    22. Re:Still not actually open by Anonymous Coward · · Score: 0

      True. For the low-end boards, we blew fuses in the chip that disabled the hardware for good... normally that was because it failed the manufacturing tests, though. So there was no way to make them into a high-end board by just installing the high-end BIOS.

    23. Re:Still not actually open by fuzzyfuzzyfungus · · Score: 1

      Oh, I was thinking of putting the TPM on the GPU and treating the rest of the system as untrusted, rather than trying to control everything. Controlling everything would work as well; but steps on a lot more toes, makes a great many more things Your Problem, and lengthens the chain of critical-things-you'll-probably-screw-up-somewhere. The GPU vendor only has an economic incentive to control a few performance-related parameters tightly coupled to the GPU silicon, so as long as the card can know its own model number(presumably lasered into the die when parts were being binned) and verify the signature on a trivial little manifest file that provides performance settings for each model number, it need trust nobody else.

      As it happens, Nvidia is apparently trying something along these lines. They are apparently verifying the whole firmware, and denying specific items to unverified firmware, rather than ignoring most of the firmware and only signing for the specific items; but the effect is fairly similar. GPUs are tightly coupled to their hosts; but they have enough onboard capability to implement what is effectively a 'locked bootloader' behavior without exerting control over the remainder of the system(any more than only applying updates from signed repositories requires control of the internet).

      (What won't be pleasant, though, is Team Copyright demanding that all video memory where precious 'premium content' might momentarily reside be protected from access by everyone and everything.)

    24. Re:Still not actually open by Anonymous Coward · · Score: 0

      > Plus, keep in mind that some of their technology isn't theirs, cross licensing and patents protect many things in video graphics, some of it isn't theirs to release...

      Nvidia and ATI have been saying for at least 15 years. When are they going to start figuring out how to license those things in a way that is compatible with open source? Patents may make it incompatible with the GPL, but that doesn't mean they can't use their own license make it possible to build from source.

    25. Re:Still not actually open by Anonymous Coward · · Score: 0

      Works the same way for AMD, and has been that way at least since r6xx.
      The hardware reads bits from efuses into certain registers on reset, and from the host side you can only set more bits to disable additional units, but not clear bits to enable them.
      Now, there appears to be a odd quirks there: Dies are binned and fused off pre-packaging, it's not possible to blow additional fuses post-packaging. (that's informed speculation, but the actual events don't really agree with any other interpretation).
      So, let's assume that's true... that can lead to issues when you have stocks of chips binned for a certain product, and demand unexpectedly stays well below expectation.
      Which actually happens.
      Most recently, fully enabled tahitis destined for non-ghz-edition 7970s. After the GHz 7970 was released demand dropped massively. So, what to do with those chips sitting around? They were only tested to 925MHz after all. Answer: use them to make 7950 boost cards.
      But... those are only supposed to have 14 shader clusters enabled, not 16. So those cards got a special BIOS that sets a few bits to disable the "not supposed to be enabled" units on boot. And the driver has to do the same thing after soft-resetting the chip.
      Why do I know all that? Well, the foss radeon driver didn't properly read and apply the ATOMBIOS golden register settings table, resulting in it *not* setting those bits to disable the "extra" units after a soft reset.
      Was that way for quite a while until someone noticed the unusual power consumption and performance relative to "identical" cards with a properly fused off Tahiti.
      So radeon actually had to fix the bug and properly cripple those cards after a reset, simply to avoid the risk of damaging them. :-/
      If you dig for a bit, another earlier example were 4830s with 4850 chips, and there's likely a few more occurrences where simply no one noticed.

    26. Re:Still not actually open by erapert · · Score: 1

      At roughly 33% less power/cycle cost vs DX which requires being sent through the CPU two or three times instead of going directly to the GPU.

      Citation required.

    27. Re:Still not actually open by FlyHelicopters · · Score: 1

      When are they going to start figuring out how to license those things in a way that is compatible with open source?

      What benefit does AMD or nVidia get from doing that?

      Considering the desktop market of Linux is about 1%, give or take... Frankly I think you should be happy they do ANYTHING at all...

      Poke at them enough and they might decide to not bother.

    28. Re:Still not actually open by Anonymous Coward · · Score: 0

      > What benefit does AMD or nVidia get from doing that?
      > Considering the desktop market of Linux is about 1%, give or take... Frankly I think you should be happy they do ANYTHING at all...

      You've just made an argument for them to do nothing at all.

      >Poke at them enough and they might decide to not bother.
      You are a real bootlicker. Seriously, what kind of quisling goes around making excuses for corporations?

    29. Re:Still not actually open by Wootery · · Score: 1

      Another ignorant idiot that has never heard of Omega Drivers.

      No need to be an asshole. Also, you're wrong on all three counts.

      Do modern AMD cards still have soft-disabled capabilities? Years back I played about with drivers to unlock pixel/vertex pipelines on cards, but I read nVidia took to physically disabling their disabled pipelines. I assumed - perhaps wrongly - that unlocking in drivers was a thing of the past.

    30. Re:Still not actually open by gerald.edward.butler · · Score: 1

      Binary Blob =/= User Space

    31. Re:Still not actually open by Khyber · · Score: 1

      "Do modern AMD cards still have soft-disabled capabilities?"

      Yup. Today we just toss a firmware blob in there to unlock it and then fix the card report string.

      OTOH, that's also how cards get counterfeited, as well.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    32. Re:Still not actually open by MiPen · · Score: 1

      As long as my ATI drivers on my main pc, get better im all for it. Because Borderlands 2 on linux is a stuttering mess, compared to my other PC with a Nvidia card. Yeah thanks to patent trolls a lot of stuff is locked up tight. Lawyers would have Nvidias and Ati's balls in a fire, if they released code that they had licenced for free into the Linux community. So that explains why it probably not open sourced, plus the code probably has hidden secrets on how their chips work and they don't want the competition getting an edge.

    33. Re:Still not actually open by MiPen · · Score: 1

      Well im glad Open GL is getting a re-write soon as its showing its age. On win PC with warthuder it renders poorly with lots of artifacting. Can't wait for the new and improved Open GL :). With both ATI and Nvidia committing seriously to Linux drivers, hopefully the times of bad card support for newer cards will be over soon or shorter till fixed.

  2. systemd support? by Gothmolly · · Score: 3, Funny

    Call me when RedHat ships systemd-catalystdriver, until then I'm not touching this old, crufty technology that's clearly not ready for the Cloud.

    --
    I want to delete my account but Slashdot doesn't allow it.
    1. Re:systemd support? by Curunir_wolf · · Score: 1

      Call me when RedHat ships systemd-catalystdriver, until then I'm not touching this old, crufty technology that's clearly not ready for the Cloud.

      Good one.

      --
      "Somebody has to do something. It's just incredibly pathetic it has to be us."
      --- Jerry Garcia
    2. Re:systemd support? by blackomegax · · Score: 1

      Due to dependencies in software, this will also require systemd-nvidiadriver to be loaded and running simultaneously, requiring one of each GPU to be installed. I can't wait for systemd-3dfx to be thrown in!

    3. Re:systemd support? by Anonymous Coward · · Score: 0

      It will happen next week and after that we can start testing the systemd-catalystdriver-cupsd, which will integrate the essential printer driver subsystem into the simple and non-bloated init software. That will show to the non-believers, who spread all those false claims against systemd's widely approved technological superiority.

  3. Interesting legally by l2718 · · Score: 2

    Moving binary blob into user space while keeping the kernel driver free would be an excellent move. I'm of course assuming that this "open source" driver will actually be free software like the current X.org driver.

  4. hum by Anonymous Coward · · Score: 0

    So Intel and AMD cpu's(architecture, registers, etc...) are open to the public but they can't do the same with the gpu's? I mean DirectX and other licensed technology is not actually embedded(circuitry) onto the GPU itself, is it?. Don't need to open source the drivers or Catalyst software just open up the gpu architecture for the public for the purpose of developing their own video drivers.

    1. Re:hum by armanox · · Score: 1

      AMD GPU arch is Open....

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
  5. Cool by pouar · · Score: 1

    Now if Catalyst gets good enough it might be an option to start using now.

    --
    while :;do if windows sucks;then mv windows /dev/null;pacman -Sy linux;fi;done
    1. Re:Cool by pouar · · Score: 1

      Although a lot of problems with Cataclyst will probably be solved as a result of this

      --
      while :;do if windows sucks;then mv windows /dev/null;pacman -Sy linux;fi;done
  6. Right... by Anonymous Coward · · Score: 0

    So, AMD has showed its ineptitude at software once more by stating

    This new driver model will also only apply to future generations of AMD GPUs.

    This tells me that AMD does not care about its actual users that plan their purchasing today. It also tells me that AMD does not have a workable software model today because they can't backport changes even for today's supported hardware.

    So Linux remains Intel GPU for low powered graphics or nVidia for higher performance OpenGL/CUDA or games?

    1. Re:Right... by armanox · · Score: 1

      Or they'll just be on Catalyst-legacy for quite a while...

      It's also not the first time that AMD has done something like this - remember when they dropped everything older then the HD 5000 series?

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    2. Re:Right... by Bengie · · Score: 2

      "future generations of AMD GPUs"

      The "future" GPUs support protected mode and preemptive context switching, first of their kind. You will actually be able to pass a virtual memory address to the GPU, and it will respect that virtual memory space just like the CPU, and can even issue page faults to have the kernel load from the page file. Their new GPUs will fully integrate into the virtual memory system. I'm sure this has a lot to do with their lack of backwards compatibility.

  7. xkcd 927 by Anonymous Coward · · Score: 0

    http://xkcd.com/927/

    Situation: We have 2 kernel drivers for AMD GPUs
    That's ridicoulus lets write one driver to rule them all.
    Situation: We have 3 kernel drivers for AMD GPUs

  8. Great, but... by Anonymous Coward · · Score: 0

    Will it support systemd-x11?

  9. Meh, no Systemd support? by ntropia · · Score: 0

    I didn't see any plans to be integrated in the new Systemd OS, so it's a "dead in the cradle" project for me. Wake me up when they see the light.

  10. Can I fucking get HDCP off this thing yet? by mikelieman · · Score: 1

    Seriously. I'd just like to see the ouput of my cablecard network device...

    --
    Technology -- No Place For Wimps! Grateful Dead and Jerry Garcia Chatroom -- http://www.wemissjerry.org
  11. What a load of market-BS by Anonymous Coward · · Score: 0

    This is clearly a PR only announcement. Caveats: I'm a "FLAME" - Former Loyal AMd Employee. I still own stock in AMD, but I truly detest bull-guano.

    If AMD was actually interested in supporting Linux/OpenSource, a lot of truly Mho-Rhon-Ick projects would be killed. Example: CodeXL - if You were working on Linux, you got sacked, while neanderthalensis level of skills of developers were kept on.

  12. AMD should just die on Linux platform by Anonymous Coward · · Score: 0

    No one will missing them.

    They keep changing their model and try everything to stay closed. At the end, they keep producing shit for 30 years. They should just learn how to produce an open sourced video driver from intel or just die like a rotten rat.

  13. Closed or open... by Torp · · Score: 1

    Do AMD linux graphic drivers actually work now? Last time I checked on winehq, there were a lot more people complaining about graphics problems on cards than on Nvidia cards...

    --
    I apologize for the lack of a signature.
    1. Re:Closed or open... by jbrandv · · Score: 1

      We are using Catalyst drivers to run 4K monitors in our operations center under Xubuntu. They are working great for the operator workstations! I had to get the latest drivers from the AMD site in order to get both the resolution and HDMI sound working but work it does. Love these big 50 inch monitors. No we don't play games we're just keeping the lights on. (Electric utility) We are also running CentOS with Nvidia cards to operate our video wall. Each has 4 Nvidia cards with 4, 4K outputs each to drive 8, 80" custom built Planar monitors acting as a single logical screen. I've had much more problems getting the Nvidia drivers working but Nvidia tech support has been very helpful.