cl_yieldcpu 1 causes massive stutter with nVidia RTX hardware on Windows

[nashmuhandes]

The default setting, cl_yieldcpu 1 causes huge stutters on Windows 10 (and can be seen clearly on the built-in frame graph).

Setting it to 0 eliminates the frame spikes.

[Xylemon]

We'll look into this.

[fhomolka]

@nashmuhandes
Hey, could you test something for me? Since you surely experienced this.

test_fteqw.zip

In this zip, there are 2 binaries, one is a regular release binary for windows, the other uses SDL.
Does this issue happen with both binaries?

[Xylemon]

I'm hoping @nashmuhandes or another Windows 10/11 user can test, I tested these two binaries on a Windows 7 AMD/Nvidia machine and can't get any stuttering related to cl_yieldcpu. But I didn't get any stuttering with the binaries from fteqw.org either

[Xylemon]

Tested binaries stable binaries from fteqw.org and @fhomolka's binaries on another (desktop) machine and had no stutter with either:

OS: Windows 10 Pro
CPU: Intel i9-7900X @ 3.30 GHz
GPU: nVidia GeForce GTX 1070

If you could @nashmuhandes, let us know what CPU/GPU you have. I was also curious if you had OGG music installed? Maybe the stuttering is actually caused by bug #136

[nashmuhandes]

• Fully clean FTEQW - R6343 64 bit downloaded from fteqw.org, extracted into a separate folder
• ID1 folder with the 2 PAK files and nothing else - no music, no lit maps, no nothing. It's as minimal as it gets
• Specs: Windows 10 Pro, i7 8700 @ 3.2 GHz, RTX 2080
• Ran the game (again - clean install - fresh CFG generated) and jumped into START right away, toggling cl_yieldcpu on the fly without any restarts. Attached pictures are immediate before/after results. Notice the mini spikes when the CVar is on, VS the extremely flat graph when the CVar is turned off.

cl_yieldcpu 1 (default)

cl_yieldcpu 0

[fhomolka]

@nashmuhandes
Yes, that build has not been changed to deal with that

What about the builds provided here:

test_fteqw.zip

I was also curious if you had OGG music installed? Maybe the stuttering is actually caused by bug #136

@Xylemon , We ruled that out in the brief conversation made in the Discord server, just before the issue was made on the tracker

[Shpoike]

Try setting sys_clockprecision to 2 then back to 1 or something. I suspect it'll help a bit (until you restart the engine) - I think the engine might be failing to use the cvar's callback and thus not actually changing the system settings that the cvar is meant to override by default.

Either way any kind of yielding/sleeping is going to increase stuttering by a bit, its just a question of how much. Its tempting to just enable it by default, but the environmentalist in me says no, let the cpu sleep between frames.
The other option is to force vsync on by default and let the gpu drivers do the wait-for-hardware-interrupt in a low power mode instead of fte busywaiting without the low-cpu-power-mode thing.

[Theuaredead]

Having tested this on my main machine and another machine, I was only able to reproduce the reported bug on my dad's laptop.

One of the common factors between the other machine and the reported machine is the RTX series of card.

[nashmuhandes]

@nashmuhandes Hey, could you test something for me? Since you surely experienced this.

test_fteqw.zip

In this zip, there are 2 binaries, one is a regular release binary for windows, the other uses SDL. Does this issue happen with both binaries?

Finally got around to testing this (sorry, been real busy).

fteqw64.exe still shows the spikes.

I'm unable to run the SDL executable, missing DLLs.

Setup is a 100% clean install (separate folder with fresh CFG) with literally only id1 PAKs and nothing else (no music, no colored lights etc).

[Xylemon]

fteqw64.exe still shows the spikes.

I'm unable to run the SDL executable, missing DLLs.

You can get an official SDL2.dll from here https://github.com/libsdl-org/SDL/releases/download/release-2.28.2/SDL2-2.28.2-win32-x64.zip

[nashmuhandes]

@nashmuhandes Hey, could you test something for me? Since you surely experienced this.

test_fteqw.zip

In this zip, there are 2 binaries, one is a regular release binary for windows, the other uses SDL. Does this issue happen with both binaries?

There is unfortunately no difference with the test_fteqw executables, both normal and SDL.

I am still getting the same results as the official builds, as in - frame spikes with cl_yieldcpu 1, but otherwise completely flat frame graph with cl_yieldcpu 0.

And again - fresh install, fresh CFG, all-default settings, base PAKs only and no additional content or music.

My OS and hardware hasn't changed - Windows 10 Pro, i7 8700 @ 3.2 GHz, 32 GB RAM, m.2 SSD, RTX 2080.

[nashmuhandes]

One thing that I just realized I didn't mention anywhere in here - I'm on a 144 hz display. Not sure if that has anything to do with anything (like maybe the problem isn't noticable on 60 hz displays? Just a wild guess, heh)

[Xylemon]

We have tested it on different refresh rate displays with no problem. The only common factor we've found so far is RTX series hardware. FTE just may not deal with their power consumption properly, but we don't have a lot of RTX hardware to test, just a laptop from a family member.