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.veli...@gmail.com> > wrote: > > On 17 June 2016 at 22:22, Jason Ekstrand <ja...@jlekstrand.net> wrote: > >> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov <emil.l.veli...@gmail.com> > >> wrote: > >>> > >>> On 17 June 2016 at 21:12, Mike Gorchak <mike.gorchak....@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
