[Mesa-dev] Expose ES 3.2 symbols in libGLESv2.so?

[Erik Faye-Lund]

On Thu, Sep 22, 2016 at 5:45 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 22 September 2016 at 08:10, Erik Faye-Lund <kusmabite at gmail.com> wrote:
>> On Wed, Sep 21, 2016 at 8:57 PM, Kenneth Graunke <kenneth at 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.