<p>OpenGL 4.1's <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetProgramBinary.xhtml" rel="nofollow noreferrer"><code>glGetProgramBinary</code></a> and <a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glProgramBinary.xhtml" rel="nofollow noreferrer"><code>glProgramBinary</code></a> exist for this purpose. The first one retrieves a binary that represents the compiled program in its entirety (though none of the state stored within it. It, and its implementation-defined format, can be stored and reloaded via <code>glProgramBinary</code>.</p>

<p>Of course, there are limitations. Implementations are not required to be able to load the format they gave you. That is, a driver change could cause implementations to switch to a different versions, leaving all of your binaries obsolete and un-loadable. So you have to be ready to recompile from the source.</p>

<p>Alternatively, GL 4.6 allows you to <a href="https://www.khronos.org/opengl/wiki/SPIR-V" rel="nofollow noreferrer">employ SPIR-V</a>, an intermediate shader language. The idea here is that you compile your code to SPIR-V, then load that SPIR-V into a shader, where you can move forward from there. There are no version changes that could break your code.</p>

<p>Of course, SPIR-V is an intermediate language, so it still has to be compiled to some degree, along with all of the error checking and the like needed to make the final GPU code. It won't be faster than program binaries, but it's a bit more reliable (for implementations that support it).</p>

CC BY-SA 4.0
2020-05-11T13:50:50.080Z
2020-05-11T13:50:50.080Z
Nicol Bolas
<p>Shaders get compiled during runtime every single time an app starts. I understand the reasoning for this is that there are so many GPU architectures out there that it does not make sense to ship pre-compiled shaders. However, I wonder if the designers have explored the possibility of storing out the compiled shader during the first run and load the compiled version from the next run. This is akin to having the intermediate "<code>*.o</code>" as in C/C++ compilation and just linking them when we're building the app. If this is possible, is it a bad idea to do this?</p>

<opengl><shader><c++><gpu><shading>
Do we have OpenGL shaders write out the intermediate *.o-esque file on first compile so that we can skip compiling them in run-time every single time?
Harsh
# Do we have OpenGL shaders write out the intermediate *.o-esque file on first compile so that we can skip compiling them in run-time every single time?

(Asked by: username_0 on 2020-05-11)

Shaders get compiled during runtime every single time an app starts. I understand the reasoning for this is that there are so many GPU architectures out there that it does not make sense to ship pre-compiled shaders. However, I wonder if the designers have explored the possibility of storing out the compiled shader during the first run and load the compiled version from the next run. This is akin to having the intermediate "`*.o`" as in C/C++ compilation and just linking them when we're building the app. If this is possible, is it a bad idea to do this?

**Tags:** opengl, shader, c++, gpu, shading


---

## 1 answers

### Answer by username_1 on 2020-05-11. Score: 2 | Accepted answer

OpenGL 4.1's [`glGetProgramBinary`](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetProgramBinary.xhtml) and [`glProgramBinary`](https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glProgramBinary.xhtml) exist for this purpose. The first one retrieves a binary that represents the compiled program in its entirety (though none of the state stored within it. It, and its implementation-defined format, can be stored and reloaded via `glProgramBinary`.

Of course, there are limitations. Implementations are not required to be able to load the format they gave you. That is, a driver change could cause implementations to switch to a different versions, leaving all of your binaries obsolete and un-loadable. So you have to be ready to recompile from the source.

Alternatively, GL 4.6 allows you to [employ SPIR-V](https://www.khronos.org/opengl/wiki/SPIR-V), an intermediate shader language. The idea here is that you compile your code to SPIR-V, then load that SPIR-V into a shader, where you can move forward from there. There are no version changes that could break your code.

Of course, SPIR-V is an intermediate language, so it still has to be compiled to some degree, along with all of the error checking and the like needed to make the final GPU code. It won't be faster than program binaries, but it's a bit more reliable (for implementations that support it).


---

