Re: [Mesa-dev] [PATCH 4/4] radeonsi/nir: gather buffers declared more accurately and use const fast path

[Timothy Arceri]

On 27/03/18 15:19, Timothy Arceri wrote:

For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip
setting the more accurate masks for some builtin uniforms for now as
it causes some piglit regressions.
---
  src/gallium/drivers/radeonsi/si_shader.c |  8 +++
  src/gallium/drivers/radeonsi/si_shader_nir.c | 82 ++--
  2 files changed, 84 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 62cb7ea7eb5..9a12f9ee8f2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2377,8 +2377,16 @@ static LLVMValueRef load_const_buffer_desc(struct 
si_shader_context *ctx, int i)
  static LLVMValueRef load_ubo(struct ac_shader_abi *abi, LLVMValueRef index)
  {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+   struct si_shader_selector *sel = ctx->shader->selector;
+
LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
  
+	if (sel->info.const_buffers_declared == 1 &&

+   sel->info.shader_buffers_declared == 0 &&
+   !(ctx->screen->info.chip_class == SI && HAVE_LLVM < 0x0600)) {
+   return load_const_buffer_desc_fast_path(ctx);
+   }
+
index = si_llvm_bound_index(ctx, index, ctx->num_const_buffers);
index = LLVMBuildAdd(ctx->ac.builder, index,
 LLVMConstInt(ctx->i32, SI_NUM_SHADER_BUFFERS, 0), 
"");
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 52950668714..595f376f6a2 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -611,23 +611,91 @@ void si_nir_scan_shader(const struct nir_shader *nir,
  
  	info->num_outputs = num_outputs;
  
+	struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,

+  _mesa_key_pointer_equal);
+
+   unsigned ubo_idx = 1;
nir_foreach_variable(variable, >uniforms) {
const struct glsl_type *type = variable->type;
enum glsl_base_type base_type =
glsl_get_base_type(glsl_without_array(type));
unsigned aoa_size = MAX2(1, glsl_get_aoa_size(type));
  
+		/* Gather buffers declared bitmasks. Note: radeonsi doesn't

+* really use the mask (other than ubo_idx == 1 for regular
+* uniforms) its really only used for getting the buffer count
+* so we don't need to worry about the ordering.
+*/
+   if (variable->interface_type != NULL) {
+   if (variable->data.mode == nir_var_uniform) {
+
+   unsigned block_size;
+   if (base_type != GLSL_TYPE_INTERFACE) {
+   struct set_entry *entry =
+   _mesa_set_search(ubo_set, 
variable->interface_type);
+
+   /* Check if we have already processed
+* a member from this ubo.
+*/
+   if (entry)
+   continue;
+
+   block_size = 1;
+   } else {
+   block_size = aoa_size;
+   }
+
+   info->const_buffers_declared |= 
u_bit_consecutive(ubo_idx, block_size);
+   ubo_idx += block_size;
+
+   _mesa_set_add(ubo_set, 
variable->interface_type);
+   }
+
+   if (variable->data.mode == nir_var_shader_storage) {
+   /* TODO: make this more accurate */
+   info->shader_buffers_declared =
+   u_bit_consecutive(0, 
SI_NUM_SHADER_BUFFERS);
+   }
+
+   continue;
+   }
+
/* We rely on the fact that nir_lower_samplers_as_deref has
 * eliminated struct dereferences.
 */
-   if (base_type == GLSL_TYPE_SAMPLER)
+   if (base_type == GLSL_TYPE_SAMPLER) {
info->samplers_declared |=
u_bit_consecutive(variable->data.binding, 
aoa_size);
-   else if (base_type == GLSL_TYPE_IMAGE)
+
+   if (variable->data.bindless)
+   info->const_buffers_declared |= 1;
+   } else if (base_type == GLSL_TYPE_IMAGE) {
info->images_declared |=
u_bit_consecutive(variable->data.binding, 

Re: [Mesa-dev] [PATCH 4/4] i965: Drop unnecessary bo->align field.

[Jason Ekstrand]

On March 26, 2018 22:39:33 Jason Ekstrand  wrote:

Some day we may need this because Ys tiled images must be 64K aligned.
However, we can always put it back in.  Rb

If you're not worries about sparse right now (which I wouldn't be), you can 
put my rb on the other too.



On March 26, 2018 16:52:42 Kenneth Graunke  wrote:

bo->align is always 0; there's no need to waste 8 bytes storing it.
Thanks to C99 initializers zeroing fields, we can completely drop the
only read of the field altogether.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 --
src/mesa/drivers/dri/i965/brw_bufmgr.h| 7 ---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 -
3 files changed, 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 83c0286e0da..8ba915b179a 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -320,7 +320,6 @@ retry:
bo = LIST_ENTRY(struct brw_bo, bucket->head.prev, head);
list_del(>head);
alloc_from_cache = true;
- bo->align = 0;
} else {
/* For non-render-target BOs (where we're probably
* going to map it first thing in order to fill it
@@ -381,7 +380,6 @@ retry:
bo->gem_handle = create.handle;

bo->bufmgr = bufmgr;
-  bo->align = 0;

bo->tiling_mode = I915_TILING_NONE;
bo->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index 65e76b27d1b..68f5e0c2c85 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -56,13 +56,6 @@ struct brw_bo {
*/
uint64_t size;

-   /**
-* Alignment requirement for object
-*
-* Used for GTT mapping & pinning the object.
-*/
-   uint64_t align;
-
/** Buffer manager context associated with this buffer object */
struct brw_bufmgr *bufmgr;

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 9147ff82939..ebc02ff3897 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -170,7 +170,6 @@ add_exec_bo(struct intel_batchbuffer *batch, struct
brw_bo *bo)
batch->validation_list[batch->exec_count] =
(struct drm_i915_gem_exec_object2) {
.handle = bo->gem_handle,
- .alignment = bo->align,
.offset = bo->gtt_offset,
.flags = bo->kflags,
};
--
2.16.3

___
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 4/4] i965: Drop unnecessary bo->align field.

[Jason Ekstrand]

Some day we may need this because Ys tiled images must be 64K aligned.  
However, we can always put it back in.  Rb


On March 26, 2018 16:52:42 Kenneth Graunke  wrote:


bo->align is always 0; there's no need to waste 8 bytes storing it.
Thanks to C99 initializers zeroing fields, we can completely drop the
only read of the field altogether.
---
src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 --
src/mesa/drivers/dri/i965/brw_bufmgr.h| 7 ---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 -
3 files changed, 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c

index 83c0286e0da..8ba915b179a 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -320,7 +320,6 @@ retry:
 bo = LIST_ENTRY(struct brw_bo, bucket->head.prev, head);
 list_del(>head);
 alloc_from_cache = true;
- bo->align = 0;
  } else {
 /* For non-render-target BOs (where we're probably
  * going to map it first thing in order to fill it
@@ -381,7 +380,6 @@ retry:
  bo->gem_handle = create.handle;

  bo->bufmgr = bufmgr;
-  bo->align = 0;

  bo->tiling_mode = I915_TILING_NONE;
  bo->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h

index 65e76b27d1b..68f5e0c2c85 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -56,13 +56,6 @@ struct brw_bo {
*/
   uint64_t size;

-   /**
-* Alignment requirement for object
-*
-* Used for GTT mapping & pinning the object.
-*/
-   uint64_t align;
-
   /** Buffer manager context associated with this buffer object */
   struct brw_bufmgr *bufmgr;

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c

index 9147ff82939..ebc02ff3897 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -170,7 +170,6 @@ add_exec_bo(struct intel_batchbuffer *batch, struct 
brw_bo *bo)

   batch->validation_list[batch->exec_count] =
  (struct drm_i915_gem_exec_object2) {
 .handle = bo->gem_handle,
- .alignment = bo->align,
 .offset = bo->gtt_offset,
 .flags = bo->kflags,
  };
--
2.16.3

___
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 4/4] radeonsi/nir: gather buffers declared more accurately and use const fast path

[Timothy Arceri]

On 27/03/18 15:19, Timothy Arceri wrote:

For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip
setting the more accurate masks for some builtin uniforms for now as
it causes some piglit regressions.
---
  src/gallium/drivers/radeonsi/si_shader.c |  8 +++
  src/gallium/drivers/radeonsi/si_shader_nir.c | 82 ++--
  2 files changed, 84 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 62cb7ea7eb5..9a12f9ee8f2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2377,8 +2377,16 @@ static LLVMValueRef load_const_buffer_desc(struct 
si_shader_context *ctx, int i)
  static LLVMValueRef load_ubo(struct ac_shader_abi *abi, LLVMValueRef index)
  {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+   struct si_shader_selector *sel = ctx->shader->selector;
+
LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
  
+	if (sel->info.const_buffers_declared == 1 &&

+   sel->info.shader_buffers_declared == 0 &&
+   !(ctx->screen->info.chip_class == SI && HAVE_LLVM < 0x0600)) {
+   return load_const_buffer_desc_fast_path(ctx);
+   }
+
index = si_llvm_bound_index(ctx, index, ctx->num_const_buffers);
index = LLVMBuildAdd(ctx->ac.builder, index,
 LLVMConstInt(ctx->i32, SI_NUM_SHADER_BUFFERS, 0), 
"");
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 52950668714..595f376f6a2 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -611,23 +611,91 @@ void si_nir_scan_shader(const struct nir_shader *nir,
  
  	info->num_outputs = num_outputs;
  
+	struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,

+  _mesa_key_pointer_equal);
+
+   unsigned ubo_idx = 1;
nir_foreach_variable(variable, >uniforms) {
const struct glsl_type *type = variable->type;
enum glsl_base_type base_type =
glsl_get_base_type(glsl_without_array(type));
unsigned aoa_size = MAX2(1, glsl_get_aoa_size(type));
  
+		/* Gather buffers declared bitmasks. Note: radeonsi doesn't

+* really use the mask (other than ubo_idx == 1 for regular
+* uniforms) its really only used for getting the buffer count
+* so we don't need to worry about the ordering.
+*/
+   if (variable->interface_type != NULL) {
+   if (variable->data.mode == nir_var_uniform) {
+
+   unsigned block_size;
+   if (base_type != GLSL_TYPE_INTERFACE) {
+   struct set_entry *entry =
+   _mesa_set_search(ubo_set, 
variable->interface_type);
+
+   /* Check if we have already processed
+* a member from this ubo.
+*/
+   if (entry)
+   continue;
+
+   block_size = 1;
+   } else {
+   block_size = aoa_size;
+   }
+
+   info->const_buffers_declared |= 
u_bit_consecutive(ubo_idx, block_size);
+   ubo_idx += block_size;
+
+   _mesa_set_add(ubo_set, 
variable->interface_type);
+   }
+
+   if (variable->data.mode == nir_var_shader_storage) {
+   /* TODO: make this more accurate */
+   info->shader_buffers_declared =
+   u_bit_consecutive(0, 
SI_NUM_SHADER_BUFFERS);
+   }
+
+   continue;
+   }
+
/* We rely on the fact that nir_lower_samplers_as_deref has
 * eliminated struct dereferences.
 */
-   if (base_type == GLSL_TYPE_SAMPLER)
+   if (base_type == GLSL_TYPE_SAMPLER) {
info->samplers_declared |=
u_bit_consecutive(variable->data.binding, 
aoa_size);
-   else if (base_type == GLSL_TYPE_IMAGE)
+
+   if (variable->data.bindless)
+   info->const_buffers_declared |= 1;


Whoops this if should also do:

info->const_file_max[0] +=
glsl_count_attribute_slots(type, false);



+ 

[Mesa-dev] [PATCH 1/4] st/glsl_to_nir: gather next_stage in shader_info

[Timothy Arceri]

---
 src/compiler/shader_info.h|  5 +
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 15 +++
 2 files changed, 20 insertions(+)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 0eeb2ca58ea..fcf5cca7b77 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -63,6 +63,11 @@ typedef struct shader_info {
/** The shader stage, such as MESA_SHADER_VERTEX. */
gl_shader_stage stage;
 
+   /** The shader stage in a non SSO linked program that follows this stage,
+ * such as MESA_SHADER_FRAGMENT.
+ */
+   gl_shader_stage next_stage;
+
/* Number of textures used by this shader */
unsigned num_textures;
/* Number of uniform buffers used by this shader */
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index abdb5406a6e..682328b398f 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -367,6 +367,21 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
 
nir_shader *nir = glsl_to_nir(shader_program, stage, options);
 
+   /* Set the next shader stage hint for VS and TES. */
+   if (!nir->info.separate_shader &&
+   (nir->info.stage == MESA_SHADER_VERTEX ||
+nir->info.stage == MESA_SHADER_TESS_EVAL)) {
+
+  unsigned prev_stages = (1 << (prog->info.stage + 1)) - 1;
+  unsigned stages_mask =
+ ~prev_stages & shader_program->data->linked_stages;
+
+  nir->info.next_stage = stages_mask ?
+ (gl_shader_stage) ffs(stages_mask) : MESA_SHADER_FRAGMENT;
+   } else {
+  nir->info.next_stage = MESA_SHADER_FRAGMENT;
+   }
+
nir_variable_mode mask =
   (nir_variable_mode) (nir_var_shader_in | nir_var_shader_out);
nir_remove_dead_variables(nir, mask);
-- 
2.14.3

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

[Mesa-dev] [PATCH 4/4] radeonsi/nir: gather buffers declared more accurately and use const fast path

[Timothy Arceri]

For now we skip SI && HAVE_LLVM < 0x0600 for simplicity. We also skip
setting the more accurate masks for some builtin uniforms for now as
it causes some piglit regressions.
---
 src/gallium/drivers/radeonsi/si_shader.c |  8 +++
 src/gallium/drivers/radeonsi/si_shader_nir.c | 82 ++--
 2 files changed, 84 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 62cb7ea7eb5..9a12f9ee8f2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2377,8 +2377,16 @@ static LLVMValueRef load_const_buffer_desc(struct 
si_shader_context *ctx, int i)
 static LLVMValueRef load_ubo(struct ac_shader_abi *abi, LLVMValueRef index)
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+   struct si_shader_selector *sel = ctx->shader->selector;
+
LLVMValueRef ptr = LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
 
+   if (sel->info.const_buffers_declared == 1 &&
+   sel->info.shader_buffers_declared == 0 &&
+   !(ctx->screen->info.chip_class == SI && HAVE_LLVM < 0x0600)) {
+   return load_const_buffer_desc_fast_path(ctx);
+   }
+
index = si_llvm_bound_index(ctx, index, ctx->num_const_buffers);
index = LLVMBuildAdd(ctx->ac.builder, index,
 LLVMConstInt(ctx->i32, SI_NUM_SHADER_BUFFERS, 0), 
"");
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 52950668714..595f376f6a2 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -611,23 +611,91 @@ void si_nir_scan_shader(const struct nir_shader *nir,
 
info->num_outputs = num_outputs;
 
+   struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
+  _mesa_key_pointer_equal);
+
+   unsigned ubo_idx = 1;
nir_foreach_variable(variable, >uniforms) {
const struct glsl_type *type = variable->type;
enum glsl_base_type base_type =
glsl_get_base_type(glsl_without_array(type));
unsigned aoa_size = MAX2(1, glsl_get_aoa_size(type));
 
+   /* Gather buffers declared bitmasks. Note: radeonsi doesn't
+* really use the mask (other than ubo_idx == 1 for regular
+* uniforms) its really only used for getting the buffer count
+* so we don't need to worry about the ordering.
+*/
+   if (variable->interface_type != NULL) {
+   if (variable->data.mode == nir_var_uniform) {
+
+   unsigned block_size;
+   if (base_type != GLSL_TYPE_INTERFACE) {
+   struct set_entry *entry =
+   _mesa_set_search(ubo_set, 
variable->interface_type);
+
+   /* Check if we have already processed
+* a member from this ubo.
+*/
+   if (entry)
+   continue;
+
+   block_size = 1;
+   } else {
+   block_size = aoa_size;
+   }
+
+   info->const_buffers_declared |= 
u_bit_consecutive(ubo_idx, block_size);
+   ubo_idx += block_size;
+
+   _mesa_set_add(ubo_set, 
variable->interface_type);
+   }
+
+   if (variable->data.mode == nir_var_shader_storage) {
+   /* TODO: make this more accurate */
+   info->shader_buffers_declared =
+   u_bit_consecutive(0, 
SI_NUM_SHADER_BUFFERS);
+   }
+
+   continue;
+   }
+
/* We rely on the fact that nir_lower_samplers_as_deref has
 * eliminated struct dereferences.
 */
-   if (base_type == GLSL_TYPE_SAMPLER)
+   if (base_type == GLSL_TYPE_SAMPLER) {
info->samplers_declared |=
u_bit_consecutive(variable->data.binding, 
aoa_size);
-   else if (base_type == GLSL_TYPE_IMAGE)
+
+   if (variable->data.bindless)
+   info->const_buffers_declared |= 1;
+   } else if (base_type == GLSL_TYPE_IMAGE) {
info->images_declared |=
u_bit_consecutive(variable->data.binding, 
aoa_size);
+
+   

[Mesa-dev] [PATCH 2/4] radeonsi/nir: set TGSI_PROPERTY_NEXT_SHADER

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index d0830424967..52950668714 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -255,6 +255,9 @@ void si_nir_scan_shader(const struct nir_shader *nir,
info->num_tokens = 2; /* indicate that the shader is non-empty */
info->num_instructions = 2;
 
+   info->properties[TGSI_PROPERTY_NEXT_SHADER] =
+   pipe_shader_type_from_mesa(nir->info.next_stage);
+
if (nir->info.stage == MESA_SHADER_TESS_CTRL) {
info->properties[TGSI_PROPERTY_TCS_VERTICES_OUT] =
nir->info.tess.tcs_vertices_out;
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/4] radeonsi: create load_const_buffer_desc_fast_path() helper

[Timothy Arceri]

This will be shared by the TGSI and NIR backends. For simplicity
we leave the SI LLVM 5.0 and lower work around only in the TGSI
backend.
---
 src/gallium/drivers/radeonsi/si_shader.c | 88 ++--
 1 file changed, 49 insertions(+), 39 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index d5607a99d32..62cb7ea7eb5 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -2322,6 +2322,49 @@ void si_tgsi_declare_compute_memory(struct 
si_shader_context *ctx,
si_declare_compute_memory(ctx);
 }
 
+static LLVMValueRef load_const_buffer_desc_fast_path(struct si_shader_context 
*ctx)
+{
+   LLVMValueRef ptr =
+   LLVMGetParam(ctx->main_fn, ctx->param_const_and_shader_buffers);
+   struct si_shader_selector *sel = ctx->shader->selector;
+
+   /* Do the bounds checking with a descriptor, because
+* doing computation and manual bounds checking of 64-bit
+* addresses generates horrible VALU code with very high
+* VGPR usage and very low SIMD occupancy.
+*/
+   ptr = LLVMBuildPtrToInt(ctx->ac.builder, ptr, ctx->ac.intptr, "");
+
+   LLVMValueRef desc0, desc1;
+   if (HAVE_32BIT_POINTERS) {
+   desc0 = ptr;
+   desc1 = LLVMConstInt(ctx->i32,
+
S_008F04_BASE_ADDRESS_HI(ctx->screen->info.address32_hi), 0);
+   } else {
+   ptr = LLVMBuildBitCast(ctx->ac.builder, ptr, ctx->v2i32, "");
+   desc0 = LLVMBuildExtractElement(ctx->ac.builder, ptr, 
ctx->i32_0, "");
+   desc1 = LLVMBuildExtractElement(ctx->ac.builder, ptr, 
ctx->i32_1, "");
+   /* Mask out all bits except BASE_ADDRESS_HI. */
+   desc1 = LLVMBuildAnd(ctx->ac.builder, desc1,
+LLVMConstInt(ctx->i32, 
~C_008F04_BASE_ADDRESS_HI, 0), "");
+   }
+
+   LLVMValueRef desc_elems[] = {
+   desc0,
+   desc1,
+   LLVMConstInt(ctx->i32, (sel->info.const_file_max[0] + 1) * 16, 
0),
+   LLVMConstInt(ctx->i32,
+   S_008F0C_DST_SEL_X(V_008F0C_SQ_SEL_X) |
+   S_008F0C_DST_SEL_Y(V_008F0C_SQ_SEL_Y) |
+   S_008F0C_DST_SEL_Z(V_008F0C_SQ_SEL_Z) |
+   S_008F0C_DST_SEL_W(V_008F0C_SQ_SEL_W) |
+   S_008F0C_NUM_FORMAT(V_008F0C_BUF_NUM_FORMAT_FLOAT) |
+   S_008F0C_DATA_FORMAT(V_008F0C_BUF_DATA_FORMAT_32), 0)
+   };
+
+   return ac_build_gather_values(>ac, desc_elems, 4);
+}
+
 static LLVMValueRef load_const_buffer_desc(struct si_shader_context *ctx, int 
i)
 {
LLVMValueRef list_ptr = LLVMGetParam(ctx->main_fn,
@@ -2400,8 +2443,6 @@ static LLVMValueRef fetch_constant(
/* Fast path when user data SGPRs point to constant buffer 0 directly. 
*/
if (sel->info.const_buffers_declared == 1 &&
sel->info.shader_buffers_declared == 0) {
-   LLVMValueRef ptr =
-   LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
 
/* This enables use of s_load_dword and flat_load_dword for 
const buffer 0
 * loads, and up to x4 load opcode merging. However, it leads 
to horrible
@@ -2416,48 +2457,17 @@ static LLVMValueRef fetch_constant(
 * s_buffer_load_dword (that we have to prevent) is when we use 
use
 * a literal offset where we don't need bounds checking.
 */
-   if (ctx->screen->info.chip_class == SI &&
-HAVE_LLVM < 0x0600 &&
-!reg->Register.Indirect) {
+   if (ctx->screen->info.chip_class == SI && HAVE_LLVM < 0x0600 &&
+   !reg->Register.Indirect) {
+   LLVMValueRef ptr =
+   LLVMGetParam(ctx->main_fn, 
ctx->param_const_and_shader_buffers);
+
addr = LLVMBuildLShr(ctx->ac.builder, addr, 
LLVMConstInt(ctx->i32, 2, 0), "");
LLVMValueRef result = ac_build_load_invariant(>ac, 
ptr, addr);
return bitcast(bld_base, type, result);
}
 
-   /* Do the bounds checking with a descriptor, because
-* doing computation and manual bounds checking of 64-bit
-* addresses generates horrible VALU code with very high
-* VGPR usage and very low SIMD occupancy.
-*/
-   ptr = LLVMBuildPtrToInt(ctx->ac.builder, ptr, ctx->ac.intptr, 
"");
-
-   LLVMValueRef desc0, desc1;
-   if (HAVE_32BIT_POINTERS) {
-   desc0 = ptr;
-   desc1 = LLVMConstInt(ctx->i32,
-
S_008F04_BASE_ADDRESS_HI(ctx->screen->info.address32_hi), 0);
-  

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #11 from Ilia Mirkin  ---
As an aside... there's no compilation bug here. Perhaps $other driver happens
to get you a value of 0, but nothing guarantees that. Could just be luck in
precisely how they do RA. Certainly nothing in the spec.

And there are legitimate situations where a variable might be uninitialized
prior to (compiler-proven) use, e.g.

int x;
int y = 0;
loop {
  if (a)
y += x;
  if (b)
x = 5;
}

The compiler couldn't reasonably prove that a never happens before b does
(except in some circumstances).

Would it be the end of the world if one were to add code to zero-initialize all
variables? No - but it'd add unnecessary code to otherwise functioning shaders.

Mesa tends to stick to what's required by the spec.

(You could argue that the "shader has gone into infinite loop" case should be
handled better, with some success, but that's obviously a very
driver-backend-specific issue.)

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #10 from Ilia Mirkin  ---
(In reply to Swyter from comment #9)
> @imirkin I'm just doing this, nothing too fancy:
> 
> > glEnable(GL_DEBUG_OUTPUT);
> > glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS); GL_ASSERT;
> > glDebugMessageCallback(GLErrorCallback, NULL); GL_ASSERT;
> > glDebugMessageControl(
> > GL_DONT_CARE,
> > GL_DONT_CARE,
> > GL_DONT_CARE,
> > 0,
> > NULL,
> > TRUE
> > ); GL_ASSERT;
> 
> If you take a look at the game log above you can see that it spits the
> compiler info stats. Maybe I'm doing something wrong.

A couple of stupid questions:

1. Could you be feeding the shader to glCompileShader before the above lines?
2. Could the end user have already cached the compilation of this shader?

For the latter, one can run with MESA_GLSL_CACHE_DISABLE=1 to avoid using the
cache.

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #9 from Swyter  ---
@imirkin I'm just doing this, nothing too fancy:

>   glEnable(GL_DEBUG_OUTPUT);
>   glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS); GL_ASSERT;
>   glDebugMessageCallback(GLErrorCallback, NULL); GL_ASSERT;
>   glDebugMessageControl(
>   GL_DONT_CARE,
>   GL_DONT_CARE,
>   GL_DONT_CARE,
>   0,
>   NULL,
>   TRUE
>   ); GL_ASSERT;

If you take a look at the game log above you can see that it spits the compiler
info stats. Maybe I'm doing something wrong.

Anyway, here is a backtrace from a customer using i965 with an Intel(R) HD
Graphics 520. He is running a release build of Mesa, so it doesn't come with
debug symbols, but you can see that it is stuck at a DRI syscall at the end of
the frame, just like you said:

https://www.reddit.com/r/linux_gaming/comments/81t838/sphinx_and_the_cursed_mummy_freezes_at_intro/dvjsvop/


The only thing that appears in the stdout/err log from the driver side is this:

> i965: Failed to submit batchbuffer: Input/output error

(https://www.reddit.com/r/linux_gaming/comments/81t838/sphinx_and_the_cursed_mummy_freezes_at_intro/dvjhza6/)

Some of the other replies in that reddit thread may be of interest. I told him
to use the LIBGL_DEBUG=verbose env var, but it doesn't look too chatty.

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #8 from Ilia Mirkin  ---
(In reply to Swyter from comment #5)
> Created attachment 138368 [details]
> game-log-with-debug-ogl-context-and-callback-no-undefined-warns.txt
> 
> @imirkin Looks like these GLSL warnings aren't exposed through
> GL_ARB_debug_output/GL_KHR_debug callbacks. I originally developed the Linux

That's very surprising.

This stuff goes through _mesa_glsl_warning which in turn should emit a
DEBUG_TYPE_OTHER message. Are you sure that you don't get a callback with that?
(Or perhaps you have it just filtering to ERROR's?)

-- 
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 2/8] util: Add and use util_is_power_of_two_nonzero

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
Reviewed-by: Eduardo Lima Mitev 
---
 src/compiler/nir/nir_search_helpers.h | 13 -
 src/compiler/nir/nir_validate.c   |  2 +-
 src/gallium/drivers/etnaviv/etnaviv_blt.c |  2 +-
 src/intel/compiler/brw_fs.cpp |  4 ++--
 src/util/bitscan.h| 11 +++
 5 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/src/compiler/nir/nir_search_helpers.h 
b/src/compiler/nir/nir_search_helpers.h
index 2d399bd5dcd..8bc6d723c34 100644
--- a/src/compiler/nir/nir_search_helpers.h
+++ b/src/compiler/nir/nir_search_helpers.h
@@ -28,12 +28,7 @@
 #define _NIR_SEARCH_HELPERS_
 
 #include "nir.h"
-
-static inline bool
-__is_power_of_two(unsigned int x)
-{
-   return ((x != 0) && !(x & (x - 1)));
-}
+#include "util/bitscan.h"
 
 static inline bool
 is_pos_power_of_two(nir_alu_instr *instr, unsigned src, unsigned 
num_components,
@@ -50,11 +45,11 @@ is_pos_power_of_two(nir_alu_instr *instr, unsigned src, 
unsigned num_components,
   case nir_type_int:
  if (val->i32[swizzle[i]] < 0)
 return false;
- if (!__is_power_of_two(val->i32[swizzle[i]]))
+ if (!util_is_power_of_two_nonzero(val->i32[swizzle[i]]))
 return false;
  break;
   case nir_type_uint:
- if (!__is_power_of_two(val->u32[swizzle[i]]))
+ if (!util_is_power_of_two_nonzero(val->u32[swizzle[i]]))
 return false;
  break;
   default:
@@ -80,7 +75,7 @@ is_neg_power_of_two(nir_alu_instr *instr, unsigned src, 
unsigned num_components,
   case nir_type_int:
  if (val->i32[swizzle[i]] > 0)
 return false;
- if (!__is_power_of_two(abs(val->i32[swizzle[i]])))
+ if (!util_is_power_of_two_nonzero(abs(val->i32[swizzle[i]])))
 return false;
  break;
   default:
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index 725ba43152c..565cb2ef163 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -982,7 +982,7 @@ validate_var_decl(nir_variable *var, bool is_global, 
validate_state *state)
validate_assert(state, is_global == nir_variable_is_global(var));
 
/* Must have exactly one mode set */
-   validate_assert(state, util_bitcount(var->data.mode) == 1);
+   validate_assert(state, util_is_power_of_two_nonzero(var->data.mode));
 
if (var->data.compact) {
   /* The "compact" flag is only valid on arrays of scalars. */
diff --git a/src/gallium/drivers/etnaviv/etnaviv_blt.c 
b/src/gallium/drivers/etnaviv/etnaviv_blt.c
index c30c11ab61e..52731a9c770 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_blt.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_blt.c
@@ -178,7 +178,7 @@ emit_blt_copyimage(struct etna_cmd_stream *stream, const 
struct blt_imgcopy_op *
 static void
 emit_blt_inplace(struct etna_cmd_stream *stream, const struct blt_inplace_op 
*op)
 {
-   assert(op->bpp > 0 && util_is_power_of_two_or_zero(op->bpp));
+   assert(op->bpp > 0 && util_is_power_of_two_nonzero(op->bpp));
etna_cmd_stream_reserve(stream, 64*2); /* Never allow BLT sequences to be 
broken up */
etna_set_state(stream, VIVS_BLT_ENABLE, 0x0001);
etna_set_state(stream, VIVS_BLT_CONFIG,
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index fdcc909a3d5..40896db26b3 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -1976,7 +1976,7 @@ struct cplx_align {
 static void
 cplx_align_assert_sane(struct cplx_align a)
 {
-   assert(a.mul > 0 && util_is_power_of_two_or_zero(a.mul));
+   assert(a.mul > 0 && util_is_power_of_two_nonzero(a.mul));
assert(a.offset < a.mul);
 }
 
@@ -2028,7 +2028,7 @@ static void
 mark_uniform_slots_read(struct uniform_slot_info *slots,
 unsigned num_slots, unsigned alignment)
 {
-   assert(alignment > 0 && util_is_power_of_two_or_zero(alignment));
+   assert(alignment > 0 && util_is_power_of_two_nonzero(alignment));
assert(alignment <= CPLX_ALIGN_MAX_MUL);
 
/* We can't align a slot to anything less than the slot size */
diff --git a/src/util/bitscan.h b/src/util/bitscan.h
index 2d4e46ec0f1..a3f2d414bd6 100644
--- a/src/util/bitscan.h
+++ b/src/util/bitscan.h
@@ -119,6 +119,17 @@ util_is_power_of_two_or_zero(unsigned v)
return (v & (v - 1)) == 0;
 }
 
+/* Determine if an unsigned value is a power of two.
+ *
+ * \note
+ * Zero is \b not treated as a power of two.
+ */
+static inline bool
+util_is_power_of_two_nonzero(unsigned v)
+{
+   return v != 0 && (v & (v - 1)) == 0;
+}
+
 /* For looping over a bitmask when you want to loop over consecutive bits
  * manually, for example:
  *
-- 
2.14.3

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

[Mesa-dev] [PATCH 6/8] compiler: All leaf Makefile.am should use +=

[Ian Romanick]

From: Ian Romanick 

This slightly simplifies later changes that add more Makefile.*.am
files.

Signed-off-by: Ian Romanick 
Reviewed-by: Eduardo Lima Mitev 
---
 src/compiler/Makefile.am  | 1 +
 src/compiler/Makefile.glsl.am | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index fd6811ff26e..18c062019f0 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -53,6 +53,7 @@ noinst_LTLIBRARIES = libcompiler.la
 
 libcompiler_la_SOURCES = $(LIBCOMPILER_FILES)
 
+noinst_PROGRAMS =
 check_PROGRAMS =
 TESTS =
 BUILT_SOURCES =
diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index 179f415fe6f..ad19b14e446 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -54,7 +54,7 @@ check_PROGRAMS += \
glsl/tests/sampler-types-test   \
glsl/tests/uniform-initializer-test
 
-noinst_PROGRAMS = glsl_compiler
+noinst_PROGRAMS += glsl_compiler
 
 glsl_tests_blob_test_SOURCES = \
glsl/tests/blob_test.c
-- 
2.14.3

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

[Mesa-dev] [PATCH 4/8] util: Optimize util_is_power_of_two_nonzero

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
Suggested-by: Matt Turner 
Reviewed-by: Eduardo Lima Mitev 
---
 src/util/bitscan.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/util/bitscan.h b/src/util/bitscan.h
index a3f2d414bd6..5cc75f0beba 100644
--- a/src/util/bitscan.h
+++ b/src/util/bitscan.h
@@ -38,6 +38,10 @@
 #include 
 #endif
 
+#if defined(__POPCNT__)
+#include 
+#endif
+
 #include "c99_compat.h"
 
 #ifdef __cplusplus
@@ -127,7 +131,20 @@ util_is_power_of_two_or_zero(unsigned v)
 static inline bool
 util_is_power_of_two_nonzero(unsigned v)
 {
+   /* __POPCNT__ is different from HAVE___BUILTIN_POPCOUNT.  The latter
+* indicates the existence of the __builtin_popcount function.  The former
+* indicates that _mm_popcnt_u32 exists and is a native instruction.
+*
+* The other alternative is to use SSE 4.2 compile-time flags.  This has
+* two drawbacks.  First, there is currently no build infrastructure for
+* SSE 4.2 (only 4.1), so that would have to be added.  Second, some AMD
+* CPUs support POPCNT but not SSE 4.2 (e.g., Barcelona).
+*/
+#ifdef __POPCNT__
+   return _mm_popcnt_u32(v) == 1;
+#else
return v != 0 && (v & (v - 1)) == 0;
+#endif
 }
 
 /* For looping over a bitmask when you want to loop over consecutive bits
-- 
2.14.3

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

[Mesa-dev] [PATCH 1/8] util: Move util_is_power_of_two to bitscan.h and rename to util_is_power_of_two_or_zero

[Ian Romanick]

From: Ian Romanick 

The new name make the zero-input behavior more obvious.  The next
patch adds a new function with different zero-input behavior.

Signed-off-by: Ian Romanick 
Suggested-by: Matt Turner 
---
 src/amd/common/ac_gpu_info.c |  4 ++--
 src/amd/common/ac_surface.c  |  2 +-
 src/amd/vulkan/radv_formats.c|  4 ++--
 src/broadcom/compiler/nir_to_vir.c   |  4 ++--
 src/gallium/auxiliary/gallivm/lp_bld_arit.c  |  2 +-
 src/gallium/auxiliary/gallivm/lp_bld_debug.cpp   |  2 +-
 src/gallium/auxiliary/gallivm/lp_bld_format_aos.c|  4 ++--
 src/gallium/auxiliary/gallivm/lp_bld_gather.c|  8 
 src/gallium/auxiliary/gallivm/lp_bld_pack.c  |  2 +-
 src/gallium/auxiliary/gallivm/lp_bld_sample.c|  6 +++---
 src/gallium/auxiliary/util/u_math.h  | 10 +-
 src/gallium/auxiliary/util/u_ringbuffer.c|  2 +-
 src/gallium/drivers/etnaviv/etnaviv_blt.c|  2 +-
 src/gallium/drivers/etnaviv/etnaviv_texture_state.c  |  3 ++-
 src/gallium/drivers/freedreno/freedreno_query_hw.c   |  2 +-
 src/gallium/drivers/i915/i915_state_sampler.c|  3 ++-
 src/gallium/drivers/llvmpipe/lp_state_fs.c   |  2 +-
 src/gallium/drivers/llvmpipe/lp_texture.c|  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir.cpp  |  2 +-
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp |  4 ++--
 src/gallium/drivers/nouveau/nv30/nv30_miptree.c  |  6 +++---
 src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c   |  2 +-
 src/gallium/drivers/r300/r300_texture_desc.c |  6 +++---
 src/gallium/drivers/r600/r600_texture.c  |  2 +-
 src/gallium/drivers/radeon/r600_texture.c|  2 +-
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c  |  2 +-
 src/gallium/drivers/softpipe/sp_texture.c| 12 ++--
 src/gallium/drivers/swr/swr_screen.cpp   |  4 ++--
 src/gallium/drivers/vc4/vc4_program.c|  4 ++--
 src/intel/compiler/brw_fs.cpp|  4 ++--
 src/intel/vulkan/anv_allocator.c |  6 +++---
 src/intel/vulkan/anv_formats.c   |  4 ++--
 src/intel/vulkan/anv_nir_lower_multiview.c   |  2 +-
 src/mesa/state_tracker/st_cb_readpixels.c|  4 ++--
 src/mesa/state_tracker/st_cb_texture.c   |  6 +++---
 src/util/bitscan.h   | 12 
 src/util/u_vector.c  |  4 ++--
 37 files changed, 79 insertions(+), 73 deletions(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 73b5da0fe18..fe993824151 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -331,8 +331,8 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
}
info->has_virtual_memory = true;
 
-   assert(util_is_power_of_two(dma.available_rings + 1));
-   assert(util_is_power_of_two(compute.available_rings + 1));
+   assert(util_is_power_of_two_or_zero(dma.available_rings + 1));
+   assert(util_is_power_of_two_or_zero(compute.available_rings + 1));
 
info->num_sdma_rings = util_bitcount(dma.available_rings);
info->num_compute_rings = util_bitcount(compute.available_rings);
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 92bdf1dedec..cca273b8606 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -271,7 +271,7 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
AddrSurfInfoIn->bpp) {
unsigned alignment = 256 / (AddrSurfInfoIn->bpp / 8);
 
-   assert(util_is_power_of_two(AddrSurfInfoIn->bpp));
+   assert(util_is_power_of_two_or_zero(AddrSurfInfoIn->bpp));
AddrSurfInfoIn->width = align(AddrSurfInfoIn->width, alignment);
}
 
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index da341a3a848..56b1edaed07 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -602,13 +602,13 @@ radv_physical_device_get_format_properties(struct 
radv_physical_device *physical
tiled |= 
VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT;
}
}
-   if (tiled && 
util_is_power_of_two(vk_format_get_blocksize(format)) && !scaled) {
+   if (tiled && 
util_is_power_of_two_or_zero(vk_format_get_blocksize(format)) && !scaled) {
tiled |= VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR |
 VK_FORMAT_FEATURE_TRANSFER_DST_BIT_KHR;
}
}
 
-   if (linear 

[Mesa-dev] [PATCH 8/8] i965: Silence unused parameter warning

[Ian Romanick]

From: Ian Romanick 

src/mesa/drivers/dri/i965/brw_draw_upload.c: In function ‘double_types’:
src/mesa/drivers/dri/i965/brw_draw_upload.c:225:34: warning: unused parameter 
‘brw’ [-Wunused-parameter]
 double_types(struct brw_context *brw,
  ^~~

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_draw_upload.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c 
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 4ede33aea17..344e2f2b4ee 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -222,9 +222,7 @@ static const GLuint byte_types_scale[5] = {
 };
 
 static GLuint
-double_types(struct brw_context *brw,
- int size,
- GLboolean doubles)
+double_types(int size, GLboolean doubles)
 {
/* From the BDW PRM, Volume 2d, page 588 (VERTEX_ELEMENT_STATE):
 * "When SourceElementFormat is set to one of the *64*_PASSTHRU formats,
@@ -292,7 +290,7 @@ brw_get_vertex_surface_type(struct brw_context *brw,
   return ISL_FORMAT_R11G11B10_FLOAT;
} else if (glattrib->Normalized) {
   switch (glattrib->Type) {
-  case GL_DOUBLE: return double_types(brw, size, glattrib->Doubles);
+  case GL_DOUBLE: return double_types(size, glattrib->Doubles);
   case GL_FLOAT: return float_types[size];
   case GL_HALF_FLOAT:
   case GL_HALF_FLOAT_OES:
@@ -371,7 +369,7 @@ brw_get_vertex_surface_type(struct brw_context *brw,
   }
   assert(glattrib->Format == GL_RGBA); /* sanity check */
   switch (glattrib->Type) {
-  case GL_DOUBLE: return double_types(brw, size, glattrib->Doubles);
+  case GL_DOUBLE: return double_types(size, glattrib->Doubles);
   case GL_FLOAT: return float_types[size];
   case GL_HALF_FLOAT:
   case GL_HALF_FLOAT_OES:
-- 
2.14.3

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

[Mesa-dev] [PATCH 5/8] util: Include bitscan.h directly

[Ian Romanick]

From: Ian Romanick 

Previously bitset.h would include u_math.h to get bitscan.h.  u_math.h
lives in src/gallium/auxiliary/util while both bitset.h and bitscan.h
live in src/util.  Having the one file directly include another file
that lives in the same directory makes much more sense.

As a side-effect, several files need to directly include standard header
files that were previously indirectly included.

v2: Fix build break in src/amd/common/ac_nir_to_llvm.c.

Signed-off-by: Ian Romanick 
Reviewed-by: Eduardo Lima Mitev 
---
 src/amd/common/ac_nir_to_llvm.c  | 1 +
 src/compiler/nir/nir.c   | 1 +
 src/compiler/spirv/vtn_alu.c | 1 +
 src/compiler/spirv/vtn_glsl450.c | 1 +
 src/util/bitset.h| 2 +-
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b7d29ef0b53..dfd1ea05ba1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -28,6 +28,7 @@
 #include "sid.h"
 #include "nir/nir.h"
 #include "util/bitscan.h"
+#include "util/u_math.h"
 #include "ac_shader_abi.h"
 #include "ac_shader_util.h"
 
diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index a97b119bf72..3fb16e6ca5f 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -28,6 +28,7 @@
 #include "nir.h"
 #include "nir_control_flow_private.h"
 #include "util/half_float.h"
+#include 
 #include 
 #include 
 
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 01be397e271..fc378495b81 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -21,6 +21,7 @@
  * IN THE SOFTWARE.
  */
 
+#include 
 #include "vtn_private.h"
 
 /*
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 7d32914d516..eb0b90f7976 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -25,6 +25,7 @@
  *
  */
 
+#include 
 #include "vtn_private.h"
 #include "GLSL.std.450.h"
 
diff --git a/src/util/bitset.h b/src/util/bitset.h
index b4c21520238..75e29a9a519 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -31,7 +31,7 @@
 #ifndef BITSET_H
 #define BITSET_H
 
-#include "util/u_math.h"
+#include "util/bitscan.h"
 
 /
  * generic bitset implementation
-- 
2.14.3

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

[Mesa-dev] [PATCH 3/8] util: Use util_is_power_of_two_nonzero in u_vector

[Ian Romanick]

From: Ian Romanick 

Previously size=0, element_size=0 would have been allowed.  That
combination can only lead to despair.

Signed-off-by: Ian Romanick 
---
 src/util/u_vector.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/util/u_vector.c b/src/util/u_vector.c
index bec6e5bbc30..15f8ed6bdad 100644
--- a/src/util/u_vector.c
+++ b/src/util/u_vector.c
@@ -37,8 +37,8 @@
 int
 u_vector_init(struct u_vector *vector, uint32_t element_size, uint32_t size)
 {
-   assert(util_is_power_of_two_or_zero(size));
-   assert(element_size < size && util_is_power_of_two_or_zero(element_size));
+   assert(util_is_power_of_two_nonzero(size));
+   assert(element_size < size && util_is_power_of_two_nonzero(element_size));
 
vector->head = 0;
vector->tail = 0;
-- 
2.14.3

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

[Mesa-dev] [MOSTLY RESEND PATCH 0/8] Emit SPIR-V pre-pre-work

[Ian Romanick]

Most of these patches have been on the list at least once.  Major
changes are:

- Patches 1, 6, and 7 had a bunch of changes due to rebasing.

- Patches 2 had some minor changes due to rebasing.

- Patches 3 and 8 are new.

Only patches 4 and 5 should be unchanged.  The whole series passes the
Intel CI, but I haven't tested the changes to other drivers.

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

[Mesa-dev] [PATCH 7/8] spirv: Move SPIR-V building to Makefile.spirv.am and spirv/meson.build

[Ian Romanick]

From: Ian Romanick 

Future changes will add generated files used only from
src/compiler/glsl.  These can't be built from Makefile.nir.am, and we
can't move all the rules from Makefile.nir.am to Makefile.spirv.am (and
it would be silly anyway).

v2: Do it for meson too.

Signed-off-by: Ian Romanick 
Reviewed-by: Eric Engestrom  (the meson bits)
---
 src/compiler/Makefile.am   |  2 ++
 src/compiler/Makefile.nir.am   | 36 ++--
 src/compiler/Makefile.spirv.am | 54 ++
 src/compiler/meson.build   |  5 
 src/compiler/nir/meson.build   | 15 
 src/compiler/spirv/meson.build | 26 
 6 files changed, 89 insertions(+), 49 deletions(-)
 create mode 100644 src/compiler/Makefile.spirv.am
 create mode 100644 src/compiler/spirv/meson.build

diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index 18c062019f0..8ec9b0449ca 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -69,6 +69,8 @@ EXTRA_DIST = \
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
 
+include Makefile.spirv.am
+
 include Makefile.glsl.am
 
 include Makefile.nir.am
diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
index 28033256762..0b9d419c6a6 100644
--- a/src/compiler/Makefile.nir.am
+++ b/src/compiler/Makefile.nir.am
@@ -52,33 +52,6 @@ nir/nir_opt_algebraic.c: nir/nir_opt_algebraic.py 
nir/nir_algebraic.py
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/nir/nir_opt_algebraic.py > $@ || ($(RM) $@; 
false)
 
-spirv/spirv_info.c: spirv/spirv_info_c.py spirv/spirv.core.grammar.json
-   $(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/spirv/spirv_info_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
-
-spirv/vtn_gather_types.c: spirv/vtn_gather_types_c.py 
spirv/spirv.core.grammar.json
-   $(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/spirv/vtn_gather_types_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
-
-noinst_PROGRAMS += spirv2nir
-
-spirv2nir_SOURCES = \
-   spirv/spirv2nir.c
-
-spirv2nir_CPPFLAGS =   \
-   $(AM_CPPFLAGS)  \
-   -I$(top_builddir)/src/compiler/nir  \
-   -I$(top_srcdir)/src/compiler/nir\
-   -I$(top_srcdir)/src/compiler/spirv
-
-spirv2nir_LDADD =  \
-   nir/libnir.la   \
-   $(top_builddir)/src/util/libmesautil.la \
-   -lm \
-   $(PTHREAD_LIBS)
-
-nodist_EXTRA_spirv2nir_SOURCES = dummy.cpp
-
 check_PROGRAMS += nir/tests/control_flow_tests
 
 nir_tests_control_flow_tests_CPPFLAGS = \
@@ -101,12 +74,10 @@ TESTS += nir/tests/control_flow_tests
 
 
 BUILT_SOURCES += \
-   $(NIR_GENERATED_FILES) \
-   $(SPIRV_GENERATED_FILES)
+   $(NIR_GENERATED_FILES)
 
 CLEANFILES += \
-   $(NIR_GENERATED_FILES) \
-   $(SPIRV_GENERATED_FILES)
+   $(NIR_GENERATED_FILES)
 
 EXTRA_DIST += \
nir/nir_algebraic.py\
@@ -118,7 +89,4 @@ EXTRA_DIST += \
nir/nir_opt_algebraic.py\
nir/tests \
nir/README \
-   spirv/spirv_info_c.py   \
-   spirv/spirv.core.grammar.json   \
-   spirv/vtn_gather_types_c.py \
SConscript.nir
diff --git a/src/compiler/Makefile.spirv.am b/src/compiler/Makefile.spirv.am
new file mode 100644
index 000..9841004d540
--- /dev/null
+++ b/src/compiler/Makefile.spirv.am
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2017 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+# IN THE SOFTWARE.
+
+spirv/spirv_info.c: spirv/spirv_info_c.py 

Re: [Mesa-dev] [PATCH 1/4] i965: Drop BO_ALLOC_BUSY in intel_miptree_create_for_bo().

[Jason Ekstrand]

Rb

On March 26, 2018 16:52:40 Kenneth Graunke  wrote:


intel_miptree_create_for_bo does not actually allocate a BO, so
specifying allocation flags accomplishes nothing and is confusing.
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c

index c6213b21629..23cb40f3226 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -820,7 +820,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
devinfo->gen >= 6 ? depth_only_format : format,
0, 0, width, height, depth, 1, ISL_TILING_Y0_BIT,
ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
-BO_ALLOC_BUSY, pitch, bo);
+0, pitch, bo);
  if (!mt)
 return NULL;

@@ -836,7 +836,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
ISL_TILING_W_BIT,
ISL_SURF_USAGE_STENCIL_BIT |
ISL_SURF_USAGE_TEXTURE_BIT,
-BO_ALLOC_BUSY, pitch, bo);
+0, pitch, bo);
  if (!mt)
 return NULL;

--
2.16.3

___
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #7 from Ilia Mirkin  ---
(In reply to Ian Romanick from comment #6)
> Swyter: Can you run your program in gdb, interrupt it during the hang, and
> provide a backtrace?
> 
> Reading Ilia's response, it seems that the trivial glslsparsertest based
> test case doesn't reproduce the hang.  I guess a shader-runner test that
> tries to draw with the shader would...

glslparsertest just parses. The hang is just due to a very long shader loop
(sometimes, I'd guess, depending what 'i' happens to get initialized to... like
MIN_INT, it'll be looping for a while). gdb would just show it hung in "waiting
for draw to complete".

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #6 from Ian Romanick  ---
Swyter: Can you run your program in gdb, interrupt it during the hang, and
provide a backtrace?

Reading Ilia's response, it seems that the trivial glslsparsertest based test
case doesn't reproduce the hang.  I guess a shader-runner test that tries to
draw with the shader would...

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

Swyter  changed:

   What|Removed |Added

 CC||swyterzone+mes...@gmail.com

--- Comment #5 from Swyter  ---
Created attachment 138368
  --> https://bugs.freedesktop.org/attachment.cgi?id=138368=edit
game-log-with-debug-ogl-context-and-callback-no-undefined-warns.txt

@imirkin Looks like these GLSL warnings aren't exposed through
GL_ARB_debug_output/GL_KHR_debug callbacks. I originally developed the Linux
port using Mesa/radeonsi on a [AMD/ATI] Kaveri [Radeon R7 Graphics] (rev d4)
(PCI ID 1002:130f) and the warnings and error reporting always proved useful,
but that was before I implemented the dynamic lights part. I need to test if
the newer version of the game (with the attached shader) lock ups AMD/radeon
cards, too.

Anyway, thanks for the piglit tip. I'll use it from now on to lint my shaders,
hopefully they'll end up slightly less 'freezy'.

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

Re: [Mesa-dev] [PATCH v3 4/8] intel: Handle firstvertex in an identical way to BaseVertex

[Ian Romanick]

It looks like there are a couple places in brw_fs_nir.cpp
(emit_system_values_block and fs_visitor::nir_emit_vs_intrinsic) that
handle nir_intrinsic_load_base_instance but not
nir_intrinsic_load_first_vertex.  Should those cases be added?

I have pushed a branch to my fd.o repo called gl_VertexID-fixes that
rebases this series on current master.  I had to apply some fixes to the
last patch in the series to get it to build.  I have tested that whole
series patch-by-patch in the CI with no regressions.  I have also
applied my R-b on several patches in the series.  I think once we decide
what to do about this patch and the squash! patch in my branch, we can
(finally) push this.

On 01/25/2018 10:15 AM, Antia Puentes wrote:
> Until we set gl_BaseVertex to zero for non-indexed draw calls
> both have an identical value.
> 
> The Vertex Elements are kept like that:
> * VE 1: 
> * VE 2: 
> ---
>  src/intel/compiler/brw_nir.c  |  3 +++
>  src/intel/compiler/brw_vec4.cpp   |  1 +
>  src/mesa/drivers/dri/i965/brw_context.h   |  8 ++--
>  src/mesa/drivers/dri/i965/brw_draw.c  | 14 +-
>  src/mesa/drivers/dri/i965/brw_draw_upload.c   |  7 +--
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 +++
>  6 files changed, 31 insertions(+), 13 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index dbddef0d04d..34b1e44adf0 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -239,6 +239,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
> const bool has_sgvs =
>nir->info.system_values_read &
>(BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
> +   BITFIELD64_BIT(SYSTEM_VALUE_FIRST_VERTEX) |
> BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
> BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
> BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID));
> @@ -261,6 +262,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
>  
>  switch (intrin->intrinsic) {
>  case nir_intrinsic_load_base_vertex:
> +case nir_intrinsic_load_first_vertex:
>  case nir_intrinsic_load_base_instance:
>  case nir_intrinsic_load_vertex_id_zero_base:
>  case nir_intrinsic_load_instance_id:
> @@ -278,6 +280,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
> nir_intrinsic_set_base(load, num_inputs);
> switch (intrin->intrinsic) {
> case nir_intrinsic_load_base_vertex:
> +   case nir_intrinsic_load_first_vertex:
>nir_intrinsic_set_component(load, 0);
>break;
> case nir_intrinsic_load_base_instance:
> diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
> index 36e17d77d47..06c79630119 100644
> --- a/src/intel/compiler/brw_vec4.cpp
> +++ b/src/intel/compiler/brw_vec4.cpp
> @@ -2788,6 +2788,7 @@ brw_compile_vs(const struct brw_compiler *compiler, 
> void *log_data,
>  */
> if (shader->info.system_values_read &
> (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
> +BITFIELD64_BIT(SYSTEM_VALUE_FIRST_VERTEX) |
>  BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
>  BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
>  BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))) {
> diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
> b/src/mesa/drivers/dri/i965/brw_context.h
> index 9046acd175c..0a20706567e 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.h
> +++ b/src/mesa/drivers/dri/i965/brw_context.h
> @@ -881,8 +881,12 @@ struct brw_context
>  
> struct {
>struct {
> - /** The value of gl_BaseVertex for the current _mesa_prim. */
> - int gl_basevertex;
> + /**
> +  * Either the value of gl_BaseVertex for indexed draw calls or the
> +  * value of the argument  for non-indexed draw calls for the
> +  * current _mesa_prim.
> +  */
> + int firstvertex;
>  
>   /** The value of gl_BaseInstance for the current _mesa_prim. */
>   int gl_baseinstance;
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 50cf8b12c74..a1a5161fd35 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -816,25 +816,29 @@ brw_draw_single_prim(struct gl_context *ctx,
>  * always flag if the shader uses one of the values. For direct draws,
>  * we only flag if the values change.
>  */
> -   const int new_basevertex =
> +   const int new_firstvertex =
>prim->indexed ? prim->basevertex : prim->start;
> const int new_baseinstance = prim->base_instance;
> const struct brw_vs_prog_data *vs_prog_data =
>brw_vs_prog_data(brw->vs.base.prog_data);
> if (prim_id > 0) {
> -  const bool uses_draw_parameters =
> +  const bool uses_firstvertex =
>   

[Mesa-dev] [PATCH 3/4] radeonsi: don't use the SPI barrier management bug workaround

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 8ae742c93f6..00ebbb9b0f2 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -7964,20 +7964,25 @@ static bool si_shader_select_ps_parts(struct si_screen 
*sscreen,
if (!shader->key.part.ps.epilog.poly_line_smoothing &&
!shader->selector->info.reads_samplemask)
shader->config.spi_ps_input_ena &= C_0286CC_SAMPLE_COVERAGE_ENA;
 
return true;
 }
 
 void si_multiwave_lds_size_workaround(struct si_screen *sscreen,
  unsigned *lds_size)
 {
+   /* If tessellation is all offchip and on-chip GS isn't used, this
+* workaround is not needed.
+*/
+   return;
+
/* SPI barrier management bug:
 *   Make sure we have at least 4k of LDS in use to avoid the bug.
 *   It applies to workgroup sizes of more than one wavefront.
 */
if (sscreen->info.family == CHIP_BONAIRE ||
sscreen->info.family == CHIP_KABINI ||
sscreen->info.family == CHIP_MULLINS)
*lds_size = MAX2(*lds_size, 8);
 }
 
-- 
2.15.1

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

[Mesa-dev] [PATCH 2/4] radeonsi: use maximum OFFCHIP_BUFFERING on Vega12

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index fa9ee43389a..1cc08c5feed 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -748,21 +748,28 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
if (!debug_get_bool_option("RADEON_DISABLE_PERFCOUNTERS", false))
si_init_perfcounters(sscreen);
 
/* Determine tessellation ring info. */
bool double_offchip_buffers = sscreen->info.chip_class >= CIK &&
  sscreen->info.family != CHIP_CARRIZO &&
  sscreen->info.family != CHIP_STONEY;
/* This must be one less than the maximum number due to a hw limitation.
 * Various hardware bugs in SI, CIK, and GFX9 need this.
 */
-   unsigned max_offchip_buffers_per_se = double_offchip_buffers ? 127 : 63;
+   unsigned max_offchip_buffers_per_se;
+
+   /* Only certain chips can use the maximum value. */
+   if (sscreen->info.family == CHIP_VEGA12)
+   max_offchip_buffers_per_se = double_offchip_buffers ? 128 : 64;
+   else
+   max_offchip_buffers_per_se = double_offchip_buffers ? 127 : 63;
+
unsigned max_offchip_buffers = max_offchip_buffers_per_se *
   sscreen->info.max_se;
unsigned offchip_granularity;
 
/* Hawaii has a bug with offchip buffers > 256 that can be worked
 * around by setting 4K granularity.
 */
if (sscreen->info.family == CHIP_HAWAII) {
sscreen->tess_offchip_block_dw_size = 4096;
offchip_granularity = V_03093C_X_4K_DWORDS;
-- 
2.15.1

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

[Mesa-dev] [PATCH 4/4] radeonsi: simplify DCC format categories

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeon/r600_texture.c | 29 +
 1 file changed, 9 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/radeon/r600_texture.c 
b/src/gallium/drivers/radeon/r600_texture.c
index 1614df63c98..eb6706c9dcd 100644
--- a/src/gallium/drivers/radeon/r600_texture.c
+++ b/src/gallium/drivers/radeon/r600_texture.c
@@ -1875,64 +1875,53 @@ static const struct u_resource_vtbl r600_texture_vtbl =
NULL,   /* get_handle */
r600_texture_destroy,   /* resource_destroy */
r600_texture_transfer_map,  /* transfer_map */
u_default_transfer_flush_region, /* transfer_flush_region */
r600_texture_transfer_unmap,/* transfer_unmap */
 };
 
 /* DCC channel type categories within which formats can be reinterpreted
  * while keeping the same DCC encoding. The swizzle must also match. */
 enum dcc_channel_type {
-   dcc_channel_float32,
-   dcc_channel_uint32,
-   dcc_channel_sint32,
-   dcc_channel_float16,
-   dcc_channel_uint16,
-   dcc_channel_sint16,
+   dcc_channel_float,
+   /* uint and sint can be merged if we never use TC-compatible DCC clear
+* encoding with the clear value of 1. */
+   dcc_channel_uint,
+   dcc_channel_sint,
dcc_channel_uint_10_10_10_2,
-   dcc_channel_uint8,
-   dcc_channel_sint8,
dcc_channel_incompatible,
 };
 
 /* Return the type of DCC encoding. */
 static enum dcc_channel_type
 vi_get_dcc_channel_type(const struct util_format_description *desc)
 {
int i;
 
/* Find the first non-void channel. */
for (i = 0; i < desc->nr_channels; i++)
if (desc->channel[i].type != UTIL_FORMAT_TYPE_VOID)
break;
if (i == desc->nr_channels)
return dcc_channel_incompatible;
 
switch (desc->channel[i].size) {
case 32:
-   if (desc->channel[i].type == UTIL_FORMAT_TYPE_FLOAT)
-   return dcc_channel_float32;
-   if (desc->channel[i].type == UTIL_FORMAT_TYPE_UNSIGNED)
-   return dcc_channel_uint32;
-   return dcc_channel_sint32;
case 16:
+   case 8:
if (desc->channel[i].type == UTIL_FORMAT_TYPE_FLOAT)
-   return dcc_channel_float16;
+   return dcc_channel_float;
if (desc->channel[i].type == UTIL_FORMAT_TYPE_UNSIGNED)
-   return dcc_channel_uint16;
-   return dcc_channel_sint16;
+   return dcc_channel_uint;
+   return dcc_channel_sint;
case 10:
return dcc_channel_uint_10_10_10_2;
-   case 8:
-   if (desc->channel[i].type == UTIL_FORMAT_TYPE_UNSIGNED)
-   return dcc_channel_uint8;
-   return dcc_channel_sint8;
default:
return dcc_channel_incompatible;
}
 }
 
 /* Return if it's allowed to reinterpret one format as another with DCC 
enabled. */
 bool vi_dcc_formats_compatible(enum pipe_format format1,
   enum pipe_format format2)
 {
const struct util_format_description *desc1, *desc2;
-- 
2.15.1

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

[Mesa-dev] [PATCH 2/4] radeonsi: use maximum OFFCHIP_BUFFERING on Vega12

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_pipe.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index fa9ee43389a..1cc08c5feed 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -748,21 +748,28 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
if (!debug_get_bool_option("RADEON_DISABLE_PERFCOUNTERS", false))
si_init_perfcounters(sscreen);
 
/* Determine tessellation ring info. */
bool double_offchip_buffers = sscreen->info.chip_class >= CIK &&
  sscreen->info.family != CHIP_CARRIZO &&
  sscreen->info.family != CHIP_STONEY;
/* This must be one less than the maximum number due to a hw limitation.
 * Various hardware bugs in SI, CIK, and GFX9 need this.
 */
-   unsigned max_offchip_buffers_per_se = double_offchip_buffers ? 127 : 63;
+   unsigned max_offchip_buffers_per_se;
+
+   /* Only certain chips can use the maximum value. */
+   if (sscreen->info.family == CHIP_VEGA12)
+   max_offchip_buffers_per_se = double_offchip_buffers ? 128 : 64;
+   else
+   max_offchip_buffers_per_se = double_offchip_buffers ? 127 : 63;
+
unsigned max_offchip_buffers = max_offchip_buffers_per_se *
   sscreen->info.max_se;
unsigned offchip_granularity;
 
/* Hawaii has a bug with offchip buffers > 256 that can be worked
 * around by setting 4K granularity.
 */
if (sscreen->info.family == CHIP_HAWAII) {
sscreen->tess_offchip_block_dw_size = 4096;
offchip_granularity = V_03093C_X_4K_DWORDS;
-- 
2.15.1

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

[Mesa-dev] [PATCH 1/4] ac/surface: set AddrSurfInfoIn.format = ADDR_FMT_8, add assertions

[Marek Olšák]

From: Marek Olšák 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105738
---
 src/amd/common/ac_surface.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 12dfc0cb1f2..81882576baf 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1150,32 +1150,39 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
break;
case 16:
AddrSurfInfoIn.format = ADDR_FMT_BC3;
break;
default:
assert(0);
}
} else {
switch (surf->bpe) {
case 1:
+   assert(!(surf->flags & RADEON_SURF_ZBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_8;
break;
case 2:
+   assert(surf->flags & RADEON_SURF_ZBUFFER ||
+  !(surf->flags & RADEON_SURF_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_16;
break;
case 4:
+   assert(surf->flags & RADEON_SURF_ZBUFFER ||
+  !(surf->flags & RADEON_SURF_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32;
break;
case 8:
+   assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32_32;
break;
case 16:
+   assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
break;
default:
assert(0);
}
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
 
AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
@@ -1251,20 +1258,21 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
/* Calculate texture layout information. */
r = gfx9_compute_miptree(addrlib, config, surf, compressed,
 );
if (r)
return r;
 
/* Calculate texture layout information for stencil. */
if (surf->flags & RADEON_SURF_SBUFFER) {
AddrSurfInfoIn.flags.stencil = 1;
AddrSurfInfoIn.bpp = 8;
+   AddrSurfInfoIn.format = ADDR_FMT_8;
 
if (!AddrSurfInfoIn.flags.depth) {
r = gfx9_get_preferred_swizzle_mode(addrlib, 
, false,

);
if (r)
return r;
} else
AddrSurfInfoIn.flags.depth = 0;
 
r = gfx9_compute_miptree(addrlib, config, surf, compressed,
-- 
2.15.1

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

[Mesa-dev] [PATCH 1/4] ac/surface: set AddrSurfInfoIn.format = ADDR_FMT_8, add assertions

[Marek Olšák]

From: Marek Olšák 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105738
---
 src/amd/common/ac_surface.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 12dfc0cb1f2..81882576baf 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -1150,32 +1150,39 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
break;
case 16:
AddrSurfInfoIn.format = ADDR_FMT_BC3;
break;
default:
assert(0);
}
} else {
switch (surf->bpe) {
case 1:
+   assert(!(surf->flags & RADEON_SURF_ZBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_8;
break;
case 2:
+   assert(surf->flags & RADEON_SURF_ZBUFFER ||
+  !(surf->flags & RADEON_SURF_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_16;
break;
case 4:
+   assert(surf->flags & RADEON_SURF_ZBUFFER ||
+  !(surf->flags & RADEON_SURF_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32;
break;
case 8:
+   assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32_32;
break;
case 16:
+   assert(!(surf->flags & RADEON_SURF_Z_OR_SBUFFER));
AddrSurfInfoIn.format = ADDR_FMT_32_32_32_32;
break;
default:
assert(0);
}
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
 
AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
@@ -1251,20 +1258,21 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
/* Calculate texture layout information. */
r = gfx9_compute_miptree(addrlib, config, surf, compressed,
 );
if (r)
return r;
 
/* Calculate texture layout information for stencil. */
if (surf->flags & RADEON_SURF_SBUFFER) {
AddrSurfInfoIn.flags.stencil = 1;
AddrSurfInfoIn.bpp = 8;
+   AddrSurfInfoIn.format = ADDR_FMT_8;
 
if (!AddrSurfInfoIn.flags.depth) {
r = gfx9_get_preferred_swizzle_mode(addrlib, 
, false,

);
if (r)
return r;
} else
AddrSurfInfoIn.flags.depth = 0;
 
r = gfx9_compute_miptree(addrlib, config, surf, compressed,
-- 
2.15.1

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

[Mesa-dev] [PATCH 3/4] i965: Drop unused alignment parameter from brw_bo_alloc().

[Kenneth Graunke]

brw_bo_alloc no longer uses this parameter, so there's no point.
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
 src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 +-
 src/mesa/drivers/dri/i965/brw_bufmgr.h| 2 +-
 src/mesa/drivers/dri/i965/brw_performance_query.c | 5 ++---
 src/mesa/drivers/dri/i965/brw_pipe_control.c  | 2 +-
 src/mesa/drivers/dri/i965/brw_program.c   | 6 +++---
 src/mesa/drivers/dri/i965/brw_program_cache.c | 4 ++--
 src/mesa/drivers/dri/i965/brw_queryobj.c  | 6 +++---
 src/mesa/drivers/dri/i965/gen6_queryobj.c | 2 +-
 src/mesa/drivers/dri/i965/gen6_sol.c  | 4 ++--
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 ++--
 src/mesa/drivers/dri/i965/intel_buffer_objects.c  | 6 +++---
 src/mesa/drivers/dri/i965/intel_screen.c  | 4 ++--
 src/mesa/drivers/dri/i965/intel_upload.c  | 2 +-
 14 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index a9c6dc4d501..44064fc0cf3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -827,7 +827,7 @@ blorp_get_client_bo(struct brw_context *brw,
* data which we need to copy into a BO.
*/
   struct brw_bo *bo =
- brw_bo_alloc(brw->bufmgr, "tmp_tex_subimage_src", size, 64);
+ brw_bo_alloc(brw->bufmgr, "tmp_tex_subimage_src", size);
   if (bo == NULL) {
  perf_debug("intel_texsubimage: temp bo creation failed: size = %u\n",
 size);
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 295211e89f0..83c0286e0da 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -428,7 +428,7 @@ err:
 
 struct brw_bo *
 brw_bo_alloc(struct brw_bufmgr *bufmgr,
- const char *name, uint64_t size, uint64_t alignment)
+ const char *name, uint64_t size)
 {
return bo_alloc_internal(bufmgr, name, size, 0, I915_TILING_NONE, 0);
 }
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index f33b6b5a3be..65e76b27d1b 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -175,7 +175,7 @@ struct brw_bo {
  * using brw_bo_map() to be used by the CPU.
  */
 struct brw_bo *brw_bo_alloc(struct brw_bufmgr *bufmgr, const char *name,
-uint64_t size, uint64_t alignment);
+uint64_t size);
 
 /**
  * Allocate a tiled buffer object.
diff --git a/src/mesa/drivers/dri/i965/brw_performance_query.c 
b/src/mesa/drivers/dri/i965/brw_performance_query.c
index 4144aa3c9b8..ef5401a21b4 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_query.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_query.c
@@ -1236,8 +1236,7 @@ brw_begin_perf_query(struct gl_context *ctx,
   }
 
   obj->oa.bo =
- brw_bo_alloc(brw->bufmgr, "perf. query OA MI_RPC bo",
-  MI_RPC_BO_SIZE, 64);
+ brw_bo_alloc(brw->bufmgr, "perf. query OA MI_RPC bo", MI_RPC_BO_SIZE);
 #ifdef DEBUG
   /* Pre-filling the BO helps debug whether writes landed. */
   void *map = brw_bo_map(brw, obj->oa.bo, MAP_WRITE);
@@ -1293,7 +1292,7 @@ brw_begin_perf_query(struct gl_context *ctx,
 
   obj->pipeline_stats.bo =
  brw_bo_alloc(brw->bufmgr, "perf. query pipeline stats bo",
-STATS_BO_SIZE, 64);
+  STATS_BO_SIZE);
 
   /* Take starting snapshots. */
   snapshot_statistics_registers(brw, obj, 0);
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index 71f79b18474..02278be6d62 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -572,7 +572,7 @@ brw_init_pipe_control(struct brw_context *brw,
 * the gen6 workaround because it involves actually writing to
 * the buffer, and the kernel doesn't let us write to the batch.
 */
-   brw->workaround_bo = brw_bo_alloc(brw->bufmgr, "workaround", 4096, 4096);
+   brw->workaround_bo = brw_bo_alloc(brw->bufmgr, "workaround", 4096);
if (brw->workaround_bo == NULL)
   return -ENOMEM;
 
diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
b/src/mesa/drivers/dri/i965/brw_program.c
index 23743639dc8..4579a58b820 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -342,7 +342,7 @@ brw_get_scratch_bo(struct brw_context *brw,
}
 
if (!old_bo) {
-  *scratch_bo = brw_bo_alloc(brw->bufmgr, "scratch bo", size, 4096);
+  *scratch_bo = brw_bo_alloc(brw->bufmgr, "scratch bo", size);
}
 }
 
@@ -437,7 +437,7 @@ brw_alloc_stage_scratch(struct brw_context *brw,
 
stage_state->scratch_bo =
   brw_bo_alloc(brw->bufmgr, "shader scratch space",
-   

[Mesa-dev] [PATCH 1/4] i965: Drop BO_ALLOC_BUSY in intel_miptree_create_for_bo().

[Kenneth Graunke]

intel_miptree_create_for_bo does not actually allocate a BO, so
specifying allocation flags accomplishes nothing and is confusing.
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c6213b21629..23cb40f3226 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -820,7 +820,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
 devinfo->gen >= 6 ? depth_only_format : format,
 0, 0, width, height, depth, 1, ISL_TILING_Y0_BIT,
 ISL_SURF_USAGE_DEPTH_BIT | ISL_SURF_USAGE_TEXTURE_BIT,
-BO_ALLOC_BUSY, pitch, bo);
+0, pitch, bo);
   if (!mt)
  return NULL;
 
@@ -836,7 +836,7 @@ intel_miptree_create_for_bo(struct brw_context *brw,
 ISL_TILING_W_BIT,
 ISL_SURF_USAGE_STENCIL_BIT |
 ISL_SURF_USAGE_TEXTURE_BIT,
-BO_ALLOC_BUSY, pitch, bo);
+0, pitch, bo);
   if (!mt)
  return NULL;
 
-- 
2.16.3

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

[Mesa-dev] [PATCH 2/4] i965: Drop alignment parameter from bo_alloc_internal().

[Kenneth Graunke]

Buffers are always page aligned on 965+ hardware; I believe this extra
parameter is a vestige from the Gen2-3 era.

All callers pass 0, and in fact we assert that the alignment is 0 unless
BO_ALLOC_BUSY is set (for some reason).  We can just drop the parameter
and set the value to 0 explicitly.
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index f698123db4c..295211e89f0 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -269,7 +269,7 @@ bo_alloc_internal(struct brw_bufmgr *bufmgr,
   uint64_t size,
   unsigned flags,
   uint32_t tiling_mode,
-  uint32_t stride, uint64_t alignment)
+  uint32_t stride)
 {
struct brw_bo *bo;
unsigned int page_size = getpagesize();
@@ -320,9 +320,8 @@ retry:
  bo = LIST_ENTRY(struct brw_bo, bucket->head.prev, head);
  list_del(>head);
  alloc_from_cache = true;
- bo->align = alignment;
+ bo->align = 0;
   } else {
- assert(alignment == 0);
  /* For non-render-target BOs (where we're probably
   * going to map it first thing in order to fill it
   * with data), check if the last BO in the cache is
@@ -382,7 +381,7 @@ retry:
   bo->gem_handle = create.handle;
 
   bo->bufmgr = bufmgr;
-  bo->align = alignment;
+  bo->align = 0;
 
   bo->tiling_mode = I915_TILING_NONE;
   bo->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
@@ -431,7 +430,7 @@ struct brw_bo *
 brw_bo_alloc(struct brw_bufmgr *bufmgr,
  const char *name, uint64_t size, uint64_t alignment)
 {
-   return bo_alloc_internal(bufmgr, name, size, 0, I915_TILING_NONE, 0, 0);
+   return bo_alloc_internal(bufmgr, name, size, 0, I915_TILING_NONE, 0);
 }
 
 struct brw_bo *
@@ -439,7 +438,7 @@ brw_bo_alloc_tiled(struct brw_bufmgr *bufmgr, const char 
*name,
uint64_t size, uint32_t tiling_mode, uint32_t pitch,
unsigned flags)
 {
-   return bo_alloc_internal(bufmgr, name, size, flags, tiling_mode, pitch, 0);
+   return bo_alloc_internal(bufmgr, name, size, flags, tiling_mode, pitch);
 }
 
 struct brw_bo *
@@ -480,7 +479,7 @@ brw_bo_alloc_tiled_2d(struct brw_bufmgr *bufmgr, const char 
*name,
if (tiling == I915_TILING_NONE)
   stride = 0;
 
-   return bo_alloc_internal(bufmgr, name, size, flags, tiling, stride, 0);
+   return bo_alloc_internal(bufmgr, name, size, flags, tiling, stride);
 }
 
 /**
-- 
2.16.3

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

[Mesa-dev] [PATCH 4/4] i965: Drop unnecessary bo->align field.

[Kenneth Graunke]

bo->align is always 0; there's no need to waste 8 bytes storing it.
Thanks to C99 initializers zeroing fields, we can completely drop the
only read of the field altogether.
---
 src/mesa/drivers/dri/i965/brw_bufmgr.c| 2 --
 src/mesa/drivers/dri/i965/brw_bufmgr.h| 7 ---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 1 -
 3 files changed, 10 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 83c0286e0da..8ba915b179a 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -320,7 +320,6 @@ retry:
  bo = LIST_ENTRY(struct brw_bo, bucket->head.prev, head);
  list_del(>head);
  alloc_from_cache = true;
- bo->align = 0;
   } else {
  /* For non-render-target BOs (where we're probably
   * going to map it first thing in order to fill it
@@ -381,7 +380,6 @@ retry:
   bo->gem_handle = create.handle;
 
   bo->bufmgr = bufmgr;
-  bo->align = 0;
 
   bo->tiling_mode = I915_TILING_NONE;
   bo->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index 65e76b27d1b..68f5e0c2c85 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -56,13 +56,6 @@ struct brw_bo {
 */
uint64_t size;
 
-   /**
-* Alignment requirement for object
-*
-* Used for GTT mapping & pinning the object.
-*/
-   uint64_t align;
-
/** Buffer manager context associated with this buffer object */
struct brw_bufmgr *bufmgr;
 
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 9147ff82939..ebc02ff3897 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -170,7 +170,6 @@ add_exec_bo(struct intel_batchbuffer *batch, struct brw_bo 
*bo)
batch->validation_list[batch->exec_count] =
   (struct drm_i915_gem_exec_object2) {
  .handle = bo->gem_handle,
- .alignment = bo->align,
  .offset = bo->gtt_offset,
  .flags = bo->kflags,
   };
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH] glapi: add glBlendBarrier(), glPrimitiveBoundingBox() prototypes

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh 

On Mon, Mar 26, 2018 at 04:56:22PM -0600, Brian Paul wrote:
> in glapi_dispatch.c, as we have for many other GLES functions.
> Fixes a cross-compile issue (missing prototype) when GLES support
> is disabled.
> ---
>  src/mapi/glapi/glapi_dispatch.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
> index 269adc7..3239523 100644
> --- a/src/mapi/glapi/glapi_dispatch.c
> +++ b/src/mapi/glapi/glapi_dispatch.c
> @@ -143,6 +143,8 @@ GL_API void GL_APIENTRY glTexParameterx (GLenum target, 
> GLenum pname, GLfixed pa
>  GL_API void GL_APIENTRY glTexParameterxv (GLenum target, GLenum pname, const 
> GLfixed *params);
>  GL_API void GL_APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z);
>  GL_API void GL_APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, 
> const GLvoid *pointer);
> +GL_API void GL_APIENTRY glBlendBarrier (void);
> +GL_API void GL_APIENTRY glPrimitiveBoundingBox (GLfloat minX, GLfloat minY, 
> GLfloat minZ, GLfloat minW, GLfloat maxX, GLfloat maxY, GLfloat maxZ, GLfloat 
> maxW);
>  
>  /* Enable frame pointer elimination on Windows, otherwise forgetting to add
>   * APIENTRY to _mesa_* entrypoints will not cause crashes on debug builds, as
> -- 
> 2.7.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: fix crash in loop unroll corner case

[Jason Ekstrand]

On Sun, Mar 25, 2018 at 6:32 PM, Timothy Arceri 
wrote:

> When an if nesting inside anouther if is optimised away we can
> end up with a loop terminator and following block that looks like
> this:
>
> if ssa_596 {
> block block_5:
> /* preds: block_4 */
> vec1 32 ssa_601 = load_const (0x /* -nan */)
> break
> /* succs: block_8 */
> } else {
> block block_6:
> /* preds: block_4 */
> /* succs: block_7 */
> }
> block block_7:
> /* preds: block_6 */
> vec1 32 ssa_602 = phi block_6: ssa_552
> vec1 32 ssa_603 = phi block_6: ssa_553
> vec1 32 ssa_604 = iadd ssa_551, ssa_66
>
> The problem is the phis. Loop unrolling expects the last block in
> the loop to be empty once we splice the instructions in the last
> block into the continue branch. The problem is we cant move phis
> so here we lower the phis to regs when preparing the loop for
> unrolling. As it could be possible to have multiple additional
> blocks/ifs following the terminator we just convert all phis at
> the top level of the loop body for simplicity.
>
> We also add some comments to loop_prepare_for_unroll() while we
> are here.
>
> Fixes: 51daccb289eb "nir: add a loop unrolling pass"
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670
> ---
>  src/compiler/nir/nir_opt_loop_unroll.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
> b/src/compiler/nir/nir_opt_loop_unroll.c
> index 79d04f978bc..85df3097264 100644
> --- a/src/compiler/nir/nir_opt_loop_unroll.c
> +++ b/src/compiler/nir/nir_opt_loop_unroll.c
> @@ -37,10 +37,10 @@
>  #define LOOP_UNROLL_LIMIT 26
>
>  /* Prepare this loop for unrolling by first converting to lcssa and then
> - * converting the phis from the loops first block and the block that
> follows
> - * the loop into regs.  Partially converting out of SSA allows us to
> unroll
> - * the loop without having to keep track of and update phis along the way
> - * which gets tricky and doesn't add much value over conveting to regs.
> + * converting the phis from the top level of the loop body to regs.
> + * Partially converting out of SSA allows us to unroll the loop without
> having
> + * to keep track of and update phis along the way which gets tricky and
> + * doesn't add much value over conveting to regs.
>

converting


>   *
>   * The loop may have a continue instruction at the end of the loop which
> does
>   * nothing.  Once we're out of SSA, we can safely delete it so we don't
> have
> @@ -51,13 +51,20 @@ loop_prepare_for_unroll(nir_loop *loop)
>  {
> nir_convert_loop_to_lcssa(loop);
>
> -   nir_lower_phis_to_regs_block(nir_loop_first_block(loop));
> +   /* Lower phis at the top level of the loop body */
> +   foreach_list_typed_safe(nir_cf_node, node, node, >body) {
> +  if (nir_cf_node_block == node->type) {
> + nir_lower_phis_to_regs_block(nir_cf_node_as_block(node));
> +  }
> +   }
>

This is a bit of a big hammer and I don't really like it for that but it
does work.  We could predicate it on block->predecessors->entries == 1 or
we could try and do something even more clever.  That said, this is tricky
and what you've done is robust so I'm ok with it as-is.

Reviewed-by: Jason Ekstrand 


> +   /* Lower phis after the loop */
> nir_block *block_after_loop =
>nir_cf_node_as_block(nir_cf_node_next(>cf_node));
>
> nir_lower_phis_to_regs_block(block_after_loop);
>
> +   /* Remove continue if its the last instruction in the loop */
> nir_instr *last_instr = nir_block_last_instr(nir_loop_
> last_block(loop));
> if (last_instr && last_instr->type == nir_instr_type_jump) {
>assert(nir_instr_as_jump(last_instr)->type == nir_jump_continue);
> --
> 2.14.3
>
> ___
> 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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #4 from Ilia Mirkin  ---
The shader compiler provides warnings:

$ bin/glslparsertest foo.frag pass 1.30
Successfully compiled fragment shader foo.frag: 0:54(14): warning: `i' used
uninitialized
0:58(39): warning: `i' used uninitialized
0:59(53): warning: `i' used uninitialized
0:61(30): warning: `i' used uninitialized
0:62(33): warning: `i' used uninitialized
0:54(30): warning: `i' used uninitialized

PIGLIT: {"result": "pass" }

These warnings would be available to you programmatically using the KHR_debug
callback, I believe. Or printed to stderr with a debug mesa build.

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #3 from Swyter  ---
Created attachment 138367
  --> https://bugs.freedesktop.org/attachment.cgi?id=138367=edit
glxinfo.txt

-- 
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] [AppVeyor] mesa master #7298 failed

[AppVeyor]

Build mesa 7298 failed


Commit 7d2079908d by Marek Olšák on 3/21/2018 8:10 PM:

winsys/amdgpu: always allow GTT placements on APUs\n\nReviewed-by: Christian König 


Configure your notification preferences

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

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #2 from Swyter  ---
Created attachment 138366
  --> https://bugs.freedesktop.org/attachment.cgi?id=138366=edit
default-fixed.frag

-- 
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 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

--- Comment #1 from Swyter  ---
Created attachment 138365
  --> https://bugs.freedesktop.org/attachment.cgi?id=138365=edit
default.vert

-- 
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] Question about min_index/max_index calculation

[Marek Olšák]

On Mon, Mar 26, 2018 at 6:39 PM, Erico Nunes  wrote:

> Thanks all for the input.
>
> I don't have an in-depth knowledge of the hardware either, though as
> far as we can see the hardware does expect that we pass min_index in
> the command stream. max_index is used to calculate the sizes in other
> command stream fields (which is not the same as pipe_draw_info.count).
> The existing lima-ng implementation does the same:
> https://github.com/limadriver-ng/lima/blob/660a940c8cc151fd886559233c1a22
> 385ee5f254/limare/lib/gp.c#L584
> (draw->vertex_start).
>
> On Sat, Mar 17, 2018 at 7:23 PM, Ilia Mirkin  wrote:
> > For an approximation, you can use the sizes of the bound vbo's to
> > guess a min/max index. See
> > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/
> drivers/vc4/vc4_draw.c#n183
> > for an example.
>
> I quickly played with porting something like that to mesa-lima but I
> don't think it can solve our problem.
> Apparently our bo currently have a fairly large fixed size so I'm not
> sure we can do an equivalent calculation using bo size.
> And then, min_index is required too.
>
> On Sat, Mar 24, 2018 at 10:32 PM, Marek Olšák  wrote:
> > Here is how to do it:
> >
> > if (max_index != ~0u)
> >// index bounds are valid;
> > else
> >// scan the index buffer manually;
> >
> > u_vbuf_get_minmax_index can be used for the scanning.
>
> mesa-lima currently does not use any vbuf function. And we currently
> can't call u_vbuf_get_minmax_index since it's static in u_vbuf.c.
>
> I suppose we can consider making u_vbuf_get_minmax_index public then.
> I tested this and it works for me. It's still a bit annoying since we
> need to create fields probably in lima_context (like
> vc4_context.max_index does) and use those instead of the ones in
> pipe_draw_info. But not a big problem I guess. We could submit this
> refactor when mesa-lima gets proposed upstream.
>
> Just for completeness, one other idea that came up was to define a new
> PIPE_CAP_xxx config used to override
> st_context.draw_needs_minmax_index, and set that in this driver. This
> way, pipe_draw_info would come correctly filled and we wouldn't need
> to explicitly assemble minmax indices during the driver draw_vbo. How
> does this sound compared to the other solution?
>

The PIPE_CAP solution sounds OK.

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

[Mesa-dev] [Bug 105755] Mesa freezes when the GLSL shader contains a `for` loop with an uninitialized `i` index/counter variable

[bugzilla-daemon]

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

Bug ID: 105755
   Summary: Mesa freezes when the GLSL shader contains a `for`
loop with an uninitialized `i` index/counter variable
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: swyterzone+mes...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 138364
  --> https://bugs.freedesktop.org/attachment.cgi?id=138364=edit
default.frag

So yeah, this has baffled me for a while. I have had reports of soft-locks and
freezes of my OpenGL/SDL2 game in Mesa-based Linux distros for a while, mainly
under Intel hardware. The game works fine in Windows and macOS using the same
shaders. Luckily I have just found out that it also happens under Nouveau, so
the problem seems to be at the GLSL parser-level or other shared/common
component.

After debugging the soft-locking issue for a bit it was clear that it only
happened whenever the dynamic point lights code path was in use. After
disabling and enabling it I suddenly realized something:

> for (int i; i < lightCount; i++)

I forgot to initialize the counter of the loop and that completely froze the
entire graphics pipeline, making the system unusable!


I find it funny that glslangValidator doesn't throw any error or warning even
if that should cause undefined behavior. Looks like the proprietary AMD and
NVIDIA OpenGL drivers initialize the `i` indexing variable to zero, which looks
like the sane thing to do.


It was my mistake, I'll try to lint them better. But the consequences are a bit
unforgiving.


PS: I'd attach an apitrace, but everything freezes. Let me know if you need
anything else, maybe we can give a bunch Steam keys to Mesa developers, in case
they are needed. The game is called Sphinx and the Cursed Mummy, a native
OpenGL 3+ port.

-- 
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] glsl_types: fix build break with intel/msvc compiler

[Roland Scheidegger]

Looks nicer in any case.

Reviewed-by: Roland Scheidegger 

Am 27.03.2018 um 00:49 schrieb Rob Clark:
> The VECN() macro was taking advantage of a GCC specific feature that is
> not available on lesser compilers, mostly for the purposes of avoiding a
> macro that encoded a return statement.
> 
> But as suggested by Ian, we could just have the macro produce the entire
> method body and avoid the need for this.  So let's do that instead.
> 
> Bugzilla: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105740=DwIBAg=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=eRT_I_3VoCDxWw_I8noUCJeFaGWagLBmzE6HG6--xTQ=UHvkTixq7N04Wy2N6znh7Cawv6FkBYnnmytu-3lYiAM=
> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
> Cc: Emil Velikov 
> Cc: Timothy Arceri 
> Cc: Roland Scheidegger 
> Cc: Ian Romanick 
> Signed-off-by: Rob Clark 
> ---
>  src/compiler/glsl_types.cpp | 107 
> ++--
>  1 file changed, 24 insertions(+), 83 deletions(-)
> 
> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
> index e92e03421f4..f18e131cf18 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -509,89 +509,30 @@ glsl_type::vec(unsigned components, const glsl_type 
> *const ts[])
> return ts[n - 1];
>  }
>  
> -#define VECN(components, sname, vname) ({\
> -  static const glsl_type *const ts[] = { \
> - sname ## _type, vname ## 2_type,\
> - vname ## 3_type, vname ## 4_type,   \
> - vname ## 8_type, vname ## 16_type,  \
> -  }; \
> -  glsl_type::vec(components, ts);\
> -   })
> -
> -const glsl_type *
> -glsl_type::vec(unsigned components)
> -{
> -   return VECN(components, float, vec);
> -}
> -
> -const glsl_type *
> -glsl_type::f16vec(unsigned components)
> -{
> -   return VECN(components, float16_t, f16vec);
> -}
> -
> -const glsl_type *
> -glsl_type::dvec(unsigned components)
> -{
> -   return VECN(components, double, dvec);
> -}
> -
> -const glsl_type *
> -glsl_type::ivec(unsigned components)
> -{
> -   return VECN(components, int, ivec);
> -}
> -
> -const glsl_type *
> -glsl_type::uvec(unsigned components)
> -{
> -   return VECN(components, uint, uvec);
> -}
> -
> -const glsl_type *
> -glsl_type::bvec(unsigned components)
> -{
> -   return VECN(components, bool, bvec);
> -}
> -
> -const glsl_type *
> -glsl_type::i64vec(unsigned components)
> -{
> -   return VECN(components, int64_t, i64vec);
> -}
> -
> -
> -const glsl_type *
> -glsl_type::u64vec(unsigned components)
> -{
> -   return VECN(components, uint64_t, u64vec);
> -}
> -
> -const glsl_type *
> -glsl_type::i16vec(unsigned components)
> -{
> -   return VECN(components, int16_t, i16vec);
> -}
> -
> -
> -const glsl_type *
> -glsl_type::u16vec(unsigned components)
> -{
> -   return VECN(components, uint16_t, u16vec);
> -}
> -
> -const glsl_type *
> -glsl_type::i8vec(unsigned components)
> -{
> -   return VECN(components, int8_t, i8vec);
> -}
> -
> -
> -const glsl_type *
> -glsl_type::u8vec(unsigned components)
> -{
> -   return VECN(components, uint8_t, u8vec);
> -}
> +#define VECN(components, sname, vname)   \
> +const glsl_type *\
> +glsl_type:: vname (unsigned components)  \
> +{\
> +   static const glsl_type *const ts[] = {\
> +  sname ## _type, vname ## 2_type,   \
> +  vname ## 3_type, vname ## 4_type,  \
> +  vname ## 8_type, vname ## 16_type, \
> +   };\
> +   return glsl_type::vec(components, ts);\
> +}
> +
> +VECN(components, float, vec)
> +VECN(components, float16_t, f16vec)
> +VECN(components, double, dvec)
> +VECN(components, int, ivec)
> +VECN(components, uint, uvec)
> +VECN(components, bool, bvec)
> +VECN(components, int64_t, i64vec)
> +VECN(components, uint64_t, u64vec)
> +VECN(components, int16_t, i16vec)
> +VECN(components, uint16_t, u16vec)
> +VECN(components, int8_t, i8vec)
> +VECN(components, uint8_t, u8vec)
>  
>  const glsl_type *
>  glsl_type::get_instance(unsigned base_type, unsigned rows, unsigned columns)
> 

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

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Roland Scheidegger]

Am 27.03.2018 um 00:44 schrieb Rob Clark:
> On Mon, Mar 26, 2018 at 6:38 PM, Rob Clark  wrote:
>> On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger  
>> wrote:
>>> Am 26.03.2018 um 23:01 schrieb Rob Clark:
 correct me if I'm wrong, but I don't see how you could do the ## stuff
 to construct the built-in type name with templates.  So I think the
 options are tons of copy/pasta code (ie. what we had before) or
 macros.

 I agree that could just construct the whole method with the macro.. I
 like that better than changing VECN() macro to contain the return
 (which I was explicitly trying to avoid in the original version, since
 macros that contain return statements are evil)
>>>
>>> macros which don't compile are worse...
>>> Albeit I'm not a fan of any kind of macros, but whatever compiles.
>>
>> fair enough, although tbh gcc is the compiler I have, so I tend not to
>> realize when I introduce things that are gcc specific.  (And, well,
>> the linux kernel uses constructs like these, so I tend to assume they
>> are fair game.)
>>
>> Ian's suggestion to make the entire method body into the macro is the
>> approach I like best (and even more negative diff-stat).. I'll send a
>> patch in a few minutes.
> 
> oh, and if there is a compiler flag that would disallow things that
> intel or MS compiler doesn't like.. we should use that.  It would save
> me from embarrassing myself ;-)
> 
> (alternatively something that pro-actively pulls patches from list and
> builds them with compilers that most mesa dev's don't have, along the
> lines of what kbuild robot does, could work.. the original patch was
> sitting on list for at least a week.. but I guess the compiler arg, if
> it exists, is the easier solution.)

I don't think there is such a flag - -Wpedantic should flag some usage
of non-iso extensions but not all.
I believe clang should warn about it unless you use -Wno-gnu (or maybe
it would need -Wgnu).

Roland



> 
> BR,
> -R
> 
> 
>> BR,
>> -R
>>
>>> Roland
>>>
>>>

 BR,
 -R

 On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
> As much as I'm not a fan of C++ templates, I don't see how this
> preprocessor macro reinvention of that mechanism is an improvement.
>
> On 03/26/2018 09:45 AM, Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Update the macro to have the explic return. Using the current GCC
>> specific macro breaks other compilers such as the Intel one or MSVC.
>>
>> Bugzilla: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105740=DwIBaQ=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=wN0OlA9-uN-YjyUfAXoi2DgA6qDPtzMil4RM0xhwDyM=dvKEnjT1-nDYwicM-O11QsrqsmV6TlYiouvj0Pc1R1Q=
>> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
>> Cc: Rob Clark 
>> Cc: Timothy Arceri 
>> Cc: Roland Scheidegger 
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/compiler/glsl_types.cpp | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
>> index b8caddb406..ab356cb5a0 100644
>> --- a/src/compiler/glsl_types.cpp
>> +++ b/src/compiler/glsl_types.cpp
>> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const 
>> glsl_type *const ts[])
>> return ts[n - 1];
>>  }
>>
>> -#define VECN(components, sname, vname) ({\
>> +#define VECN(components, sname, vname)  {\
>>static const glsl_type *const ts[] = { \
>>   sname ## _type, vname ## 2_type,\
>>   vname ## 3_type, vname ## 4_type,   \
>>   vname ## 8_type, vname ## 16_type,  \
>>}; \
>> -  glsl_type::vec(components, ts);\
>> -   })
>> +  return glsl_type::vec(components, ts); \
>> +   }
>>
>>  const glsl_type *
>>  glsl_type::vec(unsigned components)
>>  {
>> -   return VECN(components, float, vec);
>> +   VECN(components, float, vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::f16vec(unsigned components)
>>  {
>> -   return VECN(components, float16_t, f16vec);
>> +   VECN(components, float16_t, f16vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::dvec(unsigned components)
>>  {
>> -   return VECN(components, double, dvec);
>> +   VECN(components, double, dvec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::ivec(unsigned components)
>>  {
>> -   return VECN(components, int, ivec);
>> +   VECN(components, int, ivec);
>>  }
>>
>>  const 

[Mesa-dev] [PATCH] glapi: add glBlendBarrier(), glPrimitiveBoundingBox() prototypes

[Brian Paul]

in glapi_dispatch.c, as we have for many other GLES functions.
Fixes a cross-compile issue (missing prototype) when GLES support
is disabled.
---
 src/mapi/glapi/glapi_dispatch.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c
index 269adc7..3239523 100644
--- a/src/mapi/glapi/glapi_dispatch.c
+++ b/src/mapi/glapi/glapi_dispatch.c
@@ -143,6 +143,8 @@ GL_API void GL_APIENTRY glTexParameterx (GLenum target, 
GLenum pname, GLfixed pa
 GL_API void GL_APIENTRY glTexParameterxv (GLenum target, GLenum pname, const 
GLfixed *params);
 GL_API void GL_APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z);
 GL_API void GL_APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, 
const GLvoid *pointer);
+GL_API void GL_APIENTRY glBlendBarrier (void);
+GL_API void GL_APIENTRY glPrimitiveBoundingBox (GLfloat minX, GLfloat minY, 
GLfloat minZ, GLfloat minW, GLfloat maxX, GLfloat maxY, GLfloat maxZ, GLfloat 
maxW);
 
 /* Enable frame pointer elimination on Windows, otherwise forgetting to add
  * APIENTRY to _mesa_* entrypoints will not cause crashes on debug builds, as
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] glsl_types: fix build break with intel/msvc compiler

[Timothy Arceri]

Acked-by: Timothy Arceri 

On 27/03/18 09:49, Rob Clark wrote:

The VECN() macro was taking advantage of a GCC specific feature that is
not available on lesser compilers, mostly for the purposes of avoiding a
macro that encoded a return statement.

But as suggested by Ian, we could just have the macro produce the entire
method body and avoid the need for this.  So let's do that instead.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
Cc: Emil Velikov 
Cc: Timothy Arceri 
Cc: Roland Scheidegger 
Cc: Ian Romanick 
Signed-off-by: Rob Clark 
---
  src/compiler/glsl_types.cpp | 107 ++--
  1 file changed, 24 insertions(+), 83 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index e92e03421f4..f18e131cf18 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -509,89 +509,30 @@ glsl_type::vec(unsigned components, const glsl_type 
*const ts[])
 return ts[n - 1];
  }
  
-#define VECN(components, sname, vname) ({\

-  static const glsl_type *const ts[] = { \
- sname ## _type, vname ## 2_type,\
- vname ## 3_type, vname ## 4_type,   \
- vname ## 8_type, vname ## 16_type,  \
-  }; \
-  glsl_type::vec(components, ts);\
-   })
-
-const glsl_type *
-glsl_type::vec(unsigned components)
-{
-   return VECN(components, float, vec);
-}
-
-const glsl_type *
-glsl_type::f16vec(unsigned components)
-{
-   return VECN(components, float16_t, f16vec);
-}
-
-const glsl_type *
-glsl_type::dvec(unsigned components)
-{
-   return VECN(components, double, dvec);
-}
-
-const glsl_type *
-glsl_type::ivec(unsigned components)
-{
-   return VECN(components, int, ivec);
-}
-
-const glsl_type *
-glsl_type::uvec(unsigned components)
-{
-   return VECN(components, uint, uvec);
-}
-
-const glsl_type *
-glsl_type::bvec(unsigned components)
-{
-   return VECN(components, bool, bvec);
-}
-
-const glsl_type *
-glsl_type::i64vec(unsigned components)
-{
-   return VECN(components, int64_t, i64vec);
-}
-
-
-const glsl_type *
-glsl_type::u64vec(unsigned components)
-{
-   return VECN(components, uint64_t, u64vec);
-}
-
-const glsl_type *
-glsl_type::i16vec(unsigned components)
-{
-   return VECN(components, int16_t, i16vec);
-}
-
-
-const glsl_type *
-glsl_type::u16vec(unsigned components)
-{
-   return VECN(components, uint16_t, u16vec);
-}
-
-const glsl_type *
-glsl_type::i8vec(unsigned components)
-{
-   return VECN(components, int8_t, i8vec);
-}
-
-
-const glsl_type *
-glsl_type::u8vec(unsigned components)
-{
-   return VECN(components, uint8_t, u8vec);
-}
+#define VECN(components, sname, vname)   \
+const glsl_type *\
+glsl_type:: vname (unsigned components)  \
+{\
+   static const glsl_type *const ts[] = {\
+  sname ## _type, vname ## 2_type,   \
+  vname ## 3_type, vname ## 4_type,  \
+  vname ## 8_type, vname ## 16_type, \
+   };\
+   return glsl_type::vec(components, ts);\
+}
+
+VECN(components, float, vec)
+VECN(components, float16_t, f16vec)
+VECN(components, double, dvec)
+VECN(components, int, ivec)
+VECN(components, uint, uvec)
+VECN(components, bool, bvec)
+VECN(components, int64_t, i64vec)
+VECN(components, uint64_t, u64vec)
+VECN(components, int16_t, i16vec)
+VECN(components, uint16_t, u16vec)
+VECN(components, int8_t, i8vec)
+VECN(components, uint8_t, u8vec)
  
  const glsl_type *

  glsl_type::get_instance(unsigned base_type, unsigned rows, unsigned columns)


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

[Mesa-dev] [PATCH] glsl_types: fix build break with intel/msvc compiler

[Rob Clark]

The VECN() macro was taking advantage of a GCC specific feature that is
not available on lesser compilers, mostly for the purposes of avoiding a
macro that encoded a return statement.

But as suggested by Ian, we could just have the macro produce the entire
method body and avoid the need for this.  So let's do that instead.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
Cc: Emil Velikov 
Cc: Timothy Arceri 
Cc: Roland Scheidegger 
Cc: Ian Romanick 
Signed-off-by: Rob Clark 
---
 src/compiler/glsl_types.cpp | 107 ++--
 1 file changed, 24 insertions(+), 83 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index e92e03421f4..f18e131cf18 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -509,89 +509,30 @@ glsl_type::vec(unsigned components, const glsl_type 
*const ts[])
return ts[n - 1];
 }
 
-#define VECN(components, sname, vname) ({\
-  static const glsl_type *const ts[] = { \
- sname ## _type, vname ## 2_type,\
- vname ## 3_type, vname ## 4_type,   \
- vname ## 8_type, vname ## 16_type,  \
-  }; \
-  glsl_type::vec(components, ts);\
-   })
-
-const glsl_type *
-glsl_type::vec(unsigned components)
-{
-   return VECN(components, float, vec);
-}
-
-const glsl_type *
-glsl_type::f16vec(unsigned components)
-{
-   return VECN(components, float16_t, f16vec);
-}
-
-const glsl_type *
-glsl_type::dvec(unsigned components)
-{
-   return VECN(components, double, dvec);
-}
-
-const glsl_type *
-glsl_type::ivec(unsigned components)
-{
-   return VECN(components, int, ivec);
-}
-
-const glsl_type *
-glsl_type::uvec(unsigned components)
-{
-   return VECN(components, uint, uvec);
-}
-
-const glsl_type *
-glsl_type::bvec(unsigned components)
-{
-   return VECN(components, bool, bvec);
-}
-
-const glsl_type *
-glsl_type::i64vec(unsigned components)
-{
-   return VECN(components, int64_t, i64vec);
-}
-
-
-const glsl_type *
-glsl_type::u64vec(unsigned components)
-{
-   return VECN(components, uint64_t, u64vec);
-}
-
-const glsl_type *
-glsl_type::i16vec(unsigned components)
-{
-   return VECN(components, int16_t, i16vec);
-}
-
-
-const glsl_type *
-glsl_type::u16vec(unsigned components)
-{
-   return VECN(components, uint16_t, u16vec);
-}
-
-const glsl_type *
-glsl_type::i8vec(unsigned components)
-{
-   return VECN(components, int8_t, i8vec);
-}
-
-
-const glsl_type *
-glsl_type::u8vec(unsigned components)
-{
-   return VECN(components, uint8_t, u8vec);
-}
+#define VECN(components, sname, vname)   \
+const glsl_type *\
+glsl_type:: vname (unsigned components)  \
+{\
+   static const glsl_type *const ts[] = {\
+  sname ## _type, vname ## 2_type,   \
+  vname ## 3_type, vname ## 4_type,  \
+  vname ## 8_type, vname ## 16_type, \
+   };\
+   return glsl_type::vec(components, ts);\
+}
+
+VECN(components, float, vec)
+VECN(components, float16_t, f16vec)
+VECN(components, double, dvec)
+VECN(components, int, ivec)
+VECN(components, uint, uvec)
+VECN(components, bool, bvec)
+VECN(components, int64_t, i64vec)
+VECN(components, uint64_t, u64vec)
+VECN(components, int16_t, i16vec)
+VECN(components, uint16_t, u16vec)
+VECN(components, int8_t, i8vec)
+VECN(components, uint8_t, u8vec)
 
 const glsl_type *
 glsl_type::get_instance(unsigned base_type, unsigned rows, unsigned columns)
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Rob Clark]

On Mon, Mar 26, 2018 at 6:38 PM, Rob Clark  wrote:
> On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger  
> wrote:
>> Am 26.03.2018 um 23:01 schrieb Rob Clark:
>>> correct me if I'm wrong, but I don't see how you could do the ## stuff
>>> to construct the built-in type name with templates.  So I think the
>>> options are tons of copy/pasta code (ie. what we had before) or
>>> macros.
>>>
>>> I agree that could just construct the whole method with the macro.. I
>>> like that better than changing VECN() macro to contain the return
>>> (which I was explicitly trying to avoid in the original version, since
>>> macros that contain return statements are evil)
>>
>> macros which don't compile are worse...
>> Albeit I'm not a fan of any kind of macros, but whatever compiles.
>
> fair enough, although tbh gcc is the compiler I have, so I tend not to
> realize when I introduce things that are gcc specific.  (And, well,
> the linux kernel uses constructs like these, so I tend to assume they
> are fair game.)
>
> Ian's suggestion to make the entire method body into the macro is the
> approach I like best (and even more negative diff-stat).. I'll send a
> patch in a few minutes.

oh, and if there is a compiler flag that would disallow things that
intel or MS compiler doesn't like.. we should use that.  It would save
me from embarrassing myself ;-)

(alternatively something that pro-actively pulls patches from list and
builds them with compilers that most mesa dev's don't have, along the
lines of what kbuild robot does, could work.. the original patch was
sitting on list for at least a week.. but I guess the compiler arg, if
it exists, is the easier solution.)

BR,
-R


> BR,
> -R
>
>> Roland
>>
>>
>>>
>>> BR,
>>> -R
>>>
>>> On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
 As much as I'm not a fan of C++ templates, I don't see how this
 preprocessor macro reinvention of that mechanism is an improvement.

 On 03/26/2018 09:45 AM, Emil Velikov wrote:
> From: Emil Velikov 
>
> Update the macro to have the explic return. Using the current GCC
> specific macro breaks other compilers such as the Intel one or MSVC.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
> Cc: Rob Clark 
> Cc: Timothy Arceri 
> Cc: Roland Scheidegger 
> Signed-off-by: Emil Velikov 
> ---
>  src/compiler/glsl_types.cpp | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
> index b8caddb406..ab356cb5a0 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
> *const ts[])
> return ts[n - 1];
>  }
>
> -#define VECN(components, sname, vname) ({\
> +#define VECN(components, sname, vname)  {\
>static const glsl_type *const ts[] = { \
>   sname ## _type, vname ## 2_type,\
>   vname ## 3_type, vname ## 4_type,   \
>   vname ## 8_type, vname ## 16_type,  \
>}; \
> -  glsl_type::vec(components, ts);\
> -   })
> +  return glsl_type::vec(components, ts); \
> +   }
>
>  const glsl_type *
>  glsl_type::vec(unsigned components)
>  {
> -   return VECN(components, float, vec);
> +   VECN(components, float, vec);
>  }
>
>  const glsl_type *
>  glsl_type::f16vec(unsigned components)
>  {
> -   return VECN(components, float16_t, f16vec);
> +   VECN(components, float16_t, f16vec);
>  }
>
>  const glsl_type *
>  glsl_type::dvec(unsigned components)
>  {
> -   return VECN(components, double, dvec);
> +   VECN(components, double, dvec);
>  }
>
>  const glsl_type *
>  glsl_type::ivec(unsigned components)
>  {
> -   return VECN(components, int, ivec);
> +   VECN(components, int, ivec);
>  }
>
>  const glsl_type *
>  glsl_type::uvec(unsigned components)
>  {
> -   return VECN(components, uint, uvec);
> +   VECN(components, uint, uvec);
>  }
>
>  const glsl_type *
>  glsl_type::bvec(unsigned components)
>  {
> -   return VECN(components, bool, bvec);
> +   VECN(components, bool, bvec);
>  }
>
>  const glsl_type *
>  glsl_type::i64vec(unsigned components)
>  {
> -   return VECN(components, int64_t, i64vec);
> +   VECN(components, int64_t, i64vec);
>  }
>
>
>  const glsl_type *
>  glsl_type::u64vec(unsigned components)

Re: [Mesa-dev] Question about min_index/max_index calculation

[Erico Nunes]

Thanks all for the input.

I don't have an in-depth knowledge of the hardware either, though as
far as we can see the hardware does expect that we pass min_index in
the command stream. max_index is used to calculate the sizes in other
command stream fields (which is not the same as pipe_draw_info.count).
The existing lima-ng implementation does the same:
https://github.com/limadriver-ng/lima/blob/660a940c8cc151fd886559233c1a22385ee5f254/limare/lib/gp.c#L584
(draw->vertex_start).

On Sat, Mar 17, 2018 at 7:23 PM, Ilia Mirkin  wrote:
> For an approximation, you can use the sizes of the bound vbo's to
> guess a min/max index. See
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/vc4/vc4_draw.c#n183
> for an example.

I quickly played with porting something like that to mesa-lima but I
don't think it can solve our problem.
Apparently our bo currently have a fairly large fixed size so I'm not
sure we can do an equivalent calculation using bo size.
And then, min_index is required too.

On Sat, Mar 24, 2018 at 10:32 PM, Marek Olšák  wrote:
> Here is how to do it:
>
> if (max_index != ~0u)
>// index bounds are valid;
> else
>// scan the index buffer manually;
>
> u_vbuf_get_minmax_index can be used for the scanning.

mesa-lima currently does not use any vbuf function. And we currently
can't call u_vbuf_get_minmax_index since it's static in u_vbuf.c.

I suppose we can consider making u_vbuf_get_minmax_index public then.
I tested this and it works for me. It's still a bit annoying since we
need to create fields probably in lima_context (like
vc4_context.max_index does) and use those instead of the ones in
pipe_draw_info. But not a big problem I guess. We could submit this
refactor when mesa-lima gets proposed upstream.

Just for completeness, one other idea that came up was to define a new
PIPE_CAP_xxx config used to override
st_context.draw_needs_minmax_index, and set that in this driver. This
way, pipe_draw_info would come correctly filled and we wouldn't need
to explicitly assemble minmax indices during the driver draw_vbo. How
does this sound compared to the other solution?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Rob Clark]

On Mon, Mar 26, 2018 at 6:07 PM, Roland Scheidegger  wrote:
> Am 26.03.2018 um 23:01 schrieb Rob Clark:
>> correct me if I'm wrong, but I don't see how you could do the ## stuff
>> to construct the built-in type name with templates.  So I think the
>> options are tons of copy/pasta code (ie. what we had before) or
>> macros.
>>
>> I agree that could just construct the whole method with the macro.. I
>> like that better than changing VECN() macro to contain the return
>> (which I was explicitly trying to avoid in the original version, since
>> macros that contain return statements are evil)
>
> macros which don't compile are worse...
> Albeit I'm not a fan of any kind of macros, but whatever compiles.

fair enough, although tbh gcc is the compiler I have, so I tend not to
realize when I introduce things that are gcc specific.  (And, well,
the linux kernel uses constructs like these, so I tend to assume they
are fair game.)

Ian's suggestion to make the entire method body into the macro is the
approach I like best (and even more negative diff-stat).. I'll send a
patch in a few minutes.

BR,
-R

> Roland
>
>
>>
>> BR,
>> -R
>>
>> On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
>>> As much as I'm not a fan of C++ templates, I don't see how this
>>> preprocessor macro reinvention of that mechanism is an improvement.
>>>
>>> On 03/26/2018 09:45 AM, Emil Velikov wrote:
 From: Emil Velikov 

 Update the macro to have the explic return. Using the current GCC
 specific macro breaks other compilers such as the Intel one or MSVC.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
 Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
 Cc: Rob Clark 
 Cc: Timothy Arceri 
 Cc: Roland Scheidegger 
 Signed-off-by: Emil Velikov 
 ---
  src/compiler/glsl_types.cpp | 30 +++---
  1 file changed, 15 insertions(+), 15 deletions(-)

 diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
 index b8caddb406..ab356cb5a0 100644
 --- a/src/compiler/glsl_types.cpp
 +++ b/src/compiler/glsl_types.cpp
 @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
 *const ts[])
 return ts[n - 1];
  }

 -#define VECN(components, sname, vname) ({\
 +#define VECN(components, sname, vname)  {\
static const glsl_type *const ts[] = { \
   sname ## _type, vname ## 2_type,\
   vname ## 3_type, vname ## 4_type,   \
   vname ## 8_type, vname ## 16_type,  \
}; \
 -  glsl_type::vec(components, ts);\
 -   })
 +  return glsl_type::vec(components, ts); \
 +   }

  const glsl_type *
  glsl_type::vec(unsigned components)
  {
 -   return VECN(components, float, vec);
 +   VECN(components, float, vec);
  }

  const glsl_type *
  glsl_type::f16vec(unsigned components)
  {
 -   return VECN(components, float16_t, f16vec);
 +   VECN(components, float16_t, f16vec);
  }

  const glsl_type *
  glsl_type::dvec(unsigned components)
  {
 -   return VECN(components, double, dvec);
 +   VECN(components, double, dvec);
  }

  const glsl_type *
  glsl_type::ivec(unsigned components)
  {
 -   return VECN(components, int, ivec);
 +   VECN(components, int, ivec);
  }

  const glsl_type *
  glsl_type::uvec(unsigned components)
  {
 -   return VECN(components, uint, uvec);
 +   VECN(components, uint, uvec);
  }

  const glsl_type *
  glsl_type::bvec(unsigned components)
  {
 -   return VECN(components, bool, bvec);
 +   VECN(components, bool, bvec);
  }

  const glsl_type *
  glsl_type::i64vec(unsigned components)
  {
 -   return VECN(components, int64_t, i64vec);
 +   VECN(components, int64_t, i64vec);
  }


  const glsl_type *
  glsl_type::u64vec(unsigned components)
  {
 -   return VECN(components, uint64_t, u64vec);
 +   VECN(components, uint64_t, u64vec);
  }

  const glsl_type *
  glsl_type::i16vec(unsigned components)
  {
 -   return VECN(components, int16_t, i16vec);
 +   VECN(components, int16_t, i16vec);
  }


  const glsl_type *
  glsl_type::u16vec(unsigned components)
  {
 -   return VECN(components, uint16_t, u16vec);
 +   VECN(components, uint16_t, u16vec);
  }

  const glsl_type *
  glsl_type::i8vec(unsigned components)
  {
 -   return VECN(components, int8_t, i8vec);
 +   VECN(components, int8_t, i8vec);
  }


  const glsl_type *
  

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Ian Romanick]

On 03/26/2018 02:01 PM, Rob Clark wrote:
> correct me if I'm wrong, but I don't see how you could do the ## stuff
> to construct the built-in type name with templates.  So I think the
> options are tons of copy/pasta code (ie. what we had before) or
> macros.

That is true... I don't know why my eyes just glazed over that.  I think
there actually is a way when the table is outside the function, but that
wanders pretty far out of the original intent...  maybe best to ignore
my grumpiness today.

> I agree that could just construct the whole method with the macro.. I
> like that better than changing VECN() macro to contain the return
> (which I was explicitly trying to avoid in the original version, since
> macros that contain return statements are evil)
> 
> BR,
> -R
> 
> On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
>> As much as I'm not a fan of C++ templates, I don't see how this
>> preprocessor macro reinvention of that mechanism is an improvement.
>>
>> On 03/26/2018 09:45 AM, Emil Velikov wrote:
>>> From: Emil Velikov 
>>>
>>> Update the macro to have the explic return. Using the current GCC
>>> specific macro breaks other compilers such as the Intel one or MSVC.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
>>> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
>>> Cc: Rob Clark 
>>> Cc: Timothy Arceri 
>>> Cc: Roland Scheidegger 
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  src/compiler/glsl_types.cpp | 30 +++---
>>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
>>> index b8caddb406..ab356cb5a0 100644
>>> --- a/src/compiler/glsl_types.cpp
>>> +++ b/src/compiler/glsl_types.cpp
>>> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
>>> *const ts[])
>>> return ts[n - 1];
>>>  }
>>>
>>> -#define VECN(components, sname, vname) ({\
>>> +#define VECN(components, sname, vname)  {\
>>>static const glsl_type *const ts[] = { \
>>>   sname ## _type, vname ## 2_type,\
>>>   vname ## 3_type, vname ## 4_type,   \
>>>   vname ## 8_type, vname ## 16_type,  \
>>>}; \
>>> -  glsl_type::vec(components, ts);\
>>> -   })
>>> +  return glsl_type::vec(components, ts); \
>>> +   }
>>>
>>>  const glsl_type *
>>>  glsl_type::vec(unsigned components)
>>>  {
>>> -   return VECN(components, float, vec);
>>> +   VECN(components, float, vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::f16vec(unsigned components)
>>>  {
>>> -   return VECN(components, float16_t, f16vec);
>>> +   VECN(components, float16_t, f16vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::dvec(unsigned components)
>>>  {
>>> -   return VECN(components, double, dvec);
>>> +   VECN(components, double, dvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::ivec(unsigned components)
>>>  {
>>> -   return VECN(components, int, ivec);
>>> +   VECN(components, int, ivec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::uvec(unsigned components)
>>>  {
>>> -   return VECN(components, uint, uvec);
>>> +   VECN(components, uint, uvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::bvec(unsigned components)
>>>  {
>>> -   return VECN(components, bool, bvec);
>>> +   VECN(components, bool, bvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i64vec(unsigned components)
>>>  {
>>> -   return VECN(components, int64_t, i64vec);
>>> +   VECN(components, int64_t, i64vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u64vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint64_t, u64vec);
>>> +   VECN(components, uint64_t, u64vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i16vec(unsigned components)
>>>  {
>>> -   return VECN(components, int16_t, i16vec);
>>> +   VECN(components, int16_t, i16vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u16vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint16_t, u16vec);
>>> +   VECN(components, uint16_t, u16vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i8vec(unsigned components)
>>>  {
>>> -   return VECN(components, int8_t, i8vec);
>>> +   VECN(components, int8_t, i8vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u8vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint8_t, u8vec);
>>> +   VECN(components, uint8_t, u8vec);
>>>  }
>>>
>>>  const glsl_type *
>>>
>>
>> ___
>> 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

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Roland Scheidegger]

Am 26.03.2018 um 23:01 schrieb Rob Clark:
> correct me if I'm wrong, but I don't see how you could do the ## stuff
> to construct the built-in type name with templates.  So I think the
> options are tons of copy/pasta code (ie. what we had before) or
> macros.
> 
> I agree that could just construct the whole method with the macro.. I
> like that better than changing VECN() macro to contain the return
> (which I was explicitly trying to avoid in the original version, since
> macros that contain return statements are evil)

macros which don't compile are worse...
Albeit I'm not a fan of any kind of macros, but whatever compiles.

Roland


> 
> BR,
> -R
> 
> On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
>> As much as I'm not a fan of C++ templates, I don't see how this
>> preprocessor macro reinvention of that mechanism is an improvement.
>>
>> On 03/26/2018 09:45 AM, Emil Velikov wrote:
>>> From: Emil Velikov 
>>>
>>> Update the macro to have the explic return. Using the current GCC
>>> specific macro breaks other compilers such as the Intel one or MSVC.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
>>> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
>>> Cc: Rob Clark 
>>> Cc: Timothy Arceri 
>>> Cc: Roland Scheidegger 
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  src/compiler/glsl_types.cpp | 30 +++---
>>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
>>> index b8caddb406..ab356cb5a0 100644
>>> --- a/src/compiler/glsl_types.cpp
>>> +++ b/src/compiler/glsl_types.cpp
>>> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
>>> *const ts[])
>>> return ts[n - 1];
>>>  }
>>>
>>> -#define VECN(components, sname, vname) ({\
>>> +#define VECN(components, sname, vname)  {\
>>>static const glsl_type *const ts[] = { \
>>>   sname ## _type, vname ## 2_type,\
>>>   vname ## 3_type, vname ## 4_type,   \
>>>   vname ## 8_type, vname ## 16_type,  \
>>>}; \
>>> -  glsl_type::vec(components, ts);\
>>> -   })
>>> +  return glsl_type::vec(components, ts); \
>>> +   }
>>>
>>>  const glsl_type *
>>>  glsl_type::vec(unsigned components)
>>>  {
>>> -   return VECN(components, float, vec);
>>> +   VECN(components, float, vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::f16vec(unsigned components)
>>>  {
>>> -   return VECN(components, float16_t, f16vec);
>>> +   VECN(components, float16_t, f16vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::dvec(unsigned components)
>>>  {
>>> -   return VECN(components, double, dvec);
>>> +   VECN(components, double, dvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::ivec(unsigned components)
>>>  {
>>> -   return VECN(components, int, ivec);
>>> +   VECN(components, int, ivec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::uvec(unsigned components)
>>>  {
>>> -   return VECN(components, uint, uvec);
>>> +   VECN(components, uint, uvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::bvec(unsigned components)
>>>  {
>>> -   return VECN(components, bool, bvec);
>>> +   VECN(components, bool, bvec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i64vec(unsigned components)
>>>  {
>>> -   return VECN(components, int64_t, i64vec);
>>> +   VECN(components, int64_t, i64vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u64vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint64_t, u64vec);
>>> +   VECN(components, uint64_t, u64vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i16vec(unsigned components)
>>>  {
>>> -   return VECN(components, int16_t, i16vec);
>>> +   VECN(components, int16_t, i16vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u16vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint16_t, u16vec);
>>> +   VECN(components, uint16_t, u16vec);
>>>  }
>>>
>>>  const glsl_type *
>>>  glsl_type::i8vec(unsigned components)
>>>  {
>>> -   return VECN(components, int8_t, i8vec);
>>> +   VECN(components, int8_t, i8vec);
>>>  }
>>>
>>>
>>>  const glsl_type *
>>>  glsl_type::u8vec(unsigned components)
>>>  {
>>> -   return VECN(components, uint8_t, u8vec);
>>> +   VECN(components, uint8_t, u8vec);
>>>  }
>>>
>>>  const glsl_type *
>>>
>>
>> ___
>> 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

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Rob Clark]

correct me if I'm wrong, but I don't see how you could do the ## stuff
to construct the built-in type name with templates.  So I think the
options are tons of copy/pasta code (ie. what we had before) or
macros.

I agree that could just construct the whole method with the macro.. I
like that better than changing VECN() macro to contain the return
(which I was explicitly trying to avoid in the original version, since
macros that contain return statements are evil)

BR,
-R

On Mon, Mar 26, 2018 at 4:33 PM, Ian Romanick  wrote:
> As much as I'm not a fan of C++ templates, I don't see how this
> preprocessor macro reinvention of that mechanism is an improvement.
>
> On 03/26/2018 09:45 AM, Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Update the macro to have the explic return. Using the current GCC
>> specific macro breaks other compilers such as the Intel one or MSVC.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
>> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
>> Cc: Rob Clark 
>> Cc: Timothy Arceri 
>> Cc: Roland Scheidegger 
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/compiler/glsl_types.cpp | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
>> index b8caddb406..ab356cb5a0 100644
>> --- a/src/compiler/glsl_types.cpp
>> +++ b/src/compiler/glsl_types.cpp
>> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
>> *const ts[])
>> return ts[n - 1];
>>  }
>>
>> -#define VECN(components, sname, vname) ({\
>> +#define VECN(components, sname, vname)  {\
>>static const glsl_type *const ts[] = { \
>>   sname ## _type, vname ## 2_type,\
>>   vname ## 3_type, vname ## 4_type,   \
>>   vname ## 8_type, vname ## 16_type,  \
>>}; \
>> -  glsl_type::vec(components, ts);\
>> -   })
>> +  return glsl_type::vec(components, ts); \
>> +   }
>>
>>  const glsl_type *
>>  glsl_type::vec(unsigned components)
>>  {
>> -   return VECN(components, float, vec);
>> +   VECN(components, float, vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::f16vec(unsigned components)
>>  {
>> -   return VECN(components, float16_t, f16vec);
>> +   VECN(components, float16_t, f16vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::dvec(unsigned components)
>>  {
>> -   return VECN(components, double, dvec);
>> +   VECN(components, double, dvec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::ivec(unsigned components)
>>  {
>> -   return VECN(components, int, ivec);
>> +   VECN(components, int, ivec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::uvec(unsigned components)
>>  {
>> -   return VECN(components, uint, uvec);
>> +   VECN(components, uint, uvec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::bvec(unsigned components)
>>  {
>> -   return VECN(components, bool, bvec);
>> +   VECN(components, bool, bvec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::i64vec(unsigned components)
>>  {
>> -   return VECN(components, int64_t, i64vec);
>> +   VECN(components, int64_t, i64vec);
>>  }
>>
>>
>>  const glsl_type *
>>  glsl_type::u64vec(unsigned components)
>>  {
>> -   return VECN(components, uint64_t, u64vec);
>> +   VECN(components, uint64_t, u64vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::i16vec(unsigned components)
>>  {
>> -   return VECN(components, int16_t, i16vec);
>> +   VECN(components, int16_t, i16vec);
>>  }
>>
>>
>>  const glsl_type *
>>  glsl_type::u16vec(unsigned components)
>>  {
>> -   return VECN(components, uint16_t, u16vec);
>> +   VECN(components, uint16_t, u16vec);
>>  }
>>
>>  const glsl_type *
>>  glsl_type::i8vec(unsigned components)
>>  {
>> -   return VECN(components, int8_t, i8vec);
>> +   VECN(components, int8_t, i8vec);
>>  }
>>
>>
>>  const glsl_type *
>>  glsl_type::u8vec(unsigned components)
>>  {
>> -   return VECN(components, uint8_t, u8vec);
>> +   VECN(components, uint8_t, u8vec);
>>  }
>>
>>  const glsl_type *
>>
>
> ___
> 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] glsl: soft fp64 precursor patches

[Dave Airlie]

I split all the stuff that might interfere into this nice set of patches?

They've gone through intel-ci fine.

Anyone? if not I suppose I can review Elie's stuff and he can review mine :-)

Dave.

On 12 March 2018 at 15:14, Dave Airlie  wrote:
> I've been fixing up Elie's work and although the produced shaders are large,
> and really show up the copy prop and sb liveness passes as horrible inefficent
> when you have lots of if statements, I think we should start angling towards
> upstreaming it.
>
> It now passes 99% of the piglit tests on r600 with nosb, so I think the glsl
> code is pretty much working.
>
> These 6 patches are the patches to the current 64-bit lowering code to
> give it the ability to handle doubles. None of these should break anything
> currently.
>
> Dave.
>
> ___
> 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] glsl: remove GCC construct from VECN macro

[Ian Romanick]

On 03/26/2018 01:33 PM, Ian Romanick wrote:
> As much as I'm not a fan of C++ templates, I don't see how this
> preprocessor macro reinvention of that mechanism is an improvement.

At least if we're going to do this, can we put the whole body of the
function in the macro, as is done elsewhere?

> On 03/26/2018 09:45 AM, Emil Velikov wrote:
>> From: Emil Velikov 
>>
>> Update the macro to have the explic return. Using the current GCC
>> specific macro breaks other compilers such as the Intel one or MSVC.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
>> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
>> Cc: Rob Clark 
>> Cc: Timothy Arceri 
>> Cc: Roland Scheidegger 
>> Signed-off-by: Emil Velikov 
>> ---
>>  src/compiler/glsl_types.cpp | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
>> index b8caddb406..ab356cb5a0 100644
>> --- a/src/compiler/glsl_types.cpp
>> +++ b/src/compiler/glsl_types.cpp
>> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
>> *const ts[])
>> return ts[n - 1];
>>  }
>>  
>> -#define VECN(components, sname, vname) ({\
>> +#define VECN(components, sname, vname)  {\
>>static const glsl_type *const ts[] = { \
>>   sname ## _type, vname ## 2_type,\
>>   vname ## 3_type, vname ## 4_type,   \
>>   vname ## 8_type, vname ## 16_type,  \
>>}; \
>> -  glsl_type::vec(components, ts);\
>> -   })
>> +  return glsl_type::vec(components, ts); \
>> +   }
>>  
>>  const glsl_type *
>>  glsl_type::vec(unsigned components)
>>  {
>> -   return VECN(components, float, vec);
>> +   VECN(components, float, vec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::f16vec(unsigned components)
>>  {
>> -   return VECN(components, float16_t, f16vec);
>> +   VECN(components, float16_t, f16vec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::dvec(unsigned components)
>>  {
>> -   return VECN(components, double, dvec);
>> +   VECN(components, double, dvec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::ivec(unsigned components)
>>  {
>> -   return VECN(components, int, ivec);
>> +   VECN(components, int, ivec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::uvec(unsigned components)
>>  {
>> -   return VECN(components, uint, uvec);
>> +   VECN(components, uint, uvec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::bvec(unsigned components)
>>  {
>> -   return VECN(components, bool, bvec);
>> +   VECN(components, bool, bvec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::i64vec(unsigned components)
>>  {
>> -   return VECN(components, int64_t, i64vec);
>> +   VECN(components, int64_t, i64vec);
>>  }
>>  
>>  
>>  const glsl_type *
>>  glsl_type::u64vec(unsigned components)
>>  {
>> -   return VECN(components, uint64_t, u64vec);
>> +   VECN(components, uint64_t, u64vec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::i16vec(unsigned components)
>>  {
>> -   return VECN(components, int16_t, i16vec);
>> +   VECN(components, int16_t, i16vec);
>>  }
>>  
>>  
>>  const glsl_type *
>>  glsl_type::u16vec(unsigned components)
>>  {
>> -   return VECN(components, uint16_t, u16vec);
>> +   VECN(components, uint16_t, u16vec);
>>  }
>>  
>>  const glsl_type *
>>  glsl_type::i8vec(unsigned components)
>>  {
>> -   return VECN(components, int8_t, i8vec);
>> +   VECN(components, int8_t, i8vec);
>>  }
>>  
>>  
>>  const glsl_type *
>>  glsl_type::u8vec(unsigned components)
>>  {
>> -   return VECN(components, uint8_t, u8vec);
>> +   VECN(components, uint8_t, u8vec);
>>  }
>>  
>>  const glsl_type *
>>
> 

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

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Ian Romanick]

As much as I'm not a fan of C++ templates, I don't see how this
preprocessor macro reinvention of that mechanism is an improvement.

On 03/26/2018 09:45 AM, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Update the macro to have the explic return. Using the current GCC
> specific macro breaks other compilers such as the Intel one or MSVC.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
> Cc: Rob Clark 
> Cc: Timothy Arceri 
> Cc: Roland Scheidegger 
> Signed-off-by: Emil Velikov 
> ---
>  src/compiler/glsl_types.cpp | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
> index b8caddb406..ab356cb5a0 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
> *const ts[])
> return ts[n - 1];
>  }
>  
> -#define VECN(components, sname, vname) ({\
> +#define VECN(components, sname, vname)  {\
>static const glsl_type *const ts[] = { \
>   sname ## _type, vname ## 2_type,\
>   vname ## 3_type, vname ## 4_type,   \
>   vname ## 8_type, vname ## 16_type,  \
>}; \
> -  glsl_type::vec(components, ts);\
> -   })
> +  return glsl_type::vec(components, ts); \
> +   }
>  
>  const glsl_type *
>  glsl_type::vec(unsigned components)
>  {
> -   return VECN(components, float, vec);
> +   VECN(components, float, vec);
>  }
>  
>  const glsl_type *
>  glsl_type::f16vec(unsigned components)
>  {
> -   return VECN(components, float16_t, f16vec);
> +   VECN(components, float16_t, f16vec);
>  }
>  
>  const glsl_type *
>  glsl_type::dvec(unsigned components)
>  {
> -   return VECN(components, double, dvec);
> +   VECN(components, double, dvec);
>  }
>  
>  const glsl_type *
>  glsl_type::ivec(unsigned components)
>  {
> -   return VECN(components, int, ivec);
> +   VECN(components, int, ivec);
>  }
>  
>  const glsl_type *
>  glsl_type::uvec(unsigned components)
>  {
> -   return VECN(components, uint, uvec);
> +   VECN(components, uint, uvec);
>  }
>  
>  const glsl_type *
>  glsl_type::bvec(unsigned components)
>  {
> -   return VECN(components, bool, bvec);
> +   VECN(components, bool, bvec);
>  }
>  
>  const glsl_type *
>  glsl_type::i64vec(unsigned components)
>  {
> -   return VECN(components, int64_t, i64vec);
> +   VECN(components, int64_t, i64vec);
>  }
>  
>  
>  const glsl_type *
>  glsl_type::u64vec(unsigned components)
>  {
> -   return VECN(components, uint64_t, u64vec);
> +   VECN(components, uint64_t, u64vec);
>  }
>  
>  const glsl_type *
>  glsl_type::i16vec(unsigned components)
>  {
> -   return VECN(components, int16_t, i16vec);
> +   VECN(components, int16_t, i16vec);
>  }
>  
>  
>  const glsl_type *
>  glsl_type::u16vec(unsigned components)
>  {
> -   return VECN(components, uint16_t, u16vec);
> +   VECN(components, uint16_t, u16vec);
>  }
>  
>  const glsl_type *
>  glsl_type::i8vec(unsigned components)
>  {
> -   return VECN(components, int8_t, i8vec);
> +   VECN(components, int8_t, i8vec);
>  }
>  
>  
>  const glsl_type *
>  glsl_type::u8vec(unsigned components)
>  {
> -   return VECN(components, uint8_t, u8vec);
> +   VECN(components, uint8_t, u8vec);
>  }
>  
>  const glsl_type *
> 

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

[Mesa-dev] [Bug 104665] r600: computer shaders break Bioshock on barts (bisected)

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 CC||m...@protonmail.ch

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

[Mesa-dev] [PATCH shaderdb] run: handling binding of attribute variable name (v2)

[Dongwon Kim]

Optional binding of variables can be processed before linking shader
objects for creating shader program. It is activated by adding lines
with a keyword "BindAttribLoc" followed by name and index as,

"BindAttribLoc name_str1 "

For example,

[require]
..
BindAttrbLoc vertex 1
BindAttrbLoc coord 2
BindAttrbLoc col 3

This makes the shader-db run

glBindAttribLocation(p, 1, "vertex");
glBindAttribLocation(p, 2, "coord");
glBindAttribLocation(p, 3, "col");

before glLinkProgram() to include these binding info in binary shader
program.

v2: get_shaders returns its own head of list for binding variables
instead of using a global head to support parallel processing of
multiple shader_tests

Signed-off-by: Dongwon Kim 
---
 run.c | 81 +--
 1 file changed, 79 insertions(+), 2 deletions(-)

diff --git a/run.c b/run.c
index 4712e27..ce8ef41 100644
--- a/run.c
+++ b/run.c
@@ -71,6 +71,12 @@ struct shader {
 int type;
 };
 
+struct binding_list {
+char *name;
+GLint index;
+struct binding_list *prev;
+};
+
 static bool
 extension_in_string(const char *haystack, const char *needle)
 {
@@ -100,13 +106,15 @@ extension_in_string(const char *haystack, const char 
*needle)
 return false;
 }
 
+#define SKIP_SPACES(str) while (*(str) == ' ') str++
+
 static struct shader *
 get_shaders(const struct context_info *core, const struct context_info *compat,
 const struct context_info *es,
 const char *text, size_t text_size,
 enum shader_type *type, unsigned *num_shaders,
 bool *use_separate_shader_objects,
-const char *shader_name)
+const char *shader_name, struct binding_list *binding)
 {
 static const char *req = "[require]";
 static const char *gl_req = "\nGL >= ";
@@ -115,6 +123,7 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 static const char *fp_req = "\nGL_ARB_fragment_program";
 static const char *vp_req = "\nGL_ARB_vertex_program";
 static const char *sso_req = "\nSSO ENABLED";
+static const char *binding_req = "\nBindAttribLoc";
 static const char *gs = "geometry shader]\n";
 static const char *fs = "fragment ";
 static const char *vs = "vertex ";
@@ -181,11 +190,13 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 const struct context_info *info = *type == TYPE_CORE ? core : compat;
 
 const char *extension_text = text;
+
 while ((extension_text = memmem(extension_text, end_text - extension_text,
 "\nGL_", strlen("\nGL_"))) != NULL) {
 extension_text += 1;
 const char *newline = memchr(extension_text, '\n',
  end_text - extension_text);
+
 if (memmem(info->extension_string, info->extension_string_len,
extension_text, newline - extension_text) == NULL) {
 fprintf(stderr, "SKIP: %s requires unavailable extension %.*s\n",
@@ -197,6 +208,62 @@ get_shaders(const struct context_info *core, const struct 
context_info *compat,
 }
 }
 
+/* process binding */
+struct binding_list *binding_prev = binding = NULL;
+const char *pre_binding_text = text;
+
+/* binding = NULL if there's no binding required */
+binding = NULL;
+while ((pre_binding_text = memmem(pre_binding_text, end_text - 
pre_binding_text,
+  binding_req, strlen(binding_req))) != 
NULL) {
+pre_binding_text += strlen(binding_req);
+
+const char *newline = memchr(pre_binding_text, '\n', end_text - 
pre_binding_text);
+
+SKIP_SPACES(pre_binding_text);
+
+char *endword = memchr(pre_binding_text, ' ', newline - 
pre_binding_text);
+
+/* if there's no more space in the same line */
+if (!endword) {
+fprintf(stderr, "SKIP: can't find attr index for this binding\n");
+continue;
+}
+
+char *binding_name = (char *)calloc(1, endword - pre_binding_text + 1);
+
+strncpy(binding_name, pre_binding_text, endword - pre_binding_text);
+
+pre_binding_text = endword;
+
+SKIP_SPACES(pre_binding_text);
+if (*pre_binding_text == '\n') {
+fprintf(stderr, "SKIP: can't find attr variable name for this 
binding\n");
+continue;
+}
+
+endword = memchr(pre_binding_text, ' ', newline - pre_binding_text);
+
+if (!endword)
+endword = (char *)newline;
+
+char *index_string = calloc(1, endword - pre_binding_text + 1);
+strncpy(index_string, pre_binding_text, endword - pre_binding_text);
+
+struct binding_list *binding_new = malloc(sizeof(struct binding_list));
+
+binding_new->index = strtol(index_string, NULL, 10);
+binding_new->name = binding_name;
+binding_new->prev = 

Re: [Mesa-dev] [PATCH] glsl: remove GCC construct from VECN macro

[Matt Turner]

On Mon, Mar 26, 2018 at 9:45 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Update the macro to have the explic return. Using the current GCC
> specific macro breaks other compilers such as the Intel one or MSVC.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
> Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
> Cc: Rob Clark 
> Cc: Timothy Arceri 
> Cc: Roland Scheidegger 
> Signed-off-by: Emil Velikov 

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

[Mesa-dev] [Bug 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 CC||m...@protonmail.ch

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

[Mesa-dev] [PATCH 2/2] autotools: Include intel/dev/meson.build in tarball

[Dylan Baker]

FixeS: 272bef0601a1bdb5292771aefc8d62fcbdf4c47f
   ("intel: Split gen_device_info out into libintel_dev")
Signed-off-by: Dylan Baker 
---
 src/intel/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
index bfb7f5b9f08..2f96a68d992 100644
--- a/src/intel/Makefile.am
+++ b/src/intel/Makefile.am
@@ -66,6 +66,7 @@ EXTRA_DIST = \
blorp/meson.build \
common/meson.build \
compiler/meson.build \
+   dev/meson.build \
genxml/meson.build \
isl/meson.build \
tools/meson.build \
-- 
2.16.2

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

[Mesa-dev] [PATCH 1/2] autotools: include meson_get_version

[Dylan Baker]

Otherwise meson won't read the VERSION file and won't set a version.
That means that pkg-config files will have version unset as well.

Signed-off-by: Dylan Baker 
fixes: 3e9533d9b88d75d99632fa40e38cfed842d10842
   ("meson: Add script to use VERSION file for getting version")
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 804b1d85353..a83f2bcb5f4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -64,7 +64,8 @@ EXTRA_DIST = \
meson_options.txt \
bin/meson.build \
include/meson.build \
-   bin/install_megadrivers.py
+   bin/install_megadrivers.py \
+   bin/meson_get_version.py
 
 noinst_HEADERS = \
include/c99_alloca.h \
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH 02/11] i965: initialize SPIR-V capabilities

[Jason Ekstrand]

On March 26, 2018 07:53:44 Alejandro Piñeiro  wrote:

Ping.

This is the only pending patch to review from this series. Although it is 
independent enough and I could submit to master the rest of the series, I 
would prefer to push all the series, and move to shape a second batch 
without pending patches around.


Thanks in advance.


On 08/03/18 09:19, Alejandro Piñeiro wrote:
Needed for ARB_gl_spirv. Right now those are the same that the intel
vulkan driver, but those are not shared. From the ARB_spirv_extensions
spec:

"3. If a new GL extension is added that includes SPIR-V support via
a new SPIR-V extension does it's SPIR-V extension also get
enumerated by the SPIR_V_EXTENSIONS_ARB query?.

RESOLVED. Yes. It's good to include it for consistency. Any SPIR-V
functionality supported beyond the SPIR-V version that is required
for the GL API version should be enumerated."

Reading between lines, there is the possibility of specific GL
extensions enabling specific SPIR-V extensions (so capabilities). That
would mean that it is possible that OpenGL and Vulkan not having the
same capabilities supported, even for the same driver. So for now we
keep them separate. Perhaps in the future it is better to keep them
the same and synced.

Note: we initialize SPIR-V capabilities at brwCreateContext instead of
the usual brw_initialize_context_constants because we want to do that
only for version >= 3.3. At brw_initialize_context_constans GL version
is still not computed.

v2:
* Rebase update (SpirVCapabilities not a pointer anymore)
* Fill spirv capabilities for OpenGL >= 3.3 (Ian Romanick)
---
src/mesa/drivers/dri/i965/brw_context.c | 20 
1 file changed, 20 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c

index fca5c8e3072..abd1592c0f5 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -78,6 +78,7 @@

#include "common/gen_defines.h"

+#include "compiler/spirv/nir_spirv.h"
/***
* Mesa's Driver Functions
***/
@@ -343,6 +344,21 @@ brw_init_driver_functions(struct brw_context *brw,
brw_deserialize_program_binary;
}

+static void
+brw_initialize_spirv_supported_capabilities(struct brw_context *brw)
+{
+   const struct gen_device_info *devinfo = >screen->devinfo;
+   struct gl_context *ctx = >ctx;
+
+   ctx->Const.SpirVCapabilities.float64 = devinfo->gen >= 8;
+   ctx->Const.SpirVCapabilities.int64 = devinfo->gen >= 8;
+   ctx->Const.SpirVCapabilities.tessellation = true;
+   ctx->Const.SpirVCapabilities.draw_parameters = true;
+   ctx->Const.SpirVCapabilities.image_write_without_format = true;
+   ctx->Const.SpirVCapabilities.multiview = true;

We don't support any multiview GL extension so this should probably be dropped.


+   ctx->Const.SpirVCapabilities.variable_pointers = true;
+}
+
static void
brw_initialize_context_constants(struct brw_context *brw)
{
@@ -1063,6 +1079,10 @@ brwCreateContext(gl_api api,
_mesa_override_extensions(ctx);
_mesa_compute_version(ctx);

+   /* GL_ARB_gl_spirv */
+   if (ctx->Version >= 33)

Do we really just want to check for 3.3 here or do we also want to check 
for core profile?  Maybe we just want to check if the SPIR-V extension is 
enabled.


Also, I believe SNB supports 3.3 but it does not support basically any of 
the above capabilities.



+  brw_initialize_spirv_supported_capabilities(brw);
+
_mesa_initialize_dispatch_tables(ctx);
_mesa_initialize_vbo_vtxfmt(ctx);

___
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] glsl: remove GCC construct from VECN macro

[Emil Velikov]

From: Emil Velikov 

Update the macro to have the explic return. Using the current GCC
specific macro breaks other compilers such as the Intel one or MSVC.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105740
Fixes: f407edf3407396379e16b0be74b8d3b85d2ad7f0
Cc: Rob Clark 
Cc: Timothy Arceri 
Cc: Roland Scheidegger 
Signed-off-by: Emil Velikov 
---
 src/compiler/glsl_types.cpp | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index b8caddb406..ab356cb5a0 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -509,88 +509,88 @@ glsl_type::vec(unsigned components, const glsl_type 
*const ts[])
return ts[n - 1];
 }
 
-#define VECN(components, sname, vname) ({\
+#define VECN(components, sname, vname)  {\
   static const glsl_type *const ts[] = { \
  sname ## _type, vname ## 2_type,\
  vname ## 3_type, vname ## 4_type,   \
  vname ## 8_type, vname ## 16_type,  \
   }; \
-  glsl_type::vec(components, ts);\
-   })
+  return glsl_type::vec(components, ts); \
+   }
 
 const glsl_type *
 glsl_type::vec(unsigned components)
 {
-   return VECN(components, float, vec);
+   VECN(components, float, vec);
 }
 
 const glsl_type *
 glsl_type::f16vec(unsigned components)
 {
-   return VECN(components, float16_t, f16vec);
+   VECN(components, float16_t, f16vec);
 }
 
 const glsl_type *
 glsl_type::dvec(unsigned components)
 {
-   return VECN(components, double, dvec);
+   VECN(components, double, dvec);
 }
 
 const glsl_type *
 glsl_type::ivec(unsigned components)
 {
-   return VECN(components, int, ivec);
+   VECN(components, int, ivec);
 }
 
 const glsl_type *
 glsl_type::uvec(unsigned components)
 {
-   return VECN(components, uint, uvec);
+   VECN(components, uint, uvec);
 }
 
 const glsl_type *
 glsl_type::bvec(unsigned components)
 {
-   return VECN(components, bool, bvec);
+   VECN(components, bool, bvec);
 }
 
 const glsl_type *
 glsl_type::i64vec(unsigned components)
 {
-   return VECN(components, int64_t, i64vec);
+   VECN(components, int64_t, i64vec);
 }
 
 
 const glsl_type *
 glsl_type::u64vec(unsigned components)
 {
-   return VECN(components, uint64_t, u64vec);
+   VECN(components, uint64_t, u64vec);
 }
 
 const glsl_type *
 glsl_type::i16vec(unsigned components)
 {
-   return VECN(components, int16_t, i16vec);
+   VECN(components, int16_t, i16vec);
 }
 
 
 const glsl_type *
 glsl_type::u16vec(unsigned components)
 {
-   return VECN(components, uint16_t, u16vec);
+   VECN(components, uint16_t, u16vec);
 }
 
 const glsl_type *
 glsl_type::i8vec(unsigned components)
 {
-   return VECN(components, int8_t, i8vec);
+   VECN(components, int8_t, i8vec);
 }
 
 
 const glsl_type *
 glsl_type::u8vec(unsigned components)
 {
-   return VECN(components, uint8_t, u8vec);
+   VECN(components, uint8_t, u8vec);
 }
 
 const glsl_type *
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] gallium: Correct minor typo in header comments

[Dylan Baker]

Quoting Alyssa Rosenzweig (2018-03-26 08:56:53)
> Signed-off-by: Alyssa Rosenzweig 
> ---
>  src/gallium/include/state_tracker/graw.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/include/state_tracker/graw.h 
> b/src/gallium/include/state_tracker/graw.h
> index 217fa31ba1..78ddf0a87f 100644
> --- a/src/gallium/include/state_tracker/graw.h
> +++ b/src/gallium/include/state_tracker/graw.h
> @@ -33,7 +33,7 @@
>   * necessary to implement this interface is orchestrated by the
>   * individual target building this entity.
>   *
> - * For instance, the graw-xlib target includes code to implent these
> + * For instance, the graw-xlib target includes code to implement these
>   * interfaces on top of the X window system.
>   *
>   * Programs using this interface may additionally benefit from some of
> -- 
> 2.16.1
> 

Reviewed-by: Dylan Baker 

Do you have commit access, or should I push this for you?


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

Re: [Mesa-dev] [PATCH] glsl: fix infinite loop caused by bug in loop unrolling pass

[Ian Romanick]

On 03/25/2018 04:31 PM, Timothy Arceri wrote:
> Just checking for 2 jumps is not enough to be sure we can do a
> complex loop unroll. We need to make sure we also have also found
> 2 loop terminators.
> 
> Without this we were attempting to unroll a loop where the second
> jump was nesed inside multiple ifs which loop analysis is unable

   nested

> to detect as a terminator. We ended up splicing out the first
> terminator but failed to actually unroll the loop, this resulted
> in the creation of a possible infinite loop.
> 
> Fixes: 646621c66da9 "glsl: make loop unrolling more like the nir unrolling 
> path"
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=105670

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

Based on my understanding of this code, I think this is correct.

Reviewed-by: Ian Romanick 

> ---
>  src/compiler/glsl/loop_unroll.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/loop_unroll.cpp 
> b/src/compiler/glsl/loop_unroll.cpp
> index 6e06a30fb91..f6efe6475a0 100644
> --- a/src/compiler/glsl/loop_unroll.cpp
> +++ b/src/compiler/glsl/loop_unroll.cpp
> @@ -519,7 +519,7 @@ loop_unroll_visitor::visit_leave(ir_loop *ir)
>  * isn't any additional unknown terminators, or any other jumps nested
>  * inside futher ifs.
>  */
> -   if (ls->num_loop_jumps != 2)
> +   if (ls->num_loop_jumps != 2 || ls->terminators.length() != 2)
>return visit_continue;
>  
> ir_instruction *first_ir =
> 

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

[Mesa-dev] [PATCH] gallium: Correct minor typo in header comments

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/include/state_tracker/graw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/include/state_tracker/graw.h 
b/src/gallium/include/state_tracker/graw.h
index 217fa31ba1..78ddf0a87f 100644
--- a/src/gallium/include/state_tracker/graw.h
+++ b/src/gallium/include/state_tracker/graw.h
@@ -33,7 +33,7 @@
  * necessary to implement this interface is orchestrated by the
  * individual target building this entity.
  *
- * For instance, the graw-xlib target includes code to implent these
+ * For instance, the graw-xlib target includes code to implement these
  * interfaces on top of the X window system.
  *
  * Programs using this interface may additionally benefit from some of
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Chih-Wei Huang]

2018-03-22 16:23 GMT+08:00 Tomasz Figa :
> Hi Chih-Wei,
>
> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang  wrote:
>> 2018-02-21 3:03 GMT+08:00 Rob Herring :
>>>
>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>> then may change opinions some. We already have to handle multiple
>>> opens share the same pipe_screen, so I don't think reusing the fd buys
>>> us anything.
>>>
>>> Maybe we're close to the point of removing the flink name support too.
>>> The android-x86 folks have been working to get dma-bufs working.
>>> Chih-Wei, any comments on this?
>>
>> Ah! Sorry. I didn't catch or understand the details.
>> Did you mean the attempts to use drm_hwcomposer
>> in android-x86?
>> My understanding so far is most x86 GPUs won't work
>> except some very limited models.
>> It's due to kernel driver issues which may never be solved.
>> So we can't drop the flink name support.
>> Please correct me if I am wrong.
>
> Could you elaborate a bit more on those GPUs that won't work and
> corresponding driver issues? We're running cros_gralloc on Intel and
> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
> any problems.

Hi Tomasz,
I remember (in our previous discussion) you said
CrOS uses your own hwcomposer (proprietary?) so
the story may be different.

What we have tried is gbm_gralloc + drm_hwcomposer
and I reported the issues here:
https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html

Sorry I didn't make more tests recently.
I CC Mauro to comment. He should have made more tests
with newer kernel and mesa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson/configure: detect endian.h instead of trying to guess when it's available

[Khem Raj]

On Wed, Mar 21, 2018 at 10:09 AM, Eric Engestrom
 wrote:
> Cc: Maxin B. John 
> Cc: Khem Raj 
> Suggested-by: Jon Turney 
> Signed-off-by: Eric Engestrom 
> ---
>  configure.ac| 1 +
>  meson.build | 2 +-
>  src/util/u_endian.h | 2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 29d3c3457a7cdaefc36a..36c56da787e4fab5a355 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -865,6 +865,7 @@ fi
>  AC_HEADER_MAJOR
>  AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
>  AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
> +AC_CHECK_HEADER([endian.h], [DEFINES="$DEFINES -DHAVE_ENDIAN_H"])
>  AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
>  AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
>  AC_CHECK_FUNC([timespec_get], [DEFINES="$DEFINES -DHAVE_TIMESPEC_GET"])
> diff --git a/meson.build b/meson.build
> index 88518ec0f0e9b81759a7..1132b4bd37075d8c9d21 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -904,7 +904,7 @@ elif cc.has_header_symbol('sys/mkdev.h', 'major')
>pre_args += '-DMAJOR_IN_MKDEV'
>  endif
>
> -foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h']
> +foreach h : ['xlocale.h', 'sys/sysctl.h', 'linux/futex.h', 'endian.h']
>if cc.compiles('#include <@0@>'.format(h), name : '@0@ works'.format(h))
>  pre_args += '-DHAVE_@0@'.format(h.to_upper().underscorify())
>endif
> diff --git a/src/util/u_endian.h b/src/util/u_endian.h
> index 22d011ec0086ee77e11c..e11b381588dbc960e8c3 100644
> --- a/src/util/u_endian.h
> +++ b/src/util/u_endian.h
> @@ -27,7 +27,7 @@
>  #ifndef U_ENDIAN_H
>  #define U_ENDIAN_H
>
> -#if defined(__GLIBC__) || defined(ANDROID) || defined(__CYGWIN__)
> +#ifdef HAVE_ENDIAN_H
>  #include 
>
>  #if __BYTE_ORDER == __LITTLE_ENDIAN

I like this patch better than what I had done. Please go ahead with this change
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 18/21] clover: Handle CL_PROGRAM_IL in clGetProgramInfo

[Karol Herbst]

Reviewed-by: Karol Herbst 

On Sun, Mar 25, 2018 at 8:02 PM, Pierre Moreau  wrote:
> Signed-off-by: Pierre Moreau 
> ---
>  src/gallium/state_trackers/clover/api/program.cpp | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/api/program.cpp 
> b/src/gallium/state_trackers/clover/api/program.cpp
> index 3c7e56efb9..851a212b99 100644
> --- a/src/gallium/state_trackers/clover/api/program.cpp
> +++ b/src/gallium/state_trackers/clover/api/program.cpp
> @@ -429,6 +429,13 @@ clGetProgramInfo(cl_program d_prog, cl_program_info 
> param,
>buf.as_string() = prog.source();
>break;
>
> +   case CL_PROGRAM_IL:
> +  if (prog.has_il)
> + buf.as_vector() = prog.il();
> +  else if (r_size)
> + *r_size = 0u;
> +  break;
> +
> case CL_PROGRAM_BINARY_SIZES:
>buf.as_vector() = map([&](const device ) {
>  return prog.build(dev).binary.size();
> --
> 2.16.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/5] i965: Hard code scratch_ids_per_subslice for Cherryview

[Juan A. Suarez Romero]

On Wed, 2018-03-07 at 00:16 -0800, Jordan Justen wrote:
> Ken suggested that we might be underallocating scratch space on HD
> 400. Allocating scratch space as though there was actually 8 EUs
> seems to help with a GPU hang seen on synmark CSDof.
> 

FYI, in order to pick this commit for next 17.3 stable release, I need to pick
also:

commit f9d5a7add42af5a2e4410526d1480a08f41317ae
Author: Jordan Justen 
Date:   Tue Oct 31 00:34:32 2017 -0700

i965: Calculate thread_count in brw_alloc_stage_scratch
  

Unless you prefer not picking them, I'll add both.


Cheers!


J.A.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104636
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105290
> Cc: Kenneth Graunke 
> Cc: Eero Tamminen 
> Cc: 
> Signed-off-by: Jordan Justen 
> ---
>  src/mesa/drivers/dri/i965/brw_program.c | 44 
> -
>  1 file changed, 27 insertions(+), 17 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 527f003977b..c121136c439 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -402,23 +402,33 @@ brw_alloc_stage_scratch(struct brw_context *brw,
>if (devinfo->gen >= 9)
>   subslices = 4 * brw->screen->devinfo.num_slices;
>  
> -  /* WaCSScratchSize:hsw
> -   *
> -   * Haswell's scratch space address calculation appears to be sparse
> -   * rather than tightly packed.  The Thread ID has bits indicating
> -   * which subslice, EU within a subslice, and thread within an EU
> -   * it is.  There's a maximum of two slices and two subslices, so these
> -   * can be stored with a single bit.  Even though there are only 10 EUs
> -   * per subslice, this is stored in 4 bits, so there's an effective
> -   * maximum value of 16 EUs.  Similarly, although there are only 7
> -   * threads per EU, this is stored in a 3 bit number, giving an 
> effective
> -   * maximum value of 8 threads per EU.
> -   *
> -   * This means that we need to use 16 * 8 instead of 10 * 7 for the
> -   * number of threads per subslice.
> -   */
> -  const unsigned scratch_ids_per_subslice =
> - devinfo->is_haswell ? 16 * 8 : devinfo->max_cs_threads;
> +  unsigned scratch_ids_per_subslice;
> +  if (devinfo->is_haswell) {
> + /* WaCSScratchSize:hsw
> +  *
> +  * Haswell's scratch space address calculation appears to be sparse
> +  * rather than tightly packed. The Thread ID has bits indicating
> +  * which subslice, EU within a subslice, and thread within an EU it
> +  * is. There's a maximum of two slices and two subslices, so these
> +  * can be stored with a single bit. Even though there are only 10 
> EUs
> +  * per subslice, this is stored in 4 bits, so there's an effective
> +  * maximum value of 16 EUs. Similarly, although there are only 7
> +  * threads per EU, this is stored in a 3 bit number, giving an
> +  * effective maximum value of 8 threads per EU.
> +  *
> +  * This means that we need to use 16 * 8 instead of 10 * 7 for the
> +  * number of threads per subslice.
> +  */
> + scratch_ids_per_subslice = 16 * 8;
> +  } else if (devinfo->is_cherryview) {
> + /* For Cherryview, it appears that the scratch addresses for the 6 
> EU
> +  * devices may still generate compute scratch addresses covering the
> +  * same range as 8 EU.
> +  */
> + scratch_ids_per_subslice = 8 * 7;
> +  } else {
> + scratch_ids_per_subslice = devinfo->max_cs_threads;
> +  }
>  
>thread_count = scratch_ids_per_subslice * subslices;
>break;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105737] st_tests_common.cpp:140:42: error: no matching function for call to 'tgsi_get_opcode_info'

[bugzilla-daemon]

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

Brian Paul  changed:

   What|Removed |Added

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

--- Comment #2 from Brian Paul  ---
Pushed as commit a21da49e5c55f8e61253503d865cef936125ea5f.

Thanks, Gert!

-- 
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/st/tests: Use tgsi opcode enum also in the test classes

[Gert Wollny]

Am Montag, den 26.03.2018, 08:46 -0600 schrieb Brian Paul:
> Reviewed-by: Brian Paul 

I forgot to mention: I can't push, could you take care of this? 

Thanks, 
Gert 

> 
> Sorry for the breakage.
> 
> -Brian
> 
> On 03/26/2018 02:17 AM, Gert Wollny wrote:
> > Fixes: ec478cf9c31c3775a21cd7b5b4b5cdd9263bde9e
> >  st/mesa,tgsi: use enum tgsi_opcode
> > Bugzilla: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs
> > .freedesktop.org_show-5Fbug.cgi-3Fid-
> > 3D105737=DwIBAg=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgof
> > w0ITcfE8JKfaUjIQhncGA=lq2W5BZEbroPgPpeg6LQhQDMza_vdl8IYWN8cSDPsBw
> > =RbSoaOlqbBS4Vq039rA2vIel6dkwOkK7V2OhXuLlPdI=
> > Signed-off-by: Gert Wollny 
> > ---
> >   src/mesa/state_tracker/tests/st_tests_common.cpp |  6 +++---
> >   src/mesa/state_tracker/tests/st_tests_common.h   | 10 +-
> >   2 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/src/mesa/state_tracker/tests/st_tests_common.cpp
> > b/src/mesa/state_tracker/tests/st_tests_common.cpp
> > index ea01ca..63e3d6b2c4 100644
> > --- a/src/mesa/state_tracker/tests/st_tests_common.cpp
> > +++ b/src/mesa/state_tracker/tests/st_tests_common.cpp
> > @@ -43,7 +43,7 @@ using std::tuple;
> >   /* Implementation of helper and test classes */
> >   void *FakeCodeline::mem_ctx = nullptr;
> >   
> > -FakeCodeline::FakeCodeline(unsigned _op, const vector& _dst,
> > +FakeCodeline::FakeCodeline(tgsi_opcode _op, const vector&
> > _dst,
> >  const vector& _src, const
> > vector&_to):
> >  op(_op),
> >  max_temp_id(0)
> > @@ -59,7 +59,7 @@ FakeCodeline::FakeCodeline(unsigned _op, const
> > vector& _dst,
> >   
> >   }
> >   
> > -FakeCodeline::FakeCodeline(unsigned _op, const
> > vector>& _dst,
> > +FakeCodeline::FakeCodeline(tgsi_opcode _op, const
> > vector>& _dst,
> >  const vector>&
> > _src,
> >  const vector > *>>&_to,
> >  SWZ with_swizzle):
> > @@ -84,7 +84,7 @@ FakeCodeline::FakeCodeline(unsigned _op, const
> > vector>& _dst,
> >  });
> >   }
> >   
> > -FakeCodeline::FakeCodeline(unsigned _op, const
> > vector>& _dst,
> > +FakeCodeline::FakeCodeline(tgsi_opcode _op, const
> > vector>& _dst,
> >  const vector>&
> > _src,
> >  const vector>&_to,
> > RA with_reladdr):
> >  op(_op),
> > diff --git a/src/mesa/state_tracker/tests/st_tests_common.h
> > b/src/mesa/state_tracker/tests/st_tests_common.h
> > index 2e18832923..6d855fe581 100644
> > --- a/src/mesa/state_tracker/tests/st_tests_common.h
> > +++ b/src/mesa/state_tracker/tests/st_tests_common.h
> > @@ -40,15 +40,15 @@ struct RA {};
> >   
> >   /* A line to describe a TGSI instruction for building mock
> > shaders. */
> >   struct FakeCodeline {
> > -   FakeCodeline(unsigned _op): op(_op), max_temp_id(0) {}
> > -   FakeCodeline(unsigned _op, const std::vector& _dst, const
> > std::vector& _src,
> > +   FakeCodeline(tgsi_opcode _op): op(_op), max_temp_id(0) {}
> > +   FakeCodeline(tgsi_opcode _op, const std::vector& _dst,
> > const std::vector& _src,
> >   const std::vector&_to);
> >   
> > -   FakeCodeline(unsigned _op, const
> > std::vector>& _dst,
> > +   FakeCodeline(tgsi_opcode _op, const
> > std::vector>& _dst,
> >   const std::vector>&
> > _src,
> >   const std::vector > *>>&_to, SWZ with_swizzle);
> >   
> > -   FakeCodeline(unsigned _op, const
> > std::vector>& _dst,
> > +   FakeCodeline(tgsi_opcode _op, const
> > std::vector>& _dst,
> >   const std::vector>& _src,
> >   const std::vector>&_to,
> > RA with_reladdr);
> >   
> > @@ -78,7 +78,7 @@ private:
> >  template 
> >  void read_reg(const st_reg& s);
> >   
> > -   unsigned op;
> > +   tgsi_opcode op;
> >  std::vector dst;
> >  std::vector src;
> >  std::vector tex_offsets;
> > 
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/11] i965: initialize SPIR-V capabilities

[Alejandro Piñeiro]

Ping.

This is the only pending patch to review from this series. Although it is 
independent enough and I could submit to master the rest of the series, I would 
prefer to push all the series, and move to shape a second batch without pending 
patches around. 

Thanks in advance.


On 08/03/18 09:19, Alejandro Piñeiro wrote:
> Needed for ARB_gl_spirv. Right now those are the same that the intel
> vulkan driver, but those are not shared. From the ARB_spirv_extensions
> spec:
>
>"3. If a new GL extension is added that includes SPIR-V support via
>a new SPIR-V extension does it's SPIR-V extension also get
>enumerated by the SPIR_V_EXTENSIONS_ARB query?.
>
>RESOLVED. Yes. It's good to include it for consistency. Any SPIR-V
>functionality supported beyond the SPIR-V version that is required
>for the GL API version should be enumerated."
>
> Reading between lines, there is the possibility of specific GL
> extensions enabling specific SPIR-V extensions (so capabilities). That
> would mean that it is possible that OpenGL and Vulkan not having the
> same capabilities supported, even for the same driver. So for now we
> keep them separate. Perhaps in the future it is better to keep them
> the same and synced.
>
> Note: we initialize SPIR-V capabilities at brwCreateContext instead of
> the usual brw_initialize_context_constants because we want to do that
> only for version >= 3.3. At brw_initialize_context_constans GL version
> is still not computed.
>
> v2:
>* Rebase update (SpirVCapabilities not a pointer anymore)
>* Fill spirv capabilities for OpenGL >= 3.3 (Ian Romanick)
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index fca5c8e3072..abd1592c0f5 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -78,6 +78,7 @@
>  
>  #include "common/gen_defines.h"
>  
> +#include "compiler/spirv/nir_spirv.h"
>  /***
>   * Mesa's Driver Functions
>   ***/
> @@ -343,6 +344,21 @@ brw_init_driver_functions(struct brw_context *brw,
>brw_deserialize_program_binary;
>  }
>  
> +static void
> +brw_initialize_spirv_supported_capabilities(struct brw_context *brw)
> +{
> +   const struct gen_device_info *devinfo = >screen->devinfo;
> +   struct gl_context *ctx = >ctx;
> +
> +   ctx->Const.SpirVCapabilities.float64 = devinfo->gen >= 8;
> +   ctx->Const.SpirVCapabilities.int64 = devinfo->gen >= 8;
> +   ctx->Const.SpirVCapabilities.tessellation = true;
> +   ctx->Const.SpirVCapabilities.draw_parameters = true;
> +   ctx->Const.SpirVCapabilities.image_write_without_format = true;
> +   ctx->Const.SpirVCapabilities.multiview = true;
> +   ctx->Const.SpirVCapabilities.variable_pointers = true;
> +}
> +
>  static void
>  brw_initialize_context_constants(struct brw_context *brw)
>  {
> @@ -1063,6 +1079,10 @@ brwCreateContext(gl_api api,
> _mesa_override_extensions(ctx);
> _mesa_compute_version(ctx);
>  
> +   /* GL_ARB_gl_spirv */
> +   if (ctx->Version >= 33)
> +  brw_initialize_spirv_supported_capabilities(brw);
> +
> _mesa_initialize_dispatch_tables(ctx);
> _mesa_initialize_vbo_vtxfmt(ctx);
>  

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

Re: [Mesa-dev] [PATCH] mesa/st/tests: Use tgsi opcode enum also in the test classes

[Brian Paul]

Reviewed-by: Brian Paul 

Sorry for the breakage.

-Brian

On 03/26/2018 02:17 AM, Gert Wollny wrote:

Fixes: ec478cf9c31c3775a21cd7b5b4b5cdd9263bde9e
 st/mesa,tgsi: use enum tgsi_opcode
Bugzilla: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105737=DwIBAg=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=lq2W5BZEbroPgPpeg6LQhQDMza_vdl8IYWN8cSDPsBw=RbSoaOlqbBS4Vq039rA2vIel6dkwOkK7V2OhXuLlPdI=
Signed-off-by: Gert Wollny 
---
  src/mesa/state_tracker/tests/st_tests_common.cpp |  6 +++---
  src/mesa/state_tracker/tests/st_tests_common.h   | 10 +-
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/tests/st_tests_common.cpp 
b/src/mesa/state_tracker/tests/st_tests_common.cpp
index ea01ca..63e3d6b2c4 100644
--- a/src/mesa/state_tracker/tests/st_tests_common.cpp
+++ b/src/mesa/state_tracker/tests/st_tests_common.cpp
@@ -43,7 +43,7 @@ using std::tuple;
  /* Implementation of helper and test classes */
  void *FakeCodeline::mem_ctx = nullptr;
  
-FakeCodeline::FakeCodeline(unsigned _op, const vector& _dst,

+FakeCodeline::FakeCodeline(tgsi_opcode _op, const vector& _dst,
 const vector& _src, const vector&_to):
 op(_op),
 max_temp_id(0)
@@ -59,7 +59,7 @@ FakeCodeline::FakeCodeline(unsigned _op, const vector& 
_dst,
  
  }
  
-FakeCodeline::FakeCodeline(unsigned _op, const vector>& _dst,

+FakeCodeline::FakeCodeline(tgsi_opcode _op, const vector>& _dst,
 const vector>& _src,
 const vector>&_to,
 SWZ with_swizzle):
@@ -84,7 +84,7 @@ FakeCodeline::FakeCodeline(unsigned _op, const 
vector>& _dst,
 });
  }
  
-FakeCodeline::FakeCodeline(unsigned _op, const vector>& _dst,

+FakeCodeline::FakeCodeline(tgsi_opcode _op, const vector>& 
_dst,
 const vector>& _src,
 const vector>&_to, RA 
with_reladdr):
 op(_op),
diff --git a/src/mesa/state_tracker/tests/st_tests_common.h 
b/src/mesa/state_tracker/tests/st_tests_common.h
index 2e18832923..6d855fe581 100644
--- a/src/mesa/state_tracker/tests/st_tests_common.h
+++ b/src/mesa/state_tracker/tests/st_tests_common.h
@@ -40,15 +40,15 @@ struct RA {};
  
  /* A line to describe a TGSI instruction for building mock shaders. */

  struct FakeCodeline {
-   FakeCodeline(unsigned _op): op(_op), max_temp_id(0) {}
-   FakeCodeline(unsigned _op, const std::vector& _dst, const 
std::vector& _src,
+   FakeCodeline(tgsi_opcode _op): op(_op), max_temp_id(0) {}
+   FakeCodeline(tgsi_opcode _op, const std::vector& _dst, const 
std::vector& _src,
  const std::vector&_to);
  
-   FakeCodeline(unsigned _op, const std::vector>& _dst,

+   FakeCodeline(tgsi_opcode _op, const std::vector>& _dst,
  const std::vector>& _src,
  const std::vector>&_to, SWZ 
with_swizzle);
  
-   FakeCodeline(unsigned _op, const std::vector>& _dst,

+   FakeCodeline(tgsi_opcode _op, const std::vector>& 
_dst,
  const std::vector>& _src,
  const std::vector>&_to, RA 
with_reladdr);
  
@@ -78,7 +78,7 @@ private:

 template 
 void read_reg(const st_reg& s);
  
-   unsigned op;

+   tgsi_opcode op;
 std::vector dst;
 std::vector src;
 std::vector tex_offsets;



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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Sergii Romantsov]

Hello, Emil. Thanks for involving.
> Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")

Actually that patch doesn't fix exactly cee9f3890351. Also I wrote earlier
(probably, my e-mails may go into spam :)):
"That issue is present even on mesa 13-0.0 and also solved with similar
type-conversion fix."

On Mon, Mar 26, 2018 at 4:57 PM, Emil Velikov 
wrote:

> On 26 March 2018 at 13:31, Chris Wilson  wrote:
> > Quoting Sergii Romantsov (2018-03-26 13:16:24)
> >> Negative deltas are used to fake a range in a large buffer.
> >> See 900a5c91eeb3
> >> "i965: Use negative relocation deltas to minimise vertex uploads"
> >>
> >> Gen8+ use 48-bit address relocations so need to extend the sign
> >
> > Note that 48-bit relocations were only switched on in
> > commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
> > to save having to backport too far (although the patch is trivial).
> >
> Agreed, one could backport it for older instances, although it seems
> unneeded.
> Please use a simple fixes tag like:
>
> Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
>
> >> to 64-bit return value. Without it we have higher bits zeroed
> >> and missing the negavive values.
> >> Haswell and older use 32-bit deltas so are unaffected by this issue.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> >> Signed-off-by: Sergii Romantsov 
> >> Tested-by: Andriy Khulap 
> >> ---
> >>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> index d824ff2..128da77 100644
> >> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> >> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> >> /* Using the old buffer offset, write in what the right data would
> be, in
> >>  * case the buffer doesn't move and we can short-circuit the
> relocation
> >>  * processing in the kernel
> >> +*
> >> +* Some target_offsets may be negative, so extend the sign to 64
> bits.
> >>  */
> >> -   return entry->offset + target_offset;
> >> +   return entry->offset + (int64_t)((int32_t)target_offset);
> >
> > Although just changing s/uint32_t target_offset/int32_t target_offset/
> > may be cleaner.
>
> Seems like there's plenty of users that opt for unsigned. Might be
> better to address the issue as-is and as a follow-up do a consistent
> to-signed sweep.
> It keeps the fix small and simple, plus avoids a ton of extra warnings
> [for those using -W*sign*] ;-)
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105740] glsl_types.cpp(524): error: a dynamically-initialized local static variable is not allowed inside of a statement expression

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

   Severity|normal  |critical
   Priority|medium  |high

--- Comment #1 from Roland Scheidegger  ---
It's not just intel c++, appveyor also complained.

-- 
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 mesa] gbm: remove never-implemented function

[Eric Engestrom]

I assume this was implemented in a previous version of that commit, but
was removed in the version that actually landed.

Fixes: 8430af5ebe1ee8119e14 "Add support for swrast to the DRM EGL platform"
Cc: Giovanni Campagna 
Cc: Emil Velikov 
Signed-off-by: Eric Engestrom 
---
 src/gbm/gbm-symbols-check | 1 -
 src/gbm/main/gbm.h| 2 --
 2 files changed, 3 deletions(-)

diff --git a/src/gbm/gbm-symbols-check b/src/gbm/gbm-symbols-check
index 5adeadaed07811010d9b..9b1508ede00e7e12c7af 100755
--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check
@@ -40,7 +40,6 @@ gbm_bo_get_user_data
 gbm_bo_destroy
 gbm_surface_create
 gbm_surface_create_with_modifiers
-gbm_surface_needs_lock_front_buffer
 gbm_surface_lock_front_buffer
 gbm_surface_release_buffer
 gbm_surface_has_free_buffers
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 7710e61b1324b8b5fd02..e95f9e34960bd23083a0 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -386,8 +386,6 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
   uint32_t format,
   const uint64_t *modifiers,
   const unsigned int count);
-int
-gbm_surface_needs_lock_front_buffer(struct gbm_surface *surface);
 
 struct gbm_bo *
 gbm_surface_lock_front_buffer(struct gbm_surface *surface);
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH v3] mesa: readpixels add support for GL_HALF_FLOAT

[Lin Johnson]

Ext_color_buffer_half_float is using type GL_HALF_FLOAT
and data_type GL_FLOAT. This fix Android CTS test
android.view.cts.PixelCopyTest
v2: remove commtens of Ext_color_buffer_half_float.
As Ext_color_buffer__float can use type GL_HALF_FLOAT

Reviewed-by:   Palli, Tapani 
Signed-off-by: Lin Johnson 
---
 src/mesa/main/readpix.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 6ce340ddf9bb..4407f13289e2 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -920,6 +920,8 @@ read_pixels_es3_error_check(GLenum format, GLenum type,
case GL_RGBA:
   if (type == GL_FLOAT && data_type == GL_FLOAT)
  return GL_NO_ERROR; /* EXT_color_buffer_float */
+  if (type == GL_HALF_FLOAT && data_type == GL_FLOAT)
+ return GL_NO_ERROR;
   if (type == GL_UNSIGNED_BYTE && data_type == GL_UNSIGNED_NORMALIZED)
  return GL_NO_ERROR;
   if (internalFormat == GL_RGB10_A2 &&
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Emil Velikov]

On 26 March 2018 at 13:31, Chris Wilson  wrote:
> Quoting Sergii Romantsov (2018-03-26 13:16:24)
>> Negative deltas are used to fake a range in a large buffer.
>> See 900a5c91eeb3
>> "i965: Use negative relocation deltas to minimise vertex uploads"
>>
>> Gen8+ use 48-bit address relocations so need to extend the sign
>
> Note that 48-bit relocations were only switched on in
> commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
> to save having to backport too far (although the patch is trivial).
>
Agreed, one could backport it for older instances, although it seems unneeded.
Please use a simple fixes tag like:

Fixes: cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")

>> to 64-bit return value. Without it we have higher bits zeroed
>> and missing the negavive values.
>> Haswell and older use 32-bit deltas so are unaffected by this issue.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
>> Signed-off-by: Sergii Romantsov 
>> Tested-by: Andriy Khulap 
>> ---
>>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
>> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> index d824ff2..128da77 100644
>> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
>> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
>> /* Using the old buffer offset, write in what the right data would be, in
>>  * case the buffer doesn't move and we can short-circuit the relocation
>>  * processing in the kernel
>> +*
>> +* Some target_offsets may be negative, so extend the sign to 64 bits.
>>  */
>> -   return entry->offset + target_offset;
>> +   return entry->offset + (int64_t)((int32_t)target_offset);
>
> Although just changing s/uint32_t target_offset/int32_t target_offset/
> may be cleaner.

Seems like there's plenty of users that opt for unsigned. Might be
better to address the issue as-is and as a follow-up do a consistent
to-signed sweep.
It keeps the fix small and simple, plus avoids a ton of extra warnings
[for those using -W*sign*] ;-)

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

[Mesa-dev] [PATCH v2] mesa: readpixels add support for GL_HALF_FLOAT

[Lin Johnson]

Ext_color_buffer_half_float is using type GL_HALF_FLOAT
and data_type GL_FLOAT. This fix Android CTS test android.view.cts.PixelCopyTest
v2: remove commtens of Ext_color_buffer_half_float. As Ext_color_buffer__float
can use type GL_HALF_FLOAT

Reviewed-by:   Palli, Tapani 
Signed-off-by: Lin Johnson 
---
 src/mesa/main/readpix.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 6ce340ddf9bb..4407f13289e2 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -920,6 +920,8 @@ read_pixels_es3_error_check(GLenum format, GLenum type,
case GL_RGBA:
   if (type == GL_FLOAT && data_type == GL_FLOAT)
  return GL_NO_ERROR; /* EXT_color_buffer_float */
+  if (type == GL_HALF_FLOAT && data_type == GL_FLOAT)
+ return GL_NO_ERROR;
   if (type == GL_UNSIGNED_BYTE && data_type == GL_UNSIGNED_NORMALIZED)
  return GL_NO_ERROR;
   if (internalFormat == GL_RGB10_A2 &&
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Chris Wilson]

Quoting Sergii Romantsov (2018-03-26 14:11:26)
> Hello, Chris. Thank you for reviewing patch.
> Do you mean changing just only emit_reloc() parameter type or all the 
> preceding
> callers too?

If you insist, but you don't have to. int32_t on the parameter is enough
to document and correct the type. Propagating it through to all callers
can be left for another day.
 
> Also, please, explain what you mean about patch cee9f3890351?
> That issue is present even on mesa 13-0.0 and also solved with similar
> type-conversion fix.

Hmm. I was thinking that if we only assigned 32b addresses the wrap
would be ok; but no, it's only ok if the kernel does the relocation.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Emil Velikov]

On 26 March 2018 at 14:08, Tomasz Figa  wrote:
> On Mon, Mar 26, 2018 at 9:45 PM, Robert Foss  
> wrote:
>> Hey,
>>
>> On 03/23/2018 06:21 PM, Emil Velikov wrote:
>>>
>>> On 23 March 2018 at 16:20, Tomasz Figa  wrote:

 On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov 
 wrote:
>
> On 23 March 2018 at 13:15, Tomasz Figa  wrote:
>
>>
>> Perhaps we could try to use drmOpenWithType() [2]. We could have one
>> property that would be passed as "name" argument and another property
>> for "busid" argument. I assume "type" would be always RENDER?
>>
> I would strongly encourage against using the drmOpen* API, it's a DRI1
> remnant.
> It might work in a particular instance, but has a number of serious
> flaws. Some highlights:
>   - using busid works only with PCI devices
>   - open() w/o O_CLOEXEC
>   - when build w/o udev - it creates a node: mkdir, chown(root), chmod,
> mknod
>   - calls back into Xserver/DDX module
>   - last but no least - borderline hacks with massive documentation [1]
> to keep this running.


 I wasn't aware of that. Thanks for pointing this out.

 Still, I think matching by name and/or bus ID would make sense,
 wouldn't it? Perhaps Mesa already has some helpers for that?

>>> Indeed it does make sense. AFAICT there's no such helper - yet no
>>> objections to adding one ;-)
>>
>>
>> So, I guess having one would be helpful.
>> Where should it live, and what should it be built ontop of?
>
> There is some code of similar purpose in src/loader/loader.c, e.g.
> loader_open_device(). Emil, does it sound like a reasonable place?
>
Right, should have mentioned it - src/loader/loader.c is the place
from mesa POV.

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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Sergii Romantsov]

Hello, Chris. Thank you for reviewing patch.
Do you mean changing just only emit_reloc() parameter type or all the
preceding callers too?

Also, please, explain what you mean about patch cee9f3890351?
That issue is present even on mesa 13-0.0 and also solved with similar
type-conversion fix.


Regards, Sergii.

On Mon, Mar 26, 2018 at 3:31 PM, Chris Wilson 
wrote:

> Quoting Sergii Romantsov (2018-03-26 13:16:24)
> > Negative deltas are used to fake a range in a large buffer.
> > See 900a5c91eeb3
> > "i965: Use negative relocation deltas to minimise vertex uploads"
> >
> > Gen8+ use 48-bit address relocations so need to extend the sign
>
> Note that 48-bit relocations were only switched on in
> commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
> to save having to backport too far (although the patch is trivial).
>
> > to 64-bit return value. Without it we have higher bits zeroed
> > and missing the negavive values.
> > Haswell and older use 32-bit deltas so are unaffected by this issue.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> > Signed-off-by: Sergii Romantsov 
> > Tested-by: Andriy Khulap 
> > ---
> >  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index d824ff2..128da77 100644
> > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> > /* Using the old buffer offset, write in what the right data would
> be, in
> >  * case the buffer doesn't move and we can short-circuit the
> relocation
> >  * processing in the kernel
> > +*
> > +* Some target_offsets may be negative, so extend the sign to 64
> bits.
> >  */
> > -   return entry->offset + target_offset;
> > +   return entry->offset + (int64_t)((int32_t)target_offset);
>
> Although just changing s/uint32_t target_offset/int32_t target_offset/
> may be cleaner.
> -Chris
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



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

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

On Mon, Mar 26, 2018 at 9:45 PM, Robert Foss  wrote:
> Hey,
>
> On 03/23/2018 06:21 PM, Emil Velikov wrote:
>>
>> On 23 March 2018 at 16:20, Tomasz Figa  wrote:
>>>
>>> On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov 
>>> wrote:

 On 23 March 2018 at 13:15, Tomasz Figa  wrote:

>
> Perhaps we could try to use drmOpenWithType() [2]. We could have one
> property that would be passed as "name" argument and another property
> for "busid" argument. I assume "type" would be always RENDER?
>
 I would strongly encourage against using the drmOpen* API, it's a DRI1
 remnant.
 It might work in a particular instance, but has a number of serious
 flaws. Some highlights:
   - using busid works only with PCI devices
   - open() w/o O_CLOEXEC
   - when build w/o udev - it creates a node: mkdir, chown(root), chmod,
 mknod
   - calls back into Xserver/DDX module
   - last but no least - borderline hacks with massive documentation [1]
 to keep this running.
>>>
>>>
>>> I wasn't aware of that. Thanks for pointing this out.
>>>
>>> Still, I think matching by name and/or bus ID would make sense,
>>> wouldn't it? Perhaps Mesa already has some helpers for that?
>>>
>> Indeed it does make sense. AFAICT there's no such helper - yet no
>> objections to adding one ;-)
>
>
> So, I guess having one would be helpful.
> Where should it live, and what should it be built ontop of?

There is some code of similar purpose in src/loader/loader.c, e.g.
loader_open_device(). Emil, does it sound like a reasonable place?

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

Re: [Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Robert Foss]

Hey,

On 03/23/2018 06:21 PM, Emil Velikov wrote:

On 23 March 2018 at 16:20, Tomasz Figa  wrote:

On Sat, Mar 24, 2018 at 12:55 AM, Emil Velikov  wrote:

On 23 March 2018 at 13:15, Tomasz Figa  wrote:



Perhaps we could try to use drmOpenWithType() [2]. We could have one
property that would be passed as "name" argument and another property
for "busid" argument. I assume "type" would be always RENDER?


I would strongly encourage against using the drmOpen* API, it's a DRI1 remnant.
It might work in a particular instance, but has a number of serious
flaws. Some highlights:
  - using busid works only with PCI devices
  - open() w/o O_CLOEXEC
  - when build w/o udev - it creates a node: mkdir, chown(root), chmod, mknod
  - calls back into Xserver/DDX module
  - last but no least - borderline hacks with massive documentation [1]
to keep this running.


I wasn't aware of that. Thanks for pointing this out.

Still, I think matching by name and/or bus ID would make sense,
wouldn't it? Perhaps Mesa already has some helpers for that?


Indeed it does make sense. AFAICT there's no such helper - yet no
objections to adding one ;-)


So, I guess having one would be helpful.
Where should it live, and what should it be built ontop of?


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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Chris Wilson]

Quoting Sergii Romantsov (2018-03-26 13:16:24)
> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
> 
> Gen8+ use 48-bit address relocations so need to extend the sign

Note that 48-bit relocations were only switched on in
commit cee9f3890351 ("i965: Allow 48-bit addressing on Gen8+.")
to save having to backport too far (although the patch is trivial).

> to 64-bit return value. Without it we have higher bits zeroed
> and missing the negavive values.
> Haswell and older use 32-bit deltas so are unaffected by this issue.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> Signed-off-by: Sergii Romantsov 
> Tested-by: Andriy Khulap 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index d824ff2..128da77 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> /* Using the old buffer offset, write in what the right data would be, in
>  * case the buffer doesn't move and we can short-circuit the relocation
>  * processing in the kernel
> +*
> +* Some target_offsets may be negative, so extend the sign to 64 bits.
>  */
> -   return entry->offset + target_offset;
> +   return entry->offset + (int64_t)((int32_t)target_offset);

Although just changing s/uint32_t target_offset/int32_t target_offset/
may be cleaner.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Sergii Romantsov]

Hello, Stuart.
Could You, please, test this patch?

On Mon, Mar 26, 2018 at 3:16 PM, Sergii Romantsov <
sergii.romant...@gmail.com> wrote:

> Negative deltas are used to fake a range in a large buffer.
> See 900a5c91eeb3
> "i965: Use negative relocation deltas to minimise vertex uploads"
>
> Gen8+ use 48-bit address relocations so need to extend the sign
> to 64-bit return value. Without it we have higher bits zeroed
> and missing the negavive values.
> Haswell and older use 32-bit deltas so are unaffected by this issue.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
> Signed-off-by: Sergii Romantsov 
> Tested-by: Andriy Khulap 
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index d824ff2..128da77 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
> /* Using the old buffer offset, write in what the right data would be,
> in
>  * case the buffer doesn't move and we can short-circuit the relocation
>  * processing in the kernel
> +*
> +* Some target_offsets may be negative, so extend the sign to 64 bits.
>  */
> -   return entry->offset + target_offset;
> +   return entry->offset + (int64_t)((int32_t)target_offset);
>  }
>
>  uint64_t
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



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

[Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Sergii Romantsov]

Negative deltas are used to fake a range in a large buffer.
See 900a5c91eeb3
"i965: Use negative relocation deltas to minimise vertex uploads"

Gen8+ use 48-bit address relocations so need to extend the sign
to 64-bit return value. Without it we have higher bits zeroed
and missing the negavive values.
Haswell and older use 32-bit deltas so are unaffected by this issue.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101408
Signed-off-by: Sergii Romantsov 
Tested-by: Andriy Khulap 
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index d824ff2..128da77 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -1124,8 +1124,10 @@ emit_reloc(struct intel_batchbuffer *batch,
/* Using the old buffer offset, write in what the right data would be, in
 * case the buffer doesn't move and we can short-circuit the relocation
 * processing in the kernel
+*
+* Some target_offsets may be negative, so extend the sign to 64 bits.
 */
-   return entry->offset + target_offset;
+   return entry->offset + (int64_t)((int32_t)target_offset);
 }
 
 uint64_t
-- 
2.7.4

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

[Mesa-dev] [Bug 105442] Hang when running nine ff lighting shader with radeonsi

[bugzilla-daemon]

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

--- Comment #2 from i...@yahoo.com ---
Can you do a bisect between Mesa-17.2 and Mesa-17.3, using the same LLVM-5.0.1
?

-- 
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] glsl: fix infinite loop caused by bug in loop unrolling pass

[Gert Wollny]

This fixes the bug for me, thanks,

Tested-by: Gert Wollny 

Am Montag, den 26.03.2018, 10:31 +1100 schrieb Timothy Arceri:
> Just checking for 2 jumps is not enough to be sure we can do a
> complex loop unroll. We need to make sure we also have also found
> 2 loop terminators.
> 
> Without this we were attempting to unroll a loop where the second
> jump was nesed inside multiple ifs which loop analysis is unable
> to detect as a terminator. We ended up splicing out the first
> terminator but failed to actually unroll the loop, this resulted
> in the creation of a possible infinite loop.
> 
> Fixes: 646621c66da9 "glsl: make loop unrolling more like the nir
> unrolling path"
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=105670
> ---
>  src/compiler/glsl/loop_unroll.cpp | 2 +-mesa-dev@lists.freedesktop.o
> rg
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/loop_unroll.cpp
> b/src/compiler/glsl/loop_unroll.cpp
> index 6e06a30fb91..f6efe6475a0 100644
> --- a/src/compiler/glsl/loop_unroll.cpp
> +++ b/src/compiler/glsl/loop_unroll.cpp
> @@ -519,7 +519,7 @@ loop_unroll_visitor::visit_leave(ir_loop *ir)
>  * isn't any additional unknown terminators, or any other jumps
> nested
>  * inside futher ifs.
>  */
> -   if (ls->num_loop_jumps != 2)
> +   if (ls->num_loop_jumps != 2 || ls->terminators.length() != 2)
>return visit_continue;
>  
> ir_instruction *first_ir =
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 02/13] mesa/st: glsl_to_tgsi: Split arrays who's elements are only accessed directly

[Gert Wollny]

Array who's elements are only accessed directly are replaced by the
according number of temporary registers. By doing so the otherwise
reserved register range becomes subject to further optimizations like
copy propagation and register merging.

Thanks to the resulting reduced register pressure this patch makes
the piglits

  spec/glsl-1.50/execution -
  variable-indexing/vs-output-array-vec3-index-wr-before-gs
  geometry/max-input-components

pass on r600 (barts) where they would fail before with a "GPR limit exceeded"
error.

v3: * enable this optimization only if the driver requests register merge

v2: * rename method dissolve_arrays to split_arrays
* unify the tracking and remapping methods for src and st registers
* also track access to arrays via reladdr*

Signed-off-by: Gert Wollny 
---
 src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 117 -
 1 file changed, 116 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 9829e32884..a4331a9bc1 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -369,6 +369,7 @@ public:
void copy_propagate(void);
int eliminate_dead_code(void);
 
+   void split_arrays(void);
void merge_two_dsts(void);
void merge_registers(void);
void renumber_registers(void);
@@ -5396,6 +5397,110 @@ glsl_to_tgsi_visitor::merge_two_dsts(void)
}
 }
 
+
+
+/* One-dimensional arrays who's elements are only accessed directly are
+ * replaced by an according set of temporary registers that then can become
+ * subject to further optimization steps like copy propagation and
+ * register merging.
+ */
+
+template 
+void test_indirect_access(const st_reg& reg, bool *has_indirect_access)
+{
+   if (reg.file == PROGRAM_ARRAY) {
+  if (reg.reladdr || reg.reladdr2 || reg.has_index2) {
+ has_indirect_access[reg.array_id] = true;
+ if (reg.reladdr)
+test_indirect_access(*reg.reladdr, has_indirect_access);
+ if (reg.reladdr2)
+test_indirect_access(*reg.reladdr, has_indirect_access);
+  }
+   }
+}
+
+template 
+void remap_array(st_reg& reg, const int *array_remap_info,
+ const bool *has_indirect_access)
+{
+   if (reg.file == PROGRAM_ARRAY) {
+  if (!has_indirect_access[reg.array_id]) {
+ reg.file = PROGRAM_TEMPORARY;
+ reg.index = reg.index + array_remap_info[reg.array_id];
+ reg.array_id = 0;
+  } else {
+ reg.array_id = array_remap_info[reg.array_id];
+  }
+
+  if (reg.reladdr)
+ remap_array(*reg.reladdr, array_remap_info, has_indirect_access);
+
+  if (reg.reladdr2)
+ remap_array(*reg.reladdr2, array_remap_info, has_indirect_access);
+   }
+}
+
+void
+glsl_to_tgsi_visitor::split_arrays(void)
+{
+   if (!next_array)
+  return;
+
+   bool *has_indirect_access = rzalloc_array(mem_ctx, bool, next_array + 1);
+
+   foreach_in_list(glsl_to_tgsi_instruction, inst, >instructions) {
+  for (unsigned j = 0; j < num_inst_src_regs(inst); j++)
+ test_indirect_access(inst->src[j], has_indirect_access);
+
+  for (unsigned j = 0; j < inst->tex_offset_num_offset; j++)
+ test_indirect_access(inst->tex_offsets[j], has_indirect_access);
+
+  for (unsigned j = 0; j < num_inst_dst_regs(inst); j++)
+ test_indirect_access(inst->dst[j], has_indirect_access);
+   }
+
+   unsigned array_offset = 0;
+   unsigned n_remaining_arrays = 0;
+
+   /* Double use: For arrays that get disolved this value will contain
+* the base index of the temporary registers this array is replaced
+* with. For arrays that remain it contains the new array ID.
+*/
+   int *array_remap_info = rzalloc_array(has_indirect_access, int,
+ next_array + 1);
+
+   for (unsigned i = 1; i <= next_array; ++i) {
+  if (!has_indirect_access[i]) {
+ array_remap_info[i] = this->next_temp + array_offset;
+ array_offset += array_sizes[i-1];
+  } else {
+ array_sizes[n_remaining_arrays] = array_sizes[i-1];
+ array_remap_info[i] = ++n_remaining_arrays;
+  }
+   }
+
+   if (next_array !=  n_remaining_arrays) {
+
+  foreach_in_list(glsl_to_tgsi_instruction, inst, >instructions) {
+
+ for (unsigned j = 0; j < num_inst_src_regs(inst); j++)
+remap_array(inst->src[j], array_remap_info, has_indirect_access);
+
+ for (unsigned j = 0; j < inst->tex_offset_num_offset; j++)
+remap_array(inst->tex_offsets[j], array_remap_info, 
has_indirect_access);
+
+ for (unsigned j = 0; j < num_inst_dst_regs(inst); j++) {
+remap_array(inst->dst[j], array_remap_info, has_indirect_access);
+ }
+  }
+   }
+
+   ralloc_free(has_indirect_access);
+
+   this->next_temp += array_offset;
+   next_array = n_remaining_arrays;
+}
+
 /* Merges 

[Mesa-dev] [PATCH v2 08/13] mesa/st/tests: Add tests for array merge helper classes.

[Gert Wollny]

Signed-off-by: Gert Wollny 
---
 src/mesa/state_tracker/tests/Makefile.am   |  20 +-
 src/mesa/state_tracker/tests/st_tests_common.h |   7 +-
 .../tests/test_glsl_to_tgsi_array_merge.cpp| 296 +
 3 files changed, 317 insertions(+), 6 deletions(-)
 create mode 100644 
src/mesa/state_tracker/tests/test_glsl_to_tgsi_array_merge.cpp

diff --git a/src/mesa/state_tracker/tests/Makefile.am 
b/src/mesa/state_tracker/tests/Makefile.am
index cbb7447ee2..160f85a8bf 100644
--- a/src/mesa/state_tracker/tests/Makefile.am
+++ b/src/mesa/state_tracker/tests/Makefile.am
@@ -17,8 +17,10 @@ AM_CPPFLAGS = \
 
 if HAVE_STD_CXX11
 if HAVE_SHARED_GLAPI
-TESTS = st-renumerate-test
-check_PROGRAMS = st-renumerate-test
+TESTS = st-renumerate-test \
+   st-array-merge-test
+check_PROGRAMS = st-renumerate-test \
+   st-array-merge-test
 
 check_LIBRARIES = libmesa-st-tests-common.a
 endif
@@ -34,7 +36,13 @@ st_renumerate_test_SOURCES = \
 st_renumerate_test_LDFLAGS = \
$(LLVM_LDFLAGS)
 
-st_renumerate_test_LDADD = \
+st_array_merge_test_SOURCES = \
+   test_glsl_to_tgsi_array_merge.cpp
+
+st_array_merge_test_LDFLAGS = \
+   $(LLVM_LDFLAGS)
+
+st_common_LDADD = \
libmesa-st-tests-common.a \
$(top_builddir)/src/mesa/libmesagallium.la \
$(top_builddir)/src/mapi/shared-glapi/libglapi.la \
@@ -43,3 +51,9 @@ st_renumerate_test_LDADD = \
$(top_builddir)/src/gtest/libgtest.la \
$(GALLIUM_COMMON_LIB_DEPS) \
$(LLVM_LIBS)
+
+st_renumerate_test_LDADD = \
+   $(st_common_LDADD)
+
+st_array_merge_test_LDADD = \
+   $(st_common_LDADD)
diff --git a/src/mesa/state_tracker/tests/st_tests_common.h 
b/src/mesa/state_tracker/tests/st_tests_common.h
index 03baf50753..a4fe65947e 100644
--- a/src/mesa/state_tracker/tests/st_tests_common.h
+++ b/src/mesa/state_tracker/tests/st_tests_common.h
@@ -24,14 +24,15 @@
 #ifndef mesa_st_tests_h
 #define mesa_st_tests_h
 
-#include 
-#include 
+#include "state_tracker/st_glsl_to_tgsi_temprename.h"
+#include "state_tracker/st_glsl_to_tgsi_array_merge.h"
+#include "gtest/gtest.h"
+
 #include 
 
 #define MP(X, W) std::make_pair(X, W)
 #define MT(X,Y,Z) std::make_tuple(X,Y,Z)
 
-
 /* Use this to make the compiler pick the swizzle constructor below */
 struct SWZ {};
 
diff --git a/src/mesa/state_tracker/tests/test_glsl_to_tgsi_array_merge.cpp 
b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_array_merge.cpp
new file mode 100644
index 00..d8a5e7fbd1
--- /dev/null
+++ b/src/mesa/state_tracker/tests/test_glsl_to_tgsi_array_merge.cpp
@@ -0,0 +1,296 @@
+/*
+ * Copyright © 2017 Gert Wollny
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+
+#include "st_tests_common.h"
+
+#include "tgsi/tgsi_ureg.h"
+#include "tgsi/tgsi_info.h"
+#include "mesa/program/prog_instruction.h"
+#include "gtest/gtest.h"
+
+#include 
+#include 
+#include 
+
+using std::vector;
+
+using namespace tgsi_array_merge;
+using SwizzleRemapTest=testing::Test;
+
+TEST_F(SwizzleRemapTest, ArrayRemappingBase_x_x)
+{
+   array_remapping map1(10, 1, 1);
+   ASSERT_EQ(map1.target_array_id(), 10u);
+   ASSERT_EQ(map1.map_writemask(1), 2);
+   ASSERT_EQ(map1.map_one_swizzle(0), 1);
+   ASSERT_EQ(map1.combined_access_mask(), 3);
+}
+
+TEST_F(SwizzleRemapTest, ArrayRemappingBase_xy_x)
+{
+   array_remapping map1(5, 3, 1);
+   ASSERT_EQ(map1.target_array_id(), 5u);
+   ASSERT_EQ(map1.map_writemask(1), 4);
+   ASSERT_EQ(map1.map_one_swizzle(0), 2);
+   ASSERT_EQ(map1.combined_access_mask(), 0x7);
+}
+
+TEST_F(SwizzleRemapTest, ArrayRemappingBase_no_reswizzle)
+{
+   array_remapping map1(5, 3);
+   ASSERT_EQ(map1.target_array_id(), 5u);
+   for (int i = 1; i < 16; ++i)
+  ASSERT_EQ(map1.map_writemask(i), i);
+
+   for (int i = 0; i < 4; ++i)
+  ASSERT_EQ(map1.map_one_swizzle(i), i);
+}
+
+TEST_F(SwizzleRemapTest, 

[Mesa-dev] [PATCH v2 11/13] mesa/st/glsl_to_tgsi: add class for array access tracking

[Gert Wollny]

Signed-off-by: Gert Wollny 
---
 .../state_tracker/st_glsl_to_tgsi_temprename.cpp   | 102 +
 1 file changed, 102 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
index b6e87e9a02..00c7155e14 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
@@ -22,6 +22,7 @@
  */
 
 #include "st_glsl_to_tgsi_temprename.h"
+#include "st_glsl_to_tgsi_array_merge.h"
 #include "tgsi/tgsi_info.h"
 #include "tgsi/tgsi_strings.h"
 #include "program/prog_instruction.h"
@@ -239,6 +240,27 @@ private:
bool needs_component_tracking;
 };
 
+/* Class to track array access.
+ * Compared to the temporary tracking this is very simplified, mainly because
+ * with the likely indirect access one can not really establish access
+ * patterns for individual elements. Instead the life range evaluation is
+ * always for the whole array, handles only loops and the fact whether a
+ * value was accessed conditionally in a loop.
+ */
+class array_access {
+public:
+   array_access();
+   void record_access(int line, prog_scope *scope, int swizzle);
+   void get_required_live_range(array_live_range );
+private:
+   int first_access;
+   int last_access;
+   prog_scope *first_access_scope;
+   prog_scope *last_access_scope;
+   unsigned accumulated_swizzle:4;
+   int conditional_access_in_loop:1;
+};
+
 prog_scope_storage::prog_scope_storage(void *mc, int n):
mem_ctx(mc),
current_slot(0)
@@ -508,6 +530,86 @@ void temp_access::record_read(int line, prog_scope *scope, 
int readmask)
   comp[3].record_read(line, scope);
 }
 
+array_access::array_access():
+   first_access(-1),
+   last_access(-1),
+   first_access_scope(nullptr),
+   last_access_scope(nullptr),
+   accumulated_swizzle(0),
+   conditional_access_in_loop(false)
+{
+}
+
+void array_access::record_access(int line, prog_scope *scope, int swizzle)
+{
+   if (!first_access_scope) {
+  first_access = line;
+  first_access_scope = scope;
+   }
+   last_access_scope = scope;
+   last_access = line;
+   accumulated_swizzle |= swizzle;
+   if (scope->in_ifelse_scope() && scope->innermost_loop())
+  conditional_access_in_loop = true;
+}
+
+void array_access::get_required_live_range(array_live_range& lr)
+{
+   RENAME_DEBUG(debug_log << "first_access_scope=" << first_access_scope << 
"\n");
+   RENAME_DEBUG(debug_log << "last_access_scope=" << last_access_scope << 
"\n");
+
+   if (first_access_scope == last_access_scope) {
+  lr.set_live_range(first_access, last_access);
+  lr.set_access_mask(accumulated_swizzle);
+  return;
+   }
+
+   const prog_scope *shared_scope = first_access_scope;
+   const prog_scope *other_scope = last_access_scope;
+
+   assert(shared_scope);
+   RENAME_DEBUG(debug_log << "shared_scope=" << shared_scope << "\n");
+
+   if (conditional_access_in_loop) {
+  const prog_scope *help = shared_scope->outermost_loop();
+  if (help) {
+ shared_scope = help;
+  } else {
+ help = other_scope->outermost_loop();
+ if (help)
+other_scope = help;
+  }
+  if (first_access > shared_scope->begin())
+ first_access = shared_scope->begin();
+  if (last_access < shared_scope->end())
+ last_access = shared_scope->end();
+   }
+
+   /* See if any of the two is the parent of the other. */
+   if (other_scope->contains_range_of(*shared_scope)) {
+  shared_scope = other_scope;
+   } else while (!shared_scope->contains_range_of(*other_scope)) {
+  assert(shared_scope->parent());
+  if (shared_scope->type() == loop_body) {
+ if (last_access < shared_scope->end())
+ last_access = shared_scope->end();
+  }
+  shared_scope = shared_scope->parent();
+   }
+
+   while (shared_scope != other_scope) {
+  if (other_scope->type() == loop_body) {
+ if (last_access < other_scope->end())
+ last_access = other_scope->end();
+  }
+  other_scope = other_scope->parent();
+   }
+
+   lr.set_live_range(first_access, last_access);
+   lr.set_access_mask(accumulated_swizzle);
+}
+
+
 inline static register_live_range make_live_range(int b, int e)
 {
register_live_range lt;
-- 
2.16.1

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

[Mesa-dev] [PATCH v2 12/13] mesa/st/glsl_to_tgsi: add array life range evaluation into tracking code

[Gert Wollny]

Signed-off-by: Gert Wollny 
---
 .../state_tracker/st_glsl_to_tgsi_temprename.cpp   | 61 +-
 1 file changed, 49 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
index 00c7155e14..bc63bfc1cd 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_temprename.cpp
@@ -1009,28 +1009,34 @@ public:
 
 class access_recorder {
 public:
-   access_recorder(int _ntemps);
+   access_recorder(int _ntemps, int _narrays);
~access_recorder();
 
void record_read(const st_src_reg& src, int line, prog_scope *scope);
-   void record_write(const st_dst_reg& src, int line, prog_scope *scope);
+   void record_write(const st_dst_reg& src, int line, prog_scope *scope,
+ bool no_reswizzle);
 
-   void get_required_live_ranges(register_live_range *register_live_ranges);
+   void get_required_live_ranges(register_live_range *register_live_ranges,
+ array_live_range *array_live_ranges);
 private:
 
int ntemps;
+   int narrays;
temp_access *temp_acc;
-
+   array_access *array_acc;
 };
 
-access_recorder::access_recorder(int _ntemps):
-   ntemps(_ntemps)
+access_recorder::access_recorder(int _ntemps, int _narrays):
+   ntemps(_ntemps),
+   narrays(_narrays)
 {
temp_acc = new temp_access[ntemps];
+   array_acc = new array_access[narrays];
 }
 
 access_recorder::~access_recorder()
 {
+   delete[] array_acc;
delete[] temp_acc;
 }
 
@@ -1046,6 +1052,11 @@ void access_recorder::record_read(const st_src_reg& src, 
int line,
if (src.file == PROGRAM_TEMPORARY)
   temp_acc[src.index].record_read(line, scope, readmask);
 
+   if (src.file == PROGRAM_ARRAY) {
+  assert(src.array_id <= narrays);
+  array_acc[src.array_id - 1].record_access(line, scope, readmask);
+   }
+
if (src.reladdr)
   record_read(*src.reladdr, line, scope);
if (src.reladdr2)
@@ -1053,18 +1064,30 @@ void access_recorder::record_read(const st_src_reg& 
src, int line,
 }
 
 void access_recorder::record_write(const st_dst_reg& dst, int line,
-   prog_scope *scope)
+   prog_scope *scope, bool can_reswizzle)
 {
if (dst.file == PROGRAM_TEMPORARY)
   temp_acc[dst.index].record_write(line, scope, dst.writemask);
 
+   if (dst.file == PROGRAM_ARRAY) {
+  assert(dst.array_id <= narrays);
+
+  /* If the array is written as dst of a multi-dst operation, we must not
+   * reswizzle the access, because we would have to reswizzle also the
+   * other dst. For now just fill the mask to make interleaving impossible.
+   */
+  array_acc[dst.array_id - 1].record_access(line, scope,
+can_reswizzle ? dst.writemask: 
0xF);
+   }
+
if (dst.reladdr)
   record_read(*dst.reladdr, line, scope);
if (dst.reladdr2)
   record_read(*dst.reladdr2, line, scope);
 }
 
-void access_recorder::get_required_live_ranges(struct register_live_range 
*register_live_ranges)
+void access_recorder::get_required_live_ranges(struct register_live_range 
*register_live_ranges,
+   struct array_live_range 
*array_live_ranges)
 {
RENAME_DEBUG(debug_log << "== register live ranges ==\n");
for(int i = 0; i < ntemps; ++i) {
@@ -1074,6 +1097,15 @@ void access_recorder::get_required_live_ranges(struct 
register_live_range *regis
 <

[Mesa-dev] [PATCH v2 06/13] mesa/st/glsl_to_tgsi: Add class to track array live range

[Gert Wollny]

todo explain

Signed-off-by: Gert Wollny 
---
 .../state_tracker/st_glsl_to_tgsi_array_merge.cpp  | 69 ++
 .../state_tracker/st_glsl_to_tgsi_array_merge.h| 46 +++
 2 files changed, 115 insertions(+)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
index 52d0d81796..89b9bf66d4 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
@@ -37,6 +37,75 @@ using std::unique_ptr;
 using std::make_unique;
 #endif
 
+
+array_live_range::array_live_range():
+   id(0),
+   length(0),
+   first_access(0),
+   last_access(0),
+   component_access_mask(0),
+   used_component_count(0)
+{
+}
+
+array_live_range::array_live_range(unsigned aid, unsigned alength):
+   id(aid),
+   length(alength),
+   first_access(0),
+   last_access(0),
+   component_access_mask(0),
+   used_component_count(0)
+{
+}
+
+array_live_range::array_live_range(unsigned aid, unsigned alength, int begin,
+   int end, int sw):
+   id(aid),
+   length(alength),
+   first_access(begin),
+   last_access(end),
+   component_access_mask(sw),
+   used_component_count(util_bitcount(sw))
+{
+}
+
+void array_live_range::set_live_range(int _begin, int _end)
+{
+   set_begin(_begin);
+   set_end(_end);
+}
+
+void array_live_range::set_access_mask(int mask)
+{
+   component_access_mask = mask;
+   used_component_count = util_bitcount(mask);
+}
+
+void array_live_range::merge_live_range(const array_live_range )
+{
+   if (other.begin() < first_access)
+  first_access = other.begin();
+   if (other.end() > last_access)
+  last_access = other.end();
+}
+
+void array_live_range::print(std::ostream& os) const
+{
+   os << "[id:" << id
+  << ", length:" << length
+  << ", (b:" << first_access
+  << ", e:" << last_access
+  << "), sw:" << component_access_mask
+  << ", nc:" << used_component_count
+  << "]";
+}
+
+bool array_live_range::time_doesnt_overlap(const array_live_range& other) const
+{
+   return (other.last_access < first_access ||
+   last_access < other.first_access);
+}
+
 namespace tgsi_array_merge {
 
 array_remapping::array_remapping():
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.h 
b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.h
index c74c854e09..b9fb498e69 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.h
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.h
@@ -27,6 +27,52 @@
 #include "st_glsl_to_tgsi_private.h"
 #include 
 
+/* Helper class to evaluate the required live range of an array.
+ *
+ * For arrays not only the live range must be tracked, but also the arrays
+ * length and since we want to interleave arrays, we also track an access mask.
+ * Consequently, one array can be merged into another or interleaved with
+ * another only if the target array is longer.
+ */
+class array_live_range {
+public:
+   array_live_range();
+   array_live_range(unsigned aid, unsigned alength);
+   array_live_range(unsigned aid, unsigned alength, int first_access,
+  int last_access, int mask);
+
+   void set_live_range(int first_access, int last_access);
+   void set_begin(int _begin){first_access = _begin;}
+   void set_end(int _end){last_access = _end;}
+   void set_access_mask(int s);
+   void merge_live_range(const array_live_range& other);
+
+   unsigned array_id() const {return id;}
+   int array_length() const { return length;}
+   int begin() const { return first_access;}
+   int end() const { return last_access;}
+   int access_mask() const { return component_access_mask;}
+   int used_components() const {return used_component_count;}
+
+   bool time_doesnt_overlap(const array_live_range& other) const;
+
+   void print(std::ostream& os) const;
+
+private:
+   unsigned id;
+   unsigned length;
+   int first_access;
+   int last_access;
+   int component_access_mask;
+   int used_component_count;
+};
+
+inline
+std::ostream& operator << (std::ostream& os, const array_live_range& lt) {
+   lt.print(os);
+   return os;
+}
+
 namespace tgsi_array_merge {
 
 /* Helper class to merge and interleave arrays.
-- 
2.16.1

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

[Mesa-dev] [PATCH v2 07/13] mesa/st/glsl_to_tgsi:Add array merge logic

[Gert Wollny]

Signed-off-by: Gert Wollny 
---
 .../state_tracker/st_glsl_to_tgsi_array_merge.cpp  | 389 -
 .../state_tracker/st_glsl_to_tgsi_array_merge.h|  26 +-
 2 files changed, 413 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
index 89b9bf66d4..1e8aca99a2 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi_array_merge.cpp
@@ -21,6 +21,109 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+/* A short overview on how the array merging works:
+ *
+ * Inputs:
+ *   - per array information: live range, access mask, size
+ *   - the program
+ *
+ * Output:
+ *   - the program with updated array addressing
+ *
+ * Pseudo algorithm:
+ *
+ * repeat
+ *for all pairs of arrays:
+ *   if they have non-overlapping live ranges and equal access masks:
+ *  - pick shorter array
+ *  - merge its live range into the longer array
+ *  - set its merge target array to the longer array
+ *  - mark the shorter array as processed
+ *
+ *for all pairs of arrays:
+ *   if they have overlapping live ranges use in sum at most four 
components:
+ *  - pick shorter array
+ *  - evaluate reswizzle map to move its components into the components
+ *that are not used by the longer array
+ *  - set its merge target array to the longer array
+ *  - mark the shorter array as processed
+ *  - bail out loop
+ *  until no more successfull merges were found
+ *
+ *  for all pairs of arrays:
+ * if they have non-overlapping live ranges:
+ *  - pick shorter array
+ *  - merge its live range into the longer array
+ *  - set its merge target array to the longer array
+ *  - mark the shorter array as processed
+ *
+ * Finalize remapping map so that target arrays are always final, i.e. have
+ * themselfes no merge target set.
+ *
+ * Example:
+ *   ID  | Length | Live range | access mask | target id | reswizzle
+ *   
+ *   1   3   3-10  x___0
+ *   2   4  13-20  x___0
+ *   3   8   3-20  x___0
+ *   4   6  21-40  xy__0
+ *   5   7  12-30  xy__0
+ *
+ * 1. merge live ranges 1 and 2
+ *
+ *   ID  | Length | Live range | access mask | target id | reswizzle
+ *   
+ *   1   --x___2
+ *   2   4   3-20  x___0
+ *   3   8   3-20  x___0
+ *   4   6  21-40  xy__0
+ *   5   7  12-30  xy__0
+ *
+ *
+ *  3. interleave 2 and 3
+ *
+ *   ID  | Length | Live range | access mask | target id | reswizzle
+ *   
+ *   1   --x___2
+ *   2   --x___3_x__
+ *   3   8   3-20  xy__0
+ *   4   6  21-40  xy__0
+ *   5   7  12-30  xy__0
+ *
+ *   3. merge live ranges 3 and 4
+ *
+ *   ID  | Length | Live range | access mask | target id | reswizzle
+ *   
+ *   1   --x___2
+ *   2   --x___3_x__
+ *   3   8   3-40  xy__0
+ *   4   --xy__3
+ *   5   7   3-21  xy__0
+ *
+ *   4. interleave 3 and 5
+ *
+ *   ID  | Length | Live range | access mask | target id | reswizzle
+ *   
+ *   1   --x___2
+ *   2   --x___3_x__
+ *   3   8   3-40  xy__0
+ *   4   --xy__3
+ *   5   --xy__3__xy
+ *
+ *   5. finalize remapping
+ *   (Array 1 has been merged with 2 that was later interleaved, so
+ *   the reswizzeling must be propagated.
+ *
+ *   ID  | Length | Live range | new access mask | target id | reswizzle
+ *   
+ *   1   --   _y__3_x__
+ *   2   --   _y__3