Does exist a VAAPI driver to the radxa zero 3W or in general for ARM64 or a valid / partial alternative,even bugged,that can be fixed ?

ZioMario

ZioMario

Hello to every FreeBSD brother all around.

I have implemented a full IOMMU v2 integration with DRM / RockChip / Panfrost code on the Radxa board Zero 3W. It has been a crazy 3 full days of night and day work. It's not only about to patch some file here and there. I have fixed a large numbers of bugs because in Linux it works differently. Now,this is the final situation :

1) Xorg with the glamour driver + xfce4 uses the 200% of the radxa cpus. Something is not working properly maybe I should disable the xfwm4 compositor :

Code: 
xfconf-query -c xfwm4 -p /general/use_compositing -s false

  1. xfwm4 compositor — it uses XDamage + XComposite for rendering. On FreeBSD with glamor it could not match with the vblank timing.
  2. vsync not configured — xfwm4 ha an option vblank_mode that on Linux uses glx or xpresent, but on FreeBSD may fail silently or come back to a loop busy-wait.

2) I have switched from xfce4 to lxde and cpu takes much less power from cpus

Despite point 1 and 2,Firefox does not seem to be the best choice for surfing (and compiling from ports a fresh version of Chromium is a serious challenge and I'm not sure it will work as I wish)

When I go to YouTube for watching some videos I see the page has large black checks, sometimes magenta, and often it shows missing elements. Everything gets fixed after a while, but then the problems come back. I don't know what the problem is, perhaps some incompatibility between the xfce4 compositing and the panfrost driver ? Maybe there aren't bugs,but it's only Firefox that asks to the radxa board too many resources that it can't offer ?

Anyway do you know if does exists or if it's possible to port the VAAPI driver to the radxa zero 3W or in general to ARM64 for FreeBSD ? This is what I get for the moment :

Code: 
# vainfo
Trying display: wayland
Trying display: x11
libva info: VA-API version 1.23.0
libva info: Trying to open /usr/local/lib/dri/panfrost_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Does exists a partial port of RKVDEC / RKVENC for FreeBSD already ? v4l2 on FreeBSD already supports something for RK35xx ?
 
Tip try first MATE, if i remember good only linux there is an application installable to tune the compositor to very different settings.
Like none,picom ,xrandr, glx , and combinations and variations. This is nice to try out which work or crash the GPU.
 
Alain De Vos said:
Tip try first MATE, if i remember good only linux there is an application installable to tune the compositor to very different settings.
Like none,picom ,xrandr, glx , and combinations and variations. This is nice to try out which work or crash the GPU.
Click to expand...

At the moment my problem is not about the fact that the Mali GPU of the Radxa Zero 3W crashes. Everything works here. DRM,Panfrost,IOVA + IOMMU flow. Problem is that Firefox can't use the hardware GPU acceleration because FreeBSD misses a VAAPI driver for ARM64 and / or if it does exist,it does not work great with panfrost. Dunno. So it can't use the GPU power,but only the CPU. So it is not so fast to render pages and it creates glitches. How can Mate desktop help me ? Dunno. Maybe Wayland can. But I suspect it is not yet mature for arm64. Can Chromium be a valid alternative ? Maybe. But Chromium is not between the packages for FreeBSD for arm64. It can be compiled from ports,but here the challenge is that the compilation will be very slow on my machines. To do it on a slow arm64 board can take ages. On my PC I should use QEMU without the hypervisor acceleration. There is no acceleration for QEMU if it emulates arm code on X64. Without it can take a lot of time.
 
Porting these components from Linux to FreeBSD maybe is the solution : https://github.com/HermanChen/mpp :

Rockchip MPP (Media Process Platfrom) module directory description:

MPP : Media Process Platform
MPI : Media Process Interface
HAL : Hardware Abstract Layer
OSAL : Operation System Abstract Layer
 
Tip when compiling chromium use poudriere, i start poudriere with ,
cat /root/Scripts/poudriere_nice
nice -n 31 idprio 31 ./poudriere_run
note , nice & idprio , so it only runs when cpu is in sleep state. idprio makes the bus data transfer is not overloaded.
 
Alain De Vos said:
Tip when compiling chromium use poudriere, i start poudriere with ,
cat /root/Scripts/poudriere_nice
nice -n 31 idprio 31 ./poudriere_run
note , nice & idprio , so it only runs when cpu is in sleep state. idprio makes the bus data transfer is not overloaded.
Click to expand...

How long time do you need to compile Chromium from ports with Poudriere ?
 
Maybe 12 hours on a 12-Core CPU & 16GB memory. But there good tuning of poudriere comes into place.
- If CPU 100% , desktop blocks, mouse does not move.
- Starting to many parallel build and you eat up all memory & swap , sometimes resulting in crash.
So only : Trial & Error.
 
With poudriere + QEMU (FreeBSD or Linux host) everything runs inside an emulated arm64 jail. Every arm64 binary—including Chromium's thousands of compilation steps—runs through QEMU. It's slow by definition.What would really cut down on time: native cross-compilation. Chromium uses GN + Ninja and natively supports cross-compiling. In this case, the compiler toolchain (clang) runs as a native x86_64 binary and produces arm64 output, without any emulation. The speed difference can be 5-10x.
 

Can you give again the webpage with all the patches needed to fix Firefox,Wayland and MESA libs ? It was a set of 4 patches.If I remember correctly those patches was created by Ruslan...


github.com

Failed to open device: '/dev/dri/card0': No such file or directory · Issue #25 · evadot/drm-subtree

I'm using an RK3399 base board called the RockPi 4C. Freebsd 14.0-CURRENT is installed and your drm-subtree patches applied as instructed in the README. I've managed to build everything, install th...
github.com github.com

* Yes,I have applied it,but despite this,Firefox does not work good on the Radxa Zero. It produces a lot of glitches.
 
It seems that the libdrm patch is not enough. Firefox also needs the hantro driver to use panfrost ?

Istantanea_2026-03-27_06-04-54.jpg


Ruslan Bukin's drm_hack_panfrost.patch addresses 2D/3D rendering with the Mali GPU—it ensures Mesa/Panfrost is recognized as a valid platform on FreeBSD instead of falling back to llvmpipe. This speeds up Firefox UI rendering (scrolling, compositing, WebGL), but has nothing to do with video decoding. These are two completely separate issues:

Issue 1 — GPU Rendering (Mesa/Panfrost):Firefox uses the Mali GPU to draw the interface. Fixed by the drm_hack_panfrost.patch on libdrm.

Issue 2 — Hardware Video Decoding (VPU): Firefox uses the VPU to decode H.264/VP9 on YouTube requires VA-API → VPU driver → RKVDEC/Hantro hardware. Not fixed by the libdrm patch — they're two completely different chains.

Both are needed. The libdrm patch fixes rendering, while Hantro fixes video decoding.
 
You must log in or register to reply here.
Back
Top