4
\$\begingroup\$

After reading this link I am still unclear as to the shading language support in Vulkan.

As Vulkan only supports SPIR-V is it the case that GLSL is therefore being phased out? Are there any indication of what the next 5 years looks like in terms of the "hot" language to study in for graphics programming?

\$\endgroup\$
  • 1
    \$\begingroup\$ No, and it doesn't matter, because graphics programming is the same regardless of shading language. IIRC, Vulkan will ship with an offline GLSL to SPIR-V compiler. Furthermore, Nvidia just announced that their Vulkan drivers will have an extension to support direct GLSL shader submission (like you have in OpenGL) out of the box. \$\endgroup\$ – jmegaffin Jan 17 '16 at 0:44
12
\$\begingroup\$

No, but OpenGL might ;)

The base Vulkan specification only supports SPIR-V. However, Vulkan does allow for vendor extensions. And NVIDIA is already on-record on this matter; they will be providing a Vulkan extension to be able to shove GLSL into their Vulkan implementation.

That shouldn't be taken to mean everyone else will.

However, let's not forget that Vulkan is not going to magically appear everywhere, nor will OpenGL instantly vanish into the aether the moment the Vulkan spec ships.

First, there are entire classes of users who will gain virtually nothing from switching to Vulkan. Who are getting good enough performance for their problem domains from OpenGL, so they don't need to. Pretty much every 2D game you've ever seen has little to gain performance-wise from Vulkan. Even the CPU power consumption gains from VK are minimal for them.

Second, users who would benefit from Vulkan will still take several years to switch over.

Now, if you want to understand my cryptic comment, it is entirely possible for OpenGL to start being able to take SPIR-V as its shading language. SPIR-V contains virtually every feature of OpenGL 4.5, with the exception of shader subroutines (a feature so terrible I won't even link you to the OpenGL Wiki article for fear that you might try to use it).

Indeed, if SPIR-V were only intended to be used for Vulkan or OpenCL, there would be no reason for it to have so many GLSL-based decorators and such in the language. Vulkan uses descriptor sets, not binding points, so why does SPIR-V allow you to specify binding points for textures/images/etc? The same goes for many other GLSL-isms in SPIR-V.

All it would take is an OpenGL extension to allow SPIR-V to be fed to glProgramBinary, likely with a dedicated format enumerator for it.

Will Vulkan kill GLSL? No. But OpenGL and Vulkan might. Though even then, it'd take a long time for it to die.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Subroutines do not look very scary (geeks3d.com/20140701/…). What is the catch? \$\endgroup\$ – Kromster Jan 17 '16 at 5:10
  • \$\begingroup\$ @KromStern: It's the first warning on the Wiki section explaining how you specify which subroutine is being used from GL code. And, more to the point, the fact that "subroutine uniforms" are not like actual "uniforms" in any way, shape, or form. Or the fact that subroutine uniforms aren't anything you couldn't do with a switch statement. \$\endgroup\$ – Nicol Bolas Jan 17 '16 at 14:16
  • \$\begingroup\$ So it sounds like they were introduced to be optimized versions of switch statements, with less overhead? \$\endgroup\$ – Kromster Jan 17 '16 at 15:11
  • 2
    \$\begingroup\$ @KromStern: I'd agree with that. Well, if you replace "optimized version of" with "likely has the same performance cost as." And if you replace "less overhead" with "a highly annoying interface that is utterly unlike anything in the API." Please take note of that warning: shader subroutines are the only place in all of OpenGL where state that you set will just magically vanish. This only exists because that's how D3D11 did it. And the only reason D3D11 did it that way was because it doesn't have an equivalent of uniform variables; they only have constant buffers. \$\endgroup\$ – Nicol Bolas Jan 17 '16 at 15:19
  • 1
    \$\begingroup\$ There's now also GL_ARB_gl_spirv extension for OpenGL, which appears to allow loading SPIR-V modules instead of GLSL sources. \$\endgroup\$ – Ruslan Apr 27 '17 at 5:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.