[Mesa-dev] [PATCH] mesa: remove remaining tabs in api_validate.c

[Timothy Arceri]

---
 src/mesa/main/api_validate.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
index c7625c3..4ef86b8 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/api_validate.c
@@ -54,7 +54,7 @@ check_valid_to_render(struct gl_context *ctx, const char 
*function)
   /* For OpenGL ES, only draw if we have vertex positions
*/
   if (!ctx->Array.VAO->VertexAttrib[VERT_ATTRIB_POS].Enabled)
-return false;
+ return false;
   break;
 
case API_OPENGL_CORE:
@@ -346,10 +346,10 @@ _mesa_valid_prim_mode(struct gl_context *ctx, GLenum 
mode, const char *name)
   }
   if (!pass) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
-"%s(mode=%s vs transform feedback %s)",
-name,
-_mesa_lookup_prim_by_nr(mode),
-_mesa_lookup_prim_by_nr(ctx->TransformFeedback.Mode));
+ "%s(mode=%s vs transform feedback %s)",
+ name,
+ _mesa_lookup_prim_by_nr(mode),
+ _mesa_lookup_prim_by_nr(ctx->TransformFeedback.Mode));
  return GL_FALSE;
   }
}
@@ -431,8 +431,8 @@ validate_DrawElements_common(struct gl_context *ctx,
  */
 GLboolean
 _mesa_validate_DrawElements(struct gl_context *ctx,
-   GLenum mode, GLsizei count, GLenum type,
-   const GLvoid *indices)
+GLenum mode, GLsizei count, GLenum type,
+const GLvoid *indices)
 {
FLUSH_CURRENT(ctx, 0);
 
@@ -494,9 +494,9 @@ _mesa_validate_MultiDrawElements(struct gl_context *ctx,
  */
 GLboolean
 _mesa_validate_DrawRangeElements(struct gl_context *ctx, GLenum mode,
-GLuint start, GLuint end,
-GLsizei count, GLenum type,
-const GLvoid *indices)
+ GLuint start, GLuint end,
+ GLsizei count, GLenum type,
+ const GLvoid *indices)
 {
FLUSH_CURRENT(ctx, 0);
 
@@ -580,7 +580,7 @@ _mesa_validate_DrawArraysInstanced(struct gl_context *ctx, 
GLenum mode, GLint fi
 
if (first < 0) {
   _mesa_error(ctx, GL_INVALID_VALUE,
- "glDrawArraysInstanced(start=%d)", first);
+  "glDrawArraysInstanced(start=%d)", first);
   return GL_FALSE;
}
 
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH 2/2] i965: Support "unlimited" compute shader scratch space.

[Kenneth Graunke]

On Thursday, June 16, 2016 8:16:43 PM PDT Ian Romanick wrote:
> How well tested is this?  I suspect nothing hits the 2Mb limit, but do
> we have any tests or apps that even hit the 12k limit?

I forgot to update the commit message to include the info from the bug:

"Fixes Piglit's spec/arb_compute_shader/linker/bug-93840 on Ivybridge GT1
 and Baytrail."

That Piglit test hits the 12k limit on IVB GT1 and Baytrail, which have
to use SIMD32 mode.  (IVB GT2 has enough threads that it can get away
with SIMD16 mode and doesn't spill as much.)

I believe I tried clamping the 2MB limit to something smaller so that it
would actually hit this code, and it worked.

--Ken


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

Re: [Mesa-dev] [PATCH 1/2] i965: Reorganize prog_data->total_scratch code a bit.

[Ian Romanick]

I like this organization much better.  This patch is

Reviewed-by: Ian Romanick 

On 06/16/2016 07:58 PM, Kenneth Graunke wrote:
> Cc: "12.0" 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 35 +++
>  1 file changed, 19 insertions(+), 16 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 8774f25..cadf905 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -5973,23 +5973,26 @@ fs_visitor::allocate_registers(bool allow_spilling)
> schedule_instructions(SCHEDULE_POST);
>  
> if (last_scratch > 0) {
> -  prog_data->total_scratch = brw_get_scratch_size(last_scratch);
> +  unsigned max_scratch_size = 2 * 1024 * 1024;
>  
> -  if (devinfo->is_haswell && stage == MESA_SHADER_COMPUTE) {
> - /* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
> -  * field documentation, Haswell supports a minimum of 2kB of
> -  * scratch space for compute shaders, unlike every other stage
> -  * and platform.
> -  */
> - prog_data->total_scratch = MAX2(prog_data->total_scratch, 2048);
> -  } else if (devinfo->gen <= 7 && stage == MESA_SHADER_COMPUTE) {
> - /* According to the MEDIAVFE_STATE's "Per Thread Scratch Space"
> -  * field documentation, platforms prior to Haswell measure scratch
> -  * size linearly with a range of [1kB, 12kB] and 1kB granularity.
> -  */
> - prog_data->total_scratch = ALIGN(last_scratch, 1024);
> +  prog_data->total_scratch = brw_get_scratch_size(last_scratch);
>  
> - assert(prog_data->total_scratch < 12 * 1024);
> +  if (stage == MESA_SHADER_COMPUTE) {
> + if (devinfo->is_haswell) {
> +/* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
> + * field documentation, Haswell supports a minimum of 2kB of
> + * scratch space for compute shaders, unlike every other stage
> + * and platform.
> + */
> +prog_data->total_scratch = MAX2(prog_data->total_scratch, 2048);
> + } else if (devinfo->gen <= 7) {
> +/* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
> + * field documentation, platforms prior to Haswell measure 
> scratch
> + * size linearly with a range of [1kB, 12kB] and 1kB granularity.
> + */
> +prog_data->total_scratch = ALIGN(last_scratch, 1024);
> +max_scratch_size = 12 * 1024;
> + }
>}
>  
>/* We currently only support up to 2MB of scratch space.  If we
> @@ -6002,7 +6005,7 @@ fs_visitor::allocate_registers(bool allow_spilling)
> * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
> * Thread Group Tracking > Local Memory/Scratch Space.
> */
> -  assert(prog_data->total_scratch < 2 * 1024 * 1024);
> +  assert(prog_data->total_scratch < max_scratch_size);
> }
>  }
>  
> 

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

Re: [Mesa-dev] [PATCH 2/2] i965: Support "unlimited" compute shader scratch space.

[Ian Romanick]

How well tested is this?  I suspect nothing hits the 2Mb limit, but do
we have any tests or apps that even hit the 12k limit?

On 06/16/2016 07:58 PM, Kenneth Graunke wrote:
> Ivybridge and Baytrail have a pretty harsh limit of 12kB scratch space
> per thread.  However, we can exceed this limit with some clever tricks
> and gain effectively unlimited scratch space.
> 
> Later platforms have a 2MB limit, which is much more reasonable, but
> we may as well apply the same trick there.
> 
> We can probably extend this trick to other stages, but would need to
> adjust the shader code for the different thread payload layouts.
> 
> Cc: "12.0" 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96505
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp  | 50 
> +++
>  src/mesa/drivers/dri/i965/gen7_cs_state.c |  6 ++--
>  2 files changed, 41 insertions(+), 15 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index cadf905..9075918 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -5993,19 +5993,45 @@ fs_visitor::allocate_registers(bool allow_spilling)
>  prog_data->total_scratch = ALIGN(last_scratch, 1024);
>  max_scratch_size = 12 * 1024;
>   }
> -  }
>  
> -  /* We currently only support up to 2MB of scratch space.  If we
> -   * need to support more eventually, the documentation suggests
> -   * that we could allocate a larger buffer, and partition it out
> -   * ourselves.  We'd just have to undo the hardware's address
> -   * calculation by subtracting (FFTID * Per Thread Scratch Space)
> -   * and then add FFTID * (Larger Per Thread Scratch Space).
> -   *
> -   * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
> -   * Thread Group Tracking > Local Memory/Scratch Space.
> -   */
> -  assert(prog_data->total_scratch < max_scratch_size);
> + if (prog_data->total_scratch >= max_scratch_size) {
> +/* Normally, the hardware computes a pointer to the scratch
> + * space region for our thread for us.  This comes with a
> + * limitation - each thread can only use a limited amount
> + * of scratch space.  To support more than that limit, we
> + * can subtract the hardware's offset and add our own:
> + *
> + * Scratch Space Pointer +=
> + *FFTID * (prog_data->total_scratch - max_scratch_size);
> + *
> + * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
> + * Thread Group Tracking > Local Memory/Scratch Space.
> + */
> +const fs_builder bld =
> +   fs_builder(this, cfg->blocks[0], (fs_inst *)
> +  cfg->blocks[0]->start()).exec_all();
> +struct brw_reg g0_5 =
> +   retype(brw_vec1_grf(0, 5), BRW_REGISTER_TYPE_D);
> +struct brw_reg g127 =
> +   retype(brw_vec1_grf(127, 0), BRW_REGISTER_TYPE_D);
> +
> +/* Multiply FFTID by max_scratch_size and shift the result
> + * left by 10.  Then subtract that from the scratch pointer.
> + *
> + * We need a register for temporary storage, but can't allocate
> + * one post-register-allocation.  However, since our code will
> + * be emitted at the top of the program, we can safely use g127,
> + * as it isn't part of the thread payload and can't be in use.
> + */
> +bld.AND(g127, g0_5, brw_imm_d(0x3ff));
> +bld.MUL(g127, g127,
> +brw_imm_d(prog_data->total_scratch - max_scratch_size));
> +bld.ADD(g0_5, g0_5, g127);
> + }
> +  } else {
> + /* We should extend the above hack for other stages someday. */
> + assert(prog_data->total_scratch < max_scratch_size);
> +  }
> }
>  }
>  
> diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c 
> b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> index 5fb8829..b89a186 100644
> --- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
> @@ -70,21 +70,21 @@ brw_upload_cs_state(struct brw_context *brw)
>*/
>   OUT_RELOC64(stage_state->scratch_bo,
>   I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
> - ffs(stage_state->per_thread_scratch) - 11);
> + MIN2(ffs(stage_state->per_thread_scratch) - 11, 11));
>} else if (brw->is_haswell) {
>   /* Haswell's Per Thread Scratch Space is in the range [0, 10]
>* where 0 = 2k, 1 = 4k, 2 = 8k, ..., 10 = 2M.
>*/
>   OUT_RELOC(stage_state->scratch_bo,
> I915_GEM_DOMAIN_RENDER, 

Re: [Mesa-dev] [PATCH] glcpp: Only expose ARB_enhanced_layouts if it's supported.

[Ian Romanick]

This patch is

Reviewed-by: Ian Romanick 

On 06/16/2016 06:15 PM, Dylan Baker wrote:
> This fixes the following piglit tests:
> spec/arb_enhanced_layouts/preprocessor/disabled-defined-core.*
> 
> Signed-off-by: Dylan Baker 
> ---
>  src/compiler/glsl/glcpp/glcpp-parse.y | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y 
> b/src/compiler/glsl/glcpp/glcpp-parse.y
> index 2cfa6a6..76cba07 100644
> --- a/src/compiler/glsl/glcpp/glcpp-parse.y
> +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
> @@ -2338,12 +2338,14 @@ 
> _glcpp_parser_handle_version_declaration(glcpp_parser_t *parser, intmax_t 
> versio
>}
> } else {
>add_builtin_define(parser, "GL_ARB_draw_buffers", 1);
> -  add_builtin_define(parser, "GL_ARB_enhanced_layouts", 1);
>add_builtin_define(parser, "GL_ARB_separate_shader_objects", 1);
>add_builtin_define(parser, "GL_ARB_texture_rectangle", 1);
>add_builtin_define(parser, "GL_AMD_shader_trinary_minmax", 1);
>  
>if (extensions != NULL) {
> + if (extensions->ARB_enhanced_layouts)
> + add_builtin_define(parser, "GL_ARB_enhanced_layouts", 1);
> +
>   if (extensions->EXT_texture_array)
>  add_builtin_define(parser, "GL_EXT_texture_array", 1);
>  

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

Re: [Mesa-dev] [PATCH v2 04/11] glsl: Pack integer and double varyings as flat even if interpolation mode is none

[Ian Romanick]

On 06/16/2016 12:07 PM, Ian Romanick wrote:
> From: Ian Romanick 
> 
> v2: Also update varying_matches::compute_packing_class().  Suggested by
> Timothy Arceri.
> 
> Signed-off-by: Ian Romanick 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
> Cc: "12.0" 
> Cc: Gregory Hainaut 
> Cc: Ilia Mirkin 
> ---
>  src/compiler/glsl/ir.h  |  7 +++
>  src/compiler/glsl/link_varyings.cpp |  3 ++-
>  src/compiler/glsl/lower_packed_varyings.cpp | 11 ++-
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
> index 3629356..e5b8154 100644
> --- a/src/compiler/glsl/ir.h
> +++ b/src/compiler/glsl/ir.h
> @@ -590,6 +590,13 @@ public:
>return this->u.state_slots;
> }
>  
> +   inline bool is_interpolation_flat() const
> +   {
> +  return this->data.interpolation == INTERP_QUALIFIER_FLAT ||
> + this->type->contains_integer() ||
> + this->type->contains_double();
> +   }
> +
> inline bool is_name_ralloced() const
> {
>return this->name != ir_variable::tmp_name;
> diff --git a/src/compiler/glsl/link_varyings.cpp 
> b/src/compiler/glsl/link_varyings.cpp
> index ef8bdbe..84686ee 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -1610,7 +1610,8 @@ varying_matches::compute_packing_class(const 
> ir_variable *var)
> unsigned packing_class = var->data.centroid | (var->data.sample << 1) |
>  (var->data.patch << 2);
> packing_class *= 4;
> -   packing_class += var->data.interpolation;
> +   packing_class += var->is_interpolation_flat()
> +  ? INTERP_QUALIFIER_FLAT : data.interpolation;

I had fixed the two bugs in this line, but I didn't squash the !fixup
patch before sending this out.  This should obviously be:

   packing_class += var->is_interpolation_flat()
  ? unsigned(INTERP_QUALIFIER_FLAT) : var->data.interpolation;

D'oh!

> return packing_class;
>  }
>  
> diff --git a/src/compiler/glsl/lower_packed_varyings.cpp 
> b/src/compiler/glsl/lower_packed_varyings.cpp
> index 130b8f6..9aa463c 100644
> --- a/src/compiler/glsl/lower_packed_varyings.cpp
> +++ b/src/compiler/glsl/lower_packed_varyings.cpp
> @@ -273,11 +273,11 @@ lower_packed_varyings_visitor::run(struct gl_shader 
> *shader)
>   continue;
>  
>/* This lowering pass is only capable of packing floats and ints
> -   * together when their interpolation mode is "flat".  Therefore, to be
> -   * safe, caller should ensure that integral varyings always use flat
> -   * interpolation, even when this is not required by GLSL.
> +   * together when their interpolation mode is "flat".  Treat integers as
> +   * being flat when the interpolation mode is none.
> */
>assert(var->data.interpolation == INTERP_QUALIFIER_FLAT ||
> + var->data.interpolation == INTERP_QUALIFIER_NONE ||
>   !var->type->contains_integer());
>  
>/* Clone the variable for program resource list before
> @@ -607,7 +607,7 @@ lower_packed_varyings_visitor::get_packed_varying_deref(
> if (this->packed_varyings[slot] == NULL) {
>char *packed_name = ralloc_asprintf(this->mem_ctx, "packed:%s", name);
>const glsl_type *packed_type;
> -  if (unpacked_var->data.interpolation == INTERP_QUALIFIER_FLAT)
> +  if (unpacked_var->is_interpolation_flat())
>   packed_type = glsl_type::ivec4_type;
>else
>   packed_type = glsl_type::vec4_type;
> @@ -627,7 +627,8 @@ lower_packed_varyings_visitor::get_packed_varying_deref(
>packed_var->data.centroid = unpacked_var->data.centroid;
>packed_var->data.sample = unpacked_var->data.sample;
>packed_var->data.patch = unpacked_var->data.patch;
> -  packed_var->data.interpolation = unpacked_var->data.interpolation;
> +  packed_var->data.interpolation = packed_type == glsl_type::ivec4_type
> + ? unsigned(INTERP_QUALIFIER_FLAT) : 
> unpacked_var->data.interpolation;
>packed_var->data.location = location;
>packed_var->data.precision = unpacked_var->data.precision;
>packed_var->data.always_active_io = 
> unpacked_var->data.always_active_io;
> 

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

[Mesa-dev] [PATCH 1/2] i965: Reorganize prog_data->total_scratch code a bit.

[Kenneth Graunke]

Cc: "12.0" 
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8774f25..cadf905 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -5973,23 +5973,26 @@ fs_visitor::allocate_registers(bool allow_spilling)
schedule_instructions(SCHEDULE_POST);
 
if (last_scratch > 0) {
-  prog_data->total_scratch = brw_get_scratch_size(last_scratch);
+  unsigned max_scratch_size = 2 * 1024 * 1024;
 
-  if (devinfo->is_haswell && stage == MESA_SHADER_COMPUTE) {
- /* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
-  * field documentation, Haswell supports a minimum of 2kB of
-  * scratch space for compute shaders, unlike every other stage
-  * and platform.
-  */
- prog_data->total_scratch = MAX2(prog_data->total_scratch, 2048);
-  } else if (devinfo->gen <= 7 && stage == MESA_SHADER_COMPUTE) {
- /* According to the MEDIAVFE_STATE's "Per Thread Scratch Space"
-  * field documentation, platforms prior to Haswell measure scratch
-  * size linearly with a range of [1kB, 12kB] and 1kB granularity.
-  */
- prog_data->total_scratch = ALIGN(last_scratch, 1024);
+  prog_data->total_scratch = brw_get_scratch_size(last_scratch);
 
- assert(prog_data->total_scratch < 12 * 1024);
+  if (stage == MESA_SHADER_COMPUTE) {
+ if (devinfo->is_haswell) {
+/* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
+ * field documentation, Haswell supports a minimum of 2kB of
+ * scratch space for compute shaders, unlike every other stage
+ * and platform.
+ */
+prog_data->total_scratch = MAX2(prog_data->total_scratch, 2048);
+ } else if (devinfo->gen <= 7) {
+/* According to the MEDIA_VFE_STATE's "Per Thread Scratch Space"
+ * field documentation, platforms prior to Haswell measure scratch
+ * size linearly with a range of [1kB, 12kB] and 1kB granularity.
+ */
+prog_data->total_scratch = ALIGN(last_scratch, 1024);
+max_scratch_size = 12 * 1024;
+ }
   }
 
   /* We currently only support up to 2MB of scratch space.  If we
@@ -6002,7 +6005,7 @@ fs_visitor::allocate_registers(bool allow_spilling)
* See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
* Thread Group Tracking > Local Memory/Scratch Space.
*/
-  assert(prog_data->total_scratch < 2 * 1024 * 1024);
+  assert(prog_data->total_scratch < max_scratch_size);
}
 }
 
-- 
2.8.3

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

[Mesa-dev] [PATCH 2/2] i965: Support "unlimited" compute shader scratch space.

[Kenneth Graunke]

Ivybridge and Baytrail have a pretty harsh limit of 12kB scratch space
per thread.  However, we can exceed this limit with some clever tricks
and gain effectively unlimited scratch space.

Later platforms have a 2MB limit, which is much more reasonable, but
we may as well apply the same trick there.

We can probably extend this trick to other stages, but would need to
adjust the shader code for the different thread payload layouts.

Cc: "12.0" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96505
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_fs.cpp  | 50 +++
 src/mesa/drivers/dri/i965/gen7_cs_state.c |  6 ++--
 2 files changed, 41 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cadf905..9075918 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -5993,19 +5993,45 @@ fs_visitor::allocate_registers(bool allow_spilling)
 prog_data->total_scratch = ALIGN(last_scratch, 1024);
 max_scratch_size = 12 * 1024;
  }
-  }
 
-  /* We currently only support up to 2MB of scratch space.  If we
-   * need to support more eventually, the documentation suggests
-   * that we could allocate a larger buffer, and partition it out
-   * ourselves.  We'd just have to undo the hardware's address
-   * calculation by subtracting (FFTID * Per Thread Scratch Space)
-   * and then add FFTID * (Larger Per Thread Scratch Space).
-   *
-   * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
-   * Thread Group Tracking > Local Memory/Scratch Space.
-   */
-  assert(prog_data->total_scratch < max_scratch_size);
+ if (prog_data->total_scratch >= max_scratch_size) {
+/* Normally, the hardware computes a pointer to the scratch
+ * space region for our thread for us.  This comes with a
+ * limitation - each thread can only use a limited amount
+ * of scratch space.  To support more than that limit, we
+ * can subtract the hardware's offset and add our own:
+ *
+ * Scratch Space Pointer +=
+ *FFTID * (prog_data->total_scratch - max_scratch_size);
+ *
+ * See 3D-Media-GPGPU Engine > Media GPGPU Pipeline >
+ * Thread Group Tracking > Local Memory/Scratch Space.
+ */
+const fs_builder bld =
+   fs_builder(this, cfg->blocks[0], (fs_inst *)
+  cfg->blocks[0]->start()).exec_all();
+struct brw_reg g0_5 =
+   retype(brw_vec1_grf(0, 5), BRW_REGISTER_TYPE_D);
+struct brw_reg g127 =
+   retype(brw_vec1_grf(127, 0), BRW_REGISTER_TYPE_D);
+
+/* Multiply FFTID by max_scratch_size and shift the result
+ * left by 10.  Then subtract that from the scratch pointer.
+ *
+ * We need a register for temporary storage, but can't allocate
+ * one post-register-allocation.  However, since our code will
+ * be emitted at the top of the program, we can safely use g127,
+ * as it isn't part of the thread payload and can't be in use.
+ */
+bld.AND(g127, g0_5, brw_imm_d(0x3ff));
+bld.MUL(g127, g127,
+brw_imm_d(prog_data->total_scratch - max_scratch_size));
+bld.ADD(g0_5, g0_5, g127);
+ }
+  } else {
+ /* We should extend the above hack for other stages someday. */
+ assert(prog_data->total_scratch < max_scratch_size);
+  }
}
 }
 
diff --git a/src/mesa/drivers/dri/i965/gen7_cs_state.c 
b/src/mesa/drivers/dri/i965/gen7_cs_state.c
index 5fb8829..b89a186 100644
--- a/src/mesa/drivers/dri/i965/gen7_cs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_cs_state.c
@@ -70,21 +70,21 @@ brw_upload_cs_state(struct brw_context *brw)
   */
  OUT_RELOC64(stage_state->scratch_bo,
  I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- ffs(stage_state->per_thread_scratch) - 11);
+ MIN2(ffs(stage_state->per_thread_scratch) - 11, 11));
   } else if (brw->is_haswell) {
  /* Haswell's Per Thread Scratch Space is in the range [0, 10]
   * where 0 = 2k, 1 = 4k, 2 = 8k, ..., 10 = 2M.
   */
  OUT_RELOC(stage_state->scratch_bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
-   ffs(stage_state->per_thread_scratch) - 12);
+   MIN2(ffs(stage_state->per_thread_scratch) - 12, 10));
   } else {
  /* Earlier platforms use the range [0, 11] to mean [1kB, 12kB]
   * where 0 = 1kB, 1 = 2kB, 2 = 3kB, ..., 11 = 12kB.
   */
  OUT_RELOC(stage_state->scratch_bo,
 

Re: [Mesa-dev] Mesa 11.2.2 and Mesa 12.0.0rc3 GLES 3.1 issues with i965 driver

[Ian Romanick]

On 06/16/2016 06:36 AM, Mike Gorchak wrote:
> Hi,
> 
>> You're supposed to get at these functions with eglGetProcAddress() and
> such
> 
> A'm afraid EGL v1.4 spec forbids obtaining core functions through
> eglGetProcAddress(), they should be visible at dynamic linker level.

Unless you have the EGL_KHR_get_all_proc_addresses extension, which I
believe Mesa has. :)

> Anyway, thanks!
> 
> 
> On Wed, Jun 15, 2016 at 3:06 PM, Ilia Mirkin  > wrote:
> 
> On Wed, Jun 15, 2016 at 2:55 PM, Mike Gorchak
> > wrote:
> > Hi,
> >
> > hm, could you check "cat ./src/mapi/es2api/glapi_mapi_tmp.h | grep
> > glFramebufferParameteri" ?
> >
> > I can see void APIENTRY gl_dispatch_stub_888(GLenum target, GLenum 
> pname,
> > GLint param); instead of glFramebufferParameteri there.
> >
> > Also objdump -x for GLES 2.0 API shows absence of 
> glFramebufferParameteri()
> > function as well. Only GLES 3.0 functions are present.
> 
> I'm not up on all the latest, but are those supposed to be there? This
> just means that they're not exposed symbols in libGLESv2.so, which
> afaik is right. It's definitely right for libGL.so. You're supposed to
> get at these functions with eglGetProcAddress() and such. However
> perhaps the policy for libGLESv2.so is supposed to be different? Ian
> will know for sure.
> 
>   -ilia

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

Re: [Mesa-dev] Mesa 11.2.2 and Mesa 12.0.0rc3 GLES 3.1 issues with i965 driver

[Ian Romanick]

On 06/15/2016 11:23 AM, Mike Gorchak wrote:
> Hello,
> 
> Just found that latest Mesa 11.2.2 and 12.0.0rc3 exposes version 3.1 of
> OpenGL ES instead of 3.0 if i965 DRI driver is used on Intel Gen8
> (Broadwell) or Gen9 (AppolloLake/Broxton) hardware.
> 
> At the same time some of GLES 3.1 functions are not available through
> MAPI interface like glFramebufferParameteri().

I was having similar issues when adding a piglit test for
GL_OES_geometry_shader.  I hadn't had a chance to examine the spec to be
sure that the functions should be statically exported by libGLESv2 or
not.  It looks like we did that for OpenGL ES 3.0, so I expect we should
for 3.1 as well.

> It seems it is just a question of regeneration of interface files, could
> you regenerate them and release new bugfix version?
> 
> Thanks in advance!
> 
> 
> 
> ___
> 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] swr: push/pop DEBUG macro around llvm includes

[Tim Rowley]

llvm redefines DEBUG; adding push/pop prevents a undefined reference
to debug_refcnt_state in llvm-3.7+.
---
 src/gallium/drivers/swr/swr_shader.cpp | 9 ++---
 src/gallium/drivers/swr/swr_state.cpp  | 6 +-
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/swr/swr_shader.cpp 
b/src/gallium/drivers/swr/swr_shader.cpp
index 8af0700..3d966a8 100644
--- a/src/gallium/drivers/swr/swr_shader.cpp
+++ b/src/gallium/drivers/swr/swr_shader.cpp
@@ -21,14 +21,17 @@
  * IN THE SOFTWARE.
  ***/
 
+// llvm redefines DEBUG
+#pragma push_macro("DEBUG")
 #include "JitManager.h"
+#include "llvm-c/Core.h"
+#include "llvm/Support/CBindingWrapping.h"
+#pragma pop_macro("DEBUG")
+
 #include "state.h"
 #include "state_llvm.h"
 #include "builder.h"
 
-#include "llvm-c/Core.h"
-#include "llvm/Support/CBindingWrapping.h"
-
 #include "tgsi/tgsi_strings.h"
 #include "gallivm/lp_bld_init.h"
 #include "gallivm/lp_bld_flow.h"
diff --git a/src/gallium/drivers/swr/swr_state.cpp 
b/src/gallium/drivers/swr/swr_state.cpp
index 3eeb98d..36ab353 100644
--- a/src/gallium/drivers/swr/swr_state.cpp
+++ b/src/gallium/drivers/swr/swr_state.cpp
@@ -21,9 +21,13 @@
  * IN THE SOFTWARE.
  ***/
 
+// llvm redefines DEBUG
+#pragma push_macro("DEBUG")
+#include "JitManager.h"
+#pragma pop_macro("DEBUG")
+
 #include "common/os.h"
 #include "jit_api.h"
-#include "JitManager.h"
 #include "state_llvm.h"
 
 #include "gallivm/lp_bld_tgsi.h"
-- 
1.9.1

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

[Mesa-dev] [PATCH] glcpp: Only expose ARB_enhanced_layouts if it's supported.

[Dylan Baker]

This fixes the following piglit tests:
spec/arb_enhanced_layouts/preprocessor/disabled-defined-core.*

Signed-off-by: Dylan Baker 
---
 src/compiler/glsl/glcpp/glcpp-parse.y | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y 
b/src/compiler/glsl/glcpp/glcpp-parse.y
index 2cfa6a6..76cba07 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -2338,12 +2338,14 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
*parser, intmax_t versio
   }
} else {
   add_builtin_define(parser, "GL_ARB_draw_buffers", 1);
-  add_builtin_define(parser, "GL_ARB_enhanced_layouts", 1);
   add_builtin_define(parser, "GL_ARB_separate_shader_objects", 1);
   add_builtin_define(parser, "GL_ARB_texture_rectangle", 1);
   add_builtin_define(parser, "GL_AMD_shader_trinary_minmax", 1);
 
   if (extensions != NULL) {
+ if (extensions->ARB_enhanced_layouts)
+ add_builtin_define(parser, "GL_ARB_enhanced_layouts", 1);
+
  if (extensions->EXT_texture_array)
 add_builtin_define(parser, "GL_EXT_texture_array", 1);
 
-- 
2.8.3

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

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Emil Velikov]

On 16 June 2016 at 21:14, Haixia Shi  wrote:
> Emil
>
> I looked at commit 3689ef32 which started the problem, and it seems that
> patch removed the line "touch git_sha1.h.tmp". Previously my workflow was
> "working" because the touch command ensures there's always going to be an
> empty header file.
>
> Was this intentional? For the new git_sha1.h rules, I wonder if it is ok to
> add a step for git_sha1.h.tmp that does a "touch git_sha1.h" to ensure the
> file exists?
>
As said earlier - if the proposed workflow solutions don't work,
please check the earlier suggestions/email [1]. Also [2] might be
mildly related (joking of course)

Thanks
Emil

[1] https://lists.freedesktop.org/archives/mesa-dev/2016-June/120709.html
[2] https://xkcd.com/1172/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Haixia Shi]

Emil

I looked at commit 3689ef32 which started the problem, and it seems that
patch removed the line "touch git_sha1.h.tmp". Previously my workflow was
"working" because the touch command ensures there's always going to be an
empty header file.

Was this intentional? For the new git_sha1.h rules, I wonder if it is ok to
add a step for git_sha1.h.tmp that does a "touch git_sha1.h" to ensure the
file exists?

On Thu, Jun 16, 2016 at 12:48 PM, Emil Velikov 
wrote:

> On 16 June 2016 at 20:47, Emil Velikov  wrote:
> > On 16 June 2016 at 20:42, Haixia Shi  wrote:
> >> Bisect shows the problem started at commit
> >> 3689ef32afdafbb030069e560aac0e563fc29048
> >> Author: Emil Velikov 
> >> Date:   Mon May 30 12:32:05 2016 +0100
> >>
> >> automake: rework the git_sha1.h rule, include in tarball
> >>
> >> As we'll need the file in the release tarball, rework the rule so
> that
> >> the file is regenerated _only_ if we're in a git repository.
> >>
> >> With this in place we can build vulkan (anv) from a release tarball.
> >>
> >> Cc: Jason Ekstrand 
> >> Cc: Kristian Høgsberg Kristensen 
> >> Signed-off-by: Emil Velikov 
> >>
> >> I'm not building from a release tarball, but the workflow first copies
> the
> >> source tree to a tmp directory (without the .git directory), so there's
> no
> >> git_sha1.h file, and the file is not generated either.
> >>
> > Hmmm... I wouldn't have imagine this particular workflow. Have you
> > considered gitlink and/or git worktree ?
> >
> > If neither of these are an option for you see my earlier email.
> >
> The former seems to be missing a manpage so here's a PDF
> https://media.readthedocs.org/pdf/git-link/latest/git-link.pdf
>
> -Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] virgl and vc4 problem on Android

[Emil Velikov]

On 16 June 2016 at 17:56, Rob Herring  wrote:
> On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
>> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
>>> In the process of adding RGBX (XB24) format to mesa for Android, I
>>> started seeing a new problem that makes the UI stop updating. It
>>> happens about when the splash screen is stopped and the lock screen is
>>> displayed. The display flickers on mouse movement, and it looks like
>>> the screen is flipping to old buffers (like the splash screen after
>>> its process exited). It is working fine for freedreno AFAICT, but I am
>>> running into a problem with virgl. With virgl, I get the following
>>> error:
>>>
>>> vrend_create_surface: context error reported 1 "surfaceflinger"
>>> Illegal resource 1435
>>> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
>>> Illegal command buffer 329729
>>>
>>> The addition of the pixel format changes the eglconfig used for the
>>> splash screen. If I force the splash screen eglconfig to have an alpha
>>> or draw one frame of the splash screen and exit early or disable the
>>> splash screen, everything seems fine though I have hit the problem
>>> rarely navigating around. I suspect this has nothing to do with the
>>> pixel format other than different buffer sizes cause buffers to get
>>> reused differently.
>>>
>>> Now I've started working on getting RPi3 and vc4 working, and it
>>> appears to have a similar problem. I'm getting these errors though
>>> things go haywire before getting any error message:
>>>
>>> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 
>>> 0: 4
>>
>> at least in the vc4 case, I suspect you need a similar bit of winsys
>> magic to ensure the same pipe_screen is returned for any given drm
>> device fd.  (Or did someone already add that?)
>
> That problem should be gone with GBM gralloc, right?
>
I think you might have figured it out already, but just in case:
GBM gralloc does not make the winsys fd hashing obsolete. It only
removes the need for exporting the foo_winsys_create symbol from the
DRI module and using it directing from (drm_)gralloc.

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

[Mesa-dev] [PATCH] swr: switch from overriding -march to selecting features

[Tim Rowley]

---
 configure.ac| 11 +++
 src/gallium/drivers/swr/Makefile.am |  4 ++--
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index c492e15..cc9bc47 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2400,8 +2400,8 @@ if test -n "$with_gallium_drivers"; then
 swr_llvm_check "swr"
 
 AC_MSG_CHECKING([whether $CXX supports c++11/AVX/AVX2])
-AVX_CXXFLAGS="-march=core-avx-i"
-AVX2_CXXFLAGS="-march=core-avx2"
+SWR_AVX_CXXFLAGS="-mavx"
+SWR_AVX2_CXXFLAGS="-mavx2 -mfma -mbmi2 -mf16c"
 
 AC_LANG_PUSH([C++])
 save_CXXFLAGS="$CXXFLAGS"
@@ -2411,18 +2411,21 @@ if test -n "$with_gallium_drivers"; then
 CXXFLAGS="$save_CXXFLAGS"
 
 save_CXXFLAGS="$CXXFLAGS"
-CXXFLAGS="$AVX_CXXFLAGS $CXXFLAGS"
+CXXFLAGS="$SWR_AVX_CXXFLAGS $CXXFLAGS"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],[],
   [AC_MSG_ERROR([AVX compiler support not 
detected])])
 CXXFLAGS="$save_CXXFLAGS"
 
 save_CFLAGS="$CXXFLAGS"
-CXXFLAGS="$AVX2_CXXFLAGS $CXXFLAGS"
+CXXFLAGS="$SWR_AVX2_CXXFLAGS $CXXFLAGS"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],[],
   [AC_MSG_ERROR([AVX2 compiler support not 
detected])])
 CXXFLAGS="$save_CXXFLAGS"
 AC_LANG_POP([C++])
 
+AC_SUBST([SWR_AVX_CXXFLAGS])
+AC_SUBST([SWR_AVX2_CXXFLAGS])
+
 HAVE_GALLIUM_SWR=yes
 ;;
 xvc4)
diff --git a/src/gallium/drivers/swr/Makefile.am 
b/src/gallium/drivers/swr/Makefile.am
index 8151e4a..d896154 100644
--- a/src/gallium/drivers/swr/Makefile.am
+++ b/src/gallium/drivers/swr/Makefile.am
@@ -125,7 +125,7 @@ COMMON_LDFLAGS = \
 lib_LTLIBRARIES = libswrAVX.la libswrAVX2.la
 
 libswrAVX_la_CXXFLAGS = \
-   -march=core-avx-i \
+   $(SWR_AVX_CXXFLAGS) \
-DKNOB_ARCH=KNOB_ARCH_AVX \
$(COMMON_CXXFLAGS)
 
@@ -139,7 +139,7 @@ libswrAVX_la_LDFLAGS = \
$(COMMON_LDFLAGS)
 
 libswrAVX2_la_CXXFLAGS = \
-   -march=core-avx2 \
+   $(SWR_AVX2_CXXFLAGS) \
-DKNOB_ARCH=KNOB_ARCH_AVX2 \
$(COMMON_CXXFLAGS)
 
-- 
1.9.1

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

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Emil Velikov]

On 16 June 2016 at 20:47, Emil Velikov  wrote:
> On 16 June 2016 at 20:42, Haixia Shi  wrote:
>> Bisect shows the problem started at commit
>> 3689ef32afdafbb030069e560aac0e563fc29048
>> Author: Emil Velikov 
>> Date:   Mon May 30 12:32:05 2016 +0100
>>
>> automake: rework the git_sha1.h rule, include in tarball
>>
>> As we'll need the file in the release tarball, rework the rule so that
>> the file is regenerated _only_ if we're in a git repository.
>>
>> With this in place we can build vulkan (anv) from a release tarball.
>>
>> Cc: Jason Ekstrand 
>> Cc: Kristian Høgsberg Kristensen 
>> Signed-off-by: Emil Velikov 
>>
>> I'm not building from a release tarball, but the workflow first copies the
>> source tree to a tmp directory (without the .git directory), so there's no
>> git_sha1.h file, and the file is not generated either.
>>
> Hmmm... I wouldn't have imagine this particular workflow. Have you
> considered gitlink and/or git worktree ?
>
> If neither of these are an option for you see my earlier email.
>
The former seems to be missing a manpage so here's a PDF
https://media.readthedocs.org/pdf/git-link/latest/git-link.pdf

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

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Herring]

On Thu, Jun 16, 2016 at 2:20 PM, Rob Clark  wrote:
> On Thu, Jun 16, 2016 at 2:57 PM, Rob Herring  wrote:
>> On Thu, Jun 16, 2016 at 12:09 PM, Rob Clark  wrote:
>>> On Thu, Jun 16, 2016 at 12:56 PM, Rob Herring  wrote:
 On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
>> In the process of adding RGBX (XB24) format to mesa for Android, I
>> started seeing a new problem that makes the UI stop updating. It
>> happens about when the splash screen is stopped and the lock screen is
>> displayed. The display flickers on mouse movement, and it looks like
>> the screen is flipping to old buffers (like the splash screen after
>> its process exited). It is working fine for freedreno AFAICT, but I am
>> running into a problem with virgl. With virgl, I get the following
>> error:
>>
>> vrend_create_surface: context error reported 1 "surfaceflinger"
>> Illegal resource 1435
>> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
>> Illegal command buffer 329729
>>
>> The addition of the pixel format changes the eglconfig used for the
>> splash screen. If I force the splash screen eglconfig to have an alpha
>> or draw one frame of the splash screen and exit early or disable the
>> splash screen, everything seems fine though I have hit the problem
>> rarely navigating around. I suspect this has nothing to do with the
>> pixel format other than different buffer sizes cause buffers to get
>> reused differently.
>>
>> Now I've started working on getting RPi3 and vc4 working, and it
>> appears to have a similar problem. I'm getting these errors though
>> things go haywire before getting any error message:
>>
>> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM 
>> BO 0: 4
>
> at least in the vc4 case, I suspect you need a similar bit of winsys
> magic to ensure the same pipe_screen is returned for any given drm
> device fd.  (Or did someone already add that?)

 That problem should be gone with GBM gralloc, right?
>>>
>>> *maaaybe*..
>>>
>>> It, like the gralloc-drm-pipe approach, means we have a pipe_screen
>>> (vs. the other drm-gralloc backends which were using libdrm_xyz
>>> directly), so it was going through the logic to avoid duplicate
>>> pipe_screen's (for the drivers which had that).
>>>
>>> Maybe w/ gbm, everything ends up sharing the same pipe_screen?  I'm
>>> not really sure, since I guess both GL and gralloc are creating a gbm
>>> device?
>>>
>>> I guess easy enough to put some debug print in vc4_screen_create() to
>>> confirm.  But the sort of errors you are seeing make me suspicious.
>>
>> Uhh, well looks like that is a problem for vc4:
>>
>> 01-01 00:00:07.295   127   127 W VC4 : vc4_screen_create
>> 01-01 00:00:07.334   127   127 W VC4 : vc4_screen_create
>> 01-01 00:00:08.349   205   223 W VC4 : vc4_screen_create
>> 01-01 00:00:08.352   205   223 W VC4 : vc4_screen_create
>> 01-01 00:00:35.467   437   488 W VC4 : vc4_screen_create
>> 01-01 00:00:35.477   437   488 W VC4 : vc4_screen_create
>> 01-01 00:00:39.041   511   511 W VC4 : vc4_screen_create
>> 01-01 00:00:43.385   511   798 W VC4 : vc4_screen_create
>> 01-01 00:00:44.135   718   718 W VC4 : vc4_screen_create
>> 01-01 00:00:44.202   718   923 W VC4 : vc4_screen_create
>>
>>> Possibly the "libdrm equivalent" part of vc4 needs to do more to avoid
>>> re-importing the same handle multiple times?
>>
>> Maybe time for the common implementation.
>
> yeah, probably
>
>> This doesn't explain the virgl case though as I already fixed this
>> problem. The log below is from virgl.
>
> I haven't looked closely at virgl yet, but if it has some sort of bo
> cache, perhaps it is allowing shared buffers into the cache??  Not
> sure, but I'd be on the lookout for things like that..

I had disabled the cache for virgl without any improvement.

> Presumably it already has a hashtable to deal w/ multiple-imports of
> the same flink name?

virgl does, though I added the dmabuf support, so maybe it needs
better review. :) It looks like this is the 2nd problem with vc4.

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

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Emil Velikov]

On 16 June 2016 at 20:42, Haixia Shi  wrote:
> Bisect shows the problem started at commit
> 3689ef32afdafbb030069e560aac0e563fc29048
> Author: Emil Velikov 
> Date:   Mon May 30 12:32:05 2016 +0100
>
> automake: rework the git_sha1.h rule, include in tarball
>
> As we'll need the file in the release tarball, rework the rule so that
> the file is regenerated _only_ if we're in a git repository.
>
> With this in place we can build vulkan (anv) from a release tarball.
>
> Cc: Jason Ekstrand 
> Cc: Kristian Høgsberg Kristensen 
> Signed-off-by: Emil Velikov 
>
> I'm not building from a release tarball, but the workflow first copies the
> source tree to a tmp directory (without the .git directory), so there's no
> git_sha1.h file, and the file is not generated either.
>
Hmmm... I wouldn't have imagine this particular workflow. Have you
considered gitlink and/or git worktree ?

If neither of these are an option for you see my earlier email.

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

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Emil Velikov]

Hi Haixia Shi,

On 16 June 2016 at 19:46, Haixia Shi  wrote:
> Posting a question in case someone already know the issue.
>
> I'm observing "missing git_sha1.h" errors sometime after Emil's git_sha1.h
> patches by May 31st. This is not fixed at TOT with the latest patches on
> Makefile.am.
>
> The problem only happens if src/git_sha1.h doesn't exist already. I just
> need to put a dummy git_sha1.h file there to work around the error.
>
> There's a similar bug filed
> (https://bugs.freedesktop.org/show_bug.cgi?id=50976) but the fix for that
> one patches src/Makefile directly, whereas my build flow only requires
> Makefile.am.
>
The bug report in question is ancient and doesn't reflect what we have atm.

I'd imagine that you're using one of the following two:
 - git archive tarballs, or
 - you don't have access to the 'git' executable after the checkout
(using chroot and//or other).

In case of the latter I have a patch that I'm testing atm. Sadly it
won't 'fix' the issue, as that is a deliberate change.

Namely: one should _really_ be using either a proper git checkout
(with the .git folder) or a tarball produced by `make dist' (like the
release ones).

In the case that you use one of the top two, I'd suggest adding the
following or one that produces similar result.

echo '#define MESA_GIT_SHA1 "git-$mesa-checkout-sha1"' > mesa/src/git_sha1.h

Obviously you should already know the actual sha (mesa-checkout-sha1).

Regards,
Emil

P.S. What exactly does TOT mean ?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Haixia Shi]

Bisect shows the problem started at commit
3689ef32afdafbb030069e560aac0e563fc29048
Author: Emil Velikov 
Date:   Mon May 30 12:32:05 2016 +0100

automake: rework the git_sha1.h rule, include in tarball

As we'll need the file in the release tarball, rework the rule so that
the file is regenerated _only_ if we're in a git repository.

With this in place we can build vulkan (anv) from a release tarball.

Cc: Jason Ekstrand 
Cc: Kristian Høgsberg Kristensen 
Signed-off-by: Emil Velikov 

I'm not building from a release tarball, but the workflow first copies the
source tree to a tmp directory (without the .git directory), so there's no
git_sha1.h file, and the file is not generated either.

On Thu, Jun 16, 2016 at 11:46 AM, Haixia Shi  wrote:

> Posting a question in case someone already know the issue.
>
> I'm observing "missing git_sha1.h" errors sometime after Emil's git_sha1.h
> patches by May 31st. This is not fixed at TOT with the latest patches on
> Makefile.am.
>
> The problem only happens if src/git_sha1.h doesn't exist already. I just
> need to put a dummy git_sha1.h file there to work around the error.
>
> There's a similar bug filed (
> https://bugs.freedesktop.org/show_bug.cgi?id=50976) but the fix for that
> one patches src/Makefile directly, whereas my build flow only requires
> Makefile.am.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/64] i965: Drop Max3DTextureLevels to 512 on Sandy Bridge and prior

[Ian Romanick]

On 06/16/2016 11:50 AM, Jason Ekstrand wrote:
> 
> 
> On Thu, Jun 16, 2016 at 11:43 AM, Ian Romanick  > wrote:
> 
> On 06/11/2016 09:02 AM, Jason Ekstrand wrote:
> > The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to 
> be
> > set to the depth of a 3-D texture when rendering.  Unfortunatley, that
>  Unfortunately
> 
> > field is only 9 bits on Sandy Bridge and prior so we can't actually bind
> > a 3-D texturing for rendering if it has depth > 512.  On Ivy Bridge, 
> this
> > field was bumpped to 11 bits so we can go all the way up to 2048.
> bumped
> 
> > Cc: "11.1 11.2 12.0"  >
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> > index 7bbc128..3b11bef 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -467,7 +467,10 @@ brw_initialize_context_constants(struct 
> brw_context *brw)
> > ctx->Const.MaxImageUnits = MAX_IMAGE_UNITS;
> > ctx->Const.MaxRenderbufferSize = 8192;
> > ctx->Const.MaxTextureLevels = MIN2(14 /* 8192 */, 
> MAX_TEXTURE_LEVELS);
> > -   ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> > +   if (brw->gen >= 7)
> > +  ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> > +   else
> > +  ctx->Const.Max3DTextureLevels = 10; /* 512 */
> 
> This should use ?: like MaxArrayTextureLayers below.
> 
> This was increased from 512 to 2048 in 2014 in commit 06b047eb.  There
> was some assertion in the commit message that the Windows driver was
> already advertising 2048.  There is no mention, however, of which
> hardware the Windows driver was checked on.  In the related bug report
> (https://bugs.freedesktop.org/show_bug.cgi?id=74130), Ken says, "All
> Gen4+ systems support 2048x2048 3D textures, so we could just bump the
> limit."
> 
> It sounds like this may be a temporary fix, and we need a work around
> for rendering to slices > 9?
> 
> It's a bit more subtle than that, I'm afraid.  The current gen4 render
> target setup code (which isn't used on SNB) can handle rendering to any
> layer of a 3-D texture regardless of size and SNB could be fixed up to
> do the same.  The problem is when you use layered rendering.  When doing
> layered rendering, we can only access at most 512 layers.  This means
> that we need to either limit the texture size or we need to give the
> user an incomplete framebuffer if they try and do layered rendering on a
> 3-D texture with more than 512 slices.  That's kind-of a nasty edge for
> applications to hit.

Oh yuck.  It is mean to give a spurious incomplete framebuffer, but
reducing a limit can make a previously working app fail... also mean.
I think there's a less-mean plan possible.  I believe these are the
facts:

 * Gen4 and Gen5 don't have layered rendering, so Max3DTextureLevels =
   12 should "just work" there.

 * According to 
http://feedback.wildfiregames.com/report/opengl/device/Intel%28R%29%20HD%20Graphics%203000,
   the Windows driver only supports OpenGL 3.1, so they never had the
   layered rendering issue.  They also advertise 2048 starting with
   driver version 9.17.10.2792.

 * In OpenGL ES and OpenGL Compatibility profile, there is no way to do
   layered rendering on SNB with our driver.

 * With a bit of work, we could handle 2048 on SNB for all non-layered
   rendering cases.

Assuming that's all correct, how about if we change the current patch to

   ctx->Const.Max3DTextureLevels = brw->gen == 6 ? 9 /* 512 */ : 12 /* 2048 */;

and add a release note.

For 12.next let's plan to do Gen4-style layer offsetting for SNB.  Then
change the limit setting code to

   ctx->Const.Max3DTextureLevels = brw->gen == 6 && ctx->API == API_OPENGL_CORE
  ? 9 /* 512 */ : 12 /* 2048 */;

We can also add a driconf option to force 2048.

A "patches welcome" follow-up would be to implement
GL_NV_deep_texture3D to expose width or height of 2048 with depth
limited to 512.

> --Jason
> 
> > ctx->Const.MaxCubeTextureLevels = 14; /* 8192 */
> > ctx->Const.MaxArrayTextureLayers = brw->gen >= 7 ? 2048 : 512;
> > ctx->Const.MaxTextureMbytes = 1536;
> >

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

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Clark]

On Thu, Jun 16, 2016 at 2:57 PM, Rob Herring  wrote:
> On Thu, Jun 16, 2016 at 12:09 PM, Rob Clark  wrote:
>> On Thu, Jun 16, 2016 at 12:56 PM, Rob Herring  wrote:
>>> On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
 On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
> In the process of adding RGBX (XB24) format to mesa for Android, I
> started seeing a new problem that makes the UI stop updating. It
> happens about when the splash screen is stopped and the lock screen is
> displayed. The display flickers on mouse movement, and it looks like
> the screen is flipping to old buffers (like the splash screen after
> its process exited). It is working fine for freedreno AFAICT, but I am
> running into a problem with virgl. With virgl, I get the following
> error:
>
> vrend_create_surface: context error reported 1 "surfaceflinger"
> Illegal resource 1435
> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
> Illegal command buffer 329729
>
> The addition of the pixel format changes the eglconfig used for the
> splash screen. If I force the splash screen eglconfig to have an alpha
> or draw one frame of the splash screen and exit early or disable the
> splash screen, everything seems fine though I have hit the problem
> rarely navigating around. I suspect this has nothing to do with the
> pixel format other than different buffer sizes cause buffers to get
> reused differently.
>
> Now I've started working on getting RPi3 and vc4 working, and it
> appears to have a similar problem. I'm getting these errors though
> things go haywire before getting any error message:
>
> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 
> 0: 4

 at least in the vc4 case, I suspect you need a similar bit of winsys
 magic to ensure the same pipe_screen is returned for any given drm
 device fd.  (Or did someone already add that?)
>>>
>>> That problem should be gone with GBM gralloc, right?
>>
>> *maaaybe*..
>>
>> It, like the gralloc-drm-pipe approach, means we have a pipe_screen
>> (vs. the other drm-gralloc backends which were using libdrm_xyz
>> directly), so it was going through the logic to avoid duplicate
>> pipe_screen's (for the drivers which had that).
>>
>> Maybe w/ gbm, everything ends up sharing the same pipe_screen?  I'm
>> not really sure, since I guess both GL and gralloc are creating a gbm
>> device?
>>
>> I guess easy enough to put some debug print in vc4_screen_create() to
>> confirm.  But the sort of errors you are seeing make me suspicious.
>
> Uhh, well looks like that is a problem for vc4:
>
> 01-01 00:00:07.295   127   127 W VC4 : vc4_screen_create
> 01-01 00:00:07.334   127   127 W VC4 : vc4_screen_create
> 01-01 00:00:08.349   205   223 W VC4 : vc4_screen_create
> 01-01 00:00:08.352   205   223 W VC4 : vc4_screen_create
> 01-01 00:00:35.467   437   488 W VC4 : vc4_screen_create
> 01-01 00:00:35.477   437   488 W VC4 : vc4_screen_create
> 01-01 00:00:39.041   511   511 W VC4 : vc4_screen_create
> 01-01 00:00:43.385   511   798 W VC4 : vc4_screen_create
> 01-01 00:00:44.135   718   718 W VC4 : vc4_screen_create
> 01-01 00:00:44.202   718   923 W VC4 : vc4_screen_create
>
>> Possibly the "libdrm equivalent" part of vc4 needs to do more to avoid
>> re-importing the same handle multiple times?
>
> Maybe time for the common implementation.

yeah, probably

> This doesn't explain the virgl case though as I already fixed this
> problem. The log below is from virgl.

I haven't looked closely at virgl yet, but if it has some sort of bo
cache, perhaps it is allowing shared buffers into the cache??  Not
sure, but I'd be on the lookout for things like that..

Presumably it already has a hashtable to deal w/ multiple-imports of
the same flink name?

BR,
-R

 In both virgl and vc4 case, you need to make sure that shared
 (exported/imported) buffers don't end up in the bo cache.
>>>
>>> I've disabled the cache (in the gallium drv, right?) and still see problems.
>>>
>>> I am seeing a double GEM_CLOSE. I'm not sure how that is happening.
>>> One of them must be hwc releasing an imported buffer, but it's all in
>>> the same thread.
>>>
>>> [7.024495] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret = 0,
>>> DRM_IOCTL_GEM_CLOSE
>>> [7.025379] [drm] pid=1310, dev=0xe280, auth=0, handle=23, ret = 0,
>>> DRM_IOCTL_PRIME_FD_TO_HANDLE
>>> [7.026663] [drm] pid=1310, dev=0xe280, auth=0, handle=10, ret = 0,
>>> DRM_IOCTL_GEM_CLOSE
>>> [7.027343] [drm] pid=1310, dev=0xe200, auth=1, handle=23, ret = 0,
>>> DRM_IOCTL_PRIME_FD_TO_HANDLE
>>> [7.035098] [drm] pid=1333, dev=0xe200, auth=1, handle=1, ret = 0,
>>> DRM_IOCTL_GEM_CLOSE
>>> [7.036093] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret =

Re: [Mesa-dev] [Mesa-stable] [PATCH] swr: fix -march flag for AVX

[Chuck Atkins]

After some architecture testing, it looks like we can drop the march
options and just enable the specific instruction sets via:

libswrAVX: -mavx
libswrAVX2: -mavx2 -mfma -mbmi2 -mf16c

The benefit of course is that with these flags swr works on AMD cpu's with
AVX and AVX2 instructions enabled.  The specific march flags can cause
instruction set compatibility mismatch since AMD CPUs that supported AVX
didn't necessarily support all of sandybridge instructions and similar for
AVX2 and haswell.  Regarding the extra options for fma, bmi2, and f16c, all
AMD CPUs that supported AVX2 also supported those as well.

- Chuck

On Mon, Jun 13, 2016 at 1:22 PM, Emil Velikov 
wrote:

> On 13 June 2016 at 15:43, Rowley, Timothy O 
> wrote:
> >
> >> On Jun 12, 2016, at 3:56 AM, Steven Newbury 
> wrote:
> >>
> >> On Fri, 2016-06-10 at 16:05 -0400, Ilia Mirkin wrote:
> >>> On Fri, Jun 10, 2016 at 3:43 PM, Tim Rowley  >>> om> wrote:
> 
>  Previously used core-avx-i was for ivybridge;
>  corei7-avx allows sandybridge.
>  ---
>   src/gallium/drivers/swr/Makefile.am | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/src/gallium/drivers/swr/Makefile.am
>  b/src/gallium/drivers/swr/Makefile.am
>  index d211f2e..8156cf2 100644
>  --- a/src/gallium/drivers/swr/Makefile.am
>  +++ b/src/gallium/drivers/swr/Makefile.am
>  @@ -124,7 +124,7 @@ COMMON_LDFLAGS = \
>   lib_LTLIBRARIES = libswrAVX.la libswrAVX2.la
> 
>   libswrAVX_la_CXXFLAGS = \
>  -   -march=core-avx-i \
>  +   -march=corei7-avx \
> >>> Just wondering if it'd be enough to say like
> >>>
> >>> -march=x86_64
> >>> -mavx
> >>>
> >>> and add -mavx2 for libswrAVX2.
> >>>
> >>> I suspect you've iterated through this 20 times and this has some
> >>> shortcoming I'm not thinking of, but figured I'd point it out just in
> >>> case it helps.
> >>>
> >>>   -ilia
> >>>
> >> Maybe I'm the only one who finds it horrible to override -march from
> >> within project build systems.
>
> >> It causes no end of problems with LTO,
> >> and results in objects being built inappropriately for the target as
> >> specified by the builder.
> Can you please elaborate on the exact problem ? Is there link where
> one can read more on the topic ?
>
> > I agree that the way swr is built can be improved and welcome
> ideas/discussion for work on the master branch, but for the moment I’m
> trying to get the 12.0 branch in good shape for swr with non-invasive
> changes (as we’ve tested the current setup pretty extensively).
> >
> Fully agree. Getting something more robust and less evasive for 12.0
> and work for 'the best' in master. Perhaps attribute((target)) perhaps
> folding the multiple binaries into one, or maybe something else ?
>
> >> Why not use function attributes?  Either compile a function
> >> specifically for a particular target, or specifically enable AVX though
> >> "__attribute__ ((__target__ ("avx")))"
> Is this going to produce correct binary if one provides -mno-avx
> and/or alike ? I believe for some CPUs one should (or the compiler
> does it for them) explicitly disable avx but honestly I've never
> looked if cpuid for the said CPUs shows avx as supported.
>
> In the latter case (cpuid listing AVX as supported, while one is
> recommended building with -mno-avx) how do you suggest we should
> handle things ?
>
> >> (ideally with a fall-back
> >> implementation detected at run-time when the instruction set isn't
> >> supported).  Even better, have it also protected at build-time by a
> >> simple check for __AVX__ so the code can be compiled out entirely where
> >> the package builder has specified -march(=native) as a build flag.
> The idea here is to have the binary build explicitly with avx/avx2 (if
> compiler is capable), even when doing generic builds. The picky part
> comes when one has to establish if the user provided one is 'more
> generic' or not (as per your example).
>
> Then again, based on my limited 'testing', building mesa with native
> and LTO brings us little to no improvements. 'Tested' running glxgears
> in small window.
>
> > One problem with the function attribute path is that as far as I know,
> MSVC does not have a similar feature.
> >
> Afaict MSVC has optimise pragma [1], just like GCC. Ideally they'll
> add an equivalent to attribute((target)) soon ?
>
> Even without that, swr (as seen in mesa) does not build MSVC. When
> that cases it should be a matter of factoring the attribute target as
> a macro and leaving it empty for the !GCC build ?
>
> TL;DR: IMHO fix is ok for now, but for the future we might want to
> explode other options.
>
> -Emil
> [1] https://msdn.microsoft.com/en-us/library/chh3fb0k.aspx
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> 

Re: [Mesa-dev] [PATCH v2 03/11] mesa: Strip arrayness from interface block names in some IO validation

[Ilia Mirkin]

On Thu, Jun 16, 2016 at 3:06 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> Outputs from the vertex shader need to be able to match
> per-vertex-arrayed inputs of later stages.  Acomplish this by stripping
> one level of arrayness from the names and types of outputs going to a
> per-vertex-arrayed stage.
>
> v2: Add missing checks for TESS_EVAL->GEOMETRY.  Noticed by Timothy
> Arceri.
>
> Signed-off-by: Ian Romanick 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
> Cc: "12.0" 
> Cc: Gregory Hainaut 
> Cc: Ilia Mirkin 
> ---
>  src/mesa/main/shader_query.cpp | 100 
> +
>  1 file changed, 92 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index 5956ce4..a6a0a2f 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -1385,13 +1385,26 @@ _mesa_get_program_resourceiv(struct gl_shader_program 
> *shProg,
>
>  static bool
>  validate_io(struct gl_shader_program *producer,
> -struct gl_shader_program *consumer)
> +struct gl_shader_program *consumer,
> +gl_shader_stage producer_stage,
> +gl_shader_stage consumer_stage)
>  {
> if (producer == consumer)
>return true;
>
> +   const bool nonarray_stage_to_array_stage =
> +  (producer_stage == MESA_SHADER_VERTEX &&
> +   (consumer_stage == MESA_SHADER_GEOMETRY ||
> +consumer_stage == MESA_SHADER_TESS_CTRL ||
> +consumer_stage == MESA_SHADER_TESS_EVAL)) ||
> +  (producer_stage == MESA_SHADER_TESS_EVAL &&
> +   consumer_stage == MESA_SHADER_GEOMETRY);

Since TCS -> GEOM is not possible, isn't the only way that array ->
array can happen is TCS -> TES? IOW, couldn't this just be

producer != TCS && (consumer == TCS || consumer == TES || consumer == GS)

Your call whether you want to rewrite it. [No comment on the rest of
the patch...]

  -ilia

> +
> bool valid = true;
>
> +   void *name_buffer = NULL;
> +   size_t name_buffer_size = 0;
> +
> gl_shader_variable const **outputs =
>(gl_shader_variable const **) calloc(producer->NumProgramResourceList,
> sizeof(gl_shader_variable *));
> @@ -1463,11 +1476,52 @@ validate_io(struct gl_shader_program *producer,
>  }
>   }
>} else {
> + char *consumer_name = consumer_var->name;
> +
> + if (nonarray_stage_to_array_stage &&
> + consumer_var->interface_type != NULL &&
> + consumer_var->interface_type->is_array() &&
> + !is_gl_identifier(consumer_var->name)) {
> +const size_t name_len = strlen(consumer_var->name);
> +
> +if (name_len >= name_buffer_size) {
> +   free(name_buffer);
> +
> +   name_buffer_size = name_len + 1;
> +   name_buffer = malloc(name_buffer_size);
> +   if (name_buffer == NULL) {
> +  valid = false;
> +  goto out;
> +   }
> +}
> +
> +consumer_name = (char *) name_buffer;
> +
> +char *s = strchr(consumer_var->name, '[');
> +if (s == NULL) {
> +   valid = false;
> +   goto out;
> +}
> +
> +char *t = strchr(s, ']');
> +if (t == NULL) {
> +   valid = false;
> +   goto out;
> +}
> +
> +assert(t[1] == '.' || t[1] == '[');
> +
> +const ptrdiff_t base_name_len = s - consumer_var->name;
> +
> +memcpy(consumer_name, consumer_var->name, base_name_len);
> +strcpy(consumer_name + base_name_len, t + 1);
> + }
> +
>   for (unsigned j = 0; j < num_outputs; j++) {
>  const gl_shader_variable *const var = outputs[j];
>
>  if (!var->explicit_location &&
> -strcmp(consumer_var->name, var->name) == 0) {
> +strcmp(consumer_name, var->name) == 0) {
> producer_var = var;
> match_index = j;
> break;
> @@ -1529,25 +1583,53 @@ validate_io(struct gl_shader_program *producer,
> * Note that location mismatches are detected by the loops above that
> * find the producer variable that goes with the consumer variable.
> */
> -  if (producer_var->type != consumer_var->type ||
> -  producer_var->interpolation != consumer_var->interpolation ||
> -  producer_var->precision != consumer_var->precision) {
> +  if (nonarray_stage_to_array_stage) {
> + if (!consumer_var->type->is_array() ||
> + consumer_var->type->fields.array != producer_var->type) {
> +valid = false;
> +goto out;
> + }
> +
> + 

[Mesa-dev] [PATCH v2 04/11] glsl: Pack integer and double varyings as flat even if interpolation mode is none

[Ian Romanick]

From: Ian Romanick 

v2: Also update varying_matches::compute_packing_class().  Suggested by
Timothy Arceri.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
Cc: "12.0" 
Cc: Gregory Hainaut 
Cc: Ilia Mirkin 
---
 src/compiler/glsl/ir.h  |  7 +++
 src/compiler/glsl/link_varyings.cpp |  3 ++-
 src/compiler/glsl/lower_packed_varyings.cpp | 11 ++-
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index 3629356..e5b8154 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -590,6 +590,13 @@ public:
   return this->u.state_slots;
}
 
+   inline bool is_interpolation_flat() const
+   {
+  return this->data.interpolation == INTERP_QUALIFIER_FLAT ||
+ this->type->contains_integer() ||
+ this->type->contains_double();
+   }
+
inline bool is_name_ralloced() const
{
   return this->name != ir_variable::tmp_name;
diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index ef8bdbe..84686ee 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -1610,7 +1610,8 @@ varying_matches::compute_packing_class(const ir_variable 
*var)
unsigned packing_class = var->data.centroid | (var->data.sample << 1) |
 (var->data.patch << 2);
packing_class *= 4;
-   packing_class += var->data.interpolation;
+   packing_class += var->is_interpolation_flat()
+  ? INTERP_QUALIFIER_FLAT : data.interpolation;
return packing_class;
 }
 
diff --git a/src/compiler/glsl/lower_packed_varyings.cpp 
b/src/compiler/glsl/lower_packed_varyings.cpp
index 130b8f6..9aa463c 100644
--- a/src/compiler/glsl/lower_packed_varyings.cpp
+++ b/src/compiler/glsl/lower_packed_varyings.cpp
@@ -273,11 +273,11 @@ lower_packed_varyings_visitor::run(struct gl_shader 
*shader)
  continue;
 
   /* This lowering pass is only capable of packing floats and ints
-   * together when their interpolation mode is "flat".  Therefore, to be
-   * safe, caller should ensure that integral varyings always use flat
-   * interpolation, even when this is not required by GLSL.
+   * together when their interpolation mode is "flat".  Treat integers as
+   * being flat when the interpolation mode is none.
*/
   assert(var->data.interpolation == INTERP_QUALIFIER_FLAT ||
+ var->data.interpolation == INTERP_QUALIFIER_NONE ||
  !var->type->contains_integer());
 
   /* Clone the variable for program resource list before
@@ -607,7 +607,7 @@ lower_packed_varyings_visitor::get_packed_varying_deref(
if (this->packed_varyings[slot] == NULL) {
   char *packed_name = ralloc_asprintf(this->mem_ctx, "packed:%s", name);
   const glsl_type *packed_type;
-  if (unpacked_var->data.interpolation == INTERP_QUALIFIER_FLAT)
+  if (unpacked_var->is_interpolation_flat())
  packed_type = glsl_type::ivec4_type;
   else
  packed_type = glsl_type::vec4_type;
@@ -627,7 +627,8 @@ lower_packed_varyings_visitor::get_packed_varying_deref(
   packed_var->data.centroid = unpacked_var->data.centroid;
   packed_var->data.sample = unpacked_var->data.sample;
   packed_var->data.patch = unpacked_var->data.patch;
-  packed_var->data.interpolation = unpacked_var->data.interpolation;
+  packed_var->data.interpolation = packed_type == glsl_type::ivec4_type
+ ? unsigned(INTERP_QUALIFIER_FLAT) : unpacked_var->data.interpolation;
   packed_var->data.location = location;
   packed_var->data.precision = unpacked_var->data.precision;
   packed_var->data.always_active_io = unpacked_var->data.always_active_io;
-- 
2.5.5

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

[Mesa-dev] [PATCH v2 03/11] mesa: Strip arrayness from interface block names in some IO validation

[Ian Romanick]

From: Ian Romanick 

Outputs from the vertex shader need to be able to match
per-vertex-arrayed inputs of later stages.  Acomplish this by stripping
one level of arrayness from the names and types of outputs going to a
per-vertex-arrayed stage.

v2: Add missing checks for TESS_EVAL->GEOMETRY.  Noticed by Timothy
Arceri.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
Cc: "12.0" 
Cc: Gregory Hainaut 
Cc: Ilia Mirkin 
---
 src/mesa/main/shader_query.cpp | 100 +
 1 file changed, 92 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 5956ce4..a6a0a2f 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -1385,13 +1385,26 @@ _mesa_get_program_resourceiv(struct gl_shader_program 
*shProg,
 
 static bool
 validate_io(struct gl_shader_program *producer,
-struct gl_shader_program *consumer)
+struct gl_shader_program *consumer,
+gl_shader_stage producer_stage,
+gl_shader_stage consumer_stage)
 {
if (producer == consumer)
   return true;
 
+   const bool nonarray_stage_to_array_stage =
+  (producer_stage == MESA_SHADER_VERTEX &&
+   (consumer_stage == MESA_SHADER_GEOMETRY ||
+consumer_stage == MESA_SHADER_TESS_CTRL ||
+consumer_stage == MESA_SHADER_TESS_EVAL)) ||
+  (producer_stage == MESA_SHADER_TESS_EVAL &&
+   consumer_stage == MESA_SHADER_GEOMETRY);
+
bool valid = true;
 
+   void *name_buffer = NULL;
+   size_t name_buffer_size = 0;
+
gl_shader_variable const **outputs =
   (gl_shader_variable const **) calloc(producer->NumProgramResourceList,
sizeof(gl_shader_variable *));
@@ -1463,11 +1476,52 @@ validate_io(struct gl_shader_program *producer,
 }
  }
   } else {
+ char *consumer_name = consumer_var->name;
+
+ if (nonarray_stage_to_array_stage &&
+ consumer_var->interface_type != NULL &&
+ consumer_var->interface_type->is_array() &&
+ !is_gl_identifier(consumer_var->name)) {
+const size_t name_len = strlen(consumer_var->name);
+
+if (name_len >= name_buffer_size) {
+   free(name_buffer);
+
+   name_buffer_size = name_len + 1;
+   name_buffer = malloc(name_buffer_size);
+   if (name_buffer == NULL) {
+  valid = false;
+  goto out;
+   }
+}
+
+consumer_name = (char *) name_buffer;
+
+char *s = strchr(consumer_var->name, '[');
+if (s == NULL) {
+   valid = false;
+   goto out;
+}
+
+char *t = strchr(s, ']');
+if (t == NULL) {
+   valid = false;
+   goto out;
+}
+
+assert(t[1] == '.' || t[1] == '[');
+
+const ptrdiff_t base_name_len = s - consumer_var->name;
+
+memcpy(consumer_name, consumer_var->name, base_name_len);
+strcpy(consumer_name + base_name_len, t + 1);
+ }
+
  for (unsigned j = 0; j < num_outputs; j++) {
 const gl_shader_variable *const var = outputs[j];
 
 if (!var->explicit_location &&
-strcmp(consumer_var->name, var->name) == 0) {
+strcmp(consumer_name, var->name) == 0) {
producer_var = var;
match_index = j;
break;
@@ -1529,25 +1583,53 @@ validate_io(struct gl_shader_program *producer,
* Note that location mismatches are detected by the loops above that
* find the producer variable that goes with the consumer variable.
*/
-  if (producer_var->type != consumer_var->type ||
-  producer_var->interpolation != consumer_var->interpolation ||
-  producer_var->precision != consumer_var->precision) {
+  if (nonarray_stage_to_array_stage) {
+ if (!consumer_var->type->is_array() ||
+ consumer_var->type->fields.array != producer_var->type) {
+valid = false;
+goto out;
+ }
+
+ if (consumer_var->interface_type != NULL) {
+if (!consumer_var->interface_type->is_array() ||
+consumer_var->interface_type->fields.array != 
producer_var->interface_type) {
+   valid = false;
+   goto out;
+}
+ } else if (producer_var->interface_type != NULL) {
+valid = false;
+goto out;
+ }
+  } else {
+ if (producer_var->type != consumer_var->type) {
+valid = false;
+goto out;
+ }
+
+ if (producer_var->interface_type != 

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Herring]

On Thu, Jun 16, 2016 at 12:09 PM, Rob Clark  wrote:
> On Thu, Jun 16, 2016 at 12:56 PM, Rob Herring  wrote:
>> On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
>>> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
 In the process of adding RGBX (XB24) format to mesa for Android, I
 started seeing a new problem that makes the UI stop updating. It
 happens about when the splash screen is stopped and the lock screen is
 displayed. The display flickers on mouse movement, and it looks like
 the screen is flipping to old buffers (like the splash screen after
 its process exited). It is working fine for freedreno AFAICT, but I am
 running into a problem with virgl. With virgl, I get the following
 error:

 vrend_create_surface: context error reported 1 "surfaceflinger"
 Illegal resource 1435
 vrend_report_buffer_error: context error reported 1 "surfaceflinger"
 Illegal command buffer 329729

 The addition of the pixel format changes the eglconfig used for the
 splash screen. If I force the splash screen eglconfig to have an alpha
 or draw one frame of the splash screen and exit early or disable the
 splash screen, everything seems fine though I have hit the problem
 rarely navigating around. I suspect this has nothing to do with the
 pixel format other than different buffer sizes cause buffers to get
 reused differently.

 Now I've started working on getting RPi3 and vc4 working, and it
 appears to have a similar problem. I'm getting these errors though
 things go haywire before getting any error message:

 [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 
 0: 4
>>>
>>> at least in the vc4 case, I suspect you need a similar bit of winsys
>>> magic to ensure the same pipe_screen is returned for any given drm
>>> device fd.  (Or did someone already add that?)
>>
>> That problem should be gone with GBM gralloc, right?
>
> *maaaybe*..
>
> It, like the gralloc-drm-pipe approach, means we have a pipe_screen
> (vs. the other drm-gralloc backends which were using libdrm_xyz
> directly), so it was going through the logic to avoid duplicate
> pipe_screen's (for the drivers which had that).
>
> Maybe w/ gbm, everything ends up sharing the same pipe_screen?  I'm
> not really sure, since I guess both GL and gralloc are creating a gbm
> device?
>
> I guess easy enough to put some debug print in vc4_screen_create() to
> confirm.  But the sort of errors you are seeing make me suspicious.

Uhh, well looks like that is a problem for vc4:

01-01 00:00:07.295   127   127 W VC4 : vc4_screen_create
01-01 00:00:07.334   127   127 W VC4 : vc4_screen_create
01-01 00:00:08.349   205   223 W VC4 : vc4_screen_create
01-01 00:00:08.352   205   223 W VC4 : vc4_screen_create
01-01 00:00:35.467   437   488 W VC4 : vc4_screen_create
01-01 00:00:35.477   437   488 W VC4 : vc4_screen_create
01-01 00:00:39.041   511   511 W VC4 : vc4_screen_create
01-01 00:00:43.385   511   798 W VC4 : vc4_screen_create
01-01 00:00:44.135   718   718 W VC4 : vc4_screen_create
01-01 00:00:44.202   718   923 W VC4 : vc4_screen_create

> Possibly the "libdrm equivalent" part of vc4 needs to do more to avoid
> re-importing the same handle multiple times?

Maybe time for the common implementation.

This doesn't explain the virgl case though as I already fixed this
problem. The log below is from virgl.

>>> In both virgl and vc4 case, you need to make sure that shared
>>> (exported/imported) buffers don't end up in the bo cache.
>>
>> I've disabled the cache (in the gallium drv, right?) and still see problems.
>>
>> I am seeing a double GEM_CLOSE. I'm not sure how that is happening.
>> One of them must be hwc releasing an imported buffer, but it's all in
>> the same thread.
>>
>> [7.024495] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret = 0,
>> DRM_IOCTL_GEM_CLOSE
>> [7.025379] [drm] pid=1310, dev=0xe280, auth=0, handle=23, ret = 0,
>> DRM_IOCTL_PRIME_FD_TO_HANDLE
>> [7.026663] [drm] pid=1310, dev=0xe280, auth=0, handle=10, ret = 0,
>> DRM_IOCTL_GEM_CLOSE
>> [7.027343] [drm] pid=1310, dev=0xe200, auth=1, handle=23, ret = 0,
>> DRM_IOCTL_PRIME_FD_TO_HANDLE
>> [7.035098] [drm] pid=1333, dev=0xe200, auth=1, handle=1, ret = 0,
>> DRM_IOCTL_GEM_CLOSE
>> [7.036093] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret =
>> -22, DRM_IOCTL_GEM_CLOSE
>
> sure would be nice if there was a dump_stack() that showed you the
> userspace stack too ;-)
>
> (but maybe dumb question, is pid unique per process or thread?)

Ignoring namespaces, pids are globally unique.

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

Re: [Mesa-dev] [PATCH 21/64] isl/state: Set the IntegerSurfaceFormat bit on Haswell

[Jason Ekstrand]

On Thu, Jun 16, 2016 at 11:26 AM, Chad Versace 
wrote:

> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > This fixes 688 Vulkan CTS tests on Haswell.
>
> Whoo! Bugfixes!
>
> The PRM states that, on HSW, you also need to program
> SAMPLER_BORDER_COLOR_STATE correctly for integer formats. I suspect that
> the CTS tests may be passing by luck.
>
> See this encouraging comment in brw_sampler_state.c:
>
>   /* Haswell's integer border color support is completely insane:
>* SAMPLER_BORDER_COLOR_STATE is 20 DWords.  The first four are
>* for float colors.  The next 12 DWords are MBZ and only exist to
>* pad it out to a 64 byte cacheline boundary.  DWords 16-19 then
>* contain integer colors; these are only used if SURFACE_STATE
>* has the "Integer Surface Format" bit set.  Even then, the
>* arrangement of the RGBA data devolves into madness.
>*/
>

Oh, I'm well aware of the insanity there!  I reviewed those patches.


>
> Anyway, this patch is
> Reviewed-by: Chad Versace 
> and please add a TODO somewhere for SAMPLER_BORDER_COLOR_STATE.
>

I'm not quite sure where to put that TODO...  Sadly, integer border color
will probably never work properly on Haswell :-(
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/64] i965: Drop Max3DTextureLevels to 512 on Sandy Bridge and prior

[Jason Ekstrand]

On Thu, Jun 16, 2016 at 11:43 AM, Ian Romanick  wrote:

> On 06/11/2016 09:02 AM, Jason Ekstrand wrote:
> > The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to
> be
> > set to the depth of a 3-D texture when rendering.  Unfortunatley, that
>  Unfortunately
>
> > field is only 9 bits on Sandy Bridge and prior so we can't actually bind
> > a 3-D texturing for rendering if it has depth > 512.  On Ivy Bridge, this
> > field was bumpped to 11 bits so we can go all the way up to 2048.
> bumped
>
> > Cc: "11.1 11.2 12.0" 
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> > index 7bbc128..3b11bef 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -467,7 +467,10 @@ brw_initialize_context_constants(struct brw_context
> *brw)
> > ctx->Const.MaxImageUnits = MAX_IMAGE_UNITS;
> > ctx->Const.MaxRenderbufferSize = 8192;
> > ctx->Const.MaxTextureLevels = MIN2(14 /* 8192 */,
> MAX_TEXTURE_LEVELS);
> > -   ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> > +   if (brw->gen >= 7)
> > +  ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> > +   else
> > +  ctx->Const.Max3DTextureLevels = 10; /* 512 */
>
> This should use ?: like MaxArrayTextureLayers below.
>
> This was increased from 512 to 2048 in 2014 in commit 06b047eb.  There
> was some assertion in the commit message that the Windows driver was
> already advertising 2048.  There is no mention, however, of which
> hardware the Windows driver was checked on.  In the related bug report
> (https://bugs.freedesktop.org/show_bug.cgi?id=74130), Ken says, "All
> Gen4+ systems support 2048x2048 3D textures, so we could just bump the
> limit."
>
> It sounds like this may be a temporary fix, and we need a work around
> for rendering to slices > 9?
>

It's a bit more subtle than that, I'm afraid.  The current gen4 render
target setup code (which isn't used on SNB) can handle rendering to any
layer of a 3-D texture regardless of size and SNB could be fixed up to do
the same.  The problem is when you use layered rendering.  When doing
layered rendering, we can only access at most 512 layers.  This means that
we need to either limit the texture size or we need to give the user an
incomplete framebuffer if they try and do layered rendering on a 3-D
texture with more than 512 slices.  That's kind-of a nasty edge for
applications to hit.

--Jason


>
> > ctx->Const.MaxCubeTextureLevels = 14; /* 8192 */
> > ctx->Const.MaxArrayTextureLayers = brw->gen >= 7 ? 2048 : 512;
> > ctx->Const.MaxTextureMbytes = 1536;
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Trouble with missing git_sha1.h when building from a fresh tree

[Haixia Shi]

Posting a question in case someone already know the issue.

I'm observing "missing git_sha1.h" errors sometime after Emil's git_sha1.h
patches by May 31st. This is not fixed at TOT with the latest patches on
Makefile.am.

The problem only happens if src/git_sha1.h doesn't exist already. I just
need to put a dummy git_sha1.h file there to work around the error.

There's a similar bug filed (
https://bugs.freedesktop.org/show_bug.cgi?id=50976) but the fix for that
one patches src/Makefile directly, whereas my build flow only requires
Makefile.am.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/64] i965/fs: Use a default Y coordinate of 0 for TXF on gen9+

[Ian Romanick]

This patch is

Reviewed-by: Ian Romanick 

On 06/11/2016 09:02 AM, Jason Ekstrand wrote:
> Previously, we were incrementing length but not actually putting anything
> in the Y coordinate.  This meant that 1-D TXF operations had a garbage
> array index.  If the surface is emitted as 1-D non-array, the coordinate
> gets discarded and it works fine.  If it happens to be bound as an array
> surface, it may count as an out-of-bounds array access and you get zero.
> 
> Cc: "11.1 11.2 12.0" 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 4b29ee5..5d3d4d0 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -4274,6 +4274,8 @@ lower_sampler_logical_send_gen7(const fs_builder , 
> fs_inst *inst, opcode op,
>   if (coord_components >= 2) {
>  bld.MOV(retype(sources[length], BRW_REGISTER_TYPE_D),
>  offset(coordinate, bld, 1));
> + } else {
> +sources[length] = brw_imm_d(0);
>   }
>   length++;
>}
> 

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

Re: [Mesa-dev] [PATCH 01/64] i965: Drop Max3DTextureLevels to 512 on Sandy Bridge and prior

[Ian Romanick]

On 06/11/2016 09:02 AM, Jason Ekstrand wrote:
> The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to be
> set to the depth of a 3-D texture when rendering.  Unfortunatley, that
 Unfortunately

> field is only 9 bits on Sandy Bridge and prior so we can't actually bind
> a 3-D texturing for rendering if it has depth > 512.  On Ivy Bridge, this
> field was bumpped to 11 bits so we can go all the way up to 2048.
bumped

> Cc: "11.1 11.2 12.0" 
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 7bbc128..3b11bef 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -467,7 +467,10 @@ brw_initialize_context_constants(struct brw_context *brw)
> ctx->Const.MaxImageUnits = MAX_IMAGE_UNITS;
> ctx->Const.MaxRenderbufferSize = 8192;
> ctx->Const.MaxTextureLevels = MIN2(14 /* 8192 */, MAX_TEXTURE_LEVELS);
> -   ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> +   if (brw->gen >= 7)
> +  ctx->Const.Max3DTextureLevels = 12; /* 2048 */
> +   else
> +  ctx->Const.Max3DTextureLevels = 10; /* 512 */

This should use ?: like MaxArrayTextureLayers below.

This was increased from 512 to 2048 in 2014 in commit 06b047eb.  There
was some assertion in the commit message that the Windows driver was
already advertising 2048.  There is no mention, however, of which
hardware the Windows driver was checked on.  In the related bug report
(https://bugs.freedesktop.org/show_bug.cgi?id=74130), Ken says, "All
Gen4+ systems support 2048x2048 3D textures, so we could just bump the
limit."

It sounds like this may be a temporary fix, and we need a work around
for rendering to slices > 9?

> ctx->Const.MaxCubeTextureLevels = 14; /* 8192 */
> ctx->Const.MaxArrayTextureLayers = brw->gen >= 7 ? 2048 : 512;
> ctx->Const.MaxTextureMbytes = 1536;
> 

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

Re: [Mesa-dev] [PATCH 21/64] isl/state: Set the IntegerSurfaceFormat bit on Haswell

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> This fixes 688 Vulkan CTS tests on Haswell.

Whoo! Bugfixes!

The PRM states that, on HSW, you also need to program
SAMPLER_BORDER_COLOR_STATE correctly for integer formats. I suspect that
the CTS tests may be passing by luck.

See this encouraging comment in brw_sampler_state.c:

  /* Haswell's integer border color support is completely insane:
   * SAMPLER_BORDER_COLOR_STATE is 20 DWords.  The first four are
   * for float colors.  The next 12 DWords are MBZ and only exist to
   * pad it out to a 64 byte cacheline boundary.  DWords 16-19 then
   * contain integer colors; these are only used if SURFACE_STATE
   * has the "Integer Surface Format" bit set.  Even then, the
   * arrangement of the RGBA data devolves into madness.
   */

Anyway, this patch is
Reviewed-by: Chad Versace 
and please add a TODO somewhere for SAMPLER_BORDER_COLOR_STATE.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/64] isl/state: Refactor the setup of clear colors

[Chad Versace]

On Thu 16 Jun 2016, Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 11:05 AM, Chad Versace 
> wrote:
> 
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > This commit switches clear colors to use #if's instead of a C if.  This
> > > lets us properly handle SNB where the clear color field doesn't exist.
> > > ---
> > >  src/intel/isl/isl_surface_state.c | 44
> > +++
> > >  1 file changed, 22 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/src/intel/isl/isl_surface_state.c
> > b/src/intel/isl/isl_surface_state.c
> > > index db90936..aa720d8 100644
> > > --- a/src/intel/isl/isl_surface_state.c
> > > +++ b/src/intel/isl/isl_surface_state.c
> > > @@ -372,31 +372,31 @@ isl_genX(surf_fill_state_s)(const struct
> > isl_device *dev, void *state,
> > > }
> > >  #endif
> > >
> > > -   if (GEN_GEN <= 8) {
> > > -  /* Prior to Sky Lake, we only have one bit for the clear color
> > which
> > > -   * gives us 0 or 1 in whatever the surface's format happens to be.
> > > -   */
> > > -  if (isl_format_has_int_channel(info->view->format)) {
> > > - for (unsigned i = 0; i < 4; i++) {
> > > -assert(info->clear_color.u32[i] == 0 ||
> > > -   info->clear_color.u32[i] == 1);
> > > - }
> > > -  } else {
> > > - for (unsigned i = 0; i < 4; i++) {
> > > -assert(info->clear_color.f32[i] == 0.0f ||
> > > -   info->clear_color.f32[i] == 1.0f);
> > > - }
> > > +#if GEN_GEN >= 9
> > > +   s.RedClearColor = info->clear_color.u32[0];
> > > +   s.GreenClearColor = info->clear_color.u32[1];
> > > +   s.BlueClearColor = info->clear_color.u32[2];
> > > +   s.AlphaClearColor = info->clear_color.u32[3];
> >
> > The gen9 block looks good.
> >
> > > +#elif GEN_GEN >= 7
> > > +   /* Prior to Sky Lake, we only have one bit for the clear color which
> > > +* gives us 0 or 1 in whatever the surface's format happens to be.
> > > +*/
> > > +   if (isl_format_has_int_channel(info->view->format)) {
> > > +  for (unsigned i = 0; i < 4; i++) {
> > > + assert(info->clear_color.u32[i] == 0 ||
> > > +info->clear_color.u32[i] == 1);
> > >}
> > > -  s.RedClearColor = info->clear_color.u32[0] != 0;
> > > -  s.GreenClearColor = info->clear_color.u32[1] != 0;
> > > -  s.BlueClearColor = info->clear_color.u32[2] != 0;
> > > -  s.AlphaClearColor = info->clear_color.u32[3] != 0;
> > > } else {
> > > -  s.RedClearColor = info->clear_color.u32[0];
> > > -  s.GreenClearColor = info->clear_color.u32[1];
> > > -  s.BlueClearColor = info->clear_color.u32[2];
> > > -  s.AlphaClearColor = info->clear_color.u32[3];
> > > +  for (unsigned i = 0; i < 4; i++) {
> > > + assert(info->clear_color.f32[i] == 0.0f ||
> > > +info->clear_color.f32[i] == 1.0f);
> > > +  }
> > > }
> > > +   s.RedClearColor = info->clear_color.u32[0] != 0;
> > > +   s.GreenClearColor = info->clear_color.u32[1] != 0;
> > > +   s.BlueClearColor = info->clear_color.u32[2] != 0;
> > > +   s.AlphaClearColor = info->clear_color.u32[3] != 0;
> >
> > This block looks broken, both pre- and post-patch. Is this code actually
> > used anywhere in the Vulkan driver? I expect not, as the driver doesn't
> > use the CCS yet.
> >
> > In the for loop, the code asserts clear_color.f32[i] is 0.0f or 1.0f.
> > I believe the assignment expressions should also use f32, not u32. That
> > is,
> >
> > s.RedClearColor = info->clear_color.f32[0] != 0.0f;
> > s.GreenClearColor = info->clear_color.f32[1] != 0.0f;
> > s.BlueClearColor = info->clear_color.f32[2] != 0.0f;
> > s.AlphaClearColor = info->clear_color.f32[3] != 0.0f;
> >
> 
> Right.  That's probably more correct but given that 0.0f is 0u as bits, I
> don't know if it actually matters.  Maybe for -0?

Yes, we should do it for -0. The user inputs to glClearColor may be
calculated in convoluted ways that produce -0.

Also, I think
s.RedClearColor = info->clear_color.f32[0] == 1.0f
is clearer, but it's not important.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/vdpau: use bicubic filter for scaling

[Nayan Deshmukh]

v2: fix a typo and add a newline to code

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/state_trackers/vdpau/mixer.c | 53 +---
 src/gallium/state_trackers/vdpau/vdpau_private.h |  6 +++
 2 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 65c3ce2..751c7e5 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -82,7 +82,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -110,6 +109,9 @@ vlVdpVideoMixerCreate(VdpDevice device,
  vmixer->luma_key.supported = true;
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
+ vmixer->bicubic.supported = true;
+ break;
   default: goto no_params;
   }
}
@@ -202,6 +204,11 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
   vl_matrix_filter_cleanup(vmixer->sharpness.filter);
   FREE(vmixer->sharpness.filter);
}
+
+   if (vmixer->bicubic.filter) {
+  vl_bicubic_filter_cleanup(vmixer->bicubic.filter);
+  FREE(vmixer->bicubic.filter);
+   }
pipe_mutex_unlock(vmixer->device->mutex);
DeviceReference(>device, NULL);
 
@@ -344,7 +351,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
}
 
vl_compositor_set_dst_clip(>cstate, RectToPipe(destination_rect, 
));
-   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter)
+   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter && 
!vmixer->bicubic.filter)
   vlVdpSave4DelayedRendering(vmixer->device, destination_surface, 
>cstate);
else {
   vl_compositor_render(>cstate, compositor, dst->surface, 
>dirty_area, true);
@@ -359,6 +366,10 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   if (vmixer->sharpness.filter)
  vl_matrix_filter_render(vmixer->sharpness.filter,
  dst->sampler_view, dst->surface);
+
+  if (vmixer->bicubic.filter)
+ vl_bicubic_filter_render(vmixer->bicubic.filter,
+ dst->sampler_view, dst->surface);
}
pipe_mutex_unlock(vmixer->device->mutex);
 
@@ -461,6 +472,28 @@ vlVdpVideoMixerUpdateSharpnessFilter(vlVdpVideoMixer 
*vmixer)
 }
 
 /**
+ * Update the bicubic filter
+ */
+static void
+vlVdpVideoMixerUpdateBicubicFilter(vlVdpVideoMixer *vmixer)
+{
+   assert(vmixer);
+
+   /* if present remove the old filter first */
+   if (vmixer->bicubic.filter) {
+  vl_bicubic_filter_cleanup(vmixer->bicubic.filter);
+  FREE(vmixer->bicubic.filter);
+  vmixer->bicubic.filter = NULL;
+   }
+   /* and create a new filter as needed */
+   if (vmixer->bicubic.enabled) {
+  vmixer->bicubic.filter = MALLOC(sizeof(struct vl_bicubic_filter));
+  vl_bicubic_filter_init(vmixer->bicubic.filter, vmixer->device->context,
+vmixer->video_width, vmixer->video_height);
+   }
+}
+
+/**
  * Retrieve whether features were requested at creation time.
  */
 VdpStatus
@@ -483,7 +516,6 @@ vlVdpVideoMixerGetFeatureSupport(VdpVideoMixer mixer,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -512,6 +544,10 @@ vlVdpVideoMixerGetFeatureSupport(VdpVideoMixer mixer,
  feature_supports[i] = vmixer->luma_key.supported;
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
+ feature_supports[i] = vmixer->bicubic.supported;
+ break;
+
   default:
  return VDP_STATUS_INVALID_VIDEO_MIXER_FEATURE;
   }
@@ -544,7 +580,6 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -578,6 +613,11 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
  vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
  break;
 
+  case 

Re: [Mesa-dev] [PATCH 20/64] isl/format: Mark R9G9B9E5 as containing 9-bit unsigned float channels

[Chad Versace]

Patches 18,19,20 are
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH 17/64] isl/state: Refactor the setup of clear colors

[Jason Ekstrand]

On Thu, Jun 16, 2016 at 11:05 AM, Chad Versace 
wrote:

> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > This commit switches clear colors to use #if's instead of a C if.  This
> > lets us properly handle SNB where the clear color field doesn't exist.
> > ---
> >  src/intel/isl/isl_surface_state.c | 44
> +++
> >  1 file changed, 22 insertions(+), 22 deletions(-)
> >
> > diff --git a/src/intel/isl/isl_surface_state.c
> b/src/intel/isl/isl_surface_state.c
> > index db90936..aa720d8 100644
> > --- a/src/intel/isl/isl_surface_state.c
> > +++ b/src/intel/isl/isl_surface_state.c
> > @@ -372,31 +372,31 @@ isl_genX(surf_fill_state_s)(const struct
> isl_device *dev, void *state,
> > }
> >  #endif
> >
> > -   if (GEN_GEN <= 8) {
> > -  /* Prior to Sky Lake, we only have one bit for the clear color
> which
> > -   * gives us 0 or 1 in whatever the surface's format happens to be.
> > -   */
> > -  if (isl_format_has_int_channel(info->view->format)) {
> > - for (unsigned i = 0; i < 4; i++) {
> > -assert(info->clear_color.u32[i] == 0 ||
> > -   info->clear_color.u32[i] == 1);
> > - }
> > -  } else {
> > - for (unsigned i = 0; i < 4; i++) {
> > -assert(info->clear_color.f32[i] == 0.0f ||
> > -   info->clear_color.f32[i] == 1.0f);
> > - }
> > +#if GEN_GEN >= 9
> > +   s.RedClearColor = info->clear_color.u32[0];
> > +   s.GreenClearColor = info->clear_color.u32[1];
> > +   s.BlueClearColor = info->clear_color.u32[2];
> > +   s.AlphaClearColor = info->clear_color.u32[3];
>
> The gen9 block looks good.
>
> > +#elif GEN_GEN >= 7
> > +   /* Prior to Sky Lake, we only have one bit for the clear color which
> > +* gives us 0 or 1 in whatever the surface's format happens to be.
> > +*/
> > +   if (isl_format_has_int_channel(info->view->format)) {
> > +  for (unsigned i = 0; i < 4; i++) {
> > + assert(info->clear_color.u32[i] == 0 ||
> > +info->clear_color.u32[i] == 1);
> >}
> > -  s.RedClearColor = info->clear_color.u32[0] != 0;
> > -  s.GreenClearColor = info->clear_color.u32[1] != 0;
> > -  s.BlueClearColor = info->clear_color.u32[2] != 0;
> > -  s.AlphaClearColor = info->clear_color.u32[3] != 0;
> > } else {
> > -  s.RedClearColor = info->clear_color.u32[0];
> > -  s.GreenClearColor = info->clear_color.u32[1];
> > -  s.BlueClearColor = info->clear_color.u32[2];
> > -  s.AlphaClearColor = info->clear_color.u32[3];
> > +  for (unsigned i = 0; i < 4; i++) {
> > + assert(info->clear_color.f32[i] == 0.0f ||
> > +info->clear_color.f32[i] == 1.0f);
> > +  }
> > }
> > +   s.RedClearColor = info->clear_color.u32[0] != 0;
> > +   s.GreenClearColor = info->clear_color.u32[1] != 0;
> > +   s.BlueClearColor = info->clear_color.u32[2] != 0;
> > +   s.AlphaClearColor = info->clear_color.u32[3] != 0;
>
> This block looks broken, both pre- and post-patch. Is this code actually
> used anywhere in the Vulkan driver? I expect not, as the driver doesn't
> use the CCS yet.
>
> In the for loop, the code asserts clear_color.f32[i] is 0.0f or 1.0f.
> I believe the assignment expressions should also use f32, not u32. That
> is,
>
> s.RedClearColor = info->clear_color.f32[0] != 0.0f;
> s.GreenClearColor = info->clear_color.f32[1] != 0.0f;
> s.BlueClearColor = info->clear_color.f32[2] != 0.0f;
> s.AlphaClearColor = info->clear_color.f32[3] != 0.0f;
>

Right.  That's probably more correct but given that 0.0f is 0u as bits, I
don't know if it actually matters.  Maybe for -0?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/64] isl/state: Refactor the setup of clear colors

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> This commit switches clear colors to use #if's instead of a C if.  This
> lets us properly handle SNB where the clear color field doesn't exist.
> ---
>  src/intel/isl/isl_surface_state.c | 44 
> +++
>  1 file changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index db90936..aa720d8 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -372,31 +372,31 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> *dev, void *state,
> }
>  #endif
>  
> -   if (GEN_GEN <= 8) {
> -  /* Prior to Sky Lake, we only have one bit for the clear color which
> -   * gives us 0 or 1 in whatever the surface's format happens to be.
> -   */
> -  if (isl_format_has_int_channel(info->view->format)) {
> - for (unsigned i = 0; i < 4; i++) {
> -assert(info->clear_color.u32[i] == 0 ||
> -   info->clear_color.u32[i] == 1);
> - }
> -  } else {
> - for (unsigned i = 0; i < 4; i++) {
> -assert(info->clear_color.f32[i] == 0.0f ||
> -   info->clear_color.f32[i] == 1.0f);
> - }
> +#if GEN_GEN >= 9
> +   s.RedClearColor = info->clear_color.u32[0];
> +   s.GreenClearColor = info->clear_color.u32[1];
> +   s.BlueClearColor = info->clear_color.u32[2];
> +   s.AlphaClearColor = info->clear_color.u32[3];

The gen9 block looks good.

> +#elif GEN_GEN >= 7
> +   /* Prior to Sky Lake, we only have one bit for the clear color which
> +* gives us 0 or 1 in whatever the surface's format happens to be.
> +*/
> +   if (isl_format_has_int_channel(info->view->format)) {
> +  for (unsigned i = 0; i < 4; i++) {
> + assert(info->clear_color.u32[i] == 0 ||
> +info->clear_color.u32[i] == 1);
>}
> -  s.RedClearColor = info->clear_color.u32[0] != 0;
> -  s.GreenClearColor = info->clear_color.u32[1] != 0;
> -  s.BlueClearColor = info->clear_color.u32[2] != 0;
> -  s.AlphaClearColor = info->clear_color.u32[3] != 0;
> } else {
> -  s.RedClearColor = info->clear_color.u32[0];
> -  s.GreenClearColor = info->clear_color.u32[1];
> -  s.BlueClearColor = info->clear_color.u32[2];
> -  s.AlphaClearColor = info->clear_color.u32[3];
> +  for (unsigned i = 0; i < 4; i++) {
> + assert(info->clear_color.f32[i] == 0.0f ||
> +info->clear_color.f32[i] == 1.0f);
> +  }
> }
> +   s.RedClearColor = info->clear_color.u32[0] != 0;
> +   s.GreenClearColor = info->clear_color.u32[1] != 0;
> +   s.BlueClearColor = info->clear_color.u32[2] != 0;
> +   s.AlphaClearColor = info->clear_color.u32[3] != 0;

This block looks broken, both pre- and post-patch. Is this code actually
used anywhere in the Vulkan driver? I expect not, as the driver doesn't
use the CCS yet.

In the for loop, the code asserts clear_color.f32[i] is 0.0f or 1.0f.
I believe the assignment expressions should also use f32, not u32. That
is,

s.RedClearColor = info->clear_color.f32[0] != 0.0f;
s.GreenClearColor = info->clear_color.f32[1] != 0.0f;
s.BlueClearColor = info->clear_color.f32[2] != 0.0f;
s.AlphaClearColor = info->clear_color.f32[3] != 0.0f;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 16/64] isl/state: Refactor the per-gen isl_to_gen_h/valign tables

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> This moves the #if's around so that halign and valign have different sets
> of #if conditions.  This also prepares us for SNB because isl_to_gen_halign
> is not defined at all on gen6.
> ---
>  src/intel/isl/isl_surface_state.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)

Patch 16 is
Reviewed-by: Chad Versace 


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

Re: [Mesa-dev] [PATCH 14/64] isl/state: Put pitch calculations together

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl_surface_state.c | 42 
> +++
>  1 file changed, 20 insertions(+), 22 deletions(-)

Patch 14 is
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH 15/64] isl/state: Return an extent3d from the halign/valign helper

[Chad Versace]

On Thu 16 Jun 2016, Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 10:39 AM, Chad Versace 
> wrote:
> 
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > ---
> > >  src/intel/isl/isl_surface_state.c | 28 
> > >  1 file changed, 8 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/src/intel/isl/isl_surface_state.c
> > b/src/intel/isl/isl_surface_state.c
> > > index 50570aa..1e94e60 100644
> > > --- a/src/intel/isl/isl_surface_state.c
> > > +++ b/src/intel/isl/isl_surface_state.c
> > > @@ -110,9 +110,8 @@ get_surftype(enum isl_surf_dim dim,
> > isl_surf_usage_flags_t usage)
> > >  /*
> > >   * Get the values to pack into
> > RENDER_SUFFACE_STATE.SurfaceHorizontalAlignment
> > >   * and SurfaceVerticalAlignment.
> > >   */
> > > -static void
> > > -get_halign_valign(const struct isl_surf *surf,
> > > -  uint32_t *halign, uint32_t *valign)
> > > +static struct isl_extent3d
> > > +get_image_alignment(const struct isl_surf *surf)
> >
> >
> > The function comment is incorrect post-patch. It should say something to
> > the tune of "Returns indices into isl_to_gen_halign, isl_to_gen_valign".
> > Specifically, the function comment needs to clarify (with as few words
> > as possible) that the units of the returned extent is neither samples,
> > pixels, nor elements, but something entirely different--array indices--
> > because it's not really an extent at all.
> >
> 
> Right.  It's the "logical" halign/valign values not the actual hardware
> enums.

But even the term "logical values" is overly ambiguous. Logical values
of *what*? On some gens, the returned value is in units of surface
samples; other gens, surface elements. So, in effect, the returned value
is a *unitless* array index.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/64] isl/state: Remove some unused fields

[Chad Versace]

On Thu 16 Jun 2016, Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 10:14 AM, Chad Versace 
> wrote:
> 
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > They're already zero-initialized and we have no plans of doing anything
> > > more interesting with them.
> > > ---
> > >  src/intel/isl/isl_surface_state.c | 9 -
> > >  1 file changed, 9 deletions(-)
> >
> >
> >
> > > @@ -261,12 +258,6 @@ isl_genX(surf_fill_state_s)(const struct isl_device
> > *dev, void *state,
> > > s.MultisampledSurfaceStorageFormat =
> > >isl_to_gen_multisample_layout[info->surf->msaa_layout];
> > > s.NumberofMultisamples = ffs(info->surf->samples) - 1;
> > > -   s.MultisamplePositionPaletteIndex = 0; /* UNUSED */
> > > -
> > > -   s.XOffset = 0;
> > > -   s.YOffset = 0;
> >
> > Wait. Seriously? i965 no longer uses XOffset/YOffset on *any* gen!?!?!?
> > When did that happen? I've been waiting for years for i965 to stop using
> > XOffset/YOffset on old hardware, but obviously I wasn't paying enough
> > attention to the git logs.
> >
> 
> Nope.  Further on I add them back in for real.

I haven't yet reached the patch that adds them back. Be aware that these
fields are buggy on Haswell.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/1] r600: Enable FMA on chips that support it

[Jan Vesely]

On Thu, 2016-06-16 at 00:47 +0200, Glenn Kennard wrote:
> On Wed, 15 Jun 2016 20:13:13 +0200, Jan Vesely  u> wrote:
> 
> > 
> > Signed-off-by: Jan Vesely 
> > ---
> > Untested (I don't have the required hw)
> > 
> >  src/gallium/drivers/r600/r600_pipe.c   | 5 -
> >  src/gallium/drivers/r600/r600_shader.c | 2 +-
> >  2 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/r600/r600_pipe.c
> > b/src/gallium/drivers/r600/r600_pipe.c
> > index a49b00f..49c3e1d 100644
> > --- a/src/gallium/drivers/r600/r600_pipe.c
> > +++ b/src/gallium/drivers/r600/r600_pipe.c
> > @@ -548,7 +548,6 @@ static int r600_get_shader_param(struct
> > pipe_screen* pscreen, unsigned shader, e
> >     return 0;
> >     case PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED:
> >     case PIPE_SHADER_CAP_TGSI_DFRACEXP_DLDEXP_SUPPORTED:
> > -   case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED:
> >     case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
> >     case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
> >     return 0;
> > @@ -558,6 +557,10 @@ static int r600_get_shader_param(struct
> > pipe_screen* pscreen, unsigned shader, e
> >      *https://bugs.freedesktop.org/show_bug.cgi?id
> > =86720
> >      */
> >     return 255;
> > +   case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED:
> > +   // Enable on CYPRESS(EG) and CAYMAN(NI)
> > +   return rscreen->b.family == CHIP_CYPRESS ||
> > +      rscreen->b.family == CHIP_CAYMAN;
> >     }
> >     return 0;
> >  }
> > diff --git a/src/gallium/drivers/r600/r600_shader.c
> > b/src/gallium/drivers/r600/r600_shader.c
> > index 101f666..35019e3 100644
> > --- a/src/gallium/drivers/r600/r600_shader.c
> > +++ b/src/gallium/drivers/r600/r600_shader.c
> > @@ -8917,7 +8917,7 @@ static const struct
> > r600_shader_tgsi_instruction r600_shader_tgsi_instruction[]
> >     [TGSI_OPCODE_MAD]   = { ALU_OP3_MULADD, tgsi_op3},
> >     [TGSI_OPCODE_SUB]   = { ALU_OP2_ADD, tgsi_op2},
> >     [TGSI_OPCODE_LRP]   = { ALU_OP0_NOP, tgsi_lrp},
> > -   [TGSI_OPCODE_FMA]   = { ALU_OP0_NOP,
> > tgsi_unsupported},
> > +   [TGSI_OPCODE_FMA]   = { ALU_OP3_FMA, tgsi_op3},
> >     [TGSI_OPCODE_SQRT]  = { ALU_OP1_SQRT_IEEE,
> > tgsi_trans_srcx_replicate},
> >     [TGSI_OPCODE_DP2A]  = { ALU_OP0_NOP,
> > tgsi_unsupported},
> >     [22]= { ALU_OP0_NOP,
> > tgsi_unsupported},
> You probably meant to add the opcode to the
> eg_shader_tgsi_instruction and cm_shader_tgsi_instruction opcode
> tables rather than the R600/R700 one?
> 
> 
> I'll also note in passing that FMA on CYPRESS/HEMLOCK has an issue
> rate of 4/cycle vs MULADD 5/cycle since FMA cannot be issued in the
> 't' slot,
> may or may not affect performance depending on if the GLSL front end
> decides to use fma for mul+add operations. On Cayman/Aruba they are
> the same rate.

since FMA is only available on DP parts I'd expect the FMA rate to be
that of DP operations (double ops take two slots, but the issue rate is
usually lower than 1/2). I don't really know how the EG/CM pipeline
handles hazards.

Jan

> 
> 
> /Glenn


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

Re: [Mesa-dev] [PATCH 15/64] isl/state: Return an extent3d from the halign/valign helper

[Jason Ekstrand]

On Thu, Jun 16, 2016 at 10:39 AM, Chad Versace 
wrote:

> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > ---
> >  src/intel/isl/isl_surface_state.c | 28 
> >  1 file changed, 8 insertions(+), 20 deletions(-)
> >
> > diff --git a/src/intel/isl/isl_surface_state.c
> b/src/intel/isl/isl_surface_state.c
> > index 50570aa..1e94e60 100644
> > --- a/src/intel/isl/isl_surface_state.c
> > +++ b/src/intel/isl/isl_surface_state.c
> > @@ -110,9 +110,8 @@ get_surftype(enum isl_surf_dim dim,
> isl_surf_usage_flags_t usage)
> >  /*
> >   * Get the values to pack into
> RENDER_SUFFACE_STATE.SurfaceHorizontalAlignment
> >   * and SurfaceVerticalAlignment.
> >   */
> > -static void
> > -get_halign_valign(const struct isl_surf *surf,
> > -  uint32_t *halign, uint32_t *valign)
> > +static struct isl_extent3d
> > +get_image_alignment(const struct isl_surf *surf)
>
>
> The function comment is incorrect post-patch. It should say something to
> the tune of "Returns indices into isl_to_gen_halign, isl_to_gen_valign".
> Specifically, the function comment needs to clarify (with as few words
> as possible) that the units of the returned extent is neither samples,
> pixels, nor elements, but something entirely different--array indices--
> because it's not really an extent at all.
>

Right.  It's the "logical" halign/valign values not the actual hardware
enums.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 15/64] isl/state: Return an extent3d from the halign/valign helper

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl_surface_state.c | 28 
>  1 file changed, 8 insertions(+), 20 deletions(-)
> 
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index 50570aa..1e94e60 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -110,9 +110,8 @@ get_surftype(enum isl_surf_dim dim, 
> isl_surf_usage_flags_t usage)
>  /*
>   * Get the values to pack into 
> RENDER_SUFFACE_STATE.SurfaceHorizontalAlignment
>   * and SurfaceVerticalAlignment.
>   */
> -static void
> -get_halign_valign(const struct isl_surf *surf,
> -  uint32_t *halign, uint32_t *valign)
> +static struct isl_extent3d
> +get_image_alignment(const struct isl_surf *surf)


The function comment is incorrect post-patch. It should say something to
the tune of "Returns indices into isl_to_gen_halign, isl_to_gen_valign".
Specifically, the function comment needs to clarify (with as few words
as possible) that the units of the returned extent is neither samples,
pixels, nor elements, but something entirely different--array indices--
because it's not really an extent at all.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 13/64] isl/state: Put all dimension setup together and towards the top

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
>  src/intel/isl/isl_surface_state.c | 154 
> ++
>  1 file changed, 74 insertions(+), 80 deletions(-)
> 
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index 0f21e34..0ada3e4 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -213,7 +213,81 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> *dev, void *state,
>s.SurfaceFormat = info->view->format;
> }
>  
> +   s.Width = info->surf->logical_level0_px.width - 1;
> +   s.Height = info->surf->logical_level0_px.height - 1;
> +
> +   switch (s.SurfaceType) {
> +   case SURFTYPE_1D:
> +   case SURFTYPE_2D:
> +  s.MinimumArrayElement = info->view->base_array_layer;

Small nitpick. You can move s.MinimumArrayElement out of the switch, as
each case assigns the same value. Ignore this if you wish.

Patches 12 and 13 are
Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] [PATCH v4] gallium: add API for setting window rectangles

[Brian Paul]

On 06/15/2016 06:24 PM, Ilia Mirkin wrote:

Window rectangles apply to all framebuffer operations, either in
inclusive or exclusive mode. They may also be specified as part of a
blit operation.

In exclusive mode, any fragment inside any of the specified rectangles
will be discarded.

In inclusive mode, any fragment outside every rectangle will be
discarded.

The no-op state is to have 0 rectangles in exclusive mode.

Signed-off-by: Ilia Mirkin 
---

v3 -> v4:
   - make it clearer that clears aren't affected by window rectangles.
   - rename context call to ->set_window_rectangles

  src/gallium/docs/source/context.rst  | 17 ++---
  src/gallium/include/pipe/p_context.h |  5 +
  src/gallium/include/pipe/p_state.h   |  6 ++
  3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/src/gallium/docs/source/context.rst 
b/src/gallium/docs/source/context.rst
index 3a45f40..6f09c55 100644
--- a/src/gallium/docs/source/context.rst
+++ b/src/gallium/docs/source/context.rst
@@ -79,6 +79,17 @@ objects. They all follow simple, one-method binding calls, 
e.g.
should be the same as the number of set viewports and can be up to
PIPE_MAX_VIEWPORTS.
  * ``set_viewport_states``
+* ``set_window_rectangles`` sets the window rectangles to be used for
+  rendering, as defined by GL_EXT_window_rectangles. There are two
+  modes - include and exclude, which define whether the supplied
+  rectangles are to be used for including fragments or excluding
+  them. All of the rectangles are ORed together, so in exclude mode,
+  any fragment inside any rectangle would be culled, while in include
+  mode, any fragment outside all rectangles would be culled. xmin/ymin
+  are inclusive, while xmax/ymax are exclusive (same as scissor states
+  above). Note that this only applies to draws, not clears or
+  blits. (Blits have their own way to pass the requisite rectangles
+  in.)
  * ``set_tess_state`` configures the default tessellation parameters:
* ``default_outer_level`` is the default value for the outer tessellation
  levels. This corresponds to GL's ``PATCH_DEFAULT_OUTER_LEVEL``.
@@ -492,9 +503,9 @@ This can be considered the equivalent of a CPU memcpy.

  ``blit`` blits a region of a resource to a region of another resource, 
including
  scaling, format conversion, and up-/downsampling, as well as a destination 
clip
-rectangle (scissors). It can also optionally honor the current render condition
-(but either way the blit itself never contributes anything to queries currently
-gathering data).
+rectangle (scissors) and window rectangles. It can also optionally honor the
+current render condition (but either way the blit itself never contributes
+anything to queries currently gathering data).
  As opposed to manually drawing a textured quad, this lets the pipe driver 
choose
  the optimal method for blitting (like using a special 2D engine), and usually
  offers, for example, accelerated stencil-only copies even where
diff --git a/src/gallium/include/pipe/p_context.h 
b/src/gallium/include/pipe/p_context.h
index 9d7a8eb..6fde875 100644
--- a/src/gallium/include/pipe/p_context.h
+++ b/src/gallium/include/pipe/p_context.h
@@ -274,6 +274,11 @@ struct pipe_context {
 unsigned num_scissors,
 const struct pipe_scissor_state * );

+   void (*set_window_rectangles)( struct pipe_context *,
+  boolean include,
+  unsigned num_rectangles,
+  const struct pipe_scissor_state * );
+
 void (*set_viewport_states)( struct pipe_context *,
  unsigned start_slot,
  unsigned num_viewports,
diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index 396f563..9c69355 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -69,6 +69,7 @@ extern "C" {
  #define PIPE_MAX_VIEWPORTS16
  #define PIPE_MAX_CLIP_OR_CULL_DISTANCE_COUNT 8
  #define PIPE_MAX_CLIP_OR_CULL_DISTANCE_ELEMENT_COUNT 2
+#define PIPE_MAX_WINDOW_RECTANGLES 8


  struct pipe_reference
@@ -710,6 +711,11 @@ struct pipe_blit_info
 boolean scissor_enable;
 struct pipe_scissor_state scissor;

+   /* Window rectangles can either be inclusive or exclusive. */
+   boolean window_rectangle_include;
+   unsigned num_window_rectangles;
+   struct pipe_scissor_state window_rectangles[PIPE_MAX_WINDOW_RECTANGLES];
+
 boolean render_condition_enable; /**< whether the blit should honor the
  current render condition */
 boolean alpha_blend; /* dst.rgb = src.rgb * src.a + dst.rgb * (1 - src.a) 
*/



Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH 11/64] isl/state: Remove some unused fields

[Chad Versace]

On Thu 16 Jun 2016, Chad Versace wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > They're already zero-initialized and we have no plans of doing anything
> > more interesting with them.
> > ---
> >  src/intel/isl/isl_surface_state.c | 9 -
> >  1 file changed, 9 deletions(-)
> 
> 
> 
> > @@ -261,12 +258,6 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> > *dev, void *state,
> > s.MultisampledSurfaceStorageFormat =
> >isl_to_gen_multisample_layout[info->surf->msaa_layout];
> > s.NumberofMultisamples = ffs(info->surf->samples) - 1;
> > -   s.MultisamplePositionPaletteIndex = 0; /* UNUSED */
> > -
> > -   s.XOffset = 0;
> > -   s.YOffset = 0;
> 
> Wait. Seriously? i965 no longer uses XOffset/YOffset on *any* gen!?!?!?
> When did that happen? I've been waiting for years for i965 to stop using
> XOffset/YOffset on old hardware, but obviously I wasn't paying enough
> attention to the git logs.

I found the commit:

commit b1080cfbdb0a084122fcd662cd27b4748c5598fd
Author: Eric Anholt 
Date:   Wed Aug 28 11:53:09 2013 -0700
Subject: i965: Switch gen4-6 to using the sampler's base level for GL 
BASE_LEVEL.

This patch is
Reviewed-by: Chad Versace 


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

[Mesa-dev] [PATCH] scons: put the generated git_sha1.h file in top-level src/ directory

[Brian Paul]

To match what's done in the automake build.

v2: Use git rev-parse to get a 10-character hash ID
Fix Python imports
---
 src/SConscript  | 49 -
 src/mesa/SConscript | 45 ++---
 2 files changed, 50 insertions(+), 44 deletions(-)

diff --git a/src/SConscript b/src/SConscript
index 4ba0a32..d861af8 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -1,5 +1,8 @@
-Import('*')
+import filecmp
+import os
+import subprocess
 
+Import('*')
 
 if env['platform'] == 'windows':
 SConscript('getopt/SConscript')
@@ -12,6 +15,50 @@ if env['hostonly']:
 # compilation
 Return()
 
+
+def write_git_sha1_h_file(filename):
+"""Mesa looks for a git_sha1.h file at compile time in order to display
+the current git hash id in the GL_VERSION string.  This function tries
+to retrieve the git hashid and write the header file.  An empty file
+will be created if anything goes wrong."""
+
+args = [ 'git', 'rev-parse', '--short=10', 'HEAD' ]
+try:
+(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
+except:
+print "Warning: exception in write_git_sha1_h_file()"
+# git log command didn't work
+if not os.path.exists(filename):
+dirname = os.path.dirname(filename)
+if dirname and not os.path.exists(dirname):
+os.makedirs(dirname)
+# create an empty file if none already exists
+f = open(filename, "w")
+f.close()
+return
+
+# note that commit[:-1] removes the trailing newline character
+commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[:-1]
+tempfile = "git_sha1.h.tmp"
+f = open(tempfile, "w")
+f.write(commit)
+f.close()
+if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
+# The filename does not exist or it's different from the new file,
+# so replace old file with new.
+if os.path.exists(filename):
+os.remove(filename)
+os.rename(tempfile, filename)
+return
+
+
+# Create the git_sha1.h header file
+write_git_sha1_h_file("git_sha1.h")
+# and update CPPPATH so the git_sha1.h header can be found
+env.Append(CPPPATH = ["#" + env['build_dir']])
+
+
+
 if env['platform'] != 'windows':
 SConscript('loader/SConscript')
 
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 434800e..d20b158 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -3,9 +3,6 @@
 
 
 Import('*')
-import filecmp
-import os
-import subprocess
 from sys import executable as python_cmd
 
 env = env.Clone()
@@ -18,10 +15,12 @@ env.Append(CPPPATH = [
 '#/src/mapi',
 '#/src/glsl',
 '#/src/mesa',
+'#/src/mesa/main',
 '#/src/gallium/include',
 '#/src/gallium/auxiliary',
 Dir('../mapi'), # src/mapi build path
 Dir('.'), # src/mesa build path
+Dir('main'),  # src/mesa/main/ build path
 ])
 
 if env['platform'] == 'windows':
@@ -119,46 +118,6 @@ if env['platform'] not in ('cygwin', 'darwin', 'windows', 
'haiku'):
 env.Append(CPPPATH = [matypes[0].dir])
 
 
-def write_git_sha1_h_file(filename):
-"""Mesa looks for a git_sha1.h file at compile time in order to display
-the current git hash id in the GL_VERSION string.  This function tries
-to retrieve the git hashid and write the header file.  An empty file
-will be created if anything goes wrong."""
-
-args = [ 'git', 'log', '-n', '1', '--oneline' ]
-try:
-(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
-except:
-# git log command didn't work
-if not os.path.exists(filename):
-dirname = os.path.dirname(filename)
-if not os.path.exists(dirname):
-os.makedirs(dirname)
-# create an empty file if none already exists
-f = open(filename, "w")
-f.close()
-return
-
-commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]
-tempfile = "git_sha1.h.tmp"
-f = open(tempfile, "w")
-f.write(commit)
-f.close()
-if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
-# The filename does not exist or it's different from the new file,
-# so replace old file with new.
-if os.path.exists(filename):
-os.remove(filename)
-os.rename(tempfile, filename)
-return
-
-
-# Create the git_sha1.h header file
-write_git_sha1_h_file("main/git_sha1.h")
-# and update CPPPATH so the git_sha1.h header can be found
-env.Append(CPPPATH = ["#" + env['build_dir'] + "/mesa/main"])
-
-
 #
 # Libraries
 #
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 11/64] isl/state: Remove some unused fields

[Jason Ekstrand]

On Thu, Jun 16, 2016 at 10:14 AM, Chad Versace 
wrote:

> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > They're already zero-initialized and we have no plans of doing anything
> > more interesting with them.
> > ---
> >  src/intel/isl/isl_surface_state.c | 9 -
> >  1 file changed, 9 deletions(-)
>
>
>
> > @@ -261,12 +258,6 @@ isl_genX(surf_fill_state_s)(const struct isl_device
> *dev, void *state,
> > s.MultisampledSurfaceStorageFormat =
> >isl_to_gen_multisample_layout[info->surf->msaa_layout];
> > s.NumberofMultisamples = ffs(info->surf->samples) - 1;
> > -   s.MultisamplePositionPaletteIndex = 0; /* UNUSED */
> > -
> > -   s.XOffset = 0;
> > -   s.YOffset = 0;
>
> Wait. Seriously? i965 no longer uses XOffset/YOffset on *any* gen!?!?!?
> When did that happen? I've been waiting for years for i965 to stop using
> XOffset/YOffset on old hardware, but obviously I wasn't paying enough
> attention to the git logs.
>

Nope.  Further on I add them back in for real.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/64] isl/state: Remove some unused fields

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> They're already zero-initialized and we have no plans of doing anything
> more interesting with them.
> ---
>  src/intel/isl/isl_surface_state.c | 9 -
>  1 file changed, 9 deletions(-)



> @@ -261,12 +258,6 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> *dev, void *state,
> s.MultisampledSurfaceStorageFormat =
>isl_to_gen_multisample_layout[info->surf->msaa_layout];
> s.NumberofMultisamples = ffs(info->surf->samples) - 1;
> -   s.MultisamplePositionPaletteIndex = 0; /* UNUSED */
> -
> -   s.XOffset = 0;
> -   s.YOffset = 0;

Wait. Seriously? i965 no longer uses XOffset/YOffset on *any* gen!?!?!?
When did that happen? I've been waiting for years for i965 to stop using
XOffset/YOffset on old hardware, but obviously I wasn't paying enough
attention to the git logs.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/64] isl/state: Don't use designated initializers for the surface state

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> While designated initializers are nice, they also force us to put some
> things in the initializer and some things later.  Surface state setup is
> complicated enough that this really hurs readability in the long run.
typo: 


> ---
>  src/intel/isl/isl_surface_state.c | 95 
> ---
>  1 file changed, 48 insertions(+), 47 deletions(-)
> 
> diff --git a/src/intel/isl/isl_surface_state.c 
> b/src/intel/isl/isl_surface_state.c
> index 51c5953..ae8096f 100644
> --- a/src/intel/isl/isl_surface_state.c
> +++ b/src/intel/isl/isl_surface_state.c
> @@ -202,89 +202,90 @@ isl_genX(surf_fill_state_s)(const struct isl_device 
> *dev, void *state,
> uint32_t halign, valign;
> get_halign_valign(info->surf, , );
>  
> -   struct GENX(RENDER_SURFACE_STATE) s = {
> -  .SurfaceType = get_surftype(info->surf->dim, info->view->usage),
> -  .SurfaceArray = info->surf->phys_level0_sa.array_len > 1,
> -  .SurfaceVerticalAlignment = valign,
> -  .SurfaceHorizontalAlignment = halign,
> +   struct GENX(RENDER_SURFACE_STATE) s = { 0 };
> +
> +   s.SurfaceType = get_surftype(info->surf->dim, info->view->usage);
> +
> +   s.SurfaceArray = info->surf->phys_level0_sa.array_len > 1;
> +   s.SurfaceVerticalAlignment = valign;
> +   s.SurfaceHorizontalAlignment = halign;

Small nit. The newline below SurfaceType looks odd.

Patch 9 and 10 are
Reviewed-by: Chad Versace 

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

[Mesa-dev] [PATCH 1/2] vl: add a bicubic interpolation filter

[Nayan Deshmukh]

This is a shader based bicubic interpolater which uses cubic
Hermite spline algorithm.

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/vl/vl_bicubic_filter.c | 370 +++
 src/gallium/auxiliary/vl/vl_bicubic_filter.h |  61 +
 3 files changed, 433 insertions(+)
 create mode 100644 src/gallium/auxiliary/vl/vl_bicubic_filter.c
 create mode 100644 src/gallium/auxiliary/vl/vl_bicubic_filter.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 7b3853e..5430aee 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -315,6 +315,8 @@ NIR_SOURCES := \
nir/tgsi_to_nir.h
 
 VL_SOURCES := \
+   vl/vl_bicubic_filter.c \
+   vl/vl_bicubic_filter.h \
vl/vl_compositor.c \
vl/vl_compositor.h \
vl/vl_csc.c \
diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c 
b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
new file mode 100644
index 000..8005914
--- /dev/null
+++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c
@@ -0,0 +1,370 @@
+/**
+ *
+ * Copyright 2016 Nayan Deshmukh.
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 NON-INFRINGEMENT.
+ * IN NO EVENT SHALL VMWARE AND/OR ITS SUPPLIERS 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 
+
+#include "pipe/p_context.h"
+
+#include "tgsi/tgsi_ureg.h"
+
+#include "util/u_draw.h"
+#include "util/u_memory.h"
+#include "util/u_math.h"
+
+#include "vl_types.h"
+#include "vl_vertex_buffers.h"
+#include "vl_bicubic_filter.h"
+
+enum VS_OUTPUT
+{
+   VS_O_VPOS = 0,
+   VS_O_VTEX = 0
+};
+
+static void *
+create_vert_shader(struct vl_bicubic_filter *filter)
+{
+   struct ureg_program *shader;
+   struct ureg_src i_vpos;
+   struct ureg_dst o_vpos, o_vtex;
+
+   shader = ureg_create(PIPE_SHADER_VERTEX);
+   if (!shader)
+  return NULL;
+
+   i_vpos = ureg_DECL_vs_input(shader, 0);
+   o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
+
+   ureg_MOV(shader, o_vpos, i_vpos);
+   ureg_MOV(shader, o_vtex, i_vpos);
+
+   ureg_END(shader);
+
+   return ureg_create_shader_and_destroy(shader, filter->pipe);
+}
+
+static void
+create_frag_shader_cubic_interpolater(struct ureg_program *shader, struct 
ureg_src tex_a,
+  struct ureg_src tex_b, struct ureg_src 
tex_c,
+  struct ureg_src tex_d, struct ureg_src 
i_vtex,
+  unsigned size, struct ureg_dst 
o_fragment)
+{
+   struct ureg_dst temp[4];
+   struct ureg_dst t, t_2;
+   unsigned i;
+
+   for(i = 0; i < 4; ++i)
+   temp[i] = ureg_DECL_temporary(shader);
+   t = ureg_DECL_temporary(shader);
+
+   /*
+* |temp[0]|   |  0  2  0  0 |  |tex_a|
+* |temp[1]| = | -1  0  1  0 |* |tex_b|
+* |temp[2]|   |  2 -5  4 -1 |  |tex_c|
+* |temp[3]|   | -1  3 -3  1 |  |tex_d|
+*/
+   ureg_MUL(shader, temp[0], tex_b, ureg_imm1f(shader, 2.0f));
+
+   ureg_MUL(shader, temp[1], tex_a, ureg_imm1f(shader, -1.0f));
+   ureg_MAD(shader, temp[1], tex_c, ureg_imm1f(shader, 1.0f),
+ureg_src(temp[1]));
+
+   ureg_MUL(shader, temp[2], tex_a, ureg_imm1f(shader, 2.0f));
+   ureg_MAD(shader, temp[2], tex_b, ureg_imm1f(shader, -5.0f),
+ureg_src(temp[2]));
+   ureg_MAD(shader, temp[2], tex_c, ureg_imm1f(shader, 4.0f),
+ureg_src(temp[2]));
+   ureg_MAD(shader, temp[2], tex_d, ureg_imm1f(shader, -1.0f),
+ ureg_src(temp[2]));
+
+   ureg_MUL(shader, temp[3], tex_a, ureg_imm1f(shader, -1.0f));
+   ureg_MAD(shader, temp[3], tex_b, ureg_imm1f(shader, 3.0f),
+ureg_src(temp[3]));
+   ureg_MAD(shader, temp[3], tex_c, 

[Mesa-dev] [PATCH 2/2] st/vdpau: use bicubic filter for scaling

[Nayan Deshmukh]

Signed-off-by: Nayan Deshmukh 
---
 src/gallium/state_trackers/vdpau/mixer.c | 52 +---
 src/gallium/state_trackers/vdpau/vdpau_private.h |  6 +++
 2 files changed, 53 insertions(+), 5 deletions(-)

diff --git a/src/gallium/state_trackers/vdpau/mixer.c 
b/src/gallium/state_trackers/vdpau/mixer.c
index 65c3ce2..569511d 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -82,7 +82,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -110,6 +109,9 @@ vlVdpVideoMixerCreate(VdpDevice device,
  vmixer->luma_key.supported = true;
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
+ vmixer->bicubic.supported = true;
+ break;
   default: goto no_params;
   }
}
@@ -202,6 +204,10 @@ vlVdpVideoMixerDestroy(VdpVideoMixer mixer)
   vl_matrix_filter_cleanup(vmixer->sharpness.filter);
   FREE(vmixer->sharpness.filter);
}
+   if (vmixer->sharpness.filter) {
+  vl_bicubic_filter_cleanup(vmixer->bicubic.filter);
+  FREE(vmixer->bicubic.filter);
+   }
pipe_mutex_unlock(vmixer->device->mutex);
DeviceReference(>device, NULL);
 
@@ -344,7 +350,7 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
}
 
vl_compositor_set_dst_clip(>cstate, RectToPipe(destination_rect, 
));
-   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter)
+   if (!vmixer->noise_reduction.filter && !vmixer->sharpness.filter && 
!vmixer->bicubic.filter)
   vlVdpSave4DelayedRendering(vmixer->device, destination_surface, 
>cstate);
else {
   vl_compositor_render(>cstate, compositor, dst->surface, 
>dirty_area, true);
@@ -359,6 +365,10 @@ VdpStatus vlVdpVideoMixerRender(VdpVideoMixer mixer,
   if (vmixer->sharpness.filter)
  vl_matrix_filter_render(vmixer->sharpness.filter,
  dst->sampler_view, dst->surface);
+
+  if (vmixer->bicubic.filter)
+ vl_bicubic_filter_render(vmixer->bicubic.filter,
+ dst->sampler_view, dst->surface);
}
pipe_mutex_unlock(vmixer->device->mutex);
 
@@ -461,6 +471,28 @@ vlVdpVideoMixerUpdateSharpnessFilter(vlVdpVideoMixer 
*vmixer)
 }
 
 /**
+ * Update the bicubic filter
+ */
+static void
+vlVdpVideoMixerUpdateBicubicFilter(vlVdpVideoMixer *vmixer)
+{
+   assert(vmixer);
+
+   /* if present remove the old filter first */
+   if (vmixer->bicubic.filter) {
+  vl_bicubic_filter_cleanup(vmixer->bicubic.filter);
+  FREE(vmixer->bicubic.filter);
+  vmixer->bicubic.filter = NULL;
+   }
+   /* and create a new filter as needed */
+   if (vmixer->bicubic.enabled) {
+  vmixer->bicubic.filter = MALLOC(sizeof(struct vl_bicubic_filter));
+  vl_bicubic_filter_init(vmixer->bicubic.filter, vmixer->device->context,
+vmixer->video_width, vmixer->video_height);
+   }
+}
+
+/**
  * Retrieve whether features were requested at creation time.
  */
 VdpStatus
@@ -483,7 +515,6 @@ vlVdpVideoMixerGetFeatureSupport(VdpVideoMixer mixer,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -512,6 +543,10 @@ vlVdpVideoMixerGetFeatureSupport(VdpVideoMixer mixer,
  feature_supports[i] = vmixer->luma_key.supported;
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
+ feature_supports[i] = vmixer->bicubic.supported;
+ break;
+
   default:
  return VDP_STATUS_INVALID_VIDEO_MIXER_FEATURE;
   }
@@ -544,7 +579,6 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
   switch (features[i]) {
   /* they are valid, but we doesn't support them */
   case VDP_VIDEO_MIXER_FEATURE_DEINTERLACE_TEMPORAL_SPATIAL:
-  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L2:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L3:
   case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L4:
@@ -578,6 +612,11 @@ vlVdpVideoMixerSetFeatureEnables(VdpVideoMixer mixer,
  vmixer->luma_key.luma_min, 
vmixer->luma_key.luma_max);
  break;
 
+  case VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1:
+

[Mesa-dev] [PATCH 0/2] implement bicubic interpolation

[Nayan Deshmukh]

Hi,

This series aims to implement bicubic interpolation using
cubic Hermite spline algorithm.

Please Review!

Thanks,
Nayan.

Nayan Deshmukh (2):
  vl: add a bicubic interpolation filter
  st/vdpau: use bicubic filter for scaling

 src/gallium/auxiliary/Makefile.sources   |   2 +
 src/gallium/auxiliary/vl/vl_bicubic_filter.c | 370 +++
 src/gallium/auxiliary/vl/vl_bicubic_filter.h |  61 
 src/gallium/state_trackers/vdpau/mixer.c |  52 +++-
 src/gallium/state_trackers/vdpau/vdpau_private.h |   6 +
 5 files changed, 486 insertions(+), 5 deletions(-)
 create mode 100644 src/gallium/auxiliary/vl/vl_bicubic_filter.c
 create mode 100644 src/gallium/auxiliary/vl/vl_bicubic_filter.h

-- 
2.5.5

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

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Clark]

On Thu, Jun 16, 2016 at 12:56 PM, Rob Herring  wrote:
> On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
>> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
>>> In the process of adding RGBX (XB24) format to mesa for Android, I
>>> started seeing a new problem that makes the UI stop updating. It
>>> happens about when the splash screen is stopped and the lock screen is
>>> displayed. The display flickers on mouse movement, and it looks like
>>> the screen is flipping to old buffers (like the splash screen after
>>> its process exited). It is working fine for freedreno AFAICT, but I am
>>> running into a problem with virgl. With virgl, I get the following
>>> error:
>>>
>>> vrend_create_surface: context error reported 1 "surfaceflinger"
>>> Illegal resource 1435
>>> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
>>> Illegal command buffer 329729
>>>
>>> The addition of the pixel format changes the eglconfig used for the
>>> splash screen. If I force the splash screen eglconfig to have an alpha
>>> or draw one frame of the splash screen and exit early or disable the
>>> splash screen, everything seems fine though I have hit the problem
>>> rarely navigating around. I suspect this has nothing to do with the
>>> pixel format other than different buffer sizes cause buffers to get
>>> reused differently.
>>>
>>> Now I've started working on getting RPi3 and vc4 working, and it
>>> appears to have a similar problem. I'm getting these errors though
>>> things go haywire before getting any error message:
>>>
>>> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 
>>> 0: 4
>>
>> at least in the vc4 case, I suspect you need a similar bit of winsys
>> magic to ensure the same pipe_screen is returned for any given drm
>> device fd.  (Or did someone already add that?)
>
> That problem should be gone with GBM gralloc, right?

*maaaybe*..

It, like the gralloc-drm-pipe approach, means we have a pipe_screen
(vs. the other drm-gralloc backends which were using libdrm_xyz
directly), so it was going through the logic to avoid duplicate
pipe_screen's (for the drivers which had that).

Maybe w/ gbm, everything ends up sharing the same pipe_screen?  I'm
not really sure, since I guess both GL and gralloc are creating a gbm
device?

I guess easy enough to put some debug print in vc4_screen_create() to
confirm.  But the sort of errors you are seeing make me suspicious.

Possibly the "libdrm equivalent" part of vc4 needs to do more to avoid
re-importing the same handle multiple times?

>> In both virgl and vc4 case, you need to make sure that shared
>> (exported/imported) buffers don't end up in the bo cache.
>
> I've disabled the cache (in the gallium drv, right?) and still see problems.
>
> I am seeing a double GEM_CLOSE. I'm not sure how that is happening.
> One of them must be hwc releasing an imported buffer, but it's all in
> the same thread.
>
> [7.024495] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret = 0,
> DRM_IOCTL_GEM_CLOSE
> [7.025379] [drm] pid=1310, dev=0xe280, auth=0, handle=23, ret = 0,
> DRM_IOCTL_PRIME_FD_TO_HANDLE
> [7.026663] [drm] pid=1310, dev=0xe280, auth=0, handle=10, ret = 0,
> DRM_IOCTL_GEM_CLOSE
> [7.027343] [drm] pid=1310, dev=0xe200, auth=1, handle=23, ret = 0,
> DRM_IOCTL_PRIME_FD_TO_HANDLE
> [7.035098] [drm] pid=1333, dev=0xe200, auth=1, handle=1, ret = 0,
> DRM_IOCTL_GEM_CLOSE
> [7.036093] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret =
> -22, DRM_IOCTL_GEM_CLOSE

sure would be nice if there was a dump_stack() that showed you the
userspace stack too ;-)

(but maybe dumb question, is pid unique per process or thread?)

BR,
-R

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

Re: [Mesa-dev] [PATCH 08/64] i965/blorp: Only set src_z for gen8+ 3D textures

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> Otherwise, we end up with a bogus value in the third component.  On gen6-7
> where we always use 2D textures, this can cause problems if the
> SurfaceArray bit is set in the SURFACE_STATE.

Enlighten me. Why does blorp use 3D surfaces on gen >= 8 but not
earlier?

> ---
>  src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp 
> b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> index 782d285..cdb6b33 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
> @@ -1846,8 +1846,15 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
> brw_blorp_setup_coord_transform(_push_consts.y_transform,
> src_y0, src_y1, dst_y0, dst_y1, mirror_y);
>  
> -   params.wm_push_consts.src_z =
> -  params.src.mt->target == GL_TEXTURE_3D ? params.src.layer : 0;
> +   if (brw->gen >= 8 && params.src.mt->target == GL_TEXTURE_3D) {
> +  /* On gen8+ we use actual 3-D textures so we need to pass the layer
> +   * through to the sampler.
> +   */
> +  params.wm_push_consts.src_z = params.src.layer;
> +   } else {
> +  /* On gen7 and earlier, we fake everything with 2-D textures */
> +  params.wm_push_consts.src_z = 0;
> +   }
>  
> if (params.dst.num_samples <= 1 && dst_mt->num_samples > 1) {
>/* We must expand the rectangle we send through the rendering pipeline,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 07/64] i965/gen7, 8: Set SURFACE_IS_ARRAY for all non-3D texture types

[Chad Versace]

On Sat 11 Jun 2016, Jason Ekstrand wrote:
> There's no real reason why we shouldn't set this bit.  It does affect how
> the sampler operates a bit but since you can have a 2D non-array view of a
> 2D_ARRAY texture that distinction is very weak.  Also, this is what ISL
> will do and we would like this change to be isolated from using ISL.
> ---
>  src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 2 +-
>  src/mesa/drivers/dri/i965/gen8_surface_state.c| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Chad Versace 

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

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Herring]

On Thu, Jun 16, 2016 at 11:44 AM, Rob Clark  wrote:
> On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
>> In the process of adding RGBX (XB24) format to mesa for Android, I
>> started seeing a new problem that makes the UI stop updating. It
>> happens about when the splash screen is stopped and the lock screen is
>> displayed. The display flickers on mouse movement, and it looks like
>> the screen is flipping to old buffers (like the splash screen after
>> its process exited). It is working fine for freedreno AFAICT, but I am
>> running into a problem with virgl. With virgl, I get the following
>> error:
>>
>> vrend_create_surface: context error reported 1 "surfaceflinger"
>> Illegal resource 1435
>> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
>> Illegal command buffer 329729
>>
>> The addition of the pixel format changes the eglconfig used for the
>> splash screen. If I force the splash screen eglconfig to have an alpha
>> or draw one frame of the splash screen and exit early or disable the
>> splash screen, everything seems fine though I have hit the problem
>> rarely navigating around. I suspect this has nothing to do with the
>> pixel format other than different buffer sizes cause buffers to get
>> reused differently.
>>
>> Now I've started working on getting RPi3 and vc4 working, and it
>> appears to have a similar problem. I'm getting these errors though
>> things go haywire before getting any error message:
>>
>> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 0: 
>> 4
>
> at least in the vc4 case, I suspect you need a similar bit of winsys
> magic to ensure the same pipe_screen is returned for any given drm
> device fd.  (Or did someone already add that?)

That problem should be gone with GBM gralloc, right?

> In both virgl and vc4 case, you need to make sure that shared
> (exported/imported) buffers don't end up in the bo cache.

I've disabled the cache (in the gallium drv, right?) and still see problems.

I am seeing a double GEM_CLOSE. I'm not sure how that is happening.
One of them must be hwc releasing an imported buffer, but it's all in
the same thread.

[7.024495] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret = 0,
DRM_IOCTL_GEM_CLOSE
[7.025379] [drm] pid=1310, dev=0xe280, auth=0, handle=23, ret = 0,
DRM_IOCTL_PRIME_FD_TO_HANDLE
[7.026663] [drm] pid=1310, dev=0xe280, auth=0, handle=10, ret = 0,
DRM_IOCTL_GEM_CLOSE
[7.027343] [drm] pid=1310, dev=0xe200, auth=1, handle=23, ret = 0,
DRM_IOCTL_PRIME_FD_TO_HANDLE
[7.035098] [drm] pid=1333, dev=0xe200, auth=1, handle=1, ret = 0,
DRM_IOCTL_GEM_CLOSE
[7.036093] [drm] pid=1310, dev=0xe280, auth=0, handle=17, ret =
-22, DRM_IOCTL_GEM_CLOSE

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

Re: [Mesa-dev] [PATCH 03/11] mesa: Strip arrayness from interface block names in some IO validation

[Ian Romanick]

On 06/14/2016 08:34 PM, Timothy Arceri wrote:
> On Tue, 2016-06-14 at 19:01 -0700, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> Outputs from the vertex shader need to be able to match
>> per-vertex-arrayed inputs of later stages.  Acomplish this by
>> stripping
>> one level of arrayness from the names and types of outputs going to a
>> per-vertex-arrayed stage.
>>
>> Signed-off-by: Ian Romanick 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96358
>> Cc: "12.0" 
>> Cc: Gregory Hainaut 
>> Cc: Ilia Mirkin 
>> ---
>>  src/mesa/main/shader_query.cpp | 98
>> ++
>>  1 file changed, 90 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/mesa/main/shader_query.cpp
>> b/src/mesa/main/shader_query.cpp
>> index 5956ce4..b2e53fb 100644
>> --- a/src/mesa/main/shader_query.cpp
>> +++ b/src/mesa/main/shader_query.cpp
>> @@ -1385,13 +1385,24 @@ _mesa_get_program_resourceiv(struct
>> gl_shader_program *shProg,
>>  
>>  static bool
>>  validate_io(struct gl_shader_program *producer,
>> -struct gl_shader_program *consumer)
>> +struct gl_shader_program *consumer,
>> +gl_shader_stage producer_stage,
>> +gl_shader_stage consumer_stage)
>>  {
>> if (producer == consumer)
>>return true;
>>  
>> +   const bool nonarray_stage_to_array_stage =
>> +  producer_stage == MESA_SHADER_VERTEX &&
>> +  (consumer_stage == MESA_SHADER_GEOMETRY ||
>> +   consumer_stage == MESA_SHADER_TESS_CTRL ||
>> +   consumer_stage == MESA_SHADER_TESS_EVAL);
> 
> TESS_EVAL->GEOM ?

I missed that TESS_EVAL shader outputs are not arrayed.  I'll add that.

>> +
>> bool valid = true;
>>  
>> +   void *name_buffer = NULL;
>> +   size_t name_buffer_size = 0;
>> +
>> gl_shader_variable const **outputs =
>>(gl_shader_variable const **) calloc(producer-
>>> NumProgramResourceList,
>> sizeof(gl_shader_variable
>> *));
>> @@ -1463,11 +1474,52 @@ validate_io(struct gl_shader_program
>> *producer,
>>  }
>>   }
>>} else {
>> + char *consumer_name = consumer_var->name;
>> +
>> + if (nonarray_stage_to_array_stage &&
>> + consumer_var->interface_type != NULL &&
>> + consumer_var->interface_type->is_array() &&
>> + !is_gl_identifier(consumer_var->name)) {
>> +const size_t name_len = strlen(consumer_var->name);
>> +
>> +if (name_len >= name_buffer_size) {
>> +   free(name_buffer);
>> +
>> +   name_buffer_size = name_len + 1;
>> +   name_buffer = malloc(name_buffer_size);
>> +   if (name_buffer == NULL) {
>> +  valid = false;
>> +  goto out;
>> +   }
>> +}
>> +
>> +consumer_name = (char *) name_buffer;
>> +
>> +char *s = strchr(consumer_var->name, '[');
>> +if (s == NULL) {
>> +   valid = false;
>> +   goto out;
>> +}
>> +
>> +char *t = strchr(s, ']');
>> +if (t == NULL) {
>> +   valid = false;
>> +   goto out;
>> +}
>> +
>> +assert(t[1] == '.' || t[1] == '[');
>> +
>> +const ptrdiff_t base_name_len = s - consumer_var->name;
>> +
>> +memcpy(consumer_name, consumer_var->name,
>> base_name_len);
>> +strcpy(consumer_name + base_name_len, t + 1);
>> + }
>> +
>>   for (unsigned j = 0; j < num_outputs; j++) {
>>  const gl_shader_variable *const var = outputs[j];
>>  
>>  if (!var->explicit_location &&
>> -strcmp(consumer_var->name, var->name) == 0) {
>> +strcmp(consumer_name, var->name) == 0) {
>> producer_var = var;
>> match_index = j;
>> break;
>> @@ -1529,25 +1581,53 @@ validate_io(struct gl_shader_program
>> *producer,
>> * Note that location mismatches are detected by the loops
>> above that
>> * find the producer variable that goes with the consumer
>> variable.
>> */
>> -  if (producer_var->type != consumer_var->type ||
>> -  producer_var->interpolation != consumer_var->interpolation 
>> ||
>> -  producer_var->precision != consumer_var->precision) {
>> +  if (nonarray_stage_to_array_stage) {
>> + if (!consumer_var->type->is_array() ||
>> + consumer_var->type->fields.array != producer_var->type) 
>> {
>> +valid = false;
>> +goto out;
>> + }
>> +
>> + if (consumer_var->interface_type != NULL) {
>> +if (!consumer_var->interface_type->is_array() ||
>> +consumer_var->interface_type->fields.array !=
>> 

Re: [Mesa-dev] virgl and vc4 problem on Android

[Rob Clark]

On Wed, Jun 15, 2016 at 8:34 PM, Rob Herring  wrote:
> In the process of adding RGBX (XB24) format to mesa for Android, I
> started seeing a new problem that makes the UI stop updating. It
> happens about when the splash screen is stopped and the lock screen is
> displayed. The display flickers on mouse movement, and it looks like
> the screen is flipping to old buffers (like the splash screen after
> its process exited). It is working fine for freedreno AFAICT, but I am
> running into a problem with virgl. With virgl, I get the following
> error:
>
> vrend_create_surface: context error reported 1 "surfaceflinger"
> Illegal resource 1435
> vrend_report_buffer_error: context error reported 1 "surfaceflinger"
> Illegal command buffer 329729
>
> The addition of the pixel format changes the eglconfig used for the
> splash screen. If I force the splash screen eglconfig to have an alpha
> or draw one frame of the splash screen and exit early or disable the
> splash screen, everything seems fine though I have hit the problem
> rarely navigating around. I suspect this has nothing to do with the
> pixel format other than different buffer sizes cause buffers to get
> reused differently.
>
> Now I've started working on getting RPi3 and vc4 working, and it
> appears to have a similar problem. I'm getting these errors though
> things go haywire before getting any error message:
>
> [   43.846569] [drm:vc4_submit_cl_ioctl] *ERROR* Failed to look up GEM BO 0: 4

at least in the vc4 case, I suspect you need a similar bit of winsys
magic to ensure the same pipe_screen is returned for any given drm
device fd.  (Or did someone already add that?)

In both virgl and vc4 case, you need to make sure that shared
(exported/imported) buffers don't end up in the bo cache.

That is at least what occurs to me off the top of my head.  Beyond
that, I'd have to look at code.  But it does sound a lot like the same
old handle <-> buffer confusion..

BR,
-R

> Here's a screenshot[1]. I've also seen an error for fbo size of 4KB
> when expected size is 5MB. The RPi is a bit different in that I can
> continue to navigate around, but apps are not really working and don't
> render completely. Returning to the home screen starts the flickering
> like the pic except the old contents are the app that ran last.
>
> Any suggestions on how to debug this? I've tried a few things like
> disabling the BO cache in vc4 gallium driver and logging BO
> create/free, but didn't see anything.
>
> Rob
>
> [1] https://goo.gl/photos/zqq3ksMVXLvbA6CK8
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] scons: put the generated git_sha1.h file in top-level src/ directory

[Brian Paul]

On 06/16/2016 10:31 AM, Eric Engestrom wrote:

On Thu, Jun 16, 2016 at 09:48:54AM -0600, Brian Paul wrote:

On 06/16/2016 07:35 AM, Eric Engestrom wrote:

That fixed truncation can give non-unique hashes. Switching to rev-parse
(suggested above) fixes this.


rev-parse --short produces a 7-char hash.


No it doesn't, not in the general case. You may well have tested it on
a commit whose hash was unique at that length, but in general it gives
you the shortest hash that's unique at the point in time when it's run
(with a minimum, default = 7).


Ah, OK.  I was going from the portion of the man page which says:

"""
   --short, --short=number
   Instead of outputting the full SHA-1 values of object names 
try to

   abbreviate them to a shorter unique name. When no length is
   specified 7 is used. The minimum length is 4.
"""

I had never come across git rev-parse before today.  I feel like I know 
about 1% of git to be honest.





I think I didn't explain my point very well, so I'll say it differently:
- If a commit hash is meant as a short lived information, the minimal
   unique hash at that point is good enough. Manually truncating doesn't
   guarantee that.
- If the commit hash is meant to be long lived, the full hash should be
   used. (This is typically the case in a commit message.)

In this case, the hash is meaningless once it becomes old, so the first
option is good enough.
It still needs to be unique, at least when generated. For this reason,
manually truncating it is not a good method.

(This is, of course, my opinion. I know other people have other opinions
(in both directions), which I respect. I'm just sharing mine.)



The commit[0:7] part above is
used to strip the trailing newline from the string (though that could be
expressed better).


The original command (log) printed more informations on that line, which
is what this code was stripping.
I don't know if python needs newlines to be stripped, but if it does,
please use an other method (would `commit[0:-1]` do that?).


Yeah, when I was testing without the substring specifier I was getting a 
newline character in my C string and that, of course, broke things.







Yeah, I think I'll bump the hash length to ten.


Please do so using `rev-parse --short=10` :)


Yup, that's what my patch is doing.  I still need to test it on Windows...






v2 patch coming in a bit...

-Brian



Cheers,
   Eric

PS: I promise I'm not trying to be mean, but I feel like I'm coming
 across as such :(


Nope, thanks for the helpful feedback!

-Brian


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

Re: [Mesa-dev] [PATCH] scons: put the generated git_sha1.h file in top-level src/ directory

[Eric Engestrom]

On Thu, Jun 16, 2016 at 09:48:54AM -0600, Brian Paul wrote:
> On 06/16/2016 07:35 AM, Eric Engestrom wrote:
> > That fixed truncation can give non-unique hashes. Switching to rev-parse
> > (suggested above) fixes this.
> 
> rev-parse --short produces a 7-char hash.

No it doesn't, not in the general case. You may well have tested it on
a commit whose hash was unique at that length, but in general it gives
you the shortest hash that's unique at the point in time when it's run
(with a minimum, default = 7).

I think I didn't explain my point very well, so I'll say it differently:
- If a commit hash is meant as a short lived information, the minimal
  unique hash at that point is good enough. Manually truncating doesn't
  guarantee that.
- If the commit hash is meant to be long lived, the full hash should be
  used. (This is typically the case in a commit message.)

In this case, the hash is meaningless once it becomes old, so the first
option is good enough.
It still needs to be unique, at least when generated. For this reason,
manually truncating it is not a good method.

(This is, of course, my opinion. I know other people have other opinions
(in both directions), which I respect. I'm just sharing mine.)


> The commit[0:7] part above is
> used to strip the trailing newline from the string (though that could be
> expressed better).

The original command (log) printed more informations on that line, which
is what this code was stripping.
I don't know if python needs newlines to be stripped, but if it does,
please use an other method (would `commit[0:-1]` do that?).


> Yeah, I think I'll bump the hash length to ten.

Please do so using `rev-parse --short=10` :)

> 
> v2 patch coming in a bit...
> 
> -Brian
> 

Cheers,
  Eric

PS: I promise I'm not trying to be mean, but I feel like I'm coming
across as such :(
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] scons: put the generated git_sha1.h file in top-level src/ directory

[Brian Paul]

On 06/16/2016 07:35 AM, Eric Engestrom wrote:

On Wed, Jun 15, 2016 at 11:58:29AM -0600, Brian Paul wrote:

To match what's done in the automake build.
---
  src/SConscript  | 43 +++
  src/mesa/SConscript | 43 ++-
  2 files changed, 45 insertions(+), 41 deletions(-)

diff --git a/src/SConscript b/src/SConscript
index 4ba0a32..719aa69 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -1,5 +1,6 @@
  Import('*')

+import os

  if env['platform'] == 'windows':
  SConscript('getopt/SConscript')
@@ -12,6 +13,48 @@ if env['hostonly']:
  # compilation
  Return()

+
+def write_git_sha1_h_file(filename):
+"""Mesa looks for a git_sha1.h file at compile time in order to display
+the current git hash id in the GL_VERSION string.  This function tries
+to retrieve the git hashid and write the header file.  An empty file
+will be created if anything goes wrong."""
+
+args = [ 'git', 'log', '-n', '1', '--oneline' ]


You could take the opportunity to change this to:

args = [ 'git', 'rev-parse', '--short', 'HEAD' ]

to match what's being done on the make build:
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_90532_=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8=0zzXqbMZULPltpwVbCJ7fMOHXGh4Br2grMgXY81QxQo=jgTYcNCdGznhwVF_DEuJaDfG6_ACwJnhVROqpu0ZWvg=


Will do.



+try:
+(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
+except:
+# git log command didn't work
+if not os.path.exists(filename):
+dirname = os.path.dirname(filename)
+if dirname and not os.path.exists(dirname):
+os.makedirs(dirname)
+# create an empty file if none already exists
+f = open(filename, "w")
+f.close()
+return
+
+commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]


That fixed truncation can give non-unique hashes. Switching to rev-parse
(suggested above) fixes this.


rev-parse --short produces a 7-char hash.  The commit[0:7] part above is 
used to strip the trailing newline from the string (though that could be 
expressed better).




I had a quick grep and found Mesa has already 314 commits that can't be
uniquely described from the first 7 chars of their hashes:

$ git rev-list --all --abbrev=0 --abbrev-commit | grep -E '.{8,}' | wc 
-l
314


Yeah, I think I'll bump the hash length to ten.

v2 patch coming in a bit...

-Brian




(I also tend to dislike overwriting a variable with something
semantically different from what it contained before, but that's
a matter of opinion, and you didn't author that code anyway.)

The rest looks good, but I've never used SCons and my Python experience
is very limited so I won't formally give an r-b on this.


+tempfile = "git_sha1.h.tmp"
+f = open(tempfile, "w")
+f.write(commit)
+f.close()
+if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
+# The filename does not exist or it's different from the new file,
+# so replace old file with new.
+if os.path.exists(filename):
+os.remove(filename)
+os.rename(tempfile, filename)
+return
+
+
+# Create the git_sha1.h header file
+write_git_sha1_h_file("git_sha1.h")
+# and update CPPPATH so the git_sha1.h header can be found
+env.Append(CPPPATH = ["#" + env['build_dir']])
+
+
+
  if env['platform'] != 'windows':
  SConscript('loader/SConscript')

diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index 434800e..2a340ac 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -4,7 +4,6 @@

  Import('*')
  import filecmp
-import os
  import subprocess
  from sys import executable as python_cmd

@@ -18,10 +17,12 @@ env.Append(CPPPATH = [
  '#/src/mapi',
  '#/src/glsl',
  '#/src/mesa',
+'#/src/mesa/main',
  '#/src/gallium/include',
  '#/src/gallium/auxiliary',
  Dir('../mapi'), # src/mapi build path
  Dir('.'), # src/mesa build path
+Dir('main'),  # src/mesa/main/ build path
  ])

  if env['platform'] == 'windows':
@@ -119,46 +120,6 @@ if env['platform'] not in ('cygwin', 'darwin', 'windows', 
'haiku'):
  env.Append(CPPPATH = [matypes[0].dir])


-def write_git_sha1_h_file(filename):
-"""Mesa looks for a git_sha1.h file at compile time in order to display
-the current git hash id in the GL_VERSION string.  This function tries
-to retrieve the git hashid and write the header file.  An empty file
-will be created if anything goes wrong."""
-
-args = [ 'git', 'log', '-n', '1', '--oneline' ]
-try:
-(commit, foo) = subprocess.Popen(args, 
stdout=subprocess.PIPE).communicate()
-except:
-# git log command didn't work
-if not os.path.exists(filename):
-dirname = os.path.dirname(filename)
-if 

Re: [Mesa-dev] [PATCH v2] swr: automake: don't ship LLVM version specific generated sources

[Chuck Atkins]

So, I can confirm that with this patch applied to the rc3 tag, I can
generate a tarball on Arch with make dist, and then use said tarball to
build with SWR enabled on fedora.  So:

Tested-by: Chuck Atkins 

- Chuck

On Tue, Jun 14, 2016 at 1:14 PM, Emil Velikov 
wrote:

> On 14 June 2016 at 18:06, Rowley, Timothy O 
> wrote:
> >
> >> On Jun 13, 2016, at 8:03 PM, Rowley, Timothy O <
> timothy.o.row...@intel.com> wrote:
> >>
> >> A clean tree build works with this version, but distcheck fails:
> >>
> >> ...
> >> rm -f config.status config.cache config.log configure.lineno
> config.status.lineno
> >> rm -f Makefile
> >> ERROR: files left in build directory after distclean:
> >> ./src/gallium/drivers/swr/rasterizer/jitter/builder_gen.cpp
> >> ./src/gallium/drivers/swr/rasterizer/jitter/builder_x86.cpp
> >> ./src/gallium/drivers/swr/rasterizer/jitter/builder_gen.h
> >> make[1]: *** [distcleancheck] Error 1
> >> make[1]: Leaving directory
> `/home/torowley/work/mesa-opt/mesa-12.1.0-devel/_build'
> >> make: *** [distcheck] Error 1
> >>
> >> Not sure how builder_x86.cpp managed to change its status.
> >
> > To answer my own question: the reason for builder_x86.cpp being
> regenerated is because of its dependency on builder_gen.h (through
> builder.h).
> >
> I thought that one was mentioned is the big comment in the patch.
> Perhaps my wording could be improved - any suggestions ?
>
> And yes, due to the missing dependency the file will be (re)generated
> at a later stage thus we'll need to add yet another workaround for
> that. Just listing the whole lot in CLEANFILES should be enough.
>
> Feel free to give it a try, or I'll do at some point later on today.
>
> Thanks,
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 96543] N-Ball editor shows only a blackscreen

[bugzilla-daemon]

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

--- Comment #2 from Fabian Maurer  ---
Interesting, with this option it works in my system, too.
Is this the expected behaviour? Since it worked on windows without that
parameter, but on my linux pc I got a blackscreen, I assumed it should work
without.

-- 
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] scons: put the generated git_sha1.h file in top-level src/ directory

[Emil Velikov]

On 15 June 2016 at 18:58, Brian Paul  wrote:
> To match what's done in the automake build.
Considering the grief that it caused for autoconf builds I've
deliberately left scons as-is the moment.

There's even one more corner case that I will send a patch out in a moment.

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

Re: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Rob Clark]

So, if we wanted to extend this to support the fourcc-modifiers that
we have on the kernel side for compressed/tiled/etc formats, what
would be the right approach?

A new version of the existing extension or a new
EGL_EXT_image_dma_buf_import2 extension, or ??

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  wrote:
> Hi All,
>
> The final spec has had enum values assigned and been published on Khronos:
>
> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>
> Thanks to all who've provided input.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm@lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm@lists.freedesktop.org] On Behalf Of Tom Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-dev@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri-
>> de...@lists.freedesktop.org; linux-me...@vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> +-++
>>Table aaa.  Legal values for eglCreateImageKHR  parameter
>>
>> ...
>>
>> If  

Re: [Mesa-dev] [PATCH] mesa/glsl: stop using GL shader type internally

[Jose Fonseca]

On 05/06/16 04:17, Timothy Arceri wrote:

Instead use the internal gl_shader_stage enum everywhere. This
makes things more consistent and gets rid of unnecessary
conversions.

Ideally it would be nice to remove the Type field from gl_shader
altogether but currently it is used to differentiate between
gl_shader and gl_shader_program in the ShaderObjects hash table.
---
  src/compiler/glsl/builtin_functions.cpp  |  2 +-
  src/compiler/glsl/link_varyings.cpp  |  2 +-
  src/compiler/glsl/linker.cpp |  2 +-
  src/compiler/glsl/standalone.cpp |  2 +-
  src/compiler/glsl/standalone_scaffolding.cpp |  7 +++
  src/compiler/glsl/standalone_scaffolding.h   |  2 +-
  src/mesa/drivers/common/meta.c   | 12 +--
  src/mesa/drivers/common/meta.h   |  5 -
  src/mesa/drivers/dri/i965/brw_link.cpp   |  5 ++---
  src/mesa/drivers/dri/i965/brw_shader.h   |  3 ++-
  src/mesa/main/dd.h   |  2 +-
  src/mesa/main/ff_fragment_shader.cpp |  2 +-
  src/mesa/main/shaderapi.c| 20 ++-
  src/mesa/main/shaderobj.c|  6 ++
  src/mesa/state_tracker/st_glsl_to_nir.cpp|  6 +++---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp   | 30 ++--
  16 files changed, 51 insertions(+), 57 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index edd02bb..87d22e6 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -948,7 +948,7 @@ builtin_builder::create_shader()
  * GLSL utility code that could be linked against any stage, so just
  * arbitrarily pick GL_VERTEX_SHADER.
  */
-   shader = _mesa_new_shader(NULL, 0, GL_VERTEX_SHADER);
+   shader = _mesa_new_shader(NULL, 0, MESA_SHADER_VERTEX);
 shader->symbols = new(mem_ctx) glsl_symbol_table;

 gl_ModelViewProjectionMatrix =
diff --git a/src/compiler/glsl/link_varyings.cpp 
b/src/compiler/glsl/link_varyings.cpp
index a286e77..2ff7d80 100644
--- a/src/compiler/glsl/link_varyings.cpp
+++ b/src/compiler/glsl/link_varyings.cpp
@@ -2111,7 +2111,7 @@ assign_varying_locations(struct gl_context *ctx,
* within a patch and can be used as shared memory.
*/
   if (input_var || (prog->SeparateShader && consumer == NULL) ||
- producer->Type == GL_TESS_CONTROL_SHADER) {
+ producer->Stage == MESA_SHADER_TESS_CTRL) {
  matches.record(output_var, input_var);
   }

diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
index 43719f4..e0e09e9 100644
--- a/src/compiler/glsl/linker.cpp
+++ b/src/compiler/glsl/linker.cpp
@@ -2237,7 +2237,7 @@ link_intrastage_shaders(void *mem_ctx,
return NULL;
 }

-   gl_shader *linked = ctx->Driver.NewShader(NULL, 0, main->Type);
+   gl_shader *linked = ctx->Driver.NewShader(NULL, 0, shader_list[0]->Stage);
 linked->ir = new(linked) exec_list;
 clone_ir_list(mem_ctx, linked->ir, main->ir);

diff --git a/src/compiler/glsl/standalone.cpp b/src/compiler/glsl/standalone.cpp
index c3afbc3..9b77b3a 100644
--- a/src/compiler/glsl/standalone.cpp
+++ b/src/compiler/glsl/standalone.cpp
@@ -419,7 +419,7 @@ standalone_compile_shader(const struct standalone_options 
*_options,
  continue;

   shader->Program = rzalloc(shader, gl_program);
- init_gl_program(shader->Program, shader->Type);
+ init_gl_program(shader->Program, shader->Stage);
}
 }

diff --git a/src/compiler/glsl/standalone_scaffolding.cpp 
b/src/compiler/glsl/standalone_scaffolding.cpp
index e7f6555..94938ef 100644
--- a/src/compiler/glsl/standalone_scaffolding.cpp
+++ b/src/compiler/glsl/standalone_scaffolding.cpp
@@ -76,17 +76,16 @@ _mesa_shader_debug(struct gl_context *, GLenum, GLuint *,
  }

  struct gl_shader *
-_mesa_new_shader(struct gl_context *ctx, GLuint name, GLenum type)
+_mesa_new_shader(struct gl_context *ctx, GLuint name, gl_shader_stage stage)
  {
 struct gl_shader *shader;

 (void) ctx;

-   assert(type == GL_FRAGMENT_SHADER || type == GL_VERTEX_SHADER);
+   assert(stage == MESA_SHADER_FRAGMENT || stage == MESA_SHADER_VERTEX);
 shader = rzalloc(NULL, struct gl_shader);
 if (shader) {
-  shader->Type = type;
-  shader->Stage = _mesa_shader_enum_to_shader_stage(type);
+  shader->Stage = stage;
shader->Name = name;
shader->RefCount = 1;
 }
diff --git a/src/compiler/glsl/standalone_scaffolding.h 
b/src/compiler/glsl/standalone_scaffolding.h
index 6cef784..cfac883 100644
--- a/src/compiler/glsl/standalone_scaffolding.h
+++ b/src/compiler/glsl/standalone_scaffolding.h
@@ -47,7 +47,7 @@ _mesa_reference_program_(struct gl_context *ctx, struct 
gl_program **ptr,
 struct gl_shader *sh);

  extern "C" struct gl_shader *
-_mesa_new_shader(struct gl_context *ctx, GLuint name, GLenum 

Re: [Mesa-dev] [PATCH] i965: remove remaining tabs in brw_link.cpp

[Jason Ekstrand]

Thanks,

Acked-by: Jason Ekstrand 
On Jun 15, 2016 11:13 PM, "Timothy Arceri" 
wrote:

> ---
>  src/mesa/drivers/dri/i965/brw_link.cpp | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index 16bfbaa..ab2484e 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -210,13 +210,13 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
> for (stage = 0; stage < ARRAY_SIZE(shProg->_LinkedShaders); stage++) {
>struct gl_shader *shader = shProg->_LinkedShaders[stage];
>if (!shader)
> -continue;
> + continue;
>
>struct gl_program *prog =
> -ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
> + ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
>  shader->Name);
>if (!prog)
> -   return false;
> +return false;
>prog->Parameters = _mesa_new_parameter_list();
>
>_mesa_copy_linked_program_data((gl_shader_stage) stage, shProg,
> prog);
> @@ -231,19 +231,19 @@ brw_link_shader(struct gl_context *ctx, struct
> gl_shader_program *shProg)
> * get sent to the shader.
> */
>foreach_in_list(ir_instruction, node, shader->ir) {
> -ir_variable *var = node->as_variable();
> + ir_variable *var = node->as_variable();
>
> -if ((var == NULL) || (var->data.mode != ir_var_uniform)
> -|| (strncmp(var->name, "gl_", 3) != 0))
> -   continue;
> + if ((var == NULL) || (var->data.mode != ir_var_uniform)
> + || (strncmp(var->name, "gl_", 3) != 0))
> +continue;
>
> -const ir_state_slot *const slots = var->get_state_slots();
> -assert(slots != NULL);
> + const ir_state_slot *const slots = var->get_state_slots();
> + assert(slots != NULL);
>
> -for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
> -   _mesa_add_state_reference(prog->Parameters,
> - (gl_state_index *) slots[i].tokens);
> -}
> + for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
> +_mesa_add_state_reference(prog->Parameters,
> +  (gl_state_index *) slots[i].tokens);
> + }
>}
>
>do_set_program_inouts(shader->ir, prog, shader->Stage);
> --
> 2.5.5
>
> ___
> 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] scons: put the generated git_sha1.h file in top-level src/ directory

[Eric Engestrom]

On Wed, Jun 15, 2016 at 11:58:29AM -0600, Brian Paul wrote:
> To match what's done in the automake build.
> ---
>  src/SConscript  | 43 +++
>  src/mesa/SConscript | 43 ++-
>  2 files changed, 45 insertions(+), 41 deletions(-)
> 
> diff --git a/src/SConscript b/src/SConscript
> index 4ba0a32..719aa69 100644
> --- a/src/SConscript
> +++ b/src/SConscript
> @@ -1,5 +1,6 @@
>  Import('*')
>  
> +import os
>  
>  if env['platform'] == 'windows':
>  SConscript('getopt/SConscript')
> @@ -12,6 +13,48 @@ if env['hostonly']:
>  # compilation
>  Return()
>  
> +
> +def write_git_sha1_h_file(filename):
> +"""Mesa looks for a git_sha1.h file at compile time in order to display
> +the current git hash id in the GL_VERSION string.  This function tries
> +to retrieve the git hashid and write the header file.  An empty file
> +will be created if anything goes wrong."""
> +
> +args = [ 'git', 'log', '-n', '1', '--oneline' ]

You could take the opportunity to change this to:

args = [ 'git', 'rev-parse', '--short', 'HEAD' ]

to match what's being done on the make build:
https://patchwork.freedesktop.org/patch/90532/

> +try:
> +(commit, foo) = subprocess.Popen(args, 
> stdout=subprocess.PIPE).communicate()
> +except:
> +# git log command didn't work
> +if not os.path.exists(filename):
> +dirname = os.path.dirname(filename)
> +if dirname and not os.path.exists(dirname):
> +os.makedirs(dirname)
> +# create an empty file if none already exists
> +f = open(filename, "w")
> +f.close()
> +return
> +
> +commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]

That fixed truncation can give non-unique hashes. Switching to rev-parse
(suggested above) fixes this.
I had a quick grep and found Mesa has already 314 commits that can't be
uniquely described from the first 7 chars of their hashes:

$ git rev-list --all --abbrev=0 --abbrev-commit | grep -E '.{8,}' | wc 
-l
314

(I also tend to dislike overwriting a variable with something
semantically different from what it contained before, but that's
a matter of opinion, and you didn't author that code anyway.)

The rest looks good, but I've never used SCons and my Python experience
is very limited so I won't formally give an r-b on this.

> +tempfile = "git_sha1.h.tmp"
> +f = open(tempfile, "w")
> +f.write(commit)
> +f.close()
> +if not os.path.exists(filename) or not filecmp.cmp(tempfile, filename):
> +# The filename does not exist or it's different from the new file,
> +# so replace old file with new.
> +if os.path.exists(filename):
> +os.remove(filename)
> +os.rename(tempfile, filename)
> +return
> +
> +
> +# Create the git_sha1.h header file
> +write_git_sha1_h_file("git_sha1.h")
> +# and update CPPPATH so the git_sha1.h header can be found
> +env.Append(CPPPATH = ["#" + env['build_dir']])
> +
> +
> +
>  if env['platform'] != 'windows':
>  SConscript('loader/SConscript')
>  
> diff --git a/src/mesa/SConscript b/src/mesa/SConscript
> index 434800e..2a340ac 100644
> --- a/src/mesa/SConscript
> +++ b/src/mesa/SConscript
> @@ -4,7 +4,6 @@
>  
>  Import('*')
>  import filecmp
> -import os
>  import subprocess
>  from sys import executable as python_cmd
>  
> @@ -18,10 +17,12 @@ env.Append(CPPPATH = [
>  '#/src/mapi',
>  '#/src/glsl',
>  '#/src/mesa',
> +'#/src/mesa/main',
>  '#/src/gallium/include',
>  '#/src/gallium/auxiliary',
>  Dir('../mapi'), # src/mapi build path
>  Dir('.'), # src/mesa build path
> +Dir('main'),  # src/mesa/main/ build path
>  ])
>  
>  if env['platform'] == 'windows':
> @@ -119,46 +120,6 @@ if env['platform'] not in ('cygwin', 'darwin', 
> 'windows', 'haiku'):
>  env.Append(CPPPATH = [matypes[0].dir])
>  
>  
> -def write_git_sha1_h_file(filename):
> -"""Mesa looks for a git_sha1.h file at compile time in order to display
> -the current git hash id in the GL_VERSION string.  This function tries
> -to retrieve the git hashid and write the header file.  An empty file
> -will be created if anything goes wrong."""
> -
> -args = [ 'git', 'log', '-n', '1', '--oneline' ]
> -try:
> -(commit, foo) = subprocess.Popen(args, 
> stdout=subprocess.PIPE).communicate()
> -except:
> -# git log command didn't work
> -if not os.path.exists(filename):
> -dirname = os.path.dirname(filename)
> -if not os.path.exists(dirname):
> -os.makedirs(dirname)
> -# create an empty file if none already exists
> -f = open(filename, "w")
> -f.close()
> -return
> -
> -commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[0:7]
> -tempfile = "git_sha1.h.tmp"
> -f = open(tempfile, "w")
> - 

Re: [Mesa-dev] Mesa 11.2.2 and Mesa 12.0.0rc3 GLES 3.1 issues with i965 driver

[Mike Gorchak]

Hi,

> You're supposed to get at these functions with eglGetProcAddress() and
such

A'm afraid EGL v1.4 spec forbids obtaining core functions through
eglGetProcAddress(), they should be visible at dynamic linker level.

Anyway, thanks!


On Wed, Jun 15, 2016 at 3:06 PM, Ilia Mirkin  wrote:

> On Wed, Jun 15, 2016 at 2:55 PM, Mike Gorchak
>  wrote:
> > Hi,
> >
> > hm, could you check "cat ./src/mapi/es2api/glapi_mapi_tmp.h | grep
> > glFramebufferParameteri" ?
> >
> > I can see void APIENTRY gl_dispatch_stub_888(GLenum target, GLenum pname,
> > GLint param); instead of glFramebufferParameteri there.
> >
> > Also objdump -x for GLES 2.0 API shows absence of
> glFramebufferParameteri()
> > function as well. Only GLES 3.0 functions are present.
>
> I'm not up on all the latest, but are those supposed to be there? This
> just means that they're not exposed symbols in libGLESv2.so, which
> afaik is right. It's definitely right for libGL.so. You're supposed to
> get at these functions with eglGetProcAddress() and such. However
> perhaps the policy for libGLESv2.so is supposed to be different? Ian
> will know for sure.
>
>   -ilia
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] scons: put the generated git_sha1.h file in top-level src/ directory

[Jose Fonseca]

On 15/06/16 18:58, Brian Paul wrote:

To match what's done in the automake build.
---
  src/SConscript  | 43 +++
  src/mesa/SConscript | 43 ++-
  2 files changed, 45 insertions(+), 41 deletions(-)

diff --git a/src/SConscript b/src/SConscript
index 4ba0a32..719aa69 100644
--- a/src/SConscript
+++ b/src/SConscript
@@ -1,5 +1,6 @@
  Import('*')

+import os


Nitpick: personally I prefer the Python import at the top.


Either way,

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

Re: [Mesa-dev] [PATCH v2] mesa: replace 1.F with 1.0F

[Eric Engestrom]

On Wed, Jun 15, 2016 at 11:19:28PM +0530, Nayan Deshmukh wrote:
> Hi Eric,
> 
> Could you please push both the patches as I don't have the push access.
> 
> Thanks,
> Nayan.

I don't have push access either. Emil will probably be happy to do it
for you though, seeing as this was his idea :)

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

Re: [Mesa-dev] [PATCH 7/7] util: Fix ralloc to use malloc instead of calloc

[Juha-Pekka Heikkila]

On 14.06.2016 18:03, Jason Ekstrand wrote:



On Tue, Jun 14, 2016 at 7:59 AM, Juha-Pekka Heikkila
> wrote:

ralloc originally had had idea of using malloc but somehow
had slipped in calloc. Without these changes rzalloc did double
job of zeroing the memory, first calloc and then memset.
Now change ralloc to use malloc, leave rzalloc to use calloc and
make needed changes in ralloc functions to get things working.

Signed-off-by: Juha-Pekka Heikkila >
---
  src/util/ralloc.c | 49
+
  src/util/ralloc.h |  2 +-
  2 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/src/util/ralloc.c b/src/util/ralloc.c
index 9526011..527385d 100644
--- a/src/util/ralloc.c
+++ b/src/util/ralloc.c
@@ -104,25 +104,12 @@ add_child(ralloc_header *parent, ralloc_header
*info)
  void *
  ralloc_context(const void *ctx)
  {
-   return ralloc_size(ctx, 0);
+   return rzalloc_size(ctx, 0);
  }

-void *
-ralloc_size(const void *ctx, size_t size)
-{
-   /* ralloc_size was originally implemented using calloc, which
meant some
-* code accidentally relied on its zero filling behavior.
-*
-* TODO: Make ralloc_size not zero fill memory, and cleanup any
code that
-* should instead be using rzalloc.
-*/
-   return rzalloc_size(ctx, size);
-}
-
-void *
-rzalloc_size(const void *ctx, size_t size)
+static void*
+ralloc_header_helper(const void *ctx, const void *block)
  {
-   void *block = calloc(1, size + sizeof(ralloc_header));
 ralloc_header *info;
 ralloc_header *parent;

@@ -131,6 +118,12 @@ rzalloc_size(const void *ctx, size_t size)
 info = (ralloc_header *) block;
 parent = ctx != NULL ? get_header(ctx) : NULL;

+   info->child = NULL;
+   info->parent = NULL;
+   info->prev = NULL;
+   info->next = NULL;
+   info->destructor = NULL;
+
 add_child(parent, info);

  #ifdef DEBUG
@@ -140,6 +133,30 @@ rzalloc_size(const void *ctx, size_t size)
 return PTR_FROM_HEADER(info);
  }

+void *
+ralloc_size(const void *ctx, size_t size)
+{
+   void *block;
+
+   if (size + sizeof(ralloc_header) < size )
+  return NULL;
+
+   block = malloc(size + sizeof(ralloc_header));


One more thing that I think I'd like to see you try is to add

memset(block, 139, size + sizeof(ralloc_header));

right here and see if everything still works.  Frequently malloc will
return zerod memory and we'd like to be 100% sure that isn't a problem.
For that matter, I think it'd be good to just put that inside of a
"#ifndef NDEBUG" and leave it so that it gets tested in debug builds.


Both these I think are great ideas, thanks Jason. For IVB I'm probably 
good with Valgrind but for rest of the platforms I cannot go run 
Valgrind in Mark's test system.


As for those other platforms (freedreno and others) that I cannot go 
test I hope to have time to look at over weekend and be back with new 
set again next week.




+   return ralloc_header_helper(ctx, block);
+}
+
+void *
+rzalloc_size(const void *ctx, size_t size)
+{
+   void *block;
+
+   if (size + sizeof(ralloc_header) < size )
+  return NULL;
+
+   block = calloc(1, size + sizeof(ralloc_header));
+   return ralloc_header_helper(ctx, block);
+}
+
  /* helper function - assumes ptr != NULL */
  static void *
  resize(void *ptr, size_t size)
diff --git a/src/util/ralloc.h b/src/util/ralloc.h
index 7587e11..462db7d 100644
--- a/src/util/ralloc.h
+++ b/src/util/ralloc.h
@@ -430,7 +430,7 @@ private:
  \
  public:
   \
 static void* operator new(size_t size, void *mem_ctx)
\
 {
\
-  void *p = ralloc_size(mem_ctx, size);
   \
+  void *p = rzalloc_size(mem_ctx, size);
  \
assert(p != NULL);
\
if (!HAS_TRIVIAL_DESTRUCTOR(TYPE))
\
   ralloc_set_destructor(p, _ralloc_destructor);
\
--
1.9.1

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




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

[Mesa-dev] [Bug 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

--- Comment #5 from Rahul  ---
Yes sure .. I will do ..

Thanks

On Thu, Jun 16, 2016 at 5:44 PM,  wrote:

> Timothy Arceri  changed bug 96552
> 
> What Removed Added
> Resolution --- WONTFIX
> Status NEW RESOLVED
>
> *Comment # 4  on
> bug 96552  from Timothy
> Arceri  *
>
> (In reply to Rahul from comment #3 
> )> I guess i got you ..
> >
> > Thanks,
> > Rahul
>
> Under "Developer git Access" basically submit a number of patches then come
> back and reopen this bug if you still want to contribute further.
>
> --
> 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
>
>

-- 
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] st/mesa: Remove tautological check (v2)

[francians]

From: Francesco Ansanelli 

---
 src/mesa/state_tracker/st_cb_fbo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index a53b95a..950ec3e 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -704,7 +704,7 @@ st_DrawBuffers(struct gl_context *ctx, GLsizei count, const 
GLenum *buffers)
 
/* add the renderbuffers on demand */
for (i = 0; i < fb->_NumColorDrawBuffers; i++) {
-  gl_buffer_index idx = fb->_ColorDrawBufferIndexes[i];
+  GLint idx = fb->_ColorDrawBufferIndexes[i];
 
   if (idx >= 0) {
  st_manager_add_color_renderbuffer(st, fb, idx);
-- 
1.7.9.5

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

[Mesa-dev] [Bug 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Timothy Arceri  ---
(In reply to Rahul from comment #3)
> I guess i got you .. 
> 
> Thanks,
> Rahul

Under "Developer git Access" basically submit a number of patches then come
back and reopen this bug if you still want to contribute further.

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

Re: [Mesa-dev] [PATCH 1/1] r600: Enable FMA on chips that support it

[Marek Olšák]

On Thu, Jun 16, 2016 at 12:47 AM, Glenn Kennard  wrote:
> On Wed, 15 Jun 2016 20:13:13 +0200, Jan Vesely 
> wrote:
>
>> Signed-off-by: Jan Vesely 
>> ---
>> Untested (I don't have the required hw)
>>
>>  src/gallium/drivers/r600/r600_pipe.c   | 5 -
>>  src/gallium/drivers/r600/r600_shader.c | 2 +-
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/r600/r600_pipe.c
>> b/src/gallium/drivers/r600/r600_pipe.c
>> index a49b00f..49c3e1d 100644
>> --- a/src/gallium/drivers/r600/r600_pipe.c
>> +++ b/src/gallium/drivers/r600/r600_pipe.c
>> @@ -548,7 +548,6 @@ static int r600_get_shader_param(struct pipe_screen*
>> pscreen, unsigned shader, e
>> return 0;
>> case PIPE_SHADER_CAP_TGSI_DROUND_SUPPORTED:
>> case PIPE_SHADER_CAP_TGSI_DFRACEXP_DLDEXP_SUPPORTED:
>> -   case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED:
>> case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
>> case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
>> return 0;
>> @@ -558,6 +557,10 @@ static int r600_get_shader_param(struct pipe_screen*
>> pscreen, unsigned shader, e
>>  *https://bugs.freedesktop.org/show_bug.cgi?id=86720
>>  */
>> return 255;
>> +   case PIPE_SHADER_CAP_TGSI_FMA_SUPPORTED:
>> +   // Enable on CYPRESS(EG) and CAYMAN(NI)
>> +   return rscreen->b.family == CHIP_CYPRESS ||
>> +  rscreen->b.family == CHIP_CAYMAN;
>> }
>> return 0;
>>  }
>> diff --git a/src/gallium/drivers/r600/r600_shader.c
>> b/src/gallium/drivers/r600/r600_shader.c
>> index 101f666..35019e3 100644
>> --- a/src/gallium/drivers/r600/r600_shader.c
>> +++ b/src/gallium/drivers/r600/r600_shader.c
>> @@ -8917,7 +8917,7 @@ static const struct r600_shader_tgsi_instruction
>> r600_shader_tgsi_instruction[]
>> [TGSI_OPCODE_MAD]   = { ALU_OP3_MULADD, tgsi_op3},
>> [TGSI_OPCODE_SUB]   = { ALU_OP2_ADD, tgsi_op2},
>> [TGSI_OPCODE_LRP]   = { ALU_OP0_NOP, tgsi_lrp},
>> -   [TGSI_OPCODE_FMA]   = { ALU_OP0_NOP, tgsi_unsupported},
>> +   [TGSI_OPCODE_FMA]   = { ALU_OP3_FMA, tgsi_op3},
>> [TGSI_OPCODE_SQRT]  = { ALU_OP1_SQRT_IEEE,
>> tgsi_trans_srcx_replicate},
>> [TGSI_OPCODE_DP2A]  = { ALU_OP0_NOP, tgsi_unsupported},
>> [22]= { ALU_OP0_NOP, tgsi_unsupported},
>
>
> You probably meant to add the opcode to the eg_shader_tgsi_instruction and
> cm_shader_tgsi_instruction opcode tables rather than the R600/R700 one?
>
>
> I'll also note in passing that FMA on CYPRESS/HEMLOCK has an issue rate of
> 4/cycle vs MULADD 5/cycle since FMA cannot be issued in the 't' slot,
> may or may not affect performance depending on if the GLSL front end decides
> to use fma for mul+add operations. On Cayman/Aruba they are the same rate.

It depends on the application, not the GLSL frontend. Alien Isolation
uses fma everywhere, other games don't AFAIK.

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

[Mesa-dev] [Bug 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

--- Comment #3 from Rahul  ---
I guess i got you .. 

Thanks,
Rahul

-- 
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 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

--- Comment #2 from Rahul  ---
Do you mean 
git pull origin

-
Rahul

-- 
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 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
Please see the steps at http://mesa3d.org/repository.html specifically step 3.

-- 
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 96552] Request for new account for contribution in mesa driver development

[bugzilla-daemon]

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

Bug ID: 96552
   Summary: Request for new account for contribution in mesa
driver development
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: talente...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi, 
I'd like to request an account for contributing in mesa driver.

Thanks,
Rahul

-- 
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 96309] Request for new account

[bugzilla-daemon]

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

Rahul  changed:

   What|Removed |Added

 CC||talente...@gmail.com

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

[Mesa-dev] [Bug 96550] 12.0.0-rc3: mesa_dri_drivers.so linking fails with: relocation R_X86_64_32S against `V4F_COUNT' can not be used when making a shared object

[bugzilla-daemon]

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

Bug ID: 96550
   Summary: 12.0.0-rc3: mesa_dri_drivers.so linking fails with:
relocation R_X86_64_32S against `V4F_COUNT' can not be
used when making a shared object
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: war...@o2.pl
QA Contact: mesa-dev@lists.freedesktop.org

I'm trying to build 12.0.0-rc3 in cross-compile environment.
Build fails at mesa_dri_drivers.so linking with following error:

libtool: link: x86_64-minimyth-linux-gnu-g++  -fPIC -DPIC -shared -nostdlib
/home/piotro/minimyth-dev/images/main/usr/lib/crti.o
/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/crtbeginS.o
 -Wl,--whole-archive ../../.libs/libmesa.a common/.libs/libmegadriver_stub.a
common/.libs/libdricommon.a common/.libs/libxmlconfig.a
i915/.libs/libi915_dri.a i965/.libs/libi965_dri.a r200/.libs/libr200_dri.a
radeon/.libs/libradeon_dri.a swrast/.libs/libswrast_dri.a
-Wl,--no-whole-archive  -lgcrypt -ldrm_intel -ldrm_radeon -ldrm -lexpat
-lpthread -ldl
-L/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0
-L/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/../../../../x86_64-minimyth-linux-gnu/lib
-L/home/piotro/minimyth-dev/images/main/lib
-L/home/piotro/minimyth-dev/images/main/usr/lib -lstdc++ -lm -lc -lgcc_s
/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/crtendS.o
/home/piotro/minimyth-dev/images/main/usr/lib/crtn.o  -flto -march=x86-64
-mtune=generic -O3 -mfpmath=sse -flto -m64 -Wl,-Bsymbolic -Wl,--gc-sections
-Wl,--as-needed -flto -march=x86-64 -mtune=generic -O3 -mfpmath=sse -flto -m64 
 -Wl,-soname -Wl,mesa_dri_drivers.so -o .libs/mesa_dri_drivers.so

/home/piotro/minimyth-dev/images/build/usr/lib/gcc/x86_64-minimyth-linux-gnu/5.3.0/../../../../x86_64-minimyth-linux-gnu/bin/ld:
../../.libs/libmesa.a(xform4.o): relocation R_X86_64_32S against `V4F_COUNT'
can not be used when making a shared object; recompile with -fPIC
../../.libs/libmesa.a(xform4.o): error adding symbols: Bad value
collect2: error: ld returned 1 exit status


11.2.2 builds perfectly in the same environment.

-- 
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] i965: remove remaining tabs in brw_link.cpp

[Timothy Arceri]

---
 src/mesa/drivers/dri/i965/brw_link.cpp | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 16bfbaa..ab2484e 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -210,13 +210,13 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
for (stage = 0; stage < ARRAY_SIZE(shProg->_LinkedShaders); stage++) {
   struct gl_shader *shader = shProg->_LinkedShaders[stage];
   if (!shader)
-continue;
+ continue;
 
   struct gl_program *prog =
-ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
+ ctx->Driver.NewProgram(ctx, _mesa_shader_stage_to_program(stage),
 shader->Name);
   if (!prog)
-   return false;
+return false;
   prog->Parameters = _mesa_new_parameter_list();
 
   _mesa_copy_linked_program_data((gl_shader_stage) stage, shProg, prog);
@@ -231,19 +231,19 @@ brw_link_shader(struct gl_context *ctx, struct 
gl_shader_program *shProg)
* get sent to the shader.
*/
   foreach_in_list(ir_instruction, node, shader->ir) {
-ir_variable *var = node->as_variable();
+ ir_variable *var = node->as_variable();
 
-if ((var == NULL) || (var->data.mode != ir_var_uniform)
-|| (strncmp(var->name, "gl_", 3) != 0))
-   continue;
+ if ((var == NULL) || (var->data.mode != ir_var_uniform)
+ || (strncmp(var->name, "gl_", 3) != 0))
+continue;
 
-const ir_state_slot *const slots = var->get_state_slots();
-assert(slots != NULL);
+ const ir_state_slot *const slots = var->get_state_slots();
+ assert(slots != NULL);
 
-for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
-   _mesa_add_state_reference(prog->Parameters,
- (gl_state_index *) slots[i].tokens);
-}
+ for (unsigned int i = 0; i < var->get_num_state_slots(); i++) {
+_mesa_add_state_reference(prog->Parameters,
+  (gl_state_index *) slots[i].tokens);
+ }
   }
 
   do_set_program_inouts(shader->ir, prog, shader->Stage);
-- 
2.5.5

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