I had this question in my head for quite some time already. Recently a new version of LWJGL (3.0) has been released which supposedly supports Vulkan API, which is a good opportunity to ask.
Seems like Minecraft is quite CPU-intensive, so Vulkan could improve performance. Any thoughts on this?
I had this question in my head for quite some time already. Recently a new version of LWJGL (3.0) has been released which supposedly supports Vulkan API, which is a good opportunity to ask.
Seems like Minecraft is quite CPU-intensive, so Vulkan could improve performance. Any thoughts on this?
Vulkan is a graphics API, so an important distinction that has to be made is that any advancements Vulkan brings to the table are purely graphical and have to do with how your CPU communicates with your GPU.
The main bottleneck in Minecraft actually isn't in how your CPU communicates with your GPU, nor is it how much work the GPU has to do. It's in how much work your CPU has to do. And unfortunately this isn't a problem solved by a change in API, it's just fundamentally a problem that a game like Minecraft has to deal with. Minecraft is quite a unique game technologically, every single aspect of the world is entirely editable, you can have absolutely no blocks, or you can have chunks literally be solid 16x16x256 cubes. You can have really complex terrain with cliff faces, floating islands, meandering rivers, deep oceans, or you can have a simple world with small and shallow rivers, small lakes, big plateaus. Or, you can even have worlds a single block thick with no change in height, or alternatively, 64 blocks thick with still no change in height on the surface. You can have huge structures with random blocks jutting out to approximate weathering effects on a large scale, you can have tiny houses forming neighbourhoods, you can have rich forests, dense jungles, barren deserts, deep oceans, high mountains, vast plains. And even the density of individual biomes can be changed, biomes can be small and common, or large and sparse. Every single aspect of the world is 100% dynamic, there's virtually no pre-generated elements aside from the obvious ones like models, textures, sounds, particle effects (even then the motion of particles still is 100% dynamic), text.
A game of this nature obviously is going to be incredibly demanding on your CPU, much more so than other games, even with the simple graphics and AI. Keeping track of every single block, within 81 chunks centred on the chunk the player currently occupies, then with mods potentially hundreds more. This is a hard thing to accomplish, and naturally will hit your CPU hard. Especially when things like lighting are required to be done on the CPU (where they're normally done on the GPU) in order to expose the lighting environment to gameplay for things like mob spawning and AI, crop growth, block placement, etc.
For Minecraft to really become easier to run, Mojang needs to optimise the internals of the game. They need to simplify how these fundamentally complex features are actually implemented to overall lighten the load on the CPU. This isn't an easy problem to solve, in fact if you're able to solve problems like this, I highly, highly suggest teaming up with the likes of NVIDIA, Epic Studios, Intel, AutoDesk in order to accelerate the progression of real-time technology to solve seemingly simple problems that are incredibly complex.
Vulkan can help to alleviate graphical bottlenecks, being able to run Minecraft with the video settings (excluding render distance) turned up on underpowered laptops, for instance. Apart from that, it really won't help solve the actual problems at hand.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Wow this is an old thread! The truth is, Minecraft doesn't keep track of every block at once, only the ones that you can see and the ones that are being updated (block updates). The rest it just stores to the save file. If it kept track of every single block, everyone's computer would be on meltdown.
Rollback Post to RevisionRollBack
"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."
Wow this is an old thread! The truth is, Minecraft doesn't keep track of every block at once, only the ones that you can see and the ones that are being updated (block updates). The rest it just stores to the save file. If it kept track of every single block, everyone's computer would be on meltdown.
Not quite true - it is true that only blocks that you can see are being rendered but the game most certainly (speaking as an experienced modder) keeps track of every single block in every single chunk that is loaded in memory; performance would be absolutely terrible if it actually had to read a block from disk just because it happened to become visible - disks, even SSDs, are many orders of magnitude slower than RAM (plus, the game does not save individual blocks, only entire chunks, which must be loaded/saved/modified as one entity, even the individual chunk sections are only handled separately once they are loaded into memory).
On a render distance of 10 in a normal world at least 7.2 million blocks are loaded at once (chunks loaded = (render distance * 2 + 1)^2; with sea level at y=63 the lower 4 chunks sections are always loaded, which is 64 blocks high) and as many as 29 million (filled up to y=256. Chunk sections below this can possibly be empty but it is unlikely on a normal world as caves almost never get large enough or are aligned so they surround a chunk section. And yes, "empty" parts of chunk sections, aka air blocks, do count, with every section always having 4096 slots allocated at any time; only sections that only contain air blocks are not loaded/saved).
There are also two copies of the data for every chunk loaded when playing in singleplayer since the internal server and client maintain separate chunk caches (this is why this thread mentions that memory usage was increased when they combined them into one instead of having a client that also handles the world logic), as well as the data the game sends to the GPU for rendering (which is a third separate set of data which represents the visible vertices and textures each block has, compiled on a per-chunk section basis (the "chunk updates" displayed in F3 represents the number of chunk sections which have been re-rendered over the last second). All of this rendering occurs on the CPU, which includes determining if a face should be rendered (even non-visible blocks require checking for whether each face if exposed or not) and how to shade it based on lighting, with some blocks requiring additional calculations for the biome color and so on).
As mentioned by others, part of the reason the game is demanding is due to poor design decisions; by making some rather trivial changes (I did not change the lighting algorithm) I was able to quadruple the performance of lighting calculations, leading to a halving of world generation time* in biomes with huge trees (also because I delayed per-block relighting until after everything generated, not as each block is placed). Essentially, I just cache chunks and directly access them instead of relying on the normal World.get/set block/light methods which rely on fetching the chunks from the cache, which is quite slow.
Another issue is excessive allocation of objects, which forces the JVM to garbage collect often in order to free memory (one good thing about Java is that you don't have to worry about managing memory (e.g. manually deallocating memory yourself) but it doesn't come free of any downsides), as well as too many method calls and wrappers around code; versions since 1.8 are particularly notorious for this but it also occurs in earlier versions (for example, every time a chunk is generated and populated thousands of temporary objects are allocated. For example, cave generation allocates a new Random instance and passes around and recalculates a lot of data (method parameters) for every single tunnel segment when it really could use a single RNG separate from the main one and storing the data in fields which are calculated just once per chunk; with this and other changes, including using a better, faster RNG than the outdated one that Java provides, in part due to custom methods which reduce the number of method calls, I halved the time taken to generate caves compared to an earlier version of my mod*, and even before it was very lightweight considering how much memory and resources many mods seem to require - Notch was actually a very good programmer compared to most modders).
*Here are a couple examples of how I've optimized my own mod:
Cave generation speed; the various times refer to different steps (generationTime is the actual time spent generating caves while totalTime is the metric I used overall. The last line for the optimized version includes the largest and most extreme form of cave in any of my mods, which still took less time overall than a normal area before):
Timings with Random (milliseconds per 1000 chunks or microseconds per chunk):
initializeTime: 288; validTime: 824; generationTime: 3331; totalTime: 4444
initializeTime: 378; validTime: 901; generationTime: 3437; totalTime: 4717
initializeTime: 391; validTime: 896; generationTime: 3047; totalTime: 4335
initializeTime: 360; validTime: 906; generationTime: 3396; totalTime: 4663
World generation time for a Superflat world set to Mega Forest, which took several times longer to generate than most other biomes in TMCWv4 (first time is how long the server took to generate the spawn area, second is how much time passed between the time the world first opened and the time blocks rendered, making it playable):
TMCWv4: 32 seconds to generate, 24 seconds to load+render, 56 seconds total
TMCWv5 (vanilla lighting): 28 seconds to generate, 16 seconds to load+render, 44 seconds total
TMCWv5 (optimized lighting): 14 seconds to generate, 7 seconds to load+render, 21 seconds total
To put these times into perspective, the game generates/populates 625/576 chunks during world creation.
I was just now curious about the benefit it could bring. I have a decent CPU, an i7-4790 non-k, 12GB PC312800, and a Kepler GT-730 with 2GB DDR3. So in terms of CPU load, I am not concerned. I am wondering how it would benefit my rather weak GPU, which was released for basic office needs in 2014.
I use KUDA Legacy 6.1 shaders, and I use higher settings with the normal game, and a mixture of low shading quality and more shading settings on the shaders. I get about 10-25 fps.
Realistically, I just need to get a better GPU if I want better quality and framerate. Ideally, I want to buy new rather than used, so a Zotac GTX-1650 Super which fits in my case would be perfect, and I would be able to crank things up a bit comfortably. The roadblock in this situation is that I have an OEM computer made by Lenovo, and they use non-standard power supply connection, as well as very weak power supplies in general, mine being 280 watts. I would need to buy both a new power supply--my eyes are on the Corsair CX (2017) 450--and a 24-pin to 14 pin power adapter to connect it to my motherboard. I'm certain this would function and I would be okay using that kind of arrangement. Right now though, I don't have the savings or the income to comfortably spend on all that, totaling at around 215 or 220 USD for all three pieces (PSU, GPU, power adapter). So, I'm stuck with my GT 730 for the foreseeable future.
I wonder how may Minecraft look if it will use CryEngine. I mean, not the graphic side - beacouse its only how models are generated, but remembering structures - and here im thinking about how behave asteroid field in StarCitizen for comparsion. And as I remember, model memory in CE is pyramidal logic of cuboids - large cuboid containing smaller set of them, and ech of them contain smaller ones and so on. But im not sure if CryEngine is as portable as Java engine of MC. Anyway, any wild ideas about Minecraft at CryEngine for PC?
^ title
I had this question in my head for quite some time already. Recently a new version of LWJGL (3.0) has been released which supposedly supports Vulkan API, which is a good opportunity to ask.
Seems like Minecraft is quite CPU-intensive, so Vulkan could improve performance. Any thoughts on this?
Inactive on these forums. Use Steam or Discord if you want to say hi
Vulkan is a graphics API, so an important distinction that has to be made is that any advancements Vulkan brings to the table are purely graphical and have to do with how your CPU communicates with your GPU.
The main bottleneck in Minecraft actually isn't in how your CPU communicates with your GPU, nor is it how much work the GPU has to do. It's in how much work your CPU has to do. And unfortunately this isn't a problem solved by a change in API, it's just fundamentally a problem that a game like Minecraft has to deal with. Minecraft is quite a unique game technologically, every single aspect of the world is entirely editable, you can have absolutely no blocks, or you can have chunks literally be solid 16x16x256 cubes. You can have really complex terrain with cliff faces, floating islands, meandering rivers, deep oceans, or you can have a simple world with small and shallow rivers, small lakes, big plateaus. Or, you can even have worlds a single block thick with no change in height, or alternatively, 64 blocks thick with still no change in height on the surface. You can have huge structures with random blocks jutting out to approximate weathering effects on a large scale, you can have tiny houses forming neighbourhoods, you can have rich forests, dense jungles, barren deserts, deep oceans, high mountains, vast plains. And even the density of individual biomes can be changed, biomes can be small and common, or large and sparse. Every single aspect of the world is 100% dynamic, there's virtually no pre-generated elements aside from the obvious ones like models, textures, sounds, particle effects (even then the motion of particles still is 100% dynamic), text.
A game of this nature obviously is going to be incredibly demanding on your CPU, much more so than other games, even with the simple graphics and AI. Keeping track of every single block, within 81 chunks centred on the chunk the player currently occupies, then with mods potentially hundreds more. This is a hard thing to accomplish, and naturally will hit your CPU hard. Especially when things like lighting are required to be done on the CPU (where they're normally done on the GPU) in order to expose the lighting environment to gameplay for things like mob spawning and AI, crop growth, block placement, etc.
For Minecraft to really become easier to run, Mojang needs to optimise the internals of the game. They need to simplify how these fundamentally complex features are actually implemented to overall lighten the load on the CPU. This isn't an easy problem to solve, in fact if you're able to solve problems like this, I highly, highly suggest teaming up with the likes of NVIDIA, Epic Studios, Intel, AutoDesk in order to accelerate the progression of real-time technology to solve seemingly simple problems that are incredibly complex.
Vulkan can help to alleviate graphical bottlenecks, being able to run Minecraft with the video settings (excluding render distance) turned up on underpowered laptops, for instance. Apart from that, it really won't help solve the actual problems at hand.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Now I understand, thank you a lot
So there are simply more important problems to solve.
Inactive on these forums. Use Steam or Discord if you want to say hi
Not just that, but the way you go about solving them isn't as easy as a change in API.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Wow this is an old thread! The truth is, Minecraft doesn't keep track of every block at once, only the ones that you can see and the ones that are being updated (block updates). The rest it just stores to the save file. If it kept track of every single block, everyone's computer would be on meltdown.
Not quite true - it is true that only blocks that you can see are being rendered but the game most certainly (speaking as an experienced modder) keeps track of every single block in every single chunk that is loaded in memory; performance would be absolutely terrible if it actually had to read a block from disk just because it happened to become visible - disks, even SSDs, are many orders of magnitude slower than RAM (plus, the game does not save individual blocks, only entire chunks, which must be loaded/saved/modified as one entity, even the individual chunk sections are only handled separately once they are loaded into memory).
On a render distance of 10 in a normal world at least 7.2 million blocks are loaded at once (chunks loaded = (render distance * 2 + 1)^2; with sea level at y=63 the lower 4 chunks sections are always loaded, which is 64 blocks high) and as many as 29 million (filled up to y=256. Chunk sections below this can possibly be empty but it is unlikely on a normal world as caves almost never get large enough or are aligned so they surround a chunk section. And yes, "empty" parts of chunk sections, aka air blocks, do count, with every section always having 4096 slots allocated at any time; only sections that only contain air blocks are not loaded/saved).
There are also two copies of the data for every chunk loaded when playing in singleplayer since the internal server and client maintain separate chunk caches (this is why this thread mentions that memory usage was increased when they combined them into one instead of having a client that also handles the world logic), as well as the data the game sends to the GPU for rendering (which is a third separate set of data which represents the visible vertices and textures each block has, compiled on a per-chunk section basis (the "chunk updates" displayed in F3 represents the number of chunk sections which have been re-rendered over the last second). All of this rendering occurs on the CPU, which includes determining if a face should be rendered (even non-visible blocks require checking for whether each face if exposed or not) and how to shade it based on lighting, with some blocks requiring additional calculations for the biome color and so on).
As mentioned by others, part of the reason the game is demanding is due to poor design decisions; by making some rather trivial changes (I did not change the lighting algorithm) I was able to quadruple the performance of lighting calculations, leading to a halving of world generation time* in biomes with huge trees (also because I delayed per-block relighting until after everything generated, not as each block is placed). Essentially, I just cache chunks and directly access them instead of relying on the normal World.get/set block/light methods which rely on fetching the chunks from the cache, which is quite slow.
Another issue is excessive allocation of objects, which forces the JVM to garbage collect often in order to free memory (one good thing about Java is that you don't have to worry about managing memory (e.g. manually deallocating memory yourself) but it doesn't come free of any downsides), as well as too many method calls and wrappers around code; versions since 1.8 are particularly notorious for this but it also occurs in earlier versions (for example, every time a chunk is generated and populated thousands of temporary objects are allocated. For example, cave generation allocates a new Random instance and passes around and recalculates a lot of data (method parameters) for every single tunnel segment when it really could use a single RNG separate from the main one and storing the data in fields which are calculated just once per chunk; with this and other changes, including using a better, faster RNG than the outdated one that Java provides, in part due to custom methods which reduce the number of method calls, I halved the time taken to generate caves compared to an earlier version of my mod*, and even before it was very lightweight considering how much memory and resources many mods seem to require - Notch was actually a very good programmer compared to most modders).
*Here are a couple examples of how I've optimized my own mod:
Timings with Random (milliseconds per 1000 chunks or microseconds per chunk):
initializeTime: 288; validTime: 824; generationTime: 3331; totalTime: 4444
initializeTime: 378; validTime: 901; generationTime: 3437; totalTime: 4717
initializeTime: 391; validTime: 896; generationTime: 3047; totalTime: 4335
initializeTime: 360; validTime: 906; generationTime: 3396; totalTime: 4663
Timings with Random64:
initializeTime: 210; validTime: 320; generationTime: 1730; totalTime: 2262
initializeTime: 244; validTime: 406; generationTime: 1778; totalTime: 2429
initializeTime: 269; validTime: 387; generationTime: 1577; totalTime: 2235
initializeTime: 270; validTime: 398; generationTime: 1813; totalTime: 2482
initializeTime: 258; validTime: 370; generationTime: 3369; totalTime: 3997 (giant cave region)
World generation time for a Superflat world set to Mega Forest, which took several times longer to generate than most other biomes in TMCWv4 (first time is how long the server took to generate the spawn area, second is how much time passed between the time the world first opened and the time blocks rendered, making it playable):
TMCWv4: 32 seconds to generate, 24 seconds to load+render, 56 seconds total
TMCWv5 (vanilla lighting): 28 seconds to generate, 16 seconds to load+render, 44 seconds total
TMCWv5 (optimized lighting): 14 seconds to generate, 7 seconds to load+render, 21 seconds total
To put these times into perspective, the game generates/populates 625/576 chunks during world creation.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
nova-renderer
https://github.com/NovaMods/nova-renderer
https://continuum.graphics/
A mod to replace Minecraft's renderer with an Vulkan renderer written in C++
I was just now curious about the benefit it could bring. I have a decent CPU, an i7-4790 non-k, 12GB PC312800, and a Kepler GT-730 with 2GB DDR3. So in terms of CPU load, I am not concerned. I am wondering how it would benefit my rather weak GPU, which was released for basic office needs in 2014.
I use KUDA Legacy 6.1 shaders, and I use higher settings with the normal game, and a mixture of low shading quality and more shading settings on the shaders. I get about 10-25 fps.
Realistically, I just need to get a better GPU if I want better quality and framerate. Ideally, I want to buy new rather than used, so a Zotac GTX-1650 Super which fits in my case would be perfect, and I would be able to crank things up a bit comfortably. The roadblock in this situation is that I have an OEM computer made by Lenovo, and they use non-standard power supply connection, as well as very weak power supplies in general, mine being 280 watts. I would need to buy both a new power supply--my eyes are on the Corsair CX (2017) 450--and a 24-pin to 14 pin power adapter to connect it to my motherboard. I'm certain this would function and I would be okay using that kind of arrangement. Right now though, I don't have the savings or the income to comfortably spend on all that, totaling at around 215 or 220 USD for all three pieces (PSU, GPU, power adapter). So, I'm stuck with my GT 730 for the foreseeable future.
Could the Vulkan api bring raytracing to java minecraft?
I wonder how may Minecraft look if it will use CryEngine. I mean, not the graphic side - beacouse its only how models are generated, but remembering structures - and here im thinking about how behave asteroid field in StarCitizen for comparsion. And as I remember, model memory in CE is pyramidal logic of cuboids - large cuboid containing smaller set of them, and ech of them contain smaller ones and so on. But im not sure if CryEngine is as portable as Java engine of MC. Anyway, any wild ideas about Minecraft at CryEngine for PC?