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>
>>> 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:
>> And it seems these should be exposed, as section 220.127.116.11 ("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
>> In section 18.104.22.168 ("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.|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