GZDoom perfomance issue

Forum rules
Contrary to popular belief, we are not all-knowing-all-seeing magical beings!

If you want help you're going to have to provide lots of info. Like what is your hardware, what is your operating system, what version of GZDoom/LZDoom/whatever you're using, what mods you're loading, how you're loading it, what you've already tried for fixing the problem, and anything else that is even remotely relevant to the problem.

We can't magically figure out what it is if you're going to be vague, and if we feel like you're just wasting our time with guessing games we will act like that's what you're really doing and won't help you.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: GZDoom perfomance issue

Re: GZDoom perfomance issue

by Rachael » Sat Feb 08, 2025 8:50 pm

https://github.com/ZDoom/gzdoom/commit/ ... 4d8c707ca9

So as of that commit:
  • vid_lowerinbackground is now the method that lowers GZDoom's CPU usage in the background
  • Priority changing code is removed entirely. It still exists for the CPU speed calc in Windows but it does it and then switches it to whatever priority GZDoom was originally launched with. (Note that the speed calc code requests 'realtime' priority - I believe Windows NT and later automatically demotes that to 'Highest' priority if the app is not in Administrator mode)
  • vid_lowerinbackground overrides vid_dontdowait - if for some reason you can't afford to have GZDoom lower its FPS then simply set vid_lowerinbackground to false.
This should tie up any loose ends for this issue.

Re: GZDoom perfomance issue

by undeadgamer9609 » Sun Feb 02, 2025 9:23 am

Never mind i just remembered to check and saw the same issue on the board sorry.

Re: GZDoom perfomance issue

by undeadgamer9609 » Sun Feb 02, 2025 9:21 am

I need to screenshot a new issue all the text looks slightly corrupted but i don't know how to make a screenshot this is i noticed yesterday so this is very recent.

Re: GZDoom perfomance issue

by Rachael » Sun Feb 02, 2025 5:51 am

undeadgamer9609 wrote: ↑Sat Feb 01, 2025 11:52 pm Sorry for the late reply' just been busy so i set gzdoom to windowed mode to test the alt-tab causing the issue from loss of focus and it still lowered its priority so it can't be because it is losing focus from alt-tab as gzdoom is it seen in the background running and now the text when gzdoom is started looks slightly corrupted you can still tell what is says but it don't look normal i can show you what it looks like as soon as i know how to capture a screenshot.
The recent changes won't be in the latest version of GZDoom until a new release.

Another release is in the works (technically, one always is anyhow) but it probably won't be available for at least a week or two yet. I'd like to wrap up the loose ends from this thread first and remove the priority changing code and put in the optional background limiter which will be turned on by default.

There might be other loose ends that others need to wrap up too before an official release can be made.
Graf Zahl wrote: ↑Sat Feb 01, 2025 10:18 am There's the vid_dontdowait CVAR, but for obvious reasons it will be ignored if FPS are not capped.
The background limiter will override the mentioned cvar - that cvar was mostly put in in order to allow cheap crappy g-sync/free-sync setups to not flicker the screen. If you tab out that should no longer be a problem.

Re: GZDoom perfomance issue

by undeadgamer9609 » Sat Feb 01, 2025 11:52 pm

Sorry for the late reply' just been busy so i set gzdoom to windowed mode to test the alt-tab causing the issue from loss of focus and it still lowered its priority so it can't be because it is losing focus from alt-tab as gzdoom is it seen in the background running and now the text when gzdoom is started looks slightly corrupted you can still tell what is says but it don't look normal i can show you what it looks like as soon as i know how to capture a screenshot.

Re: GZDoom perfomance issue

by Graf Zahl » Sat Feb 01, 2025 10:18 am

Rachael wrote: ↑Sat Feb 01, 2025 7:14 am I don't think GZDoom does this natively, yet, but it can be set to do so, I would like to make it optional though, and overall I think it's a good idea.
There's the vid_dontdowait CVAR, but for obvious reasons it will be ignored if FPS are not capped.

Re: GZDoom perfomance issue

by Rachael » Sat Feb 01, 2025 7:14 am

dpJudas wrote: ↑Sat Feb 01, 2025 3:39 am Secondly, lowering the FPS to 30 (or whatever it is set to) already deprioritizes the app when its in the background.
I don't think GZDoom does this natively, yet, but it can be set to do so, I would like to make it optional though, and overall I think it's a good idea.

Re: GZDoom perfomance issue

by Rachael » Sat Feb 01, 2025 7:13 am

I'm all for removing the priority changing code too. I never liked it in the first place.

There is some logic for it in the CPU measuring step, but even then I am a bit iffy on whether it's really necessary. And measuring the CPU speed is one of the "cool" things GZDoom does that's probably ultimately unnecessary anyhow.

Re: GZDoom perfomance issue

by dpJudas » Sat Feb 01, 2025 3:39 am

If it were up to me I'd remove the code. First of all the OS itself already boosts priority on foreground apps. Secondly, lowering the FPS to 30 (or whatever it is set to) already deprioritizes the app when its in the background. Third, we live in a multicore world today, so its not like it directly interrupts the running thread of the foreground app anyway. And last, the thread still has to run eventually, so whatever micro-stutter its meant to avoid is still going to occur, if that is what is trying to avoid.

I also once read an article, although I can't really find it anymore to link it here, that effectively argued that the entire concept of thread priority class is broken. The issue is basically that in a chaotic world where there's literally hundreds of threads doing all kinds of stuff, knowing what is important how long a "low priority" thread can be delayed without severe negative impact is impossible to predict. It is a bad 90's idea that should be left there.

PS. If a debugger is attached to a process that changes thread priorities and how threads are scheduled too, so that also shouldn't be the purpose of this code.

Re: GZDoom perfomance issue

by Blzut3 » Fri Jan 31, 2025 8:50 pm

Honestly, I wonder if it might make sense to remove the priority changing code. I know it's not a lot of code so really doesn't make a difference one way or another, but a comment seems to indicate at one point the idea was to boost the priority for extra performance (guessing reverted to normal since doing that really isn't recommended). So might mostly be a relic from the single core days to make the debugging experience a little better? I could be wrong but I don't think this is a thing that's typically done by other games?

Re: GZDoom perfomance issue

by Rachael » Fri Jan 31, 2025 5:23 am

Blzut3 wrote: ↑Fri Jan 31, 2025 4:13 am I don't daily Windows so can't confirm, but I believe setting i_pauseinbackground to 0 should disable the priority changing code, but yeah I suspect he might just be observing GZDoom lowering its priority while he interacts with task manager.
The logic in that was a bit weird but I went ahead and fixed it, and even took the extra step to add a cvar that will turn off priority changing entirely if disabled.

Re: GZDoom perfomance issue

by Blzut3 » Fri Jan 31, 2025 4:13 am

I don't daily Windows so can't confirm, but I believe setting i_pauseinbackground to 0 should disable the priority changing code, but yeah I suspect he might just be observing GZDoom lowering its priority while he interacts with task manager.

Re: GZDoom perfomance issue

by Hellser » Thu Jan 30, 2025 1:32 am

Blzut3 wrote: ↑Mon Jan 13, 2025 8:59 pm Only time GZDoom changes its priority is when you task switch away from it (and then restores to normal when returning). It does sound like you have some tool running either intentionally or via preinstalled bloatware that's trying to "optimize" your system.
When you alt-tab away from GZDoom (or go to a different Window) - it will lower itself down to Low then should return to Normal upon returning back to GZDoom. You have yourself a schrodinger's cat situation here where as GZDoom is either in the Normal or Low Priority until observed.

Again, something is turning GZDoom down to Low and GZDoom shouldn't be doing that unless it loses focus. :shrug: Something fucky is going on and given that you're the only one reporting this issue, I can't fathom what's going on. We've done what we could and the only time GZDoom ran normally is immediately after you refreshed Windows. To which this could be a Windows bug or one of the various drivers that Windows installs in the background, an update or undisclosed behavior is rearing its ugly head within Windows.

Re: GZDoom perfomance issue

by undeadgamer9609 » Mon Jan 27, 2025 11:43 am

Through task manager in details but for some reason the only process that does lowers it's priority is gzdoom i have tested around a dozen or more games and apps and they stay at normal never lowering do you think this might be a rare gzdoom bug or something like that just trying to find out why only gzdoom is affected.

Re: GZDoom perfomance issue

by Blzut3 » Sun Jan 26, 2025 8:57 pm

Nothing else is jumping out at me either in your process or service list.

How are you observing the priority change by the way?

Top