Power-saving sleep makes some Wine games perform really bad

[RalfJung]

The power-saving usleep introduced with bebe0bf makes some Wine games perform really badly: The game stutters, with the framerate going down to <5fps (estimated) every few seconds. Specifically, both TrackMania Nations: United and Audiosurf are unplayable with the default configuration. Setting PRIMUS_SLEEP=10 fixes the problem: Both games remain perfectly fluid (>=30fps, I would estimate).

Some other games I tried are not affected, which is why it took me so long to notice this.

This is with Debian testing, an NVIdia GeForce 630M and an Intel Sandybridge GPU.

[amonakov]

Can you try checking how CPU frequency scaling affects it? Specifically, by checking whether using "performance" scaling governor and p-state/acpi scaling driver changes things.

[RalfJung]

Can you try checking how CPU frequency scaling affects it? Specifically, by checking whether using "performance" scaling governor

You mean, I should write "performance" to
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor? I can try that.

and p-state/acpi scaling driver changes things.

What exactly would I have to do to try this?

[amonakov]

On Tue, Mar 31, 2015 at 4:18 PM, Ralf Jung [email protected] wrote:

Can you try checking how CPU frequency scaling affects it? Specifically,
by checking whether using "performance" scaling governor

You mean, I should write "performance" to
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor? I can try that.

Right, and ...

and p-state/acpi scaling driver changes things.

What exactly would I have to do to try this?

You can use dmesg | grep -iE p.?state to see if pstate driver is used by
default. If so, you can boot with intel_pstate=disable on the kernel
command line to disable it, and then the old acpi scaling driver will be
used.

[RalfJung]

Changing the governor to "performance" did not have any noticeable effect.

Then I rebooted with intel_pstate=disable, and indeed now things behave much better. Of course, I won't leave the p-states disabled...

I also did a crazy (stupid?) experiment and set PRIMUS_SLEEP to 150. The effect was that it would sleep longer and longer with every frame, presumably it would take 150% of its previous sleep time, not knowing that it could actually have been much faster... in other words, it seems the heuristic is not good at compensating that it slept too long (and will only do that in 10% steps, with the default setting, I guess). Mind you, this is without actually looking at the code.

[amonakov]

On Tue, Mar 31, 2015 at 9:54 PM, Ralf Jung [email protected] wrote:

Changing the governor to "performance" did not have any noticeable effect.

Then I rebooted with intel_pstate=disable, and indeed now things behave
much better. Of course, I won't leave the p-states disabled...

This flag does not disable frequency scaling altogether, it switches from
Intel p-state driver to ACPI cpufreq driver. Intel p-state driver is
relatively new, and I've seen mentions that sometimes it has worse
behavior (nothing specific though). What kernel version are you running?

I also did a crazy (stupid?) experiment and set PRIMUS_SLEEP to 150. The
effect was that it would sleep longer and longer with every frame,
presumably it would take 150% of its previous sleep time, not knowing that
it could actually have been much faster... in other words, it seems the
heuristic is not good at compensating that it slept too long (and will only
do that in 10% steps, with the default setting, I guess). Mind you, this is
without actually looking at the code.

Right, setting PRIMUS_SLEEP at 100 or above is not useful, and recovering
after a long delay takes several frames. Currently the heuristic is
extremely simple.

—
Reply to this email directly or view it on GitHub
#164 (comment).

[RalfJung]

This flag does not disable frequency scaling altogether, it switches from Intel p-state driver to ACPI cpufreq driver. Intel p-state driver is relatively new, and I've seen mentions that sometimes it has worse behavior (nothing specific though).

I see. I did not have problems so far. Whatever that means^^

What kernel version are you running?

$ uname -a ... 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux