Re: [meta-ti] Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

["Andrew F. Davis" <afd@ti.com>]

On 5/17/20 5:22 PM, Luca wrote:
> Probably the topic was too broad,
> 
> I think I got a partial solution and here you have a partial reply:
> 
> To my understanding, when using OpenGL and EGL there are two common
> scenarios:
> 
>  1. The provider for both GL and EGL is mesa: that works fine in our case
>  2. The provider for GL is mesa (specifically mesa-gl) and the provider
>     for EGL is a GPU user space module (in our case /ti-sgx-ddk-um):
>     /that at the moment is giving some bitbake errors due to a conflict.
>     Indeed both mesa-gl and ti-sgx-ddk-um provide the header
>     khrplatform.h and the library libglapi
> 
> Since my goal is to use the GPU provided by the am335x SOC I have to
> focus on the second one.
> 
> To setup the second scenario in a .conf file we have to set://
> //
> 
> IMAGE_INSTALL_append = " ti-sgx-ddk-km ti-sgx-ddk-um libdrm"
> PREFERRED_PROVIDER_virtual/egl = "ti-sgx-ddk-um"
> PREFERRED_PROVIDER_virtual/libgles1= "ti-sgx-ddk-um"
> PREFERRED_PROVIDER_virtual/libgles2 = "ti-sgx-ddk-um"
> PREFERRED_PROVIDER_virtual/libgl = "mesa-gl"
> PREFERRED_PROVIDER_virtual/mesa = "mesa-gl"
> PREFERRED_PROVIDER_libgbm = "libgbm"
> PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev"


libgbm is a virtual as it has multiple optional providers, one of which
is ti-sgx-ddk-um, our standalone libgbm has been deprecated, use the one
provided by ti-sgx-ddk-um:

PREFERRED_PROVIDER_virtual/libgbm = "ti-sgx-ddk-um"

Also it can be argued virtual/mesa should *not* be a virtual as there is
only one provider: Mesa. No one should depend on 'mesa' either, what
programs really want is one of the API/libraries provided by the mesa
software package (GL, GLES1, GLES2, GLX, etc.) and they should DEPENDS
on those specifically by name, so they can be provided by the
appropriate providing software package for the given system as defined
by PREFERRED_PROVIDER.

I have been working slowly to remove all references to virtual/mesa
upstream in OE, and replace them with the exact needed API/lib.


>  
> Moreover, since TI provides its own version of libgbm, in a
> mesa-gl_%.bbappend we set
> 
> PACKAGES_remove = "libgbm"
> PACKAGES_remove = "libgbm-dev"
> EXTRA_OECONF_remove = "--enable-gbm"
> /
> (Reference Automotive Grade Linux
> <https://gerrit.automotivelinux.org/gerrit/gitweb?p=AGL/meta-agl.git;a=blob;f=meta-agl-bsp/meta-ti/recipes-graphics/mesa/mesa-gl_%25.bbappend;h=a5a69513ab927aa054d358aa699845fc435012a6;hb=HEAD)>)
> /
> This way the "providers should be set up properly" but unfortunately
> (depending on the openembedded-core we are using) we could get the error:
> "file /usr/include/KHR/khrplatform.h is installed by
> both ti-sgx-ddk-um and mesa-gl, aborting"
> 
> This seems to be caused by mesa commit 87c156183
> <https://lists.yoctoproject.org/g/meta-ti/topic/build_core_image_weston_for/87c1561> that
> installs the header khrplatform.h even when mesa should provide only opengl.
> In other BSP layers the issue has been fixed preventing the GPU module
> to install the header (See meta-xilinx
> <https://www.yoctoproject.org/pipermail/meta-xilinx/2019-November/004555.html>).
> I don't know if it is the proper solution, but I tried to implement it
> and I patched the Makefile in omap5-sgx-ddk-um-linux, results:
> - The error related to khrplatform.h is gone
> - I get another similar error about libglapi.so being installed by
> both ti-sgx-ddk-um and mesa-gl. Should I disable its installation too?
> Not sure...
> 
> Any suggestion?
> 


This is actually a bit complicated right now, you cannot use both
ti-sgx-ddk-um and mesa-gl together, as you have found out they provide
many of the same things and overlap in function.

EGL provides window system (x11, wayland, gbm, surfaceless) integration
for both GL and GLES (and OpenVG), but our EGL implementation only
supports GLES, as that is all our GPUs support (at least on AM335x).
Full desktop GL would have to be done using SW rendering, which is
probably not what you want.

The idea behind 'mesa-gl' was to allow this SW rendering for OpenGL
without interfering with the real HW GLES-only stack. I'm not convinced
this ever really worked with EGL.. (maybe GLX+libgl.so but not sure)

The EGL implementation, plus things like libglapi.so, and all the API
headers are common to both GL and GLES, so they just don't mix well when
provided by two different stacks. It is hard to make a well defined
separation point that would still allow runtime selection.

So my question back is then, why are you trying to pull in 'mesa' and/or
'mesa-gl'? Weston works fine with the stack we provide in ti-sgx-ddk-um.

Andrew


> Regards
> Luca
> 
> 
>