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)...
A company as large as Microsoft has resources to do a lot of things, but you’re not borrowing resources from the Office team to help on this project.
The relevant measurement is the resources Mojang has as a studio. And I expect the decision here is that they don’t want to commit to the long term maintenance of three renderer implementations on the Java side.
Another concern is that modding is a major part of why Java Edition is so popular, and that includes shaders specifically. This is already going to cause chaos in the modding world as it is, no need to compound that by making shader mods that much more burdensome to maintain.
This is such a gold mine project! thanks for sharing it.
I suppose, if someone in future might want to create their own godot-alternative. Why not just use bgfx with the language bindings instead.
I Love Godot from my time tinkering with it but one of the reasons why Godot is so hopeful in future compared to other engines is imo the fact that they support many many platforms.
I have seen some blogposts on HN where someone used godot to prototype an android GUI application (and not a game) and how the whole process actually makes sense when you think about where they talked about it in the blog post.
Actually there were discussions about even integrating bgfx into raylib (the goat) but looks like that its not getting integrated but it was interesting to read the discussion and maybe anyone more experienced than me could even contribute to the discussion below
Honestly pick between Vulkan and DX12 is very superficial.
But you can easily make Vulkan run on macOS. Not sure what would be the reason to use DX12 in the new project today given free choice of technology, especially when team comes from OpenGL.
I don't think it's faster than a windows game running Vulkan, though, is it? Like, if you benchmarked a game that has native DX12 and Vulkan modes (such as Wolfenstein: The New Colossus, I believe), it will probably have higher FPS in Vulkan mode, right?
Well our game runs faster in DX12 under Proton than Vulkan under Proton.
Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.
I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.
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.
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.
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.
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.
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.
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.
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.
I don't think this is as much of an issue as you are making it out to be. I have my Steam Deck on the main branch release which seems to exclude it from downloading precompiled shaders. When a game updates it has to compile the shaders first, but even on a big game this does not take an unreasonable amount of time. Less time than it takes for game updates to download at least.
Steam could improve the experience here by having the shaders compile overnight in the background so it presents zero delay but the current way doesn't bother me much at all.
I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.
Really depends on the game.
There's no easy way around this problem. It never came up as much in the OpenGL/D3D11 era because we didn't make as many shaders back then. Shader graphs and letting artists author shaders really opened pandoras box on this problem, but OpenGL was already on its way out by the time these techniques were proliferating so Vulkan gets lumped in as the cause.
You're getting lucky with the games you're playing, then; there are absolutely PC games that have had 20-30 minute long shader compilation times _on high-end gaming hardware_. (I think some of Sony's ports were known for this; Googling tells me Borderlands 4, Stalker 2, and Starfield also had notably long shader times.) Typically those occur within the game's UI after launch but before the game starts playing, though, which makes me wonder if Valve might still be caching a non-GPU-specific intermediate of the DX12 to Vulkan conversion, and _that's_ what Linux Steam clients are compiling pre-launch and/or sharing with other clients. That's pure speculation on my part though, as I haven't played any of the worst-case-scenario games on my Deck, nor have I done anything that would cause the shader downloading to not operate.
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)
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.
Java is the original version from Mojang/Notch. There’s always been enough of a community that killing it off to move away from Java would break so many extensions and servers would see an active revolt.
There is the non-Java version (Bedrock), but that’s not nearly as extensible.
Not a Java implementation, but the original game was written in Java. Later, Microsoft bought Minecraft and rewrote it (Bedrock edition) which runs on Xbox, tablets, etc. But, the community writes mods in Java.
Now both exist and get roughly the same feature set now, but the Java version remains popular given the vast variety of mods and servers.
As I recall the C++ reimplementation of Minecraft predates the Microsoft sale. Unless they did a complete rewrite I don't know about, Bedrock is distantly based on the old mobile/console version of Minecraft.
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)...
A company as large as Microsoft has resources to do a lot of things, but you’re not borrowing resources from the Office team to help on this project.
The relevant measurement is the resources Mojang has as a studio. And I expect the decision here is that they don’t want to commit to the long term maintenance of three renderer implementations on the Java side.
Another concern is that modding is a major part of why Java Edition is so popular, and that includes shaders specifically. This is already going to cause chaos in the modding world as it is, no need to compound that by making shader mods that much more burdensome to maintain.
TBH Mojang should have the resources to do that on his own, Minecraft is the best selling game of all times btw.
They use bgfx for bedrock edition.
https://github.com/bkaradzic/bgfx
https://www.minecraft.net/en-us/attribution
This is such a gold mine project! thanks for sharing it.
I suppose, if someone in future might want to create their own godot-alternative. Why not just use bgfx with the language bindings instead.
I Love Godot from my time tinkering with it but one of the reasons why Godot is so hopeful in future compared to other engines is imo the fact that they support many many platforms.
I have seen some blogposts on HN where someone used godot to prototype an android GUI application (and not a game) and how the whole process actually makes sense when you think about where they talked about it in the blog post.
Actually there were discussions about even integrating bgfx into raylib (the goat) but looks like that its not getting integrated but it was interesting to read the discussion and maybe anyone more experienced than me could even contribute to the discussion below
https://github.com/raysan5/raylib/discussions/1699
On mobile 3rd party launchers use ANGLE to use EGL or Metal drivers.
Honestly pick between Vulkan and DX12 is very superficial.
But you can easily make Vulkan run on macOS. Not sure what would be the reason to use DX12 in the new project today given free choice of technology, especially when team comes from OpenGL.
The reason you use DX12 in a new project is so that you can get good linux support.
I'm making a joke, but it's also true.
How good does Wine support DX12?
DXVK does not need wine.
Support for DX12 under Proton in linux is incredibly good. Some games actually run faster under DX12 in Proton than the native versions do.
I don't think it's faster than a windows game running Vulkan, though, is it? Like, if you benchmarked a game that has native DX12 and Vulkan modes (such as Wolfenstein: The New Colossus, I believe), it will probably have higher FPS in Vulkan mode, right?
Well our game runs faster in DX12 under Proton than Vulkan under Proton.
Of course since Proton uses Vulkan to implement DX12, it means that our Vulkan implementation is simply worse than the one that Valve created to emulate DX12.
I'm sure it's possible to improve that, but it implies that there way to get the best performance out of Vulkan is less obvious than the way to get it out of DX12.
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 hope Vibrant Visuals comes to Minecraft Java Edition quickly, it's a shame you need mods to have shaders on Java.
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.
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.
Hopefully it would use the Foreign Function and Memory API instead of JNI.
I'm pretty sure Mojang will just use the Vulkan bindings provided by LWJGL, considering that Minecraft uses LWJGL
I hope they have a solution to the notorious Vulkan shader compilation lag spikes.
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.
I wouldn't trust them to not implement the next version of Minecraft in UE5 with nanite and lumen
And by voxels you mean triangles
I’m not even a neophyte here but why don’t precompiled shaders solve that?
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.
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.
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.
I don't think this is as much of an issue as you are making it out to be. I have my Steam Deck on the main branch release which seems to exclude it from downloading precompiled shaders. When a game updates it has to compile the shaders first, but even on a big game this does not take an unreasonable amount of time. Less time than it takes for game updates to download at least.
Steam could improve the experience here by having the shaders compile overnight in the background so it presents zero delay but the current way doesn't bother me much at all.
I remember Star Wars Jedi Survivor had a 5-6 minute shader pre-compile on my 5950X. I heard of people well into the 30 minute mark on lower core count machines. Battlefield 6 was a few minutes on my 9950X, higher again on lower core count CPUs.
Really depends on the game.
There's no easy way around this problem. It never came up as much in the OpenGL/D3D11 era because we didn't make as many shaders back then. Shader graphs and letting artists author shaders really opened pandoras box on this problem, but OpenGL was already on its way out by the time these techniques were proliferating so Vulkan gets lumped in as the cause.
You're getting lucky with the games you're playing, then; there are absolutely PC games that have had 20-30 minute long shader compilation times _on high-end gaming hardware_. (I think some of Sony's ports were known for this; Googling tells me Borderlands 4, Stalker 2, and Starfield also had notably long shader times.) Typically those occur within the game's UI after launch but before the game starts playing, though, which makes me wonder if Valve might still be caching a non-GPU-specific intermediate of the DX12 to Vulkan conversion, and _that's_ what Linux Steam clients are compiling pre-launch and/or sharing with other clients. That's pure speculation on my part though, as I haven't played any of the worst-case-scenario games on my Deck, nor have I done anything that would cause the shader downloading to not operate.
It kinda does. Kinda. Steam constantly downloads precompiled shaders for your games. Especially on Linux.
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)
> For the macOS side of things, they'll use a translation layer since Apple don't support Vulkan directly (they made their own API with Metal)
Where does it say that? Why not use MoltenVK?
I think MoltenVK probably is the translation layer they're using.
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.
I'm frankly shocked microsoft has a java implementation. I thought they were the type of organization to pretend it didn't exist!
Java is the original version from Mojang/Notch. There’s always been enough of a community that killing it off to move away from Java would break so many extensions and servers would see an active revolt.
There is the non-Java version (Bedrock), but that’s not nearly as extensible.
Switching to vulkan breaks all the extensions too
Ah, I had misread "minecraft" as "microsoft". I wasn't aware minecraft java was a thing. Crazy they have their own java implementation!
Not a Java implementation, but the original game was written in Java. Later, Microsoft bought Minecraft and rewrote it (Bedrock edition) which runs on Xbox, tablets, etc. But, the community writes mods in Java.
Now both exist and get roughly the same feature set now, but the Java version remains popular given the vast variety of mods and servers.
As I recall the C++ reimplementation of Minecraft predates the Microsoft sale. Unless they did a complete rewrite I don't know about, Bedrock is distantly based on the old mobile/console version of Minecraft.
It’s the Java version of the game, not a game version of Java.
There’s a native version called bedrock
> It’s the Java version of the game, not a game version of Java.
This would be termed "Java Minecraft", not "Minecraft Java"
You appear to be the only one confused
No, the game's Java version's official title post-Microsoft acquisition of Mojang is Minecraft: Java Edition.
They have renamed both product lines, Bedrock edition many times.
While you meant Minecraft here, to shock you further, please enjoy this:
https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine
They also currently release their own build of OpenJDK.
https://www.microsoft.com/openjdk