Re: [Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

2019-06-24 Thread Dieter Nützel

t-b

Dieter

Am 25.06.2019 02:12, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_drawpixels.c | 58 +++
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 59868d3ff1d..26d3cc33e5c 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1508,35 +1508,35 @@ static GLboolean
 blit_copy_pixels(struct gl_context *ctx, GLint srcx, GLint srcy,
  GLsizei width, GLsizei height,
  GLint dstx, GLint dsty, GLenum type)
 {
struct st_context *st = st_context(ctx);
struct pipe_context *pipe = st->pipe;
struct pipe_screen *screen = pipe->screen;
struct gl_pixelstore_attrib pack, unpack;
GLint readX, readY, readW, readH, drawX, drawY, drawW, drawH;

-   if (type == GL_COLOR &&
-   ctx->Pixel.ZoomX == 1.0 &&
+   if (ctx->Pixel.ZoomX == 1.0 &&
ctx->Pixel.ZoomY == 1.0 &&
-   ctx->_ImageTransferState == 0x0 &&
-   !ctx->Color.BlendEnabled &&
-   !ctx->Color.AlphaEnabled &&
-   (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == 
GL_COPY) &&

-   !ctx->Depth.Test &&
-   !ctx->Fog.Enabled &&
-   !ctx->Stencil.Enabled &&
-   !ctx->FragmentProgram.Enabled &&
-   !ctx->VertexProgram.Enabled &&
-   !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
-   !_mesa_ati_fragment_shader_enabled(ctx) &&
-   ctx->DrawBuffer->_NumColorDrawBuffers == 1 &&
+   (type != GL_COLOR ||
+(ctx->_ImageTransferState == 0x0 &&
+ !ctx->Color.BlendEnabled &&
+ !ctx->Color.AlphaEnabled &&
+ (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == 
GL_COPY) &&

+ !ctx->Depth.Test &&
+ !ctx->Fog.Enabled &&
+ !ctx->Stencil.Enabled &&
+ !ctx->FragmentProgram.Enabled &&
+ !ctx->VertexProgram.Enabled &&
+ !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
+ !_mesa_ati_fragment_shader_enabled(ctx) &&
+ ctx->DrawBuffer->_NumColorDrawBuffers == 1)) &&
!ctx->Query.CondRenderQuery &&
!ctx->Query.CurrentOcclusionObject) {
   struct st_renderbuffer *rbRead, *rbDraw;

   /*
* Clip the read region against the src buffer bounds.
* We'll still allocate a temporary buffer/texture for the 
original
* src region size but we'll only read the region which is 
on-screen.
* This may mean that we draw garbage pixels into the dest 
region, but

* that's expected.
@@ -1555,22 +1555,32 @@ blit_copy_pixels(struct gl_context *ctx, GLint
srcx, GLint srcy,
   unpack = pack;
   if (!_mesa_clip_drawpixels(ctx, , , , , 
))

  return GL_TRUE; /* all done */

   readX = readX - pack.SkipPixels + unpack.SkipPixels;
   readY = readY - pack.SkipRows + unpack.SkipRows;

   drawW = readW;
   drawH = readH;

-  rbRead = st_get_color_read_renderbuffer(ctx);
-  rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
+  if (type == GL_COLOR) {
+ rbRead = st_get_color_read_renderbuffer(ctx);
+ rbDraw = 
st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);

+  } else if (type == GL_DEPTH || type == GL_DEPTH_STENCIL) {
+ rbRead =
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+ rbDraw =
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+  } else if (type == GL_STENCIL) {
+ rbRead =
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+ rbDraw =
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+  } else {
+ return false;
+  }

   /* Flip src/dst position depending on the orientation of 
buffers. */

   if (st_fb_orientation(ctx->ReadBuffer) == Y_0_TOP) {
  readY = rbRead->Base.Height - readY;
  readH = -readH;
   }

   if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
  /* We can't flip the destination for pipe->blit, so we only 
adjust

   * its position and flip the source.
@@ -1597,23 +1607,31 @@ blit_copy_pixels(struct gl_context *ctx, GLint
srcx, GLint srcy,
  blit.src.box.depth = 1;
  blit.dst.resource = rbDraw->texture;
  blit.dst.level = rbDraw->surface->u.tex.level;
  blit.dst.format = rbDraw->texture->format;
  blit.dst.box.x = drawX;
  blit.dst.box.y = drawY;
  blit.dst.box.z = rbDraw->surface->u.tex.first_layer;
  blit.dst.box.width = drawW;
  blit.dst.box.height = drawH;
  blit.dst.box.depth = 1;
- blit.mask = PIPE_MASK_RGBA;
  blit.filter = PIPE_TEX_FILTER_NEAREST;

+ if (type == GL_COLOR)
+blit.mask |= PIPE_MASK_RGBA;
+ if (type == GL_DEPTH)
+blit.mask |= PIPE_MASK_Z;
+ if (type == 

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Elie Tournier
On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote:
> Elie Tournier  writes:
> 
> > Hi there,
> >
> > Great topic. For the past few days, I was looking at a CI for Mesa:
> > https://gitlab.freedesktop.org/hopetech/tracie
> > OK, it's in a very very alpha stage. ;)
> 
> I did one of those things using apitrace diff-images in piglit:
> 
> https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace
> 
> https://github.com/anholt/trace-db
> 
> It was bad.  diff-images is too picky and you end up needing to bless
> new images constantly.  I have decided to not pursue this line of
> testing any further because it was so unproductive.
For now, my plan is to run the CI only once a week.
So efficiency is not my top priority right now. But it will at some point.

I'm trying to figure out which tools is the best for this job:
Correctness *and* perf testing.

> 
> What I *am* interested in trying with traces for correctness testing is
> using a single driver to replay trace keyframes multiple times and make
> sure the image is invariant.  This could catch a large class of UB in
> real world applications without needing continuous human intervention.
So what's happening if an object is not render in all frame?
> 
> > @eric Out of curiosity, did you looked at apitrace or did you go
> > straight with renderdoc?
> 
> Since I was only looking at perf, I didn't use apitrace (I'd tried to
> use it for perf in the past and it was absolutely dominated by trace
> loading).  frameretrace would have made apitrace interesting to use for
> this, but José blocked merging that.  That makes apitrace pretty dead
> from my perspective.
> 
> Also, renderdoc's android capture is really nice to use.
Thanks for your input.


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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 98996, which changed state.

Bug 98996 Summary: Counter Strike: Global Offensive performance on Radeon 
Polaris
https://bugs.freedesktop.org/show_bug.cgi?id=98996

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

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

Re: [Mesa-dev] [PATCH 5/8] radeonsi: don't set spi_ps_input_* for monolithic shaders

2019-06-24 Thread Bas Nieuwenhuizen
sorry, totally missed that it was set in src/amd/common as well.

r-b for this patch too.

On Tue, Jun 25, 2019 at 2:17 AM Marek Olšák  wrote:
>
> If the shader is monolithic, the value of SPI_PS_INPUT_ENA that is generated 
> by LLVM is used as-is.
>
> Marek
>
> On Fri, Jun 21, 2019 at 7:03 PM Bas Nieuwenhuizen  
> wrote:
>>
>> Doesn't this cause assertions in si_shader_ps() for monolithic
>> shaders? Some of these assertions check that at least one bit in a
>> group is set and I think we end up with input_ena = 0 for monolithic
>> shaders now?
>>
>> On Thu, Jun 20, 2019 at 6:20 AM Marek Olšák  wrote:
>> >
>> > From: Marek Olšák 
>> >
>> > The driver doesn't use these values and ac_rtld has assertions
>> > expecting the value of 0.
>> > ---
>> >  src/gallium/drivers/radeonsi/si_shader.c | 39 
>> >  1 file changed, 26 insertions(+), 13 deletions(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
>> > b/src/gallium/drivers/radeonsi/si_shader.c
>> > index 54b29d0ae01..0489399b827 100644
>> > --- a/src/gallium/drivers/radeonsi/si_shader.c
>> > +++ b/src/gallium/drivers/radeonsi/si_shader.c
>> > @@ -6128,21 +6128,22 @@ static void si_get_ps_prolog_key(struct si_shader 
>> > *shader,
>> >  key->ps_prolog.states.bc_optimize_for_linear);
>> > key->ps_prolog.ancillary_vgpr_index = 
>> > shader->info.ancillary_vgpr_index;
>> >
>> > if (info->colors_read) {
>> > unsigned *color = shader->selector->color_attr_index;
>> >
>> > if (shader->key.part.ps.prolog.color_two_side) {
>> > /* BCOLORs are stored after the last input. */
>> > key->ps_prolog.num_interp_inputs = 
>> > info->num_inputs;
>> > key->ps_prolog.face_vgpr_index = 
>> > shader->info.face_vgpr_index;
>> > -   shader->config.spi_ps_input_ena |= 
>> > S_0286CC_FRONT_FACE_ENA(1);
>> > +   if (separate_prolog)
>> > +   shader->config.spi_ps_input_ena |= 
>> > S_0286CC_FRONT_FACE_ENA(1);
>> > }
>> >
>> > for (unsigned i = 0; i < 2; i++) {
>> > unsigned interp = 
>> > info->input_interpolate[color[i]];
>> > unsigned location = 
>> > info->input_interpolate_loc[color[i]];
>> >
>> > if (!(info->colors_read & (0xf << i*4)))
>> > continue;
>> >
>> > key->ps_prolog.color_attr_index[i] = color[i];
>> > @@ -6159,66 +6160,78 @@ static void si_get_ps_prolog_key(struct si_shader 
>> > *shader,
>> > case TGSI_INTERPOLATE_COLOR:
>> > /* Force the interpolation location for 
>> > colors here. */
>> > if 
>> > (shader->key.part.ps.prolog.force_persp_sample_interp)
>> > location = 
>> > TGSI_INTERPOLATE_LOC_SAMPLE;
>> > if 
>> > (shader->key.part.ps.prolog.force_persp_center_interp)
>> > location = 
>> > TGSI_INTERPOLATE_LOC_CENTER;
>> >
>> > switch (location) {
>> > case TGSI_INTERPOLATE_LOC_SAMPLE:
>> > 
>> > key->ps_prolog.color_interp_vgpr_index[i] = 0;
>> > -   shader->config.spi_ps_input_ena |=
>> > -   
>> > S_0286CC_PERSP_SAMPLE_ENA(1);
>> > +   if (separate_prolog) {
>> > +   
>> > shader->config.spi_ps_input_ena |=
>> > +   
>> > S_0286CC_PERSP_SAMPLE_ENA(1);
>> > +   }
>> > break;
>> > case TGSI_INTERPOLATE_LOC_CENTER:
>> > 
>> > key->ps_prolog.color_interp_vgpr_index[i] = 2;
>> > -   shader->config.spi_ps_input_ena |=
>> > -   
>> > S_0286CC_PERSP_CENTER_ENA(1);
>> > +   if (separate_prolog) {
>> > +   
>> > shader->config.spi_ps_input_ena |=
>> > +   
>> > S_0286CC_PERSP_CENTER_ENA(1);
>> > +   }
>> > break;
>> > case TGSI_INTERPOLATE_LOC_CENTROID:
>> > 
>> > key->ps_prolog.color_interp_vgpr_index[i] = 4;
>> > -   shader->config.spi_ps_input_ena |=
>> > -   
>> > 

Re: [Mesa-dev] [PATCH 5/8] radeonsi: don't set spi_ps_input_* for monolithic shaders

2019-06-24 Thread Marek Olšák
If the shader is monolithic, the value of SPI_PS_INPUT_ENA that is
generated by LLVM is used as-is.

Marek

On Fri, Jun 21, 2019 at 7:03 PM Bas Nieuwenhuizen 
wrote:

> Doesn't this cause assertions in si_shader_ps() for monolithic
> shaders? Some of these assertions check that at least one bit in a
> group is set and I think we end up with input_ena = 0 for monolithic
> shaders now?
>
> On Thu, Jun 20, 2019 at 6:20 AM Marek Olšák  wrote:
> >
> > From: Marek Olšák 
> >
> > The driver doesn't use these values and ac_rtld has assertions
> > expecting the value of 0.
> > ---
> >  src/gallium/drivers/radeonsi/si_shader.c | 39 
> >  1 file changed, 26 insertions(+), 13 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_shader.c
> b/src/gallium/drivers/radeonsi/si_shader.c
> > index 54b29d0ae01..0489399b827 100644
> > --- a/src/gallium/drivers/radeonsi/si_shader.c
> > +++ b/src/gallium/drivers/radeonsi/si_shader.c
> > @@ -6128,21 +6128,22 @@ static void si_get_ps_prolog_key(struct
> si_shader *shader,
> >  key->ps_prolog.states.bc_optimize_for_linear);
> > key->ps_prolog.ancillary_vgpr_index =
> shader->info.ancillary_vgpr_index;
> >
> > if (info->colors_read) {
> > unsigned *color = shader->selector->color_attr_index;
> >
> > if (shader->key.part.ps.prolog.color_two_side) {
> > /* BCOLORs are stored after the last input. */
> > key->ps_prolog.num_interp_inputs =
> info->num_inputs;
> > key->ps_prolog.face_vgpr_index =
> shader->info.face_vgpr_index;
> > -   shader->config.spi_ps_input_ena |=
> S_0286CC_FRONT_FACE_ENA(1);
> > +   if (separate_prolog)
> > +   shader->config.spi_ps_input_ena |=
> S_0286CC_FRONT_FACE_ENA(1);
> > }
> >
> > for (unsigned i = 0; i < 2; i++) {
> > unsigned interp =
> info->input_interpolate[color[i]];
> > unsigned location =
> info->input_interpolate_loc[color[i]];
> >
> > if (!(info->colors_read & (0xf << i*4)))
> > continue;
> >
> > key->ps_prolog.color_attr_index[i] = color[i];
> > @@ -6159,66 +6160,78 @@ static void si_get_ps_prolog_key(struct
> si_shader *shader,
> > case TGSI_INTERPOLATE_COLOR:
> > /* Force the interpolation location for
> colors here. */
> > if
> (shader->key.part.ps.prolog.force_persp_sample_interp)
> > location =
> TGSI_INTERPOLATE_LOC_SAMPLE;
> > if
> (shader->key.part.ps.prolog.force_persp_center_interp)
> > location =
> TGSI_INTERPOLATE_LOC_CENTER;
> >
> > switch (location) {
> > case TGSI_INTERPOLATE_LOC_SAMPLE:
> >
>  key->ps_prolog.color_interp_vgpr_index[i] = 0;
> > -   shader->config.spi_ps_input_ena
> |=
> > -
>  S_0286CC_PERSP_SAMPLE_ENA(1);
> > +   if (separate_prolog) {
> > +
>  shader->config.spi_ps_input_ena |=
> > +
>  S_0286CC_PERSP_SAMPLE_ENA(1);
> > +   }
> > break;
> > case TGSI_INTERPOLATE_LOC_CENTER:
> >
>  key->ps_prolog.color_interp_vgpr_index[i] = 2;
> > -   shader->config.spi_ps_input_ena
> |=
> > -
>  S_0286CC_PERSP_CENTER_ENA(1);
> > +   if (separate_prolog) {
> > +
>  shader->config.spi_ps_input_ena |=
> > +
>  S_0286CC_PERSP_CENTER_ENA(1);
> > +   }
> > break;
> > case TGSI_INTERPOLATE_LOC_CENTROID:
> >
>  key->ps_prolog.color_interp_vgpr_index[i] = 4;
> > -   shader->config.spi_ps_input_ena
> |=
> > -
>  S_0286CC_PERSP_CENTROID_ENA(1);
> > +   if (separate_prolog) {
> > +
>  shader->config.spi_ps_input_ena |=
> > +
>  S_0286CC_PERSP_CENTROID_ENA(1);
> > +   }
> > break;
> > default:
> > assert(0);
> > }
> > break;
> > case TGSI_INTERPOLATE_LINEAR:
> > /* Force the interpolation location for
> colors here. */
> > if
> (shader->key.part.ps.prolog.force_linear_sample_interp)
> > location =
> TGSI_INTERPOLATE_LOC_SAMPLE;
> 

[Mesa-dev] [PATCH] st/mesa: accelerate glCopyPixels(STENCIL)

2019-06-24 Thread Marek Olšák
From: Marek Olšák 

---
 src/mesa/state_tracker/st_cb_drawpixels.c | 58 +++
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 59868d3ff1d..26d3cc33e5c 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -1508,35 +1508,35 @@ static GLboolean
 blit_copy_pixels(struct gl_context *ctx, GLint srcx, GLint srcy,
  GLsizei width, GLsizei height,
  GLint dstx, GLint dsty, GLenum type)
 {
struct st_context *st = st_context(ctx);
struct pipe_context *pipe = st->pipe;
struct pipe_screen *screen = pipe->screen;
struct gl_pixelstore_attrib pack, unpack;
GLint readX, readY, readW, readH, drawX, drawY, drawW, drawH;
 
-   if (type == GL_COLOR &&
-   ctx->Pixel.ZoomX == 1.0 &&
+   if (ctx->Pixel.ZoomX == 1.0 &&
ctx->Pixel.ZoomY == 1.0 &&
-   ctx->_ImageTransferState == 0x0 &&
-   !ctx->Color.BlendEnabled &&
-   !ctx->Color.AlphaEnabled &&
-   (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == GL_COPY) &&
-   !ctx->Depth.Test &&
-   !ctx->Fog.Enabled &&
-   !ctx->Stencil.Enabled &&
-   !ctx->FragmentProgram.Enabled &&
-   !ctx->VertexProgram.Enabled &&
-   !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
-   !_mesa_ati_fragment_shader_enabled(ctx) &&
-   ctx->DrawBuffer->_NumColorDrawBuffers == 1 &&
+   (type != GL_COLOR ||
+(ctx->_ImageTransferState == 0x0 &&
+ !ctx->Color.BlendEnabled &&
+ !ctx->Color.AlphaEnabled &&
+ (!ctx->Color.ColorLogicOpEnabled || ctx->Color.LogicOp == GL_COPY) &&
+ !ctx->Depth.Test &&
+ !ctx->Fog.Enabled &&
+ !ctx->Stencil.Enabled &&
+ !ctx->FragmentProgram.Enabled &&
+ !ctx->VertexProgram.Enabled &&
+ !ctx->_Shader->CurrentProgram[MESA_SHADER_FRAGMENT] &&
+ !_mesa_ati_fragment_shader_enabled(ctx) &&
+ ctx->DrawBuffer->_NumColorDrawBuffers == 1)) &&
!ctx->Query.CondRenderQuery &&
!ctx->Query.CurrentOcclusionObject) {
   struct st_renderbuffer *rbRead, *rbDraw;
 
   /*
* Clip the read region against the src buffer bounds.
* We'll still allocate a temporary buffer/texture for the original
* src region size but we'll only read the region which is on-screen.
* This may mean that we draw garbage pixels into the dest region, but
* that's expected.
@@ -1555,22 +1555,32 @@ blit_copy_pixels(struct gl_context *ctx, GLint srcx, 
GLint srcy,
   unpack = pack;
   if (!_mesa_clip_drawpixels(ctx, , , , , ))
  return GL_TRUE; /* all done */
 
   readX = readX - pack.SkipPixels + unpack.SkipPixels;
   readY = readY - pack.SkipRows + unpack.SkipRows;
 
   drawW = readW;
   drawH = readH;
 
-  rbRead = st_get_color_read_renderbuffer(ctx);
-  rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
+  if (type == GL_COLOR) {
+ rbRead = st_get_color_read_renderbuffer(ctx);
+ rbDraw = st_renderbuffer(ctx->DrawBuffer->_ColorDrawBuffers[0]);
+  } else if (type == GL_DEPTH || type == GL_DEPTH_STENCIL) {
+ rbRead = 
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+ rbDraw = 
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer);
+  } else if (type == GL_STENCIL) {
+ rbRead = 
st_renderbuffer(ctx->ReadBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+ rbDraw = 
st_renderbuffer(ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer);
+  } else {
+ return false;
+  }
 
   /* Flip src/dst position depending on the orientation of buffers. */
   if (st_fb_orientation(ctx->ReadBuffer) == Y_0_TOP) {
  readY = rbRead->Base.Height - readY;
  readH = -readH;
   }
 
   if (st_fb_orientation(ctx->DrawBuffer) == Y_0_TOP) {
  /* We can't flip the destination for pipe->blit, so we only adjust
   * its position and flip the source.
@@ -1597,23 +1607,31 @@ blit_copy_pixels(struct gl_context *ctx, GLint srcx, 
GLint srcy,
  blit.src.box.depth = 1;
  blit.dst.resource = rbDraw->texture;
  blit.dst.level = rbDraw->surface->u.tex.level;
  blit.dst.format = rbDraw->texture->format;
  blit.dst.box.x = drawX;
  blit.dst.box.y = drawY;
  blit.dst.box.z = rbDraw->surface->u.tex.first_layer;
  blit.dst.box.width = drawW;
  blit.dst.box.height = drawH;
  blit.dst.box.depth = 1;
- blit.mask = PIPE_MASK_RGBA;
  blit.filter = PIPE_TEX_FILTER_NEAREST;
 
+ if (type == GL_COLOR)
+blit.mask |= PIPE_MASK_RGBA;
+ if (type == GL_DEPTH)
+blit.mask |= PIPE_MASK_Z;
+ if (type == GL_STENCIL)
+blit.mask |= PIPE_MASK_S;
+ if 

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Rob Clark
On Mon, Jun 24, 2019 at 11:48 AM Eric Anholt  wrote:
>
> Rob Clark  writes:
>
> > On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
> >
> > (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
> >
> >>   - Mozilla folks tell me that firefox's WebRender display lists can be
> >> captured in browser and then replayed from the WR repo under
> >> apitrace or rendredoc.
> >>
> >>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
> >> it wouldn't play the demo under renderdoc.
> >>
> >>   Do you have some apps that should be represented here?
> >>
> >> - Add microbenchmarks?  Looks like it would be pretty easy to grab
> >>   piglit drawoverhead results, not using renderdoc.  Capturing from
> >>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
> >>   excited about (Do we do different configs in those apps?  Then we need
> >>   config infrastructure.  Ugh).
> >>
> >> - I should probably add an estimate of "does this overall improve or
> >>   hurt perf?"  Yay doing more stats.
> >>
> >> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
> >>   prevents me from running run.py directly on my targets.
> >
> > thoughts about adding amd_perfcntr/etc support?  I guess some of the
> > perfcntrs we have perhaps want some post-processing to turn into
> > usuable numbers, and plenty of them we don't know much about what they
> > are other than the name.  But some of them are easy enough to
> > understand (like # of fs ALU cycles, etc), and being able to compare
> > that before/after shader optimizations seems useful.
>
> I'm not coming up with a good usecase for that, myself -- shader-db
> gives me a reasonable proxy for ALU cycles, and we've got wall time for
> a frame from this new tool, so perf counters would let me
> measure... maybe something like cycles spent in shader including stalls
> (think an optimization like GCM where shader-db analysis is unsuitable)
> but avoiding the rest of the noise introduced from CPU side costs and
> scheduling of jobs onto the GPU?

I suspect it would be useful in cases where we shift one bottleneck to another..

anyways, I think it is something that could be done generically (ie.
cmdline arg to ask for various counters by name).. that isn't to say
that this isn't already pretty useful as-is, but I guess adding
perfcntrs is probably something I'd do sooner or later..

BR,
-R

> Running my current perf analysis overnight feels a lot easier than
> trying to add configuration to capture specific GPU perf counters to the
> tool.  :)
>
> > Also, it would be nice to have a way to extract "slow frames" somehow
> > (maybe out of scope for this tool, but related?).. ie. when framerate
> > suddenly drops, those are the frames we probably want to look at more
> > closely..
>
> Renderdoc lets you capture a series of frames, so I guess you could do
> that and pick out your slow one?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv: always initialize levels without DCC as fully expanded

2019-06-24 Thread Bas Nieuwenhuizen
r-b for this patch only.

On Mon, Jun 24, 2019 at 5:00 PM Samuel Pitoiset
 wrote:
>
> This fixes a rendering issue with RoTR/DXVK.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 32 +++-
>  1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 9b4d4528028..733795eb1a4 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4960,26 +4960,24 @@ void radv_initialize_dcc(struct radv_cmd_buffer 
> *cmd_buffer,
>  * support fast clears and we have to initialize them as 
> "fully
>  * expanded".
>  */
> -   if (image->planes[0].surface.num_dcc_levels > 1) {
> -   /* Compute the size of all fast clearable DCC levels. 
> */
> -   for (unsigned i = 0; i < 
> image->planes[0].surface.num_dcc_levels; i++) {
> -   struct legacy_surf_level *surf_level =
> -   
> >planes[0].surface.u.legacy.level[i];
> +   /* Compute the size of all fast clearable DCC levels. */
> +   for (unsigned i = 0; i < 
> image->planes[0].surface.num_dcc_levels; i++) {
> +   struct legacy_surf_level *surf_level =
> +   >planes[0].surface.u.legacy.level[i];
>
> -   if (!surf_level->dcc_fast_clear_size)
> -   break;
> +   if (!surf_level->dcc_fast_clear_size)
> +   break;
>
> -   size = surf_level->dcc_offset + 
> surf_level->dcc_fast_clear_size;
> -   }
> +   size = surf_level->dcc_offset + 
> surf_level->dcc_fast_clear_size;
> +   }
>
> -   /* Initialize the mipmap levels without DCC. */
> -   if (size != image->planes[0].surface.dcc_size) {
> -   state->flush_bits |=
> -   radv_fill_buffer(cmd_buffer, 
> image->bo,
> -image->offset + 
> image->dcc_offset + size,
> -
> image->planes[0].surface.dcc_size - size,
> -0x);
> -   }
> +   /* Initialize the mipmap levels without DCC. */
> +   if (size != image->planes[0].surface.dcc_size) {
> +   state->flush_bits |=
> +   radv_fill_buffer(cmd_buffer, image->bo,
> +image->offset + 
> image->dcc_offset + size,
> +
> image->planes[0].surface.dcc_size - size,
> +0x);
> }
> }
>
> --
> 2.22.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

Re: [Mesa-dev] [PATCH 1/2] radv: fix setting CB_DCC_BASE if the base level doesn't enable DCC

2019-06-24 Thread Bas Nieuwenhuizen
why?

We should be regulating enabling it with S_028C70_DCC_ENABLE.

On Mon, Jun 24, 2019 at 5:00 PM Samuel Pitoiset
 wrote:
>
> CB_DCC_BASE should be 0 if no DCC.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 26b31cff9f1..dc5de683050 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -4342,15 +4342,16 @@ radv_initialise_color_surface(struct radv_device 
> *device,
> va += iview->image->cmask.offset;
> cb->cb_color_cmask = va >> 8;
>
> -   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
> -   va += iview->image->dcc_offset;
> +   if (radv_dcc_enabled(iview->image, iview->base_mip)) {
> +   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
> +   va += iview->image->dcc_offset;
>
> -   if (radv_dcc_enabled(iview->image, iview->base_mip) &&
> -   device->physical_device->rad_info.chip_class <= GFX8)
> -   va += 
> plane->surface.u.legacy.level[iview->base_mip].dcc_offset;
> +   if (device->physical_device->rad_info.chip_class <= GFX8)
> +   va += 
> plane->surface.u.legacy.level[iview->base_mip].dcc_offset;
>
> -   cb->cb_dcc_base = va >> 8;
> -   cb->cb_dcc_base |= surf->tile_swizzle;
> +   cb->cb_dcc_base = va >> 8;
> +   cb->cb_dcc_base |= surf->tile_swizzle;
> +   }
>
> uint32_t max_slice = radv_surface_max_layer_count(iview) - 1;
> cb->cb_color_view = S_028C6C_SLICE_START(iview->base_layer) |
> --
> 2.22.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

Re: [Mesa-dev] [PATCH] radv: clear FMASK layers instead of the whole buffer on GFX8

2019-06-24 Thread Bas Nieuwenhuizen
r-b

On Mon, Jun 24, 2019 at 12:14 PM Samuel Pitoiset
 wrote:
>
> This reduces the size of fill operations needed to clear FMASK
> for layered color textures.
>
> GFX9 unsupported for now.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_surface.c |  1 +
>  src/amd/common/ac_surface.h |  1 +
>  src/amd/vulkan/radv_cmd_buffer.c|  7 ---
>  src/amd/vulkan/radv_image.c |  1 +
>  src/amd/vulkan/radv_meta.h  |  3 ++-
>  src/amd/vulkan/radv_meta_clear.c| 22 ++
>  src/amd/vulkan/radv_meta_fmask_expand.c |  2 +-
>  src/amd/vulkan/radv_private.h   |  4 +++-
>  8 files changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index 7b86cb1e1f2..03d3505df53 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -953,6 +953,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
> surf->u.legacy.fmask.tiling_index = fout.tileIndex;
> surf->u.legacy.fmask.bankh = fout.pTileInfo->bankHeight;
> surf->u.legacy.fmask.pitch_in_pixels = fout.pitch;
> +   surf->u.legacy.fmask.slice_size = fout.sliceSize;
>
> /* Compute tile swizzle for FMASK. */
> if (config->info.fmask_surf_index &&
> diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
> index 49f68f4fc92..aa93e917270 100644
> --- a/src/amd/common/ac_surface.h
> +++ b/src/amd/common/ac_surface.h
> @@ -86,6 +86,7 @@ struct legacy_surf_fmask {
>  uint8_t tiling_index;/* max 31 */
>  uint8_t bankh;   /* max 8 */
>  uint16_t pitch_in_pixels;
> +uint64_t slice_size;
>  };
>
>  struct legacy_surf_layout {
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 9b4d4528028..419be5842e8 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4905,7 +4905,8 @@ static void radv_initialise_cmask(struct 
> radv_cmd_buffer *cmd_buffer,
>  }
>
>  void radv_initialize_fmask(struct radv_cmd_buffer *cmd_buffer,
> -  struct radv_image *image)
> +  struct radv_image *image,
> +  const VkImageSubresourceRange *range)
>  {
> struct radv_cmd_state *state = _buffer->state;
> static const uint32_t fmask_clear_values[4] = {
> @@ -4920,7 +4921,7 @@ void radv_initialize_fmask(struct radv_cmd_buffer 
> *cmd_buffer,
> state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
>  RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>
> -   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, value);
> +   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, range, 
> value);
>
> state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>  }
> @@ -5010,7 +5011,7 @@ static void radv_init_color_image_metadata(struct 
> radv_cmd_buffer *cmd_buffer,
> }
>
> if (radv_image_has_fmask(image)) {
> -   radv_initialize_fmask(cmd_buffer, image);
> +   radv_initialize_fmask(cmd_buffer, image, range);
> }
>
> if (radv_dcc_enabled(image, range->baseMipLevel)) {
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index cf3f0eb1d55..ca007d1dd65 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -907,6 +907,7 @@ radv_image_get_fmask_info(struct radv_device *device,
> out->slice_tile_max = 
> image->planes[0].surface.u.legacy.fmask.slice_tile_max;
> out->tile_mode_index = 
> image->planes[0].surface.u.legacy.fmask.tiling_index;
> out->pitch_in_pixels = 
> image->planes[0].surface.u.legacy.fmask.pitch_in_pixels;
> +   out->slice_size = image->planes[0].surface.u.legacy.fmask.slice_size;
> out->bank_height = image->planes[0].surface.u.legacy.fmask.bankh;
> out->tile_swizzle = image->planes[0].surface.fmask_tile_swizzle;
> out->alignment = image->planes[0].surface.fmask_alignment;
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 5880064ff30..30981f00790 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -214,7 +214,8 @@ void radv_decompress_resolve_src(struct radv_cmd_buffer 
> *cmd_buffer,
>  uint32_t radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
>   struct radv_image *image, uint32_t value);
>  uint32_t radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
> - struct radv_image *image, uint32_t value);
> + struct radv_image *image,
> + const VkImageSubresourceRange *range, uint32_t 
> value);
>  uint32_t radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
> struct radv_image *image,
> const VkImageSubresourceRange *range, 

Re: [Mesa-dev] [PATCH] radv: clear CMASK layers instead of the whole buffer on GFX8

2019-06-24 Thread Bas Nieuwenhuizen
r-b

On Mon, Jun 24, 2019 at 6:37 PM Samuel Pitoiset
 wrote:
>
> This reduces the size of fill operations needed to clear CMASK
> for layered color textures.
>
> GFX9 unsupported for now.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_surface.c  |  3 ++-
>  src/amd/common/ac_surface.h  |  1 +
>  src/amd/vulkan/radv_cmd_buffer.c |  8 ---
>  src/amd/vulkan/radv_image.c  |  1 +
>  src/amd/vulkan/radv_meta.h   |  3 ++-
>  src/amd/vulkan/radv_meta_clear.c | 36 
>  src/amd/vulkan/radv_private.h|  1 +
>  7 files changed, 35 insertions(+), 18 deletions(-)
>
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index 03d3505df53..24e2a01bfec 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -609,7 +609,8 @@ static void ac_compute_cmask(const struct radeon_info 
> *info,
> num_layers = config->info.array_size;
>
> surf->cmask_alignment = MAX2(256, base_align);
> -   surf->cmask_size = align(slice_bytes, base_align) * num_layers;
> +   surf->cmask_slice_size = align(slice_bytes, base_align);
> +   surf->cmask_size = surf->cmask_slice_size * num_layers;
>  }
>
>  /**
> diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
> index aa93e917270..31623634936 100644
> --- a/src/amd/common/ac_surface.h
> +++ b/src/amd/common/ac_surface.h
> @@ -219,6 +219,7 @@ struct radeon_surf {
>  uint32_thtile_alignment;
>
>  uint32_tcmask_size;
> +uint32_tcmask_slice_size;
>  uint32_tcmask_alignment;
>
>  union {
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 419be5842e8..0526e2719af 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4892,14 +4892,16 @@ static void radv_handle_depth_image_transition(struct 
> radv_cmd_buffer *cmd_buffe
>  }
>
>  static void radv_initialise_cmask(struct radv_cmd_buffer *cmd_buffer,
> - struct radv_image *image, uint32_t value)
> + struct radv_image *image,
> + const VkImageSubresourceRange *range,
> + uint32_t value)
>  {
> struct radv_cmd_state *state = _buffer->state;
>
> state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
> RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>
> -   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, value);
> +   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, range, 
> value);
>
> state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>  }
> @@ -5007,7 +5009,7 @@ static void radv_init_color_image_metadata(struct 
> radv_cmd_buffer *cmd_buffer,
> value = 0xu;
> }
>
> -   radv_initialise_cmask(cmd_buffer, image, value);
> +   radv_initialise_cmask(cmd_buffer, image, range, value);
> }
>
> if (radv_image_has_fmask(image)) {
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index ca007d1dd65..4099c57aa85 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -942,6 +942,7 @@ radv_image_get_cmask_info(struct radv_device *device,
>
> out->slice_tile_max = 
> image->planes[0].surface.u.legacy.cmask_slice_tile_max;
> out->alignment = image->planes[0].surface.cmask_alignment;
> +   out->slice_size = image->planes[0].surface.cmask_slice_size;
> out->size = image->planes[0].surface.cmask_size;
>  }
>
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index 30981f00790..c3d37bb07d2 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -212,7 +212,8 @@ void radv_decompress_resolve_src(struct radv_cmd_buffer 
> *cmd_buffer,
>  const VkImageResolve *regions);
>
>  uint32_t radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
> - struct radv_image *image, uint32_t value);
> + struct radv_image *image,
> + const VkImageSubresourceRange *range, uint32_t 
> value);
>  uint32_t radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
>   struct radv_image *image,
>   const VkImageSubresourceRange *range, uint32_t 
> value);
> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> b/src/amd/vulkan/radv_meta_clear.c
> index 0a9d9e76ca4..4d569729dda 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1326,11 +1326,21 @@ radv_get_cmask_fast_clear_value(const struct 
> radv_image *image)
>
>  uint32_t
>  radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
> -struct radv_image *image, uint32_t value)
> +

[Mesa-dev] [ANNOUNCE] mesa 19.0.7

2019-06-24 Thread Dylan Baker
Hi List,

I'd like to announce the availability of mesa 19.0.7. This is the last release
of the mesa 19.0 series, and all users are encouraged to migrate 19.1.x instead.

I'd like to apologize for the lateness of this release, in my defence I was on
vacation most of the 19.0.7 cycle and there were several patches that needed
backport.

There's nothing too crazy here for the final release of the series. It's pretty
spread across the system except for radv which had a number of small bug fixes.

Thanks again for the smooth sailing 19.0.x series, I'll see y'all again as
release manager in October for the 19.3 cycle.

Dylan

Bas Nieuwenhuizen (5):
  radv: Prevent out of bound shift on 32-bit builds.
  radv: Decompress DCC when the image format is not allowed for buffers.
  radv: Fix vulkan build in meson.
  anv: Fix vulkan build in meson.
  meson: Allow building radeonsi with just the android platform.

Charmaine Lee (1):
  svga: Remove unnecessary check for the pre flush bit for setting vertex 
buffers

Deepak Rawat (1):
  winsys/svga/drm: Fix 32-bit RPCI send message

Dylan Baker (4):
  docs: Add SHA256 sums for 19.0.6
  cherry-ignore: add additional 19.1 only patches
  Bump version for 19.0.7 release
  Docs add 19.0.7 release notes

Emil Velikov (1):
  mapi: correctly handle the full offset table

Gert Wollny (2):
  virgl: Add a caps feature check version
  virgl: Assume sRGB write control for older guest kernels or virglrenderer 
hosts

Haihao Xiang (1):
  i965: support UYVY for external import only

Jason Ekstrand (2):
  nir/propagate_invariant: Don't add NULL vars to the hash table
  anv: Set STATE_BASE_ADDRESS upper bounds on gen7

Kenneth Graunke (1):
  glsl: Fix out of bounds read in shader_cache_read_program_metadata

Kevin Strasser (2):
  gallium/winsys/kms: Fix dumb buffer bpp
  st/mesa: Add rgbx handling for fp formats

Lionel Landwerlin (2):
  intel/perf: fix EuThreadsCount value in performance equations
  intel/perf: improve dynamic loading config detection

Mathias Fröhlich (1):
  egl: Don't add hardware device if there is no render node v2.

Nanley Chery (1):
  anv/cmd_buffer: Initalize the clear color struct for CNL+

Nataraj Deshpande (1):
  anv: Fix check for isl_fmt in assert

Samuel Pitoiset (5):
  radv: fix alpha-to-coverage when there is unused color attachments
  radv: fix setting CB_SHADER_MASK for dual source blending
  radv: fix occlusion queries on VegaM
  radv: fix VK_EXT_memory_budget if one heap isn't available
  radv: fix FMASK expand with SRGB formats



git tag: mesa-19.0.7

https://mesa.freedesktop.org/archive/mesa-19.0.7.tar.gz
MD5:  8bb02b54b228f1bf46936f760adfc9a7  mesa-19.0.7.tar.gz
SHA1: 4c0e2dfe5dacdcbe9c46f4046970324fcc419908  mesa-19.0.7.tar.gz
SHA256: 81119f0cbbd1fbe7c0574e1e2690e0dae8868124d24c875f5fb76f165db3a54d  
mesa-19.0.7.tar.gz
SHA512: 
619796f193dc1667e0a88b0cd06f6d0d0ef4bfc078bdb7af1ac9dcf05cb9b5d753d9215ef5fe057ef3990735a5570e65b5d23fc4e5a5e1d37905a8eb87286d0a
  mesa-19.0.7.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.7.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-19.0.7.tar.xz
MD5:  4834e7951ba57bb8a2a403d9d5d93f31  mesa-19.0.7.tar.xz
SHA1: 1c7cd71150082d52a5308aef17ad8b41a6d7f726  mesa-19.0.7.tar.xz
SHA256: d7bf3db2e442fe5eeb96144f8508d94f04aededdf37af477e644638d366b2b28  
mesa-19.0.7.tar.xz
SHA512: 
eda02c426ad642c1f783aa376533c4f93354e819f99fd0187a88be2afd109effc9365e8d5ffd676202b006399674572d26b806da7f4c96adb8111243330cd121
  mesa-19.0.7.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.7.tar.xz.sig



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

[Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-24 Thread Simon Ser
gbm_{bo,surface}_create_with_modifiers is missing the usage flags. Add a new
function which lets library users specify it.

Signed-off-by: Simon Ser 
---
 src/gbm/main/gbm.c | 38 ++
 src/gbm/main/gbm.h | 17 +
 2 files changed, 55 insertions(+)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 38480ca966c6..ca68a3292327 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -491,6 +491,27 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
return gbm->bo_create(gbm, width, height, format, 0, modifiers, count);
 }

+GBM_EXPORT struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+  uint32_t width, uint32_t height,
+  uint32_t format,
+  const uint64_t *modifiers,
+  const unsigned int count,
+  uint32_t usage)
+{
+   if (width == 0 || height == 0) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   if ((count && !modifiers) || (modifiers && !count)) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   return gbm->bo_create(gbm, width, height, format, usage, modifiers, count);
+}
+
 /**
  * Create a gbm buffer object from a foreign object
  *
@@ -616,6 +637,23 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
   modifiers, count);
 }

+GBM_EXPORT struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format,
+   const uint64_t *modifiers,
+   const unsigned int count,
+   uint32_t flags)
+{
+   if ((count && !modifiers) || (modifiers && !count)) {
+  errno = EINVAL;
+  return NULL;
+   }
+
+   return gbm->surface_create(gbm, width, height, format, flags,
+  modifiers, count);
+}
+
 /**
  * Destroys the given surface and frees all resources associated with
  * it.
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 9b5288710a5b..0bb2e4443f97 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -263,6 +263,15 @@ gbm_bo_create_with_modifiers(struct gbm_device *gbm,
  uint32_t format,
  const uint64_t *modifiers,
  const unsigned int count);
+
+struct gbm_bo *
+gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
+  uint32_t width, uint32_t height,
+  uint32_t format,
+  const uint64_t *modifiers,
+  const unsigned int count,
+  uint32_t flags);
+
 #define GBM_BO_IMPORT_WL_BUFFER 0x5501
 #define GBM_BO_IMPORT_EGL_IMAGE 0x5502
 #define GBM_BO_IMPORT_FD0x5503
@@ -390,6 +399,14 @@ gbm_surface_create_with_modifiers(struct gbm_device *gbm,
   const uint64_t *modifiers,
   const unsigned int count);

+struct gbm_surface *
+gbm_surface_create_with_modifiers2(struct gbm_device *gbm,
+   uint32_t width, uint32_t height,
+   uint32_t format,
+   const uint64_t *modifiers,
+   const unsigned int count,
+   uint32_t flags);
+
 struct gbm_bo *
 gbm_surface_lock_front_buffer(struct gbm_surface *surface);

--
2.22.0


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

[Mesa-dev] [Bug 110983] [AMD TAHITI XT] vulkan dota2 broken

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110983

Sylvain BERTRAND  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #1 from Sylvain BERTRAND  ---
was me, as I was suspicious of

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

[Mesa-dev] [PATCH 1/2] panfrost: Track point sprites in fragment shader key

2019-06-24 Thread Alyssa Rosenzweig
In preparation for lowering point sprites, track them like we track
alpha testing state.

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

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index ceea48c401a..1e3c0dccc79 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1665,6 +1665,11 @@ panfrost_bind_rasterizer_state(
 
 ctx->rasterizer = hwcso;
 ctx->dirty |= PAN_DIRTY_RASTERIZER;
+
+/* Point sprites are emulated */
+
+if (ctx->rasterizer->base.sprite_coord_enable)
+ctx->base.bind_fs_state(>base, ctx->fs);
 }
 
 static void *
@@ -1805,6 +1810,7 @@ panfrost_variant_matches(
 struct panfrost_shader_state *variant,
 enum pipe_shader_type type)
 {
+struct pipe_rasterizer_state *rasterizer = >rasterizer->base;
 struct pipe_alpha_state *alpha = >depth_stencil->alpha;
 
 bool is_fragment = (type == PIPE_SHADER_FRAGMENT);
@@ -1823,6 +1829,22 @@ panfrost_variant_matches(
 return false;
 }
 }
+
+if (is_fragment && rasterizer && (rasterizer->sprite_coord_enable |
+variant->point_sprite_mask)) {
+/* Ensure the same varyings are turned to point sprites */
+if (rasterizer->sprite_coord_enable != 
variant->point_sprite_mask)
+return false;
+
+/* Ensure the orientation is correct */
+bool upper_left =
+rasterizer->sprite_coord_mode ==
+PIPE_SPRITE_COORD_UPPER_LEFT;
+
+if (variant->point_sprite_upper_left != upper_left)
+return false;
+}
+
 /* Otherwise, we're good to go */
 return true;
 }
@@ -1863,10 +1885,21 @@ panfrost_bind_shader_state(
 variant = variants->variant_count++;
 assert(variants->variant_count < MAX_SHADER_VARIANTS);
 
-variants->variants[variant].base = hwcso;
+struct panfrost_shader_state *v =
+>variants[variant];
+
+v->base = hwcso;
 
-if (type == PIPE_SHADER_FRAGMENT)
-variants->variants[variant].alpha_state = 
ctx->depth_stencil->alpha;
+if (type == PIPE_SHADER_FRAGMENT) {
+v->alpha_state = ctx->depth_stencil->alpha;
+
+if (ctx->rasterizer) {
+v->point_sprite_mask = 
ctx->rasterizer->base.sprite_coord_enable;
+v->point_sprite_upper_left =
+
ctx->rasterizer->base.sprite_coord_mode ==
+PIPE_SPRITE_COORD_UPPER_LEFT;
+}
+}
 
 /* Allocate the mapped descriptor ahead-of-time. */
 struct panfrost_context *ctx = pan_context(pctx);
diff --git a/src/gallium/drivers/panfrost/pan_context.h 
b/src/gallium/drivers/panfrost/pan_context.h
index 1f718bcd9c4..fc8fc3c1291 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -258,6 +258,9 @@ struct panfrost_shader_state {
 
 /* Information on this particular shader variant */
 struct pipe_alpha_state alpha_state;
+
+uint16_t point_sprite_mask;
+unsigned point_sprite_upper_left : 1;
 };
 
 /* A collection of varyings (the CSO) */
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/2] panfrost: Point sprites

2019-06-24 Thread Alyssa Rosenzweig
A pretty basic implementation of half of point sprites. No coordinate
flipping (either from the FB transform or from the sprite coord key).
Probably room for optimizations. Just enough to make the stars show up
in neverball, basically.

Alyssa Rosenzweig (2):
  panfrost: Track point sprites in fragment shader key
  panfrost: Replace varyings for point sprites

 src/gallium/drivers/panfrost/pan_context.c | 65 +-
 src/gallium/drivers/panfrost/pan_context.h |  3 +
 2 files changed, 65 insertions(+), 3 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH 2/2] panfrost: Replace varyings for point sprites

2019-06-24 Thread Alyssa Rosenzweig
This doesn't handle Y-flipping, but it's good enough to render the stars
in Neverball.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 28 +-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 1e3c0dccc79..895dcceff4e 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -610,6 +610,29 @@ panfrost_emit_varying_descriptor(
 for (unsigned i = 0; i < fs->tripipe->varying_count; i++) {
 unsigned j;
 
+/* If we have a point sprite replacement, handle that here. We
+ * have to translate location first.  TODO: Flip y in shader.
+ * We're already keying ... just time crunch .. */
+
+unsigned loc = fs->varyings_loc[i];
+unsigned pnt_loc =
+(loc >= VARYING_SLOT_VAR0) ? (loc - VARYING_SLOT_VAR0) 
:
+(loc == VARYING_SLOT_PNTC) ? 8 :
+~0;
+
+if (~pnt_loc && fs->point_sprite_mask & (1 << pnt_loc)) {
+/* gl_PointCoord index by convention */
+fs->varyings[i].index = 3;
+fs->reads_point_coord = true;
+
+/* Swizzle out the z/w to 0/1 */
+fs->varyings[i].format = MALI_RG16F;
+fs->varyings[i].swizzle =
+panfrost_get_default_swizzle(2);
+
+continue;
+}
+
 if (fs->varyings[i].index)
 continue;
 
@@ -1668,7 +1691,10 @@ panfrost_bind_rasterizer_state(
 
 /* Point sprites are emulated */
 
-if (ctx->rasterizer->base.sprite_coord_enable)
+struct panfrost_shader_state *variant =
+ctx->fs ? >fs->variants[ctx->fs->active_variant] : NULL;
+
+if (ctx->rasterizer->base.sprite_coord_enable || (variant && 
variant->point_sprite_mask))
 ctx->base.bind_fs_state(>base, ctx->fs);
 }
 
-- 
2.20.1

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

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Eric Anholt
Rob Clark  writes:

> On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
>
> (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
>
>>   - Mozilla folks tell me that firefox's WebRender display lists can be
>> captured in browser and then replayed from the WR repo under
>> apitrace or rendredoc.
>>
>>   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
>> it wouldn't play the demo under renderdoc.
>>
>>   Do you have some apps that should be represented here?
>>
>> - Add microbenchmarks?  Looks like it would be pretty easy to grab
>>   piglit drawoverhead results, not using renderdoc.  Capturing from
>>   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
>>   excited about (Do we do different configs in those apps?  Then we need
>>   config infrastructure.  Ugh).
>>
>> - I should probably add an estimate of "does this overall improve or
>>   hurt perf?"  Yay doing more stats.
>>
>> - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
>>   prevents me from running run.py directly on my targets.
>
> thoughts about adding amd_perfcntr/etc support?  I guess some of the
> perfcntrs we have perhaps want some post-processing to turn into
> usuable numbers, and plenty of them we don't know much about what they
> are other than the name.  But some of them are easy enough to
> understand (like # of fs ALU cycles, etc), and being able to compare
> that before/after shader optimizations seems useful.

I'm not coming up with a good usecase for that, myself -- shader-db
gives me a reasonable proxy for ALU cycles, and we've got wall time for
a frame from this new tool, so perf counters would let me
measure... maybe something like cycles spent in shader including stalls
(think an optimization like GCM where shader-db analysis is unsuitable)
but avoiding the rest of the noise introduced from CPU side costs and
scheduling of jobs onto the GPU?

Running my current perf analysis overnight feels a lot easier than
trying to add configuration to capture specific GPU perf counters to the
tool.  :)

> Also, it would be nice to have a way to extract "slow frames" somehow
> (maybe out of scope for this tool, but related?).. ie. when framerate
> suddenly drops, those are the frames we probably want to look at more
> closely..

Renderdoc lets you capture a series of frames, so I guess you could do
that and pick out your slow one?


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

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Eric Anholt
Elie Tournier  writes:

> Hi there,
>
> Great topic. For the past few days, I was looking at a CI for Mesa:
> https://gitlab.freedesktop.org/hopetech/tracie
> OK, it's in a very very alpha stage. ;)

I did one of those things using apitrace diff-images in piglit:

https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace

https://github.com/anholt/trace-db

It was bad.  diff-images is too picky and you end up needing to bless
new images constantly.  I have decided to not pursue this line of
testing any further because it was so unproductive.

What I *am* interested in trying with traces for correctness testing is
using a single driver to replay trace keyframes multiple times and make
sure the image is invariant.  This could catch a large class of UB in
real world applications without needing continuous human intervention.

> @eric Out of curiosity, did you looked at apitrace or did you go
> straight with renderdoc?

Since I was only looking at perf, I didn't use apitrace (I'd tried to
use it for perf in the past and it was absolutely dominated by trace
loading).  frameretrace would have made apitrace interesting to use for
this, but José blocked merging that.  That makes apitrace pretty dead
from my perspective.

Also, renderdoc's android capture is really nice to use.


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

Re: [Mesa-dev] Possible bug in nir_algebraic?

2019-06-24 Thread Ian Romanick
On 6/22/19 5:10 AM, Connor Abbott wrote:
> I haven't thought about whether it's algebraically correct, but
> otherwise your pattern looks fine to me.

I'll have a proof when I send out the patch. :)

> If you haven't noticed already, I added some commented out code to
> nir_replace_instr() that will print out each pattern that's matched.
> The first thing I'd do is move that up to the beginning of the
> function, so that it prints potential matches instead of actual
> matches. If your pattern shows up as a potential match, then it's a
> problem with match_expression() and not the automaton, and at that
> point you can start setting breakpoints and stepping through it.

It looks like the automaton is matching, but match_expression is not.
I'll dig deeper.  Thanks for the tips.

> If it's not a potential match because the automaton filtered it out,
> then debugging is currently a little harder. You'll have to add some
> debugging code to ${pass_name}_pre_block() that prints out the
> assigned state for each ALU instruction. The state is an integer which
> is conceptually an index into TreeAutomaton.states for the constructed
> TreeAutomaton. So if an instruction has state n, then
> automaton.states[n] should be a set of potential partial matches for
> that instruction. Note that variables like a, b, c etc. are converted
> into __wildcard while constants are all converted into __constant. So
> for example, ssa_2 should have a set { __const, __wildcard } as it can
> be matched as a variable or as a constant (we actually explicitly
> construct this set in TreeAutomaton._build_table). ssa_83 should have
> a set { __wildcard, (neg __wildcard) } since it can be matched either
> as a variable or as something like (neg a). (yes, this is very similar
> to the subset construction for getting a DFA from an NFA...). Unless
> there's a bug, each of these "match sets" should contain the
> appropriate subset of your pattern until ssa_97 which should have the
> full pattern as one of the entries in the set. Let us know the details
> if that's not the case.
> 
> I think that we could definitely do better when it comes to debugging
> why the automaton didn't match something. We could emit the
> automaton's state list in C, and then have a debugging option to print
> the match set for each instruction so you'd know where something went
> awry. I didn't do that earlier since I didn't have a need for it while
> bringing up the automaton, but we could add it if it helps. That being
> said, hopefully you won't need it this time :)
> 
> Best,
> 
> Connor
> 
> On Sat, Jun 22, 2019 at 2:26 AM Ian Romanick  wrote:
>>
>> I have encountered what I believe to be a bug in nir_algebraic.  Since
>> the rewrite to use automata, I'm not sure how to begin debugging it.
>> I'm looking for some suggestions... even if the suggestion is, "Fix your
>> patterns."
>>
>> I have added a pattern like:
>>
>>(('~fadd@32', ('fmul', ('fadd', 1.0, ('fneg', a)),
>>   ('fadd', 1.0, ('fneg', a))),
>>  ('fmul', ('flrp', a, 1.0, a), b)),
>> ('flrp', 1.0, b, a), '!options->lower_flrp32'),
>>
>> While using NIR_PRINT=1, I see this in my instruction stream:
>>
>> vec1 32 ssa_2 = load_const (0x3f80 /* 1.00 */)
>> ...
>> vec1 32 ssa_196 = intrinsic load_uniform (ssa_195) (68, 4, 160)
>> vec1 32 ssa_83 = fneg ssa_196
>> vec1 32 ssa_84 = fadd ssa_83, ssa_2
>> vec1 32 ssa_85 = fmul ssa_84, ssa_84
>> ...
>> vec1 32 ssa_95 = flrp ssa_196, ssa_2, ssa_196
>> vec1 32 ssa_96 = fmul ssa_78, ssa_95
>> vec1 32 ssa_97 = fadd ssa_96, ssa_85
>>
>> But nir_opt_algebraic does not make any progress.  It sure looks like it
>> should trigger with a = ssa_196 and b = ssa_78.
>>
>> However, progress is made if I change the pattern to
>>
>>(('~fadd@32', ('fmul', ('fadd', 1.0, ('fneg', a)),
>>   c),
>>  ('fmul', ('flrp', a, 1.0, a), b)),
>> ('flrp', 1.0, b, a), '!options->lower_flrp32'),
>>
>> ssa_85 is definitely ('fmul', ssa_84, ssa_84), and ssa_84 is definitely
>> ('fadd', 1.0, ('fneg', ssa_196))... both times. :)

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

[Mesa-dev] [Bug 110983] [AMD TAHITI XT] vulkan dota2 broken

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110983

Bug ID: 110983
   Summary: [AMD TAHITI XT] vulkan dota2 broken
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: highest
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: sylvain.bertr...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Updated mesa from git today, vulkan Dota2 is segfaulting while starting. Does
not even reach the radv built-in shader compilation.

Yes, I can bisect (could be me who did something wrong, and nothing pertinent
in the logs)

-- 
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] meson: Add dep_thread dependency.

2019-06-24 Thread Vinson Lee
Fix this build error on Ubuntu 18.04.

/usr/bin/ld: src/util/libmesa_util.a(u_cpu_detect.c.o): undefined reference to 
symbol 'pthread_once@@GLIBC_2.2.5'

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110663
Suggested-by: Eric Engestrom 
Signed-off-by: Vinson Lee 
---
 src/gallium/tests/trivial/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/tests/trivial/meson.build 
b/src/gallium/tests/trivial/meson.build
index bbb25519e12..1f912d5aa46 100644
--- a/src/gallium/tests/trivial/meson.build
+++ b/src/gallium/tests/trivial/meson.build
@@ -24,6 +24,7 @@ foreach t : ['compute', 'tri', 'quad-tex']
 '@0@.c'.format(t),
 include_directories : inc_common,
 link_with : [libmesa_util, libgallium, libpipe_loader_dynamic],
+dependencies : dep_thread,
 install : false,
   )
 endforeach
-- 
2.17.1

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

[Mesa-dev] [PATCH 17/20] panfrost: Support (non-)seamless cube maps

2019-06-24 Thread Alyssa Rosenzweig
Identify the seamless cubemap bit and passthrough the Gallium state
rather than setting unconditionally.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/include/panfrost-job.h | 5 +++--
 src/gallium/drivers/panfrost/pan_context.c  | 2 +-
 src/gallium/drivers/panfrost/pandecode/decode.c | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h 
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 6da86148cd7..f1094d76cdf 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -1235,8 +1235,9 @@ struct mali_sampler_descriptor {
 enum mali_wrap_mode wrap_r : 4;
 enum mali_alt_func compare_func : 3;
 
-/* A single set bit of unknown, ha! */
-unsigned unknown2 : 1;
+/* No effect on 2D textures. For cubemaps, set for ES3 and clear for
+ * ES2, controlling seamless cubemapping */
+unsigned seamless_cube_map : 1;
 
 unsigned zero : 16;
 
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index bdd1551a531..c6fe3f87890 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1743,7 +1743,7 @@ panfrost_create_sampler_state(
 },
 .min_lod = FIXED_16(cso->min_lod),
 .max_lod = FIXED_16(cso->max_lod),
-.unknown2 = 1,
+.seamless_cube_map = cso->seamless_cube_map,
 };
 
 /* If necessary, we disable mipmapping in the sampler descriptor by
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 8d03618c9f0..b26cd2909e0 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -1758,7 +1758,7 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 pandecode_prop("zero = 0x%X, 0x%X\n", 
s->zero, s->zero2);
 }
 
-pandecode_prop("unknown2 = %d", s->unknown2);
+pandecode_prop("seamless_cube_map = %d", 
s->seamless_cube_map);
 
 pandecode_prop("border_color = { %f, %f, %f, 
%f }",
  s->border_color[0],
-- 
2.20.1

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

[Mesa-dev] [PATCH 19/20] panfrost/ci: Update failures list

2019-06-24 Thread Alyssa Rosenzweig
A ton of tests were fixed by this series. A few were incorrectly passing
before (QualityError, for instance) and now are explicitly failing. A
few legitimate regressions but overwhelmingly positive.

Signed-off-by: Alyssa Rosenzweig 
---
 .../drivers/panfrost/ci/expected-failures.txt | 304 +-
 1 file changed, 11 insertions(+), 293 deletions(-)

diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt 
b/src/gallium/drivers/panfrost/ci/expected-failures.txt
index b5d3d430c30..63d5433ae60 100644
--- a/src/gallium/drivers/panfrost/ci/expected-failures.txt
+++ b/src/gallium/drivers/panfrost/ci/expected-failures.txt
@@ -8,77 +8,45 @@ dEQP-GLES2.functional.color_clear.scissored_rgb
 dEQP-GLES2.functional.color_clear.scissored_rgba
 dEQP-GLES2.functional.color_clear.short_scissored_rgb
 dEQP-GLES2.functional.fbo.completeness.size.distinct
-dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb5_a1
-dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgb5_a1_depth_component16
-dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgba4
-dEQP-GLES2.functional.fbo.render.color.blend_npot_rbo_rgba4_depth_component16
-dEQP-GLES2.functional.fbo.render.color.blend_rbo_rgb5_a1
-dEQP-GLES2.functional.fbo.render.color.blend_rbo_rgb5_a1_depth_component16
-dEQP-GLES2.functional.fbo.render.color.blend_rbo_rgba4
-dEQP-GLES2.functional.fbo.render.color.blend_rbo_rgba4_depth_component16
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgb5_a1
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgb5_a1_depth_component16
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgb5_a1_stencil_index8
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgba4
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgba4_depth_component16
-dEQP-GLES2.functional.fbo.render.color_clear.rbo_rgba4_stencil_index8
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgb565_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgb565_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgb5_a1
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgb5_a1_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgb5_a1_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgba4
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgba4_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_rbo_rgba4_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgb
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgb_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgb_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgba
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgba_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.no_rebind_tex2d_rgba_stencil_index8
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgb565_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgb565_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgb5_a1
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgb5_a1_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgb5_a1_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgba4
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgba4_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_rbo_rgba4_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgb
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgb_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgb_stencil_index8
-dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgba
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgba_depth_component16
 
dEQP-GLES2.functional.fbo.render.recreate_colorbuffer.rebind_tex2d_rgba_stencil_index8
-dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgb
-dEQP-GLES2.functional.fbo.render.repeated_clear.tex2d_rgba
+dEQP-GLES2.functional.fbo.render.resize.rbo_rgb565_depth_component16
 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb565_stencil_index8
-dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1
 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1_depth_component16
 dEQP-GLES2.functional.fbo.render.resize.rbo_rgb5_a1_stencil_index8
-dEQP-GLES2.functional.fbo.render.resize.rbo_rgba4
 dEQP-GLES2.functional.fbo.render.resize.rbo_rgba4_depth_component16
 dEQP-GLES2.functional.fbo.render.resize.rbo_rgba4_stencil_index8
+dEQP-GLES2.functional.fbo.render.resize.tex2d_rgb_depth_component16
 

[Mesa-dev] [PATCH 11/20] panfrost: Divide array_size by 6 for cubemaps

2019-06-24 Thread Alyssa Rosenzweig
Addresses the disparity between Mali and Gallium definitions of
array_size.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index e7d1d0a01df..c9d37f770ac 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2091,6 +2091,7 @@ panfrost_create_sampler_view(
 if (texture->target == PIPE_TEXTURE_CUBE) {
 /* TODO: Cubemap arrays */
 assert(array_size == 6);
+array_size /= 6;
 }
 
 struct mali_texture_descriptor texture_descriptor = {
-- 
2.20.1

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

[Mesa-dev] [PATCH 18/20] panfrost/midgard: Set magic flag for vertex textures

2019-06-24 Thread Alyssa Rosenzweig
Let's match the blob. It's not clear what exactly this controls yet,
though.

Signed-off-by: Alyssa Rosenzweig 
---
 .../drivers/panfrost/midgard/midgard_compile.c  | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index e4c21c671fb..5d2e9ca8d3b 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1545,6 +1545,19 @@ emit_texop_native(compiler_context *ctx, nir_tex_instr 
*instr,
 ins.texture.in_reg_select = in_reg;
 ins.texture.out_reg_select = out_reg;
 
+/* Setup magic flag? */
+bool is_vertex = ctx->stage == MESA_SHADER_VERTEX;
+bool is_cube = instr->sampler_dim == GLSL_SAMPLER_DIM_CUBE;
+bool is_2d = instr->sampler_dim == GLSL_SAMPLER_DIM_2D;
+
+if (is_vertex) {
+if (is_cube)
+ins.texture.unknown4 = 0x3;
+else if (is_2d)
+ins.texture.unknown4 = 0x5;
+}
+
+
 /* Setup bias/LOD if necessary. Only register mode support right now.
  * TODO: Immediate mode for performance gains */
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 13/20] panfrost: Use dedicated u_blitter context for wallpapers

2019-06-24 Thread Alyssa Rosenzweig
The main ctx->blitter instance should be reserved for blits originated
from Gallium (like mipmap generation). Since wallpapering is
conceptually different -- wallpaper blits can be triggered by Gallium
blits -- the blitter pipes must be separate to avoid potential u_blitter
recursion.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_blit.c| 40 --
 src/gallium/drivers/panfrost/pan_context.c |  6 
 src/gallium/drivers/panfrost/pan_context.h |  8 +
 3 files changed, 35 insertions(+), 19 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_blit.c 
b/src/gallium/drivers/panfrost/pan_blit.c
index 1e50448a67d..c98e08e8a0b 100644
--- a/src/gallium/drivers/panfrost/pan_blit.c
+++ b/src/gallium/drivers/panfrost/pan_blit.c
@@ -31,29 +31,31 @@
 #include "util/u_format.h"
 
 static void
-panfrost_blitter_save(struct panfrost_context *ctx)
+panfrost_blitter_save(
+struct panfrost_context *ctx,
+struct blitter_context *blitter)
 {
 
-util_blitter_save_vertex_buffer_slot(ctx->blitter, 
ctx->vertex_buffers);
-util_blitter_save_vertex_elements(ctx->blitter, ctx->vertex);
-util_blitter_save_vertex_shader(ctx->blitter, ctx->vs);
-util_blitter_save_rasterizer(ctx->blitter, ctx->rasterizer);
-util_blitter_save_viewport(ctx->blitter, >pipe_viewport);
-util_blitter_save_scissor(ctx->blitter, >scissor);
-util_blitter_save_fragment_shader(ctx->blitter, ctx->fs);
-util_blitter_save_blend(ctx->blitter, ctx->blend);
-util_blitter_save_depth_stencil_alpha(ctx->blitter, 
ctx->depth_stencil);
-util_blitter_save_stencil_ref(ctx->blitter, >stencil_ref);
-   util_blitter_save_so_targets(ctx->blitter, 0, NULL);
+util_blitter_save_vertex_buffer_slot(blitter, ctx->vertex_buffers);
+util_blitter_save_vertex_elements(blitter, ctx->vertex);
+util_blitter_save_vertex_shader(blitter, ctx->vs);
+util_blitter_save_rasterizer(blitter, ctx->rasterizer);
+util_blitter_save_viewport(blitter, >pipe_viewport);
+util_blitter_save_scissor(blitter, >scissor);
+util_blitter_save_fragment_shader(blitter, ctx->fs);
+util_blitter_save_blend(blitter, ctx->blend);
+util_blitter_save_depth_stencil_alpha(blitter, ctx->depth_stencil);
+util_blitter_save_stencil_ref(blitter, >stencil_ref);
+   util_blitter_save_so_targets(blitter, 0, NULL);
 
/* For later */
-//util_blitter_save_sample_mask(ctx->blitter, ctx->sample_mask);
+//util_blitter_save_sample_mask(blitter, ctx->sample_mask);
 
-util_blitter_save_framebuffer(ctx->blitter, >pipe_framebuffer);
-util_blitter_save_fragment_sampler_states(ctx->blitter,
+util_blitter_save_framebuffer(blitter, >pipe_framebuffer);
+util_blitter_save_fragment_sampler_states(blitter,
  
ctx->sampler_count[PIPE_SHADER_FRAGMENT],
  (void 
**)(>samplers[PIPE_SHADER_FRAGMENT]));
-util_blitter_save_fragment_sampler_views(ctx->blitter,
+util_blitter_save_fragment_sampler_views(blitter,
 
ctx->sampler_view_count[PIPE_SHADER_FRAGMENT],
 (struct pipe_sampler_view 
**)>sampler_views[PIPE_SHADER_FRAGMENT]);
 }
@@ -73,7 +75,7 @@ panfrost_u_blitter_blit(struct pipe_context *pipe,
 
 /* TODO: Scissor */
 
-panfrost_blitter_save(ctx);
+panfrost_blitter_save(ctx, ctx->blitter);
 util_blitter_blit(ctx->blitter, info);
 
 return true;
@@ -105,7 +107,7 @@ panfrost_blit_wallpaper(struct panfrost_context *ctx)
 {
 struct pipe_blit_info binfo = { };
 
-panfrost_blitter_save(ctx);
+panfrost_blitter_save(ctx, ctx->blitter_wallpaper);
 
binfo.src.resource = binfo.dst.resource = 
ctx->pipe_framebuffer.cbufs[0]->texture;
binfo.src.level = binfo.dst.level = 0;
@@ -122,6 +124,6 @@ panfrost_blit_wallpaper(struct panfrost_context *ctx)
binfo.filter = PIPE_TEX_FILTER_LINEAR;
binfo.scissor_enable = FALSE;
 
-   util_blitter_blit(ctx->blitter, );
+   util_blitter_blit(ctx->blitter_wallpaper, );
 }
 
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index c9d37f770ac..3723d108c68 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2416,6 +2416,9 @@ panfrost_destroy(struct pipe_context *pipe)
 if (panfrost->blitter)
 util_blitter_destroy(panfrost->blitter);
 
+if (panfrost->blitter_wallpaper)
+util_blitter_destroy(panfrost->blitter_wallpaper);
+
 panfrost_drm_free_slab(screen, >scratchpad);
 panfrost_drm_free_slab(screen, >varying_mem);
 panfrost_drm_free_slab(screen, 

[Mesa-dev] [PATCH 15/20] panfrost/decode: Limit MRT blend count

2019-06-24 Thread Alyssa Rosenzweig
I thought I already fixed this. Maybe that was a dream...? Then again, I
might be dreaming now.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pandecode/decode.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 5bc6dd84c60..8d03618c9f0 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -672,7 +672,7 @@ pandecode_render_target(uint64_t gpu_va, unsigned job_no, 
const struct bifrost_f
 pandecode_log("};\n");
 }
 
-static void
+static unsigned
 pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no, bool 
with_render_targets)
 {
 struct pandecode_mapped_memory *mem = 
pandecode_find_mapped_gpu_mem_containing(gpu_va);
@@ -855,6 +855,9 @@ pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no, bool 
with_render_targets)
 
 if (with_render_targets)
 pandecode_render_target(gpu_va, job_no, fb);
+
+/* Passback the render target count */
+return MALI_NEGATIVE(fb->rt_count_1);
 }
 
 static void
@@ -1311,6 +1314,8 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 mali_ptr shader_meta_ptr = (u64) (uintptr_t) (p->_shader_upper << 4);
 struct pandecode_mapped_memory *attr_mem;
 
+unsigned rt_count = 1;
+
 /* On Bifrost, since the tiler heap (for tiler jobs) and the scratchpad
  * are the only things actually needed from the FBD, vertex/tiler jobs
  * no longer reference the FBD -- instead, this field points to some
@@ -1319,7 +1324,7 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 if (is_bifrost)
 pandecode_replay_scratchpad(p->framebuffer & ~FBD_TYPE, 
job_no, suffix);
 else if (p->framebuffer & MALI_MFBD)
-pandecode_replay_mfbd_bfr((u64) ((uintptr_t) p->framebuffer) & 
FBD_MASK, job_no, false);
+rt_count = pandecode_replay_mfbd_bfr((u64) ((uintptr_t) 
p->framebuffer) & FBD_MASK, job_no, false);
 else if (job_type == JOB_TYPE_COMPUTE)
 pandecode_compute_fbd((u64) (uintptr_t) p->framebuffer, 
job_no);
 else
@@ -1470,7 +1475,7 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 if (job_type == JOB_TYPE_TILER) {
 void* blend_base = (void *) (s + 1);
 
-for (unsigned i = 0; i < 4; i++) {
+for (unsigned i = 0; i < rt_count; i++) {
 mali_ptr shader = 0;
 
 if (is_bifrost)
-- 
2.20.1

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

[Mesa-dev] [PATCH 09/20] panfrost: Merge AFBC slab with BO backing

2019-06-24 Thread Alyssa Rosenzweig
Rather than tracking AFBC memory "specially", just use the same codepath
as linear and tiled. Less things to mess up, I figure. This allows us to
use the standard setup_slices() call with AFBC resources, allowing
mipmapped AFBC resources.

Unfortunately, we do have to disable AFBC (and checksumming) in the
meantime to avoid functional regressions, as we don't know _a priori_ if
we'll need to access a resource from software (which is not yet hooked
up with AFBC) and we don't yet have routines to switch the layout of a
BO at runtime.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_afbc.c | 43 -
 src/gallium/drivers/panfrost/pan_context.c  | 26 +++--
 src/gallium/drivers/panfrost/pan_mfbd.c | 23 +--
 src/gallium/drivers/panfrost/pan_resource.c | 29 +++---
 src/gallium/drivers/panfrost/pan_resource.h | 16 +++-
 5 files changed, 46 insertions(+), 91 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_afbc.c 
b/src/gallium/drivers/panfrost/pan_afbc.c
index 5621d1f333a..c9487b5e943 100644
--- a/src/gallium/drivers/panfrost/pan_afbc.c
+++ b/src/gallium/drivers/panfrost/pan_afbc.c
@@ -101,22 +101,9 @@ panfrost_format_supports_afbc(enum pipe_format format)
 return false;
 }
 
-/* AFBC is enabled on a per-resource basis (AFBC enabling is theoretically
- * indepdent between color buffers and depth/stencil). To enable, we allocate
- * the AFBC metadata buffer and mark that it is enabled. We do -not- actually
- * edit the fragment job here. This routine should be called ONCE per
- * AFBC-compressed buffer, rather than on every frame. */
-
-void
-panfrost_enable_afbc(struct panfrost_context *ctx, struct panfrost_resource 
*rsrc, bool ds)
+unsigned
+panfrost_afbc_header_size(unsigned width, unsigned height)
 {
-struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = pan_screen(gallium->screen);
-
-unsigned width  = rsrc->base.width0;
-unsigned height = rsrc->base.height0;
-unsigned bytes_per_pixel = 
util_format_get_blocksize(rsrc->base.format);
-
 /* Align to tile */
 unsigned aligned_width  = ALIGN(width,  AFBC_TILE_WIDTH);
 unsigned aligned_height = ALIGN(height, AFBC_TILE_HEIGHT);
@@ -126,26 +113,10 @@ panfrost_enable_afbc(struct panfrost_context *ctx, struct 
panfrost_resource *rsr
 unsigned tile_count_y = aligned_height / AFBC_TILE_HEIGHT;
 unsigned tile_count = tile_count_x * tile_count_y;
 
+/* Multiply to find the header size */
 unsigned header_bytes = tile_count * AFBC_HEADER_BYTES_PER_TILE;
-unsigned header_size = ALIGN(header_bytes, AFBC_CACHE_ALIGN);
-
-/* The stride is a normal stride, but aligned */
-unsigned unaligned_stride = aligned_width * bytes_per_pixel;
-unsigned stride = ALIGN(unaligned_stride, AFBC_CACHE_ALIGN);
-
-/* Compute the entire buffer size */
-unsigned body_size = stride * aligned_height;
-unsigned buffer_size = header_size + body_size;
-
-/* Allocate the AFBC slab itself, large enough to hold the above */
-panfrost_drm_allocate_slab(screen, >bo->afbc_slab,
-   ALIGN(buffer_size, 4096) / 4096,
-   true, 0, 0, 0);
-
-/* Compressed textured reads use a tagged pointer to the metadata */
-rsrc->bo->layout = PAN_AFBC;
-rsrc->bo->gpu = rsrc->bo->afbc_slab.gpu | (ds ? 0 : 1);
-rsrc->bo->cpu = rsrc->bo->afbc_slab.cpu;
-rsrc->bo->gem_handle = rsrc->bo->afbc_slab.gem_handle;
-rsrc->bo->afbc_metadata_size = header_size;
+
+/* Align and go */
+return ALIGN(header_bytes, AFBC_CACHE_ALIGN);
+
 }
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 6bda78e96dc..28a1f598934 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -813,7 +813,12 @@ panfrost_get_texture_address(
 unsigned level_offset = rsrc->bo->slices[level].offset;
 unsigned face_offset = face * rsrc->bo->cubemap_stride;
 
-return rsrc->bo->gpu + level_offset + face_offset;
+/* Lower-bit is set when sampling from colour AFBC */
+bool is_afbc = rsrc->bo->layout == PAN_AFBC;
+bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
+unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
+
+return rsrc->bo->gpu + level_offset + face_offset + afbc_bit;
 
 }
 
@@ -2213,18 +2218,6 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
 ctx->vt_framebuffer_mfbd = panfrost_emit_mfbd(ctx, ~0);
 
 panfrost_attach_vt_framebuffer(ctx);
-
-struct panfrost_resource *tex = ((struct panfrost_resource *) 
ctx->pipe_framebuffer.cbufs[i]->texture);
-enum pipe_format format = 

[Mesa-dev] [PATCH 20/20] panfrost/midgard: Fixup NIR texture op

2019-06-24 Thread Alyssa Rosenzweig
In a vertex shader, a tex op should map to txl, as there *must* be a LOD
given to the hardware (implicitly or explicitly).

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 5d2e9ca8d3b..9109544f89f 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1601,6 +1601,14 @@ emit_texop_native(compiler_context *ctx, nir_tex_instr 
*instr,
 static void
 emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 {
+/* Fixup op, since only textureLod is permitted in VS but NIR can give
+ * generic tex in some cases (which confuses the hardware) */
+
+bool is_vertex = ctx->stage == MESA_SHADER_VERTEX;
+
+if (is_vertex && instr->op == nir_texop_tex)
+instr->op = nir_texop_txl;
+
 switch (instr->op) {
 case nir_texop_tex:
 case nir_texop_txb:
-- 
2.20.1

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

[Mesa-dev] [PATCH 14/20] panfrost: Clamp tile coordinates before job submission

2019-06-24 Thread Alyssa Rosenzweig
Fixes TILE_RANGE_FAULT raised on some tests in
dEQP-GLES3.functional.fbo.blit.*

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_fragment.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_fragment.c 
b/src/gallium/drivers/panfrost/pan_fragment.c
index d6b8afdc6b9..5dbca021141 100644
--- a/src/gallium/drivers/panfrost/pan_fragment.c
+++ b/src/gallium/drivers/panfrost/pan_fragment.c
@@ -69,6 +69,26 @@ panfrost_fragment_job(struct panfrost_context *ctx, bool 
has_draws)
 
 struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
 
+/* The passed tile coords can be out of range in some cases, so we need
+ * to clamp them to the framebuffer size to avoid a TILE_RANGE_FAULT.
+ * Theoretically we also need to clamp the coordinates positive, but we
+ * avoid that edge case as all four values are unsigned. Also,
+ * theoretically we could clamp the minima, but if that has to happen
+ * the asserts would fail anyway (since the maxima would get clamped
+ * and then be smaller than the minima). An edge case of sorts occurs
+ * when no scissors are added to draw, so by default min=~0 and max=0.
+ * But that can't happen if any actual drawing occurs (beyond a
+ * wallpaper reload), so this is again irrelevant in practice. */
+
+job->maxx = MIN2(job->maxx, fb->width);
+job->maxy = MIN2(job->maxy, fb->height);
+
+/* Rendering region must be at least 1x1; otherwise, there is nothing
+ * to do and the whole job chain should have been discarded. */
+
+assert(job->maxx > job->minx);
+assert(job->maxy > job->miny);
+
 struct mali_payload_fragment payload = {
 .min_tile_coord = MALI_COORDINATE_TO_TILE_MIN(job->minx, 
job->miny),
 .max_tile_coord = MALI_COORDINATE_TO_TILE_MAX(job->maxx, 
job->maxy),
-- 
2.20.1

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

[Mesa-dev] [PATCH 16/20] panfrost: Merge checksum buffer with main BO

2019-06-24 Thread Alyssa Rosenzweig
This is similar to the AFBC merge; now all (non-imported) buffers use a
common backing buffer. Reenables checksumming, eliminating a performance
regression.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c  | 16 --
 src/gallium/drivers/panfrost/pan_drm.c  |  3 --
 src/gallium/drivers/panfrost/pan_mfbd.c | 15 --
 src/gallium/drivers/panfrost/pan_resource.c | 60 +++--
 src/gallium/drivers/panfrost/pan_resource.h | 17 +++---
 5 files changed, 64 insertions(+), 47 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 3723d108c68..bdd1551a531 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -75,22 +75,6 @@ panfrost_job_type_for_pipe(enum pipe_shader_type type)
 }
 }
 
-static void
-panfrost_enable_checksum(struct panfrost_context *ctx, struct 
panfrost_resource *rsrc)
-{
-struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = pan_screen(gallium->screen);
-int tile_w = (rsrc->base.width0 + (MALI_TILE_LENGTH - 1)) >> 
MALI_TILE_SHIFT;
-int tile_h = (rsrc->base.height0 + (MALI_TILE_LENGTH - 1)) >> 
MALI_TILE_SHIFT;
-
-/* 8 byte checksum per tile */
-rsrc->bo->checksum_stride = tile_w * 8;
-int pages = (((rsrc->bo->checksum_stride * tile_h) + 4095) / 4096);
-panfrost_drm_allocate_slab(screen, >bo->checksum_slab, pages, 
false, 0, 0, 0);
-
-rsrc->bo->has_checksum = true;
-}
-
 /* Framebuffer descriptor */
 
 static void
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 2ab43cc1e4c..4f354190455 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -214,9 +214,6 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64 
job_desc, int reqs, st
struct panfrost_resource *res = pan_resource(surf->texture);
assert(res->bo->gem_handle > 0);
bo_handles[submit.bo_handle_count++] = res->bo->gem_handle;
-
-   if (res->bo->checksum_slab.gem_handle)
-   bo_handles[submit.bo_handle_count++] = 
res->bo->checksum_slab.gem_handle;
}
 
/* TODO: Add here the transient pools */
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c 
b/src/gallium/drivers/panfrost/pan_mfbd.c
index af59497fa78..4d5fa4ad9ac 100644
--- a/src/gallium/drivers/panfrost/pan_mfbd.c
+++ b/src/gallium/drivers/panfrost/pan_mfbd.c
@@ -289,14 +289,21 @@ panfrost_mfbd_fragment(struct panfrost_context *ctx, bool 
has_draws)
 if (job->requirements & PAN_REQ_DEPTH_WRITE)
 fb.mfbd_flags |= MALI_MFBD_DEPTH_WRITE;
 
+/* Checksumming only works with a single render target */
+
 if (ctx->pipe_framebuffer.nr_cbufs == 1) {
-struct panfrost_resource *rsrc = (struct panfrost_resource *) 
ctx->pipe_framebuffer.cbufs[0]->texture;
+struct pipe_surface *surf = ctx->pipe_framebuffer.cbufs[0];
+struct panfrost_resource *rsrc = pan_resource(surf->texture);
+struct panfrost_bo *bo = rsrc->bo;
+
+if (bo->checksummed) {
+unsigned level = surf->u.tex.level;
+struct panfrost_slice *slice = >slices[level];
 
-if (rsrc->bo->has_checksum) {
 fb.mfbd_flags |= MALI_MFBD_EXTRA;
 fbx.flags |= MALI_EXTRA_PRESENT;
-fbx.checksum_stride = rsrc->bo->checksum_stride;
-fbx.checksum = rsrc->bo->gpu + 
rsrc->bo->slices[0].stride * rsrc->base.height0;
+fbx.checksum_stride = slice->checksum_stride;
+fbx.checksum = bo->gpu + slice->checksum_offset;
 }
 }
 
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index beb5f72d2d8..89403ab183b 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -180,6 +180,31 @@ panfrost_surface_destroy(struct pipe_context *pipe,
 ralloc_free(surf);
 }
 
+/* Computes sizes for checksumming, which is 8 bytes per 16x16 tile */
+
+#define CHECKSUM_TILE_WIDTH 16
+#define CHECKSUM_TILE_HEIGHT 16
+#define CHECKSUM_BYTES_PER_TILE 8
+
+static unsigned
+panfrost_compute_checksum_sizes(
+struct panfrost_slice *slice,
+unsigned width,
+unsigned height)
+{
+unsigned aligned_width = ALIGN(width, CHECKSUM_TILE_WIDTH);
+unsigned aligned_height = ALIGN(width, CHECKSUM_TILE_HEIGHT);
+
+unsigned tile_count_x = aligned_width / CHECKSUM_TILE_WIDTH;
+unsigned tile_count_y = aligned_height / CHECKSUM_TILE_HEIGHT;
+
+slice->checksum_stride = tile_count_x * 

[Mesa-dev] [PATCH 10/20] panfrost: Use get_texture_address for framebuffer computations

2019-06-24 Thread Alyssa Rosenzweig
Allows for sharing some code as well as theoretically allowing cubemap
rendering.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c  | 19 ---
 src/gallium/drivers/panfrost/pan_mfbd.c | 11 +--
 src/gallium/drivers/panfrost/pan_resource.c | 18 ++
 src/gallium/drivers/panfrost/pan_resource.h |  5 +
 4 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 28a1f598934..e7d1d0a01df 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -803,25 +803,6 @@ panfrost_upload_sampler_descriptors(struct 
panfrost_context *ctx)
 }
 }
 
-/* Computes the address to a texture at a particular slice */
-
-static mali_ptr
-panfrost_get_texture_address(
-struct panfrost_resource *rsrc,
-unsigned level, unsigned face)
-{
-unsigned level_offset = rsrc->bo->slices[level].offset;
-unsigned face_offset = face * rsrc->bo->cubemap_stride;
-
-/* Lower-bit is set when sampling from colour AFBC */
-bool is_afbc = rsrc->bo->layout == PAN_AFBC;
-bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
-unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
-
-return rsrc->bo->gpu + level_offset + face_offset + afbc_bit;
-
-}
-
 static mali_ptr
 panfrost_upload_tex(
 struct panfrost_context *ctx,
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c 
b/src/gallium/drivers/panfrost/pan_mfbd.c
index 0ebfecc1200..e74a8e6229f 100644
--- a/src/gallium/drivers/panfrost/pan_mfbd.c
+++ b/src/gallium/drivers/panfrost/pan_mfbd.c
@@ -94,10 +94,10 @@ panfrost_mfbd_set_cbuf(
 struct panfrost_resource *rsrc = pan_resource(surf->texture);
 
 unsigned level = surf->u.tex.level;
-assert(surf->u.tex.first_layer == 0);
-
+unsigned first_layer = surf->u.tex.first_layer;
 int stride = rsrc->bo->slices[level].stride;
-unsigned offset = rsrc->bo->slices[level].offset;
+
+mali_ptr base = panfrost_get_texture_address(rsrc, level, first_layer);
 
 rt->format = panfrost_mfbd_format(surf);
 
@@ -105,16 +105,15 @@ panfrost_mfbd_set_cbuf(
 
 if (rsrc->bo->layout == PAN_LINEAR) {
 rt->format.block = MALI_MFBD_BLOCK_LINEAR;
-rt->framebuffer = rsrc->bo->gpu + offset;
+rt->framebuffer = base;
 rt->framebuffer_stride = stride / 16;
 } else if (rsrc->bo->layout == PAN_TILED) {
 rt->format.block = MALI_MFBD_BLOCK_TILED;
-rt->framebuffer = rsrc->bo->gpu + offset;
+rt->framebuffer = base;
 rt->framebuffer_stride = stride;
 } else if (rsrc->bo->layout == PAN_AFBC) {
 rt->format.block = MALI_MFBD_BLOCK_AFBC;
 
-mali_ptr base = rsrc->bo->gpu + offset;
 unsigned header_size = rsrc->bo->slices[level].header_size;
 
 rt->framebuffer = base + header_size;
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index d8f1a9b521f..beb5f72d2d8 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -718,6 +718,24 @@ panfrost_generate_mipmap(
 return blit_res;
 }
 
+/* Computes the address to a texture at a particular slice */
+
+mali_ptr
+panfrost_get_texture_address(
+struct panfrost_resource *rsrc,
+unsigned level, unsigned face)
+{
+unsigned level_offset = rsrc->bo->slices[level].offset;
+unsigned face_offset = face * rsrc->bo->cubemap_stride;
+
+/* Lower-bit is set when sampling from colour AFBC */
+bool is_afbc = rsrc->bo->layout == PAN_AFBC;
+bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
+unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
+
+return rsrc->bo->gpu + level_offset + face_offset + afbc_bit;
+}
+
 static void
 panfrost_resource_set_stencil(struct pipe_resource *prsrc,
   struct pipe_resource *stencil)
diff --git a/src/gallium/drivers/panfrost/pan_resource.h 
b/src/gallium/drivers/panfrost/pan_resource.h
index a0bb5e962d9..220492039a5 100644
--- a/src/gallium/drivers/panfrost/pan_resource.h
+++ b/src/gallium/drivers/panfrost/pan_resource.h
@@ -120,6 +120,11 @@ pan_transfer(struct pipe_transfer *p)
return (struct panfrost_gtransfer *)p;
 }
 
+mali_ptr
+panfrost_get_texture_address(
+struct panfrost_resource *rsrc,
+unsigned level, unsigned face);
+
 void panfrost_resource_screen_init(struct panfrost_screen *screen);
 void panfrost_resource_screen_deinit(struct panfrost_screen *screen);
 
-- 
2.20.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH 12/20] panfrost: Sanity check layer

2019-06-24 Thread Alyssa Rosenzweig
It doesn't make sense to try to render to multiple array elements at
once.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_mfbd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c 
b/src/gallium/drivers/panfrost/pan_mfbd.c
index e74a8e6229f..af59497fa78 100644
--- a/src/gallium/drivers/panfrost/pan_mfbd.c
+++ b/src/gallium/drivers/panfrost/pan_mfbd.c
@@ -95,6 +95,7 @@ panfrost_mfbd_set_cbuf(
 
 unsigned level = surf->u.tex.level;
 unsigned first_layer = surf->u.tex.first_layer;
+assert(surf->u.tex.last_layer == first_layer);
 int stride = rsrc->bo->slices[level].stride;
 
 mali_ptr base = panfrost_get_texture_address(rsrc, level, first_layer);
-- 
2.20.1

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

[Mesa-dev] [PATCH 03/20] panfrost: Skip flushes only for wallpapers, not any blit

2019-06-24 Thread Alyssa Rosenzweig
We need the flush from u_blitter for a normal blit (e.g. for mipmaps);
it's only wallpaper-related blits that are special-cased.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index c4ea7175033..5a7ae6c88dc 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2180,7 +2180,7 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
 bool is_scanout = panfrost_is_scanout(ctx);
 bool has_draws = job->last_job.gpu;
 
-if (!ctx->blitter->running && (!is_scanout || has_draws)) {
+if (!ctx->wallpaper_batch && (!is_scanout || has_draws)) {
 panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
 }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 08/20] panfrost: Z/S can't be tiled

2019-06-24 Thread Alyssa Rosenzweig
As far as we know, Utgard-style tiling only works for color render
targets, not depth/stencil, so ensure we don't try to tile it (rather
than compress or plain old linear) and drive ourselves into a corner.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_resource.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index 027cd61f16d..961cecf8cf0 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -295,6 +295,9 @@ panfrost_create_bo(struct panfrost_screen *screen, const 
struct pipe_resource *t
 
 bool should_tile = is_streaming && is_texture && is_2d;
 
+/* Depth/stencil can't be tiled, only linear or AFBC */
+should_tile &= !(template->bind & PIPE_BIND_DEPTH_STENCIL);
+
 /* Set the layout appropriately */
 bo->layout = should_tile ? PAN_TILED : PAN_LINEAR;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 02/20] panfrost: Handle generate_mipmap ourselves

2019-06-24 Thread Alyssa Rosenzweig
To avoid interference with the wallpaper code, we need to do some state
tracking when generating mipmaps. In particular, we need to mark the
generated layers as invalid before generating the mipmap, so we don't
try to backblit them if they already had content.

Likewise, we need to flush both before and after generating a mipmap
since our usual set_framebuffer_state flushing isn't quite there yet.
Ideally better optimizations would save the flush but I digress.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_resource.c | 52 +
 src/gallium/drivers/panfrost/pan_screen.c   |  3 ++
 2 files changed, 55 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index 1a691a5be34..027cd61f16d 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -39,6 +39,7 @@
 #include "util/u_surface.h"
 #include "util/u_transfer.h"
 #include "util/u_transfer_helper.h"
+#include "util/u_gen_mipmap.h"
 
 #include "pan_context.h"
 #include "pan_screen.h"
@@ -663,6 +664,56 @@ panfrost_resource_get_internal_format(struct pipe_resource 
*prsrc)
 return prsrc->format;
 }
 
+static boolean
+panfrost_generate_mipmap(
+struct pipe_context *pctx,
+struct pipe_resource *prsrc,
+enum pipe_format format,
+unsigned base_level,
+unsigned last_level,
+unsigned first_layer,
+unsigned last_layer)
+{
+struct panfrost_context *ctx = pan_context(pctx);
+struct panfrost_resource *rsrc = pan_resource(prsrc);
+
+/* Generating a mipmap invalidates the written levels, so make that
+ * explicit so we don't try to wallpaper them back and end up with
+ * u_blitter recursion */
+
+assert(rsrc->bo);
+for (unsigned l = base_level + 1; l <= last_level; ++l)
+rsrc->bo->slices[l].initialized = false;
+
+/* Beyond that, we just delegate the hard stuff. We're careful to
+ * include flushes on both ends to make sure the data is really valid.
+ * We could be doing a lot better perf-wise, especially once we have
+ * reorder-type optimizations in place. But for now prioritize
+ * correctness. */
+
+struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+bool has_draws = job->last_job.gpu;
+
+if (has_draws)
+panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
+
+/* We've flushed the original buffer if needed, now trigger a blit */
+
+bool blit_res = util_gen_mipmap(
+pctx, prsrc, format, 
+base_level, last_level,
+first_layer, last_layer,
+PIPE_TEX_FILTER_LINEAR);
+
+/* If the blit was successful, flush once more. If it wasn't, well, let
+ * the state tracker deal with it. */
+
+if (blit_res)
+panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
+
+return blit_res;
+}
+
 static void
 panfrost_resource_set_stencil(struct pipe_resource *prsrc,
   struct pipe_resource *stencil)
@@ -730,6 +781,7 @@ panfrost_resource_context_init(struct pipe_context *pctx)
 pctx->surface_destroy = panfrost_surface_destroy;
 pctx->resource_copy_region = util_resource_copy_region;
 pctx->blit = panfrost_blit;
+pctx->generate_mipmap = panfrost_generate_mipmap;
 pctx->flush_resource = panfrost_flush_resource;
 pctx->invalidate_resource = panfrost_invalidate_resource;
 pctx->transfer_flush_region = u_transfer_helper_transfer_flush_region;
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index dccb0143a53..27f352c68ba 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -143,6 +143,9 @@ panfrost_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
 case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
 return 1;
 
+case PIPE_CAP_GENERATE_MIPMAP:
+return 1;
+
 case PIPE_CAP_DEPTH_CLIP_DISABLE:
 return 1;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 05/20] panfrost: Allow texelFetch for wallpaper blits

2019-06-24 Thread Alyssa Rosenzweig
We just implemented the routine; we may as well use it.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_blit.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_blit.c 
b/src/gallium/drivers/panfrost/pan_blit.c
index 5859f92f9d1..103316929ba 100644
--- a/src/gallium/drivers/panfrost/pan_blit.c
+++ b/src/gallium/drivers/panfrost/pan_blit.c
@@ -117,9 +117,7 @@ panfrost_blit_wallpaper(struct panfrost_context *ctx)
binfo.src.box.y = binfo.dst.box.y = 0;
binfo.src.box.width = binfo.dst.box.width = ctx->pipe_framebuffer.width;
binfo.src.box.height = binfo.dst.box.height = 
ctx->pipe_framebuffer.height;
-
-   /* This avoids an assert due to missing nir_texop_txb support */
-   //binfo.src.box.depth = binfo.dst.box.depth = 1;
+   binfo.src.box.depth = binfo.dst.box.depth = 1;
 
binfo.src.format = binfo.dst.format = 
ctx->pipe_framebuffer.cbufs[0]->texture->format;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 06/20] panfrost: Enable blitting

2019-06-24 Thread Alyssa Rosenzweig
Now that all the prerequisites breaking u_blitter are fixed, we can
finally hook up panfrost_blit.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_blit.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_blit.c 
b/src/gallium/drivers/panfrost/pan_blit.c
index 103316929ba..1e50448a67d 100644
--- a/src/gallium/drivers/panfrost/pan_blit.c
+++ b/src/gallium/drivers/panfrost/pan_blit.c
@@ -87,14 +87,10 @@ panfrost_blit(struct pipe_context *pipe,
  * u_blitter. We could do a little better by culling
  * vertex jobs, though. */
 
-/* TODO: Implement blitting. Commented out because u_blitter is not
- * fully integrated and creates bugs in other places. */
-#if 0
 if (panfrost_u_blitter_blit(pipe, info))
 return;
 
 fprintf(stderr, "Unhandled blit");
-#endif
 
 return;
 }
-- 
2.20.1

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

[Mesa-dev] [PATCH 04/20] panfrost/midgard: Implement texelFetch (2D only)

2019-06-24 Thread Alyssa Rosenzweig
txf instructions can result from blits, so handle them rather than
crash. Only works for 2D textures (not even 2D array texture) due to a
register allocation constraint that may not be sorted for a while.

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 41 ---
 1 file changed, 35 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index baf637d666a..e4c21c671fb 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -86,6 +86,7 @@ midgard_block_add_successor(midgard_block *block, 
midgard_block *successor)
 #define SWIZZLE_XYXX SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_X, 
COMPONENT_X)
 #define SWIZZLE_XYZX SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z, 
COMPONENT_X)
 #define SWIZZLE_XYZW SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z, 
COMPONENT_W)
+#define SWIZZLE_XYZZ SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z, 
COMPONENT_Z)
 #define SWIZZLE_XYXZ SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_X, 
COMPONENT_Z)
 #define SWIZZLE_ SWIZZLE(COMPONENT_W, COMPONENT_W, COMPONENT_W, 
COMPONENT_W)
 
@@ -1468,12 +1469,32 @@ emit_texop_native(compiler_context *ctx, nir_tex_instr 
*instr,
 ins.alu.mask = 
expand_writemask(mask_of(nr_comp));
 emit_mir_instruction(ctx, ins);
 
-/* To the hardware, z is depth, w is array
- * layer. To NIR, z is array layer for a 2D
- * array */
+if (midgard_texop == TEXTURE_OP_TEXEL_FETCH) {
+/* Texel fetch opcodes care about the
+ * values of z and w, so we actually
+ * need to spill into a second register
+ * for a texel fetch with register bias
+ * (for non-2D). TODO: Implement that
+ */
 
-if (instr->sampler_dim == GLSL_SAMPLER_DIM_2D)
-position_swizzle = SWIZZLE_XYXZ;
+assert(instr->sampler_dim == 
GLSL_SAMPLER_DIM_2D);
+
+midgard_instruction zero = 
v_mov(index, alu_src, reg);
+zero.ssa_args.inline_constant = true;
+zero.ssa_args.src1 = 
SSA_FIXED_REGISTER(REGISTER_CONSTANT);
+zero.has_constants = true;
+zero.alu.mask = ~ins.alu.mask;
+emit_mir_instruction(ctx, zero);
+
+position_swizzle = SWIZZLE_XYZZ;
+} else {
+/* To the hardware, z is depth, w is 
array
+ * layer. To NIR, z is array layer for 
a 2D
+ * array */
+
+if (instr->sampler_dim == 
GLSL_SAMPLER_DIM_2D)
+position_swizzle = 
SWIZZLE_XYXZ;
+}
 }
 
 break;
@@ -1527,7 +1548,12 @@ emit_texop_native(compiler_context *ctx, nir_tex_instr 
*instr,
 /* Setup bias/LOD if necessary. Only register mode support right now.
  * TODO: Immediate mode for performance gains */
 
-if (instr->op == nir_texop_txb || instr->op == nir_texop_txl) {
+bool needs_lod =
+instr->op == nir_texop_txb ||
+instr->op == nir_texop_txl ||
+instr->op == nir_texop_txf;
+
+if (needs_lod) {
 ins.texture.lod_register = true;
 
 midgard_tex_register_select sel = {
@@ -1570,6 +1596,9 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 case nir_texop_txl:
 emit_texop_native(ctx, instr, TEXTURE_OP_LOD);
 break;
+case nir_texop_txf:
+emit_texop_native(ctx, instr, TEXTURE_OP_TEXEL_FETCH);
+break;
 case nir_texop_txs:
 emit_sysval_read(ctx, >instr);
 break;
-- 
2.20.1

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

[Mesa-dev] [PATCH 07/20] panfrost: Enable mipmapping

2019-06-24 Thread Alyssa Rosenzweig
Now the autogeneration of mipmaps is working (via u_blitter), we can
finally enable mipmaps!

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 5a7ae6c88dc..6bda78e96dc 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -2127,7 +2127,7 @@ panfrost_create_sampler_view(
 .swizzle = panfrost_translate_swizzle_4(user_swizzle)
 };
 
-//texture_descriptor.nr_mipmap_levels = last_level - first_level;
+texture_descriptor.nr_mipmap_levels = last_level - first_level;
 
 so->hw = texture_descriptor;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 01/20] panfrost: Disable mipmapping if necessary

2019-06-24 Thread Alyssa Rosenzweig
If a mipfilter is not set, it's legal to have an incomplete mipmap; we
should handle this accordingly. An "easy way out" is to rig the LOD
clamps.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index ceea48c401a..c4ea7175033 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1776,6 +1776,22 @@ panfrost_create_sampler_state(
 .unknown2 = 1,
 };
 
+/* If necessary, we disable mipmapping in the sampler descriptor by
+ * clamping the LOD as tight as possible (from 0 to epsilon,
+ * essentially -- remember these are fixed point numbers, so
+ * epsilon=1/256) */
+
+if (cso->min_mip_filter == PIPE_TEX_MIPFILTER_NONE)
+sampler_descriptor.max_lod = sampler_descriptor.min_lod;
+
+/* Enforce that there is something in the middle by adding epsilon*/
+
+if (sampler_descriptor.min_lod == sampler_descriptor.max_lod)
+sampler_descriptor.max_lod++;
+
+/* Sanity check */
+assert(sampler_descriptor.max_lod > sampler_descriptor.min_lod);
+
 so->hw = sampler_descriptor;
 
 return so;
-- 
2.20.1

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

[Mesa-dev] [PATCH 00/20] panfrost: Mipmapping! (and other goodies)

2019-06-24 Thread Alyssa Rosenzweig
Texturing is very broken, especially anywhere mipmapping is involved,
revolving around issues blitting and bugs with AFBC.

Let's fix this :)

Several hundred dEQP-GLES2 tests are now passing; see the updated
failures list at the end of the series.

Alyssa Rosenzweig (20):
  panfrost: Disable mipmapping if necessary
  panfrost: Handle generate_mipmap ourselves
  panfrost: Skip flushes only for wallpapers, not any blit
  panfrost/midgard: Implement texelFetch (2D only)
  panfrost: Allow texelFetch for wallpaper blits
  panfrost: Enable blitting
  panfrost: Enable mipmapping
  panfrost: Z/S can't be tiled
  panfrost: Merge AFBC slab with BO backing
  panfrost: Use get_texture_address for framebuffer computations
  panfrost: Divide array_size by 6 for cubemaps
  panfrost: Sanity check layer
  panfrost: Use dedicated u_blitter context for wallpapers
  panfrost: Clamp tile coordinates before job submission
  panfrost/decode: Limit MRT blend count
  panfrost: Merge checksum buffer with main BO
  panfrost: Support (non-)seamless cube maps
  panfrost/midgard: Set magic flag for vertex textures
  panfrost/ci: Update failures list
  panfrost/midgard: Fixup NIR texture op

 .../drivers/panfrost/ci/expected-failures.txt | 304 +-
 .../drivers/panfrost/include/panfrost-job.h   |   5 +-
 .../panfrost/midgard/midgard_compile.c|  62 +++-
 src/gallium/drivers/panfrost/pan_afbc.c   |  43 +--
 src/gallium/drivers/panfrost/pan_blit.c   |  48 ++-
 src/gallium/drivers/panfrost/pan_context.c|  78 ++---
 src/gallium/drivers/panfrost/pan_context.h|   8 +
 src/gallium/drivers/panfrost/pan_drm.c|   3 -
 src/gallium/drivers/panfrost/pan_fragment.c   |  20 ++
 src/gallium/drivers/panfrost/pan_mfbd.c   |  48 +--
 src/gallium/drivers/panfrost/pan_resource.c   | 160 +++--
 src/gallium/drivers/panfrost/pan_resource.h   |  34 +-
 src/gallium/drivers/panfrost/pan_screen.c |   3 +
 .../drivers/panfrost/pandecode/decode.c   |  13 +-
 14 files changed, 342 insertions(+), 487 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [Bug 110970] [RADV] texelFetch not working when multiple texel buffer inputs are bound

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110970

kd-11  changed:

   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 110970] [RADV] texelFetch not working when multiple texel buffer inputs are bound

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110970

--- Comment #2 from kd-11  ---
Confirmed. Switched to padoka drivers which are llvm9 and the issue is not
present.

-- 
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] radv: clear CMASK layers instead of the whole buffer on GFX8

2019-06-24 Thread Samuel Pitoiset
This reduces the size of fill operations needed to clear CMASK
for layered color textures.

GFX9 unsupported for now.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_surface.c  |  3 ++-
 src/amd/common/ac_surface.h  |  1 +
 src/amd/vulkan/radv_cmd_buffer.c |  8 ---
 src/amd/vulkan/radv_image.c  |  1 +
 src/amd/vulkan/radv_meta.h   |  3 ++-
 src/amd/vulkan/radv_meta_clear.c | 36 
 src/amd/vulkan/radv_private.h|  1 +
 7 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 03d3505df53..24e2a01bfec 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -609,7 +609,8 @@ static void ac_compute_cmask(const struct radeon_info *info,
num_layers = config->info.array_size;
 
surf->cmask_alignment = MAX2(256, base_align);
-   surf->cmask_size = align(slice_bytes, base_align) * num_layers;
+   surf->cmask_slice_size = align(slice_bytes, base_align);
+   surf->cmask_size = surf->cmask_slice_size * num_layers;
 }
 
 /**
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index aa93e917270..31623634936 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -219,6 +219,7 @@ struct radeon_surf {
 uint32_thtile_alignment;
 
 uint32_tcmask_size;
+uint32_tcmask_slice_size;
 uint32_tcmask_alignment;
 
 union {
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 419be5842e8..0526e2719af 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4892,14 +4892,16 @@ static void radv_handle_depth_image_transition(struct 
radv_cmd_buffer *cmd_buffe
 }
 
 static void radv_initialise_cmask(struct radv_cmd_buffer *cmd_buffer,
- struct radv_image *image, uint32_t value)
+ struct radv_image *image,
+ const VkImageSubresourceRange *range,
+ uint32_t value)
 {
struct radv_cmd_state *state = _buffer->state;
 
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 
-   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, value);
+   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, range, value);
 
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 }
@@ -5007,7 +5009,7 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
value = 0xu;
}
 
-   radv_initialise_cmask(cmd_buffer, image, value);
+   radv_initialise_cmask(cmd_buffer, image, range, value);
}
 
if (radv_image_has_fmask(image)) {
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index ca007d1dd65..4099c57aa85 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -942,6 +942,7 @@ radv_image_get_cmask_info(struct radv_device *device,
 
out->slice_tile_max = 
image->planes[0].surface.u.legacy.cmask_slice_tile_max;
out->alignment = image->planes[0].surface.cmask_alignment;
+   out->slice_size = image->planes[0].surface.cmask_slice_size;
out->size = image->planes[0].surface.cmask_size;
 }
 
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 30981f00790..c3d37bb07d2 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -212,7 +212,8 @@ void radv_decompress_resolve_src(struct radv_cmd_buffer 
*cmd_buffer,
 const VkImageResolve *regions);
 
 uint32_t radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
- struct radv_image *image, uint32_t value);
+ struct radv_image *image,
+ const VkImageSubresourceRange *range, uint32_t value);
 uint32_t radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
  struct radv_image *image,
  const VkImageSubresourceRange *range, uint32_t value);
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index 0a9d9e76ca4..4d569729dda 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1326,11 +1326,21 @@ radv_get_cmask_fast_clear_value(const struct radv_image 
*image)
 
 uint32_t
 radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
-struct radv_image *image, uint32_t value)
+struct radv_image *image,
+const VkImageSubresourceRange *range, uint32_t value)
 {
-   return radv_fill_buffer(cmd_buffer, image->bo,
-   image->offset + image->cmask.offset,
-   image->cmask.size, value);
+  

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Elie Tournier
Hi there,

Great topic. For the past few days, I was looking at a CI for Mesa:
https://gitlab.freedesktop.org/hopetech/tracie
OK, it's in a very very alpha stage. ;)

My idea was to use apitrace to dump and replay traces then compare images with 
reference
images or images dump the previous week.
Apitrace was a good choice for a "correctness CI", maybe not for the 
"performance CI".

@eric Out of curiosity, did you looked at apitrace or did you go straight with 
renderdoc?

I add below some comments based on what I learned playing with the CI.


On Sat, Jun 22, 2019 at 10:59:34AM -0700, Rob Clark wrote:
> On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:
> >
> > Hey folks, I wanted to show you this follow-on to shader-db I've been
> > working on:
> >
> > https://gitlab.freedesktop.org/anholt/renderdoc-traces
> >
> > For x86 development I've got a collection of ad-hoc scripts to capture
> > FPS numbers from various moderately interesting open source apps so I
> > could compare-perf them.  I was only looking at specific apps when they
> > seemed relevant, so it would be easy to miss regressions.
> >
> > Starting work on freedreno, one of the first questions I ran into was
> > "does this change to the command stream make the driver faster?".  I
> > don't have my old set of apps on my debian ARM systems, and even less so
> > for Chrome OS.  Ultimately, users will be judging us based on web
> > browser and android app performance, not whatever I've got laying around
> > on my debian system.  And, I'd love to fix that "I ignore apps unless I
> > think of them" thing.
> >
> > So, I've used renderdoc to capture some traces from Android apps.  With
> > an unlocked phone, it's pretty easy.  Tossing those in a repo (not
> > shared here), I can then run driver changes past them to see what
> > happens.  See
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
> > results.
> >
> > Where is this repo going from here?
> >
> > - I add a runner for doing frame-to-frame consistency tests.  We could
> >   catch UB in a lot of circumstances by replaying a few times and making
> >   sure that results are consistent.  Comparing frames between drivers
> >   might also be interesting, though for that you would need human
> >   validation since pixel values and pixels lit will change on many
> >   shader optimization changes.
Comparing frames between drivers is hard. I try comparing LLVMpipe, sotfpipe 
and i965.
They all produce different frames.
For the human validation, it's sadly hard to avoid. One of the idea Erik come 
of with
was to use a mask.
I think we should first focus on comparing frame from the same driver and 
extend later.
The subject is hard enough. ;)
> >
> > - Need to collect more workloads for the public repo:
I would be happy to help here.
We should create a list of FOSS games/apps to dump based on there OGL 
requirement.
> >
> >   - I've tried to capture webgl on Chrome and Firefox on Linux with no
> > luck. WebGL on ff is supposed to work under apitrace, maybe I could
> > do that and then replay on top of renderdoc to capture.
> 
> perhaps worth a try capturing these on android?
> 
> I have managed to apitrace chromium-browser in the past.. it ends up a
> bit weird because there are multiple contexts, but apitrace has
> managed to replay them.  Maybe the multiple ctx thing is confusing
> renderdoc?
> 
> (tbh I've not really played w/ renderdoc yet.. I should probably do so..)
> 
> >   - Mozilla folks tell me that firefox's WebRender display lists can be
> > captured in browser and then replayed from the WR repo under
> > apitrace or rendredoc.
> >
> >   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
> > it wouldn't play the demo under renderdoc.
> >
> >   Do you have some apps that should be represented here?
> >
> > - Add microbenchmarks?  Looks like it would be pretty easy to grab
> >   piglit drawoverhead results, not using renderdoc.  Capturing from
> >   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
> >   excited about (Do we do different configs in those apps?  Then we need
> >   config infrastructure.  Ugh).
> >
> > - I should probably add an estimate of "does this overall improve or
> >   hurt perf?"  Yay doing more stats.
Sure. Sadly most benchmark I tryed were unstable performancewise.
Cache change result a lot. Well, you already know it.
> >
> > - I'd love to drop scipy.  I only need it for stats.t.ppf, but it
> >   prevents me from running run.py directly on my targets.
> 
> thoughts about adding amd_perfcntr/etc support?  I guess some of the
> perfcntrs we have perhaps want some post-processing to turn into
> usuable numbers, and plenty of them we don't know much about what they
> are other than the name.  But some of them are easy enough to
> understand (like # of fs ALU cycles, etc), and being able to compare
> that before/after shader optimizations seems useful.
> 
> Also, it would be nice to have a 

[Mesa-dev] [Bug 109757] Rename src/vulkan/overlay-layer/README to src/vulkan/overlay-layer/README.md

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109757

Eric Engestrom  changed:

   What|Removed |Added

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

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

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-24 Thread Eero Tamminen

Hi,

On 20.6.2019 22.26, Eric Anholt wrote:

Hey folks, I wanted to show you this follow-on to shader-db I've been
working on:

https://gitlab.freedesktop.org/anholt/renderdoc-traces

For x86 development I've got a collection of ad-hoc scripts to capture
FPS numbers from various moderately interesting open source apps so I
could compare-perf them.  I was only looking at specific apps when they
seemed relevant, so it would be easy to miss regressions.

Starting work on freedreno, one of the first questions I ran into was
"does this change to the command stream make the driver faster?".  I
don't have my old set of apps on my debian ARM systems, and even less so
for Chrome OS.  Ultimately, users will be judging us based on web
browser and android app performance, not whatever I've got laying around
on my debian system.  And, I'd love to fix that "I ignore apps unless I
think of them" thing.

So, I've used renderdoc to capture some traces from Android apps.  With
an unlocked phone, it's pretty easy.  Tossing those in a repo (not
shared here), I can then run driver changes past them to see what
happens.  See
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
results.

Where is this repo going from here?

- I add a runner for doing frame-to-frame consistency tests.  We could
   catch UB in a lot of circumstances by replaying a few times and making
   sure that results are consistent.  Comparing frames between drivers
   might also be interesting, though for that you would need human
   validation since pixel values and pixels lit will change on many
   shader optimization changes.


When bisecting, ezBench[1] lists all perf and rendering changes, and
provides visual diff for *all* the rendering changes.  Without latter,
something like this would have been really hard to notice & bisect:
https://bugs.freedesktop.org/show_bug.cgi?id=103197

Or something like this in a moving part of a long benchmark:
https://bugs.freedesktop.org/attachment.cgi?id=134878
https://bugs.freedesktop.org/attachment.cgi?id=134879

As to providing info on how likely driver is to be rendering something
wrong / differently instead of differences being just due to accuracy /
calculations order... Maybe something like PSNR would be useful:
https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio
?

- Eero

[1] https://github.com/freedesktop/ezbench



- Need to collect more workloads for the public repo:

   - I've tried to capture webgl on Chrome and Firefox on Linux with no
 luck. WebGL on ff is supposed to work under apitrace, maybe I could
 do that and then replay on top of renderdoc to capture.

   - Mozilla folks tell me that firefox's WebRender display lists can be
 captured in browser and then replayed from the WR repo under
 apitrace or rendredoc.

   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
 it wouldn't play the demo under renderdoc.

   Do you have some apps that should be represented here?

- Add microbenchmarks?  Looks like it would be pretty easy to grab
   piglit drawoverhead results, not using renderdoc.  Capturing from
   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
   excited about (Do we do different configs in those apps?  Then we need
   config infrastructure.  Ugh).

- I should probably add an estimate of "does this overall improve or
   hurt perf?"  Yay doing more stats.

- I'd love to drop scipy.  I only need it for stats.t.ppf, but it
   prevents me from running run.py directly on my targets.


___
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] panfrost: Maintain a whitelist of supported GPU's

2019-06-24 Thread Alyssa Rosenzweig
> +if (!supported_gpu) {
> +fprintf(stderr, "Unsupported GPU\n");
> +free(screen);
> +return NULL;
> +}

End users may see this. Is it better to silently fail or to print a
message that Panfrost isn't loaded (either way, the swrast would
probably load in its place).

> +static const panfrost_supported_gpus[] = {
> +0x0750,
> +0x0820,
> +0x0860
> +};

Please add a comment to each line with the commercial name of the
respective GPU. (e.g. "/* Mali T760 */")


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

[Mesa-dev] [PATCH 2/2] radv: always initialize levels without DCC as fully expanded

2019-06-24 Thread Samuel Pitoiset
This fixes a rendering issue with RoTR/DXVK.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 9b4d4528028..733795eb1a4 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4960,26 +4960,24 @@ void radv_initialize_dcc(struct radv_cmd_buffer 
*cmd_buffer,
 * support fast clears and we have to initialize them as "fully
 * expanded".
 */
-   if (image->planes[0].surface.num_dcc_levels > 1) {
-   /* Compute the size of all fast clearable DCC levels. */
-   for (unsigned i = 0; i < 
image->planes[0].surface.num_dcc_levels; i++) {
-   struct legacy_surf_level *surf_level =
-   
>planes[0].surface.u.legacy.level[i];
+   /* Compute the size of all fast clearable DCC levels. */
+   for (unsigned i = 0; i < 
image->planes[0].surface.num_dcc_levels; i++) {
+   struct legacy_surf_level *surf_level =
+   >planes[0].surface.u.legacy.level[i];
 
-   if (!surf_level->dcc_fast_clear_size)
-   break;
+   if (!surf_level->dcc_fast_clear_size)
+   break;
 
-   size = surf_level->dcc_offset + 
surf_level->dcc_fast_clear_size;
-   }
+   size = surf_level->dcc_offset + 
surf_level->dcc_fast_clear_size;
+   }
 
-   /* Initialize the mipmap levels without DCC. */
-   if (size != image->planes[0].surface.dcc_size) {
-   state->flush_bits |=
-   radv_fill_buffer(cmd_buffer, image->bo,
-image->offset + 
image->dcc_offset + size,
-
image->planes[0].surface.dcc_size - size,
-0x);
-   }
+   /* Initialize the mipmap levels without DCC. */
+   if (size != image->planes[0].surface.dcc_size) {
+   state->flush_bits |=
+   radv_fill_buffer(cmd_buffer, image->bo,
+image->offset + 
image->dcc_offset + size,
+
image->planes[0].surface.dcc_size - size,
+0x);
}
}
 
-- 
2.22.0

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

[Mesa-dev] [PATCH 1/2] radv: fix setting CB_DCC_BASE if the base level doesn't enable DCC

2019-06-24 Thread Samuel Pitoiset
CB_DCC_BASE should be 0 if no DCC.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 26b31cff9f1..dc5de683050 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4342,15 +4342,16 @@ radv_initialise_color_surface(struct radv_device 
*device,
va += iview->image->cmask.offset;
cb->cb_color_cmask = va >> 8;
 
-   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
-   va += iview->image->dcc_offset;
+   if (radv_dcc_enabled(iview->image, iview->base_mip)) {
+   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
+   va += iview->image->dcc_offset;
 
-   if (radv_dcc_enabled(iview->image, iview->base_mip) &&
-   device->physical_device->rad_info.chip_class <= GFX8)
-   va += plane->surface.u.legacy.level[iview->base_mip].dcc_offset;
+   if (device->physical_device->rad_info.chip_class <= GFX8)
+   va += 
plane->surface.u.legacy.level[iview->base_mip].dcc_offset;
 
-   cb->cb_dcc_base = va >> 8;
-   cb->cb_dcc_base |= surf->tile_swizzle;
+   cb->cb_dcc_base = va >> 8;
+   cb->cb_dcc_base |= surf->tile_swizzle;
+   }
 
uint32_t max_slice = radv_surface_max_layer_count(iview) - 1;
cb->cb_color_view = S_028C6C_SLICE_START(iview->base_layer) |
-- 
2.22.0

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

[Mesa-dev] [PATCH] panfrost: Maintain a whitelist of supported GPU's

2019-06-24 Thread Rohan Garg
Maintain a list of panfrost supported GPU's and exit early when
running on a unsupported GPU.

Signed-off-by: Rohan Garg 
---
 src/gallium/drivers/panfrost/pan_screen.c | 15 +++
 src/gallium/drivers/panfrost/pan_screen.h |  6 ++
 2 files changed, 21 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index dccb0143a53..a0c940d4c30 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -563,6 +563,8 @@ panfrost_screen_get_compiler_options(struct pipe_screen 
*pscreen,
 struct pipe_screen *
 panfrost_create_screen(int fd, struct renderonly *ro)
 {
+unsigned gpu_id;
+bool supported_gpu = false;
 struct panfrost_screen *screen = rzalloc(NULL, struct panfrost_screen);
 
pan_debug = debug_get_option_pan_debug();
@@ -581,6 +583,19 @@ panfrost_create_screen(int fd, struct renderonly *ro)
 
 screen->fd = fd;
 
+gpu_id = panfrost_drm_query_gpu_version(screen);
+
+for (int i = 0; i < ARRAY_SIZE(panfrost_supported_gpus); i++) {
+if (panfrost_supported_gpus[i] == gpu_id)
+supported_gpu = true;
+}
+
+if (!supported_gpu) {
+fprintf(stderr, "Unsupported GPU\n");
+free(screen);
+return NULL;
+}
+
 if (pan_debug & PAN_DBG_TRACE)
 pandecode_initialize();
 
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 4907bd4395f..8c8915d0ad5 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -46,6 +46,12 @@ struct panfrost_screen;
 #define PAN_ALLOCATE_INVISIBLE (1 << 2)
 #define PAN_ALLOCATE_COHERENT_LOCAL (1 << 3)
 
+static const panfrost_supported_gpus[] = {
+0x0750,
+0x0820,
+0x0860
+};
+
 struct panfrost_screen {
 struct pipe_screen base;
 int fd;
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 1/3] panfrost: Print a backtrace if there is one

2019-06-24 Thread Tomeu Vizoso
On Mon, 24 Jun 2019 at 12:00, Rohan Garg  wrote:
>
> > I think assertions should be limited to the most basic of sanity checks,
> > and the other asserts replaced by proper error handling.
>
> So, should I leave it as is and let us hit assertions that we fix?

Sorry, can you rephrase?

Thanks,

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

[Mesa-dev] [Bug 110970] [RADV] texelFetch not working when multiple texel buffer inputs are bound

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110970

--- Comment #1 from Philip Rebohle  ---
This only seems to happen with LLVM 8. The capture replays fine for me with
latest LLVM 9.0-git.

-- 
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] radv: clear FMASK layers instead of the whole buffer on GFX8

2019-06-24 Thread Samuel Pitoiset
This reduces the size of fill operations needed to clear FMASK
for layered color textures.

GFX9 unsupported for now.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_surface.c |  1 +
 src/amd/common/ac_surface.h |  1 +
 src/amd/vulkan/radv_cmd_buffer.c|  7 ---
 src/amd/vulkan/radv_image.c |  1 +
 src/amd/vulkan/radv_meta.h  |  3 ++-
 src/amd/vulkan/radv_meta_clear.c| 22 ++
 src/amd/vulkan/radv_meta_fmask_expand.c |  2 +-
 src/amd/vulkan/radv_private.h   |  4 +++-
 8 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 7b86cb1e1f2..03d3505df53 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -953,6 +953,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
surf->u.legacy.fmask.tiling_index = fout.tileIndex;
surf->u.legacy.fmask.bankh = fout.pTileInfo->bankHeight;
surf->u.legacy.fmask.pitch_in_pixels = fout.pitch;
+   surf->u.legacy.fmask.slice_size = fout.sliceSize;
 
/* Compute tile swizzle for FMASK. */
if (config->info.fmask_surf_index &&
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 49f68f4fc92..aa93e917270 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -86,6 +86,7 @@ struct legacy_surf_fmask {
 uint8_t tiling_index;/* max 31 */
 uint8_t bankh;   /* max 8 */
 uint16_t pitch_in_pixels;
+uint64_t slice_size;
 };
 
 struct legacy_surf_layout {
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 9b4d4528028..419be5842e8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4905,7 +4905,8 @@ static void radv_initialise_cmask(struct radv_cmd_buffer 
*cmd_buffer,
 }
 
 void radv_initialize_fmask(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_image *image)
+  struct radv_image *image,
+  const VkImageSubresourceRange *range)
 {
struct radv_cmd_state *state = _buffer->state;
static const uint32_t fmask_clear_values[4] = {
@@ -4920,7 +4921,7 @@ void radv_initialize_fmask(struct radv_cmd_buffer 
*cmd_buffer,
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
 RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 
-   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, value);
+   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, range, value);
 
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 }
@@ -5010,7 +5011,7 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
}
 
if (radv_image_has_fmask(image)) {
-   radv_initialize_fmask(cmd_buffer, image);
+   radv_initialize_fmask(cmd_buffer, image, range);
}
 
if (radv_dcc_enabled(image, range->baseMipLevel)) {
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index cf3f0eb1d55..ca007d1dd65 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -907,6 +907,7 @@ radv_image_get_fmask_info(struct radv_device *device,
out->slice_tile_max = 
image->planes[0].surface.u.legacy.fmask.slice_tile_max;
out->tile_mode_index = 
image->planes[0].surface.u.legacy.fmask.tiling_index;
out->pitch_in_pixels = 
image->planes[0].surface.u.legacy.fmask.pitch_in_pixels;
+   out->slice_size = image->planes[0].surface.u.legacy.fmask.slice_size;
out->bank_height = image->planes[0].surface.u.legacy.fmask.bankh;
out->tile_swizzle = image->planes[0].surface.fmask_tile_swizzle;
out->alignment = image->planes[0].surface.fmask_alignment;
diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
index 5880064ff30..30981f00790 100644
--- a/src/amd/vulkan/radv_meta.h
+++ b/src/amd/vulkan/radv_meta.h
@@ -214,7 +214,8 @@ void radv_decompress_resolve_src(struct radv_cmd_buffer 
*cmd_buffer,
 uint32_t radv_clear_cmask(struct radv_cmd_buffer *cmd_buffer,
  struct radv_image *image, uint32_t value);
 uint32_t radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
- struct radv_image *image, uint32_t value);
+ struct radv_image *image,
+ const VkImageSubresourceRange *range, uint32_t value);
 uint32_t radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
const VkImageSubresourceRange *range, uint32_t value);
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index c3def76e957..0a9d9e76ca4 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1336,11 +1336,25 @@ radv_clear_cmask(struct 

Re: [Mesa-dev] [PATCH 1/3] panfrost: Print a backtrace if there is one

2019-06-24 Thread Rohan Garg
> I think assertions should be limited to the most basic of sanity checks,
> and the other asserts replaced by proper error handling.

So, should I leave it as is and let us hit assertions that we fix?

Cheers
Rohan Garg

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

Re: [Mesa-dev] [PATCH v2] radv: implement VK_EXT_sample_locations

2019-06-24 Thread Samuel Pitoiset

Thanks for the head-up Marek, I will update once I have hardware access.

On 6/21/19 7:33 PM, Marek Olšák wrote:
Gfx10 remembers sample positions in compressed Z/S memory, so the hw 
doesn't need the decompress pass for shader loads.


Marek

On Wed, May 22, 2019 at 4:20 PM Marek Olšák > wrote:


The depth decompress pass needs to know the sample locations.

If shader loads read from compressed depth, the texture hardware
will always use the standard locations for decompression.

Marek

On Tue, May 21, 2019 at 8:17 PM Bas Nieuwenhuizen
mailto:b...@basnieuwenhuizen.nl>> wrote:

So this does not seem to use the sample locations during
layout transitions?

AFAIK those are needed for e.g. HTILE decompression as it is
based on
equations somehow.

On Thu, May 16, 2019 at 11:51 AM Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>>
wrote:
>
> Basically, this extension allows applications to use custom
> sample locations. It doesn't support variable sample locations
> during subpass. Note that we don't have to upload the user
> sample locations because the spec doesn't allow this.
>
> Only enabled on VI+ because it's untested on older chips.
>
> v2: - change sampleLocationCoordinateRange[1] to 0.9375
>     - compute and emit PA_SC_CENTROID_PRIORITY_{0,1}
>     - rebased on top of master
>     - some cleanups
>
> Signed-off-by: Samuel Pitoiset mailto:samuel.pitoi...@gmail.com>>
> ---
>  src/amd/vulkan/radv_cmd_buffer.c  | 223
++
>  src/amd/vulkan/radv_device.c      |  27 
>  src/amd/vulkan/radv_extensions.py |   1 +
>  src/amd/vulkan/radv_pipeline.c    |  30 
>  src/amd/vulkan/radv_private.h     |  26 +++-
>  5 files changed, 300 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
b/src/amd/vulkan/radv_cmd_buffer.c
> index 4f592bc7f68..fb79c1c6713 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -105,6 +105,7 @@ radv_bind_dynamic_state(struct
radv_cmd_buffer *cmd_buffer,
>         dest->viewport.count = src->viewport.count;
>         dest->scissor.count = src->scissor.count;
>         dest->discard_rectangle.count =
src->discard_rectangle.count;
> +       dest->sample_location.count =
src->sample_location.count;
>
>         if (copy_mask & RADV_DYNAMIC_VIEWPORT) {
>                 if (memcmp(>viewport.viewports,
>viewport.viewports,
> @@ -192,6 +193,22 @@ radv_bind_dynamic_state(struct
radv_cmd_buffer *cmd_buffer,
>                 }
>         }
>
> +       if (copy_mask & RADV_DYNAMIC_SAMPLE_LOCATIONS) {
> +               if (dest->sample_location.per_pixel !=
src->sample_location.per_pixel ||
> +  dest->sample_location.grid_size.width !=
src->sample_location.grid_size.width ||
> +  dest->sample_location.grid_size.height !=
src->sample_location.grid_size.height ||
> +  memcmp(>sample_location.locations,
> + >sample_location.locations,
> + src->sample_location.count * sizeof(VkSampleLocationEXT))) {
> +  dest->sample_location.per_pixel =
src->sample_location.per_pixel;
> +  dest->sample_location.grid_size =
src->sample_location.grid_size;
> +  typed_memcpy(dest->sample_location.locations,
> + src->sample_location.locations,
> + src->sample_location.count);
> +                       dest_mask |=
RADV_DYNAMIC_SAMPLE_LOCATIONS;
> +               }
> +       }
> +
>         cmd_buffer->state.dirty |= dest_mask;
>  }
>
> @@ -632,6 +649,190 @@ radv_emit_descriptor_pointers(struct
radv_cmd_buffer *cmd_buffer,
>         }
>  }
>
> +/**
> + * Convert the user sample locations to hardware sample
locations (the values
> + * that will be emitted by PA_SC_AA_SAMPLE_LOCS_PIXEL_*).
> + */
> +static void
> +radv_convert_user_sample_locs(struct
radv_sample_locations_state *state,
> +                             uint32_t x, uint32_t y,
VkOffset2D *sample_locs)
> +{
> +       uint32_t x_offset = x % state->grid_size.width;
> +       uint32_t y_offset = y % state->grid_size.height;
> +       uint32_t num_samples = (uint32_t)state->per_pixel;
> +       VkSampleLocationEXT *user_locs;
> +       uint32_t pixel_offset;
> +
> +       pixel_offset = (x_offset + y_offset *

[Mesa-dev] [Bug 105171] performance regression (3x slower) running glamor with PutImage workload (radeonsi)

2019-06-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105171

Michel Dänzer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #21 from Michel Dänzer  ---
Let's assume this is the same as bug 110781, which is now fixed.

*** This bug has been marked as a duplicate of bug 110781 ***

-- 
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] radv: add support for VK_AMD_buffer_marker

2019-06-24 Thread Bas Nieuwenhuizen
R-b

On Fri, Jun 21, 2019, 4:14 PM Samuel Pitoiset 
wrote:

> This simple extension might be useful for debugging purposes.
> GAPID has support for it.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>
> A simple crucible test:
> https://gitlab.freedesktop.org/mesa/crucible/merge_requests/47
>
>  src/amd/vulkan/radv_cmd_buffer.c  | 35 +++
>  src/amd/vulkan/radv_extensions.py |  1 +
>  2 files changed, 36 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 9b4d4528028..215ccced144 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -5716,3 +5716,38 @@ void radv_CmdDrawIndirectByteCountEXT(
>
> radv_draw(cmd_buffer, );
>  }
> +
> +/* VK_AMD_buffer_marker */
> +void radv_CmdWriteBufferMarkerAMD(
> +VkCommandBuffer commandBuffer,
> +VkPipelineStageFlagBits pipelineStage,
> +VkBufferdstBuffer,
> +VkDeviceSizedstOffset,
> +uint32_tmarker)
> +{
> +   RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
> +   RADV_FROM_HANDLE(radv_buffer, buffer, dstBuffer);
> +   struct radeon_cmdbuf *cs = cmd_buffer->cs;
> +   uint64_t va = radv_buffer_get_va(buffer->bo) + dstOffset;
> +
> +   si_emit_cache_flush(cmd_buffer);
> +
> +   if (!(pipelineStage & ~VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT)) {
> +   radeon_emit(cs, PKT3(PKT3_COPY_DATA, 4, 0));
> +   radeon_emit(cs, COPY_DATA_SRC_SEL(COPY_DATA_IMM) |
> +   COPY_DATA_DST_SEL(COPY_DATA_DST_MEM) |
> +   COPY_DATA_WR_CONFIRM);
> +   radeon_emit(cs, marker);
> +   radeon_emit(cs, 0);
> +   radeon_emit(cs, va);
> +   radeon_emit(cs, va >> 32);
> +   } else {
> +   si_cs_emit_write_event_eop(cs,
> +
> cmd_buffer->device->physical_device->rad_info.chip_class,
> +
> radv_cmd_buffer_uses_mec(cmd_buffer),
> +  V_028A90_BOTTOM_OF_PIPE_TS, 0,
> +  EOP_DATA_SEL_VALUE_32BIT,
> +  va, marker,
> +  cmd_buffer->gfx9_eop_bug_va);
> +   }
> +}
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index b676cb8b8e2..1708173817b 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -130,6 +130,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_transform_feedback',1, True),
>  Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>  Extension('VK_EXT_ycbcr_image_arrays',1, True),
> +Extension('VK_AMD_buffer_marker', 1, True),
>  Extension('VK_AMD_draw_indirect_count',   1, True),
>  Extension('VK_AMD_gcn_shader',1, True),
>  Extension('VK_AMD_gpu_shader_half_float', 1,
> 'device->rad_info.chip_class >= GFX8 && HAVE_LLVM >= 0x0800'),
> --
> 2.22.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

Re: [Mesa-dev] about building radeonsi drivers with meson

2019-06-24 Thread Eric Engestrom
On 2019-06-24 at 08:21, cloudwin  wrote:
> Hi
> I used to build radeonsi drivers, like radeonsi_dri.so and 
> radeonsi_drv_video.so by autogen in old version mesa, but when I switch 
> to meson which is the only way to build mesa driver now, I find 
> radeonsi_dri.so can not be generated, I used this to build drivers:
>  meson -Dgallium-drivers=radeonsi ./build
> cd ./build
> ninja
> 
> but only ./src/gallium/targets/dri/libgallium_dri.so and 
> ./src/gallium/targets/va/libgallium_drv_video.so are generated, how can 
> I get radeonsi_dri.so and radeonsi_drv_video.so with meson?
> Thanks!

Hi!

You need to install the driver to get the various *_dri.so links.

Run `ninja install` to do so, with `export DESTDIR=/path/to/local/install` first
if you don't want to overwrite your system install.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] about building radeonsi drivers with meson

2019-06-24 Thread cloudwin
Hi
I used to build radeonsi drivers, like radeonsi_dri.so and 
radeonsi_drv_video.so by autogen in old version mesa, but when I switch to 
meson which is the only way to build mesa driver now, I find radeonsi_dri.so 
can not be generated, I used this to build drivers:
 meson -Dgallium-drivers=radeonsi ./build
cd ./build
ninja


but only ./src/gallium/targets/dri/libgallium_dri.so and 
./src/gallium/targets/va/libgallium_drv_video.so are generated, how can I get 
radeonsi_dri.so and radeonsi_drv_video.so with meson?
Thanks!___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] about building radeonsi drivers with meson

2019-06-24 Thread cloudwin
Hi
I used to build radeonsi drivers, like radeonsi_dri.so and 
radeonsi_drv_video.so by autogen in old version mesa, but when I switch to 
meson which is the only way to build mesa driver now, I find radeonsi_dri.so 
can not be generated, I used this to build drivers:
 meson -Dgallium-drivers=radeonsi ./build
cd ./build
ninja


but only ./src/gallium/targets/dri/libgallium_dri.so and 
./src/gallium/targets/va/libgallium_drv_video.so are generated, how can I get 
radeonsi_dri.so and radeonsi_drv_video.so with meson?
Thanks!___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] android: virgl: fix libmesa_virgil_common build and dependencies

2019-06-24 Thread Chih-Wei Huang
Mauro Rossi  於 2019年6月15日 週六 下午1:39寫道:
>
> Fixes the following building errors and resolves Bug 110922
> Fixes gallium_dri target missing symbols at linking.
>
> external/mesa/src/gallium/winsys/virgl/drm/Android.mk:
> error: libmesa_winsys_virgl (STATIC_LIBRARIES android-x86_64) missing 
> libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
> ...
> external/mesa/src/gallium/winsys/virgl/vtest/Android.mk:
> error: libmesa_winsys_virgl_vtest (STATIC_LIBRARIES android-x86_64) missing 
> libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
> ...
> build/core/main.mk:728: error: exiting from previous errors.
>
> In file included from 
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c:34:
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
> fatal error: 'virgl_resource_cache.h' file not found
>  ^~~~
> 1 error generated.
>
> In file included from 
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c:32:
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
> fatal error: 'virgl_resource_cache.h' file not found
> #include "virgl_resource_cache.h"
>  ^~~~
> 1 error generated.
>
> Fixes: b18f09a ("virgl: Introduce virgl_resource_cache")
> Signed-off-by: Mauro Rossi 
> ---
>  src/gallium/Android.mk| 2 +-
>  src/gallium/drivers/virgl/Android.mk  | 2 +-
>  src/gallium/winsys/virgl/drm/Android.mk   | 2 ++
>  src/gallium/winsys/virgl/vtest/Android.mk | 2 ++
>  4 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
> index 3a3f042c7a..37e923c225 100644
> --- a/src/gallium/Android.mk
> +++ b/src/gallium/Android.mk
> @@ -43,7 +43,7 @@ SUBDIRS += winsys/radeon/drm drivers/r300
>  SUBDIRS += winsys/radeon/drm drivers/r600
>  SUBDIRS += winsys/radeon/drm winsys/amdgpu/drm drivers/radeonsi
>  SUBDIRS += winsys/vc4/drm drivers/vc4
> -SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
> +SUBDIRS += winsys/virgl/common winsys/virgl/drm winsys/virgl/vtest 
> drivers/virgl
>  SUBDIRS += winsys/svga/drm drivers/svga
>  SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
>  SUBDIRS += state_trackers/dri
> diff --git a/src/gallium/drivers/virgl/Android.mk 
> b/src/gallium/drivers/virgl/Android.mk
> index 0067dfa702..a6fe53fbe9 100644
> --- a/src/gallium/drivers/virgl/Android.mk
> +++ b/src/gallium/drivers/virgl/Android.mk
> @@ -35,5 +35,5 @@ include $(BUILD_STATIC_LIBRARY)
>
>  ifneq ($(HAVE_GALLIUM_VIRGL),)
>  GALLIUM_TARGET_DRIVERS += virtio_gpu
> -$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl 
> libmesa_winsys_virgl_vtest)
> +$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl_common 
> libmesa_winsys_virgl libmesa_winsys_virgl_vtest)
>  endif
> diff --git a/src/gallium/winsys/virgl/drm/Android.mk 
> b/src/gallium/winsys/virgl/drm/Android.mk
> index 5e2500774e..398a7645bc 100644
> --- a/src/gallium/winsys/virgl/drm/Android.mk
> +++ b/src/gallium/winsys/virgl/drm/Android.mk
> @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
>
>  LOCAL_SRC_FILES := $(C_SOURCES)
>
> +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common

This should be unnecessary.
The include path should be imported automatically.
However, there is a typo in Android.mk of libmesa_winsys_virgl_common
that prevents it from working. We should fix the typo instead of adding this.
Will send a patch later.

> +
>  LOCAL_MODULE := libmesa_winsys_virgl
>
>  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
> diff --git a/src/gallium/winsys/virgl/vtest/Android.mk 
> b/src/gallium/winsys/virgl/vtest/Android.mk
> index 5b33f67711..6d35223c8e 100644
> --- a/src/gallium/winsys/virgl/vtest/Android.mk
> +++ b/src/gallium/winsys/virgl/vtest/Android.mk
> @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
>
>  LOCAL_SRC_FILES := $(C_SOURCES)
>
> +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common

Ditto

> +
>  LOCAL_MODULE := libmesa_winsys_virgl_vtest
>
>  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
> --



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] android: fix typo LOCAL_EXPORT_C_INCLUDES

2019-06-24 Thread Chih-Wei Huang
Should be LOCAL_EXPORT_C_INCLUDE_DIRS.

Signed-off-by: Chih-Wei Huang 
---
 src/gallium/winsys/virgl/common/Android.mk | 2 +-
 src/mapi/Android.mk| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/winsys/virgl/common/Android.mk 
b/src/gallium/winsys/virgl/common/Android.mk
index 0b8eda1..c2b25cb 100644
--- a/src/gallium/winsys/virgl/common/Android.mk
+++ b/src/gallium/winsys/virgl/common/Android.mk
@@ -29,7 +29,7 @@ LOCAL_SRC_FILES := $(C_SOURCES)
 
 LOCAL_MODULE := libmesa_winsys_virgl_common
 
-LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)
+LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
 
 include $(GALLIUM_COMMON_MK)
 include $(BUILD_STATIC_LIBRARY)
diff --git a/src/mapi/Android.mk b/src/mapi/Android.mk
index 06a7647..9405d2a 100644
--- a/src/mapi/Android.mk
+++ b/src/mapi/Android.mk
@@ -50,7 +50,7 @@ LOCAL_CFLAGS := \
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi
 
-LOCAL_EXPORT_C_INCLUDES := \
+LOCAL_EXPORT_C_INCLUDE_DIRS := \
$(MESA_TOP)/src/mapi
 
 LOCAL_MODULE := libglapi
-- 
2.7.4

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