Live data from Hacker News

Minecraft Java is switching from OpenGL to Vulkan

gamingonlinux.com

91–100 of 177 posts

Re: Minecraft Java is switching from OpenGL to Vulkan

#91
post #13

Earlier quoted context omitted.

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.

There is also this: > Minecraft: Java Edition runs on Windows, Mac, and Linux; Minecraft: Bedrock Edition runs on Windows. (From their own website. Bedrock might work with wine etc.) For a game as popular as Minecraft, where every year a fresh cohort of young players reaches an age suitable for playing it, it would be madness to discard Linux and Mac users and possibly push the modding community to some other game.

There is an open-source launcher to run Bedrock on Mac and Linux, and it runs well. Bedrock, however, still isn't as popular because servers and mods are more of an afterthought, so not a lot of effort has been put into making it developer-friendly.

Re: Minecraft Java is switching from OpenGL to Vulkan

#92

Earlier quoted context omitted.

TBH Mojang should have the resources to do that on his own, Minecraft is the best selling game of all times btw.

Minecraft is extremely mismanaged, the fact that the java version is still the ”main” version after all these years is just crazy

Why is it crazy? Any rewrite that would be as flexible wrt mods would be shaped similarly.

Re: Minecraft Java is switching from OpenGL to Vulkan

#93

Damn, this will break Minecraft on my original machine, an Acer C720 Chromebook modded to run Linux. The Intel HD4400 iGPU doesn’t support Vulcan! I always appreciated that MC would run on virtually any hardware, especially as a kid without access to anything nice.

It depends what features they use but under Mesa that chip does have some Vulkan support.

Re: Minecraft Java is switching from OpenGL to Vulkan

#94

Why are they even maintaining two versions of the same game?

As far as I remember the original plan was to only maintain both in a transitional phase, with the aim of fully replacing the Java edition. A simple plan: bring Bedrock to feature parity with Java, add a modding API that satisfies 95% of use cases, then force everyone onto Bedrock. The feature parity is mostly there, but modding in Bedrock seems to have become a non-goal, and Bedrock has so many bugs that if your platform offers the choice between both Java is still preferred even if you don't care about modding.

Re: Minecraft Java is switching from OpenGL to Vulkan

#95

Damn, this will break Minecraft on my original machine, an Acer C720 Chromebook modded to run Linux. The Intel HD4400 iGPU doesn’t support Vulcan! I always appreciated that MC would run on virtually any hardware, especially as a kid without access to anything nice.

It's pretty interesting that OpenGL achieved its stated goal and is the graphics API with the highest degree of compatibility across many devices.

Vulkan more or less also has that goal, but for then-current hardware 24 years later (2016). In this case (Intel HD Graphics 4400, Haswell?), there is unofficial support on Linux that can be enabled with some hacks, and it may or may not work. Similar support for my previous (desktop) AMD GPU generally worked fine. The situation for Haswell seems more iffy, though.

Re: Minecraft Java is switching from OpenGL to Vulkan

#96

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

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

Re: Minecraft Java is switching from OpenGL to Vulkan

#97
post #83

I bet they will lose most of the mods, as I don't see many wanting to learn Vulkan only to port their mods. They better make use of Zink/Angle or similar approaches.

Most mods don't even touch the rendering system, they just supply models in json format. If you do need custom rendering, Minecraft has the Blaze3D api, and that should be mostly unchanged. There are relatively few mods like Sodium and Iris that make extensive use of direct opengl calls.

Re: Minecraft Java is switching from OpenGL to Vulkan

#98

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…

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.

https://benchmark.unigine.com/heaven

https://github.com/doitsujin/dxvk

Re: Minecraft Java is switching from OpenGL to Vulkan

#99

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

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