Banana Pi / Arch Linux / Accelerated Mali GPU

Introduction

Achieving accelerated graphics on the Banana Pi was quite a challenge for me. Unfortunately it is not done completely just by installing xf86-video-fbturbo-git from the AUR as I had library issues with that package.

So I decided to try the “hard way” building all the stuff on my own. Thanks to “WebReflection” who made a great guide, I finally could build everything (see this thread).

Unfortunately the Mali 400 is not able to render accelerated OpenGL but OpenGLES only, which means, that mesa-libgl is still required as OpenGL software rendering fallback.

Building

We are going to build the packages libdri2, libump, sunxi-mali and xf86-video-fbturbo. If you installed any of these using AUR, the following steps probably will fail somewhere (at least they did on my machine).At first, please make sure you have a running X11 using xf86-video-fbdev. Secondly make sure, the required kernel modules are up and running, lsmod should show at least the modules ump, mali, drm and mali_drm.Besides the usual building packages like make etc., I needed to install dh-autoreconf to get the required autoreconf tool from AUR which has a quite long dependency list. The whole process took some time and I needed some tiny changes to some PKGBUILD files but in the end it worked.

yaourt -S xorg-server-devel xorg-server mesa-libgl make gcc git automake autoconf pkg-config libtool dh-autoreconf

When you’re ready, we can begin building all the things.

Clone the repositories:

cd $HOME
git clone https://github.com/robclark/libdri2.git
git clone https://github.com/linux-sunxi/libump.git
git clone https://github.com/linux-sunxi/sunxi-mali.git
git clone https://github.com/ssvb/xf86-video-fbturbo.git

Build libdri2:

cd $HOME/libdri2
./autogen.sh --prefix=/usr
sudo make install

Build libump:

cd $HOME/libump
autoreconf -vi
./configure --prefix=/usr
make
sudo make install

We are going to build sunxi-mali but install the libraries into /usr/lib/mali to avoid conflicts with mesa-libgl (see my blog post libGLES Problems). Optionally we also replace the files gl2.h and gl2ext.h to avoid possible compiling problems later:

cd $HOME/sunxi-mali
git submodule init
git submodule update
sudo mkdir /usr/lib/mali
make config ABI=armhf VERSION=r3p0
wget http://pastebin.com/raw.php?i=hHKVQfrh -O ./include/GLES2/gl2.h
wget http://pastebin.com/raw.php?i=ShQXc6jy -O ./include/GLES2/gl2ext.h
sudo make -C include install
sudo make -C lib/mali prefix=/usr/ libdir='$(prefix)/lib/mali/' install
sudo sh -c 'echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf'

Build xf86-video-fbturbo:

cd $HOME/xf86-video-fbturbo
autoreconf -vi
./configure --prefix=/usr
make
sudo make install

Tell X11 to use the driver, therefore we create a file /etc/X11/xorg.conf.d/99-fbturbo.conf and use following configuration:

Section "Screen"
        Identifier      "My Screen"
        Device          "Allwinner A10/A13 FBDEV"
        Monitor         "My Monitor"
EndSection

Section "Device"
        Identifier      "Allwinner A10/A13 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb0"
        Option          "SwapbuffersWait" "true"
        Option          "AccelMethod" "G2D"
EndSection

Section "Monitor"
        Identifier      "My Monitor"
        Option          "DPMS" "false"
EndSection

If everything built, congratulations, you should be done. If you restart your X11 you hopefully see the information in your /var/log/Xorg.0.log, that fbturbo_drv.so is loaded:

Loading /usr/lib/xorg/modules/drivers/fbturbo_drv.so

Note, that you will get following issue in your X11 log file:

AIGLX: reverting to software rendering

To allow hardware acceleration without root privileges, you have to give write permissions to following device files:

chmod 666 /dev/ump /dev/mali /dev/disp /dev/g2d /dev/fb* /dev/cedar_dev

To make that permanent, edit the already given file /etc/udev/rules.d/50-mali.rules with root privileges, so that it looks like:

KERNEL=="mali", MODE="0660", GROUP="video"
KERNEL=="ump", MODE="0660", GROUP="video"
KERNEL=="disp", MODE="0660", GROUP="video"
KERNEL=="g2d", MODE="0660", GROUP="video"
KERNEL=="fb*", MODE="0660", GROUP="video"
KERNEL=="cedar_dev", MODE="0660", GROUP="video"

And make sure your user is in group video. If the command groups does not show video, you have to assign the group to the user:

sudo usermod -aG video $USER

You might test, if OpenGLES is working by compiling and running (within a X11 session) the given test program in sunxi-mali repository (if you use make, add -lX11 to the appropriate parameters):

cd $HOME/sunxi-mali/test
cc -Wall -o test test.c -lEGL -lGLESv2 -lX11
./test

If you see a red, green, blue triangle, you were successful. In my case, the program es2gears_x11 shows an average of 148 FPS (es2gears_x11 is the OpenGLES counterpart of glxgears, you also get it in package mesa-demos).

VDPAU

It is also possible to accelerate video playback by compiling libvdpau-sunxi (see also the post #6 and #10 of “nnn2” in this thread).
As we need libvdpau, we install the package “libvdpau-va-gl” first.

yaourt -S libvdpau-va-gl
cd $HOME
git clone https://github.com/linux-sunxi/libvdpau-sunxi.git
cd $HOME/libvdpau-sunxi
make
sudo make install

Export the correct value for VDPAU_DRIVER environment variable and start mplayer:

export VDPAU_DRIVER=sunxi
sudo mplayer -vo vdpau -vc ffmpeg12vdpau,ffh264vdpau [filename]

Finally add the export of the environment variable to the /etc/profile:

sudo sh -c 'echo "export VDPAU_DRIVER=sunxi" >> /etc/profile'

I also created an optional ~/.mplayer/config to have the mplayer parameters automatically set:

vo=vdpau
vc=ffmpeg12vdpau,ffh264vdpau
fullscreen=yes
quiet=yes
ao=pulse
framedrop=yes
cache=8192
lavdopts=threads=2
ass=no
ass-font-scale=1.4
ass-color=FFFFFF00
ass-border-color=00000000
ass-use-margins=yes
ass-bottom-margin=50
spualign=2
subalign=2
subfont=/usr/share/fonts/TTF/DejaVuSans.ttf
subcp=cp1250

Using the above mentioned configuration, I am able to run 1080p MKV files flawlessly at about 25% CPU usage by mplayer.

AUR

Hopefully this whole process will be simplified by providing a proper PKGBUILD. Maybe I find the time to do so, as it would be a cleaner and easier solution for most of us.

24 comments:

  1. Thank you very much for your guide, Ryad. I worked really hard to get it finally working on my A10 tablet and your guide saved me great amounts of time and effort. It’s working! It wasn’t problem-free ride, though:

    1. I couldn’t get it to work with dedicated /usr/lib/mali library directory like you advised. GL applications didn’t work and threw me errors about ‘libraries not found’ and other errors. After some manual rearrangement in ‘/lib/libGL* links I concluded libraries must’ve messed up somewhere along the way. I reinstalled mesa and mesa-libgl completely, and went with good old ‘sudo make install’ on sunxi-mali. It did the trick.

    2. Some programs still complain about ‘LibEGL DRI2 failed to authenticate’, or ‘failed to load lima driver’. I think it must be mesa/libGL thing (?). Anyway, mplayer plays 720p HD videos just fine and chocolate-doom runs smoothly, so video acceleration must be working correctly (I only get ~40 FPS in es2gears_x11, so yeah, guess it’s not as good as BananaPi’s A20 GPU).

  2. Great to hear that! 😀
    This is actually fantastic, i hope tho you can release a ready to install package …
    Can by any chance this be ported to other linux systems?
    Anyway, great job, ill try to compile it and hopefully ill be able to enjoy 1080p videos on banana pi !

  3. Hi Ryad,

    I’ve read your work and first of all: congratulations for your great effort.
    I’m writing to you because I’ve been working hard on a project for the last year that is focused on transforming Allwinner A20’s into vmware view thinclients. I’ve based on Debian distro instead of Arch-linux, but the main concept is the same. It is working right now in a production environment for more than 40 minipcs, so the development is solid. I was able to compile and make work video acceleration for mplayer or vlan, because you can launch them based on opengles (as you stated in your post), but I haven’t been succesful with vmware video acceleration: it drops to software acceleration, so when you play a video inside the virtual machine via vmware view client, cpu goes to 110% and everything gets a little bit unstable; it doesn’t fail, but image hangs out a little bit.

    We have tested bananapis, and they also work, so the aproach works (I could say) for almost all sunxi boards (A10, A13, A20, A31, ….).

    I’m writing to you because maybe you could colaborate with me with some ideas in order to make video hardware acceleration work with vmware view… The problem is that vmware doesn’t have an opened-source distro, and I only have armhf debian packages. I have thought about a couple of solutions, but I’m not pretty sure if I’m in the right way with them or not…:

    first idea: Writing/using an opengl wrapper for the opengles driver, in order for X.org to use hardware accelerated opengl, based on opengles.

    second idea: hesitate using X.org as X server and installing Wayland as windows server. As Wayland is able to manage windows based on opengles, maybe it could be the clue, because vmware client relies on X server to display all the video, so maybe it could do the trick…

    third idea: As someone commented out in this post, maybe I could use VNC as X server, and compiling VNC to use OpenGLES to use hardware acceleration. That way, maybe (and only maybe) it would be posible to use hardware acceleration as a basis for X-windows.

    What do you think? Shall we colaborate on this issue? I can share my image with you if you want. That could accelerate the process.

    Thanks in advance for your time and hard contribution to sunxi community,
    Miguel

Leave a Reply

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