On 10/30/19 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: [email protected] [mailto:meta-ti- >>>>> [email protected]] On Behalf Of Davis, Andrew >>>>> Sent: Wednesday, October 30, 2019 8:36 AM >>>>> To: Ruei, Eric; Ruei, Eric; [email protected] >>>>> 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 <[email protected]> >>>>>>>> --- >>>>>>>> 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? >
The GL headers are the stock headers provided by Kronos that every GL implementation should provide, they often contain definitions for unsupported features (even the GLES folders have unsupported extension definitions). The exact set of usable features can be determined at runtime using various provided methods. Basically it is up to the EGL layer to report back what the underlying implementation supports, it should not be based on the content/age of the headers at compile time. Without these headers valid/usable programs may not compile on our platform. Andrew -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
