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

[Andreas Boll]

2016-07-19 13:20 GMT+02:00 Emil Velikov :
> On 19 July 2016 at 09:55, Andreas Boll  wrote:
>> Hi,
>>
>> sorry for being late but this patch doesn't mention that all those
>> symbols should be exported in libGL.so too [1].
>> If you look at the history of static_data.py it was mentioned that
>> this list of functions should never grow [2].
>>
> I believe this is a side effect from our mapi python code. Although to
> be perfectly honest, I'm not sure if any of these matter, since
> libglvnd's libGL exports "the world" and my suggestions against doing
> that fell on deaf ears [0].
>
> Thanks
> Emil
>
> [0] https://github.com/NVIDIA/libglvnd/issues/62

Ugh that sounds awful.

Ian, what do you think about this?

Thanks,
Andreas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 19 July 2016 at 09:55, Andreas Boll  wrote:
> Hi,
>
> sorry for being late but this patch doesn't mention that all those
> symbols should be exported in libGL.so too [1].
> If you look at the history of static_data.py it was mentioned that
> this list of functions should never grow [2].
>
I believe this is a side effect from our mapi python code. Although to
be perfectly honest, I'm not sure if any of these matter, since
libglvnd's libGL exports "the world" and my suggestions against doing
that fell on deaf ears [0].

Thanks
Emil

[0] https://github.com/NVIDIA/libglvnd/issues/62
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Andreas Boll]

Hi,

sorry for being late but this patch doesn't mention that all those
symbols should be exported in libGL.so too [1].
If you look at the history of static_data.py it was mentioned that
this list of functions should never grow [2].

Thanks,
Andreas

[1] 
https://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git/commit/?h=debian-experimental=abc592b02856f4438da97693025f5ccd9807a443
[2] 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=d9be1db4b69a04f58a951351051ef9798d55da98

2016-06-17 19:20 GMT+02:00 Ian Romanick :
> From: Ian Romanick 
>
> 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.
>
> Signed-off-by: Ian Romanick 
> Cc: "11.2 12.0" 
> Cc: Mike Gorchak 
> Reported-by: Mike Gorchak 
> ---
>  src/mapi/glapi/gen/static_data.py | 51 
> +++
>  1 file changed, 51 insertions(+)
>
> diff --git a/src/mapi/glapi/gen/static_data.py 
> b/src/mapi/glapi/gen/static_data.py
> index 142c503..b25dab1 100644
> --- a/src/mapi/glapi/gen/static_data.py
> +++ b/src/mapi/glapi/gen/static_data.py
> @@ -437,6 +437,7 @@ offsets = {
>
>  functions = [
> "Accum",
> +   "ActiveShaderProgram",
> "ActiveTexture",
> "ActiveTextureARB",
> "AlphaFunc",
> @@ -470,6 +471,7 @@ functions = [
> "BindImageTexture",
> "BindImageTextures",
> "BindProgramARB",
> +   "BindProgramPipeline",
> "BindRenderbuffer",
> "BindRenderbufferEXT",
> "BindSampler",
> @@ -615,6 +617,7 @@ functions = [
> "CreateProgramObjectARB",
> "CreateShader",
> "CreateShaderObjectARB",
> +   "CreateShaderProgramv",
> "CullFace",
> "DebugMessageCallback",
> "DebugMessageCallbackARB",
> @@ -629,6 +632,7 @@ functions = [
> "DeleteLists",
> "DeleteObjectARB",
> "DeleteProgram",
> +   "DeleteProgramPipelines",
> "DeleteProgramsARB",
> "DeleteQueries",
> "DeleteQueriesARB",
> @@ -737,6 +741,7 @@ functions = [
> "Fogiv",
> "Fogx",
> "Fogxv",
> +   "FramebufferParameteri",
> "FramebufferRenderbuffer",
> "FramebufferRenderbufferEXT",
> "FramebufferTexture",
> @@ -761,6 +766,7 @@ functions = [
> "GenFramebuffers",
> "GenFramebuffersEXT",
> "GenLists",
> +   "GenProgramPipelines",
> "GenProgramsARB",
> "GenQueries",
> "GenQueriesARB",
> @@ -818,6 +824,7 @@ functions = [
> "GetFragDataLocationEXT",
> "GetFramebufferAttachmentParameteriv",
> "GetFramebufferAttachmentParameterivEXT",
> +   "GetFramebufferParameteriv",
> "GetGraphicsResetStatusARB",
> "GetHandleARB",
> "GetHistogram",
> @@ -874,10 +881,17 @@ functions = [
> "GetProgramEnvParameterdvARB",
> "GetProgramEnvParameterfvARB",
> "GetProgramInfoLog",
> +   "GetProgramInterfaceiv",
> "GetProgramiv",
> "GetProgramivARB",
> "GetProgramLocalParameterdvARB",
> "GetProgramLocalParameterfvARB",
> +   "GetProgramPipelineInfoLog",
> +   "GetProgramPipelineiv",
> +   "GetProgramResourceIndex",
> +   "GetProgramResourceiv",
> +   "GetProgramResourceLocation",
> +   "GetProgramResourceName",
> "GetProgramStringARB",
> "GetQueryIndexediv",
> "GetQueryiv",
> @@ -973,6 +987,7 @@ functions = [
> "IsList",
> "IsProgram",
> "IsProgramARB",
> +   "IsProgramPipeline",
> "IsQuery",
> "IsQueryARB",
> "IsRenderbuffer",
> @@ -1032,6 +1047,7 @@ functions = [
> "Materialxv",
> "MatrixMode",
> "MemoryBarrier",
> +   "MemoryBarrierByRegion",
> "Minmax",
> "MinSampleShading",
> "MinSampleShadingARB",
> @@ -1192,6 +1208,39 @@ functions = [
> "ProgramParameteri",
> "ProgramParameteriARB",
> "ProgramStringARB",
> +   "ProgramUniform1f",
> +   "ProgramUniform1fv",
> +   "ProgramUniform1i",
> +   "ProgramUniform1iv",
> +   "ProgramUniform1ui",
> +   "ProgramUniform1uiv",
> +   "ProgramUniform2f",
> +   "ProgramUniform2fv",
> +   "ProgramUniform2i",
> +   "ProgramUniform2iv",
> +   "ProgramUniform2ui",
> +   "ProgramUniform2uiv",
> +   "ProgramUniform3f",
> +   "ProgramUniform3fv",
> +   "ProgramUniform3i",
> +   "ProgramUniform3iv",
> +   "ProgramUniform3ui",
> +   "ProgramUniform3uiv",
> +   "ProgramUniform4f",
> +   "ProgramUniform4fv",
> +   "ProgramUniform4i",
> +   "ProgramUniform4iv",
> +   "ProgramUniform4ui",
> +   "ProgramUniform4uiv",
> +   "ProgramUniformMatrix2fv",
> +   "ProgramUniformMatrix2x3fv",
> +   "ProgramUniformMatrix2x4fv",
> +   "ProgramUniformMatrix3fv",
> +   "ProgramUniformMatrix3x2fv",
> +   "ProgramUniformMatrix3x4fv",
> +   

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

[Emil Velikov]

On 27 June 2016 at 18:38, Ian Romanick  wrote:
> On 06/24/2016 09:30 AM, Emil Velikov wrote:
>> On 20 June 2016 at 19:14, Ian Romanick  wrote:
>>> On 06/17/2016 11:15 AM, Emil Velikov wrote:
 On 17 June 2016 at 18:20, Ian Romanick  wrote:
> From: Ian Romanick 
>
> 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ian Romanick]

On 06/24/2016 09:30 AM, Emil Velikov wrote:
> On 20 June 2016 at 19:14, Ian Romanick  wrote:
>> On 06/17/2016 11:15 AM, Emil Velikov wrote:
>>> On 17 June 2016 at 18:20, Ian Romanick  wrote:
 From: Ian Romanick 

 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

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

[Emil Velikov]

On 20 June 2016 at 19:14, Ian Romanick  wrote:
> On 06/17/2016 11:15 AM, Emil Velikov wrote:
>> On 17 June 2016 at 18:20, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> 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 ?

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-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Ian Romanick]

On 06/17/2016 11:15 AM, Emil Velikov wrote:
> On 17 June 2016 at 18:20, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> 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.

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.

>  - 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].
> 
> 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-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 18 June 2016 at 00:01, Kenneth Graunke  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  
>> wrote:
>> > On 17 June 2016 at 22:22, Jason Ekstrand  wrote:
>> >> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov 
>> >> wrote:
>> >>>
>> >>> On 17 June 2016 at 21:12, Mike Gorchak  
>> >>> 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 

Re: [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  
> wrote:
> > On 17 June 2016 at 22:22, Jason Ekstrand  wrote:
> >> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov 
> >> wrote:
> >>>
> >>> On 17 June 2016 at 21:12, Mike Gorchak  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

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

[Ilia Mirkin]

On Fri, Jun 17, 2016 at 5:48 PM, Emil Velikov  wrote:
> On 17 June 2016 at 22:22, Jason Ekstrand  wrote:
>> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov 
>> wrote:
>>>
>>> On 17 June 2016 at 21:12, Mike Gorchak  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).

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.

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

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

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 17 June 2016 at 22:22, Jason Ekstrand  wrote:
> On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov 
> wrote:
>>
>> On 17 June 2016 at 21:12, Mike Gorchak  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.

Regards,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Jason Ekstrand]

On Fri, Jun 17, 2016 at 2:09 PM, Emil Velikov 
wrote:

> On 17 June 2016 at 21:12, Mike Gorchak  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.


>
> > What's common for desktop
> > usually uncommon for embedded and vice versa.
> True. And dare I say it, the embedded world tends to have more and
> nastier hacks than the desktop one :-P
>
> > We are currently ship
> > libraries from many silicon vendors: Imagination RGX, Mali, Vivante,
> nVidia
> > - all have GLES 3.1 and 3.2 functions in libGLESv2.so .
> >
> Quick look for 'we' shows QNX (in case someone like myself is wondering).
>
> Hmm looking at the Mali one makes me uneasy - singe binary that
> provides the OpenCL, EGL GBM, wayland-egl and OpenGLES* APIs.
> 
> Let's not forget that much needed symbols such as ConvertUTF8toUTF16
> (+ friends) and abstraction layers around dl, sem, mutex, sync_object,
> and threads must also be exported.
> 
>
> Would be great if we get another confirmation if other vendors have
> butchered it so nicely. I believe there's a sound logic behind my
> suggestion, but if the cat is out of the bag (sort of speak) and we
> cannot do anything mitigate things so be it.
>
> Regards,
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 17 June 2016 at 21:12, Mike Gorchak  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.

> What's common for desktop
> usually uncommon for embedded and vice versa.
True. And dare I say it, the embedded world tends to have more and
nastier hacks than the desktop one :-P

> We are currently ship
> libraries from many silicon vendors: Imagination RGX, Mali, Vivante, nVidia
> - all have GLES 3.1 and 3.2 functions in libGLESv2.so .
>
Quick look for 'we' shows QNX (in case someone like myself is wondering).

Hmm looking at the Mali one makes me uneasy - singe binary that
provides the OpenCL, EGL GBM, wayland-egl and OpenGLES* APIs.

Let's not forget that much needed symbols such as ConvertUTF8toUTF16
(+ friends) and abstraction layers around dl, sem, mutex, sync_object,
and threads must also be exported.


Would be great if we get another confirmation if other vendors have
butchered it so nicely. I believe there's a sound logic behind my
suggestion, but if the cat is out of the bag (sort of speak) and we
cannot do anything mitigate things so be it.

Regards,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mike Gorchak]

Please understand me right, we are not talking about desktop hardware and
libraries, only about embedded in case of GL ES. What's common for desktop
usually uncommon for embedded and vice versa. We are currently ship
libraries from many silicon vendors: Imagination RGX, Mali, Vivante, nVidia
- all have GLES 3.1 and 3.2 functions in libGLESv2.so .

Thanks!


On Fri, Jun 17, 2016 at 2:15 PM, Emil Velikov 
wrote:

> On 17 June 2016 at 18:20, Ian Romanick  wrote:
> > From: Ian Romanick 
> >
> > 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.
>  - 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].
>
> 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-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

On 17 June 2016 at 18:20, Ian Romanick  wrote:
> From: Ian Romanick 
>
> 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.
 - 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].

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-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev