The Vulkan driver code supports back to SI (aka GCN 1.0), which launched in late 2011 and early 2012.

The code is for a userspace driver so just depends on having a suitably recent kernel driver & libdrm (already open source and already picked up by pretty much every distro on the planet). I would not call RHEL bleeding edge, although their kernel definitely has some newer bits than the base 3.10 version would suggest.

Re; having to use Linux in the first place along with an application that uses Vulkan, yes guilty as charged :)

Why do you say "the only hope is amdgpu" when radeon is the officially supported driver for your card ? Agree that you will want to move to amdgpu eventually in order to get Vulkan support, and as you know we published the first open source Vulkan support for amdgpu this morning, but other than "Vulkan vs OpenGL" I don't think you should be expecting any more performance from amdgpu than from radeon.

Just curious, which proprietary software are you talking about ? Be careful not to conflate hardware microcode (which runs on GPU state machines) with software running on the CPU. The only software running on the CPU is the on-card VBIOS, but even that is written in an interpreted bytecode with an open source interpreter included in the driver.

Citation needed. I don't think we have ever done that with Linux drivers. We have been hiring developers to contribute to the existing open source driver projects for a decade now. If you think we dumped a driver code base and walked away from it please give me an idea what you are talking about. Thanks.

Actually no. ATI supported and funded open source driver development from the time that Linux gaming became a possibility (~1998 with the introduction of DRI) until 2002 when we acquired FireGL and hoped that their pre-existing closed-source Linux workstation driver (fglrx) would be a good replacement. As it turned out, fglrx was OK for workstation users but never worked out well for consumer/desktop users. We looked at restarting the open source driver effort a couple of times but since that was also the point where DRM was starting to become a big and risky requirement (big penalties for failing to maintain robust DRM coupled with security-by-obscurity industry DRM model) the conclusion was that the risk was too high. Once we joined up with AMD we picked up a second major revenue stream (CPUs) so even if the worst-case happened on the GPU side (open source drivers providing a starting point for cracking our DRM and crippling our ability to sell into OEM markets) the company would still survive. Management was willing to accept the risk so we restarted open source driver support in 2007.

Sorry, thought I was logged in already.

Isn't the 6845 a display controller aka CRTC ?

It's actually the amdgpu driver rather than radeon, but the fix is already in the 4.7 kernel tree.

Technically yes (in the sense that we only provide VBIOS in binary form) but the code is written in a portable bytecode with open source interpreter, header files are provided for all data tables, and an open source utility is available to dump out the code and data tables.

Most of the numbers in that article came from proprietary drivers - all of the NVidia numbers and most of the AMD numbers IIRC.

Can you do a quick fact check ? The AMD open drivers are BSD-licensed, and are being used on FreeBSD today.

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.

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.

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

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