No GPU acceleration on Radxa Zero 3W with Debian Bullseye

I recently bought a Radxa Zero 3W and installed the latest Debian Bullseye image (b6 release).

Unfortunately, the graphical display is laggy and does not seem to be GPU accelerated. When I run “glxgears”, I get the following error message:

libGL error: failed to create DRI screen
libGL error: failed to load driver: rockchip

According to “glxinfo” the display is not hardware accelerated.

Does anyone know how to enable hardware acceleration?

Response from from the Radxa development team:

ZERO 3W’s SoC uses Mali-G52 GPU [1] which does not list OpenGL as one of its supported API. They support OpenGL ES, but this is a separate API, and the program built for one cannot use the other. As a result, Arm’s official GPU driver does not support OpenGL either, which is the GPU driver supported in Rockchip SDK. This is unfortunate since most of the desktop applications are built with OpenGL in mind, so when running in our system, they have to fallback to software rendering.

To verify OpenGL ES is working on your system though, you can install
glmark2-es2-x11 to verify.

The popular open source GPU driver panfrost supports OpenGL. But this is provided with internal API translation, as the underlying hardware does support all OpenGL’s features, which is why its OpenGL implementation is listed as non-conformant [2]. Although for the majority of the desktop applications, it was good enough.

We tried to support Panfrost in our system without Rockchip’s blessing, but currently, Debian 11 ships Mesa 20.3.5 [3], while the required version for RK356X is at least 21.2.0 [4].

Since Rockchip hasn’t released their Debian 12 SDK for RK356X, it will take a while before we try this route again.


I have installed and run glmark2-es2-x11 as suggested and can confirm that OpenGL ES acceleration is present. Unfortunately, that does not help me a lot.

I was working with a Radxa Zero 2 using the Ubuntu image before. The Ubuntu image came with the panfrost driver installed and had at least basic hardware OpenGL acceleration.

Somehow I expected that the same applies for the Radxa Zero 3W, but learned from the dev team that the Zero 3 is actually not a successor of the Zero 2, but rather the Zero.

Following a hint from the dev team I gave the gl4es wrapper a try. Instructions for installation can be found here.

The wrapper seems to work with the Python Kivy toolkit, which uses SDL2 as graphical backend. My application is not lightning fast, but much speedier than before and probably fast enough for my purposes.

These are the log messages I get to see now when starting my Kivy application after the installation of gl2es:

LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Jan 19 2024 16:01:03
LIBGL: Using GLES 2.0 backend
LIBGL: loaded:
LIBGL: loaded:
LIBGL: Using GLES 2.0 backend
arm_release_ver of this libmali is 'g2p0-01eac0', rk_so_ver is '4'.
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax  detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Subtract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer  detected
LIBGL: Extension GL_OES_element_index_uint  detected and used
LIBGL: Extension GL_OES_packed_depth_stencil  detected and used
LIBGL: Extension GL_OES_depth24  detected and used
LIBGL: Extension GL_OES_rgb8_rgba8  detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888  detected and used
LIBGL: Extension GL_OES_depth_texture  detected and used
LIBGL: Extension GL_OES_texture_stencil8  detected and used
LIBGL: Extension GL_EXT_texture_rg  detected and used
LIBGL: Extension GL_EXT_color_buffer_float  detected and used
LIBGL: Extension GL_EXT_color_buffer_half_float  detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Max vertex attrib: 16
LIBGL: Extension GL_OES_standard_derivatives  detected and used
LIBGL: Extension GL_ARM_shader_framebuffer_fetch detected and used
LIBGL: Extension GL_OES_get_program_binary  detected and used
LIBGL: Number of supported Program Binary Format: 1
LIBGL: Max texture size: 16383
LIBGL: Max Varying Vector: 31
LIBGL: Texture Units: 16/16 (hardware: 16), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic  detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is ARM
LIBGL: sRGB surface supported
LIBGL: EGLImage from Pixmap supported
LIBGL: EGLImage to Texture2D supported
LIBGL: EGLImage to RenderBuffer supported
LIBGL: Targeting OpenGL 2.1
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: glXMakeCurrent FBO workaround enabled
LIBGL: FBO workaround for using binded texture enabled
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/home/radxa
LIBGL: Loaded a PSA with 1 Precompiled Programs
arm_release_ver of this libmali is 'g2p0-01eac0', rk_so_ver is '4'.
[INFO   ] [GL          ] Using the "OpenGL" graphics system
[INFO   ] [GL          ] Backend used <sdl2>
[INFO   ] [GL          ] OpenGL version <b'2.1 gl4es wrapper 1.1.5'>
[INFO   ] [GL          ] OpenGL vendor <b'ptitSeb'>
[INFO   ] [GL          ] OpenGL renderer <b'GL4ES wrapper'>
[INFO   ] [GL          ] OpenGL parsed version: 2, 1
[INFO   ] [GL          ] Shading version <b'1.20 via gl4es'>
[INFO   ] [GL          ] Texture max size <16383>
[INFO   ] [GL          ] Texture max units <16>

So, if you are application uses SDL2, libGL or any wrapper around libGL, gl4es may do the trick for you.