Kivy on NanoPi 2 Fire - Slow OpenGL Software Renderer

[Shane Burgess]

I am trying to set up Kivy wity Python 3.4 on Debian Jessie on a NanoPi 2 Fire (a single-board computer like Raspberry Pi - http://nanopi.io/nanopi2-fire.html). Kivy applications do run, but they respond very slowly (2-3 fps). My hypothesis is that the system does not have a hardware OpenGL driver and is doing everything in software. Although this may not be a Kivy-specific problem, I'm including information below in hopes that someone more experienced might point me in the right direction.

I tried installing Kivy using the wiki's Debian instructions, and also using the Raspberry Pi instructions, but the results were the same.

Results from Kivy's report.py:

fa@NanoPi2:/usr/local/lib/python3.4/dist-packages/kivy/tools$ python3 report.py
REPORT posted at https://gist.github.com/2403bd1e0c1cfea6eb20a09e6a17e017

Running Kivy's benchmark.py:

fa@NanoPi2:/usr/local/lib/python3.4/dist-packages/kivy/tools$ python3 benchmark.py
[INFO ] [Logger ] Record log in /home/fa/.kivy/logs/kivy_17-02-03_0.txt
[INFO ] [Kivy ] v1.9.2.dev0, git-309ac12, 20170202
[INFO ] [Python ] v3.4.2 (default, Oct 8 2014, 14:38:51)
[GCC 4.9.1]
[INFO ] [Factory ] 193 symbols loaded
[INFO ] [Image ] Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO ] [Text ] Provider: sdl2
[INFO ] [OSC ] using <multiprocessing> for socket

======================================================================
Kivy Benchmark v1
======================================================================

System informations
-------------------
OS platform : linux
Python EXE : /usr/bin/python3
Python Version : 3.4.2 (default, Oct 8 2014, 14:38:51)
[GCC 4.9.1]
Python API : 1013
Kivy Version : 1.9.2.dev0
Install path : /usr/local/lib/python3.4/dist-packages/kivy
Install date : Thu Feb 2 09:25:32 2017

OpenGL informations
-------------------
[INFO ] [Window ] Provider: sdl2(['window_egl_rpi'] ignored)
[INFO ] [GL ] Using the "OpenGL" graphics system
[INFO ] [GL ] Backend used <gl>
[INFO ] [GL ] OpenGL version <b'2.1 Mesa 10.3.2'>
[INFO ] [GL ] OpenGL vendor <b'Mesa Project'>
[INFO ] [GL ] OpenGL renderer <b'Software Rasterizer'>
[INFO ] [GL ] OpenGL parsed version: 2, 1
[INFO ] [GL ] Shading version <b'1.20'>
[INFO ] [GL ] Texture max size <16384>
[INFO ] [GL ] Texture max units <32>
[INFO ] [Window ] auto add sdl2 input provider
[INFO ] [Window ] virtual keyboard not allowed, single mode, not docked
GL Vendor: b'Mesa Project'
GL Renderer: b'Software Rasterizer'
GL Version: b'2.1 Mesa 10.3.2'

Benchmark
---------
1/8 Core: button creation (10000 * 10 a-z) 46.993413
2/8 Core: button creation (10000 * 10 a-z), with Clock.tick [INFO ] [GL ] NPOT texture support is available
57.878476
3/8 Core: label creation (10000 * 10 a-z) 33.569446
4/8 Core: label creation (10000 * 10 a-z), with Clock.tick 42.419741
5/8 Widget: creation (10000 Widget) 11.400269
6/8 Widget: creation (10000 Widget + 1 root) 13.320312
7/8 Widget: event dispatch (1000 on_update in 10*1000 Widget) 0.243442
8/8 Widget: empty drawing (10000 Widget + 1 root) 0.006345

Result: 205.831445

Running the glxgears utility (apt-get install mesa-demos), it gets 90 fps on a 300x300 window, but only 17 fps at 1024x600 (fullscreen). I don't know if this proves anything regarding the existence or non-existence of hardware OpenGL drivers in the system.

From http://wiki.cchtml.com/index.php/Glxgears_is_not_a_Benchmark#Check_fglrx_install_status
it says "If glxinfo reports direct rendering as "no" or the OpenGL renderer as "Mesa", then you are currently using software (un-accelerated) rendering." According to that, the system is using software rendering.

> glxinfo | grep 'OpenGL\|direct'
direct rendering: Yes
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 2.1 Mesa 10.3.2
OpenGL shading language version string: 1.20
OpenGL extensions:

Is it common to only have software-based OpenGL rendering on single-board computers? Is it difficult to add hardware OpenGL support? I know the NanoPi 2 is not as popular as the Raspberry Pi, but I haven't worked much with either of them, so any information is greatly appreciated!

For reference, I have also come across this forum post on getting hardware OpenGL drivers configured for a Mali GPU (this is what the NanoPi 2 Fire has). I haven't tried to follow this process yet, but I may later if no easier solution comes up. https://forum.armbian.com/index.php/topic/1420-opengl-on-mali-gpu-bananapi-orangepi-pc-etc/

[Marco Hinz]

Hello,

i have the same experience with M2 and M3 caused of missing GPU i think.
It would be wunderful if there is a way to run kivy von M2 or M3 with better performance.
At the moment it is not usable and i have to use raspberry 3 for that.

Any ideas?

Thank you

Marco

[ZenCODE]

From my (very) limited understanding here, I doubt the problem here is Kivy. It is the operating system which supplies the OpenGL renderer: all Kivy does is request one. I would suggest the first steps is to ensure you have the appropriate drivers installed. Then, use choose another arb app that uses OpenGL. How does that perform?

Essentially, in order to demonstrate that it is a Kivy specific, we would need to establish:

* Kivy is very slow
* Other OpenGL apps are fast

So please can we get some metrics on those two cases?

Thanks

[Shane Burgess]

I am pretty sure that you are right. I have been unable to find an OpenGL renderer that uses the hardware GPU on the NanoPi 2 Fire, and it is most likely the case that all OpenGL rendering on this computer will be slow. That being said, Kivy is surprisingly slow, as the glxgears program at least runs at 17fps fullscreen, whereas a simple Kivy program never surpasses ~5fps. I'm not particularly concerned about why it's so much slower, as for my purposes, 17fps is still much too slow.

I agree with Marco that using a Raspberry Pi is the best option right now for Kivy, or anything requiring hardware acceleration.