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

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

It have been a few months now.

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

GL_ARB_texture_filter_anisotropic

Previously IP encumbered? Is it now free?

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.

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

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

That does sound interesting. I wish it well.

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

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

In my case this drivers works with ppsspp normally (ppsspp shows opengl 4.6)

View video on youtube.com

^_^


Last edited by mrdeathjr on 31 July 2017 at 7:48 pm UTC

In other news jozef kucia add detection of one opengl 4.6 extension in wine git

From: Józef Kucia <[email protected]>
Subject: [PATCH] wined3d: Update ARB_pipeline_statistics_query extension detection.
Message-Id: <[email protected]>
Date: Mon, 31 Jul 2017 23:31:17 +0200

ARB_pipeline_statistics_query is included in OpenGL 4.6.

Signed-off-by: Józef Kucia <[email protected]>
---
dlls/wined3d/directx.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 9707f81a3b..919b997e2e 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -3898,6 +3898,8 @@ static BOOL wined3d_adapter_init_gl_caps(struct wined3d_adapter *adapter,

{ARB_CLIP_CONTROL, MAKEDWORD_VERSION(4, 5)},
{ARB_DERIVATIVE_CONTROL, MAKEDWORD_VERSION(4, 5)},
+
+ {ARB_PIPELINE_STATISTICS_QUERY, MAKEDWORD_VERSION(4, 6)},
};
struct wined3d_driver_info *driver_info = &adapter->driver_info;
const char *gl_vendor_str, *gl_renderer_str, *gl_version_str;

--
2.13.0

^_^

GL_ARB_texture_filter_anisotropic

Previously IP encumbered? Is it now free?

This suggest the answer is no. Nivida owns the patent.

https://www.google.com/patents/US5651104


Another patent own by Intel lapsed in December.

https://www.google.com/patents/US6816167

This suggest the answer is no. Nivida owns the patent.

https://www.google.com/patents/US5651104


Another patent own by Intel lapsed in December.

https://www.google.com/patents/US6816167

How is it the newer patent expired before the older one?


Last edited by Shmerl on 1 August 2017 at 7:14 pm UTC

This suggest the answer is no. Nivida owns the patent.

https://www.google.com/patents/US5651104


Another patent own by Intel lapsed in December.

https://www.google.com/patents/US6816167

How is it the newer patent expired before the older one?

I guess someone forgot to do clever redrafting/extension tricks.


Last edited by Purple Library Guy on 1 August 2017 at 9:53 pm UTC

How is it the newer patent expired before the older one?

I for one have no idea which patent is the one holding Mesa up. I was hoping you knew.

See https://www.khronos.org/files/ip-disclosures/opengl/

That Nvidia patent lists these dates:

Publication date Jul 22, 1997
Filing date Apr 25, 1995
Priority date Apr 25, 1995

I think the term is 20 years since the filing date (that would be Apr 25, 2015). But now it's even 20 since publication date too. I suppose for some weird reason they were counting it from the publication date, and it expired just last month. So Mesa can implement it now without a problem.

If I understand correctly, Khronos only includes patent-free extensions in the versioned OpenGL specification.


Last edited by Shmerl on 2 August 2017 at 4:00 am UTC

I missed this part (pretty nice of them to mention Mesa):

"OpenGL 4.6 will be the first OpenGL release where conformant open source implementations based on the Mesa project will be deliverable in a reasonable timeframe after release. The open sourcing of the OpenGL conformance test suite and ongoing work between Khronos and X.org will also allow for non-vendor led open source implementations to achieve conformance in the near future," said David Airlie, senior principal engineer at Red Hat, and developer on Mesa/X.org projects.

If I understand correctly, Khronos only includes patent-free extensions in the versioned OpenGL specification.

No. Khronos operate an IP framework, the essence of which is that Khronos members agree not to assert any patents they hold against other members implementing a Khronos specification. I'm not sure how legally strong that provision is.

No mention is made concerning implementation of Khronos specifications by non-members, or what happens if non-members hold patents that might interfere with specifications - although one would assume Khronos then use alternatives where possible.

So the situation still seems a little unclear, although there is evident goodwill towards open implementations.