Re: [Mesa-dev] [PATCH v2 1/9] panfrost: Make ctx->job useful

2019-08-10 Thread Juan A. Suarez Romero 
On Thu, 2019-08-08 at 15:28 +0200, Boris Brezillon wrote:
> On Thu, 8 Aug 2019 06:08:05 -0700
> Alyssa Rosenzweig  wrote:
> 
> > @Boris I don't see why this patch particularly needs to be backported to
> > 19.1?
> 
> Nope, no reason to backport it to 19.1. It's just a (bad?) kernel dev
> habit to put "Fixes:" tag the patch fixes a problem introduced by a
> previous commit. But it does not necessarily means "backport to stable"
> in mind.
> 

If a patch fixes another patch that is in the stable branch, we try at our best
to include the fix also in the stable branch. I think it makes sense to fix
something that is already in stable.

But if you think this fix is not worth to be on stable, that's fine. I'll keep
it ignored.

Thanks!

> > On Thu, Aug 08, 2019 at 11:46:43AM +0200, Juan A. Suarez Romero wrote:
> > > On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:  
> > > > ctx->job is supposed to serve as a cache to avoid an hash table lookup
> > > > everytime we access the job attached to the currently bound FB, except
> > > > it was never assigned to anything but NULL.
> > > > 
> > > > Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> > > > Also add a missing NULL assignment in the ->set_framebuffer_state()
> > > > path.
> > > > 
> > > > While at it, add extra assert()s to make sure ctx->job is consistent.
> > > > 
> > > > Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> > > > Signed-off-by: Boris Brezillon 
> > > > Changes in v2:
> > > > * New patch (suggested by Alyssa)  
> > > 
> > > This patch is a candidate for 19.1, but unfortunately it does not apply 
> > > cleanly.
> > > It seems it depends on a bunch of other commits not in 19.1
> > > 
> > > At this point, I will ignore/reject this patch for 19.1, unless you can 
> > > provide
> > > me a specific version for 19.1 branch (use staging/19.1 as reference).
> > > 
> > > Thanks.
> > > 
> > >   J.A.
> > >   
> > > > ---
> > > >  src/gallium/drivers/panfrost/pan_context.c |  5 +
> > > >  src/gallium/drivers/panfrost/pan_job.c | 19 ++-
> > > >  2 files changed, 23 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> > > > b/src/gallium/drivers/panfrost/pan_context.c
> > > > index 014f8f6a9d07..ba2df2ce66ae 100644
> > > > --- a/src/gallium/drivers/panfrost/pan_context.c
> > > > +++ b/src/gallium/drivers/panfrost/pan_context.c
> > > > @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct 
> > > > pipe_context *pctx,
> > > >  panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
> > > >  }
> > > >  
> > > > +/* Invalidate the FBO job cache since we've just been assigned 
> > > > a new
> > > > + * FB state.
> > > > + */
> > > > +ctx->job = NULL;
> > > > +
> > > >  util_copy_framebuffer_state(&ctx->pipe_framebuffer, fb);
> > > >  
> > > >  /* Given that we're rendering, we'd love to have compression */
> > > > diff --git a/src/gallium/drivers/panfrost/pan_job.c 
> > > > b/src/gallium/drivers/panfrost/pan_job.c
> > > > index 6339b39d29a0..cc81d475165e 100644
> > > > --- a/src/gallium/drivers/panfrost/pan_job.c
> > > > +++ b/src/gallium/drivers/panfrost/pan_job.c
> > > > @@ -23,6 +23,8 @@
> > > >   *
> > > >   */
> > > >  
> > > > +#include 
> > > > +
> > > >  #include "pan_context.h"
> > > >  #include "util/hash_table.h"
> > > >  #include "util/ralloc.h"
> > > > @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context 
> > > > *ctx)
> > > >  
> > > >  /* If we already began rendering, use that */
> > > >  
> > > > -if (ctx->job)
> > > > +if (ctx->job) {
> > > > +assert(ctx->job->key.zsbuf == 
> > > > ctx->pipe_framebuffer.zsbuf &&
> > > > +   !memcmp(ctx->job->key.cbufs,
> > > > +   ctx->pipe_framebuffer.cbufs,
> > > > +   sizeof(ctx->job->key.cbufs)));
> > > >  return ctx->job;
> > > > +}
> > > >  
> > > >  /* If not, look up the job */
> > > >  
> > > > @@ -133,6 +140,10 @@ panfrost_get_job_for_fbo(struct panfrost_context 
> > > > *ctx)
> > > >  struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
> > > >  struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
> > > >  
> > > > +/* Set this job as the current FBO job. Will be reset when 
> > > > updating the
> > > > + * FB state and when submitting or releasing a job.
> > > > + */
> > > > +ctx->job = job;
> > > >  return job;
> > > >  }
> > > >  
> > > > @@ -181,6 +192,12 @@ panfrost_job_submit(struct panfrost_context *ctx, 
> > > > struct panfrost_job *job)
> > > >  
> > > >  if (ret)
> > > >  fprintf(stderr, "panfrost_job_submit failed: %d\n", 
> > > > ret);
> > > > +
> > > > +/* The job has been submitted, let's invalidate the current 
> > > > F

Re: [Mesa-dev] [PATCH 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Kenneth Graunke 
This patch is also:

Reviewed-by: Kenneth Graunke 

though it would probably be best if Jason or Lionel reviewed it as well.

On Friday, August 9, 2019 5:20:39 PM PDT Francisco Jerez wrote:
> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> for the rationale.  Marked optional because no performance evaluation
> has been done on this commit, it is provided to match the hashing
> settings of the Iris driver.  Test reports welcome.
> ---
>  src/intel/vulkan/anv_genX.h|  4 ++
>  src/intel/vulkan/anv_private.h |  6 ++
>  src/intel/vulkan/genX_blorp_exec.c |  6 ++
>  src/intel/vulkan/genX_cmd_buffer.c | 96 ++
>  4 files changed, 112 insertions(+)
> 
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index a5435e566a3..06c6b467acf 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct 
> anv_cmd_buffer *cmd_buffer);
>  
>  void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer 
> *cmd_buffer);
>  
> +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer *cmd_buffer,
> +unsigned width, unsigned height,
> +unsigned scale);
> +
>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);
>  
> diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
> index 2465f264354..b381386a716 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
>  
> bool conditional_render_enabled;
>  
> +   /**
> +* Last rendering scale argument provided to
> +* genX(cmd_buffer_emit_hashing_mode)().
> +*/
> +   unsigned current_hash_scale;
> +
> /**
>  * Array length is anv_cmd_state::pass::attachment_count. Array content is
>  * valid only when recording a render pass instance.
> diff --git a/src/intel/vulkan/genX_blorp_exec.c 
> b/src/intel/vulkan/genX_blorp_exec.c
> index 1592e7f7e3d..e9eedc06696 100644
> --- a/src/intel/vulkan/genX_blorp_exec.c
> +++ b/src/intel/vulkan/genX_blorp_exec.c
> @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
>genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
> }
>  
> +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
> +   if (cmd_buffer->state.current_hash_scale != scale) {
> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 - params->x0,
> + params->y1 - params->y0, scale);
> +   }
> +
>  #if GEN_GEN >= 11
> /* The PIPE_CONTROL command description says:
>  *
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 86ef1663ac4..e9e5570d49f 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
>  */
> primary->state.current_pipeline = UINT32_MAX;
> primary->state.current_l3_config = NULL;
> +   primary->state.current_hash_scale = 0;
>  
> /* Each of the secondary command buffers will use its own state base
>  * address.  We need to re-emit state base address for the primary after
> @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer 
> *cmd_buffer)
>  
> genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
>  
> +   if (cmd_buffer->state.current_hash_scale != 1)
> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX, UINT_MAX, 1);
> +
> genX(flush_pipeline_select_3d)(cmd_buffer);
>  
> if (vb_emit) {
> @@ -3925,6 +3929,98 @@ genX(cmd_buffer_emit_gen7_depth_flush)(struct 
> anv_cmd_buffer *cmd_buffer)
> }
>  }
>  
> +/**
> + * Update the pixel hashing modes that determine the balancing of PS threads
> + * across subslices and slices.
> + *
> + * \param width Width bound of the rendering area (already scaled down if \p
> + *  scale is greater than 1).
> + * \param height Height bound of the rendering area (already scaled down if 
> \p
> + *   scale is greater than 1).
> + * \param scale The number of framebuffer samples that could potentially be
> + *  affected by an individual channel of the PS thread.  This is
> + *  typically one for single-sampled rendering, but for 
> operations
> + *  like CCS resolves and fast clears a single PS invocation may
> + *  update a huge number of pixels, in which case a finer
> + *  balancing is desirable in order to maximally utilize the
> + *  bandwidth available.  UINT_MAX can be used as shorthand for
> + *  "finest hashing mode available".
> + */
> +void
> +genX(cmd_buffer_emit_hashing_mode)(struct

Re: [Mesa-dev] [PATCH 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Jason Ekstrand 
Let's hold this for at least a tiny bit. I'll run some benchmarks and may 
want to tweak how in interacts with the rest of the vulkan state tracking.  
Thanks for figuring out a heuristic!


--Jason

On August 9, 2019 19:22:48 Francisco Jerez  wrote:


See "i965/gen9: Optimize slice and subslice load balancing behavior."
for the rationale.  Marked optional because no performance evaluation
has been done on this commit, it is provided to match the hashing
settings of the Iris driver.  Test reports welcome.
---
src/intel/vulkan/anv_genX.h|  4 ++
src/intel/vulkan/anv_private.h |  6 ++
src/intel/vulkan/genX_blorp_exec.c |  6 ++
src/intel/vulkan/genX_cmd_buffer.c | 96 ++
4 files changed, 112 insertions(+)

diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
index a5435e566a3..06c6b467acf 100644
--- a/src/intel/vulkan/anv_genX.h
+++ b/src/intel/vulkan/anv_genX.h
@@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct 
anv_cmd_buffer *cmd_buffer);


void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer *cmd_buffer);

+void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer *cmd_buffer,
+unsigned width, unsigned height,
+unsigned scale);
+
void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 2465f264354..b381386a716 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2421,6 +2421,12 @@ struct anv_cmd_state {

   bool conditional_render_enabled;

+   /**
+* Last rendering scale argument provided to
+* genX(cmd_buffer_emit_hashing_mode)().
+*/
+   unsigned current_hash_scale;
+
   /**
* Array length is anv_cmd_state::pass::attachment_count. Array content is
* valid only when recording a render pass instance.
diff --git a/src/intel/vulkan/genX_blorp_exec.c 
b/src/intel/vulkan/genX_blorp_exec.c

index 1592e7f7e3d..e9eedc06696 100644
--- a/src/intel/vulkan/genX_blorp_exec.c
+++ b/src/intel/vulkan/genX_blorp_exec.c
@@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
  genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
   }

+   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
+   if (cmd_buffer->state.current_hash_scale != scale) {
+  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 - params->x0,
+ params->y1 - params->y0, scale);
+   }
+
#if GEN_GEN >= 11
   /* The PIPE_CONTROL command description says:
*
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c

index 86ef1663ac4..e9e5570d49f 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
*/
   primary->state.current_pipeline = UINT32_MAX;
   primary->state.current_l3_config = NULL;
+   primary->state.current_hash_scale = 0;

   /* Each of the secondary command buffers will use its own state base
* address.  We need to re-emit state base address for the primary after
@@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer 
*cmd_buffer)


   genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);

+   if (cmd_buffer->state.current_hash_scale != 1)
+  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX, UINT_MAX, 1);
+
   genX(flush_pipeline_select_3d)(cmd_buffer);

   if (vb_emit) {
@@ -3925,6 +3929,98 @@ genX(cmd_buffer_emit_gen7_depth_flush)(struct 
anv_cmd_buffer *cmd_buffer)

   }
}

+/**
+ * Update the pixel hashing modes that determine the balancing of PS threads
+ * across subslices and slices.
+ *
+ * \param width Width bound of the rendering area (already scaled down if \p
+ *  scale is greater than 1).
+ * \param height Height bound of the rendering area (already scaled down if \p
+ *   scale is greater than 1).
+ * \param scale The number of framebuffer samples that could potentially be
+ *  affected by an individual channel of the PS thread.  This is
+ *  typically one for single-sampled rendering, but for operations
+ *  like CCS resolves and fast clears a single PS invocation may
+ *  update a huge number of pixels, in which case a finer
+ *  balancing is desirable in order to maximally utilize the
+ *  bandwidth available.  UINT_MAX can be used as shorthand for
+ *  "finest hashing mode available".
+ */
+void
+genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer *cmd_buffer,
+   unsigned width, unsigned height,
+   unsigned scale)
+{
+#if GEN_GEN == 9
+   const struct gen_device_i

[Mesa-dev] [Bug 111248] Navi10 Font rendering issue in Overwatch

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111248

--- Comment #6 from Bas Nieuwenhuizen  ---
Seems like a Geometry Shader issue with NGG (primitive shaders). You can
specify RADV_DEBUG=nongg as a workaround for now.

-- 
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 111370] Cannot get OpenCL visible with Radeon VII installation

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111370

Bug ID: 111370
   Summary: Cannot get OpenCL visible with Radeon VII installation
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: charlesshe...@my.unt.edu
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 145019
  --> https://bugs.freedesktop.org/attachment.cgi?id=145019&action=edit
requested reports from Radeon VII installation instructions

I am a post doctoral researcher at University of North Texas.  We recently
purchased a Dell 7425 system with Dual AMD EPYC 7281 16-Core Processors, an AMD
Radeon VII graphics card from Sapphire Technology and a Xilinx Alveo FPGA
accelerator card.  This equipment was purchased to analyze the differences in
various algorithms' performance on CPU, GPU, and FPGA implementations with
OpenCL.  So far, we have been unable to get either the Radeon VII or the Alveo
to display as an OpenCL platform.

Radeon drivers were downloaded from AMD website and the amdgpu-pro-install
script was used for the installation. The install script listed this site to
report problems if we did not have an AMD Customer Engagement Representative. 
Perhaps someone here could help me get one of these representatives?

This may actually be a duplicate of 110035, although I am using 18.04.1 rather
than 18.04.2 and I login remotely and use command line access to the OpenCL
platforms.

I have attached the reports suggested by the installation instructions.

I apologize if this is the wrong location to file this issue; I feel I should
be dealing with AMD customer support staff, but have not been able to find a
contact for support in the install instructions except this forum.  Please
direct me to the correct location if possible.

Is it possible the Xilinx and Radeon OpenCL platforms conflict with each other?

Thank you, Charles

-- 
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 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Jason Ekstrand 
This gets us +2.7% on Aztec Ruins (5 runs on each branch)

On Sat, Aug 10, 2019 at 7:31 AM Jason Ekstrand  wrote:

> Let's hold this for at least a tiny bit. I'll run some benchmarks and may
> want to tweak how in interacts with the rest of the vulkan state
> tracking.
> Thanks for figuring out a heuristic!
>
> --Jason
>
> On August 9, 2019 19:22:48 Francisco Jerez  wrote:
>
> > See "i965/gen9: Optimize slice and subslice load balancing behavior."
> > for the rationale.  Marked optional because no performance evaluation
> > has been done on this commit, it is provided to match the hashing
> > settings of the Iris driver.  Test reports welcome.
> > ---
> > src/intel/vulkan/anv_genX.h|  4 ++
> > src/intel/vulkan/anv_private.h |  6 ++
> > src/intel/vulkan/genX_blorp_exec.c |  6 ++
> > src/intel/vulkan/genX_cmd_buffer.c | 96 ++
> > 4 files changed, 112 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> > index a5435e566a3..06c6b467acf 100644
> > --- a/src/intel/vulkan/anv_genX.h
> > +++ b/src/intel/vulkan/anv_genX.h
> > @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct
> > anv_cmd_buffer *cmd_buffer);
> >
> > void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
> *cmd_buffer);
> >
> > +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer
> *cmd_buffer,
> > +unsigned width, unsigned height,
> > +unsigned scale);
> > +
> > void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
> > void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer
> *cmd_buffer);
> >
> > diff --git a/src/intel/vulkan/anv_private.h
> b/src/intel/vulkan/anv_private.h
> > index 2465f264354..b381386a716 100644
> > --- a/src/intel/vulkan/anv_private.h
> > +++ b/src/intel/vulkan/anv_private.h
> > @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
> >
> >bool
>  conditional_render_enabled;
> >
> > +   /**
> > +* Last rendering scale argument provided to
> > +* genX(cmd_buffer_emit_hashing_mode)().
> > +*/
> > +   unsigned current_hash_scale;
> > +
> >/**
> > * Array length is anv_cmd_state::pass::attachment_count. Array
> content is
> > * valid only when recording a render pass instance.
> > diff --git a/src/intel/vulkan/genX_blorp_exec.c
> > b/src/intel/vulkan/genX_blorp_exec.c
> > index 1592e7f7e3d..e9eedc06696 100644
> > --- a/src/intel/vulkan/genX_blorp_exec.c
> > +++ b/src/intel/vulkan/genX_blorp_exec.c
> > @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
> >   genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
> >}
> >
> > +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
> > +   if (cmd_buffer->state.current_hash_scale != scale) {
> > +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 -
> params->x0,
> > + params->y1 - params->y0,
> scale);
> > +   }
> > +
> > #if GEN_GEN >= 11
> >/* The PIPE_CONTROL command description says:
> > *
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 86ef1663ac4..e9e5570d49f 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
> > */
> >primary->state.current_pipeline = UINT32_MAX;
> >primary->state.current_l3_config = NULL;
> > +   primary->state.current_hash_scale = 0;
> >
> >/* Each of the secondary command buffers will use its own state base
> > * address.  We need to re-emit state base address for the primary
> after
> > @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer
> > *cmd_buffer)
> >
> >genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
> >
> > +   if (cmd_buffer->state.current_hash_scale != 1)
> > +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX,
> UINT_MAX, 1);
> > +
> >genX(flush_pipeline_select_3d)(cmd_buffer);
> >
> >if (vb_emit) {
> > @@ -3925,6 +3929,98 @@ genX(cmd_buffer_emit_gen7_depth_flush)(struct
> > anv_cmd_buffer *cmd_buffer)
> >}
> > }
> >
> > +/**
> > + * Update the pixel hashing modes that determine the balancing of PS
> threads
> > + * across subslices and slices.
> > + *
> > + * \param width Width bound of the rendering area (already scaled down
> if \p
> > + *  scale is greater than 1).
> > + * \param height Height bound of the rendering area (already scaled
> down if \p
> > + *   scale is greater than 1).
> > + * \param scale The number of framebuffer samples that could
> potentially be
> > + *  affected by an individual channel of the PS thread.
> This is
> > + *  typically one for single-sampled rendering, but for
> operations
> > + *  like CCS resolves and fast clears a single PS
> invocation may
> > + *

Re: [Mesa-dev] [PATCH 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Jason Ekstrand 
On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez 
wrote:

> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> for the rationale.  Marked optional because no performance evaluation
> has been done on this commit, it is provided to match the hashing
> settings of the Iris driver.  Test reports welcome.
>

Improves Aztec Ruins by 2.7% (tested 5 times in each configuration).  I
also tested Batman: Arkham City but it only reports integer FPS numbers and
no change was noticable.


> ---
>  src/intel/vulkan/anv_genX.h|  4 ++
>  src/intel/vulkan/anv_private.h |  6 ++
>  src/intel/vulkan/genX_blorp_exec.c |  6 ++
>  src/intel/vulkan/genX_cmd_buffer.c | 96 ++
>  4 files changed, 112 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> index a5435e566a3..06c6b467acf 100644
> --- a/src/intel/vulkan/anv_genX.h
> +++ b/src/intel/vulkan/anv_genX.h
> @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct
> anv_cmd_buffer *cmd_buffer);
>
>  void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
> *cmd_buffer);
>
> +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer *cmd_buffer,
> +unsigned width, unsigned height,
> +unsigned scale);
> +
>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);
>
> diff --git a/src/intel/vulkan/anv_private.h
> b/src/intel/vulkan/anv_private.h
> index 2465f264354..b381386a716 100644
> --- a/src/intel/vulkan/anv_private.h
> +++ b/src/intel/vulkan/anv_private.h
> @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
>
> bool
>  conditional_render_enabled;
>
> +   /**
> +* Last rendering scale argument provided to
> +* genX(cmd_buffer_emit_hashing_mode)().
> +*/
> +   unsigned current_hash_scale;
> +
> /**
>  * Array length is anv_cmd_state::pass::attachment_count. Array
> content is
>  * valid only when recording a render pass instance.
> diff --git a/src/intel/vulkan/genX_blorp_exec.c
> b/src/intel/vulkan/genX_blorp_exec.c
> index 1592e7f7e3d..e9eedc06696 100644
> --- a/src/intel/vulkan/genX_blorp_exec.c
> +++ b/src/intel/vulkan/genX_blorp_exec.c
> @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
>genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
> }
>
> +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
> +   if (cmd_buffer->state.current_hash_scale != scale) {
> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 -
> params->x0,
> + params->y1 - params->y0, scale);
> +   }
> +
>  #if GEN_GEN >= 11
> /* The PIPE_CONTROL command description says:
>  *
> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> b/src/intel/vulkan/genX_cmd_buffer.c
> index 86ef1663ac4..e9e5570d49f 100644
> --- a/src/intel/vulkan/genX_cmd_buffer.c
> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
>  */
> primary->state.current_pipeline = UINT32_MAX;
> primary->state.current_l3_config = NULL;
> +   primary->state.current_hash_scale = 0;
>
> /* Each of the secondary command buffers will use its own state base
>  * address.  We need to re-emit state base address for the primary
> after
> @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer
> *cmd_buffer)
>
> genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
>
> +   if (cmd_buffer->state.current_hash_scale != 1)
> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX, UINT_MAX,
> 1);
>

Can we do the check against current_hash_scale as an early return inside
the emit function since that's already where the "current" value is
updated?  Maybe call it cmd_buffer_config_hashing_mode if "emit" no longer
seems right with that change?  I don't really care about the rename.


> +
> genX(flush_pipeline_select_3d)(cmd_buffer);
>
> if (vb_emit) {
> @@ -3925,6 +3929,98 @@ genX(cmd_buffer_emit_gen7_depth_flush)(struct
> anv_cmd_buffer *cmd_buffer)
> }
>  }
>
> +/**
> + * Update the pixel hashing modes that determine the balancing of PS
> threads
> + * across subslices and slices.
> + *
> + * \param width Width bound of the rendering area (already scaled down if
> \p
> + *  scale is greater than 1).
> + * \param height Height bound of the rendering area (already scaled down
> if \p
> + *   scale is greater than 1).
> + * \param scale The number of framebuffer samples that could potentially
> be
> + *  affected by an individual channel of the PS thread.  This
> is
> + *  typically one for single-sampled rendering, but for
> operations
> + *  like CCS resolves and fast clears a single PS invocation
> may
> + *  update a huge number of pixels, in

[Mesa-dev] [Bug 111370] Cannot get OpenCL visible with Radeon VII installation

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111370

--- Comment #1 from Michael Eagle  ---
I am not sure if their amdgpu-pro supports Radeon VII. Have you also tried
ROCm? Their effort is mostly focused around ROCm these days.
You could try it. If you encounter errors, this is their issue page:
https://github.com/RadeonOpenCompute/ROCm/issues

You could also pinpoint if there an issue of incompatibility between the
hardware by blacklisting the modules.

---
Sent from mobile, apologies for typos.

On Sat, 10 Aug 2019, 16:31 ,  wrote:

> Bug ID 111370 
> Summary Cannot get OpenCL visible with Radeon VII installation
> Product Mesa
> Version unspecified
> Hardware x86-64 (AMD64)
> OS Linux (All)
> Status NEW
> Severity normal
> Priority medium
> Component Drivers/Vulkan/radeon
> Assignee mesa-dev@lists.freedesktop.org
> Reporter charlesshe...@my.unt.edu
> QA Contact mesa-dev@lists.freedesktop.org
>
> Created attachment 145019 
>  [details] 
> 
> requested reports from Radeon VII installation instructions
>
> I am a post doctoral researcher at University of North Texas.  We recently
> purchased a Dell 7425 system with Dual AMD EPYC 7281 16-Core Processors, an 
> AMD
> Radeon VII graphics card from Sapphire Technology and a Xilinx Alveo FPGA
> accelerator card.  This equipment was purchased to analyze the differences in
> various algorithms' performance on CPU, GPU, and FPGA implementations with
> OpenCL.  So far, we have been unable to get either the Radeon VII or the Alveo
> to display as an OpenCL platform.
>
> Radeon drivers were downloaded from AMD website and the amdgpu-pro-install
> script was used for the installation. The install script listed this site to
> report problems if we did not have an AMD Customer Engagement Representative.
> Perhaps someone here could help me get one of these representatives?
>
> This may actually be a duplicate of 110035, although I am using 18.04.1 rather
> than 18.04.2 and I login remotely and use command line access to the OpenCL
> platforms.
>
> I have attached the reports suggested by the installation instructions.
>
> I apologize if this is the wrong location to file this issue; I feel I should
> be dealing with AMD customer support staff, but have not been able to find a
> contact for support in the install instructions except this forum.  Please
> direct me to the correct location if possible.
>
> Is it possible the Xilinx and Radeon OpenCL platforms conflict with each 
> other?
>
> Thank you, Charles
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>- You are the QA Contact for the bug.
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
You are receiving this mail because:
You are the 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] st/mesa: don't allocate mipmapped texture for NEAREST_MIPMAP_LINEAR

2019-08-10 Thread Marek Olšák 
Ping

On Fri., Aug. 2, 2019, 19:13 Marek Olšák,  wrote:

> From: Marek Olšák 
>
> ---
>  src/mesa/state_tracker/st_cb_texture.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index 0edb3ea5c7e..1ace61863ff 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -516,20 +516,32 @@ allocate_full_mipmap(const struct st_texture_object
> *stObj,
>return FALSE;
>
> if (stObj->base.BaseLevel == 0 && stObj->base.MaxLevel == 0)
>return FALSE;
>
> if (stObj->base.Sampler.MinFilter == GL_NEAREST ||
> stObj->base.Sampler.MinFilter == GL_LINEAR)
>/* not a mipmap minification filter */
>return FALSE;
>
> +   /* If the following sequence of GL calls is used:
> +*   glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, w, h, 0, GL_RGB, ...
> +*   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
> +*
> +* we would needlessly allocate a mipmapped texture, because the
> initial
> +* MinFilter is GL_NEAREST_MIPMAP_LINEAR. Catch this case and don't
> +* allocate a mipmapped texture by default. This may cause texture
> +* reallocation later, but GL_NEAREST_MIPMAP_LINEAR is pretty rare.
> +*/
> +   if (stObj->base.Sampler.MinFilter == GL_NEAREST_MIPMAP_LINEAR)
> +  return FALSE;
> +
> if (stObj->base.Target == GL_TEXTURE_3D)
>/* 3D textures are seldom mipmapped */
>return FALSE;
>
> return TRUE;
>  }
>
>
>  /**
>   * Try to allocate a pipe_resource object for the given st_texture_object.
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111370] Cannot get OpenCL visible with Radeon VII installation

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111370

Bas Nieuwenhuizen  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
   |org |.org
  Component|Drivers/Vulkan/radeon   |DRM/AMDgpu-pro
Product|Mesa|DRI
 QA Contact|mesa-dev@lists.freedesktop. |
   |org |

--- Comment #2 from Bas Nieuwenhuizen  ---
AFAIU right site, but definitely wrong 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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=110662

--- Comment #18 from tempel.jul...@gmail.com ---
Someone here reports of the issue in Origins, but only with ACO:
https://github.com/daniel-schuermann/mesa/issues/105
Perhaps I was a bit too quick judging it was the same issue on Odyssey as in
Unity, will recheck.

-- 
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 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Francisco Jerez 
Jason Ekstrand  writes:

> On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez 
> wrote:
>
>> See "i965/gen9: Optimize slice and subslice load balancing behavior."
>> for the rationale.  Marked optional because no performance evaluation
>> has been done on this commit, it is provided to match the hashing
>> settings of the Iris driver.  Test reports welcome.
>>
>
> Improves Aztec Ruins by 2.7% (tested 5 times in each configuration).  I
> also tested Batman: Arkham City but it only reports integer FPS numbers and
> no change was noticable.
>
>
>> ---
>>  src/intel/vulkan/anv_genX.h|  4 ++
>>  src/intel/vulkan/anv_private.h |  6 ++
>>  src/intel/vulkan/genX_blorp_exec.c |  6 ++
>>  src/intel/vulkan/genX_cmd_buffer.c | 96 ++
>>  4 files changed, 112 insertions(+)
>>
>> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
>> index a5435e566a3..06c6b467acf 100644
>> --- a/src/intel/vulkan/anv_genX.h
>> +++ b/src/intel/vulkan/anv_genX.h
>> @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct
>> anv_cmd_buffer *cmd_buffer);
>>
>>  void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
>> *cmd_buffer);
>>
>> +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer *cmd_buffer,
>> +unsigned width, unsigned height,
>> +unsigned scale);
>> +
>>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
>>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer *cmd_buffer);
>>
>> diff --git a/src/intel/vulkan/anv_private.h
>> b/src/intel/vulkan/anv_private.h
>> index 2465f264354..b381386a716 100644
>> --- a/src/intel/vulkan/anv_private.h
>> +++ b/src/intel/vulkan/anv_private.h
>> @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
>>
>> bool
>>  conditional_render_enabled;
>>
>> +   /**
>> +* Last rendering scale argument provided to
>> +* genX(cmd_buffer_emit_hashing_mode)().
>> +*/
>> +   unsigned current_hash_scale;
>> +
>> /**
>>  * Array length is anv_cmd_state::pass::attachment_count. Array
>> content is
>>  * valid only when recording a render pass instance.
>> diff --git a/src/intel/vulkan/genX_blorp_exec.c
>> b/src/intel/vulkan/genX_blorp_exec.c
>> index 1592e7f7e3d..e9eedc06696 100644
>> --- a/src/intel/vulkan/genX_blorp_exec.c
>> +++ b/src/intel/vulkan/genX_blorp_exec.c
>> @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
>>genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
>> }
>>
>> +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
>> +   if (cmd_buffer->state.current_hash_scale != scale) {
>> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 -
>> params->x0,
>> + params->y1 - params->y0, scale);
>> +   }
>> +
>>  #if GEN_GEN >= 11
>> /* The PIPE_CONTROL command description says:
>>  *
>> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
>> b/src/intel/vulkan/genX_cmd_buffer.c
>> index 86ef1663ac4..e9e5570d49f 100644
>> --- a/src/intel/vulkan/genX_cmd_buffer.c
>> +++ b/src/intel/vulkan/genX_cmd_buffer.c
>> @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
>>  */
>> primary->state.current_pipeline = UINT32_MAX;
>> primary->state.current_l3_config = NULL;
>> +   primary->state.current_hash_scale = 0;
>>
>> /* Each of the secondary command buffers will use its own state base
>>  * address.  We need to re-emit state base address for the primary
>> after
>> @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer
>> *cmd_buffer)
>>
>> genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
>>
>> +   if (cmd_buffer->state.current_hash_scale != 1)
>> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX, UINT_MAX,
>> 1);
>>
>
> Can we do the check against current_hash_scale as an early return inside
> the emit function since that's already where the "current" value is
> updated?  Maybe call it cmd_buffer_config_hashing_mode if "emit" no longer
> seems right with that change?  I don't really care about the rename.
>

That's what my first revision did.  I moved the current_hash_scale check
one level up because the function call overhead was visible in
brw_upload_pipeline_state(), which is quite a hot path in i965.  That
said I don't have any data justifying the change in the Vulkan driver --
Because caller and callee are defined in the same compilation unit it
*might* be that the function is inlined into
genX(cmd_buffer_flush_state), though it's large enough that it may not
be, either way it seemed like a good idea to do things consistently
across drivers.

>
>> +
>> genX(flush_pipeline_select_3d)(cmd_buffer);
>>
>> if (vb_emit) {
>> @@ -3925,6 +3929,98 @@ genX(cmd_buffer_emit_gen7_depth_flush)(struct
>> anv_cmd_buffer *cmd_buffer)
>> }
>>  }
>>
>> +/**
>> + * Update the pixel hashing modes that determine the bala

Re: [Mesa-dev] [PATCH 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Jason Ekstrand 
On Sat, Aug 10, 2019 at 2:22 PM Francisco Jerez 
wrote:

> Jason Ekstrand  writes:
>
> > On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez 
> > wrote:
> >
> >> See "i965/gen9: Optimize slice and subslice load balancing behavior."
> >> for the rationale.  Marked optional because no performance evaluation
> >> has been done on this commit, it is provided to match the hashing
> >> settings of the Iris driver.  Test reports welcome.
> >>
> >
> > Improves Aztec Ruins by 2.7% (tested 5 times in each configuration).  I
> > also tested Batman: Arkham City but it only reports integer FPS numbers
> and
> > no change was noticable.
> >
> >
> >> ---
> >>  src/intel/vulkan/anv_genX.h|  4 ++
> >>  src/intel/vulkan/anv_private.h |  6 ++
> >>  src/intel/vulkan/genX_blorp_exec.c |  6 ++
> >>  src/intel/vulkan/genX_cmd_buffer.c | 96 ++
> >>  4 files changed, 112 insertions(+)
> >>
> >> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
> >> index a5435e566a3..06c6b467acf 100644
> >> --- a/src/intel/vulkan/anv_genX.h
> >> +++ b/src/intel/vulkan/anv_genX.h
> >> @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct
> >> anv_cmd_buffer *cmd_buffer);
> >>
> >>  void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
> >> *cmd_buffer);
> >>
> >> +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer
> *cmd_buffer,
> >> +unsigned width, unsigned
> height,
> >> +unsigned scale);
> >> +
> >>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
> >>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer
> *cmd_buffer);
> >>
> >> diff --git a/src/intel/vulkan/anv_private.h
> >> b/src/intel/vulkan/anv_private.h
> >> index 2465f264354..b381386a716 100644
> >> --- a/src/intel/vulkan/anv_private.h
> >> +++ b/src/intel/vulkan/anv_private.h
> >> @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
> >>
> >> bool
> >>  conditional_render_enabled;
> >>
> >> +   /**
> >> +* Last rendering scale argument provided to
> >> +* genX(cmd_buffer_emit_hashing_mode)().
> >> +*/
> >> +   unsigned current_hash_scale;
> >> +
> >> /**
> >>  * Array length is anv_cmd_state::pass::attachment_count. Array
> >> content is
> >>  * valid only when recording a render pass instance.
> >> diff --git a/src/intel/vulkan/genX_blorp_exec.c
> >> b/src/intel/vulkan/genX_blorp_exec.c
> >> index 1592e7f7e3d..e9eedc06696 100644
> >> --- a/src/intel/vulkan/genX_blorp_exec.c
> >> +++ b/src/intel/vulkan/genX_blorp_exec.c
> >> @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
> >>genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
> >> }
> >>
> >> +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
> >> +   if (cmd_buffer->state.current_hash_scale != scale) {
> >> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 -
> >> params->x0,
> >> + params->y1 - params->y0,
> scale);
> >> +   }
> >> +
> >>  #if GEN_GEN >= 11
> >> /* The PIPE_CONTROL command description says:
> >>  *
> >> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
> >> b/src/intel/vulkan/genX_cmd_buffer.c
> >> index 86ef1663ac4..e9e5570d49f 100644
> >> --- a/src/intel/vulkan/genX_cmd_buffer.c
> >> +++ b/src/intel/vulkan/genX_cmd_buffer.c
> >> @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
> >>  */
> >> primary->state.current_pipeline = UINT32_MAX;
> >> primary->state.current_l3_config = NULL;
> >> +   primary->state.current_hash_scale = 0;
> >>
> >> /* Each of the secondary command buffers will use its own state base
> >>  * address.  We need to re-emit state base address for the primary
> >> after
> >> @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer
> >> *cmd_buffer)
> >>
> >> genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
> >>
> >> +   if (cmd_buffer->state.current_hash_scale != 1)
> >> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX,
> UINT_MAX,
> >> 1);
> >>
> >
> > Can we do the check against current_hash_scale as an early return inside
> > the emit function since that's already where the "current" value is
> > updated?  Maybe call it cmd_buffer_config_hashing_mode if "emit" no
> longer
> > seems right with that change?  I don't really care about the rename.
> >
>
> That's what my first revision did.  I moved the current_hash_scale check
> one level up because the function call overhead was visible in
> brw_upload_pipeline_state(), which is quite a hot path in i965.


That's a bit surprising but believable if the two are in different files
and there's a real function call going on there.


>   That
> said I don't have any data justifying the change in the Vulkan driver --
> Because caller and callee are defined in the same compilation unit it
> *might* be that the function is inlined into
>

Re: [Mesa-dev] [PATCH 4/4] OPTIONAL: anv/gen9: Optimize slice and subslice load balancing behavior.

2019-08-10 Thread Francisco Jerez 
Jason Ekstrand  writes:

> On Sat, Aug 10, 2019 at 2:22 PM Francisco Jerez 
> wrote:
>
>> Jason Ekstrand  writes:
>>
>> > On Fri, Aug 9, 2019 at 7:22 PM Francisco Jerez 
>> > wrote:
>> >
>> >> See "i965/gen9: Optimize slice and subslice load balancing behavior."
>> >> for the rationale.  Marked optional because no performance evaluation
>> >> has been done on this commit, it is provided to match the hashing
>> >> settings of the Iris driver.  Test reports welcome.
>> >>
>> >
>> > Improves Aztec Ruins by 2.7% (tested 5 times in each configuration).  I
>> > also tested Batman: Arkham City but it only reports integer FPS numbers
>> and
>> > no change was noticable.
>> >
>> >
>> >> ---
>> >>  src/intel/vulkan/anv_genX.h|  4 ++
>> >>  src/intel/vulkan/anv_private.h |  6 ++
>> >>  src/intel/vulkan/genX_blorp_exec.c |  6 ++
>> >>  src/intel/vulkan/genX_cmd_buffer.c | 96 ++
>> >>  4 files changed, 112 insertions(+)
>> >>
>> >> diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
>> >> index a5435e566a3..06c6b467acf 100644
>> >> --- a/src/intel/vulkan/anv_genX.h
>> >> +++ b/src/intel/vulkan/anv_genX.h
>> >> @@ -44,6 +44,10 @@ void genX(cmd_buffer_apply_pipe_flushes)(struct
>> >> anv_cmd_buffer *cmd_buffer);
>> >>
>> >>  void genX(cmd_buffer_emit_gen7_depth_flush)(struct anv_cmd_buffer
>> >> *cmd_buffer);
>> >>
>> >> +void genX(cmd_buffer_emit_hashing_mode)(struct anv_cmd_buffer
>> *cmd_buffer,
>> >> +unsigned width, unsigned
>> height,
>> >> +unsigned scale);
>> >> +
>> >>  void genX(flush_pipeline_select_3d)(struct anv_cmd_buffer *cmd_buffer);
>> >>  void genX(flush_pipeline_select_gpgpu)(struct anv_cmd_buffer
>> *cmd_buffer);
>> >>
>> >> diff --git a/src/intel/vulkan/anv_private.h
>> >> b/src/intel/vulkan/anv_private.h
>> >> index 2465f264354..b381386a716 100644
>> >> --- a/src/intel/vulkan/anv_private.h
>> >> +++ b/src/intel/vulkan/anv_private.h
>> >> @@ -2421,6 +2421,12 @@ struct anv_cmd_state {
>> >>
>> >> bool
>> >>  conditional_render_enabled;
>> >>
>> >> +   /**
>> >> +* Last rendering scale argument provided to
>> >> +* genX(cmd_buffer_emit_hashing_mode)().
>> >> +*/
>> >> +   unsigned current_hash_scale;
>> >> +
>> >> /**
>> >>  * Array length is anv_cmd_state::pass::attachment_count. Array
>> >> content is
>> >>  * valid only when recording a render pass instance.
>> >> diff --git a/src/intel/vulkan/genX_blorp_exec.c
>> >> b/src/intel/vulkan/genX_blorp_exec.c
>> >> index 1592e7f7e3d..e9eedc06696 100644
>> >> --- a/src/intel/vulkan/genX_blorp_exec.c
>> >> +++ b/src/intel/vulkan/genX_blorp_exec.c
>> >> @@ -223,6 +223,12 @@ genX(blorp_exec)(struct blorp_batch *batch,
>> >>genX(cmd_buffer_config_l3)(cmd_buffer, cfg);
>> >> }
>> >>
>> >> +   const unsigned scale = params->fast_clear_op ? UINT_MAX : 1;
>> >> +   if (cmd_buffer->state.current_hash_scale != scale) {
>> >> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, params->x1 -
>> >> params->x0,
>> >> + params->y1 - params->y0,
>> scale);
>> >> +   }
>> >> +
>> >>  #if GEN_GEN >= 11
>> >> /* The PIPE_CONTROL command description says:
>> >>  *
>> >> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
>> >> b/src/intel/vulkan/genX_cmd_buffer.c
>> >> index 86ef1663ac4..e9e5570d49f 100644
>> >> --- a/src/intel/vulkan/genX_cmd_buffer.c
>> >> +++ b/src/intel/vulkan/genX_cmd_buffer.c
>> >> @@ -1595,6 +1595,7 @@ genX(CmdExecuteCommands)(
>> >>  */
>> >> primary->state.current_pipeline = UINT32_MAX;
>> >> primary->state.current_l3_config = NULL;
>> >> +   primary->state.current_hash_scale = 0;
>> >>
>> >> /* Each of the secondary command buffers will use its own state base
>> >>  * address.  We need to re-emit state base address for the primary
>> >> after
>> >> @@ -2663,6 +2664,9 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer
>> >> *cmd_buffer)
>> >>
>> >> genX(cmd_buffer_config_l3)(cmd_buffer, pipeline->urb.l3_config);
>> >>
>> >> +   if (cmd_buffer->state.current_hash_scale != 1)
>> >> +  genX(cmd_buffer_emit_hashing_mode)(cmd_buffer, UINT_MAX,
>> UINT_MAX,
>> >> 1);
>> >>
>> >
>> > Can we do the check against current_hash_scale as an early return inside
>> > the emit function since that's already where the "current" value is
>> > updated?  Maybe call it cmd_buffer_config_hashing_mode if "emit" no
>> longer
>> > seems right with that change?  I don't really care about the rename.
>> >
>>
>> That's what my first revision did.  I moved the current_hash_scale check
>> one level up because the function call overhead was visible in
>> brw_upload_pipeline_state(), which is quite a hot path in i965.
>
>
> That's a bit surprising but believable if the two are in different files
> and there's a real function call going on there.
>
>
>>   That
>> said I don't have any data justify

[Mesa-dev] [Bug 111265] [TRACKER] Mesa 19.2 feature tracker

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111265
Bug 111265 depends on bug 111274, which changed state.

Bug 111274 Summary: Feature: support gpu metrics in iris
https://bugs.freedesktop.org/show_bug.cgi?id=111274

   What|Removed |Added

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

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

[Mesa-dev] [Bug 111248] Navi10 Font rendering issue in Overwatch

2019-08-10 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=111248

--- Comment #7 from Matt  ---
confirming that RADV_DEBUG=nongg workaround fixes the font rendering

-- 
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