Re: [Mesa-dev] [PATCH v2 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

2017-11-22 Thread Eric Engestrom 
On Tuesday, 2017-11-21 11:24:48 -0800, Jordan Justen wrote:
> On 2017-11-21 05:45:36, Eric Engestrom wrote:
> > On Monday, 2017-11-20 14:27:27 -0800, Jordan Justen wrote:
> > > Similar idea to Tim's "spec: MESA_program_binary", but simplified and
> > > written to support both ARB_get_program_binary and
> > > OES_get_program_binary.
> > > 
> > > This spec was merged into the OpenGL Registry in version
> > > 667c5a253781834b40a6ae9eb19d05af4542cfe1.
> > > 
> > > Ref: https://github.com/KhronosGroup/OpenGL-Registry/pull/127
> > > Signed-off-by: Jordan Justen 
> > > Cc: Ian Romanick 
> > > Cc: Timothy Arceri 
> > > Reviewed-by: Ian Romanick 
> > > Reviewed-by: Nicolai Hähnle 
> > > ---
> > >  docs/specs/MESA_program_binary_formats.txt | 88 
> > > ++
> > 
> > As far as I can tell, this file ^ is identical to the one upstream [1].
> > Why do we want a copy here?
> 
> I assumed that we kept a copy in Mesa as well. Why would we keep spec
> docs in Mesa that are not in the Khronos registry?

My understanding is that we only kept specs that are not upstream (yet),
but I might be wrong.

Why would we want a copy of some of the upstream specs? At best it's an
unnecessary duplicate, at worst it's a non-authoritative differing spec.

I had a quick look, and it seems about half of the specs we have in that
folder are now upstream; I'll double check that they're identical and
send patches to remove them.

Let's see what people say when I send that series.

> 
> -Jordan
> 
> > (ack on the rest of the patch though)
> > 
> > [1] 
> > https://www.khronos.org/registry/OpenGL/extensions/MESA/MESA_program_binary_formats.txt
> > 
> > >  docs/specs/enums.txt   |  3 +
> > >  src/mapi/glapi/registry/gl.xml |  7 ++-
> > >  3 files changed, 97 insertions(+), 1 deletion(-)
> > >  create mode 100644 docs/specs/MESA_program_binary_formats.txt
> > > 
> > > diff --git a/docs/specs/MESA_program_binary_formats.txt 
> > > b/docs/specs/MESA_program_binary_formats.txt
> > > new file mode 100644
> > > index 000..937e8ef4bf3
> > > --- /dev/null
> > > +++ b/docs/specs/MESA_program_binary_formats.txt
> > > @@ -0,0 +1,88 @@
> > > +Name
> > > +
> > > +MESA_program_binary_formats
> > > +
> > > +Name Strings
> > > +
> > > +GL_MESA_program_binary_formats
> > > +
> > > +Contributors
> > > +
> > > +Ian Romanick
> > > +Jordan Justen
> > > +Timothy Arceri
> > > +
> > > +Contact
> > > +
> > > +Jordan Justen (jordan.l.justen 'at' intel.com)
> > > +
> > > +Status
> > > +
> > > +Complete.
> > > +
> > > +Version
> > > +
> > > +Last Modified Date: November 10, 2017
> > > +Revision: #2
> > > +
> > > +Number
> > > +
> > > +OpenGL Extension #516
> > > +OpenGL ES Extension #294
> > > +
> > > +Dependencies
> > > +
> > > +For use with the OpenGL ARB_get_program_binary extension, or the
> > > +OpenGL ES OES_get_program_binary extension.
> > > +
> > > +Overview
> > > +
> > > +The get_program_binary exensions require a GLenum binaryFormat.
> > > +This extension documents that format for use with Mesa.
> > > +
> > > +New Procedures and Functions
> > > +
> > > +None.
> > > +
> > > +New Tokens
> > > +
> > > +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> > > +
> > > +For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > > +returned from GetProgramBinary calls in the 
> > > +parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
> > > +
> > > +For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > > +returned from GetProgramBinaryOES calls in the 
> > > +parameter and when retrieving the value of
> > > +PROGRAM_BINARY_FORMATS_OES.
> > > +
> > > +New State
> > > +
> > > +None.
> > > +
> > > +Issues
> > > +
> > > +(1) Should we have a different format for each driver?
> > > +
> > > +  RESOLVED. Since Mesa supports multiple hardware drivers, having
> > > +  a single format may cause separate drivers to have to reject a
> > > +  binary for another type of hardware on the same machine. This
> > > +  could lead to an application having to invalidate and get a new
> > > +  binary more often.
> > > +
> > > +  This extension, at least initially, does not to attempt to
> > > +  define a new token for each driver since systems that run
> > > +  multiple drivers are not the common case.
> > > +
> > > +  Additionally, drivers in Mesa are now gaining the ability to
> > > +  transparently cache shader programs. Therefore, although they
> > > +  may need to provide the application with a new binary more
> > > +  often, they likely can retrieve the program from the cache
> > > +  rather than performing an expensive recompile.
> > > +
> > > +Revision History
> > > +
> > > +#0211/10/2017Jordan

Re: [Mesa-dev] [PATCH v2 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

2017-11-21 Thread Jordan Justen 
On 2017-11-21 05:45:36, Eric Engestrom wrote:
> On Monday, 2017-11-20 14:27:27 -0800, Jordan Justen wrote:
> > Similar idea to Tim's "spec: MESA_program_binary", but simplified and
> > written to support both ARB_get_program_binary and
> > OES_get_program_binary.
> > 
> > This spec was merged into the OpenGL Registry in version
> > 667c5a253781834b40a6ae9eb19d05af4542cfe1.
> > 
> > Ref: https://github.com/KhronosGroup/OpenGL-Registry/pull/127
> > Signed-off-by: Jordan Justen 
> > Cc: Ian Romanick 
> > Cc: Timothy Arceri 
> > Reviewed-by: Ian Romanick 
> > Reviewed-by: Nicolai Hähnle 
> > ---
> >  docs/specs/MESA_program_binary_formats.txt | 88 
> > ++
> 
> As far as I can tell, this file ^ is identical to the one upstream [1].
> Why do we want a copy here?

I assumed that we kept a copy in Mesa as well. Why would we keep spec
docs in Mesa that are not in the Khronos registry?

-Jordan

> (ack on the rest of the patch though)
> 
> [1] 
> https://www.khronos.org/registry/OpenGL/extensions/MESA/MESA_program_binary_formats.txt
> 
> >  docs/specs/enums.txt   |  3 +
> >  src/mapi/glapi/registry/gl.xml |  7 ++-
> >  3 files changed, 97 insertions(+), 1 deletion(-)
> >  create mode 100644 docs/specs/MESA_program_binary_formats.txt
> > 
> > diff --git a/docs/specs/MESA_program_binary_formats.txt 
> > b/docs/specs/MESA_program_binary_formats.txt
> > new file mode 100644
> > index 000..937e8ef4bf3
> > --- /dev/null
> > +++ b/docs/specs/MESA_program_binary_formats.txt
> > @@ -0,0 +1,88 @@
> > +Name
> > +
> > +MESA_program_binary_formats
> > +
> > +Name Strings
> > +
> > +GL_MESA_program_binary_formats
> > +
> > +Contributors
> > +
> > +Ian Romanick
> > +Jordan Justen
> > +Timothy Arceri
> > +
> > +Contact
> > +
> > +Jordan Justen (jordan.l.justen 'at' intel.com)
> > +
> > +Status
> > +
> > +Complete.
> > +
> > +Version
> > +
> > +Last Modified Date: November 10, 2017
> > +Revision: #2
> > +
> > +Number
> > +
> > +OpenGL Extension #516
> > +OpenGL ES Extension #294
> > +
> > +Dependencies
> > +
> > +For use with the OpenGL ARB_get_program_binary extension, or the
> > +OpenGL ES OES_get_program_binary extension.
> > +
> > +Overview
> > +
> > +The get_program_binary exensions require a GLenum binaryFormat.
> > +This extension documents that format for use with Mesa.
> > +
> > +New Procedures and Functions
> > +
> > +None.
> > +
> > +New Tokens
> > +
> > +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> > +
> > +For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > +returned from GetProgramBinary calls in the 
> > +parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
> > +
> > +For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > +returned from GetProgramBinaryOES calls in the 
> > +parameter and when retrieving the value of
> > +PROGRAM_BINARY_FORMATS_OES.
> > +
> > +New State
> > +
> > +None.
> > +
> > +Issues
> > +
> > +(1) Should we have a different format for each driver?
> > +
> > +  RESOLVED. Since Mesa supports multiple hardware drivers, having
> > +  a single format may cause separate drivers to have to reject a
> > +  binary for another type of hardware on the same machine. This
> > +  could lead to an application having to invalidate and get a new
> > +  binary more often.
> > +
> > +  This extension, at least initially, does not to attempt to
> > +  define a new token for each driver since systems that run
> > +  multiple drivers are not the common case.
> > +
> > +  Additionally, drivers in Mesa are now gaining the ability to
> > +  transparently cache shader programs. Therefore, although they
> > +  may need to provide the application with a new binary more
> > +  often, they likely can retrieve the program from the cache
> > +  rather than performing an expensive recompile.
> > +
> > +Revision History
> > +
> > +#0211/10/2017Jordan Justen   Add Issues (1) suggested by 
> > Ian
> > +
> > +#0110/28/2017Jordan Justen   First draft.
> > diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
> > index eb4aa396c56..bf3ca9c1762 100644
> > --- a/docs/specs/enums.txt
> > +++ b/docs/specs/enums.txt
> > @@ -63,6 +63,9 @@ GL_MESAX_texture_stack:
> >   GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
> >   GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
> >  
> > +GL_MESA_program_binary_formats:
> > +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> > +
> >  GL_MESA_tile_raster_order
> >   GL_TILE_RASTER_ORDER_FIXED_MESA 0x8BB8
> >   GL_TILE_RASTER_ORDER_INCREASING_X_MESA  0x8BB9
> > diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
> > index

Re: [Mesa-dev] [PATCH v2 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

2017-11-21 Thread Eric Engestrom 
On Monday, 2017-11-20 14:27:27 -0800, Jordan Justen wrote:
> Similar idea to Tim's "spec: MESA_program_binary", but simplified and
> written to support both ARB_get_program_binary and
> OES_get_program_binary.
> 
> This spec was merged into the OpenGL Registry in version
> 667c5a253781834b40a6ae9eb19d05af4542cfe1.
> 
> Ref: https://github.com/KhronosGroup/OpenGL-Registry/pull/127
> Signed-off-by: Jordan Justen 
> Cc: Ian Romanick 
> Cc: Timothy Arceri 
> Reviewed-by: Ian Romanick 
> Reviewed-by: Nicolai Hähnle 
> ---
>  docs/specs/MESA_program_binary_formats.txt | 88 
> ++

As far as I can tell, this file ^ is identical to the one upstream [1].
Why do we want a copy here?

(ack on the rest of the patch though)

[1] 
https://www.khronos.org/registry/OpenGL/extensions/MESA/MESA_program_binary_formats.txt

>  docs/specs/enums.txt   |  3 +
>  src/mapi/glapi/registry/gl.xml |  7 ++-
>  3 files changed, 97 insertions(+), 1 deletion(-)
>  create mode 100644 docs/specs/MESA_program_binary_formats.txt
> 
> diff --git a/docs/specs/MESA_program_binary_formats.txt 
> b/docs/specs/MESA_program_binary_formats.txt
> new file mode 100644
> index 000..937e8ef4bf3
> --- /dev/null
> +++ b/docs/specs/MESA_program_binary_formats.txt
> @@ -0,0 +1,88 @@
> +Name
> +
> +MESA_program_binary_formats
> +
> +Name Strings
> +
> +GL_MESA_program_binary_formats
> +
> +Contributors
> +
> +Ian Romanick
> +Jordan Justen
> +Timothy Arceri
> +
> +Contact
> +
> +Jordan Justen (jordan.l.justen 'at' intel.com)
> +
> +Status
> +
> +Complete.
> +
> +Version
> +
> +Last Modified Date: November 10, 2017
> +Revision: #2
> +
> +Number
> +
> +OpenGL Extension #516
> +OpenGL ES Extension #294
> +
> +Dependencies
> +
> +For use with the OpenGL ARB_get_program_binary extension, or the
> +OpenGL ES OES_get_program_binary extension.
> +
> +Overview
> +
> +The get_program_binary exensions require a GLenum binaryFormat.
> +This extension documents that format for use with Mesa.
> +
> +New Procedures and Functions
> +
> +None.
> +
> +New Tokens
> +
> +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> +
> +For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> +returned from GetProgramBinary calls in the 
> +parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
> +
> +For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> +returned from GetProgramBinaryOES calls in the 
> +parameter and when retrieving the value of
> +PROGRAM_BINARY_FORMATS_OES.
> +
> +New State
> +
> +None.
> +
> +Issues
> +
> +(1) Should we have a different format for each driver?
> +
> +  RESOLVED. Since Mesa supports multiple hardware drivers, having
> +  a single format may cause separate drivers to have to reject a
> +  binary for another type of hardware on the same machine. This
> +  could lead to an application having to invalidate and get a new
> +  binary more often.
> +
> +  This extension, at least initially, does not to attempt to
> +  define a new token for each driver since systems that run
> +  multiple drivers are not the common case.
> +
> +  Additionally, drivers in Mesa are now gaining the ability to
> +  transparently cache shader programs. Therefore, although they
> +  may need to provide the application with a new binary more
> +  often, they likely can retrieve the program from the cache
> +  rather than performing an expensive recompile.
> +
> +Revision History
> +
> +#0211/10/2017Jordan Justen   Add Issues (1) suggested by Ian
> +
> +#0110/28/2017Jordan Justen   First draft.
> diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
> index eb4aa396c56..bf3ca9c1762 100644
> --- a/docs/specs/enums.txt
> +++ b/docs/specs/enums.txt
> @@ -63,6 +63,9 @@ GL_MESAX_texture_stack:
>   GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
>   GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
>  
> +GL_MESA_program_binary_formats:
> +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> +
>  GL_MESA_tile_raster_order
>   GL_TILE_RASTER_ORDER_FIXED_MESA 0x8BB8
>   GL_TILE_RASTER_ORDER_INCREASING_X_MESA  0x8BB9
> diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
> index cbabe11b398..833478aa515 100644
> --- a/src/mapi/glapi/registry/gl.xml
> +++ b/src/mapi/glapi/registry/gl.xml
> @@ -5505,7 +5505,7 @@ typedef unsigned int GLhandleARB;
>  
>  
>  
> -
> +
>  
>  
>  
> @@ -44361,6 +44361,11 @@ typedef unsigned int GLhandleARB;
>  
>  
>  
> + supported="gl|gles2">
> +
> +
> +
> +
>

[Mesa-dev] [PATCH v2 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

2017-11-20 Thread Jordan Justen 
Similar idea to Tim's "spec: MESA_program_binary", but simplified and
written to support both ARB_get_program_binary and
OES_get_program_binary.

This spec was merged into the OpenGL Registry in version
667c5a253781834b40a6ae9eb19d05af4542cfe1.

Ref: https://github.com/KhronosGroup/OpenGL-Registry/pull/127
Signed-off-by: Jordan Justen 
Cc: Ian Romanick 
Cc: Timothy Arceri 
Reviewed-by: Ian Romanick 
Reviewed-by: Nicolai Hähnle 
---
 docs/specs/MESA_program_binary_formats.txt | 88 ++
 docs/specs/enums.txt   |  3 +
 src/mapi/glapi/registry/gl.xml |  7 ++-
 3 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 docs/specs/MESA_program_binary_formats.txt

diff --git a/docs/specs/MESA_program_binary_formats.txt 
b/docs/specs/MESA_program_binary_formats.txt
new file mode 100644
index 000..937e8ef4bf3
--- /dev/null
+++ b/docs/specs/MESA_program_binary_formats.txt
@@ -0,0 +1,88 @@
+Name
+
+MESA_program_binary_formats
+
+Name Strings
+
+GL_MESA_program_binary_formats
+
+Contributors
+
+Ian Romanick
+Jordan Justen
+Timothy Arceri
+
+Contact
+
+Jordan Justen (jordan.l.justen 'at' intel.com)
+
+Status
+
+Complete.
+
+Version
+
+Last Modified Date: November 10, 2017
+Revision: #2
+
+Number
+
+OpenGL Extension #516
+OpenGL ES Extension #294
+
+Dependencies
+
+For use with the OpenGL ARB_get_program_binary extension, or the
+OpenGL ES OES_get_program_binary extension.
+
+Overview
+
+The get_program_binary exensions require a GLenum binaryFormat.
+This extension documents that format for use with Mesa.
+
+New Procedures and Functions
+
+None.
+
+New Tokens
+
+GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
+
+For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
+returned from GetProgramBinary calls in the 
+parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
+
+For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
+returned from GetProgramBinaryOES calls in the 
+parameter and when retrieving the value of
+PROGRAM_BINARY_FORMATS_OES.
+
+New State
+
+None.
+
+Issues
+
+(1) Should we have a different format for each driver?
+
+  RESOLVED. Since Mesa supports multiple hardware drivers, having
+  a single format may cause separate drivers to have to reject a
+  binary for another type of hardware on the same machine. This
+  could lead to an application having to invalidate and get a new
+  binary more often.
+
+  This extension, at least initially, does not to attempt to
+  define a new token for each driver since systems that run
+  multiple drivers are not the common case.
+
+  Additionally, drivers in Mesa are now gaining the ability to
+  transparently cache shader programs. Therefore, although they
+  may need to provide the application with a new binary more
+  often, they likely can retrieve the program from the cache
+  rather than performing an expensive recompile.
+
+Revision History
+
+#0211/10/2017Jordan Justen   Add Issues (1) suggested by Ian
+
+#0110/28/2017Jordan Justen   First draft.
diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
index eb4aa396c56..bf3ca9c1762 100644
--- a/docs/specs/enums.txt
+++ b/docs/specs/enums.txt
@@ -63,6 +63,9 @@ GL_MESAX_texture_stack:
GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
 
+GL_MESA_program_binary_formats:
+GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
+
 GL_MESA_tile_raster_order
GL_TILE_RASTER_ORDER_FIXED_MESA 0x8BB8
GL_TILE_RASTER_ORDER_INCREASING_X_MESA  0x8BB9
diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
index cbabe11b398..833478aa515 100644
--- a/src/mapi/glapi/registry/gl.xml
+++ b/src/mapi/glapi/registry/gl.xml
@@ -5505,7 +5505,7 @@ typedef unsigned int GLhandleARB;
 
 
 
-
+
 
 
 
@@ -44361,6 +44361,11 @@ typedef unsigned int GLhandleARB;
 
 
 
+
+
+
+
+
 
 
 
-- 
2.14.1

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