4 ms·

Does anyone know whether this functionality is expected in Vulkan? Will it be covered by uploading SPIR-V binaries instead of native code? My understanding is t

Does anyone know whether this functionality is expected in Vulkan? Will it be covered by uploading SPIR-V binaries instead of native code? My understanding is that the main motivation for glProgramBinary() is to bypass a bunch of higher-level compiler passes, and getting back native code is just a result of vendors doing The Simplest Thing That Could Possibly Work rather than a deliberate feature. Is that right, or is there more to it that I'm missing?

nhaehnle 11y ago
You can get the main motivation for glProgramBinary right from the horse's mouth (i.e. https://www.opengl.org/registry/specs/ARB/get_program_binary.txt https://www.opengl.org/registry/specs/ARB/get_program_binary... ): This is a very useful path for applications that wish to remain portable by shipping pure GLSL source shaders, yet would like to avoid the cost of compiling their shaders at runtime.
- Qantourisc 11y ago
  I see this a lot on NVidia driver on Linux games. Games where slow to load. NVidia's fix -> compiled sharers cache. They are stored in ~/.nv (ftp://download.nvidia.com/XFree86/FreeBSD-x86/295.71/README/openglenvvariables.html)
  - robbies 11y ago
    This is relatively old NV functionality. However, there were some complaints about this folder ballooning after installing a couple driver updates, which caused brand new shader blobs to be built. Not a huge issue, but that spurred some of the extension getting traction to allow games to manage the process
robbies 11y ago
The original motivation for GetProgramBinary was to bypass the driver compiler passes, but in order to prevent the unpredictable (by the game) compilations that would happen mid-game, causing CPU spikes. As far as Vulkan, this is not the same use case. Vulkan is using the DX model of compile high level to intermediate representation, and then let driver compile to maybe. One idea of SPIR-V is that any compiler can generate the bytecode, whereas on DX, it currently is that only fxc is allowed to (this didn't used to be the requirement...I speculate it changed when the IL started to drift away from HW ISA , making it so that targeting IL was a bad idea). As far as GetProgramBinary on Vulkan, that doesn't jive with how it's supposed to work. DX12/Vulkan have precompiled pipeline state objects that include compiled shader binaries as part of the state. Ideally, you build (and serialize) these at installation/startup so you don't have to worry about those during runtime.

nhaehnle 11y ago

You can get the main motivation for glProgramBinary right from the horse's mouth (i.e. https://www.opengl.org/registry/specs/ARB/get_program_binary.txt https://www.opengl.org/registry/specs/ARB/get_program_binary... ): This is a very useful path for applications that wish to remain portable by shipping pure GLSL source shaders, yet would like to avoid the cost of compiling their shaders at runtime.

Qantourisc 11y ago
I see this a lot on NVidia driver on Linux games. Games where slow to load. NVidia's fix -> compiled sharers cache. They are stored in ~/.nv (ftp://download.nvidia.com/XFree86/FreeBSD-x86/295.71/README/openglenvvariables.html)
- robbies 11y ago
  This is relatively old NV functionality. However, there were some complaints about this folder ballooning after installing a couple driver updates, which caused brand new shader blobs to be built. Not a huge issue, but that spurred some of the extension getting traction to allow games to manage the process

robbies 11y ago

The original motivation for GetProgramBinary was to bypass the driver compiler passes, but in order to prevent the unpredictable (by the game) compilations that would happen mid-game, causing CPU spikes. As far as Vulkan, this is not the same use case. Vulkan is using the DX model of compile high level to intermediate representation, and then let driver compile to maybe. One idea of SPIR-V is that any compiler can generate the bytecode, whereas on DX, it currently is that only fxc is allowed to (this didn't used to be the requirement...I speculate it changed when the IL started to drift away from HW ISA , making it so that targeting IL was a bad idea). As far as GetProgramBinary on Vulkan, that doesn't jive with how it's supposed to work. DX12/Vulkan have precompiled pipeline state objects that include compiled shader binaries as part of the state. Ideally, you build (and serialize) these at installation/startup so you don't have to worry about those during runtime.