PathOfBuilding icon indicating copy to clipboard operation
PathOfBuilding copied to clipboard

high cpu/gpu usage when minimized

Open nvm2 opened this issue 1 year ago • 14 comments

Check version

  • [X] I'm running the latest version of Path of Building and I've verified this by checking the changelog

Check for duplicates

  • [X] I've checked for duplicate open and closed issues by using the search function of the issue tracker

How is Path of Building expected to behave?

should not use more cpu/gpu when minimized

How does Path of Building behave?

after about a minute or two of pob being minimized, it uses too much cpu/gpu resource. Looks like 100% cpu single thread and 50% gpu (checked using task manager)

How to reproduce the issue

  1. start pob
  2. minimize
  3. wait 2 minutes

Character build code

No response

Screenshots

pob_high_cpu

nvm2 avatar Mar 25 '24 02:03 nvm2

and ram also. its like miner. it allocates/deallocates memory each second even minimized.

0x111BA6FA avatar Mar 25 '24 19:03 0x111BA6FA

and its is too much usage even maximized. im not expert in gui. it is rendering, right? can we set desired fps, 1 for example? or re-render only after activity? why do i need continious re-rendering for planner app? seems like my CPU doing unnecessary work, just heating my air.

0x111BA6FA avatar Mar 25 '24 19:03 0x111BA6FA

Path of Building is built from the start around what amounts to a 2D game engine named SimpleGraphic with Lua scripting. The runtime handles windowing, input, subscripts, drawing and things like that.

As it's built like a game, there's a main loop that checks for inputs, checks for notifications from subscripts, calls into Lua to do a frame, and renders the results. Almost all the logic happens in the Lua side of the program and that's one of the reasons why PoB is able to so quickly adapt to changes in leagues and patches; it's a very prototype-friendly language.

This design however means that as everything from reacting to build changes, processing input/UI and issuing draw calls is done every frame. If we don't process frames, background tasks in subscripts get eventually blocked, incremental computations like node power can't progress, tooltips can't update, etc. We have some logic to pace frames already when likely to not be needed, but that already can be felt as background computations and updates cease to progress when defocused.

OP's computer is not representative of the normal operation of the program when minimized. It typically consumes a small amount of CPU and GPU while idle. This can be amplified if the computer for some reason doesn't honour vsync or has hooks that interfere with the natural throttling of the render loop. When properly throttled it can't eat more than a particular amount of resources, and for most reasonable computers that's of extremely limited impact on the game; especially if it's prioritized by running in (windowed) fullscreen.

For now the best you get is reducing the cost of frames by not redrawing identical frames. If nothing changes in the window; displaying even at 60 FPS is mostly quick-stepping through the simulation and ignoring the draw requests. It should have minimal impact on the GPU so sorely needed by Path of Exile.

Much of the rendering work done in the new runtime indirectly helps with this, as it takes much less GPU effort to draw a frame now in most situations, ending up with less power spent when meeting a particular frame rate.

If you're bored you could probably play with something like RivaTuner and try to artificially constrain the update rate of specific programs.

I've long wanted to have PoB function in a more event-driven manner as you suggest to reduce the load on the computer, but that requires some serious restructuring and is far away on the roadmap. It might be possible to change throttling in some way to not run amok in case the driver misbehaves, but in the end it's a matter of priorities when we have fewer people than things we would like to do.

zao avatar Mar 25 '24 20:03 zao

If you're bored

yes, im bored reading your zerobrain neurosh1t.

some serious restructuring

one flag - activity since last update true/false. do not render if no activity. like it did in pull request with minimizing. activity is mouse or kb event. it is veeery simple to do if it is possible, or its is just impossible.

just dont answer pls. ure stup1d. i hate stup1ds.

0x111BA6FA avatar Mar 25 '24 21:03 0x111BA6FA

@nvm2 Could you tell me more about your environment to help us figure out what might be causing your PoB to consume surprising amounts of resources? It would help inform any work on making it less so.

What kind of CPU, GPU, Windows version. Are you on a variable-rate display with G-sync/FreeSync, do you force VSync off, do you have any unusual overlays that hook into programs?

zao avatar Mar 25 '24 22:03 zao

cpu - AMD Ryzen 5 7500F gpu - GeForce RTX 3060 12gb Windows: Version 10.0.19045 Build 19045 144Hz display, variable rate is enabled vsync is not forced geforce experience overlay is the only overlay I can think of, also the issue is not consistent, sometimes it works just fine

nvm2 avatar Mar 26 '24 01:03 nvm2

I figured out how to reproduce this bug reliably and it's really strange. Collapsing window by clicking on its icon in windows taskbar seems to cause this issue. If I minimize window using right-top button everything is normal, cpu/gpu usage is around 0%. Also I tried using ahk script to minimize window and it doesn't cause the issue. Forcing VSync off doesn't reproduce the issue either. I tested this on the other machine with fresh install of pob, same bug happens there too. I hope this helps.

nvm2 avatar Mar 26 '24 08:03 nvm2

I'd just like to add that I have replicated this behaviour using the instructions commented above.

Minimizing via icon leaves me at 8-9% usage for PoB, with one thread absolutely maxed out on my 5800H. (Plugged in, boosting, no limitations on perf). image Minimizing via minimise icon, or even just having the program fully open, leaves me at 0.7% usage and the thread almost completely frees up. image

I have attached images in support of the points above.

Edit (Environment): CPU - AMD Ryzen 7 5800H GPU - GeForce RTX 3070 Mobile (130W) Windows: Version 10.0.19045 Build 19045 165Hz display, variable rate is enabled, locked to max 120Hz, PoB tested locked to 60Hz, no change in behaviour GSync enabled, VSync on

Asa-Jai avatar Mar 26 '24 10:03 Asa-Jai

Thanks for the computer specs and repro details. We have reproduced this across several team members, the key commonality seems to be Windows 10.

zao avatar Mar 26 '24 19:03 zao

Keeping this open, as the issue is only half-fixed

Wires77 avatar Mar 27 '24 07:03 Wires77

Regression noticed with the latest update.

Now when I minimise using the button on the top right, the high cpu usage of one whole thread is presented. So now both methods of minimisation cause one thread to lock at 100% utilisation and present high CPU usage. When PoB is not minimised, super low CPU usage noted.

Asa-Jai avatar Mar 28 '24 12:03 Asa-Jai

This PR should solve that https://github.com/PathOfBuildingCommunity/PathOfBuilding-SimpleGraphic/pull/53

Hopefully it gets merged and a release soon enough

In the meantime you can try to compile SimpleGraphics yourself and replace the DLL manually

ryuukk avatar Mar 28 '24 13:03 ryuukk

Just found this issue because I had the same problem on W10.
And because I wanted to look into how to get automatic line breaks/word wrap in the 'notes' tab.

Path of Building is built from the start around what amounts to a 2D game engine named SimpleGraphic with Lua scripting.

@zao Thank you for the explanation, that sounds - interesting. And probably explains the ~3% CPU usage for it just being idle which I find insane. Why would anyone do something like that in the first place?

ganego avatar Mar 29 '24 11:03 ganego

@ganego The early years of the project are veiled in mystery ;) It's one of the things that have served the project well over time allowing for rapid prototyping of functionality every league, despite its drawbacks.

The changes ryuukk mentioned have been merged into the runtime repository and should be in a PoB release in the future.

zao avatar Mar 29 '24 11:03 zao