Home > Allwinner A-Series, Allwinner H-Series, Allwinner R-Series, AllWinner V-Series, Linux, Linux 4.x > Allwinner SoCs with Mali GPU Get Mainline Linux OpenGL ES Support

Allwinner SoCs with Mali GPU Get Mainline Linux OpenGL ES Support

September 26th, 2017 Leave a comment Go to comments

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.

  1. ValdikSS
    September 26th, 2017 at 12:53 | #1

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

  2. m][sko
    September 26th, 2017 at 13:04 | #2

    @ValdikSS
    git clone https://github.com/free-electrons/mali-blobs.git
    so you really clone some mali blobs 🙂

  3. blu
    September 26th, 2017 at 14:23 | #3

    All of a sudden Allwinner parts become much more useful.

  4. bob
    September 26th, 2017 at 14:41 | #4

    Awsome news!
    About hw h264 encoder, maybe a blob in 2 years when H3 will be obsolete

  5. Taner
    September 26th, 2017 at 14:44 | #5

    Glad to see there is also a wayland port. Does this driver implements hw video decoding?

  6. tkaiser
    September 26th, 2017 at 14:58 | #6

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

  7. tkaiser
    September 26th, 2017 at 15:38 | #7

    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.

  8. September 26th, 2017 at 16:48 | #8

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

  9. bob
    September 26th, 2017 at 17:04 | #9

    @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

  10. roel
    September 26th, 2017 at 17:07 | #10

    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.

  11. blu
    September 26th, 2017 at 17:14 | #11

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

  12. bob
    September 26th, 2017 at 17:21 | #12

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

  13. September 26th, 2017 at 17:56 | #13

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

  14. tkaiser
    September 26th, 2017 at 18:03 | #14

    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?

  15. Jerry
    September 26th, 2017 at 18:17 | #15

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

  16. September 26th, 2017 at 19:54 | #16

    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.

  17. Lewin
    September 27th, 2017 at 05:16 | #17

    @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

  18. Rob Clark
    September 27th, 2017 at 08:38 | #18

    Ok, so proper open source gpu drivers like etnaviv and freedreno are workarounds, but this hack isn’t? WTF!?!

  19. willmore
    September 27th, 2017 at 09:29 | #19

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

  20. blu
    September 27th, 2017 at 14:29 | #20

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

  21. Sergey Suloev
    October 9th, 2017 at 01:38 | #21

    Hello, can someone help with DTS for h3/sun8i ? There is only a20/sun7i in the example above.

  1. No trackbacks yet.