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.
1: https://developer.arm.com/Processors/Mali-G52
2: https://wiki.debian.org/PanfrostLima#Software_support
3: https://packages.debian.org/source/bullseye/mesa
4: https://gitlab.freedesktop.org/mesa/mesa/-/commit/e1959f0f5990fc73e78a7431a800c623b6fc5208
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: libGLESv2.so
LIBGL: loaded: libEGL.so
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.
Nice finds folks, and thanks for reaching out to their dev team on this!
In theory, would this not lead towards just building https://gitlab.freedesktop.org/mesa/mesa/ 21.2 or above as the easy solution instead of using something like gl4es?
One question: Which is faster? Libmali ? or MESA? Is gl4es a better solution than using MESA?
That is correct. I have a Rock 3A, which has the RK3568 not the RK3566 in the Zero 3W, but both have the same GPU and I’m able to get Panfrost working with my own compiled from source version of Mesa 21.3. Panfrost works ok(sometimes the desktop glitches), and is much faster than libmali, while not requiring any modifications to xserver/X11.
Panfrost via mesa is faster and is fully OpenGL 3 compliant, plus doesn’t require any translation layer from OpenGL ES(direct translation from hardware, something like that). gl4es does a translation of OpenGL ES -> OpenGL so there’s overhead(slower) and doesn’t work with all applications, plus it’s not conformant
Hmm I believe this information on Debian’s wiki is outdated, Mesa’s own Panfrost page lists the G52 GPU as the only conformant GPU supported by the Panfrost driver. So technically Panfrost is better than libmali in every way, it’s an official OpenGL conformant driver that works with both X11 and Wayland.
For anyone who needs Panfrost driver on Debian 11(Bullseye), here’s Mesa 21.3.8 compiled with Panfrost enabled. To get Panfrost working, you’ll need to install the mesa libraries along with a Linux kernel version 5.8 and above.
I also have Mesa 24 for Debian 12 compiled with Panfrost if anyone is interested. Newer mesa has updated Panfrost driver that is more stable(less graphical glitches on desktop) and I enabled the experimental Panvk Vulkan driver.
For more info on setting up GPU drivers(Panfrost/libmali) for the Mali G52 GPU on RK3566/RK3568, you may refer to my thread for the Rock 3A/3B that I will be updating as I experiment further.
Nice work there, I’ll have to mess with it a bit more when I get some time!
Hi, possible to provide Mesa 24 binaries to install? Thanks