OpenGL 4.6 officially released, new beta NVIDIA driver with support for it

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.

Mesa finally caught up to 4.5 and now they release this...

Quoting: AnxiousInfusionMesa finally caught up to 4.5 and now they release this...

It have been a few months now.

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

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.

QuoteGL_ARB_texture_filter_anisotropic

Previously IP encumbered? Is it now free?

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.

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...

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.

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.