date:20160708

[Mesa-dev] [PATCH] glsl: emit a specific error when ast_*_assign changes type

2016-07-08 Thread Ilia Mirkin

For regular ast_add, we can implicitly change either a or b's type.
However in an assignment situation, the type of the lvalue is fixed. So
if the implicit conversion logic decides to change it, it means that the
rhs's type could not be converted to the lhs type.

Emit a specific error for this rather than the rather mysterious "is not
an lvalue" error that results from having a i2f or other operation as
the lvalue.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96729
Signed-off-by: Ilia Mirkin 
---
 src/compiler/glsl/ast_to_hir.cpp | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 8ddc084..55ee840 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1353,7 +1353,7 @@ ast_expression::do_hir(exec_list *instructions,
};
ir_rvalue *result = NULL;
ir_rvalue *op[3];
-   const struct glsl_type *type; /* a temporary variable for switch cases */
+   const struct glsl_type *type, *orig_type;
bool error_emitted = false;
YYLTYPE loc;
 
@@ -1639,10 +1639,18 @@ ast_expression::do_hir(exec_list *instructions,
   op[0] = this->subexpressions[0]->hir(instructions, state);
   op[1] = this->subexpressions[1]->hir(instructions, state);
 
+  orig_type = op[0]->type;
   type = arithmetic_result_type(op[0], op[1],
 (this->oper == ast_mul_assign),
 state, & loc);
 
+  if (type != orig_type) {
+ _mesa_glsl_error(& loc, state,
+  "could not implicitly convert "
+  "rvalue type to lvalue type");
+ type = glsl_type::error_type;
+  }
+
   ir_rvalue *temp_rhs = new(ctx) ir_expression(operations[this->oper], 
type,
op[0], op[1]);
 
@@ -1666,8 +1674,16 @@ ast_expression::do_hir(exec_list *instructions,
   op[0] = this->subexpressions[0]->hir(instructions, state);
   op[1] = this->subexpressions[1]->hir(instructions, state);
 
+  orig_type = op[0]->type;
   type = modulus_result_type(op[0], op[1], state, );
 
+  if (type != orig_type) {
+ _mesa_glsl_error(& loc, state,
+  "could not implicitly convert "
+  "rvalue type to lvalue type");
+ type = glsl_type::error_type;
+  }
+
   assert(operations[this->oper] == ir_binop_mod);
 
   ir_rvalue *temp_rhs;
@@ -1707,7 +1723,17 @@ ast_expression::do_hir(exec_list *instructions,
   this->subexpressions[0]->set_is_lhs(true);
   op[0] = this->subexpressions[0]->hir(instructions, state);
   op[1] = this->subexpressions[1]->hir(instructions, state);
+
+  orig_type = op[0]->type;
   type = bit_logic_result_type(op[0], op[1], this->oper, state, );
+
+  if (type != orig_type) {
+ _mesa_glsl_error(& loc, state,
+  "could not implicitly convert "
+  "rvalue type to lvalue type");
+ type = glsl_type::error_type;
+  }
+
   ir_rvalue *temp_rhs = new(ctx) ir_expression(operations[this->oper],
type, op[0], op[1]);
   error_emitted =
-- 
2.7.3

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

Re: [Mesa-dev] [PATCH] radeonsi: fix bad assertion in si_emit_sample_mask

2016-07-08 Thread Edward O'Callaghan

Reviewed-by: Edward O'Callaghan 

On 07/09/2016 03:42 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle 
> 
> The blitter sets mask == 1, which is fine since it doesn't use smoothing.
> Fixes a regression introduced in commit 5bcfbf91.
> ---
>  src/gallium/drivers/radeonsi/si_state.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index df6b610..bdd7ef4 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -3197,7 +3197,8 @@ static void si_emit_sample_mask(struct si_context 
> *sctx, struct r600_atom *atom)
>* small primitive filter. We expect the state tracker to take care of
>* this for us.
>*/
> - assert(mask == 0x || sctx->framebuffer.nr_samples > 1);
> + assert(mask == 0x || sctx->framebuffer.nr_samples > 1 ||
> +(mask & 1 && sctx->blitter->running));
>  
>   radeon_set_context_reg_seq(cs, R_028C38_PA_SC_AA_MASK_X0Y0_X1Y0, 2);
>   radeon_emit(cs, mask | (mask << 16));
> 



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

[Mesa-dev] [PATCH v2] mesa: etc2 online compression is unsupported, don't attempt it

2016-07-08 Thread Ilia Mirkin

Signed-off-by: Ilia Mirkin 
Cc: "11.2 12.0" 
---

v1 -> v2: also include a mesa_is_etc2_format function which takes a GLenum.

 src/mesa/main/glformats.c | 23 +++
 src/mesa/main/glformats.h |  3 +++
 src/mesa/main/teximage.c  |  1 +
 3 files changed, 27 insertions(+)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 24ce7b0..90f525c 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -907,6 +907,29 @@ _mesa_is_astc_format(GLenum internalFormat)
 }
 
 /**
+ * Test if the given format is an ETC2 format.
+ */
+GLboolean
+_mesa_is_etc2_format(GLenum internalFormat)
+{
+   switch (internalFormat) {
+   case GL_COMPRESSED_RGB8_ETC2:
+   case GL_COMPRESSED_SRGB8_ETC2:
+   case GL_COMPRESSED_RGBA8_ETC2_EAC:
+   case GL_COMPRESSED_SRGB8_ALPHA8_ETC2_EAC:
+   case GL_COMPRESSED_R11_EAC:
+   case GL_COMPRESSED_RG11_EAC:
+   case GL_COMPRESSED_SIGNED_R11_EAC:
+   case GL_COMPRESSED_SIGNED_RG11_EAC:
+   case GL_COMPRESSED_RGB8_PUNCHTHROUGH_ALPHA1_ETC2:
+   case GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2:
+  return true;
+   default:
+  return false;
+   }
+}
+
+/**
  * Test if the given format is an integer (non-normalized) format.
  */
 GLboolean
diff --git a/src/mesa/main/glformats.h b/src/mesa/main/glformats.h
index c73f464..474ede2 100644
--- a/src/mesa/main/glformats.h
+++ b/src/mesa/main/glformats.h
@@ -61,6 +61,9 @@ extern GLboolean
 _mesa_is_astc_format(GLenum internalFormat);
 
 extern GLboolean
+_mesa_is_etc2_format(GLenum internalFormat);
+
+extern GLboolean
 _mesa_is_type_unsigned(GLenum type);
 
 extern GLboolean
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 26a6c21..81e46a1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1307,6 +1307,7 @@ bool
 _mesa_format_no_online_compression(const struct gl_context *ctx, GLenum format)
 {
return _mesa_is_astc_format(format) ||
+  _mesa_is_etc2_format(format) ||
   compressedteximage_only_format(ctx, format);
 }
 
-- 
2.7.3

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: etc2 online compression is unsupported, don't attempt it

2016-07-08 Thread Ilia Mirkin

On Fri, Jul 8, 2016 at 8:16 PM, Anuj Phogat  wrote:
> On Fri, Jul 8, 2016 at 3:42 PM, Ilia Mirkin  wrote:
>> Signed-off-by: Ilia Mirkin 
>> Cc: "11.2 12.0" 
>> ---
>>
>> This is sort of pending a question to KHR at
>>
>> https://www.khronos.org/bugzilla/show_bug.cgi?id=1511
>>
>> but OTOH, no matter their answer, mesa doesn't have online compression for 
>> etc2. So we should reject those calls either way.
>>
>>  src/mesa/main/teximage.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
>> index 26a6c21..81e46a1 100644
>> --- a/src/mesa/main/teximage.c
>> +++ b/src/mesa/main/teximage.c
>> @@ -1307,6 +1307,7 @@ bool
>>  _mesa_format_no_online_compression(const struct gl_context *ctx, GLenum 
>> format)
>>  {
>> return _mesa_is_astc_format(format) ||
>> +  _mesa_is_etc2_format(format) ||
> You're missing a patch adding _mesa_is_etc2_format() helper.

Gr. Moral of the story - compile + test first. It's there for mesa
formats, but is called _mesa_format_is_etc2. There is no version for
GLenum's, I'll add it. Thanks for catching this retard-o =/

>>compressedteximage_only_format(ctx, format);
>>  }
>>
>> --
>> 2.7.3
>>
>> ___
>> mesa-stable mailing list
>> mesa-sta...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: etc2 online compression is unsupported, don't attempt it

2016-07-08 Thread Anuj Phogat

On Fri, Jul 8, 2016 at 3:42 PM, Ilia Mirkin  wrote:
> Signed-off-by: Ilia Mirkin 
> Cc: "11.2 12.0" 
> ---
>
> This is sort of pending a question to KHR at
>
> https://www.khronos.org/bugzilla/show_bug.cgi?id=1511
>
> but OTOH, no matter their answer, mesa doesn't have online compression for 
> etc2. So we should reject those calls either way.
>
>  src/mesa/main/teximage.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 26a6c21..81e46a1 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1307,6 +1307,7 @@ bool
>  _mesa_format_no_online_compression(const struct gl_context *ctx, GLenum 
> format)
>  {
> return _mesa_is_astc_format(format) ||
> +  _mesa_is_etc2_format(format) ||
You're missing a patch adding _mesa_is_etc2_format() helper.
>compressedteximage_only_format(ctx, format);
>  }
>
> --
> 2.7.3
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2016-07-08 Thread bugzilla-daemon

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

--- Comment #3 from Kenneth Graunke  ---
Closing this out as having an "all regressions ever" tracker is useless...it's
just a meta-bugzilla.  Per-release trackers are more reasonable.

At the time of closing, these were open:
44519 66346 70359 71199 77161 77288 78318 87276 89199 90081 90346

And these were closed:
45348 49713 59777 61153 61326 72326 75661 79098 80069 80835 82471 82477 83463
83573 83574 85189 85529 86837 86939 86944 86980 88467 88806 89112 89292 89330
89773 89960 90539

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

[Mesa-dev] [Bug 80835] [llvmpipe] piglit fs-struct-pad regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 66346] shader_query.cpp:49: error: invalid conversion from 'void*' to 'GLuint'

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86939] test_vf_float_conversions.cpp:63:12: error: expected primary-expression before ‘union’

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89199] u_math.h:591:4: error: implicit declaration of function 'ffsll'

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86837] kodi segfault since auxiliary/vl: rework the build of the VL code

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89773] "builtin_functions.cpp", line 3218: Error: INFINITY is not defined.

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88806] nir/nir_constant_expressions.c:2754:15: error: controlling expression type 'unsigned int' not compatible with any generic association type

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90539] [softpipe] piglit varying-packing-simple dmat3 array regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86944] glsl_parser_extras.cpp", line 1455: Error: Badly formed expression. (Oracle Studio)

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89960] [softpipe] piglit copy-pixels regreession

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 85189] llvm/invocation.cpp: In function 'void {anonymous}::optimize(llvm::Module, unsigned int, const std::vector<llvm::Function>&)': llvm/invocation.cpp:324:18: error: expected type

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 86980] [swrast] piglit fp-rfl regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 80069] rendering problems: black areas in KDE desktop. [mesa 10.2.1 (not with 10.1.4)]

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72326] [swrast] piglit glean pbo regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90346] DispatchSanity_test.GLES2 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 82471] [swrast] piglit fp-condition_codes-01 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89112] u_atomic_test: u_atomic_test.c:124: test_atomic_8bits_bool: Assertion `r == 65 && "p_atomic_add"' failed.

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 70359] [llvmpipe] piglit arb_shader_texture_lod-texgrad fails

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 87276] u_atomic_test.c:108:1: error: implicit declaration of function 'test_atomic_cmpxchg_int16_t'

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90081] [llvmpipe] piglit ext_transform_feedback-immediate-reuse-uniform-buffer regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 78318] [swrast] piglit glsl-kwin-blur-1 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 45348] [swrast] piglit fbo-drawbuffers-arbfp regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 75661] st_glsl_to_tgsi.cpp:637:get_opcode: Assertion `src0.type != GLSL_TYPE_STRUCT' failed.

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 61153] [softpipe] piglit interpolation-noperspective-gl_BackColor-flat-vertex regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 79098] x86/common_x86.c:51:19: error: cpuid.h: No such file or directory

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Depends on|44519, 66346, 70359, 71199, |
   |77161, 77288, 78318, 87276, |
   |89199, 90081, 90346, 45348, |
   |49713, 59777, 61153, 61326, |
   |72326, 75661, 79098, 80069, |
   |80835, 82471, 82477, 83463, |
   |83573, 83574, 85189, 85529, |
   |86837, 86939, 86944, 86980, |
   |88467, 88806, 89112, 89292, |
   |89330, 89773, 89960, 90539  |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=44519
[Bug 44519] translate_test generic regression
https://bugs.freedesktop.org/show_bug.cgi?id=45348
[Bug 45348] [swrast] piglit fbo-drawbuffers-arbfp regression
https://bugs.freedesktop.org/show_bug.cgi?id=49713
[Bug 49713] piglit glsl-const-folding-01 regression
https://bugs.freedesktop.org/show_bug.cgi?id=59777
[Bug 59777] [softpipe] piglit
interpolation-noperspective-gl_BackColor-flat-distance regression
https://bugs.freedesktop.org/show_bug.cgi?id=61153
[Bug 61153] [softpipe] piglit
interpolation-noperspective-gl_BackColor-flat-vertex regression
https://bugs.freedesktop.org/show_bug.cgi?id=61326
[Bug 61326] [softpipe] piglit
interpolation-noperspective-gl_BackSecondaryColor-flat-vertex regression
https://bugs.freedesktop.org/show_bug.cgi?id=66346
[Bug 66346] shader_query.cpp:49: error: invalid conversion from 'void*' to
'GLuint'
https://bugs.freedesktop.org/show_bug.cgi?id=70359
[Bug 70359] [llvmpipe] piglit arb_shader_texture_lod-texgrad fails
https://bugs.freedesktop.org/show_bug.cgi?id=71199
[Bug 71199] [llvmpipe] piglit gl-1.4-polygon-offset regression
https://bugs.freedesktop.org/show_bug.cgi?id=72326
[Bug 72326] [swrast] piglit glean pbo regression
https://bugs.freedesktop.org/show_bug.cgi?id=75661
[Bug 75661] st_glsl_to_tgsi.cpp:637:get_opcode: Assertion `src0.type !=
GLSL_TYPE_STRUCT' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=77161
[Bug 77161] [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=77288
[Bug 77288] [swrast] piglit glean glsl1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=78318
[Bug 78318] [swrast] piglit glsl-kwin-blur-1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=79098
[Bug 79098] x86/common_x86.c:51:19: error: cpuid.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=80069
[Bug 80069] rendering problems: black areas in KDE desktop. [mesa 10.2.1 (not
with 10.1.4)]
https://bugs.freedesktop.org/show_bug.cgi?id=80835
[Bug 80835] [llvmpipe] piglit fs-struct-pad regression
https://bugs.freedesktop.org/show_bug.cgi?id=82471
[Bug 82471] [swrast] piglit fp-condition_codes-01 regression
https://bugs.freedesktop.org/show_bug.cgi?id=82477
[Bug 82477] [softpipe] piglit fp-long-alu regression
https://bugs.freedesktop.org/show_bug.cgi?id=83463
[Bug 83463] [swrast] piglit glsl-vs-clamp-1 regression
https://bugs.freedesktop.org/show_bug.cgi?id=83573
[Bug 83573] [swrast] piglit fs-op-not-bool-using-if regression
https://bugs.freedesktop.org/show_bug.cgi?id=83574
[Bug 83574] [llvmpipe] [softpipe] piglit
arb_explicit_uniform_location-use-of-unused-loc regression
https://bugs.freedesktop.org/show_bug.cgi?id=85189
[Bug 85189] llvm/invocation.cpp: In function 'void
{anonymous}::optimize(llvm::Module*, unsigned int, const
std::vector&)': llvm/invocation.cpp:324:18: error: expected
type-specifier
https://bugs.freedesktop.org/show_bug.cgi?id=85529
[Bug 85529] Surfaces not drawn in Unvanquished
https://bugs.freedesktop.org/show_bug.cgi?id=86837
[Bug 86837] kodi segfault since auxiliary/vl: rework the build of the VL code
https://bugs.freedesktop.org/show_bug.cgi?id=86939
[Bug 86939] test_vf_float_conversions.cpp:63:12: error: expected
primary-expression before ‘union’
https://bugs.freedesktop.org/show_bug.cgi?id=86944
[Bug 86944] glsl_parser_extras.cpp", line 1455: Error: Badly formed expression.
(Oracle Studio)
https://bugs.freedesktop.org/show_bug.cgi?id=86980
[Bug 86980] [swrast] piglit fp-rfl regression
https://bugs.freedesktop.org/show_bug.cgi?id=87276
[Bug 87276] u_atomic_test.c:108:1: error: implicit declaration of function
'test_atomic_cmpxchg_int16_t'
https://bugs.freedesktop.org/show_bug.cgi?id=88467
[Bug 88467] nir.c:140: error: ‘nir_src’ has no member named ‘ssa’
https://bugs.freedesktop.org/show_bug.cgi?id=88806
[Bug 88806] nir/nir_constant_expressions.c:2754:15: error: controlling
expression type 'unsigned int' not compatible with any generic association type
https://bugs.freedesktop.org/show_bug.cgi?id=89112
[Bug 89112] u_atomic_test: u_atomic_test.c:124: test_atomic_8bits_bool:
Assertion `r == 65 && "p_atomic_add"' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=89199

[Mesa-dev] [Bug 77288] [swrast] piglit glean glsl1 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 82477] [softpipe] piglit fp-long-alu regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 59777] [softpipe] piglit interpolation-noperspective-gl_BackColor-flat-distance regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 88467] nir.c:140: error: ‘nir_src’ has no member named ‘ssa’

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 89330] piglit glsl-1.50 invariant-qualifier-in-out-block-01 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
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
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 77161] [softpipe] piglit fbo-generatemipmap-cubemap S3TC_DXT1 regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 71199] [llvmpipe] piglit gl-1.4-polygon-offset regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 61326] [softpipe] piglit interpolation-noperspective-gl_BackSecondaryColor-flat-vertex regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 44519] translate_test generic regression

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Blocks|79706   |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=79706
[Bug 79706] [TRACKER] Mesa regression tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2016-07-08 Thread bugzilla-daemon

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

Kenneth Graunke  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

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

[Mesa-dev] [RFC 00/13] egl, i965: Support EGL_ANDROID_native_fence_sync

2016-07-08 Thread Chad Versace

This extension is needed by Android (via ARC++) on Chrome OS.
Essentially, this extension provides a translation between EGLSync and
explicit cross-process synchronization points, represented as "sync
fds".  The relevant documentation is:

  [1]: 
https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_native_fence_sync.txt
  [2]: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/sync_file.txt?id=refs/tags/v4.7-rc6
  [3]: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/sync_file.h?id=refs/tags/v4.7-rc6
  [4]: 
https://source.android.com/devices/graphics/index.html#synchronization_framework
  [5]: 
https://source.android.com/devices/graphics/implement.html#explicit_synchronization

This series is only an RFC because the i915 kernel interface is not yet
upstream. Here's the upstream status:

  - Core kernel support for sync files was merged into Linux 4.7. See
[2] and [3] above.

  - Chris Wilson is actively working on the i915 interface (or at least
I think he is).

  - Chris Wilson, Daniel Vetter, and I roughly agree on the how the i915
interface should work. Add two new optional parameters to execbuf: an
in-fence fd and an out-fence fd. (See [2] above).

This series builds on some of Rob Clark's previous RFC patches, which
are included here. Some of my patches make changes to Rob's or document
open questions about Rob's; those patches are prefixed with either
'squash!' or 'todo!'.

This exact patch series lives at
  git://git.kiwitree.net/~chadv/mesa 
review/i965-EGL_ANDROID_native_fence_sync-v01
  
http://cgit.kiwitree.net/~chadv/mesa/log/?h=review/i965-EGL_ANDROID_native_fence_sync-v01

My up-to-date, work-in-progress, continually changing branch lives at
  git://git.kiwitree.net/~chadv/mesa wip/i965-EGL_ANDROID_native_fence_sync
  
http://cgit.kiwitree.net/~chadv/mesa/log/?h=wip/i965-EGL_ANDROID_native_fence_sync

If you want to build this, you also need my libdrm branch:
  git://cgit.kiwitree.net/~chadv/libdrm wip/intel-fence-fds
  http://cgit.kiwitree.net/~chadv/libdrm/log/?h=wip/intel-fence-fds

Nothing is tested (but at least it builds). Before testing anything,
I plan to wait until I have a working kernel branch for the i915
interface.

Chad Versace (10):
  egl: Use atomic ops on _EGLResource::RefCount
  todo! dri: Questions about fence fd ownership
  squash! egl: add EGL_ANDROID_native_fence_sync
  squash! egl: add EGL_ANDROID_native_fence_sync
  todo! egl/dri2: Questions about sync fd ownership
  i965/sync: Stop cacheing fence's signal status
  i965/sync: Fold brw_fence_has_completed() into caller
  rfc! i965: Add intel_screen::has_fence_fd
  rfc! i965: Add intel_batchbuffer_flush_fence()
  rfc! i965/sync: Support EGL_ANDROID_native_fence_sync

Rob Clark (3):
  egl: initialize SyncCondition after attr parsing
  dri: extend fence extension to support native fd fences
  egl: add EGL_ANDROID_native_fence_sync

 include/GL/internal/dri_interface.h   |  53 +-
 src/egl/drivers/dri2/egl_dri2.c   |  69 +++-
 src/egl/main/eglapi.c |  36 +++-
 src/egl/main/eglapi.h |   2 +
 src/egl/main/egldisplay.c |  13 +-
 src/egl/main/egldisplay.h |   1 +
 src/egl/main/eglfallbacks.c   |   1 +
 src/egl/main/eglsync.c|  35 +++-
 src/egl/main/eglsync.h|   1 +
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |  30 +++-
 src/mesa/drivers/dri/i965/intel_batchbuffer.h |  14 +-
 src/mesa/drivers/dri/i965/intel_screen.c  |   3 +
 src/mesa/drivers/dri/i965/intel_screen.h  |   2 +-
 src/mesa/drivers/dri/i965/intel_syncobj.c | 239 --
 14 files changed, 415 insertions(+), 84 deletions(-)

-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 13/13] rfc! i965/sync: Support EGL_ANDROID_native_fence_sync

2016-07-08 Thread Chad Versace

TODO: The i915 kernel interface nor the libdrm interface is upstream
  yet. So small details may change between now and the final patch.
TODO: Agree on fd ownership rules between EGL and driver with Rob Clark.
TODO: Handle errors from ppoll().
TODO: Test it!
---
 src/mesa/drivers/dri/i965/intel_syncobj.c | 217 ++
 1 file changed, 193 insertions(+), 24 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index 8132efa..77cc8bf 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -38,17 +38,36 @@
  * performance bottleneck, though.
  */
 
+#include 
+
 #include "main/imports.h"
 
 #include "brw_context.h"
 #include "intel_batchbuffer.h"
 #include "intel_reg.h"
 
+enum brw_fence_type {
+   BRW_FENCE_TYPE_BATCH_WAIT,
+   BRW_FENCE_TYPE_SYNC_FD,
+};
+
 struct brw_fence {
-   /** The fence waits for completion of this batch. */
-   drm_intel_bo *batch_bo;
+   union {
+  /** The fence waits for completion of this batch. */
+  drm_intel_bo *batch_bo;
+
+  /**
+   * A kernel sync fd.  Requires I915_PARAM_HAS_EXEC_FENCE_FD. The uapi
+   * for generic sync fds arrived in Linux 4.7; i915 support arrived in
+   * Linux TODO.
+   */
+  int sync_fd;
+   };
+
+   enum brw_fence_type type;
 };
 
+
 struct intel_gl_sync_object {
struct gl_sync_object Base;
struct brw_fence fence;
@@ -57,50 +76,153 @@ struct intel_gl_sync_object {
 static void
 brw_fence_finish(struct brw_fence *fence)
 {
-   if (fence->batch_bo)
-  drm_intel_bo_unreference(fence->batch_bo);
+   switch (fence->type) {
+   case BRW_FENCE_TYPE_BATCH_WAIT:
+  if (fence->batch_bo)
+ drm_intel_bo_unreference(fence->batch_bo);
+  break;
+   case BRW_FENCE_TYPE_SYNC_FD:
+  /* EGL owns the fd, so don't close it. */
+  break;
+   }
+}
+
+static void
+brw_fence_init(struct brw_fence *fence, enum brw_fence_type type)
+{
+   fence->type = type;
+
+   switch (type) {
+   case BRW_FENCE_TYPE_BATCH_WAIT:
+  fence->batch_bo = NULL;
+  break;
+   case BRW_FENCE_TYPE_SYNC_FD:
+  fence->sync_fd = -1;
+  break;
+   }
 }
 
 static void
 brw_fence_insert(struct brw_context *brw, struct brw_fence *fence)
 {
-   assert(!fence->batch_bo);
-
brw_emit_mi_flush(brw);
-   fence->batch_bo = brw->batch.bo;
-   drm_intel_bo_reference(fence->batch_bo);
-   intel_batchbuffer_flush(brw);
+
+   switch (fence->type) {
+   case BRW_FENCE_TYPE_BATCH_WAIT:
+  assert(fence->batch_bo == NULL);
+  fence->batch_bo = brw->batch.bo;
+  drm_intel_bo_reference(fence->batch_bo);
+  intel_batchbuffer_flush(brw);
+  break;
+   case BRW_FENCE_TYPE_SYNC_FD:
+  if (fence->sync_fd == -1) {
+ /* Create a new sync fd.
+  *
+  * From the EGL_ANDROID_native_fence_sync spec (v3):
+  *
+  * When [...] an EGL native fence sync object is created with the
+  * EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute set to
+  * EGL_NO_NATIVE_FENCE_FD_ANDROID, eglCreateSyncKHR also inserts
+  * a fence command into the command stream of the bound client
+  * API's current context [...] The next Flush() operation [...]
+  * causes a new native fence object to be created, and the
+  * EGL_SYNC_NATIVE_FENCE_ANDROID attribute of the EGL native
+  * fence object is set to a file descriptor that refers to the
+  * new native fence object.
+  *
+  * We immediately flush the context. The spec permits but does not
+  * require an immediate flush.
+  */
+ intel_batchbuffer_flush_fence(brw, -1, >sync_fd);
+  } else {
+ /* Insert an existing sync fd into the command stream.
+  *
+  * From the EGL_ANDROID_native_fence_sync spec (v3):
+  *
+  *If the EGL_SYNC_NATIVE_FENCE_FD_ANDROID attribute is not
+  *EGL_NO_NATIVE_FENCE_FD_ANDROID then the EGL_SYNC_CONDITION_KHR
+  *attribute is set to EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID and
+  *the EGL_SYNC_STATUS_KHR attribute is set to reflect the signal
+  *status of the native fence object.  Additionally, the EGL
+  *implementation assumes ownership of the file descriptor, so the
+  *caller must not use it after calling eglCreateSyncKHR.
+  */
+ intel_batchbuffer_flush_fence(brw, fence->sync_fd, NULL);
+  }
+  break;
+   }
 }
 
 /**
- * Return true if the function successfully signals or has already signalled.
+ * Return true if the fence signals or has already signalled.
  * (This matches the behavior expected from __DRI2fence::client_wait_sync).
  */
 static bool
 brw_fence_client_wait(struct brw_context *brw, struct brw_fence *fence,
   uint64_t timeout)
 {
-   assert(fence->batch_bo);
+   switch (fence->type) {
+

[Mesa-dev] [PATCH 03/13] dri: extend fence extension to support native fd fences

2016-07-08 Thread Chad Versace

From: Rob Clark 

Required to implement EGL_ANDROID_native_fence_sync.

Signed-off-by: Rob Clark 
---
 include/GL/internal/dri_interface.h | 44 -
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 1c73cce..99c83ec 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -340,12 +340,19 @@ struct __DRI2throttleExtensionRec {
  */
 
 #define __DRI2_FENCE "DRI2_Fence"
-#define __DRI2_FENCE_VERSION 1
+#define __DRI2_FENCE_VERSION 2
 
 #define __DRI2_FENCE_TIMEOUT_INFINITE 0xllu
 
 #define __DRI2_FENCE_FLAG_FLUSH_COMMANDS  (1 << 0)
 
+/**
+ * \name Capabilities that might be returned by 
__DRI2fenceExtensionRec::get_capabilities
+ */
+/*@{*/
+#define __DRI_FENCE_CAP_NATIVE_FD 1
+/*@}*/
+
 struct __DRI2fenceExtensionRec {
__DRIextension base;
 
@@ -390,6 +397,41 @@ struct __DRI2fenceExtensionRec {
 *sense with this function (right now there are none)
 */
void (*server_wait_sync)(__DRIcontext *ctx, void *fence, unsigned flags);
+
+   /**
+* Query for general capabilities of the driver that concern fences.
+* Returns a bitmask of __DRI_FENCE_CAP_x
+*
+* \since 2
+*/
+   unsigned (*get_capabilities)(__DRIscreen *screen);
+
+   /**
+* Create an fd (file descriptor) associated fence.  If the fence fd
+* is -1, this behaves similarly to create_fence() except that when
+* rendering is flushed the driver creates a fence fd.  Otherwise,
+* the driver wraps an existing fence fd.
+*
+* This is used to implement the EGL_ANDROID_native_fence_sync extension.
+*
+* \since 2
+*
+* \param ctx the context associated with the fence
+* \param fd  the fence fd or -1
+*/
+   void *(*create_fence_fd)(__DRIcontext *ctx, int fd);
+
+   /**
+* For fences created with create_fence_fd(), after rendering is flushed,
+* this retrieves the native fence fd.  Caller takes ownership of the
+* fd and will close() it when it is no longer needed.
+*
+* \since 2
+*
+* \param screen  the screen associated with the fence
+* \param fence   the fence
+*/
+   int (*get_fence_fd)(__DRIscreen *screen, void *fence);
 };
 
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 12/13] rfc! i965: Add intel_batchbuffer_flush_fence()

2016-07-08 Thread Chad Versace

A variant of intel_batchbuffer_flush() with parameters for in and out
fence fds.

TODO: The i915 kernel interface is not yet upstream.
TODO: The fence variants of libdrm functions drm_intel_*_exec() are not
  upstream.
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 30 +++
 src/mesa/drivers/dri/i965/intel_batchbuffer.h | 14 +++--
 2 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 5a0db9f..63a96ef 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -320,7 +320,7 @@ throttle(struct brw_context *brw)
 /* TODO: Push this whole function into bufmgr.
  */
 static int
-do_flush_locked(struct brw_context *brw)
+do_flush_locked(struct brw_context *brw, int in_fence_fd, int *out_fence_fd)
 {
struct intel_batchbuffer *batch = >batch;
int ret = 0;
@@ -353,12 +353,17 @@ do_flush_locked(struct brw_context *brw)
  if (unlikely(INTEL_DEBUG & DEBUG_AUB))
 brw_annotate_aub(brw);
 
+ /* TODO(chadv): The fence variants of drm_intel_*_exec() are not
+  * upstream.
+  */
 if (brw->hw_ctx == NULL || batch->ring != RENDER_RING) {
-ret = drm_intel_bo_mrb_exec(batch->bo, 4 * USED_BATCH(*batch),
-NULL, 0, 0, flags);
+ret = drm_intel_bo_mrb_fence_exec(batch->bo, 4 * 
USED_BATCH(*batch),
+  NULL, 0, 0, flags,
+  in_fence_fd, out_fence_fd);
 } else {
-   ret = drm_intel_gem_bo_context_exec(batch->bo, brw->hw_ctx,
-4 * USED_BATCH(*batch), flags);
+   ret = drm_intel_gem_bo_context_fence_exec(batch->bo, brw->hw_ctx,
+  4 * USED_BATCH(*batch), 
flags,
+  in_fence_fd, 
out_fence_fd);
 }
   }
 
@@ -379,9 +384,17 @@ do_flush_locked(struct brw_context *brw)
return ret;
 }
 
+/**
+ * The in_fence_fd is ignored if -1.  Otherwise this function takes ownership
+ * of the fd.
+ *
+ * The out_fence_fd is ignored if NULL. Otherwise, the caller takes ownership
+ * of the returned fd.
+ */
 int
-_intel_batchbuffer_flush(struct brw_context *brw,
-const char *file, int line)
+_intel_batchbuffer_flush_fence(struct brw_context *brw,
+   int in_fence_fd, int *out_fence_fd,
+   const char *file, int line)
 {
int ret;
 
@@ -420,7 +433,7 @@ _intel_batchbuffer_flush(struct brw_context *brw,
/* Check that we didn't just wrap our batchbuffer at a bad time. */
assert(!brw->no_batch_wrap);
 
-   ret = do_flush_locked(brw);
+   ret = do_flush_locked(brw, in_fence_fd, out_fence_fd);
 
if (unlikely(INTEL_DEBUG & DEBUG_SYNC)) {
   fprintf(stderr, "waiting for idle\n");
@@ -436,7 +449,6 @@ _intel_batchbuffer_flush(struct brw_context *brw,
return ret;
 }
 
-
 /*  This is the only way buffers get added to the validate list.
  */
 uint32_t
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 67e8e8f..9376c8d 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -46,14 +46,16 @@ void intel_batchbuffer_save_state(struct brw_context *brw);
 void intel_batchbuffer_reset_to_saved(struct brw_context *brw);
 void intel_batchbuffer_require_space(struct brw_context *brw, GLuint sz,
  enum brw_gpu_ring ring);
+int _intel_batchbuffer_flush_fence(struct brw_context *brw,
+   int in_fence_fd, int *out_fence_fd,
+   const char *file, int line);
 
-int _intel_batchbuffer_flush(struct brw_context *brw,
-const char *file, int line);
-
-#define intel_batchbuffer_flush(intel) \
-   _intel_batchbuffer_flush(intel, __FILE__, __LINE__)
-
+#define intel_batchbuffer_flush(brw) \
+   _intel_batchbuffer_flush_fence((brw), -1, NULL, __FILE__, __LINE__)
 
+#define intel_batchbuffer_flush_fence(brw, in_fence_fd, out_fence_fd) \
+   _intel_batchbuffer_flush_fence((brw), (in_fence_fd), (out_fence_fd), \
+  __FILE__, __LINE__)
 
 /* Unlike bmBufferData, this currently requires the buffer be mapped.
  * Consider it a convenience function wrapping multple
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 06/13] squash! egl: add EGL_ANDROID_native_fence_sync

2016-07-08 Thread Chad Versace

Don't set SyncCondition twice.
---
 src/egl/main/eglsync.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index 375f223..d65fbdd 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -119,7 +119,6 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type,
   sync->SyncCondition = EGL_SYNC_CL_EVENT_COMPLETE_KHR;
   break;
case EGL_SYNC_NATIVE_FENCE_ANDROID:
-  sync->SyncCondition = EGL_SYNC_NATIVE_FENCE_SIGNALED_ANDROID;
   if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID)
  sync->SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR;
   else
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 08/13] todo! egl/dri2: Questions about sync fd ownership

2016-07-08 Thread Chad Versace

See the comments.
---
 src/egl/drivers/dri2/egl_dri2.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index c7b81ce..03ed4b9 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2412,6 +2412,18 @@ dri2_egl_unref_sync(struct dri2_egl_display *dri2_dpy,
  cnd_destroy(_sync->cond);
  break;
   case EGL_SYNC_NATIVE_FENCE_ANDROID:
+ /* TODO(chadv): We must take care to not double-close nor leak the
+  * fd. To avoid double-close and leak, we need to carefully document
+  * fd ownership and duplication rules.
+  *
+  * TODO(chadv): Document the decision at _EGLSync::SyncFd,
+  *
+  * FIXME(chadv): Potential bug. If we define that EGL (not the
+  * driver) owns the fence fd created by the flush after
+  * eglCreateSync(), we need to ensure the fd doesn't leak. Today, it
+  * leaks if the user never calls eglDupNativeFenceFDANDROID() because
+  * _EGLSync::SyncFd remains -1 forever.
+  */
  if (dri2_sync->base.SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
 close(dri2_sync->base.SyncFd);
  break;
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 10/13] i965/sync: Fold brw_fence_has_completed() into caller

2016-07-08 Thread Chad Versace

The function is tiny and called exactly once. There's no need for it to
exist.
---
 src/mesa/drivers/dri/i965/intel_syncobj.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index 8a18016..8132efa 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -72,13 +72,6 @@ brw_fence_insert(struct brw_context *brw, struct brw_fence 
*fence)
intel_batchbuffer_flush(brw);
 }
 
-static bool
-brw_fence_has_completed(struct brw_fence *fence)
-{
-   assert(fence->batch_bo);
-   return !drm_intel_bo_busy(fence->batch_bo);
-}
-
 /**
  * Return true if the function successfully signals or has already signalled.
  * (This matches the behavior expected from __DRI2fence::client_wait_sync).
@@ -166,8 +159,11 @@ static void
 intel_gl_check_sync(struct gl_context *ctx, struct gl_sync_object *s)
 {
struct intel_gl_sync_object *sync = (struct intel_gl_sync_object *)s;
+   struct brw_fence *fence = >fence;
 
-   if (brw_fence_has_completed(>fence))
+   assert(fence->batch_bo);
+
+   if (!drm_intel_bo_busy(fence->batch_bo))
   s->StatusFlag = 1;
 }
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 02/13] egl: initialize SyncCondition after attr parsing

2016-07-08 Thread Chad Versace

From: Rob Clark 

Reduce the noise in the next patch.  For EGL_SYNC_NATIVE_FENCE_ANDROID
the sync condition is conditional on EGL_SYNC_NATIVE_FENCE_FD_ANDROID
attribute.

Signed-off-by: Rob Clark 
---
 src/egl/main/eglsync.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index eb56655..becb57d 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -100,19 +100,19 @@ _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum 
type,
sync->Type = type;
sync->SyncStatus = EGL_UNSIGNALED_KHR;
 
-   switch (type) {
-   case EGL_SYNC_CL_EVENT_KHR:
-  sync->SyncCondition = EGL_SYNC_CL_EVENT_COMPLETE_KHR;
-  break;
-   default:
-  sync->SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR;
-   }
-
if (attrib_list64)
   err = _eglParseSyncAttribList64(sync, attrib_list64);
else
   err = _eglParseSyncAttribList(sync, attrib_list);
 
+   switch (type) {
+   case EGL_SYNC_CL_EVENT_KHR:
+  sync->SyncCondition = EGL_SYNC_CL_EVENT_COMPLETE_KHR;
+  break;
+   default:
+  sync->SyncCondition = EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR;
+   }
+
if (err != EGL_SUCCESS)
   return _eglError(err, "eglCreateSyncKHR");
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 01/13] egl: Use atomic ops on _EGLResource::RefCount

2016-07-08 Thread Chad Versace

Mesa was incrementing and decrementing EGL refcounts with ++ and --.
---
 src/egl/main/egldisplay.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/egl/main/egldisplay.c b/src/egl/main/egldisplay.c
index bbc3063..78b5d20 100644
--- a/src/egl/main/egldisplay.c
+++ b/src/egl/main/egldisplay.c
@@ -37,6 +37,8 @@
 #include 
 #include "c11/threads.h"
 
+#include "util/u_atomic.h"
+
 #include "eglcontext.h"
 #include "eglcurrent.h"
 #include "eglsurface.h"
@@ -385,21 +387,20 @@ _eglInitResource(_EGLResource *res, EGLint size, 
_EGLDisplay *dpy)
 void
 _eglGetResource(_EGLResource *res)
 {
-   assert(res && res->RefCount > 0);
-   /* hopefully a resource is always manipulated with its display locked */
-   res->RefCount++;
+   assert(res->RefCount > 0);
+   p_atomic_inc(>RefCount);
 }
 
 
 /**
  * Decrement reference count for the resource.
+ * Return true when the last reference is dropped.
  */
 EGLBoolean
 _eglPutResource(_EGLResource *res)
 {
-   assert(res && res->RefCount > 0);
-   res->RefCount--;
-   return (!res->RefCount);
+   assert(res->RefCount > 0);
+   return p_atomic_dec_return(>RefCount) == 0;
 }
 
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 07/13] squash! egl: add EGL_ANDROID_native_fence_sync

2016-07-08 Thread Chad Versace

Close the sync fd *after* the sync's refcount drops to 0.
---
 src/egl/drivers/dri2/egl_dri2.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index a9d351e..c7b81ce 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -2407,8 +2407,17 @@ dri2_egl_unref_sync(struct dri2_egl_display *dri2_dpy,
 struct dri2_egl_sync *dri2_sync)
 {
if (p_atomic_dec_zero(_sync->refcount)) {
-  if (dri2_sync->base.Type == EGL_SYNC_REUSABLE_KHR)
+  switch (dri2_sync->base.Type) {
+  case EGL_SYNC_REUSABLE_KHR:
  cnd_destroy(_sync->cond);
+ break;
+  case EGL_SYNC_NATIVE_FENCE_ANDROID:
+ if (dri2_sync->base.SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
+close(dri2_sync->base.SyncFd);
+ break;
+  default:
+ break;
+  }
 
   if (dri2_sync->fence)
  dri2_dpy->fence->destroy_fence(dri2_dpy->dri_screen, 
dri2_sync->fence);
@@ -2544,9 +2553,6 @@ dri2_destroy_sync(_EGLDriver *drv, _EGLDisplay *dpy, 
_EGLSync *sync)
   }
}
 
-   if (sync->SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
-  close(sync->SyncFd);
-
dri2_egl_unref_sync(dri2_dpy, dri2_sync);
 
return ret;
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 04/13] todo! dri: Questions about fence fd ownership

2016-07-08 Thread Chad Versace

See the comments.
---
 include/GL/internal/dri_interface.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 99c83ec..051ddb4 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -418,6 +418,12 @@ struct __DRI2fenceExtensionRec {
 *
 * \param ctx the context associated with the fence
 * \param fd  the fence fd or -1
+*
+* TODO(chadv): Who owns the fence fd when the caller imports it (when
+* fd != 1)? Does EGL or the driver own it?
+*
+* TODO(chadv): Who owns the fence fd when the driver creates it (when
+* fd == -1)? Does EGL or the driver own it?
 */
void *(*create_fence_fd)(__DRIcontext *ctx, int fd);
 
@@ -430,6 +436,9 @@ struct __DRI2fenceExtensionRec {
 *
 * \param screen  the screen associated with the fence
 * \param fence   the fence
+*
+* TODO(chadv): Should the driver return its actual fence fd? Or should it
+* return a dup'd fd?
 */
int (*get_fence_fd)(__DRIscreen *screen, void *fence);
 };
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 11/13] rfc! i965: Add intel_screen::has_fence_fd

2016-07-08 Thread Chad Versace

This bool maps to I915_PARAM_HAS_EXEC_FENCE_FD.

TODO: The i915 param is not yet upstream.  Wait for the kernel interface
  before committing.
---
 src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.h | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 432ab7b..5a2cee1 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1637,6 +1637,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
 intel_get_boolean(intelScreen, I915_PARAM_HAS_RESOURCE_STREAMER);
}
 
+   intelScreen->has_fence_fd =
+ intel_get_boolean(intelScreen, I915_PARAM_HAS_EXEC_FENCE_FD);
+
return (const __DRIconfig**) intel_screen_make_configs(psp);
 }
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h
index 98f9d24..d167758 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -45,8 +45,8 @@ struct intel_screen
__DRIscreen *driScrnPriv;
 
bool no_hw;
-
bool hw_has_swizzling;
+   bool has_fence_fd;
 
int hw_has_timestamp;
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 05/13] egl: add EGL_ANDROID_native_fence_sync

2016-07-08 Thread Chad Versace

From: Rob Clark 

[chadv]: Fix bugs in attribute parsing.

Signed-off-by: Rob Clark 
---
 src/egl/drivers/dri2/egl_dri2.c | 49 +
 src/egl/main/eglapi.c   | 36 +++---
 src/egl/main/eglapi.h   |  2 ++
 src/egl/main/egldisplay.h   |  1 +
 src/egl/main/eglfallbacks.c |  1 +
 src/egl/main/eglsync.c  | 20 -
 src/egl/main/eglsync.h  |  1 +
 7 files changed, 106 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index bfde640..a9d351e 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -624,6 +624,12 @@ dri2_setup_screen(_EGLDisplay *disp)
   disp->Extensions.KHR_wait_sync = EGL_TRUE;
   if (dri2_dpy->fence->get_fence_from_cl_event)
  disp->Extensions.KHR_cl_event2 = EGL_TRUE;
+  if (dri2_dpy->fence->base.version >= 2) {
+ unsigned capabilities =
+dri2_dpy->fence->get_capabilities(dri2_dpy->dri_screen);
+ disp->Extensions.ANDROID_native_fence_sync =
+(capabilities & __DRI_FENCE_CAP_NATIVE_FD) != 0;
+  }
}
 
disp->Extensions.KHR_reusable_sync = EGL_TRUE;
@@ -2495,6 +2501,19 @@ dri2_create_sync(_EGLDriver *drv, _EGLDisplay *dpy,
   /* initial status of reusable sync must be "unsignaled" */
   dri2_sync->base.SyncStatus = EGL_UNSIGNALED_KHR;
   break;
+
+   case EGL_SYNC_NATIVE_FENCE_ANDROID:
+  if (dri2_dpy->fence->create_fence_fd) {
+ dri2_sync->fence = dri2_dpy->fence->create_fence_fd(
+dri2_ctx->dri_context,
+dri2_sync->base.SyncFd);
+  }
+  if (!dri2_sync->fence) {
+ _eglError(EGL_BAD_ATTRIBUTE, "eglCreateSyncKHR");
+ free(dri2_sync);
+ return NULL;
+  }
+  break;
}
 
p_atomic_set(_sync->refcount, 1);
@@ -2524,11 +2543,40 @@ dri2_destroy_sync(_EGLDriver *drv, _EGLDisplay *dpy, 
_EGLSync *sync)
  ret = EGL_FALSE;
   }
}
+
+   if (sync->SyncFd != EGL_NO_NATIVE_FENCE_FD_ANDROID)
+  close(sync->SyncFd);
+
dri2_egl_unref_sync(dri2_dpy, dri2_sync);
 
return ret;
 }
 
+static EGLint
+dri2_dup_native_fence_fd(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync)
+{
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(dpy);
+   struct dri2_egl_sync *dri2_sync = dri2_egl_sync(sync);
+
+   assert(sync->Type == EGL_SYNC_NATIVE_FENCE_ANDROID);
+
+   if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
+  /* try to retrieve the actual native fence fd.. if rendering is
+   * not flushed this will just return -1, aka NO_NATIVE_FENCE_FD:
+   */
+  sync->SyncFd = dri2_dpy->fence->get_fence_fd(dri2_dpy->dri_screen,
+   dri2_sync->fence);
+   }
+
+   if (sync->SyncFd == EGL_NO_NATIVE_FENCE_FD_ANDROID) {
+  /* if native fence fd still not created, return an error: */
+  _eglError(EGL_BAD_PARAMETER, "eglDupNativeFenceFDANDROID");
+  return EGL_NO_NATIVE_FENCE_FD_ANDROID;
+   }
+
+   return dup(sync->SyncFd);
+}
+
 static EGLint
 dri2_client_wait_sync(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSync *sync,
   EGLint flags, EGLTime timeout)
@@ -2826,6 +2874,7 @@ _eglBuiltInDriverDRI2(const char *args)
dri2_drv->base.API.SignalSyncKHR = dri2_signal_sync;
dri2_drv->base.API.WaitSyncKHR = dri2_server_wait_sync;
dri2_drv->base.API.DestroySyncKHR = dri2_destroy_sync;
+   dri2_drv->base.API.DupNativeFenceFDANDROID = dri2_dup_native_fence_fd;
dri2_drv->base.API.GLInteropQueryDeviceInfo = 
dri2_interop_query_device_info;
dri2_drv->base.API.GLInteropExportObject = dri2_interop_export_object;
 
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4f5b0b2..cd8c5f8 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -425,6 +425,7 @@ _eglCreateExtensionsString(_EGLDisplay *dpy)
/* Please keep these sorted alphabetically. */
_EGL_CHECK_EXTENSION(ANDROID_framebuffer_target);
_EGL_CHECK_EXTENSION(ANDROID_image_native_buffer);
+   _EGL_CHECK_EXTENSION(ANDROID_native_fence_sync);
_EGL_CHECK_EXTENSION(ANDROID_recordable);
 
_EGL_CHECK_EXTENSION(CHROMIUM_sync_control);
@@ -1439,6 +1440,10 @@ _eglCreateSync(EGLDisplay dpy, EGLenum type, const 
EGLint *attrib_list,
   if (!disp->Extensions.KHR_cl_event2)
  RETURN_EGL_ERROR(disp, invalid_type_error, EGL_NO_SYNC_KHR);
   break;
+   case EGL_SYNC_NATIVE_FENCE_ANDROID:
+  if (!disp->Extensions.ANDROID_native_fence_sync)
+ RETURN_EGL_ERROR(disp, invalid_type_error, EGL_NO_SYNC_KHR);
+  break;
default:
   RETURN_EGL_ERROR(disp, invalid_type_error, EGL_NO_SYNC_KHR);
}
@@ -1484,7 +1489,8 @@ eglDestroySync(EGLDisplay dpy, EGLSync sync)
 
_EGL_CHECK_SYNC(disp, s, EGL_FALSE, drv);

[Mesa-dev] [PATCH 09/13] i965/sync: Stop cacheing fence's signal status

2016-07-08 Thread Chad Versace

Cacheing the signal status complicates the code for questionable
performance benefit. I added the cacheing long ago, and I now think it
was the wrong decision.
---
 src/mesa/drivers/dri/i965/intel_syncobj.c | 28 +++-
 1 file changed, 3 insertions(+), 25 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c 
b/src/mesa/drivers/dri/i965/intel_syncobj.c
index c44c4be..8a18016 100644
--- a/src/mesa/drivers/dri/i965/intel_syncobj.c
+++ b/src/mesa/drivers/dri/i965/intel_syncobj.c
@@ -47,8 +47,6 @@
 struct brw_fence {
/** The fence waits for completion of this batch. */
drm_intel_bo *batch_bo;
-
-   bool signalled;
 };
 
 struct intel_gl_sync_object {
@@ -67,7 +65,6 @@ static void
 brw_fence_insert(struct brw_context *brw, struct brw_fence *fence)
 {
assert(!fence->batch_bo);
-   assert(!fence->signalled);
 
brw_emit_mi_flush(brw);
fence->batch_bo = brw->batch.bo;
@@ -78,17 +75,8 @@ brw_fence_insert(struct brw_context *brw, struct brw_fence 
*fence)
 static bool
 brw_fence_has_completed(struct brw_fence *fence)
 {
-   if (fence->signalled)
-  return true;
-
-   if (fence->batch_bo && !drm_intel_bo_busy(fence->batch_bo)) {
-  drm_intel_bo_unreference(fence->batch_bo);
-  fence->batch_bo = NULL;
-  fence->signalled = true;
-  return true;
-   }
-
-   return false;
+   assert(fence->batch_bo);
+   return !drm_intel_bo_busy(fence->batch_bo);
 }
 
 /**
@@ -99,9 +87,6 @@ static bool
 brw_fence_client_wait(struct brw_context *brw, struct brw_fence *fence,
   uint64_t timeout)
 {
-   if (fence->signalled)
-  return true;
-
assert(fence->batch_bo);
 
/* DRM_IOCTL_I915_GEM_WAIT uses a signed 64 bit timeout and returns
@@ -112,14 +97,7 @@ brw_fence_client_wait(struct brw_context *brw, struct 
brw_fence *fence,
if (timeout > INT64_MAX)
   timeout = INT64_MAX;
 
-   if (drm_intel_gem_bo_wait(fence->batch_bo, timeout) != 0)
-  return false;
-
-   fence->signalled = true;
-   drm_intel_bo_unreference(fence->batch_bo);
-   fence->batch_bo = NULL;
-
-   return true;
+   return drm_intel_gem_bo_wait(fence->batch_bo, timeout) == 0;
 }
 
 static void
-- 
2.9.0.rc2

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

[Mesa-dev] [Bug 89599] symbol 'x86_64_entry_start' is already defined when building with LLVM/clang

2016-07-08 Thread bugzilla-daemon

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

Vinson Lee  changed:

   What|Removed |Added

 CC||v...@freedesktop.org

--- Comment #10 from Vinson Lee  ---
*** Bug 92630 has been marked as a duplicate of this bug. ***

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

[Mesa-dev] [Bug 92630] fatal error: error in backend: symbol 'x86_64_entry_start' is already defined

2016-07-08 Thread bugzilla-daemon

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

Vinson Lee  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Vinson Lee  ---


*** This bug has been marked as a duplicate of bug 89599 ***

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

[Mesa-dev] [Bug 75661] st_glsl_to_tgsi.cpp:637:get_opcode: Assertion `src0.type != GLSL_TYPE_STRUCT' failed.

2016-07-08 Thread bugzilla-daemon

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

Vinson Lee  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Vinson Lee  ---
mesa: 83a782cd5ed6d0c3265b4bd817160fc4de6a19c1 (master 12.1.0-devel)

piglit fs-deref-literal-array-of-structs passes on both llvmpipe and softpipe.

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

[Mesa-dev] [Bug 79706] [TRACKER] Mesa regression tracker

2016-07-08 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=79706
Bug 79706 depends on bug 75661, which changed state.

Bug 75661 Summary: st_glsl_to_tgsi.cpp:637:get_opcode: Assertion `src0.type != 
GLSL_TYPE_STRUCT' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=75661

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

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

[Mesa-dev] [Bug 79471] [llvmpipe] [softpipe] state_tracker/st_glsl_to_tgsi.cpp:4495:translate_src: Assertion `src_reg->file != PROGRAM_TEMPORARY' failed.

2016-07-08 Thread bugzilla-daemon

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

Vinson Lee  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Vinson Lee  ---
mesa: 83a782cd5ed6d0c3265b4bd817160fc4de6a19c1 (master 12.1.0-devel)

piglit fs-const-array-of-struct-of-array passes on both llvmpipe and softpipe
now.

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

[Mesa-dev] [ANNOUNCE] mesa 12.0.1

2016-07-08 Thread Emil Velikov

Hi all,

Mesa 12.0.1 is available.

It resolves r600/radeonsi build issues introduced in the 12.0.0 release.

Emil Velikov (4):
  docs: add sha256 checksums for 12.0.0
  radeon: reference the correct cdw/max_dw
  Update version to 12.0.1
  docs: add release notes for 12.0.1

git tag: mesa-12.0.1

ftp://ftp.freedesktop.org/pub/mesa/12.0.1/mesa-12.0.1.tar.gz
MD5:  2e291a528dce8451dbd3eaaa1e765d5a  mesa-12.0.1.tar.gz
SHA1: 1b239fb395d55a78037f60a1d397f6080dcdd52b  mesa-12.0.1.tar.gz
SHA256: 28dff9c045f4305c96a875a487b9f06c7e88d910511cd6016dbddcd1f53ade0d  
mesa-12.0.1.tar.gz
PGP:  ftp://ftp.freedesktop.org/pub/mesa/12.0.1/mesa-12.0.1.tar.gz.sig

ftp://ftp.freedesktop.org/pub/mesa/12.0.1/mesa-12.0.1.tar.xz
MD5:  972fd5ad5a63aeabf173fb9adefc6522  mesa-12.0.1.tar.xz
SHA1: c1f84352bb02af837c9853981c985b000ba4f799  mesa-12.0.1.tar.xz
SHA256: bab24fb79f78c876073527f515ed871fc9c81d816f66c8a0b051d8d653896389  
mesa-12.0.1.tar.xz
PGP:  ftp://ftp.freedesktop.org/pub/mesa/12.0.1/mesa-12.0.1.tar.xz.sig




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

[Mesa-dev] [Bug 96853] gl_PrimitiveID is zero when rendering points of size > 1

2016-07-08 Thread bugzilla-daemon

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

--- Comment #4 from Brian Paul  ---
I'll try to take a look at this when I get a little time...

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

[Mesa-dev] [PATCH 3/4] egl: Refactor errors for bad EGLSync attributes

2016-07-08 Thread Chad Versace

Move the error handling into a little helper function. This will keep
the code clean when later adding error handling for attribute
EGL_SYNC_NATIVE_FENCE_FD_ANDROID.

And fix the log message to work when EGLAttrib is 32-bit or 64-bit.
---
 src/egl/main/eglsync.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index 48714d1..e90aeb4 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -67,11 +67,18 @@ _eglParseSyncAttribList(_EGLSync *sync, const EGLint 
*attrib_list)
 }
 
 
+static EGLint
+badSyncAttrib(EGLAttrib attr)
+{
+   _eglLog(_EGL_DEBUG, "bad sync attribute 0x0*%" PRIxPTR,
+   2 * sizeof(attr), attr);
+   return EGL_BAD_ATTRIBUTE;
+}
+
+
 static EGLint
 _eglParseSyncAttribList64(_EGLSync *sync, const EGLAttrib *attrib_list)
 {
-   EGLint err = EGL_SUCCESS;
-
if (!attrib_list)
   return EGL_SUCCESS;
 
@@ -81,24 +88,16 @@ _eglParseSyncAttribList64(_EGLSync *sync, const EGLAttrib 
*attrib_list)
 
   switch (attr) {
   case EGL_CL_EVENT_HANDLE_KHR:
- if (sync->Type == EGL_SYNC_CL_EVENT_KHR) {
-sync->CLEvent = val;
-break;
- }
- /* fall through */
-  default:
- (void) val;
- err = EGL_BAD_ATTRIBUTE;
+ if (sync->Type != EGL_SYNC_CL_EVENT_KHR)
+return badSyncAttrib(attr);
+ sync->CLEvent = val;
  break;
-  }
-
-  if (err != EGL_SUCCESS) {
- _eglLog(_EGL_DEBUG, "bad sync attribute 0x%" PRIxPTR, attr);
- return err;
+  default:
+ return badSyncAttrib(attr);
   }
}
 
-   return err;
+   return EGL_SUCCESS;
 }
 
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 0/4] egl: Fixes and cleanups for EGLSync

2016-07-08 Thread Chad Versace

I found these fixes and cleanups while trying to implement
EGL_ANDROID_native_fence_sync for i965.

No changes in test results when running `deqp-egl --deqp-case='*sync*'`
under X11.

Branch lives at
  git://git.kiwitree.net/~chadv/mesa#review/egl-sync-cleanups-v01
  http://cgit.kiwitree.net/~chadv/mesa/log/?h=review/egl-sync-cleanups-v01

Chad Versace (4):
  egl: Add _eglConvertIntsToAttribs()
  egl: Fix type errors in _eglParseSyncAttribList64()
  egl: Refactor errors for bad EGLSync attributes
  egl: Unify attrib parsing of eglCreateSync, eglCreateSyncKHR

 src/egl/main/eglapi.c  | 41 
 src/egl/main/eglapi.h  |  2 ++
 src/egl/main/eglsync.c | 73 +++---
 3 files changed, 71 insertions(+), 45 deletions(-)

-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 1/4] egl: Add _eglConvertIntsToAttribs()

2016-07-08 Thread Chad Versace

This function converts an attribute list from EGLint[] to EGLAttrib[].
Will be use in following patches to cleanup EGLSync attribute parsing.
---
 src/egl/main/eglapi.c | 41 +
 src/egl/main/eglapi.h |  2 ++
 2 files changed, 43 insertions(+)

diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4700dbe..4f5b0b2 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -251,6 +251,47 @@ _eglUnlockDisplay(_EGLDisplay *dpy)
 }
 
 
+/**
+ * Convert an attribute list from EGLint[] to EGLAttrib[].
+ *
+ * Return an EGL error code. The output parameter out_attrib_list is modified
+ * only on success.
+ */
+EGLint
+_eglConvertIntsToAttribs(const EGLint *int_list, EGLAttrib **out_attrib_list)
+{
+   size_t len = 0;
+   EGLAttrib *attrib_list;
+
+   if (int_list) {
+  while (int_list[2*len] != EGL_NONE)
+ ++len;
+   }
+
+   if (len == 0) {
+  *out_attrib_list = NULL;
+  return EGL_SUCCESS;
+   }
+
+   if (2*len + 1 > SIZE_MAX / sizeof(EGLAttrib))
+  return EGL_BAD_ALLOC;
+
+   attrib_list = malloc((2*len + 1) * sizeof(EGLAttrib));
+   if (!attrib_list)
+  return EGL_BAD_ALLOC;
+
+   for (size_t i = 0; i < len; ++i) {
+  attrib_list[2*i + 0] = int_list[2*i + 0];
+  attrib_list[2*i + 1] = int_list[2*i + 1];
+   }
+
+   attrib_list[2*len] = EGL_NONE;
+
+   *out_attrib_list = attrib_list;
+   return EGL_SUCCESS;
+}
+
+
 static EGLint *
 _eglConvertAttribsToInt(const EGLAttrib *attr_list)
 {
diff --git a/src/egl/main/eglapi.h b/src/egl/main/eglapi.h
index 2d6a24f..5d9c1b8 100644
--- a/src/egl/main/eglapi.h
+++ b/src/egl/main/eglapi.h
@@ -199,6 +199,8 @@ struct _egl_api
 struct mesa_glinterop_export_out *out);
 };
 
+EGLint _eglConvertIntsToAttribs(const EGLint *int_list,
+EGLAttrib **out_attrib_list);
 
 #ifdef __cplusplus
 }
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 4/4] egl: Unify attrib parsing of eglCreateSync, eglCreateSyncKHR

2016-07-08 Thread Chad Versace

eglCreateSyncKHR takes an attribute list of type EGLint[]. eglCreateSync
takes one of type EGLAttrib[]. Implement eglCreateSyncKHR's attribute
parsing in terms of eglCreateSync's by converting the EGLint[] into
EGLAttrib[].

This cleanup will simplify the code when later implementing
EGL_ANDROID_native_fence_sync.
---
 src/egl/main/eglsync.c | 47 +++
 1 file changed, 15 insertions(+), 32 deletions(-)

diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index e90aeb4..eb56655 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -35,38 +35,6 @@
 #include "egllog.h"
 
 
-/**
- * Parse the list of sync attributes and return the proper error code.
- */
-static EGLint
-_eglParseSyncAttribList(_EGLSync *sync, const EGLint *attrib_list)
-{
-   EGLint i, err = EGL_SUCCESS;
-
-   if (!attrib_list)
-  return EGL_SUCCESS;
-
-   for (i = 0; attrib_list[i] != EGL_NONE; i++) {
-  EGLint attr = attrib_list[i++];
-  EGLint val = attrib_list[i];
-
-  switch (attr) {
-  default:
- (void) val;
- err = EGL_BAD_ATTRIBUTE;
- break;
-  }
-
-  if (err != EGL_SUCCESS) {
- _eglLog(_EGL_DEBUG, "bad sync attribute 0x%04x", attr);
- break;
-  }
-   }
-
-   return err;
-}
-
-
 static EGLint
 badSyncAttrib(EGLAttrib attr)
 {
@@ -100,6 +68,21 @@ _eglParseSyncAttribList64(_EGLSync *sync, const EGLAttrib 
*attrib_list)
return EGL_SUCCESS;
 }
 
+static EGLint
+_eglParseSyncAttribList(_EGLSync *sync, const EGLint *int_list)
+{
+   EGLAttrib *attrib_list;
+   EGLint err;
+
+   err = _eglConvertIntsToAttribs(int_list, _list);
+   if (err != EGL_SUCCESS)
+  return err;
+
+   err = _eglParseSyncAttribList64(sync, attrib_list);
+   free(attrib_list);
+   return err;
+}
+
 
 EGLBoolean
 _eglInitSync(_EGLSync *sync, _EGLDisplay *dpy, EGLenum type,
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH 2/4] egl: Fix type errors in _eglParseSyncAttribList64()

2016-07-08 Thread Chad Versace

- The list elements have type EGLAttrib, not EGLint.
- The array index iterator should be size_t, not EGLint.
---
 src/egl/main/eglsync.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/egl/main/eglsync.c b/src/egl/main/eglsync.c
index 33625e9..48714d1 100644
--- a/src/egl/main/eglsync.c
+++ b/src/egl/main/eglsync.c
@@ -26,6 +26,7 @@
  **/
 
 
+#include 
 #include 
 
 #include "eglsync.h"
@@ -69,14 +70,14 @@ _eglParseSyncAttribList(_EGLSync *sync, const EGLint 
*attrib_list)
 static EGLint
 _eglParseSyncAttribList64(_EGLSync *sync, const EGLAttrib *attrib_list)
 {
-   EGLint i, err = EGL_SUCCESS;
+   EGLint err = EGL_SUCCESS;
 
if (!attrib_list)
   return EGL_SUCCESS;
 
-   for (i = 0; attrib_list[i] != EGL_NONE; i++) {
-  EGLint attr = attrib_list[i++];
-  EGLint val = attrib_list[i];
+   for (size_t i = 0; attrib_list[i] != EGL_NONE; i++) {
+  EGLAttrib attr = attrib_list[i++];
+  EGLAttrib val = attrib_list[i];
 
   switch (attr) {
   case EGL_CL_EVENT_HANDLE_KHR:
@@ -92,8 +93,8 @@ _eglParseSyncAttribList64(_EGLSync *sync, const EGLAttrib 
*attrib_list)
   }
 
   if (err != EGL_SUCCESS) {
- _eglLog(_EGL_DEBUG, "bad sync attribute 0x%04x", attr);
- break;
+ _eglLog(_EGL_DEBUG, "bad sync attribute 0x%" PRIxPTR, attr);
+ return err;
   }
}
 
-- 
2.9.0.rc2

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

[Mesa-dev] [PATCH] mesa: etc2 online compression is unsupported, don't attempt it

2016-07-08 Thread Ilia Mirkin

Signed-off-by: Ilia Mirkin 
Cc: "11.2 12.0" 
---

This is sort of pending a question to KHR at

https://www.khronos.org/bugzilla/show_bug.cgi?id=1511

but OTOH, no matter their answer, mesa doesn't have online compression for 
etc2. So we should reject those calls either way.

 src/mesa/main/teximage.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 26a6c21..81e46a1 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1307,6 +1307,7 @@ bool
 _mesa_format_no_online_compression(const struct gl_context *ctx, GLenum format)
 {
return _mesa_is_astc_format(format) ||
+  _mesa_is_etc2_format(format) ||
   compressedteximage_only_format(ctx, format);
 }
 
-- 
2.7.3

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

[Mesa-dev] [PATCH 1/7] glsl: Separate overlapping sentinel nodes in exec_list.

2016-07-08 Thread Matt Turner

I do appreciate the cleverness, but unfortunately it prevents a lot more
cleverness in the form of additional compiler optimizations brought on
by -fstrict-aliasing.

No difference in OglBatch7 (n=20).

Co-authored-by: Davin McCall 
---
I took Ian's suggestion to add get_head_raw() and get_tail_raw() methods
and use them in place of head_sentinel.next and tail_sentinel.prev.

 src/compiler/glsl/ast.h|   4 +-
 src/compiler/glsl/ast_function.cpp |  22 +--
 src/compiler/glsl/ast_to_hir.cpp   |   6 +-
 src/compiler/glsl/ast_type.cpp |   2 +-
 src/compiler/glsl/glsl_parser_extras.cpp   |   6 +-
 src/compiler/glsl/ir.cpp   |   8 +-
 src/compiler/glsl/ir_clone.cpp |   2 +-
 src/compiler/glsl/ir_constant_expression.cpp   |   2 +-
 src/compiler/glsl/ir_function.cpp  |  14 +-
 src/compiler/glsl/ir_reader.cpp|   4 +-
 src/compiler/glsl/ir_validate.cpp  |   4 +-
 src/compiler/glsl/list.h   | 184 -
 src/compiler/glsl/lower_distance.cpp   |   4 +-
 src/compiler/glsl/lower_jumps.cpp  |   2 +-
 src/compiler/glsl/lower_packed_varyings.cpp|   8 +-
 src/compiler/glsl/lower_tess_level.cpp |   4 +-
 src/compiler/glsl/opt_conditional_discard.cpp  |   6 +-
 src/compiler/glsl/opt_dead_builtin_varyings.cpp|   2 +-
 src/compiler/glsl/opt_dead_code.cpp|   2 +-
 src/compiler/glsl/opt_flatten_nested_if_blocks.cpp |   2 +-
 src/compiler/nir/nir.h |   4 +-
 src/compiler/nir/nir_opt_gcm.c |   2 +-
 src/mesa/drivers/dri/i965/brw_cfg.h|   2 +-
 src/mesa/drivers/dri/i965/brw_fs_builder.h |   2 +-
 src/mesa/drivers/dri/i965/brw_vec4_builder.h   |   2 +-
 25 files changed, 164 insertions(+), 136 deletions(-)

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 06c7b03..fa5a731 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -346,8 +346,8 @@ public:
 
bool is_single_dimension() const
{
-  return this->array_dimensions.tail_pred->prev != NULL &&
- this->array_dimensions.tail_pred->prev->is_head_sentinel();
+  return this->array_dimensions.get_tail_raw()->prev != NULL &&
+ this->array_dimensions.get_tail_raw()->is_head_sentinel();
}
 
virtual void print(void) const;
diff --git a/src/compiler/glsl/ast_function.cpp 
b/src/compiler/glsl/ast_function.cpp
index f74394f..9dcec50 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -186,8 +186,8 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
   exec_list _ir_parameters,
   exec_list _ast_parameters)
 {
-   exec_node *actual_ir_node  = actual_ir_parameters.head;
-   exec_node *actual_ast_node = actual_ast_parameters.head;
+   exec_node *actual_ir_node  = actual_ir_parameters.get_head_raw();
+   exec_node *actual_ast_node = actual_ast_parameters.get_head_raw();
 
foreach_in_list(const ir_variable, formal, >parameters) {
   /* The lists must be the same length. */
@@ -318,10 +318,12 @@ verify_parameter_modes(_mesa_glsl_parse_state *state,
const char *func_name = sig->function_name();
bool is_atomic = is_atomic_function(func_name);
if (is_atomic) {
-  const ir_rvalue *const actual = (ir_rvalue *) actual_ir_parameters.head;
+  const ir_rvalue *const actual =
+ (ir_rvalue *) actual_ir_parameters.get_head_raw();
 
   const ast_expression *const actual_ast =
- exec_node_data(ast_expression, actual_ast_parameters.head, link);
+ exec_node_data(ast_expression,
+actual_ast_parameters.get_head_raw(), link);
   YYLTYPE loc = actual_ast->get_location();
 
   if (!verify_first_atomic_parameter(, state,
@@ -1176,7 +1178,7 @@ constant_record_constructor(const glsl_type 
*constructor_type,
 bool
 single_scalar_parameter(exec_list *parameters)
 {
-   const ir_rvalue *const p = (ir_rvalue *) parameters->head;
+   const ir_rvalue *const p = (ir_rvalue *) parameters->get_head_raw();
assert(((ir_rvalue *)p)->as_rvalue() != NULL);
 
return (p->type->is_scalar() && p->next->is_tail_sentinel());
@@ -1220,7 +1222,7 @@ emit_inline_vector_constructor(const glsl_type *type,
 */
const unsigned lhs_components = type->components();
if (single_scalar_parameter(parameters)) {
-  ir_rvalue *first_param = (ir_rvalue *)parameters->head;
+  ir_rvalue *first_param = (ir_rvalue *)parameters->get_head_raw();
   ir_rvalue *rhs = new(ctx) ir_swizzle(first_param, 0, 0, 0, 0,
   lhs_components);
   ir_dereference_variable *lhs = new(ctx) ir_dereference_variable(var);
@@ -1421,7 +1423,7 @@

Re: [Mesa-dev] [PATCH 04/47] clover/llvm: Collect #ifdef mess into a separate file.

2016-07-08 Thread Jan Vesely

On Fri, 2016-07-08 at 14:39 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
> 
> > On Sun, 2016-07-03 at 17:51 -0700, Francisco Jerez wrote:
> > > This gets rid of most ifdef's from the invocation.cpp code --
> > > Only a
> > > couple of them are left which will be removed differently in the
> > > following commits.
> > > 
> > > Reviewed-by: Serge Martin 
> > > ---
> > >  src/gallium/state_trackers/clover/Makefile.sources |   1 +
> > >  src/gallium/state_trackers/clover/llvm/compat.hpp  | 116
> > > +
> > >  .../state_trackers/clover/llvm/invocation.cpp  | 115
> > > +++-
> > >  3 files changed, 157 insertions(+), 75 deletions(-)
> > >  create mode 100644
> > > src/gallium/state_trackers/clover/llvm/compat.hpp
> > > 
> > > diff --git a/src/gallium/state_trackers/clover/Makefile.sources
> > > b/src/gallium/state_trackers/clover/Makefile.sources
> > > index 10bbda0..c4a692b 100644
> > > --- a/src/gallium/state_trackers/clover/Makefile.sources
> > > +++ b/src/gallium/state_trackers/clover/Makefile.sources
> > > @@ -54,6 +54,7 @@ CPP_SOURCES := \
> > >   util/tuple.hpp
> > >  
> > >  LLVM_SOURCES := \
> > > + llvm/compat.hpp \
> > >   llvm/invocation.cpp
> > >  
> > >  TGSI_SOURCES := \
> > > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > > new file mode 100644
> > > index 000..3206f77c
> > > --- /dev/null
> > > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > > @@ -0,0 +1,116 @@
> > > +//
> > > +// Copyright 2016 Francisco Jerez
> > > +//
> > > +// Permission is hereby granted, free of charge, to any person
> > > obtaining a
> > > +// copy of this software and associated documentation files (the
> > > "Software"),
> > > +// to deal in the Software without restriction, including
> > > without limitation
> > > +// the rights to use, copy, modify, merge, publish, distribute,
> > > sublicense,
> > > +// and/or sell copies of the Software, and to permit persons to
> > > whom the
> > > +// Software is furnished to do so, subject to the following
> > > conditions:
> > > +//
> > > +// The above copyright notice and this permission notice shall
> > > be included in
> > > +// all copies or substantial portions of the Software.
> > > +//
> > > +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > KIND, EXPRESS OR
> > > +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > MERCHANTABILITY,
> > > +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > > EVENT SHALL
> > > +// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > > DAMAGES OR
> > > +// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > > OTHERWISE,
> > > +// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
> > > THE USE OR
> > > +// OTHER DEALINGS IN THE SOFTWARE.
> > > +//
> > > +
> > > +///
> > > +/// \file
> > > +/// Some thin wrappers around the Clang/LLVM API used to
> > > preserve
> > > +/// compatibility with older API versions while keeping the
> > > ifdef clutter low
> > > +/// in the rest of the clover::llvm subtree.  In case of an API
> > > break please
> > > +/// consider whether it's possible to preserve backwards
> > > compatibility by
> > > +/// introducing a new one-liner inline function or typedef here
> > > under the
> > > +/// compat namespace in order to keep the running code free from
> > > preprocessor
> > > +/// conditionals.
> > > +///
> > > +
> > > +#ifndef CLOVER_LLVM_COMPAT_HPP
> > > +#define CLOVER_LLVM_COMPAT_HPP
> > > +
> > > +#include "util/algorithm.hpp"
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#if HAVE_LLVM >= 0x0307
> > > +#include 
> > > +#include 
> > > +#else
> > > +#include 
> > > +#include 
> > > +#endif
> > > +
> > > +#include 
> > > +#include 
> > 
> > Have you considered using add push/pop_macro for DEBUG (like srw).
> > TO
> > avoid conflict between llvm's and mesa's DEBUG ?
> > 
> Nope, I haven't.  I don't think any of the LLVM invocation code below
> relies on the DEBUG macro?

we still get 'macro redefined' complains from the compiler. and if
anyone adds ifdef DEBUG code in the future it will cause unexpected
behaviour.
this goes for every file that includes llvm headers. it'd be nicer to
get mesa (and llvm) to stop using generic macro names, but I don't
think that's on anybody's todo list.
it was just a suggestion, feel free to ignore it.

Jan

> 
> > Jan
> > 
> > > +
> > > +namespace clover {
> > > +   namespace llvm {
> > > +  namespace compat {
> > > +#if HAVE_LLVM >= 0x0307
> > > + typedef ::llvm::TargetLibraryInfoImpl
> > > target_library_info;
> > > +#else
> > > + typedef ::llvm::TargetLibraryInfo target_library_info;
> > > +#endif
> > > +
> > > + inline void
> > > + set_lang_defaults(clang::CompilerInvocation ,
> > > +   clang::LangOptions ,
> > > clang::InputKind ik,
> > > +

Re: [Mesa-dev] [PATCH 04/47] clover/llvm: Collect #ifdef mess into a separate file.

2016-07-08 Thread Francisco Jerez

Jan Vesely  writes:

> On Sun, 2016-07-03 at 17:51 -0700, Francisco Jerez wrote:
>> This gets rid of most ifdef's from the invocation.cpp code -- Only a
>> couple of them are left which will be removed differently in the
>> following commits.
>> 
>> Reviewed-by: Serge Martin 
>> ---
>>  src/gallium/state_trackers/clover/Makefile.sources |   1 +
>>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 116 
>> +
>>  .../state_trackers/clover/llvm/invocation.cpp  | 115 
>> +++-
>>  3 files changed, 157 insertions(+), 75 deletions(-)
>>  create mode 100644 src/gallium/state_trackers/clover/llvm/compat.hpp
>> 
>> diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
>> b/src/gallium/state_trackers/clover/Makefile.sources
>> index 10bbda0..c4a692b 100644
>> --- a/src/gallium/state_trackers/clover/Makefile.sources
>> +++ b/src/gallium/state_trackers/clover/Makefile.sources
>> @@ -54,6 +54,7 @@ CPP_SOURCES := \
>>  util/tuple.hpp
>>  
>>  LLVM_SOURCES := \
>> +llvm/compat.hpp \
>>  llvm/invocation.cpp
>>  
>>  TGSI_SOURCES := \
>> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
>> b/src/gallium/state_trackers/clover/llvm/compat.hpp
>> new file mode 100644
>> index 000..3206f77c
>> --- /dev/null
>> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
>> @@ -0,0 +1,116 @@
>> +//
>> +// Copyright 2016 Francisco Jerez
>> +//
>> +// Permission is hereby granted, free of charge, to any person obtaining a
>> +// copy of this software and associated documentation files (the 
>> "Software"),
>> +// to deal in the Software without restriction, including without limitation
>> +// the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> +// and/or sell copies of the Software, and to permit persons to whom the
>> +// Software is furnished to do so, subject to the following conditions:
>> +//
>> +// The above copyright notice and this permission notice shall be included 
>> in
>> +// all copies or substantial portions of the Software.
>> +//
>> +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> +// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> +// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> +// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> +// OTHER DEALINGS IN THE SOFTWARE.
>> +//
>> +
>> +///
>> +/// \file
>> +/// Some thin wrappers around the Clang/LLVM API used to preserve
>> +/// compatibility with older API versions while keeping the ifdef clutter 
>> low
>> +/// in the rest of the clover::llvm subtree.  In case of an API break please
>> +/// consider whether it's possible to preserve backwards compatibility by
>> +/// introducing a new one-liner inline function or typedef here under the
>> +/// compat namespace in order to keep the running code free from 
>> preprocessor
>> +/// conditionals.
>> +///
>> +
>> +#ifndef CLOVER_LLVM_COMPAT_HPP
>> +#define CLOVER_LLVM_COMPAT_HPP
>> +
>> +#include "util/algorithm.hpp"
>> +
>> +#include 
>> +#include 
>> +
>> +#if HAVE_LLVM >= 0x0307
>> +#include 
>> +#include 
>> +#else
>> +#include 
>> +#include 
>> +#endif
>> +
>> +#include 
>> +#include 
>
> Have you considered using add push/pop_macro for DEBUG (like srw). TO
> avoid conflict between llvm's and mesa's DEBUG ?
>
Nope, I haven't.  I don't think any of the LLVM invocation code below
relies on the DEBUG macro?

> Jan
>
>> +
>> +namespace clover {
>> +   namespace llvm {
>> +  namespace compat {
>> +#if HAVE_LLVM >= 0x0307
>> + typedef ::llvm::TargetLibraryInfoImpl target_library_info;
>> +#else
>> + typedef ::llvm::TargetLibraryInfo target_library_info;
>> +#endif
>> +
>> + inline void
>> + set_lang_defaults(clang::CompilerInvocation ,
>> +   clang::LangOptions , clang::InputKind ik,
>> +   const ::llvm::Triple ,
>> +   clang::PreprocessorOptions ,
>> +   clang::LangStandard::Kind std) {
>> +#if HAVE_LLVM >= 0x0309
>> +inv.setLangDefaults(lopts, ik, t, ppopts, std);
>> +#else
>> +inv.setLangDefaults(lopts, ik, std);
>> +#endif
>> + }
>> +
>> + inline void
>> + add_link_bitcode_file(clang::CodeGenOptions ,
>> +   const std::string ) {
>> +#if HAVE_LLVM >= 0x0308
>> +opts.LinkBitcodeFiles.emplace_back(::llvm::Linker::Flags::None, 
>> path);
>> +#else
>> +opts.LinkBitcodeFile = path;
>> +#endif
>> + }
>> +
>> +#if HAVE_LLVM >= 0x0307
>> + typedef ::llvm::legacy::PassManager pass_manager;
>> +#else
>> + typedef ::llvm::PassManager pass_manager;
>> +#endif
>> +

Re: [Mesa-dev] [PATCH 04/47] clover/llvm: Collect #ifdef mess into a separate file.

2016-07-08 Thread Jan Vesely

On Sun, 2016-07-03 at 17:51 -0700, Francisco Jerez wrote:
> This gets rid of most ifdef's from the invocation.cpp code -- Only a
> couple of them are left which will be removed differently in the
> following commits.
> 
> Reviewed-by: Serge Martin 
> ---
>  src/gallium/state_trackers/clover/Makefile.sources |   1 +
>  src/gallium/state_trackers/clover/llvm/compat.hpp  | 116 
> +
>  .../state_trackers/clover/llvm/invocation.cpp  | 115 +++-
>  3 files changed, 157 insertions(+), 75 deletions(-)
>  create mode 100644 src/gallium/state_trackers/clover/llvm/compat.hpp
> 
> diff --git a/src/gallium/state_trackers/clover/Makefile.sources 
> b/src/gallium/state_trackers/clover/Makefile.sources
> index 10bbda0..c4a692b 100644
> --- a/src/gallium/state_trackers/clover/Makefile.sources
> +++ b/src/gallium/state_trackers/clover/Makefile.sources
> @@ -54,6 +54,7 @@ CPP_SOURCES := \
>   util/tuple.hpp
>  
>  LLVM_SOURCES := \
> + llvm/compat.hpp \
>   llvm/invocation.cpp
>  
>  TGSI_SOURCES := \
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> new file mode 100644
> index 000..3206f77c
> --- /dev/null
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -0,0 +1,116 @@
> +//
> +// Copyright 2016 Francisco Jerez
> +//
> +// Permission is hereby granted, free of charge, to any person obtaining a
> +// copy of this software and associated documentation files (the "Software"),
> +// to deal in the Software without restriction, including without limitation
> +// the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +// and/or sell copies of the Software, and to permit persons to whom the
> +// Software is furnished to do so, subject to the following conditions:
> +//
> +// The above copyright notice and this permission notice shall be included in
> +// all copies or substantial portions of the Software.
> +//
> +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +// OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +// OTHER DEALINGS IN THE SOFTWARE.
> +//
> +
> +///
> +/// \file
> +/// Some thin wrappers around the Clang/LLVM API used to preserve
> +/// compatibility with older API versions while keeping the ifdef clutter low
> +/// in the rest of the clover::llvm subtree.  In case of an API break please
> +/// consider whether it's possible to preserve backwards compatibility by
> +/// introducing a new one-liner inline function or typedef here under the
> +/// compat namespace in order to keep the running code free from preprocessor
> +/// conditionals.
> +///
> +
> +#ifndef CLOVER_LLVM_COMPAT_HPP
> +#define CLOVER_LLVM_COMPAT_HPP
> +
> +#include "util/algorithm.hpp"
> +
> +#include 
> +#include 
> +
> +#if HAVE_LLVM >= 0x0307
> +#include 
> +#include 
> +#else
> +#include 
> +#include 
> +#endif
> +
> +#include 
> +#include 

Have you considered using add push/pop_macro for DEBUG (like srw). TO
avoid conflict between llvm's and mesa's DEBUG ?

Jan

> +
> +namespace clover {
> +   namespace llvm {
> +  namespace compat {
> +#if HAVE_LLVM >= 0x0307
> + typedef ::llvm::TargetLibraryInfoImpl target_library_info;
> +#else
> + typedef ::llvm::TargetLibraryInfo target_library_info;
> +#endif
> +
> + inline void
> + set_lang_defaults(clang::CompilerInvocation ,
> +   clang::LangOptions , clang::InputKind ik,
> +   const ::llvm::Triple ,
> +   clang::PreprocessorOptions ,
> +   clang::LangStandard::Kind std) {
> +#if HAVE_LLVM >= 0x0309
> +inv.setLangDefaults(lopts, ik, t, ppopts, std);
> +#else
> +inv.setLangDefaults(lopts, ik, std);
> +#endif
> + }
> +
> + inline void
> + add_link_bitcode_file(clang::CodeGenOptions ,
> +   const std::string ) {
> +#if HAVE_LLVM >= 0x0308
> +opts.LinkBitcodeFiles.emplace_back(::llvm::Linker::Flags::None, 
> path);
> +#else
> +opts.LinkBitcodeFile = path;
> +#endif
> + }
> +
> +#if HAVE_LLVM >= 0x0307
> + typedef ::llvm::legacy::PassManager pass_manager;
> +#else
> + typedef ::llvm::PassManager pass_manager;
> +#endif
> +
> + inline void
> + add_data_layout_pass(pass_manager ) {
> +#if HAVE_LLVM < 0x0307
> +pm.add(new ::llvm::DataLayoutPass());
> +#endif
> + }
> +
> + inline void
> + add_internalize_pass(pass_manager ,
> +  const

[Mesa-dev] [PATCH] EGL: Combine the GL and GLES current contexts.

2016-07-08 Thread Kyle Brenneman

Only keep track of a single current context, instead of separate contexts for
GL and GLES.

In EGL 1.4 (and 1.5), EGL_OPENGL_API and EGL_OPENGL_ES_API are supposed to be
interchangeable for all purposes except for eglCreateContext.

The _EGLThreadInfo::CurrentContexts array is now a single pointer to the
current context, which may be a GL or GLES context. In addition, it now keeps
track of the current API as an enum instead of an index.

eglMakeCurrent will now replace the current context, regardless of which client
API is used for for the current and new contexts. It no longer checks for a
conflicting context. In addition, calling eglMakeCurrent with EGL_NO_CONTEXT
will now release the current context regardless of the current API.
---
 src/egl/main/eglapi.c | 42 --
 src/egl/main/eglcontext.c | 31 ---
 src/egl/main/eglcurrent.c | 15 ++-
 src/egl/main/eglcurrent.h | 39 +++
 4 files changed, 21 insertions(+), 106 deletions(-)

diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 4700dbe..df2dcd6 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -1088,18 +1088,8 @@ eglWaitClient(void)
 EGLBoolean EGLAPIENTRY
 eglWaitGL(void)
 {
-   _EGLThreadInfo *t = _eglGetCurrentThread();
-   EGLint api_index = t->CurrentAPIIndex;
-   EGLint es_index = _eglConvertApiToIndex(EGL_OPENGL_ES_API);
-   EGLBoolean ret;
-
-   if (api_index != es_index && _eglIsCurrentThreadDummy())
-  RETURN_EGL_ERROR(NULL, EGL_BAD_ALLOC, EGL_FALSE);
-
-   t->CurrentAPIIndex = es_index;
-   ret = eglWaitClient();
-   t->CurrentAPIIndex = api_index;
-   return ret;
+   /* Since we only support OpenGL and GLES, eglWaitGL is equivalent to 
eglWaitClient. */
+   return eglWaitClient();
 }
 
 
@@ -1222,7 +1212,7 @@ eglBindAPI(EGLenum api)
if (!_eglIsApiValid(api))
   RETURN_EGL_ERROR(NULL, EGL_BAD_PARAMETER, EGL_FALSE);
 
-   t->CurrentAPIIndex = _eglConvertApiToIndex(api);
+   t->CurrentAPI = api;
 
RETURN_EGL_SUCCESS(NULL, EGL_TRUE);
 }
@@ -1238,7 +1228,7 @@ eglQueryAPI(void)
EGLenum ret;
 
/* returns one of EGL_OPENGL_API, EGL_OPENGL_ES_API or EGL_OPENVG_API */
-   ret = _eglConvertApiFromIndex(t->CurrentAPIIndex);
+   ret = t->CurrentAPI;
 
RETURN_EGL_SUCCESS(NULL, ret);
 }
@@ -1271,25 +1261,17 @@ eglReleaseThread(void)
/* unbind current contexts */
if (!_eglIsCurrentThreadDummy()) {
   _EGLThreadInfo *t = _eglGetCurrentThread();
-  EGLint api_index = t->CurrentAPIIndex;
-  EGLint i;
-
-  for (i = 0; i < _EGL_API_NUM_APIS; i++) {
- _EGLContext *ctx = t->CurrentContexts[i];
- if (ctx) {
-_EGLDisplay *disp = ctx->Resource.Display;
-_EGLDriver *drv;
 
-t->CurrentAPIIndex = i;
+  _EGLContext *ctx = t->CurrentContext;
+  if (ctx) {
+ _EGLDisplay *disp = ctx->Resource.Display;
+ _EGLDriver *drv;
 
-mtx_lock(>Mutex);
-drv = disp->Driver;
-(void) drv->API.MakeCurrent(drv, disp, NULL, NULL, NULL);
-mtx_unlock(>Mutex);
- }
+ mtx_lock(>Mutex);
+ drv = disp->Driver;
+ (void) drv->API.MakeCurrent(drv, disp, NULL, NULL, NULL);
+ mtx_unlock(>Mutex);
   }
-
-  t->CurrentAPIIndex = api_index;
}
 
_eglDestroyCurrentThread();
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index ae19862..ebc004d 100644
--- a/src/egl/main/eglcontext.c
+++ b/src/egl/main/eglcontext.c
@@ -557,20 +557,16 @@ _eglQueryContext(_EGLDriver *drv, _EGLDisplay *dpy, 
_EGLContext *c,
 static _EGLContext *
 _eglBindContextToThread(_EGLContext *ctx, _EGLThreadInfo *t)
 {
-   EGLint apiIndex;
_EGLContext *oldCtx;
 
-   apiIndex = (ctx) ?
-  _eglConvertApiToIndex(ctx->ClientAPI) : t->CurrentAPIIndex;
-
-   oldCtx = t->CurrentContexts[apiIndex];
+   oldCtx = t->CurrentContext;
if (ctx != oldCtx) {
   if (oldCtx)
  oldCtx->Binding = NULL;
   if (ctx)
  ctx->Binding = t;
 
-  t->CurrentContexts[apiIndex] = ctx;
+  t->CurrentContext = ctx;
}
 
return oldCtx;
@@ -585,7 +581,6 @@ _eglCheckMakeCurrent(_EGLContext *ctx, _EGLSurface *draw, 
_EGLSurface *read)
 {
_EGLThreadInfo *t = _eglGetCurrentThread();
_EGLDisplay *dpy;
-   EGLint conflict_api;
 
if (_eglIsCurrentThreadDummy())
   return _eglError(EGL_BAD_ALLOC, "eglMakeCurrent");
@@ -617,13 +612,11 @@ _eglCheckMakeCurrent(_EGLContext *ctx, _EGLSurface *draw, 
_EGLSurface *read)
if (ctx->Binding && ctx->Binding != t)
   return _eglError(EGL_BAD_ACCESS, "eglMakeCurrent");
if (draw && draw->CurrentContext && draw->CurrentContext != ctx) {
-  if (draw->CurrentContext->Binding != t ||
-  draw->CurrentContext->ClientAPI != ctx->ClientAPI)
+  if (draw->CurrentContext->Binding != t)
  return _eglError(EGL_BAD_ACCESS, "eglMakeCurrent");
}
if (read &&

[Mesa-dev] [Bug 61907] Indirect rendering of multi-texture vertex arrays broken

2016-07-08 Thread bugzilla-daemon

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

Matt Turner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Matt Turner  ---
I've pushed four patches, beginning with commit d57c85c1bf77f194720a that
resolve this bug.

Colin, thank you very much for tracking this down and fixing it. Sorry it took
so long for someone else to notice it.

In the future, it would make others' lives easier if you attached a real patch.
I had to check out Mesa from the date you mentioned, untar the files over the
existing ones, make a commit, and then rebase forward multiple years.

The next major release of Mesa will contain the fixes, which I expect will be
12.1 or 13.0 depending on how GL support progresses. We could probably
cherry-pick them to older stable branches if that is useful.

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

Re: [Mesa-dev] [PATCH 3/6] i965/fs/gen7: split instructions that run into exec masking bugs

2016-07-08 Thread Francisco Jerez

Iago Toral  writes:

> On Thu, 2016-07-07 at 19:36 -0700, Francisco Jerez wrote:
>> Samuel Iglesias Gonsálvez  writes:
>> 
>> > 
>> > From: Iago Toral Quiroga 
>> > 
>> > In fp64 we can produce code like this:
>> > 
>> > mov(16) vgrf2<2>:UD, vgrf3<2>:UD
>> > 
>> > That our simd lowering pass would typically split in instructions
>> > with a
>> > width of 8, writing to two consecutive registers each.
>> > Unfortunately, gen7
>> > hardware has a bug affecting execution masking and as a result, the
>> > second GRF register write won't work properly. Curro verified this:
>> > 
>> > "The problem is that pre-Gen8 EUs are hardwired to use the
>> > QtrCtrl+1
>> >  (where QtrCtrl is the 8-bit quarter of the execution mask signals
>> >  specified in the instruction control fields) for the second
>> >  compressed half of any single-precision instruction (for
>> >  double-precision instructions it's hardwired to use NibCtrl+1),
>> >  which means that the EU will apply the wrong execution controls
>> >  for the second sequential GRF write if the number of channels per
>> >  GRF is not exactly eight in single-precision mode (or four in
>> >  double-float mode)."
>> > 
>> > In practice, this means that we cannot write more than one
>> > consecutive GRF in a single instruction if the number of channels
>> > per GRF is not exactly eight in single-precision mode (or four
>> > in double-float mode).
>> > 
>> > This patch makes our SIMD lowering pass split this kind of
>> > instructions
>> > so that the split versions only write to a single register. In the
>> > example above this means that we split the write in 4 instructions,
>> > each
>> > one writing 4 UD elements (width = 4) to a single register.
>> > ---
>> >  src/mesa/drivers/dri/i965/brw_fs.cpp | 20 
>> >  1 file changed, 20 insertions(+)
>> > 
>> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > index 2f473cc..caf88d1 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > @@ -4677,6 +4677,26 @@ static unsigned
>> >  get_fpu_lowered_simd_width(const struct brw_device_info *devinfo,
>> > const fs_inst *inst)
>> >  {
>> > +   /* Pre-Gen8 EUs are hardwired to use the QtrCtrl+1 (where
>> > QtrCtrl is
>> > +* the 8-bit quarter of the execution mask signals specified in
>> > the
>> > +* instruction control fields) for the second compressed half
>> > of any
>> > +* single-precision instruction (for double-precision
>> > instructions
>> > +* it's hardwired to use NibCtrl+1), which means that the EU
>> > will
>> When I found out the hardware issue you describe in this comment I
>> only
>> had a HSW at hand, so I looked into this again today in order to
>> verify
>> whether IVB/VLV behave in the same way, and I'm afraid they
>> don't...  I
>> haven't tried it on real IVB hardware, but at least the simulator
>> behaves the same as HSW for single precision execution types, while
>> for
>> double precision types instruction decompression seems to be
>> completely
>> busted.  AFAICT it applies the same channel enable signals to both
>> halves of the compressed instruction which will be just wrong under
>> non-uniform control flow.  Can you clarify in the comment above that
>> the
>> text in parentheses referring to double-precision instructions may
>> only
>> apply to HSW?
>
> Sure.
>
>> Have you been able to get any of the FP64 non-uniform control flow
>> tests
>> to pass on IVB?  If you have I guess this may be a simulator-only
>> bug,
>> although I'm not sure the FS tests you have written will be non-
>> uniform
>> enough to reproduce the issue.  If you haven't, we may have to add
>> another check here in order to lower all non-force_writemask_all DF
>> instructions to SIMD4 on IVB/VLV...  :(
>
> For now we have focused on HSW only but thanks for the update regarding
> IVB. I'll make sure to pay special attention to non-uniform control-
> flow cases there when we start testing things there (we intend to start
> putting effort on IVB in the next days).
>
> I suppose that for now we can leave this patch as gen7 specific (rather
> than HSW specific) and fix it up if needed for IVB when we actually
> verify that it needs extra work there. Does that sound like a good
> plan?
>
Sure.

>> > 
>> > +* apply the wrong execution controls for the second sequential
>> > GRF
>> > +* write if the number of channels per GRF is not exactly eight
>> > in
>> > +* single-precision mode (or four in double-float mode).
>> > +*
>> > +* In this situation we calculate the maximum size of the split
>> > +* instructions so they only ever write to a single register.
>> > +*/
>> > +   unsigned type_size = type_sz(inst->dst.type);
>> > +   unsigned channels_per_grf = inst->exec_size / inst-
>> > >regs_written;
>> This will cause a division by zero if the

[Mesa-dev] [Bug 96865] [swrast] egl-create-pbuffer-surface regression

2016-07-08 Thread bugzilla-daemon

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

Bug ID: 96865
   Summary: [swrast] egl-create-pbuffer-surface regression
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: chad.vers...@intel.com

mesa: a0bf1768c7131a5d9a23c5177e7b9d7a0267ef6c (12.1.0-devel)

$ ./bin/egl-create-pbuffer-surface -auto
Segmentation fault (core dumped)

(gdb) bt
#0  __memcpy_avx_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:238
#1  0x7ff000483961 in memcpy (__len=262144, __src=,
__dest=0x0) at /usr/include/x86_64-linux-gnu/bits/string3.h:53
#2  swrastGetImage (read=, x=, y=,
w=, h=, data=0x0, 
loaderPrivate=0x1b00a60) at drivers/dri2/platform_x11.c:179
#3  0x7feffb11e65c in swrastSetTexBuffer2 (pDRICtx=,
target=, texture_format=8410, dPriv=0x1aef960)
at swrast.c:110
#4  0x7ff00047feb2 in dri2_bind_tex_image (drv=0x1937c10, disp=0x19375d0,
surf=0x1b00a60, buffer=12420) at drivers/dri2/egl_dri2.c:1452
#5  0x7ff000475dff in eglBindTexImage (dpy=0x19375d0, surface=, buffer=12420) at main/eglapi.c:944
#6  0x004024d2 in draw (state=0x7fff00df85c0) at
piglit/tests/egl/egl-create-pbuffer-surface.c:64
#7  0x00401d12 in event_loop (state=0x7fff00df85c0,
test=0x7fff00df8650) at piglit/tests/egl/egl-util.c:158
#8  0x004022ae in egl_util_run (test=0x7fff00df8650, argc=2,
argv=0x7fff00df8788)
at piglit/tests/egl/egl-util.c:299
#9  0x004026b1 in main (argc=2, argv=0x7fff00df8788) at
piglit/tests/egl/egl-create-pbuffer-surface.c:100
(gdb) frame 2
#2  swrastGetImage (read=, x=, y=,
w=, h=, data=0x0, 
loaderPrivate=0x1b00a60) at drivers/dri2/platform_x11.c:179
179   memcpy(data, idata, bytes);
(gdb) print data
$1 = 0x0
(gdb) print idata
$2 = 
(gdb) print bytes
$3 = 262144



9fea9d6f8e862a8b3f569d37d06d1ff69c6e18f5 is the first bad commit
commit 9fea9d6f8e862a8b3f569d37d06d1ff69c6e18f5
Author: Guillaume Charifi 
Date:   Mon Jun 20 15:27:33 2016 +0200

egl: Fix the bad surface attributes combination checking for pbuffers. (v3)

Fixes a regression induced by commit
a0674ce5c41903ccd161e89abb149621bfbc40d2:
When EGL_TEXTURE_FORMAT and EGL_TEXTURE_TARGET were both specified (and
both != EGL_NO_TEXTURE), an error was instantly triggered, before the
other one had even a chance to be checked, which is obviously not the
intended behaviour.

v2: Full commit hash, remove useless variables.
v3: [chadv] Add Fixes footers.

Fixes: piglit "spec/egl 1.4/eglcreatepbuffersurface and then glclear"
Fixes: piglit "spec/egl 1.4/largest possible eglcreatepbuffersurface and
then glclear"
Signed-off-by: Guillaume Charifi 
Reviewed-by: Frank Binns 
Reviewed-by: Chad Versace 

:04 04 3c833d0cdcb72af089cc2a777d4e782db0f51646
a851d5bcedb1fe8dd95b0a173cfaacdf19ea1025 M  src
bisect run success

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

[Mesa-dev] [Bug 96765] BindFragDataLocationIndexed on array fragment shader output.

2016-07-08 Thread bugzilla-daemon

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

Corentin Wallez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Corentin Wallez  ---
Mesa 12.0 with your patch applied fixes all the remaining failures in the
relevant Chromium tests.

There's still one failure but it is trying to set FragData[0] = 2 and
FragData[1] = 1 which is invalid given the discussion in the Khronos bug
tracker. I'll fix this on our side.

Thank you again for fixing this!

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

Re: [Mesa-dev] [PATCH v3] i965: intel_texture_barrier reimplemented

2016-07-08 Thread Alejandro Piñeiro

Forget the previous email. It was an error on the test. The texture
barrier works fine.

Sorry for the noise.

BR

On 08/07/16 15:58, Alejandro Piñeiro wrote:
> Hi, today I was updating the piglit test, as I got a detailed review.
> While testing the changes, I found that there are some parameters
> combinations that are still not passing. They are related to the number
> of draw passes (or in other words, the number of glDrawElements calls
> for the same vertices). So I added more combinations on the piglit
> patch. Before it was testing with 1 and 8 drawing passes. But I added
> the cases of 2, 3 and 4 drawing passes.
>
> So:
>   * v3 version of the piglit patch includes 48 parameter combinations of
> the same test. All passing with current master.
>   * v5 version (the one committed [1]) includes 144 parameter
> combinations. 40 are failing.
>
> Just as a quick test, I tried the old version of the mesa fix,
> consisting on a combination of gen7_emit_cs_stall_flush +
> brw_emit_mi_flush (that was called as a "big hammer"), and still have 40
> subtests not passing.
>
> I will start to look to this problem, but any idea/feedback to get it
> solved would be welcome.
>
> BR
>
> [1]
> https://cgit.freedesktop.org/piglit/commit/?id=8cb75a1bc1cbdec0e0c8f9a9b10631a369df2f5b
>
> On 30/06/16 23:16, Francisco Jerez wrote:
>> Alejandro Piñeiro  writes:
>>
>>> Fixes:
>>> GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
>>>
>>> On Haswell, Broadwell and Skylake (note that in order to execute that
>>> test, it is needed to override GL and GLSL versions).
>>>
>>> On gen6 this test was already working without this change. It keeps
>>> working after it.
>>>
>>> This commit replaces the call to brw_emit_mi_flush for gen6+ with two
>>> calls to brw_emit_pipe_control_flush:
>>>
>>>  * The first one with RENDER_TARGET_FLUSH and CS_STALL set to initiate
>>>a render cache flush after any concurrent rendering completes and
>>>cause the CS to stop parsing commands until the render cache
>>>becomes coherent with memory.
>>>
>>>  * The second one have TEXTURE_CACHE_INVALIDATE set (and no CS stall)
>>>to clean up any stale data from the sampler caches before rendering
>>>continues.
>>>
>>> Didn't touch gen4-5, basically because I don't have a way to test
>>> them.
>>>
>>> More info on commits:
>>> 0aa4f99f562a05880a779707cbcd46be459863bf
>>> 72473658c51d5e074ce219c1e6385a4cce29f467
>>>
>>> Thanks to Curro to help to tracking this down, as the root case was a
>>> hw race condition.
>>>
>>> v2: use two calls to pipe_control_flush instead of a combination of
>>> gen7_emit_cs_stall_flush and brw_emit_mi_flush calls (Curro)
>>> v3: no need to const cache invalidation (Curro)
>>> ---
>>>
>>> FWIW: checked with the CTS tests, and the piglit series, and confirmed
>>> that the const cache invalidation is not needed.
>>>
>>>  src/mesa/drivers/dri/i965/intel_tex.c | 21 -
>>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
>>> b/src/mesa/drivers/dri/i965/intel_tex.c
>>> index cac33ac..a802d5a 100644
>>> --- a/src/mesa/drivers/dri/i965/intel_tex.c
>>> +++ b/src/mesa/drivers/dri/i965/intel_tex.c
>>> @@ -9,6 +9,7 @@
>>>  #include "intel_mipmap_tree.h"
>>>  #include "intel_tex.h"
>>>  #include "intel_fbo.h"
>>> +#include "intel_reg.h"
>>>  
>>>  #define FILE_DEBUG_FLAG DEBUG_TEXTURE
>>>  
>>> @@ -362,7 +363,25 @@ intel_texture_barrier(struct gl_context *ctx)
>>>  {
>>> struct brw_context *brw = brw_context(ctx);
>>>  
>>> -   brw_emit_mi_flush(brw);
>>> +   if (brw->gen >= 6) {
>>> +  if (brw->gen == 6) {
>>> + /* [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache
>>> +  * Flush Enable = 1, a PIPE_CONTROL with any non-zero
>>> +  * post-sync-op is required.
>>> +  */
>>> + brw_emit_post_sync_nonzero_flush(brw);
>>> +  }
>>> +
>>> +  brw_emit_pipe_control_flush(brw,
>>> +  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
>>> +  PIPE_CONTROL_RENDER_TARGET_FLUSH |
>>> +  PIPE_CONTROL_CS_STALL);
>>> +
>>> +  brw_emit_pipe_control_flush(brw,
>>> +  PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
>>> +   } else {
>>> +  brw_emit_mi_flush(brw);
>>> +   }
>> Looks reasonable to me, let's get this bug fixed on master, things can
>> be refactored later on:
>>
>> Reviewed-by: Francisco Jerez 
>>
>>>  }
>>>  
>>>  void
>>> -- 
>>> 2.7.4
>




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

Re: [Mesa-dev] [PATCH RFC 1/1] r600, compute: Use vtx #3 for kernel arguments

2016-07-08 Thread Jan Vesely

ping.

is there any other way to get dynamic indices working?

Jan


On Sun, 2016-06-26 at 20:40 -0400, Jan Vesely wrote:
> Both explicit and implicit.
> Using vtx 0 (as existing llvm code implies) does not work for dynamic
> offsets.
> 
> Signed-off-by: Jan Vesely 
> ---
> Hi,
> 
> I ran into problem when using VTX_READ from constant buffer would
> work only for 0 index. The LLVM code implied that it should work (or
> maybe they considered constant offsets only), but I could not find
> one way or the other in ISA docs.
> 
> Switching to vtx#3 fixed the problem, though I'm not sure if it's the
> right solution.
> 
> thanks,
> Jan
> 
> 
>  src/gallium/drivers/r600/evergreen_compute.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c
> b/src/gallium/drivers/r600/evergreen_compute.c
> index 7f9580c..b351cee 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -369,6 +369,8 @@ static void evergreen_compute_upload_input(struct
> pipe_context *ctx,
>   ctx->transfer_unmap(ctx, transfer);
>  
>   /* ID=0 is reserved for the parameters */
> + evergreen_cs_set_vertex_buffer(rctx, 3, 0,
> + (struct pipe_resource*)shader-
> >kernel_param);
>   evergreen_cs_set_constant_buffer(rctx, 0, 0, input_size,
>   (struct pipe_resource*)shader-
> >kernel_param);
>  }
> @@ -614,9 +616,9 @@ static void
> evergreen_set_compute_resources(struct pipe_context *ctx,
>   start, count);
>  
>   for (unsigned i = 0; i < count; i++) {
> - /* The First three vertex buffers are reserved for
> parameters and
> + /* The First four vertex buffers are reserved for
> parameters and
>    * global buffers. */
> - unsigned vtx_id = 3 + i;
> + unsigned vtx_id = 4 + i;
>   if (resources[i]) {
>   struct r600_resource_global *buffer =
>   (struct r600_resource_global*)
-- 

Jan Vesely 

signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: set _NEW_BUFFERS when updating texture bound to current buffers

2016-07-08 Thread Ilia Mirkin

When a glTexImage call updates the parameters of a currently bound
framebuffer, we might miss out on revalidating whether it is complete.
Make sure to set _NEW_BUFFERS which will trigger the revalidation in
that case.

Also while we're at it, fix the fb parameter passed in to the eventual
RenderTexture call.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94148
Signed-off-by: Ilia Mirkin 
Cc: "11.2 12.0" 
---
 src/mesa/main/teximage.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 26a6c21..a97815f 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2605,10 +2605,16 @@ check_rtt_cb(GLuint key, void *data, void *userData)
  att->Texture == texObj &&
  att->TextureLevel == level &&
  att->CubeMapFace == face) {
-_mesa_update_texture_renderbuffer(ctx, ctx->DrawBuffer, att);
+_mesa_update_texture_renderbuffer(ctx, fb, att);
 assert(att->Renderbuffer->TexImage);
 /* Mark fb status as indeterminate to force re-validation */
 fb->_Status = 0;
+
+/* Make sure that the revalidation actually happens if this is
+ * being done to currently-bound buffers.
+ */
+if (fb == ctx->DrawBuffer || fb == ctx->ReadBuffer)
+   ctx->NewState |= _NEW_BUFFERS;
  }
   }
}
-- 
2.7.3

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

[Mesa-dev] [PATCH] radeonsi: fix bad assertion in si_emit_sample_mask

2016-07-08 Thread Nicolai Hähnle

From: Nicolai Hähnle 

The blitter sets mask == 1, which is fine since it doesn't use smoothing.
Fixes a regression introduced in commit 5bcfbf91.
---
 src/gallium/drivers/radeonsi/si_state.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state.c 
b/src/gallium/drivers/radeonsi/si_state.c
index df6b610..bdd7ef4 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3197,7 +3197,8 @@ static void si_emit_sample_mask(struct si_context *sctx, 
struct r600_atom *atom)
 * small primitive filter. We expect the state tracker to take care of
 * this for us.
 */
-   assert(mask == 0x || sctx->framebuffer.nr_samples > 1);
+   assert(mask == 0x || sctx->framebuffer.nr_samples > 1 ||
+  (mask & 1 && sctx->blitter->running));
 
radeon_set_context_reg_seq(cs, R_028C38_PA_SC_AA_MASK_X0Y0_X1Y0, 2);
radeon_emit(cs, mask | (mask << 16));
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] meta/texsubimage: tex_image is always non-null, avoid confusing code

2016-07-08 Thread Eric Engestrom

On Fri, Jul 08, 2016 at 12:35:11PM -0400, Ilia Mirkin wrote:
> Probably a copy-paste from mesa_meta_pbo_GetTexSubImage where tex_image
> may apparently be null.
> 
> Signed-off-by: Ilia Mirkin 

Indeed, tex_image is dereferenced 30 lines before, so at this point it
can't be null anymore.
Reviewed-by: Eric Engestrom 

> ---
> 
> Happened upon this when trying to figure out the "incomplete fbo" issue.
> 
>  src/mesa/drivers/common/meta_tex_subimage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
> b/src/mesa/drivers/common/meta_tex_subimage.c
> index 988af91..703efcd 100644
> --- a/src/mesa/drivers/common/meta_tex_subimage.c
> +++ b/src/mesa/drivers/common/meta_tex_subimage.c
> @@ -235,7 +235,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint 
> dims,
> if (drawFb == NULL)
>goto fail;
>  
> -   _mesa_bind_framebuffers(ctx, drawFb, tex_image ? readFb : 
> ctx->ReadBuffer);
> +   _mesa_bind_framebuffers(ctx, drawFb, readFb);
>  
> if (tex_image->TexObject->Target == GL_TEXTURE_1D_ARRAY) {
>assert(depth == 1);
> -- 
> 2.7.3
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meta/texsubimage: tex_image is always non-null, avoid confusing code

2016-07-08 Thread Ilia Mirkin

Probably a copy-paste from mesa_meta_pbo_GetTexSubImage where tex_image
may apparently be null.

Signed-off-by: Ilia Mirkin 
---

Happened upon this when trying to figure out the "incomplete fbo" issue.

 src/mesa/drivers/common/meta_tex_subimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 988af91..703efcd 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -235,7 +235,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint 
dims,
if (drawFb == NULL)
   goto fail;
 
-   _mesa_bind_framebuffers(ctx, drawFb, tex_image ? readFb : ctx->ReadBuffer);
+   _mesa_bind_framebuffers(ctx, drawFb, readFb);
 
if (tex_image->TexObject->Target == GL_TEXTURE_1D_ARRAY) {
   assert(depth == 1);
-- 
2.7.3

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

Re: [Mesa-dev] [PATCH 00/12] render reordering for optimized tile buffer usage

2016-07-08 Thread Rob Clark

On Sat, Jul 2, 2016 at 12:52 PM, Rob Clark  wrote:
> So, games/apps that are aware of how a tiler gpu works will make an
> effort to avoid mid-batch (tile pass) updates to textures, UBOs, etc,
> since this will force a flush, and extra resolve (tile->mem) and
> restore (mem->tile) in the next batch.  They also avoid unnecessary
> framebuffer switches, for the same reason.
>
> But turns out that many games, benchmarks, etc, aren't very good at
> this.  But what if we could re-order the batches (and potentially
> shadow texture/UBO/etc resources) to minimize the tile passes and
> unnecessary resolve/restore?
>
> This is based on a rough idea that Eric suggested a while back, and
> a few other experiments that I have been trying recently.  It boils
> down to three parts:
>
> 1) Add an fd_batch object, which tracks cmdstream being built for that
>particular tile pass.  State that is global to the tile pass is
>move from fd_context to fd_batch.  (Mostly the framebuffer state,
>but also so internal tracking that is done to decide whether to
>use GMEM or sysmem/bypass mode, etc.)
>
>Tracking of resources written/read in the batch is also moved from
>ctx to batch.

So, it turned out that tracking only the most recent batch that reads
a resource leads to unnecessary dependencies, and results in batches
getting force-flushed (to avoid a dependency loop) when otherwise not
needed.

I initially did things this way so I could have a single list_head in
the pipe_resource, and to avoid needing to track a 'struct set' of
batches per pipe_resource.  But we really need a way to allow tracking
of multiple batches that read a resource without introducing an
artificial dependency between the reading batches.

So I came up with a different approach after discussing a few
different options with glisse.  It involves putting an upper bound on
the # of batches at 32 (although 64 would be a possibility).  In the
batch, we end up needing a hash-set to track resources accessed by the
batch.  But in the resource we only need a bitmask of which batches
access this resource (and a single 'struct fd_batch *write_batch' for
most recent writer).  (And I check the bitmask to short-circuit the
hashset lookup/insert in the common case.)

So now I'm getting ~+20% on manhattan, and a bit more improvement in
xonotic than before.  There are still a few glitches in xonotic (the
increased re-ordering exposes that occlusion query is completely
broken and queries need some work to dtrt in the face of re-ordering).
And the map in the upper left corner somehow doesn't show the
outline/map of the level (just the dots where the players are at).
Not sure yet what is going on there.

Mostly I only hit forced flushes due to hitting upper limit on # of
batches during game startup, when it is doing a lot of texture uploads
and mipmap generation, but not yet submitted any rendering that uses
those textures.  And an upper-bound on un-flushed batches in that sort
of scenario actually seems like a good thing.  Although I could
probably be more clever about picking which batch(es) to flush in that
scenario.  The upper limit could be problematic if someone uploaded
layer 0 to a bunch of textures, and then generated mipmap for all of
the textures (as opposed to interleaving upload/genmipmap).  I guess
you probably have to go out of your way to be that stupid, so meh?

One of the annoying things, since pipe_resource is per-screen, not
per-context, I end up having to push batch_cache down into screen.
Which means that, for example, one context switching fb state could
force flushing a batch from another context.  Eventually if I push of
gmem+submit to a per-context helper thread, that should help keep
things properly serialized.  Although I still need some (currently
missing) mutexes to serialize batch_cache access, etc.  Also it means
that the upper limit on # of batches is per-screen, not per-context.
Not really sure what to do about that.  I really wish resources were
not shared across contexts (but rather just use flink or dmabuf when
you need to share), but I guess it is too late for that now :-(

https://github.com/freedreno/mesa/commit/e23dac02234de1c688efbad58758fdf9d837c94b

BR,
-R

> 2) Add a batch-cache.  Previously, whenever new framebuffer state is
>set, it forced a flush.  Now (if reordering is enabled), we use
>the framebuffer state as key into a hashtable to map it to an
>existing batch (if there is one, otherwise construct a new batch
>and add it to the table).
>
>When a resource is marked as read/written by a batch, which is
>already pending access by another batch, a dependency between the
>two batches is added.
>
>TODO there is probably a bit more room for improvement here.  See
>below analysis of supertuxkart.
>
> 3) Shadow resources.  Mid-batch UBO updates or uploading new contents
>to an in-use texture is sadly too common.  Traditional (non-tiler)
>gpu's

Re: [Mesa-dev] [PATCH 3/3] nvc0/ir: remove unused resource info loading helpers

2016-07-08 Thread Ilia Mirkin

Series is

Reviewed-by: Ilia Mirkin 

On Tue, Jul 5, 2016 at 8:01 AM, Samuel Pitoiset
 wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  | 24 
> --
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.h|  4 
>  2 files changed, 28 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index 561ff62..9735773 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -1451,24 +1451,6 @@ NVC0LoweringPass::loadResLength32(Value *ptr, uint32_t 
> off, uint16_t base)
>  }
>
>  inline Value *
> -NVC0LoweringPass::loadSuInfo64(Value *ptr, uint32_t off)
> -{
> -   return loadResInfo64(ptr, off, prog->driver->io.suInfoBase);
> -}
> -
> -inline Value *
> -NVC0LoweringPass::loadSuLength32(Value *ptr, uint32_t off)
> -{
> -   return loadResLength32(ptr, off, prog->driver->io.suInfoBase);
> -}
> -
> -inline Value *
> -NVC0LoweringPass::loadBufInfo32(Value *ptr, uint32_t off)
> -{
> -   return loadResInfo32(ptr, off, prog->driver->io.bufInfoBase);
> -}
> -
> -inline Value *
>  NVC0LoweringPass::loadBufInfo64(Value *ptr, uint32_t off)
>  {
> return loadResInfo64(ptr, off, prog->driver->io.bufInfoBase);
> @@ -1481,12 +1463,6 @@ NVC0LoweringPass::loadBufLength32(Value *ptr, uint32_t 
> off)
>  }
>
>  inline Value *
> -NVC0LoweringPass::loadUboInfo32(Value *ptr, uint32_t off)
> -{
> -   return loadResInfo32(ptr, off, prog->driver->io.uboInfoBase);
> -}
> -
> -inline Value *
>  NVC0LoweringPass::loadUboInfo64(Value *ptr, uint32_t off)
>  {
> return loadResInfo64(ptr, off, prog->driver->io.uboInfoBase);
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> index 5ab27ce..4d7d8cc 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
> @@ -127,12 +127,8 @@ private:
> Value *loadResInfo64(Value *ptr, uint32_t off, uint16_t base);
> Value *loadResLength32(Value *ptr, uint32_t off, uint16_t base);
> Value *loadSuInfo32(Value *ptr, int slot, uint32_t off);
> -   Value *loadSuInfo64(Value *ptr, uint32_t off);
> -   Value *loadSuLength32(Value *ptr, uint32_t off);
> -   Value *loadBufInfo32(Value *ptr, uint32_t off);
> Value *loadBufInfo64(Value *ptr, uint32_t off);
> Value *loadBufLength32(Value *ptr, uint32_t off);
> -   Value *loadUboInfo32(Value *ptr, uint32_t off);
> Value *loadUboInfo64(Value *ptr, uint32_t off);
> Value *loadUboLength32(Value *ptr, uint32_t off);
> Value *loadMsInfo32(Value *ptr, uint32_t off);
> --
> 2.9.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [ANNOUNCE] mesa 12.0.0

2016-07-08 Thread Emil Velikov

Hi all,

It's a real honour to announce Mesa 12.0.0.

This release has massive amount of features, but without a doubt the biggest
ones are:
 - Vulkan driver for Intel hardware from Ivy Bridge onward.
 - OpenGL 4.3 for nvc0, radeonsi and i965 (Gen8+)
 - OpenGL ES 3.1 on nvc0 and radeonsi
 - GLVND support for GLX, OpenGL
 - New gallium software driver - SWR.
 - DRI3 enablement for VDPAU, OMX and VAAPI

Note:
 - Gallium radeon drivers (r300, r600 and radeonsi) now require kernel 3.2 and
LLVM 3.6 or later.
 - Building SWR requires python2, since some of the generated files cannot be
distributed as part of the release tarball.


To check the full changelog, consisting of more than 5k8 commits from over 120
developers use the following command

 git log 11.2-branchpoint..mesa-12.0.0


Important changes since RC4:
 - People using git tarballs and/or otherwise retrieving the sources no longer
require to generate their own git_sha1.h file.
 - SWR no longer ships LLVM version specific sources. Thus the explicit python2
requirement above.

Changes since -rc4. 
 
Akihiko Odaki (1):
  mesa: don't install GLX files if GLX is not built

Ardinartsev Nikita (1):
  i965: Avoid division by zero.

Chuck Atkins (2):
  swr: Refactor checks for compiler feature flags
  gallium: Force blend color to 16-byte alignment

Dave Airlie (3):
  virgl: reduce some limits for now
  st/glsl_to_tgsi: don't increase immediate index by 1.
  Revert "st/glsl_to_tgsi: don't increase immediate index by 1."

Emil Velikov (10):
  Revert "swr: Refactor checks for compiler feature flags"
  clover: conditionally use MESA_GIT_SHA1
  anv: use cache uuid based on the build timestamp.
  automake: don't mandate git_sha1.h/MESA_GIT_SHA1
  swr: automake: don't ship LLVM version specific generated sources
  anv: install the intel_icd.json to ${datarootdir} by default
  anv: vulkan: remove the anv_device.$(OBJEXT) rule
  bugzilla_mesa.sh: Drop "Bug " from sed command
  Update version to 12.0.0(final)
  docs: Update 12.0.0 release notes

Ian Romanick (1):
  mapi: Export all GLES 3.1 functions in libGLESv2.so

Ilia Mirkin (5):
  translate: fix start_instance parameter in sse version
  nv50,nvc0: fix start_instance in manual push path
  glsl: only match gl_FragData and not gl_SecondaryFragDataEXT
  nvc0: when mapping directly, provide accurate xfer info + start
  glsl: don't try to lower non-gl builtins as if they were gl_FragData

Jason Ekstrand (38):
  spirv: Use the system value version of gl_FrontFace
  anv/cmd: Move flush_descriptor_sets to anv_cmd_buffer.c
  anv/cmd: Move emit_descriptor_pointers to genX_cmd_buffer.c
  anv/cmd: Dirty descriptor sets when a new pipeline is bound
  i965/gen4: Pull texture formats from the texture object not the miptree
  i965/gen4-6: Handle gl_texture_object::BaseLevel and MinLayer correctly
  i965: Drop the maximum 3D texture size to 512 on Sandy Bridge
  i965/blorp/gen8: Use the correct max level and layer in 
emit_surface_states
  i965/gen8: Use the qpitch from the aux_mt for AUX_QPITCH
  i965/fs: Use a default Y coordinate of 0 for TXF on gen9+
  i965/gen4: Subtract 1 from buffer sizes
  genxml/gen8,9: Prefix the multisample format enum with MSFMT
  isl/state: Don't use designated initializers for the surface state
  isl/state: Remove some unused fields
  isl/state: Put surface format setup at the top
  isl/state: Put all dimension setup together and towards the top
  isl/state: Put pitch calculations together
  isl/state: Return an extent3d from the halign/valign helper
  isl/state: Refactor the per-gen isl_to_gen_h/valign tables
  isl/state: Refactor the setup of clear colors
  isl/state: Don't force-disable L2 bypass for everything
  isl/state: Set SurfaceArray based on the surface dimension
  isl/state: Don't set RenderTargetViewExtent for texture surfaces
  isl/format: Mark R9G9B9E5 as containing 9-bit unsigned float channels
  isl/state: Set the IntegerSurfaceFormat bit on Haswell
  isl/state: Use the layout for computing qpitch rather than dimensions
  isl/state: Only set cube face enables if usage includes CUBE_BIT
  isl/state: Emit no-op mip tail setup on SKL
  isl/state: Use TILEWALK_XMAJOR for linear surfaces on gen7
  isl/state: Don't set SurfacePitch for gen9 1-D textures
  isl/state: Add assertions for buffer surface restrictions
  isl/state: Don't use designated initializers for buffer surface state
  isl/state: Allow for full 31-bit buffer texture sizes
  anv,isl: Lower storage image formats in anv
  genxml: Put append counter fields before MCS in RENDER_SURFACE_STATE on 
gen7
  anv: Add an allocator for scratch buffers
  genxml: Make ScratchSpaceBasePointer an address instead of an offset
  anv: Use different BOs for different scratch sizes and stages

Jordan

Re: [Mesa-dev] [PATCH v3] i965: intel_texture_barrier reimplemented

2016-07-08 Thread Alejandro Piñeiro

Hi, today I was updating the piglit test, as I got a detailed review.
While testing the changes, I found that there are some parameters
combinations that are still not passing. They are related to the number
of draw passes (or in other words, the number of glDrawElements calls
for the same vertices). So I added more combinations on the piglit
patch. Before it was testing with 1 and 8 drawing passes. But I added
the cases of 2, 3 and 4 drawing passes.

So:
  * v3 version of the piglit patch includes 48 parameter combinations of
the same test. All passing with current master.
  * v5 version (the one committed [1]) includes 144 parameter
combinations. 40 are failing.

Just as a quick test, I tried the old version of the mesa fix,
consisting on a combination of gen7_emit_cs_stall_flush +
brw_emit_mi_flush (that was called as a "big hammer"), and still have 40
subtests not passing.

I will start to look to this problem, but any idea/feedback to get it
solved would be welcome.

BR

[1]
https://cgit.freedesktop.org/piglit/commit/?id=8cb75a1bc1cbdec0e0c8f9a9b10631a369df2f5b

On 30/06/16 23:16, Francisco Jerez wrote:
> Alejandro Piñeiro  writes:
>
>> Fixes:
>> GL44-CTS.texture_barrier_ARB.same-texel-rw-multipass
>>
>> On Haswell, Broadwell and Skylake (note that in order to execute that
>> test, it is needed to override GL and GLSL versions).
>>
>> On gen6 this test was already working without this change. It keeps
>> working after it.
>>
>> This commit replaces the call to brw_emit_mi_flush for gen6+ with two
>> calls to brw_emit_pipe_control_flush:
>>
>>  * The first one with RENDER_TARGET_FLUSH and CS_STALL set to initiate
>>a render cache flush after any concurrent rendering completes and
>>cause the CS to stop parsing commands until the render cache
>>becomes coherent with memory.
>>
>>  * The second one have TEXTURE_CACHE_INVALIDATE set (and no CS stall)
>>to clean up any stale data from the sampler caches before rendering
>>continues.
>>
>> Didn't touch gen4-5, basically because I don't have a way to test
>> them.
>>
>> More info on commits:
>> 0aa4f99f562a05880a779707cbcd46be459863bf
>> 72473658c51d5e074ce219c1e6385a4cce29f467
>>
>> Thanks to Curro to help to tracking this down, as the root case was a
>> hw race condition.
>>
>> v2: use two calls to pipe_control_flush instead of a combination of
>> gen7_emit_cs_stall_flush and brw_emit_mi_flush calls (Curro)
>> v3: no need to const cache invalidation (Curro)
>> ---
>>
>> FWIW: checked with the CTS tests, and the piglit series, and confirmed
>> that the const cache invalidation is not needed.
>>
>>  src/mesa/drivers/dri/i965/intel_tex.c | 21 -
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_tex.c 
>> b/src/mesa/drivers/dri/i965/intel_tex.c
>> index cac33ac..a802d5a 100644
>> --- a/src/mesa/drivers/dri/i965/intel_tex.c
>> +++ b/src/mesa/drivers/dri/i965/intel_tex.c
>> @@ -9,6 +9,7 @@
>>  #include "intel_mipmap_tree.h"
>>  #include "intel_tex.h"
>>  #include "intel_fbo.h"
>> +#include "intel_reg.h"
>>  
>>  #define FILE_DEBUG_FLAG DEBUG_TEXTURE
>>  
>> @@ -362,7 +363,25 @@ intel_texture_barrier(struct gl_context *ctx)
>>  {
>> struct brw_context *brw = brw_context(ctx);
>>  
>> -   brw_emit_mi_flush(brw);
>> +   if (brw->gen >= 6) {
>> +  if (brw->gen == 6) {
>> + /* [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache
>> +  * Flush Enable = 1, a PIPE_CONTROL with any non-zero
>> +  * post-sync-op is required.
>> +  */
>> + brw_emit_post_sync_nonzero_flush(brw);
>> +  }
>> +
>> +  brw_emit_pipe_control_flush(brw,
>> +  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
>> +  PIPE_CONTROL_RENDER_TARGET_FLUSH |
>> +  PIPE_CONTROL_CS_STALL);
>> +
>> +  brw_emit_pipe_control_flush(brw,
>> +  PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
>> +   } else {
>> +  brw_emit_mi_flush(brw);
>> +   }
> Looks reasonable to me, let's get this bug fixed on master, things can
> be refactored later on:
>
> Reviewed-by: Francisco Jerez 
>
>>  }
>>  
>>  void
>> -- 
>> 2.7.4




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

Re: [Mesa-dev] [PATCH 3/4] st/mesa: refactor duplicated etc fallback checks

2016-07-08 Thread Ilia Mirkin

On Fri, Jul 8, 2016 at 6:22 AM, Eric Engestrom
 wrote:
> On Fri, Jul 08, 2016 at 02:48:04AM -0400, Ilia Mirkin wrote:
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/mesa/state_tracker/st_cb_texture.c | 15 +--
>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
>> b/src/mesa/state_tracker/st_cb_texture.c
>> index 1474d97..7852d45 100644
>> --- a/src/mesa/state_tracker/st_cb_texture.c
>> +++ b/src/mesa/state_tracker/st_cb_texture.c
>> @@ -189,6 +189,12 @@ st_FreeTextureImageBuffer(struct gl_context *ctx,
>> stImage->num_transfers = 0;
>>  }
>>
>> +static void
>
> s/void/bool/

Of course, thank you. It's actually fixed in the next patch, but I
forgot to fold the fix in. (And I end up making it into a global
function there, I guess I should move that into this patch as well.)

>
>> +etc_fallback(struct st_context *st, struct gl_texture_image *texImage)
>> +{
>> +   return (_mesa_is_format_etc2(texImage->TexFormat) && !st->has_etc2) ||
>> +  (texImage->TexFormat == MESA_FORMAT_ETC1_RGB8 && !st->has_etc1);
>> +}
>>
>>  /** called via ctx->Driver.MapTextureImage() */
>>  static void
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 96853] gl_PrimitiveID is zero when rendering points of size > 1

2016-07-08 Thread bugzilla-daemon

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

--- Comment #3 from Roland Scheidegger  ---
(In reply to denis.fisseler from comment #2)
> This sounds plausible, thank you for shedding some light on this! The faking
> of large points through triangles in a GS would also explain, why some of my
> GS code, I use with large points and for constructing wide lines, doesn't
> work as expected. Unfortunately this part of the mesa code seems to have a
> lot of bugs, and produces crashes, no rendering output and false rendering
> output. The same code works flawless with ubuntu, win7, winxp on
> nvidia/amd/intel graphics in a non-vm environment.

In theory if there already is a user-provided gs (which doesn't output points)
then the emulation code doesn't really apply. But I don't really know this code
(other than knowing this is pretty tricky stuff...).

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

[Mesa-dev] [Bug 96853] gl_PrimitiveID is zero when rendering points of size > 1

2016-07-08 Thread bugzilla-daemon

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

--- Comment #2 from denis.fisse...@tu-dortmund.de ---
This sounds plausible, thank you for shedding some light on this! The faking of
large points through triangles in a GS would also explain, why some of my GS
code, I use with large points and for constructing wide lines, doesn't work as
expected. Unfortunately this part of the mesa code seems to have a lot of bugs,
and produces crashes, no rendering output and false rendering output. The same
code works flawless with ubuntu, win7, winxp on nvidia/amd/intel graphics in a
non-vm environment.

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

Re: [Mesa-dev] [PATCH 1/6] i965/fs: add a helper function to create double immediates

2016-07-08 Thread Samuel Iglesias Gonsálvez



On 08/07/16 00:27, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
>> From: Iago Toral Quiroga 
>>
>> Gen7 hardware does not support double immediates so these need
>> to be moved in 32-bit chunks to a regular vgrf instead. Instead
>> of doing this every time we need to create a DF immediate,
>> create a helper function that does the right thing depending
>> on the hardware generation.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.h   |  2 ++
>>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 43 
>> 
>>  2 files changed, 45 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
>> b/src/mesa/drivers/dri/i965/brw_fs.h
>> index 4237197..dd7ce7d 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.h
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
>> @@ -167,6 +167,8 @@ public:
>> bool lower_simd_width();
>> bool opt_combine_constants();
>>  
>> +   fs_reg setup_imm_df(double v);
>> +
>> void emit_dummy_fs();
>> void emit_repclear_shader();
>> fs_reg *emit_fragcoord_interpolation();
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> index b3f5dfd..268c847 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> @@ -616,6 +616,49 @@ fs_visitor::optimize_frontfacing_ternary(nir_alu_instr 
>> *instr,
>> return true;
>>  }
>>  
>> +fs_reg
>> +fs_visitor::setup_imm_df(double v)
> 
> Mainly nitpicking here, but because this function only needs an i965 IR
> builder and doesn't otherwise care about the fs_visitor class, it would
> make more sense for it to be a stand-alone function independent from
> fs_visitor taking an fs_builder as argument instead.
> 
>> +{
>> +   assert(devinfo->gen >= 7);
>> +
>> +   if (devinfo->gen >= 8)
>> +  return brw_imm_df(v);
>> +
>> +   /* gen7 does not support DF immediates, so we generate a 64-bit constant 
>> by
>> +* writing the low 32-bit of the constant to suboffset 0 of a VGRF and
>> +* the high 32-bit to suboffset 4 and then applying a stride of 0.
>> +*
>> +* Alternatively, we could also produce a normal VGRF (without stride 0)
>> +* by writing to all the channels in the VGRF, however, that would hit 
>> the
>> +* gen7 bug where we have to split writes that span more than 1 register
>> +* into instructions with a width of 4 (otherwise the write to the second
>> +* register written runs into an execmask hardware bug) which isn't very
>> +* nice.
>> +*/
>> +   union {
>> +  double d;
>> +  struct {
>> + uint32_t i1;
>> + uint32_t i2;
>> +  };
>> +   } di;
>> +
>> +   di.d = v;
>> +
> 
> You can declare a scalar builder here for convenience like:
> 
> | const fs_builder ubld = bld.exec_all().group(1, 0);
> 
> then use it below instead of 'bld' so you can get rid of the six inst
> field assignments.
> 
>> +   fs_reg tmp = vgrf(glsl_type::uint_type);
> 
> On e.g. SIMD32 mode this will allocate 32 components worth of registers
> even though you only need two.  Once you have a scalar builder at hand
> you can do it as follows instead:
> 
> | const fs_reg tmp = ubld.vgrf(BRW_REGISTER_TYPE_UD, 2);
> 
> Other than that looks okay to me.
> 

OK, thanks for the suggestions! I will implement them.

Sam

>> +   fs_inst *inst = bld.MOV(tmp, brw_imm_ud(di.i1));
>> +   inst->force_writemask_all = true;
>> +   inst->exec_size = 1;
>> +   inst->regs_written = 1;
>> +
>> +   inst = bld.MOV(horiz_offset(tmp, 1), brw_imm_ud(di.i2));
>> +   inst->force_writemask_all = true;
>> +   inst->exec_size = 1;
>> +   inst->regs_written = 1;
>> +
>> +   return component(retype(tmp, BRW_REGISTER_TYPE_DF), 0);
>> +}
>> +
>>  void
>>  fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr)
>>  {
>> -- 
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



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

Re: [Mesa-dev] [PATCH 3/4] st/mesa: refactor duplicated etc fallback checks

2016-07-08 Thread Eric Engestrom

On Fri, Jul 08, 2016 at 02:48:04AM -0400, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_cb_texture.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_texture.c 
> b/src/mesa/state_tracker/st_cb_texture.c
> index 1474d97..7852d45 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -189,6 +189,12 @@ st_FreeTextureImageBuffer(struct gl_context *ctx,
> stImage->num_transfers = 0;
>  }
>  
> +static void

s/void/bool/

> +etc_fallback(struct st_context *st, struct gl_texture_image *texImage)
> +{
> +   return (_mesa_is_format_etc2(texImage->TexFormat) && !st->has_etc2) ||
> +  (texImage->TexFormat == MESA_FORMAT_ETC1_RGB8 && !st->has_etc1);
> +}
>  
>  /** called via ctx->Driver.MapTextureImage() */
>  static void
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: Force blend color to 16-byte alignment

2016-07-08 Thread Nicolai Hähnle


Hi Chuck,

this commit breaks 32-bit builds at least of radeonsi and probably 
others because malloc()ed structures are only aligned to 8 bytes, see 
https://bugs.freedesktop.org/show_bug.cgi?id=96835


I presume there are two possible fixes:
1. Drop the alignment on 32-bit.
2. Align affected structures to 16 byte boundaries manually.

Personally, I prefer the first option because it seems less fragile, but 
the question is whether the 16-byte alignment is needed for 32-bit 
builds as well?


Cheers,
Nicolai

On 28.06.2016 22:45, Chuck Atkins wrote:

This aligns the 4-element color float array to 16 byte boundaries.  This
should allow compiler vectorizers to generate better optimizations.
Also fixes broken vectorization generated by Intel compiler.

Reported-by: Tim Rowley 
Signed-off-by: Chuck Atkins 
---
  src/gallium/include/pipe/p_state.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index 1543e90..95f140f 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -326,7 +326,7 @@ struct pipe_blend_state

  struct pipe_blend_color
  {
-   float color[4];
+  PIPE_ALIGN_VAR(16) float color[4];
  };




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

[Mesa-dev] [Bug 96835] "gallium: Force blend color to 16-byte alignment" crash with "-march=native -O3" causes some 32bit games to crash

2016-07-08 Thread bugzilla-daemon

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

Nicolai Hähnle  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Mesa core
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

--- Comment #8 from Nicolai Hähnle  ---
(The Gallium HUD crash is "benign": you enabled more graphs than there are
pre-defined colors. Annoying, but unrelated to the problem at hand.)

My understanding is that malloc should return pointers with the largest
alignment requirement possible for the size that it allocates. Although,
perhaps that's less than 16 bytes on 32 bits?

Actually, I think that's it: the backtrace shows ctx=0x569cbfc8, i.e. ctx is
only 8-byte aligned even though it contains a pipe_blend_color structure.

Moving to Mesa core since it's not really radeonsi-specific.

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

Re: [Mesa-dev] [PATCH 3/4] radeonsi: use multi-threaded compilation in debug contexts

2016-07-08 Thread Nicolai Hähnle


On 07.07.2016 23:49, Marek Olšák wrote:

On Thu, Jul 7, 2016 at 9:39 AM, Nicolai Hähnle  wrote:

From: Nicolai Hähnle 

We only have to stay single-threaded when debug output must be synchronous.
This yields better parallelism in shader-db runs for me.


shader-db should already get the CPU load to 100% for all cores. It
doesn't seem to possible to get better parallelism than that.


I know, though for some reason it didn't always get it for me. I haven't 
bothered to look into it so far though.


Nicolai



Marek


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

Re: [Mesa-dev] [PATCH 1/4] gallium: add async flag to pipe_debug_callback

2016-07-08 Thread Nicolai Hähnle


On 07.07.2016 16:40, Jan Vesely wrote:

On Thu, 2016-07-07 at 09:39 +0200, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

---
  src/gallium/include/pipe/p_state.h   | 6 ++
  src/gallium/state_trackers/clover/core/queue.cpp | 5 -
  src/mesa/state_tracker/st_debug.c| 5 -
  3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_state.h
b/src/gallium/include/pipe/p_state.h
index f4bee38..f7bf402 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -809,6 +809,12 @@ struct pipe_compute_state
  struct pipe_debug_callback
  {
 /**
+* When set to \c true, the callback may be called asynchronously
from a
+* driver-created thread.
+*/
+   bool async;
+
+   /**
  * Callback for the driver to report debug/performance/etc
information back
  * to the state tracker.
  *
diff --git a/src/gallium/state_trackers/clover/core/queue.cpp
b/src/gallium/state_trackers/clover/core/queue.cpp
index 24d71f1..00afdb6 100644
--- a/src/gallium/state_trackers/clover/core/queue.cpp
+++ b/src/gallium/state_trackers/clover/core/queue.cpp
@@ -50,7 +50,10 @@ command_queue::command_queue(clover::context ,
clover::device ,
throw error(CL_INVALID_DEVICE);

 if (ctx.notify) {
-  struct pipe_debug_callback cb = { _notify_callback, this
};
+  struct pipe_debug_callback cb;
+  memset(, 0, sizeof(db));
+  cb.debug_message = _notify_callback;
+  cb.data = this;


I don't think this is necessary, elements that are not mentioned are
initialized to zero, both C(below) and C++.


Yes, but I think it's better to use a form of initialization that does 
not depend on the order of variables.


I suppose one could use designated initializers instead, but the pattern 
of memset to zero followed by explicit assignment is quite common in 
Mesa (and Gallium in particular), so I stuck with that.


Nicolai



Jan


if (pipe->set_debug_callback)
   pipe->set_debug_callback(pipe, );
 }
diff --git a/src/mesa/state_tracker/st_debug.c
b/src/mesa/state_tracker/st_debug.c
index eaf2549..214e223 100644
--- a/src/mesa/state_tracker/st_debug.c
+++ b/src/mesa/state_tracker/st_debug.c
@@ -172,7 +172,10 @@ st_enable_debug_output(struct st_context *st,
boolean enable)
return;

 if (enable) {
-  struct pipe_debug_callback cb = { st_debug_message, st };
+  struct pipe_debug_callback cb;
+  memset(, 0, sizeof(cb));
+  cb.debug_message = st_debug_message;
+  cb.data = st;
pipe->set_debug_callback(pipe, );
 } else {
pipe->set_debug_callback(pipe, NULL);

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

Re: [Mesa-dev] [PATCH 3/6] i965/fs/gen7: split instructions that run into exec masking bugs

2016-07-08 Thread Iago Toral

On Fri, 2016-07-08 at 09:21 +0200, Iago Toral wrote:
> On Thu, 2016-07-07 at 19:36 -0700, Francisco Jerez wrote:
> > 
> > Samuel Iglesias Gonsálvez  writes:
> > 
> > > 
> > > 
> > > From: Iago Toral Quiroga 
> > > 
> > > In fp64 we can produce code like this:
> > > 
> > > mov(16) vgrf2<2>:UD, vgrf3<2>:UD
> > > 
> > > That our simd lowering pass would typically split in instructions
> > > with a
> > > width of 8, writing to two consecutive registers each.
> > > Unfortunately, gen7
> > > hardware has a bug affecting execution masking and as a result,
> > > the
> > > second GRF register write won't work properly. Curro verified
> > > this:
> > > 
> > > "The problem is that pre-Gen8 EUs are hardwired to use the
> > > QtrCtrl+1
> > >  (where QtrCtrl is the 8-bit quarter of the execution mask
> > > signals
> > >  specified in the instruction control fields) for the second
> > >  compressed half of any single-precision instruction (for
> > >  double-precision instructions it's hardwired to use NibCtrl+1),
> > >  which means that the EU will apply the wrong execution controls
> > >  for the second sequential GRF write if the number of channels
> > > per
> > >  GRF is not exactly eight in single-precision mode (or four in
> > >  double-float mode)."
> > > 
> > > In practice, this means that we cannot write more than one
> > > consecutive GRF in a single instruction if the number of channels
> > > per GRF is not exactly eight in single-precision mode (or four
> > > in double-float mode).
> > > 
> > > This patch makes our SIMD lowering pass split this kind of
> > > instructions
> > > so that the split versions only write to a single register. In
> > > the
> > > example above this means that we split the write in 4
> > > instructions,
> > > each
> > > one writing 4 UD elements (width = 4) to a single register.
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_fs.cpp | 20 
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > index 2f473cc..caf88d1 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > @@ -4677,6 +4677,26 @@ static unsigned
> > >  get_fpu_lowered_simd_width(const struct brw_device_info
> > > *devinfo,
> > > const fs_inst *inst)
> > >  {
> > > +   /* Pre-Gen8 EUs are hardwired to use the QtrCtrl+1 (where
> > > QtrCtrl is
> > > +* the 8-bit quarter of the execution mask signals specified
> > > in
> > > the
> > > +* instruction control fields) for the second compressed half
> > > of any
> > > +* single-precision instruction (for double-precision
> > > instructions
> > > +* it's hardwired to use NibCtrl+1), which means that the EU
> > > will
> > When I found out the hardware issue you describe in this comment I
> > only
> > had a HSW at hand, so I looked into this again today in order to
> > verify
> > whether IVB/VLV behave in the same way, and I'm afraid they
> > don't...  I
> > haven't tried it on real IVB hardware, but at least the simulator
> > behaves the same as HSW for single precision execution types, while
> > for
> > double precision types instruction decompression seems to be
> > completely
> > busted.  AFAICT it applies the same channel enable signals to both
> > halves of the compressed instruction which will be just wrong under
> > non-uniform control flow.  Can you clarify in the comment above
> > that
> > the
> > text in parentheses referring to double-precision instructions may
> > only
> > apply to HSW?
> Sure.
> 
> > 
> > Have you been able to get any of the FP64 non-uniform control flow
> > tests
> > to pass on IVB?  If you have I guess this may be a simulator-only
> > bug,
> > although I'm not sure the FS tests you have written will be non-
> > uniform
> > enough to reproduce the issue.  If you haven't, we may have to add
> > another check here in order to lower all non-force_writemask_all DF
> > instructions to SIMD4 on IVB/VLV...  :(
> For now we have focused on HSW only but thanks for the update
> regarding
> IVB. I'll make sure to pay special attention to non-uniform control-
> flow cases there when we start testing things there (we intend to
> start
> putting effort on IVB in the next days).
> 
> I suppose that for now we can leave this patch as gen7 specific
> (rather
> than HSW specific) and fix it up if needed for IVB when we actually
> verify that it needs extra work there. Does that sound like a good
> plan?
> 
> > 
> > > 
> > > 
> > > +* apply the wrong execution controls for the second
> > > sequential
> > > GRF
> > > +* write if the number of channels per GRF is not exactly
> > > eight
> > > in
> > > +* single-precision mode (or four in double-float mode).
> > > +*
> > > +* In this situation we calculate the maximum size of the
> > > split
> > > +* instructions so they only ever write to a

Re: [Mesa-dev] [PATCH 4/6] i965/fs: do not require force_writemask_all with exec_size 4

2016-07-08 Thread Samuel Iglesias Gonsálvez



On 07/07/16 23:38, Francisco Jerez wrote:
> Samuel Iglesias Gonsálvez  writes:
> 
>> So far we only used instructions with this size in situations where we
>> did not operate per-channel and we wanted to ignore the execution mask,
>> but gen7 fp64 will need to emit code with a width of 4 that needs
>> normal execution masking.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> index d25d26a..07581d2 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
>> @@ -1649,7 +1649,6 @@ fs_generator::generate_code(const cfg_t *cfg, int 
>> dispatch_width)
>>brw_set_default_acc_write_control(p, inst->writes_accumulator);
>>brw_set_default_exec_size(p, cvt(inst->exec_size) - 1);
>>  
>> -  assert(inst->force_writemask_all || inst->exec_size >= 8);
> 
> Another possibility would be to relax the assertion to check that
> "inst->force_writemask_all || inst->exec_size >= 4" -- Because you can
> only control the channel enable group with nibble granularity at best
> it's unpractical to split instructions into chunks of execution size
> less than four.  SIMD4 though definitely makes sense because of FP64.

Right. I will relax the assertion check as suggested.

> Either way patch is:
> 
> Reviewed-by: Francisco Jerez 
> 

Thanks!

Sam

>>assert(inst->force_writemask_all || inst->group % inst->exec_size == 
>> 0);
>>assert(inst->base_mrf + inst->mlen <= BRW_MAX_MRF(devinfo->gen));
>>assert(inst->mlen <= BRW_MAX_MSG_LENGTH);
>> -- 
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



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

Re: [Mesa-dev] [PATCH 3/6] i965/fs/gen7: split instructions that run into exec masking bugs

2016-07-08 Thread Iago Toral

On Fri, 2016-07-08 at 09:21 +0200, Iago Toral wrote:
> On Thu, 2016-07-07 at 19:36 -0700, Francisco Jerez wrote:
> > 
> > Samuel Iglesias Gonsálvez  writes:
> > 
> > > 
> > > 
> > > From: Iago Toral Quiroga 
> > > 
> > > In fp64 we can produce code like this:
> > > 
> > > mov(16) vgrf2<2>:UD, vgrf3<2>:UD
> > > 
> > > That our simd lowering pass would typically split in instructions
> > > with a
> > > width of 8, writing to two consecutive registers each.
> > > Unfortunately, gen7
> > > hardware has a bug affecting execution masking and as a result,
> > > the
> > > second GRF register write won't work properly. Curro verified
> > > this:
> > > 
> > > "The problem is that pre-Gen8 EUs are hardwired to use the
> > > QtrCtrl+1
> > >  (where QtrCtrl is the 8-bit quarter of the execution mask
> > > signals
> > >  specified in the instruction control fields) for the second
> > >  compressed half of any single-precision instruction (for
> > >  double-precision instructions it's hardwired to use NibCtrl+1),
> > >  which means that the EU will apply the wrong execution controls
> > >  for the second sequential GRF write if the number of channels
> > > per
> > >  GRF is not exactly eight in single-precision mode (or four in
> > >  double-float mode)."
> > > 
> > > In practice, this means that we cannot write more than one
> > > consecutive GRF in a single instruction if the number of channels
> > > per GRF is not exactly eight in single-precision mode (or four
> > > in double-float mode).
> > > 
> > > This patch makes our SIMD lowering pass split this kind of
> > > instructions
> > > so that the split versions only write to a single register. In
> > > the
> > > example above this means that we split the write in 4
> > > instructions,
> > > each
> > > one writing 4 UD elements (width = 4) to a single register.
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_fs.cpp | 20 
> > >  1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > index 2f473cc..caf88d1 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > > @@ -4677,6 +4677,26 @@ static unsigned
> > >  get_fpu_lowered_simd_width(const struct brw_device_info
> > > *devinfo,
> > > const fs_inst *inst)
> > >  {
> > > +   /* Pre-Gen8 EUs are hardwired to use the QtrCtrl+1 (where
> > > QtrCtrl is
> > > +* the 8-bit quarter of the execution mask signals specified
> > > in
> > > the
> > > +* instruction control fields) for the second compressed half
> > > of any
> > > +* single-precision instruction (for double-precision
> > > instructions
> > > +* it's hardwired to use NibCtrl+1), which means that the EU
> > > will
> > When I found out the hardware issue you describe in this comment I
> > only
> > had a HSW at hand, so I looked into this again today in order to
> > verify
> > whether IVB/VLV behave in the same way, and I'm afraid they
> > don't...  I
> > haven't tried it on real IVB hardware, but at least the simulator
> > behaves the same as HSW for single precision execution types, while
> > for
> > double precision types instruction decompression seems to be
> > completely
> > busted.  AFAICT it applies the same channel enable signals to both
> > halves of the compressed instruction which will be just wrong under
> > non-uniform control flow.  Can you clarify in the comment above
> > that
> > the
> > text in parentheses referring to double-precision instructions may
> > only
> > apply to HSW?
> Sure.
> 
> > 
> > Have you been able to get any of the FP64 non-uniform control flow
> > tests
> > to pass on IVB?  If you have I guess this may be a simulator-only
> > bug,
> > although I'm not sure the FS tests you have written will be non-
> > uniform
> > enough to reproduce the issue.  If you haven't, we may have to add
> > another check here in order to lower all non-force_writemask_all DF
> > instructions to SIMD4 on IVB/VLV...  :(
> For now we have focused on HSW only but thanks for the update
> regarding
> IVB. I'll make sure to pay special attention to non-uniform control-
> flow cases there when we start testing things there (we intend to
> start
> putting effort on IVB in the next days).
> 
> I suppose that for now we can leave this patch as gen7 specific
> (rather
> than HSW specific) and fix it up if needed for IVB when we actually
> verify that it needs extra work there. Does that sound like a good
> plan?
> 
> > 
> > > 
> > > 
> > > +* apply the wrong execution controls for the second
> > > sequential
> > > GRF
> > > +* write if the number of channels per GRF is not exactly
> > > eight
> > > in
> > > +* single-precision mode (or four in double-float mode).
> > > +*
> > > +* In this situation we calculate the maximum size of the
> > > split
> > > +* instructions so they only ever write to a

1 2 >

1 - 100 of 106 matches

Mail list logo