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

[Emil Velikov]

On 27 June 2016 at 18:38, Ian Romanick <idr at freedesktop.org> wrote:
> On 06/24/2016 09:30 AM, Emil Velikov wrote:
>> On 20 June 2016 at 19:14, Ian Romanick <idr at freedesktop.org> wrote:
>>> On 06/17/2016 11:15 AM, Emil Velikov wrote:
>>>> On 17 June 2016 at 18:20, Ian Romanick <idr at freedesktop.org> wrote:
>>>>> From: Ian Romanick <ian.d.romanick at 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. :)
>
As you guys wish, I won't stir up a hornet's nest. Just a reminder
that we did a similar thing on the libGL front, which, imho, was
significantly more likely to have actual users that depend on such
'odd' behaviour.

A humble request - can we keep an eye open as GLES 3.3 and/or OpenGL
4.6 comes out. Would be great if with those include the proposed
suggestion/fix. Namely: in order to use these with EGL, one needs to
have the EGL_KHR_get_all_proc_addresses extension or EGL 1.5.

I'll keep an eye open Collabora being a Khronos member, although it
would be great if I'm not the only one.

Thanks
Emil