Jump to content

OpenGL on Mali GPU (BananaPi, OrangePi PC, etc)


dimag0g

Recommended Posts

Hello,

 

I wish to share my research on getting OpenGL to work on Mali GPU. I realize Armbian focuses on server images, but I suppose many people would be interested nevertheless. I have a Banana Pi Pro and an Orange Pi PC, which both have a compatible GPU. Perhaps it will work on other boards as well.

 

Here are the commands I used to get OpenGL to work.

 

1. Install:

# install GLX Gears, mesa GL and GLU libraries 
apt-get -y install mesa-utils

# install development tools
apt-get -y install build-essential automake pkg-config libtool ca-certificates git cmake subversion
                                                                                
# install required libraries                                                 
apt-get install libx11-dev libxext-dev xutils-dev libdrm-dev x11proto-xf86dri-dev libxfixes-dev
                                   
#  get source code                                                                                        
git clone https://github.com/robclark/libdri2                                   
git clone https://github.com/linux-sunxi/libump                                 
git clone https://github.com/linux-sunxi/sunxi-mali                             
git clone https://github.com/ssvb/xf86-video-fbturbo                            
git clone https://github.com/ptitSeb/glshim

# install mali driver
cd sunxi-mali                                                                   
git submodule init                                                              
git submodule update                                                            
git pull                                                                        
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   
make config ABI=armhf VERSION=r3p0                                              
mkdir /usr/lib/mali                                                             
echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                            
make -C include install                                                         
make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install           
cd ..

2. Build

# Step 1: build and install helper libraries                                    
                                                                                
cd libdri2                                                                      
autoreconf -i                                                                   
./configure --prefix=/usr                                                       
make                                                                            
make install                                                                    
cd ..                                                                           
                                                                                
cd libump                                                                       
autoreconf -i                                                                   
./configure --prefix=/usr                                                       
make                                                                            
make install                                                                    
cd ..                 

# Step 2: build video driver                              
                                                                                
cd xf86-video-fbturbo                                                           
autoreconf -i                                                                   
./configure --prefix=/usr                                                       
make                                                                            
make install                                                                    
cd ..     

# Step 3: build GL wrapper                                               
                                                                                
cd glshim                                                                       
cmake .                                                                         
make                                                                            
cp lib/libGL.so.1 /usr/lib/ # replace the software GL library with the wrapper
cd ..    

3. Configure your system

- configure your kernel to allocate memory for the GPU

- make sure mali and mali_drm kernel modules are loaded

- give your user permissions to access /dev/ump and /dev/mali

- configure Xorg to use fbturbo driver

 

4. Test:

# run a basic test
glxgears   

# install and run a GL benchmark 
apt-get -y install globs  
/usr/lib/globs/benchmarks/GL_pointz/gl_pointz                            

# try to run a real game
apt-get -y install billard-gl
billard-gl  

This all worked out for me rather nicely. The only issue I have encountered is a segfault that many GL programs get when they shut down. I'm currently debugging this issue, but it would be helpful to know others experience it as well, and perhaps get some advice from people experienced in GLX or SDL.

 

Edit: I know glxgears is not a real benchmark, but let me give you some numbers to make it clear what I'm talking about. Results are from Orange Pi PC clocked at 1296000 Hz (and are CPU-bound):

user@bananapi:~$ glxgears
LIBGL: Initialising glshim
libGL: built on Jun 12 2016 06:12:01
LIBGL: Current folder is:/home/user
libGL:loaded: libGLESv1_CM.so
libGL:loaded: libEGL.so
2074 frames in 5.0 seconds = 414.688 FPS
2071 frames in 5.0 seconds = 414.085 FPS
2070 frames in 5.0 seconds = 413.915 FPS
^C
Link to comment
Share on other sites

Thankyou for posting this. there are many people who visit this forum that are looking for support and solutions as you have posted above.

 

The devs are looking for help to create more Desktop style images and solutions. You seem like just the sort of person they are looking for to assist. Your contribution could well be rewarded!!

 

please take a look here http://forum.armbian.com/index.php/topic/1325-claim-a-task-set-due-date-and-start-doing-it/

Link to comment
Share on other sites

This all worked out for me rather nicely.

 

Two questions:

 

1) How differs that from using any recent desktop Armbian image for A20 or H3 devices (we try to do all of the above already as part of our desktop installation routine and it 'should just work' since 5.05)? I really have a hard time to see threads like this popping up every few weeks explaining in detail time consuming compilation processes for stuff that should already work out of the box with desktop Armbian images for those 2 platforms. Please explain

 

2) Are we talking about OpenGL or OpenGL ES here?

Link to comment
Share on other sites

@dimag0g

 

Now we only need a step more ;) As Thomas already mentioned, our desktop come with working video and GLes acceleration. It works on H3, while I think it's currently broken on A20 due to some recent kernel patches. More people are trying to fix all this so it would be nice to join efforts.

 

http://forum.armbian.com/index.php/topic/1273-armbian-510-to-511-break-video-playback-cb2/

http://linux-sunxi.org/User:Rellla/Armbian

and more

 

We would like to produce a deb packaged desktop upgrade pack that would simplify all this and that we might get rid off special desktop version download. Take a look on current build system:

https://github.com/igorpecovnik/lib/blob/master/desktop.sh#L78

 

What needs to be done: we use prepacked libraries - they need to be build from sources, one by one. Result must be monitored / supported until it becomes rock stable.

Link to comment
Share on other sites

Two questions:

 

2) Are we talking about OpenGL or OpenGL ES here?

I think it's openGL ES only. The only OpenGL board I have is an NVidia TK1. I tried OpenGL on an A20 but it is software rendering only.

 

Cheers,

Steven

Link to comment
Share on other sites

https://github.com/ptitSeb/glshim is a wrapper to execute OpenGL1.x (<-desktop!) code embedded systems which only provide OpenGL/ES 1.1

The only thing that differs from the desktop image should be the last point. Installation of glshim. If that would be necessary in a desktop distribution? I would prefer to get that optionally if ever. Though it's a nice gimmick imho.

Trying to get GL working on GL/ES platform is hacky anyway. At least when dealing with the minor version numbers glshim supports.

 

Regards

rellla

Link to comment
Share on other sites

I think it's openGL ES only. The only OpenGL board I have is an NVidia TK1. I tried OpenGL on an A20 but it is software rendering only.

It's OpenGL (GLX to be precise) emulated via hardware-accelerated GLES. What would be the use of only GLES anyway? Most games in Debian repo require OpenGL, don't they?

 

If that would be necessary in a desktop distribution? I would prefer to get that optionally if ever.

Trying to get GL working on GL/ES platform is hacky anyway. At least when dealing with the minor version numbers glshim supports.

Well, it's far from perfect I admit, but it's definitely usable, and I don't see the alternative. It's not like OpenGL games are getting GLES ports soon. I don't have the intention to push anything though, only to share. If you feel that armbian is better off without OpenGL than with a buggy one, I won't argue.

 

PS. It looks like I went through many unnecessary steps here by picking the wrong image. I didn't see a desktop image for Banana Pi and it felt like desktop images were not so stable yet.

Link to comment
Share on other sites

# install mali driver
cd sunxi-mali                                                                   
git submodule init                                                              
git submodule update                                                            
git pull                                                                        
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   
make config ABI=armhf VERSION=r3p0                                              
mkdir /usr/lib/mali                                                             
echo "/usr/lib/mali" > /etc/ld.so.conf.d/1-mali.conf                            
make -C include install                                                         
make -C lib/mali prefix=/usr libdir='$(prefix)/lib/mali/' install           
cd ..

Thanks for sharing this. It will definitely take a part in my future installations. Before i test it - will i be able to choose opengl as rendering method in video players, or it is only for games? And it's not clear for me from above - what variant of mali binary driver you install - X11 or framebuffer? Does it matter?

Link to comment
Share on other sites

will i be able to choose opengl as rendering method in video players, or it is only for games?

I didn't try any video players, though I'm pretty sure GLX won't beat VDPAU for video rendering.

 

And it's not clear for me from above - what variant of mali binary driver you install - X11 or framebuffer? Does it matter?

I tested X11 one.

Link to comment
Share on other sites

It looks like I went through many unnecessary steps here by picking the wrong image. I didn't see a desktop image for Banana Pi and it felt like desktop images were not so stable yet.

 

The desktop images are simply our server / CLI images where 'few' stuff will be added at image creation time: https://github.com/igorpecovnik/lib/blob/master/desktop.sh (we try to refactor this whole stuff so that it's not part of image creation but will be part of several armbian .deb packages available through apt.armbian.com... or let's better say we asked for volunteers to do this. If this has been resolved it will be easy to upgrade CLI images to desktop. And now the recommended way if unsure regarding GUI acceleration or not to start with a desktop image and downgrade this to server as outlined in H3 mini FAQ)

 

They're not unstable in any way, the only difference is that they consume more disk space and RAM (/boot/boot.cmd has to be adjusted when switching between CLI and GUI mode too) but that's it. You can use any desktop image for server tasks, just disable the nodm service and you're done (will then performan exactly identical afterwards if memory reservations in boot.cmd/boot.scr are also adjusted)

 

I really appreciate that users like you or @RagnerBG start to contribute improving desktop images. But our goal should be to get this as part of the build system (creating all this stuff nicely packaged so that it's just an apt-get install|remove away later without the need to torture these small boards with compile orgies :) )

Link to comment
Share on other sites

I didn't try any video players, though I'm pretty sure GLX won't beat VDPAU for video rendering.

I guess so, but VDPAU have some issues with certain mpeg4 files, so it is good to have other option at hand. Thank you.

Link to comment
Share on other sites

I guess so, but VDPAU have some issues with certain mpeg4 files, so it is good to have other option at hand. Thank you.

 

You will still have problems with decoding then. GL doesn't do any video decoding, just rendering. VDPAU rendering much more efficient BTW.

Link to comment
Share on other sites

I have a bunch of questions, (I hope I don't waste your time with these, feel free to tell if I do):

 

we try to do all of the above already as part of our desktop installation routine and it 'should just work' since 5.05

Do you refer to "legacy" images here? Am I right that Mali is only usable with the old 3.x kernel?

 

You can use any desktop image for server tasks, just disable the nodm service and you're done (will then performan exactly identical afterwards if memory reservations in boot.cmd/boot.scr are also adjusted)

This is handled by desktop.sh when going from CLI to desktop, right? Is the rollback to be done manually when going from desktop to CLI?

 

our goal should be to get this as part of the build system (creating all this stuff nicely packaged so that it's just an apt-get install|remove away later without the need to torture these small boards with compile orgies :) )

Well, I fully agree. I switched from bananian to armbian exactly because of how you guys have packaged everything nicely.

I just wanted to show you what I've done to understand if people are interested in this. Also, I'm not familiar with debian packaging system, so it would be hard for me to share *.deb files from the start (and I'd do the double work for all the packages you already have, as it turned out)

Link to comment
Share on other sites

Am I right that Mali is only usable with the old 3.x kernel?

Yes

 

This is handled by desktop.sh when going from CLI to desktop, right? Is the rollback to be done manually when going from desktop to CLI?

desktop.sh installs additional stuff at build time (+ extra packages defined in configuration.sh). There is no official rollback procedure, other than "disable nodm or remove a bunch of packages if you want to free up space"

 

Well, I fully agree. I switched from bananian to armbian exactly because of how you guys have packaged everything nicely.

I just wanted to show you what I've done to understand if people are interested in this. Also, I'm not familiar with debian packaging system, so it would be hard for me to share *.deb files from the start (and I'd do the double work for all the packages you already have, as it turned out)

We have prebuilt packages, but this is not the right solution, we need to have scripts to create packages from scratch. It's not hard, testing will probably consome more time than writing the scripts.

Link to comment
Share on other sites

Well, regarding Mali400 better don't ask me. I still don't know exactly how much GUI stuff benefits from available Mali drivers (apart from 3D games and some window manager effects) since my understanding is that when disabling transparency effects missing 3D acceleration doesn't hurt when it's about 'normal GUI usage' (using X, browsers and mpv to watch video... and the Mali driver version we're dealing with -- 4.0.something AFAIK -- is not sufficient to help speeding up eg. Chromium)

 

Then desktop.sh is currently part of the build process that means we have only one switch at image creation time and that's why desktop vs. server images exist. Our goal is to change that so that we might be able to provide one OS image per board that is later upgradeable by an 'apt-get install|remove armbian-desktop' (or whatever name this meta package will have). Downgrading from desktop to CLI is possible already (please also see the aforementioned H3 Mini FAQ)

 

And I'm also yet not that much familiar with Debian packaging and also re-invented the wheel a few times. But often steps differ slightly and in the end the already established process might benefit from anyway :)

Link to comment
Share on other sites

Just my 2 cents: Mali drivers in current form are not useful on mainline, but mripard ported kernel part for C.H.I.P. (R8) already, so if there is interest, it can be done. But first you need video driver to actually output any image to display, which is work in progress. Anyway, GL ES wouldn't help you in normal usage, except for games and Kodi, as tkaiser already said.

Link to comment
Share on other sites

Just my 2 cents: Mali drivers in current form are not useful on mainline, but mripard ported kernel part for C.H.I.P. (R8) already, so if there is interest, it can be done. But first you need video driver to actually output any image to display, which is work in progress. Anyway, GL ES wouldn't help you in normal usage, except for games and Kodi, as tkaiser already said.

Pardon my ignorance, but what is CHIP (a very unfortunate name to google for)? Is it rockchip SoC?

 

And yes, OpenGL is primarly needed for games (you have stuff like openscad, but I don't expect to meet many users here). You make it sound like games are not a big deal, or not normal usage. I bet many people would see it as a big advantage if they could run 3D games on their boards.

Link to comment
Share on other sites

Pardon my ignorance, but what is CHIP (a very unfortunate name to google for)? Is it rockchip SoC?

 

And yes, OpenGL is primarly needed for games (you have stuff like openscad, but I don't expect to meet many users here). You make it sound like games are not a big deal, or not normal usage. I bet many people would see it as a big advantage if they could run 3D games on their boards.

 

C.H.I.P. is Next Things SBC based on Allwinner R8 chip (similar to A13, I think) https://getchip.com/

 

Quoted from github:

 

This is a shim providing OpenGL 1.x functionality to OpenGL ES accelerated cards.

 

I'm not a gamer, but OpenGL 1.x sounds like that you won't be able to play many games.

Link to comment
Share on other sites

I'm not a gamer, but OpenGL 1.x sounds like that you won't be able to play many games.

It's enough to play Minecraft, OpenArena, Torcs and Nexuiz, just to name a few (when I say ehough I mean solely OpenGL API version, GPU and CPU performance can be sufficient or not for a decent gameplay).

Link to comment
Share on other sites

It's enough to play Minecraft, OpenArena, Torcs and Nexuiz, just to name a few (when I say ehough I mean solely OpenGL API version, GPU and CPU performance can be sufficient or not for a decent gameplay).

 

Not to mention some nice emulators out there.

 

I went through the same "compilation orgy" to produce my framebuffer mali driver and finally was able to run glmark2-es with some (useless) satisfaction. I also noticed the performance bump due to a patch included in armbian 5.11 to run the mali at 600Mhz instead of miserable 250Mhz.

 

BTW some applications are precluded in case of lack of an accelerated display driver, beginning from desktop compositing ending to games and emulators, which may be helpful to spread both the SBCs and armbian...

Link to comment
Share on other sites

I just registered in the forum (hello everyone!) to thank you for this post, I had to do something quite similar to this to make GPU and VPU work on my Orange Pi plus.

 

First of all, I'm sorry, but I'm an Arch linux user. I don't like that much XFCE or desktop managers: maybe I'm old fashioned but I prefer configuring a small window manager (I'm using i3 right now). I'm more interested about what is inside the window than about the background, decoration, panels, etc. And (in my opinion) uninstalling stuff is normally more difficult (why does this depend on that?)

 

As my (our) device has only 1GB of RAM, I consider "memory frugality" even more important, but I don't want to lose VPU and GPU and i like watching videos. 

 

So... Thank you!!

Link to comment
Share on other sites

I just registered in the forum (hello everyone!) to thank you for this post, I had to do something quite similar to this to make GPU and VPU work on my Orange Pi plus.

 

First of all, I'm sorry, but I'm an Arch linux user. I don't like that much XFCE or desktop managers: maybe I'm old fashioned but I prefer configuring a small window manager (I'm using i3 right now). I'm more interested about what is inside the window than about the background, decoration, panels, etc. And (in my opinion) uninstalling stuff is normally more difficult (why does this depend on that?)

 

As my (our) device has only 1GB of RAM, I consider "memory frugality" even more important, but I don't want to lose VPU and GPU and i like watching videos. 

 

So... Thank you!!

Hi. Which kernel do you use with Archlinux? Can you describe how to get OpenGL and hw accel to work in Arch, please.

Link to comment
Share on other sites

Hi. Which kernel do you use with Archlinux? Can you describe how to get OpenGL and hw accel to work in Arch, please.

Hi, 

 

I'm an arch linux user on x86, if I'm not wrong arch linux would need a mainline kernel and graphics are not working in that one.

Link to comment
Share on other sites

I am a sailor and use OpenCPN for the navigation chart plotter. The charts load and zoom much faster with hardware openGL/ or ES.

It has a way to display rendering technique and frames/sec and is barely useful without acceleration. It is very nice with it, even on the Orange Pi One. But I will use the Opi PC Plus for my final installation.

 

I compiled opencpn(4.2 and 4.4) on the default Jessie desktop of both 5.05 and 5.10. I will be recompiling on 5.17 soon.

 

So it is not only games and display managers that use openGL and hardware acceleration.

Thank you all for armbian and the rest.

Link to comment
Share on other sites

hi does not work in the banana pi m1?

made step by step tutorial

error in the compilation section Step # 3: Build GL wrapper exist 2 error

not working # glxinfo

Banana Pi M1 has the same SoC as banana Pi Pro, so it should work just as well. I cannot help you without the exact error message you're getting. Please post the exact command which fails and its output.

 

Note that Zador has already integrated this GL wrapper in mainstream build script, so it will be available in desktop version of Armbian soon.

Link to comment
Share on other sites

Hi. Which kernel do you use with Archlinux? Can you describe how to get OpenGL and hw accel to work in Arch, please.

You will need hardware GLES for glshim OpenGL wrapper, so you'll need sunxi-mali driver which only works with 3.x legacy kernel. glshim itself is just a library which can be built for virtually any distro (it was originally developed for Angstrom Linux).

Link to comment
Share on other sites

I am a sailor and use OpenCPN for the navigation chart plotter. The charts load and zoom much faster with hardware openGL/ or ES.

It has a way to display rendering technique and frames/sec and is barely useful without acceleration. It is very nice with it, even on the Orange Pi One. But I will use the Opi PC Plus for my final installation.

Good to know. Feel free to report any OpenCPN-specific bugs if you encounter any. I cannot guarantee anything but I will take a look.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines