AMD Finally Pushing Out Open-Source Vulkan Driver(phoronix.com)
phoronix.com
AMD Finally Pushing Out Open-Source Vulkan Driver
https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1
4 comments
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
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.
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.
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
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
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.
Except thanks to my AMD GPU, (and especially on Windows) there is zero ability to.
I've been seeing comments like this for a while, and for my most recent PC I got Radeon RX560, the card which is highly recommended for its excellent Linux support via open drivers. Yes indeed, it worked great, but it's the little things that inevitably get you: the fans on this card are supposed to be off if the GPU temperature is under 50C, but on Linux they're on 100% of the time [1], with everyone saying "just run some scripts that fiddle with lm-sensors every second". The bugzilla issue is over a year old and marked as "medium" priority so it's unlikely to be touched soon. So I plugged my older Nvidia card back and the binary blob works just fine.
[1] It baffles me that this obvious behavior needs any kind of driver support. "turn off the fan when temperature drops below X" feature was present in cars before software was even invented.
[1] It baffles me that this obvious behavior needs any kind of driver support. "turn off the fan when temperature drops below X" feature was present in cars before software was even invented.
Nvidia is so far ahead in mindshare that even when they mess up (see GeForce 400 series) they come out miles ahead of AMD/RTG (Radeon Technologies Group). At this point, even though they're making a pretty decent dent in the market through Microsoft and Sony's consoles and provide all of Apple's dedicated chips, they just won't be able to catch up to Nvidia's pixel pushers.
See: AdoredTV's The GPU War is Over https://www.youtube.com/watch?v=uN7i1bViOkU
See: AdoredTV's The GPU War is Over https://www.youtube.com/watch?v=uN7i1bViOkU
That video has some good analysis but around the 27 minute mark he starts talking about the poor sales of the RX480/580 by again referencing the Steam Surveys as support for his analysis but doesn't have the 2016 numbers. He simply points to last quarter revenue numbers from Nvidia as proof of his hypothesis for the future.
However if you look at this year's numbers for AMD's graphics division you'll see they're waaaay up despite AMD being almost absent from the Steam hardware survey.
So what's going on? Crypto currencies.
AMD's current GPUs lend themselves very well to mining crypto currencies and as a result they have been virtually unavailable on the market for the last year.
This is both good and bad for AMD. In the short term it's getting money but in the long term it's losing market share and mind share to Nvidia.
The conclusions drawn in the video might be correct but only time will tell. Things will also be interesting when all those RX 480/580 GPUs start getting dumped on ebay as the DAG file sizes for crypto currencies exceed their RAM capacity. That probably won't be until 2019 or later.
However if you look at this year's numbers for AMD's graphics division you'll see they're waaaay up despite AMD being almost absent from the Steam hardware survey.
So what's going on? Crypto currencies.
AMD's current GPUs lend themselves very well to mining crypto currencies and as a result they have been virtually unavailable on the market for the last year.
This is both good and bad for AMD. In the short term it's getting money but in the long term it's losing market share and mind share to Nvidia.
The conclusions drawn in the video might be correct but only time will tell. Things will also be interesting when all those RX 480/580 GPUs start getting dumped on ebay as the DAG file sizes for crypto currencies exceed their RAM capacity. That probably won't be until 2019 or later.
[deleted]
I'm not quite clear on what you're saying here. Whose nerve did your rant strike?
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.
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.
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.
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.
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.
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.
I believe gfx-rs is one such effort in rust, as an example.
> 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.
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.
Couldn't you use Mesa or its ilk to provide OpenGL on top of Vulkan?
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.
I'm excited because Vulkan support will mean better GPU compute support across platforms.
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
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.
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.
By platforms, I assume you mean Windows and Linux.
Yes, and android too. And depending on MoltenVK's success, maybe Apple devices.
future repo?
https://github.com/GPUOpen-Drivers
https://github.com/GPUOpen-Drivers
Yup, that’s where I’ll flip the switches to make the other repos public, when we’re ready to set the code free.
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
[2] https://www.phoronix.com/scan.php?page=article&item=amdgpu-1...