Yeah, but until now I’ve not connected any PCIe device to any of the M.2 slots. So I really need to get a good SSD to test with since judging by reports from ODROID forum idle consumption once an NVMe SSD has been slapped into the M.2 slot rises to insane levels with RK’s BSP kernel (should be 4.19 over there, unfortunately users only sometimes post the relevant details).
Could be an indication that there are driver/settings issues with NVMe’s APST (Autonomous Power State Transition) asides ASPM.
If I can manage to arrange some time for this this week-end, I could run some tests with ASPM. I’m having M2->PCIE adapters and an M2 WIFI card, that should be sufficient.
There’s not much point in doing that yet… currently I wait for the GPU to power off between each frame so there’s an overhead of a few milliseconds each frame, so benchmarks will always be a lot worse. I think the blob is at least five times faster for things like glmark at the moment.
In terms of stability, it’s getting a lot better, and just a few minutes ago I fixed a bug with importing shared buffers, so now Weston, Sway and Mutter all work, and even Xwayland with acceleration can work to a degree, which the blob can’t do.
Also recently fixed is support for using the blob for clients when the compositor is using Panfrost, for non-wlroots compositors. This means that you can have (or will have, once I fix a few more issues) all the performance of the blob for Wayland GLES applications, but X11 can still be accelerated!
A few horrendous hacks later, and SuperTuxKart now runs, even with the fancy GLES3 renderer!
Which driver will win the race?
(Answer: They both run badly, because the real bottleneck is Weston’s screen capture. Maybe Sway+wf-recorder would work better, except that the blob doesn’t work with it unless I do some patching.)
It uses kbase, as panfrost.ko doesn’t yet have any code for firmware loading and the like. So the driver will not work with mainline. Running an out-of-tree kbase module on top of mainline might work, but then you have to work out how to fix the power management bits to get the GPU to actually power on.
That’s unfortunate, as I have found kbase to be a very broken kernel driver, at least when misused as I do… stack corruption, NULL dereferences, undefined instruction faults, spurious MMU faults causing CPU lockup, accessing user memory when it shouldn’t, etc. etc. etc. It really needs a rewrite in Rust!
I think at least some of the bugs were added by Rockchip, though.
Actually, it appears that rockchip-drm is causing problems at least as often as kbase… I wonder why my kernel is so unreliable, there shouldn’t be too many changes from the Radxa repository.
For example, here’s a bug message I got without using the GPU at all:
The whole board consumes 1.735W with aspm/policy=powersave, and 2.062W with performance, or 328mW difference.
Without the WiFi card (thus with the realtek NIC only), I’m seeing 1.605W in powersave mode vs 1.760W in performance mode, or a 155mW difference. This means the WiFi card on the M.2 slot was responsible for 173mW extra difference (+130mW in powersave, +302mW in performance mode).
I don’t know if the savings are on the controller side, the device side, or both. I suspect that they’re both though, at least because it could allow to stop the PCIe clock.
我发现一个瑕疵,
系统:
root@rock-5b:/home/rock# uname -a
Linux rock-5b 5.10.66-22-rockchip-g882edb720d40 #rockchip SMP Sat Sep 17 11:11:07 UTC 2022 aarch64 GNU/Linux
root@rock-5b:/home/rock#
使用reboot,系统无法正常的重启需要手动断电
(I’m interested in the default configuration of XFCE with GPU-accelerated Chromium using libmali. “Hang” is talking about a system hang, the webpage is supposed to stop visually updating when persistence reaches 1.0. If it is still working fine at that point, try dragging the slider back down to see if the system hangs then.)
