Allwinner SoCs with Mali GPU Get Mainline Linux OpenGL ES Support

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:


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:


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.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

23 Replies to “Allwinner SoCs with Mali GPU Get Mainline Linux OpenGL ES Support”

  1. Wow! So you can finally run blob-free desktop on Allwinner SoCs? Almost everything is supported in mainline already.

  2. @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?

  3. Taner :
    Does this driver implements hw video decoding?

    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.

  4. 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.

  5. @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.

  6. @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!

  7. blu :
    OGL ES2 is still something.

    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?

  8. @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.

  9. 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.

  10. @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

  11. @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.

  12. 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.

  13. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC