View Full Version : OpenGL dev on the Raspberry Pi3 platform and the Rasbian 8.0 distrib

The Little Body
04-08-2016, 03:34 PM

I just begin OpenGL dev on a Raspberry Pi platform

I have first installed GL and GLUT libs and devel packages and have run glxgears on my raspberry Pi3 platform with the Rasbian 8.0 distrib

I have run glxgears for to have an idea about the performance of OpenGL on it and find "bads" performances :(
(OK, glxgears is not really a good benchmark test but it generally give a good idea about defaults OpenGL performances on a specific platform)

pi@piYann:~/Devel/OpenGL $ glxgears
41 frames in 5.0 seconds = 8.140 FPS
98 frames in 5.0 seconds = 19.563 FPS
101 frames in 5.0 seconds = 20.129 FPS
99 frames in 5.0 seconds = 19.664 FPS

I have next runned the glxGears with --info parameter for to see what is the driver used

pi@piYann:~/Devel/OpenGL $ glxgears -info
GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)
GL_VERSION = 3.0 Mesa 11.1.0
GL_VENDOR = VMware, Inc.
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color ...

The xdpyinfo utility give me this that seem me "not too bad" :

pi@piYann:~ $ xdpyinfo
name of display: :0.0
version number: 11.0
vendor string: The X.Org Foundation
vendor release number: 11702000
X.Org version: 1.17.2
maximum request size: 16777212 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
depth 4, bits_per_pixel 8, scanline_pad 32
depth 8, bits_per_pixel 8, scanline_pad 32
depth 15, bits_per_pixel 16, scanline_pad 32
depth 16, bits_per_pixel 16, scanline_pad 32
depth 24, bits_per_pixel 32, scanline_pad 32
depth 32, bits_per_pixel 32, scanline_pad 32
keycode range: minimum 8, maximum 255
focus: window 0x180ab68, revert to Parent
number of extensions: 28
Generic Event Extension
default screen number: 0
number of screens: 1

screen #0:
dimensions: 1360x768 pixels (360x203 millimeters)
resolution: 96x96 dots per inch
depths (7): 16, 1, 4, 8, 15, 24, 32
root window id: 0x1aa
depth of root window: 16 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 64
preallocated pixels: black 0, white 65535
options: backing-store WHEN MAPPED, save-unders NO
largest cursor: 1360x768
current input event mask: 0x7a003f
KeyPressMask KeyReleaseMask ButtonPressMask
ButtonReleaseMask EnterWindowMask LeaveWindowMask
StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask
FocusChangeMask PropertyChangeMask
number of visuals: 61
default visual id: 0x21
visual id: 0x21
class: TrueColor
depth: 16 planes
available colormap entries: 64 per subfield
red, green, blue masks: 0xf800, 0x7e0, 0x1f
significant bits in color specification: 8 bits

Is the Gallium driver a good driver for the Raspberry Pi3 platform or where can I find a better graphic driver for it ?

Because only about 20 fps seem me really too slow, is the VideoCore IV GPU as "slow" as this ?
(on other side, the Raspberry Pi3 is really very very small and cheap, so this is perhaps normal ...)

The Little Body
04-08-2016, 04:31 PM
I have used the raspi-config utility for to activate the experimental OpenGL driver and performances are really very better :)

pi@piYann:~ $ glxgears
Running synchronized to the vertical refresh.
The framerate should beapproximately the same as the monitor refresh rate.
298 frames in 5.0 seconds = 59.561 FPS
294 frames in 5.0 seconds = 58.622 FPS

pi@piYann:~ $ glxgears -info
GL_RENDERER = Gallium 0.4 on VC4
GL_VERSION = 2.1 Mesa 11.1.0
GL_VENDOR = Broadcom
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color ...

=> the VideoCore IV GPU don't seem me now as slow as this because this "bench" is clearly limited by the vertical refresh rate at 60 Hz :)

But with this experimental hardware accelleration enabled, my screen flash very often to black :(
(it seem that only move the mouse is suffisant for normally redisplay the screen but this is very too frequent for to can really live with this ...)

=> is this "normal" or it's my screen that can be problematic with the vertical refresh when the hardware accelleration is enable ?
(the raspi-config say that it is an experimental driver, so this is certainly only a temporal problem who will be speedly resolved)

The Little Body
04-08-2016, 07:06 PM
This seem to can be resolved with a transformator that can handle a power of more than 2A

I have only replace the 2.0A transformator with 2.4A transformator and the screen go to black "not as frequent as before" with the experimental OpenGL driver

But this is not really fonctionnal because the screen go always sometimes to black but at a very very slower frequence that before with the "only" 2.0A transformator
(say only after somes minuts with the 2.4A transformator instead each second with the 2.0A transformator)

I have too enable the Overscan option into the "Configuration du Raspberry Pi" utility because the picture is trembling and wavy on the screen without this option

So now, I think to can begin to work about an OpenGL viewer that can mix the video given by the Rasberry Pi Camera Module with one or more external videos decoded via the FFMPEG / libav library on my new Raspberry Pi 3 platform :)

PS : I end to "squat" this "OpenGL coding: beginners" forum with my specific Raspberry Pi problem because this is not really a beginner problem but more a subject for the "OpenGL drivers" forum :)