OpenGL ES support in Linux for ARM SoC is usually pretty hard to get because of closed source binary blobs coupled with the manufacturers focus on Android. Workarounds include open driver projects such as Freedreno for Qualcomm Adreno GPU, Nouveau for Tegra, or Etnaviv for Vivante GPUs, as well as libhybris library that converts Linux calls into Android calls in order to leverage existing Android GPU binary blobs. Allwinner processors relies on either PoverVR or ARM Mali GPU, and the former does not have any open source project, while some work is still being going for the latter with Lima project, but it’s not ready yet.
That means so far, you’re only option was to use libhybris for either GPU family. The good news is that Free Electrons engineers have been working on OpenGL ES support for ARM Mali GPU for Allwinner processor, and have been allowed to release the userspace binary blobs. Not quite as exciting as an actual open source release, but at least, we should now be able to use OpenGL ES with mainline Linux on most Allwinner SoCs (the ones not using PowerVR GPUs).
If you want to try it on your platform, you’ll first need to add ARM Mali GPU device tree definitions to your platform’s DTS file if it is not already there, before building the open source Mali kernel module for your board:
|
1 2 3 4 5 6 7 |
git clone https://github.com/mripard/sunxi-mali.git cd sunxi-mali export CROSS_COMPILE=$TOOLCHAIN_PREFIX export KDIR=$KERNEL_BUILD_DIR export INSTALL_MOD_PATH=$TARGET_DIR ./build.sh -r r6p2 -b ./build.sh -r r6p2 -i |
This will install mali.ko module to your rootfs. The final step is to get the userspace drivers, either fbdev or X11-dma-buf depending on your setup, for example:
|
1 2 3 |
git clone https://github.com/free-electrons/mali-blobs.git cd mali-blobs cp -a r6p2/fbdev/lib/lib_fb_dev/lib* $TARGET_DIR/usr/lib |
That should be all for the installation, and you should be able to test OpenGL ES using es2_gears or glmark2-es2 programs. Based on the github patchsets, this should currently work for Linux 4.6 to 4.14.
Update: On a separate note, somebody has recently released ffmpeg 3.3.4 with open source Cedrus driver for Allwinner video processing unit, and tested with Allwinner R40 and A64 SoC. Code and package can be found in github.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Wow! So you can finally run blob-free desktop on Allwinner SoCs? Almost everything is supported in mainline already.
@ValdikSS
git clone https://github.com/free-electrons/mali-blobs.git
so you really clone some mali blobs 🙂
All of a sudden Allwinner parts become much more useful.
Awsome news!
About hw h264 encoder, maybe a blob in 2 years when H3 will be obsolete
Glad to see there is also a wayland port. Does this driver implements hw video decoding?
@blu
Can you please elaborate which use cases this could affect. I also fail to understand for which Mali variants this applies since my understanding is that the only problem all the time was Allwinner not providing ARM DDK stuff under a proper license and what has happened now only talks about ultra dog slow Mali 400 (‘EULA for Mali 400MP _AW.pdf’). Is dog slow Mali450 also affected?
@bob
How is Allwinner’s video engine affected by the above? Why don’t you use the HW accelerated encoding with Allwinner SoCs already if you’re interested in?
Of course not. No GPU in the ARM world deals with video decoding/encoding. And if people would start to realize this (video being totally unrelated to 2D/3D stuff) all that excitement about really outdated GPU userland blobs being now (!) available for horribly outdated 2D/3D acceleration implementations from almost a decade ago might already be gone.
@bob
A few days ago, somebody contacted me about “ffmpeg 3.3.4 with cedrus264 HW encoder”. I’ve added a couple of lines about that at the end of the post.
@cnxsoft
I know there is a working hw encoder under legacy kernel (see armbian forum) but if it’s work with mainline kernel i m happy to hear that
So now we can play quake on a old allwinner A10 with a mainline kernel. Altough I still hoped Libv would pick-up LIMA again.
@tkaiser
I was referring to scenarios where people with recent kernels can now actually use their Allwinner malis for OGL ES. Of course the 400 series are ancient by all standards, and usless for OCL, but OGL ES2 is still something.
@tkaiser
I understand gpu isn’t vpu for hw encode and decode but all this blob and all thing legacy kernel are mystic so it’ s was just an question lost. i read also there is some limitation about resolution on the input of h264 encoder. my goal is to record h264 (rtsp camip) and reencode in lower resolution for preview near realtime. in case the camip don’t output the resolution needed by hw encoder, im out!
@bob
I think Cedrus is an open source implementation, and there’s a version of mainline Linux: https://github.com/FlorentRevest/linux-sunxi-cedrus
I’m not sure about the status (no commit since Jan 10. though).
But what exactly? Most users reading the headline think only about video (decoding) which is totally unrelated. Without proper mainline Cedrus support too the few use cases where ‘real OpenGL ES’ support would make a difference still aren’t possible (thinking about Kodi or the stuff everyone dreams of: replacing their PCs with a $7 toy and watching videos in Chromium on an OPi Zero).
So what’s possible now? Quake with mainline kernel. What else? 32-bit platforms only? Or also 64-bit? Wrt Mali450: do blobs work here and does EULA cover this Mali variant too?
@tkaiser
OpenGL graphics is quite important for users of development boards. The main reason Raspberry Pi users buy the board is OpenGL desktop Linux on the same machine as GPIO coding with ported Arduino libraries.
Its true that the GPU’s are generally painfully slow, but even so being able to finally use OpenGLES2.0 is wonderful news for people like me who want to do actual graphical programming.
I feel Rpi leads mainly due to the simple fact everything on it works, the same simply is not true of so many other SBC’s
I hope this release will see all the makers producing new distro’s for their boards, and encourage other chip makers to open up the GPU, not just to OpenGLES but OpenCL as well so we can really push them and force new tech to keep up with users needs.
@tkaiser My understanding is that *at least* scaling and colorspace conversion are supported in such GPUs, which are required parts of video rendering (yeah ok you could get technical and say that decoding and rendering are not the same thing, but for practical purposes one without the other is pointless). Even as far back as old Cirrus Logic parts (ARM7TDMI maybe? it’s a long time ago…) this was a feature
Ok, so proper open source gpu drivers like etnaviv and freedreno are workarounds, but this hack isn’t? WTF!?!
@Lewin
Scaling and color space conversion are usually done with the display engine–the actual logic that scans out the buffer and to the display.
@tkaiser
What’s wrong about some Quake on the allwinners? ; )
Seriously, though, there are quite a few things one can do with a functioning GLES2 GPU. Even if one doesn’t care about GPU programming and/or games, there are desktop compositors and libraries that can make use of the 3D API for acceleration of general computations like FFT; Utgard Mali is really at a disadvantage there, with its reduced fp precision, but is still usable. Even the worst GPU is a potent computational accelerator – what people would use that for is entirely up to their imagination (and often patience in extracting the computations they need from the APIs at hand).
ps: since RPi was brought in the discussion – RPi started with barely functioning GLES2 drives – its GLSL compiler was very sub-par (which made me drop it then and there, but I hope things have progressed since the RPi1 days). And yet, people took it in droves and made some very creative things with it. Imagine what would’ve been the case if it had a proper GLES2 stack.
Hello, can someone help with DTS for h3/sun8i ? There is only a20/sun7i in the example above.
More Arm Mali blobs released for 64-bit, Wayland, etc.. Available blobs are now:
r6p2 version, ARM 32 bits, X11
r6p2 version, ARM 32 bits, fbdev
r6p2 version, ARM 32 bits, Wayland (new)
r6p2 version, ARM 64 bits, X11 (new)
r6p2 version, ARM 64 bits, fbdev (new)
r6p2 version, ARM 64 bits, Wayland (new)
r8p1 version, ARM 32 bits, fbdev (new)
r8p1 version, ARM 64 bits, fbdev (new)
Still in the same Free Electrons github repository.
TV drove down the price of arm SoC TV boxes. Embracing games on them will bring the GPU support you desire.
Happy chick emulator shows what is possible in Android, however Comodo mobile security says it has a virus. However sadly people prefer to infight rather than co-operate on solutions.