NVIDIA "OpenGL 2016" Driver Leaks Out Early, Adds GLSL SPIR-V Extension

[phoronix]

Phoronix: NVIDIA "OpenGL 2016" Driver Leaks Out Early, Adds GLSL SPIR-V Extension

The Khronos BOFs for SIGGRAPH 2016 aren't until tomorrow, but NVIDIA posted today their development driver with support for the "OpenGL 2016" extensions...

http://www.phoronix.com/scan.php?pag...-NVIDIA-Driver

[chuckula]

Good to see Khronos bringing SPIR-V over to OpenGL too since it allows for code reuse and better interoperability between GL and Vulkan.

[pinguinpc]

The updated NVIDIA Linux developer driver is marked 369.00

In nvidia article shows this

Windows driver version 369.00 and Linux drivers version 367.36.02 provide beta support for OpenGL 2016 ARB extensions on capable hardware.

369 drivers series apply to windows, in linux is 367.36.02

Respect behavior remains similar to 367.35

[blacknova]

Interesting, will new driver persist FBO across suspend?

[plonoma]

Does this mean OpenGL SPIR-V will be able to have the slim graphics driver model and other advantages SPIR-V brings for Vulkan too?

[zanny]

Does this mean OpenGL SPIR-V will be able to have the slim graphics driver model and other advantages SPIR-V brings for Vulkan too?

The "slimness" of Vulkan isn't in its shading language. Its the same one OpenGL uses. SPIR-V in OpenGL is most useful to reduce startup times since the driver can operate on compiled shaders out of the box now rather than having to compile textual GLSL shaders first. And even those benefits are limited, since you can already use glShaderBinary to cache the driver-compiled classic GLSL text files.

Really, the benefit is that you can now write once your GLSL, compile it to SPIR-V, and deploy it to anything - OpenGL, Vulkan, even OpenCL. The API you use to consume your shaders is now effectively agnostic to your shaders and their binary format, which makes it really easy to switch APIs as appropriate while maintaining the same workflows across projects.

[plonoma]

zanny The absence of the GLSL shader compiler and compilation is what I was trying to get at with slimness of the driver.

Your second paragraph does highlight a very interesting future for graphics programming.
Maybe there will be automated OpenGL <-> Vulkan conversion programs made in the future.

[artivision]

So now OpenGL state trackers accept SPIR-V except of GLSL. That is very good, lower overhead.

[Ancurio]

Does this mean OpenGL SPIR-V will be able to have the slim graphics driver model and other advantages SPIR-V brings for Vulkan too?

Not really. It's not like the driver can just be purged of the GLSL compilation stack and say "I accept SPIR-V now, so GLSL shaders are no longer welcome"; if anything, the driver is just a tiny little bit more bloated now, because it has to accept both code paths (although it's really an ant in comparison to the giants that are GL drivers).

Really, the benefit is that you can now write once your GLSL, compile it to SPIR-V, and deploy it to anything - OpenGL, Vulkan, even OpenCL. The API you use to consume your shaders is now effectively agnostic to your shaders and their binary format, which makes it really easy to switch APIs as appropriate while maintaining the same workflows across projects.

I'd be careful with that assumption; I don't expect the exact same compiled spirv to just be usable between both APIs. Remember that they still have different shader semantics, eg. Vulkan deals with descriptor sets, whereas GL allows "unblocked" uniforms (not permissible in Vulkan).

If you check out the extension spec, you can see that the term "SPIR-V for OpenGL" is used everywhere to clearly distinguish it from the Vulkan variant. I think the best you could do is try and only use the intersection of GL/Vulkan features, but that would rob you of tons of Vulkan benefits (push constants come to mind).

Another option would be to string your source GLSL with ifdefs for both APIs. I'm doubting the feasibility of this, although it's not impossible (but definitely messy).

[artivision]

Not really. It's not like the driver can just be purged of the GLSL compilation stack and say "I accept SPIR-V now, so GLSL shaders are no longer welcome"; if anything, the driver is just a tiny little bit more bloated now, because it has to accept both code paths (although it's really an ant in comparison to the giants that are GL drivers).



I'd be careful with that assumption; I don't expect the exact same compiled spirv to just be usable between both APIs. Remember that they still have different shader semantics, eg. Vulkan deals with descriptor sets, whereas GL allows "unblocked" uniforms (not permissible in Vulkan).

If you check out the extension spec, you can see that the term "SPIR-V for OpenGL" is used everywhere to clearly distinguish it from the Vulkan variant. I think the best you could do is try and only use the intersection of GL/Vulkan features, but that would rob you of tons of Vulkan benefits (push constants come to mind).

Another option would be to string your source GLSL with ifdefs for both APIs. I'm doubting the feasibility of this, although it's not impossible (but definitely messy).

It is clear that:
1) OGL games distributed in SPIR-V will only work with OGL state trackers.
2) Vulkan games distributed in SPIR-V will only work with Vulkan front drivers.
3) OCL apps distributed in SPIR-V will only work with OCL state trackers.
4) Vulkan games distributed in SPIR-V can be made with various languages like GLSL - HLSL and even DotNet.
5) There are automated "basic" converters (source based), from D3D to OGL and from both to Vulkan.

EDIT: I also propose to Companies like Feral to stop porting games from D3D9 to OGL, it is unnecessary (Gallium Nine). They should port the D3D11-only games that are less restricted and they do not exist on Linux.