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.
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.
Who would have thought that Microsoft would end up getting cosier with Khronos standards than Apple. This is after they adopted SPIR-V both as a target in their shader compiler and as an ingest format in DirectX, smoothing over interop with Vulkan in both directions.
Microsoft has already been there before as well, they are adopting SPIR-V only to cut down their fork, and because Google already did part of the work for them.
Apple apparently got very pissed on how Khronos took care of OpenCL.
Then Sony and Nintendo couldn't care less about Khronos, people keep forgetting about game consoles when discussing the portability of Khronos APIs, or ignoring the fact that in reality they aren't really that portable due to the extension spaghetti.
Not a bad choice... since Minecraft Java edition only supports desktops, they don't have to deal with the abysmal Vulkan drivers on mobile.
Though I thought a company large as Microsoft would have the resources to build a cross-platform RHI with the most stable API available for each platform (DX12 for Windows and Metal for macOS)...
I hope this reduces the CPU overhead a bit on the main thread with some time. Quite a few games that ported from DX11 to 12 and openGL to Vulkan didn't just gain performance from the API swap it required taking advantage of the new higher parallel draw call capabilities. #
The main thread is often the limiting factor in minecraft. Minecraft just can't go as fast as the GPU could render the scene and even with quite a lot of shaders things are CPU bottlenecked. Hopefully this changes with time as modding minecraft could certainly do with a bit more CPU time free.
I use Unigine Heaven to benchmark Linux systems. A colleague's friend has an epic spreadsheet of Heaven benchmarks across many configurations, and he submitted a few I've done. I ran it at home on my Linux desktop. For shits and giggles, I also downloaded the Windows version and ran it in Proton, and got a 30% performance boost! I suspect that a lot of that is due to the dxvk library that Proton uses, and the multithreading that it introduces translating D3D11 calls to Vulkan.
I wasn’t aware Java had Vulkan bindings. So this is JNI I’m guessing?
This makes sense. I guess I’m a bit surprised they were still OpenGL anywhere.
I never really got into Minecraft though, so I can’t pretend I know much about its current state. I didn’t even realize there was a non-Java version for desktops.
To elaborate on the other comment about the Foreign Function & Memory API: JNI is effectively dead/deprecated, and has been replaced by the aforementioned API. It is orders of magnitude more developer friendly to use. It handles memory much more cleanly. It's way easier to create bindings to talk to foreign functions (e.g. Vulkan).
Probably the most underappreciated great feature in recent Java releases.
This is great news. I was super disappointed when Rainbow Six Siege dropped the Vulkan version of their game. They cited the support burden as the reason they dropped it, as nearly every game in the studio defaulted to DX11/12. For at least two years after that they received non-stop complaints of frame stutters on DX12. I do not know if the situation has gotten much better since then.
Slightly off-topic too, but I would love for Minecraft Java Edition to have a safer and more robust modding API. For the past decade modding efforts have mostly just been patching on top of a reverse engineering mod framework which exposes some of the game to mods. Factorio is practically the Platonic Ideal in this regard with its Lua sandboxing and restricted API. This is a huge security and stability issue, but Microsoft have no real incentive to fix it.
> it's a shame you need mods to have shaders on Java
You don't. Ever since 1.17 you have been able to build GL shaders directly into resource packs. Resource packs don't require any complex loaders and don't pose a malware risk. To install them you can either drag-and-drop them as .zips directly into the resource pack menu, or a server/world can be configured to prompt the installation of a resource pack. These resource pack shaders are not quite as flexible as Aperture, Iris, or Optifine shaders, but they are fairly close in functionality.
I'm curious if they will carry over this functionality for Vulkan shaders embedded into resource packs. I suspect they may not, which is understandable given how it can be used to break the game's functionality much worse than an ordinary resource pack can (not full RCE, though)
Microsoft seems to be doing anything they can to get rid of Minecraft Java users having bought a Mojang license in the past. Either they are conspiring against their users, or they just don't care.
The dubious Mojang account migration. Their lack of support for kids who got their accounts phished recently. Migrating to Vulkan breaking old hardware.
Sad story, but it was to be expected MS bought Mojang.
Exciting! VulkanMod gives such drastic performance improvements, but it isn't compatible with most other mods. It'll be great to be using Vulkan with a full modpack in the future
35 comments
[ 3.1 ms ] story [ 50.5 ms ] threadVulkan 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.
Apple apparently got very pissed on how Khronos took care of OpenCL.
Then Sony and Nintendo couldn't care less about Khronos, people keep forgetting about game consoles when discussing the portability of Khronos APIs, or ignoring the fact that in reality they aren't really that portable due to the extension spaghetti.
Though I thought a company large as Microsoft would have the resources to build a cross-platform RHI with the most stable API available for each platform (DX12 for Windows and Metal for macOS)...
https://cdn.graph.office.net/prod/media/java/how-microsoft-a...
The main thread is often the limiting factor in minecraft. Minecraft just can't go as fast as the GPU could render the scene and even with quite a lot of shaders things are CPU bottlenecked. Hopefully this changes with time as modding minecraft could certainly do with a bit more CPU time free.
https://benchmark.unigine.com/heaven
https://github.com/doitsujin/dxvk
This makes sense. I guess I’m a bit surprised they were still OpenGL anywhere.
I never really got into Minecraft though, so I can’t pretend I know much about its current state. I didn’t even realize there was a non-Java version for desktops.
Probably the most underappreciated great feature in recent Java releases.
Slightly off-topic too, but I would love for Minecraft Java Edition to have a safer and more robust modding API. For the past decade modding efforts have mostly just been patching on top of a reverse engineering mod framework which exposes some of the game to mods. Factorio is practically the Platonic Ideal in this regard with its Lua sandboxing and restricted API. This is a huge security and stability issue, but Microsoft have no real incentive to fix it.
https://learn.microsoft.com/en-us/minecraft/creator/scriptap...
You don't. Ever since 1.17 you have been able to build GL shaders directly into resource packs. Resource packs don't require any complex loaders and don't pose a malware risk. To install them you can either drag-and-drop them as .zips directly into the resource pack menu, or a server/world can be configured to prompt the installation of a resource pack. These resource pack shaders are not quite as flexible as Aperture, Iris, or Optifine shaders, but they are fairly close in functionality.
I'm curious if they will carry over this functionality for Vulkan shaders embedded into resource packs. I suspect they may not, which is understandable given how it can be used to break the game's functionality much worse than an ordinary resource pack can (not full RCE, though)
Where does it say that? Why not use MoltenVK?
I always appreciated that MC would run on virtually any hardware, especially as a kid without access to anything nice.
The dubious Mojang account migration. Their lack of support for kids who got their accounts phished recently. Migrating to Vulkan breaking old hardware.
Sad story, but it was to be expected MS bought Mojang.
They better make use of Zink/Angle or similar approaches.