2 ms·

I hope they have a solution to the notorious Vulkan shader compilation lag spikes.

cyber_kinetist 9mo ago
I don't think Minecraft's renderer will be PSO-heavy enough to have stuttering issues. It's not a state-of-the-art compute-driven renderer that supports artist-driven workflows with custom materials and shaders... it's just a voxel renderer with very primitive lighting.
- slopinthebag 9mo ago
  I wouldn't trust them to not implement the next version of Minecraft in UE5 with nanite and lumen
- direwolf20 9mo ago
  And by voxels you mean triangles
  - Oxodao 9mo ago
    Are you the real direwolf20?
jimbob45 9mo ago
I’m not even a neophyte here but why don’t precompiled shaders solve that?
- ozarkerD 9mo ago
  Can't precompile for all the combinations of hardware, driver version, operating systems, etc... It's not really a vulkan specific problem and it's hard to solve. (for desktops anyways)
- raincole 9mo ago
  It kinda does. Kinda. Steam constantly downloads precompiled shaders for your games. Especially on Linux.
- MindSpunk 9mo ago
  Depends what you're precompiling. For Vulkan you already ship "pre-compiled" shaders in SPIR-V form. The SPIR-V needs to be compiled to GPU ISA before it can run. You can't, in general, pre-compile the SPIR-V to GPU ISA because you don't know the target device you're running on until the app launches. You would have to precompile ISA for every GPU you ever plan to run on, for every platform, for every driver version they've ever released that you will run on. Also you need to know when new hardware and drivers come out and have pre-compiled ISA ready for them. Steam tries to do this. They store pre-compiled ISA tagged with the GPU+Driver+Platform, then ship it to you. Kinda works if they have the shaders for a game compiled for your GPU/Driver/Platform. In reality your cache hit rate will be spotty and plenty of people are going to stutter. OpenGL/DirectX11 still has this problem too, but it's all hidden in the driver. Drivers would do a lot of heroics to hide compilation stutter. They'd still often fail though and developers had no way to really manage it out outside of some truly disgusting hacks.
  - Gigachad 9mo ago
    There's two tiers of precompiled though. Even if you can't download them precompiled, you can compile before the game launches so there are no stutters after.
    - MindSpunk 9mo ago
      Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more. But in reality the exhaustive pre-compile will compile way more than will be used by any given game session (on average) and waste lots of time. Also you would have to recompile every time the user upgraded their driver version or changed hardware. And you're likely to churn a lot of customers if you smack them with a 30+ minute loading screen. Precisely which shaders get used by the game can only be correctly discovered at runtime in many games, it depends on the precise state of the game/renderer and the quality settings and often hardware vendor if there are vendor-specific code paths. Some games will get QA to play a bunch of the game, or maybe setup automated scripts to fly through all the levels and log which shaders get used. Then that log gets replayed in a startup pre-compile loading screen so you're at least pre-compiling shaders you know will be used.
exDM69 9mo ago
> notorious Vulkan shader compilation lag spikes. Vulkan gives all the tools to avoid any "lag spikes" from shader compiling. In fact, causing them is much more difficult than OpenGL where they could happen in surprising places (and only on certain hardware). The issue is two fold: 1. Some engines produce a lot of shader permutations. Some AAA titles can have 60000 different shaders compiled. 2. Some GPU rasterizer states (such as color blending) are implemented as shader epilogues. In Vulkan 1.0 almost all of the pipeline state had to be pre-baked into a pipeline state object compiled ahead of time. This lead to a "shader permutation explosion" where different states need different pipelines. This requires the game engine to either a) compile all the pipeline combinations ahead of time (slow loading time) or b) compile them as needed (lag spikes). The core issue for this was solved years ago and now most of the pipeline states can be added to the command buffers ("dynamic states"). This solves the permutation explosion. But at the same time it opens the door for issue 2: some states (blending in particular) can cause a state-based recompile (like ye olde OpenGL days) at runtime. The only solution to the second problem is not to use the dynamic states that trigger recompiling. That's basically only blending as far as I know. You can't even have dynamic blend state on all GPUs. For maximum developer flexibility there's the shader object extension that allows mixing and matching shaders and pipeline states any way you want. This will cause state based recompiles at unpredictable times but it's an opt-in feature and easy to avoid if lag spikes are not wanted. tl;dr: shader recompilation is easy to avoid in Vulkan but porting legacy engine code or art content may take you off the happy path.
uyzstvqs 9mo ago
Honestly, this is either a game developer skill issue or laziness issue, not Vulkan's fault. Most big game developers have been notoriously negligent at any form of technical optimization in recent years.

I don't think Minecraft's renderer will be PSO-heavy enough to have stuttering issues. It's not a state-of-the-art compute-driven renderer that supports artist-driven workflows with custom materials and shaders... it's just a voxel renderer with very primitive lighting.

slopinthebag 9mo ago
I wouldn't trust them to not implement the next version of Minecraft in UE5 with nanite and lumen
direwolf20 9mo ago
And by voxels you mean triangles
- Oxodao 9mo ago
  Are you the real direwolf20?

jimbob45 9mo ago

I’m not even a neophyte here but why don’t precompiled shaders solve that?

ozarkerD 9mo ago
Can't precompile for all the combinations of hardware, driver version, operating systems, etc... It's not really a vulkan specific problem and it's hard to solve. (for desktops anyways)
raincole 9mo ago
It kinda does. Kinda. Steam constantly downloads precompiled shaders for your games. Especially on Linux.
MindSpunk 9mo ago
Depends what you're precompiling. For Vulkan you already ship "pre-compiled" shaders in SPIR-V form. The SPIR-V needs to be compiled to GPU ISA before it can run. You can't, in general, pre-compile the SPIR-V to GPU ISA because you don't know the target device you're running on until the app launches. You would have to precompile ISA for every GPU you ever plan to run on, for every platform, for every driver version they've ever released that you will run on. Also you need to know when new hardware and drivers come out and have pre-compiled ISA ready for them. Steam tries to do this. They store pre-compiled ISA tagged with the GPU+Driver+Platform, then ship it to you. Kinda works if they have the shaders for a game compiled for your GPU/Driver/Platform. In reality your cache hit rate will be spotty and plenty of people are going to stutter. OpenGL/DirectX11 still has this problem too, but it's all hidden in the driver. Drivers would do a lot of heroics to hide compilation stutter. They'd still often fail though and developers had no way to really manage it out outside of some truly disgusting hacks.
- Gigachad 9mo ago
  There's two tiers of precompiled though. Even if you can't download them precompiled, you can compile before the game launches so there are no stutters after.
  - MindSpunk 9mo ago
    Yes, many games do that too. Depending on how many shaders the game uses and how fast the user's CPU is an exhaustive pre-compile could take half an hour or more. But in reality the exhaustive pre-compile will compile way more than will be used by any given game session (on average) and waste lots of time. Also you would have to recompile every time the user upgraded their driver version or changed hardware. And you're likely to churn a lot of customers if you smack them with a 30+ minute loading screen. Precisely which shaders get used by the game can only be correctly discovered at runtime in many games, it depends on the precise state of the game/renderer and the quality settings and often hardware vendor if there are vendor-specific code paths. Some games will get QA to play a bunch of the game, or maybe setup automated scripts to fly through all the levels and log which shaders get used. Then that log gets replayed in a startup pre-compile loading screen so you're at least pre-compiling shaders you know will be used.

exDM69 9mo ago

> notorious Vulkan shader compilation lag spikes. Vulkan gives all the tools to avoid any "lag spikes" from shader compiling. In fact, causing them is much more difficult than OpenGL where they could happen in surprising places (and only on certain hardware). The issue is two fold: 1. Some engines produce a lot of shader permutations. Some AAA titles can have 60000 different shaders compiled. 2. Some GPU rasterizer states (such as color blending) are implemented as shader epilogues. In Vulkan 1.0 almost all of the pipeline state had to be pre-baked into a pipeline state object compiled ahead of time. This lead to a "shader permutation explosion" where different states need different pipelines. This requires the game engine to either a) compile all the pipeline combinations ahead of time (slow loading time) or b) compile them as needed (lag spikes). The core issue for this was solved years ago and now most of the pipeline states can be added to the command buffers ("dynamic states"). This solves the permutation explosion. But at the same time it opens the door for issue 2: some states (blending in particular) can cause a state-based recompile (like ye olde OpenGL days) at runtime. The only solution to the second problem is not to use the dynamic states that trigger recompiling. That's basically only blending as far as I know. You can't even have dynamic blend state on all GPUs. For maximum developer flexibility there's the shader object extension that allows mixing and matching shaders and pipeline states any way you want. This will cause state based recompiles at unpredictable times but it's an opt-in feature and easy to avoid if lag spikes are not wanted. tl;dr: shader recompilation is easy to avoid in Vulkan but porting legacy engine code or art content may take you off the happy path.

uyzstvqs 9mo ago

Honestly, this is either a game developer skill issue or laziness issue, not Vulkan's fault. Most big game developers have been notoriously negligent at any form of technical optimization in recent years.