[Mesa-dev] [PATCH 1/4] i965: Make emit_shader_time_write return rather than emit.

2015-02-27 Thread Kenneth Graunke
Instead of emit_shader_time_write, we now do emit(SHADER_TIME_ADD(...)).
The advantage is that we can also insert a shader time write at an
arbitrary location in the instruction stream, rather than being
restricted to emitting at the end.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 15 +++
 src/mesa/drivers/dri/i965/brw_fs.h   |  3 +--
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0354f56..9c6f084 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -775,16 +775,15 @@ fs_visitor::emit_shader_time_end()
 */
emit(ADD(diff, diff, fs_reg(-2u)));
 
-   emit_shader_time_write(type, diff);
-   emit_shader_time_write(written_type, fs_reg(1u));
+   emit(SHADER_TIME_ADD(type, diff));
+   emit(SHADER_TIME_ADD(written_type, fs_reg(1u)));
emit(BRW_OPCODE_ELSE);
-   emit_shader_time_write(reset_type, fs_reg(1u));
+   emit(SHADER_TIME_ADD(reset_type, fs_reg(1u)));
emit(BRW_OPCODE_ENDIF);
 }
 
-void
-fs_visitor::emit_shader_time_write(enum shader_time_shader_type type,
-   fs_reg value)
+fs_inst *
+fs_visitor::SHADER_TIME_ADD(enum shader_time_shader_type type, fs_reg value)
 {
int shader_time_index =
   brw_get_shader_time_index(brw, shader_prog, prog, type);
@@ -796,8 +795,8 @@ fs_visitor::emit_shader_time_write(enum 
shader_time_shader_type type,
else
   payload = vgrf(glsl_type::uint_type);
 
-   emit(new(mem_ctx) fs_inst(SHADER_OPCODE_SHADER_TIME_ADD,
- fs_reg(), payload, offset, value));
+   return new(mem_ctx) fs_inst(SHADER_OPCODE_SHADER_TIME_ADD,
+   fs_reg(), payload, offset, value);
 }
 
 void
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 70098d8..be1c8a1 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -378,8 +378,7 @@ public:
 
void emit_shader_time_begin();
void emit_shader_time_end();
-   void emit_shader_time_write(enum shader_time_shader_type type,
-   fs_reg value);
+   fs_inst *SHADER_TIME_ADD(enum shader_time_shader_type type, fs_reg value);
 
void emit_untyped_atomic(unsigned atomic_op, unsigned surf_index,
 fs_reg dst, fs_reg offset, fs_reg src0,
-- 
2.2.2

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


[Mesa-dev] [PATCH 3/4] i965/fs: Make emit_shader_time_end() insert before EOT.

2015-02-27 Thread Kenneth Graunke
Previously, we emitted the shader-time epilogue from emit_fb_writes(),
during the middle of looping through color regions (or emit_urb_writes
for the VS).  This is duplicated several times and rather awkward.

I need to fix a bug in our FB write handling, and it will be a lot
easier if we move emit_shader_time_end() out of there.

Now, we simply emit FB writes/URB writes, and subsequently have
emit_shader_time_end() insert instructions before the final SEND with
EOT.  Not only is this simpler, it's actually a slight improvement:
we now include the MOVs to set up the final FB write payload in our
shader-time measurements.

Note that INTEL_DEBUG=shader_time only exists on Gen7+, and uses
send-from-GRF.  (In the past, we might have hit trouble where both
attempt to use MRFs for messages; that's not a problem now.)

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 29 ++--
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 13 -
 2 files changed, 19 insertions(+), 23 deletions(-)

I verified that INTEL_DEBUG=shader_time produced equivalent results on
anholt's openarena timedemo before and after this patch.

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index faa6f3f..2fd7f46 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -754,7 +754,12 @@ fs_visitor::emit_shader_time_end()
   unreachable("fs_visitor::emit_shader_time_end missing code");
}
 
-   fs_inst *tm_read = emit(timestamp_read());
+   /* Insert our code just before the final SEND with EOT. */
+   exec_node *end = this->instructions.get_tail();
+   assert(end && ((fs_inst *) end)->eot);
+
+   fs_inst *tm_read = timestamp_read();
+   end->insert_before(tm_read);
fs_reg shader_end_time = tm_read->dst;
 
/* Check that there weren't any timestamp reset events (assuming these
@@ -762,26 +767,27 @@ fs_visitor::emit_shader_time_end()
 */
fs_reg reset = shader_end_time;
reset.set_smear(2);
-   fs_inst *test = emit(AND(reg_null_d, reset, fs_reg(1u)));
+   fs_inst *test = AND(reg_null_d, reset, fs_reg(1u));
test->conditional_mod = BRW_CONDITIONAL_Z;
-   emit(IF(BRW_PREDICATE_NORMAL));
+   end->insert_before(test);
+   end->insert_before(IF(BRW_PREDICATE_NORMAL));
 
fs_reg start = shader_start_time;
start.negate = true;
fs_reg diff = fs_reg(GRF, alloc.allocate(1), BRW_REGISTER_TYPE_UD, 1);
-   emit(ADD(diff, start, shader_end_time));
+   end->insert_before(ADD(diff, start, shader_end_time));
 
/* If there were no instructions between the two timestamp gets, the diff
 * is 2 cycles.  Remove that overhead, so I can forget about that when
 * trying to determine the time taken for single instructions.
 */
-   emit(ADD(diff, diff, fs_reg(-2u)));
+   end->insert_before(ADD(diff, diff, fs_reg(-2u)));
 
-   emit(SHADER_TIME_ADD(type, diff));
-   emit(SHADER_TIME_ADD(written_type, fs_reg(1u)));
-   emit(BRW_OPCODE_ELSE);
-   emit(SHADER_TIME_ADD(reset_type, fs_reg(1u)));
-   emit(BRW_OPCODE_ENDIF);
+   end->insert_before(SHADER_TIME_ADD(type, diff));
+   end->insert_before(SHADER_TIME_ADD(written_type, fs_reg(1u)));
+   end->insert_before(new(mem_ctx) fs_inst(BRW_OPCODE_ELSE, dispatch_width));
+   end->insert_before(SHADER_TIME_ADD(reset_type, fs_reg(1u)));
+   end->insert_before(new(mem_ctx) fs_inst(BRW_OPCODE_ENDIF, dispatch_width));
 }
 
 fs_inst *
@@ -3913,6 +3919,9 @@ fs_visitor::run_fs()
 
   emit_fb_writes();
 
+  if (INTEL_DEBUG & DEBUG_SHADER_TIME)
+ emit_shader_time_end();
+
   calculate_cfg();
 
   optimize();
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 13a3bf2..77e1103 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3648,9 +3648,6 @@ fs_visitor::emit_fb_writes()
 
fs_inst *inst;
if (do_dual_src) {
-  if (INTEL_DEBUG & DEBUG_SHADER_TIME)
- emit_shader_time_end();
-
   this->current_annotation = ralloc_asprintf(this->mem_ctx,
 "FB dual-source write");
   inst = emit_single_fb_write(this->outputs[0], this->dual_src_output,
@@ -3666,19 +3663,12 @@ fs_visitor::emit_fb_writes()
  if (brw->gen >= 6 && key->replicate_alpha && target != 0)
 src0_alpha = offset(outputs[0], 3);
 
- if (target == key->nr_color_regions - 1 &&
- (INTEL_DEBUG & DEBUG_SHADER_TIME))
-emit_shader_time_end();
-
  inst = emit_single_fb_write(this->outputs[target], reg_undef,
  src0_alpha,
  this->output_components[target]);
  inst->target = target;
   }
} else {
-  if (INTEL_DEBUG & DEBUG_SHADER_TIME)
- emit_shader_time_end();
-
   /* Even if there's no color buffers enabled, we still need to se

[Mesa-dev] [PATCH 4/4] i965/fs: Don't issue FB writes for bound but unwritten color targets.

2015-02-27 Thread Kenneth Graunke
We used to loop over all color attachments, and emit FB writes for each
one, even if the shader didn't write to a corresponding output variable.
Those color attachments would be filled with garbage (undefined values).

Football Manager binds a framebuffer with 4 color attachments, but draws
to it using a shader that only writes to gl_FragData[0..2].  This meant
that color attachment 3 would be filled with garbage, resulting in
rendering artifacts.  Now we skip writing to it, fixing rendering.

Writes to gl_FragColor initialize outputs[0..nr_color_regions-1] to
GRFs, while writes to gl_FragData[i] initialize outputs[i].

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86747
Signed-off-by: Kenneth Graunke 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

While this should be much more correct, I wonder if more fixes are needed.

It seems like the loop condition should be:

   for (int target = 0; target < BRW_MAX_DRAW_BUFFERS; target++)

Even if we have only 1 color region, it could be attached to
GL_COLOR_ATTACHMENT3.  (Ilia mentioned this should be legal.)
It sure looks like that would break here (and probably always has).
Unfortunately, fixing that means binding more NULL render targets,
and that's complex enough I think it's best left to a follow-up series.

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 77e1103..dc5c2fe 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3646,7 +3646,7 @@ fs_visitor::emit_fb_writes()
  do_dual_src = false;
}
 
-   fs_inst *inst;
+   fs_inst *inst = NULL;
if (do_dual_src) {
   this->current_annotation = ralloc_asprintf(this->mem_ctx,
 "FB dual-source write");
@@ -3654,8 +3654,12 @@ fs_visitor::emit_fb_writes()
   reg_undef, 4);
   inst->target = 0;
   prog_data->dual_src_blend = true;
-   } else if (key->nr_color_regions > 0) {
+   } else {
   for (int target = 0; target < key->nr_color_regions; target++) {
+ /* Skip over outputs that weren't written. */
+ if (this->outputs[target].file == BAD_FILE)
+continue;
+
  this->current_annotation = ralloc_asprintf(this->mem_ctx,
 "FB write target %d",
 target);
@@ -3668,7 +3672,9 @@ fs_visitor::emit_fb_writes()
  this->output_components[target]);
  inst->target = target;
   }
-   } else {
+   }
+
+   if (inst == NULL) {
   /* Even if there's no color buffers enabled, we still need to send
* alpha out the pipeline to our null renderbuffer to support
* alpha-testing, alpha-to-coverage, and so on.
-- 
2.2.2

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


[Mesa-dev] [PATCH 2/4] i965/fs: Make get_timestamp() return an fs_inst * rather than emitting.

2015-02-27 Thread Kenneth Graunke
This makes another part of the INTEL_DEBUG=shader_time code emittable
at arbitrary locations, rather than just at the end of the instruction
stream.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
 src/mesa/drivers/dri/i965/brw_fs.h   |  2 +-
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9c6f084..faa6f3f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -680,8 +680,8 @@ fs_visitor::type_size(const struct glsl_type *type)
return 0;
 }
 
-fs_reg
-fs_visitor::get_timestamp()
+fs_inst *
+fs_visitor::timestamp_read()
 {
assert(brw->gen >= 7);
 
@@ -692,7 +692,7 @@ fs_visitor::get_timestamp()
 
fs_reg dst = fs_reg(GRF, alloc.allocate(1), BRW_REGISTER_TYPE_UD, 4);
 
-   fs_inst *mov = emit(MOV(dst, ts));
+   fs_inst *mov = MOV(dst, ts);
/* We want to read the 3 fields we care about even if it's not enabled in
 * the dispatch.
 */
@@ -710,14 +710,15 @@ fs_visitor::get_timestamp()
 */
dst.set_smear(0);
 
-   return dst;
+   return mov;
 }
 
 void
 fs_visitor::emit_shader_time_begin()
 {
current_annotation = "shader time start";
-   shader_start_time = get_timestamp();
+   fs_inst *tm_read = emit(timestamp_read());
+   shader_start_time = tm_read->dst;
 }
 
 void
@@ -753,7 +754,8 @@ fs_visitor::emit_shader_time_end()
   unreachable("fs_visitor::emit_shader_time_end missing code");
}
 
-   fs_reg shader_end_time = get_timestamp();
+   fs_inst *tm_read = emit(timestamp_read());
+   fs_reg shader_end_time = tm_read->dst;
 
/* Check that there weren't any timestamp reset events (assuming these
 * were the only two timestamp reads that happened).
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index be1c8a1..f8044f8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -399,7 +399,7 @@ public:
void resolve_ud_negate(fs_reg *reg);
void resolve_bool_comparison(ir_rvalue *rvalue, fs_reg *reg);
 
-   fs_reg get_timestamp();
+   fs_inst *timestamp_read();
 
struct brw_reg interp_reg(int location, int channel);
void setup_uniform_values(ir_variable *ir);
-- 
2.2.2

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


[Mesa-dev] [Bug 89328] python required to build Mesa release tarballs

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89328

--- Comment #3 from Samuel Iglesias  ---
Created attachment 113857
  --> https://bugs.freedesktop.org/attachment.cgi?id=113857&action=edit
remove mako check when python is not installed

> The distribution tarballs (should) provide all the auto-generated files, 
> similar to any other autotools project. As such one should not need any of 
> python/mako/lex/etc but a plain compiler toolchain.
> 
> Imho we should fix these in a way that, when the files are generated, all the 
> non-compiler requirements are non-fatal.
> 

I wrote a patch (attached) that removes the python mako module check when
python is not installed in the system. If it needs to do something with python,
it is going to fail anyway.

I tested this patch in a virtual machine without python installed to check if I
can compile mesa from a tarball created by 'make dist' command. At least now,
mako doesn't block the configuration step. The build fails at a later time due
to some python files but unrelated to autogenerated format_pack.c and
format_unpack.c files because the latter ones were already generated by make
dist.

If you think this patch is interesting to have in master, just say so and I
will send this patch to the mailing list.

> Although I cannot find a way to do that of the top of my head.

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


Re: [Mesa-dev] [PATCH] include, auxiliary: Remove support for MSVC older then 2008.

2015-02-27 Thread Kenneth Graunke
On Thursday, February 26, 2015 12:09:57 PM Jose Fonseca wrote:
> MSVC 2008 (shipped with Windows SDK 7.0.7600) is the oldest we
> need to support.  At least on llvmpipe, gallium/auxiliary, and util
> modules.  For the remaining modules (particular all OpenGL specific
> code) can be built with MSVC 2013.

Really?  That's fantastic news - thank 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] [PATCH 1/2] nir: Use alloca instead of variable length arrays.

2015-02-27 Thread Kenneth Graunke
On Thursday, February 26, 2015 04:51:21 PM Jose Fonseca wrote:
> This is to enable the code to build with -Werror=vla in the short term,
> and enable the code to build with MSVC2013 soon after.
> ---
>  include/c99_alloca.h | 45 
> 
>  src/glsl/nir/nir_from_ssa.c  | 19 +++
>  src/glsl/nir/nir_live_variables.c|  5 ++--
>  src/glsl/nir/nir_lower_vars_to_ssa.c | 13 +++
>  4 files changed, 66 insertions(+), 16 deletions(-)
>  create mode 100644 include/c99_alloca.h

Thanks, Jose!  We really appreciate this!

Both patches are:
Reviewed-by: Kenneth Graunke 

(I'm fine with the code either as-is, or with Brian's suggestion.)


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 88907] [PNV Bisected]Ogles2conform ES2-CTS.gtf.GL2ExtensionTests.texture_float.texture_float segfault

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=88907

Tapani Pälli  changed:

   What|Removed |Added

 Attachment #113390|0   |1
is obsolete||

--- Comment #7 from Tapani Pälli  ---
Created attachment 113864
  --> https://bugs.freedesktop.org/attachment.cgi?id=113864&action=edit
patch to fix the issue

Updated patch. QA, please test with this patch.

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


Re: [Mesa-dev] [PATCH 2/4] i965/fs: Make get_timestamp() return an fs_inst * rather than emitting.

2015-02-27 Thread Pohjolainen, Topi
On Fri, Feb 27, 2015 at 12:06:00AM -0800, Kenneth Graunke wrote:
> This makes another part of the INTEL_DEBUG=shader_time code emittable
> at arbitrary locations, rather than just at the end of the instruction
> stream.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 14 --
>  src/mesa/drivers/dri/i965/brw_fs.h   |  2 +-
>  2 files changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 9c6f084..faa6f3f 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -680,8 +680,8 @@ fs_visitor::type_size(const struct glsl_type *type)
> return 0;
>  }
>  
> -fs_reg
> -fs_visitor::get_timestamp()
> +fs_inst *
> +fs_visitor::timestamp_read()
>  {
> assert(brw->gen >= 7);
>  
> @@ -692,7 +692,7 @@ fs_visitor::get_timestamp()
>  
> fs_reg dst = fs_reg(GRF, alloc.allocate(1), BRW_REGISTER_TYPE_UD, 4);
>  
> -   fs_inst *mov = emit(MOV(dst, ts));
> +   fs_inst *mov = MOV(dst, ts);
> /* We want to read the 3 fields we care about even if it's not enabled in
>  * the dispatch.
>  */
> @@ -710,14 +710,15 @@ fs_visitor::get_timestamp()
>  */
> dst.set_smear(0);

This is now lost. Callers of timestamp_read() will from now on consult the
destination register of the instruction while this stack copy won't be
consumed by anything.

>  
> -   return dst;
> +   return mov;
>  }
>  
>  void
>  fs_visitor::emit_shader_time_begin()
>  {
> current_annotation = "shader time start";
> -   shader_start_time = get_timestamp();
> +   fs_inst *tm_read = emit(timestamp_read());
> +   shader_start_time = tm_read->dst;
>  }
>  
>  void
> @@ -753,7 +754,8 @@ fs_visitor::emit_shader_time_end()
>unreachable("fs_visitor::emit_shader_time_end missing code");
> }
>  
> -   fs_reg shader_end_time = get_timestamp();
> +   fs_inst *tm_read = emit(timestamp_read());
> +   fs_reg shader_end_time = tm_read->dst;
>  
> /* Check that there weren't any timestamp reset events (assuming these
>  * were the only two timestamp reads that happened).
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index be1c8a1..f8044f8 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -399,7 +399,7 @@ public:
> void resolve_ud_negate(fs_reg *reg);
> void resolve_bool_comparison(ir_rvalue *rvalue, fs_reg *reg);
>  
> -   fs_reg get_timestamp();
> +   fs_inst *timestamp_read();
>  
> struct brw_reg interp_reg(int location, int channel);
> void setup_uniform_values(ir_variable *ir);
> -- 
> 2.2.2
> 
> ___
> 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 1/4] i965: Make emit_shader_time_write return rather than emit.

2015-02-27 Thread Pohjolainen, Topi
On Fri, Feb 27, 2015 at 12:05:59AM -0800, Kenneth Graunke wrote:
> Instead of emit_shader_time_write, we now do emit(SHADER_TIME_ADD(...)).
> The advantage is that we can also insert a shader time write at an
> arbitrary location in the instruction stream, rather than being
> restricted to emitting at the end.
> 
> Signed-off-by: Kenneth Graunke 

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


Re: [Mesa-dev] [PATCH 1/3] clover: Don't unconditionally define cl_khr_fp64

2015-02-27 Thread Francisco Jerez
Tom Stellard  writes:

> This should be done by the frontend for devices that support this
> extension.

Reviewed-by: Francisco Jerez 

> ---
>  src/gallium/state_trackers/clover/llvm/invocation.cpp | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp 
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index 508979a..9354812 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -203,7 +203,6 @@ namespace {
>  
>// clc.h requires that this macro be defined:
>
> c.getPreprocessorOpts().addMacroDef("cl_clang_storage_class_specifiers");
> -  c.getPreprocessorOpts().addMacroDef("cl_khr_fp64");
>  
>c.getLangOpts().NoBuiltin = true;
>c.getTargetOpts().Triple = triple;
> -- 
> 2.0.4


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


Re: [Mesa-dev] [PATCH 3/4] i965/fs: Make emit_shader_time_end() insert before EOT.

2015-02-27 Thread Pohjolainen, Topi
On Fri, Feb 27, 2015 at 12:06:01AM -0800, Kenneth Graunke wrote:
> Previously, we emitted the shader-time epilogue from emit_fb_writes(),
> during the middle of looping through color regions (or emit_urb_writes
> for the VS).  This is duplicated several times and rather awkward.
> 
> I need to fix a bug in our FB write handling, and it will be a lot
> easier if we move emit_shader_time_end() out of there.
> 
> Now, we simply emit FB writes/URB writes, and subsequently have
> emit_shader_time_end() insert instructions before the final SEND with
> EOT.  Not only is this simpler, it's actually a slight improvement:
> we now include the MOVs to set up the final FB write payload in our
> shader-time measurements.
> 
> Note that INTEL_DEBUG=shader_time only exists on Gen7+, and uses
> send-from-GRF.  (In the past, we might have hit trouble where both
> attempt to use MRFs for messages; that's not a problem now.)
> 
> Signed-off-by: Kenneth Graunke 

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


Re: [Mesa-dev] [PATCH 3/3] radeonsi/compute: Enable PIPE_SHADER_CAP_DOUBLES

2015-02-27 Thread Kai Wasserbäch
Should GL_ARB_gpu_shader_fp64 be marked as done for radeonsi in GL3.txt then? Or
is PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED a must as well (I don't think so and
maybe PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED could be enabled as well?).

Cheers,
Kai


Tom Stellard wrote on 27.02.2015 02:06:
> ---
>  src/gallium/drivers/radeonsi/si_pipe.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> b/src/gallium/drivers/radeonsi/si_pipe.c
> index 26182c2..c7a7622 100644
> --- a/src/gallium/drivers/radeonsi/si_pipe.c
> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> @@ -360,8 +360,11 @@ static int si_get_shader_param(struct pipe_screen* 
> pscreen, unsigned shader, enu
>   return PIPE_SHADER_IR_NATIVE;
>  #endif
>   case PIPE_SHADER_CAP_DOUBLES:
> - return 0; /* XXX: Enable doubles once the compiler can
> -  handle them. */
> +#if HAVE_LLVM >= 0x0307
> + return 1;
> +#else
> + return 0;
> +#endif
>   case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE: {
>   uint64_t max_const_buffer_size;
>   pscreen->get_compute_param(pscreen,
> 

-- 

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


Re: [Mesa-dev] Should GL_UN/PACK_IMAGE_HEIGHT affect GL_TEXTURE_1D_ARRAY?

2015-02-27 Thread Neil Roberts
Ian Romanick  writes:

> IMAGE_HEIGHT is definitely used for glGetTexImage because that and
> IMAGE_WIDTH allow you to get a subimage (before ARB_get_texture_sub_image).
>
> I guess on glTexImage2D those could let you initialize a subregion of a
> larger texture... kind of like doing glTexImage2D(..., NULL) followed by
> glTexSubImage2D.  It does seem pretty weird.

No, that's not right. The packing properties are used to describe the
layout of the client-side image, not the texture, so they aren't a
replacement for glGetTexSubImage or glTexSubImage?D. You can use them to
download to or upload from a sub-region of a larger image in your
client-side malloc'd buffer, but not a subregion of the texture.

I don't think there's any question whether the IMAGE_HEIGHT property
should affect glGetTexImage or glTexImage3D in general but the question
I'm asking is specifically whether it should affect 1D array textures.
The IMAGE_HEIGHT property is normally only used to help specify a
subregion of a 3D image. Arguably you could say that a 1D array texture
is like a 3D image with a width and depth but the height fixed at 1,
however GL doesn't seem to treat it like that because you have to use
glTexImage2D to upload it. It seems more like it is treating it as a 2D
image and in that case IMAGE_HEIGHT doesn't make any sense because it is
only used to create padding between the multiple images of a 3D texture.
You can already use the ROW_LENGTH property to describe the padding
between the 1D images of your client-side representation of the 1D
texture.

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


Re: [Mesa-dev] [PATCH 1/2] nir: Use alloca instead of variable length arrays.

2015-02-27 Thread Jose Fonseca

On 26/02/15 18:07, Brian Paul wrote:

On 02/26/2015 09:51 AM, Jose Fonseca wrote:

This is to enable the code to build with -Werror=vla in the short term,
and enable the code to build with MSVC2013 soon after.
---
  include/c99_alloca.h | 45

  src/glsl/nir/nir_from_ssa.c  | 19 +++
  src/glsl/nir/nir_live_variables.c|  5 ++--
  src/glsl/nir/nir_lower_vars_to_ssa.c | 13 +++
  4 files changed, 66 insertions(+), 16 deletions(-)
  create mode 100644 include/c99_alloca.h

diff --git a/include/c99_alloca.h b/include/c99_alloca.h
new file mode 100644
index 000..6d96d06
--- /dev/null
+++ b/include/c99_alloca.h
@@ -0,0 +1,45 @@
+/**

+ *
+ * Copyright 2015 VMware, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+
**/

+
+#ifndef _C99_ALLOCA_H_
+#define _C99_ALLOCA_H_
+
+
+#if defined(_MSC_VER)
+
+#  include 
+
+#  define alloca _alloca
+
+#else /* !defined(_MSC_VER) */
+
+#  include 
+
+#endif /* !defined(_MSC_VER) */
+
+
+#endif
diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
index c695c95..66339f3 100644
--- a/src/glsl/nir/nir_from_ssa.c
+++ b/src/glsl/nir/nir_from_ssa.c
@@ -26,6 +26,7 @@
   */

  #include "nir.h"
+#include "c99_alloca.h"

  /*
   * This file implements an out-of-SSA pass as described in "Revisiting
@@ -181,7 +182,7 @@ merge_merge_sets(merge_set *a, merge_set *b)
  static bool
  merge_sets_interfere(merge_set *a, merge_set *b)
  {
-   merge_node *dom[a->size + b->size];
+   merge_node **dom = alloca((a->size + b->size) * sizeof *dom);
 int dom_idx = -1;

 struct exec_node *an = exec_list_get_head(&a->nodes);
@@ -673,21 +674,21 @@ resolve_parallel_copy(nir_parallel_copy_instr
*pcopy,
 }

 /* The register/source corresponding to the given index */
-   nir_src values[num_copies * 2];
-   memset(values, 0, sizeof values);
+   nir_src *values = alloca(num_copies * 2 * sizeof *values);
+   memset(values, 0, num_copies * 2 * sizeof *values);

 /* The current location of a given piece of data */
-   int loc[num_copies * 2];
+   int *loc = alloca(num_copies * 2 * sizeof *loc);

 /* The piece of data that the given piece of data is to be copied
from */
-   int pred[num_copies * 2];
+   int *pred = alloca(num_copies * 2 * sizeof *pred);

 /* Initialize loc and pred.  We will use -1 for "null" */
-   memset(loc, -1, sizeof loc);
-   memset(pred, -1, sizeof pred);
+   memset(loc, -1, num_copies * 2 * sizeof *loc);
+   memset(pred, -1, num_copies * 2 * sizeof *pred);

 /* The destinations we have yet to properly fill */
-   int to_do[num_copies * 2];
+   int *to_do = alloca(num_copies * 2 * sizeof *to_do);
 int to_do_idx = -1;

 /* Now we set everything up:
@@ -737,7 +738,7 @@ resolve_parallel_copy(nir_parallel_copy_instr *pcopy,
 }

 /* Currently empty destinations we can go ahead and fill */
-   int ready[num_copies * 2];
+   int *ready = alloca(num_copies * 2 * sizeof *ready);
 int ready_idx = -1;

 /* Mark the ones that are ready for copying.  We know an index is a
diff --git a/src/glsl/nir/nir_live_variables.c
b/src/glsl/nir/nir_live_variables.c
index 7402dc0..b57ca3a 100644
--- a/src/glsl/nir/nir_live_variables.c
+++ b/src/glsl/nir/nir_live_variables.c
@@ -26,6 +26,7 @@

  #include "nir.h"
  #include "nir_worklist.h"
+#include "c99_alloca.h"

  /*
   * Basic liveness analysis.  This works only in SSA form.
@@ -130,8 +131,8 @@ static bool
  propagate_across_edge(nir_block *pred, nir_block *succ,
struct live_variables_state *state)
  {
-   BITSET_WORD live[state->bitset_words];
-   memcpy(live, succ->live_in, sizeof live);
+   BITSET_WORD *live = alloca(state->bitset_words * sizeof *

[Mesa-dev] [Bug 89342] main/light.c:159:62: error: 'M_PI' undeclared (first use in this function)

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89342

Brian Paul  changed:

   What|Removed |Added

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

--- Comment #2 from Brian Paul  ---
Fixed with commit 06ed81044fc6b1dee90e67de314f81150746e104

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


[Mesa-dev] [Bug 89345] imports.h:452:58: error: expected declaration specifiers or '...' before 'va_list'

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89345

Brian Paul  changed:

   What|Removed |Added

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

--- Comment #2 from Brian Paul  ---
Fixed with commit 84a1e3d61e6df449571e41426ec64b115fedc7c3

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


[Mesa-dev] [PATCH] tgsi: don't forget interp for BCOLOR inputs

2015-02-27 Thread Rob Clark
From: Rob Clark 

To lower two sided color, tgsi_lowering creates additional BCOLOR inputs
(matching up to the BCOLOR outputs on the vert shader).  These inputs
should copy the interpolation state of their matching COLOR input.

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/tgsi/tgsi_lowering.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_lowering.c 
b/src/gallium/auxiliary/tgsi/tgsi_lowering.c
index dee6c41..4954c11 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_lowering.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_lowering.c
@@ -1152,7 +1152,7 @@ transform_samp(struct tgsi_transform_context *tctx,
  */
 #define TWOSIDE_GROW(n)  (  \
   2 + /* FACE */\
-  ((n) * 2) + /* IN[] BCOLOR[n] */  \
+  ((n) * 3) + /* IN[], BCOLOR[n],  */\
   ((n) * 1) + /* TEMP[] */  \
   ((n) * NINST(3))   /* CMP instr */\
   )
@@ -1172,13 +1172,17 @@ emit_twoside(struct tgsi_transform_context *tctx)
 
/* additional inputs for BCOLOR's */
for (i = 0; i < ctx->two_side_colors; i++) {
+  unsigned in_idx = ctx->two_side_idx[i];
   decl = tgsi_default_full_declaration();
   decl.Declaration.File = TGSI_FILE_INPUT;
   decl.Declaration.Semantic = true;
   decl.Range.First = decl.Range.Last = inbase + i;
   decl.Semantic.Name = TGSI_SEMANTIC_BCOLOR;
-  decl.Semantic.Index =
- info->input_semantic_index[ctx->two_side_idx[i]];
+  decl.Semantic.Index = info->input_semantic_index[in_idx];
+  decl.Declaration.Interpolate = true;
+  decl.Interp.Interpolate = info->input_interpolate[in_idx];
+  decl.Interp.Location = info->input_interpolate_loc[in_idx];
+  decl.Interp.CylindricalWrap = info->input_cylindrical_wrap[in_idx];
   tctx->emit_declaration(tctx, &decl);
}
 
-- 
2.1.0

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


Re: [Mesa-dev] [PATCH] radeonsi: Add additional information to shader dumps

2015-02-27 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Fri, Feb 27, 2015 at 3:30 AM, Tom Stellard  wrote:
> This adds SGPR count, VGPR count, shader size, LDS size, and scratch
> usage to shader dumps.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index e6849ad..c71bdf0 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -2604,17 +2604,23 @@ int si_shader_binary_read(struct si_screen *sscreen,
> bool dump  = r600_can_dump_shader(&sscreen->b,
> shader->selector ? shader->selector->tokens : NULL);
>
> -   if (dump && !binary->disassembled) {
> -   fprintf(stderr, "SI CODE:\n");
> -   for (i = 0; i < binary->code_size; i+=4 ) {
> -   fprintf(stderr, "@0x%x: %02x%02x%02x%02x\n", i, 
> binary->code[i + 3],
> +   si_shader_binary_read_config(sscreen, shader, 0);
> +
> +   if (dump) {
> +   if (!binary->disassembled) {
> +   fprintf(stderr, "SI CODE:\n");
> +   for (i = 0; i < binary->code_size; i+=4 ) {
> +   fprintf(stderr, "@0x%x: %02x%02x%02x%02x\n", 
> i, binary->code[i + 3],
> binary->code[i + 2], binary->code[i + 1],
> binary->code[i]);
> +   }
> }
> +   fprintf(stderr, "SGPRS: %d\nVGPRS: %d\nCode Size: %d 
> bytes\nLDS: %d blocks\n"
> +   "Scratch: %d bytes per wave\n",
> +   shader->num_sgprs, shader->num_vgprs, 
> binary->code_size,
> +   shader->lds_size, shader->scratch_bytes_per_wave);
> }
>
> -   si_shader_binary_read_config(sscreen, shader, 0);
> -
> /* copy new shader */
> code_size = binary->code_size + binary->rodata_size;
> r600_resource_reference(&shader->bo, NULL);
> --
> 1.8.5.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 89328] python required to build Mesa release tarballs

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89328

--- Comment #4 from Emil Velikov  ---
(In reply to Samuel Iglesias from comment #3)
> I wrote a patch (attached) that removes the python mako module check when
> python is not installed in the system. If it needs to do something with
> python, it is going to fail anyway.
> 
True.

> If you think this patch is interesting to have in master, just say so and I
> will send this patch to the mailing list.
> 
Imho the patch looks good. Alternative solution is to have the macro set a
variable that we check in configure (like below), but let see what others think
on the ML.

PYTHON_MAKO_REQUIRED=0.3.4
AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
if test -n "$PYTHON2" -a $foo_mako_found = no; then
AC_MSG_ERROR([Python mako module v$PYTHON_MAKO_MODULE not found])
fi


Thank you Samuel!

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


[Mesa-dev] Crash with Mesa-10.4.4 and NV68

2015-02-27 Thread Arno Willig

Hi,

I experience a crash in the nouveau part of the mesa driver:

src/gallium/drivers/nouveau/nv30/nv30_vbo.c

in function:

void nv30_vbo_validate(struct nv30_context *nv30)


Sometimes, ve->vertex_buffer_index seems to be greater or equal
nv30->num_vtxbuf. If this happens, PUSH_RESRC crashes!
How can this happen??

I tried to break out of the for-loop
for (i = 0; i < vertex->num_elements; i++)
when the problem appears.
If I do this, the driver won't crash anymore, but some screen elements
are missing.
A short while later I get a GPU lockup message:
> kernel: nouveau E[ DRM] GPU lockup - switching to software fbcon


I can reproduce this crash with a Qt5.3 Quick2 application.

Where would be the next point to look into this?

Can anyone help me with this? Does a mmiotrace help?


My system:
- Board: ASRock N68C-GS FX with NV68 GeForce 7025 OnBoard
- Linux 3.18.4, (32 bit)
- Mesa-10.4.4
-

Regards,

Arno



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


[Mesa-dev] [PATCH] identity: Remove.

2015-02-27 Thread Jose Fonseca
It's unmaintained, and most likely broken: I use trace driver every now
and then, and everytime I do I need to fix it up.

It's also unused: identity_screen_create is never called.

Above all, it's dead weight: if identity driver had the infrastructure
for other pass-through drivers (like trace and rbug), then it would make
sense on its own right.  But as it is implemmented, it's just another
driver to (forget) to update whenever there is a gallium interface
change.
---
 configure.ac  |   1 -
 src/gallium/Makefile.am   |   1 -
 src/gallium/SConscript|   1 -
 src/gallium/drivers/identity/Makefile.am  |  11 -
 src/gallium/drivers/identity/Makefile.sources |   8 -
 src/gallium/drivers/identity/SConscript   |  12 -
 src/gallium/drivers/identity/id_context.c | 883 --
 src/gallium/drivers/identity/id_context.h |  52 --
 src/gallium/drivers/identity/id_objects.c | 189 --
 src/gallium/drivers/identity/id_objects.h | 177 --
 src/gallium/drivers/identity/id_public.h  |  37 --
 src/gallium/drivers/identity/id_screen.c  | 286 -
 src/gallium/drivers/identity/id_screen.h  |  48 --
 src/gallium/targets/egl-static/Makefile.am|   1 -
 14 files changed, 1707 deletions(-)
 delete mode 100644 src/gallium/drivers/identity/Makefile.am
 delete mode 100644 src/gallium/drivers/identity/Makefile.sources
 delete mode 100644 src/gallium/drivers/identity/SConscript
 delete mode 100644 src/gallium/drivers/identity/id_context.c
 delete mode 100644 src/gallium/drivers/identity/id_context.h
 delete mode 100644 src/gallium/drivers/identity/id_objects.c
 delete mode 100644 src/gallium/drivers/identity/id_objects.h
 delete mode 100644 src/gallium/drivers/identity/id_public.h
 delete mode 100644 src/gallium/drivers/identity/id_screen.c
 delete mode 100644 src/gallium/drivers/identity/id_screen.h

diff --git a/configure.ac b/configure.ac
index 22dc023..c5abbfd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2378,7 +2378,6 @@ AC_CONFIG_FILES([Makefile
src/gallium/drivers/freedreno/Makefile
src/gallium/drivers/galahad/Makefile
src/gallium/drivers/i915/Makefile
-   src/gallium/drivers/identity/Makefile
src/gallium/drivers/ilo/Makefile
src/gallium/drivers/llvmpipe/Makefile
src/gallium/drivers/noop/Makefile
diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
index 6a2a866..f6bf3c0 100644
--- a/src/gallium/Makefile.am
+++ b/src/gallium/Makefile.am
@@ -12,7 +12,6 @@ SUBDIRS += auxiliary
 
 SUBDIRS += \
drivers/galahad \
-   drivers/identity \
drivers/noop \
drivers/trace \
drivers/rbug
diff --git a/src/gallium/SConscript b/src/gallium/SConscript
index 25d0af6..37767b5 100644
--- a/src/gallium/SConscript
+++ b/src/gallium/SConscript
@@ -13,7 +13,6 @@ SConscript('auxiliary/SConscript')
 # These are common and work across all platforms
 SConscript([
 'drivers/galahad/SConscript',
-'drivers/identity/SConscript',
 'drivers/llvmpipe/SConscript',
 'drivers/rbug/SConscript',
 'drivers/softpipe/SConscript',
diff --git a/src/gallium/drivers/identity/Makefile.am 
b/src/gallium/drivers/identity/Makefile.am
deleted file mode 100644
index 0a49633..000
--- a/src/gallium/drivers/identity/Makefile.am
+++ /dev/null
@@ -1,11 +0,0 @@
-include Makefile.sources
-include $(top_srcdir)/src/gallium/Automake.inc
-
-AM_CFLAGS = \
-   $(GALLIUM_DRIVER_CFLAGS)
-
-noinst_LTLIBRARIES = libidentity.la
-
-libidentity_la_SOURCES = $(C_SOURCES)
-
-EXTRA_DIST = SConscript
diff --git a/src/gallium/drivers/identity/Makefile.sources 
b/src/gallium/drivers/identity/Makefile.sources
deleted file mode 100644
index e3e34a8..000
--- a/src/gallium/drivers/identity/Makefile.sources
+++ /dev/null
@@ -1,8 +0,0 @@
-C_SOURCES := \
-   id_context.c \
-   id_context.h \
-   id_objects.c \
-   id_objects.h \
-   id_public.h \
-   id_screen.c \
-   id_screen.h
diff --git a/src/gallium/drivers/identity/SConscript 
b/src/gallium/drivers/identity/SConscript
deleted file mode 100644
index 1209951..000
--- a/src/gallium/drivers/identity/SConscript
+++ /dev/null
@@ -1,12 +0,0 @@
-Import('*')
-
-env = env.Clone()
-
-identity = env.ConvenienceLibrary(
-   target = 'identity',
-   source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
-   )
-
-env.Alias('identity', identity)
-
-Export('identity')
diff --git a/src/gallium/drivers/identity/id_context.c 
b/src/gallium/drivers/identity/id_context.c
deleted file mode 100644
index 97b3967..000
--- a/src/gallium/drivers/identity/id_context.c
+++ /dev/null
@@ -1,883 +0,0 @@
-/**
- *
- * Copyright 2009 VMware, Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person ob

[Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Jose Fonseca
As we're gaining momentum cleanup Mesa code, I think it would help if we 
also removed some stale components.


What do people feel about removing:

- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I 
haven't used in a very long time, and given that the old SW rasterizer 
is so far behind compared gallium based softpipe/llvmpipe rasterizers, 
it's hard to imagine this will ever be useful again


- src/gallium/drivers/rbug: -- do people use it? does it work?  it 
predates apitrace GL + GUI, which sort of enables a lot of the same 
things, but without the issue of having to hit moving target, which is 
what gallium interfaces are


- src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems 
to have dwindled away. I recall Zack himself saying that much. The code 
would still be interesting if we wanted to implement NV_path_rendering 
[1], but given the trend of the next gen graphics APIs, it seems 
unlikely that this becomes ARB or core.


- src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but 
since then I discovered WGL/GLX_EXT_create_context_es_profile, and the 
odds of us (VMware) needing this again are dimmer than last time, so I 
have to admit it does seem unlikely we or anybody will need it again, 
and we can always revert it from history..



Anything else?


Jose


[1] http://zrusin.blogspot.co.uk/2011/09/nv-path-rendering.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [RFC] configure.ac: Don't check for python mako module if python is not installed

2015-02-27 Thread Samuel Iglesias Gonsalvez
This could be the case of trying to compile a Mesa tarball (from 'make dist'
command) in a machine without Python interpreter installed. The autogenerated
files from mako templates were already created during tarball
generation.

In case of building from git without Python it is going to fail anyway because
Python is not present when trying to autogenerate the files from mako
templates.

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

Signed-off-by: Samuel Iglesias Gonsalvez 
---
 configure.ac | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 22dc023..a4e6338 100644
--- a/configure.ac
+++ b/configure.ac
@@ -114,7 +114,12 @@ if test "x$INDENT" != "xcat"; then
 fi
 fi
 
-AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
+if test -n "$PYTHON2"; then
+AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
+else
+AC_MSG_WARN([python not found - unable to check for python mako module])
+fi
+
 
 AC_PROG_INSTALL
 
-- 
2.1.4

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


[Mesa-dev] [RFC 0/1] configure.ac: Don't check for python mako module if python is not installed

2015-02-27 Thread Samuel Iglesias Gonsalvez
Hello,

Bug 89328 [0] shows that Mesa releases will not build without python.
If there is no python installed in the system, the build's
configuration step is going to fail due to python mako module check.

The idea behind this patch is to disable the python mako module check
when python is not installed in the system: if it needs to do something
with python, it is going to fail anyway.

Emil suggested another way of doing the same: the macro will set a
variable that we check in configure. Something like:

   PYTHON_MAKO_REQUIRED=0.3.4
   AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
   if test -n "$PYTHON2" -a $foo_mako_found = no; then
   AC_MSG_ERROR([Python mako module v$PYTHON_MAKO_MODULE not found])
   fi

Which one do you prefer? Is there a better solution for this?

Thanks,

Sam

[0] https://bugs.freedesktop.org/show_bug.cgi?id=89328

Samuel Iglesias Gonsalvez (1):
  configure.ac: Don't check for python mako module if python is not
installed

 configure.ac | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.1.4

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


[Mesa-dev] [PATCH 04/13] i965: Mask out unused Align16 components in brw_untyped_atomic.

2015-02-27 Thread Francisco Jerez
This is currently not a problem because the vec4 visitor happens to
mask out unused components from the destination, but it might become
an issue when we start using atomics without writeback message.  In
any case it seems sensible to set it again here because the
consequences of setting the wrong writemask (random graphics memory
corruption) are difficult to debug and can easily go unnoticed.
---
 src/mesa/drivers/dri/i965/brw_eu_emit.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 2b1d6ff..0b655d4 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2799,16 +2799,25 @@ brw_untyped_atomic(struct brw_compile *p,
bool response_expected)
 {
const struct brw_context *brw = p->brw;
+   const bool align1 = (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1);
+   /* Mask out unused components -- This is especially important in Align16
+* mode on generations that don't have native support for SIMD4x2 atomics,
+* because unused but enabled components will cause the dataport to perform
+* additional atomic operations on the addresses that happen to be in the
+* uninitialized Y, Z and W coordinates of the payload.
+*/
+   const unsigned mask = (align1 ? WRITEMASK_XYZW : WRITEMASK_X);
brw_inst *insn = brw_next_insn(p, BRW_OPCODE_SEND);
 
-   brw_set_dest(p, insn, retype(dest, BRW_REGISTER_TYPE_UD));
+   brw_set_dest(p, insn, retype(brw_writemask(dest, mask),
+BRW_REGISTER_TYPE_UD));
brw_set_src0(p, insn, retype(payload, BRW_REGISTER_TYPE_UD));
brw_set_src1(p, insn, brw_imm_d(0));
brw_set_dp_untyped_atomic_message(
   p, insn, atomic_op, bind_table_index, msg_length,
   brw_surface_payload_size(p, response_expected,
brw->gen >= 8 || brw->is_haswell, true),
-  brw_inst_access_mode(brw, insn) == BRW_ALIGN_1);
+  align1);
 }
 
 static void
-- 
2.1.3

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


[Mesa-dev] [PATCH 07/13] i965: Don't request untyped atomic writeback message if the destination is null.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 4e695f5..48eee18 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1887,7 +1887,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  assert(src[1].file == BRW_IMMEDIATE_VALUE &&
 src[2].file == BRW_IMMEDIATE_VALUE);
  brw_untyped_atomic(p, dst, src[0], src[2], src[1].dw1.ud,
-inst->mlen, true);
+inst->mlen, !inst->dst.is_null());
  brw_mark_surface_used(prog_data, src[2].dw1.ud);
  break;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 131fd4f..22fdd63 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -1462,7 +1462,8 @@ vec4_generator::generate_code(const cfg_t *cfg)
  assert(src[0].file == BRW_IMMEDIATE_VALUE &&
 src[1].file == BRW_IMMEDIATE_VALUE);
  brw_untyped_atomic(p, dst, brw_message_reg(inst->base_mrf),
-src[1], src[0].dw1.ud, inst->mlen, true);
+src[1], src[0].dw1.ud, inst->mlen,
+!inst->dst.is_null());
  brw_mark_surface_used(&prog_data->base, src[1].dw1.ud);
  break;
 
-- 
2.1.3

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


[Mesa-dev] [PATCH 05/13] i965: Fix the untyped surface opcodes to deal with indirect surface access.

2015-02-27 Thread Francisco Jerez
Change brw_untyped_atomic() and brw_untyped_surface_read() to take the
surface index as a register instead of a constant and to use
brw_send_indirect_message() to emit the indirect variant of send with
a dynamically calculated message descriptor.  This will be required to
support variable indexing of image arrays for
ARB_shader_image_load_store.
---
 src/mesa/drivers/dri/i965/brw_eu.h   |  10 +-
 src/mesa/drivers/dri/i965/brw_eu_emit.c  | 158 +--
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   |   4 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |   4 +-
 4 files changed, 96 insertions(+), 80 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 87a9f3f..9cc9123 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -398,18 +398,18 @@ void brw_CMP(struct brw_compile *p,
 
 void
 brw_untyped_atomic(struct brw_compile *p,
-   struct brw_reg dest,
+   struct brw_reg dst,
struct brw_reg payload,
+   struct brw_reg surface,
unsigned atomic_op,
-   unsigned bind_table_index,
unsigned msg_length,
bool response_expected);
 
 void
 brw_untyped_surface_read(struct brw_compile *p,
- struct brw_reg dest,
- struct brw_reg mrf,
- unsigned bind_table_index,
+ struct brw_reg dst,
+ struct brw_reg payload,
+ struct brw_reg surface,
  unsigned msg_length,
  unsigned num_channels);
 
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 0b655d4..34695bf 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2518,6 +2518,48 @@ brw_send_indirect_message(struct brw_compile *p,
return setup;
 }
 
+static struct brw_inst *
+brw_send_indirect_surface_message(struct brw_compile *p,
+  unsigned sfid,
+  struct brw_reg dst,
+  struct brw_reg payload,
+  struct brw_reg surface,
+  unsigned message_len,
+  unsigned response_len,
+  bool header_present)
+{
+   const struct brw_context *brw = p->brw;
+   struct brw_inst *insn;
+
+   if (surface.file != BRW_IMMEDIATE_VALUE) {
+  struct brw_reg addr = retype(brw_address_reg(0), BRW_REGISTER_TYPE_UD);
+
+  brw_push_insn_state(p);
+  brw_set_default_access_mode(p, BRW_ALIGN_1);
+  brw_set_default_mask_control(p, BRW_MASK_DISABLE);
+  brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
+
+  /* Mask out invalid bits from the surface index to avoid hangs e.g. when
+   * some surface array is accessed out of bounds.
+   */
+  insn = brw_AND(p, addr,
+ suboffset(vec1(retype(surface, BRW_REGISTER_TYPE_UD)),
+   BRW_GET_SWZ(surface.dw1.bits.swizzle, 0)),
+ brw_imm_ud(0xff));
+
+  brw_pop_insn_state(p);
+
+  surface = addr;
+   }
+
+   insn = brw_send_indirect_message(p, sfid, dst, payload, surface);
+   brw_inst_set_mlen(brw, insn, message_len);
+   brw_inst_set_rlen(brw, insn, response_len);
+   brw_inst_set_header_present(brw, insn, header_present);
+
+   return insn;
+}
+
 static int
 brw_find_next_block_end(struct brw_compile *p, int start_offset)
 {
@@ -2747,25 +2789,16 @@ static void
 brw_set_dp_untyped_atomic_message(struct brw_compile *p,
   brw_inst *insn,
   unsigned atomic_op,
-  unsigned bind_table_index,
-  unsigned msg_length,
-  unsigned response_length,
-  bool header_present)
+  bool response_expected)
 {
const struct brw_context *brw = p->brw;
-
unsigned msg_control =
   atomic_op | /* Atomic Operation Type: BRW_AOP_* */
-  (response_length ? 1 << 5 : 0); /* Return data expected */
+  (response_expected ? 1 << 5 : 0); /* Return data expected */
 
if (brw->gen >= 8 || brw->is_haswell) {
-  brw_set_message_descriptor(p, insn, HSW_SFID_DATAPORT_DATA_CACHE_1,
- msg_length, response_length,
- header_present, false);
-
-
-  if (brw_inst_access_mode(brw, insn) == BRW_ALIGN_1) {
- if (brw_inst_exec_size(brw, insn) != BRW_EXECUTE_16)
+  if (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1) {
+ if (!p->compressed)
 msg_control |= 1 << 4; /* SIM

[Mesa-dev] [PATCH 13/13] i965: Add memory fence opcode.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_defines.h  |  2 +
 src/mesa/drivers/dri/i965/brw_eu.h   |  4 ++
 src/mesa/drivers/dri/i965/brw_eu_emit.c  | 70 
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   |  4 ++
 src/mesa/drivers/dri/i965/brw_shader.cpp |  3 +
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  4 ++
 6 files changed, 87 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index cf07da9..1ef9c2c 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -910,6 +910,8 @@ enum opcode {
SHADER_OPCODE_TYPED_SURFACE_READ,
SHADER_OPCODE_TYPED_SURFACE_WRITE,
 
+   SHADER_OPCODE_MEMORY_FENCE,
+
SHADER_OPCODE_GEN4_SCRATCH_READ,
SHADER_OPCODE_GEN4_SCRATCH_WRITE,
SHADER_OPCODE_GEN7_SCRATCH_READ,
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index ce9554b..84f74a3 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -445,6 +445,10 @@ brw_typed_surface_write(struct brw_compile *p,
 unsigned num_channels);
 
 void
+brw_memory_fence(struct brw_compile *p,
+ struct brw_reg dst);
+
+void
 brw_pixel_interpolator_query(struct brw_compile *p,
  struct brw_reg dest,
  struct brw_reg mrf,
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 74f1fc1..0b56a62 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -3113,6 +3113,76 @@ brw_typed_surface_write(struct brw_compile *p,
   p, insn, num_channels);
 }
 
+static void
+brw_set_memory_fence_message(struct brw_compile *p,
+ struct brw_inst *insn,
+ enum brw_message_target sfid,
+ bool commit_enable)
+{
+   const struct brw_context *brw = p->brw;
+
+   brw_set_message_descriptor(p, insn, sfid,
+  1 /* message length */,
+  (commit_enable ? 1 : 0) /* response length */,
+  true /* header present */,
+  false);
+
+   switch (sfid) {
+   case GEN6_SFID_DATAPORT_RENDER_CACHE:
+  brw_inst_set_dp_msg_type(brw, insn, GEN7_DATAPORT_RC_MEMORY_FENCE);
+  break;
+   case GEN7_SFID_DATAPORT_DATA_CACHE:
+  brw_inst_set_dp_msg_type(brw, insn, GEN7_DATAPORT_DC_MEMORY_FENCE);
+  break;
+   default:
+  unreachable("Not reached");
+   }
+
+   if (commit_enable)
+  brw_inst_set_dp_msg_control(brw, insn, 1 << 5);
+}
+
+void
+brw_memory_fence(struct brw_compile *p,
+ struct brw_reg dst)
+{
+   const struct brw_context *brw = p->brw;
+   const bool commit_enable = (brw->gen == 7 && !brw->is_haswell);
+   struct brw_inst *insn;
+
+   /* Set dst as destination for dependency tracking, the MEMORY_FENCE
+* message doesn't write anything back.
+*/
+   insn = next_insn(p, BRW_OPCODE_SEND);
+   brw_set_dest(p, insn, dst);
+   brw_set_src0(p, insn, dst);
+   brw_set_memory_fence_message(p, insn, GEN7_SFID_DATAPORT_DATA_CACHE,
+commit_enable);
+
+   if (brw->gen == 7 && !brw->is_haswell) {
+  /* IVB does typed surface access through the render cache, so we need to
+   * flush it too.  Use a different register so both flushes can be
+   * pipelined by the hardware.
+   */
+  insn = next_insn(p, BRW_OPCODE_SEND);
+  brw_set_dest(p, insn, offset(dst, 1));
+  brw_set_src0(p, insn, offset(dst, 1));
+  brw_set_memory_fence_message(p, insn, GEN6_SFID_DATAPORT_RENDER_CACHE,
+   commit_enable);
+
+  /* Now write the response of the second message into the response of the
+   * first to trigger a pipeline stall -- This way future render and data
+   * cache messages will be properly ordered with respect to past data and
+   * render cache messages.
+   */
+  brw_push_insn_state(p);
+  brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
+  brw_set_default_mask_control(p, BRW_MASK_DISABLE);
+  brw_MOV(p, dst, offset(dst, 1));
+  brw_pop_insn_state(p);
+   }
+}
+
 void
 brw_pixel_interpolator_query(struct brw_compile *p,
  struct brw_reg dest,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index e80866b..b72a929 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1922,6 +1922,10 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  brw_typed_surface_write(p, src[0], src[1], inst->mlen, src[2].dw1.ud);
  break;
 
+  case SHADER_OPCODE_MEMORY_FENCE:
+ brw_memory_fence(p, dst);
+   

[Mesa-dev] [PATCH 09/13] i965: Pass the number of components as a source of the untyped surface read opcode.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 5 +++--
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 6 --
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp   | 3 ++-
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 48eee18..bd07008 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1892,9 +1892,10 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
- assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE &&
+src[2].file == BRW_IMMEDIATE_VALUE);
  brw_untyped_surface_read(p, dst, src[0], src[1],
-  inst->mlen, 1);
+  inst->mlen, src[2].dw1.ud);
  brw_mark_surface_used(prog_data, src[1].dw1.ud);
  break;
 
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 2d5bef8..6c401f4 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3208,7 +3208,7 @@ fs_visitor::emit_untyped_surface_read(unsigned 
surf_index, fs_reg dst,
 
/* Emit the instruction. */
inst = emit(SHADER_OPCODE_UNTYPED_SURFACE_READ, dst, src_payload,
-   fs_reg(surf_index));
+   fs_reg(surf_index), fs_reg(1));
inst->mlen = mlen;
 }
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index ef0cde9..c97a5ba 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -1467,8 +1467,10 @@ vec4_generator::generate_code(const cfg_t *cfg)
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
- assert(src[1].file == BRW_IMMEDIATE_VALUE);
- brw_untyped_surface_read(p, dst, src[0], src[1], inst->mlen, 1);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE &&
+src[2].file == BRW_IMMEDIATE_VALUE);
+ brw_untyped_surface_read(p, dst, src[0], src[1], inst->mlen,
+  src[2].dw1.ud);
  brw_mark_surface_used(&prog_data->base, src[1].dw1.ud);
  break;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index b8cfe8f..ebd02c6 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2971,7 +2971,8 @@ vec4_visitor::emit_untyped_surface_read(unsigned 
surf_index, dst_reg dst,
 * channels will be masked out.
 */
vec4_instruction *inst = emit(SHADER_OPCODE_UNTYPED_SURFACE_READ, dst,
- brw_message_reg(0), src_reg(surf_index));
+ brw_message_reg(0),
+ src_reg(surf_index), src_reg(1));
inst->base_mrf = 0;
inst->mlen = 1;
 }
-- 
2.1.3

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


[Mesa-dev] [PATCH 10/13] i965: Reorder sources of the untyped atomic opcode.

2015-02-27 Thread Francisco Jerez
This is consistent with the untyped surface read opcode.  From now on
all typed and untyped surface access opcodes will follow the same
pattern: src[0] will be the message payload, src[1] will be the
surface index and src[2] will be a control immediate (atomic operation
for atomic opcodes and number of vector components for surface read
and write opcodes).
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 4 ++--
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 4 ++--
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp   | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index bd07008..a0aa64e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1886,9 +1886,9 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
   case SHADER_OPCODE_UNTYPED_ATOMIC:
  assert(src[1].file == BRW_IMMEDIATE_VALUE &&
 src[2].file == BRW_IMMEDIATE_VALUE);
- brw_untyped_atomic(p, dst, src[0], src[2], src[1].dw1.ud,
+ brw_untyped_atomic(p, dst, src[0], src[1], src[2].dw1.ud,
 inst->mlen, !inst->dst.is_null());
- brw_mark_surface_used(prog_data, src[2].dw1.ud);
+ brw_mark_surface_used(prog_data, src[1].dw1.ud);
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 6c401f4..c5b61b7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -3160,7 +3160,7 @@ fs_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
 
/* Emit the instruction. */
fs_inst *inst = emit(SHADER_OPCODE_UNTYPED_ATOMIC, dst, src_payload,
-fs_reg(atomic_op), fs_reg(surf_index));
+fs_reg(surf_index), fs_reg(atomic_op));
inst->mlen = mlen;
 }
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index c97a5ba..5c350fe 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -1461,9 +1461,9 @@ vec4_generator::generate_code(const cfg_t *cfg)
   case SHADER_OPCODE_UNTYPED_ATOMIC:
  assert(src[1].file == BRW_IMMEDIATE_VALUE &&
 src[2].file == BRW_IMMEDIATE_VALUE);
- brw_untyped_atomic(p, dst, src[0], src[2], src[1].dw1.ud, inst->mlen,
+ brw_untyped_atomic(p, dst, src[0], src[1], src[2].dw1.ud, inst->mlen,
 !inst->dst.is_null());
- brw_mark_surface_used(&prog_data->base, src[2].dw1.ud);
+ brw_mark_surface_used(&prog_data->base, src[1].dw1.ud);
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index ebd02c6..4afe2c0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2954,7 +2954,7 @@ vec4_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
 */
vec4_instruction *inst = emit(SHADER_OPCODE_UNTYPED_ATOMIC, dst,
  brw_message_reg(0),
- src_reg(atomic_op), src_reg(surf_index));
+ src_reg(surf_index), src_reg(atomic_op));
inst->base_mrf = 0;
inst->mlen = mlen;
 }
-- 
2.1.3

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


[Mesa-dev] [PATCH 08/13] i965/vec4: Add support for untyped surface message sends from GRF.

2015-02-27 Thread Francisco Jerez
This doesn't actually enable untyped surface message sends from GRF
yet, the upcoming atomic counter and image intrinsic lowering code
will.
---
 src/mesa/drivers/dri/i965/brw_vec4.cpp   |  7 ---
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 16 +++-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp   |  5 +++--
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index e19..0004b10 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -256,6 +256,8 @@ vec4_instruction::is_send_from_grf()
switch (opcode) {
case SHADER_OPCODE_SHADER_TIME_ADD:
case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
+   case SHADER_OPCODE_UNTYPED_ATOMIC:
+   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
   return true;
default:
   return false;
@@ -270,6 +272,8 @@ vec4_instruction::regs_read(unsigned arg) const
 
switch (opcode) {
case SHADER_OPCODE_SHADER_TIME_ADD:
+   case SHADER_OPCODE_UNTYPED_ATOMIC:
+   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
   return arg == 0 ? mlen : 1;
 
case VS_OPCODE_PULL_CONSTANT_LOAD_GEN7:
@@ -347,9 +351,6 @@ vec4_visitor::implied_mrf_writes(vec4_instruction *inst)
case SHADER_OPCODE_TG4:
case SHADER_OPCODE_TG4_OFFSET:
   return inst->header_present ? 1 : 0;
-   case SHADER_OPCODE_UNTYPED_ATOMIC:
-   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
-  return 0;
default:
   unreachable("not reached");
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 22fdd63..ef0cde9 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -1459,19 +1459,17 @@ vec4_generator::generate_code(const cfg_t *cfg)
  break;
 
   case SHADER_OPCODE_UNTYPED_ATOMIC:
- assert(src[0].file == BRW_IMMEDIATE_VALUE &&
-src[1].file == BRW_IMMEDIATE_VALUE);
- brw_untyped_atomic(p, dst, brw_message_reg(inst->base_mrf),
-src[1], src[0].dw1.ud, inst->mlen,
+ assert(src[1].file == BRW_IMMEDIATE_VALUE &&
+src[2].file == BRW_IMMEDIATE_VALUE);
+ brw_untyped_atomic(p, dst, src[0], src[2], src[1].dw1.ud, inst->mlen,
 !inst->dst.is_null());
- brw_mark_surface_used(&prog_data->base, src[1].dw1.ud);
+ brw_mark_surface_used(&prog_data->base, src[2].dw1.ud);
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
- assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_untyped_surface_read(p, dst, brw_message_reg(inst->base_mrf),
-  src[0], inst->mlen, 1);
- brw_mark_surface_used(&prog_data->base, src[0].dw1.ud);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ brw_untyped_surface_read(p, dst, src[0], src[1], inst->mlen, 1);
+ brw_mark_surface_used(&prog_data->base, src[1].dw1.ud);
  break;
 
   case SHADER_OPCODE_FIND_LIVE_CHANNEL:
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index f25bff9..b8cfe8f 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -2953,6 +2953,7 @@ vec4_visitor::emit_untyped_atomic(unsigned atomic_op, 
unsigned surf_index,
 * unused channels will be masked out.
 */
vec4_instruction *inst = emit(SHADER_OPCODE_UNTYPED_ATOMIC, dst,
+ brw_message_reg(0),
  src_reg(atomic_op), src_reg(surf_index));
inst->base_mrf = 0;
inst->mlen = mlen;
@@ -2969,8 +2970,8 @@ vec4_visitor::emit_untyped_surface_read(unsigned 
surf_index, dst_reg dst,
 * untyped surface read message, but that's OK because unused
 * channels will be masked out.
 */
-   vec4_instruction *inst = emit(SHADER_OPCODE_UNTYPED_SURFACE_READ,
- dst, src_reg(surf_index));
+   vec4_instruction *inst = emit(SHADER_OPCODE_UNTYPED_SURFACE_READ, dst,
+ brw_message_reg(0), src_reg(surf_index));
inst->base_mrf = 0;
inst->mlen = 1;
 }
-- 
2.1.3

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


[Mesa-dev] [PATCH 03/13] i965: Pass number of components explicitly to brw_untyped_atomic and _surface_read.

2015-02-27 Thread Francisco Jerez
And calculate the message response size based on the number of
components rather than the other way around.  This simplifies their
interface somewhat and allows the caller to request a writeback
message with more than one vector component in SIMD4x2 mode.
---
 src/mesa/drivers/dri/i965/brw_eu.h   |  4 ++--
 src/mesa/drivers/dri/i965/brw_eu_emit.c  | 30 +++-
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   |  9 ---
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  5 ++--
 4 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 9b1e0e2..87a9f3f 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -403,7 +403,7 @@ brw_untyped_atomic(struct brw_compile *p,
unsigned atomic_op,
unsigned bind_table_index,
unsigned msg_length,
-   unsigned response_length);
+   bool response_expected);
 
 void
 brw_untyped_surface_read(struct brw_compile *p,
@@ -411,7 +411,7 @@ brw_untyped_surface_read(struct brw_compile *p,
  struct brw_reg mrf,
  unsigned bind_table_index,
  unsigned msg_length,
- unsigned response_length);
+ unsigned num_channels);
 
 void
 brw_pixel_interpolator_query(struct brw_compile *p,
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index cd2ce92..2b1d6ff 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2729,6 +2729,20 @@ brw_svb_write(struct brw_compile *p,
 send_commit_msg); /* send_commit_msg */
 }
 
+static unsigned
+brw_surface_payload_size(struct brw_compile *p,
+ unsigned num_channels,
+ bool has_simd4x2,
+ bool has_simd16)
+{
+   if (has_simd4x2 && brw_inst_access_mode(p->brw, p->current) == BRW_ALIGN_16)
+  return 1;
+   else if (has_simd16 && p->compressed)
+  return 2 * num_channels;
+   else
+  return num_channels;
+}
+
 static void
 brw_set_dp_untyped_atomic_message(struct brw_compile *p,
   brw_inst *insn,
@@ -2782,7 +2796,8 @@ brw_untyped_atomic(struct brw_compile *p,
unsigned atomic_op,
unsigned bind_table_index,
unsigned msg_length,
-   unsigned response_length) {
+   bool response_expected)
+{
const struct brw_context *brw = p->brw;
brw_inst *insn = brw_next_insn(p, BRW_OPCODE_SEND);
 
@@ -2790,7 +2805,9 @@ brw_untyped_atomic(struct brw_compile *p,
brw_set_src0(p, insn, retype(payload, BRW_REGISTER_TYPE_UD));
brw_set_src1(p, insn, brw_imm_d(0));
brw_set_dp_untyped_atomic_message(
-  p, insn, atomic_op, bind_table_index, msg_length, response_length,
+  p, insn, atomic_op, bind_table_index, msg_length,
+  brw_surface_payload_size(p, response_expected,
+   brw->gen >= 8 || brw->is_haswell, true),
   brw_inst_access_mode(brw, insn) == BRW_ALIGN_1);
 }
 
@@ -2800,12 +2817,12 @@ brw_set_dp_untyped_surface_read_message(struct 
brw_compile *p,
 unsigned bind_table_index,
 unsigned msg_length,
 unsigned response_length,
+unsigned num_channels,
 bool header_present)
 {
const struct brw_context *brw = p->brw;
const unsigned dispatch_width =
   (brw_inst_exec_size(brw, insn) == BRW_EXECUTE_16 ? 16 : 8);
-   const unsigned num_channels = response_length / (dispatch_width / 8);
 
if (brw->gen >= 8 || brw->is_haswell) {
   brw_set_message_descriptor(p, insn, HSW_SFID_DATAPORT_DATA_CACHE_1,
@@ -2843,7 +2860,7 @@ brw_untyped_surface_read(struct brw_compile *p,
  struct brw_reg mrf,
  unsigned bind_table_index,
  unsigned msg_length,
- unsigned response_length)
+ unsigned num_channels)
 {
const struct brw_context *brw = p->brw;
brw_inst *insn = next_insn(p, BRW_OPCODE_SEND);
@@ -2851,8 +2868,9 @@ brw_untyped_surface_read(struct brw_compile *p,
brw_set_dest(p, insn, retype(dest, BRW_REGISTER_TYPE_UD));
brw_set_src0(p, insn, retype(mrf, BRW_REGISTER_TYPE_UD));
brw_set_dp_untyped_surface_read_message(
-  p, insn, bind_table_index, msg_length, response_length,
-  brw_inst_access_mode(brw, insn) == BRW_ALIGN_1);
+  p, insn, bind_table_index, msg_length,
+  brw_surface_payload_size(p, num_channels, true, true),
+  num_channels, brw_inst_access_mode(brw, insn) == BR

[Mesa-dev] [PATCH 02/13] i965: Don't disable exec masking for sampler message sends.

2015-02-27 Thread Francisco Jerez
This was telling the sampler to do texture fetches for *all* channels
in the non-constant surface index case, what could have reduced
throughput unnecessarily when some of the channels were disabled by
control flow.
---
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 12 ++--
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp |  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index a54a274..63c59a5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -754,6 +754,8 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
   brw_AND(p, addr, addr, brw_imm_ud(0x0ff));
   brw_OR(p, addr, addr, temp);
 
+  brw_pop_insn_state(p);
+
   /* dst = send(offset, a0.0 | ) */
   brw_inst *insn = brw_send_indirect_message(
  p, BRW_SFID_SAMPLER, dst, src, addr);
@@ -767,8 +769,6 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
   simd_mode,
   return_format);
 
-  brw_pop_insn_state(p);
-
   /* visitor knows more than we do about the surface limit required,
* so has already done marking.
*/
@@ -1039,6 +1039,8 @@ 
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
   brw_set_src0(p, insn_and, vec1(retype(index, BRW_REGISTER_TYPE_UD)));
   brw_set_src1(p, insn_and, brw_imm_ud(0x0ff));
 
+  brw_pop_insn_state(p);
+
   /* dst = send(payload, a0.0 | ) */
   brw_inst *insn = brw_send_indirect_message(
  p, GEN6_SFID_DATAPORT_CONSTANT_CACHE, vec16(dst), payload, addr);
@@ -1051,8 +1053,6 @@ 
fs_generator::generate_uniform_pull_constant_load_gen7(fs_inst *inst,
   true, /* header */
   2); /* rlen */
 
-  brw_pop_insn_state(p);
-
   /* visitor knows more than we do about the surface limit required,
* so has already done marking.
*/
@@ -1186,6 +1186,8 @@ 
fs_generator::generate_varying_pull_constant_load_gen7(fs_inst *inst,
   brw_set_src0(p, insn_and, vec1(retype(index, BRW_REGISTER_TYPE_UD)));
   brw_set_src1(p, insn_and, brw_imm_ud(0x0ff));
 
+  brw_pop_insn_state(p);
+
   /* dst = send(offset, a0.0 | ) */
   brw_inst *insn = brw_send_indirect_message(
  p, BRW_SFID_SAMPLER, dst, offset, addr);
@@ -1199,8 +1201,6 @@ 
fs_generator::generate_varying_pull_constant_load_gen7(fs_inst *inst,
   simd_mode,
   0);
 
-  brw_pop_insn_state(p);
-
   /* visitor knows more than we do about the surface limit required,
* so has already done marking.
*/
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 4d67100..c7494e5 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
@@ -419,6 +419,8 @@ vec4_generator::generate_tex(vec4_instruction *inst,
   brw_AND(p, addr, addr, brw_imm_ud(0x0ff));
   brw_OR(p, addr, addr, temp);
 
+  brw_pop_insn_state(p);
+
   /* dst = send(offset, a0.0 | ) */
   brw_inst *insn = brw_send_indirect_message(
  p, BRW_SFID_SAMPLER, dst, src, addr);
@@ -432,8 +434,6 @@ vec4_generator::generate_tex(vec4_instruction *inst,
   BRW_SAMPLER_SIMD_MODE_SIMD4X2,
   return_format);
 
-  brw_pop_insn_state(p);
-
   /* visitor knows more than we do about the surface limit required,
* so has already done marking.
*/
@@ -1083,6 +1083,8 @@ 
vec4_generator::generate_pull_constant_load_gen7(vec4_instruction *inst,
   brw_set_src0(p, insn_and, vec1(retype(surf_index, 
BRW_REGISTER_TYPE_UD)));
   brw_set_src1(p, insn_and, brw_imm_ud(0x0ff));
 
+  brw_pop_insn_state(p);
+
   /* dst = send(offset, a0.0 | ) */
   brw_inst *insn = brw_send_indirect_message(
  p, BRW_SFID_SAMPLER, dst, offset, addr);
@@ -1096,8 +1098,6 @@ 
vec4_generator::generate_pull_constant_load_gen7(vec4_instruction *inst,
   BRW_SAMPLER_SIMD_MODE_SIMD4X2,
   0);
 
-  brw_pop_insn_state(p);
-
   /* visitor knows more than we do about the surface limit required,
* so has already done marking.
*/
-- 
2.1.3

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


[Mesa-dev] [PATCH 06/13] i965: Simplify generator code for untyped surface messages.

2015-02-27 Thread Francisco Jerez
The generate_untyped_*() methods do nothing useful other than calling
the corresponding function from brw_eu_emit.c.  The calls to
brw_mark_surface_used() will go away too in a future commit.
---
 src/mesa/drivers/dri/i965/brw_fs.h   | 11 --
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 42 +--
 src/mesa/drivers/dri/i965/brw_vec4.h |  9 -
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 43 +---
 4 files changed, 18 insertions(+), 87 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index 34a8f79..4a77ac6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -609,17 +609,6 @@ private:
  struct brw_reg offset,
  struct brw_reg value);
 
-   void generate_untyped_atomic(fs_inst *inst,
-struct brw_reg dst,
-struct brw_reg payload,
-struct brw_reg atomic_op,
-struct brw_reg surf_index);
-
-   void generate_untyped_surface_read(fs_inst *inst,
-  struct brw_reg dst,
-  struct brw_reg payload,
-  struct brw_reg surf_index);
-
bool patch_discard_jumps_to_fb_writes();
 
struct brw_context *brw;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index f739837..4e695f5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1418,37 +1418,6 @@ fs_generator::generate_shader_time_add(fs_inst *inst,
 }
 
 void
-fs_generator::generate_untyped_atomic(fs_inst *inst, struct brw_reg dst,
-  struct brw_reg payload,
-  struct brw_reg atomic_op,
-  struct brw_reg surf_index)
-{
-   assert(atomic_op.file == BRW_IMMEDIATE_VALUE &&
-  atomic_op.type == BRW_REGISTER_TYPE_UD &&
-  surf_index.file == BRW_IMMEDIATE_VALUE &&
- surf_index.type == BRW_REGISTER_TYPE_UD);
-
-   brw_untyped_atomic(p, dst, payload,
-  surf_index, atomic_op.dw1.ud,
-  inst->mlen, true);
-
-   brw_mark_surface_used(prog_data, surf_index.dw1.ud);
-}
-
-void
-fs_generator::generate_untyped_surface_read(fs_inst *inst, struct brw_reg dst,
-struct brw_reg payload,
-struct brw_reg surf_index)
-{
-   assert(surf_index.file == BRW_IMMEDIATE_VALUE &&
- surf_index.type == BRW_REGISTER_TYPE_UD);
-
-   brw_untyped_surface_read(p, dst, payload, surf_index, inst->mlen, 1);
-
-   brw_mark_surface_used(prog_data, surf_index.dw1.ud);
-}
-
-void
 fs_generator::enable_debug(const char *shader_name)
 {
debug_flag = true;
@@ -1915,11 +1884,18 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
  break;
 
   case SHADER_OPCODE_UNTYPED_ATOMIC:
- generate_untyped_atomic(inst, dst, src[0], src[1], src[2]);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE &&
+src[2].file == BRW_IMMEDIATE_VALUE);
+ brw_untyped_atomic(p, dst, src[0], src[2], src[1].dw1.ud,
+inst->mlen, true);
+ brw_mark_surface_used(prog_data, src[2].dw1.ud);
  break;
 
   case SHADER_OPCODE_UNTYPED_SURFACE_READ:
- generate_untyped_surface_read(inst, dst, src[0], src[1]);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ brw_untyped_surface_read(p, dst, src[0], src[1],
+  inst->mlen, 1);
+ brw_mark_surface_used(prog_data, src[1].dw1.ud);
  break;
 
   case SHADER_OPCODE_FIND_LIVE_CHANNEL:
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index adb5fe4..fe2bca0 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -501,15 +501,6 @@ private:
  struct brw_reg offset);
void generate_unpack_flags(struct brw_reg dst);
 
-   void generate_untyped_atomic(vec4_instruction *inst,
-struct brw_reg dst,
-struct brw_reg atomic_op,
-struct brw_reg surf_index);
-
-   void generate_untyped_surface_read(vec4_instruction *inst,
-  struct brw_reg dst,
-  struct brw_reg surf_index);
-
struct brw_context *brw;
 
struct brw_compile *p;
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_generator.cpp
index 00886c5..131fd4f 100644
--- a/src/mesa/drivers/dri/i965/brw_ve

[Mesa-dev] [PATCH 01/13] i965: Factor out logic to build a send message instruction with indirect descriptor.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_eu.h   | 19 ++--
 src/mesa/drivers/dri/i965/brw_eu_emit.c  | 58 ++--
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp   | 55 +-
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 37 ---
 4 files changed, 77 insertions(+), 92 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 1b954c8..9b1e0e2 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -205,11 +205,6 @@ void brw_set_sampler_message(struct brw_compile *p,
  unsigned simd_mode,
  unsigned return_format);
 
-void brw_set_indirect_send_descriptor(struct brw_compile *p,
-  brw_inst *insn,
-  unsigned sfid,
-  struct brw_reg descriptor);
-
 void brw_set_dp_read_message(struct brw_compile *p,
 brw_inst *insn,
 unsigned binding_table_index,
@@ -243,6 +238,20 @@ void brw_urb_WRITE(struct brw_compile *p,
   unsigned offset,
   unsigned swizzle);
 
+/**
+ * Send message to shared unit \p sfid with a possibly indirect descriptor \p
+ * desc.  If the descriptor is not an immediate it will be transparently
+ * loaded to an address register using an OR instruction that will be returned
+ * to the caller so additional descriptor bits can be specified with the usual
+ * brw_set_*_message() helper functions.
+ */
+struct brw_inst *
+brw_send_indirect_message(struct brw_compile *p,
+  unsigned sfid,
+  struct brw_reg dst,
+  struct brw_reg payload,
+  struct brw_reg desc);
+
 void brw_ff_sync(struct brw_compile *p,
   struct brw_reg dest,
   unsigned msg_reg_nr,
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index e69840a..cd2ce92 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -751,21 +751,6 @@ brw_set_sampler_message(struct brw_compile *p,
}
 }
 
-void brw_set_indirect_send_descriptor(struct brw_compile *p,
-  brw_inst *insn,
-  unsigned sfid,
-  struct brw_reg descriptor)
-{
-   /* Only a0.0 may be used as SEND's descriptor operand. */
-   assert(descriptor.file == BRW_ARCHITECTURE_REGISTER_FILE);
-   assert(descriptor.type == BRW_REGISTER_TYPE_UD);
-   assert(descriptor.nr == BRW_ARF_ADDRESS);
-   assert(descriptor.subnr == 0);
-
-   brw_set_message_descriptor(p, insn, sfid, 0, 0, false, false);
-   brw_set_src1(p, insn, descriptor);
-}
-
 static void
 gen7_set_dp_scratch_message(struct brw_compile *p,
 brw_inst *inst,
@@ -2490,6 +2475,49 @@ void brw_urb_WRITE(struct brw_compile *p,
   swizzle);
 }
 
+struct brw_inst *
+brw_send_indirect_message(struct brw_compile *p,
+  unsigned sfid,
+  struct brw_reg dst,
+  struct brw_reg payload,
+  struct brw_reg desc)
+{
+   const struct brw_context *brw = p->brw;
+   struct brw_inst *send, *setup;
+
+   assert(desc.type == BRW_REGISTER_TYPE_UD);
+
+   if (desc.file == BRW_IMMEDIATE_VALUE) {
+  setup = send = next_insn(p, BRW_OPCODE_SEND);
+  brw_set_src1(p, send, desc);
+
+   } else {
+  struct brw_reg addr = retype(brw_address_reg(0), BRW_REGISTER_TYPE_UD);
+
+  brw_push_insn_state(p);
+  brw_set_default_access_mode(p, BRW_ALIGN_1);
+  brw_set_default_mask_control(p, BRW_MASK_DISABLE);
+  brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
+
+  /* Load the indirect descriptor to an address register using OR so the
+   * caller can specify additional descriptor bits with the usual
+   * brw_set_*_message() helper functions.
+   */
+  setup = brw_OR(p, addr, desc, brw_imm_ud(0));
+
+  brw_pop_insn_state(p);
+
+  send = next_insn(p, BRW_OPCODE_SEND);
+  brw_set_src1(p, send, addr);
+   }
+
+   brw_set_dest(p, send, retype(dst, BRW_REGISTER_TYPE_UD));
+   brw_set_src0(p, send, retype(payload, BRW_REGISTER_TYPE_UD));
+   brw_inst_set_sfid(brw, send, sfid);
+
+   return setup;
+}
+
 static int
 brw_find_next_block_end(struct brw_compile *p, int start_offset)
 {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 2ebbfe6..a54a274 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -754,9 +754,10 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
   brw_AND(p, addr, addr, brw

[Mesa-dev] [PATCH 12/13] i965: Add typed surface access opcodes.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_defines.h|   4 +
 src/mesa/drivers/dri/i965/brw_eu.h |  24 +++
 src/mesa/drivers/dri/i965/brw_eu_emit.c| 169 +
 src/mesa/drivers/dri/i965/brw_fs.cpp   |  12 ++
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp |  17 +++
 .../drivers/dri/i965/brw_schedule_instructions.cpp |   3 +
 src/mesa/drivers/dri/i965/brw_shader.cpp   |   8 +
 src/mesa/drivers/dri/i965/brw_vec4.cpp |   6 +
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp   |  18 +++
 9 files changed, 261 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index e56f49c..cf07da9 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -906,6 +906,10 @@ enum opcode {
SHADER_OPCODE_UNTYPED_SURFACE_READ,
SHADER_OPCODE_UNTYPED_SURFACE_WRITE,
 
+   SHADER_OPCODE_TYPED_ATOMIC,
+   SHADER_OPCODE_TYPED_SURFACE_READ,
+   SHADER_OPCODE_TYPED_SURFACE_WRITE,
+
SHADER_OPCODE_GEN4_SCRATCH_READ,
SHADER_OPCODE_GEN4_SCRATCH_WRITE,
SHADER_OPCODE_GEN7_SCRATCH_READ,
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index cad956b..ce9554b 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -421,6 +421,30 @@ brw_untyped_surface_write(struct brw_compile *p,
   unsigned num_channels);
 
 void
+brw_typed_atomic(struct brw_compile *p,
+ struct brw_reg dst,
+ struct brw_reg payload,
+ struct brw_reg surface,
+ unsigned atomic_op,
+ unsigned msg_length,
+ bool response_expected);
+
+void
+brw_typed_surface_read(struct brw_compile *p,
+   struct brw_reg dst,
+   struct brw_reg payload,
+   struct brw_reg surface,
+   unsigned msg_length,
+   unsigned num_channels);
+
+void
+brw_typed_surface_write(struct brw_compile *p,
+struct brw_reg payload,
+struct brw_reg surface,
+unsigned msg_length,
+unsigned num_channels);
+
+void
 brw_pixel_interpolator_query(struct brw_compile *p,
  struct brw_reg dest,
  struct brw_reg mrf,
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index f5b8fa9..74f1fc1 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2944,6 +2944,175 @@ brw_untyped_surface_write(struct brw_compile *p,
   p, insn, num_channels);
 }
 
+static void
+brw_set_dp_typed_atomic_message(struct brw_compile *p,
+struct brw_inst *insn,
+unsigned atomic_op,
+bool response_expected)
+{
+   const struct brw_context *brw = p->brw;
+   unsigned msg_control =
+  atomic_op | /* Atomic Operation Type: BRW_AOP_* */
+  (response_expected ? 1 << 5 : 0); /* Return data expected */
+
+   if (brw->gen >= 8 || brw->is_haswell) {
+  if (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1) {
+ if (brw_inst_qtr_control(brw, p->current) == GEN6_COMPRESSION_2Q)
+msg_control |= 1 << 4; /* Use high 8 slots of the sample mask */
+
+ brw_inst_set_dp_msg_type(brw, insn,
+  HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP);
+  } else {
+ brw_inst_set_dp_msg_type(brw, insn,
+  
HSW_DATAPORT_DC_PORT1_TYPED_ATOMIC_OP_SIMD4X2);
+  }
+
+   } else {
+  brw_inst_set_dp_msg_type(brw, insn,
+   GEN7_DATAPORT_RC_TYPED_ATOMIC_OP);
+
+  if (brw_inst_qtr_control(brw, p->current) == GEN6_COMPRESSION_2Q)
+ msg_control |= 1 << 4; /* Use high 8 slots of the sample mask */
+   }
+
+   brw_inst_set_dp_msg_control(brw, insn, msg_control);
+}
+
+void
+brw_typed_atomic(struct brw_compile *p,
+ struct brw_reg dst,
+ struct brw_reg payload,
+ struct brw_reg surface,
+ unsigned atomic_op,
+ unsigned msg_length,
+ bool response_expected) {
+   const struct brw_context *brw = p->brw;
+   const unsigned sfid = (brw->gen >= 8 || brw->is_haswell ?
+  HSW_SFID_DATAPORT_DATA_CACHE_1 :
+  GEN6_SFID_DATAPORT_RENDER_CACHE);
+   const bool align1 = (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1);
+   /* Mask out unused components -- See comment in brw_untyped_atomic(). */
+   const unsigned mask = (align1 ? WRITEMASK_XYZW : WRITEMASK_X);
+   struct brw_inst *insn = brw_send_indirect_surface_message(
+  p, sfid, brw_writemask(dst, mask), payload, surface, msg_len

[Mesa-dev] [PATCH 11/13] i965: Add untyped surface write opcode.

2015-02-27 Thread Francisco Jerez
---
 src/mesa/drivers/dri/i965/brw_defines.h|  1 +
 src/mesa/drivers/dri/i965/brw_eu.h |  7 +++
 src/mesa/drivers/dri/i965/brw_eu_emit.c| 51 ++
 src/mesa/drivers/dri/i965/brw_fs.cpp   |  4 ++
 src/mesa/drivers/dri/i965/brw_fs_generator.cpp |  6 +++
 .../drivers/dri/i965/brw_schedule_instructions.cpp |  1 +
 src/mesa/drivers/dri/i965/brw_shader.cpp   |  3 ++
 src/mesa/drivers/dri/i965/brw_vec4.cpp |  2 +
 src/mesa/drivers/dri/i965/brw_vec4_generator.cpp   |  6 +++
 9 files changed, 81 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 7660feb..e56f49c 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -904,6 +904,7 @@ enum opcode {
 
SHADER_OPCODE_UNTYPED_ATOMIC,
SHADER_OPCODE_UNTYPED_SURFACE_READ,
+   SHADER_OPCODE_UNTYPED_SURFACE_WRITE,
 
SHADER_OPCODE_GEN4_SCRATCH_READ,
SHADER_OPCODE_GEN4_SCRATCH_WRITE,
diff --git a/src/mesa/drivers/dri/i965/brw_eu.h 
b/src/mesa/drivers/dri/i965/brw_eu.h
index 9cc9123..cad956b 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.h
+++ b/src/mesa/drivers/dri/i965/brw_eu.h
@@ -414,6 +414,13 @@ brw_untyped_surface_read(struct brw_compile *p,
  unsigned num_channels);
 
 void
+brw_untyped_surface_write(struct brw_compile *p,
+  struct brw_reg payload,
+  struct brw_reg surface,
+  unsigned msg_length,
+  unsigned num_channels);
+
+void
 brw_pixel_interpolator_query(struct brw_compile *p,
  struct brw_reg dest,
  struct brw_reg mrf,
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 34695bf..f5b8fa9 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -2893,6 +2893,57 @@ brw_untyped_surface_read(struct brw_compile *p,
   p, insn, num_channels);
 }
 
+static void
+brw_set_dp_untyped_surface_write_message(struct brw_compile *p,
+ struct brw_inst *insn,
+ unsigned num_channels)
+{
+   const struct brw_context *brw = p->brw;
+   /* Set mask of 32-bit channels to drop. */
+   unsigned msg_control = (0xf & (0xf << num_channels));
+
+   if (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1) {
+  if (p->compressed)
+ msg_control |= 1 << 4; /* SIMD16 mode */
+  else
+ msg_control |= 2 << 4; /* SIMD8 mode */
+   } else {
+  if (brw->gen >= 8 || brw->is_haswell)
+ msg_control |= 0 << 4; /* SIMD4x2 mode */
+  else
+ msg_control |= 2 << 4; /* SIMD8 mode */
+   }
+
+   brw_inst_set_dp_msg_type(brw, insn,
+(brw->gen >= 8 || brw->is_haswell ?
+ HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_WRITE :
+ GEN7_DATAPORT_DC_UNTYPED_SURFACE_WRITE));
+   brw_inst_set_dp_msg_control(brw, insn, msg_control);
+}
+
+void
+brw_untyped_surface_write(struct brw_compile *p,
+  struct brw_reg payload,
+  struct brw_reg surface,
+  unsigned msg_length,
+  unsigned num_channels)
+{
+   const struct brw_context *brw = p->brw;
+   const unsigned sfid = (brw->gen >= 8 || p->brw->is_haswell ?
+  HSW_SFID_DATAPORT_DATA_CACHE_1 :
+  GEN7_SFID_DATAPORT_DATA_CACHE);
+   const bool align1 = (brw_inst_access_mode(brw, p->current) == BRW_ALIGN_1);
+   /* Mask out unused components -- See comment in brw_untyped_atomic(). */
+   const unsigned mask = (brw->gen == 7 && !brw->is_haswell && !align1 ?
+  WRITEMASK_X : WRITEMASK_XYZW);
+   struct brw_inst *insn = brw_send_indirect_surface_message(
+  p, sfid, brw_writemask(brw_null_reg(), mask),
+  payload, surface, msg_length, 0, align1);
+
+   brw_set_dp_untyped_surface_write_message(
+  p, insn, num_channels);
+}
+
 void
 brw_pixel_interpolator_query(struct brw_compile *p,
  struct brw_reg dest,
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 6e6ce58..6d363f1 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -508,6 +508,7 @@ fs_inst::is_send_from_grf() const
case FS_OPCODE_INTERPOLATE_AT_PER_SLOT_OFFSET:
case SHADER_OPCODE_UNTYPED_ATOMIC:
case SHADER_OPCODE_UNTYPED_SURFACE_READ:
+   case SHADER_OPCODE_UNTYPED_SURFACE_WRITE:
case SHADER_OPCODE_URB_WRITE_SIMD8:
   return true;
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
@@ -930,6 +931,8 @@ fs_inst::regs_read(int arg) const
   return mlen;
} else if (opcode == SHADER_OPCODE_UNTYPED_SURFACE_READ && arg == 0) 

Re: [Mesa-dev] [PATCH 3/3] radeonsi/compute: Enable PIPE_SHADER_CAP_DOUBLES

2015-02-27 Thread Marek Olšák
Hi Kai,

The patch only enables double support for compute shaders, which don't use TGSI.

There is no TGSI double support in radeonsi yet, so
ARB_gpu_shader_fp64 can't be marked as done.

Marek

On Fri, Feb 27, 2015 at 1:38 PM, Kai Wasserbäch
 wrote:
> Should GL_ARB_gpu_shader_fp64 be marked as done for radeonsi in GL3.txt then? 
> Or
> is PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED a must as well (I don't think so and
> maybe PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED could be enabled as well?).
>
> Cheers,
> Kai
>
>
> Tom Stellard wrote on 27.02.2015 02:06:
>> ---
>>  src/gallium/drivers/radeonsi/si_pipe.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
>> b/src/gallium/drivers/radeonsi/si_pipe.c
>> index 26182c2..c7a7622 100644
>> --- a/src/gallium/drivers/radeonsi/si_pipe.c
>> +++ b/src/gallium/drivers/radeonsi/si_pipe.c
>> @@ -360,8 +360,11 @@ static int si_get_shader_param(struct pipe_screen* 
>> pscreen, unsigned shader, enu
>>   return PIPE_SHADER_IR_NATIVE;
>>  #endif
>>   case PIPE_SHADER_CAP_DOUBLES:
>> - return 0; /* XXX: Enable doubles once the compiler can
>> -  handle them. */
>> +#if HAVE_LLVM >= 0x0307
>> + return 1;
>> +#else
>> + return 0;
>> +#endif
>>   case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE: {
>>   uint64_t max_const_buffer_size;
>>   pscreen->get_compute_param(pscreen,
>>
>
> --
>
> Kai Wasserbäch (Kai Wasserbaech)
>
> E-Mail: k...@dev.carbon-project.org
>
>
> ___
> 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] RFC: Prune stale components

2015-02-27 Thread Ian Romanick
On 02/27/2015 07:16 AM, Jose Fonseca wrote:
> As we're gaining momentum cleanup Mesa code, I think it would help if we
> also removed some stale components.
> 
> What do people feel about removing:
> 
> - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
> haven't used in a very long time, and given that the old SW rasterizer
> is so far behind compared gallium based softpipe/llvmpipe rasterizers,
> it's hard to imagine this will ever be useful again

I'm in favor.

> - src/gallium/drivers/rbug: -- do people use it? does it work?  it
> predates apitrace GL + GUI, which sort of enables a lot of the same
> things, but without the issue of having to hit moving target, which is
> what gallium interfaces are
> 
> - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems
> to have dwindled away. I recall Zack himself saying that much. The code
> would still be interesting if we wanted to implement NV_path_rendering
> [1], but given the trend of the next gen graphics APIs, it seems
> unlikely that this becomes ARB or core.

I'm not a big fan of NV_path_rendering, and it would surprise me greatly
if it ever became a core part of OpenGL... or even an ARB extension.
Either way, if we delete the code, it is still in GIT.

> - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but
> since then I discovered WGL/GLX_EXT_create_context_es_profile, and the
> odds of us (VMware) needing this again are dimmer than last time, so I
> have to admit it does seem unlikely we or anybody will need it again,
> and we can always revert it from history..
> 
> 
> Anything else?
> 
> 
> Jose
> 
> 
> [1] http://zrusin.blogspot.co.uk/2011/09/nv-path-rendering.html
> ___
> 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] Crash with Mesa-10.4.4 and NV68

2015-02-27 Thread Ilia Mirkin
Hi Arno,

I think at this point the most helpful thing would be to get an
apitrace (https://github.com/apitrace/apitrace) with your "fix" in
place. Once you make the trace, change your fix to instead abort the
program, and replay the trace. This will allow us to look at the
precise call sequence that causes the issue.

What is the numerical value of ve->vertex_buffer_index when it's >=
num_vtxbufs? [What about num_vtxbufs?]

Cheers,

  -ilia

On Fri, Feb 27, 2015 at 9:41 AM, Arno Willig  wrote:
>
> Hi,
>
> I experience a crash in the nouveau part of the mesa driver:
>
> src/gallium/drivers/nouveau/nv30/nv30_vbo.c
>
> in function:
>
> void nv30_vbo_validate(struct nv30_context *nv30)
>
>
> Sometimes, ve->vertex_buffer_index seems to be greater or equal
> nv30->num_vtxbuf. If this happens, PUSH_RESRC crashes!
> How can this happen??
>
> I tried to break out of the for-loop
> for (i = 0; i < vertex->num_elements; i++)
> when the problem appears.
> If I do this, the driver won't crash anymore, but some screen elements
> are missing.
> A short while later I get a GPU lockup message:
>> kernel: nouveau E[ DRM] GPU lockup - switching to software fbcon
>
>
> I can reproduce this crash with a Qt5.3 Quick2 application.
>
> Where would be the next point to look into this?
>
> Can anyone help me with this? Does a mmiotrace help?
>
>
> My system:
> - Board: ASRock N68C-GS FX with NV68 GeForce 7025 OnBoard
> - Linux 3.18.4, (32 bit)
> - Mesa-10.4.4
> -
>
> Regards,
>
> Arno
>
>
>
>
> ___
> 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] identity: Remove.

2015-02-27 Thread Marek Olšák
This seems like a good idea to me.

Marek

On Fri, Feb 27, 2015 at 3:51 PM, Jose Fonseca  wrote:
> It's unmaintained, and most likely broken: I use trace driver every now
> and then, and everytime I do I need to fix it up.
>
> It's also unused: identity_screen_create is never called.
>
> Above all, it's dead weight: if identity driver had the infrastructure
> for other pass-through drivers (like trace and rbug), then it would make
> sense on its own right.  But as it is implemmented, it's just another
> driver to (forget) to update whenever there is a gallium interface
> change.
> ---
>  configure.ac  |   1 -
>  src/gallium/Makefile.am   |   1 -
>  src/gallium/SConscript|   1 -
>  src/gallium/drivers/identity/Makefile.am  |  11 -
>  src/gallium/drivers/identity/Makefile.sources |   8 -
>  src/gallium/drivers/identity/SConscript   |  12 -
>  src/gallium/drivers/identity/id_context.c | 883 
> --
>  src/gallium/drivers/identity/id_context.h |  52 --
>  src/gallium/drivers/identity/id_objects.c | 189 --
>  src/gallium/drivers/identity/id_objects.h | 177 --
>  src/gallium/drivers/identity/id_public.h  |  37 --
>  src/gallium/drivers/identity/id_screen.c  | 286 -
>  src/gallium/drivers/identity/id_screen.h  |  48 --
>  src/gallium/targets/egl-static/Makefile.am|   1 -
>  14 files changed, 1707 deletions(-)
>  delete mode 100644 src/gallium/drivers/identity/Makefile.am
>  delete mode 100644 src/gallium/drivers/identity/Makefile.sources
>  delete mode 100644 src/gallium/drivers/identity/SConscript
>  delete mode 100644 src/gallium/drivers/identity/id_context.c
>  delete mode 100644 src/gallium/drivers/identity/id_context.h
>  delete mode 100644 src/gallium/drivers/identity/id_objects.c
>  delete mode 100644 src/gallium/drivers/identity/id_objects.h
>  delete mode 100644 src/gallium/drivers/identity/id_public.h
>  delete mode 100644 src/gallium/drivers/identity/id_screen.c
>  delete mode 100644 src/gallium/drivers/identity/id_screen.h
>
> diff --git a/configure.ac b/configure.ac
> index 22dc023..c5abbfd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2378,7 +2378,6 @@ AC_CONFIG_FILES([Makefile
> src/gallium/drivers/freedreno/Makefile
> src/gallium/drivers/galahad/Makefile
> src/gallium/drivers/i915/Makefile
> -   src/gallium/drivers/identity/Makefile
> src/gallium/drivers/ilo/Makefile
> src/gallium/drivers/llvmpipe/Makefile
> src/gallium/drivers/noop/Makefile
> diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
> index 6a2a866..f6bf3c0 100644
> --- a/src/gallium/Makefile.am
> +++ b/src/gallium/Makefile.am
> @@ -12,7 +12,6 @@ SUBDIRS += auxiliary
>
>  SUBDIRS += \
> drivers/galahad \
> -   drivers/identity \
> drivers/noop \
> drivers/trace \
> drivers/rbug
> diff --git a/src/gallium/SConscript b/src/gallium/SConscript
> index 25d0af6..37767b5 100644
> --- a/src/gallium/SConscript
> +++ b/src/gallium/SConscript
> @@ -13,7 +13,6 @@ SConscript('auxiliary/SConscript')
>  # These are common and work across all platforms
>  SConscript([
>  'drivers/galahad/SConscript',
> -'drivers/identity/SConscript',
>  'drivers/llvmpipe/SConscript',
>  'drivers/rbug/SConscript',
>  'drivers/softpipe/SConscript',
> diff --git a/src/gallium/drivers/identity/Makefile.am 
> b/src/gallium/drivers/identity/Makefile.am
> deleted file mode 100644
> index 0a49633..000
> --- a/src/gallium/drivers/identity/Makefile.am
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -include Makefile.sources
> -include $(top_srcdir)/src/gallium/Automake.inc
> -
> -AM_CFLAGS = \
> -   $(GALLIUM_DRIVER_CFLAGS)
> -
> -noinst_LTLIBRARIES = libidentity.la
> -
> -libidentity_la_SOURCES = $(C_SOURCES)
> -
> -EXTRA_DIST = SConscript
> diff --git a/src/gallium/drivers/identity/Makefile.sources 
> b/src/gallium/drivers/identity/Makefile.sources
> deleted file mode 100644
> index e3e34a8..000
> --- a/src/gallium/drivers/identity/Makefile.sources
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -C_SOURCES := \
> -   id_context.c \
> -   id_context.h \
> -   id_objects.c \
> -   id_objects.h \
> -   id_public.h \
> -   id_screen.c \
> -   id_screen.h
> diff --git a/src/gallium/drivers/identity/SConscript 
> b/src/gallium/drivers/identity/SConscript
> deleted file mode 100644
> index 1209951..000
> --- a/src/gallium/drivers/identity/SConscript
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -Import('*')
> -
> -env = env.Clone()
> -
> -identity = env.ConvenienceLibrary(
> -   target = 'identity',
> -   source = env.ParseSourceList('Makefile.sources', 'C_SOURCES')
> -   )
> -
> -env.Alias('identity', identity)
> -
> -Export('identity')
> diff --git a/src/gallium/drivers/identity/id_context.c 
> b/src/gallium/drivers/identity/

Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Ilia Mirkin
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca  wrote:
> - src/gallium/drivers/rbug: -- do people use it? does it work?  it predates
> apitrace GL + GUI, which sort of enables a lot of the same things, but
> without the issue of having to hit moving target, which is what gallium
> interfaces are

FWIW I tried to use it when debugging a VDPAU issue, but getting it to
pass through video textures (even without any inspection) proved
harder than (eventually) fixing the driver bug. I think it's
especially useful for situations where apitrace doesn't work, and even
where it does, it can provide visibility into intermediate stages of
rendering. I think it's a useful-enough tool to keep around.

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


Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Marek Olšák
On Fri, Feb 27, 2015 at 4:16 PM, Jose Fonseca  wrote:
> As we're gaining momentum cleanup Mesa code, I think it would help if we
> also removed some stale components.
>
> What do people feel about removing:
>
> - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
> haven't used in a very long time, and given that the old SW rasterizer is so
> far behind compared gallium based softpipe/llvmpipe rasterizers, it's hard
> to imagine this will ever be useful again
>
> - src/gallium/drivers/rbug: -- do people use it? does it work?  it predates
> apitrace GL + GUI, which sort of enables a lot of the same things, but
> without the issue of having to hit moving target, which is what gallium
> interfaces are

I used it to debug Unigine Sanctuary last year and it helped me track
down a driver bug. It works pretty well.

It has some cool features like being able to watch textures and
renderbuffers as they change in real time.

I guess whoever wants to use it should expect that some functions may
not be implemented.

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


Re: [Mesa-dev] [PATCH 2/2] configure: Leverage gcc warn options to enable safe use of C99 features where possible.

2015-02-27 Thread Ian Romanick
I like the idea as it should prevent future thrash.  There are a couple
comments below.

On 02/26/2015 08:51 AM, Jose Fonseca wrote:
> The main objective of this change is to enable Linux developers to use
> more of C99 throughout Mesa, with confidence that the portions that need
> to be built with MSVC -- and only those portions --, stay portable.
> 
> This is achieved by using the appropriate -Werror= options only on the
> places they need to be used.
> 
> Unfortunately we still need MSVC 2008 on a few portions of the code
> (namely llvmpipe and its dependencies).  I hope to eventually eliminate
> this so that we can use C99 everywhere, but there are technical/logistic
> challenges (specifically, newer Windows SDKs no longer bundle MSVC,
> instead require a full installation of Visual Studio, and that has
> hindered adoption of newer MSVC versions on our build processes.)
> Thankfully we have more directy control over our OpenGL driver, which is
> why we're now able to migrate to MSVC 2013 for most of the tree.
> ---
>  configure.ac   | 17 +
>  src/egl/main/Makefile.am   |  1 +
>  src/gallium/auxiliary/Makefile.am  |  7 +--
>  src/gallium/drivers/llvmpipe/Makefile.am   |  6 --
>  src/gallium/state_trackers/egl/Makefile.am |  3 ++-
>  src/gallium/targets/egl-static/Makefile.am |  3 ++-
>  src/glsl/Makefile.am   |  8 ++--
>  src/loader/Makefile.am |  1 +
>  src/mapi/Makefile.am   |  4 +++-
>  src/mesa/Makefile.am   | 10 --
>  src/util/Makefile.am   |  3 ++-
>  11 files changed, 51 insertions(+), 12 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 5fbb7bc..22dc023 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -263,6 +263,18 @@ if test "x$GCC" = xyes; then
>  # gcc's builtin memcmp is slower than glibc's
>  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
>  CFLAGS="$CFLAGS -fno-builtin-memcmp"
> +
> +# Flags to help ensure that certain portions of the code -- and only 
> those
> +# portions -- can be built with MSVC:
> +# - src/util, src/gallium/auxiliary, and src/gallium/drivers/llvmpipe 
> needs
> +#   to build with Windows SDK 7.0.7600, which bundles MSVC 2008
> +# - non-Linux/Posix OpenGL portions needs to build on MSVC 2013 (which
> +#   supports most of C99)
> +# - the rest has no compiler compiler restrictions
> +MSVC2013_COMPAT_CFLAGS="-Werror=vla -Werror=pointer-arith"
> +MSVC2013_COMPAT_CXXFLAGS="-Werror=vla -Werror=pointer-arith"
> +MSVC2008_COMPAT_CFLAGS="$MSVC2013_COMPAT_CFLAGS 
> -Werror=declaration-after-statement"
> +MSVC2008_COMPAT_CXXFLAGS="$MSVC2013_COMPAT_CXXFLAGS"
>  fi
>  if test "x$GXX" = xyes; then
>  CXXFLAGS="$CXXFLAGS -Wall"
> @@ -288,6 +300,11 @@ if test "x$GXX" = xyes; then
>  CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp"
>  fi
>  
> +AC_SUBST([MSVC2013_COMPAT_CFLAGS])
> +AC_SUBST([MSVC2013_COMPAT_CXXFLAGS])
> +AC_SUBST([MSVC2008_COMPAT_CFLAGS])
> +AC_SUBST([MSVC2008_COMPAT_CXXFLAGS])
> +
>  dnl even if the compiler appears to support it, using visibility attributes 
> isn't
>  dnl going to do anything useful currently on cygwin apart from emit lots of 
> warnings
>  case "$host_os" in
> diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
> index d21d8a9..a4db210 100644
> --- a/src/egl/main/Makefile.am
> +++ b/src/egl/main/Makefile.am
> @@ -26,6 +26,7 @@ AM_CFLAGS = \
>   -I$(top_srcdir)/src/gbm/main \
>   $(DEFINES) \
>   $(VISIBILITY_CFLAGS) \
> + $(MSVC2013_COMPAT_CFLAGS) \
>   $(EGL_CFLAGS) \
>   -D_EGL_NATIVE_PLATFORM=$(EGL_NATIVE_PLATFORM) \
>   -D_EGL_DRIVER_SEARCH_DIR=\"$(libdir)/egl\" \
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 4b62057..27a8b3f 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -12,9 +12,12 @@ noinst_LTLIBRARIES = libgallium.la
>  AM_CFLAGS = \
>   -I$(top_srcdir)/src/gallium/auxiliary/util \
>   $(GALLIUM_CFLAGS) \
> - $(VISIBILITY_CFLAGS)
> + $(VISIBILITY_CFLAGS) \
> + $(MSVC2008_COMPAT_CXXFLAGS)
>  
> -AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
> +AM_CXXFLAGS = \
> + $(VISIBILITY_CXXFLAGS) \
> + $(MSVC2008_COMPAT_CXXFLAGS)
>  
>  libgallium_la_SOURCES = \
>   $(C_SOURCES) \
> diff --git a/src/gallium/drivers/llvmpipe/Makefile.am 
> b/src/gallium/drivers/llvmpipe/Makefile.am
> index 0bd4282..1d3853e 100644
> --- a/src/gallium/drivers/llvmpipe/Makefile.am
> +++ b/src/gallium/drivers/llvmpipe/Makefile.am
> @@ -25,10 +25,12 @@ include $(top_srcdir)/src/gallium/Automake.inc
>  
>  AM_CFLAGS = \
>   $(GALLIUM_DRIVER_CFLAGS) \
> - $(LLVM_CFLAGS)
> + $(LLVM_CFLAGS) \
> + $(MSVC2008_COMPAT_CFLAGS)
>  AM_CXXFLAGS= \
>   $(GALLIUM_DRIVER_CXXFLAGS) \
> - $(LLVM_CXXFLAGS)
> + $(LLVM_CXXFLAGS) \
> +

Re: [Mesa-dev] [PATCH 1/2] nir: Use alloca instead of variable length arrays.

2015-02-27 Thread Ian Romanick
On 02/26/2015 10:07 AM, Brian Paul wrote:
> On 02/26/2015 09:51 AM, Jose Fonseca wrote:
>> This is to enable the code to build with -Werror=vla in the short term,
>> and enable the code to build with MSVC2013 soon after.
>> ---
>>   include/c99_alloca.h | 45
>> 
>>   src/glsl/nir/nir_from_ssa.c  | 19 +++
>>   src/glsl/nir/nir_live_variables.c|  5 ++--
>>   src/glsl/nir/nir_lower_vars_to_ssa.c | 13 +++
>>   4 files changed, 66 insertions(+), 16 deletions(-)
>>   create mode 100644 include/c99_alloca.h
>>
>> diff --git a/include/c99_alloca.h b/include/c99_alloca.h
>> new file mode 100644
>> index 000..6d96d06
>> --- /dev/null
>> +++ b/include/c99_alloca.h
>> @@ -0,0 +1,45 @@
>> +/**
>>
>> + *
>> + * Copyright 2015 VMware, Inc.
>> + * All Rights Reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person
>> obtaining a
>> + * copy of this software and associated documentation files (the
>> + * "Software"), to deal in the Software without restriction, including
>> + * without limitation the rights to use, copy, modify, merge, publish,
>> + * distribute, sub license, and/or sell copies of the Software, and to
>> + * permit persons to whom the Software is furnished to do so, subject to
>> + * the following conditions:
>> + *
>> + * The above copyright notice and this permission notice (including the
>> + * next paragraph) shall be included in all copies or substantial
>> portions
>> + * of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> EXPRESS
>> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> NON-INFRINGEMENT.
>> + * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS BE LIABLE FOR
>> + * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
>> CONTRACT,
>> + * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
>> + * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> +
>> **/
>>
>> +
>> +#ifndef _C99_ALLOCA_H_
>> +#define _C99_ALLOCA_H_
>> +
>> +
>> +#if defined(_MSC_VER)
>> +
>> +#  include 
>> +
>> +#  define alloca _alloca
>> +
>> +#else /* !defined(_MSC_VER) */
>> +
>> +#  include 
>> +
>> +#endif /* !defined(_MSC_VER) */
>> +
>> +
>> +#endif
>> diff --git a/src/glsl/nir/nir_from_ssa.c b/src/glsl/nir/nir_from_ssa.c
>> index c695c95..66339f3 100644
>> --- a/src/glsl/nir/nir_from_ssa.c
>> +++ b/src/glsl/nir/nir_from_ssa.c
>> @@ -26,6 +26,7 @@
>>*/
>>
>>   #include "nir.h"
>> +#include "c99_alloca.h"
>>
>>   /*
>>* This file implements an out-of-SSA pass as described in "Revisiting
>> @@ -181,7 +182,7 @@ merge_merge_sets(merge_set *a, merge_set *b)
>>   static bool
>>   merge_sets_interfere(merge_set *a, merge_set *b)
>>   {
>> -   merge_node *dom[a->size + b->size];
>> +   merge_node **dom = alloca((a->size + b->size) * sizeof *dom);
>>  int dom_idx = -1;
>>
>>  struct exec_node *an = exec_list_get_head(&a->nodes);
>> @@ -673,21 +674,21 @@ resolve_parallel_copy(nir_parallel_copy_instr
>> *pcopy,
>>  }
>>
>>  /* The register/source corresponding to the given index */
>> -   nir_src values[num_copies * 2];
>> -   memset(values, 0, sizeof values);
>> +   nir_src *values = alloca(num_copies * 2 * sizeof *values);
>> +   memset(values, 0, num_copies * 2 * sizeof *values);
>>
>>  /* The current location of a given piece of data */
>> -   int loc[num_copies * 2];
>> +   int *loc = alloca(num_copies * 2 * sizeof *loc);
>>
>>  /* The piece of data that the given piece of data is to be copied
>> from */
>> -   int pred[num_copies * 2];
>> +   int *pred = alloca(num_copies * 2 * sizeof *pred);
>>
>>  /* Initialize loc and pred.  We will use -1 for "null" */
>> -   memset(loc, -1, sizeof loc);
>> -   memset(pred, -1, sizeof pred);
>> +   memset(loc, -1, num_copies * 2 * sizeof *loc);
>> +   memset(pred, -1, num_copies * 2 * sizeof *pred);
>>
>>  /* The destinations we have yet to properly fill */
>> -   int to_do[num_copies * 2];
>> +   int *to_do = alloca(num_copies * 2 * sizeof *to_do);
>>  int to_do_idx = -1;
>>
>>  /* Now we set everything up:
>> @@ -737,7 +738,7 @@ resolve_parallel_copy(nir_parallel_copy_instr *pcopy,
>>  }
>>
>>  /* Currently empty destinations we can go ahead and fill */
>> -   int ready[num_copies * 2];
>> +   int *ready = alloca(num_copies * 2 * sizeof *ready);
>>  int ready_idx = -1;
>>
>>  /* Mark the ones that are ready for copying.  We know an index is a
>> diff --git a/src/glsl/nir/nir_live_variables.c
>> b/src/glsl/nir/nir_live_variables.c
>> index 7402dc0..b57ca3a 100644
>> --- a/src/glsl/nir/nir_live_variables.c
>> +++ b/src/glsl/nir/nir_live_variables.c
>> @@ -26,6 +26,7 @@
>>
>>   #include "nir.h"
>>   #include "ni

Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Brian Paul

On 02/27/2015 08:16 AM, Jose Fonseca wrote:

As we're gaining momentum cleanup Mesa code, I think it would help if we
also removed some stale components.

What do people feel about removing:

- src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
haven't used in a very long time, and given that the old SW rasterizer
is so far behind compared gallium based softpipe/llvmpipe rasterizers,
it's hard to imagine this will ever be useful again


Sounds good.



- src/gallium/drivers/rbug: -- do people use it? does it work?  it
predates apitrace GL + GUI, which sort of enables a lot of the same
things, but without the issue of having to hit moving target, which is
what gallium interfaces are


Either way is OK by me.



- src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems
to have dwindled away. I recall Zack himself saying that much. The code
would still be interesting if we wanted to implement NV_path_rendering
[1], but given the trend of the next gen graphics APIs, it seems
unlikely that this becomes ARB or core.


If Zack's OK with it, fine by me.  Though it's a little sad it hasn't 
been used more.




- src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but
since then I discovered WGL/GLX_EXT_create_context_es_profile, and the
odds of us (VMware) needing this again are dimmer than last time, so I
have to admit it does seem unlikely we or anybody will need it again,
and we can always revert it from history..


The fact this stuff can be revived from git if actually needed makes it 
a fairly easy decision, I think.


-Brian

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


Re: [Mesa-dev] [PATCH 2/2] configure: Leverage gcc warn options to enable safe use of C99 features where possible.

2015-02-27 Thread Tom Stellard
Hi,

This patch breaks the build for me:

CFLAGS="-g" CXXFLAGS="$CFLAGS" CC="ccache gcc" CXX="ccache g++"
./autogen.sh \
--prefix=/usr/local \
--with-dri-drivers="no" \
--with-gallium-drivers="r600,radeonsi" \
--enable-glx-tls \
--enable-debug \
--enable-shared-glapi \
--with-egl-platforms=x11,drm \
--enable-gallium-egl \
--enable-gallium-gbm \
--with-llvm-prefix=/usr/local/llvm/3.7 \
--enable-gallium-drm-loader \
--enable-gallium-compute-api \
--enable-opencl-icd \
--enable-opengl \
--disable-dri3 \
--enable-texture-float \
--with-llvm-shared-libs \
--enable-opencl \
--enable-gbm

  CC   glapi_libglapi_la-entry.lo
In file included from entry.c:49:0:
entry_x86-64_tls.h: In function 'entry_generate':
entry_x86-64_tls.h:105:29: error: pointer of type 'void *' used in arithmetic 
[-Werror=pointer-arith]
*((unsigned int *) (code + 5)) = addr;
 ^
cc1: some warnings being treated as errors
Makefile:1425: recipe for target 'shared_glapi_libglapi_la-entry.lo'
failed


On Fri, Feb 27, 2015 at 07:59:47AM -0800, Ian Romanick wrote:
> I like the idea as it should prevent future thrash.  There are a couple
> comments below.
> 
> On 02/26/2015 08:51 AM, Jose Fonseca wrote:
> > The main objective of this change is to enable Linux developers to use
> > more of C99 throughout Mesa, with confidence that the portions that need
> > to be built with MSVC -- and only those portions --, stay portable.
> > 
> > This is achieved by using the appropriate -Werror= options only on the
> > places they need to be used.
> > 
> > Unfortunately we still need MSVC 2008 on a few portions of the code
> > (namely llvmpipe and its dependencies).  I hope to eventually eliminate
> > this so that we can use C99 everywhere, but there are technical/logistic
> > challenges (specifically, newer Windows SDKs no longer bundle MSVC,
> > instead require a full installation of Visual Studio, and that has
> > hindered adoption of newer MSVC versions on our build processes.)
> > Thankfully we have more directy control over our OpenGL driver, which is
> > why we're now able to migrate to MSVC 2013 for most of the tree.
> > ---
> >  configure.ac   | 17 +
> >  src/egl/main/Makefile.am   |  1 +
> >  src/gallium/auxiliary/Makefile.am  |  7 +--
> >  src/gallium/drivers/llvmpipe/Makefile.am   |  6 --
> >  src/gallium/state_trackers/egl/Makefile.am |  3 ++-
> >  src/gallium/targets/egl-static/Makefile.am |  3 ++-
> >  src/glsl/Makefile.am   |  8 ++--
> >  src/loader/Makefile.am |  1 +
> >  src/mapi/Makefile.am   |  4 +++-
> >  src/mesa/Makefile.am   | 10 --
> >  src/util/Makefile.am   |  3 ++-
> >  11 files changed, 51 insertions(+), 12 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 5fbb7bc..22dc023 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -263,6 +263,18 @@ if test "x$GCC" = xyes; then
> >  # gcc's builtin memcmp is slower than glibc's
> >  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
> >  CFLAGS="$CFLAGS -fno-builtin-memcmp"
> > +
> > +# Flags to help ensure that certain portions of the code -- and only 
> > those
> > +# portions -- can be built with MSVC:
> > +# - src/util, src/gallium/auxiliary, and src/gallium/drivers/llvmpipe 
> > needs
> > +#   to build with Windows SDK 7.0.7600, which bundles MSVC 2008
> > +# - non-Linux/Posix OpenGL portions needs to build on MSVC 2013 (which
> > +#   supports most of C99)
> > +# - the rest has no compiler compiler restrictions
> > +MSVC2013_COMPAT_CFLAGS="-Werror=vla -Werror=pointer-arith"
> > +MSVC2013_COMPAT_CXXFLAGS="-Werror=vla -Werror=pointer-arith"
> > +MSVC2008_COMPAT_CFLAGS="$MSVC2013_COMPAT_CFLAGS 
> > -Werror=declaration-after-statement"
> > +MSVC2008_COMPAT_CXXFLAGS="$MSVC2013_COMPAT_CXXFLAGS"
> >  fi
> >  if test "x$GXX" = xyes; then
> >  CXXFLAGS="$CXXFLAGS -Wall"
> > @@ -288,6 +300,11 @@ if test "x$GXX" = xyes; then
> >  CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp"
> >  fi
> >  
> > +AC_SUBST([MSVC2013_COMPAT_CFLAGS])
> > +AC_SUBST([MSVC2013_COMPAT_CXXFLAGS])
> > +AC_SUBST([MSVC2008_COMPAT_CFLAGS])
> > +AC_SUBST([MSVC2008_COMPAT_CXXFLAGS])
> > +
> >  dnl even if the compiler appears to support it, using visibility 
> > attributes isn't
> >  dnl going to do anything useful currently on cygwin apart from emit lots 
> > of warnings
> >  case "$host_os" in
> > diff --git a/src/egl/main/Makefile.am b/src/egl/main/Makefile.am
> > index d21d8a9..a4db210 100644
> > --- a/src/egl/main/Makefile.am
> > +++ b/src/egl/main/Makefile.am
> > @@ -26,6 +26,7 @@ AM_CFLAGS = \
> > -I$(top_srcdir)/src/gbm/main \
> > $(DEFINES) \
> > $(VISIBILITY_CFLAGS) \
> > +   $(MSVC2013_COMPAT_CFLAGS) \
> > $(EGL_CFLAGS) \
> > -D_EGL_NATIVE_PLATFORM=$(EGL_NATIVE_PLATFORM) \
> > -D_EGL_DRIV

Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Rob Clark
On Fri, Feb 27, 2015 at 10:16 AM, Jose Fonseca  wrote:
> - src/gallium/drivers/rbug: -- do people use it? does it work?  it predates
> apitrace GL + GUI, which sort of enables a lot of the same things, but
> without the issue of having to hit moving target, which is what gallium
> interfaces are

Another vote for keeping rbug..

Maybe some extensions to expose things like tgsi level shaders and
maybe some other gallium level state to apitrace could replace part of
what I use rbug for.  Although the single-stepping is useful too..

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


Re: [Mesa-dev] [PATCH 2/7] i965: Remove the create_raw_surface vtbl hook.

2015-02-27 Thread Kristian Høgsberg
On Sat, Jan 17, 2015 at 3:04 PM, Francisco Jerez  wrote:
> It's a wrapper around emit_buffer_surface_state with format=RAW, pitch=1,
> rw=true and the remaining arguments ordered differently.  There's no point in
> having a separate vtbl pointer for that.

Yeah, I agree, that can go.

Reviewed-by: Kristian Høgsberg 

> ---
>  src/mesa/drivers/dri/i965/brw_binding_tables.c|  8 +---
>  src/mesa/drivers/dri/i965/brw_context.h   |  6 --
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c  |  6 +++---
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 19 ---
>  src/mesa/drivers/dri/i965/gen8_surface_state.c| 16 
>  5 files changed, 8 insertions(+), 47 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c 
> b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> index ea82e71..08e4191 100644
> --- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> +++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> @@ -68,9 +68,11 @@ brw_upload_binding_table(struct brw_context *brw,
> } else {
>/* Upload a new binding table. */
>if (INTEL_DEBUG & DEBUG_SHADER_TIME) {
> - brw->vtbl.create_raw_surface(
> -brw, brw->shader_time.bo, 0, brw->shader_time.bo->size,
> -
> &stage_state->surf_offset[prog_data->binding_table.shader_time_start], true);
> + brw->vtbl.emit_buffer_surface_state(
> +brw, &stage_state->surf_offset[
> +prog_data->binding_table.shader_time_start],
> +brw->shader_time.bo, 0, BRW_SURFACEFORMAT_RAW,
> +brw->shader_time.bo->size, 1, true);
>}
>
>uint32_t *bind = brw_state_batch(brw, AUB_TRACE_BINDING_TABLE,
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 6195d3d..d21e175 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -962,12 +962,6 @@ struct brw_context
>void (*update_null_renderbuffer_surface)(struct brw_context *brw,
>unsigned unit);
>
> -  void (*create_raw_surface)(struct brw_context *brw,
> - drm_intel_bo *bo,
> - uint32_t offset,
> - uint32_t size,
> - uint32_t *out_offset,
> - bool rw);
>void (*emit_buffer_surface_state)(struct brw_context *brw,
>  uint32_t *out_offset,
>  drm_intel_bo *bo,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index ece352b..e5f2058 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -920,9 +920,9 @@ brw_upload_abo_surfaces(struct brw_context *brw,
>drm_intel_bo *bo = intel_bufferobj_buffer(
>   brw, intel_bo, binding->Offset, intel_bo->Base.Size - 
> binding->Offset);
>
> -  brw->vtbl.create_raw_surface(brw, bo, binding->Offset,
> -   bo->size - binding->Offset,
> -   &surf_offsets[i], true);
> +  brw->vtbl.emit_buffer_surface_state(brw, &surf_offsets[i], bo,
> +  binding->Offset, 
> BRW_SURFACEFORMAT_RAW,
> +  bo->size - binding->Offset, 1, 
> true);
> }
>
> if (prog->NumAtomicBuffers)
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c 
> b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> index 24547d9..1421ac4 100644
> --- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
> @@ -370,24 +370,6 @@ gen7_update_texture_surface(struct gl_context *ctx,
>  }
>
>  /**
> - * Create a raw surface for untyped R/W access.
> - */
> -static void
> -gen7_create_raw_surface(struct brw_context *brw, drm_intel_bo *bo,
> -uint32_t offset, uint32_t size,
> -uint32_t *out_offset, bool rw)
> -{
> -   gen7_emit_buffer_surface_state(brw,
> -  out_offset,
> -  bo,
> -  offset,
> -  BRW_SURFACEFORMAT_RAW,
> -  size,
> -  1,
> -  true /* rw */);
> -}
> -
> -/**
>   * Creates a null renderbuffer surface.
>   *
>   * This is used when the shader doesn't write to any color output.  An FB
> @@ -563,6 +545,5 @@ gen7_init_vtable_surface_functions(struct brw_context 
> *brw)
> brw->vtbl.update_renderbuffer_surface = gen7_update_renderbuffer_surface;
> brw->vtbl.update_null_renderbuffer_surface =
>gen7_update_nu

Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Matt Turner
On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca  wrote:
> Anything else?

Are the classic xlib and osmesa drivers useful given that they both
have Gallium alternatives these days?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Brian Paul

On 02/27/2015 10:05 AM, Matt Turner wrote:

On Fri, Feb 27, 2015 at 7:16 AM, Jose Fonseca  wrote:

Anything else?


Are the classic xlib and osmesa drivers useful given that they both
have Gallium alternatives these days?


Yeah, I'd like to keep those.

-Brian

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


Re: [Mesa-dev] [RFC] configure.ac: Don't check for python mako module if python is not installed

2015-02-27 Thread Matt Turner
On Fri, Feb 27, 2015 at 7:27 AM, Samuel Iglesias Gonsalvez
 wrote:
> This could be the case of trying to compile a Mesa tarball (from 'make dist'
> command) in a machine without Python interpreter installed. The autogenerated
> files from mako templates were already created during tarball
> generation.
>
> In case of building from git without Python it is going to fail anyway because
> Python is not present when trying to autogenerate the files from mako
> templates.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89328
>
> Signed-off-by: Samuel Iglesias Gonsalvez 
> ---
>  configure.ac | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 22dc023..a4e6338 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -114,7 +114,12 @@ if test "x$INDENT" != "xcat"; then
>  fi
>  fi
>
> -AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
> +if test -n "$PYTHON2"; then
> +AX_CHECK_PYTHON_MAKO_MODULE(0.3.4)
> +else
> +AC_MSG_WARN([python not found - unable to check for python mako module])
> +fi
> +

For flex and bison, we check if a generated source file exists, which
is probably a good idea. That way configure will fail in a git
checkout if you don't have python.

I have in my todo list to add some remaining source files generated by
python to the autotools distribution. After we commit some version of
this patch, Emil or I should make sure that all the python-generated
code is included in the tarball.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/4] i965: Rename some PIPE_CONTROL flags

2015-02-27 Thread Ben Widawsky
I'm not really sure of the origins of the existing flag names. Modern docs have
some slightly different names. Having the correct names makes it easier to
determine if existing PIPE_CONTROL flag settings are correct, as well as making
adding new PIPE_CONTROLs easier.

This originally came up while I was trying to implement workarounds and spotted
some things called, "flush" which should have been called "invalidate."

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/brw_program.c   | 10 +-
 src/mesa/drivers/dri/i965/gen6_vs_state.c |  2 +-
 src/mesa/drivers/dri/i965/gen8_depth_state.c  |  2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |  8 
 src/mesa/drivers/dri/i965/intel_reg.h |  6 +++---
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index aed595e..70b5a62 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -195,24 +195,24 @@ brw_memory_barrier(struct gl_context *ctx, GLbitfield 
barriers)
   bits |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
 
if (barriers & GL_UNIFORM_BARRIER_BIT)
-  bits |= (PIPE_CONTROL_TC_FLUSH |
+  bits |= (PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
PIPE_CONTROL_CONST_CACHE_INVALIDATE);
 
if (barriers & GL_TEXTURE_FETCH_BARRIER_BIT)
-  bits |= PIPE_CONTROL_TC_FLUSH;
+  bits |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
 
if (barriers & GL_TEXTURE_UPDATE_BARRIER_BIT)
-  bits |= PIPE_CONTROL_WRITE_FLUSH;
+  bits |= PIPE_CONTROL_RENDER_TARGET_FLUSH;
 
if (barriers & GL_FRAMEBUFFER_BARRIER_BIT)
   bits |= (PIPE_CONTROL_DEPTH_CACHE_FLUSH |
-   PIPE_CONTROL_WRITE_FLUSH);
+   PIPE_CONTROL_RENDER_TARGET_FLUSH);
 
/* Typed surface messages are handled by the render cache on IVB, so we
 * need to flush it too.
 */
if (brw->gen == 7 && !brw->is_haswell)
-  bits |= PIPE_CONTROL_WRITE_FLUSH;
+  bits |= PIPE_CONTROL_RENDER_TARGET_FLUSH;
 
brw_emit_pipe_control_flush(brw, bits);
 }
diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c 
b/src/mesa/drivers/dri/i965/gen6_vs_state.c
index ee68ba5..35d10ef 100644
--- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
@@ -248,7 +248,7 @@ upload_vs_state(struct brw_context *brw)
 */
brw_emit_pipe_control_flush(brw,
PIPE_CONTROL_DEPTH_STALL |
-   PIPE_CONTROL_INSTRUCTION_FLUSH |
+   PIPE_CONTROL_INSTRUCTION_INVALIDATE |
PIPE_CONTROL_STATE_CACHE_INVALIDATE);
 }
 
diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c 
b/src/mesa/drivers/dri/i965/gen8_depth_state.c
index b4eb6e1..5c56d51 100644
--- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
@@ -340,7 +340,7 @@ write_pma_stall_bits(struct brw_context *brw, uint32_t 
pma_stall_bits)
 * Flush is also necessary.
 */
const uint32_t render_cache_flush =
-  ctx->Stencil._WriteEnabled ? PIPE_CONTROL_WRITE_FLUSH : 0;
+  ctx->Stencil._WriteEnabled ? PIPE_CONTROL_RENDER_TARGET_FLUSH : 0;
brw_emit_pipe_control_flush(brw,
PIPE_CONTROL_CS_STALL |
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 7b96005..f19406f 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -411,7 +411,7 @@ intel_batchbuffer_data(struct brw_context *brw,
 static void
 gen8_add_cs_stall_workaround_bits(uint32_t *flags)
 {
-   uint32_t wa_bits = PIPE_CONTROL_WRITE_FLUSH |
+   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
   PIPE_CONTROL_DEPTH_CACHE_FLUSH |
   PIPE_CONTROL_WRITE_IMMEDIATE |
   PIPE_CONTROL_WRITE_DEPTH_COUNT |
@@ -665,7 +665,7 @@ intel_batchbuffer_emit_mi_flush(struct brw_context *brw)
   OUT_BATCH(0);
   ADVANCE_BATCH();
} else {
-  int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_WRITE_FLUSH;
+  int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_RENDER_TARGET_FLUSH;
   if (brw->gen >= 6) {
  if (brw->gen == 9) {
 /* Hardware workaround: SKL
@@ -676,10 +676,10 @@ intel_batchbuffer_emit_mi_flush(struct brw_context *brw)
 brw_emit_pipe_control_flush(brw, 0);
  }
 
- flags |= PIPE_CONTROL_INSTRUCTION_FLUSH |
+ flags |= PIPE_CONTROL_INSTRUCTION_INVALIDATE |
   PIPE_CONTROL_DEPTH_CACHE_FLUSH |
   PIPE_CONTROL_VF_CACHE_INVALIDATE |
-  PIPE_CONTROL_TC_FLUSH |
+  PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
   PIPE_CONTROL_CS_STALL;
 
  if (brw->gen == 6) 

[Mesa-dev] [PATCH 3/4] i965: Prevent infinite finish_batch recursion

2015-02-27 Thread Ben Widawsky
From the comments in the code:

   Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
   sending it off.

This fixes a possible, unlikely infinite recursion in our batch flush path. More
importantly it allows me to add some code here.

The relevant part of the call chain for flush
intel_batchbuffer_flush()->brw_finish_batch(). The problem arises if anything in
the time from intel_batchbuffer_flush, until brw_finish_batch ends up calling
itself. This can happen as a result of a call to
intel_batchbuffer_begin()->intel_batchbuffer_require_space()->intel_batchbuffer_flush().

There are two possible cases today which can spawn this recursion.
1. There is a ring switch occurring (impossible, see below)
2. The ring is out of space (fairly unlikely)

brw_finish_batch() currently only has two cases where we end up calling
intel_batchbuffer_begin().
1. Query objects pre hardware contexts:
   Post hardware contexts, this is a NOP. Pre hardware contexts we did not have
   a blitter ring. As mesa does not currently use the BSD ring (and probably
   never will pre-GEN6), the only way to have a problem is a full ring (#2
   above).

2. brw_perf_monitor_finish_batch:
   Here too it's only used pre GEN6 which means no ring switches are possible,
   and so only a full ring can cause an issue.

Therefore only when we run out of ring space at batchbuffer flush do we have an
issue.

I've implemented the cheap hack to fix this. It is totally not thread safe.  The
proper way to fix this is with a lock as callers do not expect an early return
before the flush has occurred. I'm not really certain if we can ever actually
hit this path with mulththreaded situations, so cheap hack wins.

The same bug and reasoning (in fact it's more likely) may exist in the i915
driver as well.

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index db2f345..b0ebec7 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -209,6 +209,19 @@ brw_new_batch(struct brw_context *brw)
 static void
 brw_finish_batch(struct brw_context *brw)
 {
+   /* FIXME: not threadsafe */
+   static int nest_depth = 0;
+   assert (nest_depth >= 0);
+
+   if (nest_depth++) {
+  /* It's actually possible to get here without multithreading (no 
ringspace
+   * + ring switch). Oh well. */
+  if (nest_depth >= 2)
+ _mesa_warning(NULL, "Multhreaded batch flushing is out of order\n");
+
+  return;
+   }
+
/* Capture the closing pipeline statistics register values necessary to
 * support query objects (in the non-hardware context world).
 */
@@ -223,6 +236,8 @@ brw_finish_batch(struct brw_context *brw)
 * next batch.
 */
brw->cache.bo_used_by_gpu = true;
+
+   nest_depth--;
 }
 
 /* TODO: Push this whole function into bufmgr.
-- 
2.3.1

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


[Mesa-dev] [PATCH 2/4] i965/hsw: Properly handle RO state invalidation

2015-02-27 Thread Ben Widawsky
Before invalidating the "RO state" caches, we have to emit a PIPE_CONTROL...

The following is the best I can explain things as I understand them without
getting too far into the low-level details.

I believe the "read only" aspect of this is misleading. It just so happens that
the state caches are read only, but really this is about state cache coherency.
As I understand it, when invalidating any of the state caches, the internal
hardware that handles this stuff (state arbiter, sometimes referred to as sarb)
must flush and sync on any pending requests before it can send an invalidation.
Why this is needed is based on the uArch design. Essentially you can have
multiple pending requests for *things* and the invalidation must occur after
those pending things.

The result of this is the following:
   Programming Note: PIPECONTROL with RO Cache Invalidation: Prior to
   programming a PIPECONTROL command with any of the RO cache invalidation bit
   set, program a PIPECONTROL flush command with “CS stall” bit and “HDC Flush”
   bit set.

Unfortunately, there is no such thing as an "HDC Flush" bit anywhere that I can
find. AFAICT, HDC is short for H? Data Cluster. So I've settled on
PIPE_CONTROL_DATA_CACHE_INVALIDATE as the closest sounding thing.

I've put this code before the existing every 4 PIPE_CONTROL workaround because
this might emit a PIPE_CONTROL which would void the need to use that workaround.
It probably makes no difference since back to back CS stalls probably have
little measurable impact anyway - but it would be less commands.

v2: Rebased on master
Updated commit message
Filled picked a different PIPE_CONTROL flag

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
 src/mesa/drivers/dri/i965/intel_reg.h |  4 
 2 files changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index f19406f..db2f345 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -453,6 +453,17 @@ gen7_cs_stall_every_four_pipe_controls(struct brw_context 
*brw, uint32_t flags)
return 0;
 }
 
+static uint32_t
+hsw_stall_before_ro_state_cache_invalidate(struct brw_context *brw, uint32_t 
flags)
+{
+  if (brw->is_haswell && (flags & READ_ONLY_CACHE_INVALIDATIONS)) {
+ return PIPE_CONTROL_DATA_CACHE_INVALIDATE |
+PIPE_CONTROL_CS_STALL;
+  }
+
+  return 0;
+}
+
 /**
  * Emit a PIPE_CONTROL with various flushing flags.
  *
@@ -474,6 +485,7 @@ brw_emit_pipe_control_flush(struct brw_context *brw, 
uint32_t flags)
   OUT_BATCH(0);
   ADVANCE_BATCH();
} else if (brw->gen >= 6) {
+  flags |= hsw_stall_before_ro_state_cache_invalidate(brw, flags);
   flags |= gen7_cs_stall_every_four_pipe_controls(brw, flags);
 
   BEGIN_BATCH(5);
diff --git a/src/mesa/drivers/dri/i965/intel_reg.h 
b/src/mesa/drivers/dri/i965/intel_reg.h
index 488fb5b..44765ad 100644
--- a/src/mesa/drivers/dri/i965/intel_reg.h
+++ b/src/mesa/drivers/dri/i965/intel_reg.h
@@ -78,6 +78,10 @@
 #define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1 << 0)
 #define PIPE_CONTROL_PPGTT_WRITE   (0 << 2)
 #define PIPE_CONTROL_GLOBAL_GTT_WRITE  (1 << 2)
+#define READ_ONLY_CACHE_INVALIDATIONS   (PIPE_CONTROL_INSTRUCTION_INVALIDATE | 
\
+ PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE 
| \
+ PIPE_CONTROL_CONST_CACHE_INVALIDATE | 
\
+ PIPE_CONTROL_STATE_CACHE_INVALIDATE)
 
 /** @} */
 
-- 
2.3.1

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


[Mesa-dev] [PATCH 4/4] i965/hsw: Implement end of batch workaround

2015-02-27 Thread Ben Widawsky
Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index b0ebec7..e405918 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -32,6 +32,7 @@
 #include "intel_buffers.h"
 #include "intel_fbo.h"
 #include "brw_context.h"
+#include "brw_defines.h"
 
 static void
 intel_batchbuffer_reset(struct brw_context *brw);
@@ -231,6 +232,21 @@ brw_finish_batch(struct brw_context *brw)
if (brw->batch.ring == RENDER_RING)
   brw_perf_monitor_finish_batch(brw);
 
+   if (brw->is_haswell) {
+  /* SW must program 3DSTATE_CC_STATE_POINTERS command at the end of every
+   * 3D batch buffer followed by a PIPE_CONTROL with RC flush and CS stall.
+   *
+   * From the example in the docs, it seems to expect a regular pipe 
control
+   * flush here as well. We may have done it already, but meh.
+   */
+  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_RENDER_TARGET_FLUSH);
+  BEGIN_BATCH(2);
+  OUT_BATCH(_3DSTATE_CC_STATE_POINTERS << 16 | (2 - 2));
+  OUT_BATCH(brw->cc.state_offset | 1);
+  ADVANCE_BATCH();
+  intel_batchbuffer_emit_mi_flush(brw);
+   }
+
/* Mark that the current program cache BO has been used by the GPU.
 * It will be reallocated if we need to put new programs in for the
 * next batch.
-- 
2.3.1

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


Re: [Mesa-dev] [PATCH 3/4] i965: Prevent infinite finish_batch recursion

2015-02-27 Thread Ben Widawsky
On Fri, Feb 27, 2015 at 10:22:10AM -0800, Ben Widawsky wrote:
> From the comments in the code:
> 
>Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
>sending it off.
> 
> This fixes a possible, unlikely infinite recursion in our batch flush path. 
> More
> importantly it allows me to add some code here.
> 
> The relevant part of the call chain for flush
> intel_batchbuffer_flush()->brw_finish_batch(). The problem arises if anything 
> in
> the time from intel_batchbuffer_flush, until brw_finish_batch ends up calling
> itself. This can happen as a result of a call to
> intel_batchbuffer_begin()->intel_batchbuffer_require_space()->intel_batchbuffer_flush().
> 
> There are two possible cases today which can spawn this recursion.
> 1. There is a ring switch occurring (impossible, see below)
> 2. The ring is out of space (fairly unlikely)
> 
> brw_finish_batch() currently only has two cases where we end up calling
> intel_batchbuffer_begin().
> 1. Query objects pre hardware contexts:
>Post hardware contexts, this is a NOP. Pre hardware contexts we did not 
> have
>a blitter ring. As mesa does not currently use the BSD ring (and probably
>never will pre-GEN6), the only way to have a problem is a full ring (#2
>above).
> 
> 2. brw_perf_monitor_finish_batch:
>Here too it's only used pre GEN6 which means no ring switches are possible,
>and so only a full ring can cause an issue.
> 
> Therefore only when we run out of ring space at batchbuffer flush do we have 
> an
> issue.
> 
> I've implemented the cheap hack to fix this. It is totally not thread safe.  
> The
> proper way to fix this is with a lock as callers do not expect an early return
> before the flush has occurred. I'm not really certain if we can ever actually
> hit this path with mulththreaded situations, so cheap hack wins.
> 
> The same bug and reasoning (in fact it's more likely) may exist in the i915
> driver as well.
> 
> Signed-off-by: Ben Widawsky 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index db2f345..b0ebec7 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -209,6 +209,19 @@ brw_new_batch(struct brw_context *brw)
>  static void
>  brw_finish_batch(struct brw_context *brw)
>  {
> +   /* FIXME: not threadsafe */
> +   static int nest_depth = 0;
> +   assert (nest_depth >= 0);
> +
> +   if (nest_depth++) {
> +  /* It's actually possible to get here without multithreading (no 
> ringspace
> +   * + ring switch). Oh well. */
> +  if (nest_depth >= 2)
> + _mesa_warning(NULL, "Multhreaded batch flushing is out of order\n");
> +
> +  return;
> +   }
> +
> /* Capture the closing pipeline statistics register values necessary to
>  * support query objects (in the non-hardware context world).
>  */
> @@ -223,6 +236,8 @@ brw_finish_batch(struct brw_context *brw)
>  * next batch.
>  */
> brw->cache.bo_used_by_gpu = true;
> +
> +   nest_depth--;
> 

Whoops, forgot to commit.. this is nest_depth = 0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] i965: Rename some PIPE_CONTROL flags

2015-02-27 Thread Kristian Høgsberg
On Fri, Feb 27, 2015 at 10:22 AM, Ben Widawsky
 wrote:
> I'm not really sure of the origins of the existing flag names. Modern docs 
> have
> some slightly different names. Having the correct names makes it easier to
> determine if existing PIPE_CONTROL flag settings are correct, as well as 
> making
> adding new PIPE_CONTROLs easier.
>
> This originally came up while I was trying to implement workarounds and 
> spotted
> some things called, "flush" which should have been called "invalidate."

Yeah, good point.

Reviewed-by: Kristian Høgsberg 

> Signed-off-by: Ben Widawsky 
> ---
>  src/mesa/drivers/dri/i965/brw_program.c   | 10 +-
>  src/mesa/drivers/dri/i965/gen6_vs_state.c |  2 +-
>  src/mesa/drivers/dri/i965/gen8_depth_state.c  |  2 +-
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c |  8 
>  src/mesa/drivers/dri/i965/intel_reg.h |  6 +++---
>  5 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index aed595e..70b5a62 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -195,24 +195,24 @@ brw_memory_barrier(struct gl_context *ctx, GLbitfield 
> barriers)
>bits |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
>
> if (barriers & GL_UNIFORM_BARRIER_BIT)
> -  bits |= (PIPE_CONTROL_TC_FLUSH |
> +  bits |= (PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE |
> PIPE_CONTROL_CONST_CACHE_INVALIDATE);
>
> if (barriers & GL_TEXTURE_FETCH_BARRIER_BIT)
> -  bits |= PIPE_CONTROL_TC_FLUSH;
> +  bits |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
>
> if (barriers & GL_TEXTURE_UPDATE_BARRIER_BIT)
> -  bits |= PIPE_CONTROL_WRITE_FLUSH;
> +  bits |= PIPE_CONTROL_RENDER_TARGET_FLUSH;
>
> if (barriers & GL_FRAMEBUFFER_BARRIER_BIT)
>bits |= (PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> -   PIPE_CONTROL_WRITE_FLUSH);
> +   PIPE_CONTROL_RENDER_TARGET_FLUSH);
>
> /* Typed surface messages are handled by the render cache on IVB, so we
>  * need to flush it too.
>  */
> if (brw->gen == 7 && !brw->is_haswell)
> -  bits |= PIPE_CONTROL_WRITE_FLUSH;
> +  bits |= PIPE_CONTROL_RENDER_TARGET_FLUSH;
>
> brw_emit_pipe_control_flush(brw, bits);
>  }
> diff --git a/src/mesa/drivers/dri/i965/gen6_vs_state.c 
> b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> index ee68ba5..35d10ef 100644
> --- a/src/mesa/drivers/dri/i965/gen6_vs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_vs_state.c
> @@ -248,7 +248,7 @@ upload_vs_state(struct brw_context *brw)
>  */
> brw_emit_pipe_control_flush(brw,
> PIPE_CONTROL_DEPTH_STALL |
> -   PIPE_CONTROL_INSTRUCTION_FLUSH |
> +   PIPE_CONTROL_INSTRUCTION_INVALIDATE |
> PIPE_CONTROL_STATE_CACHE_INVALIDATE);
>  }
>
> diff --git a/src/mesa/drivers/dri/i965/gen8_depth_state.c 
> b/src/mesa/drivers/dri/i965/gen8_depth_state.c
> index b4eb6e1..5c56d51 100644
> --- a/src/mesa/drivers/dri/i965/gen8_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen8_depth_state.c
> @@ -340,7 +340,7 @@ write_pma_stall_bits(struct brw_context *brw, uint32_t 
> pma_stall_bits)
>  * Flush is also necessary.
>  */
> const uint32_t render_cache_flush =
> -  ctx->Stencil._WriteEnabled ? PIPE_CONTROL_WRITE_FLUSH : 0;
> +  ctx->Stencil._WriteEnabled ? PIPE_CONTROL_RENDER_TARGET_FLUSH : 0;
> brw_emit_pipe_control_flush(brw,
> PIPE_CONTROL_CS_STALL |
> PIPE_CONTROL_DEPTH_CACHE_FLUSH |
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 7b96005..f19406f 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -411,7 +411,7 @@ intel_batchbuffer_data(struct brw_context *brw,
>  static void
>  gen8_add_cs_stall_workaround_bits(uint32_t *flags)
>  {
> -   uint32_t wa_bits = PIPE_CONTROL_WRITE_FLUSH |
> +   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
>PIPE_CONTROL_DEPTH_CACHE_FLUSH |
>PIPE_CONTROL_WRITE_IMMEDIATE |
>PIPE_CONTROL_WRITE_DEPTH_COUNT |
> @@ -665,7 +665,7 @@ intel_batchbuffer_emit_mi_flush(struct brw_context *brw)
>OUT_BATCH(0);
>ADVANCE_BATCH();
> } else {
> -  int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_WRITE_FLUSH;
> +  int flags = PIPE_CONTROL_NO_WRITE | PIPE_CONTROL_RENDER_TARGET_FLUSH;
>if (brw->gen >= 6) {
>   if (brw->gen == 9) {
>  /* Hardware workaround: SKL
> @@ -676,10 +676,10 @@ intel_batchbuffer_emit_mi_flush(struct brw_context *brw)
>  brw_emit_pipe_control_flush(brw, 0);
>   }
>
> - flags |= PIPE_CONTROL_INSTRUCTION_FLUSH |
> + flags |= P

[Mesa-dev] [PATCH 4/4] [v2] i965/hsw: Implement end of batch workaround

2015-02-27 Thread Ben Widawsky
v2: Sent out the wrong patch original. This patches switches the order of
flushes, doing the generic flush before the CC_STATE, and the required
workaround flush afterwards

Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 7439cce..5bba453 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -32,6 +32,7 @@
 #include "intel_buffers.h"
 #include "intel_fbo.h"
 #include "brw_context.h"
+#include "brw_defines.h"
 
 static void
 intel_batchbuffer_reset(struct brw_context *brw);
@@ -231,6 +232,22 @@ brw_finish_batch(struct brw_context *brw)
if (brw->batch.ring == RENDER_RING)
   brw_perf_monitor_finish_batch(brw);
 
+   if (brw->is_haswell) {
+  /* SW must program 3DSTATE_CC_STATE_POINTERS command at the end of every
+   * 3D batch buffer followed by a PIPE_CONTROL with RC flush and CS stall.
+   *
+   * From the example in the docs, it seems to expect a regular pipe 
control
+   * flush here as well. We may have done it already, but meh.
+   */
+  intel_batchbuffer_emit_mi_flush(brw);
+  BEGIN_BATCH(2);
+  OUT_BATCH(_3DSTATE_CC_STATE_POINTERS << 16 | (2 - 2));
+  OUT_BATCH(brw->cc.state_offset | 1);
+  ADVANCE_BATCH();
+  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_RENDER_TARGET_FLUSH |
+   PIPE_CONTROL_CS_STALL);
+   }
+
/* Mark that the current program cache BO has been used by the GPU.
 * It will be reallocated if we need to put new programs in for the
 * next batch.
-- 
2.3.1

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


[Mesa-dev] [PATCH] gallium/auxiliary/indices: fix start param

2015-02-27 Thread Marc-André Lureau
Since commit 28f3f8d, indices generator take a start parameter. However, some
index values have been left to start at 0.

This fixes the glean/fbo test with the virgl driver.
---
 src/gallium/auxiliary/indices/u_indices_gen.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/indices/u_indices_gen.py 
b/src/gallium/auxiliary/indices/u_indices_gen.py
index 2714df8..f05b70a 100644
--- a/src/gallium/auxiliary/indices/u_indices_gen.py
+++ b/src/gallium/auxiliary/indices/u_indices_gen.py
@@ -193,7 +193,7 @@ def lineloop(intype, outtype, inpv, outpv):
 print '  for (i = start, j = 0; j < nr - 2; j+=2, i++) { '
 do_line( intype, outtype, 'out+j',  'i', 'i+1', inpv, outpv );
 print '   }'
-do_line( intype, outtype, 'out+j',  'i', '0', inpv, outpv );
+do_line( intype, outtype, 'out+j',  'i', 'start', inpv, outpv );
 postamble()
 
 def tris(intype, outtype, inpv, outpv):
@@ -218,7 +218,7 @@ def tristrip(intype, outtype, inpv, outpv):
 def trifan(intype, outtype, inpv, outpv):
 preamble(intype, outtype, inpv, outpv, prim='trifan')
 print '  for (i = start, j = 0; j < nr; j+=3, i++) { '
-do_tri( intype, outtype, 'out+j',  '0', 'i+1', 'i+2', inpv, outpv );
+do_tri( intype, outtype, 'out+j',  'start', 'i+1', 'i+2', inpv, outpv );
 print '   }'
 postamble()
 
@@ -228,9 +228,9 @@ def polygon(intype, outtype, inpv, outpv):
 preamble(intype, outtype, inpv, outpv, prim='polygon')
 print '  for (i = start, j = 0; j < nr; j+=3, i++) { '
 if inpv == FIRST:
-do_tri( intype, outtype, 'out+j',  '0', 'i+1', 'i+2', inpv, outpv );
+do_tri( intype, outtype, 'out+j',  'start', 'i+1', 'i+2', inpv, outpv 
);
 else:
-do_tri( intype, outtype, 'out+j',  'i+1', 'i+2', '0', inpv, outpv );
+do_tri( intype, outtype, 'out+j',  'i+1', 'i+2', 'start', inpv, outpv 
);
 print '   }'
 postamble()
 
-- 
2.1.0

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


[Mesa-dev] [Bug 89363] build error - error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89363

Bug ID: 89363
   Summary: build error - error: pointer of type 'void *' used in
arithmetic [-Werror=pointer-arith]
   Product: Mesa
   Version: git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: fabio@libero.it
QA Contact: mesa-dev@lists.freedesktop.org
CC: jfons...@vmware.com

I get this build error after latest today commits:
  CC   shared_glapi_libglapi_la-entry.lo
In file included from ../../../../src/mapi/entry.c:49:0:
../../../../src/mapi/entry_x86-64_tls.h: In function 'entry_generate':
../../../../src/mapi/entry_x86-64_tls.h:105:29: error: pointer of type 'void *'
used in arithmetic [-Werror=pointer-arith]
*((unsigned int *) (code + 5)) = addr;

Full build log:
https://launchpadlibrarian.net/198919571/buildlog_ubuntu-utopic-amd64.mesa_10.6~git1502271930.da85ab~gd~u_BUILDING.txt.gz

configure options:
../../configure --prefix=/usr --mandir=\${prefix}/share/man \
 --infodir=\${prefix}/share/info --sysconfdir=/etc \
 --libdir=\${prefix}/lib/x86_64-linux-gnu \
 --localstatedir=/var \
 --build=x86_64-linux-gnu --enable-dri --with-sha1=libnettle
--with-dri-drivers=" nouveau i915 i965 r200 radeon swrast"
--with-dri-driverdir=/usr/lib/x86_64-linux-gnu/dri
--with-dri-searchpath='/usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri'
--enable-osmesa --enable-glx-tls --enable-shared-glapi --enable-texture-float
--enable-driglx-direct --enable-dri3 --with-egl-platforms="x11 wayland drm"
--enable-xa --enable-gallium-llvm ac_cv_path_LLVM_CONFIG=llvm-config-3.6
--enable-vdpau --enable-omx --enable-va --enable-xvmc --enable-opencl
--enable-opencl-icd --enable-nine --enable-r600-llvm-compiler
--with-gallium-drivers=" nouveau svga swrast r600 r300 i915 ilo radeonsi"
--enable-gles1 --enable-gles2  CFLAGS="-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security  -O2 -fno-omit-frame-pointer -ggdb -g -gdwarf-2
-gstrict-dwarf" CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2
-fstack-protector-strong -Wformat -Werror=format-security  -O2
-fno-omit-frame-pointer -ggdb -g -gdwarf-2 -gstrict-dwarf" FCFLAGS="-g -O2
-fstack-protector-strong" FFLAGS="-g -O2 -fstack-protector-strong" GCJFLAGS="-g
-O2 -fstack-protector-strong" LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro"
OBJCFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security"
OBJCXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security"

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


[Mesa-dev] [Bug 89364] c99_alloca.h:40:22: fatal error: alloca.h: No such file or directory

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89364

Bug ID: 89364
   Summary: c99_alloca.h:40:22: fatal error: alloca.h: No such
file or directory
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: blocker
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

mesa: da85ab4b655a28cec33a81dae78ebe375fef9aa1 (master 10.6.0-devel)

MinGW build error

In file included from nir/nir_live_variables.c:29:0:
../../include/c99_alloca.h:40:22: fatal error: alloca.h: No such file or
directory
 #  include 
  ^

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


Re: [Mesa-dev] [PATCH 3/4] i965: Prevent infinite finish_batch recursion

2015-02-27 Thread Ben Widawsky
On Fri, Feb 27, 2015 at 10:22:10AM -0800, Ben Widawsky wrote:
> From the comments in the code:
> 
>Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
>sending it off.
> 
> This fixes a possible, unlikely infinite recursion in our batch flush path. 
> More
> importantly it allows me to add some code here.
> 
> The relevant part of the call chain for flush
> intel_batchbuffer_flush()->brw_finish_batch(). The problem arises if anything 
> in
> the time from intel_batchbuffer_flush, until brw_finish_batch ends up calling
> itself. This can happen as a result of a call to
> intel_batchbuffer_begin()->intel_batchbuffer_require_space()->intel_batchbuffer_flush().
> 
> There are two possible cases today which can spawn this recursion.
> 1. There is a ring switch occurring (impossible, see below)
> 2. The ring is out of space (fairly unlikely)

Just discussed this with krh. #2 cannot occur because of the BATCH_RESERVE. So
only case #1 is possible, and only after the next patch.

Also, there is probably a cleaner way to do this (I'm thinking modify the ring
variable in a different place), but this is cleaner, and I'd like to see if it
fixes anything first

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


[Mesa-dev] [PATCH v2 2/4] i965/fs: Make get_timestamp() return an fs_inst * rather than emitting.

2015-02-27 Thread Kenneth Graunke
This makes another part of the INTEL_DEBUG=shader_time code emittable
at arbitrary locations, rather than just at the end of the instruction
stream.

v2: Don't lose smear!  Caught by Topi Pohjolainen.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 24 +---
 src/mesa/drivers/dri/i965/brw_fs.h   |  2 +-
 2 files changed, 14 insertions(+), 12 deletions(-)

Yikes, good catch!  Thanks for the review, Topi!

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9c6f084..d65f1f1 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -680,8 +680,8 @@ fs_visitor::type_size(const struct glsl_type *type)
return 0;
 }
 
-fs_reg
-fs_visitor::get_timestamp()
+fs_inst *
+fs_visitor::timestamp_read()
 {
assert(brw->gen >= 7);
 
@@ -692,12 +692,6 @@ fs_visitor::get_timestamp()
 
fs_reg dst = fs_reg(GRF, alloc.allocate(1), BRW_REGISTER_TYPE_UD, 4);
 
-   fs_inst *mov = emit(MOV(dst, ts));
-   /* We want to read the 3 fields we care about even if it's not enabled in
-* the dispatch.
-*/
-   mov->force_writemask_all = true;
-
/* The caller wants the low 32 bits of the timestamp.  Since it's running
 * at the GPU clock rate of ~1.2ghz, it will roll over every ~3 seconds,
 * which is plenty of time for our purposes.  It is identical across the
@@ -710,14 +704,21 @@ fs_visitor::get_timestamp()
 */
dst.set_smear(0);
 
-   return dst;
+   fs_inst *mov = MOV(dst, ts);
+   /* We want to read the 3 fields we care about even if it's not enabled in
+* the dispatch.
+*/
+   mov->force_writemask_all = true;
+
+   return mov;
 }
 
 void
 fs_visitor::emit_shader_time_begin()
 {
current_annotation = "shader time start";
-   shader_start_time = get_timestamp();
+   fs_inst *tm_read = emit(timestamp_read());
+   shader_start_time = tm_read->dst;
 }
 
 void
@@ -753,7 +754,8 @@ fs_visitor::emit_shader_time_end()
   unreachable("fs_visitor::emit_shader_time_end missing code");
}
 
-   fs_reg shader_end_time = get_timestamp();
+   fs_inst *tm_read = emit(timestamp_read());
+   fs_reg shader_end_time = tm_read->dst;
 
/* Check that there weren't any timestamp reset events (assuming these
 * were the only two timestamp reads that happened).
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
b/src/mesa/drivers/dri/i965/brw_fs.h
index be1c8a1..f8044f8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -399,7 +399,7 @@ public:
void resolve_ud_negate(fs_reg *reg);
void resolve_bool_comparison(ir_rvalue *rvalue, fs_reg *reg);
 
-   fs_reg get_timestamp();
+   fs_inst *timestamp_read();
 
struct brw_reg interp_reg(int location, int channel);
void setup_uniform_values(ir_variable *ir);
-- 
2.2.2

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


[Mesa-dev] [PATCH] i965/skl: Fix the maximum thread count format for the PS

2015-02-27 Thread Neil Roberts
According to the bspec for some reason the format of the maximum
number of threads field has changed from U8-2 to U8-1 for the PS.

I've run this through Piglit and it doesn't cause any regressions.
---
 src/mesa/drivers/dri/i965/gen8_ps_state.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c 
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index d4a58e4..5f39e12 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -146,8 +146,13 @@ upload_ps_state(struct brw_context *brw)
 
/* 3DSTATE_PS expects the number of threads per PSD, which is always 64;
 * it implicitly scales for different GT levels (which have some # of PSDs).
+*
+* In Gen8 the format is U8-2 whereas in Gen9 it is U8-1.
 */
-   dw6 |= (64 - 2) << HSW_PS_MAX_THREADS_SHIFT;
+   if (brw->gen >= 9)
+  dw6 |= (64 - 1) << HSW_PS_MAX_THREADS_SHIFT;
+   else
+  dw6 |= (64 - 2) << HSW_PS_MAX_THREADS_SHIFT;
 
if (prog_data->base.nr_params > 0)
   dw6 |= GEN7_PS_PUSH_CONSTANT_ENABLE;
-- 
1.9.3

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


[Mesa-dev] [PATCH] i965/skl: Ignore the vertical alignment for the qpitch of 1D textures

2015-02-27 Thread Neil Roberts
The vertical alignment is ignored in the surface state for 1D array
textures so we can tightly pack them.

I've run this through Piglit and it doesn't cause any regressions.

(This should probably be squashed into the patch entitled “i965/skl:
Fix the qpitch value”)
---
 src/mesa/drivers/dri/i965/brw_tex_layout.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c 
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 15a0eca..2969db0 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -323,11 +323,11 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
   brw_miptree_layout_2d(mt);
 
if (layout_1d) {
-  physical_qpitch = mt->align_h;
+  physical_qpitch = 1;
   /* When using the horizontal layout the qpitch specifies the distance in
* pixels between array slices.
*/
-  mt->qpitch = physical_qpitch * mt->total_width;
+  mt->qpitch = mt->total_width;
} else if (brw->gen >= 9) {
   GLenum base_format;
 
-- 
1.9.3

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


[Mesa-dev] [PATCH 2/3] i965/fs: Consider cmod when propagating to inst with different type.

2015-02-27 Thread Matt Turner
We can safely propagate the conditional mod to an instruction with a
different type if the conditional mod does not involve comparing for
equality with zero (or probably NaN, but ignore that for now).

This is because -0.0 and +0.0 are both test equal to zero, but their
integer representations do not.

Cc: 10.5 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317
---
 .../drivers/dri/i965/brw_fs_cmod_propagation.cpp   |  8 +++
 .../drivers/dri/i965/test_fs_cmod_propagation.cpp  | 67 ++
 2 files changed, 75 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
index c6384ab..a92eef6 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
@@ -80,6 +80,14 @@ opt_cmod_propagation_local(fs_visitor *v, bblock_t *block)
 scan_inst->dst.reg_offset != inst->src[0].reg_offset)
break;
 
+/* Testing equality with zero is different for ints and floats */
+if (scan_inst->dst.type != inst->dst.type &&
+(inst->conditional_mod == BRW_CONDITIONAL_Z ||
+ inst->conditional_mod == BRW_CONDITIONAL_NZ ||
+ inst->conditional_mod == BRW_CONDITIONAL_GE ||
+ inst->conditional_mod == BRW_CONDITIONAL_LE))
+   break;
+
 /* If the instruction generating inst's source also wrote the
  * flag, and inst is doing a simple .nz comparison, then inst
  * is redundant - the appropriate value is already in the flag
diff --git a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp 
b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
index fbe4fd9..0287161 100644
--- a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
@@ -415,3 +415,70 @@ TEST_F(cmod_propagation_test, movnz)
EXPECT_EQ(BRW_OPCODE_CMP, instruction(block0, 0)->opcode);
EXPECT_EQ(BRW_CONDITIONAL_GE, instruction(block0, 0)->conditional_mod);
 }
+
+TEST_F(cmod_propagation_test, different_types)
+{
+   fs_reg dest = v->vgrf(glsl_type::int_type);
+   fs_reg src0 = v->vgrf(glsl_type::int_type);
+   fs_reg src1 = v->vgrf(glsl_type::int_type);
+   fs_reg zero(0.0f);
+   v->emit(BRW_OPCODE_ADD, dest, src0, src1);
+   v->emit(BRW_OPCODE_CMP, v->reg_null_f, retype(dest, BRW_REGISTER_TYPE_F),
+  zero)
+  ->conditional_mod = BRW_CONDITIONAL_G;
+
+   /* = Before =
+*
+* 0: add(8)dest:D  src0:D  src1:D
+* 1: cmp.g.f0(8)   null:F  dest:F  0.0f
+*
+* = After =
+* 0: add.g.f0(8)   dest:D  src0:D  src1:D
+*/
+
+   v->calculate_cfg();
+   bblock_t *block0 = v->cfg->blocks[0];
+
+   EXPECT_EQ(0, block0->start_ip);
+   EXPECT_EQ(1, block0->end_ip);
+
+   EXPECT_TRUE(cmod_propagation(v));
+   EXPECT_EQ(0, block0->start_ip);
+   EXPECT_EQ(0, block0->end_ip);
+   EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode);
+   EXPECT_EQ(BRW_CONDITIONAL_G, instruction(block0, 0)->conditional_mod);
+}
+
+TEST_F(cmod_propagation_test, different_types_cmod_with_zero)
+{
+   fs_reg dest = v->vgrf(glsl_type::int_type);
+   fs_reg src0 = v->vgrf(glsl_type::int_type);
+   fs_reg src1 = v->vgrf(glsl_type::int_type);
+   fs_reg zero(0.0f);
+   v->emit(BRW_OPCODE_ADD, dest, src0, src1);
+   v->emit(BRW_OPCODE_CMP, v->reg_null_f, retype(dest, BRW_REGISTER_TYPE_F),
+  zero)
+  ->conditional_mod = BRW_CONDITIONAL_GE;
+
+   /* = Before =
+*
+* 0: add(8)dest:D  src0:D  src1:D
+* 1: cmp.ge.f0(8)  null:F  dest:F  0.0f
+*
+* = After =
+* (no changes)
+*/
+
+   v->calculate_cfg();
+   bblock_t *block0 = v->cfg->blocks[0];
+
+   EXPECT_EQ(0, block0->start_ip);
+   EXPECT_EQ(1, block0->end_ip);
+
+   EXPECT_FALSE(cmod_propagation(v));
+   EXPECT_EQ(0, block0->start_ip);
+   EXPECT_EQ(1, block0->end_ip);
+   EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode);
+   EXPECT_EQ(BRW_OPCODE_CMP, instruction(block0, 1)->opcode);
+   EXPECT_EQ(BRW_CONDITIONAL_GE, instruction(block0, 1)->conditional_mod);
+}
-- 
2.0.5

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


[Mesa-dev] [PATCH 3/3] i965: Avoid applying negate to wrong MAD source.

2015-02-27 Thread Matt Turner
For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
function would see that one of the +'s sources was a negate expression
and set mul_negate = true without confirming that it was actually a
multiply.

Cc: 10.5 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89315
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89095
---
 src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 29 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 28 -
 2 files changed, 27 insertions(+), 30 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 13a3bf2..352c52e 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
@@ -430,21 +430,16 @@ fs_visitor::try_emit_mad(ir_expression *ir)
if (ir->type != glsl_type::float_type)
   return false;
 
-   ir_rvalue *nonmul = ir->operands[1];
-   ir_expression *mul = ir->operands[0]->as_expression();
+   ir_rvalue *nonmul;
+   ir_expression *mul;
+   bool mul_negate, mul_abs;
 
-   bool mul_negate = false, mul_abs = false;
-   if (mul && mul->operation == ir_unop_abs) {
-  mul = mul->operands[0]->as_expression();
-  mul_abs = true;
-   } else if (mul && mul->operation == ir_unop_neg) {
-  mul = mul->operands[0]->as_expression();
-  mul_negate = true;
-   }
+   for (int i = 0; i < 2; i++) {
+  mul_negate = false;
+  mul_abs = false;
 
-   if (!mul || mul->operation != ir_binop_mul) {
-  nonmul = ir->operands[0];
-  mul = ir->operands[1]->as_expression();
+  mul = ir->operands[i]->as_expression();
+  nonmul = ir->operands[1 - i];
 
   if (mul && mul->operation == ir_unop_abs) {
  mul = mul->operands[0]->as_expression();
@@ -452,12 +447,16 @@ fs_visitor::try_emit_mad(ir_expression *ir)
   } else if (mul && mul->operation == ir_unop_neg) {
  mul = mul->operands[0]->as_expression();
  mul_negate = true;
+
   }
 
-  if (!mul || mul->operation != ir_binop_mul)
- return false;
+  if (mul && mul->operation == ir_binop_mul)
+ break;
}
 
+   if (!mul || mul->operation != ir_binop_mul)
+  return false;
+
nonmul->accept(this);
fs_reg src0 = this->result;
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 0e30772..c174fdb 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1159,21 +1159,16 @@ vec4_visitor::try_emit_mad(ir_expression *ir)
if (ir->type->base_type != GLSL_TYPE_FLOAT)
   return false;
 
-   ir_rvalue *nonmul = ir->operands[1];
-   ir_expression *mul = ir->operands[0]->as_expression();
+   ir_rvalue *nonmul;
+   ir_expression *mul;
+   bool mul_negate, mul_abs;
 
-   bool mul_negate = false, mul_abs = false;
-   if (mul && mul->operation == ir_unop_abs) {
-  mul = mul->operands[0]->as_expression();
-  mul_abs = true;
-   } else if (mul && mul->operation == ir_unop_neg) {
-  mul = mul->operands[0]->as_expression();
-  mul_negate = true;
-   }
+   for (int i = 0; i < 2; i++) {
+  mul_negate = false;
+  mul_abs = false;
 
-   if (!mul || mul->operation != ir_binop_mul) {
-  nonmul = ir->operands[0];
-  mul = ir->operands[1]->as_expression();
+  mul = ir->operands[i]->as_expression();
+  nonmul = ir->operands[1 - i];
 
   if (mul && mul->operation == ir_unop_abs) {
  mul = mul->operands[0]->as_expression();
@@ -1183,10 +1178,13 @@ vec4_visitor::try_emit_mad(ir_expression *ir)
  mul_negate = true;
   }
 
-  if (!mul || mul->operation != ir_binop_mul)
- return false;
+  if (mul && mul->operation == ir_binop_mul)
+ break;
}
 
+   if (!mul || mul->operation != ir_binop_mul)
+  return false;
+
nonmul->accept(this);
src_reg src0 = fix_3src_operand(this->result);
 
-- 
2.0.5

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


[Mesa-dev] [PATCH 1/3] i965/vec4: Fix implementation of i2b.

2015-02-27 Thread Matt Turner
I broke this in commit 2881b123d. I must have misread i2b as b2i.

Cc: 10.5 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88246
---
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index f6f589d..0e30772 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -1655,7 +1655,7 @@ vec4_visitor::visit(ir_expression *ir)
   emit(CMP(result_dst, op[0], src_reg(0.0f), BRW_CONDITIONAL_NZ));
   break;
case ir_unop_i2b:
-  emit(AND(result_dst, op[0], src_reg(1)));
+  emit(CMP(result_dst, op[0], src_reg(0), BRW_CONDITIONAL_NZ));
   break;
 
case ir_unop_trunc:
-- 
2.0.5

___
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: Consider cmod when propagating to inst with different type.

2015-02-27 Thread Matt Turner
On Fri, Feb 27, 2015 at 11:34 AM, Matt Turner  wrote:
> We can safely propagate the conditional mod to an instruction with a
> different type if the conditional mod does not involve comparing for
> equality with zero (or probably NaN, but ignore that for now).
>
> This is because -0.0 and +0.0 are both test equal to zero, but their
> integer representations do not.
>
> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317
> ---

As a note -- I couldn't really confirm that the -0.0/+0.0 integer
comparison issue I described was indeed the problem reported in that
bug. It's the only thing my mind could come up with, and I couldn't
get any breakpoints to trigger in the deQP test to investigate more
what was going on.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 89364] c99_alloca.h:40:22: fatal error: alloca.h: No such file or directory

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89364

--- Comment #1 from Brian Paul  ---
The _MSC_VER check fails on MinGW.  I'll post a patch...

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


[Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.

2015-02-27 Thread Matt Turner
Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which makes
arithmetic on void pointers an error.

See https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
---
 src/mapi/entry_x86-64_tls.h | 2 +-
 src/mapi/entry_x86_tls.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
index 71e9d60..d571df9 100644
--- a/src/mapi/entry_x86-64_tls.h
+++ b/src/mapi/entry_x86-64_tls.h
@@ -88,7 +88,7 @@ entry_generate(int slot)
   0x41, 0xff, 0xa3, 0x34, 0x12, 0x00, 0x00,
};
unsigned long addr;
-   void *code;
+   char *code;
mapi_func entry;
 
addr = x86_64_current_tls();
diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
index fa7bc15..df31dce 100644
--- a/src/mapi/entry_x86_tls.h
+++ b/src/mapi/entry_x86_tls.h
@@ -113,7 +113,7 @@ entry_generate(int slot)
   0xff, 0xa0, 0x34, 0x12, 0x00, 0x00, /* jmp *0x1234(%eax) */
   0x90, 0x90, 0x90, 0x90  /* nop's */
};
-   void *code;
+   char *code;
mapi_func entry;
 
code = u_execmem_alloc(sizeof(code_templ));
-- 
2.0.5

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


Re: [Mesa-dev] [PATCH 1/2] nir: Use alloca instead of variable length arrays.

2015-02-27 Thread Kenneth Graunke
On Friday, February 27, 2015 02:04:47 PM Jose Fonseca wrote:
> On 26/02/15 18:07, Brian Paul wrote:
[snip]
> > AFAIK, there's no zeroing version of alloca().
> 
> Yes, I also searched.  And unfortunately inline functions can't be used 
> due to alloca semantics.  I'm not sure if there's any C-preprocessor magic.
> 
> 
> Anyway, depending on the maximum size of these alloca arrays, we might 
> actually need to use malloc, as Windows stack is 1MB by default, plus 
> the OpenGL driver only gets to use whatever stack is left from the 
> application.
> 
> If using C++ on NIR is acceptable, std::vector<> would be a nice 
> solution overall: practically the same syntax/semantics as C99 VLAs, 
> plus no risk of stack overflow.

We're hoping to keep it C99 - malloc and freeing them is probably the
best plan.  Thanks again!

--Ken


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] gallium/util: fix 'statement with no effect' warning

2015-02-27 Thread Brian Paul
---
 src/gallium/auxiliary/util/u_math.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_math.h 
b/src/gallium/auxiliary/util/u_math.h
index 959f76e..5400fce 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -581,8 +581,8 @@ util_bitcount(unsigned n)
 * Requires only one iteration per set bit, instead of
 * one iteration per bit less than highest set bit.
 */
-   unsigned bits = 0;
-   for (bits; n; bits++) {
+   unsigned bits;
+   for (bits = 0; n; bits++) {
   n &= n - 1;
}
return bits;
-- 
1.9.1

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


Re: [Mesa-dev] [PATCH V2 1/3] glsl: move array validation into its own function

2015-02-27 Thread Matt Turner
On Wed, Feb 25, 2015 at 11:45 PM, Timothy Arceri  wrote:
> V2: return true when var->type is unsized by max access is within valid range
>
> ---
>  src/glsl/linker.cpp | 89 
> ++---
>  src/glsl/linker.h   |  5 +++
>  2 files changed, 55 insertions(+), 39 deletions(-)
>
> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
> index 3f5eac1..dafcbe0 100644
> --- a/src/glsl/linker.cpp
> +++ b/src/glsl/linker.cpp
> @@ -680,6 +680,45 @@ validate_geometry_shader_emissions(struct gl_context 
> *ctx,
> }
>  }
>
> +bool
> +validate_intrastage_arrays(struct gl_shader_program *prog,
> +   ir_variable *const var,
> +  ir_variable *const existing)
> +{
> +   /* Consider the types to be "the same" if both types are arrays
> +* of the same type and one of the arrays is implicitly sized.
> +* In addition, set the type of the linked variable to the
> +* explicitly sized array.
> +*/
> +   if (var->type->is_array() && existing->type->is_array() &&
> +   (var->type->fields.array == existing->type->fields.array) &&
> +   ((var->type->length == 0)|| (existing->type->length == 0))) {

Space between ) and ||.

Jordan, this series is touching interface block stuff. Could you review it?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 4/5] mesa: silence unused var warning in get_tex_rgba_uncompressed()

2015-02-27 Thread Brian Paul
---
 src/mesa/main/texgetimage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 24df5b6..f975c16 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -375,7 +375,7 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint 
dimensions,
GLuint height = texImage->Height;
GLuint depth = texImage->Depth;
GLuint img;
-   GLboolean dst_is_integer = _mesa_is_enum_format_integer(format);
+   GLboolean dst_is_integer;
uint32_t dst_format;
int dst_stride;
uint8_t rebaseSwizzle[4];
@@ -423,6 +423,7 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint 
dimensions,
 * integer then transferOps do not apply.
 */
assert(!transferOps || (transferOps && !dst_is_integer));
+   (void) dst_is_integer; /* silence unused var warning */
 
for (img = 0; img < depth; img++) {
   GLubyte *srcMap;
-- 
1.9.1

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


[Mesa-dev] [PATCH] c99_alloca.h: fix #include for MinGW

2015-02-27 Thread Brian Paul
As with MSVC, include malloc.h but don't redefine alloca.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89364
---
 include/c99_alloca.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/c99_alloca.h b/include/c99_alloca.h
index 6d96d06..7a81c50 100644
--- a/include/c99_alloca.h
+++ b/include/c99_alloca.h
@@ -35,6 +35,10 @@
 
 #  define alloca _alloca
 
+#elif defined(__MINGW32__)
+
+#  include 
+
 #else /* !defined(_MSC_VER) */
 
 #  include 
-- 
1.9.1

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


[Mesa-dev] [PATCH] gallium/util: add debug_print_usage_enum() debug helper

2015-02-27 Thread Brian Paul
---
 src/gallium/auxiliary/util/u_debug.c | 19 +++
 src/gallium/auxiliary/util/u_debug.h |  3 +++
 2 files changed, 22 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_debug.c 
b/src/gallium/auxiliary/util/u_debug.c
index f54fc3a..2d2d049 100644
--- a/src/gallium/auxiliary/util/u_debug.c
+++ b/src/gallium/auxiliary/util/u_debug.c
@@ -771,4 +771,23 @@ debug_print_bind_flags(const char *msg, unsigned usage)
 }
 
 
+/**
+ * Print PIPE_USAGE_x enum values with a message.
+ */
+void
+debug_print_usage_enum(const char *msg, unsigned usage)
+{
+   static const struct debug_named_value names[] = {
+  DEBUG_NAMED_VALUE(PIPE_USAGE_DEFAULT),
+  DEBUG_NAMED_VALUE(PIPE_USAGE_IMMUTABLE),
+  DEBUG_NAMED_VALUE(PIPE_USAGE_DYNAMIC),
+  DEBUG_NAMED_VALUE(PIPE_USAGE_STREAM),
+  DEBUG_NAMED_VALUE(PIPE_USAGE_STAGING),
+  DEBUG_NAMED_VALUE_END
+   };
+
+   debug_printf("%s: %s\n", msg, debug_dump_enum(names, usage));
+}
+
+
 #endif
diff --git a/src/gallium/auxiliary/util/u_debug.h 
b/src/gallium/auxiliary/util/u_debug.h
index 5706eeb..3b22552 100644
--- a/src/gallium/auxiliary/util/u_debug.h
+++ b/src/gallium/auxiliary/util/u_debug.h
@@ -470,6 +470,9 @@ debug_print_transfer_flags(const char *msg, unsigned usage);
 void
 debug_print_bind_flags(const char *msg, unsigned usage);
 
+void
+debug_print_usage_enum(const char *msg, unsigned usage);
+
 
 #ifdef __cplusplus
 }
-- 
1.9.1

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


[Mesa-dev] [PATCH 5/5] glsl: silence uninitialized var warning on MinGW

2015-02-27 Thread Brian Paul
---
 src/glsl/opt_algebraic.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt_algebraic.cpp
index c3f3842..c6040bf 100644
--- a/src/glsl/opt_algebraic.cpp
+++ b/src/glsl/opt_algebraic.cpp
@@ -866,6 +866,7 @@ ir_algebraic_visitor::handle_expression(ir_expression *ir)
 one = new(mem_ctx) ir_constant(1.0, op2_components);
 break;
  default:
+one = NULL;
 unreachable("unexpected type");
  }
 
-- 
1.9.1

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


[Mesa-dev] [PATCH 2/5] meta: silence declaration after code warning on MinGW

2015-02-27 Thread Brian Paul
---
 src/mesa/drivers/common/meta_tex_subimage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 5ae12c8..bba2b4f 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -78,9 +78,10 @@ create_texture_for_pbo(struct gl_context *ctx, bool 
create_pbo,
   *tmp_pbo = 0;
   buffer_obj = packing->BufferObj;
} else {
-  assert(create_pbo);
   bool is_pixel_pack = pbo_target == GL_PIXEL_PACK_BUFFER;
 
+  assert(create_pbo);
+
   _mesa_GenBuffers(1, tmp_pbo);
 
   /* We are not doing this inside meta_begin/end.  However, we know the
-- 
1.9.1

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


[Mesa-dev] [PATCH 1/5] meta: silence uninitialized variable warnings for MinGW

2015-02-27 Thread Brian Paul
---
 src/mesa/drivers/common/meta_blit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 971a2ff..bb21642 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -133,6 +133,8 @@ setup_glsl_msaa_blit_scaled_shader(struct gl_context *ctx,
   sample_map = ctx->Const.SampleMap8x;
   break;
default:
+  sample_number = NULL;
+  sample_map = NULL;
   _mesa_problem(ctx, "Unsupported sample count %d\n", samples);
   unreachable("Unsupported sample count");
}
-- 
1.9.1

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


[Mesa-dev] [PATCH 3/5] mesa: move declaration before code

2015-02-27 Thread Brian Paul
To fix MinGW warning.
---
 src/mesa/main/queryobj.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index e02969d2..0842b54 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -146,12 +146,13 @@ static struct gl_query_object **
 get_pipe_stats_binding_point(struct gl_context *ctx,
  GLenum target)
 {
+   const int which = target - GL_VERTICES_SUBMITTED_ARB;
+   assert(which < MAX_PIPELINE_STATISTICS);
+
if (!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_pipeline_statistics_query)
   return NULL;
 
-   const int which = target - GL_VERTICES_SUBMITTED_ARB;
-   assert(which < MAX_PIPELINE_STATISTICS);
return &ctx->Query.pipeline_stats[which];
 }
 
-- 
1.9.1

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


Re: [Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.

2015-02-27 Thread Brian Paul


Reviewed-by: Brian Paul 

On 02/27/2015 12:48 PM, Matt Turner wrote:

Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which makes
arithmetic on void pointers an error.

See 
https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_onlinedocs_gcc_Pointer-2DArith.html&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=052IAVVedL2BjCrjLEKZyknhccNH2rRlkI7SbID7plM&s=-UFZqd1Gq_A5k0EdW7bztw7O_NkXz_AiMFNnu7FhuS4&e=
---
  src/mapi/entry_x86-64_tls.h | 2 +-
  src/mapi/entry_x86_tls.h| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
index 71e9d60..d571df9 100644
--- a/src/mapi/entry_x86-64_tls.h
+++ b/src/mapi/entry_x86-64_tls.h
@@ -88,7 +88,7 @@ entry_generate(int slot)
0x41, 0xff, 0xa3, 0x34, 0x12, 0x00, 0x00,
 };
 unsigned long addr;
-   void *code;
+   char *code;
 mapi_func entry;

 addr = x86_64_current_tls();
diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
index fa7bc15..df31dce 100644
--- a/src/mapi/entry_x86_tls.h
+++ b/src/mapi/entry_x86_tls.h
@@ -113,7 +113,7 @@ entry_generate(int slot)
0xff, 0xa0, 0x34, 0x12, 0x00, 0x00, /* jmp *0x1234(%eax) */
0x90, 0x90, 0x90, 0x90  /* nop's */
 };
-   void *code;
+   char *code;
 mapi_func entry;

 code = u_execmem_alloc(sizeof(code_templ));



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


[Mesa-dev] [PATCH] nir: Zero undefined variables when zero_undefiend_variables is set

2015-02-27 Thread Jason Ekstrand
Cc: 10.5 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
---
 src/glsl/nir/nir_lower_vars_to_ssa.c| 34 +
 src/mesa/drivers/common/meta_tex_subimage.c |  2 +-
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/src/glsl/nir/nir_lower_vars_to_ssa.c 
b/src/glsl/nir/nir_lower_vars_to_ssa.c
index 8af7530..cf88c58 100644
--- a/src/glsl/nir/nir_lower_vars_to_ssa.c
+++ b/src/glsl/nir/nir_lower_vars_to_ssa.c
@@ -675,15 +675,31 @@ get_ssa_def_for_block(struct deref_node *node, nir_block 
*block,
if (node->def_stack && node->def_stack_tail >= node->def_stack)
   return *node->def_stack_tail;
 
-   /* If we got here then we don't have a definition that dominates the
-* given block.  This means that we need to add an undef and use that.
-*/
-   nir_ssa_undef_instr *undef =
-  nir_ssa_undef_instr_create(state->mem_ctx,
- glsl_get_vector_elements(node->type));
-   nir_instr_insert_before_cf_list(&state->impl->body, &undef->instr);
-   def_stack_push(node, &undef->def, state);
-   return &undef->def;
+   nir_ssa_def *def;
+   if (getenv("zero_undefined_variables")) {
+  /* The user wants us to zero all undefined variables.  We'll do so
+   * while printing a (hopefully) helpful warning.
+   */
+  fprintf(stderr, "Undefined variable\n");
+
+  nir_load_const_instr *load =
+ nir_load_const_instr_create(state->mem_ctx,
+ glsl_get_vector_elements(node->type));
+  memset(&load->value, 0, sizeof(load->value));
+  nir_instr_insert_before_cf_list(&state->impl->body, &load->instr);
+  def = &load->def;
+   } else {
+  /* If we got here then we don't have a definition that dominates the
+   * given block.  This means that we need to add an undef and use that.
+   */
+  nir_ssa_undef_instr *undef =
+ nir_ssa_undef_instr_create(state->mem_ctx,
+glsl_get_vector_elements(node->type));
+  nir_instr_insert_before_cf_list(&state->impl->body, &undef->instr);
+  def = &undef->def;
+   }
+   def_stack_push(node, def, state);
+   return def;
 }
 
 /* Given a block and one of its predecessors, this function fills in the
diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 5ae12c8..0aeb2c9 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -312,7 +312,7 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, 
GLuint dims,
   return false;
 
/* Only stash the current FBO */
-   _mesa_meta_begin(ctx, 0);
+   _mesa_meta_begin(ctx, MESA_META_SCISSOR);
 
_mesa_GenFramebuffers(2, fbos);
 
-- 
2.3.0

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


[Mesa-dev] [PATCH] meta/TexSubImage: Stash everything other than PIXEL_TRANSFER/store in meta_begin

2015-02-27 Thread Jason Ekstrand
Cc: 10.5 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
---
 src/mesa/drivers/common/meta_tex_subimage.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 5ae12c8..802430a 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -192,8 +192,8 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint 
dims,
if (allocate_storage)
   ctx->Driver.AllocTextureImageBuffer(ctx, tex_image);
 
-   /* Only stash the current FBO */
-   _mesa_meta_begin(ctx, 0);
+   _mesa_meta_begin(ctx, ~(MESA_META_PIXEL_TRANSFER |
+   MESA_META_PIXEL_STORE));
 
_mesa_GenFramebuffers(2, fbos);
_mesa_BindFramebuffer(GL_READ_FRAMEBUFFER, fbos[0]);
@@ -311,8 +311,8 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, 
GLuint dims,
if (!pbo_tex_image)
   return false;
 
-   /* Only stash the current FBO */
-   _mesa_meta_begin(ctx, 0);
+   _mesa_meta_begin(ctx, ~(MESA_META_PIXEL_TRANSFER |
+   MESA_META_PIXEL_STORE));
 
_mesa_GenFramebuffers(2, fbos);
 
-- 
2.3.0

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


Re: [Mesa-dev] [PATCH] nir: Zero undefined variables when zero_undefiend_variables is set

2015-02-27 Thread Jason Ekstrand
NEVER MIND THIS PATCH.  I had a git-send-email fail


On Fri, Feb 27, 2015 at 12:26 PM, Jason Ekstrand 
wrote:

> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
> ---
>  src/glsl/nir/nir_lower_vars_to_ssa.c| 34
> +
>  src/mesa/drivers/common/meta_tex_subimage.c |  2 +-
>  2 files changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/src/glsl/nir/nir_lower_vars_to_ssa.c
> b/src/glsl/nir/nir_lower_vars_to_ssa.c
> index 8af7530..cf88c58 100644
> --- a/src/glsl/nir/nir_lower_vars_to_ssa.c
> +++ b/src/glsl/nir/nir_lower_vars_to_ssa.c
> @@ -675,15 +675,31 @@ get_ssa_def_for_block(struct deref_node *node,
> nir_block *block,
> if (node->def_stack && node->def_stack_tail >= node->def_stack)
>return *node->def_stack_tail;
>
> -   /* If we got here then we don't have a definition that dominates the
> -* given block.  This means that we need to add an undef and use that.
> -*/
> -   nir_ssa_undef_instr *undef =
> -  nir_ssa_undef_instr_create(state->mem_ctx,
> - glsl_get_vector_elements(node->type));
> -   nir_instr_insert_before_cf_list(&state->impl->body, &undef->instr);
> -   def_stack_push(node, &undef->def, state);
> -   return &undef->def;
> +   nir_ssa_def *def;
> +   if (getenv("zero_undefined_variables")) {
> +  /* The user wants us to zero all undefined variables.  We'll do so
> +   * while printing a (hopefully) helpful warning.
> +   */
> +  fprintf(stderr, "Undefined variable\n");
> +
> +  nir_load_const_instr *load =
> + nir_load_const_instr_create(state->mem_ctx,
> +
>  glsl_get_vector_elements(node->type));
> +  memset(&load->value, 0, sizeof(load->value));
> +  nir_instr_insert_before_cf_list(&state->impl->body, &load->instr);
> +  def = &load->def;
> +   } else {
> +  /* If we got here then we don't have a definition that dominates the
> +   * given block.  This means that we need to add an undef and use
> that.
> +   */
> +  nir_ssa_undef_instr *undef =
> + nir_ssa_undef_instr_create(state->mem_ctx,
> +glsl_get_vector_elements(node->type));
> +  nir_instr_insert_before_cf_list(&state->impl->body, &undef->instr);
> +  def = &undef->def;
> +   }
> +   def_stack_push(node, def, state);
> +   return def;
>  }
>
>  /* Given a block and one of its predecessors, this function fills in the
> diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
> b/src/mesa/drivers/common/meta_tex_subimage.c
> index 5ae12c8..0aeb2c9 100644
> --- a/src/mesa/drivers/common/meta_tex_subimage.c
> +++ b/src/mesa/drivers/common/meta_tex_subimage.c
> @@ -312,7 +312,7 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
> GLuint dims,
>return false;
>
> /* Only stash the current FBO */
> -   _mesa_meta_begin(ctx, 0);
> +   _mesa_meta_begin(ctx, MESA_META_SCISSOR);
>
> _mesa_GenFramebuffers(2, fbos);
>
> --
> 2.3.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] meta/TexSubImage: Stash everything other than PIXEL_TRANSFER/store in meta_begin

2015-02-27 Thread Jason Ekstrand
Alternatively, it's probably safe (and faster) to just save/restore the
scissor in meta_begin/end.  The _mesa_meta_BlitFramebuffer implementation
stashes everything else anyway.
--Jason

On Fri, Feb 27, 2015 at 12:29 PM, Jason Ekstrand 
wrote:

> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89292
> ---
>  src/mesa/drivers/common/meta_tex_subimage.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/common/meta_tex_subimage.c
> b/src/mesa/drivers/common/meta_tex_subimage.c
> index 5ae12c8..802430a 100644
> --- a/src/mesa/drivers/common/meta_tex_subimage.c
> +++ b/src/mesa/drivers/common/meta_tex_subimage.c
> @@ -192,8 +192,8 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx,
> GLuint dims,
> if (allocate_storage)
>ctx->Driver.AllocTextureImageBuffer(ctx, tex_image);
>
> -   /* Only stash the current FBO */
> -   _mesa_meta_begin(ctx, 0);
> +   _mesa_meta_begin(ctx, ~(MESA_META_PIXEL_TRANSFER |
> +   MESA_META_PIXEL_STORE));
>
> _mesa_GenFramebuffers(2, fbos);
> _mesa_BindFramebuffer(GL_READ_FRAMEBUFFER, fbos[0]);
> @@ -311,8 +311,8 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx,
> GLuint dims,
> if (!pbo_tex_image)
>return false;
>
> -   /* Only stash the current FBO */
> -   _mesa_meta_begin(ctx, 0);
> +   _mesa_meta_begin(ctx, ~(MESA_META_PIXEL_TRANSFER |
> +   MESA_META_PIXEL_STORE));
>
> _mesa_GenFramebuffers(2, fbos);
>
> --
> 2.3.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 89363] build error - error: pointer of type 'void *' used in arithmetic [-Werror=pointer-arith]

2015-02-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=89363

Frederik vom Hofe  changed:

   What|Removed |Added

 CC||frederik.h...@gmail.com

-- 
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] [Mesa-stable] [PATCH 1/3] i965/vec4: Fix implementation of i2b.

2015-02-27 Thread Ian Romanick
This patch is

Reviewed-by: Ian Romanick 

On 02/27/2015 11:34 AM, Matt Turner wrote:
> I broke this in commit 2881b123d. I must have misread i2b as b2i.
> 
> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88246
> ---
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index f6f589d..0e30772 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -1655,7 +1655,7 @@ vec4_visitor::visit(ir_expression *ir)
>emit(CMP(result_dst, op[0], src_reg(0.0f), BRW_CONDITIONAL_NZ));
>break;
> case ir_unop_i2b:
> -  emit(AND(result_dst, op[0], src_reg(1)));
> +  emit(CMP(result_dst, op[0], src_reg(0), BRW_CONDITIONAL_NZ));
>break;
>  
> case ir_unop_trunc:
> 

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] i965: Avoid applying negate to wrong MAD source.

2015-02-27 Thread Ian Romanick
With the tiny nit below fixed, this patch is

Reviewed-by: Ian Romanick 

On 02/27/2015 11:34 AM, Matt Turner wrote:
> For some given GLSL IR like (+ (neg x) (* 1.2 x)), the try_emit_mad
> function would see that one of the +'s sources was a negate expression
> and set mul_negate = true without confirming that it was actually a
> multiply.
> 
> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89315
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89095
> ---
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   | 29 
> +-
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 28 -
>  2 files changed, 27 insertions(+), 30 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 13a3bf2..352c52e 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -430,21 +430,16 @@ fs_visitor::try_emit_mad(ir_expression *ir)
> if (ir->type != glsl_type::float_type)
>return false;
>  
> -   ir_rvalue *nonmul = ir->operands[1];
> -   ir_expression *mul = ir->operands[0]->as_expression();
> +   ir_rvalue *nonmul;
> +   ir_expression *mul;
> +   bool mul_negate, mul_abs;
>  
> -   bool mul_negate = false, mul_abs = false;
> -   if (mul && mul->operation == ir_unop_abs) {
> -  mul = mul->operands[0]->as_expression();
> -  mul_abs = true;
> -   } else if (mul && mul->operation == ir_unop_neg) {
> -  mul = mul->operands[0]->as_expression();
> -  mul_negate = true;
> -   }
> +   for (int i = 0; i < 2; i++) {
> +  mul_negate = false;
> +  mul_abs = false;
>  
> -   if (!mul || mul->operation != ir_binop_mul) {
> -  nonmul = ir->operands[0];
> -  mul = ir->operands[1]->as_expression();
> +  mul = ir->operands[i]->as_expression();
> +  nonmul = ir->operands[1 - i];
>  
>if (mul && mul->operation == ir_unop_abs) {
>   mul = mul->operands[0]->as_expression();
> @@ -452,12 +447,16 @@ fs_visitor::try_emit_mad(ir_expression *ir)
>} else if (mul && mul->operation == ir_unop_neg) {
>   mul = mul->operands[0]->as_expression();
>   mul_negate = true;
> +

Spurious whitespace change.

>}
>  
> -  if (!mul || mul->operation != ir_binop_mul)
> - return false;
> +  if (mul && mul->operation == ir_binop_mul)
> + break;
> }
>  
> +   if (!mul || mul->operation != ir_binop_mul)
> +  return false;
> +
> nonmul->accept(this);
> fs_reg src0 = this->result;
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> index 0e30772..c174fdb 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
> @@ -1159,21 +1159,16 @@ vec4_visitor::try_emit_mad(ir_expression *ir)
> if (ir->type->base_type != GLSL_TYPE_FLOAT)
>return false;
>  
> -   ir_rvalue *nonmul = ir->operands[1];
> -   ir_expression *mul = ir->operands[0]->as_expression();
> +   ir_rvalue *nonmul;
> +   ir_expression *mul;
> +   bool mul_negate, mul_abs;
>  
> -   bool mul_negate = false, mul_abs = false;
> -   if (mul && mul->operation == ir_unop_abs) {
> -  mul = mul->operands[0]->as_expression();
> -  mul_abs = true;
> -   } else if (mul && mul->operation == ir_unop_neg) {
> -  mul = mul->operands[0]->as_expression();
> -  mul_negate = true;
> -   }
> +   for (int i = 0; i < 2; i++) {
> +  mul_negate = false;
> +  mul_abs = false;
>  
> -   if (!mul || mul->operation != ir_binop_mul) {
> -  nonmul = ir->operands[0];
> -  mul = ir->operands[1]->as_expression();
> +  mul = ir->operands[i]->as_expression();
> +  nonmul = ir->operands[1 - i];
>  
>if (mul && mul->operation == ir_unop_abs) {
>   mul = mul->operands[0]->as_expression();
> @@ -1183,10 +1178,13 @@ vec4_visitor::try_emit_mad(ir_expression *ir)
>   mul_negate = true;
>}
>  
> -  if (!mul || mul->operation != ir_binop_mul)
> - return false;
> +  if (mul && mul->operation == ir_binop_mul)
> + break;
> }
>  
> +   if (!mul || mul->operation != ir_binop_mul)
> +  return false;
> +
> nonmul->accept(this);
> src_reg src0 = fix_3src_operand(this->result);
>  
> 

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 2/3] i965/fs: Consider cmod when propagating to inst with different type.

2015-02-27 Thread Ian Romanick
On 02/27/2015 11:34 AM, Matt Turner wrote:
> We can safely propagate the conditional mod to an instruction with a
> different type if the conditional mod does not involve comparing for
> equality with zero (or probably NaN, but ignore that for now).
> 
> This is because -0.0 and +0.0 are both test equal to zero, but their
> integer representations do not.

That sounds really sketchy.  Did you try to make a stand-alone test to
reproduce the problem based on your theory?

> Cc: 10.5 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89317
> ---
>  .../drivers/dri/i965/brw_fs_cmod_propagation.cpp   |  8 +++
>  .../drivers/dri/i965/test_fs_cmod_propagation.cpp  | 67 
> ++
>  2 files changed, 75 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
> index c6384ab..a92eef6 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_cmod_propagation.cpp
> @@ -80,6 +80,14 @@ opt_cmod_propagation_local(fs_visitor *v, bblock_t *block)
>  scan_inst->dst.reg_offset != inst->src[0].reg_offset)
> break;
>  
> +/* Testing equality with zero is different for ints and floats */
> +if (scan_inst->dst.type != inst->dst.type &&
> +(inst->conditional_mod == BRW_CONDITIONAL_Z ||
> + inst->conditional_mod == BRW_CONDITIONAL_NZ ||
> + inst->conditional_mod == BRW_CONDITIONAL_GE ||
> + inst->conditional_mod == BRW_CONDITIONAL_LE))
> +   break;
> +
>  /* If the instruction generating inst's source also wrote the
>   * flag, and inst is doing a simple .nz comparison, then inst
>   * is redundant - the appropriate value is already in the flag
> diff --git a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp 
> b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> index fbe4fd9..0287161 100644
> --- a/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/test_fs_cmod_propagation.cpp
> @@ -415,3 +415,70 @@ TEST_F(cmod_propagation_test, movnz)
> EXPECT_EQ(BRW_OPCODE_CMP, instruction(block0, 0)->opcode);
> EXPECT_EQ(BRW_CONDITIONAL_GE, instruction(block0, 0)->conditional_mod);
>  }
> +
> +TEST_F(cmod_propagation_test, different_types)
> +{
> +   fs_reg dest = v->vgrf(glsl_type::int_type);
> +   fs_reg src0 = v->vgrf(glsl_type::int_type);
> +   fs_reg src1 = v->vgrf(glsl_type::int_type);
> +   fs_reg zero(0.0f);
> +   v->emit(BRW_OPCODE_ADD, dest, src0, src1);
> +   v->emit(BRW_OPCODE_CMP, v->reg_null_f, retype(dest, BRW_REGISTER_TYPE_F),
> +  zero)
> +  ->conditional_mod = BRW_CONDITIONAL_G;
> +
> +   /* = Before =
> +*
> +* 0: add(8)dest:D  src0:D  src1:D
> +* 1: cmp.g.f0(8)   null:F  dest:F  0.0f
> +*
> +* = After =
> +* 0: add.g.f0(8)   dest:D  src0:D  src1:D
> +*/
> +
> +   v->calculate_cfg();
> +   bblock_t *block0 = v->cfg->blocks[0];
> +
> +   EXPECT_EQ(0, block0->start_ip);
> +   EXPECT_EQ(1, block0->end_ip);
> +
> +   EXPECT_TRUE(cmod_propagation(v));
> +   EXPECT_EQ(0, block0->start_ip);
> +   EXPECT_EQ(0, block0->end_ip);
> +   EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode);
> +   EXPECT_EQ(BRW_CONDITIONAL_G, instruction(block0, 0)->conditional_mod);
> +}
> +
> +TEST_F(cmod_propagation_test, different_types_cmod_with_zero)
> +{
> +   fs_reg dest = v->vgrf(glsl_type::int_type);
> +   fs_reg src0 = v->vgrf(glsl_type::int_type);
> +   fs_reg src1 = v->vgrf(glsl_type::int_type);
> +   fs_reg zero(0.0f);
> +   v->emit(BRW_OPCODE_ADD, dest, src0, src1);
> +   v->emit(BRW_OPCODE_CMP, v->reg_null_f, retype(dest, BRW_REGISTER_TYPE_F),
> +  zero)
> +  ->conditional_mod = BRW_CONDITIONAL_GE;
> +
> +   /* = Before =
> +*
> +* 0: add(8)dest:D  src0:D  src1:D
> +* 1: cmp.ge.f0(8)  null:F  dest:F  0.0f
> +*
> +* = After =
> +* (no changes)
> +*/
> +
> +   v->calculate_cfg();
> +   bblock_t *block0 = v->cfg->blocks[0];
> +
> +   EXPECT_EQ(0, block0->start_ip);
> +   EXPECT_EQ(1, block0->end_ip);
> +
> +   EXPECT_FALSE(cmod_propagation(v));
> +   EXPECT_EQ(0, block0->start_ip);
> +   EXPECT_EQ(1, block0->end_ip);
> +   EXPECT_EQ(BRW_OPCODE_ADD, instruction(block0, 0)->opcode);
> +   EXPECT_EQ(BRW_OPCODE_CMP, instruction(block0, 1)->opcode);
> +   EXPECT_EQ(BRW_CONDITIONAL_GE, instruction(block0, 1)->conditional_mod);
> +}
> 

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


Re: [Mesa-dev] [PATCH v2 2/4] i965/fs: Make get_timestamp() return an fs_inst * rather than emitting.

2015-02-27 Thread Pohjolainen, Topi
On Fri, Feb 27, 2015 at 11:15:35AM -0800, Kenneth Graunke wrote:
> This makes another part of the INTEL_DEBUG=shader_time code emittable
> at arbitrary locations, rather than just at the end of the instruction
> stream.
> 
> v2: Don't lose smear!  Caught by Topi Pohjolainen.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 24 +---
>  src/mesa/drivers/dri/i965/brw_fs.h   |  2 +-
>  2 files changed, 14 insertions(+), 12 deletions(-)
> 
> Yikes, good catch!  Thanks for the review, Topi!
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 9c6f084..d65f1f1 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -680,8 +680,8 @@ fs_visitor::type_size(const struct glsl_type *type)
> return 0;
>  }
>  
> -fs_reg
> -fs_visitor::get_timestamp()
> +fs_inst *
> +fs_visitor::timestamp_read()
>  {
> assert(brw->gen >= 7);
>  
> @@ -692,12 +692,6 @@ fs_visitor::get_timestamp()
>  
> fs_reg dst = fs_reg(GRF, alloc.allocate(1), BRW_REGISTER_TYPE_UD, 4);
>  
> -   fs_inst *mov = emit(MOV(dst, ts));
> -   /* We want to read the 3 fields we care about even if it's not enabled in
> -* the dispatch.
> -*/
> -   mov->force_writemask_all = true;
> -
> /* The caller wants the low 32 bits of the timestamp.  Since it's running
>  * at the GPU clock rate of ~1.2ghz, it will roll over every ~3 seconds,
>  * which is plenty of time for our purposes.  It is identical across the
> @@ -710,14 +704,21 @@ fs_visitor::get_timestamp()
>  */
> dst.set_smear(0);
>  
> -   return dst;
> +   fs_inst *mov = MOV(dst, ts);

Previously the smear wasn't set for the destination in the instruction
itself. I had to check what set_smear() really does. It also sets stride to
zero which the original logic left to the init value of one. I guess this is
not what you intented?

> +   /* We want to read the 3 fields we care about even if it's not enabled in
> +* the dispatch.
> +*/
> +   mov->force_writemask_all = true;
> +
> +   return mov;
>  }
>  
>  void
>  fs_visitor::emit_shader_time_begin()
>  {
> current_annotation = "shader time start";
> -   shader_start_time = get_timestamp();
> +   fs_inst *tm_read = emit(timestamp_read());
> +   shader_start_time = tm_read->dst;
>  }
>  
>  void
> @@ -753,7 +754,8 @@ fs_visitor::emit_shader_time_end()
>unreachable("fs_visitor::emit_shader_time_end missing code");
> }
>  
> -   fs_reg shader_end_time = get_timestamp();
> +   fs_inst *tm_read = emit(timestamp_read());
> +   fs_reg shader_end_time = tm_read->dst;
>  
> /* Check that there weren't any timestamp reset events (assuming these
>  * were the only two timestamp reads that happened).
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h 
> b/src/mesa/drivers/dri/i965/brw_fs.h
> index be1c8a1..f8044f8 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_fs.h
> @@ -399,7 +399,7 @@ public:
> void resolve_ud_negate(fs_reg *reg);
> void resolve_bool_comparison(ir_rvalue *rvalue, fs_reg *reg);
>  
> -   fs_reg get_timestamp();
> +   fs_inst *timestamp_read();
>  
> struct brw_reg interp_reg(int location, int channel);
> void setup_uniform_values(ir_variable *ir);
> -- 
> 2.2.2
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] configure: Leverage gcc warn options to enable safe use of C99 features where possible.

2015-02-27 Thread Jose Fonseca
Sorry, this didn't pop up when I built it here.  And I'm afraid I won't have 
time to look into this today, and possibly the weekend.

If there's not an obvious fix feel free to push a commit commiting out the  
.MSVC2013_COMPAT_*FLAGS= in configure.ac

I'll act on other reviews too as soon as I can.

Jose




From: Tom Stellard 
Sent: 27 February 2015 16:21
To: Jose Fonseca
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 2/2] configure: Leverage gcc warn options to 
enable safe use of C99 features where possible.

Hi,

This patch breaks the build for me:

CFLAGS="-g" CXXFLAGS="$CFLAGS" CC="ccache gcc" CXX="ccache g++"
./autogen.sh \
--prefix=/usr/local \
--with-dri-drivers="no" \
--with-gallium-drivers="r600,radeonsi" \
--enable-glx-tls \
--enable-debug \
--enable-shared-glapi \
--with-egl-platforms=x11,drm \
--enable-gallium-egl \
--enable-gallium-gbm \
--with-llvm-prefix=/usr/local/llvm/3.7 \
--enable-gallium-drm-loader \
--enable-gallium-compute-api \
--enable-opencl-icd \
--enable-opengl \
--disable-dri3 \
--enable-texture-float \
--with-llvm-shared-libs \
--enable-opencl \
--enable-gbm

  CC   glapi_libglapi_la-entry.lo
In file included from entry.c:49:0:
entry_x86-64_tls.h: In function 'entry_generate':
entry_x86-64_tls.h:105:29: error: pointer of type 'void *' used in arithmetic 
[-Werror=pointer-arith]
*((unsigned int *) (code + 5)) = addr;
 ^
cc1: some warnings being treated as errors
Makefile:1425: recipe for target 'shared_glapi_libglapi_la-entry.lo'
failed


On Fri, Feb 27, 2015 at 07:59:47AM -0800, Ian Romanick wrote:
> I like the idea as it should prevent future thrash.  There are a couple
> comments below.
>
> On 02/26/2015 08:51 AM, Jose Fonseca wrote:
> > The main objective of this change is to enable Linux developers to use
> > more of C99 throughout Mesa, with confidence that the portions that need
> > to be built with MSVC -- and only those portions --, stay portable.
> >
> > This is achieved by using the appropriate -Werror= options only on the
> > places they need to be used.
> >
> > Unfortunately we still need MSVC 2008 on a few portions of the code
> > (namely llvmpipe and its dependencies).  I hope to eventually eliminate
> > this so that we can use C99 everywhere, but there are technical/logistic
> > challenges (specifically, newer Windows SDKs no longer bundle MSVC,
> > instead require a full installation of Visual Studio, and that has
> > hindered adoption of newer MSVC versions on our build processes.)
> > Thankfully we have more directy control over our OpenGL driver, which is
> > why we're now able to migrate to MSVC 2013 for most of the tree.
> > ---
> >  configure.ac   | 17 +
> >  src/egl/main/Makefile.am   |  1 +
> >  src/gallium/auxiliary/Makefile.am  |  7 +--
> >  src/gallium/drivers/llvmpipe/Makefile.am   |  6 --
> >  src/gallium/state_trackers/egl/Makefile.am |  3 ++-
> >  src/gallium/targets/egl-static/Makefile.am |  3 ++-
> >  src/glsl/Makefile.am   |  8 ++--
> >  src/loader/Makefile.am |  1 +
> >  src/mapi/Makefile.am   |  4 +++-
> >  src/mesa/Makefile.am   | 10 --
> >  src/util/Makefile.am   |  3 ++-
> >  11 files changed, 51 insertions(+), 12 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index 5fbb7bc..22dc023 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -263,6 +263,18 @@ if test "x$GCC" = xyes; then
> >  # gcc's builtin memcmp is slower than glibc's
> >  # 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D43052&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=tyrvqAm0EVC5AwhM7HUFBP2BLPSrfRoV_sdwABGjAPs&s=jkc8mkso0tyQ_eIVNoxTYLSLWc9UWUzC02Lg6STYlAU&e=
> >  CFLAGS="$CFLAGS -fno-builtin-memcmp"
> > +
> > +# Flags to help ensure that certain portions of the code -- and only 
> > those
> > +# portions -- can be built with MSVC:
> > +# - src/util, src/gallium/auxiliary, and src/gallium/drivers/llvmpipe 
> > needs
> > +#   to build with Windows SDK 7.0.7600, which bundles MSVC 2008
> > +# - non-Linux/Posix OpenGL portions needs to build on MSVC 2013 (which
> > +#   supports most of C99)
> > +# - the rest has no compiler compiler restrictions
> > +MSVC2013_COMPAT_CFLAGS="-Werror=vla -Werror=pointer-arith"
> > +MSVC2013_COMPAT_CXXFLAGS="-Werror=vla -Werror=pointer-arith"
> > +MSVC2008_COMPAT_CFLAGS="$MSVC2013_COMPAT_CFLAGS 
> > -Werror=declaration-after-statement"
> > +MSVC2008_COMPAT_CXXFLAGS="$MSVC2013_COMPAT_CXXFLAGS"
> >  fi
> >  if test "x$GXX" = xyes; then
> >  CXXFLAGS="$CXXFLAGS -Wall"
> > @@ -288,6 +300,11 @@ if test "x$GXX" = xyes; then
> >  CXXFLAGS="$CXXFLAGS -fno-builtin-memcmp"
> >

Re: [Mesa-dev] [PATCH 4/4] i965/fs: Don't issue FB writes for bound but unwritten color targets.

2015-02-27 Thread Jason Ekstrand
Thanks for figuring out how to do this properly.

Reviewed-by: Jason Ekstrand 

On Fri, Feb 27, 2015 at 12:06 AM, Kenneth Graunke 
wrote:

> We used to loop over all color attachments, and emit FB writes for each
> one, even if the shader didn't write to a corresponding output variable.
> Those color attachments would be filled with garbage (undefined values).
>
> Football Manager binds a framebuffer with 4 color attachments, but draws
> to it using a shader that only writes to gl_FragData[0..2].  This meant
> that color attachment 3 would be filled with garbage, resulting in
> rendering artifacts.  Now we skip writing to it, fixing rendering.
>
> Writes to gl_FragColor initialize outputs[0..nr_color_regions-1] to
> GRFs, while writes to gl_FragData[i] initialize outputs[i].
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86747
> Signed-off-by: Kenneth Graunke 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> While this should be much more correct, I wonder if more fixes are needed.
>
> It seems like the loop condition should be:
>
>for (int target = 0; target < BRW_MAX_DRAW_BUFFERS; target++)
>
> Even if we have only 1 color region, it could be attached to
> GL_COLOR_ATTACHMENT3.  (Ilia mentioned this should be legal.)
> It sure looks like that would break here (and probably always has).
> Unfortunately, fixing that means binding more NULL render targets,
> and that's complex enough I think it's best left to a follow-up series.
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> index 77e1103..dc5c2fe 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
> @@ -3646,7 +3646,7 @@ fs_visitor::emit_fb_writes()
>   do_dual_src = false;
> }
>
> -   fs_inst *inst;
> +   fs_inst *inst = NULL;
> if (do_dual_src) {
>this->current_annotation = ralloc_asprintf(this->mem_ctx,
>  "FB dual-source write");
> @@ -3654,8 +3654,12 @@ fs_visitor::emit_fb_writes()
>reg_undef, 4);
>inst->target = 0;
>prog_data->dual_src_blend = true;
> -   } else if (key->nr_color_regions > 0) {
> +   } else {
>for (int target = 0; target < key->nr_color_regions; target++) {
> + /* Skip over outputs that weren't written. */
> + if (this->outputs[target].file == BAD_FILE)
> +continue;
> +
>   this->current_annotation = ralloc_asprintf(this->mem_ctx,
>  "FB write target %d",
>  target);
> @@ -3668,7 +3672,9 @@ fs_visitor::emit_fb_writes()
>   this->output_components[target]);
>   inst->target = target;
>}
> -   } else {
> +   }
> +
> +   if (inst == NULL) {
>/* Even if there's no color buffers enabled, we still need to send
> * alpha out the pipeline to our null renderbuffer to support
> * alpha-testing, alpha-to-coverage, and so on.
> --
> 2.2.2
>
> ___
> 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 3/5] mesa: move declaration before code

2015-02-27 Thread Jose Fonseca
I think this is fine now.

We need to update SCons to be less pedantic about the 
-Wdeclaration-after-statement / -Wpointer-arith this on a per-directory-basis, 
like my recent configure.ac change. 

Jose


From: mesa-dev  on behalf of Brian Paul 

Sent: 27 February 2015 20:07
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH 3/5] mesa: move declaration before code

To fix MinGW warning.
---
 src/mesa/main/queryobj.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/queryobj.c b/src/mesa/main/queryobj.c
index e02969d2..0842b54 100644
--- a/src/mesa/main/queryobj.c
+++ b/src/mesa/main/queryobj.c
@@ -146,12 +146,13 @@ static struct gl_query_object **
 get_pipe_stats_binding_point(struct gl_context *ctx,
  GLenum target)
 {
+   const int which = target - GL_VERTICES_SUBMITTED_ARB;
+   assert(which < MAX_PIPELINE_STATISTICS);
+
if (!_mesa_is_desktop_gl(ctx) ||
!ctx->Extensions.ARB_pipeline_statistics_query)
   return NULL;

-   const int which = target - GL_VERTICES_SUBMITTED_ARB;
-   assert(which < MAX_PIPELINE_STATISTICS);
return &ctx->Query.pipeline_stats[which];
 }

--
1.9.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=wdMATjjfK8jXIMaa_U4Okqmf0L6WCqcI96sykCISLS0&s=WTPNaE_C1hNwj9EJ8u45nyhP-geoZvsndEtO0lybXJk&e=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.

2015-02-27 Thread Jose Fonseca
Thanks!

From: mesa-dev  on behalf of Matt 
Turner 
Sent: 27 February 2015 19:48
To: mesa-dev@lists.freedesktop.org
Subject: [Mesa-dev] [PATCH] mapi: Don't rely on GNU void pointer arithmetic.

Commit 79daa510c added -Werror=pointer-arith to CFLAGS, which makes
arithmetic on void pointers an error.

See 
https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_onlinedocs_gcc_Pointer-2DArith.html&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=F5WshQ5OWJAdkK-kod4m9HHW5gQilW6buTVoWFRy5h0&s=lfKj2_2croEU2khpRbtkJtTG8PoizTe7FjMDebi5nlA&e=
---
 src/mapi/entry_x86-64_tls.h | 2 +-
 src/mapi/entry_x86_tls.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mapi/entry_x86-64_tls.h b/src/mapi/entry_x86-64_tls.h
index 71e9d60..d571df9 100644
--- a/src/mapi/entry_x86-64_tls.h
+++ b/src/mapi/entry_x86-64_tls.h
@@ -88,7 +88,7 @@ entry_generate(int slot)
   0x41, 0xff, 0xa3, 0x34, 0x12, 0x00, 0x00,
};
unsigned long addr;
-   void *code;
+   char *code;
mapi_func entry;

addr = x86_64_current_tls();
diff --git a/src/mapi/entry_x86_tls.h b/src/mapi/entry_x86_tls.h
index fa7bc15..df31dce 100644
--- a/src/mapi/entry_x86_tls.h
+++ b/src/mapi/entry_x86_tls.h
@@ -113,7 +113,7 @@ entry_generate(int slot)
   0xff, 0xa0, 0x34, 0x12, 0x00, 0x00, /* jmp *0x1234(%eax) */
   0x90, 0x90, 0x90, 0x90  /* nop's */
};
-   void *code;
+   char *code;
mapi_func entry;

code = u_execmem_alloc(sizeof(code_templ));
--
2.0.5

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=F5WshQ5OWJAdkK-kod4m9HHW5gQilW6buTVoWFRy5h0&s=eWMs5WQPhojLnoe4zvNusb3X5he38G_EzAnEHy5qqls&e=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] RFC: Prune stale components

2015-02-27 Thread Emil Velikov
On 27/02/15 15:16, Jose Fonseca wrote:
> As we're gaining momentum cleanup Mesa code, I think it would help if we
> also removed some stale components.
> 
> What do people feel about removing:
> 
> - src/mesa/drivers/windows/gdi -- the old SW rasterizer for Windows -- I
> haven't used in a very long time, and given that the old SW rasterizer
> is so far behind compared gallium based softpipe/llvmpipe rasterizers,
> it's hard to imagine this will ever be useful again
> 
> - src/gallium/drivers/rbug: -- do people use it? does it work?  it
> predates apitrace GL + GUI, which sort of enables a lot of the same
> things, but without the issue of having to hit moving target, which is
> what gallium interfaces are
> 
If we're going to keep this should we move the rbug-gui tool within the
mesa tree ? It would be nice to spare some of the "sigh... it does not
build" and let you guys just use it.


> - src/gallium/state_trackers/vega/,src/mapi/vgapi/ -- OpenVG API seems
> to have dwindled away. I recall Zack himself saying that much. The code
> would still be interesting if we wanted to implement NV_path_rendering
> [1], but given the trend of the next gen graphics APIs, it seems
> unlikely that this becomes ARB or core.
> 
> - src/gallium/state_trackers/egl/ -- yeah, I know I was against it, but
> since then I discovered WGL/GLX_EXT_create_context_es_profile, and the
> odds of us (VMware) needing this again are dimmer than last time, so I
> have to admit it does seem unlikely we or anybody will need it again,
> and we can always revert it from history..
> 
> 
> Anything else?
> 
Some of the winsys/sw are used by the st/egl alone. Their nukeage will
also allow us to simplify the pipe-loader business, and hide/push some
of the mayhem from the state-trackers into that aux module :)

All that fill follow up afterwords of course.

-Emil

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


Re: [Mesa-dev] [PATCH 1/5] meta: silence uninitialized variable warnings for MinGW

2015-02-27 Thread Anuj Phogat
On Fri, Feb 27, 2015 at 12:07 PM, Brian Paul  wrote:
> ---
>  src/mesa/drivers/common/meta_blit.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/drivers/common/meta_blit.c 
> b/src/mesa/drivers/common/meta_blit.c
> index 971a2ff..bb21642 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -133,6 +133,8 @@ setup_glsl_msaa_blit_scaled_shader(struct gl_context *ctx,
>sample_map = ctx->Const.SampleMap8x;
>break;
> default:
> +  sample_number = NULL;
> +  sample_map = NULL;
>_mesa_problem(ctx, "Unsupported sample count %d\n", samples);
>unreachable("Unsupported sample count");
> }
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


[Mesa-dev] [PATCH] i965/fs/nir: Use emit_math for nir_op_fpow

2015-02-27 Thread Ian Romanick
From: Ian Romanick 

It appears that all the other instructions that need it already use it.
This one just got missed.

Signed-off-by: Ian Romanick 
Cc: "10.5" 
Cc: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
index 388e636..f15d82f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
@@ -1090,7 +1090,7 @@ fs_visitor::nir_emit_alu(nir_alu_instr *instr)
   break;
 
case nir_op_fpow:
-  inst = emit(SHADER_OPCODE_POW, result, op[0], op[1]);
+  inst = emit_math(SHADER_OPCODE_POW, result, op[0], op[1]);
   inst->saturate = instr->dest.saturate;
   break;
 
-- 
2.1.0

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


  1   2   >