On 18 June 2016 at 00:01, Kenneth Graunke <kenn...@whitecape.org> wrote: > 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). > That's precisely what I alluded with "If the list continues to grow programs will have unstable ABI - sort of how libGL ended up...."
> 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. > Correct. > 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. > We decided against this. >> 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... > Static linking against newer symbols is the other concern that I've mentioned earlier - "Applications are going to link against 3.1 or later symbols, even if they only optionally use them." > That might be a problem. I'll gladly defer to distro people who are > much more experienced with this than I am. > I would gladly hear them as well, sadly I'm not sure we will .They have less time than us to comb through the mesa-dev ML and my earlier call for mesa-maintainers (or similar channel) died off with Arch's maintainer stating that putting it in the release notes is fine :-( >> Not sure what the right answer is, but IMHO this merits a discussion. >> Precisely what I'm asking. Thanks for elaborating on my arguments Ilia ! >> -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. > Looks like everyone has missed a similar discussion in libepoxy [1] that I've linked earlier. To quote the best bits (EGL 1.5), the emphasis is mine of course. "eglGetProcAddress may be queried for all EGL and client API functions sup- ported by the implementation (whether those functions _are_ _extensions_ _or_ _not_, and whether they are supported by the current client API context or not). For functions that are queryable with eglGetProcAddress, implementations _may_ _choose_ to also export those functions _statically_ from the object libraries im- plementing those functions. However, portable clients _cannot_ _rely_ on this behavior " So to sum up - Khronos saw that things are getting a bit crazy so they tried to correct them with EGL 1.5. They even tried to mitigate it for earlier EGL versions with the EGL_KHR_get_all_proc_addresses extension. Can we check how many Linux vendors follow the EGL 1.5 spec and how many earlier versions. We combine that with (gu)estimate of the amount of 'broken' users and then decide what we'll do for mesa. TL:DR; I'm not saying "mesa will never export GLES 3.1 ...", but "don't make rushed decisions" :-) Thanks Emil [1] https://github.com/anholt/libepoxy/issues/21 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
