Re: [Mesa-dev] [PATCH] i965: Disable L3 cache allocation for external buffers

[Timo Aaltonen]

On 24.10.2017 19:06, Chris Wilson wrote:
> Through the use of mocs, we can define the cache usage for any surface
> used by the GPU. In particular, we can request that L3 cache be
> allocated for either a read/write miss so that subsequent reads can be
> fetched from cache rather than memory. A consequence of this is that if
> we allocate a L3/LLC cacheline for a read and the object is changed in
> main memory (e.g. a PCIe write bypassing the CPU) then the next read
> will be serviced from the stale cache and not from the new data in
> memory. This is an issue for external PRIME buffers where we may miss
> the updates entirely if the image is small enough to fit within our
> cache.
> 
> Currently, we have a single bit to mark all external buffers so use that
> to tell us when it is unsafe to use a cache override in mocs and
> fallback to the PTE value instead (which should be set to the correct
> cache level to be coherent amongst all active parties: PRIME, scanout and
> render). This may be refined in future to limit the override to buffers
> outside the control of mesa; as buffers being shared between mesa
> clients should be able to coordinate themselves without resolves.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101691
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Lyude Paul 
> Cc: Timo Aalton 
> Cc: Ben Widawsky 
> Cc: Daniel Vetter 

This did not pass our testing, though I backported it to 17.2. Should
that matter?


-- 
t

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

Re: [Mesa-dev] [PATCH] amdgpu: Add R600_DEBUG flag to reserve VMID per ctx.

[Christian König]

Am 31.10.2017 um 16:50 schrieb Michel Dänzer:

On 31/10/17 04:40 PM, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 

[...]


diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 8f43e93..1155492 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -256,6 +256,14 @@ static struct radeon_winsys_ctx *amdgpu_ctx_create(struct 
radeon_winsys *ws)
goto error_create;
 }
  
+   if (ctx->ws->reserve_vmid) {

+  r = amdgpu_vm_reserve_vmid(ctx->ctx, 0);
+  if (r) {
+   fprintf(stderr, "amdgpu: amdgpu_cs_ctx_create failed. (%i)\n", 
r);

This should say "amdgpu: amdgpu_vm_reserve_vmid failed. (%i)\n".



Not sure when amdgpu_ctx_create() is called, but the VMID is reserved 
per process not per context.


Christian.

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

Re: [Mesa-dev] [PATCH] amdgpu: Add R600_DEBUG flag to reserve VMID per ctx.

[Christian König]

I'm not 100% sure that patch was correct.

When is amdgpu_ctx_create() called? The VMID is reserved for the whole 
process, not just a context.


Regards,
Christian.

Am 31.10.2017 um 16:57 schrieb Marek Olšák:

I addressed the feedback and pushed the patch.

Marek

On Tue, Oct 31, 2017 at 4:50 PM, Michel Dänzer  wrote:

On 31/10/17 04:40 PM, Andrey Grodzovsky wrote:

Signed-off-by: Andrey Grodzovsky 

[...]


diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 8f43e93..1155492 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -256,6 +256,14 @@ static struct radeon_winsys_ctx *amdgpu_ctx_create(struct 
radeon_winsys *ws)
goto error_create;
 }

+   if (ctx->ws->reserve_vmid) {
+r = amdgpu_vm_reserve_vmid(ctx->ctx, 0);
+if (r) {
+ fprintf(stderr, "amdgpu: amdgpu_cs_ctx_create failed. (%i)\n", r);

This should say "amdgpu: amdgpu_vm_reserve_vmid failed. (%i)\n".


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



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

Re: [Mesa-dev] [PATCH 1/2] configure.ac: append to existing MSVC compat flags

[Eric Engestrom]

On Tuesday, 2017-10-31 19:26:32 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Currently we were overwriting the existing warning flags, instead of
> adding new [as applicable].
> 
> Fixes e4b2b69e828 ("configure: Add and use AX_CHECK_COMPILE_FLAG")
> Cc: Matt Turner 
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index efc653ad7fa..1bba6c5b208 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -309,11 +309,11 @@ AC_LANG_POP([C++])
>  # - non-Linux/Posix OpenGL portions needs to build on MSVC 2013 (which
>  #   supports most of C99)
>  # - the rest has no compiler compiler restrictions
> -AX_CHECK_COMPILE_FLAG([-Werror=pointer-arith], 
> [MSVC2013_COMPAT_CFLAGS="-Werror=pointer-arith"])
> -AX_CHECK_COMPILE_FLAG([-Werror=vla],   
> [MSVC2013_COMPAT_CFLAGS="-Werror=vla"])
> +AX_CHECK_COMPILE_FLAG([-Werror=pointer-arith], 
> [MSVC2013_COMPAT_CFLAGS="$MSVC2013_COMPAT_CFLAGS-Werror=pointer-arith"])

Missing space between `$MSVC2013_COMPAT_CFLAGS` and `-Werror`

With that fixed, both patches are
Reviewed-by: Eric Engestrom 

> +AX_CHECK_COMPILE_FLAG([-Werror=vla],   
> [MSVC2013_COMPAT_CFLAGS="$MSVC2013_COMPAT_CFLAGS -Werror=vla"])
>  AC_LANG_PUSH([C++])
> -AX_CHECK_COMPILE_FLAG([-Werror=pointer-arith], 
> [MSVC2013_COMPAT_CXXFLAGS="-Werror=pointer-arith"])
> -AX_CHECK_COMPILE_FLAG([-Werror=vla],   
> [MSVC2013_COMPAT_CXXFLAGS="-Werror=vla"])
> +AX_CHECK_COMPILE_FLAG([-Werror=pointer-arith], 
> [MSVC2013_COMPAT_CXXFLAGS="$MSVC2013_COMPAT_CXXFLAGS -Werror=pointer-arith"])
> +AX_CHECK_COMPILE_FLAG([-Werror=vla],   
> [MSVC2013_COMPAT_CXXFLAGS="$MSVC2013_COMPAT_CXXFLAGS -Werror=vla"])
>  AC_LANG_POP([C++])
>  
>  AC_SUBST([MSVC2013_COMPAT_CFLAGS])
> -- 
> 2.14.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Wladimir J. van der Laan]

GC3000 resolve-in-place assumes that the TS state is configured.
If it is not, this will result in MMU errors. This is especially
apparent when using glGenMipmaps().

Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.

Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
 src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
 src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
 src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
 4 files changed, 11 insertions(+)

Ooops. This seems like an obvious oversight but I hadn't thought we would get
into this path at all when there is no TS to "flush".

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index c62287b..8fc7cfc 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -555,6 +555,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
}
 
/* Set up color TS to source surface before blit, if needed */
+   bool source_ts_valid = false;
if (src->levels[blit_info->src.level].ts_size &&
src->levels[blit_info->src.level].ts_valid) {
   struct etna_reloc reloc;
@@ -579,6 +580,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
 
   etna_set_state(ctx->stream, VIVS_TS_COLOR_CLEAR_VALUE,
  src->levels[blit_info->src.level].clear_value);
+
+  source_ts_valid = true;
} else {
   etna_set_state(ctx->stream, VIVS_TS_MEM_CONFIG, ts_mem_config);
}
@@ -593,6 +596,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
   .source_stride = src_lev->stride,
   .source_padded_width = src_lev->padded_width,
   .source_padded_height = src_lev->padded_height,
+  .source_ts_valid = source_ts_valid,
   .dest_format = translate_rs_format(dst_format),
   .dest_tiling = dst->layout,
   .dest = dst->bo,
diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
b/src/gallium/drivers/etnaviv/etnaviv_emit.c
index 707b1e7..5397aa3 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
@@ -171,6 +171,10 @@ etna_submit_rs_state(struct etna_context *ctx,
struct etna_cmd_stream *stream = ctx->stream;
struct etna_coalesce coalesce;
 
+   if (cs->RS_KICKER_INPLACE && !cs->source_ts_valid)
+  /* Inplace resolve is no-op if TS is not configured */
+  return;
+
ctx->stats.rs_operations++;
 
if (cs->RS_KICKER_INPLACE) {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
b/src/gallium/drivers/etnaviv/etnaviv_rs.c
index c9072c2..60c2c39 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
@@ -133,6 +133,7 @@ etna_compile_rs_state(struct etna_context *ctx, struct 
compiled_rs_state *cs,
   /* Total number of tiles (same as for autodisable) */
   cs->RS_KICKER_INPLACE = rs->source_padded_width * 
rs->source_padded_height / 16;
}
+   cs->source_ts_valid = rs->source_ts_valid;
 }
 
 void
diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
b/src/gallium/drivers/etnaviv/etnaviv_rs.h
index 171d3fa..41a5960 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
@@ -33,6 +33,7 @@
 struct rs_state {
uint8_t downsample_x : 1; /* Downsample in x direction */
uint8_t downsample_y : 1; /* Downsample in y direction */
+   uint8_t source_ts_valid : 1;
 
uint8_t source_format; /* RS_FORMAT_XXX */
uint8_t source_tiling; /* ETNA_LAYOUT_XXX */
@@ -61,6 +62,7 @@ struct rs_state {
 
 /* treat this as opaque structure */
 struct compiled_rs_state {
+   uint8_t source_ts_valid : 1;
uint32_t RS_CONFIG;
uint32_t RS_SOURCE_STRIDE;
uint32_t RS_DEST_STRIDE;
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Eric Engestrom]

On Wednesday, 2017-11-01 11:17:53 +0100, Wladimir J. van der Laan wrote:
> GC3000 resolve-in-place assumes that the TS state is configured.
> If it is not, this will result in MMU errors. This is especially
> apparent when using glGenMipmaps().
> 
> Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.

I can't review your patch because I don't know anything about that code,
but a quick drive-by comment: the format for this information is

Fixes: 78ade659569ee6fe9bd2 "etnaviv: Do GC3000 resolve-in-place when possible"

That way, scripts can parse it and apply the fix everywhere the commit
introducing the issue exists :)

> 
> Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
>  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
>  4 files changed, 11 insertions(+)
> 
> Ooops. This seems like an obvious oversight but I hadn't thought we would get
> into this path at all when there is no TS to "flush".
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index c62287b..8fc7cfc 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -555,6 +555,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> }
>  
> /* Set up color TS to source surface before blit, if needed */
> +   bool source_ts_valid = false;
> if (src->levels[blit_info->src.level].ts_size &&
> src->levels[blit_info->src.level].ts_valid) {
>struct etna_reloc reloc;
> @@ -579,6 +580,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
>  
>etna_set_state(ctx->stream, VIVS_TS_COLOR_CLEAR_VALUE,
>   src->levels[blit_info->src.level].clear_value);
> +
> +  source_ts_valid = true;
> } else {
>etna_set_state(ctx->stream, VIVS_TS_MEM_CONFIG, ts_mem_config);
> }
> @@ -593,6 +596,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>.source_stride = src_lev->stride,
>.source_padded_width = src_lev->padded_width,
>.source_padded_height = src_lev->padded_height,
> +  .source_ts_valid = source_ts_valid,
>.dest_format = translate_rs_format(dst_format),
>.dest_tiling = dst->layout,
>.dest = dst->bo,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index 707b1e7..5397aa3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -171,6 +171,10 @@ etna_submit_rs_state(struct etna_context *ctx,
> struct etna_cmd_stream *stream = ctx->stream;
> struct etna_coalesce coalesce;
>  
> +   if (cs->RS_KICKER_INPLACE && !cs->source_ts_valid)
> +  /* Inplace resolve is no-op if TS is not configured */
> +  return;
> +
> ctx->stats.rs_operations++;
>  
> if (cs->RS_KICKER_INPLACE) {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index c9072c2..60c2c39 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -133,6 +133,7 @@ etna_compile_rs_state(struct etna_context *ctx, struct 
> compiled_rs_state *cs,
>/* Total number of tiles (same as for autodisable) */
>cs->RS_KICKER_INPLACE = rs->source_padded_width * 
> rs->source_padded_height / 16;
> }
> +   cs->source_ts_valid = rs->source_ts_valid;
>  }
>  
>  void
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> index 171d3fa..41a5960 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> @@ -33,6 +33,7 @@
>  struct rs_state {
> uint8_t downsample_x : 1; /* Downsample in x direction */
> uint8_t downsample_y : 1; /* Downsample in y direction */
> +   uint8_t source_ts_valid : 1;
>  
> uint8_t source_format; /* RS_FORMAT_XXX */
> uint8_t source_tiling; /* ETNA_LAYOUT_XXX */
> @@ -61,6 +62,7 @@ struct rs_state {
>  
>  /* treat this as opaque structure */
>  struct compiled_rs_state {
> +   uint8_t source_ts_valid : 1;
> uint32_t RS_CONFIG;
> uint32_t RS_SOURCE_STRIDE;
> uint32_t RS_DEST_STRIDE;
> -- 
> 2.7.4
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Lucas Stach]

Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan:
> GC3000 resolve-in-place assumes that the TS state is configured.
> If it is not, this will result in MMU errors. This is especially
> apparent when using glGenMipmaps().
> 
> Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
> 
> > Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
>  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
>  4 files changed, 11 insertions(+)
> 
> Ooops. This seems like an obvious oversight but I hadn't thought we would get
> into this path at all when there is no TS to "flush".

And that's probably what we should fix. The self-resolve cases on
resource flush and sampler update don't check the TS status, but they
are only useful if there is a valid TS.

With the change you did here we are still wasting bandwidth for a no-op 
blit on older cores like GC880 when generating mipmaps.

Regards,
Lucas
 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index c62287b..8fc7cfc 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -555,6 +555,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> }
>  
> /* Set up color TS to source surface before blit, if needed */
> +   bool source_ts_valid = false;
> if (src->levels[blit_info->src.level].ts_size &&
> src->levels[blit_info->src.level].ts_valid) {
>    struct etna_reloc reloc;
> @@ -579,6 +580,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
>  
>    etna_set_state(ctx->stream, VIVS_TS_COLOR_CLEAR_VALUE,
>   src->levels[blit_info->src.level].clear_value);
> +
> +  source_ts_valid = true;
> } else {
>    etna_set_state(ctx->stream, VIVS_TS_MEM_CONFIG, ts_mem_config);
> }
> @@ -593,6 +596,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>    .source_stride = src_lev->stride,
>    .source_padded_width = src_lev->padded_width,
>    .source_padded_height = src_lev->padded_height,
> +  .source_ts_valid = source_ts_valid,
>    .dest_format = translate_rs_format(dst_format),
>    .dest_tiling = dst->layout,
>    .dest = dst->bo,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index 707b1e7..5397aa3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -171,6 +171,10 @@ etna_submit_rs_state(struct etna_context *ctx,
> struct etna_cmd_stream *stream = ctx->stream;
> struct etna_coalesce coalesce;
>  
> +   if (cs->RS_KICKER_INPLACE && !cs->source_ts_valid)
> +  /* Inplace resolve is no-op if TS is not configured */
> +  return;
> +
> ctx->stats.rs_operations++;
>  
> if (cs->RS_KICKER_INPLACE) {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index c9072c2..60c2c39 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -133,6 +133,7 @@ etna_compile_rs_state(struct etna_context *ctx, struct 
> compiled_rs_state *cs,
>    /* Total number of tiles (same as for autodisable) */
>    cs->RS_KICKER_INPLACE = rs->source_padded_width * 
> rs->source_padded_height / 16;
> }
> +   cs->source_ts_valid = rs->source_ts_valid;
>  }
>  
>  void
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> index 171d3fa..41a5960 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> @@ -33,6 +33,7 @@
>  struct rs_state {
> uint8_t downsample_x : 1; /* Downsample in x direction */
> uint8_t downsample_y : 1; /* Downsample in y direction */
> +   uint8_t source_ts_valid : 1;
>  
> uint8_t source_format; /* RS_FORMAT_XXX */
> uint8_t source_tiling; /* ETNA_LAYOUT_XXX */
> @@ -61,6 +62,7 @@ struct rs_state {
>  
>  /* treat this as opaque structure */
>  struct compiled_rs_state {
> +   uint8_t source_ts_valid : 1;
> uint32_t RS_CONFIG;
> uint32_t RS_SOURCE_STRIDE;
> uint32_t RS_DEST_STRIDE;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/19] etnaviv: Use only DRAW_INSTANCED on GC3000+

[Philipp Zabel]

On Mon, 2017-10-30 at 17:16 +0100, Wladimir J. van der Laan wrote:
> The blob does this, as DRAW_INSTANCED can replace fully all the other
> draw commands - the other path is only there for compatibility and
> will go away (or at least rot to become buggy due to dis-use) in newer
> hardware.
> 
> Preparation for GC7000 support.

This also changes behaviour for <= GC2000 in the indexed case, should
this be mentioned in the commit message?

> Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_context.c | 16 
>  src/gallium/drivers/etnaviv/etnaviv_emit.h| 21 +
>  2 files changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> b/src/gallium/drivers/etnaviv/etnaviv_context.c
> index 65c20d2..5aa9c66 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> @@ -188,6 +188,8 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> pipe_draw_info *info)
>   BUG("Index buffer upload failed.");
>   return;
>}
> +  /* Add start to index offset, when rendering indexed */
> +  index_offset += info->start * info->index_size;
>  
>ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> etna_resource(indexbuf)->bo;
>ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;

So adding the start offset here makes up for always emitting a zero
start offset with DRAW_INDEXED_PRIMITIVES below.

> @@ -273,10 +275,16 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> pipe_draw_info *info)
> /* First, sync state, then emit DRAW_PRIMITIVES or 
> DRAW_INDEXED_PRIMITIVES */
> etna_emit_state(ctx);
>  
> -   if (info->index_size)
> -  etna_draw_indexed_primitives(ctx->stream, draw_mode, info->start, 
> prims, info->index_bias);
> -   else
> -  etna_draw_primitives(ctx->stream, draw_mode, info->start, prims);
> +   if (ctx->specs.halti >= 2) {
> +  /* On HALTI2+ (GC3000 and higher) only use instanced drawing commands, 
> as the blob does */
> +  etna_draw_instanced(ctx->stream, info->index_size, draw_mode, 1,
> + info->count, info->index_size ? info->index_bias : info->start);
> +   } else {
> +  if (info->index_size)
> + etna_draw_indexed_primitives(ctx->stream, draw_mode, 0, prims, 
> info->index_bias);

Since this is the only place where etna_draw_indexed_primitives is
called, should the unused start parameter be removed from this
function?

> +  else
> + etna_draw_primitives(ctx->stream, draw_mode, info->start, prims);
> +   }
>  
> if (DBG_ENABLED(ETNA_DBG_DRAW_STALL)) {
>/* Stall the FE after every draw operation.  This allows better
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.h 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.h
> index e0c0eda..3c3d129 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.h
> @@ -117,6 +117,27 @@ etna_draw_indexed_primitives(struct etna_cmd_stream 
> *stream,
> etna_cmd_stream_emit(stream, 0);
>  }
>  
> +/* important: this takes a vertex count, not a primitive count */
> +static inline void
> +etna_draw_instanced(struct etna_cmd_stream *stream,
> +uint32_t indexed, uint32_t primitive_type,
> +uint32_t instance_count,
> +uint32_t vertex_count, uint32_t offset)
> +{
> +   etna_cmd_stream_reserve(stream, 3 + 1);
> +   etna_cmd_stream_emit(stream,
> +  VIV_FE_DRAW_INSTANCED_HEADER_OP_DRAW_INSTANCED |
> +  COND(indexed, VIV_FE_DRAW_INSTANCED_HEADER_INDEXED) |
> +  VIV_FE_DRAW_INSTANCED_HEADER_TYPE(primitive_type) |
> +  VIV_FE_DRAW_INSTANCED_HEADER_INSTANCE_COUNT_LO(instance_count & 
> 0x));
> +   etna_cmd_stream_emit(stream,
> +  VIV_FE_DRAW_INSTANCED_COUNT_INSTANCE_COUNT_HI(instance_count >> 16) |
> +  VIV_FE_DRAW_INSTANCED_COUNT_VERTEX_COUNT(vertex_count));
> +   etna_cmd_stream_emit(stream,
> +  VIV_FE_DRAW_INSTANCED_START_INDEX(offset));
> +   etna_cmd_stream_emit(stream, 0);
> +}
> +
>  void
>  etna_emit_state(struct etna_context *ctx);

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 02/19] etnaviv: Const-correctness etnaviv_emit.h

[Philipp Zabel]

On Mon, 2017-10-30 at 17:16 +0100, Wladimir J. van der Laan wrote:
> The relocation structure is never changed by submitting it.
> 
> Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_emit.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.h 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.h
> index 6a3c772..e0c0eda 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.h
> @@ -59,7 +59,7 @@ etna_set_state(struct etna_cmd_stream *stream, uint32_t 
> address, uint32_t value)
>  
>  static inline void
>  etna_set_state_reloc(struct etna_cmd_stream *stream, uint32_t address,
> - struct etna_reloc *reloc)
> + const struct etna_reloc *reloc)
>  {
> etna_cmd_stream_reserve(stream, 2);
> etna_emit_load_state(stream, address >> 2, 1, 0);

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Andres Gomez]

Tapani, this patch landed with the "mesa-sta...@lists.freedesktop.org"
tag without specifying branch.

However, it addresses a fix for 8d90e28839, which didn't land in 17.2
so I'm skipping this patch for that queue.

I hope this is OK with you. Let me know otherwise.

On Fri, 2017-10-27 at 15:55 +0300, Tapani Pälli wrote:
> Patch uses mem_ctx for allocation to ensure param array gets freed
> later, in blorp clear case this happens in blorp_params_get_clear_kernel.
> 
> ==6164== 48 bytes in 1 blocks are definitely lost in loss record 61 of 193
> ==6164==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
> ==6164==by 0x12E31C6C: ralloc_size (ralloc.c:121)
> ==6164==by 0x130189F1: fs_visitor::assign_constant_locations() 
> (brw_fs.cpp:2095)
> ==6164==by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715)
> ==6164==by 0x13024D5A: fs_visitor::run_fs(bool, bool) (brw_fs.cpp:6229)
> ==6164==by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
> ==6164==by 0x130C4B07: blorp_compile_fs (blorp.c:194)
> ==6164==by 0x130D384B: blorp_params_get_clear_kernel (blorp_clear.c:79)
> ==6164==by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
> ==6164==by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261)
> ==6164==by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326)
> ==6164==by 0x12EFF72B: brw_clear (brw_clear.c:297)
> 
> Signed-off-by: Tapani Pälli 
> ---
>  src/intel/compiler/brw_fs.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 4616529abc..6b27c38be7 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
>  */
> uint32_t *param = stage_prog_data->param;
> stage_prog_data->nr_params = num_push_constants;
> -   stage_prog_data->param = ralloc_array(NULL, uint32_t, num_push_constants);
> +   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
> num_push_constants);
> if (num_pull_constants > 0) {
>stage_prog_data->nr_pull_params = num_pull_constants;
>stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
-- 
Br,

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

[Mesa-dev] [PATCH 1/2] st/glsl_to_nir: generate NIR earlier

[Timothy Arceri]

We want to use nir_shader_gather_info() the GLSL IR version might
be including varyings that NIR later eliminates. To do this we
need to generate NIR before we we start using the in/out bitmasks.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp |  6 +
 src/mesa/state_tracker/st_program.c   | 45 ++-
 2 files changed, 14 insertions(+), 37 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index bbef830a2e..d59e472584 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -400,20 +400,21 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
   NIR_PASS_V(nir, nir_lower_samplers_as_deref, shader_program);
else
   NIR_PASS_V(nir, nir_lower_samplers, shader_program);
 }
 
 struct gl_program *
 st_nir_get_mesa_program(struct gl_context *ctx,
 struct gl_shader_program *shader_program,
 struct gl_linked_shader *shader)
 {
+   struct st_context *st = st_context(ctx);
struct gl_program *prog;
 
validate_ir_tree(shader->ir);
 
prog = shader->Program;
 
prog->Parameters = _mesa_new_parameter_list();
 
do_set_program_inouts(shader->ir, prog, shader->Stage);
 
@@ -455,14 +456,19 @@ st_nir_get_mesa_program(struct gl_context *ctx,
   break;
case MESA_SHADER_COMPUTE:
   stcp = (struct st_compute_program *)prog;
   stcp->shader_program = shader_program;
   break;
default:
   assert(!"should not be reached");
   return NULL;
}
 
+   struct st_common_program *st_comm_prog = (struct st_common_program *)prog;
+   nir_shader *nir = st_glsl_to_nir(st, prog, shader_program, shader->Stage);
+   st_comm_prog->tgsi.type = PIPE_SHADER_IR_NIR;
+   st_comm_prog->tgsi.ir.nir = nir;
+
return prog;
 }
 
 } /* extern "C" */
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 25a849bb18..e3649a8b7c 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -440,26 +440,20 @@ st_translate_vertex_program(struct st_context *st,
   ST_NEW_RASTERIZER |
   ST_NEW_VERTEX_ARRAYS;
 
   if (stvp->Base.Parameters->NumParameters)
  stvp->affected_states |= ST_NEW_VS_CONSTANTS;
 
   /* No samplers are allowed in ARB_vp. */
}
 
if (stvp->shader_program) {
-  nir_shader *nir = st_glsl_to_nir(st, &stvp->Base, stvp->shader_program,
-   MESA_SHADER_VERTEX);
-
-  stvp->tgsi.type = PIPE_SHADER_IR_NIR;
-  stvp->tgsi.ir.nir = nir;
-
   struct gl_program *prog = stvp->shader_program->last_vert_prog;
   if (prog) {
  st_translate_stream_output_info2(prog->sh.LinkedTransformFeedback,
   stvp->result_to_output,
   &stvp->tgsi.stream_output);
   }
 
   return true;
}
 
@@ -888,29 +882,23 @@ st_translate_fragment_program(struct st_context *st,
 fs_output_semantic_index[fs_num_outputs] = index;
 outputMapping[attr] = fs_num_outputs;
 break;
  }
  }
 
  fs_num_outputs++;
   }
}
 
-   if (stfp->shader_program) {
-  nir_shader *nir = st_glsl_to_nir(st, &stfp->Base, stfp->shader_program,
-   MESA_SHADER_FRAGMENT);
-
-  stfp->tgsi.type = PIPE_SHADER_IR_NIR;
-  stfp->tgsi.ir.nir = nir;
-
+   /* We have already compiler to NIR so just return */
+   if (stfp->shader_program)
   return true;
-   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_FRAGMENT, st->pipe->screen);
if (ureg == NULL)
   return false;
 
if (ST_DEBUG & DEBUG_MESA) {
   _mesa_print_program(&stfp->Base);
   _mesa_print_program_parameters(st->ctx, &stfp->Base);
   debug_printf("\n");
}
@@ -1674,29 +1662,23 @@ st_get_basic_variant(struct st_context *st,
 
 /**
  * Translate a tessellation control program to create a new variant.
  */
 bool
 st_translate_tessctrl_program(struct st_context *st,
   struct st_common_program *sttcp)
 {
struct ureg_program *ureg;
 
-   if (sttcp->shader_program) {
-  nir_shader *nir = st_glsl_to_nir(st, &sttcp->Base, sttcp->shader_program,
-   MESA_SHADER_TESS_EVAL);
-
-  sttcp->tgsi.type = PIPE_SHADER_IR_NIR;
-  sttcp->tgsi.ir.nir = nir;
-
+   /* We have already compiler to NIR so just return */
+   if (sttcp->shader_program)
   return true;
-   }
 
ureg = ureg_create_with_screen(PIPE_SHADER_TESS_CTRL, st->pipe->screen);
if (ureg == NULL)
   return false;
 
ureg_property(ureg, TGSI_PROPERTY_TCS_VERTICES_OUT,
  sttcp->Base.info.tess.tcs_vertices_out);
 
st_translate_program_common(st, &sttcp->Base, sttcp->glsl_to_tgsi, ureg,

[Mesa-dev] [PATCH 2/2] st/glsl_to_nir: use nir_shader_gather_info()

[Timothy Arceri]

Use the NIR helper rather than the GLSL IR helper to get in/out
masks. This allows us to ignore varyings removed by NIR
optimisations.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index d59e472584..7f4651a3cc 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -266,30 +266,26 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
 * This should be enough for Bitmap and DrawPixels constants.
 */
_mesa_reserve_parameter_storage(prog->Parameters, 8);
 
/* This has to be done last.  Any operation the can cause
 * prog->ParameterValues to get reallocated (e.g., anything that adds a
 * program constant) has to happen before creating this linkage.
 */
_mesa_associate_uniform_storage(st->ctx, shader_program, prog, true);
 
-   st_set_prog_affected_state_flags(prog);
-
NIR_PASS_V(nir, nir_lower_io_to_temporaries,
  nir_shader_get_entrypoint(nir),
  true, true);
NIR_PASS_V(nir, nir_lower_global_vars_to_local);
NIR_PASS_V(nir, nir_split_var_copies);
NIR_PASS_V(nir, nir_lower_var_copies);
-   NIR_PASS_V(nir, st_nir_lower_builtin);
-   NIR_PASS_V(nir, nir_lower_atomics, shader_program);
 
/* fragment shaders may need : */
if (stage == MESA_SHADER_FRAGMENT) {
   static const gl_state_index wposTransformState[STATE_LENGTH] = {
  STATE_INTERNAL, STATE_FB_WPOS_Y_TRANSFORM
   };
   nir_lower_wpos_ytransform_options wpos_options = { { 0 } };
   struct pipe_screen *pscreen = st->pipe->screen;
 
   memcpy(wpos_options.state_tokens, wposTransformState,
@@ -302,20 +298,30 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
  pscreen->get_param(pscreen, 
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
   wpos_options.fs_coord_pixel_center_half_integer =
  pscreen->get_param(pscreen, 
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER);
 
   if (nir_lower_wpos_ytransform(nir, &wpos_options)) {
  nir_validate_shader(nir);
  _mesa_add_state_reference(prog->Parameters, wposTransformState);
   }
}
 
+   NIR_PASS_V(nir, nir_lower_system_values);
+
+   nir_shader_gather_info(nir, nir_shader_get_entrypoint(nir));
+   prog->info = nir->info;
+
+   st_set_prog_affected_state_flags(prog);
+
+   NIR_PASS_V(nir, st_nir_lower_builtin);
+   NIR_PASS_V(nir, nir_lower_atomics, shader_program);
+
if (st->ctx->_Shader->Flags & GLSL_DUMP) {
   _mesa_log("\n");
   _mesa_log("NIR IR for linked %s program %d:\n",
  _mesa_shader_stage_to_string(stage),
  shader_program->Name);
   nir_print_shader(nir, _mesa_get_log_file());
   _mesa_log("\n\n");
}
 
prog->nir = nir;
@@ -387,44 +393,40 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
} else {
   unreachable("invalid shader type for tgsi bypass\n");
}
 
NIR_PASS_V(nir, nir_lower_atomics_to_ssbo,
  st->ctx->Const.Program[nir->info.stage].MaxAtomicBuffers);
 
st_nir_assign_uniform_locations(prog, shader_program,
&nir->uniforms, &nir->num_uniforms);
 
-   NIR_PASS_V(nir, nir_lower_system_values);
-
if (screen->get_param(screen, PIPE_CAP_NIR_SAMPLERS_AS_DEREF))
   NIR_PASS_V(nir, nir_lower_samplers_as_deref, shader_program);
else
   NIR_PASS_V(nir, nir_lower_samplers, shader_program);
 }
 
 struct gl_program *
 st_nir_get_mesa_program(struct gl_context *ctx,
 struct gl_shader_program *shader_program,
 struct gl_linked_shader *shader)
 {
struct st_context *st = st_context(ctx);
struct gl_program *prog;
 
validate_ir_tree(shader->ir);
 
prog = shader->Program;
 
prog->Parameters = _mesa_new_parameter_list();
 
-   do_set_program_inouts(shader->ir, prog, shader->Stage);
-
_mesa_copy_linked_program_data(shader_program, shader);
_mesa_generate_parameters_list_for_uniforms(ctx, shader_program, shader,
prog->Parameters);
 
if (ctx->_Shader->Flags & GLSL_DUMP) {
   _mesa_log("\n");
   _mesa_log("GLSL IR for linked %s program %d:\n",
  _mesa_shader_stage_to_string(shader->Stage),
  shader_program->Name);
   _mesa_print_ir(_mesa_get_log_file(), shader->ir, NULL);
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH v2] meson: implement default driver arguments

[Eric Engestrom]

On Tuesday, 2017-10-31 15:50:49 -0700, Dylan Baker wrote:
> This allows drivers to be set by OS/arch in a sane manner.
> 
> v2: - set _drivers to a list of drivers instead of manually assigning
>   each with_*
> 
> cc: Eric Engestrom 
> Signed-off-by: Dylan Baker 
> ---
>  meson.build   | 18 ++
>  meson_options.txt |  8 
>  2 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index d22d49535af..38c0c77f875 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -90,6 +90,14 @@ with_dri_r200 = false
>  with_dri_nouveau = false
>  with_dri_swrast = false
>  _drivers = get_option('dri-drivers')
> +if _drivers == 'default'
> +  if ['linux', 'bsd'].contains(host_machine.system())
> +if ['x86', 'x86_64'].contains(host_machine.cpu_family())
> +  _drivers = 'i915,i965,r100,r200,nouveau'
> +endif
> +# TODO: PPC, Sparc
> +  endif

I think we need something here to handle the cases where `default` is
the value, but isn't handled by the detection logic.
Something like this at the end of the `_drivers == default` block, for
instance?

if _drivers == 'default'
  error(host_machine.system() + ' ' + host_machine.cpu_family() + ' has no 
default set; you need to set `dri-drivers` manually with `meson configure 
-Ddri-drivers=something`')
endif

(that's a bloody long line, but I don't think meson supports multiline
error)

> +endif
>  if _drivers != ''
>_split = _drivers.split(',')
>with_dri_i915 = _split.contains('i915')
> @@ -112,6 +120,16 @@ with_gallium_vc5 = false
>  with_gallium_etnaviv = false
>  with_gallium_imx = false
>  _drivers = get_option('gallium-drivers')
> +if _drivers == 'default'
> +  if ['linux', 'bsd'].contains(host_machine.system())
> +if ['x86', 'x86_64'].contains(host_machine.cpu_family())
> +  _drivers = 'radeonsi,nouveau,softpipe'
> +elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
> +  _drivers = 'pl111,vc4,vc5,freedreno,etnaviv,imx,softpipe'

`softpipe` is a new addition in this commit; might be worth splitting
out, or at least mention in the commit message.

> +endif
> +# TODO: PPC, Sparc
> +  endif

same `if _drivers still 'default'` error here.

Other than that, this looks good to me. With the errors added and
the addition of softpipe mentioned in the commit msg or split out,
this is:
Reviewed-by: Eric Engestrom 

> +endif
>  if _drivers != ''
>_split = _drivers.split(',')
>with_gallium_pl111 = _split.contains('pl111')
> diff --git a/meson_options.txt b/meson_options.txt
> index d93dd6eab2a..ce46438b5d3 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -34,8 +34,8 @@ option(
>  option(
>'dri-drivers',
>type : 'string',
> -  value : 'i915,i965,r100,r200,nouveau',
> -  description : 'comma separated list of dri drivers to build.'
> +  value : 'default',
> +  description : 'comma separated list of dri drivers to build. If this is 
> set to default all drivers applicable to the target OS/architecture will be 
> built'
>  )
>  option(
>'dri-drivers-path',
> @@ -46,8 +46,8 @@ option(
>  option(
>'gallium-drivers',
>type : 'string',
> -  value : 'pl111,radeonsi,nouveau,freedreno,swrast,vc4,etnaviv,imx',
> -  description : 'comma separated list of gallium drivers to build.'
> +  value : 'default',
> +  description : 'comma separated list of gallium drivers to build. If this 
> is set to default all drivers applicable to the target OS/architecture will 
> be built'
>  )
>  option(
>'gallium-media',
> -- 
> 2.14.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Wladimir J. van der Laan]

On Wed, Nov 01, 2017 at 11:52:55AM +0100, Lucas Stach wrote:
> Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan:
> > GC3000 resolve-in-place assumes that the TS state is configured.
> > If it is not, this will result in MMU errors. This is especially
> > apparent when using glGenMipmaps().
> > 
> > Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
> > 
> > > Signed-off-by: Wladimir J. van der Laan 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
> >  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
> >  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
> >  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
> >  4 files changed, 11 insertions(+)
> > 
> > Ooops. This seems like an obvious oversight but I hadn't thought we would 
> > get
> > into this path at all when there is no TS to "flush".
> 
> And that's probably what we should fix. The self-resolve cases on
> resource flush and sampler update don't check the TS status, but they
> are only useful if there is a valid TS.
> 
> With the change you did here we are still wasting bandwidth for a no-op 
> blit on older cores like GC880 when generating mipmaps.

Yes, just a bugfix (my original commit did not introduce the higher-level
behavior). This particular case should not result in a MMU error. If we fix the
higher level, then this could be replaced with an assertion instead.

On the longer run I'd personally prefer to make "Flush resource level TS" a
separate, explicit operation, for example a method on the context, and not make
it go through the blit path with source==destination. It's a hardware operation
implemented differently on GC3000 and GC7000, that just happens to use the RS
blit on https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/19] etnaviv: Use only DRAW_INSTANCED on GC3000+

[Wladimir J. van der Laan]

On Wed, Nov 01, 2017 at 11:57:39AM +0100, Philipp Zabel wrote:
> On Mon, 2017-10-30 at 17:16 +0100, Wladimir J. van der Laan wrote:
> > The blob does this, as DRAW_INSTANCED can replace fully all the other
> > draw commands - the other path is only there for compatibility and
> > will go away (or at least rot to become buggy due to dis-use) in newer
> > hardware.
> > 
> > Preparation for GC7000 support.
> 
> This also changes behaviour for <= GC2000 in the indexed case, should
> this be mentioned in the commit message?

Yes, it does. I'll add it to the commit message.

I could also keep exactly the same behavior for old hw, but it didn't feel worth
the extra complexity because offsetting INDEX_ADDR does the same thing and we 
update
that state every time before an indexed draw, so as I see it this should not 
result
in more state per draw - correct me if wrong!

> > Signed-off-by: Wladimir J. van der Laan 
> > ---
> >  src/gallium/drivers/etnaviv/etnaviv_context.c | 16 
> >  src/gallium/drivers/etnaviv/etnaviv_emit.h| 21 +
> >  2 files changed, 33 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/etnaviv/etnaviv_context.c 
> > b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > index 65c20d2..5aa9c66 100644
> > --- a/src/gallium/drivers/etnaviv/etnaviv_context.c
> > +++ b/src/gallium/drivers/etnaviv/etnaviv_context.c
> > @@ -188,6 +188,8 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> > pipe_draw_info *info)
> >   BUG("Index buffer upload failed.");
> >   return;
> >}
> > +  /* Add start to index offset, when rendering indexed */
> > +  index_offset += info->start * info->index_size;
> >  
> >ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.bo = 
> > etna_resource(indexbuf)->bo;
> >ctx->index_buffer.FE_INDEX_STREAM_BASE_ADDR.offset = index_offset;
> 
> So adding the start offset here makes up for always emitting a zero
> start offset with DRAW_INDEXED_PRIMITIVES below.

Yes.

> > @@ -273,10 +275,16 @@ etna_draw_vbo(struct pipe_context *pctx, const struct 
> > pipe_draw_info *info)
> > /* First, sync state, then emit DRAW_PRIMITIVES or 
> > DRAW_INDEXED_PRIMITIVES */
> > etna_emit_state(ctx);
> >  
> > -   if (info->index_size)
> > -  etna_draw_indexed_primitives(ctx->stream, draw_mode, info->start, 
> > prims, info->index_bias);
> > -   else
> > -  etna_draw_primitives(ctx->stream, draw_mode, info->start, prims);
> > +   if (ctx->specs.halti >= 2) {
> > +  /* On HALTI2+ (GC3000 and higher) only use instanced drawing 
> > commands, as the blob does */
> > +  etna_draw_instanced(ctx->stream, info->index_size, draw_mode, 1,
> > + info->count, info->index_size ? info->index_bias : info->start);
> > +   } else {
> > +  if (info->index_size)
> > + etna_draw_indexed_primitives(ctx->stream, draw_mode, 0, prims, 
> > info->index_bias);
> 
> Since this is the only place where etna_draw_indexed_primitives is
> called, should the unused start parameter be removed from this
> function?

Sounds good to me.

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

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Lucas Stach]

Am Mittwoch, den 01.11.2017, 12:34 +0100 schrieb Wladimir J. van der Laan:
> On Wed, Nov 01, 2017 at 11:52:55AM +0100, Lucas Stach wrote:
> > Am Mittwoch, den 01.11.2017, 11:17 +0100 schrieb Wladimir J. van der Laan:
> > > GC3000 resolve-in-place assumes that the TS state is configured.
> > > If it is not, this will result in MMU errors. This is especially
> > > apparent when using glGenMipmaps().
> > > 
> > > Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
> > > 
> > > > Signed-off-by: Wladimir J. van der Laan 
> > > 
> > > ---
> > >  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
> > >  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
> > >  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
> > >  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
> > >  4 files changed, 11 insertions(+)
> > > 
> > > Ooops. This seems like an obvious oversight but I hadn't thought we would 
> > > get
> > > into this path at all when there is no TS to "flush".
> > 
> > And that's probably what we should fix. The self-resolve cases on
> > resource flush and sampler update don't check the TS status, but they
> > are only useful if there is a valid TS.
> > 
> > With the change you did here we are still wasting bandwidth for a no-op 
> > blit on older cores like GC880 when generating mipmaps.
> 
> Yes, just a bugfix (my original commit did not introduce the higher-level
> behavior). This particular case should not result in a MMU error. If we fix 
> the
> higher level, then this could be replaced with an assertion instead.
> 
> On the longer run I'd personally prefer to make "Flush resource level TS" a
> separate, explicit operation, for example a method on the context, and not 
> make
> it go through the blit path with source==destination. It's a hardware 
> operation
> implemented differently on GC3000 and GC7000, that just happens to use the RS
> blit on https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Wladimir]

On Wed, Nov 1, 2017 at 11:35 AM, Eric Engestrom
 wrote:
> On Wednesday, 2017-11-01 11:17:53 +0100, Wladimir J. van der Laan wrote:
>> GC3000 resolve-in-place assumes that the TS state is configured.
>> If it is not, this will result in MMU errors. This is especially
>> apparent when using glGenMipmaps().
>>
>> Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
>
> I can't review your patch because I don't know anything about that code,
> but a quick drive-by comment: the format for this information is

Thanks for the heads-up, I didn't know there was a standard format,
will do that next time.

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

Re: [Mesa-dev] [PATCH] gallium: fix typos in README.portability

[Andres Gomez]

This is:

Reviewed-by: Andres Gomez 

I would drop the mesa-stable nomination, though. These are just typos
and not even in the docs/ directory ...

On Mon, 2017-10-30 at 10:55 -0400, Ben Crocker wrote:
> Cc: "17.2" 
> Signed-off-by: Ben Crocker 
> ---
>  src/gallium/README.portability | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/README.portability b/src/gallium/README.portability
> index cf6cc36afb..cdc02bb36d 100644
> --- a/src/gallium/README.portability
> +++ b/src/gallium/README.portability
> @@ -45,7 +45,7 @@ not available in Windows Kernel Mode. Use the appropriate 
> p_*.h include.
>  
>  = Code Style =
>  
> -== Inherantice in C ==
> +== Inheritance in C ==
>  
>  The main thing we do is mimic inheritance by structure containment.
>  
> @@ -58,7 +58,7 @@ struct buffer
>void (*validate)(struct buffer *buf);
>  };
>  
> -/* sub-class of bufffer */
> +/* sub-class of buffer */
>  struct texture_buffer
>  {
>struct buffer base;  /* the base class, MUST COME FIRST! */
> @@ -104,4 +104,4 @@ Note that we typically do not use typedefs to make "class 
> names"; we use
>  'struct whatever' everywhere.
>  
>  Gallium's pipe_context and the subclassed psb_context, etc are prime 
> examples 
> -of this.  There's also many examples in Mesa and the Mesa state tracker.
> +of this.  There are also many examples in Mesa and the Mesa state tracker.
-- 
Br,

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

Re: [Mesa-dev] [PATCH 1/3] meson: Set c visibility args for wayland-drm

[Eric Engestrom]

On Tuesday, 2017-10-31 11:57:33 -0700, Dylan Baker wrote:
> Because otherwise gbm will expose wayland symbols that it shouldn't.
> 
> Signed-off-by: Dylan Baker 

Reviewed-and-Tested-by: Eric Engestrom 

> ---
>  src/egl/wayland/wayland-drm/meson.build | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/egl/wayland/wayland-drm/meson.build 
> b/src/egl/wayland/wayland-drm/meson.build
> index 12b49ca4f06..196feb4fff9 100644
> --- a/src/egl/wayland/wayland-drm/meson.build
> +++ b/src/egl/wayland/wayland-drm/meson.build
> @@ -42,6 +42,7 @@ wayland_drm_server_protocol_h = custom_target(
>  libwayland_drm = static_library(
>'wayland_drm',
>['wayland-drm.c', wayland_drm_protocol_c, wayland_drm_server_protocol_h],
> +  c_args : c_vis_args,
>dependencies : [dep_wayland_server],
>build_by_default : false,
>  )
> -- 
> 2.14.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] es2api/ABI-check: Add es3.x symbols

[Eric Engestrom]

On Tuesday, 2017-10-31 11:57:34 -0700, Dylan Baker wrote:
> Currently this ABI check only checks for es2.x symbols, but es3.x
> symbols are also exposed. Exposing these symbols is recommended by
> Khronos, and as such the test should accept that as ABI.
> 
> see: https://lists.freedesktop.org/archives/mesa-stable/2016-June/004545.html
> for the discussion about exposing these symbols
> 
> These are added to the top to ease review.
> 
> cc: Ian Romanick 
> Signed-off-by: Dylan Baker 

Tested-by: Eric Engestrom 

> ---
>  src/mapi/es2api/ABI-check | 117 
> ++
>  1 file changed, 117 insertions(+)
> 
> diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
> index 2c2764e7fb9..84e8a130601 100755
> --- a/src/mapi/es2api/ABI-check
> +++ b/src/mapi/es2api/ABI-check
> @@ -15,6 +15,123 @@ fi
>  
>  FUNCS=$(nm -D --defined-only $LIB | grep -o 'T gl.*' | cut -c 3- | while 
> read func; do
>  ( grep -q "^$func$" || echo $func )  < +glActiveShaderProgram
> +glBindImageTexture
> +glBindFragDataLocationEXT
> +glBindProgramPipeline
> +glBindVertexBuffer
> +glBlendBarrier
> +glBlendEquationi
> +glBlendEquationSeparatei
> +glBlendFunci
> +glBlendFuncSeparatei
> +glColorMaski
> +glCopyImageSubData
> +glCreateShaderProgramv
> +glDebugMessageCallback
> +glDebugMessageControl
> +glDebugMessageInsert
> +glDeleteProgramPipelines
> +glDisablei
> +glDispatchCompute
> +glDispatchComputeIndirect
> +glDrawArraysIndirect
> +glDrawElementsBaseVertex
> +glDrawElementsIndirect
> +glDrawElementsInstancedBaseVertex
> +glDrawRangeElementsBaseVertex
> +glEnablei
> +glFramebufferParameteri
> +glFramebufferTexture
> +glGenProgramPipelines
> +glGetBooleani_v
> +glGetDebugMessageLog
> +glGetFramebufferParameteriv
> +glGetGraphicsResetStatus
> +glGetMultisamplefv
> +glGetnUniformfv
> +glGetnUniformiv
> +glGetnUniformuiv
> +glGetObjectLabel
> +glGetObjectPtrLabel
> +glGetPointerv
> +glGetProgramInterfaceiv
> +glGetProgramPipelineInfoLog
> +glGetProgramPipelineiv
> +glGetProgramResourceIndex
> +glGetProgramResourceiv
> +glGetProgramResourceLocation
> +glGetProgramResourceName
> +glGetSamplerParameterIiv
> +glGetSamplerParameterIuiv
> +glGetTexLevelParameterfv
> +glGetTexLevelParameteriv
> +glGetTexParameterIiv
> +glGetTexParameterIivEXT
> +glGetTexParameterIuiv
> +glGetTexParameterIuivEXT
> +glIsEnabledi
> +glIsProgramPipeline
> +glMemoryBarrier
> +glMemoryBarrierByRegion
> +glMinSampleShading
> +glObjectLabel
> +glObjectPtrLabel
> +glPatchParameteri
> +glPopDebugGroup
> +glPrimitiveBoundingBox
> +glProgramUniform1f
> +glProgramUniform1fv
> +glProgramUniform1i
> +glProgramUniform1iv
> +glProgramUniform1ui
> +glProgramUniform1uiv
> +glProgramUniform2f
> +glProgramUniform2fv
> +glProgramUniform2i
> +glProgramUniform2iv
> +glProgramUniform2ui
> +glProgramUniform2uiv
> +glProgramUniform3f
> +glProgramUniform3fv
> +glProgramUniform3i
> +glProgramUniform3iv
> +glProgramUniform3ui
> +glProgramUniform3uiv
> +glProgramUniform4f
> +glProgramUniform4fv
> +glProgramUniform4i
> +glProgramUniform4iv
> +glProgramUniform4ui
> +glProgramUniform4uiv
> +glProgramUniformMatrix2fv
> +glProgramUniformMatrix2x3fv
> +glProgramUniformMatrix2x4fv
> +glProgramUniformMatrix3fv
> +glProgramUniformMatrix3x2fv
> +glProgramUniformMatrix3x4fv
> +glProgramUniformMatrix4fv
> +glProgramUniformMatrix4x2fv
> +glProgramUniformMatrix4x3fv
> +glPushDebugGroup
> +glReadnPixels
> +glSampleMaski
> +glSamplerParameterIiv
> +glSamplerParameterIuiv
> +glTexBuffer
> +glTexBufferRange
> +glTexParameterIiv
> +glTexParameterIivEXT
> +glTexParameterIuiv
> +glTexParameterIuivEXT
> +glTexStorage2DMultisample
> +glTexStorage3DMultisample
> +glUseProgramStages
> +glValidateProgramPipeline
> +glVertexAttribBinding
> +glVertexAttribFormat
> +glVertexAttribIFormat
> +glVertexBindingDivisor
>  glActiveTexture
>  glAttachShader
>  glBeginQuery
> -- 
> 2.14.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] etnaviv: Allow clearing constant buffer using buffer==NULL user_buffer==NULL

[Lucas Stach]

Am Montag, den 30.10.2017, 17:14 +0100 schrieb Wladimir J. van der Laan:
> On Mon, Oct 30, 2017 at 02:21:07PM +0100, Lucas Stach wrote:
> > I would prefer the shorter expression (!cb->buffer && !cb->user_buffer) 
> > here, which seems more consistent with the rest of the codebase.
> 
> Well, I mimiced the style from other assertion in the function which compares
> explicitly with NULL. But ok, I'll update it some time.

If you agree with my suggestion I can also just fix it up while
applying, but I'll leave the decision how you want to handle this up to
you.

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

Re: [Mesa-dev] [PATCH 1/2] configure: loosen --enable-glvnd check to honour egl

[Eric Engestrom]

On Tuesday, 2017-10-31 18:58:09 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Currently we error out when building GLVND w/o GLX.
> 
> That was the original premice before we had EGL. As the commit says,
> that error should be reworked to honour both - do so.
> 
> Reported-by: Lukas Rusak 
> Cc: Lukas Rusak 
> Fixes: ce562f9e3fa ("EGL: Implement the libglvnd interface for EGL (v3)")
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 9aa02f55ded..945241bcb0e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1383,17 +1383,11 @@ AC_ARG_ENABLE([libglvnd],
>  AM_CONDITIONAL(USE_LIBGLVND, test "x$enable_libglvnd" = xyes)
>  
>  if test "x$enable_libglvnd" = xyes ; then
> -dnl XXX: update once we can handle more than libGL/glx.
> -dnl Namely: we should error out if neither of the glvnd enabled libraries
> -dnl are built
>  case "x$enable_glx" in
> -xno)
> -AC_MSG_ERROR([cannot build libglvnd without GLX])
> -;;
>  xxlib | xgallium-xlib )
>  AC_MSG_ERROR([cannot build libgvnd when Xlib-GLX or Gallium-Xlib-GLX 
> is enabled])
>  ;;
> -xdri)
> +*)
>  ;;

`*);;` is a noop and can be dropped

both your patches in this series are
Reviewed-by: Eric Engestrom 

>  esac
>  
> @@ -1403,6 +1397,10 @@ if test "x$enable_libglvnd" = xyes ; then
>  
>  DEFINES="${DEFINES} -DUSE_LIBGLVND=1"
>  DEFAULT_GL_LIB_NAME=GLX_mesa
> +
> +if test "x$enable_glx" = xno -a "x$enable_egl" = xno; then
> +AC_MSG_ERROR([cannot build libglvnd without GLX or EGL])
> +fi
>  fi
>  
>  AC_ARG_WITH([gl-lib-name],
> -- 
> 2.14.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Allow building glvnd with EGL and non-dri based GLX

[Eric Engestrom]

On Tuesday, 2017-10-31 13:57:25 -0700, Dylan Baker wrote:
> Because meson mirrors the auototools logic, it needs the same changes to
> allow building glvnd based EGL without building any GLX.
> 
> Signed-off-by: Dylan Baker 
> ---
> 
> Emil, 
> 
> This implements the same logic that you're implementing for meson: one or both
> of dri based GLX or EGL is required for glvnd, but not xlib* based GLX. Could
> you add this into your series?
> 
>  meson.build | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index d22d49535af..4e4718686ac 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -231,8 +231,12 @@ if with_glx != 'disabled'
>  endif
>  
>  with_glvnd = get_option('glvnd')
> -if with_glvnd and with_glx != 'dri'
> -  message('glvnd requires dri based glx')
> +if with_glvnd
> +  if with_glx == 'xlib' or with_glx == 'gallium-xlib'
> +error('Cannot build glvnd support for GLX that is not DRI based.')
> +  if with_glx == 'disabled' and not with_egl

s/if/elif/

with that fixed:
Reviewed-by: Eric Engestrom 

> +error('glvnd requires DRI based GLX and/or EGL')
> +  endif
>  endif
>  
>  # TODO: toggle for this
> -- 
> 2.14.3
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amdgpu: Add R600_DEBUG flag to reserve VMID per ctx.

[Marek Olšák]

Yeah, it should be called when the winsys is created.

Marek

On Wed, Nov 1, 2017 at 9:49 AM, Christian König
 wrote:
> I'm not 100% sure that patch was correct.
>
> When is amdgpu_ctx_create() called? The VMID is reserved for the whole
> process, not just a context.
>
> Regards,
> Christian.
>
>
> Am 31.10.2017 um 16:57 schrieb Marek Olšák:
>>
>> I addressed the feedback and pushed the patch.
>>
>> Marek
>>
>> On Tue, Oct 31, 2017 at 4:50 PM, Michel Dänzer  wrote:
>>>
>>> On 31/10/17 04:40 PM, Andrey Grodzovsky wrote:

 Signed-off-by: Andrey Grodzovsky 
>>>
>>> [...]
>>>
 diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
 b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
 index 8f43e93..1155492 100644
 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
 +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
 @@ -256,6 +256,14 @@ static struct radeon_winsys_ctx
 *amdgpu_ctx_create(struct radeon_winsys *ws)
 goto error_create;
  }

 +   if (ctx->ws->reserve_vmid) {
 +r = amdgpu_vm_reserve_vmid(ctx->ctx, 0);
 +if (r) {
 + fprintf(stderr, "amdgpu: amdgpu_cs_ctx_create failed.
 (%i)\n", r);
>>>
>>> This should say "amdgpu: amdgpu_vm_reserve_vmid failed. (%i)\n".
>>>
>>>
>>> --
>>> Earthling Michel Dänzer   |   http://www.amd.com
>>> Libre software enthusiast | Mesa and X developer
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] create src/wsi

[Eric Engestrom]

On Friday, 2017-10-20 18:00:13 -0700, Dylan Baker wrote:
> This very short series creates a new src/wsi folder, and moves wayland-drm 
> into
> it. Basically wsi stuff is scattered about, and is needed by multiple 
> components
> within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
> wayland-wsi.
> 
> I think there's more that could be moved into wsi, we could move EGL, GBM, and
> GLX, and vulkan/wsi, for example.

The patches themselves are
Reviewed-by: Eric Engestrom 

(and 1 & 2 should land regardless of the discussion on 3)

I'm a bit weary of the move as well, as it makes history harder to
follow (eg. log and blame) and will likely break some scripts.
No actual objection from me though.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium: increase pipe_sampler_view::target bitfield size for MSVC

[Brian Paul]

MSVC treats enums as being signed.  The 4-bit target field isn't large
enough to correctly store the value 8 (for PIPE_TEXTURE_CUBE_ARRAY).
The bitfield value 0x8 was being interpreted as -8 so matching the
target with PIPE_TEXTURE_CUBE_ARRAY in switch statements, etc. was
failing.

To keep the structure size the same, we reduce the format field from
16 bits to 15.  There don't appear to be any other enum bitfields
which need to be adjusted.

This fixes a number of Piglit cube map array tests.
---
 src/gallium/include/pipe/p_state.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index 10bf678..90dc561 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -34,6 +34,10 @@
  * Basic notes:
  *   1. Want compact representations, so we use bitfields.
  *   2. Put bitfields before other (GLfloat) fields.
+ *   3. enum bitfields need to be at least one bit extra in size so the most
+ *  significant bit is zero.  MSVC treats enums as signed so if the high
+ *  bit is set, the value will be interpreted as a negative number.
+ *  That causes trouble in various places.
  */
 
 
@@ -436,8 +440,8 @@ struct pipe_surface
 struct pipe_sampler_view
 {
struct pipe_reference reference;
-   enum pipe_format format:16;  /**< typed PIPE_FORMAT_x */
-   enum pipe_texture_target target:4; /**< PIPE_TEXTURE_x */
+   enum pipe_format format:15;  /**< typed PIPE_FORMAT_x */
+   enum pipe_texture_target target:5; /**< PIPE_TEXTURE_x */
unsigned swizzle_r:3; /**< PIPE_SWIZZLE_x for red component */
unsigned swizzle_g:3; /**< PIPE_SWIZZLE_x for green component */
unsigned swizzle_b:3; /**< PIPE_SWIZZLE_x for blue component */
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Jason Ekstrand]

On Fri, Oct 27, 2017 at 5:55 AM, Tapani Pälli 
wrote:

> Patch uses mem_ctx for allocation to ensure param array gets freed
> later, in blorp clear case this happens in blorp_params_get_clear_kernel.
>
> ==6164== 48 bytes in 1 blocks are definitely lost in loss record 61 of 193
> ==6164==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
> ==6164==by 0x12E31C6C: ralloc_size (ralloc.c:121)
> ==6164==by 0x130189F1: fs_visitor::assign_constant_locations()
> (brw_fs.cpp:2095)
> ==6164==by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715)
> ==6164==by 0x13024D5A: fs_visitor::run_fs(bool, bool) (brw_fs.cpp:6229)
> ==6164==by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
> ==6164==by 0x130C4B07: blorp_compile_fs (blorp.c:194)
> ==6164==by 0x130D384B: blorp_params_get_clear_kernel (blorp_clear.c:79)
> ==6164==by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
> ==6164==by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261)
> ==6164==by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326)
> ==6164==by 0x12EFF72B: brw_clear (brw_clear.c:297)
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/intel/compiler/brw_fs.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 4616529abc..6b27c38be7 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
>  */
> uint32_t *param = stage_prog_data->param;
> stage_prog_data->nr_params = num_push_constants;
> -   stage_prog_data->param = ralloc_array(NULL, uint32_t,
> num_push_constants);
> +   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
> num_push_constants);
>

Wow, I don't know how I didn't see this pass.  The more correct answer is
that blorp no longer uses push constants, so we can just delete the whole
mess.  I'll send a patch.


> if (num_pull_constants > 0) {
>stage_prog_data->nr_pull_params = num_pull_constants;
>stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
> --
> 2.13.6
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Jason Ekstrand]

On Wed, Nov 1, 2017 at 7:53 AM, Jason Ekstrand  wrote:

> On Fri, Oct 27, 2017 at 5:55 AM, Tapani Pälli 
> wrote:
>
>> Patch uses mem_ctx for allocation to ensure param array gets freed
>> later, in blorp clear case this happens in blorp_params_get_clear_kernel.
>>
>> ==6164== 48 bytes in 1 blocks are definitely lost in loss record 61 of 193
>> ==6164==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
>> ==6164==by 0x12E31C6C: ralloc_size (ralloc.c:121)
>> ==6164==by 0x130189F1: fs_visitor::assign_constant_locations()
>> (brw_fs.cpp:2095)
>> ==6164==by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715)
>> ==6164==by 0x13024D5A: fs_visitor::run_fs(bool, bool)
>> (brw_fs.cpp:6229)
>> ==6164==by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
>> ==6164==by 0x130C4B07: blorp_compile_fs (blorp.c:194)
>> ==6164==by 0x130D384B: blorp_params_get_clear_kernel
>> (blorp_clear.c:79)
>> ==6164==by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
>> ==6164==by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261)
>> ==6164==by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326)
>> ==6164==by 0x12EFF72B: brw_clear (brw_clear.c:297)
>>
>> Signed-off-by: Tapani Pälli 
>> ---
>>  src/intel/compiler/brw_fs.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cp
>> p
>> index 4616529abc..6b27c38be7 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
>>  */
>> uint32_t *param = stage_prog_data->param;
>> stage_prog_data->nr_params = num_push_constants;
>> -   stage_prog_data->param = ralloc_array(NULL, uint32_t,
>> num_push_constants);
>> +   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
>> num_push_constants);
>>
>
> Wow, I don't know how I didn't see this pass.  The more correct answer is
> that blorp no longer uses push constants, so we can just delete the whole
> mess.  I'll send a patch.
>

Gah!  Ignore me.  This is, indeed, correct.


> if (num_pull_constants > 0) {
>>stage_prog_data->nr_pull_params = num_pull_constants;
>>stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
>>
>
We should be doing it here as well.


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

Re: [Mesa-dev] [PATCH 2/2] configure.ac: require xcb* for the omx/va/... when using x11 platform

[Lukas Rusak]

Working as expected. Thanks!
On Tue, Oct 31, 2017 at 12:05 PM Emil Velikov 
wrote:

> From: Emil Velikov 
>
> Targets such as omx and va can work w/o anything X related. Mandate the
> xcb* dependencies only when the X11 platform is selected.
>
> Reported-by: Lukas Rusak 
> Cc: Lukas Rusak 
> Fixes: 63e11ac2b5c ("configure: error out if building VA w/o supported
> platform")
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 945241bcb0e..e3261915285 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2158,7 +2158,9 @@ if test "x$enable_xvmc" = xyes -o \
>  "x$enable_vdpau" = xyes -o \
>  "x$enable_omx_bellagio" = xyes -o \
>  "x$enable_va" = xyes; then
> -PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >= $XCBDRI2_REQUIRED])
> +if echo $platforms | grep -q "x11"; then
> +PKG_CHECK_MODULES([VL], [x11-xcb xcb xcb-dri2 >=
> $XCBDRI2_REQUIRED])
> +fi
>  need_gallium_vl_winsys=yes
>  fi
>  AM_CONDITIONAL(NEED_GALLIUM_VL_WINSYS, test "x$need_gallium_vl_winsys" =
> xyes)
> --
> 2.14.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 31/33] intel: decoder: decouple decoding from memory pointers

[Scott D Phillips]

Lionel Landwerlin  writes:

> On 31/10/17 23:04, Scott D Phillips wrote:
>> Lionel Landwerlin  writes:
>>
>>> On 31/10/17 20:54, Scott D Phillips wrote:
 Lionel Landwerlin  writes:

> We want to introduce a reader interface for accessing memory, so that
> later on we can use different ways of storing the content of the GTT
> address space that don't involve a pointer to a linear buffer.
 I'm kinda sceptical that this is the best way to achieve what you want
 here. It strikes me as code that we'll look at in a year and wonder
 what's going on.

 If I'm understanding, it seems like the essence of what you're going for
 here is in the one place where you're using the sub_struct_reader. Maybe
 instead of plumbing the reader object through everywhere, you can add a
 callback just in gen_print_group for fixing up offsets to pointers, and
 then leave everywhere else assuming contiguous memory blocks as today.
>>> First, thanks for you time reviewing this!
>>>
>>> I should have stated that in patch 33 I introduce a sparse memory object
>>> that isn't contiguous.
>>> It's based on the data structure described here :
>>> https://en.wikipedia.org/wiki/Hash_array_mapped_trie
>>>
>>> The idea is to split the memory into chunks of 4Kb but still make it
>>> look like it's a 64bit address space.
>>> The trie structure allows for reuse of pages at different point in time
>>> without having an actual copy of the whole address space.
>> What I meant was that most dword reads will really be adjacent in a
>> piece of memory and leaving the simple pointer math there is
>> clearer. You will only need to callback for indirection when you're
>> chasing an offset or an address.
>>
>>> Like a couple of pages might have been written by relocations associated
>>> to the first batch buffer, then 10 batches later you override them.
>>> The amount of memory we need to allocate for storing 2 snapshots is just
>>> the modified pages (+ ~12 nodes in the trie but those are less than
>>> 300bytes).
>>> That allows the UI to decode 2 batches at the same time as well as all
>>> the associated memory with a small cost.
>> Really there's no need to manage any memory for the buffers themselves,
>> they're immutably stored in the aub file. If you mmap the entire file
>> then you would just need to have a map of gfx addrs to file addrs that
>> would help direct your decoding.
>>
> Thanks, I'll try that.

Thinking more about it, I remember that intel_aubdump will break up
buffers into 32KiB chunks. So that would cause problems for this idea for
buffers bigger than 32KiB. We could try just not doing that splitting in
aubdump and see if it has any other adverse effects.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Disable L3 cache allocation for external buffers

[Daniel Vetter]

On Tue, Oct 24, 2017 at 05:06:33PM +0100, Chris Wilson wrote:
> Through the use of mocs, we can define the cache usage for any surface
> used by the GPU. In particular, we can request that L3 cache be
> allocated for either a read/write miss so that subsequent reads can be
> fetched from cache rather than memory. A consequence of this is that if
> we allocate a L3/LLC cacheline for a read and the object is changed in
> main memory (e.g. a PCIe write bypassing the CPU) then the next read
> will be serviced from the stale cache and not from the new data in
> memory. This is an issue for external PRIME buffers where we may miss
> the updates entirely if the image is small enough to fit within our
> cache.
> 
> Currently, we have a single bit to mark all external buffers so use that
> to tell us when it is unsafe to use a cache override in mocs and
> fallback to the PTE value instead (which should be set to the correct
> cache level to be coherent amongst all active parties: PRIME, scanout and
> render). This may be refined in future to limit the override to buffers
> outside the control of mesa; as buffers being shared between mesa
> clients should be able to coordinate themselves without resolves.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101691
> Cc: Kenneth Graunke 
> Cc: Jason Ekstrand 
> Cc: Lyude Paul 
> Cc: Timo Aalton 
> Cc: Ben Widawsky 
> Cc: Daniel Vetter 
> ---
>  src/intel/blorp/blorp.c  |  1 +
>  src/intel/blorp/blorp.h  |  1 +
>  src/intel/blorp/blorp_genX_exec.h|  2 +-
>  src/intel/blorp/blorp_priv.h |  1 +
>  src/mesa/drivers/dri/i965/brw_blorp.c|  1 +
>  src/mesa/drivers/dri/i965/brw_state.h|  3 ++-
>  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 16 +++-
>  7 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
> index 7cc6335f2f..459ad66652 100644
> --- a/src/intel/blorp/blorp.c
> +++ b/src/intel/blorp/blorp.c
> @@ -71,6 +71,7 @@ brw_blorp_surface_info_init(struct blorp_context *blorp,
> surf->surf->logical_level0_px.array_len));
>  
> info->enabled = true;
> +   info->external = surf->external;
>  
> if (format == ISL_FORMAT_UNSUPPORTED)
>format = surf->surf->format;
> diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
> index 9716c66302..af056c9d52 100644
> --- a/src/intel/blorp/blorp.h
> +++ b/src/intel/blorp/blorp.h
> @@ -106,6 +106,7 @@ struct blorp_surf
> enum isl_aux_usage aux_usage;
>  
> union isl_color_value clear_color;
> +   bool external;
>  };
>  
>  void
> diff --git a/src/intel/blorp/blorp_genX_exec.h 
> b/src/intel/blorp/blorp_genX_exec.h
> index 5389262098..18715788ff 100644
> --- a/src/intel/blorp/blorp_genX_exec.h
> +++ b/src/intel/blorp/blorp_genX_exec.h
> @@ -1328,7 +1328,7 @@ blorp_emit_surface_states(struct blorp_batch *batch,
>   blorp_emit_surface_state(batch, ¶ms->src,
>surface_maps[BLORP_TEXTURE_BT_INDEX],
>surface_offsets[BLORP_TEXTURE_BT_INDEX],
> -  NULL, false);
> +  NULL, params->src.external);
>}
> }
>  
> diff --git a/src/intel/blorp/blorp_priv.h b/src/intel/blorp/blorp_priv.h
> index c7d5d308da..f841aa7cdc 100644
> --- a/src/intel/blorp/blorp_priv.h
> +++ b/src/intel/blorp/blorp_priv.h
> @@ -47,6 +47,7 @@ enum {
>  struct brw_blorp_surface_info
>  {
> bool enabled;
> +   bool external;
>  
> struct isl_surf surf;
> struct blorp_address addr;
> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
> b/src/mesa/drivers/dri/i965/brw_blorp.c
> index ed4f9870f2..563d13a037 100644
> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
> @@ -160,6 +160,7 @@ blorp_surf_for_miptree(struct brw_context *brw,
>.offset = mt->offset,
>.reloc_flags = is_render_target ? EXEC_OBJECT_WRITE : 0,
> };
> +   surf->external = mt->bo->external;
>  
> surf->aux_usage = aux_usage;
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
> b/src/mesa/drivers/dri/i965/brw_state.h
> index 8db354cf23..01c0cd12cb 100644
> --- a/src/mesa/drivers/dri/i965/brw_state.h
> +++ b/src/mesa/drivers/dri/i965/brw_state.h
> @@ -342,6 +342,7 @@ void gen10_init_atoms(struct brw_context *brw);
>   * may still respect that.
>   */
>  #define GEN7_MOCS_L31
> +#define GEN7_MOCS_PTE   0

I think we want to keep the current bitfield (it obviously works with
uncached scanout buffers), but with a big comment:


diff --git a/src/mesa/drivers/dri/i965/brw_state.h 
b/src/mesa/drivers/dri/i965/brw_state.h
index 8db354cf232d..4e418f5e8ea5 100644
--- a/src/mesa/drivers/dri/i965/brw_state.h
+++ b/src/mesa/drivers/dri/i965/brw_state.h
@@ -342,6 +342,12 @@ void gen10_init_atoms(struct brw_conte

Re: [Mesa-dev] [PATCH 2/3] es2api/ABI-check: Add es3.x symbols

[Michel Dänzer]

On 31/10/17 07:57 PM, Dylan Baker wrote:
> Currently this ABI check only checks for es2.x symbols, but es3.x
> symbols are also exposed. Exposing these symbols is recommended by
> Khronos, and as such the test should accept that as ABI.
> 
> see: https://lists.freedesktop.org/archives/mesa-stable/2016-June/004545.html
> for the discussion about exposing these symbols
> 
> These are added to the top to ease review.
> 
> cc: Ian Romanick 
> Signed-off-by: Dylan Baker 

Tested-by: Michel Dänzer 


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

Re: [Mesa-dev] [PATCH mesa] mapi: fix .so path in ABI-check

[Michel Dänzer]

On 31/10/17 07:50 PM, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom 
> ---
> Didn't find when this was broken, but it looks like the tests had been
> silently ignored by `make check` for a long time...
> ---
>  src/mapi/es1api/ABI-check | 2 +-
>  src/mapi/es2api/ABI-check | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mapi/es1api/ABI-check b/src/mapi/es1api/ABI-check
> index 25970bc41419eac5b544..bd9d0288d60dc7323f46 100755
> --- a/src/mapi/es1api/ABI-check
> +++ b/src/mapi/es1api/ABI-check
> @@ -9,7 +9,7 @@ set -eu
>  # or in extensions that are part of the ES 1.1 extension pack.
>  # (see 
> http://www.khronos.org/registry/gles/specs/1.1/opengles_spec_1_1_extension_pack.pdf)
>  
> -LIB=${1-.libs/libGLESv1_CM.so.1}
> +LIB=${1-es1api/.libs/libGLESv1_CM.so.1}
>  
>  if ! [ -f "$LIB" ]
>  then
> diff --git a/src/mapi/es2api/ABI-check b/src/mapi/es2api/ABI-check
> index 2c2764e7fb94fb9494d2..835882c954a0911719a0 100755
> --- a/src/mapi/es2api/ABI-check
> +++ b/src/mapi/es2api/ABI-check
> @@ -6,7 +6,7 @@ set -eu
>  # GL_EXT_multi_draw_arrays
>  # GL_OES_EGL_image
>  
> -LIB=${1-.libs/libGLESv2.so.2}
> +LIB=${1-es2api/.libs/libGLESv2.so.2}
>  
>  if ! [ -f "$LIB" ]
>  then
> 

Tested with out-of-tree build, but presumably this works in-tree as
well? If so,

Reviewed-and-Tested-by: Michel Dänzer 


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

Re: [Mesa-dev] [PATCH] gallium: increase pipe_sampler_view::target bitfield size for MSVC

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Wed, Nov 1, 2017 at 3:45 PM, Brian Paul  wrote:
> MSVC treats enums as being signed.  The 4-bit target field isn't large
> enough to correctly store the value 8 (for PIPE_TEXTURE_CUBE_ARRAY).
> The bitfield value 0x8 was being interpreted as -8 so matching the
> target with PIPE_TEXTURE_CUBE_ARRAY in switch statements, etc. was
> failing.
>
> To keep the structure size the same, we reduce the format field from
> 16 bits to 15.  There don't appear to be any other enum bitfields
> which need to be adjusted.
>
> This fixes a number of Piglit cube map array tests.
> ---
>  src/gallium/include/pipe/p_state.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/include/pipe/p_state.h 
> b/src/gallium/include/pipe/p_state.h
> index 10bf678..90dc561 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -34,6 +34,10 @@
>   * Basic notes:
>   *   1. Want compact representations, so we use bitfields.
>   *   2. Put bitfields before other (GLfloat) fields.
> + *   3. enum bitfields need to be at least one bit extra in size so the most
> + *  significant bit is zero.  MSVC treats enums as signed so if the high
> + *  bit is set, the value will be interpreted as a negative number.
> + *  That causes trouble in various places.
>   */
>
>
> @@ -436,8 +440,8 @@ struct pipe_surface
>  struct pipe_sampler_view
>  {
> struct pipe_reference reference;
> -   enum pipe_format format:16;  /**< typed PIPE_FORMAT_x */
> -   enum pipe_texture_target target:4; /**< PIPE_TEXTURE_x */
> +   enum pipe_format format:15;  /**< typed PIPE_FORMAT_x */
> +   enum pipe_texture_target target:5; /**< PIPE_TEXTURE_x */
> unsigned swizzle_r:3; /**< PIPE_SWIZZLE_x for red component */
> unsigned swizzle_g:3; /**< PIPE_SWIZZLE_x for green component */
> unsigned swizzle_b:3; /**< PIPE_SWIZZLE_x for blue component */
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 31/33] intel: decoder: decouple decoding from memory pointers

[Lionel Landwerlin]

On 01/11/17 15:09, Scott D Phillips wrote:

Lionel Landwerlin  writes:


On 31/10/17 23:04, Scott D Phillips wrote:

Lionel Landwerlin  writes:


On 31/10/17 20:54, Scott D Phillips wrote:

Lionel Landwerlin  writes:


We want to introduce a reader interface for accessing memory, so that
later on we can use different ways of storing the content of the GTT
address space that don't involve a pointer to a linear buffer.

I'm kinda sceptical that this is the best way to achieve what you want
here. It strikes me as code that we'll look at in a year and wonder
what's going on.

If I'm understanding, it seems like the essence of what you're going for
here is in the one place where you're using the sub_struct_reader. Maybe
instead of plumbing the reader object through everywhere, you can add a
callback just in gen_print_group for fixing up offsets to pointers, and
then leave everywhere else assuming contiguous memory blocks as today.

First, thanks for you time reviewing this!

I should have stated that in patch 33 I introduce a sparse memory object
that isn't contiguous.
It's based on the data structure described here :
https://en.wikipedia.org/wiki/Hash_array_mapped_trie

The idea is to split the memory into chunks of 4Kb but still make it
look like it's a 64bit address space.
The trie structure allows for reuse of pages at different point in time
without having an actual copy of the whole address space.

What I meant was that most dword reads will really be adjacent in a
piece of memory and leaving the simple pointer math there is
clearer. You will only need to callback for indirection when you're
chasing an offset or an address.


Like a couple of pages might have been written by relocations associated
to the first batch buffer, then 10 batches later you override them.
The amount of memory we need to allocate for storing 2 snapshots is just
the modified pages (+ ~12 nodes in the trie but those are less than
300bytes).
That allows the UI to decode 2 batches at the same time as well as all
the associated memory with a small cost.

Really there's no need to manage any memory for the buffers themselves,
they're immutably stored in the aub file. If you mmap the entire file
then you would just need to have a map of gfx addrs to file addrs that
would help direct your decoding.


Thanks, I'll try that.

Thinking more about it, I remember that intel_aubdump will break up
buffers into 32KiB chunks. So that would cause problems for this idea for
buffers bigger than 32KiB. We could try just not doing that splitting in
aubdump and see if it has any other adverse effects.

I gave a try to your approach and it seems to work but I'm still dealing 
with bugs everywhere :(

Still, I like the idea of the trie :)

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

Re: [Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET

[Marek Olšák]

Any reviewers?

BTW I enabled the CAP for vc5.

Marek

On Thu, Oct 26, 2017 at 5:31 PM, Marek Olšák  wrote:
> From: Marek Olšák 
>
> ---
>  src/gallium/docs/source/screen.rst   | 4 
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
>  src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
>  src/gallium/drivers/i915/i915_screen.c   | 1 +
>  src/gallium/drivers/llvmpipe/lp_screen.c | 1 +
>  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 1 +
>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 1 +
>  src/gallium/drivers/r300/r300_screen.c   | 1 +
>  src/gallium/drivers/r600/r600_pipe.c | 1 +
>  src/gallium/drivers/radeonsi/si_pipe.c   | 1 +
>  src/gallium/drivers/softpipe/sp_screen.c | 1 +
>  src/gallium/drivers/svga/svga_screen.c   | 1 +
>  src/gallium/drivers/swr/swr_screen.cpp   | 1 +
>  src/gallium/drivers/vc4/vc4_screen.c | 1 +
>  src/gallium/drivers/virgl/virgl_screen.c | 1 +
>  src/gallium/include/pipe/p_defines.h | 1 +
>  17 files changed, 20 insertions(+)
>
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index bc0db42..6d1b484 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -404,20 +404,24 @@ The integer capabilities:
>for a driver that does not support multiple output streams (i.e.,
>``PIPE_CAP_MAX_VERTEX_STREAMS`` is 1), both query types are identical.
>  * ``PIPE_CAP_MEMOBJ``: Whether operations on memory objects are supported.
>  * ``PIPE_CAP_LOAD_CONSTBUF``: True if the driver supports TGSI_OPCODE_LOAD 
> use
>with constant buffers.
>  * ``PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS``: Any TGSI register can be used as
>an address for indirect register indexing.
>  * ``PIPE_CAP_TILE_RASTER_ORDER``: Whether the driver supports
>GL_MESA_tile_raster_order, using the tile_raster_order_* fields in
>pipe_rasterizer_state.
> +* ``PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET``:
> +  Whether pipe_vertex_buffer::buffer_offset is treated as signed. The u_vbuf
> +  module needs this for optimal performance in workstation applications.
> +
>
>
>  .. _pipe_capf:
>
>  PIPE_CAPF_*
>  
>
>  The floating-point capabilities are:
>
>  * ``PIPE_CAPF_MAX_LINE_WIDTH``: The maximum width of a regular line.
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index 009bc73..e501df4 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -259,20 +259,21 @@ etna_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
> case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
> case PIPE_CAP_POST_DEPTH_COVERAGE:
> case PIPE_CAP_BINDLESS_TEXTURE:
> case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
> case PIPE_CAP_QUERY_SO_OVERFLOW:
> case PIPE_CAP_MEMOBJ:
> case PIPE_CAP_LOAD_CONSTBUF:
> case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
> case PIPE_CAP_TILE_RASTER_ORDER:
> +   case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
>return 0;
>
> /* Stream output. */
> case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
> case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
> case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
> case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
>return 0;
>
> /* Geometry shader output, unsupported. */
> diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
> b/src/gallium/drivers/freedreno/freedreno_screen.c
> index 4efd41f..4758d35 100644
> --- a/src/gallium/drivers/freedreno/freedreno_screen.c
> +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
> @@ -320,20 +320,21 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
> case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
> case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
> case PIPE_CAP_POST_DEPTH_COVERAGE:
> case PIPE_CAP_BINDLESS_TEXTURE:
> case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
> case PIPE_CAP_QUERY_SO_OVERFLOW:
> case PIPE_CAP_MEMOBJ:
> case PIPE_CAP_LOAD_CONSTBUF:
> case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
> case PIPE_CAP_TILE_RASTER_ORDER:
> +   case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
> return 0;
>
> case PIPE_CAP_MAX_VIEWPORTS:
> return 1;
>
> case PIPE_CAP_SHAREABLE_SHADERS:
> case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
> /* manage the variants for these ourself, to avoid breaking 
> precompile: */
> case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
> case PIPE_CAP_VERTEX_COLOR_CLAMPED:
> diff --git a/src/gallium/drivers/i915/i915_screen.c 
> b/src/gallium/drivers/i915/i915_screen.c
> index 8b9574e..f8e47f5 100644
> --- a/src/gallium/drivers/i915/i

[Mesa-dev] [PATCH 1/2] intel/fs: Alloc pull constants off mem_ctx

[Jason Ekstrand]

It doesn't actually matter since the only user of push constants, i965,
ralloc_steals it back to NULL but it's more consistent and probably
fixes memory leaks in some error cases.
---
 src/intel/compiler/brw_fs.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index e546792..21ff030 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2095,7 +2095,7 @@ fs_visitor::assign_constant_locations()
stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
num_push_constants);
if (num_pull_constants > 0) {
   stage_prog_data->nr_pull_params = num_pull_constants;
-  stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
+  stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
  num_pull_constants);
}
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 2/2] intel/fs: Don't allocate a param array for zero push constants

[Jason Ekstrand]

Thanks to the ralloc invariant of "any pointer returned from ralloc can
be used as a context", calling ralloc_size with a size of zero will
cause it to allocate at least a header.  If we don't have any push
constants, then NULL is perfectly acceptable (and even preferred).
---
 src/intel/compiler/brw_fs.cpp | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 21ff030..685f9f3 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2092,7 +2092,14 @@ fs_visitor::assign_constant_locations()
 */
uint32_t *param = stage_prog_data->param;
stage_prog_data->nr_params = num_push_constants;
-   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
num_push_constants);
+   if (num_push_constants) {
+  stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
+num_push_constants);
+   } else {
+  stage_prog_data->param = NULL;
+   }
+   assert(stage_prog_data->nr_pull_params == 0);
+   assert(stage_prog_data->pull_param == NULL);
if (num_pull_constants > 0) {
   stage_prog_data->nr_pull_params = num_pull_constants;
   stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
-- 
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 1/2] intel/fs: Alloc pull constants off mem_ctx

[Lionel Landwerlin]

Both patches are :

Reviewed-by: Lionel Landwerlin 

On 01/11/17 16:00, Jason Ekstrand wrote:

It doesn't actually matter since the only user of push constants, i965,
ralloc_steals it back to NULL but it's more consistent and probably
fixes memory leaks in some error cases.
---
  src/intel/compiler/brw_fs.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index e546792..21ff030 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2095,7 +2095,7 @@ fs_visitor::assign_constant_locations()
 stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
num_push_constants);
 if (num_pull_constants > 0) {
stage_prog_data->nr_pull_params = num_pull_constants;
-  stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
+  stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
   num_pull_constants);
 }
  



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

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Tapani Pälli]

On 11/01/2017 12:59 PM, Andres Gomez wrote:

Tapani, this patch landed with the "mesa-sta...@lists.freedesktop.org"
tag without specifying branch.

However, it addresses a fix for 8d90e28839, which didn't land in 17.2
so I'm skipping this patch for that queue.

I hope this is OK with you. Let me know otherwise.


Yes, that is fine. I threw the stable tag in last minute 'just in case'.


On Fri, 2017-10-27 at 15:55 +0300, Tapani Pälli wrote:

Patch uses mem_ctx for allocation to ensure param array gets freed
later, in blorp clear case this happens in blorp_params_get_clear_kernel.

==6164== 48 bytes in 1 blocks are definitely lost in loss record 61 of 193
==6164==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==6164==by 0x12E31C6C: ralloc_size (ralloc.c:121)
==6164==by 0x130189F1: fs_visitor::assign_constant_locations() 
(brw_fs.cpp:2095)
==6164==by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715)
==6164==by 0x13024D5A: fs_visitor::run_fs(bool, bool) (brw_fs.cpp:6229)
==6164==by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
==6164==by 0x130C4B07: blorp_compile_fs (blorp.c:194)
==6164==by 0x130D384B: blorp_params_get_clear_kernel (blorp_clear.c:79)
==6164==by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
==6164==by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261)
==6164==by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326)
==6164==by 0x12EFF72B: brw_clear (brw_clear.c:297)

Signed-off-by: Tapani Pälli 
---
  src/intel/compiler/brw_fs.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 4616529abc..6b27c38be7 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
  */
 uint32_t *param = stage_prog_data->param;
 stage_prog_data->nr_params = num_push_constants;
-   stage_prog_data->param = ralloc_array(NULL, uint32_t, num_push_constants);
+   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
num_push_constants);
 if (num_pull_constants > 0) {
stage_prog_data->nr_pull_params = num_pull_constants;
stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,

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

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Tapani Pälli]

On 11/01/2017 04:55 PM, Jason Ekstrand wrote:
On Wed, Nov 1, 2017 at 7:53 AM, Jason Ekstrand > wrote:


On Fri, Oct 27, 2017 at 5:55 AM, Tapani Pälli
mailto:tapani.pa...@intel.com>> wrote:

Patch uses mem_ctx for allocation to ensure param array gets freed
later, in blorp clear case this happens in
blorp_params_get_clear_kernel.

==6164== 48 bytes in 1 blocks are definitely lost in loss record
61 of 193
==6164==    at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
==6164==    by 0x12E31C6C: ralloc_size (ralloc.c:121)
==6164==    by 0x130189F1:
fs_visitor::assign_constant_locations() (brw_fs.cpp:2095)
==6164==    by 0x13022D32: fs_visitor::optimize() (brw_fs.cpp:5715)
==6164==    by 0x13024D5A: fs_visitor::run_fs(bool, bool)
(brw_fs.cpp:6229)
==6164==    by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
==6164==    by 0x130C4B07: blorp_compile_fs (blorp.c:194)
==6164==    by 0x130D384B: blorp_params_get_clear_kernel
(blorp_clear.c:79)
==6164==    by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
==6164==    by 0x12EFA439: do_single_blorp_clear (brw_blorp.c:1261)
==6164==    by 0x12EFC4AF: brw_blorp_clear_color (brw_blorp.c:1326)
==6164==    by 0x12EFF72B: brw_clear (brw_clear.c:297)

Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
  src/intel/compiler/brw_fs.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp
b/src/intel/compiler/brw_fs.cpp
index 4616529abc..6b27c38be7 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
      */
     uint32_t *param = stage_prog_data->param;
     stage_prog_data->nr_params = num_push_constants;
-   stage_prog_data->param = ralloc_array(NULL, uint32_t,
num_push_constants);
+   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
num_push_constants);


Wow, I don't know how I didn't see this pass.  The more correct
answer is that blorp no longer uses push constants, so we can just
delete the whole mess.  I'll send a patch.


Gah!  Ignore me.  This is, indeed, correct.

     if (num_pull_constants > 0) {
        stage_prog_data->nr_pull_params = num_pull_constants;
        stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,


We should be doing it here as well.



ok, did not catch that as the use case I was running did not use pull 
constants, I can send a separate fix for that one.


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

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Alloc pull constants off mem_ctx

[Tapani Pälli]

series
Reviewed-by: Tapani Pälli 

On 11/01/2017 06:00 PM, Jason Ekstrand wrote:

It doesn't actually matter since the only user of push constants, i965,
ralloc_steals it back to NULL but it's more consistent and probably
fixes memory leaks in some error cases.
---
  src/intel/compiler/brw_fs.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index e546792..21ff030 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2095,7 +2095,7 @@ fs_visitor::assign_constant_locations()
 stage_prog_data->param = ralloc_array(mem_ctx, uint32_t, 
num_push_constants);
 if (num_pull_constants > 0) {
stage_prog_data->nr_pull_params = num_pull_constants;
-  stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
+  stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
   num_pull_constants);
 }
  


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

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Alloc pull constants off mem_ctx

[Jason Ekstrand]

Do either of you mind if I cc the first one to stable?  It does fix a
potential memory leak in the case where compilation fails.

On Wed, Nov 1, 2017 at 9:26 AM, Tapani Pälli  wrote:

> series
> Reviewed-by: Tapani Pälli 
>
>
> On 11/01/2017 06:00 PM, Jason Ekstrand wrote:
>
>> It doesn't actually matter since the only user of push constants, i965,
>> ralloc_steals it back to NULL but it's more consistent and probably
>> fixes memory leaks in some error cases.
>> ---
>>   src/intel/compiler/brw_fs.cpp | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cp
>> p
>> index e546792..21ff030 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -2095,7 +2095,7 @@ fs_visitor::assign_constant_locations()
>>  stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
>> num_push_constants);
>>  if (num_pull_constants > 0) {
>> stage_prog_data->nr_pull_params = num_pull_constants;
>> -  stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
>> +  stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
>>num_pull_constants);
>>  }
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: increase pipe_sampler_view::target bitfield size for MSVC

[Roland Scheidegger]

Oh no msvc enums strike again... (A real pity c doesn't allow to
explicitly make enums signed or unsigned.)
We use bitfields for compact representation, so if we need an extra bit
that seems a bit counterintuitive (even if it dosen't increase the
overall size here). Also, I believe the 16 bits for format were chosen
for slightly more efficient code.
Worse though, needing one bit more than everybody thinks is necessary
looks error-prone to me (albeit in this case it seems very unlikely the
enum gets more values).
But I guess the alternative would be to just use unsigned:4 for the
target. Not sure if that would be preferable, there's really no good
solution, but in any case

Reviewed-by: Roland Scheidegger 

Am 01.11.2017 um 15:45 schrieb Brian Paul:
> MSVC treats enums as being signed.  The 4-bit target field isn't large
> enough to correctly store the value 8 (for PIPE_TEXTURE_CUBE_ARRAY).
> The bitfield value 0x8 was being interpreted as -8 so matching the
> target with PIPE_TEXTURE_CUBE_ARRAY in switch statements, etc. was
> failing.
> 
> To keep the structure size the same, we reduce the format field from
> 16 bits to 15.  There don't appear to be any other enum bitfields
> which need to be adjusted.
> 
> This fixes a number of Piglit cube map array tests.
> ---
>  src/gallium/include/pipe/p_state.h | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_state.h 
> b/src/gallium/include/pipe/p_state.h
> index 10bf678..90dc561 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -34,6 +34,10 @@
>   * Basic notes:
>   *   1. Want compact representations, so we use bitfields.
>   *   2. Put bitfields before other (GLfloat) fields.
> + *   3. enum bitfields need to be at least one bit extra in size so the most
> + *  significant bit is zero.  MSVC treats enums as signed so if the high
> + *  bit is set, the value will be interpreted as a negative number.
> + *  That causes trouble in various places.
>   */
>  
>  
> @@ -436,8 +440,8 @@ struct pipe_surface
>  struct pipe_sampler_view
>  {
> struct pipe_reference reference;
> -   enum pipe_format format:16;  /**< typed PIPE_FORMAT_x */
> -   enum pipe_texture_target target:4; /**< PIPE_TEXTURE_x */
> +   enum pipe_format format:15;  /**< typed PIPE_FORMAT_x */
> +   enum pipe_texture_target target:5; /**< PIPE_TEXTURE_x */
> unsigned swizzle_r:3; /**< PIPE_SWIZZLE_x for red component */
> unsigned swizzle_g:3; /**< PIPE_SWIZZLE_x for green component */
> unsigned swizzle_b:3; /**< PIPE_SWIZZLE_x for blue component */
> 

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

Re: [Mesa-dev] [PATCH] i965: fix blorp stage_prog_data->param leak

[Jason Ekstrand]

On Wed, Nov 1, 2017 at 9:24 AM, Tapani Pälli  wrote:

>
>
> On 11/01/2017 04:55 PM, Jason Ekstrand wrote:
>
>> On Wed, Nov 1, 2017 at 7:53 AM, Jason Ekstrand > > wrote:
>>
>> On Fri, Oct 27, 2017 at 5:55 AM, Tapani Pälli
>> mailto:tapani.pa...@intel.com>> wrote:
>>
>> Patch uses mem_ctx for allocation to ensure param array gets freed
>> later, in blorp clear case this happens in
>> blorp_params_get_clear_kernel.
>>
>> ==6164== 48 bytes in 1 blocks are definitely lost in loss record
>> 61 of 193
>> ==6164==at 0x4C2EB6B: malloc (vg_replace_malloc.c:299)
>> ==6164==by 0x12E31C6C: ralloc_size (ralloc.c:121)
>> ==6164==by 0x130189F1:
>> fs_visitor::assign_constant_locations() (brw_fs.cpp:2095)
>> ==6164==by 0x13022D32: fs_visitor::optimize()
>> (brw_fs.cpp:5715)
>> ==6164==by 0x13024D5A: fs_visitor::run_fs(bool, bool)
>> (brw_fs.cpp:6229)
>> ==6164==by 0x1302549A: brw_compile_fs (brw_fs.cpp:6570)
>> ==6164==by 0x130C4B07: blorp_compile_fs (blorp.c:194)
>> ==6164==by 0x130D384B: blorp_params_get_clear_kernel
>> (blorp_clear.c:79)
>> ==6164==by 0x130D3C56: blorp_fast_clear (blorp_clear.c:332)
>> ==6164==by 0x12EFA439: do_single_blorp_clear
>> (brw_blorp.c:1261)
>> ==6164==by 0x12EFC4AF: brw_blorp_clear_color
>> (brw_blorp.c:1326)
>> ==6164==by 0x12EFF72B: brw_clear (brw_clear.c:297)
>>
>> Signed-off-by: Tapani Pälli > >
>> ---
>>   src/intel/compiler/brw_fs.cpp | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs.cpp
>> b/src/intel/compiler/brw_fs.cpp
>> index 4616529abc..6b27c38be7 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -2092,7 +2092,7 @@ fs_visitor::assign_constant_locations()
>>   */
>>  uint32_t *param = stage_prog_data->param;
>>  stage_prog_data->nr_params = num_push_constants;
>> -   stage_prog_data->param = ralloc_array(NULL, uint32_t,
>> num_push_constants);
>> +   stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
>> num_push_constants);
>>
>>
>> Wow, I don't know how I didn't see this pass.  The more correct
>> answer is that blorp no longer uses push constants, so we can just
>> delete the whole mess.  I'll send a patch.
>>
>>
>> Gah!  Ignore me.  This is, indeed, correct.
>>
>>  if (num_pull_constants > 0) {
>> stage_prog_data->nr_pull_params = num_pull_constants;
>> stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
>>
>>
>> We should be doing it here as well.
>>
>>
> ok, did not catch that as the use case I was running did not use pull
> constants, I can send a separate fix for that one.


As I said in the commit message of the patch I sent, it *almost* doesn't
matter in practice.  It only matters if shader compilation somehow fails
which is not a common case.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 33/33] intel: add aubinator ui

[Lionel Landwerlin]

On 31/10/17 21:11, Scott D Phillips wrote:

+}

[snip imgui]

imgui seems to be the first instance of someone pasting a sizeable third
party library into the repo.  I'm not sure how everyone feels about
that. Unfortunately it seems like imgui isn't packaged by any distros
that I can see either.

Maybe we could do some meson wrap magic or something to pull it in
without having to commit the code.

Copying seems to be the main way anybody is using it. Are you suggesting 
a submodule?


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

Re: [Mesa-dev] [PATCH] gallium: increase pipe_sampler_view::target bitfield size for MSVC

[Brian Paul]

On 11/01/2017 10:33 AM, Roland Scheidegger wrote:

Oh no msvc enums strike again... (A real pity c doesn't allow to
explicitly make enums signed or unsigned.)


There's a proposal for that feature for a future std C version.


We use bitfields for compact representation, so if we need an extra bit
that seems a bit counterintuitive (even if it dosen't increase the
overall size here). Also, I believe the 16 bits for format were chosen
for slightly more efficient code.
Worse though, needing one bit more than everybody thinks is necessary
looks error-prone to me (albeit in this case it seems very unlikely the
enum gets more values).


I'll certainly be on the lookout for this issue in the future.


But I guess the alternative would be to just use unsigned:4 for the
target. Not sure if that would be preferable, there's really no good
solution, but in any case

Reviewed-by: Roland Scheidegger 


Thanks.

-Brian



Am 01.11.2017 um 15:45 schrieb Brian Paul:

MSVC treats enums as being signed.  The 4-bit target field isn't large
enough to correctly store the value 8 (for PIPE_TEXTURE_CUBE_ARRAY).
The bitfield value 0x8 was being interpreted as -8 so matching the
target with PIPE_TEXTURE_CUBE_ARRAY in switch statements, etc. was
failing.

To keep the structure size the same, we reduce the format field from
16 bits to 15.  There don't appear to be any other enum bitfields
which need to be adjusted.

This fixes a number of Piglit cube map array tests.
---
  src/gallium/include/pipe/p_state.h | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index 10bf678..90dc561 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -34,6 +34,10 @@
   * Basic notes:
   *   1. Want compact representations, so we use bitfields.
   *   2. Put bitfields before other (GLfloat) fields.
+ *   3. enum bitfields need to be at least one bit extra in size so the most
+ *  significant bit is zero.  MSVC treats enums as signed so if the high
+ *  bit is set, the value will be interpreted as a negative number.
+ *  That causes trouble in various places.
   */


@@ -436,8 +440,8 @@ struct pipe_surface
  struct pipe_sampler_view
  {
 struct pipe_reference reference;
-   enum pipe_format format:16;  /**< typed PIPE_FORMAT_x */
-   enum pipe_texture_target target:4; /**< PIPE_TEXTURE_x */
+   enum pipe_format format:15;  /**< typed PIPE_FORMAT_x */
+   enum pipe_texture_target target:5; /**< PIPE_TEXTURE_x */
 unsigned swizzle_r:3; /**< PIPE_SWIZZLE_x for red component */
 unsigned swizzle_g:3; /**< PIPE_SWIZZLE_x for green component */
 unsigned swizzle_b:3; /**< PIPE_SWIZZLE_x for blue component */





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

[Mesa-dev] [PATCH 2/2] etnaviv: ASTC texture support

[Wladimir J. van der Laan]

Add ASTC texture support for hardware that supports this
(currently only GC3000 on i.MX6qp is known to have this).

Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_emit.c |  8 +++
 src/gallium/drivers/etnaviv/etnaviv_format.c   | 30 ++
 src/gallium/drivers/etnaviv/etnaviv_format.h   |  1 +
 src/gallium/drivers/etnaviv/etnaviv_internal.h |  2 ++
 src/gallium/drivers/etnaviv/etnaviv_screen.c   |  6 ++
 src/gallium/drivers/etnaviv/etnaviv_texture.c  | 11 --
 src/gallium/drivers/etnaviv/etnaviv_texture.h  |  1 +
 7 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
b/src/gallium/drivers/etnaviv/etnaviv_emit.c
index 5397aa3..d313af6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
@@ -703,6 +703,14 @@ etna_emit_state(struct etna_context *ctx)
  /*03828*/ EMIT_STATE(GL_VARYING_COMPONENT_USE(x), 
ctx->shader_state.GL_VARYING_COMPONENT_USE[x]);
   }
}
+   if (unlikely(ctx->specs.tex_astc && (dirty & (ETNA_DIRTY_SAMPLER_VIEWS {
+  for (int x = 0; x < VIVS_TE_SAMPLER__LEN; ++x) {
+ if ((1 << x) & active_samplers) {
+struct etna_sampler_view *sv = 
etna_sampler_view(ctx->sampler_view[x]);
+/*10500*/ EMIT_STATE(NTE_SAMPLER_ASTC0(x), sv->TE_SAMPLER_ASTC0);
+ }
+  }
+   }
etna_coalesce_end(stream, &coalesce);
/* end only EMIT_STATE */
 
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
b/src/gallium/drivers/etnaviv/etnaviv_format.c
index 987f6a8..3dd212f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
@@ -246,6 +246,36 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
_T(ETC2_RG11_UNORM, EXT_RG11_EAC | EXT_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
_T(ETC2_RG11_SNORM, EXT_SIGNED_RG11_EAC | EXT_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
 
+   _T(ASTC_4x4,ASTC_RGBA_4x4 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_5x4,ASTC_RGBA_5x4 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_5x5,ASTC_RGBA_5x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_6x5,ASTC_RGBA_6x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_6x6,ASTC_RGBA_6x6 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x5,ASTC_RGBA_8x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x6,ASTC_RGBA_8x6 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x8,ASTC_RGBA_8x8 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x5,   ASTC_RGBA_10x5 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x6,   ASTC_RGBA_10x6 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x8,   ASTC_RGBA_10x8 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x10,  ASTC_RGBA_10x10 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_12x10,  ASTC_RGBA_12x10 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_12x12,  ASTC_RGBA_12x12 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+
+   _T(ASTC_4x4_SRGB,   ASTC_SRGB8_ALPHA8_4x4 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_5x4_SRGB,   ASTC_SRGB8_ALPHA8_5x4 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_5x5_SRGB,   ASTC_SRGB8_ALPHA8_5x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_6x5_SRGB,   ASTC_SRGB8_ALPHA8_6x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_6x6_SRGB,   ASTC_SRGB8_ALPHA8_6x6 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x5_SRGB,   ASTC_SRGB8_ALPHA8_8x5 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x6_SRGB,   ASTC_SRGB8_ALPHA8_8x6 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_8x8_SRGB,   ASTC_SRGB8_ALPHA8_8x8 | ASTC_FORMAT,SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x5_SRGB,  ASTC_SRGB8_ALPHA8_10x5 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x6_SRGB,  ASTC_SRGB8_ALPHA8_10x6 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x8_SRGB,  ASTC_SRGB8_ALPHA8_10x8 | ASTC_FORMAT,   SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_10x10_SRGB, ASTC_SRGB8_ALPHA8_10x10 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_12x10_SRGB, ASTC_SRGB8_ALPHA8_12x10 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+   _T(ASTC_12x12_SRGB, ASTC_SRGB8_ALPHA8_12x12 | ASTC_FORMAT,  SWIZ(X, 
Y, Z, W), NONE),
+
/* YUV */
_T(YUYV, YUY2, SWIZ(X, Y, Z, W), YUY2),
_T(UYVY, UYVY, SWIZ(X, Y, Z, W), NONE),
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.h 
b/src/gallium/drivers/etnaviv/etnaviv_format.h
index 543e309..1672d6

[Mesa-dev] [PATCH 0/2] etnaviv: ASTC texture support

[Wladimir J. van der Laan]

Add ASTC texture support for hardware that supports this
(currently only GC3000 on i.MX6qp is known to have this).

Piglit output:

$ bin/khr_compressed_astc-miptree_gles2
PIGLIT: {"subtest": {"LDR Profile" : "pass"}}
PIGLIT: {"subtest": {"HDR Profile" : "pass"}}
PIGLIT: {"subtest": {"sRGB decode" : "pass"}}
Probe at (144,44)
Expected: 0.972549 0.972549 0.972549 1.00
Observed: 0.984314 0.984314 0.984314 1.00
piglit: error: Miplevel 0
piglit: error: Mode ldrs Block 4x4.
PIGLIT: {"subtest": {"sRGB decode full precision" : "fail"}}
PIGLIT: {"subtest": {"sRGB skip decode" : "pass"}}

This means all block sizes are working, and basic RGB/sRGB.

Not sure why "sRGB decode full precision" is not passing,
probably the hw just doesn't do that.

Wladimir J. van der Laan (2):
  etnaviv: Update from rnndb
  etnaviv: ASTC texture support

 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c |   2 +-
 src/gallium/drivers/etnaviv/etnaviv_emit.c   |   8 +
 src/gallium/drivers/etnaviv/etnaviv_format.c |  39 ++-
 src/gallium/drivers/etnaviv/etnaviv_format.h |   1 +
 src/gallium/drivers/etnaviv/etnaviv_internal.h   |   2 +
 src/gallium/drivers/etnaviv/etnaviv_screen.c |   6 +
 src/gallium/drivers/etnaviv/etnaviv_state.c  |   2 +-
 src/gallium/drivers/etnaviv/etnaviv_texture.c|  11 +-
 src/gallium/drivers/etnaviv/etnaviv_texture.h|   1 +
 src/gallium/drivers/etnaviv/etnaviv_transfer.c   |   2 +
 src/gallium/drivers/etnaviv/etnaviv_translate.h  |  15 +-
 src/gallium/drivers/etnaviv/hw/cmdstream.xml.h   |  20 +-
 src/gallium/drivers/etnaviv/hw/common.xml.h  |  11 +-
 src/gallium/drivers/etnaviv/hw/common_3d.xml.h   | 171 ++
 src/gallium/drivers/etnaviv/hw/isa.xml.h |  15 +-
 src/gallium/drivers/etnaviv/hw/state.xml.h   | 210 +---
 src/gallium/drivers/etnaviv/hw/state_3d.xml.h| 402 ++-
 src/gallium/drivers/etnaviv/hw/state_blt.xml.h   | 282 
 src/gallium/drivers/etnaviv/hw/texdesc_3d.xml.h  | 194 +++
 19 files changed, 1072 insertions(+), 322 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/hw/common_3d.xml.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/state_blt.xml.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/texdesc_3d.xml.h

-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] etnaviv: Update from rnndb

[Wladimir J. van der Laan]

Updated as of etnav_viv commit 3b4a8ec.

Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_clear_blit.c |   2 +-
 src/gallium/drivers/etnaviv/etnaviv_format.c |   9 +-
 src/gallium/drivers/etnaviv/etnaviv_state.c  |   2 +-
 src/gallium/drivers/etnaviv/etnaviv_transfer.c   |   2 +
 src/gallium/drivers/etnaviv/etnaviv_translate.h  |  15 +-
 src/gallium/drivers/etnaviv/hw/cmdstream.xml.h   |  20 +-
 src/gallium/drivers/etnaviv/hw/common.xml.h  |  11 +-
 src/gallium/drivers/etnaviv/hw/common_3d.xml.h   | 171 ++
 src/gallium/drivers/etnaviv/hw/isa.xml.h |  15 +-
 src/gallium/drivers/etnaviv/hw/state.xml.h   | 210 +---
 src/gallium/drivers/etnaviv/hw/state_3d.xml.h| 402 ++-
 src/gallium/drivers/etnaviv/hw/state_blt.xml.h   | 282 
 src/gallium/drivers/etnaviv/hw/texdesc_3d.xml.h  | 194 +++
 13 files changed, 1015 insertions(+), 320 deletions(-)
 create mode 100644 src/gallium/drivers/etnaviv/hw/common_3d.xml.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/state_blt.xml.h
 create mode 100644 src/gallium/drivers/etnaviv/hw/texdesc_3d.xml.h

diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
index 21f50b7..ff37a6b 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
@@ -531,7 +531,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
if (src->base.nr_samples > 1) {
   uint32_t msaa_format = translate_msaa_format(src_format);
   assert(msaa_format != ETNA_NO_MATCH);
-  ts_mem_config |= VIVS_TS_MEM_CONFIG_MSAA | msaa_format;
+  ts_mem_config |= VIVS_TS_MEM_CONFIG_COLOR_COMPRESSION | msaa_format;
}
 
/* Always flush color and depth cache together before resolving. This works
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c 
b/src/gallium/drivers/etnaviv/etnaviv_format.c
index ac9b2d1..987f6a8 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
@@ -26,6 +26,7 @@
 
 #include "etnaviv_format.h"
 
+#include "hw/common_3d.xml.h"
 #include "hw/state.xml.h"
 #include "hw/state_3d.xml.h"
 
@@ -62,7 +63,7 @@ struct etna_format {
 /* vertex + texture */
 #define VT(pipe, vtxfmt, texfmt, texswiz, rsfmt)  \
[PIPE_FORMAT_##pipe] = {   \
-  .vtx = VIVS_FE_VERTEX_ELEMENT_CONFIG_TYPE_##vtxfmt, \
+  .vtx = FE_DATA_TYPE_##vtxfmt, \
   .tex = TEXTURE_FORMAT_##texfmt, \
   .rs = RS_FORMAT_##rsfmt,\
   .present = 1,   \
@@ -82,7 +83,7 @@ struct etna_format {
 /* vertex-only */
 #define V_(pipe, fmt, rsfmt)   \
[PIPE_FORMAT_##pipe] = {\
-  .vtx = VIVS_FE_VERTEX_ELEMENT_CONFIG_TYPE_##fmt, \
+  .vtx = FE_DATA_TYPE_##fmt, \
   .tex = ETNA_NO_MATCH,\
   .rs = RS_FORMAT_##rsfmt, \
   .present = 1,\
@@ -173,8 +174,8 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] = {
V_(R10G10B10A2_USCALED, UNSIGNED_INT_10_10_10_2, NONE),
V_(R10G10B10A2_SSCALED, INT_10_10_10_2,  NONE),
 
-   _T(X8Z24_UNORM,   D24S8, SWIZ(X, Y, Z, W), A8R8G8B8),
-   _T(S8_UINT_Z24_UNORM, D24S8, SWIZ(X, Y, Z, W), A8R8G8B8),
+   _T(X8Z24_UNORM,   D24X8, SWIZ(X, Y, Z, W), A8R8G8B8),
+   _T(S8_UINT_Z24_UNORM, D24X8, SWIZ(X, Y, Z, W), A8R8G8B8),
 
/* 48-bit */
V_(R16G16B16_UNORM,   UNSIGNED_SHORT, NONE),
diff --git a/src/gallium/drivers/etnaviv/etnaviv_state.c 
b/src/gallium/drivers/etnaviv/etnaviv_state.c
index 34bcb19..6e82216 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_state.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_state.c
@@ -177,7 +177,7 @@ etna_set_framebuffer_state(struct pipe_context *pctx,
   /* MSAA */
   if (cbuf->base.texture->nr_samples > 1)
  ts_mem_config |=
-VIVS_TS_MEM_CONFIG_MSAA | translate_msaa_format(cbuf->base.format);
+VIVS_TS_MEM_CONFIG_COLOR_COMPRESSION | 
translate_msaa_format(cbuf->base.format);
 
   nr_samples_color = cbuf->base.texture->nr_samples;
} else {
diff --git a/src/gallium/drivers/etnaviv/etnaviv_transfer.c 
b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
index 08ec198..e402e19 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_transfer.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_transfer.c
@@ -40,6 +40,8 @@
 #include "util/u_surface.h"
 #include "util/u_transfer.h"
 
+#include "hw/common_3d.xml.h"
+
 #include 
 
 /* Compute offset into a 1D/2D/3D buffer of a certain box.
diff --git a/src/gallium/drivers/etnaviv/etnaviv_translate.h 
b/src/gallium/drivers/etnaviv/etnaviv_translate.h
index 0761251..7c85f81 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_translate.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_translate.h
@

Re: [Mesa-dev] [PATCH] meson: Allow building glvnd with EGL and non-dri based GLX

[Dylan Baker]

Quoting Eric Engestrom (2017-11-01 06:36:35)
> On Tuesday, 2017-10-31 13:57:25 -0700, Dylan Baker wrote:
> > Because meson mirrors the auototools logic, it needs the same changes to
> > allow building glvnd based EGL without building any GLX.
> > 
> > Signed-off-by: Dylan Baker 
> > ---
> > 
> > Emil, 
> > 
> > This implements the same logic that you're implementing for meson: one or 
> > both
> > of dri based GLX or EGL is required for glvnd, but not xlib* based GLX. 
> > Could
> > you add this into your series?
> > 
> >  meson.build | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index d22d49535af..4e4718686ac 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -231,8 +231,12 @@ if with_glx != 'disabled'
> >  endif
> >  
> >  with_glvnd = get_option('glvnd')
> > -if with_glvnd and with_glx != 'dri'
> > -  message('glvnd requires dri based glx')
> > +if with_glvnd
> > +  if with_glx == 'xlib' or with_glx == 'gallium-xlib'
> > +error('Cannot build glvnd support for GLX that is not DRI based.')
> > +  if with_glx == 'disabled' and not with_egl
> 
> s/if/elif/
> 
> with that fixed:
> Reviewed-by: Eric Engestrom 

oops!

> 
> > +error('glvnd requires DRI based GLX and/or EGL')
> > +  endif
> >  endif
> >  
> >  # TODO: toggle for this
> > -- 
> > 2.14.3
> > 


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

[Mesa-dev] [PATCH v2] meson: Allow building glvnd with EGL and non-dri based GLX

[Dylan Baker]

Because meson mirrors the auototools logic, it needs the same changes to
allow building glvnd based egl.

v2: - change if to elif (Eric)

Signed-off-by: Dylan Baker 
Reviewed-by: Eric Engestrom 
---
 meson.build | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 6ad8c8bbf4b..47234556bd3 100644
--- a/meson.build
+++ b/meson.build
@@ -231,8 +231,12 @@ if with_glx != 'disabled'
 endif
 
 with_glvnd = get_option('glvnd')
-if with_glvnd and with_glx != 'dri'
-  message('glvnd requires dri based glx')
+if with_glvnd
+  if with_glx == 'xlib' or with_glx == 'gallium-xlib'
+error('Cannot build glvnd support for GLX that is not DRI based.')
+  elif with_glx == 'disabled' and not with_egl
+error('glvnd requires DRI based GLX and/or EGL')
+  endif
 endif
 
 # TODO: toggle for this
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 0/2] etnaviv: ASTC texture support

[Ilia Mirkin]

On Wed, Nov 1, 2017 at 1:19 PM, Wladimir J. van der Laan
 wrote:
> Add ASTC texture support for hardware that supports this
> (currently only GC3000 on i.MX6qp is known to have this).
>
> Piglit output:
>
> $ bin/khr_compressed_astc-miptree_gles2
> PIGLIT: {"subtest": {"LDR Profile" : "pass"}}
> PIGLIT: {"subtest": {"HDR Profile" : "pass"}}
> PIGLIT: {"subtest": {"sRGB decode" : "pass"}}
> Probe at (144,44)
> Expected: 0.972549 0.972549 0.972549 1.00
> Observed: 0.984314 0.984314 0.984314 1.00
> piglit: error: Miplevel 0
> piglit: error: Mode ldrs Block 4x4.
> PIGLIT: {"subtest": {"sRGB decode full precision" : "fail"}}
> PIGLIT: {"subtest": {"sRGB skip decode" : "pass"}}
>
> This means all block sizes are working, and basic RGB/sRGB.
>
> Not sure why "sRGB decode full precision" is not passing,
> probably the hw just doesn't do that.

On the off chance that you're not intimately familiar with ASTC,
there's the concept of decoding into UNORM8 and FP16's. I don't mean
the external view of it, but internal as part of the decompression.
The end result is what it is, but with FP16 you get more precision esp
when doing sRGB correction (perhaps only when you do sRGB correction).

"""
If sRGB conversion is enabled, the top 8 bits of the interpolation
result for the R, G and B channels are passed to the external sRGB
conversion block. Otherwise, if C = 65535, then the final result is
1.0 (0x3C00) otherwise C is divided by 65536 and the infinite-precision
result of the division is converted to FP16 with round-to-zero
semantics.
"""

And HDR is supposed to be all-FP16. Anyways, I wouldn't be surprised
if some of those UNK's enable FP16 decoding.

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

Re: [Mesa-dev] [PATCH 33/33] intel: add aubinator ui

[Scott D Phillips]

Lionel Landwerlin  writes:

> On 31/10/17 21:11, Scott D Phillips wrote:
>>> +}
>> [snip imgui]
>>
>> imgui seems to be the first instance of someone pasting a sizeable third
>> party library into the repo.  I'm not sure how everyone feels about
>> that. Unfortunately it seems like imgui isn't packaged by any distros
>> that I can see either.
>>
>> Maybe we could do some meson wrap magic or something to pull it in
>> without having to commit the code.
>>
> Copying seems to be the main way anybody is using it. Are you suggesting 
> a submodule?

Right, something like making a 'wrap' for imgui that can go download and
build the source:

http://mesonbuild.com/Wrap-dependency-system-manual.html

Really no idea if this is a great or terrible idea though. Dylan might
have a better idea.

> ___
> 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] gallium: increase pipe_sampler_view::target bitfield size for MSVC

[Charmaine Lee]

Nice catch.

Reviewed-by: Charmaine Lee 

From: Brian Paul 
Sent: Wednesday, November 1, 2017 7:45:29 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH] gallium: increase pipe_sampler_view::target bitfield size for 
MSVC

MSVC treats enums as being signed.  The 4-bit target field isn't large
enough to correctly store the value 8 (for PIPE_TEXTURE_CUBE_ARRAY).
The bitfield value 0x8 was being interpreted as -8 so matching the
target with PIPE_TEXTURE_CUBE_ARRAY in switch statements, etc. was
failing.

To keep the structure size the same, we reduce the format field from
16 bits to 15.  There don't appear to be any other enum bitfields
which need to be adjusted.

This fixes a number of Piglit cube map array tests.
---
 src/gallium/include/pipe/p_state.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/include/pipe/p_state.h 
b/src/gallium/include/pipe/p_state.h
index 10bf678..90dc561 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -34,6 +34,10 @@
  * Basic notes:
  *   1. Want compact representations, so we use bitfields.
  *   2. Put bitfields before other (GLfloat) fields.
+ *   3. enum bitfields need to be at least one bit extra in size so the most
+ *  significant bit is zero.  MSVC treats enums as signed so if the high
+ *  bit is set, the value will be interpreted as a negative number.
+ *  That causes trouble in various places.
  */


@@ -436,8 +440,8 @@ struct pipe_surface
 struct pipe_sampler_view
 {
struct pipe_reference reference;
-   enum pipe_format format:16;  /**< typed PIPE_FORMAT_x */
-   enum pipe_texture_target target:4; /**< PIPE_TEXTURE_x */
+   enum pipe_format format:15;  /**< typed PIPE_FORMAT_x */
+   enum pipe_texture_target target:5; /**< PIPE_TEXTURE_x */
unsigned swizzle_r:3; /**< PIPE_SWIZZLE_x for red component */
unsigned swizzle_g:3; /**< PIPE_SWIZZLE_x for green component */
unsigned swizzle_b:3; /**< PIPE_SWIZZLE_x for blue component */
--
1.9.1

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

Re: [Mesa-dev] create src/wsi

[Emil Velikov]

On 31 October 2017 at 21:07, Dylan Baker  wrote:
> Quoting Emil Velikov (2017-10-30 10:47:22)
>> On 30 October 2017 at 17:05, Dylan Baker  wrote:
>> > So I think the consensus is this is okay?
>> >
>> > Emil, is the autotools right here?
>> >
>>
>> Without a clear separation or cleanup of the the existing code, this
>> such move brings no technical benefit.
>> If anything, it makes it harder for people [roughly] familiar with
>> current setup.
>>
>> i was wondering if we can nuke wl_drm, but I don't see that happening
>> anytime soon :-(
>>
>> -Emil
>
> How strong is your objection Emil?
>
> My intention is to pull some of the generated files that are shared
> between vulkan/wsi/wayland and egl/wayland/wayland-drm. Daniel has said that 
> he
> has more generated files that will be shared between them in work he is doing
> currently, and putting them in neither EGL or Wayland would make the build
> cleaner, and that's the intention of this series.
>
Across various systems I have over ~10 different branches that cover
egl, gbm and friends.
I have to admit that the goal is very admirable, but it would
seriously hinder attempts to get those sorted.

If the key issue is wayland-drm - we should be able to move the XML
file to wayland-protocols?
This way it will be a bit more straightforward, we can drop the 4
copies of it with a single canonical one.

I'll same a patch for that later on today/early tomorrow.

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

Re: [Mesa-dev] [PATCH v2] meson: implement default driver arguments

[Dylan Baker]

Quoting Eric Engestrom (2017-11-01 04:09:26)
> On Tuesday, 2017-10-31 15:50:49 -0700, Dylan Baker wrote:
> > This allows drivers to be set by OS/arch in a sane manner.
> > 
> > v2: - set _drivers to a list of drivers instead of manually assigning
> >   each with_*
> > 
> > cc: Eric Engestrom 
> > Signed-off-by: Dylan Baker 
> > ---
> >  meson.build   | 18 ++
> >  meson_options.txt |  8 
> >  2 files changed, 22 insertions(+), 4 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index d22d49535af..38c0c77f875 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -90,6 +90,14 @@ with_dri_r200 = false
> >  with_dri_nouveau = false
> >  with_dri_swrast = false
> >  _drivers = get_option('dri-drivers')
> > +if _drivers == 'default'
> > +  if ['linux', 'bsd'].contains(host_machine.system())
> > +if ['x86', 'x86_64'].contains(host_machine.cpu_family())
> > +  _drivers = 'i915,i965,r100,r200,nouveau'
> > +endif
> > +# TODO: PPC, Sparc
> > +  endif
> 
> I think we need something here to handle the cases where `default` is
> the value, but isn't handled by the detection logic.
> Something like this at the end of the `_drivers == default` block, for
> instance?
> 
> if _drivers == 'default'
>   error(host_machine.system() + ' ' + host_machine.cpu_family() + ' has no 
> default set; you need to set `dri-drivers` manually with `meson configure 
> -Ddri-drivers=something`')
> endif
> 
> (that's a bloody long line, but I don't think meson supports multiline
> error)

meson has ''' strings like python, I have no idea if you can use them in errors.
I guess I'll find out

> 
> > +endif
> >  if _drivers != ''
> >_split = _drivers.split(',')
> >with_dri_i915 = _split.contains('i915')
> > @@ -112,6 +120,16 @@ with_gallium_vc5 = false
> >  with_gallium_etnaviv = false
> >  with_gallium_imx = false
> >  _drivers = get_option('gallium-drivers')
> > +if _drivers == 'default'
> > +  if ['linux', 'bsd'].contains(host_machine.system())
> > +if ['x86', 'x86_64'].contains(host_machine.cpu_family())
> > +  _drivers = 'radeonsi,nouveau,softpipe'
> > +elif ['arm', 'aarch64'].contains(host_machine.cpu_family())
> > +  _drivers = 'pl111,vc4,vc5,freedreno,etnaviv,imx,softpipe'
> 
> `softpipe` is a new addition in this commit; might be worth splitting
> out, or at least mention in the commit message.

oops, that should be swrast, which is in the default list.

Internally we call it softpipe (because swr is also a gallium based software
rasterizer), but to keep compatibility with autotools it's called swrast for
-Dgallium-drivers

> 
> > +endif
> > +# TODO: PPC, Sparc
> > +  endif
> 
> same `if _drivers still 'default'` error here.
> 
> Other than that, this looks good to me. With the errors added and
> the addition of softpipe mentioned in the commit msg or split out,
> this is:
> Reviewed-by: Eric Engestrom 
> 
> > +endif
> >  if _drivers != ''
> >_split = _drivers.split(',')
> >with_gallium_pl111 = _split.contains('pl111')
> > diff --git a/meson_options.txt b/meson_options.txt
> > index d93dd6eab2a..ce46438b5d3 100644
> > --- a/meson_options.txt
> > +++ b/meson_options.txt
> > @@ -34,8 +34,8 @@ option(
> >  option(
> >'dri-drivers',
> >type : 'string',
> > -  value : 'i915,i965,r100,r200,nouveau',
> > -  description : 'comma separated list of dri drivers to build.'
> > +  value : 'default',
> > +  description : 'comma separated list of dri drivers to build. If this is 
> > set to default all drivers applicable to the target OS/architecture will be 
> > built'
> >  )
> >  option(
> >'dri-drivers-path',
> > @@ -46,8 +46,8 @@ option(
> >  option(
> >'gallium-drivers',
> >type : 'string',
> > -  value : 'pl111,radeonsi,nouveau,freedreno,swrast,vc4,etnaviv,imx',
> > -  description : 'comma separated list of gallium drivers to build.'
> > +  value : 'default',
> > +  description : 'comma separated list of gallium drivers to build. If this 
> > is set to default all drivers applicable to the target OS/architecture will 
> > be built'
> >  )
> >  option(
> >'gallium-media',
> > -- 
> > 2.14.3
> > 


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 2/2] etnaviv: ASTC texture support

[Christian Gmeiner]

Hi..

First quick review send from my smartphone...

Am 01.11.2017 6:19 nachm. schrieb "Wladimir J. van der Laan" <
laa...@gmail.com>:

Add ASTC texture support for hardware that supports this
(currently only GC3000 on i.MX6qp is known to have this).

Signed-off-by: Wladimir J. van der Laan 
---
 src/gallium/drivers/etnaviv/etnaviv_emit.c |  8 +++
 src/gallium/drivers/etnaviv/etnaviv_format.c   | 30
++
 src/gallium/drivers/etnaviv/etnaviv_format.h   |  1 +
 src/gallium/drivers/etnaviv/etnaviv_internal.h |  2 ++
 src/gallium/drivers/etnaviv/etnaviv_screen.c   |  6 ++
 src/gallium/drivers/etnaviv/etnaviv_texture.c  | 11 --
 src/gallium/drivers/etnaviv/etnaviv_texture.h  |  1 +
 7 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c
b/src/gallium/drivers/etnaviv/etnaviv_emit.c
index 5397aa3..d313af6 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
@@ -703,6 +703,14 @@ etna_emit_state(struct etna_context *ctx)
  /*03828*/ EMIT_STATE(GL_VARYING_COMPONENT_USE(x),
ctx->shader_state.GL_VARYING_COMPONENT_USE[x]);
   }
}
+   if (unlikely(ctx->specs.tex_astc && (dirty &
(ETNA_DIRTY_SAMPLER_VIEWS {
+  for (int x = 0; x < VIVS_TE_SAMPLER__LEN; ++x) {
+ if ((1 << x) & active_samplers) {
+struct etna_sampler_view *sv = etna_sampler_view(ctx->
sampler_view[x]);
+/*10500*/ EMIT_STATE(NTE_SAMPLER_ASTC0(x),
sv->TE_SAMPLER_ASTC0);
+ }
+  }
+   }
etna_coalesce_end(stream, &coalesce);
/* end only EMIT_STATE */

diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.c
b/src/gallium/drivers/etnaviv/etnaviv_format.c
index 987f6a8..3dd212f 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.c
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.c
@@ -246,6 +246,36 @@ static struct etna_format formats[PIPE_FORMAT_COUNT] =
{
_T(ETC2_RG11_UNORM, EXT_RG11_EAC | EXT_FORMAT,
SWIZ(X, Y, Z, W), NONE),
_T(ETC2_RG11_SNORM, EXT_SIGNED_RG11_EAC | EXT_FORMAT,
 SWIZ(X, Y, Z, W), NONE),

+   _T(ASTC_4x4,ASTC_RGBA_4x4 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_5x4,ASTC_RGBA_5x4 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_5x5,ASTC_RGBA_5x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_6x5,ASTC_RGBA_6x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_6x6,ASTC_RGBA_6x6 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x5,ASTC_RGBA_8x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x6,ASTC_RGBA_8x6 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x8,ASTC_RGBA_8x8 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x5,   ASTC_RGBA_10x5 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x6,   ASTC_RGBA_10x6 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x8,   ASTC_RGBA_10x8 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x10,  ASTC_RGBA_10x10 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_12x10,  ASTC_RGBA_12x10 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_12x12,  ASTC_RGBA_12x12 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+
+   _T(ASTC_4x4_SRGB,   ASTC_SRGB8_ALPHA8_4x4 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_5x4_SRGB,   ASTC_SRGB8_ALPHA8_5x4 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_5x5_SRGB,   ASTC_SRGB8_ALPHA8_5x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_6x5_SRGB,   ASTC_SRGB8_ALPHA8_6x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_6x6_SRGB,   ASTC_SRGB8_ALPHA8_6x6 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x5_SRGB,   ASTC_SRGB8_ALPHA8_8x5 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x6_SRGB,   ASTC_SRGB8_ALPHA8_8x6 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_8x8_SRGB,   ASTC_SRGB8_ALPHA8_8x8 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x5_SRGB,  ASTC_SRGB8_ALPHA8_10x5 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x6_SRGB,  ASTC_SRGB8_ALPHA8_10x6 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x8_SRGB,  ASTC_SRGB8_ALPHA8_10x8 | ASTC_FORMAT,
 SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_10x10_SRGB, ASTC_SRGB8_ALPHA8_10x10 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_12x10_SRGB, ASTC_SRGB8_ALPHA8_12x10 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+   _T(ASTC_12x12_SRGB, ASTC_SRGB8_ALPHA8_12x12 | ASTC_FORMAT,
SWIZ(X, Y, Z, W), NONE),
+
/* YUV */
_T(YUYV, YUY2, SWIZ(X, Y, Z, W), YUY2),
_T(UYVY, UYVY, SWIZ(X, Y, Z, W), NONE),
diff --git a/src/gallium/drivers/etnaviv/etnaviv_format.h
b/src/gallium/drivers/etnaviv/etnaviv_format.h
index 543e309..1672d67 100644
--- a/src/gallium/drivers/etnaviv/etnaviv_format.h
+++ b/src/gallium/drivers/etnaviv/etnaviv_format.h
@@ -32,6 +32,7 @@

 #define ETNA_NO_MATCH (~0)
 #define EXT_FORMAT (1 << 31)
+#define ASTC_FORMAT (1 << 30)


 uint32_t
 translate_texture_format(enum pipe_format fmt);
diff --git a/src/gallium/drivers/etnaviv/etnaviv_i

Re: [Mesa-dev] [PATCH v2] meson: Allow building glvnd with EGL and non-dri based GLX

[Emil Velikov]

On 1 November 2017 at 17:24, Dylan Baker  wrote:
> Because meson mirrors the auototools logic, it needs the same changes to
> allow building glvnd based egl.
>
> v2: - change if to elif (Eric)
>
> Signed-off-by: Dylan Baker 
> Reviewed-by: Eric Engestrom 
Thanks for the correction/fixup Dylan. FWIW
Acked-by: Emil Velikov 

This should be fine to land regardless of the autotools commit.
I'll push those in the morning - don't want to risk breaking $world by
pushing at 7:30pm :-\

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

Re: [Mesa-dev] [PATCH 2/2] i965/miptree: Use format_ccs_compat_with_miptree for textures

[Nanley Chery]

On Tue, Oct 31, 2017 at 08:01:05PM -0700, Jason Ekstrand wrote:
> This function is a bit more accurate because it lets us sample from sRGB
> textures if sRGB decode is off.  This should improve performance in
  ^ ^
 missing "with CCS_E"?   extra word?

> whenever GL_SKIP_DECODE_EXT is used.
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index 82f5a81..835d7ae 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -2566,9 +2566,8 @@ can_texture_with_ccs(struct brw_context *brw,
> if (mt->aux_usage != ISL_AUX_USAGE_CCS_E)
>return false;
>  
> -   /* TODO: Replace with format_ccs_e_compat_with_miptree for better perf. */
> -   if (!isl_formats_are_ccs_e_compatible(&brw->screen->devinfo,
> - mt->surf.format, view_format)) {
> +   if (!format_ccs_e_compat_with_miptree(&brw->screen->devinfo,
> + mt, view_format)) {
>perf_debug("Incompatible sampling format (%s) for rbc (%s)\n",
>   isl_format_get_layout(view_format)->name,
>   _mesa_get_format_name(mt->format));

Do we want to update this perf_debug to return the linear format of the
miptree?

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

Re: [Mesa-dev] create src/wsi

[Jason Ekstrand]

On Wed, Nov 1, 2017 at 10:33 AM, Emil Velikov 
wrote:

> On 31 October 2017 at 21:07, Dylan Baker  wrote:
> > Quoting Emil Velikov (2017-10-30 10:47:22)
> >> On 30 October 2017 at 17:05, Dylan Baker  wrote:
> >> > So I think the consensus is this is okay?
> >> >
> >> > Emil, is the autotools right here?
> >> >
> >>
> >> Without a clear separation or cleanup of the the existing code, this
> >> such move brings no technical benefit.
> >> If anything, it makes it harder for people [roughly] familiar with
> >> current setup.
> >>
> >> i was wondering if we can nuke wl_drm, but I don't see that happening
> >> anytime soon :-(
> >>
> >> -Emil
> >
> > How strong is your objection Emil?
> >
> > My intention is to pull some of the generated files that are shared
> > between vulkan/wsi/wayland and egl/wayland/wayland-drm. Daniel has said
> that he
> > has more generated files that will be shared between them in work he is
> doing
> > currently, and putting them in neither EGL or Wayland would make the
> build
> > cleaner, and that's the intention of this series.
> >
> Across various systems I have over ~10 different branches that cover
> egl, gbm and friends.
> I have to admit that the goal is very admirable, but it would
> seriously hinder attempts to get those sorted.
>
> If the key issue is wayland-drm - we should be able to move the XML
> file to wayland-protocols?
>

No, wayland-drm is internal to mesa and needs to stay that way.  There are
other XML files that we need to use which are in wayland-protocols but it
would be nice if we had a single place where the codegen is done so we
don't have to repeat it per-component.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

[Dylan Baker]

I'm asking a dumb question, but we always build with --enable-debug, are you
building with --enable-debug?

Dylan

Quoting Marek Olšák (2017-10-31 18:16:51)
> This is how I run piglit on i965:
> WAFFLE_GBM_DEVICE=/dev/dri/renderD128 PIGLIT_PLATFORM=gbm 
> piglit/bin/glinfo|head
> GL_RENDERER = Mesa DRI Intel(R) Ivybridge Desktop
> 
> Of course I have Radeon as my main GPU.
> 
> Marek
> 
> On Wed, Nov 1, 2017 at 12:52 AM, Mark Janes  wrote:
> > No, please don't.  We can't have thousands of failures added to CI.
> >
> > Dylan, can you double check this for Marek?  I'm surprised that it
> > doesn't reproduce for him.
> >
> > -Mark
> >
> > Marek Olšák  writes:
> >
> >> I can't reproduce the issue on my IVB. How about I just push this and
> >> you guys fix i965 when you have time?
> >>
> >> Marek
> >>
> >> On Thu, Oct 26, 2017 at 5:46 PM, Mark Janes  wrote:
> >>> That fixed many issues, but:
> >>>
> >>> On deqp EGL tests, we get:
> >>>
> >>> dEQP-EGL.functional.create_context_ext.gl_42.rgba_no_depth_no_stencil
> >>> deqp-egl: main/api_exec.c:135: _mesa_initialize_exec_table: Assertion 
> >>> `ctx->Version > 0' failed.
> >>>
> >>> On ES31 CTS tests:
> >>> ES31-CTS.functional.texture.texture_buffer.render.as_vertex_array_as_vertex_texture_as_fragment_texture.range_size_513
> >>> glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
> >>> gluContextInfo.cpp:229
> >>>
> >>> on GL46 CTS (27 failures):
> >>> src/mesa/main/teximage.c:595: _mesa_tex_target_is_layered: Assertion
> >>> `!"Invalid texture target."' failed.
> >>>
> >>> Piglit fails 3.5k tests with the same `ctx->Version > 0' assertion as
> >>> deqp-egl.
> >>>
> >>> -Mark
> >>>
> >>> Dylan Baker  writes:
> >>>
>  I've pushed it to our CI, I'll let you know tomorrow what it looks like
> 
>  Dylan
> 
>  Quoting Marek Olšák (2017-10-25 19:52:43)
> > Hi Dylan,
> >
> > Can you please add this and re-test?
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> > b/src/mesa/drivers/
> > dri/i965/intel_extensions.c
> > index 21cf632..4d17393 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -178,7 +178,7 @@ intelInitExtensions(struct gl_context *ctx)
> >ctx->Extensions.ARB_pipeline_statistics_query = true;
> >ctx->Extensions.ARB_sample_shading = true;
> >ctx->Extensions.ARB_shading_language_420pack = true;
> > -  if (ctx->API == API_OPENGL_CORE) {
> > +  if (ctx->API != API_OPENGL_COMPAT) {
> >   ctx->Extensions.ARB_texture_buffer_object = true;
> >   ctx->Extensions.ARB_texture_buffer_object_rgb32 = true;
> >   ctx->Extensions.ARB_texture_buffer_range = true;
> >
> >
> > Marek
> >
> > On Wed, Oct 25, 2017 at 11:42 PM, Dylan Baker 
> >  wrote:
> >
> > There are a significant number of i965 regressions from
> > d96c68146a781c79a23f5181d7050174f1070d90, largely related to 
> > texturing (I
> > can
> > send you a complete list of regressions if you care, but due to the 
> > large
> > number
> > of them I suspect it's something fairly simple).
> >
> > For example:
> > ES31-CTS.functional.texture.format.buffer.r32ui_npot
> >
> > glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
> > gluContextInfo.cpp:229
> >
> > dEQP-GLES31.functional.state_query.integer.texture_buffer_
> > binding_getinteger:
> >
> > glGetIntegerv(GL_TEXTURE_BUFFER_BINDING, 0x7ffee0c43834);
> > // data = { -555819298 }
> > glGetError();
> > // GL_INVALID_ENUM returned
> >  // ERROR: glGetIntegerv: glGetError() returned GL_INVALID_ENUM
> >
> > Dylan
> >
> > Quoting Emil Velikov (2017-10-24 09:30:03)
> > > Hi Marek,
> > >
> > > On 21 October 2017 at 13:54, Marek Olšák  wrote:
> > > > From: Marek Olšák 
> > > >
> > > > We already have piglit tests testing alpha, luminance, and 
> > intensity
> > > > formats. They were skipped by piglit until now.
> > > >
> > > > Additionally, I'm enabling one ARB_texture_buffer_range piglit 
> > test to
> > run
> > > > with the compat profile.
> > >
> > > Can you please mention that ARB_texture_buffer_* on i965 is 
> > unchanged
> > > - aka still enabled only for core profiles.
> > > Out of curiosity - can you tried the series with anything more 
> > than
> > piglit?
> > >
> > > The Intel guys can run the lot through CTS, dEQP... admittedly 
> > only on
> > > Intel hardware.
> > > Still it should help catch if a piece is missing somewhere.
> > >
> > >
> > > -Emil
> > > __

Re: [Mesa-dev] [PATCH 2/2] i965/miptree: Use format_ccs_compat_with_miptree for textures

[Jason Ekstrand]

On Wed, Nov 1, 2017 at 10:46 AM, Nanley Chery  wrote:

> On Tue, Oct 31, 2017 at 08:01:05PM -0700, Jason Ekstrand wrote:
> > This function is a bit more accurate because it lets us sample from sRGB
> > textures if sRGB decode is off.  This should improve performance in
>   ^ ^
>  missing "with CCS_E"?   extra
> word?
>

Yup.  Commit message improved:

Using this function is a bit more accurate because it lets us sample
from sRGB textures with CCS_E whenever sRGB decode is disabled.  The
old check for CCS_E compatibility would bail if the miptree's native
format were sRGB even if the view format is linear.  This should improve
performance whenever GL_SKIP_DECODE_EXT is used.



>
> > whenever GL_SKIP_DECODE_EXT is used.
> > ---
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > index 82f5a81..835d7ae 100644
> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > @@ -2566,9 +2566,8 @@ can_texture_with_ccs(struct brw_context *brw,
> > if (mt->aux_usage != ISL_AUX_USAGE_CCS_E)
> >return false;
> >
> > -   /* TODO: Replace with format_ccs_e_compat_with_miptree for better
> perf. */
> > -   if (!isl_formats_are_ccs_e_compatible(&brw->screen->devinfo,
> > - mt->surf.format, view_format))
> {
> > +   if (!format_ccs_e_compat_with_miptree(&brw->screen->devinfo,
> > + mt, view_format)) {
> >perf_debug("Incompatible sampling format (%s) for rbc (%s)\n",
> >   isl_format_get_layout(view_format)->name,
> >   _mesa_get_format_name(mt->format));
>
> Do we want to update this perf_debug to return the linear format of the
> miptree
>

I don't know that it matters much since it's just a perf debug.  I think
I'd prefer we leave it as-is because right now it tells us the exact
miptree format not some format calculated from it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

[Marek Olšák]

On Wed, Nov 1, 2017 at 6:56 PM, Dylan Baker  wrote:
> I'm asking a dumb question, but we always build with --enable-debug, are you
> building with --enable-debug?

Yes. If ctx->Version == 0, something is terribly wrong and the OpenGL
driver should be non-functional.

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

Re: [Mesa-dev] [PATCH 2/2] etnaviv: ASTC texture support

[Wladimir J. van der Laan]

On Wed, Nov 01, 2017 at 06:38:21PM +0100, Christian Gmeiner wrote:

> I would love to see a new format helper (util_format_is_astc(..) and not
> even start thinking about adding a new format bit (ASTC_FORMAT).

These formats are in a completely different space from the others, in the
hardware (programmed through a different register), so IMO it makes sense to
add a new format bit for it, just like for EXT_FORMAT.

Relying on mesa's judgement on whether something is astc seems brittle.

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

[Mesa-dev] [PATCH v2 00/11] intel: UI for aubinator

[Lionel Landwerlin]

Hi,

A quick update following a number of comments. Scott's suggestion of
using aubdumps' mmapped memory to decode instruction instead of
another structure isn't implemented yet (I'll probably post a v3 with
that). Meanwhile a few other small patches could make it onto master.

Cheers,

Lionel Landwerlin (11):
  intel: aubinator: factor out MI_BATCH_BUFFER_END
  intel: decoder: remove duplicate of gen_spec_find_enum() declaration
  intel: decoder: enable search for instruction by name
  intel: genxml: add blitter instructions for gen6->10
  intel: genxml: be consistent about register offset naming
  intel: genxml: rename output urb offset field
  intel: decoder: change group_get_length() to take first dword
  intel: decoder: change find_instruction() to take first dword
  intel: decoder: decouple decoding from memory pointers
  intel: decoder: add function to query shader length
  intel: add aubinator ui

 configure.ac   |16 +
 meson.build| 7 +
 meson_options.txt  | 6 +
 src/intel/Makefile.tools.am|58 +
 src/intel/common/gen_decoder.c |   112 +-
 src/intel/common/gen_decoder.h |30 +-
 src/intel/genxml/gen10.xml |   782 +-
 src/intel/genxml/gen4.xml  | 2 +-
 src/intel/genxml/gen45.xml | 2 +-
 src/intel/genxml/gen5.xml  | 2 +-
 src/intel/genxml/gen6.xml  |   748 +-
 src/intel/genxml/gen7.xml  |   750 +-
 src/intel/genxml/gen75.xml |   754 +-
 src/intel/genxml/gen8.xml  |   739 +-
 src/intel/genxml/gen9.xml  |   782 +-
 src/intel/tools/.gitignore | 2 +
 src/intel/tools/aubinator.c|17 +-
 src/intel/tools/aubinator_error_decode.c   |16 +-
 src/intel/tools/aubinator_imgui_widgets.cpp|   183 +
 src/intel/tools/aubinator_imgui_widgets.h  |12 +
 src/intel/tools/aubinator_ui.cpp   |  3174 +++
 src/intel/tools/disasm.c   |34 +
 src/intel/tools/gen_disasm.h   | 2 +
 src/intel/tools/imgui/LICENSE.txt  |21 +
 src/intel/tools/imgui/imconfig.h   |57 +
 src/intel/tools/imgui/imgui.cpp| 10725 +++
 src/intel/tools/imgui/imgui.h  |  1516 
 src/intel/tools/imgui/imgui_demo.cpp   |  2827 ++
 src/intel/tools/imgui/imgui_draw.cpp   |  2673 ++
 src/intel/tools/imgui/imgui_impl_gtk3_cogl.cpp |   784 ++
 src/intel/tools/imgui/imgui_impl_gtk3_cogl.h   |27 +
 src/intel/tools/imgui/imgui_internal.h |   864 ++
 src/intel/tools/imgui/stb_rect_pack.h  |   583 ++
 src/intel/tools/imgui/stb_textedit.h   |  1322 +++
 src/intel/tools/imgui/stb_truetype.h   |  4018 +
 src/intel/tools/intel_aub.h| 1 +
 src/intel/tools/memory.c   |   545 ++
 src/intel/tools/memory.h   |55 +
 src/intel/tools/meson.build|30 +
 src/intel/vulkan/genX_cmd_buffer.c | 6 +-
 src/intel/vulkan/genX_gpu_memcpy.c | 4 +-
 src/intel/vulkan/genX_query.c  |20 +-
 src/mesa/drivers/dri/i965/genX_state_upload.c  | 2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c  |30 +-
 44 files changed, 34227 insertions(+), 113 deletions(-)
 create mode 100644 src/intel/tools/aubinator_imgui_widgets.cpp
 create mode 100644 src/intel/tools/aubinator_imgui_widgets.h
 create mode 100644 src/intel/tools/aubinator_ui.cpp
 create mode 100644 src/intel/tools/imgui/LICENSE.txt
 create mode 100644 src/intel/tools/imgui/imconfig.h
 create mode 100644 src/intel/tools/imgui/imgui.cpp
 create mode 100644 src/intel/tools/imgui/imgui.h
 create mode 100644 src/intel/tools/imgui/imgui_demo.cpp
 create mode 100644 src/intel/tools/imgui/imgui_draw.cpp
 create mode 100644 src/intel/tools/imgui/imgui_impl_gtk3_cogl.cpp
 create mode 100644 src/intel/tools/imgui/imgui_impl_gtk3_cogl.h
 create mode 100644 src/intel/tools/imgui/imgui_internal.h
 create mode 100644 src/intel/tools/imgui/stb_rect_pack.h
 create mode 100644 src/intel/tools/imgui/stb_textedit.h
 create mode 100644 src/intel/tools/imgui/stb_truetype.h
 create mode 100644 src/intel/tools/memory.c
 create mode 100644 src/intel/tools/memory.h

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

[Mesa-dev] [PATCH v2 03/11] intel: decoder: enable search for instruction by name

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/common/gen_decoder.c | 8 
 src/intel/common/gen_decoder.h | 1 +
 2 files changed, 9 insertions(+)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index d09b6ea32b6..736bfd6df16 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -73,6 +73,14 @@ gen_group_get_opcode(struct gen_group *group)
return group->opcode;
 }
 
+struct gen_group *
+gen_spec_find_instruction_by_name(struct gen_spec *spec, const char *name)
+{
+   struct hash_entry *entry = _mesa_hash_table_search(spec->commands,
+  name);
+   return entry ? entry->data : NULL;
+}
+
 struct gen_group *
 gen_spec_find_struct(struct gen_spec *spec, const char *name)
 {
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 28bf94b099e..343d68b0eda 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -51,6 +51,7 @@ struct gen_spec *gen_spec_load_from_path(const struct 
gen_device_info *devinfo,
 void gen_spec_destroy(struct gen_spec *spec);
 uint32_t gen_spec_get_gen(struct gen_spec *spec);
 struct gen_group *gen_spec_find_instruction(struct gen_spec *spec, const 
uint32_t *p);
+struct gen_group *gen_spec_find_instruction_by_name(struct gen_spec *spec, 
const char *name);
 struct gen_group *gen_spec_find_register(struct gen_spec *spec, uint32_t 
offset);
 struct gen_group *gen_spec_find_register_by_name(struct gen_spec *spec, const 
char *name);
 struct gen_enum *gen_spec_find_enum(struct gen_spec *spec, const char *name);
-- 
2.15.0

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

[Mesa-dev] [PATCH v2 01/11] intel: aubinator: factor out MI_BATCH_BUFFER_END

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/tools/aubinator.c | 6 --
 src/intel/tools/intel_aub.h | 1 +
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 48d4456cc16..728edad37ff 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -43,12 +43,6 @@
 #include "intel_aub.h"
 #include "gen_disasm.h"
 
-/* Below is the only command missing from intel_aub.h in libdrm
- * So, reuse intel_aub.h from libdrm and #define the
- * AUB_MI_BATCH_BUFFER_END as below
- */
-#define AUB_MI_BATCH_BUFFER_END (0x0500 << 16)
-
 #define CSI "\e["
 #define BLUE_HEADER  CSI "0;44m"
 #define GREEN_HEADER CSI "1;42m"
diff --git a/src/intel/tools/intel_aub.h b/src/intel/tools/intel_aub.h
index 5f0aba8e68e..f9de3c918e1 100644
--- a/src/intel/tools/intel_aub.h
+++ b/src/intel/tools/intel_aub.h
@@ -42,6 +42,7 @@
 
 #define AUB_MI_NOOP(0)
 #define AUB_MI_BATCH_BUFFER_START  (0x31 << 23)
+#define AUB_MI_BATCH_BUFFER_END(0x05 << 24)
 #define AUB_PIPE_CONTROL   (0x7a02)
 
 /* DW0: instruction type. */
-- 
2.15.0

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

[Mesa-dev] [PATCH v2 02/11] intel: decoder: remove duplicate of gen_spec_find_enum() declaration

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/common/gen_decoder.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 8b00b6edc2f..28bf94b099e 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -59,7 +59,6 @@ int gen_group_get_length(struct gen_group *group, const 
uint32_t *p);
 const char *gen_group_get_name(struct gen_group *group);
 uint32_t gen_group_get_opcode(struct gen_group *group);
 struct gen_field *gen_group_find_field(struct gen_group *group, const char 
*name);
-struct gen_enum *gen_spec_find_enum(struct gen_spec *spec, const char *name);
 
 bool gen_field_is_header(struct gen_field *field);
 void gen_field_decode(struct gen_field *field,
-- 
2.15.0

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

[Mesa-dev] [PATCH v2 05/11] intel: genxml: be consistent about register offset naming

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/genxml/gen10.xml |  8 
 src/intel/genxml/gen4.xml  |  2 +-
 src/intel/genxml/gen45.xml |  2 +-
 src/intel/genxml/gen5.xml  |  2 +-
 src/intel/genxml/gen6.xml  |  2 +-
 src/intel/genxml/gen7.xml  |  4 ++--
 src/intel/genxml/gen75.xml |  8 
 src/intel/genxml/gen8.xml  |  8 
 src/intel/genxml/gen9.xml  |  8 
 src/intel/vulkan/genX_cmd_buffer.c |  6 +++---
 src/intel/vulkan/genX_gpu_memcpy.c |  4 ++--
 src/intel/vulkan/genX_query.c  | 20 ++--
 12 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index bb33526e6dc..5bb46f819a8 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -3195,7 +3195,7 @@
 
 
 
-
+
 
   
 
@@ -3203,8 +3203,8 @@
 
 
 
-
-
+
+
   
 
   
@@ -3405,7 +3405,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen4.xml b/src/intel/genxml/gen4.xml
index fc24329535d..6345b75c48f 100644
--- a/src/intel/genxml/gen4.xml
+++ b/src/intel/genxml/gen4.xml
@@ -1100,7 +1100,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen45.xml b/src/intel/genxml/gen45.xml
index c91085831ea..dd9ca262030 100644
--- a/src/intel/genxml/gen45.xml
+++ b/src/intel/genxml/gen45.xml
@@ -1130,7 +1130,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen5.xml b/src/intel/genxml/gen5.xml
index 93e687a32bd..4c822df67f8 100644
--- a/src/intel/genxml/gen5.xml
+++ b/src/intel/genxml/gen5.xml
@@ -1216,7 +1216,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index 0707a33cd2a..317529b4065 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -1833,7 +1833,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index bda3b82e718..09d45818c3a 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -2254,7 +2254,7 @@
 
 
 
-
+
 
   
 
@@ -2347,7 +2347,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index b6aa9c55031..0bd1ce6ace6 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -2614,7 +2614,7 @@
 
 
 
-
+
 
   
 
@@ -2622,8 +2622,8 @@
 
 
 
-
-
+
+
   
 
   
@@ -2796,7 +2796,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 9f0fa48ce66..7ccb8046796 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2835,7 +2835,7 @@
 
 
 
-
+
 
   
 
@@ -2843,8 +2843,8 @@
 
 
 
-
-
+
+
   
 
   
@@ -3056,7 +3056,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 0e2dddeacfb..db4b608f61f 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3120,7 +3120,7 @@
 
 
 
-
+
 
   
 
@@ -3128,8 +3128,8 @@
 
 
 
-
-
+
+
   
 
   
@@ -3341,7 +3341,7 @@
 
 
 
-
+
 
   
 
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index 20a885c4381..fd395ff3077 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -37,7 +37,7 @@ emit_lrm(struct anv_batch *batch,
  uint32_t reg, struct anv_bo *bo, uint32_t offset)
 {
anv_batch_emit(batch, GENX(MI_LOAD_REGISTER_MEM), lrm) {
-  lrm.RegisterAddress  = reg;
+  lrm.RegisterOffset   = reg;
   lrm.MemoryAddress= (struct anv_address) { bo, offset };
}
 }
@@ -56,8 +56,8 @@ static void
 emit_lrr(struct anv_batch *batch, uint32_t dst, uint32_t src)
 {
anv_batch_emit(batch, GENX(MI_LOAD_REGISTER_REG), lrr) {
-  lrr.SourceRegisterAddress= src;
-  lrr.DestinationRegisterAddress   = dst;
+  lrr.SourceRegisterOffset= src;
+  lrr.DestinationRegisterOffset   = dst;
}
 }
 #endif
diff --git a/src/intel/vulkan/genX_gpu_memcpy.c 
b/src/intel/vulkan/genX_gpu_memcpy.c
index 5b00b314f6f..0ef2fec53a3 100644
--- a/src/intel/vulkan/genX_gpu_memcpy.c
+++ b/src/intel/vulkan/genX_gpu_memcpy.c
@@ -78,11 +78,11 @@ genX(cmd_buffer_mi_memcpy)(struct anv_cmd_buffer 
*cmd_buffer,
*/
 #define TEMP_REG 0x2440 /* GEN7_3DPRIM_BASE_VERTEX */
   anv_batch_emit(&cmd_buffer->batch, GENX(MI_LOAD_REGISTER_MEM), load) {
- load.RegisterAddress = TEMP_REG;
+ load.RegisterOffset = TEMP_REG;
  load.MemoryAddress = src_addr;
   }
   anv_batch_emit(&cmd_buffer->batch, GENX(MI_STORE_REGISTER_MEM), store) {
- store.RegisterAddress = TEMP_REG;
+ store.Register

[Mesa-dev] [PATCH v2 06/11] intel: genxml: rename output urb offset field

[Lionel Landwerlin]

"Output Read Offset" is a bit non-sensical, let's just make this match
"Output Length".

Signed-off-by: Lionel Landwerlin 
---
 src/intel/genxml/gen10.xml| 6 +++---
 src/intel/genxml/gen8.xml | 6 +++---
 src/intel/genxml/gen9.xml | 6 +++---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 5bb46f819a8..d94c6e4ecc2 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -1447,7 +1447,7 @@
 
 
 
-
+
 
 
 
@@ -1653,7 +1653,7 @@
 
 
 
-
+
 
 
 
@@ -2669,7 +2669,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 7ccb8046796..4511e3d3749 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -1349,7 +1349,7 @@
 
 
 
-
+
 
 
 
@@ -1511,7 +1511,7 @@
 
 
 
-
+
 
 
 
@@ -2353,7 +2353,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index db4b608f61f..87fff9e7ba0 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -1411,7 +1411,7 @@
 
 
 
-
+
 
 
 
@@ -1617,7 +1617,7 @@
 
 
 
-
+
 
 
 
@@ -2585,7 +2585,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index b7a6cd73619..17c1e9e8421 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -2649,7 +2649,7 @@ genX(upload_gs_state)(struct brw_context *brw)
 DIV_ROUND_UP(vue_prog_data->vue_map.num_slots, 2) -
 urb_entry_write_offset;
 
- gs.VertexURBEntryOutputReadOffset = urb_entry_write_offset;
+ gs.VertexURBEntryOutputOffset = urb_entry_write_offset;
  gs.VertexURBEntryOutputLength = MAX2(urb_entry_output_length, 1);
 #endif
   }
-- 
2.15.0

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

[Mesa-dev] [PATCH v2 07/11] intel: decoder: change group_get_length() to take first dword

[Lionel Landwerlin]

This is a first step in not accessing the dwords through pointers.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/common/gen_decoder.c| 29 +--
 src/intel/common/gen_decoder.h|  2 +-
 src/intel/tools/aubinator.c   |  2 +-
 src/intel/tools/aubinator_error_decode.c  |  2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c |  2 +-
 5 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 736bfd6df16..b8f7c3c79a7 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -718,35 +718,34 @@ gen_group_find_field(struct gen_group *group, const char 
*name)
 }
 
 int
-gen_group_get_length(struct gen_group *group, const uint32_t *p)
+gen_group_get_length(struct gen_group *group, uint32_t dw0)
 {
-   uint32_t h = p[0];
-   uint32_t type = field_value(h, 29, 31);
+   uint32_t type = field_value(dw0, 29, 31);
 
switch (type) {
case 0: /* MI */ {
-  uint32_t opcode = field_value(h, 23, 28);
+  uint32_t opcode = field_value(dw0, 23, 28);
   if (opcode < 16)
  return 1;
   else
- return field_value(h, 0, 7) + 2;
+ return field_value(dw0, 0, 7) + 2;
   break;
}
 
case 2: /* BLT */ {
-  return field_value(h, 0, 7) + 2;
+  return field_value(dw0, 0, 7) + 2;
}
 
case 3: /* Render */ {
-  uint32_t subtype = field_value(h, 27, 28);
-  uint32_t opcode = field_value(h, 24, 26);
-  uint16_t whole_opcode = field_value(h, 16, 31);
+  uint32_t subtype = field_value(dw0, 27, 28);
+  uint32_t opcode = field_value(dw0, 24, 26);
+  uint16_t whole_opcode = field_value(dw0, 16, 31);
   switch (subtype) {
   case 0:
  if (whole_opcode == 0x6104 /* PIPELINE_SELECT_965 */)
 return 1;
  else if (opcode < 2)
-return field_value(h, 0, 7) + 2;
+return field_value(dw0, 0, 7) + 2;
  else
 return -1;
   case 1:
@@ -756,9 +755,9 @@ gen_group_get_length(struct gen_group *group, const 
uint32_t *p)
 return -1;
   case 2: {
  if (opcode == 0)
-return field_value(h, 0, 7) + 2;
+return field_value(dw0, 0, 7) + 2;
  else if (opcode < 3)
-return field_value(h, 0, 15) + 2;
+return field_value(dw0, 0, 15) + 2;
  else
 return -1;
   }
@@ -766,7 +765,7 @@ gen_group_get_length(struct gen_group *group, const 
uint32_t *p)
  if (whole_opcode == 0x780b)
 return 1;
  else if (opcode < 4)
-return field_value(h, 0, 7) + 2;
+return field_value(dw0, 0, 7) + 2;
  else
 return -1;
   }
@@ -805,7 +804,7 @@ iter_more_groups(const struct gen_field_iterator *iter)
 {
if (iter->group->variable) {
   return iter_group_offset_bits(iter, iter->group_iter + 1) <
-  (gen_group_get_length(iter->group, iter->p) * 32);
+  (gen_group_get_length(iter->group, iter->p[0]) * 32);
} else {
   return (iter->group_iter + 1) < iter->group->group_count ||
  iter->group->next != NULL;
@@ -978,7 +977,7 @@ gen_field_iterator_init(struct gen_field_iterator *iter,
else
   iter->field = group->next->fields;
iter->p = p;
-   iter->p_end = &p[gen_group_get_length(iter->group, iter->p)];
+   iter->p_end = &p[gen_group_get_length(iter->group, p[0])];
iter->print_colors = print_colors;
 
iter_decode_field(iter);
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 343d68b0eda..971fe04d2bd 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -56,7 +56,7 @@ struct gen_group *gen_spec_find_register(struct gen_spec 
*spec, uint32_t offset)
 struct gen_group *gen_spec_find_register_by_name(struct gen_spec *spec, const 
char *name);
 struct gen_enum *gen_spec_find_enum(struct gen_spec *spec, const char *name);
 
-int gen_group_get_length(struct gen_group *group, const uint32_t *p);
+int gen_group_get_length(struct gen_group *group, uint32_t dw0);
 const char *gen_group_get_name(struct gen_group *group);
 uint32_t gen_group_get_opcode(struct gen_group *group);
 struct gen_field *gen_group_find_field(struct gen_group *group, const char 
*name);
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 728edad37ff..a5141c34d78 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -693,7 +693,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
 
for (p = cmds; p < end; p += length) {
   inst = gen_spec_find_instruction(spec, p);
-  length = gen_group_get_length(inst, p);
+  length = gen_group_get_length(inst, p[0]);
   assert(inst == NULL || length > 0);
   length = MAX2(1, length);
   if (inst == NULL) {
diff --git a/src/intel/tools/aubinator_error_decode

[Mesa-dev] [PATCH v2 08/11] intel: decoder: change find_instruction() to take first dword

[Lionel Landwerlin]

Another step into decoupling memory access from pointers.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/common/gen_decoder.c| 4 ++--
 src/intel/common/gen_decoder.h| 2 +-
 src/intel/tools/aubinator.c   | 2 +-
 src/intel/tools/aubinator_error_decode.c  | 2 +-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index b8f7c3c79a7..7aebcef278c 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -677,13 +677,13 @@ void gen_spec_destroy(struct gen_spec *spec)
 }
 
 struct gen_group *
-gen_spec_find_instruction(struct gen_spec *spec, const uint32_t *p)
+gen_spec_find_instruction(struct gen_spec *spec, uint32_t dw0)
 {
struct hash_entry *entry;
 
hash_table_foreach(spec->commands, entry) {
   struct gen_group *command = entry->data;
-  uint32_t opcode = *p & command->opcode_mask;
+  uint32_t opcode = dw0 & command->opcode_mask;
   if (opcode == command->opcode)
  return command;
}
diff --git a/src/intel/common/gen_decoder.h b/src/intel/common/gen_decoder.h
index 971fe04d2bd..d4a5984e578 100644
--- a/src/intel/common/gen_decoder.h
+++ b/src/intel/common/gen_decoder.h
@@ -50,7 +50,7 @@ struct gen_spec *gen_spec_load_from_path(const struct 
gen_device_info *devinfo,
  const char *path);
 void gen_spec_destroy(struct gen_spec *spec);
 uint32_t gen_spec_get_gen(struct gen_spec *spec);
-struct gen_group *gen_spec_find_instruction(struct gen_spec *spec, const 
uint32_t *p);
+struct gen_group *gen_spec_find_instruction(struct gen_spec *spec, const 
uint32_t dw0);
 struct gen_group *gen_spec_find_instruction_by_name(struct gen_spec *spec, 
const char *name);
 struct gen_group *gen_spec_find_register(struct gen_spec *spec, uint32_t 
offset);
 struct gen_group *gen_spec_find_register_by_name(struct gen_spec *spec, const 
char *name);
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index a5141c34d78..bf9490e315f 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tools/aubinator.c
@@ -692,7 +692,7 @@ parse_commands(struct gen_spec *spec, uint32_t *cmds, int 
size, int engine)
struct gen_group *inst;
 
for (p = cmds; p < end; p += length) {
-  inst = gen_spec_find_instruction(spec, p);
+  inst = gen_spec_find_instruction(spec, p[0]);
   length = gen_group_get_length(inst, p[0]);
   assert(inst == NULL || length > 0);
   length = MAX2(1, length);
diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index fef85ffde1f..0881a8ef502 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -249,7 +249,7 @@ static void decode(struct gen_spec *spec,
  *reset_color = NORMAL;
   uint64_t offset = gtt_offset + 4 * (p - data);
 
-  inst = gen_spec_find_instruction(spec, p);
+  inst = gen_spec_find_instruction(spec, p[0]);
   length = gen_group_get_length(inst, p[0]);
   assert(inst == NULL || length > 0);
   length = MAX2(1, length);
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 811f8a42f1e..0f6759d55aa 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -454,7 +454,7 @@ do_batch_dump(struct brw_context *brw)
const char *reset_color  = color ? NORMAL : "";
 
for (uint32_t *p = batch_data; p < end; p += length) {
-  struct gen_group *inst = gen_spec_find_instruction(spec, p);
+  struct gen_group *inst = gen_spec_find_instruction(spec, p[0]);
   length = gen_group_get_length(inst, p[0]);
   assert(inst == NULL || length > 0);
   length = MAX2(1, length);
-- 
2.15.0

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

[Mesa-dev] [PATCH v2 09/11] intel: decoder: decouple decoding from memory pointers

[Lionel Landwerlin]

We want to introduce a reader interface for accessing memory, so that
later on we can use different ways of storing the content of the GTT
address space that don't involve a pointer to a linear buffer.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/common/gen_decoder.c| 75 ---
 src/intel/common/gen_decoder.h| 24 +++--
 src/intel/tools/aubinator.c   |  7 ++-
 src/intel/tools/aubinator_error_decode.c  | 12 +++--
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 26 +++---
 5 files changed, 108 insertions(+), 36 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index 7aebcef278c..c578824c186 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -799,12 +799,18 @@ iter_group_offset_bits(const struct gen_field_iterator 
*iter,
return iter->group->group_offset + (group_iter * iter->group->group_size);
 }
 
+uint32_t gen_read_dword_from_pointer(void *user_data, uint32_t dword_offset)
+{
+   return ((uint32_t *) user_data)[dword_offset];
+}
+
 static bool
 iter_more_groups(const struct gen_field_iterator *iter)
 {
if (iter->group->variable) {
   return iter_group_offset_bits(iter, iter->group_iter + 1) <
-  (gen_group_get_length(iter->group, iter->p[0]) * 32);
+ (gen_group_get_length(iter->group,
+   gen_read_dword(iter->reader, 0)) * 32);
} else {
   return (iter->group_iter + 1) < iter->group->group_count ||
  iter->group->next != NULL;
@@ -856,17 +862,20 @@ iter_advance_field(struct gen_field_iterator *iter)
 
 static uint64_t
 iter_decode_field_raw(struct gen_field *field,
-  const uint32_t *p,
-  const uint32_t *end)
+  uint32_t dword_offset,
+  uint32_t dword_end,
+  const struct gen_dword_reader *reader)
 {
uint64_t qw = 0;
 
if ((field->end - field->start) > 32) {
-  if ((p + 1) < end)
- qw = ((uint64_t) p[1]) << 32;
-  qw |= p[0];
+  if ((dword_offset + 1) < dword_end) {
+ qw = gen_read_dword(reader, dword_offset + 1);
+ qw <<= 32;
+  }
+  qw |= gen_read_dword(reader, dword_offset);
} else
-  qw = p[0];
+  qw = gen_read_dword(reader, dword_offset);
 
qw = field_value(qw, field->start, field->end);
 
@@ -895,8 +904,8 @@ iter_decode_field(struct gen_field_iterator *iter)
 
memset(&v, 0, sizeof(v));
 
-   v.qw = iter_decode_field_raw(iter->field,
-&iter->p[iter->dword], iter->p_end);
+   v.qw = iter_decode_field_raw(iter->field, iter->dword,
+iter->dword_end, iter->reader);
 
const char *enum_name = NULL;
 
@@ -966,7 +975,7 @@ iter_decode_field(struct gen_field_iterator *iter)
 void
 gen_field_iterator_init(struct gen_field_iterator *iter,
 struct gen_group *group,
-const uint32_t *p,
+const struct gen_dword_reader *reader,
 bool print_colors)
 {
memset(iter, 0, sizeof(*iter));
@@ -976,8 +985,9 @@ gen_field_iterator_init(struct gen_field_iterator *iter,
   iter->field = group->fields;
else
   iter->field = group->next->fields;
-   iter->p = p;
-   iter->p_end = &p[gen_group_get_length(iter->group, p[0])];
+   iter->reader = reader;
+   iter->dword_end = gen_group_get_length(iter->group,
+  gen_read_dword(reader, 0));
iter->print_colors = print_colors;
 
iter_decode_field(iter);
@@ -997,10 +1007,12 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 static void
 print_dword_header(FILE *outfile,
struct gen_field_iterator *iter,
-   uint64_t offset, uint32_t dword)
+   uint64_t offset,
+   uint32_t dword)
 {
fprintf(outfile, "0x%08"PRIx64":  0x%08x : Dword %d\n",
-   offset + 4 * dword, iter->p[dword], dword);
+   offset + 4 * dword,
+   gen_read_dword(iter->reader, dword), dword);
 }
 
 bool
@@ -1018,21 +1030,38 @@ gen_field_is_header(struct gen_field *field)
 }
 
 void gen_field_decode(struct gen_field *field,
-  const uint32_t *p, const uint32_t *end,
+  const struct gen_dword_reader *reader,
   union gen_field_value *value)
 {
+   uint32_t length = gen_group_get_length(field->parent,
+  gen_read_dword(reader, 0));
uint32_t dword = field->start / 32;
-   value->u64 = iter_decode_field_raw(field, &p[dword], end);
+   value->u64 = iter_decode_field_raw(field, dword, length, reader);
+}
+
+struct sub_struct_reader {
+   struct gen_dword_reader base;
+   const struct gen_dword_reader *reader;
+   uint32_t struct_offset;
+};
+
+static uint32_t
+read_struct_dword(void *user_data, 

[Mesa-dev] [PATCH v2 10/11] intel: decoder: add function to query shader length

[Lionel Landwerlin]

Signed-off-by: Lionel Landwerlin 
---
 src/intel/tools/disasm.c | 34 ++
 src/intel/tools/gen_disasm.h |  2 ++
 2 files changed, 36 insertions(+)

diff --git a/src/intel/tools/disasm.c b/src/intel/tools/disasm.c
index 251acd313dc..fbf4f9e8999 100644
--- a/src/intel/tools/disasm.c
+++ b/src/intel/tools/disasm.c
@@ -26,6 +26,8 @@
 #include "compiler/brw_inst.h"
 #include "compiler/brw_eu.h"
 
+#include "common/gen_decoder.h"
+
 #include "gen_disasm.h"
 
 uint64_t INTEL_DEBUG;
@@ -43,6 +45,38 @@ is_send(uint32_t opcode)
opcode == BRW_OPCODE_SENDSC );
 }
 
+uint32_t
+gen_disasm_get_assembly_size(struct gen_disasm *disasm,
+ const struct gen_dword_reader *reader)
+{
+   struct gen_device_info *devinfo = &disasm->devinfo;
+   uint32_t size = 0;
+
+   /* This loop exits when send-with-EOT or when opcode is 0 */
+   while (true) {
+  union {
+ brw_inst insn;
+ uint32_t data[sizeof(brw_inst) / sizeof(uint32_t)];
+  } data;
+  for (int i = 0; i < ARRAY_SIZE(data.data); i++)
+ data.data[i] = gen_read_dword(reader, size / 4 + i);
+
+  if (brw_inst_cmpt_control(devinfo, &data.insn)) {
+ size += 8;
+  } else {
+ size += 16;
+  }
+
+  /* Simplistic, but efficient way to terminate disasm */
+  uint32_t opcode = brw_inst_opcode(devinfo, &data.insn);
+  if (opcode == 0 || (is_send(opcode) && brw_inst_eot(devinfo, 
&data.insn))) {
+ break;
+  }
+   }
+
+   return size;
+}
+
 static int
 gen_disasm_find_end(struct gen_disasm *disasm, void *assembly, int start)
 {
diff --git a/src/intel/tools/gen_disasm.h b/src/intel/tools/gen_disasm.h
index d2764bb90b7..bf72759f410 100644
--- a/src/intel/tools/gen_disasm.h
+++ b/src/intel/tools/gen_disasm.h
@@ -31,6 +31,8 @@ extern "C" {
 struct gen_disasm;
 
 struct gen_disasm *gen_disasm_create(int pciid);
+uint32_t gen_disasm_get_assembly_size(struct gen_disasm *disasm,
+  const struct gen_dword_reader *reader);
 void gen_disasm_disassemble(struct gen_disasm *disasm,
 void *assembly, int start, FILE *out);
 
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

[Dylan Baker]

I haven't run the CTS tests, but both the deqp and the piglit test pass on my
skl with Marek's patches applied.

Dylan

Quoting Marek Olšák (2017-10-31 18:16:51)
> This is how I run piglit on i965:
> WAFFLE_GBM_DEVICE=/dev/dri/renderD128 PIGLIT_PLATFORM=gbm 
> piglit/bin/glinfo|head
> GL_RENDERER = Mesa DRI Intel(R) Ivybridge Desktop
> 
> Of course I have Radeon as my main GPU.
> 
> Marek
> 
> On Wed, Nov 1, 2017 at 12:52 AM, Mark Janes  wrote:
> > No, please don't.  We can't have thousands of failures added to CI.
> >
> > Dylan, can you double check this for Marek?  I'm surprised that it
> > doesn't reproduce for him.
> >
> > -Mark
> >
> > Marek Olšák  writes:
> >
> >> I can't reproduce the issue on my IVB. How about I just push this and
> >> you guys fix i965 when you have time?
> >>
> >> Marek
> >>
> >> On Thu, Oct 26, 2017 at 5:46 PM, Mark Janes  wrote:
> >>> That fixed many issues, but:
> >>>
> >>> On deqp EGL tests, we get:
> >>>
> >>> dEQP-EGL.functional.create_context_ext.gl_42.rgba_no_depth_no_stencil
> >>> deqp-egl: main/api_exec.c:135: _mesa_initialize_exec_table: Assertion 
> >>> `ctx->Version > 0' failed.
> >>>
> >>> On ES31 CTS tests:
> >>> ES31-CTS.functional.texture.texture_buffer.render.as_vertex_array_as_vertex_texture_as_fragment_texture.range_size_513
> >>> glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
> >>> gluContextInfo.cpp:229
> >>>
> >>> on GL46 CTS (27 failures):
> >>> src/mesa/main/teximage.c:595: _mesa_tex_target_is_layered: Assertion
> >>> `!"Invalid texture target."' failed.
> >>>
> >>> Piglit fails 3.5k tests with the same `ctx->Version > 0' assertion as
> >>> deqp-egl.
> >>>
> >>> -Mark
> >>>
> >>> Dylan Baker  writes:
> >>>
>  I've pushed it to our CI, I'll let you know tomorrow what it looks like
> 
>  Dylan
> 
>  Quoting Marek Olšák (2017-10-25 19:52:43)
> > Hi Dylan,
> >
> > Can you please add this and re-test?
> >
> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
> > b/src/mesa/drivers/
> > dri/i965/intel_extensions.c
> > index 21cf632..4d17393 100644
> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
> > @@ -178,7 +178,7 @@ intelInitExtensions(struct gl_context *ctx)
> >ctx->Extensions.ARB_pipeline_statistics_query = true;
> >ctx->Extensions.ARB_sample_shading = true;
> >ctx->Extensions.ARB_shading_language_420pack = true;
> > -  if (ctx->API == API_OPENGL_CORE) {
> > +  if (ctx->API != API_OPENGL_COMPAT) {
> >   ctx->Extensions.ARB_texture_buffer_object = true;
> >   ctx->Extensions.ARB_texture_buffer_object_rgb32 = true;
> >   ctx->Extensions.ARB_texture_buffer_range = true;
> >
> >
> > Marek
> >
> > On Wed, Oct 25, 2017 at 11:42 PM, Dylan Baker 
> >  wrote:
> >
> > There are a significant number of i965 regressions from
> > d96c68146a781c79a23f5181d7050174f1070d90, largely related to 
> > texturing (I
> > can
> > send you a complete list of regressions if you care, but due to the 
> > large
> > number
> > of them I suspect it's something fairly simple).
> >
> > For example:
> > ES31-CTS.functional.texture.format.buffer.r32ui_npot
> >
> > glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
> > gluContextInfo.cpp:229
> >
> > dEQP-GLES31.functional.state_query.integer.texture_buffer_
> > binding_getinteger:
> >
> > glGetIntegerv(GL_TEXTURE_BUFFER_BINDING, 0x7ffee0c43834);
> > // data = { -555819298 }
> > glGetError();
> > // GL_INVALID_ENUM returned
> >  // ERROR: glGetIntegerv: glGetError() returned GL_INVALID_ENUM
> >
> > Dylan
> >
> > Quoting Emil Velikov (2017-10-24 09:30:03)
> > > Hi Marek,
> > >
> > > On 21 October 2017 at 13:54, Marek Olšák  wrote:
> > > > From: Marek Olšák 
> > > >
> > > > We already have piglit tests testing alpha, luminance, and 
> > intensity
> > > > formats. They were skipped by piglit until now.
> > > >
> > > > Additionally, I'm enabling one ARB_texture_buffer_range piglit 
> > test to
> > run
> > > > with the compat profile.
> > >
> > > Can you please mention that ARB_texture_buffer_* on i965 is 
> > unchanged
> > > - aka still enabled only for core profiles.
> > > Out of curiosity - can you tried the series with anything more 
> > than
> > piglit?
> > >
> > > The Intel guys can run the lot through CTS, dEQP... admittedly 
> > only on
> > > Intel hardware.
> > > Still it should help catch if a piece is missing somewhere.
> > >
> > >
> > > -Emil
> > > _

Re: [Mesa-dev] [PATCH] etnaviv: bugfix: Don't do resolve-in-place without valid TS

[Chris Healy]

Tested-by: Chris Healy 

I tested this with i.MX6qp (and i.MX6q) and found that the rendering
issues I experienced with Wayland/Weston and the i.MX6qp went away
with this patch applied.

Also, I ran glmark2-es2-drm and saw no regressions.

On Wed, Nov 1, 2017 at 3:17 AM, Wladimir J. van der Laan
 wrote:
> GC3000 resolve-in-place assumes that the TS state is configured.
> If it is not, this will result in MMU errors. This is especially
> apparent when using glGenMipmaps().
>
> Fixes a problem introduced in 78ade659569ee6fe9bd244170956139f19dd8c6c.
>
> Signed-off-by: Wladimir J. van der Laan 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_clear_blit.c | 4 
>  src/gallium/drivers/etnaviv/etnaviv_emit.c   | 4 
>  src/gallium/drivers/etnaviv/etnaviv_rs.c | 1 +
>  src/gallium/drivers/etnaviv/etnaviv_rs.h | 2 ++
>  4 files changed, 11 insertions(+)
>
> Ooops. This seems like an obvious oversight but I hadn't thought we would get
> into this path at all when there is no TS to "flush".
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> index c62287b..8fc7cfc 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_clear_blit.c
> @@ -555,6 +555,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
> }
>
> /* Set up color TS to source surface before blit, if needed */
> +   bool source_ts_valid = false;
> if (src->levels[blit_info->src.level].ts_size &&
> src->levels[blit_info->src.level].ts_valid) {
>struct etna_reloc reloc;
> @@ -579,6 +580,8 @@ etna_try_rs_blit(struct pipe_context *pctx,
>
>etna_set_state(ctx->stream, VIVS_TS_COLOR_CLEAR_VALUE,
>   src->levels[blit_info->src.level].clear_value);
> +
> +  source_ts_valid = true;
> } else {
>etna_set_state(ctx->stream, VIVS_TS_MEM_CONFIG, ts_mem_config);
> }
> @@ -593,6 +596,7 @@ etna_try_rs_blit(struct pipe_context *pctx,
>.source_stride = src_lev->stride,
>.source_padded_width = src_lev->padded_width,
>.source_padded_height = src_lev->padded_height,
> +  .source_ts_valid = source_ts_valid,
>.dest_format = translate_rs_format(dst_format),
>.dest_tiling = dst->layout,
>.dest = dst->bo,
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_emit.c 
> b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> index 707b1e7..5397aa3 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_emit.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_emit.c
> @@ -171,6 +171,10 @@ etna_submit_rs_state(struct etna_context *ctx,
> struct etna_cmd_stream *stream = ctx->stream;
> struct etna_coalesce coalesce;
>
> +   if (cs->RS_KICKER_INPLACE && !cs->source_ts_valid)
> +  /* Inplace resolve is no-op if TS is not configured */
> +  return;
> +
> ctx->stats.rs_operations++;
>
> if (cs->RS_KICKER_INPLACE) {
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.c 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> index c9072c2..60c2c39 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.c
> @@ -133,6 +133,7 @@ etna_compile_rs_state(struct etna_context *ctx, struct 
> compiled_rs_state *cs,
>/* Total number of tiles (same as for autodisable) */
>cs->RS_KICKER_INPLACE = rs->source_padded_width * 
> rs->source_padded_height / 16;
> }
> +   cs->source_ts_valid = rs->source_ts_valid;
>  }
>
>  void
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_rs.h 
> b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> index 171d3fa..41a5960 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_rs.h
> +++ b/src/gallium/drivers/etnaviv/etnaviv_rs.h
> @@ -33,6 +33,7 @@
>  struct rs_state {
> uint8_t downsample_x : 1; /* Downsample in x direction */
> uint8_t downsample_y : 1; /* Downsample in y direction */
> +   uint8_t source_ts_valid : 1;
>
> uint8_t source_format; /* RS_FORMAT_XXX */
> uint8_t source_tiling; /* ETNA_LAYOUT_XXX */
> @@ -61,6 +62,7 @@ struct rs_state {
>
>  /* treat this as opaque structure */
>  struct compiled_rs_state {
> +   uint8_t source_ts_valid : 1;
> uint32_t RS_CONFIG;
> uint32_t RS_SOURCE_STRIDE;
> uint32_t RS_DEST_STRIDE;
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] meson: Allow building glvnd with EGL and non-dri based GLX

[Dylan Baker]

Quoting Emil Velikov (2017-11-01 10:41:10)
> On 1 November 2017 at 17:24, Dylan Baker  wrote:
> > Because meson mirrors the auototools logic, it needs the same changes to
> > allow building glvnd based egl.
> >
> > v2: - change if to elif (Eric)
> >
> > Signed-off-by: Dylan Baker 
> > Reviewed-by: Eric Engestrom 
> Thanks for the correction/fixup Dylan. FWIW
> Acked-by: Emil Velikov 
> 
> This should be fine to land regardless of the autotools commit.
> I'll push those in the morning - don't want to risk breaking $world by
> pushing at 7:30pm :-\
> 
> -Emil

No worries, I don't see any pressing reason to push this by itself, so why don't
you just push the meson patch with the autotools patch, that way the behavior of
the two build systems stays in step.

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 2/2] i965/miptree: Use format_ccs_compat_with_miptree for textures

[Nanley Chery]

On Wed, Nov 01, 2017 at 10:58:03AM -0700, Jason Ekstrand wrote:
> On Wed, Nov 1, 2017 at 10:46 AM, Nanley Chery  wrote:
> 
> > On Tue, Oct 31, 2017 at 08:01:05PM -0700, Jason Ekstrand wrote:
> > > This function is a bit more accurate because it lets us sample from sRGB
> > > textures if sRGB decode is off.  This should improve performance in
> >   ^ ^
> >  missing "with CCS_E"?   extra
> > word?
> >
> 
> Yup.  Commit message improved:
> 
> Using this function is a bit more accurate because it lets us sample
> from sRGB textures with CCS_E whenever sRGB decode is disabled.  The
> old check for CCS_E compatibility would bail if the miptree's native
> format were sRGB even if the view format is linear.  This should improve
> performance whenever GL_SKIP_DECODE_EXT is used.
> 
> 
> 

Nice!

> >
> > > whenever GL_SKIP_DECODE_EXT is used.
> > > ---
> > >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > index 82f5a81..835d7ae 100644
> > > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> > > @@ -2566,9 +2566,8 @@ can_texture_with_ccs(struct brw_context *brw,
> > > if (mt->aux_usage != ISL_AUX_USAGE_CCS_E)
> > >return false;
> > >
> > > -   /* TODO: Replace with format_ccs_e_compat_with_miptree for better
> > perf. */
> > > -   if (!isl_formats_are_ccs_e_compatible(&brw->screen->devinfo,
> > > - mt->surf.format, view_format))
> > {
> > > +   if (!format_ccs_e_compat_with_miptree(&brw->screen->devinfo,
> > > + mt, view_format)) {
> > >perf_debug("Incompatible sampling format (%s) for rbc (%s)\n",
> > >   isl_format_get_layout(view_format)->name,
> > >   _mesa_get_format_name(mt->format));
> >
> > Do we want to update this perf_debug to return the linear format of the
> > miptree
> >
> 
> I don't know that it matters much since it's just a perf debug.  I think
> I'd prefer we leave it as-is because right now it tells us the exact
> miptree format not some format calculated from it.

Yeah, that's what I was leaning towards as well.

This patch is
Reviewed-by: Nanley Chery 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] etnaviv: Allow clearing constant buffer using buffer==NULL user_buffer==NULL

[Wladimir J. van der Laan]

On Wed, Nov 01, 2017 at 02:27:40PM +0100, Lucas Stach wrote:
> Am Montag, den 30.10.2017, 17:14 +0100 schrieb Wladimir J. van der Laan:
> > On Mon, Oct 30, 2017 at 02:21:07PM +0100, Lucas Stach wrote:
> > > I would prefer the shorter expression (!cb->buffer && !cb->user_buffer) 
> > > here, which seems more consistent with the rest of the codebase.
> > 
> > Well, I mimiced the style from other assertion in the function which 
> > compares
> > explicitly with NULL. But ok, I'll update it some time.
> 
> If you agree with my suggestion I can also just fix it up while
> applying, but I'll leave the decision how you want to handle this up to
> you.

Feel free to do so while applying - I don't mind how it's solved really, it's
just useful to not have this crash :)

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

Re: [Mesa-dev] create src/wsi

[Dylan Baker]

Quoting Eric Engestrom (2017-11-01 07:05:02)
> On Friday, 2017-10-20 18:00:13 -0700, Dylan Baker wrote:
> > This very short series creates a new src/wsi folder, and moves wayland-drm 
> > into
> > it. Basically wsi stuff is scattered about, and is needed by multiple 
> > components
> > within mesa, wayland-drm, for example, is used by EGL, GBM, and vulkan
> > wayland-wsi.
> > 
> > I think there's more that could be moved into wsi, we could move EGL, GBM, 
> > and
> > GLX, and vulkan/wsi, for example.
> 
> The patches themselves are
> Reviewed-by: Eric Engestrom 
> 
> (and 1 & 2 should land regardless of the discussion on 3)
> 
> I'm a bit weary of the move as well, as it makes history harder to
> follow (eg. log and blame) and will likely break some scripts.
> No actual objection from me though.

Emil, are patches 1 & 2 okay, and we can land those and discuss 3 further?

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 2/2] etnaviv: ASTC texture support

[Christian Gmeiner]

Am 01.11.2017 7:06 nachm. schrieb "Wladimir J. van der Laan" <
laa...@gmail.com>:

On Wed, Nov 01, 2017 at 06:38:21PM +0100, Christian Gmeiner wrote:

> I would love to see a new format helper (util_format_is_astc(..) and not
> even start thinking about adding a new format bit (ASTC_FORMAT).

These formats are in a completely different space from the others, in the
hardware (programmed through a different register), so IMO it makes sense to
add a new format bit for it, just like for EXT_FORMAT.

Relying on mesa's judgement on whether something is astc seems brittle.


Sorry I do not share this option. Did you had a look at
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/util/u_
format.csv ?

All astc formats are marked as those and why should we not trust mesa here?
Such helper could look like:  https://hastebin.com/jelisigife.m

Do we need ctx->specs.tex_astc at all? We could simply do it like this in
etnaviv_screen.c:

if (util_format_is_astc(format))
  supported = VIV_FEATURE(screen, chipMinorFeatures4, TEXTURE_ASTC);


I am still on travel but will share you tomorrow evening how I think this
should look like.

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

[Mesa-dev] [PATCH] meson: Add script to use VERSION file for getting version

[Dylan Baker]

Meson has up until this point set it's version in the root meson.build
script. While there are other build systems them creates "one more
thing" to duplicate between meson and every other build system, this
script is a simple "read, strip, print" sort of deal to allow meson to
read the VERSION file.

I chose to implement this in python since python is portable, and to
keep the meson.build script clean. This is also complicated by the fact
that the project() call *must* be the first non-comment,non-blank in the
toplevel meson.build script.

Signed-off-by: Dylan Baker 
---
 meson.build  |  2 +-
 scripts/meson_get_version.py | 35 +++
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 scripts/meson_get_version.py

diff --git a/meson.build b/meson.build
index 6ad8c8bbf4b..3f77380f7df 100644
--- a/meson.build
+++ b/meson.build
@@ -21,7 +21,7 @@
 project(
   'mesa',
   ['c', 'cpp'],
-  version : '17.3.0-devel',
+  version : run_command(find_program('scripts/meson_get_version.py')).stdout(),
   license : 'MIT',
   meson_version : '>= 0.42',
   default_options : ['c_std=c99', 'cpp_std=c++11']
diff --git a/scripts/meson_get_version.py b/scripts/meson_get_version.py
new file mode 100644
index 000..a221e26f250
--- /dev/null
+++ b/scripts/meson_get_version.py
@@ -0,0 +1,35 @@
+#!/usr/bin/env python
+# encoding=utf-8
+# Copyright © 2017 Intel Corporation
+
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+# SOFTWARE.
+
+from __future__ import print_function
+import os
+
+
+def main():
+filename = os.path.join(os.environ['MESON_SOURCE_ROOT'], 'VERSION')
+with open(filename) as f:
+version = f.read().strip()
+print(version, end='')
+
+
+if __name__ == '__main__':
+main()
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 1/2] intel/fs: Alloc pull constants off mem_ctx

[Tapani Pälli]

On 11/01/2017 06:33 PM, Jason Ekstrand wrote:
Do either of you mind if I cc the first one to stable?  It does fix a 
potential memory leak in the case where compilation fails.


IMO CC stable would be fine for that one.

On Wed, Nov 1, 2017 at 9:26 AM, Tapani Pälli > wrote:


series
Reviewed-by: Tapani Pälli mailto:tapani.pa...@intel.com>>


On 11/01/2017 06:00 PM, Jason Ekstrand wrote:

It doesn't actually matter since the only user of push
constants, i965,
ralloc_steals it back to NULL but it's more consistent and probably
fixes memory leaks in some error cases.
---
   src/intel/compiler/brw_fs.cpp | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs.cpp
b/src/intel/compiler/brw_fs.cpp
index e546792..21ff030 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2095,7 +2095,7 @@ fs_visitor::assign_constant_locations()
      stage_prog_data->param = ralloc_array(mem_ctx, uint32_t,
num_push_constants);
      if (num_pull_constants > 0) {
         stage_prog_data->nr_pull_params = num_pull_constants;
-      stage_prog_data->pull_param = ralloc_array(NULL, uint32_t,
+      stage_prog_data->pull_param = ralloc_array(mem_ctx, uint32_t,
  
  num_pull_constants);

      }



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

Re: [Mesa-dev] [PATCH v3 23/43] i965/fs: Add byte scattered read message and fs support

[Jason Ekstrand]

On Thu, Oct 12, 2017 at 11:38 AM, Jose Maria Casanova Crespo <
jmcasan...@igalia.com> wrote:

> ---
>  src/intel/compiler/brw_eu.h|  7 +
>  src/intel/compiler/brw_eu_defines.h|  2 ++
>  src/intel/compiler/brw_eu_emit.c   | 41
> ++
>  src/intel/compiler/brw_fs.cpp  | 10 +++
>  src/intel/compiler/brw_fs_copy_propagation.cpp |  2 ++
>  src/intel/compiler/brw_fs_generator.cpp|  5 
>  src/intel/compiler/brw_fs_surface_builder.cpp  | 12 
>  src/intel/compiler/brw_fs_surface_builder.h|  5 
>  src/intel/compiler/brw_shader.cpp  |  6 
>  9 files changed, 90 insertions(+)
>
> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
> index b44ca0f518..ca1ff21a83 100644
> --- a/src/intel/compiler/brw_eu.h
> +++ b/src/intel/compiler/brw_eu.h
> @@ -476,6 +476,13 @@ brw_typed_surface_write(struct brw_codegen *p,
>  unsigned num_channels);
>
>  void
> +brw_byte_scattered_read(struct brw_codegen *p,
> +struct brw_reg dst,
> +struct brw_reg payload,
> +struct brw_reg surface,
> +unsigned msg_length);
> +
> +void
>  brw_byte_scattered_write(struct brw_codegen *p,
>   struct brw_reg payload,
>   struct brw_reg surface,
> diff --git a/src/intel/compiler/brw_eu_defines.h
> b/src/intel/compiler/brw_eu_defines.h
> index 9aac385ba7..c5dc5fd5fb 100644
> --- a/src/intel/compiler/brw_eu_defines.h
> +++ b/src/intel/compiler/brw_eu_defines.h
> @@ -397,6 +397,8 @@ enum opcode {
>  * opcode, but instead of taking a single payload blog they expect
> their
>  * arguments separately as individual sources, like untyped write/read.
>  */
> +   SHADER_OPCODE_BYTE_SCATTERED_READ,
> +   SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL,
> SHADER_OPCODE_BYTE_SCATTERED_WRITE,
> SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL,
>
> diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_
> emit.c
> index 84d85be653..8c83d8b500 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -2929,6 +2929,47 @@ brw_untyped_surface_write(struct brw_codegen *p,
>p, insn, num_channels);
>  }
>
> +
> +
> +static void
> +brw_set_dp_byte_scattered_read_message(struct brw_codegen *p,
> +   struct brw_inst *insn)
> +{
> +
> +   const struct gen_device_info *devinfo = p->devinfo;
> +   /* Set mask of 32-bit channels to drop. */
> +   unsigned msg_control = GEN7_BYTE_SCATTERED_DATA_SIZE_WORD << 2;
> +
> +   if (brw_inst_access_mode(devinfo, p->current) == BRW_ALIGN_1) {
> +  if (brw_inst_exec_size(devinfo, p->current) == BRW_EXECUTE_16)
> + msg_control |= 1; /* SIMD16 mode */
> +  else
> + msg_control |= 2; /* SIMD8 mode */
>

Is this really supposed to be 2?  From my reading of the BDW docs, it looks
like you want 1 and 0.  2 gives you 0 in the SIMD mode bit (which indicates
SIMD8) and a 1 in a reserved MBZ bit.


> +   }
>

I think we probably want an else unreachable here.  Also, we want that for
scattered_write.


> +
> +   brw_inst_set_dp_msg_type(devinfo, insn,
> +(devinfo->gen >= 8 || devinfo->is_haswell ?
> + HSW_DATAPORT_DC_PORT0_BYTE_SCATTERED_READ :
> + GEN7_DATAPORT_DC_BYTE_SCATTERED_READ));
> +   brw_inst_set_dp_msg_control(devinfo, insn, msg_control);
> +}
> +
> +void
> +brw_byte_scattered_read(struct brw_codegen *p,
> +struct brw_reg dst,
> +struct brw_reg payload,
> +struct brw_reg surface,
> +unsigned msg_length)
> +{
> +   const unsigned sfid =  GEN7_SFID_DATAPORT_DATA_CACHE;
> +   struct brw_inst *insn = brw_send_indirect_scattered_message(
> +  p, sfid, dst, payload, surface, msg_length,
> +  brw_surface_payload_size(p, 1, true, true),
> +  false);
> +
> +   brw_set_dp_byte_scattered_read_message(p, insn);
>

Again, I think we can inline this


> +}
> +
>  static void
>  brw_set_dp_byte_scattered_write(struct brw_codegen *p,
>  struct brw_inst *insn)
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index e4a94ff053..bd0d32b741 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -251,6 +251,7 @@ fs_inst::is_send_from_grf() const
> case SHADER_OPCODE_UNTYPED_SURFACE_READ:
> case SHADER_OPCODE_UNTYPED_SURFACE_WRITE:
> case SHADER_OPCODE_BYTE_SCATTERED_WRITE:
> +   case SHADER_OPCODE_BYTE_SCATTERED_READ:
> case SHADER_OPCODE_TYPED_ATOMIC:
> case SHADER_OPCODE_TYPED_SURFACE_READ:
> case SHADER_OPCODE_TYPED_SURFACE_WRITE:
> @@ -733,6 +734,7 @@ fs_inst::components_read(unsigned i) const
>
> case SHADER_

Re: [Mesa-dev] [PATCH v3 23/43] i965/fs: Add byte scattered read message and fs support

[Jason Ekstrand]

On Wed, Nov 1, 2017 at 12:09 PM, Jason Ekstrand 
wrote:

> On Thu, Oct 12, 2017 at 11:38 AM, Jose Maria Casanova Crespo <
> jmcasan...@igalia.com> wrote:
>
>> ---
>>  src/intel/compiler/brw_eu.h|  7 +
>>  src/intel/compiler/brw_eu_defines.h|  2 ++
>>  src/intel/compiler/brw_eu_emit.c   | 41
>> ++
>>  src/intel/compiler/brw_fs.cpp  | 10 +++
>>  src/intel/compiler/brw_fs_copy_propagation.cpp |  2 ++
>>  src/intel/compiler/brw_fs_generator.cpp|  5 
>>  src/intel/compiler/brw_fs_surface_builder.cpp  | 12 
>>  src/intel/compiler/brw_fs_surface_builder.h|  5 
>>  src/intel/compiler/brw_shader.cpp  |  6 
>>  9 files changed, 90 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
>> index b44ca0f518..ca1ff21a83 100644
>> --- a/src/intel/compiler/brw_eu.h
>> +++ b/src/intel/compiler/brw_eu.h
>> @@ -476,6 +476,13 @@ brw_typed_surface_write(struct brw_codegen *p,
>>  unsigned num_channels);
>>
>>  void
>> +brw_byte_scattered_read(struct brw_codegen *p,
>> +struct brw_reg dst,
>> +struct brw_reg payload,
>> +struct brw_reg surface,
>> +unsigned msg_length);
>> +
>> +void
>>  brw_byte_scattered_write(struct brw_codegen *p,
>>   struct brw_reg payload,
>>   struct brw_reg surface,
>> diff --git a/src/intel/compiler/brw_eu_defines.h
>> b/src/intel/compiler/brw_eu_defines.h
>> index 9aac385ba7..c5dc5fd5fb 100644
>> --- a/src/intel/compiler/brw_eu_defines.h
>> +++ b/src/intel/compiler/brw_eu_defines.h
>> @@ -397,6 +397,8 @@ enum opcode {
>>  * opcode, but instead of taking a single payload blog they expect
>> their
>>  * arguments separately as individual sources, like untyped
>> write/read.
>>  */
>> +   SHADER_OPCODE_BYTE_SCATTERED_READ,
>> +   SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL,
>> SHADER_OPCODE_BYTE_SCATTERED_WRITE,
>> SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL,
>>
>> diff --git a/src/intel/compiler/brw_eu_emit.c
>> b/src/intel/compiler/brw_eu_emit.c
>> index 84d85be653..8c83d8b500 100644
>> --- a/src/intel/compiler/brw_eu_emit.c
>> +++ b/src/intel/compiler/brw_eu_emit.c
>> @@ -2929,6 +2929,47 @@ brw_untyped_surface_write(struct brw_codegen *p,
>>p, insn, num_channels);
>>  }
>>
>> +
>> +
>> +static void
>> +brw_set_dp_byte_scattered_read_message(struct brw_codegen *p,
>> +   struct brw_inst *insn)
>> +{
>> +
>> +   const struct gen_device_info *devinfo = p->devinfo;
>> +   /* Set mask of 32-bit channels to drop. */
>> +   unsigned msg_control = GEN7_BYTE_SCATTERED_DATA_SIZE_WORD << 2;
>>
>
As I commented before, I don't think we want to make this assumption.


> +
>> +   if (brw_inst_access_mode(devinfo, p->current) == BRW_ALIGN_1) {
>> +  if (brw_inst_exec_size(devinfo, p->current) == BRW_EXECUTE_16)
>> + msg_control |= 1; /* SIMD16 mode */
>> +  else
>> + msg_control |= 2; /* SIMD8 mode */
>>
>
> Is this really supposed to be 2?  From my reading of the BDW docs, it
> looks like you want 1 and 0.  2 gives you 0 in the SIMD mode bit (which
> indicates SIMD8) and a 1 in a reserved MBZ bit.
>
>
>> +   }
>>
>
> I think we probably want an else unreachable here.  Also, we want that for
> scattered_write.
>
>
>> +
>> +   brw_inst_set_dp_msg_type(devinfo, insn,
>> +(devinfo->gen >= 8 || devinfo->is_haswell ?
>> + HSW_DATAPORT_DC_PORT0_BYTE_SCATTERED_READ :
>> + GEN7_DATAPORT_DC_BYTE_SCATTERED_READ));
>> +   brw_inst_set_dp_msg_control(devinfo, insn, msg_control);
>> +}
>> +
>> +void
>> +brw_byte_scattered_read(struct brw_codegen *p,
>> +struct brw_reg dst,
>> +struct brw_reg payload,
>> +struct brw_reg surface,
>> +unsigned msg_length)
>> +{
>> +   const unsigned sfid =  GEN7_SFID_DATAPORT_DATA_CACHE;
>> +   struct brw_inst *insn = brw_send_indirect_scattered_message(
>> +  p, sfid, dst, payload, surface, msg_length,
>> +  brw_surface_payload_size(p, 1, true, true),
>> +  false);
>> +
>> +   brw_set_dp_byte_scattered_read_message(p, insn);
>>
>
> Again, I think we can inline this
>
>
>> +}
>> +
>>  static void
>>  brw_set_dp_byte_scattered_write(struct brw_codegen *p,
>>  struct brw_inst *insn)
>> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cp
>> p
>> index e4a94ff053..bd0d32b741 100644
>> --- a/src/intel/compiler/brw_fs.cpp
>> +++ b/src/intel/compiler/brw_fs.cpp
>> @@ -251,6 +251,7 @@ fs_inst::is_send_from_grf() const
>> case SHADER_OPCODE_UNTYPED_SURFACE_READ:
>> case SHADER_OPCODE_UNTYPED_SURFACE_WRITE:
>> case SHADER_OPCODE_BYTE_SCA

[Mesa-dev] [PATCH] gallivm: allow arch rounding with avx512

[Tim Rowley]

Fixes piglit vs-roundeven-{float,vec[234]} with simd16 VS.
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index cf1958b3b6..a1edd349f1 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -1953,7 +1953,8 @@ arch_rounding_available(const struct lp_type type)
 {
if ((util_cpu_caps.has_sse4_1 &&
(type.length == 1 || type.width*type.length == 128)) ||
-   (util_cpu_caps.has_avx && type.width*type.length == 256))
+   (util_cpu_caps.has_avx && type.width*type.length == 256) ||
+   (util_cpu_caps.has_avx512f && type.width*type.length == 512))
   return TRUE;
else if ((util_cpu_caps.has_altivec &&
 (type.width == 32 && type.length == 4)))
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] gallivm: allow arch rounding with avx512

[Roland Scheidegger]

Looks good to me.
Albeit I think there's quite a few more places which probably should
handle avx512...

Reviewed-by: Roland Scheidegger 

Am 01.11.2017 um 20:17 schrieb Tim Rowley:
> Fixes piglit vs-roundeven-{float,vec[234]} with simd16 VS.
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_arit.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index cf1958b3b6..a1edd349f1 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -1953,7 +1953,8 @@ arch_rounding_available(const struct lp_type type)
>  {
> if ((util_cpu_caps.has_sse4_1 &&
> (type.length == 1 || type.width*type.length == 128)) ||
> -   (util_cpu_caps.has_avx && type.width*type.length == 256))
> +   (util_cpu_caps.has_avx && type.width*type.length == 256) ||
> +   (util_cpu_caps.has_avx512f && type.width*type.length == 512))
>return TRUE;
> else if ((util_cpu_caps.has_altivec &&
>  (type.width == 32 && type.length == 4)))
> 

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

Re: [Mesa-dev] [PATCH 2/2] etnaviv: ASTC texture support

[Wladimir J. van der Laan]

> These formats are in a completely different space from the others, in the
> hardware (programmed through a different register), so IMO it makes sense to
> add a new format bit for it, just like for EXT_FORMAT.
> 
> Relying on mesa's judgement on whether something is astc seems brittle.
> 
> 
> Sorry I do not share this option. Did you had a look at
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/util/u_
> format.csv ?
> 
> All astc formats are marked as those and why should we not trust mesa here?

Well vivante's opinion of what an ASTC format might differ from mesa's
some day. I think we should keep specific implementation details
such as what register switches formats contained to our driver.
This keeps etnaviv_format.c self-contained.

It's not like we're running out of bits or something. I really disagree
with calling into mesa for this, at least in the sampler view code.

> Such helper could look like:  https://hastebin.com/jelisigife.m
> 
> Do we need ctx->specs.tex_astc at all? We could simply do it like this in
> etnaviv_screen.c:
> 
> if (util_format_is_astc(format))
>   supported = VIV_FEATURE(screen, chipMinorFeatures4, TEXTURE_ASTC);

It's also using this in the state emit code, where directly calling into
VIV_FEATURE is ugly.

Also, some GPUs seem to have TEXTURE_ASTC but broken ASTC (such as the 
GC7000lite)
so this logic must be extended some day. Having a specs bit is easier
for that.

(also, vivante is doing away with feature bits on newer GPUs; we're
going to have our own model->specs mapping database like them at some point)

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

Re: [Mesa-dev] [PATCH 2/2] etnaviv: ASTC texture support

[Ilia Mirkin]

On Wed, Nov 1, 2017 at 3:32 PM, Wladimir J. van der Laan
 wrote:
>
>> These formats are in a completely different space from the others, in the
>> hardware (programmed through a different register), so IMO it makes sense to
>> add a new format bit for it, just like for EXT_FORMAT.
>>
>> Relying on mesa's judgement on whether something is astc seems brittle.
>>
>>
>> Sorry I do not share this option. Did you had a look at
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/util/u_
>> format.csv ?
>>
>> All astc formats are marked as those and why should we not trust mesa here?
>
> Well vivante's opinion of what an ASTC format might differ from mesa's
> some day. I think we should keep specific implementation details

These aren't supported today in gallium (due to no hw support), but be
aware that there are 3D ASTC formats, which would likely be considered
to be "astc" by an updated util_format_is_astc().

Most drivers have an explicit list of formats they support though, so
if it's just for code that processes already-validated formats, it
shouldn't be a problem to use util_format_is_astc() since you know
that it must be a format that is in the table already.

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

[Mesa-dev] [PATCH] radv: Don't expose heaps with 0 memory.

[Bas Nieuwenhuizen]

It confuses CTS. This pregenerates the heap info into the
physical device, so we can use it for translating contiguous
indices into our "standard" ones.

This also makes the WSI a bit smarter in case the first preferred
heap does not exist.

CC: 
---
 src/amd/vulkan/radv_device.c  | 135 ++
 src/amd/vulkan/radv_private.h |   3 +
 src/amd/vulkan/radv_wsi.c |  16 -
 3 files changed, 101 insertions(+), 53 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 0c2f6fa6312..e95f3ee32af 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -104,6 +104,75 @@ get_chip_name(enum radeon_family family)
}
 }
 
+static void
+radv_physical_device_init_mem_types(struct radv_physical_device *device)
+{
+   STATIC_ASSERT(RADV_MEM_HEAP_COUNT <= VK_MAX_MEMORY_HEAPS);
+   uint64_t visible_vram_size = MIN2(device->rad_info.vram_size,
+ device->rad_info.vram_vis_size);
+
+   int vram_index = -1, visible_vram_index = -1, gart_index = -1;
+   device->memory_properties.memoryHeapCount = 0;
+   if (device->rad_info.vram_size - visible_vram_size > 0) {
+   vram_index = device->memory_properties.memoryHeapCount++;
+   device->memory_properties.memoryHeaps[vram_index] = 
(VkMemoryHeap) {
+   .size = device->rad_info.vram_size - visible_vram_size,
+   .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
+   };
+   }
+   if (visible_vram_size) {
+   visible_vram_index = 
device->memory_properties.memoryHeapCount++;
+   device->memory_properties.memoryHeaps[visible_vram_index] = 
(VkMemoryHeap) {
+   .size = visible_vram_size,
+   .flags = VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
+   };
+   }
+   if (device->rad_info.gart_size > 0) {
+   gart_index = device->memory_properties.memoryHeapCount++;
+   device->memory_properties.memoryHeaps[gart_index] = 
(VkMemoryHeap) {
+   .size = device->rad_info.gart_size,
+   .flags = 0,
+   };
+   }
+
+   STATIC_ASSERT(RADV_MEM_TYPE_COUNT <= VK_MAX_MEMORY_TYPES);
+   unsigned type_count = 0;
+   if (vram_index >= 0) {
+   device->mem_type_indices[type_count] = RADV_MEM_TYPE_VRAM;
+   device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
+   .propertyFlags = VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT,
+   .heapIndex = vram_index,
+   };
+   }
+   if (gart_index >= 0) {
+   device->mem_type_indices[type_count] = 
RADV_MEM_TYPE_GTT_WRITE_COMBINE;
+   device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
+   .propertyFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
+   VK_MEMORY_PROPERTY_HOST_COHERENT_BIT,
+   .heapIndex = gart_index,
+   };
+   }
+   if (visible_vram_index >= 0) {
+   device->mem_type_indices[type_count] = 
RADV_MEM_TYPE_VRAM_CPU_ACCESS;
+   device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
+   .propertyFlags = VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT |
+   VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
+   VK_MEMORY_PROPERTY_HOST_COHERENT_BIT,
+   .heapIndex = visible_vram_index,
+   };
+   }
+   if (gart_index >= 0) {
+   device->mem_type_indices[type_count] = RADV_MEM_TYPE_GTT_CACHED;
+   device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
+   .propertyFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
+   VK_MEMORY_PROPERTY_HOST_COHERENT_BIT |
+   VK_MEMORY_PROPERTY_HOST_CACHED_BIT,
+   .heapIndex = gart_index,
+   };
+   }
+   device->memory_properties.memoryTypeCount = type_count;
+}
+
 static VkResult
 radv_physical_device_init(struct radv_physical_device *device,
  struct radv_instance *instance,
@@ -190,6 +259,7 @@ radv_physical_device_init(struct radv_physical_device 
*device,
 */
device->has_clear_state = device->rad_info.chip_class >= CIK;
 
+   radv_physical_device_init_mem_types(device);
return VK_SUCCESS;
 
 fail:
@@ -780,49 +850,7 @@ void radv_GetPhysicalDeviceMemoryProperties(
 {
RADV_FROM_HANDLE(radv_physical_device, physical_device, physicalDevice);
 
-   STATIC_ASSERT(RADV_MEM_TYPE_COUNT <= VK_MAX_MEMORY_TYPES);
-
-   pMemoryProperties->memoryTypeCount = RADV_MEM_TYPE_COUNT;
-   pMemoryProperties->memoryTypes[RADV_MEM_TYPE_VRAM] = (VkMemoryType) {
-   .propertyFlags = VK_MEMORY_PROPERTY_DEVICE_LOCAL

Re: [Mesa-dev] [PATCH] gallivm: allow arch rounding with avx512

[Rowley, Timothy O]

I agree that we’re probably dropping into fallback paths in a variety of 
locations as there are a number of width==256 tests in the gallivm code.  Right 
now I’m working through piglit regressions versus avx2 in our driver, and the 
rounding tests weren't passing.

Thanks.

> On Nov 1, 2017, at 2:27 PM, Roland Scheidegger  wrote:
> 
> Looks good to me.
> Albeit I think there's quite a few more places which probably should
> handle avx512...
> 
> Reviewed-by: Roland Scheidegger 
> 
> Am 01.11.2017 um 20:17 schrieb Tim Rowley:
>> Fixes piglit vs-roundeven-{float,vec[234]} with simd16 VS.
>> ---
>> src/gallium/auxiliary/gallivm/lp_bld_arit.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
>> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> index cf1958b3b6..a1edd349f1 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> @@ -1953,7 +1953,8 @@ arch_rounding_available(const struct lp_type type)
>> {
>>if ((util_cpu_caps.has_sse4_1 &&
>>(type.length == 1 || type.width*type.length == 128)) ||
>> -   (util_cpu_caps.has_avx && type.width*type.length == 256))
>> +   (util_cpu_caps.has_avx && type.width*type.length == 256) ||
>> +   (util_cpu_caps.has_avx512f && type.width*type.length == 512))
>>   return TRUE;
>>else if ((util_cpu_caps.has_altivec &&
>> (type.width == 32 && type.length == 4)))
>> 
> 

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

Re: [Mesa-dev] [PATCH 33/33] intel: add aubinator ui

[Dylan Baker]

Quoting Scott D Phillips (2017-11-01 10:30:09)
> Lionel Landwerlin  writes:
> 
> > On 31/10/17 21:11, Scott D Phillips wrote:
> >>> +}
> >> [snip imgui]
> >>
> >> imgui seems to be the first instance of someone pasting a sizeable third
> >> party library into the repo.  I'm not sure how everyone feels about
> >> that. Unfortunately it seems like imgui isn't packaged by any distros
> >> that I can see either.
> >>
> >> Maybe we could do some meson wrap magic or something to pull it in
> >> without having to commit the code.
> >>
> > Copying seems to be the main way anybody is using it. Are you suggesting 
> > a submodule?
> 
> Right, something like making a 'wrap' for imgui that can go download and
> build the source:
> 
> http://mesonbuild.com/Wrap-dependency-system-manual.html
> 
> Really no idea if this is a great or terrible idea though. Dylan might
> have a better idea.
> 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev

I'm really not thrilled with the idea of pulling such a large fast moving
project into the tree either, though there is president, we have gtest in tree
already.

A wrap might be a good way to build it it, especially for an optional tool that
distros aren't expected to package. I wonder if upstream would take a meson 
build
specifically for this purpose? Would you like me to follow up with them and see
if that would be an option (meson feels [rightly] that it's preferable to try to
get a meson build into the upstream project before adding it to wrapdb)?

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 v3 24/43] i965/fs: Use byte scattered read

[Jason Ekstrand]

On Thu, Oct 12, 2017 at 11:38 AM, Jose Maria Casanova Crespo <
jmcasan...@igalia.com> wrote:

> Added on do_untyped_vector_read, that is used on the following
> intrinsics:
>* nir_intrinsic_load_shared
>* nir_intrinsic_load_ubo
>* nir_intrinsic_load_ssbo
>
> v2: Removed use of stride = 2 on 16-bit sources (Jason Ekstrand)
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 13c16fc912..d2f2e17b70 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -2268,6 +2268,18 @@ do_untyped_vector_read(const fs_builder &bld,
>
>   bld.ADD(read_offset, read_offset, brw_imm_ud(16));
>}
> +   } else if (type_sz(dest.type) == 2) {
> +  for (unsigned i = 0; i < num_components; i++) {
> + fs_reg base_offset = bld.vgrf(BRW_REGISTER_TYPE_UD);
> + bld.ADD(base_offset,
> + offset_reg,
> + brw_imm_ud(i * type_sz(dest.type)));
> + fs_reg read_reg = emit_byte_scattered_read(bld, surf_index,
> base_offset,
> +1 /* dims */,
> +1,
> +BRW_PREDICATE_NONE);
> + bld.MOV(offset(dest,bld,i), subscript(read_reg, dest.type, 0));
> +  }
>

This looks fine though I'm not actually sure byte scattered reads are
actually going to buy us anything over doing a DWORD read and unpacking the
16-bit values from the result.


> } else {
>unreachable("Unsupported type");
> }
> @@ -3911,10 +3923,14 @@ fs_visitor::nir_emit_intrinsic(const fs_builder
> &bld, nir_intrinsic_instr *instr
>if (const_offset == NULL) {
>   fs_reg base_offset = retype(get_nir_src(instr->src[1]),
>   BRW_REGISTER_TYPE_UD);
> -
> - for (int i = 0; i < instr->num_components; i++)
> -VARYING_PULL_CONSTANT_LOAD(bld, offset(dest, bld, i),
> surf_index,
> -   base_offset, i *
> type_sz(dest.type));
> + if (type_sz(dest.type) == 2) {
> +do_untyped_vector_read(bld, dest, surf_index, base_offset,
> +   instr->num_components);
> + } else {
> +for (int i = 0; i < instr->num_components; i++)
> +   VARYING_PULL_CONSTANT_LOAD(bld, offset(dest, bld, i),
> surf_index,
> +  base_offset, i *
> type_sz(dest.type));
> + }
>

I don't like lumping this change in with the other and I'm not sure I like
the change at all.  This switches us from using the sampler cache over to
using the data cache silently based on the component size.  I would rather
we either switch 100% over to the byte/oword scattered messages at some
hardware generation, or just keep with the sampler operation we're doing
today.  From my reading of the SKL docs, it looks like we can't actually
use the constant cache with the byte scattered messages but we could with
the DWORD scattered messages which may be a good change in future (though
Curro may have some reason we don't want to do that).  Unless we have a
very good reason why we need to use the byte messages, let's use something
that goes through the constant or sampler cache.  This is for UBO constant
data pulls so there's no real problem with reading too much data.

I think the thing to do in the short term is just do a
VARYING_PULL_CONSTANT_LOAD for each pair of components and then split them
out into 16-bit chunks.  Also, that should be it's own patch.


>} else {
>   /* Even if we are loading doubles, a pull constant load will load
>* a 32-bit vec4, so should only reserve vgrf space for that. If
> we
> --
> 2.13.6
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103538] vkDestroySwapchain causes deadlock on Wayland compositor with X11

[bugzilla-daemon]

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

Bug ID: 103538
   Summary: vkDestroySwapchain causes deadlock on Wayland
compositor with X11
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mais...@archlinux.us
QA Contact: mesa-dev@lists.freedesktop.org

When using the X11 backend in GLFW on RADV (and Anvil for that matter), when
tearing down the device, vkDestroySwapchain deadlocks while waiting for a
thread to complete execution. vkDeviceWaitIdle() has been called prior.

thread 1:
#0  0x7747743d in pthread_join () from /usr/lib/libpthread.so.0
#1  0x74968fa0 in x11_swapchain_destroy (anv_chain=0x56680b50,
pAllocator=0x5654eac8) at wsi/wsi_common_x11.c:1088
#2  0x74957cdc in radv_DestroySwapchainKHR (_device=0x5654eac0,
_swapchain=0x56680b50, pAllocator=0x0) at radv_wsi.c:418
#3  0x7fffeee27eff in ?? () from /usr/lib/libVkLayer_unique_objects.so

thread 2:
#0  0x7747c38d in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x74a48b90 in cnd_wait (cond=0x564bdd18, mtx=0x564bdcf0) at
../../include/c11/threads_posix.h:159
#2  0x74a49283 in util_queue_thread_func (input=0x564be310) at
u_queue.c:171
#3  0x74a48aa5 in impl_thrd_routine (p=0x564be330) at
../../include/c11/threads_posix.h:87
#4  0x7747608a in start_thread () from /usr/lib/libpthread.so.0
#5  0x768c424f in clone () from /usr/lib/libc.so.6

thread 3:
#0  0x768b9d4b in poll () from /usr/lib/libc.so.6
#1  0x765b18e0 in ?? () from /usr/lib/libxcb.so.1
#2  0x765b3779 in xcb_wait_for_special_event () from
/usr/lib/libxcb.so.1
#3  0x74968a14 in x11_manage_fifo_queues (state=0x56680b50) at
wsi/wsi_common_x11.c:936
#4  0x7747608a in start_thread () from /usr/lib/libpthread.so.0
#5  0x768c424f in clone () from /usr/lib/libc.so.6

-- 
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 103538] vkDestroySwapchain causes deadlock on Wayland compositor with X11

[bugzilla-daemon]

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

--- Comment #1 from mais...@archlinux.us ---
Running Wayland on Gnome 3 if that helps.

-- 
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] anv/meson: Generate dev_icd.json

[Chad Versace]

I tested this in a setup where the builddir was outside of the srcdir.
---
 src/intel/vulkan/meson.build | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
index ff24e304ef5..e8b7f407507 100644
--- a/src/intel/vulkan/meson.build
+++ b/src/intel/vulkan/meson.build
@@ -48,6 +48,18 @@ intel_icd = custom_target(
   install : true,
 )
 
+dev_icd = custom_target(
+  'dev_icd',
+  input : 'anv_icd.py',
+  output : 'dev_icd.@0@.json'.format(target_machine.cpu()),
+  command : [prog_python2, '@INPUT@',
+ '--lib-path', meson.current_build_dir(),
+ '--out', '@OUTPUT@'],
+  depend_files : files('anv_extensions.py'),
+  build_by_default : true,
+  install : false,
+)
+
 # TODO: workaround for anv_entrypoints combining the .h and .c files in it's
 # output. See issue #2346
 block_entrypoints = custom_target(
-- 
2.13.0

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

Re: [Mesa-dev] [PATCH 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

[Mark Janes]

Dylan Baker  writes:

> I haven't run the CTS tests, but both the deqp and the piglit test pass on my
> skl with Marek's patches applied.

I must have tested with only the patch 2 applied.  Running with all
three patches in the series, I see no piglit/deqp regressions.

However, GLES CTS fails thousands of ES31-CTS.functional.texture tests,
eg:

ES31-CTS.functional.texture.format.buffer.rg8i_npot
glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at 
gluContextInfo.cpp:229

-Mark

>
> Dylan
>
> Quoting Marek Olšák (2017-10-31 18:16:51)
>> This is how I run piglit on i965:
>> WAFFLE_GBM_DEVICE=/dev/dri/renderD128 PIGLIT_PLATFORM=gbm 
>> piglit/bin/glinfo|head
>> GL_RENDERER = Mesa DRI Intel(R) Ivybridge Desktop
>> 
>> Of course I have Radeon as my main GPU.
>> 
>> Marek
>> 
>> On Wed, Nov 1, 2017 at 12:52 AM, Mark Janes  wrote:
>> > No, please don't.  We can't have thousands of failures added to CI.
>> >
>> > Dylan, can you double check this for Marek?  I'm surprised that it
>> > doesn't reproduce for him.
>> >
>> > -Mark
>> >
>> > Marek Olšák  writes:
>> >
>> >> I can't reproduce the issue on my IVB. How about I just push this and
>> >> you guys fix i965 when you have time?
>> >>
>> >> Marek
>> >>
>> >> On Thu, Oct 26, 2017 at 5:46 PM, Mark Janes  
>> >> wrote:
>> >>> That fixed many issues, but:
>> >>>
>> >>> On deqp EGL tests, we get:
>> >>>
>> >>> dEQP-EGL.functional.create_context_ext.gl_42.rgba_no_depth_no_stencil
>> >>> deqp-egl: main/api_exec.c:135: _mesa_initialize_exec_table: Assertion 
>> >>> `ctx->Version > 0' failed.
>> >>>
>> >>> On ES31 CTS tests:
>> >>> ES31-CTS.functional.texture.texture_buffer.render.as_vertex_array_as_vertex_texture_as_fragment_texture.range_size_513
>> >>> glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
>> >>> gluContextInfo.cpp:229
>> >>>
>> >>> on GL46 CTS (27 failures):
>> >>> src/mesa/main/teximage.c:595: _mesa_tex_target_is_layered: Assertion
>> >>> `!"Invalid texture target."' failed.
>> >>>
>> >>> Piglit fails 3.5k tests with the same `ctx->Version > 0' assertion as
>> >>> deqp-egl.
>> >>>
>> >>> -Mark
>> >>>
>> >>> Dylan Baker  writes:
>> >>>
>>  I've pushed it to our CI, I'll let you know tomorrow what it looks like
>> 
>>  Dylan
>> 
>>  Quoting Marek Olšák (2017-10-25 19:52:43)
>> > Hi Dylan,
>> >
>> > Can you please add this and re-test?
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
>> > b/src/mesa/drivers/
>> > dri/i965/intel_extensions.c
>> > index 21cf632..4d17393 100644
>> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
>> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
>> > @@ -178,7 +178,7 @@ intelInitExtensions(struct gl_context *ctx)
>> >ctx->Extensions.ARB_pipeline_statistics_query = true;
>> >ctx->Extensions.ARB_sample_shading = true;
>> >ctx->Extensions.ARB_shading_language_420pack = true;
>> > -  if (ctx->API == API_OPENGL_CORE) {
>> > +  if (ctx->API != API_OPENGL_COMPAT) {
>> >   ctx->Extensions.ARB_texture_buffer_object = true;
>> >   ctx->Extensions.ARB_texture_buffer_object_rgb32 = true;
>> >   ctx->Extensions.ARB_texture_buffer_range = true;
>> >
>> >
>> > Marek
>> >
>> > On Wed, Oct 25, 2017 at 11:42 PM, Dylan Baker 
>> >  wrote:
>> >
>> > There are a significant number of i965 regressions from
>> > d96c68146a781c79a23f5181d7050174f1070d90, largely related to 
>> > texturing (I
>> > can
>> > send you a complete list of regressions if you care, but due to 
>> > the large
>> > number
>> > of them I suspect it's something fairly simple).
>> >
>> > For example:
>> > ES31-CTS.functional.texture.format.buffer.r32ui_npot
>> >
>> > glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
>> > gluContextInfo.cpp:229
>> >
>> > dEQP-GLES31.functional.state_query.integer.texture_buffer_
>> > binding_getinteger:
>> >
>> > glGetIntegerv(GL_TEXTURE_BUFFER_BINDING, 0x7ffee0c43834);
>> > // data = { -555819298 }
>> > glGetError();
>> > // GL_INVALID_ENUM returned
>> >  // ERROR: glGetIntegerv: glGetError() returned GL_INVALID_ENUM
>> >
>> > Dylan
>> >
>> > Quoting Emil Velikov (2017-10-24 09:30:03)
>> > > Hi Marek,
>> > >
>> > > On 21 October 2017 at 13:54, Marek Olšák  
>> > wrote:
>> > > > From: Marek Olšák 
>> > > >
>> > > > We already have piglit tests testing alpha, luminance, and 
>> > intensity
>> > > > formats. They were skipped by piglit until now.
>> > > >
>> > > > Additionally, I'm enabling one ARB_texture_buffer_range piglit 
>> > test to
>> > run
>> > > > with the compat profile.
>> > >
>> > > Can y

[Mesa-dev] [Bug 103539] Windows build breaks if 'sh' is not available

[bugzilla-daemon]

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

Bug ID: 103539
   Summary: Windows build breaks if 'sh' is not available
   Product: Mesa
   Version: 17.2
  Hardware: x86 (IA32)
OS: Windows (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: genpfa...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

3fd425aed7 switched write_git_sha1_h_file() in src/SConscript from Popen()ing
'git' directly to using a sh script.  Since sh isn't available on Windows the
function fails to create the git_sha1.h file and eventually breaks the build
when things like src\mesa\main\version.c try to #include it.

I'm using the mesa-17.2.4 tag (a4b72e2643) with the VS2015 toolchain.

-- 
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 2/3] mesa: enable ARB_texture_buffer_* extensions in the Compatibility profile

[Marek Olšák]

Hi Mark,

Can you try the attached patches instead?

Thanks,
Marek

On Wed, Nov 1, 2017 at 9:49 PM, Mark Janes  wrote:
> Dylan Baker  writes:
>
>> I haven't run the CTS tests, but both the deqp and the piglit test pass on my
>> skl with Marek's patches applied.
>
> I must have tested with only the patch 2 applied.  Running with all
> three patches in the series, I see no piglit/deqp regressions.
>
> However, GLES CTS fails thousands of ES31-CTS.functional.texture tests,
> eg:
>
> ES31-CTS.functional.texture.format.buffer.rg8i_npot
> glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at 
> gluContextInfo.cpp:229
>
> -Mark
>
>>
>> Dylan
>>
>> Quoting Marek Olšák (2017-10-31 18:16:51)
>>> This is how I run piglit on i965:
>>> WAFFLE_GBM_DEVICE=/dev/dri/renderD128 PIGLIT_PLATFORM=gbm 
>>> piglit/bin/glinfo|head
>>> GL_RENDERER = Mesa DRI Intel(R) Ivybridge Desktop
>>>
>>> Of course I have Radeon as my main GPU.
>>>
>>> Marek
>>>
>>> On Wed, Nov 1, 2017 at 12:52 AM, Mark Janes  wrote:
>>> > No, please don't.  We can't have thousands of failures added to CI.
>>> >
>>> > Dylan, can you double check this for Marek?  I'm surprised that it
>>> > doesn't reproduce for him.
>>> >
>>> > -Mark
>>> >
>>> > Marek Olšák  writes:
>>> >
>>> >> I can't reproduce the issue on my IVB. How about I just push this and
>>> >> you guys fix i965 when you have time?
>>> >>
>>> >> Marek
>>> >>
>>> >> On Thu, Oct 26, 2017 at 5:46 PM, Mark Janes  
>>> >> wrote:
>>> >>> That fixed many issues, but:
>>> >>>
>>> >>> On deqp EGL tests, we get:
>>> >>>
>>> >>> dEQP-EGL.functional.create_context_ext.gl_42.rgba_no_depth_no_stencil
>>> >>> deqp-egl: main/api_exec.c:135: _mesa_initialize_exec_table: Assertion 
>>> >>> `ctx->Version > 0' failed.
>>> >>>
>>> >>> On ES31 CTS tests:
>>> >>> ES31-CTS.functional.texture.texture_buffer.render.as_vertex_array_as_vertex_texture_as_fragment_texture.range_size_513
>>> >>> glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
>>> >>> gluContextInfo.cpp:229
>>> >>>
>>> >>> on GL46 CTS (27 failures):
>>> >>> src/mesa/main/teximage.c:595: _mesa_tex_target_is_layered: Assertion
>>> >>> `!"Invalid texture target."' failed.
>>> >>>
>>> >>> Piglit fails 3.5k tests with the same `ctx->Version > 0' assertion as
>>> >>> deqp-egl.
>>> >>>
>>> >>> -Mark
>>> >>>
>>> >>> Dylan Baker  writes:
>>> >>>
>>>  I've pushed it to our CI, I'll let you know tomorrow what it looks like
>>> 
>>>  Dylan
>>> 
>>>  Quoting Marek Olšák (2017-10-25 19:52:43)
>>> > Hi Dylan,
>>> >
>>> > Can you please add this and re-test?
>>> >
>>> > diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
>>> > b/src/mesa/drivers/
>>> > dri/i965/intel_extensions.c
>>> > index 21cf632..4d17393 100644
>>> > --- a/src/mesa/drivers/dri/i965/intel_extensions.c
>>> > +++ b/src/mesa/drivers/dri/i965/intel_extensions.c
>>> > @@ -178,7 +178,7 @@ intelInitExtensions(struct gl_context *ctx)
>>> >ctx->Extensions.ARB_pipeline_statistics_query = true;
>>> >ctx->Extensions.ARB_sample_shading = true;
>>> >ctx->Extensions.ARB_shading_language_420pack = true;
>>> > -  if (ctx->API == API_OPENGL_CORE) {
>>> > +  if (ctx->API != API_OPENGL_COMPAT) {
>>> >   ctx->Extensions.ARB_texture_buffer_object = true;
>>> >   ctx->Extensions.ARB_texture_buffer_object_rgb32 = true;
>>> >   ctx->Extensions.ARB_texture_buffer_range = true;
>>> >
>>> >
>>> > Marek
>>> >
>>> > On Wed, Oct 25, 2017 at 11:42 PM, Dylan Baker 
>>> >  wrote:
>>> >
>>> > There are a significant number of i965 regressions from
>>> > d96c68146a781c79a23f5181d7050174f1070d90, largely related to 
>>> > texturing (I
>>> > can
>>> > send you a complete list of regressions if you care, but due to 
>>> > the large
>>> > number
>>> > of them I suspect it's something fairly simple).
>>> >
>>> > For example:
>>> > ES31-CTS.functional.texture.format.buffer.r32ui_npot
>>> >
>>> > glGetIntegerv() failed: glGetError() returned GL_INVALID_ENUM at
>>> > gluContextInfo.cpp:229
>>> >
>>> > dEQP-GLES31.functional.state_query.integer.texture_buffer_
>>> > binding_getinteger:
>>> >
>>> > glGetIntegerv(GL_TEXTURE_BUFFER_BINDING, 0x7ffee0c43834);
>>> > // data = { -555819298 }
>>> > glGetError();
>>> > // GL_INVALID_ENUM returned
>>> >  // ERROR: glGetIntegerv: glGetError() returned GL_INVALID_ENUM
>>> >
>>> > Dylan
>>> >
>>> > Quoting Emil Velikov (2017-10-24 09:30:03)
>>> > > Hi Marek,
>>> > >
>>> > > On 21 October 2017 at 13:54, Marek Olšák  
>>> > wrote:
>>> > > > From: Marek Olšák 
>>> > > >
>>> > > > We already have piglit tests testing alpha, luminance, and 
>>> > intensity
>>> >