AMD Finally Pushing Out Open-Source Vulkan Driver
phoronix.com
phoronix.com
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...
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.
It's disappointing to see GPLed scientific software which won't run unless you have the closed hardware and software of a particular manufacturer.
Except thanks to my AMD GPU, (and especially on Windows) there is zero ability to.
See: AdoredTV's The GPU War is Over https://www.youtube.com/watch?v=uN7i1bViOkU
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.
[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.
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'm excited because Vulkan support will mean better GPU compute support across platforms.
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.
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.
I believe gfx-rs is one such effort in rust, as an example.
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.