Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.
OpenGL is still very much alive and kicking, with the release today of OpenGL 4.6 to further improve the API.

From the press release:
QuoteThe Khronos™ Group, an open consortium of leading hardware and software companies, announces from the SIGGRAPH 2017 Conference the immediate public availability of the OpenGL® 4.6 specification. OpenGL 4.6 integrates the functionality of numerous ARB and EXT extensions created by Khronos members AMD, Intel, and NVIDIA into core, including the capability to ingest SPIR-V™ shaders.

SPIR-V is a Khronos-defined standard intermediate language for parallel compute and graphics, which enables content creators to simplify their shader authoring and management pipelines while providing significant source shading language flexibility. OpenGL 4.6 adds support for ingesting SPIR-V shaders to the core specification, guaranteeing that SPIR-V shaders will be widely supported by OpenGL implementations.


OpenGL 4.6 has officially added these into the core spec:
  • GL_ARB_gl_spirv and GL_ARB_spirv_extensions to standardize SPIR-V support for OpenGL
  • GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry
  • GL_ARB_pipeline_statistics_query and GL_ARB_transform_feedback_overflow_query standardize OpenGL support for features available in Direct3D
  • GL_ARB_texture_filter_anisotropic (based on GL_EXT_texture_filter_anisotropic) brings previously IP encumbered functionality into OpenGL to improve the visual quality of textured scenes
  • GL_ARB_polygon_offset_clamp (based on GL_EXT_polygon_offset_clamp) suppresses a common visual artifact known as a “light leak” associated with rendering shadows
  • GL_ARB_shader_atomic_counter_ops and GL_ARB_shader_group_vote add shader intrinsics supported by all desktop vendors to improve functionality and performance
  • GL_KHR_no_error reduces driver overhead by allowing the application to indicate that it expects error-free operation so errors need not be generated

They also released two new extensions:
  • GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput
  • WGL_ARB_create_context_no_error and GXL_ARB_create_context_no_error allow no error contexts to be created with WGL or GLX that support the GL_KHR_no_error extension

They also released a set of extensions to allow OpenGL and OpenGL ES interoperability with Vulkan and Direct3D.

You can see the full OpenGL 4.6 specifications here.

NVIDIA have also just released a new beta 381.26.11 driver which pulls in support for OpenGL 4.6. They do note that they're mainly for developers looking to experiment with GL4.6. Article taken from GamingOnLinux.com.
Tags: OpenGL
21 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
26 comments
Page: 1/3»
  Go to:

Corben Jul 31, 2017
Hmm... I'm atm on the 381.26.08 beta driver for Steam VR on Linux, as it looks its successor versions doesn't have the needed extensions. This driver could be installed via this ppa: https://launchpad.net/%7Emamarley/+archive/ubuntu/nvidia-dev/+packages.
I wondering if this will be updated to have 381.26.11.
And if so, if Steam VR on Linux works better for me then. Atm I have quite some issues getting it up and running.
GustyGhost Jul 31, 2017
Mesa finally caught up to 4.5 and now they release this...
Abu_Shawarib Jul 31, 2017
Quoting: AnxiousInfusionMesa finally caught up to 4.5 and now they release this...
It have been a few months now.
sr_ls_boy Jul 31, 2017
Quoting: AnxiousInfusionMesa finally caught up to 4.5 and now they release this...
Most of these extensions are marked as done by Mesa.

  • GL_ARB_indirect_parameters

  • GL_ARB_shader_draw_parameters

  • GL_ARB_pipeline_statistics_query

  • GL_ARB_transform_feedback_overflow_query

  • GL_ARB_shader_atomic_counter_ops

  • GL_ARB_shader_group_vote

  • GL_KHR_no_error(started)

  • GL_ARB_gl_spirv(patches sent today)



That just leaves the following extensions.
  • GL_ARB_spirv_extensions

  • GL_ARB_texture_filter_anisotropic

  • GL_ARB_polygon_offset_clamp




Last edited by sr_ls_boy on 31 July 2017 at 2:25 pm UTC
edo Jul 31, 2017
so opengl now can read spirv shaders? like using vulkan shaders and to be able to use them for opengl too? that sounds useful for feral which still create both renderers for their games.
Shmerl Jul 31, 2017
QuoteGL_ARB_texture_filter_anisotropic

Previously IP encumbered? Is it now free?
Jajcus Jul 31, 2017
Quoting: edoso opengl now can read spirv shaders? like using vulkan shaders and to be able to use them for opengl too? that sounds useful for feral which still create both renderers for their games.

That would mean targeting OpenGL 4.6, which would limit compatibility to devices and drivers compatible with OpenGL 4.6. This would be probably the same set that can handle Vulkan. Would it be any better than supporting only Vulkan? I don't think so.

SPIR-V in OpenGL is useful for those who don't want to use Vulkan (prefer higher level API) but would like to take advantage of SPIR-V.
etonbears Jul 31, 2017
This is quite nice, but possibly more important is the Vulkan Portability Initiative

The aim here is to identify the subset of Vulkan that can map directly to D3D12 and Metal, provide open-source libraries to effect the mapping and cross-compilers for spir-v to the D3D12/Metal intermediate shader languages.

That would possibly offer developers a single API ( Vulkan ) to target almost every platform at minimal performance cost.

The question would then be whether that is good enough for the main AAA developers ( it certainly would be for smaller teams ), and whether the parties that control D3D12 and Metal attempt to sabotage the initiative...
Purple Library Guy Jul 31, 2017
Quoting: etonbearsThis is quite nice, but possibly more important is the Vulkan Portability Initiative

The aim here is to identify the subset of Vulkan that can map directly to D3D12 and Metal, provide open-source libraries to effect the mapping and cross-compilers for spir-v to the D3D12/Metal intermediate shader languages.

That would possibly offer developers a single API ( Vulkan ) to target almost every platform at minimal performance cost.

The question would then be whether that is good enough for the main AAA developers ( it certainly would be for smaller teams ), and whether the parties that control D3D12 and Metal attempt to sabotage the initiative...
That does sound interesting. I wish it well.
DrMcCoy Jul 31, 2017
Quoting: edoso opengl now can read spirv shaders? like using vulkan shaders and to be able to use them for opengl too?

Yes and no. The source form for Vulkan shaders is GLSL too (*), or rather a variant of GLSL that is still essentially GLSL 4.5. You give that source to glslang, which compiles it into SPIR-V bytecode.

(*) At least usually. The SPIR-V specs are open, and you can theoretically build a compiler that creates SPIR-V bytecode out of something else. But the usual way is to just feed it GLSL.

Quoting: JajcusThat would mean targeting OpenGL 4.6, which would limit compatibility to devices and drivers compatible with OpenGL 4.6.

Like Vulkan, it would also cut off macOS.

But, unlike Vulkan, GL_ARB_gl_spirv would be pretty easy to provide optionally. I.e. the GL doesn't support GL_ARB_gl_spirv, you just feed it GLSL source as normal. The GL does support GL_ARB_gl_spirv, you feed it the precompiled bytecode instead, for a potential speed-boost during shader-loading.

If that speed-boost is worth it, however, I wouldn't know. It would only be noticable during the initial loading of the shader, and possibly only once because of driver-level shader caches.

Whether the shaders are then interchangebly between their OpenGL and Vulkan renderer as well, that depends on whether their pipeline for both renderers is essentially the same, with the same bindings in the same slots.

Also depends on how Feral does their porting: if they automatically translate Direct3D shader bytecode to SPIR-V bytecode for Vulkan and GLSL source for OpenGL, they are probably already set up to be compatible.


What I'm hoping, though, is that maybe this will help unify shader compilation across driver boundaries. Currectly, the issue is that some drivers might accept some GLSL source, while another might reject it or even interpret it differently. If now all drivers need to load SPIR-V anyway, and the GLSL to SPIR-V compiler is open, they could just simply their compilation step by ripping out their old compiler, plug in glslang and have all these differences disappear. Even retroactively for devices that don't support OpenGL 4.6.

This would mean that game and engine creators could be more secure in what GLSL code is correct, since if glslang eats and it creates the correct SPIR-V out of it, that then should really work on all devices, even if they don't have the resources to test on every single device.

This is the important thing that SPIR-V brings: stability, not necessarily a speed-up.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.