Mesa Fixes A Large Performance Regression For Systems Using HPET

[Vistaus]

Should AMD's Ryzen 9 5900HX be included in "old CPUs" here? I currently get:

Same CPU here, but I get:

> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

[stormcrow]

niko@talos2 ~ $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
timebase​

What the hell is timebase?

The time counter for the Power architecture, PPC, Power9, etc. The clock source is architecture dependent (and even revision dependent) and far as I know only x86 post 486 uses TSC, which is an actual hardware timer addressed by the TSC pin on all subsequent x86 derived CPUs. It's also not always fully functional or desirable to use it as there are other timer circuits in an x86 based system that might be more useful for any given application including the HPET (High Precision Event Timer), the PIT (Programmable Interrupt Timer), and the RTC (Real Time Clock) and there are various reasons why you might or might not want to use them (speed not being one of them, although very short intervals and precision might). So no, it's not always correct to use TSC. As to why HPET is used without an end user's direct input, that may depend on distribution specific defaults, or it may be some logic that determines if the system's (CPU's) TSC is reliable or not. I've not looked into it in a number of years since timing on x86 based systems became more reliable (it used to be downright atrocious - that's not to say individual systems can't still be awful!).

Edit to add: This is one setting where you should know exactly what your doing, what the side effects can be, and have a damned good reason why you should change the default. The timing counter on any given computer system can screw up the entire running system in subtle and non-subtle ways. (Slow isn't always bad. Consistent accuracy is the key to timing counters, not speed!) Also, consider that not all architectures even have more than one addressable timing circuit available. If you don't know what you're doing, don't touch this knob.

[fitzie]

Should AMD's Ryzen 9 5900HX be included in "old CPUs" here? I currently get:

❯ uname -a
Linux 6.3.12-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jul 6 04:05:18 UTC 2023 x86_64 GNU/Linux​
❯ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm​
❯ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet​

I noticed recently my performance took a nosedive in F1 22 (on VKD3D-proton/Vulkan) and the game is now unplayable. Wondering if this could be the cause. I'll have to test older Kernels.

you should check the boot log, because it should indicate why it rejected tsc. it's pretty easy to show how poor hpet performs compared to tsc, just counting how many gettimeofdays you can run in a second in a tight loop is enough to show a difference, but the worst is that hpet is one timer per box, so if each core is running gettimeofday they are all competing for time.

lots of old systems were configured to hpet due to tsc not being consistent on the machines (as people have mentioned earlier). You could have an old kernel command line, or just dealing with a legacy default. you should be able to force tsc through kernel command line.

easiest way to tell if you are buggy, is just run gettimeofday in a loop, and see if time ever goes backwards. just have to make sure the process migrates between cores.

[X_m7]

Meanwhile my Ryzen 7 6800H doesn't even have HPET as an option, only TSC and acpi_pm, and currently it's using TSC.

[chuckula]

Thanks to this article I'm checking my custom kernel configuration to make sure I've got TSC going!

[V1tol]

Thanks to this article I'm checking my custom kernel configuration to make sure I've got TSC going!

I think it should be enough to have

clock=tsc

in kernel command line for that.

[cl333r]

Is Vulkan also affected?

[superm1]

Same on mine. That's interesting. I thought my 5950X should definitely use HPET and I don't remember tinkering anything in UEFI related to that.

Check for a BIOS upgrade from your motherboard vendor. The kernel falls back to HPET if TSC isn't working well enough. There were platform bugs on Ryzen 5xxx that are fixed in newer BIOS. You might be caught in those.

[skeevy420]

My AMD R5 4650G...I have no idea how my Powerlevel10K will be rendered for y'all...gotta learn sometime

░▒▓    ~────────────────────────────────────────────────── ────────────────────────────────────────────────── ────────────────────────────────── at 14:44:40  ▓▒░
❯uname -a
Linux Blackhole 6.1.37-1-cachyos-lts #1 SMP PREEMPT_DYNAMIC Sat, 01 Jul 2023 20:36:07 +0000 x86_64 GNU/Linux

░▒▓    ~────────────────────────────────────────────────── ────────────────────────────────────────────────── ────────────────────────────────── at 14:44:43  ▓▒░
❯cat/sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

░▒▓    ~────────────────────────────────────────────────── ────────────────────────────────────────────────── ────────────────────────────────── at 14:44:45  ▓▒░
❯cat/sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

[chuckula]

I think it should be enough to have

clock=tsc

in kernel command line for that.

Good call, and it is enabled and set to default so no recompiles needed now.