Re: [Mesa-dev] [PATCH 1/2] glapi: Move PrimitiveBoundingBox and BlendBarrier definitions into ES3.2 category.

[Dylan Baker]

Quoting Francisco Jerez (2016-10-18 20:48:51)
> These two GLES 3.2 entry points were being defined in the category of
> the ARB_ES3_2_compatibility and KHR_blend_equation_advanced extensions
> respectively instead of in the ES3.2 category.  Defining them in the
> ES3.2 category makes sure that the gl_procs.py generator emits
> declarations in the glprocs.h header file for the unsuffixed GLES-only
> entry points that PrimitiveBoundingBoxARB and BlendBarrierKHR
> respectively alias.  This should avoid a compilation failure during
> scons builds in combination with "mapi: export all GLES 3.2 functions
> in libGLESv2.so".
> ---
>  src/mapi/glapi/gen/gl_API.xml | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 5998ccf..00c9bb7 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8296,6 +8296,23 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>  
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>  
>  
>  
> @@ -8316,7 +8333,6 @@
>  
>  
>  
> -
>  
>  
>  
> @@ -8332,18 +8348,6 @@
>  
>  
>  
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
>  
>  
>  
> -- 
> 2.9.0
> 

I didn't look too closely, but your theory on why this fixes the scons build
makes sense to me. I've tested this and it seems good.

We should probably also get this in 13.0, so CC stable?

for the series:
Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] [PATCH 1/2] glapi: Move PrimitiveBoundingBox and BlendBarrier definitions into ES3.2 category.

[Francisco Jerez]

Ilia Mirkin  writes:

> Why does it care where those functions are defined? I thought it was
> all one big happy namespace, with the categories just there for
> general amusement. Could you shed some light on what the actual
> situation is?
>

Heh, I won't pretend to understand the dispatch generation mess, but
apparently the gl_procs.py treats the ES (and GL_OES) categories
specially and emits forward declarations for them before the actual
table -- Possibly to hack around build failures with GLES entry points
not defined in desktop GL headers.

> On Tue, Oct 18, 2016 at 11:48 PM, Francisco Jerez  
> wrote:
>> These two GLES 3.2 entry points were being defined in the category of
>> the ARB_ES3_2_compatibility and KHR_blend_equation_advanced extensions
>> respectively instead of in the ES3.2 category.  Defining them in the
>> ES3.2 category makes sure that the gl_procs.py generator emits
>> declarations in the glprocs.h header file for the unsuffixed GLES-only
>> entry points that PrimitiveBoundingBoxARB and BlendBarrierKHR
>> respectively alias.  This should avoid a compilation failure during
>> scons builds in combination with "mapi: export all GLES 3.2 functions
>> in libGLESv2.so".
>> ---
>>  src/mapi/glapi/gen/gl_API.xml | 30 +-
>>  1 file changed, 17 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
>> index 5998ccf..00c9bb7 100644
>> --- a/src/mapi/glapi/gen/gl_API.xml
>> +++ b/src/mapi/glapi/gen/gl_API.xml
>> @@ -8296,6 +8296,23 @@
>>  
>>  > xmlns:xi="http://www.w3.org/2001/XInclude"/>
>>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>  
>>  
>>
>> @@ -8316,7 +8333,6 @@
>>  
>>  
>>
>> -
>>  
>>  
>>
>> @@ -8332,18 +8348,6 @@
>>  
>>  
>>
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>>  
>>  
>>  
>> --
>> 2.9.0
>>


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] glapi: Move PrimitiveBoundingBox and BlendBarrier definitions into ES3.2 category.

[Ilia Mirkin]

Why does it care where those functions are defined? I thought it was
all one big happy namespace, with the categories just there for
general amusement. Could you shed some light on what the actual
situation is?

On Tue, Oct 18, 2016 at 11:48 PM, Francisco Jerez  wrote:
> These two GLES 3.2 entry points were being defined in the category of
> the ARB_ES3_2_compatibility and KHR_blend_equation_advanced extensions
> respectively instead of in the ES3.2 category.  Defining them in the
> ES3.2 category makes sure that the gl_procs.py generator emits
> declarations in the glprocs.h header file for the unsuffixed GLES-only
> entry points that PrimitiveBoundingBoxARB and BlendBarrierKHR
> respectively alias.  This should avoid a compilation failure during
> scons builds in combination with "mapi: export all GLES 3.2 functions
> in libGLESv2.so".
> ---
>  src/mapi/glapi/gen/gl_API.xml | 30 +-
>  1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
> index 5998ccf..00c9bb7 100644
> --- a/src/mapi/glapi/gen/gl_API.xml
> +++ b/src/mapi/glapi/gen/gl_API.xml
> @@ -8296,6 +8296,23 @@
>  
>   xmlns:xi="http://www.w3.org/2001/XInclude"/>
>
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
> +
>  
>  
>
> @@ -8316,7 +8333,6 @@
>  
>  
>
> -
>  
>  
>
> @@ -8332,18 +8348,6 @@
>  
>  
>
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
>  
>  
>  
> --
> 2.9.0
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev