Jump to content

Extra high GPU usage when window is not in focus MC 1.12.2 Forge 14.23.5.2860


Recommended Posts

Posted (edited)

Tested with 5900X, 64GB 3200 MHz, 3070 Ti, driver 551.86  Edit: Win 11 Pro, MC allocation limit 16GB
GPU clock range: 200 - 1950 MHz, usually 210 MHz with 10-30% utilisation on desktop idle use

Render settings: Vsync ON, Framerate unlimited, Render distance 32, Fullscreen ON (60hz monitor, so 60 fps with vsync)

Vanilla minecraft: Main menu: 210mhz idle clock always, ingame clock around 400 - 1000 mhz with ~30% utilisation and after alt+tab stays at same.

Modded install with curseforge app, only said forge added:
Main menu: 210 mhz idle clock always, ingame clock around 400 - 1000 mhz with ~30% utilisation, but after alt+tab gpu clock shoots up to 1950 mhz and utilisation is at 50-60%
After disabling all render and chunk related stuff in config, after alt+tab it goes up to 1500 mhz.
So game turns gpu into space heater when its not even seen. GPU usage returns to expected when game comes back on top.

If instead of unlimited fps, fps is set to ~60, then during alt+tab gpu stays at same range as vanilla, but minecraft has horrible limit logic and framerate limit causes lot of tearing, so its not an option.
So it seems that when alt+tabbing, for some reason logic no longer takes vsync toggle into account.

So expected behaviour would be for it to work like vanilla does. keep rendering in same manner, no matter if its seen and use same amount of resources.

Essentially noticed this behaviour while playing Supersymmetry and after elimination testing, result was that only Forge was enough to cause it. And also confirmed it by doing fresh pack with only Forge added, so no other mods even in disabled state.
Also happened with both singleplayer and remote multiplayer.

Other offender was "Universal Tweaks" which introduced same effect to main menu with its
# Removes the hardcoded 30 FPS limit in screens like the main menu
B:"Uncap FPS"=true

setting, meaning when game was on top, it still worked in limits of vsync cap, but after alt+tabbing even in main menu gpu usage shot up to max.

Edited by Labris
Forgot information
Posted (edited)

Did some more testing and found workaround.

Newest MC and Forge for it didn't have this problem, also isolated that problem is only with fullscreen, meaning there is problem with exclusive fullscreen handling when application gets moved to background/minimized.

So installing this mod fixed problem for MC 1.12.2 and forge for it https://www.curseforge.com/minecraft/mc-mods/fullscreen-windowed-borderless-for-minecraft

Edited by Labris

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I’m working on a Manta Ray entity in MCreator using GeckoLib animations, and my goal is to have a looping (flip) animation that ends at −360°, then transitions seamlessly into a swim animation starting at 0°. However, every method I’ve tried—like quickly interpolating the angle, inserting a brief keyframe at 0°, or using a micro “bridge” animation—still causes a visible “flash” https://imgur.com/a/5ucjUb9 or "jump" when the rotation resets. I want a perfectly smooth motion from the flip’s final rotation to the swim’s initial rotation. If anyone has solved this in MCreator/GeckoLib, or found a better trick for handling the −360° →0° gap without a snap, I’d appreciate some advice ! P.S.- I cannot set swim to start at -360 because I would have the same issue but in reverse. Here's the custom LoopingAnimationGoal :   class LoopingAnimationGoal extends Goal { private final MantaRayEntity entity; private final int cooldownTime; private int animationTimer; private int cooldownTimer; // New boolean to prevent double calls private boolean isLoopingActive = false; public LoopingAnimationGoal(MantaRayEntity entity, int cooldownTime) { this.entity = entity; this.cooldownTime = cooldownTime; this.animationTimer = 0; this.cooldownTimer = 0; this.setFlags(EnumSet.of(Flag.MOVE, Flag.LOOK)); } @Override public boolean canUse() { System.out.println("[DEBUG] LoopingGoal canUse => cooldownTimer=" + cooldownTimer); if (cooldownTimer > 0) { cooldownTimer--; return false; } BlockPos entityPos = entity.blockPosition(); boolean canUse = entity.isWaterAbove(entityPos, 4); System.out.println("[DEBUG] LoopingGoal canUse => WATER " + (canUse ? "DETECTED" : "NOT DETECTED") + " at " + entityPos + ", returning " + canUse); return canUse; } @Override public void start() { entity.setAnimation("looping"); animationTimer = 63; isLoopingActive = true; System.out.println("[DEBUG] Looping animation STARTED. Timer=" + animationTimer + ", gameTime=" + entity.level().getGameTime()); } @Override public boolean canContinueToUse() { System.out.println("[DEBUG] LoopingGoal canContinueToUse => animationTimer=" + animationTimer); return animationTimer > 0; } @Override public void tick() { animationTimer--; System.out.println("[DEBUG] LoopingGoal TICK => animationTimer=" + animationTimer); // We stop ONLY if we are still looping if (animationTimer <= 0 && isLoopingActive) { System.out.println("[DEBUG] condition => animationTimer <= 0 && isLoopingActive"); stop(); } } @Override public void stop() { // Check if already stopped if (!isLoopingActive) { System.out.println("[DEBUG] stop() called again, but isLoopingActive = false. Doing nothing."); return; } System.out.println("[DEBUG] Looping STOP at tick=" + entity.level().getGameTime() + ", last known rotation=" + entity.getXRot() + "/" + entity.getYRot() + ", animationTimer=" + animationTimer); // Immediately switch to "swim" entity.setAnimation("swim"); // Reset cooldown cooldownTimer = cooldownTime; // Disable looping to prevent a second stop isLoopingActive = false; System.out.println("[DEBUG] Looping STOP => setAnimation('swim'), cooldownTimer=" + cooldownTimer); } }  
    • So is the intention of the crusher for ores meant to be used with a silk touch pickaxe or something? Cause that seems like too much effort just to profit off of the machine, when everything drops as raw materials now. Am I just missing something? 
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
  • Topics

  • Who's Online (See full list)

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.