[Mesa-dev] [Mesa-stable] [PATCH] mapi: Export all GLES 3.1 functions in libGLESv2.so

Ilia Mirkin imirkin at alum.mit.edu
Fri Jun 17 21:58:21 UTC 2016


On Fri, Jun 17, 2016 at 5:48 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 17 June 2016 at 22:22, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov <emil.l.velikov at gmail.com>
>> wrote:
>>>
>>> On 17 June 2016 at 21:12, Mike Gorchak <mike.gorchak.qnx at gmail.com> wrote:
>>> > Please understand me right, we are not talking about desktop hardware
>>> > and
>>> > libraries, only about embedded in case of GL ES.
>>> GLES hasn't been "embedded only" for a while I believe.
>>
>>
>> No, but Mike is 100% correct that looking at AMD and NVIDIA isn't sufficient
>> in the gles case.  AMD doesn't matter (they don't do GLES) and NVIDIA is
>> only one vendor.  If the majority of *other* vendors (and there are a lot of
>> them) export the symbols, that does mean something.
>>
> My ideas are the following:
>  - First and foremost: Can we make things saner/more robust or is it
> too late [since most vendors are exporting the symbols] ?
>  - Can we confirm that's the case for Linux platforms ?
>
> I'm not trying to start a fight here, but to point out that
> "everybody's doing it" type of argument does not mean that "it" is a
> wise idea. IMHO one should establish exactly who "everybody" is (both
> vendors and platforms), consider for the consequences and then make a
> decision.

I don't think Emil has said this explicitly, and I don't want to put
words into his mouth, but at least I think it sucks to have this
non-fixed ABI for libGLESv2.so, which is otherwise (effectively)
unversioned. Perhaps we can version it like have a libGLESv2.so.3.1.0
or whatever which will have the ABI required for GLES 3.1, and
libGLESv2.so.3.0.0 which has the ABI required for GLES 3.0 (and
libGLESv2.so.2.0.0 which has the GLES 2.0 symbols).

But then what does mesa generate? Do freedreno, which supports GLES
3.0, and vc4, which supports GLES 2.0, ship a libGLESv2.so.3.1.0
because that's what core mesa supports? I guess that's not the end of
the world.

But of course then people who linked against libGLESv2.so.2 which is
what we ship now will be in trouble...

Not sure what the right answer is, but IMHO this merits a discussion.

  -ilia


More information about the mesa-dev mailing list