Re: [Mesa-dev] [PATCH 06/11] nir: rework force_unroll_array_access()

2018-12-04 Thread Thomas Helland
Den tir. 20. nov. 2018 kl. 09:15 skrev Timothy Arceri :
>
> Here we rework force_unroll_array_access() so that we can reused
> the induction variable detection in a following patch.
> ---
>  src/compiler/nir/nir_loop_analyze.c | 49 -
>  1 file changed, 35 insertions(+), 14 deletions(-)
>
> diff --git a/src/compiler/nir/nir_loop_analyze.c 
> b/src/compiler/nir/nir_loop_analyze.c
> index 700d1fe552..a103a22afd 100644
> --- a/src/compiler/nir/nir_loop_analyze.c
> +++ b/src/compiler/nir/nir_loop_analyze.c
> @@ -350,6 +350,38 @@ find_loop_terminators(loop_info_state *state)
> return success;
>  }
>
> +/* This function looks for an array access within a loop that use an 
> induction
> + * variable for the array index. If found it returns the size of the array,
> + * otherwise 0 is returned.
> + */
> +static unsigned
> +find_array_access_via_induction(loop_info_state *state,
> +nir_deref_instr *deref,
> +nir_loop_variable **array_index_out)

Maybe make a small comment about the last parameter?
I guess it's quite obvious, but I'd rather have too much
handholding than too little =)

> +{
> +   for (nir_deref_instr *d = deref; d; d = nir_deref_instr_parent(d)) {
> +  if (d->deref_type != nir_deref_type_array)
> + continue;
> +
> +  assert(d->arr.index.is_ssa);
> +  nir_loop_variable *array_index = get_loop_var(d->arr.index.ssa, state);
> +
> +  if (array_index->type != basic_induction)
> + continue;
> +
> +  if (array_index_out)
> + *array_index_out = array_index;
> +
> +  nir_deref_instr *parent = nir_deref_instr_parent(d);
> +  assert(glsl_type_is_array(parent->type) ||
> + glsl_type_is_matrix(parent->type));

Maybe use glsl_type_is_array_or_matrix() ?
With (or without) that this patchs looks good and is:

Reviewed-by: Thomas Helland 

> +
> +  return glsl_get_length(parent->type);
> +   }
> +
> +   return 0;
> +}
> +
>  static int32_t
>  get_iteration(nir_op cond_op, nir_const_value *initial, nir_const_value 
> *step,
>nir_const_value *limit)
> @@ -626,20 +658,9 @@ find_trip_count(loop_info_state *state)
>  static bool
>  force_unroll_array_access(loop_info_state *state, nir_deref_instr *deref)
>  {
> -   for (nir_deref_instr *d = deref; d; d = nir_deref_instr_parent(d)) {
> -  if (d->deref_type != nir_deref_type_array)
> - continue;
> -
> -  assert(d->arr.index.is_ssa);
> -  nir_loop_variable *array_index = get_loop_var(d->arr.index.ssa, state);
> -
> -  if (array_index->type != basic_induction)
> - continue;
> -
> -  nir_deref_instr *parent = nir_deref_instr_parent(d);
> -  assert(glsl_type_is_array(parent->type) ||
> - glsl_type_is_matrix(parent->type));
> -  if (glsl_get_length(parent->type) == state->loop->info->max_trip_count)
> +   unsigned array_size = find_array_access_via_induction(state, deref, NULL);
> +   if (array_size) {
> +  if (array_size == state->loop->info->max_trip_count)
>   return true;
>
>if (deref->mode & state->indirect_mask)
> --
> 2.19.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 05/11] nir: factor out some of the complex loop unroll code to a helper

2018-12-04 Thread Thomas Helland
Den tir. 20. nov. 2018 kl. 09:15 skrev Timothy Arceri :
>
> ---
>  src/compiler/nir/nir_opt_loop_unroll.c | 116 ++---
>  1 file changed, 64 insertions(+), 52 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_loop_unroll.c 
> b/src/compiler/nir/nir_opt_loop_unroll.c
> index 935429add4..dc440e88b1 100644
> --- a/src/compiler/nir/nir_opt_loop_unroll.c
> +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> @@ -237,6 +237,65 @@ get_complex_unroll_insert_location(nir_cf_node *node, 
> bool continue_from_then)
> }
>  }
>
> +static nir_cf_node *
> +complex_unroll_loop_body(nir_loop *loop, nir_loop_terminator *unlimit_term,
> + nir_cf_list *lp_header, nir_cf_list *lp_body,
> + struct hash_table *remap_table,
> + unsigned num_times_to_clone)
> +{
> +   /* In the terminator that we have no trip count for move everything after
> +* the terminator into the continue from branch.
> +*/
> +   nir_cf_list loop_end;
> +   nir_cf_extract(_end, nir_after_cf_node(_term->nif->cf_node),
> +  nir_after_block(nir_loop_last_block(loop)));
> +   move_cf_list_into_loop_term(_end, unlimit_term);
> +
> +   /* Pluck out the loop body. */
> +   nir_cf_extract(lp_body, nir_before_block(nir_loop_first_block(loop)),
> +  nir_after_block(nir_loop_last_block(loop)));
> +
> +   /* Set unroll_loc to the loop as we will insert the unrolled loop before 
> it
> +*/
> +   nir_cf_node *unroll_loc = >cf_node;
> +
> +   /* Temp list to store the cloned loop as we unroll */
> +   nir_cf_list unrolled_lp_body;
> +
> +   for (unsigned i = 0; i < num_times_to_clone; i++) {
> +
> +  nir_cursor cursor =
> + get_complex_unroll_insert_location(unroll_loc,
> +
> unlimit_term->continue_from_then);
> +
> +  /* Clone loop header and insert in if branch */
> +  nir_cf_list_clone_and_reinsert(lp_header, loop->cf_node.parent,
> + cursor, remap_table);
> +
> +  cursor =
> + get_complex_unroll_insert_location(unroll_loc,
> +
> unlimit_term->continue_from_then);
> +
> +  /* Clone loop body */
> +  nir_cf_list_clone(_lp_body, lp_body, loop->cf_node.parent,
> +remap_table);
> +
> +  unroll_loc = exec_node_data(nir_cf_node,
> +  exec_list_get_tail(_lp_body.list),
> +  node);
> +  assert(unroll_loc->type == nir_cf_node_block &&
> + 
> exec_list_is_empty(_cf_node_as_block(unroll_loc)->instr_list));
> +
> +  /* Get the unrolled if node */
> +  unroll_loc = nir_cf_node_prev(unroll_loc);
> +
> +  /* Insert unrolled loop body */
> +  nir_cf_reinsert(_lp_body, cursor);
> +   }
> +
> +   return unroll_loc;
> +}
> +
>  /**
>   * Unroll a loop with two exists when the trip count of one of the exits is
>   * unknown.  If continue_from_then is true, the loop is repeated only when 
> the
> @@ -359,61 +418,14 @@ complex_unroll(nir_loop *loop, nir_loop_terminator 
> *unlimit_term,
>num_times_to_clone = loop->info->max_trip_count;
> }
>
> -   /* In the terminator that we have no trip count for move everything after
> -* the terminator into the continue from branch.
> -*/
> -   nir_cf_list loop_end;
> -   nir_cf_extract(_end, nir_after_cf_node(_term->nif->cf_node),
> -  nir_after_block(nir_loop_last_block(loop)));
> -   move_cf_list_into_loop_term(_end, unlimit_term);
> -
> -   /* Pluck out the loop body. */
> -   nir_cf_list loop_body;
> -   nir_cf_extract(_body, nir_before_block(nir_loop_first_block(loop)),
> -  nir_after_block(nir_loop_last_block(loop)));
> -
> struct hash_table *remap_table =
>_mesa_hash_table_create(NULL, _mesa_hash_pointer,
>_mesa_key_pointer_equal);
>
> -   /* Set unroll_loc to the loop as we will insert the unrolled loop before 
> it
> -*/
> -   nir_cf_node *unroll_loc = >cf_node;
> -
> -   /* Temp lists to store the cloned loop as we unroll */
> -   nir_cf_list unrolled_lp_body;
> -   nir_cf_list cloned_header;

^ This was actually unused as of the previous patch?
Might want to remove it there instead, but that's just
nitpicking. Either way this patch is:

Reviewed-by: Thomas Helland 

> -
> -   for (unsigned i = 0; i < num_times_to_clone; i++) {
> -
> -  nir_cursor cursor =
> - get_complex_unroll_insert_location(unroll_loc,
> -
> unlimit_term->continue_from_then);
> -
> -  /* Clone loop header and insert in if branch */
> -  nir_cf_list_clone_and_reinsert(_header, loop->cf_node.parent,
> - cursor, remap_table);
> -
> -  cursor =
> - get_complex_unroll_insert_location(unroll_loc,
> -
> 

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108946

Lee Donaghy  changed:

   What|Removed |Added

 CC||lee295...@gmail.com

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


[Mesa-dev] [PATCH 3/8] st/mesa: select ATOMFADD when source type is float

2018-12-04 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 2 ++
 src/mesa/state_tracker/st_glsl_to_tgsi_private.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 831ed3be0be..2102b7a57d5 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -781,6 +781,7 @@ glsl_to_tgsi_visitor::get_opcode(enum tgsi_opcode op,
   case7(ISHR,LAST, ISHR,USHR,LAST,I64SHR,  U64SHR);
   case7(ATOMIMAX,LAST, ATOMIMAX,ATOMUMAX,LAST,LAST,LAST);
   case7(ATOMIMIN,LAST, ATOMIMIN,ATOMUMIN,LAST,LAST,LAST);
+  case7(ATOMUADD,ATOMFADD,ATOMUADD,ATOMUADD,LAST, LAST,LAST);
 
   casecomp(SEQ, FSEQ, USEQ, USEQ, DSEQ, U64SEQ, U64SEQ);
   casecomp(SNE, FSNE, USNE, USNE, DSNE, U64SNE, U64SNE);
@@ -6204,6 +6205,7 @@ compile_tgsi_instruction(struct st_translate *t,
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
case TGSI_OPCODE_IMG2HND:
   for (i = num_src - 1; i >= 0; i--)
  src[i + 1] = src[i];
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_private.h 
b/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
index c82de951427..6b5d8278027 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_private.h
@@ -181,6 +181,7 @@ is_resource_instruction(unsigned opcode)
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
case TGSI_OPCODE_IMG2HND:
   return true;
default:
-- 
2.18.1

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


[Mesa-dev] [PATCH 8/8] nvc0: expose ATOMFADD on all generations

2018-12-04 Thread Ilia Mirkin
This is supported on all generations for regular memory. For shared
memory, all operations are entirely emulated on Fermi/Kepler anyways,
for Maxwell, we add a special path to emulate just this operation (using
ATOMS.CAS to implement a loop), since there is no ATOMS.ADD.F32 variant.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
index bd48f15063a..729b7640186 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
@@ -266,6 +266,7 @@ nvc0_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
case PIPE_CAP_QUERY_SO_OVERFLOW:
+   case PIPE_CAP_TGSI_ATOMFADD:
   return 1;
case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
   return nouveau_screen(pscreen)->vram_domain & NOUVEAU_BO_VRAM ? 1 : 0;
-- 
2.18.1

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


[Mesa-dev] [PATCH 2/8] gallium: add PIPE_CAP_TGSI_ATOMFADD to indicate support

2018-12-04 Thread Ilia Mirkin
ATOMFADD is a little special -- make drivers have to specify it
explicitly.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/auxiliary/util/u_screen.c | 1 +
 src/gallium/docs/source/screen.rst| 2 ++
 src/gallium/include/pipe/p_defines.h  | 1 +
 3 files changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_screen.c 
b/src/gallium/auxiliary/util/u_screen.c
index 73dbbee94a9..a9ce3c2d871 100644
--- a/src/gallium/auxiliary/util/u_screen.c
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -311,6 +311,7 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
*pscreen,
case PIPE_CAP_MAX_COMBINED_SHADER_BUFFERS:
case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTERS:
case PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS:
+   case PIPE_CAP_TGSI_ATOMFADD:
   return 0;
 
case PIPE_CAP_MAX_GS_INVOCATIONS:
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 0abd164494c..657b04c7a5c 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -477,6 +477,8 @@ subpixel precision bias in bits during conservative 
rasterization.
   0 means no limit.
 * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value for
   of pipe_vertex_element::src_offset.
+* ``PIPE_CAP_TGSI_ATOMFADD``: Atomic floating point adds are supported on
+  images, buffers, and shared memory.
 
 .. _pipe_capf:
 
diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index e99895d30d8..0660e641b06 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -832,6 +832,7 @@ enum pipe_cap
PIPE_CAP_MAX_COMBINED_HW_ATOMIC_COUNTER_BUFFERS,
PIPE_CAP_MAX_TEXTURE_UPLOAD_MEMORY_BUDGET,
PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET,
+   PIPE_CAP_TGSI_ATOMFADD,
 };
 
 /**
-- 
2.18.1

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


[Mesa-dev] [PATCH 1/8] tgsi: add ATOMFADD operation

2018-12-04 Thread Ilia Mirkin
This is supported by at least NVIDIA hardware, and exposeable via GL
extensions.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c |  4 
 src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h |  2 +-
 src/gallium/auxiliary/tgsi/tgsi_scan.c |  1 +
 src/gallium/auxiliary/tgsi/tgsi_util.c |  1 +
 src/gallium/docs/source/tgsi.rst   | 15 +++
 src/gallium/include/pipe/p_shader_tokens.h |  2 +-
 6 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 5db515a0753..99edf33c22e 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -4253,6 +4253,9 @@ exec_atomop_mem(struct tgsi_exec_machine *mach,
   if (val == value[0].u[0])
  val = value2[0].u[0];
   break;
+   case TGSI_OPCODE_ATOMFADD:
+  val = fui(r[0].f[0] + value[0].f[0]);
+  break;
default:
   break;
}
@@ -5933,6 +5936,7 @@ exec_instruction(
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
   exec_atomop(mach, inst);
   break;
 
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h 
b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
index c3787c2fbb2..f391b0cea6b 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h
@@ -101,7 +101,7 @@ OPCODE(0, 0, NONE, BGNLOOP, .is_branch = 1, .post_indent = 
1)
 OPCODE(0, 0, NONE, BGNSUB, .post_indent = 1)
 OPCODE(0, 0, NONE, ENDLOOP, .is_branch = 1, .pre_dedent = 1)
 OPCODE(0, 0, NONE, ENDSUB, .pre_dedent = 1)
-OPCODE_GAP(103) /* removed */
+OPCODE(1, 3, OTHR, ATOMFADD, .is_store = 1)
 OPCODE(1, 1, OTHR, TXQS, .is_tex = 1)
 OPCODE(1, 1, OTHR, RESQ)
 OPCODE(1, 1, COMP, READ_FIRST)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c 
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 4ca84902dd4..d776fc7bef1 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_scan.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_scan.c
@@ -391,6 +391,7 @@ scan_instruction(struct tgsi_shader_info *info,
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
   if (tgsi_is_bindless_image_file(fullinst->Src[0].Register.File)) {
  info->uses_bindless_images = true;
 
diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.c 
b/src/gallium/auxiliary/tgsi/tgsi_util.c
index ebbd561f7d0..1e5582ba273 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.c
@@ -385,6 +385,7 @@ tgsi_util_get_inst_usage_mask(const struct 
tgsi_full_instruction *inst,
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
   if (src_idx == 0) {
  read_mask = TGSI_WRITEMASK_XY; /* bindless handle possible */
   } else if (src_idx == 1) {
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 7d4ebb62674..277f25ca41b 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2684,6 +2684,21 @@ These atomic operations may only be used with 32-bit 
integer image formats.
   resource[offset] = dst_x + src_x
 
 
+.. opcode:: ATOMFADD - Atomic floating point addition
+
+  Syntax: ``ATOMFADD dst, resource, offset, src``
+
+  Example: ``ATOMFADD TEMP[0], BUFFER[0], TEMP[1], TEMP[2]``
+
+  The following operation is performed atomically:
+
+.. math::
+
+  dst_x = resource[offset]
+
+  resource[offset] = dst_x + src_x
+
+
 .. opcode:: ATOMXCHG - Atomic exchange
 
   Syntax: ``ATOMXCHG dst, resource, offset, src``
diff --git a/src/gallium/include/pipe/p_shader_tokens.h 
b/src/gallium/include/pipe/p_shader_tokens.h
index bef826f23b5..8f290615c3f 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -442,7 +442,7 @@ enum tgsi_opcode {
TGSI_OPCODE_BGNSUB = 100,
TGSI_OPCODE_ENDLOOP= 101,
TGSI_OPCODE_ENDSUB = 102,
-   /* gap */
+   TGSI_OPCODE_ATOMFADD   = 103,
TGSI_OPCODE_TXQS   = 104,
TGSI_OPCODE_RESQ   = 105,
TGSI_OPCODE_READ_FIRST = 106,
-- 
2.18.1

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


[Mesa-dev] [PATCH 6/8] nv50/ir: ensure that the constraint mov is placed above flow control

2018-12-04 Thread Ilia Mirkin
This is tickled by the Maxwell lowering logic for shared floating point
add, but it could potentially come up in other ways too.

Signed-off-by: Ilia Mirkin 
---

Note that this may depend slightly on a local patch. However the overall
idea remains entirely the same.

 src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
index 8d0d66cd212..9b7f46e1e86 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp
@@ -442,7 +442,15 @@ RegAlloc::PhiMovesPass::visit(BasicBlock *bb)
  Instruction *mov = new_Instruction(func, OP_MOV, 
typeOfSize(tmp->reg.size));
  mov->setSrc(0, phi->getSrc(i));
  mov->setDef(0, tmp);
- pb->insertBefore(pb->getExit(), mov);
+
+ // A BB may have multiple flow instructions at the end. We have to
+ // make sure that the mov goes in before the relevant jump.
+ Instruction *jump = pb->getExit();
+ while (jump->asFlow()->target.bb != bb) {
+assert(jump->prev->asFlow());
+jump = jump->prev;
+ }
+ pb->insertBefore(jump, mov);
 
  phi->setSrc(i, tmp);
   }
-- 
2.18.1

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


[Mesa-dev] [PATCH 5/8] nv50/ir: add support for converting ATOMFADD to proper ir

2018-12-04 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
index c6e69ff1230..afd7916a321 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
@@ -968,6 +968,7 @@ static nv50_ir::operation translateOpcode(uint opcode)
NV50_IR_OPCODE_CASE(ATOMUMAX, ATOM);
NV50_IR_OPCODE_CASE(ATOMIMIN, ATOM);
NV50_IR_OPCODE_CASE(ATOMIMAX, ATOM);
+   NV50_IR_OPCODE_CASE(ATOMFADD, ATOM);
 
NV50_IR_OPCODE_CASE(TEX2, TEX);
NV50_IR_OPCODE_CASE(TXB2, TXB);
@@ -1010,6 +1011,7 @@ static uint16_t opcodeToSubOp(uint opcode)
case TGSI_OPCODE_ATOMIMIN: return NV50_IR_SUBOP_ATOM_MIN;
case TGSI_OPCODE_ATOMUMAX: return NV50_IR_SUBOP_ATOM_MAX;
case TGSI_OPCODE_ATOMIMAX: return NV50_IR_SUBOP_ATOM_MAX;
+   case TGSI_OPCODE_ATOMFADD: return NV50_IR_SUBOP_ATOM_ADD;
case TGSI_OPCODE_IMUL_HI:
case TGSI_OPCODE_UMUL_HI:
   return NV50_IR_SUBOP_MUL_HIGH;
@@ -1619,6 +1621,7 @@ bool Source::scanInstruction(const struct 
tgsi_full_instruction *inst)
   case TGSI_OPCODE_ATOMIMIN:
   case TGSI_OPCODE_ATOMUMAX:
   case TGSI_OPCODE_ATOMIMAX:
+  case TGSI_OPCODE_ATOMFADD:
   case TGSI_OPCODE_LOAD:
  info->io.globalAccess |= (insn.getOpcode() == TGSI_OPCODE_LOAD) ?
 0x1 : 0x2;
@@ -3834,6 +3837,7 @@ Converter::handleInstruction(const struct 
tgsi_full_instruction *insn)
case TGSI_OPCODE_ATOMIMIN:
case TGSI_OPCODE_ATOMUMAX:
case TGSI_OPCODE_ATOMIMAX:
+   case TGSI_OPCODE_ATOMFADD:
   handleATOM(dst0, dstTy, tgsi::opcodeToSubOp(tgsi.getOpcode()));
   break;
case TGSI_OPCODE_RESQ:
-- 
2.18.1

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


[Mesa-dev] [PATCH 7/8] gm107/ir: add lowering of atomic f32 add on shared memory

2018-12-04 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 49 +++
 .../nouveau/codegen/nv50_ir_lowering_nvc0.h   |  1 +
 2 files changed, 50 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
index 295497be2f9..44c62820342 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
@@ -1347,6 +1347,53 @@ NVC0LoweringPass::handleBUFQ(Instruction *bufq)
return true;
 }
 
+void
+NVC0LoweringPass::handleSharedATOMGM107(Instruction *atom)
+{
+   if (atom->dType != TYPE_F32)
+  return;
+
+   assert(atom->subOp == NV50_IR_SUBOP_ATOM_ADD);
+   assert(atom->src(0).getFile() == FILE_MEMORY_SHARED);
+
+   BasicBlock *currBB = atom->bb;
+   BasicBlock *addAndCasBB = atom->bb->splitBefore(atom, false);
+   BasicBlock *joinBB = atom->bb->splitAfter(atom);
+
+   bld.setPosition(currBB, true);
+
+   Value *load = atom->getDef(0), *newval = bld.getSSA();
+   // TODO: Use "U" subop?
+   bld.mkLoad(TYPE_U32, load, atom->getSrc(0)->asSym(), atom->getIndirect(0, 
0));
+   assert(!currBB->joinAt);
+   currBB->joinAt = bld.mkFlow(OP_JOINAT, joinBB, CC_ALWAYS, NULL);
+
+   bld.mkFlow(OP_BRA, addAndCasBB, CC_ALWAYS, NULL);
+   currBB->cfg.attach(>cfg, Graph::Edge::TREE);
+
+   bld.setPosition(addAndCasBB, true);
+   bld.remove(atom);
+
+   bld.mkOp2(OP_ADD, TYPE_F32, newval, load, atom->getSrc(1));
+
+   // Try to do a compare-and-swap. If the old value doesn't match the loaded
+   // value, repeat.
+   Value *old = bld.getSSA();
+   Instruction *cas =
+  bld.mkOp3(OP_ATOM, TYPE_U32, old, atom->getSrc(0), load, newval);
+   cas->setIndirect(0, 0, atom->getIndirect(0, 0));
+   cas->subOp = NV50_IR_SUBOP_ATOM_CAS;
+   Value *pred = bld.getSSA(1, FILE_PREDICATE);
+   bld.mkCmp(OP_SET, CC_EQ, TYPE_U32, pred, TYPE_U32, old, load);
+   bld.mkMov(load, old);
+   bld.mkFlow(OP_BRA, addAndCasBB, CC_NOT_P, pred);
+   bld.mkFlow(OP_BRA, joinBB, CC_ALWAYS, NULL);
+   addAndCasBB->cfg.attach(>cfg, Graph::Edge::BACK);
+
+   bld.setPosition(joinBB, false);
+   bld.mkFlow(OP_JOIN, NULL, CC_ALWAYS, NULL)->fixed = 1;
+}
+
 void
 NVC0LoweringPass::handleSharedATOMNVE4(Instruction *atom)
 {
@@ -1559,6 +1606,8 @@ NVC0LoweringPass::handleATOM(Instruction *atom)
  handleSharedATOM(atom);
   else if (targ->getChipset() < NVISA_GM107_CHIPSET)
  handleSharedATOMNVE4(atom);
+  else
+ handleSharedATOMGM107(atom);
   return true;
default:
   assert(atom->src(0).getFile() == FILE_MEMORY_BUFFER);
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
index e0f50ab0904..2d77e918358 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.h
@@ -143,6 +143,7 @@ protected:
void handleSurfaceOpNVC0(TexInstruction *);
void handleSharedATOM(Instruction *);
void handleSharedATOMNVE4(Instruction *);
+   void handleSharedATOMGM107(Instruction *);
void handleLDST(Instruction *);
bool handleBUFQ(Instruction *);
void handlePIXLD(Instruction *);
-- 
2.18.1

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


[Mesa-dev] [PATCH 4/8] st/mesa: expose GL_NV_shader_atomic_float when ATOMFADD is supported

2018-12-04 Thread Ilia Mirkin
Signed-off-by: Ilia Mirkin 
---
 src/mesa/state_tracker/st_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 002866d4cdb..8d0e8e0292f 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -759,6 +759,7 @@ void st_init_extensions(struct pipe_screen *screen,
   { o(NV_conditional_render),PIPE_CAP_CONDITIONAL_RENDER   
},
   { o(NV_fill_rectangle),
PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE  },
   { o(NV_primitive_restart), PIPE_CAP_PRIMITIVE_RESTART
},
+  { o(NV_shader_atomic_float),   PIPE_CAP_TGSI_ATOMFADD
},
   { o(NV_texture_barrier),   PIPE_CAP_TEXTURE_BARRIER  
},
   { o(NVX_gpu_memory_info),  PIPE_CAP_QUERY_MEMORY_INFO
},
   /* GL_NV_point_sprite is not supported by gallium because we don't
-- 
2.18.1

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


[Mesa-dev] [Bug 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107991

John  changed:

   What|Removed |Added

 CC||john.etted...@gmail.com

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


[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108946

--- Comment #1 from MGG  ---
Created attachment 142729
  --> https://bugs.freedesktop.org/attachment.cgi?id=142729=edit
game apitrace

-- 
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 108946] High memory usage in Black Mesa

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108946

Bug ID: 108946
   Summary: High memory usage in Black Mesa
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: marco.ge...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142728
  --> https://bugs.freedesktop.org/attachment.cgi?id=142728=edit
glxinfo

Hello,

Since some time this game keeps getting an out of memory error that makes it
crash (it's a 32bit binary). While reporting the issues to the game devs this
is the reason they gave to the users
(https://steamcommunity.com/app/362890/discussions/1/3307213006836757658/?ctp=7):

"... From what I noticed, more shaders game had - faster out of memory
occurred. Black Mesa has full (or almost full) support of SM 3.0 on Linux which
allowed us to use same shaders with same code on both platfroms, while opening
new horizons for our new dynamic lighting implementation. After first discovery
of issues with Mesa driver, to avoid out of memory I had to cut some of shader
combinations completely specifically for OpenGL version by introducing shader
platform flags that decide if particular part with some visual feature the of
shader will be compiled. That helped quite a lot, we were able to run Black
Mesa for a while on AMD with lowest settings and CSM being turned off. But
while Mesa is sharing same memory location in application's address space, it's
pretty hard to go further being 32 bit."

Also, they mention that with Nvidia propietary driver the game with full
setting doesn't go over 1.2 GB of ram (on my system, I detect a first peak of
almost 3Gb of ram usage before crashing). So, there is some way that Mesa
drivers could be leaking about 2Gb of ram? I understand that the memory usage
between propietary drivers a Mesa are quite different, but I feel that it's
quite suspicious that there is such a big ram usage for what seems to be
shaders compile output.

Finally, while running an apitrace I detected a lot this errors: "major shader
compiler issue 21156: 0:4(12): warning: extension `GL_EXT_gpu_shader4'
unsupported in vertex shader". Not sure if it could be related with any leak
though.

I'm attaching to the ticket my system information plus and the apitrace I got
until the crash. Let me know if there's any other information you need or if
it's necessary that I test this game with newer version of Mesa.

-- 
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 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107991

--- Comment #17 from John  ---
My apologies for the delay, I had not seen your question before.

Your trace replays fine here, but truthfully I did not try it before so I don't
know if anything changed on my end.

My dolphin save still crashes the system, and I'm guessing it's related to your
issue somehow, but I can continue that on the bug I created. Either way is fine
with me.

Thank you for waiting!

(In case you're curious, here's my trace:
https://mega.nz/#!plBngY4B!zQ8P24a84PsHWym-5hAGUMjiMKv1CKQB7EFnlPorrx4 I used
the command you provided here but it ended up all black, it still freezes the
system though)

-- 
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] Make Jordan an Owner of the mesa project?

2018-12-04 Thread Jason Ekstrand
It's been 24 hours and the only owner who hasn't replied yet is Matt.
Given that everyone else has firmly ACKed, I'm going to click the button.
Congratulations, Jordan, you're now a mesa Owner!

--Jason

On Tue, Dec 4, 2018 at 1:41 PM Rob Clark  wrote:

> On Mon, Dec 3, 2018 at 7:49 PM Jason Ekstrand 
> wrote:
> >
> > Jordan has requested to be made an Owner of the mesa project.  As much
> as I may be the guy who pushed to get everything set up, I don't want to do
> this sort of thing on my own.  As such, I'm asking for some ACKs.  If I can
> get 5 ACKs (at least 2 non-intel) from other Owners and no NAKs, I'll click
> the button.
> >
> > Personally, I think the answer here is absurdly obvious.  Jordan is one
> of the most involved people in the community. :-D
> >
> > As a side-note, does this seem like a reasonable process for adding
> people as Owners?
> >
>
> Ack
>
> BR,
> -R
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] build: remove autotools

2018-12-04 Thread Marek Olšák
On Tue, Dec 4, 2018 at 7:18 PM Dylan Baker  wrote:

> Quoting Marek Olšák (2018-12-04 16:04:11)
> > On Tue, Dec 4, 2018 at 7:01 PM Dylan Baker  wrote:
> >
> > Quoting Marek Olšák (2018-12-04 14:52:19)
> > > CFLAGS="-fno-omit-frame-pointer" \
> > > CXXFLAGS="-fno-omit-frame-pointer" \
> > > LDFLAGS="-fuse-ld=gold" \
> > > meson $reconfigure build \
> > > --prefix /usr --libdir /usr/lib/$archdir --buildtype
> debugoptimized
> > > --native-file $llvm_config \
> > > -Dgallium-va=false -Dgallium-xvmc=false -Dgallium-omx=disabled
> > -Dgallium-xa
> > > =false \
> > > -Dplatforms=x11,drm,surfaceless
> -Dgallium-drivers=radeonsi,r300,r600
> > \
> > > -Ddri-drivers= -Dvulkan-drivers=amd \
> > > -Dlibunwind=true
> > >
> > > Marek
> >
> > If you want the -DDEBUG added automatically you need a
> --buildtype=debug,
> > --buildtype=debugoptimized doesn't get -DDEBUG.
> >
> >
> > That's a change in behavior compared to autotools, which was always
> > debugoptimized.
> >
> > Marek
>
> That was changed after the initial meson merge, here's the thread
> discussing
> that:
> https://lists.freedesktop.org/archives/mesa-dev/2017-November/175104.html


It doesn't discuss it.

Autotools doesn't have buildtype=debug (-O0). --enable-debug is
debugoptimized (-g -O2 -DDEBUG).

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


Re: [Mesa-dev] [PATCH mesa] drop autotools

2018-12-04 Thread Matt Turner
On Tue, Dec 4, 2018 at 3:43 PM Gert Wollny  wrote:
>
> Am Dienstag, den 04.12.2018, 14:01 -0800 schrieb Matt Turner:
> > On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny 
> > wrote:
> > > FWIW, I also don't understand the urge to remove the automake build
> > > system files, they account for less then 1% of line count in the
> > > source
> > > tree, Emil offered to maintain the build system in a way that
> > > nobody
> > > who doesn't want to deal with has to touch it
> >
> > Do you see any value in removing the autotools build system at all?
>
> If there was nobody willing to maintain it and nobody who wants to use
> it then I would say it makes sense to remove it, because it doesn't
> make sense to keep something that is unused and will bitrot, but right
> now this is not the case. In light of what Emil wrote I could also ask:
> what's the harm in keeping it?

Noted, but I think your opinion is out of step even with those others
asking to keep autotools around a while longer.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] build: remove autotools

2018-12-04 Thread Dylan Baker
Quoting Marek Olšák (2018-12-04 16:04:11)
> On Tue, Dec 4, 2018 at 7:01 PM Dylan Baker  wrote:
> 
> Quoting Marek Olšák (2018-12-04 14:52:19)
> > CFLAGS="-fno-omit-frame-pointer" \
> > CXXFLAGS="-fno-omit-frame-pointer" \
> > LDFLAGS="-fuse-ld=gold" \
> >     meson $reconfigure build \
> >     --prefix /usr --libdir /usr/lib/$archdir --buildtype debugoptimized
> > --native-file $llvm_config \
> >     -Dgallium-va=false -Dgallium-xvmc=false -Dgallium-omx=disabled
> -Dgallium-xa
> > =false \
> >     -Dplatforms=x11,drm,surfaceless -Dgallium-drivers=radeonsi,r300,r600
> \
> >     -Ddri-drivers= -Dvulkan-drivers=amd \
> >     -Dlibunwind=true
> >
> > Marek
> 
> If you want the -DDEBUG added automatically you need a --buildtype=debug,
> --buildtype=debugoptimized doesn't get -DDEBUG.
> 
> 
> That's a change in behavior compared to autotools, which was always
> debugoptimized.
> 
> Marek

That was changed after the initial meson merge, here's the thread discussing
that: https://lists.freedesktop.org/archives/mesa-dev/2017-November/175104.html

Dylan


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] build: remove autotools

2018-12-04 Thread Marek Olšák
On Tue, Dec 4, 2018 at 7:01 PM Dylan Baker  wrote:

> Quoting Marek Olšák (2018-12-04 14:52:19)
> > CFLAGS="-fno-omit-frame-pointer" \
> > CXXFLAGS="-fno-omit-frame-pointer" \
> > LDFLAGS="-fuse-ld=gold" \
> > meson $reconfigure build \
> > --prefix /usr --libdir /usr/lib/$archdir --buildtype debugoptimized
> > --native-file $llvm_config \
> > -Dgallium-va=false -Dgallium-xvmc=false -Dgallium-omx=disabled
> -Dgallium-xa
> > =false \
> > -Dplatforms=x11,drm,surfaceless -Dgallium-drivers=radeonsi,r300,r600
> \
> > -Ddri-drivers= -Dvulkan-drivers=amd \
> > -Dlibunwind=true
> >
> > Marek
>
> If you want the -DDEBUG added automatically you need a --buildtype=debug,
> --buildtype=debugoptimized doesn't get -DDEBUG.
>

That's a change in behavior compared to autotools, which was always
debugoptimized.

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


Re: [Mesa-dev] [PATCH mesa] drop autotools

2018-12-04 Thread Dylan Baker
Quoting Gert Wollny (2018-12-04 15:42:58)
> Am Dienstag, den 04.12.2018, 14:01 -0800 schrieb Matt Turner:
> > On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny 
> > wrote:
> > > FWIW, I also don't understand the urge to remove the automake build
> > > system files, they account for less then 1% of line count in the
> > > source
> > > tree, Emil offered to maintain the build system in a way that
> > > nobody
> > > who doesn't want to deal with has to touch it
> > 
> > Do you see any value in removing the autotools build system at all?
> 
> If there was nobody willing to maintain it and nobody who wants to use
> it then I would say it makes sense to remove it, because it doesn't
> make sense to keep something that is unused and will bitrot, but right
> now this is not the case. In light of what Emil wrote I could also ask:
> what's the harm in keeping it?
> 
> Personally, I use both, meson/ninja is great when you want to build 
> the whole project, but being able to go to a subdirectory and just run
> "make something" there has its virtues too.
> 
> Best, 
> Gert
> 

Is that really any different than doing a `ninja -C builddir/
src/mesa/libmesa_gallium.a` (or whatever target you want)? Especially since you
can tab complete ninja targets.

Dylan


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] build: remove autotools

2018-12-04 Thread Dylan Baker
Quoting Marek Olšák (2018-12-04 14:52:19)
> CFLAGS="-fno-omit-frame-pointer" \
> CXXFLAGS="-fno-omit-frame-pointer" \
> LDFLAGS="-fuse-ld=gold" \
>     meson $reconfigure build \
>     --prefix /usr --libdir /usr/lib/$archdir --buildtype debugoptimized
> --native-file $llvm_config \
>     -Dgallium-va=false -Dgallium-xvmc=false -Dgallium-omx=disabled 
> -Dgallium-xa
> =false \
>     -Dplatforms=x11,drm,surfaceless -Dgallium-drivers=radeonsi,r300,r600 \
>     -Ddri-drivers= -Dvulkan-drivers=amd \
>     -Dlibunwind=true
> 
> Marek

If you want the -DDEBUG added automatically you need a --buildtype=debug,
--buildtype=debugoptimized doesn't get -DDEBUG.

Dylan


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 mesa] drop autotools

2018-12-04 Thread Gert Wollny
Am Dienstag, den 04.12.2018, 14:01 -0800 schrieb Matt Turner:
> On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny 
> wrote:
> > FWIW, I also don't understand the urge to remove the automake build
> > system files, they account for less then 1% of line count in the
> > source
> > tree, Emil offered to maintain the build system in a way that
> > nobody
> > who doesn't want to deal with has to touch it
> 
> Do you see any value in removing the autotools build system at all?

If there was nobody willing to maintain it and nobody who wants to use
it then I would say it makes sense to remove it, because it doesn't
make sense to keep something that is unused and will bitrot, but right
now this is not the case. In light of what Emil wrote I could also ask:
what's the harm in keeping it?

Personally, I use both, meson/ninja is great when you want to build 
the whole project, but being able to go to a subdirectory and just run
"make something" there has its virtues too.

Best, 
Gert

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


Re: [Mesa-dev] [PATCH v2] build: remove autotools

2018-12-04 Thread Marek Olšák
CFLAGS="-fno-omit-frame-pointer" \
CXXFLAGS="-fno-omit-frame-pointer" \
LDFLAGS="-fuse-ld=gold" \
meson $reconfigure build \
--prefix /usr --libdir /usr/lib/$archdir --buildtype debugoptimized
--native-file $llvm_config \
-Dgallium-va=false -Dgallium-xvmc=false -Dgallium-omx=disabled
-Dgallium-xa=false \
-Dplatforms=x11,drm,surfaceless -Dgallium-drivers=radeonsi,r300,r600 \
-Ddri-drivers= -Dvulkan-drivers=amd \
-Dlibunwind=true

Marek


On Tue, Dec 4, 2018 at 5:32 PM Dylan Baker  wrote:

> Quoting Eric Engestrom (2018-12-04 09:36:53)
> > On Tuesday, 2018-12-04 09:16:18 -0800, Dylan Baker wrote:
> > > There are now no known distributions using autotools, meson has all of
> > > the features that autotools does. We don't need two build systems to do
> > > exactly the same thing, meson is faster, easier to maintain, and used
> by
> > > more devs than autotools. Let's reduce the ongoing burden of
> maintaining
> > > autotools.
> > >
> > > This removes the following:
> > >  - configure.ac
> > >  - autogen.sh
> > >  - Makefile.*.am
> > >  - Makefile.am
> > >  - Makefile.sources (which are used only by autotools)
> > >  - travis jobs for autotools
> > >  - docs for autotools
> > >  - .gitignore
> > >
> > > v2: - remove stray no-op change in .travis.yml
> > > ---
> > [snip]
> > > diff --git a/.travis.yml b/.travis.yml
> > > index 6b50d49e143..66be44ffc21 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -74,240 +74,13 @@ matrix:
> > >  - python3.5
> > >  - python3-pip
> > >  - env:
> > > -- LABEL="make loaders/classic DRI"
> > > -- BUILD=make
> > > -- MAKEFLAGS="-j4"
> > > -- MAKE_CHECK_COMMAND="make check"
> > > -- DRI_LOADERS="--enable-glx --enable-gbm --enable-egl
> --with-platforms=x11,drm,surfaceless,wayland --enable-osmesa"
> > > -- DRI_DRIVERS="i915,i965,radeon,r200,swrast,nouveau"
> > > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa
> --disable-nine --disable-xvmc --disable-vdpau --disable-va
> --disable-omx-bellagio --disable-gallium-osmesa"
> > > -- GALLIUM_DRIVERS=""
> > > -- VULKAN_DRIVERS=""
> > > -- LIBUNWIND_FLAGS="--disable-libunwind"
> > > -  addons:
> > > -apt:
> > > -  packages:
> > > -- xz-utils
> > > -- x11proto-xf86vidmode-dev
> > > -- libexpat1-dev
> > > -- libx11-xcb-dev
> > > -- libxdamage-dev
> > > -- libxfixes-dev
> > > -- python3-pip
> > > -- env:
> > > -# NOTE: Building SWR is 2x (yes two) times slower than all
> the other
> > > -# gallium drivers combined.
> > > -# Start this early so that it doesn't hunder the run time.
> > > -- LABEL="make Gallium Drivers SWR"
> > > -- BUILD=make
> > > -- MAKEFLAGS="-j4"
> > > -- MAKE_CHECK_COMMAND="true"
> > > -- LLVM_VERSION=6.0
> > > -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > > -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> > > -- DRI_DRIVERS=""
> > > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa
> --disable-nine --disable-xvmc --disable-vdpau --disable-va
> --disable-omx-bellagio --disable-gallium-osmesa"
> > > -- GALLIUM_DRIVERS="swr"
> > > -- VULKAN_DRIVERS=""
> > > -- LIBUNWIND_FLAGS="--enable-libunwind"
> > > -  addons:
> > > -apt:
> > > -  sources:
> > > -- llvm-toolchain-trusty-6.0
> > > -# llvm-6 requires libstdc++4.9 which is not in main repo
> > > -- ubuntu-toolchain-r-test
> > > -  packages:
> > > -# From sources above
> > > -- llvm-6.0-dev
> > > -# Common
> > > -- xz-utils
> > > -- libexpat1-dev
> > > -- libx11-xcb-dev
> > > -- libelf-dev
> > > -- libunwind8-dev
> > > -- python3-pip
> > > -- env:
> > > -- LABEL="make Gallium Drivers RadeonSI"
> > > -- BUILD=make
> > > -- MAKEFLAGS="-j4"
> > > -- MAKE_CHECK_COMMAND="true"
> > > -- LLVM_VERSION=6.0
> > > -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > > -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> > > -- DRI_DRIVERS=""
> > > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa
> --disable-nine --disable-xvmc --disable-vdpau --disable-va
> --disable-omx-bellagio --disable-gallium-osmesa"
> > > -- GALLIUM_DRIVERS="radeonsi"
> > > -- VULKAN_DRIVERS=""
> > > -- LIBUNWIND_FLAGS="--enable-libunwind"
> > > -  addons:
> > > -apt:
> > > -  sources:
> > > -- llvm-toolchain-trusty-6.0
> > > -# llvm-6 requires libstdc++4.9 which is not in main repo
> > > -- ubuntu-toolchain-r-test
> > > -  packages:
> > > -# From sources above

Re: [Mesa-dev] [PATCH v2 1/5] mesa: Add core support for EXT_multisampled_render_to_texture2

2018-12-04 Thread Marek Olšák
On Thu, Nov 29, 2018 at 7:50 PM Kristian Høgsberg 
wrote:

> On Tue, Nov 6, 2018 at 3:03 PM Ilia Mirkin  wrote:
> >
> > On Tue, Nov 6, 2018 at 5:18 PM Kristian H. Kristensen
> >  wrote:
> > >
> > > This also turns on EXT_multisampled_render_to_texture which is a
> > > subset of EXT_multisampled_render_to_texture2, allowing only
> > > COLOR_ATTACHMENT0.
> >
> > You also enable the texture2 variant as well, no?
>
> Yes, I'll update the subject.
>
> >
> > >
> > > Signed-off-by: Kristian H. Kristensen 
> > > ---
> > >  .../EXT_multisampled_render_to_texture.xml| 34 ++
> > >  src/mapi/glapi/gen/Makefile.am|  1 +
> > >  src/mapi/glapi/gen/gl_API.xml |  2 +
> > >  src/mapi/glapi/gen/meson.build|  1 +
> > >  src/mesa/drivers/common/meta.c|  2 +-
> > >  src/mesa/main/extensions_table.h  |  2 +
> > >  src/mesa/main/fbobject.c  | 45 +--
> > >  src/mesa/main/fbobject.h  |  8 +++-
> > >  src/mesa/main/mtypes.h|  2 +
> > >  9 files changed, 81 insertions(+), 16 deletions(-)
> > >  create mode 100644
> src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > >
> > > diff --git a/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > > new file mode 100644
> > > index 000..cf44e6976f0
> > > --- /dev/null
> > > +++ b/src/mapi/glapi/gen/EXT_multisampled_render_to_texture.xml
> > > @@ -0,0 +1,34 @@
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +  value="0x8CAB"/>
> > > +  value="0x8D56"/>
> > > + value="0x8D57"/>
> > > + value="0x8D6C"/>
> >
> > I don't see any logic to enable retrieving these (*_SAMPLES_EXT), so I
> > think this implementation is slightly incomplete.
>
> Will add.
>
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > +
> > > diff --git a/src/mapi/glapi/gen/Makefile.am
> b/src/mapi/glapi/gen/Makefile.am
> > > index 6e0ee1e1687..40538b0ff2e 100644
> > > --- a/src/mapi/glapi/gen/Makefile.am
> > > +++ b/src/mapi/glapi/gen/Makefile.am
> > > @@ -200,6 +200,7 @@ API_XML = \
> > > EXT_external_objects_fd.xml \
> > > EXT_framebuffer_object.xml \
> > > EXT_gpu_shader4.xml \
> > > +   EXT_multisampled_render_to_texture.xml \
> > > EXT_packed_depth_stencil.xml \
> > > EXT_provoking_vertex.xml \
> > > EXT_separate_shader_objects.xml \
> > > diff --git a/src/mapi/glapi/gen/gl_API.xml
> b/src/mapi/glapi/gen/gl_API.xml
> > > index aae9a5835db..ee4d13f1f06 100644
> > > --- a/src/mapi/glapi/gen/gl_API.xml
> > > +++ b/src/mapi/glapi/gen/gl_API.xml
> > > @@ -8166,6 +8166,8 @@
> > >
> > >  http://www.w3.org/2001/XInclude"/>
> > >
> > > +http://www.w3.org/2001/XInclude"/>
> > > +
> > >  http://www.w3.org/2001/XInclude"/>
> > >
> > >  
> > > diff --git a/src/mapi/glapi/gen/meson.build
> b/src/mapi/glapi/gen/meson.build
> > > index f494e9707b6..8cc163b2989 100644
> > > --- a/src/mapi/glapi/gen/meson.build
> > > +++ b/src/mapi/glapi/gen/meson.build
> > > @@ -107,6 +107,7 @@ api_xml_files = files(
> > >'EXT_external_objects_fd.xml',
> > >'EXT_framebuffer_object.xml',
> > >'EXT_gpu_shader4.xml',
> > > +  'EXT_multisampled_render_to_texture.xml',
> > >'EXT_packed_depth_stencil.xml',
> > >'EXT_provoking_vertex.xml',
> > >'EXT_separate_shader_objects.xml',
> > > diff --git a/src/mesa/drivers/common/meta.c
> b/src/mesa/drivers/common/meta.c
> > > index 4392c4bbd88..3515e312023 100644
> > > --- a/src/mesa/drivers/common/meta.c
> > > +++ b/src/mesa/drivers/common/meta.c
> > > @@ -127,7 +127,7 @@ _mesa_meta_framebuffer_texture_image(struct
> gl_context *ctx,
> > > assert(att);
> > >
> > > _mesa_framebuffer_texture(ctx, fb, attachment, att, texObj,
> texTarget,
> > > - level, layer, false);
> > > + level, att->NumSamples, layer, false);
> > >  }
> > >
> > >  static struct gl_shader *
> > > diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> > > index a516a1b17f8..f13b8b6a21a 100644
> > > --- a/src/mesa/main/extensions_table.h
> > > +++ b/src/mesa/main/extensions_table.h
> > > @@ -241,6 +241,8 @@ EXT(EXT_map_buffer_range,
> ARB_map_buffer_range
> > >  EXT(EXT_memory_object   , EXT_memory_object
> , GLL, GLC,  x , ES2, 2017)
> > >  EXT(EXT_memory_object_fd, EXT_memory_object_fd
>, GLL, GLC,  x , ES2, 2017)
> > >  EXT(EXT_multi_draw_arrays   , dummy_true
>, GLL,  x , ES1, ES2, 1999)
> > > +EXT(EXT_multisampled_render_to_texture  ,
> EXT_multisampled_render_to_texture ,  x ,  x ,  x , ES2, 2016)
> > > +EXT(EXT_multisampled_render_to_texture2 

Re: [Mesa-dev] [PATCH v2] build: remove autotools

2018-12-04 Thread Dylan Baker
Quoting Eric Engestrom (2018-12-04 09:36:53)
> On Tuesday, 2018-12-04 09:16:18 -0800, Dylan Baker wrote:
> > There are now no known distributions using autotools, meson has all of
> > the features that autotools does. We don't need two build systems to do
> > exactly the same thing, meson is faster, easier to maintain, and used by
> > more devs than autotools. Let's reduce the ongoing burden of maintaining
> > autotools.
> > 
> > This removes the following:
> >  - configure.ac
> >  - autogen.sh
> >  - Makefile.*.am
> >  - Makefile.am
> >  - Makefile.sources (which are used only by autotools)
> >  - travis jobs for autotools
> >  - docs for autotools
> >  - .gitignore
> > 
> > v2: - remove stray no-op change in .travis.yml
> > ---
> [snip]
> > diff --git a/.travis.yml b/.travis.yml
> > index 6b50d49e143..66be44ffc21 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -74,240 +74,13 @@ matrix:
> >  - python3.5
> >  - python3-pip
> >  - env:
> > -- LABEL="make loaders/classic DRI"
> > -- BUILD=make
> > -- MAKEFLAGS="-j4"
> > -- MAKE_CHECK_COMMAND="make check"
> > -- DRI_LOADERS="--enable-glx --enable-gbm --enable-egl 
> > --with-platforms=x11,drm,surfaceless,wayland --enable-osmesa"
> > -- DRI_DRIVERS="i915,i965,radeon,r200,swrast,nouveau"
> > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> > --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> > --disable-omx-bellagio --disable-gallium-osmesa"
> > -- GALLIUM_DRIVERS=""
> > -- VULKAN_DRIVERS=""
> > -- LIBUNWIND_FLAGS="--disable-libunwind"
> > -  addons:
> > -apt:
> > -  packages:
> > -- xz-utils
> > -- x11proto-xf86vidmode-dev
> > -- libexpat1-dev
> > -- libx11-xcb-dev
> > -- libxdamage-dev
> > -- libxfixes-dev
> > -- python3-pip
> > -- env:
> > -# NOTE: Building SWR is 2x (yes two) times slower than all the 
> > other
> > -# gallium drivers combined.
> > -# Start this early so that it doesn't hunder the run time.
> > -- LABEL="make Gallium Drivers SWR"
> > -- BUILD=make
> > -- MAKEFLAGS="-j4"
> > -- MAKE_CHECK_COMMAND="true"
> > -- LLVM_VERSION=6.0
> > -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> > -- DRI_DRIVERS=""
> > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> > --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> > --disable-omx-bellagio --disable-gallium-osmesa"
> > -- GALLIUM_DRIVERS="swr"
> > -- VULKAN_DRIVERS=""
> > -- LIBUNWIND_FLAGS="--enable-libunwind"
> > -  addons:
> > -apt:
> > -  sources:
> > -- llvm-toolchain-trusty-6.0
> > -# llvm-6 requires libstdc++4.9 which is not in main repo
> > -- ubuntu-toolchain-r-test
> > -  packages:
> > -# From sources above
> > -- llvm-6.0-dev
> > -# Common
> > -- xz-utils
> > -- libexpat1-dev
> > -- libx11-xcb-dev
> > -- libelf-dev
> > -- libunwind8-dev
> > -- python3-pip
> > -- env:
> > -- LABEL="make Gallium Drivers RadeonSI"
> > -- BUILD=make
> > -- MAKEFLAGS="-j4"
> > -- MAKE_CHECK_COMMAND="true"
> > -- LLVM_VERSION=6.0
> > -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> > -- DRI_DRIVERS=""
> > -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> > --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> > --disable-omx-bellagio --disable-gallium-osmesa"
> > -- GALLIUM_DRIVERS="radeonsi"
> > -- VULKAN_DRIVERS=""
> > -- LIBUNWIND_FLAGS="--enable-libunwind"
> > -  addons:
> > -apt:
> > -  sources:
> > -- llvm-toolchain-trusty-6.0
> > -# llvm-6 requires libstdc++4.9 which is not in main repo
> > -- ubuntu-toolchain-r-test
> > -  packages:
> > -# From sources above
> > -- llvm-6.0-dev
> > -# Common
> > -- xz-utils
> > -- libexpat1-dev
> > -- libx11-xcb-dev
> > -- libelf-dev
> > -- libunwind8-dev
> > -- python3-pip
> > -- env:
> > -- LABEL="make Gallium Drivers Other"
> > -- BUILD=make
> > -- MAKEFLAGS="-j4"
> > -- MAKE_CHECK_COMMAND="true"
> > -- LLVM_VERSION=3.9
> > -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > -# New binutils linker is required for llvm-3.9
> > -- OVERRIDE_PATH=/usr/lib/binutils-2.26/bin
> > -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> > -  

Re: [Mesa-dev] [PATCH mesa] drop autotools

2018-12-04 Thread Matt Turner
On Tue, Dec 4, 2018 at 12:48 PM Gert Wollny  wrote:
> FWIW, I also don't understand the urge to remove the automake build
> system files, they account for less then 1% of line count in the source
> tree, Emil offered to maintain the build system in a way that nobody
> who doesn't want to deal with has to touch it

Do you see any value in removing the autotools build system at all?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] build: remove autotools

2018-12-04 Thread Dylan Baker
Quoting Marek Olšák (2018-12-04 12:21:58)
> There is still the issue that DEBUG is not defined in debug builds if I set
> CFLAGS and CXXFLAGS.
> 
> Marek

What does you command line look like, and what version of meson do you have?

I can do:
$ CFLAGS=-Dfoobar CXXFLAGS=-Dfoobar meson build -Dbuildtype=debug
$ grep 'DDEBUG' build/build.ninja

and I see 2055 definitions of -DDEBUG

Dylan


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] radv: fix vkCmdCopyQueryoolResults() for timestamp queries

2018-12-04 Thread Bas Nieuwenhuizen
On Tue, Dec 4, 2018 at 4:52 PM Samuel Pitoiset
 wrote:
>
> Because WAIT_REG_MEM can only wait for a 32-bit value, it's not
> safe to use it for timestamp queries. If we only wait on the low
> 32 bits of a timestamp query we could be unlucky and the GPU
> might hang.
>
> One possible fix is to emit a full end of pipe event and wait
> on a 32-bit value which is actually an availability bit. This
> bit is allocated at creation time and always cleared before
> emitting the EOP event.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
> Fixes: 5d6a560a29 ("radv: do not use the availability bit for timestamp 
> queries")
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_query.c | 49 +++--
>  1 file changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 550abe307a1..9bb6b660add 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1056,8 +1056,15 @@ VkResult radv_CreateQueryPool(
> pool->pipeline_stats_mask = pCreateInfo->pipelineStatistics;
> pool->availability_offset = pool->stride * pCreateInfo->queryCount;
> pool->size = pool->availability_offset;
> -   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS)
> +   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS) {
> pool->size += 4 * pCreateInfo->queryCount;
> +   } else if (pCreateInfo->queryType == VK_QUERY_TYPE_TIMESTAMP) {
> +   /* Allocate one DWORD for the availability bit which is needed
> +* for vkCmdCopyQueryPoolResults() because we can't perform a
> +* WAIT_REG_MEM on a 64-bit value.
> +*/
> +   pool->size += 4;
> +   }
>
> pool->bo = device->ws->buffer_create(device->ws, pool->size,
>  64, RADEON_DOMAIN_GTT, 
> RADEON_FLAG_NO_INTERPROCESS_SHARING);
> @@ -1328,19 +1335,45 @@ void radv_CmdCopyQueryPoolResults(
>   pool->availability_offset + 4 * firstQuery);
> break;
> case VK_QUERY_TYPE_TIMESTAMP:
> +   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
> +   /* Emit a full end of pipe event because we can't
> +* perform a WAIT_REG_MEM on a 64-bit value. If we 
> only
> +* do a WAIT_REG_MEM on the low 32 bits of a timestamp
> +* query we could be unlucky and the GPU might hang.
> +*/
> +   enum chip_class chip = 
> cmd_buffer->device->physical_device->rad_info.chip_class;
> +   bool is_mec = radv_cmd_buffer_uses_mec(cmd_buffer);
> +   uint64_t avail_va = va + pool->availability_offset;
> +
> +   /* Clear the availability bit before waiting on the 
> end
> +* of pipe event.
> +*/
> +   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
> +   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
> +   S_370_WR_CONFIRM(1) |
> +   S_370_ENGINE_SEL(V_370_ME));
> +   radeon_emit(cs, avail_va);
> +   radeon_emit(cs, avail_va >> 32);
> +   radeon_emit(cs, 0xdeadbeef);
> +
> +   /* Wait for all prior GPU work. */
> +   si_cs_emit_write_event_eop(cs, chip, is_mec,
> +  
> V_028A90_BOTTOM_OF_PIPE_TS, 0,
> +  EOP_DATA_SEL_VALUE_32BIT,
> +  avail_va, 0, 1,
> +  
> cmd_buffer->gfx9_eop_bug_va);
> +
> +   /* Wait on the timestamp value. */
> +   radv_cp_wait_mem(cs, WAIT_REG_MEM_EQUAL, avail_va,
> +1, 0x);
> +   }
> +

Can we put this in a separate function? Also, you'll want to allocate
the availability bit in the upload buffer, in case there are multiple
concurrent command buffers using the same query pool.

Alternative solution: look at the upper 32 bits, those definitely
should not be 0xfff until a far away point in the future.

> for(unsigned i = 0; i < queryCount; ++i, dest_va += stride) {
> unsigned query = firstQuery + i;
> uint64_t local_src_va = va  + query * pool->stride;
>
> MAYBE_UNUSED unsigned cdw_max = 
> radeon_check_space(cmd_buffer->device->ws, cs, 19);
>
> -
> -   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
> -   radv_cp_wait_mem(cs, WAIT_REG_MEM_NOT_EQUAL,
> -

[Mesa-dev] [PATCH 2/5] meson: Fix ppc64 little endian detection

2018-12-04 Thread Dylan Baker
Old versions of meson returned ppc64le as the cpu_family for little
endian power8 cpus, versions >=0.48 don't do this, so the check wouldn't
work in that case. This generalizes the check to work for both old and
new versions of meson.

Fixes: 34bbb24ce7702658cdc4e9d34a650e169716c39e
   ("meson: Add support for ppc assembly/optimizations")
---
 meson.build | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 48ba8127f95..3d07c88364a 100644
--- a/meson.build
+++ b/meson.build
@@ -625,7 +625,12 @@ if with_gallium_st_nine
 endif
 
 if get_option('power8') != 'false'
-  if host_machine.cpu_family() == 'ppc64le'
+  # on old versions of meson the cpu family would return as ppc64le on little
+  # endian power8, this was changed in 0.48 such that the family would always
+  # be ppc64 regardless of endianness, and the the machine.endian() value
+  # should be checked. Since we support versions < 0.48 we need to use
+  # startswith.
+  if host_machine.cpu_family().startswith('ppc64') and host_machine.endian() 
== 'little'
 if cc.get_id() == 'gcc' and cc.version().version_compare('< 4.8')
   error('Altivec is not supported with gcc version < 4.8.')
 endif
@@ -966,7 +971,7 @@ if with_asm
   with_asm_arch = 'sparc'
   pre_args += ['-DUSE_SPARC_ASM']
 endif
-  elif host_machine.cpu_family() == 'ppc64le'
+  elif host_machine.cpu_family().startswith('ppc64') and host_machine.endian() 
== 'little'
 if system_has_kms_drm
   with_asm_arch = 'ppc64le'
   pre_args += ['-DUSE_PPC64LE_ASM']
-- 
2.19.2

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


[Mesa-dev] [PATCH 4/5] meson: Add support for gnu hurd

2018-12-04 Thread Dylan Baker
---
 meson.build | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 0785609c4b0..3f835e2b952 100644
--- a/meson.build
+++ b/meson.build
@@ -220,8 +220,6 @@ elif system_has_kms_drm
 else
   # FIXME: haiku doesn't use dri, and xlib doesn't use dri, probably should
   # assert here that one of those cases has been met.
-  # FIXME: GNU (hurd) ends up here as well, but meson doesn't officially
-  # support Hurd at time of writing (2017/11)
   # FIXME: illumos ends up here as well
   with_dri_platform = 'none'
 endif
@@ -795,7 +793,7 @@ if cc.compiles('int foo(void) 
__attribute__((__noreturn__));',
 endif
 
 # TODO: this is very incomplete
-if ['linux', 'cygwin'].contains(host_machine.system())
+if ['linux', 'cygwin', 'gnu'].contains(host_machine.system())
   pre_args += '-D_GNU_SOURCE'
 endif
 
@@ -954,7 +952,7 @@ endif
 with_asm_arch = ''
 if with_asm
   if host_machine.cpu_family() == 'x86'
-if system_has_kms_drm
+if system_has_kms_drm or host_machine.system() == 'gnu'
   with_asm_arch = 'x86'
   pre_args += ['-DUSE_X86_ASM', '-DUSE_MMX_ASM', '-DUSE_3DNOW_ASM',
'-DUSE_SSE_ASM']
-- 
2.19.2

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


[Mesa-dev] [PATCH 3/5] meson: Override C++ standard to gnu++11 when building with altivec on ppc64le

2018-12-04 Thread Dylan Baker
Otherwise there will be symbol collisions for the vector name.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108943
Fixes: 34bbb24ce7702658cdc4e9d34a650e169716c39e
   ("meson: Add support for ppc assembly/optimizations")
---
 meson.build   | 12 
 src/gallium/state_trackers/clover/meson.build |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/meson.build b/meson.build
index 3d07c88364a..0785609c4b0 100644
--- a/meson.build
+++ b/meson.build
@@ -624,6 +624,7 @@ if with_gallium_st_nine
   endif
 endif
 
+clover_cpp_std = []
 if get_option('power8') != 'false'
   # on old versions of meson the cpu family would return as ppc64le on little
   # endian power8, this was changed in 0.48 such that the family would always
@@ -631,6 +632,7 @@ if get_option('power8') != 'false'
   # should be checked. Since we support versions < 0.48 we need to use
   # startswith.
   if host_machine.cpu_family().startswith('ppc64') and host_machine.endian() 
== 'little'
+_test_args = []
 if cc.get_id() == 'gcc' and cc.version().version_compare('< 4.8')
   error('Altivec is not supported with gcc version < 4.8.')
 endif
@@ -645,9 +647,19 @@ if get_option('power8') != 'false'
 args : '-mpower8-vector',
 name : 'POWER8 intrinsics')
   pre_args += ['-D_ARCH_PWR8', '-mpower8-vector']
+  _test_args += ['-D_ARCH_PWR8', '-mpower8-vector']
 elif get_option('power8') == 'true'
   error('POWER8 intrinsic support required but not found.')
 endif
+
+if cpp.compiles('''
+#if !defined(__VEC__) || !defined(__ALTIVEC__)
+#error "AltiVec not enabled"
+#endif''',
+args : _test_args,
+name : 'Altivec')
+  clover_cpp_std += ['cpp_std=gnu++11']
+endif
   endif
 endif
 
diff --git a/src/gallium/state_trackers/clover/meson.build 
b/src/gallium/state_trackers/clover/meson.build
index 1a09d8f2ca9..a6729af2fb8 100644
--- a/src/gallium/state_trackers/clover/meson.build
+++ b/src/gallium/state_trackers/clover/meson.build
@@ -30,6 +30,7 @@ libcltgsi = static_library(
   files('tgsi/compiler.cpp', 'tgsi/invocation.hpp'),
   include_directories : clover_incs,
   cpp_args : [cpp_vis_args],
+  override_options : clover_cpp_std,
 )
 
 libclllvm = static_library(
@@ -56,6 +57,7 @@ libclllvm = static_library(
 )),
   ],
   dependencies : [dep_llvm, dep_elf],
+  override_options : clover_cpp_std,
 )
 
 clover_files = files(
@@ -119,4 +121,5 @@ libclover = static_library(
   include_directories : clover_incs,
   cpp_args : [clover_cpp_args, cpp_vis_args],
   link_with : [libcltgsi, libclllvm],
+  override_options : clover_cpp_std,
 )
-- 
2.19.2

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


[Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd

2018-12-04 Thread Dylan Baker
This little series is aimed at fixing problems reported by fedora and debian
when using meson, there's a couple of patches in here for fixing ppc64 detection
(tested without llvm), and a couple for gnu hurd (not tested).

Dylan Baker (5):
  meson: remove duplicate definition
  meson: Fix ppc64 little endian detection
  meson: Override C++ standard to gnu++11 when building with altivec on
ppc64le
  meson: Add support for gnu hurd
  meson: Add toggle for glx-direct

 meson.build   | 33 ---
 meson_options.txt |  6 
 src/gallium/state_trackers/clover/meson.build |  3 ++
 3 files changed, 31 insertions(+), 11 deletions(-)

-- 
2.19.2

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


[Mesa-dev] [PATCH 1/5] meson: remove duplicate definition

2018-12-04 Thread Dylan Baker
---
 meson.build | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meson.build b/meson.build
index 1aeef95f722..48ba8127f95 100644
--- a/meson.build
+++ b/meson.build
@@ -34,8 +34,6 @@ cpp = meson.get_compiler('cpp')
 
 null_dep = dependency('', required : false)
 
-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
-
 # Arguments for the preprocessor, put these in a separate array from the C and
 # C++ (cpp in meson terminology) arguments since they need to be added to the
 # default arguments for both C and C++.
-- 
2.19.2

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


[Mesa-dev] [PATCH 5/5] meson: Add toggle for glx-direct

2018-12-04 Thread Dylan Baker
GNU Hurd needs to turn off glx-direct, rather than special case it,
we'll just add a toggle.
---
 meson.build   | 4 +---
 meson_options.txt | 6 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index 3f835e2b952..3aacfa04900 100644
--- a/meson.build
+++ b/meson.build
@@ -51,6 +51,7 @@ with_valgrind = get_option('valgrind')
 with_libunwind = get_option('libunwind')
 with_asm = get_option('asm')
 with_glx_read_only_text = get_option('glx-read-only-text')
+with_glx_direct = get_option('glx-direct')
 with_osmesa = get_option('osmesa')
 with_swr_arches = get_option('swr-arches')
 with_tools = get_option('tools')
@@ -365,9 +366,6 @@ if with_glvnd
   endif
 endif
 
-# TODO: toggle for this
-with_glx_direct = true
-
 if with_vulkan_icd_dir == ''
   with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
 endif
diff --git a/meson_options.txt b/meson_options.txt
index a1d5ab0e185..589d10bb3f3 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -318,3 +318,9 @@ option(
   choices : ['auto', 'true', 'false'],
   description : 'Enable VK_EXT_acquire_xlib_display.'
 )
+option(
+  'glx-direct',
+  type : 'boolean',
+  value : true,
+  description : 'Enable direct rendering in GLX and EGL for DRI',
+)
-- 
2.19.2

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


[Mesa-dev] [Bug 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #26 from egon2003  ---
I just tried it with LLVM and Mesa from git and the glitch is gone.

However I see the glitch with Mesa 18.2.5 compiled against LLVM 7.0.0 and LLVM
7.0.1. The glitch is also there with Mesa 18.3.0-rc5 and LLVM 7.0.0 and LLVM
7.0.1.

Thanks for looking into this.

-- 
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: Be resilient in the face of GPU hangs

2018-12-04 Thread Chris Wilson
Quoting Chris Wilson (2018-10-24 09:40:08)
> If we hang the GPU and end up banning our context, we will no longer be
> able to submit and abort with an error (exit(1) no less). As we submit
> minimal incremental batches that rely on the logical context state of
> previous batches, we can not rely on the kernel's recovery mechanism
> which tries to restore the context back to a "golden" renderstate (the
> default HW setup) and replay the batches in flight. Instead, we must
> create a new context and set it up, including all the lost register
> settings that we only apply once during setup, before allow the user to
> continue rendering. The batches already submitted are lost
> (unrecoverable) so there will be a momentarily glitch and lost rendering
> across frames, but the application should be able to recover and
> continue on fairly oblivious.
> 
> To make wedging even more likely, we use a new "no recovery" context
> parameter that tells the kernel to not even attempt to replay any
> batches in flight against the default context image, as experience shows
> the HW is not always robust enough to cope with the conflicting state.
> 
> Cc: Kenneth Graunke 

So, give or take some forgotten state that is not reset on context reload,
what do you think about this as a stepping stone to handling GPU resets
robustly?

> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c| 25 +++
>  src/mesa/drivers/dri/i965/brw_bufmgr.h|  2 ++
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 19 ++
>  3 files changed, 46 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index f1675b191c1..328393e2ade 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -1589,6 +1589,16 @@ init_cache_buckets(struct brw_bufmgr *bufmgr)
> }
>  }
>  
> +static void init_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
> +{
> +   struct drm_i915_gem_context_param p = {
> +  .ctx_id = ctx_id,
> +  .param = 0x7, // I915_CONTEXT_PARAM_RECOVERABLE,
> +   };
> +
> +   drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> +}
> +
>  uint32_t
>  brw_create_hw_context(struct brw_bufmgr *bufmgr)
>  {
> @@ -1599,6 +1609,8 @@ brw_create_hw_context(struct brw_bufmgr *bufmgr)
>return 0;
> }
>  
> +   init_context(bufmgr, create.ctx_id);
> +
> return create.ctx_id;
>  }
>  
> @@ -1621,6 +1633,19 @@ brw_hw_context_set_priority(struct brw_bufmgr *bufmgr,
> return err;
>  }
>  
> +int
> +brw_hw_context_get_priority(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
> +{
> +   struct drm_i915_gem_context_param p = {
> +  .ctx_id = ctx_id,
> +  .param = I915_CONTEXT_PARAM_PRIORITY,
> +   };
> +
> +   drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, );
> +
> +   return p.value; /* on error, return 0 i.e. default priority */
> +}
> +
>  void
>  brw_destroy_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
>  {
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> index 32fc7a553c9..886b2e607ce 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
> @@ -356,6 +356,8 @@ uint32_t brw_create_hw_context(struct brw_bufmgr *bufmgr);
>  int brw_hw_context_set_priority(struct brw_bufmgr *bufmgr,
>  uint32_t ctx_id,
>  int priority);
> +int
> +brw_hw_context_get_priority(struct brw_bufmgr *bufmgr, uint32_t ctx_id);
>  
>  void brw_destroy_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id);
>  
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 4363b146150..73c2bbab18e 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -735,6 +735,18 @@ execbuffer(int fd,
> return ret;
>  }
>  
> +static void recreate_context(struct brw_context *brw)
> +{
> +   struct brw_bufmgr *bufmgr = brw->bufmgr;
> +   int prio;
> +
> +   prio = brw_hw_context_get_priority(bufmgr, brw->hw_ctx);
> +   brw_destroy_hw_context(bufmgr, brw->hw_ctx);
> +
> +   brw->hw_ctx = brw_create_hw_context(bufmgr);
> +   brw_hw_context_set_priority(bufmgr, brw->hw_ctx, prio);
> +}
> +
>  static int
>  submit_batch(struct brw_context *brw, int in_fence_fd, int *out_fence_fd)
>  {
> @@ -821,6 +833,13 @@ submit_batch(struct brw_context *brw, int in_fence_fd, 
> int *out_fence_fd)
> if (brw->ctx.Const.ResetStrategy == GL_LOSE_CONTEXT_ON_RESET_ARB)
>brw_check_for_reset(brw);
>  
> +   if (ret == -EIO) {
> +  recreate_context(brw);
> +  brw->ctx.NewDriverState |= BRW_NEW_CONTEXT;
> +  brw_upload_invariant_state(brw);
> +  ret = 0;
> +   }
> +
> if (ret != 0) {
>fprintf(stderr, "i965: Failed to submit batchbuffer: %s\n",
>strerror(-ret));
> -- 
> 2.19.1
> 

Re: [Mesa-dev] [PATCH] mesa/main: fix up _mesa_has_rg_textures for gles2

2018-12-04 Thread Mark Janes
Choose a well-named branch on your mesa repository that you will use to
trigger i965 CI builds.  Provide me with the branch name and the repo
details, and I will configure the build.

When you force-push to the branch, your build will start.  You will get
a notification when the build starts, and when it finishes.  Results
will appear on mesa-ci.01.org a few minutes after the final
notification.

Erik Faye-Lund  writes:

> On Tue, 2018-12-04 at 10:33 -0800, Mark Janes wrote:
>> Tested-by: Mark Janes 
>> 
>> Erik Faye-Lund  writes:
>> 
>> > rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's
>> > make
>> > sure the enums are accepted.
>> > 
>> > Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums
>> > before gles3"
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
>> > Signed-off-by: Erik Faye-Lund 
>> > ---
>> > Whoops, seems I missed an extension to enable RG-textures. Sorry
>> > for the
>> > breakage!
>> 
>> You are welcome to test on the i965 CI, which will quickly catch
>> these
>> errors for you.
>
> I would love to! How do I do that?
>
> I can't see an obvious way of triggering something here:
> https://mesa-ci.01.org/
>
>> 
>> >  src/mesa/main/context.h | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > 
>> > diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
>> > index cdda8cf2012..7de10e9924b 100644
>> > --- a/src/mesa/main/context.h
>> > +++ b/src/mesa/main/context.h
>> > @@ -378,7 +378,8 @@ _mesa_has_packed_float(const struct gl_context
>> > *ctx)
>> >  static inline bool
>> >  _mesa_has_rg_textures(const struct gl_context *ctx)
>> >  {
>> > -   return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
>> > +   return _mesa_has_ARB_texture_rg(ctx) ||
>> > _mesa_has_EXT_texture_rg(ctx) ||
>> > +  _mesa_is_gles3(ctx);
>> >  }
>> >  
>> >  static inline bool
>> > -- 
>> > 2.19.2
>> ___
>> 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 mesa] drop autotools

2018-12-04 Thread Gert Wollny
Am Dienstag, den 04.12.2018, 14:47 -0500 schrieb Jan Vesely:
> 
> > You can, that's what I've done as well. 0.49 just has a much nicer
> > mechanism (and one that presumably distro packagers can use more
> > easily).
> 
> I don't understand why distros are such a big focus. Don't they all
> have scripts to build packages? Why would volatility of configuration
> options be a problem for them?
> 
Usually they have, and at least in Debian when you build the package
for the package archive you also use a build environment that pulls
exactly in what is needed for building the package, so using the wrong
version because of some automatism usually point to some actual bug
either in the package itself or in the dependencies of the required
packages.

FWIW, I also don't understand the urge to remove the automake build
system files, they account for less then 1% of line count in the source
tree, Emil offered to maintain the build system in a way that nobody
who doesn't want to deal with has to touch it (which is different from
old drivers where changes to the core might actually require touching
these drivers too), and there are people out there like you who have a
technical reason not to switch to meson (yet). 

Best, 
Gert 


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


Re: [Mesa-dev] [PATCH 2/2] mesa: expose EXT_texture_compression_bptc in GLES

2018-12-04 Thread Erik Faye-Lund
Nice :)

For the series:
Reviewed-by: Erik Faye-Lund 

On Tue, 2018-12-04 at 14:57 -0500, Marek Olšák wrote:
> From: Marek Olšák 
> 
> tested by piglit.
> 
> v2: rebase
> 
> Reviewed-by: Ilia Mirkin  (v1)
> ---
>  docs/relnotes/19.0.0.html|  1 +
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/glformats.c| 13 -
>  src/mesa/main/texcompress.c  |  8 
>  4 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
> index 4a61420be1a..5a2e96e4eab 100644
> --- a/docs/relnotes/19.0.0.html
> +++ b/docs/relnotes/19.0.0.html
> @@ -33,20 +33,21 @@ Compatibility contexts may report a lower version
> depending on each driver.
>  SHA256 checksums
>  
>  TBD.
>  
>  
>  
>  New features
>  
>  
>  GL_EXT_shader_implicit_conversions on all drivers (ES
> extension).
> +GL_EXT_texture_compression_bptc on all GL 4.0 drivers (ES
> extension).
>  GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES
> extension).
>  GL_EXT_texture_view on drivers supporting texture views (ES
> extension).
>  GL_OES_texture_view on drivers supporting texture views (ES
> extension).
>  
>  
>  Bug fixes
>  
>  
>  TBD
>  
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index a229f3af2b2..d6ab81ee689 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -269,20 +269,21 @@ EXT(EXT_shadow_funcs,
> ARB_shadow
>  EXT(EXT_stencil_two_side,
> EXT_stencil_two_side   , GLL,  x ,  x ,  x , 2001)
>  EXT(EXT_stencil_wrap,
> dummy_true , GLL,  x ,  x ,  x , 2002)
>  EXT(EXT_subtexture  ,
> dummy_true , GLL,  x ,  x ,  x , 1995)
>  EXT(EXT_tessellation_point_size ,
> ARB_tessellation_shader,  x ,  x ,  x ,  31, 2013)
>  EXT(EXT_tessellation_shader ,
> ARB_tessellation_shader,  x ,  x ,  x ,  31, 2013)
>  EXT(EXT_texture ,
> dummy_true , GLL,  x ,  x ,  x , 1996)
>  EXT(EXT_texture3D   ,
> dummy_true , GLL,  x ,  x ,  x , 1996)
>  EXT(EXT_texture_array   ,
> EXT_texture_array  , GLL, GLC,  x ,  x , 2006)
>  EXT(EXT_texture_border_clamp,
> ARB_texture_border_clamp   ,  x ,  x ,  x , ES2, 2014)
>  EXT(EXT_texture_buffer  ,
> OES_texture_buffer ,  x ,  x ,  x ,  31, 2014)
> +EXT(EXT_texture_compression_bptc,
> ARB_texture_compression_bptc   ,  x ,  x ,  x ,  30, 2017)
>  EXT(EXT_texture_compression_dxt1,
> ANGLE_texture_compression_dxt  , GLL, GLC, ES1, ES2, 2004)
>  EXT(EXT_texture_compression_latc,
> EXT_texture_compression_latc   , GLL,  x ,  x ,  x , 2006)
>  EXT(EXT_texture_compression_rgtc,
> ARB_texture_compression_rgtc   , GLL, GLC,  x ,  30, 2004)
>  EXT(EXT_texture_compression_s3tc,
> EXT_texture_compression_s3tc   , GLL, GLC,  x , ES2, 2000)
>  EXT(EXT_texture_cube_map,
> ARB_texture_cube_map   , GLL,  x ,  x ,  x , 2001)
>  EXT(EXT_texture_cube_map_array  ,
> OES_texture_cube_map_array ,  x ,  x ,  x ,  31, 2014)
>  EXT(EXT_texture_edge_clamp  ,
> dummy_true , GLL,  x ,  x ,  x , 1997)
>  EXT(EXT_texture_env_add ,
> dummy_true , GLL,  x ,  x ,  x , 1999)
>  EXT(EXT_texture_env_combine ,
> dummy_true , GLL,  x ,  x ,  x , 2000)
>  EXT(EXT_texture_env_dot3,
> EXT_texture_env_dot3   , GLL,  x ,  x ,  x , 2000)
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index 77e0d94a71b..74e1d3761ec 100644
> --- a/src/mesa/main/glformats.c
> +++ b/src/mesa/main/glformats.c
> @@ -1381,21 +1381,22 @@ _mesa_is_compressed_format(const struct
> gl_context *ctx, GLenum format)
> case MESA_FORMAT_LAYOUT_RGTC:
>return _mesa_has_ARB_texture_compression_rgtc(ctx) ||
>   _mesa_has_EXT_texture_compression_rgtc(ctx);
> case MESA_FORMAT_LAYOUT_LATC:
>return _mesa_has_EXT_texture_compression_latc(ctx);
> case MESA_FORMAT_LAYOUT_ETC1:
>return _mesa_has_OES_compressed_ETC1_RGB8_texture(ctx);
> case MESA_FORMAT_LAYOUT_ETC2:
>return _mesa_is_gles3(ctx) ||
> _mesa_has_ARB_ES3_compatibility(ctx);
> case MESA_FORMAT_LAYOUT_BPTC:
> -  return _mesa_has_ARB_texture_compression_bptc(ctx);
> +  return _mesa_has_ARB_texture_compression_bptc(ctx) ||
> + _mesa_has_EXT_texture_compression_bptc(ctx);
> case MESA_FORMAT_LAYOUT_ASTC:
>  

Re: [Mesa-dev] [PATCH] gallium: Android build fixes

2018-12-04 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Tue, Dec 4, 2018 at 1:51 PM Kristian H. Kristensen 
wrote:

> A couple of simple fixes for building on Android with autotools.
> ---
>  src/gallium/auxiliary/util/u_debug_stack_android.cpp | 2 +-
>  src/gallium/drivers/freedreno/Makefile.am| 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> index 395a1fe911..879b0fb2e9 100644
> --- a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> +++ b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
> @@ -23,7 +23,7 @@
>
>  #include 
>
> -#include "u_debug.h"
> +#include "util/u_debug.h"
>  #include "u_debug_stack.h"
>  #include "util/hash_table.h"
>  #include "os/os_thread.h"
> diff --git a/src/gallium/drivers/freedreno/Makefile.am
> b/src/gallium/drivers/freedreno/Makefile.am
> index 32130ab94c..504ad290de 100644
> --- a/src/gallium/drivers/freedreno/Makefile.am
> +++ b/src/gallium/drivers/freedreno/Makefile.am
> @@ -7,6 +7,7 @@ AM_CFLAGS = \
> -I$(top_srcdir)/src/freedreno \
> -I$(top_builddir)/src/compiler/nir \
> -I$(top_srcdir)/src/compiler/nir \
> +   $(LIBDRM_CFLAGS) \
> $(GALLIUM_DRIVER_CFLAGS)
>
>  noinst_LTLIBRARIES = libfreedreno.la
> --
> 2.19.2
>
> ___
> 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] mesa/main: fix up _mesa_has_rg_textures for gles2

2018-12-04 Thread Erik Faye-Lund
On Tue, 2018-12-04 at 10:33 -0800, Mark Janes wrote:
> Tested-by: Mark Janes 
> 
> Erik Faye-Lund  writes:
> 
> > rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's
> > make
> > sure the enums are accepted.
> > 
> > Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums
> > before gles3"
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
> > Signed-off-by: Erik Faye-Lund 
> > ---
> > Whoops, seems I missed an extension to enable RG-textures. Sorry
> > for the
> > breakage!
> 
> You are welcome to test on the i965 CI, which will quickly catch
> these
> errors for you.

I would love to! How do I do that?

I can't see an obvious way of triggering something here:
https://mesa-ci.01.org/

> 
> >  src/mesa/main/context.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> > index cdda8cf2012..7de10e9924b 100644
> > --- a/src/mesa/main/context.h
> > +++ b/src/mesa/main/context.h
> > @@ -378,7 +378,8 @@ _mesa_has_packed_float(const struct gl_context
> > *ctx)
> >  static inline bool
> >  _mesa_has_rg_textures(const struct gl_context *ctx)
> >  {
> > -   return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
> > +   return _mesa_has_ARB_texture_rg(ctx) ||
> > _mesa_has_EXT_texture_rg(ctx) ||
> > +  _mesa_is_gles3(ctx);
> >  }
> >  
> >  static inline bool
> > -- 
> > 2.19.2
> ___
> 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] build: remove autotools

2018-12-04 Thread Marek Olšák
There is still the issue that DEBUG is not defined in debug builds if I set
CFLAGS and CXXFLAGS.

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


Re: [Mesa-dev] [PATCH] mesa/main: fix up _mesa_has_rg_textures for gles2

2018-12-04 Thread Erik Faye-Lund
Thanks, pushed :)

On Tue, 2018-12-04 at 15:03 -0500, Marek Olšák wrote:
> Reviewed-by: Marek Olšák 
> 
> Marek
> 
> On Tue, Dec 4, 2018 at 6:51 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's
> > make
> > sure the enums are accepted.
> > 
> > Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums
> > before gles3"
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
> > Signed-off-by: Erik Faye-Lund 
> > ---
> > Whoops, seems I missed an extension to enable RG-textures. Sorry
> > for the
> > breakage!
> > 
> >  src/mesa/main/context.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> > index cdda8cf2012..7de10e9924b 100644
> > --- a/src/mesa/main/context.h
> > +++ b/src/mesa/main/context.h
> > @@ -378,7 +378,8 @@ _mesa_has_packed_float(const struct gl_context
> > *ctx)
> >  static inline bool
> >  _mesa_has_rg_textures(const struct gl_context *ctx)
> >  {
> > -   return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
> > +   return _mesa_has_ARB_texture_rg(ctx) ||
> > _mesa_has_EXT_texture_rg(ctx) ||
> > +  _mesa_is_gles3(ctx);
> >  }
> > 
> >  static inline bool

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


Re: [Mesa-dev] [PATCH] mesa/main: fix up _mesa_has_rg_textures for gles2

2018-12-04 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Marek

On Tue, Dec 4, 2018 at 6:51 AM Erik Faye-Lund 
wrote:

> rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's make
> sure the enums are accepted.
>
> Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums before gles3"
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
> Signed-off-by: Erik Faye-Lund 
> ---
> Whoops, seems I missed an extension to enable RG-textures. Sorry for the
> breakage!
>
>  src/mesa/main/context.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> index cdda8cf2012..7de10e9924b 100644
> --- a/src/mesa/main/context.h
> +++ b/src/mesa/main/context.h
> @@ -378,7 +378,8 @@ _mesa_has_packed_float(const struct gl_context *ctx)
>  static inline bool
>  _mesa_has_rg_textures(const struct gl_context *ctx)
>  {
> -   return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
> +   return _mesa_has_ARB_texture_rg(ctx) || _mesa_has_EXT_texture_rg(ctx)
> ||
> +  _mesa_is_gles3(ctx);
>  }
>
>  static inline bool
> --
> 2.19.2
>
> ___
> 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: expose EXT_texture_compression_rgtc on GLES

2018-12-04 Thread Marek Olšák
From: Marek Olšák 

The spec was modified to support GLES. Tested by piglit.

v2: rebase

Reviewed-by: Ilia Mirkin  (v1)
---
 docs/relnotes/19.0.0.html|  1 +
 src/mesa/main/extensions_table.h |  2 +-
 src/mesa/main/glformats.c| 19 ++-
 src/mesa/main/texcompress.c  |  9 +
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
index 1629e0ba52e..4a61420be1a 100644
--- a/docs/relnotes/19.0.0.html
+++ b/docs/relnotes/19.0.0.html
@@ -33,20 +33,21 @@ Compatibility contexts may report a lower version depending 
on each driver.
 SHA256 checksums
 
 TBD.
 
 
 
 New features
 
 
 GL_EXT_shader_implicit_conversions on all drivers (ES extension).
+GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES extension).
 GL_EXT_texture_view on drivers supporting texture views (ES 
extension).
 GL_OES_texture_view on drivers supporting texture views (ES 
extension).
 
 
 Bug fixes
 
 
 TBD
 
 
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 8d6d56c640d..a229f3af2b2 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -271,21 +271,21 @@ EXT(EXT_stencil_wrap, dummy_true
 EXT(EXT_subtexture  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
 EXT(EXT_tessellation_point_size , ARB_tessellation_shader  
  ,  x ,  x ,  x ,  31, 2013)
 EXT(EXT_tessellation_shader , ARB_tessellation_shader  
  ,  x ,  x ,  x ,  31, 2013)
 EXT(EXT_texture , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
 EXT(EXT_texture3D   , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
 EXT(EXT_texture_array   , EXT_texture_array
  , GLL, GLC,  x ,  x , 2006)
 EXT(EXT_texture_border_clamp, ARB_texture_border_clamp 
  ,  x ,  x ,  x , ES2, 2014)
 EXT(EXT_texture_buffer  , OES_texture_buffer   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt
  , GLL, GLC, ES1, ES2, 2004)
 EXT(EXT_texture_compression_latc, EXT_texture_compression_latc 
  , GLL,  x ,  x ,  x , 2006)
-EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc 
  , GLL, GLC,  x ,  x , 2004)
+EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc 
  , GLL, GLC,  x ,  30, 2004)
 EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc 
  , GLL, GLC,  x , ES2, 2000)
 EXT(EXT_texture_cube_map, ARB_texture_cube_map 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_texture_edge_clamp  , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
 EXT(EXT_texture_env_add , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
 EXT(EXT_texture_env_combine , dummy_true   
  , GLL,  x ,  x ,  x , 2000)
 EXT(EXT_texture_env_dot3, EXT_texture_env_dot3 
  , GLL,  x ,  x ,  x , 2000)
 EXT(EXT_texture_filter_anisotropic  , EXT_texture_filter_anisotropic   
  , GLL, GLC, ES1, ES2, 1999)
 EXT(EXT_texture_format_BGRA , dummy_true   
  ,  x ,  x , ES1, ES2, 2005)
 EXT(EXT_texture_integer , EXT_texture_integer  
  , GLL, GLC,  x ,  x , 2006)
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 7506c238232..77e0d94a71b 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1372,21 +1372,22 @@ _mesa_is_compressed_format(const struct gl_context 
*ctx, GLenum format)
case MESA_FORMAT_LAYOUT_S3TC:
   if (_mesa_get_format_color_encoding(m_format) == GL_LINEAR) {
  return _mesa_has_EXT_texture_compression_s3tc(ctx);
   } else {
  return _mesa_has_EXT_texture_sRGB(ctx) &&
 _mesa_has_EXT_texture_compression_s3tc(ctx);
   }
case MESA_FORMAT_LAYOUT_FXT1:
   return _mesa_has_3DFX_texture_compression_FXT1(ctx);
case MESA_FORMAT_LAYOUT_RGTC:
-  return _mesa_has_ARB_texture_compression_rgtc(ctx);
+  return _mesa_has_ARB_texture_compression_rgtc(ctx) ||
+ _mesa_has_EXT_texture_compression_rgtc(ctx);
case MESA_FORMAT_LAYOUT_LATC:
   return _mesa_has_EXT_texture_compression_latc(ctx);
case MESA_FORMAT_LAYOUT_ETC1:
   return _mesa_has_OES_compressed_ETC1_RGB8_texture(ctx);
case MESA_FORMAT_LAYOUT_ETC2:
   return _mesa_is_gles3(ctx) || _mesa_has_ARB_ES3_compatibility(ctx);
case 

[Mesa-dev] [PATCH 2/2] mesa: expose EXT_texture_compression_bptc in GLES

2018-12-04 Thread Marek Olšák
From: Marek Olšák 

tested by piglit.

v2: rebase

Reviewed-by: Ilia Mirkin  (v1)
---
 docs/relnotes/19.0.0.html|  1 +
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/glformats.c| 13 -
 src/mesa/main/texcompress.c  |  8 
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
index 4a61420be1a..5a2e96e4eab 100644
--- a/docs/relnotes/19.0.0.html
+++ b/docs/relnotes/19.0.0.html
@@ -33,20 +33,21 @@ Compatibility contexts may report a lower version depending 
on each driver.
 SHA256 checksums
 
 TBD.
 
 
 
 New features
 
 
 GL_EXT_shader_implicit_conversions on all drivers (ES extension).
+GL_EXT_texture_compression_bptc on all GL 4.0 drivers (ES extension).
 GL_EXT_texture_compression_rgtc on all GL 3.0 drivers (ES extension).
 GL_EXT_texture_view on drivers supporting texture views (ES 
extension).
 GL_OES_texture_view on drivers supporting texture views (ES 
extension).
 
 
 Bug fixes
 
 
 TBD
 
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index a229f3af2b2..d6ab81ee689 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -269,20 +269,21 @@ EXT(EXT_shadow_funcs, ARB_shadow
 EXT(EXT_stencil_two_side, EXT_stencil_two_side 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_stencil_wrap, dummy_true   
  , GLL,  x ,  x ,  x , 2002)
 EXT(EXT_subtexture  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
 EXT(EXT_tessellation_point_size , ARB_tessellation_shader  
  ,  x ,  x ,  x ,  31, 2013)
 EXT(EXT_tessellation_shader , ARB_tessellation_shader  
  ,  x ,  x ,  x ,  31, 2013)
 EXT(EXT_texture , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
 EXT(EXT_texture3D   , dummy_true   
  , GLL,  x ,  x ,  x , 1996)
 EXT(EXT_texture_array   , EXT_texture_array
  , GLL, GLC,  x ,  x , 2006)
 EXT(EXT_texture_border_clamp, ARB_texture_border_clamp 
  ,  x ,  x ,  x , ES2, 2014)
 EXT(EXT_texture_buffer  , OES_texture_buffer   
  ,  x ,  x ,  x ,  31, 2014)
+EXT(EXT_texture_compression_bptc, ARB_texture_compression_bptc 
  ,  x ,  x ,  x ,  30, 2017)
 EXT(EXT_texture_compression_dxt1, ANGLE_texture_compression_dxt
  , GLL, GLC, ES1, ES2, 2004)
 EXT(EXT_texture_compression_latc, EXT_texture_compression_latc 
  , GLL,  x ,  x ,  x , 2006)
 EXT(EXT_texture_compression_rgtc, ARB_texture_compression_rgtc 
  , GLL, GLC,  x ,  30, 2004)
 EXT(EXT_texture_compression_s3tc, EXT_texture_compression_s3tc 
  , GLL, GLC,  x , ES2, 2000)
 EXT(EXT_texture_cube_map, ARB_texture_cube_map 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_texture_cube_map_array  , OES_texture_cube_map_array   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_texture_edge_clamp  , dummy_true   
  , GLL,  x ,  x ,  x , 1997)
 EXT(EXT_texture_env_add , dummy_true   
  , GLL,  x ,  x ,  x , 1999)
 EXT(EXT_texture_env_combine , dummy_true   
  , GLL,  x ,  x ,  x , 2000)
 EXT(EXT_texture_env_dot3, EXT_texture_env_dot3 
  , GLL,  x ,  x ,  x , 2000)
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 77e0d94a71b..74e1d3761ec 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1381,21 +1381,22 @@ _mesa_is_compressed_format(const struct gl_context 
*ctx, GLenum format)
case MESA_FORMAT_LAYOUT_RGTC:
   return _mesa_has_ARB_texture_compression_rgtc(ctx) ||
  _mesa_has_EXT_texture_compression_rgtc(ctx);
case MESA_FORMAT_LAYOUT_LATC:
   return _mesa_has_EXT_texture_compression_latc(ctx);
case MESA_FORMAT_LAYOUT_ETC1:
   return _mesa_has_OES_compressed_ETC1_RGB8_texture(ctx);
case MESA_FORMAT_LAYOUT_ETC2:
   return _mesa_is_gles3(ctx) || _mesa_has_ARB_ES3_compatibility(ctx);
case MESA_FORMAT_LAYOUT_BPTC:
-  return _mesa_has_ARB_texture_compression_bptc(ctx);
+  return _mesa_has_ARB_texture_compression_bptc(ctx) ||
+ _mesa_has_EXT_texture_compression_bptc(ctx);
case MESA_FORMAT_LAYOUT_ASTC:
   return _mesa_has_KHR_texture_compression_astc_ldr(ctx);
default:
   return GL_FALSE;
}
 }
 
 /**
  * Test if the given format represents an sRGB format.
  * \param format the GL format (can be an internal format)
@@ -2837,20 +2838,25 @@ _mesa_gles_error_check_format_and_type(const struct 
gl_context 

Re: [Mesa-dev] [PATCH mesa] drop autotools

2018-12-04 Thread Jan Vesely
On Mon, 2018-12-03 at 16:17 -0800, Dylan Baker wrote:
> Quoting Bas Nieuwenhuizen (2018-12-03 14:14:19)
> > On Mon, Dec 3, 2018 at 7:30 PM Jan Vesely  wrote:
> > > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> > > > Cc: Emil Velikov 
> > > > Cc: Andres Gomez 
> > > > Cc: Juan A. Suarez Romero 
> > > > Cc: Dylan Baker 
> > > > Signed-off-by: Eric Engestrom 
> > > > ---
> > > > This patch depends on the releasing procedure in docs/releasing.html to
> > > > be updated to not rely on autotools anymore.
> > > > 
> > > > I think our release managers (cc'ed) should work together and figure out
> > > > the procedure they want to go by; only once that's done can we delete
> > > > these 200+ files and 14k+ lines :)
> > > 
> > > once again, I'm going to request that this patch is delayed until meson
> > > 0.49 is more widely available (it has not been released yet!).
> > > afaik, there is currently no way to build against non-default llvm
> > > outside autotools.
> > 
> > Can't you just add the llvm-config of the non-default to the PATH (and
> > if you have a setup which instead of putting it in a different path
> > suffixes it, make a new directory, add a llvm-config symlink in there
> > and add that to the PATH)? I've been building with non-default llvm
> > for ages with meson.

It works as a backstop for scripted updates. The problem is that the
next rebuild will silently switch to system default llvm, so I'd need
to set the PATH before every ninja call.

> You can, that's what I've done as well. 0.49 just has a much nicer mechanism
> (and one that presumably distro packagers can use more easily).

I don't understand why distros are such a big focus. Don't they all
have scripts to build packages? Why would volatility of configuration
options be a problem for them?
Then again I'm not a distro maintainer ...

Jan

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



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


Re: [Mesa-dev] Make Jordan an Owner of the mesa project?

2018-12-04 Thread Rob Clark
On Mon, Dec 3, 2018 at 7:49 PM Jason Ekstrand  wrote:
>
> Jordan has requested to be made an Owner of the mesa project.  As much as I 
> may be the guy who pushed to get everything set up, I don't want to do this 
> sort of thing on my own.  As such, I'm asking for some ACKs.  If I can get 5 
> ACKs (at least 2 non-intel) from other Owners and no NAKs, I'll click the 
> button.
>
> Personally, I think the answer here is absurdly obvious.  Jordan is one of 
> the most involved people in the community. :-D
>
> As a side-note, does this seem like a reasonable process for adding people as 
> Owners?
>

Ack

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


[Mesa-dev] [PATCH] gallium: Android build fixes

2018-12-04 Thread Kristian H. Kristensen
A couple of simple fixes for building on Android with autotools.
---
 src/gallium/auxiliary/util/u_debug_stack_android.cpp | 2 +-
 src/gallium/drivers/freedreno/Makefile.am| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/util/u_debug_stack_android.cpp 
b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
index 395a1fe911..879b0fb2e9 100644
--- a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
+++ b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
@@ -23,7 +23,7 @@
 
 #include 
 
-#include "u_debug.h"
+#include "util/u_debug.h"
 #include "u_debug_stack.h"
 #include "util/hash_table.h"
 #include "os/os_thread.h"
diff --git a/src/gallium/drivers/freedreno/Makefile.am 
b/src/gallium/drivers/freedreno/Makefile.am
index 32130ab94c..504ad290de 100644
--- a/src/gallium/drivers/freedreno/Makefile.am
+++ b/src/gallium/drivers/freedreno/Makefile.am
@@ -7,6 +7,7 @@ AM_CFLAGS = \
-I$(top_srcdir)/src/freedreno \
-I$(top_builddir)/src/compiler/nir \
-I$(top_srcdir)/src/compiler/nir \
+   $(LIBDRM_CFLAGS) \
$(GALLIUM_DRIVER_CFLAGS)
 
 noinst_LTLIBRARIES = libfreedreno.la
-- 
2.19.2

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


[Mesa-dev] [Bug 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #11 from Igor Gnatenko  ---
Yeah, the gnu++11 fixes problem.

And also submitted https://gitlab.freedesktop.org/dbaker/mesa/issues/21.

-- 
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] mesa/main: fix up _mesa_has_rg_textures for gles2

2018-12-04 Thread Mark Janes
Tested-by: Mark Janes 

Erik Faye-Lund  writes:

> rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's make
> sure the enums are accepted.
>
> Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums before gles3"
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936
> Signed-off-by: Erik Faye-Lund 
> ---
> Whoops, seems I missed an extension to enable RG-textures. Sorry for the
> breakage!

You are welcome to test on the i965 CI, which will quickly catch these
errors for you.

>  src/mesa/main/context.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> index cdda8cf2012..7de10e9924b 100644
> --- a/src/mesa/main/context.h
> +++ b/src/mesa/main/context.h
> @@ -378,7 +378,8 @@ _mesa_has_packed_float(const struct gl_context *ctx)
>  static inline bool
>  _mesa_has_rg_textures(const struct gl_context *ctx)
>  {
> -   return _mesa_has_ARB_texture_rg(ctx) || _mesa_is_gles3(ctx);
> +   return _mesa_has_ARB_texture_rg(ctx) || _mesa_has_EXT_texture_rg(ctx) ||
> +  _mesa_is_gles3(ctx);
>  }
>  
>  static inline bool
> -- 
> 2.19.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/12] vtn: handle SpvExecutionModelKernel

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/spirv/spirv_to_nir.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index f6a7cd6c4fd..2c2dbe12a3c 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3319,6 +3319,8 @@ stage_for_execution_model(struct vtn_builder *b, 
SpvExecutionModel model)
   return MESA_SHADER_FRAGMENT;
case SpvExecutionModelGLCompute:
   return MESA_SHADER_COMPUTE;
+   case SpvExecutionModelKernel:
+  return MESA_SHADER_KERNEL;
default:
   vtn_fail("Unsupported execution model");
}
-- 
2.19.2

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


[Mesa-dev] [PATCH 12/12] nir/spirv: handle ContractionOff execution mode

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/spirv/spirv_info.h| 1 +
 src/compiler/spirv/spirv_info_c.py | 1 +
 src/compiler/spirv/spirv_to_nir.c  | 9 -
 src/compiler/spirv/vtn_alu.c   | 4 ++--
 src/compiler/spirv/vtn_cfg.c   | 2 ++
 src/compiler/spirv/vtn_private.h   | 3 +++
 6 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv_info.h b/src/compiler/spirv/spirv_info.h
index 121ffd2febb..a03c2ef8eb0 100644
--- a/src/compiler/spirv/spirv_info.h
+++ b/src/compiler/spirv/spirv_info.h
@@ -28,6 +28,7 @@
 
 const char *spirv_capability_to_string(SpvCapability cap);
 const char *spirv_decoration_to_string(SpvDecoration dec);
+const char *spirv_executionmode_to_string(SpvExecutionMode mode);
 const char *spirv_op_to_string(SpvOp op);
 
 #endif /* SPIRV_INFO_H */
diff --git a/src/compiler/spirv/spirv_info_c.py 
b/src/compiler/spirv/spirv_info_c.py
index ff7942bcd3a..6880d3e329d 100644
--- a/src/compiler/spirv/spirv_info_c.py
+++ b/src/compiler/spirv/spirv_info_c.py
@@ -90,6 +90,7 @@ if __name__ == "__main__":
 info = [
 collect_data(spirv_info, "Capability"),
 collect_data(spirv_info, "Decoration"),
+collect_data(spirv_info, "ExecutionMode"),
 collect_opcodes(spirv_info),
 ]
 
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 1a7d5b3a9bd..488c61cf1c6 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3771,9 +3771,16 @@ vtn_handle_execution_mode(struct vtn_builder *b, struct 
vtn_value *entry_point,
   break;
 
case SpvExecutionModeVecTypeHint:
-   case SpvExecutionModeContractionOff:
   break; /* OpenCL */
 
+   case SpvExecutionModeContractionOff:
+  if (b->shader->info.stage != MESA_SHADER_KERNEL)
+ vtn_warn("ExectionMode only allowed for CL-style kernels: %s",
+  spirv_executionmode_to_string(mode->exec_mode));
+  else
+ b->exact = true;
+  break;
+
case SpvExecutionModeStencilRefReplacingEXT:
   vtn_assert(b->shader->info.stage == MESA_SHADER_FRAGMENT);
   break;
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index dc6fedc9129..f910630acfb 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -395,7 +395,7 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
if (glsl_type_is_matrix(vtn_src[0]->type) ||
(num_inputs >= 2 && glsl_type_is_matrix(vtn_src[1]->type))) {
   vtn_handle_matrix_alu(b, opcode, val, vtn_src[0], vtn_src[1]);
-  b->nb.exact = false;
+  b->nb.exact = b->exact;
   return;
}
 
@@ -661,5 +661,5 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
} /* default */
}
 
-   b->nb.exact = false;
+   b->nb.exact = b->exact;
 }
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 5b3cc703f94..bc1a949fdee 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -281,6 +281,7 @@ vtn_cfg_handle_prepass_instruction(struct vtn_builder *b, 
SpvOp opcode,
   b->func->impl = nir_function_impl_create(func);
   nir_builder_init(>nb, func->impl);
   b->nb.cursor = nir_before_cf_list(>func->impl->body);
+  b->nb.exact = b->exact;
 
   b->func_param_idx = 0;
 
@@ -1040,6 +1041,7 @@ vtn_function_emit(struct vtn_builder *b, struct 
vtn_function *func,
nir_builder_init(>nb, func->impl);
b->func = func;
b->nb.cursor = nir_after_cf_list(>impl->body);
+   b->nb.exact = b->exact;
b->has_loop_continue = false;
b->phi_table = _mesa_hash_table_create(b, _mesa_hash_pointer,
   _mesa_key_pointer_equal);
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index e380d8e82ff..930beec30ef 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -607,6 +607,9 @@ struct vtn_builder {
 
bool has_loop_continue;
 
+   /* false by default, set to true by the ContractionOff execution mode */
+   bool exact;
+
/* when a physical memory model is choosen */
bool physical_ptrs;
 };
-- 
2.19.2

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


[Mesa-dev] [PATCH 01/12] mesa: add MESA_SHADER_KERNEL

2018-12-04 Thread Karol Herbst
used for CL kernels

Signed-off-by: Karol Herbst 
---
 src/amd/common/ac_nir_to_llvm.c|  4 ++--
 src/compiler/nir/nir.c |  2 +-
 src/compiler/nir/nir_print.c   |  7 ++-
 src/compiler/shader_enums.c|  5 -
 src/compiler/shader_enums.h| 18 ++
 src/compiler/spirv/spirv_to_nir.c  |  2 +-
 src/freedreno/ir3/ir3_compiler_nir.c   |  3 ++-
 src/gallium/drivers/freedreno/a6xx/fd6_emit.c  |  1 +
 src/gallium/drivers/freedreno/a6xx/fd6_emit.h  |  1 +
 .../drivers/freedreno/a6xx/fd6_program.c   |  1 +
 src/gallium/drivers/freedreno/freedreno_util.h |  1 +
 .../drivers/freedreno/ir3/ir3_cmdline.c|  1 +
 .../drivers/freedreno/ir3/ir3_gallium.c|  2 +-
 src/gallium/drivers/radeonsi/si_shader_nir.c   |  4 ++--
 src/mesa/main/shaderobj.h  |  6 ++
 15 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index a109f5a8156..18e9b69f3c0 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4012,13 +4012,13 @@ void ac_nir_translate(struct ac_llvm_context *ac, 
struct ac_shader_abi *abi,
 
setup_locals(, func);
 
-   if (nir->info.stage == MESA_SHADER_COMPUTE)
+   if (gl_shader_stage_is_compute(nir->info.stage))
setup_shared(, nir);
 
visit_cf_list(, >impl->body);
phi_post_pass();
 
-   if (nir->info.stage != MESA_SHADER_COMPUTE)
+   if (!gl_shader_stage_is_compute(nir->info.stage))
ctx.abi->emit_outputs(ctx.abi, AC_LLVM_MAX_OUTPUTS,
  ctx.abi->outputs);
 
diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 249b9357c3f..03199856cc2 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -147,7 +147,7 @@ nir_shader_add_variable(nir_shader *shader, nir_variable 
*var)
   break;
 
case nir_var_shared:
-  assert(shader->info.stage == MESA_SHADER_COMPUTE);
+  assert(gl_shader_stage_is_compute(shader->info.stage));
   exec_list_push_tail(>shared, >node);
   break;
 
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index 7124ff09e82..b8549f56eb8 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -472,6 +472,7 @@ print_var_decl(nir_variable *var, print_state *state)
   case MESA_SHADER_TESS_CTRL:
   case MESA_SHADER_TESS_EVAL:
   case MESA_SHADER_COMPUTE:
+  case MESA_SHADER_KERNEL:
   default:
  /* TODO */
  break;
@@ -1255,17 +1256,13 @@ nir_print_shader_annotated(nir_shader *shader, FILE *fp,
if (shader->info.label)
   fprintf(fp, "label: %s\n", shader->info.label);
 
-   switch (shader->info.stage) {
-   case MESA_SHADER_COMPUTE:
+   if (gl_shader_stage_is_compute(shader->info.stage)) {
   fprintf(fp, "local-size: %u, %u, %u%s\n",
   shader->info.cs.local_size[0],
   shader->info.cs.local_size[1],
   shader->info.cs.local_size[2],
   shader->info.cs.local_size_variable ? " (variable)" : "");
   fprintf(fp, "shared-size: %u\n", shader->info.cs.shared_size);
-  break;
-   default:
-  break;
}
 
fprintf(fp, "inputs: %u\n", shader->num_inputs);
diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index 0210b503d3f..15ab6d81dae 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -43,8 +43,9 @@ gl_shader_stage_name(gl_shader_stage stage)
   ENUM(MESA_SHADER_GEOMETRY),
   ENUM(MESA_SHADER_FRAGMENT),
   ENUM(MESA_SHADER_COMPUTE),
+  ENUM(MESA_SHADER_KERNEL),
};
-   STATIC_ASSERT(ARRAY_SIZE(names) == MESA_SHADER_STAGES);
+   STATIC_ASSERT(ARRAY_SIZE(names) == MESA_ALL_SHADER_STAGES);
return NAME(stage);
 }
 
@@ -60,6 +61,7 @@ _mesa_shader_stage_to_string(unsigned stage)
case MESA_SHADER_FRAGMENT: return "fragment";
case MESA_SHADER_GEOMETRY: return "geometry";
case MESA_SHADER_COMPUTE:  return "compute";
+   case MESA_SHADER_KERNEL:   return "kernel";
case MESA_SHADER_TESS_CTRL: return "tessellation control";
case MESA_SHADER_TESS_EVAL: return "tessellation evaluation";
}
@@ -79,6 +81,7 @@ _mesa_shader_stage_to_abbrev(unsigned stage)
case MESA_SHADER_FRAGMENT: return "FS";
case MESA_SHADER_GEOMETRY: return "GS";
case MESA_SHADER_COMPUTE:  return "CS";
+   case MESA_SHADER_KERNEL:   return "CL";
case MESA_SHADER_TESS_CTRL: return "TCS";
case MESA_SHADER_TESS_EVAL: return "TES";
}
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index f023b48cbb3..1dff01484b5 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -26,6 +26,8 @@
 #ifndef SHADER_ENUMS_H
 #define SHADER_ENUMS_H
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -46,8 +48,16 @@ typedef enum

[Mesa-dev] [PATCH 08/12] nir/validate: allow to check against a bitmask of bit_sizes

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir_validate.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index 7ee13da258d..ef24e96ee3f 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -129,11 +129,11 @@ log_error(validate_state *state, const char *cond, const 
char *file, int line)
} while (0)
 
 static void validate_src(nir_src *src, validate_state *state,
- unsigned bit_size, unsigned num_components);
+ unsigned bit_sizes, unsigned num_components);
 
 static void
 validate_reg_src(nir_src *src, validate_state *state,
- unsigned bit_size, unsigned num_components)
+ unsigned bit_sizes, unsigned num_components)
 {
validate_assert(state, src->reg.reg != NULL);
 
@@ -156,8 +156,8 @@ validate_reg_src(nir_src *src, validate_state *state,
}
 
if (!src->reg.reg->is_packed) {
-  if (bit_size)
- validate_assert(state, src->reg.reg->bit_size == bit_size);
+  if (bit_sizes)
+ validate_assert(state, src->reg.reg->bit_size & bit_sizes);
   if (num_components)
  validate_assert(state, src->reg.reg->num_components == 
num_components);
}
@@ -177,7 +177,7 @@ validate_reg_src(nir_src *src, validate_state *state,
 
 static void
 validate_ssa_src(nir_src *src, validate_state *state,
- unsigned bit_size, unsigned num_components)
+ unsigned bit_sizes, unsigned num_components)
 {
validate_assert(state, src->ssa != NULL);
 
@@ -200,8 +200,8 @@ validate_ssa_src(nir_src *src, validate_state *state,
   _mesa_set_add(def_state->if_uses, src);
}
 
-   if (bit_size)
-  validate_assert(state, src->ssa->bit_size == bit_size);
+   if (bit_sizes)
+  validate_assert(state, src->ssa->bit_size & bit_sizes);
if (num_components)
   validate_assert(state, src->ssa->num_components == num_components);
 
@@ -210,7 +210,7 @@ validate_ssa_src(nir_src *src, validate_state *state,
 
 static void
 validate_src(nir_src *src, validate_state *state,
- unsigned bit_size, unsigned num_components)
+ unsigned bit_sizes, unsigned num_components)
 {
if (state->instr)
   validate_assert(state, src->parent_instr == state->instr);
@@ -218,9 +218,9 @@ validate_src(nir_src *src, validate_state *state,
   validate_assert(state, src->parent_if == state->if_stmt);
 
if (src->is_ssa)
-  validate_ssa_src(src, state, bit_size, num_components);
+  validate_ssa_src(src, state, bit_sizes, num_components);
else
-  validate_reg_src(src, state, bit_size, num_components);
+  validate_reg_src(src, state, bit_sizes, num_components);
 }
 
 static void
@@ -243,7 +243,7 @@ validate_alu_src(nir_alu_instr *instr, unsigned index, 
validate_state *state)
 
 static void
 validate_reg_dest(nir_reg_dest *dest, validate_state *state,
-  unsigned bit_size, unsigned num_components)
+  unsigned bit_sizes, unsigned num_components)
 {
validate_assert(state, dest->reg != NULL);
 
@@ -263,8 +263,8 @@ validate_reg_dest(nir_reg_dest *dest, validate_state *state,
}
 
if (!dest->reg->is_packed) {
-  if (bit_size)
- validate_assert(state, dest->reg->bit_size == bit_size);
+  if (bit_sizes)
+ validate_assert(state, dest->reg->bit_size & bit_sizes);
   if (num_components)
  validate_assert(state, dest->reg->num_components == num_components);
}
@@ -309,16 +309,16 @@ validate_ssa_def(nir_ssa_def *def, validate_state *state)
 
 static void
 validate_dest(nir_dest *dest, validate_state *state,
-  unsigned bit_size, unsigned num_components)
+  unsigned bit_sizes, unsigned num_components)
 {
if (dest->is_ssa) {
-  if (bit_size)
- validate_assert(state, dest->ssa.bit_size == bit_size);
+  if (bit_sizes)
+ validate_assert(state, dest->ssa.bit_size & bit_sizes);
   if (num_components)
  validate_assert(state, dest->ssa.num_components == num_components);
   validate_ssa_def(>ssa, state);
} else {
-  validate_reg_dest(>reg, state, bit_size, num_components);
+  validate_reg_dest(>reg, state, bit_sizes, num_components);
}
 }
 
-- 
2.19.2

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


[Mesa-dev] [PATCH 04/12] nir/spirv: improve parsing of the memory model

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir.h|  8 
 src/compiler/nir/nir_clone.c  |  1 +
 src/compiler/nir/nir_serialize.c  |  2 ++
 src/compiler/spirv/spirv_to_nir.c | 26 ++
 src/compiler/spirv/vtn_private.h  |  3 +++
 5 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index db935c8496b..a111e87ed71 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2249,6 +2249,14 @@ typedef struct nir_shader {
 */
void *constant_data;
unsigned constant_data_size;
+
+   /**
+* pointer size is:
+*   AddressingModelLogical:0(default)
+*   AddressingModelPhysical32: 32
+*   AddressingModelPhysical64: 64
+*/
+   unsigned ptr_size;
 } nir_shader;
 
 static inline nir_function_impl *
diff --git a/src/compiler/nir/nir_clone.c b/src/compiler/nir/nir_clone.c
index 989c5051a54..d47d3e8cb72 100644
--- a/src/compiler/nir/nir_clone.c
+++ b/src/compiler/nir/nir_clone.c
@@ -733,6 +733,7 @@ nir_shader_clone(void *mem_ctx, const nir_shader *s)
ns->num_uniforms = s->num_uniforms;
ns->num_outputs = s->num_outputs;
ns->num_shared = s->num_shared;
+   ns->ptr_size = s->ptr_size;
 
ns->constant_data_size = s->constant_data_size;
if (s->constant_data_size > 0) {
diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 43016310048..5ec6972b02a 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -1106,6 +1106,7 @@ nir_serialize(struct blob *blob, const nir_shader *nir)
blob_write_uint32(blob, nir->num_uniforms);
blob_write_uint32(blob, nir->num_outputs);
blob_write_uint32(blob, nir->num_shared);
+   blob_write_uint32(blob, nir->ptr_size);
 
blob_write_uint32(blob, exec_list_length(>functions));
nir_foreach_function(fxn, nir) {
@@ -1165,6 +1166,7 @@ nir_deserialize(void *mem_ctx,
ctx.nir->num_uniforms = blob_read_uint32(blob);
ctx.nir->num_outputs = blob_read_uint32(blob);
ctx.nir->num_shared = blob_read_uint32(blob);
+   ctx.nir->ptr_size = blob_read_uint32(blob);
 
unsigned num_functions = blob_read_uint32(blob);
for (unsigned i = 0; i < num_functions; i++)
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index e41a7e960ce..1a7d5b3a9bd 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3581,9 +3581,27 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
   break;
 
case SpvOpMemoryModel:
-  vtn_assert(w[1] == SpvAddressingModelLogical);
+  switch (w[1]) {
+  case SpvAddressingModelPhysical32:
+ b->shader->ptr_size = 32;
+ b->physical_ptrs = true;
+ break;
+  case SpvAddressingModelPhysical64:
+ b->shader->ptr_size = 64;
+ b->physical_ptrs = true;
+ break;
+  case SpvAddressingModelLogical:
+ b->shader->ptr_size = 0;
+ b->physical_ptrs = false;
+ break;
+  default:
+ vtn_fail("Unknown addressing model");
+ break;
+  }
+
   vtn_assert(w[2] == SpvMemoryModelSimple ||
- w[2] == SpvMemoryModelGLSL450);
+ w[2] == SpvMemoryModelGLSL450 ||
+ w[2] == SpvMemoryModelOpenCL);
   break;
 
case SpvOpEntryPoint:
@@ -4258,6 +4276,8 @@ spirv_to_nir(const uint32_t *words, size_t word_count,
/* Skip the SPIR-V header, handled at vtn_create_builder */
words+= 5;
 
+   b->shader = nir_shader_create(b, stage, nir_options, NULL);
+
/* Handle all the preamble instructions */
words = vtn_foreach_instruction(b, words, word_end,
vtn_handle_preamble_instruction);
@@ -4268,8 +4288,6 @@ spirv_to_nir(const uint32_t *words, size_t word_count,
   return NULL;
}
 
-   b->shader = nir_shader_create(b, stage, nir_options, NULL);
-
/* Set shader info defaults */
b->shader->info.gs.invocations = 1;
 
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index da7a04ce59f..47f26dac642 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -605,6 +605,9 @@ struct vtn_builder {
unsigned func_param_idx;
 
bool has_loop_continue;
+
+   /* when a physical memory model is choosen */
+   bool physical_ptrs;
 };
 
 nir_ssa_def *
-- 
2.19.2

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


[Mesa-dev] [PATCH 11/12] nir: add support for address bit sized system values

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/amd/vulkan/radv_meta_buffer.c  |  8 ++--
 src/amd/vulkan/radv_meta_bufimage.c| 28 +++---
 src/amd/vulkan/radv_meta_clear.c   |  4 +-
 src/amd/vulkan/radv_meta_fast_clear.c  |  4 +-
 src/amd/vulkan/radv_meta_resolve_cs.c  |  4 +-
 src/amd/vulkan/radv_query.c| 12 +++---
 src/compiler/nir/nir_intrinsics.py | 12 +++---
 src/compiler/nir/nir_lower_system_values.c | 43 +-
 8 files changed, 61 insertions(+), 54 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_buffer.c 
b/src/amd/vulkan/radv_meta_buffer.c
index 76854d7bbad..208988c3775 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -15,8 +15,8 @@ build_buffer_fill_shader(struct radv_device *dev)
b.shader->info.cs.local_size[1] = 1;
b.shader->info.cs.local_size[2] = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -67,8 +67,8 @@ build_buffer_copy_shader(struct radv_device *dev)
b.shader->info.cs.local_size[1] = 1;
b.shader->info.cs.local_size[2] = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
diff --git a/src/amd/vulkan/radv_meta_bufimage.c 
b/src/amd/vulkan/radv_meta_bufimage.c
index 45df8438234..c8a733b3062 100644
--- a/src/amd/vulkan/radv_meta_bufimage.c
+++ b/src/amd/vulkan/radv_meta_bufimage.c
@@ -60,8 +60,8 @@ build_nir_itob_compute_shader(struct radv_device *dev, bool 
is_3d)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -289,8 +289,8 @@ build_nir_btoi_compute_shader(struct radv_device *dev, bool 
is_3d)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -511,8 +511,8 @@ build_nir_btoi_r32g32b32_compute_shader(struct radv_device 
*dev)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -719,8 +719,8 @@ build_nir_itoi_compute_shader(struct radv_device *dev, bool 
is_3d)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = nir_load_work_group_id();
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id(, 32);
+   nir_ssa_def *wg_id = nir_load_work_group_id(, 32);
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -932,8 +932,8 @@ build_nir_itoi_r32g32b32_compute_shader(struct radv_device 
*dev)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
-   nir_ssa_def *wg_id = 

[Mesa-dev] [PATCH 07/12] nir: replace more nir_load_system_value calls with builder functions

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/amd/vulkan/radv_meta_bufimage.c | 12 ++--
 src/amd/vulkan/radv_meta_clear.c|  4 ++--
 src/amd/vulkan/radv_query.c |  4 ++--
 src/gallium/auxiliary/nir/tgsi_to_nir.c |  3 +--
 src/intel/compiler/brw_nir.c|  3 +--
 5 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_bufimage.c 
b/src/amd/vulkan/radv_meta_bufimage.c
index e0dc7151556..45df8438234 100644
--- a/src/amd/vulkan/radv_meta_bufimage.c
+++ b/src/amd/vulkan/radv_meta_bufimage.c
@@ -511,8 +511,8 @@ build_nir_btoi_r32g32b32_compute_shader(struct radv_device 
*dev)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_system_value(, 
nir_intrinsic_load_local_invocation_id, 0);
-   nir_ssa_def *wg_id = nir_load_system_value(, 
nir_intrinsic_load_work_group_id, 0);
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
+   nir_ssa_def *wg_id = nir_load_work_group_id();
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -932,8 +932,8 @@ build_nir_itoi_r32g32b32_compute_shader(struct radv_device 
*dev)
output_img->data.descriptor_set = 0;
output_img->data.binding = 1;
 
-   nir_ssa_def *invoc_id = nir_load_system_value(, 
nir_intrinsic_load_local_invocation_id, 0);
-   nir_ssa_def *wg_id = nir_load_system_value(, 
nir_intrinsic_load_work_group_id, 0);
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
+   nir_ssa_def *wg_id = nir_load_work_group_id();
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
@@ -1331,8 +1331,8 @@ build_nir_cleari_r32g32b32_compute_shader(struct 
radv_device *dev)
output_img->data.descriptor_set = 0;
output_img->data.binding = 0;
 
-   nir_ssa_def *invoc_id = nir_load_system_value(, 
nir_intrinsic_load_local_invocation_id, 0);
-   nir_ssa_def *wg_id = nir_load_system_value(, 
nir_intrinsic_load_work_group_id, 0);
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
+   nir_ssa_def *wg_id = nir_load_work_group_id();
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 83d4b071d52..5805d39c4b3 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1025,8 +1025,8 @@ build_clear_htile_mask_shader()
b.shader->info.cs.local_size[1] = 1;
b.shader->info.cs.local_size[2] = 1;
 
-   nir_ssa_def *invoc_id = nir_load_system_value(, 
nir_intrinsic_load_local_invocation_id, 0);
-   nir_ssa_def *wg_id = nir_load_system_value(, 
nir_intrinsic_load_work_group_id, 0);
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
+   nir_ssa_def *wg_id = nir_load_work_group_id();
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 550abe307a1..d3baf2357ff 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -590,8 +590,8 @@ build_tfb_query_shader(struct radv_device *device)
nir_builder_instr_insert(, _buf->instr);
 
/* Compute global ID. */
-   nir_ssa_def *invoc_id = nir_load_system_value(, 
nir_intrinsic_load_local_invocation_id, 0);
-   nir_ssa_def *wg_id = nir_load_system_value(, 
nir_intrinsic_load_work_group_id, 0);
+   nir_ssa_def *invoc_id = nir_load_local_invocation_id();
+   nir_ssa_def *wg_id = nir_load_work_group_id();
nir_ssa_def *block_size = nir_imm_ivec4(,
b.shader->info.cs.local_size[0],
b.shader->info.cs.local_size[1],
diff --git a/src/gallium/auxiliary/nir/tgsi_to_nir.c 
b/src/gallium/auxiliary/nir/tgsi_to_nir.c
index f0bcce0feb3..e28582880b5 100644
--- a/src/gallium/auxiliary/nir/tgsi_to_nir.c
+++ b/src/gallium/auxiliary/nir/tgsi_to_nir.c
@@ -516,8 +516,7 @@ ttn_src_for_file_and_index(struct ttn_compile *c, unsigned 
file, unsigned index,
   c->scan->input_semantic_name[index] == TGSI_SEMANTIC_FACE) {
  nir_ssa_def *tgsi_frontface[4] = {
 nir_bcsel(>build,
-  nir_load_system_value(>build,
-nir_intrinsic_load_front_face, 0),
+

[Mesa-dev] [PATCH 03/12] nir/vtn: add caps for some cl related capabilities

2018-12-04 Thread Karol Herbst
From: Rob Clark 

vtn supports these, so don't squalk if user is happy with enabling
these.

Signed-off-by: Karol Herbst 
---
 src/compiler/shader_info.h |  3 +++
 src/compiler/spirv/spirv_to_nir.c  | 17 ++---
 src/compiler/spirv/vtn_variables.c |  6 --
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 65bc0588d67..5286cf8fc5f 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -62,6 +62,9 @@ struct spirv_supported_capabilities {
bool post_depth_coverage;
bool transform_feedback;
bool geometry_streams;
+   bool address;
+   bool kernel;
+   bool int8;
 };
 
 typedef struct shader_info {
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 2c2dbe12a3c..e41a7e960ce 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -783,8 +783,10 @@ struct_member_decoration_cb(struct vtn_builder *b,
case SpvDecorationFPRoundingMode:
case SpvDecorationFPFastMathMode:
case SpvDecorationAlignment:
-  vtn_warn("Decoration only allowed for CL-style kernels: %s",
-   spirv_decoration_to_string(dec->decoration));
+  if (b->shader->info.stage != MESA_SHADER_KERNEL) {
+ vtn_warn("Decoration only allowed for CL-style kernels: %s",
+  spirv_decoration_to_string(dec->decoration));
+  }
   break;
 
case SpvDecorationHlslSemanticGOOGLE:
@@ -3420,7 +3422,6 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
   case SpvCapabilityFloat16:
   case SpvCapabilityInt64Atomics:
   case SpvCapabilityStorageImageMultisample:
-  case SpvCapabilityInt8:
   case SpvCapabilitySparseResidency:
   case SpvCapabilityMinLod:
  vtn_warn("Unsupported SPIR-V capability: %s",
@@ -3449,8 +3450,18 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(geometry_streams, cap);
  break;
 
+  case SpvCapabilityInt8:
+ spv_check_supported(int8, cap);
+ break;
+
   case SpvCapabilityAddresses:
+ spv_check_supported(address, cap);
+ break;
+
   case SpvCapabilityKernel:
+ spv_check_supported(kernel, cap);
+ break;
+
   case SpvCapabilityImageBasic:
   case SpvCapabilityImageReadWrite:
   case SpvCapabilityImageMipmap:
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 55721fc36e3..fe44e71800d 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1381,8 +1381,10 @@ apply_var_decoration(struct vtn_builder *b,
case SpvDecorationFPRoundingMode:
case SpvDecorationFPFastMathMode:
case SpvDecorationAlignment:
-  vtn_warn("Decoration only allowed for CL-style kernels: %s",
-   spirv_decoration_to_string(dec->decoration));
+  if (b->shader->info.stage != MESA_SHADER_KERNEL) {
+ vtn_warn("Decoration only allowed for CL-style kernels: %s",
+  spirv_decoration_to_string(dec->decoration));
+  }
   break;
 
case SpvDecorationHlslSemanticGOOGLE:
-- 
2.19.2

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


[Mesa-dev] [PATCH 06/12] nir/spirv: handle SpvStorageClassCrossWorkgroup

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir.c | 4 
 src/compiler/nir/nir.h | 1 +
 src/compiler/nir/nir_print.c   | 2 ++
 src/compiler/spirv/vtn_private.h   | 1 +
 src/compiler/spirv/vtn_variables.c | 4 
 5 files changed, 12 insertions(+)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 45c4a3e8375..7f16200015f 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -129,6 +129,10 @@ nir_shader_add_variable(nir_shader *shader, nir_variable 
*var)
   assert(!"nir_shader_add_variable cannot be used for local variables");
   break;
 
+   case nir_var_global:
+  assert(!"nir_shader_add_variable cannot be used for global memory");
+  break;
+
case nir_var_private:
   exec_list_push_tail(>globals, >node);
   break;
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 30d22fb9d7d..e9f8f15d387 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -103,6 +103,7 @@ typedef enum {
nir_var_shader_storage  = (1 << 5),
nir_var_system_value= (1 << 6),
nir_var_shared  = (1 << 8),
+   nir_var_global  = (1 << 9),
nir_var_all = ~0,
 } nir_variable_mode;
 
diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
index 1d409b1da7b..f509c92e0cd 100644
--- a/src/compiler/nir/nir_print.c
+++ b/src/compiler/nir/nir_print.c
@@ -413,6 +413,8 @@ get_variable_mode_str(nir_variable_mode mode, bool 
want_local_global_mode)
   return want_local_global_mode ? "private" : "";
case nir_var_function:
   return want_local_global_mode ? "function" : "";
+   case nir_var_global:
+  return want_local_global_mode ? "global" : "";
default:
   return "";
}
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index b84ac2cf0b4..e380d8e82ff 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -417,6 +417,7 @@ enum vtn_variable_mode {
vtn_variable_mode_ssbo,
vtn_variable_mode_push_constant,
vtn_variable_mode_workgroup,
+   vtn_variable_mode_cross_workgroup,
vtn_variable_mode_input,
vtn_variable_mode_output,
 };
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index b911b114b70..5bf407eb8a7 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1582,6 +1582,9 @@ vtn_storage_class_to_mode(struct vtn_builder *b,
   nir_mode = nir_var_uniform;
   break;
case SpvStorageClassCrossWorkgroup:
+  mode = vtn_variable_mode_cross_workgroup;
+  nir_mode = nir_var_global;
+  break;
case SpvStorageClassGeneric:
default:
   vtn_fail("Unhandled variable storage class");
@@ -1841,6 +1844,7 @@ vtn_create_variable(struct vtn_builder *b, struct 
vtn_value *val,
case vtn_variable_mode_ubo:
case vtn_variable_mode_ssbo:
case vtn_variable_mode_push_constant:
+   case vtn_variable_mode_cross_workgroup:
   /* These don't need actual variables. */
   break;
}
-- 
2.19.2

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


[Mesa-dev] [PATCH 05/12] nir: rename global/local to private/function memory

2018-12-04 Thread Karol Herbst
the naming is a bit confusing no matter how you look at it. Within SPIR-V
"global" memory is memory accessible from all threads. glsl "global" memory
normally refers to shader thread private memory declared at global scope. As
we already use "shared" for memory shared across all thrads of a work group
the solution where everybody could be happy with is to rename "global" to
"private" and use "global" later for memory usually stored within system
accessible memory (be it VRAM or system RAM if keeping SVM in mind).
glsl "local" memory is memory only accessible within a function, while SPIR-V
"local" memory is memory accessible within the same workgroup.

v2: rename local to function as well

Signed-off-by: Karol Herbst 
---
 src/amd/common/ac_nir_to_llvm.c   |  6 ++--
 src/amd/vulkan/radv_shader.c  |  8 ++---
 src/compiler/glsl/glsl_to_nir.cpp | 10 +++
 src/compiler/nir/nir.c|  6 ++--
 src/compiler/nir/nir.h|  8 ++---
 src/compiler/nir/nir_linking_helpers.c|  2 +-
 src/compiler/nir/nir_lower_clip.c |  2 +-
 .../nir/nir_lower_constant_initializers.c |  6 ++--
 .../nir/nir_lower_global_vars_to_local.c  |  6 ++--
 .../nir/nir_lower_io_to_temporaries.c |  2 +-
 src/compiler/nir/nir_lower_locals_to_regs.c   |  4 +--
 src/compiler/nir/nir_lower_vars_to_ssa.c  |  8 ++---
 src/compiler/nir/nir_opt_copy_prop_vars.c |  8 ++---
 src/compiler/nir/nir_opt_dead_write_vars.c|  4 +--
 src/compiler/nir/nir_opt_find_array_copies.c  |  4 +--
 src/compiler/nir/nir_opt_large_constants.c| 14 -
 src/compiler/nir/nir_print.c  |  8 ++---
 src/compiler/nir/nir_remove_dead_variables.c  |  6 ++--
 src/compiler/nir/nir_split_vars.c | 30 +--
 src/compiler/nir/nir_validate.c   |  2 +-
 src/compiler/nir/tests/vars_tests.cpp | 18 +--
 src/compiler/spirv/vtn_cfg.c  |  2 +-
 src/compiler/spirv/vtn_private.h  |  2 +-
 src/compiler/spirv/vtn_variables.c|  8 ++---
 src/freedreno/ir3/ir3_nir.c   |  2 +-
 src/gallium/auxiliary/nir/tgsi_to_nir.c   |  2 +-
 src/gallium/drivers/v3d/v3d_program.c |  2 +-
 src/gallium/drivers/vc4/vc4_program.c |  4 +--
 src/intel/compiler/brw_nir.c  | 10 +++
 src/intel/vulkan/anv_pipeline.c   |  4 +--
 src/mesa/main/glspirv.c   |  2 +-
 src/mesa/state_tracker/st_glsl_to_nir.cpp |  4 +--
 32 files changed, 102 insertions(+), 102 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 18e9b69f3c0..2d8a27a0ab9 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1923,7 +1923,7 @@ static LLVMValueRef visit_load_var(struct ac_nir_context 
*ctx,
values[chan] = ctx->abi->inputs[idx + chan + 
const_index * stride];
}
break;
-   case nir_var_local:
+   case nir_var_function:
for (unsigned chan = 0; chan < ve; chan++) {
if (indir_index) {
unsigned count = glsl_count_attribute_slots(
@@ -2055,7 +2055,7 @@ visit_store_var(struct ac_nir_context *ctx,
}
}
break;
-   case nir_var_local:
+   case nir_var_function:
for (unsigned chan = 0; chan < 8; chan++) {
if (!(writemask & (1 << chan)))
continue;
@@ -4061,7 +4061,7 @@ ac_lower_indirect_derefs(struct nir_shader *nir, enum 
chip_class chip_class)
 * See the following thread for more details of the problem:
 * https://lists.freedesktop.org/archives/mesa-dev/2017-July/162106.html
 */
-   indirect_mask |= nir_var_local;
+   indirect_mask |= nir_var_function;
 
nir_lower_indirect_derefs(nir, indirect_mask);
 }
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 456c462a230..fa15478ad2d 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -126,8 +126,8 @@ radv_optimize_nir(struct nir_shader *shader, bool 
optimize_conservatively,
 do {
 progress = false;
 
-   NIR_PASS(progress, shader, nir_split_array_vars, nir_var_local);
-   NIR_PASS(progress, shader, nir_shrink_vec_array_vars, 
nir_var_local);
+   NIR_PASS(progress, shader, nir_split_array_vars, 
nir_var_function);
+   NIR_PASS(progress, shader, nir_shrink_vec_array_vars, 
nir_var_function);
 
 NIR_PASS_V(shader, nir_lower_vars_to_ssa);
NIR_PASS_V(shader, nir_lower_pack);
@@ -261,7 +261,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
 * inline functions.  That way they get properly initialized at 
the top
 

[Mesa-dev] [PATCH 10/12] nir: add bit_size parameter to system values with multiple allowed bit sizes

2018-12-04 Thread Karol Herbst
Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir_builder_opcodes_h.py | 14 --
 src/compiler/nir/nir_lower_system_values.c|  4 ++--
 src/gallium/drivers/vc4/vc4_nir_lower_blend.c |  4 ++--
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/src/compiler/nir/nir_builder_opcodes_h.py 
b/src/compiler/nir/nir_builder_opcodes_h.py
index 34b8c4371e1..f2e33071c6d 100644
--- a/src/compiler/nir/nir_builder_opcodes_h.py
+++ b/src/compiler/nir/nir_builder_opcodes_h.py
@@ -44,13 +44,14 @@ nir_${name}(nir_builder *build, 
${src_decl_list(opcode.num_inputs)})
 
 /* Generic builder for system values. */
 static inline nir_ssa_def *
-nir_load_system_value(nir_builder *build, nir_intrinsic_op op, int index)
+nir_load_system_value(nir_builder *build, nir_intrinsic_op op, int index,
+  unsigned bit_size)
 {
nir_intrinsic_instr *load = nir_intrinsic_instr_create(build->shader, op);
load->num_components = nir_intrinsic_infos[op].dest_components;
load->const_index[0] = index;
nir_ssa_dest_init(>instr, >dest,
- nir_intrinsic_infos[op].dest_components, 32, NULL);
+ nir_intrinsic_infos[op].dest_components, bit_size, NULL);
nir_builder_instr_insert(build, >instr);
return >dest.ssa;
 }
@@ -60,6 +61,8 @@ def sysval_decl_list(opcode):
res = ''
if opcode.indices:
   res += ', unsigned ' + opcode.indices[0].lower()
+   if len(opcode.bit_sizes) > 1:
+  res += ', unsigned bit_size'
return res
 
 def sysval_arg_list(opcode):
@@ -68,6 +71,13 @@ def sysval_arg_list(opcode):
   args.append(opcode.indices[0].lower())
else:
   args.append('0')
+
+   if len(opcode.bit_sizes) == 1:
+  bit_size = opcode.bit_sizes[0]
+  args.append(str(bit_size))
+   else:
+  args.append('bit_size')
+
return ', '.join(args)
 %>
 
diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 08a9e8be44a..68b0ea89c8d 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -261,8 +261,8 @@ convert_block(nir_block *block, nir_builder *b)
   if (sysval == NULL) {
  nir_intrinsic_op sysval_op =
 nir_intrinsic_from_system_value(var->data.location);
- sysval = nir_load_system_value(b, sysval_op, 0);
- sysval->bit_size = load_deref->dest.ssa.bit_size;
+ sysval = nir_load_system_value(b, sysval_op, 0,
+load_deref->dest.ssa.bit_size);
   }
 
   nir_ssa_def_rewrite_uses(_deref->dest.ssa, nir_src_for_ssa(sysval));
diff --git a/src/gallium/drivers/vc4/vc4_nir_lower_blend.c 
b/src/gallium/drivers/vc4/vc4_nir_lower_blend.c
index 60eccb4fc00..f80558722a1 100644
--- a/src/gallium/drivers/vc4/vc4_nir_lower_blend.c
+++ b/src/gallium/drivers/vc4/vc4_nir_lower_blend.c
@@ -130,7 +130,7 @@ vc4_blend_channel_f(nir_builder *b,
 return nir_load_system_value(b,
  
nir_intrinsic_load_blend_const_color_r_float +
  channel,
- 0);
+ 0, 32);
 case PIPE_BLENDFACTOR_CONST_ALPHA:
 return nir_load_blend_const_color_a_float(b);
 case PIPE_BLENDFACTOR_ZERO:
@@ -148,7 +148,7 @@ vc4_blend_channel_f(nir_builder *b,
 nir_load_system_value(b,
   
nir_intrinsic_load_blend_const_color_r_float +
   channel,
-  0));
+  0, 32));
 case PIPE_BLENDFACTOR_INV_CONST_ALPHA:
 return nir_fsub(b, nir_imm_float(b, 1.0),
 nir_load_blend_const_color_a_float(b));
-- 
2.19.2

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


[Mesa-dev] [PATCH 09/12] nir: add legal bit_sizes to intrinsics

2018-12-04 Thread Karol Herbst
With OpenCL some system values match the address bits, but in GLSL we also
have some system values being 64 bit like subgroup masks.

With this it is possible to adjust the builder functions so that depending
on the bit_sizes the correct bit_size is used or an additional argument is
added in case of multiple possible values.

v2: validate dest bit_size

Signed-off-by: Karol Herbst 
---
 src/compiler/nir/nir.h   |  3 +++
 src/compiler/nir/nir_intrinsics.py   | 25 +++--
 src/compiler/nir/nir_intrinsics_c.py |  6 +-
 src/compiler/nir/nir_validate.c  |  6 ++
 4 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index e9f8f15d387..c5ea8dcdd1e 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1297,6 +1297,9 @@ typedef struct {
 
/** semantic flags for calls to this intrinsic */
nir_intrinsic_semantic_flag flags;
+
+   /** bitfield of legal bit sizes */
+   unsigned bit_sizes : 7;
 } nir_intrinsic_info;
 
 extern const nir_intrinsic_info nir_intrinsic_infos[nir_num_intrinsics];
diff --git a/src/compiler/nir/nir_intrinsics.py 
b/src/compiler/nir/nir_intrinsics.py
index 6ea6ad1198f..830c406b450 100644
--- a/src/compiler/nir/nir_intrinsics.py
+++ b/src/compiler/nir/nir_intrinsics.py
@@ -32,7 +32,7 @@ class Intrinsic(object):
NOTE: this must be kept in sync with nir_intrinsic_info.
"""
def __init__(self, name, src_components, dest_components,
-indices, flags, sysval):
+indices, flags, sysval, bit_sizes):
"""Parameters:
 
- name: the intrinsic name
@@ -45,6 +45,7 @@ class Intrinsic(object):
- indices: list of constant indicies
- flags: list of semantic flags
- sysval: is this a system-value intrinsic
+   - bit_sizes: allowed dest bit_sizes
"""
assert isinstance(name, str)
assert isinstance(src_components, list)
@@ -58,6 +59,8 @@ class Intrinsic(object):
if flags:
assert isinstance(flags[0], str)
assert isinstance(sysval, bool)
+   if bit_sizes:
+   assert isinstance(bit_sizes[0], int)
 
self.name = name
self.num_srcs = len(src_components)
@@ -68,6 +71,7 @@ class Intrinsic(object):
self.indices = indices
self.flags = flags
self.sysval = sysval
+   self.bit_sizes = bit_sizes
 
 #
 # Possible indices:
@@ -123,10 +127,10 @@ CAN_REORDER   = "NIR_INTRINSIC_CAN_REORDER"
 INTR_OPCODES = {}
 
 def intrinsic(name, src_comp=[], dest_comp=-1, indices=[],
-  flags=[], sysval=False):
+  flags=[], sysval=False, bit_sizes=[]):
 assert name not in INTR_OPCODES
 INTR_OPCODES[name] = Intrinsic(name, src_comp, dest_comp,
-   indices, flags, sysval)
+   indices, flags, sysval, bit_sizes)
 
 intrinsic("nop", flags=[CAN_ELIMINATE])
 
@@ -448,9 +452,10 @@ intrinsic("shared_atomic_fmin",  src_comp=[1, 1], 
dest_comp=1, indices=[BASE])
 intrinsic("shared_atomic_fmax",  src_comp=[1, 1], dest_comp=1, indices=[BASE])
 intrinsic("shared_atomic_fcomp_swap", src_comp=[1, 1, 1], dest_comp=1, 
indices=[BASE])
 
-def system_value(name, dest_comp, indices=[]):
+def system_value(name, dest_comp, indices=[], bit_sizes=[32]):
 intrinsic("load_" + name, [], dest_comp, indices,
-  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True)
+  flags=[CAN_ELIMINATE, CAN_REORDER], sysval=True,
+  bit_sizes=bit_sizes)
 
 system_value("frag_coord", 4)
 system_value("front_face", 1)
@@ -485,11 +490,11 @@ system_value("layer_id", 1)
 system_value("view_index", 1)
 system_value("subgroup_size", 1)
 system_value("subgroup_invocation", 1)
-system_value("subgroup_eq_mask", 0)
-system_value("subgroup_ge_mask", 0)
-system_value("subgroup_gt_mask", 0)
-system_value("subgroup_le_mask", 0)
-system_value("subgroup_lt_mask", 0)
+system_value("subgroup_eq_mask", 0, bit_sizes=[32, 64])
+system_value("subgroup_ge_mask", 0, bit_sizes=[32, 64])
+system_value("subgroup_gt_mask", 0, bit_sizes=[32, 64])
+system_value("subgroup_le_mask", 0, bit_sizes=[32, 64])
+system_value("subgroup_lt_mask", 0, bit_sizes=[32, 64])
 system_value("num_subgroups", 1)
 system_value("subgroup_id", 1)
 system_value("local_group_size", 3)
diff --git a/src/compiler/nir/nir_intrinsics_c.py 
b/src/compiler/nir/nir_intrinsics_c.py
index ac45b94d496..d0f1c29fa39 100644
--- a/src/compiler/nir/nir_intrinsics_c.py
+++ b/src/compiler/nir/nir_intrinsics_c.py
@@ -1,3 +1,5 @@
+from functools import reduce
+import operator
 
 template = """\
 /* Copyright (C) 2018 Red Hat
@@ -45,6 +47,7 @@ const nir_intrinsic_info 
nir_intrinsic_infos[nir_num_intrinsics] = {
 },
 % endif
.flags = ${"0" if len(opcode.flags) == 0 else " | ".join(opcode.flags)},
+   .bit_sizes = ${reduce(operator.or_, opcode.bit_sizes, 0)},
 },
 % endfor
 };
@@ -54,6 +57,7 @@ from nir_intrinsics import 

[Mesa-dev] [PATCH 00/12] Some cleaned up Compute patches

2018-12-04 Thread Karol Herbst
Extracted some patches from my previous compute series and reworked most of
them quite significantly.

Most notable changes:
* adding a MESA_SHADER_KERNEL to indicate a compute kernel
* split physical ptrs from kernel execution model
  (they don't require each other)
* validate bit_size of system values
* handle ContractionOff for compute kernels

Karol Herbst (11):
  mesa: add MESA_SHADER_KERNEL
  vtn: handle SpvExecutionModelKernel
  nir/spirv: improve parsing of the memory model
  nir: rename global/local to private/function memory
  nir/spirv: handle SpvStorageClassCrossWorkgroup
  nir: replace more nir_load_system_value calls with builder functions
  nir/validate: allow to check against a bitmask of bit_sizes
  nir: add legal bit_sizes to intrinsics
  nir: add bit_size parameter to system values with multiple allowed bit
sizes
  nir: add support for address bit sized system values
  nir/spirv: handle ContractionOff execution mode

Rob Clark (1):
  nir/vtn: add caps for some cl related capabilities

 src/amd/common/ac_nir_to_llvm.c   | 10 ++--
 src/amd/vulkan/radv_meta_buffer.c |  8 +--
 src/amd/vulkan/radv_meta_bufimage.c   | 28 +-
 src/amd/vulkan/radv_meta_clear.c  |  4 +-
 src/amd/vulkan/radv_meta_fast_clear.c |  4 +-
 src/amd/vulkan/radv_meta_resolve_cs.c |  4 +-
 src/amd/vulkan/radv_query.c   | 12 ++--
 src/amd/vulkan/radv_shader.c  |  8 +--
 src/compiler/glsl/glsl_to_nir.cpp | 10 ++--
 src/compiler/nir/nir.c| 10 +++-
 src/compiler/nir/nir.h| 20 +--
 src/compiler/nir/nir_builder_opcodes_h.py | 14 -
 src/compiler/nir/nir_clone.c  |  1 +
 src/compiler/nir/nir_intrinsics.py| 37 ++--
 src/compiler/nir/nir_intrinsics_c.py  |  6 +-
 src/compiler/nir/nir_linking_helpers.c|  2 +-
 src/compiler/nir/nir_lower_clip.c |  2 +-
 .../nir/nir_lower_constant_initializers.c |  6 +-
 .../nir/nir_lower_global_vars_to_local.c  |  6 +-
 .../nir/nir_lower_io_to_temporaries.c |  2 +-
 src/compiler/nir/nir_lower_locals_to_regs.c   |  4 +-
 src/compiler/nir/nir_lower_system_values.c| 47 +---
 src/compiler/nir/nir_lower_vars_to_ssa.c  |  8 +--
 src/compiler/nir/nir_opt_copy_prop_vars.c |  8 +--
 src/compiler/nir/nir_opt_dead_write_vars.c|  4 +-
 src/compiler/nir/nir_opt_find_array_copies.c  |  4 +-
 src/compiler/nir/nir_opt_large_constants.c| 14 ++---
 src/compiler/nir/nir_print.c  | 13 ++---
 src/compiler/nir/nir_remove_dead_variables.c  |  6 +-
 src/compiler/nir/nir_serialize.c  |  2 +
 src/compiler/nir/nir_split_vars.c | 30 +-
 src/compiler/nir/nir_validate.c   | 42 --
 src/compiler/nir/tests/vars_tests.cpp | 18 +++---
 src/compiler/shader_enums.c   |  5 +-
 src/compiler/shader_enums.h   | 18 ++
 src/compiler/shader_info.h|  3 +
 src/compiler/spirv/spirv_info.h   |  1 +
 src/compiler/spirv/spirv_info_c.py|  1 +
 src/compiler/spirv/spirv_to_nir.c | 56 ---
 src/compiler/spirv/vtn_alu.c  |  4 +-
 src/compiler/spirv/vtn_cfg.c  |  4 +-
 src/compiler/spirv/vtn_private.h  |  9 ++-
 src/compiler/spirv/vtn_variables.c| 18 --
 src/freedreno/ir3/ir3_compiler_nir.c  |  3 +-
 src/freedreno/ir3/ir3_nir.c   |  2 +-
 src/gallium/auxiliary/nir/tgsi_to_nir.c   |  5 +-
 src/gallium/drivers/freedreno/a6xx/fd6_emit.c |  1 +
 src/gallium/drivers/freedreno/a6xx/fd6_emit.h |  1 +
 .../drivers/freedreno/a6xx/fd6_program.c  |  1 +
 .../drivers/freedreno/freedreno_util.h|  1 +
 .../drivers/freedreno/ir3/ir3_cmdline.c   |  1 +
 .../drivers/freedreno/ir3/ir3_gallium.c   |  2 +-
 src/gallium/drivers/radeonsi/si_shader_nir.c  |  4 +-
 src/gallium/drivers/v3d/v3d_program.c |  2 +-
 src/gallium/drivers/vc4/vc4_nir_lower_blend.c |  4 +-
 src/gallium/drivers/vc4/vc4_program.c |  4 +-
 src/intel/compiler/brw_nir.c  | 13 ++---
 src/intel/vulkan/anv_pipeline.c   |  4 +-
 src/mesa/main/glspirv.c   |  2 +-
 src/mesa/main/shaderobj.h |  6 ++
 src/mesa/state_tracker/st_glsl_to_nir.cpp |  4 +-
 61 files changed, 356 insertions(+), 217 deletions(-)

-- 
2.19.2

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


[Mesa-dev] [Bug 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #10 from Dylan Baker  ---
I have a similar patch in a series I'm about to send out (the debian guys ran
into the same thing), but we actually need to do
`host_machine.system().startswith('ppc64')` since we still support versions of
meson that return `ppc64le` :/

There's another place where you need the same change.

you might be interested in:
 gitlab.freedesktop.org:dbaker/mesa.git fix-less-common-arches

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #9 from Igor Gnatenko  ---
(In reply to Dylan Baker from comment #7)
> I see some code in autotools we don't have an equivalent of in meson, does
> adding `-Dcpp_std=gnu++11` fix this issue?

It seems that autotools was building clover with gnu++11 while the rest was
built with c++11 which is not the case with meson.

Trying it out.

FYI, patch from earlier comment is not related to fix this bug, but is
correcting altvec detection.

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #8 from Igor Gnatenko  ---
Created attachment 142723
  --> https://bugs.freedesktop.org/attachment.cgi?id=142723=edit
0001-build-correctly-check-for-ppc64le.patch

Some trivial fix for correctly detecting power8.

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #7 from Dylan Baker  ---
I see some code in autotools we don't have an equivalent of in meson, does
adding `-Dcpp_std=gnu++11` fix this issue?

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #6 from Eric Engestrom  ---
(In reply to Igor Gnatenko from comment #3)
> > What OS are you running this on?
> 
> Fedora Rawhide. I'm mesa maintainer in Fedora and trying to switch from
> autotools to meson in our RPM package.
> 
> > and what toolchain?
> 
> GCC, the standard one in Fedora ;)

Oh, good to see you're doing the move! Don't hesitate to cc me and Dylan on any
meson issue you have.

(In reply to Igor Gnatenko from comment #4)
> Interestingly it works fine if I use autotools as a buildsystem.

Good comparison point, I forgot to ask that.

(In reply to Igor Gnatenko from comment #4)
> ../src/gallium/state_trackers/clover/tgsi/compiler.cpp:35:2: error: #error
> "`vector` is #define'd"
>  #error "`vector` is #define'd"
>   ^

So that really is the issue :/

(In reply to Igor Gnatenko from comment #5)
> Might it be related to this meson part:
> 
> if get_option('power8') != 'false'
>   ...
> endif
> 
> ?

Yes indeed, it sounds like a reasonable candidate for this issue.
You can try disabling it with `meson configure -D power8=false`.

I'll try to have a closer look tomorrow so see if `-mpower8-vector` is meant to
work with C++ or not.

-- 
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 v2] build: remove autotools

2018-12-04 Thread Eric Engestrom
On Tuesday, 2018-12-04 09:16:18 -0800, Dylan Baker wrote:
> There are now no known distributions using autotools, meson has all of
> the features that autotools does. We don't need two build systems to do
> exactly the same thing, meson is faster, easier to maintain, and used by
> more devs than autotools. Let's reduce the ongoing burden of maintaining
> autotools.
> 
> This removes the following:
>  - configure.ac
>  - autogen.sh
>  - Makefile.*.am
>  - Makefile.am
>  - Makefile.sources (which are used only by autotools)
>  - travis jobs for autotools
>  - docs for autotools
>  - .gitignore
> 
> v2: - remove stray no-op change in .travis.yml
> ---
[snip]
> diff --git a/.travis.yml b/.travis.yml
> index 6b50d49e143..66be44ffc21 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -74,240 +74,13 @@ matrix:
>  - python3.5
>  - python3-pip
>  - env:
> -- LABEL="make loaders/classic DRI"
> -- BUILD=make
> -- MAKEFLAGS="-j4"
> -- MAKE_CHECK_COMMAND="make check"
> -- DRI_LOADERS="--enable-glx --enable-gbm --enable-egl 
> --with-platforms=x11,drm,surfaceless,wayland --enable-osmesa"
> -- DRI_DRIVERS="i915,i965,radeon,r200,swrast,nouveau"
> -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> -- GALLIUM_DRIVERS=""
> -- VULKAN_DRIVERS=""
> -- LIBUNWIND_FLAGS="--disable-libunwind"
> -  addons:
> -apt:
> -  packages:
> -- xz-utils
> -- x11proto-xf86vidmode-dev
> -- libexpat1-dev
> -- libx11-xcb-dev
> -- libxdamage-dev
> -- libxfixes-dev
> -- python3-pip
> -- env:
> -# NOTE: Building SWR is 2x (yes two) times slower than all the other
> -# gallium drivers combined.
> -# Start this early so that it doesn't hunder the run time.
> -- LABEL="make Gallium Drivers SWR"
> -- BUILD=make
> -- MAKEFLAGS="-j4"
> -- MAKE_CHECK_COMMAND="true"
> -- LLVM_VERSION=6.0
> -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> -- DRI_DRIVERS=""
> -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> -- GALLIUM_DRIVERS="swr"
> -- VULKAN_DRIVERS=""
> -- LIBUNWIND_FLAGS="--enable-libunwind"
> -  addons:
> -apt:
> -  sources:
> -- llvm-toolchain-trusty-6.0
> -# llvm-6 requires libstdc++4.9 which is not in main repo
> -- ubuntu-toolchain-r-test
> -  packages:
> -# From sources above
> -- llvm-6.0-dev
> -# Common
> -- xz-utils
> -- libexpat1-dev
> -- libx11-xcb-dev
> -- libelf-dev
> -- libunwind8-dev
> -- python3-pip
> -- env:
> -- LABEL="make Gallium Drivers RadeonSI"
> -- BUILD=make
> -- MAKEFLAGS="-j4"
> -- MAKE_CHECK_COMMAND="true"
> -- LLVM_VERSION=6.0
> -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> -- DRI_DRIVERS=""
> -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> -- GALLIUM_DRIVERS="radeonsi"
> -- VULKAN_DRIVERS=""
> -- LIBUNWIND_FLAGS="--enable-libunwind"
> -  addons:
> -apt:
> -  sources:
> -- llvm-toolchain-trusty-6.0
> -# llvm-6 requires libstdc++4.9 which is not in main repo
> -- ubuntu-toolchain-r-test
> -  packages:
> -# From sources above
> -- llvm-6.0-dev
> -# Common
> -- xz-utils
> -- libexpat1-dev
> -- libx11-xcb-dev
> -- libelf-dev
> -- libunwind8-dev
> -- python3-pip
> -- env:
> -- LABEL="make Gallium Drivers Other"
> -- BUILD=make
> -- MAKEFLAGS="-j4"
> -- MAKE_CHECK_COMMAND="true"
> -- LLVM_VERSION=3.9
> -- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> -# New binutils linker is required for llvm-3.9
> -- OVERRIDE_PATH=/usr/lib/binutils-2.26/bin
> -- DRI_LOADERS="--disable-glx --disable-gbm --disable-egl"
> -- DRI_DRIVERS=""
> -- GALLIUM_ST="--enable-dri --disable-opencl --disable-xa 
> --disable-nine --disable-xvmc --disable-vdpau --disable-va 
> --disable-omx-bellagio --disable-gallium-osmesa"
> -- 
> 

[Mesa-dev] [Bug 107991] RX580 ~ ring gfx timeout ~ particular shaders created by a dolphin-emu game can crash AMDGPU, with both RadeonSI and RADV ~ attached apitrace for RadeonSI

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107991

keramidasc...@gmail.com changed:

   What|Removed |Added

 CC||keramidasc...@gmail.com

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


Re: [Mesa-dev] [PATCH 17/59] intel/compiler: allow extended math functions with HF operands

2018-12-04 Thread Pohjolainen, Topi
On Tue, Dec 04, 2018 at 08:16:41AM +0100, Iago Toral Quiroga wrote:
> The PRM states that half-float operands are supported since gen9.
> ---
>  src/intel/compiler/brw_eu_emit.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/compiler/brw_eu_emit.c 
> b/src/intel/compiler/brw_eu_emit.c
> index 4630b83b1a0..5f066d17a1f 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -1860,8 +1860,10 @@ void gen6_math(struct brw_codegen *p,
>assert(src1.file == BRW_GENERAL_REGISTER_FILE ||
>   (devinfo->gen >= 8 && src1.file == BRW_IMMEDIATE_VALUE));
> } else {
> -  assert(src0.type == BRW_REGISTER_TYPE_F);
> -  assert(src1.type == BRW_REGISTER_TYPE_F);
> +  assert(src0.type == BRW_REGISTER_TYPE_F ||
> + (src0.type == BRW_REGISTER_TYPE_HF && devinfo->gen >= 9));
> +  assert(src1.type == BRW_REGISTER_TYPE_F ||
> + (src1.type == BRW_REGISTER_TYPE_HF && devinfo->gen >= 9));
> }
>  
> /* Source modifiers are ignored for extended math instructions on Gen6. */
> -- 
> 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 1/2] nir/algebraic: Rewrite bit-size inference

2018-12-04 Thread Dylan Baker
Quoting Connor Abbott (2018-12-04 01:58:28)
> On Mon, Dec 3, 2018 at 11:39 PM Dylan Baker  wrote:
> >
> > Quoting Jason Ekstrand (2018-12-03 14:12:41)
> > > On Mon, Dec 3, 2018 at 3:50 PM Dylan Baker  wrote:
> > >
> > > Quoting Connor Abbott (2018-11-29 10:32:02)
> > > > Before this commit, there were two copies of the algorithm: one in 
> > > C,
> > > > that we would use to figure out what bit-size to give the 
> > > replacement
> > > > expression, and one in Python, that emulated the C one and tried to
> > > > prove that the C algorithm would never fail to correctly assign
> > > > bit-sizes. That seemed pretty fragile, and likely to fall over if we
> > > > make any changes. Furthermore, the C code was really just 
> > > recomputing
> > > > more-or-less the same thing as the Python code every time. Instead, 
> > > we
> > > > can just store the results of the Python algorithm in the C
> > > > datastructure, and consult it to compute the bitsize of each value,
> > > > moving the "brains" entirely into Python. Since the Python 
> > > algorithm no
> > > > longer has to match C, it's also a lot easier to change it to 
> > > something
> > > > more closely approximating an actual type-inference algorithm. The
> > > > algorithm used is based on Hindley-Milner, although deliberately
> > > > weakened a little. It's a few more lines than the old one, judging 
> > > by
> > > > the diffstat, but I think it's easier to verify that it's correct 
> > > while
> > > > being as general as possible.
> > > >
> > > > We could split this up into two changes, first making the C code 
> > > use the
> > > > results of the Python code and then rewriting the Python algorithm, 
> > > but
> > > > since the old algorithm never tracked which variable each 
> > > equivalence
> > > > class, it would mean we'd have to add some non-trivial code which 
> > > would
> > > > then get thrown away. I think it's better to see the final state 
> > > all at
> > > > once, although I could also try splitting it up.
> > > > ---
> > > >  src/compiler/nir/nir_algebraic.py | 518 
> > > --
> > > >  src/compiler/nir/nir_search.c | 146 +
> > > >  src/compiler/nir/nir_search.h |   2 +-
> > > >  3 files changed, 295 insertions(+), 371 deletions(-)
> > > >
> > > > diff --git a/src/compiler/nir/nir_algebraic.py b/src/compiler/nir/
> > > nir_algebraic.py
> > > > index 728196136ab..48390dbde38 100644
> > > > --- a/src/compiler/nir/nir_algebraic.py
> > > > +++ b/src/compiler/nir/nir_algebraic.py
> > > > @@ -88,7 +88,7 @@ class Value(object):
> > > >
> > > > __template = mako.template.Template("""
> > > >  static const ${val.c_type} ${val.name} = {
> > > > -   { ${val.type_enum}, ${val.bit_size} },
> > > > +   { ${val.type_enum}, ${val.c_bit_size} },
> > > >  % if isinstance(val, Constant):
> > > > ${val.type()}, { ${val.hex()} /* ${val.value} */ },
> > > >  % elif isinstance(val, Variable):
> > > > @@ -112,6 +112,40 @@ static const ${val.c_type} ${val.name} = {
> > > > def __str__(self):
> > > >return self.in_val
> > > >
> > > > +   def get_bit_size(self):
> > > > +  """Get the physical bit-size that has been chosen for this 
> > > value,
> > > or if
> > > > +  there is none, the canonical value which currently 
> > > represents this
> > > > +  bit-size class. Variables will be preferred, i.e. if there 
> > > are any
> > > > +  variables in the equivalence class, the canonical value will 
> > > be a
> > > > +  variable. We do this since we'll need to know which variable 
> > > each
> > > value
> > > > +  is equivalent to when constructing the replacement 
> > > expression.
> > > This is
> > > > +  the "find" part of the union-find algorithm.
> > > > +  """
> > > > +  bit_size = self
> > > > +
> > > > +  while isinstance(bit_size, Value):
> > > > + if bit_size._bit_size == None:
> > >
> > > Use "is" and "is not" instead of "==" and "!=" when comparing 
> > > singletons
> > > like
> > > None, True, False; the former are the identity operators, they'll be 
> > > faster
> > > and
> > > avoid any surprises.
> > >
> > > > +break
> > > > + bit_size = bit_size._bit_size
> > > > +
> > > > +  if bit_size != self:
> > >
> > > Is this a comparison of identity or equality? If it's identity you 
> > > should
> > > use
> > > "is not"
> > >
> > >
> > > I just saw this one in v2.  Agreed; it should be "is not"
> > >
> > >
> > > > + self._bit_size = bit_size
> > > > +  return bit_size
> > > > +
> > >
> > > [snip]
> > >
> > > >   else:
> > > > -if val.common_class != 0:
> > > > -  

Re: [Mesa-dev] [PATCH 16/59] intel/compiler: implement 16-bit fsign

2018-12-04 Thread Pohjolainen, Topi
On Tue, Dec 04, 2018 at 08:16:40AM +0100, Iago Toral Quiroga wrote:
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 27 +--
>  1 file changed, 21 insertions(+), 6 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index 3eba8a478f5..559b55a0f84 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -938,14 +938,29 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
>* Predicated OR ORs 1.0 (0x3f80) with the sign bit if val is 
> not
>* zero.
>*/
> - bld.CMP(bld.null_reg_f(), op[0], brw_imm_f(0.0f), 
> BRW_CONDITIONAL_NZ);
> + fs_reg zero, one_mask, sign_mask;
> + brw_reg_type reg_type;
> + if (type_sz(op[0].type) == 4) {
> +zero = brw_imm_f(0.0f);
> +one_mask = brw_imm_ud(0x3f80);
> +sign_mask = brw_imm_ud(0x8000);
> +reg_type = BRW_REGISTER_TYPE_UD;
> + } else {
> +assert(type_sz(op[0].type) == 2);
> +zero = retype(brw_imm_uw(0), BRW_REGISTER_TYPE_HF);
> +one_mask = brw_imm_uw(0x3c00);
> +sign_mask = brw_imm_uw(0x8000);
> +reg_type = BRW_REGISTER_TYPE_UW;
> + }
> +
> + bld.CMP(bld.null_reg_f(), op[0], zero, BRW_CONDITIONAL_NZ);
>  
> - fs_reg result_int = retype(result, BRW_REGISTER_TYPE_UD);
> - op[0].type = BRW_REGISTER_TYPE_UD;
> - result.type = BRW_REGISTER_TYPE_UD;
> - bld.AND(result_int, op[0], brw_imm_ud(0x8000u));
> + fs_reg result_int = retype(result, reg_type);
> + op[0].type = reg_type;
> + result.type = reg_type;
> + bld.AND(result_int, op[0], sign_mask);
>  
> - inst = bld.OR(result_int, result_int, brw_imm_ud(0x3f80u));
> + inst = bld.OR(result_int, result_int, one_mask);
>   inst->predicate = BRW_PREDICATE_NORMAL;
>} else {
>   /* For doubles we do the same but we need to consider:
> -- 
> 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 mesa] drop autotools

2018-12-04 Thread Dylan Baker
Quoting Eric Engestrom (2018-12-03 10:26:01)
> On Monday, 2018-12-03 10:06:30 -0800, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-12-03 09:46:29)
> > > On Monday, 2018-12-03 09:25:48 -0800, Dylan Baker wrote:
> > > > Can I admit I was really wanted to send this patch out and it actually 
> > > > makes me
> > > > sad that you beat me too it? 
> > > 
> > > Heh, I think many (most?) of us wanted to send this patch :P
> > > 
> > > > 
> > > > That said there are a couple things you missed.
> > > 
> > > I think you forgot to mention what those things are?
> > > 
> > > If you prefer, feel free to just compare your patch and mine and just
> > > add anything you might have missed and send out yours as the v2 of mine.
> > > Note that Anholt gave some feedback which I applied locally, in case it
> > > applies to you too :)
> > 
> > What I saw diffing them is that I did get the travis jobs, but didn't get 
> > the
> > .gitignore files. I also wrote a little script and found the 
> > Makefile.sources
> > files that are used only by autotools (not scons or android), which I think 
> > was
> > the bulk of what you missed.
> > 
> > I went ahead and sent out a v2 with a heartfelt plea :)
> 
> I don't seem to have received it... It might have been too big and got
> caught in moderation?
> If you haven't, you should use --irreversible-delete to not show the
> diff of files deleted, as I did (and my email was already 60KB!)

I had no idea that --irreversible-delete existed! Resent using that (and with
the stray change removed)

Dylan


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


[Mesa-dev] [PATCH v2] build: remove autotools

2018-12-04 Thread Dylan Baker
There are now no known distributions using autotools, meson has all of
the features that autotools does. We don't need two build systems to do
exactly the same thing, meson is faster, easier to maintain, and used by
more devs than autotools. Let's reduce the ongoing burden of maintaining
autotools.

This removes the following:
 - configure.ac
 - autogen.sh
 - Makefile.*.am
 - Makefile.am
 - Makefile.sources (which are used only by autotools)
 - travis jobs for autotools
 - docs for autotools
 - .gitignore

v2: - remove stray no-op change in .travis.yml
---
 .travis.yml   |  370 +-
 Makefile.am   |   92 -
 REVIEWERS |8 -
 autogen.sh|   14 -
 bin/.gitignore|9 -
 configure.ac  | 3373 -
 docs/autoconf.html|  243 +-
 docs/debugging.html   |3 +-
 docs/devinfo.html |2 +-
 docs/faq.html |4 +-
 docs/install.html |   22 +-
 docs/llvmpipe.html|6 +-
 docs/releasing.html   |  101 +-
 docs/relnotes/19.0.0.html |2 +-
 docs/submittingpatches.html   |8 +-
 docs/vmware-guest.html|   17 +-
 doxygen/.gitignore|   19 -
 install-gallium-links.mk  |   37 -
 install-lib-links.mk  |   25 -
 m4/.gitignore |5 -
 m4/ax_check_compile_flag.m4   |   79 -
 m4/ax_check_gnu_make.m4   |   78 -
 m4/ax_check_python_mako_module.m4 |   64 -
 m4/ax_gcc_builtin.m4  |  168 -
 m4/ax_gcc_func_attribute.m4   |  230 --
 m4/ax_prog_bison.m4   |   71 -
 m4/ax_prog_flex.m4|   63 -
 m4/ax_pthread.m4  |  309 --
 src/Makefile.am   |  138 -
 src/amd/Makefile.addrlib.am   |   40 -
 src/amd/Makefile.am   |   35 -
 src/amd/Makefile.common.am|   71 -
 src/amd/common/.gitignore |1 -
 src/amd/vulkan/.gitignore |9 -
 src/amd/vulkan/Makefile.am|  200 -
 src/broadcom/.gitignore   |3 -
 src/broadcom/Makefile.am  |   65 -
 src/broadcom/Makefile.cle.am  |6 -
 src/broadcom/Makefile.genxml.am   |   54 -
 src/broadcom/Makefile.v3d.am  |   32 -
 src/broadcom/qpu/tests/.gitignore |1 -
 src/compiler/.gitignore   |6 -
 src/compiler/Makefile.am  |   77 -
 src/compiler/Makefile.glsl.am |  264 --
 src/compiler/Makefile.nir.am  |  116 -
 src/compiler/Makefile.spirv.am|   59 -
 src/compiler/glsl/.gitignore  |   12 -
 src/compiler/glsl/glcpp/.gitignore|6 -
 src/compiler/glsl/glcpp/tests/.gitignore  |4 -
 src/compiler/glsl/tests/.gitignore|6 -
 src/compiler/glsl/tests/warnings/.gitignore   |1 -
 src/compiler/nir/.gitignore   |7 -
 src/compiler/nir/tests/.gitignore |1 -
 src/compiler/spirv/.gitignore |2 -
 src/egl/.gitignore|2 -
 src/egl/Makefile.am   |  233 --
 src/egl/drivers/dri2/.gitignore   |2 -
 src/egl/wayland/wayland-drm/.gitignore|3 -
 src/egl/wayland/wayland-drm/Makefile.am   |   37 -
 src/freedreno/Makefile.am |   76 -
 src/freedreno/Makefile.sources|   41 -
 src/gallium/Makefile.am   |  211 --
 src/gallium/auxiliary/Makefile.am |  134 -
 src/gallium/auxiliary/indices/.gitignore  |2 -
 src/gallium/auxiliary/pipe-loader/Makefile.am |   51 -
 src/gallium/auxiliary/util/.gitignore |2 -
 src/gallium/drivers/etnaviv/.gitignore|1 -
 src/gallium/drivers/etnaviv/Makefile.am   |   46 -
 src/gallium/drivers/freedreno/.gitignore  |2 -
 src/gallium/drivers/freedreno/Makefile.am |   23 -
 src/gallium/drivers/i915/Makefile.am  |   33 -
 src/gallium/drivers/imx/Makefile.am   |8 -
 src/gallium/drivers/llvmpipe/.gitignore   |5 -
 src/gallium/drivers/llvmpipe/Makefile.am  |   80 -
 src/gallium/drivers/nouveau/.gitignore|1 -
 src/gallium/drivers/nouveau/Makefile.am   |   54 -
 src/gallium/drivers/pl111/Makefile.am |8 -
 src/gallium/drivers/r300/.gitignore   |1 -
 

[Mesa-dev] [Bug 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #25 from Samuel Pitoiset  ---
This is with mesa 18.2.5 and LLVM 7.0.1 on Vega 56.

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #5 from Igor Gnatenko  ---
Might it be related to this meson part:

if get_option('power8') != 'false'
  if host_machine.cpu_family() == 'ppc64le'
if cc.get_id() == 'gcc' and cc.version().version_compare('< 4.8')
  error('Altivec is not supported with gcc version < 4.8.')
endif
if cc.compiles('''
#include 
int main() {
  vector unsigned char r;
  vector unsigned int v = vec_splat_u32 (1);
  r = __builtin_vec_vgbbd ((vector unsigned char) v);
  return 0;
}''',
args : '-mpower8-vector',
name : 'POWER8 intrinsics')
  pre_args += ['-D_ARCH_PWR8', '-mpower8-vector']
elif get_option('power8') == 'true'
  error('POWER8 intrinsic support required but not found.')
endif
  endif
endif

?

-- 
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 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #24 from Samuel Pitoiset  ---
Can't be reproduced on my side, what llvm are you using?

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #4 from Igor Gnatenko  ---
(In reply to Eric Engestrom from comment #1)
> This sounds like one of your system headers is #define'ing `vector` as
> `__attribute__((something))`, but if that's the case then good luck
> compiling *any* C++ code :/

Interestingly it works fine if I use autotools as a buildsystem.

> Can you confirm this by adding this next to that sts::vector line and seeing
> if it fires when you compile?
> 
> #ifdef vector
> #error "`vector` is #define'd"
> #endif

[1694/1840] c++
-Isrc/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta
-Isrc/gallium/state_trackers/clover -I../src/gallium/state_trackers/clover
-Iinclude -I../include -Isrc -I../src -I../src/gallium/include
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -fdiagnostics-color=always
-pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DVERSION="18.3.0-rc5"'
-DPACKAGE_VERSION=VERSION
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa;'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=1
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM
-DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
-DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL
-DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE
-DUSE_GCC_ATOMIC_BUILTINS -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H
-DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF
-DHAVE_MKOSTEMP -DHAVE_POSIX_MEMALIGN -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE
-DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0700
-DMESA_LLVM_VERSION_PATCH=0 -DUSE_LIBGLVND=1 -DHAVE_VALGRIND -DMESA_SELINUX
-DHAVE_WAYLAND_PLATFORM -DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS
-Werror=return-type -fno-math-errno -fno-trapping-math -Wno-non-virtual-dtor
-Wno-missing-field-initializers -Wno-format-truncation -O2 -g -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mcpu=power8 -mtune=power8
-fasynchronous-unwind-tables -fstack-clash-protection -fPIC -fvisibility=hidden
 -MD -MQ
'src/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta/tgsi_compiler.cpp.o'
-MF
'src/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta/tgsi_compiler.cpp.o.d'
-o
'src/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta/tgsi_compiler.cpp.o'
-c ../src/gallium/state_trackers/clover/tgsi/compiler.cpp
FAILED:
src/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta/tgsi_compiler.cpp.o
 
c++
-Isrc/gallium/state_trackers/clover/src@gallium@state_trackers@clover@@cltgsi@sta
-Isrc/gallium/state_trackers/clover -I../src/gallium/state_trackers/clover
-Iinclude -I../include -Isrc -I../src -I../src/gallium/include
-Isrc/gallium/auxiliary -I../src/gallium/auxiliary -fdiagnostics-color=always
-pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DVERSION="18.3.0-rc5"'
-DPACKAGE_VERSION=VERSION
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa;'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=1
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM
-DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32
-DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL
-DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK
-DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED
-DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_VISIBILITY
-DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE
-DUSE_GCC_ATOMIC_BUILTINS -DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H

Re: [Mesa-dev] [PATCH v4 5/5] intel/tools: make sure the binary file is properly read

2018-12-04 Thread Eric Engestrom
On Tuesday, 2018-12-04 15:36:28 +0200, andrey simiklit wrote:
> Hello,
> 
> I'm sorry for disturbing, could I ask you to push this patch if it
> possible? )))

Sorry yes, thanks for the reminder :)
I just pushed it!

> 
> Regards,
> Andrii.
> 
> On Fri, Nov 30, 2018 at 6:19 PM andrey simiklit 
> wrote:
> 
> > On Fri, Nov 30, 2018 at 5:49 PM Eric Engestrom 
> > wrote:
> >
> >> On Friday, 2018-11-30 15:47:11 +, Lionel Landwerlin wrote:
> >> > On 14/11/2018 16:30, asimiklit.w...@gmail.com wrote:
> >> > > From: Andrii Simiklit 
> >> > >
> >> > > 1. tools/i965_disasm.c:58:4: warning:
> >> > >   ignoring return value of ‘fread’,
> >> > >   declared with attribute warn_unused_result
> >> > >   fread(assembly, *end, 1, fp);
> >> > >
> >> > > v2: Fixed incorrect return value check.
> >> > > ( Eric Engestrom  )
> >> > >
> >> > > v3: Zero size file check placed before fread with exit()
> >> > > ( Eric Engestrom  )
> >> > >
> >> > > v4: - Title is changed.
> >> > >  - The 'size' variable was moved to top of a function scope.
> >> > >  - The assertion was replaced by the proper error handling.
> >> > >  - The error message on a caller side was fixed.
> >> > > ( Eric Engestrom  )
> >> > >
> >> > > Signed-off-by: Andrii Simiklit 
> >> >
> >> >
> >> > With the nit below :
> >> >
> >> >
> >> > Reviewed-by: Lionel Landwerlin 
> >>
> >> I'll change that as I push it in a minute :)
> >> Reviewed-by: Eric Engestrom 
> >>
> >
> > Thanks a lot for reviews :)
> >
> >
> >>
> >> >
> >> >
> >> > > ---
> >> > >   src/intel/tools/i965_disasm.c | 16 +---
> >> > >   1 file changed, 13 insertions(+), 3 deletions(-)
> >> > >
> >> > > diff --git a/src/intel/tools/i965_disasm.c
> >> b/src/intel/tools/i965_disasm.c
> >> > > index 73a6760fc1..0efbdab706 100644
> >> > > --- a/src/intel/tools/i965_disasm.c
> >> > > +++ b/src/intel/tools/i965_disasm.c
> >> > > @@ -47,17 +47,23 @@ i965_disasm_get_file_size(FILE *fp)
> >> > >   static void *
> >> > >   i965_disasm_read_binary(FILE *fp, size_t *end)
> >> > >   {
> >> > > +   size_t size;
> >> > >  void *assembly;
> >> > >  *end = i965_disasm_get_file_size(fp);
> >> > > +   if (!*end)
> >> > > +  return NULL;
> >> > >  assembly = malloc(*end + 1);
> >> > >  if (assembly == NULL)
> >> > > return NULL;
> >> > > -   fread(assembly, *end, 1, fp);
> >> > > +   size = fread(assembly, *end, 1, fp);
> >> > >  fclose(fp);
> >> > > -
> >> > > +   if (!size) {
> >> > > +  free(assembly);
> >> > > +  return NULL;
> >> > > +   }
> >> > >  return assembly;
> >> > >   }
> >> > > @@ -167,7 +173,11 @@ int main(int argc, char *argv[])
> >> > >  assembly = i965_disasm_read_binary(fp, );
> >> > >  if (!assembly) {
> >> > > -  fprintf(stderr, "Unable to allocate buffer to read binary
> >> file\n");
> >> > > +  if(end)
> >> > if (end)
> >> > > +fprintf(stderr, "Unable to allocate buffer to read binary
> >> file\n");
> >> > > +  else
> >> > > +fprintf(stderr, "Input file is empty\n");
> >> > > +
> >> > > exit(EXIT_FAILURE);
> >> > >  }
> >> >
> >> >
> >> ___
> >> 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] Make Jordan an Owner of the mesa project?

2018-12-04 Thread Jose Fonseca
ACK.


Jose



From: Jason Ekstrand 
Sent: Tuesday, December 4, 2018 00:48
To: ML mesa-dev
Cc: Nicolai Hähnle; Ian Romanick; Ilia Mirkin; Dave Airlie; Kenneth Graunke; 
Matt Turner; Brian Paul; Jose Fonseca; Eric Anholt; Marek Olšák; Rob Clark
Subject: Make Jordan an Owner of the mesa project?

Jordan has requested to be made an Owner of the mesa project.  As much as I may 
be the guy who pushed to get everything set up, I don't want to do this sort of 
thing on my own.  As such, I'm asking for some ACKs.  If I can get 5 ACKs (at 
least 2 non-intel) from other Owners and no NAKs, I'll click the button.

Personally, I think the answer here is absurdly obvious.  Jordan is one of the 
most involved people in the community. :-D

As a side-note, does this seem like a reasonable process for adding people as 
Owners?

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


Re: [Mesa-dev] [PATCH] radv: fix vkCmdCopyQueryoolResults() for timestamp queries

2018-12-04 Thread Alex Smith
Tested-by: Alex Smith 

Thanks! s/Queryool/QueryPool/ in the subject, btw.

On Tue, 4 Dec 2018 at 15:52, Samuel Pitoiset 
wrote:

> Because WAIT_REG_MEM can only wait for a 32-bit value, it's not
> safe to use it for timestamp queries. If we only wait on the low
> 32 bits of a timestamp query we could be unlucky and the GPU
> might hang.
>
> One possible fix is to emit a full end of pipe event and wait
> on a 32-bit value which is actually an availability bit. This
> bit is allocated at creation time and always cleared before
> emitting the EOP event.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
> Fixes: 5d6a560a29 ("radv: do not use the availability bit for timestamp
> queries")
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_query.c | 49 +++--
>  1 file changed, 41 insertions(+), 8 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 550abe307a1..9bb6b660add 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1056,8 +1056,15 @@ VkResult radv_CreateQueryPool(
> pool->pipeline_stats_mask = pCreateInfo->pipelineStatistics;
> pool->availability_offset = pool->stride * pCreateInfo->queryCount;
> pool->size = pool->availability_offset;
> -   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS)
> +   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS) {
> pool->size += 4 * pCreateInfo->queryCount;
> +   } else if (pCreateInfo->queryType == VK_QUERY_TYPE_TIMESTAMP) {
> +   /* Allocate one DWORD for the availability bit which is
> needed
> +* for vkCmdCopyQueryPoolResults() because we can't
> perform a
> +* WAIT_REG_MEM on a 64-bit value.
> +*/
> +   pool->size += 4;
> +   }
>
> pool->bo = device->ws->buffer_create(device->ws, pool->size,
>  64, RADEON_DOMAIN_GTT,
> RADEON_FLAG_NO_INTERPROCESS_SHARING);
> @@ -1328,19 +1335,45 @@ void radv_CmdCopyQueryPoolResults(
>   pool->availability_offset + 4 *
> firstQuery);
> break;
> case VK_QUERY_TYPE_TIMESTAMP:
> +   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
> +   /* Emit a full end of pipe event because we can't
> +* perform a WAIT_REG_MEM on a 64-bit value. If we
> only
> +* do a WAIT_REG_MEM on the low 32 bits of a
> timestamp
> +* query we could be unlucky and the GPU might
> hang.
> +*/
> +   enum chip_class chip =
> cmd_buffer->device->physical_device->rad_info.chip_class;
> +   bool is_mec = radv_cmd_buffer_uses_mec(cmd_buffer);
> +   uint64_t avail_va = va + pool->availability_offset;
> +
> +   /* Clear the availability bit before waiting on
> the end
> +* of pipe event.
> +*/
> +   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
> +   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
> +   S_370_WR_CONFIRM(1) |
> +   S_370_ENGINE_SEL(V_370_ME));
> +   radeon_emit(cs, avail_va);
> +   radeon_emit(cs, avail_va >> 32);
> +   radeon_emit(cs, 0xdeadbeef);
> +
> +   /* Wait for all prior GPU work. */
> +   si_cs_emit_write_event_eop(cs, chip, is_mec,
> +
> V_028A90_BOTTOM_OF_PIPE_TS, 0,
> +
> EOP_DATA_SEL_VALUE_32BIT,
> +  avail_va, 0, 1,
> +
> cmd_buffer->gfx9_eop_bug_va);
> +
> +   /* Wait on the timestamp value. */
> +   radv_cp_wait_mem(cs, WAIT_REG_MEM_EQUAL, avail_va,
> +1, 0x);
> +   }
> +
> for(unsigned i = 0; i < queryCount; ++i, dest_va +=
> stride) {
> unsigned query = firstQuery + i;
> uint64_t local_src_va = va  + query * pool->stride;
>
> MAYBE_UNUSED unsigned cdw_max =
> radeon_check_space(cmd_buffer->device->ws, cs, 19);
>
> -
> -   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
> -   radv_cp_wait_mem(cs,
> WAIT_REG_MEM_NOT_EQUAL,
> -local_src_va,
> -TIMESTAMP_NOT_READY >> 32,
> -0x);
> -   }
> if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT)
> {
> uint64_t avail_dest_va = dest_va +
> elem_size;
>
> --

Re: [Mesa-dev] [PATCH 12/59] intel/compiler: handle b2i/b2f with other integer conversion opcodes

2018-12-04 Thread Pohjolainen, Topi
On Tue, Dec 04, 2018 at 08:16:36AM +0100, Iago Toral Quiroga wrote:
> Since we handle booleans as integers this makes more sense.

If this is applied before patch 10, can we merge 10 and 13?

> ---
>  src/intel/compiler/brw_fs_nir.cpp | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index 9f3d3bf9762..6c765fc2661 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -801,11 +801,6 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
>inst->saturate = instr->dest.saturate;
>break;
>  
> -   case nir_op_b2i:
> -   case nir_op_b2f:
> -  op[0].type = BRW_REGISTER_TYPE_D;
> -  op[0].negate = !op[0].negate;
> -  /* fallthrough */
> case nir_op_f2f64:
> case nir_op_f2i64:
> case nir_op_f2u64:
> @@ -850,6 +845,11 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
>inst->saturate = instr->dest.saturate;
>break;
>  
> +   case nir_op_b2i:
> +   case nir_op_b2f:
> +  op[0].type = BRW_REGISTER_TYPE_D;
> +  op[0].negate = !op[0].negate;
> +  /* fallthrough */
> case nir_op_i2f64:
> case nir_op_i2i64:
> case nir_op_u2f64:
> -- 
> 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] [Mesa-stable] [PATCH] mesa: Revert INTEL_fragment_shader_ordering support

2018-12-04 Thread Juan A. Suarez Romero
On Tue, 2018-12-04 at 07:47 -0800, Matt Turner wrote:
> On Tue, Dec 4, 2018 at 3:15 AM Juan A. Suarez Romero
>  wrote:
> > On Mon, 2018-12-03 at 15:38 -0800, Matt Turner wrote:
> > > On Mon, Dec 3, 2018 at 8:12 AM Emil Velikov  
> > > wrote:
> > > > On Thu, 29 Nov 2018 at 23:54, Matt Turner  wrote:
> > > > > This extension is not properly tested (testing for
> > > > > GL_ARB_fragment_shader_interlock is not sufficient), and since this 
> > > > > was
> > > > > noted in review on August 28th no tests have been sent.
> > > > > 
> > > > > Revert "i965: Add INTEL_fragment_shader_ordering support."
> > > > > Revert "mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_ordering"
> > > > > 
> > > > > This reverts commit 03ecec9ed2099f6e2b62994b33dc948dc731e7b8.
> > > > > This reverts commit 119435c8778dd26cb7c8bcde9f04b3982239fe60.
> > > > > 
> > > > Kind of unfortunate but I can see where you're coming from.
> > > > No tests, thus one cannot verify the extension works correctly and
> > > > ensures it stays OK.
> > > > 
> > > > Fwiw I couldn't spot any dEQP tests either :-(
> > > > 
> > > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > > ---
> > > > > Emil: I just noticed that this was never reverted from master (and it
> > > > > needs to be removed before the 18.3 release)
> > > > > 
> > > > Are you planning to push this to master? Or you'd like it reverted
> > > > only for the 18.3 branch?
> > > 
> > > Just pushed to master. Please include in 18.3.
> > 
> > This was committed without explicitly CCing to 18.3 stable release, so it is
> > shown as a candidate to 18.2 stable release too.
> 
> Hm, I thought that the scripts read the "This reverts commit $SHA1"
> and did the right thing. Or was it my Cc: mesa-stable that caused the
> confusion?


Yes, was the mesa-stable that caused the confusion.


There is no problem, just telling because my duty is to tell people when
anything is added in the cherry-ignore :)


J.A.

> 
> > As I think this is not what we want, I'll ignore this commit for 18.2.
> 
> Right, thanks.
> 

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


[Mesa-dev] [Bug 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #23 from egon2003  ---
Created attachment 142721
  --> https://bugs.freedesktop.org/attachment.cgi?id=142721=edit
Screenshot with glitch

-- 
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 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #22 from egon2003  ---
I forgot i had played a few minutes. When you start a new game the first time
you get an option to choose something I see the issue the first time. See
attached screenshot.

-- 
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 10/59] intel/compiler: implement conversions from 16-bit float to 64-bit

2018-12-04 Thread Pohjolainen, Topi
On Tue, Dec 04, 2018 at 02:33:25PM +0200, Pohjolainen, Topi wrote:
> On Tue, Dec 04, 2018 at 08:16:34AM +0100, Iago Toral Quiroga wrote:
> > Signed-off-by: Samuel Iglesias Gonsálvez 
> > ---
> >  src/intel/compiler/brw_fs_nir.cpp | 41 +++
> >  1 file changed, 41 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> > b/src/intel/compiler/brw_fs_nir.cpp
> > index 6eb68794f58..7294f49ddc0 100644
> > --- a/src/intel/compiler/brw_fs_nir.cpp
> > +++ b/src/intel/compiler/brw_fs_nir.cpp
> > @@ -796,6 +796,47 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> > nir_alu_instr *instr)
> > case nir_op_f2f64:
> > case nir_op_f2i64:
> > case nir_op_f2u64:
> > +  /* BDW PRM, vol02, Command Reference Instructions, mov - MOVE:
> > +   *
> > +   *   "There is no direct conversion from HF to DF or DF to HF.
> > +   *Use two instructions and F (Float) as an intermediate type.
> > +   *
> > +   *There is no direct conversion from HF to Q/UQ or Q/UQ to HF.
> > +   *Use two instructions and F (Float) or a word integer type
> > +   *or a DWord integer type as an intermediate type."
> > +   */
> > +  if (nir_src_bit_size(instr->src[0].src) == 16) {
> > + fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_F, 1);
> > + inst = bld.MOV(tmp, op[0]);
> > + inst->saturate = instr->dest.saturate;
> > + op[0] = tmp;
> > +  }
> > +
> > +  /* CHV PRM, vol07, 3D Media GPGPU Engine, Register Region 
> > Restrictions:
> > +   *
> > +   *"When source or destination is 64b (...), regioning in Align1
> > +   * must follow these rules:
> > +   *
> > +   * 1. Source and destination horizontal stride must be aligned to
> > +   *the same qword.
> > +   * (...)"
> > +   *
> > +   * This means that conversions from bit-sizes smaller than 64-bit to
> > +   * 64-bit need to have the source data elements aligned to 64-bit.
> > +   * This restriction does not apply to BDW and later.
> > +   */
> > +  if (type_sz(result.type) == 8 && type_sz(op[0].type) < 8 &&
> > +  (devinfo->is_cherryview || gen_device_info_is_9lp(devinfo))) {
> > + fs_reg tmp = bld.vgrf(result.type, 1);
> > + tmp = subscript(tmp, op[0].type, 0);
> > + inst = bld.MOV(tmp, op[0]);
> > + op[0] = tmp;
> > +  }
> 
> For this second part we seem to have similar logic further down after
> "nir_op_u2u64" (not visible here) in master? Would it be possible to fallthru
> from here and re-use that?

And after reading it more carefully myself it looks that this is actually
cleaner.

I noticed that in the nir_op_u2u64 case the destination and source sizes are
checked using:

   if (nir_dest_bit_size(instr->dest.dest) == 64 &&
   nir_src_bit_size(instr->src[0].src) < 64 &&
   ...

Should we use the same here for consistency?

> 
> > +
> > +  inst = bld.MOV(result, op[0]);
> > +  inst->saturate = instr->dest.saturate;
> > +  break;
> > +
> > case nir_op_i2f64:
> > case nir_op_i2i64:
> > case nir_op_u2f64:
> > -- 
> > 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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #3 from Igor Gnatenko  ---
> What OS are you running this on?

Fedora Rawhide. I'm mesa maintainer in Fedora and trying to switch from
autotools to meson in our RPM package.

> and what toolchain?

GCC, the standard one in Fedora ;)

-- 
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 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #21 from egon2003  ---
Great!

I see the issue the first time I get control in the game after starting a new
game when looking at certain objects. In the starting scene there is a doctor t
perro and the head of the character i just a big white aura.

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #2 from Eric Engestrom  ---
(In reply to Eric Engestrom from comment #1)
> What OS are you running this on?

and what toolchain?

-- 
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 108943] Build fails on ppc64le with meson

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108943

--- Comment #1 from Eric Engestrom  ---
This sounds like one of your system headers is #define'ing `vector` as
`__attribute__((something))`, but if that's the case then good luck compiling
*any* C++ code :/

Can you confirm this by adding this next to that sts::vector line and seeing if
it fires when you compile?

#ifdef vector
#error "`vector` is #define'd"
#endif

Looking at the rest of the build log, it looks like `bool` is also #define'd to
something that can't be used as a type...

What OS are you running this on?

-- 
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] radv: rework the TC-compat HTILE hardware bug with COND_EXEC

2018-12-04 Thread Samuel Pitoiset



On 12/3/18 11:21 PM, Bas Nieuwenhuizen wrote:

On Mon, Dec 3, 2018 at 11:13 PM Samuel Pitoiset
 wrote:


After investigating on this, it appears that COND_WRITE doesn't
work correctly in some situations. I don't know exactly why does
it fail to update DB_Z_INFO.ZRANGE_PRECISION, but as AMDVLK
also uses COND_EXEC I think there is a reason.

Now the driver stores a new metadata value in order to reflect
the last fast depth clear state. If a TC-compat HTILE is fast cleared
with 0.0f, we have to update ZRANGE_PRECISION to 0 in order to
work around that hardware bug.

This fixes rendering issues with The Forest and DXVK and doesn't
seem to introduce any regressions.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108914
Fixes: 68dead112e7 ("radv: update the ZRANGE_PRECISION value for the TC-compat 
bug")
Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 91 ++--
  src/amd/vulkan/radv_image.c  | 10 +++-
  src/amd/vulkan/radv_private.h|  2 +
  3 files changed, 75 insertions(+), 28 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ccf762ead46..23909a0f7dd 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1067,7 +1067,7 @@ static void
  radv_update_zrange_precision(struct radv_cmd_buffer *cmd_buffer,
  struct radv_ds_buffer_info *ds,
  struct radv_image *image, VkImageLayout layout,
-bool requires_cond_write)
+bool requires_cond_exec)
  {
 uint32_t db_z_info = ds->db_z_info;
 uint32_t db_z_info_reg;
@@ -1091,38 +1091,21 @@ radv_update_zrange_precision(struct radv_cmd_buffer 
*cmd_buffer,
 }

 /* When we don't know the last fast clear value we need to emit a
-* conditional packet, otherwise we can update DB_Z_INFO directly.
+* conditional packet that will eventually skip the following
+* SET_CONTEXT_REG packet.
  */
-   if (requires_cond_write) {
-   radeon_emit(cmd_buffer->cs, PKT3(PKT3_COND_WRITE, 7, 0));
-
-   const uint32_t write_space = 0 << 8;/* register */
-   const uint32_t poll_space = 1 << 4; /* memory */
-   const uint32_t function = 3 << 0;   /* equal to the 
reference */
-   const uint32_t options = write_space | poll_space | function;
-   radeon_emit(cmd_buffer->cs, options);
-
-   /* poll address - location of the depth clear value */
+   if (requires_cond_exec) {
 uint64_t va = radv_buffer_get_va(image->bo);
-   va += image->offset + image->clear_value_offset;
-
-   /* In presence of stencil format, we have to adjust the base
-* address because the first value is the stencil clear value.
-*/
-   if (vk_format_is_stencil(image->vk_format))
-   va += 4;
+   va += image->offset + image->tc_compat_zrange_offset;

+   radeon_emit(cmd_buffer->cs, PKT3(PKT3_COND_EXEC, 3, 0));
 radeon_emit(cmd_buffer->cs, va);
 radeon_emit(cmd_buffer->cs, va >> 32);
-
-   radeon_emit(cmd_buffer->cs, fui(0.0f));  /* reference 
value */
-   radeon_emit(cmd_buffer->cs, (uint32_t)-1);   /* comparison 
mask */
-   radeon_emit(cmd_buffer->cs, db_z_info_reg >> 2); /* write 
address low */
-   radeon_emit(cmd_buffer->cs, 0u); /* write 
address high */
-   radeon_emit(cmd_buffer->cs, db_z_info);
-   } else {
-   radeon_set_context_reg(cmd_buffer->cs, db_z_info_reg, 
db_z_info);
+   radeon_emit(cmd_buffer->cs, 0);
+   radeon_emit(cmd_buffer->cs, 3); /* SET_CONTEXT_REG size */
 }
+
+   radeon_set_context_reg(cmd_buffer->cs, db_z_info_reg, db_z_info);
  }

  static void
@@ -1269,6 +1252,45 @@ radv_set_ds_clear_metadata(struct radv_cmd_buffer 
*cmd_buffer,
 radeon_emit(cs, fui(ds_clear_value.depth));
  }

+/**
+ * Update the TC-compat metadata value for this image.
+ */
+static void
+radv_set_tc_compat_zrange_metadata(struct radv_cmd_buffer *cmd_buffer,
+  struct radv_image *image,
+  uint32_t value)
+{
+   struct radeon_cmdbuf *cs = cmd_buffer->cs;
+   uint64_t va = radv_buffer_get_va(image->bo);
+   va += image->offset + image->tc_compat_zrange_offset;
+
+   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
+   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
+   S_370_WR_CONFIRM(1) |
+   S_370_ENGINE_SEL(V_370_PFP));
+   radeon_emit(cs, va);
+   radeon_emit(cs, va >> 32);
+   radeon_emit(cs, value);
+}
+
+static void
+radv_update_tc_compat_zrange_metadata(struct 

[Mesa-dev] [PATCH] radv: fix vkCmdCopyQueryoolResults() for timestamp queries

2018-12-04 Thread Samuel Pitoiset
Because WAIT_REG_MEM can only wait for a 32-bit value, it's not
safe to use it for timestamp queries. If we only wait on the low
32 bits of a timestamp query we could be unlucky and the GPU
might hang.

One possible fix is to emit a full end of pipe event and wait
on a 32-bit value which is actually an availability bit. This
bit is allocated at creation time and always cleared before
emitting the EOP event.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108925
Fixes: 5d6a560a29 ("radv: do not use the availability bit for timestamp 
queries")
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_query.c | 49 +++--
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 550abe307a1..9bb6b660add 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1056,8 +1056,15 @@ VkResult radv_CreateQueryPool(
pool->pipeline_stats_mask = pCreateInfo->pipelineStatistics;
pool->availability_offset = pool->stride * pCreateInfo->queryCount;
pool->size = pool->availability_offset;
-   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS)
+   if (pCreateInfo->queryType == VK_QUERY_TYPE_PIPELINE_STATISTICS) {
pool->size += 4 * pCreateInfo->queryCount;
+   } else if (pCreateInfo->queryType == VK_QUERY_TYPE_TIMESTAMP) {
+   /* Allocate one DWORD for the availability bit which is needed
+* for vkCmdCopyQueryPoolResults() because we can't perform a
+* WAIT_REG_MEM on a 64-bit value.
+*/
+   pool->size += 4;
+   }
 
pool->bo = device->ws->buffer_create(device->ws, pool->size,
 64, RADEON_DOMAIN_GTT, 
RADEON_FLAG_NO_INTERPROCESS_SHARING);
@@ -1328,19 +1335,45 @@ void radv_CmdCopyQueryPoolResults(
  pool->availability_offset + 4 * firstQuery);
break;
case VK_QUERY_TYPE_TIMESTAMP:
+   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
+   /* Emit a full end of pipe event because we can't
+* perform a WAIT_REG_MEM on a 64-bit value. If we only
+* do a WAIT_REG_MEM on the low 32 bits of a timestamp
+* query we could be unlucky and the GPU might hang.
+*/
+   enum chip_class chip = 
cmd_buffer->device->physical_device->rad_info.chip_class;
+   bool is_mec = radv_cmd_buffer_uses_mec(cmd_buffer);
+   uint64_t avail_va = va + pool->availability_offset;
+
+   /* Clear the availability bit before waiting on the end
+* of pipe event.
+*/
+   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
+   radeon_emit(cs, S_370_DST_SEL(V_370_MEM_ASYNC) |
+   S_370_WR_CONFIRM(1) |
+   S_370_ENGINE_SEL(V_370_ME));
+   radeon_emit(cs, avail_va);
+   radeon_emit(cs, avail_va >> 32);
+   radeon_emit(cs, 0xdeadbeef);
+
+   /* Wait for all prior GPU work. */
+   si_cs_emit_write_event_eop(cs, chip, is_mec,
+  V_028A90_BOTTOM_OF_PIPE_TS, 
0,
+  EOP_DATA_SEL_VALUE_32BIT,
+  avail_va, 0, 1,
+  cmd_buffer->gfx9_eop_bug_va);
+
+   /* Wait on the timestamp value. */
+   radv_cp_wait_mem(cs, WAIT_REG_MEM_EQUAL, avail_va,
+1, 0x);
+   }
+
for(unsigned i = 0; i < queryCount; ++i, dest_va += stride) {
unsigned query = firstQuery + i;
uint64_t local_src_va = va  + query * pool->stride;
 
MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws, cs, 19);
 
-
-   if (flags & VK_QUERY_RESULT_WAIT_BIT) {
-   radv_cp_wait_mem(cs, WAIT_REG_MEM_NOT_EQUAL,
-local_src_va,
-TIMESTAMP_NOT_READY >> 32,
-0x);
-   }
if (flags & VK_QUERY_RESULT_WITH_AVAILABILITY_BIT) {
uint64_t avail_dest_va = dest_va + elem_size;
 
-- 
2.19.2

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


[Mesa-dev] [Bug 108925] vkCmdCopyQueryPoolResults(VK_QUERY_RESULT_WAIT_BIT) for timestamps with large query count hangs

2018-12-04 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108925

--- Comment #4 from Samuel Pitoiset  ---
Can you try this patch https://patchwork.freedesktop.org/series/53482/ ?

-- 
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] [Mesa-stable] [PATCH] mesa: Revert INTEL_fragment_shader_ordering support

2018-12-04 Thread Matt Turner
On Tue, Dec 4, 2018 at 3:15 AM Juan A. Suarez Romero
 wrote:
>
> On Mon, 2018-12-03 at 15:38 -0800, Matt Turner wrote:
> > On Mon, Dec 3, 2018 at 8:12 AM Emil Velikov  
> > wrote:
> > > On Thu, 29 Nov 2018 at 23:54, Matt Turner  wrote:
> > > > This extension is not properly tested (testing for
> > > > GL_ARB_fragment_shader_interlock is not sufficient), and since this was
> > > > noted in review on August 28th no tests have been sent.
> > > >
> > > > Revert "i965: Add INTEL_fragment_shader_ordering support."
> > > > Revert "mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_ordering"
> > > >
> > > > This reverts commit 03ecec9ed2099f6e2b62994b33dc948dc731e7b8.
> > > > This reverts commit 119435c8778dd26cb7c8bcde9f04b3982239fe60.
> > > >
> > > Kind of unfortunate but I can see where you're coming from.
> > > No tests, thus one cannot verify the extension works correctly and
> > > ensures it stays OK.
> > >
> > > Fwiw I couldn't spot any dEQP tests either :-(
> > >
> > > > Cc: mesa-sta...@lists.freedesktop.org
> > > > ---
> > > > Emil: I just noticed that this was never reverted from master (and it
> > > > needs to be removed before the 18.3 release)
> > > >
> > > Are you planning to push this to master? Or you'd like it reverted
> > > only for the 18.3 branch?
> >
> > Just pushed to master. Please include in 18.3.
>
>
> This was committed without explicitly CCing to 18.3 stable release, so it is
> shown as a candidate to 18.2 stable release too.

Hm, I thought that the scripts read the "This reverts commit $SHA1"
and did the right thing. Or was it my Cc: mesa-stable that caused the
confusion?

> As I think this is not what we want, I'll ignore this commit for 18.2.

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


Re: [Mesa-dev] GitLab merge requests, discussion summary - Re: [PATCH] docs: Document optional GitLab code review process

2018-12-04 Thread Brian Paul
On 12/03/2018 06:50 PM, Jordan Justen wrote:
> Lots of discussion here. :) I hoped to just dip our toes into the
> merge request stream, but the consensus is clearly against my idea. Oh
> well. :)
> 
> Here's what I gathered from the discussion:
> 
> == Keep email, allow duplicate MR, my idea ==
> 
> I don't think anyone else was in favor of this. Several were against
> it.
> 
> == NACK merge requests altogether ==
> 
> I did not see this, so that seems promising for merge requests. :) I
> guess no one strongly disagrees with trying merge requests.
> 
> == Allow submitter (or driver) to choose to email or MR, but not both ==
> 
> Several seemed to argue that this could be a good next step. But, in
> all those cases, I think they wanted to use merge requests going
> forward.
> 
> It was mentioned that vc4 has moved to github in order to allow github
> pull requests to be used.
> 
> == Require all email list, or all merge requests ==
> 
> A few argued in favor of this, and seemed to feel pretty strongly
> about it. In both cases I believe they wanted to more to merge
> requests. :)
> 
> == Next step? ==
> 
> So, what do you all think is the best next step after the discussion?
> 
> We could take the smaller step to allow the submitter, or project to
> decide which they prefer. It would allow those who prefer email to
> continue with email, while trying out gitlab merge requests. But, it
> could mean that devs need to check both gitlab and email.
> 
> Or, we could just try to make the jump to MR only. Maybe if I write
> that patch someone will finally stand up to try to NACK moving away
> from email. :)
> 
> Or, are we a little too early for this discussion, and we should just
> drop it for now?
> 
> My opinion would be to try to move a bit slower and allow the
> submitter/project to choose for a trial period. (Dylan and Daniel seem
> to think this could be really frustrating for devs though.) But, if
> everyone seems to think it's reasonable to try to jump straight to
> using merge requests exclusively, I can type that version up...

FWIW, I'd prefer the trial period where both methods are available.

-Brian

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


Re: [Mesa-dev] Make Jordan an Owner of the mesa project?

2018-12-04 Thread Brian Paul
Me too.

-Brian

On 12/04/2018 07:57 AM, Nicolai Hähnle wrote:
> +1
> 
> On 04.12.18 08:26, Marek Olšák wrote:
>> Ack.
>>
>> On Mon, Dec 3, 2018, 7:49 PM Jason Ekstrand >  wrote:
>>
>>     Jordan has requested to be made an Owner of the mesa project.  As
>>     much as I may be the guy who pushed to get everything set up, I
>>     don't want to do this sort of thing on my own.  As such, I'm asking
>>     for some ACKs.  If I can get 5 ACKs (at least 2 non-intel) from
>>     other Owners and no NAKs, I'll click the button.
>>
>>     Personally, I think the answer here is absurdly obvious.  Jordan is
>>     one of the most involved people in the community. :-D
>>
>>     As a side-note, does this seem like a reasonable process for adding
>>     people as Owners?
>>
>>     --Jason
>>
> 
> 

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


Re: [Mesa-dev] [PATCH] wayland/egl: Ensure EGL surface is resized on DRI update_buffers()

2018-12-04 Thread Carlos Garnacho
Hi!,
On Mon, Dec 3, 2018 at 7:02 PM Juan A. Suarez Romero
 wrote:
>
> On Mon, 2018-12-03 at 17:08 +, Emil Velikov wrote:
> > Hi Carlos,
> >
> > On Mon, 3 Dec 2018 at 08:09, Carlos Garnacho  wrote:
> > > Fullscreening and unfullscreening a totem window while playing a video
> > > sometimes results in the video subsurface not changing size along. This
> > > is also reproducible with epiphany.
> > >
> > > If a surface gets resized while we have an active back buffer for it, the
> > > resized dimensions won't get neither immediately applied on the resize
> > > callback, nor correctly synchronized on update_buffers(), as the
> > > (now stale) surface size and currently attached buffer size still do 
> > > match.
> > >
> > > There's actually 2 things to synchronize here, first the surface query
> > > size might not be updated yet to the wl_egl_window's (i.e. resize_callback
> > > happened while there is a back buffer), and second the wayland buffers
> > > would need dropping if new surface size differs with the currently 
> > > attached
> > > buffer. These are done in separate steps now.
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1650929
> > >
> > > Signed-off-by: Carlos Garnacho 
> > > Tested-by: Bastien Nocera 
> >
> > Please check if commit a9fb331ea7d1a78936ea8d8385e44cfd66f835c1 has
> > any effect on the issue at hand.
> > Does it resolve it, or perhaps it makes it more prominent?
> >
>
> Actually, the commit a9fb331ea7 seems the one causing this bug.

That is indeed the case :).

> So this should
> include:
>
> Fixes: a9fb331ea7d ("wayland/egl: update surface size on window resize")

Sure, will do a v2 with it soon, if nothing else pops up in review.

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


  1   2   >