Detect hardware generically and reduce CPU usage

[jlucaso1]

Verified on an RK3326 handheld (Mali-G31, panfrost, kernel 6.12). I have no RK3588 to test on, so the vendor driver path there is reasoned about rather than measured; please check it.

Closes #2.

Devfreq nodes

The GPU and NPU paths were hardcoded to the RK3588 addresses, so frequency read as unavailable on other SoCs (RK3326 uses ff400000.gpu). Resolved by the driver bound to the device instead: DRM cards first, then the devfreq class, then the device tree compatible string. The original paths stay as a last resort so this cannot regress hardware I could not test.

SoC

get_rk_model looked for RKxxxx in the board model string, which only works when the vendor puts it there. This board reports Game Console R36S, and the Orange Pi 5 Plus in #2 reports Orange Pi 5 Plus. Reads /proc/device-tree/compatible instead, walking it in reverse so the SoC entry is found before the board entry. Also accepts the px and rv prefixes.

GPU utilisation

get_gpu_usage read only /sys/kernel/debug/mali0/dvfs_utilization, which the vendor driver provides and panfrost and panthor do not, so utilisation was permanently unavailable there. Falls back to the per client drm-engine-* counters in DRM fdinfo. The panel also gated on utilisation being present, so it was hidden entirely rather than showing the frequency.

Measured under a fragment bound Vulkan load: 98.7% fragment, 1.1% vertex-tiler, against 0% idle.

Two caveats worth knowing: panfrost and panthor gate these counters behind the device's profiling attribute, and where it is off every engine reads as idle; and the summary reports the busiest engine rather than the sum, because vertex/tiler and fragment run on separate job slots that overlap.

The fdinfo path is skipped entirely when the vendor debugfs is present, so this costs nothing on hardware that already worked.

CPU cost

rktop used about 5% at rest on this device (4x Cortex-A35). Timing each data source put nearly all of it in one place: building the process table cost 32 ms, which at one redraw per second is most of the total.

• /proc/<pid>/stat was read three times per process, once each for the nice value, the CPU core and the state.
• /proc/<pid>/status was read per process for Tgid alone. A pid listed in /proc is its own thread group leader, and sysinfo already records the owning process as a task's parent, so no read is needed. Validated against Tgid for every process on this system: 189 checked, 0 mismatched.
• The sysinfo refresh also collected each process's command line, executable path, working directory, environment and disk usage, none of which is displayed.

This also fixes a latent bug: stat fields were located by splitting the whole line, but the second field is the command name in parentheses and may contain spaces, which shifts every later field and yields another process's nice value and CPU core. Fields are now located relative to the last ).

5.0% before, 4.1% after, while additionally sampling GPU utilisation.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.