dimag0g Posted June 15, 2016 Posted June 15, 2016 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 6
Gravelrash Posted June 15, 2016 Posted June 15, 2016 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/ 1
tkaiser Posted June 16, 2016 Posted June 16, 2016 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?
Igor Posted June 16, 2016 Posted June 16, 2016 @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.
phelum Posted June 16, 2016 Posted June 16, 2016 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
rellla Posted June 16, 2016 Posted June 16, 2016 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 1
dimag0g Posted June 16, 2016 Author Posted June 16, 2016 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.
RagnerBG Posted June 16, 2016 Posted June 16, 2016 # 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?
dimag0g Posted June 16, 2016 Author Posted June 16, 2016 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.
tkaiser Posted June 16, 2016 Posted June 16, 2016 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 )
RagnerBG Posted June 16, 2016 Posted June 16, 2016 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.
jernej Posted June 16, 2016 Posted June 16, 2016 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. 1
dimag0g Posted June 16, 2016 Author Posted June 16, 2016 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)
zador.blood.stained Posted June 16, 2016 Posted June 16, 2016 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.
tkaiser Posted June 16, 2016 Posted June 16, 2016 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
jernej Posted June 16, 2016 Posted June 16, 2016 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.
dimag0g Posted June 16, 2016 Author Posted June 16, 2016 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.
jernej Posted June 16, 2016 Posted June 16, 2016 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.
dimag0g Posted June 16, 2016 Author Posted June 16, 2016 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).
jock Posted June 23, 2016 Posted June 23, 2016 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...
The_Loko Posted June 24, 2016 Posted June 24, 2016 What's the difference between installing this and libgl1-mesa-dri package? I installed the latter as I needed OpenGL for some applications like the OpenCV camera viewer and it seems to work fine.
dimag0g Posted July 23, 2016 Author Posted July 23, 2016 What's the difference between installing this and libgl1-mesa-dri package? Hardware acceleration
opengu Posted August 1, 2016 Posted August 1, 2016 hi does not work in the banana pi m1?made step by step tutorialerror in the compilation section Step # 3: Build GL wrapper exist 2 errornot working # glxinfo
brunorro Posted August 3, 2016 Posted August 3, 2016 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!!
borombo Posted August 3, 2016 Posted August 3, 2016 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.
brunorro Posted August 5, 2016 Posted August 5, 2016 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.
svkatielee Posted August 10, 2016 Posted August 10, 2016 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. 3
dimag0g Posted August 14, 2016 Author Posted August 14, 2016 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.
dimag0g Posted August 14, 2016 Author Posted August 14, 2016 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).
dimag0g Posted August 14, 2016 Author Posted August 14, 2016 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.
Recommended Posts