date:20151009

[Mesa-dev] [PATCH v2] configure.ac: ensure RM is set

2015-10-09 Thread Jonathan Gray

GNU make predefines RM to rm -f but this is not required by POSIX
so ensure that RM is set.  This fixes "make clean" on OpenBSD.

v2: use AC_CHECK_PROG

Signed-off-by: Jonathan Gray 
CC: "10.6 11.0" 
---
 configure.ac | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure.ac b/configure.ac
index 3feec19..f99545f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,6 +107,8 @@ AC_SYS_LARGEFILE
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
 
+AC_CHECK_PROG(RM, rm, [rm -f])
+
 AX_PROG_BISON([],
   AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
 [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
-- 
2.5.3

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

[Mesa-dev] [PATCH] nouveau: avoid emitting new fences unnecessarily

2015-10-09 Thread Ilia Mirkin

Right now we emit on every kick, but this is only necessary if something
will ever be able to observe that the fence completed. If there are no
refs, leave the fence alone and emit it another day.

This also happens to work around an issue for the kick handler -- a kick
can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be
due to lack of space in the pushbuf. We want the emit to happen in the
current batch, so we want there to always be enough space. However an
explicit kick could take the reserved space for the implicitly-triggered
kick's fence emission if it happened right after. With the new mechanism,
hopefully there's no way to cause two fences to be emitted into the same
reserved space.

Signed-off-by: Ilia Mirkin 
Cc: mesa-sta...@lists.freedesktop.org
Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence)
---
 src/gallium/drivers/nouveau/nouveau_fence.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nouveau_fence.c 
b/src/gallium/drivers/nouveau/nouveau_fence.c
index ee4e08d..18b1592 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -190,8 +190,10 @@ nouveau_fence_wait(struct nouveau_fence *fence)
/* wtf, someone is waiting on a fence in flush_notify handler? */
assert(fence->state != NOUVEAU_FENCE_STATE_EMITTING);
 
-   if (fence->state < NOUVEAU_FENCE_STATE_EMITTED)
+   if (fence->state < NOUVEAU_FENCE_STATE_EMITTED) {
+  PUSH_SPACE(screen->pushbuf, 8);
   nouveau_fence_emit(fence);
+   }
 
if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED)
   if (nouveau_pushbuf_kick(screen->pushbuf, screen->pushbuf->channel))
@@ -224,8 +226,12 @@ nouveau_fence_wait(struct nouveau_fence *fence)
 void
 nouveau_fence_next(struct nouveau_screen *screen)
 {
-   if (screen->fence.current->state < NOUVEAU_FENCE_STATE_EMITTING)
-  nouveau_fence_emit(screen->fence.current);
+   if (screen->fence.current->state < NOUVEAU_FENCE_STATE_EMITTING) {
+  if (screen->fence.current->ref > 1)
+ nouveau_fence_emit(screen->fence.current);
+  else
+ return;
+   }
 
nouveau_fence_ref(NULL, &screen->fence.current);
 
-- 
2.4.9

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

Re: [Mesa-dev] [PATCH 0/9 v3] Apply GLSL ES initializer restrictions

2015-10-09 Thread Matt Turner

I sent a couple of small comments. The series is

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] program: remove unused function _mesa_find_line_column

2015-10-09 Thread Ian Romanick

It looks like the last user of this function was removed by Ken in 2012
(2f350f3).  Kill it with fire.

This patch is

Reviewed-by: Ian Romanick 

On 10/07/2015 05:11 PM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mesa/program/program.c | 43 ---
>  src/mesa/program/program.h |  5 -
>  2 files changed, 48 deletions(-)
> 
> diff --git a/src/mesa/program/program.c b/src/mesa/program/program.c
> index e94c102..23d8be8 100644
> --- a/src/mesa/program/program.c
> +++ b/src/mesa/program/program.c
> @@ -173,49 +173,6 @@ _mesa_set_program_error(struct gl_context *ctx, GLint 
> pos, const char *string)
>  
>  
>  /**
> - * Find the line number and column for 'pos' within 'string'.
> - * Return a copy of the line which contains 'pos'.  Free the line with
> - * free().
> - * \param string  the program string
> - * \param pos the position within the string
> - * \param linereturns the line number corresponding to 'pos'.
> - * \param col returns the column number corresponding to 'pos'.
> - * \return copy of the line containing 'pos'.
> - */
> -const GLubyte *
> -_mesa_find_line_column(const GLubyte *string, const GLubyte *pos,
> -   GLint *line, GLint *col)
> -{
> -   const GLubyte *lineStart = string;
> -   const GLubyte *p = string;
> -   GLubyte *s;
> -   int len;
> -
> -   *line = 1;
> -
> -   while (p != pos) {
> -  if (*p == (GLubyte) '\n') {
> - (*line)++;
> - lineStart = p + 1;
> -  }
> -  p++;
> -   }
> -
> -   *col = (pos - lineStart) + 1;
> -
> -   /* return copy of this line */
> -   while (*p != 0 && *p != '\n')
> -  p++;
> -   len = p - lineStart;
> -   s = malloc(len + 1);
> -   memcpy(s, lineStart, len);
> -   s[len] = 0;
> -
> -   return s;
> -}
> -
> -
> -/**
>   * Initialize a new gl_program object.
>   */
>  static void
> diff --git a/src/mesa/program/program.h b/src/mesa/program/program.h
> index a894147..aad81de 100644
> --- a/src/mesa/program/program.h
> +++ b/src/mesa/program/program.h
> @@ -63,11 +63,6 @@ _mesa_update_default_objects_program(struct gl_context 
> *ctx);
>  extern void
>  _mesa_set_program_error(struct gl_context *ctx, GLint pos, const char 
> *string);
>  
> -extern const GLubyte *
> -_mesa_find_line_column(const GLubyte *string, const GLubyte *pos,
> -   GLint *line, GLint *col);
> -
> -
>  extern struct gl_program *
>  _mesa_init_vertex_program(struct gl_context *ctx,
>struct gl_vertex_program *prog,
> 

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

Re: [Mesa-dev] [PATCH 8/9] glsl: In later GLSL versions, sequence operator is cannot be a constant expression

2015-10-09 Thread Matt Turner

On Fri, Oct 9, 2015 at 6:53 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> Fixes:
> ES3-CTS.shaders.negative.constant_sequence
>
> spec/glsl-es-3.00/compiler/global-initializer/from-sequence.vert
> spec/glsl-es-3.00/compiler/global-initializer/from-sequence.frag
>
> Signed-off-by: Ian Romanick 
> Cc: "10.6 11.0" 
> ---
>  src/glsl/ast_to_hir.cpp | 43 ++-
>  1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 6af0f80..f34cbe0 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -3311,8 +3311,49 @@ process_initializer(ir_variable *var, ast_declaration 
> *decl,
>if (new_rhs != NULL) {
>   rhs = new_rhs;
>
> + /* Section 4.3.3 (Constant Expressions) of the GLSL ES 3.00.4 spec
> +  * says:
> +  *
> +  * "A constant expression is one of
> +  *
> +  *...
> +  *
> +  *- an expression formed by an operator on operands that are
> +  *  all constant expressions, including getting an element 
> of
> +  *  a constant array, or a field of a constant structure, or
> +  *  components of a constant vector.  However, the sequence
> +  *  operator ( , ) and the assignment operators ( =, +=, 
> ...)
> +  *  are not included in the operators that can create a
> +  *  constant expression."
> +  *
> +  * Section 12.43 (Sequence operator and constant expressions) says:
> +  *
> +  * "Should the following construct be allowed?
> +  *
> +  * float a[2,3];
> +  *
> +  * The expression within the brackets uses the sequence operator
> +  * (',') and returns the integer 3 so the construct is decl 
> aring

There's a space in the middle of "declaring"

> +  * a single-dimensional array of size 3.  In some languages, the
> +  * construct declares a two-dimensional array.  It would be
> +  * preferable to make this construct illegal to avoid confusion.
> +  *
> +  * One possibility is to change the definition of the sequence
> +  * operator so that it does not return a constant- expression 
> and

Presumably the space after the - comes from a line break and isn't intentional.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/9] ff_fragment_shader: Use binding to set the sampler unit

2015-10-09 Thread Matt Turner

On Fri, Oct 9, 2015 at 6:52 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This is the way layout(binding=xxx) works from GLSL.  The old method
> just happened to work (and significantly predated support for
> layout(binding=xxx)), but future changes will break this.
>
> Signed-off-by: Ian Romanick 
> Cc: "10.6 11.0" 
> ---
>  src/mesa/main/ff_fragment_shader.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp 
> b/src/mesa/main/ff_fragment_shader.cpp
> index e4e2a18..f5a4fa5 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -981,7 +981,8 @@ static void load_texture( texenv_fragment_program *p, 
> GLuint unit )
>  * NOTE: The cast to int is important.  Without it, the constant will have
>  * type uint, and things later on may get confused.
>  */
> -   sampler->constant_value = new(p->mem_ctx) ir_constant(int(unit));
> +   sampler->data.explicit_binding = true;
> +   sampler->data.binding = unit;

With the comment immediately above removed,

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/9] glsl: Allow built-in functions as constant expressions in OpenGL ES 1.00

2015-10-09 Thread Matt Turner

On Fri, Oct 9, 2015 at 6:52 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> In d4a24745 (August 2012), Paul made functions calls not be constant
> expressions in GLSL ES 1.00.  Since this feature was added in desktop
> GLSL 1.20, we believed that it was added in GLSL ES 3.00.  That turns
> out to be completely wrong.  Built-in functions have always been allowed
> as constant expressions in GLSL ES, and the patch adds the (many) spec
> quotations to prove it.
>
> While we never previously encountered this, a later patch enfoces a GLSL

typo: enforces

> ES 1.00 rule that global variable initializers must be constant
> expressions.  Without this fix, severl dEQP tests fail.

typo: several

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 9/9] glsl: Never allow the sequence operator anywhere in an array size

2015-10-09 Thread Ian Romanick

On 10/09/2015 06:53 PM, Ian Romanick wrote:
> From: Ian Romanick 
> 

Forgot to add:

Fixes:


spec/glsl-1.20/compiler/structure-and-array-operations/array-size-sequence-in-parenthesis.vert
spec/glsl-es-1.00/compiler/array-sized-by-sequence-in-parenthesis.vert
spec/glsl-es-3.00/compiler/array-sized-by-sequence-in-parenthesis.vert

> Signed-off-by: Ian Romanick 
> ---
>  src/glsl/ast_to_hir.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index f34cbe0..a21f25c 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -2069,7 +2069,7 @@ process_array_size(exec_node *node,
> }
>  
> ir_constant *const size = ir->constant_expression_value();
> -   if (size == NULL) {
> +   if (size == NULL || array_size->has_sequence_subexpression()) {
>_mesa_glsl_error(& loc, state, "array size must be a "
> "constant valued expression");
>return 0;
> 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 2/9] ff_fragment_shader: Use binding to set the sampler unit

2015-10-09 Thread Chris Forbes

The comment above this about the cast to int can probably go away?

- Chris

On Sat, Oct 10, 2015 at 2:52 PM, Ian Romanick  wrote:

> From: Ian Romanick 
>
> This is the way layout(binding=xxx) works from GLSL.  The old method
> just happened to work (and significantly predated support for
> layout(binding=xxx)), but future changes will break this.
>
> Signed-off-by: Ian Romanick 
> Cc: "10.6 11.0" 
> ---
>  src/mesa/main/ff_fragment_shader.cpp | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/ff_fragment_shader.cpp
> b/src/mesa/main/ff_fragment_shader.cpp
> index e4e2a18..f5a4fa5 100644
> --- a/src/mesa/main/ff_fragment_shader.cpp
> +++ b/src/mesa/main/ff_fragment_shader.cpp
> @@ -981,7 +981,8 @@ static void load_texture( texenv_fragment_program *p,
> GLuint unit )
>  * NOTE: The cast to int is important.  Without it, the constant will
> have
>  * type uint, and things later on may get confused.
>  */
> -   sampler->constant_value = new(p->mem_ctx) ir_constant(int(unit));
> +   sampler->data.explicit_binding = true;
> +   sampler->data.binding = unit;
>
> deref = new(p->mem_ctx) ir_dereference_variable(sampler);
> tex->set_sampler(deref, glsl_type::vec4_type);
> --
> 2.1.0
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/9 v3] Apply GLSL ES initializer restrictions

2015-10-09 Thread Ian Romanick

So, this should have been a quick, easy fix.  One thing led to another,
and here we are at v3 of a 9 patch series.

There were some old bugs hanging around the code that we either never
noticed or just happend to work out okay.  The first 4 patches in the
series resolve those issues.  Patch 1 fixes a bug added 3 years ago.
I'm really, really surprised no application ever hit that one.  I only
noticed it because the patch 6 increases the exposure of the bug, and
several dEQP tests began failing.

The remaining 5 patches apply the GLSL ES restrictions on global
variable initializers (must be constant expressions) and disallow the
sequence operator (the comma) as a constant expression.  Patch 9 fixes a
piglit test from 2011 that tries to use sequence operator to size an
array.  From discussions in the ARB at that time, it seems that other
vendors also do not support this... though there is no documentation in
the test about which vendors pass the test.

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

[Mesa-dev] [PATCH 6/9] glsl: Restrict initializers for global variables to constant expression in ES

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

v2: Combine this check with the existing const and uniform checks.  This
change depends on the previous patch (glsl: Only set
ir_variable::constant_value for const-decorated variables).

Fixes:

ES2-CTS.shaders.negative.initialize
ES3-CTS.shaders.negative.initialize

spec/glsl-es-1.00/compiler/global-initializer/from-attribute.vert
spec/glsl-es-1.00/compiler/global-initializer/from-uniform.vert
spec/glsl-es-1.00/compiler/global-initializer/from-uniform.frag
spec/glsl-es-1.00/compiler/global-initializer/from-global.vert
spec/glsl-es-1.00/compiler/global-initializer/from-global.frag
spec/glsl-es-1.00/compiler/global-initializer/from-varying.frag
spec/glsl-es-3.00/compiler/global-initializer/from-uniform.vert
spec/glsl-es-3.00/compiler/global-initializer/from-uniform.frag
spec/glsl-es-3.00/compiler/global-initializer/from-in.vert
spec/glsl-es-3.00/compiler/global-initializer/from-in.frag
spec/glsl-es-3.00/compiler/global-initializer/from-global.vert
spec/glsl-es-3.00/compiler/global-initializer/from-global.frag

Note: spec/glsl-es-3.00/compiler/global-initializer/from-sequence.*
still fail because the result of a sequence operator is still considered
to be a constant expression.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92304
Reviewed-by: Tapani Pälli  [v1]
Reviewed-by: Iago Toral Quiroga  [v1]
Cc: "10.6 11.0" 
---
 src/glsl/ast_to_hir.cpp | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index e3d4c44..eefc7b7 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3213,9 +3213,19 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
 
/* Calculate the constant value if this is a const or uniform
 * declaration.
+*
+* Section 4.3 (Storage Qualifiers) of the GLSL ES 1.00.17 spec says:
+*
+* "Declarations of globals without a storage qualifier, or with
+* just the const qualifier, may include initializers, in which case
+* they will be initialized before the first line of main() is
+* executed.  Such initializers must be a constant expression."
+*
+* The same section of the GLSL ES 3.00.4 spec has similar language.
 */
if (type->qualifier.flags.q.constant
-   || type->qualifier.flags.q.uniform) {
+   || type->qualifier.flags.q.uniform
+   || (state->es_shader && state->current_function == NULL)) {
   ir_rvalue *new_rhs = validate_assignment(state, initializer_loc,
lhs, rhs, true);
   if (new_rhs != NULL) {
@@ -3223,6 +3233,11 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
 
  ir_constant *constant_value = rhs->constant_expression_value();
  if (!constant_value) {
+const char *const variable_mode =
+   (type->qualifier.flags.q.constant)
+   ? "const"
+   : ((type->qualifier.flags.q.uniform) ? "uniform" : "global");
+
 /* If ARB_shading_language_420pack is enabled, initializers of
  * const-qualified local variables do not have to be constant
  * expressions. Const-qualified global variables must still be
@@ -3233,8 +3248,7 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
_mesa_glsl_error(& initializer_loc, state,
 "initializer of %s variable `%s' must be a "
 "constant expression",
-(type->qualifier.flags.q.constant)
-? "const" : "uniform",
+variable_mode,
 decl->identifier);
if (var->type->is_numeric()) {
   /* Reduce cascading errors. */
-- 
2.1.0

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

[Mesa-dev] [PATCH 3/9] glsl/linker: Use constant_initializer instead of constant_value to initialize uniforms

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/glsl/link_uniform_initializers.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glsl/link_uniform_initializers.cpp 
b/src/glsl/link_uniform_initializers.cpp
index 0918d2a..065257b 100644
--- a/src/glsl/link_uniform_initializers.cpp
+++ b/src/glsl/link_uniform_initializers.cpp
@@ -326,9 +326,9 @@ link_set_uniform_initializers(struct gl_shader_program 
*prog,
 } else {
assert(!"Explicit binding not on a sampler, UBO or atomic.");
 }
- } else if (var->constant_value) {
+ } else if (var->constant_initializer) {
 linker::set_uniform_initializer(mem_ctx, prog, var->name,
-var->type, var->constant_value,
+var->type, 
var->constant_initializer,
 boolean_true);
  }
   }
-- 
2.1.0

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

[Mesa-dev] [PATCH 1/9] glsl: Allow built-in functions as constant expressions in OpenGL ES 1.00

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

In d4a24745 (August 2012), Paul made functions calls not be constant
expressions in GLSL ES 1.00.  Since this feature was added in desktop
GLSL 1.20, we believed that it was added in GLSL ES 3.00.  That turns
out to be completely wrong.  Built-in functions have always been allowed
as constant expressions in GLSL ES, and the patch adds the (many) spec
quotations to prove it.

While we never previously encountered this, a later patch enfoces a GLSL
ES 1.00 rule that global variable initializers must be constant
expressions.  Without this fix, severl dEQP tests fail.

Fixes:

tests/spec/glsl-es-1.00/compiler/const-initializer/from-function.frag
tests/spec/glsl-es-1.00/compiler/const-initializer/from-function.vert

tests/spec/glsl-es-1.00/compiler/const-initializer/from-sequence-in-function.frag

tests/spec/glsl-es-1.00/compiler/const-initializer/from-sequence-in-function.vert

Signed-off-by: Ian Romanick 
Cc: "10.0 10.1 10.2 10.3 10.4 10.5 10.6 11.0" 


Yes, I know we don't maintain stable branches that far back, but that
*is* how far back this bug goes!
---
 src/glsl/ast_function.cpp | 51 ++-
 1 file changed, 46 insertions(+), 5 deletions(-)

diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 26d4c62..6538992 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -437,13 +437,54 @@ generate_call(exec_list *instructions, 
ir_function_signature *sig,
   }
}
 
-   /* If the function call is a constant expression, don't generate any
-* instructions; just generate an ir_constant.
+   /* Section 4.3.2 (Const) of the GLSL 1.10.59 spec says:
+*
+* "Initializers for const declarations must be formed from literal
+* values, other const variables (not including function call
+* paramaters), or expressions of these.
+*
+* Constructors may be used in such expressions, but function calls may
+* not."
+*
+* Section 4.3.3 (Constant Expressions) of the GLSL 1.20.8 spec says:
+*
+* "A constant expression is one of
+*
+* ...
+*
+* - a built-in function call whose arguments are all constant
+*   expressions, with the exception of the texture lookup
+*   functions, the noise functions, and ftransform. The built-in
+*   functions dFdx, dFdy, and fwidth must return 0 when evaluated
+*   inside an initializer with an argument that is a constant
+*   expression."
+*
+* Section 5.10 (Constant Expressions) of the GLSL ES 1.00.17 spec says:
 *
-* Function calls were first allowed to be constant expressions in GLSL
-* 1.20 and GLSL ES 3.00.
+* "A constant expression is one of
+*
+* ...
+*
+* - a built-in function call whose arguments are all constant
+*   expressions, with the exception of the texture lookup
+*   functions."
+*
+* Section 4.3.3 (Constant Expressions) of the GLSL ES 3.00.4 spec says:
+*
+* "A constant expression is one of
+*
+* ...
+*
+* - a built-in function call whose arguments are all constant
+*   expressions, with the exception of the texture lookup
+*   functions.  The built-in functions dFdx, dFdy, and fwidth must
+*   return 0 when evaluated inside an initializer with an argument
+*   that is a constant expression."
+*
+* If the function call is a constant expression, don't generate any
+* instructions; just generate an ir_constant.
 */
-   if (state->is_version(120, 300)) {
+   if (state->is_version(120, 100)) {
   ir_constant *value = sig->constant_expression_value(actual_parameters, 
NULL);
   if (value != NULL) {
 return value;
-- 
2.1.0

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

[Mesa-dev] [PATCH 2/9] ff_fragment_shader: Use binding to set the sampler unit

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

This is the way layout(binding=xxx) works from GLSL.  The old method
just happened to work (and significantly predated support for
layout(binding=xxx)), but future changes will break this.

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/mesa/main/ff_fragment_shader.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/ff_fragment_shader.cpp 
b/src/mesa/main/ff_fragment_shader.cpp
index e4e2a18..f5a4fa5 100644
--- a/src/mesa/main/ff_fragment_shader.cpp
+++ b/src/mesa/main/ff_fragment_shader.cpp
@@ -981,7 +981,8 @@ static void load_texture( texenv_fragment_program *p, 
GLuint unit )
 * NOTE: The cast to int is important.  Without it, the constant will have
 * type uint, and things later on may get confused.
 */
-   sampler->constant_value = new(p->mem_ctx) ir_constant(int(unit));
+   sampler->data.explicit_binding = true;
+   sampler->data.binding = unit;
 
deref = new(p->mem_ctx) ir_dereference_variable(sampler);
tex->set_sampler(deref, glsl_type::vec4_type);
-- 
2.1.0

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

[Mesa-dev] [PATCH 4/9] glsl: Use constant_initializer instead of constant_value to determine whether to keep an unused uniform

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

This even matches the comment "uniform initializers are precious, and
could get used by another stage."

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/glsl/opt_dead_code.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index 2cb7f41..071485a 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -103,7 +103,7 @@ do_dead_code(exec_list *instructions, bool 
uniform_locations_assigned)
  */
  if (entry->var->data.mode == ir_var_uniform ||
  entry->var->data.mode == ir_var_shader_storage) {
-if (uniform_locations_assigned || entry->var->constant_value)
+if (uniform_locations_assigned || entry->var->constant_initializer)
continue;
 
 /* Section 2.11.6 (Uniform Variables) of the OpenGL ES 3.0.3 spec
-- 
2.1.0

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

[Mesa-dev] [PATCH 9/9] glsl: Never allow the sequence operator anywhere in an array size

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/glsl/ast_to_hir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index f34cbe0..a21f25c 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2069,7 +2069,7 @@ process_array_size(exec_node *node,
}
 
ir_constant *const size = ir->constant_expression_value();
-   if (size == NULL) {
+   if (size == NULL || array_size->has_sequence_subexpression()) {
   _mesa_glsl_error(& loc, state, "array size must be a "
"constant valued expression");
   return 0;
-- 
2.1.0

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

[Mesa-dev] [PATCH 7/9] glsl: Add method to determine whether an expression contains the sequence operator

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

This will be used in the next patch to enforce some language sematics.

v2: Fix inverted logic in
ast_function_expression::has_sequence_subexpression.  The method
originally had a different name and a different meaning.  I fixed the
logic in ast_to_hir.cpp, but I only changed the names in
ast_function.cpp.

Signed-off-by: Ian Romanick 
Reviewed-by: Marta Lofstedt  [v1]
Cc: "10.6 11.0" 
---
 src/glsl/ast.h|  6 
 src/glsl/ast_function.cpp | 11 +++
 src/glsl/ast_to_hir.cpp   | 80 +++
 3 files changed, 97 insertions(+)

diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 4c31436..67faacd 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -62,6 +62,8 @@ public:
virtual ir_rvalue *hir(exec_list *instructions,
  struct _mesa_glsl_parse_state *state);
 
+   virtual bool has_sequence_subexpression() const;
+
/**
 * Retrieve the source location of an AST node
 *
@@ -221,6 +223,8 @@ public:
virtual void hir_no_rvalue(exec_list *instructions,
   struct _mesa_glsl_parse_state *state);
 
+   virtual bool has_sequence_subexpression() const;
+
ir_rvalue *do_hir(exec_list *instructions,
  struct _mesa_glsl_parse_state *state,
  bool needs_rvalue);
@@ -299,6 +303,8 @@ public:
virtual void hir_no_rvalue(exec_list *instructions,
   struct _mesa_glsl_parse_state *state);
 
+   virtual bool has_sequence_subexpression() const;
+
 private:
/**
 * Is this function call actually a constructor?
diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
index 6538992..b72eb3f 100644
--- a/src/glsl/ast_function.cpp
+++ b/src/glsl/ast_function.cpp
@@ -1999,6 +1999,17 @@ ast_function_expression::hir(exec_list *instructions,
unreachable("not reached");
 }
 
+bool
+ast_function_expression::has_sequence_subexpression() const
+{
+   foreach_list_typed(const ast_node, ast, link, &this->expressions) {
+  if (ast->has_sequence_subexpression())
+ return true;
+   }
+
+   return false;
+}
+
 ir_rvalue *
 ast_aggregate_initializer::hir(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index eefc7b7..6af0f80 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -1004,6 +1004,12 @@ ast_node::hir(exec_list *instructions, struct 
_mesa_glsl_parse_state *state)
return NULL;
 }
 
+bool
+ast_node::has_sequence_subexpression() const
+{
+   return false;
+}
+
 void
 ast_function_expression::hir_no_rvalue(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
@@ -1915,6 +1921,80 @@ ast_expression::do_hir(exec_list *instructions,
return result;
 }
 
+bool
+ast_expression::has_sequence_subexpression() const
+{
+   switch (this->oper) {
+   case ast_plus:
+   case ast_neg:
+   case ast_bit_not:
+   case ast_logic_not:
+   case ast_pre_inc:
+   case ast_pre_dec:
+   case ast_post_inc:
+   case ast_post_dec:
+  return this->subexpressions[0]->has_sequence_subexpression();
+
+   case ast_assign:
+   case ast_add:
+   case ast_sub:
+   case ast_mul:
+   case ast_div:
+   case ast_mod:
+   case ast_lshift:
+   case ast_rshift:
+   case ast_less:
+   case ast_greater:
+   case ast_lequal:
+   case ast_gequal:
+   case ast_nequal:
+   case ast_equal:
+   case ast_bit_and:
+   case ast_bit_xor:
+   case ast_bit_or:
+   case ast_logic_and:
+   case ast_logic_or:
+   case ast_logic_xor:
+   case ast_array_index:
+   case ast_mul_assign:
+   case ast_div_assign:
+   case ast_add_assign:
+   case ast_sub_assign:
+   case ast_mod_assign:
+   case ast_ls_assign:
+   case ast_rs_assign:
+   case ast_and_assign:
+   case ast_xor_assign:
+   case ast_or_assign:
+  return this->subexpressions[0]->has_sequence_subexpression() ||
+ this->subexpressions[1]->has_sequence_subexpression();
+
+   case ast_conditional:
+  return this->subexpressions[0]->has_sequence_subexpression() ||
+ this->subexpressions[1]->has_sequence_subexpression() ||
+ this->subexpressions[2]->has_sequence_subexpression();
+
+   case ast_sequence:
+  return true;
+
+   case ast_field_selection:
+   case ast_identifier:
+   case ast_int_constant:
+   case ast_uint_constant:
+   case ast_float_constant:
+   case ast_bool_constant:
+   case ast_double_constant:
+  return false;
+
+   case ast_aggregate:
+  unreachable("ast_aggregate: Should never get here.");
+
+   case ast_function_call:
+  unreachable("should be handled by ast_function_expression::hir");
+   }
+
+   return false;
+}
 
 ir_rvalue *
 ast_expression_statement::hir(exec_list *instructions,
-- 
2.1.0

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

[Mesa-dev] [PATCH 8/9] glsl: In later GLSL versions, sequence operator is cannot be a constant expression

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

Fixes:
ES3-CTS.shaders.negative.constant_sequence

spec/glsl-es-3.00/compiler/global-initializer/from-sequence.vert
spec/glsl-es-3.00/compiler/global-initializer/from-sequence.frag

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/glsl/ast_to_hir.cpp | 43 ++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 6af0f80..f34cbe0 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3311,8 +3311,49 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
   if (new_rhs != NULL) {
  rhs = new_rhs;
 
+ /* Section 4.3.3 (Constant Expressions) of the GLSL ES 3.00.4 spec
+  * says:
+  *
+  * "A constant expression is one of
+  *
+  *...
+  *
+  *- an expression formed by an operator on operands that are
+  *  all constant expressions, including getting an element of
+  *  a constant array, or a field of a constant structure, or
+  *  components of a constant vector.  However, the sequence
+  *  operator ( , ) and the assignment operators ( =, +=, ...)
+  *  are not included in the operators that can create a
+  *  constant expression."
+  *
+  * Section 12.43 (Sequence operator and constant expressions) says:
+  *
+  * "Should the following construct be allowed?
+  *
+  * float a[2,3];
+  *
+  * The expression within the brackets uses the sequence operator
+  * (',') and returns the integer 3 so the construct is decl aring
+  * a single-dimensional array of size 3.  In some languages, the
+  * construct declares a two-dimensional array.  It would be
+  * preferable to make this construct illegal to avoid confusion.
+  *
+  * One possibility is to change the definition of the sequence
+  * operator so that it does not return a constant- expression and
+  * hence cannot be used to declare an array size.
+  *
+  * RESOLUTION: The result of a sequence operator is not a
+  * constant-expression."
+  *
+  * Section 4.3.3 (Constant Expressions) of the GLSL 4.30.9 spec
+  * contains language almost identical to the section 4.3.3 in the
+  * GLSL ES 3.00.4 spec.  This is a new limitation for these GLSL
+  * versions.
+  */
  ir_constant *constant_value = rhs->constant_expression_value();
- if (!constant_value) {
+ if (!constant_value ||
+ (state->is_version(430, 300) &&
+  decl->initializer->has_sequence_subexpression())) {
 const char *const variable_mode =
(type->qualifier.flags.q.constant)
? "const"
-- 
2.1.0

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

[Mesa-dev] [PATCH 5/9] glsl: Only set ir_variable::constant_value for const-decorated variables

2015-10-09 Thread Ian Romanick

From: Ian Romanick 

Right now we're also setting for uniforms, and that doesn't seem to hurt
things.  The next patch will make general global variables in GLSL ES,
and those definitely should not have constant_value set!

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/glsl/ast_to_hir.cpp | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 9511440..e3d4c44 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -3238,17 +3238,20 @@ process_initializer(ir_variable *var, ast_declaration 
*decl,
 decl->identifier);
if (var->type->is_numeric()) {
   /* Reduce cascading errors. */
-  var->constant_value = ir_constant::zero(state, var->type);
+  var->constant_value = type->qualifier.flags.q.constant
+ ? ir_constant::zero(state, var->type) : NULL;
}
 }
  } else {
 rhs = constant_value;
-var->constant_value = constant_value;
+var->constant_value = type->qualifier.flags.q.constant
+   ? constant_value : NULL;
  }
   } else {
  if (var->type->is_numeric()) {
 /* Reduce cascading errors. */
-var->constant_value = ir_constant::zero(state, var->type);
+var->constant_value = type->qualifier.flags.q.constant
+   ? ir_constant::zero(state, var->type) : NULL;
  }
   }
}
-- 
2.1.0

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

Re: [Mesa-dev] [PATCH] glsl: couple shader_enums cleanups

2015-10-09 Thread Rob Clark

On Fri, Oct 9, 2015 at 8:07 PM, Emil Velikov  wrote:
> On 9 October 2015 at 23:27, Rob Clark  wrote:
>> On Fri, Oct 9, 2015 at 5:57 PM, Emil Velikov  
>> wrote:
>>> On 9 October 2015 at 21:31, Rob Clark  wrote:
 From: Rob Clark 

 Add missing enum to gl_system_value_name() and move VARYING_SLOT_MAX /
 FRAG_RESULT_MAX / etc into shader_enums.h as suggested by Emil.

 Reported-by: Emil Velikov 
 Signed-off-by: Rob Clark 
 ---
 Note: punted on the STATIC_ASSERT() thing for now..  kinda wanted some-
 think more like tgsi_strings_check() where we check everything once on
 startup, so you don't have to trigger something that calls the various
 xyz_name() to realize something is out of sync.

>>> I'm confused - isn't static_assert a compile thing ?
>>
>> oh, heh, good point..
>>
  src/glsl/nir/shader_enums.c | 1 +
  src/glsl/nir/shader_enums.h | 7 +++
  src/mesa/main/mtypes.h  | 5 -
  3 files changed, 8 insertions(+), 5 deletions(-)

 diff --git a/src/glsl/nir/shader_enums.c b/src/glsl/nir/shader_enums.c
 index 3722475..7fcbe81 100644
 --- a/src/glsl/nir/shader_enums.c
 +++ b/src/glsl/nir/shader_enums.c
 @@ -169,6 +169,7 @@ const char * gl_system_value_name(gl_system_value 
 sysval)
   ENUM(SYSTEM_VALUE_TESS_LEVEL_INNER),
   ENUM(SYSTEM_VALUE_LOCAL_INVOCATION_ID),
   ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
 + ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
   ENUM(SYSTEM_VALUE_VERTEX_CNT),
 };
 return NAME(sysval);
 diff --git a/src/glsl/nir/shader_enums.h b/src/glsl/nir/shader_enums.h
 index 2a5d2c5..77638ba 100644
 --- a/src/glsl/nir/shader_enums.h
 +++ b/src/glsl/nir/shader_enums.h
 @@ -233,6 +233,11 @@ typedef enum
 VARYING_SLOT_VAR31,
  } gl_varying_slot;

 +
 +#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
>>> I'd keep this and FRAG_RESULT_MAX defined as FOO + 1. Otherwise we'll
>>> end in funny spaghetti of header dependencies due to the extra two
>>> macros.
>>
>> not quite sure, but it sounds like you are asking to open-code
>> MAX_VARYINGS?  I don't think that is needed since that seems to
>> basically be a global config.h type thing (I mean mesa/main/config.h,
>> not autoconf one)
>>
>> There isn't really *supposed* to be a VARYING_SLOT_VAR(n-1) (ignoring
>> the fact that I added them simply to get nice string values to print
>> out in nir_print)
>>
> I was thinking that #define VARYING_SLOT_MAX (VARYING_SLOT_VAR + 1)
> /*VARYING_SLOT_VAR(n) */ is the preferred way.
> Hmm can you please point me in the right direction, as to why having
> VARYING_SLOT_VAR(n-1) is a bad idea ?

A few of the enums are meant to have their last element be interpreted
as xyz0 + n (where n < #define MAX_xyz from config.h)

I guess technically the max isn't something that is likely to change
frequently but if we ignore the MAX_xyz from config.h that means we
have two places to update if the max was ever increased.

 +#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
 +#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
 +
>>> As there are defined 'on top'/'after' of the existing enum perhaps we
>>> should keep them alongside their PRIM_MAX...UNKNOWN brethren ?
>>
>> PRIM_MAX is a different thing, not related to anything that is already
>> in shader_enums..
>>
> I had in mind the relationship wrt the respective enums/macros, rather
> than their meaning. Although with the _MAX above in mind, I'm likely
> missing something.

prim == gl draw primitive (ie. tris/tristrip/quads/points/etc)..  not
something that is internal to mesa or in shader_enums.h..

BR,
-R

> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/glformats: Undo code changes from _mesa_base_tex_format() move

2015-10-09 Thread Matt Turner

On Fri, Oct 9, 2015 at 3:26 PM, Nanley Chery  wrote:
> From: Nanley Chery 
>
> The refactoring commit, c6bf1cd, accidentally reverted cd49b97
> and 99b1f47. These changes caused more code to be added to the
> function and removed the existing support for ASTC. This patch
> reverts those modifications.

I can see missing such a thing during review in a big "move this from
here to there" commit, but the author should have noticed there was a
problem when git rebase turned up conflicts...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: couple shader_enums cleanups

2015-10-09 Thread Emil Velikov

On 9 October 2015 at 23:27, Rob Clark  wrote:
> On Fri, Oct 9, 2015 at 5:57 PM, Emil Velikov  wrote:
>> On 9 October 2015 at 21:31, Rob Clark  wrote:
>>> From: Rob Clark 
>>>
>>> Add missing enum to gl_system_value_name() and move VARYING_SLOT_MAX /
>>> FRAG_RESULT_MAX / etc into shader_enums.h as suggested by Emil.
>>>
>>> Reported-by: Emil Velikov 
>>> Signed-off-by: Rob Clark 
>>> ---
>>> Note: punted on the STATIC_ASSERT() thing for now..  kinda wanted some-
>>> think more like tgsi_strings_check() where we check everything once on
>>> startup, so you don't have to trigger something that calls the various
>>> xyz_name() to realize something is out of sync.
>>>
>> I'm confused - isn't static_assert a compile thing ?
>
> oh, heh, good point..
>
>>>  src/glsl/nir/shader_enums.c | 1 +
>>>  src/glsl/nir/shader_enums.h | 7 +++
>>>  src/mesa/main/mtypes.h  | 5 -
>>>  3 files changed, 8 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/src/glsl/nir/shader_enums.c b/src/glsl/nir/shader_enums.c
>>> index 3722475..7fcbe81 100644
>>> --- a/src/glsl/nir/shader_enums.c
>>> +++ b/src/glsl/nir/shader_enums.c
>>> @@ -169,6 +169,7 @@ const char * gl_system_value_name(gl_system_value 
>>> sysval)
>>>   ENUM(SYSTEM_VALUE_TESS_LEVEL_INNER),
>>>   ENUM(SYSTEM_VALUE_LOCAL_INVOCATION_ID),
>>>   ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
>>> + ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
>>>   ENUM(SYSTEM_VALUE_VERTEX_CNT),
>>> };
>>> return NAME(sysval);
>>> diff --git a/src/glsl/nir/shader_enums.h b/src/glsl/nir/shader_enums.h
>>> index 2a5d2c5..77638ba 100644
>>> --- a/src/glsl/nir/shader_enums.h
>>> +++ b/src/glsl/nir/shader_enums.h
>>> @@ -233,6 +233,11 @@ typedef enum
>>> VARYING_SLOT_VAR31,
>>>  } gl_varying_slot;
>>>
>>> +
>>> +#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
>> I'd keep this and FRAG_RESULT_MAX defined as FOO + 1. Otherwise we'll
>> end in funny spaghetti of header dependencies due to the extra two
>> macros.
>
> not quite sure, but it sounds like you are asking to open-code
> MAX_VARYINGS?  I don't think that is needed since that seems to
> basically be a global config.h type thing (I mean mesa/main/config.h,
> not autoconf one)
>
> There isn't really *supposed* to be a VARYING_SLOT_VAR(n-1) (ignoring
> the fact that I added them simply to get nice string values to print
> out in nir_print)
>
I was thinking that #define VARYING_SLOT_MAX (VARYING_SLOT_VAR + 1)
/*VARYING_SLOT_VAR(n) */ is the preferred way.
Hmm can you please point me in the right direction, as to why having
VARYING_SLOT_VAR(n-1) is a bad idea ?

>>> +#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
>>> +#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
>>> +
>> As there are defined 'on top'/'after' of the existing enum perhaps we
>> should keep them alongside their PRIM_MAX...UNKNOWN brethren ?
>
> PRIM_MAX is a different thing, not related to anything that is already
> in shader_enums..
>
I had in mind the relationship wrt the respective enums/macros, rather
than their meaning. Although with the _MAX above in mind, I'm likely
missing something.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa/glformats: Undo code changes from _mesa_base_tex_format() move

2015-10-09 Thread Nanley Chery

From: Nanley Chery 

The refactoring commit, c6bf1cd, accidentally reverted cd49b97
and 99b1f47. These changes caused more code to be added to the
function and removed the existing support for ASTC. This patch
reverts those modifications.

v2. Actually include ASTC support again.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92221
Cc: "11.0" 
Signed-off-by: Nanley Chery 
---
 src/mesa/main/glformats.c | 149 +++---
 1 file changed, 8 insertions(+), 141 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index faa6382..2ed42ea 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2275,45 +2275,16 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   ; /* fallthrough */
}
 
-   if (ctx->Extensions.TDFX_texture_compression_FXT1) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB_FXT1_3DFX:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA_FXT1_3DFX:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
+   if (_mesa_is_compressed_format(ctx, internalFormat)) {
+  GLenum base_compressed =
+ _mesa_gl_compressed_format_base_format(internalFormat);
+  if (base_compressed)
+return base_compressed;
}
 
-   /* Assume that the ANGLE flag will always be set if the EXT flag is set.
-*/
-   if (ctx->Extensions.ANGLE_texture_compression_dxt) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB_S3TC_DXT1_EXT:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA_S3TC_DXT1_EXT:
-  case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
-  case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (_mesa_is_desktop_gl(ctx)
-   && ctx->Extensions.ANGLE_texture_compression_dxt) {
-  switch (internalFormat) {
-  case GL_RGB_S3TC:
-  case GL_RGB4_S3TC:
- return GL_RGB;
-  case GL_RGBA_S3TC:
-  case GL_RGBA4_S3TC:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
-   }
+   if (ctx->Extensions.KHR_texture_compression_astc_ldr &&
+  _mesa_is_astc_format(internalFormat))
+return GL_RGBA;
 
if (ctx->Extensions.MESA_ycbcr_texture) {
   if (internalFormat == GL_YCBCR_MESA)
@@ -2390,16 +2361,10 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   case GL_SRGB8_EXT:
   case GL_COMPRESSED_SRGB_EXT:
  return GL_RGB;
-  case GL_COMPRESSED_SRGB_S3TC_DXT1_EXT:
- return ctx->Extensions.EXT_texture_compression_s3tc ? GL_RGB : -1;
   case GL_SRGB_ALPHA_EXT:
   case GL_SRGB8_ALPHA8_EXT:
   case GL_COMPRESSED_SRGB_ALPHA_EXT:
  return GL_RGBA;
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT:
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT:
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT:
- return ctx->Extensions.EXT_texture_compression_s3tc ? GL_RGBA : -1;
   case GL_SLUMINANCE_ALPHA_EXT:
   case GL_SLUMINANCE8_ALPHA8_EXT:
   case GL_COMPRESSED_SLUMINANCE_ALPHA_EXT:
@@ -2544,104 +2509,6 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   }
}
 
-   if (ctx->Extensions.ARB_texture_compression_rgtc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RED_RGTC1:
-  case GL_COMPRESSED_SIGNED_RED_RGTC1:
- return GL_RED;
-  case GL_COMPRESSED_RG_RGTC2:
-  case GL_COMPRESSED_SIGNED_RG_RGTC2:
- return GL_RG;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.EXT_texture_compression_latc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_LUMINANCE_LATC1_EXT:
-  case GL_COMPRESSED_SIGNED_LUMINANCE_LATC1_EXT:
- return GL_LUMINANCE;
-  case GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT:
-  case GL_COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_EXT:
- return GL_LUMINANCE_ALPHA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.ATI_texture_compression_3dc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI:
- return GL_LUMINANCE_ALPHA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.OES_compressed_ETC1_RGB8_texture) {
-  switch (internalFormat) {
-  case GL_ETC1_RGB8_OES:
- return GL_RGB;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB8_ETC2:
-  case GL_COMPRESSED_SRGB8_ETC2:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA8_ETC2_EAC:
-  case GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC:
-  case GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2:
-  case GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2:
- return GL_RGBA;
-  case GL_COMPRESSED_R11_EAC:
-

Re: [Mesa-dev] [PATCH] glsl: couple shader_enums cleanups

2015-10-09 Thread Rob Clark

On Fri, Oct 9, 2015 at 5:57 PM, Emil Velikov  wrote:
> On 9 October 2015 at 21:31, Rob Clark  wrote:
>> From: Rob Clark 
>>
>> Add missing enum to gl_system_value_name() and move VARYING_SLOT_MAX /
>> FRAG_RESULT_MAX / etc into shader_enums.h as suggested by Emil.
>>
>> Reported-by: Emil Velikov 
>> Signed-off-by: Rob Clark 
>> ---
>> Note: punted on the STATIC_ASSERT() thing for now..  kinda wanted some-
>> think more like tgsi_strings_check() where we check everything once on
>> startup, so you don't have to trigger something that calls the various
>> xyz_name() to realize something is out of sync.
>>
> I'm confused - isn't static_assert a compile thing ?

oh, heh, good point..

>>  src/glsl/nir/shader_enums.c | 1 +
>>  src/glsl/nir/shader_enums.h | 7 +++
>>  src/mesa/main/mtypes.h  | 5 -
>>  3 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/glsl/nir/shader_enums.c b/src/glsl/nir/shader_enums.c
>> index 3722475..7fcbe81 100644
>> --- a/src/glsl/nir/shader_enums.c
>> +++ b/src/glsl/nir/shader_enums.c
>> @@ -169,6 +169,7 @@ const char * gl_system_value_name(gl_system_value sysval)
>>   ENUM(SYSTEM_VALUE_TESS_LEVEL_INNER),
>>   ENUM(SYSTEM_VALUE_LOCAL_INVOCATION_ID),
>>   ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
>> + ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
>>   ENUM(SYSTEM_VALUE_VERTEX_CNT),
>> };
>> return NAME(sysval);
>> diff --git a/src/glsl/nir/shader_enums.h b/src/glsl/nir/shader_enums.h
>> index 2a5d2c5..77638ba 100644
>> --- a/src/glsl/nir/shader_enums.h
>> +++ b/src/glsl/nir/shader_enums.h
>> @@ -233,6 +233,11 @@ typedef enum
>> VARYING_SLOT_VAR31,
>>  } gl_varying_slot;
>>
>> +
>> +#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
> I'd keep this and FRAG_RESULT_MAX defined as FOO + 1. Otherwise we'll
> end in funny spaghetti of header dependencies due to the extra two
> macros.

not quite sure, but it sounds like you are asking to open-code
MAX_VARYINGS?  I don't think that is needed since that seems to
basically be a global config.h type thing (I mean mesa/main/config.h,
not autoconf one)

There isn't really *supposed* to be a VARYING_SLOT_VAR(n-1) (ignoring
the fact that I added them simply to get nice string values to print
out in nir_print)

>> +#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
>> +#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
>> +
> As there are defined 'on top'/'after' of the existing enum perhaps we
> should keep them alongside their PRIM_MAX...UNKNOWN brethren ?

PRIM_MAX is a different thing, not related to anything that is already
in shader_enums..

BR,
-R

> Thanks for sticking with my suggestion.
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa/glformats: Undo code changes from _mesa_base_tex_format() move

2015-10-09 Thread Nanley Chery

From: Nanley Chery 

The refactoring commit, c6bf1cd, accidentally reverted cd49b97
and 99b1f47. These changes caused more code to be added to the
function and removed the existing support for ASTC. This patch
reverts those modifications.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92221
Cc: "11.0" 
Signed-off-by: Nanley Chery 
---
 src/mesa/main/glformats.c | 147 ++
 1 file changed, 5 insertions(+), 142 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index faa6382..dfa6c2e 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2275,44 +2275,11 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   ; /* fallthrough */
}
 
-   if (ctx->Extensions.TDFX_texture_compression_FXT1) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB_FXT1_3DFX:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA_FXT1_3DFX:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   /* Assume that the ANGLE flag will always be set if the EXT flag is set.
-*/
-   if (ctx->Extensions.ANGLE_texture_compression_dxt) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB_S3TC_DXT1_EXT:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA_S3TC_DXT1_EXT:
-  case GL_COMPRESSED_RGBA_S3TC_DXT3_EXT:
-  case GL_COMPRESSED_RGBA_S3TC_DXT5_EXT:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (_mesa_is_desktop_gl(ctx)
-   && ctx->Extensions.ANGLE_texture_compression_dxt) {
-  switch (internalFormat) {
-  case GL_RGB_S3TC:
-  case GL_RGB4_S3TC:
- return GL_RGB;
-  case GL_RGBA_S3TC:
-  case GL_RGBA4_S3TC:
- return GL_RGBA;
-  default:
- ; /* fallthrough */
-  }
+   if (_mesa_is_compressed_format(ctx, internalFormat)) {
+  GLenum base_compressed =
+ _mesa_gl_compressed_format_base_format(internalFormat);
+  if (base_compressed)
+return base_compressed;
}
 
if (ctx->Extensions.MESA_ycbcr_texture) {
@@ -2390,16 +2357,10 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   case GL_SRGB8_EXT:
   case GL_COMPRESSED_SRGB_EXT:
  return GL_RGB;
-  case GL_COMPRESSED_SRGB_S3TC_DXT1_EXT:
- return ctx->Extensions.EXT_texture_compression_s3tc ? GL_RGB : -1;
   case GL_SRGB_ALPHA_EXT:
   case GL_SRGB8_ALPHA8_EXT:
   case GL_COMPRESSED_SRGB_ALPHA_EXT:
  return GL_RGBA;
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT:
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT3_EXT:
-  case GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT:
- return ctx->Extensions.EXT_texture_compression_s3tc ? GL_RGBA : -1;
   case GL_SLUMINANCE_ALPHA_EXT:
   case GL_SLUMINANCE8_ALPHA8_EXT:
   case GL_COMPRESSED_SLUMINANCE_ALPHA_EXT:
@@ -2544,104 +2505,6 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   }
}
 
-   if (ctx->Extensions.ARB_texture_compression_rgtc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RED_RGTC1:
-  case GL_COMPRESSED_SIGNED_RED_RGTC1:
- return GL_RED;
-  case GL_COMPRESSED_RG_RGTC2:
-  case GL_COMPRESSED_SIGNED_RG_RGTC2:
- return GL_RG;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.EXT_texture_compression_latc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_LUMINANCE_LATC1_EXT:
-  case GL_COMPRESSED_SIGNED_LUMINANCE_LATC1_EXT:
- return GL_LUMINANCE;
-  case GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT:
-  case GL_COMPRESSED_SIGNED_LUMINANCE_ALPHA_LATC2_EXT:
- return GL_LUMINANCE_ALPHA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.ATI_texture_compression_3dc) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI:
- return GL_LUMINANCE_ALPHA;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (ctx->Extensions.OES_compressed_ETC1_RGB8_texture) {
-  switch (internalFormat) {
-  case GL_ETC1_RGB8_OES:
- return GL_RGB;
-  default:
- ; /* fallthrough */
-  }
-   }
-
-   if (_mesa_is_gles3(ctx) || ctx->Extensions.ARB_ES3_compatibility) {
-  switch (internalFormat) {
-  case GL_COMPRESSED_RGB8_ETC2:
-  case GL_COMPRESSED_SRGB8_ETC2:
- return GL_RGB;
-  case GL_COMPRESSED_RGBA8_ETC2_EAC:
-  case GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC:
-  case GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2:
-  case GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2:
- return GL_RGBA;
-  case GL_COMPRESSED_R11_EAC:
-  case GL_COMPRESSED_SIGNED_R11_EAC:
- return GL_RED;
-  case GL_COMPRESSED_RG11_EAC:
-  case GL_COMPRESSED_SIGNED_RG11_EAC:
- return GL_RG;
-  default:
- ; /* fallthrough */
-

Re: [Mesa-dev] [PATCH] u_vbuf: fix vb slot assignment for translated buffers

2015-10-09 Thread Marek Olšák

Do you still have commit access and should somebody else push this?

Marek

On Sun, Oct 4, 2015 at 2:19 PM, Marek Olšák  wrote:
> Oh, I forgot this:
>
> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Sun, Oct 4, 2015 at 2:03 PM, Marek Olšák  wrote:
>> Nice catch. Please add this to the commit message:
>>
>> Cc: mesa-sta...@lists.freedesktop.org
>>
>> It will be automatically picked for 11.0 after you push it.
>>
>> Marek
>>
>> On Sun, Oct 4, 2015 at 12:09 PM, Nicolai Hähnle  wrote:
>>> Vertex attributes of different categories (constant/per-instance/
>>> per-vertex) go into different buffers for translation, and this is now
>>> properly reflected in the vertex buffers passed to the driver.
>>>
>>> Fixes e.g. piglit's point-vertex-id divisor test.
>>> ---
>>>  src/gallium/auxiliary/util/u_vbuf.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/gallium/auxiliary/util/u_vbuf.c 
>>> b/src/gallium/auxiliary/util/u_vbuf.c
>>> index 3d2193c..b31ada1 100644
>>> --- a/src/gallium/auxiliary/util/u_vbuf.c
>>> +++ b/src/gallium/auxiliary/util/u_vbuf.c
>>> @@ -544,6 +544,7 @@ u_vbuf_translate_find_free_vb_slots(struct u_vbuf *mgr,
>>>
>>>   index = ffs(unused_vb_mask) - 1;
>>>   fallback_vbs[type] = index;
>>> + unused_vb_mask &= ~(1 << index);
>>>   /*printf("found slot=%i for type=%i\n", index, type);*/
>>>}
>>> }
>>> --
>>> 2.1.4
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: couple shader_enums cleanups

2015-10-09 Thread Emil Velikov

On 9 October 2015 at 21:31, Rob Clark  wrote:
> From: Rob Clark 
>
> Add missing enum to gl_system_value_name() and move VARYING_SLOT_MAX /
> FRAG_RESULT_MAX / etc into shader_enums.h as suggested by Emil.
>
> Reported-by: Emil Velikov 
> Signed-off-by: Rob Clark 
> ---
> Note: punted on the STATIC_ASSERT() thing for now..  kinda wanted some-
> think more like tgsi_strings_check() where we check everything once on
> startup, so you don't have to trigger something that calls the various
> xyz_name() to realize something is out of sync.
>
I'm confused - isn't static_assert a compile thing ?

>  src/glsl/nir/shader_enums.c | 1 +
>  src/glsl/nir/shader_enums.h | 7 +++
>  src/mesa/main/mtypes.h  | 5 -
>  3 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/nir/shader_enums.c b/src/glsl/nir/shader_enums.c
> index 3722475..7fcbe81 100644
> --- a/src/glsl/nir/shader_enums.c
> +++ b/src/glsl/nir/shader_enums.c
> @@ -169,6 +169,7 @@ const char * gl_system_value_name(gl_system_value sysval)
>   ENUM(SYSTEM_VALUE_TESS_LEVEL_INNER),
>   ENUM(SYSTEM_VALUE_LOCAL_INVOCATION_ID),
>   ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
> + ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
>   ENUM(SYSTEM_VALUE_VERTEX_CNT),
> };
> return NAME(sysval);
> diff --git a/src/glsl/nir/shader_enums.h b/src/glsl/nir/shader_enums.h
> index 2a5d2c5..77638ba 100644
> --- a/src/glsl/nir/shader_enums.h
> +++ b/src/glsl/nir/shader_enums.h
> @@ -233,6 +233,11 @@ typedef enum
> VARYING_SLOT_VAR31,
>  } gl_varying_slot;
>
> +
> +#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
I'd keep this and FRAG_RESULT_MAX defined as FOO + 1. Otherwise we'll
end in funny spaghetti of header dependencies due to the extra two
macros.

> +#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
> +#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
> +
As there are defined 'on top'/'after' of the existing enum perhaps we
should keep them alongside their PRIM_MAX...UNKNOWN brethren ?

Thanks for sticking with my suggestion.
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] program: remove _mesa_init_*_program wrappers

2015-10-09 Thread Emil Velikov

On 9 October 2015 at 18:38, Marek Olšák  wrote:
> On Fri, Oct 9, 2015 at 7:33 PM, Emil Velikov  wrote:
>> On 9 October 2015 at 17:55, Marek Olšák  wrote:
[snip]
>>> I think GL_FRAGMENT_PROGRAM_NV is from an NV extension supported by
>>> some classic drivers but not st/mesa.
>>>
>> Seems to be part of GL_NV_fragment_program, which was removed a while ago 
>> with
>
> I think it's GL_NV_fragment_program_option, so you can't just remove
> it unless you want to remove the whole extension.
>
Just double-checked the official website plus the SVN repo and both
say that GL_FRAGMENT_PROGRAM_NV is part of GL_NV_fragment_program. Wrt
the *_option I'll leave it's fate to others.

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

[Mesa-dev] [PATCH] glsl: couple shader_enums cleanups

2015-10-09 Thread Rob Clark

From: Rob Clark 

Add missing enum to gl_system_value_name() and move VARYING_SLOT_MAX /
FRAG_RESULT_MAX / etc into shader_enums.h as suggested by Emil.

Reported-by: Emil Velikov 
Signed-off-by: Rob Clark 
---
Note: punted on the STATIC_ASSERT() thing for now..  kinda wanted some-
think more like tgsi_strings_check() where we check everything once on
startup, so you don't have to trigger something that calls the various
xyz_name() to realize something is out of sync.

 src/glsl/nir/shader_enums.c | 1 +
 src/glsl/nir/shader_enums.h | 7 +++
 src/mesa/main/mtypes.h  | 5 -
 3 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/glsl/nir/shader_enums.c b/src/glsl/nir/shader_enums.c
index 3722475..7fcbe81 100644
--- a/src/glsl/nir/shader_enums.c
+++ b/src/glsl/nir/shader_enums.c
@@ -169,6 +169,7 @@ const char * gl_system_value_name(gl_system_value sysval)
  ENUM(SYSTEM_VALUE_TESS_LEVEL_INNER),
  ENUM(SYSTEM_VALUE_LOCAL_INVOCATION_ID),
  ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
+ ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
  ENUM(SYSTEM_VALUE_VERTEX_CNT),
};
return NAME(sysval);
diff --git a/src/glsl/nir/shader_enums.h b/src/glsl/nir/shader_enums.h
index 2a5d2c5..77638ba 100644
--- a/src/glsl/nir/shader_enums.h
+++ b/src/glsl/nir/shader_enums.h
@@ -233,6 +233,11 @@ typedef enum
VARYING_SLOT_VAR31,
 } gl_varying_slot;
 
+
+#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
+#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
+#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
+
 const char * gl_varying_slot_name(gl_varying_slot slot);
 
 /**
@@ -473,4 +478,6 @@ typedef enum
 
 const char * gl_frag_result_name(gl_frag_result result);
 
+#define FRAG_RESULT_MAX(FRAG_RESULT_DATA0 + MAX_DRAW_BUFFERS)
+
 #endif /* SHADER_ENUMS_H */
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 0a54b20..ba94402 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -94,11 +94,6 @@ struct vbo_context;
 #define PRIM_OUTSIDE_BEGIN_END   (PRIM_MAX + 1)
 #define PRIM_UNKNOWN (PRIM_MAX + 2)
 
-#define VARYING_SLOT_MAX   (VARYING_SLOT_VAR0 + MAX_VARYING)
-#define VARYING_SLOT_PATCH0(VARYING_SLOT_MAX)
-#define VARYING_SLOT_TESS_MAX  (VARYING_SLOT_PATCH0 + MAX_VARYING)
-#define FRAG_RESULT_MAX(FRAG_RESULT_DATA0 + MAX_DRAW_BUFFERS)
-
 /**
  * Determine if the given gl_varying_slot appears in the fragment shader.
  */
-- 
2.4.3

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

[Mesa-dev] [Bug 92371] [HSW]deqp-gles2 Functional@shaders@constant_expressions@ sutests are failing 432 of 462 available tests

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92371

Matt Turner  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/DRI/i965
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92372] [HSW] deqp-gles2 functional.clipping.line/point are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92372

Matt Turner  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/DRI/i965
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92373] [HSW] deqpl-gles2 Functional@fbo@completeness@renderable sub cases are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92373

Matt Turner  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/DRI/i965
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92374] [HSW] deqp-gles2 functional@fbo@render@recreate_buffer are failing some tests (5)

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92374

Matt Turner  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/DRI/i965
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |
 QA Contact|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
   |org |ktop.org

--- Comment #2 from Matt Turner  ---
Please file i965 bugs against Component: Drivers/DRI/i965. You can use this
link directly:
https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa&component=Drivers/DRI/i965

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92374] [HSW] deqp-gles2 functional@fbo@render@recreate_buffer are failing some tests (5)

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92374

--- Comment #1 from Elio  ---
Created attachment 118790
  --> https://bugs.freedesktop.org/attachment.cgi?id=118790&action=edit
Terminal Output

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92374] [HSW] deqp-gles2 functional@fbo@render@recreate_buffer are failing some tests (5)

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92374

Bug ID: 92374
   Summary: [HSW] deqp-gles2 functional@fbo@render@recreate_buffer
are failing some tests (5)
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: elio.martinez.mon...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118789
  --> https://bugs.freedesktop.org/attachment.cgi?id=118789&action=edit
Dmesg logs

The following test cases are failing from
functional@fbo@render@recreate_buffer:

<%
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgb
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgba
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgba_depth_component16
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgba_stencil_index8
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgb_depth_component16
deqp-gles2@functional@fbo@render@recreate_colorbuffer@no_rebind_tex2d_rgb_stencil_index8
%>

Test Enviroment:

kernel: 4.3.0
Mesa: (11.2)git-
Xf86_video_intel:2.99.917
Libdrm:libdrm-2.4.65
Libva: 1.6.1
vaapi-in tel-driver: 1.6.1
Cairo: 1.14.2
Xserver: xorg-server-latests

Hardware:

Hardware
Platform: Intel NUC D54250WYK
Processor Intel Core I5-425OU 1.30 GHz
Software
Linux distribution: Ubuntu 14.04 LTS 64Bits
BIOS: WTLPT10H.86A.0021.2013.1.017.1606

Steps to reproduce:
Install Graphic stack with configuration mentioned before.
Install deqp tool.
Execute: sudo ./deqp-gles2
--deqp-case=dEQP-GLES2.functional.fbo.render.recreate_buffer.*

Expected Result: Test should pass without crash/error
Actual results: The mentioned test cases are failing

Please check attached logs

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: move shader_enums into nir

2015-10-09 Thread Rob Clark

On Fri, Oct 9, 2015 at 4:55 AM, Emil Velikov  wrote:
> On 8 October 2015 at 23:25, Rob Clark  wrote:
>> From: Rob Clark 
>>
>> First step towards inverting the dependency between glsl and nir (so nir
>> can be used without glsl).  Also solves this issue with 'make distclean'
>>
>>   Making distclean in mesa
>>   make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
>>   Makefile:2486: ../glsl/.deps/shader_enums.Plo: No such file or directory
>>   make[2]: *** No rule to make target '../glsl/.deps/shader_enums.Plo'. Stop.
>>   make[2]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
>>   Makefile:684: recipe for target 'distclean-recursive' failed
>>   make[1]: *** [distclean-recursive] Error 1
>>   make[1]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src'
>>   Makefile:615: recipe for target 'distclean-recursive' failed
>>   make: *** [distclean-recursive] Error 1
>>
>> Reported-by: Andy Furniss 
>> Signed-off-by: Rob Clark 
> Reviewed-by: Emil Velikov 
>
> You might want to pick (as a follow up?) some of these
>  - move VARYING_SLOT_MAX and FRAG_RESULT_MAX from mtypes.h to shader_enum.h
>  - add the missing SYSTEM_VALUE_NUM_WORK_GROUPS enum
>  - use STATIC_ASSERT

yeah, seams reasonable..  but follow up patches..

> I'm also wondering if we'd want to use a prefix for symbols (and
> files?) to easily draw the line between the different components.
> Through I'd suspect that it will turn into a bikeshed battle ;-)

yeah.. either way I'm kind of a fan of moving first and then renaming
as a separate patch..

BR,
-R

> Thanks
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92373] [HSW] deqpl-gles2 Functional@fbo@completeness@renderable sub cases are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92373

--- Comment #2 from Elio  ---
Adding test cases for reference (query creation for fast tracking)
<%
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@r11f_g11f_b10f
 
Fail
new bug
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@r16f  
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@rg16f 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@rgb10_a2  
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@rgba16f   
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@renderbuffer@color0@srgb8_alpha8
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@r11f_g11f_b10f 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@r16f
Fail
EditRemove deqp-gles2@functional@fbo@completeness@renderable@texture@color0@r8  
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@red_unsigned_byte
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rg16f
Fail
EditRemove deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rg8 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgb10_a2   
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgb565
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgb5_a1
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgb8
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgba16f
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgba4
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rgba8
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@rg_unsigned_byte
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@color0@srgb8_alpha8   
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@depth@depth24_stencil8
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@depth@depth_component16
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@depth@depth_component24
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@depth@red_unsigned_byte
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@depth@rg_unsigned_byte
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@stencil@depth24_stencil8
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@stencil@red_unsigned_byte
 
Fail
EditRemove
deqp-gles2@functional@fbo@completeness@renderable@texture@stencil@rg_unsigned_byte
 
Fail
%>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92373] [HSW] deqpl-gles2 Functional@fbo@completeness@renderable sub cases are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92373

--- Comment #1 from Elio  ---
Created attachment 118788
  --> https://bugs.freedesktop.org/attachment.cgi?id=118788&action=edit
Terminal Output

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92373] [HSW] deqpl-gles2 Functional@fbo@completeness@renderable sub cases are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92373

Bug ID: 92373
   Summary: [HSW] deqpl-gles2
Functional@fbo@completeness@renderable sub cases are
failing
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: elio.martinez.mon...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118787
  --> https://bugs.freedesktop.org/attachment.cgi?id=118787&action=edit
Dmesg logs

About 29 test cases from family Functional@fbo@completeness@renderable are
failing:

Test Enviroment:

kernel: 4.3.0
Mesa: (11.2)git-
Xf86_video_intel:2.99.917
Libdrm:libdrm-2.4.65
Libva: 1.6.1
vaapi-in tel-driver: 1.6.1
Cairo: 1.14.2
Xserver: xorg-server-latests

Hardware:

Hardware
Platform: Intel NUC D54250WYK
Processor Intel Core I5-425OU 1.30 GHz
Software
Linux distribution: Ubuntu 14.04 LTS 64Bits
BIOS: WTLPT10H.86A.0021.2013.1.017.1606

Steps to reproduce:
Install Graphic stack with configuration mentioned before.
Install deqp tool.
Execute: sudo ./deqp-gles2
--deqp-case=dEQP-GLES2.functional.fbo.completeness.rendarable.*

Expected Result: Test should pass without crash/error
Actual results: From 264 test cases, failing test cases 29

Please check attached logs

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92372] [HSW] deqp-gles2 functional.clipping.line/point are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92372

Bug ID: 92372
   Summary: [HSW] deqp-gles2 functional.clipping.line/point are
failing
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: elio.martinez.mon...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118784
  --> https://bugs.freedesktop.org/attachment.cgi?id=118784&action=edit
Dmesg logs

<%
The following tests are failing from the family: functional@clipping:
deqp-gles2@functional@clipping@line@wide_line_clip_viewport_center
Fail
deqp-gles2@functional@clipping@line@wide_line_clip_viewport_corner
Fail
deqp-gles2@functional@clipping@point@wide_point_clip
Fail
deqp-gles2@functional@clipping@point@wide_point_clip_viewport_center
Fail
deqp-gles2@functional@clipping@point@wide_point_clip_viewport_corner
Fail
%>


Test Enviroment:

kernel: 4.3.0
Mesa: (11.2)git-
Xf86_video_intel:2.99.917
Libdrm:libdrm-2.4.65
Libva: 1.6.1
vaapi-in tel-driver: 1.6.1
Cairo: 1.14.2
Xserver: xorg-server-latests

Hardware:

Hardware
Platform: Intel NUC D54250WYK
Processor Intel Core I5-425OU 1.30 GHz
Software
Linux distribution: Ubuntu 14.04 LTS 64Bits
BIOS: WTLPT10H.86A.0021.2013.1.017.1606

Steps to reproduce:
Install Graphic stack with configuration mentioned before.
Install deqp tool.
Execute: sudo ./deqp-gles2 --deqp-case=dEQP-GLES2.functional.clipping.*

Expected Result: Test should pass without crash/error
Actual results: The mentioned tests shows errors

Please check attached logs

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92372] [HSW] deqp-gles2 functional.clipping.line/point are failing

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92372

--- Comment #1 from Elio  ---
Created attachment 118785
  --> https://bugs.freedesktop.org/attachment.cgi?id=118785&action=edit
Terminal Output

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Remove GL_ARB_sampler_object depth compare error checking.

2015-10-09 Thread Stefan Dösinger

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 2015-10-06 um 21:01 schrieb Brian Paul:
> Thanks for reposting.  Look OK to me.  I'll commit it later.
I see it is in. Thanks for taking care of this!

Cheers,
Stefan


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWGAY+AAoJEN0/YqbEcdMwEmkP/0VgZsmvcug9g/ELhSCFZMJr
QFiEMT4J2mOFmfYfuprTGdA6to7FuUKsR2EC+8KKGH4S6tLuxQk3UV1um9dKCQRW
R6m50lLJRTCB4+BoAqfjiwBD2rgczNycuP8bp5q/947zfSsZGN3UyX8AbvdOLXZc
EBNksGi9sNgVl0PsK/klYpyhAqItFbMez6Vi1fLSYHa1fNuRdhlITvR8B+0HT88j
l/XLsqVL3TyrHwdvug6KsUIS69ykgnkJXcvjP7JfjsQ/We3jtwEHRGF+58xRN5yJ
YLMwMnYJSQ5CcXlfhFDvfF47PL0uzfa+51H2HnWyevNt25hphAjqNaTIs0T7daPN
+WE44G8cByiWNgzUusfNNENaBP8uNTEwlQdNNfJUg21RFtQJsWtwBLXcNmeuTFeC
mYfbVcaqgutiZyZnGYuIZpCw+B07/mUZvc3WxYjf+PPhJGmWRNAnRE7J6gM236xS
vVJZLz4PLFrJoPxH9Ef8+nVv/QEvw2/BYdQ1ssMprsFA0CGbePjpfUHAM4dlzeu0
3fFtS+2g1Qt/tMLCQHyihifhkVCfDcXQHnmB77aT1B+h+5yM4daQVENLhxsXjIZw
fi6z7rRb9lZnazpzZEJ21TvGjgGC44evZVJaqxyn0CEyKSC8dA/UmFDQ4utiTAAR
zpHHB2VSP/K1jpeg/lFJ
=WBfb
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] New stable-branch 11.0 candidate pushed

2015-10-09 Thread Ilia Mirkin

On Thu, Oct 8, 2015 at 5:50 AM, Emil Velikov  wrote:
> Ilia Mirkin (6):
>   nouveau: make sure there's always room to emit a fence

Please remove this one from your list of cherry-picked patches. While
it fixes real issues on nv30 (and probably the other generations too),
it appears to introduce some new ones on nvc0. I've figured out what's
causing it, but haven't figured out a proper fix. Not sure I'll be
able to before you do a release.

Thanks,

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

[Mesa-dev] [Bug 92371] [HSW]deqp-gles2 Functional@shaders@constant_expressions@ sutests are failing 432 of 462 available tests

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92371

--- Comment #2 from Elio  ---
Adding test cases :

<%
deqp-gles2@functional@shaders@builtin_variable@max_draw_buffers_fragment
Fail
deqp-gles2@functional@shaders@builtin_variable@max_draw_buffers_vertex
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_float_fragment
 
Fail
new bug
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec2_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec2_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec3_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec3_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec4_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@abs_vec4_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec2_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec2_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec3_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec3_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec4_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@ceil_vec4_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec2_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec2_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec2_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec2_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec3_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec3_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec3_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec3_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec4_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec4_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec4_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@clamp_vec4_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec2_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec2_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec3_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec3_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec4_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@floor_vec4_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_float_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_float_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec2_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec2_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec3_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec3_vertex
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec4_fragment
 
Fail
deqp-gles2@functional@shaders@constant_expressions@builtin_functions@common@fract_vec4_vertex
 
Fail
d

[Mesa-dev] [Bug 92371] [HSW]deqp-gles2 Functional@shaders@constant_expressions@ sutests are failing 432 of 462 available tests

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92371

--- Comment #1 from Elio  ---
Created attachment 118782
  --> https://bugs.freedesktop.org/attachment.cgi?id=118782&action=edit
Terminal Output

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92371] [HSW]deqp-gles2 Functional@shaders@constant_expressions@ sutests are failing 432 of 462 available tests

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92371

Bug ID: 92371
   Summary: [HSW]deqp-gles2
Functional@shaders@constant_expressions@ sutests are
failing 432 of 462 available tests
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: elio.martinez.mon...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 118781
  --> https://bugs.freedesktop.org/attachment.cgi?id=118781&action=edit
Dmesg logs

Most to of the tests in DEQP-2 in functional.shaders.constant_expressions are
failing:
432 of 462

Test Enviroment:

kernel: 4.3.0
Mesa: (11.2)git-
Xf86_video_intel:2.99.917
Libdrm:libdrm-2.4.65
Libva: 1.6.1
vaapi-in tel-driver: 1.6.1
Cairo: 1.14.2
Xserver: xorg-server-latests

Hardware:

Hardware
Platform: Intel NUC D54250WYK
Processor Intel Core I5-425OU 1.30 GHz
Software
Linux distribution: Ubuntu 14.04 LTS 64Bits
BIOS: WTLPT10H.86A.0021.2013.1.017.1606

Steps to reproduce:
Install Graphic stack with configuration mentioned before.
Install deqp tool.
Execute: sudo ./deqp-gles2
--deqp-case=dEQP-GLES2.functional.shaders.constant_expressions.*

Expected Result: Test should pass without crash/error
Actual results: From 462 test cases only 28 does.

Please check attached logs

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] program: remove _mesa_init_*_program wrappers

2015-10-09 Thread Matt Turner

On Fri, Oct 9, 2015 at 10:38 AM, Marek Olšák  wrote:
> On Fri, Oct 9, 2015 at 7:33 PM, Emil Velikov  wrote:
>> On 9 October 2015 at 17:55, Marek Olšák  wrote:
>>> On Thu, Oct 8, 2015 at 3:49 PM, Emil Velikov  
>>> wrote:
 On 8 October 2015 at 01:12, Marek Olšák  wrote:
> From: Marek Olšák 
>
> They didn't do anything useful.
> ---
>  src/mesa/drivers/dri/i915/i915_fragprog.c  |   7 +-
>  src/mesa/drivers/dri/i965/brw_program.c|  10 +-
>  .../drivers/dri/i965/test_fs_cmod_propagation.cpp  |   2 +-
>  .../dri/i965/test_fs_saturate_propagation.cpp  |   2 +-
>  .../dri/i965/test_vec4_copy_propagation.cpp|   2 +-
>  .../dri/i965/test_vec4_register_coalesce.cpp   |   2 +-
>  src/mesa/drivers/dri/r200/r200_vertprog.c  |   4 +-
>  src/mesa/program/program.c | 133 
> +++--
>  src/mesa/program/program.h |  29 +
>  src/mesa/state_tracker/st_cb_program.c |  43 +++
>  10 files changed, 50 insertions(+), 184 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
> b/src/mesa/drivers/dri/i915/i915_fragprog.c
> index 1a5943c..237d219 100644
> --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
> +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
> @@ -1316,8 +1316,8 @@ i915NewProgram(struct gl_context * ctx, GLenum 
> target, GLuint id)
>  {
> switch (target) {
> case GL_VERTEX_PROGRAM_ARB:
> -  return _mesa_init_vertex_program(ctx, 
> CALLOC_STRUCT(gl_vertex_program),
> -   target, id);
> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
> +   target, id);
>
 Worth doing the memory allocation to a temporary variable, and feeding
 &prog->base to _mesa_init_gl_program ?
>>>
>>> I tried that first, but it required more lines of code.
>>>
>> The ones that you'll gain, will be balanced out by the other suggestions :-)
>>

> --- a/src/mesa/drivers/dri/r200/r200_vertprog.c
> +++ b/src/mesa/drivers/dri/r200/r200_vertprog.c
> @@ -1205,9 +1205,9 @@ r200NewProgram(struct gl_context *ctx, GLenum 
> target, GLuint id)
> switch(target){
> case GL_VERTEX_PROGRAM_ARB:
>vp = CALLOC_STRUCT(r200_vertex_program);
> -  return _mesa_init_vertex_program(ctx, &vp->mesa_program, target, 
> id);
> +  return _mesa_init_gl_program(&vp->mesa_program, target, id);
> case GL_FRAGMENT_PROGRAM_ARB:
> -  return _mesa_init_fragment_program( ctx, 
> CALLOC_STRUCT(gl_fragment_program), target, id );
> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_fragment_program), 
> target, id);
 Ditto.


> --- a/src/mesa/program/program.c
> +++ b/src/mesa/program/program.c

> @@ -309,34 +217,29 @@ _mesa_new_program(struct gl_context *ctx, GLenum 
> target, GLuint id)
> struct gl_program *prog;
> switch (target) {
> case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
> -  prog = _mesa_init_vertex_program(ctx, 
> CALLOC_STRUCT(gl_vertex_program),
> -   target, id );
> +  prog = _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
> +   target, id);
 Ditto. + early return similar to st/mesa ?

> --- a/src/mesa/program/program.h
> +++ b/src/mesa/program/program.h

> -extern struct gl_program *
> -_mesa_init_compute_program(struct gl_context *ctx,
> -   struct gl_compute_program *prog,
> -   GLenum target, GLuint id);
> +_mesa_init_gl_program(void *prog, GLenum target, GLuint id);
>
 If you go for my suggestion you can keep prog as struct gl_program *.

> --- a/src/mesa/state_tracker/st_cb_program.c
> +++ b/src/mesa/state_tracker/st_cb_program.c

> +   switch (target) {
> +   case GL_VERTEX_PROGRAM_ARB:
> +  prog = (struct gl_program*)ST_CALLOC_STRUCT(st_vertex_program);
> +  break;
> +   case GL_FRAGMENT_PROGRAM_ARB:
 Worth adding case GL_FRAGMENT_PROGRAM_NV, or perhaps nuking it from
 mesa/program/program.c above ?
>>>
>>> I think GL_FRAGMENT_PROGRAM_NV is from an NV extension supported by
>>> some classic drivers but not st/mesa.
>>>
>> Seems to be part of GL_NV_fragment_program, which was removed a while ago 
>> with
>
> I think it's GL_NV_fragment_program_option, so you can't just remove
> it unless you want to remove the whole extension.

FWIW, there was a discussion in February ("[PATCH] mesa: don't enable
NV_fragment_program_option with swrast") about removing it. It seems
that it's only needed to support viewperf on swrast.

Maybe we should continue the discussion in that thread.
___

Re: [Mesa-dev] [PATCH 4/4] program: remove _mesa_init_*_program wrappers

2015-10-09 Thread Marek Olšák

On Fri, Oct 9, 2015 at 7:33 PM, Emil Velikov  wrote:
> On 9 October 2015 at 17:55, Marek Olšák  wrote:
>> On Thu, Oct 8, 2015 at 3:49 PM, Emil Velikov  
>> wrote:
>>> On 8 October 2015 at 01:12, Marek Olšák  wrote:
 From: Marek Olšák 

 They didn't do anything useful.
 ---
  src/mesa/drivers/dri/i915/i915_fragprog.c  |   7 +-
  src/mesa/drivers/dri/i965/brw_program.c|  10 +-
  .../drivers/dri/i965/test_fs_cmod_propagation.cpp  |   2 +-
  .../dri/i965/test_fs_saturate_propagation.cpp  |   2 +-
  .../dri/i965/test_vec4_copy_propagation.cpp|   2 +-
  .../dri/i965/test_vec4_register_coalesce.cpp   |   2 +-
  src/mesa/drivers/dri/r200/r200_vertprog.c  |   4 +-
  src/mesa/program/program.c | 133 
 +++--
  src/mesa/program/program.h |  29 +
  src/mesa/state_tracker/st_cb_program.c |  43 +++
  10 files changed, 50 insertions(+), 184 deletions(-)

 diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
 b/src/mesa/drivers/dri/i915/i915_fragprog.c
 index 1a5943c..237d219 100644
 --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
 +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
 @@ -1316,8 +1316,8 @@ i915NewProgram(struct gl_context * ctx, GLenum 
 target, GLuint id)
  {
 switch (target) {
 case GL_VERTEX_PROGRAM_ARB:
 -  return _mesa_init_vertex_program(ctx, 
 CALLOC_STRUCT(gl_vertex_program),
 -   target, id);
 +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
 +   target, id);

>>> Worth doing the memory allocation to a temporary variable, and feeding
>>> &prog->base to _mesa_init_gl_program ?
>>
>> I tried that first, but it required more lines of code.
>>
> The ones that you'll gain, will be balanced out by the other suggestions :-)
>
>>>
 --- a/src/mesa/drivers/dri/r200/r200_vertprog.c
 +++ b/src/mesa/drivers/dri/r200/r200_vertprog.c
 @@ -1205,9 +1205,9 @@ r200NewProgram(struct gl_context *ctx, GLenum 
 target, GLuint id)
 switch(target){
 case GL_VERTEX_PROGRAM_ARB:
vp = CALLOC_STRUCT(r200_vertex_program);
 -  return _mesa_init_vertex_program(ctx, &vp->mesa_program, target, 
 id);
 +  return _mesa_init_gl_program(&vp->mesa_program, target, id);
 case GL_FRAGMENT_PROGRAM_ARB:
 -  return _mesa_init_fragment_program( ctx, 
 CALLOC_STRUCT(gl_fragment_program), target, id );
 +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_fragment_program), 
 target, id);
>>> Ditto.
>>>
>>>
 --- a/src/mesa/program/program.c
 +++ b/src/mesa/program/program.c
>>>
 @@ -309,34 +217,29 @@ _mesa_new_program(struct gl_context *ctx, GLenum 
 target, GLuint id)
 struct gl_program *prog;
 switch (target) {
 case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
 -  prog = _mesa_init_vertex_program(ctx, 
 CALLOC_STRUCT(gl_vertex_program),
 -   target, id );
 +  prog = _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
 +   target, id);
>>> Ditto. + early return similar to st/mesa ?
>>>
 --- a/src/mesa/program/program.h
 +++ b/src/mesa/program/program.h
>>>
 -extern struct gl_program *
 -_mesa_init_compute_program(struct gl_context *ctx,
 -   struct gl_compute_program *prog,
 -   GLenum target, GLuint id);
 +_mesa_init_gl_program(void *prog, GLenum target, GLuint id);

>>> If you go for my suggestion you can keep prog as struct gl_program *.
>>>
 --- a/src/mesa/state_tracker/st_cb_program.c
 +++ b/src/mesa/state_tracker/st_cb_program.c
>>>
 +   switch (target) {
 +   case GL_VERTEX_PROGRAM_ARB:
 +  prog = (struct gl_program*)ST_CALLOC_STRUCT(st_vertex_program);
 +  break;
 +   case GL_FRAGMENT_PROGRAM_ARB:
>>> Worth adding case GL_FRAGMENT_PROGRAM_NV, or perhaps nuking it from
>>> mesa/program/program.c above ?
>>
>> I think GL_FRAGMENT_PROGRAM_NV is from an NV extension supported by
>> some classic drivers but not st/mesa.
>>
> Seems to be part of GL_NV_fragment_program, which was removed a while ago with

I think it's GL_NV_fragment_program_option, so you can't just remove
it unless you want to remove the whole extension.

>
> commit 2f350f360b00e786e140d9ccb9db83bf23269d8f
> Author: Kenneth Graunke 
> Date:   Sun Oct 14 15:53:06 2012 -0700
>
>mesa: Remove get and enable bits for NV_fragment_program.
>
> and a few other follow-up commits.
>
> Seems like we still have a few remnants which I will clean-up after
> this series lands.
>
>>> Can we keep the variables as is and avoid the casts ?
>>
>> ST_CALLOC_STRUCT needs a cast.
>> Or &ST_

Re: [Mesa-dev] [PATCH 2/2] glsl: include variable name in error messages about initializers

2015-10-09 Thread Matt Turner

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] glsl: shader outputs cannot have initializers

2015-10-09 Thread Matt Turner

On Wed, Oct 7, 2015 at 1:12 AM, Iago Toral Quiroga  wrote:
> GLSL Spec 4.20.8, 4.3 Storage Qualifiers:
>
> "Initializers in global declarations may only be used in declarations of
>  global variables with no storage qualifier, with a const qualifier or
>  with a uniform qualifier."
>
> We do this for input variables, but not for output variables. AMD and NVIDIA
> proprietary drivers don't allow this either.
> ---
>  src/glsl/ast_to_hir.cpp | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 9511440..da79597 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -3201,6 +3201,12 @@ process_initializer(ir_variable *var, ast_declaration 
> *decl,
>? "attribute" : "varying");
> }
>
> +   if ((var->data.mode == ir_var_shader_out) && (state->current_function == 
> NULL)) {

No need for the parentheses.

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] program: remove _mesa_init_*_program wrappers

2015-10-09 Thread Emil Velikov

On 9 October 2015 at 17:55, Marek Olšák  wrote:
> On Thu, Oct 8, 2015 at 3:49 PM, Emil Velikov  wrote:
>> On 8 October 2015 at 01:12, Marek Olšák  wrote:
>>> From: Marek Olšák 
>>>
>>> They didn't do anything useful.
>>> ---
>>>  src/mesa/drivers/dri/i915/i915_fragprog.c  |   7 +-
>>>  src/mesa/drivers/dri/i965/brw_program.c|  10 +-
>>>  .../drivers/dri/i965/test_fs_cmod_propagation.cpp  |   2 +-
>>>  .../dri/i965/test_fs_saturate_propagation.cpp  |   2 +-
>>>  .../dri/i965/test_vec4_copy_propagation.cpp|   2 +-
>>>  .../dri/i965/test_vec4_register_coalesce.cpp   |   2 +-
>>>  src/mesa/drivers/dri/r200/r200_vertprog.c  |   4 +-
>>>  src/mesa/program/program.c | 133 
>>> +++--
>>>  src/mesa/program/program.h |  29 +
>>>  src/mesa/state_tracker/st_cb_program.c |  43 +++
>>>  10 files changed, 50 insertions(+), 184 deletions(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
>>> b/src/mesa/drivers/dri/i915/i915_fragprog.c
>>> index 1a5943c..237d219 100644
>>> --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
>>> +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
>>> @@ -1316,8 +1316,8 @@ i915NewProgram(struct gl_context * ctx, GLenum 
>>> target, GLuint id)
>>>  {
>>> switch (target) {
>>> case GL_VERTEX_PROGRAM_ARB:
>>> -  return _mesa_init_vertex_program(ctx, 
>>> CALLOC_STRUCT(gl_vertex_program),
>>> -   target, id);
>>> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
>>> +   target, id);
>>>
>> Worth doing the memory allocation to a temporary variable, and feeding
>> &prog->base to _mesa_init_gl_program ?
>
> I tried that first, but it required more lines of code.
>
The ones that you'll gain, will be balanced out by the other suggestions :-)

>>
>>> --- a/src/mesa/drivers/dri/r200/r200_vertprog.c
>>> +++ b/src/mesa/drivers/dri/r200/r200_vertprog.c
>>> @@ -1205,9 +1205,9 @@ r200NewProgram(struct gl_context *ctx, GLenum target, 
>>> GLuint id)
>>> switch(target){
>>> case GL_VERTEX_PROGRAM_ARB:
>>>vp = CALLOC_STRUCT(r200_vertex_program);
>>> -  return _mesa_init_vertex_program(ctx, &vp->mesa_program, target, id);
>>> +  return _mesa_init_gl_program(&vp->mesa_program, target, id);
>>> case GL_FRAGMENT_PROGRAM_ARB:
>>> -  return _mesa_init_fragment_program( ctx, 
>>> CALLOC_STRUCT(gl_fragment_program), target, id );
>>> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_fragment_program), 
>>> target, id);
>> Ditto.
>>
>>
>>> --- a/src/mesa/program/program.c
>>> +++ b/src/mesa/program/program.c
>>
>>> @@ -309,34 +217,29 @@ _mesa_new_program(struct gl_context *ctx, GLenum 
>>> target, GLuint id)
>>> struct gl_program *prog;
>>> switch (target) {
>>> case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
>>> -  prog = _mesa_init_vertex_program(ctx, 
>>> CALLOC_STRUCT(gl_vertex_program),
>>> -   target, id );
>>> +  prog = _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
>>> +   target, id);
>> Ditto. + early return similar to st/mesa ?
>>
>>> --- a/src/mesa/program/program.h
>>> +++ b/src/mesa/program/program.h
>>
>>> -extern struct gl_program *
>>> -_mesa_init_compute_program(struct gl_context *ctx,
>>> -   struct gl_compute_program *prog,
>>> -   GLenum target, GLuint id);
>>> +_mesa_init_gl_program(void *prog, GLenum target, GLuint id);
>>>
>> If you go for my suggestion you can keep prog as struct gl_program *.
>>
>>> --- a/src/mesa/state_tracker/st_cb_program.c
>>> +++ b/src/mesa/state_tracker/st_cb_program.c
>>
>>> +   switch (target) {
>>> +   case GL_VERTEX_PROGRAM_ARB:
>>> +  prog = (struct gl_program*)ST_CALLOC_STRUCT(st_vertex_program);
>>> +  break;
>>> +   case GL_FRAGMENT_PROGRAM_ARB:
>> Worth adding case GL_FRAGMENT_PROGRAM_NV, or perhaps nuking it from
>> mesa/program/program.c above ?
>
> I think GL_FRAGMENT_PROGRAM_NV is from an NV extension supported by
> some classic drivers but not st/mesa.
>
Seems to be part of GL_NV_fragment_program, which was removed a while ago with

commit 2f350f360b00e786e140d9ccb9db83bf23269d8f
Author: Kenneth Graunke 
Date:   Sun Oct 14 15:53:06 2012 -0700

   mesa: Remove get and enable bits for NV_fragment_program.

and a few other follow-up commits.

Seems like we still have a few remnants which I will clean-up after
this series lands.

>> Can we keep the variables as is and avoid the casts ?
>
> ST_CALLOC_STRUCT needs a cast.
> Or &ST_CALLOC_STRUCT(...)->Base.Base if I fix the macro to allow that.
>
I was thinking about retaining the original style/approach and not use
CALLOC_STRUCT(foo) as a function argument. Declaring a function
(_mesa_init_gl_program) argument as void * only to down and up cast
it, depending on the scenario, seems a bit

Re: [Mesa-dev] [PATCH shader-db 1/2] report.py: rework and update for cycle info

2015-10-09 Thread Matt Turner

On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott  wrote:
> Now that we have three separate things we want to measure (instructions,
> cycles, and loops), it's impractical to keep adding special code for
> changes in each thing. Instead, for each program in before and after we
> store a table of measurement -> value, and when reporting we loop over
> each measurement and report helped/hurt before reporting the gained/lost
> programs.
>
> Signed-off-by: Connor Abbott 
> ---
>  report.py | 140 
> ++
>  1 file changed, 67 insertions(+), 73 deletions(-)
>
> diff --git a/report.py b/report.py
> index 4c06714..bc3a640 100755
> --- a/report.py
> +++ b/report.py
> @@ -10,17 +10,22 @@ def get_results(filename):
>
>  results = {}
>
> -re_match = re.compile(r"(\S+) - (.S \S+) shader: (\S*) inst, (\S*) 
> loops")
> +re_match = re.compile(r"(\S+) - (.S \S+) shader: (\S*) inst, (\S*) 
> cycles, (\S*) loops")

I'd like to keep results files generated before your series working,
so to do that we'll have to move cycles after loops.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] nir/prog: Use nir_foreach_variable

2015-10-09 Thread Matt Turner

Reviewed-by: Matt Turner 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] i965: Turn UBOs as push constants

2015-10-09 Thread Ben Widawsky

On Fri, Oct 09, 2015 at 06:06:30PM +0300, Abdiel Janulgue wrote:
> Ping! No thoughts/consensus if this approach is worth considering or
> not? The patches are getting stale. Should I re-base or just discard
> these optimisations?
> 

I am not the right person to ask, but I think it's certainly worth considering.
Like I said previously I do suspect there are benchmarks that would have a very
large benefit and that the shader-db results are underselling this.

Having an option to turn things off easily so we can one day perhaps use
heuristics to determine when to use this and when not seem like an important to
have if it isn't already there (maybe not an ENV var, but an easy knob in the
code).

> On 09/15/2015 08:59 PM, Ben Widawsky wrote:
> > On Tue, Sep 15, 2015 at 12:24:00PM +0300, Abdiel Janulgue wrote:
> >> Here's a more comprehensive shader-db run:
> >>
> >> total instructions in shared programs: 6394485 -> 6374865 (-0.31%)
> >> instructions in affected programs: 261322 -> 241702 (-7.51%)
> >> helped:3210
> >> HURT:  0
> >> GAINED:5
> >> LOST:  2
> >>
> >>
> >> - Abdiel
> > 
> > Thanks. The interesting thing to me isn't so much that you reduced 
> > instruction
> > count but hopefully that you reduced a whole bunch of pull loads. I suspect
> > there should be benchmarks out there which have a greater benefit than this
> > (which was why I asked), but I don't know what off the top of my head.
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 

-- 
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] program: remove _mesa_init_*_program wrappers

2015-10-09 Thread Marek Olšák

On Thu, Oct 8, 2015 at 3:49 PM, Emil Velikov  wrote:
> On 8 October 2015 at 01:12, Marek Olšák  wrote:
>> From: Marek Olšák 
>>
>> They didn't do anything useful.
>> ---
>>  src/mesa/drivers/dri/i915/i915_fragprog.c  |   7 +-
>>  src/mesa/drivers/dri/i965/brw_program.c|  10 +-
>>  .../drivers/dri/i965/test_fs_cmod_propagation.cpp  |   2 +-
>>  .../dri/i965/test_fs_saturate_propagation.cpp  |   2 +-
>>  .../dri/i965/test_vec4_copy_propagation.cpp|   2 +-
>>  .../dri/i965/test_vec4_register_coalesce.cpp   |   2 +-
>>  src/mesa/drivers/dri/r200/r200_vertprog.c  |   4 +-
>>  src/mesa/program/program.c | 133 
>> +++--
>>  src/mesa/program/program.h |  29 +
>>  src/mesa/state_tracker/st_cb_program.c |  43 +++
>>  10 files changed, 50 insertions(+), 184 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c 
>> b/src/mesa/drivers/dri/i915/i915_fragprog.c
>> index 1a5943c..237d219 100644
>> --- a/src/mesa/drivers/dri/i915/i915_fragprog.c
>> +++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
>> @@ -1316,8 +1316,8 @@ i915NewProgram(struct gl_context * ctx, GLenum target, 
>> GLuint id)
>>  {
>> switch (target) {
>> case GL_VERTEX_PROGRAM_ARB:
>> -  return _mesa_init_vertex_program(ctx, 
>> CALLOC_STRUCT(gl_vertex_program),
>> -   target, id);
>> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
>> +   target, id);
>>
> Worth doing the memory allocation to a temporary variable, and feeding
> &prog->base to _mesa_init_gl_program ?

I tried that first, but it required more lines of code.

>
>> --- a/src/mesa/drivers/dri/r200/r200_vertprog.c
>> +++ b/src/mesa/drivers/dri/r200/r200_vertprog.c
>> @@ -1205,9 +1205,9 @@ r200NewProgram(struct gl_context *ctx, GLenum target, 
>> GLuint id)
>> switch(target){
>> case GL_VERTEX_PROGRAM_ARB:
>>vp = CALLOC_STRUCT(r200_vertex_program);
>> -  return _mesa_init_vertex_program(ctx, &vp->mesa_program, target, id);
>> +  return _mesa_init_gl_program(&vp->mesa_program, target, id);
>> case GL_FRAGMENT_PROGRAM_ARB:
>> -  return _mesa_init_fragment_program( ctx, 
>> CALLOC_STRUCT(gl_fragment_program), target, id );
>> +  return _mesa_init_gl_program(CALLOC_STRUCT(gl_fragment_program), 
>> target, id);
> Ditto.
>
>
>> --- a/src/mesa/program/program.c
>> +++ b/src/mesa/program/program.c
>
>> @@ -309,34 +217,29 @@ _mesa_new_program(struct gl_context *ctx, GLenum 
>> target, GLuint id)
>> struct gl_program *prog;
>> switch (target) {
>> case GL_VERTEX_PROGRAM_ARB: /* == GL_VERTEX_PROGRAM_NV */
>> -  prog = _mesa_init_vertex_program(ctx, 
>> CALLOC_STRUCT(gl_vertex_program),
>> -   target, id );
>> +  prog = _mesa_init_gl_program(CALLOC_STRUCT(gl_vertex_program),
>> +   target, id);
> Ditto. + early return similar to st/mesa ?
>
>> --- a/src/mesa/program/program.h
>> +++ b/src/mesa/program/program.h
>
>> -extern struct gl_program *
>> -_mesa_init_compute_program(struct gl_context *ctx,
>> -   struct gl_compute_program *prog,
>> -   GLenum target, GLuint id);
>> +_mesa_init_gl_program(void *prog, GLenum target, GLuint id);
>>
> If you go for my suggestion you can keep prog as struct gl_program *.
>
>> --- a/src/mesa/state_tracker/st_cb_program.c
>> +++ b/src/mesa/state_tracker/st_cb_program.c
>
>> +   switch (target) {
>> +   case GL_VERTEX_PROGRAM_ARB:
>> +  prog = (struct gl_program*)ST_CALLOC_STRUCT(st_vertex_program);
>> +  break;
>> +   case GL_FRAGMENT_PROGRAM_ARB:
> Worth adding case GL_FRAGMENT_PROGRAM_NV, or perhaps nuking it from
> mesa/program/program.c above ?

I think GL_FRAGMENT_PROGRAM_NV is from an NV extension supported by
some classic drivers but not st/mesa.

> Can we keep the variables as is and avoid the casts ?

ST_CALLOC_STRUCT needs a cast.
Or &ST_CALLOC_STRUCT(...)->Base.Base if I fix the macro to allow that.

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

[Mesa-dev] [Bug 92368] [BSW] Regression: glx@glx_arb_sync_control@timing -fullscreen test Fail

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92368

Rami  changed:

   What|Removed |Added

Summary|[BSW] Regression:   |[BSW] Regression:
   |glx@glx_arb_sync_control@ti |glx@glx_arb_sync_control@ti
   |ming -fullscreen -diviso|ming -fullscreen  test Fail
   |test Fail   |

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92368] [BSW] Regression: glx@glx_arb_sync_control@timing -fullscreen -diviso test Fail

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92368

Bug ID: 92368
   Summary: [BSW] Regression: glx@glx_arb_sync_control@timing
-fullscreen -diviso test Fail
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ramix.ben.hass...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Test fail after executing all piglit tests. this test passed with last setup:

Actual setup:
=
Hardware:
Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW C0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03 

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel drm-intel-nightly 4.3.0-rc3 eb69e51
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa 11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26  
 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, origin/master, origin/HEAD, master)
1b492e311ce13fe4bc42f1edd5479441662d4855 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

Last setup:
===
Hardware:

Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32,F33 & F37
Optional reworks : O-01a

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel 4.3.0-rc2-drm-intel-nightly+
commit 794e1cdfb84be003dbd287c69501c98ec280a89b
Author: Jani Nikula 
Date:   Mon Sep 28 17:28:29 2015 +0300

drm-intel-nightly: 2015y-09m-28d-14h-28m-11s UTC integration manifest

cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa-10.6.7) 32efdc87cbf89cfe08ad9571cd756e27c803caa8 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver

intel-gpu-tools: (HEAD, tag: intel-gpu-tools-1.12)
1f9e0550455be4b219954a026407dd23ec21b299 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/gen8: Remove gen<8 checks in gen8 code

2015-10-09 Thread Anuj Phogat

On Thu, Oct 8, 2015 at 12:21 PM, Chad Versace  wrote:
> Some assertions in gen8_surface_state.c checked for gen < 8.
> ---
>  src/mesa/drivers/dri/i965/gen8_surface_state.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen8_surface_state.c 
> b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> index e1e7704..18b8665 100644
> --- a/src/mesa/drivers/dri/i965/gen8_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_surface_state.c
> @@ -221,8 +221,8 @@ gen8_emit_texture_surface_state(struct brw_context *brw,
> * "When Auxiliary Surface Mode is set to AUX_CCS_D or AUX_CCS_E, 
> HALIGN
> *  16 must be used."
> */
> -  assert(brw->gen < 9 || mt->halign == 16);
> -  assert(brw->gen < 8 || mt->num_samples > 1 || mt->halign == 16);
> +  if (brw->gen >= 9 || mt->num_samples == 1)
> + assert(mt->halign == 16);
> }
>
> const uint32_t surf_type = translate_tex_target(target);
> @@ -470,8 +470,8 @@ gen8_update_renderbuffer_surface(struct brw_context *brw,
> * "When Auxiliary Surface Mode is set to AUX_CCS_D or AUX_CCS_E, 
> HALIGN
> *  16 must be used."
> */
> -  assert(brw->gen < 9 || mt->halign == 16);
> -  assert(brw->gen < 8 || mt->num_samples > 1 || mt->halign == 16);
> +  if (brw->gen >= 9 || mt->num_samples == 1)
> + assert(mt->halign == 16);
> }
>
> uint32_t *surf = allocate_surface_state(brw, &offset, surf_index);
> --
> 2.5.0.342.g44e0223
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92366] [BSW] Regression: glx@glx-swap-event_async failed

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92366

Rami  changed:

   What|Removed |Added

Summary|BSW] Regression:|[BSW] Regression:
   |glx@glx-swap-event_async|glx@glx-swap-event_async
   |failed  |failed

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 92366] BSW] Regression: glx@glx-swap-event_async failed

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92366

Bug ID: 92366
   Summary: BSW] Regression: glx@glx-swap-event_async failed
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ramix.ben.hass...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Test fail after executing all piglit tests. this test passed with last setup:

Actual setup:
=
Hardware:
Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW C0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03 

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel drm-intel-nightly 4.3.0-rc3 eb69e51
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa 11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26  
 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, origin/master, origin/HEAD, master)
1b492e311ce13fe4bc42f1edd5479441662d4855 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

Last setup:
===
Hardware:

Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32,F33 & F37
Optional reworks : O-01a

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel 4.3.0-rc2-drm-intel-nightly+
commit 794e1cdfb84be003dbd287c69501c98ec280a89b
Author: Jani Nikula 
Date:   Mon Sep 28 17:28:29 2015 +0300

drm-intel-nightly: 2015y-09m-28d-14h-28m-11s UTC integration manifest

cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa-10.6.7) 32efdc87cbf89cfe08ad9571cd756e27c803caa8 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver

intel-gpu-tools: (HEAD, tag: intel-gpu-tools-1.12)
1f9e0550455be4b219954a026407dd23ec21b299 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: use gl_shader_variable in program resource list WIP

2015-10-09 Thread Marek Olšák

Hi,

I like the idea. I started working on this too, but stopped because of
other things:
http://cgit.freedesktop.org/~mareko/mesa/commit/?id=d5266d5c22ba798c105b95c8f227faf8f04718af

Marek

On Fri, Oct 9, 2015 at 7:57 AM, Tapani Pälli  wrote:
> Patch changes linker to allocate gl_shader_variable instead of using
> ir_variable. This makes it possible to get rid of ir_variables and ir
> as a whole.
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/glsl/linker.cpp| 42 ++-
>  src/mesa/main/mtypes.h | 56 
> ++
>  src/mesa/main/shader_query.cpp | 36 +--
>  3 files changed, 110 insertions(+), 24 deletions(-)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index a97b4ef..76f74dc 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -3305,6 +3305,27 @@ build_stageref(struct gl_shader_program *shProg, const 
> char *name,
> return stages;
>  }
>
> +/**
> + * Create gl_shader_variable from ir_variable class.
> + */
> +static gl_shader_variable *
> +create_shader_variable(struct gl_shader_program *shProg, const ir_variable 
> *in)
> +{
> +   gl_shader_variable *out = ralloc(shProg, struct gl_shader_variable);
> +   if (!out)
> +  return NULL;
> +
> +   out->type = in->type;
> +   out->name = ralloc_strdup(shProg, in->name);
> +
> +   out->location = in->data.location;
> +   out->index = in->data.index;
> +   out->patch = in->data.patch;
> +   out->mode = in->data.mode;
> +
> +   return out;
> +}
> +
>  static bool
>  add_interface_variables(struct gl_shader_program *shProg,
>  exec_list *ir, GLenum programInterface)
> @@ -3350,9 +3371,13 @@ add_interface_variables(struct gl_shader_program 
> *shProg,
>if (strncmp(var->name, "packed:", 7) == 0)
>   continue;
>
> -  if (!add_program_resource(shProg, programInterface, var,
> -build_stageref(shProg, var->name,
> -   var->data.mode) | mask))
> +  gl_shader_variable *sha_v = create_shader_variable(shProg, var);
> +  if (!sha_v)
> + return false;
> +
> +  if (!add_program_resource(shProg, programInterface, sha_v,
> +build_stageref(shProg, sha_v->name,
> +   sha_v->mode) | mask))
>   return false;
> }
> return true;
> @@ -3380,9 +3405,14 @@ add_packed_varyings(struct gl_shader_program *shProg, 
> int stage)
>   default:
>  unreachable("unexpected type");
>   }
> - if (!add_program_resource(shProg, iface, var,
> -   build_stageref(shProg, var->name,
> -  var->data.mode)))
> +
> + gl_shader_variable *sha_v = create_shader_variable(shProg, var);
> + if (!sha_v)
> +return false;
> +
> + if (!add_program_resource(shProg, iface, sha_v,
> +   build_stageref(shProg, sha_v->name,
> +  sha_v->mode)))
>  return false;
>}
> }
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index 288d757..6a54fe2 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -2518,6 +2518,62 @@ struct gl_active_atomic_buffer
>  };
>
>  /**
> + * Data container for shader queries. This holds only the minimal
> + * amount of required information for resource queries to work.
> + */
> +struct gl_shader_variable
> +{
> +   /**
> +* Declared type of the variable
> +*/
> +   const struct glsl_type *type;
> +
> +   /**
> +* Declared name of the variable
> +*/
> +   char *name;
> +
> +   /**
> +* Storage location of the base of this variable
> +*
> +* The precise meaning of this field depends on the nature of the 
> variable.
> +*
> +*   - Vertex shader input: one of the values from \c gl_vert_attrib.
> +*   - Vertex shader output: one of the values from \c gl_varying_slot.
> +*   - Geometry shader input: one of the values from \c gl_varying_slot.
> +*   - Geometry shader output: one of the values from \c gl_varying_slot.
> +*   - Fragment shader input: one of the values from \c gl_varying_slot.
> +*   - Fragment shader output: one of the values from \c gl_frag_result.
> +*   - Uniforms: Per-stage uniform slot number for default uniform block.
> +*   - Uniforms: Index within the uniform block definition for UBO 
> members.
> +*   - Non-UBO Uniforms: explicit location until linking then reused to
> +* store uniform slot number.
> +*   - Other: This field is not currently used.
> +*
> +* If the variable is a uniform, shader input, or shader output, and the
> +* slot has not been assigned, the value will be -1.
> +*/
> +   int location;
> +
> +   /**
> +* Output index fo

[Mesa-dev] [Bug 92361] [BSW] Regression: glx@glx-copy-sub-buffer failed

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92361

Bug ID: 92361
   Summary: [BSW] Regression: glx@glx-copy-sub-buffer failed
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ramix.ben.hass...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

Test fail after executing all piglit tests. this test passed with last setup:

Actual setup:
=
Hardware:
Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW C0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All Feature Reworks: F28, F32, F33, F35, F37
Optional reworks : O-01a; O-02, O-03 

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel drm-intel-nightly 4.3.0-rc3 eb69e51
cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa 11.0.2) 51e0b06d9916e126060c0d218de1aaa4e5a4ce26  
 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver
intel-gpu-tools: (HEAD, origin/master, origin/HEAD, master)
1b492e311ce13fe4bc42f1edd5479441662d4855 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

Last setup:
===
Hardware:

Platform: Braswell M 
CPU : Intel(R) Celeron N3060 1.60GHz @ 1.6 GHz (family: 6, model: 76 stepping:
4)
SoC : BSW D0
QDF : K6XC
CRB : BRASWELL RVP Fab2
Mandatory Reworks : All 
Feature Reworks: F28, F32,F33 & F37
Optional reworks : O-01a

Software :
Linux distribution: Ubuntu 14.04 LTS 64 bits 
BIOS : BRAS.X64.B084.R00.1508310642
TXE FW : 2.0.0.2073
Ksc : 1.08

kernel 4.3.0-rc2-drm-intel-nightly+
commit 794e1cdfb84be003dbd287c69501c98ec280a89b
Author: Jani Nikula 
Date:   Mon Sep 28 17:28:29 2015 +0300

drm-intel-nightly: 2015y-09m-28d-14h-28m-11s UTC integration manifest

cairo: (HEAD, tag: 1.14.2) 93422b3cb5e0ef8104b8194c8873124ce2f5ea2d from
git://git.freedesktop.org/git/cairo
drm: (HEAD, tag: libdrm-2.4.64, tag: 2.4.64)
ab2fadabde3829b1ec56bd4756165dd9bd281488 from
git://git.freedesktop.org/git/mesa/drm
intel-driver: (HEAD, origin/master, origin/HEAD, master)
2a72f99d24714f2a58f400ef63b913d4cf9080b3 from
git://git.freedesktop.org/git/vaapi/intel-driver
libva: (HEAD, tag: libva-1.6.1, origin/v1.6-branch)
613eb962b45fbbd1526d751e88e0d8897af6c0e0 from
git://git.freedesktop.org/git/vaapi/libva
mesa: (HEAD, tag: mesa-10.6.7) 32efdc87cbf89cfe08ad9571cd756e27c803caa8 from
git://git.freedesktop.org/git/mesa/mesa
xf86-video-intel: (HEAD, origin/master, origin/HEAD, master)
f0fd4d500de03c30c7ce19915f85acadd1ca4e5d from
git://git.freedesktop.org/git/xorg/driver/xf86-video-intel
xserver: (HEAD, tag: xorg-server-1.17.2)
2123f7682d522619f101b05fb75efa75dabbe371 from
git://git.freedesktop.org/git/xorg/xserver

intel-gpu-tools: (HEAD, tag: intel-gpu-tools-1.12)
1f9e0550455be4b219954a026407dd23ec21b299 from
git://git.freedesktop.org/git/xorg/app/intel-gpu-tools

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] Vendor-neutral dispatch library for OpenGL

2015-10-09 Thread Kyle Brenneman


On 10/08/2015 08:44 PM, Michel Dänzer wrote:

On 07.10.2015 04:58, Kyle Brenneman wrote:

On 10/06/2015 12:43 PM, Emil Velikov wrote:

On 6 October 2015 at 16:39, Kyle Brenneman  wrote:

On 10/06/2015 07:34 AM, Emil Velikov wrote:

   * The existing x11glvnd extension seems to be a "xserver only" approach.
Iirc at XDC last year, people were leaning towards using an FD to
obtain all the information needed. Currently mesa/xserver uses that to
detect if we should load i915, i965, r300, r600... driver. What's your
take on this ?

I'm open to alternatives, but I'm not familiar with the FD approach you're
describing. Can you give me more details about it, or point me at where in
the Mesa code it is?


The idea is that you can get the device(node) fd from the server
(x,weston,foo) and use that to communicate with the module and/apply
any form of heuristics. Currently mesa has a few:
  - get the kernel module name (via ioctls or sysfs) and map it to the
userspace driver.
  - get the vendor/device pciid (via libudev or sysfs), and map it to
the userspace driver.

The code is in src/loader, it's a bit hard to look at, so be warned.

I've been planning to nuke the ioctl vs sysfs vs libudev, by pushing
the chaos to libdrm. So that others can reuse it when needed. yet it's
not the most interesting thing to do bth.

The only thing that libGLX can assume is that each X screen corresponds
to at most one vendor library.

Actually, it can't: the amdgpu kernel driver is not only supported by
the Mesa radeonsi driver but will also be supported by future versions
of the Catalyst OpenGL driver. Either OpenGL driver will work with both
the xf86-video-amdgpu driver and the generic modesetting Xorg driver.



The x11glvnd extension will (by default) hand back the name of whatever
video driver is driving a screen. For cases where multiple vendor names
should all use the same vendor library, all the different names would
just be symlinks to the same library. So for example, you might have
have libGLX_mesa.so as the library, and then you'd have symlinks to it
named libGLX_intel.so, libGLX_vesa.so, and so on.

I hope we can handle the above scenario as well, allowing to select one
of the supported OpenGL drivers for each application without having to
resort to manipulating symlinks, e.g. via configuration files and/or
environment variables. I think something like Mesa's driconf
infrastructure would be nice for this from a user perspective, it allows
making persistent per-application configuration.


The symlinks idea is more for the reverse of that scenario. When you've 
got multiple server-side display drivers that all call for the same 
client-side vendor library, then you can add symlinks so that each name 
gets you the same library. There's no variation on configuration in that 
case, so the installer or package manager would just create the symlinks 
and leave it at that.


If there are multiple possible vendor libraries for a single display 
driver, then it would need some way to select one. On the server side, 
you can set an X config option to override the vendor name that the 
x11glvnd extension sends back, and on the client side you can set an 
environment variable that would override the vendor library selection in 
libGLX. Both of those require manual configuration, though.


For simple cases where two vendor libraries might be available, but 
you'd always want to pick one over the other, it might be possible for 
the x11glvnd extension to send back multiple names, assuming there was 
some way to figure out what those names should be.


But, I think a config file of some sort would be a better overall 
solution. It would be more flexible, and would lend itself better to 
per-application configuration.


Also note that the vendor library selection logic is internal to libGLX, 
so we can still hammer out the rest of the interface in the meantime.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH shader-db 1/2] report.py: rework and update for cycle info

2015-10-09 Thread Erik Faye-Lund

On Fri, Oct 2, 2015 at 11:37 PM, Connor Abbott  wrote:
> Now that we have three separate things we want to measure (instructions,
> cycles, and loops), it's impractical to keep adding special code for
> changes in each thing. Instead, for each program in before and after we
> store a table of measurement -> value, and when reporting we loop over
> each measurement and report helped/hurt before reporting the gained/lost
> programs.
>
> Signed-off-by: Connor Abbott 
> ---
>  report.py | 140 
> ++
>  1 file changed, 67 insertions(+), 73 deletions(-)
>
> diff --git a/report.py b/report.py
> index 4c06714..bc3a640 100755
> --- a/report.py
> +++ b/report.py
> @@ -10,17 +10,22 @@ def get_results(filename):
>
>  results = {}
>
> -re_match = re.compile(r"(\S+) - (.S \S+) shader: (\S*) inst, (\S*) 
> loops")
> +re_match = re.compile(r"(\S+) - (.S \S+) shader: (\S*) inst, (\S*) 
> cycles, (\S*) loops")
>  for line in lines:
>  match = re.search(re_match, line)
>  if match is None:
>  continue
>
>  groups = match.groups()
> -count = int(groups[2])
> -loop = int(groups[3])
> -if count != 0:
> -results[(groups[0], groups[1])] = count, loop
> +inst_count = int(groups[2])
> +   cycle_count = int(groups[3])

Something's up with the indentation here...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] i965: Turn UBOs as push constants

2015-10-09 Thread Abdiel Janulgue

Ping! No thoughts/consensus if this approach is worth considering or
not? The patches are getting stale. Should I re-base or just discard
these optimisations?

On 09/15/2015 08:59 PM, Ben Widawsky wrote:
> On Tue, Sep 15, 2015 at 12:24:00PM +0300, Abdiel Janulgue wrote:
>> Here's a more comprehensive shader-db run:
>>
>> total instructions in shared programs: 6394485 -> 6374865 (-0.31%)
>> instructions in affected programs: 261322 -> 241702 (-7.51%)
>> helped:3210
>> HURT:  0
>> GAINED:5
>> LOST:  2
>>
>>
>> - Abdiel
> 
> Thanks. The interesting thing to me isn't so much that you reduced instruction
> count but hopefully that you reduced a whole bunch of pull loads. I suspect
> there should be benchmarks out there which have a greater benefit than this
> (which was why I asked), but I don't know what off the top of my head.
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nir/glsl: Use shader_prog->Name for naming the NIR shader

2015-10-09 Thread Jason Ekstrand

This has the better name to use. Aparently, sh->Name is usually 0.
---
 src/glsl/nir/glsl_to_nir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 6e1dd84..3284bdc 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -150,7 +150,7 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
   if (sh->Program->SamplersUsed & (1 << i))
  num_textures = i;
 
-   shader->info.name = ralloc_asprintf(shader, "GLSL%d", sh->Name);
+   shader->info.name = ralloc_asprintf(shader, "GLSL%d", shader_prog->Name);
if (shader_prog->Label)
   shader->info.label = ralloc_strdup(shader, shader_prog->Label);
shader->info.num_textures = num_textures;
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 1/3] nir/glsl: Delete dead function handling code

2015-10-09 Thread Jason Ekstrand

Scratch this patch.  Not all of that code is dead, just the part where
we add the return variable.

On Fri, Oct 9, 2015 at 7:09 AM, Jason Ekstrand  wrote:
> ---
>  src/glsl/nir/glsl_to_nir.cpp | 39 +--
>  1 file changed, 1 insertion(+), 38 deletions(-)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> index efaa73e..874e361 100644
> --- a/src/glsl/nir/glsl_to_nir.cpp
> +++ b/src/glsl/nir/glsl_to_nir.cpp
> @@ -495,44 +495,7 @@ nir_visitor::visit(ir_function_signature *ir)
> if (ir->is_intrinsic)
>return;
>
> -   struct hash_entry *entry =
> -  _mesa_hash_table_search(this->overload_table, ir);
> -
> -   assert(entry);
> -   nir_function_overload *overload = (nir_function_overload *) entry->data;
> -
> -   if (ir->is_defined) {
> -  nir_function_impl *impl = nir_function_impl_create(overload);
> -  this->impl = impl;
> -
> -  unsigned num_params = overload->num_params;
> -  impl->num_params = num_params;
> -  impl->params = ralloc_array(this->shader, nir_variable *, num_params);
> -  unsigned i = 0;
> -  foreach_in_list(ir_variable, param, &ir->parameters) {
> - param->accept(this);
> - impl->params[i] = this->var;
> - i++;
> -  }
> -
> -  if (overload->return_type == glsl_type::void_type) {
> - impl->return_var = NULL;
> -  } else {
> - impl->return_var = ralloc(this->shader, nir_variable);
> - impl->return_var->name = ralloc_strdup(impl->return_var,
> -"return_var");
> - impl->return_var->type = overload->return_type;
> -  }
> -
> -  this->is_global = false;
> -
> -  this->cf_node_list = &impl->body;
> -  visit_exec_list(&ir->body, this);
> -
> -  this->is_global = true;
> -   } else {
> -  overload->impl = NULL;
> -   }
> +   assert(!"Functions should be lowered away at this point");
>  }
>
>  void
> --
> 2.5.0.400.gff86faf
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] nir/glsl: Delete dead function handling code

2015-10-09 Thread Jason Ekstrand

---
 src/glsl/nir/glsl_to_nir.cpp | 39 +--
 1 file changed, 1 insertion(+), 38 deletions(-)

diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index efaa73e..874e361 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -495,44 +495,7 @@ nir_visitor::visit(ir_function_signature *ir)
if (ir->is_intrinsic)
   return;
 
-   struct hash_entry *entry =
-  _mesa_hash_table_search(this->overload_table, ir);
-
-   assert(entry);
-   nir_function_overload *overload = (nir_function_overload *) entry->data;
-
-   if (ir->is_defined) {
-  nir_function_impl *impl = nir_function_impl_create(overload);
-  this->impl = impl;
-
-  unsigned num_params = overload->num_params;
-  impl->num_params = num_params;
-  impl->params = ralloc_array(this->shader, nir_variable *, num_params);
-  unsigned i = 0;
-  foreach_in_list(ir_variable, param, &ir->parameters) {
- param->accept(this);
- impl->params[i] = this->var;
- i++;
-  }
-
-  if (overload->return_type == glsl_type::void_type) {
- impl->return_var = NULL;
-  } else {
- impl->return_var = ralloc(this->shader, nir_variable);
- impl->return_var->name = ralloc_strdup(impl->return_var,
-"return_var");
- impl->return_var->type = overload->return_type;
-  }
-
-  this->is_global = false;
-
-  this->cf_node_list = &impl->body;
-  visit_exec_list(&ir->body, this);
-
-  this->is_global = true;
-   } else {
-  overload->impl = NULL;
-   }
+   assert(!"Functions should be lowered away at this point");
 }
 
 void
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/3] nir/prog: Use nir_foreach_variable

2015-10-09 Thread Jason Ekstrand

---
 src/mesa/program/prog_to_nir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
index fc00534..d9b1854 100644
--- a/src/mesa/program/prog_to_nir.c
+++ b/src/mesa/program/prog_to_nir.c
@@ -923,7 +923,7 @@ ptn_add_output_stores(struct ptn_compile *c)
 {
nir_builder *b = &c->build;
 
-   foreach_list_typed(nir_variable, var, node, &b->shader->outputs) {
+   nir_foreach_variable(var, &b->shader->outputs) {
   nir_intrinsic_instr *store =
  nir_intrinsic_instr_create(b->shader, nir_intrinsic_store_var);
   store->num_components = glsl_get_vector_elements(var->type);
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 3/3] nir: Add helpers for creating variables and adding them to lists

2015-10-09 Thread Jason Ekstrand

---
 src/glsl/nir/glsl_to_nir.cpp   | 40 -
 src/glsl/nir/nir.c | 66 ++
 src/glsl/nir/nir.h | 20 +
 src/mesa/program/prog_to_nir.c | 19 +---
 4 files changed, 99 insertions(+), 46 deletions(-)

diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index 874e361..5250080 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -389,35 +389,10 @@ nir_visitor::visit(ir_variable *ir)
 
var->interface_type = ir->get_interface_type();
 
-   switch (var->data.mode) {
-   case nir_var_local:
-  exec_list_push_tail(&impl->locals, &var->node);
-  break;
-
-   case nir_var_global:
-  exec_list_push_tail(&shader->globals, &var->node);
-  break;
-
-   case nir_var_shader_in:
-  exec_list_push_tail(&shader->inputs, &var->node);
-  break;
-
-   case nir_var_shader_out:
-  exec_list_push_tail(&shader->outputs, &var->node);
-  break;
-
-   case nir_var_uniform:
-   case nir_var_shader_storage:
-  exec_list_push_tail(&shader->uniforms, &var->node);
-  break;
-
-   case nir_var_system_value:
-  exec_list_push_tail(&shader->system_values, &var->node);
-  break;
-
-   default:
-  unreachable("not reached");
-   }
+   if (var->data.mode == nir_var_local)
+  nir_function_impl_add_variable(impl, var);
+   else
+  nir_shader_add_variable(shader, var);
 
_mesa_hash_table_insert(var_table, ir, var);
this->var = var;
@@ -2023,13 +1998,10 @@ nir_visitor::visit(ir_constant *ir)
 * constant initializer and return a dereference.
 */
 
-   nir_variable *var = ralloc(this->shader, nir_variable);
-   var->name = ralloc_strdup(var, "const_temp");
-   var->type = ir->type;
-   var->data.mode = nir_var_local;
+   nir_variable *var =
+  nir_local_variable_create(this->impl, ir->type, "const_temp");
var->data.read_only = true;
var->constant_initializer = constant_copy(ir, var);
-   exec_list_push_tail(&this->impl->locals, &var->node);
 
this->deref_head = nir_deref_var_create(this->shader, var);
this->deref_tail = &this->deref_head->deref;
diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
index e12da80..3645726 100644
--- a/src/glsl/nir/nir.c
+++ b/src/glsl/nir/nir.c
@@ -103,6 +103,72 @@ nir_reg_remove(nir_register *reg)
exec_node_remove(®->node);
 }
 
+void
+nir_shader_add_variable(nir_shader *shader, nir_variable *var)
+{
+   switch (var->data.mode) {
+   case nir_var_local:
+  assert(!"nir_shader_add_variable cannot be used for local variables");
+  break;
+
+   case nir_var_global:
+  exec_list_push_tail(&shader->globals, &var->node);
+  break;
+
+   case nir_var_shader_in:
+  exec_list_push_tail(&shader->inputs, &var->node);
+  break;
+
+   case nir_var_shader_out:
+  exec_list_push_tail(&shader->outputs, &var->node);
+  break;
+
+   case nir_var_uniform:
+   case nir_var_shader_storage:
+  exec_list_push_tail(&shader->uniforms, &var->node);
+  break;
+
+   case nir_var_system_value:
+  exec_list_push_tail(&shader->system_values, &var->node);
+  break;
+   }
+}
+
+nir_variable *
+nir_variable_create(nir_shader *shader, nir_variable_mode mode,
+const struct glsl_type *type, const char *name)
+{
+   nir_variable *var = rzalloc(shader, nir_variable);
+   var->name = ralloc_strdup(var, name);
+   var->type = type;
+   var->data.mode = mode;
+
+   if ((mode == nir_var_shader_in && shader->stage != MESA_SHADER_VERTEX) ||
+   (mode == nir_var_shader_out && shader->stage != MESA_SHADER_FRAGMENT))
+  var->data.interpolation = INTERP_QUALIFIER_SMOOTH;
+
+   if (mode == nir_var_shader_in || mode == nir_var_uniform)
+  var->data.read_only = true;
+
+   nir_shader_add_variable(shader, var);
+
+   return var;
+}
+
+nir_variable *
+nir_local_variable_create(nir_function_impl *impl,
+  const struct glsl_type *type, const char *name)
+{
+   nir_variable *var = rzalloc(impl->overload->function->shader, nir_variable);
+   var->name = ralloc_strdup(var, name);
+   var->type = type;
+   var->data.mode = nir_var_local;
+
+   nir_function_impl_add_variable(impl, var);
+
+   return var;
+}
+
 nir_function *
 nir_function_create(nir_shader *shader, const char *name)
 {
diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
index bde9f49..997e2bd 100644
--- a/src/glsl/nir/nir.h
+++ b/src/glsl/nir/nir.h
@@ -1559,6 +1559,26 @@ nir_register *nir_local_reg_create(nir_function_impl 
*impl);
 
 void nir_reg_remove(nir_register *reg);
 
+/** Adds a variable to the appropreate list in nir_shader */
+void nir_shader_add_variable(nir_shader *shader, nir_variable *var);
+
+static inline void
+nir_function_impl_add_variable(nir_function_impl *impl, nir_variable *var)
+{
+   assert(var->data.mode == nir_var_local);
+   exec_list_push_tail(&impl->locals, &var->node);
+}
+
+/** creates a variable, sets a few defaults, and adds it

[Mesa-dev] [PATCH] configure.ac: ensure RM is set

2015-10-09 Thread Jonathan Gray

GNU make predefines RM to rm -f but this is not required by POSIX
so ensure that RM is set.  This fixes "make clean" on OpenBSD.

Signed-off-by: Jonathan Gray 
CC: "10.6 11.0" 
---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index e032d77..9ba25a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -106,6 +106,9 @@ AC_SYS_LARGEFILE
 LT_PREREQ([2.2])
 LT_INIT([disable-static])
 
+RM?=rm -f
+AC_SUBST([RM])
+
 AX_PROG_BISON([],
   AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"],
 [AC_MSG_ERROR([bison not found - unable to compile 
glcpp-parse.y])]))
-- 
2.5.3

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

Re: [Mesa-dev] [PATCH 0/4] Implement separate index spaces for UBOs and SSBOs

2015-10-09 Thread Iago Toral

On Fri, 2015-10-09 at 15:23 +0200, Iago Toral Quiroga wrote:
> See the rationale for this in [1], no piglit regressions observed in my
> IvyBridge laptop.
> 
> Patch 1: Renames {Num}UniformBlocks to {Num}BufferInterfaceBlocks. This is
> more consistent with the current implementation, since right now
> UniformBlocks contains both UBOs and SSBOs.
> 
> Patch 2: Adds separate UniformBlocks and ShaderStorageBlocks arrays.
> 
> Patch 3: Changes lower_ubo_reference pass to use UniformBlocks and
>  ShaderStorageBlocks instead of BufferInterfaceBlocks so we get
>  block indices in separate index spaces.
> 
> Patch 4: Changes i965 to work with separate index spaces.
> 
> I think there are other places that use BufferInterfaceBlocks after
> linking that can be rewritten to use UniformBlocks or ShaderStorageBlocks
> more efficiently. I'd like to tackle that too, but I think it makes sense
> to land this first I think.

For the sake of being complete, other things to do after landing this:

- Fix NIR to use the right counts for UBOs and SSBOs, which is trivial
with this series. Right now we are taking the counts from the combined
list of blocks, which is wrong.

- Now that we use separate index spaces in i965, we might want to define
BRW_NEW_SHADER_STORAGE_BUFFER as well (right now we always upload
UBO/SSBO surfaces together)

Iago

> [1] http://lists.freedesktop.org/archives/mesa-dev/2015-October/095951.html
> 
> Iago Toral Quiroga (4):
>   mesa: Rename {Num}UniformBlocks to {Num}BufferInterfaceBlocks
>   mesa: Add {Num}UniformBlocks and {Num}ShaderStorageBlocks to
> gl_shader{_program}
>   glsl/lower_ubo_reference: lower UBOs and SSBOs to separate index
> spaces
>   i965: Adapt SSBOs to work with their own separate index space
> 
>  src/glsl/link_uniform_initializers.cpp   |   4 +-
>  src/glsl/link_uniforms.cpp   |  22 ++---
>  src/glsl/linker.cpp  | 105 
> ++-
>  src/glsl/lower_ubo_reference.cpp |  22 +++--
>  src/glsl/nir/glsl_to_nir.cpp |   2 +-
>  src/glsl/standalone_scaffolding.cpp  |  11 ++-
>  src/mesa/drivers/dri/i965/brw_context.h  |   4 +-
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp |  24 +++---
>  src/mesa/drivers/dri/i965/brw_shader.cpp |   7 +-
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp   |  24 +++---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  79 +
>  src/mesa/main/mtypes.h   |  53 +++-
>  src/mesa/main/shader_query.cpp   |   4 +-
>  src/mesa/main/shaderapi.c|   4 +-
>  src/mesa/main/shaderobj.c|   4 +-
>  src/mesa/main/uniforms.c |  12 +--
>  src/mesa/state_tracker/st_atom_constbuf.c|   4 +-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp   |   4 +-
>  18 files changed, 257 insertions(+), 132 deletions(-)
> 


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

[Mesa-dev] [PATCH 2/4] mesa: Add {Num}UniformBlocks and {Num}ShaderStorageBlocks to gl_shader{_program}

2015-10-09 Thread Iago Toral Quiroga

These arrays provide backends with separate index spaces for UBOS and SSBOs.
---
 src/glsl/linker.cpp | 61 +
 src/glsl/standalone_scaffolding.cpp |  9 ++
 src/mesa/main/mtypes.h  | 49 -
 3 files changed, 118 insertions(+), 1 deletion(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 8d30bea..972bd40 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -3599,6 +3599,42 @@ link_assign_subroutine_types(struct gl_shader_program 
*prog)
}
 }
 
+static void
+split_ubos_and_ssbos(void *mem_ctx,
+ struct gl_uniform_block *blocks,
+ unsigned num_blocks,
+ struct gl_uniform_block ***ubos,
+ unsigned *num_ubos,
+ struct gl_uniform_block ***ssbos,
+ unsigned *num_ssbos)
+{
+   unsigned num_ubo_blocks = 0;
+   unsigned num_ssbo_blocks = 0;
+
+   for (unsigned i = 0; i < num_blocks; i++) {
+  if (blocks[i].IsShaderStorage)
+ num_ssbo_blocks++;
+  else
+ num_ubo_blocks++;
+   }
+
+   *ubos = ralloc_array(mem_ctx, gl_uniform_block *, num_ubo_blocks);
+   *num_ubos = 0;
+
+   *ssbos = ralloc_array(mem_ctx, gl_uniform_block *, num_ssbo_blocks);
+   *num_ssbos = 0;
+
+   for (unsigned i = 0; i < num_blocks; i++) {
+  if (blocks[i].IsShaderStorage) {
+ (*ssbos)[(*num_ssbos)++] = &blocks[i];
+  } else {
+ (*ubos)[(*num_ubos)++] = &blocks[i];
+  }
+   }
+
+   assert(*num_ubos + *num_ssbos == num_blocks);
+}
+
 void
 link_shaders(struct gl_context *ctx, struct gl_shader_program *prog)
 {
@@ -4110,6 +4146,31 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
   }
}
 
+   /* Split BufferInterfaceBlocks into UniformBlocks and ShaderStorageBlocks
+* for gl_shader_program and gl_shader, so that drivers that need separate
+* index spaces for each set can have that.
+*/
+   for (unsigned i = MESA_SHADER_VERTEX; i <= MESA_SHADER_FRAGMENT; i++) {
+  if (prog->_LinkedShaders[i] != NULL) {
+ gl_shader *sh = prog->_LinkedShaders[i];
+ split_ubos_and_ssbos(sh,
+  sh->BufferInterfaceBlocks,
+  sh->NumBufferInterfaceBlocks,
+  &sh->UniformBlocks,
+  &sh->NumUniformBlocks,
+  &sh->ShaderStorageBlocks,
+  &sh->NumShaderStorageBlocks);
+  }
+   }
+
+   split_ubos_and_ssbos(prog,
+prog->BufferInterfaceBlocks,
+prog->NumBufferInterfaceBlocks,
+&prog->UniformBlocks,
+&prog->NumUniformBlocks,
+&prog->ShaderStorageBlocks,
+&prog->NumShaderStorageBlocks);
+
/* FINISHME: Assign fragment shader output locations. */
 
 done:
diff --git a/src/glsl/standalone_scaffolding.cpp 
b/src/glsl/standalone_scaffolding.cpp
index 5952792..eccf094 100644
--- a/src/glsl/standalone_scaffolding.cpp
+++ b/src/glsl/standalone_scaffolding.cpp
@@ -110,6 +110,15 @@ _mesa_clear_shader_program_data(struct gl_shader_program 
*shProg)
ralloc_free(shProg->BufferInterfaceBlocks);
shProg->BufferInterfaceBlocks = NULL;
shProg->NumBufferInterfaceBlocks = 0;
+
+   ralloc_free(shProg->UniformBlocks);
+   shProg->UniformBlocks = NULL;
+   shProg->NumUniformBlocks = 0;
+
+   ralloc_free(shProg->ShaderStorageBlocks);
+   shProg->ShaderStorageBlocks = NULL;
+   shProg->NumShaderStorageBlocks = 0;
+
for (i = 0; i < MESA_SHADER_STAGES; i++) {
   ralloc_free(shProg->UniformBlockStageIndex[i]);
   shProg->UniformBlockStageIndex[i] = NULL;
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 347da14..178478f 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2286,13 +2286,35 @@ struct gl_shader
unsigned num_combined_uniform_components;
 
/**
-* This shader's uniform block information.
+* This shader's uniform/ssbo block information.
 *
 * These fields are only set post-linking.
+*
+* BufferInterfaceBlocks is a list containing both UBOs and SSBOs. This is
+* useful during the linking process so that we don't have to handle SSBOs
+* specifically.
+*
+* UniformBlocks is a list of UBOs. This is useful for backends that need
+* or prefer to see separate index spaces for UBOS and SSBOs like the GL
+* API specifies.
+*
+* ShaderStorageBlocks is a list of SSBOs. This is useful for backends that
+* need or prefer to see separate index spaces for UBOS and SSBOs like the
+* GL API specifies.
+*
+* UniformBlocks and ShaderStorageBlocks only have pointers into
+* BufferInterfaceBlocks so the actual resource information is not
+* duplicated.
 */
unsigned NumBufferInterfaceBlocks;
struct gl_un

[Mesa-dev] [PATCH 1/4] mesa: Rename {Num}UniformBlocks to {Num}BufferInterfaceBlocks

2015-10-09 Thread Iago Toral Quiroga

Currently, these arrays in gl_shader and gl_shader_program hold both
UBOs and SSBOs, so this looks like a better name. We were already
using NumBufferInterfaceBlocks in gl_shader_program, so this makes
things more consistent as well.

In a later patch we will add {Num}UniformBlocks and
{Num}ShaderStorageBlocks which will contain only references to
UBOs and SSBOs respectively that will provide backends with
a separate index space for both types of objects.
---
 src/glsl/link_uniform_initializers.cpp   |  4 +--
 src/glsl/link_uniforms.cpp   | 22 ++--
 src/glsl/linker.cpp  | 44 
 src/glsl/lower_ubo_reference.cpp |  8 ++---
 src/glsl/nir/glsl_to_nir.cpp |  2 +-
 src/glsl/standalone_scaffolding.cpp  |  4 +--
 src/mesa/drivers/dri/i965/brw_shader.cpp |  4 +--
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 10 +++---
 src/mesa/main/mtypes.h   |  6 ++--
 src/mesa/main/shader_query.cpp   |  4 +--
 src/mesa/main/shaderapi.c|  4 +--
 src/mesa/main/shaderobj.c|  4 +--
 src/mesa/main/uniforms.c | 12 +++
 src/mesa/state_tracker/st_atom_constbuf.c|  4 +--
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   |  4 +--
 15 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/src/glsl/link_uniform_initializers.cpp 
b/src/glsl/link_uniform_initializers.cpp
index 0918d2a..1ae0a8e 100644
--- a/src/glsl/link_uniform_initializers.cpp
+++ b/src/glsl/link_uniform_initializers.cpp
@@ -49,7 +49,7 @@ get_uniform_block_index(const gl_shader_program *shProg,
 const char *uniformBlockName)
 {
for (unsigned i = 0; i < shProg->NumBufferInterfaceBlocks; i++) {
-  if (!strcmp(shProg->UniformBlocks[i].Name, uniformBlockName))
+  if (!strcmp(shProg->BufferInterfaceBlocks[i].Name, uniformBlockName))
 return i;
}
 
@@ -169,7 +169,7 @@ set_block_binding(gl_shader_program *prog, const char 
*block_name, int binding)
 
  if (stage_index != -1) {
 struct gl_shader *sh = prog->_LinkedShaders[i];
-sh->UniformBlocks[stage_index].Binding = binding;
+sh->BufferInterfaceBlocks[stage_index].Binding = binding;
  }
   }
 }
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 0ccd9c8..5465687 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -502,9 +502,9 @@ public:
 
 for (unsigned i = 0; i < prog->NumBufferInterfaceBlocks; i++) {
if (strncmp(var->get_interface_type()->name,
-   prog->UniformBlocks[i].Name,
+   prog->BufferInterfaceBlocks[i].Name,
l) == 0
-   && prog->UniformBlocks[i].Name[l] == '[') {
+   && prog->BufferInterfaceBlocks[i].Name[l] == '[') {
   ubo_block_index = i;
   break;
}
@@ -512,7 +512,7 @@ public:
  } else {
 for (unsigned i = 0; i < prog->NumBufferInterfaceBlocks; i++) {
if (strcmp(var->get_interface_type()->name,
-  prog->UniformBlocks[i].Name) == 0) {
+  prog->BufferInterfaceBlocks[i].Name) == 0) {
   ubo_block_index = i;
   break;
}
@@ -530,7 +530,7 @@ public:
 ubo_byte_offset = 0;
  } else {
 const struct gl_uniform_block *const block =
-   &prog->UniformBlocks[ubo_block_index];
+   &prog->BufferInterfaceBlocks[ubo_block_index];
 
 assert(var->data.location != -1);
 
@@ -971,10 +971,10 @@ link_update_uniform_buffer_variables(struct gl_shader 
*shader)
   }
 
   const unsigned l = strlen(var->name);
-  for (unsigned i = 0; i < shader->NumUniformBlocks; i++) {
-for (unsigned j = 0; j < shader->UniformBlocks[i].NumUniforms; j++) {
+  for (unsigned i = 0; i < shader->NumBufferInterfaceBlocks; i++) {
+for (unsigned j = 0; j < shader->BufferInterfaceBlocks[i].NumUniforms; 
j++) {
 if (sentinel) {
-   const char *begin = shader->UniformBlocks[i].Uniforms[j].Name;
+   const char *begin = 
shader->BufferInterfaceBlocks[i].Uniforms[j].Name;
const char *end = strchr(begin, sentinel);
 
if (end == NULL)
@@ -989,7 +989,7 @@ link_update_uniform_buffer_variables(struct gl_shader 
*shader)
   break;
}
 } else if (!strcmp(var->name,
-   shader->UniformBlocks[i].Uniforms[j].Name)) {
+   
shader->BufferInterfaceBlocks[i].Uniforms[j].Name)) {
   found = true;
   var->data.location = j;
   break;
@@ -1115,10 +1115,10 @@

[Mesa-dev] [PATCH 4/4] i965: Adapt SSBOs to work with their own separate index space

2015-10-09 Thread Iago Toral Quiroga

---
 src/mesa/drivers/dri/i965/brw_context.h  |  4 +-
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 24 +++
 src/mesa/drivers/dri/i965/brw_shader.cpp |  9 ++-
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp   | 24 +++
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 79 
 5 files changed, 71 insertions(+), 69 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index aa1284d..6acf4a1 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -352,6 +352,7 @@ struct brw_stage_prog_data {
   uint32_t texture_start;
   uint32_t gather_texture_start;
   uint32_t ubo_start;
+  uint32_t ssbo_start;
   uint32_t abo_start;
   uint32_t image_start;
   uint32_t shader_time_start;
@@ -715,9 +716,6 @@ struct brw_vs_prog_data {
 /** Max number of SSBOs in a shader */
 #define BRW_MAX_SSBO 12
 
-/** Max number of combined UBOs and SSBOs in a shader */
-#define BRW_MAX_COMBINED_UBO_SSBO (BRW_MAX_UBO + BRW_MAX_SSBO)
-
 /** Max number of atomic counter buffer objects in a shader */
 #define BRW_MAX_ABO 16
 
diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 03fe680..2dd096f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -1488,21 +1488,21 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
 
   fs_reg surf_index;
   if (const_uniform_block) {
- unsigned index = stage_prog_data->binding_table.ubo_start +
+ unsigned index = stage_prog_data->binding_table.ssbo_start +
   const_uniform_block->u[0];
  surf_index = fs_reg(index);
  brw_mark_surface_used(prog_data, index);
   } else {
  surf_index = vgrf(glsl_type::uint_type);
  bld.ADD(surf_index, get_nir_src(instr->src[0]),
- fs_reg(stage_prog_data->binding_table.ubo_start));
+ fs_reg(stage_prog_data->binding_table.ssbo_start));
  surf_index = bld.emit_uniformize(surf_index);
 
  /* Assume this may touch any UBO. It would be nice to provide
   * a tighter bound, but the array information is already lowered away.
   */
  brw_mark_surface_used(prog_data,
-   stage_prog_data->binding_table.ubo_start +
+   stage_prog_data->binding_table.ssbo_start +
nir->info.num_ssbos - 1);
   }
 
@@ -1684,18 +1684,18 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
   nir_const_value *const_uniform_block =
  nir_src_as_const_value(instr->src[1]);
   if (const_uniform_block) {
- unsigned index = stage_prog_data->binding_table.ubo_start +
+ unsigned index = stage_prog_data->binding_table.ssbo_start +
   const_uniform_block->u[0];
  surf_index = fs_reg(index);
  brw_mark_surface_used(prog_data, index);
   } else {
  surf_index = vgrf(glsl_type::uint_type);
  bld.ADD(surf_index, get_nir_src(instr->src[1]),
-  fs_reg(stage_prog_data->binding_table.ubo_start));
+  fs_reg(stage_prog_data->binding_table.ssbo_start));
  surf_index = bld.emit_uniformize(surf_index);
 
  brw_mark_surface_used(prog_data,
-   stage_prog_data->binding_table.ubo_start +
+   stage_prog_data->binding_table.ssbo_start +
nir->info.num_ssbos - 1);
   }
 
@@ -1810,7 +1810,7 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
 
case nir_intrinsic_get_buffer_size: {
   nir_const_value *const_uniform_block = 
nir_src_as_const_value(instr->src[0]);
-  unsigned ubo_index = const_uniform_block ? const_uniform_block->u[0] : 0;
+  unsigned ssbo_index = const_uniform_block ? const_uniform_block->u[0] : 
0;
   int reg_width = dispatch_width / 8;
 
   /* Set LOD = 0 */
@@ -1821,7 +1821,7 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
nir_intrinsic_instr *instr
   BRW_REGISTER_TYPE_UD);
   bld.LOAD_PAYLOAD(src_payload, &source, 1, 0);
 
-  fs_reg surf_index = fs_reg(prog_data->binding_table.ubo_start + 
ubo_index);
+  fs_reg surf_index = fs_reg(prog_data->binding_table.ssbo_start + 
ssbo_index);
   fs_inst *inst = bld.emit(FS_OPCODE_GET_BUFFER_SIZE, dest,
src_payload, surf_index);
   inst->header_size = 0;
@@ -1874,20 +1874,20 @@ fs_visitor::nir_emit_ssbo_atomic(const fs_builder &bld,
fs_reg surface;
nir_const_value *const_surface = nir_src_as_const_value(instr->src[0]);
if (const_surface) {
-  unsigned surf_index = stage_prog_data->binding_table.ubo_start

[Mesa-dev] [PATCH 0/4] Implement separate index spaces for UBOs and SSBOs

2015-10-09 Thread Iago Toral Quiroga

See the rationale for this in [1], no piglit regressions observed in my
IvyBridge laptop.

Patch 1: Renames {Num}UniformBlocks to {Num}BufferInterfaceBlocks. This is
more consistent with the current implementation, since right now
UniformBlocks contains both UBOs and SSBOs.

Patch 2: Adds separate UniformBlocks and ShaderStorageBlocks arrays.

Patch 3: Changes lower_ubo_reference pass to use UniformBlocks and
 ShaderStorageBlocks instead of BufferInterfaceBlocks so we get
 block indices in separate index spaces.

Patch 4: Changes i965 to work with separate index spaces.

I think there are other places that use BufferInterfaceBlocks after
linking that can be rewritten to use UniformBlocks or ShaderStorageBlocks
more efficiently. I'd like to tackle that too, but I think it makes sense
to land this first I think.

[1] http://lists.freedesktop.org/archives/mesa-dev/2015-October/095951.html

Iago Toral Quiroga (4):
  mesa: Rename {Num}UniformBlocks to {Num}BufferInterfaceBlocks
  mesa: Add {Num}UniformBlocks and {Num}ShaderStorageBlocks to
gl_shader{_program}
  glsl/lower_ubo_reference: lower UBOs and SSBOs to separate index
spaces
  i965: Adapt SSBOs to work with their own separate index space

 src/glsl/link_uniform_initializers.cpp   |   4 +-
 src/glsl/link_uniforms.cpp   |  22 ++---
 src/glsl/linker.cpp  | 105 ++-
 src/glsl/lower_ubo_reference.cpp |  22 +++--
 src/glsl/nir/glsl_to_nir.cpp |   2 +-
 src/glsl/standalone_scaffolding.cpp  |  11 ++-
 src/mesa/drivers/dri/i965/brw_context.h  |   4 +-
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp |  24 +++---
 src/mesa/drivers/dri/i965/brw_shader.cpp |   7 +-
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp   |  24 +++---
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  79 +
 src/mesa/main/mtypes.h   |  53 +++-
 src/mesa/main/shader_query.cpp   |   4 +-
 src/mesa/main/shaderapi.c|   4 +-
 src/mesa/main/shaderobj.c|   4 +-
 src/mesa/main/uniforms.c |  12 +--
 src/mesa/state_tracker/st_atom_constbuf.c|   4 +-
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   |   4 +-
 18 files changed, 257 insertions(+), 132 deletions(-)

-- 
1.9.1

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

[Mesa-dev] [PATCH 3/4] glsl/lower_ubo_reference: lower UBOs and SSBOs to separate index spaces

2015-10-09 Thread Iago Toral Quiroga

---
 src/glsl/lower_ubo_reference.cpp | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/src/glsl/lower_ubo_reference.cpp b/src/glsl/lower_ubo_reference.cpp
index 338e21b..c00dc8e 100644
--- a/src/glsl/lower_ubo_reference.cpp
+++ b/src/glsl/lower_ubo_reference.cpp
@@ -277,10 +277,20 @@ 
lower_ubo_reference_visitor::setup_for_load_or_store(ir_variable *var,
   interface_field_name(mem_ctx, (char *) var->get_interface_type()->name,
deref, &nonconst_block_index);
 
-   /* Locate the ubo block by interface name */
+   /* Locate the block by interface name */
+   this->is_shader_storage = var->is_in_shader_storage_block();
+   unsigned num_blocks;
+   struct gl_uniform_block **blocks;
+   if (this->is_shader_storage) {
+  num_blocks = shader->NumShaderStorageBlocks;
+  blocks = shader->ShaderStorageBlocks;
+   } else {
+  num_blocks = shader->NumUniformBlocks;
+  blocks = shader->UniformBlocks;
+   }
this->uniform_block = NULL;
-   for (unsigned i = 0; i < shader->NumBufferInterfaceBlocks; i++) {
-  if (strcmp(field_name, shader->BufferInterfaceBlocks[i].Name) == 0) {
+   for (unsigned i = 0; i < num_blocks; i++) {
+  if (strcmp(field_name, blocks[i]->Name) == 0) {
 
  ir_constant *index = new(mem_ctx) ir_constant(i);
 
@@ -292,12 +302,8 @@ 
lower_ubo_reference_visitor::setup_for_load_or_store(ir_variable *var,
 this->uniform_block = index;
  }
 
- this->is_shader_storage = 
shader->BufferInterfaceBlocks[i].IsShaderStorage;
-
- struct gl_uniform_block *block = &shader->BufferInterfaceBlocks[i];
-
  this->ubo_var = var->is_interface_instance()
-? &block->Uniforms[0] : &block->Uniforms[var->data.location];
+? &blocks[i]->Uniforms[0] : 
&blocks[i]->Uniforms[var->data.location];
 
  break;
   }
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 06/17] nir/info: Add a few bits of info for fragment shaders

2015-10-09 Thread Jason Ekstrand

On Thu, Oct 8, 2015 at 5:22 PM, Jason Ekstrand  wrote:
> ---
>  src/glsl/nir/glsl_to_nir.cpp   |  9 +
>  src/glsl/nir/nir.h | 13 +
>  src/mesa/program/prog_to_nir.c |  6 ++
>  3 files changed, 28 insertions(+)
>
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> index e4aa709..ddacb4e 100644
> --- a/src/glsl/nir/glsl_to_nir.cpp
> +++ b/src/glsl/nir/glsl_to_nir.cpp
> @@ -173,6 +173,15 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
>shader->info.gs.invocations = sh->Geom.Invocations;
>break;
>
> +   case MESA_SHADER_FRAGMENT: {
> +  struct gl_fragment_program *fp =
> + (struct gl_fragment_program *)sh->Program;
> +
> +  shader->info.fs.uses_discard = fp->UsesKill;
> +  shader->info.fs.early_fragment_tests = sh->EarlyFragmentTests;
> +  shader->info.fs.depth_layout = fp->FragDepthLayout;

Missing a break statement.  Fixed locally.

> +   }
> +
> case MESA_SHADER_COMPUTE: {
>struct gl_compute_program *cp = (struct gl_compute_program 
> *)sh->Program;
>shader->info.cs.local_size[0] = cp->LocalSize[0];
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index 2ce958a..14f5535 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -1503,6 +1503,19 @@ typedef struct nir_shader_info {
>} gs;
>
>struct {
> + bool uses_discard;
> +
> + /**
> +  * Whether early fragment tests are enabled as defined by
> +  * ARB_shader_image_load_store.
> +  */
> + bool early_fragment_tests;
> +
> + /** gl_FragDepth layout for ARB_conservative_depth. */
> + enum gl_frag_depth_layout depth_layout;
> +  } fs;
> +
> +  struct {
>   unsigned local_size[3];
>} cs;
> };
> diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
> index fc00534..3d91b3b 100644
> --- a/src/mesa/program/prog_to_nir.c
> +++ b/src/mesa/program/prog_to_nir.c
> @@ -1135,6 +1135,12 @@ prog_to_nir(const struct gl_program *prog,
> s->info.uses_clip_distance_out = false;
> s->info.separate_shader = false;
>
> +   if (stage == MESA_SHADER_FRAGMENT) {
> +  struct gl_fragment_program *fp = (struct gl_fragment_program *)prog;
> +
> +  s->info.fs.uses_discard = fp->UsesKill;
> +   }
> +
>  fail:
> if (c->error) {
>ralloc_free(s);
> --
> 2.5.0.400.gff86faf
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nvc0: fix wrong value for NVC8_COMPUTE_CLASS

2015-10-09 Thread Samuel Pitoiset

Compute class value for GF110+ is 0x91c0 and not 0x92c0. This fixes
compute support and MP performance counters on GF110.

Signed-off-by: Samuel Pitoiset 
---
 src/gallium/drivers/nouveau/nv_object.xml.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv_object.xml.h 
b/src/gallium/drivers/nouveau/nv_object.xml.h
index 0a0e187..92c0633 100644
--- a/src/gallium/drivers/nouveau/nv_object.xml.h
+++ b/src/gallium/drivers/nouveau/nv_object.xml.h
@@ -197,7 +197,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 #define NV50_COMPUTE_CLASS 0x50c0
 #define NVA3_COMPUTE_CLASS 0x85c0
 #define NVC0_COMPUTE_CLASS 0x90c0
-#define NVC8_COMPUTE_CLASS 0x92c0
+#define NVC8_COMPUTE_CLASS 0x91c0
 #define NVE4_COMPUTE_CLASS 0xa0c0
 #define NVF0_COMPUTE_CLASS 0xa1c0
 #define NV84_CRYPT_CLASS   0x74c1
-- 
2.6.1

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

Re: [Mesa-dev] [PATCH 06/17] nir/info: Add a few bits of info for fragment shaders

2015-10-09 Thread Jason Ekstrand

On Fri, Oct 9, 2015 at 6:04 AM, Pohjolainen, Topi
 wrote:
> On Fri, Oct 09, 2015 at 05:58:41AM -0700, Jason Ekstrand wrote:
>> On Fri, Oct 9, 2015 at 12:15 AM, Pohjolainen, Topi
>>  wrote:
>> > On Thu, Oct 08, 2015 at 05:22:38PM -0700, Jason Ekstrand wrote:
>> >> ---
>> >>  src/glsl/nir/glsl_to_nir.cpp   |  9 +
>> >>  src/glsl/nir/nir.h | 13 +
>> >>  src/mesa/program/prog_to_nir.c |  6 ++
>> >>  3 files changed, 28 insertions(+)
>> >>
>> >> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
>> >> index e4aa709..ddacb4e 100644
>> >> --- a/src/glsl/nir/glsl_to_nir.cpp
>> >> +++ b/src/glsl/nir/glsl_to_nir.cpp
>> >> @@ -173,6 +173,15 @@ glsl_to_nir(const struct gl_shader_program 
>> >> *shader_prog,
>> >>shader->info.gs.invocations = sh->Geom.Invocations;
>> >>break;
>> >>
>> >> +   case MESA_SHADER_FRAGMENT: {
>> >> +  struct gl_fragment_program *fp =
>> >> + (struct gl_fragment_program *)sh->Program;
>> >> +
>> >> +  shader->info.fs.uses_discard = fp->UsesKill;
>> >> +  shader->info.fs.early_fragment_tests = sh->EarlyFragmentTests;
>> >> +  shader->info.fs.depth_layout = fp->FragDepthLayout;
>> >
>> > This series replaces in patch 15 the expression:
>> >
>> > fp->Base.OutputsWritten & BITFIELD64_BIT(FRAG_RESULT_DEPTH)
>> >
>> > with this, right? If that is the case, it would be nice to say something in
>> > one of the commits (or perhaps even use a separate patch changing the logic
>> > itself).
>>
>> Not quite.  I believe that's replaced with
>>
>> shader->info.outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH)
>>
>> It is used in patch 15 but it's used by the updated compute_depth_mode 
>> function.
>
> You are perfectly right, my bad. Sorry for the noise.

That's ok.  I'm glad you're going through it carefully enough to
notice these things.  You already caught one nasty bug!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/17] nir/info: Add a few bits of info for fragment shaders

2015-10-09 Thread Pohjolainen, Topi

On Fri, Oct 09, 2015 at 05:58:41AM -0700, Jason Ekstrand wrote:
> On Fri, Oct 9, 2015 at 12:15 AM, Pohjolainen, Topi
>  wrote:
> > On Thu, Oct 08, 2015 at 05:22:38PM -0700, Jason Ekstrand wrote:
> >> ---
> >>  src/glsl/nir/glsl_to_nir.cpp   |  9 +
> >>  src/glsl/nir/nir.h | 13 +
> >>  src/mesa/program/prog_to_nir.c |  6 ++
> >>  3 files changed, 28 insertions(+)
> >>
> >> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> >> index e4aa709..ddacb4e 100644
> >> --- a/src/glsl/nir/glsl_to_nir.cpp
> >> +++ b/src/glsl/nir/glsl_to_nir.cpp
> >> @@ -173,6 +173,15 @@ glsl_to_nir(const struct gl_shader_program 
> >> *shader_prog,
> >>shader->info.gs.invocations = sh->Geom.Invocations;
> >>break;
> >>
> >> +   case MESA_SHADER_FRAGMENT: {
> >> +  struct gl_fragment_program *fp =
> >> + (struct gl_fragment_program *)sh->Program;
> >> +
> >> +  shader->info.fs.uses_discard = fp->UsesKill;
> >> +  shader->info.fs.early_fragment_tests = sh->EarlyFragmentTests;
> >> +  shader->info.fs.depth_layout = fp->FragDepthLayout;
> >
> > This series replaces in patch 15 the expression:
> >
> > fp->Base.OutputsWritten & BITFIELD64_BIT(FRAG_RESULT_DEPTH)
> >
> > with this, right? If that is the case, it would be nice to say something in
> > one of the commits (or perhaps even use a separate patch changing the logic
> > itself).
> 
> Not quite.  I believe that's replaced with
> 
> shader->info.outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH)
> 
> It is used in patch 15 but it's used by the updated compute_depth_mode 
> function.

You are perfectly right, my bad. Sorry for the noise.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/17] i965/vs: Move use_legacy_snorm_formula into the shader key

2015-10-09 Thread Jason Ekstrand

On Fri, Oct 9, 2015 at 5:58 AM, Pohjolainen, Topi
 wrote:
> On Fri, Oct 09, 2015 at 05:53:43AM -0700, Jason Ekstrand wrote:
>> On Fri, Oct 9, 2015 at 12:00 AM, Pohjolainen, Topi
>>  wrote:
>> > On Thu, Oct 08, 2015 at 05:22:42PM -0700, Jason Ekstrand wrote:
>> >> This is really an input into the shader compiler so it kind of makes sense
>> >> in the key.  Also, given where it's placed into the key, it doesn't
>> >> actually make it any bigger.
>> >
>> > But the key specifically controls recompiles, right? Before this didn't
>> > trigger a recompile but now it does. I'm probably missing something...
>>
>> You're not missing anything.  It can cause recompiles.  However,
>> whether or not you're gles3 doesn't change that often. It can change
>> due to doing meta operations but those shaders are tiny so it's
>> probably not a big deal.
>>
>> That said, this is one of the sketchier patches in the series.  I'm
>> 100% ok with leaving it out and just passing use_legacy_snorm_formula
>> as a parameter.  I was just hoping I could reduce the parameter bloat
>> a little.
>
> I don't mind changing this. I was just concerned if we had a bug earlier as we
> didn't recompile when switching between gles3 and non-gles3.

We may yet have such a bug.  When I kicked this series off to Jenkins
last night, it came back with GPU hangs on SNB and HSW.
Unfortunately, I have yet to be able to reproduce on my HSW so I'm not
sure my patches are actually to blame.  If I can prove that it comes
from this series, this patch is definitely the most suspect.

--Jason

>>
>> >> ---
>> >>  src/mesa/drivers/dri/i965/brw_program.h   | 2 ++
>> >>  src/mesa/drivers/dri/i965/brw_vec4.cpp| 3 +--
>> >>  src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 9 -
>> >>  src/mesa/drivers/dri/i965/brw_vs.c| 3 +++
>> >>  src/mesa/drivers/dri/i965/brw_vs.h| 5 +
>> >>  5 files changed, 11 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
>> >> b/src/mesa/drivers/dri/i965/brw_program.h
>> >> index cf0522a..2a9d1e9 100644
>> >> --- a/src/mesa/drivers/dri/i965/brw_program.h
>> >> +++ b/src/mesa/drivers/dri/i965/brw_program.h
>> >> @@ -91,6 +91,8 @@ struct brw_vs_prog_key {
>> >>
>> >> bool clamp_vertex_color:1;
>> >>
>> >> +   bool use_legacy_snorm_formula:1;
>> >> +
>> >> /**
>> >>  * How many user clipping planes are being uploaded to the vertex 
>> >> shader as
>> >>  * push constants.
>> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>> >> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> >> index 4b8390f..4b03967 100644
>> >> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> >> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> >> @@ -1992,8 +1992,7 @@ brw_vs_emit(struct brw_context *brw,
>> >>
>> >>vec4_vs_visitor v(brw->intelScreen->compiler, brw, key, prog_data,
>> >>  vp->Base.nir, brw_select_clip_planes(&brw->ctx),
>> >> -mem_ctx, shader_time_index,
>> >> -!_mesa_is_gles3(&brw->ctx));
>> >> +mem_ctx, shader_time_index);
>> >>if (!v.run()) {
>> >>   if (prog) {
>> >>  prog->LinkStatus = false;
>> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp 
>> >> b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> >> index 485a80e..9cf04cd 100644
>> >> --- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> >> +++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> >> @@ -77,7 +77,8 @@ vec4_vs_visitor::emit_prolog()
>> >>  /* ES 3.0 has different rules for converting signed 
>> >> normalized
>> >>   * fixed-point numbers than desktop GL.
>> >>   */
>> >> -if ((wa_flags & BRW_ATTRIB_WA_SIGN) && 
>> >> !use_legacy_snorm_formula) {
>> >> +if ((wa_flags & BRW_ATTRIB_WA_SIGN) &&
>> >> +!key->use_legacy_snorm_formula) {
>> >> /* According to equation 2.2 of the ES 3.0 specification,
>> >>  * signed normalization conversion is done by:
>> >>  *
>> >> @@ -304,14 +305,12 @@ vec4_vs_visitor::vec4_vs_visitor(const struct 
>> >> brw_compiler *compiler,
>> >>   const nir_shader *shader,
>> >>   gl_clip_plane *clip_planes,
>> >>   void *mem_ctx,
>> >> - int shader_time_index,
>> >> - bool use_legacy_snorm_formula)
>> >> + int shader_time_index)
>> >> : vec4_visitor(compiler, log_data, &key->tex, &vs_prog_data->base, 
>> >> shader,
>> >>mem_ctx, false /* no_spills */, shader_time_index),
>> >>   key(key),
>> >>   vs_prog_data(vs_prog_data),
>> >> - clip_planes(clip_planes),
>> >> - use_legacy_snorm_formula(use_legacy_snorm_formula)
>> >> + clip_pla

Re: [Mesa-dev] [PATCH 10/17] i965/vs: Move use_legacy_snorm_formula into the shader key

2015-10-09 Thread Pohjolainen, Topi

On Fri, Oct 09, 2015 at 05:53:43AM -0700, Jason Ekstrand wrote:
> On Fri, Oct 9, 2015 at 12:00 AM, Pohjolainen, Topi
>  wrote:
> > On Thu, Oct 08, 2015 at 05:22:42PM -0700, Jason Ekstrand wrote:
> >> This is really an input into the shader compiler so it kind of makes sense
> >> in the key.  Also, given where it's placed into the key, it doesn't
> >> actually make it any bigger.
> >
> > But the key specifically controls recompiles, right? Before this didn't
> > trigger a recompile but now it does. I'm probably missing something...
> 
> You're not missing anything.  It can cause recompiles.  However,
> whether or not you're gles3 doesn't change that often. It can change
> due to doing meta operations but those shaders are tiny so it's
> probably not a big deal.
> 
> That said, this is one of the sketchier patches in the series.  I'm
> 100% ok with leaving it out and just passing use_legacy_snorm_formula
> as a parameter.  I was just hoping I could reduce the parameter bloat
> a little.

I don't mind changing this. I was just concerned if we had a bug earlier as we
didn't recompile when switching between gles3 and non-gles3.

> 
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_program.h   | 2 ++
> >>  src/mesa/drivers/dri/i965/brw_vec4.cpp| 3 +--
> >>  src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 9 -
> >>  src/mesa/drivers/dri/i965/brw_vs.c| 3 +++
> >>  src/mesa/drivers/dri/i965/brw_vs.h| 5 +
> >>  5 files changed, 11 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
> >> b/src/mesa/drivers/dri/i965/brw_program.h
> >> index cf0522a..2a9d1e9 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_program.h
> >> +++ b/src/mesa/drivers/dri/i965/brw_program.h
> >> @@ -91,6 +91,8 @@ struct brw_vs_prog_key {
> >>
> >> bool clamp_vertex_color:1;
> >>
> >> +   bool use_legacy_snorm_formula:1;
> >> +
> >> /**
> >>  * How many user clipping planes are being uploaded to the vertex 
> >> shader as
> >>  * push constants.
> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> >> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> index 4b8390f..4b03967 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> >> @@ -1992,8 +1992,7 @@ brw_vs_emit(struct brw_context *brw,
> >>
> >>vec4_vs_visitor v(brw->intelScreen->compiler, brw, key, prog_data,
> >>  vp->Base.nir, brw_select_clip_planes(&brw->ctx),
> >> -mem_ctx, shader_time_index,
> >> -!_mesa_is_gles3(&brw->ctx));
> >> +mem_ctx, shader_time_index);
> >>if (!v.run()) {
> >>   if (prog) {
> >>  prog->LinkStatus = false;
> >> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp 
> >> b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
> >> index 485a80e..9cf04cd 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
> >> @@ -77,7 +77,8 @@ vec4_vs_visitor::emit_prolog()
> >>  /* ES 3.0 has different rules for converting signed normalized
> >>   * fixed-point numbers than desktop GL.
> >>   */
> >> -if ((wa_flags & BRW_ATTRIB_WA_SIGN) && 
> >> !use_legacy_snorm_formula) {
> >> +if ((wa_flags & BRW_ATTRIB_WA_SIGN) &&
> >> +!key->use_legacy_snorm_formula) {
> >> /* According to equation 2.2 of the ES 3.0 specification,
> >>  * signed normalization conversion is done by:
> >>  *
> >> @@ -304,14 +305,12 @@ vec4_vs_visitor::vec4_vs_visitor(const struct 
> >> brw_compiler *compiler,
> >>   const nir_shader *shader,
> >>   gl_clip_plane *clip_planes,
> >>   void *mem_ctx,
> >> - int shader_time_index,
> >> - bool use_legacy_snorm_formula)
> >> + int shader_time_index)
> >> : vec4_visitor(compiler, log_data, &key->tex, &vs_prog_data->base, 
> >> shader,
> >>mem_ctx, false /* no_spills */, shader_time_index),
> >>   key(key),
> >>   vs_prog_data(vs_prog_data),
> >> - clip_planes(clip_planes),
> >> - use_legacy_snorm_formula(use_legacy_snorm_formula)
> >> + clip_planes(clip_planes)
> >>  {
> >>  }
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
> >> b/src/mesa/drivers/dri/i965/brw_vs.c
> >> index 38de98f..ecaeefa 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_vs.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
> >> @@ -31,6 +31,7 @@
> >>
> >>
> >>  #include "main/compiler.h"
> >> +#include "main/context.h"
> >>  #include "brw_context.h"
> >>  #include "brw_vs.h"
> >>  #include "brw_util.h"
> >> @@ -329,6 +330,8 @@ brw_vs_populate_key(struct

Re: [Mesa-dev] [PATCH 06/17] nir/info: Add a few bits of info for fragment shaders

2015-10-09 Thread Jason Ekstrand

On Fri, Oct 9, 2015 at 12:15 AM, Pohjolainen, Topi
 wrote:
> On Thu, Oct 08, 2015 at 05:22:38PM -0700, Jason Ekstrand wrote:
>> ---
>>  src/glsl/nir/glsl_to_nir.cpp   |  9 +
>>  src/glsl/nir/nir.h | 13 +
>>  src/mesa/program/prog_to_nir.c |  6 ++
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
>> index e4aa709..ddacb4e 100644
>> --- a/src/glsl/nir/glsl_to_nir.cpp
>> +++ b/src/glsl/nir/glsl_to_nir.cpp
>> @@ -173,6 +173,15 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
>>shader->info.gs.invocations = sh->Geom.Invocations;
>>break;
>>
>> +   case MESA_SHADER_FRAGMENT: {
>> +  struct gl_fragment_program *fp =
>> + (struct gl_fragment_program *)sh->Program;
>> +
>> +  shader->info.fs.uses_discard = fp->UsesKill;
>> +  shader->info.fs.early_fragment_tests = sh->EarlyFragmentTests;
>> +  shader->info.fs.depth_layout = fp->FragDepthLayout;
>
> This series replaces in patch 15 the expression:
>
> fp->Base.OutputsWritten & BITFIELD64_BIT(FRAG_RESULT_DEPTH)
>
> with this, right? If that is the case, it would be nice to say something in
> one of the commits (or perhaps even use a separate patch changing the logic
> itself).

Not quite.  I believe that's replaced with

shader->info.outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH)

It is used in patch 15 but it's used by the updated compute_depth_mode function.

--Jason

>> +   }
>> +
>> case MESA_SHADER_COMPUTE: {
>>struct gl_compute_program *cp = (struct gl_compute_program 
>> *)sh->Program;
>>shader->info.cs.local_size[0] = cp->LocalSize[0];
>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>> index 2ce958a..14f5535 100644
>> --- a/src/glsl/nir/nir.h
>> +++ b/src/glsl/nir/nir.h
>> @@ -1503,6 +1503,19 @@ typedef struct nir_shader_info {
>>} gs;
>>
>>struct {
>> + bool uses_discard;
>> +
>> + /**
>> +  * Whether early fragment tests are enabled as defined by
>> +  * ARB_shader_image_load_store.
>> +  */
>> + bool early_fragment_tests;
>> +
>> + /** gl_FragDepth layout for ARB_conservative_depth. */
>> + enum gl_frag_depth_layout depth_layout;
>> +  } fs;
>> +
>> +  struct {
>>   unsigned local_size[3];
>>} cs;
>> };
>> diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
>> index fc00534..3d91b3b 100644
>> --- a/src/mesa/program/prog_to_nir.c
>> +++ b/src/mesa/program/prog_to_nir.c
>> @@ -1135,6 +1135,12 @@ prog_to_nir(const struct gl_program *prog,
>> s->info.uses_clip_distance_out = false;
>> s->info.separate_shader = false;
>>
>> +   if (stage == MESA_SHADER_FRAGMENT) {
>> +  struct gl_fragment_program *fp = (struct gl_fragment_program *)prog;
>> +
>> +  s->info.fs.uses_discard = fp->UsesKill;
>> +   }
>> +
>>  fail:
>> if (c->error) {
>>ralloc_free(s);
>> --
>> 2.5.0.400.gff86faf
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/17] i965/vs: Move use_legacy_snorm_formula into the shader key

2015-10-09 Thread Jason Ekstrand

On Fri, Oct 9, 2015 at 12:00 AM, Pohjolainen, Topi
 wrote:
> On Thu, Oct 08, 2015 at 05:22:42PM -0700, Jason Ekstrand wrote:
>> This is really an input into the shader compiler so it kind of makes sense
>> in the key.  Also, given where it's placed into the key, it doesn't
>> actually make it any bigger.
>
> But the key specifically controls recompiles, right? Before this didn't
> trigger a recompile but now it does. I'm probably missing something...

You're not missing anything.  It can cause recompiles.  However,
whether or not you're gles3 doesn't change that often. It can change
due to doing meta operations but those shaders are tiny so it's
probably not a big deal.

That said, this is one of the sketchier patches in the series.  I'm
100% ok with leaving it out and just passing use_legacy_snorm_formula
as a parameter.  I was just hoping I could reduce the parameter bloat
a little.

>> ---
>>  src/mesa/drivers/dri/i965/brw_program.h   | 2 ++
>>  src/mesa/drivers/dri/i965/brw_vec4.cpp| 3 +--
>>  src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp | 9 -
>>  src/mesa/drivers/dri/i965/brw_vs.c| 3 +++
>>  src/mesa/drivers/dri/i965/brw_vs.h| 5 +
>>  5 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_program.h 
>> b/src/mesa/drivers/dri/i965/brw_program.h
>> index cf0522a..2a9d1e9 100644
>> --- a/src/mesa/drivers/dri/i965/brw_program.h
>> +++ b/src/mesa/drivers/dri/i965/brw_program.h
>> @@ -91,6 +91,8 @@ struct brw_vs_prog_key {
>>
>> bool clamp_vertex_color:1;
>>
>> +   bool use_legacy_snorm_formula:1;
>> +
>> /**
>>  * How many user clipping planes are being uploaded to the vertex shader 
>> as
>>  * push constants.
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> index 4b8390f..4b03967 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> @@ -1992,8 +1992,7 @@ brw_vs_emit(struct brw_context *brw,
>>
>>vec4_vs_visitor v(brw->intelScreen->compiler, brw, key, prog_data,
>>  vp->Base.nir, brw_select_clip_planes(&brw->ctx),
>> -mem_ctx, shader_time_index,
>> -!_mesa_is_gles3(&brw->ctx));
>> +mem_ctx, shader_time_index);
>>if (!v.run()) {
>>   if (prog) {
>>  prog->LinkStatus = false;
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> index 485a80e..9cf04cd 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_vs_visitor.cpp
>> @@ -77,7 +77,8 @@ vec4_vs_visitor::emit_prolog()
>>  /* ES 3.0 has different rules for converting signed normalized
>>   * fixed-point numbers than desktop GL.
>>   */
>> -if ((wa_flags & BRW_ATTRIB_WA_SIGN) && 
>> !use_legacy_snorm_formula) {
>> +if ((wa_flags & BRW_ATTRIB_WA_SIGN) &&
>> +!key->use_legacy_snorm_formula) {
>> /* According to equation 2.2 of the ES 3.0 specification,
>>  * signed normalization conversion is done by:
>>  *
>> @@ -304,14 +305,12 @@ vec4_vs_visitor::vec4_vs_visitor(const struct 
>> brw_compiler *compiler,
>>   const nir_shader *shader,
>>   gl_clip_plane *clip_planes,
>>   void *mem_ctx,
>> - int shader_time_index,
>> - bool use_legacy_snorm_formula)
>> + int shader_time_index)
>> : vec4_visitor(compiler, log_data, &key->tex, &vs_prog_data->base, 
>> shader,
>>mem_ctx, false /* no_spills */, shader_time_index),
>>   key(key),
>>   vs_prog_data(vs_prog_data),
>> - clip_planes(clip_planes),
>> - use_legacy_snorm_formula(use_legacy_snorm_formula)
>> + clip_planes(clip_planes)
>>  {
>>  }
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
>> b/src/mesa/drivers/dri/i965/brw_vs.c
>> index 38de98f..ecaeefa 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vs.c
>> +++ b/src/mesa/drivers/dri/i965/brw_vs.c
>> @@ -31,6 +31,7 @@
>>
>>
>>  #include "main/compiler.h"
>> +#include "main/context.h"
>>  #include "brw_context.h"
>>  #include "brw_vs.h"
>>  #include "brw_util.h"
>> @@ -329,6 +330,8 @@ brw_vs_populate_key(struct brw_context *brw,
>>key->clamp_vertex_color = ctx->Light._ClampVertexColor;
>> }
>>
>> +   key->use_legacy_snorm_formula = !_mesa_is_gles3(&brw->ctx);
>> +
>> /* _NEW_POINT */
>> if (brw->gen < 6 && ctx->Point.PointSprite) {
>>for (i = 0; i < 8; i++) {
>> diff --git a/src/mesa/drivers/dri/i965/brw_vs.h 
>> b/src/mesa/drivers/dri/i965/brw_vs.h
>> index c927cac..8cf9fa1 100644
>> --- a/src/m

Re: [Mesa-dev] [PATCH 15/17] i965/fs: Move some of the prog_data setup into brw_wm_emit

2015-10-09 Thread Jason Ekstrand

On Fri, Oct 9, 2015 at 12:10 AM, Pohjolainen, Topi
 wrote:
> On Thu, Oct 08, 2015 at 05:22:47PM -0700, Jason Ekstrand wrote:
>> This commit moves the common/modern stuff.  Some legacy stuff such as
>> setting use_alt_mode was left because it needs to know whether or not we're
>> an ARB program.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.cpp | 98 
>> 
>>  src/mesa/drivers/dri/i965/brw_wm.c   | 98 
>> 
>>  2 files changed, 98 insertions(+), 98 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index 146f4b4..0e39b50 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -5114,6 +5114,90 @@ fs_visitor::run_cs()
>> return !failed;
>>  }
>>
>> +/**
>> + * Return a bitfield where bit n is set if barycentric interpolation mode n
>> + * (see enum brw_wm_barycentric_interp_mode) is needed by the fragment 
>> shader.
>> + */
>> +static unsigned
>> +brw_compute_barycentric_interp_modes(const struct brw_device_info *devinfo,
>> + bool shade_model_flat,
>> + bool persample_shading,
>> + const nir_shader *shader)
>> +{
>> +   unsigned barycentric_interp_modes = 0;
>> +
>> +   nir_foreach_variable(var, &shader->inputs) {
>> +  enum glsl_interp_qualifier interp_qualifier =
>> + (enum glsl_interp_qualifier)var->data.interpolation;
>> +  bool is_centroid = var->data.centroid && !persample_shading;
>> +  bool is_sample = var->data.sample || persample_shading;
>> +  bool is_gl_Color = (var->data.location == VARYING_SLOT_COL0) ||
>> + (var->data.location == VARYING_SLOT_COL1);
>> +
>> +  /* Ignore WPOS and FACE, because they don't require interpolation. */
>> +  if (var->data.location == VARYING_SLOT_POS ||
>> +  var->data.location == VARYING_SLOT_FACE)
>> + continue;
>> +
>> +  /* Determine the set (or sets) of barycentric coordinates needed to
>> +   * interpolate this variable.  Note that when
>> +   * brw->needs_unlit_centroid_workaround is set, centroid interpolation
>> +   * uses PIXEL interpolation for unlit pixels and CENTROID 
>> interpolation
>> +   * for lit pixels, so we need both sets of barycentric coordinates.
>> +   */
>> +  if (interp_qualifier == INTERP_QUALIFIER_NOPERSPECTIVE) {
>> + if (is_centroid) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_NONPERSPECTIVE_CENTROID_BARYCENTRIC;
>> + } else if (is_sample) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_NONPERSPECTIVE_SAMPLE_BARYCENTRIC;
>> + }
>> + if ((!is_centroid && !is_sample) ||
>> + devinfo->needs_unlit_centroid_workaround) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC;
>> + }
>> +  } else if (interp_qualifier == INTERP_QUALIFIER_SMOOTH ||
>> + (!(shade_model_flat && is_gl_Color) &&
>> +  interp_qualifier == INTERP_QUALIFIER_NONE)) {
>> + if (is_centroid) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_PERSPECTIVE_CENTROID_BARYCENTRIC;
>> + } else if (is_sample) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_PERSPECTIVE_SAMPLE_BARYCENTRIC;
>> + }
>> + if ((!is_centroid && !is_sample) ||
>> + devinfo->needs_unlit_centroid_workaround) {
>> +barycentric_interp_modes |=
>> +   1 << BRW_WM_PERSPECTIVE_PIXEL_BARYCENTRIC;
>> + }
>> +  }
>> +   }
>> +
>> +   return barycentric_interp_modes;
>> +}
>> +
>> +static uint8_t
>> +computed_depth_mode(const nir_shader *shader)
>> +{
>> +   if (shader->info.outputs_written & BITFIELD64_BIT(FRAG_RESULT_DEPTH)) {
>> +  switch (shader->info.fs.depth_layout) {
>> +  case FRAG_DEPTH_LAYOUT_NONE:
>> +  case FRAG_DEPTH_LAYOUT_ANY:
>> + return BRW_PSCDEPTH_ON;
>> +  case FRAG_DEPTH_LAYOUT_GREATER:
>> + return BRW_PSCDEPTH_ON_GE;
>> +  case FRAG_DEPTH_LAYOUT_LESS:
>> + return BRW_PSCDEPTH_ON_LE;
>> +  case FRAG_DEPTH_LAYOUT_UNCHANGED:
>> + return BRW_PSCDEPTH_OFF;
>> +  }
>> +   }
>> +   return BRW_PSCDEPTH_OFF;
>> +}
>> +
>>  const unsigned *
>>  brw_wm_fs_emit(const struct brw_compiler *compiler, void *log_data,
>> void *mem_ctx,
>> @@ -5126,6 +5210,20 @@ brw_wm_fs_emit(const struct brw_compiler *compiler, 
>> void *log_data,
>> unsigned *final_assembly_size,
>> char **error_str)
>>  {
>> +   /* key->alpha_test_func means simulating alpha testing via discards,
>> +* so the shader definitely kills pixels.
>> +*/
>> +   prog_data->uses_kill = shader->info.fs.uses_discard ||

Re: [Mesa-dev] [PATCH v5] i965/fs: Handle non-const sample number in interpolateAtSample

2015-10-09 Thread Francisco Jerez

Neil Roberts  writes:

> If a non-const sample number is given to interpolateAtSample it will
> now generate an indirect send message with the sample ID similar to
> how non-const sampler array indexing works. Previously non-const
> values were ignored and instead it ended up using a constant 0 value.
>
> The generator will try to determine if the sample ID is dynamically
> uniform via nir_src_is_dynamically_uniform. If not it will query the
> pixel interpolator in a loop, once for each different live sample
> number. The next live sample number is found using emit_uniformize. If
> multiple live channels have the same sample number then they will be
> handled in a single iteration of the loop. The loop is necessary
> because the indirect send message doesn't seem to have a way to
> specify a different value for each fragment.
>
> This fixes the following two Piglit tests:
>
> arb_gpu_shader5-interpolateAtSample-nonconst
> arb_gpu_shader5-interpolateAtSample-dynamically-nonuniform
>
> v2: Handle dynamically non-uniform sample ids.
> v3: Remove the BREAK instruction and predicate the WHILE directly.
> Make the tokens arrays const. (Matt Turner)
> v4: Iterate over the live channels instead of each possible sample
> number.
> v5: Don't special case immediate values in
> brw_pixel_interpolator_query. Make a better wrapper for the
> function to set up the PI send instruction. Ensure that the SHL
> instructions are scalar. (Francisco Jerez).
> ---
>
> Many thanks to Francisco and Matt for the all the helpful feedback.
>

Thank you, looks pretty good to me:

Reviewed-by: Francisco Jerez 

>  src/mesa/drivers/dri/i965/brw_eu.h |   2 +-
>  src/mesa/drivers/dri/i965/brw_eu_emit.c|  27 ++---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp |   5 +-
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 139 
> -
>  4 files changed, 130 insertions(+), 43 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
> b/src/mesa/drivers/dri/i965/brw_eu.h
> index 761aa0e..0ac1ad9 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu.h
> +++ b/src/mesa/drivers/dri/i965/brw_eu.h
> @@ -461,7 +461,7 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
>   struct brw_reg mrf,
>   bool noperspective,
>   unsigned mode,
> - unsigned data,
> + struct brw_reg data,
>   unsigned msg_length,
>   unsigned response_length);
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> index dc699bb..bf2fee9 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> @@ -3212,26 +3212,29 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
>   struct brw_reg mrf,
>   bool noperspective,
>   unsigned mode,
> - unsigned data,
> + struct brw_reg data,
>   unsigned msg_length,
>   unsigned response_length)
>  {
> const struct brw_device_info *devinfo = p->devinfo;
> -   struct brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
> -
> -   brw_set_dest(p, insn, dest);
> -   brw_set_src0(p, insn, mrf);
> -   brw_set_message_descriptor(p, insn, GEN7_SFID_PIXEL_INTERPOLATOR,
> -  msg_length, response_length,
> -  false /* header is never present for PI */,
> -  false);
> +   struct brw_inst *insn;
> +   const uint16_t exec_size = brw_inst_exec_size(devinfo, p->current);
>  
> -   brw_inst_set_pi_simd_mode(
> - devinfo, insn, brw_inst_exec_size(devinfo, insn) == BRW_EXECUTE_16);
> +   /* brw_send_indirect_message will automatically use a direct send message
> +* if data is actually immediate.
> +*/
> +   insn = brw_send_indirect_message(p,
> +GEN7_SFID_PIXEL_INTERPOLATOR,
> +dest,
> +mrf,
> +vec1(data));
> +   brw_inst_set_mlen(devinfo, insn, msg_length);
> +   brw_inst_set_rlen(devinfo, insn, response_length);
> +
> +   brw_inst_set_pi_simd_mode(devinfo, insn, exec_size == BRW_EXECUTE_16);
> brw_inst_set_pi_slot_group(devinfo, insn, 0); /* zero unless 32/64px 
> dispatch */
> brw_inst_set_pi_nopersp(devinfo, insn, noperspective);
> brw_inst_set_pi_message_type(devinfo, insn, mode);
> -   brw_inst_set_pi_message_data(devinfo, insn, data);
>  }
>  
>  void
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 6f8b75e..17e19cf 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b

[Mesa-dev] [Bug 92020] wglCreatePbufferARB handle attrib error

2015-10-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=92020

zeif <332447...@qq.com> changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/7] nir: add an instruction set API

2015-10-09 Thread Jason Ekstrand

Reviewed-by: Jason Ekstrand 

On Thu, Oct 8, 2015 at 9:46 PM, Connor Abbott  wrote:
> This will replace direct usage of nir_instrs_equal() in the CSE pass,
> which reduces an O(n^2) algorithm with an effectively O(n) one. It'll
> also be useful for implementing GVN on top of GCM.
>
> v2:
> - Add texture support.
> - Add more comments.
> - Rename instr_can_hash() to instr_can_rewrite() since it's really more
> about whether its uses can be rewritten, and it's implicitly used by
> nir_instrs_equal() as well.
> - Rename nir_instr_set_add() to nir_instr_set_add_or_rewrite() (Jason).
> - Make the HASH() macro less magical (Topi).
> - Rewrite the commit message.
>
> v3:
> - For sorting phi sources, use a VLA, store pointers to the sources, and
> compare the predecessor pointer directly (Jason).
>
> Signed-off-by: Connor Abbott 
> ---
> Jason, does this look good to you? Still no piglit regressions -- I'm
> working on getting perf numbers.
>
>  src/glsl/nir/nir_instr_set.c | 314 
> +++
>  src/glsl/nir/nir_instr_set.h |  35 +
>  2 files changed, 349 insertions(+)
>
> diff --git a/src/glsl/nir/nir_instr_set.c b/src/glsl/nir/nir_instr_set.c
> index 72ab048..7460fcc 100644
> --- a/src/glsl/nir/nir_instr_set.c
> +++ b/src/glsl/nir/nir_instr_set.c
> @@ -22,6 +22,181 @@
>   */
>
>  #include "nir_instr_set.h"
> +#include "nir_vla.h"
> +
> +#define HASH(hash, data) _mesa_fnv32_1a_accumulate((hash), (data))
> +
> +static uint32_t
> +hash_src(uint32_t hash, const nir_src *src)
> +{
> +   assert(src->is_ssa);
> +   hash = HASH(hash, src->ssa);
> +   return hash;
> +}
> +
> +static uint32_t
> +hash_alu_src(uint32_t hash, const nir_alu_src *src, unsigned num_components)
> +{
> +   hash = HASH(hash, src->abs);
> +   hash = HASH(hash, src->negate);
> +
> +   for (unsigned i = 0; i < num_components; i++)
> +  hash = HASH(hash, src->swizzle[i]);
> +
> +   hash = hash_src(hash, &src->src);
> +   return hash;
> +}
> +
> +static uint32_t
> +hash_alu(uint32_t hash, const nir_alu_instr *instr)
> +{
> +   hash = HASH(hash, instr->op);
> +   hash = HASH(hash, instr->dest.dest.ssa.num_components);
> +
> +   if (nir_op_infos[instr->op].algebraic_properties & NIR_OP_IS_COMMUTATIVE) 
> {
> +  assert(nir_op_infos[instr->op].num_inputs == 2);
> +  uint32_t hash0 = hash_alu_src(hash, &instr->src[0],
> +nir_ssa_alu_instr_src_components(instr, 
> 0));
> +  uint32_t hash1 = hash_alu_src(hash, &instr->src[1],
> +nir_ssa_alu_instr_src_components(instr, 
> 1));
> +  /* For commutative operations, we need some commutative way of
> +   * combining the hashes.  One option would be to XOR them but that
> +   * means that anything with two identical sources will hash to 0 and
> +   * that's common enough we probably don't want the guaranteed
> +   * collision.  Either addition or multiplication will also work.
> +   */
> +  hash = hash0 * hash1;
> +   } else {
> +  for (unsigned i = 0; i < nir_op_infos[instr->op].num_inputs; i++) {
> + hash = hash_alu_src(hash, &instr->src[i],
> + nir_ssa_alu_instr_src_components(instr, i));
> +  }
> +   }
> +
> +   return hash;
> +}
> +
> +static uint32_t
> +hash_load_const(uint32_t hash, const nir_load_const_instr *instr)
> +{
> +   hash = HASH(hash, instr->def.num_components);
> +
> +   hash = _mesa_fnv32_1a_accumulate_block(hash, instr->value.f,
> +  instr->def.num_components
> + * sizeof(instr->value.f[0]));
> +
> +   return hash;
> +}
> +
> +static int
> +cmp_phi_src(const void *data1, const void *data2)
> +{
> +   nir_phi_src *src1 = *(nir_phi_src **)data1;
> +   nir_phi_src *src2 = *(nir_phi_src **)data2;
> +   return src1->pred - src2->pred;
> +}
> +
> +static uint32_t
> +hash_phi(uint32_t hash, const nir_phi_instr *instr)
> +{
> +   hash = HASH(hash, instr->instr.block);
> +
> +   /* sort sources by predecessor, since the order shouldn't matter */
> +   unsigned num_preds = instr->instr.block->predecessors->entries;
> +   NIR_VLA(nir_phi_src *, srcs, num_preds);
> +   unsigned i = 0;
> +   nir_foreach_phi_src(instr, src) {
> +  srcs[i++] = src;
> +   }
> +
> +   qsort(srcs, num_preds, sizeof(nir_phi_src *), cmp_phi_src);
> +
> +   for (i = 0; i < num_preds; i++) {
> +  hash = hash_src(hash, &srcs[i]->src);
> +  hash = HASH(hash, srcs[i]->pred);
> +   }
> +
> +   return hash;
> +}
> +
> +static uint32_t
> +hash_intrinsic(uint32_t hash, const nir_intrinsic_instr *instr)
> +{
> +   const nir_intrinsic_info *info = &nir_intrinsic_infos[instr->intrinsic];
> +   hash = HASH(hash, instr->intrinsic);
> +
> +   if (info->has_dest)
> +  hash = HASH(hash, instr->dest.ssa.num_components);
> +
> +   assert(info->num_variables == 0);
> +
> +   hash = _mesa_fnv32_1a_accumulate_block(hash, instr->const_index,
> +

[Mesa-dev] [PATCH v5] i965/fs: Handle non-const sample number in interpolateAtSample

2015-10-09 Thread Neil Roberts

If a non-const sample number is given to interpolateAtSample it will
now generate an indirect send message with the sample ID similar to
how non-const sampler array indexing works. Previously non-const
values were ignored and instead it ended up using a constant 0 value.

The generator will try to determine if the sample ID is dynamically
uniform via nir_src_is_dynamically_uniform. If not it will query the
pixel interpolator in a loop, once for each different live sample
number. The next live sample number is found using emit_uniformize. If
multiple live channels have the same sample number then they will be
handled in a single iteration of the loop. The loop is necessary
because the indirect send message doesn't seem to have a way to
specify a different value for each fragment.

This fixes the following two Piglit tests:

arb_gpu_shader5-interpolateAtSample-nonconst
arb_gpu_shader5-interpolateAtSample-dynamically-nonuniform

v2: Handle dynamically non-uniform sample ids.
v3: Remove the BREAK instruction and predicate the WHILE directly.
Make the tokens arrays const. (Matt Turner)
v4: Iterate over the live channels instead of each possible sample
number.
v5: Don't special case immediate values in
brw_pixel_interpolator_query. Make a better wrapper for the
function to set up the PI send instruction. Ensure that the SHL
instructions are scalar. (Francisco Jerez).
---

Many thanks to Francisco and Matt for the all the helpful feedback.

 src/mesa/drivers/dri/i965/brw_eu.h |   2 +-
 src/mesa/drivers/dri/i965/brw_eu_emit.c|  27 ++---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp |   5 +-
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp   | 139 -
 4 files changed, 130 insertions(+), 43 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 761aa0e..0ac1ad9 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -461,7 +461,7 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
  struct brw_reg mrf,
  bool noperspective,
  unsigned mode,
- unsigned data,
+ struct brw_reg data,
  unsigned msg_length,
  unsigned response_length);
 
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index dc699bb..bf2fee9 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -3212,26 +3212,29 @@ brw_pixel_interpolator_query(struct brw_codegen *p,
  struct brw_reg mrf,
  bool noperspective,
  unsigned mode,
- unsigned data,
+ struct brw_reg data,
  unsigned msg_length,
  unsigned response_length)
 {
const struct brw_device_info *devinfo = p->devinfo;
-   struct brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
-
-   brw_set_dest(p, insn, dest);
-   brw_set_src0(p, insn, mrf);
-   brw_set_message_descriptor(p, insn, GEN7_SFID_PIXEL_INTERPOLATOR,
-  msg_length, response_length,
-  false /* header is never present for PI */,
-  false);
+   struct brw_inst *insn;
+   const uint16_t exec_size = brw_inst_exec_size(devinfo, p->current);
 
-   brw_inst_set_pi_simd_mode(
- devinfo, insn, brw_inst_exec_size(devinfo, insn) == BRW_EXECUTE_16);
+   /* brw_send_indirect_message will automatically use a direct send message
+* if data is actually immediate.
+*/
+   insn = brw_send_indirect_message(p,
+GEN7_SFID_PIXEL_INTERPOLATOR,
+dest,
+mrf,
+vec1(data));
+   brw_inst_set_mlen(devinfo, insn, msg_length);
+   brw_inst_set_rlen(devinfo, insn, response_length);
+
+   brw_inst_set_pi_simd_mode(devinfo, insn, exec_size == BRW_EXECUTE_16);
brw_inst_set_pi_slot_group(devinfo, insn, 0); /* zero unless 32/64px 
dispatch */
brw_inst_set_pi_nopersp(devinfo, insn, noperspective);
brw_inst_set_pi_message_type(devinfo, insn, mode);
-   brw_inst_set_pi_message_data(devinfo, insn, data);
 }
 
 void
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 6f8b75e..17e19cf 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1377,15 +1377,14 @@ fs_generator::generate_pixel_interpolator_query(fs_inst 
*inst,
 struct brw_reg msg_data,
 unsigned msg_type)
 {
-   assert(msg_da

Re: [Mesa-dev] [PATCH V7 03/24] glsl: allow AoA to be sized by initializer or constructor

2015-10-09 Thread Samuel Iglesias Gonsálvez



On 09/10/15 13:25, Timothy Arceri wrote:
> On Thu, 2015-10-08 at 11:08 +0200, Samuel Iglesias Gonsálvez wrote:
>> On 07/10/15 00:47, Timothy Arceri wrote:
>>> From Section 4.1.9 of the GLSL ES 3.10 spec:
>>>
>>>  "Arrays are sized either at compile-time or at run-time.
>>>   To size an array at compile-time, either the size
>>>   must be specified within the brackets as above or
>>>   must be inferred from the type of the initializer."
>>> ---
>>>  src/glsl/ast.h   | 15 ++---
>>>  src/glsl/ast_array_index.cpp |  7 ++--
>>>  src/glsl/ast_function.cpp| 33 +-
>>>  src/glsl/ast_to_hir.cpp  | 79
>>> ++--
>>>  src/glsl/glsl_parser.yy  | 11 +++---
>>>  5 files changed, 104 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/src/glsl/ast.h b/src/glsl/ast.h
>>> index 4c31436..b43be24 100644
>>> --- a/src/glsl/ast.h
>>> +++ b/src/glsl/ast.h
>>> @@ -181,6 +181,7 @@ enum ast_operators {
>>> ast_post_dec,
>>> ast_field_selection,
>>> ast_array_index,
>>> +   ast_unsized_array_dim,
>>>  
>>> ast_function_call,
>>>  
>>> @@ -318,16 +319,7 @@ public:
>>>  
>>>  class ast_array_specifier : public ast_node {
>>>  public:
>>> -   /** Unsized array specifier ([]) */
>>> -   explicit ast_array_specifier(const struct YYLTYPE &locp)
>>> - : is_unsized_array(true)
>>> -   {
>>> -  set_location(locp);
>>> -   }
>>> -
>>> -   /** Sized array specifier ([dim]) */
>>> ast_array_specifier(const struct YYLTYPE &locp, ast_expression
>>> *dim)
>>> - : is_unsized_array(false)
>>> {
>>>set_location(locp);
>>>array_dimensions.push_tail(&dim->link);
>>> @@ -340,11 +332,8 @@ public:
>>>  
>>> virtual void print(void) const;
>>>  
>>> -   /* If true, this means that the array has an unsized outermost
>>> dimension. */
>>> -   bool is_unsized_array;
>>> -
>>> /* This list contains objects of type ast_node containing the
>>> -* sized dimensions only, in outermost-to-innermost order.
>>> +* array dimensions in outermost-to-innermost order.
>>>  */
>>> exec_list array_dimensions;
>>>  };
>>> diff --git a/src/glsl/ast_array_index.cpp
>>> b/src/glsl/ast_array_index.cpp
>>> index 5e8f49d..7855e0a 100644
>>> --- a/src/glsl/ast_array_index.cpp
>>> +++ b/src/glsl/ast_array_index.cpp
>>> @@ -28,13 +28,10 @@
>>>  void
>>>  ast_array_specifier::print(void) const
>>>  {
>>> -   if (this->is_unsized_array) {
>>> -  printf("[ ] ");
>>> -   }
>>> -
>>> foreach_list_typed (ast_node, array_dimension, link, &this
>>> ->array_dimensions) {
>>>printf("[ ");
>>> -  array_dimension->print();
>>> +  if (((ast_expression*)array_dimension)->oper !=
>>> ast_unsized_array_dim)
>>> + array_dimension->print();
>>>printf("] ");
>>> }
>>>  }
>>> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
>>> index 26d4c62..cf4e64a 100644
>>> --- a/src/glsl/ast_function.cpp
>>> +++ b/src/glsl/ast_function.cpp
>>> @@ -950,6 +950,7 @@ process_array_constructor(exec_list
>>> *instructions,
>>> }
>>>  
>>> bool all_parameters_are_constant = true;
>>> +   const glsl_type *element_type = constructor_type->fields.array;
>>>  
>>> /* Type cast each parameter and, if possible, fold constants.
>>> */
>>> foreach_in_list_safe(ir_rvalue, ir, &actual_parameters) {
>>> @@ -976,12 +977,34 @@ process_array_constructor(exec_list
>>> *instructions,
>>>  }
>>>}
>>>  
>>> -  if (result->type != constructor_type->fields.array) {
>>> +  if (constructor_type->fields.array->is_unsized_array()) {
>>> + /* As the inner parameters of the constructor are created
>>> without
>>> +  * knowledge of each other we need to check to make sure
>>> unsized
>>> +  * parameters of unsized constructors all end up with the
>>> same size.
>>> +  *
>>> +  * e.g we make sure to fail for a constructor like this:
>>> +  * vec4[][] a = vec4[][](vec4[](vec4(0.0), vec4(1.0)),
>>> +  *   vec4[](vec4(0.0), vec4(1.0),
>>> vec4(1.0)),
>>> +  *   vec4[](vec4(0.0), vec4(1.0)));
>>> +  */
>>> + if (element_type->is_unsized_array()) {
>>> + /* This is the first parameter so just get the type
>>> */
>>> +element_type = result->type;
>>> + } else if (element_type != result->type) {
>>> +_mesa_glsl_error(loc, state, "type error in array
>>> constructor: "
>>> + "expected: %s, found %s",
>>> + element_type->name,
>>> + result->type->name);
>>> +return ir_rvalue::error_value(ctx);
>>> + }
>>> +  } else if (result->type != constructor_type->fields.array) {
>>>  _mesa_glsl_error(loc, state, "type error in array
>>> constructor: "
>>>   "expected: %s, found %s",
>>>   constructor_type->

Re: [Mesa-dev] [PATCH 07/12] i965: Use util_next_power_of_two() for brw_get_scratch_size()

2015-10-09 Thread Francisco Jerez

Kristian Høgsberg Kristensen  writes:

> This function computes the next power of two, but at least 1024. We can
> do that by bitwise or'ing in 1023 and calling util_next_power_of_two().
>
> We use brw_get_scratch_size() from the compiler so we need it out of
> brw_program.c. We could move it to brw_shader.cpp, but let's make it a
> small inline function instead.
>
> Signed-off-by: Kristian Høgsberg Kristensen 
> ---
>  src/mesa/drivers/dri/i965/brw_context.h |  7 ++-
>  src/mesa/drivers/dri/i965/brw_program.c | 12 
>  2 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 1869f28..aa1284d 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -1723,7 +1723,12 @@ void brw_validate_textures( struct brw_context *brw );
>   */
>  void brwInitFragProgFuncs( struct dd_function_table *functions );
>  
> -int brw_get_scratch_size(int size);
> +/* Per-thread scratch space is a power-of-two multiple of 1KB. */
> +static inline int
> +brw_get_scratch_size(int size)
> +{
> +   return util_next_power_of_two(size | 1023);
> +}

This will incorrectly overallocate scratch space if size is already a
power of two greater than 1024.  I suggest you do "MAX2(1024,
util_next_power_of_two(size))" instead which is also trivial enough that
you might want to open-code it in its only use rather than defining a
one-line function for it.

>  void brw_get_scratch_bo(struct brw_context *brw,
>   drm_intel_bo **scratch_bo, int size);
>  void brw_init_shader_time(struct brw_context *brw);
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 108eb34..69ecc36 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -242,18 +242,6 @@ brw_add_texrect_params(struct gl_program *prog)
> }
>  }
>  
> -/* Per-thread scratch space is a power-of-two multiple of 1KB. */
> -int
> -brw_get_scratch_size(int size)
> -{
> -   int i;
> -
> -   for (i = 1024; i < size; i *= 2)
> -  ;
> -
> -   return i;
> -}
> -
>  void
>  brw_get_scratch_bo(struct brw_context *brw,
>  drm_intel_bo **scratch_bo, int size)
> -- 
> 2.4.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH V7 03/24] glsl: allow AoA to be sized by initializer or constructor

2015-10-09 Thread Timothy Arceri

On Thu, 2015-10-08 at 11:08 +0200, Samuel Iglesias Gonsálvez wrote:
> On 07/10/15 00:47, Timothy Arceri wrote:
> > From Section 4.1.9 of the GLSL ES 3.10 spec:
> > 
> >  "Arrays are sized either at compile-time or at run-time.
> >   To size an array at compile-time, either the size
> >   must be specified within the brackets as above or
> >   must be inferred from the type of the initializer."
> > ---
> >  src/glsl/ast.h   | 15 ++---
> >  src/glsl/ast_array_index.cpp |  7 ++--
> >  src/glsl/ast_function.cpp| 33 +-
> >  src/glsl/ast_to_hir.cpp  | 79
> > ++--
> >  src/glsl/glsl_parser.yy  | 11 +++---
> >  5 files changed, 104 insertions(+), 41 deletions(-)
> > 
> > diff --git a/src/glsl/ast.h b/src/glsl/ast.h
> > index 4c31436..b43be24 100644
> > --- a/src/glsl/ast.h
> > +++ b/src/glsl/ast.h
> > @@ -181,6 +181,7 @@ enum ast_operators {
> > ast_post_dec,
> > ast_field_selection,
> > ast_array_index,
> > +   ast_unsized_array_dim,
> >  
> > ast_function_call,
> >  
> > @@ -318,16 +319,7 @@ public:
> >  
> >  class ast_array_specifier : public ast_node {
> >  public:
> > -   /** Unsized array specifier ([]) */
> > -   explicit ast_array_specifier(const struct YYLTYPE &locp)
> > - : is_unsized_array(true)
> > -   {
> > -  set_location(locp);
> > -   }
> > -
> > -   /** Sized array specifier ([dim]) */
> > ast_array_specifier(const struct YYLTYPE &locp, ast_expression
> > *dim)
> > - : is_unsized_array(false)
> > {
> >set_location(locp);
> >array_dimensions.push_tail(&dim->link);
> > @@ -340,11 +332,8 @@ public:
> >  
> > virtual void print(void) const;
> >  
> > -   /* If true, this means that the array has an unsized outermost
> > dimension. */
> > -   bool is_unsized_array;
> > -
> > /* This list contains objects of type ast_node containing the
> > -* sized dimensions only, in outermost-to-innermost order.
> > +* array dimensions in outermost-to-innermost order.
> >  */
> > exec_list array_dimensions;
> >  };
> > diff --git a/src/glsl/ast_array_index.cpp
> > b/src/glsl/ast_array_index.cpp
> > index 5e8f49d..7855e0a 100644
> > --- a/src/glsl/ast_array_index.cpp
> > +++ b/src/glsl/ast_array_index.cpp
> > @@ -28,13 +28,10 @@
> >  void
> >  ast_array_specifier::print(void) const
> >  {
> > -   if (this->is_unsized_array) {
> > -  printf("[ ] ");
> > -   }
> > -
> > foreach_list_typed (ast_node, array_dimension, link, &this
> > ->array_dimensions) {
> >printf("[ ");
> > -  array_dimension->print();
> > +  if (((ast_expression*)array_dimension)->oper !=
> > ast_unsized_array_dim)
> > + array_dimension->print();
> >printf("] ");
> > }
> >  }
> > diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> > index 26d4c62..cf4e64a 100644
> > --- a/src/glsl/ast_function.cpp
> > +++ b/src/glsl/ast_function.cpp
> > @@ -950,6 +950,7 @@ process_array_constructor(exec_list
> > *instructions,
> > }
> >  
> > bool all_parameters_are_constant = true;
> > +   const glsl_type *element_type = constructor_type->fields.array;
> >  
> > /* Type cast each parameter and, if possible, fold constants.
> > */
> > foreach_in_list_safe(ir_rvalue, ir, &actual_parameters) {
> > @@ -976,12 +977,34 @@ process_array_constructor(exec_list
> > *instructions,
> >  }
> >}
> >  
> > -  if (result->type != constructor_type->fields.array) {
> > +  if (constructor_type->fields.array->is_unsized_array()) {
> > + /* As the inner parameters of the constructor are created
> > without
> > +  * knowledge of each other we need to check to make sure
> > unsized
> > +  * parameters of unsized constructors all end up with the
> > same size.
> > +  *
> > +  * e.g we make sure to fail for a constructor like this:
> > +  * vec4[][] a = vec4[][](vec4[](vec4(0.0), vec4(1.0)),
> > +  *   vec4[](vec4(0.0), vec4(1.0),
> > vec4(1.0)),
> > +  *   vec4[](vec4(0.0), vec4(1.0)));
> > +  */
> > + if (element_type->is_unsized_array()) {
> > + /* This is the first parameter so just get the type
> > */
> > +element_type = result->type;
> > + } else if (element_type != result->type) {
> > +_mesa_glsl_error(loc, state, "type error in array
> > constructor: "
> > + "expected: %s, found %s",
> > + element_type->name,
> > + result->type->name);
> > +return ir_rvalue::error_value(ctx);
> > + }
> > +  } else if (result->type != constructor_type->fields.array) {
> >  _mesa_glsl_error(loc, state, "type error in array
> > constructor: "
> >   "expected: %s, found %s",
> >   constructor_type->fields.array->name,
> >

Re: [Mesa-dev] [PATCH v2 2/5] i965/fs: move the fs_reg::smear() from get_timestamp() to the callers

2015-10-09 Thread Emil Velikov

On 9 October 2015 at 11:17, Emil Velikov  wrote:
> We're about to reuse get_timestamp() for the nir_intrinsic_shader_clock.
> The in the latter the generalisation does not apply, so move the smear()
> where needed. This also makes the function analogous to the vec4 one.
>
> Signed-off-by: Emil Velikov 
Should be [PATCH 4.5/6] ...

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

[Mesa-dev] [PATCH v2 2/5] i965/fs: move the fs_reg::smear() from get_timestamp() to the callers

2015-10-09 Thread Emil Velikov

We're about to reuse get_timestamp() for the nir_intrinsic_shader_clock.
The in the latter the generalisation does not apply, so move the smear()
where needed. This also makes the function analogous to the vec4 one.

Signed-off-by: Emil Velikov 
---

Whist we can safely nuke the comments now, I've decided to keep them for 
now. Let me know if you feel strongly either way.

-Emil 

 src/mesa/drivers/dri/i965/brw_fs.cpp | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 781e2d8..5958dd6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -521,6 +521,14 @@ fs_visitor::get_timestamp(const fs_builder &bld)
 */
bld.group(4, 0).exec_all().MOV(dst, ts);
 
+   return dst;
+}
+
+void
+fs_visitor::emit_shader_time_begin()
+{
+   shader_start_time = get_timestamp(bld.annotate("shader time start"));
+
/* The caller wants the low 32 bits of the timestamp.  Since it's running
 * at the GPU clock rate of ~1.2ghz, it will roll over every ~3 seconds,
 * which is plenty of time for our purposes.  It is identical across the
@@ -531,15 +539,7 @@ fs_visitor::get_timestamp(const fs_builder &bld)
 * else that might disrupt timing) by setting smear to 2 and checking if
 * that field is != 0.
 */
-   dst.set_smear(0);
-
-   return dst;
-}
-
-void
-fs_visitor::emit_shader_time_begin()
-{
-   shader_start_time = get_timestamp(bld.annotate("shader time start"));
+   shader_start_time.set_smear(0);
 }
 
 void
@@ -553,6 +553,18 @@ fs_visitor::emit_shader_time_end()
 
fs_reg shader_end_time = get_timestamp(ibld);
 
+   /* The caller wants the low 32 bits of the timestamp.  Since it's running
+* at the GPU clock rate of ~1.2ghz, it will roll over every ~3 seconds,
+* which is plenty of time for our purposes.  It is identical across the
+* EUs, but since it's tracking GPU core speed it will increment at a
+* varying rate as render P-states change.
+*
+* The caller could also check if render P-states have changed (or anything
+* else that might disrupt timing) by setting smear to 2 and checking if
+* that field is != 0.
+*/
+   shader_end_time.set_smear(0);
+
/* Check that there weren't any timestamp reset events (assuming these
 * were the only two timestamp reads that happened).
 */
-- 
2.5.0

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

[Mesa-dev] [PATCH v2 4/6] nir: add shader_clock intrinsic

2015-10-09 Thread Emil Velikov

v2: Add flags and inline comment/description.
Signed-off-by: Emil Velikov 
---
 src/glsl/nir/glsl_to_nir.cpp  | 6 ++
 src/glsl/nir/nir_intrinsics.h | 8 
 2 files changed, 14 insertions(+)

diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
index efaa73e..231bdbf 100644
--- a/src/glsl/nir/glsl_to_nir.cpp
+++ b/src/glsl/nir/glsl_to_nir.cpp
@@ -698,6 +698,8 @@ nir_visitor::visit(ir_call *ir)
  op = nir_intrinsic_ssbo_atomic_exchange;
   } else if (strcmp(ir->callee_name(), 
"__intrinsic_ssbo_atomic_comp_swap_internal") == 0) {
  op = nir_intrinsic_ssbo_atomic_comp_swap;
+  } else if (strcmp(ir->callee_name(), "__intrinsic_shader_clock") == 0) {
+ op = nir_intrinsic_shader_clock;
   } else {
  unreachable("not reached");
   }
@@ -802,6 +804,10 @@ nir_visitor::visit(ir_call *ir)
   case nir_intrinsic_memory_barrier:
  nir_instr_insert_after_cf_list(this->cf_node_list, &instr->instr);
  break;
+  case nir_intrinsic_shader_clock:
+ nir_ssa_dest_init(&instr->instr, &instr->dest, 1, NULL);
+ nir_instr_insert_after_cf_list(this->cf_node_list, &instr->instr);
+ break;
   case nir_intrinsic_store_ssbo: {
  exec_node *param = ir->actual_parameters.get_head();
  ir_rvalue *block = ((ir_instruction *)param)->as_rvalue();
diff --git a/src/glsl/nir/nir_intrinsics.h b/src/glsl/nir/nir_intrinsics.h
index 263d8c1..8141a0f 100644
--- a/src/glsl/nir/nir_intrinsics.h
+++ b/src/glsl/nir/nir_intrinsics.h
@@ -83,6 +83,14 @@ BARRIER(discard)
  */
 BARRIER(memory_barrier)
 
+/*
+ * Shader clock intrinsic with semantics analogous to the clock2x32ARB()
+ * clockARB() GLSL intrinsic.
+ * The latter can be used as code motion barrier, which is currently not
+ * feasible with NIR.
+ */
+INTRINSIC(shader_clock, 0, ARR(), true, 1, 1, 0, NIR_INTRINSIC_CAN_ELIMINATE)
+
 /** A conditional discard, with a single boolean source. */
 INTRINSIC(discard_if, 1, ARR(1), false, 0, 0, 0, 0)
 
-- 
2.5.0

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

Re: [Mesa-dev] [PATCH 05/13] nir: Add a a nir_shader_info struct

2015-10-09 Thread Iago Toral

Hi Jason, 

On Thu, 2015-10-01 at 18:50 -0700, Jason Ekstrand wrote:
> This commit also adds code to glsl_to_nir and prog_to_nir to fill it out.
> ---
>  src/glsl/nir/glsl_to_nir.cpp   | 18 ++
>  src/glsl/nir/nir.c |  1 +
>  src/glsl/nir/nir.h | 34 ++
>  src/mesa/program/prog_to_nir.c | 13 +
>  4 files changed, 66 insertions(+)
> 
> diff --git a/src/glsl/nir/glsl_to_nir.cpp b/src/glsl/nir/glsl_to_nir.cpp
> index ba08e17..6820962 100644
> --- a/src/glsl/nir/glsl_to_nir.cpp
> +++ b/src/glsl/nir/glsl_to_nir.cpp
> @@ -144,8 +144,26 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
>  
> nir_lower_outputs_to_temporaries(shader);
>  
> +   /* TODO: Use _mesa_fls instead */
> +   unsigned num_textures = 0;
> +   for (unsigned i = 0; i < 8 * sizeof(sh->Program->SamplersUsed); i++)
> +  if (sh->Program->SamplersUsed & (1 << i))
> + num_textures = i;
> +
> shader->gs.vertices_out = sh->Geom.VerticesOut;
> shader->gs.invocations = sh->Geom.Invocations;
> +   shader->info.name = ralloc_asprintf(shader, "GLSL%d", sh->Name);
> +   shader->info.num_textures = num_textures;
> +   shader->info.num_ubos = sh->NumUniformBlocks;
> +   shader->info.num_abos = shader_prog->NumAtomicBuffers;
> +   shader->info.num_ssbos = shader_prog->NumBufferInterfaceBlocks;
> +   shader->info.num_images = sh->NumImages;
> +   shader->info.inputs_read = sh->Program->InputsRead;
> +   shader->info.outputs_written = sh->Program->OutputsWritten;
> +   shader->info.system_values_read = sh->Program->SystemValuesRead;
> +   shader->info.uses_texture_gather = sh->Program->UsesGather;
> +   shader->info.uses_clip_distance_out = sh->Program->UsesClipDistanceOut;
> +   shader->info.separate_shader = shader_prog->SeparateShader;
>  
> return shader;
>  }
> diff --git a/src/glsl/nir/nir.c b/src/glsl/nir/nir.c
> index fe10b38..7a469a6 100644
> --- a/src/glsl/nir/nir.c
> +++ b/src/glsl/nir/nir.c
> @@ -41,6 +41,7 @@ nir_shader_create(void *mem_ctx,
> exec_list_make_empty(&shader->outputs);
>  
> shader->options = options;
> +   memset(&shader->info, 0, sizeof(shader->info));
>  
> exec_list_make_empty(&shader->functions);
> exec_list_make_empty(&shader->registers);
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index d0c7b04..320ffee 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -1454,6 +1454,37 @@ typedef struct nir_shader_compiler_options {
> bool native_integers;
>  } nir_shader_compiler_options;
>  
> +typedef struct nir_shader_info {
> +   const char *name;
> +
> +   /* Number of textures used by this shader */
> +   unsigned num_textures;
> +   /* Number of uniform buffers used by this shader */
> +   unsigned num_ubos;
> +   /* Number of atomic buffers used by this shader */
> +   unsigned num_abos;
> +   /* Number of shader storage buffers used by this shader */
> +   unsigned num_ssbos;
> +   /* Number of images used by this shader */
> +   unsigned num_images;
> +
> +   /* Which inputs are actually read */
> +   uint64_t inputs_read;
> +   /* Which outputs are actually written */
> +   uint64_t outputs_written;
> +   /* Which system values are actually read */
> +   uint64_t system_values_read;
> +
> +   /* Whether or not this shader ever uses textureGather() */
> +   bool uses_texture_gather;
> +
> +   /* Whether or not this shader uses the gl_ClipDistance output */
> +   bool uses_clip_distance_out;
> +
> +   /* Whether or not separate shader objects were used */
> +   bool separate_shader;
> +} nir_shader_info;
> +
>  typedef struct nir_shader {
> /** list of uniforms (nir_variable) */
> struct exec_list uniforms;
> @@ -1471,6 +1502,9 @@ typedef struct nir_shader {
>  */
> const struct nir_shader_compiler_options *options;
>  
> +   /** Various bits of compile-time information about a given shader */
> +   struct nir_shader_info info;
> +
> /** list of global variables in the shader (nir_variable) */
> struct exec_list globals;
>  
> diff --git a/src/mesa/program/prog_to_nir.c b/src/mesa/program/prog_to_nir.c
> index 1bd735a..fc00534 100644
> --- a/src/mesa/program/prog_to_nir.c
> +++ b/src/mesa/program/prog_to_nir.c
> @@ -1122,6 +1122,19 @@ prog_to_nir(const struct gl_program *prog,
>  
> ptn_add_output_stores(c);
>  
> +   s->info.name = ralloc_asprintf(s, "ARB%d", prog->Id);
> +   s->info.num_textures = _mesa_fls(prog->SamplersUsed);
> +   s->info.num_ubos = 0;
> +   s->info.num_abos = 0;
> +   s->info.num_ssbos = 0;
> +   s->info.num_images = 0;

I have just noticed that the version of the patch that was committed
does:

shader->info.num_ubos = sh->NumUniformBlocks;
shader->info.num_ssbos = shader_prog->NumBufferInterfaceBlocks;

This is not really correct at the moment. See [1] for a detailed
explanation of why.

I see that nothing uses shader->info.num_ubos for now, so I guess this
is not a real problem at the moment. I plan on sending an actu

Re: [Mesa-dev] [PATCH] glsl: move shader_enums into nir

2015-10-09 Thread Emil Velikov

On 8 October 2015 at 23:25, Rob Clark  wrote:
> From: Rob Clark 
>
> First step towards inverting the dependency between glsl and nir (so nir
> can be used without glsl).  Also solves this issue with 'make distclean'
>
>   Making distclean in mesa
>   make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
>   Makefile:2486: ../glsl/.deps/shader_enums.Plo: No such file or directory
>   make[2]: *** No rule to make target '../glsl/.deps/shader_enums.Plo'. Stop.
>   make[2]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
>   Makefile:684: recipe for target 'distclean-recursive' failed
>   make[1]: *** [distclean-recursive] Error 1
>   make[1]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src'
>   Makefile:615: recipe for target 'distclean-recursive' failed
>   make: *** [distclean-recursive] Error 1
>
> Reported-by: Andy Furniss 
> Signed-off-by: Rob Clark 
Reviewed-by: Emil Velikov 

You might want to pick (as a follow up?) some of these
 - move VARYING_SLOT_MAX and FRAG_RESULT_MAX from mtypes.h to shader_enum.h
 - add the missing SYSTEM_VALUE_NUM_WORK_GROUPS enum
 - use STATIC_ASSERT

I'm also wondering if we'd want to use a prefix for symbols (and
files?) to easily draw the line between the different components.
Through I'd suspect that it will turn into a bikeshed battle ;-)

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/2] i965/gen9: Enable rep clears

2015-10-09 Thread Neil Roberts

Seems like a good idea to me. Series is

Reviewed-by: Neil Roberts 

- Neil

Chad Versace  writes:

> This series lives at
>   git://github.com/chadversary/mesa refs/tags/skl-fast-clear-v08.01
>
> No Piglit regressions on:
>   - Skylake 0x1912 (rev 06)
>   - linux 4.3-rc4
>   - piglit master@2b23e7b
>
> Chad Versace (2):
>   i965/gen9: Disable MCS for 1x color surfaces
>   i965/gen9: Enable rep clears on gen9
>
>  src/mesa/drivers/dri/i965/brw_clear.c   | 2 +-
>  src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 6 ++
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c   | 8 
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> -- 
> 2.5.0.342.g44e0223
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glsl: include variable name in error messages about initializers

2015-10-09 Thread Samuel Iglesias Gonsálvez

Reviewed-by: Samuel Iglesias Gonsálvez 

On 07/10/15 10:12, Iago Toral Quiroga wrote:
> Also fix style / wrong indentation along the way and make the messages
> more uniform.
> ---
>  src/glsl/ast_to_hir.cpp | 29 +
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index da79597..e5543ca 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -3170,7 +3170,8 @@ process_initializer(ir_variable *var, ast_declaration 
> *decl,
>  */
> if (var->data.mode == ir_var_uniform) {
>state->check_version(120, 0, &initializer_loc,
> -   "cannot initialize uniforms");
> +   "cannot initialize uniform %s",
> +   var->name);
> }
>  
> /* Section 4.3.7 "Buffer Variables" of the GLSL 4.30 spec:
> @@ -3178,8 +3179,9 @@ process_initializer(ir_variable *var, ast_declaration 
> *decl,
>  *"Buffer variables cannot have initializers."
>  */
> if (var->data.mode == ir_var_shader_storage) {
> -  _mesa_glsl_error(& initializer_loc, state,
> -   "SSBO variables cannot have initializers");
> +  _mesa_glsl_error(&initializer_loc, state,
> +   "cannot initialize buffer variable %s",
> +   var->name);
> }
>  
> /* From section 4.1.7 of the GLSL 4.40 spec:
> @@ -3189,22 +3191,25 @@ process_initializer(ir_variable *var, ast_declaration 
> *decl,
>  * shader."
>  */
> if (var->type->contains_opaque()) {
> -  _mesa_glsl_error(& initializer_loc, state,
> -   "cannot initialize opaque variable");
> +  _mesa_glsl_error(&initializer_loc, state,
> +   "cannot initialize opaque variable %s",
> +   var->name);
> }
>  
> if ((var->data.mode == ir_var_shader_in) && (state->current_function == 
> NULL)) {
> -  _mesa_glsl_error(& initializer_loc, state,
> -"cannot initialize %s shader input / %s",
> -_mesa_shader_stage_to_string(state->stage),
> -(state->stage == MESA_SHADER_VERTEX)
> -? "attribute" : "varying");
> +  _mesa_glsl_error(&initializer_loc, state,
> +   "cannot initialize %s shader input / %s %s",
> +   _mesa_shader_stage_to_string(state->stage),
> +   (state->stage == MESA_SHADER_VERTEX)
> +   ? "attribute" : "varying",
> +   var->name);
> }
>  
> if ((var->data.mode == ir_var_shader_out) && (state->current_function == 
> NULL)) {
>_mesa_glsl_error(&initializer_loc, state,
> -   "cannot initialize %s shader output",
> -   _mesa_shader_stage_to_string(state->stage));
> +   "cannot initialize %s shader output %s",
> +   _mesa_shader_stage_to_string(state->stage),
> +   var->name);
> }
>  
> /* If the initializer is an ast_aggregate_initializer, recursively store
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

1 2 >

1 - 100 of 112 matches

Mail list logo