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 ("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 ("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?).

mesa-dev mailing list

Reply via email to