You can sign up to get a daily email of our articles, see the Mailing List page!
Support me on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! We will also never show adverts to anyone who supports GamingOnLinux! Alternatively, you can support me on Paypal.
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.
22 Likes, Who?
Comments
Page: 1/3»
  Go to:

Corben 31 July 2017 at 1:47 pm UTC
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.
AnxiousInfusion 31 July 2017 at 1:47 pm UTC
Mesa finally caught up to 4.5 and now they release this...
Abu_Shawarib 31 July 2017 at 2:10 pm UTC
AnxiousInfusionMesa finally caught up to 4.5 and now they release this...
It have been a few months now.
sr_ls_boy 31 July 2017 at 2:23 pm UTC
View PC info
  • Supporter
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 at 31 July 2017 at 2:25 pm UTC
edo 31 July 2017 at 3:08 pm UTC
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 31 July 2017 at 3:10 pm UTC
QuoteGL_ARB_texture_filter_anisotropic

Previously IP encumbered? Is it now free?
Jajcus 31 July 2017 at 4:44 pm UTC
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 31 July 2017 at 4:51 pm UTC
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 31 July 2017 at 5:11 pm UTC
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 31 July 2017 at 5:16 pm UTC
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.

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.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations! If you already are, thank you!

Due to spam you need to Register and Login to comment.


Or login with...

Livestreams & Videos
Official Livestreams
  • Borderlands: The Pre-Sequel continued
  • Date:
Community Livestreams
  • hatniX plays: Overland
  • Date:
See more!
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook