Closed birdie-github closed 2 months ago
you can't setcap a shared library, which mangohud is. At best you could wrap turbostat in the code and make the user manually apply setcap to it. Either way, what problem is being solved here? in general there shouldn't be any issue getting cpu wattage for intel or amd
you can't setcap a shared library, which mangohud is.
You're absolutely right.
you can't setcap a shared library, which mangohud is.
Probably that's the way.
Either way, what problem is being solved here? in general there shouldn't be any issue getting cpu wattage for intel or amd
But it's shown as 0W here for the Ryzen 7 5800X. AFAIK you rely on the unofficial zenpower3 driver which hasn't been maintained in years and not a single Linux distro comes with it by default.
Using a kernel module like zenpower3 is a better solution than wrapping another application and depending on it
OK, you don't like the idea of calling turbostat
.
What about RAPL?
https://web.eece.maine.edu/~vweaver/projects/rapl/ https://github.com/deater/uarch-configure/blob/master/rapl-read/rapl-read.c
Only requires read access to /dev/cpu/N/msr
The vast majority of users will never install it for various reasons
How is it any better that the user would have to install turbostat instead that they also need to set special permissions for?
zenpower3 hasn't been maintained for years and may break any minute
Does it need maintenance? Do you know that the developer has abandoned it or something?
Another option is https://github.com/BoukeHaarsma23/zenergy
Given proper MSR access, no root or anything is required to read RAPL data.
That's as easy as:
/etc/udev/rules.d/99-local-msr.rules
SUBSYSTEM=="msr", MODE="0640", GROUP="wheel"
Could be adjusted for your use case.
Out of tree kernel modules are unavailable to 99.9% of Linux users.
The problem with making msr accessible by the user is that it doesn't only let mangohud access it
The problem with making msr accessible by the user is that it doesn't only let mangohud access it
Using sudo is limited exposure, intentionally allowing a specific application access. This is giving all applications access. msr information can be used for exploits, as such the question is if it's worth exposing users to it than making a proper solution.
We already do some of this by exposing intel rapl, but question is if we should double down on it
msr information can be used for exploits, as such the question is if it's worth exposing users to it than making a proper solution.
You're right.
Looks like Linux users are screwed and there's no solution. I'm closing this ticket because I have no idea how to solve this problem. I've exhausted all my options and ideas.
Seems like the MangoHud team is having the same issues I am having now.
None of the tools out there right now that support Zen Temperature Readings except for lm_sensors properly support Zen 4 (and probably Zen 5). zenpower3 was called out here, but does not have Zen 4+ support. The same can be said for every other Zen-integration for system monitoring except for cpu-speed which uses lm_sensors under the hood.
Came here to see if there was any progress with MangoHud and integrating per-CPU Clocks or even per-CCD Temps / Power but it looks like everyone is limited by the same issue - nobody seems to know how to effectively get the data out of the Zen Power Tables. I made an attempt but without knowing how to map the Power Tables no progress can really be made.
@Kraust
turbostat
works just fine even without root access and I've been using it for years. What's more it supports pretty much all the CPUs that can report power consumption. This method doesn't need lm-sensors support.
It's just unhandy to implement since you need to system()
an external application.
I'm not a good C programmer, so I just walked away. I guess a patch to implement this feature will be fewer than 100 lines of code.
You create a new thread, run every second
turbostat --quiet --num_iterations 1 --interval 1 --show PkgWatt --Summary | tail -1 | tr -d '\n'
in it and assign the result of this function to a variable. That's it.
In a perfect world you will not use tail
and tr
and instead parse the output using C. It's gonna be faster and more efficient.
And of course you need to make sure that tr
1) doesn't hang up and 2) exits successfully. You don't want to end up running thousands of turbostat
processes.
@birdie-github Have you actually tried this on Zen 4?
[nix-shell:~]$ turbostat --quiet --num_iterations 1 --interval 1 --show PkgWatt --Summary
The fields you think that are included are not included. I think that's the thing you're missing in this chain and why you likely closed the issue. This is a software development issue and nobody is willing to maintain because it requires the end users to figure out mappings which are not immediately obvious (e.g. I struggled with it for a few days and made minimal progress.
[nix-shell:~]$ turbostat --quiet --num_iterations 1 --interval 1 --no-perf
Die Core CPU TSC_MHz IRQ POLL C1 C2 C3 POLL% C1% C2% C3%
- - - 4198 5858 25 108 1046 4221 0.00 0.09 1.92 96.90
0 0 0 4200 245 0 3 39 193 0.00 0.09 1.91 97.40
0 0 16 4200 14 0 0 4 10 0.00 0.00 0.31 99.67
0 1 1 4200 72 0 0 9 55 0.00 0.00 0.24 99.54
0 1 17 4200 12 0 0 0 11 0.00 0.00 0.00 99.96
0 2 2 4200 408 0 9 86 305 0.00 0.25 4.33 94.21
0 2 18 4200 5 0 0 1 4 0.00 0.00 0.01 99.98
0 3 3 4200 114 0 0 4 110 0.00 0.00 0.13 99.59
0 3 19 4200 4 0 0 1 3 0.00 0.00 0.02 99.97
0 4 4 4200 236 0 10 56 134 0.00 0.04 3.20 94.52
0 4 20 4200 53 0 13 7 25 0.00 0.79 0.40 98.73
0 5 5 4200 329 0 2 59 251 0.00 0.02 2.34 95.56
0 5 21 4200 20 0 0 0 20 0.00 0.00 0.00 99.94
0 6 6 4200 78 0 0 0 76 0.00 0.00 0.00 99.52
0 6 22 4200 2 0 0 0 2 0.00 0.00 0.00 99.99
0 7 7 4200 3 0 0 0 3 0.00 0.00 0.00 99.98
0 7 23 4200 1 0 0 0 1 0.00 0.00 0.00 99.99
1 8 8 4200 224 0 2 9 199 0.00 0.06 0.25 99.10
1 8 24 4200 91 0 0 0 79 0.00 0.00 0.00 99.37
1 9 9 4200 754 10 9 260 327 0.03 0.02 17.00 72.56
1 9 25 4200 348 2 3 9 252 0.01 0.04 0.36 92.90
1 10 10 4200 90 0 0 13 72 0.00 0.00 1.20 98.51
1 10 26 4200 130 0 0 7 118 0.00 0.00 0.61 99.03
1 11 11 4200 729 13 14 375 302 0.05 0.02 24.02 74.69
1 11 27 4200 270 0 4 13 248 0.00 0.10 0.83 98.26
1 12 12 4200 127 0 0 14 97 0.00 0.00 1.08 97.78
1 12 28 4200 293 0 28 13 247 0.00 1.29 0.33 97.40
1 13 13 4200 226 0 0 3 212 0.00 0.00 0.11 98.97
1 13 29 4200 397 0 9 40 339 0.00 0.23 1.81 97.37
1 14 14 4200 100 0 0 3 90 0.00 0.00 0.09 99.59
1 14 30 4200 75 0 0 0 66 0.00 0.00 0.00 99.56
1 15 15 4200 241 0 1 21 214 0.00 0.00 0.82 98.74
1 15 31 4200 167 0 1 0 156 0.00 0.08 0.00 99.60
FYI. What is actually output on Zen 4 using Kernel 6.10 and a 7950X3D. Also that data is wrong because there are actual tools out there that properly report CPU frequency because that's actually exported by sysfs.
I've not tried it on Zen 4, I've been using it on Zen 4 from day one.
RAPL is universal.
This is a software development issue and nobody is willing to maintain because it requires the end users to figure out mappings which are not immediately obvious (e.g. I struggled with it for a few days and made minimal progress.
RAPL works under Windows as well and it's here to stay. I've no idea what you're insinuating about.
Something about your system is terribly wrong, you may need to update your BIOS or something.
Here's my output for the Zen 4 based Ryzen 7 7840HS:
turbostat --quiet --num_iterations 1 --interval 1 --no-perf
Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ POLL C1 C2 C3 POLL% C1% C2% C3% CorWatt PkgWatt
- - 101 3.75 2689 3793 6121 3 193 1328 4032 0.00 0.26 4.33 91.99 5.04 5.61
0 0 84 3.95 2137 3793 749 0 27 97 563 0.00 1.20 4.57 90.97 0.54 5.61
0 1 7 0.33 2174 3793 59 0 0 0 58 0.00 0.00 0.00 99.73
1 2 261 8.46 3082 3793 794 1 23 345 358 0.00 0.17 17.35 74.63 1.23
1 3 96 3.52 2739 3793 457 0 45 37 373 0.00 1.42 1.56 93.94
2 4 123 5.04 2441 3793 576 0 6 146 371 0.00 0.08 7.76 87.63 0.45
2 5 4 0.21 2095 3793 45 0 1 0 38 0.00 0.03 0.00 99.79
3 6 79 3.49 2273 3793 515 1 31 98 344 0.00 0.40 5.32 91.22 0.29
3 7 4 0.09 4307 3793 15 0 0 5 9 0.00 0.00 0.39 99.53
4 8 80 3.37 2372 3793 475 0 8 85 346 0.00 0.15 4.72 92.15 0.55
4 9 50 2.16 2312 3793 268 0 0 29 217 0.00 0.00 1.59 96.53
5 10 500 16.58 3015 3793 847 1 12 204 476 0.00 0.14 11.06 72.91 0.82
5 11 19 0.82 2315 3793 67 0 2 19 37 0.00 0.19 1.26 97.78
6 12 157 5.56 2829 3793 580 0 7 125 390 0.00 0.11 6.22 88.61 0.76
6 13 20 0.91 2150 3793 103 0 0 0 94 0.00 0.00 0.00 99.22
7 14 104 4.55 2283 3793 515 0 31 138 312 0.00 0.27 7.56 88.05 0.41
7 15 23 0.90 2558 3793 56 0 0 0 46 0.00 0.00 0.00 99.15
All exactly the same as in Windows 10/11 using HWiNFO64.
I've no idea why your output is missing CorWatt PkgWatt
columns altogether.
A Ryzen 9 7950X's output (taken from https://www.realworldtech.com/forum/?threadid=210843&curpostid=210872 ):
turbostat version 21.05.04 - Len Brown
CPUID(0): AuthenticAMD 0x10 CPUID levels
CPUID(1): family:model:stepping 0x19:61:2 (25:97:2) microcode 0x0
CPUID(0x80000000): max_extended_levels: 0x80000028
CPUID(1): SSE3 MONITOR - - - TSC MSR - HT -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
RAPL: 234 sec. Joule Counter Range, at 280 Watts
/dev/cpu_dma_latency: 2000000000 usec (default)
current_driver: acpi_idle
current_governor: menu
current_governor_ro: menu
cpu1: POLL: CPUIDLE CORE POLL IDLE
cpu1: C1: ACPI FFH MWAIT 0x0
cpu1: C2: ACPI IOPORT 0x414
cpu1: C3: ACPI IOPORT 0x415
cpu1: cpufreq driver: acpi-cpufreq
cpu1: cpufreq governor: schedutil
cpufreq boost: 1
cpu0: MSR_RAPL_PWR_UNIT: 0x000a1000 (1.000000 Watts, 0.000015 Joules, 0.000977 sec.)
Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IPC IRQ POLL C1 C2 C3 POLL% C1% C2% C3% CorWatt PkgWatt
- - 4531 99.65 4547 4500 1.02 52975 3 186 59 229 0.00 0.01 0.03 0.31 100.23 152.59
0 0 4590 99.88 4595 4500 0.85 1539 0 1 1 1 0.00 0.00 0.04 0.08 6.33 152.57
0 16 4576 99.59 4595 4500 1.07 1440 0 0 2 9 0.00 0.00 0.00 0.41
1 1 4535 98.69 4596 4500 1.07 2328 0 4 4 26 0.00 0.01 0.00 1.31 6.69
1 17 4552 99.06 4596 4500 1.02 2198 0 1 5 26 0.00 0.00 0.13 0.82
2 2 4594 99.99 4595 4500 1.04 1379 0 0 0 1 0.00 0.00 0.00 0.01 6.86
2 18 4585 99.79 4595 4500 1.15 1420 1 22 3 4 0.00 0.02 0.03 0.15
3 3 4594 99.97 4595 4500 1.05 1503 0 1 1 1 0.00 0.00 0.00 0.02 7.00
3 19 4589 99.87 4595 4500 1.03 1451 0 1 2 3 0.00 0.00 0.01 0.12
4 4 4585 99.78 4595 4500 1.03 1413 0 3 0 4 0.00 0.00 0.00 0.22 6.88
4 20 4594 99.98 4595 4500 1.01 1286 0 9 1 1 0.00 0.02 0.00 0.00
5 5 4594 99.98 4595 4500 1.09 1579 0 21 0 0 0.00 0.02 0.00 0.00 6.94
5 21 4593 99.95 4595 4500 1.11 1532 1 0 2 1 0.00 0.00 0.01 0.04
6 6 4586 99.80 4595 4500 0.97 1398 0 0 3 3 0.00 0.00 0.13 0.08 6.59
6 22 4595 100.00 4595 4500 0.99 1274 0 1 0 0 0.00 0.00 0.00 0.00
7 7 4568 99.40 4595 4500 0.94 2207 0 52 3 14 0.00 0.06 0.08 0.46 6.45
7 23 4575 99.58 4595 4500 1.04 2442 0 14 4 9 0.00 0.02 0.07 0.33
8 8 4499 100.00 4499 4500 1.00 1402 0 0 0 0 0.00 0.00 0.00 0.00 5.74
8 24 4474 99.45 4499 4500 0.98 1424 0 1 1 13 0.00 0.00 0.04 0.51
9 9 4490 99.80 4499 4500 0.80 2094 0 5 5 7 0.00 0.01 0.10 0.10 5.51
9 25 4499 100.00 4499 4500 1.04 1305 0 0 0 0 0.00 0.00 0.00 0.00
10 10 4491 99.82 4499 4500 1.04 1285 0 4 1 3 0.00 0.00 0.01 0.16 6.07
10 26 4496 99.94 4499 4500 1.00 3922 0 8 1 1 0.00 0.02 0.00 0.04
11 11 4497 99.95 4499 4500 0.94 1560 0 0 0 1 0.00 0.00 0.00 0.05 5.78
11 27 4496 99.94 4499 4500 0.96 1436 0 0 2 4 0.00 0.00 0.03 0.03
12 12 4458 99.09 4499 4500 0.98 1754 0 1 3 15 0.00 0.00 0.07 0.85 5.83
12 28 4464 99.22 4499 4500 0.97 1393 0 10 1 14 0.00 0.02 0.01 0.76
13 13 4399 97.77 4499 4500 1.14 1591 0 5 5 44 0.00 0.00 0.10 2.14 5.90
13 29 4484 99.67 4499 4500 1.25 1450 0 11 2 6 0.00 0.01 0.05 0.27
14 14 4499 100.00 4499 4500 1.10 1353 0 0 0 0 0.00 0.00 0.00 0.00 5.84
14 30 4467 99.29 4499 4500 0.88 1359 0 0 0 9 0.00 0.00 0.00 0.71
15 15 4494 99.89 4499 4500 1.02 1666 1 7 5 0 0.00 0.01 0.10 0.00 5.82
15 31 4482 99.63 4499 4500 1.03 1592 0 4 2 9 0.00 0.01 0.07 0.29
Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IPC IRQ POLL C1 C2 C3 POLL% C1% C2% C3% CorWatt PkgWatt
- - 3 0.10 3081 4500 0.57 2126 1 54 79 1917 0.00 0.03 0.07 99.82 0.09 23.95
0 0 6 0.18 3065 4500 1.66 62 0 29 5 52 0.00 0.07 0.02 99.73 0.01 23.96
0 16 4 0.10 3542 4500 1.01 48 0 0 1 45 0.00 0.00 0.01 99.90
1 1 3 0.11 2982 4500 1.09 47 0 0 4 39 0.00 0.00 0.14 99.76 0.00
1 17 1 0.02 2909 4500 0.43 22 0 0 1 19 0.00 0.00 0.00 99.98
2 2 4 0.12 2953 4500 0.21 161 0 0 1 157 0.00 0.00 0.00 99.90 0.01
2 18 2 0.05 2949 4500 0.19 62 0 0 1 60 0.00 0.00 0.00 99.96
3 3 2 0.07 2950 4500 0.17 45 0 0 2 41 0.00 0.00 0.02 99.92 0.00
3 19 2 0.08 2964 4500 0.21 106 0 13 10 87 0.00 0.57 0.65 98.72
4 4 6 0.20 3040 4500 1.89 51 0 9 0 41 0.00 0.21 0.00 99.60 0.01
4 20 1 0.03 3304 4500 0.18 54 0 0 0 51 0.00 0.00 0.00 99.98
5 5 1 0.02 2901 4500 0.25 29 0 0 3 25 0.00 0.00 0.03 99.96 0.00
5 21 1 0.02 2911 4500 0.22 28 0 0 0 27 0.00 0.00 0.00 99.99
6 6 16 0.48 3355 4500 0.39 170 0 0 13 145 0.00 0.00 0.13 99.41 0.01
6 22 1 0.03 3243 4500 0.35 25 0 0 0 23 0.00 0.00 0.00 99.98
7 7 2 0.07 3167 4500 0.65 57 1 0 0 51 0.00 0.00 0.00 99.94 0.00
7 23 4 0.12 3050 4500 0.82 50 0 0 0 31 0.00 0.00 0.00 99.89
8 8 3 0.11 2952 4500 0.28 59 0 0 0 57 0.00 0.00 0.00 99.90 0.00
8 24 1 0.05 2922 4500 0.47 49 0 0 4 44 0.00 0.00 0.08 99.89
9 9 9 0.31 2975 4500 0.24 211 0 0 5 190 0.00 0.00 0.05 99.68 0.02
9 25 7 0.25 2964 4500 0.12 112 0 2 19 88 0.00 0.01 0.98 98.79
10 10 1 0.04 2908 4500 0.23 54 0 1 1 51 0.00 0.01 0.02 99.95 0.00
10 26 1 0.05 2943 4500 0.28 38 0 0 0 36 0.00 0.00 0.00 99.97
11 11 4 0.14 2969 4500 0.15 146 0 0 3 139 0.00 0.00 0.03 99.86 0.01
11 27 2 0.06 2943 4500 0.18 67 0 0 1 65 0.00 0.00 0.01 99.95
12 12 1 0.02 2880 4500 0.35 37 0 0 1 31 0.00 0.00 0.00 99.99 0.00
12 28 2 0.05 2939 4500 0.66 33 0 0 0 32 0.00 0.00 0.00 99.96
13 13 2 0.05 2928 4500 0.79 53 0 0 0 51 0.00 0.00 0.00 99.96 0.00
13 29 1 0.05 2940 4500 0.22 73 0 0 2 70 0.00 0.00 0.02 99.94
14 14 2 0.05 3220 4500 0.42 50 0 0 0 49 0.00 0.00 0.00 99.96 0.01
14 30 2 0.06 3257 4500 0.23 61 0 0 2 58 0.00 0.00 0.06 99.89
15 15 1 0.02 3386 4500 0.18 27 0 0 0 26 0.00 0.00 0.00 99.99 0.00
15 31 1 0.04 3174 4500 1.17 39 0 0 0 36 0.00 0.00 0.00 99.96
I've been using Linux for almost 30 years. Never been known for BS'ing people.
Anyways, I couldn't care less about brain damaged ideas shared between and perpetrated by Linux developers.
You have secure boot on? No write access to MSR for you. Totally possible in Windows.
You wanna read CPU power consumption via lm-sensors? Well, let's remove the feature from the kernel.
You wanna read CPU power consumption via turbostat? Well, go throw several circles of hell, enabling read access to MSR and setting scarily looking flags on turbostat
.
This is not a desktop OS, this is an abomination.
Ended up figuring it out. This tool does everything but do temperature reading which is pretty nice, thanks.
@flightlessmango
Maybe you could consider implementing a turbostat solution. It works and it's there to stay for the foreseeable future.
Maybe you could consider implementing a turbostat solution. It works and it's there to stay for the foreseeable future.
Like discussed previously in this thread, I don't like wrapping and depending on a application. We used to do this with intel_gpu_top and it caused more issues than it solved
@flightlessmango
Are you saying you won't even accept a merge request if someone implements the feature?
Under Linux it's absolutely possible to read CPU watt usage without (lm-) sensors.
It involves calling
turbostat
(which works for both Intel and AMD CPUs, I'm not sure about Qualcomm but they are still extremely rare), e.g.Or you could do whatever turbostat is doing yourself. There's an API for that.
msr
kernel module must be loaded.setcap
requires this to work under a non-privileged user:Prolly
mangohud
will require it too.This solution is universal, supported for all AMD/Intel CPUs released in the past decade and will be supported going forward.