Re: [meta-ti] [kirkstone] mesa compilation failures when setting PREFERRED_PROVIDER for virtual/gpudriver = "ti-sgx-ddk-km"

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Mar 16, 2023 at 11:28:47AM -0500, Ryan Eatmon via lists.yoctoproject.org wrote:
> 
> The idea behind that patch series is to rework how we incorporate
> the GPU drivers with the various software pacakges.  So, yes, that
> will be how you will include the SGX stuff.
> 
> But...  There was another patch that rolled back the SGX support to
> just software rendering because we have not had the time to complete
> the work on fxiing the SGX drivers to work with the new integration
> methodology.

https://git.yoctoproject.org/meta-ti/commit/?id=d859c8c0916c8eb4b88ca8e0db7f9e5a846ba869


> So what you are trying to do, will not currently work in
> kirkstone/master until we finish the work to update the SGX code.
> 
> The only real option if you require the SGX GPU to work is to
> fallback to dunfell.
> 
> 
> On 3/16/2023 11:11, Danny Hadley via lists.yoctoproject.org wrote:
> >Hi all! I am trying to make sure my opengl-backed GUI application
> >is leveraging the most optimal graphics drivers on the beaglebone
> >black device and am running into yocto build failures.
> >
> >Based on what I can tell from the changes in 56be461 (https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb), <https://git.yoctoproject.org/meta-ti/commit/meta-ti-bsp/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb?h=kirkstone&id=56be4618abdde45649f0f92d383d5f44e5ec6efb),> I
> >should be able to have mesa compiled using the drivers provided
> >from the `ti-sgx-ddk-km` recipe by setting my preferred provider
> >for the `virtual/gpudriver` as such:
> >
> >```
> >
> >PREFERRED_PROVIDER_virtual/gpudriver = "ti-sgx-ddk-km"
> >
> >```
> >
> >I'm not sure if this is the correct way to go about what I am
> >trying to do, or if it is even necessary to ensure my application
> >is using the best hardware it can (which is ultimately the goal).
> >Either way, with the variable mentioned above set to
> >`ti-sgx-ddk-km`, the mesa.do_compile step fails with what I
> >believe are linker errors. This is an example of what I am seeing
> >in my logs:
> >
> >```
> >
> >/<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function `PVRDRIReleaseBuffer':
> >2023-03-15T19:19:43.7831698Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1055:
> >undefined reference to `PVRDRIBufferDestroy'
> >2023-03-15T19:19:43.7832402Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld:
> >src/gallium/frontends/sgx/libsgx.a.p/pvrdri.c.o: in function
> >`PVRDRIAllocateBuffer':
> >2023-03-15T19:19:43.7833062Z | /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1027:
> >undefined reference to `PVRDRIBufferCreate'
> >2023-03-15T19:19:43.7833813Z | /<my-path-to-yocto>/tmp/work/beaglebone-poky-linux-gnueabi/mesa/2_22.0.3+pvr-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.3.0/ld: /usr/src/debug/mesa/2_22.0.3+pvr-r0/build/../git/src/gallium/frontends/sgx/pvrdri.c:1037:
> >undefined reference to `PVRDRIBufferGetName'