Failed to add service - already in use?

[daniwenne]

[alarm@alarmpi gl4es]$ LD_LIBRARY_PATH=./lib glxgears
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Dec 16 2020 20:00:31
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libbcm_host.so
LIBGL: loaded: libvcos.so
LIBGL: loaded: libbrcmGLESv2.so
LIBGL: loaded: libbrcmEGL.so
LIBGL: Using GLES 2.0 backend
* failed to add service - already in use?

I'm using Arch Linux armv7 on rpi4. I built gl4es like this: cmake .. ; make-j4, as pointed out in #129 . If I build it the same way on raspbian or manjaro it works just fine.

[ptitSeb]

Don't build for PI, use a generic (or ODROID) build. PI build are for legacy driver (using libbcm_host.so) that is not used anymore on PI4.

[daniwenne]

Don't build for PI, use a generic (or ODROID) build. PI build are for legacy driver (using libbcm_host.so) that is not used anymore on PI4.

I tried both generic and ODROID profiles, it still won't work :-( Commenting dtoverlay=vc4-fkms-v3d also didn't work.

[ptitSeb]

I checked the CMakeList, the option you need to set to OFF is BCMHOST (there is no RPI profile on gl4es). Use ccmake to have an interactive way of changing option of an already configured cmake project.

Without BCMHOST, you will not have this line LIBGL: loaded: libbcm_host.so and it should work.

[daniwenne]

Just did that, this is what I got:

[alarm@alarmpi gl4es]$ LD_LIBRARY_PATH=./lib glxgears
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Dec 18 2020 00:03:08
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libGLESv2.so
LIBGL: loaded: libEGL.so
LIBGL: Using GLES 2.0 backend
* failed to add service - already in use?

Now it won't load libbcm_host.so and libvcos.so, but still won't work. This issue seems to be related: #134 . The user that created this issue managed to get it working by disabling the broadcom driver, although I haven't been able to figure out how he did it.

[ptitSeb]

I suspect your GLES2 driver is not correctly installed on your system. Does other GLES2 app works (like es2gears or glmark2-es2?)

[daniwenne]

They're working just fine:

[alarm@alarmpi 01-es2sdlgears]$ ./demo
vertex shader info: 
fragment shader info: 
info: 
308 frames in 5.0 seconds = 61.526 FPS
301 frames in 5.0 seconds = 60.020 FPS
[alarm@alarmpi 01-es2sdlgears]$ glmark2-es2
=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Broadcom
    GL_RENDERER:   V3D 4.2
    GL_VERSION:    OpenGL ES 3.1 Mesa 20.3.0
=======================================================
[build] use-vbo=false: FPS: 268 FrameTime: 3.731 ms
[...]
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 149 FrameTime: 6.711 ms
=======================================================
                                  glmark2 Score: 171 
=======================================================

I'll try compiling mesa myself, maybe the package for my distro is broken.

[sairuk]

gl4es may be picking picking up the old libs from /opt/vc/lib instead of the MESA libs. You can see this through an strace of the process but it would be helpful if the full path for the loaded libs was in the output

I am on raspbian and built gl4es with the ODROID config as per doco.

condition

LD_LIBRARY_PATH=/home/games/devel/com.github/gl4es/lib/ glxgears
LIBGL: Initialising gl4es
LIBGL: v1.1.4 built on Dec 27 2020 14:09:15
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libGLESv2.so
LIBGL: loaded: libEGL.so
LIBGL: Using GLES 2.0 backend
* failed to add service - already in use?

strace output to look for

openat(AT_FDCWD, "/opt/vc/lib/libGLESv2.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/opt/vc/lib/libEGL.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/opt/vc/lib/libbcm_host.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/opt/vc/lib/libvchiq_arm.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/opt/vc/lib/libvcos.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3

incorrect library for mesa

$ LD_LIBRARY_PATH=/home/games/devel/com.github/gl4es/lib/ strace glxgears 2>&1 | grep libGLESv2.so
openat(AT_FDCWD, "/opt/vc/lib/libGLESv2.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3

correct library for mesa

$ LD_LIBRARY_PATH=/home/games/devel/com.github/gl4es/lib/:/usr/lib/arm-linux-gnueabihf/ strace glxgears 2>&1 | grep libGLESv2.so
openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libGLESv2.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3

I've found I can work around this 2 ways

Prioritise the gl4es path and then include the MESA libs path as secondary

LD_LIBRARY_PATH=/home/games/devel/com.github/gl4es/lib/:/usr/lib/arm-linux-gnueabihf/ glxgears
LIBGL: Initialising gl4es
LIBGL: v1.1.4 built on Dec 27 2020 14:09:15
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libGLESv2.so
LIBGL: loaded: libEGL.so
LIBGL: Using GLES 2.0 backend
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax  detected and used
LIBGL: Extension GL_EXT_draw_buffers  detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer  detected
LIBGL: Extension GL_OES_element_index_uint  detected and used
LIBGL: Extension GL_OES_packed_depth_stencil  detected and used
LIBGL: Extension GL_OES_depth24  detected and used
LIBGL: Extension GL_OES_rgb8_rgba8  detected and used
LIBGL: Extension GL_EXT_multi_draw_arrays  detected
LIBGL: Extension GL_EXT_texture_format_BGRA8888  detected and used
LIBGL: Extension GL_OES_depth_texture  detected and used
LIBGL: Extension GL_OES_texture_stencil8  detected and used
LIBGL: Extension GL_EXT_texture_rg  detected and used
LIBGL: Extension GL_OES_texture_float  detected and used
LIBGL: Extension GL_OES_texture_half_float  detected and used
LIBGL: Extension GL_EXT_color_buffer_float  detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth  detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Extension GL_OES_standard_derivatives  detected and used
LIBGL: Max texture size: 4096
LIBGL: Max Varying Vector: 16
LIBGL: Texture Units: 16/16 (hardware: 16), Max lights: 8, Max planes: 6
LIBGL: Max Color Attachments: 4 / Draw buffers: 4
LIBGL: Hardware vendor is Broadcom
LIBGL: GLSL 300 es supported
LIBGL: GLSL 310 es supported and used
LIBGL: sRGB surface supported
LIBGL: EGLImage from Pixmap supported
LIBGL: EGLImage to Texture2D supported
LIBGL: EGLImage to RenderBuffer supported
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/home/games
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.

or force the libraries through the env vars in https://github.com/ptitSeb/gl4es/blob/master/USAGE.md

export LIBGL_EGL=/usr/lib/arm-linux-gnueabihf/libEGL.so
export LIBGL_GLES=/usr/lib/arm-linux-gnueabihf/libGLESv2.so

[Kippykip]

export LIBGL_EGL=/usr/lib/arm-linux-gnueabihf/libEGL.so
export LIBGL_GLES=/usr/lib/arm-linux-gnueabihf/libGLESv2.so

Doing that fixed it for me, but anyone know why it's using the wrong path from the get go on an Rpi4? I should note I am using one of those touchscreen builds of Raspbian

EDIT: Aha! Worked it out Open a fresh terminal (pi@raspberrypi~ $) sudo apt install mesa-utils mesa-utils-extra build-essential git cmake git clone https://github.com/ptitSeb/gl4es cd gl4es mkdir build cd build cmake .. -DODROID=1 -DBCMHOST=0 -DCMAKE_BUILD_TYPE=RelWithDebInfo make -j4

Now when I do: LD_LIBRARY_PATH=/home/pi/gl4es/lib/ glxgears I get results without having to do the above export thing!