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 > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12941): https://lists.yoctoproject.org/g/meta-ti/message/12941 Mute This Topic: https://lists.yoctoproject.org/mt/74137718/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
