Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Graphics AMD Hardware Linux

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

Posted by timothy 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.
This discussion has been archived. No new comments can be posted.

AMD Publishes Preview Linux Hybrid Driver With Vulkan, OpenGL 4.5 Support More

AMD Publishes Preview Linux Hybrid Driver With Vulkan, OpenGL 4.5 Support

Comments Filter:

  • 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?!

    • Comment removed (Score:5, Interesting)

      by account_deleted ( 4530225 ) on Saturday March 19, 2016 @12:22AM (#51729559)
      Comment removed based on user account deletion

      • Well there's two things with that (Score:5, Interesting)

        by Sycraft-fu ( 314770 ) on Saturday March 19, 2016 @12:30AM (#51729585)

        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.

        • 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?

          Altho

          • Re: (Score:3, Informative)

            by bridgmanAMD ( 4376807 )

            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 o

        • Re: (Score:3)

          by Kjella ( 173770 )

          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

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

      • Re:Closed source... (Score:4, Insightful)

        by jones_supa ( 887896 ) on Saturday March 19, 2016 @12:36AM (#51729605)
        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.

        • 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

      • 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.

    • Re: (Score:3)

      by gerddie ( 173963 )

      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 [freedesktop.org]. 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.

      • 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.
        • 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.

          • Re: (Score:2)

            by vovin ( 12759 )

            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!

    • 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.

  • Good news, great trend. (Score:3)

    by blind biker ( 1066130 ) on Saturday March 19, 2016 @01:08AM (#51729733) Journal

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

  • 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

  • Is AMD the only company with Linux Vulkan drivers?

  • 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.

    • Re: (Score:2)

      by vovin ( 12759 )

      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).

    • 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?

      • 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.

    • Re: (Score:2)

      by spauldo ( 118058 )

      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 b

      • 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.

Slashdot Top Deals

You are always doing something marginal when the boss drops by your desk.

Close