On 06/24/2016 09:30 AM, Emil Velikov wrote: > On 20 June 2016 at 19:14, Ian Romanick <i...@freedesktop.org> wrote: >> On 06/17/2016 11:15 AM, Emil Velikov wrote: >>> On 17 June 2016 at 18:20, Ian Romanick <i...@freedesktop.org> wrote: >>>> From: Ian Romanick <ian.d.roman...@intel.com> >>>> >>>> Khronos recommends that the GLES 3.1 library also be called libGLESv2. >>>> It also requires that functions be statically linkable from that >>>> library. >>>> >>>> NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension >>>> since at least Mesa 10.5, so applications targeting Linux should use >>>> eglGetProcAddress to avoid problems running binaries on systems with >>>> older, non-GLES 3.1 libGLESv2 libraries. >>>> >>> Fwiw I'm inclined that we should go the "opposite direction". Namely: >>> don't expose new symbols and stick to a predefined version (3.0 being >>> the personal favour of choice). >>> >>> Why, you might ask - for a couple of reasons: >>> - If the list continues to grow programs will have unstable ABI - >>> sort of how libGL ended up. Applications are going to link against 3.1 >>> or later symbols [1], even if they only optionally use them. Thus >>> things will quite hairy and fragile. >> >> There are at least two solutions, and piglit uses both. If use of a set >> of functions is optional, you can still use GetProcAddress (when >> EGL_KHR_get_all_proc_addresses is available) or you can use dlsym. >> >> For me, piglit is where this whole problem actually started. Right now, >> piglit follows the (unextended) rules and does not attempt to use >> GetProcAddress on core functions. It uses dlsym. I tried to extend >> shader_runner for separate shader objects on GLES. Guess what? Since >> the symbols aren't exported by the library, it didn't work. So... now >> piglit would need TWO code paths... one that uses dlsym and one that >> uses eglGetProcAddress... or require an optional extension. >> > I've started looking at piglit last night. There should be some fixes > for it on the list later on today. > >> If an application requires GLES 3.1 symbols, it should just be able to >> link with them. As far as I can tell, that's how it works on Android. >> > I look at the Android wrapper too closely for the following reasons: > > - There is libGLESv3.so which is identical copy of the v2 one. > - Their libGLESv2/3.so periodically grows new symbols, including GLES > extensions. > - Android has tight control what and/how it's run on their platform - > something that Linux distributions cannot do afaict. > - Applications using GLES should annotate the version used in the > manifest, which (haven't checked exactly) could serve as a first line > of defence for applications e.g. using GLES 3.1 on system/drivers > supporting GLES 3.0. > > That said, there is one very good thing: > - They use dlsym and then eglGetProcAddress on all symbols. Thus mesa > will just work. > >>> - The other desktop GLES* provider NVIDIA does not export even a >>> single GLES 3.1/3.2 entry point (still going through the 3.0 list) in >>> their libGLESv2.so.2 binary. >>> >>> So what to do with GLES (3.0?)/3.1 and later: >>> - tweak the spec so that said version of the API is only supported if >>> the implementation can get core symbols via eglGetProcAddress. Be that >>> props to the EGL_KHR_get_all_proc_addresses extension or EGL 1.5 [2]. >>> > Any "sounds ok" or "that's a horrible idea" input on this suggestion ?
That ship has already sailed. OpenGL ES 3.0 and 3.1 have both been shipping for years. I don't think changing that is how I would use my time machine. :) > Thanks > -Emil > >>> How does this sound ? I guess the best way would be to check with >>> other implementations (note Catalyst still seems to be missing >>> libGLES*) and choose the more common route ? >>> >>> >>> Regards, >>> Emil >>> >>> [1] Yes, in practise they should use libepoxy or a similar library, >>> but from practise we all know that even those tend to have bugs. Sadly >>> libepoxy in particular hasn't seen much action in a while. >>> >>> [2] https://github.com/anholt/libepoxy/issues/21 >>> _______________________________________________ >>> mesa-stable mailing list >>> mesa-sta...@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/mesa-stable >> > _______________________________________________ > mesa-stable mailing list > mesa-sta...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-stable > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
