Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

[Luca]

[-- Attachment #1: Type: text/plain, Size: 3159 bytes --]

Hi all,

I am trying to get Weston working with the GPU SGX530 enabled.
Basically I would like to get the same results described in BeagleBoneBlack/SGX + Qt EGLFS + Weston ( https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston ) using Yocto.

At the moment I am using:

* meta-ti: branch zeus, commit 1dd4558 (with a fixed .wks see https://lists.yoctoproject.org/g/meta-ti/message/12916). I will probably switch to tag ti2020.00 or previous if needed
* poky: branch zeus, commit ca9cc50
* meta-openembedded: branch zeus, commit 44e458f
* A very simple patch applied by a ti-sgx-ddk-km_%.bbappend to set "$(1)_compiler_preferred_target := arm-linux-gnueabihf" when arm-poky-linux-gnueabi is used (Similar to the patch described in https://www.yoctoproject.org/pipermail/meta-ti/2019-September/012193.html but with arm-poky-linux-gnueabi instead of arm-oe-linux-gnueabi ).

The board seems to boot properly if I use core-image-base but when I run bitbake core-image-weston I get some bitbake errors due to libgl.

*First approach*
In my local.conf

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/mesa = "ti-sgx-ddk-um"

After taking a look to https://code.qt.io/cgit/yocto/meta-boot2qt.git meta-ti-extras layer dropped with commit 17747110065d6d1482fb5786773c27d78f7c8bac I added in my ti-sgx-ddk-um_%.bbappend

PROVIDES += "virtual/mesa"

Anyway when I run bitbake core-image-weston, it stops immediately with the error:
Nothing PROVIDES 'virtual/libgl' (but /home/qem/Yocto/poky-zeus/meta/recipes-graphics/clutter/clutter-1.0_1.26.2.bb, /home/qem/Yocto/poky-zeus/meta/recipes-graphics/cairo/cairo_1.16.0.bb, /home/qem/Yocto/poky-zeus/meta/recipes-graphics/libepoxy/libepoxy_1.5.3.bb DEPENDS on or otherwise requires it)
mesa-gl PROVIDES virtual/libgl but was skipped: PREFERRED_PROVIDER_virtual/libgl set to mesa, not mesa-gl
mesa PROVIDES virtual/libgl but was skipped: PREFERRED_PROVIDER_virtual/libgles1 set to ti-sgx-ddk-um, not mesa

*Second approach*
Considering https://www.yoctoproject.org/pipermail/meta-ti/2016-October/009100.html I deleted the  In my ti-sgx-ddk-um_%.bbappend and modified my local.conf setting

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_libgbm = "libgbm"
PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev"

But bitbake stops with the same error of the first approach.

*Doubts about Weston and OpenGL*
Looking for a solution I sow https://patchwork.openembedded.org/patch/152082/ and http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-graphics/wayland/weston_4.0.0.imx.bb?h=thud and I am wondering if "REQUIRED_DISTRO_FEATURES = "opengl"" is strictly required for Weston 7 or if a solution similar to the one implemented for Weston 4 would be viable.

Any suggestion or consideration would be much appreciated

Regards

Luca

[-- Attachment #2: Type: text/html, Size: 4706 bytes --]

Re: Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

[Luca]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

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:
* The provider for both GL and EGL is mesa: that works fine in our case
* 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"

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?

Regards
Luca

[-- Attachment #2: Type: text/html, Size: 3772 bytes --]

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

[Andrew F. Davis]

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
> 
> 
> 

Re: Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

[Luca]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

Hi Andrew,

thanks a lot for the clarifications and updated info.
It seems I was relaying on outaded and/or incomplete info.

> 
> 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"
> 

Perfect, thanks. I was just starting to understand that the standalone libgbm has been deprecated reading http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Graphics/Migration_From_Prior_Releases.html#from-processor-sdk-6-1-to-6-2-for-am3-4-5-6

> 
> 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.

I understood that full GL would have been done using SW rendering, but I thought it was the only way to get Weston working.

> 
> 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.
> 

Your question is very legitimate.
I was pulling mesa-gl just to fulfil Weston dependencies, but thank to your info I now understand that I was doing it the wrong way.
Then the question is:
How should I set the providers to get Weston working fine with ti-sgx-ddk-um?

Regards
Luca

[-- Attachment #2: Type: text/html, Size: 2763 bytes --]

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

[Denys Dmytriyenko]

On Mon, May 18, 2020 at 12:19:19PM -0700, Luca wrote:
> Hi Andrew,
> 
> thanks a lot for the clarifications and updated info.
> It seems I was relaying on outaded and/or incomplete info.
> 
> > 
> > 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"
> > 
> 
> Perfect, thanks. I was just starting to understand that the standalone 
> libgbm has been deprecated reading 
> http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Graphics/Migration_From_Prior_Releases.html#from-processor-sdk-6-1-to-6-2-for-am3-4-5-6
> 
> > 
> > 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.
> 
> I understood that full GL would have been done using SW rendering, but I 
> thought it was the only way to get Weston working.
> 
> > 
> > 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.
> > 
> 
> Your question is very legitimate.
> I was pulling mesa-gl just to fulfil Weston dependencies, but thank to your 
> info I now understand that I was doing it the wrong way.
> Then the question is:
> How should I set the providers to get Weston working fine with ti-sgx-ddk-um?

Weston does not require mesa or mesa-gl.

Your distro should set all PREFERRED_PROVIDERs and DISTRO_FEATURES properly.

E.g. Arago Project distro in meta-arago, used by TI Processor SDKs does:

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/libgbm = "ti-sgx-ddk-um"
PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"

DISTRO_FEATURES_remove = "x11"
DISTRO_FEATURES_append = " wayland opengl"

-- 
Denys

Re: Build core-image-weston for beaglebone/am335x with GPU SGX530 enabled

[Luca]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Hi Denys,

thanks a lot for the clarifications.

> 
> Weston does not require mesa or mesa-gl.

Sure, I will try to reformulate what I meant:

Weston requires opengl "REQUIRED_DISTRO_FEATURES = "opengl"" and I thought that this meant that libgl was required,
therefore I tried to use mesa-gl that provides virtual/libgl.

Now I know I was wrong, but what is providing opengl if libgl is not available?
Probably I don't get the proper meaning of "REQUIRED_DISTRO_FEATURES = "opengl"".

> 
> E.g. Arago Project distro in meta-arago, used by TI Processor SDKs does:
> 

Ok, I will keep meta-arago ( http://arago-project.org/git/?p=meta-arago.git;a=summary ) as reference for my distro layer when using meta-ti as bsp layer.

Regards
Luca

[-- Attachment #2: Type: text/html, Size: 987 bytes --]