6 ms·

AMD Finally Pushing Out Open-Source Vulkan Driver

161 points by vanburen 9y ago

ajr0 9y ago
future repo? https://github.com/GPUOpen-Drivers https://github.com/GPUOpen-Drivers
- rys 9y ago
  Yup, that’s where I’ll flip the switches to make the other repos public, when we’re ready to set the code free.
Honeybunch 9y ago
The only downside I see to this is that the Vulkan space for AMD will leave OpenGL development in the dust. The OpenGL drivers for AMD cards have been sub par on Windows and Linux for a long time. This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan. That said as someone who does a bunch of Vulkan development on AMD platforms on Linux I'm really excited. There's nothing bad with some healthy competition.
- ktta 9y ago
  Is that such a bad thing? Any game dev that's not going to use Vulkan will use a game engine, which will pretty much handle vulkan for them. I'm excited because Vulkan support will mean better GPU compute support across platforms.
  - Honeybunch 9y ago
    Not necessarily. I see a few small games that roll their own OpenGL/DX11 engines due to unique requirements that game engines can't easily accommodate. I don't have any good examples off the top of my head but it's not uncommon to see indie game blog posts talking about why they're not using Unity/Unreal
    - outworlder 9y ago
      Minecraft would be one. Bigger games, Elite Dangerous rolled its own, which is able to use both OpenGL and DX (even though the OpenGL support is no longer useful). Most indie games do not roll their own, however.
  - outworlder 9y ago
    By platforms, I assume you mean Windows and Linux.
    - ktta 9y ago
      Yes, and android too. And depending on MoltenVK's success, maybe Apple devices.
- masklinn 9y ago
  Couldn't you use Mesa or its ilk to provide OpenGL on top of Vulkan?
- dognotdog 9y ago
  I cannot think of a single use case from the top of my head where I wouldn't prefer Vulkan over modern OpenGL. In my experience it isn't actually harder to use, even though it's technically "lower level". However, I see the next useful level up from Vulkan not in OpenGL, but an actual 3D engine like Unity, which manages state more usefully from the application's POV than OpenGL.
  - Honeybunch 9y ago
    Vulkan takes time to bootstrap. Even if I have a Vulkan bootstrap that works well for one project it may be unusable for another. If I have infinite time I'll use Vulkan but for a lot of people OpenGL is just going to be faster to iterate on. Sometimes this development speed is important while at the same time using an engine like Unity or Unreal isn't going to provide the desired look and or feel. It's a rare intersection but it does exist.
    - gpm 9y ago
      How long until there are libraries that wrap vulkan well enough that you don't have the bootstrap time though (apart from initial learning time of a new api, that will affect current devs once and future devs never)? I believe gfx-rs is one such effort in rust, as an example.
- exDM69 9y ago
  > This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan. Most apps don't want to directly use OpenGL either. It's a terrible API that's not much simpler than Vulkan for the programmer (Vulkan is low level and verbose, OpenGL has 25 years of legacy baggage you need to be aware of). OpenGL also has a history of really buggy implementations out there, especially in mobile space. Doing anything with GL requires mountains of QA work on different HW/OS/driver combinations. Ideally there would be some kind of middleware/engine/framework that takes out the tedium of doing graphics with the GPU. But no open source project has really found adoption on this front, it's Unity or UE, both proprietary. One reason for this is that OpenGL is so badly designed with its stateful API that any kind of middleware short of a full game engine is very difficult to get right. Vulkan should be the choice for all green field development right now. OpenGL will stay to support the legacy stuff, but there are no compelling arguments to use it where Vulkan is supported.
bryanlarsen 9y ago
My rant on my frustrations with the NVidia Linux drivers obviously struck a nerve a few days ago: https://news.ycombinator.com/item?id=15877262 https://news.ycombinator.com/item?id=15877262 Between ROCm and GPUOpen, the AMD software team really seems to be setting themselves up for success. If their hardware team hits a home run or Nvidia makes a misstep, perhaps we could see a significant shift in market share.
- discoursism 9y ago
  I'm not quite clear on what you're saying here. Whose nerve did your rant strike?
  - DiThi 9y ago
    Everybody that upvoted that comment to the top, at least.
  - jolopy 9y ago
    That project needed to be planned to be open sourced from the start, to avoid licensing conflicts from third party's software. This has been in the making for months, if not years.
- rhn_mk1 9y ago
  HIP [0] is particularly promising, because it may free scientific institutions from their CUDA shackles. It's disappointing to see GPLed scientific software which won't run unless you have the closed hardware and software of a particular manufacturer. [0] https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP
  - mrguyorama 9y ago
    Boy how much I've wanted to fool around with neural networks and machine learning. It would be really fun. Except thanks to my AMD GPU, (and especially on Windows) there is zero ability to.
- jagger27 9y ago
kilburn 9y ago
For those who -like me- don't know much about what this means, here goes a summary: There are basically two ways to program graphics on linux: OpenGL and Vulkan. OpenGL is older and more high-level, while Vulkan is newer and lower level, which should let programmers extract the most out of your hardware (at a development cost). On the OpenGL front AMD open sourced and pushed for their RadeonSI driver. It works fine, although some say that its performance is somewhat worse than the (closed source) nvidia drivers. On the Vulkan front, two years ago AMD promised to open source their driver some day. They've now announced that the source release is imminent. However, this is a driver they've developed to share as much as possible between windows and linux, and hence it doesn't "play along" with the linux-specific inter-driver sharing efforts (Mesa [1]). Due to the long-shot promise, one guy developed RADV: a Vulkan driver that builds on Mesa. The advantage of this driver is that since it's always been open source and plays well with the linux driver-sharing efforts, it's been packaged on most distros and is really easy to use. The disadvantge is that its performance is lackluster. RADV's author has stated that he will continue to work on it despite AMD finally open-sourcing their Vulkan driver. People hope that having access to the AMD Vulkan driver will allow RADV to reap some optimitzations from it. At this point you are ready to check the very recent benchmarks to see how performance compares between opengl/vulkan and radv/amd's vulkan driver [2]. TL/DR: NVidia propietary driver > RadeonSI OpenGL > AMD's Vulkan > RADV. I don't know how they compare drivers' performance between NVidia and AMD, but this seems to be the sentiment. [1] https://en.wikipedia.org/wiki/Mesa_%28computer_graphics%29 https://en.wikipedia.org/wiki/Mesa_%28computer_graphics%29 [2] https://www.phoronix.com/scan.php?page=article&item=amdgpu-1750-open&num=1 https://www.phoronix.com/scan.php?page=article&item=amdgpu-1...

161 points by vanburen 9y ago

ajr0 9y ago

future repo? https://github.com/GPUOpen-Drivers https://github.com/GPUOpen-Drivers

rys 9y ago
Yup, that’s where I’ll flip the switches to make the other repos public, when we’re ready to set the code free.

Honeybunch 9y ago

The only downside I see to this is that the Vulkan space for AMD will leave OpenGL development in the dust. The OpenGL drivers for AMD cards have been sub par on Windows and Linux for a long time. This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan. That said as someone who does a bunch of Vulkan development on AMD platforms on Linux I'm really excited. There's nothing bad with some healthy competition.

ktta 9y ago
Is that such a bad thing? Any game dev that's not going to use Vulkan will use a game engine, which will pretty much handle vulkan for them. I'm excited because Vulkan support will mean better GPU compute support across platforms.
- Honeybunch 9y ago
  Not necessarily. I see a few small games that roll their own OpenGL/DX11 engines due to unique requirements that game engines can't easily accommodate. I don't have any good examples off the top of my head but it's not uncommon to see indie game blog posts talking about why they're not using Unity/Unreal
  - outworlder 9y ago
    Minecraft would be one. Bigger games, Elite Dangerous rolled its own, which is able to use both OpenGL and DX (even though the OpenGL support is no longer useful). Most indie games do not roll their own, however.
- outworlder 9y ago
  By platforms, I assume you mean Windows and Linux.
  - ktta 9y ago
    Yes, and android too. And depending on MoltenVK's success, maybe Apple devices.
masklinn 9y ago
Couldn't you use Mesa or its ilk to provide OpenGL on top of Vulkan?
dognotdog 9y ago
I cannot think of a single use case from the top of my head where I wouldn't prefer Vulkan over modern OpenGL. In my experience it isn't actually harder to use, even though it's technically "lower level". However, I see the next useful level up from Vulkan not in OpenGL, but an actual 3D engine like Unity, which manages state more usefully from the application's POV than OpenGL.
- Honeybunch 9y ago
  Vulkan takes time to bootstrap. Even if I have a Vulkan bootstrap that works well for one project it may be unusable for another. If I have infinite time I'll use Vulkan but for a lot of people OpenGL is just going to be faster to iterate on. Sometimes this development speed is important while at the same time using an engine like Unity or Unreal isn't going to provide the desired look and or feel. It's a rare intersection but it does exist.
  - gpm 9y ago
    How long until there are libraries that wrap vulkan well enough that you don't have the bootstrap time though (apart from initial learning time of a new api, that will affect current devs once and future devs never)? I believe gfx-rs is one such effort in rust, as an example.
exDM69 9y ago
> This doesn't matter much for AAA games but smaller games and most non-game applications don't need and shouldn't want to use Vulkan. Most apps don't want to directly use OpenGL either. It's a terrible API that's not much simpler than Vulkan for the programmer (Vulkan is low level and verbose, OpenGL has 25 years of legacy baggage you need to be aware of). OpenGL also has a history of really buggy implementations out there, especially in mobile space. Doing anything with GL requires mountains of QA work on different HW/OS/driver combinations. Ideally there would be some kind of middleware/engine/framework that takes out the tedium of doing graphics with the GPU. But no open source project has really found adoption on this front, it's Unity or UE, both proprietary. One reason for this is that OpenGL is so badly designed with its stateful API that any kind of middleware short of a full game engine is very difficult to get right. Vulkan should be the choice for all green field development right now. OpenGL will stay to support the legacy stuff, but there are no compelling arguments to use it where Vulkan is supported.

bryanlarsen 9y ago

My rant on my frustrations with the NVidia Linux drivers obviously struck a nerve a few days ago: https://news.ycombinator.com/item?id=15877262 https://news.ycombinator.com/item?id=15877262 Between ROCm and GPUOpen, the AMD software team really seems to be setting themselves up for success. If their hardware team hits a home run or Nvidia makes a misstep, perhaps we could see a significant shift in market share.

discoursism 9y ago
I'm not quite clear on what you're saying here. Whose nerve did your rant strike?
- DiThi 9y ago
  Everybody that upvoted that comment to the top, at least.
- jolopy 9y ago
  That project needed to be planned to be open sourced from the start, to avoid licensing conflicts from third party's software. This has been in the making for months, if not years.
rhn_mk1 9y ago
HIP [0] is particularly promising, because it may free scientific institutions from their CUDA shackles. It's disappointing to see GPLed scientific software which won't run unless you have the closed hardware and software of a particular manufacturer. [0] https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP
- mrguyorama 9y ago
  Boy how much I've wanted to fool around with neural networks and machine learning. It would be really fun. Except thanks to my AMD GPU, (and especially on Windows) there is zero ability to.
jagger27 9y ago

kilburn 9y ago

For those who -like me- don't know much about what this means, here goes a summary: There are basically two ways to program graphics on linux: OpenGL and Vulkan. OpenGL is older and more high-level, while Vulkan is newer and lower level, which should let programmers extract the most out of your hardware (at a development cost). On the OpenGL front AMD open sourced and pushed for their RadeonSI driver. It works fine, although some say that its performance is somewhat worse than the (closed source) nvidia drivers. On the Vulkan front, two years ago AMD promised to open source their driver some day. They've now announced that the source release is imminent. However, this is a driver they've developed to share as much as possible between windows and linux, and hence it doesn't "play along" with the linux-specific inter-driver sharing efforts (Mesa [1]). Due to the long-shot promise, one guy developed RADV: a Vulkan driver that builds on Mesa. The advantage of this driver is that since it's always been open source and plays well with the linux driver-sharing efforts, it's been packaged on most distros and is really easy to use. The disadvantge is that its performance is lackluster. RADV's author has stated that he will continue to work on it despite AMD finally open-sourcing their Vulkan driver. People hope that having access to the AMD Vulkan driver will allow RADV to reap some optimitzations from it. At this point you are ready to check the very recent benchmarks to see how performance compares between opengl/vulkan and radv/amd's vulkan driver [2]. TL/DR: NVidia propietary driver > RadeonSI OpenGL > AMD's Vulkan > RADV. I don't know how they compare drivers' performance between NVidia and AMD, but this seems to be the sentiment. [1] https://en.wikipedia.org/wiki/Mesa_%28computer_graphics%29 https://en.wikipedia.org/wiki/Mesa_%28computer_graphics%29 [2] https://www.phoronix.com/scan.php?page=article&item=amdgpu-1750-open&num=1 https://www.phoronix.com/scan.php?page=article&item=amdgpu-1...