Re: [Mesa-dev] [PATCH 04/11] gallium: Use Array._DrawVAO in st_atom_array.c.

[Mathias Fröhlich]

Hi all,

On Wednesday, 11 April 2018 16:23:52 CEST Brian Paul wrote:
> Hmm, in my experience, interleaved arrays are fairly common.
> 
> I still haven't had much time to look at Mathias's latest patches.
> 
> And I haven't looked this code in the state tracker recently, but I seem 
> to recall there was some difference between interleaved arrays (in one 
> VBO) vs. separate arrays in separate VBOs that needed special handling.
> 
> As for determining whether arrays are interleaved, if that's something 
> we still need to do, I think it could be lifted into core Mesa.  We 
> could add a new gl_vertex_array_object::_IsInterleaved field which is 
> only updated when the VAO state is modified.

We don't need such a flag.
We can easily integrate that into the current patch series. The bitmask loops 
help to loop in an outer loop by unique binding point - which would mean in 
the user space case by interleaved set or array attributes - and for each of 
that binding points (= one new buffer object) in an inner loop over the 
attributes belonging to this binding point.

I think that I have a solution for both of your concerns by just using this 
nested bitmask loops.
It is just that the interleaved scan for *user*space*arrays* (not the vbo 
interleaved case - that is already handled well or already taken from the 
already application provided data in the VAO) is currently not done in generic 
code, but can be moved there with a computational effort that is not more than 
carrying over the information from gl_vertex_buffer_binding to 
pipe_vertex_buffer and from gl_array_attributes to pipe_vertex_element.

Look at the comment in patch #1. There is a pseudo code example how this is 
meant to work.

best

Mathias


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

Re: [Mesa-dev] [PATCH] st/dri: Fix dangling pointer to a destroyed dri_drawable

[Marek Olšák]

Pushed, thanks!

Marek

On Fri, Apr 20, 2018 at 6:29 AM, Johan Klokkhammer Helsing <
johan.hels...@qt.io> wrote:

> If an EGLSurface is created, made current and destroyed, and then a second
> EGLSurface is created. Then the second malloc in driCreateNewDrawable may
> return the same pointer address the first surface's drawable had.
> Consequently, when dri_make_current later tries to determine if it should
> update the texture_stamp it compares the surface's drawable pointer against
> the drawable in the last call to dri_make_current and assumes it's the same
> surface (which it isn't).
>
> When texture_stamp is left unset, then dri_st_framebuffer_validate thinks
> it has already called update_drawable_info for that drawable, leaving it
> unvalidated and this is when bad things starts to happen. In my case it
> manifested itself by the width and height of the surface being unset.
>
> This is fixed this by setting the pointer to NULL before freeing the
> surface.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106126
> Signed-off-by: Johan Klokkhammer Helsing 
> ---
>  src/gallium/state_trackers/dri/dri_drawable.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c
> b/src/gallium/state_trackers/dri/dri_drawable.c
> index e5a7537e47..02328acd98 100644
> --- a/src/gallium/state_trackers/dri/dri_drawable.c
> +++ b/src/gallium/state_trackers/dri/dri_drawable.c
> @@ -185,6 +185,7 @@ fail:
>  void
>  dri_destroy_buffer(__DRIdrawable * dPriv)
>  {
> +   struct dri_context *ctx = dri_context(dPriv->driContextPriv);
> struct dri_drawable *drawable = dri_drawable(dPriv);
> struct dri_screen *screen = drawable->screen;
> struct st_api *stapi = screen->st_api;
> @@ -202,6 +203,9 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
> /* Notify the st manager that this drawable is no longer valid */
> stapi->destroy_drawable(stapi, >base);
>
> +   if (ctx && ctx->dPriv == dPriv)
> +  ctx->dPriv = NULL;
> +
> FREE(drawable);
>  }
>
> --
> 2.17.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4] mesa: GL_EXT_texture_norm16 extension plumbing

[Tapani Pälli]

Patch enables use of short and unsigned short data for texture uploads,
rendering and reading of framebuffers within the restrictions specified
in GL_EXT_texture_norm16 spec.

Patch also enables those 16bit format layout qualifiers listed in
GL_NV_image_formats that depend on EXT_texture_norm16.

v2: expose extension with dummy_true
fix layout qualifier map changes (Ilia Mirkin)

v3: use _mesa_has_EXT_texture_norm16, other fixes
and cleanup (Ilia Mirkin)

v4: fix rest of the issues found

Signed-off-by: Tapani Pälli 
Acked-by: Ilia Mirkin 
---
 src/compiler/glsl/glsl_parser.yy | 12 
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/genmipmap.c|  2 +-
 src/mesa/main/glformats.c| 60 +++-
 src/mesa/main/glformats.h|  3 +-
 src/mesa/main/readpix.c  | 14 --
 src/mesa/main/shaderimage.c  |  7 ++---
 7 files changed, 84 insertions(+), 15 deletions(-)

diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index e5ea41d4df..b4951a258a 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -1340,18 +1340,18 @@ layout_qualifier_id:
{ "r32i", GL_R32I, GLSL_TYPE_INT, 130, 310, false },
{ "r16i", GL_R16I, GLSL_TYPE_INT, 130, 0, true },
{ "r8i", GL_R8I, GLSL_TYPE_INT, 130, 0, true },
-   { "rgba16", GL_RGBA16, GLSL_TYPE_FLOAT, 130, 0, false },
+   { "rgba16", GL_RGBA16, GLSL_TYPE_FLOAT, 130, 0, true },
{ "rgb10_a2", GL_RGB10_A2, GLSL_TYPE_FLOAT, 130, 0, true },
{ "rgba8", GL_RGBA8, GLSL_TYPE_FLOAT, 130, 310, false },
-   { "rg16", GL_RG16, GLSL_TYPE_FLOAT, 130, 0, false },
+   { "rg16", GL_RG16, GLSL_TYPE_FLOAT, 130, 0, true },
{ "rg8", GL_RG8, GLSL_TYPE_FLOAT, 130, 0, true },
-   { "r16", GL_R16, GLSL_TYPE_FLOAT, 130, 0, false },
+   { "r16", GL_R16, GLSL_TYPE_FLOAT, 130, 0, true },
{ "r8", GL_R8, GLSL_TYPE_FLOAT, 130, 0, true },
-   { "rgba16_snorm", GL_RGBA16_SNORM, GLSL_TYPE_FLOAT, 130, 0, 
false },
+   { "rgba16_snorm", GL_RGBA16_SNORM, GLSL_TYPE_FLOAT, 130, 0, 
true },
{ "rgba8_snorm", GL_RGBA8_SNORM, GLSL_TYPE_FLOAT, 130, 310, 
false },
-   { "rg16_snorm", GL_RG16_SNORM, GLSL_TYPE_FLOAT, 130, 0, false },
+   { "rg16_snorm", GL_RG16_SNORM, GLSL_TYPE_FLOAT, 130, 0, true },
{ "rg8_snorm", GL_RG8_SNORM, GLSL_TYPE_FLOAT, 130, 0, true },
-   { "r16_snorm", GL_R16_SNORM, GLSL_TYPE_FLOAT, 130, 0, false },
+   { "r16_snorm", GL_R16_SNORM, GLSL_TYPE_FLOAT, 130, 0, true },
{ "r8_snorm", GL_R8_SNORM, GLSL_TYPE_FLOAT, 130, 0, true }
 };
 
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 492f7c3d20..aec17750d5 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -283,6 +283,7 @@ EXT(EXT_texture_format_BGRA , dummy_true
 EXT(EXT_texture_integer , EXT_texture_integer  
  , GLL, GLC,  x ,  x , 2006)
 EXT(EXT_texture_lod_bias, dummy_true   
  , GLL,  x , ES1,  x , 1999)
 EXT(EXT_texture_mirror_clamp, EXT_texture_mirror_clamp 
  , GLL, GLC,  x ,  x , 2004)
+EXT(EXT_texture_norm16  , dummy_true   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_texture_object  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
 EXT(EXT_texture_rectangle   , NV_texture_rectangle 
  , GLL,  x ,  x ,  x , 2004)
 EXT(EXT_texture_rg  , ARB_texture_rg   
  ,  x ,  x ,  x , ES2, 2011)
diff --git a/src/mesa/main/genmipmap.c b/src/mesa/main/genmipmap.c
index 488c32f810..fd20ea2806 100644
--- a/src/mesa/main/genmipmap.c
+++ b/src/mesa/main/genmipmap.c
@@ -93,7 +93,7 @@ _mesa_is_valid_generate_texture_mipmap_internalformat(struct 
gl_context *ctx,
  internalformat == GL_LUMINANCE_ALPHA ||
  internalformat == GL_LUMINANCE || internalformat == GL_ALPHA ||
  internalformat == GL_BGRA_EXT ||
- (_mesa_is_es3_color_renderable(internalformat) &&
+ (_mesa_is_es3_color_renderable(ctx, internalformat) &&
   _mesa_is_es3_texture_filterable(ctx, internalformat));
}
 
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index 1e797c24c2..cba5e670db 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2857,6 +2857,17 @@ _mesa_es3_error_check_format_and_type(const struct 
gl_context *ctx,
 return GL_INVALID_OPERATION;
  break;
 
+  case GL_UNSIGNED_SHORT:
+ if 

Re: [Mesa-dev] [PATCH 1/2] ac/radv/radeonsi: refactor raster_config default values getters.

[Samuel Pitoiset]

Series is:

Reviewed-by: Samuel Pitoiset 

On 04/23/2018 02:17 AM, Dave Airlie wrote:

From: Dave Airlie 

This just makes this common code between the two drivers.
---
  src/amd/common/ac_gpu_info.c| 93 +
  src/amd/common/ac_gpu_info.h|  4 +-
  src/amd/vulkan/si_cmd_buffer.c  | 85 ++
  src/gallium/drivers/radeonsi/si_state.c | 84 ++---
  4 files changed, 102 insertions(+), 164 deletions(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 12b03c4ea29..47a87650a6d 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -554,3 +554,96 @@ ac_get_gs_table_depth(enum chip_class chip_class, enum 
radeon_family family)
unreachable("Unknown GPU");
}
  }
+
+void
+ac_get_raster_config(struct radeon_info *info,
+uint32_t *raster_config_p,
+uint32_t *raster_config_1_p)
+{
+   unsigned num_rb = MIN2(info->num_render_backends, 16);
+   unsigned raster_config, raster_config_1;
+   switch (info->family) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   raster_config = 0x2a00126a;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_VERDE:
+   raster_config = 0x124a;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_OLAND:
+   raster_config = 0x0082;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_HAINAN:
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_BONAIRE:
+   raster_config = 0x1612;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_HAWAII:
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   break;
+   case CHIP_FIJI:
+   if (info->cik_macrotile_mode_array[0] == 0x00e8) {
+   /* old kernels with old tiling config */
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   } else {
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   }
+   break;
+   case CHIP_POLARIS10:
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   break;
+   case CHIP_POLARIS11:
+   case CHIP_POLARIS12:
+   raster_config = 0x1612;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_VEGAM:
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   break;
+   case CHIP_TONGA:
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   break;
+   case CHIP_ICELAND:
+   if (num_rb == 1)
+   raster_config = 0x;
+   else
+   raster_config = 0x0002;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_CARRIZO:
+   raster_config = 0x0002;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_KAVERI:
+   /* KV should be 0x0002, but that causes problems with 
radeon */
+   raster_config = 0x; /* 0x0002 */
+   raster_config_1 = 0x;
+   break;
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   case CHIP_STONEY:
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   default:
+   fprintf(stderr,
+   "ac: Unknown GPU, using 0 for raster_config\n");
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   }
+   *raster_config_p = raster_config;
+   *raster_config_1_p = raster_config_1;
+}
diff --git a/src/amd/common/ac_gpu_info.h b/src/amd/common/ac_gpu_info.h
index 003d340e0c1..9227ff37799 100644
--- a/src/amd/common/ac_gpu_info.h
+++ b/src/amd/common/ac_gpu_info.h
@@ -131,7 +131,9 @@ void ac_compute_driver_uuid(char *uuid, size_t size);
  void ac_compute_device_uuid(struct radeon_info *info, char *uuid, size_t 
size);
  void ac_print_gpu_info(struct radeon_info *info);
  int ac_get_gs_table_depth(enum chip_class chip_class, enum radeon_family 
family);
-
+void ac_get_raster_config(struct radeon_info *info,
+ uint32_t *raster_config_p,
+ uint32_t *raster_config_1_p);
  #ifdef __cplusplus
  }
  #endif
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c

Re: [Mesa-dev] [PATCH] radv: advertise 8 bits of subpixel precision for viewports

[Samuel Pitoiset]

On 04/23/2018 11:12 AM, Józef Kucia wrote:

On Wed, Apr 11, 2018 at 10:38 AM, Samuel Pitoiset
 wrote:

Agreed.

Reviewed-by: Samuel Pitoiset 


Please push the patch for me. I don't have commit access.


Pushed!




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

Re: [Mesa-dev] [PATCH 1/2] radv: only set raster_config_1 outside the index registers.

[Samuel Pitoiset]

Series is:

Reviewed-by: Samuel Pitoiset 

On 04/23/2018 02:43 AM, Dave Airlie wrote:

From: Dave Airlie 

This follows what radeonsi does.

Ported from radeonsi:
 radeonsi: emit PA_SC_RASTER_CONFIG_1 only once
---
  src/amd/vulkan/si_cmd_buffer.c | 31 ---
  1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index b7a2ca244bf..2140368c80d 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -63,19 +63,6 @@ si_write_harvested_raster_configs(struct 
radv_physical_device *physical_device,
 * fields are for, so I'm leaving them as their default
 * values. */
  
-	if ((num_se > 2) && ((!se_mask[0] && !se_mask[1]) ||

-(!se_mask[2] && !se_mask[3]))) {
-   raster_config_1 &= C_028354_SE_PAIR_MAP;
-
-   if (!se_mask[0] && !se_mask[1]) {
-   raster_config_1 |=
-   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_3);
-   } else {
-   raster_config_1 |=
-   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_0);
-   }
-   }
-
for (se = 0; se < num_se; se++) {
unsigned raster_config_se = raster_config;
unsigned pkr0_mask = ((1 << rb_per_pkr) - 1) << (se * 
rb_per_se);
@@ -156,8 +143,6 @@ si_write_harvested_raster_configs(struct 
radv_physical_device *physical_device,
   S_030800_SE_INDEX(se) | 
S_030800_SH_BROADCAST_WRITES(1) |
   
S_030800_INSTANCE_BROADCAST_WRITES(1));
radeon_set_context_reg(cs, R_028350_PA_SC_RASTER_CONFIG, 
raster_config_se);
-   if (physical_device->rad_info.chip_class >= CIK)
-   radeon_set_context_reg(cs, 
R_028354_PA_SC_RASTER_CONFIG_1, raster_config_1);
}
  
  	/* GRBM_GFX_INDEX has a different offset on SI and CI+ */

@@ -170,6 +155,22 @@ si_write_harvested_raster_configs(struct 
radv_physical_device *physical_device,
radeon_set_uconfig_reg(cs, R_030800_GRBM_GFX_INDEX,
   S_030800_SE_BROADCAST_WRITES(1) | 
S_030800_SH_BROADCAST_WRITES(1) |
   S_030800_INSTANCE_BROADCAST_WRITES(1));
+
+   if (physical_device->rad_info.chip_class >= CIK) {
+   if ((num_se > 2) && ((!se_mask[0] && !se_mask[1]) ||
+(!se_mask[2] && !se_mask[3]))) {
+   raster_config_1 &= C_028354_SE_PAIR_MAP;
+
+   if (!se_mask[0] && !se_mask[1]) {
+   raster_config_1 |=
+   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_3);
+   } else {
+   raster_config_1 |=
+   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_0);
+   }
+   }
+   radeon_set_context_reg(cs, R_028354_PA_SC_RASTER_CONFIG_1, 
raster_config_1);
+   }
  }
  
  static void



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

[Mesa-dev] [Bug 106126] eglMakeCurrent does not always ensure dri_drawable->update_drawable_info has been called for a new EGLSurface if another has been created and destroyed first

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Timothy Arceri  ---
Fixed by:

author  Johan Klokkhammer Helsing 
commit  dab02dea3411d325a5aee6cda5b581e61396ecc6

st/dri: Fix dangling pointer to a destroyed dri_drawable

If an EGLSurface is created, made current and destroyed, and then a second
EGLSurface is created. Then the second malloc in driCreateNewDrawable may
return the same pointer address the first surface's drawable had.
Consequently, when dri_make_current later tries to determine if it should
update the texture_stamp it compares the surface's drawable pointer against
the drawable in the last call to dri_make_current and assumes it's the same
surface (which it isn't).

When texture_stamp is left unset, then dri_st_framebuffer_validate thinks
it has already called update_drawable_info for that drawable, leaving it
unvalidated and this is when bad things starts to happen. In my case it
manifested itself by the width and height of the surface being unset.

This is fixed this by setting the pointer to NULL before freeing the
surface.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106126
Signed-off-by: Johan Klokkhammer Helsing 
Signed-off-by: Marek Olšák 
Cc: 18.0 18.1 

-- 
You are receiving this mail because:
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: advertise 8 bits of subpixel precision for viewports

[Józef Kucia]

On Wed, Apr 11, 2018 at 10:38 AM, Samuel Pitoiset
 wrote:
> Agreed.
>
> Reviewed-by: Samuel Pitoiset 

Please push the patch for me. I don't have commit access.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 04/11] gallium: Use Array._DrawVAO in st_atom_array.c.

[Mathias Fröhlich]

Hi Marek,

On Tuesday, 10 April 2018 20:09:06 CEST Marek Olšák wrote:
> Generally, if you have to loop over all arrays to find common vertex
> buffers, it's better not to do it. The default separate path is going to
> perform best, because it's straightforward and interleaved arrays are super
> rare.

Yes, I know. All the cleanup I did recently is to get rid of all these kind of 
loops and if needed make them as cheap as possible.

best
Mathias


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

Re: [Mesa-dev] [PATCH] radeonsi/gfx9: fix a hang with an empty first IB

[Juan A. Suarez Romero]

On Sat, 2018-04-21 at 00:48 -0400, Marek Olšák wrote:
> Hi Juan,
> 
> Here is the patch backported to 18.0:
> https://cgit.freedesktop.org/~mareko/mesa/commit/?h=amd-18.0=7ab59306613b08c7dd6e875c3276cac9a61889ae
> 

Thanks for the patch. Enqueued for next release.

J.A.

> Marek
> 
> On Fri, Apr 20, 2018 at 10:57 AM, Juan A. Suarez Romero  
> wrote:
> > On Tue, 2018-04-17 at 15:54 -0400, Marek Olšák wrote:
> > > From: Marek Olšák 
> > > 
> > > This packet causes the no-op IB detection to fail, so the IB is always
> > > submitted. Also fix the no-op IB detection by moving the begin call.
> > > 
> > > Cc: 18.0 
> > 
> > 
> > This patch does not apply cleanly in 18.0, so I've resolved the conflicts.
> > 
> > Please, take a look at [1] to see if it is everything correct. Thanks in
> > advance!
> > 
> > 
> > [1] 
> > https://github.com/Igalia/release-mesa/commit/68768a94b21d2c20e45ebae29698c4
> > f40f43e18f
> > 
> > 
> > 
> > J.A.
> > 
> > 
> > > ---
> > >  src/gallium/drivers/radeonsi/si_pipe.c | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
> > > b/src/gallium/drivers/radeonsi/si_pipe.c
> > > index d044b191b71..ac16aae3078 100644
> > > --- a/src/gallium/drivers/radeonsi/si_pipe.c
> > > +++ b/src/gallium/drivers/radeonsi/si_pipe.c
> > > @@ -522,38 +522,37 @@ static struct pipe_context 
> > > *si_create_context(struct pipe_screen *screen,
> > >   sctx->b.resource_copy_region = sctx->dma_copy;
> > >  
> > >   sctx->blitter = util_blitter_create(>b);
> > >   if (sctx->blitter == NULL)
> > >   goto fail;
> > >   sctx->blitter->draw_rectangle = si_draw_rectangle;
> > >   sctx->blitter->skip_viewport_restore = true;
> > >  
> > >   sctx->sample_mask = 0x;
> > >  
> > > - /* these must be last */
> > > - si_begin_new_gfx_cs(sctx);
> > > -
> > >   if (sctx->chip_class >= GFX9) {
> > >   sctx->wait_mem_scratch = r600_resource(
> > >   pipe_buffer_create(screen, 0, PIPE_USAGE_DEFAULT, 
> > > 4));
> > >   if (!sctx->wait_mem_scratch)
> > >   goto fail;
> > >  
> > >   /* Initialize the memory. */
> > >   struct radeon_winsys_cs *cs = sctx->gfx_cs;
> > >   radeon_emit(cs, PKT3(PKT3_WRITE_DATA, 3, 0));
> > >   radeon_emit(cs, S_370_DST_SEL(V_370_MEMORY_SYNC) |
> > >   S_370_WR_CONFIRM(1) |
> > >   S_370_ENGINE_SEL(V_370_ME));
> > >   radeon_emit(cs, sctx->wait_mem_scratch->gpu_address);
> > >   radeon_emit(cs, sctx->wait_mem_scratch->gpu_address >> 32);
> > >   radeon_emit(cs, sctx->wait_mem_number);
> > > + radeon_add_to_buffer_list(sctx, cs, sctx->wait_mem_scratch,
> > > +   RADEON_USAGE_WRITE, 
> > > RADEON_PRIO_FENCE);
> > >   }
> > >  
> > >   /* CIK cannot unbind a constant buffer (S_BUFFER_LOAD doesn't skip 
> > > loads
> > >* if NUM_RECORDS == 0). We need to use a dummy buffer instead. */
> > >   if (sctx->chip_class == CIK) {
> > >   sctx->null_const_buf.buffer =
> > >   pipe_aligned_buffer_create(screen,
> > >  SI_RESOURCE_FLAG_32BIT,
> > >  PIPE_USAGE_DEFAULT, 16,
> > >  
> > > sctx->screen->info.tcc_cache_line_size);
> > > @@ -612,20 +611,22 @@ static struct pipe_context 
> > > *si_create_context(struct pipe_screen *screen,
> > >   
> > > _mesa_key_pointer_equal);
> > >   sctx->img_handles = _mesa_hash_table_create(NULL, 
> > > _mesa_hash_pointer,
> > >   
> > > _mesa_key_pointer_equal);
> > >  
> > >   util_dynarray_init(>resident_tex_handles, NULL);
> > >   util_dynarray_init(>resident_img_handles, NULL);
> > >   util_dynarray_init(>resident_tex_needs_color_decompress, 
> > > NULL);
> > >   util_dynarray_init(>resident_img_needs_color_decompress, 
> > > NULL);
> > >   util_dynarray_init(>resident_tex_needs_depth_decompress, 
> > > NULL);
> > >  
> > > + /* this must be last */
> > > + si_begin_new_gfx_cs(sctx);
> > >   return >b;
> > >  fail:
> > >   fprintf(stderr, "radeonsi: Failed to create a context.\n");
> > >   si_destroy_context(>b);
> > >   return NULL;
> > >  }
> > >  
> > >  static struct pipe_context *si_pipe_create_context(struct pipe_screen 
> > > *screen,
> > >  void *priv, unsigned 
> > > flags)
> > >  {
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH] anv/allocator: Don't srink either end of the block pool

[Eero Tamminen]

Hi,

On 21.04.2018 08:15, Jason Ekstrand wrote:

Previously, we only tried to ensure that we didn't shrink either end
below what was already handed out.  However, due to the way we handle
relocations with block pools, we can't shrink the back end at all.  It's
probably best to not shrink in either direction.

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


Verified that "texture3d" demo works with this patch, crashes without it.

Tested-by: Eero Tamminen 


- Eero


Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/vulkan/anv_allocator.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index f884ac3..642e161 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -508,12 +508,12 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct 
anv_block_state *state)
assert(center_bo_offset >= back_used);
  
/* Make sure we don't shrink the back end of the pool */

-  if (center_bo_offset < pool->back_state.end)
- center_bo_offset = pool->back_state.end;
+  if (center_bo_offset < back_required)
+ center_bo_offset = back_required;
  
/* Make sure that we don't shrink the front end of the pool */

-  if (size - center_bo_offset < pool->state.end)
- center_bo_offset = size - pool->state.end;
+  if (size - center_bo_offset < front_required)
+ center_bo_offset = size - front_required;
 }
  
 assert(center_bo_offset % PAGE_SIZE == 0);




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

Re: [Mesa-dev] [PATCH 5/5] radeonsi: use common gs_table_depth code

[Nicolai Hähnle]

Patches 2, 3, 5:

Reviewed-by: Nicolai Hähnle 

On 23.04.2018 01:59, Dave Airlie wrote:

From: Dave Airlie 

---
  src/gallium/drivers/radeonsi/si_pipe.c | 33 ++---
  1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index b3ef098b8ea..327dd7c4242 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -661,37 +661,8 @@ static void si_destroy_screen(struct pipe_screen* pscreen)
  
  static void si_init_gs_info(struct si_screen *sscreen)

  {
-   /* gs_table_depth is not used by GFX9 */
-   if (sscreen->info.chip_class >= GFX9)
-   return;
-
-   switch (sscreen->info.family) {
-   case CHIP_OLAND:
-   case CHIP_HAINAN:
-   case CHIP_KAVERI:
-   case CHIP_KABINI:
-   case CHIP_MULLINS:
-   case CHIP_ICELAND:
-   case CHIP_CARRIZO:
-   case CHIP_STONEY:
-   sscreen->gs_table_depth = 16;
-   return;
-   case CHIP_TAHITI:
-   case CHIP_PITCAIRN:
-   case CHIP_VERDE:
-   case CHIP_BONAIRE:
-   case CHIP_HAWAII:
-   case CHIP_TONGA:
-   case CHIP_FIJI:
-   case CHIP_POLARIS10:
-   case CHIP_POLARIS11:
-   case CHIP_POLARIS12:
-   case CHIP_VEGAM:
-   sscreen->gs_table_depth = 32;
-   return;
-   default:
-   unreachable("unknown GPU");
-   }
+   sscreen->gs_table_depth = 
ac_get_gs_table_depth(sscreen->info.chip_class,
+   sscreen->info.family);
  }
  
  static void si_handle_env_var_force_family(struct si_screen *sscreen)





--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/decoder: Use gen_group::dw_length when available

[Lionel Landwerlin]

On 23/04/18 12:20, Topi Pohjolainen wrote:

Otherwise gen_group_get_length() will try to use first fields
of, for example, CC_VIEWPORT and SF_CLIP to determine the
group size. These packets are not present in the state with
full header but simply with their contents while equivalent
state pointers (3DSTATE_VIEWPORT_STATE_POINTERS_CC and
3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP respectively) telling
their starting points.

Before:
---

0xfffef540:  0x7823:  3DSTATE_VIEWPORT_STATE_POINTERS_CC

0xfffef540:  0x7823 : Dword 0
 DWord Length: 0
0xfffef544:  0x0180 : Dword 1
 CC Viewport Pointer: 0x0180
CC_VIEWPORT 0
0xfffea180:  0x : Dword 0
 Minimum Depth: 0.00
0xfffef548:  0x7821:  3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP
0xfffef548:  0x7821 : Dword 0
 DWord Length: 0
0xfffef54c:  0x01c0 : Dword 1
 SF Clip Viewport Pointer: 0x01c0
SF_CLIP_VIEWPORT 0
0xfffea1c0:  0x4100 : Dword 0
 Viewport Matrix Element m00: 0.00
0xfffea1c4:  0x3f00 : Dword 1
 Viewport Matrix Element m11: 0.50
0xfffef550:  0x7824:  3DSTATE_BLEND_STATE_POINTERS

After:
--

0xfffef540:  0x7823:  3DSTATE_VIEWPORT_STATE_POINTERS_CC

0xfffef540:  0x7823 : Dword 0
 DWord Length: 0
0xfffef544:  0x0180 : Dword 1
 CC Viewport Pointer: 0x0180
CC_VIEWPORT 0
0xfffea180:  0x : Dword 0
 Minimum Depth: 0.00
0xfffea184:  0x3f80 : Dword 1
 Maximum Depth: 1.00
0xfffef548:  0x7821:  3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP
0xfffef548:  0x7821 : Dword 0
 DWord Length: 0
0xfffef54c:  0x01c0 : Dword 1
 SF Clip Viewport Pointer: 0x01c0
SF_CLIP_VIEWPORT 0
0xfffea1c0:  0x4100 : Dword 0
 Viewport Matrix Element m00: 0.00
0xfffea1c4:  0x3f00 : Dword 1
 Viewport Matrix Element m11: 0.50
0xfffea1c8:  0x3f00 : Dword 2
 Viewport Matrix Element m22: 0.50
0xfffea1cc:  0x4100 : Dword 3
 Viewport Matrix Element m30: 8.00
0xfffea1d0:  0x3f00 : Dword 4
 Viewport Matrix Element m31: 0.50
0xfffea1d4:  0x3f00 : Dword 5
 Viewport Matrix Element m32: 0.50
0xfffea1d8:  0x : Dword 6
0xfffea1dc:  0x : Dword 7
0xfffea1e0:  0xc500 : Dword 8
 X Min Clip Guardband: -2048.00
0xfffea1e4:  0x4500 : Dword 9
 X Max Clip Guardband: 2048.00
0xfffea1e8:  0xc700 : Dword 10
 Y Min Clip Guardband: -32768.00
0xfffea1ec:  0x4700 : Dword 11
 Y Max Clip Guardband: 32768.00
0xfffea1f0:  0x : Dword 12
 X Min ViewPort: 0.00
0xfffea1f4:  0x4170 : Dword 13
 X Max ViewPort: 15.00
0xfffea1f8:  0x : Dword 14
 Y Min ViewPort: 0.00
0xfffea1fc:  0x : Dword 15
 Y Max ViewPort: 0.00

CC: Lionel Landwerlin 
CC: Kenneth Graunke 
Signed-off-by: Topi Pohjolainen 
---
  src/intel/common/gen_decoder.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 1b8123b..cc212cc 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -713,6 +713,9 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
  int
  gen_group_get_length(struct gen_group *group, const uint32_t *p)
  {
+   if (group->dw_length)
+  return group->dw_length;


I don't think that'll work. Some instructions have length (as default 
value) too but might have a variable DWord Length field as well.
I think the best approach is to flag  &  elements in 
the decoder and in get_length() have a if (group->is_struct || 
group->is_register) return group->dw_length;.



+
 uint32_t h = p[0];
 uint32_t type = field_value(h, 29, 31);
  



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

[Mesa-dev] [Bug 105232] piglit regressions and crashes from gbm alpha masks

[bugzilla-daemon]

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

Mark Janes  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

-- 
You are receiving this mail because:
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 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

--- Comment #8 from Samuel Pitoiset  ---
Well, I have a vega 56 so I can reproduce the hang but I would need a bit more
info. What preset are you using? Do you have something in dmesg when it hangs?

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

Re: [Mesa-dev] 16-bit comparisons in NIR

[Jason Ekstrand]

On Sun, Apr 22, 2018 at 11:31 AM, Iago Toral  wrote:

> On Fri, 2018-04-20 at 17:16 -0700, Jason Ekstrand wrote:
>
> On Fri, Apr 20, 2018 at 5:16 AM, Nicolai Hähnle 
> wrote:
>
> On 20.04.2018 10:21, Iago Toral wrote:
>
> Hi,
>
> while developing support for Vulkan shaderInt16 on Anvil I came across
> a feature of NIR that was a bit inconvenient: bools are always 32-bit
> by design, but the Intel hardware produces 16-bit bool results for 16-
> bit comparisons, so that creates a problem that manifests like this:
>
> vec1 32 ssa_21 = fge ssa_20, ssa_16
> vec1 16 ssa_22 = b2f ssa_21
>
>
>
> I was thinking about this a bit this morning and it gets even more
> sticky.  What happens if you have
>
> bool e = (a < b) && (c < d);
>
> where a and b are 16-bit and c and d are 32-bit?  In this case, one
> comprison has a 32-bit value and one has a 16-bit value and you have to
> pick one for the &&.
>
>
> Good point, yes, it seems we would need to handle this somehow. Topi seems
> to try and do something about this in the patch he referenced in his reply.
> Alternatively, we can also run a specific pass to fix this up...
>

Yeah.  For now, just making the 16-bit comparisons return 32 bits will get
things working.  If we want to write a pass to assign "optimal" bit sizes
later, that wouldn't be too hard.  However, it would be tricky since you
have to take both sources and destinations into account and handle mixed
bit sizes.

--Jason


> Our CMP instruction will produce a 16-bit boolean result for the first
> NIR instruction (where NIR expects it to be 32-bit), so by the time we
> emit the second instruction in the driver the bit-size for the operand
> of b2f provided by NIR no longer matches the reality and we emit
> incorrect code.
>
> This seems to have been a consicious design choice in NIR, and while
> discussing this with Jason he was unsure how much we wanted to change
> this  or how to do it, given how thoroughly 32-bit bools are baked into
> NIR and the complexities that modifying this would also bring to our
> bit-size validation code.
>
> I have been considering alternatives that didn't involve changing NIR
> to support multiple bit-sizes for booleans:
>
> 1) Drivers that need to emit smaller booleans could try to fix the
> generated NIR by correcting the expected bit-sizes for CMP
> instructions. This would be rather trivial to implement in drivers (and
> maybe we could even make a generic pass for other drivers to use if
> they need it) but this will make the validator complain because it
> won't recognize comparisons with 16-bit bool outputs as valid NIR
> opcodes. I also found instances where nir_search would complain about
> mismatching bit-sizes. I haven't looked any further into it yet though,
> so maybe we can reasonably work around these issues.
>
> 2) Drivers could handle this specially when they emit code from NIR.
> Specifically, when they see a 32-bit boolean source in an instruction,
> they would have to search for the instruction that produced that source
> value and check whether it is a 16-bit or a 32-bit boolean to emit
> proper code for the instruction.
>
> 3) Drivers can just convert the 16-bit bool result they generate for
> 16-bit cmp to the 32-bit bool that NIR expects, and then possibly run
> an optimization pass to eliminate these extra conversions and fix up
> the code accordingly.
>
>
> radeonsi(NIR) and radv already use option 3, since GCN hardware really
> wants to treat bools as 1-bit value, so that's what I'd suggest. The
> optimizations that cleanup the conversions happen in LLVM for us.
>
>
> Is this a GCN thing or an LLVM thing?  It would be neat if your hardware
> had 1-bit registers. :-)  We sort-of do but they're special flag registers
> and we have very few of them.
>
> --Jason
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] intel/compiler: Add scheduler deps for instructions that implicitly read g0

[Mark Janes]

I enabled these tests, and could not make them fail in CI.

This bug may also be related:

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

Ian Romanick  writes:

> From: Ian Romanick 
>
> Otherwise the scheduler can move the writes after the reads.
>
> Signed-off-by: Ian Romanick 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95012
> Cc: Mark Janes 
> Cc: Clayton A Craft 
> ---
> I'd really like to have this run on the CI with the tests from bugzill
> #95012 re-enabled.  I don't know how to do this on my own.  This series
> is also available at:
>
> https://cgit.freedesktop.org/~idr/mesa/log/?h=bug-95012.
>
>  src/intel/compiler/brw_ir_vec4.h | 25 
> 
>  src/intel/compiler/brw_schedule_instructions.cpp |  3 +++
>  2 files changed, 28 insertions(+)
>
> diff --git a/src/intel/compiler/brw_ir_vec4.h 
> b/src/intel/compiler/brw_ir_vec4.h
> index 95c5119c6c0..e401d8b4d16 100644
> --- a/src/intel/compiler/brw_ir_vec4.h
> +++ b/src/intel/compiler/brw_ir_vec4.h
> @@ -334,6 +334,31 @@ public:
>opcode != BRW_OPCODE_IF &&
>opcode != BRW_OPCODE_WHILE));
> }
> +
> +   bool reads_g0_implicitly() const
> +   {
> +  switch (opcode) {
> +  case SHADER_OPCODE_TEX:
> +  case SHADER_OPCODE_TXL:
> +  case SHADER_OPCODE_TXD:
> +  case SHADER_OPCODE_TXF:
> +  case SHADER_OPCODE_TXF_CMS_W:
> +  case SHADER_OPCODE_TXF_CMS:
> +  case SHADER_OPCODE_TXF_MCS:
> +  case SHADER_OPCODE_TXS:
> +  case SHADER_OPCODE_TG4:
> +  case SHADER_OPCODE_TG4_OFFSET:
> +  case SHADER_OPCODE_SAMPLEINFO:
> +  case VS_OPCODE_PULL_CONSTANT_LOAD:
> +  case GS_OPCODE_SET_PRIMITIVE_ID:
> +  case GS_OPCODE_GET_INSTANCE_ID:
> +  case SHADER_OPCODE_GEN4_SCRATCH_READ:
> +  case SHADER_OPCODE_GEN4_SCRATCH_WRITE:
> + return true;
> +  default:
> + return false;
> +  }
> +   }
>  };
>  
>  /**
> diff --git a/src/intel/compiler/brw_schedule_instructions.cpp 
> b/src/intel/compiler/brw_schedule_instructions.cpp
> index fa85045de74..f817142a8b5 100644
> --- a/src/intel/compiler/brw_schedule_instructions.cpp
> +++ b/src/intel/compiler/brw_schedule_instructions.cpp
> @@ -1267,6 +1267,9 @@ vec4_instruction_scheduler::calculate_deps()
>   }
>}
>  
> +  if (inst->reads_g0_implicitly())
> + add_dep(last_fixed_grf_write, n);
> +
>if (!inst->is_send_from_grf()) {
>   for (int i = 0; i < inst->mlen; i++) {
>  /* It looks like the MRF regs are released in the send
> -- 
> 2.14.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/dri: Fix dangling pointer to a destroyed dri_drawable

[Emil Velikov]

Hi Johan,

On 20 April 2018 at 11:29, Johan Klokkhammer Helsing
 wrote:
> If an EGLSurface is created, made current and destroyed, and then a second
> EGLSurface is created. Then the second malloc in driCreateNewDrawable may
> return the same pointer address the first surface's drawable had.
What do you mean with "second malloc in driCreateNewDrawable"? There's
only a single malloc in the function.

Are you saying the C runtime returns identical pointers when creating
the first and second surface?

> Consequently, when dri_make_current later tries to determine if it should
> update the texture_stamp it compares the surface's drawable pointer against
> the drawable in the last call to dri_make_current and assumes it's the same
> surface (which it isn't).
>
> When texture_stamp is left unset, then dri_st_framebuffer_validate thinks
> it has already called update_drawable_info for that drawable, leaving it
> unvalidated and this is when bad things starts to happen. In my case it
> manifested itself by the width and height of the surface being unset.
>
> This is fixed this by setting the pointer to NULL before freeing the
> surface.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106126
> Signed-off-by: Johan Klokkhammer Helsing 
> ---
>  src/gallium/state_trackers/dri/dri_drawable.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri_drawable.c 
> b/src/gallium/state_trackers/dri/dri_drawable.c
> index e5a7537e47..02328acd98 100644
> --- a/src/gallium/state_trackers/dri/dri_drawable.c
> +++ b/src/gallium/state_trackers/dri/dri_drawable.c
> @@ -185,6 +185,7 @@ fail:
>  void
>  dri_destroy_buffer(__DRIdrawable * dPriv)
>  {
> +   struct dri_context *ctx = dri_context(dPriv->driContextPriv);
> struct dri_drawable *drawable = dri_drawable(dPriv);
> struct dri_screen *screen = drawable->screen;
> struct st_api *stapi = screen->st_api;
> @@ -202,6 +203,9 @@ dri_destroy_buffer(__DRIdrawable * dPriv)
> /* Notify the st manager that this drawable is no longer valid */
> stapi->destroy_drawable(stapi, >base);
>
> +   if (ctx && ctx->dPriv == dPriv)
> +  ctx->dPriv = NULL;
> +
Context references in here feels wrong.

Are you sure we shouldn't be removing the context/drawable link in
dri_make_current?
After all it seems to be the one that adds it in the first place.

Something like the following:

--- a/src/gallium/state_trackers/dri/dri_context.c
+++ b/src/gallium/state_trackers/dri/dri_context.c
@@ -278,9 +278,16 @@ dri_make_current(__DRIcontext * cPriv,

++ctx->bind_count;

-   if (!draw && !read)
-  return ctx->stapi->make_current(ctx->stapi, ctx->st, NULL, NULL);
-   else if (!draw || !read)
+   if (!draw && !read) {
+  if (!ctx->stapi->make_current(ctx->stapi, ctx->st, NULL, NULL))
+ return GL_FALSE;
+
+  ctx->dPriv = NULL;
+  ctx->rPriv = NULL;
+  return GL_TRUE;
+   }
+
+   if (!draw || !read)
   return GL_FALSE;

if (ctx->dPriv != driDrawPriv) {

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

[Mesa-dev] [Bug 84805] DEF files missing for GLES1/GLES2

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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] unlock android graphic buffer spend too much time

[Tapani Pälli]

Hi;

On 23.04.2018 13:13, Zong, Wei wrote:

Hi Dear Mesa experts,

I'm reading android graphic buffer by calling “*GraphicBuffer::lock” 
*with parameter "GRALLOC_USAGE_SW_READ_OFTEN | 
GRALLOC_USAGE_SW_WRITE_NEVER", I copied the buffer into a CPU allocated 
memory only cost less than 1 millisecond. the resolution of this graphic 
buffer is 1280×800, and the image format is “V4L2_PIX_FMT_NV12”


After finishing memory copy, I called*“GraphicBuffer::unlock*”, this 
operation spent more than 3 milliseconds, I guess this unlock operation 
would not do much work, I'm wondering if this 3ms can be saved? Or this 
3ms is sure necessary for such operation?


This is not really a Mesa question so I think you want to ask this also 
on some other list, not sure which one though. This is specific to 
gralloc implementation. I'm guessing this is about Android-IA so you 
probably want to discuss this with minigbm module maintainers and 
checking what happens during your usecase there.


Note that there are also async versions of lock and lockYCbCr available 
.. but hopefully you could just avoid such copy.


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

[Mesa-dev] [PATCH] intel/decoder: Use gen_group::dw_length when available

[Topi Pohjolainen]

Otherwise gen_group_get_length() will try to use first fields
of, for example, CC_VIEWPORT and SF_CLIP to determine the
group size. These packets are not present in the state with
full header but simply with their contents while equivalent
state pointers (3DSTATE_VIEWPORT_STATE_POINTERS_CC and
3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP respectively) telling
their starting points.

Before:
---

0xfffef540:  0x7823:  3DSTATE_VIEWPORT_STATE_POINTERS_CC

0xfffef540:  0x7823 : Dword 0
DWord Length: 0
0xfffef544:  0x0180 : Dword 1
CC Viewport Pointer: 0x0180
CC_VIEWPORT 0
0xfffea180:  0x : Dword 0
Minimum Depth: 0.00
0xfffef548:  0x7821:  3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP
0xfffef548:  0x7821 : Dword 0
DWord Length: 0
0xfffef54c:  0x01c0 : Dword 1
SF Clip Viewport Pointer: 0x01c0
SF_CLIP_VIEWPORT 0
0xfffea1c0:  0x4100 : Dword 0
Viewport Matrix Element m00: 0.00
0xfffea1c4:  0x3f00 : Dword 1
Viewport Matrix Element m11: 0.50
0xfffef550:  0x7824:  3DSTATE_BLEND_STATE_POINTERS

After:
--

0xfffef540:  0x7823:  3DSTATE_VIEWPORT_STATE_POINTERS_CC

0xfffef540:  0x7823 : Dword 0
DWord Length: 0
0xfffef544:  0x0180 : Dword 1
CC Viewport Pointer: 0x0180
CC_VIEWPORT 0
0xfffea180:  0x : Dword 0
Minimum Depth: 0.00
0xfffea184:  0x3f80 : Dword 1
Maximum Depth: 1.00
0xfffef548:  0x7821:  3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP
0xfffef548:  0x7821 : Dword 0
DWord Length: 0
0xfffef54c:  0x01c0 : Dword 1
SF Clip Viewport Pointer: 0x01c0
SF_CLIP_VIEWPORT 0
0xfffea1c0:  0x4100 : Dword 0
Viewport Matrix Element m00: 0.00
0xfffea1c4:  0x3f00 : Dword 1
Viewport Matrix Element m11: 0.50
0xfffea1c8:  0x3f00 : Dword 2
Viewport Matrix Element m22: 0.50
0xfffea1cc:  0x4100 : Dword 3
Viewport Matrix Element m30: 8.00
0xfffea1d0:  0x3f00 : Dword 4
Viewport Matrix Element m31: 0.50
0xfffea1d4:  0x3f00 : Dword 5
Viewport Matrix Element m32: 0.50
0xfffea1d8:  0x : Dword 6
0xfffea1dc:  0x : Dword 7
0xfffea1e0:  0xc500 : Dword 8
X Min Clip Guardband: -2048.00
0xfffea1e4:  0x4500 : Dword 9
X Max Clip Guardband: 2048.00
0xfffea1e8:  0xc700 : Dword 10
Y Min Clip Guardband: -32768.00
0xfffea1ec:  0x4700 : Dword 11
Y Max Clip Guardband: 32768.00
0xfffea1f0:  0x : Dword 12
X Min ViewPort: 0.00
0xfffea1f4:  0x4170 : Dword 13
X Max ViewPort: 15.00
0xfffea1f8:  0x : Dword 14
Y Min ViewPort: 0.00
0xfffea1fc:  0x : Dword 15
Y Max ViewPort: 0.00

CC: Lionel Landwerlin 
CC: Kenneth Graunke 
Signed-off-by: Topi Pohjolainen 
---
 src/intel/common/gen_decoder.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 1b8123b..cc212cc 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -713,6 +713,9 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
 int
 gen_group_get_length(struct gen_group *group, const uint32_t *p)
 {
+   if (group->dw_length)
+  return group->dw_length;
+
uint32_t h = p[0];
uint32_t type = field_value(h, 29, 31);
 
-- 
2.7.4

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

Bug ID: 106187
   Summary: Vulkan apps run on secondary GPU on multi-GPU system
   Product: Mesa
   Version: 17.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: bri...@outlook.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 138997
  --> https://bugs.freedesktop.org/attachment.cgi?id=138997=edit
GPU selection in launcher for RotTR

I have two Sapphire R9 Fury's and Vulkan apps default to run on my secondary
headless card which performs worse compared to using the primary card.

I was actually in contact with Feral Interactive support about this after
seeing the issue in Rise of the Tomb Raider, but they claim it's a Vulkan
loader or driver issue, so why don't I just paste the e-mail here as it
describes the problem in more detail:

"Hi Feral!
This isn't really a support request. It's more of a suggestion for improving
performance on multi-GPU systems.
I'm on Debian Sid with kernel 4.15 and Mesa 17.3.9 and noticed that Vulkan
games, including Rise of the Tomb Raider runs on my secondary GPU.
By switching over to my primary GPU in the Feral launcher, I've increased my
benchmark score from 60fps to 73fps (1080p high) and the game runs noticably
smoother. This is something I have to do every time I launch the game becouse
the setting resets between play sessions.
I'ts a bit wierd that the primary GPU is in the bottom of the list. I wonder if
this is a RADV issue since it happens in all Vulkan applications, including non
Feral apps.


Debian Sid
Kernel 4.15
Mesa 17.3.9
Ryzen 1700X
Asus PRIME X370-PRO
32GiB DDR4-2400 cl14
Sapphire Nitro R9 Fury (two of them)"

-- 
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] ac/nir: fix image dimension for subpass attachments

[Nicolai Hähnle]

On 20.04.2018 18:06, Samuel Pitoiset wrote:

For subpass attachments we need one more coordinate with
the sample index, so make them array types.


Sorry about that. Shouldn't it be layer index instead of sample index 
though?


If I understand this right, I think it would be cleaner to just change 
get_ac_sampler_dim to say:


case GLSL_SAMPLER_DIM_SUBPASS:
return ac_image_2darray;
case GLSL_SAMPLER_DIM_SUBPASS_MS:
return ac_image_2darraymsaa;

That way, the code very clearly documents that subpasses are always of 
array type.


Thanks,
Nicolai





This fixes a bunch of CTS fails with RADV.

Fixes: 24fb3e6aa1 ("ac/nir: use ac_build_image_opcode for image intrinsics")
Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 18 +++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index ba7f353a9a..72c773522f 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2090,6 +2090,18 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
return sample_index;
  }
  
+static bool

+glsl_is_array_image(const struct glsl_type *type)
+{
+   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+
+   if (glsl_sampler_type_is_array(type))
+   return true;
+
+   return dim == GLSL_SAMPLER_DIM_SUBPASS ||
+  dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
+}
+
  static void get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr,
 struct ac_image_args *args)
@@ -2235,7 +2247,7 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_sampler_type_is_array(type));
+   glsl_is_array_image(type));
args.dmask = 15;
args.attributes = AC_FUNC_ATTR_READONLY;
if (var->data.image._volatile || var->data.image.coherent)
@@ -2278,7 +2290,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_sampler_type_is_array(type));
+   glsl_is_array_image(type));
args.dmask = 15;
if (force_glc || var->data.image._volatile || 
var->data.image.coherent)
args.cache_policy |= ac_glc;
@@ -2369,7 +2381,7 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_sampler_type_is_array(type));
+   glsl_is_array_image(type));
  
  		return ac_build_image_opcode(>ac, );

}




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #1 from Mike Lothian  ---
In a laptop situation the 2nd card is usually the more powerful - least this
app lets you choose which card.

If you run vulkaninfo, which card is listed first?

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #3 from Kristoffer  ---
I can't really tell which shows up first when running vulkaninfo because they
look identical.

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

Re: [Mesa-dev] [PATCH 1/2] ac/radv/radeonsi: refactor raster_config default values getters.

[Nicolai Hähnle]

For the series:

Reviewed-by: Nicolai Hähnle 

On 23.04.2018 02:17, Dave Airlie wrote:

From: Dave Airlie 

This just makes this common code between the two drivers.
---
  src/amd/common/ac_gpu_info.c| 93 +
  src/amd/common/ac_gpu_info.h|  4 +-
  src/amd/vulkan/si_cmd_buffer.c  | 85 ++
  src/gallium/drivers/radeonsi/si_state.c | 84 ++---
  4 files changed, 102 insertions(+), 164 deletions(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 12b03c4ea29..47a87650a6d 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -554,3 +554,96 @@ ac_get_gs_table_depth(enum chip_class chip_class, enum 
radeon_family family)
unreachable("Unknown GPU");
}
  }
+
+void
+ac_get_raster_config(struct radeon_info *info,
+uint32_t *raster_config_p,
+uint32_t *raster_config_1_p)
+{
+   unsigned num_rb = MIN2(info->num_render_backends, 16);
+   unsigned raster_config, raster_config_1;
+   switch (info->family) {
+   case CHIP_TAHITI:
+   case CHIP_PITCAIRN:
+   raster_config = 0x2a00126a;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_VERDE:
+   raster_config = 0x124a;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_OLAND:
+   raster_config = 0x0082;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_HAINAN:
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_BONAIRE:
+   raster_config = 0x1612;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_HAWAII:
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   break;
+   case CHIP_FIJI:
+   if (info->cik_macrotile_mode_array[0] == 0x00e8) {
+   /* old kernels with old tiling config */
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   } else {
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   }
+   break;
+   case CHIP_POLARIS10:
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   break;
+   case CHIP_POLARIS11:
+   case CHIP_POLARIS12:
+   raster_config = 0x1612;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_VEGAM:
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   break;
+   case CHIP_TONGA:
+   raster_config = 0x1612;
+   raster_config_1 = 0x002a;
+   break;
+   case CHIP_ICELAND:
+   if (num_rb == 1)
+   raster_config = 0x;
+   else
+   raster_config = 0x0002;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_CARRIZO:
+   raster_config = 0x0002;
+   raster_config_1 = 0x;
+   break;
+   case CHIP_KAVERI:
+   /* KV should be 0x0002, but that causes problems with 
radeon */
+   raster_config = 0x; /* 0x0002 */
+   raster_config_1 = 0x;
+   break;
+   case CHIP_KABINI:
+   case CHIP_MULLINS:
+   case CHIP_STONEY:
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   default:
+   fprintf(stderr,
+   "ac: Unknown GPU, using 0 for raster_config\n");
+   raster_config = 0x;
+   raster_config_1 = 0x;
+   break;
+   }
+   *raster_config_p = raster_config;
+   *raster_config_1_p = raster_config_1;
+}
diff --git a/src/amd/common/ac_gpu_info.h b/src/amd/common/ac_gpu_info.h
index 003d340e0c1..9227ff37799 100644
--- a/src/amd/common/ac_gpu_info.h
+++ b/src/amd/common/ac_gpu_info.h
@@ -131,7 +131,9 @@ void ac_compute_driver_uuid(char *uuid, size_t size);
  void ac_compute_device_uuid(struct radeon_info *info, char *uuid, size_t 
size);
  void ac_print_gpu_info(struct radeon_info *info);
  int ac_get_gs_table_depth(enum chip_class chip_class, enum radeon_family 
family);
-
+void ac_get_raster_config(struct radeon_info *info,
+ uint32_t *raster_config_p,
+ uint32_t *raster_config_1_p);
  #ifdef __cplusplus
  }
  #endif
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c

[Mesa-dev] [PATCH] ac/nir: add missing round_slice for 1D arrays

[Samuel Pitoiset]

This fixes a bunch of CTS fails with 1D arrays:

dEQP-VK.glsl.texture_functions.texture*.sampler1darray_*

Fixes: 625dcbbc456 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 72c773522f4..34efb2b9fe1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3397,6 +3397,13 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
}
 
/* Texture coordinates fixups */
+   if (instr->coord_components > 1 &&
+   instr->sampler_dim == GLSL_SAMPLER_DIM_1D &&
+   instr->is_array &&
+   instr->op != nir_texop_txf) {
+   args.coords[1] = apply_round_slice(>ac, args.coords[1]);
+   }
+
if (instr->coord_components > 2 &&
(instr->sampler_dim == GLSL_SAMPLER_DIM_2D ||
 instr->sampler_dim == GLSL_SAMPLER_DIM_MS ||
-- 
2.17.0

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

[Mesa-dev] unlock android graphic buffer spend too much time

[Zong, Wei]

Hi Dear Mesa experts,



I'm reading android graphic buffer by calling “GraphicBuffer::lock” with 
parameter "GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_NEVER", I 
copied the buffer into a CPU allocated memory only cost less than 1 
millisecond. the resolution of this graphic buffer is 1280×800, and the image 
format is “V4L2_PIX_FMT_NV12”



After finishing memory copy, I called “GraphicBuffer::unlock”, this operation 
spent more than 3 milliseconds, I guess this unlock operation would not do much 
work, I'm wondering if this 3ms can be saved? Or this 3ms is sure necessary for 
such operation?



The hardware I’m using is Broxton, and graphic driver is Mesa 18.1.0-devel.



Thanks,

Zong Wei


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

[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #19 from Timothy Arceri  ---
Piglit test was pushed long ago. Closing.

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

Re: [Mesa-dev] [PATCH 2/2] ac/radv/radeonsi: refactor harvest config register getters.

[Nicolai Hähnle]

Acked-by: Nicolai Hähnle 

On 23.04.2018 02:43, Dave Airlie wrote:

From: Dave Airlie 

This refactors the code out to share it between radv and radeonsi.
---
  src/amd/common/ac_gpu_info.c| 113 
  src/amd/common/ac_gpu_info.h|   4 ++
  src/amd/vulkan/si_cmd_buffer.c  | 108 ++
  src/gallium/drivers/radeonsi/si_state.c | 111 ++-
  4 files changed, 130 insertions(+), 206 deletions(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 47a87650a6d..031fd183b6f 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -647,3 +647,116 @@ ac_get_raster_config(struct radeon_info *info,
*raster_config_p = raster_config;
*raster_config_1_p = raster_config_1;
  }
+
+void
+ac_get_harvested_configs(struct radeon_info *info,
+unsigned raster_config,
+unsigned *cik_raster_config_1_p,
+unsigned *raster_config_se)
+{
+   unsigned sh_per_se = MAX2(info->max_sh_per_se, 1);
+   unsigned num_se = MAX2(info->max_se, 1);
+   unsigned rb_mask = info->enabled_rb_mask;
+   unsigned num_rb = MIN2(info->num_render_backends, 16);
+   unsigned rb_per_pkr = MIN2(num_rb / num_se / sh_per_se, 2);
+   unsigned rb_per_se = num_rb / num_se;
+   unsigned se_mask[4];
+   unsigned se;
+
+   se_mask[0] = ((1 << rb_per_se) - 1) & rb_mask;
+   se_mask[1] = (se_mask[0] << rb_per_se) & rb_mask;
+   se_mask[2] = (se_mask[1] << rb_per_se) & rb_mask;
+   se_mask[3] = (se_mask[2] << rb_per_se) & rb_mask;
+
+   assert(num_se == 1 || num_se == 2 || num_se == 4);
+   assert(sh_per_se == 1 || sh_per_se == 2);
+   assert(rb_per_pkr == 1 || rb_per_pkr == 2);
+
+
+   if (info->chip_class >= CIK) {
+   unsigned raster_config_1 = *cik_raster_config_1_p;
+   if ((num_se > 2) && ((!se_mask[0] && !se_mask[1]) ||
+(!se_mask[2] && !se_mask[3]))) {
+   raster_config_1 &= C_028354_SE_PAIR_MAP;
+
+   if (!se_mask[0] && !se_mask[1]) {
+   raster_config_1 |=
+   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_3);
+   } else {
+   raster_config_1 |=
+   
S_028354_SE_PAIR_MAP(V_028354_RASTER_CONFIG_SE_PAIR_MAP_0);
+   }
+   *cik_raster_config_1_p = raster_config_1;
+   }
+   }
+
+   for (se = 0; se < num_se; se++) {
+   unsigned pkr0_mask = ((1 << rb_per_pkr) - 1) << (se * 
rb_per_se);
+   unsigned pkr1_mask = pkr0_mask << rb_per_pkr;
+   int idx = (se / 2) * 2;
+
+   raster_config_se[se] = raster_config;
+   if ((num_se > 1) && (!se_mask[idx] || !se_mask[idx + 1])) {
+   raster_config_se[se] &= C_028350_SE_MAP;
+
+   if (!se_mask[idx]) {
+   raster_config_se[se] |=
+   
S_028350_SE_MAP(V_028350_RASTER_CONFIG_SE_MAP_3);
+   } else {
+   raster_config_se[se] |=
+   
S_028350_SE_MAP(V_028350_RASTER_CONFIG_SE_MAP_0);
+   }
+   }
+
+   pkr0_mask &= rb_mask;
+   pkr1_mask &= rb_mask;
+   if (rb_per_se > 2 && (!pkr0_mask || !pkr1_mask)) {
+   raster_config_se[se] &= C_028350_PKR_MAP;
+
+   if (!pkr0_mask) {
+   raster_config_se[se] |=
+   
S_028350_PKR_MAP(V_028350_RASTER_CONFIG_PKR_MAP_3);
+   } else {
+   raster_config_se[se] |=
+   
S_028350_PKR_MAP(V_028350_RASTER_CONFIG_PKR_MAP_0);
+   }
+   }
+
+   if (rb_per_se >= 2) {
+   unsigned rb0_mask = 1 << (se * rb_per_se);
+   unsigned rb1_mask = rb0_mask << 1;
+
+   rb0_mask &= rb_mask;
+   rb1_mask &= rb_mask;
+   if (!rb0_mask || !rb1_mask) {
+   raster_config_se[se] &= C_028350_RB_MAP_PKR0;
+
+   if (!rb0_mask) {
+   raster_config_se[se] |=
+   
S_028350_RB_MAP_PKR0(V_028350_RASTER_CONFIG_RB_MAP_3);
+   } else {
+   raster_config_se[se] |=
+   

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #2 from Kristoffer  ---
Created attachment 138998
  --> https://bugs.freedesktop.org/attachment.cgi?id=138998=edit
vulkaninfo

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

Re: [Mesa-dev] [PATCH 4/4] gallivm: dump bitcode before optimization

[Jose Fonseca]

On 23/04/18 05:24, srol...@vmware.com wrote:

From: Roland Scheidegger 

If we dump the bitcode for off-line debug purposes, we really want the
pre-optimized bitcode, otherwise it's useless in identifying problems
with IR optimization (if you have a shader which takes an hour to do
IR optimization, it's also nice you don't have to wait that hour...).
Also, print out the function passes for opt which correspond to what
was used for jit compilation (and also the opt level for codegen).
Using opt/llc this way should then pretty much mimic what was done
for jit. (When specifying something like -time-passes
-debug-pass=[Structure|Arguments] (for either opt or llc) that also
gives very useful information in which passes all the time was spent,
and which passes are really run along with the order - llvm will add
passes due to dependencies on its own, and of course -O2 for llc
comes with a ~100 pass list.)
---
  src/gallium/auxiliary/gallivm/lp_bld_init.c | 35 +
  1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index d0afff1..41d828c 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -142,6 +142,10 @@ create_pass_manager(struct gallivm_state *gallivm)
 * TODO: Evaluate passes some more - keeping in mind
 * both quality of generated code and compile times.
 */
+  /*
+   * NOTE: if you change this, don't forget to change the output
+   * with GALLIVM_DEBUG_DUMP_BC in gallivm_compile_module.
+   */
LLVMAddScalarReplAggregatesPass(gallivm->passmgr);
LLVMAddEarlyCSEPass(gallivm->passmgr);
LLVMAddCFGSimplificationPass(gallivm->passmgr);
@@ -151,7 +155,7 @@ create_pass_manager(struct gallivm_state *gallivm)
 * due to licm implying lcssa (since llvm 3.5), which can take forever.
 * Even for sane shaders, the cost of licm is rather high (and not just
 * due to lcssa, licm itself too), though mostly only in cases when it
-   * can actually move things, so having to disable it is a pity.
+   * can actually move things, so having to disable it is a pity.
 * LLVMAddLICMPass(gallivm->passmgr);
 */
LLVMAddReassociatePass(gallivm->passmgr);
@@ -597,6 +601,22 @@ gallivm_compile_module(struct gallivm_state *gallivm)
gallivm->builder = NULL;
 }
  
+   /* Dump bitcode to a file */

+   if (gallivm_debug & GALLIVM_DEBUG_DUMP_BC) {
+  char filename[256];
+  assert(gallivm->module_name);
+  util_snprintf(filename, sizeof(filename), "ir_%s.bc", 
gallivm->module_name);
+  LLVMWriteBitcodeToFile(gallivm->module, filename);
+  debug_printf("%s written\n", filename);
+  debug_printf("Invoke as \"opt %s %s | llc -O%d %s%s\"\n",
+   gallivm_debug & GALLIVM_DEBUG_NO_OPT ? "-mem2reg" :
+   "-sroa -early-cse -simplifycfg -reassociate "
+   "-mem2reg -constprop -instcombine -gvn",
+   filename, gallivm_debug & GALLIVM_DEBUG_NO_OPT ? 0 : 2,
+   (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-mcpu option>] " : "",
+   "[-mattr=<-mattr option(s)>]");
+   }
+
 if (gallivm_debug & GALLIVM_DEBUG_PERF)
time_begin = os_time_get();
  
@@ -630,19 +650,6 @@ gallivm_compile_module(struct gallivm_state *gallivm)

 gallivm->module_name, time_msec);
 }
  
-   /* Dump byte code to a file */

-   if (gallivm_debug & GALLIVM_DEBUG_DUMP_BC) {
-  char filename[256];
-  assert(gallivm->module_name);
-  util_snprintf(filename, sizeof(filename), "ir_%s.bc", 
gallivm->module_name);
-  LLVMWriteBitcodeToFile(gallivm->module, filename);
-  debug_printf("%s written\n", filename);
-  debug_printf("Invoke as \"llc %s%s -o - %s\"\n",
-   (HAVE_LLVM >= 0x0305) ? "[-mcpu=<-mcpu option>] " : "",
-   "[-mattr=<-mattr option(s)>]",
-   filename);
-   }
-
 if (use_mcjit) {
/* Setting the module's DataLayout to an empty string will cause the
 * ExecutionEngine to copy to the DataLayout string from its target



Series looks good to me.

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

Alex Smith  changed:

   What|Removed |Added

 CC||asm...@feralinteractive.com

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

Re: [Mesa-dev] [PATCH] ac/nir: fix image dimension for subpass attachments

[Samuel Pitoiset]

On 04/23/2018 01:24 PM, Nicolai Hähnle wrote:

On 20.04.2018 18:06, Samuel Pitoiset wrote:

For subpass attachments we need one more coordinate with
the sample index, so make them array types.


Sorry about that. Shouldn't it be layer index instead of sample index 
though?


No worries!

Yes, should be layer index. I have pushed the patch on Friday but I'm 
going to send a new one with your suggestion.




If I understand this right, I think it would be cleaner to just change 
get_ac_sampler_dim to say:


 case GLSL_SAMPLER_DIM_SUBPASS:
     return ac_image_2darray;
 case GLSL_SAMPLER_DIM_SUBPASS_MS:
     return ac_image_2darraymsaa;

That way, the code very clearly documents that subpasses are always of 
array type.


Thanks,
Nicolai





This fixes a bunch of CTS fails with RADV.

Fixes: 24fb3e6aa1 ("ac/nir: use ac_build_image_opcode for image 
intrinsics")

Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 18 +++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c 
b/src/amd/common/ac_nir_to_llvm.c

index ba7f353a9a..72c773522f 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2090,6 +2090,18 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,

  return sample_index;
  }
+static bool
+glsl_is_array_image(const struct glsl_type *type)
+{
+    const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
+
+    if (glsl_sampler_type_is_array(type))
+    return true;
+
+    return dim == GLSL_SAMPLER_DIM_SUBPASS ||
+   dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
+}
+
  static void get_image_coords(struct ac_nir_context *ctx,
   const nir_intrinsic_instr *instr,
   struct ac_image_args *args)
@@ -2235,7 +2247,7 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,

  args.resource = get_sampler_desc(ctx, instr->variables[0],
   AC_DESC_IMAGE, NULL, true, false);
  args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),

-    glsl_sampler_type_is_array(type));
+    glsl_is_array_image(type));
  args.dmask = 15;
  args.attributes = AC_FUNC_ATTR_READONLY;
  if (var->data.image._volatile || var->data.image.coherent)
@@ -2278,7 +2290,7 @@ static void visit_image_store(struct 
ac_nir_context *ctx,

  args.resource = get_sampler_desc(ctx, instr->variables[0],
   AC_DESC_IMAGE, NULL, true, false);
  args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),

-    glsl_sampler_type_is_array(type));
+    glsl_is_array_image(type));
  args.dmask = 15;
  if (force_glc || var->data.image._volatile || 
var->data.image.coherent)

  args.cache_policy |= ac_glc;
@@ -2369,7 +2381,7 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,

  args.resource = get_sampler_desc(ctx, instr->variables[0],
   AC_DESC_IMAGE, NULL, true, false);
  args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),

-    glsl_sampler_type_is_array(type));
+    glsl_is_array_image(type));
  return ac_build_image_opcode(>ac, );
  }





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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #5 from Marc Di Luzio  ---
(In reply to Mike Lothian from comment #4)
> As for selecting the first one automatically, I think the Launcher should be
> remembering the card you last used, and that would be up to Feral to fix

Figured I'd drop in here.

So the underlying issue here is that the two cards returned by
vkEnumeratePhysicalDevices are effectively identical, so we try and select the
same card we had before, and since they both match it picks the first. We also
end up defaulting to the first because we have to mostly assume the first one
is the primary, given no other viable information on that matter.

It'd be beneficial, if the performance difference isn't resolvable, to somehow
return the "primary" card first in the vkEnumeratePhysicalDevices list.

However, we'll track the failure to remember internally and see if we can deal
with it for now based on the order we're given the duplicates.

-- 
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 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #6 from Kristoffer  ---
(In reply to Mike Lothian from comment #4)
> I wonder if that's a bug in the PRIME code, I wouldn't have expected to see
> a drop in FPS that much if the cards are identical. Out of interest, do you
> see differences at other resolutions?
> 
> As for selecting the first one automatically, I think the Launcher should be
> remembering the card you last used, and that would be up to Feral to fix

1440p high
"Primary" GPU: 55fps
"Secondary" GPU: 47fps

-- 
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 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
There is extra overhead when using secondary GPUs in conjunction with prime
when you want to see the results on the display.  The display is only attached
to one GPU so when you render with the other GPU, the contents have to be
copied to the GPU with the display in order to see the results.

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

Re: [Mesa-dev] [PATCH 2/3] Autotools: Add passes.h to sources so it will be included in the tarball

[Kyriazis, George]

I agree on the commit message wording.

Sorry about missing passes.h in the original check-in.

Reviewed-by: George Kyriazis 
>

On Apr 20, 2018, at 10:00 PM, Kenneth Graunke 
> wrote:

On Friday, April 20, 2018 7:19:50 PM PDT Dylan Baker wrote:
Signed-off-by: Dylan Baker 
>
---
src/gallium/drivers/swr/Makefile.sources | 1 +
1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/swr/Makefile.sources 
b/src/gallium/drivers/swr/Makefile.sources
index dd815dcb581..a06d1d7b929 100644
--- a/src/gallium/drivers/swr/Makefile.sources
+++ b/src/gallium/drivers/swr/Makefile.sources
@@ -155,6 +155,7 @@ JITTER_CXX_SOURCES := \
rasterizer/jitter/streamout_jit.cpp \
rasterizer/jitter/streamout_jit.h \
rasterizer/jitter/shader_lib/DebugOutput.cpp \
+ rasterizer/jitter/functionpasses/passes.h \
rasterizer/jitter/functionpasses/lower_x86.cpp

MEMORY_CXX_SOURCES := \


I would add the following to the commit message:

This was introduced in commit 8f848ada8a42d9aaa8136afa1bafe32281a0fb48
but not added to the sources list, which is necessary for it to be
included in release tarballs.

Fixes: 8f848ada8a42d9aaa8136afa1bafe32281a0fb48 (swr/rast: Start refactoring of 
builder/packetizer.)
Reviewed-by: Kenneth Graunke 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Mesa-dev] [PATCH] ac: teach get_ac_sampler_dim() about subpass attachments

[Samuel Pitoiset]

Suggested by Nicolai.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 34efb2b9fe1..900c1c4afea 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -87,7 +87,6 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
glsl_sampler_dim dim,
return is_array ? ac_image_1darray : ac_image_1d;
case GLSL_SAMPLER_DIM_2D:
case GLSL_SAMPLER_DIM_RECT:
-   case GLSL_SAMPLER_DIM_SUBPASS:
case GLSL_SAMPLER_DIM_EXTERNAL:
return is_array ? ac_image_2darray : ac_image_2d;
case GLSL_SAMPLER_DIM_3D:
@@ -95,8 +94,11 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
glsl_sampler_dim dim,
case GLSL_SAMPLER_DIM_CUBE:
return ac_image_cube;
case GLSL_SAMPLER_DIM_MS:
-   case GLSL_SAMPLER_DIM_SUBPASS_MS:
return is_array ? ac_image_2darraymsaa : ac_image_2dmsaa;
+   case GLSL_SAMPLER_DIM_SUBPASS:
+   return ac_image_2darray;
+   case GLSL_SAMPLER_DIM_SUBPASS_MS:
+   return ac_image_2darraymsaa;
default:
unreachable("bad sampler dim");
}
@@ -2090,18 +2092,6 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
return sample_index;
 }
 
-static bool
-glsl_is_array_image(const struct glsl_type *type)
-{
-   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
-
-   if (glsl_sampler_type_is_array(type))
-   return true;
-
-   return dim == GLSL_SAMPLER_DIM_SUBPASS ||
-  dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
-}
-
 static void get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr,
 struct ac_image_args *args)
@@ -2247,7 +2237,7 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
args.dmask = 15;
args.attributes = AC_FUNC_ATTR_READONLY;
if (var->data.image._volatile || var->data.image.coherent)
@@ -2290,7 +2280,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
args.dmask = 15;
if (force_glc || var->data.image._volatile || 
var->data.image.coherent)
args.cache_policy |= ac_glc;
@@ -2381,7 +2371,7 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
 
return ac_build_image_opcode(>ac, );
}
-- 
2.17.0

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #4 from Mike Lothian  ---
I wonder if that's a bug in the PRIME code, I wouldn't have expected to see a
drop in FPS that much if the cards are identical. Out of interest, do you see
differences at other resolutions?

As for selecting the first one automatically, I think the Launcher should be
remembering the card you last used, and that would be up to Feral to fix

-- 
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 76694] Inconsistent behaviour of LIBGL_DEBUG

[bugzilla-daemon]

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

Stefan Brüns  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTABUG |---

--- Comment #2 from Stefan Brüns  ---
The important part is some code parts check for *defined*, while others check
for a specific value, i.e. "quiet" and "verbose"

https://github.com/anholt/mesa/blob/master/src/glx/dri_common.c#L59

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #9 from Bas Nieuwenhuizen  ---
So I think there are several issues in this bug:

1) Running on a GPU that is not connected to the display is slower. Arguably we
should be able to optimize this a bit, especially if the two cards are
identical, but there is always some extra bus traffic that is going to happen
(and not sure if card B can directly scanout from memory in card A).

2) radv does not return the "primary" GPU first. The problem here is that there
is not really a primary GPU. You can have multiple cards, with multiple X
server, and we only know which one we are going to use for display once the app
gives us an X surface, which is after we have listed the devices. Of course the
common case is that there is only one X server running. I'm wondering if we
could reasonably do some out of band communication to figure out if there is
one X server and what GPU it uses and then preferably list that?

However, generally this is not solvable, especially when the GPUs are not
duplicate. e.g. when there is an intel iGPU + Radeon dGPU the driver does not
decide the ordering at all, the loader does.

Apps should be able to check this by checking if a specific GPU supports
present from any of its queues, but then again we enabled PRIME by default, so
radv always says yes 

A solution might be disabling PRIME by default, but that breaks any game which
just picks device 0, which is likely a lot of them ... And IMO slower
performance is better than complete breakage, especially since those games
often don't really provide a workaround.

3) As for remembering GPUs even in the duplicate case, the external memory
extensions have a GPU identifier. I know it is technically not guarantueed to
be stable, but for radv at least it should be stable across reboots (and mostly
across driver upgrades), and probably the best you can get.

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

--- Comment #7 from Kristoffer  ---
This probably goes without saying, but OpenGL and OpenCL apps does not have
this issue. They will run on the GPU or GPU's I expect them to.

For example, 'ethminer --opencl-device 0' will run on my primary while
'ethminer --opencl-device 1' will run on my secondary.

Also, if you think this is a Vulkan issue rather than driver issue then I
already opened an issue on Khronos GitHub. Feel free to join the discussion
here:

https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/2600

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

Re: [Mesa-dev] [PATCH] ac/nir: add missing round_slice for 1D arrays

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Mon, Apr 23, 2018 at 2:46 PM, Samuel Pitoiset
 wrote:
> This fixes a bunch of CTS fails with 1D arrays:
>
> dEQP-VK.glsl.texture_functions.texture*.sampler1darray_*
>
> Fixes: 625dcbbc456 ("amd/common: pass address components individually to
> ac_build_image_intrinsic")
> Cc: 18.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 72c773522f4..34efb2b9fe1 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3397,6 +3397,13 @@ static void visit_tex(struct ac_nir_context *ctx, 
> nir_tex_instr *instr)
> }
>
> /* Texture coordinates fixups */
> +   if (instr->coord_components > 1 &&
> +   instr->sampler_dim == GLSL_SAMPLER_DIM_1D &&
> +   instr->is_array &&
> +   instr->op != nir_texop_txf) {
> +   args.coords[1] = apply_round_slice(>ac, args.coords[1]);
> +   }
> +
> if (instr->coord_components > 2 &&
> (instr->sampler_dim == GLSL_SAMPLER_DIM_2D ||
>  instr->sampler_dim == GLSL_SAMPLER_DIM_MS ||
> --
> 2.17.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] anv/allocator: Don't srink either end of the block pool

[Scott D Phillips]

Jason Ekstrand  writes:

> Previously, we only tried to ensure that we didn't shrink either end
> below what was already handed out.  However, due to the way we handle
> relocations with block pools, we can't shrink the back end at all.  It's
> probably best to not shrink in either direction.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105374
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106147
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/vulkan/anv_allocator.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_allocator.c 
> b/src/intel/vulkan/anv_allocator.c
> index f884ac3..642e161 100644
> --- a/src/intel/vulkan/anv_allocator.c
> +++ b/src/intel/vulkan/anv_allocator.c
> @@ -508,12 +508,12 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct 
> anv_block_state *state)

>assert(center_bo_offset >= back_used);
>  
>/* Make sure we don't shrink the back end of the pool */
> -  if (center_bo_offset < pool->back_state.end)
> - center_bo_offset = pool->back_state.end;
> +  if (center_bo_offset < back_required)
> + center_bo_offset = back_required;
>/* Make sure that we don't shrink the front end of the pool */
> -  if (size - center_bo_offset < pool->state.end)
> - center_bo_offset = size - pool->state.end;
> +  if (size - center_bo_offset < front_required)
> + center_bo_offset = size - front_required;

Reading through the function, it's not clear to me what condition will
lead to a possible shrinking of one side or the other here. Regardless,
any calculation here based on .end, the old size, seems like it would
have to be wrong because we're trying to satisfy the post condition that
there is enough room for .next on each side. So,

Reviewed-by: Scott D Phillips 

> }
>  
> assert(center_bo_offset % PAGE_SIZE == 0);
> -- 
> 2.5.0.400.gff86faf
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac: fix the number of coordinates for ac_image_get_lod and arrays

[Samuel Pitoiset]

This fixes crashes for the following CTS:
dEQP-VK.glsl.texture_functions.query.texturequerylod.*

Fixes: 625dcbbc456 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 02739f9da9c..d5bad3eeea3 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1521,6 +1521,19 @@ LLVMValueRef ac_build_image_opcode(struct 
ac_llvm_context *ctx,
LLVMValueRef addr;
unsigned num_addr = 0;
 
+   if (a->opcode == ac_image_get_lod) {
+   switch (a->dim) {
+   case ac_image_1darray:
+   num_coords = 1;
+   break;
+   case ac_image_2darray:
+   num_coords = 2;
+   break;
+   default:
+   break;
+   }
+   }
+
if (a->offset)
args[num_addr++] = ac_to_integer(ctx, a->offset);
if (a->bias)
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] anv/allocator: Don't srink either end of the block pool

[Jason Ekstrand]

On Mon, Apr 23, 2018 at 8:33 AM, Scott D Phillips <
scott.d.phill...@intel.com> wrote:

> Jason Ekstrand  writes:
>
> > Previously, we only tried to ensure that we didn't shrink either end
> > below what was already handed out.  However, due to the way we handle
> > relocations with block pools, we can't shrink the back end at all.  It's
> > probably best to not shrink in either direction.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105374
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106147
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/intel/vulkan/anv_allocator.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_
> allocator.c
> > index f884ac3..642e161 100644
> > --- a/src/intel/vulkan/anv_allocator.c
> > +++ b/src/intel/vulkan/anv_allocator.c
> > @@ -508,12 +508,12 @@ anv_block_pool_grow(struct anv_block_pool *pool,
> struct anv_block_state *state)
>
> >assert(center_bo_offset >= back_used);
> >
> >/* Make sure we don't shrink the back end of the pool */
> > -  if (center_bo_offset < pool->back_state.end)
> > - center_bo_offset = pool->back_state.end;
> > +  if (center_bo_offset < back_required)
> > + center_bo_offset = back_required;
> >/* Make sure that we don't shrink the front end of the pool */
> > -  if (size - center_bo_offset < pool->state.end)
> > - center_bo_offset = size - pool->state.end;
> > +  if (size - center_bo_offset < front_required)
> > + center_bo_offset = size - front_required;
>
> Reading through the function, it's not clear to me what condition will
> lead to a possible shrinking of one side or the other here. Regardless,
> any calculation here based on .end, the old size, seems like it would
> have to be wrong because we're trying to satisfy the post condition that
> there is enough room for .next on each side. So,
>

The problem is that he balancing algorithm above this isn't perfect and can
accidentally try to shrink one side or the other.  The logic fixed here was
intended to prevent that but didn't prevent it hard enough.


> Reviewed-by: Scott D Phillips 
>

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

Re: [Mesa-dev] [PATCH v3 3/9] i965: Add and use a getter for the miptree aux buffer

[Nanley Chery]

On Fri, Apr 20, 2018 at 03:51:34PM -0700, Rafael Antognolli wrote:
> On Fri, Apr 20, 2018 at 02:38:37PM -0700, Nanley Chery wrote:
> > On Fri, Apr 20, 2018 at 09:58:38AM -0700, Rafael Antognolli wrote:
> > > Nice, I was planning to do something like this later but didn't want to
> > > include many more changes on my ongoing series. This looks great, just a
> > > little comment below.
> > > 
> > > On Wed, Apr 11, 2018 at 01:42:20PM -0700, Nanley Chery wrote:
> > > > Make the next patch easier to read by eliminating most of the would-be
> > > > duplicate field accesses now.
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_blorp.c|  8 ++--
> > > >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +---
> > > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 24 
> > > > 
> > > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 17 +
> > > >  4 files changed, 24 insertions(+), 41 deletions(-)
> > > > 
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> > > > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > index 5dcd95e9f44..962a316c5cf 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > @@ -154,12 +154,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > > >.aux_usage = aux_usage,
> > > > };
> > > >  
> > > > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > > > -   if (mt->mcs_buf)
> > > > -  aux_buf = mt->mcs_buf;
> > > > -   else if (mt->hiz_buf)
> > > > -  aux_buf = mt->hiz_buf;
> > > > -
> > > > if (mt->format == MESA_FORMAT_S_UINT8 && is_render_target &&
> > > > devinfo->gen <= 7)
> > > >mt->r8stencil_needs_update = true;
> > > > @@ -174,6 +168,8 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > > > */
> > > >surf->clear_color = mt->fast_clear_color;
> > > >  
> > > > +  struct intel_miptree_aux_buffer *aux_buf =
> > > > + intel_miptree_get_aux_buffer(mt);
> > > >surf->aux_surf = _buf->surf;
> > > >surf->aux_addr = (struct blorp_address) {
> > > >   .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> > > > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > index 3fb101bf68b..06f739faf61 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > @@ -155,21 +155,7 @@ brw_emit_surface_state(struct brw_context *brw,
> > > > struct brw_bo *aux_bo = NULL;
> > > > struct isl_surf *aux_surf = NULL;
> > > > uint64_t aux_offset = 0;
> > > > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > > > -   switch (aux_usage) {
> > > > -   case ISL_AUX_USAGE_MCS:
> > > > -   case ISL_AUX_USAGE_CCS_D:
> > > > -   case ISL_AUX_USAGE_CCS_E:
> > > > -  aux_buf = mt->mcs_buf;
> > > > -  break;
> > > > -
> > > > -   case ISL_AUX_USAGE_HIZ:
> > > > -  aux_buf = mt->hiz_buf;
> > > > -  break;
> > > > -
> > > > -   case ISL_AUX_USAGE_NONE:
> > > > -  break;
> > > > -   }
> > > > +   struct intel_miptree_aux_buffer *aux_buf = 
> > > > intel_miptree_get_aux_buffer(mt);
> > > >  
> > > > if (aux_usage != ISL_AUX_USAGE_NONE) {
> > > >aux_surf = _buf->surf;
> > > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > index d95128de119..ba5b02bc0aa 100644
> > > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > @@ -1249,8 +1249,7 @@ intel_miptree_release(struct intel_mipmap_tree 
> > > > **mt)
> > > >brw_bo_unreference((*mt)->bo);
> > > >intel_miptree_release(&(*mt)->stencil_mt);
> > > >intel_miptree_release(&(*mt)->r8stencil_mt);
> > > > -  intel_miptree_aux_buffer_free((*mt)->hiz_buf);
> > > > -  intel_miptree_aux_buffer_free((*mt)->mcs_buf);
> > > > +  intel_miptree_aux_buffer_free(intel_miptree_get_aux_buffer(*mt));
> > > >free_aux_state_map((*mt)->aux_state);
> > > >  
> > > >intel_miptree_release(&(*mt)->plane[0]);
> > > > @@ -2876,31 +2875,16 @@ intel_miptree_make_shareable(struct brw_context 
> > > > *brw,
> > > >  0, INTEL_REMAINING_LAYERS,
> > > >  ISL_AUX_USAGE_NONE, false);
> > > >  
> > > > -   if (mt->mcs_buf) {
> > > > -  intel_miptree_aux_buffer_free(mt->mcs_buf);
> > > > +   struct intel_miptree_aux_buffer *aux_buf = 
> > > > intel_miptree_get_aux_buffer(mt);
> > > > +   if (aux_buf) {
> > > > +  intel_miptree_aux_buffer_free(aux_buf);
> > > >mt->mcs_buf = NULL;
> > > > -
> > > > -  /* Any pending MCS/CCS operations are no longer needed. Trying to
> > > > -   * execute any will likely crash due to the missing aux buffer. 
> > > > So let's
> > > > -   * delete all 

Re: [Mesa-dev] [PATCH] ac: teach get_ac_sampler_dim() about subpass attachments

[Bas Nieuwenhuizen]

works for me.

Reviewed-by: Bas Nieuwenhuizen 

On Mon, Apr 23, 2018 at 7:55 AM, Samuel Pitoiset
 wrote:
> Suggested by Nicolai.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 24 +++-
>  1 file changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 34efb2b9fe1..900c1c4afea 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -87,7 +87,6 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
> glsl_sampler_dim dim,
> return is_array ? ac_image_1darray : ac_image_1d;
> case GLSL_SAMPLER_DIM_2D:
> case GLSL_SAMPLER_DIM_RECT:
> -   case GLSL_SAMPLER_DIM_SUBPASS:
> case GLSL_SAMPLER_DIM_EXTERNAL:
> return is_array ? ac_image_2darray : ac_image_2d;
> case GLSL_SAMPLER_DIM_3D:
> @@ -95,8 +94,11 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
> glsl_sampler_dim dim,
> case GLSL_SAMPLER_DIM_CUBE:
> return ac_image_cube;
> case GLSL_SAMPLER_DIM_MS:
> -   case GLSL_SAMPLER_DIM_SUBPASS_MS:
> return is_array ? ac_image_2darraymsaa : ac_image_2dmsaa;
> +   case GLSL_SAMPLER_DIM_SUBPASS:
> +   return ac_image_2darray;
> +   case GLSL_SAMPLER_DIM_SUBPASS_MS:
> +   return ac_image_2darraymsaa;
> default:
> unreachable("bad sampler dim");
> }
> @@ -2090,18 +2092,6 @@ static LLVMValueRef 
> adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
> return sample_index;
>  }
>
> -static bool
> -glsl_is_array_image(const struct glsl_type *type)
> -{
> -   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
> -
> -   if (glsl_sampler_type_is_array(type))
> -   return true;
> -
> -   return dim == GLSL_SAMPLER_DIM_SUBPASS ||
> -  dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
> -}
> -
>  static void get_image_coords(struct ac_nir_context *ctx,
>  const nir_intrinsic_instr *instr,
>  struct ac_image_args *args)
> @@ -2247,7 +2237,7 @@ static LLVMValueRef visit_image_load(struct 
> ac_nir_context *ctx,
> args.resource = get_sampler_desc(ctx, instr->variables[0],
>  AC_DESC_IMAGE, NULL, true, 
> false);
> args.dim = get_ac_image_dim(>ac, 
> glsl_get_sampler_dim(type),
> -   glsl_is_array_image(type));
> +   glsl_sampler_type_is_array(type));
> args.dmask = 15;
> args.attributes = AC_FUNC_ATTR_READONLY;
> if (var->data.image._volatile || var->data.image.coherent)
> @@ -2290,7 +2280,7 @@ static void visit_image_store(struct ac_nir_context 
> *ctx,
> args.resource = get_sampler_desc(ctx, instr->variables[0],
>  AC_DESC_IMAGE, NULL, true, 
> false);
> args.dim = get_ac_image_dim(>ac, 
> glsl_get_sampler_dim(type),
> -   glsl_is_array_image(type));
> +   glsl_sampler_type_is_array(type));
> args.dmask = 15;
> if (force_glc || var->data.image._volatile || 
> var->data.image.coherent)
> args.cache_policy |= ac_glc;
> @@ -2381,7 +2371,7 @@ static LLVMValueRef visit_image_atomic(struct 
> ac_nir_context *ctx,
> args.resource = get_sampler_desc(ctx, instr->variables[0],
>  AC_DESC_IMAGE, NULL, true, 
> false);
> args.dim = get_ac_image_dim(>ac, 
> glsl_get_sampler_dim(type),
> -   glsl_is_array_image(type));
> +   glsl_sampler_type_is_array(type));
>
> return ac_build_image_opcode(>ac, );
> }
> --
> 2.17.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] glsl/glcpp: Handle hex constants with 0X prefix

[Vlad Golovkin]

2018-04-23 3:53 GMT+03:00 Timothy Arceri :
>
>
> On 20/04/18 06:08, Vlad Golovkin wrote:
>>
>> GLSL 4.6 spec describes hex constant as:
>>
>> hexadecimal-constant:
>>  0x hexadecimal-digit
>>  0X hexadecimal-digit
>>  hexadecimal-constant hexadecimal-digit
>>
>> Right now if you have a shader with the following structure:
>>
>>  #if 0X1 // or any hex number with the 0X prefix
>>  // some code
>>  #endif
>>
>> the code between #if and #endif gets removed because the checking is
>> performed
>> only for "0x" prefix which results in strtoll being called with the base 8
>> and
>> after encountering the 'X' char the strtoll returns 0. Letting strtoll
>> detect
>> the base makes this limitation go away and also makes code easier to read.
>
>
> The problem is strtoll supports much more than what GLSL allows.
>
>>
>> Also added 1 test for uppercase hex prefix.
>> ---
>>   src/compiler/glsl/glcpp/glcpp-parse.y| 9
>> ++---
>>   src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c   | 5
>> +
>>   .../glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected   | 5
>> +
>>   3 files changed, 12 insertions(+), 7 deletions(-)
>>   create mode 100644
>> src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
>>   create mode 100644
>> src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
>>
>> diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
>> b/src/compiler/glsl/glcpp/glcpp-parse.y
>> index ccb3aa18d3..d83f99f1c7 100644
>> --- a/src/compiler/glsl/glcpp/glcpp-parse.y
>> +++ b/src/compiler/glsl/glcpp/glcpp-parse.y
>> @@ -462,13 +462,8 @@ control_line_error:
>> integer_constant:
>> INTEGER_STRING {
>> -   if (strlen ($1) >= 3 && strncmp ($1, "0x", 2) == 0) {
>
>
>
> As per my coment above strtoll supports much more than what GLSL allows.
> Please just add strncmp($1, "0X", 2) == 0 to the if above.

Flex and Bison is not my strongest suit, so correct me if I am wrong,
but it seems that INTEGER_STRING can't contain leading whitespace
and/or leading plus/minus that strtoll supports.
As for the multitude of bases that strtoll supports, it would ignore
them and just choose between 8, 10 and 16 when base = 0. I think I
should have made it more clear in the code comment.

>
> That patch would have my r-b. If you send that fixed up patch I can push it
> for you. Thanks for looking into this.
>
>
>
>> -   $$ = strtoll ($1 + 2, NULL, 16);
>> -   } else if ($1[0] == '0') {
>> -   $$ = strtoll ($1, NULL, 8);
>> -   } else {
>> -   $$ = strtoll ($1, NULL, 10);
>> -   }
>> +   /* let strtoll detect the base */
>> +   $$ = strtoll ($1, NULL, 0);
>> }
>>   | INTEGER {
>> $$ = $1;
>> diff --git
>> a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
>> b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
>> new file mode 100644
>> index 00..1be9b28eb7
>> --- /dev/null
>> +++ b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
>> @@ -0,0 +1,5 @@
>> +#if 0x1234abcd == 0X1234abcd
>> +success
>> +#else
>> +failure
>> +#endif
>> diff --git
>> a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
>> b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
>> new file mode 100644
>> index 00..4cf250f6bb
>> --- /dev/null
>> +++
>> b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
>> @@ -0,0 +1,5 @@
>> +
>> +success
>> +
>> +
>> +
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/9] i965: Add and use a getter for the miptree aux buffer

[Jason Ekstrand]

Why is this useful in light of patch 4?  I don't mean to be overly critical
but the main purpose of this helper seems to be to deal with the fact that
we have two different fields.  If it's just one field, why the helper?

--Jason

On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:

> Make the next patch easier to read by eliminating most of the would-be
> duplicate field accesses now.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c|  8 ++--
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 24
> 
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 17 +
>  4 files changed, 24 insertions(+), 41 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 5dcd95e9f44..962a316c5cf 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -154,12 +154,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
>.aux_usage = aux_usage,
> };
>
> -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> -   if (mt->mcs_buf)
> -  aux_buf = mt->mcs_buf;
> -   else if (mt->hiz_buf)
> -  aux_buf = mt->hiz_buf;
> -
> if (mt->format == MESA_FORMAT_S_UINT8 && is_render_target &&
> devinfo->gen <= 7)
>mt->r8stencil_needs_update = true;
> @@ -174,6 +168,8 @@ blorp_surf_for_miptree(struct brw_context *brw,
> */
>surf->clear_color = mt->fast_clear_color;
>
> +  struct intel_miptree_aux_buffer *aux_buf =
> + intel_miptree_get_aux_buffer(mt);
>surf->aux_surf = _buf->surf;
>surf->aux_addr = (struct blorp_address) {
>   .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 3fb101bf68b..06f739faf61 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -155,21 +155,7 @@ brw_emit_surface_state(struct brw_context *brw,
> struct brw_bo *aux_bo = NULL;
> struct isl_surf *aux_surf = NULL;
> uint64_t aux_offset = 0;
> -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> -   switch (aux_usage) {
> -   case ISL_AUX_USAGE_MCS:
> -   case ISL_AUX_USAGE_CCS_D:
> -   case ISL_AUX_USAGE_CCS_E:
> -  aux_buf = mt->mcs_buf;
> -  break;
> -
> -   case ISL_AUX_USAGE_HIZ:
> -  aux_buf = mt->hiz_buf;
> -  break;
> -
> -   case ISL_AUX_USAGE_NONE:
> -  break;
> -   }
> +   struct intel_miptree_aux_buffer *aux_buf =
> intel_miptree_get_aux_buffer(mt);
>
> if (aux_usage != ISL_AUX_USAGE_NONE) {
>aux_surf = _buf->surf;
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index d95128de119..ba5b02bc0aa 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1249,8 +1249,7 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
>brw_bo_unreference((*mt)->bo);
>intel_miptree_release(&(*mt)->stencil_mt);
>intel_miptree_release(&(*mt)->r8stencil_mt);
> -  intel_miptree_aux_buffer_free((*mt)->hiz_buf);
> -  intel_miptree_aux_buffer_free((*mt)->mcs_buf);
> +  intel_miptree_aux_buffer_free(intel_miptree_get_aux_buffer(*mt));
>free_aux_state_map((*mt)->aux_state);
>
>intel_miptree_release(&(*mt)->plane[0]);
> @@ -2876,31 +2875,16 @@ intel_miptree_make_shareable(struct brw_context
> *brw,
>  0, INTEL_REMAINING_LAYERS,
>  ISL_AUX_USAGE_NONE, false);
>
> -   if (mt->mcs_buf) {
> -  intel_miptree_aux_buffer_free(mt->mcs_buf);
> +   struct intel_miptree_aux_buffer *aux_buf =
> intel_miptree_get_aux_buffer(mt);
> +   if (aux_buf) {
> +  intel_miptree_aux_buffer_free(aux_buf);
>mt->mcs_buf = NULL;
> -
> -  /* Any pending MCS/CCS operations are no longer needed. Trying to
> -   * execute any will likely crash due to the missing aux buffer. So
> let's
> -   * delete all pending ops.
> -   */
> -  free(mt->aux_state);
> -  mt->aux_state = NULL;
> -  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
> -   }
> -
> -   if (mt->hiz_buf) {
> -  intel_miptree_aux_buffer_free(mt->hiz_buf);
>mt->hiz_buf = NULL;
>
>for (uint32_t l = mt->first_level; l <= mt->last_level; ++l) {
>   mt->level[l].has_hiz = false;
>}
>
> -  /* Any pending HiZ operations are no longer needed. Trying to
> execute
> -   * any will likely crash due to the missing aux buffer. So let's
> delete
> -   * all pending ops.
> -   */
>free(mt->aux_state);
>mt->aux_state = NULL;
>brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
> diff --git 

Re: [Mesa-dev] [PATCH v3 4/9] i965: Add and use a single miptree aux_buf field

[Jason Ekstrand]

On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:

> We want to add and use a function that accesses the auxiliary buffer's
> clear_color_bo and doesn't care if it has an MCS or HiZ buffer
> specifically.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c |   4 +-
>  src/mesa/drivers/dri/i965/brw_clear.c |   4 +-
>  src/mesa/drivers/dri/i965/brw_wm.c|   2 +-
>  src/mesa/drivers/dri/i965/gen6_depth_state.c  |   6 +-
>  src/mesa/drivers/dri/i965/gen7_misc_state.c   |   4 +-
>  src/mesa/drivers/dri/i965/gen8_depth_state.c  |   6 +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 106
> +-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  42 --
>  src/mesa/drivers/dri/i965/intel_tex_image.c   |   2 +-
>  9 files changed, 80 insertions(+), 96 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index 962a316c5cf..a1882abb7cb 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -1212,7 +1212,7 @@ do_single_blorp_clear(struct brw_context *brw,
> struct gl_framebuffer *fb,
>
> /* If the MCS buffer hasn't been allocated yet, we need to allocate it
> now.
>  */
> -   if (can_fast_clear && !irb->mt->mcs_buf) {
> +   if (can_fast_clear && !irb->mt->aux_buf) {
>assert(irb->mt->aux_usage == ISL_AUX_USAGE_CCS_D);
>if (!intel_miptree_alloc_ccs(brw, irb->mt)) {
>   /* There are a few reasons in addition to out-of-memory, that can
> @@ -1611,7 +1611,7 @@ intel_hiz_exec(struct brw_context *brw, struct
> intel_mipmap_tree *mt,
> brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
> }
>
> -   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->hiz_buf);
> +   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->aux_buf);
>
> struct isl_surf isl_tmp[2];
> struct blorp_surf surf;
> diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> b/src/mesa/drivers/dri/i965/brw_clear.c
> index 487de9b8997..3d540d6d905 100644
> --- a/src/mesa/drivers/dri/i965/brw_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> @@ -240,7 +240,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
>* buffer when doing a fast clear. Since we are skipping the fast
>* clear here, we need to update the clear color ourselves.
>*/
> - uint32_t clear_offset = mt->hiz_buf->clear_color_offset;
> + uint32_t clear_offset = mt->aux_buf->clear_color_offset;
>   union isl_color_value clear_color = { .f32 = { clear_value, } };
>
>   /* We can't update the clear color while the hardware is still
> using
> @@ -249,7 +249,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
>*/
>   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
>   for (int i = 0; i < 4; i++) {
> -brw_store_data_imm32(brw, mt->hiz_buf->clear_color_bo,
> +brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
>   clear_offset + i * 4,
> clear_color.u32[i]);
>   }
>   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_
> INVALIDATE);
> diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
> b/src/mesa/drivers/dri/i965/brw_wm.c
> index 68d4ab88d77..94048cd758f 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm.c
> @@ -384,7 +384,7 @@ brw_populate_sampler_prog_key_data(struct gl_context
> *ctx,
>   if (intel_tex->mt->aux_usage == ISL_AUX_USAGE_MCS) {
>  assert(devinfo->gen >= 7);
>  assert(intel_tex->mt->surf.samples > 1);
> -assert(intel_tex->mt->mcs_buf);
> +assert(intel_tex->mt->aux_buf);
>  assert(intel_tex->mt->surf.msaa_layout ==
> ISL_MSAA_LAYOUT_ARRAY);
>  key->compressed_multisample_layout_mask |= 1 << s;
>
> diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> index 3a66b42fec1..8a1d5808051 100644
> --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> @@ -160,13 +160,13 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
>   assert(depth_mt);
>
>   uint32_t offset;
> - isl_surf_get_image_offset_B_tile_sa(_mt->hiz_buf->surf,
> + isl_surf_get_image_offset_B_tile_sa(_mt->aux_buf->surf,
>   lod, 0, 0, , NULL,
> NULL);
>
>  BEGIN_BATCH(3);
>  OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
> -OUT_BATCH(depth_mt->hiz_buf->surf.row_pitch - 1);
> -OUT_RELOC(depth_mt->hiz_buf->bo, RELOC_WRITE, offset);
> +OUT_BATCH(depth_mt->aux_buf->surf.row_pitch - 1);
> +OUT_RELOC(depth_mt->aux_buf->bo, RELOC_WRITE, offset);
>  ADVANCE_BATCH();
>} else {
>  BEGIN_BATCH(3);
> diff --git 

Re: [Mesa-dev] [PATCH v3 3/9] i965: Add and use a getter for the miptree aux buffer

[Nanley Chery]

On Mon, Apr 23, 2018 at 11:01:12AM -0700, Jason Ekstrand wrote:
> Why is this useful in light of patch 4?  I don't mean to be overly critical
> but the main purpose of this helper seems to be to deal with the fact that
> we have two different fields.  If it's just one field, why the helper?
> 
> --Jason
> 
> On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:
> 
> > Make the next patch easier to read by eliminating most of the would-be
> > duplicate field accesses now.

No worries, honest questions are welcome :) The rationale is mentioned
here in the commit message. By the way, I leave the function behind in
patch 4 because I'm currently working under the (possibly naive)
assumption that getters are a good thing in general. That said, I
haven't thought about it much and I'm not opposed to deleting it. Maybe
I shouldn't introduce two ways of getting at the same field?

-Nanley

> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  8 ++--
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 24
> > 
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 17 +
> >  4 files changed, 24 insertions(+), 41 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index 5dcd95e9f44..962a316c5cf 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -154,12 +154,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
> >.aux_usage = aux_usage,
> > };
> >
> > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > -   if (mt->mcs_buf)
> > -  aux_buf = mt->mcs_buf;
> > -   else if (mt->hiz_buf)
> > -  aux_buf = mt->hiz_buf;
> > -
> > if (mt->format == MESA_FORMAT_S_UINT8 && is_render_target &&
> > devinfo->gen <= 7)
> >mt->r8stencil_needs_update = true;
> > @@ -174,6 +168,8 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > */
> >surf->clear_color = mt->fast_clear_color;
> >
> > +  struct intel_miptree_aux_buffer *aux_buf =
> > + intel_miptree_get_aux_buffer(mt);
> >surf->aux_surf = _buf->surf;
> >surf->aux_addr = (struct blorp_address) {
> >   .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index 3fb101bf68b..06f739faf61 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -155,21 +155,7 @@ brw_emit_surface_state(struct brw_context *brw,
> > struct brw_bo *aux_bo = NULL;
> > struct isl_surf *aux_surf = NULL;
> > uint64_t aux_offset = 0;
> > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > -   switch (aux_usage) {
> > -   case ISL_AUX_USAGE_MCS:
> > -   case ISL_AUX_USAGE_CCS_D:
> > -   case ISL_AUX_USAGE_CCS_E:
> > -  aux_buf = mt->mcs_buf;
> > -  break;
> > -
> > -   case ISL_AUX_USAGE_HIZ:
> > -  aux_buf = mt->hiz_buf;
> > -  break;
> > -
> > -   case ISL_AUX_USAGE_NONE:
> > -  break;
> > -   }
> > +   struct intel_miptree_aux_buffer *aux_buf =
> > intel_miptree_get_aux_buffer(mt);
> >
> > if (aux_usage != ISL_AUX_USAGE_NONE) {
> >aux_surf = _buf->surf;
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index d95128de119..ba5b02bc0aa 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -1249,8 +1249,7 @@ intel_miptree_release(struct intel_mipmap_tree **mt)
> >brw_bo_unreference((*mt)->bo);
> >intel_miptree_release(&(*mt)->stencil_mt);
> >intel_miptree_release(&(*mt)->r8stencil_mt);
> > -  intel_miptree_aux_buffer_free((*mt)->hiz_buf);
> > -  intel_miptree_aux_buffer_free((*mt)->mcs_buf);
> > +  intel_miptree_aux_buffer_free(intel_miptree_get_aux_buffer(*mt));
> >free_aux_state_map((*mt)->aux_state);
> >
> >intel_miptree_release(&(*mt)->plane[0]);
> > @@ -2876,31 +2875,16 @@ intel_miptree_make_shareable(struct brw_context
> > *brw,
> >  0, INTEL_REMAINING_LAYERS,
> >  ISL_AUX_USAGE_NONE, false);
> >
> > -   if (mt->mcs_buf) {
> > -  intel_miptree_aux_buffer_free(mt->mcs_buf);
> > +   struct intel_miptree_aux_buffer *aux_buf =
> > intel_miptree_get_aux_buffer(mt);
> > +   if (aux_buf) {
> > +  intel_miptree_aux_buffer_free(aux_buf);
> >mt->mcs_buf = NULL;
> > -
> > -  /* Any pending MCS/CCS operations are no longer needed. Trying to
> > -   * execute any will likely crash due to the missing aux buffer. So
> > let's
> > -   * delete all pending ops.
> > -   */
> > -  free(mt->aux_state);
> > -  

Re: [Mesa-dev] [PATCH v3 5/9] i965/wm_surface_state: Use the clear address if it's non-zero

[Jason Ekstrand]

I think you want to say "clear_color_bo is non-NULL" in the commit message
rather than talking about addresses.  Otherwise, this looks like a very
nice clean-up.

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:

> We want to add and use a getter that turns off the indirect path by
> returning zero for the clear address.
> ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 17 ++---
>  1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 06f739faf61..3c70dbcc110 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -155,6 +155,8 @@ brw_emit_surface_state(struct brw_context *brw,
> struct brw_bo *aux_bo = NULL;
> struct isl_surf *aux_surf = NULL;
> uint64_t aux_offset = 0;
> +   struct brw_bo *clear_bo = NULL;
> +   uint32_t clear_offset = 0;
> struct intel_miptree_aux_buffer *aux_buf =
> intel_miptree_get_aux_buffer(mt);
>
> if (aux_usage != ISL_AUX_USAGE_NONE) {
> @@ -165,6 +167,8 @@ brw_emit_surface_state(struct brw_context *brw,
>/* We only really need a clear color if we also have an auxiliary
> * surface.  Without one, it does nothing.
> */
> +  clear_bo = aux_buf->clear_color_bo;
> +  clear_offset = aux_buf->clear_color_offset;
>clear_color = mt->fast_clear_color;
> }
>
> @@ -173,15 +177,6 @@ brw_emit_surface_state(struct brw_context *brw,
>   brw->isl_dev.ss.align,
>   surf_offset);
>
> -   bool use_clear_address = devinfo->gen >= 10 && aux_surf;
> -
> -   struct brw_bo *clear_bo = NULL;
> -   uint32_t clear_offset = 0;
> -   if (use_clear_address) {
> -  clear_bo = aux_buf->clear_color_bo;
> -  clear_offset = aux_buf->clear_color_offset;
> -   }
> -
> isl_surf_fill_state(>isl_dev, state, .surf = , .view =
> ,
> .address = brw_state_reloc(>batch,
>*surf_offset +
> brw->isl_dev.ss.addr_offset,
> @@ -190,7 +185,7 @@ brw_emit_surface_state(struct brw_context *brw,
> .aux_address = aux_offset,
> .mocs = brw_get_bo_mocs(devinfo, mt->bo),
> .clear_color = clear_color,
> -   .use_clear_address = use_clear_address,
> +   .use_clear_address = clear_bo != NULL,
> .clear_address = clear_offset,
> .x_offset_sa = tile_x, .y_offset_sa = tile_y);
> if (aux_surf) {
> @@ -222,7 +217,7 @@ brw_emit_surface_state(struct brw_context *brw,
>}
> }
>
> -   if (use_clear_address) {
> +   if (clear_bo != NULL) {
>/* Make sure the offset is aligned with a cacheline. */
>assert((clear_offset & 0x3f) == 0);
>uint32_t *clear_address =
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac: teach get_ac_sampler_dim() about subpass attachments

[Nicolai Hähnle]

Thanks!

Reviewed-by: Nicolai Hähnle 


On 23.04.2018 16:55, Samuel Pitoiset wrote:

Suggested by Nicolai.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 24 +++-
  1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 34efb2b9fe1..900c1c4afea 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -87,7 +87,6 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
glsl_sampler_dim dim,
return is_array ? ac_image_1darray : ac_image_1d;
case GLSL_SAMPLER_DIM_2D:
case GLSL_SAMPLER_DIM_RECT:
-   case GLSL_SAMPLER_DIM_SUBPASS:
case GLSL_SAMPLER_DIM_EXTERNAL:
return is_array ? ac_image_2darray : ac_image_2d;
case GLSL_SAMPLER_DIM_3D:
@@ -95,8 +94,11 @@ get_ac_sampler_dim(const struct ac_llvm_context *ctx, enum 
glsl_sampler_dim dim,
case GLSL_SAMPLER_DIM_CUBE:
return ac_image_cube;
case GLSL_SAMPLER_DIM_MS:
-   case GLSL_SAMPLER_DIM_SUBPASS_MS:
return is_array ? ac_image_2darraymsaa : ac_image_2dmsaa;
+   case GLSL_SAMPLER_DIM_SUBPASS:
+   return ac_image_2darray;
+   case GLSL_SAMPLER_DIM_SUBPASS_MS:
+   return ac_image_2darraymsaa;
default:
unreachable("bad sampler dim");
}
@@ -2090,18 +2092,6 @@ static LLVMValueRef 
adjust_sample_index_using_fmask(struct ac_llvm_context *ctx,
return sample_index;
  }
  
-static bool

-glsl_is_array_image(const struct glsl_type *type)
-{
-   const enum glsl_sampler_dim dim = glsl_get_sampler_dim(type);
-
-   if (glsl_sampler_type_is_array(type))
-   return true;
-
-   return dim == GLSL_SAMPLER_DIM_SUBPASS ||
-  dim == GLSL_SAMPLER_DIM_SUBPASS_MS;
-}
-
  static void get_image_coords(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr,
 struct ac_image_args *args)
@@ -2247,7 +2237,7 @@ static LLVMValueRef visit_image_load(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
args.dmask = 15;
args.attributes = AC_FUNC_ATTR_READONLY;
if (var->data.image._volatile || var->data.image.coherent)
@@ -2290,7 +2280,7 @@ static void visit_image_store(struct ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
args.dmask = 15;
if (force_glc || var->data.image._volatile || 
var->data.image.coherent)
args.cache_policy |= ac_glc;
@@ -2381,7 +2371,7 @@ static LLVMValueRef visit_image_atomic(struct 
ac_nir_context *ctx,
args.resource = get_sampler_desc(ctx, instr->variables[0],
 AC_DESC_IMAGE, NULL, true, 
false);
args.dim = get_ac_image_dim(>ac, 
glsl_get_sampler_dim(type),
-   glsl_is_array_image(type));
+   glsl_sampler_type_is_array(type));
  
  		return ac_build_image_opcode(>ac, );

}




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106133] make check "OSError: [Errno 24] Too many open files"

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

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

--- Comment #2 from Dylan Baker  ---
0e945fdf23b..dbf5b772b3b  master -> master

-- 
You are receiving this mail because:
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] ac: fix the number of coordinates for ac_image_get_lod and arrays

[Nicolai Hähnle]

On 23.04.2018 17:52, Samuel Pitoiset wrote:

This fixes crashes for the following CTS:
dEQP-VK.glsl.texture_functions.query.texturequerylod.*

Fixes: 625dcbbc456 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_llvm_build.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 02739f9da9c..d5bad3eeea3 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1521,6 +1521,19 @@ LLVMValueRef ac_build_image_opcode(struct 
ac_llvm_context *ctx,
LLVMValueRef addr;
unsigned num_addr = 0;
  
+	if (a->opcode == ac_image_get_lod) {

+   switch (a->dim) {
+   case ac_image_1darray:
+   num_coords = 1;
+   break;
+   case ac_image_2darray:
+   num_coords = 2;


This is probably also needed for cube maps, isn't it?

With that:

Reviewed-by: Nicolai Hähnle 




+   break;
+   default:
+   break;
+   }
+   }
+
if (a->offset)
args[num_addr++] = ac_to_integer(ctx, a->offset);
if (a->bias)




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] anv/allocator: Don't srink either end of the block pool

[Dylan Baker]

You have a typo in the commit message "srink" -> "shrink"

Quoting Jason Ekstrand (2018-04-20 22:15:00)
> Previously, we only tried to ensure that we didn't shrink either end
> below what was already handed out.  However, due to the way we handle
> relocations with block pools, we can't shrink the back end at all.  It's
> probably best to not shrink in either direction.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105374
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106147
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/vulkan/anv_allocator.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_allocator.c 
> b/src/intel/vulkan/anv_allocator.c
> index f884ac3..642e161 100644
> --- a/src/intel/vulkan/anv_allocator.c
> +++ b/src/intel/vulkan/anv_allocator.c
> @@ -508,12 +508,12 @@ anv_block_pool_grow(struct anv_block_pool *pool, struct 
> anv_block_state *state)
>assert(center_bo_offset >= back_used);
>  
>/* Make sure we don't shrink the back end of the pool */
> -  if (center_bo_offset < pool->back_state.end)
> - center_bo_offset = pool->back_state.end;
> +  if (center_bo_offset < back_required)
> + center_bo_offset = back_required;
>  
>/* Make sure that we don't shrink the front end of the pool */
> -  if (size - center_bo_offset < pool->state.end)
> - center_bo_offset = size - pool->state.end;
> +  if (size - center_bo_offset < front_required)
> + center_bo_offset = size - front_required;
> }
>  
> assert(center_bo_offset % PAGE_SIZE == 0);
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable


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

Re: [Mesa-dev] [PATCH] ac: fix the number of coordinates for ac_image_get_lod and arrays

[Samuel Pitoiset]

On 04/23/2018 06:55 PM, Nicolai Hähnle wrote:

On 23.04.2018 17:52, Samuel Pitoiset wrote:

This fixes crashes for the following CTS:
dEQP-VK.glsl.texture_functions.query.texturequerylod.*

Fixes: 625dcbbc456 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_llvm_build.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c 
b/src/amd/common/ac_llvm_build.c

index 02739f9da9c..d5bad3eeea3 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1521,6 +1521,19 @@ LLVMValueRef ac_build_image_opcode(struct 
ac_llvm_context *ctx,

  LLVMValueRef addr;
  unsigned num_addr = 0;
+    if (a->opcode == ac_image_get_lod) {
+    switch (a->dim) {
+    case ac_image_1darray:
+    num_coords = 1;
+    break;
+    case ac_image_2darray:
+    num_coords = 2;


This is probably also needed for cube maps, isn't it?


cubes should have 3 coordinates for textureQueryLod(), no?



With that:

Reviewed-by: Nicolai Hähnle 




+    break;
+    default:
+    break;
+    }
+    }
+
  if (a->offset)
  args[num_addr++] = ac_to_integer(ctx, a->offset);
  if (a->bias)





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

Re: [Mesa-dev] [PATCH 1/3] meson: don't build classic mesa tests without dri_drivers

[Dylan Baker]

Quoting Dylan Baker (2018-04-19 09:20:49)
> Since mesa_classic is not build-on-demand the tests will create a demand
> and add a bunch of extra compilation.
> 
> Fixes: 43a6e84927e3b1290f6f211f5dfb184dfe5a719e
>("meson: build mesa test.")
> Signed-off-by: Dylan Baker 
> ---
>  src/mesa/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/meson.build b/src/mesa/meson.build
> index 30954beac54..3100dfc50f6 100644
> --- a/src/mesa/meson.build
> +++ b/src/mesa/meson.build
> @@ -732,6 +732,6 @@ endif
>  if with_glx == 'xlib'
>subdir('drivers/x11')
>  endif
> -if with_tests
> +if with_tests and dri_drivers != []
>subdir('main/tests')
>  endif
> -- 
> 2.17.0
> 

ping.


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

Re: [Mesa-dev] [Mesa-stable] [PATCH] anv/allocator: Don't srink either end of the block pool

[Jason Ekstrand]

On Mon, Apr 23, 2018 at 10:00 AM, Dylan Baker  wrote:

> You have a typo in the commit message "srink" -> "shrink"
>

Thanks! Fixed.


> Quoting Jason Ekstrand (2018-04-20 22:15:00)
> > Previously, we only tried to ensure that we didn't shrink either end
> > below what was already handed out.  However, due to the way we handle
> > relocations with block pools, we can't shrink the back end at all.  It's
> > probably best to not shrink in either direction.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105374
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106147
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/intel/vulkan/anv_allocator.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_
> allocator.c
> > index f884ac3..642e161 100644
> > --- a/src/intel/vulkan/anv_allocator.c
> > +++ b/src/intel/vulkan/anv_allocator.c
> > @@ -508,12 +508,12 @@ anv_block_pool_grow(struct anv_block_pool *pool,
> struct anv_block_state *state)
> >assert(center_bo_offset >= back_used);
> >
> >/* Make sure we don't shrink the back end of the pool */
> > -  if (center_bo_offset < pool->back_state.end)
> > - center_bo_offset = pool->back_state.end;
> > +  if (center_bo_offset < back_required)
> > + center_bo_offset = back_required;
> >
> >/* Make sure that we don't shrink the front end of the pool */
> > -  if (size - center_bo_offset < pool->state.end)
> > - center_bo_offset = size - pool->state.end;
> > +  if (size - center_bo_offset < front_required)
> > + center_bo_offset = size - front_required;
> > }
> >
> > assert(center_bo_offset % PAGE_SIZE == 0);
> > --
> > 2.5.0.400.gff86faf
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 7/9] i965: Add and use a getter for the clear color

[Nanley Chery]

On Fri, Apr 20, 2018 at 03:18:18PM -0700, Rafael Antognolli wrote:
> On Fri, Apr 20, 2018 at 03:01:44PM -0700, Nanley Chery wrote:
> > On Fri, Apr 20, 2018 at 01:35:39PM -0700, Rafael Antognolli wrote:
> > > On Wed, Apr 11, 2018 at 01:42:24PM -0700, Nanley Chery wrote:
> > > > This getter allows CNL to sample from fast-cleared sRGB textures 
> > > > correctly.
> > > 
> > > I think it might be worth mentioning in the commit message that the
> > > helper both returns the clear color for inline use, and updates the
> > > pointer to the indirect clear color buffer.
> > > 
> > 
> > Sure, here's what I'm planning to update it to:
> > 
> > It returns the both the inline clear color and a clear address
> > which points to the indirect clear color buffer (or NULL if
> > unused/non-existent). This getter allows CNL to sample from
> > fast-cleared sRGB textures correctly by doing the needed
> > sRGB-decode on the clear color (inline) and making the indirect
> > clear color buffer unused.
> 
> That description is great, thanks!
> 
> > > > ---
> > > >  src/mesa/drivers/dri/i965/brw_blorp.c| 13 ---
> > > >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  7 +++---
> > > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 29 
> > > > 
> > > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  8 +++
> > > >  4 files changed, 46 insertions(+), 11 deletions(-)
> > > > 
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> > > > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > index a1882abb7cb..48022bb1c4f 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > > @@ -166,7 +166,11 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > > >/* We only really need a clear color if we also have an auxiliary
> > > > * surface.  Without one, it does nothing.
> > > > */
> > > > -  surf->clear_color = mt->fast_clear_color;
> > > > +  surf->clear_color =
> > > > + intel_miptree_get_clear_color(devinfo, mt, mt->surf.format,
> > > > +   !is_render_target, (struct 
> > > > brw_bo **)
> > > > +   >clear_color_addr.buffer,
> > > > +   >clear_color_addr.offset);
> > > >  
> > > >struct intel_miptree_aux_buffer *aux_buf =
> > > >   intel_miptree_get_aux_buffer(mt);
> > > > @@ -178,13 +182,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > > >  
> > > >surf->aux_addr.buffer = aux_buf->bo;
> > > >surf->aux_addr.offset = aux_buf->offset;
> > > > -
> > > > -  if (devinfo->gen >= 10) {
> > > > - surf->clear_color_addr = (struct blorp_address) {
> > > > -.buffer = aux_buf->clear_color_bo,
> > > > -.offset = aux_buf->clear_color_offset,
> > > > - };
> > > > -  }
> > > > } else {
> > > >surf->aux_addr = (struct blorp_address) {
> > > >   .buffer = NULL,
> > > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> > > > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > index 3c70dbcc110..fb8e5942a11 100644
> > > > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > > @@ -167,9 +167,10 @@ brw_emit_surface_state(struct brw_context *brw,
> > > >/* We only really need a clear color if we also have an auxiliary
> > > > * surface.  Without one, it does nothing.
> > > > */
> > > > -  clear_bo = aux_buf->clear_color_bo;
> > > > -  clear_offset = aux_buf->clear_color_offset;
> > > > -  clear_color = mt->fast_clear_color;
> > > > +  clear_color =
> > > > + intel_miptree_get_clear_color(devinfo, mt, view.format,
> > > > +   view.usage & 
> > > > ISL_SURF_USAGE_TEXTURE_BIT,
> > > > +   _bo, _offset);
> > > > }
> > > >  
> > > > void *state = brw_state_batch(brw,
> > > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> > > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > index c5791835409..88468399e1b 100644
> > > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > > @@ -46,6 +46,9 @@
> > > >  #include "main/texcompress_etc.h"
> > > >  #include "main/teximage.h"
> > > >  #include "main/streaming-load-memcpy.h"
> > > > +
> > > > +#include "util/format_srgb.h"
> > > > +
> > > >  #include "x86/common_x86_asm.h"
> > > >  
> > > >  #define FILE_DEBUG_FLAG DEBUG_MIPTREE
> > > > @@ -3802,3 +3805,29 @@ intel_miptree_set_depth_clear_value(struct 
> > > > brw_context *brw,
> > > > }
> > > > return false;
> > > >  }
> > > > +
> > > > +union isl_color_value
> > > > +intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
> > > > + 

[Mesa-dev] [PATCH] intel: devinfo: fix assertion on devices with odd number of EUs

[Lionel Landwerlin]

I forgot to change the assert in the second helper function in a
previous change.

This hit the assert() on a Broadwell platform with quite a few EUs
fused off :
   https://i.imgur.com/4Wx6tjz.png

Fixes: c1900f5b0fb ("intel: devinfo: add helper functions to fill fusing masks 
values")
Signed-off-by: Lionel Landwerlin 
---
 src/intel/dev/gen_device_info.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index dfeab6e6060..aa72d96e178 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -1044,11 +1044,7 @@ gen_device_info_update_from_topology(struct 
gen_device_info *devinfo,
for (int b = 0; b < eu_mask_len; b++)
   n_eus += __builtin_popcount(devinfo->eu_masks[b]);

-   /* We expect the total number of EUs to be uniformly distributed throughout
-* the subslices.
-*/
-   assert(n_subslices && (n_eus % n_subslices) == 0);
-   devinfo->num_eu_per_subslice = n_eus / n_subslices;
+   devinfo->num_eu_per_subslice = DIV_ROUND_UP(n_eus, n_subslices);
 }

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

Re: [Mesa-dev] [PATCH 2/3] Autotools: Add passes.h to sources so it will be included in the tarball

[Dylan Baker]

Quoting Kyriazis, George (2018-04-23 07:52:23)
> I agree on the commit message wording.
> 
> Sorry about missing passes.h in the original check-in.
> 

No worries, most (all?) of us forget about it. I guess it's just one more thing
that meson will improve in our workflow :)

Dylan


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

Re: [Mesa-dev] [PATCH] ac/nir: add missing round_slice for 1D arrays

[Nicolai Hähnle]

On 23.04.2018 14:46, Samuel Pitoiset wrote:

This fixes a bunch of CTS fails with 1D arrays:

dEQP-VK.glsl.texture_functions.texture*.sampler1darray_*

Fixes: 625dcbbc456 ("amd/common: pass address components individually to
ac_build_image_intrinsic")
Cc: 18.1 
Signed-off-by: Samuel Pitoiset 


Reviewed-by: Nicolai Hähnle 



---
  src/amd/common/ac_nir_to_llvm.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 72c773522f4..34efb2b9fe1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3397,6 +3397,13 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
}
  
  	/* Texture coordinates fixups */

+   if (instr->coord_components > 1 &&
+   instr->sampler_dim == GLSL_SAMPLER_DIM_1D &&
+   instr->is_array &&
+   instr->op != nir_texop_txf) {
+   args.coords[1] = apply_round_slice(>ac, args.coords[1]);
+   }
+
if (instr->coord_components > 2 &&
(instr->sampler_dim == GLSL_SAMPLER_DIM_2D ||
 instr->sampler_dim == GLSL_SAMPLER_DIM_MS ||




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] i965: Add and use a helper to update the indirect miptree color

[Nanley Chery]

On Mon, Apr 23, 2018 at 11:27:16AM -0700, Jason Ekstrand wrote:
> There are two refactors going on here that are being conflated.  One is
> what the commit message says where we add and use a helper.
> 
> On Fri, Apr 20, 2018 at 3:12 PM, Rafael Antognolli <
> rafael.antogno...@intel.com> wrote:
> 
> > On Wed, Apr 11, 2018 at 01:56:16PM -0700, Nanley Chery wrote:
> > > Split out this functionality to enable a fast-clear optimization for
> > > color miptrees in the next commit.
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_clear.c | 54
> > ---
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 22 +++
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  7 
> > >  3 files changed, 36 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > b/src/mesa/drivers/dri/i965/brw_clear.c
> > > index 3d540d6d905..1cdc2241eac 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > > @@ -108,7 +108,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > struct intel_mipmap_tree *mt = depth_irb->mt;
> > > struct gl_renderbuffer_attachment *depth_att =
> > >Attachment[BUFFER_DEPTH];
> > > const struct gen_device_info *devinfo = >screen->devinfo;
> > > -   bool same_clear_value = true;
> > >
> > > if (devinfo->gen < 6)
> > >return false;
> > > @@ -176,7 +175,8 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > > /* If we're clearing to a new clear value, then we need to resolve
> > any clear
> > >  * flags out of the HiZ buffer into the real depth buffer.
> > >  */
> > > -   if (mt->fast_clear_color.f32[0] != clear_value) {
> > > +   const bool same_clear_value = mt->fast_clear_color.f32[0] ==
> > clear_value;
> > > +   if (!same_clear_value) {
> > >for (uint32_t level = mt->first_level; level <= mt->last_level;
> > level++) {
> > >   if (!intel_miptree_level_has_hiz(mt, level))
> > >  continue;
> > > @@ -214,7 +214,6 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > >}
> > >
> > >intel_miptree_set_depth_clear_value(brw, mt, clear_value);
> > > -  same_clear_value = false;
> > > }
> > >
> > > bool need_clear = false;
> > > @@ -225,56 +224,17 @@ brw_fast_clear_depth(struct gl_context *ctx)
> > >
> > >if (aux_state != ISL_AUX_STATE_CLEAR) {
> > >   need_clear = true;
> > > - break;
> > > -  }
> > > -   }
> > > -
> > > -   if (!need_clear) {
> > > -  /* If all of the layers we intend to clear are already in the
> > clear
> > > -   * state then simply updating the miptree fast clear value is
> > sufficient
> > > -   * to change their clear value.
> > > -   */
> > > -  if (devinfo->gen >= 10 && !same_clear_value) {
> > > - /* Before gen10, it was enough to just update the clear value
> > in the
> > > -  * miptree. But on gen10+, we let blorp update the clear value
> > state
> > > -  * buffer when doing a fast clear. Since we are skipping the
> > fast
> > > -  * clear here, we need to update the clear color ourselves.
> > > -  */
> > > - uint32_t clear_offset = mt->aux_buf->clear_color_offset;
> > > - union isl_color_value clear_color = { .f32 = { clear_value, }
> > };
> > > -
> > > - /* We can't update the clear color while the hardware is still
> > using
> > > -  * the previous one for a resolve or sampling from it. So make
> > sure
> > > -  * that there's no pending commands at this point.
> > > -  */
> > > - brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
> > > - for (int i = 0; i < 4; i++) {
> > > -brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
> > > - clear_offset + i * 4,
> > clear_color.u32[i]);
> > > - }
> > > - brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_
> > INVALIDATE);
> > > -  }
> > > -  return true;
> > > -   }
> >
> 
> The other is down here where you re-order setting the indirect clear color
> with respect to the HiZ op.  I'd rather we split this patch into two
> different onces which do the two different refactors.  I think the re-order
> is safe but I'd like to have something for it to bisect to if not. :-)
> 
> 

Yeah, this patch does do many things at once.. I'll split it out into
multiple patches.

-Nanley

> > > -
> > > -   for (unsigned a = 0; a < num_layers; a++) {
> > > -  enum isl_aux_state aux_state =
> > > - intel_miptree_get_aux_state(mt, depth_irb->mt_level,
> > > - depth_irb->mt_layer + a);
> > > -
> > > -  if (aux_state != ISL_AUX_STATE_CLEAR) {
> > >   intel_hiz_exec(brw, mt, depth_irb->mt_level,
> > >  depth_irb->mt_layer + a, 1,
> > >  ISL_AUX_OP_FAST_CLEAR);
> > > + 

[Mesa-dev] [Bug 76694] Inconsistent behaviour of LIBGL_DEBUG

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|REOPENED|RESOLVED

--- Comment #3 from Timothy Arceri  ---
(In reply to Stefan Brüns from comment #2)
> The important part is some code parts check for *defined*, while others
> check for a specific value, i.e. "quiet" and "verbose"
> 
> https://github.com/anholt/mesa/blob/master/src/glx/dri_common.c#L59

Right but I don't think anyone cares enough to change this. Feel free to submit
a patch to the mailing list and see what the other devs have to say, but we
tend not to alter how these environment vars operate since people have
memorised, scripted them etc.

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

[Mesa-dev] [Bug 65422] Rename api_validate.[ch] to draw_validate.[ch]

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #2 from Timothy Arceri  ---
Fixed by:

commit 295f57e09a8b67da07dd96609591dc5144031a62
Author: Timothy Arceri 
Date:   Mon Apr 23 13:46:15 2018 +1000

mesa: rename api_validate.{c,h} -> draw_validate.{c,h}

Reviewed-by: Mathias Fröhlich 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65422

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

[Mesa-dev] [PATCH v2] i965: Add and use a single miptree aux_buf field

[Nanley Chery]

We want to add and use a function that accesses the auxiliary buffer's
clear_color_bo and doesn't care if it has an MCS or HiZ buffer
specifically.

v2 (Jason Ekstrand):
* Drop intel_miptree_get_aux_buffer().
* Mention CCS in the aux_buf field.
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  16 ++--
 src/mesa/drivers/dri/i965/brw_clear.c|   4 +-
 src/mesa/drivers/dri/i965/brw_wm.c   |   2 +-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  11 ++-
 src/mesa/drivers/dri/i965/gen6_depth_state.c |   6 +-
 src/mesa/drivers/dri/i965/gen7_misc_state.c  |   4 +-
 src/mesa/drivers/dri/i965/gen8_depth_state.c |   6 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 106 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  53 +---
 src/mesa/drivers/dri/i965/intel_tex_image.c  |   2 +-
 10 files changed, 96 insertions(+), 114 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 962a316c5cf..37fca5e9d31 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -168,21 +168,19 @@ blorp_surf_for_miptree(struct brw_context *brw,
*/
   surf->clear_color = mt->fast_clear_color;
 
-  struct intel_miptree_aux_buffer *aux_buf =
- intel_miptree_get_aux_buffer(mt);
-  surf->aux_surf = _buf->surf;
+  surf->aux_surf = >aux_buf->surf;
   surf->aux_addr = (struct blorp_address) {
  .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
  .mocs = surf->addr.mocs,
   };
 
-  surf->aux_addr.buffer = aux_buf->bo;
-  surf->aux_addr.offset = aux_buf->offset;
+  surf->aux_addr.buffer = mt->aux_buf->bo;
+  surf->aux_addr.offset = mt->aux_buf->offset;
 
   if (devinfo->gen >= 10) {
  surf->clear_color_addr = (struct blorp_address) {
-.buffer = aux_buf->clear_color_bo,
-.offset = aux_buf->clear_color_offset,
+.buffer = mt->aux_buf->clear_color_bo,
+.offset = mt->aux_buf->clear_color_offset,
  };
   }
} else {
@@ -1212,7 +1210,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
/* If the MCS buffer hasn't been allocated yet, we need to allocate it now.
 */
-   if (can_fast_clear && !irb->mt->mcs_buf) {
+   if (can_fast_clear && !irb->mt->aux_buf) {
   assert(irb->mt->aux_usage == ISL_AUX_USAGE_CCS_D);
   if (!intel_miptree_alloc_ccs(brw, irb->mt)) {
  /* There are a few reasons in addition to out-of-memory, that can
@@ -1611,7 +1609,7 @@ intel_hiz_exec(struct brw_context *brw, struct 
intel_mipmap_tree *mt,
brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
}
 
-   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->hiz_buf);
+   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->aux_buf);
 
struct isl_surf isl_tmp[2];
struct blorp_surf surf;
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 487de9b8997..3d540d6d905 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -240,7 +240,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
   * buffer when doing a fast clear. Since we are skipping the fast
   * clear here, we need to update the clear color ourselves.
   */
- uint32_t clear_offset = mt->hiz_buf->clear_color_offset;
+ uint32_t clear_offset = mt->aux_buf->clear_color_offset;
  union isl_color_value clear_color = { .f32 = { clear_value, } };
 
  /* We can't update the clear color while the hardware is still using
@@ -249,7 +249,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
   */
  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
  for (int i = 0; i < 4; i++) {
-brw_store_data_imm32(brw, mt->hiz_buf->clear_color_bo,
+brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
  clear_offset + i * 4, clear_color.u32[i]);
  }
  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c
index 68d4ab88d77..94048cd758f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -384,7 +384,7 @@ brw_populate_sampler_prog_key_data(struct gl_context *ctx,
  if (intel_tex->mt->aux_usage == ISL_AUX_USAGE_MCS) {
 assert(devinfo->gen >= 7);
 assert(intel_tex->mt->surf.samples > 1);
-assert(intel_tex->mt->mcs_buf);
+assert(intel_tex->mt->aux_buf);
 assert(intel_tex->mt->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY);
 key->compressed_multisample_layout_mask |= 1 << s;
 
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 

Re: [Mesa-dev] [PATCH v3 3/9] i965: Add and use a getter for the miptree aux buffer

[Jason Ekstrand]

On Mon, Apr 23, 2018 at 11:11 AM, Nanley Chery 
wrote:

> On Mon, Apr 23, 2018 at 11:01:12AM -0700, Jason Ekstrand wrote:
> > Why is this useful in light of patch 4?  I don't mean to be overly
> critical
> > but the main purpose of this helper seems to be to deal with the fact
> that
> > we have two different fields.  If it's just one field, why the helper?
> >
> > --Jason
> >
> > On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery 
> wrote:
> >
> > > Make the next patch easier to read by eliminating most of the would-be
> > > duplicate field accesses now.
>
> No worries, honest questions are welcome :) The rationale is mentioned
> here in the commit message. By the way, I leave the function behind in
> patch 4 because I'm currently working under the (possibly naive)
> assumption that getters are a good thing in general. That said, I
> haven't thought about it much and I'm not opposed to deleting it. Maybe
> I shouldn't introduce two ways of getting at the same field?
>

I'm not sure if getters are good in general or not.  I think they
frequently can be if the thing you're getting is complicated or if you want
to do a bunch of asserting around it.  I don't think they do any good if
it's feasable and common (which it is) to get at it directly.  In that
case, I think they just provide a false sense of security.


> -Nanley
>
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_blorp.c|  8 ++--
> > >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16
> +---
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 24
> > > 
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 17
> +
> > >  4 files changed, 24 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > index 5dcd95e9f44..962a316c5cf 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > > @@ -154,12 +154,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > >.aux_usage = aux_usage,
> > > };
> > >
> > > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > > -   if (mt->mcs_buf)
> > > -  aux_buf = mt->mcs_buf;
> > > -   else if (mt->hiz_buf)
> > > -  aux_buf = mt->hiz_buf;
> > > -
> > > if (mt->format == MESA_FORMAT_S_UINT8 && is_render_target &&
> > > devinfo->gen <= 7)
> > >mt->r8stencil_needs_update = true;
> > > @@ -174,6 +168,8 @@ blorp_surf_for_miptree(struct brw_context *brw,
> > > */
> > >surf->clear_color = mt->fast_clear_color;
> > >
> > > +  struct intel_miptree_aux_buffer *aux_buf =
> > > + intel_miptree_get_aux_buffer(mt);
> > >surf->aux_surf = _buf->surf;
> > >surf->aux_addr = (struct blorp_address) {
> > >   .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
> > > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > index 3fb101bf68b..06f739faf61 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > > @@ -155,21 +155,7 @@ brw_emit_surface_state(struct brw_context *brw,
> > > struct brw_bo *aux_bo = NULL;
> > > struct isl_surf *aux_surf = NULL;
> > > uint64_t aux_offset = 0;
> > > -   struct intel_miptree_aux_buffer *aux_buf = NULL;
> > > -   switch (aux_usage) {
> > > -   case ISL_AUX_USAGE_MCS:
> > > -   case ISL_AUX_USAGE_CCS_D:
> > > -   case ISL_AUX_USAGE_CCS_E:
> > > -  aux_buf = mt->mcs_buf;
> > > -  break;
> > > -
> > > -   case ISL_AUX_USAGE_HIZ:
> > > -  aux_buf = mt->hiz_buf;
> > > -  break;
> > > -
> > > -   case ISL_AUX_USAGE_NONE:
> > > -  break;
> > > -   }
> > > +   struct intel_miptree_aux_buffer *aux_buf =
> > > intel_miptree_get_aux_buffer(mt);
> > >
> > > if (aux_usage != ISL_AUX_USAGE_NONE) {
> > >aux_surf = _buf->surf;
> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index d95128de119..ba5b02bc0aa 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -1249,8 +1249,7 @@ intel_miptree_release(struct intel_mipmap_tree
> **mt)
> > >brw_bo_unreference((*mt)->bo);
> > >intel_miptree_release(&(*mt)->stencil_mt);
> > >intel_miptree_release(&(*mt)->r8stencil_mt);
> > > -  intel_miptree_aux_buffer_free((*mt)->hiz_buf);
> > > -  intel_miptree_aux_buffer_free((*mt)->mcs_buf);
> > > +  intel_miptree_aux_buffer_free(intel_miptree_get_aux_buffer(*
> mt));
> > >free_aux_state_map((*mt)->aux_state);
> > >
> > >intel_miptree_release(&(*mt)->plane[0]);
> > > @@ -2876,31 +2875,16 @@ intel_miptree_make_shareable(struct
> brw_context
> > > *brw,
> > >  0, 

Re: [Mesa-dev] [PATCH 0/7] broadcom/vc4: Native fence fd support

[Eric Anholt]

Stefan Schake  writes:

> This series adds support for the native fence fd extension to vc4.
> The implementation relies on a newly introduced kernel interface that
> allows submitting syncobjs for in/out fences during job submission.
>
> Since syncobjs are relatively new, patches 1 and 3 have build changes
> for automake and meson to require a recent libdrm version.
>
> There is some scope here to replace the previous sequence number based
> implementation with only syncobjs, but given that we need to continue
> supporting older kernels I felt it would have only added complexity.
>
> This has been tested with piglit and kmscube -A(tomic). In particular,
> I checked that the fd numbers weren't increasing during the kmscube run.
>
> Should not be merged until the kernel side lands. In particular, patch 2
> is purely provisional.

A few comments here that I think will clean up the series a bit, but it
looks pretty good to me.  In particular, I think the kernel ABI will be
fine, with the little comments I had in the kernel series.

Thanks for working on this!


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] [PATCH] i965/fs: Return mlen * 8 for size_written for INTERPOLATE_AT_*

[Francisco Jerez]

Jason Ekstrand  writes:

> They are send messages and this makes size_written() and mlen agree.

You mean size_read()?  And commit message should probably read "Return
mlen * 32 for size_read for INTERPOLATE_AT_*" to reflect what the commit
is doing.

> For both of these opcodes, the payload is just a dummy so mlen == 1 and
> this should decrease register pressure a bit.
>

Reviewed-by: Francisco Jerez 

> Cc: Francisco Jerez 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/compiler/brw_fs.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 40896db..8156507 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -842,6 +842,8 @@ fs_inst::size_read(int arg) const
> case SHADER_OPCODE_TYPED_ATOMIC:
> case SHADER_OPCODE_TYPED_SURFACE_READ:
> case SHADER_OPCODE_TYPED_SURFACE_WRITE:
> +   case FS_OPCODE_INTERPOLATE_AT_SAMPLE:
> +   case FS_OPCODE_INTERPOLATE_AT_SHARED_OFFSET:
> case FS_OPCODE_INTERPOLATE_AT_PER_SLOT_OFFSET:
> case SHADER_OPCODE_BYTE_SCATTERED_WRITE:
> case SHADER_OPCODE_BYTE_SCATTERED_READ:
> -- 
> 2.5.0.400.gff86faf


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] [Mesa-stable] [PATCH] ac: fix the number of coordinates for ac_image_get_lod and arrays

[Samuel Pitoiset]

On 04/23/2018 08:42 PM, Marek Olšák wrote:
On Mon, Apr 23, 2018 at 1:12 PM, Samuel Pitoiset 
> wrote:




On 04/23/2018 06:55 PM, Nicolai Hähnle wrote:

On 23.04.2018 17:52, Samuel Pitoiset wrote:

This fixes crashes for the following CTS:
dEQP-VK.glsl.texture_functions.query.texturequerylod.*

Fixes: 625dcbbc456 ("amd/common: pass address components
individually to
ac_build_image_intrinsic")
Cc: 18.1 >
Signed-off-by: Samuel Pitoiset >
---
   src/amd/common/ac_llvm_build.c | 13 +
   1 file changed, 13 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c
b/src/amd/common/ac_llvm_build.c
index 02739f9da9c..d5bad3eeea3 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1521,6 +1521,19 @@ LLVMValueRef
ac_build_image_opcode(struct ac_llvm_context *ctx,
   LLVMValueRef addr;
   unsigned num_addr = 0;
+    if (a->opcode == ac_image_get_lod) {
+    switch (a->dim) {
+    case ac_image_1darray:
+    num_coords = 1;
+    break;
+    case ac_image_2darray:
+    num_coords = 2;


This is probably also needed for cube maps, isn't it?


cubes should have 3 coordinates for textureQueryLod(), no?


Cubemaps are the same as 2D arrays.


Okay. CTS doesn't seem to have tests for cubemaps but that makes sense 
anyway. I'm going to push the patch with the cubemaps fix.




Marek


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

Re: [Mesa-dev] [PATCH] i965/fs: Return mlen * 8 for size_written for INTERPOLATE_AT_*

[Jason Ekstrand]

On Mon, Apr 23, 2018 at 1:36 PM, Francisco Jerez 
wrote:

> Jason Ekstrand  writes:
>
> > They are send messages and this makes size_written() and mlen agree.
>
> You mean size_read()?  And commit message should probably read "Return
> mlen * 32 for size_read for INTERPOLATE_AT_*" to reflect what the commit
> is doing.
>

Yes.  That was a typo.


> > For both of these opcodes, the payload is just a dummy so mlen == 1 and
> > this should decrease register pressure a bit.
> >
>
> Reviewed-by: Francisco Jerez 
>

Thanks!


> > Cc: Francisco Jerez 
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/intel/compiler/brw_fs.cpp | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.
> cpp
> > index 40896db..8156507 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -842,6 +842,8 @@ fs_inst::size_read(int arg) const
> > case SHADER_OPCODE_TYPED_ATOMIC:
> > case SHADER_OPCODE_TYPED_SURFACE_READ:
> > case SHADER_OPCODE_TYPED_SURFACE_WRITE:
> > +   case FS_OPCODE_INTERPOLATE_AT_SAMPLE:
> > +   case FS_OPCODE_INTERPOLATE_AT_SHARED_OFFSET:
> > case FS_OPCODE_INTERPOLATE_AT_PER_SLOT_OFFSET:
> > case SHADER_OPCODE_BYTE_SCATTERED_WRITE:
> > case SHADER_OPCODE_BYTE_SCATTERED_READ:
> > --
> > 2.5.0.400.gff86faf
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/9] i965: Add and use a single miptree aux_buf field

[Nanley Chery]

On Mon, Apr 23, 2018 at 11:10:08AM -0700, Jason Ekstrand wrote:
> On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:
> 
> > We want to add and use a function that accesses the auxiliary buffer's
> > clear_color_bo and doesn't care if it has an MCS or HiZ buffer
> > specifically.
> > ---
> >  src/mesa/drivers/dri/i965/brw_blorp.c |   4 +-
> >  src/mesa/drivers/dri/i965/brw_clear.c |   4 +-
> >  src/mesa/drivers/dri/i965/brw_wm.c|   2 +-
> >  src/mesa/drivers/dri/i965/gen6_depth_state.c  |   6 +-
> >  src/mesa/drivers/dri/i965/gen7_misc_state.c   |   4 +-
> >  src/mesa/drivers/dri/i965/gen8_depth_state.c  |   6 +-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 106
> > +-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  42 --
> >  src/mesa/drivers/dri/i965/intel_tex_image.c   |   2 +-
> >  9 files changed, 80 insertions(+), 96 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> > b/src/mesa/drivers/dri/i965/brw_blorp.c
> > index 962a316c5cf..a1882abb7cb 100644
> > --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> > +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> > @@ -1212,7 +1212,7 @@ do_single_blorp_clear(struct brw_context *brw,
> > struct gl_framebuffer *fb,
> >
> > /* If the MCS buffer hasn't been allocated yet, we need to allocate it
> > now.
> >  */
> > -   if (can_fast_clear && !irb->mt->mcs_buf) {
> > +   if (can_fast_clear && !irb->mt->aux_buf) {
> >assert(irb->mt->aux_usage == ISL_AUX_USAGE_CCS_D);
> >if (!intel_miptree_alloc_ccs(brw, irb->mt)) {
> >   /* There are a few reasons in addition to out-of-memory, that can
> > @@ -1611,7 +1611,7 @@ intel_hiz_exec(struct brw_context *brw, struct
> > intel_mipmap_tree *mt,
> > brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
> > }
> >
> > -   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->hiz_buf);
> > +   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->aux_buf);
> >
> > struct isl_surf isl_tmp[2];
> > struct blorp_surf surf;
> > diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> > b/src/mesa/drivers/dri/i965/brw_clear.c
> > index 487de9b8997..3d540d6d905 100644
> > --- a/src/mesa/drivers/dri/i965/brw_clear.c
> > +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> > @@ -240,7 +240,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
> >* buffer when doing a fast clear. Since we are skipping the fast
> >* clear here, we need to update the clear color ourselves.
> >*/
> > - uint32_t clear_offset = mt->hiz_buf->clear_color_offset;
> > + uint32_t clear_offset = mt->aux_buf->clear_color_offset;
> >   union isl_color_value clear_color = { .f32 = { clear_value, } };
> >
> >   /* We can't update the clear color while the hardware is still
> > using
> > @@ -249,7 +249,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
> >*/
> >   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
> >   for (int i = 0; i < 4; i++) {
> > -brw_store_data_imm32(brw, mt->hiz_buf->clear_color_bo,
> > +brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
> >   clear_offset + i * 4,
> > clear_color.u32[i]);
> >   }
> >   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_
> > INVALIDATE);
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm.c
> > b/src/mesa/drivers/dri/i965/brw_wm.c
> > index 68d4ab88d77..94048cd758f 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm.c
> > @@ -384,7 +384,7 @@ brw_populate_sampler_prog_key_data(struct gl_context
> > *ctx,
> >   if (intel_tex->mt->aux_usage == ISL_AUX_USAGE_MCS) {
> >  assert(devinfo->gen >= 7);
> >  assert(intel_tex->mt->surf.samples > 1);
> > -assert(intel_tex->mt->mcs_buf);
> > +assert(intel_tex->mt->aux_buf);
> >  assert(intel_tex->mt->surf.msaa_layout ==
> > ISL_MSAA_LAYOUT_ARRAY);
> >  key->compressed_multisample_layout_mask |= 1 << s;
> >
> > diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> > b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> > index 3a66b42fec1..8a1d5808051 100644
> > --- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
> > +++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
> > @@ -160,13 +160,13 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
> >   assert(depth_mt);
> >
> >   uint32_t offset;
> > - isl_surf_get_image_offset_B_tile_sa(_mt->hiz_buf->surf,
> > + isl_surf_get_image_offset_B_tile_sa(_mt->aux_buf->surf,
> >   lod, 0, 0, , NULL,
> > NULL);
> >
> >  BEGIN_BATCH(3);
> >  OUT_BATCH((_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
> > -OUT_BATCH(depth_mt->hiz_buf->surf.row_pitch - 1);
> > -OUT_RELOC(depth_mt->hiz_buf->bo, 

[Mesa-dev] [Bug 106197] plasma wayland cant create platform surface with mesa 18.1.0 rc1

[bugzilla-daemon]

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

Bug ID: 106197
   Summary: plasma wayland cant create platform surface with mesa
18.1.0 rc1
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: EGL/Wayland
  Assignee: wayland-b...@lists.freedesktop.org
  Reporter: farmboy0+freedesk...@googlemail.com
QA Contact: mesa-dev@lists.freedesktop.org

The error is EGL user error 0x3009 (EGL_BAD_MATCH) in
eglCreatePlatformWindowSurfaceEXT
Reverting to mesa 18.0.1 fixes this.

Snippet from the log:

kwin_wayland_drm: Using Atomic Mode Setting.
kwin_wayland_drm: Number of planes: 12
kwin_wayland_drm: Atomic init for plane: 36
kwin_wayland_drm: 36: type' (id 7): 1
kwin_wayland_drm: "type"  has enums: QVector("Primary", "Cursor", "Overlay")
kwin_wayland_drm: Test all 3 possible enums:
kwin_wayland_drm: Enum 'Overlay': runtime-value = 0
kwin_wayland_drm: Enum 'Primary': runtime-value = 1
kwin_wayland_drm: Enum 'Cursor': runtime-value = 2
kwin_wayland_drm: => "type" with mapped enum value "Primary"
kwin_wayland_drm: 36: SRC_X' (id 8): 0
kwin_wayland_drm: 36: SRC_Y' (id 9): 0
kwin_wayland_drm: 36: SRC_W' (id 10): 125829120
kwin_wayland_drm: 36: SRC_H' (id 11): 70778880
kwin_wayland_drm: 36: CRTC_X' (id 12): 0
kwin_wayland_drm: 36: CRTC_Y' (id 13): 0
kwin_wayland_drm: 36: CRTC_W' (id 14): 1920
kwin_wayland_drm: 36: CRTC_H' (id 15): 1080
kwin_wayland_drm: 36: FB_ID' (id 16): 89
kwin_wayland_drm: 36: CRTC_ID' (id 19): 43
kwin_wayland_drm: Supported Transformations:  QFlags()  on plane  36
kwin_wayland_drm: Atomic init for plane: 37
kwin_wayland_drm: 37: type' (id 7): 1
kwin_wayland_drm: "type"  has enums: QVector("Primary", "Cursor", "Overlay")
kwin_wayland_drm: Test all 3 possible enums:
kwin_wayland_drm: Enum 'Overlay': runtime-value = 0
kwin_wayland_drm: Enum 'Primary': runtime-value = 1
kwin_wayland_drm: Enum 'Cursor': runtime-value = 2
kwin_wayland_drm: => "type" with mapped enum value "Primary"
kwin_wayland_drm: 37: SRC_X' (id 8): 0
kwin_wayland_drm: 37: SRC_Y' (id 9): 0
kwin_wayland_drm: 37: SRC_W' (id 10): 0
kwin_wayland_drm: 37: SRC_H' (id 11): 0
kwin_wayland_drm: 37: CRTC_X' (id 12): 0
kwin_wayland_drm: 37: CRTC_Y' (id 13): 0
kwin_wayland_drm: 37: CRTC_W' (id 14): 0
kwin_wayland_drm: 37: CRTC_H' (id 15): 0
kwin_wayland_drm: 37: FB_ID' (id 16): 0
kwin_wayland_drm: 37: CRTC_ID' (id 19): 0
kwin_wayland_drm: Supported Transformations:  QFlags()  on plane  37
kwin_wayland_drm: Atomic init for plane: 38
kwin_wayland_drm: 38: type' (id 7): 1
kwin_wayland_drm: "type"  has enums: QVector("Primary", "Cursor", "Overlay")
kwin_wayland_drm: Test all 3 possible enums:
kwin_wayland_drm: Enum 'Overlay': runtime-value = 0
kwin_wayland_drm: Enum 'Primary': runtime-value = 1
kwin_wayland_drm: Enum 'Cursor': runtime-value = 2
kwin_wayland_drm: => "type" with mapped enum value "Primary"
kwin_wayland_drm: 38: SRC_X' (id 8): 0
kwin_wayland_drm: 38: SRC_Y' (id 9): 0
kwin_wayland_drm: 38: SRC_W' (id 10): 0
kwin_wayland_drm: 38: SRC_H' (id 11): 0
kwin_wayland_drm: 38: CRTC_X' (id 12): 0
kwin_wayland_drm: 38: CRTC_Y' (id 13): 0
kwin_wayland_drm: 38: CRTC_W' (id 14): 0
kwin_wayland_drm: 38: CRTC_H' (id 15): 0
kwin_wayland_drm: 38: FB_ID' (id 16): 0
kwin_wayland_drm: 38: CRTC_ID' (id 19): 0
kwin_wayland_drm: Supported Transformations:  QFlags()  on plane  38
kwin_wayland_drm: Atomic init for plane: 39
kwin_wayland_drm: 39: type' (id 7): 1
kwin_wayland_drm: "type"  has enums: QVector("Primary", "Cursor", "Overlay")
kwin_wayland_drm: Test all 3 possible enums:
kwin_wayland_drm: Enum 'Overlay': runtime-value = 0
kwin_wayland_drm: Enum 'Primary': runtime-value = 1
kwin_wayland_drm: Enum 'Cursor': runtime-value = 2
kwin_wayland_drm: => "type" with mapped enum value "Primary"
kwin_wayland_drm: 39: SRC_X' (id 8): 0
kwin_wayland_drm: 39: SRC_Y' (id 9): 0
kwin_wayland_drm: 39: SRC_W' (id 10): 0
kwin_wayland_drm: 39: SRC_H' (id 11): 0
kwin_wayland_drm: 39: CRTC_X' (id 12): 0
kwin_wayland_drm: 39: CRTC_Y' (id 13): 0
kwin_wayland_drm: 39: CRTC_W' (id 14): 0
kwin_wayland_drm: 39: CRTC_H' (id 15): 0
kwin_wayland_drm: 39: FB_ID' (id 16): 0
kwin_wayland_drm: 39: CRTC_ID' (id 19): 0
kwin_wayland_drm: Supported Transformations:  QFlags()  on plane  39
kwin_wayland_drm: Atomic init for plane: 40
kwin_wayland_drm: 40: type' (id 7): 1
kwin_wayland_drm: "type"  has enums: QVector("Primary", "Cursor", "Overlay")
kwin_wayland_drm: Test all 3 possible enums:
kwin_wayland_drm: Enum 'Overlay': runtime-value = 0
kwin_wayland_drm: Enum 'Primary': runtime-value = 1
kwin_wayland_drm: Enum 'Cursor': runtime-value = 2
kwin_wayland_drm: => "type" with mapped enum value "Primary"
kwin_wayland_drm: 40: SRC_X' (id 8): 0
kwin_wayland_drm: 40: SRC_Y' (id 9): 0
kwin_wayland_drm: 40: SRC_W' (id 10): 0
kwin_wayland_drm: 40: SRC_H' (id 11): 0
kwin_wayland_drm: 40: 

Re: [Mesa-dev] [PATCH v3 5/9] i965/wm_surface_state: Use the clear address if it's non-zero

[Nanley Chery]

On Mon, Apr 23, 2018 at 11:18:54AM -0700, Jason Ekstrand wrote:
> I think you want to say "clear_color_bo is non-NULL" in the commit message
> rather than talking about addresses.  Otherwise, this looks like a very
> nice clean-up.
> 

To make sure we're on the same page, I made an error in using the term
clear address, because the code only checks part of it (the bo)?

What do you think of this new commit message?

i965/wm_surface_state: Use the clear address if clear_bo is non-NULL

We want to add and use a getter that turns off the indirect path by
returning zero for the clear color bo and offset.

v2: Fix usage of "clear address" in commit message (Jason).

> Reviewed-by: Jason Ekstrand 
> 

Thanks!

-Nanley

> On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:
> 
> > We want to add and use a getter that turns off the indirect path by
> > returning zero for the clear address.
> > ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 17 ++---
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index 06f739faf61..3c70dbcc110 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -155,6 +155,8 @@ brw_emit_surface_state(struct brw_context *brw,
> > struct brw_bo *aux_bo = NULL;
> > struct isl_surf *aux_surf = NULL;
> > uint64_t aux_offset = 0;
> > +   struct brw_bo *clear_bo = NULL;
> > +   uint32_t clear_offset = 0;
> > struct intel_miptree_aux_buffer *aux_buf =
> > intel_miptree_get_aux_buffer(mt);
> >
> > if (aux_usage != ISL_AUX_USAGE_NONE) {
> > @@ -165,6 +167,8 @@ brw_emit_surface_state(struct brw_context *brw,
> >/* We only really need a clear color if we also have an auxiliary
> > * surface.  Without one, it does nothing.
> > */
> > +  clear_bo = aux_buf->clear_color_bo;
> > +  clear_offset = aux_buf->clear_color_offset;
> >clear_color = mt->fast_clear_color;
> > }
> >
> > @@ -173,15 +177,6 @@ brw_emit_surface_state(struct brw_context *brw,
> >   brw->isl_dev.ss.align,
> >   surf_offset);
> >
> > -   bool use_clear_address = devinfo->gen >= 10 && aux_surf;
> > -
> > -   struct brw_bo *clear_bo = NULL;
> > -   uint32_t clear_offset = 0;
> > -   if (use_clear_address) {
> > -  clear_bo = aux_buf->clear_color_bo;
> > -  clear_offset = aux_buf->clear_color_offset;
> > -   }
> > -
> > isl_surf_fill_state(>isl_dev, state, .surf = , .view =
> > ,
> > .address = brw_state_reloc(>batch,
> >*surf_offset +
> > brw->isl_dev.ss.addr_offset,
> > @@ -190,7 +185,7 @@ brw_emit_surface_state(struct brw_context *brw,
> > .aux_address = aux_offset,
> > .mocs = brw_get_bo_mocs(devinfo, mt->bo),
> > .clear_color = clear_color,
> > -   .use_clear_address = use_clear_address,
> > +   .use_clear_address = clear_bo != NULL,
> > .clear_address = clear_offset,
> > .x_offset_sa = tile_x, .y_offset_sa = tile_y);
> > if (aux_surf) {
> > @@ -222,7 +217,7 @@ brw_emit_surface_state(struct brw_context *brw,
> >}
> > }
> >
> > -   if (use_clear_address) {
> > +   if (clear_bo != NULL) {
> >/* Make sure the offset is aligned with a cacheline. */
> >assert((clear_offset & 0x3f) == 0);
> >uint32_t *clear_address =
> > --
> > 2.16.2
> >
> > ___
> > 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 v3 5/9] i965/wm_surface_state: Use the clear address if it's non-zero

[Jason Ekstrand]

Sounds good


On April 23, 2018 18:07:19 Nanley Chery  wrote:


On Mon, Apr 23, 2018 at 11:18:54AM -0700, Jason Ekstrand wrote:
> I think you want to say "clear_color_bo is non-NULL" in the commit message
> rather than talking about addresses.  Otherwise, this looks like a very
> nice clean-up.
>

To make sure we're on the same page, I made an error in using the term
clear address, because the code only checks part of it (the bo)?

What do you think of this new commit message?

   i965/wm_surface_state: Use the clear address if clear_bo is non-NULL

   We want to add and use a getter that turns off the indirect path by
   returning zero for the clear color bo and offset.

   v2: Fix usage of "clear address" in commit message (Jason).

> Reviewed-by: Jason Ekstrand 
>

Thanks!

-Nanley

> On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:
>
> > We want to add and use a getter that turns off the indirect path by
> > returning zero for the clear address.
> > ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 17 ++---
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index 06f739faf61..3c70dbcc110 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -155,6 +155,8 @@ brw_emit_surface_state(struct brw_context *brw,
> > struct brw_bo *aux_bo = NULL;
> > struct isl_surf *aux_surf = NULL;
> > uint64_t aux_offset = 0;
> > +   struct brw_bo *clear_bo = NULL;
> > +   uint32_t clear_offset = 0;
> > struct intel_miptree_aux_buffer *aux_buf =
> > intel_miptree_get_aux_buffer(mt);
> >
> > if (aux_usage != ISL_AUX_USAGE_NONE) {
> > @@ -165,6 +167,8 @@ brw_emit_surface_state(struct brw_context *brw,
> >/* We only really need a clear color if we also have an auxiliary
> > * surface.  Without one, it does nothing.
> > */
> > +  clear_bo = aux_buf->clear_color_bo;
> > +  clear_offset = aux_buf->clear_color_offset;
> >clear_color = mt->fast_clear_color;
> > }
> >
> > @@ -173,15 +177,6 @@ brw_emit_surface_state(struct brw_context *brw,
> >   brw->isl_dev.ss.align,
> >   surf_offset);
> >
> > -   bool use_clear_address = devinfo->gen >= 10 && aux_surf;
> > -
> > -   struct brw_bo *clear_bo = NULL;
> > -   uint32_t clear_offset = 0;
> > -   if (use_clear_address) {
> > -  clear_bo = aux_buf->clear_color_bo;
> > -  clear_offset = aux_buf->clear_color_offset;
> > -   }
> > -
> > isl_surf_fill_state(>isl_dev, state, .surf = , .view =
> > ,
> > .address = brw_state_reloc(>batch,
> >*surf_offset +
> > brw->isl_dev.ss.addr_offset,
> > @@ -190,7 +185,7 @@ brw_emit_surface_state(struct brw_context *brw,
> > .aux_address = aux_offset,
> > .mocs = brw_get_bo_mocs(devinfo, mt->bo),
> > .clear_color = clear_color,
> > -   .use_clear_address = use_clear_address,
> > +   .use_clear_address = clear_bo != NULL,
> > .clear_address = clear_offset,
> > .x_offset_sa = tile_x, .y_offset_sa = tile_y);
> > if (aux_surf) {
> > @@ -222,7 +217,7 @@ brw_emit_surface_state(struct brw_context *brw,
> >}
> > }
> >
> > -   if (use_clear_address) {
> > +   if (clear_bo != NULL) {
> >/* Make sure the offset is aligned with a cacheline. */
> >assert((clear_offset & 0x3f) == 0);
> >uint32_t *clear_address =
> > --
> > 2.16.2
> >
> > ___
> > 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 v3 7/9] i965: Add and use a getter for the clear color

[Jason Ekstrand]

I don't really like the helper because it seems like there should be a
simpler way to do this.  That said, I don't know of one. :-)

Reviewed-by: Jason Ekstrand 

On Wed, Apr 11, 2018 at 1:42 PM, Nanley Chery  wrote:

> This getter allows CNL to sample from fast-cleared sRGB textures correctly.
> ---
>  src/mesa/drivers/dri/i965/brw_blorp.c| 13 ---
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  7 +++---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 29
> 
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  8 +++
>  4 files changed, 46 insertions(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index a1882abb7cb..48022bb1c4f 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -166,7 +166,11 @@ blorp_surf_for_miptree(struct brw_context *brw,
>/* We only really need a clear color if we also have an auxiliary
> * surface.  Without one, it does nothing.
> */
> -  surf->clear_color = mt->fast_clear_color;
> +  surf->clear_color =
> + intel_miptree_get_clear_color(devinfo, mt, mt->surf.format,
> +   !is_render_target, (struct brw_bo
> **)
> +   >clear_color_addr.buffer,
> +   >clear_color_addr.offset);
>
>struct intel_miptree_aux_buffer *aux_buf =
>   intel_miptree_get_aux_buffer(mt);
> @@ -178,13 +182,6 @@ blorp_surf_for_miptree(struct brw_context *brw,
>
>surf->aux_addr.buffer = aux_buf->bo;
>surf->aux_addr.offset = aux_buf->offset;
> -
> -  if (devinfo->gen >= 10) {
> - surf->clear_color_addr = (struct blorp_address) {
> -.buffer = aux_buf->clear_color_bo,
> -.offset = aux_buf->clear_color_offset,
> - };
> -  }
> } else {
>surf->aux_addr = (struct blorp_address) {
>   .buffer = NULL,
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> index 3c70dbcc110..fb8e5942a11 100644
> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -167,9 +167,10 @@ brw_emit_surface_state(struct brw_context *brw,
>/* We only really need a clear color if we also have an auxiliary
> * surface.  Without one, it does nothing.
> */
> -  clear_bo = aux_buf->clear_color_bo;
> -  clear_offset = aux_buf->clear_color_offset;
> -  clear_color = mt->fast_clear_color;
> +  clear_color =
> + intel_miptree_get_clear_color(devinfo, mt, view.format,
> +   view.usage &
> ISL_SURF_USAGE_TEXTURE_BIT,
> +   _bo, _offset);
> }
>
> void *state = brw_state_batch(brw,
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index c5791835409..88468399e1b 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -46,6 +46,9 @@
>  #include "main/texcompress_etc.h"
>  #include "main/teximage.h"
>  #include "main/streaming-load-memcpy.h"
> +
> +#include "util/format_srgb.h"
> +
>  #include "x86/common_x86_asm.h"
>
>  #define FILE_DEBUG_FLAG DEBUG_MIPTREE
> @@ -3802,3 +3805,29 @@ intel_miptree_set_depth_clear_value(struct
> brw_context *brw,
> }
> return false;
>  }
> +
> +union isl_color_value
> +intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
> +  const struct intel_mipmap_tree *mt,
> +  enum isl_format view_format, bool sampling,
> +  struct brw_bo **clear_color_bo,
> +  uint32_t *clear_color_offset)
> +{
> +   assert(mt->aux_buf);
> +
> +   /* The gen10 sampler doesn't gamma-correct the clear color. */
> +   if (devinfo->gen == 10 && isl_format_is_srgb(view_format) &&
> sampling) {
> +  union isl_color_value srgb_decoded_value = mt->fast_clear_color;
> +  for (unsigned i = 0; i < 3; i++) {
> + srgb_decoded_value.f32[i] =
> +util_format_srgb_to_linear_float(mt->fast_clear_color.
> f32[i]);
> +  }
> +  *clear_color_bo = 0;
> +  *clear_color_offset = 0;
> +  return srgb_decoded_value;
> +   } else {
> +  *clear_color_bo = mt->aux_buf->clear_color_bo;
> +  *clear_color_offset = mt->aux_buf->clear_color_offset;
> +  return mt->fast_clear_color;
> +   }
> +}
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> index 643de962d31..bb059cf4e8f 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
> @@ -735,6 

Re: [Mesa-dev] [PATCH 7/7] broadcom/vc4: Native fence fd support

[Eric Anholt]

Stefan Schake  writes:

> With the syncobj support in place, lets use it to implement the
> native fence fd extension. This mostly follows previous implementations
> in freedreno and etnaviv.

Could we include the name of the actual extension being exposed, in the
commit message?

> Signed-off-by: Stefan Schake 
> ---
>  src/gallium/drivers/vc4/vc4_context.c | 47 
>  src/gallium/drivers/vc4/vc4_context.h |  5 +++
>  src/gallium/drivers/vc4/vc4_fence.c   | 68 
> ---
>  src/gallium/drivers/vc4/vc4_screen.c  |  6 ++--
>  src/gallium/drivers/vc4/vc4_screen.h  |  4 +--
>  5 files changed, 116 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_context.c 
> b/src/gallium/drivers/vc4/vc4_context.c
> index 0deb3ef85e..d41f1b9a26 100644
> --- a/src/gallium/drivers/vc4/vc4_context.c
> +++ b/src/gallium/drivers/vc4/vc4_context.c
> @@ -37,30 +37,54 @@
>  #include "vc4_context.h"
>  #include "vc4_resource.h"
>  
> -void
> -vc4_flush(struct pipe_context *pctx)
> +static void
> +vc4_flush_sync(struct pipe_context *pctx, uint32_t *in_sync)
>  {
>  struct vc4_context *vc4 = vc4_context(pctx);
>  
>  struct hash_entry *entry;
>  hash_table_foreach(vc4->jobs, entry) {
>  struct vc4_job *job = entry->data;
> -vc4_job_submit(vc4, job);
> +vc4_job_submit_sync(vc4, job, in_sync);
>  }
>  }
>  
> +void
> +vc4_flush(struct pipe_context *pctx)
> +{
> +vc4_flush_sync(pctx, NULL);
> +}
> +
>  static void
>  vc4_pipe_flush(struct pipe_context *pctx, struct pipe_fence_handle **fence,
> unsigned flags)
>  {
>  struct vc4_context *vc4 = vc4_context(pctx);
>  
> -vc4_flush(pctx);
> +if (vc4->in_fence_fd >= 0) {
> +/* This replaces the fence in the syncobj. */
> +drmSyncobjImportSyncFile(vc4->fd, vc4->in_syncobj,
> + vc4->in_fence_fd);
> +close(vc4->in_fence_fd);
> +vc4->in_fence_fd = -1;
> +vc4_flush_sync(pctx, >in_syncobj);
> +} else {
> +vc4_flush(pctx);
> +}

I suspect this is the wrong place to be doing the in-fence handling.
Imagine the sequence:

- vc4_fence_server_sync()
- Render from some shared object to a texture
- Render from the texture to the screen
- eglSwapBuffers().

This pipe_flush will happen at the top of eglSwapBuffers().  However,
the render from texture to screen will have already flushed the first
render job through vc4_flush_jobs_writing_resource() on its source
texture, so that job didn't wait on the fence like it was supposed to.

I think the solution might be to move this in_fence_fd logic to
vc4_job_submit()?

>  
>  if (fence) {
>  struct pipe_screen *screen = pctx->screen;
> +int fd = -1;
> +
> +if (flags & PIPE_FLUSH_FENCE_FD) {
> +/* The vc4_fence takes ownership of the returned fd. 
> */
> +drmSyncobjExportSyncFile(vc4->fd, vc4->job_syncobj,
> + );
> +}
> +
>  struct vc4_fence *f = vc4_fence_create(vc4->screen,
> -   vc4->last_emit_seqno);
> +   vc4->last_emit_seqno,
> +   fd);
>  screen->fence_reference(screen, fence, NULL);
>  *fence = (struct pipe_fence_handle *)f;
>  }
> @@ -124,8 +148,12 @@ vc4_context_destroy(struct pipe_context *pctx)
>  
>  vc4_program_fini(pctx);
>  
> -if (vc4->screen->has_syncobj)
> +if (vc4->screen->has_syncobj) {
>  drmSyncobjDestroy(vc4->fd, vc4->job_syncobj);
> +drmSyncobjDestroy(vc4->fd, vc4->in_syncobj);
> +}
> +if (vc4->in_fence_fd >= 0)
> +close(vc4->in_fence_fd);
>  
>  ralloc_free(vc4);
>  }
> @@ -161,12 +189,19 @@ vc4_context_create(struct pipe_screen *pscreen, void 
> *priv, unsigned flags)
>  vc4_query_init(pctx);
>  vc4_resource_context_init(pctx);
>  
> +vc4_job_init(vc4);
> +vc4_fence_context_init(vc4);
> +
>  vc4->fd = screen->fd;
>  
>  err = vc4_job_init(vc4);
>  if (err)
>  goto fail;
>  
> +err = vc4_fence_context_init(vc4);
> +if (err)
> +goto fail;
> +

Two vc4_fence_context_init()?

> +static int
> +vc4_fence_get_fd(struct pipe_screen *screen, struct pipe_fence_handle 
> *pfence)
> +{
> +struct vc4_fence *fence = vc4_fence(pfence);
> +
> +return dup(fence->fd);

There was a patch series recently for other drivers saying that we
should be doing "fcntl(fd, F_DUPFD_CLOEXEC, 3);" 

Re: [Mesa-dev] [PATCH 6/7] broadcom/vc4: Expose syncobj import

[Eric Anholt]

Stefan Schake  writes:

> Our submit ioctl allows to optionally specify a syncobj that will be
> waited on before job execution. Expose this in our job submission
> interface. Since every uint32_t could be a valid syncobj handle, pass
> the handle as a pointer so we can make it optional.
>
> Signed-off-by: Stefan Schake 
> ---
>  src/gallium/drivers/vc4/vc4_context.h |  2 ++
>  src/gallium/drivers/vc4/vc4_job.c | 24 +++-
>  2 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/vc4/vc4_context.h 
> b/src/gallium/drivers/vc4/vc4_context.h
> index d094957bb5..ac72a14008 100644
> --- a/src/gallium/drivers/vc4/vc4_context.h
> +++ b/src/gallium/drivers/vc4/vc4_context.h
> @@ -512,6 +512,8 @@ struct vc4_job *vc4_get_job(struct vc4_context *vc4,
>  struct vc4_job *vc4_get_job_for_fbo(struct vc4_context *vc4);
>  
>  void vc4_job_submit(struct vc4_context *vc4, struct vc4_job *job);
> +void vc4_job_submit_sync(struct vc4_context *vc4, struct vc4_job *job,
> + uint32_t* in_sync);
>  void vc4_flush_jobs_writing_resource(struct vc4_context *vc4,
>   struct pipe_resource *prsc);
>  void vc4_flush_jobs_reading_resource(struct vc4_context *vc4,
> diff --git a/src/gallium/drivers/vc4/vc4_job.c 
> b/src/gallium/drivers/vc4/vc4_job.c
> index 2b68ea7b74..1084d39b1f 100644
> --- a/src/gallium/drivers/vc4/vc4_job.c
> +++ b/src/gallium/drivers/vc4/vc4_job.c
> @@ -368,10 +368,22 @@ vc4_submit_setup_rcl_msaa_surface(struct vc4_job *job,
>  }
>  
>  /**
> - * Submits the job to the kernel and then reinitializes it.
> + * Wrapper for vc4_job_submit_sync omitting the rarely needed syncobj import
> + * parameter.
>   */
>  void
>  vc4_job_submit(struct vc4_context *vc4, struct vc4_job *job)
> +{
> +vc4_job_submit_sync(vc4, job, NULL);
> +}
> +
> +/**
> + * Submits the job to the kernel and then reinitializes it, optionally 
> passing
> + * a syncobj that will be waited on before job execution.
> + */
> +void
> +vc4_job_submit_sync(struct vc4_context *vc4, struct vc4_job *job,
> +uint32_t* in_sync)

Could we call this "vc4_job_submit_with_sync()" or something?
job_submit_sync() sounds to me like "submit this synchronously, so block
on completion."

Style nit: * goes next to the variable name rather than the type.
However, I think you can just use uint32_ts instead of pointers
throughout, with 0 meaning no sync obj.


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

[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

--- Comment #9 from Martin F  ---
The preset I'm using is 'Medium', in 1920x1080. The hang seem to happen very
often (or maybe every time when the game was never launched before) at the very
beginning of the game (when Jonas catch Lara when she jumps after the very
first fall).

dmesg:
[ 3442.737830] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
last signaled seq=272116, last emitted seq=272118
[ 3442.737835] [drm] No hardware hang detected. Did some blocks stall?
[ 3626.038022] INFO: task kworker/u32:3:163 blocked for more than 120 seconds.
[ 3626.038029]   Not tainted 4.17.0-rc1+ #5
[ 3626.038031] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 3626.038035] kworker/u32:3   D0   163  2 0x8000
[ 3626.038055] Workqueue: events_unbound commit_work [drm_kms_helper]
[ 3626.038058] Call Trace:
[ 3626.038068]  ? __schedule+0x291/0x870
[ 3626.038072]  schedule+0x28/0x80
[ 3626.038076]  schedule_timeout+0x1ee/0x380
[ 3626.038167]  ? dce120_timing_generator_get_crtc_position+0x5b/0x70 [amdgpu]
[ 3626.038271]  ? dce120_timing_generator_get_crtc_scanoutpos+0x70/0xb0
[amdgpu]
[ 3626.038279]  dma_fence_default_wait+0x1fd/0x280
[ 3626.038286]  ? dma_fence_release+0x90/0x90
[ 3626.038290]  dma_fence_wait_timeout+0x39/0xf0
[ 3626.038294]  reservation_object_wait_timeout_rcu+0x17b/0x370
[ 3626.038375]  amdgpu_dm_do_flip+0x112/0x350 [amdgpu]
[ 3626.038457]  amdgpu_dm_atomic_commit_tail+0xb00/0xd00 [amdgpu]
[ 3626.038463]  ? wait_for_completion_timeout+0x3b/0x1a0
[ 3626.038467]  ? pick_next_task_fair+0x35b/0x660
[ 3626.038473]  ? __switch_to+0xa2/0x450
[ 3626.038486]  commit_tail+0x3d/0x70 [drm_kms_helper]
[ 3626.038491]  process_one_work+0x17b/0x360
[ 3626.038495]  worker_thread+0x2e/0x390
[ 3626.038498]  ? process_one_work+0x360/0x360
[ 3626.038502]  kthread+0x113/0x130
[ 3626.038506]  ? kthread_create_worker_on_cpu+0x70/0x70
[ 3626.038509]  ret_from_fork+0x35/0x40

FYI I tried to start bisecting from mesa 17.3.5 but could not get very far due
to compilation issues (maybe related to llvm, not sure, I'm trying again).

-- 
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] Intel: Add a Kaby Lake PCI ID

[matthew . s . atwood]

From: Matt Atwood 

Signed-off-by: Matt Atwood 
---
 include/pci_ids/i965_pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index c740a50..6cbc32e 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
@@ -156,6 +156,7 @@ CHIPSET(0x5912, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby 
Lake GT2)")
 CHIPSET(0x5916, kbl_gt2, "Intel(R) HD Graphics 620 (Kaby Lake GT2)")
 CHIPSET(0x591A, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
 CHIPSET(0x591B, kbl_gt2, "Intel(R) HD Graphics 630 (Kaby Lake GT2)")
+CHIPSET(0x591C, kbl_gt2, "Intel(R) HD Graphics (Kaby Lake GT2)")
 CHIPSET(0x591D, kbl_gt2, "Intel(R) HD Graphics P630 (Kaby Lake GT2)")
 CHIPSET(0x591E, kbl_gt2, "Intel(R) HD Graphics 615 (Kaby Lake GT2)")
 CHIPSET(0x5921, kbl_gt2, "Intel(R) Kabylake GT2F")
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 2/5] radeonsi: fix error paths of si_texture_transfer_map

[Timothy Arceri]

On 20/04/18 17:19, Nicolai Hähnle wrote:

On 12.04.2018 02:10, Timothy Arceri wrote:



On 11/04/18 20:56, Nicolai Hähnle wrote:

From: Nicolai Hähnle 

trans is zero-initialized, but trans->resource is setup immediately so
needs to be dereferenced.
---
  src/gallium/drivers/radeonsi/si_texture.c | 25 
-

  1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_texture.c 
b/src/gallium/drivers/radeonsi/si_texture.c

index 0bab2a6c45b..907e8c8cec9 100644
--- a/src/gallium/drivers/radeonsi/si_texture.c
+++ b/src/gallium/drivers/radeonsi/si_texture.c
@@ -1728,49 +1728,46 @@ static void *si_texture_transfer_map(struct 
pipe_context *ctx,

   * then decompress the temporary one to staging.
   *
   * Only the region being mapped is transfered.
   */
  struct pipe_resource resource;
  si_init_temp_resource_from_box(, texture, box, 
level, 0);
  if (!si_init_flushed_depth_texture(ctx, , 
_depth)) {
  PRINT_ERR("failed to create temporary texture to 
hold untiled copy\n");

-    FREE(trans);
-    return NULL;
+    goto fail_trans;
  }
  if (usage & PIPE_TRANSFER_READ) {
  struct pipe_resource *temp = 
ctx->screen->resource_create(ctx->screen, );

  if (!temp) {
  PRINT_ERR("failed to create a temporary depth 
texture\n");

-    FREE(trans);
-    return NULL;
+    goto fail_trans;
  }
  si_copy_region_with_blit(ctx, temp, 0, 0, 0, 0, 
texture, level, box);
  si_blit_decompress_depth(ctx, (struct 
r600_texture*)temp, staging_depth,

   0, 0, 0, box->depth, 0, 0);
  pipe_resource_reference(, NULL);
  }
  /* Just get the strides. */
  si_texture_get_offset(sctx->screen, staging_depth, 
level, NULL,

  >b.b.stride,
  >b.b.layer_stride);
  } else {
  /* XXX: only readback the rectangle which is being 
mapped? */
  /* XXX: when discard is true, no need to read back from 
depth texture */
  if (!si_init_flushed_depth_texture(ctx, texture, 
_depth)) {
  PRINT_ERR("failed to create temporary texture to 
hold untiled copy\n");

-    FREE(trans);
-    return NULL;
+    goto fail_trans;
  }
  si_blit_decompress_depth(ctx, rtex, staging_depth,
   level, level,
   box->z, box->z + box->depth - 1,
   0, 0);
  offset = si_texture_get_offset(sctx->screen, 
staging_depth,

   level, box,
   >b.b.stride,
@@ -1785,22 +1782,21 @@ static void *si_texture_transfer_map(struct 
pipe_context *ctx,

  si_init_temp_resource_from_box(, texture, box, level,
   SI_RESOURCE_FLAG_TRANSFER);
  resource.usage = (usage & PIPE_TRANSFER_READ) ?
  PIPE_USAGE_STAGING : PIPE_USAGE_STREAM;
  /* Create the temporary texture. */
  staging = (struct 
r600_texture*)ctx->screen->resource_create(ctx->screen, );

  if (!staging) {
  PRINT_ERR("failed to create temporary texture to hold 
untiled copy\n");

-    FREE(trans);
-    return NULL;
+    goto fail_trans;
  }
  trans->staging = >resource;
  /* Just get the strides. */
  si_texture_get_offset(sctx->screen, staging, 0, NULL,
  >b.b.stride,
  >b.b.layer_stride);
  if (usage & PIPE_TRANSFER_READ)
  si_copy_to_staging_texture(ctx, trans);
@@ -1809,28 +1805,31 @@ static void *si_texture_transfer_map(struct 
pipe_context *ctx,

  buf = trans->staging;
  } else {
  /* the resource is mapped directly */
  offset = si_texture_get_offset(sctx->screen, rtex, level, box,
   >b.b.stride,
   >b.b.layer_stride);
  buf = >resource;
  }
-    if (!(map = si_buffer_map_sync_with_rings(sctx, buf, usage))) {
-    r600_resource_reference(>staging, NULL);
-    FREE(trans);
-    return NULL;
-    }
+    if (!(map = si_buffer_map_sync_with_rings(sctx, buf, usage)))
+    goto fail_trans;
  *ptransfer = >b.b;
  return map + offset;
+
+fail_trans:
+    r600_resource_reference(>staging, NULL);


this needs to be:

if (trans->staging)
    r600_resource_reference(>staging, NULL);


No, that's really not necessary. Only >staging needs to be 
non-NULL. r600_resource_reference is basically an assignment with 
reference counting, both the old and the new 

Re: [Mesa-dev] [PATCH v2] i965: Add and use a single miptree aux_buf field

[Jason Ekstrand]

Rb

On April 23, 2018 20:14:36 Nanley Chery  wrote:


We want to add and use a function that accesses the auxiliary buffer's
clear_color_bo and doesn't care if it has an MCS or HiZ buffer
specifically.

v2 (Jason Ekstrand):
* Drop intel_miptree_get_aux_buffer().
* Mention CCS in the aux_buf field.
---
src/mesa/drivers/dri/i965/brw_blorp.c|  16 ++--
src/mesa/drivers/dri/i965/brw_clear.c|   4 +-
src/mesa/drivers/dri/i965/brw_wm.c   |   2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  11 ++-
src/mesa/drivers/dri/i965/gen6_depth_state.c |   6 +-
src/mesa/drivers/dri/i965/gen7_misc_state.c  |   4 +-
src/mesa/drivers/dri/i965/gen8_depth_state.c |   6 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 106 +++
src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  53 +---
src/mesa/drivers/dri/i965/intel_tex_image.c  |   2 +-
10 files changed, 96 insertions(+), 114 deletions(-)

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

index 962a316c5cf..37fca5e9d31 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -168,21 +168,19 @@ blorp_surf_for_miptree(struct brw_context *brw,
   */
  surf->clear_color = mt->fast_clear_color;

-  struct intel_miptree_aux_buffer *aux_buf =
- intel_miptree_get_aux_buffer(mt);
-  surf->aux_surf = _buf->surf;
+  surf->aux_surf = >aux_buf->surf;
  surf->aux_addr = (struct blorp_address) {
 .reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
 .mocs = surf->addr.mocs,
  };

-  surf->aux_addr.buffer = aux_buf->bo;
-  surf->aux_addr.offset = aux_buf->offset;
+  surf->aux_addr.buffer = mt->aux_buf->bo;
+  surf->aux_addr.offset = mt->aux_buf->offset;

  if (devinfo->gen >= 10) {
 surf->clear_color_addr = (struct blorp_address) {
-.buffer = aux_buf->clear_color_bo,
-.offset = aux_buf->clear_color_offset,
+.buffer = mt->aux_buf->clear_color_bo,
+.offset = mt->aux_buf->clear_color_offset,
 };
  }
   } else {
@@ -1212,7 +1210,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,


   /* If the MCS buffer hasn't been allocated yet, we need to allocate it now.
*/
-   if (can_fast_clear && !irb->mt->mcs_buf) {
+   if (can_fast_clear && !irb->mt->aux_buf) {
  assert(irb->mt->aux_usage == ISL_AUX_USAGE_CCS_D);
  if (!intel_miptree_alloc_ccs(brw, irb->mt)) {
 /* There are a few reasons in addition to out-of-memory, that can
@@ -1611,7 +1609,7 @@ intel_hiz_exec(struct brw_context *brw, struct 
intel_mipmap_tree *mt,

   brw_emit_pipe_control_flush(brw, PIPE_CONTROL_DEPTH_STALL);
   }

-   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->hiz_buf);
+   assert(mt->aux_usage == ISL_AUX_USAGE_HIZ && mt->aux_buf);

   struct isl_surf isl_tmp[2];
   struct blorp_surf surf;
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c

index 487de9b8997..3d540d6d905 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -240,7 +240,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
  * buffer when doing a fast clear. Since we are skipping the fast
  * clear here, we need to update the clear color ourselves.
  */
- uint32_t clear_offset = mt->hiz_buf->clear_color_offset;
+ uint32_t clear_offset = mt->aux_buf->clear_color_offset;
 union isl_color_value clear_color = { .f32 = { clear_value, } };

 /* We can't update the clear color while the hardware is still using
@@ -249,7 +249,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
  */
 brw_emit_pipe_control_flush(brw, PIPE_CONTROL_CS_STALL);
 for (int i = 0; i < 4; i++) {
-brw_store_data_imm32(brw, mt->hiz_buf->clear_color_bo,
+brw_store_data_imm32(brw, mt->aux_buf->clear_color_bo,
 clear_offset + i * 4, clear_color.u32[i]);
 }
 brw_emit_pipe_control_flush(brw, PIPE_CONTROL_STATE_CACHE_INVALIDATE);
diff --git a/src/mesa/drivers/dri/i965/brw_wm.c 
b/src/mesa/drivers/dri/i965/brw_wm.c

index 68d4ab88d77..94048cd758f 100644
--- a/src/mesa/drivers/dri/i965/brw_wm.c
+++ b/src/mesa/drivers/dri/i965/brw_wm.c
@@ -384,7 +384,7 @@ brw_populate_sampler_prog_key_data(struct gl_context *ctx,
 if (intel_tex->mt->aux_usage == ISL_AUX_USAGE_MCS) {
assert(devinfo->gen >= 7);
assert(intel_tex->mt->surf.samples > 1);
-assert(intel_tex->mt->mcs_buf);
+assert(intel_tex->mt->aux_buf);
assert(intel_tex->mt->surf.msaa_layout == ISL_MSAA_LAYOUT_ARRAY);
key->compressed_multisample_layout_mask |= 1 << s;

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

[Mesa-dev] [Bug 91169] The Chronicles of Riddick: Assault on Dark Athena fails to start with nouveau

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #9 from Timothy Arceri  ---
The game is no longer available for Linux. Closing for now.

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

Re: [Mesa-dev] [PATCH] glsl/glcpp: Handle hex constants with 0X prefix

[Timothy Arceri]

On 24/04/18 02:04, Vlad Golovkin wrote:

2018-04-23 3:53 GMT+03:00 Timothy Arceri :



On 20/04/18 06:08, Vlad Golovkin wrote:


GLSL 4.6 spec describes hex constant as:

hexadecimal-constant:
  0x hexadecimal-digit
  0X hexadecimal-digit
  hexadecimal-constant hexadecimal-digit

Right now if you have a shader with the following structure:

  #if 0X1 // or any hex number with the 0X prefix
  // some code
  #endif

the code between #if and #endif gets removed because the checking is
performed
only for "0x" prefix which results in strtoll being called with the base 8
and
after encountering the 'X' char the strtoll returns 0. Letting strtoll
detect
the base makes this limitation go away and also makes code easier to read.



The problem is strtoll supports much more than what GLSL allows.



Also added 1 test for uppercase hex prefix.
---
   src/compiler/glsl/glcpp/glcpp-parse.y| 9
++---
   src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c   | 5
+
   .../glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected   | 5
+
   3 files changed, 12 insertions(+), 7 deletions(-)
   create mode 100644
src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
   create mode 100644
src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected

diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y
b/src/compiler/glsl/glcpp/glcpp-parse.y
index ccb3aa18d3..d83f99f1c7 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -462,13 +462,8 @@ control_line_error:
 integer_constant:
 INTEGER_STRING {
-   if (strlen ($1) >= 3 && strncmp ($1, "0x", 2) == 0) {




As per my coment above strtoll supports much more than what GLSL allows.
Please just add strncmp($1, "0X", 2) == 0 to the if above.


Flex and Bison is not my strongest suit, so correct me if I am wrong,
but it seems that INTEGER_STRING can't contain leading whitespace
and/or leading plus/minus that strtoll supports.
As for the multitude of bases that strtoll supports, it would ignore
them and just choose between 8, 10 and 16 when base = 0. I think I
should have made it more clear in the code comment.


Your right I missed that when reading the docs. I'll add something to 
the comment and push your patch. Thanks!






That patch would have my r-b. If you send that fixed up patch I can push it
for you. Thanks for looking into this.




-   $$ = strtoll ($1 + 2, NULL, 16);
-   } else if ($1[0] == '0') {
-   $$ = strtoll ($1, NULL, 8);
-   } else {
-   $$ = strtoll ($1, NULL, 10);
-   }
+   /* let strtoll detect the base */
+   $$ = strtoll ($1, NULL, 0);
 }
   | INTEGER {
 $$ = $1;
diff --git
a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
new file mode 100644
index 00..1be9b28eb7
--- /dev/null
+++ b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
@@ -0,0 +1,5 @@
+#if 0x1234abcd == 0X1234abcd
+success
+#else
+failure
+#endif
diff --git
a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
new file mode 100644
index 00..4cf250f6bb
--- /dev/null
+++
b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
@@ -0,0 +1,5 @@
+
+success
+
+
+




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

[Mesa-dev] [Bug 106174] vulkan dota2 broken (segfaulting), found bug commit

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #3 from Timothy Arceri  ---
Fixed by:

author  Bas Nieuwenhuizen 
commit  0e945fdf23bac5a62c15edfcbfd9d6ac4eee592f

nir: Do not use progress for unreachable code in return lowering.

We seem to use progress for two cases:
1) When we lowered some returns.
2) When we remove unreachable code.

If just case 2 happens we assert as state->return_flag has not
been allocated yet, but we are still trying to do insert all
predicates based on it.

This splits the concerns. We only use progress internally for case 1
and then keep track of 2 in a separate variable to indicate progress
in the return value of the pass.

This is slightly better than transforming the assert into
if (!state->return_flag) return, as the solution in this patch avoids
inserting predicates even if some other part of the might need them.

Fixes: 6e22ad6edc "nir: return early when lowering a return at the end of a
function"
CC: 18.1 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106174
Reviewed-by: Timothy Arceri 

-- 
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 26904] undefined symbol: GLwCreateM2DrawingArea

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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] mesa: rename api_validate.{c, h} -> draw_validate.{c, h}

[Timothy Arceri]

On 23/04/18 15:30, Mathias Fröhlich wrote:

Good Morning,

I was thinking to also basically 'move' vbo/vbo_exec_array.c to main/draw.c as
drawing arrays is today largely independent of the vbo module. Its more the
other way round that the vbo module utilizes the draw code path one notch
below the opengl entry points (... validate, set the Array._DrawVAO 'state'
and execute a draw). By that, the api_validate stuff would have fit into that
potential new main/draw.c.

Brian what do you think?

Anyhow, if we want, we can do this as a followup to all of the VAO cleanup and
on top of this patch, so for this one:


I've pushed this patch. We can do a further clean-up later if it makes 
sense. Thanks.





Reviewed-by: Mathias Fröhlich 

best

Mathias

On Monday, 23 April 2018 05:47:24 CEST Timothy Arceri wrote:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65422
---
  src/mesa/Makefile.sources | 4 ++--
  src/mesa/main/dlist.c | 2 +-
  src/mesa/main/{api_validate.c => draw_validate.c} | 2 +-
  src/mesa/main/{api_validate.h => draw_validate.h} | 0
  src/mesa/main/drawpix.c   | 2 +-
  src/mesa/meson.build  | 4 ++--
  src/mesa/vbo/vbo_exec_api.c   | 2 +-
  src/mesa/vbo/vbo_exec_array.c | 2 +-
  src/mesa/vbo/vbo_save_api.c   | 2 +-
  9 files changed, 10 insertions(+), 10 deletions(-)
  rename src/mesa/main/{api_validate.c => draw_validate.c} (99%)
  rename src/mesa/main/{api_validate.h => draw_validate.h} (100%)

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index c1220b9edc1..08c43195901 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -14,8 +14,6 @@ MAIN_FILES = \
main/api_exec.h \
main/api_loopback.c \
main/api_loopback.h \
-   main/api_validate.c \
-   main/api_validate.h \
main/arbprogram.c \
main/arbprogram.h \
main/arrayobj.c \
@@ -70,6 +68,8 @@ MAIN_FILES = \
main/drawpix.h \
main/drawtex.c \
main/drawtex.h \
+   main/draw_validate.c \
+   main/draw_validate.h \
main/enable.c \
main/enable.h \
main/enums.c \
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 2086611aa39..1b003c81a64 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -35,7 +35,7 @@
  #include "api_arrayelt.h"
  #include "api_exec.h"
  #include "api_loopback.h"
-#include "api_validate.h"
+#include "draw_validate.h"
  #include "atifragshader.h"
  #include "config.h"
  #include "bufferobj.h"
diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/draw_validate.c
similarity index 99%
rename from src/mesa/main/api_validate.c
rename to src/mesa/main/draw_validate.c
index 7b91fdff55f..bcb2d91306e 100644
--- a/src/mesa/main/api_validate.c
+++ b/src/mesa/main/draw_validate.c
@@ -24,7 +24,7 @@
  
  #include 

  #include "glheader.h"
-#include "api_validate.h"
+#include "draw_validate.h"
  #include "arrayobj.h"
  #include "bufferobj.h"
  #include "context.h"
diff --git a/src/mesa/main/api_validate.h b/src/mesa/main/draw_validate.h
similarity index 100%
rename from src/mesa/main/api_validate.h
rename to src/mesa/main/draw_validate.h
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index 4bf14fc4f28..2f55dde7b80 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -24,7 +24,7 @@
  
  #include "glheader.h"

  #include "imports.h"
-#include "api_validate.h"
+#include "draw_validate.h"
  #include "bufferobj.h"
  #include "context.h"
  #include "drawpix.h"
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index 93d197e12ac..3259956ad0b 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -63,8 +63,6 @@ files_libmesa_common = files(
'main/api_exec.h',
'main/api_loopback.c',
'main/api_loopback.h',
-  'main/api_validate.c',
-  'main/api_validate.h',
'main/arbprogram.c',
'main/arbprogram.h',
'main/arrayobj.c',
@@ -119,6 +117,8 @@ files_libmesa_common = files(
'main/drawpix.h',
'main/drawtex.c',
'main/drawtex.h',
+  'main/draw_validate.c',
+  'main/draw_validate.h',
'main/enable.c',
'main/enable.h',
'main/enums.h',
diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
index b3971715b57..20148acce32 100644
--- a/src/mesa/vbo/vbo_exec_api.c
+++ b/src/mesa/vbo/vbo_exec_api.c
@@ -40,7 +40,7 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
  #include "main/state.h"
  #include "main/light.h"
  #include "main/api_arrayelt.h"
-#include "main/api_validate.h"
+#include "main/draw_validate.h"
  #include "main/dispatch.h"
  #include "util/bitscan.h"
  
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c

index b3ce138a09e..e74e1bd458c 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -31,7 +31,7 @@
  #include "main/glheader.h"
  

Re: [Mesa-dev] [PATCH 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Dieter Nützel]

Hello Timo,

what about 2 and 3, #1 landed.

Dieter

Am 15.04.2018 18:16, schrieb Brian Paul:

The series looks OK to me.

Reviewed-by: Brian Paul 

On 04/13/2018 10:45 PM, Timothy Arceri wrote:

The extra params we unused by the drivers that used DrawBuffers.
---
  src/mesa/drivers/common/driverfuncs.c| 1 -
  src/mesa/drivers/dri/nouveau/nouveau_state.c | 4 ++--
  src/mesa/main/buffers.c  | 8 ++--
  src/mesa/main/dd.h   | 2 --
  src/mesa/state_tracker/st_cb_fbo.c   | 9 -
  5 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c

index 11134b69e94..b7ac2b5b434 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -134,7 +134,6 @@ _mesa_init_driver_functions(struct 
dd_function_table *driver)

 driver->ColorMaterial = NULL;
 driver->CullFace = NULL;
 driver->DrawBuffer = NULL;
-   driver->DrawBuffers = NULL;
 driver->FrontFace = NULL;
 driver->DepthFunc = NULL;
 driver->DepthMask = NULL;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_state.c 
b/src/mesa/drivers/dri/nouveau/nouveau_state.c

index e2b01043675..91ca95b5907 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_state.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_state.c
@@ -115,7 +115,7 @@ nouveau_read_buffer(struct gl_context *ctx, GLenum 
buffer)

  }
static void
-nouveau_draw_buffers(struct gl_context *ctx, GLsizei n, const GLenum 
*buffers)

+nouveau_draw_buffer(struct gl_context *ctx, GLenum buffers)
  {
nouveau_validate_framebuffer(ctx);
context_dirty(ctx, FRAMEBUFFER);
@@ -519,7 +519,7 @@ nouveau_state_init(struct gl_context *ctx)
ctx->Driver.DepthFunc = nouveau_depth_func;
ctx->Driver.DepthMask = nouveau_depth_mask;
ctx->Driver.ReadBuffer = nouveau_read_buffer;
-   ctx->Driver.DrawBuffers = nouveau_draw_buffers;
+   ctx->Driver.DrawBuffer = nouveau_draw_buffer;
ctx->Driver.Enable = nouveau_enable;
ctx->Driver.Fogfv = nouveau_fog;
ctx->Driver.Lightfv = nouveau_light;
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 5492227de08..7bb5725d085 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -304,9 +304,7 @@ draw_buffer(struct gl_context *ctx, struct 
gl_framebuffer *fb,
   /* Call device driver function only if fb is the bound draw 
buffer */

 if (fb == ctx->DrawBuffer) {
-  if (ctx->Driver.DrawBuffers)
- ctx->Driver.DrawBuffers(ctx, 1, );
-  else if (ctx->Driver.DrawBuffer)
+  if (ctx->Driver.DrawBuffer)
   ctx->Driver.DrawBuffer(ctx, buffer);
 }
  }
@@ -587,9 +585,7 @@ draw_buffers(struct gl_context *ctx, struct 
gl_framebuffer *fb, GLsizei n,

  * may not be valid.
  */
 if (fb == ctx->DrawBuffer) {
-  if (ctx->Driver.DrawBuffers)
- ctx->Driver.DrawBuffers(ctx, n, buffers);
-  else if (ctx->Driver.DrawBuffer)
+  if (ctx->Driver.DrawBuffer)
   ctx->Driver.DrawBuffer(ctx, n > 0 ? buffers[0] : GL_NONE);
 }
  }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 64ddd818835..d85d89ef50c 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -612,8 +612,6 @@ struct dd_function_table {
 void (*DepthRange)(struct gl_context *ctx);
 /** Specify the current buffer for writing */
 void (*DrawBuffer)( struct gl_context *ctx, GLenum buffer );
-   /** Specify the buffers for writing for fragment programs*/
-   void (*DrawBuffers)(struct gl_context *ctx, GLsizei n, const 
GLenum *buffers);

 /** Enable or disable server-side gl capabilities */
 void (*Enable)(struct gl_context *ctx, GLenum cap, GLboolean 
state);

 /** Specify fog parameters */
diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c

index f859133e399..696a08fd65b 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -714,13 +714,12 @@ st_validate_framebuffer(struct gl_context *ctx, 
struct gl_framebuffer *fb)

   * created FBOs.
   */
  static void
-st_DrawBuffers(struct gl_context *ctx, GLsizei count, const GLenum 
*buffers)

+st_DrawBuffer(struct gl_context *ctx, GLenum buffer)
  {
 struct st_context *st = st_context(ctx);
 struct gl_framebuffer *fb = ctx->DrawBuffer;
  -   (void) count;
-   (void) buffers;
+   (void) buffer;
   if (_mesa_is_winsys_fbo(fb)) {
GLuint i;
@@ -737,7 +736,7 @@ st_DrawBuffers(struct gl_context *ctx, GLsizei 
count, const GLenum *buffers)

  /**
- * Called via glReadBuffer.  As with st_DrawBuffers, we use this 
function
+ * Called via glReadBuffer.  As with st_DrawBuffer, we use this 
function

   * to check if we need to allocate a renderbuffer on demand.
   */
  static void
@@ -869,7 +868,7 @@ st_init_fbo_functions(struct dd_function_table 
*functions)

 functions->FinishRenderTexture 

[Mesa-dev] [Bug 64668] Clipping is performed incorrectly when using shaders with intel/nouveau/radeon drivers.

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

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

[Mesa-dev] [Bug 23525] Software rendering on QEMU guests badly broken

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Timothy Arceri  ---
Fixed by:

commit cfec000e7514342fd51859906e173ba2d474a55c
Author: Marc Pignat 
Date:   Tue Jun 28 15:21:58 2011 +0200

drisw: Fix 24bpp software rendering, take 2

This patch add the support for 24bpp in the dri/swrast implementation.
See http://bugs.freedesktop.org/show_bug.cgi?id=23525

Signed-off-by: Marc Pignat 
Signed-off-by: Brian Paul 

-- 
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 1/3] mesa: merge the driver functions DrawBuffers and DrawBuffer

[Timothy Arceri]

On 24/04/18 10:13, Dieter Nützel wrote:

Hello Timo,

what about 2 and 3, #1 landed.


It turns out the old radeon classic drivers do make use of the param 
dropped in patch 2 so I've decided to drop that patch, although the use 
of that param might be a bug as the intel drivers changed their behavior 
to fix a bug (however it's not a simple change).


I'd still like to push patch 3 but it's tripping up some old hardware in 
Intels CI system. I'm not sure whats going on yet.




Dieter

Am 15.04.2018 18:16, schrieb Brian Paul:

The series looks OK to me.

Reviewed-by: Brian Paul 

On 04/13/2018 10:45 PM, Timothy Arceri wrote:

The extra params we unused by the drivers that used DrawBuffers.
---
  src/mesa/drivers/common/driverfuncs.c    | 1 -
  src/mesa/drivers/dri/nouveau/nouveau_state.c | 4 ++--
  src/mesa/main/buffers.c  | 8 ++--
  src/mesa/main/dd.h   | 2 --
  src/mesa/state_tracker/st_cb_fbo.c   | 9 -
  5 files changed, 8 insertions(+), 16 deletions(-)

diff --git a/src/mesa/drivers/common/driverfuncs.c 
b/src/mesa/drivers/common/driverfuncs.c

index 11134b69e94..b7ac2b5b434 100644
--- a/src/mesa/drivers/common/driverfuncs.c
+++ b/src/mesa/drivers/common/driverfuncs.c
@@ -134,7 +134,6 @@ _mesa_init_driver_functions(struct 
dd_function_table *driver)

 driver->ColorMaterial = NULL;
 driver->CullFace = NULL;
 driver->DrawBuffer = NULL;
-   driver->DrawBuffers = NULL;
 driver->FrontFace = NULL;
 driver->DepthFunc = NULL;
 driver->DepthMask = NULL;
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_state.c 
b/src/mesa/drivers/dri/nouveau/nouveau_state.c

index e2b01043675..91ca95b5907 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_state.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_state.c
@@ -115,7 +115,7 @@ nouveau_read_buffer(struct gl_context *ctx, 
GLenum buffer)

  }
    static void
-nouveau_draw_buffers(struct gl_context *ctx, GLsizei n, const GLenum 
*buffers)

+nouveau_draw_buffer(struct gl_context *ctx, GLenum buffers)
  {
  nouveau_validate_framebuffer(ctx);
  context_dirty(ctx, FRAMEBUFFER);
@@ -519,7 +519,7 @@ nouveau_state_init(struct gl_context *ctx)
  ctx->Driver.DepthFunc = nouveau_depth_func;
  ctx->Driver.DepthMask = nouveau_depth_mask;
  ctx->Driver.ReadBuffer = nouveau_read_buffer;
-    ctx->Driver.DrawBuffers = nouveau_draw_buffers;
+    ctx->Driver.DrawBuffer = nouveau_draw_buffer;
  ctx->Driver.Enable = nouveau_enable;
  ctx->Driver.Fogfv = nouveau_fog;
  ctx->Driver.Lightfv = nouveau_light;
diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 5492227de08..7bb5725d085 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -304,9 +304,7 @@ draw_buffer(struct gl_context *ctx, struct 
gl_framebuffer *fb,
   /* Call device driver function only if fb is the bound draw 
buffer */

 if (fb == ctx->DrawBuffer) {
-  if (ctx->Driver.DrawBuffers)
- ctx->Driver.DrawBuffers(ctx, 1, );
-  else if (ctx->Driver.DrawBuffer)
+  if (ctx->Driver.DrawBuffer)
   ctx->Driver.DrawBuffer(ctx, buffer);
 }
  }
@@ -587,9 +585,7 @@ draw_buffers(struct gl_context *ctx, struct 
gl_framebuffer *fb, GLsizei n,

  * may not be valid.
  */
 if (fb == ctx->DrawBuffer) {
-  if (ctx->Driver.DrawBuffers)
- ctx->Driver.DrawBuffers(ctx, n, buffers);
-  else if (ctx->Driver.DrawBuffer)
+  if (ctx->Driver.DrawBuffer)
   ctx->Driver.DrawBuffer(ctx, n > 0 ? buffers[0] : GL_NONE);
 }
  }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 64ddd818835..d85d89ef50c 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -612,8 +612,6 @@ struct dd_function_table {
 void (*DepthRange)(struct gl_context *ctx);
 /** Specify the current buffer for writing */
 void (*DrawBuffer)( struct gl_context *ctx, GLenum buffer );
-   /** Specify the buffers for writing for fragment programs*/
-   void (*DrawBuffers)(struct gl_context *ctx, GLsizei n, const 
GLenum *buffers);

 /** Enable or disable server-side gl capabilities */
 void (*Enable)(struct gl_context *ctx, GLenum cap, GLboolean 
state);

 /** Specify fog parameters */
diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c

index f859133e399..696a08fd65b 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -714,13 +714,12 @@ st_validate_framebuffer(struct gl_context *ctx, 
struct gl_framebuffer *fb)

   * created FBOs.
   */
  static void
-st_DrawBuffers(struct gl_context *ctx, GLsizei count, const GLenum 
*buffers)

+st_DrawBuffer(struct gl_context *ctx, GLenum buffer)
  {
 struct st_context *st = st_context(ctx);
 struct gl_framebuffer *fb = ctx->DrawBuffer;
  -   (void) count;
-   (void) buffers;
+   (void) buffer;
   if (_mesa_is_winsys_fbo(fb)) {
    GLuint i;
@@ -737,7 +736,7 @@ st_DrawBuffers(struct 

[Mesa-dev] [Bug 66346] shader_query.cpp:49: error: invalid conversion from 'void*' to 'GLuint'

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #22 from Timothy Arceri  ---
Should be fixed by:

commit a087a09fa86f9617af98f6294dd2228555a4891c
Author: Jeremy Huddleston Sequoia 
Date:   Wed Jan 20 16:59:45 2016 -0800

mesa: Fix some function prototype mismatching

main/api_exec.c:543:36: warning: incompatible pointer types passing 'void
(GLhandleARB, GLuint, const GLcharARB *)' (aka 'void (unsigned long, unsigned
int, const char *)') to
parameter of
  type 'void (*)(GLuint, GLuint, const GLchar *)' (aka 'void
(*)(unsigned int, unsigned int, const char *)') [-Wincompatible-pointer-types]
  SET_BindAttribLocation(exec, _mesa_BindAttribLocation);
   ^~~~
./main/dispatch.h:7590:88: note: passing argument to parameter 'fn' here
static inline void SET_BindAttribLocation(struct _glapi_table *disp, void
(GLAPIENTRYP fn)(GLuint, GLuint, const GLchar *)) {
   
   ^
main/api_exec.c:547:31: warning: incompatible pointer types passing 'void
(GLhandleARB)' (aka 'void (unsigned long)') to parameter of type 'void
(*)(GLuint)' (aka 'void (*)(unsigned
int)')
  [-Wincompatible-pointer-types]
  SET_CompileShader(exec, _mesa_CompileShader);
  ^~~
./main/dispatch.h:7612:83: note: passing argument to parameter 'fn' here
static inline void SET_CompileShader(struct _glapi_table *disp, void
(GLAPIENTRYP fn)(GLuint)) {
   
  ^
main/api_exec.c:568:33: warning: incompatible pointer types passing 'void
(GLhandleARB, GLuint, GLsizei, GLsizei *, GLint *, GLenum *, GLcharARB *)' (aka
'void (unsigned long,
unsigned int,
  int, int *, int *, unsigned int *, char *)') to parameter of type
'void (*)(GLuint, GLuint, GLsizei, GLsizei *, GLint *, GLenum *, GLchar *)'
(aka 'void (*)(unsigned int,
unsigned int,
  int, int *, int *, unsigned int *, char *)')
[-Wincompatible-pointer-types]
  SET_GetActiveAttrib(exec, _mesa_GetActiveAttrib);
^
./main/dispatch.h:7711:85: note: passing argument to parameter 'fn' here
static inline void SET_GetActiveAttrib(struct _glapi_table *disp, void
(GLAPIENTRYP fn)(GLuint, GLuint, GLsizei , GLsizei *, GLint *, GLenum *, GLchar
*)) {
   
^
main/api_exec.c:571:35: warning: incompatible pointer types passing 'GLint
(GLhandleARB, const GLcharARB *)' (aka 'int (unsigned long, const char *)') to
parameter of type
  'GLint (*)(GLuint, const GLchar *)' (aka 'int (*)(unsigned int, const
char *)') [-Wincompatible-pointer-types]
  SET_GetAttribLocation(exec, _mesa_GetAttribLocation);
  ^~~
./main/dispatch.h:7744:88: note: passing argument to parameter 'fn' here
static inline void SET_GetAttribLocation(struct _glapi_table *disp, GLint
(GLAPIENTRYP fn)(GLuint, const GLchar *)) {
   
   ^
main/api_exec.c:585:33: warning: incompatible pointer types passing 'void
(GLhandleARB, GLsizei, GLsizei *, GLcharARB *)' (aka 'void (unsigned long, int,
int *, char *)') to
parameter of
  type 'void (*)(GLuint, GLsizei, GLsizei *, GLchar *)' (aka 'void
(*)(unsigned int, int, int *, char *)') [-Wincompatible-pointer-types]
  SET_GetShaderSource(exec, _mesa_GetShaderSource);
^
./main/dispatch.h:7788:85: note: passing argument to parameter 'fn' here
static inline void SET_GetShaderSource(struct _glapi_table *disp, void
(GLAPIENTRYP fn)(GLuint, GLsizei, GLsizei *, GLchar *)) {
   
^
main/api_exec.c:597:29: warning: incompatible pointer types passing 'void
(GLhandleARB)' (aka 'void (unsigned long)') to parameter of type 'void
(*)(GLuint)' (aka 'void (*)(unsigned
int)')
  [-Wincompatible-pointer-types]
  SET_LinkProgram(exec, _mesa_LinkProgram);
^
./main/dispatch.h:7909:81: note: passing argument to parameter 'fn' here
static inline void SET_LinkProgram(struct _glapi_table *disp, void
(GLAPIENTRYP fn)(GLuint)) {
 

[Mesa-dev] [Bug 24334] mesa git fails to build with xf86vidmodeproto 2.3

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Mesa-dev] [PATCH 3/3] mesa: call DrawBufferAllocate driver hook in update_framebuffer for windows-system FB

[Timothy Arceri]

From: Boyan Ding 

When draw buffers are changed on a bound framebuffer, DrawBufferAllocate()
hook should be called. However, it is missing in update_framebuffer with
window-system framebuffer, in which FB's draw buffer state should match
context state, potentially resulting in a change.

Note: This is needed because gallium delays creating the front buffer,
  i965 works fine without this change.

V2 (Timothy Arceri):
 - Rebased on merged/simplified DrawBuffer driver function
 - Move DrawBuffer call outside fb->ColorDrawBuffer[0] !=
   ctx->Color.DrawBuffer[0] check to make piglit pass.

v3 (Timothy Arceri):
 - Call new DrawBuffaerAllocate() driver function.

Tested-by: Dieter Nützel  (v2)
Reviewed-by: Brian Paul  (v2)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
---
 src/mesa/main/framebuffer.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 211e97c33bd..4ea18f6858e 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -617,6 +617,12 @@ update_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  _mesa_drawbuffers(ctx, fb, ctx->Const.MaxDrawBuffers,
ctx->Color.DrawBuffer, NULL);
   }
+
+  /* Call device driver function if fb is the bound draw buffer. */
+  if (fb == ctx->DrawBuffer) {
+ if (ctx->Driver.DrawBufferAllocate)
+ctx->Driver.DrawBufferAllocate(ctx);
+  }
}
else {
   /* This is a user-created framebuffer.
-- 
2.17.0

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

[Mesa-dev] [Bug 99116] Wine DirectDraw programs showing only a blackscreen when using Mesa Gallium drivers

[bugzilla-daemon]

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

--- Comment #18 from Timothy Arceri  ---
Ok, new series sent:

https://patchwork.freedesktop.org/series/42155/

-- 
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 1/3] mesa: some C99 tidy ups for framebuffer.c

[Timothy Arceri]

---
 src/mesa/main/framebuffer.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 249e775f8cb..211e97c33bd 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src/mesa/main/framebuffer.c
@@ -210,14 +210,12 @@ _mesa_destroy_framebuffer(struct gl_framebuffer *fb)
 void
 _mesa_free_framebuffer_data(struct gl_framebuffer *fb)
 {
-   GLuint i;
-
assert(fb);
assert(fb->RefCount == 0);
 
simple_mtx_destroy(>Mutex);
 
-   for (i = 0; i < BUFFER_COUNT; i++) {
+   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
   struct gl_renderbuffer_attachment *att = >Attachment[i];
   if (att->Renderbuffer) {
  _mesa_reference_renderbuffer(>Renderbuffer, NULL);
@@ -280,8 +278,6 @@ void
 _mesa_resize_framebuffer(struct gl_context *ctx, struct gl_framebuffer *fb,
  GLuint width, GLuint height)
 {
-   GLuint i;
-
/* XXX I think we could check if the size is not changing
 * and return early.
 */
@@ -289,7 +285,7 @@ _mesa_resize_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb,
/* Can only resize win-sys framebuffer objects */
assert(_mesa_is_winsys_fbo(fb));
 
-   for (i = 0; i < BUFFER_COUNT; i++) {
+   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
   struct gl_renderbuffer_attachment *att = >Attachment[i];
   if (att->Type == GL_RENDERBUFFER_EXT && att->Renderbuffer) {
  struct gl_renderbuffer *rb = att->Renderbuffer;
@@ -427,13 +423,11 @@ void
 _mesa_update_framebuffer_visual(struct gl_context *ctx,
struct gl_framebuffer *fb)
 {
-   GLuint i;
-
memset(>Visual, 0, sizeof(fb->Visual));
fb->Visual.rgbMode = GL_TRUE; /* assume this */
 
/* find first RGB renderbuffer */
-   for (i = 0; i < BUFFER_COUNT; i++) {
+   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
   if (fb->Attachment[i].Renderbuffer) {
  const struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer;
  const GLenum baseFormat = _mesa_get_format_base_format(rb->Format);
@@ -461,7 +455,7 @@ _mesa_update_framebuffer_visual(struct gl_context *ctx,
}
 
fb->Visual.floatMode = GL_FALSE;
-   for (i = 0; i < BUFFER_COUNT; i++) {
+   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
   if (fb->Attachment[i].Renderbuffer) {
  const struct gl_renderbuffer *rb = fb->Attachment[i].Renderbuffer;
  const mesa_format fmt = rb->Format;
@@ -936,14 +930,12 @@ _mesa_get_read_renderbuffer_for_format(const struct 
gl_context *ctx,
 void
 _mesa_print_framebuffer(const struct gl_framebuffer *fb)
 {
-   GLuint i;
-
fprintf(stderr, "Mesa Framebuffer %u at %p\n", fb->Name, (void *) fb);
fprintf(stderr, "  Size: %u x %u  Status: %s\n", fb->Width, fb->Height,
_mesa_enum_to_string(fb->_Status));
fprintf(stderr, "  Attachments:\n");
 
-   for (i = 0; i < BUFFER_COUNT; i++) {
+   for (unsigned i = 0; i < BUFFER_COUNT; i++) {
   const struct gl_renderbuffer_attachment *att = >Attachment[i];
   if (att->Type == GL_TEXTURE) {
  const struct gl_texture_image *texImage = att->Renderbuffer->TexImage;
-- 
2.17.0

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

[Mesa-dev] [PATCH 2/3] st/mesa: add new driver function DrawBufferAllocate

[Timothy Arceri]

Unlike some of the classic drivers the st was only using DrawBuffer()
to allocated some buffers on-demand. Creating a separate function
will allow us to call it from update_framebuffer() in the following
patch without regressing some of the older classic drivers.
---
 src/mesa/main/buffers.c|  4 
 src/mesa/main/dd.h |  4 +++-
 src/mesa/state_tracker/st_cb_fbo.c | 10 --
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
index 7bb5725d085..ba970d87dad 100644
--- a/src/mesa/main/buffers.c
+++ b/src/mesa/main/buffers.c
@@ -306,6 +306,8 @@ draw_buffer(struct gl_context *ctx, struct gl_framebuffer 
*fb,
if (fb == ctx->DrawBuffer) {
   if (ctx->Driver.DrawBuffer)
  ctx->Driver.DrawBuffer(ctx, buffer);
+  if (ctx->Driver.DrawBufferAllocate)
+ ctx->Driver.DrawBufferAllocate(ctx);
}
 }
 
@@ -587,6 +589,8 @@ draw_buffers(struct gl_context *ctx, struct gl_framebuffer 
*fb, GLsizei n,
if (fb == ctx->DrawBuffer) {
   if (ctx->Driver.DrawBuffer)
  ctx->Driver.DrawBuffer(ctx, n > 0 ? buffers[0] : GL_NONE);
+  if (ctx->Driver.DrawBufferAllocate)
+ ctx->Driver.DrawBufferAllocate(ctx);
}
 }
 
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index d85d89ef50c..5ee6902d3fb 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -611,7 +611,9 @@ struct dd_function_table {
/** Specify mapping of depth values from NDC to window coordinates */
void (*DepthRange)(struct gl_context *ctx);
/** Specify the current buffer for writing */
-   void (*DrawBuffer)( struct gl_context *ctx, GLenum buffer );
+   void (*DrawBuffer)(struct gl_context *ctx, GLenum buffer);
+   /** Used to allocated any buffers with on-demand creation */
+   void (*DrawBufferAllocate)(struct gl_context *ctx);
/** Enable or disable server-side gl capabilities */
void (*Enable)(struct gl_context *ctx, GLenum cap, GLboolean state);
/** Specify fog parameters */
diff --git a/src/mesa/state_tracker/st_cb_fbo.c 
b/src/mesa/state_tracker/st_cb_fbo.c
index 696a08fd65b..5eeec08655d 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -714,13 +714,11 @@ st_validate_framebuffer(struct gl_context *ctx, struct 
gl_framebuffer *fb)
  * created FBOs.
  */
 static void
-st_DrawBuffer(struct gl_context *ctx, GLenum buffer)
+st_DrawBufferAllocate(struct gl_context *ctx)
 {
struct st_context *st = st_context(ctx);
struct gl_framebuffer *fb = ctx->DrawBuffer;
 
-   (void) buffer;
-
if (_mesa_is_winsys_fbo(fb)) {
   GLuint i;
   /* add the renderbuffers on demand */
@@ -736,8 +734,8 @@ st_DrawBuffer(struct gl_context *ctx, GLenum buffer)
 
 
 /**
- * Called via glReadBuffer.  As with st_DrawBuffer, we use this function
- * to check if we need to allocate a renderbuffer on demand.
+ * Called via glReadBuffer.  As with st_DrawBufferAllocate, we use this
+ * function to check if we need to allocate a renderbuffer on demand.
  */
 static void
 st_ReadBuffer(struct gl_context *ctx, GLenum buffer)
@@ -868,7 +866,7 @@ st_init_fbo_functions(struct dd_function_table *functions)
functions->FinishRenderTexture = st_finish_render_texture;
functions->ValidateFramebuffer = st_validate_framebuffer;
 
-   functions->DrawBuffer = st_DrawBuffer;
+   functions->DrawBufferAllocate = st_DrawBufferAllocate;
functions->ReadBuffer = st_ReadBuffer;
 
functions->MapRenderbuffer = st_MapRenderbuffer;
-- 
2.17.0

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