date:20181102

[Mesa-dev] [PATCH] st/va: fix incorrect use of resource_destroy

2018-11-02 Thread Marek Olšák

From: Marek Olšák 

---
 src/gallium/state_trackers/va/surface.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/va/surface.c 
b/src/gallium/state_trackers/va/surface.c
index 5376be28531..9646427ea5f 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -591,24 +591,22 @@ surface_from_external_memory(VADriverContextP ctx, 
vlVaSurface *surface,
}
 
surface->buffer = vl_video_buffer_create_ex2(drv->pipe, templat, resources);
if (!surface->buffer) {
   result = VA_STATUS_ERROR_ALLOCATION_FAILED;
   goto fail;
}
return VA_STATUS_SUCCESS;
 
 fail:
-   for (i = 0; i < VL_NUM_COMPONENTS; i++) {
-  if (resources[i])
- pscreen->resource_destroy(pscreen, resources[i]);
-   }
+   for (i = 0; i < VL_NUM_COMPONENTS; i++)
+  pipe_resource_reference([i], NULL);
return result;
 }
 
 VAStatus
 vlVaHandleSurfaceAllocate(vlVaDriver *drv, vlVaSurface *surface,
   struct pipe_video_buffer *templat)
 {
struct pipe_surface **surfaces;
unsigned i;
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 11/11] intel/fs: Use SHADER_OPCODE_SEND for varying UBO pulls on gen7+

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_eu_defines.h   |  1 -
 src/intel/compiler/brw_fs.cpp | 31 ++--
 src/intel/compiler/brw_fs.h   |  4 -
 src/intel/compiler/brw_fs_cse.cpp |  1 -
 src/intel/compiler/brw_fs_generator.cpp   | 73 ---
 .../compiler/brw_schedule_instructions.cpp|  1 -
 src/intel/compiler/brw_shader.cpp |  2 -
 7 files changed, 25 insertions(+), 88 deletions(-)

diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index 858aec07827..bf46c45146e 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -526,7 +526,6 @@ enum opcode {
FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD,
FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD_GEN7,
FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN4,
-   FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7,
FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_LOGICAL,
FS_OPCODE_DISCARD_JUMP,
FS_OPCODE_SET_SAMPLE_ID,
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index d38c0bae4b8..5dec2cde33e 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -238,7 +238,6 @@ fs_inst::is_send_from_grf() const
 {
switch (opcode) {
case SHADER_OPCODE_SEND:
-   case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7:
case SHADER_OPCODE_SHADER_TIME_ADD:
case FS_OPCODE_INTERPOLATE_AT_SAMPLE:
case FS_OPCODE_INTERPOLATE_AT_SHARED_OFFSET:
@@ -5111,16 +5110,37 @@ lower_varying_pull_constant_logical_send(const 
fs_builder , fs_inst *inst)
const gen_device_info *devinfo = bld.shader->devinfo;
 
if (devinfo->gen >= 7) {
+  fs_reg index = inst->src[0];
   /* We are switching the instruction from an ALU-like instruction to a
* send-from-grf instruction.  Since sends can't handle strides or
* source modifiers, we have to make a copy of the offset source.
*/
-  fs_reg tmp = bld.vgrf(BRW_REGISTER_TYPE_UD);
-  bld.MOV(tmp, inst->src[1]);
-  inst->src[1] = tmp;
+  fs_reg offset = bld.vgrf(BRW_REGISTER_TYPE_UD);
+  bld.MOV(offset, inst->src[1]);
 
-  inst->opcode = FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7;
+  const unsigned simd_mode =
+ inst->exec_size <= 8 ? BRW_SAMPLER_SIMD_MODE_SIMD8 :
+BRW_SAMPLER_SIMD_MODE_SIMD16;
+
+  inst->opcode = SHADER_OPCODE_SEND;
   inst->mlen = inst->exec_size / 8;
+  inst->resize_sources(3);
+
+  inst->sfid = BRW_SFID_SAMPLER;
+  inst->desc = brw_sampler_desc(devinfo, 0, 0,
+GEN5_SAMPLER_MESSAGE_SAMPLE_LD,
+simd_mode, 0);
+  if (index.file == IMM) {
+ inst->desc |= index.ud & 0xff;
+ inst->src[0] = brw_imm_ud(0);
+  } else {
+ const fs_builder ubld = bld.exec_all().group(1, 0);
+ fs_reg tmp = ubld.vgrf(BRW_REGISTER_TYPE_UD);
+ ubld.AND(tmp, index, brw_imm_ud(0xff));
+ inst->src[0] = component(tmp, 0);
+  }
+  inst->src[1] = brw_imm_ud(0); /* ex_desc */
+  inst->src[2] = offset; /* payload */
} else {
   const fs_reg payload(MRF, FIRST_PULL_LOAD_MRF(devinfo->gen),
BRW_REGISTER_TYPE_UD);
@@ -5634,7 +5654,6 @@ get_lowered_simd_width(const struct gen_device_info 
*devinfo,
case FS_OPCODE_DDX_FINE:
case FS_OPCODE_DDY_COARSE:
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
-   case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7:
case FS_OPCODE_PACK_HALF_2x16_SPLIT:
case FS_OPCODE_UNPACK_HALF_2x16_SPLIT_X:
case FS_OPCODE_UNPACK_HALF_2x16_SPLIT_Y:
diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index d3bd1e18c52..4ad4be6885e 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -442,10 +442,6 @@ private:
void generate_varying_pull_constant_load_gen4(fs_inst *inst,
  struct brw_reg dst,
  struct brw_reg index);
-   void generate_varying_pull_constant_load_gen7(fs_inst *inst,
- struct brw_reg dst,
- struct brw_reg index,
- struct brw_reg offset);
void generate_mov_dispatch_to_flags(fs_inst *inst);
 
void generate_pixel_interpolator_query(fs_inst *inst,
diff --git a/src/intel/compiler/brw_fs_cse.cpp 
b/src/intel/compiler/brw_fs_cse.cpp
index 237c9c587b3..39bd5f9da71 100644
--- a/src/intel/compiler/brw_fs_cse.cpp
+++ b/src/intel/compiler/brw_fs_cse.cpp
@@ -74,7 +74,6 @@ is_expression(const fs_visitor *v, const fs_inst *const inst)
case FS_OPCODE_FB_READ_LOGICAL:
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_LOGICAL:
-   case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7:
case FS_OPCODE_LINTERP:
case

[Mesa-dev] [PATCH 08/11] intel/fs: Mark texture surfaces used in brw_fs_nir

2018-11-02 Thread Jason Ekstrand

Previously, we were marking constant surface used in the generator and
non-constant ones in brw_fs_nir.  We should pick one and go with it.
---
 src/intel/compiler/brw_fs_generator.cpp |  2 --
 src/intel/compiler/brw_fs_nir.cpp   | 16 
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index 3182f6014bc..36f8ec3fd16 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -1185,8 +1185,6 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
  inst->header_size != 0,
  simd_mode,
  return_format);
-
-  brw_mark_surface_used(prog_data, surface + base_binding_table_index);
} else {
   /* Non-const sampler index */
 
diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index c845d87d59b..8835334e273 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -5003,6 +5003,7 @@ void
 fs_visitor::nir_emit_texture(const fs_builder , nir_tex_instr *instr)
 {
unsigned texture = instr->texture_index;
+   unsigned max_texture = texture;
unsigned sampler = instr->sampler_index;
 
fs_reg srcs[TEX_LOGICAL_NUM_SRCS];
@@ -5088,14 +5089,7 @@ fs_visitor::nir_emit_texture(const fs_builder , 
nir_tex_instr *instr)
 
   case nir_tex_src_texture_offset: {
  /* Figure out the highest possible texture index and mark it as used 
*/
- uint32_t max_used = texture + instr->texture_array_size - 1;
- if (instr->op == nir_texop_tg4 && devinfo->gen < 8) {
-max_used += stage_prog_data->binding_table.gather_texture_start;
- } else {
-max_used += stage_prog_data->binding_table.texture_start;
- }
- brw_mark_surface_used(prog_data, max_used);
-
+ max_texture = texture + instr->texture_array_size - 1;
  /* Emit code to evaluate the actual indexing expression */
  fs_reg tmp = vgrf(glsl_type::uint_type);
  bld.ADD(tmp, src, brw_imm_ud(texture));
@@ -5126,6 +5120,7 @@ fs_visitor::nir_emit_texture(const fs_builder , 
nir_tex_instr *instr)
 stage_prog_data->binding_table.texture_start;
 
  srcs[TEX_LOGICAL_SRC_SURFACE] = brw_imm_ud(texture_index);
+ max_texture = texture_index;
  break;
   }
 
@@ -5134,6 +5129,11 @@ fs_visitor::nir_emit_texture(const fs_builder , 
nir_tex_instr *instr)
   }
}
 
+   unsigned bt_start = instr->op == nir_texop_tg4 && devinfo->gen < 8 ?
+   stage_prog_data->binding_table.gather_texture_start :
+   stage_prog_data->binding_table.texture_start;
+   brw_mark_surface_used(prog_data, bt_start + max_texture);
+
if (srcs[TEX_LOGICAL_SRC_MCS].file == BAD_FILE &&
(instr->op == nir_texop_txf_ms ||
 instr->op == nir_texop_samples_identical)) {
-- 
2.19.1

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

[Mesa-dev] [PATCH 05/11] intel/eu: Rework surface descriptor helpers

2018-11-02 Thread Jason Ekstrand

This commit pulls the surface descriptor helpers out into brw_eu.h and
makes them no longer depend on the codegen infrastructure.  This should
allow us to use them directly from the IR code instead of the generator.
This change is unfortunately less mechanical than perhaps one would like
but it should be fairly straightforward.
---
 src/intel/compiler/brw_eu.h  | 210 +
 src/intel/compiler/brw_eu_emit.c | 255 +++
 2 files changed, 231 insertions(+), 234 deletions(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 9f1ca769bd3..3b15a4a82b7 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -369,6 +369,216 @@ brw_dp_surface_desc(const struct gen_device_info *devinfo,
}
 }
 
+static inline uint32_t
+brw_dp_untyped_atomic_desc(const struct gen_device_info *devinfo,
+   unsigned exec_size, /**< 0 for SIMD4x2 */
+   unsigned atomic_op,
+   bool response_expected)
+{
+   assert(exec_size <= 8 || exec_size == 16);
+
+   unsigned msg_type;
+   if (devinfo->gen >= 8 || devinfo->is_haswell) {
+  if (exec_size > 0) {
+ msg_type = HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP;
+  } else {
+ msg_type = HSW_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_OP_SIMD4X2;
+  }
+   } else {
+  msg_type = GEN7_DATAPORT_DC_UNTYPED_ATOMIC_OP;
+   }
+
+   const unsigned msg_control =
+  SET_BITS(atomic_op, 3, 0) |
+  SET_BITS(0 < exec_size && exec_size <= 8, 4, 4) |
+  SET_BITS(response_expected, 5, 5);
+
+   return brw_dp_surface_desc(devinfo, msg_type, msg_control);
+}
+
+static inline uint32_t
+brw_dp_untyped_atomic_float_desc(const struct gen_device_info *devinfo,
+ unsigned exec_size,
+ unsigned atomic_op,
+ bool response_expected)
+{
+   assert(exec_size <= 8 || exec_size == 16);
+   assert(devinfo->gen >= 9);
+
+   assert(exec_size > 0);
+   const unsigned msg_type = GEN9_DATAPORT_DC_PORT1_UNTYPED_ATOMIC_FLOAT_OP;
+
+   const unsigned msg_control =
+  SET_BITS(atomic_op, 1, 0) |
+  SET_BITS(exec_size <= 8, 4, 4) |
+  SET_BITS(response_expected, 5, 5);
+
+   return brw_dp_surface_desc(devinfo, msg_type, msg_control);
+}
+
+static inline unsigned
+brw_mdc_cmask(unsigned num_channels)
+{
+   /* See also MDC_CMASK in the SKL PRM Vol 2d. */
+   return 0xf & (0xf << num_channels);
+}
+
+static inline uint32_t
+brw_dp_untyped_surface_rw_desc(const struct gen_device_info *devinfo,
+   unsigned exec_size, /**< 0 for SIMD4x2 */
+   unsigned num_channels,
+   bool write)
+{
+   assert(exec_size <= 8 || exec_size == 16);
+
+   unsigned msg_type;
+   if (write) {
+  if (devinfo->gen >= 8 || devinfo->is_haswell) {
+ msg_type = HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_WRITE;
+  } else {
+ msg_type = GEN7_DATAPORT_DC_UNTYPED_SURFACE_WRITE;
+  }
+   } else {
+  /* Read */
+  if (devinfo->gen >= 8 || devinfo->is_haswell) {
+ msg_type = HSW_DATAPORT_DC_PORT1_UNTYPED_SURFACE_READ;
+  } else {
+ msg_type = GEN7_DATAPORT_DC_UNTYPED_SURFACE_READ;
+  }
+   }
+
+   /* SIMD4x2 is only valid for read messages on IVB; use SIMD8 instead */
+   if (write && devinfo->gen == 7 && !devinfo->is_haswell && exec_size == 0)
+  exec_size = 8;
+
+   /* See also MDC_SM3 in the SKL PRM Vol 2d. */
+   const unsigned simd_mode = exec_size == 0 ? 0 : /* SIMD4x2 */
+  exec_size <= 8 ? 2 : 1;
+
+   const unsigned msg_control =
+  SET_BITS(brw_mdc_cmask(num_channels), 3, 0) |
+  SET_BITS(simd_mode, 5, 4);
+
+   return brw_dp_surface_desc(devinfo, msg_type, msg_control);
+}
+
+static inline unsigned
+brw_mdc_ds(unsigned bit_size)
+{
+   switch (bit_size) {
+   case 8:
+  return GEN7_BYTE_SCATTERED_DATA_ELEMENT_BYTE;
+   case 16:
+  return GEN7_BYTE_SCATTERED_DATA_ELEMENT_WORD;
+   case 32:
+  return GEN7_BYTE_SCATTERED_DATA_ELEMENT_DWORD;
+   default:
+  unreachable("Unsupported bit_size for byte scattered messages");
+   }
+}
+
+static inline uint32_t
+brw_dp_byte_scattered_rw_desc(const struct gen_device_info *devinfo,
+  unsigned exec_size,
+  unsigned bit_size,
+  bool write)
+{
+   assert(exec_size <= 8 || exec_size == 16);
+
+   assert(devinfo->gen > 7 || devinfo->is_haswell);
+   const unsigned msg_type =
+  write ? HSW_DATAPORT_DC_PORT0_BYTE_SCATTERED_WRITE :
+  HSW_DATAPORT_DC_PORT0_BYTE_SCATTERED_READ;
+
+   assert(exec_size > 0);
+   const unsigned msg_control =
+  SET_BITS(exec_size == 16, 0, 0) |
+  SET_BITS(brw_mdc_ds(bit_size), 3, 2);
+
+   return brw_dp_surface_desc(devinfo, msg_type, msg_control);
+}
+
+static inline uint32_t

[Mesa-dev] [PATCH 04/11] intel/eu: Add has_simd4x2 bools to surface_write functions

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_eu_emit.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index d22c5743038..e8235ce05f7 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -2933,13 +2933,14 @@ brw_untyped_surface_write(struct brw_codegen *p,
const unsigned sfid = (devinfo->gen >= 8 || devinfo->is_haswell ?
   HSW_SFID_DATAPORT_DATA_CACHE_1 :
   GEN7_SFID_DATAPORT_DATA_CACHE);
+   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
+   /* SIMD4x2 untyped surface write instructions only exist on HSW+ */
+   const bool has_simd4x2 = devinfo->gen >= 8 || devinfo->is_haswell;
const unsigned desc =
   brw_message_desc(devinfo, msg_length, 0, header_present) |
   brw_dp_untyped_surface_write_desc(p, num_channels);
-   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
/* Mask out unused components -- See comment in brw_untyped_atomic(). */
-   const unsigned mask = devinfo->gen == 7 && !devinfo->is_haswell && !align1 ?
-  WRITEMASK_X : WRITEMASK_XYZW;
+   const unsigned mask = !has_simd4x2 && !align1 ? WRITEMASK_X : 
WRITEMASK_XYZW;
 
brw_send_indirect_surface_message(p, sfid, brw_writemask(brw_null_reg(), 
mask),
  payload, surface, desc);
@@ -3185,13 +3186,14 @@ brw_typed_surface_write(struct brw_codegen *p,
const unsigned sfid = (devinfo->gen >= 8 || devinfo->is_haswell ?
   HSW_SFID_DATAPORT_DATA_CACHE_1 :
   GEN6_SFID_DATAPORT_RENDER_CACHE);
+   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
+   /* SIMD4x2 typed read instructions only exist on HSW+ */
+   const bool has_simd4x2 = devinfo->gen >= 8 || devinfo->is_haswell;
const unsigned desc =
   brw_message_desc(devinfo, msg_length, 0, header_present) |
   brw_dp_typed_surface_write_desc(p, num_channels);
-   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
/* Mask out unused components -- See comment in brw_untyped_atomic(). */
-   const unsigned mask = (devinfo->gen == 7 && !devinfo->is_haswell && !align1 
?
-  WRITEMASK_X : WRITEMASK_XYZW);
+   const unsigned mask = !has_simd4x2 && !align1 ? WRITEMASK_X : 
WRITEMASK_XYZW;
 
brw_send_indirect_surface_message(p, sfid, brw_writemask(brw_null_reg(), 
mask),
  payload, surface, desc);
-- 
2.19.1

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

[Mesa-dev] [PATCH 10/11] intel/fs: Use SHADER_OPCODE_SEND for texturing on gen7+

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_fs.cpp | 138 ++-
 src/intel/compiler/brw_fs.h   |   2 +-
 src/intel/compiler/brw_fs_generator.cpp   | 162 +++---
 .../compiler/brw_schedule_instructions.cpp|  17 ++
 4 files changed, 177 insertions(+), 142 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 2a7720864ce..d38c0bae4b8 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -4479,6 +4479,66 @@ is_high_sampler(const struct gen_device_info *devinfo, 
const fs_reg )
return sampler.file != IMM || sampler.ud >= 16;
 }
 
+static unsigned
+sampler_msg_type(const gen_device_info *devinfo,
+ opcode opcode, bool shadow_compare)
+{
+   assert(devinfo->gen >= 5);
+   switch (opcode) {
+   case SHADER_OPCODE_TEX:
+  return shadow_compare ? GEN5_SAMPLER_MESSAGE_SAMPLE_COMPARE :
+  GEN5_SAMPLER_MESSAGE_SAMPLE;
+   case FS_OPCODE_TXB:
+  return shadow_compare ? GEN5_SAMPLER_MESSAGE_SAMPLE_BIAS_COMPARE :
+  GEN5_SAMPLER_MESSAGE_SAMPLE_BIAS;
+   case SHADER_OPCODE_TXL:
+  return shadow_compare ? GEN5_SAMPLER_MESSAGE_SAMPLE_LOD_COMPARE :
+  GEN5_SAMPLER_MESSAGE_SAMPLE_LOD;
+   case SHADER_OPCODE_TXL_LZ:
+  return shadow_compare ? GEN9_SAMPLER_MESSAGE_SAMPLE_C_LZ :
+  GEN9_SAMPLER_MESSAGE_SAMPLE_LZ;
+   case SHADER_OPCODE_TXS:
+   case SHADER_OPCODE_IMAGE_SIZE:
+  return GEN5_SAMPLER_MESSAGE_SAMPLE_RESINFO;
+   case SHADER_OPCODE_TXD:
+  assert(!shadow_compare || devinfo->gen >= 8 || devinfo->is_haswell);
+  return shadow_compare ? HSW_SAMPLER_MESSAGE_SAMPLE_DERIV_COMPARE :
+  GEN5_SAMPLER_MESSAGE_SAMPLE_DERIVS;
+   case SHADER_OPCODE_TXF:
+  return GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
+   case SHADER_OPCODE_TXF_LZ:
+  assert(devinfo->gen >= 9);
+  return GEN9_SAMPLER_MESSAGE_SAMPLE_LD_LZ;
+   case SHADER_OPCODE_TXF_CMS_W:
+  assert(devinfo->gen >= 9);
+  return GEN9_SAMPLER_MESSAGE_SAMPLE_LD2DMS_W;
+   case SHADER_OPCODE_TXF_CMS:
+  return devinfo->gen >= 7 ? GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DMS :
+ GEN5_SAMPLER_MESSAGE_SAMPLE_LD;
+   case SHADER_OPCODE_TXF_UMS:
+  assert(devinfo->gen >= 7);
+  return GEN7_SAMPLER_MESSAGE_SAMPLE_LD2DSS;
+   case SHADER_OPCODE_TXF_MCS:
+  assert(devinfo->gen >= 7);
+  return GEN7_SAMPLER_MESSAGE_SAMPLE_LD_MCS;
+   case SHADER_OPCODE_LOD:
+  return GEN5_SAMPLER_MESSAGE_LOD;
+   case SHADER_OPCODE_TG4:
+  assert(devinfo->gen >= 7);
+  return shadow_compare ? GEN7_SAMPLER_MESSAGE_SAMPLE_GATHER4_C :
+  GEN7_SAMPLER_MESSAGE_SAMPLE_GATHER4;
+  break;
+   case SHADER_OPCODE_TG4_OFFSET:
+  assert(devinfo->gen >= 7);
+  return shadow_compare ? GEN7_SAMPLER_MESSAGE_SAMPLE_GATHER4_PO_C :
+  GEN7_SAMPLER_MESSAGE_SAMPLE_GATHER4_PO;
+   case SHADER_OPCODE_SAMPLEINFO:
+  return GEN6_SAMPLER_MESSAGE_SAMPLE_SAMPLEINFO;
+   default:
+  unreachable("not reached");
+   }
+}
+
 static void
 lower_sampler_logical_send_gen7(const fs_builder , fs_inst *inst, opcode 
op,
 const fs_reg ,
@@ -4493,6 +4553,7 @@ lower_sampler_logical_send_gen7(const fs_builder , 
fs_inst *inst, opcode op,
 unsigned grad_components)
 {
const gen_device_info *devinfo = bld.shader->devinfo;
+   const brw_stage_prog_data *prog_data = bld.shader->stage_prog_data;
unsigned reg_width = bld.dispatch_width() / 8;
unsigned header_size = 0, length = 0;
fs_reg sources[MAX_SAMPLER_MESSAGE_SIZE];
@@ -4710,14 +4771,81 @@ lower_sampler_logical_send_gen7(const fs_builder , 
fs_inst *inst, opcode op,
bld.LOAD_PAYLOAD(src_payload, sources, length, header_size);
 
/* Generate the SEND. */
-   inst->opcode = op;
-   inst->src[0] = src_payload;
-   inst->src[1] = surface;
-   inst->src[2] = sampler;
-   inst->resize_sources(3);
+   inst->opcode = SHADER_OPCODE_SEND;
inst->mlen = mlen;
inst->header_size = header_size;
 
+   const unsigned msg_type =
+  sampler_msg_type(devinfo, op, inst->shadow_compare);
+   const unsigned simd_mode =
+  inst->exec_size <= 8 ? BRW_SAMPLER_SIMD_MODE_SIMD8 :
+ BRW_SAMPLER_SIMD_MODE_SIMD16;
+
+   uint32_t base_binding_table_index;
+   switch (op) {
+   case SHADER_OPCODE_TG4:
+   case SHADER_OPCODE_TG4_OFFSET:
+  base_binding_table_index = prog_data->binding_table.gather_texture_start;
+  break;
+   case SHADER_OPCODE_IMAGE_SIZE:
+  base_binding_table_index = prog_data->binding_table.image_start;
+  break;
+   default:
+  base_binding_table_index = prog_data->binding_table.texture_start;
+  break;
+   }
+
+   inst->sfid = BRW_SFID_SAMPLER;
+   if (surface.file == IMM && sampler.file == IMM) {
+  inst->desc =

[Mesa-dev] [PATCH 09/11] intel/fs: Use a logical opcode for IMAGE_SIZE

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_eu_defines.h |  1 +
 src/intel/compiler/brw_fs.cpp   | 10 ++
 src/intel/compiler/brw_fs_nir.cpp   | 14 --
 src/intel/compiler/brw_shader.cpp   |  2 ++
 4 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index f2190a60217..858aec07827 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -362,6 +362,7 @@ enum opcode {
SHADER_OPCODE_SAMPLEINFO_LOGICAL,
 
SHADER_OPCODE_IMAGE_SIZE,
+   SHADER_OPCODE_IMAGE_SIZE_LOGICAL,
 
/**
 * Combines multiple sources of size 1 into a larger virtual GRF.
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index c98f30ca5b2..2a7720864ce 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -740,6 +740,7 @@ fs_inst::components_read(unsigned i) const
case SHADER_OPCODE_TXF_LOGICAL:
case SHADER_OPCODE_TXL_LOGICAL:
case SHADER_OPCODE_TXS_LOGICAL:
+   case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:
case FS_OPCODE_TXB_LOGICAL:
case SHADER_OPCODE_TXF_CMS_LOGICAL:
case SHADER_OPCODE_TXF_CMS_W_LOGICAL:
@@ -4602,6 +4603,11 @@ lower_sampler_logical_send_gen7(const fs_builder , 
fs_inst *inst, opcode op,
   bld.MOV(retype(sources[length], BRW_REGISTER_TYPE_UD), lod);
   length++;
   break;
+   case SHADER_OPCODE_IMAGE_SIZE:
+  /* We need an LOD; just use 0 */
+  bld.MOV(retype(sources[length], BRW_REGISTER_TYPE_UD), brw_imm_ud(0));
+  length++;
+  break;
case SHADER_OPCODE_TXF:
   /* Unfortunately, the parameters for LD are intermixed: u, lod, v, r.
* On Gen9 they are u, v, lod, r
@@ -5072,6 +5078,10 @@ fs_visitor::lower_logical_sends()
  lower_sampler_logical_send(ibld, inst, SHADER_OPCODE_TXS);
  break;
 
+  case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:
+ lower_sampler_logical_send(ibld, inst, SHADER_OPCODE_IMAGE_SIZE);
+ break;
+
   case FS_OPCODE_TXB_LOGICAL:
  lower_sampler_logical_send(ibld, inst, FS_OPCODE_TXB);
  break;
diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 8835334e273..a45fefd1265 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -3889,18 +3889,20 @@ fs_visitor::nir_emit_intrinsic(const fs_builder , 
nir_intrinsic_instr *instr
 BRW_REGISTER_TYPE_UD);
   image = bld.emit_uniformize(image);
 
+  fs_reg srcs[TEX_LOGICAL_NUM_SRCS];
+  srcs[TEX_LOGICAL_SRC_SURFACE] = image;
+  srcs[TEX_LOGICAL_SRC_SAMPLER] = brw_imm_d(0);
+  srcs[TEX_LOGICAL_SRC_COORD_COMPONENTS] = brw_imm_d(0);
+  srcs[TEX_LOGICAL_SRC_GRAD_COMPONENTS] = brw_imm_d(0);
+
   /* Since the image size is always uniform, we can just emit a SIMD8
* query instruction and splat the result out.
*/
   const fs_builder ubld = bld.exec_all().group(8, 0);
 
-  /* The LOD also serves as the message payload */
-  fs_reg lod = ubld.vgrf(BRW_REGISTER_TYPE_UD);
-  ubld.MOV(lod, brw_imm_ud(0));
-
   fs_reg tmp = ubld.vgrf(BRW_REGISTER_TYPE_UD, 4);
-  fs_inst *inst = ubld.emit(SHADER_OPCODE_IMAGE_SIZE, tmp, lod, image);
-  inst->mlen = 1;
+  fs_inst *inst = ubld.emit(SHADER_OPCODE_IMAGE_SIZE_LOGICAL,
+tmp, srcs, ARRAY_SIZE(srcs));
   inst->size_written = 4 * REG_SIZE;
 
   for (unsigned c = 0; c < instr->dest.ssa.num_components; ++c) {
diff --git a/src/intel/compiler/brw_shader.cpp 
b/src/intel/compiler/brw_shader.cpp
index 6d68a612064..6e5113bb95a 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -272,6 +272,8 @@ brw_instruction_name(const struct gen_device_info *devinfo, 
enum opcode op)
 
case SHADER_OPCODE_IMAGE_SIZE:
   return "image_size";
+   case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:
+  return "image_size_logical";
 
case SHADER_OPCODE_SHADER_TIME_ADD:
   return "shader_time_add";
-- 
2.19.1

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

[Mesa-dev] [PATCH 02/11] intel/fs: Handle IMAGE_SIZE in size_read() and is_send_from_grf()

2018-11-02 Thread Jason Ekstrand

Like all the other sends, it's just mlen * REG_SIZE.

Fixes: 3cbc02e4693 "intel: Use TXS for image_size when we have..."
---
 src/intel/compiler/brw_fs.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 3e083723471..e412730f6cc 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -251,6 +251,7 @@ fs_inst::is_send_from_grf() const
case SHADER_OPCODE_TYPED_ATOMIC:
case SHADER_OPCODE_TYPED_SURFACE_READ:
case SHADER_OPCODE_TYPED_SURFACE_WRITE:
+   case SHADER_OPCODE_IMAGE_SIZE:
case SHADER_OPCODE_URB_WRITE_SIMD8:
case SHADER_OPCODE_URB_WRITE_SIMD8_PER_SLOT:
case SHADER_OPCODE_URB_WRITE_SIMD8_MASKED:
@@ -874,6 +875,7 @@ fs_inst::size_read(int arg) const
case SHADER_OPCODE_TYPED_ATOMIC:
case SHADER_OPCODE_TYPED_SURFACE_READ:
case SHADER_OPCODE_TYPED_SURFACE_WRITE:
+   case SHADER_OPCODE_IMAGE_SIZE:
case FS_OPCODE_INTERPOLATE_AT_SAMPLE:
case FS_OPCODE_INTERPOLATE_AT_SHARED_OFFSET:
case SHADER_OPCODE_BYTE_SCATTERED_WRITE:
-- 
2.19.1

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

[Mesa-dev] [PATCH 07/11] intel/fs: Use the generic SEND opcode for surface messages

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_eu.h   |  27 ---
 src/intel/compiler/brw_eu_emit.c  |  72 ---
 src/intel/compiler/brw_fs.cpp | 181 +-
 src/intel/compiler/brw_fs_generator.cpp   |  62 --
 .../compiler/brw_schedule_instructions.cpp|  65 +++
 5 files changed, 193 insertions(+), 214 deletions(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 3b15a4a82b7..2d8d138b993 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -787,17 +787,6 @@ brw_untyped_atomic(struct brw_codegen *p,
bool response_expected,
bool header_present);
 
-void
-brw_untyped_atomic_float(struct brw_codegen *p,
- struct brw_reg dst,
- struct brw_reg payload,
- struct brw_reg surface,
- unsigned atomic_op,
- unsigned msg_length,
- bool response_expected,
- bool header_present);
-
-
 void
 brw_untyped_surface_read(struct brw_codegen *p,
  struct brw_reg dst,
@@ -841,22 +830,6 @@ brw_typed_surface_write(struct brw_codegen *p,
 unsigned num_channels,
 bool header_present);
 
-void
-brw_byte_scattered_read(struct brw_codegen *p,
-struct brw_reg dst,
-struct brw_reg payload,
-struct brw_reg surface,
-unsigned msg_length,
-unsigned bit_size);
-
-void
-brw_byte_scattered_write(struct brw_codegen *p,
- struct brw_reg payload,
- struct brw_reg surface,
- unsigned msg_length,
- unsigned bit_size,
- bool header_present);
-
 void
 brw_memory_fence(struct brw_codegen *p,
  struct brw_reg dst,
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index e1b668c70ee..42ed77d6b12 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -2774,35 +2774,6 @@ brw_untyped_atomic(struct brw_codegen *p,
  payload, surface, desc);
 }
 
-void
-brw_untyped_atomic_float(struct brw_codegen *p,
- struct brw_reg dst,
- struct brw_reg payload,
- struct brw_reg surface,
- unsigned atomic_op,
- unsigned msg_length,
- bool response_expected,
- bool header_present)
-{
-   const struct gen_device_info *devinfo = p->devinfo;
-
-   assert(devinfo->gen >= 9);
-   assert(brw_get_default_access_mode(p) == BRW_ALIGN_1);
-
-   const unsigned sfid = HSW_SFID_DATAPORT_DATA_CACHE_1;
-   const unsigned exec_size = 1 << brw_get_default_exec_size(p);
-   const unsigned response_length =
-  brw_surface_payload_size(p, response_expected, exec_size);
-   const unsigned desc =
-  brw_message_desc(devinfo, msg_length, response_length, header_present) |
-  brw_dp_untyped_atomic_float_desc(devinfo, exec_size, atomic_op,
-   response_expected);
-
-   brw_send_indirect_surface_message(p, sfid,
- brw_writemask(dst, WRITEMASK_XYZW),
- payload, surface, desc);
-}
-
 void
 brw_untyped_surface_read(struct brw_codegen *p,
  struct brw_reg dst,
@@ -2853,49 +2824,6 @@ brw_untyped_surface_write(struct brw_codegen *p,
  payload, surface, desc);
 }
 
-void
-brw_byte_scattered_read(struct brw_codegen *p,
-struct brw_reg dst,
-struct brw_reg payload,
-struct brw_reg surface,
-unsigned msg_length,
-unsigned bit_size)
-{
-   const struct gen_device_info *devinfo = p->devinfo;
-   assert(devinfo->gen > 7 || devinfo->is_haswell);
-   assert(brw_get_default_access_mode(p) == BRW_ALIGN_1);
-   const unsigned exec_size = 1 << brw_get_default_exec_size(p);
-   const unsigned response_length = brw_surface_payload_size(p, 1, exec_size);
-   const unsigned desc =
-  brw_message_desc(devinfo, msg_length, response_length, false) |
-  brw_dp_byte_scattered_rw_desc(devinfo, exec_size, bit_size, false);
-
-   brw_send_indirect_surface_message(p, GEN7_SFID_DATAPORT_DATA_CACHE,
- dst, payload, surface, desc);
-}
-
-void
-brw_byte_scattered_write(struct brw_codegen *p,
- struct brw_reg payload,
- struct brw_reg surface,
- unsigned msg_length,
- unsigned bit_size,
-

[Mesa-dev] [PATCH 06/11] intel/fs: Add a generic SEND opcode

2018-11-02 Thread Jason Ekstrand

---
 src/intel/compiler/brw_eu_defines.h   |  7 
 src/intel/compiler/brw_fs.cpp |  9 +
 src/intel/compiler/brw_fs.h   |  6 
 src/intel/compiler/brw_fs_cse.cpp |  5 +++
 src/intel/compiler/brw_fs_generator.cpp   | 35 ++-
 src/intel/compiler/brw_fs_reg_allocate.cpp|  6 ++--
 .../compiler/brw_schedule_instructions.cpp|  7 
 src/intel/compiler/brw_shader.cpp |  6 
 src/intel/compiler/brw_shader.h   |  5 +++
 9 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index 025a459760c..f2190a60217 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -315,6 +315,13 @@ enum opcode {
SHADER_OPCODE_SIN,
SHADER_OPCODE_COS,
 
+   /**
+* A generic "send" opcode.  The first two sources are the message
+* descriptor and extended message descriptor respectively.  The third
+* and optional fourth sources are the message payload
+*/
+   SHADER_OPCODE_SEND,
+
/**
 * Texture sampling opcodes.
 *
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index e412730f6cc..bcd7578afec 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -237,6 +237,7 @@ bool
 fs_inst::is_send_from_grf() const
 {
switch (opcode) {
+   case SHADER_OPCODE_SEND:
case FS_OPCODE_VARYING_PULL_CONSTANT_LOAD_GEN7:
case SHADER_OPCODE_SHADER_TIME_ADD:
case FS_OPCODE_INTERPOLATE_AT_SAMPLE:
@@ -851,6 +852,14 @@ unsigned
 fs_inst::size_read(int arg) const
 {
switch (opcode) {
+   case SHADER_OPCODE_SEND:
+  if (arg == 2) {
+ return mlen * REG_SIZE;
+  } else if (arg == 3) {
+ return mlen2 * REG_SIZE;
+  }
+  break;
+
case FS_OPCODE_FB_WRITE:
case FS_OPCODE_REP_FB_WRITE:
   if (arg == 0) {
diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index aba19d5ab2c..fd10ac7033f 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -404,6 +404,12 @@ private:
   struct brw_reg payload,
   struct brw_reg implied_header,
   GLuint nr);
+   void generate_send(fs_inst *inst,
+  struct brw_reg dst,
+  struct brw_reg desc,
+  struct brw_reg ex_desc,
+  struct brw_reg payload,
+  struct brw_reg payload2);
void generate_fb_write(fs_inst *inst, struct brw_reg payload);
void generate_fb_read(fs_inst *inst, struct brw_reg dst,
  struct brw_reg payload);
diff --git a/src/intel/compiler/brw_fs_cse.cpp 
b/src/intel/compiler/brw_fs_cse.cpp
index 6859733d58c..237c9c587b3 100644
--- a/src/intel/compiler/brw_fs_cse.cpp
+++ b/src/intel/compiler/brw_fs_cse.cpp
@@ -184,8 +184,13 @@ instructions_match(fs_inst *a, fs_inst *b, bool *negate)
   a->dst.type == b->dst.type &&
   a->offset == b->offset &&
   a->mlen == b->mlen &&
+  a->mlen2 == b->mlen2 &&
+  a->sfid == b->sfid &&
+  a->desc == b->desc &&
   a->size_written == b->size_written &&
   a->base_mrf == b->base_mrf &&
+  a->check_tdr == b->check_tdr &&
+  a->send_has_side_effects == b->send_has_side_effects &&
   a->eot == b->eot &&
   a->header_size == b->header_size &&
   a->shadow_compare == b->shadow_compare &&
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index 08dd83dded7..176da64ef7f 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -250,6 +250,33 @@ fs_generator::patch_discard_jumps_to_fb_writes()
return true;
 }
 
+void
+fs_generator::generate_send(fs_inst *inst,
+struct brw_reg dst,
+struct brw_reg desc,
+struct brw_reg ex_desc,
+struct brw_reg payload,
+struct brw_reg payload2)
+{
+   /* SENDS not yet supported */
+   assert(ex_desc.file == BRW_IMMEDIATE_VALUE && ex_desc.d == 0);
+   assert(payload2.file == BRW_ARCHITECTURE_REGISTER_FILE &&
+  payload2.nr == BRW_ARF_NULL);
+
+   const bool dst_is_null = dst.file == BRW_ARCHITECTURE_REGISTER_FILE &&
+dst.nr == BRW_ARF_NULL;
+   const unsigned rlen = dst_is_null ? 0 : inst->size_written / REG_SIZE;
+
+   uint32_t desc_imm = inst->desc |
+  brw_message_desc(devinfo, inst->mlen, rlen, inst->header_size);
+
+   brw_send_indirect_message(p, inst->sfid, dst, payload, desc, desc_imm);
+
+   brw_inst_set_eot(p->devinfo, brw_last_inst, inst->eot);
+   if (inst->check_tdr)
+  brw_inst_set_opcode(p->devinfo, brw_last_inst, BRW_OPCODE_SENDC);
+}
+
 void

[Mesa-dev] [PATCH 03/11] intel/fs: Take an explicit exec size in brw_surface_payload_size()

2018-11-02 Thread Jason Ekstrand

Instead of magically falling back to SIMD8 for atomics and typed
messages on Ivy Bridge, explicitly figure out the exec size and pass
that into brw_surface_payload_size.
---
 src/intel/compiler/brw_eu_emit.c | 59 +---
 1 file changed, 39 insertions(+), 20 deletions(-)

diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 4630b83b1a0..d22c5743038 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -2727,15 +2727,14 @@ brw_svb_write(struct brw_codegen *p,
 static unsigned
 brw_surface_payload_size(struct brw_codegen *p,
  unsigned num_channels,
- bool has_simd4x2,
- bool has_simd16)
+ unsigned exec_size /**< 0 for SIMD4x2 */)
 {
-   if (has_simd4x2 && brw_get_default_access_mode(p) == BRW_ALIGN_16)
-  return 1;
-   else if (has_simd16 && brw_get_default_exec_size(p) == BRW_EXECUTE_16)
-  return 2 * num_channels;
-   else
+   if (exec_size == 0)
+  return 1; /* SIMD4x2 */
+   else if (exec_size <= 8)
   return num_channels;
+   else
+  return 2 * num_channels;
 }
 
 static uint32_t
@@ -2782,12 +2781,16 @@ brw_untyped_atomic(struct brw_codegen *p,
const unsigned sfid = (devinfo->gen >= 8 || devinfo->is_haswell ?
   HSW_SFID_DATAPORT_DATA_CACHE_1 :
   GEN7_SFID_DATAPORT_DATA_CACHE);
-   const unsigned response_length = brw_surface_payload_size(
-  p, response_expected, devinfo->gen >= 8 || devinfo->is_haswell, true);
+   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
+   /* SIMD4x2 untyped atomic instructions only exist on HSW+ */
+   const bool has_simd4x2 = devinfo->gen >= 8 || devinfo->is_haswell;
+   const unsigned exec_size = align1 ? 1 << brw_get_default_exec_size(p) :
+  has_simd4x2 ? 0 : 8;
+   const unsigned response_length =
+  brw_surface_payload_size(p, response_expected, exec_size);
const unsigned desc =
   brw_message_desc(devinfo, msg_length, response_length, header_present) |
   brw_dp_untyped_atomic_desc(p, atomic_op, response_expected);
-   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
/* Mask out unused components -- This is especially important in Align16
 * mode on generations that don't have native support for SIMD4x2 atomics,
 * because unused but enabled components will cause the dataport to perform
@@ -2836,8 +2839,9 @@ brw_untyped_atomic_float(struct brw_codegen *p,
assert(brw_get_default_access_mode(p) == BRW_ALIGN_1);
 
const unsigned sfid = HSW_SFID_DATAPORT_DATA_CACHE_1;
-   const unsigned response_length = brw_surface_payload_size(
-  p, response_expected, true, true);
+   const unsigned exec_size = 1 << brw_get_default_exec_size(p);
+   const unsigned response_length =
+  brw_surface_payload_size(p, response_expected, exec_size);
const unsigned desc =
   brw_message_desc(devinfo, msg_length, response_length, header_present) |
   brw_dp_untyped_atomic_float_desc(p, atomic_op, response_expected);
@@ -2880,8 +2884,10 @@ brw_untyped_surface_read(struct brw_codegen *p,
const unsigned sfid = (devinfo->gen >= 8 || devinfo->is_haswell ?
   HSW_SFID_DATAPORT_DATA_CACHE_1 :
   GEN7_SFID_DATAPORT_DATA_CACHE);
+   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
+   const unsigned exec_size = align1 ? 1 << brw_get_default_exec_size(p) : 0;
const unsigned response_length =
-  brw_surface_payload_size(p, num_channels, true, true);
+  brw_surface_payload_size(p, num_channels, exec_size);
const unsigned desc =
   brw_message_desc(devinfo, msg_length, response_length, false) |
   brw_dp_untyped_surface_read_desc(p, num_channels);
@@ -2981,8 +2987,8 @@ brw_byte_scattered_read(struct brw_codegen *p,
const struct gen_device_info *devinfo = p->devinfo;
assert(devinfo->gen > 7 || devinfo->is_haswell);
assert(brw_get_default_access_mode(p) == BRW_ALIGN_1);
-   const unsigned response_length =
-  brw_surface_payload_size(p, 1, true, true);
+   const unsigned exec_size = 1 << brw_get_default_exec_size(p);
+   const unsigned response_length = brw_surface_payload_size(p, 1, exec_size);
const unsigned desc =
   brw_message_desc(devinfo, msg_length, response_length, false) |
   brw_dp_byte_scattered_desc(p, bit_size,
@@ -3058,12 +3064,18 @@ brw_typed_atomic(struct brw_codegen *p,
const unsigned sfid = (devinfo->gen >= 8 || devinfo->is_haswell ?
   HSW_SFID_DATAPORT_DATA_CACHE_1 :
   GEN6_SFID_DATAPORT_RENDER_CACHE);
-   const unsigned response_length = brw_surface_payload_size(
-  p, response_expected, devinfo->gen >= 8 || devinfo->is_haswell, false);
+   const bool align1 = brw_get_default_access_mode(p) == BRW_ALIGN_1;
+   /* SIMD4x2 typed

[Mesa-dev] [PATCH 00/11] intel/fs: Add a generic SEND opcode and use it on

2018-11-02 Thread Jason Ekstrand

This patch series is something we've talked about doing for a while and
haven't gotten around to yet.  It implements a generic SEND opcode and then
reworks a bunch of the current SEND instructions such as texturing to use
that instead of piles of shader codegen.  Among other things, this gives us
substantially better scheduling of instructions around indirect sends.
They currently generate up to 5 ALU instructions in the generator to build
the indirect descriptor and this is reduced to 1 with the other 4 happening
in the IR level where we can schedule.

Jason Ekstrand (11):
  intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITS
  intel/fs: Handle IMAGE_SIZE in size_read() and is_send_from_grf()
  intel/fs: Take an explicit exec size in brw_surface_payload_size()
  intel/eu: Add has_simd4x2 bools to surface_write functions
  intel/eu: Rework surface descriptor helpers
  intel/fs: Add a generic SEND opcode
  intel/fs: Use the generic SEND opcode for surface messages
  intel/fs: Mark texture surfaces used in brw_fs_nir
  intel/fs: Use a logical opcode for IMAGE_SIZE
  intel/fs: Use SHADER_OPCODE_SEND for texturing on gen7+
  intel/fs: Use SHADER_OPCODE_SEND for varying UBO pulls on gen7+

 src/intel/compiler/brw_eu.h   | 237 +--
 src/intel/compiler/brw_eu_defines.h   |  13 +-
 src/intel/compiler/brw_eu_emit.c  | 376 +++---
 src/intel/compiler/brw_fs.cpp | 371 ++---
 src/intel/compiler/brw_fs.h   |  12 +-
 src/intel/compiler/brw_fs_cse.cpp |   6 +-
 src/intel/compiler/brw_fs_generator.cpp   | 334 +++-
 src/intel/compiler/brw_fs_nir.cpp |  30 +-
 src/intel/compiler/brw_fs_reg_allocate.cpp|   6 +-
 .../compiler/brw_schedule_instructions.cpp|  90 -
 src/intel/compiler/brw_shader.cpp |  10 +-
 src/intel/compiler/brw_shader.h   |   5 +
 src/mesa/drivers/dri/i965/brw_defines.h   |   2 +-
 13 files changed, 778 insertions(+), 714 deletions(-)

-- 
2.19.1

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

[Mesa-dev] [PATCH 01/11] intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITS

2018-11-02 Thread Jason Ekstrand

If you pass a bool in as the value to set, the C standard says that it
gets converted to an int prior to shifting.  If you try to set a bool to
bit 31, this lands you in undefined behavior.  It's better just to add
the explicit cast and let the compiler delete it for us.
---
 src/intel/compiler/brw_eu_defines.h | 4 ++--
 src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/compiler/brw_eu_defines.h 
b/src/intel/compiler/brw_eu_defines.h
index 52957882b10..025a459760c 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -41,14 +41,14 @@
 /* Using the GNU statement expression extension */
 #define SET_FIELD(value, field) \
({   \
-  uint32_t fieldval = (value) << field ## _SHIFT;   \
+  uint32_t fieldval = (uint32_t)(value) << field ## _SHIFT; \
   assert((fieldval & ~ field ## _MASK) == 0);   \
   fieldval & field ## _MASK;\
})
 
 #define SET_BITS(value, high, low)  \
({   \
-  const uint32_t fieldval = (value) << (low);   \
+  const uint32_t fieldval = (uint32_t)(value) << (low); \
   assert((fieldval & ~INTEL_MASK(high, low)) == 0); \
   fieldval & INTEL_MASK(high, low); \
})
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 897c91aa31e..d7a41c83ee8 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -38,7 +38,7 @@
 /* Using the GNU statement expression extension */
 #define SET_FIELD(value, field) \
({   \
-  uint32_t fieldval = (value) << field ## _SHIFT;   \
+  uint32_t fieldval = (uint32_t)(value) << field ## _SHIFT; \
   assert((fieldval & ~ field ## _MASK) == 0);   \
   fieldval & field ## _MASK;\
})
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 2/2] glsl: allow linking ES shaders with desktop shaders in desktop GL

2018-11-02 Thread Timothy Arceri




On 17/5/18 10:55 am, Ilia Mirkin wrote:

ES has all kinds of additional linking rules. I suspect they'll break
down if some of the shaders are ES and some are not-ES.


Hi Ilia,

Can you think of an example of this. I've attempted to create a CTS test 
with the following justification:



Add linking test for mixing of GLSL and GLSL ES shaders

The ARB_ES2_compatibility spec doesn't explicitly state the mixing
of these shaders is not allowed. However the strict rules around
GLSL ES shader versions when linking implies this is not allowed.

From the ARB_ES2_compatibility spec:

   "(6) What should we do about conflicting #version values?

RESOLVED: The original GLSL 1.00 spec did not include #version,
it was added in GLSL 1.10 and the first accepted value was
"110". GLSL ES has only one version and it is "100", so there
is currently no overlap and ambiguity. So GLSL can be extended
to accept "100" and always interpret it to mean "GLSL ES 1.00
functionality"."

From the OpenGL ES 3.2 spec:

   "Linking can fail for a variety of reasons as specified in the
OpenGL ES Shading Language Specification, as well as any of
the following reasons:

  ...

   - The shaders do not use the same shader language version."

However the Nvidia guys are not buying it.

"I don't think this is a valid "OpenGL" conformance test since the 
OpenGL spec doesn't forbid mixing shader versions, including ESSL 
shaders. This would be a valid "OpenGL ES" conformance test.


If you think the OpenGL spec is wrong, please file an issue at 
https://gitlab.khronos.org/opengl/API.;


If we can come up with a good example of why this should not be allowed 
I'll file a spec bug. Otherwise maybe this patch is valid after all.




This all does sound very odd -- what did you see in practice?

On Wed, May 16, 2018 at 3:04 AM, Timothy Arceri  wrote:

In GLES shader versions must match but there is nothing
in the ARB_ES*_compatibility specs that say they must match.

This fixes some compilation errors in Google Earth VR.
---
  src/compiler/glsl/linker.cpp | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index f060c5316fa..2b7ee0ad5a6 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -83,6 +83,7 @@
  #include "builtin_functions.h"
  #include "shader_cache.h"

+#include "main/context.h"
  #include "main/imports.h"
  #include "main/shaderobj.h"
  #include "main/enums.h"
@@ -4799,7 +4800,8 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
min_version = MIN2(min_version, prog->Shaders[i]->Version);
max_version = MAX2(max_version, prog->Shaders[i]->Version);

-  if (prog->Shaders[i]->IsES != prog->Shaders[0]->IsES) {
+  if (!_mesa_is_desktop_gl(ctx) &&
+  prog->Shaders[i]->IsES != prog->Shaders[0]->IsES) {
   linker_error(prog, "all shaders must use same shading "
"language version\n");
   goto done;
@@ -4817,7 +4819,7 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
 /* In desktop GLSL, different shader versions may be linked together.  In
  * GLSL ES, all shader versions must be the same.
  */
-   if (prog->Shaders[0]->IsES && min_version != max_version) {
+   if (!_mesa_is_desktop_gl(ctx) && min_version != max_version) {
linker_error(prog, "all shaders must use same shading "
 "language version\n");
goto done;
--
2.17.0

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

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


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

[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0

2018-11-02 Thread bugzilla-daemon

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

Ahmed Elsayed  changed:

   What|Removed |Added

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

--- Comment #21 from Ahmed Elsayed  ---
After updating Kernel to 4.19, the problem is fixed!

-- 
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 2/2] egl/glvnd: correctly report errors when vendor cannot be found

2018-11-02 Thread Kyle Brenneman


On 11/02/2018 01:06 PM, Emil Velikov wrote:

From: Emil Velikov

If the user provides an invalid display or device the ToVendor lookup
will fail.

In this case, the local [Mesa vendor] error code will be set. Thus on
sequential eglGetError(), the error will be EGL_SUCCESS.

To be more specific, GLVND remembers the last vendor and calls back
into it's eglGetError, although there's no guarantee to ever have had
one.

Piglit: tests/egl/spec/egl_ext_device_query
Fixes: ce562f9e3fa ("EGL: Implement the libglvnd interface for EGL (v3)")
Cc: Kyle Brenneman
Cc: Eric Engestrom
Signed-off-by: Emil Velikov
---
  src/egl/main/egldispatchstubs.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/egl/main/egldispatchstubs.c b/src/egl/main/egldispatchstubs.c
index bfc3195c779..e39fd6197a6 100644
--- a/src/egl/main/egldispatchstubs.c
+++ b/src/egl/main/egldispatchstubs.c
@@ -54,9 +54,17 @@ static __eglMustCastToProperFunctionPointerType 
FetchVendorFunc(__EGLvendorInfo
  {
  __eglMustCastToProperFunctionPointerType func = NULL;
  
-if (vendor != NULL) {

-func = exports->fetchDispatchEntry(vendor, 
__EGL_DISPATCH_FUNC_INDICES[index]);
+if (vendor == NULL) {
+// XXX: How can we end here with EGL_SUCCESS?
+if (errorCode != EGL_SUCCESS) {
+// Since we have no vendor, the follow-up eglGetError() call will
+// end up using the GLVND error code. Set it here.
+exports->setEGLError(errorCode);
+}
+return NULL;
  }
+
+func = exports->fetchDispatchEntry(vendor, 
__EGL_DISPATCH_FUNC_INDICES[index]);
  if (func == NULL) {
  if (errorCode != EGL_SUCCESS) {
  _eglError(errorCode, __EGL_DISPATCH_FUNC_NAMES[index]);
The (vendor == NULL) branch should still call _eglError so that it calls 
the debug callback function. Other than that, this looks right to me.


In answer to the question in the comment, getting an EGL_SUCCESS error 
code is inherited from the code in libglvnd itself to handle the 
eglWait* functions. If there's no current context for those functions, 
then they're a no-op and don't set an error code.


Mesa doesn't have any EGL dispatch stubs that look at the current 
context, though, so you could just remove __eglDispatchFetchByCurrent 
and the (errorCode != EGL_SUCCESS) checks.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] gbm: Introduce a helper function for printing GBM format names.

2018-11-02 Thread Eric Anholt

This requires that the caller make a little (stack) allocation to store
the string.
---
 src/gbm/main/gbm.c | 18 ++
 src/gbm/main/gbm.h |  6 ++
 2 files changed, 24 insertions(+)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 0bf2922bacdd..174f62ad797f 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -695,3 +695,21 @@ gbm_surface_has_free_buffers(struct gbm_surface *surf)
 {
return surf->gbm->surface_has_free_buffers(surf);
 }
+
+/**
+ * Returns a string representing the fourcc format name.
+ *
+ * \param desc Caller-provided storage for the format name string.
+ * \return String containing the fourcc of the format.
+ */
+GBM_EXPORT char *
+gbm_format_get_name(uint32_t gbm_format, struct gbm_format_name_desc *desc)
+{
+   desc->name[0] = gbm_format;
+   desc->name[1] = gbm_format >> 8;
+   desc->name[2] = gbm_format >> 16;
+   desc->name[3] = gbm_format >> 24;
+   desc->name[4] = 0;
+
+   return desc->name;
+}
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index e95f9e34960b..9b5288710a5b 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -190,6 +190,9 @@ enum gbm_bo_format {
 #define GBM_FORMAT_YUV444  __gbm_fourcc_code('Y', 'U', '2', '4') /* 
non-subsampled Cb (1) and Cr (2) planes */
 #define GBM_FORMAT_YVU444  __gbm_fourcc_code('Y', 'V', '2', '4') /* 
non-subsampled Cr (1) and Cb (2) planes */
 
+struct gbm_format_name_desc {
+   char name[5];
+};
 
 /**
  * Flags to indicate the intended use for the buffer - these are passed into
@@ -399,6 +402,9 @@ gbm_surface_has_free_buffers(struct gbm_surface *surface);
 void
 gbm_surface_destroy(struct gbm_surface *surface);
 
+char *
+gbm_format_get_name(uint32_t gbm_format, struct gbm_format_name_desc *desc);
+
 #ifdef __cplusplus
 }
 #endif
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/2] egl: Improve the debugging of gbm format matching in DRI configs.

2018-11-02 Thread Eric Anholt

Previously the debug would be:

libEGL debug: No DRI config supports native format 0x20203852
libEGL debug: No DRI config supports native format 0x38385247

but

libEGL debug: No DRI config supports native format R8
libEGL debug: No DRI config supports native format GR88

is a lot easier to understand.
---
 src/egl/drivers/dri2/platform_drm.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 68ec8322e978..fb346e007332 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -664,8 +664,9 @@ drm_add_configs_for_visuals(_EGLDriver *drv, _EGLDisplay 
*disp)
 
for (unsigned i = 0; i < ARRAY_SIZE(format_count); i++) {
   if (!format_count[i]) {
- _eglLog(_EGL_DEBUG, "No DRI config supports native format 0x%x",
- visuals[i].gbm_format);
+ struct gbm_format_name_desc desc;
+ _eglLog(_EGL_DEBUG, "No DRI config supports native format %s",
+ gbm_format_get_name(visuals[i].gbm_format, ));
   }
}
 
-- 
2.19.1

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

[Mesa-dev] [Bug 105328] Can't include gl and gles headers simultaneously on non-64 bit architectures

2018-11-02 Thread bugzilla-daemon

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

Matt Turner  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |fdo-b...@engestrom.ch
   |org |
URL||https://github.com/KhronosG
   ||roup/OpenGL-Registry/issues
   ||/162
 CC||matts...@gmail.com

--- Comment #7 from Matt Turner  ---
Eric reported this upstream and it's now marked as fixed. Perhaps he can do
whatever is needed to propagate this into Mesa (probably just importing the
headers and confirming you can include both?)

-- 
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] meson: link gallium nine with pthreads

2018-11-02 Thread Dylan Baker

Quoting Matt Turner (2018-11-02 12:59:14)
> Reviewed-by: Matt Turner 
> 
> Probably fine to add a Tested-by from the reporter as well.
> 
> Thanks Dylan!

Yup. I'll push this to master now.


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

[Mesa-dev] [PATCH 1/2] gallium: add PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET

2018-11-02 Thread Marek Olšák

From: Marek Olšák 

---
 src/gallium/include/pipe/p_defines.h | 3 +++
 src/mesa/state_tracker/st_manager.c  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index dacedf5b936..693f041b1da 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -394,20 +394,23 @@ enum pipe_flush_flags
 /**
  * Create a high priority context.
  */
 #define PIPE_CONTEXT_HIGH_PRIORITY (1 << 4)
 
 /**
  * Create a low priority context.
  */
 #define PIPE_CONTEXT_LOW_PRIORITY  (1 << 5)
 
+/** Stop execution if the device is reset. */
+#define PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET (1 << 6)
+
 /**
  * Flags for pipe_context::memory_barrier.
  */
 #define PIPE_BARRIER_MAPPED_BUFFER (1 << 0)
 #define PIPE_BARRIER_SHADER_BUFFER (1 << 1)
 #define PIPE_BARRIER_QUERY_BUFFER  (1 << 2)
 #define PIPE_BARRIER_VERTEX_BUFFER (1 << 3)
 #define PIPE_BARRIER_INDEX_BUFFER  (1 << 4)
 #define PIPE_BARRIER_CONSTANT_BUFFER   (1 << 5)
 #define PIPE_BARRIER_INDIRECT_BUFFER   (1 << 6)
diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index eb0b88ef473..bf5493190c8 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -881,20 +881,23 @@ st_api_create_context(struct st_api *stapi, struct 
st_manager *smapi,
   ctx_flags |= PIPE_CONTEXT_ROBUST_BUFFER_ACCESS;
 
if (attribs->flags & ST_CONTEXT_FLAG_NO_ERROR)
   no_error = true;
 
if (attribs->flags & ST_CONTEXT_FLAG_LOW_PRIORITY)
   ctx_flags |= PIPE_CONTEXT_LOW_PRIORITY;
else if (attribs->flags & ST_CONTEXT_FLAG_HIGH_PRIORITY)
   ctx_flags |= PIPE_CONTEXT_HIGH_PRIORITY;
 
+   if (attribs->flags & ST_CONTEXT_FLAG_RESET_NOTIFICATION_ENABLED)
+  ctx_flags |= PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET;
+
pipe = smapi->screen->context_create(smapi->screen, NULL, ctx_flags);
if (!pipe) {
   *error = ST_CONTEXT_ERROR_NO_MEMORY;
   return NULL;
}
 
st_visual_to_context_mode(>visual, );
 
if (attribs->visual.no_config)
   mode_ptr = NULL;
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/2] radeonsi: stop command submission with PIPE_CONTEXT_LOSE_CONTEXT_ON_RESET only

2018-11-02 Thread Marek Olšák

From: Marek Olšák 

---
 src/gallium/drivers/r300/r300_context.c   | 2 +-
 src/gallium/drivers/r600/r600_pipe.c  | 2 +-
 src/gallium/drivers/r600/r600_pipe_common.c   | 2 +-
 src/gallium/drivers/r600/radeon_uvd.c | 2 +-
 src/gallium/drivers/r600/radeon_vce.c | 2 +-
 src/gallium/drivers/radeon/radeon_uvd.c   | 2 +-
 src/gallium/drivers/radeon/radeon_uvd_enc.c   | 2 +-
 src/gallium/drivers/radeon/radeon_vce.c   | 2 +-
 src/gallium/drivers/radeon/radeon_vcn_dec.c   | 2 +-
 src/gallium/drivers/radeon/radeon_vcn_enc.c   | 3 ++-
 src/gallium/drivers/radeon/radeon_winsys.h| 9 +
 src/gallium/drivers/radeonsi/si_pipe.c| 7 ---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 6 --
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.h | 1 +
 src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 3 ++-
 15 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/r300/r300_context.c 
b/src/gallium/drivers/r300/r300_context.c
index 79bfdc53d25..0a68d37b806 100644
--- a/src/gallium/drivers/r300/r300_context.c
+++ b/src/gallium/drivers/r300/r300_context.c
@@ -386,21 +386,21 @@ struct pipe_context* r300_create_context(struct 
pipe_screen* screen,
 r300->context.priv = priv;
 
 r300->context.destroy = r300_destroy_context;
 
 slab_create_child(>pool_transfers, >pool_transfers);
 
 r300->ctx = rws->ctx_create(rws);
 if (!r300->ctx)
 goto fail;
 
-r300->cs = rws->cs_create(r300->ctx, RING_GFX, r300_flush_callback, r300);
+r300->cs = rws->cs_create(r300->ctx, RING_GFX, r300_flush_callback, r300, 
false);
 if (r300->cs == NULL)
 goto fail;
 
 if (!r300screen->caps.has_tcl) {
 /* Create a Draw. This is used for SW TCL. */
 r300->draw = draw_create(>context);
 if (r300->draw == NULL)
 goto fail;
 /* Enable our renderer. */
 draw_set_rasterize_stage(r300->draw, r300_draw_stage(r300));
diff --git a/src/gallium/drivers/r600/r600_pipe.c 
b/src/gallium/drivers/r600/r600_pipe.c
index 2680396c3d6..9e8501ff333 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -199,21 +199,21 @@ static struct pipe_context *r600_create_context(struct 
pipe_screen *screen,
 
rctx->append_fence = pipe_buffer_create(rctx->b.b.screen, 
PIPE_BIND_CUSTOM,
 PIPE_USAGE_DEFAULT, 
32);
break;
default:
R600_ERR("Unsupported chip class %d.\n", rctx->b.chip_class);
goto fail;
}
 
rctx->b.gfx.cs = ws->cs_create(rctx->b.ctx, RING_GFX,
-  r600_context_gfx_flush, rctx);
+  r600_context_gfx_flush, rctx, false);
rctx->b.gfx.flush = r600_context_gfx_flush;
 
rctx->allocator_fetch_shader =
u_suballocator_create(>b.b, 64 * 1024,
  0, PIPE_USAGE_DEFAULT, 0, FALSE);
if (!rctx->allocator_fetch_shader)
goto fail;
 
rctx->isa = calloc(1, sizeof(struct r600_isa));
if (!rctx->isa || r600_isa_init(rctx, rctx->isa))
diff --git a/src/gallium/drivers/r600/r600_pipe_common.c 
b/src/gallium/drivers/r600/r600_pipe_common.c
index e7c645611d7..19ba09ae82a 100644
--- a/src/gallium/drivers/r600/r600_pipe_common.c
+++ b/src/gallium/drivers/r600/r600_pipe_common.c
@@ -708,21 +708,21 @@ bool r600_common_context_init(struct r600_common_context 
*rctx,
if (!rctx->b.const_uploader)
return false;
 
rctx->ctx = rctx->ws->ctx_create(rctx->ws);
if (!rctx->ctx)
return false;
 
if (rscreen->info.num_sdma_rings && !(rscreen->debug_flags & 
DBG_NO_ASYNC_DMA)) {
rctx->dma.cs = rctx->ws->cs_create(rctx->ctx, RING_DMA,
   r600_flush_dma_ring,
-  rctx);
+  rctx, false);
rctx->dma.flush = r600_flush_dma_ring;
}
 
return true;
 }
 
 void r600_common_context_cleanup(struct r600_common_context *rctx)
 {
if (rctx->query_result_shader)
rctx->b.delete_compute_state(>b, 
rctx->query_result_shader);
diff --git a/src/gallium/drivers/r600/radeon_uvd.c 
b/src/gallium/drivers/r600/radeon_uvd.c
index ac4f40e66c0..495a93dc55a 100644
--- a/src/gallium/drivers/r600/radeon_uvd.c
+++ b/src/gallium/drivers/r600/radeon_uvd.c
@@ -1325,21 +1325,21 @@ struct pipe_video_codec *ruvd_create_decoder(struct 
pipe_context *context,
dec->base.decode_macroblock = ruvd_decode_macroblock;
dec->base.decode_bitstream = ruvd_decode_bitstream;
dec->base.end_frame = ruvd_end_frame;
dec->base.flush = ruvd_flush;
 
dec->stream_type = profile2stream_type(dec, info.family);
dec->set_dtb =

Re: [Mesa-dev] [PATCH] meson: link gallium nine with pthreads

2018-11-02 Thread Matt Turner

Reviewed-by: Matt Turner 

Probably fine to add a Tested-by from the reporter as well.

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

[Mesa-dev] [PATCH] meson: link gallium nine with pthreads

2018-11-02 Thread Dylan Baker

In some cases (not building with llvm, which automatically pulls in
pthreads) nine needs to be directly linked with pthreads. Fixes building
on x86 (32 bit) without llvm.

Distro bug: https://bugs.gentoo.org/670094
Fixes: 6b4c7047d57178d3362a710ad503057c6a582ca3
   ("meson: build gallium nine state_tracker")
---
 src/gallium/targets/d3dadapter9/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/targets/d3dadapter9/meson.build 
b/src/gallium/targets/d3dadapter9/meson.build
index bd05b4f9692..bc72b1110a0 100644
--- a/src/gallium/targets/d3dadapter9/meson.build
+++ b/src/gallium/targets/d3dadapter9/meson.build
@@ -53,7 +53,7 @@ libgallium_nine = shared_library(
 libswkmsdri,
   ],
   dependencies : [
-dep_selinux, dep_expat, dep_libdrm, dep_llvm,
+dep_selinux, dep_expat, dep_libdrm, dep_llvm, dep_thread,
 driver_swrast, driver_r300, driver_r600, driver_radeonsi, driver_nouveau,
 driver_i915, driver_svga,
   ],
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/2] egl/glvnd: correctly report errors when vendor cannot be found

2018-11-02 Thread Emil Velikov

From: Emil Velikov 

If the user provides an invalid display or device the ToVendor lookup
will fail.

In this case, the local [Mesa vendor] error code will be set. Thus on
sequential eglGetError(), the error will be EGL_SUCCESS.

To be more specific, GLVND remembers the last vendor and calls back
into it's eglGetError, although there's no guarantee to ever have had
one.

Piglit: tests/egl/spec/egl_ext_device_query
Fixes: ce562f9e3fa ("EGL: Implement the libglvnd interface for EGL (v3)")
Cc: Kyle Brenneman 
Cc: Eric Engestrom 
Signed-off-by: Emil Velikov 
---
 src/egl/main/egldispatchstubs.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/egl/main/egldispatchstubs.c b/src/egl/main/egldispatchstubs.c
index bfc3195c779..e39fd6197a6 100644
--- a/src/egl/main/egldispatchstubs.c
+++ b/src/egl/main/egldispatchstubs.c
@@ -54,9 +54,17 @@ static __eglMustCastToProperFunctionPointerType 
FetchVendorFunc(__EGLvendorInfo
 {
 __eglMustCastToProperFunctionPointerType func = NULL;
 
-if (vendor != NULL) {
-func = exports->fetchDispatchEntry(vendor, 
__EGL_DISPATCH_FUNC_INDICES[index]);
+if (vendor == NULL) {
+// XXX: How can we end here with EGL_SUCCESS?
+if (errorCode != EGL_SUCCESS) {
+// Since we have no vendor, the follow-up eglGetError() call will
+// end up using the GLVND error code. Set it here.
+exports->setEGLError(errorCode);
+}
+return NULL;
 }
+
+func = exports->fetchDispatchEntry(vendor, 
__EGL_DISPATCH_FUNC_INDICES[index]);
 if (func == NULL) {
 if (errorCode != EGL_SUCCESS) {
 _eglError(errorCode, __EGL_DISPATCH_FUNC_NAMES[index]);
-- 
2.19.1

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

[Mesa-dev] [PATCH 1/2] egl: add EGL_EXT_device_base entrypoints

2018-11-02 Thread Emil Velikov

From: Emil Velikov 

Otherwise, we get no entrypoint which seems to break the world.

Note: there's a follow-up fix needed to our GLVND code, to make piglit
happy.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108635
Fixes: 7552fcb7b9b ("egl: add base EGL_EXT_device_base implementation")
Reported-by: kyle.de...@mykolab.com
Cc: kyle.de...@mykolab.com
Cc: Eric Engestrom 
Signed-off-by: Emil Velikov 
---
Kyle, I'm not 100% sure it addresses the problem you're seeing.
It's the only possible issue that I could spot.
---
 src/egl/generate/eglFunctionList.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/egl/generate/eglFunctionList.py 
b/src/egl/generate/eglFunctionList.py
index fb5b3c30bdf..667704eb2cb 100644
--- a/src/egl/generate/eglFunctionList.py
+++ b/src/egl/generate/eglFunctionList.py
@@ -199,5 +199,12 @@ EGL_FUNCTIONS = (
 # EGL_EXT_image_dma_buf_import_modifiers
 _eglFunc("eglQueryDmaBufFormatsEXT", "display"),
 _eglFunc("eglQueryDmaBufModifiersEXT",   "display"),
+
+# EGL_EXT_device_base
+_eglFunc("eglQueryDeviceAttribEXT",  "device"),
+_eglFunc("eglQueryDeviceStringEXT",  "device"),
+_eglFunc("eglQueryDevicesEXT",   "none"),
+_eglFunc("eglQueryDisplayAttribEXT", "display"),
+
 )
 
-- 
2.19.1

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

[Mesa-dev] [Bug 108365] swr: segfault when running test case GLES2.functional.vertex_arrays.multiple_attributes.stride.3_float2_17_float2_17_float2_0

2018-11-02 Thread bugzilla-daemon

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

--- Comment #1 from Alok Hota  ---
Thanks for the details! I'll look into this.

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

Re: [Mesa-dev] [PATCH] docs: mention EXT_shader_implicit_conversions

2018-11-02 Thread Erik Faye-Lund

On Fri, 2018-11-02 at 15:57 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Cc: Erik Faye-Lund 
> Signed-off-by: Emil Velikov 
> ---
>  Ff| 2 ++
>  docs/relnotes/19.0.0.html | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  create mode 100644 Ff
> 
> diff --git a/Ff b/Ff
> new file mode 100644
> index 000..804e31ab99e
> --- /dev/null
> +++ b/Ff
> @@ -0,0 +1,2 @@
> +sdasdads
> +
> diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
> index 12fb9916e83..1b839b0a485 100644
> --- a/docs/relnotes/19.0.0.html
> +++ b/docs/relnotes/19.0.0.html
> @@ -39,7 +39,7 @@ TBD.
>  New features
>  
>  
> -TBD
> +GL_EXT_shader_implicit_conversions on all drivers (ES
> extension).
>  
>  
>  Bug fixes

Oh yes, good call.

Reviewed-by: Erik Faye-Lund 

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

Re: [Mesa-dev] [PATCH] docs: mention EXT_shader_implicit_conversions

2018-11-02 Thread Daniel Stone

On Fri, 2 Nov 2018 at 15:58, Emil Velikov  wrote:
>  Ff| 2 ++
>  docs/relnotes/19.0.0.html | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>  create mode 100644 Ff
>
> diff --git a/Ff b/Ff
> new file mode 100644
> index 000..804e31ab99e
> --- /dev/null
> +++ b/Ff
> @@ -0,0 +1,2 @@
> +sdasdads
> +

... ?

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

Re: [Mesa-dev] [PATCH 0/5] add support for EXT_shader_implicit_conversions

2018-11-02 Thread Erik Faye-Lund

On Fri, 2018-11-02 at 15:40 +, Emil Velikov wrote:
> On Tue, 30 Oct 2018 at 17:11, Erik Faye-Lund
>  wrote:
> > EXT_shader_implicit_conversions is a useful extension that adds
> > implicit
> > conversions to OpenGL ES 3.1. Since it's tested excensively in
> > dEQP, and
> > Mesa already has support for implicit conversions, it seems
> > reasonable to
> > allow for the extension. This ended up mostly as code-cleanups
> > anyway.
> > 
> > While enabling this, one bug was discorvered due to a failing dEQP
> > test
> > (see the last patch).
> > 
> > This makes 2068 dEQP-GLE31 tests go from NotSupported to Pass on
> > i965.
> > 
> > No piglit regressions observed.
> > 
> > Erik Faye-Lund (5):
> >   glsl: add has_implicit_conversions()-helper
> >   glsl: add has_implicit_uint_to_int_conversion()-helper
> >   glsl: fall back to inexact function-match
> >   mesa/glsl: add support for EXT_shader_implicit_conversions
> >   glsl: do not allow implicit casts of unsized array initializers
> > 
> Erik, I think we'd want the hole series minus the ES extension?
> 
> The issues fixed with the final patch affect GLSL 1.30-4.60 at least.
> Even if there's no desktop gl tests for it.
> 

Do you mean for the 18.3 release? If so, yes that might be good. The
last patch alone should also fix it, it shouldn't depend on the other
patches...

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

[Mesa-dev] [PATCH] docs: mention EXT_shader_implicit_conversions

2018-11-02 Thread Emil Velikov

From: Emil Velikov 

Cc: Erik Faye-Lund 
Signed-off-by: Emil Velikov 
---
 Ff| 2 ++
 docs/relnotes/19.0.0.html | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 Ff

diff --git a/Ff b/Ff
new file mode 100644
index 000..804e31ab99e
--- /dev/null
+++ b/Ff
@@ -0,0 +1,2 @@
+sdasdads
+
diff --git a/docs/relnotes/19.0.0.html b/docs/relnotes/19.0.0.html
index 12fb9916e83..1b839b0a485 100644
--- a/docs/relnotes/19.0.0.html
+++ b/docs/relnotes/19.0.0.html
@@ -39,7 +39,7 @@ TBD.
 New features
 
 
-TBD
+GL_EXT_shader_implicit_conversions on all drivers (ES extension).
 
 
 Bug fixes
-- 
2.19.1

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

[Mesa-dev] [AppVeyor] mesa master #9239 completed

2018-11-02 Thread AppVeyor



Build mesa 9239 completed



Commit 1c140470ef by Anuj Phogat on 10/24/2018 6:35 PM:

anv/icl: Disable prefetching of sampler state entries\n\nWA_1606682166:\nIncorrect TDL's SSP address shift in SARB for 16:6 & 18:8 modes.\nDisable the Sampler state prefetch functionality in the SARB by\nprogramming 0xB000[30] to '1'. This is to be done at boot time and\nthe feature must remain disabled permanently.\n\nSigned-off-by: Anuj Phogat \nReviewed-by: Kenneth Graunke 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 0/5] add support for EXT_shader_implicit_conversions

2018-11-02 Thread Emil Velikov

On Tue, 30 Oct 2018 at 17:11, Erik Faye-Lund
 wrote:
>
> EXT_shader_implicit_conversions is a useful extension that adds implicit
> conversions to OpenGL ES 3.1. Since it's tested excensively in dEQP, and
> Mesa already has support for implicit conversions, it seems reasonable to
> allow for the extension. This ended up mostly as code-cleanups anyway.
>
> While enabling this, one bug was discorvered due to a failing dEQP test
> (see the last patch).
>
> This makes 2068 dEQP-GLE31 tests go from NotSupported to Pass on i965.
>
> No piglit regressions observed.
>
> Erik Faye-Lund (5):
>   glsl: add has_implicit_conversions()-helper
>   glsl: add has_implicit_uint_to_int_conversion()-helper
>   glsl: fall back to inexact function-match
>   mesa/glsl: add support for EXT_shader_implicit_conversions
>   glsl: do not allow implicit casts of unsized array initializers
>
Erik, I think we'd want the hole series minus the ES extension?

The issues fixed with the final patch affect GLSL 1.30-4.60 at least.
Even if there's no desktop gl tests for it.

12f001f013c glsl: add has_implicit_conversions()-helper
e975c5b785f glsl: add has_implicit_uint_to_int_conversion()-helper
ecab2d6f148 glsl: fall back to inexact function-match
742dace8251 glsl: do not allow implicit casts of unsized array initializers

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

Re: [Mesa-dev] [PATCH] virgl/vtest-winsys: Use virgl version of bind flags

2018-11-02 Thread Emil Velikov

On Thu, 1 Nov 2018 at 09:50, Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> The bind flags defined by mesa/gallium might not always be in sync
> with the ones copied to virglrenderer/gallium. Therefore, use the
> flags defined in virgl like it is done for all the other calls to
> create resources.
>
> Signed-off-by: Gert Wollny 

This landed in master as b710680093a29d4f7dcde2e5a3ee61bba80404ca
sadly it missed the fixes/stable tag.
Fixes: b3b82fe8ea1 ("virgl/vtest: add vtest driver")

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

Re: [Mesa-dev] [PATCH] amd: remove support for LLVM 6.0

2018-11-02 Thread Samuel Pitoiset




On 11/2/18 3:58 PM, Michel Dänzer wrote:

On 2018-11-02 10:23 a.m., Samuel Pitoiset wrote:

User are encouraged to switch to LLVM 7.0 released in September 2018.


At least two major releases of LLVM should always be supported,
otherwise we force our downstreams and users to upgrade LLVM and Mesa in
lockstep.


The main problem is that LLVM 6 is buggy in many ways (GPU hangs, 
rendering issues). We have encouraged people to not use it since months, 
at least for RADV and DXVK users.


Also, I assume LLVM 8 to be released in March 2019 like mesa 19.0, so 
two major releases will be supported.






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

Re: [Mesa-dev] [PATCH v2 00/13] Engine parameter for instructions

2018-11-02 Thread Toni Lönnberg

On Fri, Nov 02, 2018 at 09:47:11AM -0500, Jason Ekstrand wrote:
> On Fri, Nov 2, 2018 at 6:05 AM Toni Lönnberg 
> wrote:
> 
> > On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> > > On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg 
> > > wrote:
> > >
> > > > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > > > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg <
> > toni.lonnb...@intel.com>
> > > > > wrote:
> > > > >
> > > > > > When we debug media or 3d+media workloads, we'd like to be able to
> > see
> > > > > > what is
> > > > > > in the aub dumps for those workloads. At the moment the decoder
> > can't
> > > > > > distinguish instructions which share the same opcode between the
> > render
> > > > > > and
> > > > > > video pipe, and thus aubinator outputs garbage on media
> > instructions.
> > > > > >
> > > > > > I was reluctant to make these changes into Mesa in the first place
> > > > since
> > > > > > the
> > > > > > work is related to media, not 3d, but as aubinator is now located
> > here,
> > > > > > here we
> > > > > > are.
> > > > > >
> > > > >
> > > > > That's fine.  It's fine if these changres live in mesa.
> > > > >
> > > > >
> > > > > > As far as I can see, these are the options:
> > > > > >
> > > > > > 1. Put these in Mesa as aubinator now resides here instead of IGT.
> > > > > >a) Put all instruction definitions in the current genxml files,
> > be
> > > > it
> > > > > > with a
> > > > > >   tag or an attribute, both methods have their advantages and
> > > > > > disadvantages.
> > > > > >b) Separate genxml files into common, render and video (and
> > > > blitter?)
> > > > > >
> > > > > > 2. Fork aubinator tools and related genxml infra to a completely
> > > > separate
> > > > > >project.
> > > > > >
> > > > > > If I have missed an option, feel free to suggest.
> > > > > >
> > > > >
> > > > > I wasn't suggesting we fork the tools and the XML.  I was just
> > wondering
> > > > > whether we wanted to do separate sections or an attribute.  I think
> > it
> > > > > should land in mesa either way.
> > > >
> > > > I'm not really a fan of any of the methods to be honest as each of them
> > > > have
> > > > disadvantages.
> > > >
> > > > Using the attribute makes it easier to add instructions which should be
> > > > handled
> > > > by a set of engines and not others but requires each instruction to
> > have
> > > > one,
> > > > except the common ones that are always shared which can be made to
> > default
> > > > to
> > > > all engines like in my version.
> > > >
> > > > The tag makes it easier to group things nicely but adds a new level to
> > the
> > > > xml
> > > > and requires duplicate definitions of the instruction if more than one
> > > > engine
> > > > uses that instruction but some engine doesn't.
> > > >
> > >
> > > Yeah, I think I'm convinced.
> > >
> > >
> > > > Splitting the genxml files into different ones for each engine also
> > > > organizes
> > > > the instructions nicely but has the same problem as the tag and
> > requires
> > > > loading
> > > > and parsing of multiple xml files.
> > > >
> > >
> > > I also experimented with splitting up the XML files.  There are times
> > when
> > > this is convenient but I'm not sure it's actually all that useful.  If we
> > > were to split it, we'd probably want to split it across other logical
> > lines
> > > like "MI" commands vs. "3DSTATE" commands and maybe a separate file for
> > > registers.  At least for now, we may as well keep it all together.
> >
> > Splitting the files seems convenient but coherence is important because we
> > don't
> > want to end up with hundreds of xml files just for the sake of splitting
> > stuff.
> > So I'd keep them as they are unless at some point we find a convincing
> > reason to
> > split them apart.
> >
> > > > To make things more icky, there are the instructions, like MI_FLUSH_DW,
> > > > which
> > > > are shared between engines but might use some of the bits for different
> > > > things.
> > > >
> > >
> > > Yeah.  When you mentioned this, I briefly considered the idea of putting
> > > engine tags on individual fields in that case.  That may be getting a bit
> > > nuts; I certainly don't want to recreate the insanity that is the bxml.
> >
> > I haven't checked how many instructions there are that are shared but have
> > some
> > bits enabled for some engines and not for others, can't be that many. If
> > there
> > were a lot of those, it might make more sense adding an engine-attribute
> > to
> > fields but as of now, that's a bit overkill. And I'm with you here about
> > bspec
> > :)
> >
> > > > In the end, I just went with how Lionel saw it because it was as good
> > of
> > > > an
> > > > option as any, and pretty straight forward to implement, so.. mehhh. I
> > > > don't
> > > > know if you'd prefer one way or the other.
> > > >
> > >
> > > Works for me.  I just wanted to make sure we'd thought it through before
> > > adding it.  I know I certainly hadn't

Re: [Mesa-dev] [PATCH] amd: remove support for LLVM 6.0

2018-11-02 Thread Michel Dänzer

On 2018-11-02 10:23 a.m., Samuel Pitoiset wrote:
> User are encouraged to switch to LLVM 7.0 released in September 2018.

At least two major releases of LLVM should always be supported,
otherwise we force our downstreams and users to upgrade LLVM and Mesa in
lockstep.


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

Re: [Mesa-dev] [PATCH] android: radv: add libmesa_git_sha1 static dependency

2018-11-02 Thread Eric Engestrom

On Friday, 2018-11-02 13:38:53 +0100, Mauro Rossi wrote:
> Hi all,
> could somebody provide Reviewed-by in order to apply in mesa-dev and
> avoid trivial building error?

Not an expert on Android.mk, but this looks reasonable, and adding that
dep is definitely right, so:
Reviewed-by: Eric Engestrom 

> Thanks
> 
> Mauro
> On Tue, Oct 30, 2018 at 10:42 PM Mauro Rossi  wrote:
> >
> > libmesa_git_sha1 whole static dependency is added to get git_sha1.h header
> > and avoid following building error:
> >
> > external/mesa/src/amd/vulkan/radv_device.c:46:10:
> > fatal error: 'git_sha1.h' file not found
> >  ^
> > 1 error generated.
> >
> > Fixes: 9d40ec2cf6 ("radv: Add support for VK_KHR_driver_properties.")
> > Signed-off-by: Mauro Rossi 
> > ---
> >  src/amd/vulkan/Android.mk | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
> > index 51b03561fa..9574bf54e5 100644
> > --- a/src/amd/vulkan/Android.mk
> > +++ b/src/amd/vulkan/Android.mk
> > @@ -74,7 +74,8 @@ LOCAL_C_INCLUDES := \
> > $(call 
> > generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
> >
> >  LOCAL_WHOLE_STATIC_LIBRARIES := \
> > -   libmesa_vulkan_util
> > +   libmesa_vulkan_util \
> > +   libmesa_git_sha1
> >
> >  LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.c
> >  LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.h
> > --
> > 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 v2 00/13] Engine parameter for instructions

2018-11-02 Thread Jason Ekstrand

On Fri, Nov 2, 2018 at 6:05 AM Toni Lönnberg 
wrote:

> On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> > On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg 
> > wrote:
> >
> > > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg <
> toni.lonnb...@intel.com>
> > > > wrote:
> > > >
> > > > > When we debug media or 3d+media workloads, we'd like to be able to
> see
> > > > > what is
> > > > > in the aub dumps for those workloads. At the moment the decoder
> can't
> > > > > distinguish instructions which share the same opcode between the
> render
> > > > > and
> > > > > video pipe, and thus aubinator outputs garbage on media
> instructions.
> > > > >
> > > > > I was reluctant to make these changes into Mesa in the first place
> > > since
> > > > > the
> > > > > work is related to media, not 3d, but as aubinator is now located
> here,
> > > > > here we
> > > > > are.
> > > > >
> > > >
> > > > That's fine.  It's fine if these changres live in mesa.
> > > >
> > > >
> > > > > As far as I can see, these are the options:
> > > > >
> > > > > 1. Put these in Mesa as aubinator now resides here instead of IGT.
> > > > >a) Put all instruction definitions in the current genxml files,
> be
> > > it
> > > > > with a
> > > > >   tag or an attribute, both methods have their advantages and
> > > > > disadvantages.
> > > > >b) Separate genxml files into common, render and video (and
> > > blitter?)
> > > > >
> > > > > 2. Fork aubinator tools and related genxml infra to a completely
> > > separate
> > > > >project.
> > > > >
> > > > > If I have missed an option, feel free to suggest.
> > > > >
> > > >
> > > > I wasn't suggesting we fork the tools and the XML.  I was just
> wondering
> > > > whether we wanted to do separate sections or an attribute.  I think
> it
> > > > should land in mesa either way.
> > >
> > > I'm not really a fan of any of the methods to be honest as each of them
> > > have
> > > disadvantages.
> > >
> > > Using the attribute makes it easier to add instructions which should be
> > > handled
> > > by a set of engines and not others but requires each instruction to
> have
> > > one,
> > > except the common ones that are always shared which can be made to
> default
> > > to
> > > all engines like in my version.
> > >
> > > The tag makes it easier to group things nicely but adds a new level to
> the
> > > xml
> > > and requires duplicate definitions of the instruction if more than one
> > > engine
> > > uses that instruction but some engine doesn't.
> > >
> >
> > Yeah, I think I'm convinced.
> >
> >
> > > Splitting the genxml files into different ones for each engine also
> > > organizes
> > > the instructions nicely but has the same problem as the tag and
> requires
> > > loading
> > > and parsing of multiple xml files.
> > >
> >
> > I also experimented with splitting up the XML files.  There are times
> when
> > this is convenient but I'm not sure it's actually all that useful.  If we
> > were to split it, we'd probably want to split it across other logical
> lines
> > like "MI" commands vs. "3DSTATE" commands and maybe a separate file for
> > registers.  At least for now, we may as well keep it all together.
>
> Splitting the files seems convenient but coherence is important because we
> don't
> want to end up with hundreds of xml files just for the sake of splitting
> stuff.
> So I'd keep them as they are unless at some point we find a convincing
> reason to
> split them apart.
>
> > > To make things more icky, there are the instructions, like MI_FLUSH_DW,
> > > which
> > > are shared between engines but might use some of the bits for different
> > > things.
> > >
> >
> > Yeah.  When you mentioned this, I briefly considered the idea of putting
> > engine tags on individual fields in that case.  That may be getting a bit
> > nuts; I certainly don't want to recreate the insanity that is the bxml.
>
> I haven't checked how many instructions there are that are shared but have
> some
> bits enabled for some engines and not for others, can't be that many. If
> there
> were a lot of those, it might make more sense adding an engine-attribute
> to
> fields but as of now, that's a bit overkill. And I'm with you here about
> bspec
> :)
>
> > > In the end, I just went with how Lionel saw it because it was as good
> of
> > > an
> > > option as any, and pretty straight forward to implement, so.. mehhh. I
> > > don't
> > > know if you'd prefer one way or the other.
> > >
> >
> > Works for me.  I just wanted to make sure we'd thought it through before
> > adding it.  I know I certainly hadn't given it all that much thought in
> my
> > brief experiments.  I think the attributes is the best solution for now.
>
> So we're good to go with the reviews?
>

Yes, if I understand the question correctly.  That doesn't mean I have
reviewed it; I haven't really looked at the patches in any detail
whatsoever.  It does mean that I'm happy

Re: [Mesa-dev] [PATCH v2] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Jason Ekstrand

LGTM

On Fri, Nov 2, 2018 at 8:37 AM Timothy Arceri  wrote:

> We cannot use nir_build_alu() to create the new alu as it has no
> way to know how many components of the src we will use. This
> results in it guessing the max number of components from one of
> its inputs.
>
> Fixes the following CTS tests:
>
>
> dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
>
> dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
>
> dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
>
> dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert
>
> V2: use nir_src_for_ssa() in clone
>
> Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down some
> alu chains")
> ---
>  src/compiler/nir/nir_opt_if.c | 31 ++-
>  1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> index ed93cac9ce9..8a971c43f24 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
> @@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor cursor,
> bool *value)
> }
>  }
>
> +static nir_ssa_def *
> +clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
> +   nir_ssa_def **src_defs)
> +{
> +   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
> +   nalu->exact = alu->exact;
> +
> +   nir_ssa_dest_init(>instr, >dest.dest,
> + alu->dest.dest.ssa.num_components,
> + alu->dest.dest.ssa.bit_size, alu->dest.dest.ssa.name
> );
> +
> +   nalu->dest.saturate = alu->dest.saturate;
> +   nalu->dest.write_mask = alu->dest.write_mask;
> +
> +   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
> +  assert(alu->src[i].src.is_ssa);
> +  nalu->src[i].src = nir_src_for_ssa(src_defs[i]);
> +  nalu->src[i].negate = alu->src[i].negate;
> +  nalu->src[i].abs = alu->src[i].abs;
> +  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
> + sizeof(nalu->src[i].swizzle));
> +   }
> +
> +   nir_builder_instr_insert(b, >instr);
> +
> +   return >dest.dest.ssa;;
> +}
> +
>  /*
>   * This propagates if condition evaluation down the chain of some alu
>   * instructions. For example by checking the use of some of the following
> alu
> @@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if *nif,
> nir_src *use_src,
>   def[i] = alu->src[i].src.ssa;
>}
> }
> -   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2],
> def[3]);
> +
> +   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);
>
> /* Rewrite use to use new alu instruction */
> nir_src new_src = nir_src_for_ssa(nalu);
> --
> 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

[Mesa-dev] [AppVeyor] mesa master #9238 failed

2018-11-02 Thread AppVeyor




Build mesa 9238 failed


Commit 9cab8ccd6c by Jan Vesely on 11/1/2018 6:30 PM:

amd: Make vgpr-spilling depend on llvm version\n\nThe option was removed in LLVM r345763\n\nSigned-off-by: Jan Vesely \nReviewed-by: Marek Olšák \nReviewed-by: Samuel Pitoiset \nTested-by: Dieter Nützel 


Configure your notification preferences

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

[Mesa-dev] [Bug 108636] test_optpass has use after free bug, failing with memory testing tools like address sanitizer

2018-11-02 Thread bugzilla-daemon

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

Bug ID: 108636
   Summary: test_optpass has use after free bug, failing with
memory testing tools like address sanitizer
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: minor
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ha...@hboeck.de
QA Contact: intel-3d-b...@lists.freedesktop.org

Created attachment 142340
  --> https://bugs.freedesktop.org/attachment.cgi?id=142340=edit
patch to fix use after free in test_optpass.

When compiling mesa with address sanitizer (-fsanitize=address) and running the
test suite a use after free bug is exposed in test_optpass.cpp.

This is the code:

   ralloc_free(state);
   ralloc_free(shader);

   return state->error;

This is obviously not correct. First state is free'd and then state->error is
used as the return value.

Given this is only a test this is not severe, yet it still should be fixed so
mesa can easily be tested with address sanitizer or other memory safety check
tools.

See attached patch (works on both git and 18.2.4), I'm saving state->error to a
variable and then returning that.

-- 
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 108636] test_optpass has use after free bug, failing with memory testing tools like address sanitizer

2018-11-02 Thread bugzilla-daemon

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

--- Comment #1 from Hanno Böck  ---
Created attachment 142341
  --> https://bugs.freedesktop.org/attachment.cgi?id=142341=edit
stack trace from asan

-- 
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 00/31] nir: Use a 1-bit data type for booleans

2018-11-02 Thread Jason Ekstrand

Bump

On Mon, Oct 22, 2018 at 5:14 PM Jason Ekstrand  wrote:

> This is something that Connor and I have talked about quite a bit over the
> last couple of months.  The core idea is to replace NIR's current 32-bit
> 0/-1 D3D10-style booleans with a 1-bit data type.  All in all, I think it
> worked out pretty well though I really don't like the proliferation of
> 32-bit comparison opcodes we now have kicking around for i965.
>
> Why?  No hardware really has a 1-bit type, right?  Well, sort of...  AMD
> actually uses 64-bit scalars for booleans with one bit per invocation.
> However, most hardware such as Intel uses some other larger value for
> booleans.  The real benefit of 1-bit booleans and requiring a lowering pass
> is that you can do somewhat custom lowering (like AMD wants) and your
> lowering pass can always tell in an instant if a value is a boolean based
> on the bit size.  As can be seen in the last patch, this makes it really
> easy to implement a bool -> float lowering pass for hardware that doesn't
> have real integers where NIR's current booleans are actually rather
> painful.
>
> On Intel, the situation is a bit more complicated.  It's tempting to say
> that we have 32-bit D3D10 booleans.  However, they're not really D3D10
> booleans on gen4-5 because the top 31 bits are undefined garbage and, while
> iand, ior, ixor, and inot operations work, you have to iand with 1 at the
> last minute to clear off all that garbage.  Also, on all generations, a
> comparison of two N-bit values results in an N-bit boolean, not a 32-bit
> bool.  This has caused the Igalia folks no end of trouble as they've been
> working on native 8 and 16-bit support.  If, instead, we have a 1-bit bool
> with a lowering pass and we can lower to whatever we want, then we could
> lower to a set of comparison opcodes that return the same bit-size as they
> compare and it would match GEN hardware much better.
>
> But what about performance?  Aren't there all sorts of neat tricks we can
> do with D3D10 booleans like b & 1.0f for b2f?  As it turns out, not really;
> that's about the only one.  There is some small advantage when optimizing
> shaders that come from D3D if your native representation of booleans
> matches that of D3D.  However, penultimate patch in this series adds a few
> small optimizations that get us to actually better than we were before.
> With the entire series, shader-db on Kaby Lak looks like this:
>
> total instructions in shared programs: 15084098 -> 14988578 (-0.63%)
> instructions in affected programs: 1321114 -> 1225594 (-7.23%)
> helped: 2340
> HURT: 23
>
> total cycles in shared programs: 369790134 -> 359798399 (-2.70%)
> cycles in affected programs: 134085452 -> 124093717 (-7.45%)
> helped: 2149
> HURT: 720
>
> total loops in shared programs: 4393 -> 4393 (0.00%)
> loops in affected programs: 0 -> 0
> helped: 0
> HURT: 0
>
> total spills in shared programs: 10158 -> 10051 (-1.05%)
> spills in affected programs: 1429 -> 1322 (-7.49%)
> helped: 8
> HURT: 15
>
> total fills in shared programs: 22105 -> 21720 (-1.74%)
> fills in affected programs: 2853 -> 2468 (-13.49%)
> helped: 12
> HURT: 15
>
> How about ease of use?  Are they a pain to deal with?  Yes, adding support
> for 1-bit types was a bit awkward in a few places but most of it was
> dealing with all the places where we have 32-bit booleans baked into
> assumptions.  Getting rid of that baking in solves the problem and also
> makes the whole IR more future-proof.
>
> All in all, I'd say I'm pretty happy with it.  However, I'd like other
> people (particularly the AMD folks) to play with it a bit and verify that
> it solves their problems as well.  Also, I added a lowering pass and tried
> to turn it on in everyone's driver but may not have put it in the right
> spot.  Please double-check my work.  For those wishing to take a look, you
> can also find the entire series on my gitlab here:
>
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/review/nir-1-bit-bool
>
> Please review!
>
> --Jason
>
> Cc: Connor Abbott 
> Cc: Timothy Arceri 
> Cc: Eric Anholt 
> Cc: Rob Clark 
> Cc: Karol Herbst 
> Cc: Bas Nieuwenhuizen 
> Cc: Alyssa Rosenzweig 
>
>
> Jason Ekstrand (31):
>   nir/validate: Print when the validation failed
>   nir/constant_folding: Add an unreachable to a switch
>   nir/constant_folding: Use nir_src_as_bool for discard_if
>   nir/builder: Add a nir_imm_true/false helpers
>   nir/builder: Handle 16-bit floats in nir_imm_floatN_t
>   nir/search: Use nir_builder
>   nir/opt_if: Rework condition propagation
>   nir/system_values: Use the bit size from the load_deref
>   glsl/nir: Use i2b instead of ine for fixing UBO/SSBO booleans
>   nir/prog: Use nir_bany in kill handling
>   spirv: Use the right bit-size for spec constant ops
>   spirv: Initialize subgroup destinations with the destination type
>   intel/nir: Use the OPT macro for more passes
>

[Mesa-dev] [PATCH v2] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Timothy Arceri

We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.

Fixes the following CTS tests:

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert

V2: use nir_src_for_ssa() in clone

Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down some alu 
chains")
---
 src/compiler/nir/nir_opt_if.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index ed93cac9ce9..8a971c43f24 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor cursor, bool 
*value)
}
 }
 
+static nir_ssa_def *
+clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
+   nir_ssa_def **src_defs)
+{
+   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
+   nalu->exact = alu->exact;
+
+   nir_ssa_dest_init(>instr, >dest.dest,
+ alu->dest.dest.ssa.num_components,
+ alu->dest.dest.ssa.bit_size, alu->dest.dest.ssa.name);
+
+   nalu->dest.saturate = alu->dest.saturate;
+   nalu->dest.write_mask = alu->dest.write_mask;
+
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  assert(alu->src[i].src.is_ssa);
+  nalu->src[i].src = nir_src_for_ssa(src_defs[i]);
+  nalu->src[i].negate = alu->src[i].negate;
+  nalu->src[i].abs = alu->src[i].abs;
+  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
+ sizeof(nalu->src[i].swizzle));
+   }
+
+   nir_builder_instr_insert(b, >instr);
+
+   return >dest.dest.ssa;;
+}
+
 /*
  * This propagates if condition evaluation down the chain of some alu
  * instructions. For example by checking the use of some of the following alu
@@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  def[i] = alu->src[i].src.ssa;
   }
}
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);
+
+   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);
 
/* Rewrite use to use new alu instruction */
nir_src new_src = nir_src_for_ssa(nalu);
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Jason Ekstrand


On November 2, 2018 08:20:34 Timothy Arceri  wrote:


On 2/11/18 11:52 pm, Jason Ekstrand wrote:

On November 2, 2018 06:25:59 Timothy Arceri  wrote:


We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.




Fixes the following CTS tests:




dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag


dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom


dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc


dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert






Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down
some alu chains")
---




I'm running this in Intel CI currently but it hasn't been giving me
proper results
today so fingers crossed.




src/compiler/nir/nir_opt_if.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)




diff --git a/src/compiler/nir/nir_opt_if.c
b/src/compiler/nir/nir_opt_if.c
index ed93cac9ce9..1eb49a64aba 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor
cursor, bool *value)
  }
}


+static nir_ssa_def *
+clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
+   nir_ssa_def **src_defs)
+{
+   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
+   nalu->exact = alu->exact;
+
+   nir_ssa_dest_init(>instr, >dest.dest,
+ alu->dest.dest.ssa.num_components,
+ alu->dest.dest.ssa.bit_size,
alu->dest.dest.ssa.name);
+
+   nalu->dest.saturate = alu->dest.saturate;
+   nalu->dest.write_mask = alu->dest.write_mask;


Somewhere, we should copy over alu->exact


Yeah its at the very top :)


Drp...






+
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  nalu->src[i].src.is_ssa = alu->src[i].src.is_ssa;


I think it would be better to assert here


+  nalu->src[i].src.ssa = src_defs[i];


And use src_for_ssa here


Yeah makes sense will change.


Cool. Rb then.






+  nalu->src[i].negate = alu->src[i].negate;
+  nalu->src[i].abs = alu->src[i].abs;
+  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
+ sizeof(nalu->src[i].swizzle));
+   }
+
+   nir_builder_instr_insert(b, >instr);
+
+   return >dest.dest.ssa;;
+}
+
/*
* This propagates if condition evaluation down the chain of some alu
* instructions. For example by checking the use of some of the
following alu
@@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if
*nif, nir_src *use_src,
def[i] = alu->src[i].src.ssa;
 }
  }
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1],
def[2], def[3]);
+
+   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);


  /* Rewrite use to use new alu instruction */
  nir_src new_src = nir_src_for_ssa(nalu);
--
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] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Timothy Arceri


On 2/11/18 11:52 pm, Jason Ekstrand wrote:

On November 2, 2018 06:25:59 Timothy Arceri  wrote:


We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.


Fixes the following CTS tests:


dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag 

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom 

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc 

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert 




Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down 
some alu chains")

---


I'm running this in Intel CI currently but it hasn't been giving me 
proper results

today so fingers crossed.


src/compiler/nir/nir_opt_if.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)


diff --git a/src/compiler/nir/nir_opt_if.c 
b/src/compiler/nir/nir_opt_if.c

index ed93cac9ce9..1eb49a64aba 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor 
cursor, bool *value)

   }
}

+static nir_ssa_def *
+clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
+   nir_ssa_def **src_defs)
+{
+   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
+   nalu->exact = alu->exact;
+
+   nir_ssa_dest_init(>instr, >dest.dest,
+ alu->dest.dest.ssa.num_components,
+ alu->dest.dest.ssa.bit_size, 
alu->dest.dest.ssa.name);

+
+   nalu->dest.saturate = alu->dest.saturate;
+   nalu->dest.write_mask = alu->dest.write_mask;


Somewhere, we should copy over alu->exact


Yeah its at the very top :)




+
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  nalu->src[i].src.is_ssa = alu->src[i].src.is_ssa;


I think it would be better to assert here


+  nalu->src[i].src.ssa = src_defs[i];


And use src_for_ssa here


Yeah makes sense will change.




+  nalu->src[i].negate = alu->src[i].negate;
+  nalu->src[i].abs = alu->src[i].abs;
+  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
+ sizeof(nalu->src[i].swizzle));
+   }
+
+   nir_builder_instr_insert(b, >instr);
+
+   return >dest.dest.ssa;;
+}
+
/*
 * This propagates if condition evaluation down the chain of some alu
 * instructions. For example by checking the use of some of the 
following alu
@@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if 
*nif, nir_src *use_src,

 def[i] = alu->src[i].src.ssa;
  }
   }
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], 
def[2], def[3]);

+
+   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);

   /* Rewrite use to use new alu instruction */
   nir_src new_src = nir_src_for_ssa(nalu);
--
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

[Mesa-dev] [Bug 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

  Component|EGL |XWayland
   Assignee|mesa-dev@lists.freedesktop. |wayland-bugs@lists.freedesk
   |org |top.org
 QA Contact|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
   |org |
Product|Mesa|Wayland
Version|git |unspecified

-- 
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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

--- Comment #5 from kyle.de...@mykolab.com ---
On a whim, I tried to start Sway, but XWayland also fails to start...

-- 
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] egl: Fix eglentrypoint.h sort order.

2018-11-02 Thread Emil Velikov

On Thu, 1 Nov 2018 at 16:54, Eric Engestrom  wrote:
>
> On Thursday, 2018-11-01 17:37:57 +0100, Mathias Fröhlich wrote:
> > Hi,
> >
> > On Thursday, 1 November 2018 17:28:48 CET Eric Engestrom wrote:
> > > Pushed now, but travis still fails:
> > > https://travis-ci.org/mesa3d/mesa/jobs/449405406
> > >
> > > I'm really confused here, because the LANG is now fixed, so it shouldn't
> > > behave differently on different environments?
> > >
> > > If anyone has any clue, I'm all ears :)
> >
> > May be LC_ALL=C like the sort man page claims or as Michel meant,
> > LC_COLLATE=C which is finally the last specific variable to
> > overwrite the behavior?
>
> Yeah Michel suggested LC_ALL on irc, which I just tested and it works
> even on travis; sending the patch in a minute.
>
All my machines have been using LANG=en_GB.UTF-8 for 5+ years.

Thanks for addressing this gents.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

--- Comment #4 from kyle.de...@mykolab.com ---
Hmmm.

I'll post this on the KDE side and see what they think.

-- 
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] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Jason Ekstrand


On November 2, 2018 06:25:59 Timothy Arceri  wrote:


We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.


Fixes the following CTS tests:


dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert


Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down some alu 
chains")

---


I'm running this in Intel CI currently but it hasn't been giving me proper 
results

today so fingers crossed.


src/compiler/nir/nir_opt_if.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)


diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index ed93cac9ce9..1eb49a64aba 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor cursor, 
bool *value)

   }
}

+static nir_ssa_def *
+clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
+   nir_ssa_def **src_defs)
+{
+   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
+   nalu->exact = alu->exact;
+
+   nir_ssa_dest_init(>instr, >dest.dest,
+ alu->dest.dest.ssa.num_components,
+ alu->dest.dest.ssa.bit_size, alu->dest.dest.ssa.name);
+
+   nalu->dest.saturate = alu->dest.saturate;
+   nalu->dest.write_mask = alu->dest.write_mask;


Somewhere, we should copy over alu->exact


+
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  nalu->src[i].src.is_ssa = alu->src[i].src.is_ssa;


I think it would be better to assert here


+  nalu->src[i].src.ssa = src_defs[i];


And use src_for_ssa here


+  nalu->src[i].negate = alu->src[i].negate;
+  nalu->src[i].abs = alu->src[i].abs;
+  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
+ sizeof(nalu->src[i].swizzle));
+   }
+
+   nir_builder_instr_insert(b, >instr);
+
+   return >dest.dest.ssa;;
+}
+
/*
 * This propagates if condition evaluation down the chain of some alu
 * instructions. For example by checking the use of some of the following alu
@@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,

 def[i] = alu->src[i].src.ssa;
  }
   }
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);

+
+   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);

   /* Rewrite use to use new alu instruction */
   nir_src new_src = nir_src_for_ssa(nalu);
--
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

[Mesa-dev] [PATCH] radv: remove useless sync after copying query results with compute

2018-11-02 Thread Samuel Pitoiset

The spec says:
   "vkCmdCopyQueryPoolResults is considered to be a transfer
operation, and its writes to buffer memory must be synchronized
using VK_PIPELINE_STAGE_TRANSFER_BIT and VK_ACCESS_TRANSFER_WRITE_BIT
before using the results."

VK_PIPELINE_STAGE_TRANSFER_BIT will wait for compute to be idle,
while VK_ACCESS_TRANSFER_WRITE_BIT will invalidate both L1 vector
caches and L2. So, it's useless to set those flags internally.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_query.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 57ea22fb84..4153dc2f67 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -755,10 +755,6 @@ static void radv_query_shader(struct radv_cmd_buffer 
*cmd_buffer,
 
radv_unaligned_dispatch(cmd_buffer, count, 1, 1);
 
-   cmd_buffer->state.flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2 |
-   RADV_CMD_FLAG_INV_VMEM_L1 |
-   RADV_CMD_FLAG_CS_PARTIAL_FLUSH;
-
radv_meta_restore(_state, cmd_buffer);
 }
 
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH] android: radv: add libmesa_git_sha1 static dependency

2018-11-02 Thread Mauro Rossi

Hi all,
could somebody provide Reviewed-by in order to apply in mesa-dev and
avoid trivial building error?
Thanks

Mauro
On Tue, Oct 30, 2018 at 10:42 PM Mauro Rossi  wrote:
>
> libmesa_git_sha1 whole static dependency is added to get git_sha1.h header
> and avoid following building error:
>
> external/mesa/src/amd/vulkan/radv_device.c:46:10:
> fatal error: 'git_sha1.h' file not found
>  ^
> 1 error generated.
>
> Fixes: 9d40ec2cf6 ("radv: Add support for VK_KHR_driver_properties.")
> Signed-off-by: Mauro Rossi 
> ---
>  src/amd/vulkan/Android.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
> index 51b03561fa..9574bf54e5 100644
> --- a/src/amd/vulkan/Android.mk
> +++ b/src/amd/vulkan/Android.mk
> @@ -74,7 +74,8 @@ LOCAL_C_INCLUDES := \
> $(call 
> generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
>
>  LOCAL_WHOLE_STATIC_LIBRARIES := \
> -   libmesa_vulkan_util
> +   libmesa_vulkan_util \
> +   libmesa_git_sha1
>
>  LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.c
>  LOCAL_GENERATED_SOURCES += $(intermediates)/radv_entrypoints.h
> --
> 2.19.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

Tapani Pälli  changed:

   What|Removed |Added

 CC||lem...@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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

--- Comment #3 from Tapani Pälli  ---
Since this commit fixed failing dEQP and Piglit tests I'm assuming there is
something wrong in either kwin or XWayland. Perhaps with this commit it starts
to actually utilize EGL_EXT_device_{base,enumeration,query} but fails.

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

[Mesa-dev] [PATCH] nir: fix condition propagation when src has a swizzle

2018-11-02 Thread Timothy Arceri

We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.

Fixes the following CTS tests:

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert

Fixes: 2975422ceb6c ("nir: propagates if condition evaluation down some alu 
chains")
---

I'm running this in Intel CI currently but it hasn't been giving me proper 
results
today so fingers crossed.

 src/compiler/nir/nir_opt_if.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index ed93cac9ce9..1eb49a64aba 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -391,6 +391,34 @@ evaluate_if_condition(nir_if *nif, nir_cursor cursor, bool 
*value)
}
 }
 
+static nir_ssa_def *
+clone_alu_and_replace_src_defs(nir_builder *b, const nir_alu_instr *alu,
+   nir_ssa_def **src_defs)
+{
+   nir_alu_instr *nalu = nir_alu_instr_create(b->shader, alu->op);
+   nalu->exact = alu->exact;
+
+   nir_ssa_dest_init(>instr, >dest.dest,
+ alu->dest.dest.ssa.num_components,
+ alu->dest.dest.ssa.bit_size, alu->dest.dest.ssa.name);
+
+   nalu->dest.saturate = alu->dest.saturate;
+   nalu->dest.write_mask = alu->dest.write_mask;
+
+   for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
+  nalu->src[i].src.is_ssa = alu->src[i].src.is_ssa;
+  nalu->src[i].src.ssa = src_defs[i];
+  nalu->src[i].negate = alu->src[i].negate;
+  nalu->src[i].abs = alu->src[i].abs;
+  memcpy(nalu->src[i].swizzle, alu->src[i].swizzle,
+ sizeof(nalu->src[i].swizzle));
+   }
+
+   nir_builder_instr_insert(b, >instr);
+
+   return >dest.dest.ssa;;
+}
+
 /*
  * This propagates if condition evaluation down the chain of some alu
  * instructions. For example by checking the use of some of the following alu
@@ -456,7 +484,8 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  def[i] = alu->src[i].src.ssa;
   }
}
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);
+
+   nir_ssa_def *nalu = clone_alu_and_replace_src_defs(b, alu, def);
 
/* Rewrite use to use new alu instruction */
nir_src new_src = nir_src_for_ssa(nalu);
-- 
2.19.1

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

[Mesa-dev] [Bug 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

--- Comment #2 from kyle.de...@mykolab.com ---
Narrowed it down to XWayland.

Seems like it doesn't like that order swap...

-- 
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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes XWayland to segfault

2018-11-02 Thread bugzilla-daemon

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

Summary|68dc591af16ebb36814e4c187e4 |68dc591af16ebb36814e4c187e4
   |998948103c99c causes|998948103c99c causes
   |"startplasmacompositor" to  |XWayland to segfault
   |segfault|

-- 
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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes "startplasmacompositor" to segfault

2018-11-02 Thread bugzilla-daemon

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

-- 
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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes "startplasmacompositor" to segfault

2018-11-02 Thread bugzilla-daemon

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

kyle.de...@mykolab.com changed:

   What|Removed |Added

   Severity|normal  |major

-- 
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 00/13] Engine parameter for instructions

2018-11-02 Thread Toni Lönnberg

On Fri, Nov 02, 2018 at 12:09:54AM -0500, Jason Ekstrand wrote:
> On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg 
> wrote:
> 
> > On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg 
> > > wrote:
> > >
> > > > When we debug media or 3d+media workloads, we'd like to be able to see
> > > > what is
> > > > in the aub dumps for those workloads. At the moment the decoder can't
> > > > distinguish instructions which share the same opcode between the render
> > > > and
> > > > video pipe, and thus aubinator outputs garbage on media instructions.
> > > >
> > > > I was reluctant to make these changes into Mesa in the first place
> > since
> > > > the
> > > > work is related to media, not 3d, but as aubinator is now located here,
> > > > here we
> > > > are.
> > > >
> > >
> > > That's fine.  It's fine if these changres live in mesa.
> > >
> > >
> > > > As far as I can see, these are the options:
> > > >
> > > > 1. Put these in Mesa as aubinator now resides here instead of IGT.
> > > >a) Put all instruction definitions in the current genxml files, be
> > it
> > > > with a
> > > >   tag or an attribute, both methods have their advantages and
> > > > disadvantages.
> > > >b) Separate genxml files into common, render and video (and
> > blitter?)
> > > >
> > > > 2. Fork aubinator tools and related genxml infra to a completely
> > separate
> > > >project.
> > > >
> > > > If I have missed an option, feel free to suggest.
> > > >
> > >
> > > I wasn't suggesting we fork the tools and the XML.  I was just wondering
> > > whether we wanted to do separate sections or an attribute.  I think it
> > > should land in mesa either way.
> >
> > I'm not really a fan of any of the methods to be honest as each of them
> > have
> > disadvantages.
> >
> > Using the attribute makes it easier to add instructions which should be
> > handled
> > by a set of engines and not others but requires each instruction to have
> > one,
> > except the common ones that are always shared which can be made to default
> > to
> > all engines like in my version.
> >
> > The tag makes it easier to group things nicely but adds a new level to the
> > xml
> > and requires duplicate definitions of the instruction if more than one
> > engine
> > uses that instruction but some engine doesn't.
> >
> 
> Yeah, I think I'm convinced.
> 
> 
> > Splitting the genxml files into different ones for each engine also
> > organizes
> > the instructions nicely but has the same problem as the tag and requires
> > loading
> > and parsing of multiple xml files.
> >
> 
> I also experimented with splitting up the XML files.  There are times when
> this is convenient but I'm not sure it's actually all that useful.  If we
> were to split it, we'd probably want to split it across other logical lines
> like "MI" commands vs. "3DSTATE" commands and maybe a separate file for
> registers.  At least for now, we may as well keep it all together.

Splitting the files seems convenient but coherence is important because we 
don't 
want to end up with hundreds of xml files just for the sake of splitting stuff. 
So I'd keep them as they are unless at some point we find a convincing reason 
to 
split them apart.

> > To make things more icky, there are the instructions, like MI_FLUSH_DW,
> > which
> > are shared between engines but might use some of the bits for different
> > things.
> >
> 
> Yeah.  When you mentioned this, I briefly considered the idea of putting
> engine tags on individual fields in that case.  That may be getting a bit
> nuts; I certainly don't want to recreate the insanity that is the bxml.

I haven't checked how many instructions there are that are shared but have some 
bits enabled for some engines and not for others, can't be that many. If there 
were a lot of those, it might make more sense adding an engine-attribute to 
fields but as of now, that's a bit overkill. And I'm with you here about bspec 
:)

> > In the end, I just went with how Lionel saw it because it was as good of
> > an
> > option as any, and pretty straight forward to implement, so.. mehhh. I
> > don't
> > know if you'd prefer one way or the other.
> >
> 
> Works for me.  I just wanted to make sure we'd thought it through before
> adding it.  I know I certainly hadn't given it all that much thought in my
> brief experiments.  I think the attributes is the best solution for now.

So we're good to go with the reviews?

> --Jason
> 
> 
> 
> > >
> > > --Jason
> > >
> > >
> > > > On Wed, Oct 31, 2018 at 09:20:39AM -0500, Jason Ekstrand wrote:
> > > > > Toni,
> > > > >
> > > > > I'm a bit curious where you're going with this.  I started on a
> > similar
> > > > > project a couple of years ago:
> > > > >
> > > > >
> > https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/genxml-engines
> > > > >
> > > > > Mine took a different (not necessarily better) approach of
> > surrounding
> > > > the
> > > > > instructions in an  tag.  I'm

[Mesa-dev] [Bug 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes "startplasmacompositor" to segfault

2018-11-02 Thread bugzilla-daemon

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

--- Comment #1 from kyle.de...@mykolab.com ---
I don't know how to collect meaningful debug output from a crashing
startplasmacompositor... :/

Actually, come to think of it, it's kwin_wayland that's dying, I suppose.

Not that this helps me or you devs, much. :(

-- 
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 108635] 68dc591af16ebb36814e4c187e4998948103c99c causes "startplasmacompositor" to segfault

2018-11-02 Thread bugzilla-daemon

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

Bug ID: 108635
   Summary: 68dc591af16ebb36814e4c187e4998948103c99c causes
"startplasmacompositor" to segfault
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: EGL
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: kyle.de...@mykolab.com
QA Contact: mesa-dev@lists.freedesktop.org

Previous commit 9cbdcc86b7209d0022ca9c31668c4d38a9598e4b is the one last
working.

The segfault is simply cut off, but I'll see if I can get something useful...

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

[Mesa-dev] [PATCH] amd: remove support for LLVM 6.0

2018-11-02 Thread Samuel Pitoiset

User are encouraged to switch to LLVM 7.0 released in September 2018.

Signed-off-by: Samuel Pitoiset 
---
 configure.ac  |   4 +-
 meson.build   |   2 +-
 src/amd/common/ac_llvm_build.c| 270 +-
 src/amd/common/ac_llvm_build.h|   8 +-
 src/amd/common/ac_llvm_helper.cpp |   7 -
 src/amd/common/ac_llvm_util.c |  19 +-
 src/amd/common/ac_nir_to_llvm.c   |  24 +-
 src/amd/vulkan/radv_cmd_buffer.c  |  15 +-
 src/amd/vulkan/radv_device.c  |   4 +-
 src/amd/vulkan/radv_extensions.py |   2 +-
 src/amd/vulkan/radv_nir_to_llvm.c |  13 +-
 src/amd/vulkan/radv_private.h |   2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c |  49 +---
 src/gallium/drivers/radeonsi/si_get.c |   9 -
 src/gallium/drivers/radeonsi/si_shader.c  |  92 +-
 src/gallium/drivers/radeonsi/si_shader.h  |  27 --
 .../drivers/radeonsi/si_shader_tgsi_alu.c |  47 ++-
 .../drivers/radeonsi/si_state_shaders.c   |   7 +-
 18 files changed, 86 insertions(+), 515 deletions(-)

diff --git a/configure.ac b/configure.ac
index d782f56205..fe63044293 100644
--- a/configure.ac
+++ b/configure.ac
@@ -107,8 +107,8 @@ dnl LLVM versions
 LLVM_REQUIRED_GALLIUM=3.3.0
 LLVM_REQUIRED_OPENCL=3.9.0
 LLVM_REQUIRED_R600=3.9.0
-LLVM_REQUIRED_RADEONSI=6.0.0
-LLVM_REQUIRED_RADV=6.0.0
+LLVM_REQUIRED_RADEONSI=7.0.0
+LLVM_REQUIRED_RADV=7.0.0
 LLVM_REQUIRED_SWR=6.0.0
 
 dnl Check for progs
diff --git a/meson.build b/meson.build
index 18667988ba..22a9c7bd9a 100644
--- a/meson.build
+++ b/meson.build
@@ -1176,7 +1176,7 @@ if with_gallium_opencl
 endif
 
 if with_amd_vk or with_gallium_radeonsi
-  _llvm_version = '>= 6.0.0'
+  _llvm_version = '>= 7.0.0'
 elif with_gallium_swr
   _llvm_version = '>= 6.0.0'
 elif with_gallium_opencl or with_gallium_r600
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 1392ec0f23..108e37a3e7 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -75,7 +75,7 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->i16 = LLVMIntTypeInContext(ctx->context, 16);
ctx->i32 = LLVMIntTypeInContext(ctx->context, 32);
ctx->i64 = LLVMIntTypeInContext(ctx->context, 64);
-   ctx->intptr = HAVE_32BIT_POINTERS ? ctx->i32 : ctx->i64;
+   ctx->intptr = ctx->i32;
ctx->f16 = LLVMHalfTypeInContext(ctx->context);
ctx->f32 = LLVMFloatTypeInContext(ctx->context);
ctx->f64 = LLVMDoubleTypeInContext(ctx->context);
@@ -1342,99 +1342,28 @@ ac_build_ddxy(struct ac_llvm_context *ctx,
  int idx,
  LLVMValueRef val)
 {
+   unsigned tl_lanes[4], trbl_lanes[4];
LLVMValueRef tl, trbl, args[2];
LLVMValueRef result;
 
-   if (HAVE_LLVM >= 0x0700) {
-   unsigned tl_lanes[4], trbl_lanes[4];
-
-   for (unsigned i = 0; i < 4; ++i) {
-   tl_lanes[i] = i & mask;
-   trbl_lanes[i] = (i & mask) + idx;
-   }
-
-   tl = ac_build_quad_swizzle(ctx, val,
-  tl_lanes[0], tl_lanes[1],
-  tl_lanes[2], tl_lanes[3]);
-   trbl = ac_build_quad_swizzle(ctx, val,
-trbl_lanes[0], trbl_lanes[1],
-trbl_lanes[2], trbl_lanes[3]);
-   } else if (ctx->chip_class >= VI) {
-   LLVMValueRef thread_id, tl_tid, trbl_tid;
-   thread_id = ac_get_thread_id(ctx);
-
-   tl_tid = LLVMBuildAnd(ctx->builder, thread_id,
- LLVMConstInt(ctx->i32, mask, false), "");
-
-   trbl_tid = LLVMBuildAdd(ctx->builder, tl_tid,
-   LLVMConstInt(ctx->i32, idx, false), "");
-
-   args[0] = LLVMBuildMul(ctx->builder, tl_tid,
-  LLVMConstInt(ctx->i32, 4, false), "");
-   args[1] = val;
-   tl = ac_build_intrinsic(ctx,
-   "llvm.amdgcn.ds.bpermute", ctx->i32,
-   args, 2,
-   AC_FUNC_ATTR_READNONE |
-   AC_FUNC_ATTR_CONVERGENT);
-
-   args[0] = LLVMBuildMul(ctx->builder, trbl_tid,
-  LLVMConstInt(ctx->i32, 4, false), "");
-   trbl = ac_build_intrinsic(ctx,
- "llvm.amdgcn.ds.bpermute", ctx->i32,
- args, 2,
- AC_FUNC_ATTR_READNONE |
- AC_FUNC_ATTR_CONVERGENT);
-   } else {
-   uint32_t masks[2] = {};
-
-

Re: [Mesa-dev] [PATCH] nir: allow propagation of if evaluation for bcsel

2018-11-02 Thread Samuel Pitoiset


This change breaks:

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag,Fail
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom,Fail
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc,Fail
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert,Fail

On 11/1/18 10:53 PM, Timothy Arceri wrote:

Cc: Jason Ekstrand 
---
  src/compiler/nir/nir_opt_if.c | 26 +-
  1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 1fe95e53766..50e8947eaa1 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -448,7 +448,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
 if (!evaluate_if_condition(nif, b->cursor, _value))
return false;
  
-   nir_ssa_def *def[2] = {0};

+   nir_ssa_def *def[4] = {0};
 for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
if (alu->src[i].src.ssa == use_src->ssa) {
   def[i] = nir_imm_bool(b, bool_value);
@@ -456,7 +456,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
   def[i] = alu->src[i].src.ssa;
}
 }
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
+   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);
  
 /* Rewrite use to use new alu instruction */

 nir_src new_src = nir_src_for_ssa(nalu);
@@ -472,14 +472,22 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  static bool
  can_propagate_through_alu(nir_src *src)
  {
-   if (src->parent_instr->type == nir_instr_type_alu &&
-   (nir_instr_as_alu(src->parent_instr)->op == nir_op_ior ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_iand ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_inot ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_b2i))
-  return true;
+   if (src->parent_instr->type != nir_instr_type_alu)
+  return false;
  
-   return false;

+   switch (nir_instr_as_alu(src->parent_instr)->op) {
+  case nir_op_ior:
+  case nir_op_iand:
+  case nir_op_inot:
+  case nir_op_b2i:
+ return true;
+  case nir_op_bcsel:
+ if (src == _instr_as_alu(src->parent_instr)->src[0].src)
+return true;
+ /* fall through */
+  default:
+ return false;
+   }
  }
  
  static bool



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

Re: [Mesa-dev] [PATCH] amd: Make vgpr-spilling depend on llvm version

2018-11-02 Thread Samuel Pitoiset


Reviewed-by: Samuel Pitoiset 

On 11/1/18 7:52 PM, Jan Vesely wrote:

The option was removed in LLVM r345763
Signed-off-by: Jan Vesely 
---
  src/amd/common/ac_llvm_util.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 69d9f7b9f3..dc9b684e9d 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -153,7 +153,8 @@ static LLVMTargetMachineRef ac_create_target_machine(enum 
radeon_family family,
LLVMTargetRef target = ac_get_llvm_target(triple);
  
  	snprintf(features, sizeof(features),

-
"+DumpCode,+vgpr-spilling,-fp32-denormals,+fp64-denormals%s%s%s%s",
+"+DumpCode,-fp32-denormals,+fp64-denormals%s%s%s%s%s",
+HAVE_LLVM >= 0x0800 ? "" : ",+vgpr-spilling",
 tm_options & AC_TM_SISCHED ? ",+si-scheduler" : "",
 tm_options & AC_TM_FORCE_ENABLE_XNACK ? ",+xnack" : "",
 tm_options & AC_TM_FORCE_DISABLE_XNACK ? ",-xnack" : "",


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

Re: [Mesa-dev] [PATCH 1/4] i965: Move some genX infrastructure to genX_boilerplate.h.

2018-11-02 Thread Jordan Justen

On 2018-11-01 20:04:18, Kenneth Graunke wrote:
> This will let us make multiple genX_*.c files, without copy and pasting
> all this boilerplate.
> ---
>  src/mesa/drivers/dri/i965/Makefile.sources|  10 ++
>  src/mesa/drivers/dri/i965/genX_boilerplate.h  | 160 ++
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 129 +-
>  src/mesa/drivers/dri/i965/meson.build |   3 +-
>  4 files changed, 174 insertions(+), 128 deletions(-)
>  create mode 100644 src/mesa/drivers/dri/i965/genX_boilerplate.h
> 
> diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
> b/src/mesa/drivers/dri/i965/Makefile.sources
> index 043a70029f2..63fa7b886f2 100644
> --- a/src/mesa/drivers/dri/i965/Makefile.sources
> +++ b/src/mesa/drivers/dri/i965/Makefile.sources
> @@ -126,42 +126,52 @@ intel_tiled_memcpy_dep_FILES = \
>  
>  i965_gen4_FILES = \
> genX_blorp_exec.c \
> +   genX_boilerplate.h \

brw_genX.h? genX_common.h? genX.h?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel: Use a URB start offset of 0 for disabled stages.

2018-11-02 Thread Jordan Justen

Reviewed-by: Jordan Justen 

On 2018-11-01 20:01:36, Kenneth Graunke wrote:
> There are some cases where the VS is the only stage enabled, it uses the
> entire URB, and the URB is large enough that placing later stages after
> the VS exceeds the number of bits for "URB Starting Address".
> 
> For example, on Icelake GT2, "varying-packing-simple mat2x4 array" from
> Piglit is getting a starting offset of 128 for the GS/HS/DS.  But the
> field is only large enough to hold an offset of 127.
> 
> i965 doesn't hit any genxml assertions because it's still using the old
> OUT_BATCH mechanism.  128 << GEN7_URB_STARTING_ADDRESS_SHIFT (57) == 0,
> with the extra bit falling off the end.  So we place the disabled stage
> at the beginning of the URB (overlapping with push constants).  This is
> likely okay since it's a zero size region (0 entries).
> 
> It seems like the Vulkan driver might hit this assertion, however, and
> the situation seems harmless.  To work around this, always place
> disabled stages at the start of the URB, so the last enabled stage can
> fill the remaining space without overflowing the field.
> ---
>  src/intel/common/gen_urb_config.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/src/intel/common/gen_urb_config.c 
> b/src/intel/common/gen_urb_config.c
> index 0b632149cd9..1440dd713e9 100644
> --- a/src/intel/common/gen_urb_config.c
> +++ b/src/intel/common/gen_urb_config.c
> @@ -195,8 +195,14 @@ gen_get_urb_config(const struct gen_device_info *devinfo,
> }
>  
> /* Lay out the URB in pipeline order: push constants, VS, HS, DS, GS. */
> -   start[0] = push_constant_chunks;
> -   for (int i = MESA_SHADER_TESS_CTRL; i <= MESA_SHADER_GEOMETRY; i++) {
> -  start[i] = start[i - 1] + chunks[i - 1];
> +   int next = push_constant_chunks;
> +   for (int i = MESA_SHADER_VERTEX; i <= MESA_SHADER_GEOMETRY; i++) {
> +  if (entries[i]) {
> + start[i] = next;
> + next += chunks[i];
> +  } else {
> + /* Just put disabled stages at the beginning. */
> + start[i] = 0;
> +  }
> }
>  }
> -- 
> 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 mesa] util: use unsigned ints for bit operations

2018-11-02 Thread Mathias Fröhlich

Hi,

On Friday, 2 November 2018 06:22:13 CET Dave Airlie wrote:
> On Tue, 23 Oct 2018 at 10:57, Eric Anholt  wrote:
> >
> > Eric Engestrom  writes:
> >
> > > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > > time this macro is used.
> 
> This seems to be causing problems for me here on gcc8 (8.0.1 and
> 8.2.1) in Fedora 28.
> 
> ./bin/texelFetch fs usampler2DMS 2
> 
> is failing here with:
> Failed to compile fragment shader: 0:6(1): error: invalid input layout
> qualifier used
> 
> gcc is probably broken, but we might want to revert his from the tree
> and upcoming release until we can figure it out.

I have been experiencing something similar on fedora 28.

The observation is that gcc-8.2.1-3 works correct and gcc-8.2.1-4 does
show this problem. So for myself I have been nailing down the rpm version
of the gcc packet not to update. That helps as first aid but is not exactly 
nice.

There is now also a reduced source that does not require a full mesa compile
to ease a bug report. The file is attached here. You need -O2 to make it fail.

Before filing a bug report at gcc I wanted to verify that we are not doing 
anything
wrong like with aliasing for example. Which is the reason the bug is not filed 
yet.

Now, I don't find time to put more work into that at the weekend and
probably also not next week. So if anybody of you wants accelerate the process,
double checks that we don't do something wrong and hand that over to gcc
I would not mind!

There is also an observation that the new gcc rpm includes the fix for gcc
bug 87137 that actually turns out to be a bitfield layouting problem.
If fedora wants to experiment with a fedora only fix its probably a good
starting point to check if omitting the corresponding patch for bug 87137
does actually help on linux. Well that is pure speculation from my side.

... so far the dump from my side on that problem.

best

Mathias#include 

#include 

#define BITSET_WORD unsigned int
#define BITSET_WORDBITS (sizeof (BITSET_WORD) * 8)
#define BITSET_WORDS(bits) (((bits) + BITSET_WORDBITS - 1) / BITSET_WORDBITS)
#define BITSET_EQUAL(x, y) (std::memcmp( (x), (y), sizeof (x) ) == 0)

#define DECLARE_BITSET_T(T, N) struct T {   \
\
  T &   \
  operator=(int x)  \
  { \
 const T c = {{ (BITSET_WORD)x }};  \
 return *this = c;  \
  } \
\
  friend bool   \
  operator==(const T , const T )\
  { \
 return BITSET_EQUAL(b.words, c.words); \
  } \
\
  friend bool   \
  operator!=(const T , const T )\
  { \
 return !(b == c);  \
  } \
\
  friend bool   \
  operator==(const T , int x) \
  { \
 const T c = {{ (BITSET_WORD)x }};  \
 return b == c; \
  } \
\
  friend bool   \
  operator!=(const T , int x) \
  { \
 return !(b == x);  \
  } \
\
  friend T  \
  operator~(const T ) \
  { \
 T c;   \
 for (unsigned i = 0; i < BITSET_WORDS(N); i++) \
c.words[i] = ~b.words[i];   \
 return c;  \
  } \

Re: [Mesa-dev] [PATCH mesa] util: use unsigned ints for bit operations

2018-11-02 Thread Dave Airlie

On Fri, 2 Nov 2018 at 15:22, Dave Airlie  wrote:
>
> On Tue, 23 Oct 2018 at 10:57, Eric Anholt  wrote:
> >
> > Eric Engestrom  writes:
> >
> > > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > > time this macro is used.
>
> This seems to be causing problems for me here on gcc8 (8.0.1 and
> 8.2.1) in Fedora 28.
>
> ./bin/texelFetch fs usampler2DMS 2
>
> is failing here with:
> Failed to compile fragment shader: 0:6(1): error: invalid input layout
> qualifier used
>
> gcc is probably broken, but we might want to revert his from the tree
> and upcoming release until we can figure it out.

Actually not related to this, it looks like gcc 8.2.1 has broken out bitset.

I probably won't get to this until next week so if someone else has
time, feel free.

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

71 matches

Mail list logo