• Frequently asked questions (FAQ)
  • Why CPU-X won't start?
  • Why some labels are empty?
  • Why CPU usage is high?
  • What is the "daemon"?
  • Why macOS is no more supported?
  • Why RAM timings are not reported?
  • Why Compute Unit (CU) / Workgroup Processor (WGP) / Execution Unit (EU) / Streaming Multiprocessor (SM) are not reported in Graphics tab?
  • Why the package naming is not consistent?
  • Why CPU multipliers are not accurate?
  • Why AppImage version does not use system theme?
  • Why all CPU architectures are not supported?

• First of all, check binary permissions (do a chmod 755 cpu-x if they are wrong).
• If this doesn't solve the problem, run CPU-X with --verbose argument, and read produced output in terminal. If you are confronted to a bug, please open a new issue.

• If you manually build CPU-X, check dependencies.
• CPU-X needs root privileges to run fine. Opening CPU-X as regular user will lead of blank labels. You can start the daemon to avoid to run the UI as root user (on a graphical environment, use the Start daemon button; you can read how to start the daemon without asking password).
• If none of previous cases, your hardware is not recognized by a library.

• You can decrease refresh time with --refresh argument to avoid CPU-X high CPU usage.
• If current tab is Caches or Bench (and a benchmark is running), this is a normal behavior.

Please refer to the following page: Daemon purpose

macOS was supported until v2.2.2, back in 2015. Then, support was dropped since v3.0.0. The reason behind this is because it was difficult to build, and poorly tested. You can find several issues about this topic: https://github.com/TheTumultuousUnicornOfDarkness/CPU-X/issues?q=is%3Aissue+macos

It would have been a feature that would have had its place in CPU-X, but this is not feasible, read #96 for more information.

This information is provided by OpenCL library, but OpenCL is known to crash on Linux (read #318).

The Package label in CPU tab may be provided by the built-in dmidecode if available, otherwise it may be provided by a fallback database.
In case of dmidecode, information is decoded from SMBIOS table, in Processor Information (Type 4) structure, as Socket Designation, so the label may be not consistent across different board vendor.

By default, CPU multipliers are reported by libcpuid and read from CPU MSR (reading MSR requires privileges, so it requires the daemon). It may reports non-boost values.
The scaling driver may use different values as minimum and maximum multipliers. You can use values provided by the kernel by setting the CPUX_FORCE_CPU_FALLBACK=mult environment variable. Please note bus clock value is required to compute multipliers; if bus clock is not reported by CPU-X, you can set it by setting the CPUX_BCLK environment variable (e.g. CPUX_BCLK=100 for a 100MHz bus clock).

That is because the CPU-X daemon read the CPU voltage from CPUs MSRs, refer to #381 for more details.

In REAMDE.md, you can see that only some CPU ISA/architectures are supported.
This is because CPU-X relies on libcpuid, and libcpuid only support a few CPU architectures. The main reason is because libcpuid uses assembly instructions to detect CPU:

• x86: based on the cpuid instruction (e.g. exec_cpuid())
• ARM: based on the mrc and mrs instructions (e.g. cpuid_read_sysreg() (cpuid kernel module) and cpu_exec_mrs() (trapped instruction by kernel)).

In other words, supporting a CPU architecture requires code specific to this architecture, writing such code is complex, and testing requires specific hardware (or emulation).