Before I go down the stupid rabbit hole, has anybody tried to install the genuine Valhall drivers and userspace libraries from ARM on RK3588?
I know they’re not open source (although the ARM website says they’re GPL2. So… maybe?) and I’ve read they’re less stable than the Panthor driver, but I’m curious to see if they perform better.
I’m not curious enough to brick my laptop or fubar the Debian install though. Hence my question.
Closed vendor drivers usually require a vendor kernel and you need to work around not using mesa, so this will be quite a lot of pain
GPL2 can’t be true if they’re binary, where did you see that?
Meanwhile the open source mesa/panvk is already at Vulkan 1.3…
ARM is actively supporting the panthor/panvk driver, see Release the panthor! (“they [ARM] also took an active part in the review process and two developers are currently flagged as co-maintainers of the kernel driver”)
See also the new Tyr kernel driver: LKML: Daniel Almeida: [PATCH] Introduce Tyr (“It is a port of Panthor and therefore exposes Panthor’s uAPI and name to userspace, and the product of a joint effort between Collabora, ARM and Google engineers”)
If you want more performance, you can set your GPU frequency to 1GHz:
# Works only as root user
echo userspace > /sys/class/devfreq/fb000000.gpu/governor
echo 1000000000 > /sys/class/devfreq/fb000000.gpu/min_freq
The only limitations I currently see on panthor/panvk:
No geometry shaders (these are mostly deprecated and emulated for modern/mobile GPUs, like Apple Silicon, but panvk doesn’t have this emulation yet). Blender can work without them now but needs them to emulate barycentrics which panvk also doesn’t support.
No multiViewport, the other requirement for Blender, but this might come at some point.
Userspace has/had some unnecessary color format conversions until @mojyack figured this out (and we’re waiting for the mesa patch to trickle down back into Debian), which greatly boosts performance of i.e. Firefox
Is there some application that you need but can’t use because of GPU driver limitations at the moment?
This page, but I must have read through it too quickly. I guess the core of it in their SDK is still proprietary and they just GPLed the kernel boilerplate around it.
Blender, but that’s mainly because Blender is too demanding. I suppose it would work if I bothered to compile an old version.
Quake II has bad rendering artifacts in OpenGL 1.4 and OpenGL ES 3 (see this capture) and it renders dog slow in Vulkan. I was hoping the binary driver would render correctly in OpenGL or fast enough to be playable in Vulkan.
I half-hoped the genuine driver would offer drv acceleration. But in retrospect after looking at the Mali’s specs, I don’t think drv is even on the menu.
And just plain curiosity with regard to the state of the open source driver vs the closed source one.
Oh that’s neat! I’ll try that for sure.
But before I do: should I be worried about melting my PLA spacer? It’s already close to glass transition temperature near the heatsink when I encode a long video in CPU
Quake 2 is ancient and should be peanuts for this GPU. I’ve played Q3A on much weaker systems (i.MX8MQ), so it must be a software issue. Which engine/build are you using exactly?
Yamagi, which is not so ancient really. being that it’s been freshened up. But yeah, maybe I should try another one.
By the way, I didn’t quite pick up on your comment initially, but re-reading it, I’m intrigued:
Are you saying you do run Blender on the Reform? Did you build it yourself or did you find an arm64 package somewhere that’s compatible with the OpenGL version sported by Mali?
I tried installing the one from Debian 13 and it complains that it wants OpenGL 4.3, which is just not happening. And software rendering is horrendous of course. So I looked far and wide for an old arm64 build and I couldn’t find any. And I’d really rather not rebuild the whole thing myself. So if you have found something, I’m all ears!
Building it yourself is not so bad. We did that back in the day before version 2.79b which only required OpenGLES 3.2. Starting with 2.80 blender required OpenGL 3.2+.
The problem was forward-porting old blender onto newer library versions. I gave up when openvdb failed to find tbb/task_scheduler_init.h. This is because tbb dropped the tbb/task_scheduler_init.h header. Fixing this has to happen in openvdb but the proper fix will be to add support for onetbb to openvdb because tbb developers changed the name to onetbb. Here is the last diff we used: blender/blender.debdiff · 242ef573b564990eeda5786e9f1f56c394c5eeea · Reform / reform-debian-packages · GitLab It’s nearly 2k lines long. I put a lot of work in keeping old blender working but ultimately it’s a dead end.
Well, I’m lazy enough and I have a main computer powerful enough with Blender already on it that I’m not sure I’m interested in doing that on the Reform. Curiosity almost makes me want to do it, but it hasn’t pushed me over the edge quite yet I’d much prefer a pre-built package.
Also…
Doesn’t the current Panthor driver only support OpenGL ES 3.1?
Okay, but it was worth a shot. Note that minute wrote this patch against blender commit 1448b70625510f0a1a5408a8e8dbecc598fb890b while Debian unstable has blender 4.3.2. The commit minute used is not in any tagged release (yet) and it’s 5358 commits ahead of v4.3.2.
I have no doubt about that. I’ve been in this business long enough to know an endless pit of problems when I see one. That’s why I haven’t done anything about it so far.