[Mesa-dev] [Bug 105068] vulkaninfo gives an VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

--- Comment #5 from Pietro Pesci Feltri  ---
I add the parameters manually pressing "e" in the grub menu 2 days ago. One
hour later the initialization process was not ended.
I was forced to reboot the machine.

Anyway thanks.

-- 
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] intel/gen9+: Enable object level preemption.

[Ben Widawsky]

On 18-02-16 13:44:00, Antognolli, Rafael wrote:

"This field controls the granularity of the replay mechanism when
coming back into a previously preempted context."

The kernel disables this bit but whitelists the register, and it's a
context register. So enable it and take advantage of finer granularity
when preemption is available.



Does the kernel actually disable it? I thought the kernel just doesn't touch it
(I don't think it's whitelisted by the kernel either, it's just writable).


Signed-off-by: Rafael Antognolli 
Cc: Ben Widawsky 
---

This patch still needs more testing (only ran it through CI and also did
some basic tests on my machine to make sure it's not breaking anything).

src/intel/genxml/gen10.xml   |  8 
src/intel/genxml/gen11.xml   |  8 
src/intel/genxml/gen9.xml|  8 
src/intel/vulkan/genX_state.c| 18 ++
src/mesa/drivers/dri/i965/brw_defines.h  |  5 +
src/mesa/drivers/dri/i965/brw_state_upload.c | 10 ++
6 files changed, 57 insertions(+)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 47c679a3fa9..42ac6e82696 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -3692,6 +3692,14 @@

  

+  
+
+  
+  
+
+
+  
+
  

  
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 9a8a2fe21e3..e6ce42b2bfb 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -3688,6 +3688,14 @@

  

+  
+
+  
+  
+
+
+  
+
  

  
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 7eef4bee013..45e1fddeb50 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3638,6 +3638,14 @@

  

+  
+
+  
+  
+
+
+  
+
  

  
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index 54fb8634fdc..83b6c6387f3 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -169,6 +169,24 @@ genX(init_device_state)(struct anv_device *device)
   gen10_emit_wa_lri_to_cache_mode_zero();
#endif

+#if GEN_GEN >= 9
+   /* A fixed function pipe flush is required before modifying this field */
+   anv_batch_emit(, GENX(PIPE_CONTROL), pipe) {
+  pipe.PipeControlFlushEnable = true;
+   }
+
+   /* enable object level preemption */
+   uint32_t csc1;
+
+   anv_pack_struct(, GENX(CS_CHICKEN1),
+   .ReplayMode = ObjectLevelPreemption,
+   .ReplayModeMask = 1);
+   anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+  lri.RegisterOffset   = GENX(CS_CHICKEN1_num);
+  lri.DataDWord= csc1;
+   }
+#endif
+
   anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);

   assert(batch.next <= batch.end);
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 8bf6f68b67c..f0994d3b139 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1661,4 +1661,9 @@ enum brw_pixel_shader_coverage_mask_mode {
# define GLK_SCEC_BARRIER_MODE_3D_HULL (1 << 7)
# define GLK_SCEC_BARRIER_MODE_MASKREG_MASK(1 << 7)

+#define CS_CHICKEN10x2580 /* Gen9+ */
+# define GEN9_REPLAY_MODE_MIDBUFFER (0 << 0)
+# define GEN9_REPLAY_MODE_MIDOBJECT (1 << 0)
+# define GEN9_REPLAY_MODE_MASK  REG_MASK(1 << 0)
+
#endif
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 86c12e4d357..a90dc01d87b 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -115,6 +115,16 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
  OUT_BATCH(0);
  ADVANCE_BATCH();
   }
+
+   if (devinfo->gen >= 9) {
+  /* A fixed function pipe flush is required before modifying this field */
+  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);
+
+  /* enable object level preemption */
+  brw_load_register_imm32(brw, CS_CHICKEN1,
+  GEN9_REPLAY_MODE_MIDOBJECT |
+  GEN9_REPLAY_MODE_MASK);
+   }


One other option BTW is a context parameter in i915 driver. Note sure if you
discussed this with the i915 folks, but it could make some sense.



}

static inline const struct brw_tracked_state *


Everything looks in order to me.

Reviewed-by: Ben Widawsky 


--
2.14.3


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

Re: [Mesa-dev] [PATCH v2] radv: compact varyings after removing unused ones

[Timothy Arceri]

On 16/02/18 21:07, Samuel Pitoiset wrote:

Vega stats should be:

Totals from affected shaders:
SGPRS: 106088 -> 106232 (0.14 %)
VGPRS: 74652 -> 74700 (0.06 %)
Spilled SGPRs: 692 -> 658 (-4.91 %)
Code Size: 2967708 -> 2953028 (-0.49 %) bytes
Max Waves: 18178 -> 18162 (-0.09 %)

My local override family was wrong because I have plugged my polaris10 
yesterday. :)


On 02/16/2018 10:28 AM, Samuel Pitoiset wrote:

It makes no sense to compact before, and the description of
nir_compact_varyings() confirms that.

Polaris10:
Totals from affected shaders:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

Totals from affected shaders:
Vega10:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

v2: - compact varyings even if no varyings were removed
 - update shader stats (which are better than v1)


Yeah that makes sense :)

Reviewed-by: Timothy Arceri 



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

diff --git a/src/amd/vulkan/radv_pipeline.c 
b/src/amd/vulkan/radv_pipeline.c

index 0d1958fc93..88646fda2f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1524,6 +1524,9 @@ radv_link_shaders(struct radv_pipeline 
*pipeline, nir_shader **shaders)

  bool progress = nir_remove_unused_varyings(ordered_shaders[i],
 ordered_shaders[i - 1]);
+    nir_compact_varyings(ordered_shaders[i],
+ ordered_shaders[i - 1], true);
+
  if (progress) {
  if (nir_lower_global_vars_to_local(ordered_shaders[i])) {
  radv_lower_indirect_derefs(ordered_shaders[i],
@@ -1722,7 +1725,6 @@ void radv_create_shaders(struct radv_pipeline 
*pipeline,

  last = i;
  }
-    int prev = -1;
  for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
  const VkPipelineShaderStageCreateInfo *stage = pStages[i];
@@ -1753,11 +1755,6 @@ void radv_create_shaders(struct radv_pipeline 
*pipeline,

  nir_lower_io_to_scalar_early(nir[i], mask);
  radv_optimize_nir(nir[i]);
  }
-
-    if (prev != -1) {
-    nir_compact_varyings(nir[prev], nir[i], true);
-    }
-    prev = i;
  }
  if (nir[MESA_SHADER_TESS_CTRL]) {


___
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] i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.

[Francisco Jerez]

Kenneth Graunke  writes:

> By default, 3DSTATE_CONSTANT_* Constant Buffer 0 is relative to dynamic
> state base address.  This makes it unusable for pushing UBOs.
>
> There is a bit in the INSTPM register (or CS_DEBUG_MODE2 on Skylake)
> which controls whether buffer 0 is relative to dynamic state base
> address, or simply a normal pointer.  Setting that gives us full
> flexibility.  This lets us push up to 4 UBO ranges.
>
> We can't currently write this on Haswell and earlier, and will need
> to update the kernel command parser, and then do the whole version
> checking song and dance.  We also need a brand new kernel that supports
> context isolation - on older kernels, newly created contexts inherit
> register state from whatever happened to be running.  So, setting this
> would have catastrophic impact on other drivers such as libva, Beignet,
> or older Mesa.
>
> See commit 8ec5a4e4a4a32f4de351c5fc2bf0eb615b6eef1b where we did this
> once before, but had to revert it in commit 013d33122028f2492da90a03a.

Reviewed-by: Francisco Jerez 

> ---
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
>  src/mesa/drivers/dri/i965/intel_screen.c |  9 -
>  2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 86c12e4d357..d8273aa5734 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -49,6 +49,7 @@ static void
>  brw_upload_initial_gpu_state(struct brw_context *brw)
>  {
> const struct gen_device_info *devinfo = >screen->devinfo;
> +   const struct brw_compiler *compiler = brw->screen->compiler;
>  
> /* On platforms with hardware contexts, we can set our initial GPU state
>  * right away rather than doing it via state atoms.  This saves a small
> @@ -115,6 +116,29 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
>OUT_BATCH(0);
>ADVANCE_BATCH();
> }
> +
> +   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
> +* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
> +*
> +* This is only safe on kernels with context isolation support.
> +*/
> +   if (!compiler->constant_buffer_0_is_relative) {
> +  if (devinfo->gen >= 9) {
> + BEGIN_BATCH(3);
> + OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> + OUT_BATCH(CS_DEBUG_MODE2);
> + OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> +   CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> + ADVANCE_BATCH();
> +  } else if (devinfo->gen == 8) {
> + BEGIN_BATCH(3);
> + OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
> + OUT_BATCH(INSTPM);
> + OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
> +   INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
> + ADVANCE_BATCH();
> +  }
> +   }
>  }
>  
>  static inline const struct brw_tracked_state *
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index d275b28a4b9..4b62c5f66cb 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -2694,7 +2694,14 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
> screen->compiler = brw_compiler_create(screen, devinfo);
> screen->compiler->shader_debug_log = shader_debug_log_mesa;
> screen->compiler->shader_perf_log = shader_perf_log_mesa;
> -   screen->compiler->constant_buffer_0_is_relative = true;
> +
> +   /* Changing the meaning of constant buffer pointers from a dynamic state
> +* offset to an absolute address is only safe if the kernel isolates other
> +* contexts from our changes.
> +*/
> +   screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8 ||
> +  !(screen->kernel_features & KERNEL_ALLOWS_CONTEXT_ISOLATION);
> +
> screen->compiler->supports_pull_constants = true;
>  
> screen->has_exec_fence =
> -- 
> 2.16.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH 1/2] i965: Stop restoring the default L3 configuration on Kernel 4.16+.

[Francisco Jerez]

Kenneth Graunke  writes:

> Kernel 4.16 has proper context isolation, which means we can change
> the L3 configuration without worrying about that leaking to other
> newly created contexts, breaking the assumptions of other userspace.
>
> So, disable our workaround to reprogram it back to the default.
> ---
>  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +++--
>  src/mesa/drivers/dri/i965/intel_screen.c  | 3 +++
>  src/mesa/drivers/dri/i965/intel_screen.h  | 1 +
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> I tested this locally with Piglit and KHR-GLES31.*compute* running
> concurrently, on 4.16-rc1.  It seemed to work fine.  I verified that
> there were no regressions in the CI, but the CI doesn't run 4.16+, so
> I wouldn't expect much to show up there.
>

I doubt that running Piglit and CTS alone would have caught much,
because they shouldn't ever have been particularly sensitive to L3 state
leaks since they don't use MI_RESTORE_INHIBIT.  That said this seems
like the right thing to do to me:

Reviewed-by: Francisco Jerez 

> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
> b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 8a2b4218608..d0999bb3caa 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -739,9 +739,10 @@ brw_finish_batch(struct brw_context *brw)
> if (brw->batch.ring == RENDER_RING) {
>/* Work around L3 state leaks into contexts set MI_RESTORE_INHIBIT 
> which
> * assume that the L3 cache is configured according to the hardware
> -   * defaults.
> +   * defaults.  On Kernel 4.16+, we no longer need to do this.
> */
> -  if (devinfo->gen >= 7)
> +  if (devinfo->gen >= 7 &&
> +  !(brw->screen->kernel_features & KERNEL_ALLOWS_CONTEXT_ISOLATION))
>   gen7_restore_default_l3_config(brw);
>  
>if (devinfo->is_haswell) {
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index cc9b3486743..d275b28a4b9 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -2654,6 +2654,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
> if (devinfo->gen >= 8 || screen->cmd_parser_version >= 5)
>screen->kernel_features |= KERNEL_ALLOWS_COMPUTE_DISPATCH;
>  
> +   if (intel_get_boolean(screen, I915_PARAM_HAS_CONTEXT_ISOLATION))
> +  screen->kernel_features |= KERNEL_ALLOWS_CONTEXT_ISOLATION;
> +
> const char *force_msaa = getenv("INTEL_FORCE_MSAA");
> if (force_msaa) {
>screen->winsys_msaa_samples_override =
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
> b/src/mesa/drivers/dri/i965/intel_screen.h
> index ef2d08974ed..a2bce921449 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.h
> +++ b/src/mesa/drivers/dri/i965/intel_screen.h
> @@ -81,6 +81,7 @@ struct intel_screen
>  #define KERNEL_ALLOWS_COMPUTE_DISPATCH  (1<<4)
>  #define KERNEL_ALLOWS_EXEC_CAPTURE  (1<<5)
>  #define KERNEL_ALLOWS_EXEC_BATCH_FIRST  (1<<6)
> +#define KERNEL_ALLOWS_CONTEXT_ISOLATION (1<<7)
>  
> struct brw_bufmgr *bufmgr;
>  
> -- 
> 2.16.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [PATCH 2/2] i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.

[Kenneth Graunke]

By default, 3DSTATE_CONSTANT_* Constant Buffer 0 is relative to dynamic
state base address.  This makes it unusable for pushing UBOs.

There is a bit in the INSTPM register (or CS_DEBUG_MODE2 on Skylake)
which controls whether buffer 0 is relative to dynamic state base
address, or simply a normal pointer.  Setting that gives us full
flexibility.  This lets us push up to 4 UBO ranges.

We can't currently write this on Haswell and earlier, and will need
to update the kernel command parser, and then do the whole version
checking song and dance.  We also need a brand new kernel that supports
context isolation - on older kernels, newly created contexts inherit
register state from whatever happened to be running.  So, setting this
would have catastrophic impact on other drivers such as libva, Beignet,
or older Mesa.

See commit 8ec5a4e4a4a32f4de351c5fc2bf0eb615b6eef1b where we did this
once before, but had to revert it in commit 013d33122028f2492da90a03a.
---
 src/mesa/drivers/dri/i965/brw_state_upload.c | 24 
 src/mesa/drivers/dri/i965/intel_screen.c |  9 -
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 86c12e4d357..d8273aa5734 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -49,6 +49,7 @@ static void
 brw_upload_initial_gpu_state(struct brw_context *brw)
 {
const struct gen_device_info *devinfo = >screen->devinfo;
+   const struct brw_compiler *compiler = brw->screen->compiler;
 
/* On platforms with hardware contexts, we can set our initial GPU state
 * right away rather than doing it via state atoms.  This saves a small
@@ -115,6 +116,29 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
   OUT_BATCH(0);
   ADVANCE_BATCH();
}
+
+   /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
+* 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
+*
+* This is only safe on kernels with context isolation support.
+*/
+   if (!compiler->constant_buffer_0_is_relative) {
+  if (devinfo->gen >= 9) {
+ BEGIN_BATCH(3);
+ OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
+ OUT_BATCH(CS_DEBUG_MODE2);
+ OUT_BATCH(REG_MASK(CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
+   CSDBG2_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
+ ADVANCE_BATCH();
+  } else if (devinfo->gen == 8) {
+ BEGIN_BATCH(3);
+ OUT_BATCH(MI_LOAD_REGISTER_IMM | (3 - 2));
+ OUT_BATCH(INSTPM);
+ OUT_BATCH(REG_MASK(INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE) |
+   INSTPM_CONSTANT_BUFFER_ADDRESS_OFFSET_DISABLE);
+ ADVANCE_BATCH();
+  }
+   }
 }
 
 static inline const struct brw_tracked_state *
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index d275b28a4b9..4b62c5f66cb 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2694,7 +2694,14 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
screen->compiler = brw_compiler_create(screen, devinfo);
screen->compiler->shader_debug_log = shader_debug_log_mesa;
screen->compiler->shader_perf_log = shader_perf_log_mesa;
-   screen->compiler->constant_buffer_0_is_relative = true;
+
+   /* Changing the meaning of constant buffer pointers from a dynamic state
+* offset to an absolute address is only safe if the kernel isolates other
+* contexts from our changes.
+*/
+   screen->compiler->constant_buffer_0_is_relative = devinfo->gen < 8 ||
+  !(screen->kernel_features & KERNEL_ALLOWS_CONTEXT_ISOLATION);
+
screen->compiler->supports_pull_constants = true;
 
screen->has_exec_fence =
-- 
2.16.1

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

[Mesa-dev] [PATCH 1/2] i965: Stop restoring the default L3 configuration on Kernel 4.16+.

[Kenneth Graunke]

Kernel 4.16 has proper context isolation, which means we can change
the L3 configuration without worrying about that leaking to other
newly created contexts, breaking the assumptions of other userspace.

So, disable our workaround to reprogram it back to the default.
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +++--
 src/mesa/drivers/dri/i965/intel_screen.c  | 3 +++
 src/mesa/drivers/dri/i965/intel_screen.h  | 1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

I tested this locally with Piglit and KHR-GLES31.*compute* running
concurrently, on 4.16-rc1.  It seemed to work fine.  I verified that
there were no regressions in the CI, but the CI doesn't run 4.16+, so
I wouldn't expect much to show up there.

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 8a2b4218608..d0999bb3caa 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -739,9 +739,10 @@ brw_finish_batch(struct brw_context *brw)
if (brw->batch.ring == RENDER_RING) {
   /* Work around L3 state leaks into contexts set MI_RESTORE_INHIBIT which
* assume that the L3 cache is configured according to the hardware
-   * defaults.
+   * defaults.  On Kernel 4.16+, we no longer need to do this.
*/
-  if (devinfo->gen >= 7)
+  if (devinfo->gen >= 7 &&
+  !(brw->screen->kernel_features & KERNEL_ALLOWS_CONTEXT_ISOLATION))
  gen7_restore_default_l3_config(brw);
 
   if (devinfo->is_haswell) {
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cc9b3486743..d275b28a4b9 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -2654,6 +2654,9 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
if (devinfo->gen >= 8 || screen->cmd_parser_version >= 5)
   screen->kernel_features |= KERNEL_ALLOWS_COMPUTE_DISPATCH;
 
+   if (intel_get_boolean(screen, I915_PARAM_HAS_CONTEXT_ISOLATION))
+  screen->kernel_features |= KERNEL_ALLOWS_CONTEXT_ISOLATION;
+
const char *force_msaa = getenv("INTEL_FORCE_MSAA");
if (force_msaa) {
   screen->winsys_msaa_samples_override =
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h
index ef2d08974ed..a2bce921449 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -81,6 +81,7 @@ struct intel_screen
 #define KERNEL_ALLOWS_COMPUTE_DISPATCH  (1<<4)
 #define KERNEL_ALLOWS_EXEC_CAPTURE  (1<<5)
 #define KERNEL_ALLOWS_EXEC_BATCH_FIRST  (1<<6)
+#define KERNEL_ALLOWS_CONTEXT_ISOLATION (1<<7)
 
struct brw_bufmgr *bufmgr;
 
-- 
2.16.1

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

[Mesa-dev] [Bug 105139] Assertion in Dying Light

[bugzilla-daemon]

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

--- Comment #2 from Ilia Mirkin  ---
OK, looks like the literal attach is legal, but then the framebuffer isn't
complete. From OpenGL 4.6:

"""
The framebuffer attachment point attachment is said to be framebuffer
attachment
complete if the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for
attachment is NONE (i.e., no image is attached), or if all of the following
conditions are true:

...

If attachment is COLOR_ATTACHMENTi, then image must have a color-renderable
internal format.
"""

This should be handled in fbobject.c:test_attachment_completeness . Needs more
investigation as to what's going wrong.

-- 
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 105139] Assertion in Dying Light

[bugzilla-daemon]

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

--- Comment #1 from Ilia Mirkin  ---
They're managing to attach a depth texture to a GL_COLOR_ATTACHMENT0? That
shouldn't be possible... but I don't see any logic blocking it in
framebuffer_texture_with_dims.

-- 
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 105139] Assertion in Dying Light

[bugzilla-daemon]

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

Bug ID: 105139
   Summary: Assertion in Dying Light
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: nota...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Dying Light triggers an assertion when switching from fullscreen to windowed
mode:

DyingLightGame: state_tracker/st_atom_framebuffer.c:201:
st_update_framebuffer_state: Assertion `!framebuffer.cbufs[i] ||
framebuffer.cbufs[i]->texture->bind & PIPE_BIND_RENDER_TARGET' failed.

(gdb) p i
$1 = 0
(gdb) p framebuffer.nr_cbufs 
$2 = 1 '\001'
(gdb) p framebuffer.cbufs[i]
$3 = (struct pipe_surface *) 0x1a132450
(gdb) p framebuffer.cbufs[i]->texture->bind
$4 = 9

The assert wants PIPE_BIND_RENDER_TARGET but
PIPE_BIND_DEPTH_STENCIL|PIPE_BIND_SAMPLER_VIEW is set.

-- 
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 v2 1/2] glsl/nir: add pixel_center_integer to shader info

[Kenneth Graunke]

On Thursday, February 15, 2018 9:18:51 PM PST Timothy Arceri wrote:
> ---
>  src/compiler/glsl/glsl_to_nir.cpp | 5 +
>  src/compiler/shader_info.h| 2 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/src/compiler/glsl/glsl_to_nir.cpp 
> b/src/compiler/glsl/glsl_to_nir.cpp
> index 1a579f41cd..7a9d15015e 100644
> --- a/src/compiler/glsl/glsl_to_nir.cpp
> +++ b/src/compiler/glsl/glsl_to_nir.cpp
> @@ -406,6 +406,11 @@ nir_visitor::visit(ir_variable *ir)
> var->data.pixel_center_integer = ir->data.pixel_center_integer;
> var->data.location_frac = ir->data.location_frac;
>  
> +   if (var->data.pixel_center_integer) {
> +  assert(shader->info.stage == MESA_SHADER_FRAGMENT);
> +  shader->info.fs.pixel_center_integer = true;
> +   }
> +
> switch (ir->data.depth_layout) {
> case ir_depth_layout_none:
>var->data.depth_layout = nir_depth_layout_none;
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index 45ef4b5039..11a59ff6ac 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -164,6 +164,8 @@ typedef struct shader_info {
>  
>   bool post_depth_coverage;
>  
> + bool pixel_center_integer;
> +
>   /** gl_FragDepth layout for ARB_conservative_depth. */
>   enum gl_frag_depth_layout depth_layout;
>} fs;
> 

This looks good, thanks Tim!

Series is:
Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v4

[Dylan Baker]

Quoting Alexander von Gluck IV (2018-02-16 12:27:03)
> +  link_with : [libglapi_static, libglapi],
> +  dependencies : cpp.find_library('be'),

I think that we end up calling cpp.find_library('be') it might be worth just
adding this to the top meson.build file as dep_be, but I'm okay doing that as a
follow up.

Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] [Mesa-stable] [PATCH] meson: gallium: add idep_nir dependency where it's used

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 09:19:53)
> From: Emil Velikov 
> 
> Currently there are two type of users of NIR (and hence idep_nir):
>  - gallium/aux - via tgsi_to_nir.c
>  - drivers - freedreno, radeonsi, vc4, vc5
> 
> Of the above, the aux. module and freedreno were missing the idep_nir.
> Adjust as needed and document.
> 
> To catch the fallout, consider the following:
>  - build only drivers that do not use NIR - say nouveau
>  - build target that does not pull libmesa_gallium - since that pulls
> libglsl and thus libnir
>  - disable the linker garbage collector - since it would otherwise
> discard tgsi_to_nir.c
>  - observe the link-time errors, since the NIR references pulled by
> tgsi_to_nir.c are unresolved.
> 
> Cc: 18.0 
> Cc: Dylan Baker 
> Signed-off-by: Emil Velikov 
> ---
> This is a part of a larger WIP, although it also makes sense on its own.
> 
>  src/gallium/auxiliary/meson.build | 2 +-
>  src/gallium/drivers/freedreno/meson.build | 2 ++
>  src/gallium/drivers/radeonsi/meson.build  | 1 +
>  src/gallium/drivers/vc4/meson.build   | 1 +
>  src/gallium/drivers/vc5/meson.build   | 1 +
>  5 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/meson.build 
> b/src/gallium/auxiliary/meson.build
> index 6f1542d7ade..605c260f64d 100644
> --- a/src/gallium/auxiliary/meson.build
> +++ b/src/gallium/auxiliary/meson.build
> @@ -498,7 +498,7 @@ libgallium = static_library(
>cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
>dependencies : [
>  dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m, dep_thread, 
> dep_lmsensors,
> -idep_nir_headers,
> +idep_nir,
>],
>build_by_default : false,
>  )
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index ef70cc08c74..0d8a5908c40 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -231,6 +231,8 @@ libfreedreno = static_library(
>  driver_freedreno = declare_dependency(
>compile_args : '-DGALLIUM_FREEDRENO',
>link_with : [libfreedrenowinsys, libfreedreno],
> +  # NIR dependency is also resolved via libgallium
> +  dependencies : idep_nir,
>  )
>  
>  ir3_compiler = executable(
> diff --git a/src/gallium/drivers/radeonsi/meson.build 
> b/src/gallium/drivers/radeonsi/meson.build
> index 9a62d143088..cb5964256bc 100644
> --- a/src/gallium/drivers/radeonsi/meson.build
> +++ b/src/gallium/drivers/radeonsi/meson.build
> @@ -86,5 +86,6 @@ driver_radeonsi = declare_dependency(
>link_with : [
>  libradeonsi, libradeon, libradeonwinsys, libamdgpuwinsys, libamd_common,
>],
> +  # NIR dependency is also resolved via libgallium
>dependencies : idep_nir,
>  )
> diff --git a/src/gallium/drivers/vc4/meson.build 
> b/src/gallium/drivers/vc4/meson.build
> index ef7e7bcac5c..68f1d7d05e8 100644
> --- a/src/gallium/drivers/vc4/meson.build
> +++ b/src/gallium/drivers/vc4/meson.build
> @@ -116,5 +116,6 @@ libvc4 = static_library(
>  driver_vc4 = declare_dependency(
>compile_args : '-DGALLIUM_VC4',
>link_with : [libvc4, libvc4winsys, libbroadcom_cle],
> +  # NIR dependency is also resolved via libgallium
>dependencies : idep_nir,
>  )
> diff --git a/src/gallium/drivers/vc5/meson.build 
> b/src/gallium/drivers/vc5/meson.build
> index 005bf2f9b8e..3d2b7ad9be9 100644
> --- a/src/gallium/drivers/vc5/meson.build
> +++ b/src/gallium/drivers/vc5/meson.build
> @@ -91,5 +91,6 @@ libvc5 = static_library(
>  driver_vc5 = declare_dependency(
>compile_args : '-DGALLIUM_VC5',
>link_with : [libvc5, libvc5winsys, libbroadcom_cle, libbroadcom_vc5],
> +  # NIR dependency is also resolved via libgallium
>dependencies : idep_nir,
>  )
> -- 
> 2.16.0
> 
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable

Apart from now needing to be rebased (I fixed the freedreno missing idep_nir
already), this is fine as-is. I've kinda been thinking that having and
idep_gallium would be useful for libgallium, and we could add idep_nir as a
dependency there, which would allow us to actually use idep_nir_headers in the
driver, since all of the gallium targets need libgallium and could pull in the
idep_gallium (and thus idep_nir), this would move more of the linking to the
final shared driver, which should produce a smaller final size without lto,
correct?

Dylan


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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 14:07:26)
> On 16 February 2018 at 19:08, Alexander von Gluck IV
>  wrote:
> > February 16, 2018 11:49 AM, "Emil Velikov"  wrote:
> >> Hi Alexander,
> >>
> >> Did you drop the ball on the autotools patches? I could re-spin them
> >> but have no way to test.
> >
> > I've been focused on meson since it's the future.
> > Feel free to re-spin them if you have the bandwidth.
> >
> >> There's a couple of comments inline, but nothing major.
> >>
> >> On 16 February 2018 at 00:32, Alexander von Gluck IV
> >>  wrote:
> >>
> >>> --- a/meson.build
> >>> +++ b/meson.build
> >>>
> >>> gl_priv_libs = []
> >>> -if dep_thread.found()
> >>> +if dep_thread.found() and host_machine.system() != 'haiku'
> >>> gl_priv_libs += ['-lpthread', '-pthread']
> >>> endif
> >>
> >> There's a bug report/fix in Meson for this one right?
> >> Please mention the ticket number of Meson version where the fix
> >> landed. Thus way one can drop this when we bump the Meson requirement.
> >
> > I did a bump of Meson on my Haiku build system and still saw the same
> > incorrect searching for -lpthread issues.  I think there are places where
> > -lpthread -pthread were specified without looking at dep_thread.found()
> > though which could be at play.  (see below)
> >
> Precisely those are existing bugs and should be separate, preparatory patch.
> 
> >>> if dep_m.found()
> >>> diff --git a/src/egl/meson.build b/src/egl/meson.build
> >>> index 6cd04567b0..09c28e9f83 100644
> >>> --- a/src/egl/meson.build
> >>> +++ b/src/egl/meson.build
> >>
> >> There are three unrelated things happening here:
> >>
> >>> @@ -21,9 +21,8 @@
> >>> c_args_for_egl = []
> >>> link_for_egl = []
> >>> deps_for_egl = []
> >>> -incs_for_egl = [
> >>> - inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
> >>> -]
> >>> +incs_for_egl = [inc_include, inc_src, include_directories('main')]
> >>> +
> >>
> >> a) inc_gbm should be moved in the with_platform_drm hunk
> >
> > Can-do.  I wasn't 100% sure on when it was included so didn't want to 
> > disrupt
> > any non-Haiku build conditions.
> >
> It's an existing bug. Please flesh it out as separate commit.
> 
> >>> files_egl = files(
> >>> 'main/eglapi.c',
> >>> 'main/eglapi.h',
> >>> @@ -53,9 +52,6 @@ files_egl = files(
> >>> 'main/eglsync.h',
> >>> 'main/eglentrypoint.h',
> >>> 'main/egltypedefs.h',
> >>> - 'drivers/dri2/egl_dri2.c',
> >>> - 'drivers/dri2/egl_dri2.h',
> >>> - 'drivers/dri2/egl_dri2_fallbacks.h',
> >>> )
> >>>
> >>> linux_dmabuf_unstable_v1_protocol_c = custom_target(
> >>> @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
> >>> capture : true,
> >>> )
> >>>
> >>> +if with_dri2
> >>> + files_egl += files(
> >>> + 'drivers/dri2/egl_dri2.c',
> >>> + 'drivers/dri2/egl_dri2.h',
> >>> + 'drivers/dri2/egl_dri2_fallbacks.h',
> >>> + )
> >>> + incs_for_egl += [inc_loader, inc_gbm]
> >>> + c_args_for_egl += [
> >>> + '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> >>> + '-D_EGL_BUILT_IN_DRIVER_DRI2',
> >>> + ]
> >>> + link_for_egl += [libloader, libxmlconfig]
> >>> + deps_for_egl += dep_libdrm
> >>> +endif
> >>> +
> >>
> >> b) This should be within the with_platform_x11 hunk
> >
> > So with_platform_x11 always means with_dri2 regardless
> > of what with_dri2 is set to?
> >
> Errh, my bad. All of the whole
> with_platforms_{x11,wayland,...everything-but-haiku} should be within
> the with_dri2 block.
> 
> Alike the a) bit above, please keep that preparatory patch.
> 
> >>> if with_platform_x11
> >>> files_egl += files('drivers/dri2/platform_x11.c')
> >>> if with_dri3
> >>> @@ -133,6 +144,15 @@ if with_platform_android
> >>> deps_for_egl += dep_android
> >>> files_egl += files('drivers/dri2/platform_android.c')
> >>> endif
> >>> +if with_platform_haiku
> >>> + incs_for_egl += inc_haikugl
> >>> + c_args_for_egl += [
> >>> + '-D_EGL_BUILT_IN_DRIVER_HAIKU',
> >>> + ]
> >>> + files_egl += files('drivers/haiku/egl_haiku.cpp')
> >>> + link_for_egl += libgl
> >>> + deps_for_egl += cpp.find_library('be')
> >>> +endif
> >>
> >> c) this is the patch introducing haiku support
> >
> > These are all changes needed to properly build.
> >
> >>> --- /dev/null
> >>> +++ b/src/gallium/targets/haiku-softpipe/meson.build
> >>>
> >>> +libswpipe = shared_library(
> >>>
> >>> + dependencies : [
> >>> + driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
> >>> + cpp.find_library('network'), dep_unwind
> >>
> >> Some of these find_library calls are duplicated throughout. It would
> >> be more efficient and robust to have it done once.
> >> Say in the top level meson.build?
> >
> > That can be done.  Focused on functionality before optimizing in this first
> > commit.
> >
> 
> 
> >>> index 8aaf58a623..7a4bcd3329 100644
> >>> --- a/src/hgl/GLDispatcher.h
> >>> +++ b/src/hgl/GLDispatcher.h
> >>> @@ -15,7 +15,7 @@
> >>> #include 
> >>> #include 
> >>>
> >>> -#include "glheader.h"
> >>> +#include 

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 14:21:52)
> On 16 February 2018 at 22:12, Dylan Baker  wrote:
> > Quoting Emil Velikov (2018-02-16 13:55:06)
> >> On 16 February 2018 at 19:28, Dylan Baker  wrote:
> >> > Quoting Alexander von Gluck IV (2018-02-16 11:08:33)
> >> >> February 16, 2018 11:49 AM, "Emil Velikov"  
> >> >> wrote:
> >> >> > Hi Alexander,
> >> >> >
> >> >> > Did you drop the ball on the autotools patches? I could re-spin them
> >> >> > but have no way to test.
> >> >>
> >> >> I've been focused on meson since it's the future.
> >> >> Feel free to re-spin them if you have the bandwidth.
> >> >>
> >> >> > There's a couple of comments inline, but nothing major.
> >> >> >
> >> >> > On 16 February 2018 at 00:32, Alexander von Gluck IV
> >> >> >  wrote:
> >> >> >
> >> >> >> --- a/meson.build
> >> >> >> +++ b/meson.build
> >> >> >>
> >> >> >> gl_priv_libs = []
> >> >> >> -if dep_thread.found()
> >> >> >> +if dep_thread.found() and host_machine.system() != 'haiku'
> >> >> >> gl_priv_libs += ['-lpthread', '-pthread']
> >> >> >> endif
> >> >> >
> >> >> > There's a bug report/fix in Meson for this one right?
> >> >> > Please mention the ticket number of Meson version where the fix
> >> >> > landed. Thus way one can drop this when we bump the Meson requirement.
> >> >>
> >> >> I did a bump of Meson on my Haiku build system and still saw the same
> >> >> incorrect searching for -lpthread issues.  I think there are places 
> >> >> where
> >> >> -lpthread -pthread were specified without looking at dep_thread.found()
> >> >> though which could be at play.  (see below)
> >> >
> >> > dep_pthread.found() returns true on anything that has pthreads, so for 
> >> > us that
> >> > means anything except windows (non-cygwin windows). I think this is the 
> >> > right
> >> > way to handle this, haiku does have pthreads, they're just not a separate
> >> > library. macOS has some weird pthreads stuff too, and this is how we 
> >> > handle
> >> > macOS.
> >> >
> >> Could swear I read your reply somewhere which said that we can as
> >> Meson to provide the correct flags - be that -lpthread or others.
> >> Yet we're doing the completely opposite thing here.
> >>
> >> Did I misunderstand you or ?
> >>
> >> -Emil
> >
> > What I said was that adding `dependency('threads')` to a target, ala
> > mylib = library(
> >   'mylib',
> >   'mylib.c',
> >   dependencies : dependency('threads'),
> > )
> >
> > Will always (as of 0.44 when I fixed Haiku) do the right thing.
> >
> > The problem is that haiku *does* have pthreads, it just doesn't have a 
> > pthreads
> > library. So the dep returns found because there are pthreads, it just 
> > doesn't
> > add any -l, -L, or -I arguments because none are necessary.
> >
> Right. Using -lpthread (notice the L) is kind of wrong and incomplete.
> -pthread is sufficient and the "right thing to do". Modulo the odd
> platform (msvc, maybe suncc and maybe haiku) that wants to use
> something else ;-)
> 
> As you mentioned meson has dependency('threads') - which we can
> transcribe and use in the pkg-config files, right?
> 
> -Emil

One of the guys at redhat or fedora (not sure, maybe both) did some work in 0.45
so that pkg.generate will actually walk up the dependency graph of the libraries
you pass to the pkg.generate(libraries : ) argument, and generate the correct
Requires, Requires.private, and Libs for you. Until we can depend on that though
we'll have to manage the addition of -pthreads and -lpthreads ourselves (it's
-pthreads for cc/cxx and -lpthreads for ld, right, or is just -pthreads for
both? I can never remember which)

Dylan


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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Emil Velikov]

On 16 February 2018 at 22:12, Dylan Baker  wrote:
> Quoting Emil Velikov (2018-02-16 13:55:06)
>> On 16 February 2018 at 19:28, Dylan Baker  wrote:
>> > Quoting Alexander von Gluck IV (2018-02-16 11:08:33)
>> >> February 16, 2018 11:49 AM, "Emil Velikov"  
>> >> wrote:
>> >> > Hi Alexander,
>> >> >
>> >> > Did you drop the ball on the autotools patches? I could re-spin them
>> >> > but have no way to test.
>> >>
>> >> I've been focused on meson since it's the future.
>> >> Feel free to re-spin them if you have the bandwidth.
>> >>
>> >> > There's a couple of comments inline, but nothing major.
>> >> >
>> >> > On 16 February 2018 at 00:32, Alexander von Gluck IV
>> >> >  wrote:
>> >> >
>> >> >> --- a/meson.build
>> >> >> +++ b/meson.build
>> >> >>
>> >> >> gl_priv_libs = []
>> >> >> -if dep_thread.found()
>> >> >> +if dep_thread.found() and host_machine.system() != 'haiku'
>> >> >> gl_priv_libs += ['-lpthread', '-pthread']
>> >> >> endif
>> >> >
>> >> > There's a bug report/fix in Meson for this one right?
>> >> > Please mention the ticket number of Meson version where the fix
>> >> > landed. Thus way one can drop this when we bump the Meson requirement.
>> >>
>> >> I did a bump of Meson on my Haiku build system and still saw the same
>> >> incorrect searching for -lpthread issues.  I think there are places where
>> >> -lpthread -pthread were specified without looking at dep_thread.found()
>> >> though which could be at play.  (see below)
>> >
>> > dep_pthread.found() returns true on anything that has pthreads, so for us 
>> > that
>> > means anything except windows (non-cygwin windows). I think this is the 
>> > right
>> > way to handle this, haiku does have pthreads, they're just not a separate
>> > library. macOS has some weird pthreads stuff too, and this is how we handle
>> > macOS.
>> >
>> Could swear I read your reply somewhere which said that we can as
>> Meson to provide the correct flags - be that -lpthread or others.
>> Yet we're doing the completely opposite thing here.
>>
>> Did I misunderstand you or ?
>>
>> -Emil
>
> What I said was that adding `dependency('threads')` to a target, ala
> mylib = library(
>   'mylib',
>   'mylib.c',
>   dependencies : dependency('threads'),
> )
>
> Will always (as of 0.44 when I fixed Haiku) do the right thing.
>
> The problem is that haiku *does* have pthreads, it just doesn't have a 
> pthreads
> library. So the dep returns found because there are pthreads, it just doesn't
> add any -l, -L, or -I arguments because none are necessary.
>
Right. Using -lpthread (notice the L) is kind of wrong and incomplete.
-pthread is sufficient and the "right thing to do". Modulo the odd
platform (msvc, maybe suncc and maybe haiku) that wants to use
something else ;-)

As you mentioned meson has dependency('threads') - which we can
transcribe and use in the pkg-config files, right?

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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 13:55:06)
> On 16 February 2018 at 19:28, Dylan Baker  wrote:
> > Quoting Alexander von Gluck IV (2018-02-16 11:08:33)
> >> February 16, 2018 11:49 AM, "Emil Velikov"  
> >> wrote:
> >> > Hi Alexander,
> >> >
> >> > Did you drop the ball on the autotools patches? I could re-spin them
> >> > but have no way to test.
> >>
> >> I've been focused on meson since it's the future.
> >> Feel free to re-spin them if you have the bandwidth.
> >>
> >> > There's a couple of comments inline, but nothing major.
> >> >
> >> > On 16 February 2018 at 00:32, Alexander von Gluck IV
> >> >  wrote:
> >> >
> >> >> --- a/meson.build
> >> >> +++ b/meson.build
> >> >>
> >> >> gl_priv_libs = []
> >> >> -if dep_thread.found()
> >> >> +if dep_thread.found() and host_machine.system() != 'haiku'
> >> >> gl_priv_libs += ['-lpthread', '-pthread']
> >> >> endif
> >> >
> >> > There's a bug report/fix in Meson for this one right?
> >> > Please mention the ticket number of Meson version where the fix
> >> > landed. Thus way one can drop this when we bump the Meson requirement.
> >>
> >> I did a bump of Meson on my Haiku build system and still saw the same
> >> incorrect searching for -lpthread issues.  I think there are places where
> >> -lpthread -pthread were specified without looking at dep_thread.found()
> >> though which could be at play.  (see below)
> >
> > dep_pthread.found() returns true on anything that has pthreads, so for us 
> > that
> > means anything except windows (non-cygwin windows). I think this is the 
> > right
> > way to handle this, haiku does have pthreads, they're just not a separate
> > library. macOS has some weird pthreads stuff too, and this is how we handle
> > macOS.
> >
> Could swear I read your reply somewhere which said that we can as
> Meson to provide the correct flags - be that -lpthread or others.
> Yet we're doing the completely opposite thing here.
> 
> Did I misunderstand you or ?
> 
> -Emil

What I said was that adding `dependency('threads')` to a target, ala
mylib = library(
  'mylib',
  'mylib.c',
  dependencies : dependency('threads'),
)

Will always (as of 0.44 when I fixed Haiku) do the right thing.

The problem is that haiku *does* have pthreads, it just doesn't have a pthreads
library. So the dep returns found because there are pthreads, it just doesn't
add any -l, -L, or -I arguments because none are necessary.

Dylan


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

Re: [Mesa-dev] [PATCH] meson: freedreno depends on nir

[Emil Velikov]

On 16 February 2018 at 19:22, Dylan Baker  wrote:
> Quoting Emil Velikov (2018-02-16 10:49:05)
>> On 16 February 2018 at 17:28, Dylan Baker  wrote:
>> > Quoting Emil Velikov (2018-02-16 09:23:01)
>> >> On 16 February 2018 at 17:15, Dylan Baker  wrote:
>> >> > This fixes a race condition in building targets that link in freedreno.
>> >> >
>> >> > cc: Mark Janes 
>> >> > Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
>> >> > Signed-off-by: Dylan Baker 
>> >> > ---
>> >> >  src/gallium/drivers/freedreno/meson.build | 1 +
>> >> >  1 file changed, 1 insertion(+)
>> >> >
>> >> Dang, I have a slightly more complete patch laying around. Let me fish it 
>> >> out.
>> >>
>> >> -Emil
>> >
>> > What's incomplete about this?
>> Quite an elaborate commit (+ message) should have hit your inbox, some
>> 5+ minutes before this question ;-)
>> Can we keep it there?
>>
>> -Emil
>
> I'm not seeing any message from you on mesa-dev or in my inbox, what was the
> title of the message?
>
Hmm it might be because I used your Intel email, sorry :-\

Title: meson: gallium: add idep_nir dependency where it's used
MessageID: 20180216171953.2067-1-emil.l.veli...@gmail.com

https://patchwork.freedesktop.org/patch/205301/

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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Emil Velikov]

On 16 February 2018 at 19:08, Alexander von Gluck IV
 wrote:
> February 16, 2018 11:49 AM, "Emil Velikov"  wrote:
>> Hi Alexander,
>>
>> Did you drop the ball on the autotools patches? I could re-spin them
>> but have no way to test.
>
> I've been focused on meson since it's the future.
> Feel free to re-spin them if you have the bandwidth.
>
>> There's a couple of comments inline, but nothing major.
>>
>> On 16 February 2018 at 00:32, Alexander von Gluck IV
>>  wrote:
>>
>>> --- a/meson.build
>>> +++ b/meson.build
>>>
>>> gl_priv_libs = []
>>> -if dep_thread.found()
>>> +if dep_thread.found() and host_machine.system() != 'haiku'
>>> gl_priv_libs += ['-lpthread', '-pthread']
>>> endif
>>
>> There's a bug report/fix in Meson for this one right?
>> Please mention the ticket number of Meson version where the fix
>> landed. Thus way one can drop this when we bump the Meson requirement.
>
> I did a bump of Meson on my Haiku build system and still saw the same
> incorrect searching for -lpthread issues.  I think there are places where
> -lpthread -pthread were specified without looking at dep_thread.found()
> though which could be at play.  (see below)
>
Precisely those are existing bugs and should be separate, preparatory patch.

>>> if dep_m.found()
>>> diff --git a/src/egl/meson.build b/src/egl/meson.build
>>> index 6cd04567b0..09c28e9f83 100644
>>> --- a/src/egl/meson.build
>>> +++ b/src/egl/meson.build
>>
>> There are three unrelated things happening here:
>>
>>> @@ -21,9 +21,8 @@
>>> c_args_for_egl = []
>>> link_for_egl = []
>>> deps_for_egl = []
>>> -incs_for_egl = [
>>> - inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
>>> -]
>>> +incs_for_egl = [inc_include, inc_src, include_directories('main')]
>>> +
>>
>> a) inc_gbm should be moved in the with_platform_drm hunk
>
> Can-do.  I wasn't 100% sure on when it was included so didn't want to disrupt
> any non-Haiku build conditions.
>
It's an existing bug. Please flesh it out as separate commit.

>>> files_egl = files(
>>> 'main/eglapi.c',
>>> 'main/eglapi.h',
>>> @@ -53,9 +52,6 @@ files_egl = files(
>>> 'main/eglsync.h',
>>> 'main/eglentrypoint.h',
>>> 'main/egltypedefs.h',
>>> - 'drivers/dri2/egl_dri2.c',
>>> - 'drivers/dri2/egl_dri2.h',
>>> - 'drivers/dri2/egl_dri2_fallbacks.h',
>>> )
>>>
>>> linux_dmabuf_unstable_v1_protocol_c = custom_target(
>>> @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
>>> capture : true,
>>> )
>>>
>>> +if with_dri2
>>> + files_egl += files(
>>> + 'drivers/dri2/egl_dri2.c',
>>> + 'drivers/dri2/egl_dri2.h',
>>> + 'drivers/dri2/egl_dri2_fallbacks.h',
>>> + )
>>> + incs_for_egl += [inc_loader, inc_gbm]
>>> + c_args_for_egl += [
>>> + '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
>>> + '-D_EGL_BUILT_IN_DRIVER_DRI2',
>>> + ]
>>> + link_for_egl += [libloader, libxmlconfig]
>>> + deps_for_egl += dep_libdrm
>>> +endif
>>> +
>>
>> b) This should be within the with_platform_x11 hunk
>
> So with_platform_x11 always means with_dri2 regardless
> of what with_dri2 is set to?
>
Errh, my bad. All of the whole
with_platforms_{x11,wayland,...everything-but-haiku} should be within
the with_dri2 block.

Alike the a) bit above, please keep that preparatory patch.

>>> if with_platform_x11
>>> files_egl += files('drivers/dri2/platform_x11.c')
>>> if with_dri3
>>> @@ -133,6 +144,15 @@ if with_platform_android
>>> deps_for_egl += dep_android
>>> files_egl += files('drivers/dri2/platform_android.c')
>>> endif
>>> +if with_platform_haiku
>>> + incs_for_egl += inc_haikugl
>>> + c_args_for_egl += [
>>> + '-D_EGL_BUILT_IN_DRIVER_HAIKU',
>>> + ]
>>> + files_egl += files('drivers/haiku/egl_haiku.cpp')
>>> + link_for_egl += libgl
>>> + deps_for_egl += cpp.find_library('be')
>>> +endif
>>
>> c) this is the patch introducing haiku support
>
> These are all changes needed to properly build.
>
>>> --- /dev/null
>>> +++ b/src/gallium/targets/haiku-softpipe/meson.build
>>>
>>> +libswpipe = shared_library(
>>>
>>> + dependencies : [
>>> + driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
>>> + cpp.find_library('network'), dep_unwind
>>
>> Some of these find_library calls are duplicated throughout. It would
>> be more efficient and robust to have it done once.
>> Say in the top level meson.build?
>
> That can be done.  Focused on functionality before optimizing in this first
> commit.
>


>>> index 8aaf58a623..7a4bcd3329 100644
>>> --- a/src/hgl/GLDispatcher.h
>>> +++ b/src/hgl/GLDispatcher.h
>>> @@ -15,7 +15,7 @@
>>> #include 
>>> #include 
>>>
>>> -#include "glheader.h"
>>> +#include "main/glheader.h"
>>
>> Please keep source changes separate from build system bits.
>
> Can-do. This was a requirement and matches the other dispatchers like glx.
>
>>> diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
>>> index ea14654d2c..38a5747e9a 100644
>>> --- a/src/mapi/es1api/meson.build
>>> +++ b/src/mapi/es1api/meson.build

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Emil Velikov]

On 16 February 2018 at 19:28, Dylan Baker  wrote:
> Quoting Alexander von Gluck IV (2018-02-16 11:08:33)
>> February 16, 2018 11:49 AM, "Emil Velikov"  wrote:
>> > Hi Alexander,
>> >
>> > Did you drop the ball on the autotools patches? I could re-spin them
>> > but have no way to test.
>>
>> I've been focused on meson since it's the future.
>> Feel free to re-spin them if you have the bandwidth.
>>
>> > There's a couple of comments inline, but nothing major.
>> >
>> > On 16 February 2018 at 00:32, Alexander von Gluck IV
>> >  wrote:
>> >
>> >> --- a/meson.build
>> >> +++ b/meson.build
>> >>
>> >> gl_priv_libs = []
>> >> -if dep_thread.found()
>> >> +if dep_thread.found() and host_machine.system() != 'haiku'
>> >> gl_priv_libs += ['-lpthread', '-pthread']
>> >> endif
>> >
>> > There's a bug report/fix in Meson for this one right?
>> > Please mention the ticket number of Meson version where the fix
>> > landed. Thus way one can drop this when we bump the Meson requirement.
>>
>> I did a bump of Meson on my Haiku build system and still saw the same
>> incorrect searching for -lpthread issues.  I think there are places where
>> -lpthread -pthread were specified without looking at dep_thread.found()
>> though which could be at play.  (see below)
>
> dep_pthread.found() returns true on anything that has pthreads, so for us that
> means anything except windows (non-cygwin windows). I think this is the right
> way to handle this, haiku does have pthreads, they're just not a separate
> library. macOS has some weird pthreads stuff too, and this is how we handle
> macOS.
>
Could swear I read your reply somewhere which said that we can as
Meson to provide the correct flags - be that -lpthread or others.
Yet we're doing the completely opposite thing here.

Did I misunderstand you or ?

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

Re: [Mesa-dev] [PATCH] svga: replaced 'unsigned' with proper enum types in shader code

[Charmaine Lee]

Reviewed-by: Charmaine Lee 


From: Brian Paul 
Sent: Friday, February 16, 2018 12:59:28 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Neha Bhende
Subject: [PATCH] svga: replaced 'unsigned' with proper enum types in shader code

---
 src/gallium/drivers/svga/svga_tgsi_vgpu10.c | 33 ++---
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c 
b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
index 4d0834b..6b8337c 100644
--- a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
@@ -2053,11 +2053,15 @@ emit_decl_instruction(struct svga_shader_emitter_v10 
*emit,
  */
 static void
 emit_input_declaration(struct svga_shader_emitter_v10 *emit,
-   VGPU10_OPCODE_TYPE opcodeType, unsigned operandType,
-   unsigned dim, unsigned index, unsigned size,
-   unsigned name, unsigned numComp,
-   unsigned selMode, unsigned usageMask,
-   unsigned interpMode)
+   VGPU10_OPCODE_TYPE opcodeType,
+   VGPU10_OPERAND_TYPE operandType,
+   VGPU10_OPERAND_INDEX_DIMENSION dim,
+   unsigned index, unsigned size,
+   VGPU10_SYSTEM_NAME name,
+   VGPU10_OPERAND_NUM_COMPONENTS numComp,
+   VGPU10_OPERAND_4_COMPONENT_SELECTION_MODE selMode,
+   unsigned usageMask,
+   VGPU10_INTERPOLATION_MODE interpMode)
 {
VGPU10OpcodeToken0 opcode0;
VGPU10OperandToken0 operand0;
@@ -2117,8 +2121,9 @@ emit_input_declaration(struct svga_shader_emitter_v10 
*emit,
  */
 static void
 emit_output_declaration(struct svga_shader_emitter_v10 *emit,
-unsigned type, unsigned index,
-unsigned name, unsigned usageMask)
+VGPU10_OPCODE_TYPE type, unsigned index,
+VGPU10_SYSTEM_NAME name,
+unsigned usageMask)
 {
VGPU10OpcodeToken0 opcode0;
VGPU10OperandToken0 operand0;
@@ -2352,7 +2357,9 @@ emit_input_declarations(struct svga_shader_emitter_v10 
*emit)
  enum tgsi_semantic semantic_name = emit->info.input_semantic_name[i];
  unsigned usage_mask = emit->info.input_usage_mask[i];
  unsigned index = emit->linkage.input_map[i];
- unsigned type, interpolationMode, name;
+ VGPU10_OPCODE_TYPE type;
+ VGPU10_INTERPOLATION_MODE interpolationMode;
+ VGPU10_SYSTEM_NAME name;

  if (usage_mask == 0)
 continue;  /* register is not actually used */
@@ -2412,9 +2419,10 @@ emit_input_declarations(struct svga_shader_emitter_v10 
*emit)
  unsigned usage_mask = emit->info.input_usage_mask[i];
  unsigned index = emit->linkage.input_map[i];
  VGPU10_OPCODE_TYPE opcodeType, operandType;
- unsigned numComp, selMode;
- unsigned name;
- unsigned dim;
+ VGPU10_OPERAND_NUM_COMPONENTS numComp;
+ VGPU10_OPERAND_4_COMPONENT_SELECTION_MODE selMode;
+ VGPU10_SYSTEM_NAME name;
+ VGPU10_OPERAND_INDEX_DIMENSION dim;

  if (usage_mask == 0)
 continue;  /* register is not actually used */
@@ -2548,7 +2556,8 @@ emit_output_declarations(struct svga_shader_emitter_v10 
*emit)
   }
   else {
  /* VS or GS */
- unsigned name, type;
+ VGPU10_COMPONENT_NAME name;
+ VGPU10_OPCODE_TYPE type;
  unsigned writemask = VGPU10_OPERAND_4_COMPONENT_MASK_ALL;

  switch (semantic_name) {
--
2.7.4

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

[Mesa-dev] [Bug 105068] vulkaninfo gives an VK_ERROR_INITIALIZATION_FAILED

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #4 from Bas Nieuwenhuizen  ---
Looks like you need to call grub2-mkconfig with an argument. Looking at the
wiki it should be 

grub2-mkconfig -o /boot/grub2/grub.cfg

(https://fedoraproject.org/wiki/GRUB_2)

Could you try that.

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

[Mesa-dev] [PATCH] intel/gen9+: Enable object level preemption.

[Rafael Antognolli]

"This field controls the granularity of the replay mechanism when
 coming back into a previously preempted context."

The kernel disables this bit but whitelists the register, and it's a
context register. So enable it and take advantage of finer granularity
when preemption is available.

Signed-off-by: Rafael Antognolli 
Cc: Ben Widawsky 
---

This patch still needs more testing (only ran it through CI and also did
some basic tests on my machine to make sure it's not breaking anything).

 src/intel/genxml/gen10.xml   |  8 
 src/intel/genxml/gen11.xml   |  8 
 src/intel/genxml/gen9.xml|  8 
 src/intel/vulkan/genX_state.c| 18 ++
 src/mesa/drivers/dri/i965/brw_defines.h  |  5 +
 src/mesa/drivers/dri/i965/brw_state_upload.c | 10 ++
 6 files changed, 57 insertions(+)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 47c679a3fa9..42ac6e82696 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -3692,6 +3692,14 @@
 
   
 
+  
+
+  
+  
+
+
+  
+
   
 
   
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 9a8a2fe21e3..e6ce42b2bfb 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -3688,6 +3688,14 @@
 
   
 
+  
+
+  
+  
+
+
+  
+
   
 
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 7eef4bee013..45e1fddeb50 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3638,6 +3638,14 @@
 
   
 
+  
+
+  
+  
+
+
+  
+
   
 
   
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index 54fb8634fdc..83b6c6387f3 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -169,6 +169,24 @@ genX(init_device_state)(struct anv_device *device)
gen10_emit_wa_lri_to_cache_mode_zero();
 #endif
 
+#if GEN_GEN >= 9
+   /* A fixed function pipe flush is required before modifying this field */
+   anv_batch_emit(, GENX(PIPE_CONTROL), pipe) {
+  pipe.PipeControlFlushEnable = true;
+   }
+
+   /* enable object level preemption */
+   uint32_t csc1;
+
+   anv_pack_struct(, GENX(CS_CHICKEN1),
+   .ReplayMode = ObjectLevelPreemption,
+   .ReplayModeMask = 1);
+   anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
+  lri.RegisterOffset   = GENX(CS_CHICKEN1_num);
+  lri.DataDWord= csc1;
+   }
+#endif
+
anv_batch_emit(, GENX(MI_BATCH_BUFFER_END), bbe);
 
assert(batch.next <= batch.end);
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 8bf6f68b67c..f0994d3b139 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1661,4 +1661,9 @@ enum brw_pixel_shader_coverage_mask_mode {
 # define GLK_SCEC_BARRIER_MODE_3D_HULL (1 << 7)
 # define GLK_SCEC_BARRIER_MODE_MASKREG_MASK(1 << 7)
 
+#define CS_CHICKEN10x2580 /* Gen9+ */
+# define GEN9_REPLAY_MODE_MIDBUFFER (0 << 0)
+# define GEN9_REPLAY_MODE_MIDOBJECT (1 << 0)
+# define GEN9_REPLAY_MODE_MASK  REG_MASK(1 << 0)
+
 #endif
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
b/src/mesa/drivers/dri/i965/brw_state_upload.c
index 86c12e4d357..a90dc01d87b 100644
--- a/src/mesa/drivers/dri/i965/brw_state_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
@@ -115,6 +115,16 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
   OUT_BATCH(0);
   ADVANCE_BATCH();
}
+
+   if (devinfo->gen >= 9) {
+  /* A fixed function pipe flush is required before modifying this field */
+  brw_emit_pipe_control_flush(brw, PIPE_CONTROL_FLUSH_ENABLE);
+
+  /* enable object level preemption */
+  brw_load_register_imm32(brw, CS_CHICKEN1,
+  GEN9_REPLAY_MODE_MIDOBJECT |
+  GEN9_REPLAY_MODE_MASK);
+   }
 }
 
 static inline const struct brw_tracked_state *
-- 
2.14.3

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

[Mesa-dev] [PATCH] svga: replaced 'unsigned' with proper enum types in shader code

[Brian Paul]

---
 src/gallium/drivers/svga/svga_tgsi_vgpu10.c | 33 ++---
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c 
b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
index 4d0834b..6b8337c 100644
--- a/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
+++ b/src/gallium/drivers/svga/svga_tgsi_vgpu10.c
@@ -2053,11 +2053,15 @@ emit_decl_instruction(struct svga_shader_emitter_v10 
*emit,
  */
 static void
 emit_input_declaration(struct svga_shader_emitter_v10 *emit,
-   VGPU10_OPCODE_TYPE opcodeType, unsigned operandType,
-   unsigned dim, unsigned index, unsigned size,
-   unsigned name, unsigned numComp,
-   unsigned selMode, unsigned usageMask,
-   unsigned interpMode)
+   VGPU10_OPCODE_TYPE opcodeType,
+   VGPU10_OPERAND_TYPE operandType,
+   VGPU10_OPERAND_INDEX_DIMENSION dim,
+   unsigned index, unsigned size,
+   VGPU10_SYSTEM_NAME name,
+   VGPU10_OPERAND_NUM_COMPONENTS numComp,
+   VGPU10_OPERAND_4_COMPONENT_SELECTION_MODE selMode,
+   unsigned usageMask,
+   VGPU10_INTERPOLATION_MODE interpMode)
 {
VGPU10OpcodeToken0 opcode0;
VGPU10OperandToken0 operand0;
@@ -2117,8 +2121,9 @@ emit_input_declaration(struct svga_shader_emitter_v10 
*emit,
  */
 static void
 emit_output_declaration(struct svga_shader_emitter_v10 *emit,
-unsigned type, unsigned index,
-unsigned name, unsigned usageMask)
+VGPU10_OPCODE_TYPE type, unsigned index,
+VGPU10_SYSTEM_NAME name,
+unsigned usageMask)
 {
VGPU10OpcodeToken0 opcode0;
VGPU10OperandToken0 operand0;
@@ -2352,7 +2357,9 @@ emit_input_declarations(struct svga_shader_emitter_v10 
*emit)
  enum tgsi_semantic semantic_name = emit->info.input_semantic_name[i];
  unsigned usage_mask = emit->info.input_usage_mask[i];
  unsigned index = emit->linkage.input_map[i];
- unsigned type, interpolationMode, name;
+ VGPU10_OPCODE_TYPE type;
+ VGPU10_INTERPOLATION_MODE interpolationMode;
+ VGPU10_SYSTEM_NAME name;
 
  if (usage_mask == 0)
 continue;  /* register is not actually used */
@@ -2412,9 +2419,10 @@ emit_input_declarations(struct svga_shader_emitter_v10 
*emit)
  unsigned usage_mask = emit->info.input_usage_mask[i];
  unsigned index = emit->linkage.input_map[i];
  VGPU10_OPCODE_TYPE opcodeType, operandType;
- unsigned numComp, selMode;
- unsigned name;
- unsigned dim;
+ VGPU10_OPERAND_NUM_COMPONENTS numComp;
+ VGPU10_OPERAND_4_COMPONENT_SELECTION_MODE selMode;
+ VGPU10_SYSTEM_NAME name;
+ VGPU10_OPERAND_INDEX_DIMENSION dim;
 
  if (usage_mask == 0)
 continue;  /* register is not actually used */
@@ -2548,7 +2556,8 @@ emit_output_declarations(struct svga_shader_emitter_v10 
*emit)
   }
   else {
  /* VS or GS */
- unsigned name, type;
+ VGPU10_COMPONENT_NAME name;
+ VGPU10_OPCODE_TYPE type;
  unsigned writemask = VGPU10_OPERAND_4_COMPONENT_MASK_ALL;
 
  switch (semantic_name) {
-- 
2.7.4

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

[Mesa-dev] [PATCH] meson: Add Haiku platform support v4

[Alexander von Gluck IV]

---
 include/meson.build|  8 +
 meson.build| 16 +++---
 src/egl/meson.build| 36 +++---
 src/gallium/meson.build|  9 ++
 src/gallium/state_trackers/hgl/meson.build | 41 ++
 src/gallium/targets/haiku-softpipe/meson.build | 40 +
 src/gallium/winsys/sw/hgl/meson.build  | 29 ++
 src/hgl/meson.build| 36 ++
 src/mapi/es1api/meson.build|  2 +-
 src/mapi/es2api/meson.build|  2 +-
 src/meson.build|  7 -
 11 files changed, 209 insertions(+), 17 deletions(-)
 create mode 100644 src/gallium/state_trackers/hgl/meson.build
 create mode 100644 src/gallium/targets/haiku-softpipe/meson.build
 create mode 100644 src/gallium/winsys/sw/hgl/meson.build
 create mode 100644 src/hgl/meson.build

diff --git a/include/meson.build b/include/meson.build
index 1cbc68182c..28ffb33215 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -22,6 +22,7 @@ inc_drm_uapi = include_directories('drm-uapi')
 inc_vulkan = include_directories('vulkan')
 inc_d3d9 = include_directories('D3D9')
 inc_gl_internal = include_directories('GL/internal')
+inc_haikugl = include_directories('HaikuGL')
 
 if with_gles1
   install_headers(
@@ -80,6 +81,13 @@ if with_gallium_st_nine
   )
 endif
 
+if with_platform_haiku
+  install_headers(
+'HaikuGL/GLRenderer.h', 'HaikuGL/GLView.h', 'HaikuGL/OpenGLKit.h',
+subdir : 'opengl',
+  )
+endif
+
 # Only install the headers if we are building a stand alone implementation and
 # not an ICD enabled implementation
 if with_gallium_opencl and not with_opencl_icd
diff --git a/meson.build b/meson.build
index d6ffa30d9e..120042fb24 100644
--- a/meson.build
+++ b/meson.build
@@ -99,7 +99,7 @@ if _drivers == 'auto'
 else
   error('Unknown architecture. Please pass -Ddri-drivers to set driver 
options. Patches gladly accepted to fix this.')
 endif
-  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+  elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
 # only swrast would make sense here, but gallium swrast is a much better 
default
 _drivers = ''
   else
@@ -144,7 +144,7 @@ if _drivers == 'auto'
 else
   error('Unknown architecture. Please pass -Dgallium-drivers to set driver 
options. Patches gladly accepted to fix this.')
 endif
-  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+  elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
 _drivers = 'swrast'
   else
 error('Unknown OS. Please pass -Dgallium-drivers to set driver options. 
Patches gladly accepted to fix this.')
@@ -181,7 +181,7 @@ if _vulkan_drivers == 'auto'
 else
   error('Unknown architecture. Please pass -Dvulkan-drivers to set driver 
options. Patches gladly accepted to fix this.')
 endif
-  elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
+  elif ['darwin', 'windows', 'cygwin', 'haiku'].contains(host_machine.system())
 # No vulkan driver supports windows or macOS currently
 _vulkan_drivers = ''
   else
@@ -242,6 +242,8 @@ if _platforms == 'auto'
 _platforms = 'x11,wayland,drm,surfaceless'
   elif ['darwin', 'windows', 'cygwin'].contains(host_machine.system())
 _platforms = 'x11,surfaceless'
+  elif ['haiku'].contains(host_machine.system())
+_platforms = 'haiku'
   else
 error('Unknown OS. Please pass -Dplatforms to set platforms. Patches 
gladly accepted to fix this.')
   endif
@@ -252,6 +254,7 @@ if _platforms != ''
   with_platform_x11 = _split.contains('x11')
   with_platform_wayland = _split.contains('wayland')
   with_platform_drm = _split.contains('drm')
+  with_platform_haiku = _split.contains('haiku')
   with_platform_surfaceless = _split.contains('surfaceless')
   egl_native_platform = _split[0]
 endif
@@ -260,6 +263,8 @@ with_glx = get_option('glx')
 if with_glx == 'auto'
   if with_dri
 with_glx = 'dri'
+  elif with_platform_haiku
+with_glx = 'disabled'
   elif with_gallium
 # Even when building just gallium drivers the user probably wants dri
 with_glx = 'dri'
@@ -375,7 +380,7 @@ if with_any_vk and (with_platform_x11 and not with_dri3)
   error('Vulkan drivers require dri3 for X11 support')
 endif
 if with_dri or with_gallium
-  if with_glx == 'disabled' and not with_egl
+  if with_glx == 'disabled' and not with_egl and not with_platform_haiku
 error('building dri or gallium drivers require at least one window system')
   endif
 endif
@@ -642,6 +647,9 @@ if with_platform_android
   ]
   pre_args += '-DHAVE_ANDROID_PLATFORM'
 endif
+if with_platform_haiku
+  pre_args += '-DHAVE_HAIKU_PLATFORM'
+endif
 
 prog_python2 = find_program('python2')
 has_mako = run_command(prog_python2, '-c', 

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 10:46:59)
> On 16 February 2018 at 17:58, Dylan Baker  wrote:
> > Emil,
> >
> > If meson is going to work for their needs it seems silly to merge autotools
> > support, when the plan is to drop autotools from mesa in the coming year.
> >
> What's wrong with having it until then? Comparing the two side-by-side
> be that wrt complexity, speed or binaries produced is always
> beneficial.
> 
> -Emil

If you think so.

Dylan


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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Quoting Alexander von Gluck IV (2018-02-16 11:08:33)
> February 16, 2018 11:49 AM, "Emil Velikov"  wrote:
> > Hi Alexander,
> > 
> > Did you drop the ball on the autotools patches? I could re-spin them
> > but have no way to test.
> 
> I've been focused on meson since it's the future.
> Feel free to re-spin them if you have the bandwidth.
> 
> > There's a couple of comments inline, but nothing major.
> > 
> > On 16 February 2018 at 00:32, Alexander von Gluck IV
> >  wrote:
> > 
> >> --- a/meson.build
> >> +++ b/meson.build
> >> 
> >> gl_priv_libs = []
> >> -if dep_thread.found()
> >> +if dep_thread.found() and host_machine.system() != 'haiku'
> >> gl_priv_libs += ['-lpthread', '-pthread']
> >> endif
> > 
> > There's a bug report/fix in Meson for this one right?
> > Please mention the ticket number of Meson version where the fix
> > landed. Thus way one can drop this when we bump the Meson requirement.
> 
> I did a bump of Meson on my Haiku build system and still saw the same
> incorrect searching for -lpthread issues.  I think there are places where
> -lpthread -pthread were specified without looking at dep_thread.found()
> though which could be at play.  (see below)

dep_pthread.found() returns true on anything that has pthreads, so for us that
means anything except windows (non-cygwin windows). I think this is the right
way to handle this, haiku does have pthreads, they're just not a separate
library. macOS has some weird pthreads stuff too, and this is how we handle
macOS.

> 
> >> if dep_m.found()
> >> diff --git a/src/egl/meson.build b/src/egl/meson.build
> >> index 6cd04567b0..09c28e9f83 100644
> >> --- a/src/egl/meson.build
> >> +++ b/src/egl/meson.build
> > 
> > There are three unrelated things happening here:
> > 
> >> @@ -21,9 +21,8 @@
> >> c_args_for_egl = []
> >> link_for_egl = []
> >> deps_for_egl = []
> >> -incs_for_egl = [
> >> - inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
> >> -]
> >> +incs_for_egl = [inc_include, inc_src, include_directories('main')]
> >> +
> > 
> > a) inc_gbm should be moved in the with_platform_drm hunk
> 
> Can-do.  I wasn't 100% sure on when it was included so didn't want to disrupt
> any non-Haiku build conditions.
> 
> >> files_egl = files(
> >> 'main/eglapi.c',
> >> 'main/eglapi.h',
> >> @@ -53,9 +52,6 @@ files_egl = files(
> >> 'main/eglsync.h',
> >> 'main/eglentrypoint.h',
> >> 'main/egltypedefs.h',
> >> - 'drivers/dri2/egl_dri2.c',
> >> - 'drivers/dri2/egl_dri2.h',
> >> - 'drivers/dri2/egl_dri2_fallbacks.h',
> >> )
> >> 
> >> linux_dmabuf_unstable_v1_protocol_c = custom_target(
> >> @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
> >> capture : true,
> >> )
> >> 
> >> +if with_dri2
> >> + files_egl += files(
> >> + 'drivers/dri2/egl_dri2.c',
> >> + 'drivers/dri2/egl_dri2.h',
> >> + 'drivers/dri2/egl_dri2_fallbacks.h',
> >> + )
> >> + incs_for_egl += [inc_loader, inc_gbm]
> >> + c_args_for_egl += [
> >> + '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> >> + '-D_EGL_BUILT_IN_DRIVER_DRI2',
> >> + ]
> >> + link_for_egl += [libloader, libxmlconfig]
> >> + deps_for_egl += dep_libdrm
> >> +endif
> >> +
> > 
> > b) This should be within the with_platform_x11 hunk
> 
> So with_platform_x11 always means with_dri2 regardless
> of what with_dri2 is set to?
> 
> >> if with_platform_x11
> >> files_egl += files('drivers/dri2/platform_x11.c')
> >> if with_dri3
> >> @@ -133,6 +144,15 @@ if with_platform_android
> >> deps_for_egl += dep_android
> >> files_egl += files('drivers/dri2/platform_android.c')
> >> endif
> >> +if with_platform_haiku
> >> + incs_for_egl += inc_haikugl
> >> + c_args_for_egl += [
> >> + '-D_EGL_BUILT_IN_DRIVER_HAIKU',
> >> + ]
> >> + files_egl += files('drivers/haiku/egl_haiku.cpp')
> >> + link_for_egl += libgl
> >> + deps_for_egl += cpp.find_library('be')
> >> +endif
> > 
> > c) this is the patch introducing haiku support
> 
> These are all changes needed to properly build.
>  
> >> --- /dev/null
> >> +++ b/src/gallium/targets/haiku-softpipe/meson.build
> >> 
> >> +libswpipe = shared_library(
> >> 
> >> + dependencies : [
> >> + driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
> >> + cpp.find_library('network'), dep_unwind
> > 
> > Some of these find_library calls are duplicated throughout. It would
> > be more efficient and robust to have it done once.
> > Say in the top level meson.build?
> 
> That can be done.  Focused on functionality before optimizing in this first
> commit.
> 
> >> index 8aaf58a623..7a4bcd3329 100644
> >> --- a/src/hgl/GLDispatcher.h
> >> +++ b/src/hgl/GLDispatcher.h
> >> @@ -15,7 +15,7 @@
> >> #include 
> >> #include 
> >> 
> >> -#include "glheader.h"
> >> +#include "main/glheader.h"
> > 
> > Please keep source changes separate from build system bits.
> 
> Can-do. This was a requirement and matches the other dispatchers like glx.
> 
> >> diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
> >> 

Re: [Mesa-dev] [PATCH] meson: freedreno depends on nir

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 10:49:05)
> On 16 February 2018 at 17:28, Dylan Baker  wrote:
> > Quoting Emil Velikov (2018-02-16 09:23:01)
> >> On 16 February 2018 at 17:15, Dylan Baker  wrote:
> >> > This fixes a race condition in building targets that link in freedreno.
> >> >
> >> > cc: Mark Janes 
> >> > Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
> >> > Signed-off-by: Dylan Baker 
> >> > ---
> >> >  src/gallium/drivers/freedreno/meson.build | 1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> Dang, I have a slightly more complete patch laying around. Let me fish it 
> >> out.
> >>
> >> -Emil
> >
> > What's incomplete about this?
> Quite an elaborate commit (+ message) should have hit your inbox, some
> 5+ minutes before this question ;-)
> Can we keep it there?
> 
> -Emil

I'm not seeing any message from you on mesa-dev or in my inbox, what was the
title of the message?

Dylan


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

Re: [Mesa-dev] [PATCH v3 18/18] anv/cmd_buffer: Avoid unnecessary transitions before fast clears

[Nanley Chery]

On Wed, Feb 14, 2018 at 03:53:19PM -0800, Nanley Chery wrote:
> On Wed, Feb 14, 2018 at 12:16:33PM -0800, Jason Ekstrand wrote:
> > Previously, we would always apply the layout transition at the beginning
> > of the subpass and then do the clear whether fast or slow.  This meant
> > that there were some cases, specifically when the initial layout is
> > VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
> > ambiguate followed immediately by a fast-clear.  This probably isn't
> > terribly expensive, but it is a waste that we can avoid easily enough
> > now that we're doing everything at the same time in begin_subpass.
> > ---
> >  src/intel/vulkan/genX_cmd_buffer.c | 62 
> > +++---
> >  1 file changed, 38 insertions(+), 24 deletions(-)
> > 
> > diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
> > b/src/intel/vulkan/genX_cmd_buffer.c
> > index 7f06441..453aea8 100644
> > --- a/src/intel/vulkan/genX_cmd_buffer.c
> > +++ b/src/intel/vulkan/genX_cmd_buffer.c
> > @@ -3335,6 +3335,12 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> > *cmd_buffer,
> >   target_layout = subpass->attachments[i].layout;
> >}
> >  
> > +  /* Clears are based on the image view for 3D surfaces but transitions
> > +   * are done on an entire miplevel at a time.
> > +   */
> > +  uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
> > +  uint32_t clear_layer_count = fb->layers;
> > +
> >if (image->aspects & VK_IMAGE_ASPECT_ANY_COLOR_BIT_ANV) {
> >   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> >  
> > @@ -3348,30 +3354,8 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> > *cmd_buffer,
> >  layer_count = fb->layers;
> >   }
> >  
> > - transition_color_buffer(cmd_buffer, image, 
> > VK_IMAGE_ASPECT_COLOR_BIT,
> > - iview->planes[0].isl.base_level, 1,
> > - base_layer, layer_count,
> > - att_state->current_layout, target_layout);
> > -  } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
> > - transition_depth_buffer(cmd_buffer, image,
> > - att_state->current_layout, target_layout);
> > - att_state->aux_usage =
> > -anv_layout_to_aux_usage(_buffer->device->info, image,
> > -VK_IMAGE_ASPECT_DEPTH_BIT, 
> > target_layout);
> > -  }
> > -  att_state->current_layout = target_layout;
> > -
> > -  if (att_state->pending_clear_aspects & VK_IMAGE_ASPECT_COLOR_BIT) {
> > - assert(att_state->pending_clear_aspects == 
> > VK_IMAGE_ASPECT_COLOR_BIT);
> > -
> > - /* Multi-planar images are not supported as attachments */
> > - assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
> > - assert(image->n_planes == 1);
> > -
> > - uint32_t base_clear_layer = iview->planes[0].isl.base_array_layer;
> > - uint32_t clear_layer_count = fb->layers;
> > -
> > - if (att_state->fast_clear) {
> > + if ((att_state->pending_clear_aspects & 
> > VK_IMAGE_ASPECT_COLOR_BIT) &&
> > + att_state->fast_clear) {
> >  /* We only support fast-clears on the first layer */
> >  assert(iview->planes[0].isl.base_level == 0);
> >  assert(iview->planes[0].isl.base_array_layer == 0);
> > @@ -3381,6 +3365,13 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
> > *cmd_buffer,
> >  base_clear_layer++;
> >  clear_layer_count--;
> >  
> > +/* Performing a fast clear takes care of all our transition 
> > needs
> > + * for the first slice.  Increment the base layer and layer 
> > count
> > + * so that later transitions don't touch layer 0.
> > + */
> 
> Why not do the same optimization for depth?
> 

I did some performance testing on this patch and couldn't measure any
improvement in the Sascha Willems Vulkan demos. It also decreases the
readability of this function, so I'm no longer seeing this as net win.

I think we should instead do this for the depth case. By doing this
optimization in the depth case I noticed a 10fps increase in at least 3
out of 5 demos.

The diff of the quick hack I did for depth is included below:

--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -3353,8 +3353,18 @@ cmd_buffer_begin_subpass(struct anv_cmd_buffer 
*cmd_buffer,
  base_layer, layer_count,
  att_state->current_layout, target_layout);
   } else if (image->aspects & VK_IMAGE_ASPECT_DEPTH_BIT) {
+
+  if (att_state->fast_clear && (
+  render_area.offset.x == 0 ||
+  render_area.offset.y == 0 ||
+  render_area.extent.width == iview->extent.width ||
+  render_area.extent.height == iview->extent.height)) {
+

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Alexander von Gluck IV]

February 16, 2018 11:49 AM, "Emil Velikov"  wrote:
> Hi Alexander,
> 
> Did you drop the ball on the autotools patches? I could re-spin them
> but have no way to test.

I've been focused on meson since it's the future.
Feel free to re-spin them if you have the bandwidth.

> There's a couple of comments inline, but nothing major.
> 
> On 16 February 2018 at 00:32, Alexander von Gluck IV
>  wrote:
> 
>> --- a/meson.build
>> +++ b/meson.build
>> 
>> gl_priv_libs = []
>> -if dep_thread.found()
>> +if dep_thread.found() and host_machine.system() != 'haiku'
>> gl_priv_libs += ['-lpthread', '-pthread']
>> endif
> 
> There's a bug report/fix in Meson for this one right?
> Please mention the ticket number of Meson version where the fix
> landed. Thus way one can drop this when we bump the Meson requirement.

I did a bump of Meson on my Haiku build system and still saw the same
incorrect searching for -lpthread issues.  I think there are places where
-lpthread -pthread were specified without looking at dep_thread.found()
though which could be at play.  (see below)

>> if dep_m.found()
>> diff --git a/src/egl/meson.build b/src/egl/meson.build
>> index 6cd04567b0..09c28e9f83 100644
>> --- a/src/egl/meson.build
>> +++ b/src/egl/meson.build
> 
> There are three unrelated things happening here:
> 
>> @@ -21,9 +21,8 @@
>> c_args_for_egl = []
>> link_for_egl = []
>> deps_for_egl = []
>> -incs_for_egl = [
>> - inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
>> -]
>> +incs_for_egl = [inc_include, inc_src, include_directories('main')]
>> +
> 
> a) inc_gbm should be moved in the with_platform_drm hunk

Can-do.  I wasn't 100% sure on when it was included so didn't want to disrupt
any non-Haiku build conditions.

>> files_egl = files(
>> 'main/eglapi.c',
>> 'main/eglapi.h',
>> @@ -53,9 +52,6 @@ files_egl = files(
>> 'main/eglsync.h',
>> 'main/eglentrypoint.h',
>> 'main/egltypedefs.h',
>> - 'drivers/dri2/egl_dri2.c',
>> - 'drivers/dri2/egl_dri2.h',
>> - 'drivers/dri2/egl_dri2_fallbacks.h',
>> )
>> 
>> linux_dmabuf_unstable_v1_protocol_c = custom_target(
>> @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
>> capture : true,
>> )
>> 
>> +if with_dri2
>> + files_egl += files(
>> + 'drivers/dri2/egl_dri2.c',
>> + 'drivers/dri2/egl_dri2.h',
>> + 'drivers/dri2/egl_dri2_fallbacks.h',
>> + )
>> + incs_for_egl += [inc_loader, inc_gbm]
>> + c_args_for_egl += [
>> + '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
>> + '-D_EGL_BUILT_IN_DRIVER_DRI2',
>> + ]
>> + link_for_egl += [libloader, libxmlconfig]
>> + deps_for_egl += dep_libdrm
>> +endif
>> +
> 
> b) This should be within the with_platform_x11 hunk

So with_platform_x11 always means with_dri2 regardless
of what with_dri2 is set to?

>> if with_platform_x11
>> files_egl += files('drivers/dri2/platform_x11.c')
>> if with_dri3
>> @@ -133,6 +144,15 @@ if with_platform_android
>> deps_for_egl += dep_android
>> files_egl += files('drivers/dri2/platform_android.c')
>> endif
>> +if with_platform_haiku
>> + incs_for_egl += inc_haikugl
>> + c_args_for_egl += [
>> + '-D_EGL_BUILT_IN_DRIVER_HAIKU',
>> + ]
>> + files_egl += files('drivers/haiku/egl_haiku.cpp')
>> + link_for_egl += libgl
>> + deps_for_egl += cpp.find_library('be')
>> +endif
> 
> c) this is the patch introducing haiku support

These are all changes needed to properly build.
 
>> --- /dev/null
>> +++ b/src/gallium/targets/haiku-softpipe/meson.build
>> 
>> +libswpipe = shared_library(
>> 
>> + dependencies : [
>> + driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
>> + cpp.find_library('network'), dep_unwind
> 
> Some of these find_library calls are duplicated throughout. It would
> be more efficient and robust to have it done once.
> Say in the top level meson.build?

That can be done.  Focused on functionality before optimizing in this first
commit.

>> index 8aaf58a623..7a4bcd3329 100644
>> --- a/src/hgl/GLDispatcher.h
>> +++ b/src/hgl/GLDispatcher.h
>> @@ -15,7 +15,7 @@
>> #include 
>> #include 
>> 
>> -#include "glheader.h"
>> +#include "main/glheader.h"
> 
> Please keep source changes separate from build system bits.

Can-do. This was a requirement and matches the other dispatchers like glx.

>> diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
>> index ea14654d2c..38a5747e9a 100644
>> --- a/src/mapi/es1api/meson.build
>> +++ b/src/mapi/es1api/meson.build
>> 
>> --- a/src/mapi/es2api/meson.build
>> +++ b/src/mapi/es2api/meson.build
>> @@ -48,7 +48,7 @@ pkg.generate(
>> description : 'Mesa OpenGL ES 2.0 library',
>> version : meson.project_version(),
>> libraries : libgles2,
>> - libraries_private : '-lm -ldl -lpthread -pthread',
>> + libraries_private : gl_priv_libs,
>> )
> 
> Unrelated fixes - make that a separate patch.
>

This is actually needed to compile EGL under Haiku since
it is assuming -lpthread and -lm... so related.

>> diff --git a/src/meson.build b/src/meson.build
>> index 

[Mesa-dev] [Bug 105029] simdlib_512_avx512.inl:371:57: error: could not convert ‘_mm512_mask_blend_epi32((__mmask16)(ImmT), a, b)’ from ‘__m512i’ {aka ‘__vector(8) long long int’} to ‘SIMDImpl::SIMD51

[bugzilla-daemon]

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

--- Comment #2 from Emil Velikov  ---
Is there something broken on my end - the fix seems to be missing from the
list. Also we'll need the fix in stable since the offending commit landed in
17.2.0-devel

commit fc4f6c44c479a97b9cad5d08f0d9cd71a8e1e5f8
Author: Tim Rowley 
Date:   Thu Jun 15 15:24:07 2017 -0500

swr/rast: Switch intrinsic usage to SIMDLib

-- 
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] meson: freedreno depends on nir

[Emil Velikov]

On 16 February 2018 at 17:28, Dylan Baker  wrote:
> Quoting Emil Velikov (2018-02-16 09:23:01)
>> On 16 February 2018 at 17:15, Dylan Baker  wrote:
>> > This fixes a race condition in building targets that link in freedreno.
>> >
>> > cc: Mark Janes 
>> > Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
>> > Signed-off-by: Dylan Baker 
>> > ---
>> >  src/gallium/drivers/freedreno/meson.build | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> Dang, I have a slightly more complete patch laying around. Let me fish it 
>> out.
>>
>> -Emil
>
> What's incomplete about this?
Quite an elaborate commit (+ message) should have hit your inbox, some
5+ minutes before this question ;-)
Can we keep it there?

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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Emil Velikov]

On 16 February 2018 at 17:58, Dylan Baker  wrote:
> Emil,
>
> If meson is going to work for their needs it seems silly to merge autotools
> support, when the plan is to drop autotools from mesa in the coming year.
>
What's wrong with having it until then? Comparing the two side-by-side
be that wrt complexity, speed or binaries produced is always
beneficial.

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

Re: [Mesa-dev] [PATCH v2 0/8] The 2nd version for UVD HEVC encode

[Mark Thompson]

On 16/02/18 17:53, James Zhu wrote:
> Hi Mark,
> 
> I couldn't reproduce the issue on my Polaris 11 to run mpv / ffmpeg about 1.5 
> hours.
> 
> one terminal run:
> 
> ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 
> -hwaccel_output_format vaapi -i video/Mr.Right.mp4 -an -c:v hevc_vaapi -bf 0 
> out.mp4
> 
> the other  terminal run:
> 
> mpv --fs --loop --no-audio --vo gpu --gpu-context=x11egl --hwdec=vaapi 
> video/Mr.Right.mp4
> But it has some failure with vaDeriveImage. I am not  sure if this failure 
> matters, the video still can play without any other error,

If it's calling vaDeriveImage() at all that suggests it isn't using the proper 
interop path, and may be falling back to software decode.  This should work in 
recent versions of mpv with git Mesa and libva - maybe have a look at the 
verbose output and see what it's actually doing?

> mpv --fs --loop --no-audio --vo vaapi  --hwdec=vaapi video/Mr.Right.mp4
> 
> No error reported with this command line.

I haven't tried the legacy VAAPI test output, I'll try later to see if that 
also triggers the failure for me.


I don't think that this sort of issue should block the patches in Mesa because 
it looks likely that it is a kernel issue somehow - userspace shouldn't be able 
to nuke the GPU at all.  Still, the feature is essentially unusable for me 
because of this problem, and I imagine it will apply to at least some other 
people with setups which are match mine in some way as yet unknown.

Thanks,

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

[Mesa-dev] [Bug 105132] glxSwapBuffers has no effect

[bugzilla-daemon]

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

--- Comment #3 from Emil Velikov  ---
Grr scratch that - I missed the negation in from of invalidateAvailable :-\

-- 
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 105132] glxSwapBuffers has no effect

[bugzilla-daemon]

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

--- Comment #2 from Emil Velikov  ---
Could swear I pushed something on the topic - commit
c9d449de640f62d83149e64015029b466c44b12c. Which seems to be EGL/x11 :-(

invalidateAvailable is available only for DRI2 1.3+

Having a look at the server side
DRI2Version seems off - it always advertises DRI2 1.2
minor is set based on the driver DRI2InfoRec::version v4, relates to DRI2 1.3

Skimming through a local xorg-video-intel checkout, the only way it advertises
v3 or less, is when built against ancient xserver.

So if built correctly, the issue "should not happen" (tm)

-- 
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] meson: freedreno depends on nir

[Mark Janes]

Acked-by: Mark Janes 

Dylan Baker  writes:

> This fixes a race condition in building targets that link in freedreno.
>
> cc: Mark Janes 
> Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
> Signed-off-by: Dylan Baker 
> ---
>  src/gallium/drivers/freedreno/meson.build | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 8094e141b4b..ba1a21c9e0e 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -230,6 +230,7 @@ libfreedreno = static_library(
>  driver_freedreno = declare_dependency(
>compile_args : '-DGALLIUM_FREEDRENO',
>link_with : [libfreedrenowinsys, libfreedreno],
> +  dependencies : idep_nir,
>  )
>  
>  ir3_compiler = executable(
> -- 
> 2.16.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/10] anv/icl: Don't use DISPATCH_MODE_SIMD4X2

[Anuj Phogat]

On Thu, Feb 15, 2018 at 6:07 PM, Jason Ekstrand  wrote:
> On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat  wrote:
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/genX_pipeline.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/src/intel/vulkan/genX_pipeline.c
>> b/src/intel/vulkan/genX_pipeline.c
>> index 85391c93ca..290d78e608 100644
>> --- a/src/intel/vulkan/genX_pipeline.c
>> +++ b/src/intel/vulkan/genX_pipeline.c
>> @@ -1124,6 +1124,9 @@ emit_3dstate_vs(struct anv_pipeline *pipeline)
>>pipeline->shaders[MESA_SHADER_VERTEX];
>>
>> assert(anv_pipeline_has_stage(pipeline, MESA_SHADER_VERTEX));
>> +#if GEN_GEN >= 11
>> +   assert(vs_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8);
>> +#endif
>>
>> anv_batch_emit(>batch, GENX(3DSTATE_VS), vs) {
>>vs.Enable   = true;
>> @@ -1253,10 +1256,14 @@ emit_3dstate_hs_te_ds(struct anv_pipeline
>> *pipeline,
>>   tes_prog_data->base.base.dispatch_grf_start_reg;
>>
>>  #if GEN_GEN >= 8
>> +#if GEN_GEN < 11
>>ds.DispatchMode =
>>   tes_prog_data->base.dispatch_mode == DISPATCH_MODE_SIMD8 ?
>>  DISPATCH_MODE_SIMD8_SINGLE_PATCH :
>>  DISPATCH_MODE_SIMD4X2;
>> +#else
>
>
> You can just put the assert here.
>
Fixed locally. Thanks.
>>
>> +  ds.DispatchMode = DISPATCH_MODE_SIMD8_SINGLE_PATCH;
>> +#endif
>>
>>ds.UserClipDistanceClipTestEnableBitmask =
>>   tes_prog_data->base.clip_distance_mask;
>> --
>> 2.13.6
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Dylan Baker]

Emil,

If meson is going to work for their needs it seems silly to merge autotools
support, when the plan is to drop autotools from mesa in the coming year.

Dylan

Quoting Emil Velikov (2018-02-16 09:49:37)
> Hi Alexander,
> 
> Did you drop the ball on the autotools patches? I could re-spin them
> but have no way to test.
> 
> There's a couple of comments inline, but nothing major.
> 
> On 16 February 2018 at 00:32, Alexander von Gluck IV
>  wrote:
> 
> 
> > --- a/meson.build
> > +++ b/meson.build
> 
> >  gl_priv_libs = []
> > -if dep_thread.found()
> > +if dep_thread.found() and host_machine.system() != 'haiku'
> >gl_priv_libs += ['-lpthread', '-pthread']
> >  endif
> There's a bug report/fix in Meson for this one right?
> Please mention the ticket number of Meson version where the fix
> landed. Thus way one can drop this when we bump the Meson requirement.
> 
> 
> >  if dep_m.found()
> > diff --git a/src/egl/meson.build b/src/egl/meson.build
> > index 6cd04567b0..09c28e9f83 100644
> > --- a/src/egl/meson.build
> > +++ b/src/egl/meson.build
> There are three unrelated things happening here:
> 
> > @@ -21,9 +21,8 @@
> >  c_args_for_egl = []
> >  link_for_egl = []
> >  deps_for_egl = []
> > -incs_for_egl = [
> > -  inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
> > -]
> > +incs_for_egl = [inc_include, inc_src, include_directories('main')]
> > +
> a) inc_gbm should be moved in the with_platform_drm hunk
> 
> >  files_egl = files(
> >'main/eglapi.c',
> >'main/eglapi.h',
> > @@ -53,9 +52,6 @@ files_egl = files(
> >'main/eglsync.h',
> >'main/eglentrypoint.h',
> >'main/egltypedefs.h',
> > -  'drivers/dri2/egl_dri2.c',
> > -  'drivers/dri2/egl_dri2.h',
> > -  'drivers/dri2/egl_dri2_fallbacks.h',
> >  )
> >
> >  linux_dmabuf_unstable_v1_protocol_c = custom_target(
> > @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
> >capture : true,
> >  )
> >
> > +if with_dri2
> > +  files_egl += files(
> > +'drivers/dri2/egl_dri2.c',
> > +'drivers/dri2/egl_dri2.h',
> > +'drivers/dri2/egl_dri2_fallbacks.h',
> > +  )
> > +  incs_for_egl += [inc_loader, inc_gbm]
> > +  c_args_for_egl += [
> > +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> > +'-D_EGL_BUILT_IN_DRIVER_DRI2',
> > +  ]
> > +  link_for_egl += [libloader, libxmlconfig]
> > +  deps_for_egl += dep_libdrm
> > +endif
> > +
> b) This should be within the with_platform_x11 hunk
> 
> >  if with_platform_x11
> >files_egl += files('drivers/dri2/platform_x11.c')
> >if with_dri3
> > @@ -133,6 +144,15 @@ if with_platform_android
> >deps_for_egl += dep_android
> >files_egl += files('drivers/dri2/platform_android.c')
> >  endif
> > +if with_platform_haiku
> > +  incs_for_egl += inc_haikugl
> > +  c_args_for_egl += [
> > +'-D_EGL_BUILT_IN_DRIVER_HAIKU',
> > +  ]
> > +  files_egl += files('drivers/haiku/egl_haiku.cpp')
> > +  link_for_egl += libgl
> > +  deps_for_egl += cpp.find_library('be')
> > +endif
> >
> c) this is the patch introducing haiku support
> 
> 
> > --- /dev/null
> > +++ b/src/gallium/targets/haiku-softpipe/meson.build
> 
> > +libswpipe = shared_library(
> 
> > +  dependencies : [
> > +driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
> > +cpp.find_library('network'), dep_unwind
> Some of these find_library calls are duplicated throughout. It would
> be more efficient and robust to have it done once.
> Say in the top level meson.build?
> 
> 
> > index 8aaf58a623..7a4bcd3329 100644
> > --- a/src/hgl/GLDispatcher.h
> > +++ b/src/hgl/GLDispatcher.h
> > @@ -15,7 +15,7 @@
> >  #include 
> >  #include 
> >
> > -#include "glheader.h"
> > +#include "main/glheader.h"
> >
> Please keep source changes separate from build system bits.
> 
> 
> > diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
> > index ea14654d2c..38a5747e9a 100644
> > --- a/src/mapi/es1api/meson.build
> > +++ b/src/mapi/es1api/meson.build
> 
> > --- a/src/mapi/es2api/meson.build
> > +++ b/src/mapi/es2api/meson.build
> > @@ -48,7 +48,7 @@ pkg.generate(
> >description : 'Mesa OpenGL ES 2.0 library',
> >version : meson.project_version(),
> >libraries : libgles2,
> > -  libraries_private : '-lm -ldl -lpthread -pthread',
> > +  libraries_private : gl_priv_libs,
> >  )
> >
> Unrelated fixes - make that a separate patch.
> 
> > diff --git a/src/meson.build b/src/meson.build
> > index 730b2ff6e4..4d5637f0aa 100644
> > --- a/src/meson.build
> > +++ b/src/meson.build
> 
> > +if with_glx != 'disabled'
> > +  subdir('glx')
> > +endif
> 
> Another unrelated fix?
> 
> Last but not least, please add a meson.build to the respective
> Makefile.ams' EXTRA_DIST.
> 
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___

Re: [Mesa-dev] [PATCH 00/10] intel/anv: Prepare to add Ice Lake (ICL) support

[Anuj Phogat]

On Thu, Feb 15, 2018 at 6:14 PM, Jason Ekstrand  wrote:
> I made a few fairly trivial comments but it all looks pretty good.
>
> Reviewed-by: Jason Ekstrand 
Thanks for the quick review Jason.

>
> On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat  wrote:
>>
>> This series prepares the driver to enable Ice Lake support
>> in Vulkan driver. It wires up the build infrastructure and
>> make few ICL specific changes suggested by h/w documentation.
>> This is not everything we need to enable Vulkan on Ice Lake.
>
>
> How much is left?
>
Remaining bits are:
Compiler changes to remove line, pln and lrp
Add ICL L3 config
Separate SLM from L3
Add fp64 support
Add ICL device info
Add ICL workarounds

>>
>> Series is also available in my review branch at github.
>> https://github.com/aphogat/mesa.git
>>
>> Anuj Phogat (10):
>>   anv/icl: Add gen11 mocs defines
>>   anv/icl: Add #define genX
>>   anv/icl: Don't set ResetGatewayTimer
>>   anv/icl: Don't use SingleVertexDispatch
>>   anv/icl: Don't use DISPATCH_MODE_SIMD4X2
>>   anv/icl: Generate gen11 entry point functions
>>   anv/icl: Build anv libs for gen11
>>   anv/icl: Use gen11 functions
>>   anv/icl: Enable float blend optimization
>>   anv/icl: Add render target flush after uploading binding table
>>
>>  src/intel/Android.vulkan.mk | 21 +
>>  src/intel/Makefile.sources  |  4 
>>  src/intel/Makefile.vulkan.am|  7 ++-
>>  src/intel/vulkan/anv_blorp.c|  3 +++
>>  src/intel/vulkan/anv_device.c   |  3 +++
>>  src/intel/vulkan/anv_entrypoints_gen.py |  6 +-
>>  src/intel/vulkan/anv_private.h  | 14 ++
>>  src/intel/vulkan/genX_cmd_buffer.c  | 21 +
>>  src/intel/vulkan/genX_pipeline.c| 11 +++
>>  src/intel/vulkan/genX_state.c   |  2 +-
>>  src/intel/vulkan/meson.build|  2 +-
>>  11 files changed, 90 insertions(+), 4 deletions(-)
>>
>> --
>> 2.13.6
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support v3

[Emil Velikov]

Hi Alexander,

Did you drop the ball on the autotools patches? I could re-spin them
but have no way to test.

There's a couple of comments inline, but nothing major.

On 16 February 2018 at 00:32, Alexander von Gluck IV
 wrote:


> --- a/meson.build
> +++ b/meson.build

>  gl_priv_libs = []
> -if dep_thread.found()
> +if dep_thread.found() and host_machine.system() != 'haiku'
>gl_priv_libs += ['-lpthread', '-pthread']
>  endif
There's a bug report/fix in Meson for this one right?
Please mention the ticket number of Meson version where the fix
landed. Thus way one can drop this when we bump the Meson requirement.


>  if dep_m.found()
> diff --git a/src/egl/meson.build b/src/egl/meson.build
> index 6cd04567b0..09c28e9f83 100644
> --- a/src/egl/meson.build
> +++ b/src/egl/meson.build
There are three unrelated things happening here:

> @@ -21,9 +21,8 @@
>  c_args_for_egl = []
>  link_for_egl = []
>  deps_for_egl = []
> -incs_for_egl = [
> -  inc_include, inc_src, inc_loader, inc_gbm, include_directories('main'),
> -]
> +incs_for_egl = [inc_include, inc_src, include_directories('main')]
> +
a) inc_gbm should be moved in the with_platform_drm hunk

>  files_egl = files(
>'main/eglapi.c',
>'main/eglapi.h',
> @@ -53,9 +52,6 @@ files_egl = files(
>'main/eglsync.h',
>'main/eglentrypoint.h',
>'main/egltypedefs.h',
> -  'drivers/dri2/egl_dri2.c',
> -  'drivers/dri2/egl_dri2.h',
> -  'drivers/dri2/egl_dri2_fallbacks.h',
>  )
>
>  linux_dmabuf_unstable_v1_protocol_c = custom_target(
> @@ -100,6 +96,21 @@ g_egldispatchstubs_h = custom_target(
>capture : true,
>  )
>
> +if with_dri2
> +  files_egl += files(
> +'drivers/dri2/egl_dri2.c',
> +'drivers/dri2/egl_dri2.h',
> +'drivers/dri2/egl_dri2_fallbacks.h',
> +  )
> +  incs_for_egl += [inc_loader, inc_gbm]
> +  c_args_for_egl += [
> +'-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path),
> +'-D_EGL_BUILT_IN_DRIVER_DRI2',
> +  ]
> +  link_for_egl += [libloader, libxmlconfig]
> +  deps_for_egl += dep_libdrm
> +endif
> +
b) This should be within the with_platform_x11 hunk

>  if with_platform_x11
>files_egl += files('drivers/dri2/platform_x11.c')
>if with_dri3
> @@ -133,6 +144,15 @@ if with_platform_android
>deps_for_egl += dep_android
>files_egl += files('drivers/dri2/platform_android.c')
>  endif
> +if with_platform_haiku
> +  incs_for_egl += inc_haikugl
> +  c_args_for_egl += [
> +'-D_EGL_BUILT_IN_DRIVER_HAIKU',
> +  ]
> +  files_egl += files('drivers/haiku/egl_haiku.cpp')
> +  link_for_egl += libgl
> +  deps_for_egl += cpp.find_library('be')
> +endif
>
c) this is the patch introducing haiku support


> --- /dev/null
> +++ b/src/gallium/targets/haiku-softpipe/meson.build

> +libswpipe = shared_library(

> +  dependencies : [
> +driver_swrast, cpp.find_library('be'), cpp.find_library('translation'),
> +cpp.find_library('network'), dep_unwind
Some of these find_library calls are duplicated throughout. It would
be more efficient and robust to have it done once.
Say in the top level meson.build?


> index 8aaf58a623..7a4bcd3329 100644
> --- a/src/hgl/GLDispatcher.h
> +++ b/src/hgl/GLDispatcher.h
> @@ -15,7 +15,7 @@
>  #include 
>  #include 
>
> -#include "glheader.h"
> +#include "main/glheader.h"
>
Please keep source changes separate from build system bits.


> diff --git a/src/mapi/es1api/meson.build b/src/mapi/es1api/meson.build
> index ea14654d2c..38a5747e9a 100644
> --- a/src/mapi/es1api/meson.build
> +++ b/src/mapi/es1api/meson.build

> --- a/src/mapi/es2api/meson.build
> +++ b/src/mapi/es2api/meson.build
> @@ -48,7 +48,7 @@ pkg.generate(
>description : 'Mesa OpenGL ES 2.0 library',
>version : meson.project_version(),
>libraries : libgles2,
> -  libraries_private : '-lm -ldl -lpthread -pthread',
> +  libraries_private : gl_priv_libs,
>  )
>
Unrelated fixes - make that a separate patch.

> diff --git a/src/meson.build b/src/meson.build
> index 730b2ff6e4..4d5637f0aa 100644
> --- a/src/meson.build
> +++ b/src/meson.build

> +if with_glx != 'disabled'
> +  subdir('glx')
> +endif

Another unrelated fix?

Last but not least, please add a meson.build to the respective
Makefile.ams' EXTRA_DIST.

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

Re: [Mesa-dev] [PATCH 09/10] anv/icl: Enable float blend optimization

[Jason Ekstrand]

On Fri, Feb 16, 2018 at 9:44 AM, Anuj Phogat  wrote:

> On Thu, Feb 15, 2018 at 6:13 PM, Jason Ekstrand 
> wrote:
> > On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat 
> wrote:
> >>
> >> Signed-off-by: Anuj Phogat 
> >> ---
> >>  src/intel/vulkan/genX_state.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/intel/vulkan/genX_state.c
> b/src/intel/vulkan/genX_state.c
> >> index 54fb8634fd..f39508034f 100644
> >> --- a/src/intel/vulkan/genX_state.c
> >> +++ b/src/intel/vulkan/genX_state.c
> >> @@ -121,7 +121,7 @@ genX(init_device_state)(struct anv_device *device)
> >> }
> >>  #endif
> >>
> >> -#if GEN_GEN == 10
> >> +#if GEN_GEN == 10 || GEN_GEN == 11
> >
> >
> > Might as well make this GEN_GEN >= 10
> >
> I can see this bit going away in future generation. So, let's keep
> the check unchanged.
>

That's fine, I guess.


> >>
> >> uint32_t cache_mode_ss;
> >> anv_pack_struct(_mode_ss, GENX(CACHE_MODE_SS),
> >> .FloatBlendOptimizationEnable = true,
> >> --
> >> 2.13.6
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/10] anv/icl: Add render target flush after uploading binding table

[Anuj Phogat]

On Thu, Feb 15, 2018 at 6:12 PM, Jason Ekstrand  wrote:
>
>
> On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat  wrote:
>>
>> The PIPE_CONTROL command description says:
>>
>> "Whenever a Binding Table Index (BTI) used by a Render Taget Message
>> points to a different RENDER_SURFACE_STATE, SW must issue a Render
>> Target Cache Flush by enabling this bit. When render target flush
>> is set due to new association of BTI, PS Scoreboard Stall bit must
>> be set in this packet."
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/genX_cmd_buffer.c | 21 +
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/src/intel/vulkan/genX_cmd_buffer.c
>> b/src/intel/vulkan/genX_cmd_buffer.c
>> index ce47b8a1cc..e2b6c281e4 100644
>> --- a/src/intel/vulkan/genX_cmd_buffer.c
>> +++ b/src/intel/vulkan/genX_cmd_buffer.c
>> @@ -2001,6 +2001,27 @@ emit_binding_table(struct anv_cmd_buffer
>> *cmd_buffer,
>>   out:
>> anv_state_flush(cmd_buffer->device, *bt_state);
>>
>> +#if GEN_GEN >= 11
>> +   /* The PIPE_CONTROL command description says:
>> +*
>> +* "Whenever a Binding Table Index (BTI) used by a Render Taget
>> Message
>> +*  points to a different RENDER_SURFACE_STATE, SW must issue a Render
>> +*  Target Cache Flush by enabling this bit. When render target flush
>> +*  is set due to new association of BTI, PS Scoreboard Stall bit must
>> +*  be set in this packet."
>
>
> We usually indent block quotes like this.
>
Fixed locally.
>>
>> +*
>> +*  FINISHME: Currently we shuffle around the surface states in the
>> +*  binding table based on if they are getting used or not. So, we've
>> +*  to do below pipe control flush for every binding table upload.
>> +*  Make changes so that we do it only when we modify render target
>> +*  surface states.
>> +*/
>> +   anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
>> +  pc.RenderTargetCacheFlushEnable  = true;
>> +  pc.StallAtPixelScoreboard= true;
>> +   }
>> +#endif
>> +
>> return VK_SUCCESS;
>>  }
>>
>> --
>> 2.13.6
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/10] anv/icl: Enable float blend optimization

[Anuj Phogat]

On Thu, Feb 15, 2018 at 6:13 PM, Jason Ekstrand  wrote:
> On Thu, Feb 15, 2018 at 5:44 PM, Anuj Phogat  wrote:
>>
>> Signed-off-by: Anuj Phogat 
>> ---
>>  src/intel/vulkan/genX_state.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
>> index 54fb8634fd..f39508034f 100644
>> --- a/src/intel/vulkan/genX_state.c
>> +++ b/src/intel/vulkan/genX_state.c
>> @@ -121,7 +121,7 @@ genX(init_device_state)(struct anv_device *device)
>> }
>>  #endif
>>
>> -#if GEN_GEN == 10
>> +#if GEN_GEN == 10 || GEN_GEN == 11
>
>
> Might as well make this GEN_GEN >= 10
>
I can see this bit going away in future generation. So, let's keep
the check unchanged.

>>
>> uint32_t cache_mode_ss;
>> anv_pack_struct(_mode_ss, GENX(CACHE_MODE_SS),
>> .FloatBlendOptimizationEnable = true,
>> --
>> 2.13.6
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105132] glxSwapBuffers has no effect

[bugzilla-daemon]

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

Scott D Phillips  changed:

   What|Removed |Added

 CC||scott.d.phill...@intel.com

--- Comment #1 from Scott D Phillips  ---
It looks like the Xext hooks used by the dri2 code never get called by Xlib
when xcb owns the event queue. I think we can either disable
invalidateAvailable if xcb owns the event queue (I don't see how to query
that), or maybe change the dri2 code to use xcb-dri2.

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

[Mesa-dev] [PATCH] anv: Add WSI support for the I915_FORMAT_MOD_Y_TILED_CCS

[Jason Ekstrand]

---
 src/intel/vulkan/anv_formats.c |  9 +++
 src/intel/vulkan/anv_image.c   | 53 ++
 2 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 9c52ad5..3c17366 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -671,9 +671,18 @@ get_wsi_format_modifier_properties_list(const struct 
anv_physical_device *physic
   DRM_FORMAT_MOD_LINEAR,
   I915_FORMAT_MOD_X_TILED,
   I915_FORMAT_MOD_Y_TILED,
+  I915_FORMAT_MOD_Y_TILED_CCS,
};
 
for (uint32_t i = 0; i < ARRAY_SIZE(modifiers); i++) {
+  const struct isl_drm_modifier_info *mod_info =
+ isl_drm_modifier_get_info(modifiers[i]);
+
+  if (mod_info->aux_usage == ISL_AUX_USAGE_CCS_E &&
+  !isl_format_supports_ccs_e(_device->info,
+ anv_format->planes[0].isl_format))
+ continue;
+
   vk_outarray_append(, mod_props) {
  mod_props->modifier = modifiers[i];
  if (isl_drm_modifier_has_aux(modifiers[i]))
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index a2bae7b..d7c2e55 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -515,6 +515,7 @@ score_drm_format_mod(uint64_t modifier)
case DRM_FORMAT_MOD_LINEAR: return 1;
case I915_FORMAT_MOD_X_TILED: return 2;
case I915_FORMAT_MOD_Y_TILED: return 3;
+   case I915_FORMAT_MOD_Y_TILED_CCS: return 4;
default: unreachable("bad DRM format modifier");
}
 }
@@ -746,8 +747,13 @@ void anv_GetImageSubresourceLayout(
 VkSubresourceLayout*layout)
 {
ANV_FROM_HANDLE(anv_image, image, _image);
-   const struct anv_surface *surface =
-  get_surface(image, subresource->aspectMask);
+
+   const struct anv_surface *surface;
+   if (subresource->aspectMask == VK_IMAGE_ASPECT_PLANE_1_BIT_KHR &&
+   isl_drm_modifier_has_aux(image->drm_format_mod))
+  surface = >planes[0].aux_surface;
+   else
+  surface = get_surface(image, subresource->aspectMask);
 
assert(__builtin_popcount(subresource->aspectMask) == 1);
 
@@ -862,25 +868,20 @@ anv_layout_to_aux_usage(const struct gen_device_info * 
const devinfo,
   }
 
 
-   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
+   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR: {
   assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
 
-  /* On SKL+, the render buffer can be decompressed by the presentation
-   * engine. Support for this feature has not yet landed in the wider
-   * ecosystem. TODO: Update this code when support lands.
-   *
-   * From the BDW PRM, Vol 7, Render Target Resolve:
-   *
-   *If the MCS is enabled on a non-multisampled render target, the
-   *render target must be resolved before being used for other
-   *purposes (display, texture, CPU lock) The clear value from
-   *SURFACE_STATE is written into pixels in the render target
-   *indicated as clear in the MCS.
-   *
-   * Pre-SKL, the render buffer must be resolved before being used for
-   * presentation. We can infer that the auxiliary buffer is not used.
+  /* When handing the image off to the presentation engine, we need to
+   * ensure that things are properly resolved.  For images with no
+   * modifier, we assume that they follow the old rules and always need
+   * a full resolve because the PE doesn't understand any form of
+   * compression.  For images with modifiers, we use the aux usage from
+   * the modifier.
*/
-  return ISL_AUX_USAGE_NONE;
+  const struct isl_drm_modifier_info *mod_info =
+ isl_drm_modifier_get_info(image->drm_format_mod);
+  return mod_info ? mod_info->aux_usage : ISL_AUX_USAGE_NONE;
+   }
 
 
/* Rendering Layouts */
@@ -960,8 +961,20 @@ anv_layout_to_fast_clear_type(const struct gen_device_info 
* const devinfo,
case VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL:
   return ANV_FAST_CLEAR_ANY;
 
-   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR:
-  return ANV_FAST_CLEAR_NONE;
+   case VK_IMAGE_LAYOUT_PRESENT_SRC_KHR: {
+  assert(image->aspects == VK_IMAGE_ASPECT_COLOR_BIT);
+
+  /* When handing the image off to the presentation engine, we need to
+   * ensure that things are properly resolved.  For images with no
+   * modifier, we assume that they follow the old rules and always need
+   * a full resolve because the PE doesn't understand any form of
+   * compression.  For images with modifiers, we use the value from the
+   * modifier.
+   */
+  const struct isl_drm_modifier_info *mod_info =
+ isl_drm_modifier_get_info(image->drm_format_mod);
+  return mod_info && mod_info->supports_clear_color;
+   }
 
default:
   /* If the image has CCS_E enabled all the time then we can use
-- 
2.5.0.400.gff86faf

Re: [Mesa-dev] [PATCH] meson: freedreno depends on nir

[Dylan Baker]

Quoting Emil Velikov (2018-02-16 09:23:01)
> On 16 February 2018 at 17:15, Dylan Baker  wrote:
> > This fixes a race condition in building targets that link in freedreno.
> >
> > cc: Mark Janes 
> > Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
> > Signed-off-by: Dylan Baker 
> > ---
> >  src/gallium/drivers/freedreno/meson.build | 1 +
> >  1 file changed, 1 insertion(+)
> >
> Dang, I have a slightly more complete patch laying around. Let me fish it out.
> 
> -Emil

What's incomplete about this?


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

[Mesa-dev] [PATCH] meson: gallium: add idep_nir dependency where it's used

[Emil Velikov]

From: Emil Velikov 

Currently there are two type of users of NIR (and hence idep_nir):
 - gallium/aux - via tgsi_to_nir.c
 - drivers - freedreno, radeonsi, vc4, vc5

Of the above, the aux. module and freedreno were missing the idep_nir.
Adjust as needed and document.

To catch the fallout, consider the following:
 - build only drivers that do not use NIR - say nouveau
 - build target that does not pull libmesa_gallium - since that pulls
libglsl and thus libnir
 - disable the linker garbage collector - since it would otherwise
discard tgsi_to_nir.c
 - observe the link-time errors, since the NIR references pulled by
tgsi_to_nir.c are unresolved.

Cc: 18.0 
Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
This is a part of a larger WIP, although it also makes sense on its own.

 src/gallium/auxiliary/meson.build | 2 +-
 src/gallium/drivers/freedreno/meson.build | 2 ++
 src/gallium/drivers/radeonsi/meson.build  | 1 +
 src/gallium/drivers/vc4/meson.build   | 1 +
 src/gallium/drivers/vc5/meson.build   | 1 +
 5 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 6f1542d7ade..605c260f64d 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -498,7 +498,7 @@ libgallium = static_library(
   cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
   dependencies : [
 dep_libdrm, dep_llvm, dep_unwind, dep_dl, dep_m, dep_thread, dep_lmsensors,
-idep_nir_headers,
+idep_nir,
   ],
   build_by_default : false,
 )
diff --git a/src/gallium/drivers/freedreno/meson.build 
b/src/gallium/drivers/freedreno/meson.build
index ef70cc08c74..0d8a5908c40 100644
--- a/src/gallium/drivers/freedreno/meson.build
+++ b/src/gallium/drivers/freedreno/meson.build
@@ -231,6 +231,8 @@ libfreedreno = static_library(
 driver_freedreno = declare_dependency(
   compile_args : '-DGALLIUM_FREEDRENO',
   link_with : [libfreedrenowinsys, libfreedreno],
+  # NIR dependency is also resolved via libgallium
+  dependencies : idep_nir,
 )
 
 ir3_compiler = executable(
diff --git a/src/gallium/drivers/radeonsi/meson.build 
b/src/gallium/drivers/radeonsi/meson.build
index 9a62d143088..cb5964256bc 100644
--- a/src/gallium/drivers/radeonsi/meson.build
+++ b/src/gallium/drivers/radeonsi/meson.build
@@ -86,5 +86,6 @@ driver_radeonsi = declare_dependency(
   link_with : [
 libradeonsi, libradeon, libradeonwinsys, libamdgpuwinsys, libamd_common,
   ],
+  # NIR dependency is also resolved via libgallium
   dependencies : idep_nir,
 )
diff --git a/src/gallium/drivers/vc4/meson.build 
b/src/gallium/drivers/vc4/meson.build
index ef7e7bcac5c..68f1d7d05e8 100644
--- a/src/gallium/drivers/vc4/meson.build
+++ b/src/gallium/drivers/vc4/meson.build
@@ -116,5 +116,6 @@ libvc4 = static_library(
 driver_vc4 = declare_dependency(
   compile_args : '-DGALLIUM_VC4',
   link_with : [libvc4, libvc4winsys, libbroadcom_cle],
+  # NIR dependency is also resolved via libgallium
   dependencies : idep_nir,
 )
diff --git a/src/gallium/drivers/vc5/meson.build 
b/src/gallium/drivers/vc5/meson.build
index 005bf2f9b8e..3d2b7ad9be9 100644
--- a/src/gallium/drivers/vc5/meson.build
+++ b/src/gallium/drivers/vc5/meson.build
@@ -91,5 +91,6 @@ libvc5 = static_library(
 driver_vc5 = declare_dependency(
   compile_args : '-DGALLIUM_VC5',
   link_with : [libvc5, libvc5winsys, libbroadcom_cle, libbroadcom_vc5],
+  # NIR dependency is also resolved via libgallium
   dependencies : idep_nir,
 )
-- 
2.16.0

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

Re: [Mesa-dev] [PATCH] meson: freedreno depends on nir

[Emil Velikov]

On 16 February 2018 at 17:15, Dylan Baker  wrote:
> This fixes a race condition in building targets that link in freedreno.
>
> cc: Mark Janes 
> Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
> Signed-off-by: Dylan Baker 
> ---
>  src/gallium/drivers/freedreno/meson.build | 1 +
>  1 file changed, 1 insertion(+)
>
Dang, I have a slightly more complete patch laying around. Let me fish it out.

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

Re: [Mesa-dev] [PATCH] meson: Add Haiku platform support

[Dylan Baker]

Quoting Alexander von Gluck IV (2018-02-15 16:58:35)
> February 15, 2018 6:36 PM, "Dylan Baker"  wrote:
> 
> > Quoting Alexander von Gluck IV (2018-02-15 16:04:37)
> > 
> >> I'm actually not 100% sure here. I have missing symbols at link without 
> >> both
> >> included. More investigation needed on my part.
> > 
> > That may be my fault, on Linux and the BSDs have have to have shared_glapi
> > because you need it to do GLES, but if you're not doing GLES you should set
> > shared-glapi to false and then it should work. If you don't get it figured 
> > out
> > I'm looking at Windows (non-cygwin) right now, and that requires non-shared
> > glapi, so if I run into problems there I'll be sure to ping you :)
> 
> Thanks!
> 
> Are things in a good enough state for a "Reviewed-by"?
> 
> There's more work to be done, but this gets the initial (and furthest 
> reaching)
> work done.
> 
>  -- Alex

Yes, you can add:
Reviewed-by: Dylan Baker 

I ran this through our CI to make sure it wouldn't break the Linux build, but I
forgot to mention that :/


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

Re: [Mesa-dev] [PATCH v2] i965: Fix aux-surface size check

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

We'll get it right one of these days!

On Fri, Feb 16, 2018 at 2:52 AM, Daniel Stone  wrote:

> The previous commit reworked the checks intel_from_planar() to check the
> right individual cases for regular/planar/aux buffers, and do size
> checks in all cases.
>
> Unfortunately, the aux size check was broken, and required the aux
> surface to be allocated with the correct aux stride, but full image
> height (!).
>
> As the ISL aux surface is not recorded in the DRIimage, we cannot easily
> access it to check. Instead, store the aux size from when we do have the
> ISL surface to hand, and check against that later when we go to access
> the aux surface.
>
> Signed-off-by: Daniel Stone 
> Fixes: c2c4e5bae3ba ("i965: Fix bugs in intel_from_planar")
> Cc: Jason Ekstrand 
> ---
>  src/mesa/drivers/dri/i965/intel_image.h  |  3 +++
>  src/mesa/drivers/dri/i965/intel_screen.c | 12 +---
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_image.h
> b/src/mesa/drivers/dri/i965/intel_image.h
> index 78d689a11a3..a8193c6def9 100644
> --- a/src/mesa/drivers/dri/i965/intel_image.h
> +++ b/src/mesa/drivers/dri/i965/intel_image.h
> @@ -98,6 +98,9 @@ struct __DRIimageRec {
> /** Pitch of the auxiliary compression surface. */
> uint32_t aux_pitch;
>
> +   /** Total size in bytes of the auxiliary compression surface. */
> +   uint32_t aux_size;
> +
> /**
>  * Provided by EGL_EXT_image_dma_buf_import.
>  * \{
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index cc9b3486743..768634d92e0 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -750,6 +750,7 @@ intel_create_image_common(__DRIscreen *dri_screen,
> if (aux_surf.size) {
>image->aux_offset = surf.size;
>image->aux_pitch = aux_surf.row_pitch;
> +  image->aux_size = aux_surf.size;
> }
>
> return image;
> @@ -1137,6 +1138,8 @@ intel_create_image_from_fds_common(__DRIscreen
> *dri_screen,
>   return NULL;
>}
>
> +  image->aux_size = aux_surf.size;
> +
>const int end = image->aux_offset + aux_surf.size;
>if (size < end)
>   size = end;
> @@ -1312,7 +1315,7 @@ intel_query_dma_buf_modifiers(__DRIscreen *_screen,
> int fourcc, int max,
>  static __DRIimage *
>  intel_from_planar(__DRIimage *parent, int plane, void *loaderPrivate)
>  {
> -int width, height, offset, stride, dri_format;
> +int width, height, offset, stride, size, dri_format;
>  __DRIimage *image;
>
>  if (parent == NULL)
> @@ -1331,24 +1334,27 @@ intel_from_planar(__DRIimage *parent, int plane,
> void *loaderPrivate)
> int index = f->planes[plane].buffer_index;
> offset = parent->offsets[index];
> stride = parent->strides[index];
> +   size = height * stride;
>  } else if (plane == 0) {
> /* The only plane of a non-planar image: copy the parent definition
>  * directly. */
> dri_format = parent->dri_format;
> offset = parent->offset;
> stride = parent->pitch;
> +   size = height * stride;
>  } else if (plane == 1 && parent->modifier != DRM_FORMAT_MOD_INVALID &&
> isl_drm_modifier_has_aux(parent->modifier)) {
> /* Auxiliary plane */
> dri_format = parent->dri_format;
> offset = parent->aux_offset;
> stride = parent->aux_pitch;
> +   size = parent->aux_size;
>  } else {
> return NULL;
>  }
>
> -if (offset + height * stride > parent->bo->size) {
> -   _mesa_warning(NULL, "intel_create_sub_image: subimage out of
> bounds");
> +if (offset + size > parent->bo->size) {
> +   _mesa_warning(NULL, "intel_from_planar: subimage out of bounds");
> return NULL;
>  }
>
> --
> 2.14.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: freedreno depends on nir

[Dylan Baker]

This fixes a race condition in building targets that link in freedreno.

cc: Mark Janes 
Fixes: 0bbecc5a8548883f76a7 ("meson: define driver dependencies")
Signed-off-by: Dylan Baker 
---
 src/gallium/drivers/freedreno/meson.build | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/freedreno/meson.build 
b/src/gallium/drivers/freedreno/meson.build
index 8094e141b4b..ba1a21c9e0e 100644
--- a/src/gallium/drivers/freedreno/meson.build
+++ b/src/gallium/drivers/freedreno/meson.build
@@ -230,6 +230,7 @@ libfreedreno = static_library(
 driver_freedreno = declare_dependency(
   compile_args : '-DGALLIUM_FREEDRENO',
   link_with : [libfreedrenowinsys, libfreedreno],
+  dependencies : idep_nir,
 )
 
 ir3_compiler = executable(
-- 
2.16.1

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

[Mesa-dev] [Bug 105029] simdlib_512_avx512.inl:371:57: error: could not convert ‘_mm512_mask_blend_epi32((__mmask16)(ImmT), a, b)’ from ‘__m512i’ {aka ‘__vector(8) long long int’} to ‘SIMDImpl::SIMD51

[bugzilla-daemon]

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

George Kyriazis  changed:

   What|Removed |Added

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

--- Comment #1 from George Kyriazis  ---
resolved with f1fbeb1a53

-- 
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 v6 7/7] radeonsi: enable uvd encode for HEVC main

[James Zhu]

Enable UVD encode for HEVC main profile

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/drivers/radeonsi/si_get.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index ef03a96..a7cdcda 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -24,6 +24,7 @@
 #include "si_pipe.h"
 #include "radeon/radeon_video.h"
 #include "radeon/radeon_vce.h"
+#include "radeon/radeon_uvd_enc.h"
 #include "ac_llvm_util.h"
 #include "vl/vl_decoder.h"
 #include "vl/vl_video_buffer.h"
@@ -579,7 +580,8 @@ static int si_get_video_param(struct pipe_screen *screen,
(si_vce_is_fw_version_supported(sscreen) ||
sscreen->info.family == CHIP_RAVEN)) ||
(profile == PIPE_VIDEO_PROFILE_HEVC_MAIN &&
-   sscreen->info.family == CHIP_RAVEN);
+   (sscreen->info.family == CHIP_RAVEN ||
+   si_radeon_uvd_enc_supported(sscreen)));
case PIPE_VIDEO_CAP_NPOT_TEXTURES:
return 1;
case PIPE_VIDEO_CAP_MAX_WIDTH:
-- 
2.7.4

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

[Mesa-dev] [PATCH v6 4/7] radeon/uvd:add uvd hevc enc hw ib implementation

[James Zhu]

Implement required IBs for UVD HEVC encode.

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/Makefile.sources |1 +
 src/gallium/drivers/radeon/meson.build  |1 +
 src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1132 +++
 3 files changed, 1134 insertions(+)
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c

diff --git a/src/gallium/drivers/radeon/Makefile.sources 
b/src/gallium/drivers/radeon/Makefile.sources
index 5445625..061d1e1 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -15,6 +15,7 @@ C_SOURCES := \
radeon_vcn_enc_1_2.c \
radeon_vcn_enc.c \
radeon_vcn_enc.h \
+   radeon_uvd_enc_1_1.c \
radeon_uvd_enc.h \
radeon_vce_40_2_2.c \
radeon_vce_50.c \
diff --git a/src/gallium/drivers/radeon/meson.build 
b/src/gallium/drivers/radeon/meson.build
index f587f17..1bc5e83 100644
--- a/src/gallium/drivers/radeon/meson.build
+++ b/src/gallium/drivers/radeon/meson.build
@@ -35,6 +35,7 @@ files_libradeon = files(
   'radeon_vcn_enc.h',
   'radeon_vcn_dec.c',
   'radeon_vcn_dec.h',
+  'radeon_uvd_enc_1_1.c',
   'radeon_uvd_enc.h',
   'radeon_vce_40_2_2.c',
   'radeon_vce_50.c',
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c 
b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
new file mode 100644
index 000..42a9fa9
--- /dev/null
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
@@ -0,0 +1,1132 @@
+/**
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_video_codec.h"
+
+#include "util/u_video.h"
+#include "util/u_memory.h"
+
+#include "vl/vl_video_buffer.h"
+#include "radeonsi/si_pipe.h"
+#include "radeon_video.h"
+#include "radeon_uvd_enc.h"
+
+#define RADEON_ENC_CS(value) (enc->cs->current.buf[enc->cs->current.cdw++] = 
(value))
+#define RADEON_ENC_BEGIN(cmd) { \
+   uint32_t *begin = >cs->current.buf[enc->cs->current.cdw++]; \
+RADEON_ENC_CS(cmd)
+#define RADEON_ENC_READ(buf, domain, off) radeon_uvd_enc_add_buffer(enc, 
(buf), RADEON_USAGE_READ, (domain), (off))
+#define RADEON_ENC_WRITE(buf, domain, off) radeon_uvd_enc_add_buffer(enc, 
(buf), RADEON_USAGE_WRITE, (domain), (off))
+#define RADEON_ENC_READWRITE(buf, domain, off) radeon_uvd_enc_add_buffer(enc, 
(buf), RADEON_USAGE_READWRITE, (domain), (off))
+#define RADEON_ENC_END() *begin = (>cs->current.buf[enc->cs->current.cdw] 
- begin) * 4; \
+   enc->total_task_size += *begin;}
+
+static const unsigned index_to_shifts[4] = { 24, 16, 8, 0 };
+
+static void
+radeon_uvd_enc_add_buffer(struct radeon_uvd_encoder *enc,
+  struct pb_buffer *buf, enum radeon_bo_usage usage,
+  enum radeon_bo_domain domain, signed offset)
+{
+   enc->ws->cs_add_buffer(enc->cs, buf, usage | RADEON_USAGE_SYNCHRONIZED,
+  domain, RADEON_PRIO_VCE);
+   uint64_t addr;
+   addr = enc->ws->buffer_get_virtual_address(buf);
+   addr = addr + offset;
+   RADEON_ENC_CS(addr >> 32);
+   RADEON_ENC_CS(addr);
+}
+
+static void
+radeon_uvd_enc_set_emulation_prevention(struct radeon_uvd_encoder *enc,
+bool set)
+{
+   if (set != enc->emulation_prevention) {
+  enc->emulation_prevention = set;
+  enc->num_zeros = 0;
+   }
+}
+
+static void
+radeon_uvd_enc_output_one_byte(struct radeon_uvd_encoder *enc,
+   unsigned char byte)
+{
+   if (enc->byte_index == 0)
+  enc->cs->current.buf[enc->cs->current.cdw] = 0;
+   enc->cs->current.buf[enc->cs->current.cdw] 

[Mesa-dev] [PATCH v6 6/7] radeonsi:create uvd hevc enc entry

[James Zhu]

Add UVD hevc encode pipe video codec creation entry

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/drivers/radeonsi/si_uvd.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_uvd.c 
b/src/gallium/drivers/radeonsi/si_uvd.c
index 64f2f8e..3906bbd 100644
--- a/src/gallium/drivers/radeonsi/si_uvd.c
+++ b/src/gallium/drivers/radeonsi/si_uvd.c
@@ -31,6 +31,8 @@
 #include "radeon/radeon_vce.h"
 #include "radeon/radeon_vcn_dec.h"
 #include "radeon/radeon_vcn_enc.h"
+#include "radeon/radeon_uvd_enc.h"
+#include "util/u_video.h"
 
 /**
  * creates an video buffer with an UVD compatible memory layout
@@ -146,9 +148,16 @@ struct pipe_video_codec *si_uvd_create_decoder(struct 
pipe_context *context,
struct si_context *ctx = (struct si_context *)context;
bool vcn = (ctx->b.family == CHIP_RAVEN) ? true : false;
 
-   if (templ->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE)
-   return (vcn) ? radeon_create_encoder(context, templ, ctx->b.ws, 
si_vce_get_buffer) :
-   si_vce_create_encoder(context, templ, ctx->b.ws, 
si_vce_get_buffer);
+   if (templ->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) {
+   if (vcn) {
+   radeon_create_encoder(context, templ, ctx->b.ws, 
si_vce_get_buffer);
+   } else {
+   if (u_reduce_video_profile(templ->profile) == 
PIPE_VIDEO_FORMAT_HEVC)
+   return radeon_uvd_create_encoder(context, 
templ, ctx->b.ws, si_vce_get_buffer);
+   else
+   return si_vce_create_encoder(context, templ, 
ctx->b.ws, si_vce_get_buffer);
+   }
+   }
 
return (vcn) ?  radeon_create_decoder(context, templ) :
si_common_uvd_create_decoder(context, templ, si_uvd_set_dtb);
-- 
2.7.4

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

[Mesa-dev] [PATCH v6 5/7] radeon/uvd:add uvd hevc enc functions

[James Zhu]

Implement UVD hevc encode functions

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/Makefile.sources |   1 +
 src/gallium/drivers/radeon/meson.build  |   1 +
 src/gallium/drivers/radeon/radeon_uvd_enc.c | 381 
 3 files changed, 383 insertions(+)
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc.c

diff --git a/src/gallium/drivers/radeon/Makefile.sources 
b/src/gallium/drivers/radeon/Makefile.sources
index 061d1e1..f8ee860 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -16,6 +16,7 @@ C_SOURCES := \
radeon_vcn_enc.c \
radeon_vcn_enc.h \
radeon_uvd_enc_1_1.c \
+   radeon_uvd_enc.c \
radeon_uvd_enc.h \
radeon_vce_40_2_2.c \
radeon_vce_50.c \
diff --git a/src/gallium/drivers/radeon/meson.build 
b/src/gallium/drivers/radeon/meson.build
index 1bc5e83..582a5ff 100644
--- a/src/gallium/drivers/radeon/meson.build
+++ b/src/gallium/drivers/radeon/meson.build
@@ -36,6 +36,7 @@ files_libradeon = files(
   'radeon_vcn_dec.c',
   'radeon_vcn_dec.h',
   'radeon_uvd_enc_1_1.c',
+  'radeon_uvd_enc.c',
   'radeon_uvd_enc.h',
   'radeon_vce_40_2_2.c',
   'radeon_vce_50.c',
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.c 
b/src/gallium/drivers/radeon/radeon_uvd_enc.c
new file mode 100644
index 000..94bd26a
--- /dev/null
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.c
@@ -0,0 +1,381 @@
+/**
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include 
+
+#include "pipe/p_video_codec.h"
+
+#include "util/u_video.h"
+#include "util/u_memory.h"
+
+#include "vl/vl_video_buffer.h"
+
+#include "radeonsi/si_pipe.h"
+#include "radeon_video.h"
+#include "radeon_uvd_enc.h"
+
+#define UVD_HEVC_LEVEL_1   30
+#define UVD_HEVC_LEVEL_2   60
+#define UVD_HEVC_LEVEL_2_1 63
+#define UVD_HEVC_LEVEL_3   90
+#define UVD_HEVC_LEVEL_3_1 93
+#define UVD_HEVC_LEVEL_4   120
+#define UVD_HEVC_LEVEL_4_1 123
+#define UVD_HEVC_LEVEL_5   150
+#define UVD_HEVC_LEVEL_5_1 153
+#define UVD_HEVC_LEVEL_5_2 156
+#define UVD_HEVC_LEVEL_6   180
+#define UVD_HEVC_LEVEL_6_1 183
+#define UVD_HEVC_LEVEL_6_2 186
+
+static void
+radeon_uvd_enc_get_param(struct radeon_uvd_encoder *enc,
+ struct pipe_h265_enc_picture_desc *pic)
+{
+   enc->enc_pic.picture_type = pic->picture_type;
+   enc->enc_pic.frame_num = pic->frame_num;
+   enc->enc_pic.pic_order_cnt = pic->pic_order_cnt;
+   enc->enc_pic.pic_order_cnt_type = pic->pic_order_cnt_type;
+   enc->enc_pic.not_referenced = pic->not_referenced;
+   enc->enc_pic.is_iframe =
+  (pic->picture_type == PIPE_H265_ENC_PICTURE_TYPE_IDR)
+  || (pic->picture_type == PIPE_H265_ENC_PICTURE_TYPE_I);
+   enc->enc_pic.crop_left = 0;
+   enc->enc_pic.crop_right =
+  (align(enc->base.width, 16) - enc->base.width) / 2;
+   enc->enc_pic.crop_top = 0;
+   enc->enc_pic.crop_bottom =
+  (align(enc->base.height, 16) - enc->base.height) / 2;
+   enc->enc_pic.general_tier_flag = pic->seq.general_tier_flag;
+   enc->enc_pic.general_profile_idc = pic->seq.general_profile_idc;
+   enc->enc_pic.general_level_idc = pic->seq.general_level_idc;
+   enc->enc_pic.max_poc = pic->seq.intra_period;
+   enc->enc_pic.log2_max_poc = 0;
+   for (int i = enc->enc_pic.max_poc; i != 0; enc->enc_pic.log2_max_poc++)
+  i = (i >> 1);
+   enc->enc_pic.chroma_format_idc = pic->seq.chroma_format_idc;
+   enc->enc_pic.pic_width_in_luma_samples =
+  pic->seq.pic_width_in_luma_samples;
+   enc->enc_pic.pic_height_in_luma_samples =
+  

[Mesa-dev] [PATCH v6 0/7] The 6th version for UVD HEVC encode

[James Zhu]

The whole series are the updated version. Changes are made mainly
based on the comments from prevous code review from Alex, Leo, 
Boyuan, Bas, Marek, Christian and Mark

James Zhu (7):
  amd/common:add uvd hevc enc support check in hw query
  winsys/amdgpu:add uvd hevc enc support in amdgpu cs
  radeon/uvd:add uvd hevc enc hw interface header
  radeon/uvd:add uvd hevc enc hw ib implementation
  radeon/uvd:add uvd hevc enc functions
  radeonsi:create uvd hevc enc entry
  radeonsi: enable uvd encode for HEVC main

 src/amd/common/ac_gpu_info.c|   12 +-
 src/amd/common/ac_gpu_info.h|1 +
 src/gallium/drivers/radeon/Makefile.sources |3 +
 src/gallium/drivers/radeon/meson.build  |3 +
 src/gallium/drivers/radeon/radeon_uvd_enc.c |  381 
 src/gallium/drivers/radeon/radeon_uvd_enc.h |  469 ++
 src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 1132 +++
 src/gallium/drivers/radeonsi/si_get.c   |4 +-
 src/gallium/drivers/radeonsi/si_uvd.c   |   15 +-
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c   |6 +
 10 files changed, 2021 insertions(+), 5 deletions(-)
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc.c
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc.h
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c

-- 
2.7.4

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

[Mesa-dev] [PATCH v6 2/7] winsys/amdgpu:add uvd hevc enc support in amdgpu cs

[James Zhu]

Support UVD HEVC encode in amdgpu cs

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
index 1927a3a..92d5394 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
@@ -376,6 +376,7 @@ static bool amdgpu_cs_has_user_fence(struct 
amdgpu_cs_context *cs)
 {
return cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD &&
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCE &&
+  cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_UVD_ENC &&
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_DEC &&
   cs->ib[IB_MAIN].ip_type != AMDGPU_HW_IP_VCN_ENC;
 }
@@ -818,6 +819,10 @@ static bool amdgpu_init_cs_context(struct 
amdgpu_cs_context *cs,
   cs->ib[IB_MAIN].ip_type = AMDGPU_HW_IP_UVD;
   break;
 
+   case RING_UVD_ENC:
+  cs->ib[IB_MAIN].ip_type = AMDGPU_HW_IP_UVD_ENC;
+  break;
+
case RING_VCE:
   cs->ib[IB_MAIN].ip_type = AMDGPU_HW_IP_VCE;
   break;
@@ -1533,6 +1538,7 @@ static int amdgpu_cs_flush(struct radeon_winsys_cs *rcs,
   ws->gfx_ib_size_counter += (rcs->prev_dw + rcs->current.cdw) * 4;
   break;
case RING_UVD:
+   case RING_UVD_ENC:
   while (rcs->current.cdw & 15)
  radeon_emit(rcs, 0x8000); /* type2 nop packet */
   break;
-- 
2.7.4

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

[Mesa-dev] [PATCH v6 3/7] radeon/uvd:add uvd hevc enc hw interface header

[James Zhu]

Add hevc encode hardware interface for UVD

Signed-off-by: James Zhu 
Reviewed-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/Makefile.sources |   1 +
 src/gallium/drivers/radeon/meson.build  |   1 +
 src/gallium/drivers/radeon/radeon_uvd_enc.h | 469 
 3 files changed, 471 insertions(+)
 create mode 100644 src/gallium/drivers/radeon/radeon_uvd_enc.h

diff --git a/src/gallium/drivers/radeon/Makefile.sources 
b/src/gallium/drivers/radeon/Makefile.sources
index b756d72..5445625 100644
--- a/src/gallium/drivers/radeon/Makefile.sources
+++ b/src/gallium/drivers/radeon/Makefile.sources
@@ -15,6 +15,7 @@ C_SOURCES := \
radeon_vcn_enc_1_2.c \
radeon_vcn_enc.c \
radeon_vcn_enc.h \
+   radeon_uvd_enc.h \
radeon_vce_40_2_2.c \
radeon_vce_50.c \
radeon_vce_52.c \
diff --git a/src/gallium/drivers/radeon/meson.build 
b/src/gallium/drivers/radeon/meson.build
index 6857df3..f587f17 100644
--- a/src/gallium/drivers/radeon/meson.build
+++ b/src/gallium/drivers/radeon/meson.build
@@ -35,6 +35,7 @@ files_libradeon = files(
   'radeon_vcn_enc.h',
   'radeon_vcn_dec.c',
   'radeon_vcn_dec.h',
+  'radeon_uvd_enc.h',
   'radeon_vce_40_2_2.c',
   'radeon_vce_50.c',
   'radeon_vce_52.c',
diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc.h 
b/src/gallium/drivers/radeon/radeon_uvd_enc.h
new file mode 100644
index 000..20c340d
--- /dev/null
+++ b/src/gallium/drivers/radeon/radeon_uvd_enc.h
@@ -0,0 +1,469 @@
+/**
+ *
+ * Copyright 2018 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR
+ * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#ifndef _RADEON_UVD_ENC_H
+#define _RADEON_UVD_ENC_H
+
+#define RENC_UVD_FW_INTERFACE_MAJOR_VERSION 1
+#define RENC_UVD_FW_INTERFACE_MINOR_VERSION 1
+
+#define RENC_UVD_IB_PARAM_SESSION_INFO  0x0001
+#define RENC_UVD_IB_PARAM_TASK_INFO 0x0002
+#define RENC_UVD_IB_PARAM_SESSION_INIT  0x0003
+#define RENC_UVD_IB_PARAM_LAYER_CONTROL 0x0004
+#define RENC_UVD_IB_PARAM_LAYER_SELECT  0x0005
+#define RENC_UVD_IB_PARAM_SLICE_CONTROL 0x0006
+#define RENC_UVD_IB_PARAM_SPEC_MISC 0x0007
+#define RENC_UVD_IB_PARAM_RATE_CONTROL_SESSION_INIT 0x0008
+#define RENC_UVD_IB_PARAM_RATE_CONTROL_LAYER_INIT   0x0009
+#define RENC_UVD_IB_PARAM_RATE_CONTROL_PER_PICTURE  0x000a
+#define RENC_UVD_IB_PARAM_SLICE_HEADER  0x000b
+#define RENC_UVD_IB_PARAM_ENCODE_PARAMS 0x000c
+#define RENC_UVD_IB_PARAM_QUALITY_PARAMS0x000d
+#define RENC_UVD_IB_PARAM_DEBLOCKING_FILTER 0x000e
+#define RENC_UVD_IB_PARAM_INTRA_REFRESH 0x000f
+#define RENC_UVD_IB_PARAM_ENCODE_CONTEXT_BUFFER 0x0010
+#define RENC_UVD_IB_PARAM_VIDEO_BITSTREAM_BUFFER0x0011
+#define RENC_UVD_IB_PARAM_FEEDBACK_BUFFER   0x0012
+#define RENC_UVD_IB_PARAM_INSERT_NALU_BUFFER0x0013
+#define RENC_UVD_IB_PARAM_FEEDBACK_BUFFER_ADDITIONAL0x0014
+
+#define RENC_UVD_IB_OP_INITIALIZE   0x0801
+#define RENC_UVD_IB_OP_CLOSE_SESSION0x0802
+#define RENC_UVD_IB_OP_ENCODE   0x0803
+#define RENC_UVD_IB_OP_INIT_RC  0x0804
+#define RENC_UVD_IB_OP_INIT_RC_VBV_BUFFER_LEVEL 0x0805
+#define RENC_UVD_IB_OP_SET_SPEED_ENCODING_MODE  0x0806
+#define RENC_UVD_IB_OP_SET_BALANCE_ENCODING_MODE0x0807
+#define RENC_UVD_IB_OP_SET_QUALITY_ENCODING_MODE0x0808
+
+#define 

[Mesa-dev] [PATCH v6 1/7] amd/common:add uvd hevc enc support check in hw query

[James Zhu]

Based on amdgpu hardware query information to check if UVD hevc enc support

Signed-off-by: James Zhu 
Reviewed-by: Marek Olšák 
---
 src/amd/common/ac_gpu_info.c | 12 +++-
 src/amd/common/ac_gpu_info.h |  1 +
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c
index 6d9dcb5..3156df6 100644
--- a/src/amd/common/ac_gpu_info.c
+++ b/src/amd/common/ac_gpu_info.c
@@ -98,7 +98,7 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
 {
struct amdgpu_buffer_size_alignments alignment_info = {};
struct amdgpu_heap_info vram, vram_vis, gtt;
-   struct drm_amdgpu_info_hw_ip dma = {}, compute = {}, uvd = {}, vce = 
{}, vcn_dec = {}, vcn_enc = {};
+   struct drm_amdgpu_info_hw_ip dma = {}, compute = {}, uvd = {}, uvd_enc 
= {}, vce = {}, vcn_dec = {}, vcn_enc = {};
uint32_t vce_version = 0, vce_feature = 0, uvd_version = 0, uvd_feature 
= 0;
int r, i, j;
drmDevicePtr devinfo;
@@ -167,6 +167,14 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
}
 
if (info->drm_major == 3 && info->drm_minor >= 17) {
+   r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_UVD_ENC, 0, 
_enc);
+   if (r) {
+   fprintf(stderr, "amdgpu: 
amdgpu_query_hw_ip_info(uvd_enc) failed.\n");
+   return false;
+   }
+   }
+
+   if (info->drm_major == 3 && info->drm_minor >= 17) {
r = amdgpu_query_hw_ip_info(dev, AMDGPU_HW_IP_VCN_DEC, 0, 
_dec);
if (r) {
fprintf(stderr, "amdgpu: 
amdgpu_query_hw_ip_info(vcn_dec) failed.\n");
@@ -275,6 +283,8 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev,
uvd.available_rings ? uvd_version : 0;
info->vce_fw_version =
vce.available_rings ? vce_version : 0;
+   info->uvd_enc_supported =
+   uvd_enc.available_rings ? true : false;
info->has_userptr = true;
info->has_syncobj = has_syncobj(fd);
info->has_syncobj_wait_for_submit = info->has_syncobj && 
info->drm_minor >= 20;
diff --git a/src/amd/common/ac_gpu_info.h b/src/amd/common/ac_gpu_info.h
index cca3e98..36714ee 100644
--- a/src/amd/common/ac_gpu_info.h
+++ b/src/amd/common/ac_gpu_info.h
@@ -65,6 +65,7 @@ struct radeon_info {
uint32_tnum_compute_rings;
uint32_tuvd_fw_version;
uint32_tvce_fw_version;
+   booluvd_enc_supported;
uint32_tme_fw_version;
uint32_tme_fw_feature;
uint32_tpfp_fw_version;
-- 
2.7.4

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

[Mesa-dev] [Bug 105132] glxSwapBuffers has no effect

[bugzilla-daemon]

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

Bug ID: 105132
   Summary: glxSwapBuffers has no effect
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: GLX
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: julien.iso...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Hi, 

Initially looking at the gstreamer bug
https://bugzilla.gnome.org/show_bug.cgi?id=774809 it seems it could be a pb in
mesa:

In src/glx/dri2_glx.c::dri2SwapBuffers psc->f->invalidate is not called when
using dri2 on an up to date Ubuntu 16.04. Because the call to
dri2InvalidateBuffers is guarded by "if (!pdp->invalidateAvailable)"

But with dri2 and egl the '->invalidate' is always called, see
dri3_swap_buffers/loader_dri3_swap_buffers_msc and
egl/dri2_x11_swap_buffers_msc

X server is version 1.18.4 and xorg-video-intel is 2:2.99.917

So it looks like xserver/hw/xfree86/dri2/dri2ext.c::DRI2InvalidateBuffersEvent
is not called and the comment "/* Old servers don't send invalidate events */"
src/glx/dri2_glx.c make sense.

1: Why this difference between dri2 and dri3/egl ? I would have expect the
otherway, always called on dri2 and not on dri3.

2: Is "pdp->invalidateAvailable = (pdp->driMinor >= 3);" not accurate ? Should
it check for the exact xserver version which contains the fix ?

Thx in advance for any feedback.

-- 
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 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

[bugzilla-daemon]

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

--- Comment #49 from Thomas J. Moore  ---
(In reply to Alex from comment #48)
> Yes, the shim seems to no longer work -- I assume newer Mesa versions are no
> longer declaring compatibility with whatever version Divinity was hardcoded
> to?

Or maybe it's a Fedora issue, or an Intel issue.  I can't test either of those
(well, I could probably test Fedora if I wanted to, but that's a lot of work). 
I am currently running mesa 18-rc4 (gentoo/amdgpu), and the game still works
fine (as it has in all previous versions I've tested).  So it's not "newer
mesa", at least as far as I can tell.

OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.0-rc4
OpenGL core profile shading language version string: 4.50

I set allow_glsl_extension_directive_midshader=true in my .drirc, so my startup
script just adds the game dir to LD_LIBRARY_PATH, sets LD_PRELOAD, and runs the
game.  I don't even bother removing game-supplied libraries any more, but I
used to remove libopenal*, libpng16*, libSDL2* and libXss* (not sure any more
why).

The only thing I can think of that I do differently that probably does not
affect things is set R600_DEBUG=nodccfb due to bug #102885.  I might have some
other magical settings in my .drirc, but I don't feel like stabbing in the
dark.

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

[Mesa-dev] [PATCH] nvc0: Use GP100_COMPUTE_CLASS on GP10B

[Mikko Perttunen]

From: Mikko Perttunen 

GP10B requires the use of GP100_COMPUTE_CLASS instead of
GP104_COMPUTE_CLASS as is used for other non-GP100 chips.

Signed-off-by: Mikko Perttunen 
---
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
index f641f47..28460f8 100644
--- a/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nve4_compute.c
@@ -59,7 +59,8 @@ nve4_screen_compute_setup(struct nvc0_screen *screen,
   obj_class = GM200_COMPUTE_CLASS;
   break;
case 0x130:
-  obj_class = dev->chipset == 0x130 ? GP100_COMPUTE_CLASS : 
GP104_COMPUTE_CLASS;
+  obj_class = (dev->chipset == 0x130 || dev->chipset == 0x13b) ?
+  GP100_COMPUTE_CLASS : GP104_COMPUTE_CLASS;
   break;
default:
   NOUVEAU_ERR("unsupported chipset: NV%02x\n", dev->chipset);
-- 
2.9.3

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

[Mesa-dev] [PATCH] virgl: native fence fd support

[Gustavo Padovan]

From: Gustavo Padovan 

Following the support for fences on the virtio driver add support
for native fence on virgl. This was somewhat based on the freedeno one.

Signed-off-by: Gustavo Padovan 
---
The kernel side patches can be found at:

https://gitlab.collabora.com/padovan/linux/tree/virtio-fences


 src/gallium/drivers/virgl/virgl_context.c  | 46 +++--
 src/gallium/drivers/virgl/virgl_screen.c   | 12 +++-
 src/gallium/drivers/virgl/virgl_winsys.h   | 15 +++-
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.c| 80 +-
 src/gallium/winsys/virgl/drm/virgl_drm_winsys.h|  2 +
 src/gallium/winsys/virgl/drm/virtgpu_drm.h | 14 +++-
 .../winsys/virgl/vtest/virgl_vtest_winsys.c|  8 ++-
 7 files changed, 161 insertions(+), 16 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index f1b6ef4501..cf4aacdcbf 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -21,6 +21,7 @@
  * USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include "pipe/p_shader_tokens.h"
 
 #include "pipe/p_context.h"
@@ -615,13 +616,20 @@ static void virgl_draw_vbo(struct pipe_context *ctx,
 
 }
 
-static void virgl_flush_eq(struct virgl_context *ctx, void *closure)
+static void virgl_flush_eq(struct virgl_context *ctx, void *closure,
+  struct pipe_fence_handle **fence)
 {
struct virgl_screen *rs = virgl_screen(ctx->base.screen);
+   int out_fence_fd = -1;
 
/* send the buffer to the remote side for decoding */
ctx->num_transfers = ctx->num_draws = 0;
-   rs->vws->submit_cmd(rs->vws, ctx->cbuf);
+
+   rs->vws->submit_cmd(rs->vws, ctx->cbuf, ctx->cbuf->in_fence_fd,
+   ctx->cbuf->needs_out_fence_fd ? _fence_fd : NULL);
+
+   if (fence)
+  *fence = rs->vws->cs_create_fence(rs->vws, out_fence_fd);
 
virgl_encoder_set_sub_ctx(ctx, ctx->hw_sub_ctx_id);
 
@@ -634,11 +642,10 @@ static void virgl_flush_from_st(struct pipe_context *ctx,
enum pipe_flush_flags flags)
 {
struct virgl_context *vctx = virgl_context(ctx);
-   struct virgl_screen *rs = virgl_screen(ctx->screen);
struct virgl_buffer *buf, *tmp;
 
-   if (fence)
-  *fence = rs->vws->cs_create_fence(rs->vws);
+   if (flags & PIPE_FLUSH_FENCE_FD)
+   vctx->cbuf->needs_out_fence_fd = true;
 
LIST_FOR_EACH_ENTRY_SAFE(buf, tmp, >to_flush_bufs, flush_list) {
   struct pipe_resource *res = >base.u.b;
@@ -648,7 +655,13 @@ static void virgl_flush_from_st(struct pipe_context *ctx,
   pipe_resource_reference(, NULL);
 
}
-   virgl_flush_eq(vctx, vctx);
+   virgl_flush_eq(vctx, vctx, fence);
+
+   if (vctx->cbuf->in_fence_fd != -1) {
+  close(vctx->cbuf->in_fence_fd);
+  vctx->cbuf->in_fence_fd = -1;
+   }
+   vctx->cbuf->needs_out_fence_fd = false;
 }
 
 static struct pipe_sampler_view *virgl_create_sampler_view(struct pipe_context 
*ctx,
@@ -838,6 +851,23 @@ static void virgl_blit(struct pipe_context *ctx,
 blit);
 }
 
+static void virgl_create_fence_fd(struct pipe_context *ctx,
+   struct pipe_fence_handle **fence, int fd)
+{
+   struct virgl_screen *rs = virgl_screen(ctx->screen);
+
+   *fence = rs->vws->cs_create_fence(rs->vws, fd);
+}
+
+static void virgl_fence_server_sync(struct pipe_context *ctx,
+   struct pipe_fence_handle *fence)
+{
+   struct virgl_context *vctx = virgl_context(ctx);
+   struct virgl_screen *rs = virgl_screen(ctx->screen);
+
+   rs->vws->fence_server_sync(rs->vws, vctx->cbuf, fence);
+}
+
 static void
 virgl_context_destroy( struct pipe_context *ctx )
 {
@@ -847,7 +877,7 @@ virgl_context_destroy( struct pipe_context *ctx )
vctx->framebuffer.zsbuf = NULL;
vctx->framebuffer.nr_cbufs = 0;
virgl_encoder_destroy_sub_ctx(vctx, vctx->hw_sub_ctx_id);
-   virgl_flush_eq(vctx, vctx);
+   virgl_flush_eq(vctx, vctx, NULL);
 
rs->vws->cmd_buf_destroy(vctx->cbuf);
if (vctx->uploader)
@@ -928,6 +958,8 @@ struct pipe_context *virgl_context_create(struct 
pipe_screen *pscreen,
vctx->base.resource_copy_region = virgl_resource_copy_region;
vctx->base.flush_resource = virgl_flush_resource;
vctx->base.blit =  virgl_blit;
+   vctx->base.create_fence_fd = virgl_create_fence_fd;
+   vctx->base.fence_server_sync = virgl_fence_server_sync;
 
virgl_init_context_resource_functions(>base);
virgl_init_query_functions(vctx);
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index f4f3195ce3..f0c006bb85 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -284,7 +284,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_VIDEO_MEMORY:
   return 0;
case 

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Tomasz Figa]

On Fri, Feb 16, 2018 at 11:33 PM, Robert Foss  wrote:
> Hey Tomasz,
>
>
> On 02/16/2018 05:10 AM, Tomasz Figa wrote:
>>
>> On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring  wrote:
>>>
>>> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa  wrote:

 On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa  wrote:
>
> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring  wrote:
>>
>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa 
>> wrote:
>>>
>>> Hi Rob,
>>>
>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss
>>>  wrote:
>
>uint32_t (*get_fd)(buffer_handle_t handle, uint32_t
> plane);
>uint64_t (*get_modifier)(buffer_handle_t handle,
> uint32_t
> plane);
>uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t
> plane);
>uint32_t (*get_stride)(buffer_handle_t handle, uint32_t
> plane);
>...
> } gralloc_funcs_t;
>
>
>
> These ones? >
> Yeah, if we could retrieve such function pointer struct using
> perform
> or any equivalent (like the implementation-specific methods in
> gralloc1, but not sure if that's going to be used in practice
> anywhere), it could work for us.



 So this is where you and Rob Herring lose me, I don't think I
 understand
 quite how the gralloc1 call would be used, and how it would tie into
 this
 handle struct. I think I could do with some guidance on this.
>>>
>>>
>>> This would be very similar to gralloc0 perform call. gralloc1
>>> implementations need to provide getFunction() callback [1], which
>>> returns a pointer to given function. The list of standard functions
>>> is
>>> defined in the gralloc1.h header [2], but we could take some random
>>> big number and use it for our function that fills in provided
>>> gralloc_funcs_t struct with necessary pointers.
>>>
>>> [1]
>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>> [2]
>>> https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>
>>
>> This is a deadend because it won't work with a HIDL based
>> implementation (aka gralloc 2.0). You can't set function pointers (or
>> any pointers) because gralloc runs in a different process. Yes,
>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>
>
> Part of it. I can't see IMapper being implemented by a separate
> process. You can't map a buffer into one process from another process.
>
> But anyway, it's a good point, thanks, I almost forgot about its
> existence. I'll do further investigation.


 Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
 at the moment what we could do about it. (The idea of a dynamic
 library of a pre-defined name, exporting functions we specify, might
 still work, though.)

 Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be
 impossible to implement with IAllocator/IMapper. (Although I still
 think Mesa and Gralloc are free to have separate logic for choosing
 the DRM device to use.)
>>>
>>>
>>> I think the need for GET_FD goes away when the render node is used. We
>>> may still need the card node for s/w rendering (if I can ever get that
>>> working) though. Of course, if we use the vgem approach like CrOS then
>>> we wouldn't.
>>
>>
>> Hmm, if so, then we probably wouldn't have any strict need for these
>> function pointers anymore. We already have a makeshift format resolve
>> in place and the only missing bits that we still need to patch up
>> downstream are removing GET_FD, dropping drm_gralloc.h and adding a
>> fallback to kms_swrast if hw driver loading fails.
>
>
> So this discussion is slightly unrelated, but it is where me looking at this
> started.
>
> So I've got a kms_swrast fallback series[1], that I've been wanting to test
> before trying to push upstream, but haven't been able to run it in the
> Android environment and the arc++ + chromiumos has also been problematic for
> various reasons (which are being looked into).
>
> Tomasz: If you're interested in testing the series, it would be helpful.
> Hopefully testing is everything that needed for upstreaming.
>
> [1] https://gitlab.collabora.com/robertfoss/mesa/commits/kms_swrast

+Gurchetan, who I believe is recently taking care of swrast on our side.

Sure, I'd be more than happy to test it on Monday.

Best regards,
Tomasz
___
mesa-dev mailing list

Re: [Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

[Robert Foss]

Hey Tomasz,

On 02/16/2018 05:10 AM, Tomasz Figa wrote:

On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring  wrote:

On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa  wrote:

On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa  wrote:

On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring  wrote:

On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa  wrote:

Hi Rob,

On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss  wrote:

   uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
   uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
plane);
   uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
   uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
   ...
} gralloc_funcs_t;



These ones? >
Yeah, if we could retrieve such function pointer struct using perform
or any equivalent (like the implementation-specific methods in
gralloc1, but not sure if that's going to be used in practice
anywhere), it could work for us.



So this is where you and Rob Herring lose me, I don't think I understand
quite how the gralloc1 call would be used, and how it would tie into this
handle struct. I think I could do with some guidance on this.


This would be very similar to gralloc0 perform call. gralloc1
implementations need to provide getFunction() callback [1], which
returns a pointer to given function. The list of standard functions is
defined in the gralloc1.h header [2], but we could take some random
big number and use it for our function that fills in provided
gralloc_funcs_t struct with necessary pointers.

[1] 
https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
[2] 
https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134


This is a deadend because it won't work with a HIDL based
implementation (aka gralloc 2.0). You can't set function pointers (or
any pointers) because gralloc runs in a different process. Yes,
currently gralloc is a pass-thru HAL, but AIUI that will go away.


Part of it. I can't see IMapper being implemented by a separate
process. You can't map a buffer into one process from another process.

But anyway, it's a good point, thanks, I almost forgot about its
existence. I'll do further investigation.


Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
at the moment what we could do about it. (The idea of a dynamic
library of a pre-defined name, exporting functions we specify, might
still work, though.)

Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be
impossible to implement with IAllocator/IMapper. (Although I still
think Mesa and Gralloc are free to have separate logic for choosing
the DRM device to use.)


I think the need for GET_FD goes away when the render node is used. We
may still need the card node for s/w rendering (if I can ever get that
working) though. Of course, if we use the vgem approach like CrOS then
we wouldn't.


Hmm, if so, then we probably wouldn't have any strict need for these
function pointers anymore. We already have a makeshift format resolve
in place and the only missing bits that we still need to patch up
downstream are removing GET_FD, dropping drm_gralloc.h and adding a
fallback to kms_swrast if hw driver loading fails.


So this discussion is slightly unrelated, but it is where me looking at this 
started.


So I've got a kms_swrast fallback series[1], that I've been wanting to test 
before trying to push upstream, but haven't been able to run it in the Android 
environment and the arc++ + chromiumos has also been problematic for various 
reasons (which are being looked into).


Tomasz: If you're interested in testing the series, it would be helpful. 
Hopefully testing is everything that needed for upstreaming.


[1] https://gitlab.collabora.com/robertfoss/mesa/commits/kms_swrast
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105103] Wayland master causes Mesa to fail to compile

[bugzilla-daemon]

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

Daniel Stone  changed:

   What|Removed |Added

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

--- Comment #3 from Daniel Stone  ---
Fixed now in Mesa master, and patch is tagged for backporting to 17.3.x and
18.0.0.

-- 
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] egl/wayland: Always use in-tree wayland-egl-backend.h

[Daniel Stone]

On 16 February 2018 at 13:56, Emil Velikov  wrote:
> On 15 February 2018 at 13:13, Emil Velikov  wrote:
>> On 15 February 2018 at 09:23, Daniel Stone  wrote:
>>> A recent patchset to Wayland[0] migrated Mesa's libwayland-egl backend
>>> into Wayland itself, so implementations could provide backends. Mesa
>>> still uses its own, and the two have already diverged[1].
>>>
>>> The include from egl_dri2.h could pick up either the installed Wayland
>>> wayland-egl-backend.h (with a 'driver_private' member), or the Mesa
>>> internal wayland-egl-backend.h (with a 'private' member), failing the
>>> build in the first instance.
>>>
>>> Add an explicit directory prefix to the include, so we always get our
>>> in-tree version.
>>>
>>> [0]: https://patchwork.freedesktop.org/series/31663/
>>> [1]: https://cgit.freedesktop.org/wayland/wayland/commit/?id=9fa60983b579
>>>
>> Hmm in hind-sight, one could have fixed the "C++ issue" in a backward
>> compatible manner.
>> Let me try that instead - otherwise we need to port this patch to
>> every mesa in existence :-\
>
> Considering s/every mesa in existence/a couple odd versions/ + fix is
> dead trivial, lets go with this.
> This is way cleaner than my hack for wayland.
>
> Small nit - s/Fixes/Bugzilla/
> Reviewed-by: Emil Velikov 

Thanks a lot Emil, pushed now as ff5432dc5061. I tagged the original
commit as Fixes, so hopefully it can make it in to 17.3.x as well as
18.0.0.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] egl/wayland: Always use in-tree wayland-egl-backend.h

[Emil Velikov]

On 15 February 2018 at 13:13, Emil Velikov  wrote:
> On 15 February 2018 at 09:23, Daniel Stone  wrote:
>> A recent patchset to Wayland[0] migrated Mesa's libwayland-egl backend
>> into Wayland itself, so implementations could provide backends. Mesa
>> still uses its own, and the two have already diverged[1].
>>
>> The include from egl_dri2.h could pick up either the installed Wayland
>> wayland-egl-backend.h (with a 'driver_private' member), or the Mesa
>> internal wayland-egl-backend.h (with a 'private' member), failing the
>> build in the first instance.
>>
>> Add an explicit directory prefix to the include, so we always get our
>> in-tree version.
>>
>> [0]: https://patchwork.freedesktop.org/series/31663/
>> [1]: https://cgit.freedesktop.org/wayland/wayland/commit/?id=9fa60983b579
>>
> Hmm in hind-sight, one could have fixed the "C++ issue" in a backward
> compatible manner.
> Let me try that instead - otherwise we need to port this patch to
> every mesa in existence :-\
>
Considering s/every mesa in existence/a couple odd versions/ + fix is
dead trivial, lets go with this.
This is way cleaner than my hack for wayland.

Small nit - s/Fixes/Bugzilla/
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 00/31] SWR-related rasterizer changes

[Cherniak, Bruce]

Entire set Reviewed-by: Bruce Cherniak  

> On Feb 13, 2018, at 4:42 PM, George Kyriazis  
> wrote:
> 
> Batch patchset of SWR rasterizer-related changes
> 
> George Kyriazis (31):
>  swr/rast: Add missing parameter to a few gather functions
>  swr/rast: Cleanup knob definitions
>  swr/rast: Don't include private context in gathers
>  swr/rast: Remove some JIT debug code
>  swr/rast: Cleanup of mpPrivateContext in Builder
>  swr/rast: Separate RDTSC code from archrast
>  swr/rast: Removed unused variable
>  swr/rast: Clean up event types and remove BE events
>  swr/rast: Separate event types to public and private
>  swr/rast: Add clipper stats.
>  swr/rast: Fix invalid number of attributes
>  swr/rast: whitespace cleanup
>  swr/rast: Cull prims when all verts have negative clip distances
>  swr/rast: More precise user clip distance interpolation
>  swr/rast: Fix avx version of GATHERPS
>  swr/rast: Renamed variable in vertexbufferstate
>  swr/rast: Misc cleanup
>  swr/rast: Use llvm intrinsic masked gather
>  swr/rast: Make GATHER4PS virtual
>  swr/rast: Fix primitive replication issue in tesselation PA.
>  swr/rast: Fix bug related to passing AR handle
>  swr/rast: Be more explicit when fetching next component
>  swr/rast: Use right type for offset to next component
>  swr/rast: Make SIMDLib templated types easier to use
>  swr/rast: Update/add comments
>  swr/rast: Convert C Sampler intrinsics
>  swr/rast: Fix SRL call with a non-immediate
>  swr/rast: Add semantics for translating address
>  swr/rast: Consolidate archrast Draw events
>  swr/rast: Normalize path for debug metadata
>  swr/rast: blend_epi32() should return Integer, not Float
> 
> src/gallium/drivers/swr/Makefile.am|  18 +-
> src/gallium/drivers/swr/SConscript |  17 +-
> src/gallium/drivers/swr/meson.build|   1 +
> .../drivers/swr/rasterizer/archrast/archrast.cpp   |  50 ++-
> .../drivers/swr/rasterizer/archrast/events.proto   | 206 +--
> .../swr/rasterizer/archrast/events_private.proto   | 152 +
> .../drivers/swr/rasterizer/codegen/gen_archrast.py |  25 +-
> .../drivers/swr/rasterizer/codegen/knob_defs.py|  90 +++--
> .../drivers/swr/rasterizer/codegen/meson.build |   8 +-
> .../swr/rasterizer/codegen/templates/gen_llvm.hpp  |   3 +-
> src/gallium/drivers/swr/rasterizer/common/intrin.h |   3 +
> .../drivers/swr/rasterizer/common/simdlib.hpp  |   9 +
> .../swr/rasterizer/common/simdlib_128_avx.inl  |  16 +
> .../swr/rasterizer/common/simdlib_512_avx512.inl   |   2 +-
> src/gallium/drivers/swr/rasterizer/core/api.cpp|  53 +--
> .../drivers/swr/rasterizer/core/backend.cpp|  26 +-
> .../drivers/swr/rasterizer/core/backend_clear.cpp  |   8 +-
> .../drivers/swr/rasterizer/core/backend_impl.h |  45 ++-
> .../drivers/swr/rasterizer/core/backend_sample.cpp |  38 +--
> .../swr/rasterizer/core/backend_singlesample.cpp   |  34 +-
> src/gallium/drivers/swr/rasterizer/core/binner.cpp | 377 ++---
> src/gallium/drivers/swr/rasterizer/core/binner.h   |  18 +-
> src/gallium/drivers/swr/rasterizer/core/clip.cpp   |  30 +-
> src/gallium/drivers/swr/rasterizer/core/clip.h | 228 +++--
> src/gallium/drivers/swr/rasterizer/core/context.h  |  51 ++-
> .../drivers/swr/rasterizer/core/frontend.cpp   |  89 +++--
> src/gallium/drivers/swr/rasterizer/core/pa.h   |   1 +
> .../drivers/swr/rasterizer/core/rasterizer.cpp |  11 +-
> .../drivers/swr/rasterizer/core/rasterizer_impl.h  |  29 +-
> src/gallium/drivers/swr/rasterizer/core/state.h|  81 +++--
> .../drivers/swr/rasterizer/core/threads.cpp|   8 +-
> .../drivers/swr/rasterizer/core/tilemgr.cpp|  24 +-
> .../drivers/swr/rasterizer/jitter/JitManager.cpp   |  45 ---
> .../drivers/swr/rasterizer/jitter/JitManager.h |  38 +--
> .../drivers/swr/rasterizer/jitter/builder.cpp  |   3 +-
> .../drivers/swr/rasterizer/jitter/builder.h|  14 +
> .../drivers/swr/rasterizer/jitter/builder_mem.cpp  |  30 +-
> .../drivers/swr/rasterizer/jitter/builder_mem.h|  13 +-
> .../drivers/swr/rasterizer/jitter/fetch_jit.cpp|  20 +-
> src/gallium/drivers/swr/swr_state.cpp  |   2 +-
> 40 files changed, 962 insertions(+), 954 deletions(-)
> create mode 100644 
> src/gallium/drivers/swr/rasterizer/archrast/events_private.proto
> 
> -- 
> 2.7.4
> 
> ___
> 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 kmscube v3] formats: use weston's egl config matching logic, centralize format

[Daniel Stone]

Hi Ilia,

On 10 February 2018 at 01:49, Ilia Mirkin  wrote:
> The GBM surface format has to match the DRM mode. Both are used in a
> couple of places, so unify it so that it's only set in one place. Note
> that the GBM and DRM formats are identical.

Pushed this one to master with review, thanks for doing this!

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

Re: [Mesa-dev] [PATCH v3 00/18] Rework subpass clears and transitions

[Iago Toral]

Hi Jason, I have just noticed that this series also conflicts with the
new version of the multiview clearing series I have just sent, I guess
we should wait until this lands first?

Iago

On Wed, 2018-02-14 at 12:16 -0800, Jason Ekstrand wrote:
> This is another version of my patch series to rework subpass clears
> and
> transitions.  It's fairly similar to the other one I sent out except
> that
> it's been rebased on top of the resolve reworks and has some fixes
> from
> Nanley.  There are also two patches on the front side to remove some
> potential non-determanism in the Vulkan driver.
> 
> Jason Ekstrand (18):
>   intel/isl: Add an isl_color_value_is_zero helper
>   anv: Be more careful about fast-clear colors
>   intel/blorp: Use the hardware op for CCS ambiguate on gen10+
>   anv: Use framebuffer layers for implicit subpass transitions
>   anv/cmd_buffer: Apply subpass flushes before set_subpass
>   anv/cmd_buffer: Add begin/end_subpass helpers
>   anv/cmd_buffer: Pass a subpass id into begin_subpass
>   anv/cmd_buffer: Move the color portion of clear_subpass into
> begin_subpass
>   intel/blorp: Add a blorp_hiz_clear_depth_stencil helper
>   anv/cmd_buffer: Move the rest of clear_subpass into begin_subpass
>   anv/cmd_buffer: Decide whether or not to HiZ clear up-front
>   anv/cmd_buffer: Iterate all subpass attachments when clearing
>   anv/cmd_buffer: Add a concept of pending load aspects
>   anv/pass: Store usage in each subpass attachment
>   anv/cmd_buffer: Sync clear values in begin_subpass
>   anv/cmd_buffer: Mark depth/stencil surfaces written in
> begin_subpass
>   anv/cmd_buffer: Do subpass image transitions in begin/end_subpass
>   anv/cmd_buffer: Avoid unnecessary transitions before fast clears
> 
>  src/intel/blorp/blorp.h|  11 +
>  src/intel/blorp/blorp_clear.c  |  65 +++-
>  src/intel/blorp/blorp_genX_exec.h  |   6 +
>  src/intel/isl/isl.c|  20 ++
>  src/intel/isl/isl.h|   3 +
>  src/intel/vulkan/anv_blorp.c   | 366 -
>  src/intel/vulkan/anv_pass.c|  35 +-
>  src/intel/vulkan/anv_private.h |  42 ++-
>  src/intel/vulkan/genX_cmd_buffer.c | 644 +
> 
>  9 files changed, 663 insertions(+), 529 deletions(-)
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 2/3] anv/blorp: honor pending clear views in clear_depth_stencil_attachment

[Iago Toral Quiroga]

We can call this for both subpass load clears and VkCmdClearAttachments.
In the former case, when multiview is active, we need to honor the mask
of pending clear views so we don't clear layers that have already been
cleared by a previous subpass, just like we do for subpass load color
clears.
---
 src/intel/vulkan/anv_blorp.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index ac3a434c94..25035909b6 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1040,7 +1040,8 @@ static void
 clear_depth_stencil_attachment(struct anv_cmd_buffer *cmd_buffer,
struct blorp_batch *batch,
const VkClearAttachment *attachment,
-   uint32_t rectCount, const VkClearRect *pRects)
+   uint32_t rectCount, const VkClearRect *pRects,
+   bool is_subpass_load)
 {
static const union isl_color_value color_value = { .u32 = { 0, } };
const struct anv_subpass *subpass = cmd_buffer->state.subpass;
@@ -1073,8 +1074,15 @@ clear_depth_stencil_attachment(struct anv_cmd_buffer 
*cmd_buffer,
 
/* If multiview is enabled we ignore baseArrayLayer and layerCount */
if (subpass->view_mask) {
+  struct anv_attachment_state *att_state =
+_buffer->state.attachments[att_idx];
+
+  uint32_t clear_mask = is_subpass_load ?
+get_multiview_subpass_clear_mask(_buffer->state, att_state) :
+subpass->view_mask;
+
   uint32_t view_idx;
-  for_each_bit(view_idx, subpass->view_mask) {
+  for_each_bit(view_idx, clear_mask) {
  for (uint32_t r = 0; r < rectCount; ++r) {
 const VkOffset2D offset = pRects[r].rect.offset;
 const VkExtent2D extent = pRects[r].rect.extent;
@@ -1088,6 +1096,9 @@ clear_depth_stencil_attachment(struct anv_cmd_buffer 
*cmd_buffer,
 false, color_value,
 clear_depth, value.depth,
 clear_stencil ? 0xff : 0, value.stencil);
+
+if (is_subpass_load)
+   att_state->pending_clear_views &= ~(1 << view_idx);
  }
   }
   return;
@@ -1135,7 +1146,7 @@ void anv_CmdClearAttachments(
   } else {
  clear_depth_stencil_attachment(cmd_buffer, ,
 [a],
-rectCount, pRects);
+rectCount, pRects, false);
   }
}
 
@@ -1433,7 +1444,7 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
 
   if (!clear_with_hiz) {
  clear_depth_stencil_attachment(cmd_buffer, ,
-_att, 1, _rect);
+_att, 1, _rect, true);
   }
 
   cmd_state->attachments[ds].pending_clear_aspects = 0;
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 3/3] anv/blorp: do not clear with hiz if we have more than one layer

[Iago Toral Quiroga]

blorp_gen8_hiz_clear_attachments only clears the first layer.

v2:
  - do this in all cases, not just when multiview is involved.
  - rebased on top of fast-clear rework.
---
 src/intel/vulkan/anv_blorp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 25035909b6..ab5fefff9d 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -1409,6 +1409,9 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
 * not support this feature at all.
 */
clear_with_hiz = false;
+} else if (clear_rect.layerCount > 1 ||
+   (is_multiview && cmd_state->subpass->view_mask != 1)) {
+   clear_with_hiz = false;
 }
  }
 
-- 
2.14.1

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

[Mesa-dev] [PATCH v2 1/3] anv/blorp: consider multiview and view masks for tracking pending clear aspects

[Iago Toral Quiroga]

When multiview is active a subpass clear may only clear a subset of the
attachment layers. Other subpasses in the same render pass may also
clear too and we want to honor those clears as well, however, we need to
ensure that we only clear a layer once, on the first subpass that uses
a particular layer (view) of a given attachment.

This means that when we check if a subpass attachment needs to be cleared
we need to check if all the layers used by that subpass (as indicated by
its view_mask) have already been cleared in previous subpasses or not, in
which case, we must clear any pending layers used by the subpass, and only
those pending.

v2:
  - track pending clear views in the attachment state (Jason)
  - rebased on top of fast-clear rework.

Fixes:
dEQP-VK.multiview.readback_implicit_clear.*
---
 src/intel/vulkan/anv_blorp.c   | 86 --
 src/intel/vulkan/anv_private.h |  8 
 src/intel/vulkan/genX_cmd_buffer.c |  2 +
 3 files changed, 92 insertions(+), 4 deletions(-)

diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index df566773a4..ac3a434c94 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -963,6 +963,18 @@ binding_table_for_surface_state(struct anv_cmd_buffer 
*cmd_buffer,
return VK_SUCCESS;
 }
 
+/**
+ * This ANDs the view mask of the current subpass with the pending clear
+ * views in the attachment to get the mask of views active in the subpass
+ * that still need to be cleared.
+ */
+static inline uint32_t
+get_multiview_subpass_clear_mask(const struct anv_cmd_state *cmd_state,
+ const struct anv_attachment_state *att_state)
+{
+   return cmd_state->subpass->view_mask & att_state->pending_clear_views;
+}
+
 static void
 clear_color_attachment(struct anv_cmd_buffer *cmd_buffer,
struct blorp_batch *batch,
@@ -1162,13 +1174,25 @@ subpass_needs_clear(const struct anv_cmd_buffer 
*cmd_buffer)
return false;
 }
 
+static inline bool
+do_first_layer_clear(const struct anv_cmd_state *cmd_state,
+ const struct anv_attachment_state *att_state)
+{
+   if (!cmd_state->subpass->view_mask)
+  return true;
+
+   uint32_t pending_clear_mask =
+  get_multiview_subpass_clear_mask(cmd_state, att_state);
+
+   return pending_clear_mask & 1;
+}
+
 void
 anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer *cmd_buffer)
 {
const struct anv_cmd_state *cmd_state = _buffer->state;
const VkRect2D render_area = cmd_buffer->state.render_area;
 
-
if (!subpass_needs_clear(cmd_buffer))
   return;
 
@@ -1185,6 +1209,8 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
   .layerCount = cmd_buffer->state.framebuffer->layers,
};
 
+   bool is_multiview = cmd_state->subpass->view_mask;
+
struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
for (uint32_t i = 0; i < cmd_state->subpass->color_count; ++i) {
   const uint32_t a = cmd_state->subpass->color_attachments[i].attachment;
@@ -1209,7 +1235,7 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
   uint32_t base_layer = iview->planes[0].isl.base_array_layer;
   uint32_t layer_count = fb->layers;
 
-  if (att_state->fast_clear) {
+  if (att_state->fast_clear && do_first_layer_clear(cmd_state, att_state)) 
{
  surf.clear_color = vk_to_isl_color(att_state->clear_value.color);
 
  /* From the Sky Lake PRM Vol. 7, "Render Target Fast Clear":
@@ -1242,12 +1268,48 @@ anv_cmd_buffer_clear_subpass(struct anv_cmd_buffer 
*cmd_buffer)
   render_area.offset.y + render_area.extent.height);
  base_layer++;
  layer_count--;
+ if (is_multiview)
+att_state->pending_clear_views &= ~1;
 
  cmd_buffer->state.pending_pipe_bits |=
 ANV_PIPE_RENDER_TARGET_CACHE_FLUSH_BIT | ANV_PIPE_CS_STALL_BIT;
   }
 
-  if (layer_count > 0) {
+  /* From the VkFramebufferCreateInfo spec:
+   *
+   * "If the render pass uses multiview, then layers must be one and each
+   *  attachment requires a number of layers that is greater than the
+   *  maximum bit index set in the view mask in the subpasses in which it
+   *  is used."
+   *
+   * So if multiview is active we ignore the number of layers in the
+   * framebuffer and instead we honor the view mask from the subpass.
+   */
+  if (is_multiview) {
+ assert(image->n_planes == 1);
+ uint32_t pending_clear_mask =
+get_multiview_subpass_clear_mask(cmd_state, att_state);
+
+ uint32_t layer_idx;
+ for_each_bit(layer_idx, pending_clear_mask) {
+uint32_t layer = iview->planes[0].isl.base_array_layer + layer_idx;
+anv_cmd_buffer_mark_image_written(cmd_buffer, image,
+  VK_IMAGE_ASPECT_COLOR_BIT,
+  

Re: [Mesa-dev] [PATCH 10/11] egl/x11: Support DRI3 v1.1

[Daniel Stone]

Hi,

On 15 February 2018 at 22:44, Jason Ekstrand  wrote:
> On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone  wrote:
>> +   draw->ext->image->queryDmaBufModifiers(draw->dri_screen, format,
>> +  supported_modifiers_count,
>> +  supported_modifiers, NULL,
>> +  _modifiers_count);
>> +
>> +   for (i = 0; i < supported_modifiers_count; i++) {
>> +  for (j = 0; j < count; j++) {
>> + if (supported_modifiers[i] == modifiers[j]) {
>> +free(supported_modifiers);
>> +return true;
>> + }
>> +  }
>> +   }
>> +
>> +   free(supported_modifiers);
>> +   return false;
>
>
> We could make the cleanup path a bit nicer if we did something like this:
>
> bool found = false;
> for (...) {
>if (...) {
>   found = true;
>   break;
>}
> }
>
> free(...);
> return found;
>
> That would mean we only have one free.  I don't really care all that much
> though as the current code is correct.

Seems an obvious and good cleanup.

>> + if (mod_reply->num_drawable_modifiers) {
>> +count = mod_reply->num_drawable_modifiers;
>> +modifiers = malloc(count * sizeof(uint64_t));
>> +if (!modifiers) {
>> +   free(mod_reply);
>> +   goto no_image;
>> +}
>> +
>> +memcpy(modifiers,
>> +
>> xcb_dri3_get_supported_modifiers_drawable_modifiers(mod_reply),
>> +   count * sizeof(uint64_t));
>
>
> Dumb question, but why do we need to memcpy?  Can't we just pass these
> directly into createImageWithModifiers so long as we don't free mod_reply
> until after it returns?

Let me see if I can make that work without making the cleanup too
finicky. If so, no problem.

>> +#if XCB_DRI3_MAJOR_VERSION > 1 || (XCB_DRI3_MAJOR_VERSION == 1 &&
>> XCB_DRI3_MINOR_VERSION >= 1)
>> +   if (draw->multiplanes_available &&
>> +   buffer->modifier != DRM_FORMAT_MOD_INVALID) {
>
> I made a similar comment on the Wayland one but buffer->modifier != INVALID
> should imply multiplanes_available.  We should make multiplanes_available an
> assert.

I don't think that's true. If your winsys is not modifier-aware but
your driver is, you could, e.g., have !draw->multiplanes_available but
buffer->modifier == DRM_FORMAT_I915_MOD_X_TILED.

>> +#if XCB_DRI3_MAJOR_VERSION > 1 || (XCB_DRI3_MAJOR_VERSION == 1 &&
>> XCB_DRI3_MINOR_VERSION >= 1)
>> +   if (draw->multiplanes_available &&
>> +   draw->ext->image->base.version >= 15 &&
>> +   draw->ext->image->createImageFromDmaBufs2) {
>> +  xcb_dri3_buffers_from_pixmap_cookie_t bps_cookie;
>> +  xcb_dri3_buffers_from_pixmap_reply_t *bps_reply;
>> +
>> +  bps_cookie = xcb_dri3_buffers_from_pixmap(draw->conn, pixmap);
>> +  bps_reply = xcb_dri3_buffers_from_pixmap_reply(draw->conn,
>> bps_cookie,
>> + NULL);
>> +  if (!bps_reply)
>> + goto no_image;
>> +  buffer->image =
>> + loader_dri3_create_image_from_buffers(draw->conn, bps_reply,
>> format,
>> +   draw->dri_screen,
>> +   draw->ext->image,
>> +   buffer);
>> +  width = bps_reply->width;
>> +  height = bps_reply->height;
>> +  free(bps_reply);
>> +   } else
>> +#endif
>
>
> I really don't like mising preprocessor and C control-flow like this.  I
> made a suggestion on the previous version.  If there's nothing better to do,
> then I can live with it.

That's going to go before we land it. The #ifdefs are mainly there now
so that people can have these patches in their tree but not have a
hard-fail when they build without the experimental proto. When it
lands we'll just up the build deps.

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

Re: [Mesa-dev] [PATCH] r600/sb: fix rotated register in while loop (attempt 2)

[Gert Wollny]

Am Freitag, den 16.02.2018, 14:44 +1000 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> A bunch of CTS tests led me to write
> tests/shaders/ssa/fs-while-loop-rotate-value.shader_test
> which r600/sb always fell over on.
> 
> GCM seems to move some of the copys into other basic blocks,
> if we don't allow this to happen then it doesn't seem to schedule
> them badly.
> 
> Everything I've read on SSA/phi copies say they have to happen
> in parallel, so keeping them in the same basic block seems like
> a good way to keep some of that property.


This one fixes fs-while-loop-rotate-value for me (barts) as promised,
no longer fixes 

   spec/arb_enhanced_layouts/execution/component-layout/
sso-vs-gs-fs-array-interleave

 but breaks  

   spec/glsl-1.50/execution/variable-indexing/
vs-output-array-vec2-index-wr-before-gs


I don't know whether this is helpful, but when I apply a patch to TGSI
split arrays [1], this piglit also passes with your patch.
Specifically, since the loops are completely unrolled no indirect
access is happening and all arrays can be split. As a result, when
using plain master the shaders optimised by sb and when using your
patch on top of the array splitting are very similar (mostly
differently ordered literals and register indices), however, running 
master + this patch results in very different optimised shaders, e.g.
sb bundles many vfetch operations at the beginning.

Best, 
Gert 



[1] https://patchwork.freedesktop.org/series/37991/

> 
> Signed-off-by: Dave Airlie 
> ---
>  src/gallium/drivers/r600/sb/sb_shader.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp
> b/src/gallium/drivers/r600/sb/sb_shader.cpp
> index 321e24ea25..8959b8391d 100644
> --- a/src/gallium/drivers/r600/sb/sb_shader.cpp
> +++ b/src/gallium/drivers/r600/sb/sb_shader.cpp
> @@ -121,7 +121,7 @@ alu_node* shader::create_copy_mov(value* dst,
> value* src, unsigned affcost) {
>   alu_node *n = create_mov(dst, src);
>  
>   dst->assign_source(src);
> - n->flags |= NF_COPY_MOV | NF_DONT_HOIST;
> + n->flags |= NF_COPY_MOV | NF_DONT_HOIST | NF_DONT_MOVE;
>  
>   if (affcost && dst->is_sgpr() && src->is_sgpr())
>   coal.add_edge(src, dst, affcost);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105098] [RADV] GPU freeze with simple Vulkan App

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Bas Nieuwenhuizen  ---
Thanks, the fix is in git master now.

wrt dxvk, if you still have issues after the patch, could you open a new bug
with more details?

-- 
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 09/11] vulkan/wsi: Return VK_SUBOPTIMAL_KHR for X11

[Daniel Stone]

On 15 February 2018 at 21:38, Jason Ekstrand  wrote:
> On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone  wrote:
>> @@ -138,7 +140,7 @@ wsi_x11_connection_create(const VkAllocationCallbacks
>> *alloc,
>>return NULL;
>>
>> dri3_cookie = xcb_query_extension(conn, 4, "DRI3");
>> -   pres_cookie = xcb_query_extension(conn, 7, "PRESENT");
>> +   pres_cookie = xcb_query_extension(conn, 7, "Present");
>
>
> This seems a bit odd.  Did we just not use it before?  Looking through
> things, it appears we didn't.

Yep, I had to do a double take as well, but I checked it and it is correct.

>> @@ -699,6 +717,10 @@ x11_handle_dri3_present_event(struct x11_swapchain
>> *chain,
>>xcb_present_complete_notify_event_t *complete = (void *) event;
>>if (complete->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
>>   chain->last_present_msc = complete->msc;
>> +#if XCB_PRESENT_MAJOR_VERSION > 1 || XCB_PRESENT_MINOR_VERSION >= 1
>> +  if (complete->mode == XCB_PRESENT_COMPLETE_MODE_SUBOPTIMAL_COPY)
>> + chain->suboptimal = true;
>
> I think I like the approach taken in GLX better.  Here, we'll properly
> reallocate when we go from not flipping to flipping but, what happens if we
> stop flipping?  In that case, we can do better if we reallocate again.

Sure, I'm happy to try to do the same here and send out v11 later.

> Also, I find "chain->suboptimal" and "chain->realloc_suboptimal" to be very
> confusing.  chain->suboptimal has an obvious meaning but the other doesn't.
> At the very least we need better documentation as to what they mean.

Yeah, I think a rename could help clarify. Maybe renaming
realloc_suboptimal to suboptimal_armed or something? It's effectively
should_we_tell_the_user_if_its_suboptimal_or_no: since the WSI spec is
very clear that returning SUBOPTIMAL from QueuePresent means the
client should reallocate, we try to avoid returning that constantly
for the cases where we _can't_ allocate optimally.

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

Re: [Mesa-dev] [PATCH 03/11] vulkan/wsi: Add modifiers support to wsi_create_native_image

[Daniel Stone]

Hi,

On 15 February 2018 at 19:46, Jason Ekstrand  wrote:
> On Thu, Feb 15, 2018 at 7:57 AM, Daniel Stone  wrote:
>> +  image_modifier_count = 0;
>> +  for (uint32_t l = 0; l < num_modifier_lists; l++) {
>> + /* Walk the modifier lists and construct a list of supported
>> +  * modifiers.
>> +  */
>> + for (uint32_t i = 0; i < num_modifiers[l]; i++) {
>> +for (uint32_t j = 0; j < modifier_prop_count; j++) {
>> +   if (modifier_props[j].modifier == modifiers[l][i])
>> +  image_modifiers[image_modifier_count++] =
>> modifiers[l][i];
>> +}
>> + }
>
> I know I technically wrote this code, but I'm having a bit of trouble
> understanding why it's needed.  Are we expecting that the scanout set may
> not have any supported modifiers in it?  The 3D driver can render to a lot
> of things so that's very unlikely.  At least on Intel, LINEAR and X will
> always be there and we can definitely render to those.

The textbook example is i.MX6 where the Vivante GPU can only render to
tiled, and the Freescale display controller can only scan out linear.
You need a separate IP block to blit and convert. They did finally fix
this in i.MX6QP, but there are (for better or worse) an infinite
number of i.MX6S/DL/D/Q in the wild.

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

[Mesa-dev] [PATCH v2] i965: Fix aux-surface size check

[Daniel Stone]

The previous commit reworked the checks intel_from_planar() to check the
right individual cases for regular/planar/aux buffers, and do size
checks in all cases.

Unfortunately, the aux size check was broken, and required the aux
surface to be allocated with the correct aux stride, but full image
height (!).

As the ISL aux surface is not recorded in the DRIimage, we cannot easily
access it to check. Instead, store the aux size from when we do have the
ISL surface to hand, and check against that later when we go to access
the aux surface.

Signed-off-by: Daniel Stone 
Fixes: c2c4e5bae3ba ("i965: Fix bugs in intel_from_planar")
Cc: Jason Ekstrand 
---
 src/mesa/drivers/dri/i965/intel_image.h  |  3 +++
 src/mesa/drivers/dri/i965/intel_screen.c | 12 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_image.h 
b/src/mesa/drivers/dri/i965/intel_image.h
index 78d689a11a3..a8193c6def9 100644
--- a/src/mesa/drivers/dri/i965/intel_image.h
+++ b/src/mesa/drivers/dri/i965/intel_image.h
@@ -98,6 +98,9 @@ struct __DRIimageRec {
/** Pitch of the auxiliary compression surface. */
uint32_t aux_pitch;
 
+   /** Total size in bytes of the auxiliary compression surface. */
+   uint32_t aux_size;
+
/**
 * Provided by EGL_EXT_image_dma_buf_import.
 * \{
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index cc9b3486743..768634d92e0 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -750,6 +750,7 @@ intel_create_image_common(__DRIscreen *dri_screen,
if (aux_surf.size) {
   image->aux_offset = surf.size;
   image->aux_pitch = aux_surf.row_pitch;
+  image->aux_size = aux_surf.size;
}
 
return image;
@@ -1137,6 +1138,8 @@ intel_create_image_from_fds_common(__DRIscreen 
*dri_screen,
  return NULL;
   }
 
+  image->aux_size = aux_surf.size;
+
   const int end = image->aux_offset + aux_surf.size;
   if (size < end)
  size = end;
@@ -1312,7 +1315,7 @@ intel_query_dma_buf_modifiers(__DRIscreen *_screen, int 
fourcc, int max,
 static __DRIimage *
 intel_from_planar(__DRIimage *parent, int plane, void *loaderPrivate)
 {
-int width, height, offset, stride, dri_format;
+int width, height, offset, stride, size, dri_format;
 __DRIimage *image;
 
 if (parent == NULL)
@@ -1331,24 +1334,27 @@ intel_from_planar(__DRIimage *parent, int plane, void 
*loaderPrivate)
int index = f->planes[plane].buffer_index;
offset = parent->offsets[index];
stride = parent->strides[index];
+   size = height * stride;
 } else if (plane == 0) {
/* The only plane of a non-planar image: copy the parent definition
 * directly. */
dri_format = parent->dri_format;
offset = parent->offset;
stride = parent->pitch;
+   size = height * stride;
 } else if (plane == 1 && parent->modifier != DRM_FORMAT_MOD_INVALID &&
isl_drm_modifier_has_aux(parent->modifier)) {
/* Auxiliary plane */
dri_format = parent->dri_format;
offset = parent->aux_offset;
stride = parent->aux_pitch;
+   size = parent->aux_size;
 } else {
return NULL;
 }
 
-if (offset + height * stride > parent->bo->size) {
-   _mesa_warning(NULL, "intel_create_sub_image: subimage out of bounds");
+if (offset + size > parent->bo->size) {
+   _mesa_warning(NULL, "intel_from_planar: subimage out of bounds");
return NULL;
 }
 
-- 
2.14.3

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

Re: [Mesa-dev] [Mesa-announce] [ANNOUNCE] mesa 17.3.4

[Emil Velikov]

On 16 February 2018 at 09:31, Juan A. Suarez Romero  wrote:
> On Thu, 2018-02-15 at 12:56 +, Emil Velikov wrote:
>> Mesa 17.3.4 is now available.
>>
>> In this release we have:
>>
>> Dozens of fixes in the i965, ANV and RADV drivers. Additionally
>> the r600, virgl, etnaviv and renderonly drivers have also seen some love.
>>
>> The experimental Vulkan extension VK_KHX_multiview was disabled.
>>
>> On the video decoding drivers side:
>> r600/radeonsi correctly handle new UVD/VCN firmware. The VA and OMX
>> state-trackers have some MPEG2 glitches resolved, while locking is correctly
>> handled in the error paths.
>>
>> To top it up, the libGL module should build fine on non-dri and Darwin 
>> systems.
>
> In the pre-announcement, two patches were rejected due causing
> regressions in piglit tests:
>
> e52a9f18d69c94b7cb7f81361cdb9e2582c3d742 i965: Replace
> draw_aux_buffer_disabled with draw_aux_usage
> 20f70ae3858bc213e052a8434f0e637eb36203c4 i965/draw: Set NEW_AUX_STATE
> when draw aux changes
>
>
> But in the final release, seems they weren't added in the cherry-
> ignore, nor included in the release.
>
In cases where the patch should address specific issue: be that bug or
a test - I try to be less trigger happy on the cherry-ignore.
It saves for having to remember cases like

7295b97d61104e971aa925c2370e3f3cbb23a408
a094314340387ef2463ed8b4ddc9317bc539832b


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

Re: [Mesa-dev] [PATCH v2] radv: compact varyings after removing unused ones

[Samuel Pitoiset]

Vega stats should be:

Totals from affected shaders:
SGPRS: 106088 -> 106232 (0.14 %)
VGPRS: 74652 -> 74700 (0.06 %)
Spilled SGPRs: 692 -> 658 (-4.91 %)
Code Size: 2967708 -> 2953028 (-0.49 %) bytes
Max Waves: 18178 -> 18162 (-0.09 %)

My local override family was wrong because I have plugged my polaris10 
yesterday. :)


On 02/16/2018 10:28 AM, Samuel Pitoiset wrote:

It makes no sense to compact before, and the description of
nir_compact_varyings() confirms that.

Polaris10:
Totals from affected shaders:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

Totals from affected shaders:
Vega10:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

v2: - compact varyings even if no varyings were removed
 - update shader stats (which are better than v1)

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

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 0d1958fc93..88646fda2f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1524,6 +1524,9 @@ radv_link_shaders(struct radv_pipeline *pipeline, 
nir_shader **shaders)
bool progress = nir_remove_unused_varyings(ordered_shaders[i],
   ordered_shaders[i - 
1]);
  
+		nir_compact_varyings(ordered_shaders[i],

+ordered_shaders[i - 1], true);
+
if (progress) {
if (nir_lower_global_vars_to_local(ordered_shaders[i])) 
{
radv_lower_indirect_derefs(ordered_shaders[i],
@@ -1722,7 +1725,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
last = i;
}
  
-	int prev = -1;

for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
const VkPipelineShaderStageCreateInfo *stage = pStages[i];
  
@@ -1753,11 +1755,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,

nir_lower_io_to_scalar_early(nir[i], mask);
radv_optimize_nir(nir[i]);
}
-
-   if (prev != -1) {
-   nir_compact_varyings(nir[prev], nir[i], true);
-   }
-   prev = i;
}
  
  	if (nir[MESA_SHADER_TESS_CTRL]) {



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

[Mesa-dev] [PATCH] radv: allow to force family using RADV_FORCE_FAMILY

[Samuel Pitoiset]

Useful for pipeline-db.

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

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 09bb382eeb..98cfd9b58a 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -183,6 +183,37 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
device->memory_properties.memoryTypeCount = type_count;
 }
 
+static void
+radv_handle_env_var_force_family(struct radv_physical_device *device)
+{
+   const char *family = getenv("RADV_FORCE_FAMILY");
+   unsigned i;
+
+   if (!family)
+   return;
+
+   for (i = CHIP_TAHITI; i < CHIP_LAST; i++) {
+   if (!strcmp(family, ac_get_llvm_processor_name(i))) {
+   /* Override family and chip_class. */
+   device->rad_info.family = i;
+
+   if (i >= CHIP_VEGA10)
+   device->rad_info.chip_class = GFX9;
+   else if (i >= CHIP_TONGA)
+   device->rad_info.chip_class = VI;
+   else if (i >= CHIP_BONAIRE)
+   device->rad_info.chip_class = CIK;
+   else
+   device->rad_info.chip_class = SI;
+
+   return;
+   }
+   }
+
+   fprintf(stderr, "radv: Unknown family: %s\n", family);
+   exit(1);
+}
+
 static VkResult
 radv_physical_device_init(struct radv_physical_device *device,
  struct radv_instance *instance,
@@ -226,6 +257,8 @@ radv_physical_device_init(struct radv_physical_device 
*device,
device->local_fd = fd;
device->ws->query_info(device->ws, >rad_info);
 
+   radv_handle_env_var_force_family(device);
+
radv_get_device_name(device->rad_info.family, device->name, 
sizeof(device->name));
 
if (radv_device_get_cache_uuid(device->rad_info.family, 
device->cache_uuid)) {
-- 
2.16.1

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

[Mesa-dev] [Bug 104662] OpenGL 4.5 needs to be active by default instead of using 3.0 by default

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 CC||m...@protonmail.ch

-- 
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 104662] OpenGL 4.5 needs to be active by default instead of using 3.0 by default

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

   Priority|medium  |low
   Severity|normal  |enhancement

--- Comment #6 from mirh  ---
Enhancement severity also exists I mean.

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

[Mesa-dev] [PATCH v2] ac/nir: move ac_declare_lds_as_pointer() outside of the switch

[Samuel Pitoiset]

v2: update conditional

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

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index dc471de977..12f097e2b2 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1068,8 +1068,6 @@ static void create_function(struct radv_shader_context 
*ctx,
set_loc_shader(ctx, AC_UD_VS_LS_TCS_IN_LAYOUT,
   _sgpr_idx, 1);
}
-   if (ctx->options->key.vs.as_ls)
-   ac_declare_lds_as_pointer(>ac);
break;
case MESA_SHADER_TESS_CTRL:
set_vs_specific_input_locs(ctx, stage, has_previous_stage,
@@ -1080,7 +1078,6 @@ static void create_function(struct radv_shader_context 
*ctx,
set_loc_shader(ctx, AC_UD_TCS_OFFCHIP_LAYOUT, _sgpr_idx, 
4);
if (ctx->abi.view_index)
set_loc_shader(ctx, AC_UD_VIEW_INDEX, _sgpr_idx, 
1);
-   ac_declare_lds_as_pointer(>ac);
break;
case MESA_SHADER_TESS_EVAL:
set_loc_shader(ctx, AC_UD_TES_OFFCHIP_LAYOUT, _sgpr_idx, 
1);
@@ -1102,8 +1099,6 @@ static void create_function(struct radv_shader_context 
*ctx,
   _sgpr_idx, 2);
if (ctx->abi.view_index)
set_loc_shader(ctx, AC_UD_VIEW_INDEX, _sgpr_idx, 
1);
-   if (has_previous_stage)
-   ac_declare_lds_as_pointer(>ac);
break;
case MESA_SHADER_FRAGMENT:
if (ctx->shader_info->info.ps.needs_sample_positions) {
@@ -1115,6 +1110,13 @@ static void create_function(struct radv_shader_context 
*ctx,
unreachable("Shader stage not implemented");
}
 
+   if (stage == MESA_SHADER_TESS_CTRL ||
+   (stage == MESA_SHADER_VERTEX && ctx->options->key.vs.as_ls) ||
+   /* GFX9 has the ESGS ring buffer in LDS. */
+   (stage == MESA_SHADER_GEOMETRY && has_previous_stage)) {
+   ac_declare_lds_as_pointer(>ac);
+   }
+
ctx->shader_info->num_user_sgprs = user_sgpr_idx;
 }
 
-- 
2.16.1

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

Re: [Mesa-dev] [Mesa-announce] [ANNOUNCE] mesa 17.3.4

[Juan A. Suarez Romero]

On Thu, 2018-02-15 at 12:56 +, Emil Velikov wrote:
> Mesa 17.3.4 is now available.
> 
> In this release we have:
> 
> Dozens of fixes in the i965, ANV and RADV drivers. Additionally
> the r600, virgl, etnaviv and renderonly drivers have also seen some love.
> 
> The experimental Vulkan extension VK_KHX_multiview was disabled.
> 
> On the video decoding drivers side:
> r600/radeonsi correctly handle new UVD/VCN firmware. The VA and OMX
> state-trackers have some MPEG2 glitches resolved, while locking is correctly
> handled in the error paths.
> 
> To top it up, the libGL module should build fine on non-dri and Darwin 
> systems.

In the pre-announcement, two patches were rejected due causing
regressions in piglit tests:

e52a9f18d69c94b7cb7f81361cdb9e2582c3d742 i965: Replace
draw_aux_buffer_disabled with draw_aux_usage
20f70ae3858bc213e052a8434f0e637eb36203c4 i965/draw: Set NEW_AUX_STATE
when draw aux changes


But in the final release, seems they weren't added in the cherry-
ignore, nor included in the release.


Is this a mistake, and they should have been added in cherry-ignore?


J.A.

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

[Mesa-dev] [PATCH v2] radv: compact varyings after removing unused ones

[Samuel Pitoiset]

It makes no sense to compact before, and the description of
nir_compact_varyings() confirms that.

Polaris10:
Totals from affected shaders:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

Totals from affected shaders:
Vega10:
SGPRS: 108528 -> 108128 (-0.37 %)
VGPRS: 74548 -> 74500 (-0.06 %)
Spilled SGPRs: 844 -> 814 (-3.55 %)
Code Size: 3007328 -> 2992932 (-0.48 %) bytes
Max Waves: 16019 -> 16009 (-0.06 %)

v2: - compact varyings even if no varyings were removed
- update shader stats (which are better than v1)

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

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 0d1958fc93..88646fda2f 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1524,6 +1524,9 @@ radv_link_shaders(struct radv_pipeline *pipeline, 
nir_shader **shaders)
bool progress = nir_remove_unused_varyings(ordered_shaders[i],
   ordered_shaders[i - 
1]);
 
+   nir_compact_varyings(ordered_shaders[i],
+ordered_shaders[i - 1], true);
+
if (progress) {
if (nir_lower_global_vars_to_local(ordered_shaders[i])) 
{
radv_lower_indirect_derefs(ordered_shaders[i],
@@ -1722,7 +1725,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
last = i;
}
 
-   int prev = -1;
for (unsigned i = 0; i < MESA_SHADER_STAGES; ++i) {
const VkPipelineShaderStageCreateInfo *stage = pStages[i];
 
@@ -1753,11 +1755,6 @@ void radv_create_shaders(struct radv_pipeline *pipeline,
nir_lower_io_to_scalar_early(nir[i], mask);
radv_optimize_nir(nir[i]);
}
-
-   if (prev != -1) {
-   nir_compact_varyings(nir[prev], nir[i], true);
-   }
-   prev = i;
}
 
if (nir[MESA_SHADER_TESS_CTRL]) {
-- 
2.16.1

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