[Help] No Hardware Acceleration (EGL/Vulkan) on Weston Wayland - Chromium & Cog Fallback to CPU

Hi everyone,

I am building a Headless Kiosk System (Automotive HUD) using my Radxa board, and I am struggling to get pure Hardware Acceleration (GPU rendering) working for web browsers on Weston (Wayland).

Instead of utilizing the PowerVR BXM-4-64 GPU, both Chromium and Cog browsers are forcefully falling back to Software Rendering (LLVMPipe/CPU), causing my CPU usage to spike over 100% while the GPU utilization sits at around 8-11%.

My Environment:

  • Board: Radxa Cubie A7A

  • OS: radxa-a733_bullseye_cli_r2.output_512.img

  • Display Server: Weston running via drm-backend.so and kiosk-shell.so

  • GPU: PowerVR BXM-4-64

The Goal:
To run a local HTML/JS UI smoothly at 60FPS using EGL hardware rendering on Wayland, completely bypassing the CPU for graphics.

What I Have Tried & The Results:

1. Using Chromium (Ozone Wayland)
I launched Chromium with the following flags to force EGL and Wayland:

chromium --no-sandbox --user-data-dir=/tmp/chrome-root --ozone-platform=wayland --use-gl=egl --ignore-gpu-blocklist --enable-gpu-rasterization --disable-software-rasterizer --disable-dev-shm-usage --disable-features=Vulkan,WebGPU --kiosk "file://..."

Result:
Chromium fails to initialize the GPU and crashes/shows a white screen. If I remove --disable-software-rasterizer, it runs but uses CPU rendering (SwiftShader), pushing CPU usage to 150%+.
Log Snippet:

Warning: eglInitialize failed with EGL_NOT_INITIALIZED
Warning: loader_scanned_icd_add: Driver /usr/lib/aarch64-linux-gnu/libvulkan_lvp.so supports Vulkan 1.1...

2. Using WPE WebKit / Cog
Realizing Chromium might be too heavy, I switched to cog, which is designed for Wayland embedded systems.
I ran:

cog --platform=wl "file://..."

Result:
Immediate crash.
Log Snippet:

** (cog:1305): WARNING **: Could not load: libcogplatform-wl.so (possible cause: Resource temporarily unavailable).
** (cog:1305): CRITICAL **: WebKitWebViewBackend* webkit_web_view_backend_new(wpe_view_backend*, GDestroyNotify, gpointer): assertion 'backend' failed
Segmentation fault

My Observation:
Checking cat /sys/kernel/debug/pvr/status shows the GPU is recognized and idling. However, it seems the OS has conflicting drivers (like libvulkan_lvp.so / software rasterizer) that intercept the EGL/Vulkan calls before they reach the PowerVR driver, causing the web engines to panic or fallback.

My Questions:

  1. Is there a specific PowerVR driver package or LD_LIBRARY_PATH I need to export to force Weston and Chromium/Cog to use the hardware GPU?

  2. Has anyone successfully achieved 60fps GPU-accelerated HTML rendering on this board under Weston? If so, what browser/flags did you use?

  3. Should I move to a different OS image (like Armbian or Ubuntu) that has better out-of-the-box PowerVR EGL support?

Any advice, patches, or pointers would be highly appreciated. Thank you in advance!

The GPU user-space driver provided by Allwinner does not support running under Wayland

​​Hi ChenJaly,

​Thank you for the clarification. Since Wayland support is not available for this GPU driver on the current CLI image, I will stop pursuing the Weston/Wayland route.

​My goal is to run a simple, GPU-accelerated UI kiosk. Since Weston is not viable, what is the officially supported display server for this board to utilize the Imagination BXM-4-64 MC1 GPU?

​Specifically:

  1. ​Does Radxa provide a specific OS image or driver package that supports Xorg/X11 with full GLES/EGL acceleration for this GPU?

  2. ​Or is there an alternative platform/display backend (e.g., DRM/KMS) that is officially tested and supported for this specific SoC?

​I am looking for the path of least resistance to get 60fps UI rendering on this board. Any pointers to the correct display stack configuration would be greatly appreciated.

​Thanks!

I highly regret purchasing the Radxa Cubie A7A. The main hardware features—including the GPU, NPU, VPU, and the RISC-V co-processor—are completely unusable due to poor software support. It feels like buying an unfinished product. Furthermore, the development team has offered no solutions and remains completely silent on these issues.

But it’s Allwinner’s fault. The company offers poor, old SDKs. However, hopefully they should release Debian Trixie properly soon…

Radxa: Great on paper, total trash in reality.

Again, please don’t blame Radxa, they work with what they are given by the manufacturer