Live data from Hacker News

Minecraft Java is switching from OpenGL to Vulkan

gamingonlinux.com

31–40 of 177 posts

Re: Minecraft Java is switching from OpenGL to Vulkan

#31
post #8

Earlier quoted context omitted.

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…

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.

Re: Minecraft Java is switching from OpenGL to Vulkan

#32
post #23

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

Re: Minecraft Java is switching from OpenGL to Vulkan

#34
post #21

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)...

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.

Re: Minecraft Java is switching from OpenGL to Vulkan

#35

Earlier quoted context omitted.

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…

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.

Re: Minecraft Java is switching from OpenGL to Vulkan

#36

Earlier quoted context omitted.

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'…

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.

Re: Minecraft Java is switching from OpenGL to Vulkan

#37
post #21

Earlier quoted context omitted.

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?

Re: Minecraft Java is switching from OpenGL to Vulkan

#38
post #37

Earlier quoted context omitted.

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?

Support for DX12 under Proton in linux is incredibly good. Some games actually run faster under DX12 in Proton than the native versions do.

Re: Minecraft Java is switching from OpenGL to Vulkan

#39
post #37

Earlier quoted context omitted.

How good does Wine support DX12?

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?

Re: Minecraft Java is switching from OpenGL to Vulkan

#40

Earlier quoted context omitted.

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'…

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…

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.
Post reply on HN