Slashdot Mirror

← Back to Stories (view on slashdot.org)

AMD Publishes Preview Linux Hybrid Driver With Vulkan, OpenGL 4.5 Support (phoronix.com)

Posted by timothy on from the time-to-move-the-pixels dept.

An anonymous reader writes: AMD has finally published the previously talked about closed-source Radeon Vulkan driver for Linux. Announced by AMD via the Phoronix Forums is the new hybrid driver dubbed "AMD GPU-PRO Beta Driver – Linux." This closed-source user-space driver provides the first AMD Vulkan support on Linux along with OpenGL 4.5, OpenCL 2.0, and VDPAU video acceleration capabilities. But in using the open-source AMDGPU kernel driver, only the very latest AMD GPUs are currently supported (GCN 1.2+). Update: 03/19 03:22 GMT by T : Sorry for the borked link; now fixed.

51 comments

  1. Re:Is it written in Rust? by epyT-R · · Score: 1

    javascript of course.

  2. Closed source... by paskie · · Score: 2

    So it's how long, about 8 years, since AMD announced it's going open source with its GPU drivers?

    They did say it's going to take a while to fully shelve Catalyst, and I could understood if the new open source drivers didn't fully support 5+ years old GPUs due to various transition periods etc. But really?!

    --
    It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
    1. Re:Closed source... by hairyfeet · · Score: 5, Interesting

      Uhhh...did you bother to read TFA? AMD has ASKED the community for help, given them the code, which is exactly what the community asked for in the first place and...nothing.

      So its kinda hypocritical to bitch when the community has got the code and just haven't gotten it done yet. Maybe they are having issues, maybe they are too busy dealing with the SystemD debacle, who knows, but the community asked for code and they got it so the ball is in their court now.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    2. Re:Closed source... by jones_supa · · Score: 3, Insightful

      It's amazing that people still think that the open source community is some kind of magical software mill at which you can throw software and expect it to come out polished. There's a lot of broken stuff out there that no one bothers to touch. In this case the even bigger problem is that the "community" quite does not have the production capacity compared to a team of professional full-time GPU engineers. Especially when GPU driver code is extremely challenging.

    3. Re: Closed source... by Anonymous Coward · · Score: 0

      Which moderator mark hairyfeet's comment as troll? There is nothing wrong with what was written.

    4. Re:Closed source... by gerddie · · Score: 2

      So it's how long, about 8 years, since AMD announced it's going open source with its GPU drivers?

      They did say it's going to take a while to fully shelve Catalyst, and I could understood if the new open source drivers didn't fully support 5+ years old GPUs due to various transition periods etc. But really?!

      This is the open source driver status. Looks pretty good to me. Regarding the new driver, it is part of their mixed open source and closed source strategy: The kernel module is open, AMD provides the closed source user space that that should provide the latest and greatest features, while the community provides user space part as open source that might have to catch up a little performance wise.

    5. Re:Closed source... by drinkypoo · · Score: 0

      Uhhh...did you bother to read TFA? AMD has ASKED the community for help, given them the code, which is exactly what the community asked for in the first place and...nothing.

      All the nerds with self-respect already jumped ship for nVidia since ATI has been shitting on users since forever. AMD and ATI were not a good match; AMD good, ATI bad. Now they have to live with their decisions.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Closed source... by drinkypoo · · Score: 0

      In this case the even bigger problem is that the "community" quite does not have the production capacity compared to a team of professional full-time GPU engineers. Especially when GPU driver code is extremely challenging.

      And when, given the incredibly shit state of ATI graphics drivers, we would expect correcting the problem to be an exceptionally large problem. Since their drivers are so much less functional/more defective than the competition, one would expect it to take extra work to unfuck them. ATI has proven time and again (since the earliest days of Windows, really) that it cannot make a decent graphics driver... Some of the first bluescreens I ever saw were due to their Mach64 "effort". I would hate to inherit their work.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:Closed source... by Anonymous Coward · · Score: 0

      Nvidia have been GREAT for OSS...

    8. Re:Closed source... by shaitand · · Score: 1

      While I am a fan of all open source, on the utilitarian side that does sound like a somewhat reasonable compromise to me.

      There are two big issues we run into with the closed drivers. The first is obviously the problem of kernel support which this solves. The second is the x.org issue that comes up when having to route the display through something like a usb3 laptop dock which is currently only possible with open drivers.

    9. Re:Closed source... by bridgmanAMD · · Score: 1

      The kernel and X drivers are both open source. This is an early preview driver; we're still working out where best to publish the userspace bits for libdrm, X driver and multimedia drivers. Primary goal for this early release was to start getting Linux Vulkan drivers out in public; there'll be a couple of months of tweaking & tuning (and evolving how we deploy) before we get to a 1.0-type production stack.

    10. Re:Closed source... by vovin · · Score: 1

      I for one am not a gamer but I do occasionally dabble in the OpenGL, OpenGLES and presumably I will get pulled into Vulkan at some point.

      However I am not a fan of NVidia cards on my desktop and I only use the OpenSource AMD drivers for which I have had good luck.

      So I absolutely appreciate all the hard work and will mostly likely buy one of the cards that is reported to work with this preview on Tuesday for my semi-annual computer re-fresh.

      Good luck with the deployment and keep up the good work.

      Thanks!

    11. Re:Closed source... by Anonymous Coward · · Score: 0

      Any chance we're going to get SR-IOV support for Radeon cards in the (perhaps far) future, so we could have acceleration on a Linux host and 1 guest OS with just one card?

    12. Re: Closed source... by Redbehrend · · Score: 1

      Remember AMD doesn't have the resources to put a full staff on this yet. Hopefully with zen they'll get enough market share to put more time into it. I don't get why people talk crap about OSS. In the past they have released it and said add code and no one did, so I can see why they take their time.

    13. Re:Closed source... by Anonymous Coward · · Score: 0

      The situation is pretty fucking good actually.

      They have an opensource kernel part, a defined interface via ioctls etc., and a choice of a crappy open source user part or a high quality closed source user part.

      This takes away one of the two main problems with closed source drivers: dependency on some crap old version of the kernel; also dependency on a particular kernel (hello FreeBSD). The other problem is the Xorg module interface which changes from version to version, so you end up stuck running some crap old version of the Xorg server. They haven't (or maybe they have) provided an open source shim for Xorg, so you're still stuck with a crap X server, but it's better than having a crap kernel and crap X server, which is what you get with Nvidia cards when they go legacy.

      The Intel GPUs (I have several) have opensource drivers, which is convenient, but they are also not very good drivers with lots of multi-year outstanding OpenGL bugs.

      -puddingpimp

    14. Re:Closed source... by Anonymous Coward · · Score: 0

      > the incredibly shit state of ATI graphics drivers
      > Some of the first bluescreens I ever saw were due to their Mach64 "effort".

      You're stuck in the 90's.

  3. Well there's two things with that by Sycraft-fu · · Score: 4, Interesting

    The first is that writing a graphics driver is REALLY HARD. I think a lot of the people who were complaining and asking didn't really understand the magnitude of what they were talking about. They were people who'd maybe messed around with a network driver or something and said "Huh, drivers aren't that bad." Graphics drivers are ENORMOUS things, exceedingly complex. Lots and lots and lots of code that interacts with a lot of stuff in different ways. I mean the GPU is literally a little computer in many respects. Also GPUs change fast. New generations come out every 2 years or so and are often radically different architectures with tons of new features. So you have continual new work to do. It isn't like a NIC or RAID controller where 95%+ of the features might be copy-paste from the previous gen. I don't think a lot of people understood just how big an undertaking a GPU driver is.

    The second is that I think people forget there's a REASON the drivers are closed source and that is they make use of licensed code that cannot be open sourced. Well guess what? That code gets licensed for a reason. It makes developing this stuff easier, more feasible. You don't have that as an OSS developer, of course, so your life is going to be more difficult. I think there is a perception that the closed source drivers are closed "just because" or that the licensed code in them could be ripped out and replaced easily. No, not so much it seems. There's a reason for it.

    1. Re:Well there's two things with that by BlueCoder · · Score: 1

      I would actually like some transparency from AMD for your second point. They are using a third party developer? Or maybe third party tools? I can see that maybe 5 years ago. As the experts for their own hardware I would expect them to hire/contract a platform expert and make their own infrastructure which would be equally open source. Publicize the developers name and simply point to him and we can rake him over the coals.

      I can maybe see why they might not have a dedicated FreeBSD developer. But Linux?

      Although on second thoughts the main developer they have probably is a FreeBSD man since the PS3 an PS4 uses a modified FreeBSD kernel and system.

    2. Re:Well there's two things with that by bridgmanAMD · · Score: 3, Informative

      I would actually like some transparency from AMD for your second point. They are using a third party developer? Or maybe third party tools? I can see that maybe 5 years ago.

      Nope, all in-house developers. The issue with opening up the remaining bits (at least OpenCL and Vulkan) is that the drivers are cross-OS and include a lot of OS-specific bits (for other OSes than Linux) that we don't have the right to expose publicly. Opening up the code basically involves turning them into Linux-specific drivers, typically making the OS-independent bits smaller but removing any proprietary abstractions that might have been there before, eg rewriting anything that happened to use Windows or MacOS abstractions in the common code.

      As the experts for their own hardware I would expect them to hire/contract a platform expert and make their own infrastructure which would be equally open source. Publicize the developers name and simply point to him and we can rake him over the coals.

      Seriously, adding *one* person isn't going to even scratch the surface. Adding 20 people maybe... we're talking about 10,000+ KSLOC of code just for OpenGL.

    3. Re:Well there's two things with that by Anonymous Coward · · Score: 0

      That code gets licensed for a reason. It makes developing this stuff easier, more feasible. You don't have that as an OSS developer, of course, so your life is going to be more difficult. I think there is a perception that the closed source drivers are closed "just because" or that the licensed code in them could be ripped out and replaced easily. No, not so much it seems. There's a reason for it.

      Writing around the IBM's, SGI's (now NVidia's), ATI's and others all-encompassing fundamental patents is the challenging part compared to the technical details.

    4. Re:Well there's two things with that by Anonymous Coward · · Score: 0

      Will this improve the situation of catalyst being always behind in latest kernel support? I saw some people say the new driver has dkms in it.

    5. Re:Well there's two things with that by Kjella · · Score: 2

      The first is that writing a graphics driver is REALLY HARD. I think a lot of the people who were complaining and asking didn't really understand the magnitude of what they were talking about. They were people who'd maybe messed around with a network driver or something and said "Huh, drivers aren't that bad." Graphics drivers are ENORMOUS things, exceedingly complex. Lots and lots and lots of code that interacts with a lot of stuff in different ways. I mean the GPU is literally a little computer in many respects. Also GPUs change fast. New generations come out every 2 years or so and are often radically different architectures with tons of new features. So you have continual new work to do. It isn't like a NIC or RAID controller where 95%+ of the features might be copy-paste from the previous gen. I don't think a lot of people understood just how big an undertaking a GPU driver is.

      The real issue is that there's no "assembler-level" standard like x86 and ARM. Before Vulkan, there hasn't even been an "intermediate representation-level" standard, which would be something like Java bytecode. Implementing DirectX/OpenGL has been like re-implementing say .NET or Java, huge and evolving high level libraries. Open source has kind of made the divide internally with Gallium3D, drivers write towards that and mesa runs on top of any Gallium3D driver. AMDGPU is another such divide for the latest AMD generation, where the same kernel driver works with both open and closed source UMDs (user mode drivers) which is cutting the stack at a lower level but for AMD only.

      You can kinda see the stack fracturing now:
      Hardware <--> AMDGPU <--> User mode driver (UMD) for Vulkan <--> OpenGL to Vulkan translation layer <--> "Traditional" applications
      Hardware <--> open source <--> closed source, but going open according to AMD <--> closed UMD, Vulkan native or mesa-based shim <--> "Traditional" applications

      We're finally approaching a situation where there are parts of the stack to replace, it doesn't have to be an all-or-nothing choice. That will make a huge difference.

      --
      Live today, because you never know what tomorrow brings
    6. Re:Well there's two things with that by maestroX · · Score: 0

      Isn't it possible to use a firmware layer between driver and hardware?

    7. Re:Well there's two things with that by drinkypoo · · Score: 0

      Did I say it wasn't? I said the community is being hypocritical because for fucking YEARS what has been their mantra? What were their words? "If you just give us the code we'll do the rest".

      Nice straw man, asshole. The words were "give us the code and the documentation" and ATI has been stingy with both, trickling them out in little dribs and drabs until very recently; they provided most of the code finally, but still won't provide good documentation.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:Well there's two things with that by Anonymous Coward · · Score: 0

      Watch out everyone, hairyfeet is on the rag again.

      captcha: calamity

    9. Re:Well there's two things with that by One+With+Whisp · · Score: 0

      The issue with opening up the remaining bits (at least OpenCL and Vulkan) is that the drivers are cross-OS and include a lot of OS-specific bits (for other OSes than Linux) that we don't have the right to expose publicly.

      Is the windows display driver API not publicly disclosed? I thought anyone could write a display driver for windows.

    10. Re:Well there's two things with that by StillAnonymous · · Score: 0

      This is what I was thinking. A driver is supposed to be an interface to the hardware. It shouldn't be overly complicated. Why is there so much processing going on there? Shouldn't that kind of processing be either in the graphics subsystem (D3D, OpenGL, Vulkan) or in the card's firmware?

      Reminds me of the old WinModems and WinPrinters.

    11. Re:Well there's two things with that by Anonymous Coward · · Score: 0

      Maybe they could stop making a driver for each OS and let the chips/cards "eat" DirectX/OpenGL/Vulkan right away. This way, with a firmware update it would work with every OS.

    12. Re:Well there's two things with that by Anonymous Coward · · Score: 0

      You can. Sort of.
      But really, you will still have the driver at some level.

      What I would prefer to see more is drivers coming with the hardware.
      Plug-and-play can be done with complex hardware simply by doing the ol' switcheroo by mounting a generic storage device, install driver that disables the storage and allows access to the GPU, printer or whatever else.
      Drivers being a separate thing from hardware was the biggest pain in the ass and it simply doesn't need to happen now that memory is stupidly cheap.
      You can fit 500GB in the space of a damn finger tip now.

      Then you do the usual firmware management program that can let you reflash the hardware and provide extra features.

      The only other way to do it is to rewrite the driver model system that lets a piece of hardware describe the interfaces it has in some format that is future-proof.
      Can be done, but, well, I really don't know why it isn't being done.
      Hardware -> poll the controller -> "I use this, that and the next thing", "okay man, here is your resources", "thanks brah". Literally Android permissions system tier. (but not terrible)
      Instead, we have the current overly-complex system. The system can still work with hardware management panels as well, in the exact same way.

    13. Re:Well there's two things with that by bridgmanAMD · · Score: 1

      It won't magically solve the problem but will help in a few different ways.

    14. Re:Well there's two things with that by bridgmanAMD · · Score: 1

      Last time I checked it was publicly available but under a fairly restrictive EULA. There's a big difference between being able to write a display driver for Windows and having the right to redistribute the API materials as part of a non-Windows driver. Also there are more OSes than just Linux/Windows involved.

  4. Good news, great trend. by blind+biker · · Score: 2

    Having more manufacturers release Linux drivers, even closed-source, is great, especially considering the other trend of Microsoft fucking their customers with Windows updates.

    --
    "The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
  5. Personally, I believe... by tlambert · · Score: 1

    Personally, I believe...

    We should condemn them for implementing in user space, as this article implies, because EXPORT_SYMBOL_GPL is not a pain in the ass of everyone who wants to keep their proprietary code secret.

    Those protection domain crossing overheads are the fault of the driver writers, not the "give us your f*cking source code that we are unable to write ourselves because we are incompetent" extortionists, right?

    It's not like every graphics card company steals from each other, and doesn't want to be held accountable. "We make hardware; we would never steal!"... I'm totally right, right?

    1. Re:Personally, I believe... by Anonymous Coward · · Score: 0

      What in the flying fuck. They have been working on an open source kernel driver for a year or two now (amdgpu) and this is built upon it.

      The rest *are* userspace APIs and shader compilers, you're not going to put that in the kernel.

    2. Re:Personally, I believe... by shaitand · · Score: 1

      As long as the API's to utilize them are open and can be reasonably targeted. The big problem right now is in the space of laptop docks. Currently, all non-proprietary docks (usb3) use the same chipsets and all say they don't support linux. The manufacturer of the chipset actually does produce an open driver for linux but that driver requires you to replace your fast closed driver with the open driver because they needed access to the features in it so they could turn around and re-route the display image through the usb port.

      People are quick to mock saying just get a usb hub. That's fine if all you want is a keyboard, mouse, you could even shoehorn in a usb nic but if you want to be able to reliably support external dual displays without a proprietary (as in laptop manufacturer) dock you need a usb3 dock not a hub.

    3. Re:Personally, I believe... by bridgmanAMD · · Score: 1

      We also have fully-open userspace drivers which actively use nearly all of the open source kernel driver functionality.

  6. So, what about Nvidia and Intel? by edxwelch · · Score: 1

    Is AMD the only company with Linux Vulkan drivers?

    1. Re:So, what about Nvidia and Intel? by drinkypoo · · Score: 2

      Is AMD the only company with Linux Vulkan drivers?

      No, and learn to internet. Are you new? nVidia has Vulkan support for more cards than AMD does.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:So, what about Nvidia and Intel? by Anonymous Coward · · Score: 0

      Nvidia and Intel had Vulkan drivers from day 1 when the Vulkan beta was released. AMD is just catching up.

    3. Re:So, what about Nvidia and Intel? by bridgmanAMD · · Score: 1

      Actually AMD had Vulkan drivers from day 1 as well, but the Linux version was held up by our move from closed-source Catalyst to amdgpu hybrid.

  7. Will it work? by Anonymous Coward · · Score: 0

    The reason I am asking is because getting a proprietary, closed-source AMD graphics card driver to work under Linux still is in my to-do list, despite numerous attempts.

    1. Re:Will it work? by shaitand · · Score: 1

      I haven't tried it but from what I gather the closed portion is now userspace, the open portion is the kernel module. So that resolves the biggest headache.

  8. OT: Learning OpenGL? by TeknoHog · · Score: 1

    With Vulkan out, is there any point in learning OpenGL right now? I'd like to accelerate my iterative art (see sig) with something like render to texture, and the higher-level tools don't seem too helpful for such tasks.

    --
    Escher was the first MC and Giger invented the HR department.
    1. Re:OT: Learning OpenGL? by vovin · · Score: 1

      Vulkan shares a lot of commonality with OpenGL at a high level.
      It also will be quite some time before enough Vulkan hardware is available for a significant industry shift to happen.
      Think of it as the difference between OpenGL and OpenGLES. Early OpenGL is a quite different beast from the current version. ES is close (as intended) but not the same.

      Go ahead and learn OpenGL it will make learning Vulkan easier (IMO) as all the basic concepts will transfer (writing shaders et. al).

    2. Re:OT: Learning OpenGL? by orledrat · · Score: 1

      With Vulkan out, is there any point in learning OpenGL right now? I'd like to accelerate my iterative art (see sig) with something like render to texture, and the higher-level tools don't seem too helpful for such tasks.

      For offline GPU rendering you might as well look at OpenCL right now, perhaps with a python wrapper (pyOpenCL) or some such so that it's easier to handle, as OpenCL can be a bit of a handful if you don't have much experience with GPU/shader programming or numerical linear algebra. I've read that the Processing language has (some) OpenCL support, that may be up your alley?

    3. Re:OT: Learning OpenGL? by spauldo · · Score: 1

      When, and for whom, do you wish to write OpenGL/Vulkan for?

      If you plan on writing code for platforms that universally support Vulkan (or will by the time you actually write your code), then learn that. If you plan on writing code for platforms that don't or won't anytime soon, learn OpenGL.

      An example: Blender is just now removing OpenGL 1.3 code from the codebase, because the official policy is to enable backwards compatibility for low-end and older cards (there's a lot of third-world use of Blender). I believe the current release was the first to officially drop Windows XP support. If you wanted to write code for Blender, OpenGL is the way to go.

      If you want to write for PCs, learn OpenGL. There's a ton of legacy OpenGL code out there and no GPU manufacturer is going to drop support any time soon. For high-end games that require the fastest and newest machines, Vulkan is an option, but probably not the way to go for a couple years at least.

      On the other hand, if you want to write code for phones and tablets that will all have Vulkan support, then learn that.

      --
      Those who can't do, teach. Those who can't teach either, do tech support.
    4. Re:OT: Learning OpenGL? by TeknoHog · · Score: 1

      Good points. I've decided to give OpenGL a go, since I want to maintain portability to a variety of machines, including somewhat older/lower-end ones. For example, I may want to run small demos on RasPi type machines, rather than hauling big expensive machines to an exhibition.

      --
      Escher was the first MC and Giger invented the HR department.
    5. Re:OT: Learning OpenGL? by TeknoHog · · Score: 1

      For offline GPU rendering you might as well look at OpenCL right now, perhaps with a python wrapper (pyOpenCL) or some such so that it's easier to handle, as OpenCL can be a bit of a handful if you don't have much experience with GPU/shader programming or numerical linear algebra. I've read that the Processing language has (some) OpenCL support, that may be up your alley?

      Ah, I've also considered both OpenCL and Processing. The latter looks interesting for education/workshop purposes, but too much of a monolithic framework to my tastes -- I have enough programming/math/physics background to hate any kind of handholding, and these days I mostly code in Julia. I did have a brief stint contributing to an OpenCL project a while ago, and I'll probably have to return to it at some point.

      --
      Escher was the first MC and Giger invented the HR department.