On Thu, Sep 22, 2016 at 5:45 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 22 September 2016 at 08:10, Erik Faye-Lund <kusmab...@gmail.com> wrote: >> On Wed, Sep 21, 2016 at 8:57 PM, Kenneth Graunke <kenn...@whitecape.org> >> wrote: >>> Commit 5921f372c89a68fac6ddefc009442721d9df4db2 exposed GLES 3.1 symbols >>> in libGLESv2.so. Are we supposed to do the same thing for GLES 3.2? >>> >>> I imagine we're supposed to, but I'm not certain what spec actually >>> defines the ABI or where to look. >> >> This is the kind of stuff that is usually defined in the Khronos API >> Implementers Guide: >> https://www.khronos.org/registry/implementers_guide.html >> >> And it seems these should be exposed, as section 2.1.2.1 ("Packaging") says: >> >> "Except in cases where macros are allowed or versioned symbol naming >> is recommended (e.g., OpenCL symbol naming), ensure the API function >> names exported by your lib & dll files match the function names >> specified by the Khronos standard for the API you are implementing." >> >> I interpret this as there being an expectancy that the core API >> functions are actually exported. The same section also says >> >> "The entry points for each API must be packaged in separate libraries. >> Recommended library names are given in Table 2, “Recommended Library >> Names”." >> >> In section 2.1.2.2 ("Naming") table 2 lists the library base-name for >> OpenGL ES 3.x as "GLESv2", and even clarifies with a footnote that >> this is not a typo. >> >> All together, this tells me that libGLESv2.so should include all core >> symbols of the OpenGL 2.x *and* OpenGL 3.x API. > s|3.x|3.[012]|g but I totally agree. > > Since we've decided to let the "cat out of the bag" sort of speak, > with and ensure that all GLES 3.1 API is exported we might as well do > the same for GLES 3.2. > > It's a bit shame on the (broken?) ABI side of things, but well we > cannot do much at this point. I'm still finding my way around in > Khronos, but I have a few ideas how one can update things going > forward (GLES 3.3 anyone?).
I meant to say "OpenGL ES 2.x *and* OpenGL ES 3.x", not OpenGL. The 3.x is Khronos' phrasing, not mine. So I think also a hypothetical OpenGL ES 3.3 (and up) would be covered, unless they decide to change the Implementers Guide. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
