Re: [EXTERNAL] Re: [PATCH] ti-sgx-ddk-um: update SRCREV to pick up Mesa-based EGL/GLES libraries

[Denys Dmytriyenko <denys@ti.com>]

On Wed, Oct 30, 2019 at 11:14:34AM -0400, Ruei, Eric wrote:
> Hi, guys:
> 
> Is there anything that we do regarding the large package size (1M to 8M)?

All the standard libs in /usr/lib get stripped properly.
But there's a new /usr/lib/dri/pvr_dri.so that is 28 MB even stripped. Is it 
supposed to be this large?

-- 
Denys


> Best regards,
> 
> Eric
> 
> On 10/30/2019 11:06 AM, Denys Dmytriyenko wrote:
> >On Wed, Oct 30, 2019 at 10:58:31AM -0400, Andrew F. Davis wrote:
> >>On 10/30/19 10:53 AM, Ruei, Eric wrote:
> >>>On 10/30/2019 9:53 AM, Tammana, Gowtham wrote:
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: meta-ti-bounces@yoctoproject.org [mailto:meta-ti-
> >>>>>bounces@yoctoproject.org] On Behalf Of Davis, Andrew
> >>>>>Sent: Wednesday, October 30, 2019 8:36 AM
> >>>>>To: Ruei, Eric; Ruei, Eric; meta-ti@yoctoproject.org
> >>>>>Subject: [EXTERNAL] Re: [meta-ti] [PATCH] ti-sgx-ddk-um: update
> >>>>>SRCREV to pick
> >>>>>up Mesa-based EGL/GLES libraries
> >>>>>
> >>>>>On 10/30/19 9:31 AM, Ruei, Eric wrote:
> >>>>>>On 10/30/2019 9:22 AM, Andrew F. Davis wrote:
> >>>>>>>On 10/29/19 9:20 AM, Eric Ruei wrote:
> >>>>>>>>This is the initial step toward Mesa-based EGL/GLES libraries which
> >>>>>>>>support all the required EGL 1.5 extensions. We plan to provide a
> >>>>>>>>Mesa-pvr recipe to build Mesa from source and SGX/DDK patches where
> >>>>>>>>ti-sgx-ddk-um shall provide the EGL/GLES plugins only at the next
> >>>>>>>>step.
> >>>>>>>>
> >>>>>>>>Signed-off-by: Eric Ruei <e-ruei1@ti.com>
> >>>>>>>>---
> >>>>>>>>    recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb | 8
> >>>>>>>>+++++---
> >>>>>>>>    1 file changed, 5 insertions(+), 3 deletions(-)
> >>>>>>>>
> >>>>>>>>diff --git a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> >>>>>>>>b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> >>>>>>>>index 7a6f013e..3991d917 100644
> >>>>>>>>--- a/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> >>>>>>>>+++ b/recipes-graphics/libgles/ti-sgx-ddk-um_1.17.4948957.bb
> >>>>>>>>@@ -11,7 +11,7 @@ PR = "r34"
> >>>>>>>>    BRANCH = "ti-img-sgx/thud/${PV}"
> >>>>>>>>      SRC_URI =
> >>>>>>>>"git://git.ti.com/graphics/omap5-sgx-ddk-um-
> >>>>>linux.git;protocol=git;branch=${BRANCH}"
> >>>>>>>>
> >>>>>>>>-SRCREV = "87d7e5c1e4db1bab048939c9719059d549c1e8dd"
> >>>>>>>>+SRCREV = "2a2e5bb090ced870d73ed4edbc54793e952cc6d8"
> >>>>>>>>      TARGET_PRODUCT_omap-a15 = "jacinto6evm"
> >>>>>>>>    TARGET_PRODUCT_ti33x = "ti335x"
> >>>>>>>>@@ -47,7 +47,9 @@ S = "${WORKDIR}/git"
> >>>>>>>>      do_install () {
> >>>>>>>>        oe_runmake install DESTDIR=${D}
> >>>>>>>>TARGET_PRODUCT=${TARGET_PRODUCT}
> >>>>>>>>-    ln -sf libGLESv2.so.${PV} ${D}${libdir}/libGLESv2.so.1
> >>>>>>>>+    ln -sf libGLESv2.so ${D}${libdir}/libGLESv2.so.1
> >>>>>>>>+
> >>>>>>>>+    rm -rf ${D}${includedir}/GL
> >>>>>>>
> >>>>>>>
> >>>>>>>Why remove this?
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>There is another component provides GL header files.
> >>>>>>Denys: how do we resolve this conflict?
> >>>>>>
> >>>>>
> >>>>>
> >>>>>The DSP OpenCL implementation? That package needs fixed, not this one,
> >>>>>the OpenGL implementation (this driver) should provide the GL headers.
> >>>>
> >>>>We don't support desktop GL, they shouldn't come from this package.
> >>>>
> >>>>Gowtham
> >>>>
> >>>
> >>>Andrew:
> >>>
> >>>Do you agree? I can keep the line here tentatively until GL is removed
> >>>from the package itself.
> >>>
> >>
> >>
> >>I still believe we should be shipping the GL headers in this package.
> >>But I won't object to removing the headers temporarily using this recipe
> >>until the conflicting ones can be removed from the OpenCL package.
> >
> >Previously DDK only provided headers in these dirs: EGL, GLES, GLES2, KHR, gbm.
> >
> >And OpenCL required GL headers, hence there was a "hacky" package created
> >specifically for that:
> >http://arago-project.org/git/?p=meta-arago.git;a=blob;f=meta-arago-extras/recipes-ti/ocl/ocl-gl-headers_git.bb;hb=HEAD
> >
> >If DDK now properly provides GL headers, the other package can be dropped.
> >
> >But the question remains - should DDK actually provide GL headers, even though
> >it doesn't provide full support for it?
> >
>