The Feature Differences Now Between AMD's Two OpenGL & Two Vulkan Linux Drivers

Written by Michael Larabel in Radeon on 12 December 2017 at 10:26 AM EST. 35 Comments
For modern AMD graphics cards there are two OpenGL drivers and two Vulkan drivers available to Linux users/gamers that support the same modern AMD GPUs, not counting the older AMD Linux drivers, etc. Here's a rundown now on how those drivers compare.

With AMDGPU-PRO 17.50 now allowing you to mix and match driver components and AMD finally open-sourcing their official Vulkan driver, the scene may be even more confusing about which AMD Linux driver(s) to use depending upon your use-case.

For summing up some of the technical differences between these OpenGL/Vulkan drivers, below is a comparison of the exposed OpenGL and Vulkan capabilities for each of these drivers.

Upgrading To 17.50

First off, if moving from the AMDGPU-PRO 17.40 to AMDGPU-PRO 17.50 with using the official Vulkan driver and closed-source OpenGL driver, there are a few updates...

The official AMD Vulkan driver in 17.50 (the driver that's being open-sourced) has picked up support for VK_KHX_device_group_creation support. This is very notable as it's used for "device groups" with multi-GPU rendering. This needed Vulkan support is in place with this official AMD Vulkan driver now for a "CrossFire-like" experience, well, once Vulkan game engines begin making use of device groups.

AMDGPU-PRO 17.50 also bumps the version to Vulkan 1.0.65 over Vulkan 1.0.54. The driver has also updated its KHR_dedicated_allocation support from revision 1 to 3.

Other new Vulkan extensions flipped on in 17.50 are VK_KHR_descriptor_update_template, VK_KHX_device_group, VK_KHR_external_fence support being added. More format features are also shown now as supported while ETC2 texture compression is reported as disabled.

Meanwhile, the closed-source OpenGL driver has seen some improvements too in 17.50. The closed-source OpenGL driver in 17.50 still exposes OpenGL 4.5 but has added ARB_robustness support and ARB_spirv_extensions (but not yet ARB_gl_spirv) and KHR_no_error. So their closed-source, shared-code-with-Windows OpenGL driver is closer to OpenGL 4.6 but notably missing is the complete SPIR-V support.

From Official Vulkan / Radeon Open Vulkan To RADV

Now a look at what changes if going from the official Radeon Vulkan driver (what's long been used by AMDGPU-PRO and is what now is being open-sourced) to the existing open-source RADV Vulkan driver found within Mesa...

RADV currently doesn't have the KHX_device_group_creation support that was added to the official Vulkan driver in today's 17.50 driver update. There is also a number of differences in the exposed physical device limits between these competing drivers.

Among the Vulkan extensions that are found in the official AMD Vulkan driver but not in RADV includes: VK_KHX_device_group VK_AMD_shader_ballot VK_AMD_shader_trinary_minmax VK_AMD_shader_explicit_vertex_parameter VK_AMD_gcn_shader VK_AMD_negative_viewport_height VK_AMD_gpu_shader_half_float VK_AMD_gpu_shader_half_float_fetch VK_AMD_shader_fragment_mask VK_AMD_wave_limits VK_AMD_texture_gather_bias_lod VK_AMD_mixed_attachment_samples VK_EXT_sample_locations VK_AMD_gpu_shader_int16 VK_EXT_shader_subgroup_vote VK_KHR_16bit_storage VK_AMD_gpa_interface VK_EXT_shader_subgroup_ballot VK_EXT_shader_stencil_export VK_EXT_shader_viewport_index_layer VK_EXT_shader_viewport_index_layer. Yes, a lot of AMD-developed Vulkan extensions that are not found in RADV at this time plus a few other extensions.

But extensions that RADV has that the official driver does not include: VK_KHR_incremental_present VK_KHR_push_descriptor VK_KHR_variable_pointers VK_KHX_multiview VK_EXT_external_memory_dma_buf VK_EXT_global_priority VK_AMD_draw_indirect_count.

The official Vulkan driver also supports the physical device features of shaderStorageImageMultisample and shaderInt16 while the device features found in RADV not in the official driver right now are sparseBinding and alphaToOne.

From Official AMDGPU-PRO OpenGL To RadeonSI Gallium3D

RadeonSI is basically dominating the modern AMD Linux graphics driver stack when it comes to OpenGL support... The big exception right now is that RadeonSI doesn't have full OpenGL compatibility context support, which is needed by some legacy/workstation applications as well as a few awkward Linux games.

Both the AMDGPU-PRO OpenGL and RadeonSI expose OpenGL 4.5 right now and each inching closer to OpenGL 4.6.

Extensions found in the proprietary/PRO OpenGL driver but not RadeonSI currently include GL_AMDX_debug_output GL_AMD_blend_minmax_factor GL_AMD_debug_output GL_AMD_depth_clamp_separate GL_AMD_framebuffer_sample_positions GL_AMD_gcn_shader GL_AMD_gpu_shader_half_float and a lot of other AMD prefixed vendor extensions.

Among the RadeonSI extensions not found in the PRO driver are: GL_ANGLE_texture_compression_dxt5, GL_ARB_ES3_2_compatibility GL_ARB_compute_variable_group_size GL_ARB_shader_atomic_counter_ops GL_ARB_shader_clock and a few MESA_ and NVX_ functions.

So What Should I Use?

Due to AMD's expanding Linux graphics stack and continuing to improve their options/support, the situation can understandably be confusing, especially for new Linux users not accustomed to the Linux GPU space. Most Radeon Linux customers on a modern distribution should be best off with RadeonSI as their OpenGL driver for GCN 1.0+ GPUs rather than using the AMDGPU-PRO OpenGL driver. The AMDGPU-PRO OpenGL driver is really just best off for those needing the OpenGL compatibility context and other isolated cases.

With the Vulkan driver though the situation is a bit more confusing especially with AMD finally open-sourcing their official Vulkan driver. RADV has turned into a fairly mature open-source Vulkan driver that's part of Mesa and supports most features of the official Vulkan driver. The performance though has generally been slower than the official Vulkan driver.

I will have some AMDGPU-PRO vs. RadeonSI/RADV tests coming up in the next few hours to clear up the performance situation some more with the latest driver versions, so stay tuned. But as far as who will win the battle of RADV vs. "Radeon Open Vulkan" for the competing open-source Vulkan driver options, only time will tell. AMD will remain committed to their existing official, shared-code-across-platforms Vulkan driver while it will be a matter of how much community support gets behind this to-be-opened driver and how quickly it will begin appearing in various Linux distributions, etc.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week