Re: [Mesa-dev] [PATCH] glsl: Fix memory leak in glsl_lexer.ll

2014-09-04 Thread Aras Pranckevicius

  --- a/src/glsl/glsl_lexer.ll
  +++ b/src/glsl/glsl_lexer.ll
  @@ -232,7 +232,8 @@ HASH^{SPC}#{SPC}
   PP[ \t\r]*   { }
   PP:  return COLON;
   PP[_a-zA-Z][_a-zA-Z0-9]* {
  -  yylval-identifier = strdup(yytext);
  +  void *ctx = yyextra;
  +  yylval-identifier =
 ralloc_strdup(ctx, yytext);
 return IDENTIFIER;
  }
   PP[1-9][0-9]*{

 There's another use of strdup() in this file. I assume it needs the
 same treatment.


Seems like there's a memory leak at least in extension indentifiers:
http://lists.freedesktop.org/archives/mesa-dev/2013-August/044010.html


-- 
Aras Pranckevičius
work: http://unity3d.com
home: http://aras-p.info
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.

2014-09-04 Thread Iago Toral Quiroga
On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote:
 On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote:
  Currently, when a geometry shader can't use dual object mode we fall back to
  dual instance mode, however, when invocations == 1, single dispatch mode is
  more performant and equally efficient in terms of register pressure.
 
  Single dispatch mode requires that the driver can handle interleaving of
  registers, but this is already supported (dual instance mode has the same
  requirement).
  ---
   src/mesa/drivers/dri/i965/brw_context.h   |  8 ---
   src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 26 
  +++
   src/mesa/drivers/dri/i965/gen7_gs_state.c |  4 +---
   src/mesa/drivers/dri/i965/gen8_gs_state.c |  4 +---
   4 files changed, 20 insertions(+), 22 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
  b/src/mesa/drivers/dri/i965/brw_context.h
  index 1bbcf46..7439da1 100644
  --- a/src/mesa/drivers/dri/i965/brw_context.h
  +++ b/src/mesa/drivers/dri/i965/brw_context.h
  @@ -587,10 +587,12 @@ struct brw_gs_prog_data
  int invocations;
 
  /**
  -* True if the thread should be dispatched in DUAL_INSTANCE mode, false 
  if
  -* it should be dispatched in DUAL_OBJECT mode.
  +* Dispatch mode, can be any of:
  +* GEN7_GS_DISPATCH_MODE_DUAL_OBJECT
  +* GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE
  +* GEN7_GS_DISPATCH_MODE_SINGLE
   */
  -   bool dual_instanced_dispatch;
  +   int dispatch_mode;
   };
 
   /** Number of texture sampler units */
  diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
  b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  index b7995ad..c2a4892 100644
  --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  @@ -101,10 +101,11 @@ vec4_gs_visitor::setup_payload()
   {
  int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
 
  -   /* If we are in dual instanced mode, then attributes are going to be
  -* interleaved, so one register contains two attribute slots.
  +   /* If we are in dual instanced or single mode, then attributes are going
  +* to be interleaved, so one register contains two attribute slots.
   */
  -   int attributes_per_reg = c-prog_data.dual_instanced_dispatch ? 2 : 1;
  +   int attributes_per_reg =
  +  c-prog_data.dispatch_mode == GEN7_GS_DISPATCH_MODE_DUAL_OBJECT ? 1 
  : 2;
 
  /* If a geometry shader tries to read from an input that wasn't written 
  by
   * the vertex shader, that produces undefined results, but it shouldn't
  @@ -129,8 +130,7 @@ vec4_gs_visitor::setup_payload()
 
  reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
 
  -   lower_attributes_to_hw_regs(attribute_map,
  -   c-prog_data.dual_instanced_dispatch);
  +   lower_attributes_to_hw_regs(attribute_map, attributes_per_reg  1);
 
  this-first_non_payload_grf = reg;
   }
  @@ -640,7 +640,7 @@ brw_gs_emit(struct brw_context *brw,
   */
  if (c-prog_data.invocations = 1 
  likely(!(INTEL_DEBUG  DEBUG_NO_DUAL_OBJECT_GS))) {
  -  c-prog_data.dual_instanced_dispatch = false;
  +  c-prog_data.dispatch_mode = GEN7_GS_DISPATCH_MODE_DUAL_OBJECT;
 
 vec4_gs_visitor v(brw, c, prog, mem_ctx, true /* no_spills */);
 if (v.run()) {
  @@ -652,15 +652,15 @@ brw_gs_emit(struct brw_context *brw,
 
  /* Either we failed to compile in DUAL_OBJECT mode (probably because it
   * would have required spilling) or DUAL_OBJECT mode is disabled.  So 
  fall
  -* back to DUAL_INSTANCED mode, which consumes fewer registers.
  +* back to DUAL_INSTANCED or SINGLE mode, which consumes fewer 
  registers.
   *
  -* FIXME: In an ideal world we'd fall back to SINGLE mode, which would
  -* allow us to interleave general purpose registers (resulting in even 
  less
  -* likelihood of spilling).  But at the moment, the vec4 generator and
  -* visitor classes don't have the infrastructure to interleave general
  -* purpose registers, so DUAL_INSTANCED is the best we can do.
 
 I think Paul's note is still somewhat valid. Updates to the code gen
 could lead to improved register usage with single mode, right?
 
 So, we'll use single mode, but with the same register usage as dual instance.

Oh, I got confused with this because I thought he was talking about the
inputs for some reason, which are interleaved in both cases. I don't
know why I got confused, since we clearly mentions the generator
classes. But I see now that he is talking about the output.

I'll keep the FIXME part of the comment.

  +* SINGLE mode is more performant when invocations == 1 and 
  DUAL_INSTANCE
  +* mode is more performant when invocations  1.
 
 Maybe site the PRM?
 
 From the Ivy Bridge PRM, Vol2 Part1 7.2.1.1 3DSTATE_GS
 When InstanceCount=1 (one instance per 

Re: [Mesa-dev] [PATCH 02/37] i965/gen6/gs: refactor gen6_gs_state

2014-09-04 Thread Iago Toral Quiroga
On mié, 2014-09-03 at 18:51 -0700, Jordan Justen wrote:
 Rather than:
 i965/gen6/gs: refactor gen6_gs_state
 
 How about something like:
 i965/gen6/gs: Skeleton for user GS program support

Sure, that sounds good to me.

 (more below)
 
 On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com wrote:
  From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
  Currently, gen6 only uses geometry shaders for transform feedback so the 
  state
  we emit is not suitable to accomodate general purpose, user-provided 
  geometry
  shaders. This patch paves the way to add these support and the needed
  3DSTATE_GS packet modifications for it.
 
  Previous code that emitted state to implement transform feedback in gen6 
  goes
  to upload_gs_state_adhoc_tf().
 
  Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
  ---
   src/mesa/drivers/dri/i965/gen6_gs_state.c | 105 
  ++
   1 file changed, 94 insertions(+), 11 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/gen6_gs_state.c 
  b/src/mesa/drivers/dri/i965/gen6_gs_state.c
  index 9648fb7..e132959 100644
  --- a/src/mesa/drivers/dri/i965/gen6_gs_state.c
  +++ b/src/mesa/drivers/dri/i965/gen6_gs_state.c
  @@ -31,7 +31,7 @@
   #include intel_batchbuffer.h
 
   static void
  -upload_gs_state(struct brw_context *brw)
  +upload_gs_state_for_tf(struct brw_context *brw)
   {
  /* Disable all the constant buffers. */
  BEGIN_BATCH(5);
  @@ -49,11 +49,11 @@ upload_gs_state(struct brw_context *brw)
 OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE);
 OUT_BATCH(0); /* no scratch space */
 OUT_BATCH((2  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
  -   (brw-ff_gs.prog_data-urb_read_length  
  GEN6_GS_URB_READ_LENGTH_SHIFT));
  +(brw-ff_gs.prog_data-urb_read_length  
  GEN6_GS_URB_READ_LENGTH_SHIFT));
 OUT_BATCH(((brw-max_gs_threads - 1)  GEN6_GS_MAX_THREADS_SHIFT) |
  -   GEN6_GS_STATISTICS_ENABLE |
  -   GEN6_GS_SO_STATISTICS_ENABLE |
  -   GEN6_GS_RENDERING_ENABLE);
  +GEN6_GS_STATISTICS_ENABLE |
  +GEN6_GS_SO_STATISTICS_ENABLE |
  +GEN6_GS_RENDERING_ENABLE);
 
 This looks like tabs to spaces conversion. For lines that need to be
 changed, it is good to do that conversion. But, in this case, the only
 change is the name of the function.

Okay.

You granted the reviewed-by anyway though, so I understand that this
comment is only for reference. Or would you prefer that we remove these
changes from the patch?

 OUT_BATCH(GEN6_GS_SVBI_PAYLOAD_ENABLE |
   GEN6_GS_SVBI_POSTINCREMENT_ENABLE |
   (brw-ff_gs.prog_data-svbi_postincrement_value 
  @@ -65,24 +65,107 @@ upload_gs_state(struct brw_context *brw)
 OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
 OUT_BATCH(0); /* prog_bo */
 OUT_BATCH((0  GEN6_GS_SAMPLER_COUNT_SHIFT) |
  -   (0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
  +(0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
 OUT_BATCH(0); /* scratch space base offset */
 OUT_BATCH((1  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
  -   (0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
  -   (0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
  +(0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
  +(0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
 OUT_BATCH((0  GEN6_GS_MAX_THREADS_SHIFT) |
  -   GEN6_GS_STATISTICS_ENABLE |
  -   GEN6_GS_RENDERING_ENABLE);
  +GEN6_GS_STATISTICS_ENABLE |
  +GEN6_GS_RENDERING_ENABLE);
  +  OUT_BATCH(0);
  +  ADVANCE_BATCH();
  +   }
  +}
  +
  +static void
  +upload_gs_state(struct brw_context *brw)
  +{
  +   /* BRW_NEW_GEOMETRY_PROGRAM */
  +   bool active = brw-geometry_program;
  +   /* CACHE_NEW_GS_PROG */
  +   const struct brw_vec4_prog_data *prog_data = brw-gs.prog_data-base;
  +   const struct brw_stage_state *stage_state = brw-gs.base;
  +
  +   if (active) {
  +  /* FIXME: enable constant buffers */
  +  BEGIN_BATCH(5);
  +  OUT_BATCH(_3DSTATE_CONSTANT_GS  16 | (5 - 2));
  +  OUT_BATCH(0);
  +  OUT_BATCH(0);
 OUT_BATCH(0);
  +  OUT_BATCH(0);
  +  ADVANCE_BATCH();
  +
  +  BEGIN_BATCH(7);
  +  OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
  +  OUT_BATCH(stage_state-prog_offset);
  +
  +  /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled as it
  +   * was previously done for gen6.
  +   *
  +   * TODO: test with both disabled to see if the HW is behaving
  +   * as expected, like in gen7.
  +   */
  +  OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE |
  +((ALIGN(stage_state-sampler_count, 4)/4) 
  + GEN6_GS_SAMPLER_COUNT_SHIFT) |
  +((prog_data-base.binding_table.size_bytes / 4) 
  + 

Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.

2014-09-04 Thread Jordan Justen
On Wed, Sep 3, 2014 at 11:28 PM, Iago Toral Quiroga ito...@igalia.com wrote:
 On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote:
 On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com 
 wrote:
  Currently, when a geometry shader can't use dual object mode we fall back 
  to
  dual instance mode, however, when invocations == 1, single dispatch mode is
  more performant and equally efficient in terms of register pressure.
 
  Single dispatch mode requires that the driver can handle interleaving of
  registers, but this is already supported (dual instance mode has the same
  requirement).

Maybe this paragraph could use a minor clarification too? (Of what is
required vs. optional. And the fact that we're not doing the optional
one.)

  ---
   src/mesa/drivers/dri/i965/brw_context.h   |  8 ---
   src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 26 
  +++
   src/mesa/drivers/dri/i965/gen7_gs_state.c |  4 +---
   src/mesa/drivers/dri/i965/gen8_gs_state.c |  4 +---
   4 files changed, 20 insertions(+), 22 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
  b/src/mesa/drivers/dri/i965/brw_context.h
  index 1bbcf46..7439da1 100644
  --- a/src/mesa/drivers/dri/i965/brw_context.h
  +++ b/src/mesa/drivers/dri/i965/brw_context.h
  @@ -587,10 +587,12 @@ struct brw_gs_prog_data
  int invocations;
 
  /**
  -* True if the thread should be dispatched in DUAL_INSTANCE mode, 
  false if
  -* it should be dispatched in DUAL_OBJECT mode.
  +* Dispatch mode, can be any of:
  +* GEN7_GS_DISPATCH_MODE_DUAL_OBJECT
  +* GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE
  +* GEN7_GS_DISPATCH_MODE_SINGLE
   */
  -   bool dual_instanced_dispatch;
  +   int dispatch_mode;
   };
 
   /** Number of texture sampler units */
  diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
  b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  index b7995ad..c2a4892 100644
  --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
  @@ -101,10 +101,11 @@ vec4_gs_visitor::setup_payload()
   {
  int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
 
  -   /* If we are in dual instanced mode, then attributes are going to be
  -* interleaved, so one register contains two attribute slots.
  +   /* If we are in dual instanced or single mode, then attributes are 
  going
  +* to be interleaved, so one register contains two attribute slots.
   */
  -   int attributes_per_reg = c-prog_data.dual_instanced_dispatch ? 2 : 1;
  +   int attributes_per_reg =
  +  c-prog_data.dispatch_mode == GEN7_GS_DISPATCH_MODE_DUAL_OBJECT ? 1 
  : 2;
 
  /* If a geometry shader tries to read from an input that wasn't 
  written by
   * the vertex shader, that produces undefined results, but it shouldn't
  @@ -129,8 +130,7 @@ vec4_gs_visitor::setup_payload()
 
  reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
 
  -   lower_attributes_to_hw_regs(attribute_map,
  -   c-prog_data.dual_instanced_dispatch);
  +   lower_attributes_to_hw_regs(attribute_map, attributes_per_reg  1);
 
  this-first_non_payload_grf = reg;
   }
  @@ -640,7 +640,7 @@ brw_gs_emit(struct brw_context *brw,
   */
  if (c-prog_data.invocations = 1 
  likely(!(INTEL_DEBUG  DEBUG_NO_DUAL_OBJECT_GS))) {
  -  c-prog_data.dual_instanced_dispatch = false;
  +  c-prog_data.dispatch_mode = GEN7_GS_DISPATCH_MODE_DUAL_OBJECT;
 
 vec4_gs_visitor v(brw, c, prog, mem_ctx, true /* no_spills */);
 if (v.run()) {
  @@ -652,15 +652,15 @@ brw_gs_emit(struct brw_context *brw,
 
  /* Either we failed to compile in DUAL_OBJECT mode (probably because it
   * would have required spilling) or DUAL_OBJECT mode is disabled.  So 
  fall
  -* back to DUAL_INSTANCED mode, which consumes fewer registers.
  +* back to DUAL_INSTANCED or SINGLE mode, which consumes fewer 
  registers.
   *
  -* FIXME: In an ideal world we'd fall back to SINGLE mode, which would
  -* allow us to interleave general purpose registers (resulting in even 
  less
  -* likelihood of spilling).  But at the moment, the vec4 generator and
  -* visitor classes don't have the infrastructure to interleave general
  -* purpose registers, so DUAL_INSTANCED is the best we can do.

 I think Paul's note is still somewhat valid. Updates to the code gen
 could lead to improved register usage with single mode, right?

 So, we'll use single mode, but with the same register usage as dual instance.

 Oh, I got confused with this because I thought he was talking about the
 inputs for some reason, which are interleaved in both cases. I don't
 know why I got confused, since we clearly mentions the generator
 classes. But I see now that he is talking about the output.

 I'll keep the FIXME part of the comment.

I do think it needs a 

[Mesa-dev] [PATCH 3/3] i965: Handle ir_binop_ubo_load in boolean expression code.

2014-09-04 Thread Kenneth Graunke
UBO loads can be boolean-valued expressions, too, so we need to handle
them in emit_bool_to_cond_code() and emit_if_gen6().

However, unlike most expressions, it doesn't make sense to evaluate
their operands, then do something with the results.  We just want to
evaluate the UBO load as a whole---which performs the read from
memory---then load the boolean result into the flag register.

Instead of adding code to handle it, we can simply bypass the
ir_expression handling, and fall through to the default code, which will
do exactly that.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83468
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Ian Romanick i...@freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 4 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d7e3120..ff1e716 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2235,7 +2235,7 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
 {
ir_expression *expr = ir-as_expression();
 
-   if (!expr) {
+   if (!expr || expr-operation == ir_binop_ubo_load) {
   ir-accept(this);
 
   fs_inst *inst = emit(AND(reg_null_d, this-result, fs_reg(1)));
@@ -2363,7 +2363,7 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 {
ir_expression *expr = ir-condition-as_expression();
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   fs_reg op[3];
   fs_inst *inst;
   fs_reg temp;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 93ea63d..1e823da 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -776,7 +776,7 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
 
*predicate = BRW_PREDICATE_NORMAL;
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   src_reg op[3];
   vec4_instruction *inst;
 
@@ -897,7 +897,7 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
 {
ir_expression *expr = ir-condition-as_expression();
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   src_reg op[3];
   dst_reg temp;
 
-- 
2.1.0

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


[Mesa-dev] [PATCH 2/3] i965/fs: Make emit_if_gen6 never fall back to emit_bool_to_cond_code.

2014-09-04 Thread Kenneth Graunke
Matt and I believe that Sandybridge actually uses 0x for a
true comparison result, similar to Ivybridge.  This matches the
internal documentation, and empirical results, but contradicts the PRM.

So, the comment is inaccurate, and we can actually just handle these
directly without ever needing to fall through to the condition code
path.

Also, the vec4 backend has always done it this way, and has apparently
been working fine.  This patch makes the FS backend match the vec4
backend's behavior.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 8f2e1df..d7e3120 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2378,14 +2378,24 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 
   switch (expr-operation) {
   case ir_unop_logic_not:
+ emit(IF(op[0], fs_reg(0), BRW_CONDITIONAL_Z));
+ return;
+
   case ir_binop_logic_xor:
+ emit(IF(op[0], op[1], BRW_CONDITIONAL_NZ));
+ return;
+
   case ir_binop_logic_or:
+ temp = fs_reg(this, glsl_type::bool_type);
+ emit(OR(temp, op[0], op[1]));
+ emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+ return;
+
   case ir_binop_logic_and:
- /* For operations on bool arguments, only the low bit of the bool is
-  * valid, and the others are undefined.  Fall back to the condition
-  * code path.
-  */
- break;
+ temp = fs_reg(this, glsl_type::bool_type);
+ emit(AND(temp, op[0], op[1]));
+ emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+ return;
 
   case ir_unop_f2b:
 inst = emit(BRW_OPCODE_IF, reg_null_f, op[0], fs_reg(0));
@@ -2432,9 +2442,8 @@ fs_visitor::emit_if_gen6(ir_if *ir)
   }
}
 
-   emit_bool_to_cond_code(ir-condition);
-   fs_inst *inst = emit(BRW_OPCODE_IF);
-   inst-predicate = BRW_PREDICATE_NORMAL;
+   ir-condition-accept(this);
+   emit(IF(this-result, fs_reg(0), BRW_CONDITIONAL_NZ));
 }
 
 /**
-- 
2.1.0

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


[Mesa-dev] [PATCH 1/3] i965: Handle ir_triop_csel in emit_if_gen6().

2014-09-04 Thread Kenneth Graunke
ir_triop_csel can return a boolean expression, so we need to handle it
here; we simply forgot when we added ir_triop_csel, and forgot again
when adding it to emit_bool_to_cond_code.

Fixes Piglit's EXT_shader_integer_mix/{vs,fs}-mix-if-bool on Sandybridge.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 19 +--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 18 --
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ba163ec..8f2e1df 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2364,11 +2364,11 @@ fs_visitor::emit_if_gen6(ir_if *ir)
ir_expression *expr = ir-condition-as_expression();
 
if (expr) {
-  fs_reg op[2];
+  fs_reg op[3];
   fs_inst *inst;
   fs_reg temp;
 
-  assert(expr-get_num_operands() = 2);
+  assert(expr-get_num_operands() = 3);
   for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
 assert(expr-operands[i]-type-is_scalar());
 
@@ -2412,6 +2412,21 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 emit(IF(op[0], op[1],
  brw_conditional_for_comparison(expr-operation)));
 return;
+
+  case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ fs_inst *inst = emit(MOV(reg_null_d, op[0]));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to use as the result. */
+ fs_reg temp(this, expr-operands[1]-type);
+ inst = emit(SEL(temp, op[1], op[2]));
+ inst-predicate = BRW_PREDICATE_NORMAL;
+
+emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+return;
+  }
+
   default:
 unreachable(not reached);
   }
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 7de7755..93ea63d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -898,10 +898,10 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
ir_expression *expr = ir-condition-as_expression();
 
if (expr) {
-  src_reg op[2];
+  src_reg op[3];
   dst_reg temp;
 
-  assert(expr-get_num_operands() = 2);
+  assert(expr-get_num_operands() = 3);
   for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
 expr-operands[i]-accept(this);
 op[i] = this-result;
@@ -961,6 +961,20 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
 emit(IF(BRW_PREDICATE_ALIGN16_ANY4H));
 return;
 
+  case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ vec4_instruction *inst = emit(MOV(dst_null_d(), op[0]));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to return. */
+ dst_reg temp(this, expr-operands[1]-type);
+ inst = emit(BRW_OPCODE_SEL, temp, op[1], op[2]);
+ inst-predicate = BRW_PREDICATE_NORMAL;
+
+ emit(IF(src_reg(temp), src_reg(0), BRW_CONDITIONAL_NZ));
+ return;
+  }
+
   default:
 unreachable(not reached);
   }
-- 
2.1.0

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


Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.

2014-09-04 Thread Iago Toral Quiroga
On jue, 2014-09-04 at 00:07 -0700, Jordan Justen wrote:
 On Wed, Sep 3, 2014 at 11:28 PM, Iago Toral Quiroga ito...@igalia.com wrote:
  On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote:
  On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com 
  wrote:
   Currently, when a geometry shader can't use dual object mode we fall 
   back to
   dual instance mode, however, when invocations == 1, single dispatch mode 
   is
   more performant and equally efficient in terms of register pressure.
  
   Single dispatch mode requires that the driver can handle interleaving of
   registers, but this is already supported (dual instance mode has the same
   requirement).
 
 Maybe this paragraph could use a minor clarification too? (Of what is
 required vs. optional. And the fact that we're not doing the optional
 one.)

Sure. How about this?:

Single dispatch mode requires that the driver can handle interleaving of
input registers, but this is already supported (dual instance mode has
the same requirement). However, to take full advantage of single
dispatch mode to reduce register pressure we would also need to do
interleaved outputs, but currently, the vec4 visitor and generator
classes do not support this, so at the moment register pressure in
single and dual instance modes is the same.

   ---
src/mesa/drivers/dri/i965/brw_context.h   |  8 ---
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 26 
   +++
src/mesa/drivers/dri/i965/gen7_gs_state.c |  4 +---
src/mesa/drivers/dri/i965/gen8_gs_state.c |  4 +---
4 files changed, 20 insertions(+), 22 deletions(-)
  
   diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
   b/src/mesa/drivers/dri/i965/brw_context.h
   index 1bbcf46..7439da1 100644
   --- a/src/mesa/drivers/dri/i965/brw_context.h
   +++ b/src/mesa/drivers/dri/i965/brw_context.h
   @@ -587,10 +587,12 @@ struct brw_gs_prog_data
   int invocations;
  
   /**
   -* True if the thread should be dispatched in DUAL_INSTANCE mode, 
   false if
   -* it should be dispatched in DUAL_OBJECT mode.
   +* Dispatch mode, can be any of:
   +* GEN7_GS_DISPATCH_MODE_DUAL_OBJECT
   +* GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE
   +* GEN7_GS_DISPATCH_MODE_SINGLE
*/
   -   bool dual_instanced_dispatch;
   +   int dispatch_mode;
};
  
/** Number of texture sampler units */
   diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
   b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   index b7995ad..c2a4892 100644
   --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   @@ -101,10 +101,11 @@ vec4_gs_visitor::setup_payload()
{
   int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
  
   -   /* If we are in dual instanced mode, then attributes are going to be
   -* interleaved, so one register contains two attribute slots.
   +   /* If we are in dual instanced or single mode, then attributes are 
   going
   +* to be interleaved, so one register contains two attribute slots.
*/
   -   int attributes_per_reg = c-prog_data.dual_instanced_dispatch ? 2 : 
   1;
   +   int attributes_per_reg =
   +  c-prog_data.dispatch_mode == GEN7_GS_DISPATCH_MODE_DUAL_OBJECT ? 
   1 : 2;
  
   /* If a geometry shader tries to read from an input that wasn't 
   written by
* the vertex shader, that produces undefined results, but it 
   shouldn't
   @@ -129,8 +130,7 @@ vec4_gs_visitor::setup_payload()
  
   reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
  
   -   lower_attributes_to_hw_regs(attribute_map,
   -   c-prog_data.dual_instanced_dispatch);
   +   lower_attributes_to_hw_regs(attribute_map, attributes_per_reg  1);
  
   this-first_non_payload_grf = reg;
}
   @@ -640,7 +640,7 @@ brw_gs_emit(struct brw_context *brw,
*/
   if (c-prog_data.invocations = 1 
   likely(!(INTEL_DEBUG  DEBUG_NO_DUAL_OBJECT_GS))) {
   -  c-prog_data.dual_instanced_dispatch = false;
   +  c-prog_data.dispatch_mode = GEN7_GS_DISPATCH_MODE_DUAL_OBJECT;
  
  vec4_gs_visitor v(brw, c, prog, mem_ctx, true /* no_spills */);
  if (v.run()) {
   @@ -652,15 +652,15 @@ brw_gs_emit(struct brw_context *brw,
  
   /* Either we failed to compile in DUAL_OBJECT mode (probably because 
   it
* would have required spilling) or DUAL_OBJECT mode is disabled.  
   So fall
   -* back to DUAL_INSTANCED mode, which consumes fewer registers.
   +* back to DUAL_INSTANCED or SINGLE mode, which consumes fewer 
   registers.
*
   -* FIXME: In an ideal world we'd fall back to SINGLE mode, which 
   would
   -* allow us to interleave general purpose registers (resulting in 
   even less
   -* likelihood of spilling).  But at the moment, the vec4 generator 
   and
   -* visitor classes don't have 

[Mesa-dev] [PATCH] i965: Mark cfg dumping functions const.

2014-09-04 Thread Kenneth Graunke
The dump() methods don't alter the CFG or basic blocks, so we should
mark them as const.  This lets you call them even if you have a const
cfg_t - which is the case in certain portions of the code (such as live
interval handling).

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_cfg.cpp | 4 ++--
 src/mesa/drivers/dri/i965/brw_cfg.h   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp 
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 8714b68..e67b13a 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.cpp
+++ b/src/mesa/drivers/dri/i965/brw_cfg.cpp
@@ -145,7 +145,7 @@ bblock_t::combine_with(bblock_t *that)
 }
 
 void
-bblock_t::dump(backend_visitor *v)
+bblock_t::dump(backend_visitor *v) const
 {
int ip = this-start_ip;
for (backend_instruction *inst = (backend_instruction *)this-start;
@@ -420,7 +420,7 @@ cfg_t::make_block_array()
 }
 
 void
-cfg_t::dump(backend_visitor *v)
+cfg_t::dump(backend_visitor *v) const
 {
foreach_block (block, this) {
   fprintf(stderr, START B%d, block-num);
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.h 
b/src/mesa/drivers/dri/i965/brw_cfg.h
index ca6a2ac..7985a97 100644
--- a/src/mesa/drivers/dri/i965/brw_cfg.h
+++ b/src/mesa/drivers/dri/i965/brw_cfg.h
@@ -62,7 +62,7 @@ struct bblock_t {
bool is_successor_of(const bblock_t *block) const;
bool can_combine_with(const bblock_t *that) const;
void combine_with(bblock_t *that);
-   void dump(backend_visitor *v);
+   void dump(backend_visitor *v) const;
 #endif
 
struct exec_node link;
@@ -100,7 +100,7 @@ struct cfg_t {
void set_next_block(bblock_t **cur, bblock_t *block, int ip);
void make_block_array();
 
-   void dump(backend_visitor *v);
+   void dump(backend_visitor *v) const;
 #endif
void *mem_ctx;
 
-- 
2.0.0

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


[Mesa-dev] [PATCH] i965/fs: Pass block to insert and remove functions missed earlier.

2014-09-04 Thread Kenneth Graunke
From: Matt Turner matts...@gmail.com

Otherwise, the basic block start/end IPs don't get updated properly,
leading to a broken CFG.  This usually results in the following
assertion failure:

brw_fs_live_variables.cpp:141:
void brw::fs_live_variables::setup_def_use():
Assertion `ip == block-start_ip' failed.

Fixes KWin, WebGL demos, and a score of Piglit tests on Sandybridge and
earlier hardware.
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Here's a patch I cooked up that fixes all of the ip == block-start_ip
assertion failures that have shown up in all kinds of programs on
Sandybridge and earlier hardware.  Those platforms are basically unusable
without this patch.

I put Matt's authorship on it, because it's basically his patch with the
same name from his recent 20 patch series (awaiting review on the list),
but in a form that we can apply now, without taking the other 19 patches
(which could cause other regressions).  It seems worth fixing the major
problems now, and then evaluating the rest of the patches as usual.

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 5f98287..69982c5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2151,7 +2151,7 @@ fs_visitor::compute_to_mrf()
 
calculate_live_intervals();
 
-   foreach_in_list_safe(fs_inst, inst, instructions) {
+   foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
   int ip = next_ip;
   next_ip++;
 
@@ -2229,7 +2229,7 @@ fs_visitor::compute_to_mrf()
   scan_inst-dst.file = MRF;
   scan_inst-dst.reg = inst-dst.reg;
   scan_inst-saturate |= inst-saturate;
-  inst-remove();
+  inst-remove(block);
   progress = true;
}
break;
@@ -2342,7 +2342,7 @@ fs_visitor::try_rep_send()
 * destination registers in our block of MOVs.
 */
count = 0;
-   foreach_in_list_safe(fs_inst, inst, this-instructions) {
+   foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
   if (count == 0)
  start = inst;
   if (inst-opcode == BRW_OPCODE_MOV 
@@ -2381,9 +2381,9 @@ fs_visitor::try_rep_send()
  mov-dst.type = BRW_REGISTER_TYPE_F;
 
  /* Replace the four MOVs with the new vec4 MOV. */
- start-insert_before(mov);
+ start-insert_before(block, mov);
  for (i = 0; i  4; i++)
-mov-next-remove();
+((fs_inst *) mov-next)-remove(block);
 
  /* Finally, adjust the message length and set the opcode to
   * REP_FB_WRITE for the send, so that the generator will use the
@@ -3147,14 +3147,14 @@ fs_visitor::opt_drop_redundant_mov_to_flags()
 {
bool flag_mov_found[2] = {false};
 
-   foreach_in_list_safe(fs_inst, inst, instructions) {
+   foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
   if (inst-is_control_flow()) {
  memset(flag_mov_found, 0, sizeof(flag_mov_found));
   } else if (inst-opcode == FS_OPCODE_MOV_DISPATCH_TO_FLAGS) {
  if (!flag_mov_found[inst-flag_subreg])
 flag_mov_found[inst-flag_subreg] = true;
  else
-inst-remove();
+inst-remove(block);
   } else if (inst-writes_flag()) {
  flag_mov_found[inst-flag_subreg] = false;
   }
-- 
2.0.0

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


Re: [Mesa-dev] [PATCH 02/37] i965/gen6/gs: refactor gen6_gs_state

2014-09-04 Thread Jordan Justen
On Wed, Sep 3, 2014 at 11:33 PM, Iago Toral Quiroga ito...@igalia.com wrote:
 On mié, 2014-09-03 at 18:51 -0700, Jordan Justen wrote:
 Rather than:
 i965/gen6/gs: refactor gen6_gs_state

 How about something like:
 i965/gen6/gs: Skeleton for user GS program support

 Sure, that sounds good to me.

 (more below)

 On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com 
 wrote:
  From: Samuel Iglesias Gonsalvez sigles...@igalia.com
 
  Currently, gen6 only uses geometry shaders for transform feedback so the 
  state
  we emit is not suitable to accomodate general purpose, user-provided 
  geometry
  shaders. This patch paves the way to add these support and the needed
  3DSTATE_GS packet modifications for it.
 
  Previous code that emitted state to implement transform feedback in gen6 
  goes
  to upload_gs_state_adhoc_tf().
 
  Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
  ---
   src/mesa/drivers/dri/i965/gen6_gs_state.c | 105 
  ++
   1 file changed, 94 insertions(+), 11 deletions(-)
 
  diff --git a/src/mesa/drivers/dri/i965/gen6_gs_state.c 
  b/src/mesa/drivers/dri/i965/gen6_gs_state.c
  index 9648fb7..e132959 100644
  --- a/src/mesa/drivers/dri/i965/gen6_gs_state.c
  +++ b/src/mesa/drivers/dri/i965/gen6_gs_state.c
  @@ -31,7 +31,7 @@
   #include intel_batchbuffer.h
 
   static void
  -upload_gs_state(struct brw_context *brw)
  +upload_gs_state_for_tf(struct brw_context *brw)
   {
  /* Disable all the constant buffers. */
  BEGIN_BATCH(5);
  @@ -49,11 +49,11 @@ upload_gs_state(struct brw_context *brw)
 OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE);
 OUT_BATCH(0); /* no scratch space */
 OUT_BATCH((2  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
  -   (brw-ff_gs.prog_data-urb_read_length  
  GEN6_GS_URB_READ_LENGTH_SHIFT));
  +(brw-ff_gs.prog_data-urb_read_length  
  GEN6_GS_URB_READ_LENGTH_SHIFT));
 OUT_BATCH(((brw-max_gs_threads - 1)  GEN6_GS_MAX_THREADS_SHIFT) |
  -   GEN6_GS_STATISTICS_ENABLE |
  -   GEN6_GS_SO_STATISTICS_ENABLE |
  -   GEN6_GS_RENDERING_ENABLE);
  +GEN6_GS_STATISTICS_ENABLE |
  +GEN6_GS_SO_STATISTICS_ENABLE |
  +GEN6_GS_RENDERING_ENABLE);

 This looks like tabs to spaces conversion. For lines that need to be
 changed, it is good to do that conversion. But, in this case, the only
 change is the name of the function.

 Okay.

 You granted the reviewed-by anyway though, so I understand that this
 comment is only for reference. Or would you prefer that we remove these
 changes from the patch?

Could you clean it up? It makes review easier, both now, and in
looking back through the history. (also, git blame...)

Thanks,

-Jordan

 OUT_BATCH(GEN6_GS_SVBI_PAYLOAD_ENABLE |
   GEN6_GS_SVBI_POSTINCREMENT_ENABLE |
   (brw-ff_gs.prog_data-svbi_postincrement_value 
  @@ -65,24 +65,107 @@ upload_gs_state(struct brw_context *brw)
 OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
 OUT_BATCH(0); /* prog_bo */
 OUT_BATCH((0  GEN6_GS_SAMPLER_COUNT_SHIFT) |
  -   (0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
  +(0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
 OUT_BATCH(0); /* scratch space base offset */
 OUT_BATCH((1  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
  -   (0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
  -   (0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
  +(0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
  +(0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
 OUT_BATCH((0  GEN6_GS_MAX_THREADS_SHIFT) |
  -   GEN6_GS_STATISTICS_ENABLE |
  -   GEN6_GS_RENDERING_ENABLE);
  +GEN6_GS_STATISTICS_ENABLE |
  +GEN6_GS_RENDERING_ENABLE);
  +  OUT_BATCH(0);
  +  ADVANCE_BATCH();
  +   }
  +}
  +
  +static void
  +upload_gs_state(struct brw_context *brw)
  +{
  +   /* BRW_NEW_GEOMETRY_PROGRAM */
  +   bool active = brw-geometry_program;
  +   /* CACHE_NEW_GS_PROG */
  +   const struct brw_vec4_prog_data *prog_data = brw-gs.prog_data-base;
  +   const struct brw_stage_state *stage_state = brw-gs.base;
  +
  +   if (active) {
  +  /* FIXME: enable constant buffers */
  +  BEGIN_BATCH(5);
  +  OUT_BATCH(_3DSTATE_CONSTANT_GS  16 | (5 - 2));
  +  OUT_BATCH(0);
  +  OUT_BATCH(0);
 OUT_BATCH(0);
  +  OUT_BATCH(0);
  +  ADVANCE_BATCH();
  +
  +  BEGIN_BATCH(7);
  +  OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
  +  OUT_BATCH(stage_state-prog_offset);
  +
  +  /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled as it
  +   * was previously done for gen6.
  +   *
  +   * TODO: test with both disabled to see if the HW is behaving
  +   * as expected, like in gen7.
  +   */
  +  OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE |
  +

Re: [Mesa-dev] [PATCH] r600g, radeonsi: make sure there's enough CS space before resuming queries

2014-09-04 Thread Michel Dänzer

On 04.09.2014 07:07, Marek Olšák wrote:

From: Marek Olšák marek.ol...@amd.com

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

Cc: mesa-sta...@lists.freedesktop.org


If the fix should go to the 10.2 branch as well, that should be

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org


Reviewed-by: Michel Dänzer michel.daen...@amd.com


--
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/3] i965: Handle ir_triop_csel in emit_if_gen6().

2014-09-04 Thread Kenneth Graunke
ir_triop_csel can return a boolean expression, so we need to handle it
here; we simply forgot when we added ir_triop_csel, and forgot again
when adding it to emit_bool_to_cond_code.

Fixes Piglit's EXT_shader_integer_mix/{vs,fs}-mix-if-bool on Sandybridge.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 19 +--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 18 --
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ba163ec..8f2e1df 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2364,11 +2364,11 @@ fs_visitor::emit_if_gen6(ir_if *ir)
ir_expression *expr = ir-condition-as_expression();
 
if (expr) {
-  fs_reg op[2];
+  fs_reg op[3];
   fs_inst *inst;
   fs_reg temp;
 
-  assert(expr-get_num_operands() = 2);
+  assert(expr-get_num_operands() = 3);
   for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
 assert(expr-operands[i]-type-is_scalar());
 
@@ -2412,6 +2412,21 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 emit(IF(op[0], op[1],
  brw_conditional_for_comparison(expr-operation)));
 return;
+
+  case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ fs_inst *inst = emit(MOV(reg_null_d, op[0]));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to use as the result. */
+ fs_reg temp(this, expr-operands[1]-type);
+ inst = emit(SEL(temp, op[1], op[2]));
+ inst-predicate = BRW_PREDICATE_NORMAL;
+
+emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+return;
+  }
+
   default:
 unreachable(not reached);
   }
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 7de7755..93ea63d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -898,10 +898,10 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
ir_expression *expr = ir-condition-as_expression();
 
if (expr) {
-  src_reg op[2];
+  src_reg op[3];
   dst_reg temp;
 
-  assert(expr-get_num_operands() = 2);
+  assert(expr-get_num_operands() = 3);
   for (unsigned int i = 0; i  expr-get_num_operands(); i++) {
 expr-operands[i]-accept(this);
 op[i] = this-result;
@@ -961,6 +961,20 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
 emit(IF(BRW_PREDICATE_ALIGN16_ANY4H));
 return;
 
+  case ir_triop_csel: {
+ /* Expand the boolean condition into the flag register. */
+ vec4_instruction *inst = emit(MOV(dst_null_d(), op[0]));
+ inst-conditional_mod = BRW_CONDITIONAL_NZ;
+
+ /* Select which boolean to return. */
+ dst_reg temp(this, expr-operands[1]-type);
+ inst = emit(BRW_OPCODE_SEL, temp, op[1], op[2]);
+ inst-predicate = BRW_PREDICATE_NORMAL;
+
+ emit(IF(src_reg(temp), src_reg(0), BRW_CONDITIONAL_NZ));
+ return;
+  }
+
   default:
 unreachable(not reached);
   }
-- 
2.1.0

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


[Mesa-dev] [PATCH 2/3] i965/fs: Make emit_if_gen6 never fall back to emit_bool_to_cond_code.

2014-09-04 Thread Kenneth Graunke
Matt and I believe that Sandybridge actually uses 0x for a
true comparison result, similar to Ivybridge.  This matches the
internal documentation, and empirical results, but contradicts the PRM.

So, the comment is inaccurate, and we can actually just handle these
directly without ever needing to fall through to the condition code
path.

Also, the vec4 backend has always done it this way, and has apparently
been working fine.  This patch makes the FS backend match the vec4
backend's behavior.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

I'm not sure whether this is necessary for stable backporting or not.
It may be required by the next patch.  Probably shouldn't be, but I
haven't tried it.

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 8f2e1df..d7e3120 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2378,14 +2378,24 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 
   switch (expr-operation) {
   case ir_unop_logic_not:
+ emit(IF(op[0], fs_reg(0), BRW_CONDITIONAL_Z));
+ return;
+
   case ir_binop_logic_xor:
+ emit(IF(op[0], op[1], BRW_CONDITIONAL_NZ));
+ return;
+
   case ir_binop_logic_or:
+ temp = fs_reg(this, glsl_type::bool_type);
+ emit(OR(temp, op[0], op[1]));
+ emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+ return;
+
   case ir_binop_logic_and:
- /* For operations on bool arguments, only the low bit of the bool is
-  * valid, and the others are undefined.  Fall back to the condition
-  * code path.
-  */
- break;
+ temp = fs_reg(this, glsl_type::bool_type);
+ emit(AND(temp, op[0], op[1]));
+ emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
+ return;
 
   case ir_unop_f2b:
 inst = emit(BRW_OPCODE_IF, reg_null_f, op[0], fs_reg(0));
@@ -2432,9 +2442,8 @@ fs_visitor::emit_if_gen6(ir_if *ir)
   }
}
 
-   emit_bool_to_cond_code(ir-condition);
-   fs_inst *inst = emit(BRW_OPCODE_IF);
-   inst-predicate = BRW_PREDICATE_NORMAL;
+   ir-condition-accept(this);
+   emit(IF(this-result, fs_reg(0), BRW_CONDITIONAL_NZ));
 }
 
 /**
-- 
2.1.0

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


[Mesa-dev] [PATCH 3/3] i965: Handle ir_binop_ubo_load in boolean expression code.

2014-09-04 Thread Kenneth Graunke
UBO loads can be boolean-valued expressions, too, so we need to handle
them in emit_bool_to_cond_code() and emit_if_gen6().

However, unlike most expressions, it doesn't make sense to evaluate
their operands, then do something with the results.  We just want to
evaluate the UBO load as a whole---which performs the read from
memory---then load the boolean result into the flag register.

Instead of adding code to handle it, we can simply bypass the
ir_expression handling, and fall through to the default code, which will
do exactly that.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83468
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Ian Romanick i...@freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 4 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index d7e3120..ff1e716 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2235,7 +2235,7 @@ fs_visitor::emit_bool_to_cond_code(ir_rvalue *ir)
 {
ir_expression *expr = ir-as_expression();
 
-   if (!expr) {
+   if (!expr || expr-operation == ir_binop_ubo_load) {
   ir-accept(this);
 
   fs_inst *inst = emit(AND(reg_null_d, this-result, fs_reg(1)));
@@ -2363,7 +2363,7 @@ fs_visitor::emit_if_gen6(ir_if *ir)
 {
ir_expression *expr = ir-condition-as_expression();
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   fs_reg op[3];
   fs_inst *inst;
   fs_reg temp;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 93ea63d..1e823da 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -776,7 +776,7 @@ vec4_visitor::emit_bool_to_cond_code(ir_rvalue *ir,
 
*predicate = BRW_PREDICATE_NORMAL;
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   src_reg op[3];
   vec4_instruction *inst;
 
@@ -897,7 +897,7 @@ vec4_visitor::emit_if_gen6(ir_if *ir)
 {
ir_expression *expr = ir-condition-as_expression();
 
-   if (expr) {
+   if (expr  expr-operation != ir_binop_ubo_load) {
   src_reg op[3];
   dst_reg temp;
 
-- 
2.1.0

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


Re: [Mesa-dev] [PATCH 01/37] i965/gs: Use single dispatch mode as fallback to dual object mode when possible.

2014-09-04 Thread Jordan Justen
On Thu, Sep 4, 2014 at 12:36 AM, Iago Toral Quiroga ito...@igalia.com wrote:
 On jue, 2014-09-04 at 00:07 -0700, Jordan Justen wrote:
 On Wed, Sep 3, 2014 at 11:28 PM, Iago Toral Quiroga ito...@igalia.com 
 wrote:
  On mié, 2014-09-03 at 17:49 -0700, Jordan Justen wrote:
  On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com 
  wrote:
   Currently, when a geometry shader can't use dual object mode we fall 
   back to
   dual instance mode, however, when invocations == 1, single dispatch 
   mode is
   more performant and equally efficient in terms of register pressure.
  
   Single dispatch mode requires that the driver can handle interleaving of
   registers, but this is already supported (dual instance mode has the 
   same
   requirement).

 Maybe this paragraph could use a minor clarification too? (Of what is
 required vs. optional. And the fact that we're not doing the optional
 one.)

 Sure. How about this?:

 Single dispatch mode requires that the driver can handle interleaving of
 input registers, but this is already supported (dual instance mode has
 the same requirement). However, to take full advantage of single
 dispatch mode to reduce register pressure we would also need to do
 interleaved outputs, but currently, the vec4 visitor and generator
 classes do not support this, so at the moment register pressure in
 single and dual instance modes is the same.

   ---
src/mesa/drivers/dri/i965/brw_context.h   |  8 ---
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 26 
   +++
src/mesa/drivers/dri/i965/gen7_gs_state.c |  4 +---
src/mesa/drivers/dri/i965/gen8_gs_state.c |  4 +---
4 files changed, 20 insertions(+), 22 deletions(-)
  
   diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
   b/src/mesa/drivers/dri/i965/brw_context.h
   index 1bbcf46..7439da1 100644
   --- a/src/mesa/drivers/dri/i965/brw_context.h
   +++ b/src/mesa/drivers/dri/i965/brw_context.h
   @@ -587,10 +587,12 @@ struct brw_gs_prog_data
   int invocations;
  
   /**
   -* True if the thread should be dispatched in DUAL_INSTANCE mode, 
   false if
   -* it should be dispatched in DUAL_OBJECT mode.
   +* Dispatch mode, can be any of:
   +* GEN7_GS_DISPATCH_MODE_DUAL_OBJECT
   +* GEN7_GS_DISPATCH_MODE_DUAL_INSTANCE
   +* GEN7_GS_DISPATCH_MODE_SINGLE
*/
   -   bool dual_instanced_dispatch;
   +   int dispatch_mode;
};
  
/** Number of texture sampler units */
   diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
   b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   index b7995ad..c2a4892 100644
   --- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
   @@ -101,10 +101,11 @@ vec4_gs_visitor::setup_payload()
{
   int attribute_map[BRW_VARYING_SLOT_COUNT * MAX_GS_INPUT_VERTICES];
  
   -   /* If we are in dual instanced mode, then attributes are going to be
   -* interleaved, so one register contains two attribute slots.
   +   /* If we are in dual instanced or single mode, then attributes are 
   going
   +* to be interleaved, so one register contains two attribute slots.
*/
   -   int attributes_per_reg = c-prog_data.dual_instanced_dispatch ? 2 : 
   1;
   +   int attributes_per_reg =
   +  c-prog_data.dispatch_mode == GEN7_GS_DISPATCH_MODE_DUAL_OBJECT 
   ? 1 : 2;
  
   /* If a geometry shader tries to read from an input that wasn't 
   written by
* the vertex shader, that produces undefined results, but it 
   shouldn't
   @@ -129,8 +130,7 @@ vec4_gs_visitor::setup_payload()
  
   reg = setup_varying_inputs(reg, attribute_map, attributes_per_reg);
  
   -   lower_attributes_to_hw_regs(attribute_map,
   -   c-prog_data.dual_instanced_dispatch);
   +   lower_attributes_to_hw_regs(attribute_map, attributes_per_reg  1);
  
   this-first_non_payload_grf = reg;
}
   @@ -640,7 +640,7 @@ brw_gs_emit(struct brw_context *brw,
*/
   if (c-prog_data.invocations = 1 
   likely(!(INTEL_DEBUG  DEBUG_NO_DUAL_OBJECT_GS))) {
   -  c-prog_data.dual_instanced_dispatch = false;
   +  c-prog_data.dispatch_mode = GEN7_GS_DISPATCH_MODE_DUAL_OBJECT;
  
  vec4_gs_visitor v(brw, c, prog, mem_ctx, true /* no_spills */);
  if (v.run()) {
   @@ -652,15 +652,15 @@ brw_gs_emit(struct brw_context *brw,
  
   /* Either we failed to compile in DUAL_OBJECT mode (probably 
   because it
* would have required spilling) or DUAL_OBJECT mode is disabled.  
   So fall
   -* back to DUAL_INSTANCED mode, which consumes fewer registers.
   +* back to DUAL_INSTANCED or SINGLE mode, which consumes fewer 
   registers.
*
   -* FIXME: In an ideal world we'd fall back to SINGLE mode, which 
   would
   -* allow us to interleave general purpose registers (resulting in 
   even less
   -* likelihood of 

Re: [Mesa-dev] [PATCH 02/37] i965/gen6/gs: refactor gen6_gs_state

2014-09-04 Thread Iago Toral Quiroga
On jue, 2014-09-04 at 00:44 -0700, Jordan Justen wrote:
 On Wed, Sep 3, 2014 at 11:33 PM, Iago Toral Quiroga ito...@igalia.com wrote:
  On mié, 2014-09-03 at 18:51 -0700, Jordan Justen wrote:
  Rather than:
  i965/gen6/gs: refactor gen6_gs_state
 
  How about something like:
  i965/gen6/gs: Skeleton for user GS program support
 
  Sure, that sounds good to me.
 
  (more below)
 
  On Thu, Aug 14, 2014 at 4:11 AM, Iago Toral Quiroga ito...@igalia.com 
  wrote:
   From: Samuel Iglesias Gonsalvez sigles...@igalia.com
  
   Currently, gen6 only uses geometry shaders for transform feedback so the 
   state
   we emit is not suitable to accomodate general purpose, user-provided 
   geometry
   shaders. This patch paves the way to add these support and the needed
   3DSTATE_GS packet modifications for it.
  
   Previous code that emitted state to implement transform feedback in gen6 
   goes
   to upload_gs_state_adhoc_tf().
  
   Signed-off-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
   ---
src/mesa/drivers/dri/i965/gen6_gs_state.c | 105 
   ++
1 file changed, 94 insertions(+), 11 deletions(-)
  
   diff --git a/src/mesa/drivers/dri/i965/gen6_gs_state.c 
   b/src/mesa/drivers/dri/i965/gen6_gs_state.c
   index 9648fb7..e132959 100644
   --- a/src/mesa/drivers/dri/i965/gen6_gs_state.c
   +++ b/src/mesa/drivers/dri/i965/gen6_gs_state.c
   @@ -31,7 +31,7 @@
#include intel_batchbuffer.h
  
static void
   -upload_gs_state(struct brw_context *brw)
   +upload_gs_state_for_tf(struct brw_context *brw)
{
   /* Disable all the constant buffers. */
   BEGIN_BATCH(5);
   @@ -49,11 +49,11 @@ upload_gs_state(struct brw_context *brw)
  OUT_BATCH(GEN6_GS_SPF_MODE | GEN6_GS_VECTOR_MASK_ENABLE);
  OUT_BATCH(0); /* no scratch space */
  OUT_BATCH((2  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
   -   (brw-ff_gs.prog_data-urb_read_length  
   GEN6_GS_URB_READ_LENGTH_SHIFT));
   +(brw-ff_gs.prog_data-urb_read_length  
   GEN6_GS_URB_READ_LENGTH_SHIFT));
  OUT_BATCH(((brw-max_gs_threads - 1)  
   GEN6_GS_MAX_THREADS_SHIFT) |
   -   GEN6_GS_STATISTICS_ENABLE |
   -   GEN6_GS_SO_STATISTICS_ENABLE |
   -   GEN6_GS_RENDERING_ENABLE);
   +GEN6_GS_STATISTICS_ENABLE |
   +GEN6_GS_SO_STATISTICS_ENABLE |
   +GEN6_GS_RENDERING_ENABLE);
 
  This looks like tabs to spaces conversion. For lines that need to be
  changed, it is good to do that conversion. But, in this case, the only
  change is the name of the function.
 
  Okay.
 
  You granted the reviewed-by anyway though, so I understand that this
  comment is only for reference. Or would you prefer that we remove these
  changes from the patch?
 
 Could you clean it up? It makes review easier, both now, and in
 looking back through the history. (also, git blame...)
 
 Thanks,

Sure, no problem.

Iago

 -Jordan
 
  OUT_BATCH(GEN6_GS_SVBI_PAYLOAD_ENABLE |
GEN6_GS_SVBI_POSTINCREMENT_ENABLE |
(brw-ff_gs.prog_data-svbi_postincrement_value 
   @@ -65,24 +65,107 @@ upload_gs_state(struct brw_context *brw)
  OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
  OUT_BATCH(0); /* prog_bo */
  OUT_BATCH((0  GEN6_GS_SAMPLER_COUNT_SHIFT) |
   -   (0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
   +(0  GEN6_GS_BINDING_TABLE_ENTRY_COUNT_SHIFT));
  OUT_BATCH(0); /* scratch space base offset */
  OUT_BATCH((1  GEN6_GS_DISPATCH_START_GRF_SHIFT) |
   -   (0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
   -   (0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
   +(0  GEN6_GS_URB_READ_LENGTH_SHIFT) |
   +(0  GEN6_GS_URB_ENTRY_READ_OFFSET_SHIFT));
  OUT_BATCH((0  GEN6_GS_MAX_THREADS_SHIFT) |
   -   GEN6_GS_STATISTICS_ENABLE |
   -   GEN6_GS_RENDERING_ENABLE);
   +GEN6_GS_STATISTICS_ENABLE |
   +GEN6_GS_RENDERING_ENABLE);
   +  OUT_BATCH(0);
   +  ADVANCE_BATCH();
   +   }
   +}
   +
   +static void
   +upload_gs_state(struct brw_context *brw)
   +{
   +   /* BRW_NEW_GEOMETRY_PROGRAM */
   +   bool active = brw-geometry_program;
   +   /* CACHE_NEW_GS_PROG */
   +   const struct brw_vec4_prog_data *prog_data = 
   brw-gs.prog_data-base;
   +   const struct brw_stage_state *stage_state = brw-gs.base;
   +
   +   if (active) {
   +  /* FIXME: enable constant buffers */
   +  BEGIN_BATCH(5);
   +  OUT_BATCH(_3DSTATE_CONSTANT_GS  16 | (5 - 2));
   +  OUT_BATCH(0);
   +  OUT_BATCH(0);
  OUT_BATCH(0);
   +  OUT_BATCH(0);
   +  ADVANCE_BATCH();
   +
   +  BEGIN_BATCH(7);
   +  OUT_BATCH(_3DSTATE_GS  16 | (7 - 2));
   +  OUT_BATCH(stage_state-prog_offset);
   +
   +  /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled as 
   it
   +   * was previously done 

Re: [Mesa-dev] SandyBridge issue likely related to fast color clears using meta operations

2014-09-04 Thread Samuel Iglesias Gonsálvez
On Wed, 2014-09-03 at 15:00 -0700, Jordan Justen wrote:
 On 2014-09-03 10:41:02, Kenneth Graunke wrote:
  On Tuesday, September 02, 2014 06:16:01 PM Samuel Iglesias Gonsálvez wrote:
   Hello,
   
   Two weeks ago, Iago and myself sent a batch of patches that added
   geometry shader support for SandyBridge [0].
   
   Recently, we rebased our patches against master [1] and found
   that some things are not working properly any more. Particularly, we
   have plenty of cases where we only get a black screen when using a
   geometry shader, and in these cases it seems as if some outputs of the
   geometry shader got lost by the time they become inputs in the
   fragment shader (some input varyings in the fragment shader that come
   from the outputs of the geometry seem to be zeroed). The values we
   output in the geometry shader are correct though, since they are
   correctly captured by transform feedback.
   
   A bisect shows that the commit that introduced this problem is
   2f28a0dc231 i965: Implement fast color clears using meta operations [2].
   
   Reverting this commit fixes the problem for us. The revert also fixes
   piglit's bin/gl-3.2-layered-rendering-clear-color* tests in SandyBridge
   [3].
   
   So the question is whether the commit mentioned above introduces a
   regression that should be fixed somewhere or if our code needs to be
   updated to adapt to changes introduced by that commit in some way.
   
   Best regards,
   
   Sam
  
  Hi Sam,
  
  Layered clears now use GL_AMD_vertex_shader_layered.  If you expose
  the extension, then gl-3.2-layered-rendering-clear-color starts
  passing again.  Otherwise, the vertex shader code to set gl_LayerID
  = gl_InstanceID is #ifdef'd out, so only layer 0 would get affected.
  

Exposing the extension fixes the issue for our tests and piglit's
bin/gl-3.2-layered-rendering-clear-color* tests :-)

  I'm not sure if we can expose that extension without GL 3.2, so you
  might just put the patch to enable it (simply editing
  intel_extensions.c) near the end of your series.  Perhaps Jordan
  will know if we can just turn it on now.
 
 Yes, We should be able to enable GL_AMD_vertex_shader_layered for gen6
 now. But, it really only makes sense to enable it at the same time as
 enabling 3.2 so the glFramebufferTexture function is available.
 
 Due to this meta quirk, it sounds like we should enable them both in
 the same patch. (Or, perhaps the extension in the patch just before
 3.2. ??)

We are going to add it in the same patch where OpenGL 3.2 is enabled.

Thanks!

Sam




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


[Mesa-dev] [Bug 83485] Requesting a New Account

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83485

Samuel Iglesias sigles...@igalia.com changed:

   What|Removed |Added

   Assignee|sitewranglers@lists.freedes |mesa-dev@lists.freedesktop.
   |ktop.org|org
Product|freedesktop.org |Mesa
  Component|New Accounts|Other

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


Re: [Mesa-dev] [PATCH] configure.ac: Add AC_SYS_LARGEFILE

2014-09-04 Thread Emil Velikov
On 03/09/14 04:38, Michel Dänzer wrote:
 On 03.09.2014 06:50, Emil Velikov wrote:
 On 02/09/14 08:17, Michel Dänzer wrote:

 diff --git a/src/gallium/auxiliary/os/os_mman.h
 b/src/gallium/auxiliary/os/os_mman.h
 index b48eb053..19478d2 100644
 --- a/src/gallium/auxiliary/os/os_mman.h
 +++ b/src/gallium/auxiliary/os/os_mman.h
 @@ -40,9 +40,6 @@
   #include pipe/p_compiler.h

   #if defined(PIPE_OS_UNIX)
 -#  ifndef _FILE_OFFSET_BITS
 -#error _FILE_OFFSET_BITS must be defined to 64
 -#  endif
 Can you leave the above hunk, afaics it serves as a safeguard which is always
 a nice thing to have :)
 
 AC_SYS_LARGEFILE doesn't define _FILE_OFFSET_BITS on 64-bit, because it's not
 necessary there for large file support. That's why I converted the configure
 script check generated by AC_SYS_LARGEFILE to the STATIC_ASSERT below instead.
 I just double-checked that the STATIC_ASSERT fails on 32-bit without
 AC_SYS_LARGEFILE but passes with it.
 
You're absolutely correct. I was under the naive impression that it will be
available (for compat reasons) on 64bit systems.

v2 of the patch looks good imho.

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


[Mesa-dev] [Bug 82882] [swrast] piglit glsl-fs-uniform-bool-1 regression

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82882

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

 CC||pavel.ondra...@email.cz

--- Comment #1 from Pavel Ondračka pavel.ondra...@email.cz ---
This commit also regressed about 20 tests for r300g driver.
Some examples of failing tests:
spec/glsl-1.10/execution/built-in-functions/fs-all-bvec3.shader_test
spec/glsl-1.10/execution/built-in-functions/fs-not-bvec2.shader_test
spec/glsl-1.10/execution/built-in-functions/fs-op-not-bool.shader_test
spec/glsl-1.20/execution/uniform-initializer/fs-bool-set-by-API.shader_test
glsl-1.10/execution/built-in-functions/vs-op-selection-bool-bvec3-bvec3.shader_test

and more...

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


[Mesa-dev] [PATCH] winsys/svga: Fix incorrect type usage in IOCTL

2014-09-04 Thread Thomas Hellstrom
While similar in layout, the size of the SVGA3dSize type may be smaller than
the struct drm_vmw_size type that is part of the ioctl interface. The kernel
driver could accordingly overwrite a memory area following the size variable
on the stack. Typically that would be another local variable, causing
breakage in, for example, ubuntu 12.04.5 where the handle local variable
becomes overwritten.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Cc: 10.1 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
 src/gallium/winsys/svga/drm/vmw_screen_dri.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c 
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 79a1b3e..7b170b0 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -238,7 +238,7 @@ out_mip:
 
 static struct svga_winsys_surface *
 vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
-   struct winsys_handle *whandle,
+struct winsys_handle *whandle,
SVGA3dSurfaceFormat *format)
 {
 struct vmw_svga_winsys_surface *vsrf;
@@ -248,7 +248,8 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 struct drm_vmw_surface_arg *req = arg.req;
 struct drm_vmw_surface_create_req *rep = arg.rep;
 uint32_t handle = 0;
-SVGA3dSize size;
+struct drm_vmw_size size;
+SVGA3dSize base_size;
 int ret;
 int i;
 
@@ -274,7 +275,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 
 memset(arg, 0, sizeof(arg));
 req-sid = handle;
-rep-size_addr = (size_t)size;
+rep-size_addr = (unsigned long)size;
 
 ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_REF_SURFACE,
  arg, sizeof(arg));
@@ -324,7 +325,11 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 *format = rep-format;
 
 /* Estimate usage, for early flushing. */
-vsrf-size = svga3dsurface_get_serialized_size(rep-format, size,
+
+base_size.width = size.width;
+base_size.height = size.height;
+base_size.depth = size.depth;
+vsrf-size = svga3dsurface_get_serialized_size(rep-format, base_size,
rep-mip_levels[0],
FALSE);
 
-- 
1.8.3.2

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


Re: [Mesa-dev] [PATCH 01/20] glapi: add ARB_gpu_shader_fp64 (v2)

2014-09-04 Thread Kai Wasserbäch
Hi Dave,
just a small comment, since I'm not really the right person to review this 
patch:

Dave Airlie schrieb am 04.09.2014 06:15:
 [...]
 diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
 b/src/mesa/main/tests/dispatch_sanity.cpp
 index 04fa86b..00f9b19 100644
 --- a/src/mesa/main/tests/dispatch_sanity.cpp
 +++ b/src/mesa/main/tests/dispatch_sanity.cpp
 @@ -669,24 +669,24 @@ const struct function gl_core_functions_possible[] = {
 { glVertexAttribP4uiv, 43, -1 },
 { glDrawArraysIndirect, 43, -1 },
 { glDrawElementsIndirect, 43, -1 },
 -// { glUniform1d, 43, -1 },   // XXX: Add to xml
 -// { glUniform2d, 43, -1 },   // XXX: Add to xml
 -// { glUniform3d, 43, -1 },   // XXX: Add to xml
 -// { glUniform4d, 43, -1 },   // XXX: Add to xml
 -// { glUniform1dv, 43, -1 },  // XXX: Add to xml
 -// { glUniform2dv, 43, -1 },  // XXX: Add to xml
 -// { glUniform3dv, 43, -1 },  // XXX: Add to xml
 -// { glUniform4dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix2dv, 43, -1 },// XXX: Add to xml
 -// { glUniformMatrix3dv, 43, -1 },// XXX: Add to xml
 -// { glUniformMatrix4dv, 43, -1 },// XXX: Add to xml
 -// { glUniformMatrix2x3dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix2x4dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix3x2dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix3x4dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix4x2dv, 43, -1 },  // XXX: Add to xml
 -// { glUniformMatrix4x3dv, 43, -1 },  // XXX: Add to xml
 -// { glGetUniformdv, 43, -1 },// XXX: Add to xml
 +   { glUniform1d, 40, -1 },
 +   { glUniform2d, 40, -1 },
 +   { glUniform3d, 40, -1 },
 +   { glUniform4d, 40, -1 },
 +   { glUniform1dv, 40, -1 },
 +   { glUniform2dv, 40, -1 },
 +   { glUniform3dv, 40, -1 },
 +   { glUniform4dv, 40, -1 },
 +   { glUniformMatrix2dv, 40, -1 },
 +   { glUniformMatrix3dv, 40, -1 },
 +   { glUniformMatrix4dv, 40, -1 },
 +   { glUniformMatrix2x3dv, 40, -1 },
 +   { glUniformMatrix2x4dv, 40, -1 },
 +   { glUniformMatrix3x2dv, 40, -1 },
 +   { glUniformMatrix3x4dv, 40, -1 },
 +   { glUniformMatrix4x2dv, 40, -1 },
 +   { glUniformMatrix4x3dv, 40, -1 },
 +   { glGetUniformdv, 43, -1 },
  ^^
Shouldn't this be a 40 as well?

Cheers,
Kai



-- 

Kai Wasserbäch (Kai Wasserbaech)

E-Mail: k...@dev.carbon-project.org



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


[Mesa-dev] [PATCH] winsys/svga: Fix incorrect type usage in IOCTL v2

2014-09-04 Thread Thomas Hellstrom
While similar in layout, the size of the SVGA3dSize type may be smaller than
the struct drm_vmw_size type that is part of the ioctl interface. The kernel
driver could accordingly overwrite a memory area following the size variable
on the stack. Typically that would be another local variable, causing
breakage in, for example, ubuntu 12.04.5 where the handle local variable
becomes overwritten.

v2: Fix whitespace errors

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
Cc: 10.1 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
 src/gallium/winsys/svga/drm/vmw_screen_dri.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c 
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 79a1b3e..9f33590 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -238,7 +238,7 @@ out_mip:
 
 static struct svga_winsys_surface *
 vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
-   struct winsys_handle *whandle,
+struct winsys_handle *whandle,
SVGA3dSurfaceFormat *format)
 {
 struct vmw_svga_winsys_surface *vsrf;
@@ -248,7 +248,8 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 struct drm_vmw_surface_arg *req = arg.req;
 struct drm_vmw_surface_create_req *rep = arg.rep;
 uint32_t handle = 0;
-SVGA3dSize size;
+struct drm_vmw_size size;
+SVGA3dSize base_size;
 int ret;
 int i;
 
@@ -274,7 +275,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 
 memset(arg, 0, sizeof(arg));
 req-sid = handle;
-rep-size_addr = (size_t)size;
+rep-size_addr = (unsigned long)size;
 
 ret = drmCommandWriteRead(vws-ioctl.drm_fd, DRM_VMW_REF_SURFACE,
  arg, sizeof(arg));
@@ -324,7 +325,11 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
 *format = rep-format;
 
 /* Estimate usage, for early flushing. */
-vsrf-size = svga3dsurface_get_serialized_size(rep-format, size,
+
+base_size.width = size.width;
+base_size.height = size.height;
+base_size.depth = size.depth;
+vsrf-size = svga3dsurface_get_serialized_size(rep-format, base_size,
rep-mip_levels[0],
FALSE);
 
-- 
1.8.3.2

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


[Mesa-dev] [Bug 82882] [swrast] piglit glsl-fs-uniform-bool-1 regression

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82882

--- Comment #2 from Marek Olšák mar...@gmail.com ---
Created attachment 105739
  -- https://bugs.freedesktop.org/attachment.cgi?id=105739action=edit
r300g hack

Pavel, does this patch fix r300g? It's a hack, I just need to confirm whether
it works.

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


[Mesa-dev] [Bug 82882] [swrast] piglit glsl-fs-uniform-bool-1 regression

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82882

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

 Attachment #105739|0   |1
is obsolete||

--- Comment #3 from Marek Olšák mar...@gmail.com ---
Created attachment 105742
  -- https://bugs.freedesktop.org/attachment.cgi?id=105742action=edit
gallium fix

Scratch that. A new patch is attached. Could you please test it on r300g?

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


[Mesa-dev] [Bug 82882] [swrast] piglit glsl-fs-uniform-bool-1 regression

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82882

--- Comment #4 from Marek Olšák mar...@gmail.com ---
Created attachment 105743
  -- https://bugs.freedesktop.org/attachment.cgi?id=105743action=edit
swrast fix

Vinson, could you please test if this attached patch fixes classic swrast?

Thanks.

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


[Mesa-dev] [Bug 82538] Super Maryo Chronicles fails with st/mesa assertion failure

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82538

Marek Olšák mar...@gmail.com changed:

   What|Removed |Added

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

--- Comment #6 from Marek Olšák mar...@gmail.com ---
Fixed by 374f3e9e19f064007ea8a864fbd00f1ae7deafd1. Closing.

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


[Mesa-dev] [Bug 82882] [swrast] piglit glsl-fs-uniform-bool-1 regression

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=82882

--- Comment #5 from Pavel Ondračka pavel.ondra...@email.cz ---
(In reply to comment #3)
 Created attachment 105742 [details] [review]
 gallium fix
 
 Scratch that. A new patch is attached. Could you please test it on r300g?

Yes, that fixes it.

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


[Mesa-dev] [PATCH 2/2] st/mesa: use 1.0f as boolean true on drivers without integer support

2014-09-04 Thread Marek Olšák
From: Marek Olšák marek.ol...@amd.com

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

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
 src/mesa/state_tracker/st_extensions.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 9db648c..286c56a 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -34,6 +34,7 @@
 #include pipe/p_context.h
 #include pipe/p_defines.h
 #include pipe/p_screen.h
+#include util/u_math.h
 
 #include st_context.h
 #include st_extensions.h
@@ -274,8 +275,6 @@ void st_init_limits(struct pipe_screen *screen,
c-MinProgramTextureGatherOffset = screen-get_param(screen, 
PIPE_CAP_MIN_TEXTURE_GATHER_OFFSET);
c-MaxProgramTextureGatherOffset = screen-get_param(screen, 
PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET);
 
-   c-UniformBooleanTrue = ~0;
-
c-MaxTransformFeedbackBuffers =
   screen-get_param(screen, PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS);
c-MaxTransformFeedbackBuffers = MIN2(c-MaxTransformFeedbackBuffers, 
MAX_FEEDBACK_BUFFERS);
@@ -700,6 +699,8 @@ void st_init_extensions(struct pipe_screen *screen,
   }
}
 
+   consts-UniformBooleanTrue = consts-NativeIntegers ? ~0 : fui(1.0f);
+
/* Below are the cases which cannot be moved into tables easily. */
 
if (!has_lib_dxtc  !options-force_s3tc_enable) {
-- 
1.9.1

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


[Mesa-dev] [PATCH 1/2] mesa: set UniformBooleanTrue = 1.0f by default

2014-09-04 Thread Marek Olšák
From: Marek Olšák marek.ol...@amd.com

because NativeIntegers is 0 by default.

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

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---

Untested. This should fix swrast. See the bugzilla link above.
The second patch fixes the same issue for Gallium/r300g.

 src/mesa/main/context.c | 3 +++
 src/mesa/main/macros.h  | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index fbdbd68..8b5693e 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -653,6 +653,9 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
api)
/* GL_ARB_framebuffer_object */
consts-MaxSamples = 0;
 
+   /* GLSL default if NativeIntegers == FALSE */
+   consts-UniformBooleanTrue = FLT_AS_UINT(1.0f);
+
/* GL_ARB_sync */
consts-MaxServerWaitTimeout = 0x1fff7fffULL;
 
diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index 0ba658a..2d54ca5 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -184,6 +184,13 @@ static inline GLfloat UINT_AS_FLT(GLuint u)
return tmp.f;
 }
 
+static inline unsigned FLT_AS_UINT(float f)
+{
+   fi_type tmp;
+   tmp.f = f;
+   return tmp.u;
+}
+
 /**
  * Convert a floating point value to an unsigned fixed point value.
  *
-- 
1.9.1

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


Re: [Mesa-dev] Mesa (10.2): gallivm: Fix build with LLVM = 3.6 r215967.

2014-09-04 Thread Emil Velikov
On 03/09/14 04:45, Michel Dänzer wrote:
 On 03.09.2014 04:53, Emil Velikov wrote:
 Module: Mesa
 Branch: 10.2
 Commit: 3fe59905fc684f64508982d405031771e273e656
 URL:   
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=3fe59905fc684f64508982d405031771e273e656


 Author: Vinson Lee v...@freedesktop.org
 Date:   Tue Aug 19 23:17:40 2014 -0700

 gallivm: Fix build with LLVM = 3.6 r215967.
 
 I don't think it's worth backporting build fixes for LLVM SVN trunk. Given the
 LLVM development model, supporting anything but released versions of LLVM on
 Mesa stable branches is futile.
 
 
Marek requested this commit to be picked to stable, and it made sense to me.
As you wish I will omit/reject such patches from now on.

Cheers,
Emil
P.S. If a commit has been nominated at a later stage I'm adding the
Nominated-by tag, to ease cases such as this one :)


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


Re: [Mesa-dev] [PATCH 1/1] configure.ac: Fix build with git-svn llvm version string

2014-09-04 Thread Jan Vesely
On Thu, 2014-08-14 at 11:15 -0400, Jan Vesely wrote:
 On Thu, 2014-08-14 at 06:35 -0700, Tom Stellard wrote:
  On Wed, Aug 13, 2014 at 04:46:56PM -0400, Jan Vesely wrote:
   Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
   ---
   
   My llvm-config --version is
   3.6.0git-svn-r215564-cd35a3b3
   
   This patch assumes that the interesting part consists of only digits and 
   dots.
   
   
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
   
   diff --git a/configure.ac b/configure.ac
   index 4ff87eb..dc5117e 100644
   --- a/configure.ac
   +++ b/configure.ac
   @@ -1697,7 +1697,7 @@ if test x$enable_gallium_llvm = xyes; then
fi

if test x$LLVM_CONFIG != xno; then
   -LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/svn.*//g'`
   +LLVM_VERSION=`$LLVM_CONFIG --version | sed 's/[[^0-9.]].*//g'`
  
  As long as we are changing this.  I think it would be simpler to use grep:
  
  `$LLVM_CONFIG --version | grep -o '^[[0-9.]]\+'`

hi,

should I post another patch, or do you plan to push your version?

thanks,
jan

 
 I agree. I didn't know about grep -o.
 It fixes my issue.
 
 Reviewed-and-tested-by: Jan Vesely jan.ves...@rutgers.edu
 
 jan
 
  
  -Tom
  
LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
LLVM_BINDIR=`$LLVM_CONFIG --bindir`
LLVM_CPPFLAGS=`strip_unwanted_llvm_flags $LLVM_CONFIG 
   --cppflags`
   -- 
   1.9.3
   
   ___
   mesa-dev mailing list
   mesa-dev@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

-- 
Jan Vesely jan.ves...@rutgers.edu


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


Re: [Mesa-dev] Mesa (10.2): gallivm: Fix build with LLVM = 3.6 r215967.

2014-09-04 Thread Marek Olšák
Yeah, Michel is right.

Marek

On Thu, Sep 4, 2014 at 4:35 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
 On 03/09/14 04:45, Michel Dänzer wrote:
 On 03.09.2014 04:53, Emil Velikov wrote:
 Module: Mesa
 Branch: 10.2
 Commit: 3fe59905fc684f64508982d405031771e273e656
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=3fe59905fc684f64508982d405031771e273e656


 Author: Vinson Lee v...@freedesktop.org
 Date:   Tue Aug 19 23:17:40 2014 -0700

 gallivm: Fix build with LLVM = 3.6 r215967.

 I don't think it's worth backporting build fixes for LLVM SVN trunk. Given 
 the
 LLVM development model, supporting anything but released versions of LLVM on
 Mesa stable branches is futile.


 Marek requested this commit to be picked to stable, and it made sense to me.
 As you wish I will omit/reject such patches from now on.

 Cheers,
 Emil
 P.S. If a commit has been nominated at a later stage I'm adding the
 Nominated-by tag, to ease cases such as this one :)


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


Re: [Mesa-dev] [PATCH 05/20] mesa: add double uniform support. (v2)

2014-09-04 Thread Brian Paul

On 09/03/2014 10:15 PM, Dave Airlie wrote:

From: Dave Airlie airl...@redhat.com

This adds support for the new uniform interfaces
from ARB_gpu_shader_fp64.

v2:
support ARB_separate_shader_objects ProgramUniform*d* (Ian)
don't allow boolean uniforms to be updated (issue 15) (Ian)

Signed-off-by: Dave Airlie airl...@redhat.com
---
  src/mesa/main/uniform_query.cpp   |  52 +--
  src/mesa/main/uniforms.c  | 185 ++
  src/mesa/main/uniforms.h  |   3 +-
  src/mesa/program/ir_to_mesa.cpp   |  17 +++-
  src/mesa/program/prog_parameter.c |  16 ++--
  5 files changed, 238 insertions(+), 35 deletions(-)

diff --git a/src/mesa/main/uniform_query.cpp b/src/mesa/main/uniform_query.cpp
index 4cd2bca..aa392d7 100644
--- a/src/mesa/main/uniform_query.cpp
+++ b/src/mesa/main/uniform_query.cpp
@@ -449,6 +449,9 @@ log_uniform(const void *values, enum glsl_base_type 
basicType,
case GLSL_TYPE_FLOAT:
 printf(%g , v[i].f);
 break;
+  case GLSL_TYPE_DOUBLE:
+printf(%g , *(double* )v[i * 2].f);
+break;
default:
 assert(!Should not get here.);
 break;
@@ -509,11 +512,11 @@ _mesa_propagate_uniforms_to_driver_storage(struct 
gl_uniform_storage *uni,
  */
 const unsigned components = MAX2(1, uni-type-vector_elements);
 const unsigned vectors = MAX2(1, uni-type-matrix_columns);
-
+   const int dmul = uni-type-base_type == GLSL_TYPE_DOUBLE ? 2 : 1;
 /* Store the data in the driver's requested type in the driver's storage
  * areas.
  */
-   unsigned src_vector_byte_stride = components * 4;
+   unsigned src_vector_byte_stride = components * 4 * dmul;


If the 4 there really denotes sizeof(float) maybe dmul should be set 
to sizeof(float) or sizeof(double) and get rid of the 4.





 for (i = 0; i  uni-num_driver_storage; i++) {
struct gl_uniform_driver_storage *const store = uni-driver_storage[i];
@@ -612,6 +615,7 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 unsigned components;
 unsigned src_components;
 enum glsl_base_type basicType;
+   int size_mul = 1;

 struct gl_uniform_storage *const uni =
validate_uniform_parameters(ctx, shProg, location, count,
@@ -670,6 +674,26 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
basicType = GLSL_TYPE_INT;
src_components = 4;
break;
+   case GL_DOUBLE:
+  basicType = GLSL_TYPE_DOUBLE;
+  src_components = 1;
+  size_mul = 2;
+  break;
+   case GL_DOUBLE_VEC2:
+  basicType = GLSL_TYPE_DOUBLE;
+  src_components = 2;
+  size_mul = 2;
+  break;
+   case GL_DOUBLE_VEC3:
+  basicType = GLSL_TYPE_DOUBLE;
+  src_components = 3;
+  size_mul = 2;
+  break;
+   case GL_DOUBLE_VEC4:
+  basicType = GLSL_TYPE_DOUBLE;
+  src_components = 4;
+  size_mul = 2;
+  break;
 case GL_BOOL:
 case GL_BOOL_VEC2:
 case GL_BOOL_VEC3:
@@ -683,6 +707,15 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 case GL_FLOAT_MAT4x2:
 case GL_FLOAT_MAT4x3:
 case GL_FLOAT_MAT4:
+   case GL_DOUBLE_MAT2:
+   case GL_DOUBLE_MAT2x3:
+   case GL_DOUBLE_MAT2x4:
+   case GL_DOUBLE_MAT3x2:
+   case GL_DOUBLE_MAT3:
+   case GL_DOUBLE_MAT3x4:
+   case GL_DOUBLE_MAT4x2:
+   case GL_DOUBLE_MAT4x3:
+   case GL_DOUBLE_MAT4:
 default:
_mesa_problem(NULL, Invalid type in %s, __func__);
return;
@@ -697,7 +730,7 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
 bool match;
 switch (uni-type-base_type) {
 case GLSL_TYPE_BOOL:
-  match = true;
+  match = (basicType != GLSL_TYPE_DOUBLE);
break;
 case GLSL_TYPE_SAMPLER:
 case GLSL_TYPE_IMAGE:
@@ -789,7 +822,7 @@ _mesa_uniform(struct gl_context *ctx, struct 
gl_shader_program *shProg,
  */
 if (!uni-type-is_boolean()) {
memcpy(uni-storage[components * offset], values,
-sizeof(uni-storage[0]) * components * count);
+sizeof(uni-storage[0]) * components * count * size_mul);
 } else {
const union gl_constant_value *src =
 (const union gl_constant_value *) values;
@@ -892,13 +925,14 @@ extern C void
  _mesa_uniform_matrix(struct gl_context *ctx, struct gl_shader_program *shProg,
 GLuint cols, GLuint rows,
   GLint location, GLsizei count,
- GLboolean transpose, const GLfloat *values)
+ GLboolean transpose,
+ const GLvoid *values, GLenum type)
  {
 unsigned offset;
 unsigned vectors;
 unsigned components;
 unsigned elements;
-
+   int size_mul = mesa_type_is_double(type) ? 2 : 1;
 struct gl_uniform_storage *const uni =
validate_uniform_parameters(ctx, shProg, location, count,
offset, glUniformMatrix, false);
@@ -936,7 +970,7 @@ 

Re: [Mesa-dev] [PATCH 03/20] mesa: add mesa_type_is_double helper function (v2)

2014-09-04 Thread Brian Paul

On 09/03/2014 10:15 PM, Dave Airlie wrote:

This is a helper to return if a type is based on a double.

v2: GLboolean-bool (Ian)

Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
  src/mesa/program/prog_parameter.h | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/src/mesa/program/prog_parameter.h 
b/src/mesa/program/prog_parameter.h
index 6b3b3c2..bcbe142 100644
--- a/src/mesa/program/prog_parameter.h
+++ b/src/mesa/program/prog_parameter.h
@@ -151,6 +151,28 @@ _mesa_lookup_parameter_constant(const struct 
gl_program_parameter_list *list,
  const gl_constant_value v[], GLuint vSize,
  GLint *posOut, GLuint *swizzleOut);

+static INLINE bool mesa_type_is_double(int dataType)


static INLINE bool
mesa_type_is_double(GLenum dataType)



+{
+   switch (dataType) {
+   case GL_DOUBLE:
+   case GL_DOUBLE_VEC2:
+   case GL_DOUBLE_VEC3:
+   case GL_DOUBLE_VEC4:
+   case GL_DOUBLE_MAT2:
+   case GL_DOUBLE_MAT2x3:
+   case GL_DOUBLE_MAT2x4:
+   case GL_DOUBLE_MAT3:
+   case GL_DOUBLE_MAT3x2:
+   case GL_DOUBLE_MAT3x4:
+   case GL_DOUBLE_MAT4:
+   case GL_DOUBLE_MAT4x2:
+   case GL_DOUBLE_MAT4x3:
+  return GL_TRUE;
+   default:
+  return GL_FALSE;
+   }
+}
+
  #ifdef __cplusplus
  }
  #endif



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


Re: [Mesa-dev] Please clean your old patches out of Patchwork

2014-09-04 Thread Marek Olšák
I'd like to be an administrator, so that I can clear out other
people's patches that I committed with changes or rejected.

Marek

On Thu, Sep 4, 2014 at 12:21 AM, Matt Turner matts...@gmail.com wrote:
 We're up to 16 pages of patches. Please take a look at your patches
 and clear out the old ones.

 http://patchwork.freedesktop.org/project/mesa/list/

 If you're not an administrator, I believe you can still manage your
 own patches. If you'd like to be an administrator, reply and someone
 will add you.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 03/20] mesa: add mesa_type_is_double helper function (v2)

2014-09-04 Thread Brian Paul

On 09/04/2014 09:12 AM, Brian Paul wrote:

On 09/03/2014 10:15 PM, Dave Airlie wrote:

This is a helper to return if a type is based on a double.

v2: GLboolean-bool (Ian)

Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
  src/mesa/program/prog_parameter.h | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/src/mesa/program/prog_parameter.h
b/src/mesa/program/prog_parameter.h
index 6b3b3c2..bcbe142 100644
--- a/src/mesa/program/prog_parameter.h
+++ b/src/mesa/program/prog_parameter.h
@@ -151,6 +151,28 @@ _mesa_lookup_parameter_constant(const struct
gl_program_parameter_list *list,
  const gl_constant_value v[], GLuint
vSize,
  GLint *posOut, GLuint *swizzleOut);

+static INLINE bool mesa_type_is_double(int dataType)


static INLINE bool
mesa_type_is_double(GLenum dataType)


Oh, we're trying to use 'inline' instead of 'INLINE' now in core Mesa too.





+{
+   switch (dataType) {
+   case GL_DOUBLE:
+   case GL_DOUBLE_VEC2:
+   case GL_DOUBLE_VEC3:
+   case GL_DOUBLE_VEC4:
+   case GL_DOUBLE_MAT2:
+   case GL_DOUBLE_MAT2x3:
+   case GL_DOUBLE_MAT2x4:
+   case GL_DOUBLE_MAT3:
+   case GL_DOUBLE_MAT3x2:
+   case GL_DOUBLE_MAT3x4:
+   case GL_DOUBLE_MAT4:
+   case GL_DOUBLE_MAT4x2:
+   case GL_DOUBLE_MAT4x3:
+  return GL_TRUE;
+   default:
+  return GL_FALSE;
+   }
+}
+
  #ifdef __cplusplus
  }
  #endif






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


[Mesa-dev] [Bug 83485] Requesting a New Account

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=83485

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes
   |org |ktop.org
Product|Mesa|freedesktop.org
  Component|Other   |New Accounts

--- Comment #2 from Brian Paul bri...@vmware.com ---
Reassigning to fd.o admins...

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


Re: [Mesa-dev] [PATCH 1/2] mesa: set UniformBooleanTrue = 1.0f by default

2014-09-04 Thread Brian Paul

On 09/04/2014 08:21 AM, Marek Olšák wrote:

From: Marek Olšák marek.ol...@amd.com

because NativeIntegers is 0 by default.

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

Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---

Untested. This should fix swrast. See the bugzilla link above.
The second patch fixes the same issue for Gallium/r300g.

  src/mesa/main/context.c | 3 +++
  src/mesa/main/macros.h  | 7 +++
  2 files changed, 10 insertions(+)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index fbdbd68..8b5693e 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -653,6 +653,9 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
api)
 /* GL_ARB_framebuffer_object */
 consts-MaxSamples = 0;

+   /* GLSL default if NativeIntegers == FALSE */
+   consts-UniformBooleanTrue = FLT_AS_UINT(1.0f);
+
 /* GL_ARB_sync */
 consts-MaxServerWaitTimeout = 0x1fff7fffULL;

diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index 0ba658a..2d54ca5 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -184,6 +184,13 @@ static inline GLfloat UINT_AS_FLT(GLuint u)
 return tmp.f;
  }

+static inline unsigned FLT_AS_UINT(float f)
+{
+   fi_type tmp;
+   tmp.f = f;
+   return tmp.u;
+}
+
  /**
   * Convert a floating point value to an unsigned fixed point value.
   *



For both: Reviewed-by: Brian Paul bri...@vmware.com

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


Re: [Mesa-dev] [PATCH] state_tracker: Fix bug in conditional discards with native ints.

2014-09-04 Thread Brian Paul

On 09/03/2014 03:04 PM, Eric Anholt wrote:

A bool is 0 or ~0, and KILL_IF takes a float arg that's 0 for discard or

= 0 for not.  By negating it, we ended up doing a floating point subtract

of (0 - ~0), which ended up as an inf.  To make this actually work, we
need to convert the bool to a float.
---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index dd9c84f..62e4101 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -3091,8 +3091,18 @@ glsl_to_tgsi_visitor::visit(ir_discard *ir)
  {
 if (ir-condition) {
ir-condition-accept(this);
-  this-result.negate = ~this-result.negate;
-  emit(ir, TGSI_OPCODE_KILL_IF, undef_dst, this-result);
+  st_src_reg condition = this-result;
+
+  /* Convert the bool condition to a float so we can negate. */
+  if (native_integers) {
+ st_src_reg temp = get_temp(ir-condition-type);
+ emit(ir, TGSI_OPCODE_AND, st_dst_reg(temp),
+  condition, st_src_reg_for_float(1.0));
+ condition = temp;
+  }
+
+  condition.negate = ~condition.negate;
+  emit(ir, TGSI_OPCODE_KILL_IF, undef_dst, condition);
 } else {
/* unconditional kil */
emit(ir, TGSI_OPCODE_KILL);



Reviewed-by: Brian Paul bri...@vmware.com

Tag for stable branches?

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


[Mesa-dev] [PATCH 1/5] mesa: s/INLINE/inline/

2014-09-04 Thread Brian Paul
---
 src/mesa/main/api_arrayelt.c |4 ++--
 src/mesa/main/compiler.h |2 +-
 src/mesa/main/macros.h   |4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index ebeba88..536326f 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -75,7 +75,7 @@ typedef struct {
 
 
 /** Cast wrapper */
-static INLINE AEcontext *
+static inline AEcontext *
 AE_CONTEXT(struct gl_context *ctx)
 {
return (AEcontext *) ctx-aelt_context;
@@ -87,7 +87,7 @@ AE_CONTEXT(struct gl_context *ctx)
  * in the range [0, 7].  Luckily these type tokens are sequentially
  * numbered in gl.h, except for GL_DOUBLE.
  */
-static INLINE int
+static inline int
 TYPE_IDX(GLenum t)
 {
return t == GL_DOUBLE ? 7 : t  7;
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 3516022..813bf19 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -151,7 +151,7 @@ extern C {
 #include CoreFoundation/CFByteOrder.h
 #define CPU_TO_LE32( x )   CFSwapInt32HostToLittle( x )
 #elif (defined(_AIX) || defined(__blrts))
-static INLINE GLuint CPU_TO_LE32(GLuint x)
+static inline GLuint CPU_TO_LE32(GLuint x)
 {
return (((x  0x00ff)  24) |
((x  0xff00)   8) |
diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index 0ba658a..422eb5a 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -189,7 +189,7 @@ static inline GLfloat UINT_AS_FLT(GLuint u)
  *
  * \param frac_bits   The number of bits used to store the fractional part.
  */
-static INLINE uint32_t
+static inline uint32_t
 U_FIXED(float value, uint32_t frac_bits)
 {
value *= (1  frac_bits);
@@ -201,7 +201,7 @@ U_FIXED(float value, uint32_t frac_bits)
  *
  * \param frac_bits   The number of bits used to store the fractional part.
  */
-static INLINE int32_t
+static inline int32_t
 S_FIXED(float value, uint32_t frac_bits)
 {
return (int32_t) (value * (1  frac_bits));
-- 
1.7.10.4

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


[Mesa-dev] [PATCH 2/5] meta: s/INLINE/inline/

2014-09-04 Thread Brian Paul
---
 src/mesa/drivers/common/meta.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 85f934d..7a8e627 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1220,7 +1220,7 @@ _mesa_meta_in_progress(struct gl_context *ctx)
  * Used by the meta-Clear, Draw/CopyPixels and Bitmap functions where the Z
  * value comes from the clear value or raster position.
  */
-static INLINE GLfloat
+static inline GLfloat
 invert_z(GLfloat normZ)
 {
GLfloat objZ = 1.0f - 2.0f * normZ;
-- 
1.7.10.4

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


[Mesa-dev] [PATCH 3/5] xlib: s/INLINE/inline/

2014-09-04 Thread Brian Paul
---
 src/mesa/drivers/x11/xmesaP.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/x11/xmesaP.h b/src/mesa/drivers/x11/xmesaP.h
index b47934d..d7a934e 100644
--- a/src/mesa/drivers/x11/xmesaP.h
+++ b/src/mesa/drivers/x11/xmesaP.h
@@ -375,7 +375,7 @@ xmesa_destroy_buffers_on_display(XMesaDisplay *dpy);
 /**
  * Using a function instead of an ordinary cast is safer.
  */
-static INLINE struct xmesa_renderbuffer *
+static inline struct xmesa_renderbuffer *
 xmesa_renderbuffer(struct gl_renderbuffer *rb)
 {
return (struct xmesa_renderbuffer *) rb;
@@ -386,7 +386,7 @@ xmesa_renderbuffer(struct gl_renderbuffer *rb)
  * Return pointer to XMesaContext corresponding to a Mesa struct gl_context.
  * Since we're using structure containment, it's just a cast!.
  */
-static INLINE XMesaContext
+static inline XMesaContext
 XMESA_CONTEXT(struct gl_context *ctx)
 {
return (XMesaContext) ctx;
@@ -397,7 +397,7 @@ XMESA_CONTEXT(struct gl_context *ctx)
  * Return pointer to XMesaBuffer corresponding to a Mesa struct gl_framebuffer.
  * Since we're using structure containment, it's just a cast!.
  */
-static INLINE XMesaBuffer
+static inline XMesaBuffer
 XMESA_BUFFER(struct gl_framebuffer *b)
 {
return (XMesaBuffer) b;
-- 
1.7.10.4

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


[Mesa-dev] [PATCH 4/5] osmesa: s/INLINE/inline/

2014-09-04 Thread Brian Paul
---
 src/mesa/drivers/osmesa/osmesa.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/osmesa/osmesa.c b/src/mesa/drivers/osmesa/osmesa.c
index ab9ac31..74cbb5a 100644
--- a/src/mesa/drivers/osmesa/osmesa.c
+++ b/src/mesa/drivers/osmesa/osmesa.c
@@ -83,7 +83,7 @@ struct osmesa_context
 };
 
 
-static INLINE OSMesaContext
+static inline OSMesaContext
 OSMESA_CONTEXT(struct gl_context *ctx)
 {
/* Just cast, since we're using structure containment */
-- 
1.7.10.4

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


[Mesa-dev] [PATCH 5/5] swrast: s/INLINE/inline/

2014-09-04 Thread Brian Paul
---
 src/mesa/swrast/s_texfilter.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/swrast/s_texfilter.c b/src/mesa/swrast/s_texfilter.c
index c3fd900..65cf52e 100644
--- a/src/mesa/swrast/s_texfilter.c
+++ b/src/mesa/swrast/s_texfilter.c
@@ -804,7 +804,7 @@ get_border_color(const struct gl_sampler_object *samp,
 /**
  * Put z into texel according to GL_DEPTH_MODE.
  */
-static INLINE void
+static inline void
 apply_depth_mode(GLenum depthMode, GLfloat z, GLfloat texel[4])
 {
switch (depthMode) {
-- 
1.7.10.4

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


Re: [Mesa-dev] [PATCH 1/2] mesa: set UniformBooleanTrue = 1.0f by default

2014-09-04 Thread Matt Turner
Thanks Marek,

Both are

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


Re: [Mesa-dev] [PATCH] i965: Mark cfg dumping functions const.

2014-09-04 Thread Matt Turner
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965/fs: Pass block to insert and remove functions missed earlier.

2014-09-04 Thread Matt Turner
I guess I can put a Reviewed-by on my own patch? :)

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


Re: [Mesa-dev] [PATCH 1/3] i965: Handle ir_triop_csel in emit_if_gen6().

2014-09-04 Thread Matt Turner
Okay, this time I definitely know I already reviewed this patch :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/1] clover: Remove compat::string::c_str

2014-09-04 Thread Jan Vesely
It's unsafe as compat::string is not null terminated.
Fixes garbage log on successful build.

Signed-off-by: Jan Vesely jan.ves...@rutgers.edu
---

It's obviously not needed in program::build, but I'm not sure
if runtime_error solution is the best one.


 src/gallium/state_trackers/clover/core/program.cpp | 4 ++--
 src/gallium/state_trackers/clover/util/compat.cpp  | 2 +-
 src/gallium/state_trackers/clover/util/compat.hpp  | 5 -
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/clover/core/program.cpp 
b/src/gallium/state_trackers/clover/core/program.cpp
index 30a1f0e..3e9abec 100644
--- a/src/gallium/state_trackers/clover/core/program.cpp
+++ b/src/gallium/state_trackers/clover/core/program.cpp
@@ -61,9 +61,9 @@ program::build(const ref_vectordevice devs, const char 
*opts) {
 dev.ir_target(), 
build_opts(dev),
 log));
 _binaries.insert({ dev, module });
-_logs.insert({ dev, std::string(log.c_str()) });
+_logs.insert({ dev, std::string(log) });
  } catch (const build_error ) {
-_logs.insert({ dev, std::string(log.c_str()) });
+_logs.insert({ dev, std::string(log) });
 throw;
  }
   }
diff --git a/src/gallium/state_trackers/clover/util/compat.cpp 
b/src/gallium/state_trackers/clover/util/compat.cpp
index 80d5b3e..afba92e 100644
--- a/src/gallium/state_trackers/clover/util/compat.cpp
+++ b/src/gallium/state_trackers/clover/util/compat.cpp
@@ -34,5 +34,5 @@ exception::what() const {
 
 const char *
 runtime_error::what() const {
-   return _what.c_str();
+   return ((std::string)_what).c_str();
 }
diff --git a/src/gallium/state_trackers/clover/util/compat.hpp 
b/src/gallium/state_trackers/clover/util/compat.hpp
index 50e1c7d..b3668c5 100644
--- a/src/gallium/state_trackers/clover/util/compat.hpp
+++ b/src/gallium/state_trackers/clover/util/compat.hpp
@@ -280,11 +280,6 @@ namespace clover {
  }
 
  const char *
- c_str() const {
-return begin();
- }
-
- const char *
  find(const string s) const {
 for (size_t i = 0; i + s.size()  size(); ++i) {
if (!std::memcmp(begin() + i, s.begin(), s.size()))
-- 
1.9.3

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


Re: [Mesa-dev] [PATCH 2/3] i965/fs: Make emit_if_gen6 never fall back to emit_bool_to_cond_code.

2014-09-04 Thread Matt Turner
On Thu, Sep 4, 2014 at 12:18 AM, Kenneth Graunke kenn...@whitecape.org wrote:
 Matt and I believe that Sandybridge actually uses 0x for a
 true comparison result, similar to Ivybridge.  This matches the
 internal documentation, and empirical results, but contradicts the PRM.

 So, the comment is inaccurate, and we can actually just handle these
 directly without ever needing to fall through to the condition code
 path.

 Also, the vec4 backend has always done it this way, and has apparently
 been working fine.  This patch makes the FS backend match the vec4
 backend's behavior.

 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 25 +
  1 file changed, 17 insertions(+), 8 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
 b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
 index 8f2e1df..d7e3120 100644
 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
 @@ -2378,14 +2378,24 @@ fs_visitor::emit_if_gen6(ir_if *ir)

switch (expr-operation) {
case ir_unop_logic_not:
 + emit(IF(op[0], fs_reg(0), BRW_CONDITIONAL_Z));
 + return;
 +
case ir_binop_logic_xor:
 + emit(IF(op[0], op[1], BRW_CONDITIONAL_NZ));
 + return;
 +
case ir_binop_logic_or:
 + temp = fs_reg(this, glsl_type::bool_type);
 + emit(OR(temp, op[0], op[1]));
 + emit(IF(temp, fs_reg(0), BRW_CONDITIONAL_NZ));
 + return;
 +
case ir_binop_logic_and:
 - /* For operations on bool arguments, only the low bit of the bool is
 -  * valid, and the others are undefined.  Fall back to the condition
 -  * code path.
 -  */
 - break;
 + temp = fs_reg(this, glsl_type::bool_type);
 + emit(AND(temp, op[0], op[1]));

For this and the OR case, we might as well generate the flag and use a
predicated IF if we have to use two instructions. That would let the
SEL peephole not emit an extra CMP.

One of us can do this in a follow up. This patch is fine since it
makes the code like the vec4 code.

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


Re: [Mesa-dev] [PATCH 3/3] i965: Handle ir_binop_ubo_load in boolean expression code.

2014-09-04 Thread Matt Turner
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] state_tracker: Fix bug in conditional discards with native ints.

2014-09-04 Thread Eric Anholt
Brian Paul bri...@vmware.com writes:

 On 09/03/2014 03:04 PM, Eric Anholt wrote:
 A bool is 0 or ~0, and KILL_IF takes a float arg that's 0 for discard or
 = 0 for not.  By negating it, we ended up doing a floating point subtract
 of (0 - ~0), which ended up as an inf.  To make this actually work, we
 need to convert the bool to a float.
 ---
   src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 14 --
   1 file changed, 12 insertions(+), 2 deletions(-)

 diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
 b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 index dd9c84f..62e4101 100644
 --- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 +++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
 @@ -3091,8 +3091,18 @@ glsl_to_tgsi_visitor::visit(ir_discard *ir)
   {
  if (ir-condition) {
 ir-condition-accept(this);
 -  this-result.negate = ~this-result.negate;
 -  emit(ir, TGSI_OPCODE_KILL_IF, undef_dst, this-result);
 +  st_src_reg condition = this-result;
 +
 +  /* Convert the bool condition to a float so we can negate. */
 +  if (native_integers) {
 + st_src_reg temp = get_temp(ir-condition-type);
 + emit(ir, TGSI_OPCODE_AND, st_dst_reg(temp),
 +  condition, st_src_reg_for_float(1.0));
 + condition = temp;
 +  }
 +
 +  condition.negate = ~condition.negate;
 +  emit(ir, TGSI_OPCODE_KILL_IF, undef_dst, condition);
  } else {
 /* unconditional kil */
 emit(ir, TGSI_OPCODE_KILL);


 Reviewed-by: Brian Paul bri...@vmware.com

 Tag for stable branches?

I don't think there are any releaseable drivers doing native ints
without control flow in the stable braches -- GLSL discards just don't
work at all if you're hitting this bug.


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


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3 v2] mesa: Handle uninitialized textures like other textures in get_tex_level_parameter_image

2014-09-04 Thread Carl Worth
Carl Worth cwo...@cworth.org writes:
 Emil Velikov emil.l.veli...@gmail.com writes:

 I will not have the chance to run piglit on a i965 system until next
 week so I would love if someone can take a look at this.

 I should be able to take a look at this today or tomorrow.

I didn't see any failures on i965. Oddly, piglit doesn't seem to be
running this test for me, (maybe I'm missing all glean testing from
piglit?!---I'll debug that later.). For now, I'm running this test
manually with:

./bin/glean -o -v -v -v -t +fragProg1

 As a former stable-release manager would you have any suggestions -
 should I pull it out from the upcoming 10.2.7 ? I would not be too
 fussed it only swrast regresses, yet I'm suspecting that other classic
 drivers could be affected.

 Right. If piglit shows a regression, (on anything), I would recommend
 not including the patch.

I still stand by that policy.

But, while I did find a failure of this test on swrast, I wasn't able to
identify this patch as a regression. I see this same testing failing
similarly on both mesa-10.2.6 and 10.2-branchpoint.

Let me know if I can be of any further assistance.

-Carl

-- 
carl.d.wo...@intel.com


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


Re: [Mesa-dev] [PATCH 1/2] Eliminate several cases of multiplication in arguments to calloc

2014-09-04 Thread Carl Worth
Matt Turner matts...@gmail.com writes:
 -   configs = calloc(1, (num_modes + 1) * sizeof *configs);
 +   configs = calloc((num_modes + 1), sizeof *configs);

 I'd drop the extra parentheses.

Thanks for reading carefully, Matt!

 With that, both are

 Reviewed-by: Matt Turner matts...@gmail.com

OK. These are both pushed now.

-Carl

-- 
carl.d.wo...@intel.com


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


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

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=79706

Vinson Lee v...@freedesktop.org changed:

   What|Removed |Added

 Depends on||77288

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


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

2014-09-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=77288

Vinson Lee v...@freedesktop.org changed:

   What|Removed |Added

 Blocks||79706

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


Re: [Mesa-dev] [PATCH 1/5] mesa: s/INLINE/inline/

2014-09-04 Thread Kenneth Graunke
On Thursday, September 04, 2014 09:38:19 AM Brian Paul wrote:
 ---
  src/mesa/main/api_arrayelt.c |4 ++--
  src/mesa/main/compiler.h |2 +-
  src/mesa/main/macros.h   |4 ++--
  3 files changed, 5 insertions(+), 5 deletions(-)

Series is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org

Always nice to see INLINE go away :)  Thanks Brian!

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


Re: [Mesa-dev] Please clean your old patches out of Patchwork

2014-09-04 Thread Kenneth Graunke
On Thursday, September 04, 2014 05:16:02 PM Marek Olšák wrote:
 I'd like to be an administrator, so that I can clear out other
 people's patches that I committed with changes or rejected.
 
 Marek

Great :) I've added you.

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3 v2] mesa: Handle uninitialized textures like other textures in get_tex_level_parameter_image

2014-09-04 Thread Emil Velikov
On 04/09/14 02:50, Carl Worth wrote:
 Carl Worth cwo...@cworth.org writes:
 Emil Velikov emil.l.veli...@gmail.com writes:

 I will not have the chance to run piglit on a i965 system until next
 week so I would love if someone can take a look at this.

 I should be able to take a look at this today or tomorrow.
 
 I didn't see any failures on i965. Oddly, piglit doesn't seem to be
 running this test for me, (maybe I'm missing all glean testing from
 piglit?!---I'll debug that later.). For now, I'm running this test
 manually with:
 
   ./bin/glean -o -v -v -v -t +fragProg1
 
There is a recent bug in piglit (+ it's fix [1]) that causes the env vars used
not to be printed in the HTML test summary.

Additionally the command alone does not run the tests in question :'(

Give the patches a try and/or manually set the env vars similar to the ones
I've used [2].

 As a former stable-release manager would you have any suggestions -
 should I pull it out from the upcoming 10.2.7 ? I would not be too
 fussed it only swrast regresses, yet I'm suspecting that other classic
 drivers could be affected.

 Right. If piglit shows a regression, (on anything), I would recommend
 not including the patch.
 
 I still stand by that policy.
 
 But, while I did find a failure of this test on swrast, I wasn't able to
 identify this patch as a regression. I see this same testing failing
 similarly on both mesa-10.2.6 and 10.2-branchpoint.
 
I am a bit more lenient on the classic swrast, considering the fact that the
gallium one is used most of the time. I'm starting to lean towards your
suggestion though. If there is another driver affected - the patch will be
flying out :)

Thanks
Emil

[1] Two bugs actually - lack of env var + missing # in the escape chars,
causing an invalid link in the HTML summary :)

http://lists.freedesktop.org/archives/piglit/2014-September/012435.html
http://lists.freedesktop.org/archives/piglit/2014-September/012429.html


[2]
[glean/fragProg1-CMP]

PIGLIT_SOURCE_DIR=/home/emil/development/piglit/install-3457f015314/usr/local/lib/piglit
MESA_DEBUG=silent PIGLIT_PLATFORM=mixed_glx_egl PIGLIT_TEST=CMP test


[glean/glsl1-Preprocessor test 11 (#elif)]

PIGLIT_SOURCE_DIR=/home/emil/development/piglit/install-3457f015314/usr/local/lib/piglit
MESA_DEBUG=silent PIGLIT_PLATFORM=mixed_glx_egl PIGLIT_TEST=Preprocessor
test 11 (#elif)


 Let me know if I can be of any further assistance.
 
 -Carl
 
 
 
 ___
 mesa-stable mailing list
 mesa-sta...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-stable
 

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


Re: [Mesa-dev] [PATCH 20/20] i965: Add and use functions to get next/prev blocks.

2014-09-04 Thread Matt Turner
On Tue, Sep 2, 2014 at 9:34 PM, Matt Turner matts...@gmail.com wrote:
 diff --git a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp 
 b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
 index 557c3ad..8a7f42a 100644
 --- a/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_dead_control_flow.cpp
 @@ -52,20 +52,20 @@ dead_control_flow_eliminate(backend_visitor *v)
   continue;

backend_instruction *if_inst = NULL, *else_inst = NULL;
 -  backend_instruction *prev_inst = ((bblock_t 
 *)endif_block-link.prev)-end();
 +  backend_instruction *prev_inst = endif_block-next()-end();

This is obviously supposed to be -prev(), not -next(). Fixed locally.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3 v2] mesa: Handle uninitialized textures like other textures in get_tex_level_parameter_image

2014-09-04 Thread Kenneth Graunke
On Wednesday, September 03, 2014 06:50:39 PM Carl Worth wrote:
 Carl Worth cwo...@cworth.org writes:
  Emil Velikov emil.l.veli...@gmail.com writes:
 
  I will not have the chance to run piglit on a i965 system until next
  week so I would love if someone can take a look at this.
 
  I should be able to take a look at this today or tomorrow.
 
 I didn't see any failures on i965. Oddly, piglit doesn't seem to be
 running this test for me, (maybe I'm missing all glean testing from
 piglit?!---I'll debug that later.).

Glean is excluded by the '-p gbm' option because Glean uses GLUT, not Waffle, 
and therefore only runs on GLX.  (It has no EGL/X11, Wayland, or GBM support.)

Our plan has been to replace Glean with native Piglit tests.  We've been making 
some progress toward that, but there's a pile more work to do.

 For now, I'm running this test
 manually with:
 
   ./bin/glean -o -v -v -v -t +fragProg1
 
  As a former stable-release manager would you have any suggestions -
  should I pull it out from the upcoming 10.2.7 ? I would not be too
  fussed it only swrast regresses, yet I'm suspecting that other classic
  drivers could be affected.
 
  Right. If piglit shows a regression, (on anything), I would recommend
  not including the patch.
 
 I still stand by that policy.
 
 But, while I did find a failure of this test on swrast, I wasn't able to
 identify this patch as a regression. I see this same testing failing
 similarly on both mesa-10.2.6 and 10.2-branchpoint.
 
 Let me know if I can be of any further assistance.
 
 -Carl

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


[Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading

2014-09-04 Thread Glenn Kennard
Also fixes two sided lighting which was broken at least
on pre-evergreen by commit b1eb00.

Signed-off-by: Glenn Kennard glenn.kenn...@gmail.com
---
Changes since patch v1:
Factor out and set sample positions also for pre-evergreen
Misc r600 breakage fixes
Some cleanup

Passes piglit without regressions on radeon 6670.

Cayman and pre-evergreen still needs testing before committing.

 docs/GL3.txt |   2 +-
 docs/relnotes/10.4.html  |  62 ++
 src/gallium/drivers/r600/evergreen_state.c   |  85 +---
 src/gallium/drivers/r600/evergreend.h|   3 +
 src/gallium/drivers/r600/r600_pipe.c |   2 +-
 src/gallium/drivers/r600/r600_pipe.h |  10 +
 src/gallium/drivers/r600/r600_shader.c   | 292 ---
 src/gallium/drivers/r600/r600_shader.h   |   6 +-
 src/gallium/drivers/r600/r600_state.c|  49 -
 src/gallium/drivers/r600/r600_state_common.c |  20 ++
 src/gallium/drivers/r600/r600d.h |   3 +
 src/gallium/drivers/r600/sb/sb_bc_parser.cpp |  21 +-
 12 files changed, 435 insertions(+), 120 deletions(-)
 create mode 100644 docs/relnotes/10.4.html

diff --git a/docs/GL3.txt b/docs/GL3.txt
index f5d5e72..6a54873 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -110,7 +110,7 @@ GL 4.0, GLSL 4.00:
   - Interpolation functionsDONE ()
   - New overload resolution rules  DONE
   GL_ARB_gpu_shader_fp64   started (Dave)
-  GL_ARB_sample_shadingDONE (i965, nv50, nvc0, 
radeonsi)
+  GL_ARB_sample_shadingDONE (i965, nv50, nvc0, 
r600, radeonsi)
   GL_ARB_shader_subroutine not started
   GL_ARB_tessellation_shader   started (Chris, Ilia)
   GL_ARB_texture_buffer_object_rgb32   DONE (i965, nvc0, r600, 
radeonsi, llvmpipe, softpipe)
diff --git a/docs/relnotes/10.4.html b/docs/relnotes/10.4.html
new file mode 100644
index 000..d56275d
--- /dev/null
+++ b/docs/relnotes/10.4.html
@@ -0,0 +1,62 @@
+!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN 
http://www.w3.org/TR/html4/loose.dtd;
+html lang=en
+head
+  meta http-equiv=content-type content=text/html; charset=utf-8
+  titleMesa Release Notes/title
+  link rel=stylesheet type=text/css href=../mesa.css
+/head
+body
+
+div class=header
+  h1The Mesa 3D Graphics Library/h1
+/div
+
+iframe src=../contents.html/iframe
+div class=content
+
+h1Mesa 10.4 Release Notes / TBD/h1
+
+p
+Mesa 10.4 is a new development release.
+People who are concerned with stability and reliability should stick
+with a previous release or wait for Mesa 10.4.1.
+/p
+p
+Mesa 10.4 implements the OpenGL 3.3 API, but the version reported by
+glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
+glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
+Some drivers don't support all the features required in OpenGL 3.3.  OpenGL
+3.3 is strongonly/strong available if requested at context creation
+because compatibility contexts are not supported.
+/p
+
+
+h2MD5 checksums/h2
+pre
+TBD.
+/pre
+
+
+h2New features/h2
+
+p
+Note: some of the new features are only available with certain drivers.
+/p
+
+ul
+liGL_ARB_sample_shading on r600/li
+/ul
+
+
+h2Bug fixes/h2
+
+TBD.
+
+h2Changes/h2
+
+ul
+/ul
+
+/div
+/body
+/html
diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index e7faeaf..e0adb1e 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -1400,7 +1400,7 @@ static void evergreen_set_framebuffer_state(struct 
pipe_context *ctx,
 
/* MSAA. */
if (rctx-b.chip_class == EVERGREEN)
-   rctx-framebuffer.atom.num_dw += 14; /* Evergreen */
+   rctx-framebuffer.atom.num_dw += 17; /* Evergreen */
else
rctx-framebuffer.atom.num_dw += 28; /* Cayman */
 
@@ -1420,8 +1420,22 @@ static void evergreen_set_framebuffer_state(struct 
pipe_context *ctx,
}
 
rctx-framebuffer.atom.dirty = true;
+
+   r600_set_sample_locations_constant_buffer(rctx);
 }
 
+static void evergreen_set_min_samples(struct pipe_context *ctx, unsigned 
min_samples)
+{
+   struct r600_context *rctx = (struct r600_context *)ctx;
+
+   if (rctx-ps_iter_samples == min_samples)
+   return;
+
+   rctx-ps_iter_samples = min_samples;
+   if (rctx-framebuffer.nr_samples  1) {
+   rctx-framebuffer.atom.dirty = true;
+   }
+}
 
 /* 8xMSAA */
 static uint32_t sample_locs_8x[] = {
@@ -1475,7 +1489,7 @@ static void evergreen_get_sample_position(struct 
pipe_context *ctx,
}
 }
 
-static void evergreen_emit_msaa_state(struct r600_context *rctx, int 
nr_samples)
+static void evergreen_emit_msaa_state(struct r600_context *rctx, int 
nr_samples, int ps_iter_samples)
 {
 
 

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3 v2] mesa: Handle uninitialized textures like other textures in get_tex_level_parameter_image

2014-09-04 Thread Brian Paul

On 09/04/2014 03:17 PM, Kenneth Graunke wrote:

On Wednesday, September 03, 2014 06:50:39 PM Carl Worth wrote:

Carl Worth cwo...@cworth.org writes:

Emil Velikov emil.l.veli...@gmail.com writes:


I will not have the chance to run piglit on a i965 system until next
week so I would love if someone can take a look at this.


I should be able to take a look at this today or tomorrow.


I didn't see any failures on i965. Oddly, piglit doesn't seem to be
running this test for me, (maybe I'm missing all glean testing from
piglit?!---I'll debug that later.).


Glean is excluded by the '-p gbm' option because Glean uses GLUT, not Waffle, 
and therefore only runs on GLX.  (It has no EGL/X11, Wayland, or GBM support.)

Our plan has been to replace Glean with native Piglit tests.  We've been making 
some progress toward that, but there's a pile more work to do.


It would be great if there were a to-do list on the piglit website to 
maybe inspire people to do some of that work.  And one of the first 
items on the piglit to-do list should be to overhaul the piglit website 
itself.


http://people.freedesktop.org/~nh/piglit/

-Brian

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


Re: [Mesa-dev] [PATCH 1/5] mesa: s/INLINE/inline/

2014-09-04 Thread Brian Paul

On 09/04/2014 11:57 AM, Kenneth Graunke wrote:

On Thursday, September 04, 2014 09:38:19 AM Brian Paul wrote:

---
  src/mesa/main/api_arrayelt.c |4 ++--
  src/mesa/main/compiler.h |2 +-
  src/mesa/main/macros.h   |4 ++--
  3 files changed, 5 insertions(+), 5 deletions(-)


Series is:
Reviewed-by: Kenneth Graunke kenn...@whitecape.org

Always nice to see INLINE go away :)  Thanks Brian!


There's still many occurrences of it in the DRI drivers code.  Maybe 
someone else can change those and test.


-Brian


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


[Mesa-dev] [PATCH 1/2] gallium: Drop software-only primitive restart support.

2014-09-04 Thread Eric Anholt
The drivers not flagging primitive restart support are r300 swtcl, svga,
nv30, and vc4.

The point of primitive restart is to slightly reduce draw call overhead
for apps by batching multiple draws.  If we do an extra pass to read the
index buffer and split back into multiple draws, we've entirely missed the
point.  This is particularly bad for drivers that otherwise have hardware
IB reads, where the readback is probably uncached.
---
 src/mesa/state_tracker/st_extensions.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 9db648c..605c5e6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -714,9 +714,8 @@ void st_init_extensions(struct pipe_screen *screen,
 #endif
}
 
-   extensions-NV_primitive_restart = GL_TRUE;
-   if (!screen-get_param(screen, PIPE_CAP_PRIMITIVE_RESTART)) {
-  consts-PrimitiveRestartInSoftware = GL_TRUE;
+   if (screen-get_param(screen, PIPE_CAP_PRIMITIVE_RESTART)) {
+  extensions-NV_primitive_restart = GL_TRUE;
}
 
/* ARB_color_buffer_float. */
-- 
2.1.0

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


[Mesa-dev] [PATCH 2/2] mesa: Drop the always-software-primitive-restart paths.

2014-09-04 Thread Eric Anholt
The core sw primitive restart code is still around, because i965 uses it
in some cases, but there are no drivers that want it on all the time.
---
 src/mesa/drivers/dri/i965/brw_primitive_restart.c |  8 
 src/mesa/main/context.c   |  3 --
 src/mesa/main/mtypes.h|  5 ---
 src/mesa/vbo/vbo_exec_array.c | 46 +++
 src/mesa/vbo/vbo_primitive_restart.c  |  4 +-
 5 files changed, 8 insertions(+), 58 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_primitive_restart.c 
b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
index 2d654f6..f7764e1 100644
--- a/src/mesa/drivers/dri/i965/brw_primitive_restart.c
+++ b/src/mesa/drivers/dri/i965/brw_primitive_restart.c
@@ -138,14 +138,6 @@ brw_handle_primitive_restart(struct gl_context *ctx,
   return GL_FALSE;
}
 
-   /* If the driver has requested software handling of primitive restarts,
-* then the VBO module has already taken care of things, and we can
-* just draw as normal.
-*/
-   if (ctx-Const.PrimitiveRestartInSoftware) {
-  return GL_FALSE;
-   }
-
/* If we have set the in_progress flag, then we are in the middle
 * of handling the primitive restart draw.
 */
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index fbdbd68..ba8d00d 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -684,9 +684,6 @@ _mesa_init_constants(struct gl_constants *consts, gl_api 
api)
/* GL_ARB_robustness */
consts-ResetStrategy = GL_NO_RESET_NOTIFICATION_ARB;
 
-   /* PrimitiveRestart */
-   consts-PrimitiveRestartInSoftware = GL_FALSE;
-
/* ES 3.0 or ARB_ES3_compatibility */
consts-MaxElementIndex = 0xu;
 
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 4fb30ff..3c8f24f 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3471,11 +3471,6 @@ struct gl_constants
GLboolean GLSLSkipStrictMaxUniformLimitCheck;
 
/**
-* Force software support for primitive restart in the VBO module.
-*/
-   GLboolean PrimitiveRestartInSoftware;
-
-   /**
 * Always use the GetTransformFeedbackVertexCount() driver hook, rather
 * than passing the transform feedback object to the drawing function.
 */
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 22557e1..1ab3e23 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -562,38 +562,6 @@ vbo_bind_arrays(struct gl_context *ctx)
}
 }
 
-
-/**
- * Handle a draw case that potentially has primitive restart enabled.
- *
- * If primitive restart is enabled, and PrimitiveRestartInSoftware is
- * set, then vbo_sw_primitive_restart is used to handle the primitive
- * restart case in software.
- */
-static void
-vbo_handle_primitive_restart(struct gl_context *ctx,
- const struct _mesa_prim *prim,
- GLuint nr_prims,
- const struct _mesa_index_buffer *ib,
- GLboolean index_bounds_valid,
- GLuint min_index,
- GLuint max_index)
-{
-   struct vbo_context *vbo = vbo_context(ctx);
-
-   if (ctx-Const.PrimitiveRestartInSoftware 
-   ctx-Array._PrimitiveRestart 
-   (ib != NULL)) {
-  /* Handle primitive restart in software */
-  vbo_sw_primitive_restart(ctx, prim, nr_prims, ib, NULL);
-   } else {
-  /* Call driver directly for draw_prims */
-  vbo-draw_prims(ctx, prim, nr_prims, ib,
-  index_bounds_valid, min_index, max_index, NULL, NULL);
-   }
-}
-
-
 /**
  * Helper function called by the other DrawArrays() functions below.
  * This is where we handle primitive restart for drawing non-indexed
@@ -1011,8 +979,8 @@ vbo_validated_drawrangeelements(struct gl_context *ctx, 
GLenum mode,
 */
 
check_buffers_are_unmapped(exec-array.inputs);
-   vbo_handle_primitive_restart(ctx, prim, 1, ib,
-index_bounds_valid, start, end);
+   vbo-draw_prims(ctx, prim, 1, ib,
+   index_bounds_valid, start, end, NULL, NULL);
 
if (MESA_DEBUG_FLAGS  DEBUG_ALWAYS_FLUSH) {
   _mesa_flush(ctx);
@@ -1386,8 +1354,8 @@ vbo_validated_multidrawelements(struct gl_context *ctx, 
GLenum mode,
   }
 
   check_buffers_are_unmapped(exec-array.inputs);
-  vbo_handle_primitive_restart(ctx, prim, primcount, ib,
-   GL_FALSE, ~0, ~0);
+  vbo-draw_prims(ctx, prim, primcount, ib,
+  false, ~0, ~0, NULL, NULL);
} else {
   /* render one prim at a time */
   for (i = 0; i  primcount; i++) {
@@ -1415,8 +1383,8 @@ vbo_validated_multidrawelements(struct gl_context *ctx, 
GLenum mode,
prim[0].basevertex = 0;
 
  check_buffers_are_unmapped(exec-array.inputs);
- vbo_handle_primitive_restart(ctx, prim, 1, ib,
- 

[Mesa-dev] X.Org looking for projects and mentors for the Outreach Program for Women

2014-09-04 Thread Peter Hutterer
Hi everyone,

X.Org will join the Outreach Program for Women (OPW) in Round 9 (December
2014 - March 2015). The OPW is open to anyone who was
assigned female at birth and anyone who identifies as a woman, genderqueer,
genderfluid, or genderfree regardless of gender presentation or assigned sex
at birth. 
For more details on the program see 
https://wiki.gnome.org/OutreachProgramForWomen

We've secured funding for one participant and are currently looking for
suitable projects and mentors. The scope of the program is not limited to
coding, but include user experience design, graphic design, documentation,
web development, marketing, translation and other types of tasks needed to
sustain a FOSS project.

So if you are interested in mentoring or you can think of a suitable
project, please add it to the wiki page or alternatively email me.
http://www.x.org/wiki/XorgOPW/

If you are interested in participating and you can think of a suitable
project, please do the same and we'll try our best to find a mentor for you.

The applications will open on September 22, so let's get some good projects
up there by then!

Cheers,
   Peter, on behalf of the X.Org BoD

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


Re: [Mesa-dev] [PATCH 0/8] More format conversion reworking

2014-09-04 Thread Jason Ekstrand
Brian,
Did you want to look over these or should I try and find someone else to
review them?  I'm most concerned with the 565 and 5551 patches since those
touch corners of mesa with which I am very unfamiliar.
--Jason


On Sat, Aug 23, 2014 at 3:27 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:

 One more note:  I tested these on i965, llvmpipe, and swrast on both my
 laptop and my desktop.  No changes on i965.  A couple changes on llvmpipe
 on my desktop which I can't reproduce on my laptop.  I think that's my
 desktop being funny.  There seems to be one little issue still on swrast
 with RGB4 renderbuffers (which get mapped to 565).  Unfortunately, I
 haven't been able to track that down.  It's probably some place where the
 format conversion code is repeated.
 --Jason


 On Sat, Aug 23, 2014 at 3:23 PM, Jason Ekstrand ja...@jlekstrand.net
 wrote:

 I needed a break from the i965 compiler backend, so I wrote some more
 format conversion patches.  A lot of these are bug fixes or stand-alones.
 However, the last three require all the previous ones.

 Jason Ekstrand (8):
   main/format_util: Fix a bug in one of the format helper functions
   main: Fix packing/unpacking of MESA_FORMAT_R5G6B5_UNORM
   main/colormac: Remove an unused macro
   main: Fix A1R5G5B5 packing/unpacking
   mesa/format_utils: Prefix and expose the conversion helper functions
   main: Autogenerate most of format_pack.c
   MAYBEREVERT: Fill X components with 1
   main: Autogenerate format_unpack.c

  src/mesa/Makefile.am   |   18 +
  src/mesa/Makefile.sources  |4 +-
  src/mesa/main/colormac.h   |3 -
  src/mesa/main/format_convert.py|   72 +
  src/mesa/main/format_pack.c|   18 +-
  src/mesa/main/format_pack.c.mako   |  900 
  src/mesa/main/format_unpack.c  | 4329
 
  src/mesa/main/format_unpack.c.mako |  883 
  src/mesa/main/format_utils.c   |  215 +-
  src/mesa/main/format_utils.h   |  105 +
  src/mesa/main/formats.c|   14 +-
  src/mesa/main/run_mako.py  |7 +
  src/mesa/main/texstore.c   |2 +-
  src/mesa/swrast/s_texfetch_tmp.h   |   16 +-
  14 files changed, 2061 insertions(+), 4525 deletions(-)
  create mode 100644 src/mesa/main/format_convert.py
  create mode 100644 src/mesa/main/format_pack.c.mako
  delete mode 100644 src/mesa/main/format_unpack.c
  create mode 100644 src/mesa/main/format_unpack.c.mako
  create mode 100644 src/mesa/main/run_mako.py

 --
 2.1.0



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


[Mesa-dev] [PATCH] i965/fs: Fix basic block tracking in try_rep_send().

2014-09-04 Thread Matt Turner
The 'start' instruction is always in the current block, except for the
case of shader time, which emits code in a pattern seen no where else.
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 255df18..813e93d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2305,6 +2305,7 @@ fs_visitor::try_rep_send()
 {
int i, count;
fs_inst *start = NULL;
+   bblock_t *mov_block;
 
/* From the Ivybridge PRM, Volume 4 Part 1, section 3.9.11.2
 * (Message Descriptor - Render Target Write):
@@ -2334,15 +2335,19 @@ fs_visitor::try_rep_send()
 */
count = 0;
foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
-  if (count == 0)
+  if (count == 0) {
  start = inst;
+ mov_block = block;
+  }
   if (inst-opcode == BRW_OPCODE_MOV 
  inst-dst.file == MRF 
   inst-dst.reg == start-dst.reg + 2 * count 
   inst-src[0].file == HW_REG 
   inst-src[0].reg_offset == start-src[0].reg_offset + count) {
- if (count == 0)
+ if (count == 0) {
 start = inst;
+mov_block = block;
+ }
  count++;
   }
 
@@ -2372,9 +2377,9 @@ fs_visitor::try_rep_send()
  mov-dst.type = BRW_REGISTER_TYPE_F;
 
  /* Replace the four MOVs with the new vec4 MOV. */
- start-insert_before(block, mov);
+ start-insert_before(mov_block, mov);
  for (i = 0; i  4; i++)
-((fs_inst *)mov-next)-remove(block);
+((fs_inst *)mov-next)-remove(mov_block);
 
  /* Finally, adjust the message length and set the opcode to
   * REP_FB_WRITE for the send, so that the generator will use the
-- 
1.8.5.5

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


Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading

2014-09-04 Thread Alexandre Demers

I've been testing your patch v2 on cayman.

Here are my results. For now, my piglit runs are not conclusive because 
a quick run fails even without your patch: almost at the end of the run, 
X crashes.


However, using Tesseract as you suggested gave good results. First, it 
fixes a visual glitch appearing on object's edges. Also, being at the 
same position and pointing at the same place resulted in a FPS rate 
greatly improved (from 21 fps to 37 fps).


So it seems good on cayman. I'll try to confirm it even further with a 
good piglit run if I find a way to run it correctly first without the 
patch.


--
Alexandre Demers

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3 v2] mesa: Handle uninitialized textures like other textures in get_tex_level_parameter_image

2014-09-04 Thread Kenneth Graunke
On Thursday, September 04, 2014 04:16:47 PM Brian Paul wrote:
 On 09/04/2014 03:17 PM, Kenneth Graunke wrote:
  On Wednesday, September 03, 2014 06:50:39 PM Carl Worth wrote:
  Carl Worth cwo...@cworth.org writes:
  Emil Velikov emil.l.veli...@gmail.com writes:
 
  I will not have the chance to run piglit on a i965 system until next
  week so I would love if someone can take a look at this.
 
  I should be able to take a look at this today or tomorrow.
 
  I didn't see any failures on i965. Oddly, piglit doesn't seem to be
  running this test for me, (maybe I'm missing all glean testing from
  piglit?!---I'll debug that later.).
 
  Glean is excluded by the '-p gbm' option because Glean uses GLUT, not 
  Waffle, and therefore only runs on GLX.  (It has no EGL/X11, Wayland, or 
  GBM support.)
 
  Our plan has been to replace Glean with native Piglit tests.  We've been 
  making some progress toward that, but there's a pile more work to do.
 
 It would be great if there were a to-do list on the piglit website to 
 maybe inspire people to do some of that work.  And one of the first 
 items on the piglit to-do list should be to overhaul the piglit website 
 itself.

I agree - I've thought about adding a PiglitToDo page on the DRI wiki, where 
people could put ideas for things that need to get done, without having to take 
the time to do them all.  We always think of a million things that need more 
tests or testing that needs to be improved, but don't always have the time to 
get to it right away...writing them down seems better than forgetting about 
them.

 http://people.freedesktop.org/~nh/piglit/

Carl (I believe) created a new website in January 2013:

http://piglit.freedesktop.org/

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


[Mesa-dev] [PATCH 00/10] i965: Add a width field to fs_inst

2014-09-04 Thread Jason Ekstrand
This is the first chunk of patches in my work on adding instruction and
register widths to the fs backend.  Eventually, this will allow us to more
easily emit 8-wide instructions in SIMD16 mode from the fs_visitor level.
More patches will be coming to add a width field to the registers and allow
for more fine-grained register allocation.

I talked to Ken in the office today about maybe delaying these patches
until later, but they turned out pretty clean so I decided to send them
now.

At each commit in the series there are 0 piglit chages from master on HSW.

Jason Ekstrand (10):
  i965/fs: Clean up emitting of untyped atomic and sruface reads
  i965/fs: Add a width field to fs_inst
  i965/fs: Properly set the instruction width for atomics and surface
reads
  i965/fs: Set instruction widths in a variety of places
  i965/fs: Derive force_uncompressed from instruction width
  i965/fs: Remove unneeded uses of force_uncompressed
  i965/fs: Use instruction widths to set compression state
  i965/fs: Use instruction width instead of heuristics
  i965/fs: Determine partial writes with instruction widths
  i965/fs: Use instruction width directly for texture generation

 src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp|  10 +-
 src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h  |  34 +++---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 116 +++--
 src/mesa/drivers/dri/i965/brw_fs.h |  30 --
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp |  33 --
 .../drivers/dri/i965/brw_fs_live_variables.cpp |  10 +-
 src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp  |   8 +-
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  54 +-
 .../drivers/dri/i965/brw_schedule_instructions.cpp |   4 +-
 9 files changed, 165 insertions(+), 134 deletions(-)

-- 
2.1.0

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


[Mesa-dev] [PATCH 01/10] i965/fs: Clean up emitting of untyped atomic and sruface reads

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 8426ad3..0206fb0 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2685,6 +2685,7 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
 {
const unsigned operand_len = dispatch_width / 8;
unsigned mlen = 0;
+   fs_inst *inst;
 
/* Initialize the sample mask in the message header. */
emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
@@ -2717,12 +2718,10 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
}
 
/* Emit the instruction. */
-   fs_inst *inst = new(mem_ctx) fs_inst(SHADER_OPCODE_UNTYPED_ATOMIC, dst,
-atomic_op, surf_index);
+   inst = emit(SHADER_OPCODE_UNTYPED_ATOMIC, dst, atomic_op, surf_index);
inst-base_mrf = 0;
inst-mlen = mlen;
inst-header_present = true;
-   emit(inst);
 }
 
 void
@@ -2731,6 +2730,7 @@ fs_visitor::emit_untyped_surface_read(unsigned 
surf_index, fs_reg dst,
 {
const unsigned operand_len = dispatch_width / 8;
unsigned mlen = 0;
+   fs_inst *inst;
 
/* Initialize the sample mask in the message header. */
emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
@@ -2752,12 +2752,10 @@ fs_visitor::emit_untyped_surface_read(unsigned 
surf_index, fs_reg dst,
mlen += operand_len;
 
/* Emit the instruction. */
-   fs_inst *inst = new(mem_ctx)
-  fs_inst(SHADER_OPCODE_UNTYPED_SURFACE_READ, dst, surf_index);
+   inst = emit(SHADER_OPCODE_UNTYPED_SURFACE_READ, dst, surf_index);
inst-base_mrf = 0;
inst-mlen = mlen;
inst-header_present = true;
-   emit(inst);
 }
 
 fs_inst *
-- 
2.1.0

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


[Mesa-dev] [PATCH 05/10] i965/fs: Derive force_uncompressed from instruction width

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index ad89914..3c798f1 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2764,6 +2764,9 @@ fs_inst *
 fs_visitor::emit(fs_inst *inst)
 {
if (force_uncompressed_stack  0)
+  inst-width = 8;
+
+   if (dispatch_width == 16  inst-width == 8)
   inst-force_uncompressed = true;
 
inst-annotation = this-current_annotation;
-- 
2.1.0

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


[Mesa-dev] [PATCH 03/10] i965/fs: Properly set the instruction width for atomics and surface reads

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 30 +++-
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index a8c24e8..61b026b 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2688,17 +2688,18 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
fs_inst *inst;
 
/* Initialize the sample mask in the message header. */
-   emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
-  -force_writemask_all = true;
+   inst = emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)));
+   inst-force_writemask_all = true;
+   inst-width = 8;
 
if (fp-UsesKill) {
-  emit(MOV(brw_uvec_mrf(1, mlen, 7), brw_flag_reg(0, 1)))
- -force_writemask_all = true;
+  inst = emit(MOV(brw_uvec_mrf(1, mlen, 7), brw_flag_reg(0, 1)));
} else {
-  emit(MOV(brw_uvec_mrf(1, mlen, 7),
-   retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)))
- -force_writemask_all = true;
+  inst = emit(MOV(brw_uvec_mrf(1, mlen, 7),
+  retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)));
}
+   inst-force_writemask_all = true;
+   inst-width = 1;
 
mlen++;
 
@@ -2733,17 +2734,18 @@ fs_visitor::emit_untyped_surface_read(unsigned 
surf_index, fs_reg dst,
fs_inst *inst;
 
/* Initialize the sample mask in the message header. */
-   emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)))
-  -force_writemask_all = true;
+   inst = emit(MOV(brw_uvec_mrf(8, mlen, 0), fs_reg(0u)));
+   inst-force_writemask_all = true;
+   inst-width = 8;
 
if (fp-UsesKill) {
-  emit(MOV(brw_uvec_mrf(1, mlen, 7), brw_flag_reg(0, 1)))
- -force_writemask_all = true;
+  inst = emit(MOV(brw_uvec_mrf(1, mlen, 7), brw_flag_reg(0, 1)));
} else {
-  emit(MOV(brw_uvec_mrf(1, mlen, 7),
-   retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)))
- -force_writemask_all = true;
+  inst = emit(MOV(brw_uvec_mrf(1, mlen, 7),
+  retype(brw_vec1_grf(1, 7), BRW_REGISTER_TYPE_UD)));
}
+   inst-force_writemask_all = true;
+   inst-width = 1;
 
mlen++;
 
-- 
2.1.0

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


[Mesa-dev] [PATCH 04/10] i965/fs: Set instruction widths in a variety of places

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 6 ++
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 -
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c39a062..cbd3a77 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -342,6 +342,7 @@ fs_visitor::DEP_RESOLVE_MOV(int grf)
/* The caller always wants uncompressed to emit the minimal extra
 * dependencies, and to avoid having to deal with aligning its regs to 2.
 */
+   inst-width = 8;
inst-force_uncompressed = true;
 
return inst;
@@ -557,6 +558,7 @@ fs_visitor::get_timestamp()
 */
mov-force_writemask_all = true;
mov-force_uncompressed = true;
+   mov-width = 8;
 
/* The caller wants the low 32 bits of the timestamp.  Since it's running
 * at the GPU clock rate of ~1.2ghz, it will roll over every ~3 seconds,
@@ -1289,9 +1291,11 @@ fs_visitor::emit_samplepos_setup()
 
fs_inst *inst = emit(MOV(int_sample_x, fs_reg(sample_pos_reg)));
if (dispatch_width == 16) {
+  inst-width = 8;
   inst-force_uncompressed = true;
   inst = emit(MOV(half(int_sample_x, 1),
   fs_reg(suboffset(sample_pos_reg, 16;
+  inst-width = 8;
   inst-force_sechalf = true;
}
/* Compute gl_SamplePosition.x */
@@ -1299,9 +1303,11 @@ fs_visitor::emit_samplepos_setup()
pos.reg_offset++;
inst = emit(MOV(int_sample_y, fs_reg(suboffset(sample_pos_reg, 1;
if (dispatch_width == 16) {
+  inst-width = 8;
   inst-force_uncompressed = true;
   inst = emit(MOV(half(int_sample_y, 1),
   fs_reg(suboffset(sample_pos_reg, 17;
+  inst-width = 8;
   inst-force_sechalf = true;
}
/* Compute gl_SamplePosition.y */
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 61b026b..ad89914 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2965,11 +2965,13 @@ fs_visitor::emit_color_write(int target, int index, int 
first_color_mrf)
 push_force_uncompressed();
 inst = emit(MOV(fs_reg(MRF, first_color_mrf + index, color.type),
  color));
+ inst-width = 8;
 inst-saturate = key-clamp_fragment_color;
 pop_force_uncompressed();
 
 inst = emit(MOV(fs_reg(MRF, first_color_mrf + index + 4, color.type),
  half(color, 1)));
+ inst-width = 8;
 inst-force_sechalf = true;
 inst-saturate = key-clamp_fragment_color;
   }
@@ -3073,7 +3075,8 @@ fs_visitor::emit_fb_writes()
if (payload.aa_dest_stencil_reg) {
   push_force_uncompressed();
   emit(MOV(fs_reg(MRF, nr++),
-   fs_reg(brw_vec8_grf(payload.aa_dest_stencil_reg, 0;
+   fs_reg(brw_vec8_grf(payload.aa_dest_stencil_reg, 0
+  -width = 8;
   pop_force_uncompressed();
}
 
-- 
2.1.0

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


[Mesa-dev] [PATCH 09/10] i965/fs: Determine partial writes with instruction widths

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 64cb056..7da8cf5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -706,8 +706,8 @@ fs_visitor::spill_reg(int spill_reg)
   * inst-regs_written(), then we need to unspill the destination
   * since we write back out all of the regs_written().
  */
-if (inst-predicate || inst-force_uncompressed ||
- inst-force_sechalf || inst-dst.subreg_offset) {
+if (inst-predicate || inst-width  dispatch_width ||
+ inst-dst.subreg_offset) {
 emit_unspill(block, inst, spill_src, subset_spill_offset,
  inst-regs_written);
 }
-- 
2.1.0

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


[Mesa-dev] [PATCH 02/10] i965/fs: Add a width field to fs_inst

2014-09-04 Thread Jason Ekstrand
This will, eventually, allow us to manage execution widths of instructions
in a much more natural way from the fs_visitor level.

Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp   | 10 +--
 src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 32 +-
 src/mesa/drivers/dri/i965/brw_fs.cpp  | 76 +--
 src/mesa/drivers/dri/i965/brw_fs.h| 30 ++---
 src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |  4 +-
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp  |  2 +-
 6 files changed, 89 insertions(+), 65 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp 
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index 82ece73..31f4a20 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -69,7 +69,7 @@ brw_blorp_eu_emitter::emit_kill_if_outside_rect(const struct 
brw_reg x,
emit_cmp(BRW_CONDITIONAL_L, x, dst_x1)-predicate = BRW_PREDICATE_NORMAL;
emit_cmp(BRW_CONDITIONAL_L, y, dst_y1)-predicate = BRW_PREDICATE_NORMAL;
 
-   fs_inst *inst = new (mem_ctx) fs_inst(BRW_OPCODE_AND, g1, f0, g1);
+   fs_inst *inst = new (mem_ctx) fs_inst(BRW_OPCODE_AND, 16, g1, f0, g1);
inst-force_writemask_all = true;
insts.push_tail(inst);
 }
@@ -80,7 +80,7 @@ brw_blorp_eu_emitter::emit_texture_lookup(const struct 
brw_reg dst,
   unsigned base_mrf,
   unsigned msg_length)
 {
-   fs_inst *inst = new (mem_ctx) fs_inst(op, dst, brw_message_reg(base_mrf),
+   fs_inst *inst = new (mem_ctx) fs_inst(op, 16, dst, 
brw_message_reg(base_mrf),
  fs_reg(0u));
 
inst-base_mrf = base_mrf;
@@ -96,7 +96,7 @@ brw_blorp_eu_emitter::emit_render_target_write(const struct 
brw_reg src0,
unsigned msg_length,
bool use_header)
 {
-   fs_inst *inst = new (mem_ctx) fs_inst(FS_OPCODE_BLORP_FB_WRITE);
+   fs_inst *inst = new (mem_ctx) fs_inst(FS_OPCODE_BLORP_FB_WRITE, 16);
 
inst-src[0] = src0;
inst-base_mrf = msg_reg_nr;
@@ -115,7 +115,7 @@ brw_blorp_eu_emitter::emit_combine(enum opcode 
combine_opcode,
 {
assert(combine_opcode == BRW_OPCODE_ADD || combine_opcode == 
BRW_OPCODE_AVG);
 
-   insts.push_tail(new (mem_ctx) fs_inst(combine_opcode, dst, src_1, src_2));
+   insts.push_tail(new (mem_ctx) fs_inst(combine_opcode, 16, dst, src_1, 
src_2));
 }
 
 fs_inst *
@@ -123,7 +123,7 @@ brw_blorp_eu_emitter::emit_cmp(enum brw_conditional_mod op,
const struct brw_reg x,
const struct brw_reg y)
 {
-   fs_inst *cmp = new (mem_ctx) fs_inst(BRW_OPCODE_CMP,
+   fs_inst *cmp = new (mem_ctx) fs_inst(BRW_OPCODE_CMP, 16,
 vec16(brw_null_reg()), x, y);
cmp-conditional_mod = op;
insts.push_tail(cmp);
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h 
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
index 0459a7e..cd50da4 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
@@ -65,7 +65,7 @@ protected:
{
   emit_cmp(op, x, y);
 
-  fs_inst *mv = new (mem_ctx) fs_inst(BRW_OPCODE_MOV, dst, src);
+  fs_inst *mv = new (mem_ctx) fs_inst(BRW_OPCODE_MOV, 16, dst, src);
   mv-predicate = BRW_PREDICATE_NORMAL;
   insts.push_tail(mv);
}
@@ -82,17 +82,17 @@ protected:
 const struct brw_reg src3)
{
   insts.push_tail(
- new (mem_ctx) fs_inst(BRW_OPCODE_LRP, dst, src1, src2, src3));
+ new (mem_ctx) fs_inst(BRW_OPCODE_LRP, 16, dst, src1, src2, src3));
}
 
inline void emit_mov(const struct brw_reg dst, const struct brw_reg src)
{
-  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_MOV, dst, src));
+  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_MOV, 16, dst, src));
}
 
inline void emit_mov_8(const struct brw_reg dst, const struct brw_reg src)
{
-  fs_inst *mv = new (mem_ctx) fs_inst(BRW_OPCODE_MOV, dst, src);
+  fs_inst *mv = new (mem_ctx) fs_inst(BRW_OPCODE_MOV, 8, dst, src);
   mv-force_uncompressed = true;
   insts.push_tail(mv);
}
@@ -101,21 +101,21 @@ protected:
 const struct brw_reg src1,
 const struct brw_reg src2)
{
-  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_AND, dst, src1, src2));
+  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_AND, 16, dst, src1, 
src2));
}
 
inline void emit_add(const struct brw_reg dst,
 const struct brw_reg src1,
 const struct brw_reg src2)
{
-  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_ADD, dst, src1, src2));
+  insts.push_tail(new (mem_ctx) fs_inst(BRW_OPCODE_ADD, 16, dst, 

[Mesa-dev] [PATCH 08/10] i965/fs: Use instruction width instead of heuristics

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs.cpp   | 30 --
 .../drivers/dri/i965/brw_fs_live_variables.cpp | 10 
 .../drivers/dri/i965/brw_schedule_instructions.cpp |  4 +--
 3 files changed, 16 insertions(+), 28 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 15c68be..2d1e601 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2185,8 +2185,7 @@ fs_visitor::compute_to_mrf()
   int mrf_high;
   if (inst-dst.reg  BRW_MRF_COMPR4) {
 mrf_high = mrf_low + 4;
-  } else if (dispatch_width == 16 
-(!inst-force_uncompressed  !inst-force_sechalf)) {
+  } else if (inst-width == 16) {
 mrf_high = mrf_low + 1;
   } else {
 mrf_high = mrf_low;
@@ -2279,9 +2278,7 @@ fs_visitor::compute_to_mrf()
 
if (scan_inst-dst.reg  BRW_MRF_COMPR4) {
   scan_mrf_high = scan_mrf_low + 4;
-   } else if (dispatch_width == 16 
-  (!scan_inst-force_uncompressed 
-   !scan_inst-force_sechalf)) {
+   } else if (scan_inst-width == 16) {
   scan_mrf_high = scan_mrf_low + 1;
} else {
   scan_mrf_high = scan_mrf_low;
@@ -2488,10 +2485,6 @@ static void
 clear_deps_for_inst_src(fs_inst *inst, int dispatch_width, bool *deps,
 int first_grf, int grf_len)
 {
-   bool inst_simd16 = (dispatch_width  8 
-   !inst-force_uncompressed 
-   !inst-force_sechalf);
-
/* Clear the flag for registers that actually got read (as expected). */
for (int i = 0; i  inst-sources; i++) {
   int grf;
@@ -2507,7 +2500,7 @@ clear_deps_for_inst_src(fs_inst *inst, int 
dispatch_width, bool *deps,
   if (grf = first_grf 
   grf  first_grf + grf_len) {
  deps[grf - first_grf] = false;
- if (inst_simd16)
+ if (inst-width == 16)
 deps[grf - first_grf + 1] = false;
   }
}
@@ -2565,10 +2558,6 @@ 
fs_visitor::insert_gen4_pre_send_dependency_workarounds(fs_inst *inst)
  return;
   }
 
-  bool scan_inst_simd16 = (dispatch_width  8 
-   !scan_inst-force_uncompressed 
-   !scan_inst-force_sechalf);
-
   /* We insert our reads as late as possible on the assumption that any
* instruction but a MOV that might have left us an outstanding
* dependency has more latency than a MOV.
@@ -2582,7 +2571,7 @@ 
fs_visitor::insert_gen4_pre_send_dependency_workarounds(fs_inst *inst)
 needs_dep[reg - first_write_grf]) {
inst-insert_before(DEP_RESOLVE_MOV(reg));
needs_dep[reg - first_write_grf] = false;
-   if (scan_inst_simd16)
+   if (scan_inst-width == 16)
   needs_dep[reg - first_write_grf + 1] = false;
 }
  }
@@ -3004,11 +2993,12 @@ fs_visitor::dump_instruction(backend_instruction 
*be_inst, FILE *file)
 
fprintf(file,  );
 
-   if (inst-force_uncompressed)
-  fprintf(file, 1sthalf );
-
-   if (inst-force_sechalf)
-  fprintf(file, 2ndhalf );
+   if (inst-width == 16) {
+  if (inst-force_sechalf)
+ fprintf(file, 2ndhalf );
+  else
+ fprintf(file, 1sthalf );
+   }
 
fprintf(file, \n);
 }
diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
index e7ecb0f..160bf71 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp
@@ -85,11 +85,11 @@ fs_live_variables::setup_one_read(bblock_t *block, fs_inst 
*inst,
 * would get stomped by the first decode as well.
 */
int end_ip = ip;
-   if (v-dispatch_width == 16  (reg.stride == 0 ||
-   reg.type == BRW_REGISTER_TYPE_UW ||
-   reg.type == BRW_REGISTER_TYPE_W ||
-   reg.type == BRW_REGISTER_TYPE_UB ||
-   reg.type == BRW_REGISTER_TYPE_B)) {
+   if (inst-width == 16  (reg.stride == 0 ||
+ reg.type == BRW_REGISTER_TYPE_UW ||
+ reg.type == BRW_REGISTER_TYPE_W ||
+ reg.type == BRW_REGISTER_TYPE_UB ||
+ reg.type == BRW_REGISTER_TYPE_B)) {
   end_ip++;
}
 
diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp 
b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
index 04ac242..1b6020c 100644
--- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
+++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
@@ -734,9 +734,7 @@ instruction_scheduler::add_barrier_deps(schedule_node *n)
 bool
 

[Mesa-dev] [PATCH 06/10] i965/fs: Remove unneeded uses of force_uncompressed

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h | 2 --
 src/mesa/drivers/dri/i965/brw_fs.cpp  | 4 
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp  | 4 
 3 files changed, 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h 
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
index cd50da4..a32090b 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.h
@@ -93,7 +93,6 @@ protected:
inline void emit_mov_8(const struct brw_reg dst, const struct brw_reg src)
{
   fs_inst *mv = new (mem_ctx) fs_inst(BRW_OPCODE_MOV, 8, dst, src);
-  mv-force_uncompressed = true;
   insts.push_tail(mv);
}
 
@@ -116,7 +115,6 @@ protected:
   const struct brw_reg src2)
{
   fs_inst *add = new (mem_ctx) fs_inst(BRW_OPCODE_ADD, 8, dst, src1, src2);
-  add-force_uncompressed = true;
   insts.push_tail(add);
}
 
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cbd3a77..15c68be 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -343,7 +343,6 @@ fs_visitor::DEP_RESOLVE_MOV(int grf)
 * dependencies, and to avoid having to deal with aligning its regs to 2.
 */
inst-width = 8;
-   inst-force_uncompressed = true;
 
return inst;
 }
@@ -557,7 +556,6 @@ fs_visitor::get_timestamp()
 * even if it's not enabled in the dispatch.
 */
mov-force_writemask_all = true;
-   mov-force_uncompressed = true;
mov-width = 8;
 
/* The caller wants the low 32 bits of the timestamp.  Since it's running
@@ -1292,7 +1290,6 @@ fs_visitor::emit_samplepos_setup()
fs_inst *inst = emit(MOV(int_sample_x, fs_reg(sample_pos_reg)));
if (dispatch_width == 16) {
   inst-width = 8;
-  inst-force_uncompressed = true;
   inst = emit(MOV(half(int_sample_x, 1),
   fs_reg(suboffset(sample_pos_reg, 16;
   inst-width = 8;
@@ -1304,7 +1301,6 @@ fs_visitor::emit_samplepos_setup()
inst = emit(MOV(int_sample_y, fs_reg(suboffset(sample_pos_reg, 1;
if (dispatch_width == 16) {
   inst-width = 8;
-  inst-force_uncompressed = true;
   inst = emit(MOV(half(int_sample_y, 1),
   fs_reg(suboffset(sample_pos_reg, 17;
   inst-width = 8;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 3c798f1..f7141fc 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -2965,12 +2965,10 @@ fs_visitor::emit_color_write(int target, int index, int 
first_color_mrf)
  color));
 inst-saturate = key-clamp_fragment_color;
   } else {
-push_force_uncompressed();
 inst = emit(MOV(fs_reg(MRF, first_color_mrf + index, color.type),
  color));
  inst-width = 8;
 inst-saturate = key-clamp_fragment_color;
-pop_force_uncompressed();
 
 inst = emit(MOV(fs_reg(MRF, first_color_mrf + index + 4, color.type),
  half(color, 1)));
@@ -3076,11 +3074,9 @@ fs_visitor::emit_fb_writes()
}
 
if (payload.aa_dest_stencil_reg) {
-  push_force_uncompressed();
   emit(MOV(fs_reg(MRF, nr++),
fs_reg(brw_vec8_grf(payload.aa_dest_stencil_reg, 0
   -width = 8;
-  pop_force_uncompressed();
}
 
prog_data-uses_omask =
-- 
2.1.0

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


[Mesa-dev] [PATCH 10/10] i965/fs: Use instruction width directly for texture generation

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index e440f93..2d2fed7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -376,7 +376,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
 {
int msg_type = -1;
int rlen = 4;
-   uint32_t simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD8;
+   uint32_t simd_mode;
uint32_t return_format;
 
switch (dst.type) {
@@ -391,9 +391,16 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
   break;
}
 
-   if (dispatch_width == 16 
-  !inst-force_uncompressed  !inst-force_sechalf)
+   switch (inst-width) {
+   case 8:
+  simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD8;
+  break;
+   case 16:
   simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
+  break;
+   default:
+  assert(!Invalid width for texture instruction);
+   }
 
if (brw-gen = 5) {
   switch (inst-opcode) {
-- 
2.1.0

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


Re: [Mesa-dev] [PATCH 01/10] i965/fs: Clean up emitting of untyped atomic and sruface reads

2014-09-04 Thread Matt Turner
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/10] i965/fs: Clean up emitting of untyped atomic and sruface reads

2014-09-04 Thread Matt Turner
On Thu, Sep 4, 2014 at 10:38 PM, Matt Turner matts...@gmail.com wrote:
 Reviewed-by: Matt Turner matts...@gmail.com

That is, with the typo in the subject fixed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/10] i965/fs: Add a width field to fs_inst

2014-09-04 Thread Matt Turner
On Thu, Sep 4, 2014 at 10:19 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
 This will, eventually, allow us to manage execution widths of instructions
 in a much more natural way from the fs_visitor level.

 Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com

Adding a width field to fs_inst might be fine, but I don't think I
like adding the parameter to every fs_inst constructor. It seems like
it's something that's rarely going to be non-default. With other
things like that we just set them after creating the instruction.

Also, am I correct that the width field isn't actually hooked up to
anything at this point?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 07/10] i965/fs: Use instruction widths to set compression state

2014-09-04 Thread Jason Ekstrand
Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index d860700..e440f93 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1517,12 +1517,22 @@ fs_generator::generate_code(const cfg_t *cfg)
   brw_set_default_mask_control(p, inst-force_writemask_all);
   brw_set_default_acc_write_control(p, inst-writes_accumulator);
 
-  if (inst-force_uncompressed || dispatch_width == 8) {
+  switch (inst-width) {
+  case 1:
 brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
-  } else if (inst-force_sechalf) {
-brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
-  } else {
-brw_set_default_compression_control(p, BRW_COMPRESSION_COMPRESSED);
+ break;
+  case 8:
+ if (inst-force_sechalf) {
+brw_set_default_compression_control(p, BRW_COMPRESSION_2NDHALF);
+ } else {
+   brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
+ }
+ break;
+  case 16:
+ brw_set_default_compression_control(p, BRW_COMPRESSION_COMPRESSED);
+ break;
+  default:
+ assert(!Invalid instruction width);
   }
 
   switch (inst-opcode) {
-- 
2.1.0

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


Re: [Mesa-dev] [PATCH 10/10] i965/fs: Use instruction width directly for texture generation

2014-09-04 Thread Matt Turner
On Thu, Sep 4, 2014 at 10:19 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
 Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com
 ---
  src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

 diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
 b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
 index e440f93..2d2fed7 100644
 --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
 +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
 @@ -376,7 +376,7 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
 dst, struct brw_reg src
  {
 int msg_type = -1;
 int rlen = 4;
 -   uint32_t simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD8;
 +   uint32_t simd_mode;
 uint32_t return_format;

 switch (dst.type) {
 @@ -391,9 +391,16 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
 dst, struct brw_reg src
break;
 }

 -   if (dispatch_width == 16 
 -  !inst-force_uncompressed  !inst-force_sechalf)
 +   switch (inst-width) {
 +   case 8:
 +  simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD8;
 +  break;
 +   case 16:
simd_mode = BRW_SAMPLER_SIMD_MODE_SIMD16;
 +  break;
 +   default:
 +  assert(!Invalid width for texture instruction);

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


Re: [Mesa-dev] [PATCH 02/10] i965/fs: Add a width field to fs_inst

2014-09-04 Thread Jason Ekstrand
On Sep 4, 2014 10:45 PM, Matt Turner matts...@gmail.com wrote:

 On Thu, Sep 4, 2014 at 10:19 PM, Jason Ekstrand ja...@jlekstrand.net
wrote:
  This will, eventually, allow us to manage execution widths of
instructions
  in a much more natural way from the fs_visitor level.
 
  Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com

 Adding a width field to fs_inst might be fine, but I don't think I
 like adding the parameter to every fs_inst constructor. It seems like
 it's something that's rarely going to be non-default. With other
 things like that we just set them after creating the instruction.

Unfortunately, there's no good way to set a default in fs_inst when the
constructor is unaware of the fs_visitor.  The default is provided by the
fs_visitor::emit functions.  This is admittedly a little painful for blorp,
but it works out OK for fs_visitor.

I tried making a value of 0 mean choose a default for me but that didn't
work well either.  The only other real option would be to guess based on
register widths but that gets us to a chicken-and-egg problem where
register width depends on instruction width and vice-versa.

 Also, am I correct that the width field isn't actually hooked up to
 anything at this point?

Yes, that's correct. Hooking it up comes later.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev