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

[Kenneth Graunke]

On Friday, June 17, 2016 5:58:21 PM PDT Ilia Mirkin wrote:
> 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).

IIRC, this is similar to what we'd discussed for the new OpenGL ABI
as well.  The new libOpenGL.so would expose all symbols from core
OpenGL versions without the need for GetProcAddress.  Extensions
would still be supported via GetProcAddress.

I believe we were going to bump the .so number for major GL versions,
i.e.  libOpenGL.so.4.5 would expose the entry points for GL 4.5.  But
I might be mistaken about that.

> 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.

Exactly.  It just means that the dispatch layer is hooked up and you
have the entry points.  It doesn't mean that the driver necessarily
supports all functionality (it may just INVALID_OPERATION at you).

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

That might be a problem.  I'll gladly defer to distro people who are
much more experienced with this than I am.

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

Another point: in GL, the ABI said to only expose a small set of
functionality, and use GetProcAddress for the rest.  We accidentally
exposed far too much, and other vendors did likewise.  So we opted
not to retract that functionality to avoid breaking things just to
follow the spec.

Here, the ES ABI is clear that we should expose /more/ than we have
been.  There are other shipping implementations, and Mike's emails
suggest that people generally expect this.  I think we need to follow
the spec.  There are plenty of cases where I think GL specs are crazy,
and would love to change them, but I don't always get to do that.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160617/2d5c8d10/attachment.sig>