Re: [Mesa-dev] [PATCH v3] nir/linker: Add the start of a pure-NIR linker for XFB

2018-07-27 Thread Timothy Arceri



On 24/07/18 23:29, Alejandro Piñeiro wrote:

From: Neil Roberts 

v2: ignore names on purpose, for consistency with other places where
 we are doing the same (Alejandro)

v3: changes proposed by Timothy Arceri, implemented by Alejandro Piñeiro:
* Remove redundant 'struct active_xfb_varying'
* Update several comments, including spec quotes if needed
* Rename struct 'active_xfb_varying_array' to 'active_xfb_varyings'
* Rename variable 'array' to 'active_varyings'
* Replace one if condition for an assert (
Signed-off-by: Alejandro Piñeiro 
---
  src/compiler/Makefile.sources   |   1 +
  src/compiler/glsl/gl_nir_link_xfb.c | 317 
  src/compiler/glsl/gl_nir_linker.h   |   3 +
  src/compiler/glsl/meson.build   |   1 +
  4 files changed, 322 insertions(+)
  create mode 100644 src/compiler/glsl/gl_nir_link_xfb.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index db4dd1e89f4..fe9f607d2b1 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -31,6 +31,7 @@ LIBGLSL_FILES = \
glsl/gl_nir_link_atomics.c \
glsl/gl_nir_link_uniform_initializers.c \
glsl/gl_nir_link_uniforms.c \
+   glsl/gl_nir_link_xfb.c \
glsl/gl_nir_linker.c \
glsl/gl_nir_linker.h \
glsl/gl_nir.h \
diff --git a/src/compiler/glsl/gl_nir_link_xfb.c 
b/src/compiler/glsl/gl_nir_link_xfb.c
new file mode 100644
index 000..4703ac43400
--- /dev/null
+++ b/src/compiler/glsl/gl_nir_link_xfb.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (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 NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "nir.h"
+#include "gl_nir_linker.h"
+#include "ir_uniform.h" /* for gl_uniform_storage */
+#include "linker_util.h"
+#include "main/context.h"
+
+/*
+ * This file does the linking of GLSL transform feedback using NIR.
+ *
+ * Note: This linking pass is currently tailored for ARB_gl_spirv needs and
+ * particularities.
+ */
+
+struct active_xfb_buffer {
+   GLuint stride;
+   GLuint num_varyings;
+};
+
+struct active_xfb_varyings {
+   unsigned num_varyings;
+   unsigned num_outputs;
+   unsigned buffer_size;
+   struct nir_variable **varyings;
+   struct active_xfb_buffer buffers[MAX_FEEDBACK_BUFFERS];
+};
+
+static unsigned
+get_num_outputs(nir_variable *var)
+{
+   return glsl_count_attribute_slots(var->type,
+ false /* is_vertex_input */);
+}
+
+static void
+add_xfb_varying(struct active_xfb_varyings *active_varyings,
+nir_variable *var)
+{
+   if (active_varyings->num_varyings >= active_varyings->buffer_size) {
+  if (active_varyings->buffer_size == 0)
+ active_varyings->buffer_size = 1;
+  else
+ active_varyings->buffer_size *= 2;
+
+  active_varyings->varyings = realloc(active_varyings->varyings,
+  sizeof(nir_variable*) *
+  active_varyings->buffer_size);
+   }
+
+   active_varyings->varyings[active_varyings->num_varyings++] = var;
+
+   active_varyings->num_outputs += get_num_outputs(var);
+}
+
+static int
+cmp_xfb_offset(const void *x_generic, const void *y_generic)
+{
+   const nir_variable *const *x = x_generic;
+   const nir_variable *const *y = y_generic;
+
+   if ((*x)->data.xfb_buffer != (*y)->data.xfb_buffer)
+  return (*x)->data.xfb_buffer - (*y)->data.xfb_buffer;
+   return (*x)->data.offset - (*y)->data.offset;
+}
+
+static void
+get_active_xfb_varyings(struct gl_shader_program *prog,
+struct active_xfb_varyings *active_varyings)
+{
+   for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
+  struct gl_linked_shader *sh = prog->_LinkedShaders[i];
+  if (sh == NULL)
+ continue;
+
+  nir_shader *nir = sh->Program->nir;
+
+  nir_foreach_variable(var, >outputs) {
+ if 

Re: [Mesa-dev] [PATCH 04/15] mesa/glspirv: Set last_vert_prog

2018-07-27 Thread Timothy Arceri



On 21/07/18 01:08, Alejandro Piñeiro wrote:

From: Neil Roberts 

---
  src/mesa/main/glspirv.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index 8ad6c373914..ba4a8253671 100644
--- a/src/mesa/main/glspirv.c
+++ b/src/mesa/main/glspirv.c
@@ -173,6 +173,13 @@ _mesa_spirv_link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
prog->_LinkedShaders[shader_type] = linked;
prog->data->linked_stages |= 1 << shader_type;
 }
+
+   int last_vert_stage =
+  util_last_bit(prog->data->linked_stages &
+(((1 << (MESA_SHADER_GEOMETRY + 1)) - 1) ^
+ ((1 << MESA_SHADER_VERTEX) - 1)));


Isn't this the same as:

   int last_vert_stage =
  util_last_bit(prog->data->linked_stages &
((1 << (MESA_SHADER_GEOMETRY + 1)) - 1));

As ((1 << MESA_SHADER_VERTEX) - 1)) == 0

If you use the above simplification this patch is:

Reviewed-by: Timothy Arceri 


+   if (last_vert_stage)
+  prog->last_vert_prog = prog->_LinkedShaders[last_vert_stage - 
1]->Program;
  }
  
  nir_shader *



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


Re: [Mesa-dev] [PATCH 05/15] spirv: Handle the SpvDecorationStream decoration

2018-07-27 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On 21/07/18 01:08, Alejandro Piñeiro wrote:

From: Neil Roberts 

This just sets the stream on the nir_variable.
---
  src/compiler/spirv/vtn_variables.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 6ff2e83515a..8dab86abd74 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1298,7 +1298,6 @@ apply_var_decoration(struct vtn_builder *b,
 case SpvDecorationMatrixStride:
 case SpvDecorationAliased:
 case SpvDecorationUniform:
-   case SpvDecorationStream:
 case SpvDecorationLinkageAttributes:
break; /* Do nothing with these here */
  
@@ -1337,6 +1336,10 @@ apply_var_decoration(struct vtn_builder *b,

var_data->offset = dec->literals[0];
break;
  
+   case SpvDecorationStream:

+  var_data->stream = dec->literals[0];
+  break;
+
 case SpvDecorationCPacked:
 case SpvDecorationSaturatedConversion:
 case SpvDecorationFuncParamAttr:


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


[Mesa-dev] [Bug 107224] Incorrect Rendering in Deus Ex: Mankind Divided in-game menu

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107224

--- Comment #8 from Timothy Arceri  ---
(In reply to Alex Smith from comment #7)
> Thanks for confirming.
> 
> It looks like we have a bug where we fail to identify Mesa properly as a
> result of compatibility profile support being added, which causes us to go
> down a path for a different driver that incorrectly adds that configuration
> option. That then persists even after switching back to an older Mesa
> version.
> 
> We're looking into what we can do here, but I can confirm it is not a Mesa
> bug.

Hmm ... I'm seeing the same issue on a i965 skylake machine that should never
have exposed compatibility profile support.

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


Re: [Mesa-dev] [PATCH v3 1/8] nir: evaluate if condition uses inside the if branches

2018-07-27 Thread Timothy Arceri

On 28/07/18 11:06, Timothy Arceri wrote:

Since we know what side of the branch we ended up on we can just
replace the use with a constant.

All the spill changes in shader-db are from Dolphin uber shaders,
despite some small regressions the change is clearly positive.

V2: insert new constant after any phis in the
 use->parent_instr->type == nir_instr_type_phi path.


Meh this was meant to be V3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v2 1/8] nir: evaluate if condition uses inside the if branches

2018-07-27 Thread Timothy Arceri
Since we know what side of the branch we ended up on we can just
replace the use with a constant.

All the spill changes in shader-db are from Dolphin uber shaders,
despite some small regressions the change is clearly positive.

V2: insert new constant after any phis in the
use->parent_instr->type == nir_instr_type_phi path.

shader-db results IVB:

total instructions in shared programs: 201 -> 9993483 (-0.06%)
instructions in affected programs: 163235 -> 157517 (-3.50%)
helped: 132
HURT: 2

total cycles in shared programs: 231670754 -> 219476091 (-5.26%)
cycles in affected programs: 143424120 -> 131229457 (-8.50%)
helped: 115
HURT: 24

total spills in shared programs: 4383 -> 4370 (-0.30%)
spills in affected programs: 1656 -> 1643 (-0.79%)
helped: 9
HURT: 18

total fills in shared programs: 4610 -> 4581 (-0.63%)
fills in affected programs: 374 -> 345 (-7.75%)
helped: 6
HURT: 0
---
 src/compiler/nir/nir_opt_if.c | 124 ++
 1 file changed, 124 insertions(+)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index b3d0bf1decb..a04e99afdba 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -369,6 +369,87 @@ opt_if_loop_terminator(nir_if *nif)
return true;
 }
 
+static void
+replace_if_condition_use_with_const(nir_src *use, unsigned nir_boolean,
+void *mem_ctx, bool if_condition)
+{
+   /* Create const */
+   nir_load_const_instr *load = nir_load_const_instr_create(mem_ctx, 1, 32);
+   load->value.u32[0] = nir_boolean;
+
+   if (if_condition) {
+  nir_instr_insert_before_cf(>parent_if->cf_node,  >instr);
+   } else if (use->parent_instr->type == nir_instr_type_phi) {
+  nir_phi_instr *cond_phi = nir_instr_as_phi(use->parent_instr);
+
+  bool UNUSED found = false;
+  nir_foreach_phi_src(phi_src, cond_phi) {
+ if (phi_src->src.ssa == use->ssa) {
+nir_instr_insert(nir_after_phis(phi_src->pred), >instr);
+found = true;
+break;
+ }
+  }
+  assert(found);
+   } else {
+  nir_instr_insert_before(use->parent_instr,  >instr);
+   }
+
+   /* Rewrite use to use const */
+   nir_src new_src = nir_src_for_ssa(>def);
+
+   if (if_condition)
+  nir_if_rewrite_condition(use->parent_if, new_src);
+   else
+  nir_instr_rewrite_src(use->parent_instr, use, new_src);
+}
+
+static bool
+evaluate_condition_use(nir_if *nif, nir_src *use_src, void *mem_ctx,
+   bool if_condition)
+{
+   bool progress = false;
+
+   nir_block *use_block;
+   if (if_condition) {
+  use_block =
+ nir_cf_node_as_block(nir_cf_node_prev(_src->parent_if->cf_node));
+   } else {
+  use_block = use_src->parent_instr->block;
+   }
+
+   if (nir_block_dominates(nir_if_first_then_block(nif), use_block)) {
+  replace_if_condition_use_with_const(use_src, NIR_TRUE, mem_ctx,
+  if_condition);
+  progress = true;
+   } else if (nir_block_dominates(nir_if_first_else_block(nif), use_block)) {
+  replace_if_condition_use_with_const(use_src, NIR_FALSE, mem_ctx,
+  if_condition);
+  progress = true;
+   }
+
+   return progress;
+}
+
+static bool
+opt_if_evaluate_condition_use(nir_if *nif, void *mem_ctx)
+{
+   bool progress = false;
+
+   /* Evaluate any uses of the if condition inside the if branches */
+   assert(nif->condition.is_ssa);
+   nir_foreach_use_safe(use_src, nif->condition.ssa) {
+  progress |= evaluate_condition_use(nif, use_src, mem_ctx, false);
+   }
+
+   nir_foreach_if_use_safe(use_src, nif->condition.ssa) {
+  if (use_src->parent_if != nif)
+ progress |= evaluate_condition_use(nif, use_src, mem_ctx, true);
+   }
+
+   return progress;
+}
+
 static bool
 opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
 {
@@ -402,6 +483,41 @@ opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
return progress;
 }
 
+/**
+ * These optimisations depend on nir_metadata_block_index and therefore must
+ * not do anything to cause the metadata to become invalid.
+ */
+static bool
+opt_if_safe_cf_list(nir_builder *b, struct exec_list *cf_list, void *mem_ctx)
+{
+   bool progress = false;
+   foreach_list_typed(nir_cf_node, cf_node, node, cf_list) {
+  switch (cf_node->type) {
+  case nir_cf_node_block:
+ break;
+
+  case nir_cf_node_if: {
+ nir_if *nif = nir_cf_node_as_if(cf_node);
+ progress |= opt_if_safe_cf_list(b, >then_list, mem_ctx);
+ progress |= opt_if_safe_cf_list(b, >else_list, mem_ctx);
+ progress |= opt_if_evaluate_condition_use(nif, mem_ctx);
+ break;
+  }
+
+  case nir_cf_node_loop: {
+ nir_loop *loop = nir_cf_node_as_loop(cf_node);
+ progress |= opt_if_safe_cf_list(b, >body, mem_ctx);
+ break;
+  }
+
+  case nir_cf_node_function:
+ unreachable("Invalid cf type");
+  }
+ 

Re: [Mesa-dev] [PATCH 1/2] intel/fs: New method for register_byte_use_pattern for fs_inst

2018-07-27 Thread Francisco Jerez
Chema Casanova  writes:

> El 27/07/18 a las 02:44, Francisco Jerez escribió:
>> Chema Casanova  writes:
>> 
>>> El 26/07/18 a las 20:02, Francisco Jerez escribió:
 Chema Casanova  writes:

> El 20/07/18 a las 22:10, Francisco Jerez escribió:
>> Chema Casanova  writes:
>>
>>> El 20/07/18 a las 00:34, Francisco Jerez escribió:
 Chema Casanova  writes:

> El 14/07/18 a las 00:14, Francisco Jerez escribió:
>> Jose Maria Casanova Crespo  writes:
>>
>>> For a register source/destination of an instruction the function 
>>> returns
>>> the read/write byte pattern of a 32-byte registers as a unsigned 
>>> int.
>>>
>>> The returned pattern takes into account the exec_size of the 
>>> instruction,
>>> the type bitsize, the stride and if the register is source or 
>>> destination.
>>>
>>> The objective of the functions if to help to know the read/written 
>>> bytes
>>> of the instructions to improve the liveness analysis for partial 
>>> read/writes.
>>>
>>> We manage special cases for 
>>> SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL
>>> and SHADER_OPCODE_BYTE_SCATTERED_WRITE because depending of the 
>>> bitsize
>>> parameter they have a different read pattern.
>>> ---
>>>  src/intel/compiler/brw_fs.cpp  | 183 
>>> +
>>>  src/intel/compiler/brw_ir_fs.h |   1 +
>>>  2 files changed, 184 insertions(+)
>>>
>>> diff --git a/src/intel/compiler/brw_fs.cpp 
>>> b/src/intel/compiler/brw_fs.cpp
>>> index 2b8363ca362..f3045c4ff6c 100644
>>> --- a/src/intel/compiler/brw_fs.cpp
>>> +++ b/src/intel/compiler/brw_fs.cpp
>>> @@ -687,6 +687,189 @@ fs_inst::is_partial_write() const
>>> this->dst.offset % REG_SIZE != 0);
>>>  }
>>>  
>>> +/**
>>> + * Returns a 32-bit uint whose bits represent if the associated 
>>> register byte
>>> + * has been read/written by the instruction. The returned pattern 
>>> takes into
>>> + * account the exec_size of the instruction, the type bitsize and 
>>> the register
>>> + * stride and the register is source or destination for the 
>>> instruction.
>>> + *
>>> + * The objective of this function is to identify which parts of 
>>> the register
>>> + * are read or written for operations that don't read/write a full 
>>> register.
>>> + * So we can identify in live range variable analysis if a partial 
>>> write has
>>> + * completelly defined the part of the register used by a partial 
>>> read. So we
>>> + * avoid extending the liveness range because all data read was 
>>> already
>>> + * defined although the wasn't completely written.
>>> + */
>>> +unsigned
>>> +fs_inst::register_byte_use_pattern(const fs_reg , boolean 
>>> is_dst) const
>>> +{
>>> +   if (is_dst) {
>
>> Please split into two functions (like fs_inst::src_read and
>> ::src_written) since that would make the call-sites of this method 
>> more
>> self-documenting than a boolean parameter.  You should be able to 
>> share
>> code by refactoring the common logic into a separate function (see 
>> below
>> for some suggestions on how that could be achieved).
>
> Sure, it would improve readability and simplifies the logic, I've 
> chosen
> dst_write_pattern and src_read_pattern.
>
>>
>>> +  /* We don't know what is written so we return the worts case 
>>> */
>>
>> "worst"
>
> Fixed.
>
>>> +  if (this->predicate && this->opcode != BRW_OPCODE_SEL)
>>> + return 0;
>>> +  /* We assume that send destinations are completely written */
>>> +  if (this->is_send_from_grf())
>>> + return ~0u;
>>
>> Some send-like instructions won't be caught by this condition, you
>> should check for this->mlen != 0 in addition.
>
> Would it be enough to check for (this->mlen > 0) and forget about
> is_send_from_grf? I am using this approach in v2 I am sending.
>

 I don't think the mlen > 0 condition would catch all cases either...
 E.g. FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD IIRC.  You probably need both
 conditions.  Sucks...
>>>
>>> That is true, so now we have the:
>>>  (this->is_send_from_grf() || this->mlen != 0)
>>>
>>> +   } else {
>>> +  /* byte_scattered_write_logical pattern of src[1] is 32-bit 

Re: [Mesa-dev] [PATCH 1/2] nir: Export deref comparison functions

2018-07-27 Thread Timothy Arceri



On 28/07/18 07:51, Caio Marcelo de Oliveira Filho wrote:

---
  src/compiler/nir/nir_deref.c  | 111 +
  src/compiler/nir/nir_deref.h  |  10 ++
  src/compiler/nir/nir_opt_copy_prop_vars.c | 145 ++
  3 files changed, 134 insertions(+), 132 deletions(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index c03acf83597..0c951279672 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -270,3 +270,114 @@ nir_fixup_deref_modes(nir_shader *shader)
}
 }
  }
+
+/** Returns true if the storage referrenced to by deref completely contains
+ * the storage referenced by sub.
+ */
+nir_deref_compare_result
+nir_compare_deref_paths(nir_deref_path *a_path,
+nir_deref_path *b_path)
+{
+   if (a_path->path[0]->var != b_path->path[0]->var)
+  return 0;
+
+   /* Start off assuming they fully compare.  We ignore equality for now.  In
+* the end, we'll determine that by containment.
+*/
+   nir_deref_compare_result result = nir_derefs_may_alias_bit |
+ nir_derefs_a_contains_b_bit |
+ nir_derefs_b_contains_a_bit;
+
+   nir_deref_instr **a_p = _path->path[1];
+   nir_deref_instr **b_p = _path->path[1];
+   while (*a_p != NULL && *b_p != NULL) {
+  nir_deref_instr *a_tail = *(a_p++);
+  nir_deref_instr *b_tail = *(b_p++);
+
+  switch (a_tail->deref_type) {
+  case nir_deref_type_array:
+  case nir_deref_type_array_wildcard: {
+ assert(b_tail->deref_type == nir_deref_type_array ||
+b_tail->deref_type == nir_deref_type_array_wildcard);
+
+ if (a_tail->deref_type == nir_deref_type_array_wildcard) {
+if (b_tail->deref_type != nir_deref_type_array_wildcard)
+   result &= ~nir_derefs_b_contains_a_bit;
+ } else if (b_tail->deref_type == nir_deref_type_array_wildcard) {
+if (a_tail->deref_type != nir_deref_type_array_wildcard)
+   result &= ~nir_derefs_a_contains_b_bit;
+ } else {
+assert(a_tail->deref_type == nir_deref_type_array &&
+   b_tail->deref_type == nir_deref_type_array);
+assert(a_tail->arr.index.is_ssa && b_tail->arr.index.is_ssa);
+
+nir_const_value *a_index_const =
+   nir_src_as_const_value(a_tail->arr.index);
+nir_const_value *b_index_const =
+   nir_src_as_const_value(b_tail->arr.index);
+if (a_index_const && b_index_const) {
+   /* If they're both direct and have different offsets, they
+* don't even alias much less anything else.
+*/
+   if (a_index_const->u32[0] != b_index_const->u32[0])
+  return 0;
+} else if (a_tail->arr.index.ssa == b_tail->arr.index.ssa) {
+   /* They're the same indirect, continue on */
+} else {
+   /* They're not the same index so we can't prove anything about
+* containment.
+*/
+   result &= ~(nir_derefs_a_contains_b_bit | 
nir_derefs_b_contains_a_bit);
+}
+ }
+ break;
+  }
+
+  case nir_deref_type_struct: {
+ /* If they're different struct members, they don't even alias */
+ if (a_tail->strct.index != b_tail->strct.index)
+return 0;
+ break;
+  }
+
+  default:
+ unreachable("Invalid deref type");
+  }
+   }
+
+   /* If a is longer than b, then it can't contain b */
+   if (*a_p != NULL)
+  result &= ~nir_derefs_a_contains_b_bit;
+   if (*b_p != NULL)
+  result &= ~nir_derefs_b_contains_a_bit;
+
+   /* If a contains b and b contains a they must be equal. */
+   if ((result & nir_derefs_a_contains_b_bit) && (result & 
nir_derefs_b_contains_a_bit))
+  result |= nir_derefs_equal_bit;
+
+   return result;
+}
+
+nir_deref_compare_result
+nir_compare_derefs(nir_deref_instr *a, nir_deref_instr *b)
+{
+   if (a == b) {
+  return nir_derefs_equal_bit | nir_derefs_may_alias_bit |
+ nir_derefs_a_contains_b_bit | nir_derefs_b_contains_a_bit;
+   }
+
+   nir_deref_path a_path, b_path;
+   nir_deref_path_init(_path, a, NULL);
+   nir_deref_path_init(_path, b, NULL);
+   assert(a_path.path[0]->deref_type == nir_deref_type_var);
+   assert(b_path.path[0]->deref_type == nir_deref_type_var);
+
+   nir_deref_compare_result result = nir_compare_deref_paths(_path, _path);
+
+   nir_deref_path_finish(_path);
+   nir_deref_path_finish(_path);
+
+   return result;
+}
+
+


Please remove the extra lines introduced at the end of the file.

Otherwise this patch is:

Reviewed-by: Timothy Arceri 



diff --git a/src/compiler/nir/nir_deref.h b/src/compiler/nir/nir_deref.h
index 6f4141aaf82..c61c3f9366f 100644
--- a/src/compiler/nir/nir_deref.h
+++ b/src/compiler/nir/nir_deref.h
@@ -54,6 +54,16 @@ 

Re: [Mesa-dev] [PATCH] xlib: fix build break from _swrast_map_soft_renderbuffer() call

2018-07-27 Thread Clayton Craft
Quoting Brian Paul (2018-07-27 14:19:13)
> We need to pass the new flip_y argument.
> ---
>  src/mesa/drivers/x11/xm_buffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/x11/xm_buffer.c 
> b/src/mesa/drivers/x11/xm_buffer.c
> index 97c7814..9c5383b 100644
> --- a/src/mesa/drivers/x11/xm_buffer.c
> +++ b/src/mesa/drivers/x11/xm_buffer.c
> @@ -506,7 +506,7 @@ xmesa_MapRenderbuffer(struct gl_context *ctx,
>  
> /* otherwise, this is an ordinary malloc-based renderbuffer */
> _swrast_map_soft_renderbuffer(ctx, rb, x, y, w, h, mode,
> - mapOut, rowStrideOut);
> + mapOut, rowStrideOut, false);
>  }
>  
>  

I've confirm that this fixes 318c265160e "mesa: GL_MESA_framebuffer_flip_y
extension [v4]", which broke the scons build test in the Intel mesa CI.

Feel free to add me to tb.

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


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


Re: [Mesa-dev] [PATCH 07/12] nir: Add an array splitting pass

2018-07-27 Thread Timothy Arceri

On 27/07/18 02:00, Jason Ekstrand wrote:

This pass looks for array variables where at least one level of the
array is never indirected and splits it into multiple smaller variables.
---
  src/compiler/nir/nir.h|   1 +
  src/compiler/nir/nir_split_vars.c | 525 ++
  2 files changed, 526 insertions(+)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 4af7166f25b..c6ed5bb5358 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2607,6 +2607,7 @@ void nir_dump_cfg(nir_shader *shader, FILE *fp);
  
  int nir_gs_count_vertices(const nir_shader *shader);
  
+bool nir_split_array_vars(nir_shader *shader, nir_variable_mode modes);

  bool nir_split_var_copies(nir_shader *shader);
  bool nir_split_per_member_structs(nir_shader *shader);
  bool nir_split_struct_vars(nir_shader *shader, nir_variable_mode modes);
diff --git a/src/compiler/nir/nir_split_vars.c 
b/src/compiler/nir/nir_split_vars.c
index 1f59ac2f5e7..394ed2be622 100644
--- a/src/compiler/nir/nir_split_vars.c
+++ b/src/compiler/nir/nir_split_vars.c
@@ -269,3 +269,528 @@ nir_split_struct_vars(nir_shader *shader, 
nir_variable_mode modes)
  
 return progress;

  }
+
+static int
+num_arrays_in_type(const struct glsl_type *type)
+{
+   int num_arrays = 0;
+   while (true) {
+  if (glsl_type_is_array(type) || glsl_type_is_matrix(type)) {
+ num_arrays++;
+ type = glsl_get_array_element(type);
+  } else if (glsl_type_is_vector_or_scalar(type)) {
+ return num_arrays;
+  } else {
+ /* Unknown type */
+ return -1;
+  }
+   }
+}
+
+static bool
+init_var_list_array_indirects(struct exec_list *vars,
+  struct hash_table *var_indirect_map,
+  void *mem_ctx)
+{
+   bool has_aoa = false;
+
+   nir_foreach_variable(var, vars) {
+  int num_arrays = num_arrays_in_type(var->type);
+  if (num_arrays > 0) {
+ BITSET_WORD *indirects = rzalloc_array(mem_ctx, BITSET_WORD,
+BITSET_WORDS(num_arrays));
+ _mesa_hash_table_insert(var_indirect_map, var, indirects);
+ has_aoa = true;
+  }
+   }
+
+   return has_aoa;
+}
+
+static void
+mark_indirects_impl(nir_function_impl *impl,
+struct hash_table *var_indirect_map,
+nir_variable_mode modes,
+void *mem_ctx)
+{
+   nir_foreach_block(block, impl) {
+  nir_foreach_instr(instr, block) {
+ if (instr->type != nir_instr_type_deref)
+continue;
+
+ nir_deref_instr *deref = nir_instr_as_deref(instr);
+ if (!(deref->mode & modes))
+continue;
+
+ if (!glsl_type_is_vector_or_scalar(deref->type))
+continue;
+
+ nir_variable *base_var = nir_deref_instr_get_variable(deref);
+ struct hash_entry *entry =
+_mesa_hash_table_search(var_indirect_map, base_var);
+ if (!entry)
+continue;
+
+ BITSET_WORD *indirects = entry->data;
+
+ nir_deref_path path;
+ nir_deref_path_init(, deref, mem_ctx);
+
+ for (unsigned i = 1; path.path[i]; i++) {
+/* We already know this is an AoA variable */
+assert(path.path[i]->deref_type == nir_deref_type_array_wildcard ||
+   path.path[i]->deref_type == nir_deref_type_array);
+
+if (path.path[i]->deref_type == nir_deref_type_array &&
+nir_src_as_const_value(path.path[i]->arr.index) == NULL)
+   BITSET_SET(indirects, i - 1);
+ }
+  }
+   }
+}
+
+struct elem {
+   struct elem *parent;
+
+   const struct glsl_type *type;
+
+   nir_variable *var;
+   struct elem *ind_child;
+   struct elem *children;
+};
+
+static void
+create_split_array_vars(struct elem *elem, struct elem *parent,
+BITSET_WORD *indirects, unsigned depth,
+const struct glsl_type *type,
+const char *name,
+struct split_var_state *state)
+{
+   *elem = (struct elem) {
+  .parent = parent,
+  .type = type,
+   };
+
+   if (glsl_type_is_vector_or_scalar(type)) {
+  const struct glsl_type *var_type = type;
+  for (struct elem *e = elem->parent; e; e = e->parent) {
+ if (e->ind_child)
+var_type = glsl_array_type(var_type, glsl_get_length(e->type));
+  }
+
+  /* We add parens to the variable name so it looks like "(foo[2][*])" so
+   * that further derefs will look like "(foo[2][*])[ssa_6]"
+   */
+  name = ralloc_asprintf(state->mem_ctx, "(%s)", name);
+
+  nir_variable_mode mode = state->base_var->data.mode;
+  if (mode == nir_var_local) {
+ elem->var = nir_local_variable_create(state->impl, var_type, name);
+  } else {
+ elem->var = nir_variable_create(state->shader, mode, var_type, name);
+  }
+   } else if 

[Mesa-dev] [PATCH] intel/isl: Avoid tiling on 16K-wide render targets

2018-07-27 Thread Nanley Chery
Fix rendering issues on BDW and SKL.

Fixes 0288fe8d0417730bdd5b3477130dd1dc32bdbcd3
("i965/miptree: Use the correct BLT pitch")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107359
Cc: 
---

We could probably add an assert when filling out the surface state, but
I think BLORP would need a non-trivial amount of work done as a
prerequisite. I'm thinking specifically of the cases where we bind a
depth buffer as a render target.

I won't be able to push anything until about a week from EOD today, so
if this does end up getting reviewed, please feel free to push it.

 src/intel/isl/isl_gen7.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
index 4fa9851233f..2d85f4b568d 100644
--- a/src/intel/isl/isl_gen7.c
+++ b/src/intel/isl/isl_gen7.c
@@ -294,6 +294,25 @@ isl_gen6_filter_tiling(const struct isl_device *dev,
 */
if (ISL_DEV_GEN(dev) < 7 && isl_format_get_layout(info->format)->bpb >= 128)
   *flags &= ~ISL_TILING_Y0_BIT;
+
+   /* From the BDW and SKL PRMs, Volume 2d,
+* RENDER_SURFACE_STATE::Width - Programming Notes:
+*
+*   A known issue exists if a primitive is rendered to the first 2 rows and
+*   last 2 columns of a 16K width surface. If any geometry is drawn inside
+*   this square it will be copied to column X=2 and X=3 (arrangement on Y
+*   position will stay the same). If any geometry exceeds the boundaries of
+*   this 2x2 region it will be drawn normally. The issue also only occurs
+*   if the surface has TileMode != Linear.
+*
+* To prevent this rendering corruption, only allow linear tiling for
+* surfaces with widths greater than 16K-2 pixels.
+*/
+   if (info->width > 16382 &&
+   info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT &&
+   (ISL_DEV_GEN(dev) == 8 || dev->info->is_skylake)) {
+  *flags &= ISL_TILING_LINEAR_BIT;
+   }
 }
 
 void
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH] i965/miptree: Fix can_blit_slice()

2018-07-27 Thread Nanley Chery
On Tue, Jul 24, 2018 at 03:28:09PM +0300, Andres Gomez wrote:
> Hi Nanley,
> 
> I'm observing regressions for SKL and BDW which doesn't seem to be
> solved with this new patch, in git master. Therefore, I've gone ahead
> and reported:
> https://bugs.freedesktop.org/show_bug.cgi?id=107359
> 

Hi Andres,

Thank you for the bug report. It turned out to be a HW issue. I'll send
a fix soon.

-Nanley

> On Mon, 2018-07-23 at 10:17 -0700, Nanley Chery wrote:
> > Satisfy the BLT engine's row pitch limitation on the destination
> > miptree. The destination miptree is untiled, so its row_pitch will be
> > slightly less than or equal to the source miptree's row_pitch. Use the
> > source miptree's row_pitch in can_blit_slice instead of its blt_pitch.
> > 
> > Fixes 0288fe8d0417730bdd5b3477130dd1dc32bdbcd3
> > ("i965/miptree: Use the correct BLT pitch")
> > 
> > Cc: 
> > Reported-by: Dylan Baker 
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index a18d5ac3624..d8e823e4826 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -3544,8 +3544,13 @@ static bool
> >  can_blit_slice(struct intel_mipmap_tree *mt,
> > unsigned int level, unsigned int slice)
> >  {
> > -   /* See intel_miptree_blit() for details on the 32k pitch limit. */
> > -   if (intel_miptree_blt_pitch(mt) >= 32768)
> > +   /* The blit destination is untiled, so its row_pitch will be slightly 
> > less
> > +* than or equal to the source's row_pitch. The BLT engine only supports
> > +* linear row pitches up to but not including 32k.
> > +*
> > +* See intel_miptree_blit() for details on the 32k pitch limit.
> > +*/
> > +   if (mt->surf.row_pitch >= 32768)
> >return false;
> >  
> > return true;
> -- 
> Br,
> 
> Andres
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] nir: Add a global dead write var removal pass

2018-07-27 Thread Caio Marcelo de Oliveira Filho
> ---
>  src/compiler/Makefile.sources  |   1 +
>  src/compiler/nir/meson.build   |   1 +
>  src/compiler/nir/nir.h |   2 +
>  src/compiler/nir/nir_opt_copy_prop_vars.c  |  67 +---
>  src/compiler/nir/nir_opt_dead_write_vars.c | 379 +
>  src/intel/compiler/brw_nir.c   |   1 +

In v2 I'll split the patch into:

- add new pass
- N patches to use new pass in drivers
- remove code from copy_prop_vars

The code itself should be good to be reviewed.


Thanks,
Caio

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


[Mesa-dev] [PATCH 2/2] nir: Add a global dead write var removal pass

2018-07-27 Thread Caio Marcelo de Oliveira Filho
Replaces the existing dead write var removal that is done as part of
nir_opt_copy_prop_vars pass. The previous pass was per-block, so
it would not remove the dead write in a program like

int total = gl_VertexIndex * 10;
float r = gl_VertexIndex;

for (int i = 0; i < total; i++) {
arr[i] = i; // DEAD.
if ((i % 2) == 0) {
arr[i] = i * 3.0;
} else {
arr[i] = i * 5.0;
}
r = arr[i];
}

out_color = vec4(r,r,r,r);

The new pass will identify the first write to arr[i] as dead and
remove it.

The pass works by walking through the control flow nodes, and traverse
the instructions keeping track of the write instructions whose
destination were not overwritten by other instructions (called "live
writes"). Reading from the destinations cause the writes to be marked
as "used". If statements and loops are handled specially to take into
account the different codepaths. The writes that are not "used" are
removed.

The reason to keep this as a separate pass is to unclutter the copy
propagation code -- as later it will be changed to also do more than
the per-block propagation.
---
 src/compiler/Makefile.sources  |   1 +
 src/compiler/nir/meson.build   |   1 +
 src/compiler/nir/nir.h |   2 +
 src/compiler/nir/nir_opt_copy_prop_vars.c  |  67 +---
 src/compiler/nir/nir_opt_dead_write_vars.c | 379 +
 src/intel/compiler/brw_nir.c   |   1 +
 6 files changed, 387 insertions(+), 64 deletions(-)
 create mode 100644 src/compiler/nir/nir_opt_dead_write_vars.c

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 908508adffb..046a2f99bd6 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -273,6 +273,7 @@ NIR_FILES = \
nir/nir_opt_cse.c \
nir/nir_opt_dce.c \
nir/nir_opt_dead_cf.c \
+   nir/nir_opt_dead_write_vars.c \
nir/nir_opt_gcm.c \
nir/nir_opt_global_to_local.c \
nir/nir_opt_if.c \
diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
index a1bb19356ce..93fd542ce7e 100644
--- a/src/compiler/nir/meson.build
+++ b/src/compiler/nir/meson.build
@@ -158,6 +158,7 @@ files_libnir = files(
   'nir_opt_cse.c',
   'nir_opt_dce.c',
   'nir_opt_dead_cf.c',
+  'nir_opt_dead_write_vars.c',
   'nir_opt_gcm.c',
   'nir_opt_global_to_local.c',
   'nir_opt_if.c',
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 2ca92e8f34e..04a3b98853b 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2919,6 +2919,8 @@ bool nir_opt_dce(nir_shader *shader);
 
 bool nir_opt_dead_cf(nir_shader *shader);
 
+bool nir_opt_dead_write_vars(nir_shader *shader);
+
 bool nir_opt_gcm(nir_shader *shader, bool value_number);
 
 bool nir_opt_if(nir_shader *shader);
diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c 
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 9fecaf0eeec..b6a5b9c2bb4 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -38,10 +38,7 @@
  *  1) Copy-propagation on variables that have indirect access.  This includes
  * propagating from indirect stores into indirect loads.
  *
- *  2) Dead code elimination of store_var and copy_var intrinsics based on
- * killed destination values.
- *
- *  3) Removal of redundant load_deref intrinsics.  We can't trust regular CSE
+ *  2) Removal of redundant load_deref intrinsics.  We can't trust regular CSE
  * to do this because it isn't aware of variable writes that may alias the
  * value and make the former load invalid.
  *
@@ -51,6 +48,8 @@
  * rapidly get out of hand.  Fortunately, for anything that is only ever
  * accessed directly, we get SSA based copy-propagation which is extremely
  * powerful so this isn't that great a loss.
+ *
+ * Removal of dead writes to variables is handled by another pass.
  */
 
 struct value {
@@ -66,7 +65,6 @@ struct copy_entry {
 
nir_instr *store_instr[4];
 
-   unsigned comps_may_be_read;
struct value src;
 
nir_deref_instr *dst;
@@ -114,44 +112,6 @@ copy_entry_remove(struct copy_prop_var_state *state, 
struct copy_entry *entry)
list_add(>link, >copy_free_list);
 }
 
-static void
-remove_dead_writes(struct copy_prop_var_state *state,
-   struct copy_entry *entry, unsigned write_mask)
-{
-   /* We're overwriting another entry.  Some of it's components may not
-* have been read yet and, if that's the case, we may be able to delete
-* some instructions but we have to be careful.
-*/
-   unsigned dead_comps = write_mask & ~entry->comps_may_be_read;
-
-   for (unsigned mask = dead_comps; mask;) {
-  unsigned i = u_bit_scan();
-
-  nir_instr *instr = entry->store_instr[i];
-
-  /* We may have already deleted it on a previous iteration */
-  if (!instr)
- continue;
-
-  /* See if this instr is used anywhere 

[Mesa-dev] [PATCH 1/2] nir: Export deref comparison functions

2018-07-27 Thread Caio Marcelo de Oliveira Filho
---
 src/compiler/nir/nir_deref.c  | 111 +
 src/compiler/nir/nir_deref.h  |  10 ++
 src/compiler/nir/nir_opt_copy_prop_vars.c | 145 ++
 3 files changed, 134 insertions(+), 132 deletions(-)

diff --git a/src/compiler/nir/nir_deref.c b/src/compiler/nir/nir_deref.c
index c03acf83597..0c951279672 100644
--- a/src/compiler/nir/nir_deref.c
+++ b/src/compiler/nir/nir_deref.c
@@ -270,3 +270,114 @@ nir_fixup_deref_modes(nir_shader *shader)
   }
}
 }
+
+/** Returns true if the storage referrenced to by deref completely contains
+ * the storage referenced by sub.
+ */
+nir_deref_compare_result
+nir_compare_deref_paths(nir_deref_path *a_path,
+nir_deref_path *b_path)
+{
+   if (a_path->path[0]->var != b_path->path[0]->var)
+  return 0;
+
+   /* Start off assuming they fully compare.  We ignore equality for now.  In
+* the end, we'll determine that by containment.
+*/
+   nir_deref_compare_result result = nir_derefs_may_alias_bit |
+ nir_derefs_a_contains_b_bit |
+ nir_derefs_b_contains_a_bit;
+
+   nir_deref_instr **a_p = _path->path[1];
+   nir_deref_instr **b_p = _path->path[1];
+   while (*a_p != NULL && *b_p != NULL) {
+  nir_deref_instr *a_tail = *(a_p++);
+  nir_deref_instr *b_tail = *(b_p++);
+
+  switch (a_tail->deref_type) {
+  case nir_deref_type_array:
+  case nir_deref_type_array_wildcard: {
+ assert(b_tail->deref_type == nir_deref_type_array ||
+b_tail->deref_type == nir_deref_type_array_wildcard);
+
+ if (a_tail->deref_type == nir_deref_type_array_wildcard) {
+if (b_tail->deref_type != nir_deref_type_array_wildcard)
+   result &= ~nir_derefs_b_contains_a_bit;
+ } else if (b_tail->deref_type == nir_deref_type_array_wildcard) {
+if (a_tail->deref_type != nir_deref_type_array_wildcard)
+   result &= ~nir_derefs_a_contains_b_bit;
+ } else {
+assert(a_tail->deref_type == nir_deref_type_array &&
+   b_tail->deref_type == nir_deref_type_array);
+assert(a_tail->arr.index.is_ssa && b_tail->arr.index.is_ssa);
+
+nir_const_value *a_index_const =
+   nir_src_as_const_value(a_tail->arr.index);
+nir_const_value *b_index_const =
+   nir_src_as_const_value(b_tail->arr.index);
+if (a_index_const && b_index_const) {
+   /* If they're both direct and have different offsets, they
+* don't even alias much less anything else.
+*/
+   if (a_index_const->u32[0] != b_index_const->u32[0])
+  return 0;
+} else if (a_tail->arr.index.ssa == b_tail->arr.index.ssa) {
+   /* They're the same indirect, continue on */
+} else {
+   /* They're not the same index so we can't prove anything about
+* containment.
+*/
+   result &= ~(nir_derefs_a_contains_b_bit | 
nir_derefs_b_contains_a_bit);
+}
+ }
+ break;
+  }
+
+  case nir_deref_type_struct: {
+ /* If they're different struct members, they don't even alias */
+ if (a_tail->strct.index != b_tail->strct.index)
+return 0;
+ break;
+  }
+
+  default:
+ unreachable("Invalid deref type");
+  }
+   }
+
+   /* If a is longer than b, then it can't contain b */
+   if (*a_p != NULL)
+  result &= ~nir_derefs_a_contains_b_bit;
+   if (*b_p != NULL)
+  result &= ~nir_derefs_b_contains_a_bit;
+
+   /* If a contains b and b contains a they must be equal. */
+   if ((result & nir_derefs_a_contains_b_bit) && (result & 
nir_derefs_b_contains_a_bit))
+  result |= nir_derefs_equal_bit;
+
+   return result;
+}
+
+nir_deref_compare_result
+nir_compare_derefs(nir_deref_instr *a, nir_deref_instr *b)
+{
+   if (a == b) {
+  return nir_derefs_equal_bit | nir_derefs_may_alias_bit |
+ nir_derefs_a_contains_b_bit | nir_derefs_b_contains_a_bit;
+   }
+
+   nir_deref_path a_path, b_path;
+   nir_deref_path_init(_path, a, NULL);
+   nir_deref_path_init(_path, b, NULL);
+   assert(a_path.path[0]->deref_type == nir_deref_type_var);
+   assert(b_path.path[0]->deref_type == nir_deref_type_var);
+
+   nir_deref_compare_result result = nir_compare_deref_paths(_path, _path);
+
+   nir_deref_path_finish(_path);
+   nir_deref_path_finish(_path);
+
+   return result;
+}
+
+
diff --git a/src/compiler/nir/nir_deref.h b/src/compiler/nir/nir_deref.h
index 6f4141aaf82..c61c3f9366f 100644
--- a/src/compiler/nir/nir_deref.h
+++ b/src/compiler/nir/nir_deref.h
@@ -54,6 +54,16 @@ unsigned nir_deref_instr_get_const_offset(nir_deref_instr 
*deref,
 nir_ssa_def *nir_build_deref_offset(nir_builder *b, nir_deref_instr *deref,
 

Re: [Mesa-dev] [PATCH] i965: Disable guardband clipping on SandyBridge for odd dimensions

2018-07-27 Thread Matt Turner
On Thu, May 24, 2018 at 4:16 AM, vadym.shovkoplias
 wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104388
> Signed-off-by: Andriy Khulap 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index b485e2c..5aa8033 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2473,6 +2473,17 @@ brw_calculate_guardband_size(uint32_t fb_width, 
> uint32_t fb_height,
>  */
> const float gb_size = GEN_GEN >= 7 ? 16384.0f : 8192.0f;
>
> +   /* Workaround: prevent gpu hangs on SandyBridge
> +* by disabling guardband clipping for odd dimensions.
> +*/
> +   if (GEN_GEN == 6 && (fb_width & 1 || fb_height & 1)) {
> +  *xmin = -1.0f;
> +  *xmax =  1.0f;
> +  *ymin = -1.0f;
> +  *ymax =  1.0f;
> +  return;
> +   }

What's the theory? That odd dimension guard band is buggy on
Sandybridge? Do we have any documentation to support that theory?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] gallium/u_vbuf: handle indirect multidraws correctly and efficiently (v2)

2018-07-27 Thread Marek Olšák
On Fri, Jul 27, 2018 at 5:08 PM, Eric Anholt  wrote:
> Marek Olšák  writes:
>
>> From: Marek Olšák 
>>
>> v2: need to do MAX{start+count} instead of MAX{count}
>> added piglit tests
>> ---
>>  src/gallium/auxiliary/util/u_vbuf.c | 199 
>>  1 file changed, 175 insertions(+), 24 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_vbuf.c 
>> b/src/gallium/auxiliary/util/u_vbuf.c
>> index 746ff1085ce..ca53e6218fd 100644
>> --- a/src/gallium/auxiliary/util/u_vbuf.c
>> +++ b/src/gallium/auxiliary/util/u_vbuf.c
>> @@ -1124,20 +1124,45 @@ static void u_vbuf_set_driver_vertex_buffers(struct 
>> u_vbuf *mgr)
>> unsigned start_slot, count;
>>
>> start_slot = ffs(mgr->dirty_real_vb_mask) - 1;
>> count = util_last_bit(mgr->dirty_real_vb_mask >> start_slot);
>>
>> pipe->set_vertex_buffers(pipe, start_slot, count,
>>  mgr->real_vertex_buffer + start_slot);
>> mgr->dirty_real_vb_mask = 0;
>>  }
>>
>> +static void
>> +u_vbuf_split_indexed_multidraw(struct u_vbuf *mgr, struct pipe_draw_info 
>> *info,
>> +   unsigned *indirect_data, unsigned stride,
>> +   unsigned draw_count)
>> +{
>> +   assert(info->index_size);
>> +   info->indirect = NULL;
>> +
>> +   for (unsigned i = 0; i < draw_count; i++) {
>> +  unsigned offset = i * stride / 4;
>> +
>> +  info->count = indirect_data[offset + 0];
>> +  info->instance_count = indirect_data[offset + 1];
>> +
>> +  if (!info->count || !info->instance_count)
>> + continue;
>> +
>> +  info->start = indirect_data[offset + 2];
>> +  info->index_bias = indirect_data[offset + 3];
>> +  info->start_instance = indirect_data[offset + 4];
>> +
>> +  u_vbuf_draw_vbo(mgr, info);
>> +   }
>> +}
>> +
>>  void u_vbuf_draw_vbo(struct u_vbuf *mgr, const struct pipe_draw_info *info)
>>  {
>> struct pipe_context *pipe = mgr->pipe;
>> int start_vertex;
>> unsigned min_index;
>> unsigned num_vertices;
>> boolean unroll_indices = FALSE;
>> const uint32_t used_vb_mask = mgr->ve->used_vb_mask;
>> uint32_t user_vb_mask = mgr->user_vb_mask & used_vb_mask;
>> const uint32_t incompatible_vb_mask =
>> @@ -1153,47 +1178,172 @@ void u_vbuf_draw_vbo(struct u_vbuf *mgr, const 
>> struct pipe_draw_info *info)
>>if (mgr->dirty_real_vb_mask & used_vb_mask) {
>>   u_vbuf_set_driver_vertex_buffers(mgr);
>>}
>>
>>pipe->draw_vbo(pipe, info);
>>return;
>> }
>>
>> new_info = *info;
>>
>> -   /* Fallback. We need to know all the parameters. */
>> +   /* Handle indirect (multi)draws. */
>> if (new_info.indirect) {
>> -  struct pipe_transfer *transfer = NULL;
>> -  int *data;
>> -
>> -  if (new_info.index_size) {
>> - data = pipe_buffer_map_range(pipe, new_info.indirect->buffer,
>> -  new_info.indirect->offset, 20,
>> -  PIPE_TRANSFER_READ, );
>> - new_info.index_bias = data[3];
>> - new_info.start_instance = data[4];
>> -  }
>> -  else {
>> - data = pipe_buffer_map_range(pipe, new_info.indirect->buffer,
>> -  new_info.indirect->offset, 16,
>> -  PIPE_TRANSFER_READ, );
>> - new_info.start_instance = data[3];
>> +  const struct pipe_draw_indirect_info *indirect = new_info.indirect;
>> +  unsigned draw_count = 0;
>> +
>> +  /* Get the number of draws. */
>> +  if (indirect->indirect_draw_count) {
>> + pipe_buffer_read(pipe, indirect->indirect_draw_count,
>> +  indirect->indirect_draw_count_offset,
>> +  4, _count);
>> +  } else {
>> + draw_count = indirect->draw_count;
>>}
>>
>> -  new_info.count = data[0];
>> -  new_info.instance_count = data[1];
>> -  new_info.start = data[2];
>> -  pipe_buffer_unmap(pipe, transfer);
>> -  new_info.indirect = NULL;
>> -
>> -  if (!new_info.count)
>> +  if (!draw_count)
>>   return;
>> +
>> +  unsigned data_size = (draw_count - 1) * indirect->stride +
>> +   (new_info.index_size ? 20 : 16);
>> +  unsigned *data = alloca(data_size);
>
> I continue to believe that alloca isn't something we should be using on
> unbounded data_size like this.  We should be returing GL_OUT_OF_MEMORY
> when we fail, not segfaulting.
>
> We're already reading back the BOs, it's not like the allocation is a
> performance concern at this point.

radeonsi has optimizations where reading back BOs has no performance
impact other than reading from uncached memory, i.e. no sync and no
mmap overhead. In that case, malloc can make a difference. I agree
that it may be a little harder to justify considering the other things
that u_vbuf does.

Marek
___
mesa-dev 

[Mesa-dev] [PATCH] xlib: fix build break from _swrast_map_soft_renderbuffer() call

2018-07-27 Thread Brian Paul
We need to pass the new flip_y argument.
---
 src/mesa/drivers/x11/xm_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/x11/xm_buffer.c b/src/mesa/drivers/x11/xm_buffer.c
index 97c7814..9c5383b 100644
--- a/src/mesa/drivers/x11/xm_buffer.c
+++ b/src/mesa/drivers/x11/xm_buffer.c
@@ -506,7 +506,7 @@ xmesa_MapRenderbuffer(struct gl_context *ctx,
 
/* otherwise, this is an ordinary malloc-based renderbuffer */
_swrast_map_soft_renderbuffer(ctx, rb, x, y, w, h, mode,
- mapOut, rowStrideOut);
+ mapOut, rowStrideOut, false);
 }
 
 
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] gallium/auxiliary: Extern "c" fixes.

2018-07-27 Thread Brian Paul



Reviewed-by: Brian Paul 

On 07/27/2018 02:20 PM, Alexander von Gluck IV wrote:

Used by C++ code such as Haiku's renderer.
---
  src/gallium/auxiliary/driver_ddebug/dd_public.h  | 8 
  src/gallium/auxiliary/driver_noop/noop_public.h  | 8 
  .../auxiliary/target-helpers/inline_debug_helper.h   | 9 -
  3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_public.h 
b/src/gallium/auxiliary/driver_ddebug/dd_public.h
index e660765575..31c139d6a1 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_public.h
+++ b/src/gallium/auxiliary/driver_ddebug/dd_public.h
@@ -30,7 +30,15 @@
  
  struct pipe_screen;
  
+#ifdef __cplusplus

+extern "C" {
+#endif
+
  struct pipe_screen *
  ddebug_screen_create(struct pipe_screen *screen);
  
+#ifdef __cplusplus

+}
+#endif
+
  #endif /* DD_PUBLIC_H_ */
diff --git a/src/gallium/auxiliary/driver_noop/noop_public.h 
b/src/gallium/auxiliary/driver_noop/noop_public.h
index 180ea597fa..46a7f4084f 100644
--- a/src/gallium/auxiliary/driver_noop/noop_public.h
+++ b/src/gallium/auxiliary/driver_noop/noop_public.h
@@ -23,7 +23,15 @@
  #ifndef NOOP_PUBLIC_H
  #define NOOP_PUBLIC_H
  
+#ifdef __cplusplus

+extern "C" {
+#endif
+
  struct pipe_screen;
  struct pipe_screen *noop_screen_create(struct pipe_screen *screen);
  
+#ifdef __cplusplus

+}
+#endif
+
  #endif
diff --git a/src/gallium/auxiliary/target-helpers/inline_debug_helper.h 
b/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
index 66d46de888..15659896b6 100644
--- a/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
@@ -6,7 +6,6 @@
  #include "util/u_debug.h"
  #include "util/u_tests.h"
  
-

  /* Helper function to wrap a screen with
   * one or more debug drivers.
   */
@@ -16,6 +15,10 @@
  #include "driver_rbug/rbug_public.h"
  #include "driver_noop/noop_public.h"
  
+#ifdef __cplusplus

+extern "C" {
+#endif
+
  /*
   * TODO: Audit the following *screen_create() - all of
   * them should return the original screen on failuire.
@@ -35,3 +38,7 @@ debug_screen_wrap(struct pipe_screen *screen)
  }
  
  #endif

+
+#ifdef __cplusplus
+}
+#endif



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


Re: [Mesa-dev] [PATCH 2/2] gallium/u_vbuf: handle indirect multidraws correctly and efficiently (v2)

2018-07-27 Thread Eric Anholt
Marek Olšák  writes:

> From: Marek Olšák 
>
> v2: need to do MAX{start+count} instead of MAX{count}
> added piglit tests
> ---
>  src/gallium/auxiliary/util/u_vbuf.c | 199 
>  1 file changed, 175 insertions(+), 24 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_vbuf.c 
> b/src/gallium/auxiliary/util/u_vbuf.c
> index 746ff1085ce..ca53e6218fd 100644
> --- a/src/gallium/auxiliary/util/u_vbuf.c
> +++ b/src/gallium/auxiliary/util/u_vbuf.c
> @@ -1124,20 +1124,45 @@ static void u_vbuf_set_driver_vertex_buffers(struct 
> u_vbuf *mgr)
> unsigned start_slot, count;
>  
> start_slot = ffs(mgr->dirty_real_vb_mask) - 1;
> count = util_last_bit(mgr->dirty_real_vb_mask >> start_slot);
>  
> pipe->set_vertex_buffers(pipe, start_slot, count,
>  mgr->real_vertex_buffer + start_slot);
> mgr->dirty_real_vb_mask = 0;
>  }
>  
> +static void
> +u_vbuf_split_indexed_multidraw(struct u_vbuf *mgr, struct pipe_draw_info 
> *info,
> +   unsigned *indirect_data, unsigned stride,
> +   unsigned draw_count)
> +{
> +   assert(info->index_size);
> +   info->indirect = NULL;
> +
> +   for (unsigned i = 0; i < draw_count; i++) {
> +  unsigned offset = i * stride / 4;
> +
> +  info->count = indirect_data[offset + 0];
> +  info->instance_count = indirect_data[offset + 1];
> +
> +  if (!info->count || !info->instance_count)
> + continue;
> +
> +  info->start = indirect_data[offset + 2];
> +  info->index_bias = indirect_data[offset + 3];
> +  info->start_instance = indirect_data[offset + 4];
> +
> +  u_vbuf_draw_vbo(mgr, info);
> +   }
> +}
> +
>  void u_vbuf_draw_vbo(struct u_vbuf *mgr, const struct pipe_draw_info *info)
>  {
> struct pipe_context *pipe = mgr->pipe;
> int start_vertex;
> unsigned min_index;
> unsigned num_vertices;
> boolean unroll_indices = FALSE;
> const uint32_t used_vb_mask = mgr->ve->used_vb_mask;
> uint32_t user_vb_mask = mgr->user_vb_mask & used_vb_mask;
> const uint32_t incompatible_vb_mask =
> @@ -1153,47 +1178,172 @@ void u_vbuf_draw_vbo(struct u_vbuf *mgr, const 
> struct pipe_draw_info *info)
>if (mgr->dirty_real_vb_mask & used_vb_mask) {
>   u_vbuf_set_driver_vertex_buffers(mgr);
>}
>  
>pipe->draw_vbo(pipe, info);
>return;
> }
>  
> new_info = *info;
>  
> -   /* Fallback. We need to know all the parameters. */
> +   /* Handle indirect (multi)draws. */
> if (new_info.indirect) {
> -  struct pipe_transfer *transfer = NULL;
> -  int *data;
> -
> -  if (new_info.index_size) {
> - data = pipe_buffer_map_range(pipe, new_info.indirect->buffer,
> -  new_info.indirect->offset, 20,
> -  PIPE_TRANSFER_READ, );
> - new_info.index_bias = data[3];
> - new_info.start_instance = data[4];
> -  }
> -  else {
> - data = pipe_buffer_map_range(pipe, new_info.indirect->buffer,
> -  new_info.indirect->offset, 16,
> -  PIPE_TRANSFER_READ, );
> - new_info.start_instance = data[3];
> +  const struct pipe_draw_indirect_info *indirect = new_info.indirect;
> +  unsigned draw_count = 0;
> +
> +  /* Get the number of draws. */
> +  if (indirect->indirect_draw_count) {
> + pipe_buffer_read(pipe, indirect->indirect_draw_count,
> +  indirect->indirect_draw_count_offset,
> +  4, _count);
> +  } else {
> + draw_count = indirect->draw_count;
>}
>  
> -  new_info.count = data[0];
> -  new_info.instance_count = data[1];
> -  new_info.start = data[2];
> -  pipe_buffer_unmap(pipe, transfer);
> -  new_info.indirect = NULL;
> -
> -  if (!new_info.count)
> +  if (!draw_count)
>   return;
> +
> +  unsigned data_size = (draw_count - 1) * indirect->stride +
> +   (new_info.index_size ? 20 : 16);
> +  unsigned *data = alloca(data_size);

I continue to believe that alloca isn't something we should be using on
unbounded data_size like this.  We should be returing GL_OUT_OF_MEMORY
when we fail, not segfaulting.

We're already reading back the BOs, it's not like the allocation is a
performance concern at this point.


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


Re: [Mesa-dev] [PATCH 1/2] gallium/u_vbuf: split u_vbuf_get_minmax_index function (v2)

2018-07-27 Thread Eric Anholt
Marek Olšák  writes:

> From: Marek Olšák 
>
> This will be used by indirect multidraws.
>
> v2: clean up the function further, change return types to unsigned

Reviewed-by: Eric Anholt 


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


Re: [Mesa-dev] [PATCH 1/3] ac/surface: fix MSAA corruption on Vega due to FMASK tile swizzle

2018-07-27 Thread Marek Olšák
On Fri, Jul 27, 2018 at 5:16 AM, Bas Nieuwenhuizen
 wrote:
> Reviewed-by: Bas Nieuwenhuizen 
>
> Does it occur often that they are different?

It depends on the size. FMASK has lower bpp and always 1 sample, so
the tiling is more likely to use 4K than 64K macrotiles.

Marek

>
> On Fri, Jul 27, 2018 at 5:36 AM, Marek Olšák  wrote:
>> From: Marek Olšák 
>>
>> a needle in the haystack?
>>
>> Cc: 18.1 
>> ---
>>  src/amd/common/ac_surface.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
>> index afdae1971e9..2f4f0f8884f 100644
>> --- a/src/amd/common/ac_surface.c
>> +++ b/src/amd/common/ac_surface.c
>> @@ -1295,21 +1295,21 @@ static int gfx9_compute_miptree(ADDR_HANDLE addrlib,
>> !(surf->flags & RADEON_SURF_SHAREABLE)) {
>> ADDR2_COMPUTE_PIPEBANKXOR_INPUT xin = {0};
>> ADDR2_COMPUTE_PIPEBANKXOR_OUTPUT xout = {0};
>>
>> xin.size = 
>> sizeof(ADDR2_COMPUTE_PIPEBANKXOR_INPUT);
>> xout.size = 
>> sizeof(ADDR2_COMPUTE_PIPEBANKXOR_OUTPUT);
>>
>> /* This counter starts from 1 instead of 0. 
>> */
>> xin.surfIndex = 
>> p_atomic_inc_return(config->info.fmask_surf_index);
>> xin.flags = in->flags;
>> -   xin.swizzleMode = in->swizzleMode;
>> +   xin.swizzleMode = fin.swizzleMode;
>> xin.resourceType = in->resourceType;
>> xin.format = in->format;
>> xin.numSamples = in->numSamples;
>> xin.numFrags = in->numFrags;
>>
>> ret = Addr2ComputePipeBankXor(addrlib, , 
>> );
>> if (ret != ADDR_OK)
>> return ret;
>>
>> assert(xout.pipeBankXor <=
>> --
>> 2.17.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] swrast: fix crash in AA line code when there's no texture

2018-07-27 Thread Neha Bhende
Looks good.


For series,


Reviewed-by: Neha Bhende


Regards,

Neha


From: Brian Paul 
Sent: Friday, July 27, 2018 12:07:50 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH 2/2] swrast: fix crash in AA line code when there's no texture

Fixes a crash running the Piglit polygon-mode-facing test (and
probably others).
---
 src/mesa/swrast/s_aalinetemp.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/mesa/swrast/s_aalinetemp.h b/src/mesa/swrast/s_aalinetemp.h
index bebb131..64767a3 100644
--- a/src/mesa/swrast/s_aalinetemp.h
+++ b/src/mesa/swrast/s_aalinetemp.h
@@ -179,10 +179,12 @@ NAME(line)(struct gl_context *ctx, const SWvertex *v0, 
const SWvertex *v1)
  if (attr >= VARYING_SLOT_TEX0 && attr < VARYING_SLOT_VAR0) {
 const GLuint u = attr - VARYING_SLOT_TEX0;
 const struct gl_texture_object *obj = 
ctx->Texture.Unit[u]._Current;
-const struct gl_texture_image *texImage =
-   _mesa_base_tex_image(obj);
-line.texWidth[attr]  = (GLfloat) texImage->Width;
-line.texHeight[attr] = (GLfloat) texImage->Height;
+if (obj) {
+   const struct gl_texture_image *texImage =
+  _mesa_base_tex_image(obj);
+   line.texWidth[attr]  = (GLfloat) texImage->Width;
+   line.texHeight[attr] = (GLfloat) texImage->Height;
+}
  }
   ATTRIB_LOOP_END
}
--
2.7.4

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


[Mesa-dev] [PATCH] gallium/auxiliary: Extern "c" fixes.

2018-07-27 Thread Alexander von Gluck IV
Used by C++ code such as Haiku's renderer.
---
 src/gallium/auxiliary/driver_ddebug/dd_public.h  | 8 
 src/gallium/auxiliary/driver_noop/noop_public.h  | 8 
 .../auxiliary/target-helpers/inline_debug_helper.h   | 9 -
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_public.h 
b/src/gallium/auxiliary/driver_ddebug/dd_public.h
index e660765575..31c139d6a1 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_public.h
+++ b/src/gallium/auxiliary/driver_ddebug/dd_public.h
@@ -30,7 +30,15 @@
 
 struct pipe_screen;
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 struct pipe_screen *
 ddebug_screen_create(struct pipe_screen *screen);
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif /* DD_PUBLIC_H_ */
diff --git a/src/gallium/auxiliary/driver_noop/noop_public.h 
b/src/gallium/auxiliary/driver_noop/noop_public.h
index 180ea597fa..46a7f4084f 100644
--- a/src/gallium/auxiliary/driver_noop/noop_public.h
+++ b/src/gallium/auxiliary/driver_noop/noop_public.h
@@ -23,7 +23,15 @@
 #ifndef NOOP_PUBLIC_H
 #define NOOP_PUBLIC_H
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 struct pipe_screen;
 struct pipe_screen *noop_screen_create(struct pipe_screen *screen);
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif
diff --git a/src/gallium/auxiliary/target-helpers/inline_debug_helper.h 
b/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
index 66d46de888..15659896b6 100644
--- a/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
+++ b/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
@@ -6,7 +6,6 @@
 #include "util/u_debug.h"
 #include "util/u_tests.h"
 
-
 /* Helper function to wrap a screen with
  * one or more debug drivers.
  */
@@ -16,6 +15,10 @@
 #include "driver_rbug/rbug_public.h"
 #include "driver_noop/noop_public.h"
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 /*
  * TODO: Audit the following *screen_create() - all of
  * them should return the original screen on failuire.
@@ -35,3 +38,7 @@ debug_screen_wrap(struct pipe_screen *screen)
 }
 
 #endif
+
+#ifdef __cplusplus
+}
+#endif
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] gallium/swr: Enable support bptc format.

2018-07-27 Thread Cherniak, Bruce
Reviewed-by: Bruce Cherniak  

> On Jul 27, 2018, at 1:45 PM, Denis Pauk  wrote:
> 
> Reuse Code from:
> f69bc797e1 gallium/auxiliary: Add helper support for bptc format 
> compress/decompress
> 
> Signed-off-by: Denis Pauk 
> CC: Marek Olšák 
> CC: Bruce Cherniak 
> CC: Tim Rowley 
> ---
> src/gallium/drivers/swr/swr_screen.cpp | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
> b/src/gallium/drivers/swr/swr_screen.cpp
> index 65fa1bc50e..1cc01aa47d 100644
> --- a/src/gallium/drivers/swr/swr_screen.cpp
> +++ b/src/gallium/drivers/swr/swr_screen.cpp
> @@ -137,8 +137,7 @@ swr_is_format_supported(struct pipe_screen *_screen,
>  return FALSE;
>}
> 
> -   if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
> -   format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
> +   if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
>   return FALSE;
>}
> 
> -- 
> 2.18.0
> 

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


Re: [Mesa-dev] [PATCH 2/2] i965: implement MESA_framebuffer_flip_y [v3]

2018-07-27 Thread Chad Versace
On Mon 23 Jul 2018, Fritz Koenig wrote:
> Instead of using _mesa_is_winsys_fbo or
> _mesa_is_user_fbo to infer if an fbo is
> flipped use the InvertedY flag.
> 
> v2:
> * additional window-system framebuffer checks [for jason]
> v3:
> * s/inverted_y/flip_y/g [for chadv]
> * s/InvertedY/FlipY/g [for chadv]
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c |  2 +-
>  src/mesa/drivers/dri/i965/brw_meta_util.c |  4 +-
>  src/mesa/drivers/dri/i965/brw_sf.c|  6 +--
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 50 +--
>  src/mesa/drivers/dri/i965/intel_extensions.c  |  1 +
>  src/mesa/drivers/dri/i965/intel_fbo.c | 11 ++--
>  .../drivers/dri/i965/intel_pixel_bitmap.c |  8 +--
>  src/mesa/drivers/dri/i965/intel_pixel_copy.c  |  4 +-
>  src/mesa/drivers/dri/i965/intel_pixel_draw.c  |  2 +-
>  9 files changed, 43 insertions(+), 45 deletions(-)

For the series,
Reviewed-by: Chad Versace 

I'll push soon.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] mesa: add switch case for GL 2.1 in _mesa_compute_version()

2018-07-27 Thread Brian Paul
The xlib/swrast driver only supports GL 2.1.  This patch fixes a
crash if the app calls glGetString(GL_SHADING_LANGUAGE_VERSION).
---
 src/mesa/main/version.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 58e68b4..2c5bd77 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -617,6 +617,9 @@ _mesa_compute_version(struct gl_context *ctx)
 */
if (_mesa_is_desktop_gl(ctx)) {
   switch (ctx->Version) {
+  case 21:
+ ctx->Const.GLSLVersion = 120;
+ break;
   case 30:
  ctx->Const.GLSLVersion = 130;
  break;
-- 
2.7.4

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


[Mesa-dev] [PATCH 2/2] swrast: fix crash in AA line code when there's no texture

2018-07-27 Thread Brian Paul
Fixes a crash running the Piglit polygon-mode-facing test (and
probably others).
---
 src/mesa/swrast/s_aalinetemp.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/mesa/swrast/s_aalinetemp.h b/src/mesa/swrast/s_aalinetemp.h
index bebb131..64767a3 100644
--- a/src/mesa/swrast/s_aalinetemp.h
+++ b/src/mesa/swrast/s_aalinetemp.h
@@ -179,10 +179,12 @@ NAME(line)(struct gl_context *ctx, const SWvertex *v0, 
const SWvertex *v1)
  if (attr >= VARYING_SLOT_TEX0 && attr < VARYING_SLOT_VAR0) {
 const GLuint u = attr - VARYING_SLOT_TEX0;
 const struct gl_texture_object *obj = 
ctx->Texture.Unit[u]._Current;
-const struct gl_texture_image *texImage =
-   _mesa_base_tex_image(obj);
-line.texWidth[attr]  = (GLfloat) texImage->Width;
-line.texHeight[attr] = (GLfloat) texImage->Height;
+if (obj) {
+   const struct gl_texture_image *texImage =
+  _mesa_base_tex_image(obj);
+   line.texWidth[attr]  = (GLfloat) texImage->Width;
+   line.texHeight[attr] = (GLfloat) texImage->Height;
+}
  }
   ATTRIB_LOOP_END
}
-- 
2.7.4

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


[Mesa-dev] [PATCH] gallium/swr: Enable support bptc format.

2018-07-27 Thread Denis Pauk
Reuse Code from:
f69bc797e1 gallium/auxiliary: Add helper support for bptc format 
compress/decompress

Signed-off-by: Denis Pauk 
CC: Marek Olšák 
CC: Bruce Cherniak 
CC: Tim Rowley 
---
 src/gallium/drivers/swr/swr_screen.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_screen.cpp 
b/src/gallium/drivers/swr/swr_screen.cpp
index 65fa1bc50e..1cc01aa47d 100644
--- a/src/gallium/drivers/swr/swr_screen.cpp
+++ b/src/gallium/drivers/swr/swr_screen.cpp
@@ -137,8 +137,7 @@ swr_is_format_supported(struct pipe_screen *_screen,
  return FALSE;
}
 
-   if (format_desc->layout == UTIL_FORMAT_LAYOUT_BPTC ||
-   format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
+   if (format_desc->layout == UTIL_FORMAT_LAYOUT_ASTC) {
   return FALSE;
}
 
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH v3 3/3] glsl: propagate full variables eagerly

2018-07-27 Thread Caio Marcelo de Oliveira Filho
Hi Thomas,

On Thu, Jul 26, 2018 at 09:59:44PM +0200, Thomas Helland wrote:
> Since we're always going top-down through the
> program there should be no need to "walk backwards",
> so this approach should be enough to get the whole chain
> of assignments in one pass. Neat.

The patch that incorporates full variables in the elements pass was
already fixing up the ir_dereference_variables when visiting them
(that happens before the visit to the assignments), so this turned out
not to be needed.

So we have

b = a
- dereference visit for 'a': there's no acp_entry for 'a'
- assignment visit: creates acp_entry for (b, a)
c = b
- dereference visit for 'b': there's acp_entry for 'b', use it
  >>> c = a
- assignment visit: creates acp_entry for (c, a)

...

I was initially experimenting with the same idea for elements, which
don't have the "dereference visit" so such idea would make sense, but
that turned out not to be so useful.


Thanks,
Caio



> 2018-07-25 3:03 GMT+02:00 Caio Marcelo de Oliveira Filho
> :
> > When creating a new acp_entry after an assignment "c = b", check if b
> > itself has an acp_entry with a full variable associated and use
> > that. This reduces the number of passes the algorithm needs to
> > propagate a value in a chain of assignments.
> >
> > I've tried to make a similar change to the write_partial, but it
> > caused noise in the final output (hurting instruction count). The
> > reason is for partials, a propagation might imply a swizzle
> > operation.
> >
> > We could later investigate if it is worth to restrict the cases we are
> > eager to avoid getting things worse because of swizzling.
> > ---
> >  .../glsl/opt_copy_propagation_elements.cpp| 23 ++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/compiler/glsl/opt_copy_propagation_elements.cpp 
> > b/src/compiler/glsl/opt_copy_propagation_elements.cpp
> > index cae6d3c0707..c44f7c56f11 100644
> > --- a/src/compiler/glsl/opt_copy_propagation_elements.cpp
> > +++ b/src/compiler/glsl/opt_copy_propagation_elements.cpp
> > @@ -169,8 +169,29 @@ public:
> >   }
> >}
> >
> > +  /* If the rhs has an acp_entry pointing to another full variable, use
> > +   * that. This allows propagation to happen all in one pass, instead 
> > of
> > +   * having the value walking slowly. E.g.
> > +   *
> > +   * b = a
> > +   * c = b
> > +   * d = c
> > +   * use(d)
> > +   *
> > +   * will need one pass to propagate to
> > +   *
> > +   * b = a
> > +   * c = a// Because of b acp_entry.
> > +   * d = a// Because of c acp_entry that uses 'a' directly.
> > +   * use(a)   // Because of d acp_entry that uses 'a' directly.
> > +   */
> > +  acp_entry *rhs_entry = read(rhs);
> > +  if (rhs_entry && rhs_entry->rhs_full != NULL) {
> > + rhs = rhs_entry->rhs_full;
> > +  }
> > +  rhs_entry = pull_acp(rhs);
> > +
> >lhs_entry->rhs_full = rhs;
> > -  acp_entry *rhs_entry = pull_acp(rhs);
> >_mesa_set_add(rhs_entry->dsts, lhs);
> >
> >if (lhs->type->is_vector()) {
> > --
> > 2.18.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 0/3] GLSL Copy Propagation

2018-07-27 Thread Caio Marcelo de Oliveira Filho
> Caio Marcelo de Oliveira Filho (3):
>   glsl: teach copy_propagation_elements to deal with whole variables
>   glsl: use only copy_propagation_elements
>   glsl: propagate full variables eagerly

Landed patches 1 and 2.  Turned out patch 3 was not needed.

By Eric suggestion, I'll take a look at the impact of not using copy
propagation in GLSL.  I've opted to land the patches regardless since
it removes the "duplication" in copy propagation passes (for GLSL).


Thanks,
Caio

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


[Mesa-dev] [PATCH 1/2] intel/fs: New method for register_byte_use_pattern for fs_inst

2018-07-27 Thread Chema Casanova
El 27/07/18 a las 02:44, Francisco Jerez escribió:
> Chema Casanova  writes:
> 
>> El 26/07/18 a las 20:02, Francisco Jerez escribió:
>>> Chema Casanova  writes:
>>>
 El 20/07/18 a las 22:10, Francisco Jerez escribió:
> Chema Casanova  writes:
>
>> El 20/07/18 a las 00:34, Francisco Jerez escribió:
>>> Chema Casanova  writes:
>>>
 El 14/07/18 a las 00:14, Francisco Jerez escribió:
> Jose Maria Casanova Crespo  writes:
>
>> For a register source/destination of an instruction the function 
>> returns
>> the read/write byte pattern of a 32-byte registers as a unsigned int.
>>
>> The returned pattern takes into account the exec_size of the 
>> instruction,
>> the type bitsize, the stride and if the register is source or 
>> destination.
>>
>> The objective of the functions if to help to know the read/written 
>> bytes
>> of the instructions to improve the liveness analysis for partial 
>> read/writes.
>>
>> We manage special cases for 
>> SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL
>> and SHADER_OPCODE_BYTE_SCATTERED_WRITE because depending of the 
>> bitsize
>> parameter they have a different read pattern.
>> ---
>>  src/intel/compiler/brw_fs.cpp  | 183 
>> +
>>  src/intel/compiler/brw_ir_fs.h |   1 +
>>  2 files changed, 184 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp 
>> b/src/intel/compiler/brw_fs.cpp
>> index 2b8363ca362..f3045c4ff6c 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -687,6 +687,189 @@ fs_inst::is_partial_write() const
>> this->dst.offset % REG_SIZE != 0);
>>  }
>>  
>> +/**
>> + * Returns a 32-bit uint whose bits represent if the associated 
>> register byte
>> + * has been read/written by the instruction. The returned pattern 
>> takes into
>> + * account the exec_size of the instruction, the type bitsize and 
>> the register
>> + * stride and the register is source or destination for the 
>> instruction.
>> + *
>> + * The objective of this function is to identify which parts of the 
>> register
>> + * are read or written for operations that don't read/write a full 
>> register.
>> + * So we can identify in live range variable analysis if a partial 
>> write has
>> + * completelly defined the part of the register used by a partial 
>> read. So we
>> + * avoid extending the liveness range because all data read was 
>> already
>> + * defined although the wasn't completely written.
>> + */
>> +unsigned
>> +fs_inst::register_byte_use_pattern(const fs_reg , boolean is_dst) 
>> const
>> +{
>> +   if (is_dst) {

> Please split into two functions (like fs_inst::src_read and
> ::src_written) since that would make the call-sites of this method 
> more
> self-documenting than a boolean parameter.  You should be able to 
> share
> code by refactoring the common logic into a separate function (see 
> below
> for some suggestions on how that could be achieved).

 Sure, it would improve readability and simplifies the logic, I've 
 chosen
 dst_write_pattern and src_read_pattern.

>
>> +  /* We don't know what is written so we return the worts case 
>> */
>
> "worst"

 Fixed.

>> +  if (this->predicate && this->opcode != BRW_OPCODE_SEL)
>> + return 0;
>> +  /* We assume that send destinations are completely written */
>> +  if (this->is_send_from_grf())
>> + return ~0u;
>
> Some send-like instructions won't be caught by this condition, you
> should check for this->mlen != 0 in addition.

 Would it be enough to check for (this->mlen > 0) and forget about
 is_send_from_grf? I am using this approach in v2 I am sending.

>>>
>>> I don't think the mlen > 0 condition would catch all cases either...
>>> E.g. FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD IIRC.  You probably need both
>>> conditions.  Sucks...
>>
>> That is true, so now we have the:
>>  (this->is_send_from_grf() || this->mlen != 0)
>>
>> +   } else {
>> +  /* byte_scattered_write_logical pattern of src[1] is 32-bit 
>> aligned
>> +   * so the read pattern depends on the bitsize stored at src[4]
>> +   */
>> +  if (this->opcode == 

[Mesa-dev] [PATCH v4 1/2] intel/fs: New methods dst_write_pattern and src_read_pattern at fs_inst

2018-07-27 Thread Jose Maria Casanova Crespo
These new methods return for a instruction register source/destination
the read/write byte pattern of the 32-byte GRF as an unsigned int.

The returned pattern takes into account the exec_size of the instruction,
the type bitsize, the register stride and a relative offset inside the
register.

The motivation of this functions if to know the read/written bytes
of the instructions to improve the liveness analysis for partial
read/writes.

We manage special cases for SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL
and SHADER_OPCODE_BYTE_SCATTERED_WRITE because depending of the bitsize
parameter they have a different read pattern.

v2: (Francisco Jerez)
- Split original register_byte_use_pattern into one read and other
  write.
- Check for send like instructions using this->mlen != 0
- Pass functions src number and offset.
- Use periodic_mask function with code written by Francisco Jerez
  to simplify pattern generation.
- Avoid breaking silently if source straddles multiple GRFs.

v3: (Francisco Jerez)
- A SEND could be this->mlen != 0 or this->is_send_from_grf
- We only assume that a periodic mask with offset could be applied
  to reg_offset == 0.
- We can assure that for MOVs operations for any offset (Chema)

v4: (Francisco Jerez)
- We return 0 mask for reg_offset out of the region definition.
- We return periodic masks when access is in bounds for ALU opcodes.

Cc: Francisco Jerez 
---
 src/intel/compiler/brw_fs.cpp  | 111 +
 src/intel/compiler/brw_ir_fs.h |   2 +
 2 files changed, 113 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 7ddbd285fe2..157b49c42d3 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -39,6 +39,7 @@
 #include "compiler/glsl_types.h"
 #include "compiler/nir/nir_builder.h"
 #include "program/prog_parameter.h"
+#include 
 
 using namespace brw;
 
@@ -687,6 +688,116 @@ fs_inst::is_partial_write() const
this->dst.offset % REG_SIZE != 0);
 }
 
+/**
+ * Returns a periodic mask that is repeated "count" times with a "step"
+ * size and consecutive "bits" finally shifted "offset" bits to the left.
+ *
+ * This helper is used to calculate the representations of byte read/write
+ * register patterns
+ *
+ * Example: periodic_mask(8, 4, 2, 0)  would return 0x
+ *  periodic_mask(8, 4, 2, 2)  would return 0x
+ *  periodic_masc(8, 2, 2, 16) would return 0x
+ */
+static inline uint32_t
+periodic_mask(unsigned count, unsigned step, unsigned bits, unsigned offset)
+{
+   uint32_t m = (count ? (1 << bits) - 1 : 0);
+   const unsigned max = MIN2(count * step, sizeof(m) * CHAR_BIT);
+
+   for (unsigned shift = step; shift < max; shift *= 2)
+  m |= m << shift;
+
+   return m << offset;
+}
+
+/**
+ * Returns a 32-bit uint whose bits represent if the associated register byte
+ * has been written by the instruction. The returned pattern takes into
+ * account the exec_size of the instruction, the type bitsize, the stride
+ * of the destination register and the internal register byte offset.
+ *
+ * The objective of this function is to identify which parts of the register
+ * are written for operations that don't write a full register. So we
+ * we can identify in live range variable analysis if a partial write has
+ * completelly defined the data used by a partial read.
+ *
+ * reg_offset identifies full registers starting at dst.reg with
+ * reg_offset == 0.
+ */
+unsigned
+fs_inst::dst_write_pattern(unsigned reg_offset) const
+{
+   assert(this->dst.file == VGRF);
+
+   /* Instruction doesn't write out of bounds */
+   if (reg_offset >= regs_written(this))
+  return 0;
+
+   /* We don't know what is written so we return the worst case */
+   if (this->predicate && this->opcode != BRW_OPCODE_SEL)
+  return 0;
+
+   /* We assume that send destinations are completelly defined */
+   if (this->is_send_from_grf() || this->mlen != 0)
+  return ~0u;
+
+   /* The byte pattern is calculated using a periodic mask for ALU
+* operations and reg_offset in bounds.
+*/
+   return periodic_mask(this->exec_size,
+this->dst.stride * type_sz(this->dst.type),
+type_sz(this->dst.type),
+this->dst.offset % REG_SIZE);
+}
+
+/**
+ * Returns a 32-bit uint whose bits represent if the associated register byte
+ * has been read by the instruction. The returned pattern takes into
+ * account the exec_size of the instruction, the type bitsize and stride of
+ * a source register and the internal register byte offset.
+ *
+ * The objective of this function is to identify which parts of the register
+ * are used for operations that don't read a full register.
+ *
+ * Parameter i identifies the instruction source number and reg_offset
+ * identifies full registers starting at src[i].reg with reg_offset == 0.
+ */
+unsigned

Re: [Mesa-dev] [PATCH 2/2] mesa: move var decls in texstore_rgba()

2018-07-27 Thread Charmaine Lee

For the series, Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Friday, July 27, 2018 7:21:53 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH 2/2] mesa: move var decls in texstore_rgba()

Move them closer to where they're first used.
---
 src/mesa/main/texstore.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index c7a459e..55f66c5 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -673,12 +673,10 @@ texstore_compressed(TEXSTORE_PARAMS)
 static GLboolean
 texstore_rgba(TEXSTORE_PARAMS)
 {
-   void *tempImage = NULL, *tempRGBA = NULL;
-   int srcRowStride, img;
+   void *tempImage = NULL;
+   int img;
GLubyte *src, *dst;
-   uint32_t srcMesaFormat;
uint8_t rebaseSwizzle[4];
-   bool needRebase;
bool transferOpsDone = false;

/* We have to handle MESA_FORMAT_YCBCR manually because it is a special case
@@ -748,15 +746,18 @@ texstore_rgba(TEXSTORE_PARAMS)
   }
}

-   srcRowStride =
+   int srcRowStride =
   _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType);

-   srcMesaFormat = _mesa_format_from_format_and_type(srcFormat, srcType);
+   uint32_t srcMesaFormat =
+  _mesa_format_from_format_and_type(srcFormat, srcType);
+
dstFormat = _mesa_get_srgb_format_linear(dstFormat);

/* If we have transferOps then we need to convert to RGBA float first,
   then apply transferOps, then do the conversion to dst
 */
+   void *tempRGBA = NULL;
if (!transferOpsDone &&
_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat)) {
   /* Allocate RGBA float image */
@@ -797,6 +798,7 @@ texstore_rgba(TEXSTORE_PARAMS)
   _mesa_image_address(dims, srcPacking, srcAddr, srcWidth, srcHeight,
   srcFormat, srcType, 0, 0, 0);

+   bool needRebase;
if (_mesa_get_format_base_format(dstFormat) != baseInternalFormat) {
   needRebase =
  _mesa_compute_rgba2base2rgba_component_mapping(baseInternalFormat,
--
2.7.4

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


[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized when compiling with -fstack-protector

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107369

--- Comment #12 from Gian-Carlo Pascutto  ---
So the bugs are:

1) Debian adding flags even if they don't make sense (i.e. stack protection on
GPU code). Should be filed in Debian against libclc.

2) LLVM respecting that flag even if it shouldn't. Should be checked if it
still happens with LLVM 7 and filed against LLVM if so.

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


Re: [Mesa-dev] [PATCH] anv: Disable dual source blending when shader doesn't support it on gen8+

2018-07-27 Thread Danylo Piliaiev

bump. I can add test to Crucible if it will help.


On 20.07.18 12:54, Danylo Piliaiev wrote:

Dual source blending behaviour is undefined when shader doesn't
have second color output.

  "If SRC1 is included in a src/dst blend factor and
   a DualSource RT Write message is not used, results
   are UNDEFINED. (This reflects the same restriction in DX APIs,
   where undefined results are produced if “o1” is not written
   by a PS – there are no default values defined)."

Dismissing fragment in such situation leads to a hang on gen8+
if depth test in enabled.

Since blending cannot be gracefully fixed in such case and the result
is undefined - blending is simply disabled.

Signed-off-by: Danylo Piliaiev 
---

Also there is a similar patch which fixes the same issue
for OpenGL https://patchwork.freedesktop.org/patch/235939

  src/intel/vulkan/genX_pipeline.c | 43 
  1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 0821d71c9f..d7c532a22d 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -854,6 +854,15 @@ emit_ds_state(struct anv_pipeline *pipeline,
  #endif
  }
  
+MAYBE_UNUSED static bool

+is_dual_src_blend_factor(VkBlendFactor factor)
+{
+   return factor == VK_BLEND_FACTOR_SRC1_COLOR ||
+  factor == VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR ||
+  factor == VK_BLEND_FACTOR_SRC1_ALPHA ||
+  factor == VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA;
+}
+
  static void
  emit_cb_state(struct anv_pipeline *pipeline,
const VkPipelineColorBlendStateCreateInfo *info,
@@ -886,6 +895,7 @@ emit_cb_state(struct anv_pipeline *pipeline,
 state_pos += GENX(BLEND_STATE_length);
  #if GEN_GEN >= 8
 struct GENX(BLEND_STATE_ENTRY) bs0 = { 0 };
+   bool force_disable_color_blend = false;
  #endif
 for (unsigned i = 0; i < surface_count; i++) {
struct anv_pipeline_binding *binding = >surface_to_descriptor[i];
@@ -969,8 +979,27 @@ emit_cb_state(struct anv_pipeline *pipeline,
GENX(BLEND_STATE_ENTRY_pack)(NULL, state_pos, );
state_pos += GENX(BLEND_STATE_ENTRY_length);
  #if GEN_GEN >= 8
-  if (i == 0)
+  if (i == 0) {
   bs0 = entry;
+
+ /* The Dual Source Blending documentation says:
+  *
+  * "If SRC1 is included in a src/dst blend factor and
+  * a DualSource RT Write message is not used, results
+  * are UNDEFINED. (This reflects the same restriction in DX APIs,
+  * where undefined results are produced if “o1” is not written
+  * by a PS – there are no default values defined)."
+  *
+  * There is no way to gracefully fix this undefined situation
+  * so we just disable the blending to prevent possible issues.
+  */
+ const struct brw_wm_prog_data *wm_prog_data = 
get_wm_prog_data(pipeline);
+ force_disable_color_blend = !wm_prog_data->dual_src_blend &&
+(is_dual_src_blend_factor(a->srcColorBlendFactor) ||
+is_dual_src_blend_factor(a->dstColorBlendFactor) ||
+is_dual_src_blend_factor(a->srcAlphaBlendFactor) ||
+is_dual_src_blend_factor(a->dstAlphaBlendFactor));
+  }
  #endif
 }
  
@@ -978,7 +1007,8 @@ emit_cb_state(struct anv_pipeline *pipeline,

 anv_batch_emit(>batch, GENX(3DSTATE_PS_BLEND), blend) {
blend.AlphaToCoverageEnable = blend_state.AlphaToCoverageEnable;
blend.HasWriteableRT= has_writeable_rt;
-  blend.ColorBufferBlendEnable= bs0.ColorBufferBlendEnable;
+  blend.ColorBufferBlendEnable=
+ bs0.ColorBufferBlendEnable && !force_disable_color_blend;
blend.SourceAlphaBlendFactor= bs0.SourceAlphaBlendFactor;
blend.DestinationAlphaBlendFactor   = bs0.DestinationAlphaBlendFactor;
blend.SourceBlendFactor = bs0.SourceBlendFactor;
@@ -1430,15 +1460,6 @@ emit_3dstate_wm(struct anv_pipeline *pipeline, struct 
anv_subpass *subpass,
 }
  }
  
-UNUSED static bool

-is_dual_src_blend_factor(VkBlendFactor factor)
-{
-   return factor == VK_BLEND_FACTOR_SRC1_COLOR ||
-  factor == VK_BLEND_FACTOR_ONE_MINUS_SRC1_COLOR ||
-  factor == VK_BLEND_FACTOR_SRC1_ALPHA ||
-  factor == VK_BLEND_FACTOR_ONE_MINUS_SRC1_ALPHA;
-}
-
  static void
  emit_3dstate_ps(struct anv_pipeline *pipeline,
  const VkPipelineColorBlendStateCreateInfo *blend,


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


Re: [Mesa-dev] [PATCH v3] intel/ppgtt: memory address alignment

2018-07-27 Thread Lionel Landwerlin

Hey Sergii,

Sorry for the late answer.

For the sake of clarity, I would split the changes (4096->PAGE_SIZE) and 
the actual bug fix into 2 different patches.

I don't have see a problem with the PAGE_SIZE change.

Thanks a lot,

-
Lionel

On 25/07/18 14:24, Sergii Romantsov wrote:

Sorry,
do we have any objections about PAGE_SIZE usage instead of 4096?

And what do you think if, maybe, some auto Intel-internal tests to run 
with that patch?



On Wed, Jul 25, 2018 at 1:21 PM, Sergii Romantsov 
mailto:sergii.romant...@gmail.com>> wrote:


Kernel (for ppgtt) requires memory address to be
aligned to page size (4096).

-v2: added marking that also fixes initial commit 01058a552294.
-v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
instead of alignment of offsets (Chris Wilson).

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

Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for
full-PPGTT systems.)
Fixes: 01058a552294 (i965: Add virtual memory allocator
infrastructure to brw_bufmgr.)
Signed-off-by: Sergii Romantsov mailto:sergii.romant...@globallogic.com>>
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 09d45e3..66d7751 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr,
uint64_t size, uint32_t tiling)
       return size;

    /* 965+ just need multiples of page size for tiling */
-   return ALIGN(size, 4096);
+   return ALIGN(size, PAGE_SIZE);
 }

 /*
@@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
                   uint32_t stride)
 {
    struct brw_bo *bo;
-   unsigned int page_size = getpagesize();
    int ret;
    struct bo_cache_bucket *bucket;
    bool alloc_from_cache;
@@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
     * allocation up.
     */
    if (bucket == NULL) {
-      bo_size = size;
-      if (bo_size < page_size)
-         bo_size = page_size;
+      unsigned int page_size = getpagesize();
+      bo_size = ALIGN(size, page_size);
    } else {
       bo_size = bucket->size;
    }
+   assert(bo_size);

    mtx_lock(>lock);
    /* Get a buffer out of the cache if available */
@@ -1578,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
     * width/height alignment and rounding of sizes to pages will
     * get us useful cache hit rates anyway)
     */
-   add_bucket(bufmgr, 4096);
-   add_bucket(bufmgr, 4096 * 2);
-   add_bucket(bufmgr, 4096 * 3);
+   add_bucket(bufmgr, PAGE_SIZE);
+   add_bucket(bufmgr, PAGE_SIZE * 2);
+   add_bucket(bufmgr, PAGE_SIZE * 3);

    /* Initialize the linked lists for BO reuse cache. */
-   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
+   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
       add_bucket(bufmgr, size);

       add_bucket(bufmgr, size + size * 1 / 4);
@@ -1729,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info
*devinfo, int fd)
          bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;

         
util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
-                            4096, _4GB);
+                            PAGE_SIZE, _4GB);
         
util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
                             1 * _4GB, gtt_size - 1 * _4GB);
       } else if (devinfo->gen >= 10) {
-- 
2.7.4


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





--
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com 



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


Re: [Mesa-dev] [PATCH] radv/gfx9: implement coherent shaders for VK_ACCESS_SHADER_READ_BIT

2018-07-27 Thread Samuel Pitoiset



On 07/27/2018 04:39 PM, Bas Nieuwenhuizen wrote:

Did this pass CTS? If so, woot!


It did.



Reviewed-by: Bas Nieuwenhuizen 

btw we can avoid some more, I think literally everything on Vega uses
L2 so the VERTEX_ATTRIBUTE_READ, TRANSFER_READ (this one could use CP
DMA, but not for images, and CP DMA can be configured to go through
L2) and INPUT_ATTACHMENT_READ which are pretty much the same should be
OK too.


Sure, this is a first attempt at reducing flushes on GFX9.



On Fri, Jul 27, 2018 at 4:14 PM, Samuel Pitoiset
 wrote:

Single-sample color and single-sample depth (not stencil)
are coherent with shaders.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 21 -
  1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index e0222d0b50..b557f5a92c 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2022,6 +2022,7 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
 bool flush_CB_meta = true, flush_DB_meta = true;
 enum radv_cmd_flush_bits flush_bits = 0;
 bool flush_CB = true, flush_DB = true;
+   bool image_is_coherent = false;
 uint32_t b;

 if (image) {
@@ -2034,6 +2035,19 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
 flush_CB_meta = false;
 if (!radv_image_has_htile(image))
 flush_DB_meta = false;
+
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
GFX9) {
+   if (image->info.samples == 1 &&
+   (image->usage & 
(VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
+
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) &&
+   !vk_format_is_stencil(image->vk_format)) {
+   /* Single-sample color and single-sample depth
+* (not stencil) are coherent with shaders on
+* GFX9.
+*/
+   image_is_coherent = true;
+   }
+   }
 }

 for_each_bit(b, dst_flags) {
@@ -2045,12 +2059,17 @@ radv_dst_access_flush(struct radv_cmd_buffer 
*cmd_buffer,
 flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 | 
RADV_CMD_FLAG_INV_SMEM_L1;
 break;
 case VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT:
-   case VK_ACCESS_SHADER_READ_BIT:
 case VK_ACCESS_TRANSFER_READ_BIT:
 case VK_ACCESS_INPUT_ATTACHMENT_READ_BIT:
 flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 |
   RADV_CMD_FLAG_INV_GLOBAL_L2;
 break;
+   case VK_ACCESS_SHADER_READ_BIT:
+   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1;
+
+   if (!image_is_coherent)
+   flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2;
+   break;
 case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
 if (flush_CB)
 flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
--
2.18.0

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

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


[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized when compiling with -fstack-protector

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107369

--- Comment #11 from Jan Vesely  ---
GPUs don't really have a stack (not for data anyway) and AMDGCN backend
currently inlines all function calls anyway.
I'm not sure what kind of checks the flag adds.
If anyone can upload the different libclc bitcode it should be easy to spot.
My guess would be that it adds some initialized global variables used in
internal checks. This is illegal in CLC. only variables in constant address
space can have initializers.

IMO Debian should not be arbitrarily adding compilation flags unless they know
what they're doing and they have tested the resulting package.

local variables are stored in private address space which is backed either by
register file, or private buffers.
using volatile, to control where it is located, is a rather hacky workaround of
suboptimal register allocation/instruction scheduling.
Reporting a llvm bug with a reproducer can help. it'd need to be reproducible
using llvm-7, there are no further releases of llvm-5 or 6 planned.

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


Re: [Mesa-dev] [PATCH] i965: Disable guardband clipping on SandyBridge for odd dimensions

2018-07-27 Thread Vadim Shovkoplias
Hi Rafael,

Thanks a lot for reviewing the patch! Hopefully no one will have any
objections to push this.

Thanks,
Vadym

2018-07-26 18:11 GMT+03:00 Rafael Antognolli :

> Hi Vadym,
>
> Ken and Ian explained a bit the situation on this one to me, and it
> looks like neither of them are really against this patch. So unless
> someone else raise any concern, I'll ack and push the patch later today.
>
> Thanks for fixing this.
>
> Rafael
>
> On Thu, Jul 26, 2018 at 04:04:29PM +0300, Vadym Shovkoplias wrote:
> > ping
> >
> > On Tue, Jul 3, 2018 at 5:09 PM, Vadim Shovkoplias <
> vadim.shovkopl...@gmail.com>
> > wrote:
> >
> > Hi mesa devs,
> >
> > Can anyone please review this ?
> > This patch fixes following bugs:
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104388
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106158
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106667
> >
> >
> > 2018-06-07 18:27 GMT+03:00 Vadim Shovkoplias <
> vadim.shovkopl...@gmail.com>:
> >
> > Hi Kenneth,
> >
> > Can you please look at this patch ?
> >
> > 2018-06-07 15:30 GMT+03:00 Den :
> >
> > Hello. Found out that this patch also fixes 2 new issues:
> >
> > Bugzilla: https://bugs.freedesktop.org/
> show_bug.cgi?id=106158
> >
> > Bugzilla: https://bugs.freedesktop.org/
> show_bug.cgi?id=106667
> >
> > Tested-by: Denis 
> >
> >
> >
> > On 24.05.18 14:16, vadym.shovkoplias wrote:
> >
> > Bugzilla: https://bugs.freedesktop.org/
> show_bug.cgi?id=104388
> > Signed-off-by: Andriy Khulap <
> andriy.khu...@globallogic.com>
> > ---
> >   src/mesa/drivers/dri/i965/genX_state_upload.c | 11
> > +++
> >   1 file changed, 11 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/
> > src/mesa/drivers/dri/i965/genX_state_upload.c
> > index b485e2c..5aa8033 100644
> > --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> > +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> > @@ -2473,6 +2473,17 @@ brw_calculate_guardband_size(
> uint32_t
> > fb_width, uint32_t fb_height,
> >   */
> >  const float gb_size = GEN_GEN >= 7 ? 16384.0f :
> 8192.0f;
> >   +   /* Workaround: prevent gpu hangs on SandyBridge
> > +* by disabling guardband clipping for odd
> dimensions.
> > +*/
> > +   if (GEN_GEN == 6 && (fb_width & 1 || fb_height & 1))
> {
> > +  *xmin = -1.0f;
> > +  *xmax =  1.0f;
> > +  *ymin = -1.0f;
> > +  *ymax =  1.0f;
> > +  return;
> > +   }
> > +
> >  if (m00 != 0 && m11 != 0) {
> > /* First, we compute the screen-space render
> area */
> > const float ss_ra_xmin = MIN3(0, m30 +
> m00, m30
> > - m00);
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
> >
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
> >
> >
> >
> > --
> >
> > Vadym Shovkoplias | Senior Software Engineer
> > GlobalLogic
> > P +380.57.766.7667  M +3.8050.931.7304  S vadym.shovkoplias
> > www.globallogic.com
> >
> > http://www.globallogic.com/email_disclaimer.txt
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radv/gfx9: implement coherent shaders for VK_ACCESS_SHADER_READ_BIT

2018-07-27 Thread Bas Nieuwenhuizen
Did this pass CTS? If so, woot!

Reviewed-by: Bas Nieuwenhuizen 

btw we can avoid some more, I think literally everything on Vega uses
L2 so the VERTEX_ATTRIBUTE_READ, TRANSFER_READ (this one could use CP
DMA, but not for images, and CP DMA can be configured to go through
L2) and INPUT_ATTACHMENT_READ which are pretty much the same should be
OK too.

On Fri, Jul 27, 2018 at 4:14 PM, Samuel Pitoiset
 wrote:
> Single-sample color and single-sample depth (not stencil)
> are coherent with shaders.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index e0222d0b50..b557f5a92c 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2022,6 +2022,7 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> bool flush_CB_meta = true, flush_DB_meta = true;
> enum radv_cmd_flush_bits flush_bits = 0;
> bool flush_CB = true, flush_DB = true;
> +   bool image_is_coherent = false;
> uint32_t b;
>
> if (image) {
> @@ -2034,6 +2035,19 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> flush_CB_meta = false;
> if (!radv_image_has_htile(image))
> flush_DB_meta = false;
> +
> +   if (cmd_buffer->device->physical_device->rad_info.chip_class 
> >= GFX9) {
> +   if (image->info.samples == 1 &&
> +   (image->usage & 
> (VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
> +
> VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) &&
> +   !vk_format_is_stencil(image->vk_format)) {
> +   /* Single-sample color and single-sample depth
> +* (not stencil) are coherent with shaders on
> +* GFX9.
> +*/
> +   image_is_coherent = true;
> +   }
> +   }
> }
>
> for_each_bit(b, dst_flags) {
> @@ -2045,12 +2059,17 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 | 
> RADV_CMD_FLAG_INV_SMEM_L1;
> break;
> case VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT:
> -   case VK_ACCESS_SHADER_READ_BIT:
> case VK_ACCESS_TRANSFER_READ_BIT:
> case VK_ACCESS_INPUT_ATTACHMENT_READ_BIT:
> flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 |
>   RADV_CMD_FLAG_INV_GLOBAL_L2;
> break;
> +   case VK_ACCESS_SHADER_READ_BIT:
> +   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1;
> +
> +   if (!image_is_coherent)
> +   flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2;
> +   break;
> case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
> if (flush_CB)
> flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] mesa: remove unneeded free() call in texstore_rgba()

2018-07-27 Thread Brian Paul
The pointer will always be NULL since that's what we just tested for.
---
 src/mesa/main/texstore.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index 31163f6..c7a459e 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -764,7 +764,6 @@ texstore_rgba(TEXSTORE_PARAMS)
   tempRGBA = malloc(4 * elementCount * sizeof(float));
   if (!tempRGBA) {
  free(tempImage);
- free(tempRGBA);
  return GL_FALSE;
   }
 
-- 
2.7.4

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


[Mesa-dev] [PATCH 2/2] mesa: move var decls in texstore_rgba()

2018-07-27 Thread Brian Paul
Move them closer to where they're first used.
---
 src/mesa/main/texstore.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
index c7a459e..55f66c5 100644
--- a/src/mesa/main/texstore.c
+++ b/src/mesa/main/texstore.c
@@ -673,12 +673,10 @@ texstore_compressed(TEXSTORE_PARAMS)
 static GLboolean
 texstore_rgba(TEXSTORE_PARAMS)
 {
-   void *tempImage = NULL, *tempRGBA = NULL;
-   int srcRowStride, img;
+   void *tempImage = NULL;
+   int img;
GLubyte *src, *dst;
-   uint32_t srcMesaFormat;
uint8_t rebaseSwizzle[4];
-   bool needRebase;
bool transferOpsDone = false;
 
/* We have to handle MESA_FORMAT_YCBCR manually because it is a special case
@@ -748,15 +746,18 @@ texstore_rgba(TEXSTORE_PARAMS)
   }
}
 
-   srcRowStride =
+   int srcRowStride =
   _mesa_image_row_stride(srcPacking, srcWidth, srcFormat, srcType);
 
-   srcMesaFormat = _mesa_format_from_format_and_type(srcFormat, srcType);
+   uint32_t srcMesaFormat =
+  _mesa_format_from_format_and_type(srcFormat, srcType);
+
dstFormat = _mesa_get_srgb_format_linear(dstFormat);
 
/* If we have transferOps then we need to convert to RGBA float first,
   then apply transferOps, then do the conversion to dst
 */
+   void *tempRGBA = NULL;
if (!transferOpsDone &&
_mesa_texstore_needs_transfer_ops(ctx, baseInternalFormat, dstFormat)) {
   /* Allocate RGBA float image */
@@ -797,6 +798,7 @@ texstore_rgba(TEXSTORE_PARAMS)
   _mesa_image_address(dims, srcPacking, srcAddr, srcWidth, srcHeight,
   srcFormat, srcType, 0, 0, 0);
 
+   bool needRebase;
if (_mesa_get_format_base_format(dstFormat) != baseInternalFormat) {
   needRebase =
  _mesa_compute_rgba2base2rgba_component_mapping(baseInternalFormat,
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH v3] dri3: For 1.2, use root window instead of pixmap drawable

2018-07-27 Thread Olivier Fourdan
Hi,

On Thu, 26 Jul 2018 at 19:53, Eric Anholt  wrote:
>
> Olivier Fourdan  writes:
>
> > get_supported_modifiers() and pixmap_from_buffers() requests both
> > expect a window as drawable, passing a pixmap will fail as the Xserver
> > will fail to match the given drawable to a window.
> >
> > That leads to dri3_alloc_render_buffer() to return NULL and breaks
> > rendering when using GLX_DOUBLEBUFFER on pixmaps.
> >
> > Query the root window of the pixmap on first init, and use the root
> > window instead of the pixmap drawable for get_supported_modifiers()
> > and pixmap_from_buffers().
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107117
> > Fixes: 069fdd5 ("egl/x11: Support DRI3 v1.1")
> > Signed-off-by: Olivier Fourdan 
>
> Looks great!
>
> Reviewed-by: Eric Anholt 

Thanks both Daniel and Eric for the reviews!

If I may, could someone push that fix for me, I don't think I have
commit rights in Mesa...

(It's a regression affecting Mesa 18.1 with Xserver 1.20, would be
great to have it fixed)

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


[Mesa-dev] [PATCH] radv/gfx9: implement coherent shaders for VK_ACCESS_SHADER_READ_BIT

2018-07-27 Thread Samuel Pitoiset
Single-sample color and single-sample depth (not stencil)
are coherent with shaders.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index e0222d0b50..b557f5a92c 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2022,6 +2022,7 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
bool flush_CB_meta = true, flush_DB_meta = true;
enum radv_cmd_flush_bits flush_bits = 0;
bool flush_CB = true, flush_DB = true;
+   bool image_is_coherent = false;
uint32_t b;
 
if (image) {
@@ -2034,6 +2035,19 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
flush_CB_meta = false;
if (!radv_image_has_htile(image))
flush_DB_meta = false;
+
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
GFX9) {
+   if (image->info.samples == 1 &&
+   (image->usage & 
(VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT |
+
VK_IMAGE_USAGE_DEPTH_STENCIL_ATTACHMENT_BIT)) &&
+   !vk_format_is_stencil(image->vk_format)) {
+   /* Single-sample color and single-sample depth
+* (not stencil) are coherent with shaders on
+* GFX9.
+*/
+   image_is_coherent = true;
+   }
+   }
}
 
for_each_bit(b, dst_flags) {
@@ -2045,12 +2059,17 @@ radv_dst_access_flush(struct radv_cmd_buffer 
*cmd_buffer,
flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 | 
RADV_CMD_FLAG_INV_SMEM_L1;
break;
case VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT:
-   case VK_ACCESS_SHADER_READ_BIT:
case VK_ACCESS_TRANSFER_READ_BIT:
case VK_ACCESS_INPUT_ATTACHMENT_READ_BIT:
flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 |
  RADV_CMD_FLAG_INV_GLOBAL_L2;
break;
+   case VK_ACCESS_SHADER_READ_BIT:
+   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1;
+
+   if (!image_is_coherent)
+   flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2;
+   break;
case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
if (flush_CB)
flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
-- 
2.18.0

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


[Mesa-dev] [ANNOUNCE] mesa 18.1.5

2018-07-27 Thread Dylan Baker
Hi everyone,

I present to you the mesa 18.1.5 release, available now. The 18.1.5 cycle has
been rather busy, in fact, it's the busiest cycle since 18.1.2! Radv has gotten
the most work this cycle, with intel, nir, and the android build system coming 
up
behind it. Also getting various fixes this cycle are:

 - spriv
 - egl
 - disk cache
 - meson
 - autotools
 - vc4
 - core gallium
 - radeonsi
 - clover
 - virgl
 - st/mesa

Dylan


Shortlog


Alex Smith (1):
  anv: Pay attention to VK_ACCESS_MEMORY_(READ|WRITE)_BIT

Bas Nieuwenhuizen (7):
  radv: Select correct entries for binning.
  radv: Fix number of samples used for binning.
  radv: Disable disabled color buffers in rbplus opts.
  nir: Do not use continue block after removing it.
  util/disk_cache: Fix disk_cache_get_function_timestamp with disabled 
cache.
  nir: Fix end of function without return warning/error.
  radv: Still enable inmemory & API level caching if disk cache is not 
enabled.

Chad Versace (2):
  anv/android: Fix type error in call to vk_errorf()
  anv/android: Fix Autotools build for VK_ANDROID_native_buffer

Chih-Wei Huang (1):
  Android: fix a missing nir_intrinsics.h error

Danylo Piliaiev (1):
  i965: Sweep NIR after linking phase to free held memory

Dave Airlie (1):
  r600: enable tess_input_info for TES

Dylan Baker (6):
  docs: Add sha256 sums for 18.1.4 tarballs
  cherry-ignore: add 4a67ce886a7b3def5f66c1aedf9e5436d157a03c
  cherry-ignore: Add 1f616a840eac02241c585d28e9dac8f19a297f39
  cherry-ignore: add 11712b9ca17e4e1a819dcb7d020e19c6da77bc90
  bump version to 18.1.5
  docs: add 18.1.5 release notes

Eric Anholt (2):
  vc4: Don't automatically reallocate a PERSISTENT-mapped buffer.
  meson: Move xvmc test tools from unit tests to installed tools.

Harish Krupo (1):
  egl: Fix missing clamping in eglSetDamageRegionKHR

Jan Vesely (3):
  radeonsi: Refuse to accept code with unhandled relocations
  clover: Report error when pipe driver fails to create compute state
  clover: Catch errors from executing event action

Jason Ekstrand (6):
  anv: Stop setting 3DSTATE_PS_EXTRA::PixelShaderHasUAV
  nir/serialize: Alloc constants off the variable
  blorp: Handle the RGB workaround more like other workarounds
  intel/blorp: Handle 3-component formats in clears
  intel/compiler: Account for built-in uniforms in analyze_ubo_ranges
  spirv: Fix a couple of image atomic load/store bugs

José Fonseca (1):
  gallium/tests: Don't ignore S3TC errors.

Karol Herbst (1):
  nir: fix printing of vec16 type

Lepton Wu (1):
  virgl: Fix flush in virgl_encoder_inline_write.

Lucas Stach (1):
  st/mesa: call resource_changed when binding a EGLImage to a texture

Mauro Rossi (2):
  radv: winsys/amdgpu: include missing pthread.h header
  android: util/disk_cache: fix building errors in gallium drivers

Michel Dänzer (1):
  gallium: Check pipe_screen::resource_changed before dereferencing it

Roland Scheidegger (1):
  draw: force draw pipeline if there's more than 65535 vertices

Samuel Iglesias Gonsálvez (1):
  anv: fix assert in anv_CmdBindDescriptorSets()

Samuel Pitoiset (3):
  radv: make sure to wait for CP DMA when needed
  radv: emit a dummy ZPASS_DONE to prevent GPU hangs on GFX9
  radv: fix a memleak for merged shaders on GFX9


git tag: mesa-18.1.5

https://mesa.freedesktop.org/archive/mesa-18.1.5.tar.gz
MD5:  aec86f1101e25387932659ae09029f26  mesa-18.1.5.tar.gz
SHA1: 44a34cc8cee481aebcbb89f7962adfcc1e639c67  mesa-18.1.5.tar.gz
SHA256: f966d5d5d373a5b8a16ed5036c1e7f05d4ad46d130f793bf9782c3ac9133a02e  
mesa-18.1.5.tar.gz
SHA512: 
ea163180f555030631bccb5e19fdb161b4747ee6ae12278188dee8f616b73386afaaa8bb528515b34cdfef97b0225eee5355515eab834b759f0194a05952c6ca
  mesa-18.1.5.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.5.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-18.1.5.tar.xz
MD5:  622bd23ca8daa83a62938bd33600a580  mesa-18.1.5.tar.xz
SHA1: 1ca7d5f5d12c95f8da137be34223229b9f0594fe  mesa-18.1.5.tar.xz
SHA256: 69dbe6f1a6660386f5beb85d4fcf003ee23023ed7b9a603de84e9a37e8d98dea  
mesa-18.1.5.tar.xz
SHA512: 
f0bcb903bbf2ff7fc0b4a8fe100ea26ee91c0029b64adaf5fc4877ed7681f325c54b1be8eb0b140bff620da79f30a96375c2e1085e504ebfaf50e57f6da93013
  mesa-18.1.5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.5.tar.xz.sig


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


Re: [Mesa-dev] [PATCH v2 2/2] egl/surfaceless: Allow DRMless fallback.

2018-07-27 Thread Emil Velikov
On 27 July 2018 at 00:18, David Riley  wrote:

> I understand and agree with your comments about kms_swrast requiring KMS and
> not wanting to change those semantics.
>
> I'm not quite sure I follow all the rest of your suggestions (new to this
> entire code base).  You're suggesting that surfaceless move away from
> kms_swrast entirely?  Or just for the fallback path like I've got in these
> changes?
>
> With regards to your other suggestion I also don't follow. Are you're
> suggesting that createNewScreen3 for swrast should dispatch between
> dri2_init_screen/drisw_init_screen/dri_kms_init_screen based on some enum
> instead of a driver that has been loaded and it's vtable?
>
> I'm hoping to make some more targeted changes than major refactoring of code
> that I'm quite unfamiliar with.
>
Very few people are familiar with the DRI driver/loader interfaces.
I'm finishing something else atm and will work on this next week.

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


Re: [Mesa-dev] [RFC][PATCH 4/5] Android.mk: Add option to use vendor version of mesa

2018-07-27 Thread Emil Velikov
On 26 July 2018 at 18:38, John Stultz  wrote:
> On Thu, Jul 26, 2018 at 6:46 AM, Emil Velikov  
> wrote:
>> On 25 July 2018 at 20:52, John Stultz  wrote:
>>> On Wed, Jul 25, 2018 at 5:42 AM, Emil Velikov  
>>> wrote:
 On 25 July 2018 at 00:21, John Stultz  wrote:
> From: Yong Yao 
>
> This is a forward port of a patch from the AOSP/master branch:
> https://android.googlesource.com/platform/external/mesa3d/+/b1e5fad1db4c1d51c7ae3a033b100a8429ae5415%5E%21/
>
> Which allows boards to provide their own custom copy of mesa.
>
 Thanks for sorting these out John.

 My understanding was that when a custom project repo is used one
 handles that in the device manifest. Roughly as:
  - foo.xml -> contains vast majority of the git repos with associated 
 tags/etc
  - local.xml -> removes any repo/project from ^^, adds new one

 Is that no longer the case, or I simply misremember how Android does 
 things?
>>>
>>> So, I'm not aware of the specific history behind this patch. And I
>>> can't speak for Google, there has been a general push via the Treble
>>> efforts to standardize the Android system image, and to push vendors
>>> to keep any device specific bits into their own device directory.  So
>>> there is a strong disincentive to modify projects in AOSP and in order
>>> to include things like devboards into AOSP, the push has been to limit
>>> any device specific changes to only the device directory git tree.
>>>
>>> So while one can technically still replace projects with local repos
>>> (and this is very useful for development!), I think they do not want
>>> folks doing this for shipping devices.
>>>
>> Hmm using the word "local" brought some assumptions that were never made.
>> AFAICT the remove/add project manifest combo can be used local
>> changes/testing as well as for "shipping devices".
>> Can it not?
>>
>>> We are trying to make sure device support is pushed upstream to fdo,
>>> and then align AOSP's mesa to that, but one could imagine a board that
>>> doesn't have support upstream in mesa, and provides its own copy of
>>> mesa in the device directory. This patch allows the build to override
>>> the default mesa project with the vendor provided mesa.
>>>
>> Since the vendor will already need to add the project (git repo etc),
>> what is the blocker from removing the existing one beforehand?
>> Last I've tried - the repo tool gives you a nice and clear
>> warning/error message.
>>
>> There is one case where this patch is a must. If repo forbids removing
>> "core" Android projects via the manifest.
>
> I'm not saying the repo tool at all forbids removing/replacing entries
> in the manifest. Its just a tool.
>
> I'm saying that if someone is replacing git trees that are part of the
> system image in a shipping device, my understanding is they are likely
> going to have more problems with treble compliance. There are probably
> technical loopholes folks can get through and still do it, but I think
> generally its becoming frowned upon.
>
> Its possible, but I doubt they would chose to enforce this policy via
> the repo tool.
>
> Regardless, I'm not sure why such a trivial change to the Android.mk
> that the Android developers found useful is cause for much objection,
> but this one seems more trouble then its worth, so I'll drop it.
>
I'm fairly worried (this and 5/5) a couple of reasons:
 - there seems to be a better way to handle this
 - similar one liners have caused breakage in the past - see libdrm
4dfa458979c345ea5eb46749f545d78c09e3f244

I do agree with RobH - vendors should target upstream and resort to
fork/custom Mesa only when absolutely needed.

That said, I will repeat/rephrase an earlier comment of mine:
Hacks could be merged, as long as they're properly documented and
there's an outline for a long term solution.
That's my personal take - others may disagree.

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


Re: [Mesa-dev] [PATCH] intel/compiler: fix lower conversions to account for predication

2018-07-27 Thread Iago Toral
On Thu, 2018-07-26 at 11:30 +0200, Chema Casanova wrote:
> Please include:
> 
> Fixes: 5a12bdac09496e00 "i965/compiler: handle conversion to smaller
>  type in the lowering pass for that"

This is not specifically fixing that commit, the problem has been there
before that commit.

Iago

> Reviewed-by: Jose Maria Casanova Crespo 
> 
> El 17/07/18 a las 11:10, Iago Toral Quiroga escribió:
> > The pass can create a temporary result for the instruction and then
> > moves from it to the original destination, however, if the original
> > instruction was predicated, the mov has to be predicated as well.
> > ---
> >  src/intel/compiler/brw_fs_lower_conversions.cpp | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/compiler/brw_fs_lower_conversions.cpp
> > b/src/intel/compiler/brw_fs_lower_conversions.cpp
> > index e27e2402746..145fb55f995 100644
> > --- a/src/intel/compiler/brw_fs_lower_conversions.cpp
> > +++ b/src/intel/compiler/brw_fs_lower_conversions.cpp
> > @@ -98,7 +98,10 @@ fs_visitor::lower_conversions()
> >   * size_written accordingly.
> >   */
> >  inst->size_written = inst->dst.component_size(inst-
> > >exec_size);
> > -ibld.at(block, inst->next).MOV(dst, strided_temp)-
> > >saturate = saturate;
> > +
> > +fs_inst *mov = ibld.at(block, inst->next).MOV(dst,
> > strided_temp);
> > +mov->saturate = saturate;
> > +mov->predicate = inst->predicate;
> >  
> >  progress = true;
> >   }
> > 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 2/2] intel/compiler: implement 8-bit constant load

2018-07-27 Thread Jose Maria Casanova Crespo
From: Iago Toral Quiroga 

---
 src/intel/compiler/brw_fs_nir.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 2c8595b9730..6e9a5829d3b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -1587,6 +1587,11 @@ fs_visitor::nir_emit_load_const(const fs_builder ,
fs_reg reg = bld.vgrf(reg_type, instr->def.num_components);
 
switch (instr->def.bit_size) {
+   case 8:
+  for (unsigned i = 0; i < instr->def.num_components; i++)
+ bld.MOV(offset(reg, bld, i), setup_imm_b(bld, instr->value.i8[i]));
+  break;
+
case 16:
   for (unsigned i = 0; i < instr->def.num_components; i++)
  bld.MOV(offset(reg, bld, i), brw_imm_w(instr->value.i16[i]));
-- 
2.17.1

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


[Mesa-dev] [PATCH 0/2] intel/compiler: Enable 8-bit constants

2018-07-27 Thread Jose Maria Casanova Crespo
New VK-GL-CTS tests that use VK_KHR_8bit_storage extension use
32-bit constants that are converted to 8-bit and there are stored in a
storage buffer.

Although 8-bit constants are not enabled by VK_KHR_8bit_storage
nir_opt_constant_folding already optimizes the 32 -> 8 integer
conversion to a 8-bit constant.

So we enable them in next two patches to not assert in this scenario.

Cc: Iago Toral Quiroga 
Cc: Jason Ekstrand 

Iago Toral Quiroga (2):
  intel/compiler: add setup_imm_(u)b helpers
  intel/compiler: implement 8-bit constant load

 src/intel/compiler/brw_fs.h   |  6 ++
 src/intel/compiler/brw_fs_nir.cpp | 21 +
 2 files changed, 27 insertions(+)

-- 
2.17.1

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


[Mesa-dev] [PATCH 1/2] intel/compiler: add setup_imm_(u)b helpers

2018-07-27 Thread Jose Maria Casanova Crespo
From: Iago Toral Quiroga 

The hardware doesn't support byte immediates, so similar to setup_imm_df()
for doubles, these helpers work by loading the constant value into a
VGRF.
---
 src/intel/compiler/brw_fs.h   |  6 ++
 src/intel/compiler/brw_fs_nir.cpp | 16 
 2 files changed, 22 insertions(+)

diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index 8ccd1659075..d56e33715ee 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -540,6 +540,12 @@ fs_reg shuffle_for_32bit_write(const brw::fs_builder ,
 fs_reg setup_imm_df(const brw::fs_builder ,
 double v);
 
+fs_reg setup_imm_b(const brw::fs_builder ,
+   int8_t v);
+
+fs_reg setup_imm_ub(const brw::fs_builder ,
+   uint8_t v);
+
 enum brw_barycentric_mode brw_barycentric_mode(enum glsl_interp_mode mode,
nir_intrinsic_op op);
 
diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index a41dc2a47b8..2c8595b9730 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -5396,3 +5396,19 @@ setup_imm_df(const fs_builder , double v)
 
return component(retype(tmp, BRW_REGISTER_TYPE_DF), 0);
 }
+
+fs_reg
+setup_imm_b(const fs_builder , int8_t v)
+{
+   const fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_B);
+   bld.MOV(tmp, brw_imm_w(v));
+   return tmp;
+}
+
+fs_reg
+setup_imm_ub(const fs_builder , uint8_t v)
+{
+   const fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_UB);
+   bld.MOV(tmp, brw_imm_uw(v));
+   return tmp;
+}
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH 1/2] radv: check CS space in radv_emit_write_data_packet()

2018-07-27 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

for the series

On Fri, Jul 27, 2018 at 11:28 AM, Samuel Pitoiset
 wrote:
> This wasn't wrong but it looks better to me like this. It's
> only used for debugging purposes (ie. RADV_TRACE_FILE).
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 26 --
>  1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index f9f57a1065..131ea18b15 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -429,9 +429,13 @@ radv_cmd_buffer_upload_data(struct radv_cmd_buffer 
> *cmd_buffer,
>  }
>
>  static void
> -radv_emit_write_data_packet(struct radeon_cmdbuf *cs, uint64_t va,
> +radv_emit_write_data_packet(struct radv_cmd_buffer *cmd_buffer, uint64_t va,
> unsigned count, const uint32_t *data)
>  {
> +   struct radeon_cmdbuf *cs = cmd_buffer->cs;
> +
> +   radeon_check_space(cmd_buffer->device->ws, cs, 4 + count);
> +
> radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 2 + count, 0));
> radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
> S_370_WR_CONFIRM(1) |
> @@ -451,10 +455,12 @@ void radv_cmd_buffer_trace_emit(struct radv_cmd_buffer 
> *cmd_buffer)
> if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_SECONDARY)
> va += 4;
>
> -   MAYBE_UNUSED unsigned cdw_max = 
> radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs, 7);
> -
> ++cmd_buffer->state.trace_id;
> -   radv_emit_write_data_packet(cs, va, 1, _buffer->state.trace_id);
> +   radv_emit_write_data_packet(cmd_buffer, va, 1,
> +   _buffer->state.trace_id);
> +
> +   radeon_check_space(cmd_buffer->device->ws, cs, 2);
> +
> radeon_emit(cs, PKT3(PKT3_NOP, 0, 0));
> radeon_emit(cs, AC_ENCODE_TRACE_POINT(cmd_buffer->state.trace_id));
>  }
> @@ -493,7 +499,6 @@ radv_save_pipeline(struct radv_cmd_buffer *cmd_buffer,
>struct radv_pipeline *pipeline, enum ring_type ring)
>  {
> struct radv_device *device = cmd_buffer->device;
> -   struct radeon_cmdbuf *cs = cmd_buffer->cs;
> uint32_t data[2];
> uint64_t va;
>
> @@ -510,13 +515,10 @@ radv_save_pipeline(struct radv_cmd_buffer *cmd_buffer,
> assert(!"invalid ring type");
> }
>
> -   MAYBE_UNUSED unsigned cdw_max = radeon_check_space(device->ws,
> -  cmd_buffer->cs, 6);
> -
> data[0] = (uintptr_t)pipeline;
> data[1] = (uintptr_t)pipeline >> 32;
>
> -   radv_emit_write_data_packet(cs, va, 2, data);
> +   radv_emit_write_data_packet(cmd_buffer, va, 2, data);
>  }
>
>  void radv_set_descriptor_set(struct radv_cmd_buffer *cmd_buffer,
> @@ -540,22 +542,18 @@ radv_save_descriptors(struct radv_cmd_buffer 
> *cmd_buffer,
> struct radv_descriptor_state *descriptors_state =
> radv_get_descriptors_state(cmd_buffer, bind_point);
> struct radv_device *device = cmd_buffer->device;
> -   struct radeon_cmdbuf *cs = cmd_buffer->cs;
> uint32_t data[MAX_SETS * 2] = {};
> uint64_t va;
> unsigned i;
> va = radv_buffer_get_va(device->trace_bo) + 24;
>
> -   MAYBE_UNUSED unsigned cdw_max = radeon_check_space(device->ws,
> -  cmd_buffer->cs, 4 
> + MAX_SETS * 2);
> -
> for_each_bit(i, descriptors_state->valid) {
> struct radv_descriptor_set *set = descriptors_state->sets[i];
> data[i * 2] = (uintptr_t)set;
> data[i * 2 + 1] = (uintptr_t)set >> 32;
> }
>
> -   radv_emit_write_data_packet(cs, va, MAX_SETS * 2, data);
> +   radv_emit_write_data_packet(cmd_buffer, va, MAX_SETS * 2, data);
>  }
>
>  struct radv_userdata_info *
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 107351] Android 8.1: radv segfault with 3Dmark vulkan benchmarks

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107351

--- Comment #13 from Mauro Rossi  ---
Hi,

but the sequence of ALOGD customized LOG_TAG RADV log does tell that the line
invoking pAllocator argument was the first not being executed, and thus is
involved in the segfault,

could you please give an advice on how to modify the ALOGD arguments in a way
it may be more useful?
Thanks
Mauro

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


Re: [Mesa-dev] [PATCH 1/2] radv: reduce CB/DB meta flushes in radv_dst_access_flush()

2018-07-27 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizeh 

for the series.

On Fri, Jul 27, 2018 at 11:55 AM, Samuel Pitoiset
 wrote:
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 31 +++
>  1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index f9f57a1065..2e65be4f30 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2019,8 +2019,23 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
>VkAccessFlags dst_flags,
>struct radv_image *image)
>  {
> +   bool flush_CB_meta = true, flush_DB_meta = true;
> enum radv_cmd_flush_bits flush_bits = 0;
> +   bool flush_CB = true, flush_DB = true;
> uint32_t b;
> +
> +   if (image) {
> +   if (!(image->usage & VK_IMAGE_USAGE_STORAGE_BIT)) {
> +   flush_CB = false;
> +   flush_DB = false;
> +   }
> +
> +   if (!radv_image_has_CB_metadata(image))
> +   flush_CB_meta = false;
> +   if (!radv_image_has_htile(image))
> +   flush_DB_meta = false;
> +   }
> +
> for_each_bit(b, dst_flags) {
> switch ((VkAccessFlagBits)(1 << b)) {
> case VK_ACCESS_INDIRECT_COMMAND_READ_BIT:
> @@ -2037,16 +2052,16 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
>   RADV_CMD_FLAG_INV_GLOBAL_L2;
> break;
> case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
> -   /* TODO: change to image && when the image gets passed
> -* through from the subpass. */
> -   if (!image || (image->usage & 
> VK_IMAGE_USAGE_STORAGE_BIT))
> -   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
> - 
> RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
> +   if (flush_CB)
> +   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
> +   if (flush_CB_meta)
> +   flush_bits |= 
> RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
> break;
> case VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT:
> -   if (!image || (image->usage & 
> VK_IMAGE_USAGE_STORAGE_BIT))
> -   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB |
> - 
> RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
> +   if (flush_DB)
> +   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB;
> +   if (flush_DB_meta)
> +   flush_bits |= 
> RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
> break;
> default:
> break;
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 1/2] radv: reduce CB/DB meta flushes in radv_dst_access_flush()

2018-07-27 Thread Samuel Pitoiset
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f9f57a1065..2e65be4f30 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2019,8 +2019,23 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
   VkAccessFlags dst_flags,
   struct radv_image *image)
 {
+   bool flush_CB_meta = true, flush_DB_meta = true;
enum radv_cmd_flush_bits flush_bits = 0;
+   bool flush_CB = true, flush_DB = true;
uint32_t b;
+
+   if (image) {
+   if (!(image->usage & VK_IMAGE_USAGE_STORAGE_BIT)) {
+   flush_CB = false;
+   flush_DB = false;
+   }
+
+   if (!radv_image_has_CB_metadata(image))
+   flush_CB_meta = false;
+   if (!radv_image_has_htile(image))
+   flush_DB_meta = false;
+   }
+
for_each_bit(b, dst_flags) {
switch ((VkAccessFlagBits)(1 << b)) {
case VK_ACCESS_INDIRECT_COMMAND_READ_BIT:
@@ -2037,16 +2052,16 @@ radv_dst_access_flush(struct radv_cmd_buffer 
*cmd_buffer,
  RADV_CMD_FLAG_INV_GLOBAL_L2;
break;
case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
-   /* TODO: change to image && when the image gets passed
-* through from the subpass. */
-   if (!image || (image->usage & 
VK_IMAGE_USAGE_STORAGE_BIT))
-   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
- 
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   if (flush_CB)
+   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
+   if (flush_CB_meta)
+   flush_bits |= 
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
break;
case VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT:
-   if (!image || (image->usage & 
VK_IMAGE_USAGE_STORAGE_BIT))
-   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB |
- 
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
+   if (flush_DB)
+   flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_DB;
+   if (flush_DB_meta)
+   flush_bits |= 
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META;
break;
default:
break;
-- 
2.18.0

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


[Mesa-dev] [PATCH 2/2] radv: do not emit pipeline stats flushes on compute queue

2018-07-27 Thread Samuel Pitoiset
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/si_cmd_buffer.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index e2bdbe889a..2337036c67 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -972,7 +972,9 @@ si_emit_cache_flush(struct radv_cmd_buffer *cmd_buffer)
  
RADV_CMD_FLAG_FLUSH_AND_INV_DB_META |
  
RADV_CMD_FLAG_PS_PARTIAL_FLUSH |
  
RADV_CMD_FLAG_VS_PARTIAL_FLUSH |
- RADV_CMD_FLAG_VGT_FLUSH);
+ RADV_CMD_FLAG_VGT_FLUSH |
+ 
RADV_CMD_FLAG_START_PIPELINE_STATS |
+ 
RADV_CMD_FLAG_STOP_PIPELINE_STATS);
 
if (!cmd_buffer->state.flush_bits)
return;
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH] ac: fix get_image_coords() for radeonsi

2018-07-27 Thread Timothy Arceri



On 27/07/18 19:10, Bas Nieuwenhuizen wrote:

On Fri, Jul 27, 2018 at 7:32 AM, Timothy Arceri  wrote:

Because this was setting image to true we would end up calling
si_load_image_desc() when we sould be calling
si_load_sampler_desc().


Since the descriptor is part of an image, not a sampler,
get_image_descriptor looks like the right thing to me?

What assertion are you getting?


LLVMValueRef si_load_image_desc(struct si_shader_context *ctx,
LLVMValueRef list, LLVMValueRef index,
enum ac_descriptor_type desc_type, bool dcc_off)
{
LLVMBuilderRef builder = ctx->ac.builder;
LLVMValueRef rsrc;

if (desc_type == AC_DESC_BUFFER) {
index = LLVMBuildMul(builder, index,
 LLVMConstInt(ctx->i32, 2, 0), "");
index = LLVMBuildAdd(builder, index,
 ctx->i32_1, "");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), 
"");
} else {
assert(desc_type == AC_DESC_IMAGE);
}

rsrc = ac_build_load_to_sgpr(>ac, list, index);
if (desc_type == AC_DESC_IMAGE && dcc_off)
rsrc = force_dcc_off(ctx, rsrc);
return rsrc;
}

vs

LLVMValueRef si_load_sampler_desc(struct si_shader_context *ctx,
  LLVMValueRef list, LLVMValueRef index,
  enum ac_descriptor_type type)
{
LLVMBuilderRef builder = ctx->ac.builder;

switch (type) {
case AC_DESC_IMAGE:
/* The image is at [0:7]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32, 2, 0), 
"");
break;
case AC_DESC_BUFFER:
/* The buffer is in [4:7]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32, 4, 0), 
"");
index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), 
"");
break;
case AC_DESC_FMASK:
/* The FMASK is at [8:15]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32, 2, 0), 
"");
index = LLVMBuildAdd(builder, index, ctx->i32_1, "");
break;
case AC_DESC_SAMPLER:
/* The sampler state is at [12:15]. */
index = LLVMBuildMul(builder, index, LLVMConstInt(ctx->i32, 4, 0), 
"");
index = LLVMBuildAdd(builder, index, LLVMConstInt(ctx->i32, 3, 0), 
"");
list = LLVMBuildPointerCast(builder, list,
ac_array_in_const32_addr_space(ctx->v4i32), 
"");
break;
}

return ac_build_load_to_sgpr(>ac, list, index);
}




This fixes an assert() in Deus Ex: MD
---
  src/amd/common/ac_nir_to_llvm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index cffc980e51f..fa934e6702e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2250,7 +2250,8 @@ static void get_image_coords(struct ac_nir_context *ctx,

fmask_load_address[1],

fmask_load_address[2],
sample_index,
-  
get_image_descriptor(ctx, instr, AC_DESC_FMASK, false));
+  get_sampler_desc(ctx, 
nir_instr_as_deref(instr->src[0].ssa->parent_instr),
+   
AC_DESC_FMASK, NULL, false, false));
 }
 if (count == 1 && !gfx9_1d) {
 if (instr->src[1].ssa->num_components)
--
2.17.1

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

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


[Mesa-dev] [Bug 107385] full Screen Corruption when a program is fullscreen

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107385

Michel Dänzer  changed:

   What|Removed |Added

Version|unspecified |git
   Assignee|mesa-dev@lists.freedesktop. |xorg-driver-...@lists.x.org
   |org |
Product|Mesa|xorg
 QA Contact|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |
  Component|Other   |Driver/Radeon

--- Comment #9 from Michel Dänzer  ---
I was able to reproduce the problem. It's a regression of xf86-video-amdgpu
with Xorg < 1.20. https://patchwork.freedesktop.org/patch/241330/ fixes it.

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


[Mesa-dev] [PATCH 1/2] radv: check CS space in radv_emit_write_data_packet()

2018-07-27 Thread Samuel Pitoiset
This wasn't wrong but it looks better to me like this. It's
only used for debugging purposes (ie. RADV_TRACE_FILE).

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f9f57a1065..131ea18b15 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -429,9 +429,13 @@ radv_cmd_buffer_upload_data(struct radv_cmd_buffer 
*cmd_buffer,
 }
 
 static void
-radv_emit_write_data_packet(struct radeon_cmdbuf *cs, uint64_t va,
+radv_emit_write_data_packet(struct radv_cmd_buffer *cmd_buffer, uint64_t va,
unsigned count, const uint32_t *data)
 {
+   struct radeon_cmdbuf *cs = cmd_buffer->cs;
+
+   radeon_check_space(cmd_buffer->device->ws, cs, 4 + count);
+
radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 2 + count, 0));
radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
S_370_WR_CONFIRM(1) |
@@ -451,10 +455,12 @@ void radv_cmd_buffer_trace_emit(struct radv_cmd_buffer 
*cmd_buffer)
if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_SECONDARY)
va += 4;
 
-   MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs, 7);
-
++cmd_buffer->state.trace_id;
-   radv_emit_write_data_packet(cs, va, 1, _buffer->state.trace_id);
+   radv_emit_write_data_packet(cmd_buffer, va, 1,
+   _buffer->state.trace_id);
+
+   radeon_check_space(cmd_buffer->device->ws, cs, 2);
+
radeon_emit(cs, PKT3(PKT3_NOP, 0, 0));
radeon_emit(cs, AC_ENCODE_TRACE_POINT(cmd_buffer->state.trace_id));
 }
@@ -493,7 +499,6 @@ radv_save_pipeline(struct radv_cmd_buffer *cmd_buffer,
   struct radv_pipeline *pipeline, enum ring_type ring)
 {
struct radv_device *device = cmd_buffer->device;
-   struct radeon_cmdbuf *cs = cmd_buffer->cs;
uint32_t data[2];
uint64_t va;
 
@@ -510,13 +515,10 @@ radv_save_pipeline(struct radv_cmd_buffer *cmd_buffer,
assert(!"invalid ring type");
}
 
-   MAYBE_UNUSED unsigned cdw_max = radeon_check_space(device->ws,
-  cmd_buffer->cs, 6);
-
data[0] = (uintptr_t)pipeline;
data[1] = (uintptr_t)pipeline >> 32;
 
-   radv_emit_write_data_packet(cs, va, 2, data);
+   radv_emit_write_data_packet(cmd_buffer, va, 2, data);
 }
 
 void radv_set_descriptor_set(struct radv_cmd_buffer *cmd_buffer,
@@ -540,22 +542,18 @@ radv_save_descriptors(struct radv_cmd_buffer *cmd_buffer,
struct radv_descriptor_state *descriptors_state =
radv_get_descriptors_state(cmd_buffer, bind_point);
struct radv_device *device = cmd_buffer->device;
-   struct radeon_cmdbuf *cs = cmd_buffer->cs;
uint32_t data[MAX_SETS * 2] = {};
uint64_t va;
unsigned i;
va = radv_buffer_get_va(device->trace_bo) + 24;
 
-   MAYBE_UNUSED unsigned cdw_max = radeon_check_space(device->ws,
-  cmd_buffer->cs, 4 + 
MAX_SETS * 2);
-
for_each_bit(i, descriptors_state->valid) {
struct radv_descriptor_set *set = descriptors_state->sets[i];
data[i * 2] = (uintptr_t)set;
data[i * 2 + 1] = (uintptr_t)set >> 32;
}
 
-   radv_emit_write_data_packet(cs, va, MAX_SETS * 2, data);
+   radv_emit_write_data_packet(cmd_buffer, va, MAX_SETS * 2, data);
 }
 
 struct radv_userdata_info *
-- 
2.18.0

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


[Mesa-dev] [PATCH 2/2] radv: allocate enough space in radv_cmd_buffer_after_draw()

2018-07-27 Thread Samuel Pitoiset
The driver might emit up to 4 dwords when RADV_TRACE_FILE is
used.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 131ea18b15..064eeb1c03 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -482,6 +482,8 @@ radv_cmd_buffer_after_draw(struct radv_cmd_buffer 
*cmd_buffer,
ptr = _buffer->gfx9_fence_idx;
}
 
+   radeon_check_space(cmd_buffer->device->ws, cmd_buffer->cs, 4);
+
/* Force wait for graphics or compute engines to be idle. */
si_cs_emit_cache_flush(cmd_buffer->cs,
   
cmd_buffer->device->physical_device->rad_info.chip_class,
-- 
2.18.0

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


[Mesa-dev] [Bug 102315] GPU Hang when replaying API trace of lightsmark

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102315

Denis  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Denis  ---
Hi Jason.

I checked attached apitrace and found out that it crashes gapitrace tool with
signal 11 (KBL). After checking also found out that trace file doesn't contain
gl context creation thus making replay invalid.

BUT - it works without crash on Sandy Bridge PC (slowly, with lags, but without
crashes).

So to summarize, there were no any gpu hangs on SNB. Notify please if this
issue still actual for you and please provide your CPU gen.

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


Re: [Mesa-dev] [PATCH 1/3] ac/surface: fix MSAA corruption on Vega due to FMASK tile swizzle

2018-07-27 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

Does it occur often that they are different?

On Fri, Jul 27, 2018 at 5:36 AM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> a needle in the haystack?
>
> Cc: 18.1 
> ---
>  src/amd/common/ac_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index afdae1971e9..2f4f0f8884f 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -1295,21 +1295,21 @@ static int gfx9_compute_miptree(ADDR_HANDLE addrlib,
> !(surf->flags & RADEON_SURF_SHAREABLE)) {
> ADDR2_COMPUTE_PIPEBANKXOR_INPUT xin = {0};
> ADDR2_COMPUTE_PIPEBANKXOR_OUTPUT xout = {0};
>
> xin.size = 
> sizeof(ADDR2_COMPUTE_PIPEBANKXOR_INPUT);
> xout.size = 
> sizeof(ADDR2_COMPUTE_PIPEBANKXOR_OUTPUT);
>
> /* This counter starts from 1 instead of 0. */
> xin.surfIndex = 
> p_atomic_inc_return(config->info.fmask_surf_index);
> xin.flags = in->flags;
> -   xin.swizzleMode = in->swizzleMode;
> +   xin.swizzleMode = fin.swizzleMode;
> xin.resourceType = in->resourceType;
> xin.format = in->format;
> xin.numSamples = in->numSamples;
> xin.numFrags = in->numFrags;
>
> ret = Addr2ComputePipeBankXor(addrlib, , 
> );
> if (ret != ADDR_OK)
> return ret;
>
> assert(xout.pipeBankXor <=
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] ac: fix get_image_coords() for radeonsi

2018-07-27 Thread Bas Nieuwenhuizen
On Fri, Jul 27, 2018 at 7:32 AM, Timothy Arceri  wrote:
> Because this was setting image to true we would end up calling
> si_load_image_desc() when we sould be calling
> si_load_sampler_desc().

Since the descriptor is part of an image, not a sampler,
get_image_descriptor looks like the right thing to me?

What assertion are you getting?

>
> This fixes an assert() in Deus Ex: MD
> ---
>  src/amd/common/ac_nir_to_llvm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index cffc980e51f..fa934e6702e 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2250,7 +2250,8 @@ static void get_image_coords(struct ac_nir_context *ctx,
>
> fmask_load_address[1],
>
> fmask_load_address[2],
>sample_index,
> -  
> get_image_descriptor(ctx, instr, AC_DESC_FMASK, false));
> +  
> get_sampler_desc(ctx, nir_instr_as_deref(instr->src[0].ssa->parent_instr),
> + 
>   AC_DESC_FMASK, NULL, false, false));
> }
> if (count == 1 && !gfx9_1d) {
> if (instr->src[1].ssa->num_components)
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] ac: pass write param to get_sampler_desc() from get_image_descriptor()

2018-07-27 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 
Fixes: 506a07e4e3a "ac/nir: Add deref support to image intrinsics."

On Fri, Jul 27, 2018 at 7:08 AM, Timothy Arceri  wrote:
> Looks like a mistake from when the deref stuff landed.
>
> Fixes: 506a07e4e3a4 ("ac/nir: Add deref support to image intrinsics.")
>
> Cc: Bas Nieuwenhuizen 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 44361be0d35..cffc980e51f 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2201,7 +2201,7 @@ static LLVMValueRef get_image_descriptor(struct 
> ac_nir_context *ctx,
>   enum ac_descriptor_type desc_type,
>   bool write)
>  {
> -   return get_sampler_desc(ctx, 
> nir_instr_as_deref(instr->src[0].ssa->parent_instr), desc_type, NULL, true, 
> true);
> +   return get_sampler_desc(ctx, 
> nir_instr_as_deref(instr->src[0].ssa->parent_instr), desc_type, NULL, true, 
> write);
>  }
>
>  static void get_image_coords(struct ac_nir_context *ctx,
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] intel/ppgtt: memory address alignment

2018-07-27 Thread Sergii Romantsov
Hello, Kenneth and Lionel.
Maybe, could we make a final review?

On Wed, Jul 25, 2018 at 4:24 PM, Sergii Romantsov <
sergii.romant...@globallogic.com> wrote:

> Sorry,
> do we have any objections about PAGE_SIZE usage instead of 4096?
>
> And what do you think if, maybe, some auto Intel-internal tests to run
> with that patch?
>
>
> On Wed, Jul 25, 2018 at 1:21 PM, Sergii Romantsov <
> sergii.romant...@gmail.com> wrote:
>
>> Kernel (for ppgtt) requires memory address to be
>> aligned to page size (4096).
>>
>> -v2: added marking that also fixes initial commit 01058a552294.
>> -v3: numbers replaced by PAGE_SIZE; buffer-object size is aligned
>> instead of alignment of offsets (Chris Wilson).
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106997
>> Fixes: a363bb2cd0e2 (i965: Allocate VMA in userspace for full-PPGTT
>> systems.)
>> Fixes: 01058a552294 (i965: Add virtual memory allocator infrastructure to
>> brw_bufmgr.)
>> Signed-off-by: Sergii Romantsov 
>> ---
>>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 19 +--
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> index 09d45e3..66d7751 100644
>> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
>> @@ -195,7 +195,7 @@ bo_tile_size(struct brw_bufmgr *bufmgr, uint64_t
>> size, uint32_t tiling)
>>return size;
>>
>> /* 965+ just need multiples of page size for tiling */
>> -   return ALIGN(size, 4096);
>> +   return ALIGN(size, PAGE_SIZE);
>>  }
>>
>>  /*
>> @@ -496,7 +496,6 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>uint32_t stride)
>>  {
>> struct brw_bo *bo;
>> -   unsigned int page_size = getpagesize();
>> int ret;
>> struct bo_cache_bucket *bucket;
>> bool alloc_from_cache;
>> @@ -522,12 +521,12 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
>>  * allocation up.
>>  */
>> if (bucket == NULL) {
>> -  bo_size = size;
>> -  if (bo_size < page_size)
>> - bo_size = page_size;
>> +  unsigned int page_size = getpagesize();
>> +  bo_size = ALIGN(size, page_size);
>> } else {
>>bo_size = bucket->size;
>> }
>> +   assert(bo_size);
>>
>> mtx_lock(>lock);
>> /* Get a buffer out of the cache if available */
>> @@ -1578,12 +1577,12 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
>>  * width/height alignment and rounding of sizes to pages will
>>  * get us useful cache hit rates anyway)
>>  */
>> -   add_bucket(bufmgr, 4096);
>> -   add_bucket(bufmgr, 4096 * 2);
>> -   add_bucket(bufmgr, 4096 * 3);
>> +   add_bucket(bufmgr, PAGE_SIZE);
>> +   add_bucket(bufmgr, PAGE_SIZE * 2);
>> +   add_bucket(bufmgr, PAGE_SIZE * 3);
>>
>> /* Initialize the linked lists for BO reuse cache. */
>> -   for (size = 4 * 4096; size <= cache_max_size; size *= 2) {
>> +   for (size = 4 * PAGE_SIZE; size <= cache_max_size; size *= 2) {
>>add_bucket(bufmgr, size);
>>
>>add_bucket(bufmgr, size + size * 1 / 4);
>> @@ -1729,7 +1728,7 @@ brw_bufmgr_init(struct gen_device_info *devinfo,
>> int fd)
>>   bufmgr->initial_kflags |= EXEC_OBJECT_PINNED;
>>
>>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_LOW_4G],
>> -4096, _4GB);
>> +PAGE_SIZE, _4GB);
>>   util_vma_heap_init(>vma_allocator[BRW_MEMZONE_OTHER],
>>  1 * _4GB, gtt_size - 1 * _4GB);
>>} else if (devinfo->gen >= 10) {
>> --
>> 2.7.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
> --
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com
>



-- 
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 107224] Incorrect Rendering in Deus Ex: Mankind Divided in-game menu

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107224

--- Comment #7 from Alex Smith  ---
Thanks for confirming.

It looks like we have a bug where we fail to identify Mesa properly as a result
of compatibility profile support being added, which causes us to go down a path
for a different driver that incorrectly adds that configuration option. That
then persists even after switching back to an older Mesa version.

We're looking into what we can do here, but I can confirm it is not a Mesa bug.

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


[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized when compiling with -fstack-protector

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107369

Gian-Carlo Pascutto  changed:

   What|Removed |Added

Summary|"volatile" in OpenCL code   |"volatile" in OpenCL code
   |not recognized by POLARIS10 |not recognized when
   |and KABINI  |compiling with
   ||-fstack-protector

--- Comment #10 from Gian-Carlo Pascutto  ---
infini

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


Re: [Mesa-dev] [PATCH 2/2] radv: fix cdw check vs tracing emit

2018-07-27 Thread Samuel Pitoiset

Series is:

Reviewed-by: Samuel Pitoiset 

On 07/27/2018 06:22 AM, Dave Airlie wrote:

From: Dave Airlie 

If we have tracing enabled we could do all the tracing emits
and overflow the precalculated cdw_max.
---
  src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f9f57a10656..aba3a835daa 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1752,10 +1752,10 @@ radv_flush_descriptors(struct radv_cmd_buffer 
*cmd_buffer,
descriptors_state->dirty = 0;
descriptors_state->push_dirty = false;
  
+	assert(cmd_buffer->cs->cdw <= cdw_max);

+
if (unlikely(cmd_buffer->device->trace_bo))
radv_save_descriptors(cmd_buffer, bind_point);
-
-   assert(cmd_buffer->cs->cdw <= cdw_max);
  }
  
  static void



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


[Mesa-dev] [PATCH v2 2/2] virgl: update virgl_hw.h from virglrenderer

2018-07-27 Thread Erik Faye-Lund
This just makes sure we're currently up-to-date with what
virglrenderer has.
---
 src/gallium/drivers/virgl/virgl_hw.h | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 059888b13b..51a325548b 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -37,6 +37,7 @@ enum virgl_formats {
VIRGL_FORMAT_B5G5R5A1_UNORM  = 5,
VIRGL_FORMAT_B4G4R4A4_UNORM  = 6,
VIRGL_FORMAT_B5G6R5_UNORM= 7,
+   VIRGL_FORMAT_R10G10B10A2_UNORM   = 8,
VIRGL_FORMAT_L8_UNORM= 9,/**< ubyte luminance */
VIRGL_FORMAT_A8_UNORM= 10,   /**< ubyte alpha */
VIRGL_FORMAT_L8A8_UNORM  = 12,   /**< ubyte alpha, luminance */
@@ -112,6 +113,8 @@ enum virgl_formats {
VIRGL_FORMAT_B10G10R10A2_UNORM   = 131,
VIRGL_FORMAT_R8G8B8X8_UNORM  = 134,
VIRGL_FORMAT_B4G4R4X4_UNORM  = 135,
+   VIRGL_FORMAT_X24S8_UINT  = 136,
+   VIRGL_FORMAT_S8X24_UINT  = 137,
VIRGL_FORMAT_B2G3R3_UNORM= 139,
 
VIRGL_FORMAT_L16A16_UNORM= 140,
@@ -186,14 +189,29 @@ enum virgl_formats {
VIRGL_FORMAT_L32_SINT= 223,
VIRGL_FORMAT_L32A32_SINT = 224,
 
-   VIRGL_FORMAT_B10G10R10A2_UINT= 225, 
+   VIRGL_FORMAT_B10G10R10A2_UINT= 225,
VIRGL_FORMAT_R8G8B8X8_SNORM  = 229,
 
VIRGL_FORMAT_R8G8B8X8_SRGB   = 230,
 
+   VIRGL_FORMAT_R8G8B8X8_UINT   = 231,
+   VIRGL_FORMAT_R8G8B8X8_SINT   = 232,
VIRGL_FORMAT_B10G10R10X2_UNORM   = 233,
VIRGL_FORMAT_R16G16B16X16_UNORM  = 234,
VIRGL_FORMAT_R16G16B16X16_SNORM  = 235,
+   VIRGL_FORMAT_R16G16B16X16_FLOAT  = 236,
+   VIRGL_FORMAT_R16G16B16X16_UINT   = 237,
+   VIRGL_FORMAT_R16G16B16X16_SINT   = 238,
+
+   VIRGL_FORMAT_R10G10B10A2_UINT= 253,
+
+   VIRGL_FORMAT_BPTC_RGBA_UNORM = 255,
+   VIRGL_FORMAT_BPTC_SRGBA  = 256,
+   VIRGL_FORMAT_BPTC_RGB_FLOAT  = 257,
+   VIRGL_FORMAT_BPTC_RGB_UFLOAT = 258,
+
+   VIRGL_FORMAT_R10G10B10X2_UNORM   = 308,
+   VIRGL_FORMAT_A4B4G4R4_UNORM  = 311,
VIRGL_FORMAT_MAX,
 };
 
@@ -205,6 +223,9 @@ enum virgl_formats {
 #define VIRGL_CAP_COPY_IMAGE   (1 << 3)
 #define VIRGL_CAP_TGSI_PRECISE (1 << 4)
 
+/* virgl bind flags - these are compatible with mesa 10.5 gallium.
+ * but are fixed, no other should be passed to virgl either.
+ */
 #define VIRGL_BIND_DEPTH_STENCIL (1 << 0)
 #define VIRGL_BIND_RENDER_TARGET (1 << 1)
 #define VIRGL_BIND_SAMPLER_VIEW  (1 << 3)
@@ -279,6 +300,10 @@ struct virgl_caps_v1 {
 uint32_t max_texture_gather_components;
 };
 
+/*
+ * This struct should be growable when used in capset 2,
+ * so we shouldn't have to add a v3 ever.
+ */
 struct virgl_caps_v2 {
 struct virgl_caps_v1 v1;
 float min_aliased_point_size;
-- 
2.18.0

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


[Mesa-dev] [PATCH v2 1/2] virgl: rename msaa_sample_positions -> sample_locations

2018-07-27 Thread Erik Faye-Lund
This matches what this field is called in virglrenderer's copy of
this.

While we're at it, fixup the indentation.

This reduces the diff between the two different versions of
virgl_hw.h, and should make it easier to upgrade the file in
the future.
---
 src/gallium/drivers/virgl/virgl_context.c | 8 
 src/gallium/drivers/virgl/virgl_hw.h  | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 74b232fe6c..832bd05efc 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -996,13 +996,13 @@ static void virgl_get_sample_position(struct pipe_context 
*ctx,
   out_value[0] = out_value[1] = 0.5f;
   return;
} else if (sample_count == 2) {
-  bits = vs->caps.caps.v2.msaa_sample_positions[0] >> (8 * index);
+  bits = vs->caps.caps.v2.sample_locations[0] >> (8 * index);
} else if (sample_count <= 4) {
-  bits = vs->caps.caps.v2.msaa_sample_positions[1] >> (8 * index);
+  bits = vs->caps.caps.v2.sample_locations[1] >> (8 * index);
} else if (sample_count <= 8) {
-  bits = vs->caps.caps.v2.msaa_sample_positions[2 + (index >> 2)] >> (8 * 
(index & 3));
+  bits = vs->caps.caps.v2.sample_locations[2 + (index >> 2)] >> (8 * 
(index & 3));
} else if (sample_count <= 16) {
-  bits = vs->caps.caps.v2.msaa_sample_positions[4 + (index >> 2)] >> (8 * 
(index & 3));
+  bits = vs->caps.caps.v2.sample_locations[4 + (index >> 2)] >> (8 * 
(index & 3));
}
out_value[0] = ((bits >> 4) & 0xf) / 16.0f;
out_value[1] = (bits & 0xf) / 16.0f;
diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 4469515dd1..059888b13b 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -303,7 +303,7 @@ struct virgl_caps_v2 {
 uint32_t uniform_buffer_offset_alignment;
 uint32_t shader_buffer_offset_alignment;
 uint32_t capability_bits;
-uint32_t msaa_sample_positions[8];
+uint32_t sample_locations[8];
 uint32_t max_vertex_attrib_stride;
 uint32_t max_shader_buffer_frag_compute;
 uint32_t max_shader_buffer_other_stages;
-- 
2.18.0

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


[Mesa-dev] [PATCH v2 0/2] virgl: synchronize virgl_hw.h with virglrenderer

2018-07-27 Thread Erik Faye-Lund
Here's a few patches to get the delta between our copy of virgl_hw.h and the
copy in the virglrenderer repository as small as possible.

The goal is to make it easier to track this file in the future by simply
copying the new version of the file on top of the old.

Changes since v2:
- Rebased on master
- Dropped "virgl: move bind-flags to virgl_winsys.h" as discussed in
  review.
- Updated "virgl: update virgl_hw.h from virglrenderer" to the latest
  master from virglrenderer.

Erik Faye-Lund (2):
  virgl: rename msaa_sample_positions -> sample_locations
  virgl: update virgl_hw.h from virglrenderer

 src/gallium/drivers/virgl/virgl_context.c |  8 +++
 src/gallium/drivers/virgl/virgl_hw.h  | 29 +--
 2 files changed, 31 insertions(+), 6 deletions(-)

-- 
2.18.0

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


Re: [Mesa-dev] [PATCH 2/3 v2] Android.common.mk: define HAVE_TIMESPEC_GET

2018-07-27 Thread Rob Herring
On Thu, Jul 26, 2018 at 12:28 PM John Stultz  wrote:
>
> From: Sumit Semwal 
>
> This is a forward port of a patch from the AOSP/master tree:
> https://android.googlesource.com/platform/external/mesa3d/+/bd30b663f55f8af73a0be4446349c5a2d4c641b0%5E%21/
>
> Since https://android-review.googlesource.com/c/718518 added
> timespec_get() to bionic, mesa3d doesn't build due to redefinition
> of timespec_get().
>
> Avoid redefinition by defining HAVE_TIMESPEC_GET flag.
>
> Test: build and boot tested db820c to UI.
>
> Cc: Rob Herring 
> Cc: Alistair Strachan 
> Cc: Marissa Wall 
> Cc: Sumit Semwal 
> Cc: Emil Velikov 
> Cc: Rob Clark 
> Reviewed-by: Emil Velikov 
> Signed-off-by: Sumit Semwal 
> Signed-off-by: John Stultz 
> ---
> v2: Conditionalize it for PLATFORM_VERSION Q and higher
> ---
>  Android.common.mk | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index 397dc03..3585470 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -89,6 +89,12 @@ LOCAL_CPPFLAGS += \
>  LOCAL_CONLYFLAGS += \
> -std=c99
>
> +# c11 timespec_get is part of bionic as well
> +# https://android-review.googlesource.com/c/718518
> +ifneq ($(shell [ "$(MESA_ANDROID_MAJOR_VERSION)" \< "Q" ]; echo $$?),0)

While master is a letter most of the time, it's a number in release
branches. I guess this happens to work with numbers too?, but can we
follow the same style as other places.

$(ifneq $(filter $(MESA_ANDROID_MAJOR_VERSION), 5 6 7 8),)
...

Not sure if I have the list of versions quite right there, but you get the idea.

Note, we still list version 4 in some spots, but I'm pretty sure it is
broken with mesa master. Probably about time for another pass of
dropping older versions.

Rob


> +LOCAL_CFLAGS += -DHAVE_TIMESPEC_GET
> +endif
> +
>  ifeq ($(strip $(MESA_ENABLE_ASM)),true)
>  ifeq ($(TARGET_ARCH),x86)
>  LOCAL_CFLAGS += \
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 107385] full Screen Corruption when a program is fullscreen

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107385

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #140844|text/x-log  |text/plain
  mime type||

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


[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized by POLARIS10 and KABINI

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107369

--- Comment #9 from infini...@pwned.gg ---
I guess a third possibility is that stack protectors are actually relevant for
GPUs but Clang/LLVM is not generating correct code for those in this case.

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


[Mesa-dev] [Bug 107369] "volatile" in OpenCL code not recognized by POLARIS10 and KABINI

2018-07-27 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107369

--- Comment #8 from infini...@pwned.gg ---
For background, this is the CFLAGS that Debian passes when compiling all C
programs. From the GCC man page:

-fstack-protector
   Emit extra code to check for buffer overflows, such as stack smashing
   attacks.  This is done by adding a guard variable to functions with
   vulnerable objects.  This includes functions that call "alloca", and
   functions with buffers larger than 8 bytes.  The guards are initialized when
   a function is entered and then checked when the function exits.  If a guard
   check fails, an error message is printed and the program exits.

-fstack-protector-strong
   Like -fstack-protector but includes additional functions to be protected ---
   those that have local array definitions, or have references to local frame
   addresses.

Of course GPUs are different so this may not be appropriate. I'm not familiar
with how OpenCLs work so please confirm what the most appropriate solution is
for Debian, either:

- append -fno-stack-protector to the Debian flags, if the other flags are
appropriate/relevant here

- omit all the flags completely and leave clang_bc_flags alone, if this is such
a special thing that Debian's system-policy CFLAGS should be completely ignored

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