mojira.dev
MC-164123

Poor FPS performance with new rendering engine

Mod Notice

More information about what exactly has been changed in regards to client-side performance in 1.15 can be found in this Reddit post: A word or two about performance in Minecraft 1.15-pre1

Comment by @unknown:

You do not need to convince us that this is a bug. This is not a forum for debate, and the reddit post clearly states that we are continuously working to improve performance.

If you have more data to add to the bug, please do so without unrelated walls of text. Otherwise, please refrain from posting.

The target of 30 FPS is a minimum limit. This doesn't mean that you will never get more than 30 FPS, it means that when the game has lots of work to do, it'll remain at 30 FPS at a minimum.

If you would rather have high FPS than chunks at a far distance, there is already a mechanism in the game for this - lower your render distance. Again, this does not mean we'll stop working on performance, but your confrontational attitude is doing nothing but adding to the noise.

Any further comments that do not provide additional information for this bug will be removed. Further comments that do add information are appreciated.

The GPUs are not boosting to 3D clocks, someone in the rendering team has to enable a flag or change a tag somewhere in the code to give the GPUs the memo that this particular OpenGL load is 3D rendering instead of general computing or crypto mining. Then we can perhaps start talking about optimization, which is way worse even with the GPU boosting correctly. Spoiler alert: >50% drop.

-First, a baseline test of 1.14.4 with no tweaks or shenanigans. Minecraft Seed for the latest round of tests is "test2", fresh generated world with standard settings. About 200FPS after a minute of waiting until GPU clocks stabilize up. 44%GPU utilization at 2025Mhz.

[media]


-then 1.15-pre1 with no tweaks or shenanigans, reusing the world from 1.14.4 due to the bugfixing of world generation resulting in different visuals in some places, want a 100% correlated test here within reason (villagers or mobs popping in sight). About 110FPS, 38%GPU utilization at 1395Mhz (which is 2D-mode clocks)

[media]


-then you can force the driver to boost the GPU to Maximum Performance via the nVidia Control Panel (right-click in windows desktop): you have to manually add the javaw.exe in the Manage 3D Configuration tab to do so, AND manually select the GPU (1660Ti in this example) as the predetermined OpenGL Renderer. The workaround does not work with only one of the two fixes applied; and unfortunately I can't help Radeon users because I don't have one of their GPUs. Adding a screenshot of my own for visual reference, sorry it's in spanish but I think I'd have to change my OS language and reinstall the drivers to show you in english.

[media]

[media]


This workaround results in peaks of about 155-160FPS with 39% GPU utilization at 2025Mhz. GPU frequency usually dips below because there seems to be a "ghost" framerate limiter so the game hovers around 150±5FPS; perhaps it's a frequency-related bottleneck from the new rendering engine. I have the framerate unlimited as you can see in the F3 tags top left. Somehow, the illusion breaks when you look around as the GPU goes insane and it downclocks for no apparent reason other than refreshing the frame buffer and probably the texture buffer too; it dips well below the 60FPS mark which is quite a painful disparity between the top and bottom range of the framerate during playtime. In 1.14.4 it dips from 200FPS to 120ish during normal gameplay or 100FPS if I really try hard to spin around with the mouse.

I wanted to try a harder graphics load so I loaded my multiplayer server with snapshot 19w34a (last one before the new rendering engine) and stood still for a minute until everything loaded in, then took a screenshot. 164 FPS, GPU at 1815Mhz 40% use

[media]

After that, I updated the same server to 1.15-pre1 and tried to apply my workaround from nVidia Control Panel to get the GPU to boost up in the client PC. Unfortunately, for whatever reason it won't work even if I restart the PC and apply the settings multiple times. I guess the game is happy to provide over 30FPS and doesn't bother to ask for more resources from the GPU lol. Waited 5 minutes to see if anything changed but nope: 76 FPS, GPU at 1095Mhz and chilling at 23% usage

[media]

So, when you're actually playing the game on a multiplayer server, you can expect at least a halving of the FPS from the old rendering engine to the new one. In this particular instance, dropping from 164 to 76FPS means a [1-(76/164)] x 100 = 53.6% performance drop in static conditions. I wanted to try dynamic conditions by logging and recording a test drive of a minecart rail facing the same spot, but unfortunately the game crashed on me several times while moving around in the world so I eventually gave up.

----------------------
TL;DR: in the same benchmarking conditions, 1.14.4 was giving 200FPS, 1.15-pre1 gives 110FPS if you're an average user; or 150FPS if you know how to force your GPU as the OpenGL renderer and bruteforce Maximum Performance or 3D clocks-mode on it, but then the game stutters insanely when you actually look around and try to play instead of benchmark it. That's a -25% direct performance improvement in the absolute best case scenario. The workaround may or may not work, it seems that in graphics-intensive scenarios it doesn't so performance can tank from 160s to 70s FPS, over 50%.

GPU Frequency can be observed through gpuZ, hwinfo64, Afterburner or Rivatuner RTSS; there's plenty of material online if you google any of those names to check how your GPUs are behaving and/or toggling overlays with real time reporting. It would be nice if Minecraft could retrieve the info itself and display it in the F3 menu, it would make these issues more ovbious in the future.

Linked issues

MC-166194 Optimizations you did decreased performance of the game compared to 1.14.4 MC-167474 Frame rate is significantly lower than previous versions MC-167478 Minecraft 1.15 has huge lag issues on a fully capable computer MC-167541 Lag after 1.15 update MC-167679 1.15 Extreme Performance Decrease. Unknown Cause MC-167991 FPS issues MC-168551 1.15.1 poor performance and strange scaling. MC-168868 1.15.1 seems to be a little laggy for me... MC-169743 Low GPU Usage + unplayable stuttering MC-170311 Lag, fps MC-171091 FPS Very Inconsistent or Even Worst Than 1.13-1.14 Preformance. MC-185266 Fps drop MC-186047 irregular fps MC-189260 Sudden FPS drops since 1.15 MC-189318 The game's optimization of FPS does not seem to be very good MC-193193 1.16 being very laggy MC-209308 Game microstuttering from versions 1.15 and above (up to current version (1.16.4) and 1.17 snapshots)

Attachments

Comments

Caden Nickerson

I have the same issue with mid-range specs. It's unplayable, especially with biome blend on. That is a bug they are working on, but still haven't fixed.

violine1101

If you could nail down more exactly what might cause the lag, that would be very helpful. Biome blend is covered in MC-149181. Turn it off so that that bug doesn't influence the benchmarks.

dpokor

I just checked and I don't see any immediate effect turning off biome blend or running it at 15x15. Then I tried to set every graphics setting to minimum or off (except chunk distance rendering), still locked in the 50-60fps on the same spot. There seems to be a CPU bottleneck in the new rendering engine, because with the old engine changing the graphics settings did actually affect your performance very appreciably even when surrounded by a lot of entities like in my base area.

 

Sure, if I look to the sky or fly to world generated chunks without buildings or entities I get >100FPS again but I should be able to get them too in the base area like with the old engine.

NeunEinser

Looking at the FPS, it seems like they are about half for me, testing in a newly generated jungle biome of the same seed.

It would still be appreciated, if this could be investigated further.

Please create a new ticket if you find a specific cause/scenario where the FPS a significantly worse than in previous versions.

slicedlime

Would you be willing to share your world file?

NeunEinser

Now with all settings correct and no FPS caps anywhere:
AMD Radeon™ R9 380 Series, Render Distance: 13

World

FPS 1.14.4

FPS 19w42a

"The Void" Preset

~680

~420

[media]

~20

~10

[media]

~200

~140

[media]

~145

~100

Very sorry about that first thing I posted.

slicedlime

No worries. Thanks for the worlds and the information!

Eugene

All Java Edition 1.15 snapshots have horrible rendering and chunk issues, being very slow.

It is most noticeable when I ride my mine-cart long distance, across water and land, away from my city and back to it. The mine-cart frequently crosses unloaded, empty chunks.

wobst.michael

Please check if that's still an issue for you in 19w45a.

dpokor

surely! this weekend I'll give the new snapshot a go and report back

YourCoal

I ran a test creating a new world with the seed "12345" and tested the FPS on it, once chunks loaded I averaged 480-550 FPS in 1.14.4 but only 220-250 FPS on 19w45b. (Core tested was an i7-8750H @ 2.20GHz)

Here is a quick summary of what I produced from this:
(link if photo does not show: https://prnt.sc/puc0mp )

[media]

If you have any questions feel free to ask, I want to make this is improved. 🙂

dpokor

It's DEFINITELY still an issue, but might be easier to solve than a CPU bottleneck.

I made some tests on a fresh generated world for each MC version: seed "test1", then climbing to the same hill, standing in the same spot and facing the same direction (within reasonable 0.2º tolerance of a mere human pointing with a mouse). The two instances of the test were running the same java arguments (-xms 4G -xmx 4G), same Java version, same driver version, etc. Here are some relevant screenshots:

1.14.4: 210FPS (after 1 minute):

[media]

same 1.14.4, with performance overlay reveals the GPU is correctly boosting to 2070Mhz:

[media]

19w45b: 116FPS (after more than 3 minutes):

[media]

same 19w45b with performance overlay reveals the GPU core is not boosting to 3D clocks, staying in 2D mode at ~1400Mhz:

[media]


The rest of the performance parameters look similar to me:

-CPU usage and power consumption are the same, so with the new rendering engine it's doing the same job than in 1.14.4. Thus, my first intuition of a CPU bottleneck seems incorrect.

-That being said, it's clear that the GPU core is not boosting to 3D clocks although it may not be the culprit of the bug but a symptom, because the load percentage seems to be about the same 40% and the GDDR graphics memory is correctly boosting to 3D clocks: 6200Mhz.

-VRAM (GDDR6) consumption has increased 20% from around 1000MB to 1200MB despite the increase in framerates (or FPS decrease), which is weird but somewhat expectable if the new rendering engine uses more detailed textures.

To avoid unreasonable claims of the new world generation heavily affecting graphics performance, I upgraded the 1.14.4 world of the first test to 19w45b and took an additional couple of screenshots. While I was at it, I unlocked the FPS limit from 220 to infinite (despite being far below from it), just in case...

[media][media]

the old world generation and less grass foliage results in a paltry increase to 124FPS. Worth noting that VRAM usage is ~1100MB, 10% more than 1.14.4 exactly in the same conditions. The GPU stays in 2D-clocks

It's worth pointing out that when testing the 1.14.4 version for the second time, I noticed that it appears like the GPU starts boosting to 3D clocks only after a minute (almost exactly) of loading into the world. The test starts at 200FPS after the loading screen, then as chunks get loaded the FPS goes down to around 110FPS until the 60 second mark where it boosts all the way up to 210FPS and stays there until you close the game. The following video proves it, you can skip to around 0:50 to see the GPU clock boost from 1300Mhz to 2070Mhz and the FPS climbing from 110ish to 210: https://www.youtube.com/watch?v=BcqjClWTung

The behavior shown in the video is the reason why I mention how much time I waited after loading the world to take the snapshots, unfortunately no matter how long you wait 19w45b does not boost the GPU.

Please do forward this information to the developers, I'm sure whoever is in charge of the rendering engine can replicate the behavior from 1.14.4 and force the GPUs to 3D clocks mode. It's strange that it's not happening automatically via OpenGL and the graphics driver, but for whatever reason it's not happening.

Eugene

Snapshots 19w45a, 19w45b & 19w46a haven't improved anything. Chunk loading / rendering is very slow. It can be seen in the attached video when going over and near water. When returning to the train station, 3 cows slowly appear on a mountain on the right which hasn't rendered yet.

Link to video:

Minecraft 19w46a

dpokor

just gave 19w46b a spin but the issue persist. GPU not boosting to 3D clocks, FPS still halved in comparison to 1.14.4

Nagy Richárd

 I  can confirm that performance is worse than 1.14.2. With i5 CPU and gtx 1050 ti I had 200+ fps in 1.14.2. Now with new graphics engine I only get 100+ fps and if I set render distance to 24+ the fps is around 40+.

gregopeck

Testing snapshot 19w46b in Windows 10 installed on an SSD (both game and OS are on it) with a GTX 1660Ti and i7-8700 and 16GB RAM. Up to date NVidia driver and Windows 10 contains all updates as of today. I have attached screenshots of my settings and performance in-game. My resolution is 1920x1200@60hz. The game has been running for a few minutes. I just looked at it and the FPS (with Fullscreen off) was what I expect it to be (about 59), but then I switched to Fullscreen and looked around which caused the FPS to seriously drop. I tested this out in 1.14, but had no issues with that version of the game. There is an integrated GPU in my CPU, but I have verified that it is disabled in BIOS. I looked at the Nvidia Control Panel and changed the default option of OpenGL Rendering GPU from Auto-Select to the only other option, my Geforce GTX 1660Ti. At one point it seemed like this fixed it, but I tried again and couldn't replicate the seemingly success. I am not using any mods or resource packs with this snapshot, nor was I using any when I test (successfully) in 1.14. Also, while testing HWMonitor shows 0 to less than 10% GPU utilization. Also, it seems the first two cores of my CPU are working pretty hard, anywhere from about 50% or slightly less all the way to 100%.

[media][media]
gregopeck

Debug info

[media][media][media]
gregopeck

After some testing and troubleshooting, I resolved my issue. The issue for me was an application called Razer Cortex. It's part of the Razer software I use for my keyboard and headset, although Cortex is not necessary. It has a feature to "auto-boost" your games, supposedly freeing up resources and such. Once I disabled this, the game ran so well that my CPU and GPU were barely being utilized. LOL I even turned off VSync and saw over 200+ FPS. 🙂

Nagy Richárd

In 1.15-pre 1 I changed the render distance to 32 chunks and I have 20-30 fps. On 1.14.2 I have around 50-80.

CPU: Intel Core i5-4570

GPU: GeForce GTX 1050 ti

Cyphall

Same thing for me.

With a fully loaded world at a render distance of 32 chunks, with the exact same settings (including position and rotation), 1.14.4 gives me 115 to 120 fps and with 1.15 pre 1, I only get 60 to 65 (with down to 30 when looking in other directions).

The good point is that chunk loading seems to be faster at higher render distances.

 

Ryzen 7 2700x

GTX 1070

16 Go RAM

John Macknight

Good to see it's not just me. I found there to be a 32% performance decrease this update even when adjusting for the +2 actual chunk render distance as shown in the below pictures of the identical chunks being loaded.  I found this especially disappointing when the 1.15 update is supposed to be all about optimization and bug fixes, I hope they are able to track down the source of the issue as it seems clear now it affects Nvidia and AMD and Intel hardware they must know about this performance drop themselves already just from testing the releases on their machines. I remember way back in 1.8 snapshots they had developed a rendering algorithm similar to the version on the Minecraft Mobile app and it was a huge leave forward in performance and I tested performance to be somewhere in between 1.14.4 and 1.15.

[media][media]
violine1101

I haven't done any proper benchmarks, but it seems like client-side performance has become even worse in 1.15-pre1.

dpokor

wow... pre-release version 1? Honey blocks are pointless if the game is going to be a slideshow due to the GPU not boosting to 3D clocks, someone in the rendering team has to enable a flag or change a tag somewhere in the code to give the GPUs the memo that this particular OpenGL load is 3D rendering instead of general computing or crypto mining. Then we can perhaps start talking about optimization, which is way worse even with the GPU boosting correctly. Spoiler alert: -25%.

-First, a baseline: test of 1.14.4 with no tweaks or shenanigans. Minecraft Seed for this round of tests is "test2", fresh generated world. About 200FPS after a minute of waiting until GPU clocks stabilize. 44%GPU utilization at 2025Mhz.

[media]


-then 1.15-pre1 with no tweaks or shenanigans, reusing the world from 1.14.4 due to the bugfixing of world generation resulting in different visuals in some places, want a 100% correlated test here within reason (villagers or mobs popping in sight). About 110FPS, 38%GPU utilization at 1395Mhz

[media]


-then I forced the driver to boost the GPU to Maximum Performance via the nVidia Control Panel (right-click in windows desktop), had to manually add the javaw.exe in the Manage 3D Configuration tab to do so; AND manually select my GPU (1660Ti) as the predetermined OpenGL Renderer. The workaround does not work with only one of the two fixes. Adding a screenshot for visual reference, sorry it's in spanish but I think I'd have to change my OS language and reinstall the drivers to show you in english.

[media]

[media]


This workaround results in peaks of about 155-160FPS with 39% GPU utilization at 2025Mhz. GPU frequency usually dips below because there seems to be a "ghost" framerate limiter so the game hovers around 150±5FPS. I have the framerate unlimited as you can see in the F3 tags top left. Somehow, the illusion breaks when you look around as the GPU goes insane and it downclocks for no apparent reason other than refreshing the frame buffer and probably the texture buffer too; it dips well below the 60FPS mark which is quite a painful disparity between the top and bottom range of the framerate during playtime.
----------------------
TL;DR: in the same benchmarking conditions, 1.14.4 was giving 200FPS, 1.15-pre1 gives 110FPS if you're an average user or 150FPS if you know how to bruteforce your GPU as the OpenGL renderer and force Maximum Performance or 3D clocks-mode on it, but then the game stutters insanely when you actually look around and try to play instead of benchmark it. That's a -25% direct performance improvement in the absolute best case scenario.

Nassim Jahnke

This has had a way more drastic impact for me: whereas I have around 150 fps in 1.14.4 in an unchanched vanilla world with a render distance of 20, it drops to 40 and sometimes visibly below 30 in that same area (both also after waiting for everything to load in).

Turning the distance down to 12 gives it a more stable 60-70, but still with quite a lot of occasional stutters

Nassim Jahnke

A comment by slicedlime was that the drop in FPS is a tradeoff for a lot of other fixes and rendering in general - which is understandable with a drop from 200->150 or even 100, since both are perfectly playable. But in my (and a few of my friends') case, visibily having it below 30 is definitely not worth the tradeoff.

Eugene

Performance pertaining to chunk / rendering has gotten even worse with 1.15 Pre-release 1. It's pathetic. No snapshot subsequent to version 1.14.4 comes close.  I'm using Nvidia GeForce 210 on Linux. Maybe I'll produce another video and post it if it helps.

Cyphall

I just found that when I'm at 32 chunks render distance with the world fully loaded, when looking at the horizon, I have 30-40 fps, but when looking at my foots, I'm back to 400+ fps.

This clearly shows the problem comes from something happening in the camera frustum (like rendering or maybe chunk updates) and apparently not from chunk loading, as initially explained by sliced_lime.

NeunEinser

as initially explained by sliced_lime.

Just so that everyone is on the same page, the referenced post is this one: https://www.reddit.com/user/sliced_lime/comments/e00ohm/a_word_or_two_about_performance_in_minecraft/

I also linked it directly to the ticket now.

dpokor

after reading that Reddit post I'm baffled. So in the era of 240Hz monitors, Mojang is targetting 30FPS with the new rendering engine. I mean PAL was 50FPS and NTSC was 60FPS, they are literally targetting worse performance than the original PlayStation from 20 years ago.  I really hope they let us customize the target through settings or .txt.  People with capable systems shouldn't be punished because of people playing in potatoes, that's beyond unreasonable. But also beyond the scope of this bug report, so I'll stick to testing:

I wanted to try a harder graphics load so I loaded my multiplayer server with snapshot 19w34a (last one before the new rendering engine) and stood still for a minute until everything loaded in, then took a screenshot. 164 FPS, GPU at 1815Mhz 40% use

[media]

After that, I updated the same server to 1.15-pre1 and tried to apply my workaround from nVidia Control Panel to get the GPU to boost up in the client PC. Unfortunately, for whatever reason it won't work even if I restart the PC and apply the settings multiple times. I guess the game is happy to provide over 30FPS and doesn't bother to ask for more resources from the GPU lol. Waited 5 minutes to see if anything changed but nope: 76 FPS, GPU at 1095Mhz and chilling at 23% usage

[media]

So, when you're actually playing the game on a multiplayer server, you can expect at least a halving of the FPS from the old rendering engine to the new one. In this particular instance, dropping from 164 to 76FPS means a [1-(76/164)] x 100 = 53.6% performance drop in static conditions. I wanted to try dynamic conditions by logging and recording a test drive of a minecart rail facing the same spot, but unfortunately the game crashed on me several times while moving around in the world so I just gave up. FPS were consistently dipping below 60 in a machine that previously dipped to 120s in the same conditions.

Pretty sure most people would rather trade having 5-10 distant chunks not rendering but enjoy high framerates all time rather than having "all chunks rendered" (unable to personally verify due to game crashing) but potato FPS all time. I can bear having to stop mid-air to wait 3-5s until chunks are loaded if I'm flying long distances with the elytra; but I can't bear with barely 60FPS gameplay all time. It's a stuttery mess, and it's ridiculous that I can fly a plane in BFV at flawless 144FPS with explosions, terrain destruction, smoke and all kinds of madness going on a full-scale Iwo Jima island with 60 players; but I can't plant potatoes in my Minecraft base at 60FPS.

OpenGL doesn't even realise it's rendering a 3D load, so even though I crashed several times no crash-report was generated btw. At least not in the usual folder: %appdata%/.minecraft/crash-reports. The logs folder doesn't reveal anything on it's .log files either, nor the Windows Event Viewer.

Dariusz G. Jagielski

This issue is really awful. On 14.4 I can consistently hit 60fps (or really close too, like 5fps difference) whereas here I can barely hit 15.

Dariusz G. Jagielski

@dpokor Could you make some screenshots where you use Alt+Shift+F3 which unlocks some performance charts? From my own testing the biggest contributor to lag seems to be game renderer itself.

slicedlime

You do not need to convince us that this is a bug. This is not a forum for debate, and the reddit post clearly states that we are continuously working to improve performance.

If you have more data to add to the bug, please do so without unrelated walls of text. Otherwise, please refrain from posting.

The target of 30 FPS is a minimum limit. This doesn't mean that you will never get more than 30 FPS, it means that when the game has lots of work to do, it'll remain at 30 FPS at a minimum.

If you would rather have high FPS than chunks at a far distance, there is already a mechanism in the game for this - lower your render distance. Again, this does not mean we'll stop working on performance, but your confrontational attitude is doing nothing but adding to the noise.

Any further comments that do not provide additional information for this bug will be removed. Further comments that do add information are appreciated.

user-5f440

I also had annoying stuttering. Especially in fullscreen. What I did is installed beta version of nvidia driver(3.xx.x instead of 4.xx.x) and the game run smoothly again. Maybe you should try it too. Just saying.

 

Cyphall

So I went a bit deeper and used the Frame Profiler from Nvidia Nsight Graphics to hopefully find the cause of the FPS decrease when the world is already loaded and I found some interesting stuff.

1.14:

[media]

1.15:

[media]

First, in 1.15, there is a new OpenGL function used : glEnableClientState. This function is used 19191 times, which represents about a third of all the OpenGL calls.
Even tho it is used a lot, it only represents 1.24ms on CPU, which is not much compared to the total amount of time used to render a whole frame, so this is probably not the cause of the problem.

Second, the number of draw calls is pertty much the same between the two versions, with 3527 for 1.14 and 3841 for 1.15.
The difference could be caused by 1.14 not loading the farthest chunks, as I was using a render distance of 24 chunks (even tho I tried my best to load them all, waiting for the "chunks updates" in F3 menu to be 0 permanently and in all directions).
However, this small difference alone can't explains such a loss of FPS.

But the story doesn't end here. What I've found is that the 3841 draw calls in 1.15 takes 14.38ms on CPU and 3.52ms on GPU, where the 3527 draw calls in 1.14 only takes 9.43ms on CPU and 2.62ms on GPU. This means each draw call takes about 1.5* more time in 1.15 than in 1.14.
This difference can be explained by a potential switch from rendering blocks faces with quads to rendering them with triangles (which is the preferred way for maximum driver compatibility), a quad having only 4 vertices while 2 triangles (to represents the quad) having a total of 6 vertices.
In fact, this is probably what causes the FPS decrease.
Also, what we can see is that the rendering is heavily CPU botlenecked (draw calls taking much more CPU time than GPU time).

 

In my opinion, the solution could be to batch draw calls together to reduce their number and thus CPU time used for them. (I may be totally wrong as I haven't used batching myself yet, so I don't know exactly how this works)

Brianna Schuman

I think I'm spotting 2 disparate but connected issues emerging as I puzzle my way through the frame drop issues.  After letting the world load and cool off for a few minutes, I picked two spots on the server's spawn area base that are about 6 chunks apart.  I let the area sit for 2-3 minutes after getting to it.  Changing chunk render distance had minimal effect on frame rate.

Area 1- Next to a large base storage building with lots of chests, signs, etc.
A- facing the building:
FPS: 46 avg
E:12/195
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 29%
B- Facing cleared area. Large 8x8 map on ground using item frames, towards regular spawned land
FPS: 132 avg
E: 144/193
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 37%

Area 2 (6 chunks away; out of chest render range, map entities in between)
A- facing the building:
FPS: 105 avg
E:153/168
Total CPU % use avg: 39% (29% for JavaW)
Total GPU% use avg: 37%
B- facing unaltered natural spawned land
FPS: 170 avg
E: 4/188
Total CPU % use avg: 35% (25% for JavaW)
Total GPU% use avg: 40%

Conclusions derived from these simple tests:
1) Something is artificially capping Minecraft from fully using the CPU AND GPU to the full extent possible.  At no point was any single CPU core every running over 50%, and at no point did my GPU% ever go over 38%.  I have PLENTY of overhead available that's going unused for some reason. 
During void world block tests I did (below in point 2), I tested the same actions in 1.14.4 and 1.15.1 on a local world.  In 1.14.4 I hit 75% GPU/50% CPU use with a 20x20x20 chest group.  For 1.15.1, I never passed the 40% GPU/35% CPU boundaries I experienced above.  This reinforces again that something is capping out calls to the CPU and GPU, despite there being horsepower remaining.
2) Blocks that have previously been known to affect framerates (chests, signs, etc) are performing even worse.  I ran a separate test in a void world of dumping 4000 chests and another of 4000 wall signs into the world, and the frame rates of both were worse.  Signs in particular were  giving me a framerate 33% of that in 1.14.4.  The overall point being, some blocks seem to be affecting framerates very differently than in 1.14.4, and that is also contributing.

Machine info: i5-2500k/16GB/1050ti 4GB playing on an in home Vanilla MP server running Vanilla 1.15.1, server max render distance 12.

DrownedZombie

Added 1.15.2 to the affected versions.

Mike24

I cannot tell if 20w07a is affected. Someone please check this.

László Rasmussen

20w07a seems to have slightly higher FPS performance than 1.15.2, for me. Like 2 - 5%. But it's still not as high as the 1.14.4 days.

Mike24

Ok i would say the bug is still in 20w07a however it is more mild than in 1.15

Tstu0001

In 20w09a, the performance drops are identical to 20w07a and lower for me

Tstu0001

There seems to be some positive changes to performance 20w10a, but this issue is still noticeable.
I would honestly love Minecraft to use more of my GPU than a meager 32%

Edit:
In all snapshots, I found that pausing the game instantly stops the lag issues I have in game. In some instances it may lag immensely in the menu. Changing the render distance to any value stops the lag from there, but that is a temporary fix. The game will occasionally drop to an unplayable framerate regardless of what settings I change seconds to minutes after doing this. A small render distance and minimal settings does little to solve it.

dpokor

Messing around in a fresh singleplayer world, I found what could be the main culprit of the FPS issues: mobs around you, even with entity shadows off. Unfortunately, most people build mob farms near their bases (to let the babies grow to adult while you do some housekeeping/other stuff), so it's pretty much a game breaker for anything but a singleplayer world with the usual 70 cows, rabbits and chickens spawned around you.

Example with ~800 cows: 83FPS

[media]

After /kill @e[type=cow]: 144FPS (max. of my monitor, Gsync is on)

[media]

b...but 800 mobs is unreasonable!: it wasn't with the old rendering engine before. Usually people build at least the basic mob farms around their base: cow, chicken, sheep, pig, maybe even rabbit. And if you're in a server with 2-3 friends but sharing a common base/storage system, it's not unreasonable to have 50-100 of those 4-5 species of mobs in a pen to speed up the gathering of resources when you need to trade emeralds with another 50-100 villagers (5-10 of every profession to avoid spending an hour to gather some emeralds and xp). So it's not unreasonable to have at least 500 mobs around your base, then add some pets on top of it (pandas, horses, donkeys, cats, parrots, dogs, foxes, dolphins, tropical fish... you name it!), and you are easily halving your FPS just because you like to do other stuff in base while waiting until the baby animals grow up and you can farm the resources. I'd rather avoid ilmangoing everything and make it an afk-farm a thousand blocks away from base to have decent FPS in the place where I'm playing most of the time, it makes gameplay rather boring.

Hopefully you guys can find a solution! Not sure if it's possible to offload some of the calculations to the GPU... Maybe the performance pie chart could reflect how much time is spent calculating mob rendering vs terrain, to at least give us an idea of what could be tanking performance in crowded bases with multiple mob farms. That'd be my lazy fix for it: let people decide wether they value more their farms or their FPS xD. At least for the time being... hopefully a proper solution is feasible so we don't need to slaughter animals and villagers around our bases fingers crossed 😃

Brianna Schuman

There certainly has been FPS loss due to increased entity use. such as mob pathing improvements, etc.  This is particularly noticeable with villagers, chests, signs, etc.  This appears to potentially be a distinct issue as it does not explain what some of us are seeing as a deeper base issue: why the game appears to cap out around 30% CPU use and 40% GPU usage.  This is especially noticeable on lower end systems (e.g. i5-2500k/1050Ti) where it becomes super clear that lots of processing power is being left unused and frame rates suffer for it, for no obvious reason.

It may be that this issue needs to be bifurcated into two problems:

  • Entities using more resources than previously (Mobs, chests, signs, etc) causing lower frame rates

  • Game code unable to access all system resources on at least some machines; in other words, apparent artificial GPU/CPU usage caps.

Jfarf_Gl

Entities do seem to be much more resource intensive in 1.15.2 than 1.14.4. A simple way we test on my server is to load an area of the overworld, kill all entities, and watch the performance drastically improve. Performance is also better in the Nether relative to the Overworld, especially compared to previous updates. The Nether has very few entities loaded in, relatively. 

 

My FPS is anywhere from 35-50% of what it was in 1.14.4 on average, making the game borderline unplayable for many on my server. 

TheTamedWolf

I have intel 4000 and have less than 30 fps even with render distance all the way down and everything at the lowest setting T.T it used to be all the way passed 100 fps before 1.8 or 9 with render distance passed 12 and fancy settings and all that. idk what happened.

Edit: 1.15 to 1.15.2 to 1.16 pre release 2

user-a4a49

Confirmed in 1.16 Release Candidate 1.

Vectrobe

A very important note I will add to this; OpenGL effectively has a hard limit as to how many instructions can be passed through per second. If you add more little details to grass for example, that involves one or two more GL calls, the maximum framerate will be dropped accordingly.

If you wish to optimise against this problem, you'll want to implement chunk batching. If you batched every 2x2x2 sets of chunks (32x32x32 blocks) for example, you can cut your total draw calls by as much as 8 times. The one caveat to doing this however is chunk re-bakes (updates) will take extra time, so it's advisable that the batching be done for distant chunks, or ones that otherwise are not updating frequently.

An additional suggestion would be skinned meshes for entities, so that each entity can be rendered with a single set of draw calls instead of one set for every box they are made of. This would be incredibly simple to implement here as you'd only need a single bone per box.

Charadon

Still an issue in 1.16.3, superflat world nets 150-200fps (heavily fluctuates, not stable framerate), while 1.14.4 superflat world nets 250-300 fps (stabilizing around 300).

Nightwind8887

Affects 20w45a

Adrian Östergård

As we've done some fairly substantial changes to the rendering pipeline with snapshot 21w10a, this bug report is no longer relevant.

If you're having performance issues regarding the switch to OpenGL 3.2 Core profile, please see bug report MC-219639, and follow the instructions.

dpokor

(Unassigned)

Confirmed

Very Important

Performance, Rendering

mojang_internal_2

19w42a, 19w45b, 19w46b, 1.15 Pre-release 1, 1.15 Pre-Release 2, ..., 1.16.4 Pre-release 2, 1.16.4, 20w45a, 20w49a, 21w03a

Retrieved