[Mesa-dev] [PATCH] radeonsi/nir: fix scanning of bindless images

[Timothy Arceri]

Fixes: d62d434fe920 ("ac/nir_to_llvm: add image bindless support")
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 75 ++--
 1 file changed, 37 insertions(+), 38 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 938b0efcb76..5a925f19e09 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -181,39 +181,48 @@ static void scan_instruction(const struct nir_shader *nir,
case nir_intrinsic_load_tess_level_outer:
info->reads_tess_factors = true;
break;
-   case nir_intrinsic_image_deref_load: {
-   nir_variable *var = intrinsic_get_var(intr);
-   if (var->data.bindless) {
-   info->uses_bindless_images = true;
+   case nir_intrinsic_bindless_image_load:
+   info->uses_bindless_images = true;
 
-   if (glsl_get_sampler_dim(var->type) == 
GLSL_SAMPLER_DIM_BUF)
-   info->uses_bindless_buffer_load = true;
-   else
-   info->uses_bindless_image_load = true;
-   }
+   if (nir_intrinsic_image_dim(intr) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_load = true;
+   else
+   info->uses_bindless_image_load = true;
break;
-   }
-   case nir_intrinsic_image_deref_size:
-   case nir_intrinsic_image_deref_samples: {
-   nir_variable *var = intrinsic_get_var(intr);
-   if (var->data.bindless)
-   info->uses_bindless_images = true;
+   case nir_intrinsic_bindless_image_size:
+   case nir_intrinsic_bindless_image_samples:
+   info->uses_bindless_images = true;
break;
-   }
-   case nir_intrinsic_image_deref_store: {
-   const nir_deref_instr *image_deref = 
nir_instr_as_deref(intr->src[0].ssa->parent_instr);
-   nir_variable *var = intrinsic_get_var(intr);
-   if (var->data.bindless) {
-   info->uses_bindless_images = true;
+   case nir_intrinsic_bindless_image_store:
+   info->uses_bindless_images = true;
+
+   if (nir_intrinsic_image_dim(intr) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_store = true;
+   else
+   info->uses_bindless_image_store = true;
+
+   info->writes_memory = true;
+   break;
+   case nir_intrinsic_image_deref_store:
+   info->writes_memory = true;
+   break;
+   case nir_intrinsic_bindless_image_atomic_add:
+   case nir_intrinsic_bindless_image_atomic_min:
+   case nir_intrinsic_bindless_image_atomic_max:
+   case nir_intrinsic_bindless_image_atomic_and:
+   case nir_intrinsic_bindless_image_atomic_or:
+   case nir_intrinsic_bindless_image_atomic_xor:
+   case nir_intrinsic_bindless_image_atomic_exchange:
+   case nir_intrinsic_bindless_image_atomic_comp_swap:
+   info->uses_bindless_images = true;
+
+   if (nir_intrinsic_image_dim(intr) == 
GLSL_SAMPLER_DIM_BUF)
+   info->uses_bindless_buffer_atomic = true;
+   else
+   info->uses_bindless_image_atomic = true;
 
-   if (glsl_get_sampler_dim(image_deref->type) == 
GLSL_SAMPLER_DIM_BUF)
-   info->uses_bindless_buffer_store = true;
-   else
-   info->uses_bindless_image_store = true;
-   }
info->writes_memory = true;
break;
-   }
case nir_intrinsic_image_deref_atomic_add:
case nir_intrinsic_image_deref_atomic_min:
case nir_intrinsic_image_deref_atomic_max:
@@ -221,19 +230,9 @@ static void scan_instruction(const struct nir_shader *nir,
case nir_intrinsic_image_deref_atomic_or:
case nir_intrinsic_image_deref_atomic_xor:
case nir_intrinsic_image_deref_atomic_exchange:
-   case nir_intrinsic_image_deref_atomic_comp_swap: {
-   nir_variable *var = intrinsic_get_var(intr);
-   if (var->data.bindless) {

Re: [Mesa-dev] [PATCH] nir: optimize gl_SampleMaskIn to gl_HelperInvocation for radeonsi when possible

[Timothy Arceri]

On 16/4/19 1:14 pm, Marek Olšák wrote:



On Mon, Apr 15, 2019, 10:41 PM Timothy Arceri > wrote:




On 16/4/19 7:03 am, Marek Olšák wrote:
 > ping
 >
 > On Tue, Apr 9, 2019 at 10:03 PM Marek Olšák mailto:mar...@gmail.com>
 > >> wrote:
 >
 >     From: Marek Olšák mailto:marek.ol...@amd.com> >>
 >
 >     ---
 >       src/compiler/nir/nir.h                    |  8 +
 >       src/compiler/nir/nir_opt_intrinsics.c     | 40
+--
 >       src/gallium/drivers/radeonsi/si_get.c     |  1 +
 >       src/mesa/state_tracker/st_glsl_to_nir.cpp |  1 +
 >       4 files changed, 48 insertions(+), 2 deletions(-)
 >
 >     diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
 >     index 09950bf3398..d3874705235 100644
 >     --- a/src/compiler/nir/nir.h
 >     +++ b/src/compiler/nir/nir.h
 >     @@ -2283,20 +2283,28 @@ typedef struct
nir_shader_compiler_options {
 >           *
 >           * This depends on some possibly hw implementation details,
 >     which may
 >           * not be true for all hw.  In particular that the FS is
only
 >     executed
 >           * for covered samples or for helper invocations.  So,
do not
 >     blindly
 >           * enable this option.
 >           *
 >           * Note: See also issue #22 in ARB_shader_image_load_store
 >           */
 >          bool lower_helper_invocation;
 >
 >     +   /**
 >     +    * Convert gl_SampleMaskIn to gl_HelperInvocation as follows:
 >     +    *
 >     +    *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
 >     +    *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
 >     +    */
 >     +   bool optimize_sample_mask_in;
 >     +
 >          bool lower_cs_local_index_from_id;
 >          bool lower_cs_local_id_from_index;
 >
 >          bool lower_device_index_to_zero;
 >
 >          /* Set if nir_lower_wpos_ytransform() should also invert
 >     gl_PointCoord. */
 >          bool lower_wpos_pntc;
 >
 >          bool lower_hadd;
 >          bool lower_add_sat;
 >     diff --git a/src/compiler/nir/nir_opt_intrinsics.c
 >     b/src/compiler/nir/nir_opt_intrinsics.c
 >     index 7b054faa204..2f9e4e466c9 100644
 >     --- a/src/compiler/nir/nir_opt_intrinsics.c
 >     +++ b/src/compiler/nir/nir_opt_intrinsics.c
 >     @@ -22,21 +22,22 @@
 >        */
 >
 >       #include "nir.h"
 >       #include "nir_builder.h"
 >
 >       /**
 >        * \file nir_opt_intrinsics.c
 >        */
 >
 >       static bool
 >     -opt_intrinsics_impl(nir_function_impl *impl)
 >     +opt_intrinsics_impl(nir_function_impl *impl,
 >     +                    const struct nir_shader_compiler_options
*options)
 >       {
 >          nir_builder b;
 >          nir_builder_init(, impl);
 >          bool progress = false;
 >
 >          nir_foreach_block(block, impl) {
 >             nir_foreach_instr_safe(instr, block) {
 >                if (instr->type != nir_instr_type_intrinsic)
 >                   continue;
 >
 >     @@ -48,20 +49,55 @@ opt_intrinsics_impl(nir_function_impl *impl)
 >                case nir_intrinsic_vote_any:
 >                case nir_intrinsic_vote_all:
 >                   if (nir_src_is_const(intrin->src[0]))
 >                      replacement = nir_ssa_for_src(,
intrin->src[0], 1);
 >                   break;
 >                case nir_intrinsic_vote_feq:
 >                case nir_intrinsic_vote_ieq:
 >                   if (nir_src_is_const(intrin->src[0]))
 >                      replacement = nir_imm_true();
 >                   break;
 >     +         case nir_intrinsic_load_sample_mask_in:
 >     +            /* Transform:
 >     +             *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
 >     +             *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
 >     +             */
 >     +            if (!options->optimize_sample_mask_in)
 >     +               continue;
 >     +
 >     +            nir_foreach_use_safe(use_src, >dest.ssa) {
 >     +               if (use_src->parent_instr->type ==
nir_instr_type_alu) {
 >     +                  nir_alu_instr *alu =
 >     nir_instr_as_alu(use_src->parent_instr);
 >     +
 >     +                  if (alu->op == nir_op_ieq ||
 >     +                      alu->op == nir_op_ine) {
 >     +                     /* Check for 0 in either operand. */
 >     +                     nir_const_value *const_val =
 >     +   
  

Re: [Mesa-dev] [PATCH] panfrost: Fix ->set_vertex_buffers() for partial vertex bufs updates

[Alyssa Rosenzweig]

The patches I just posted to the list conflict with this but I think do
what you want. Could you try those?

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

Re: [Mesa-dev] [PATCH] nir: optimize gl_SampleMaskIn to gl_HelperInvocation for radeonsi when possible

[Marek Olšák]

On Mon, Apr 15, 2019, 10:41 PM Timothy Arceri  wrote:

>
>
> On 16/4/19 7:03 am, Marek Olšák wrote:
> > ping
> >
> > On Tue, Apr 9, 2019 at 10:03 PM Marek Olšák  > > wrote:
> >
> > From: Marek Olšák mailto:marek.ol...@amd.com>>
> >
> > ---
> >   src/compiler/nir/nir.h|  8 +
> >   src/compiler/nir/nir_opt_intrinsics.c | 40
> +--
> >   src/gallium/drivers/radeonsi/si_get.c |  1 +
> >   src/mesa/state_tracker/st_glsl_to_nir.cpp |  1 +
> >   4 files changed, 48 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> > index 09950bf3398..d3874705235 100644
> > --- a/src/compiler/nir/nir.h
> > +++ b/src/compiler/nir/nir.h
> > @@ -2283,20 +2283,28 @@ typedef struct nir_shader_compiler_options {
> >   *
> >   * This depends on some possibly hw implementation details,
> > which may
> >   * not be true for all hw.  In particular that the FS is only
> > executed
> >   * for covered samples or for helper invocations.  So, do not
> > blindly
> >   * enable this option.
> >   *
> >   * Note: See also issue #22 in ARB_shader_image_load_store
> >   */
> >  bool lower_helper_invocation;
> >
> > +   /**
> > +* Convert gl_SampleMaskIn to gl_HelperInvocation as follows:
> > +*
> > +*   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
> > +*   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
> > +*/
> > +   bool optimize_sample_mask_in;
> > +
> >  bool lower_cs_local_index_from_id;
> >  bool lower_cs_local_id_from_index;
> >
> >  bool lower_device_index_to_zero;
> >
> >  /* Set if nir_lower_wpos_ytransform() should also invert
> > gl_PointCoord. */
> >  bool lower_wpos_pntc;
> >
> >  bool lower_hadd;
> >  bool lower_add_sat;
> > diff --git a/src/compiler/nir/nir_opt_intrinsics.c
> > b/src/compiler/nir/nir_opt_intrinsics.c
> > index 7b054faa204..2f9e4e466c9 100644
> > --- a/src/compiler/nir/nir_opt_intrinsics.c
> > +++ b/src/compiler/nir/nir_opt_intrinsics.c
> > @@ -22,21 +22,22 @@
> >*/
> >
> >   #include "nir.h"
> >   #include "nir_builder.h"
> >
> >   /**
> >* \file nir_opt_intrinsics.c
> >*/
> >
> >   static bool
> > -opt_intrinsics_impl(nir_function_impl *impl)
> > +opt_intrinsics_impl(nir_function_impl *impl,
> > +const struct nir_shader_compiler_options
> *options)
> >   {
> >  nir_builder b;
> >  nir_builder_init(, impl);
> >  bool progress = false;
> >
> >  nir_foreach_block(block, impl) {
> > nir_foreach_instr_safe(instr, block) {
> >if (instr->type != nir_instr_type_intrinsic)
> >   continue;
> >
> > @@ -48,20 +49,55 @@ opt_intrinsics_impl(nir_function_impl *impl)
> >case nir_intrinsic_vote_any:
> >case nir_intrinsic_vote_all:
> >   if (nir_src_is_const(intrin->src[0]))
> >  replacement = nir_ssa_for_src(, intrin->src[0],
> 1);
> >   break;
> >case nir_intrinsic_vote_feq:
> >case nir_intrinsic_vote_ieq:
> >   if (nir_src_is_const(intrin->src[0]))
> >  replacement = nir_imm_true();
> >   break;
> > + case nir_intrinsic_load_sample_mask_in:
> > +/* Transform:
> > + *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
> > + *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
> > + */
> > +if (!options->optimize_sample_mask_in)
> > +   continue;
> > +
> > +nir_foreach_use_safe(use_src, >dest.ssa) {
> > +   if (use_src->parent_instr->type ==
> nir_instr_type_alu) {
> > +  nir_alu_instr *alu =
> > nir_instr_as_alu(use_src->parent_instr);
> > +
> > +  if (alu->op == nir_op_ieq ||
> > +  alu->op == nir_op_ine) {
> > + /* Check for 0 in either operand. */
> > + nir_const_value *const_val =
> > + nir_src_as_const_value(alu->src[0].src);
> > + if (!const_val)
> > +const_val =
> > nir_src_as_const_value(alu->src[1].src);
> > + if (!const_val || const_val->i32[0] != 0)
> > +continue;
> > +
> > + nir_ssa_def *new_expr =
> > nir_load_helper_invocation(, 1);
> > +
> > + if (alu->op == nir_op_ine32)
>
> How can this be nir_op_ine32 when the outer if condition is:
>
> alu->op == nir_op_ieq 

Re: [Mesa-dev] [PATCH] nir: optimize gl_SampleMaskIn to gl_HelperInvocation for radeonsi when possible

[Timothy Arceri]

On 16/4/19 7:03 am, Marek Olšák wrote:

ping

On Tue, Apr 9, 2019 at 10:03 PM Marek Olšák > wrote:


From: Marek Olšák mailto:marek.ol...@amd.com>>

---
  src/compiler/nir/nir.h                    |  8 +
  src/compiler/nir/nir_opt_intrinsics.c     | 40 +--
  src/gallium/drivers/radeonsi/si_get.c     |  1 +
  src/mesa/state_tracker/st_glsl_to_nir.cpp |  1 +
  4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 09950bf3398..d3874705235 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2283,20 +2283,28 @@ typedef struct nir_shader_compiler_options {
      *
      * This depends on some possibly hw implementation details,
which may
      * not be true for all hw.  In particular that the FS is only
executed
      * for covered samples or for helper invocations.  So, do not
blindly
      * enable this option.
      *
      * Note: See also issue #22 in ARB_shader_image_load_store
      */
     bool lower_helper_invocation;

+   /**
+    * Convert gl_SampleMaskIn to gl_HelperInvocation as follows:
+    *
+    *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
+    *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
+    */
+   bool optimize_sample_mask_in;
+
     bool lower_cs_local_index_from_id;
     bool lower_cs_local_id_from_index;

     bool lower_device_index_to_zero;

     /* Set if nir_lower_wpos_ytransform() should also invert
gl_PointCoord. */
     bool lower_wpos_pntc;

     bool lower_hadd;
     bool lower_add_sat;
diff --git a/src/compiler/nir/nir_opt_intrinsics.c
b/src/compiler/nir/nir_opt_intrinsics.c
index 7b054faa204..2f9e4e466c9 100644
--- a/src/compiler/nir/nir_opt_intrinsics.c
+++ b/src/compiler/nir/nir_opt_intrinsics.c
@@ -22,21 +22,22 @@
   */

  #include "nir.h"
  #include "nir_builder.h"

  /**
   * \file nir_opt_intrinsics.c
   */

  static bool
-opt_intrinsics_impl(nir_function_impl *impl)
+opt_intrinsics_impl(nir_function_impl *impl,
+                    const struct nir_shader_compiler_options *options)
  {
     nir_builder b;
     nir_builder_init(, impl);
     bool progress = false;

     nir_foreach_block(block, impl) {
        nir_foreach_instr_safe(instr, block) {
           if (instr->type != nir_instr_type_intrinsic)
              continue;

@@ -48,20 +49,55 @@ opt_intrinsics_impl(nir_function_impl *impl)
           case nir_intrinsic_vote_any:
           case nir_intrinsic_vote_all:
              if (nir_src_is_const(intrin->src[0]))
                 replacement = nir_ssa_for_src(, intrin->src[0], 1);
              break;
           case nir_intrinsic_vote_feq:
           case nir_intrinsic_vote_ieq:
              if (nir_src_is_const(intrin->src[0]))
                 replacement = nir_imm_true();
              break;
+         case nir_intrinsic_load_sample_mask_in:
+            /* Transform:
+             *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
+             *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
+             */
+            if (!options->optimize_sample_mask_in)
+               continue;
+
+            nir_foreach_use_safe(use_src, >dest.ssa) {
+               if (use_src->parent_instr->type == nir_instr_type_alu) {
+                  nir_alu_instr *alu =
nir_instr_as_alu(use_src->parent_instr);
+
+                  if (alu->op == nir_op_ieq ||
+                      alu->op == nir_op_ine) {
+                     /* Check for 0 in either operand. */
+                     nir_const_value *const_val =
+                         nir_src_as_const_value(alu->src[0].src);
+                     if (!const_val)
+                        const_val =
nir_src_as_const_value(alu->src[1].src);
+                     if (!const_val || const_val->i32[0] != 0)
+                        continue;
+
+                     nir_ssa_def *new_expr =
nir_load_helper_invocation(, 1);
+
+                     if (alu->op == nir_op_ine32)


How can this be nir_op_ine32 when the outer if condition is:

alu->op == nir_op_ieq || alu->op == nir_op_ine

??


+                        new_expr = nir_inot(, new_expr);
+
+                     nir_ssa_def_rewrite_uses(>dest.dest.ssa,
+ 
nir_src_for_ssa(new_expr));

+                     nir_instr_remove(>instr);
+                     continue;
+                  }
+               }
+            }
+            continue;
           default:
              break;
           }

           if (!replacement)
  

[Mesa-dev] [PATCH 2/2] panfrost: Fixup vertex offsets to prevent shadow copy

[Alyssa Rosenzweig]

Mali attribute buffers have to be 64-byte aligned. However, Gallium
enforces no such requirement; for unaligned buffers, we were previously
forced to create a shadow copy (slow!). To prevent this, we instead use
the offseted buffer's address with the lower bits masked off, and then
add those masked off bits to the src_offset. Proof of correctness
included, possibly for the opportunity to say "QED" unironically.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 104 +
 src/gallium/drivers/panfrost/pan_context.h |   6 +-
 2 files changed, 67 insertions(+), 43 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 75a975871db..d7d658fec22 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -735,6 +735,15 @@ panfrost_emit_varying_descriptor(
 ctx->payload_tiler.postfix.varyings = varyings_p;
 }
 
+static mali_ptr
+panfrost_vertex_buffer_address(struct panfrost_context *ctx, unsigned i)
+{
+struct pipe_vertex_buffer *buf = >vertex_buffers[i];
+struct panfrost_resource *rsrc = (struct panfrost_resource *) 
(buf->buffer.resource);
+
+return rsrc->bo->gpu + buf->buffer_offset;
+}
+
 /* Emits attributes and varying descriptors, which should be called every draw,
  * excepting some obscure circumstances */
 
@@ -752,42 +761,20 @@ panfrost_emit_vertex_data(struct panfrost_context *ctx, 
struct panfrost_job *job
 struct pipe_vertex_buffer *buf = >vertex_buffers[i];
 struct panfrost_resource *rsrc = (struct panfrost_resource *) 
(buf->buffer.resource);
 
-/* Let's figure out the layout of the attributes in memory so
- * we can be smart about size computation. The idea is to
- * figure out the maximum src_offset, which tells us the latest
- * spot a vertex could start. Meanwhile, we figure out the size
- * of the attribute memory (assuming interleaved
- * representation) and tack on the max src_offset for a
- * reasonably good upper bound on the size.
- *
- * Proving correctness is left as an exercise to the reader.
- */
+if (!rsrc) continue;
 
-unsigned max_src_offset = 0;
+/* Align to 64 bytes by masking off the lower bits. This
+ * will be adjusted back when we fixup the src_offset in
+ * mali_attr_meta */
 
-for (unsigned j = 0; j < ctx->vertex->num_elements; ++j) {
-if (ctx->vertex->pipe[j].vertex_buffer_index != i) 
continue;
-max_src_offset = MAX2(max_src_offset, 
ctx->vertex->pipe[j].src_offset);
-}
+mali_ptr addr = panfrost_vertex_buffer_address(ctx, i) & ~63;
 
 /* Offset vertex count by draw_start to make sure we upload 
enough */
 attrs[i].stride = buf->stride;
-attrs[i].size = buf->stride * (ctx->payload_vertex.draw_start 
+ invocation_count) + max_src_offset;
-
-/* Vertex elements are -already- GPU-visible, at
- * rsrc->gpu. However, attribute buffers must be 64 aligned. If
- * it is not, for now we have to duplicate the buffer. */
+attrs[i].size = rsrc->base.width0;
 
-mali_ptr effective_address = rsrc ? (rsrc->bo->gpu + 
buf->buffer_offset) : 0;
-
-if (effective_address & 63) {
-attrs[i].elements = panfrost_upload_transient(ctx, 
rsrc->bo->cpu + buf->buffer_offset, attrs[i].size) | MALI_ATTR_LINEAR;
-} else if (effective_address) {
-panfrost_job_add_bo(job, rsrc->bo);
-attrs[i].elements = effective_address | 
MALI_ATTR_LINEAR;
-} else {
-/* Leave unset? */
-}
+panfrost_job_add_bo(job, rsrc->bo);
+attrs[i].elements = addr | MALI_ATTR_LINEAR;
 }
 
 ctx->payload_vertex.postfix.attributes = 
panfrost_upload_transient(ctx, attrs, ctx->vertex_buffer_count * sizeof(union 
mali_attr));
@@ -804,6 +791,53 @@ panfrost_writes_point_size(struct panfrost_context *ctx)
 return vs->writes_point_size && ctx->payload_tiler.prefix.draw_mode == 
MALI_POINTS;
 }
 
+/* Stage the attribute descriptors so we can adjust src_offset
+ * to let BOs align nicely */
+
+static void
+panfrost_stage_attributes(struct panfrost_context *ctx)
+{
+struct panfrost_vertex_state *so = ctx->vertex;
+
+size_t sz = sizeof(struct mali_attr_meta) * so->num_elements;
+struct panfrost_transfer transfer = panfrost_allocate_transient(ctx, 
sz);
+struct mali_attr_meta *target = (struct mali_attr_meta *) transfer.cpu;

[Mesa-dev] [PATCH 1/2] panfrost: Track BO lifetime with jobs and reference counts

[Alyssa Rosenzweig]

This (fairly large) patch continues work surrounding the panfrost_job
abstraction to improve job lifetime management. In particular, we add
infrastructure to track which BOs are used by a particular job
(currently limited to the vertex buffer BOs), to reference count these
BOs, and to automatically manage the BOs memory based on the reference
count. This set of changes serves as a code cleanup, as a way of future
proofing for allowing flushing BOs, and immediately as a bugfix to
workaround the missing reference counting for vertex buffer BOs.
Meanwhile, there are a few cleanups to vertex buffer handling code
itself, so in the short-term, this allows us to remove the costly VBO
staging workaround, since this patch addresses the underlying causes.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c  | 37 --
 src/gallium/drivers/panfrost/pan_context.h  |  6 +-
 src/gallium/drivers/panfrost/pan_drm.c  |  6 ++
 src/gallium/drivers/panfrost/pan_job.c  | 82 +
 src/gallium/drivers/panfrost/pan_job.h  | 16 
 src/gallium/drivers/panfrost/pan_resource.c | 70 +-
 src/gallium/drivers/panfrost/pan_resource.h | 13 
 src/gallium/drivers/panfrost/pan_screen.c   |  2 +-
 src/gallium/drivers/panfrost/pan_screen.h   |  5 +-
 9 files changed, 208 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 0c97c0a2b43..75a975871db 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -36,6 +36,8 @@
 #include "util/u_memory.h"
 #include "util/u_vbuf.h"
 #include "util/half_float.h"
+#include "util/u_helpers.h"
+#include "util/u_format.h"
 #include "indices/u_primconvert.h"
 #include "tgsi/tgsi_parse.h"
 
@@ -737,7 +739,7 @@ panfrost_emit_varying_descriptor(
  * excepting some obscure circumstances */
 
 static void
-panfrost_emit_vertex_data(struct panfrost_context *ctx)
+panfrost_emit_vertex_data(struct panfrost_context *ctx, struct panfrost_job 
*job)
 {
 /* TODO: Only update the dirtied buffers */
 union mali_attr attrs[PIPE_MAX_ATTRIBS];
@@ -745,6 +747,8 @@ panfrost_emit_vertex_data(struct panfrost_context *ctx)
 unsigned invocation_count = 
MALI_NEGATIVE(ctx->payload_tiler.prefix.invocation_count);
 
 for (int i = 0; i < ctx->vertex_buffer_count; ++i) {
+if (!(ctx->vb_mask & (1 << i))) continue;
+
 struct pipe_vertex_buffer *buf = >vertex_buffers[i];
 struct panfrost_resource *rsrc = (struct panfrost_resource *) 
(buf->buffer.resource);
 
@@ -776,9 +780,10 @@ panfrost_emit_vertex_data(struct panfrost_context *ctx)
 
 mali_ptr effective_address = rsrc ? (rsrc->bo->gpu + 
buf->buffer_offset) : 0;
 
-if (effective_address) {
+if (effective_address & 63) {
 attrs[i].elements = panfrost_upload_transient(ctx, 
rsrc->bo->cpu + buf->buffer_offset, attrs[i].size) | MALI_ATTR_LINEAR;
 } else if (effective_address) {
+panfrost_job_add_bo(job, rsrc->bo);
 attrs[i].elements = effective_address | 
MALI_ATTR_LINEAR;
 } else {
 /* Leave unset? */
@@ -807,7 +812,7 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool 
with_vertex_data)
 struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
 
 if (with_vertex_data) {
-panfrost_emit_vertex_data(ctx);
+panfrost_emit_vertex_data(ctx, job);
 }
 
 bool msaa = ctx->rasterizer->base.multisample;
@@ -1252,7 +1257,8 @@ panfrost_link_jobs(struct panfrost_context *ctx)
 
 static void
 panfrost_submit_frame(struct panfrost_context *ctx, bool flush_immediate,
- struct pipe_fence_handle **fence)
+ struct pipe_fence_handle **fence,
+  struct panfrost_job *job)
 {
 struct pipe_context *gallium = (struct pipe_context *) ctx;
 struct panfrost_screen *screen = pan_screen(gallium->screen);
@@ -1274,15 +1280,15 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
bool flush_immediate,
 #ifndef DRY_RUN
 
 bool is_scanout = panfrost_is_scanout(ctx);
-int fragment_id = screen->driver->submit_vs_fs_job(ctx, has_draws, 
is_scanout);
+screen->driver->submit_vs_fs_job(ctx, has_draws, is_scanout);
 
 /* If visual, we can stall a frame */
 
 if (!flush_immediate)
 screen->driver->force_flush_fragment(ctx, fence);
 
-screen->last_fragment_id = fragment_id;
 screen->last_fragment_flushed = false;
+screen->last_job = job;
 
 /* If readback, flush now (hurts the pipelined performance) */
 if (flush_immediate)
@@ -1317,7 +1323,7 @@ panfrost_flush(
 bool flush_immediate = flags & 

[Mesa-dev] [PATCH 0/2] Avoid costly vertex staging buffer

[Alyssa Rosenzweig]

Due to a series of bugs (essentially, a GPU-side use-after-free caused
by a race condition, and a hardware limitation requiring 64-byte
alignment of vertex buffer addresses), we previously copied all vertex
data to a staging buffer and passed that staging buffer to the hardware
instead. Although correct, this was a performance disaster (deploying
the workaround to glmark's refract, a scene unaffected by the bug but
affected by the costly workaround, dropped performance from 19fps to
6fps).

This series fixes each of these bugs, by introducing BO reference
counting, stubs for future work for flushing BOs (thought to be
necessary to fix this bug -- it turned out not to be, but is left in the
series as it will be necessary in the short-term future), and an offset
fixup. In total, this patch removes the staging copy in all cases
visible to us (although Gallium has to do a staging copy for user
pointers).  Performance is helped dramatically :)

Alyssa Rosenzweig (2):
  panfrost: Track BO lifetime with jobs and reference counts
  panfrost: Fixup vertex offsets to prevent shadow copy

 src/gallium/drivers/panfrost/pan_context.c  | 137 +++-
 src/gallium/drivers/panfrost/pan_context.h  |  12 +-
 src/gallium/drivers/panfrost/pan_drm.c  |   6 +
 src/gallium/drivers/panfrost/pan_job.c  |  82 
 src/gallium/drivers/panfrost/pan_job.h  |  16 +++
 src/gallium/drivers/panfrost/pan_resource.c |  70 +-
 src/gallium/drivers/panfrost/pan_resource.h |  13 ++
 src/gallium/drivers/panfrost/pan_screen.c   |   2 +-
 src/gallium/drivers/panfrost/pan_screen.h   |   5 +-
 9 files changed, 273 insertions(+), 70 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [Bug 110441] [llvmpipe] complex-loop-analysis-bug regression

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #3 from Roland Scheidegger  ---
Fixed by 88e0bbf24aa82000195d10c7873f881d190b825b.

-- 
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 110442] [softpipe] piglit egl-create-pbuffer-surface regression

[bugzilla-daemon]

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

Bug ID: 110442
   Summary: [softpipe] piglit egl-create-pbuffer-surface
regression
   Product: Mesa
   Version: 19.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/softpipe
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: mar...@gmail.com

$ ./bin/egl-create-pbuffer-surface -auto
Probe color at (0,0)
  Expected: 1.00 0.00 1.00 1.00
  Observed: 1.00 1.00 1.00 1.00
PIGLIT: {"result": "fail" }



c5c38e831ee8113cf97fb5308fbb687464ae2f0e is the first bad commit
commit c5c38e831ee8113cf97fb5308fbb687464ae2f0e
Author: Marek Olšák 
Date:   Mon Aug 6 07:05:19 2018 -0400

mesa: implement ARB/KHR_parallel_shader_compile

Tested by piglit.

:04 04 13a50a4e506396dc21a20d19964263d50cba4381
088869329799f07a6d75284b38b30bebde64deb7 M  docs
:04 04 9bccedb08230b04ca2d228254db016e1d2628b37
c46fd72e46ca87dd09845ddd2e11ad37669b6875 M  src
bisect run success

-- 
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] gallivm: fix bogus assert in get_indirect_index

[Brian Paul]

On 04/15/2019 01:39 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

0 is a valid value as max index, and the code handles it fine. This isn't
commonly seen, as it will only happen with array declarations of size 1.
The assert was introduced with a3c898dc97ec5f0e0b93b2ee180bdf8ca3bab14c.

Fixes piglit tests/shaders/complex-loop-analysis-bug.shader_test
Bugzilla: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2Fshow_bug.cgi%3Fid%3D110441data=02%7C01%7Cbrianp%40vmware.com%7Cc4b58aeaf4c245f7794e08d6c1da2226%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636909539954259111sdata=l%2BScozK4SM92MrI4bIo7CBa1HujD0OFeKDz9ixvUdI8%3Dreserved=0
---
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 0f5b3d9acb7..d6af1d84471 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -1108,7 +1108,7 @@ get_indirect_index(struct lp_build_tgsi_soa_context *bld,
  * larger than the declared size but smaller than the buffer size.
  */
 if (reg_file != TGSI_FILE_CONSTANT) {
-  assert(index_limit > 0);
+  assert(index_limit >= 0);
max_index = lp_build_const_int_vec(bld->bld_base.base.gallivm,
   uint_bld->type, index_limit);
  



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] radv: enable shaderInt8 on SI and CIK

[Bas Nieuwenhuizen]

r-b

On Mon, Apr 15, 2019 at 5:42 PM Samuel Pitoiset
 wrote:
>
> No CTS failures.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c  | 5 ++---
>  src/amd/vulkan/radv_extensions.py | 2 +-
>  2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index c517b56cd0f..998d6f02eb2 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -901,9 +901,8 @@ void radv_GetPhysicalDeviceFeatures2(
> case 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR: {
> VkPhysicalDeviceFloat16Int8FeaturesKHR *features =
> (VkPhysicalDeviceFloat16Int8FeaturesKHR*)ext;
> -   bool enabled = pdevice->rad_info.chip_class >= VI;
> -   features->shaderFloat16 = enabled && HAVE_LLVM >= 
> 0x0800;
> -   features->shaderInt8 = enabled;
> +   features->shaderFloat16 = 
> pdevice->rad_info.chip_class >= VI && HAVE_LLVM >= 0x0800;
> +   features->shaderInt8 = true;
> break;
> }
> default:
> diff --git a/src/amd/vulkan/radv_extensions.py 
> b/src/amd/vulkan/radv_extensions.py
> index 3d0a0c4343e..13fe391e623 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -82,7 +82,7 @@ EXTENSIONS = [
>  Extension('VK_KHR_relaxed_block_layout',  1, True),
>  Extension('VK_KHR_sampler_mirror_clamp_to_edge',  1, True),
>  Extension('VK_KHR_shader_draw_parameters',1, True),
> -Extension('VK_KHR_shader_float16_int8',   1, 
> 'device->rad_info.chip_class >= VI'),
> +Extension('VK_KHR_shader_float16_int8',   1, True),
>  Extension('VK_KHR_storage_buffer_storage_class',  1, True),
>  Extension('VK_KHR_surface',  25, 
> 'RADV_HAS_SURFACE'),
>  Extension('VK_KHR_surface_protected_capabilities',1, 
> 'RADV_HAS_SURFACE'),
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109535] [Tracker] Mesa 19.0 release tracker

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Depends on|110441  |


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=110441
[Bug 110441] [llvmpipe] complex-loop-analysis-bug regression
-- 
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 110441] [llvmpipe] complex-loop-analysis-bug regression

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Blocks|109535  |

--- Comment #2 from Dylan Baker  ---
Vinson, please don't add bugs to release trackers after that release has
already happened.


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109535
[Bug 109535] [Tracker] Mesa 19.0 release tracker
-- 
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 109535] [Tracker] Mesa 19.0 release tracker

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

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

--- Comment #1 from Dylan Baker  ---
Mesa 19.0 was released, this tracker is no longer necessary.

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

Re: [Mesa-dev] [PATCH v2 1/3] ac: add support for more types with struct/raw LLVM intrinsics

[Marek Olšák]

On Mon, Apr 15, 2019 at 12:40 PM Samuel Pitoiset 
wrote:

> LLVM 9+ now supports 8-bit and 16-bit types.
>
> v2: - rebase on master (without the vec3 change)
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 46 +++---
>  1 file changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> index 8f40ddda0b5..92dd4104592 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -1135,6 +1135,7 @@ ac_build_llvm8_buffer_store_common(struct
> ac_llvm_context *ctx,
>LLVMValueRef voffset,
>LLVMValueRef soffset,
>unsigned num_channels,
> +  LLVMTypeRef base_type,
>

Can this be called return_channel_type?

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

Re: [Mesa-dev] [PATCH] nir: optimize gl_SampleMaskIn to gl_HelperInvocation for radeonsi when possible

[Marek Olšák]

ping

On Tue, Apr 9, 2019 at 10:03 PM Marek Olšák  wrote:

> From: Marek Olšák 
>
> ---
>  src/compiler/nir/nir.h|  8 +
>  src/compiler/nir/nir_opt_intrinsics.c | 40 +--
>  src/gallium/drivers/radeonsi/si_get.c |  1 +
>  src/mesa/state_tracker/st_glsl_to_nir.cpp |  1 +
>  4 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 09950bf3398..d3874705235 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2283,20 +2283,28 @@ typedef struct nir_shader_compiler_options {
>  *
>  * This depends on some possibly hw implementation details, which may
>  * not be true for all hw.  In particular that the FS is only executed
>  * for covered samples or for helper invocations.  So, do not blindly
>  * enable this option.
>  *
>  * Note: See also issue #22 in ARB_shader_image_load_store
>  */
> bool lower_helper_invocation;
>
> +   /**
> +* Convert gl_SampleMaskIn to gl_HelperInvocation as follows:
> +*
> +*   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
> +*   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
> +*/
> +   bool optimize_sample_mask_in;
> +
> bool lower_cs_local_index_from_id;
> bool lower_cs_local_id_from_index;
>
> bool lower_device_index_to_zero;
>
> /* Set if nir_lower_wpos_ytransform() should also invert
> gl_PointCoord. */
> bool lower_wpos_pntc;
>
> bool lower_hadd;
> bool lower_add_sat;
> diff --git a/src/compiler/nir/nir_opt_intrinsics.c
> b/src/compiler/nir/nir_opt_intrinsics.c
> index 7b054faa204..2f9e4e466c9 100644
> --- a/src/compiler/nir/nir_opt_intrinsics.c
> +++ b/src/compiler/nir/nir_opt_intrinsics.c
> @@ -22,21 +22,22 @@
>   */
>
>  #include "nir.h"
>  #include "nir_builder.h"
>
>  /**
>   * \file nir_opt_intrinsics.c
>   */
>
>  static bool
> -opt_intrinsics_impl(nir_function_impl *impl)
> +opt_intrinsics_impl(nir_function_impl *impl,
> +const struct nir_shader_compiler_options *options)
>  {
> nir_builder b;
> nir_builder_init(, impl);
> bool progress = false;
>
> nir_foreach_block(block, impl) {
>nir_foreach_instr_safe(instr, block) {
>   if (instr->type != nir_instr_type_intrinsic)
>  continue;
>
> @@ -48,20 +49,55 @@ opt_intrinsics_impl(nir_function_impl *impl)
>   case nir_intrinsic_vote_any:
>   case nir_intrinsic_vote_all:
>  if (nir_src_is_const(intrin->src[0]))
> replacement = nir_ssa_for_src(, intrin->src[0], 1);
>  break;
>   case nir_intrinsic_vote_feq:
>   case nir_intrinsic_vote_ieq:
>  if (nir_src_is_const(intrin->src[0]))
> replacement = nir_imm_true();
>  break;
> + case nir_intrinsic_load_sample_mask_in:
> +/* Transform:
> + *   gl_SampleMaskIn == 0 ---> gl_HelperInvocation
> + *   gl_SampleMaskIn != 0 ---> !gl_HelperInvocation
> + */
> +if (!options->optimize_sample_mask_in)
> +   continue;
> +
> +nir_foreach_use_safe(use_src, >dest.ssa) {
> +   if (use_src->parent_instr->type == nir_instr_type_alu) {
> +  nir_alu_instr *alu =
> nir_instr_as_alu(use_src->parent_instr);
> +
> +  if (alu->op == nir_op_ieq ||
> +  alu->op == nir_op_ine) {
> + /* Check for 0 in either operand. */
> + nir_const_value *const_val =
> + nir_src_as_const_value(alu->src[0].src);
> + if (!const_val)
> +const_val =
> nir_src_as_const_value(alu->src[1].src);
> + if (!const_val || const_val->i32[0] != 0)
> +continue;
> +
> + nir_ssa_def *new_expr =
> nir_load_helper_invocation(, 1);
> +
> + if (alu->op == nir_op_ine32)
> +new_expr = nir_inot(, new_expr);
> +
> + nir_ssa_def_rewrite_uses(>dest.dest.ssa,
> +  nir_src_for_ssa(new_expr));
> + nir_instr_remove(>instr);
> + continue;
> +  }
> +   }
> +}
> +continue;
>   default:
>  break;
>   }
>
>   if (!replacement)
>  continue;
>
>   nir_ssa_def_rewrite_uses(>dest.ssa,
>nir_src_for_ssa(replacement));
>   nir_instr_remove(instr);
> @@ -74,19 +110,19 @@ opt_intrinsics_impl(nir_function_impl *impl)
>
>  bool
>  nir_opt_intrinsics(nir_shader *shader)
>  {
> bool progress = false;
>
> nir_foreach_function(function, shader) {
>if (!function->impl)
>   continue;
>
> -  if (opt_intrinsics_impl(function->impl)) {
> +  

Re: [Mesa-dev] [PATCH] radeonsi: enable GL_EXT_shader_image_load_formatted

[Marek Olšák]

On Mon, Apr 15, 2019 at 3:30 PM Bas Nieuwenhuizen 
wrote:

> I don't see this cap defined anywhere?
>
> If it depends on an earlier series that is not pushed yet, but your
> are going to,
>
> Reviewed-by: Bas Nieuwenhuizen 
>

Thanks. Yes it depends on an earlier series by Rhys Perry from January.

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

[Mesa-dev] [PATCH] gallivm: fix bogus assert in get_indirect_index

[sroland]

From: Roland Scheidegger 

0 is a valid value as max index, and the code handles it fine. This isn't
commonly seen, as it will only happen with array declarations of size 1.
The assert was introduced with a3c898dc97ec5f0e0b93b2ee180bdf8ca3bab14c.

Fixes piglit tests/shaders/complex-loop-analysis-bug.shader_test
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110441
---
 src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 0f5b3d9acb7..d6af1d84471 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -1108,7 +1108,7 @@ get_indirect_index(struct lp_build_tgsi_soa_context *bld,
 * larger than the declared size but smaller than the buffer size.
 */
if (reg_file != TGSI_FILE_CONSTANT) {
-  assert(index_limit > 0);
+  assert(index_limit >= 0);
   max_index = lp_build_const_int_vec(bld->bld_base.base.gallivm,
  uint_bld->type, index_limit);
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] radeonsi: enable GL_EXT_shader_image_load_formatted

[Bas Nieuwenhuizen]

I don't see this cap defined anywhere?

If it depends on an earlier series that is not pushed yet, but your
are going to,

Reviewed-by: Bas Nieuwenhuizen 

On Mon, Apr 15, 2019 at 7:19 PM Marek Olšák  wrote:
>
> From: Marek Olšák 
>
> no changes - the driver doesn't use the format
> ---
>  docs/relnotes/19.1.0.html | 1 +
>  src/gallium/drivers/radeonsi/si_get.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/docs/relnotes/19.1.0.html b/docs/relnotes/19.1.0.html
> index 1c5f8d034b7..36d6dbe27c3 100644
> --- a/docs/relnotes/19.1.0.html
> +++ b/docs/relnotes/19.1.0.html
> @@ -33,20 +33,21 @@ Compatibility contexts may report a lower version 
> depending on each driver.
>  SHA256 checksums
>  
>  TBD.
>  
>
>
>  New features
>
>  
>  GL_ARB_parallel_shader_compile on all drivers.
> +GL_EXT_shader_image_load_formatted on radeonsi.
>  GL_EXT_texture_compression_s3tc_srgb on Gallium drivers and i965 (ES 
> extension).
>  GL_NV_compute_shader_derivatives on iris and i965.
>  GL_KHR_parallel_shader_compile on all drivers.
>  VK_EXT_buffer_device_address on Intel and RADV.
>  VK_NV_compute_shader_derivatives on Intel.
>  
>
>  Bug fixes
>
>  
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index 2142d5a33f2..67fbc50998b 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -154,20 +154,21 @@ static int si_get_param(struct pipe_screen *pscreen, 
> enum pipe_cap param)
> case PIPE_CAP_INT64_DIVMOD:
> case PIPE_CAP_TGSI_CLOCK:
> case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
> case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
> case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
> case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
> case PIPE_CAP_TGSI_BALLOT:
> case PIPE_CAP_TGSI_VOTE:
> case PIPE_CAP_TGSI_FS_FBFETCH:
> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
> +   case PIPE_CAP_IMAGE_LOAD_FORMATTED:
> return 1;
>
> case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
> return !SI_BIG_ENDIAN && sscreen->info.has_userptr;
>
> case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
> return sscreen->info.has_gpu_reset_status_query ||
>sscreen->info.has_gpu_reset_counter_query;
>
> case PIPE_CAP_TEXTURE_MULTISAMPLE:
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110441] [llvmpipe] complex-loop-analysis-bug regression

[bugzilla-daemon]

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

--- Comment #1 from Roland Scheidegger  ---
At a glance, it seems the code is correct, just the assertion is wrong. 0 is a
valid value as file_max (as it's the highest allowed value).
I guess this is rarely seen in practice because this happens with array
declarations which have size 1, which is somewhat unusual (and will lead to
inefficient code here I suppose), nevertheless the code can handle this just
fine. I'll whip up a fix...

-- 
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] radv: set ACCESS_NON_READABLE on stores for copy/fill/clear meta shaders

[Bas Nieuwenhuizen]

r-b

On Mon, Apr 15, 2019 at 6:38 PM Samuel Pitoiset
 wrote:
>
> The compiler will emit GLC=1.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_buffer.c | 2 ++
>  src/amd/vulkan/radv_meta_clear.c  | 1 +
>  2 files changed, 3 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_meta_buffer.c 
> b/src/amd/vulkan/radv_meta_buffer.c
> index b3aed109a5e..3e4f63ad3c1 100644
> --- a/src/amd/vulkan/radv_meta_buffer.c
> +++ b/src/amd/vulkan/radv_meta_buffer.c
> @@ -51,6 +51,7 @@ build_buffer_fill_shader(struct radv_device *dev)
> store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
> store->src[2] = nir_src_for_ssa(offset);
> nir_intrinsic_set_write_mask(store, 0xf);
> +   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
> store->num_components = 4;
> nir_builder_instr_insert(, >instr);
>
> @@ -110,6 +111,7 @@ build_buffer_copy_shader(struct radv_device *dev)
> store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
> store->src[2] = nir_src_for_ssa(offset);
> nir_intrinsic_set_write_mask(store, 0xf);
> +   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
> store->num_components = 4;
> nir_builder_instr_insert(, >instr);
>
> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> b/src/amd/vulkan/radv_meta_clear.c
> index 4407bd75ee9..101ef4344f4 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1114,6 +1114,7 @@ build_clear_htile_mask_shader()
> store->src[1] = nir_src_for_ssa(>dest.ssa);
> store->src[2] = nir_src_for_ssa(offset);
> nir_intrinsic_set_write_mask(store, 0xf);
> +   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
> store->num_components = 4;
> nir_builder_instr_insert(, >instr);
>
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110441] [llvmpipe] complex-loop-analysis-bug regression

[bugzilla-daemon]

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

Bug ID: 110441
   Summary: [llvmpipe] complex-loop-analysis-bug regression
   Product: Mesa
   Version: 19.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: bisected, have-backtrace, regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/llvmpipe
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: srol...@vmware.com
Blocks: 109535

$ ./bin/shader_runner tests/shaders/complex-loop-analysis-bug.shader_test -auto
shader_runner: src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c::
get_indirect_index: Assertion `index_limit > 0' failed.
Aborted (core dumped)


(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f0b7ae03535 in __GI_abort () at abort.c:79
#2  0x7f0b7ae0340f in __assert_fail_base (fmt=0x7f0b7af8f858 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=0x7f0b7a62be0e "index_limit > 0",
file=0x7f0b7a62b988 "src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c",
line=, function=) at assert.c:92
#3  0x7f0b7ae13142 in __GI___assert_fail (assertion=0x7f0b7a62be0e
"index_limit > 0", file=0x7f0b7a62b988
"src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c", line=,
function=0x7f0b7a62c630 <__PRETTY_FUNCTION__.15983> "get_indirect_index") at
assert.c:101
#4  0x7f0b7a444064 in get_indirect_index (bld=0x7ffdf2830120, reg_file=2,
reg_index=0, indirect_reg=0x55d4010317b4, index_limit=0) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:
#5  0x7f0b7a445212 in emit_fetch_input (bld_base=0x7ffdf2830120,
reg=0x55d4010317b0, stype=TGSI_TYPE_FLOAT, swizzle_in=0) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1442
#6  0x7f0b7a4b5d1c in lp_build_emit_fetch_src (bld_base=0x7ffdf2830120,
reg=0x55d4010317b0, stype=TGSI_TYPE_FLOAT, chan_index=0) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:370
#7  0x7f0b7a4b5f59 in lp_build_emit_fetch (bld_base=0x7ffdf2830120,
inst=0x55d401031780, src_op=0, chan_index=0) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:450
#8  0x7f0b7a4b5421 in lp_build_fetch_args (bld_base=0x7ffdf2830120,
emit_data=0x7ffdf282fea0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:180
#9  0x7f0b7a4b58b4 in lp_build_tgsi_inst_llvm (bld_base=0x7ffdf2830120,
inst=0x55d401031780) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:293
#10 0x7f0b7a4b63be in lp_build_tgsi_llvm (bld_base=0x7ffdf2830120,
tokens=0x55d401026e40) at src/gallium/auxiliary/gallivm/lp_bld_tgsi.c:555
#11 0x7f0b7a44b1b4 in lp_build_tgsi_soa (gallivm=0x55d400fe2860,
tokens=0x55d401026e40, type=..., mask=0x7ffdf28363a0,
consts_ptr=0x55d4010217e8, const_sizes_ptr=0x55d400fdc618,
system_values=0x7ffdf28363c0, inputs=0x7ffdf2839680, outputs=0x7ffdf28364a0, 
context_ptr=0x55d401023ce0, thread_data_ptr=0x55d401023e70,
sampler=0x55d40101dcb0, info=0x55d400fd9d28, gs_iface=0x0) at
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:4001
#12 0x7f0b79caa1cc in generate_fs_loop (gallivm=0x55d400fe2860,
shader=0x55d400fd9c00, key=0x55d400fe15d0, builder=0x55d401024ee0, type=...,
context_ptr=0x55d401023ce0, num_loop=0x55d401025800, interp=0x7ffdf2837750,
sampler=0x55d40101dcb0, mask_store=0x55d400fe4508, 
out_color=0x7ffdf2837110, depth_ptr=0x55d401023e20,
depth_stride=0x55d401023ec0, facing=0x55d401023d58,
thread_data_ptr=0x55d401023e70) at
src/gallium/drivers/llvmpipe/lp_state_fs.c:478
#13 0x7f0b79cb14d0 in generate_fragment (lp=0x55d400df87a0,
shader=0x55d400fd9c00, variant=0x55d400fe15d0, partial_mask=1) at
src/gallium/drivers/llvmpipe/lp_state_fs.c:2624
#14 0x7f0b79cb2486 in generate_variant (lp=0x55d400df87a0,
shader=0x55d400fd9c00, key=0x7ffdf283a200) at
src/gallium/drivers/llvmpipe/lp_state_fs.c:2872
#15 0x7f0b79cb3c60 in llvmpipe_update_fs (lp=0x55d400df87a0) at
src/gallium/drivers/llvmpipe/lp_state_fs.c:3451
#16 0x7f0b79ca8666 in llvmpipe_update_derived (llvmpipe=0x55d400df87a0) at
src/gallium/drivers/llvmpipe/lp_state_derived.c:210
#17 0x7f0b79c82e36 in llvmpipe_draw_vbo (pipe=0x55d400df87a0,
info=0x7ffdf283a9a0) at src/gallium/drivers/llvmpipe/lp_draw_arrays.c:70
#18 0x7f0b7a33cd4c in cso_draw_vbo (cso=0x55d400fe74d0,
info=0x7ffdf283a9a0) at src/gallium/auxiliary/cso_cache/cso_context.c:1708
#19 0x7f0b79f1f2a1 in st_draw_vbo (ctx=0x55d400e4bfd0,
prims=0x7ffdf283aa60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=3, tfb_vertcount=0x0, stream=0, indirect=0x0) at
src/mesa/state_tracker/st_draw.c:271
#20 0x7f0b79f8ac8f in _mesa_draw_arrays (ctx=0x55d400e4bfd0, mode=5,
start=0, count=4, numInstances=1, baseInstance=0, drawID=0) at
src/mesa/main/draw.c:374
#21 0x7f0b79f8b750 in _mesa_DrawArrays (mode=5, start=0, count=4) at
src/mesa/main/draw.c:531
#22 0x7f0b7b0b8404 in 

[Mesa-dev] [Bug 109535] [Tracker] Mesa 19.0 release tracker

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

 Depends on||110441


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=110441
[Bug 110441] [llvmpipe] complex-loop-analysis-bug regression
-- 
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 110440] [REGRESSION] [BISECTED] [OpenGL CTS] dEQP-GLES2.functional.uniform_api.random.3

[bugzilla-daemon]

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

--- Comment #1 from Mark Janes  ---
FWIW, this test is not in the dEQP mustpass list.

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

[Mesa-dev] [PATCH] winsys/amdgpu: don't set GTT with GDS & OA placements on APUs

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index c1863057370..09cf9247755 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -471,37 +471,39 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
amdgpu_winsys *ws,
   return NULL;
}
 
if (heap >= 0) {
   pb_cache_init_entry(>bo_cache, >u.real.cache_entry, >base,
   heap);
}
request.alloc_size = size;
request.phys_alignment = alignment;
 
-   if (initial_domain & RADEON_DOMAIN_VRAM)
+   if (initial_domain & RADEON_DOMAIN_VRAM) {
   request.preferred_heap |= AMDGPU_GEM_DOMAIN_VRAM;
+
+  /* Since VRAM and GTT have almost the same performance on APUs, we could
+   * just set GTT. However, in order to decrease GTT(RAM) usage, which is
+   * shared with the OS, allow VRAM placements too. The idea is not to use
+   * VRAM usefully, but to use it so that it's not unused and wasted.
+   */
+  if (!ws->info.has_dedicated_vram)
+ request.preferred_heap |= AMDGPU_GEM_DOMAIN_GTT;
+   }
+
if (initial_domain & RADEON_DOMAIN_GTT)
   request.preferred_heap |= AMDGPU_GEM_DOMAIN_GTT;
if (initial_domain & RADEON_DOMAIN_GDS)
   request.preferred_heap |= AMDGPU_GEM_DOMAIN_GDS;
if (initial_domain & RADEON_DOMAIN_OA)
   request.preferred_heap |= AMDGPU_GEM_DOMAIN_OA;
 
-   /* Since VRAM and GTT have almost the same performance on APUs, we could
-* just set GTT. However, in order to decrease GTT(RAM) usage, which is
-* shared with the OS, allow VRAM placements too. The idea is not to use
-* VRAM usefully, but to use it so that it's not unused and wasted.
-*/
-   if (!ws->info.has_dedicated_vram)
-  request.preferred_heap |= AMDGPU_GEM_DOMAIN_GTT;
-
if (flags & RADEON_FLAG_NO_CPU_ACCESS)
   request.flags |= AMDGPU_GEM_CREATE_NO_CPU_ACCESS;
if (flags & RADEON_FLAG_GTT_WC)
   request.flags |= AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (flags & RADEON_FLAG_NO_INTERPROCESS_SHARING &&
ws->info.has_local_buffers)
   request.flags |= AMDGPU_GEM_CREATE_VM_ALWAYS_VALID;
if (ws->zero_all_vram_allocs &&
(request.preferred_heap & AMDGPU_GEM_DOMAIN_VRAM))
   request.flags |= AMDGPU_GEM_CREATE_VRAM_CLEARED;
-- 
2.17.1

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

[Mesa-dev] [PATCH] radeonsi: enable GL_EXT_shader_image_load_formatted

[Marek Olšák]

From: Marek Olšák 

no changes - the driver doesn't use the format
---
 docs/relnotes/19.1.0.html | 1 +
 src/gallium/drivers/radeonsi/si_get.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/docs/relnotes/19.1.0.html b/docs/relnotes/19.1.0.html
index 1c5f8d034b7..36d6dbe27c3 100644
--- a/docs/relnotes/19.1.0.html
+++ b/docs/relnotes/19.1.0.html
@@ -33,20 +33,21 @@ Compatibility contexts may report a lower version depending 
on each driver.
 SHA256 checksums
 
 TBD.
 
 
 
 New features
 
 
 GL_ARB_parallel_shader_compile on all drivers.
+GL_EXT_shader_image_load_formatted on radeonsi.
 GL_EXT_texture_compression_s3tc_srgb on Gallium drivers and i965 (ES 
extension).
 GL_NV_compute_shader_derivatives on iris and i965.
 GL_KHR_parallel_shader_compile on all drivers.
 VK_EXT_buffer_device_address on Intel and RADV.
 VK_NV_compute_shader_derivatives on Intel.
 
 
 Bug fixes
 
 
diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 2142d5a33f2..67fbc50998b 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -154,20 +154,21 @@ static int si_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_INT64_DIVMOD:
case PIPE_CAP_TGSI_CLOCK:
case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
case PIPE_CAP_TGSI_BALLOT:
case PIPE_CAP_TGSI_VOTE:
case PIPE_CAP_TGSI_FS_FBFETCH:
case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
+   case PIPE_CAP_IMAGE_LOAD_FORMATTED:
return 1;
 
case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
return !SI_BIG_ENDIAN && sscreen->info.has_userptr;
 
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
return sscreen->info.has_gpu_reset_status_query ||
   sscreen->info.has_gpu_reset_counter_query;
 
case PIPE_CAP_TEXTURE_MULTISAMPLE:
-- 
2.17.1

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

[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
I was able to reproduce this, below is a better backtrace of the hanging
thread. Looks like it's waiting for a Present idle event. Not sure yet if this
Mesa's fault (maybe it missed the event while the context wasn't current), or
maybe the X server failed to send an event when it should (e.g. because the
window was unmapped). Most likely not an XCB issue though.

Thread 16 (Thread 0x7f697df1f700 (LWP 9784)):
#0  0x7f69ec60eb69 in __GI___poll (fds=0x7f697df1e508, nfds=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f69e8c64cf7 in  () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f69e8c66a0a in xcb_wait_for_special_event () at
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f69e1088bf5 in dri3_wait_for_event_locked (draw=0x7f697432bf98) at
../src/loader/loader_dri3_helper.c:545
#4  0x7f69e1088bf5 in dri3_wait_for_event_locked (draw=0x7f697432bf98) at
../src/loader/loader_dri3_helper.c:529
#5  0x7f69e1088ef7 in dri3_find_back (draw=draw@entry=0x7f697432bf98) at
../src/loader/loader_dri3_helper.c:670
#6  0x7f69e1089666 in dri3_get_buffer (format=format@entry=4098,
buffer_type=buffer_type@entry=loader_dri3_buffer_back,
draw=draw@entry=0x7f697432bf98, driDrawable=) at
../src/loader/loader_dri3_helper.c:1800
#7  0x7f69e108a590 in loader_dri3_get_buffers (driDrawable=,
format=4098, stamp=0x7f697431f5a0, loaderPrivate=0x7f697432bf98,
buffer_mask=, buffers=0x7f697df1e830) at
../src/loader/loader_dri3_helper.c:2019
#8  0x7f69c4e03de0 in dri_image_drawable_get_buffers
(statts_count=, statts=, images=,
drawable=) at ../src/gallium/state_trackers/dri/dri2.c:339
#9  0x7f69c4e03de0 in dri2_allocate_textures (ctx=0x7f697431f950,
drawable=0x7f697431f5a0, statts=0x7f69740504a0, statts_count=1) at
../src/gallium/state_trackers/dri/dri2.c:466
#10 0x7f69c4e05f72 in dri_st_framebuffer_validate (stctx=,
stfbi=, statts=0x7f69740504a0, count=1, out=0x7f697df1e9a0) at
../src/gallium/state_trackers/dri/dri_drawable.c:85
#11 0x7f69c5196117 in st_framebuffer_validate (stfb=0x7f697404ffd0,
st=st@entry=0x7f697404a920) at ../src/mesa/state_tracker/st_manager.c:222
#12 0x7f69c5196456 in st_api_make_current (stapi=,
stctxi=0x7f697404a920, stdrawi=0x7f697431f5a0, streadi=0x7f697431f5a0) at
../src/mesa/state_tracker/st_manager.c:1082
#13 0x7f69c4e059cd in dri_make_current (cPriv=,
driDrawPriv=, driReadPriv=) at
../src/gallium/state_trackers/dri/dri_context.c:301
#14 0x7f69c4dffe54 in driBindContext (pcp=, pdp=, prp=) at ../src/mesa/drivers/dri/common/dri_util.c:579
#15 0x7f69e107e546 in dri3_bind_context (context=0x7f697431f7b0,
old=, draw=88080385, read=88080385) at ../src/glx/dri3_glx.c:210
#16 0x7f69e106a684 in MakeContextCurrent (dpy=0x7f6974150740,
draw=88080385, read=88080385, gc_user=0x7f697431f7b0) at
../src/glx/glxcurrent.c:220
#17 0x7f697daa936b in  () at
/usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libglx_plugin.so
#18 0x7f697de14632 in  () at
/usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libgl_plugin.so
#19 0x7f69ec44111e in vlc_module_unload () at
/usr/lib/x86_64-linux-gnu/libvlccore.so.9
#20 0x7f69ec490e6d in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#21 0x7f69ec4a115c in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#22 0x7f69ec494506 in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#23 0x7f69ec495dea in  () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9
#24 0x7f69ec6f7fa3 in start_thread (arg=) at
pthread_create.c:486
#25 0x7f69ec61982f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

-- 
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 98846] triangle clipping causes wrong vertex's attribute to be broadcasted for flat interpolation

[bugzilla-daemon]

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

--- Comment #3 from Roland Scheidegger  ---
(In reply to Zebediah Figura from comment #2)
> This also affects softpipe and llvmpipe. I'm not familiar with mesa, but I
> think there are multiple places that do the wrong thing. For example,
> do_clip_tri() in src/gallium/auxiliary/draw/draw_pipe_clip.c gets passed the
> vertices in winding order, but it doesn't take that into account when
> determining provoking vertex.
> 
> If this should be split off to a separate bug, then I'll do so.
> 
> This causes failures in Wine's conformance test suite, since we use
> GL_FIRST_VERTEX_CONVENTION universally, and test flat shading with
> GL_TRIANGLESTRIP and some vertices slightly clipped outside of the viewport.
> Since our test suite is run in a virtual machine, it uses llvmpipe, and so
> is affected by this bug.

I suspect it's a different issue. For llvmpipe the piglit test you pointed out
works just fine.
(I have some suspicion for llvmpipe/softpipe it would make a difference if you
use interpolation qualifier flat vs. shade model flat. See the FIXME in
draw_pt_decompose.h - the order of decomposing should only be determined by
flatshade_first, and not depend on if flatshade is actually active. But we need
this to compensate for some bug elsewhere, apparently...)

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

[Mesa-dev] [PATCH v2 1/3] ac: add support for more types with struct/raw LLVM intrinsics

[Samuel Pitoiset]

LLVM 9+ now supports 8-bit and 16-bit types.

v2: - rebase on master (without the vec3 change)

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 46 +++---
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8f40ddda0b5..92dd4104592 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1135,6 +1135,7 @@ ac_build_llvm8_buffer_store_common(struct ac_llvm_context 
*ctx,
   LLVMValueRef voffset,
   LLVMValueRef soffset,
   unsigned num_channels,
+  LLVMTypeRef base_type,
   bool glc,
   bool slc,
   bool writeonly_memory,
@@ -1150,18 +1151,19 @@ ac_build_llvm8_buffer_store_common(struct 
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = CLAMP(num_channels, 1, 3) - 1;
-
-   const char *type_names[] = {"f32", "v2f32", "v4f32"};
+   unsigned func = num_channels == 3 ? 4 : num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
-   char name[256];
+   char name[256], type_name[8];
+
+   LLVMTypeRef type = func > 1 ? LLVMVectorType(base_type, func) : 
base_type;
+   ac_build_type_name_for_intr(type, type_name, sizeof(type_name));
 
if (use_format) {
snprintf(name, sizeof(name), 
"llvm.amdgcn.%s.buffer.store.format.%s",
-indexing_kind, type_names[func]);
+indexing_kind, type_name);
} else {
snprintf(name, sizeof(name), "llvm.amdgcn.%s.buffer.store.%s",
-indexing_kind, type_names[func]);
+indexing_kind, type_name);
}
 
ac_build_intrinsic(ctx, name, ctx->voidt, args, idx,
@@ -1181,8 +1183,8 @@ ac_build_buffer_store_format(struct ac_llvm_context *ctx,
if (HAVE_LLVM >= 0x800) {
ac_build_llvm8_buffer_store_common(ctx, rsrc, data, vindex,
   voffset, NULL, num_channels,
-  glc, false, writeonly_memory,
-  true, true);
+  ctx->f32, glc, false,
+  writeonly_memory, true, 
true);
} else {
ac_build_buffer_store_common(ctx, rsrc, data, vindex, voffset,
 num_channels, glc, false,
@@ -1245,6 +1247,7 @@ ac_build_buffer_store_dword(struct ac_llvm_context *ctx,
   ctx->i32_0,
   voffset, offset,
   num_channels,
+  ctx->f32,
   glc, slc,
   writeonly_memory,
   false, false);
@@ -1320,6 +1323,7 @@ ac_build_llvm8_buffer_load_common(struct ac_llvm_context 
*ctx,
  LLVMValueRef voffset,
  LLVMValueRef soffset,
  unsigned num_channels,
+ LLVMTypeRef base_type,
  bool glc,
  bool slc,
  bool can_speculate,
@@ -1334,23 +1338,22 @@ ac_build_llvm8_buffer_load_common(struct 
ac_llvm_context *ctx,
args[idx++] = voffset ? voffset : ctx->i32_0;
args[idx++] = soffset ? soffset : ctx->i32_0;
args[idx++] = LLVMConstInt(ctx->i32, (glc ? 1 : 0) + (slc ? 2 : 0), 0);
-   unsigned func = CLAMP(num_channels, 1, 3) - 1;
-
-   LLVMTypeRef types[] = {ctx->f32, ctx->v2f32, ctx->v4f32};
-   const char *type_names[] = {"f32", "v2f32", "v4f32"};
+   unsigned func = num_channels == 3 ? 4 : num_channels;
const char *indexing_kind = structurized ? "struct" : "raw";
-   char name[256];
+   char name[256], type_name[8];
+
+   LLVMTypeRef type = func > 1 ? LLVMVectorType(base_type, func) : 
base_type;
+   ac_build_type_name_for_intr(type, type_name, sizeof(type_name));
 
if (use_format) {
snprintf(name, sizeof(name), 
"llvm.amdgcn.%s.buffer.load.format.%s",
-indexing_kind, type_names[func]);
+indexing_kind, type_name);
} else {

Re: [Mesa-dev] Low interpolation precision for 8 bit textures using llvmpipe

[Roland Scheidegger]

Am 15.04.19 um 13:55 schrieb Dominik Drees:
> On 4/12/19 5:32 PM, Roland Scheidegger wrote:
>> Am 12.04.19 um 14:34 schrieb Dominik Drees:
>>> Hi Roland!
>>>
>>> On 4/11/19 8:18 PM, Roland Scheidegger wrote:
 What version of mesa are you using?
>>> The original results were generated using version 19.0.2 (from the arch
>>> linux repositories), but I got the same results using the current git
>>> version (98934e6aa19795072a353dae6020dafadc76a1e3).
>> Alright, both of these would use the GALLIVM_PERF var.
>>
 The debug flags were changed a while ago (so that those perf tweaks can
 be disabled on release builds too), it needs to be either:
 GALLIVM_PERF=no_rho_approx,no_brilinear,no_quad_lod
 or easier
 GALLIVM_PERF=no_filter_hacks (which disables these 3 things above
 together)

 Although all of that only really affects filtering with mipmaps (not
 sure if you do?).
>>> Using GALLIVM_PERF does not a make a difference, either, but that should
>>> be expected because I'm not using mipmaps, just "regular" linear
>>> filtering (GL_NEAREST).


 (more below)
>>> See my responses below as well.


 Am 11.04.19 um 18:00 schrieb Dominik Drees:
> Running with the suggested flags in the environment does not change the
> result for the test case I described below. The results with and without
> the environment variables set are pixel-wise equal.
>
> By the way, and if this of interest: For GL_NEAREST sampling the results
> from hardware and llvmpipe are equal as well.
>
> Best,
> Dominik
>
> On 4/11/19 4:36 PM, Ilia Mirkin wrote:
>> llvmpipe takes a number of shortcuts in the interest of speed which
>> cause inaccurate texturing. Try running with
>>
>> GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
>>
>> and see if the issue still occurs.
>>
>> Cheers,
>>
>>      -ilia
>>
>>
>>
>> On Thu, Apr 11, 2019 at 8:30 AM Dominik Drees 
>> wrote:
>>>
>>> Hello, everyone!
>>>
>>> I have a question regarding the interpolation precision of llvmpipe.
>>> Feel free to redirect me to somewhere else if this is not the right
>>> place to ask. Consider the following scenario: In a fragment shader we
>>> are sampling from a 16x16, 8 bit texture with values between 0 and 3
>>> using linear interpolation. Then we write white to the screen if the
>>> sampled value is > 1/255 and black otherwise. The output looks very
>>> different when rendered with llvmpipe compared to the result
>>> produced by
>>> rendering hardware (for both intel (mesa i965) and nvidia (proprietary
>>> driver)).
>>>
>>> I've uploaded examplary output images here
>>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2FD1udpezdata=02%7C01%7Csroland%40vmware.com%7Cbdef52eb504c4078f9f808d6be96da17%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636905952501149697sdata=vymggYHZTDLwKNh7RpcM1eSyhVA2L%2BfHNchvYS8yQPQ%3Dreserved=0)
>>>
>>>
>>> and the corresponding fragment shader here
>>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fpa808Reqdata=02%7C01%7Csroland%40vmware.com%7Cbdef52eb504c4078f9f808d6be96da17%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636905952501149697sdata=%2FqKVJCXFS4UswynKeSoqCKivTHAb2o%2FZwVE1nwNms3M%3Dreserved=0).
>>>
 The shader looks iffy to me, how do you use that vec4 in the if clause?


>>>
>>> My hypothesis is that llvmpipe (in contrast to hardware) only uses
>>> 8 bit
>>> for the interpolation computation when reading from 8 bit textures and
>>> thus loses precision in the lower bits. Is that correct? If so, does
>>> anyone know of a workaround?

 So, in theory it is indeed possible the results are less accurate with
 llvmpipe (I believe all recent hw does rgba8 filtering with more than 8
 bit precision).
 For formats fitting into rgba8, we have a fast path in llvmpipe
 (gallivm) for the lerp, which unpacks the 8bit values into 16bit values,
 does the lerp with that and packs back to 8 bit. The result is
 accurately rounded there (to 8 bit) but only for 1 lerp step - for a 2d
 texture there are 3 of those (one per direction, and a final one
 combining the result). And yes this means the filtered result only has 8
 bits.
>>> Do I understand you correctly in that for the 2D case, the results of
>>> the first two lerps (done in 16 bit) are converted to 8 bit, then
>>> converted back to 16 bit for the final (second stage) lerp?
>> Yes. Even the final lerp is converted back to 8 bit before being finally
>> converted to float. (In theory we could avoid this for the final lerp,
>> but this would need some refactoring, since the last lerp isn't always
>> the same - if you have mipmaps for instance there's yet another lerp in
>> the end between the results of 

[Mesa-dev] [PATCH] radv: set ACCESS_NON_READABLE on stores for copy/fill/clear meta shaders

[Samuel Pitoiset]

The compiler will emit GLC=1.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_buffer.c | 2 ++
 src/amd/vulkan/radv_meta_clear.c  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/src/amd/vulkan/radv_meta_buffer.c 
b/src/amd/vulkan/radv_meta_buffer.c
index b3aed109a5e..3e4f63ad3c1 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -51,6 +51,7 @@ build_buffer_fill_shader(struct radv_device *dev)
store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
store->src[2] = nir_src_for_ssa(offset);
nir_intrinsic_set_write_mask(store, 0xf);
+   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
store->num_components = 4;
nir_builder_instr_insert(, >instr);
 
@@ -110,6 +111,7 @@ build_buffer_copy_shader(struct radv_device *dev)
store->src[1] = nir_src_for_ssa(_buf->dest.ssa);
store->src[2] = nir_src_for_ssa(offset);
nir_intrinsic_set_write_mask(store, 0xf);
+   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
store->num_components = 4;
nir_builder_instr_insert(, >instr);
 
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 4407bd75ee9..101ef4344f4 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1114,6 +1114,7 @@ build_clear_htile_mask_shader()
store->src[1] = nir_src_for_ssa(>dest.ssa);
store->src[2] = nir_src_for_ssa(offset);
nir_intrinsic_set_write_mask(store, 0xf);
+   nir_intrinsic_set_access(store, ACCESS_NON_READABLE);
store->num_components = 4;
nir_builder_instr_insert(, >instr);
 
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv: enable shaderInt8 on SI and CIK

[Samuel Pitoiset]

No CTS failures.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c  | 5 ++---
 src/amd/vulkan/radv_extensions.py | 2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index c517b56cd0f..998d6f02eb2 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -901,9 +901,8 @@ void radv_GetPhysicalDeviceFeatures2(
case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT16_INT8_FEATURES_KHR: {
VkPhysicalDeviceFloat16Int8FeaturesKHR *features =
(VkPhysicalDeviceFloat16Int8FeaturesKHR*)ext;
-   bool enabled = pdevice->rad_info.chip_class >= VI;
-   features->shaderFloat16 = enabled && HAVE_LLVM >= 
0x0800;
-   features->shaderInt8 = enabled;
+   features->shaderFloat16 = pdevice->rad_info.chip_class 
>= VI && HAVE_LLVM >= 0x0800;
+   features->shaderInt8 = true;
break;
}
default:
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 3d0a0c4343e..13fe391e623 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -82,7 +82,7 @@ EXTENSIONS = [
 Extension('VK_KHR_relaxed_block_layout',  1, True),
 Extension('VK_KHR_sampler_mirror_clamp_to_edge',  1, True),
 Extension('VK_KHR_shader_draw_parameters',1, True),
-Extension('VK_KHR_shader_float16_int8',   1, 
'device->rad_info.chip_class >= VI'),
+Extension('VK_KHR_shader_float16_int8',   1, True),
 Extension('VK_KHR_storage_buffer_storage_class',  1, True),
 Extension('VK_KHR_surface',  25, 
'RADV_HAS_SURFACE'),
 Extension('VK_KHR_surface_protected_capabilities',1, 
'RADV_HAS_SURFACE'),
-- 
2.21.0

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

Re: [Mesa-dev] Mesa 19.1.0 release plan

[Eero Tamminen]

Hi,

On 15.4.2019 17.15, Juan A. Suarez Romero wrote:

Here is the tentative release plan for 19.1.0.

As many of you are well aware, it's time to the next branch point.
The calendar is already updated, so these are the tentative dates:

  Apr 30 2019 - Feature freeze/Release candidate 1
  May 07 2019 - Release candidate 2
  May 14 2019 - Release candidate 3
  May 21 2019 - Release candidate 4/final release

This gives us around 2 weeks until the branch point.

Note: In the spirit of keeping things clearer and more transparent, we
will be keeping track of any features planned for the release in
Bugzilla [1].

Do add a separate "Depends on" for each work you have planned.
Alternatively you can reply to this email and I'll add them for you.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=110439


Should the current GPU hang bugs initially be blockers for that?

For example the remaining (open) mesa-19.0 blocker bug:
https://bugs.freedesktop.org/show_bug.cgi?id=108820

(There has been no comment for the attached error states from Mesa devs
since Lionel's initial comment 4 months ago, e.g. on whether Jakub's and
my cases are same or should they be filed as separate bugs.)


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

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Michel Dänzer]

On 2019-04-15 12:57 p.m., Lucas Stach wrote:
> Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
>> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
>>> Unconditionally requesting both bindings can lead to premature
>>> failure to create a valid image.
>>>
> Signed-off-by: Lucas Stach 
>>> ---
>>>  src/gallium/state_trackers/dri/dri2.c | 13 +++--
>>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/dri/dri2.c 
>>> b/src/gallium/state_trackers/dri/dri2.c
>>> index efb43c0d7973..510b7f8d04a7 100644
>>> --- a/src/gallium/state_trackers/dri/dri2.c
>>> +++ b/src/gallium/state_trackers/dri/dri2.c
>>> @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
>>>  {
>>> const struct dri2_format_mapping *map = 
>>> dri2_get_mapping_by_format(format);
>>> struct dri_screen *screen = dri_screen(_screen);
>>> +   struct pipe_screen *pscreen = screen->base.screen;
>>> __DRIimage *img;
>>> struct pipe_resource templ;
>>> -   unsigned tex_usage;
>>> +   unsigned tex_usage = 0;
>>>  
>>> if (!map)
>>>    return NULL;
>>>  
>>> -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
>>> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
>>> screen->target,
>>> +0, 0, PIPE_BIND_RENDER_TARGET))
>>> +  tex_usage |= PIPE_BIND_RENDER_TARGET;
>>> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
>>> screen->target,
>>> +0, 0, PIPE_BIND_SAMPLER_VIEW))
>>> +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
>>> +
>>> +   if (!tex_usage)
>>> +  return NULL;
>>>  
>>> if (use & __DRI_IMAGE_USE_SCANOUT)
>>>    tex_usage |= PIPE_BIND_SCANOUT;
>>>
>>
>> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
>> expectation does seem to be that both are supported. What happens if an
>> image is created for a format which only supports sampling, then the
>> caller attempts rendering to it?
> 
> While I agree that the missing flags is a problem, I don't think the
> expectation that createImage must create something which is both render
> and sampler compatible holds anymore.

I don't mean "expectation" as in that of any particular application. I
mean that because the caller cannot yet express that it only wants to
sample from / render to the image, dri2_create_image_common must assume
that the image will be used for both.


> kmscube for example does create a R8 buffer via gbm_bo_create that is
> only used to create a texture. As this is going through the createImage
> path it will fail on drivers that only support texturing from R8, like
> etnaviv, which is definitely not what the application expects. There is
> quite a bit of API abuse involved in this example, but I'm not sure if
> the right way to deal with this is break the application.

kmscube could never work using existing API on hardware which can't
render to R8, so "break" doesn't really fit.

Conversely, is it possible for the caller to find out that the image
can't be used for rendering, so that e.g. an attempt to use it for a
GL(ES) FBO would be correctly marked as incomplete? If not, this change
may break other applications which worked before, e.g. glamor.


> Also are other ways to come up with a DRI image that is only sampler
> compatible, like the create_image_from_fd paths. While we may be able
> to fix the gbm case, as we have the flags available there, we can't do
> this as easily for the import paths, as there are no usage flags
> available at the EGL API level.

One possibility might be adding new "sample only" flags / API where needed.


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

[Mesa-dev] [Bug 110440] [REGRESSION] [BISECTED] [OpenGL CTS] dEQP-GLES2.functional.uniform_api.random.3

[bugzilla-daemon]

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

Bug ID: 110440
   Summary: [REGRESSION] [BISECTED] [OpenGL CTS]
dEQP-GLES2.functional.uniform_api.random.3
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ago...@igalia.com
QA Contact: intel-3d-b...@lists.freedesktop.org
CC: kenn...@whitecape.org

After:

--

commit 9e0c744f07a21fc7bb018a77cf83b057436d0d1b
Author: Kenneth Graunke 
Date:   Thu Apr 11 07:04:58 2019 -0700

glsl: Set location on structure-split sampler uniform variables

gl_nir_lower_samplers_as_deref splits structure uniform variables,
creating new variables for individual fields.  As part of that, it
calculates a new location.  It then never set this on the new variables.

Thanks to Michael Fiano for finding this bug.  Fixes crashes on i965
with Piglit's new tests/spec/glsl-1.10/execution/samplers/uniform-struct
test, which was reduced from the failing case in Michael's app.

Fixes: f003859f97c nir: Make gl_nir_lower_samplers use
gl_nir_lower_samplers_as_deref
Reviewed-by: Timothy Arceri 

--

dEQP-GLES2.functional.uniform_api.random.3 fails:

--

./glcts --deqp-case=dEQP-GLES2.functional.uniform_api.random.3
Writing test log into TestResults.qpa
dEQP Core git-4207a2ba566fad7d8233c96a17d0ce9eed119aa3 (0x4207a2ba) starting..
  target implementation = 'Wayland'
ATTENTION: default value of option vblank_mode overridden by environment.

Test case 'dEQP-GLES2.functional.uniform_api.random.3'..
  Fail (Failed)

DONE!

Test run totals:
 Passed:0/1 (0.0%)
  Failed:1/1 (100.0%)
  Not supported: 0/1 (0.0%)
  Warnings:  0/1 (0.0%)

--

Found with VK-GL-CTS compiled for Wayland target, but confirmed also with the
X11_EGL target. Also, failing, at least, in KBL, SKL, BDW and HSW.

-- 
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] Mesa 19.1.0 release plan

[Juan A. Suarez Romero]

Hi all,

Here is the tentative release plan for 19.1.0.

As many of you are well aware, it's time to the next branch point.
The calendar is already updated, so these are the tentative dates:

 Apr 30 2019 - Feature freeze/Release candidate 1
 May 07 2019 - Release candidate 2
 May 14 2019 - Release candidate 3
 May 21 2019 - Release candidate 4/final release

This gives us around 2 weeks until the branch point.

Note: In the spirit of keeping things clearer and more transparent, we
will be keeping track of any features planned for the release in
Bugzilla [1].

Do add a separate "Depends on" for each work you have planned.
Alternatively you can reply to this email and I'll add them for you.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=110439

Thanks

J.A.


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

[Mesa-dev] [Bug 110439] [TRACKER] Mesa 19.1 feature tracker

[bugzilla-daemon]

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

Bug ID: 110439
   Summary: [TRACKER] Mesa 19.1 feature tracker
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: jasua...@igalia.com
QA Contact: mesa-dev@lists.freedesktop.org

This is a tracker for features planned for the 19.1 release.

Note: features should be merged prior to the branchpoint.
Schedule is at https://www.mesa3d.org/release-calendar.html

-- 
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 8/8] etnaviv: handle YUV textures with the 2D GPU

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> This allows color space conversion and tiling in a single step, as
> well as handling multi-planar formats like NV12, which are really
> useful when dealing with hardware video decoders.
> 
> Signed-off-by: Lucas Stach 
> ---
>  .../drivers/etnaviv/etnaviv_clear_blit.c  |  2 +-
>  src/gallium/drivers/etnaviv/etnaviv_format.c  |  5 +++-
>  .../drivers/etnaviv/etnaviv_resource.c| 16 
>  src/gallium/drivers/etnaviv/etnaviv_rs.c  |  5 
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  |  5 +++-
>  src/gallium/drivers/etnaviv/etnaviv_texture.c | 25 ---
>  6 files changed, 46 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index 45c30cbf5076..5214162d8798 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -159,7 +159,7 @@ etna_copy_resource(struct pipe_context *pctx, struct 
> pipe_resource *dst,
> struct etna_resource *src_priv = etna_resource(src);
> struct etna_resource *dst_priv = etna_resource(dst);
>  
> -   assert(src->format == dst->format);
> +   assert(src->format == dst->format || util_format_is_yuv(src->format));
> assert(src->array_size == dst->array_size);
> assert(last_level <= dst->last_level && last_level <= src->last_level);
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
> b/src/gallium/drivers/etnaviv/etnaviv_format.c
> index 29e81c4a8b04..0879ddd6a6c8 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_format.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
> @@ -282,8 +282,11 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
> _T(ASTC_12x12_SRGB, ASTC_SRGB8_ALPHA8_12x12 | ASTC_FORMAT,  
> SWIZ(X, Y, Z, W), NONE, NONE),
>  
> /* YUV */
> -   _T(YUYV, YUY2, SWIZ(X, Y, Z, W), YUY2, NONE),
> +   _T(YUYV, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
> _T(UYVY, UYVY, SWIZ(X, Y, Z, W), NONE, NONE),
> +
> +   /* multi-planar YUV */
> +   _T(NV12, X8B8G8R8, SWIZ(X, Y, Z, W), NONE, NONE),
>  };
>  
>  uint32_t
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 650c8e7eb7f5..5ba3eba5bd33 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -560,6 +560,17 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>
> level->padded_height);
> level->size = level->layer_stride;
>  
> +   rsc->pending_ctx = _mesa_set_create(NULL, _mesa_hash_pointer,
> +   _mesa_key_pointer_equal);
> +   if (!rsc->pending_ctx)
> +  goto fail;
> +
> +   /* YUV resources are handled by the 2D GPU, so the below constraint checks
> +* are invalid.
> +*/
> +   if (util_format_is_yuv(tmpl->format))
> +  return prsc;
> +
> /* The DDX must give us a BO which conforms to our padding size.
>  * The stride of the BO must be greater or equal to our padded
>  * stride. The size of the BO must accomodate the padded height. */
> @@ -576,11 +587,6 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>goto fail;
> }
>  
> -   rsc->pending_ctx = _mesa_set_create(NULL, _mesa_hash_pointer,
> -   _mesa_key_pointer_equal);
> -   if (!rsc->pending_ctx)
> -  goto fail;
> -
> if (rsc->layout == ETNA_LAYOUT_LINEAR) {
>/*
> * Both sampler and pixel pipes can't handle linear, create a 
> compatible
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index fcc2342aedc3..22d07d8f9726 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -26,6 +26,7 @@
>  
>  #include "etnaviv_rs.h"
>  
> +#include "etnaviv_2d.h"
>  #include "etnaviv_clear_blit.h"
>  #include "etnaviv_context.h"
>  #include "etnaviv_emit.h"
> @@ -775,6 +776,10 @@ etna_blit_rs(struct pipe_context *pctx, const struct 
> pipe_blit_info *blit_info)
>return;
> }
>  
> +   if (util_format_is_yuv(blit_info->src.format) &&
> +   etna_try_2d_blit(pctx, blit_info))
> +  return;
> +
> if (etna_try_rs_blit(pctx, blit_info))
>return;
>  
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 0dea6056c75a..b0630e27b507 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -535,6 +535,9 @@ gpu_supports_texure_format(struct etna_screen *screen, 
> uint32_t fmt,
>supported = screen->specs.tex_astc;
> }
>  
> +   if (util_format_is_yuv(format))
> +  supported = !!screen->gpu2d;

Isn't screen->gpu2d == NULL for devices with combined 2D/3D 

Re: [Mesa-dev] [PATCH 4/6] st/dri: handle emulated YUV texture sampling in query_dma_buf_modifiers

[Philipp Zabel]

On Fri, 2019-04-12 at 19:33 +0200, Lucas Stach wrote:
> The Mesa state tracker will emulate YUV texture sampling for drivers that
> don't support it natively by using multiple R8/RG88 samplers. Teach
> dri2_query_dma_buf_modifiers about this special case.
> This allows clients like GStreamer glupload or Kodi to properly query
> the supported dma-buf import formats, without the need to take a special
> code path for the emulated OES_external texture handling.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index f139bd6722b9..4243a00cb38d 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -1358,19 +1358,30 @@ dri2_query_dma_buf_modifiers(__DRIscreen *_screen, 
> int fourcc, int max,
> const struct dri2_format_mapping *map = 
> dri2_get_mapping_by_fourcc(fourcc);
> enum pipe_format format;
>  
> -   if (!map)
> +   if (!map || !pscreen->query_dmabuf_modifiers)
>return false;
>  
> format = map->pipe_format;
>  
> -   if (pscreen->query_dmabuf_modifiers != NULL &&
> -   (pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
> +   if ((pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
>   PIPE_BIND_RENDER_TARGET) ||
>  pscreen->is_format_supported(pscreen, format, screen->target, 0, 0,
>   PIPE_BIND_SAMPLER_VIEW))) {
>pscreen->query_dmabuf_modifiers(pscreen, format, max, modifiers,
>external_only, count);
>return true;
> +   } else if (util_format_is_yuv(format) &&
> +  pscreen->is_format_supported(pscreen, PIPE_FORMAT_R8_UNORM,
> +   screen->target, 0, 0,
> +   PIPE_BIND_SAMPLER_VIEW)) {
> +  /* YUV format sampling can be emulated by the Mesa state tracker by
> +   * using multiple R8/RG88 samplers if the driver doesn't support those
> +   * formats natively, so we need a special case here to give a mostly
> +   * accurate answer to the modifiers query.
> +   */

"Mostly accurate" meaning that for IYUV this is correct, but for NV12 we
are assuming that the drivers will return the same modifiers for
PIPE_FORMAT_R8_UNORM as for PIPE_FORMAT_RG88_UNORM. As far as I can
tell, this is currently the case for all drivers that implement
query_dmabuf_modifiers.

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 6/6] st/mesa: skip any extra handling of YUV textures if driver supports them

[Philipp Zabel]

On Fri, 2019-04-12 at 19:33 +0200, Lucas Stach wrote:
> If the driver provides native support for YUV textures we can skip
> adding additional samplers and re-writing the shaders.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 5/6] st/dri: don't re-write plane format if supported by driver

[Philipp Zabel]

On Fri, 2019-04-12 at 19:33 +0200, Lucas Stach wrote:
> If the driver supports multi-planar formats natively we don't want to
> re-write the format of the planes on import. Split this out in a
> separate function for clarity.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] Low interpolation precision for 8 bit textures using llvmpipe

[Dominik Drees]

On 4/12/19 5:32 PM, Roland Scheidegger wrote:
> Am 12.04.19 um 14:34 schrieb Dominik Drees:
>> Hi Roland!
>>
>> On 4/11/19 8:18 PM, Roland Scheidegger wrote:
>>> What version of mesa are you using?
>> The original results were generated using version 19.0.2 (from the arch
>> linux repositories), but I got the same results using the current git
>> version (98934e6aa19795072a353dae6020dafadc76a1e3).
> Alright, both of these would use the GALLIVM_PERF var.
> 
>>> The debug flags were changed a while ago (so that those perf tweaks can
>>> be disabled on release builds too), it needs to be either:
>>> GALLIVM_PERF=no_rho_approx,no_brilinear,no_quad_lod
>>> or easier
>>> GALLIVM_PERF=no_filter_hacks (which disables these 3 things above
>>> together)
>>>
>>> Although all of that only really affects filtering with mipmaps (not
>>> sure if you do?).
>> Using GALLIVM_PERF does not a make a difference, either, but that should
>> be expected because I'm not using mipmaps, just "regular" linear
>> filtering (GL_NEAREST).
>>>
>>>
>>> (more below)
>> See my responses below as well.
>>>
>>>
>>> Am 11.04.19 um 18:00 schrieb Dominik Drees:
 Running with the suggested flags in the environment does not change the
 result for the test case I described below. The results with and without
 the environment variables set are pixel-wise equal.

 By the way, and if this of interest: For GL_NEAREST sampling the results
 from hardware and llvmpipe are equal as well.

 Best,
 Dominik

 On 4/11/19 4:36 PM, Ilia Mirkin wrote:
> llvmpipe takes a number of shortcuts in the interest of speed which
> cause inaccurate texturing. Try running with
>
> GALLIVM_DEBUG=no_rho_approx,no_brilinear,no_quad_lod
>
> and see if the issue still occurs.
>
> Cheers,
>
>      -ilia
>
>
>
> On Thu, Apr 11, 2019 at 8:30 AM Dominik Drees 
> wrote:
>>
>> Hello, everyone!
>>
>> I have a question regarding the interpolation precision of llvmpipe.
>> Feel free to redirect me to somewhere else if this is not the right
>> place to ask. Consider the following scenario: In a fragment shader we
>> are sampling from a 16x16, 8 bit texture with values between 0 and 3
>> using linear interpolation. Then we write white to the screen if the
>> sampled value is > 1/255 and black otherwise. The output looks very
>> different when rendered with llvmpipe compared to the result
>> produced by
>> rendering hardware (for both intel (mesa i965) and nvidia (proprietary
>> driver)).
>>
>> I've uploaded examplary output images here
>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2FD1udpezdata=02%7C01%7Csroland%40vmware.com%7Cbdef52eb504c4078f9f808d6be96da17%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636905952501149697sdata=vymggYHZTDLwKNh7RpcM1eSyhVA2L%2BfHNchvYS8yQPQ%3Dreserved=0)
>>
>>
>> and the corresponding fragment shader here
>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fpa808Reqdata=02%7C01%7Csroland%40vmware.com%7Cbdef52eb504c4078f9f808d6be96da17%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636905952501149697sdata=%2FqKVJCXFS4UswynKeSoqCKivTHAb2o%2FZwVE1nwNms3M%3Dreserved=0).
>>
>>> The shader looks iffy to me, how do you use that vec4 in the if clause?
>>>
>>>
>>
>> My hypothesis is that llvmpipe (in contrast to hardware) only uses
>> 8 bit
>> for the interpolation computation when reading from 8 bit textures and
>> thus loses precision in the lower bits. Is that correct? If so, does
>> anyone know of a workaround?
>>>
>>> So, in theory it is indeed possible the results are less accurate with
>>> llvmpipe (I believe all recent hw does rgba8 filtering with more than 8
>>> bit precision).
>>> For formats fitting into rgba8, we have a fast path in llvmpipe
>>> (gallivm) for the lerp, which unpacks the 8bit values into 16bit values,
>>> does the lerp with that and packs back to 8 bit. The result is
>>> accurately rounded there (to 8 bit) but only for 1 lerp step - for a 2d
>>> texture there are 3 of those (one per direction, and a final one
>>> combining the result). And yes this means the filtered result only has 8
>>> bits.
>> Do I understand you correctly in that for the 2D case, the results of
>> the first two lerps (done in 16 bit) are converted to 8 bit, then
>> converted back to 16 bit for the final (second stage) lerp?
> Yes. Even the final lerp is converted back to 8 bit before being finally
> converted to float. (In theory we could avoid this for the final lerp,
> but this would need some refactoring, since the last lerp isn't always
> the same - if you have mipmaps for instance there's yet another lerp in
> the end between the results of each mip.)
> 
> 
>>
>> If so and if I'm understanding this correctly, for 2D (i.e., a 2-stage
>> linear interpolation) we potentially have an error 

Re: [Mesa-dev] [PATCH 7/8] etnaviv: improve PIPE_BIND_LINEAR handling

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> We weren't handling this flag at all, which broke some assumptions
> made by the users of the resource_create interface. As we can't render
> to a linear surface and the usefulness of yet another layout transition
> to handle this case seems limited, we only respect the flag when the
> resource isn't used for rendering.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index f405b880a6c0..650c8e7eb7f5 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -369,6 +369,14 @@ etna_resource_create(struct pipe_screen *pscreen,
> if (templat->target == PIPE_TEXTURE_3D)
>layout = ETNA_LAYOUT_LINEAR;
>  
> +   /* The render pipe can't handle linear and there is no code to do yet 
> another
> +* layout transformation for this case, so we only respect the linear flag
> +* if the resource isn't meant to be rendered.
> +*/
> +   if ((templat->bind & PIPE_BIND_LINEAR) &&
> +   !(templat->bind & PIPE_BIND_RENDER_TARGET))
> +  layout = ETNA_LAYOUT_LINEAR;
> +
> /* modifier is only used for scanout surfaces, so safe to use LINEAR here 
> */
> return etna_resource_alloc(pscreen, layout, mode, DRM_FORMAT_MOD_LINEAR, 
> templat);
>  }

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Lucas Stach]

Hi Michel,

Am Montag, den 15.04.2019, 12:04 +0200 schrieb Michel Dänzer:
> On 2019-04-12 7:33 p.m., Lucas Stach wrote:
> > Unconditionally requesting both bindings can lead to premature
> > failure to create a valid image.
> > 
> > > > Signed-off-by: Lucas Stach 
> > ---
> >  src/gallium/state_trackers/dri/dri2.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/gallium/state_trackers/dri/dri2.c 
> > b/src/gallium/state_trackers/dri/dri2.c
> > index efb43c0d7973..510b7f8d04a7 100644
> > --- a/src/gallium/state_trackers/dri/dri2.c
> > +++ b/src/gallium/state_trackers/dri/dri2.c
> > @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
> >  {
> > const struct dri2_format_mapping *map = 
> > dri2_get_mapping_by_format(format);
> > struct dri_screen *screen = dri_screen(_screen);
> > +   struct pipe_screen *pscreen = screen->base.screen;
> > __DRIimage *img;
> > struct pipe_resource templ;
> > -   unsigned tex_usage;
> > +   unsigned tex_usage = 0;
> >  
> > if (!map)
> >    return NULL;
> >  
> > -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> > screen->target,
> > +0, 0, PIPE_BIND_RENDER_TARGET))
> > +  tex_usage |= PIPE_BIND_RENDER_TARGET;
> > +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> > screen->target,
> > +0, 0, PIPE_BIND_SAMPLER_VIEW))
> > +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> > +
> > +   if (!tex_usage)
> > +  return NULL;
> >  
> > if (use & __DRI_IMAGE_USE_SCANOUT)
> >    tex_usage |= PIPE_BIND_SCANOUT;
> > 
> 
> Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
> expectation does seem to be that both are supported. What happens if an
> image is created for a format which only supports sampling, then the
> caller attempts rendering to it?

While I agree that the missing flags is a problem, I don't think the
expectation that createImage must create something which is both render
and sampler compatible holds anymore.

kmscube for example does create a R8 buffer via gbm_bo_create that is
only used to create a texture. As this is going through the createImage
path it will fail on drivers that only support texturing from R8, like
etnaviv, which is definitely not what the application expects. There is
quite a bit of API abuse involved in this example, but I'm not sure if
the right way to deal with this is break the application.

Also are other ways to come up with a DRI image that is only sampler
compatible, like the create_image_from_fd paths. While we may be able
to fix the gbm case, as we have the flags available there, we can't do
this as easily for the import paths, as there are no usage flags
available at the EGL API level.

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

Re: [Mesa-dev] [PATCH 6/8] etnaviv: use filter blit for 2D YUV import on old GC320

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> The GC320 without the 2D tiling feature doesn't support regular blits
> with YUV input, as well as the tiled output. So on those cores we need
> need to do a filter blit for the YUV->RGB conversion to a temporary
> linear buffer and then do a tiling blit into the texture buffer using
> the RS engine on the 3D core.
> 
> Not the most efficient path, but at least gives us the same level of
> functionality as on the newer GC320 cores and looks the same to the
> application.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_2d.c | 198 ---
>  1 file changed, 180 insertions(+), 18 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
> b/src/gallium/drivers/etnaviv/etnaviv_2d.c
> index 457fa4e0cbd0..31b6bf4313dd 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_2d.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
> @@ -25,13 +25,16 @@
>  #include "etnaviv_context.h"
>  #include "etnaviv_emit.h"
>  #include "etnaviv_screen.h"
> +#include "etnaviv_rs.h"
>  
>  #include "pipe/p_state.h"
>  #include "util/u_format.h"
>  
>  #include "hw/state_2d.xml.h"
> +#include "hw/common.xml.h"
>  
>  #include 
> +#include 
>  
>  #define EMIT_STATE(state_name, src_value) \
> etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
> @@ -39,15 +42,85 @@
>  #define EMIT_STATE_RELOC(state_name, src_value) \
> etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
>  
> +/* stolen from xf86-video-armada */
> +#define KERNEL_ROWS 17
> +#define KERNEL_INDICES  9
> +#define KERNEL_SIZE (KERNEL_ROWS * KERNEL_INDICES)
> +#define KERNEL_STATE_SZ ((KERNEL_SIZE + 1) / 2)
> +
> +static bool filter_kernel_initialized;
> +static uint32_t filter_kernel[KERNEL_STATE_SZ];
> +
> +static inline float
> +sinc (float x)
   ^
> +{
> +  return x != 0.0 ? sinf (x) / x : 1.0;
   ^
> +}
> +
> +static void
> +etnaviv_init_filter_kernel(void)
> +{
> +   unsigned row, idx, i;
> +   int16_t kernel_val[KERNEL_STATE_SZ * 2];
> +   float row_ofs = 0.5;
> +   float radius = 4.0;
> +
> +   /* Compute lanczos filter kernel */
> +   for (row = i = 0; row < KERNEL_ROWS; row++) {
> +  float kernel[KERNEL_INDICES] = { 0.0 };
> +  float sum = 0.0;
> +
> +  for (idx = 0; idx < KERNEL_INDICES; idx++) {
> + float x = idx - 4.0 + row_ofs;
> +
> + if (fabs (x) <= radius)
> +kernel[idx] = sinc (M_PI * x) * sinc (M_PI * x / radius);
 ^ ^

Why the whitespace?

> +
> + sum += kernel[idx];
> +   }
> +
> +   /* normalise the row */
> +   if (sum)
> +  for (idx = 0; idx < KERNEL_INDICES; idx++)
> + kernel[idx] /= sum;
> +
> +   /* convert to 1.14 format */
> +   for (idx = 0; idx < KERNEL_INDICES; idx++) {
> +  int val = kernel[idx] * (float) (1 << 14);
> +
> +  if (val < -0x8000)
> + val = -0x8000;
> +  else if (val > 0x7fff)
> + val = 0x7fff;
> +
> +  kernel_val[i++] = val;
> +   }
> +
> +   row_ofs -= 1.0 / ((KERNEL_ROWS - 1) * 2);
> +   }
> +
> +   kernel_val[KERNEL_SIZE] = 0;
> +
> +   /* Now convert the kernel values into state values */
> +   for (i = 0; i < KERNEL_STATE_SZ * 2; i += 2)
> +  filter_kernel[i / 2] =
> + VIVS_DE_FILTER_KERNEL_COEFFICIENT0 (kernel_val[i]) |
> + VIVS_DE_FILTER_KERNEL_COEFFICIENT1 (kernel_val[i + 1]);
> +}
> +
>  bool etna_try_2d_blit(struct pipe_context *pctx,
>const struct pipe_blit_info *blit_info)
>  {
> struct etna_context *ctx = etna_context(pctx);
> +   struct etna_screen *screen = ctx->screen;
> struct etna_cmd_stream *stream = ctx->stream2d;
> struct etna_coalesce coalesce;
> struct etna_reloc ry, ru, rv, rdst;
> struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
> +   struct etna_bo *temp_bo = NULL;
> uint32_t src_format;
> +   bool ext_blt = VIV_2D_FEATURE(screen, chipMinorFeatures2, 2D_TILING);
> +   uint32_t dst_config;
>  
> assert(util_format_is_yuv(blit_info->src.format));
> assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
> @@ -55,6 +128,11 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
> if (!stream)
>return FALSE;
>  
> +  if (unlikely(!ext_blt && !filter_kernel_initialized)) {
> +  etnaviv_init_filter_kernel();
> +  filter_kernel_initialized = true;
> +  }
> +
> switch (blit_info->src.format) {
> case PIPE_FORMAT_NV12:
>src_format = DE_FORMAT_NV12;
> @@ -66,6 +144,18 @@ bool etna_try_2d_blit(struct pipe_context *pctx,
>return FALSE;
> }
>  
> +   res_dst = blit_info->dst.resource;
> +
> +   if (!ext_blt && etna_resource(res_dst)->layout != ETNA_LAYOUT_LINEAR) {
> +  struct etna_resource *dst = etna_resource(blit_info->dst.resource);
> +  unsigned int bo_size = dst->levels[blit_info->dst.level].stride 

Re: [Mesa-dev] [PATCH 4/8] etnaviv: add 2D GPU YUV->RGB blitter

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> This adds a blit path using the 2D GPU for a linear YUV to tiled RGB
> blit. This allows to implement importing of planar YUV textures with
> a single copy.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/Makefile.sources  |2 +
>  src/gallium/drivers/etnaviv/etnaviv_2d.c  |  164 ++
>  src/gallium/drivers/etnaviv/etnaviv_2d.h  |   37 +
>  src/gallium/drivers/etnaviv/hw/state_2d.xml.h | 1499 +
>  src/gallium/drivers/etnaviv/meson.build   |3 +
>  5 files changed, 1705 insertions(+)
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.c
>  create mode 100644 src/gallium/drivers/etnaviv/etnaviv_2d.h
>  create mode 100644 src/gallium/drivers/etnaviv/hw/state_2d.xml.h
> 
> diff --git a/src/gallium/drivers/etnaviv/Makefile.sources 
> b/src/gallium/drivers/etnaviv/Makefile.sources
> index 01e7e49a38ad..36dd7d1b6aa4 100644
> --- a/src/gallium/drivers/etnaviv/Makefile.sources
> +++ b/src/gallium/drivers/etnaviv/Makefile.sources
> @@ -3,11 +3,13 @@ C_SOURCES :=  \
>   hw/common.xml.h \
>   hw/common_3d.xml.h \
>   hw/isa.xml.h \
> + hw/state_2d.xml.h \
>   hw/state_3d.xml.h \
>   hw/state_blt.xml.h \
>   hw/state.xml.h \
>   hw/texdesc_3d.xml.h \
>   \
> + etnaviv_2d.c \
>   etnaviv_asm.c \
>   etnaviv_asm.h \
>   etnaviv_blend.c \
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_2d.c 
> b/src/gallium/drivers/etnaviv/etnaviv_2d.c
> new file mode 100644
> index ..457fa4e0cbd0
> --- /dev/null
> +++ b/src/gallium/drivers/etnaviv/etnaviv_2d.c
> @@ -0,0 +1,164 @@
> +/*
> + * Copyright (c) 2018 Etnaviv Project
> + *
> + * 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
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "etnaviv_2d.h"
> +#include "etnaviv_context.h"
> +#include "etnaviv_emit.h"
> +#include "etnaviv_screen.h"
> +
> +#include "pipe/p_state.h"
> +#include "util/u_format.h"
> +
> +#include "hw/state_2d.xml.h"
> +
> +#include 
> +
> +#define EMIT_STATE(state_name, src_value) \
> +   etna_coalsence_emit(stream, , VIVS_##state_name, src_value)
> +
> +#define EMIT_STATE_RELOC(state_name, src_value) \
> +   etna_coalsence_emit_reloc(stream, , VIVS_##state_name, src_value)
> +
> +bool etna_try_2d_blit(struct pipe_context *pctx,
> +  const struct pipe_blit_info *blit_info)
> +{
> +   struct etna_context *ctx = etna_context(pctx);
> +   struct etna_cmd_stream *stream = ctx->stream2d;
> +   struct etna_coalesce coalesce;
> +   struct etna_reloc ry, ru, rv, rdst;
> +   struct pipe_resource *res_y, *res_u, *res_v, *res_dst;
> +   uint32_t src_format;
> +
> +   assert(util_format_is_yuv(blit_info->src.format));
> +   assert(blit_info->dst.format == PIPE_FORMAT_R8G8B8A8_UNORM);
> +
> +   if (!stream)
> +  return FALSE;
> +
> +   switch (blit_info->src.format) {
> +   case PIPE_FORMAT_NV12:
> +  src_format = DE_FORMAT_NV12;
> +  break;
> +   case PIPE_FORMAT_YUYV:
> +  src_format = DE_FORMAT_YUY2;
> +  break;
> +   default:
> +  return FALSE;
> +   }
> +
> +   res_y = blit_info->src.resource;
> +   res_u = res_y->next ? res_y->next : res_y;
> +   res_v = res_u->next ? res_u->next : res_u;
> +
> +   ry.bo = etna_resource(res_y)->bo;
> +   ry.offset = etna_resource(res_y)->levels[blit_info->src.level].offset;
> +   ru.bo = etna_resource(res_u)->bo;
> +   ru.offset = etna_resource(res_u)->levels[blit_info->src.level].offset;
> +   rv.bo = etna_resource(res_v)->bo;
> +   rv.offset = etna_resource(res_v)->levels[blit_info->src.level].offset;
> +
> +   ry.flags = ru.flags = rv.flags = ETNA_RELOC_READ;
> +
> +   res_dst = blit_info->dst.resource;
> +   rdst.bo = etna_resource(res_dst)->bo;
> +   rdst.flags = ETNA_RELOC_WRITE;
> +   rdst.offset = 0;
> +
> +   etna_coalesce_start(stream, );
> +
> +   EMIT_STATE_RELOC(DE_SRC_ADDRESS, );
> +   

Re: [Mesa-dev] [PATCH 5/8] etnaviv: export etna_submit_rs_state

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> The new 2D YUV blit needs this in some cases, so make it available.

That is a bit unspecific.

Maybe
s/in some cases/to implement a workaround for a cache flushing bug on (at 
least) GC2000/
?

> Signed-off-by: Lucas Stach 

Either way,

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 2/8] etnaviv: clear out next pointer when allocating resource

[Philipp Zabel]

On Mon, 2019-04-15 at 12:31 +0200, Lucas Stach wrote:
> Am Montag, den 15.04.2019, 12:20 +0200 schrieb Philipp Zabel:
> > On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> > > We copy the template resource content into the newly allocated resource.
> > > If the template derived from a planar resource this leads to a non 
> > > reference
> > > counted copy of the next resource pointer. Make sure to clear this out 
> > > when
> > > allocating a new resource.
> > > 
> > > Signed-off-by: Lucas Stach 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > index 83179d3cd088..77d027ac806b 100644
> > > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > > @@ -274,6 +274,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> > > unsigned layout,
> > 
> > Context:
> > 
> >    rsc = CALLOC_STRUCT(etna_resource);
> >    if (!rsc)
> > >    return NULL;
> > >  
> > > rsc->base = *templat;
> 
> This copies the content of templat into our resource base, so if
> templat has the next pointer set it will also be set in our resource.

Oh, and the patch description, which I should have read more closely,
even correctly points it out.

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 2/8] etnaviv: clear out next pointer when allocating resource

[Lucas Stach]

Am Montag, den 15.04.2019, 12:20 +0200 schrieb Philipp Zabel:
> On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> > We copy the template resource content into the newly allocated resource.
> > If the template derived from a planar resource this leads to a non reference
> > counted copy of the next resource pointer. Make sure to clear this out when
> > allocating a new resource.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > index 83179d3cd088..77d027ac806b 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> > @@ -274,6 +274,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, 
> > unsigned layout,
> 
> Context:
> 
>    rsc = CALLOC_STRUCT(etna_resource);
>    if (!rsc)
> >    return NULL;
> >  
> > rsc->base = *templat;

This copies the content of templat into our resource base, so if
templat has the next pointer set it will also be set in our resource.

> > +   rsc->base.next = NULL;
> > rsc->base.screen = pscreen;
> > rsc->base.nr_samples = nr_samples;
> > rsc->layout = layout;
> 
> The calloc just above already clears the memory to zero.

See above.

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

Re: [Mesa-dev] [PATCH 4/8] etnaviv: add 2D GPU YUV->RGB blitter

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> This adds a blit path using the 2D GPU for a linear YUV to tiled RGB
> blit. This allows to implement importing of planar YUV textures with
> a single copy.
> 
> Signed-off-by: Lucas Stach 

Reviewed-by: Philipp Zabel 

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

[Mesa-dev] [Bug 110436] preview connection issues

[bugzilla-daemon]

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

Preeti  changed:

   What|Removed |Added

 QA Contact|mesa-dev@lists.freedesktop. |preethi.dasika@getrightdata
   |org |.com
   Assignee|mesa-dev@lists.freedesktop. |preethi.dasika@getrightdata
   |org |.com

-- 
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 110436] preview connection issues

[bugzilla-daemon]

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

Bug ID: 110436
   Summary: preview connection issues
   Product: Mesa
   Version: git
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Demos
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: preethi.das...@getrightdata.com
QA Contact: mesa-dev@lists.freedesktop.org

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

Re: [Mesa-dev] [PATCH 2/8] etnaviv: clear out next pointer when allocating resource

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> We copy the template resource content into the newly allocated resource.
> If the template derived from a planar resource this leads to a non reference
> counted copy of the next resource pointer. Make sure to clear this out when
> allocating a new resource.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 83179d3cd088..77d027ac806b 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -274,6 +274,7 @@ etna_resource_alloc(struct pipe_screen *pscreen, unsigned 
> layout,

Context:

   rsc = CALLOC_STRUCT(etna_resource);
   if (!rsc)
>return NULL;
>  
> rsc->base = *templat;
> +   rsc->base.next = NULL;
> rsc->base.screen = pscreen;
> rsc->base.nr_samples = nr_samples;
> rsc->layout = layout;

The calloc just above already clears the memory to zero.

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

Re: [Mesa-dev] [PATCH 3/8] etnaviv: remember data offset into BO

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> Imported resources might not start at offset 0 into the buffer object.
> Make sure to remember the offset that is provided with the handle on
> import.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c 
> b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> index 77d027ac806b..f405b880a6c0 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_resource.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_resource.c
> @@ -535,6 +535,7 @@ etna_resource_from_handle(struct pipe_screen *pscreen,
>  
> level->width = tmpl->width0;
> level->height = tmpl->height0;
> +   level->offset = handle->offset;
>  
> /* Determine padding of the imported resource. */
> unsigned paddingX = 0, paddingY = 0;

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 1/8] etnaviv: create optional 2d pipe in screen

[Philipp Zabel]

On Fri, 2019-04-12 at 19:38 +0200, Lucas Stach wrote:
> The 2D pipe is useful to implement fast planar and interleaved YUV buffer
> imports. Not all systems have a 2D capable core, so this is strictly
> optional.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c |  6 ++
>  src/gallium/drivers/etnaviv/etnaviv_context.h |  1 +
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  | 68 +++
>  src/gallium/drivers/etnaviv/etnaviv_screen.h  |  6 ++
>  4 files changed, 81 insertions(+)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index a59338490b62..631f551d0ad4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -78,6 +78,9 @@ etna_context_destroy(struct pipe_context *pctx)
> if (ctx->stream)
>etna_cmd_stream_del(ctx->stream);
>  
> +   if (ctx->stream2d)
> +  etna_cmd_stream_del(ctx->stream2d);
> +
> slab_destroy_child(>transfer_pool);
>  
> if (ctx->in_fence_fd != -1)
> @@ -434,6 +437,9 @@ etna_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
> if (ctx->stream == NULL)
>goto fail;
>  
> +   if (screen->pipe2d)
> +  ctx->stream2d = etna_cmd_stream_new(screen->pipe2d, 0x1000, NULL, 
> NULL);
> +
> /* context ctxate setup */
> ctx->specs = screen->specs;
> ctx->screen = screen;
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.h 
> b/src/gallium/drivers/etnaviv/etnaviv_context.h
> index a79d739100d9..2c6e5d6c3db1 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.h
> @@ -110,6 +110,7 @@ struct etna_context {
> struct etna_specs specs;
> struct etna_screen *screen;
> struct etna_cmd_stream *stream;
> +   struct etna_cmd_stream *stream2d;
>  
> /* which state objects need to be re-emit'd: */
> enum {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 62b6f1c80fae..0dea6056c75a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -95,6 +95,12 @@ etna_screen_destroy(struct pipe_screen *pscreen)
> if (screen->gpu)
>etna_gpu_del(screen->gpu);
>  
> +   if (screen->pipe2d)
> +  etna_pipe_del(screen->pipe2d);
> +
> +   if (screen->gpu2d)
> +  etna_gpu_del(screen->gpu2d);
> +
> if (screen->ro)
>FREE(screen->ro);
>  
> @@ -891,6 +897,66 @@ etna_screen_bo_from_handle(struct pipe_screen *pscreen,
> return bo;
>  }
>  
> +static void etna_screen_init_2d(struct etna_screen *screen)
> +{
> +   struct etna_gpu *gpu2d = NULL;
> +   uint64_t val;
> +   int ret, i;
> +
> +   /* If the current GPU is a combined 2d/3D core, use it as 2D engine */
   ^ 2D

> +   if (screen->features[0] & chipFeatures_PIPE_2D)
> +  gpu2d = screen->gpu;

If the GPU is a combined 2D/3D core, is screen->gpu2d set anywhere?
I assume it isn't on purpose, so it can be used to check whether
etna_gpu_del(screen->gpu2d) must be called in etna_screen_destroy().

> +
> +   /* otherwise search for a 2D capable core */
> +   if (!gpu2d) {

This could just be

   else {
  /* otherwise search for a 2D capable core */

> +  for (i = 0;; i++) {
> + gpu2d = etna_gpu_new(screen->dev, i);
> + if (!gpu2d)
> +return;
> +
> + ret = etna_gpu_get_param(gpu2d, ETNA_GPU_FEATURES_0, );
> + if (!ret && (val & chipFeatures_PIPE_2D)) {
> +screen->gpu2d = gpu2d;
> +break;
> + }
> +
> + etna_gpu_del(gpu2d);
> +  }
> +   }
> +
> +   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_0, ))

If the GPU is a combined 2D/3D core, and screen->gpu2d == NULL at this
point, won't this fail trying to dereference the gpu NULL pointer in
etna_gpu_get_param()? I suppose these should be using the local gpu2d
variable instead of screen->gpu2d.

Further, if the GPU is a combined 2D/3D core, we have already queried
GPU features just before etna_screen_init_2d() was called,
in etna_screen_create(). We could just copy features to features2d.

Nitpick: if the gpu2d is 2D-only, the only way we can arrive here is
from the break in the loop above, just after val was already set to the
ETNA_GPU_FEATURES_0 value. In that case the first call to
etna_gpu_get_parm() is superfluous.

> +  return;
> +   screen->features2d[0] = val;
> +
> +   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_1, ))
> +  return;
> +   screen->features2d[1] = val;
> +
> +   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_2, ))
> +  return;
> +   screen->features2d[2] = val;
> +
> +   if (etna_gpu_get_param(screen->gpu2d, ETNA_GPU_FEATURES_3, ))
> +  return;
> +   screen->features2d[3] = val;
> +
> +   if (etna_gpu_get_param(screen->gpu2d, 

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Michel Dänzer]

On 2019-04-12 7:33 p.m., Lucas Stach wrote:
> Unconditionally requesting both bindings can lead to premature
> failure to create a valid image.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index efb43c0d7973..510b7f8d04a7 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
>  {
> const struct dri2_format_mapping *map = 
> dri2_get_mapping_by_format(format);
> struct dri_screen *screen = dri_screen(_screen);
> +   struct pipe_screen *pscreen = screen->base.screen;
> __DRIimage *img;
> struct pipe_resource templ;
> -   unsigned tex_usage;
> +   unsigned tex_usage = 0;
>  
> if (!map)
>return NULL;
>  
> -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> screen->target,
> +0, 0, PIPE_BIND_RENDER_TARGET))
> +  tex_usage |= PIPE_BIND_RENDER_TARGET;
> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> screen->target,
> +0, 0, PIPE_BIND_SAMPLER_VIEW))
> +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> +
> +   if (!tex_usage)
> +  return NULL;
>  
> if (use & __DRI_IMAGE_USE_SCANOUT)
>tex_usage |= PIPE_BIND_SCANOUT;
> 

Since there are no __DRI_IMAGE_USE_* flags for rendering & sampling, the
expectation does seem to be that both are supported. What happens if an
image is created for a format which only supports sampling, then the
caller attempts rendering to it?


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

Re: [Mesa-dev] [PATCH 1/6] st/dri: allow to create image for formats that only support SV or RT binding

[Philipp Zabel]

On Fri, 2019-04-12 at 19:33 +0200, Lucas Stach wrote:
> Unconditionally requesting both bindings can lead to premature
> failure to create a valid image.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/state_trackers/dri/dri2.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/dri/dri2.c 
> b/src/gallium/state_trackers/dri/dri2.c
> index efb43c0d7973..510b7f8d04a7 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -987,14 +987,23 @@ dri2_create_image_common(__DRIscreen *_screen,
>  {
> const struct dri2_format_mapping *map = 
> dri2_get_mapping_by_format(format);
> struct dri_screen *screen = dri_screen(_screen);
> +   struct pipe_screen *pscreen = screen->base.screen;
> __DRIimage *img;
> struct pipe_resource templ;
> -   unsigned tex_usage;
> +   unsigned tex_usage = 0;
>  
> if (!map)
>return NULL;
>  
> -   tex_usage = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> screen->target,
> +0, 0, PIPE_BIND_RENDER_TARGET))
> +  tex_usage |= PIPE_BIND_RENDER_TARGET;
> +   if (pscreen->is_format_supported(pscreen, map->pipe_format, 
> screen->target,
> +0, 0, PIPE_BIND_SAMPLER_VIEW))
> +  tex_usage |= PIPE_BIND_SAMPLER_VIEW;
> +
> +   if (!tex_usage)
> +  return NULL;
>  
> if (use & __DRI_IMAGE_USE_SCANOUT)
>tex_usage |= PIPE_BIND_SCANOUT;

Reviewed-by: Philipp Zabel 

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

[Mesa-dev] [Bug 110433] preview issues

[bugzilla-daemon]

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

vanaja  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |vanaja.thummalapalli@getrig
   |org |htdata.com
 QA Contact|mesa-dev@lists.freedesktop. |vanaja.thummalapalli@getrig
   |org |htdata.com

-- 
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 110434] preview issues

[bugzilla-daemon]

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

vanaja  changed:

   What|Removed |Added

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

-- 
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 110434] preview issues

[bugzilla-daemon]

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

Bug ID: 110434
   Summary: preview issues
   Product: Mesa
   Version: git
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Demos
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: vanaja.thummalapa...@getrightdata.com
QA Contact: mesa-dev@lists.freedesktop.org

-- 
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 110433] preview issues

[bugzilla-daemon]

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

Bug ID: 110433
   Summary: preview issues
   Product: Mesa
   Version: git
  Hardware: Other
OS: Windows (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Demos
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: vanaja.thummalapa...@getrightdata.com
QA Contact: mesa-dev@lists.freedesktop.org

-- 
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] Move adriconf to mesa repositories

[Erik Faye-Lund]

Yeah, moving this to the mesa group in gitlab would be great for
visibility.

On Sat, 2019-04-13 at 12:22 +, Jean Hertel wrote:
> Any other mesa developer interested in seeing this move forward?
> 
> Kind Regards,
> Jean Hertel
> 
> ___
> 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] ac/nir_to_llvm: use correct intrinsic type for bindless atomic_{min, max}

[Bas Nieuwenhuizen]

r-b

On Mon, Apr 15, 2019 at 2:17 AM Timothy Arceri  wrote:
>
> Coverity: CID 1444664
>
> Fixes: d62d434fe920 ("ac/nir_to_llvm: add image bindless support")
> ---
>  src/amd/common/ac_nir_to_llvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 61b33c74e6c..8266e7e9f68 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -2549,8 +2549,8 @@ static LLVMValueRef visit_image_atomic(struct 
> ac_nir_context *ctx,
> bool is_unsigned;
> bool is_array;
> if (bindless) {
> -   if (instr->intrinsic == nir_intrinsic_image_atomic_min ||
> -   instr->intrinsic == nir_intrinsic_image_atomic_max) {
> +   if (instr->intrinsic == 
> nir_intrinsic_bindless_image_atomic_min ||
> +   instr->intrinsic == 
> nir_intrinsic_bindless_image_atomic_max) {
> const GLenum format = nir_intrinsic_format(instr);
> assert(format == GL_R32UI || format == GL_R32I);
> is_unsigned = format == GL_R32UI;
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: fix packing components with arrays

[Samuel Pitoiset]

On 4/15/19 10:55 AM, Timothy Arceri wrote:

On 15/4/19 5:53 pm, Samuel Pitoiset wrote:

Shouldn't we also apply that fix in gather_varying_component_info() ?



No because we don't enter that code path for arrays because we don't 
try to pack arrays into other slots/components. But we do pack scalar 
components with "unmovable" arrays when there is space. Hopefully that 
makes sense.


That makes sense.

Reviewed-by: Samuel Pitoiset 




On 4/15/19 7:00 AM, Timothy Arceri wrote:

When gathering info for unmovable types we need to handle arrays.
While we dont support packing/moving arrays we do support packing
scalar components with these arrays.

Fixes piglit:
tests/spec/arb_enhanced_layouts/execution/component-layout/vs-fs-array-interleave-range.shader_test 



Fixes: 5eb17506e159 ("nir: do not pack varying with different types")
---
  src/compiler/nir/nir_linking_helpers.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 7594728e25e..f4494c78f98 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -309,7 +309,8 @@ get_unmoveable_components_masks(struct exec_list 
*var_list,

  comps[location + i].interp_type =
 get_interp_type(var, type, default_to_smooth_interp);
  comps[location + i].interp_loc = get_interp_loc(var);
-    comps[location + i].is_32bit = glsl_type_is_32bit(type);
+    comps[location + i].is_32bit =
+   glsl_type_is_32bit(glsl_without_array(type));
   }
    }
 }

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

Re: [Mesa-dev] [PATCH] nir: fix packing components with arrays

[Timothy Arceri]

On 15/4/19 5:53 pm, Samuel Pitoiset wrote:

Shouldn't we also apply that fix in gather_varying_component_info() ?



No because we don't enter that code path for arrays because we don't try 
to pack arrays into other slots/components. But we do pack scalar 
components with "unmovable" arrays when there is space. Hopefully that 
makes sense.



On 4/15/19 7:00 AM, Timothy Arceri wrote:

When gathering info for unmovable types we need to handle arrays.
While we dont support packing/moving arrays we do support packing
scalar components with these arrays.

Fixes piglit:
tests/spec/arb_enhanced_layouts/execution/component-layout/vs-fs-array-interleave-range.shader_test 



Fixes: 5eb17506e159 ("nir: do not pack varying with different types")
---
  src/compiler/nir/nir_linking_helpers.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

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

index 7594728e25e..f4494c78f98 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -309,7 +309,8 @@ get_unmoveable_components_masks(struct exec_list 
*var_list,

  comps[location + i].interp_type =
 get_interp_type(var, type, default_to_smooth_interp);
  comps[location + i].interp_loc = get_interp_loc(var);
-    comps[location + i].is_32bit = glsl_type_is_32bit(type);
+    comps[location + i].is_32bit =
+   glsl_type_is_32bit(glsl_without_array(type));
   }
    }
 }

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

[Mesa-dev] [Bug 110431] Please add support for GL_EXT_gpu_shader4 (including on non-core profiles)

[bugzilla-daemon]

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

Bug ID: 110431
   Summary: Please add support for GL_EXT_gpu_shader4 (including
on non-core profiles)
   Product: Mesa
   Version: 18.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: f...@deegan.id.au
QA Contact: mesa-dev@lists.freedesktop.org

Certain applications (eg. most Minecraft shaders, Substance Painter, and
probably a bunch of other games) tend to assume that GL_EXT_gpu_shader4 is
supported everywhere. This makes Mesa (and particularly AMDGPU) users sad, as
shaders won't work, instead filling logs with messages like "warning: extension
`GL_EXT_gpu_shader4' unsupported in fragment shader" and "error: no function
with name 'texelFetch2D'".

(Hopefully I tagged the right component...)

-- 
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] nir: fix packing components with arrays

[Samuel Pitoiset]

Shouldn't we also apply that fix in gather_varying_component_info() ?

On 4/15/19 7:00 AM, Timothy Arceri wrote:

When gathering info for unmovable types we need to handle arrays.
While we dont support packing/moving arrays we do support packing
scalar components with these arrays.

Fixes piglit:
tests/spec/arb_enhanced_layouts/execution/component-layout/vs-fs-array-interleave-range.shader_test

Fixes: 5eb17506e159 ("nir: do not pack varying with different types")
---
  src/compiler/nir/nir_linking_helpers.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index 7594728e25e..f4494c78f98 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -309,7 +309,8 @@ get_unmoveable_components_masks(struct exec_list *var_list,
  comps[location + i].interp_type =
 get_interp_type(var, type, default_to_smooth_interp);
  comps[location + i].interp_loc = get_interp_loc(var);
-comps[location + i].is_32bit = glsl_type_is_32bit(type);
+comps[location + i].is_32bit =
+   glsl_type_is_32bit(glsl_without_array(type));
   }
}
 }

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

[Mesa-dev] [PATCH] radeon: Fix width align for hevc encode

[Lei Zhou]

Before, width is aligned to 16, we get 512x800 when encoding
with 480x800, and conformance_window_flag=0 in sps.

Signed-off-by: Lei Zhou 
---
 src/gallium/drivers/radeon/radeon_uvd_enc.c | 2 +-
 src/gallium/drivers/radeon/radeon_vcn_enc.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c 
b/src/gallium/drivers/radeon/radeon_uvd_enc.c
index 3164dbb2c20..f0bf756ec50 100644
--- a/src/gallium/drivers/radeon/radeon_uvd_enc.c
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
@@ -66,7 +66,7 @@ radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
   || (pic->picture_type == PIPE_H265_ENC_PICTURE_TYPE_I);
enc->enc_pic.crop_left = 0;
enc->enc_pic.crop_right =
-  (align(enc->base.width, 16) - enc->base.width) / 2;
+  (align(enc->base.width, 64) - enc->base.width) / 2;
enc->enc_pic.crop_top = 0;
enc->enc_pic.crop_bottom =
   (align(enc->base.height, 16) - enc->base.height) / 2;
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc.c
index 7d64a28a405..248f4c7d99e 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.c
@@ -66,7 +66,7 @@ static void radeon_vcn_enc_get_param(struct radeon_encoder 
*enc, struct pipe_pic
   enc->enc_pic.is_idr = (pic->picture_type == 
PIPE_H265_ENC_PICTURE_TYPE_IDR) ||
 (pic->picture_type == 
PIPE_H265_ENC_PICTURE_TYPE_I);
   enc->enc_pic.crop_left = 0;
-  enc->enc_pic.crop_right = (align(enc->base.width, 16) - enc->base.width) 
/ 2;
+  enc->enc_pic.crop_right = (align(enc->base.width, 64) - enc->base.width) 
/ 2;
   enc->enc_pic.crop_top = 0;
   enc->enc_pic.crop_bottom = (align(enc->base.height, 16) - 
enc->base.height) / 2;
   enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
-- 
2.21.0



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