[Mesa-dev] [PATCH 2/2] anv: add anv_extensions.h in gitignore

[Alejandro Piñeiro]

Generated since:
dd088d4bec74f37ffe4cd02626a6a8af93fdebac
"anv/extensions: Generate a header file with extension tables"
---
 src/intel/vulkan/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/.gitignore b/src/intel/vulkan/.gitignore
index 4ea978d6e41..4036a1bfe3c 100644
--- a/src/intel/vulkan/.gitignore
+++ b/src/intel/vulkan/.gitignore
@@ -5,3 +5,4 @@
 /anv_timestamp.h
 /dev_icd.json
 /intel_icd.*.json
+/anv_extensions.h
\ No newline at end of file
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/2] compiler/nir: add nir_intrinsics.[ch] to .gitignore

[Alejandro Piñeiro]

Generated since
76dfed8ae2d5c6c509eb2661389be3c6a25077df
"nir: mako all the intrinsics"
---
 src/compiler/nir/.gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir/.gitignore b/src/compiler/nir/.gitignore
index 64828eba6d3..dea9ada80fa 100644
--- a/src/compiler/nir/.gitignore
+++ b/src/compiler/nir/.gitignore
@@ -3,3 +3,5 @@ nir_opt_algebraic.c
 nir_opcodes.c
 nir_opcodes.h
 nir_constant_expressions.c
+nir_intrinsics.h
+nir_intrinsics.c
\ No newline at end of file
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] i965: Extend the negative 32-bit deltas to 64-bits

[Kenneth Graunke]

On Tuesday, April 3, 2018 11:56:27 PM PDT Sergii Romantsov wrote:
> Hello, Mark.
> I've done: Cc, Tested-by and Reviewed-by also added.

I pushed your patch.  Thanks so much for tracking this down!


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

[Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < > (Vinson Lee)

v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)

Signed-of-by: Mike Lothian 
Tested-by: Vinson Lee 
---
 src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..19f68c2bb6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/Scalar.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/Utils.h"
+#endif
 #include "llvm/Support/Host.h"
 #include "llvm/Support/DynamicLibrary.h"
 
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH 2/2] etnaviv: advertise YUV formats as external only

[Philipp Zabel]

On Thu, 2018-03-29 at 16:15 +0200, Lucas Stach wrote:
> We only support importing YUV as OES external resources.
> This will change in the future, but for now this fixes the
> advertised capabilities in eglQueryDmaBufModifiersEXT.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index e38e48c89436..3c2addb4aa5a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -632,7 +632,7 @@ etna_screen_query_dmabuf_modifiers(struct pipe_screen 
> *pscreen,
>if (modifiers)
>   modifiers[num_modifiers] = supported_modifiers[i];
>if (external_only)
> - external_only[num_modifiers] = 0;
> + external_only[num_modifiers] = util_format_is_yuv(format) ? 1 : 0;
>num_modifiers++;
> }

Reviewed-by: Philipp Zabel 

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

Re: [Mesa-dev] [PATCH 1/2] gallium/util: implement util_format_is_yuv

[Philipp Zabel]

On Thu, 2018-03-29 at 16:15 +0200, Lucas Stach wrote:
> This adds a helper to check if a pipe format is in YUV color space.
> Drivers want to know about this, as YUV mostly needs special handling.
> 
> Signed-off-by: Lucas Stach 
> ---
>  src/gallium/auxiliary/util/u_format.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/gallium/auxiliary/util/u_format.h 
> b/src/gallium/auxiliary/util/u_format.h
> index 88bfd72d0538..e497b4b3375a 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -557,6 +557,18 @@ util_format_is_depth_and_stencil(enum pipe_format format)
>util_format_has_stencil(desc);
>  }
>  
> +static inline boolean
> +util_format_is_yuv(enum pipe_format format)
> +{
> +   const struct util_format_description *desc = 
> util_format_description(format);
> +
> +   assert(desc);
> +   if (!desc) {
> +  return FALSE;
> +   }
> +
> +   return desc->colorspace == UTIL_FORMAT_COLORSPACE_YUV;
> +}
>  
>  /**
>   * Calculates the depth format type based upon the incoming format 
> description.

Reviewed-by: Philipp Zabel 

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

[Mesa-dev] [PATCH 1/2] radv: mask out high VM address bits in registers where needed

[Samuel Pitoiset]

Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 18 +-
 src/amd/vulkan/radv_device.c |  2 +-
 src/amd/vulkan/radv_pipeline.c   | 18 +-
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f0a0b08678..b3d6fc484e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -820,20 +820,20 @@ radv_emit_fb_color_state(struct radv_cmd_buffer 
*cmd_buffer,
if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
radeon_set_context_reg_seq(cmd_buffer->cs, 
R_028C60_CB_COLOR0_BASE + index * 0x3c, 11);
radeon_emit(cmd_buffer->cs, cb->cb_color_base);
-   radeon_emit(cmd_buffer->cs, cb->cb_color_base >> 32);
+   radeon_emit(cmd_buffer->cs, 
S_028C64_BASE_256B(cb->cb_color_base >> 32));
radeon_emit(cmd_buffer->cs, cb->cb_color_attrib2);
radeon_emit(cmd_buffer->cs, cb->cb_color_view);
radeon_emit(cmd_buffer->cs, cb_color_info);
radeon_emit(cmd_buffer->cs, cb->cb_color_attrib);
radeon_emit(cmd_buffer->cs, cb->cb_dcc_control);
radeon_emit(cmd_buffer->cs, cb->cb_color_cmask);
-   radeon_emit(cmd_buffer->cs, cb->cb_color_cmask >> 32);
+   radeon_emit(cmd_buffer->cs, 
S_028C80_BASE_256B(cb->cb_color_cmask >> 32));
radeon_emit(cmd_buffer->cs, cb->cb_color_fmask);
-   radeon_emit(cmd_buffer->cs, cb->cb_color_fmask >> 32);
+   radeon_emit(cmd_buffer->cs, 
S_028C88_BASE_256B(cb->cb_color_fmask >> 32));
 
radeon_set_context_reg_seq(cmd_buffer->cs, 
R_028C94_CB_COLOR0_DCC_BASE + index * 0x3c, 2);
radeon_emit(cmd_buffer->cs, cb->cb_dcc_base);
-   radeon_emit(cmd_buffer->cs, cb->cb_dcc_base >> 32);
+   radeon_emit(cmd_buffer->cs, S_028C98_BASE_256B(cb->cb_dcc_base 
>> 32));

radeon_set_context_reg(cmd_buffer->cs, R_0287A0_CB_MRT0_EPITCH 
+ index * 4,
   
S_0287A0_EPITCH(att->attachment->image->surface.u.gfx9.surf.epitch));
@@ -881,20 +881,20 @@ radv_emit_fb_ds_state(struct radv_cmd_buffer *cmd_buffer,
if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
radeon_set_context_reg_seq(cmd_buffer->cs, 
R_028014_DB_HTILE_DATA_BASE, 3);
radeon_emit(cmd_buffer->cs, ds->db_htile_data_base);
-   radeon_emit(cmd_buffer->cs, ds->db_htile_data_base >> 32);
+   radeon_emit(cmd_buffer->cs, 
S_028018_BASE_HI(ds->db_htile_data_base >> 32));
radeon_emit(cmd_buffer->cs, ds->db_depth_size);
 
radeon_set_context_reg_seq(cmd_buffer->cs, R_028038_DB_Z_INFO, 
10);
radeon_emit(cmd_buffer->cs, db_z_info); /* 
DB_Z_INFO */
radeon_emit(cmd_buffer->cs, db_stencil_info);   /* 
DB_STENCIL_INFO */
radeon_emit(cmd_buffer->cs, ds->db_z_read_base);/* 
DB_Z_READ_BASE */
-   radeon_emit(cmd_buffer->cs, ds->db_z_read_base >> 32);  /* 
DB_Z_READ_BASE_HI */
+   radeon_emit(cmd_buffer->cs, S_028044_BASE_HI(ds->db_z_read_base 
>> 32));/* DB_Z_READ_BASE_HI */
radeon_emit(cmd_buffer->cs, ds->db_stencil_read_base);  /* 
DB_STENCIL_READ_BASE */
-   radeon_emit(cmd_buffer->cs, ds->db_stencil_read_base >> 32); /* 
DB_STENCIL_READ_BASE_HI */
+   radeon_emit(cmd_buffer->cs, 
S_02804C_BASE_HI(ds->db_stencil_read_base >> 32)); /* DB_STENCIL_READ_BASE_HI */
radeon_emit(cmd_buffer->cs, ds->db_z_write_base);   /* 
DB_Z_WRITE_BASE */
-   radeon_emit(cmd_buffer->cs, ds->db_z_write_base >> 32); /* 
DB_Z_WRITE_BASE_HI */
+   radeon_emit(cmd_buffer->cs, 
S_028054_BASE_HI(ds->db_z_write_base >> 32));   /* DB_Z_WRITE_BASE_HI */
radeon_emit(cmd_buffer->cs, ds->db_stencil_write_base); /* 
DB_STENCIL_WRITE_BASE */
-   radeon_emit(cmd_buffer->cs, ds->db_stencil_write_base >> 32); 
/* DB_STENCIL_WRITE_BASE_HI */
+   radeon_emit(cmd_buffer->cs, 
S_02805C_BASE_HI(ds->db_stencil_write_base >> 32)); /* DB_STENCIL_WRITE_BASE_HI 
*/
 
radeon_set_context_reg_seq(cmd_buffer->cs, R_028068_DB_Z_INFO2, 
2);
radeon_emit(cmd_buffer->cs, ds->db_z_info2);
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 4acdf3d416..65727571a3 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1921,7 +1921,7 @@ radv_get_preamble_cs(struct radv_queue *queue,
   tf_va >> 8);
if 
(queue->device->physical_device->rad_info.chip_class >= GFX9) {
  

[Mesa-dev] [PATCH 2/2] radv: don't use the SPI barrier management bug workaround

[Samuel Pitoiset]

Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 5a44efb78b..89a643a1b1 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1274,6 +1274,11 @@ calculate_gs_ring_sizes(struct radv_pipeline *pipeline, 
const struct radv_gs_sta
 static void si_multiwave_lds_size_workaround(struct radv_device *device,
 unsigned *lds_size)
 {
+   /* If tessellation is all offchip and on-chip GS isn't used, this
+* workaround is not needed.
+*/
+   return;
+
/* SPI barrier management bug:
 *   Make sure we have at least 4k of LDS in use to avoid the bug.
 *   It applies to workgroup sizes of more than one wavefront.
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH 2/2] etnaviv: advertise YUV formats as external only

[Christian Gmeiner]

2018-03-29 16:15 GMT+02:00 Lucas Stach :
> We only support importing YUV as OES external resources.
> This will change in the future, but for now this fixes the
> advertised capabilities in eglQueryDmaBufModifiersEXT.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/etnaviv/etnaviv_screen.c 
> b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> index e38e48c89436..3c2addb4aa5a 100644
> --- a/src/gallium/drivers/etnaviv/etnaviv_screen.c
> +++ b/src/gallium/drivers/etnaviv/etnaviv_screen.c
> @@ -632,7 +632,7 @@ etna_screen_query_dmabuf_modifiers(struct pipe_screen 
> *pscreen,
>if (modifiers)
>   modifiers[num_modifiers] = supported_modifiers[i];
>if (external_only)
> - external_only[num_modifiers] = 0;
> + external_only[num_modifiers] = util_format_is_yuv(format) ? 1 : 0;
>num_modifiers++;
> }
>
> --
> 2.16.1
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH 1/2] gallium/util: implement util_format_is_yuv

[Christian Gmeiner]

2018-03-29 16:15 GMT+02:00 Lucas Stach :
> This adds a helper to check if a pipe format is in YUV color space.
> Drivers want to know about this, as YUV mostly needs special handling.
>
> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  src/gallium/auxiliary/util/u_format.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_format.h 
> b/src/gallium/auxiliary/util/u_format.h
> index 88bfd72d0538..e497b4b3375a 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -557,6 +557,18 @@ util_format_is_depth_and_stencil(enum pipe_format format)
>util_format_has_stencil(desc);
>  }
>
> +static inline boolean
> +util_format_is_yuv(enum pipe_format format)
> +{
> +   const struct util_format_description *desc = 
> util_format_description(format);
> +
> +   assert(desc);
> +   if (!desc) {
> +  return FALSE;
> +   }
> +
> +   return desc->colorspace == UTIL_FORMAT_COLORSPACE_YUV;
> +}
>
>  /**
>   * Calculates the depth format type based upon the incoming format 
> description.
> --
> 2.16.1
>
> ___
> etnaviv mailing list
> etna...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/etnaviv



-- 
greets
--
Christian Gmeiner, MSc

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

Re: [Mesa-dev] [PATCH] intel: compiler: silence compiler warning

[Iago Toral]

Reviewed-by: Iago Toral Quiroga 

On Tue, 2018-04-03 at 15:41 +0100, Lionel Landwerlin wrote:
> ../src/intel/compiler/brw_reg.h: In function ‘bool
> brw_regs_negative_equal(const brw_reg*, const brw_reg*)’:
> ../src/intel/compiler/brw_reg.h:305:1: warning: control reaches end
> of non-void function [-Wreturn-type]
> 
> Introduced by 8f83eea71e233 ("i965: Add negative_equals methods").
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/intel/compiler/brw_reg.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/intel/compiler/brw_reg.h
> b/src/intel/compiler/brw_reg.h
> index 68158cc0cc8..afcd146de2c 100644
> --- a/src/intel/compiler/brw_reg.h
> +++ b/src/intel/compiler/brw_reg.h
> @@ -293,6 +293,7 @@ brw_regs_negative_equal(const struct brw_reg *a,
> const struct brw_reg *b)
>case BRW_REGISTER_TYPE_UB:
>case BRW_REGISTER_TYPE_B:
>case BRW_REGISTER_TYPE_NF:
> +  default:
>   unreachable("not reached");
>}
> } else {
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: do not always disable dual quad mode when chip has RbPlus

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Thu, Mar 29, 2018 at 2:51 PM, Samuel Pitoiset
 wrote:
> For GFX9+ only, RadeonSI does this too.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index af1ea395d3..6797f768fe 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -669,9 +669,23 @@ radv_pipeline_init_blend_state(struct radv_pipeline 
> *pipeline,
> blend.sx_mrt_blend_opt[i] = 
> S_028760_COLOR_COMB_FCN(V_028760_OPT_COMB_BLEND_DISABLED) | 
> S_028760_ALPHA_COMB_FCN(V_028760_OPT_COMB_BLEND_DISABLED);
> }
>
> -   /* disable RB+ for now */
> -   if (pipeline->device->physical_device->has_rbplus)
> -   blend.cb_color_control |= S_028808_DISABLE_DUAL_QUAD(1);
> +   if (pipeline->device->physical_device->has_rbplus) {
> +   /* Disable RB+ blend optimizations for dual source blending. 
> */
> +   if (blend_mrt0_is_dual_src) {
> +   for (i = 0; i < 8; i++) {
> +   blend.sx_mrt_blend_opt[i] =
> +   
> S_028760_COLOR_COMB_FCN(V_028760_OPT_COMB_NONE) |
> +   
> S_028760_ALPHA_COMB_FCN(V_028760_OPT_COMB_NONE);
> +   }
> +   }
> +
> +   /* RB+ doesn't work with dual source blending, logic op and
> +* RESOLVE.
> +*/
> +   if (blend_mrt0_is_dual_src || vkblend->logicOpEnable ||
> +   mode == V_028808_CB_RESOLVE)
> +   blend.cb_color_control |= 
> S_028808_DISABLE_DUAL_QUAD(1);
> +   }
>
> if (blend.cb_target_mask)
> blend.cb_color_control |= S_028808_MODE(mode);
> --
> 2.16.3
>
> ___
> 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 2/2] radv: don't use the SPI barrier management bug workaround

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Wed, Apr 4, 2018 at 10:55 AM, Samuel Pitoiset
 wrote:
> Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 5a44efb78b..89a643a1b1 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -1274,6 +1274,11 @@ calculate_gs_ring_sizes(struct radv_pipeline 
> *pipeline, const struct radv_gs_sta
>  static void si_multiwave_lds_size_workaround(struct radv_device *device,
>  unsigned *lds_size)
>  {
> +   /* If tessellation is all offchip and on-chip GS isn't used, this
> +* workaround is not needed.
> +*/
> +   return;
> +
> /* SPI barrier management bug:
>  *   Make sure we have at least 4k of LDS in use to avoid the bug.
>  *   It applies to workgroup sizes of more than one wavefront.
> --
> 2.16.3
>
> ___
> 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 15/17] radeonsi: always prefetch later shaders after the draw packet

[Samuel Pitoiset]

On 04/04/2018 03:59 AM, Marek Olšák wrote:

From: Marek Olšák 

so that the draw is started as soon as possible.
---
  src/gallium/drivers/radeonsi/si_cp_dma.c | 68 ++--
  src/gallium/drivers/radeonsi/si_pipe.h   |  2 +-
  src/gallium/drivers/radeonsi/si_state_draw.c | 11 -
  src/util/bitscan.h   |  8 
  4 files changed, 61 insertions(+), 28 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c 
b/src/gallium/drivers/radeonsi/si_cp_dma.c
index 15bd305a350..ea2c7cf7198 100644
--- a/src/gallium/drivers/radeonsi/si_cp_dma.c
+++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
@@ -514,80 +514,98 @@ static void cik_prefetch_shader_async(struct si_context 
*sctx,
  static void cik_prefetch_VBO_descriptors(struct si_context *sctx)
  {
if (!sctx->vertex_elements)
return;
  
  	cik_prefetch_TC_L2_async(sctx, &sctx->vb_descriptors_buffer->b.b,

 sctx->vb_descriptors_offset,
 sctx->vertex_elements->desc_list_byte_size);
  }
  
-void cik_emit_prefetch_L2(struct si_context *sctx)

+/**
+ * Prefetch shaders and VBO descriptors.
+ *
+ * \param first_two  Whether only the first 2 items should be prefetched,
+ *   which are usually the API VS and VBO descriptors.
+ */
+void cik_emit_prefetch_L2(struct si_context *sctx, bool first_two)
  {
+   unsigned mask;
+
+   assert(sctx->prefetch_L2_mask);
+
+   if (first_two) {
+   mask = 1 << u_bit_scan16(&sctx->prefetch_L2_mask);
+
+   if (sctx->prefetch_L2_mask)
+   mask |= 1 << u_bit_scan16(&sctx->prefetch_L2_mask);


Where do you reset the prefetch L2 mask ? It looks like to me that you 
are going to prefetch VS/VBOs twice in the fast draw path.

+   } else {
+   mask = sctx->prefetch_L2_mask;
+   sctx->prefetch_L2_mask = 0;
+   }
+
/* Prefetch shaders and VBO descriptors to TC L2. */
if (sctx->b.chip_class >= GFX9) {
/* Choose the right spot for the VBO prefetch. */
if (sctx->tes_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_HS)
+   if (mask & SI_PREFETCH_HS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.hs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
+   if (mask & SI_PREFETCH_GS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.gs);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
} else if (sctx->gs_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
+   if (mask & SI_PREFETCH_GS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.gs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
} else {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
+   if (mask & SI_PREFETCH_VS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.vs);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
}
} else {
/* SI-CI-VI */
/* Choose the right spot for the VBO prefetch. */
if (sctx->tes_shader.cso) {
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_LS)
+   if (mask & SI_PREFETCH_LS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.ls);
-   if (sctx->prefetch_L2_mask & 
SI_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
cik_prefetch_VBO_descriptors(sctx);
-   if (sctx->prefetch_L2_mask & SI_PREFETCH_HS)
+   if (mask & SI_PREFETCH_HS)
cik_prefetch_shader_async(sctx, 
sctx->queued.named.hs);
-   if (sctx->prefetch_L2_m

[Mesa-dev] [PATCH 1/3] radv: use a mask for VBOs and shaders prefetching

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 75 ++--
 src/amd/vulkan/radv_private.h|  3 +-
 2 files changed, 51 insertions(+), 27 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index b3d6fc484e..684f2a239a 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -37,6 +37,20 @@
 
 #include "ac_debug.h"
 
+enum {
+   RADV_PREFETCH_VBO_DESCRIPTORS   = (1 << 0),
+   RADV_PREFETCH_VS= (1 << 1),
+   RADV_PREFETCH_TCS   = (1 << 2),
+   RADV_PREFETCH_TES   = (1 << 3),
+   RADV_PREFETCH_GS= (1 << 4),
+   RADV_PREFETCH_PS= (1 << 5),
+   RADV_PREFETCH_SHADERS   = (RADV_PREFETCH_VS  |
+  RADV_PREFETCH_TCS |
+  RADV_PREFETCH_TES |
+  RADV_PREFETCH_GS  |
+  RADV_PREFETCH_PS)
+};
+
 static void radv_handle_image_transition(struct radv_cmd_buffer *cmd_buffer,
 struct radv_image *image,
 VkImageLayout src_layout,
@@ -617,17 +631,6 @@ radv_emit_prefetch_TC_L2_async(struct radv_cmd_buffer 
*cmd_buffer, uint64_t va,
si_cp_dma_prefetch(cmd_buffer, va, size);
 }
 
-static void
-radv_emit_VBO_descriptors_prefetch(struct radv_cmd_buffer *cmd_buffer)
-{
-   if (cmd_buffer->state.vb_prefetch_dirty) {
-   radv_emit_prefetch_TC_L2_async(cmd_buffer,
-  cmd_buffer->state.vb_va,
-  cmd_buffer->state.vb_size);
-   cmd_buffer->state.vb_prefetch_dirty = false;
-   }
-}
-
 static void
 radv_emit_shader_prefetch(struct radv_cmd_buffer *cmd_buffer,
  struct radv_shader_variant *shader)
@@ -649,18 +652,35 @@ static void
 radv_emit_prefetch(struct radv_cmd_buffer *cmd_buffer,
   struct radv_pipeline *pipeline)
 {
-   radv_emit_shader_prefetch(cmd_buffer,
- pipeline->shaders[MESA_SHADER_VERTEX]);
-   radv_emit_VBO_descriptors_prefetch(cmd_buffer);
-   radv_emit_shader_prefetch(cmd_buffer,
- pipeline->shaders[MESA_SHADER_TESS_CTRL]);
-   radv_emit_shader_prefetch(cmd_buffer,
- pipeline->shaders[MESA_SHADER_TESS_EVAL]);
-   radv_emit_shader_prefetch(cmd_buffer,
- pipeline->shaders[MESA_SHADER_GEOMETRY]);
-   radv_emit_shader_prefetch(cmd_buffer, pipeline->gs_copy_shader);
-   radv_emit_shader_prefetch(cmd_buffer,
- pipeline->shaders[MESA_SHADER_FRAGMENT]);
+   struct radv_cmd_state *state = &cmd_buffer->state;
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
+   radv_emit_shader_prefetch(cmd_buffer,
+ 
pipeline->shaders[MESA_SHADER_VERTEX]);
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
+   radv_emit_prefetch_TC_L2_async(cmd_buffer, state->vb_va,
+  state->vb_size);
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
+   radv_emit_shader_prefetch(cmd_buffer,
+ 
pipeline->shaders[MESA_SHADER_TESS_CTRL]);
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_TES)
+   radv_emit_shader_prefetch(cmd_buffer,
+ 
pipeline->shaders[MESA_SHADER_TESS_EVAL]);
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_GS) {
+   radv_emit_shader_prefetch(cmd_buffer,
+ 
pipeline->shaders[MESA_SHADER_GEOMETRY]);
+   radv_emit_shader_prefetch(cmd_buffer, pipeline->gs_copy_shader);
+   }
+
+   if (state->prefetch_L2_mask & RADV_PREFETCH_PS)
+   radv_emit_shader_prefetch(cmd_buffer,
+ 
pipeline->shaders[MESA_SHADER_FRAGMENT]);
+
+   state->prefetch_L2_mask = 0;
 }
 
 static void
@@ -1476,7 +1496,7 @@ radv_cmd_buffer_update_vertex_descriptors(struct 
radv_cmd_buffer *cmd_buffer, bo
 
cmd_buffer->state.vb_va = va;
cmd_buffer->state.vb_size = count * 16;
-   cmd_buffer->state.vb_prefetch_dirty = true;
+   cmd_buffer->state.prefetch_L2_mask |= 
RADV_PREFETCH_VBO_DESCRIPTORS;
}
cmd_buffer->state.dirty &= ~RADV_CMD_DIRTY_VERTEX_BUFFER;
 
@@ -2282,6 +2302,9 @@ void radv_CmdBindPipeline(
cmd_buffer->state.last_first_instance = -1;
cmd_buffer->state.last_vertex_offset = -1;
 
+   /* Prefetch all pipeline shaders at first draw time. */
+  

[Mesa-dev] [PATCH 2/3] radv: rename radv_emit_prefetch() to radv_emit_prefetch_L2()

[Samuel Pitoiset]

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 684f2a239a..393d9ba4f4 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -621,16 +621,6 @@ radv_update_multisample_state(struct radv_cmd_buffer 
*cmd_buffer,
}
 }
 
-
-
-static inline void
-radv_emit_prefetch_TC_L2_async(struct radv_cmd_buffer *cmd_buffer, uint64_t va,
-  unsigned size)
-{
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= CIK)
-   si_cp_dma_prefetch(cmd_buffer, va, size);
-}
-
 static void
 radv_emit_shader_prefetch(struct radv_cmd_buffer *cmd_buffer,
  struct radv_shader_variant *shader)
@@ -645,22 +635,24 @@ radv_emit_shader_prefetch(struct radv_cmd_buffer 
*cmd_buffer,
va = radv_buffer_get_va(shader->bo) + shader->bo_offset;
 
radv_cs_add_buffer(ws, cs, shader->bo, 8);
-   radv_emit_prefetch_TC_L2_async(cmd_buffer, va, shader->code_size);
+   si_cp_dma_prefetch(cmd_buffer, va, shader->code_size);
 }
 
 static void
-radv_emit_prefetch(struct radv_cmd_buffer *cmd_buffer,
-  struct radv_pipeline *pipeline)
+radv_emit_prefetch_L2(struct radv_cmd_buffer *cmd_buffer,
+ struct radv_pipeline *pipeline)
 {
struct radv_cmd_state *state = &cmd_buffer->state;
 
+   if (cmd_buffer->device->physical_device->rad_info.chip_class < CIK)
+   return;
+
if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_VERTEX]);
 
if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
-   radv_emit_prefetch_TC_L2_async(cmd_buffer, state->vb_va,
-  state->vb_size);
+   si_cp_dma_prefetch(cmd_buffer, state->vb_va, state->vb_size);
 
if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
radv_emit_shader_prefetch(cmd_buffer,
@@ -3049,8 +3041,8 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
 * important.
 */
if (cmd_buffer->state.prefetch_L2_mask) {
-   radv_emit_prefetch(cmd_buffer,
-  cmd_buffer->state.pipeline);
+   radv_emit_prefetch_L2(cmd_buffer,
+ cmd_buffer->state.pipeline);
}
} else {
/* If we don't wait for idle, start prefetches first, then set
@@ -3059,8 +3051,8 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
si_emit_cache_flush(cmd_buffer);
 
if (cmd_buffer->state.prefetch_L2_mask) {
-   radv_emit_prefetch(cmd_buffer,
-  cmd_buffer->state.pipeline);
+   radv_emit_prefetch_L2(cmd_buffer,
+ cmd_buffer->state.pipeline);
}
 
if (!radv_upload_graphics_shader_descriptors(cmd_buffer, 
pipeline_is_dirty))
-- 
2.16.3

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

[Mesa-dev] [PATCH 3/3] radv: implement a fast prefetch path for the vertex stage

[Samuel Pitoiset]

This allows to start draws as soon as possible.

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

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 393d9ba4f4..0e59f99799 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -640,39 +640,48 @@ radv_emit_shader_prefetch(struct radv_cmd_buffer 
*cmd_buffer,
 
 static void
 radv_emit_prefetch_L2(struct radv_cmd_buffer *cmd_buffer,
- struct radv_pipeline *pipeline)
+ struct radv_pipeline *pipeline,
+ bool vertex_stage_only)
 {
struct radv_cmd_state *state = &cmd_buffer->state;
+   uint32_t mask = state->prefetch_L2_mask;
 
if (cmd_buffer->device->physical_device->rad_info.chip_class < CIK)
return;
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
+   if (vertex_stage_only) {
+   /* Fast prefetch path for starting draws as soon as possible.
+*/
+   mask = state->prefetch_L2_mask & (RADV_PREFETCH_VS |
+ 
RADV_PREFETCH_VBO_DESCRIPTORS);
+   }
+
+   if (mask & RADV_PREFETCH_VS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_VERTEX]);
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
+   if (mask & RADV_PREFETCH_VBO_DESCRIPTORS)
si_cp_dma_prefetch(cmd_buffer, state->vb_va, state->vb_size);
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
+   if (mask & RADV_PREFETCH_TCS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_TESS_CTRL]);
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_TES)
+   if (mask & RADV_PREFETCH_TES)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_TESS_EVAL]);
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_GS) {
+   if (mask & RADV_PREFETCH_GS) {
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_GEOMETRY]);
radv_emit_shader_prefetch(cmd_buffer, pipeline->gs_copy_shader);
}
 
-   if (state->prefetch_L2_mask & RADV_PREFETCH_PS)
+   if (mask & RADV_PREFETCH_PS)
radv_emit_shader_prefetch(cmd_buffer,
  
pipeline->shaders[MESA_SHADER_FRAGMENT]);
 
-   state->prefetch_L2_mask = 0;
+   state->prefetch_L2_mask &= ~mask;
 }
 
 static void
@@ -3042,7 +3051,7 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
 */
if (cmd_buffer->state.prefetch_L2_mask) {
radv_emit_prefetch_L2(cmd_buffer,
- cmd_buffer->state.pipeline);
+ cmd_buffer->state.pipeline, 
false);
}
} else {
/* If we don't wait for idle, start prefetches first, then set
@@ -3051,8 +3060,11 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
si_emit_cache_flush(cmd_buffer);
 
if (cmd_buffer->state.prefetch_L2_mask) {
+   /* Only prefetch the vertex shader and VBO descriptors
+* in order to start the draw as soon as possible.
+*/
radv_emit_prefetch_L2(cmd_buffer,
- cmd_buffer->state.pipeline);
+ cmd_buffer->state.pipeline, true);
}
 
if (!radv_upload_graphics_shader_descriptors(cmd_buffer, 
pipeline_is_dirty))
@@ -3060,6 +3072,14 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
 
radv_emit_all_graphics_states(cmd_buffer, info);
radv_emit_draw_packets(cmd_buffer, info);
+
+   /* Prefetch the remaining shaders after the draw has been
+* started.
+*/
+   if (cmd_buffer->state.prefetch_L2_mask) {
+   radv_emit_prefetch_L2(cmd_buffer,
+ cmd_buffer->state.pipeline, 
false);
+   }
}
 
assert(cmd_buffer->cs->cdw <= cdw_max);
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Michel Dänzer]

On 2018-04-04 03:59 AM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> This enables the tile swizzle for some cases of the displayable micro mode,
> and it also fixes an addrlib assertion failure on Vega.
> ---
>  src/amd/common/ac_surface.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> index b294cd85259..2b20a553d51 100644
> --- a/src/amd/common/ac_surface.c
> +++ b/src/amd/common/ac_surface.c
> @@ -408,20 +408,29 @@ static unsigned cik_get_macro_tile_index(struct 
> radeon_surf *surf)
>   tileb = 8 * 8 * surf->bpe;
>   tileb = MIN2(surf->u.legacy.tile_split, tileb);
>  
>   for (index = 0; tileb > 64; index++)
>   tileb >>= 1;
>  
>   assert(index < 16);
>   return index;
>  }
>  
> +static bool get_display_flag(const struct ac_surf_config *config,
> +  const struct radeon_surf *surf)
> +{
> + return surf->flags & RADEON_SURF_SCANOUT &&
> +!(surf->flags & RADEON_SURF_FMASK) &&
> +config->info.samples <= 1 &&
> +surf->bpe >= 4 && surf->bpe <= 8;

surf->bpe is the number of bytes used to store each pixel, right? If so,
this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats can be
displayed.


-- 
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 2/4] nir: add support for bindless_texture samplers

[Karol Herbst]

On Wed, Apr 4, 2018 at 2:16 AM, Jason Ekstrand  wrote:
> On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
>>  src/compiler/nir/nir.h|  1 +
>>  src/compiler/nir/nir_print.c  |  3 +++
>>  3 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
>> b/src/compiler/glsl/glsl_to_nir.cpp
>> index dbb58d82e8f..8e2d96a2361 100644
>> --- a/src/compiler/glsl/glsl_to_nir.cpp
>> +++ b/src/compiler/glsl/glsl_to_nir.cpp
>> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
>>  {
>> unsigned num_srcs;
>> nir_texop op;
>> +   bool bindless =
>> ir->sampler->variable_referenced()->contains_bindless();
>> +
>> switch (ir->op) {
>> case ir_tex:
>>op = nir_texop_tex;
>> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
>>num_srcs++;
>> if (ir->offset != NULL)
>>num_srcs++;
>> +   if (bindless)
>> +  num_srcs=+;
>>
>> nir_tex_instr *instr = nir_tex_instr_create(this->shader, num_srcs);
>>
>> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
>>unreachable("not reached");
>> }
>>
>> -   instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> -
>> unsigned src_number = 0;
>>
>> +   /* for bindless we use the handle src */
>> +   if (bindless) {
>> +  instr->texture = NULL;
>> +  instr->src[src_number].src =
>> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
>> +  instr->src[src_number].src_type = nir_tex_src_handle;
>> +  src_number++;
>> +   } else {
>> +  instr->texture = evaluate_deref(&instr->instr, ir->sampler);
>> +   }
>> +
>> if (ir->coordinate != NULL) {
>>instr->coord_components = ir->coordinate->type->vector_elements;
>>instr->src[src_number].src =
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index f33049d7134..e4d626d263e 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -1218,6 +1218,7 @@ typedef enum {
>> nir_tex_src_texture_offset, /* < dynamically uniform indirect offset
>> */
>> nir_tex_src_sampler_offset, /* < dynamically uniform indirect offset
>> */
>> nir_tex_src_plane,  /* < selects plane for planar textures */
>> +   nir_tex_src_handle, /* < handle for bindless samples */
>
>
> Do we want to have separate texture and sampler handles?  We don't care for
> GL but I kind-of think we will for Vulkan.
>

Don't know. Never looked into vulkan yet. I could rename it to
sample_handle for now and we can add the texture handle later for
vulkan?

>>
>> nir_num_tex_src_types
>>  } nir_tex_src_type;
>>
>> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
>> index 21f13097651..c9431555f2f 100644
>> --- a/src/compiler/nir/nir_print.c
>> +++ b/src/compiler/nir/nir_print.c
>> @@ -778,6 +778,9 @@ print_tex_instr(nir_tex_instr *instr, print_state
>> *state)
>>case nir_tex_src_plane:
>>   fprintf(fp, "(plane)");
>>   break;
>> +  case nir_tex_src_handle:
>> + fprintf(fp, "(handle)");
>> + break;
>>
>>default:
>>   unreachable("Invalid texture source type");
>> --
>> 2.14.3
>>
>> ___
>> 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/4] nir/split_var_copies: handle IMAGE and SAMPLER for bindless vars

[Karol Herbst]

On Wed, Apr 4, 2018 at 2:23 AM, Jason Ekstrand  wrote:
> I have a very strong feeling that this isn't the only place where
> reading/writing IMAGE and SAMPLER variables is going to cause NIR heartburn.
> For example, we have special cases in nir_validate for SUBROUTINE variables
> and we probably need IMAGE and SAMPLER support everywhere we have SUBROUTINE
> plus some (since you can write to them now as well).
>

yeah. I was just making piglit happy here. I guess I will try to run
it with some games using bindless_textures and fix all the crashes I
encounter there at least. More piglit tests might be useful as well.
Sadly I don't see any bindless_textures tests in the CTS :(

>
> On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/compiler/nir/nir_split_var_copies.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir_split_var_copies.c
>> b/src/compiler/nir/nir_split_var_copies.c
>> index bc3ceedbdb8..231a89add4d 100644
>> --- a/src/compiler/nir/nir_split_var_copies.c
>> +++ b/src/compiler/nir/nir_split_var_copies.c
>> @@ -241,6 +241,10 @@ split_var_copies_block(nir_block *block, struct
>> split_var_copies_state *state)
>>  ralloc_steal(state->dead_ctx, instr);
>>   }
>>   break;
>> +  /* for bindless those are uint64 */
>> +  case GLSL_TYPE_IMAGE:
>> +  case GLSL_TYPE_SAMPLER:
>> + assert(src_head->var->data.bindless);
>>case GLSL_TYPE_INT:
>>case GLSL_TYPE_UINT:
>>case GLSL_TYPE_INT16:
>> --
>> 2.14.3
>>
>> ___
>> 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/4] nir/split_var_copies: handle IMAGE and SAMPLER for bindless vars

[Timothy Arceri]

On 04/04/18 20:20, Karol Herbst wrote:

On Wed, Apr 4, 2018 at 2:23 AM, Jason Ekstrand  wrote:

I have a very strong feeling that this isn't the only place where
reading/writing IMAGE and SAMPLER variables is going to cause NIR heartburn.
For example, we have special cases in nir_validate for SUBROUTINE variables
and we probably need IMAGE and SAMPLER support everywhere we have SUBROUTINE
plus some (since you can write to them now as well).



yeah. I was just making piglit happy here. I guess I will try to run
it with some games using bindless_textures and fix all the crashes I
encounter there at least. More piglit tests might be useful as well.
Sadly I don't see any bindless_textures tests in the CTS :(


I don't think games really use the spec to its full extent either. I had 
Dawn of War 3 working without issue with just the uniform support 
implemented on radeonsi.







On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:


Signed-off-by: Karol Herbst 
---
  src/compiler/nir/nir_split_var_copies.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/compiler/nir/nir_split_var_copies.c
b/src/compiler/nir/nir_split_var_copies.c
index bc3ceedbdb8..231a89add4d 100644
--- a/src/compiler/nir/nir_split_var_copies.c
+++ b/src/compiler/nir/nir_split_var_copies.c
@@ -241,6 +241,10 @@ split_var_copies_block(nir_block *block, struct
split_var_copies_state *state)
  ralloc_steal(state->dead_ctx, instr);
   }
   break;
+  /* for bindless those are uint64 */
+  case GLSL_TYPE_IMAGE:
+  case GLSL_TYPE_SAMPLER:
+ assert(src_head->var->data.bindless);
case GLSL_TYPE_INT:
case GLSL_TYPE_UINT:
case GLSL_TYPE_INT16:
--
2.14.3

___
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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #3 from sergio.calleg...@gmail.com ---
Seeing exactly the same on kubuntu 17.10 with the padoka ppa (bringing mesa
18.0.0) and the kde ppa on a haswell laptop.

Many gray items now are much darker.

-- 
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 105846] Assertion failure @ st_atom_array.c:675 when playing Natural Selection 2

[bugzilla-daemon]

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

--- Comment #5 from Timothy Arceri  ---
(In reply to las from comment #2)
> link to coredump (also uploading as attachment):
> https://doc-0o-4k-docs.googleusercontent.com/docs/securesc/
> pum26a1iie2onuvj4oi878g6cm4t7ee5/ogcgqid4h8vlgsdm101jckd6jo5jqqc5/
> 152266320/00738005966732616001/00738005966732616001/
> 11no6HF0WfEwwlE2IoeMx6aigsJ-
> 504qp?e=download&nonce=lohv7ot3cnbqm&user=00738005966732616001&hash=29id47asc
> b0lesgtto26eu8r8cmsptdn

I get access denied trying to view this link. Can you try again to upload here?
I had to try multiple times yesterday but it eventually worked, otherwise can
you place it somewhere with public access?

I tried to run the game but it's missing a library on fedora which it seems
needs to be built from source and configured to run as a service or something
like that which I'm not willing to mess around with.

Anyway are you able to either build mesa from git or use a ppa (assuming you
are using ubuntu) [1] to see if this is still happening in the current dev
version of mesa/llvm?

[1] https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa/+packages

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #4 from sergio.calleg...@gmail.com ---
Disabling compositing, all colors go back to normal. The issue seems to be
realated to translucent elements.

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

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675 when playing Natural Selection 2

[bugzilla-daemon]

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

--- Comment #6 from l...@protonmail.ch ---
Another attempt at sharing my coredump:
https://drive.google.com/open?id=11no6HF0WfEwwlE2IoeMx6aigsJ-504qp

I'll also try to upload it here again, although it will probably take a long
time (am currently downloading my dump with 0.5 MB/s to upload it here...).

I'll update my local version of mesa to the latest git commit once I can (am
not currently on that computer).

Another thing to note: Yesterday I tested for ~1 hour with mesa_glthread=true,
and it didn't crash.
Although previously even with mesa_glthread=true, crashes could happen every 30
to 120 minutes, so I can not be completely sure yet, that it is
mesa_glthread=true causing it, but I *think* it is. I suppose setting those
debug variables just prevented some race condition by causing mesa to run
slower.

Also if you still want to attempt to run the game: Try running the game with
SDL_AUDIODRIVER=alsa and SDL_VIDEODRIVER=x11, that should fix your problem.
Yes, the devs don't make it easy for linux players to run their game.

PS:
I use Arch Linux.

-- 
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] [AppVeyor] mesa master #7374 completed

[AppVeyor]

Build mesa 7374 completed



Commit 1beb80cb56 by Lionel Landwerlin on 4/3/2018 1:41 PM:

intel: compiler: silence compiler warning\n\n../src/intel/compiler/brw_reg.h: In function ‘bool brw_regs_negative_equal(const brw_reg*, const brw_reg*)’:\n../src/intel/compiler/brw_reg.h:305:1: warning: control reaches end of non-void function [-Wreturn-type]\n\nIntroduced by 8f83eea71e233 ("i965: Add negative_equals methods").\n\nSigned-off-by: Lionel Landwerlin \nReviewed-by: Iago Toral Quiroga 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 1/2] compiler/nir: add nir_intrinsics.[ch] to .gitignore

[Rob Clark]

On Wed, Apr 4, 2018 at 3:25 AM, Alejandro Piñeiro  wrote:
> Generated since
> 76dfed8ae2d5c6c509eb2661389be3c6a25077df
> "nir: mako all the intrinsics"

oh, people still do in-tree builds?  I've been spoiled by meson
forcing out-of-tree builds ;-)

Reviewed-by: Rob Clark 

> ---
>  src/compiler/nir/.gitignore | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/.gitignore b/src/compiler/nir/.gitignore
> index 64828eba6d3..dea9ada80fa 100644
> --- a/src/compiler/nir/.gitignore
> +++ b/src/compiler/nir/.gitignore
> @@ -3,3 +3,5 @@ nir_opt_algebraic.c
>  nir_opcodes.c
>  nir_opcodes.h
>  nir_constant_expressions.c
> +nir_intrinsics.h
> +nir_intrinsics.c
> \ No newline at end of file
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

sergio.calleg...@gmail.com changed:

   What|Removed |Added

 CC||sergio.calleg...@gmail.com

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #5 from sergio.calleg...@gmail.com ---
In my case:

KDE Frameworks 5.44.0
Qt 5.9.1 (built against 5.9.1)
KDE Plasma 5.12.4
kernel 4.13.0-38-generic (ubuntu)
Xorg 1.19.5
libdrm 2.4.91 + git
mesa Version: 18.0.0
intel driver 2.99.917 + git @ 2017/03/09 (used with DRI3 and sna)

Integrated Graphics Chipset: Intel(R) Iris(TM) Pro Graphics 5200 that is
haswell mobile Crystal Well Integrated Graphics Controller (rev 08).

-- 
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] Status of radeonsi NIR

[Benedikt Schemmer]

Hi Timothy,

thanks for looking into this.

Dead Island still crashes for me with NIR.

However when I attach apitrace it behaves even more strangely, both TGSI
and NIR crash. TGSI gets a little further. Without apitrace I can play
the game with TGSI and it reproducibly crashes during shader compilation
(Loading Resort screen) with NIR.

Dont spend too much time on this though I think it might be related to
changes in mesa itself (memory leaks?) not necessarily NIR.

I used
apitrace trace --output=/home/nano/deadbeaf5  %command%
in the launch options of steam, otherwise I dont even get this far or
apitrace disattaches itself from the process and no trace is output

tails
==> nircrash <==
186658 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0,
yoffset = 0, width = 1280, height = 720, format = GL_RED, type =
GL_UNSIGNED_BYTE, pixels = blob(921600))
186659 glGenerateMipmap(target = GL_TEXTURE_2D)
186660 glXMakeCurrent(dpy = 0xcb62580, drawable = 0, ctx = NULL) = True
186661 glXMakeCurrent(dpy = 0xcb62580, drawable = 39845908, ctx =
0xce13840) = True
186662 glBindTexture(target = GL_TEXTURE_2D, texture = 129)
186663 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0,
yoffset = 0, width = 640, height = 360, format = GL_RED, type =
GL_UNSIGNED_BYTE, pixels = blob(230400))
186664 glGenerateMipmap(target = GL_TEXTURE_2D)
186665 glXMakeCurrent(dpy = 0xcb62580, drawable = 0, ctx = NULL) = True
18 glXMakeCurrent(dpy = 0xcb62580, drawable = 39845908, ctx =
0xce13840) = True
186667 glBindTexture(target = GL_TEXTURE_2D, texture = 130)

==> nircrash2 <==
167095 glEnable(cap = GL_FRAMEBUFFER_SRGB)
167096 glClearColor(red = 0, green = 0, blue = 0, alpha = 1)
167097 glClear(mask = GL_COLOR_BUFFER_BIT)
167098 glClearColor(red = 0, green = 0, blue = 0, alpha = 0)
167099 glBindTexture(target = GL_TEXTURE_2D, texture = 128)
167100 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0,
yoffset = 0, width = 1280, height = 720, format = GL_RED, type =
GL_UNSIGNED_BYTE, pixels = blob(921600))
167101 glGenerateMipmap(target = GL_TEXTURE_2D)
167102 glXMakeCurrent(dpy = 0xcc99820, drawable = 0, ctx = NULL) = True
167103 glXMakeCurrent(dpy = 0xcc99820, drawable = 39845908, ctx =
0xcf4bd50) = True
167104 glBindTexture(target = GL_TEXTURE_2D, texture = 129)

==> nircrash3 <==
156903 glEnable(cap = GL_FRAMEBUFFER_SRGB)
156904 glClearColor(red = 0, green = 0, blue = 0, alpha = 1)
156905 glClear(mask = GL_COLOR_BUFFER_BIT)
156906 glClearColor(red = 0, green = 0, blue = 0, alpha = 0)
156907 glBindTexture(target = GL_TEXTURE_2D, texture = 128)
156908 glTexSubImage2D(target = GL_TEXTURE_2D, level = 0, xoffset = 0,
yoffset = 0, width = 1280, height = 720, format = GL_RED, type =
GL_UNSIGNED_BYTE, pixels = blob(921600))
156909 glGenerateMipmap(target = GL_TEXTURE_2D)
156910 glXMakeCurrent(dpy = 0xc97f820, drawable = 0, ctx = NULL) = True
156911 glXMakeCurrent(dpy = 0xc97f820, drawable = 39845908, ctx =
0xcc57650) = True
156912 glBindTexture(target = GL_TEXTURE_2D, texture = 129)

==> tgsicrash <==
256272 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 39845908, ctx =
0xc974890) = True
256273 glEnable(cap = GL_CULL_FACE)
256274 glFrontFace(mode = GL_CW)
256275 glDepthMask(flag = GL_FALSE)
256276 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 0, ctx = NULL) = True
256277 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 39845908, ctx =
0xc974890) = True
256278 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 0, ctx = NULL) = True
256279 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 39845908, ctx =
0xc974890) = True
256280 glXSwapIntervalMESA(interval = 0) = 0
256281 glXMakeCurrent(dpy = 0xc6d26d0, drawable = 0, ctx = NULL) = True

==> tgsicrash2 <==
294167 glXMakeCurrent(dpy = 0xcbbc820, drawable = 39845908, ctx =
0xce69b30) = True
294168 glEnable(cap = GL_CULL_FACE)
294169 glFrontFace(mode = GL_CW)
294170 glDepthMask(flag = GL_FALSE)
294171 glXMakeCurrent(dpy = 0xcbbc820, drawable = 0, ctx = NULL) = True
294172 glXMakeCurrent(dpy = 0xcbbc820, drawable = 39845908, ctx =
0xce69b30) = True
294173 glXMakeCurrent(dpy = 0xcbbc820, drawable = 0, ctx = NULL) = True
294174 glXMakeCurrent(dpy = 0xcbbc820, drawable = 39845908, ctx =
0xce69b30) = True
294175 glXSwapIntervalMESA(interval = 0) = 0
294176 glXMakeCurrent(dpy = 0xcbbc820, drawable = 0, ctx = NULL) = True



Am 04.04.2018 um 06:05 schrieb Timothy Arceri:
> On 31/03/18 02:44, Benedikt Schemmer wrote:
>> Hi all,
>>
>> I did some more testing with NIR and wanted to share the results.
>> https://github.com/bendat78/mymesa/tree/mymesa2/testresults
>>
>> Overall it seems nir could be better than tgsi, but there are some
>> shaders with significant regressions and I think that introduces
>> framerate drops that are quite noticable in some games (Total War:
>> WARHAMMER benchmark for example).
> 
> I ran the benchmark for this game and there was no real difference
> between the two backends. Can you try again with current master.
> 
>>
>> See the run* directory for comparisons of tgsi vs ni

[Mesa-dev] [Bug 105846] Assertion failure @ st_atom_array.c:675 when playing Natural Selection 2

[bugzilla-daemon]

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

--- Comment #7 from Timothy Arceri  ---
(In reply to las from comment #6)
> Another attempt at sharing my coredump:
> https://drive.google.com/open?id=11no6HF0WfEwwlE2IoeMx6aigsJ-504qp
> 
> I'll also try to upload it here again, although it will probably take a long
> time (am currently downloading my dump with 0.5 MB/s to upload it here...).

Oh certainly don't upload that here :P I thought it was just the backtrace you
were trying to upload.

> 
> I'll update my local version of mesa to the latest git commit once I can (am
> not currently on that computer).

Thanks.

> 
> Another thing to note: Yesterday I tested for ~1 hour with
> mesa_glthread=true, and it didn't crash.
> Although previously even with mesa_glthread=true, crashes could happen every
> 30 to 120 minutes, so I can not be completely sure yet, that it is
> mesa_glthread=true causing it, but I *think* it is. I suppose setting those
> debug variables just prevented some race condition by causing mesa to run
> slower.
> 
> Also if you still want to attempt to run the game: Try running the game with
> SDL_AUDIODRIVER=alsa and SDL_VIDEODRIVER=x11, that should fix your problem.
> Yes, the devs don't make it easy for linux players to run their game.

I'm still getting: error while loading shared libraries: libsndio.so.6.1:
cannot open shared object file: No such file or directory

At least they have released a 64bit version I guess, so they are trying. The
32bit version was useless.

-- 
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] Status of radeonsi NIR

[Timothy Arceri]

On 04/04/18 21:51, Benedikt Schemmer wrote:

Hi Timothy,

thanks for looking into this.

Dead Island still crashes for me with NIR.


Just to make sure, are you building a 32bit version of Mesa? If not you 
might be running your system Mesa. If you are definitely building Mesa 
32bit then I'll take a closer look tomorrow.

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

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

No I dont.

32-bit is a problem, because Ubuntu wants to literally deinstall itself
before letting me do that (some dependency nonsense).

So I only build 64-bit myself.

For 32-bit & backup 64-bit I use the oibaf ppa which I updated this morning.

I wouldnt spend to much time right now, because mesa git feels a bit
broken. If I switch to stable versions like 17.3.8 most problems
disappear (but so does NIR I guess ;)


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

Hi Timothy,

another game that is behaving strangly is Metro 2033 Redux, also crashes
earlier with apitrace attached. This time TGSI and NIR crash at about
the same time (press any key to continue screen)
Without apitrace TGSI works fine, NIR crashes like above.

==> metronir <==
2059446 glDisableVertexAttribArray(index = 8)
2059447 glDisableVertexAttribArray(index = 9)
2059448 glDisableVertexAttribArray(index = 10)
2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
= GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
= GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi <==
1744537 glEnableVertexAttribArray(index = 4)
1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
1744539 glVertexAttribDivisor(index = 4, divisor = 0)
1744540 glDisableVertexAttribArray(index = 5)
1744541 glDisableVertexAttribArray(index = 6)
1744542 glDisableVertexAttribArray(index = 7)
1744543 glDisableVertexAttribArray(index = 8)
1744544 glDisableVertexAttribArray(index = 9)
1744545 glDisableVertexAttribArray(index = 10)
1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi2 <==
2141178 glVertexAttribDivisor(index = 1, divisor = 0)
2141179 glEnableVertexAttribArray(index = 2)
2141180 glVertexAttribPointer(index = 2, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
2141181 glVertexAttribDivisor(index = 2, divisor = 0)
2141182 glEnableVertexAttribArray(index = 3)
2141183 glVertexAttribPointer(index = 3, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
2141184 glVertexAttribDivisor(index = 3, divisor = 0)
2141185 glEnableVertexAttribArray(index = 4)
2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Marek Olšák]

On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  wrote:

> On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > This enables the tile swizzle for some cases of the displayable micro
> mode,
> > and it also fixes an addrlib assertion failure on Vega.
> > ---
> >  src/amd/common/ac_surface.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> > index b294cd85259..2b20a553d51 100644
> > --- a/src/amd/common/ac_surface.c
> > +++ b/src/amd/common/ac_surface.c
> > @@ -408,20 +408,29 @@ static unsigned cik_get_macro_tile_index(struct
> radeon_surf *surf)
> >   tileb = 8 * 8 * surf->bpe;
> >   tileb = MIN2(surf->u.legacy.tile_split, tileb);
> >
> >   for (index = 0; tileb > 64; index++)
> >   tileb >>= 1;
> >
> >   assert(index < 16);
> >   return index;
> >  }
> >
> > +static bool get_display_flag(const struct ac_surf_config *config,
> > +  const struct radeon_surf *surf)
> > +{
> > + return surf->flags & RADEON_SURF_SCANOUT &&
> > +!(surf->flags & RADEON_SURF_FMASK) &&
> > +config->info.samples <= 1 &&
> > +surf->bpe >= 4 && surf->bpe <= 8;
>
> surf->bpe is the number of bytes used to store each pixel, right? If so,
> this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats can be
> displayed.
>

Sure, but what are the chances they will be displayed with the current
stack? GLX doesn't have 16bpp visuals for on-screen rendering.

Marek


>
> --
> 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 15/17] radeonsi: always prefetch later shaders after the draw packet

[Marek Olšák]

On Wed, Apr 4, 2018, 6:07 AM Samuel Pitoiset 
wrote:

>
>
> On 04/04/2018 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > so that the draw is started as soon as possible.
> > ---
> >   src/gallium/drivers/radeonsi/si_cp_dma.c | 68
> ++--
> >   src/gallium/drivers/radeonsi/si_pipe.h   |  2 +-
> >   src/gallium/drivers/radeonsi/si_state_draw.c | 11 -
> >   src/util/bitscan.h   |  8 
> >   4 files changed, 61 insertions(+), 28 deletions(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> > index 15bd305a350..ea2c7cf7198 100644
> > --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> > +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> > @@ -514,80 +514,98 @@ static void cik_prefetch_shader_async(struct
> si_context *sctx,
> >   static void cik_prefetch_VBO_descriptors(struct si_context *sctx)
> >   {
> >   if (!sctx->vertex_elements)
> >   return;
> >
> >   cik_prefetch_TC_L2_async(sctx, &sctx->vb_descriptors_buffer->b.b,
> >sctx->vb_descriptors_offset,
> >
> sctx->vertex_elements->desc_list_byte_size);
> >   }
> >
> > -void cik_emit_prefetch_L2(struct si_context *sctx)
> > +/**
> > + * Prefetch shaders and VBO descriptors.
> > + *
> > + * \param first_two  Whether only the first 2 items should be
> prefetched,
> > + *   which are usually the API VS and VBO descriptors.
> > + */
> > +void cik_emit_prefetch_L2(struct si_context *sctx, bool first_two)
> >   {
> > + unsigned mask;
> > +
> > + assert(sctx->prefetch_L2_mask);
> > +
> > + if (first_two) {
> > + mask = 1 << u_bit_scan16(&sctx->prefetch_L2_mask);
> > +
> > + if (sctx->prefetch_L2_mask)
> > + mask |= 1 << u_bit_scan16(&sctx->prefetch_L2_mask);
>
> Where do you reset the prefetch L2 mask ? It looks like to me that you
> are going to prefetch VS/VBOs twice in the fast draw path.
>

u_bit_scan16 clears the returned bit.

Marek

> + } else {
> > + mask = sctx->prefetch_L2_mask;
> > + sctx->prefetch_L2_mask = 0;
> > + }
> > +
> >   /* Prefetch shaders and VBO descriptors to TC L2. */
> >   if (sctx->b.chip_class >= GFX9) {
> >   /* Choose the right spot for the VBO prefetch. */
> >   if (sctx->tes_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_HS)
> > + if (mask & SI_PREFETCH_HS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.hs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
> > + if (mask & SI_PREFETCH_GS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.gs);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> >   } else if (sctx->gs_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_GS)
> > + if (mask & SI_PREFETCH_GS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.gs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> >   } else {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_VS)
> > + if (mask & SI_PREFETCH_VS)
> >   cik_prefetch_shader_async(sctx,
> sctx->queued.named.vs);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VBO_DESCRIPTORS)
> >   cik_prefetch_VBO_descriptors(sctx);
> >   }
> >   } else {
> >   /* SI-CI-VI */
> >   /* Choose the right spot for the VBO prefetch. */
> >   if (sctx->tes_shader.cso) {
> > - if (sctx->prefetch_L2_mask & SI_PREFETCH_LS)
> > + if (mask & SI_PREFETCH_LS)
> >   cik_prefetch_shader_async(sctx, sctx->
> queued.named.ls);
> > - if (sctx->prefetch_L2_mask &
> SI_PREFETCH_VBO_DESCRIPTORS)
> > + if (mask & SI_PREFETCH_VB

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Michel Dänzer]

On 2018-04-04 02:57 PM, Marek Olšák wrote:
> On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  > wrote:
> 
> On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > From: Marek Olšák mailto:marek.ol...@amd.com>>
> >
> > This enables the tile swizzle for some cases of the displayable
> micro mode,
> > and it also fixes an addrlib assertion failure on Vega.
> > ---
> >  src/amd/common/ac_surface.c | 18 ++
> >  1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
> > index b294cd85259..2b20a553d51 100644
> > --- a/src/amd/common/ac_surface.c
> > +++ b/src/amd/common/ac_surface.c
> > @@ -408,20 +408,29 @@ static unsigned
> cik_get_macro_tile_index(struct radeon_surf *surf)
> >       tileb = 8 * 8 * surf->bpe;
> >       tileb = MIN2(surf->u.legacy.tile_split, tileb);
> >
> >       for (index = 0; tileb > 64; index++)
> >               tileb >>= 1;
> >
> >       assert(index < 16);
> >       return index;
> >  }
> >
> > +static bool get_display_flag(const struct ac_surf_config *config,
> > +                          const struct radeon_surf *surf)
> > +{
> > +     return surf->flags & RADEON_SURF_SCANOUT &&
> > +            !(surf->flags & RADEON_SURF_FMASK) &&
> > +            config->info.samples <= 1 &&
> > +            surf->bpe >= 4 && surf->bpe <= 8;
> 
> surf->bpe is the number of bytes used to store each pixel, right? If so,
> this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats can be
> displayed.
> 
> 
> Sure, but what are the chances they will be displayed with the current
> stack? GLX doesn't have 16bpp visuals for on-screen rendering.

Maybe not when the X server runs at depth 24, but it can also run at
depths 8, 15 & 16, in which case displayable surfaces with bpe == 1 or 2
are needed even before GLX even comes into the picture.


-- 
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] Status of radeonsi NIR

[Benedikt Schemmer]

Just for baseline:
I have no problem running and creating apitraces from
Bioshock Infinite or TombRaider, I think both 32-bit
CAT Interstellar which is 64-bit

using this command
R600_DEBUG=nir apitrace trace --output=/home/nano/bio2 %command%

and building either the 64 or 32 bit version of apitrace

Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
> On 04/04/18 21:51, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> thanks for looking into this.
>>
>> Dead Island still crashes for me with NIR.
> 
> Just to make sure, are you building a 32bit version of Mesa? If not you
> might be running your system Mesa. If you are definitely building Mesa
> 32bit then I'll take a closer look tomorrow.
R600_DEBUG=nir apitrace trace --output=/home/nano/bio2 %command%
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #10 from Ben Clapp  ---
Regarding the freeze when using the OpenGL backend with Mesa 18.0, it seems a
different user has already reported that bug:
https://bugs.dolphin-emu.org/issues/10904
https://bugs.freedesktop.org/show_bug.cgi?id=105339

Apologies for the late response Timothy.

>Do you think you could get a dump of the NIR and LLVM IR for the shaders in 
>question and attach it here? You can use the following environment var to dump 
>?the shaders: RADV_DEBUG=shaders
I'm struggling to properly dump the shaders because RADV now has an on-disk
shader cache, and RADV_DEBUG=shaders seems to only print out shaders when they
are actually compiled for the first time.
How can I clear and/or disable the shader cache?

>You also might be able to catch the attention of some devs if you jump on the 
>freenode #radeon IRC channel.
I'm already lurking in there, but perhaps I'll actually say something over
there sometime soon.

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

Re: [Mesa-dev] [PATCH 3/3] radv: implement a fast prefetch path for the vertex stage

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Wed, Apr 4, 2018 at 12:12 PM, Samuel Pitoiset
 wrote:
> This allows to start draws as soon as possible.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 40 
> ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 393d9ba4f4..0e59f99799 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -640,39 +640,48 @@ radv_emit_shader_prefetch(struct radv_cmd_buffer 
> *cmd_buffer,
>
>  static void
>  radv_emit_prefetch_L2(struct radv_cmd_buffer *cmd_buffer,
> - struct radv_pipeline *pipeline)
> + struct radv_pipeline *pipeline,
> + bool vertex_stage_only)
>  {
> struct radv_cmd_state *state = &cmd_buffer->state;
> +   uint32_t mask = state->prefetch_L2_mask;
>
> if (cmd_buffer->device->physical_device->rad_info.chip_class < CIK)
> return;
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_VS)
> +   if (vertex_stage_only) {
> +   /* Fast prefetch path for starting draws as soon as possible.
> +*/
> +   mask = state->prefetch_L2_mask & (RADV_PREFETCH_VS |
> + 
> RADV_PREFETCH_VBO_DESCRIPTORS);
> +   }
> +
> +   if (mask & RADV_PREFETCH_VS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_VERTEX]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_VBO_DESCRIPTORS)
> +   if (mask & RADV_PREFETCH_VBO_DESCRIPTORS)
> si_cp_dma_prefetch(cmd_buffer, state->vb_va, state->vb_size);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_TCS)
> +   if (mask & RADV_PREFETCH_TCS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_TESS_CTRL]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_TES)
> +   if (mask & RADV_PREFETCH_TES)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_TESS_EVAL]);
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_GS) {
> +   if (mask & RADV_PREFETCH_GS) {
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_GEOMETRY]);
> radv_emit_shader_prefetch(cmd_buffer, 
> pipeline->gs_copy_shader);
> }
>
> -   if (state->prefetch_L2_mask & RADV_PREFETCH_PS)
> +   if (mask & RADV_PREFETCH_PS)
> radv_emit_shader_prefetch(cmd_buffer,
>   
> pipeline->shaders[MESA_SHADER_FRAGMENT]);
>
> -   state->prefetch_L2_mask = 0;
> +   state->prefetch_L2_mask &= ~mask;
>  }
>
>  static void
> @@ -3042,7 +3051,7 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
>  */
> if (cmd_buffer->state.prefetch_L2_mask) {
> radv_emit_prefetch_L2(cmd_buffer,
> - cmd_buffer->state.pipeline);
> + cmd_buffer->state.pipeline, 
> false);
> }
> } else {
> /* If we don't wait for idle, start prefetches first, then set
> @@ -3051,8 +3060,11 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
> si_emit_cache_flush(cmd_buffer);
>
> if (cmd_buffer->state.prefetch_L2_mask) {
> +   /* Only prefetch the vertex shader and VBO descriptors
> +* in order to start the draw as soon as possible.
> +*/
> radv_emit_prefetch_L2(cmd_buffer,
> - cmd_buffer->state.pipeline);
> + cmd_buffer->state.pipeline, 
> true);
> }
>
> if (!radv_upload_graphics_shader_descriptors(cmd_buffer, 
> pipeline_is_dirty))
> @@ -3060,6 +3072,14 @@ radv_draw(struct radv_cmd_buffer *cmd_buffer,
>
> radv_emit_all_graphics_states(cmd_buffer, info);
> radv_emit_draw_packets(cmd_buffer, info);
> +
> +   /* Prefetch the remaining shaders after the draw has been
> +* started.
> +*/
> +   if (cmd_buffer->state.prefetch_L2_mask) {
> +   radv_emit_prefetch_L2(cmd_buffer,
> + cmd_buffer->state.pipeline, 
> false);
> +   }
> }
>
> assert(cmd_buffer->cs->cdw <= cdw_max);
> --
> 2.16.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #6 from Tapani Pälli  ---
Pretty sure this is the same bug, I'm not sure if the Xorg patch is in place
since 32bit visual seems to be srgb capable (see 's'), it shouldn't be like
this with the patch:

--- 8< ---
0x086 32 tc  0  32  0 r  y .   8  8  8  8 .  s  0 24  8  0  0  0  0  0 0 None

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

Tapani Pälli  changed:

   What|Removed |Added

 CC||lem...@gmail.com

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

Re: [Mesa-dev] Status of radeonsi NIR

[Timothy Arceri]

On 04/04/18 22:53, Benedikt Schemmer wrote:

Hi Timothy,

another game that is behaving strangly is Metro 2033 Redux, also crashes
earlier with apitrace attached. This time TGSI and NIR crash at about
the same time (press any key to continue screen)
Without apitrace TGSI works fine, NIR crashes like above.


Strange. This game works fine for me on NIR, what card did you say you 
were testing on?




==> metronir <==
2059446 glDisableVertexAttribArray(index = 8)
2059447 glDisableVertexAttribArray(index = 9)
2059448 glDisableVertexAttribArray(index = 10)
2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
= GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)
2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
blob(352), usage = GL_DYNAMIC_DRAW)
2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
= GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi <==
1744537 glEnableVertexAttribArray(index = 4)
1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
1744539 glVertexAttribDivisor(index = 4, divisor = 0)
1744540 glDisableVertexAttribArray(index = 5)
1744541 glDisableVertexAttribArray(index = 6)
1744542 glDisableVertexAttribArray(index = 7)
1744543 glDisableVertexAttribArray(index = 8)
1744544 glDisableVertexAttribArray(index = 9)
1744545 glDisableVertexAttribArray(index = 10)
1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer = 3)

==> metrotgsi2 <==
2141178 glVertexAttribDivisor(index = 1, divisor = 0)
2141179 glEnableVertexAttribArray(index = 2)
2141180 glVertexAttribPointer(index = 2, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
2141181 glVertexAttribDivisor(index = 2, divisor = 0)
2141182 glEnableVertexAttribArray(index = 3)
2141183 glVertexAttribPointer(index = 3, size = 4, type =
GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
2141184 glVertexAttribDivisor(index = 3, divisor = 0)
2141185 glEnableVertexAttribArray(index = 4)
2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
stride = 32, pointer = 0x18)
2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete


Am 04.04.2018 um 14:06 schrieb Timothy Arceri:

On 04/04/18 21:51, Benedikt Schemmer wrote:

Hi Timothy,

thanks for looking into this.

Dead Island still crashes for me with NIR.


Just to make sure, are you building a 32bit version of Mesa? If not you
might be running your system Mesa. If you are definitely building Mesa
32bit then I'll take a closer look tomorrow.

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

Re: [Mesa-dev] Status of radeonsi NIR

[Benedikt Schemmer]

RX460 4GB

Am 04.04.2018 um 15:59 schrieb Timothy Arceri:
> On 04/04/18 22:53, Benedikt Schemmer wrote:
>> Hi Timothy,
>>
>> another game that is behaving strangly is Metro 2033 Redux, also crashes
>> earlier with apitrace attached. This time TGSI and NIR crash at about
>> the same time (press any key to continue screen)
>> Without apitrace TGSI works fine, NIR crashes like above.
> 
> Strange. This game works fine for me on NIR, what card did you say you
> were testing on?
> 
>>
>> ==> metronir <==
>> 2059446 glDisableVertexAttribArray(index = 8)
>> 2059447 glDisableVertexAttribArray(index = 9)
>> 2059448 glDisableVertexAttribArray(index = 10)
>> 2059449 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>> 2059450 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
>> blob(352), usage = GL_DYNAMIC_DRAW)
>> 2059451 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 720, type
>> = GL_UNSIGNED_SHORT, indices = 0x176a6, basevertex = 15823)
>> 2059452 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>> 2059453 glBufferData(target = GL_UNIFORM_BUFFER, size = 352, data =
>> blob(352), usage = GL_DYNAMIC_DRAW)
>> 2059454 glDrawElementsBaseVertex(mode = GL_TRIANGLES, count = 711, type
>> = GL_UNSIGNED_SHORT, indices = 0x17c46, basevertex = 16303)
>> 2059455 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>>
>> ==> metrotgsi <==
>> 1744537 glEnableVertexAttribArray(index = 4)
>> 1744538 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
>> stride = 32, pointer = 0x18)
>> 1744539 glVertexAttribDivisor(index = 4, divisor = 0)
>> 1744540 glDisableVertexAttribArray(index = 5)
>> 1744541 glDisableVertexAttribArray(index = 6)
>> 1744542 glDisableVertexAttribArray(index = 7)
>> 1744543 glDisableVertexAttribArray(index = 8)
>> 1744544 glDisableVertexAttribArray(index = 9)
>> 1744545 glDisableVertexAttribArray(index = 10)
>> 1744546 glBindBufferBase(target = GL_UNIFORM_BUFFER, index = 1, buffer
>> = 3)
>>
>> ==> metrotgsi2 <==
>> 2141178 glVertexAttribDivisor(index = 1, divisor = 0)
>> 2141179 glEnableVertexAttribArray(index = 2)
>> 2141180 glVertexAttribPointer(index = 2, size = 4, type =
>> GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x10)
>> 2141181 glVertexAttribDivisor(index = 2, divisor = 0)
>> 2141182 glEnableVertexAttribArray(index = 3)
>> 2141183 glVertexAttribPointer(index = 3, size = 4, type =
>> GL_UNSIGNED_BYTE, normalized = GL_TRUE, stride = 32, pointer = 0x14)
>> 2141184 glVertexAttribDivisor(index = 3, divisor = 0)
>> 2141185 glEnableVertexAttribArray(index = 4)
>> 2141186 glVertexAttribIPointer(index = 4, size = 4, type = GL_SHORT,
>> stride = 32, pointer = 0x18)
>> 2141187 glVertexAttribDivisor(index = 4, divisor = 0) // incomplete
>>
>>
>> Am 04.04.2018 um 14:06 schrieb Timothy Arceri:
>>> On 04/04/18 21:51, Benedikt Schemmer wrote:
 Hi Timothy,

 thanks for looking into this.

 Dead Island still crashes for me with NIR.
>>>
>>> Just to make sure, are you building a 32bit version of Mesa? If not you
>>> might be running your system Mesa. If you are definitely building Mesa
>>> 32bit then I'll take a closer look tomorrow.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Kyriazis, George]

Thank you!

Reviewed-By: George Kyriazis 
mailto:george.kyria...@intel.com>>

On Apr 4, 2018, at 3:22 AM, Mike Lothian 
mailto:m...@fireburn.co.uk>> wrote:

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < > (Vinson Lee)

v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)

Signed-of-by: Mike Lothian mailto:m...@fireburn.co.uk>>
Tested-by: Vinson Lee mailto:v...@freedesktop.org>>
---
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..19f68c2bb6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
#include "llvm/Support/DynamicLibrary.h"
#include "llvm/Transforms/IPO.h"
#include "llvm/Transforms/Scalar.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/Utils.h"
+#endif
#include "llvm/Support/Host.h"
#include "llvm/Support/DynamicLibrary.h"

--
2.17.0


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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #7 from Tapani Pälli  ---
I see the patch in "server-1.19-branch" but it looks like there has not been a
release which would include the fix :/ Release 1.19.7 will have it.

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #11 from Timothy Arceri  ---
(In reply to Ben Clapp from comment #10)
> Regarding the freeze when using the OpenGL backend with Mesa 18.0, it seems
> a different user has already reported that bug:
> https://bugs.dolphin-emu.org/issues/10904
> https://bugs.freedesktop.org/show_bug.cgi?id=105339
> 
> Apologies for the late response Timothy.
> 
> >Do you think you could get a dump of the NIR and LLVM IR for the shaders in 
> >question and attach it here? You can use the following environment var to 
> >dump ?the shaders: RADV_DEBUG=shaders
> I'm struggling to properly dump the shaders because RADV now has an on-disk
> shader cache, and RADV_DEBUG=shaders seems to only print out shaders when
> they are actually compiled for the first time.
> How can I clear and/or disable the shader cache?

RADV_DEBUG=nocache or MESA_GLSL_CACHE_DISABLE=1 should do it. Also you can dump
the unoptimised LLVM IR with RADV_DEBUG=preoptir which can be useful sometimes.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #8 from sergio.calleg...@gmail.com ---
I do not know if the following information is relevant, but in doubt I am
providing it:

I was the original reporter of
https://bugs.freedesktop.org/show_bug.cgi?id=103699. The issue with the firefox
menus has been fixed for a while on my system and even with mesa 18, I get the
firefox menus fine.

It is unclear to me if the issue is with something that should not happen with
the opengl visuals or with something that happens but is then mismanaged by
kwin. To assure that the kwin developers are aware of the issue, I have cross
posted on their bug repo as https://bugs.kde.org/show_bug.cgi?id=392716

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #9 from sergio.calleg...@gmail.com ---
A quick question... the patch being mentioned is related to the part of xorg
that usually gets packaged as xserver-xorg-core, right? Not to the individual
video drivers such as those packaged in xserver-xorg-video-intel, correct?

I am asking because ubuntu has various PPAs providing updated graphic stacks,
but all of them appear to be currently shipping the updated video-xxx packages
but no updated core package for xorg.

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #12 from Ben Clapp  ---
Created attachment 138582
  --> https://bugs.freedesktop.org/attachment.cgi?id=138582&action=edit
Dump of optimized shaders in scene with incorrect rendering of vertex color.

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #13 from Ben Clapp  ---
Created attachment 138583
  --> https://bugs.freedesktop.org/attachment.cgi?id=138583&action=edit
Dump of unoptimized shaders in scene with incorrect rendering of vertex color.

OK, here's your shader dumps attached to the ticket, both optimized and
optimized.
There may be some unrelated shaders included in the dump due to the way
dolphin/shader dumping works, but not sure there's much I can do about that.
Let me know if you need anything else.

-- 
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 v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Are you able to push this for me on my behalf?

On Wed, 4 Apr 2018 at 15:04 Kyriazis, George 
wrote:

> Thank you!
>
> Reviewed-By: George Kyriazis 
>
> On Apr 4, 2018, at 3:22 AM, Mike Lothian  wrote:
>
> Include llvm/Transforms/Utils.h with the newest LLVM 7
>
> v2: Include with " " rather than < > (Vinson Lee)
>
> v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)
>
> Signed-of-by: Mike Lothian 
> Tested-by: Vinson Lee 
> ---
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> index 031bced8a0..19f68c2bb6 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> @@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
> #include "llvm/Support/DynamicLibrary.h"
> #include "llvm/Transforms/IPO.h"
> #include "llvm/Transforms/Scalar.h"
> +#if LLVM_VERSION_MAJOR >= 7
> +#include "llvm/Transforms/Utils.h"
> +#endif
> #include "llvm/Support/Host.h"
> #include "llvm/Support/DynamicLibrary.h"
>
> --
> 2.17.0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

[Roland Scheidegger]

Am 04.04.2018 um 05:42 schrieb Timothy Arceri:
> On 04/04/18 13:22, Roland Scheidegger wrote:
>> Am 04.04.2018 um 05:03 schrieb Timothy Arceri:
>>> On 04/04/18 12:44, Roland Scheidegger wrote:
 Am 04.04.2018 um 04:32 schrieb Timothy Arceri:
> On 04/04/18 11:58, Roland Scheidegger wrote:
>> AFAIK these filters (and I've never looked into them) should be
>> transparent to hw drivers. Hence a cap bit doesn't make sense, and if
>> it's broken we shouldn't just paper over this.
>
> I created a CAP because the AMD devs have no interest in supporting
> this
> feature [1]. Even if they are transparent to drivers I don't see why
> drivers should be forced to enable them if they don't want to. CCing
> Marek for his opinion.

 I still don't see why using cap bits for bugs is a good idea.
>>>
>>> Well I see it as a CAP for an unwanted feature that just happens to not
>>> work currently.
>>>
 (Even more so if the bug actually would be in the postprocess, but I've
 no idea there really.)
>>>
>>> It's crashing in src/gallium/drivers/radeonsi/si_state_draw.c
>>
>> Doesn't necessarily mean the bug is in the driver.
>> Not sure it's really worth fixing it this way neither - people are
>> probably just as confused why pp won't work than they are if it's
>> crashing...
> 
> Well I can either update the webpage to say its disabled for radeonsi or
> I can close the bugs as won't fix and let people wonder why its crashing
> potentially filling another bug report. The first bug was filed a year
> ago and nobody seems to want to fix it. Either way I don't care to much
> but disabling the feature seems like a better way to go than just
> letting it crash forever.

Alright, if the bug is that old I suppose there's really no interest in
actually fixing it...
So I suppose that would be an improvement...

Roland


>>
>>
>> Roland
>>
>>>

 Roland

>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D99549-23c3&d=DwICaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=s23eRwsegKslN9P2JpzYmfnEOt7uPtVLO6XI3-BR_h4&s=LnLvs_TtyuJE3MWrA16CVWgkwxKkfKCuXHJDbtO3KGo&e=
>
>
>
>
>>
>> Roland
>>
>> Am 03.04.2018 um 13:38 schrieb Timothy Arceri:
>>> For radeonsi these seem to have been somewhat broken for over a
>>> year, and as of recently they cause the driver to crash.
>>>
>>> This patch adds a CAP for the filters and enables the CAP for all
>>> driver except radeonsi.
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D99549&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=FsyE0Iv-1HkgmJ_6JgvnISAuUbjQthRX9OcSu3BUhgc&s=5iJ7ErqsBvMPRH06U44_GD_7EvtIFP8hzyKeeDtIxxE&e=
>>>
>>>
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D105026&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0&m=FsyE0Iv-1HkgmJ_6JgvnISAuUbjQthRX9OcSu3BUhgc&s=PeI7pgvz9cprwPELTcdw_TUZHrtj1tt6KjHa-4rVRtY&e=
>>>
>>>
>>>
>>> ---
>>>     src/gallium/docs/source/screen.rst   |  2 ++
>>>     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_get.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/vc5/vc5_screen.c |  1 +
>>>     src/gallium/drivers/virgl/virgl_screen.c |  2 ++
>>>     src/gallium/include/pipe/p_defines.h |  1 +
>>>     src/gallium/state_trackers/dri/dri_screen.c  | 15
>>> ---
>>>     19 files changed, 28 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/src/gallium/docs/source/screen.rst
>>> b/src/gallium/docs/source/screen.rst
>>> index 3837360fb40..22aba928580 100644
>>> --- a/src/gallium/docs/source/screen.rst
>>> +++ b/src/gallium/docs/source/screen.rst
>>> @@ -420,6 +420,8 @@ The integer capabilities:
>>>   by the driver, and the driver can throw as

Re: [Mesa-dev] [PATCH 1/4] mesa: add INTEL_blackhole_render

[Lionel Landwerlin]

On 15/03/18 16:03, Emil Velikov wrote:

+EXT(INTEL_blackhole_render  , INTEL_blackhole_render   
  , GLL, GLC,  x , ES2, 2018)

Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
Wrt GLES side the spec does not mention anything - is that ES1, ES2,
which version etc.
Worth keeping it simple and update the spec to say ES2+?

The patch implements Enable/Disable, yet IsEnabled is missing.
Actually the gl.xml was set to enable it for GL/GLES2, although written 
against the ES3 spec.


Looking at the other extensions, they don't seem to specify what version 
of GLES it applies to.


So I'm still not quite sure what I should put into this extension table :|

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

Re: [Mesa-dev] [PATCH 2/4] nir: add support for bindless_texture samplers

[Jason Ekstrand]

On Wed, Apr 4, 2018 at 3:18 AM, Karol Herbst  wrote:

> On Wed, Apr 4, 2018 at 2:16 AM, Jason Ekstrand 
> wrote:
> > On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
> >>
> >> Signed-off-by: Karol Herbst 
> >> ---
> >>  src/compiler/glsl/glsl_to_nir.cpp | 17 +++--
> >>  src/compiler/nir/nir.h|  1 +
> >>  src/compiler/nir/nir_print.c  |  3 +++
> >>  3 files changed, 19 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/compiler/glsl/glsl_to_nir.cpp
> >> b/src/compiler/glsl/glsl_to_nir.cpp
> >> index dbb58d82e8f..8e2d96a2361 100644
> >> --- a/src/compiler/glsl/glsl_to_nir.cpp
> >> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> >> @@ -1971,6 +1971,8 @@ nir_visitor::visit(ir_texture *ir)
> >>  {
> >> unsigned num_srcs;
> >> nir_texop op;
> >> +   bool bindless =
> >> ir->sampler->variable_referenced()->contains_bindless();
> >> +
> >> switch (ir->op) {
> >> case ir_tex:
> >>op = nir_texop_tex;
> >> @@ -2044,6 +2046,8 @@ nir_visitor::visit(ir_texture *ir)
> >>num_srcs++;
> >> if (ir->offset != NULL)
> >>num_srcs++;
> >> +   if (bindless)
> >> +  num_srcs=+;
> >>
> >> nir_tex_instr *instr = nir_tex_instr_create(this->shader,
> num_srcs);
> >>
> >> @@ -2069,10 +2073,19 @@ nir_visitor::visit(ir_texture *ir)
> >>unreachable("not reached");
> >> }
> >>
> >> -   instr->texture = evaluate_deref(&instr->instr, ir->sampler);
> >> -
> >> unsigned src_number = 0;
> >>
> >> +   /* for bindless we use the handle src */
> >> +   if (bindless) {
> >> +  instr->texture = NULL;
> >> +  instr->src[src_number].src =
> >> + nir_src_for_ssa(evaluate_rvalue(ir->sampler));
> >> +  instr->src[src_number].src_type = nir_tex_src_handle;
> >> +  src_number++;
> >> +   } else {
> >> +  instr->texture = evaluate_deref(&instr->instr, ir->sampler);
> >> +   }
> >> +
> >> if (ir->coordinate != NULL) {
> >>instr->coord_components = ir->coordinate->type->vector_elements;
> >>instr->src[src_number].src =
> >> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> >> index f33049d7134..e4d626d263e 100644
> >> --- a/src/compiler/nir/nir.h
> >> +++ b/src/compiler/nir/nir.h
> >> @@ -1218,6 +1218,7 @@ typedef enum {
> >> nir_tex_src_texture_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_sampler_offset, /* < dynamically uniform indirect offset
> >> */
> >> nir_tex_src_plane,  /* < selects plane for planar textures
> */
> >> +   nir_tex_src_handle, /* < handle for bindless samples */
> >
> >
> > Do we want to have separate texture and sampler handles?  We don't care
> for
> > GL but I kind-of think we will for Vulkan.
> >
>
> Don't know. Never looked into vulkan yet. I could rename it to
> sample_handle for now and we can add the texture handle later for
> vulkan?
>

Sure.  Or we can just add both now and add nir_print support for both and
then we have them.  It's just an enum.  It's not like it costs us much.


> >>
> >> nir_num_tex_src_types
> >>  } nir_tex_src_type;
> >>
> >> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> >> index 21f13097651..c9431555f2f 100644
> >> --- a/src/compiler/nir/nir_print.c
> >> +++ b/src/compiler/nir/nir_print.c
> >> @@ -778,6 +778,9 @@ print_tex_instr(nir_tex_instr *instr, print_state
> >> *state)
> >>case nir_tex_src_plane:
> >>   fprintf(fp, "(plane)");
> >>   break;
> >> +  case nir_tex_src_handle:
> >> + fprintf(fp, "(handle)");
> >> + break;
> >>
> >>default:
> >>   unreachable("Invalid texture source type");
> >> --
> >> 2.14.3
> >>
> >> ___
> >> 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/4] nir/split_var_copies: handle IMAGE and SAMPLER for bindless vars

[Jason Ekstrand]

On Wed, Apr 4, 2018 at 3:33 AM, Timothy Arceri 
wrote:

> On 04/04/18 20:20, Karol Herbst wrote:
>
>> On Wed, Apr 4, 2018 at 2:23 AM, Jason Ekstrand 
>> wrote:
>>
>>> I have a very strong feeling that this isn't the only place where
>>> reading/writing IMAGE and SAMPLER variables is going to cause NIR
>>> heartburn.
>>> For example, we have special cases in nir_validate for SUBROUTINE
>>> variables
>>> and we probably need IMAGE and SAMPLER support everywhere we have
>>> SUBROUTINE
>>> plus some (since you can write to them now as well).
>>>
>>>
>> yeah. I was just making piglit happy here. I guess I will try to run
>> it with some games using bindless_textures and fix all the crashes I
>> encounter there at least. More piglit tests might be useful as well.
>> Sadly I don't see any bindless_textures tests in the CTS :(
>>
>
> I don't think games really use the spec to its full extent either. I had
> Dawn of War 3 working without issue with just the uniform support
> implemented on radeonsi.
>

Sounds like someone gets to write some more piglit tests. :-)

--Jason


>
>>
>>> On Tue, Apr 3, 2018 at 6:21 AM, Karol Herbst  wrote:
>>>

 Signed-off-by: Karol Herbst 
 ---
   src/compiler/nir/nir_split_var_copies.c | 4 
   1 file changed, 4 insertions(+)

 diff --git a/src/compiler/nir/nir_split_var_copies.c
 b/src/compiler/nir/nir_split_var_copies.c
 index bc3ceedbdb8..231a89add4d 100644
 --- a/src/compiler/nir/nir_split_var_copies.c
 +++ b/src/compiler/nir/nir_split_var_copies.c
 @@ -241,6 +241,10 @@ split_var_copies_block(nir_block *block, struct
 split_var_copies_state *state)
   ralloc_steal(state->dead_ctx, instr);
}
break;
 +  /* for bindless those are uint64 */
 +  case GLSL_TYPE_IMAGE:
 +  case GLSL_TYPE_SAMPLER:
 + assert(src_head->var->data.bindless);
 case GLSL_TYPE_INT:
 case GLSL_TYPE_UINT:
 case GLSL_TYPE_INT16:
 --
 2.14.3

 ___
 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #14 from Samuel Pitoiset  ---
Can you attach your vulkaninfo too?

-- 
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 00/14] Enable sRGB-encoded fast-clears on CannonLake

[Nanley Chery]

On Tue, Apr 03, 2018 at 03:50:38PM -0700, Jason Ekstrand wrote:
> I think I've reviewed all the ones that make significant functional
> changes.  The exception is the patch that makes us not do a fast depth
> clear.  I think what you did is probably better but I haven't thought about
> it enough to be sure.
> 

I can drop this patch. Although I think it's an improvement, I should
probably find some benchmarks to substantiate the claim.

> I'm not sure what I think about the last several that mostly move code
> around.  On the one hand, it kind-of unifies the "should we fast-clear"
> question into intel_mipmap_tree.c.  On the other hand, it pulls it away
> from the function that actually does the clear spreads the code out more.
> Multiple times in the past, I've wanted to pull the guts of the color
> clearing code out of brw_blorp.c and into brw_clear.c and just have
> brw_clear_miptree and brw_ccs/mcs_clear_miptree helpers.  Then all of those
> decisions would be together in brw_clear.c.  In any case, I'll think on it
> more.
> 

I understand your concern. There are multiple ways to go about hiding
::fast_clear_color and the one I went for (with super-powered setters)
does have the issues you bring up. I'll send out a v2 that accomplishes
hiding it in a less invasive manner. Please, let me know which version
you prefer (if either).

-Nanley

> --Jason
> 
> 
> On Fri, Mar 30, 2018 at 11:12 AM, Nanley Chery 
> wrote:
> 
> > Starting with CannonLake, the sampler no longer decodes the surface
> > state clear color when using an sRGB-formatted texture. This change
> > requires that our driver perform this decode in software instead. We
> > accounted for this change initially by disabling fast-clears when sRGB
> > encode was enabled. This series implements the software decode and
> > re-enables sRGB-encoded fast-clears.
> >
> > The software decode is performed through a new getter for the miptree
> > clear color. To keep the miptree API balanced and to discourage its
> > users from accessing the clear color field directly, we add a getter for
> > the depth clear value and change the existing setters so that the user
> > no longer needs to know the current clear color to perform an efficient
> > clear operation.
> >
> > Two piglit tests have been modified to test that the linearization of
> > the clear color occurs (when appropriate) for shader texture() calls and
> > on framebuffer blit sources. The modification patches can be found here:
> > https://lists.freedesktop.org/archives/piglit/2018-March/023996.html
> >
> > Jason Ekstrand (1):
> >   util/srgb: Add a float sRGB -> linear helper
> >
> > Nanley Chery (13):
> >   i965: Use the brw_context for the clear color and value setters
> >   i965/miptree: Move the clear color and value setter implementations
> >   i965: Make the miptree clear color setter take a gl_color_union
> >   i965/miptree: Add and use a getter for the clear color
> >   i965/miptree: Extend the sRGB-blending WA to future platforms
> >   i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL
> >   i965: Add and use a getter for depth miptree clear values
> >   i965: Allow failure when setting the depth clear value
> >   i965/brw_clear: Don't resolve to change the depth clear value
> >   i965/brw_clear: Delete redundant code
> >   i965/blorp: Also skip the fast clear if the clear color differs
> >   i965/miptree: Allow failure when setting the clear color
> >   i965/blorp: Delete redundant code
> >
> >  src/mesa/drivers/dri/i965/brw_blorp.c|  60 +++--
> >  src/mesa/drivers/dri/i965/brw_clear.c|  45 +--
> >  src/mesa/drivers/dri/i965/brw_meta_util.c|  11 --
> >  src/mesa/drivers/dri/i965/brw_misc_state.c   |  15 ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c |   4 +-
> >  src/mesa/drivers/dri/i965/gen6_depth_state.c |   4 +-
> >  src/mesa/drivers/dri/i965/gen7_misc_state.c  |   3 +-
> >  src/mesa/drivers/dri/i965/gen8_depth_state.c |   3 +-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 165
> > ++-
> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  53 
> >  src/util/format_srgb.h   |  14 ++
> >  11 files changed, 233 insertions(+), 144 deletions(-)
> >
> > --
> > 2.16.2
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #15 from Ben Clapp  ---
Created attachment 138586
  --> https://bugs.freedesktop.org/attachment.cgi?id=138586&action=edit
vulkaninfo output when using mesa 18.0.

I already had attached my vulkaninfo, but that was back when I was using
17.2.x, so here's an updated version.

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

[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #16 from Samuel Pitoiset  ---
Thanks, are you still using the same dolphin? If not, can you report the
version number, please?

-- 
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 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)

[bugzilla-daemon]

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

--- Comment #17 from Ben Clapp  ---
(In reply to Samuel Pitoiset from comment #16)
> Thanks, are you still using the same dolphin? If not, can you report the
> version number, please?

Currently using commit dea30e08b for dolphin (was latest commit in master
branch about two days ago).

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

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Emil Velikov]

On 22 March 2018 at 00:39, Ilia Mirkin  wrote:
> Just one bit of feedback, for the rest I either agree or have no opinion:
>
> On Wed, Mar 21, 2018 at 8:28 PM, Emil Velikov  
> wrote:
>>  * unfit and late nominations:
>> * any rejections that are unfit based on the existing criteria can
>>   be merged as long as:
>>* subsystem specific patches are approved by the team
>>  maintainer(s).
>>* patches that cover multiple subsystems are approved by 50%+1
>>  of the maintainers of the affected subsystems.
>
> I don't think 50% + 1 is workable. That would mean for a core mesa
> patch, one would have to get like 5+ people to ack it. Seems like a
> lot. (And I suspect will lead to debates about how to count "affected"
> subsystems.) IMHO 2 is enough, i.e. the maintainer that wants it, and
> another maintainer who thinks it's reasonable.
>
The presumption of 5+ people is based that we'll get at least 8
sub-system maintainers.

As of now, there has been only one person to clearly step forward - Mark.
Even if we get as many, the idea is to have broad consensus or at
least awareness.

An explicit NACK (as you mentioned later) is perfect, but it has
fairly big assumption.
Namely: other maintainers will review/test the patch, before actual
release (with it) is made.

Sure 50% might be too much and we can make it lower (say 30%), but
you'd want more representative size than 2.
Feature releases are a collective work of over 100 people, while
stable releases average of around 15.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Leo Liu  writes:

> On the CI family, firmware requires the destory command have to be the
> last command in the IB, moving feedback command after destroy is causing
> issues on CI cards, so we have to keep the previous logic that moves
> destroy back to the last command.
>
> But as the original issue fixed previously, with the newer family like Vega10,
> feedback command have to be included inside of the task info command along
> with destroy command.
>
> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>
> Signed-off-by: Leo Liu 
> Cc: mesa-sta...@lists.freedesktop.org

These tags seem ambiguous to me.  If this commit fixes a specific
commit, then the patch should be applied only to stable branches which
contain that commit.

However, the mesa-stable CC caused this patch to be applied to 17.3,
which does *not* contain the broken patch.

Leo: did you intend for the mesa-stable CC to cause this patch to be
applied to older stable branches?

Release managers: is there a protocol for how this specification should
be parsed, when considering a patch for stable?

> ---
>  src/gallium/drivers/radeon/radeon_vce.c|  1 -
>  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
>  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
>  3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
> b/src/gallium/drivers/radeon/radeon_vce.c
> index 427bf01ed8..c84103e0ac 100644
> --- a/src/gallium/drivers/radeon/radeon_vce.c
> +++ b/src/gallium/drivers/radeon/radeon_vce.c
> @@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
>   enc->fb = &fb;
>   enc->session(enc);
>   enc->destroy(enc);
> - enc->feedback(enc);
>   flush(enc);
>   si_vid_destroy_buffer(&fb);
>   }
> diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
> b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> index f1db47d4bd..04e9d7f5e1 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> @@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
>  {
>   enc->task_info(enc, 0x0001, 0, 0, 0);
>  
> + feedback(enc);
> +
>   RVCE_BEGIN(0x0201); // destroy
>   RVCE_END();
>  }
> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> b/src/gallium/drivers/radeon/radeon_vce_52.c
> index a941c476f6..421539c4bd 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> @@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
>   RVCE_END();
>  }
>  
> -static void destroy(struct rvce_encoder *enc)
> -{
> - enc->task_info(enc, 0x0001, 0, 0, 0);
> -
> - RVCE_BEGIN(0x0201); // destroy
> - RVCE_END();
> -}
> -
>  static void feedback(struct rvce_encoder *enc)
>  {
>   RVCE_BEGIN(0x0505); // feedback buffer
> @@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
>   RVCE_END();
>  }
>  
> +static void destroy(struct rvce_encoder *enc)
> +{
> + enc->task_info(enc, 0x0001, 0, 0, 0);
> +
> + feedback(enc);
> +
> + RVCE_BEGIN(0x0201); // destroy
> + RVCE_END();
> +}
> +
>  static void motion_estimation(struct rvce_encoder *enc)
>  {
>   RVCE_BEGIN(0x0407); // motion estimation
> -- 
> 2.14.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] mesa: add INTEL_blackhole_render

[Emil Velikov]

On 4 April 2018 at 15:48, Lionel Landwerlin
 wrote:
> On 15/03/18 16:03, Emil Velikov wrote:
>
>> Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
>> Wrt GLES side the spec does not mention anything - is that ES1, ES2,
>> which version etc.
>> Worth keeping it simple and update the spec to say ES2+?
>
>> The patch implements Enable/Disable, yet IsEnabled is missing.
>
> Actually the gl.xml was set to enable it for GL/GLES2, although written
> against the ES3 spec.
>
The "supported" section in the XML should reflect the supported API.
I don't think it supports gles3 or any other form of explicit version check.

The version checks are only on mesa's extensions_table.h. IIRC that
one is there because some apps assume that the extension is advertised
only if all the dependencies are met.
Layman example: I need GL3.0 and extension FOO. Since the FOO already
requires GL3.0, I can omit the GL3.0 check.

Since the spec says GL 3.0 and (any) GLES, I'd make the line "30, 30, ES1, ES2"

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

[Mesa-dev] [Bug 105847] Profile GL3bc is not available on X11GraphicsDevice

[bugzilla-daemon]

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

--- Comment #1 from Emil Velikov  ---
Some of the previous scilab reports indicate that the jogl has some funky
driver detection code - see bug 103078.

If the suggestion from there (reinstating the "Gallium 0.4") makes things work
again, then we can call this a duplicate.

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

Re: [Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Mark Janes]

Emil Velikov  writes:

> Hi all,
>
> Having gone through the thread a few times, I believe it can be
> summarised as follows:
>  * Greater transparency is needed.
>  * Subsystem/team maintainers.
>  * Unfit and late nominations.
>  * Developers/everyone should be more involved.
>  * Greater automation must be explored.
>
>
> NOTES:
>  * Some of the details are not listed in the thread, but have been
>raised in one form or another.
>  * The details focuses more on the goals, than the actual means.
>  * Above said, some details may have been missed - I'm mere human.
>
>
> In detail:
>  * make the patch queue, release date and blockers accessible at any
>point in time:
> * queued patches can be accessed, via a branch - say wip/17.3,
>   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
>   normally reverts are recommended.

I created a bot that applies commits from master to wip stable branches
and tests in CI.  It runs several times a day and identifies patches
that do not cherry-pick cleanly.  Branches are here:

 https://github.com/janesma/mesa/tree/wip/17.3
 https://github.com/janesma/mesa/tree/wip/18.0

I've sent a couple of mails to developers when their recent patches
don't apply.  So far it handles about 85% of the commits containing
stable tags without intervention.

> * rejected patches must be listed alongside the reason why and
>   author+reviewer must be informed (email & IRC?) ASAP.
>* we already document and track those in .cherry-ignore. can we
>  reuse that?
>
> * patches with trivial conflicts can be merged to the wip branch
>   after another release manager, or patch author/reviewer has
>   confirmed the changes.
>
> * patches that require backports will be rejected. usual rejection
>   procedure applies (described above).
>
> * if there is delay due to extra testing time or otherwise, the
>   release manager must list the blocking issues and ETA must be
>   provided. ETA must be updated before it's reached. it may be
>   worth having the ETA and rejections in a single place - inside
>   the wip/ branch, html page, elsewhere.
>
> * the current metabug with release blockers must be made more
>   obvious.
>
> * release manager can contact Phoronix and/or similar media to
>   publicise expected delays, blockers or seek request for testing.
>
>
>  * teams are encouraged to have one or multiple maintainers. some of
>the goals of having such people include:
> * individuals that have greater interaction with the team and
>   knowledge about the team plans. rough examples include:
>* backport/bug is needed, yet person is not available - on a
>  leave (sick, sabbatical, other) or busy with other things.
>* team has higher priority with details not publicly available.
>
> * can approve unfit or late nominations - see next section.
> * to ensure cover and minimise stress it's encouraged to have
>   multiple maintainers per team and they are rotated regularly.
> * list of maintainers must be documented
>
>
>  * unfit and late nominations:
> * any rejections that are unfit based on the existing criteria can
>   be merged as long as:
>* subsystem specific patches are approved by the team
>  maintainer(s).
>* patches that cover multiple subsystems are approved by 50%+1
>  of the maintainers of the affected subsystems.
>
> * late nominations can be made after the pre-release announcement.
>   they must be approved by the subsystem maintainers up-to X hours
>   before the actual release. approval specifics are identical to the
>   ones listed in 'unfit' section just above.
>
>
>  * developers/everyone should be more involved:
> * with the patch queue accessible at any point, everyone is
>   encouraged to keep an eye open and report issues.
>
> * developers should be more active in providing backports and
>   updating the status of release blocking bugs.
>
> * release managers and team maintainers must check with developer
>   (via email, IRC, other) if no action has been made for X days.
>
> * everyone is encouraged to provide a piglit/dEQP/etc testing
>   summary (via email, attachment, html page., etc). if they do,
>   please ensure that summary consistently available, regardless if
>   there's any regressions or not. if extra time is needed reply to
>   the list informing release managers
>
> * in case of regressions bisection must be provided.
>
>
>  * testing - pre and post merge, automation:
>
>NOTE: implementation specifics is up-to each team, with goals of:
>a) results must be accessible reasonably easy
>b) high level documentation of the setup and contact points are
>   documented
>
> * with over 120 developers contributing to mesa, ambiguous patch
>   nominations will always exist.
>
> * the obvious ones 

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #10 from Tasev  ---
Hi,
Same bug here after upgrading today to mesa 18.0 on both Broadwell and Skylake
mobile.

mesa 18.0.0 from padoka PPA stable
X.Org version: 1.19.5
KDE Neon
KDE Frameworks 5.44.0
Qt 5.10
KDE Plasma 5.12.4
kernel 4.13.0-38-generic (ubuntu) (tested also with 4.15 and 4.16)
intel driver 2.99.917 + git

For info, no problem on ivybridge and ironlake mobile with the same config.

-- 
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 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

Tasev  changed:

   What|Removed |Added

 CC||tasev.stefano...@skynet.be

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Dylan Baker  ---
I'm sorry I let this slip so long, someone had sent a patch to fix this and I'd
asked them to make some changes and that never happened. I'm sending a patch
for this.

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

Re: [Mesa-dev] [PATCH 02/17] ac/surface: don't set the display flag for obviously unsupported cases

[Marek Olšák]

On Wed, Apr 4, 2018 at 9:01 AM, Michel Dänzer  wrote:

> On 2018-04-04 02:57 PM, Marek Olšák wrote:
> > On Wed, Apr 4, 2018, 6:18 AM Michel Dänzer  > > wrote:
> >
> > On 2018-04-04 03:59 AM, Marek Olšák wrote:
> > > From: Marek Olšák mailto:marek.ol...@amd.com
> >>
> > >
> > > This enables the tile swizzle for some cases of the displayable
> > micro mode,
> > > and it also fixes an addrlib assertion failure on Vega.
> > > ---
> > >  src/amd/common/ac_surface.c | 18 ++
> > >  1 file changed, 14 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/src/amd/common/ac_surface.c
> b/src/amd/common/ac_surface.c
> > > index b294cd85259..2b20a553d51 100644
> > > --- a/src/amd/common/ac_surface.c
> > > +++ b/src/amd/common/ac_surface.c
> > > @@ -408,20 +408,29 @@ static unsigned
> > cik_get_macro_tile_index(struct radeon_surf *surf)
> > >   tileb = 8 * 8 * surf->bpe;
> > >   tileb = MIN2(surf->u.legacy.tile_split, tileb);
> > >
> > >   for (index = 0; tileb > 64; index++)
> > >   tileb >>= 1;
> > >
> > >   assert(index < 16);
> > >   return index;
> > >  }
> > >
> > > +static bool get_display_flag(const struct ac_surf_config *config,
> > > +  const struct radeon_surf *surf)
> > > +{
> > > + return surf->flags & RADEON_SURF_SCANOUT &&
> > > +!(surf->flags & RADEON_SURF_FMASK) &&
> > > +config->info.samples <= 1 &&
> > > +surf->bpe >= 4 && surf->bpe <= 8;
> >
> > surf->bpe is the number of bytes used to store each pixel, right? If
> so,
> > this cannot exclude surf->bpe < 4, since 16 bpp and 8 bpp formats
> can be
> > displayed.
> >
> >
> > Sure, but what are the chances they will be displayed with the current
> > stack? GLX doesn't have 16bpp visuals for on-screen rendering.
>
> Maybe not when the X server runs at depth 24, but it can also run at
> depths 8, 15 & 16, in which case displayable surfaces with bpe == 1 or 2
> are needed even before GLX even comes into the picture.
>

OK. Let me ask differently. Do we wanna support displayable 8, 15, and 16
bpp? Can we just say that we don't support those?

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

--- Comment #4 from Jan Alexander Steffens (heftig)  ---
Arch Linux currently carries two patches (fix-install.diff and
fix-versions.diff) to reduce to differences between the Meson product and the
Autotools one; it also adds the project version script that was missing from
the 18.0.0 tarball.

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

[Mesa-dev] [PATCH] meson: fix megadriver symlinking

[Dylan Baker]

Which should be relative instead of absolute.

Fixes: f7f1b30f81e842db6057591470ce3cb6d4fb2795
   ("meson: extend install_megadrivers script to handle symmlinking")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105567
Signed-off-by: Dylan Baker 
---
 bin/install_megadrivers.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
index 86bfa359188..7931a544bd2 100755
--- a/bin/install_megadrivers.py
+++ b/bin/install_megadrivers.py
@@ -58,7 +58,7 @@ def main():
 while ext != '.so':
 if os.path.exists(name):
 os.unlink(name)
-os.symlink(driver, name)
+os.symlink(each, name)
 name, ext = os.path.splitext(name)
 finally:
 os.chdir(ret)
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH 1/4] mesa: add INTEL_blackhole_render

[Lionel Landwerlin]

On 04/04/18 17:51, Emil Velikov wrote:

On 4 April 2018 at 15:48, Lionel Landwerlin
 wrote:

On 15/03/18 16:03, Emil Velikov wrote:


Spec says "OpenGL 3.0 is required" so GLL + GLC should become 30
Wrt GLES side the spec does not mention anything - is that ES1, ES2,
which version etc.
Worth keeping it simple and update the spec to say ES2+?
The patch implements Enable/Disable, yet IsEnabled is missing.

Actually the gl.xml was set to enable it for GL/GLES2, although written
against the ES3 spec.


The "supported" section in the XML should reflect the supported API.
I don't think it supports gles3 or any other form of explicit version check.

The version checks are only on mesa's extensions_table.h. IIRC that
one is there because some apps assume that the extension is advertised
only if all the dependencies are met.
Layman example: I need GL3.0 and extension FOO. Since the FOO already
requires GL3.0, I can omit the GL3.0 check.

Since the spec says GL 3.0 and (any) GLES, I'd make the line "30, 30, ES1, ES2"


Thanks a lot. I just figured what GLL/GLC means ;)



HTH
Emil
___
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] [RFC] Mesa 17.3.x release problems and process improvements

[Juan A. Suarez Romero]

On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote:
> Emil Velikov  writes:
> 
> > Hi all,
> > 
> > Having gone through the thread a few times, I believe it can be
> > summarised as follows:
> >  * Greater transparency is needed.
> >  * Subsystem/team maintainers.
> >  * Unfit and late nominations.
> >  * Developers/everyone should be more involved.
> >  * Greater automation must be explored.
> > 
> > 
> > NOTES:
> >  * Some of the details are not listed in the thread, but have been
> >raised in one form or another.
> >  * The details focuses more on the goals, than the actual means.
> >  * Above said, some details may have been missed - I'm mere human.
> > 
> > 
> > In detail:
> >  * make the patch queue, release date and blockers accessible at any
> >point in time:
> > * queued patches can be accessed, via a branch - say wip/17.3,
> >   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
> >   normally reverts are recommended.
> 
> I created a bot that applies commits from master to wip stable branches
> and tests in CI.  It runs several times a day and identifies patches
> that do not cherry-pick cleanly.  Branches are here:
> 
>  https://github.com/janesma/mesa/tree/wip/17.3
>  https://github.com/janesma/mesa/tree/wip/18.0
> 
> I've sent a couple of mails to developers when their recent patches
> don't apply.  So far it handles about 85% of the commits containing
> stable tags without intervention.
> 

Cool! I was thinking on a similar approach here:

* Everytime a push happens, a job/bot scans the pushed patches, and creates a
pull request with the stable patches. If some of the patches that does not
apply, then it sends an email to the authors informing. I group all the stable
patches in one PR because when a push is done, I assume that all the patches
belong to the same feature/bugfix, and thus it makes sense to deal with them as
in one PR.

* There's a bot that is listening for the PR. Everytime a new PR arrives, it
starts the proper testing. If test is successful, it automatically merges the
PR; otherwise it just sends an email informing the failure. An important point
here is that if a PR is under testing, then the bot waits until the test
finishes and the PR under testing is either merged or rejected. If it is merged,
the bot rebases the new PR and starts the test. This way, we guarantee the test
is done with a version that won't change after while the test is happening. If
you are more interested, I was thinking on using Marge bot for this.


J.A.



> > * rejected patches must be listed alongside the reason why and
> >   author+reviewer must be informed (email & IRC?) ASAP.
> >* we already document and track those in .cherry-ignore. can we
> >  reuse that?
> > 
> > * patches with trivial conflicts can be merged to the wip branch
> >   after another release manager, or patch author/reviewer has
> >   confirmed the changes.
> > 
> > * patches that require backports will be rejected. usual rejection
> >   procedure applies (described above).
> > 
> > * if there is delay due to extra testing time or otherwise, the
> >   release manager must list the blocking issues and ETA must be
> >   provided. ETA must be updated before it's reached. it may be
> >   worth having the ETA and rejections in a single place - inside
> >   the wip/ branch, html page, elsewhere.
> > 
> > * the current metabug with release blockers must be made more
> >   obvious.
> > 
> > * release manager can contact Phoronix and/or similar media to
> >   publicise expected delays, blockers or seek request for testing.
> > 
> > 
> >  * teams are encouraged to have one or multiple maintainers. some of
> >the goals of having such people include:
> > * individuals that have greater interaction with the team and
> >   knowledge about the team plans. rough examples include:
> >* backport/bug is needed, yet person is not available - on a
> >  leave (sick, sabbatical, other) or busy with other things.
> >* team has higher priority with details not publicly available.
> > 
> > * can approve unfit or late nominations - see next section.
> > * to ensure cover and minimise stress it's encouraged to have
> >   multiple maintainers per team and they are rotated regularly.
> > * list of maintainers must be documented
> > 
> > 
> >  * unfit and late nominations:
> > * any rejections that are unfit based on the existing criteria can
> >   be merged as long as:
> >* subsystem specific patches are approved by the team
> >  maintainer(s).
> >* patches that cover multiple subsystems are approved by 50%+1
> >  of the maintainers of the affected subsystems.
> > 
> > * late nominations can be made after the pre-release announcement.
> >   they must be approved by the subsystem maintainers up-to X hours
> >   before the actual release. 

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Juan A. Suarez Romero]

On Wed, 2018-04-04 at 09:40 -0700, Mark Janes wrote:
> Leo Liu  writes:
> 
> > On the CI family, firmware requires the destory command have to be the
> > last command in the IB, moving feedback command after destroy is causing
> > issues on CI cards, so we have to keep the previous logic that moves
> > destroy back to the last command.
> > 
> > But as the original issue fixed previously, with the newer family like 
> > Vega10,
> > feedback command have to be included inside of the task info command along
> > with destroy command.
> > 
> > Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
> > 
> > Signed-off-by: Leo Liu 
> > Cc: mesa-sta...@lists.freedesktop.org
> 
> These tags seem ambiguous to me.  If this commit fixes a specific
> commit, then the patch should be applied only to stable branches which
> contain that commit.
> 
> However, the mesa-stable CC caused this patch to be applied to 17.3,
> which does *not* contain the broken patch.
> 
> Leo: did you intend for the mesa-stable CC to cause this patch to be
> applied to older stable branches?
> 
> Release managers: is there a protocol for how this specification should
> be parsed, when considering a patch for stable?
> 

In my case, if a patch is nominated, then it is applied to the proper stable
branch. I understand that while the patch probably fixes a commit, it makes
sense per se as a valid independent patch.

But I think we should modify our script to warn us in this situation and just
clarify with the author about the intention.


J.A.


> > ---
> >  src/gallium/drivers/radeon/radeon_vce.c|  1 -
> >  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
> >  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
> >  3 files changed, 12 insertions(+), 9 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
> > b/src/gallium/drivers/radeon/radeon_vce.c
> > index 427bf01ed8..c84103e0ac 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce.c
> > @@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec 
> > *encoder)
> > enc->fb = &fb;
> > enc->session(enc);
> > enc->destroy(enc);
> > -   enc->feedback(enc);
> > flush(enc);
> > si_vid_destroy_buffer(&fb);
> > }
> > diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
> > b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > index f1db47d4bd..04e9d7f5e1 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
> > @@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
> >  {
> > enc->task_info(enc, 0x0001, 0, 0, 0);
> >  
> > +   feedback(enc);
> > +
> > RVCE_BEGIN(0x0201); // destroy
> > RVCE_END();
> >  }
> > diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> > b/src/gallium/drivers/radeon/radeon_vce_52.c
> > index a941c476f6..421539c4bd 100644
> > --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> > +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> > @@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
> > RVCE_END();
> >  }
> >  
> > -static void destroy(struct rvce_encoder *enc)
> > -{
> > -   enc->task_info(enc, 0x0001, 0, 0, 0);
> > -
> > -   RVCE_BEGIN(0x0201); // destroy
> > -   RVCE_END();
> > -}
> > -
> >  static void feedback(struct rvce_encoder *enc)
> >  {
> > RVCE_BEGIN(0x0505); // feedback buffer
> > @@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
> > RVCE_END();
> >  }
> >  
> > +static void destroy(struct rvce_encoder *enc)
> > +{
> > +   enc->task_info(enc, 0x0001, 0, 0, 0);
> > +
> > +   feedback(enc);
> > +
> > +   RVCE_BEGIN(0x0201); // destroy
> > +   RVCE_END();
> > +}
> > +
> >  static void motion_estimation(struct rvce_encoder *enc)
> >  {
> > RVCE_BEGIN(0x0407); // motion estimation
> > -- 
> > 2.14.1
> > 
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: Set .so version for xa like autotools does

[Dylan Baker]

Fixes: 0ba909f0f111824223bc38563d1a6bc73e69c2cc
   ("meson: build gallium xa state tracker")
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/xa/meson.build | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/targets/xa/meson.build 
b/src/gallium/targets/xa/meson.build
index ea6e1296dae..733ef54ff85 100644
--- a/src/gallium/targets/xa/meson.build
+++ b/src/gallium/targets/xa/meson.build
@@ -30,6 +30,7 @@ if with_ld_version_script
   xa_link_depends += files('xa.sym')
 endif
 
+_xa_version = '.'.join(xa_version)
 
 libxatracker = shared_library(
   'xatracker',
@@ -49,12 +50,13 @@ libxatracker = shared_library(
   dependencies : [
 dep_thread, driver_nouveau, driver_i915, driver_svga, driver_freedreno,
   ],
+  version : _xa_version,
   install : true,
 )
 
 pkg.generate(
   name : 'xatracker',
   description : 'Xorg gallium3D acceleration library',
-  version : '.'.join(xa_version),
+  version : _xa_version,
   libraries : libxatracker,
 )
-- 
2.16.3

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

--- Comment #5 from Dylan Baker  ---
patch here:
https://patchwork.freedesktop.org/patch/214930/

As a side note, feel free to CC me on any meson related things.

The missing version script should be fixed for 18.0.1, the change is in master
as bc2fdb9759dc702ec351a044b3fd408c0701fedb.

I've also sent a patch to fix the xa version which is missing:
https://patchwork.freedesktop.org/series/41150/

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Emil Velikov]

On 4 April 2018 at 17:40, Mark Janes  wrote:
> Leo Liu  writes:
>
>> On the CI family, firmware requires the destory command have to be the
>> last command in the IB, moving feedback command after destroy is causing
>> issues on CI cards, so we have to keep the previous logic that moves
>> destroy back to the last command.
>>
>> But as the original issue fixed previously, with the newer family like 
>> Vega10,
>> feedback command have to be included inside of the task info command along
>> with destroy command.
>>
>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>
>> Signed-off-by: Leo Liu 
>> Cc: mesa-sta...@lists.freedesktop.org
>
> These tags seem ambiguous to me.  If this commit fixes a specific
> commit, then the patch should be applied only to stable branches which
> contain that commit.
>
> However, the mesa-stable CC caused this patch to be applied to 17.3,
> which does *not* contain the broken patch.
>
> Leo: did you intend for the mesa-stable CC to cause this patch to be
> applied to older stable branches?
>
> Release managers: is there a protocol for how this specification should
> be parsed, when considering a patch for stable?
>
If the Fixes tag, reference a commit that is missing in specific
stable branch then obviously the fix is not suitable.
Hence the stable piece than be ignored + alongside a reply to the
patch that it will not be in $stable_branch because $reason.

Even if offending commit is not part of $stable_branch, getting into
the habit and cross-referencing is very beneficial.
Some customers may use non-stable branch, hence having track of which
fixes they need is a smart move.

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

[Mesa-dev] [Bug 105871] Discolored KDE panels after updating to Mesa 18.0 on Intel broadwell

[bugzilla-daemon]

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

--- Comment #11 from Tapani Pälli  ---
(In reply to sergio.callegari from comment #9)
> A quick question... the patch being mentioned is related to the part of xorg
> that usually gets packaged as xserver-xorg-core, right? Not to the
> individual video drivers such as those packaged in xserver-xorg-video-intel,
> correct?
> 
> I am asking because ubuntu has various PPAs providing updated graphic
> stacks, but all of them appear to be currently shipping the updated
> video-xxx packages but no updated core package for xorg.

Yes, it would be the xore package. The change is not in individual driver but
the server glx code.

-- 
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] [RFC] Mesa 17.3.x release problems and process improvements

[Mark Janes]

"Juan A. Suarez Romero"  writes:

> On Wed, 2018-04-04 at 10:07 -0700, Mark Janes wrote:
>> Emil Velikov  writes:
>> > In detail:
>> >  * make the patch queue, release date and blockers accessible at any
>> >point in time:
>> > * queued patches can be accessed, via a branch - say wip/17.3,
>> >   wip/18.0, wip/18.1, etc. The branch _will be_ rebased, although
>> >   normally reverts are recommended.
>> 
>> I created a bot that applies commits from master to wip stable branches
>> and tests in CI.  It runs several times a day and identifies patches
>> that do not cherry-pick cleanly.  Branches are here:
>> 
>>  https://github.com/janesma/mesa/tree/wip/17.3
>>  https://github.com/janesma/mesa/tree/wip/18.0
>> 
>> I've sent a couple of mails to developers when their recent patches
>> don't apply.  So far it handles about 85% of the commits containing
>> stable tags without intervention.
>> 
>
> Cool! I was thinking on a similar approach here:
>
> * Everytime a push happens, a job/bot scans the pushed patches, and creates a
> pull request with the stable patches. If some of the patches that does not
> apply, then it sends an email to the authors informing.

IMO, automating messages to developers will generate undesired noise on
mailing lists.  We should have a real person moderate the notifications,
until they prove to be consistently actionable.

> I group all the stable patches in one PR because when a push is done,
> I assume that all the patches belong to the same feature/bugfix, and
> thus it makes sense to deal with them as in one PR.

PRs seem like an unnecessary complication.  My proof-of-concept script
simply applies all commits with stable tags to an arbitrary wip branch,
based on the stable branch policies.

CI triggers from the wip branch as with any developer CI branch.

> * There's a bot that is listening for the PR. Everytime a new PR
> arrives, it starts the proper testing. If test is successful, it
> automatically merges the PR; otherwise it just sends an email
> informing the failure. An important point here is that if a PR is
> under testing, then the bot waits until the test finishes and the PR
> under testing is either merged or rejected. If it is merged, the bot
> rebases the new PR and starts the test. This way, we guarantee the
> test is done with a version that won't change after while the test is
> happening. If you are more interested, I was thinking on using Marge
> bot for this.

Fewer/smaller dependencies is better.  What does gitlab + marge buy us
over a single script?

To be clear, my script is gross at the moment.  I just hacked to get
something that would match the stable policy, and provide immediate
feedback when commits are pushed.  It could be cleaned up and shared if
anyone wants it.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Mark Janes]

Emil Velikov  writes:

> On 4 April 2018 at 17:40, Mark Janes  wrote:
>> Leo Liu  writes:
>>
>>> On the CI family, firmware requires the destory command have to be the
>>> last command in the IB, moving feedback command after destroy is causing
>>> issues on CI cards, so we have to keep the previous logic that moves
>>> destroy back to the last command.
>>>
>>> But as the original issue fixed previously, with the newer family like 
>>> Vega10,
>>> feedback command have to be included inside of the task info command along
>>> with destroy command.
>>>
>>> Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")
>>>
>>> Signed-off-by: Leo Liu 
>>> Cc: mesa-sta...@lists.freedesktop.org
>>
>> These tags seem ambiguous to me.  If this commit fixes a specific
>> commit, then the patch should be applied only to stable branches which
>> contain that commit.
>>
>> However, the mesa-stable CC caused this patch to be applied to 17.3,
>> which does *not* contain the broken patch.
>>
>> Leo: did you intend for the mesa-stable CC to cause this patch to be
>> applied to older stable branches?
>>
>> Release managers: is there a protocol for how this specification should
>> be parsed, when considering a patch for stable?
>>
> If the Fixes tag, reference a commit that is missing in specific
> stable branch then obviously the fix is not suitable.
> Hence the stable piece than be ignored + alongside a reply to the
> patch that it will not be in $stable_branch because $reason.

OK, we have violated this policy at least a couple times in the previous
release, based on my audits:

  2f67c9b17518cf0d2fe946e39e5b8ff5ec2797c5
  i965/vec4: Fix null destination register in 3-source instructions

  6f69b63896ce2352aaa25f89287133f7f2ba1fab
  radeon/vce: move feedback command inside of destroy function

> Even if offending commit is not part of $stable_branch, getting into
> the habit and cross-referencing is very beneficial.
> Some customers may use non-stable branch, hence having track of which
> fixes they need is a smart move.
>
> HTH
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH, v2] CHROMIUM: configure.ac/meson.build: Fix -latomic test

[Matt Turner]

On Thu, Mar 29, 2018 at 4:10 PM, Nicolas Boichat  wrote:
> On Fri, Mar 30, 2018 at 2:26 AM, Matt Turner  wrote:
>> On Thu, Mar 29, 2018 at 1:31 AM, Nicolas Boichat  
>> wrote:
>>> From: Nicolas Boichat 
>>>
>>> When compiling with LLVM 6.0, the test fails to detect that
>>> -latomic is actually required, as the atomic call is inlined.
>>>
>>> In the code itself (src/util/disk_cache.c), we see this pattern:
>>> p_atomic_add(cache->size, - (uint64_t)size);
>>> where cache->size is an uint64_t *, and results in the following
>>> link time error without -latomic:
>>> src/util/disk_cache.c:628: error: undefined reference to 
>>> '__atomic_fetch_add_8'
>>>
>>> Fix the configure/meson test to replicate this pattern, which then
>>> correctly realizes the need for -latomic.
>>>
>>> Signed-off-by: Nicolas Boichat 
>>> ---
>>>
>>> Changes since v1:
>>>  - Updated meson.build as well (untested)
>>>
>>>  configure.ac | 6 --
>>>  meson.build  | 6 --
>>>  2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index e874f8ebfb2..eff9a0ef88f 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -445,9 +445,11 @@ if test "x$GCC_ATOMIC_BUILTINS_SUPPORTED" = x1; then
>>>  AC_MSG_CHECKING(whether -latomic is needed)
>>>  AC_LINK_IFELSE([AC_LANG_SOURCE([[
>>>  #include 
>>> -uint64_t v;
>>> +struct {
>>> +uint64_t* v;
>>
>> I wouldn't care expect that you put the * with the v in the Meson case. :)
>
> Argh ,-( I'll send a v3, let's see if anyone has further comments, first.
>
>> Also, on what platform does this occur?
>
> This is ARC++ (Android 32-bit x86) with clang version:
> Android (4639204 based on r316199) clang version 6.0.1
> (https://android.googlesource.com/toolchain/clang
> 279c0d3a962121a6d1d535e7b0b5d9d36d3c829d)
> (https://android.googlesource.com/toolchain/llvm
> aadd87ffb6a2eafcb577913073d46b20195a9cdc) (based on LLVM 6.0.1svn)
>
>> Looking at this code, I would expect it to behave the same as before.
>> Do you have an idea why this fixes it, or why the original code didn't
>> work? I'm guess it's about the compiler's ability to recognize that it
>> knows the location of the variable.
>
> With the original code, objdump looks like this:
>
> 08048400 :
>  8048400:   53  push   %ebx
>  8048401:   56  push   %esi
>  8048402:   e8 00 00 00 00  call   8048407 
>  8048407:   5e  pop%esi
>  8048408:   81 c6 ed 1b 00 00   add$0x1bed,%esi
>  804840e:   31 c0   xor%eax,%eax
>  8048410:   31 d2   xor%edx,%edx
>  8048412:   31 c9   xor%ecx,%ecx
>  8048414:   31 db   xor%ebx,%ebx
>  8048416:   f0 0f c7 8e 24 00 00lock cmpxchg8b 0x24(%esi)
>  804841d:   00
>  804841e:   5e  pop%esi
>  804841f:   5b  pop%ebx
>  8048420:   c3  ret
>
> Looks like LLVM figures out that &v is constant, and uses some 64-bit
> atomic swap operations on it directly.
>
> With the updated code (building with -latomic, it fails otherwise)
> 08048480 :
>  8048480:   53  push   %ebx
>  8048481:   83 ec 08sub$0x8,%esp
>  8048484:   e8 00 00 00 00  call   8048489 
>  8048489:   5b  pop%ebx
>  804848a:   81 c3 6b 1b 00 00   add$0x1b6b,%ebx
>  8048490:   83 ec 08sub$0x8,%esp
>  8048493:   6a 02   push   $0x2
>  8048495:   ff b3 8c 10 00 00   pushl  0x108c(%ebx)
>  804849b:   e8 05 00 00 00  call   80484a5 <__atomic_load_8>
>  80484a0:   83 c4 18add$0x18,%esp
>  80484a3:   5b  pop%ebx
>  80484a4:   c3  ret
>
> I think the the code is trying to protect both x.v (address) _and_ its
> value *x.v? Or maybe LLVM does not see the pattern... (I don't see why
> cmpxchg8b wouldn't work here too, otherwise...)
>
> Actually, the test can be made simpler, by just using:
> uint64_t *v;
> ...
> __atomic_load_n(v, ...
>
> But then it does not match the usage pattern in the code, so I feel a
> little bit more confident that the current test will actually capture
> when -latomic is needed.

Yeah. That makes sense, and seems like a good idea to me.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] radeon/vce: move feedback command inside of destroy function

[Leo Liu]

On 04/04/2018 12:40 PM, Mark Janes wrote:

Leo Liu  writes:


On the CI family, firmware requires the destory command have to be the
last command in the IB, moving feedback command after destroy is causing
issues on CI cards, so we have to keep the previous logic that moves
destroy back to the last command.

But as the original issue fixed previously, with the newer family like Vega10,
feedback command have to be included inside of the task info command along
with destroy command.

Fixes: 6d74cb25("radeon/vce: move destroy command before feedback command")

Signed-off-by: Leo Liu 
Cc: mesa-sta...@lists.freedesktop.org

These tags seem ambiguous to me.  If this commit fixes a specific
commit, then the patch should be applied only to stable branches which
contain that commit.

However, the mesa-stable CC caused this patch to be applied to 17.3,
which does *not* contain the broken patch.

Leo: did you intend for the mesa-stable CC to cause this patch to be
applied to older stable branches?
I would like to have this patch apply to branches "17.2", "17.3", 
"18.0", which got patch titled "radeon/vce: move destroy command before 
feedback command"


And this Cc-ed patch is to fix "radeon/vce: move destroy command before 
feedback command"


Thanks,
Leo




Release managers: is there a protocol for how this specification should
be parsed, when considering a patch for stable?


---
  src/gallium/drivers/radeon/radeon_vce.c|  1 -
  src/gallium/drivers/radeon/radeon_vce_40_2_2.c |  2 ++
  src/gallium/drivers/radeon/radeon_vce_52.c | 18 ++
  3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/radeon/radeon_vce.c 
b/src/gallium/drivers/radeon/radeon_vce.c
index 427bf01ed8..c84103e0ac 100644
--- a/src/gallium/drivers/radeon/radeon_vce.c
+++ b/src/gallium/drivers/radeon/radeon_vce.c
@@ -247,7 +247,6 @@ static void rvce_destroy(struct pipe_video_codec *encoder)
enc->fb = &fb;
enc->session(enc);
enc->destroy(enc);
-   enc->feedback(enc);
flush(enc);
si_vid_destroy_buffer(&fb);
}
diff --git a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c 
b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
index f1db47d4bd..04e9d7f5e1 100644
--- a/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
+++ b/src/gallium/drivers/radeon/radeon_vce_40_2_2.c
@@ -421,6 +421,8 @@ static void destroy(struct rvce_encoder *enc)
  {
enc->task_info(enc, 0x0001, 0, 0, 0);
  
+	feedback(enc);

+
RVCE_BEGIN(0x0201); // destroy
RVCE_END();
  }
diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
b/src/gallium/drivers/radeon/radeon_vce_52.c
index a941c476f6..421539c4bd 100644
--- a/src/gallium/drivers/radeon/radeon_vce_52.c
+++ b/src/gallium/drivers/radeon/radeon_vce_52.c
@@ -458,14 +458,6 @@ static void config_extension(struct rvce_encoder *enc)
RVCE_END();
  }
  
-static void destroy(struct rvce_encoder *enc)

-{
-   enc->task_info(enc, 0x0001, 0, 0, 0);
-
-   RVCE_BEGIN(0x0201); // destroy
-   RVCE_END();
-}
-
  static void feedback(struct rvce_encoder *enc)
  {
RVCE_BEGIN(0x0505); // feedback buffer
@@ -474,6 +466,16 @@ static void feedback(struct rvce_encoder *enc)
RVCE_END();
  }
  
+static void destroy(struct rvce_encoder *enc)

+{
+   enc->task_info(enc, 0x0001, 0, 0, 0);
+
+   feedback(enc);
+
+   RVCE_BEGIN(0x0201); // destroy
+   RVCE_END();
+}
+
  static void motion_estimation(struct rvce_encoder *enc)
  {
RVCE_BEGIN(0x0407); // motion estimation
--
2.14.1

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


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

[Mesa-dev] [Bug 105832] radeonsi NIR missing bindless textures support

[bugzilla-daemon]

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

--- Comment #18 from b...@besd.de  ---
I've also changed shader capture to name shaders after the sha1 of their source
+ program number and noticed that shader-db compiles some of them twice with
different results (happens for TGSI as well but makes comparisons difficult):
R600_DEBUG=nir ./run shaders/metro2033redux/ | sort

shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- LLVM diagnostic (remark): :0:0: 215 instructions in function
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- LLVM diagnostic (remark): :0:0: 324 instructions in function
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- Shader Stats: SGPRS: 56 VGPRS: 36 Code Size: 1060 LDS: 0 Scratch: 0 Max
Waves: 7 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa37761e70a58456b26005791e1ae0ea1f8398b03876.shader_test
- Shader Stats: SGPRS: 64 VGPRS: 32 Code Size: 1720 LDS: 0 Scratch: 0 Max
Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- LLVM diagnostic (remark): :0:0: 250 instructions in function
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- LLVM diagnostic (remark): :0:0: 87 instructions in function
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- Shader Stats: SGPRS: 40 VGPRS: 28 Code Size: 484 LDS: 0 Scratch: 0 Max Waves:
8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0
shaders/metro2033redux/fa70500e637e4e51c3c907df268522ec48430dc82798.shader_test
- Shader Stats: SGPRS: 48 VGPRS: 32 Code Size: 1300 LDS: 0 Scratch: 0 Max
Waves: 8 Spilled SGPRs: 0 Spilled VGPRs: 0 PrivMem VGPRs: 0

-- 
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 2/2] gallium/pp: fix MLAA shaders

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/auxiliary/postprocess/pp_mlaa.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.h 
b/src/gallium/auxiliary/postprocess/pp_mlaa.h
index 85c14a786a3..3507f813781 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.h
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.h
@@ -56,21 +56,21 @@ static const char depth1fs[] = "FRAG\n"
"  0: TEX TEMP[0].x, IN[1].xyyy, SAMP[0], 2D\n"
"  1: MOV TEMP[1].x, TEMP[0].\n"
"  2: TEX TEMP[0].x, IN[1].zwww, SAMP[0], 2D\n"
"  3: MOV TEMP[1].y, TEMP[0].\n"
"  4: TEX TEMP[0].x, IN[2].xyyy, SAMP[0], 2D\n"
"  5: MOV TEMP[1].z, TEMP[0].\n"
"  6: TEX TEMP[0].x, IN[2].zwww, SAMP[0], 2D\n"
"  7: MOV TEMP[1].w, TEMP[0].\n"
"  8: TEX TEMP[0].x, IN[0].xyyy, SAMP[0], 2D\n"
"  9: ADD TEMP[2], TEMP[0]., -TEMP[1]\n"
-   " 10: ABS TEMP[0], TEMP[2]\n"
+   " 10: MOV TEMP[0], |TEMP[2]|\n"
" 11: SGE TEMP[2], TEMP[0], IMM[0].\n"
" 12: DP4 TEMP[0].x, TEMP[2], IMM[0].\n"
" 13: SEQ TEMP[1].x, TEMP[0]., IMM[0].\n"
" 14: IF TEMP[1]. :16\n"
" 15:   KILL\n"
" 16: ENDIF\n"
" 17: MOV OUT[0], TEMP[2]\n"
" 18: END\n";
 
 
@@ -89,21 +89,21 @@ static const char color1fs[] = "FRAG\n"
"  1: DP3 TEMP[0].x, TEMP[1].xyzz, IMM[0]\n"
"  2: TEX TEMP[1].xyz, IN[1].zwww, SAMP[0], 2D\n"
"  3: DP3 TEMP[0].y, TEMP[1].xyzz, IMM[0].xyzz\n"
"  4: TEX TEMP[1].xyz, IN[2].xyyy, SAMP[0], 2D\n"
"  5: DP3 TEMP[0].z, TEMP[1].xyzz, IMM[0].xyzz\n"
"  6: TEX TEMP[1].xyz, IN[2].zwww, SAMP[0], 2D\n"
"  7: DP3 TEMP[0].w, TEMP[1].xyzz, IMM[0].xyzz\n"
"  8: TEX TEMP[1].xyz, IN[0].xyyy, SAMP[0], 2D\n"
"  9: DP3 TEMP[2].x, TEMP[1].xyzz, IMM[0].xyzz\n"
" 10: ADD TEMP[1], TEMP[2]., -TEMP[0]\n"
-   " 11: ABS TEMP[0], TEMP[1]\n"
+   " 11: MOV TEMP[0], |TEMP[1]|\n"
" 12: SGE TEMP[2], TEMP[0], IMM[0].\n"
" 13: DP4 TEMP[0].x, TEMP[2], IMM[1].\n"
" 14: SEQ TEMP[1].x, TEMP[0]., IMM[1].\n"
" 15: IF TEMP[1]. :17\n"
" 16:   KILL\n"
" 17: ENDIF\n"
" 18: MOV OUT[0], TEMP[2]\n"
" 19: END\n";
 
 
@@ -254,21 +254,21 @@ static const char blend2fs_2[] =
" 61:   MOV TEMP[4], TEMP[1].xyyy\n"
" 62:   MOV TEMP[4].w, IMM[0].\n"
" 63:   TXL TEMP[5].x, TEMP[4], SAMP[2], 2D\n"
" 64:   MOV TEMP[4].x, TEMP[5].\n"
" 65:   MOV TEMP[5], TEMP[1].zwww\n"
" 66:   MOV TEMP[5].w, IMM[0].\n"
" 67:   TXL TEMP[1].x, TEMP[5], SAMP[2], 2D\n"
" 68:   MOV TEMP[4].y, TEMP[1].\n"
" 69:   MUL TEMP[5].xy, IMM[2]., TEMP[4].xyyy\n"
" 70:   ROUND TEMP[1].xy, TEMP[5].xyyy\n"
-   " 71:   ABS TEMP[4].xy, TEMP[3].xyyy\n"
+   " 71:   MOV TEMP[4].xy, |TEMP[3].xyyy|\n"
" 72:   MAD TEMP[3].xy, IMM[2]., TEMP[1].xyyy, TEMP[4].xyyy\n"
" 73:   MUL TEMP[5].xyz, TEMP[3].xyyy, IMM[0].\n"
" 74:   MOV TEMP[5].w, IMM[0].\n"
" 75:   TXL TEMP[0].xy, TEMP[5], SAMP[0], 2D\n"
" 76: ENDIF\n"
" 77: SNE TEMP[1].x, TEMP[2]., IMM[0].\n"
" 78: IF TEMP[1]. :151\n"
" 79:   MOV TEMP[1].xy, IN[0].xyxx\n"
" 80:   MOV TEMP[3].x, IMM[1].\n"
" 81:   BGNLOOP :98\n"
@@ -328,21 +328,21 @@ static const char blend2fs_2[] =
"135:   MOV TEMP[3], TEMP[1].xyyy\n"
"136:   MOV TEMP[3].w, IMM[0].\n"
"137:   TXL TEMP[4].y, TEMP[3], SAMP[2], 2D\n"
"138:   MOV TEMP[3].x, TEMP[4].\n"
"139:   MOV TEMP[4], TEMP[1].zwww\n"
"140:   MOV TEMP[4].w, IMM[0].\n"
"141:   TXL TEMP[1].y, TEMP[4], SAMP[2], 2D\n"
"142:   MOV TEMP[3].y, TEMP[1].\n"
"143:   MUL TEMP[4].xy, IMM[2]., TEMP[3].xyyy\n"
"144:   ROUND TEMP[1].xy, TEMP[4].xyyy\n"
-   "145:   ABS TEMP[3].xy, TEMP[2].xyyy\n"
+   "145:   MOV TEMP[3].xy, |TEMP[2].xyyy|\n"
"146:   MAD TEMP[2].xy, IMM[2]., TEMP[1].xyyy, TEMP[3].xyyy\n"
"147:   MUL TEMP[3].xyz, TEMP[2].xyyy, IMM[0].\n"
"148:   MOV TEMP[3].w, IMM[0].\n"
"149:   TXL TEMP[1].xy, TEMP[3], SAMP[0], 2D\n"
"150:   MOV TEMP[0].zw, TEMP[1].yyxy\n"
"151: ENDIF\n"
"152: MOV OUT[0], TEMP[0]\n"
"153: END\n";
 
 #endif
-- 
2.15.1

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

[Mesa-dev] [PATCH 1/2] gallium/pp: use user constant buffers

[Marek Olšák]

From: Marek Olšák 

This fixes a radeonsi crash.
---
 src/gallium/auxiliary/cso_cache/cso_context.c  | 17 
 src/gallium/auxiliary/cso_cache/cso_context.h  |  3 +++
 src/gallium/auxiliary/postprocess/pp_mlaa.c| 37 --
 src/gallium/auxiliary/postprocess/pp_private.h |  1 -
 4 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c 
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 3fa57f16ff4..3a3a63a3327 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -1540,20 +1540,37 @@ cso_set_constant_buffer_resource(struct cso_context 
*cso,
   cb.buffer = buffer;
   cb.buffer_offset = 0;
   cb.buffer_size = buffer->width0;
   cb.user_buffer = NULL;
   cso_set_constant_buffer(cso, shader_stage, index, &cb);
} else {
   cso_set_constant_buffer(cso, shader_stage, index, NULL);
}
 }
 
+void
+cso_set_constant_user_buffer(struct cso_context *cso,
+ enum pipe_shader_type shader_stage,
+ unsigned index, void *ptr, unsigned size)
+{
+   if (ptr) {
+  struct pipe_constant_buffer cb;
+  cb.buffer = NULL;
+  cb.buffer_offset = 0;
+  cb.buffer_size = size;
+  cb.user_buffer = ptr;
+  cso_set_constant_buffer(cso, shader_stage, index, &cb);
+   } else {
+  cso_set_constant_buffer(cso, shader_stage, index, NULL);
+   }
+}
+
 void
 cso_save_constant_buffer_slot0(struct cso_context *cso,
enum pipe_shader_type shader_stage)
 {
util_copy_constant_buffer(&cso->aux_constbuf_saved[shader_stage],
  &cso->aux_constbuf_current[shader_stage]);
 }
 
 void
 cso_restore_constant_buffer_slot0(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h 
b/src/gallium/auxiliary/cso_cache/cso_context.h
index b1bc0813442..3a4e808f0c0 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -207,20 +207,23 @@ cso_set_shader_images(struct cso_context *cso,
 
 /* constant buffers */
 
 void cso_set_constant_buffer(struct cso_context *cso,
  enum pipe_shader_type shader_stage,
  unsigned index, struct pipe_constant_buffer *cb);
 void cso_set_constant_buffer_resource(struct cso_context *cso,
   enum pipe_shader_type shader_stage,
   unsigned index,
   struct pipe_resource *buffer);
+void cso_set_constant_user_buffer(struct cso_context *cso,
+  enum pipe_shader_type shader_stage,
+  unsigned index, void *ptr, unsigned size);
 void cso_save_constant_buffer_slot0(struct cso_context *cso,
 enum pipe_shader_type shader_stage);
 void cso_restore_constant_buffer_slot0(struct cso_context *cso,
enum pipe_shader_type shader_stage);
 
 
 /* drawing */
 
 void
 cso_draw_vbo(struct cso_context *cso,
diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c 
b/src/gallium/auxiliary/postprocess/pp_mlaa.c
index 0edd01f3f5d..610cedbd1b3 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
@@ -50,76 +50,64 @@
 #include "util/u_inlines.h"
 #include "util/u_memory.h"
 #include "util/u_string.h"
 #include "pipe/p_screen.h"
 
 #define IMM_SPACE 80
 
 static float constants[] = { 1, 1, 0, 0 };
 static unsigned int dimensions[2] = { 0, 0 };
 
-/** Upload the constants. */
-static void
-up_consts(struct pp_queue_t *ppq)
-{
-   struct pipe_context *pipe = ppq->p->pipe;
-
-   pipe->buffer_subdata(pipe, ppq->constbuf, PIPE_TRANSFER_WRITE,
-0, sizeof(constants), constants);
-}
-
 /** Run function of the MLAA filter. */
 static void
 pp_jimenezmlaa_run(struct pp_queue_t *ppq, struct pipe_resource *in,
struct pipe_resource *out, unsigned int n, bool iscolor)
 {
 
struct pp_program *p = ppq->p;
 
struct pipe_depth_stencil_alpha_state mstencil;
struct pipe_sampler_view v_tmp, *arr[3];
 
unsigned int w = 0;
unsigned int h = 0;
 
const struct pipe_stencil_ref ref = { {1} };
 
/* Insufficient initialization checks. */
assert(p);
assert(ppq);
-   assert(ppq->constbuf);
assert(ppq->areamaptex);
assert(ppq->inner_tmp);
assert(ppq->shaders[n]);
 
w = p->framebuffer.width;
h = p->framebuffer.height;
 
memset(&mstencil, 0, sizeof(mstencil));
 
cso_set_stencil_ref(p->cso, &ref);
 
/* Init the pixel size constant */
if (dimensions[0] != p->framebuffer.width ||
dimensions[1] != p->framebuffer.height) {
   constants[0] = 1.0f / p->framebuffer.width;
   constants[1] = 1.0f / p->framebuffer.height;
 
-  up

Re: [Mesa-dev] [PATCH] gallium: add CAP for postprocess filters

[Marek Olšák]

On Wed, Apr 4, 2018 at 10:30 AM, Roland Scheidegger 
wrote:

> Am 04.04.2018 um 05:42 schrieb Timothy Arceri:
> > On 04/04/18 13:22, Roland Scheidegger wrote:
> >> Am 04.04.2018 um 05:03 schrieb Timothy Arceri:
> >>> On 04/04/18 12:44, Roland Scheidegger wrote:
>  Am 04.04.2018 um 04:32 schrieb Timothy Arceri:
> > On 04/04/18 11:58, Roland Scheidegger wrote:
> >> AFAIK these filters (and I've never looked into them) should be
> >> transparent to hw drivers. Hence a cap bit doesn't make sense, and
> if
> >> it's broken we shouldn't just paper over this.
> >
> > I created a CAP because the AMD devs have no interest in supporting
> > this
> > feature [1]. Even if they are transparent to drivers I don't see why
> > drivers should be forced to enable them if they don't want to. CCing
> > Marek for his opinion.
> 
>  I still don't see why using cap bits for bugs is a good idea.
> >>>
> >>> Well I see it as a CAP for an unwanted feature that just happens to not
> >>> work currently.
> >>>
>  (Even more so if the bug actually would be in the postprocess, but
> I've
>  no idea there really.)
> >>>
> >>> It's crashing in src/gallium/drivers/radeonsi/si_state_draw.c
> >>
> >> Doesn't necessarily mean the bug is in the driver.
> >> Not sure it's really worth fixing it this way neither - people are
> >> probably just as confused why pp won't work than they are if it's
> >> crashing...
> >
> > Well I can either update the webpage to say its disabled for radeonsi or
> > I can close the bugs as won't fix and let people wonder why its crashing
> > potentially filling another bug report. The first bug was filed a year
> > ago and nobody seems to want to fix it. Either way I don't care to much
> > but disabling the feature seems like a better way to go than just
> > letting it crash forever.
>
> Alright, if the bug is that old I suppose there's really no interest in
> actually fixing it...
> So I suppose that would be an improvement...
>

I've just fixed it. The patches are on the ML.

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

[Mesa-dev] [PATCH] ac/nir: Add workaround for GFX9 buffer views.

[Bas Nieuwenhuizen]

On GFX9 whether the buffer size is interpreted as elements or bytes
depends on whether IDXEN is enabled in the instruction. If the index
is a constant zero, LLVM optimizes IDXEN to 0.

Now the size in elements is interpreted in bytes which of course
results in out of bounds accesses.

The correct fix is most likely to disable the LLVM optimization,
but we need something to work with LLVM <= 6.0.

radeonsi does the max between stride and element count on the CPU
but that results in the size intrinsics returning the wrong size
for the buffer. This would cause CTS errors for radv.

v2: Also include the store changes.

Fixes: e38685cc62e 'Revert "radv: disable support for VEGA for now."'
(backported from 4503ff760c794c3bb15b978a47c530037d56498e for 17.3)
---
 src/amd/common/ac_llvm_build.c  | 20 
 src/amd/common/ac_llvm_build.h  |  8 
 src/amd/common/ac_nir_to_llvm.c | 36 ++--
 src/amd/common/ac_shader_abi.h  |  4 
 4 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index e5cd23e025..f193f71c3e 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -960,6 +960,26 @@ LLVMValueRef ac_build_buffer_load_format(struct 
ac_llvm_context *ctx,
  AC_FUNC_ATTR_READONLY);
 }
 
+LLVMValueRef ac_build_buffer_load_format_gfx9_safe(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef vindex,
+  LLVMValueRef voffset,
+  bool can_speculate)
+{
+   LLVMValueRef elem_count = LLVMBuildExtractElement(ctx->builder, rsrc, 
LLVMConstInt(ctx->i32, 2, 0), "");
+   LLVMValueRef stride = LLVMBuildExtractElement(ctx->builder, rsrc, 
LLVMConstInt(ctx->i32, 1, 0), "");
+   stride = LLVMBuildLShr(ctx->builder, stride, LLVMConstInt(ctx->i32, 16, 
0), "");
+
+   LLVMValueRef new_elem_count = LLVMBuildSelect(ctx->builder,
+ 
LLVMBuildICmp(ctx->builder, LLVMIntUGT, elem_count, stride, ""),
+ elem_count, stride, "");
+
+   LLVMValueRef new_rsrc = LLVMBuildInsertElement(ctx->builder, rsrc, 
new_elem_count,
+  LLVMConstInt(ctx->i32, 
2, 0), "");
+
+   return ac_build_buffer_load_format(ctx, new_rsrc, vindex, voffset, 
can_speculate);
+}
+
 /**
  * Set range metadata on an instruction.  This can only be used on load and
  * call instructions.  If you know an instruction can only produce the values
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index aa2a2899ab..d4264f2879 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -188,6 +188,14 @@ LLVMValueRef ac_build_buffer_load_format(struct 
ac_llvm_context *ctx,
 LLVMValueRef voffset,
 bool can_speculate);
 
+/* load_format that handles the stride & element count better if idxen is
+ * disabled by LLVM. */
+LLVMValueRef ac_build_buffer_load_format_gfx9_safe(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef vindex,
+  LLVMValueRef voffset,
+  bool can_speculate);
+
 LLVMValueRef
 ac_get_thread_id(struct ac_llvm_context *ctx);
 
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index b696cb8a45..8ee80b1a67 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -2257,11 +2257,19 @@ static LLVMValueRef build_tex_intrinsic(struct 
ac_nir_context *ctx,
struct ac_image_args *args)
 {
if (instr->sampler_dim == GLSL_SAMPLER_DIM_BUF) {
-   return ac_build_buffer_load_format(&ctx->ac,
-  args->resource,
-  args->addr,
-  LLVMConstInt(ctx->ac.i32, 0, 
false),
-  true);
+   if (ctx->abi->gfx9_stride_size_workaround) {
+   return ac_build_buffer_load_format_gfx9_safe(&ctx->ac,
+
args->resource,
+args->addr,
+
ctx->ac.i32_0,
+true);
+   } else {
+   re

Re: [Mesa-dev] [PATCH v3 013/104] nir: Support deref instructions in remove_dead_variables

[Caio Marcelo de Oliveira Filho]

Hi,

> @@ -144,6 +197,45 @@ remove_dead_var_writes(nir_shader *shader, struct set 
> *live)
> nir_instr_remove(instr);
>   }
>}
> +
> +  /* We walk the list of instructions backwards because we're going to
> +   * delete a deref and all of it's uses and we don't want to end up
> +   * deleting stuff ahead of us.
> +   */
> +  nir_foreach_block(block, function->impl) {
> + nir_foreach_instr_safe(instr, block) {

The comment says backwards, the loop walks forwards.

It seems to me propagating the mode needs to be forward, e.g. a deref
will be marked mode = 0 because of a variable, then another deref that
has the first as parent marked mode = 0. But I might be missing
something.


> +switch (instr->type) {
> +case nir_instr_type_deref: {
> +   /* For deref instructions, propagate modes */
> +   nir_deref_instr *deref = nir_instr_as_deref(instr);
> +   if (deref->deref_type == nir_deref_type_var) {
> +  deref->mode = deref->var->data.mode;
> +   } else {
> +  nir_deref_instr *parent = nir_deref_instr_parent(deref);
> +  deref->mode = parent->mode;
> +   }

Should we write deref->mode only if the new mode is zero?
I.e. deref->var->data.mode == 0 for the first case, and parent->mode
== 0 for the else case.


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

[Mesa-dev] [PATCH v2 06/11] i965/miptree: Extend the sRGB-blending WA to future platforms

[Nanley Chery]

The blending issue seems to be present on CNL as well.

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index c21c4d8bae1..87c730452b5 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2704,11 +2704,11 @@ intel_miptree_render_aux_usage(struct brw_context *brw,
  return ISL_AUX_USAGE_NONE;
   }
 
-  /* gen9 hardware technically supports non-0/1 clear colors with sRGB
+  /* gen9+ hardware technically supports non-0/1 clear colors with sRGB
* formats.  However, there are issues with blending where it doesn't
* properly apply the sRGB curve to the clear color when blending.
*/
-  if (devinfo->gen == 9 && blend_enabled &&
+  if (devinfo->gen >= 9 && blend_enabled &&
   isl_format_is_srgb(render_format) &&
   !isl_color_value_is_zero_one(mt->fast_clear_color, render_format))
  return ISL_AUX_USAGE_NONE;
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 03/11] i965: Make the miptree clear color setter take a gl_color_union

[Nanley Chery]

We want to hide the internal details of how the miptree's clear color
is calculated.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 5 +
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index f5a653fff97..6ab5267ddea 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1236,12 +1236,9 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
if (can_fast_clear) {
   const enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(irb->mt, irb->mt_level, irb->mt_layer);
-  union isl_color_value clear_color =
- brw_meta_convert_fast_clear_color(brw, irb->mt,
-   &ctx->Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, &ctx->Color.ClearColor);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 163accf023b..7aa0e7920d3 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -36,6 +36,7 @@
 
 #include "brw_blorp.h"
 #include "brw_context.h"
+#include "brw_meta_util.h"
 #include "brw_state.h"
 
 #include "main/enums.h"
@@ -3774,8 +3775,11 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
+  const union gl_color_union *color)
 {
+   const union isl_color_value clear_color =
+  brw_meta_convert_fast_clear_color(brw, mt, color);
+
if (memcmp(&mt->fast_clear_color, &clear_color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
   brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 600296904ba..961f8fe812e 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -718,7 +718,7 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color);
+  const union gl_color_union *color);
 
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 02/11] i965/miptree: Move the clear color and value setter implementations

[Nanley Chery]

These will get more complex in later commits.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 26 ++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 25 -
 2 files changed, 30 insertions(+), 21 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 23cb40f3226..163accf023b 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3770,3 +3770,29 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
 
return mt->aux_usage;
 }
+
+bool
+intel_miptree_set_clear_color(struct brw_context *brw,
+  struct intel_mipmap_tree *mt,
+  union isl_color_value clear_color)
+{
+   if (memcmp(&mt->fast_clear_color, &clear_color, sizeof(clear_color)) != 0) {
+  mt->fast_clear_color = clear_color;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
+
+bool
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
+struct intel_mipmap_tree *mt,
+float clear_value)
+{
+   if (mt->fast_clear_color.f32[0] != clear_value) {
+  mt->fast_clear_color.f32[0] = clear_value;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
+  return true;
+   }
+   return false;
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 0c24b93e3da..600296904ba 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,32 +715,15 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
-
-static inline bool
+bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-  union isl_color_value clear_color)
-{
-   if (memcmp(&mt->fast_clear_color, &clear_color, sizeof(clear_color)) != 0) {
-  mt->fast_clear_color = clear_color;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+  union isl_color_value clear_color);
 
-static inline bool
+bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-float clear_value)
-{
-   if (mt->fast_clear_color.f32[0] != clear_value) {
-  mt->fast_clear_color.f32[0] = clear_value;
-  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
-  return true;
-   }
-   return false;
-}
+float clear_value);
 
 #ifdef __cplusplus
 }
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 01/11] i965: Use the brw_context for the clear color and value setters

[Nanley Chery]

Do what all the other functions in the miptree API do.

Reviewed-by: Topi Pohjolainen 
Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
 src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 44064fc0cf3..f5a653fff97 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1241,7 +1241,7 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
&ctx->Color.ClearColor);
 
   bool same_clear_color =
- !intel_miptree_set_clear_color(ctx, irb->mt, clear_color);
+ !intel_miptree_set_clear_color(brw, irb->mt, clear_color);
 
   /* If the buffer is already in INTEL_FAST_CLEAR_STATE_CLEAR, the clear
* is redundant and can be skipped.
diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8aa83722ee9..8f7594baf59 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -212,7 +212,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
  }
   }
 
-  intel_miptree_set_depth_clear_value(ctx, mt, clear_value);
+  intel_miptree_set_depth_clear_value(brw, mt, clear_value);
}
 
bool need_clear = false;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 07c85807e80..0c24b93e3da 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -717,26 +717,26 @@ intel_miptree_sample_with_hiz(struct brw_context *brw,
 
 
 static inline bool
-intel_miptree_set_clear_color(struct gl_context *ctx,
+intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   union isl_color_value clear_color)
 {
if (memcmp(&mt->fast_clear_color, &clear_color, sizeof(clear_color)) != 0) {
   mt->fast_clear_color = clear_color;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
 }
 
 static inline bool
-intel_miptree_set_depth_clear_value(struct gl_context *ctx,
+intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
 float clear_value)
 {
if (mt->fast_clear_color.f32[0] != clear_value) {
   mt->fast_clear_color.f32[0] = clear_value;
-  ctx->NewDriverState |= BRW_NEW_AUX_STATE;
+  brw->ctx.NewDriverState |= BRW_NEW_AUX_STATE;
   return true;
}
return false;
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 07/11] i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL

[Nanley Chery]

The paths which sample with the clear color are now using a getter which
performs the sRGB decode needed to enable this fast clear.

This path can be exercised by fast-clearing a texture, then performing
an operation which requires sRGB decoding. Test coverage for this
feature is provided with the following tests:

* Shader texture calls:
  - spec@ext_texture_srgb@tex-srgb

* Shader texelfetch calls:
  - spec@arb_framebuffer_srgb@fbo-fast-clear
  - spec@arb_framebuffer_srgb@msaa-fast-clear

* Blending:
  - spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend

* Blitting:
  - spec@arb_framebuffer_srgb@blit texture srgb msaa enabled clear

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_meta_util.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_util.c 
b/src/mesa/drivers/dri/i965/brw_meta_util.c
index b31181521c7..d292f5a8e24 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_util.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_util.c
@@ -293,18 +293,7 @@ brw_is_color_fast_clear_compatible(struct brw_context *brw,
brw->mesa_to_isl_render_format[mt->format])
   return false;
 
-   const bool srgb_rb = _mesa_get_srgb_format_linear(mt->format) != mt->format;
-  /* Gen10 doesn't automatically decode the clear color of sRGB buffers. Since
-   * we currently don't perform this decode in software, avoid a fast-clear
-   * altogether. TODO: Do this in software.
-   */
const mesa_format format = _mesa_get_render_format(ctx, mt->format);
-   if (devinfo->gen >= 10 && srgb_rb) {
-  perf_debug("sRGB fast clear not enabled for (%s)",
- _mesa_get_format_name(format));
-  return false;
-   }
-
if (_mesa_is_format_integer_color(format)) {
   if (devinfo->gen >= 8) {
  perf_debug("Integer fast clear not enabled for (%s)",
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 00/11] Enable sRGB-encoded fast-clears on CNL

[Nanley Chery]

Compared to the v1, this v2 manages to restrict the uses of
intel_miptree::fast_clear_color to the miptree module with less churn.

Notes:
* Patches 8-10 have no reviews.
* Patches 10-11 are optional improvements found by inspection.

Jason Ekstrand (1):
  util/srgb: Add a float sRGB -> linear helper

Nanley Chery (10):
  i965: Use the brw_context for the clear color and value setters
  i965/miptree: Move the clear color and value setter implementations
  i965: Make the miptree clear color setter take a gl_color_union
  i965: Add and use a getter for the clear color
  i965/miptree: Extend the sRGB-blending WA to future platforms
  i965/meta_util: Re-enable sRGB-encoded fast-clears on CNL
  i965: Add and use a getter for depth miptree clear values
  i965: Add and use a helper for depth miptree clear values
  i965/brw_clear: Remove extra for-loop in brw_fast_clear_depth
  i965/blorp: Also skip the fast clear if the clear color differs

 src/mesa/drivers/dri/i965/brw_blorp.c| 14 ++--
 src/mesa/drivers/dri/i965/brw_clear.c| 35 ++
 src/mesa/drivers/dri/i965/brw_meta_util.c| 11 ---
 src/mesa/drivers/dri/i965/brw_misc_state.c   | 15 -
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +-
 src/mesa/drivers/dri/i965/gen6_depth_state.c |  4 +-
 src/mesa/drivers/dri/i965/gen7_misc_state.c  |  3 +-
 src/mesa/drivers/dri/i965/gen8_depth_state.c |  3 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 85 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h| 43 ++--
 src/util/format_srgb.h   | 14 
 11 files changed, 138 insertions(+), 93 deletions(-)

-- 
2.16.2

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

[Mesa-dev] [PATCH v2 04/11] util/srgb: Add a float sRGB -> linear helper

[Nanley Chery]

From: Jason Ekstrand 

Reviewed-by: Nanley Chery 
Reviewed-by: Jason Ekstrand 
---
 src/util/format_srgb.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/util/format_srgb.h b/src/util/format_srgb.h
index 34b50afe3d1..596af56f4cd 100644
--- a/src/util/format_srgb.h
+++ b/src/util/format_srgb.h
@@ -54,6 +54,20 @@ extern const unsigned
 util_format_linear_to_srgb_helper_table[104];
 
 
+static inline float
+util_format_srgb_to_linear_float(float cs)
+{
+   if (cs <= 0.0f)
+  return 0.0f;
+   else if (cs <= 0.04045f)
+  return cs / 12.92f;
+   else if (cs < 1.0f)
+  return powf((cs + 0.055) / 1.055f, 2.4f);
+   else
+  return 1.0f;
+}
+
+
 static inline float
 util_format_linear_to_srgb_float(float cl)
 {
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 10/11] i965/brw_clear: Remove extra for-loop in brw_fast_clear_depth

[Nanley Chery]

Make the algorithm easier to follow.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 31 ---
 1 file changed, 4 insertions(+), 27 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 653abae2d8f..cda47bcabac 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -215,26 +215,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
   intel_miptree_set_depth_clear_value(brw, mt, clear_value);
}
 
-   bool need_clear = false;
-   for (unsigned a = 0; a < num_layers; a++) {
-  enum isl_aux_state aux_state =
- intel_miptree_get_aux_state(mt, depth_irb->mt_level,
- depth_irb->mt_layer + a);
-
-  if (aux_state != ISL_AUX_STATE_CLEAR) {
- need_clear = true;
- break;
-  }
-   }
-
-   if (!need_clear) {
-  /* If all of the layers we intend to clear are already in the clear
-   * state then simply updating the miptree fast clear value is sufficient
-   * to change their clear value.
-   */
-  return true;
-   }
-
+   /* Fast-clear any of the layers that are not already in the clear state. */
for (unsigned a = 0; a < num_layers; a++) {
   enum isl_aux_state aux_state =
  intel_miptree_get_aux_state(mt, depth_irb->mt_level,
@@ -244,16 +225,12 @@ brw_fast_clear_depth(struct gl_context *ctx)
  intel_hiz_exec(brw, mt, depth_irb->mt_level,
 depth_irb->mt_layer + a, 1,
 ISL_AUX_OP_FAST_CLEAR);
+ intel_miptree_set_aux_state(brw, mt, depth_irb->mt_level,
+ depth_irb->mt_layer + a, 1,
+ ISL_AUX_STATE_CLEAR);
   }
}
 
-   /* Now, the HiZ buffer contains data that needs to be resolved to the depth
-* buffer.
-*/
-   intel_miptree_set_aux_state(brw, mt, depth_irb->mt_level,
-   depth_irb->mt_layer, num_layers,
-   ISL_AUX_STATE_CLEAR);
-
return true;
 }
 
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 09/11] i965: Add and use a helper for depth miptree clear values

[Nanley Chery]

Add and use a comparison function to remove the last external user of
intel_miptree::fast_color_clear.
---
 src/mesa/drivers/dri/i965/brw_clear.c | 2 +-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 7 +++
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 4 
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_clear.c 
b/src/mesa/drivers/dri/i965/brw_clear.c
index 8f7594baf59..653abae2d8f 100644
--- a/src/mesa/drivers/dri/i965/brw_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_clear.c
@@ -175,7 +175,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
/* If we're clearing to a new clear value, then we need to resolve any clear
 * flags out of the HiZ buffer into the real depth buffer.
 */
-   if (mt->fast_clear_color.f32[0] != clear_value) {
+   if (!intel_miptree_has_depth_clear_value(mt, clear_value)) {
   for (uint32_t level = mt->first_level; level <= mt->last_level; level++) 
{
  if (!intel_miptree_level_has_hiz(mt, level))
 continue;
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index dec2e614938..c2363979564 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -3775,6 +3775,13 @@ intel_miptree_get_aux_isl_usage(const struct brw_context 
*brw,
return mt->aux_usage;
 }
 
+bool
+intel_miptree_has_depth_clear_value(const struct intel_mipmap_tree *mt,
+float clear_value)
+{
+   return mt->fast_clear_color.f32[0] == clear_value;
+}
+
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index edf9a619218..1070921837f 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -715,6 +715,10 @@ bool
 intel_miptree_sample_with_hiz(struct brw_context *brw,
   struct intel_mipmap_tree *mt);
 
+bool
+intel_miptree_has_depth_clear_value(const struct intel_mipmap_tree *mt,
+float clear_value);
+
 bool
 intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
-- 
2.16.2

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

[Mesa-dev] [PATCH v2 05/11] i965: Add and use a getter for the clear color

[Nanley Chery]

Use a getter which allows CNL to sample from sRGB textures correctly.

Reviewed-by: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/brw_blorp.c|  4 +++-
 src/mesa/drivers/dri/i965/brw_wm_surface_state.c |  4 +++-
 src/mesa/drivers/dri/i965/intel_mipmap_tree.c| 25 
 src/mesa/drivers/dri/i965/intel_mipmap_tree.h|  7 +++
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 6ab5267ddea..c6fa5195ee3 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -172,7 +172,9 @@ blorp_surf_for_miptree(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  surf->clear_color = mt->fast_clear_color;
+  surf->clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, mt->surf.format,
+   !is_render_target);
 
   surf->aux_surf = aux_surf;
   surf->aux_addr = (struct blorp_address) {
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index caa92d7d878..2c9e986b184 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -178,7 +178,9 @@ brw_emit_surface_state(struct brw_context *brw,
   /* We only really need a clear color if we also have an auxiliary
* surface.  Without one, it does nothing.
*/
-  clear_color = mt->fast_clear_color;
+  clear_color =
+ intel_miptree_get_clear_color(devinfo, mt, view.format,
+   view.usage & 
ISL_SURF_USAGE_TEXTURE_BIT);
}
 
void *state = brw_state_batch(brw,
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 7aa0e7920d3..c21c4d8bae1 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -46,6 +46,9 @@
 #include "main/texcompress_etc.h"
 #include "main/teximage.h"
 #include "main/streaming-load-memcpy.h"
+
+#include "util/format_srgb.h"
+
 #include "x86/common_x86_asm.h"
 
 #define FILE_DEBUG_FLAG DEBUG_MIPTREE
@@ -3800,3 +3803,25 @@ intel_miptree_set_depth_clear_value(struct brw_context 
*brw,
}
return false;
 }
+
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling)
+{
+   /* Prior to gen10, the clear color can be used unchanged. From gen10
+* onwards, HW no longer gamma-corrects the clear color for sampling
+* operations.
+*/
+   if (devinfo->gen >= 10 && isl_format_is_srgb(view_format) && sampling) {
+  union isl_color_value linear_color = mt->fast_clear_color;
+  for (unsigned i = 0; i < 3; i++) {
+ linear_color.f32[i] =
+util_format_srgb_to_linear_float(mt->fast_clear_color.f32[i]);
+  }
+  return linear_color;
+   } else {
+  return mt->fast_clear_color;
+   }
+}
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h 
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
index 961f8fe812e..e66a2a8d384 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.h
@@ -720,6 +720,13 @@ intel_miptree_set_clear_color(struct brw_context *brw,
   struct intel_mipmap_tree *mt,
   const union gl_color_union *color);
 
+/* Get a clear color suitable for filling out an ISL surface state. */
+union isl_color_value
+intel_miptree_get_clear_color(const struct gen_device_info *devinfo,
+  const struct intel_mipmap_tree *mt,
+  enum isl_format view_format,
+  bool sampling);
+
 bool
 intel_miptree_set_depth_clear_value(struct brw_context *brw,
 struct intel_mipmap_tree *mt,
-- 
2.16.2

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