[Mesa-dev] [Bug 108024] [Debian Stretch]Fail to build because "xcb_randr_lease_t"

2018-09-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108024

--- Comment #2 from Stuart Young  ---
Suspect this is the related commit where the randr leases code was added:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7ab1fffcd2a504024b16e408de329f7a94553ecc

A quick look at similar commits for radv and anv don't reference randr leases,
so it seems it's just vulkan that's affected.

Related:

1.
https://cgit.freedesktop.org/mesa/mesa/commit/?id=c9b153fea746fa0bef100d72d157e534dbd44905
updates travis to use libxcb 1.13, so it seems a requirement for at least
libxcb 1.13 to be used was expected.

2.
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7aeef2d4efdc809a698e9b983c8be8e4ccb27134
(after travis update) suggests that building against older versions of libxcb
should still be supported.

-- 
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 108024] [Debian Stretch]Fail to build because "xcb_randr_lease_t"

2018-09-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108024

--- Comment #1 from Stuart Young  ---
Probably needs libxcb-1.13 (released March 2018). From the xcb release notes
https://lists.freedesktop.org/archives/xcb/2018-March/011090.html :

This release of xcb-proto brings support for buffer modifiers and
multi-planar buffers through DRI3 v1.2 and Present v1.2, support for
leasing KMS devices to clients via RandR 1.6, and also allows clients
to send each other XInput2 events via support for the GenericEvent
extension's SendExtension event.

.. specifically wrt RandR leases.

Suspect that the code simply doesn't compile if an older version of libxcb is
installed.

Options:
 1. Code gets corrected to handle if an older version of libxcb is installed.
 2. Install libxcb 1.13. Note that it's not in stretch-backports so either you
will need to backport it yourself from buster, or request a backport on the
debian-backorts list.

-- 
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 108024] [Debian Stretch]Fail to build because "xcb_randr_lease_t"

2018-09-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108024

Bug ID: 108024
   Summary: [Debian Stretch]Fail to build because
"xcb_randr_lease_t"
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: berilli...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 141692
  --> https://bugs.freedesktop.org/attachment.cgi?id=141692=edit
Build log error radeon vulkan

Hello,

I try to build Mesa 18.2.1 on Debian Stretch with version 1.12 of libxcb
packages. Unfortunatly, the build fails during the compilation of Radeon Vulkan
driver about  "xcb_randr_lease_t" / "xcb_randr_create_lease_cookie_t" etc ...
type name which are unknown.

I attach the complete build log. The errors are at the end of file.

Thanks,
Maxime

-- 
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] docs: Update FAQ with current OpenGL API version supported

2018-09-22 Thread Stuart Young
Used a variation on the standard boilerplate version info that is used in
the release notes.

---
 docs/faq.html | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/docs/faq.html b/docs/faq.html
index 6270a071da..080c6b6da7 100644
--- a/docs/faq.html
+++ b/docs/faq.html
@@ -45,7 +45,16 @@ See the https://www.opengl.org/;>OpenGL website 
for more
 information.
 
 
-Mesa 9.x supports the OpenGL 3.1 specification.
+Since the release of 17.0.0, Mesa supports the OpenGL 4.5 API specification.
+Note that the version reported by glGetString(GL_VERSION) or
+glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on
+the particular driver being used. Some drivers don't support all the features
+required in OpenGL 4.5. OpenGL 4.5 is only available if requested at context
+creation because compatibility contexts are not supported.
+
+
+For earlier versions, consult the release notes for the version of the
+OpenGL API they support.
 
 
 
-- 
2.11.0

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


[Mesa-dev] [PATCH 5/5] spirv: Make images, samplers, and sampled images normal SSA values

2018-09-22 Thread Jason Ekstrand
Instead of treating image, sampler, and combined image sampler SSA
values as pointers and special-casing them various places, we now allow
them to be part of regular SSA values.  Among other things, this means
that composites of opaque types should now work correctly.
---
 src/compiler/spirv/spirv_to_nir.c  | 53 ++
 src/compiler/spirv/vtn_cfg.c   | 70 +++---
 src/compiler/spirv/vtn_private.h   |  7 ++-
 src/compiler/spirv/vtn_variables.c | 51 ++
 4 files changed, 86 insertions(+), 95 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 2ad83196e46..b6e9d9fe11a 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1860,25 +1860,19 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
const uint32_t *w, unsigned count)
 {
if (opcode == SpvOpSampledImage) {
-  struct vtn_value *val =
- vtn_push_value(b, w[2], vtn_value_type_sampled_image);
-  val->sampled_image = ralloc(b, struct vtn_sampled_image);
-  val->sampled_image->type =
- vtn_value(b, w[1], vtn_value_type_type)->type;
-  val->sampled_image->image =
- vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
-  val->sampled_image->sampler =
- vtn_value(b, w[4], vtn_value_type_pointer)->pointer;
+  struct vtn_type *res_type = vtn_value(b, w[1], 
vtn_value_type_type)->type;
+  struct vtn_ssa_value *ssa = vtn_create_ssa_value(b, res_type->type);
+  ssa->sampled_image = ralloc(b, struct vtn_sampled_image);
+  ssa->sampled_image->type = res_type;
+  ssa->sampled_image->image = vtn_ssa_value(b, w[3])->image;
+  ssa->sampled_image->sampler = vtn_ssa_value(b, w[4])->sampler;
+  vtn_push_ssa(b, w[2], res_type, ssa);
   return;
} else if (opcode == SpvOpImage) {
-  struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_pointer);
-  struct vtn_value *src_val = vtn_untyped_value(b, w[3]);
-  if (src_val->value_type == vtn_value_type_sampled_image) {
- val->pointer = src_val->sampled_image->image;
-  } else {
- vtn_assert(src_val->value_type == vtn_value_type_pointer);
- val->pointer = src_val->pointer;
-  }
+  struct vtn_type *res_type = vtn_value(b, w[1], 
vtn_value_type_type)->type;
+  struct vtn_ssa_value *ssa = vtn_create_ssa_value(b, res_type->type);
+  ssa->image = vtn_ssa_value(b, w[3])->sampled_image->image;
+  vtn_push_ssa(b, w[2], res_type, ssa);
   return;
}
 
@@ -1886,14 +1880,14 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp opcode,
struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_ssa);
 
struct vtn_sampled_image sampled;
-   struct vtn_value *sampled_val = vtn_untyped_value(b, w[3]);
-   if (sampled_val->value_type == vtn_value_type_sampled_image) {
-  sampled = *sampled_val->sampled_image;
+   struct vtn_value *sampled_val = vtn_value(b, w[3], vtn_value_type_ssa);
+   if (sampled_val->type->base_type == vtn_base_type_sampled_image) {
+  sampled = *sampled_val->ssa->sampled_image;
} else {
-  vtn_assert(sampled_val->value_type == vtn_value_type_pointer);
-  sampled.type = sampled_val->pointer->type;
+  vtn_assert(sampled_val->type->base_type == vtn_base_type_image);
+  sampled.type = sampled_val->type;
   sampled.image = NULL;
-  sampled.sampler = sampled_val->pointer;
+  sampled.sampler = sampled_val->ssa->image;
}
 
const struct glsl_type *image_type = sampled.type->type;
@@ -2319,13 +2313,13 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
   break;
 
case SpvOpImageQuerySize:
-  image.image = vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
+  image.image = vtn_ssa_value(b, w[3])->image;
   image.coord = NULL;
   image.sample = NULL;
   break;
 
case SpvOpImageRead:
-  image.image = vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
+  image.image = vtn_ssa_value(b, w[3])->image;
   image.coord = get_image_coord(b, w[4]);
 
   if (count > 5 && (w[5] & SpvImageOperandsSampleMask)) {
@@ -2337,7 +2331,7 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
   break;
 
case SpvOpImageWrite:
-  image.image = vtn_value(b, w[1], vtn_value_type_pointer)->pointer;
+  image.image = vtn_ssa_value(b, w[1])->image;
   image.coord = get_image_coord(b, w[2]);
 
   /* texel = w[3] */
@@ -3836,12 +3830,11 @@ vtn_handle_body_instruction(struct vtn_builder *b, 
SpvOp opcode,
   break;
 
case SpvOpImageQuerySize: {
-  struct vtn_pointer *image =
- vtn_value(b, w[3], vtn_value_type_pointer)->pointer;
-  if (glsl_type_is_image(image->type->type)) {
+  struct vtn_value *val = vtn_value(b, w[3], vtn_value_type_ssa);
+  if (glsl_type_is_image(val->type->type)) {
  vtn_handle_image(b, opcode, w, count);
   } else {
- 

[Mesa-dev] [PATCH 4/5] spirv: Pass SSA values through functions

2018-09-22 Thread Jason Ekstrand
Previously, we would create temporary variables and fill them out.
Instead, we create as many function parameters as we need and pass them
through as SSA defs.
---
 src/compiler/spirv/vtn_cfg.c | 180 +++
 1 file changed, 139 insertions(+), 41 deletions(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 87149905ed1..1020b2722f4 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -42,6 +42,135 @@ vtn_load_param_pointer(struct vtn_builder *b,
return vtn_pointer_from_ssa(b, nir_load_param(>nb, param_idx), ptr_type);
 }
 
+static unsigned
+vtn_type_count_function_params(struct vtn_type *type)
+{
+   switch (type->base_type) {
+   case vtn_base_type_array:
+  return type->length * 
vtn_type_count_function_params(type->array_element);
+
+   case vtn_base_type_struct: {
+  unsigned count = 0;
+  for (unsigned i = 0; i < type->length; i++)
+ count += vtn_type_count_function_params(type->members[i]);
+  return count;
+   }
+
+   case vtn_base_type_sampled_image:
+  return 2;
+
+   default:
+  return 1;
+   }
+}
+
+static void
+vtn_type_add_to_function_params(struct vtn_type *type,
+nir_function *func,
+unsigned *param_idx)
+{
+   static const nir_parameter nir_deref_param = {
+  .num_components = 1,
+  .bit_size = 32,
+   };
+
+   switch (type->base_type) {
+   case vtn_base_type_array:
+  for (unsigned i = 0; i < type->length; i++)
+ vtn_type_add_to_function_params(type->array_element, func, param_idx);
+  break;
+
+   case vtn_base_type_struct:
+  for (unsigned i = 0; i < type->length; i++)
+ vtn_type_add_to_function_params(type->members[i], func, param_idx);
+  break;
+
+   case vtn_base_type_sampled_image:
+  func->params[(*param_idx)++] = nir_deref_param;
+  func->params[(*param_idx)++] = nir_deref_param;
+  break;
+
+   case vtn_base_type_image:
+   case vtn_base_type_sampler:
+  func->params[(*param_idx)++] = nir_deref_param;
+  break;
+
+   case vtn_base_type_pointer:
+  if (type->type) {
+ func->params[(*param_idx)++] = (nir_parameter) {
+.num_components = glsl_get_vector_elements(type->type),
+.bit_size = glsl_get_bit_size(type->type),
+ };
+  } else {
+ func->params[(*param_idx)++] = nir_deref_param;
+  }
+  break;
+
+   default:
+  func->params[(*param_idx)++] = (nir_parameter) {
+ .num_components = glsl_get_vector_elements(type->type),
+ .bit_size = glsl_get_bit_size(type->type),
+  };
+   }
+}
+
+static void
+vtn_ssa_value_add_to_call_params(struct vtn_builder *b,
+ struct vtn_ssa_value *value,
+ struct vtn_type *type,
+ nir_call_instr *call,
+ unsigned *param_idx)
+{
+   switch (type->base_type) {
+   case vtn_base_type_array:
+  for (unsigned i = 0; i < type->length; i++) {
+ vtn_ssa_value_add_to_call_params(b, value->elems[i],
+  type->array_element,
+  call, param_idx);
+  }
+  break;
+
+   case vtn_base_type_struct:
+  for (unsigned i = 0; i < type->length; i++) {
+ vtn_ssa_value_add_to_call_params(b, value->elems[i],
+  type->members[i],
+  call, param_idx);
+  }
+  break;
+
+   default:
+  call->params[(*param_idx)++] = nir_src_for_ssa(value->def);
+  break;
+   }
+}
+
+static void
+vtn_ssa_value_load_function_param(struct vtn_builder *b,
+  struct vtn_ssa_value *value,
+  struct vtn_type *type,
+  unsigned *param_idx)
+{
+   switch (type->base_type) {
+   case vtn_base_type_array:
+  for (unsigned i = 0; i < type->length; i++) {
+ vtn_ssa_value_load_function_param(b, value->elems[i],
+   type->array_element, param_idx);
+  }
+  break;
+
+   case vtn_base_type_struct:
+  for (unsigned i = 0; i < type->length; i++) {
+ vtn_ssa_value_load_function_param(b, value->elems[i],
+   type->members[i], param_idx);
+  }
+  break;
+
+   default:
+  value->def = nir_load_param(>nb, b->func_param_idx++);
+  break;
+   }
+}
+
 void
 vtn_handle_function_call(struct vtn_builder *b, SpvOp opcode,
  const uint32_t *w, unsigned count)
@@ -86,12 +215,8 @@ vtn_handle_function_call(struct vtn_builder *b, SpvOp 
opcode,
  call->params[param_idx++] =
 nir_src_for_ssa(vtn_pointer_to_ssa(b, pointer));
   } else {
- /* This is a regular SSA value and we need a temporary */
- 

[Mesa-dev] [PATCH 3/5] spirv: Move function call handling to vtn_cfg

2018-09-22 Thread Jason Ekstrand
It makes way more sense for it to live there with the rest of function
handling.
---
 src/compiler/spirv/spirv_to_nir.c | 63 ---
 src/compiler/spirv/vtn_cfg.c  | 63 +++
 src/compiler/spirv/vtn_private.h  |  2 +
 3 files changed, 65 insertions(+), 63 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 96224354057..2ad83196e46 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -1802,69 +1802,6 @@ vtn_handle_constant(struct vtn_builder *b, SpvOp opcode,
vtn_foreach_decoration(b, val, handle_workgroup_size_decoration_cb, NULL);
 }
 
-static void
-vtn_handle_function_call(struct vtn_builder *b, SpvOp opcode,
- const uint32_t *w, unsigned count)
-{
-   struct vtn_type *res_type = vtn_value(b, w[1], vtn_value_type_type)->type;
-   struct vtn_function *vtn_callee =
-  vtn_value(b, w[3], vtn_value_type_function)->func;
-   struct nir_function *callee = vtn_callee->impl->function;
-
-   vtn_callee->referenced = true;
-
-   nir_call_instr *call = nir_call_instr_create(b->nb.shader, callee);
-
-   unsigned param_idx = 0;
-
-   nir_deref_instr *ret_deref = NULL;
-   struct vtn_type *ret_type = vtn_callee->type->return_type;
-   if (ret_type->base_type != vtn_base_type_void) {
-  nir_variable *ret_tmp =
- nir_local_variable_create(b->nb.impl, ret_type->type, "return_tmp");
-  ret_deref = nir_build_deref_var(>nb, ret_tmp);
-  call->params[param_idx++] = nir_src_for_ssa(_deref->dest.ssa);
-   }
-
-   for (unsigned i = 0; i < vtn_callee->type->length; i++) {
-  struct vtn_type *arg_type = vtn_callee->type->params[i];
-  unsigned arg_id = w[4 + i];
-
-  if (arg_type->base_type == vtn_base_type_sampled_image) {
- struct vtn_sampled_image *sampled_image =
-vtn_value(b, arg_id, vtn_value_type_sampled_image)->sampled_image;
-
- call->params[param_idx++] =
-nir_src_for_ssa(_image->image->deref->dest.ssa);
- call->params[param_idx++] =
-nir_src_for_ssa(_image->sampler->deref->dest.ssa);
-  } else if (arg_type->base_type == vtn_base_type_pointer ||
- arg_type->base_type == vtn_base_type_image ||
- arg_type->base_type == vtn_base_type_sampler) {
- struct vtn_pointer *pointer =
-vtn_value(b, arg_id, vtn_value_type_pointer)->pointer;
- call->params[param_idx++] =
-nir_src_for_ssa(vtn_pointer_to_ssa(b, pointer));
-  } else {
- /* This is a regular SSA value and we need a temporary */
- nir_variable *tmp =
-nir_local_variable_create(b->nb.impl, arg_type->type, "arg_tmp");
- nir_deref_instr *tmp_deref = nir_build_deref_var(>nb, tmp);
- vtn_local_store(b, vtn_ssa_value(b, arg_id), tmp_deref);
- call->params[param_idx++] = nir_src_for_ssa(_deref->dest.ssa);
-  }
-   }
-   assert(param_idx == call->num_params);
-
-   nir_builder_instr_insert(>nb, >instr);
-
-   if (ret_type->base_type == vtn_base_type_void) {
-  vtn_push_value(b, w[2], vtn_value_type_undef);
-   } else {
-  vtn_push_ssa(b, w[2], res_type, vtn_local_load(b, ret_deref));
-   }
-}
-
 struct vtn_ssa_value *
 vtn_create_ssa_value(struct vtn_builder *b, const struct glsl_type *type)
 {
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index ed1ab5d1c2c..87149905ed1 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -42,6 +42,69 @@ vtn_load_param_pointer(struct vtn_builder *b,
return vtn_pointer_from_ssa(b, nir_load_param(>nb, param_idx), ptr_type);
 }
 
+void
+vtn_handle_function_call(struct vtn_builder *b, SpvOp opcode,
+ const uint32_t *w, unsigned count)
+{
+   struct vtn_type *res_type = vtn_value(b, w[1], vtn_value_type_type)->type;
+   struct vtn_function *vtn_callee =
+  vtn_value(b, w[3], vtn_value_type_function)->func;
+   struct nir_function *callee = vtn_callee->impl->function;
+
+   vtn_callee->referenced = true;
+
+   nir_call_instr *call = nir_call_instr_create(b->nb.shader, callee);
+
+   unsigned param_idx = 0;
+
+   nir_deref_instr *ret_deref = NULL;
+   struct vtn_type *ret_type = vtn_callee->type->return_type;
+   if (ret_type->base_type != vtn_base_type_void) {
+  nir_variable *ret_tmp =
+ nir_local_variable_create(b->nb.impl, ret_type->type, "return_tmp");
+  ret_deref = nir_build_deref_var(>nb, ret_tmp);
+  call->params[param_idx++] = nir_src_for_ssa(_deref->dest.ssa);
+   }
+
+   for (unsigned i = 0; i < vtn_callee->type->length; i++) {
+  struct vtn_type *arg_type = vtn_callee->type->params[i];
+  unsigned arg_id = w[4 + i];
+
+  if (arg_type->base_type == vtn_base_type_sampled_image) {
+ struct vtn_sampled_image *sampled_image =
+vtn_value(b, arg_id, vtn_value_type_sampled_image)->sampled_image;
+
+ 

[Mesa-dev] [PATCH 2/5] nir/from_ssa: Don't rewrite derefs destinations to registers

2018-09-22 Thread Jason Ekstrand
We already call nir_rematerialize_derefs_in_use_blocks_impl prior to
calling nir_lower_ssa_defs_to_regs_block so the assertion that all deref
uses in the block should hold.  This fixes validation errors in some
Vulkan CTS tests with SPIR-V optimizations enabled.

Fixes: 606eb56ab9449b "intel/nir: Only lower load/store derefs"
---
 src/compiler/nir/nir_from_ssa.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compiler/nir/nir_from_ssa.c b/src/compiler/nir/nir_from_ssa.c
index 19d4bc33820..08d480f119c 100644
--- a/src/compiler/nir/nir_from_ssa.c
+++ b/src/compiler/nir/nir_from_ssa.c
@@ -976,6 +976,12 @@ nir_lower_ssa_defs_to_regs_block(nir_block *block)
  mov->dest.dest = nir_dest_for_reg(reg);
  mov->dest.write_mask = (1 << reg->num_components) - 1;
  nir_instr_insert(nir_after_instr(>instr), >instr);
+  } else if (instr->type == nir_instr_type_deref) {
+ /* Derefs should always be SSA values, don't rewrite them. */
+ nir_deref_instr *deref = nir_instr_as_deref(instr);
+ nir_foreach_use_safe(use, >dest.ssa)
+assert(use->parent_instr->block == block);
+ assert(list_empty(>dest.ssa.if_uses));
   } else {
  nir_foreach_dest(instr, dest_replace_ssa_with_reg, );
   }
-- 
2.17.1

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


[Mesa-dev] [PATCH 0/5] nir,spirv: Fix bugs uncovered by spirv-opt

2018-09-22 Thread Jason Ekstrand
This little series fixes three bugs encountered while running the Vulkan
CTS with SPIR-V optimizations enabled.  The optimizations shouldn't, in
theory, change the behavior of the shader but it does change some of the
SPIR-V patterns and triggered a number of compiler bugs.  I'd like to CC
the whole thing to stable but the last three patches are probably best only
hitting the latest release because they're fairly major surgery.

Jason Ekstrand (5):
  nir/cf: Remove phi sources if needed in nir_handle_add_jump
  nir/from_ssa: Don't rewrite derefs destinations to registers
  spirv: Move function call handling to vtn_cfg
  spirv: Pass SSA values through functions
  spirv: Make images, samplers, and sampled images normal SSA values

 src/compiler/nir/nir_control_flow.c |  36 ++--
 src/compiler/nir/nir_from_ssa.c |   6 +
 src/compiler/spirv/spirv_to_nir.c   | 123 +++-
 src/compiler/spirv/vtn_cfg.c| 279 ++--
 src/compiler/spirv/vtn_private.h|   9 +-
 src/compiler/spirv/vtn_variables.c  |  51 +++--
 6 files changed, 297 insertions(+), 207 deletions(-)

-- 
2.17.1

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


[Mesa-dev] [PATCH 1/5] nir/cf: Remove phi sources if needed in nir_handle_add_jump

2018-09-22 Thread Jason Ekstrand
If the block in which the jump is inserted is the predecessor of a phi
then we need to remove phi sources otherwise the phi may end up with
things improperly connected.  Found by running the Vulkan CTS with
SPIR-V optimizations enabled.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/compiler/nir/nir_control_flow.c | 36 +++--
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/src/compiler/nir/nir_control_flow.c 
b/src/compiler/nir/nir_control_flow.c
index 3b0a0f1a5b0..a82f35550b8 100644
--- a/src/compiler/nir/nir_control_flow.c
+++ b/src/compiler/nir/nir_control_flow.c
@@ -437,6 +437,23 @@ nearest_loop(nir_cf_node *node)
return nir_cf_node_as_loop(node);
 }
 
+static void
+remove_phi_src(nir_block *block, nir_block *pred)
+{
+   nir_foreach_instr(instr, block) {
+  if (instr->type != nir_instr_type_phi)
+ break;
+
+  nir_phi_instr *phi = nir_instr_as_phi(instr);
+  nir_foreach_phi_src_safe(src, phi) {
+ if (src->pred == pred) {
+list_del(>src.use_link);
+exec_node_remove(>node);
+ }
+  }
+   }
+}
+
 /*
  * update the CFG after a jump instruction has been added to the end of a block
  */
@@ -447,6 +464,8 @@ nir_handle_add_jump(nir_block *block)
nir_instr *instr = nir_block_last_instr(block);
nir_jump_instr *jump_instr = nir_instr_as_jump(instr);
 
+   if (block->successors[0])
+  remove_phi_src(block->successors[0], block);
unlink_block_successors(block);
 
nir_function_impl *impl = nir_cf_node_get_function(>cf_node);
@@ -470,23 +489,6 @@ nir_handle_add_jump(nir_block *block)
}
 }
 
-static void
-remove_phi_src(nir_block *block, nir_block *pred)
-{
-   nir_foreach_instr(instr, block) {
-  if (instr->type != nir_instr_type_phi)
- break;
-
-  nir_phi_instr *phi = nir_instr_as_phi(instr);
-  nir_foreach_phi_src_safe(src, phi) {
- if (src->pred == pred) {
-list_del(>src.use_link);
-exec_node_remove(>node);
- }
-  }
-   }
-}
-
 /* Removes the successor of a block with a jump. Note that the jump to be
  * eliminated may be free-floating.
  */
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH mesa 1/2] docs: update repo URLs after GitLab move

2018-09-22 Thread Eric Engestrom
On Friday, 2018-09-21 16:29:48 +0100, Emil Velikov wrote:
> On 21 September 2018 at 14:46, Eric Engestrom  
> wrote:
> > I also updated the developer instructions; presumably someone who's been
> > given commit rights already knows how to clone a repository :)
> >
> > A more useful thing is to show how to update the pushurl, and how to use
> > access tokens to push over HTTPS (especially for us at Intel, where
> > non-http traffic is a pain).
> >
> Personally I'd omit the Intel mention (in the documentation), but it's
> your call.

Dropped.

> For the series:
> Reviewed-by: Emil Velikov 

Thanks!

> 
> Unrelated: I wish gitlab would stop redirecting when the clone URL is
> missing the .git at the end.
> The redirection message git throws is fairly annoying :-\

Agreed :/
If it already figured out that it's replying a git client, it could just
do the right thing silently, like GitHub does, where having the .git at
the end of the repo url makes no difference for the client.

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


Re: [Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess

2018-09-22 Thread Eric Engestrom
On Saturday, 2018-09-22 10:27:50 -0400, Jan Vesely wrote:
> The warning is correct. In the first case, memset tries to zero "Target"
> object which has a non-trivial constructor and non-trivial
> copy-constructor. The original code is broken in the way it mixes C and C++
> initialization and the patch only papers over the issue.
> The correct fix would be to provide a proper constructor for structs that
> include instances of C++ classes.

Thanks for the analysis here, I'll drop these memaccess patches.
The correct fix is beyond what I'm willing to do though, so I'll let
someone else fix them :)

> 
> Jan
> 
> On Sat, Sep 22, 2018 at 6:43 AM Karol Herbst  wrote:
> 
> > yeah, I agree here. Either the code was wrong in the first place,
> > which means it would have to be fixed properly or the warning is
> > wrong. The proper fix here is that GCC should detect itself if it's
> > safe to do or not, otherwise that warning becomes a "might be a
> > problem" thing which doesn't help at all. Either it is wrong, or it
> > isn't. And gcc should be able to know in this case.
> >
> > On Sat, Sep 22, 2018 at 6:07 AM, Ilia Mirkin  wrote:
> > > Based on the various fixes, warning seems bogus -- is the proper
> > > solution -Wno-class-memaccess? (Or however one disables such
> > > things...)
> > >
> > > On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
> > >  wrote:
> > >> Signed-off-by: Eric Engestrom 
> > >> ---
> > >>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
> > >>  src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
> > >>  2 files changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> > >> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
> > >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> > >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> > >> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction
> > *i) const
> > >>  TexInstruction::TexInstruction(Function *fn, operation op)
> > >> : Instruction(fn, op, TYPE_F32)
> > >>  {
> > >> -   memset(, 0, sizeof(tex));
> > >> +   memset(static_cast(), 0, sizeof(tex));
> > >>
> > >> tex.rIndirectSrc = -1;
> > >> tex.sIndirectSrc = -1;
> > >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> > >> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
> > >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> > >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> > >> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply
> > apply)
> > >>if (!fixupInfo)
> > >>   return false;
> > >>if (n == 0)
> > >> - memset(fixupInfo, 0, sizeof(FixupInfo));
> > >> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
> > >> }
> > >> ++fixupInfo->count;
> > >>
> > >> --
> > >> Cheers,
> > >>   Eric
> > >>
> > >> ___
> > >> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3] nvc0: fix bindless multisampled images on Maxwell+

2018-09-22 Thread Ilia Mirkin
On Mon, Sep 17, 2018 at 12:19 PM, Rhys Perry  wrote:
> NVC0_CB_AUX_BINDLESS_INFO isn't written to on Maxwell+ and it's too small
> anyway.
>
> With these changes, TXQ is used to determine the number of samples and
> the coordinate adjustment information looked up in a small array in the
> driver constant buffer.
>
> v2: rework to use TXQ and a small array instead of a larger array with an
> entry for each texture
> v3: get rid of the small array and calculate the adjustments in the shader
>
> Signed-off-by: Rhys Perry 
> Fixes: c2ae9b40527 ('nvc0: implement multisampled images on Maxwell+')
> ---
>  .../codegen/nv50_ir_lowering_gm107.cpp|  4 +-
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 43 ++-
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.h   |  3 +-
>  3 files changed, 45 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp
> index c7436e2e29..49a5f3b01f 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_gm107.cpp
> @@ -320,11 +320,11 @@ GM107LoweringPass::handleSUQ(TexInstruction *suq)
>
>if (mask & 0x1)
>   bld.mkOp2(OP_SHR, TYPE_U32, suq->getDef(0), suq->getDef(0),
> -   loadSuInfo32(ind, slot, NVC0_SU_INFO_MS(0), 
> suq->tex.bindless));
> +   loadMsAdjInfo32(suq->tex.target, 0, slot, ind, 
> suq->tex.bindless));
>if (mask & 0x2) {
>   int d = util_bitcount(mask & 0x1);
>   bld.mkOp2(OP_SHR, TYPE_U32, suq->getDef(d), suq->getDef(d),
> -   loadSuInfo32(ind, slot, NVC0_SU_INFO_MS(1), 
> suq->tex.bindless));
> +   loadMsAdjInfo32(suq->tex.target, 1, slot, ind, 
> suq->tex.bindless));
>}
> }
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index 176e0cf608..7ca38ca4bb 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -1732,6 +1732,45 @@ NVC0LoweringPass::loadSuInfo32(Value *ptr, int slot, 
> uint32_t off, bool bindless
>  prog->driver->io.suInfoBase);
>  }
>
> +inline Value *
> +NVC0LoweringPass::loadMsAdjInfo32(TexInstruction::Target target, uint32_t 
> index, int slot, Value *ind, bool bindless)
> +{
> +   if (!bindless || targ->getChipset() < NVISA_GM107_CHIPSET)
> +  return loadSuInfo32(ind, slot, NVC0_SU_INFO_MS(index), bindless);
> +
> +   assert(bindless);
> +
> +   Value *samples = bld.getSSA();
> +   // this shouldn't be lowered because it's being inserted before the 
> current instruction
> +   TexInstruction *tex = new_TexInstruction(func, OP_TXQ);
> +   tex->tex.target = target;
> +   tex->tex.query = TXQ_TYPE;
> +   tex->tex.mask = 0x4;
> +   tex->tex.r = 0xff;
> +   tex->tex.s = 0x1f;
> +   tex->tex.rIndirectSrc = 0;
> +   tex->setDef(0, samples);
> +   tex->setSrc(0, ind);
> +   tex->setSrc(1, bld.loadImm(NULL, 0));
> +   bld.insert(tex);
> +
> +   // doesn't work with sample counts other than 1/2/4/8 but they aren't 
> supported
> +   switch (index) {
> +   case 0: {
> +  Value *tmp = bld.mkOp2v(OP_ADD, TYPE_U32, bld.getSSA(), samples, 
> bld.mkImm(2));
> +  return bld.mkOp2v(OP_SHR, TYPE_U32, bld.getSSA(), tmp, bld.mkImm(2));
> +   }
> +   case 1: {
> +  Value *tmp = bld.mkCmp(OP_SET, CC_GT, TYPE_U32, bld.getSSA(), 
> TYPE_U32, samples, bld.mkImm(2))->getDef(0);
> +  return bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), tmp, bld.mkImm(1));

I'd prefer OP_NEG here (with a TYPE_S32). That will allow the modifier
to get embedded into a use, perhaps.

Or alternatively, make OP_SET with TYPE_U8 + FILE_PREDICATE, and then
OP_CVT the predicate, which will come out as a 1, iirc. However I
think I like the OP_NEG better -- predicates are apparently slow, and
it's a lot more likely for this value to get used in arithmetic (hence
NEG embedding possible).

Otherwise this is

Reviewed-by: Ilia Mirkin 

> +   }
> +   default: {
> +  assert(false);
> +  return NULL;
> +   }
> +   }
> +}
> +
>  static inline uint16_t getSuClampSubOp(const TexInstruction *su, int c)
>  {
> switch (su->tex.target.getEnum()) {
> @@ -1817,8 +1856,8 @@ NVC0LoweringPass::adjustCoordinatesMS(TexInstruction 
> *tex)
> Value *tx = bld.getSSA(), *ty = bld.getSSA(), *ts = bld.getSSA();
> Value *ind = tex->getIndirectR();
>
> -   Value *ms_x = loadSuInfo32(ind, slot, NVC0_SU_INFO_MS(0), 
> tex->tex.bindless);
> -   Value *ms_y = loadSuInfo32(ind, slot, NVC0_SU_INFO_MS(1), 
> tex->tex.bindless);
> +   Value *ms_x = loadMsAdjInfo32(tex->tex.target, 0, slot, ind, 
> tex->tex.bindless);
> +   Value *ms_y = loadMsAdjInfo32(tex->tex.target, 1, slot, ind, 
> tex->tex.bindless);
>
> bld.mkOp2(OP_SHL, TYPE_U32, tx, x, ms_x);

Re: [Mesa-dev] [PATCH] nvc0: warn about changing NVC0_CB_AUX_MP_INFO and NVC0_CB_AUX_DRAW_INFO

2018-09-22 Thread Ilia Mirkin
Reviewed-by: Ilia Mirkin 

On Thu, Sep 20, 2018 at 1:44 PM, Rhys Perry  wrote:
> Signed-off-by: Rhys Perry 
> ---
>  src/gallium/drivers/nouveau/nvc0/nvc0_context.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
> index 77237a3c0a..b7cc415359 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.h
> @@ -138,7 +138,9 @@
>  #define NVC0_CB_AUX_SAMPLE_INFO 0x1a0 /* FP */
>  /* 256 bytes, though only 64 bytes used before GM200 */
>  #define NVC0_CB_AUX_SAMPLE_SIZE (8 * 2 * 4 * 4)
> -/* draw parameters (index bais, base instance, drawid) */
> +/* draw parameters (index bias, base instance, drawid)
> + * be sure to update the indirect draw macros in com9097.mme when changing 
> this
> + */
>  #define NVC0_CB_AUX_DRAW_INFO   0x1a0 /* VP */
>  /* 32 user buffers, at 4 32-bits integers each */
>  #define NVC0_CB_AUX_BUF_INFO(i) 0x2a0 + (i) * 4 * 4
> @@ -146,7 +148,9 @@
>  /* 8 surfaces, at 16 32-bits integers each */
>  #define NVC0_CB_AUX_SU_INFO(i)  0x4a0 + (i) * 16 * 4
>  #define NVC0_CB_AUX_SU_SIZE (NVC0_MAX_IMAGES * 16 * 4)
> -/* 1 64-bits address and 1 32-bits sequence */
> +/* 1 64-bits address and 1 32-bits sequence
> + * be sure to update the shaders in nvc0_query_hw_sm.c when changing this
> + */
>  #define NVC0_CB_AUX_MP_INFO 0x6a0
>  #define NVC0_CB_AUX_MP_SIZE 3 * 4
>  /* 512 64-byte blocks for bindless image handles */
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Update counter reading shaders to new NVC0_CB_AUX_MP_INFO

2018-09-22 Thread Ilia Mirkin
Reviewed-by: Ilia Mirkin 

On Thu, Sep 20, 2018 at 1:10 PM, Rhys Perry  wrote:
> Fixes: 66ca7e400b8 ('nvc0: add support for programmable sample locations')
> Signed-off-by: Rhys Perry 
> ---
>  .../drivers/nouveau/nvc0/nvc0_query_hw_sm.c   | 36 +--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> index df5723dc37..726160d7c0 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_sm.c
> @@ -429,9 +429,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
>  * mov b32 $r6 $pm6
>  * mov b32 $r7 $pm7
>  * set $p0 0x1 eq u32 $r8 0x0
> -* mov b32 $r10 c7[0x620]
> +* mov b32 $r10 c7[0x6a0]
>  * ext u32 $r8 $r12 0x414
> -* mov b32 $r11 c7[0x624]
> +* mov b32 $r11 c7[0x6a4]
>  * sched 0x04 0x2e 0x04 0x20 0x20 0x28 0x04
>  * ext u32 $r9 $r12 0x208
>  * (not $p0) exit
> @@ -449,7 +449,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
>  * add b32 $r12 $c $r12 $r9
>  * st b128 wt g[$r10d] $r0q
>  * sched 0x4 0x2c 0x20 0x04 0x2e 0x00 0x00
> -* mov b32 $r0 c7[0x628]
> +* mov b32 $r0 c7[0x6a8]
>  * add b32 $r13 $r13 0x0 $c
>  * $p1 st b128 wt g[$r12d+0x40] $r4q
>  * st b32 wt g[$r12d+0x50] $r0
> @@ -467,9 +467,9 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
> 0x2c0028019c04ULL,
> 0x2c002c01dc04ULL,
> 0x190efc81dc03ULL,
> -   0x28005c1880029de4ULL,
> +   0x28005c1a80029de4ULL,
> 0x7000c01050c21c03ULL,
> -   0x28005c189002dde4ULL,
> +   0x28005c1a9002dde4ULL,
> 0x204282020042e047ULL,
> 0x7000c00820c25c03ULL,
> 0x800021e7ULL,
> @@ -487,7 +487,7 @@ static const uint64_t nve4_read_hw_sm_counters_code[] =
> 0x480124c31c03ULL,
> 0x94a01fc5ULL,
> 0x22e04202c047ULL,
> -   0x28005c18a0001de4ULL,
> +   0x28005c1aa0001de4ULL,
> 0x08d35c42ULL,
> 0x940100c107c5ULL,
> 0x940140c01f85ULL,
> @@ -510,9 +510,9 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
> 0x8640051c001aULL,
> 0x8640059c001eULL,
> 0xdb201c007f9c201eULL,
> -   0x64c03ce0c41c002aULL,
> +   0x64c03ce0d41c002aULL,
> 0xc0020a1c3021ULL,
> -   0x64c03ce0c49c002eULL,
> +   0x64c03ce0d49c002eULL,
> 0x0810a0808010b810ULL,
> 0xc001041c3025ULL,
> 0x1820003cULL,
> @@ -530,7 +530,7 @@ static const uint64_t nvf0_read_hw_sm_counters_code[] =
> 0xe084049c3032ULL,
> 0xfe80001c2800ULL,
> 0x08b81080b010ULL,
> -   0x64c03ce0c51c0002ULL,
> +   0x64c03ce0d51c0002ULL,
> 0xe08040007f9c3436ULL,
> 0xfe8020043010ULL,
> 0xfc80281c3000ULL,
> @@ -554,10 +554,10 @@ static const uint64_t gm107_read_hw_sm_counters_code[] =
> 0x001f8401fc2007a1ULL, /* sched (st 0x1 wr 0x5) (st 0x1 wt 0x1) (st 0x1)  
>*/
> 0xf0c800b70007ULL, /* mov $r7 $pm7
>*/
> 0x5b6403800087ff07ULL, /* isetp eq u32 and $p0 0x1 0x0 $r8 0x1
>*/
> -   0x4c98079c1887000aULL, /* mov $r10 c7[0x620] 0xf  
>*/
> +   0x4c98079c1a87000aULL, /* mov $r10 c7[0x6a0] 0xf  
>*/
> 0x001fa400fc2017e1ULL, /* sched (st 0x1 wt 0x2) (st 0x1) (st 0x9) 
>*/
> 0x380091470c08ULL, /* bfe u32 $r8 $r12 0x914  
>*/
> -   0x4c98079c1897000bULL, /* mov $r11 c7[0x624] 0xf  
>*/
> +   0x4c98079c1a97000bULL, /* mov $r11 c7[0x6a4] 0xf  
>*/
> 0x380020870c09ULL, /* bfe u32 $r9 $r12 0x208  
>*/
> 0x001c1800fc2007edULL, /* sched (st 0xd) (st 0x1) (st 0x6 wr 0x0) 
>*/
> 0xe308000fULL, /* not $p0 exit
>*/
> @@ -578,7 +578,7 @@ static const uint64_t gm107_read_hw_sm_counters_code[] =
> 0x003f983c1c4007e1ULL, /* sched (st 0x1) (st 0x2 rd 0x0 wt 0x3c) (st 0x6 
> wt 0x1) */
> 0x5c1008000ff70d0dULL, /* iadd x $r13 $r13 0x0
>*/
> 0xbfd70a00ULL, /* st e wt b128 g[$r10] $r0 0x1
>*/
> -   0x4c98079c18a7ULL, /* mov $r0 c7[0x628] 0xf   
>*/
> +   0x4c98079c1aa7ULL, /* mov $r0 c7[0x6a8] 0xf   
>*/
> 0x001fbc00fc2007e6ULL, /* sched (st 0x1) (st 0x1) (st 0xf)
>*/
> 0xbfd004010c04ULL, /* $p1 st e wt b128 g[$r12+0x40] $r4 0x1   
>*/
> 0xbf9005070c00ULL, /* st e wt b32 g[$r12+0x50] $r0 0x1
>*/
> @@ -1760,14 +1760,14 @@ static const uint64_t nvc0_read_hw_sm_counters_code[] 
> =
>  * mov b32 $r6 $pm6
>  * mov b32 $r7 $pm7
>  * set $p0 0x1 

Re: [Mesa-dev] [PATCH mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess

2018-09-22 Thread Jan Vesely
The warning is correct. In the first case, memset tries to zero "Target"
object which has a non-trivial constructor and non-trivial
copy-constructor. The original code is broken in the way it mixes C and C++
initialization and the patch only papers over the issue.
The correct fix would be to provide a proper constructor for structs that
include instances of C++ classes.

Jan

On Sat, Sep 22, 2018 at 6:43 AM Karol Herbst  wrote:

> yeah, I agree here. Either the code was wrong in the first place,
> which means it would have to be fixed properly or the warning is
> wrong. The proper fix here is that GCC should detect itself if it's
> safe to do or not, otherwise that warning becomes a "might be a
> problem" thing which doesn't help at all. Either it is wrong, or it
> isn't. And gcc should be able to know in this case.
>
> On Sat, Sep 22, 2018 at 6:07 AM, Ilia Mirkin  wrote:
> > Based on the various fixes, warning seems bogus -- is the proper
> > solution -Wno-class-memaccess? (Or however one disables such
> > things...)
> >
> > On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
> >  wrote:
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
> >>  src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> >> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction
> *i) const
> >>  TexInstruction::TexInstruction(Function *fn, operation op)
> >> : Instruction(fn, op, TYPE_F32)
> >>  {
> >> -   memset(, 0, sizeof(tex));
> >> +   memset(static_cast(), 0, sizeof(tex));
> >>
> >> tex.rIndirectSrc = -1;
> >> tex.sIndirectSrc = -1;
> >> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
> >> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
> >> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply
> apply)
> >>if (!fixupInfo)
> >>   return false;
> >>if (n == 0)
> >> - memset(fixupInfo, 0, sizeof(FixupInfo));
> >> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
> >> }
> >> ++fixupInfo->count;
> >>
> >> --
> >> Cheers,
> >>   Eric
> >>
> >> ___
> >> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

2018-09-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106151

Rafał Cieślak  changed:

   What|Removed |Added

 CC||rafalcieslak...@ubuntu.com

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


Re: [Mesa-dev] [PATCH] st/mesa: do not call update_framebuffer_size with NULL pointer

2018-09-22 Thread Guillaume Charifi

Reviewed-by: Guillaume Charifi 

Le 20/09/2018 à 10:27, Erik Faye-Lund a écrit :

In st_renderbuffer_alloc_storage, we avoid allocating storage for
zero-sized buffers, leading to this pointer being NULL. We already
take care to avoid dereferencing these pointers for color-buffers,
but not for depth/stencil-buffers.

So let's thread a bit more carefully here.

This avoids a crash while running Piglit's glx/glx-visuals-stencil
test, both on virgl and r600g.

Signed-off-by: Erik Faye-Lund 
---
  src/mesa/state_tracker/st_atom_framebuffer.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_atom_framebuffer.c 
b/src/mesa/state_tracker/st_atom_framebuffer.c
index 807c312a5d..a0dd0d1f64 100644
--- a/src/mesa/state_tracker/st_atom_framebuffer.c
+++ b/src/mesa/state_tracker/st_atom_framebuffer.c
@@ -181,7 +181,8 @@ st_update_framebuffer_state( struct st_context *st )
   st_update_renderbuffer_surface(st, strb);
}
framebuffer.zsbuf = strb->surface;
-  update_framebuffer_size(, strb->surface);
+  if (strb->surface)
+ update_framebuffer_size(, strb->surface);
 }
 else
framebuffer.zsbuf = NULL;


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


[Mesa-dev] [Bug 107170] Build fails if building against X server/libxrandr with no leases support

2018-09-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107170

--- Comment #3 from network...@rkmail.ru ---
Is this bug is still being worked on? It seems that patch never reached GIT
master...

-- 
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 mesa 2/6] nouveau: silence paranoid compiler's -Wclass-memaccess

2018-09-22 Thread Karol Herbst
yeah, I agree here. Either the code was wrong in the first place,
which means it would have to be fixed properly or the warning is
wrong. The proper fix here is that GCC should detect itself if it's
safe to do or not, otherwise that warning becomes a "might be a
problem" thing which doesn't help at all. Either it is wrong, or it
isn't. And gcc should be able to know in this case.

On Sat, Sep 22, 2018 at 6:07 AM, Ilia Mirkin  wrote:
> Based on the various fixes, warning seems bogus -- is the proper
> solution -Wno-class-memaccess? (Or however one disables such
> things...)
>
> On Fri, Sep 21, 2018 at 9:50 AM, Eric Engestrom
>  wrote:
>> Signed-off-by: Eric Engestrom 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 2 +-
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> index 49425b98b9137058c986..62ebc2d24069b7b5f523 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
>> @@ -905,7 +905,7 @@ Instruction::isCommutationLegal(const Instruction *i) 
>> const
>>  TexInstruction::TexInstruction(Function *fn, operation op)
>> : Instruction(fn, op, TYPE_F32)
>>  {
>> -   memset(, 0, sizeof(tex));
>> +   memset(static_cast(), 0, sizeof(tex));
>>
>> tex.rIndirectSrc = -1;
>> tex.sIndirectSrc = -1;
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> index 9193a01f189874a7fb38..b6b9b42964bec670079c 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp
>> @@ -454,7 +454,7 @@ CodeEmitter::addInterp(int ipa, int reg, FixupApply 
>> apply)
>>if (!fixupInfo)
>>   return false;
>>if (n == 0)
>> - memset(fixupInfo, 0, sizeof(FixupInfo));
>> + memset(static_cast(fixupInfo), 0, sizeof(FixupInfo));
>> }
>> ++fixupInfo->count;
>>
>> --
>> Cheers,
>>   Eric
>>
>> ___
>> 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