libraspberrypi0 does not ship EGL/GLES while rpi-update confusingly installs them

[gkiagia]

I recently needed to test something with GStreamer on a raspberry pi. So, I went to raspberrypi.org and downloaded the recommended raspbian image. I tried to build GStreamer on it, but surprisingly, the build failed even to configure, complaining about EGL/GLES missing.

To my surprise, this image comes with no EGL/GLES libraries in /opt/vc/lib. Instead, it ships libbrcmEGL.so / libbrcmGLESv2.so. I have seen previous tickets that say this is intentional, like:

• https://github.com/RPi-Distro/firmware/issues/3
• https://github.com/RPi-Distro/repo/issues/80

But honestly... it makes no sense to me.

Confusingly enough (!), rpi-update installs those libraries. I had so much trouble trying to figure out why every other GStreamer developer I was talking to was able to build GStreamer and I wasn't. After two days of trying, we finally figured out it's rpi-update. See the whole thread here: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/577#note_137097

This is completely broken behaviour, please consider shipping all the libraries properly in the image. Not clashing with mesa is a poor excuse, especially since these libraries are installed in a different place in the system and you will get them anyway if you just run rpi-update. The proper way of not clashing with mesa is to use the debian alternatives system.

[XECDesign]

It will eventually be removed from rpi-update as well. gstreamer and qt will need to update to use the proper library names.

[ystreet]

Are you aware prefixing the EGL/GLESv2 libraries with brcm does not follow the recommended naming conventions set out by Khronos in https://www.khronos.org/registry/implementers_guide.html#libnames ?

[gkiagia]

Aside from the fact that it violates naming conventions, it's a massive pain for all the software that requires linking with GL. We've already been through a lot of pain over the years to support broadcom's GL stack and now it's getting even worse... All existing software that currently works correctly on the rpi will need to be modified. I just don't see the reason.

You could at least consider using some more standard way to install vendor-specific GL stack, like glvnd

[evelikov]

@XECDesign managing multiple EGL/GLES libraries can be troublesome. To address that GLVND (GL Vendor-Neutral Dispatch library) was introduced.

It provides all the frontend/user-facing libraries A while the vendor ships the backing implementation B.

A: libEGL.so + libGLES*.so (and libGL.s o + libOpenGL.so) B: libEGL$vendor.so (and libGLX$vendor.so)

Porting the vendor driver is trivial - see work done in Mesa (C) for reference.

C

• Initial implementation
• Couple of fixes

• New entry-points will need to be annotated as shown

Additionally, Debian (the base for RPi-Distro AFAICT) has GLVND packages in stable-backports, testing and unstable.

Can I suggest adhering to the existing conventions set by Khronos and porting the driver? It should easily fit into a single summer internship ;-)

Thanks Emil

[XECDesign]

Can I suggest adhering to the existing conventions set by Khronos and porting the driver? It should easily fit into a single summer internship ;-)

I'm sceptical it's as easy as that, since nothing ever is and the implementations are not at all interchangeable. But in either case who's going to finance this? Raspberry Pi have to allocate their resources in a way that makes sense and I don't see them putting a lot of them towards a legacy stack when the plan is to move away from it.

[XECDesign]

Just to rehash some of the points made in other places to avoid making it look like I'm just being dismissive.

The libraries are not interchangeable. You end up needing dispmanx contexts, calling bcm_init and so on. You can't just use an SDL context, for example. Your program either has to be written to target mesa or the legacy broadcom stack. You can't run a typical, platform-agnostic GL application with these drivers.

The transition was made because people repeatedly pointed this out and had problems with programs trying to link against the wrong set of libraries, giving undefined symbol errors, missing typedefs and so on.

If glvnd requires them to be interchangeable (I don't know if that's the case), it's a significant overhaul of all the plumbing involved. Without a doubt, that effort would better spent going forward with mesa/vc4 instead.

If your build targets either library, you have some ifdefs in there and a build system where you specify which libraries you end up targetting. You also have different include paths based on this selection.

If the libraries are not required to be interchangeable, then what's the point? You still need to have different code paths and a build system that determines which path is taken. Whose life is made easier?

The only difference now is that the build system needs to explicitly link against the intended library. You already have the mechanism to do this. The positive is that is avoid issues people were having before when they were trying to link against the wrong library.

There were alternative solutions proposed before glvnd and most of them were either not possible or not practical and we could go over those too, if necessary.

[evelikov]

A 2 minute look at hello_triangle highlights what you're saying.

Some libbcm_host.so calls like vc_dispmanx calls are interleaved with the seemingly normal EGL codebase.

strings libbrcmEGL.so shows a rather daunting truth - the legacy driver does not support essential extensions from 2013 - EGL_EXT_client_extensions, EGL_EXT_platform_base, EGL_KHR_debug, et al. Those are a requirement for GLVND :-(

If it did, the port would be a trivial - only tweak of the client/platform extension string handling. Everything else is coping files from the above commit.

On the $$$ side - I'm can envision a number of volunteers coming forward to hack it for free. Sadly that may not play along if an NDA is required.

Seems like moving RPi-distro to the Mesa vc4 driver would be very welcome and anticipated ;-)

[XECDesign]

On the $$$ side - I'm can envision a number of volunteers coming forward to hack it for free. Sadly that may not play along if an NDA is required.

Past experience shows that the number of people willing and able of doing something like this are few and far between. I don't think any of them would or should be willing to work for free. Opening things up has resulted in a few demos here and there but no progress towards and a more standard gles implementation.

Although, I am surprised by the number of contributors here: https://gitlab.freedesktop.org/mesa/mesa/commits/master/src/gallium/drivers/vc4