Intel Posts Patches For SPIR-V Generation From Mesa's GLSL Compiler

[phoronix]

Phoronix: Intel Posts Patches For SPIR-V Generation From Mesa's GLSL Compiler

Longtime Intel open-source graphics driver developer Ian Romanick has posted his initial set of patches for what he calls "the first of the real SPIR-V work."..

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Mesa-GLSL-To-SPIR-V

[plonoma]

many of the shaders not converting to SPIR-V are due to those shaders relying upon legacy features that cannot be represented within SPIR-V constructs.

Does the standard specify a standardized error message for this common error case?
(If not they should add that to the standard.)

[smitty3268]

Does the standard specify a standardized error message for this common error case?
(If not they should add that to the standard.)

I don't think Michael's description of this work was correct, or is at least misleading. It's only a step towards that extension in regards that it provides more testing possibilities for the driver.

This is about turning Mesa into a GLSL->SPIR-V compiler, which is not a part of any standard spec and definitely not in OpenGL. It's just a new dev tool that game developers can use (they already have a HLSL->GLSL pipeline, so now they can do HLSL->GLSL->SPIR-V), and a new way of testing SPIR-V drivers by using existing GLSL tests.

The spec Michael referred to just lets drivers take in pre-existing SPIR-V code. I think it's not yet enabled for the Intel drivers because there are a few more pieces that need to be finished off, and Ian just wants more testing done first before going there.

***Don't take any of that as gospel, it's just my impression of things so i could be wrong about parts.

[microcode]

I don't think Michael's description of this work was correct, or is at least misleading. It's only a step towards that extension in regards that it provides more testing possibilities for the driver.

This is about turning Mesa into a GLSL->SPIR-V compiler, which is not a part of any standard spec and definitely not in OpenGL. It's just a new dev tool that game developers can use (they already have a HLSL->GLSL pipeline, so now they can do HLSL->GLSL->SPIR-V), and a new way of testing SPIR-V drivers by using existing GLSL tests.

The spec Michael referred to just lets drivers take in pre-existing SPIR-V code. I think it's not yet enabled for the Intel drivers because there are a few more pieces that need to be finished off, and Ian just wants more testing done first before going there.

***Don't take any of that as gospel, it's just my impression of things so i could be wrong about parts.

The standard way to compile GLSL shaders to SPIR-V offline/ahead of time is Glslang (often through shaderc). If a GLSL->SPIR-V pass is being added to Mesa, it is probably intended to centralize the pipeline between GLSL and SPIR-V shaders, so that GLSL shaders are simply lowered to SPIR-V, which you could've provided directly (through GL_ARB_gl_spirv). This means that both paths hit the SPIR-V step, which means that behaviour will be standard between the two.

This is, at least, what I think it would be useful for.

[smitty3268]

The standard way to compile GLSL shaders to SPIR-V offline/ahead of time is Glslang (often through shaderc). If a GLSL->SPIR-V pass is being added to Mesa, it is probably intended to centralize the pipeline between GLSL and SPIR-V shaders, so that GLSL shaders are simply lowered to SPIR-V, which you could've provided directly (through GL_ARB_gl_spirv). This means that both paths hit the SPIR-V step, which means that behaviour will be standard between the two.

This is, at least, what I think it would be useful for.

Ian definitely intends for this to be a glslang competitor, used for compiling the shaders offline. However, I'm sure he has some thoughts about combining code paths as much as possible too.