[Mesa-dev] [PATCH v2] st/nine: skip position checks in SetCursorPosition()

[Andre Heider]

For HW cursors, "cursor.pos" doesn't hold the current position of the
pointer, just the position of the last call to SetCursorPosition().

Skip the check against stale values and bump the d3dadapter9 drm version
to expose this change of behaviour.

Signed-off-by: Andre Heider 
---
V2: don't introduce SetVersion(), bump D3DADAPTER9DRM_MINOR instead

Corresponding d3d9-nine.dll patch:
https://github.com/iXit/wine-nine-standalone/commit/e09fcbbad4efd481833df1123de0cb690e1b2860

 include/d3dadapter/drm.h  | 7 +--
 src/gallium/state_trackers/nine/device9.c | 8 +---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/include/d3dadapter/drm.h b/include/d3dadapter/drm.h
index 647f017fc7f..210e2395669 100644
--- a/include/d3dadapter/drm.h
+++ b/include/d3dadapter/drm.h
@@ -29,11 +29,14 @@
 #define D3DADAPTER9DRM_NAME "drm"
 /* current version */
 #define D3DADAPTER9DRM_MAJOR 0
-#define D3DADAPTER9DRM_MINOR 1
+#define D3DADAPTER9DRM_MINOR 2
 
 /* version 0.0: Initial release
  * 0.1: All IDirect3D objects can be assumed to have a pointer to the
- *  internal vtable in second position of the structure */
+ *  internal vtable in second position of the structure
+ * 0.2: IDirect3DDevice9_SetCursorPosition doesn't check the cursor
+ *  position anymore
+ */
 
 struct D3DAdapter9DRM
 {
diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c
index db1c3a1d23d..0b1fe59cb70 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -793,9 +793,11 @@ NineDevice9_SetCursorPosition( struct NineDevice9 *This,
 
 DBG("This=%p X=%d Y=%d Flags=%d\n", This, X, Y, Flags);
 
-if (This->cursor.pos.x == X &&
-This->cursor.pos.y == Y)
-return;
+/* present >= v1.4 handles this itself */
+if (This->minor_version_num < 4) {
+if (This->cursor.pos.x == X && This->cursor.pos.y == Y)
+return;
+}
 
 This->cursor.pos.x = X;
 This->cursor.pos.y = Y;
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/2] ac/nir: fix nir_op_b2f16

[Samuel Pitoiset]

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

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 6739551ca26..8510be5dfe6 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -322,10 +322,16 @@ static LLVMValueRef emit_b2f(struct ac_llvm_context *ctx,
   "");
result = LLVMBuildBitCast(ctx->builder, result, ctx->f32, "");
 
-   if (bitsize == 32)
+   switch (bitsize) {
+   case 16:
+   return LLVMBuildFPTrunc(ctx->builder, result, ctx->f16, "");
+   case 32:
return result;
-
-   return LLVMBuildFPExt(ctx->builder, result, ctx->f64, "");
+   case 64:
+   return LLVMBuildFPExt(ctx->builder, result, ctx->f64, "");
+   default:
+   unreachable("Unsupported bit size.");
+   }
 }
 
 static LLVMValueRef emit_f2b(struct ac_llvm_context *ctx,
-- 
2.21.0

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

[Mesa-dev] [PATCH 2/2] ac: add 16-bit support to ac_build_ddxy()

[Samuel Pitoiset]

From: Rhys Perry 

Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_llvm_build.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 54e90288bda..3e3ca5c7fdb 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1862,9 +1862,16 @@ ac_build_ddxy(struct ac_llvm_context *ctx,
  LLVMValueRef val)
 {
unsigned tl_lanes[4], trbl_lanes[4];
+   char name[32], type[8];
LLVMValueRef tl, trbl;
+   LLVMTypeRef result_type;
LLVMValueRef result;
 
+   result_type = ac_to_float_type(ctx, LLVMTypeOf(val));
+
+   if (result_type == ctx->f16)
+   val = LLVMBuildZExt(ctx->builder, val, ctx->i32, "");
+
for (unsigned i = 0; i < 4; ++i) {
tl_lanes[i] = i & mask;
trbl_lanes[i] = (i & mask) + idx;
@@ -1877,14 +1884,19 @@ ac_build_ddxy(struct ac_llvm_context *ctx,
 trbl_lanes[0], trbl_lanes[1],
 trbl_lanes[2], trbl_lanes[3]);
 
-   tl = LLVMBuildBitCast(ctx->builder, tl, ctx->f32, "");
-   trbl = LLVMBuildBitCast(ctx->builder, trbl, ctx->f32, "");
+   if (result_type == ctx->f16) {
+   tl = LLVMBuildTrunc(ctx->builder, tl, ctx->i16, "");
+   trbl = LLVMBuildTrunc(ctx->builder, trbl, ctx->i16, "");
+   }
+
+   tl = LLVMBuildBitCast(ctx->builder, tl, result_type, "");
+   trbl = LLVMBuildBitCast(ctx->builder, trbl, result_type, "");
result = LLVMBuildFSub(ctx->builder, trbl, tl, "");
 
-   result = ac_build_intrinsic(ctx, "llvm.amdgcn.wqm.f32", ctx->f32,
-   &result, 1, 0);
+   ac_build_type_name_for_intr(result_type, type, sizeof(type));
+   snprintf(name, sizeof(name), "llvm.amdgcn.wqm.%s", type);
 
-   return result;
+   return ac_build_intrinsic(ctx, name, result_type, &result, 1, 0);
 }
 
 void
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] radv: enable VK_AMD_gpu_shader_half_float

[Samuel Pitoiset]

On 3/21/19 11:09 AM, Bas Nieuwenhuizen wrote:

Honestly the zero tests is worrying me. This is a pretty big extension
and I have questions like:

to 16-bit loads + 16-bit ALU actually work together or have we been
silently relying on the fact there is always a ZExt cast after and
that did not care about input size?


With the two 16-bit fixes I have just sent, it should be now safe to 
enable it.


VK_KHR_shader_float16_int8 now works too, I'm just waiting for CTS 
bugfixes before enabling it by default.


Can you Rb this one or do you still think it's too fragile?



On Thu, Mar 21, 2019 at 10:03 AM Samuel Pitoiset
 wrote:

Should be safe to enable as all instructions seem to support 16-bit.
Unfortunately, there is no CTS test.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_extensions.py | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 421f8b926ea..23106765c2a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -122,6 +122,7 @@ EXTENSIONS = [
  Extension('VK_EXT_vertex_attribute_divisor',  3, True),
  Extension('VK_AMD_draw_indirect_count',   1, True),
  Extension('VK_AMD_gcn_shader',1, True),
+Extension('VK_AMD_gpu_shader_half_float', 1, 'device->rad_info.chip_class 
>= VI && HAVE_LLVM >= 0x0800'),
  Extension('VK_AMD_rasterization_order',   1, 
'device->has_out_of_order_rast'),
  Extension('VK_AMD_shader_core_properties',1, True),
  Extension('VK_AMD_shader_info',   1, True),
--
2.21.0

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

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

[Mesa-dev] [Bug 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

--- Comment #2 from Andrew Sheldon  ---
Created attachment 143891
  --> https://bugs.freedesktop.org/attachment.cgi?id=143891&action=edit
Dragon Quest XI DXVK renderdoc

-- 
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 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

--- Comment #3 from Andrew Sheldon  ---
Added a renderdoc for the game. And yes, it affects up to current master
(4209a27c61ee4bda2efb63e080bde01545edb2b5).

-- 
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 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

--- Comment #4 from Andrew Sheldon  ---
I should note that I used a version of Mesa with the test patch in #110348
(which I thought might be related), which I forgot to remove. If this is likely
to affect the trace I'll upload a new one (the bug is still evident with or
without the patch).

-- 
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] ac/nir: fix intrinsic names for atomic operations with LLVM 9+

[Samuel Pitoiset]

This fixes the following LLVM error when using RADV_DEBUG=checkir:
Intrinsic name not mangled correctly for type arguments! Should be: 
llvm.amdgcn.buffer.atomic.add.i32
i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.add

The cmpswap operation still uses the old intrinsic.

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

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 6739551ca26..cc819286c65 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct ac_nir_context *ctx,
 static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context *ctx,
   const nir_intrinsic_instr *instr)
 {
-   const char *name;
+   const char *op;
+   char name[64];
LLVMValueRef params[6];
int arg_count = 0;
 
@@ -1696,39 +1697,48 @@ static LLVMValueRef visit_atomic_ssbo(struct 
ac_nir_context *ctx,
 
switch (instr->intrinsic) {
case nir_intrinsic_ssbo_atomic_add:
-   name = "llvm.amdgcn.buffer.atomic.add";
+   op = "add";
break;
case nir_intrinsic_ssbo_atomic_imin:
-   name = "llvm.amdgcn.buffer.atomic.smin";
+   op = "smin";
break;
case nir_intrinsic_ssbo_atomic_umin:
-   name = "llvm.amdgcn.buffer.atomic.umin";
+   op = "umin";
break;
case nir_intrinsic_ssbo_atomic_imax:
-   name = "llvm.amdgcn.buffer.atomic.smax";
+   op = "smax";
break;
case nir_intrinsic_ssbo_atomic_umax:
-   name = "llvm.amdgcn.buffer.atomic.umax";
+   op = "umax";
break;
case nir_intrinsic_ssbo_atomic_and:
-   name = "llvm.amdgcn.buffer.atomic.and";
+   op = "and";
break;
case nir_intrinsic_ssbo_atomic_or:
-   name = "llvm.amdgcn.buffer.atomic.or";
+   op = "or";
break;
case nir_intrinsic_ssbo_atomic_xor:
-   name = "llvm.amdgcn.buffer.atomic.xor";
+   op = "xor";
break;
case nir_intrinsic_ssbo_atomic_exchange:
-   name = "llvm.amdgcn.buffer.atomic.swap";
+   op = "swap";
break;
case nir_intrinsic_ssbo_atomic_comp_swap:
-   name = "llvm.amdgcn.buffer.atomic.cmpswap";
+   op = "cmpswap";
break;
default:
abort();
}
 
+   if (HAVE_LLVM >= 0x900 &&
+   instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
+   snprintf(name, sizeof(name),
+ "llvm.amdgcn.buffer.atomic.%s.i32", op);
+   } else {
+   snprintf(name, sizeof(name),
+"llvm.amdgcn.buffer.atomic.%s", op);
+   }
+
return ac_build_intrinsic(&ctx->ac, name, ctx->ac.i32, params, 
arg_count, 0);
 }
 
-- 
2.21.0

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

[Mesa-dev] [Bug 110261] Segmentation fault when using vulkaninfo on Radeon

[bugzilla-daemon]

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

Denis  changed:

   What|Removed |Added

 CC||denys.kos...@globallogic.co
   ||m

-- 
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 110261] Segmentation fault when using vulkaninfo on Radeon

[bugzilla-daemon]

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

--- Comment #8 from Denis  ---
>/build/vulkan-tools/src/Vulkan-Tools-1.1.102/vulkaninfo/vulkaninfo.c:4504: 
>failed with VK_ERROR_OUT_OF_HOST_MEMORY

Actually that's exactly what I got in "normal" version. I discussed this error
with dev and he said that it couldn't be very critical. So during bisection my
"good" result - was that error, and "bad" - sigfault

>Can you reproduce with a full debug build in gdb and run "bt all"?
sorry for long response. Is this still actual or Kenneth gave needed log?

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

[Mesa-dev] [PATCH] nir/radv: remove restrictions on opt_if_loop_last_continue()

[Timothy Arceri]

When I implemented opt_if_loop_last_continue() I had restricted
this pass from moving other if-statements inside the branch opposite
the continue. At the time it was causing a bunch of spilling in
shader-db for i965.

However Samuel Pitoiset noticed that making this pass more aggressive
significantly improved the performance of Doom on RADV. Below are
the statistics he gathered.

28717 shaders in 14931 tests
Totals:
SGPRS: 1267317 -> 1267549 (0.02 %)
VGPRS: 896876 -> 895920 (-0.11 %)
Spilled SGPRs: 24701 -> 26367 (6.74 %)
Code Size: 48379452 -> 48507880 (0.27 %) bytes
Max Waves: 241159 -> 241190 (0.01 %)

Totals from affected shaders:
SGPRS: 23584 -> 23816 (0.98 %)
VGPRS: 25908 -> 24952 (-3.69 %)
Spilled SGPRs: 503 -> 2169 (331.21 %)
Code Size: 2471392 -> 2599820 (5.20 %) bytes
Max Waves: 586 -> 617 (5.29 %)

The codesize increases is related to Wolfenstein II it seems largely
due to an increase in phis rather than the existing jumps.

This gives +10% FPS with Doom on my Vega56.

Rhys Perry also benchmarked Doom on his VEGA64:

Before: 72.53 FPS
After:  80.77 FPS

v2: disable pass on non-AMD drivers

Reviewed-by: Ian Romanick  (v1)
---
 src/amd/vulkan/radv_shader.c |  2 +-
 src/compiler/nir/nir.h   |  2 +-
 src/compiler/nir/nir_opt_if.c| 87 
 src/freedreno/ir3/ir3_nir.c  |  2 +-
 src/gallium/auxiliary/nir/tgsi_to_nir.c  |  2 +-
 src/gallium/drivers/freedreno/a2xx/ir2_nir.c |  2 +-
 src/gallium/drivers/radeonsi/si_shader_nir.c |  2 +-
 src/intel/compiler/brw_nir.c |  2 +-
 src/mesa/state_tracker/st_glsl_to_nir.cpp|  2 +-
 9 files changed, 61 insertions(+), 42 deletions(-)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index d3d073d1db8..7cde5e728e4 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -158,7 +158,7 @@ radv_optimize_nir(struct nir_shader *shader, bool 
optimize_conservatively,
NIR_PASS(progress, shader, nir_opt_remove_phis);
 NIR_PASS(progress, shader, nir_opt_dce);
 }
-NIR_PASS(progress, shader, nir_opt_if);
+NIR_PASS(progress, shader, nir_opt_if, true);
 NIR_PASS(progress, shader, nir_opt_dead_cf);
 NIR_PASS(progress, shader, nir_opt_cse);
 NIR_PASS(progress, shader, nir_opt_peephole_select, 8, true, 
true);
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index bc72d8f83f5..c1ecf5ad561 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -3434,7 +3434,7 @@ bool nir_opt_gcm(nir_shader *shader, bool value_number);
 
 bool nir_opt_idiv_const(nir_shader *shader, unsigned min_bit_size);
 
-bool nir_opt_if(nir_shader *shader);
+bool nir_opt_if(nir_shader *shader, bool aggressive_last_continue);
 
 bool nir_opt_intrinsics(nir_shader *shader);
 
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 4d3183ed151..065fa83c51c 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -824,47 +824,60 @@ nir_block_ends_in_continue(nir_block *block)
  * The continue should then be removed by nir_opt_trivial_continues() and the
  * loop can potentially be unrolled.
  *
- * Note: do_work_2() is only ever blocks and nested loops. We could also nest
- * other if-statments in the branch which would allow further continues to
- * be removed. However in practice this can result in increased register
- * pressure.
+ * Note: Unless the function param aggressive_last_continue==true do_work_2()
+ * is only ever blocks and nested loops. We avoid nesting other if-statments
+ * in the branch as this can result in increased register pressure, and in
+ * the i965 driver it causes a large amount of spilling in shader-db.
+ * For RADV however nesting these if-statements allows further continues to be
+ * remove and provides a significant FPS boost in Doom, which is why we have
+ * opted for this special bool to enable for more aggresive optimisation.
+ * TODO: The GCM pass solves most of the spilling regressions in i965, if it
+ * is ever enabled we should consider removing the aggressive_last_continue
+ * param.
  */
 static bool
-opt_if_loop_last_continue(nir_loop *loop)
+opt_if_loop_last_continue(nir_loop *loop, bool aggressive_last_continue)
 {
-   /* Get the last if-stament in the loop */
+   nir_if *nif;
+   bool then_ends_in_continue;
+   bool else_ends_in_continue;
+
+   /* Scan the control flow of the loop from the last to the first node
+* looking for an if-statement we can optimise.
+*/
nir_block *last_block = nir_loop_last_block(loop);
nir_cf_node *if_node = nir_cf_node_prev(&last_block->cf_node);
while (if_node) {
-  if (if_node->type == nir_cf_node_if)
- break;
+  if (if_node->type == nir_cf_node_if) {
+ nif = nir_cf_node_as_if(if_node);
+ nir_block *then_block = nir_if_last_t

Re: [Mesa-dev] Move adriconf to mesa repositories

[Emil Velikov]

On Thu, 4 Apr 2019 at 17:25, Jean Hertel  wrote:
>
> From: Emil Velikov 
> Sent: 4th april, 2019 13:08
> >Yes I have interest in a configuration tool, although my vision varies
> >a lot from what adriconf and its predecessor.
>
> I'm super interested and open to hear yours, and other mesa devs, ideas
> on how a good configuration utility should look and behave.
> Feel free to reach over with ideas/suggestions/visions.
> Anything you think could make the current situation better.
>
> >That said, I don't mind if the project migrates under
> >gitlab.fd.o/mesa/ - it would be beneficial to have it close-by.
> >
> >What I would strongly suggest is to add some documentation about patch
> >submission, review process and releasing criteria/process.
>
> I will try to come up with something this weekend regarding
> patch submission, reviews and release criteria.
> As soon as I have some documentation I will come back to you.
>
> Thanks for the feedback on this.
>

Could not find my original notes, but the idea is roughly as follows:
 - introduce a separate (user only?) library - say libmesa-config.so
 - ^^ provides an API to query/set attributes, via numerical tokens
 - any localisation is built on top of ^^ as standalone files

Reasoning:
 - library reused by anyone to make a pretty config tool in their
toolkit and/or language
 - numerical tokens are trivial to handle and cheap - can be
binned/deprecated easily
 - translation lives outside of the driver - the driver doesn't care
about it, so don't bloat
 - translators do not need access to mesa - one less hurdle/obstacle


Hope it makes sense, not sure if coffee has kicked in fully ;-)
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Emil Velikov]

On Fri, 5 Apr 2019 at 14:57, Mathias Fröhlich  wrote:
>
> Hi Emil,
>
> Now that I have been putting together a test case for the the actual use
> I do see some issues with the pbuffer code path. Well - still investigating
> if the test is wrong or the result.
>
Actually I do recall some issues with surfaceless (which is
practically identical to this code) and some (with alpha?) formats.
My memory is pretty flaky - I would suggest trying various configs:
with, w/o alpha, 32/24 etc.

> In the mean time some small comments inline below ...
>
> Mathias
>

> > --- a/src/egl/Android.mk
> > +++ b/src/egl/Android.mk
> > @@ -36,6 +36,7 @@ include $(CLEAR_VARS)
> >  LOCAL_SRC_FILES := \
> >   $(LIBEGL_C_FILES) \
> >   $(dri2_backend_core_FILES) \
> > + drivers/dri2/platform_android.c \
> >   drivers/dri2/platform_android.c
>
> That one duplicates the file.
> The hunk is probably no longer needed?
>
That should have been "platform_device.c" - fixed locally.

> > +   /* Extension requires a PlatformDisplay - the EGLDevice. */
> > +   dev = disp->PlatformDisplay;
> > +   if (_eglDeviceSupports(dev, _EGL_DEVICE_DRM)) {
> > +  if (!disp->Options.ForceSoftware)
>
> if (disp->Options.ForceSoftware)
>
> The '!' in your code appears wrong to me.
>
Indeed it does. Fixed locally.

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

Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+

[Erik Faye-Lund]

On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> This fixes the following LLVM error when using RADV_DEBUG=checkir:
> Intrinsic name not mangled correctly for type arguments! Should be:
> llvm.amdgcn.buffer.atomic.add.i32
> i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.add
> 
> The cmpswap operation still uses the old intrinsic.
> 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 32 +
> ---
>  1 file changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index 6739551ca26..cc819286c65 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
> ac_nir_context *ctx,
>  static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context *ctx,
>const nir_intrinsic_instr
> *instr)
>  {
> - const char *name;
> + const char *op;
> + char name[64];
>   LLVMValueRef params[6];
>   int arg_count = 0;
>  
> @@ -1696,39 +1697,48 @@ static LLVMValueRef visit_atomic_ssbo(struct
> ac_nir_context *ctx,
>  
>   switch (instr->intrinsic) {
>   case nir_intrinsic_ssbo_atomic_add:
> - name = "llvm.amdgcn.buffer.atomic.add";
> + op = "add";
>   break;
>   case nir_intrinsic_ssbo_atomic_imin:
> - name = "llvm.amdgcn.buffer.atomic.smin";
> + op = "smin";
>   break;
>   case nir_intrinsic_ssbo_atomic_umin:
> - name = "llvm.amdgcn.buffer.atomic.umin";
> + op = "umin";
>   break;
>   case nir_intrinsic_ssbo_atomic_imax:
> - name = "llvm.amdgcn.buffer.atomic.smax";
> + op = "smax";
>   break;
>   case nir_intrinsic_ssbo_atomic_umax:
> - name = "llvm.amdgcn.buffer.atomic.umax";
> + op = "umax";
>   break;
>   case nir_intrinsic_ssbo_atomic_and:
> - name = "llvm.amdgcn.buffer.atomic.and";
> + op = "and";
>   break;
>   case nir_intrinsic_ssbo_atomic_or:
> - name = "llvm.amdgcn.buffer.atomic.or";
> + op = "or";
>   break;
>   case nir_intrinsic_ssbo_atomic_xor:
> - name = "llvm.amdgcn.buffer.atomic.xor";
> + op = "xor";
>   break;
>   case nir_intrinsic_ssbo_atomic_exchange:
> - name = "llvm.amdgcn.buffer.atomic.swap";
> + op = "swap";
>   break;
>   case nir_intrinsic_ssbo_atomic_comp_swap:
> - name = "llvm.amdgcn.buffer.atomic.cmpswap";
> + op = "cmpswap";
>   break;
>   default:
>   abort();
>   }
>  
> + if (HAVE_LLVM >= 0x900 &&
> + instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
> + snprintf(name, sizeof(name),
> + "llvm.amdgcn.buffer.atomic.%s.i32", op);

The indention here seems off, compared to the else-case... (tabs vs
spaces?)

> + } else {
> + snprintf(name, sizeof(name),
> +  "llvm.amdgcn.buffer.atomic.%s", op);
> + }
> +
>   return ac_build_intrinsic(&ctx->ac, name, ctx->ac.i32, params,
> arg_count, 0);
>  }
>  

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

Re: [Mesa-dev] [PATCH 1/2] egl: add optional plat_opt to _eglFindDisplay()

[Emil Velikov]

On Thu, 4 Apr 2019 at 18:05, Adam Jackson  wrote:
>
> On Thu, 2019-04-04 at 16:25 +0100, Emil Velikov wrote:
>
> > I'm not a huge fan of this. Yet again the other platform (x11) that uses
> > these has a number of issues, see below for details. Once those are resolved
> > we could try and make this more uniform.
> >
> >  a) spec does not mention if a new (or the existing) EGLDislay should be
> > given for same native_dpy/screen_no combo.
>
> An EGLDisplay maps to an X11 screen. EGL_KHR_platform_x11 says:
>
> > On the X11 platform, an EGLDisplay refers to a specific X11 screen 
> > rather
> > than an X11 display connection.
>
> And EGL 1.5 says (with similar text in EGL_EXT_platform_base):
>
> > Multiple calls made to eglGetPlatformDisplay with the same parameters will
> > return the same EGLDisplay handle.
>
> EGL_KHR_platform_x11 is a little confusing on this point in one of the
> issues, because it says a new display connection is created for
> EGL_DEFAULT_DISPLAY; presumably that's only for the first EGLDisplay
> you create though.
>
> >  b) the implementation has number of issues:
> >  - screen 0 is hardcoded when using DEFAULT_DISPLAY
>
> False, but:
>
> >  - screen is _ignored_ when using !DEFAULT_DISPLAY
>
> true, but easily fixed. We definitely store the screen number in
> disp->Options.Platform in _eglParseX11DisplayAttribList, and then:
>
> > static EGLBoolean
> > dri2_get_xcb_connection(_EGLDriver *drv, _EGLDisplay *disp,
> > struct dri2_egl_display *dri2_dpy)
> > {
> >xcb_screen_iterator_t s;
> >int screen = (uintptr_t)disp->Options.Platform;
> >const char *msg;
> >
> >disp->DriverData = (void *) dri2_dpy;
> >if (disp->PlatformDisplay == NULL) {
> >   dri2_dpy->conn = xcb_connect(NULL, &screen);
> >   dri2_dpy->own_device = true;
>
> If no display was given, we connect however xcb would, and save what it
> decided was the default screen number.
>
> >} else {
> >   Display *dpy = disp->PlatformDisplay;
> >
> >   dri2_dpy->conn = XGetXCBConnection(dpy);
> >   screen = DefaultScreen(dpy);
> >}
>
> If not, we use what the display already had set; this is where we
> ignore the user's screen number and instead use the display's default.
>
> I think the fix is to delete that DefaultScreen line above, and in
> _eglFindDisplay call the appropriate platform's vtable to check for
> identical option lists (this is your _eglSameDeviceDisplay in the next
> patch, just abstracted out a bit).
>
Thanks for having a look Adam.

Can I interest you in writing a fix for the X11 code ;-)
It'll be great if we have inline comments with the spec quotes and
reasoning you mentioned.

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

[Mesa-dev] [Bug 110261] Segmentation fault when using vulkaninfo on Radeon

[bugzilla-daemon]

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

--- Comment #9 from Denis  ---
bt all didn't provide anything, so I did same with Kenneth. Output below:


(gdb) bt all
No symbol "all" in current context.
(gdb) thread apply all backtrace

Thread 2 (Thread 0x76c37700 (LWP 11457)):
#0  0x77bc2afc in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7771d5c7 in cnd_wait (cond=0x5584be30, mtx=0x5584be08) at
../include/c11/threads_posix.h:155
#2  0x7771e0a6 in util_queue_thread_func (input=0x5557ffd0) at
../src/util/u_queue.c:272
#3  0x7771d3f8 in impl_thrd_routine (p=0x55658040) at
../include/c11/threads_posix.h:87
#4  0x77bbca9d in start_thread () from /usr/lib/libpthread.so.0
#5  0x77cfab23 in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x77a2b740 (LWP 11453)):
#0  0x77f780ce in xcb_send_request_with_fds64 () from
/usr/lib/libxcb.so.1
#1  0x77f7866a in xcb_send_request () from /usr/lib/libxcb.so.1
#2  0x77f87405 in xcb_query_extension () from /usr/lib/libxcb.so.1
#3  0x7770a3ce in wsi_x11_connection_create (wsi_dev=0x55600510,
conn=0xa0ec8148e5894855)
at ../src/vulkan/wsi/wsi_common_x11.c:135
#4  0x7770a782 in wsi_x11_get_connection (wsi_dev=0x55600510,
conn=0xa0ec8148e5894855)
at ../src/vulkan/wsi/wsi_common_x11.c:242
#5  0x7770ac90 in x11_surface_get_support (icd_surface=0x5584d3a0,
wsi_device=0x55600510, queueFamilyIndex=0, 
pSupported=0x7fffd8d4) at ../src/vulkan/wsi/wsi_common_x11.c:428
#6  0x77709086 in wsi_common_get_surface_support
(wsi_device=0x55600510, queueFamilyIndex=0, _surface=0x5584d3a0, 
pSupported=0x7fffd8d4) at ../src/vulkan/wsi/wsi_common.c:724
#7  0x7746074e in anv_GetPhysicalDeviceSurfaceSupportKHR
(physicalDevice=0x55600070, queueFamilyIndex=0, 
surface=0x5584d3a0, pSupported=0x7fffd8d4) at
../src/intel/vulkan/anv_wsi.c:91
#8  0x55562693 in ?? ()
#9  0x7f72 in ?? ()
#10 0x77c23223 in __libc_start_main () from /usr/lib/libc.so.6
#11 0x87be in ?? ()

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

Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+

[Samuel Pitoiset]

On 4/8/19 12:32 PM, Erik Faye-Lund wrote:

On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:

This fixes the following LLVM error when using RADV_DEBUG=checkir:
Intrinsic name not mangled correctly for type arguments! Should be:
llvm.amdgcn.buffer.atomic.add.i32
i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.add

The cmpswap operation still uses the old intrinsic.

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

diff --git a/src/amd/common/ac_nir_to_llvm.c
b/src/amd/common/ac_nir_to_llvm.c
index 6739551ca26..cc819286c65 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
ac_nir_context *ctx,
  static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context *ctx,
const nir_intrinsic_instr
*instr)
  {
-   const char *name;
+   const char *op;
+   char name[64];
LLVMValueRef params[6];
int arg_count = 0;
  
@@ -1696,39 +1697,48 @@ static LLVMValueRef visit_atomic_ssbo(struct

ac_nir_context *ctx,
  
  	switch (instr->intrinsic) {

case nir_intrinsic_ssbo_atomic_add:
-   name = "llvm.amdgcn.buffer.atomic.add";
+   op = "add";
break;
case nir_intrinsic_ssbo_atomic_imin:
-   name = "llvm.amdgcn.buffer.atomic.smin";
+   op = "smin";
break;
case nir_intrinsic_ssbo_atomic_umin:
-   name = "llvm.amdgcn.buffer.atomic.umin";
+   op = "umin";
break;
case nir_intrinsic_ssbo_atomic_imax:
-   name = "llvm.amdgcn.buffer.atomic.smax";
+   op = "smax";
break;
case nir_intrinsic_ssbo_atomic_umax:
-   name = "llvm.amdgcn.buffer.atomic.umax";
+   op = "umax";
break;
case nir_intrinsic_ssbo_atomic_and:
-   name = "llvm.amdgcn.buffer.atomic.and";
+   op = "and";
break;
case nir_intrinsic_ssbo_atomic_or:
-   name = "llvm.amdgcn.buffer.atomic.or";
+   op = "or";
break;
case nir_intrinsic_ssbo_atomic_xor:
-   name = "llvm.amdgcn.buffer.atomic.xor";
+   op = "xor";
break;
case nir_intrinsic_ssbo_atomic_exchange:
-   name = "llvm.amdgcn.buffer.atomic.swap";
+   op = "swap";
break;
case nir_intrinsic_ssbo_atomic_comp_swap:
-   name = "llvm.amdgcn.buffer.atomic.cmpswap";
+   op = "cmpswap";
break;
default:
abort();
}
  
+	if (HAVE_LLVM >= 0x900 &&

+   instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
+   snprintf(name, sizeof(name),
+ "llvm.amdgcn.buffer.atomic.%s.i32", op);

The indention here seems off, compared to the else-case... (tabs vs
spaces?)

Will fix before pushing.



+   } else {
+   snprintf(name, sizeof(name),
+"llvm.amdgcn.buffer.atomic.%s", op);
+   }
+
return ac_build_intrinsic(&ctx->ac, name, ctx->ac.i32, params,
arg_count, 0);
  }
  

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

Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+

[Erik Faye-Lund]

On Mon, 2019-04-08 at 12:39 +0200, Samuel Pitoiset wrote:
> On 4/8/19 12:32 PM, Erik Faye-Lund wrote:
> > On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> > > This fixes the following LLVM error when using
> > > RADV_DEBUG=checkir:
> > > Intrinsic name not mangled correctly for type arguments! Should
> > > be:
> > > llvm.amdgcn.buffer.atomic.add.i32
> > > i32 (i32, <4 x i32>, i32, i32, i1)*
> > > @llvm.amdgcn.buffer.atomic.add
> > > 
> > > The cmpswap operation still uses the old intrinsic.
> > > 
> > > Signed-off-by: Samuel Pitoiset 
> > > ---
> > >   src/amd/common/ac_nir_to_llvm.c | 32 +-
> > > ---
> > > ---
> > >   1 file changed, 21 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/src/amd/common/ac_nir_to_llvm.c
> > > b/src/amd/common/ac_nir_to_llvm.c
> > > index 6739551ca26..cc819286c65 100644
> > > --- a/src/amd/common/ac_nir_to_llvm.c
> > > +++ b/src/amd/common/ac_nir_to_llvm.c
> > > @@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
> > > ac_nir_context *ctx,
> > >   static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context
> > > *ctx,
> > > const nir_intrinsic_instr
> > > *instr)
> > >   {
> > > - const char *name;
> > > + const char *op;
> > > + char name[64];
> > >   LLVMValueRef params[6];
> > >   int arg_count = 0;
> > >   
> > > @@ -1696,39 +1697,48 @@ static LLVMValueRef
> > > visit_atomic_ssbo(struct
> > > ac_nir_context *ctx,
> > >   
> > >   switch (instr->intrinsic) {
> > >   case nir_intrinsic_ssbo_atomic_add:
> > > - name = "llvm.amdgcn.buffer.atomic.add";
> > > + op = "add";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_imin:
> > > - name = "llvm.amdgcn.buffer.atomic.smin";
> > > + op = "smin";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_umin:
> > > - name = "llvm.amdgcn.buffer.atomic.umin";
> > > + op = "umin";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_imax:
> > > - name = "llvm.amdgcn.buffer.atomic.smax";
> > > + op = "smax";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_umax:
> > > - name = "llvm.amdgcn.buffer.atomic.umax";
> > > + op = "umax";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_and:
> > > - name = "llvm.amdgcn.buffer.atomic.and";
> > > + op = "and";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_or:
> > > - name = "llvm.amdgcn.buffer.atomic.or";
> > > + op = "or";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_xor:
> > > - name = "llvm.amdgcn.buffer.atomic.xor";
> > > + op = "xor";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_exchange:
> > > - name = "llvm.amdgcn.buffer.atomic.swap";
> > > + op = "swap";
> > >   break;
> > >   case nir_intrinsic_ssbo_atomic_comp_swap:
> > > - name = "llvm.amdgcn.buffer.atomic.cmpswap";
> > > + op = "cmpswap";
> > >   break;
> > >   default:
> > >   abort();
> > >   }
> > >   
> > > + if (HAVE_LLVM >= 0x900 &&
> > > + instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
> > > + snprintf(name, sizeof(name),
> > > + "llvm.amdgcn.buffer.atomic.%s.i32",
> > > op);
> > The indention here seems off, compared to the else-case... (tabs vs
> > spaces?)
> Will fix before pushing.
> > > + } else {
> > > + snprintf(name, sizeof(name),
> > > +  "llvm.amdgcn.buffer.atomic.%s", op);
> > > + }
> > > +

I'm not an expert on LLVM, but the code changes looks good to me, and
the reasoning makes sense. So if you want:

Reviewed-by: Erik Faye-Lund 


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

Re: [Mesa-dev] [PATCH] ac/nir: fix intrinsic names for atomic operations with LLVM 9+

[Bas Nieuwenhuizen]

r-b

On Mon, Apr 8, 2019 at 12:36 PM Samuel Pitoiset
 wrote:
>
>
> On 4/8/19 12:32 PM, Erik Faye-Lund wrote:
> > On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> >> This fixes the following LLVM error when using RADV_DEBUG=checkir:
> >> Intrinsic name not mangled correctly for type arguments! Should be:
> >> llvm.amdgcn.buffer.atomic.add.i32
> >> i32 (i32, <4 x i32>, i32, i32, i1)* @llvm.amdgcn.buffer.atomic.add
> >>
> >> The cmpswap operation still uses the old intrinsic.
> >>
> >> Signed-off-by: Samuel Pitoiset 
> >> ---
> >>   src/amd/common/ac_nir_to_llvm.c | 32 +
> >> ---
> >>   1 file changed, 21 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/src/amd/common/ac_nir_to_llvm.c
> >> b/src/amd/common/ac_nir_to_llvm.c
> >> index 6739551ca26..cc819286c65 100644
> >> --- a/src/amd/common/ac_nir_to_llvm.c
> >> +++ b/src/amd/common/ac_nir_to_llvm.c
> >> @@ -1679,7 +1679,8 @@ static void visit_store_ssbo(struct
> >> ac_nir_context *ctx,
> >>   static LLVMValueRef visit_atomic_ssbo(struct ac_nir_context *ctx,
> >> const nir_intrinsic_instr
> >> *instr)
> >>   {
> >> -const char *name;
> >> +const char *op;
> >> +char name[64];
> >>  LLVMValueRef params[6];
> >>  int arg_count = 0;
> >>
> >> @@ -1696,39 +1697,48 @@ static LLVMValueRef visit_atomic_ssbo(struct
> >> ac_nir_context *ctx,
> >>
> >>  switch (instr->intrinsic) {
> >>  case nir_intrinsic_ssbo_atomic_add:
> >> -name = "llvm.amdgcn.buffer.atomic.add";
> >> +op = "add";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_imin:
> >> -name = "llvm.amdgcn.buffer.atomic.smin";
> >> +op = "smin";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_umin:
> >> -name = "llvm.amdgcn.buffer.atomic.umin";
> >> +op = "umin";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_imax:
> >> -name = "llvm.amdgcn.buffer.atomic.smax";
> >> +op = "smax";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_umax:
> >> -name = "llvm.amdgcn.buffer.atomic.umax";
> >> +op = "umax";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_and:
> >> -name = "llvm.amdgcn.buffer.atomic.and";
> >> +op = "and";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_or:
> >> -name = "llvm.amdgcn.buffer.atomic.or";
> >> +op = "or";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_xor:
> >> -name = "llvm.amdgcn.buffer.atomic.xor";
> >> +op = "xor";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_exchange:
> >> -name = "llvm.amdgcn.buffer.atomic.swap";
> >> +op = "swap";
> >>  break;
> >>  case nir_intrinsic_ssbo_atomic_comp_swap:
> >> -name = "llvm.amdgcn.buffer.atomic.cmpswap";
> >> +op = "cmpswap";
> >>  break;
> >>  default:
> >>  abort();
> >>  }
> >>
> >> +if (HAVE_LLVM >= 0x900 &&
> >> +instr->intrinsic != nir_intrinsic_ssbo_atomic_comp_swap) {
> >> +snprintf(name, sizeof(name),
> >> + "llvm.amdgcn.buffer.atomic.%s.i32", op);
> > The indention here seems off, compared to the else-case... (tabs vs
> > spaces?)
> Will fix before pushing.
> >
> >> +} else {
> >> +snprintf(name, sizeof(name),
> >> + "llvm.amdgcn.buffer.atomic.%s", op);
> >> +}
> >> +
> >>  return ac_build_intrinsic(&ctx->ac, name, ctx->ac.i32, params,
> >> arg_count, 0);
> >>   }
> >>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

[Eero Tamminen]

Hi,

On 6.4.2019 11.44, Khaled Emara wrote:

Sorry, I though LTS distros used old versions of mesa.
Got it.


Those *provide* older Mesa version, so naturally people want to build
latest Mesa on them (especially if they've just bought HW that isn't
supported by distro version of Mesa).  Building would fail if Mesa would
require newer Meson version than the one in the distro.


- Eero

PS. On Ubuntu 18.04 LTS, one can install 0.47 Meson binary package
from 18.10, it works fine.  Maybe something similar can be done also
on other LTS distros.

On Sat, Apr 6, 2019 at 12:38 AM Dylan Baker > wrote:


Quoting Khaled Emara (2019-04-05 11:28:28)
 > Upgraded meson's minimum version from 0.45 to 0.47
 > Version 0.47 is required to use build_always_stale
 > ---
 >  meson.build | 2 +-
 >  1 file changed, 1 insertion(+), 1 deletion(-)
 >
 > diff --git a/meson.build b/meson.build
 > index 2c98e9e18a9..454928e244a 100644
 > --- a/meson.build
 > +++ b/meson.build
 > @@ -25,7 +25,7 @@ project(
 >      [find_program('python', 'python2', 'python3'),
'bin/meson_get_version.py']
 >    ).stdout(),
 >    license : 'MIT',
 > -  meson_version : '>= 0.45',
 > +  meson_version : '>= 0.47',
 >    default_options : ['buildtype=debugoptimized',
'b_ndebug=if-release', 'c_std=c99', 'cpp_std=c++11']
 >  )
 >
 > --
 > 2.21.0
 >
 > ___
 > mesa-dev mailing list
 > mesa-dev@lists.freedesktop.org

 > https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Unfortunately we can't bump the minimum version at the moment, there
are a
couple of LTS distros we need support for that only ship 0.45.x
currently. As an
upstream meson dev, we have no time table in place for the removal of
build_always.

Dylan


___
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 110261] Segmentation fault when using vulkaninfo on Radeon

[bugzilla-daemon]

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

--- Comment #10 from Jason Ekstrand  ---
Unfortunately, thanks fo Vulkan passing everything as struct pointers, a
backtrack with `bt full` isn't as useful as one would like.  That said, given
where it's crashing, I'm 93% sure that both of those backtraces are due to the
client (vulkaninfo) providing us with a bogus X11 connection/display.

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

Re: [Mesa-dev] [PATCH v2 1/2] nir: Add nir_lower_viewport_transform

[Qiang Yu]

On Mon, Apr 8, 2019 at 12:30 PM Alyssa Rosenzweig  wrote:
>
> On Mali hardware (supported by Panfrost and Lima), the fixed-function
> transformation from world-space to screen-space coordinates is done in
> the vertex shader prior to writing out the gl_Position varying, rather
> than in dedicated hardware. This commit adds a shared NIR pass for
> implementing coordinate transformation and lowering gl_Position writes
> into screen-space gl_Position writes.
>
> v2: Run directly on derefs before io/vars are lowered to cleanup the
> code substantially. Thank you to Qiang for this suggestion!
>
> Signed-off-by: Alyssa Rosenzweig 
> Suggested-by: Qiang Yu 
> Cc: Jason Ekstrand 
> Cc: Eric Anholt 
> ---
>  src/compiler/nir/meson.build  |  1 +
>  src/compiler/nir/nir.h|  1 +
>  .../nir/nir_lower_viewport_transform.c| 98 +++
>  3 files changed, 100 insertions(+)
>  create mode 100644 src/compiler/nir/nir_lower_viewport_transform.c
>
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index c65f2ff62ff..c274361bdc4 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -151,6 +151,7 @@ files_libnir = files(
>'nir_lower_vars_to_ssa.c',
>'nir_lower_var_copies.c',
>'nir_lower_vec_to_movs.c',
> +  'nir_lower_viewport_transform.c',
>'nir_lower_wpos_center.c',
>'nir_lower_wpos_ytransform.c',
>'nir_lower_bit_size.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index bc72d8f83f5..0f6ed734efa 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3124,6 +3124,7 @@ void nir_lower_io_to_scalar(nir_shader *shader, 
> nir_variable_mode mask);
>  void nir_lower_io_to_scalar_early(nir_shader *shader, nir_variable_mode 
> mask);
>  bool nir_lower_io_to_vector(nir_shader *shader, nir_variable_mode mask);
>
> +void nir_lower_viewport_transform(nir_shader *shader);
>  bool nir_lower_uniforms_to_ubo(nir_shader *shader, int multiplier);
>
>  typedef struct nir_lower_subgroups_options {
> diff --git a/src/compiler/nir/nir_lower_viewport_transform.c 
> b/src/compiler/nir/nir_lower_viewport_transform.c
> new file mode 100644
> index 000..9646b72c053
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_viewport_transform.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (C) 2019 Alyssa Rosenzweig
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (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 NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +/* On some hardware (particularly, all current versions of Mali GPUs),
> + * vertex shaders do not output gl_Position in world-space. Instead, they
> + * output gl_Position in transformed screen space via the "pseudo"
> + * position varying. Thus, this pass finds writes to gl_Position and
> + * changes them to transformed writes, still to gl_Position. The
> + * outputted screen space is still written back to VARYING_SLOT_POS,
> + * which is semantically ambiguous but nevertheless a good match for
> + * Gallium/NIR/Mali.
> + *
> + * Implements coordinate transformation as defined in section 12.5
> + * "Coordinate Transformation" of the OpenGL ES 3.2 full specification.
> + *
> + * This pass must run before lower_vars/lower_io such that derefs are
> + * still in place.
> + */
> +
> +#include "nir/nir.h"
> +#include "nir/nir_builder.h"
> +
> +void
> +nir_lower_viewport_transform(nir_shader *shader)
> +{
> +   assert(shader->info.stage == MESA_SHADER_VERTEX);
> +
> +   nir_foreach_function(func, shader) {
> +  nir_foreach_block(block, func->impl) {
> + nir_foreach_instr_safe(instr, block) {
> +if (instr->type != nir_instr_type_intrinsic) continue;
> +
> +nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
> +if (intr->intrinsic != nir_intrinsic_store_deref) continue;
> +
> +nir_variable *var = nir_intrinsic_get_var(intr, 0);
> +if (v

[Mesa-dev] [PATCH] radv: fix getting the vertex strides if the bindings aren't contiguous

[Samuel Pitoiset]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110349
Fixes: a66b186bebf ("radv: use typed buffer loads for vertex input fetches")
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 83a06226ada..d96ae9a4223 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1827,6 +1827,20 @@ radv_link_shaders(struct radv_pipeline *pipeline, 
nir_shader **shaders)
}
 }
 
+static uint32_t
+radv_get_attrib_stride(const VkPipelineVertexInputStateCreateInfo *input_state,
+  uint32_t attrib_binding)
+{
+   for (uint32_t i = 0; i < input_state->vertexBindingDescriptionCount; 
i++) {
+   const VkVertexInputBindingDescription *input_binding =
+   &input_state->pVertexBindingDescriptions[i];
+
+   if (input_binding->binding == attrib_binding)
+   return input_binding->stride;
+   }
+
+   return 0;
+}
 
 static struct radv_pipeline_key
 radv_generate_graphics_pipeline_key(struct radv_pipeline *pipeline,
@@ -1886,7 +1900,7 @@ radv_generate_graphics_pipeline_key(struct radv_pipeline 
*pipeline,
key.vertex_attribute_formats[location] = data_format | 
(num_format << 4);
key.vertex_attribute_bindings[location] = desc->binding;
key.vertex_attribute_offsets[location] = desc->offset;
-   key.vertex_attribute_strides[location] = 
input_state->pVertexBindingDescriptions[desc->binding].stride;
+   key.vertex_attribute_strides[location] = 
radv_get_attrib_stride(input_state, desc->binding);
 
if (pipeline->device->physical_device->rad_info.chip_class <= 
VI &&
pipeline->device->physical_device->rad_info.family != 
CHIP_STONEY) {
-- 
2.21.0

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

[Mesa-dev] [Bug 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
Can you apply this
https://patchwork.freedesktop.org/patch/297237/?series=59168&rev=1 ?

-- 
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 110291] Vega 64 GPU hang running Space Engineers

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Is this a recent regression?

-- 
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] nir: Add nir_lower_viewport_transform

[Thomas Helland]

man. 8. apr. 2019 kl. 06:30 skrev Alyssa Rosenzweig :
>
> On Mali hardware (supported by Panfrost and Lima), the fixed-function
> transformation from world-space to screen-space coordinates is done in
> the vertex shader prior to writing out the gl_Position varying, rather
> than in dedicated hardware. This commit adds a shared NIR pass for
> implementing coordinate transformation and lowering gl_Position writes
> into screen-space gl_Position writes.
>
> v2: Run directly on derefs before io/vars are lowered to cleanup the
> code substantially. Thank you to Qiang for this suggestion!
>
> Signed-off-by: Alyssa Rosenzweig 
> Suggested-by: Qiang Yu 
> Cc: Jason Ekstrand 
> Cc: Eric Anholt 
> ---
>  src/compiler/nir/meson.build  |  1 +
>  src/compiler/nir/nir.h|  1 +
>  .../nir/nir_lower_viewport_transform.c| 98 +++
>  3 files changed, 100 insertions(+)
>  create mode 100644 src/compiler/nir/nir_lower_viewport_transform.c
>
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index c65f2ff62ff..c274361bdc4 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -151,6 +151,7 @@ files_libnir = files(
>'nir_lower_vars_to_ssa.c',
>'nir_lower_var_copies.c',
>'nir_lower_vec_to_movs.c',
> +  'nir_lower_viewport_transform.c',
>'nir_lower_wpos_center.c',
>'nir_lower_wpos_ytransform.c',
>'nir_lower_bit_size.c',
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index bc72d8f83f5..0f6ed734efa 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -3124,6 +3124,7 @@ void nir_lower_io_to_scalar(nir_shader *shader, 
> nir_variable_mode mask);
>  void nir_lower_io_to_scalar_early(nir_shader *shader, nir_variable_mode 
> mask);
>  bool nir_lower_io_to_vector(nir_shader *shader, nir_variable_mode mask);
>
> +void nir_lower_viewport_transform(nir_shader *shader);
>  bool nir_lower_uniforms_to_ubo(nir_shader *shader, int multiplier);
>
>  typedef struct nir_lower_subgroups_options {
> diff --git a/src/compiler/nir/nir_lower_viewport_transform.c 
> b/src/compiler/nir/nir_lower_viewport_transform.c
> new file mode 100644
> index 000..9646b72c053
> --- /dev/null
> +++ b/src/compiler/nir/nir_lower_viewport_transform.c
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (C) 2019 Alyssa Rosenzweig
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (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 NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +/* On some hardware (particularly, all current versions of Mali GPUs),
> + * vertex shaders do not output gl_Position in world-space. Instead, they
> + * output gl_Position in transformed screen space via the "pseudo"
> + * position varying. Thus, this pass finds writes to gl_Position and
> + * changes them to transformed writes, still to gl_Position. The
> + * outputted screen space is still written back to VARYING_SLOT_POS,
> + * which is semantically ambiguous but nevertheless a good match for
> + * Gallium/NIR/Mali.
> + *
> + * Implements coordinate transformation as defined in section 12.5
> + * "Coordinate Transformation" of the OpenGL ES 3.2 full specification.
> + *
> + * This pass must run before lower_vars/lower_io such that derefs are
> + * still in place.
> + */
> +
> +#include "nir/nir.h"
> +#include "nir/nir_builder.h"
> +
> +void
> +nir_lower_viewport_transform(nir_shader *shader)
> +{
> +   assert(shader->info.stage == MESA_SHADER_VERTEX);
> +
> +   nir_foreach_function(func, shader) {
> +  nir_foreach_block(block, func->impl) {
> + nir_foreach_instr_safe(instr, block) {
> +if (instr->type != nir_instr_type_intrinsic) continue;
> +
> +nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
> +if (intr->intrinsic != nir_intrinsic_store_deref) continue;
> +
> +nir_variable *var = nir_intrinsic_get_var(intr, 0);
> +if (var->

[Mesa-dev] [Bug 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

--- Comment #6 from Andrew Sheldon  ---
(In reply to Samuel Pitoiset from comment #5)
> Can you apply this
> https://patchwork.freedesktop.org/patch/297237/?series=59168&rev=1 ?

The patch fixes the issue, thanks.

-- 
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 110356] install_megadrivers.py creates new dangling symlink [bisected]

[bugzilla-daemon]

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

Bug ID: 110356
   Summary: install_megadrivers.py creates new dangling symlink
[bisected]
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: m...@fireburn.co.uk
QA Contact: mesa-dev@lists.freedesktop.org

Before aa7afe324c2092fb31f9498cb3eda47dda96e6f2

lrwxrwxrwx   1 root root  19 Feb 23 17:02 libvdpau_va_gl.so ->
libvdpau_va_gl.so.1
-rwxr-xr-x   1 root root  126136 Feb 23 17:02 libvdpau_va_gl.so.1
lrwxrwxrwx   1 root root  23 Mar  1 09:30 libvdpau_trace.so.1 ->
libvdpau_trace.so.1.0.0
lrwxrwxrwx   1 root root  23 Mar  1 09:30 libvdpau_trace.so ->
libvdpau_trace.so.1.0.0
-rwxr-xr-x   1 root root   59264 Mar  1 09:30 libvdpau_trace.so.1.0.0
lrwxrwxrwx   1 root root  26 Apr  8 15:23 libvdpau_radeonsi.so.1.0 ->
libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx   1 root root  26 Apr  8 15:23 libvdpau_radeonsi.so.1 ->
libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx   1 root root  26 Apr  8 15:23 libvdpau_radeonsi.so ->
libvdpau_radeonsi.so.1.0.0
-rwxr-xr-x   1 root root 5264216 Apr  8 15:23 libvdpau_radeonsi.so.1.0.0


After aa7afe324c2092fb31f9498cb3eda47dda96e6f2

lrwxrwxrwx   1 root root  19 Feb 23 17:02 libvdpau_va_gl.so ->
libvdpau_va_gl.so.1
-rwxr-xr-x   1 root root  126136 Feb 23 17:02 libvdpau_va_gl.so.1
lrwxrwxrwx   1 root root  23 Mar  1 09:30 libvdpau_trace.so.1 ->
libvdpau_trace.so.1.0.0
lrwxrwxrwx   1 root root  23 Mar  1 09:30 libvdpau_trace.so ->
libvdpau_trace.so.1.0.0
-rwxr-xr-x   1 root root   59264 Mar  1 09:30 libvdpau_trace.so.1.0.0

lrwxrwxrwx   1 root root  25 Apr  8 15:31 libvdpau_gallium.so ->
libvdpau_gallium.so.1.0.0 **

lrwxrwxrwx   1 root root  26 Apr  8 15:31 libvdpau_radeonsi.so.1.0 ->
libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx   1 root root  26 Apr  8 15:31 libvdpau_radeonsi.so.1 ->
libvdpau_radeonsi.so.1.0.0
lrwxrwxrwx   1 root root  26 Apr  8 15:31 libvdpau_radeonsi.so ->
libvdpau_radeonsi.so.1.0.0
-rwxr-xr-x   1 root root 5264216 Apr  8 15:31 libvdpau_radeonsi.so.1.0.0

It seems there is now a link from libvdpau_gallium.so to a non-existent
libvdpau_gallium.so.1.0.0

-- 
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 110350] DOOM 2016 crash + severe artifacting on RADV + Vega VII

[bugzilla-daemon]

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

--- Comment #1 from Samuel Pitoiset  ---
Can you explain the steps for reproducing the problem in-game?

-- 
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] radv: allow secondary command buffers to inherit unknown framebuffers

[Samuel Pitoiset]

What's the status of this patch?

On 12/20/18 8:05 PM, Rhys Perry wrote:

Fixes: f4e499ec79 ('radv: add initial non-conformant radv vulkan driver')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107986
Signed-off-by: Rhys Perry 
---
  src/amd/vulkan/radv_cmd_buffer.c | 59 ++--
  src/amd/vulkan/radv_meta_clear.c |  8 +
  src/amd/vulkan/radv_private.h|  2 ++
  3 files changed, 50 insertions(+), 19 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index c61310f3fc9..96fe5acb3bf 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -730,6 +730,9 @@ radv_emit_rbplus_state(struct radv_cmd_buffer *cmd_buffer)
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
  
+	/* FIXME: handle when the framebuffer is unknown in secondary framebuffers */

+   assert(!cmd_buffer->inherit_unknown_fb);
+
unsigned sx_ps_downconvert = 0;
unsigned sx_blend_opt_epsilon = 0;
unsigned sx_blend_opt_control = 0;
@@ -1189,19 +1192,22 @@ radv_update_bound_fast_clear_ds(struct radv_cmd_buffer 
*cmd_buffer,
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-   struct radv_attachment_info *att;
-   uint32_t att_idx;
+   struct radv_attachment_info *att = NULL;
  
-	if (!framebuffer || !subpass)

+   if (!subpass)
return;
-
-   att_idx = subpass->depth_stencil_attachment.attachment;
-   if (att_idx == VK_ATTACHMENT_UNUSED)
+   if (!framebuffer && !cmd_buffer->inherit_unknown_fb)
return;
  
-	att = &framebuffer->attachments[att_idx];

-   if (att->attachment->image != image)
-   return;
+   if (framebuffer) {
+   uint32_t att_idx = subpass->depth_stencil_attachment.attachment;
+   if (att_idx == VK_ATTACHMENT_UNUSED)
+   return;
+
+   att = &framebuffer->attachments[att_idx];
+   if (att->attachment->image != image)
+   return;
+   }
  
  	radeon_set_context_reg_seq(cs, R_028028_DB_STENCIL_CLEAR, 2);

radeon_emit(cs, ds_clear_value.stencil);
@@ -1212,6 +1218,8 @@ radv_update_bound_fast_clear_ds(struct radv_cmd_buffer 
*cmd_buffer,
 */
if ((aspects & VK_IMAGE_ASPECT_DEPTH_BIT) &&
ds_clear_value.depth == 0.0) {
+   assert(att);
+
VkImageLayout layout = subpass->depth_stencil_attachment.layout;
  
  		radv_update_zrange_precision(cmd_buffer, &att->ds, image,

@@ -1426,19 +1434,22 @@ radv_update_bound_fast_clear_color(struct 
radv_cmd_buffer *cmd_buffer,
struct radv_framebuffer *framebuffer = cmd_buffer->state.framebuffer;
const struct radv_subpass *subpass = cmd_buffer->state.subpass;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-   struct radv_attachment_info *att;
-   uint32_t att_idx;
  
-	if (!framebuffer || !subpass)

+   if (!subpass)
return;
-
-   att_idx = subpass->color_attachments[cb_idx].attachment;
-   if (att_idx == VK_ATTACHMENT_UNUSED)
+   if (!framebuffer && !cmd_buffer->inherit_unknown_fb)
return;
  
-	att = &framebuffer->attachments[att_idx];

-   if (att->attachment->image != image)
-   return;
+   if (framebuffer) {
+   struct radv_attachment_info *att;
+   uint32_t att_idx = 
subpass->color_attachments[cb_idx].attachment;
+   if (att_idx == VK_ATTACHMENT_UNUSED)
+   return;
+
+   att = &framebuffer->attachments[att_idx];
+   if (att->attachment->image != image)
+   return;
+   }
  
  	radeon_set_context_reg_seq(cs, R_028C8C_CB_COLOR0_CLEAR_WORD0 + cb_idx * 0x3c, 2);

radeon_emit(cs, color_values[0]);
@@ -2528,6 +2539,7 @@ VkResult radv_BeginCommandBuffer(
cmd_buffer->state.last_first_instance = -1;
cmd_buffer->state.predication_type = -1;
cmd_buffer->usage_flags = pBeginInfo->flags;
+   cmd_buffer->inherit_unknown_fb = false;
  
  	if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_SECONDARY &&

(pBeginInfo->flags & 
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT)) {
@@ -2535,6 +2547,9 @@ VkResult radv_BeginCommandBuffer(
cmd_buffer->state.framebuffer = 
radv_framebuffer_from_handle(pBeginInfo->pInheritanceInfo->framebuffer);
cmd_buffer->state.pass = 
radv_render_pass_from_handle(pBeginInfo->pInheritanceInfo->renderPass);
  
+		if (cmd_buffer->state.pass && !pBeginInfo->pInheritanceInfo->framebuffer)

+   cmd_buffer->inherit_unknown_fb = true;
+
struct radv_subpass *subpass =
 

Re: [Mesa-dev] [PATCH 1/2] radeonsi: always use compute rings for clover on CI and newer (v2)

[Michel Dänzer]

On 2019-04-02 4:00 p.m., Michel Dänzer wrote:
> On 2019-04-02 2:57 p.m., Marek Olšák wrote:
>> On Tue, Apr 2, 2019 at 4:57 AM Michel Dänzer  wrote:
>>> On 2019-04-02 12:39 a.m., Marek Olšák wrote:
 On Mon, Apr 1, 2019 at 1:28 PM Jan Vesely 
>>> wrote:
> On Mon, 2019-04-01 at 12:30 -0400, Marek Olšák wrote:
>> Does the attached patch fix the copy-buffer test?
>
> it does thanks.
> Won't the compute only context still need some synchronization?
> Is there anything else to guarantee that the data is in place after
> return from resource_copy_region ?

 The synchronization is the same on gfx and compute rings.
>>>
>>> BTW, did you see https://bugs.freedesktop.org/show_bug.cgi?id=110214#c24
>>> ? It does indicate some kind of synchronization issue between
>>> si_resource_copy_region using a compute ring and other operations using
>>> a GFX ring.
>>
>> Only OpenCL uses the compute ring. xterm doesn't invoke OpenCL AFAIK.
> 
> That bugzilla comment is about the GTK menu issue, not about xterm.
> Anyway, I doubt GTK uses OpenCL either, and neither does glamor, so it
> was probably an invalid bisect result then.

Apparently not, after all:

https://bugs.freedesktop.org/110355

Looks like there is some issue with si_compute_copy_image, even if it
doesn't use a compute ring.


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

[Mesa-dev] [Bug 109565] CmdBindDescriptorSets gets confused about dynamic offsets

[bugzilla-daemon]

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

--- Comment #9 from Samuel Pitoiset  ---
Do you still have a problem with binding offsets?

-- 
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 v2] virgl: Use right key to insert resource to hash.

[Lepton Wu]

The old code could use gem name as key when inserting it to bo_handles
hash table while trying to remove it from hash table with bo_handle as
key in virgl_hw_res_destroy and then it fail to remove it from bo_handles
hash table. This triggers use after free. Also, we should insert resource
to bo_names hash table when handle type is SHARED.

Signed-off-by: Lepton Wu 
---
 .../winsys/virgl/drm/virgl_drm_winsys.c   | 24 +--
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
index 2cf8b4ba076..af92b6a98fc 100644
--- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
+++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
@@ -406,6 +406,12 @@ virgl_drm_winsys_resource_create_handle(struct 
virgl_winsys *qws,
   return NULL;
}
 
+   if (whandle->type != WINSYS_HANDLE_TYPE_FD &&
+   whandle->type != WINSYS_HANDLE_TYPE_SHARED) {
+  fprintf(stderr, "Unexpected handle type: %d\n", whandle->type);
+  return NULL;
+   }
+
mtx_lock(&qdws->bo_handles_mutex);
 
if (whandle->type == WINSYS_HANDLE_TYPE_SHARED) {
@@ -424,13 +430,13 @@ virgl_drm_winsys_resource_create_handle(struct 
virgl_winsys *qws,
  res = NULL;
  goto done;
   }
-   }
 
-   res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
-   if (res) {
-  struct virgl_hw_res *r = NULL;
-  virgl_drm_resource_reference(qdws, &r, res);
-  goto done;
+  res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
+  if (res) {
+ struct virgl_hw_res *r = NULL;
+ virgl_drm_resource_reference(qdws, &r, res);
+ goto done;
+  }
}
 
res = CALLOC_STRUCT(virgl_hw_res);
@@ -448,6 +454,8 @@ virgl_drm_winsys_resource_create_handle(struct virgl_winsys 
*qws,
  goto done;
   }
   res->bo_handle = open_arg.handle;
+  res->flinked = true;
+  res->flink = whandle->handle;
}
res->name = handle;
 
@@ -469,7 +477,9 @@ virgl_drm_winsys_resource_create_handle(struct virgl_winsys 
*qws,
res->num_cs_references = 0;
res->fence_fd = -1;
 
-   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle, res);
+   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)res->bo_handle, 
res);
+   if (whandle->type == WINSYS_HANDLE_TYPE_SHARED)
+  util_hash_table_set(qdws->bo_names, (void *)(uintptr_t)res->flink, res);
 
 done:
mtx_unlock(&qdws->bo_handles_mutex);
-- 
2.21.0.392.gf8f6787159e-goog

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

[Mesa-dev] [PATCH v2] virgl: Set bind when creating temp resource.

[Lepton Wu]

virgl render complains about "Illegal resource" when running
dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
the reason is that a zero bind value was given for temp resource.

Signed-off-by: Lepton Wu 
---
 src/gallium/drivers/virgl/virgl_texture.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/drivers/virgl/virgl_texture.c 
b/src/gallium/drivers/virgl/virgl_texture.c
index 231319899e0..12b05b52508 100644
--- a/src/gallium/drivers/virgl/virgl_texture.c
+++ b/src/gallium/drivers/virgl/virgl_texture.c
@@ -60,12 +60,22 @@ static void virgl_copy_region_with_blit(struct pipe_context 
*pipe,
   pipe->blit(pipe, &blit);
}
 }
+
+static unsigned int temp_bind(unsigned int orig)
+{
+   if (orig & ~(PIPE_BIND_RENDER_TARGET | PIPE_BIND_DEPTH_STENCIL |
+PIPE_BIND_SAMPLER_VIEW))
+  fprintf(stderr, "Waring, possibly unhandled bind: %x\n", orig);
+   return orig & (PIPE_BIND_DEPTH_STENCIL | PIPE_BIND_RENDER_TARGET);
+}
+
 static void virgl_init_temp_resource_from_box(struct pipe_resource *res,
   struct pipe_resource *orig,
   const struct pipe_box *box,
   unsigned level, unsigned flags)
 {
memset(res, 0, sizeof(*res));
+   res->bind = temp_bind(orig->bind);
res->format = orig->format;
res->width0 = box->width;
res->height0 = box->height;
-- 
2.21.0.392.gf8f6787159e-goog

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

[Mesa-dev] [Bug 109183] GPU Hangs randomly with GTA V

[bugzilla-daemon]

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

Alexander  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from Alexander  ---
Changing this reopened okay this could be really related to mesa because i cant
press ctl+alt+F2 while the game is frozen and this happends only in online
mode.

-- 
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] intel/compiler: Set flag reg/subreg number properly

[Anuj Phogat]

On Wed, Mar 27, 2019 at 4:05 PM Sagar Ghuge  wrote:
>
> If predicate control is set to None, then in that case we can simply set
> flag reg/subreg number to zero. This allows round-tripping through the
> assembler/disassembler
>
> Signed-off-by: Sagar Ghuge 
> ---
>  src/intel/compiler/brw_eu_emit.c| 7 +++
>  src/intel/compiler/brw_fs_generator.cpp | 1 +
>  2 files changed, 8 insertions(+)
>
> diff --git a/src/intel/compiler/brw_eu_emit.c 
> b/src/intel/compiler/brw_eu_emit.c
> index 94e247e1a39..f59543db8df 100644
> --- a/src/intel/compiler/brw_eu_emit.c
> +++ b/src/intel/compiler/brw_eu_emit.c
> @@ -2267,6 +2267,13 @@ brw_fb_WRITE(struct brw_codegen *p,
> brw_inst_set_sfid(devinfo, insn, target_cache);
> brw_inst_set_compression(devinfo, insn, false);
>
> +   if (brw_inst_pred_control(devinfo, insn) == BRW_PREDICATE_NONE) {
> +  brw_inst_set_flag_subreg_nr(devinfo, insn, 0);
> +  if (devinfo->gen >= 7) {
> + brw_inst_set_flag_reg_nr(devinfo, insn, 0);
> +  }
> +   }
> +
> if (devinfo->gen >= 6) {
>/* headerless version, just submit color payload */
>src0 = payload;
> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
> b/src/intel/compiler/brw_fs_generator.cpp
> index c24d4eb7cab..242450c605e 100644
> --- a/src/intel/compiler/brw_fs_generator.cpp
> +++ b/src/intel/compiler/brw_fs_generator.cpp
> @@ -307,6 +307,7 @@ fs_generator::fire_fb_write(fs_inst *inst,
>brw_set_default_mask_control(p, BRW_MASK_DISABLE);
>brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
>brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
> +  brw_set_default_flag_reg(p, 0, 0);
>brw_MOV(p, offset(retype(payload, BRW_REGISTER_TYPE_UD), 1),
>offset(retype(implied_header, BRW_REGISTER_TYPE_UD), 1));
>brw_pop_insn_state(p);
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Change looks correct and harmless.
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/compiler: Set flag reg/subreg number properly

[Sagar Ghuge]

Thanks for reviewing the patch. 

On 4/8/19 10:34 AM, Anuj Phogat wrote:
> On Wed, Mar 27, 2019 at 4:05 PM Sagar Ghuge  wrote:
>>
>> If predicate control is set to None, then in that case we can simply set
>> flag reg/subreg number to zero. This allows round-tripping through the
>> assembler/disassembler
>>
>> Signed-off-by: Sagar Ghuge 
>> ---
>>  src/intel/compiler/brw_eu_emit.c| 7 +++
>>  src/intel/compiler/brw_fs_generator.cpp | 1 +
>>  2 files changed, 8 insertions(+)
>>
>> diff --git a/src/intel/compiler/brw_eu_emit.c 
>> b/src/intel/compiler/brw_eu_emit.c
>> index 94e247e1a39..f59543db8df 100644
>> --- a/src/intel/compiler/brw_eu_emit.c
>> +++ b/src/intel/compiler/brw_eu_emit.c
>> @@ -2267,6 +2267,13 @@ brw_fb_WRITE(struct brw_codegen *p,
>> brw_inst_set_sfid(devinfo, insn, target_cache);
>> brw_inst_set_compression(devinfo, insn, false);
>>
>> +   if (brw_inst_pred_control(devinfo, insn) == BRW_PREDICATE_NONE) {
>> +  brw_inst_set_flag_subreg_nr(devinfo, insn, 0);
>> +  if (devinfo->gen >= 7) {
>> + brw_inst_set_flag_reg_nr(devinfo, insn, 0);
>> +  }
>> +   }
>> +
>> if (devinfo->gen >= 6) {
>>/* headerless version, just submit color payload */
>>src0 = payload;
>> diff --git a/src/intel/compiler/brw_fs_generator.cpp 
>> b/src/intel/compiler/brw_fs_generator.cpp
>> index c24d4eb7cab..242450c605e 100644
>> --- a/src/intel/compiler/brw_fs_generator.cpp
>> +++ b/src/intel/compiler/brw_fs_generator.cpp
>> @@ -307,6 +307,7 @@ fs_generator::fire_fb_write(fs_inst *inst,
>>brw_set_default_mask_control(p, BRW_MASK_DISABLE);
>>brw_set_default_predicate_control(p, BRW_PREDICATE_NONE);
>>brw_set_default_compression_control(p, BRW_COMPRESSION_NONE);
>> +  brw_set_default_flag_reg(p, 0, 0);
>>brw_MOV(p, offset(retype(payload, BRW_REGISTER_TYPE_UD), 1),
>>offset(retype(implied_header, BRW_REGISTER_TYPE_UD), 1));
>>brw_pop_insn_state(p);
>> --
>> 2.20.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> Change looks correct and harmless.
> Reviewed-by: Anuj Phogat 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] intel/disasm: Disassemble JIP offset for while

[Anuj Phogat]

On Wed, Mar 27, 2019 at 5:12 PM Sagar Ghuge  wrote:
>
> Signed-off-by: Sagar Ghuge 
> ---
>  src/intel/compiler/brw_disasm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_disasm.c b/src/intel/compiler/brw_disasm.c
> index efca3e2ce7d..440e51faa61 100644
> --- a/src/intel/compiler/brw_disasm.c
> +++ b/src/intel/compiler/brw_disasm.c
> @@ -1661,7 +1661,8 @@ brw_disassemble_inst(FILE *file, const struct 
> gen_device_info *devinfo,
>format(file, "Pop: %"PRIu64, brw_inst_gen4_pop_count(devinfo, inst));
> } else if (devinfo->gen < 6 && (opcode == BRW_OPCODE_IF ||
> opcode == BRW_OPCODE_IFF ||
> -   opcode == BRW_OPCODE_HALT)) {
> +   opcode == BRW_OPCODE_HALT ||
> +   opcode == BRW_OPCODE_WHILE)) {
>pad(file, 16);
>format(file, "Jump: %d", brw_inst_gen4_jump_count(devinfo, inst));
> } else if (devinfo->gen < 6 && opcode == BRW_OPCODE_ENDIF) {
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

looks fine to me.
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] virgl: Use right key to insert resource to hash.

[Chia-I Wu]

On Mon, Apr 8, 2019 at 9:34 AM Lepton Wu  wrote:

> The old code could use gem name as key when inserting it to bo_handles
> hash table while trying to remove it from hash table with bo_handle as
> key in virgl_hw_res_destroy and then it fail to remove it from bo_handles
> hash table. This triggers use after free. Also, we should insert resource
> to bo_names hash table when handle type is SHARED.
>
> Signed-off-by: Lepton Wu 
> ---
>  .../winsys/virgl/drm/virgl_drm_winsys.c   | 24 +--
>  1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> index 2cf8b4ba076..af92b6a98fc 100644
> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> @@ -406,6 +406,12 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
>return NULL;
> }
>
> +   if (whandle->type != WINSYS_HANDLE_TYPE_FD &&
> +   whandle->type != WINSYS_HANDLE_TYPE_SHARED) {
> +  fprintf(stderr, "Unexpected handle type: %d\n", whandle->type);
> +  return NULL;
> +   }
> +
> mtx_lock(&qdws->bo_handles_mutex);
>
> if (whandle->type == WINSYS_HANDLE_TYPE_SHARED) {
> @@ -424,13 +430,13 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
>   res = NULL;
>   goto done;
>}
> -   }
>
> -   res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
> -   if (res) {
> -  struct virgl_hw_res *r = NULL;
> -  virgl_drm_resource_reference(qdws, &r, res);
> -  goto done;
> +  res = util_hash_table_get(qdws->bo_handles,
> (void*)(uintptr_t)handle);
> +  if (res) {
> + struct virgl_hw_res *r = NULL;
> + virgl_drm_resource_reference(qdws, &r, res);
> + goto done;
> +  }
> }
>
> You can still run into troubles when asked to import a buffer by both its
prime fd and its flink name.

res = CALLOC_STRUCT(virgl_hw_res);
> @@ -448,6 +454,8 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
>   goto done;
>}
>res->bo_handle = open_arg.handle;
> +  res->flinked = true;
> +  res->flink = whandle->handle;
> }
> res->name = handle;
>
res->name has no user.  Remove it.

It is also less confusing to make sure `handle' means GEM handle at this
point, by calling either GEM_OPEN or drmPrimeFDToHandle depending on the
handle type.


> @@ -469,7 +477,9 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
> res->num_cs_references = 0;
> res->fence_fd = -1;
>
> -   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle, res);
> +   util_hash_table_set(qdws->bo_handles, (void
> *)(uintptr_t)res->bo_handle, res);
> +   if (whandle->type == WINSYS_HANDLE_TYPE_SHARED)
> +  util_hash_table_set(qdws->bo_names, (void *)(uintptr_t)res->flink,
> res);
>
>  done:
> mtx_unlock(&qdws->bo_handles_mutex);
> --
> 2.21.0.392.gf8f6787159e-goog
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: Use right key to insert resource to hash.

[Chia-I Wu]

On Wed, Apr 3, 2019 at 8:17 PM Dave Airlie  wrote:

> On Thu, 4 Apr 2019 at 06:54, Chia-I Wu  wrote:
> >
> > You could end up having two virgl_hw_res with two different GEM handles
> pointing to the same kernel GEM object.  That might break some assumptions
> about dependency tracking.
> >
> > For example, when the cmdbuf being built uses a buffer and you want to
> transfer some more data into the buffer, you normally need to submit the
> cmdbuf first before starting the transfer.  The current code detects that
> with virgl_drm_res_is_ref, which assumes each kernel GEM object has a
> unique virgl_hw_res.
> >
> > On Mon, Apr 1, 2019 at 12:37 PM Lepton Wu  wrote:
> >>
> >>
> >>
> >>
> >> On Wed, Mar 20, 2019 at 3:03 PM Chia-I Wu  wrote:
> >>>
> >>> On Mon, Mar 18, 2019 at 2:22 PM Lepton Wu  wrote:
> 
>  The old code could use gem name as key when inserting it to bo_handles
>  hash table while trying to remove it from hash table with bo_handle as
>  key in virgl_hw_res_destroy. This triggers use after free. Also, we
>  should only reuse resource from bo_handle hash when the handle type is
>  FD.
> >>>
> >>> Reuse is not very accurate.  Opening a shared handle (flink name)
> twice gives two GEM handles.  Importing an fd handle (prime fd) twice gives
> the same GEM handle.  In all cases, within a virgl_winsys, we want only one
> GEM handle and only one virgl_resource for each kernel GEM object.
> >>>
> >>> I think the logic should go like:
> >>>
> >>>   if (HANDLE_TYPE_SHARED) {
> >>> if (bo_names.has(flink_name))
> >>>   return bo_names[flink_name];
> >>> gem_handle = gem_open(flink_name);
> >>>   } else {
> >>> gem_handle = drmPrimeFDToHandle(prime_fd);
> >>>   }
> >>>
> >>>
> >>>   if (bo_handles.has(gem_handle))
> >>> return bo_handles[gem_handle];
> >>>   bo_handles[gem_handle] = create_new_resource();
> >>>
> >> Hi, the current patch did most of what you said with only one
> difference:  it didn't insert to bo_handles[]   hash when the type is
> HANDLE_TYPE_SHARED.
> >> I think this is reasonable since opening a shared handle always get a
> new gem handle very time and I think it doesn't worth to insert it to
> bo_handles[] hash.
> >> What do you think?
>
> Just to reinforce this, we can only have one GEM handle for a kernel
> object, validation will go wrong and deadlock if we submit two handles
> pointing at the same bo.
>
> Opening a shared handle should not get a new gem handle, if should
> return any gem handle that already exists.
>
I just tried and that is not the case.  Sounds like a kernel bug?


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

Re: [Mesa-dev] [PATCH] virgl: Use right key to insert resource to hash.

[Lepton Wu]

The kernel code will create a new gem handle for SHARED handle every
time, see code here:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_gem.c#L796


On Mon, Apr 8, 2019 at 11:12 AM Chia-I Wu  wrote:
>
>
>
> On Wed, Apr 3, 2019 at 8:17 PM Dave Airlie  wrote:
>>
>> On Thu, 4 Apr 2019 at 06:54, Chia-I Wu  wrote:
>> >
>> > You could end up having two virgl_hw_res with two different GEM handles 
>> > pointing to the same kernel GEM object.  That might break some assumptions 
>> > about dependency tracking.
>> >
>> > For example, when the cmdbuf being built uses a buffer and you want to 
>> > transfer some more data into the buffer, you normally need to submit the 
>> > cmdbuf first before starting the transfer.  The current code detects that 
>> > with virgl_drm_res_is_ref, which assumes each kernel GEM object has a 
>> > unique virgl_hw_res.
>> >
>> > On Mon, Apr 1, 2019 at 12:37 PM Lepton Wu  wrote:
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Mar 20, 2019 at 3:03 PM Chia-I Wu  wrote:
>> >>>
>> >>> On Mon, Mar 18, 2019 at 2:22 PM Lepton Wu  wrote:
>> 
>>  The old code could use gem name as key when inserting it to bo_handles
>>  hash table while trying to remove it from hash table with bo_handle as
>>  key in virgl_hw_res_destroy. This triggers use after free. Also, we
>>  should only reuse resource from bo_handle hash when the handle type is
>>  FD.
>> >>>
>> >>> Reuse is not very accurate.  Opening a shared handle (flink name) twice 
>> >>> gives two GEM handles.  Importing an fd handle (prime fd) twice gives 
>> >>> the same GEM handle.  In all cases, within a virgl_winsys, we want only 
>> >>> one GEM handle and only one virgl_resource for each kernel GEM object.
>> >>>
>> >>> I think the logic should go like:
>> >>>
>> >>>   if (HANDLE_TYPE_SHARED) {
>> >>> if (bo_names.has(flink_name))
>> >>>   return bo_names[flink_name];
>> >>> gem_handle = gem_open(flink_name);
>> >>>   } else {
>> >>> gem_handle = drmPrimeFDToHandle(prime_fd);
>> >>>   }
>> >>>
>> >>>
>> >>>   if (bo_handles.has(gem_handle))
>> >>> return bo_handles[gem_handle];
>> >>>   bo_handles[gem_handle] = create_new_resource();
>> >>>
>> >> Hi, the current patch did most of what you said with only one difference: 
>> >>  it didn't insert to bo_handles[]   hash when the type is  
>> >> HANDLE_TYPE_SHARED.
>> >> I think this is reasonable since opening a shared handle always get a new 
>> >> gem handle very time and I think it doesn't worth to insert it to 
>> >> bo_handles[] hash.
>> >> What do you think?
>>
>> Just to reinforce this, we can only have one GEM handle for a kernel
>> object, validation will go wrong and deadlock if we submit two handles
>> pointing at the same bo.
>>
>> Opening a shared handle should not get a new gem handle, if should
>> return any gem handle that already exists.
>
> I just tried and that is not the case.  Sounds like a kernel bug?
The kernel code will create a new gem handle for SHARED handle every
time, see code here:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_gem.c#L796
>
>>
>>
>> Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109323] [TRACKER] mesa: Remove autotools

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109323
Bug 109323 depends on bug 109333, which changed state.

Bug 109333 Summary: mesa, meson: Need ability to remember PKG_CONFIG_PATH
https://bugs.freedesktop.org/show_bug.cgi?id=109333

   What|Removed |Added

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

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

[Mesa-dev] [Bug 109333] mesa, meson: Need ability to remember PKG_CONFIG_PATH

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

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

--- Comment #6 from Dylan Baker  ---
Closed via: https://github.com/mesonbuild/meson/pull/4931#event-2257813181

PKG_CONFIG_PATH will be read in during meson setup, and can be configured using
-Dpkg_config_path and -Dcross_pkg_config_path. It is remembered across
invocations

-- 
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 v2] virgl: Use right key to insert resource to hash.

[Lepton Wu]

On Mon, Apr 8, 2019 at 11:10 AM Chia-I Wu  wrote:
>
>
>
> On Mon, Apr 8, 2019 at 9:34 AM Lepton Wu  wrote:
>>
>> The old code could use gem name as key when inserting it to bo_handles
>> hash table while trying to remove it from hash table with bo_handle as
>> key in virgl_hw_res_destroy and then it fail to remove it from bo_handles
>> hash table. This triggers use after free. Also, we should insert resource
>> to bo_names hash table when handle type is SHARED.
>>
>> Signed-off-by: Lepton Wu 
>> ---
>>  .../winsys/virgl/drm/virgl_drm_winsys.c   | 24 +--
>>  1 file changed, 17 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
>> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> index 2cf8b4ba076..af92b6a98fc 100644
>> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> @@ -406,6 +406,12 @@ virgl_drm_winsys_resource_create_handle(struct 
>> virgl_winsys *qws,
>>return NULL;
>> }
>>
>> +   if (whandle->type != WINSYS_HANDLE_TYPE_FD &&
>> +   whandle->type != WINSYS_HANDLE_TYPE_SHARED) {
>> +  fprintf(stderr, "Unexpected handle type: %d\n", whandle->type);
>> +  return NULL;
>> +   }
>> +
>> mtx_lock(&qdws->bo_handles_mutex);
>>
>> if (whandle->type == WINSYS_HANDLE_TYPE_SHARED) {
>> @@ -424,13 +430,13 @@ virgl_drm_winsys_resource_create_handle(struct 
>> virgl_winsys *qws,
>>   res = NULL;
>>   goto done;
>>}
>> -   }
>>
>> -   res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
>> -   if (res) {
>> -  struct virgl_hw_res *r = NULL;
>> -  virgl_drm_resource_reference(qdws, &r, res);
>> -  goto done;
>> +  res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
>> +  if (res) {
>> + struct virgl_hw_res *r = NULL;
>> + virgl_drm_resource_reference(qdws, &r, res);
>> + goto done;
>> +  }
>> }
>>
> You can still run into troubles when asked to import a buffer by both its 
> prime fd and its flink name.
But it seems there is no way to fix it at user space, right? Every
time we got a flink name for
the first time, kernel will give a new handle and no way to  reuse any
res from hash table.
>
>> res = CALLOC_STRUCT(virgl_hw_res);
>> @@ -448,6 +454,8 @@ virgl_drm_winsys_resource_create_handle(struct 
>> virgl_winsys *qws,
>>   goto done;
>>}
>>res->bo_handle = open_arg.handle;
>> +  res->flinked = true;
>> +  res->flink = whandle->handle;
>> }
>> res->name = handle;
>
> res->name has no user.  Remove it.
>
> It is also less confusing to make sure `handle' means GEM handle at this 
> point, by calling either GEM_OPEN or drmPrimeFDToHandle depending on the 
> handle type.
>
>>
>> @@ -469,7 +477,9 @@ virgl_drm_winsys_resource_create_handle(struct 
>> virgl_winsys *qws,
>> res->num_cs_references = 0;
>> res->fence_fd = -1;
>>
>> -   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle, res);
>> +   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)res->bo_handle, 
>> res);
>> +   if (whandle->type == WINSYS_HANDLE_TYPE_SHARED)
>> +  util_hash_table_set(qdws->bo_names, (void *)(uintptr_t)res->flink, 
>> res);
>>
>>  done:
>> mtx_unlock(&qdws->bo_handles_mutex);
>> --
>> 2.21.0.392.gf8f6787159e-goog
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: fix a crash when unbinding sampler states

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 244ba5a7bec..ac40ed27f91 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct si_context *sctx)
 static void si_bind_sampler_states(struct pipe_context *ctx,
enum pipe_shader_type shader,
unsigned start, unsigned count, void 
**states)
 {
struct si_context *sctx = (struct si_context *)ctx;
struct si_samplers *samplers = &sctx->samplers[shader];
struct si_descriptors *desc = si_sampler_and_image_descriptors(sctx, 
shader);
struct si_sampler_state **sstates = (struct si_sampler_state**)states;
int i;
 
-   if (!count || shader >= SI_NUM_SHADERS)
+   if (!count || shader >= SI_NUM_SHADERS || !sstates)
return;
 
for (i = 0; i < count; i++) {
unsigned slot = start + i;
unsigned desc_slot = si_get_sampler_slot(slot);
 
if (!sstates[i] ||
sstates[i] == samplers->sampler_states[slot])
continue;
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] gallium/drivers/radeonsi: Add si_bind_sampler_states unbind support

[Marek Olšák]

I've sent a simpler patch. Please review.

Thanks,
Marek

On Sat, Apr 6, 2019 at 9:07 AM Zhu, James  wrote:

> commit a613607dc3dab2b43884a4e5891aa5939cdcfbe0 will cause segfault
> during unbind sampler state. This patch will fix the issue.
>
> Signed-off-by: James Zhu 
> ---
>  src/gallium/drivers/radeonsi/si_descriptors.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 244ba5a..883b91c 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -956,8 +956,11 @@ static void si_bind_sampler_states(struct
> pipe_context *ctx,
> unsigned slot = start + i;
> unsigned desc_slot = si_get_sampler_slot(slot);
>
> -   if (!sstates[i] ||
> -   sstates[i] == samplers->sampler_states[slot])
> +   if(!sstates) {
> +   samplers->sampler_states[slot] = NULL;
> +   continue;
> +   } else if (!sstates[i] ||
> +   sstates[i] == samplers->sampler_states[slot])
> continue;
>
>  #ifdef DEBUG
> --
> 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] radeonsi: fix a crash when unbinding sampler states

[James Zhu]

On 2019-04-08 2:25 p.m., Marek Olšák wrote:
> From: Marek Olšák 
>
> ---
>   src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 244ba5a7bec..ac40ed27f91 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct si_context 
> *sctx)
>   static void si_bind_sampler_states(struct pipe_context *ctx,
>  enum pipe_shader_type shader,
>  unsigned start, unsigned count, void 
> **states)
>   {
>   struct si_context *sctx = (struct si_context *)ctx;
>   struct si_samplers *samplers = &sctx->samplers[shader];
>   struct si_descriptors *desc = si_sampler_and_image_descriptors(sctx, 
> shader);
>   struct si_sampler_state **sstates = (struct si_sampler_state**)states;
>   int i;
>   
> - if (!count || shader >= SI_NUM_SHADERS)
> + if (!count || shader >= SI_NUM_SHADERS || !sstates)

if sstates == NULL, it means we want to unbind samplers->sampler_states 
from current setting.

So I think it is better not just bypass it.

James

>   return;
>   
>   for (i = 0; i < count; i++) {
>   unsigned slot = start + i;
>   unsigned desc_slot = si_get_sampler_slot(slot);
>   
>   if (!sstates[i] ||
>   sstates[i] == samplers->sampler_states[slot])
>   continue;
>   
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/va: reverse qt matrix back to its original order

[boyuan.zhang]

From: Boyuan Zhang 

The quantiser matrix that VAAPI provides has been applied with inverse z-scan.
However, what we expect in MPEG2 picture description is the original order.
Therefore, we need to reverse it back to its original order.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110257
Cc: mesa-sta...@lists.freedesktop.org

Signed-off-by: Boyuan Zhang 
Acked-by: Alex Deucher 
---
 src/gallium/state_trackers/va/picture_mpeg12.c | 38 ++
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/va/picture_mpeg12.c 
b/src/gallium/state_trackers/va/picture_mpeg12.c
index 1e5a9c7..daf95f7 100644
--- a/src/gallium/state_trackers/va/picture_mpeg12.c
+++ b/src/gallium/state_trackers/va/picture_mpeg12.c
@@ -27,6 +27,19 @@
 
 #include "va_private.h"
 
+const int reverse_inverse_zscan[] =
+{
+   /* Reverse inverse z scan pattern */
+0,  2,  3,  9, 10, 20, 21, 35,
+1,  4,  8, 11, 19, 22, 34, 36,
+5,  7, 12, 18, 23, 33, 37, 48,
+6, 13, 17, 24, 32, 38, 47, 49,
+   14, 16, 25, 31, 39, 46, 50, 57,
+   15, 26, 30, 40, 45, 51, 56, 58,
+   27, 29, 41, 44, 52, 55, 59, 62,
+   28, 42, 43, 53, 54, 60, 61, 63,
+};
+
 void vlVaHandlePictureParameterBufferMPEG12(vlVaDriver *drv, vlVaContext 
*context, vlVaBuffer *buf)
 {
VAPictureParameterBufferMPEG2 *mpeg2 = buf->data;
@@ -66,16 +79,29 @@ void vlVaHandlePictureParameterBufferMPEG12(vlVaDriver 
*drv, vlVaContext *contex
 void vlVaHandleIQMatrixBufferMPEG12(vlVaContext *context, vlVaBuffer *buf)
 {
VAIQMatrixBufferMPEG2 *mpeg2 = buf->data;
+   static uint8_t temp_intra_matrix[64];
+   static uint8_t temp_nonintra_matrix[64];
 
assert(buf->size >= sizeof(VAIQMatrixBufferMPEG2) && buf->num_elements == 
1);
-   if (mpeg2->load_intra_quantiser_matrix)
-  context->desc.mpeg12.intra_matrix = mpeg2->intra_quantiser_matrix;
-   else
+   if (mpeg2->load_intra_quantiser_matrix) {
+  /* The quantiser matrix that VAAPI provides has been applied
+ with inverse z-scan. However, what we expect in MPEG2
+ picture description is the original order. Therefore,
+ we need to reverse it back to its original order.
+  */
+  for (int i = 0; i < 64; i++)
+ temp_intra_matrix[i] =
+mpeg2->intra_quantiser_matrix[reverse_inverse_zscan[i]];
+  context->desc.mpeg12.intra_matrix = temp_intra_matrix;
+   } else
   context->desc.mpeg12.intra_matrix = NULL;
 
-   if (mpeg2->load_non_intra_quantiser_matrix)
-  context->desc.mpeg12.non_intra_matrix = 
mpeg2->non_intra_quantiser_matrix;
-   else
+   if (mpeg2->load_non_intra_quantiser_matrix) {
+  for (int i = 0; i < 64; i++)
+ temp_nonintra_matrix[i] =
+mpeg2->non_intra_quantiser_matrix[reverse_inverse_zscan[i]];
+  context->desc.mpeg12.non_intra_matrix = temp_nonintra_matrix;
+   } else
   context->desc.mpeg12.non_intra_matrix = NULL;
 }
 
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] radeonsi: fix a crash when unbinding sampler states

[Marek Olšák]

On Mon, Apr 8, 2019 at 2:33 PM James Zhu  wrote:

>
> On 2019-04-08 2:25 p.m., Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > ---
> >   src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> > index 244ba5a7bec..ac40ed27f91 100644
> > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > @@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct si_context
> *sctx)
> >   static void si_bind_sampler_states(struct pipe_context *ctx,
> >  enum pipe_shader_type shader,
> >  unsigned start, unsigned count,
> void **states)
> >   {
> >   struct si_context *sctx = (struct si_context *)ctx;
> >   struct si_samplers *samplers = &sctx->samplers[shader];
> >   struct si_descriptors *desc =
> si_sampler_and_image_descriptors(sctx, shader);
> >   struct si_sampler_state **sstates = (struct
> si_sampler_state**)states;
> >   int i;
> >
> > - if (!count || shader >= SI_NUM_SHADERS)
> > + if (!count || shader >= SI_NUM_SHADERS || !sstates)
>
> if sstates == NULL, it means we want to unbind samplers->sampler_states
> from current setting.
>
> So I think it is better not just bypass it.
>

The driver never unbinds constant state objects. If sstates[i] == NULL,
it's not unbound. sstates == NULL is a similar case.

It's not a standard behavior, but the driver has been doing it for a very
long time.

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

Re: [Mesa-dev] [PATCH v2] virgl: Use right key to insert resource to hash.

[Chia-I Wu]

On Mon, Apr 8, 2019 at 11:24 AM Lepton Wu  wrote:

> On Mon, Apr 8, 2019 at 11:10 AM Chia-I Wu  wrote:
> >
> >
> >
> > On Mon, Apr 8, 2019 at 9:34 AM Lepton Wu  wrote:
> >>
> >> The old code could use gem name as key when inserting it to bo_handles
> >> hash table while trying to remove it from hash table with bo_handle as
> >> key in virgl_hw_res_destroy and then it fail to remove it from
> bo_handles
> >> hash table. This triggers use after free. Also, we should insert
> resource
> >> to bo_names hash table when handle type is SHARED.
> >>
> >> Signed-off-by: Lepton Wu 
> >> ---
> >>  .../winsys/virgl/drm/virgl_drm_winsys.c   | 24 +--
> >>  1 file changed, 17 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> >> index 2cf8b4ba076..af92b6a98fc 100644
> >> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> >> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
> >> @@ -406,6 +406,12 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
> >>return NULL;
> >> }
> >>
> >> +   if (whandle->type != WINSYS_HANDLE_TYPE_FD &&
> >> +   whandle->type != WINSYS_HANDLE_TYPE_SHARED) {
> >> +  fprintf(stderr, "Unexpected handle type: %d\n", whandle->type);
> >> +  return NULL;
> >> +   }
> >> +
> >> mtx_lock(&qdws->bo_handles_mutex);
> >>
> >> if (whandle->type == WINSYS_HANDLE_TYPE_SHARED) {
> >> @@ -424,13 +430,13 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
> >>   res = NULL;
> >>   goto done;
> >>}
> >> -   }
> >>
> >> -   res = util_hash_table_get(qdws->bo_handles,
> (void*)(uintptr_t)handle);
> >> -   if (res) {
> >> -  struct virgl_hw_res *r = NULL;
> >> -  virgl_drm_resource_reference(qdws, &r, res);
> >> -  goto done;
> >> +  res = util_hash_table_get(qdws->bo_handles,
> (void*)(uintptr_t)handle);
> >> +  if (res) {
> >> + struct virgl_hw_res *r = NULL;
> >> + virgl_drm_resource_reference(qdws, &r, res);
> >> + goto done;
> >> +  }
> >> }
> >>
> > You can still run into troubles when asked to import a buffer by both
> its prime fd and its flink name.
> But it seems there is no way to fix it at user space, right? Every
> time we got a flink name for
> the first time, kernel will give a new handle and no way to  reuse any
> res from hash table.
>
Yeah, I think you are right... but that appears to be a kernel bug.  Once
kernel is fixed to return the same handle for the same flink name / prime
fd, we should be ready for that.  Let's see what Dave thinks.

>
> >> res = CALLOC_STRUCT(virgl_hw_res);
> >> @@ -448,6 +454,8 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
> >>   goto done;
> >>}
> >>res->bo_handle = open_arg.handle;
> >> +  res->flinked = true;
> >> +  res->flink = whandle->handle;
> >> }
> >> res->name = handle;
> >
> > res->name has no user.  Remove it.
> >
> > It is also less confusing to make sure `handle' means GEM handle at this
> point, by calling either GEM_OPEN or drmPrimeFDToHandle depending on the
> handle type.
> >
> >>
> >> @@ -469,7 +477,9 @@ virgl_drm_winsys_resource_create_handle(struct
> virgl_winsys *qws,
> >> res->num_cs_references = 0;
> >> res->fence_fd = -1;
> >>
> >> -   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle,
> res);
> >> +   util_hash_table_set(qdws->bo_handles, (void
> *)(uintptr_t)res->bo_handle, res);
> >> +   if (whandle->type == WINSYS_HANDLE_TYPE_SHARED)
> >> +  util_hash_table_set(qdws->bo_names, (void
> *)(uintptr_t)res->flink, res);
> >>
> >>  done:
> >> mtx_unlock(&qdws->bo_handles_mutex);
> >> --
> >> 2.21.0.392.gf8f6787159e-goog
> >>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix a crash when unbinding sampler states

[James Zhu]

On 2019-04-08 2:39 p.m., Marek Olšák wrote:
On Mon, Apr 8, 2019 at 2:33 PM James Zhu 
mailto:jam...@amd.com>> wrote:

On 2019-04-08 2:25 p.m., Marek Olšák wrote:
> From: Marek Olšák mailto:marek.ol...@amd.com>>
>
> ---
>   src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 244ba5a7bec..ac40ed27f91 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct si_context 
> *sctx)
>   static void si_bind_sampler_states(struct pipe_context *ctx,
>  enum pipe_shader_type shader,
>  unsigned start, unsigned count, void 
> **states)
>   {
>   struct si_context *sctx = (struct si_context *)ctx;
>   struct si_samplers *samplers = &sctx->samplers[shader];
>   struct si_descriptors *desc = si_sampler_and_image_descriptors(sctx, 
> shader);
>   struct si_sampler_state **sstates = (struct si_sampler_state**)states;
>   int i;
>
> - if (!count || shader >= SI_NUM_SHADERS)
> + if (!count || shader >= SI_NUM_SHADERS || !sstates)

if sstates == NULL, it means we want to unbind samplers->sampler_states
from current setting.

So I think it is better not just bypass it.

The driver never unbinds constant state objects. If sstates[i] == NULL, it's 
not unbound. sstates == NULL is a similar case.

Then we should not call unbind sampler state after compute shader launch. Since 
it is doing nothing.

James

It's not a standard behavior, but the driver has been doing it for a very long 
time.

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

Re: [Mesa-dev] [PATCH v7 28/35] intel/compiler: implement SIMD16 restrictions for mixed-float instructions

[Francisco Jerez]

"Juan A. Suarez Romero"  writes:

> From: Iago Toral Quiroga 
>
> v2: f32to16/f16to32 can use a :W destination (Curro)
> ---
>  src/intel/compiler/brw_fs.cpp | 71 +++
>  1 file changed, 71 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index d4803c63b93..48b5cc6c403 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5606,6 +5606,48 @@ fs_visitor::lower_logical_sends()
> return progress;
>  }
>  
> +static bool
> +is_mixed_float_with_fp32_dst(const fs_inst *inst)
> +{
> +   /* This opcode sometimes uses :W type on the source even if the operand is
> +* a :HF, because in gen7 there is no support for :HF, and thus it uses 
> :W.
> +*/
> +   if (inst->opcode == BRW_OPCODE_F16TO32)
> +  return true;
> +
> +   if (inst->dst.type != BRW_REGISTER_TYPE_F)
> +  return false;
> +
> +   for (int i = 0; i < inst->sources; i++) {
> +  if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
> + return true;
> +   }
> +
> +   return false;
> +}
> +
> +static bool
> +is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
> +{
> +   /* This opcode sometimes uses :W type on the destination even if the
> +* destination is a :HF, because in gen7 there is no support for :HF, and
> +* thus it uses :W.
> +*/
> +   if (inst->opcode == BRW_OPCODE_F32TO16)

Don't you need to check whether the destination is packed here?

> +  return true;
> +
> +   if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
> +   inst->dst.stride != 1)
> +  return false;
> +
> +   for (int i = 0; i < inst->sources; i++) {
> +  if (inst->src[i].type == BRW_REGISTER_TYPE_F)
> + return true;
> +   }
> +
> +   return false;
> +}
> +
>  /**
>   * Get the closest allowed SIMD width for instruction \p inst accounting for
>   * some common regioning and execution control restrictions that apply to FPU
> @@ -5768,6 +5810,35 @@ get_fpu_lowered_simd_width(const struct 
> gen_device_info *devinfo,
>   max_width = MIN2(max_width, 4);
> }
>  
> +   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is f32. Instruction
> +* execution size must be no more than 8."
> +*
> +* FIXME: the simulator doesn't seem to complain if we don't do this and
> +* empirical testing with existing CTS tests show that they pass just fine
> +* without implementing this, however, since our interpretation of the PRM
> +* is that conversion MOVs between HF and F are still mixed-float
> +* instructions (and therefore subject to this restriction) we decided to
> +* split them to be safe. Might be useful to do additional investigation 
> to
> +* lift the restriction if we can ensure that it is safe though, since 
> these
> +* conversions are common when half-float types are involved since many
> +* instructions do not support HF types and conversions from/to F are
> +* required.
> +*/
> +   if (is_mixed_float_with_fp32_dst(inst))
> +  max_width = MIN2(max_width, 8);
> +
> +   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is packed f16 for both
> +* Align1 and Align16."
> +*/
> +   if (is_mixed_float_with_packed_fp16_dst(inst))
> +  max_width = MIN2(max_width, 8);
> +
> /* Only power-of-two execution sizes are representable in the instruction
>  * control fields.
>  */
> -- 
> 2.20.1


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

[Mesa-dev] [Bug 109183] GPU Hangs randomly with GTA V

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
Do you have something in dmesg when it freezes?

-- 
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] radeonsi: fix a crash when unbinding sampler states

[Marek Olšák]

On Mon, Apr 8, 2019 at 2:45 PM James Zhu  wrote:

>
> On 2019-04-08 2:39 p.m., Marek Olšák wrote:
>
> On Mon, Apr 8, 2019 at 2:33 PM James Zhu  wrote:
>
>>
>> On 2019-04-08 2:25 p.m., Marek Olšák wrote:
>> > From: Marek Olšák 
>> >
>> > ---
>> >   src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
>> >   1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
>> b/src/gallium/drivers/radeonsi/si_descriptors.c
>> > index 244ba5a7bec..ac40ed27f91 100644
>> > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
>> > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
>> > @@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct
>> si_context *sctx)
>> >   static void si_bind_sampler_states(struct pipe_context *ctx,
>> >  enum pipe_shader_type shader,
>> >  unsigned start, unsigned count,
>> void **states)
>> >   {
>> >   struct si_context *sctx = (struct si_context *)ctx;
>> >   struct si_samplers *samplers = &sctx->samplers[shader];
>> >   struct si_descriptors *desc =
>> si_sampler_and_image_descriptors(sctx, shader);
>> >   struct si_sampler_state **sstates = (struct
>> si_sampler_state**)states;
>> >   int i;
>> >
>> > - if (!count || shader >= SI_NUM_SHADERS)
>> > + if (!count || shader >= SI_NUM_SHADERS || !sstates)
>>
>> if sstates == NULL, it means we want to unbind samplers->sampler_states
>> from current setting.
>>
>> So I think it is better not just bypass it.
>>
>
> The driver never unbinds constant state objects. If sstates[i] == NULL,
> it's not unbound. sstates == NULL is a similar case.
>
> Then we should not call unbind sampler state after compute shader launch.
> Since it is doing nothing.
>
You are right.

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

Re: [Mesa-dev] [PATCH] gallium: Add support for frame_cropping_flag of VAEncSequenceParameterBufferH264

[Liu, Leo]

On 4/8/19 1:17 AM, Sahu, Satyajit wrote:
> From: suresh guttula 
>
> This patch will add support for frame_cropping when the input size is not
> matched with aligned size. Currently vaapi driver ignores frame cropping
> values provided by client. This change will update SPS nalu with proper
> cropping values.
>
> Signed-off-by: suresh guttula 
> Signed-off-by: Satyajit Sahu 
> ---
>   src/gallium/drivers/radeon/radeon_vce_52.c   | 8 ++--
>   src/gallium/include/pipe/p_video_state.h | 5 +
>   src/gallium/state_trackers/va/picture_h264_enc.c | 8 
>   3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
> b/src/gallium/drivers/radeon/radeon_vce_52.c
> index fc7ddc62a90..593730756d5 100644
> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
> @@ -81,8 +81,12 @@ static void get_pic_control_param(struct rvce_encoder 
> *enc, struct pipe_h264_enc
>   unsigned encNumMBsPerSlice;
>   encNumMBsPerSlice = align(enc->base.width, 16) / 16;
>   encNumMBsPerSlice *= align(enc->base.height, 16) / 16;
> - enc->enc_pic.pc.enc_crop_right_offset = (align(enc->base.width, 16) - 
> enc->base.width) >> 1;
> - enc->enc_pic.pc.enc_crop_bottom_offset = (align(enc->base.height, 16) - 
> enc->base.height) >> 1;

Shouldn't we need to keep this code path when the cropping info is not 
available, since VA spec says it's optional.

Regards,

Leo



> + if (pic->pic_ctrl.enc_frame_cropping_flag) {
> + enc->enc_pic.pc.enc_crop_left_offset = 
> pic->pic_ctrl.enc_frame_crop_left_offset;
> + enc->enc_pic.pc.enc_crop_right_offset = 
> pic->pic_ctrl.enc_frame_crop_right_offset;
> + enc->enc_pic.pc.enc_crop_top_offset = 
> pic->pic_ctrl.enc_frame_crop_top_offset;
> + enc->enc_pic.pc.enc_crop_bottom_offset = 
> pic->pic_ctrl.enc_frame_crop_bottom_offset;
> + }
>   enc->enc_pic.pc.enc_num_mbs_per_slice = encNumMBsPerSlice;
>   enc->enc_pic.pc.enc_b_pic_pattern = MAX2(enc->base.max_references, 1) - 
> 1;
>   enc->enc_pic.pc.enc_number_of_reference_frames = 
> MIN2(enc->base.max_references, 2);
> diff --git a/src/gallium/include/pipe/p_video_state.h 
> b/src/gallium/include/pipe/p_video_state.h
> index 05855a36e23..1369f1a8ca6 100644
> --- a/src/gallium/include/pipe/p_video_state.h
> +++ b/src/gallium/include/pipe/p_video_state.h
> @@ -395,6 +395,11 @@ struct pipe_h264_enc_pic_control
>   {
>  unsigned enc_cabac_enable;
>  unsigned enc_constraint_set_flags;
> +   unsigned enc_frame_cropping_flag;
> +   unsigned enc_frame_crop_left_offset;
> +   unsigned enc_frame_crop_right_offset;
> +   unsigned enc_frame_crop_top_offset;
> +   unsigned enc_frame_crop_bottom_offset;
>   };
>   
>   struct pipe_h264_enc_picture_desc
> diff --git a/src/gallium/state_trackers/va/picture_h264_enc.c 
> b/src/gallium/state_trackers/va/picture_h264_enc.c
> index abfd39633de..f46b3425566 100644
> --- a/src/gallium/state_trackers/va/picture_h264_enc.c
> +++ b/src/gallium/state_trackers/va/picture_h264_enc.c
> @@ -127,6 +127,14 @@ 
> vlVaHandleVAEncSequenceParameterBufferTypeH264(vlVaDriver *drv, vlVaContext 
> *con
>  context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
>  context->desc.h264enc.rate_ctrl.frame_rate_den = h264->num_units_in_tick;
>  context->desc.h264enc.pic_order_cnt_type = 
> h264->seq_fields.bits.pic_order_cnt_type;
> +
> +   if (h264->frame_cropping_flag) {
> +  context->desc.h264enc.pic_ctrl.enc_frame_cropping_flag = 
> h264->frame_cropping_flag;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_left_offset = 
> h264->frame_crop_left_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_right_offset = 
> h264->frame_crop_right_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_top_offset = 
> h264->frame_crop_top_offset;
> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_bottom_offset = 
> h264->frame_crop_bottom_offset;
> +   }
>  return VA_STATUS_SUCCESS;
>   }
>   
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: fix a crash when unbinding sampler states

[James Zhu]

This patch is Acked-by: James Zhu 

On 2019-04-08 3:02 p.m., Marek Olšák wrote:
On Mon, Apr 8, 2019 at 2:45 PM James Zhu 
mailto:jam...@amd.com>> wrote:


On 2019-04-08 2:39 p.m., Marek Olšák wrote:
On Mon, Apr 8, 2019 at 2:33 PM James Zhu 
mailto:jam...@amd.com>> wrote:

On 2019-04-08 2:25 p.m., Marek Olšák wrote:
> From: Marek Olšák mailto:marek.ol...@amd.com>>
>
> ---
>   src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 244ba5a7bec..ac40ed27f91 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct si_context 
> *sctx)
>   static void si_bind_sampler_states(struct pipe_context *ctx,
>  enum pipe_shader_type shader,
>  unsigned start, unsigned count, void 
> **states)
>   {
>   struct si_context *sctx = (struct si_context *)ctx;
>   struct si_samplers *samplers = &sctx->samplers[shader];
>   struct si_descriptors *desc = si_sampler_and_image_descriptors(sctx, 
> shader);
>   struct si_sampler_state **sstates = (struct si_sampler_state**)states;
>   int i;
>
> - if (!count || shader >= SI_NUM_SHADERS)
> + if (!count || shader >= SI_NUM_SHADERS || !sstates)

if sstates == NULL, it means we want to unbind samplers->sampler_states
from current setting.

So I think it is better not just bypass it.

The driver never unbinds constant state objects. If sstates[i] == NULL, it's 
not unbound. sstates == NULL is a similar case.

Then we should not call unbind sampler state after compute shader launch. Since 
it is doing nothing.

You are right.

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

[Mesa-dev] [Bug 110349] radv: Dragon Quest XI (DXVK) has a graphical glitch (regression, bisected)

[bugzilla-daemon]

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

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #7 from Samuel Pitoiset  ---
Should be fixed by
https://cgit.freedesktop.org/mesa/mesa/commit/?id=775191cd99a772acda37f41790ff09b93c7a00ba

Thanks for reporting this!

-- 
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 110350] DOOM 2016 crash + severe artifacting on RADV + Vega VII

[bugzilla-daemon]

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

--- Comment #2 from Thomas Crider  ---
Sure, I just started a new campaign and loaded into the first mission. no less
than about 15-30 seconds in it immediately went black/polygony, then crashed.
I'll see if I can record it later tonight. My resolution was 4k60 and settings
were maxed

-- 
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] gitlab: Let's delete a buildsystem

[Dylan Baker]

As per the discussion last time around, the last feature meson needed to grow to
be able to remove autotools was support for remembering PKG_CONFIG_PATH, since
that has landed: https://github.com/mesonbuild/meson/pull/4931, so I'm sending
this out again.

The gitlab link for the PR is here:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601

Dylan


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

[Mesa-dev] [PATCH 2/2] radv: allow to force enable vsync with RADV_VSYNC=1

[Samuel Pitoiset]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107391
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_wsi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2fd07447668..7651043b2b2 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -38,11 +38,13 @@ radv_wsi_proc_addr(VkPhysicalDevice physicalDevice, const 
char *pName)
 VkResult
 radv_init_wsi(struct radv_physical_device *physical_device)
 {
+   bool vsync = !!env_var_as_unsigned("RADV_VSYNC", 0);
+
return wsi_device_init(&physical_device->wsi_device,
   radv_physical_device_to_handle(physical_device),
   radv_wsi_proc_addr,
   &physical_device->instance->alloc,
-  physical_device->master_fd, false);
+  physical_device->master_fd, vsync);
 }
 
 void
-- 
2.21.0

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

[Mesa-dev] [PATCH 1/2] wsi: add an option that allows to force enable vsync at device creation

[Samuel Pitoiset]

When the WSI device wants to enable vsync, it just switches
to the FIFO presentation mode.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_wsi.c   | 2 +-
 src/freedreno/vulkan/tu_wsi.c   | 2 +-
 src/intel/vulkan/anv_wsi.c  | 2 +-
 src/vulkan/wsi/wsi_common.c | 4 +++-
 src/vulkan/wsi/wsi_common.h | 4 +++-
 src/vulkan/wsi/wsi_common_display.c | 3 +++
 src/vulkan/wsi/wsi_common_wayland.c | 3 +++
 src/vulkan/wsi/wsi_common_x11.c | 3 +++
 8 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 346fb43d675..2fd07447668 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -42,7 +42,7 @@ radv_init_wsi(struct radv_physical_device *physical_device)
   radv_physical_device_to_handle(physical_device),
   radv_wsi_proc_addr,
   &physical_device->instance->alloc,
-  physical_device->master_fd);
+  physical_device->master_fd, false);
 }
 
 void
diff --git a/src/freedreno/vulkan/tu_wsi.c b/src/freedreno/vulkan/tu_wsi.c
index ce06a05d5d5..8ea12010a19 100644
--- a/src/freedreno/vulkan/tu_wsi.c
+++ b/src/freedreno/vulkan/tu_wsi.c
@@ -40,7 +40,7 @@ tu_wsi_init(struct tu_physical_device *physical_device)
return wsi_device_init(&physical_device->wsi_device,
   tu_physical_device_to_handle(physical_device),
   tu_wsi_proc_addr, &physical_device->instance->alloc,
-  physical_device->master_fd);
+  physical_device->master_fd, false);
 }
 
 void
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 024bc1c245d..d24f076dce5 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -49,7 +49,7 @@ anv_init_wsi(struct anv_physical_device *physical_device)
 anv_physical_device_to_handle(physical_device),
 anv_wsi_proc_addr,
 &physical_device->instance->alloc,
-physical_device->master_fd);
+physical_device->master_fd, false);
if (result != VK_SUCCESS)
   return result;
 
diff --git a/src/vulkan/wsi/wsi_common.c b/src/vulkan/wsi/wsi_common.c
index 3cba0a4b06e..6c92f3282e1 100644
--- a/src/vulkan/wsi/wsi_common.c
+++ b/src/vulkan/wsi/wsi_common.c
@@ -35,7 +35,8 @@ wsi_device_init(struct wsi_device *wsi,
 VkPhysicalDevice pdevice,
 WSI_FN_GetPhysicalDeviceProcAddr proc_addr,
 const VkAllocationCallbacks *alloc,
-int display_fd)
+int display_fd,
+bool forces_vsync)
 {
VkResult result;
 
@@ -60,6 +61,7 @@ wsi_device_init(struct wsi_device *wsi,
GetPhysicalDeviceProperties2(pdevice, &pdp2);
 
wsi->maxImageDimension2D = pdp2.properties.limits.maxImageDimension2D;
+   wsi->forces_vsync = forces_vsync;
 
GetPhysicalDeviceMemoryProperties(pdevice, &wsi->memory_props);
GetPhysicalDeviceQueueFamilyProperties(pdevice, &wsi->queue_family_count, 
NULL);
diff --git a/src/vulkan/wsi/wsi_common.h b/src/vulkan/wsi/wsi_common.h
index e693e2be425..3f4c8d44936 100644
--- a/src/vulkan/wsi/wsi_common.h
+++ b/src/vulkan/wsi/wsi_common.h
@@ -100,6 +100,7 @@ struct wsi_device {
VkPhysicalDevicePCIBusInfoPropertiesEXT pci_bus_info;
 
bool supports_modifiers;
+   bool forces_vsync;
uint32_t maxImageDimension2D;
 
uint64_t (*image_get_modifier)(VkImage image);
@@ -143,7 +144,8 @@ wsi_device_init(struct wsi_device *wsi,
 VkPhysicalDevice pdevice,
 WSI_FN_GetPhysicalDeviceProcAddr proc_addr,
 const VkAllocationCallbacks *alloc,
-int display_fd);
+int display_fd,
+bool forces_vsync);
 
 void
 wsi_device_finish(struct wsi_device *wsi,
diff --git a/src/vulkan/wsi/wsi_common_display.c 
b/src/vulkan/wsi/wsi_common_display.c
index 09c18315623..d0f3d519e29 100644
--- a/src/vulkan/wsi/wsi_common_display.c
+++ b/src/vulkan/wsi/wsi_common_display.c
@@ -1765,6 +1765,9 @@ wsi_display_surface_create_swapchain(
 
chain->surface = (VkIcdSurfaceDisplay *) icd_surface;
 
+   if (wsi_device->forces_vsync)
+  chain->base.present_mode = VK_PRESENT_MODE_FIFO_KHR;
+
for (uint32_t image = 0; image < chain->base.image_count; image++) {
   result = wsi_display_image_init(device, &chain->base,
   create_info, allocator,
diff --git a/src/vulkan/wsi/wsi_common_wayland.c 
b/src/vulkan/wsi/wsi_common_wayland.c
index a312a99d412..3a5b0632c7c 100644
--- a/src/vulkan/wsi/wsi_common_wayland.c
+++ b/src/vulkan/wsi/wsi_common_wayland.c
@@ -981,6 +981,9 @@ wsi_wl_surface_create_swapchain(VkIcdSurfaceBase 
*icd_surface,
chain->vk_format = pCreateInfo->imageFormat;
chai

Re: [Mesa-dev] [PATCH] nir/radv: remove restrictions on opt_if_loop_last_continue()

[Samuel Pitoiset]

Acked-by: Samuel Pitoiset 

On 4/8/19 12:13 PM, Timothy Arceri wrote:

When I implemented opt_if_loop_last_continue() I had restricted
this pass from moving other if-statements inside the branch opposite
the continue. At the time it was causing a bunch of spilling in
shader-db for i965.

However Samuel Pitoiset noticed that making this pass more aggressive
significantly improved the performance of Doom on RADV. Below are
the statistics he gathered.

28717 shaders in 14931 tests
Totals:
SGPRS: 1267317 -> 1267549 (0.02 %)
VGPRS: 896876 -> 895920 (-0.11 %)
Spilled SGPRs: 24701 -> 26367 (6.74 %)
Code Size: 48379452 -> 48507880 (0.27 %) bytes
Max Waves: 241159 -> 241190 (0.01 %)

Totals from affected shaders:
SGPRS: 23584 -> 23816 (0.98 %)
VGPRS: 25908 -> 24952 (-3.69 %)
Spilled SGPRs: 503 -> 2169 (331.21 %)
Code Size: 2471392 -> 2599820 (5.20 %) bytes
Max Waves: 586 -> 617 (5.29 %)

The codesize increases is related to Wolfenstein II it seems largely
due to an increase in phis rather than the existing jumps.

This gives +10% FPS with Doom on my Vega56.

Rhys Perry also benchmarked Doom on his VEGA64:

Before: 72.53 FPS
After:  80.77 FPS

v2: disable pass on non-AMD drivers

Reviewed-by: Ian Romanick  (v1)
---
  src/amd/vulkan/radv_shader.c |  2 +-
  src/compiler/nir/nir.h   |  2 +-
  src/compiler/nir/nir_opt_if.c| 87 
  src/freedreno/ir3/ir3_nir.c  |  2 +-
  src/gallium/auxiliary/nir/tgsi_to_nir.c  |  2 +-
  src/gallium/drivers/freedreno/a2xx/ir2_nir.c |  2 +-
  src/gallium/drivers/radeonsi/si_shader_nir.c |  2 +-
  src/intel/compiler/brw_nir.c |  2 +-
  src/mesa/state_tracker/st_glsl_to_nir.cpp|  2 +-
  9 files changed, 61 insertions(+), 42 deletions(-)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index d3d073d1db8..7cde5e728e4 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -158,7 +158,7 @@ radv_optimize_nir(struct nir_shader *shader, bool 
optimize_conservatively,
NIR_PASS(progress, shader, nir_opt_remove_phis);
  NIR_PASS(progress, shader, nir_opt_dce);
  }
-NIR_PASS(progress, shader, nir_opt_if);
+NIR_PASS(progress, shader, nir_opt_if, true);
  NIR_PASS(progress, shader, nir_opt_dead_cf);
  NIR_PASS(progress, shader, nir_opt_cse);
  NIR_PASS(progress, shader, nir_opt_peephole_select, 8, true, 
true);
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index bc72d8f83f5..c1ecf5ad561 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -3434,7 +3434,7 @@ bool nir_opt_gcm(nir_shader *shader, bool value_number);
  
  bool nir_opt_idiv_const(nir_shader *shader, unsigned min_bit_size);
  
-bool nir_opt_if(nir_shader *shader);

+bool nir_opt_if(nir_shader *shader, bool aggressive_last_continue);
  
  bool nir_opt_intrinsics(nir_shader *shader);
  
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c

index 4d3183ed151..065fa83c51c 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -824,47 +824,60 @@ nir_block_ends_in_continue(nir_block *block)
   * The continue should then be removed by nir_opt_trivial_continues() and the
   * loop can potentially be unrolled.
   *
- * Note: do_work_2() is only ever blocks and nested loops. We could also nest
- * other if-statments in the branch which would allow further continues to
- * be removed. However in practice this can result in increased register
- * pressure.
+ * Note: Unless the function param aggressive_last_continue==true do_work_2()
+ * is only ever blocks and nested loops. We avoid nesting other if-statments
+ * in the branch as this can result in increased register pressure, and in
+ * the i965 driver it causes a large amount of spilling in shader-db.
+ * For RADV however nesting these if-statements allows further continues to be
+ * remove and provides a significant FPS boost in Doom, which is why we have
+ * opted for this special bool to enable for more aggresive optimisation.
+ * TODO: The GCM pass solves most of the spilling regressions in i965, if it
+ * is ever enabled we should consider removing the aggressive_last_continue
+ * param.
   */
  static bool
-opt_if_loop_last_continue(nir_loop *loop)
+opt_if_loop_last_continue(nir_loop *loop, bool aggressive_last_continue)
  {
-   /* Get the last if-stament in the loop */
+   nir_if *nif;
+   bool then_ends_in_continue;
+   bool else_ends_in_continue;
+
+   /* Scan the control flow of the loop from the last to the first node
+* looking for an if-statement we can optimise.
+*/
 nir_block *last_block = nir_loop_last_block(loop);
 nir_cf_node *if_node = nir_cf_node_prev(&last_block->cf_node);
 while (if_node) {
-  if (if_node->type == nir_cf_node_if)
- break;
+  if (if_node->type == nir_c

[Mesa-dev] [PATCH] glsl: fix shader_storage_blocks_write_access for SSBO block arrays

[Marek Olšák]

From: Marek Olšák 

CTS: GL45-CTS.compute_shader.resources-max

Fixes: 4e1e8f684bf "glsl: remember which SSBOs are not read-only and pass it to 
gallium"
---
 src/compiler/glsl/link_uniforms.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/link_uniforms.cpp 
b/src/compiler/glsl/link_uniforms.cpp
index ef124111991..bbd71593948 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -537,22 +537,26 @@ public:
 for (unsigned i = 0; i < num_blks; i++) {
if (strcmp(var->get_interface_type()->name, blks[i].Name) == 0) 
{
   buffer_block_index = i;
   break;
}
 }
  }
  assert(buffer_block_index != -1);
 
  if (var->is_in_shader_storage_block() &&
- !var->data.memory_read_only)
-shader_storage_blocks_write_access |= 1 << buffer_block_index;
+ !var->data.memory_read_only) {
+shader_storage_blocks_write_access |=
+   u_bit_consecutive(buffer_block_index,
+ var->type->is_array() ?
+var->type->array_size() : 1);
+ }
 
  /* Uniform blocks that were specified with an instance name must be
   * handled a little bit differently.  The name of the variable is the
   * name used to reference the uniform block instead of being the name
   * of a variable within the block.  Therefore, searching for the name
   * within the block will fail.
   */
  if (var->is_interface_instance()) {
 ubo_byte_offset = 0;
 process(var->get_interface_type(),
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

[Dylan Baker]

It would be nice if people wouldn't try to build bleeding edge mesa on a 12 year
old distro :D. Unfortunately as Eero ppoints out they do. I'd like to bump the
meson version to 0.47 in the future for some of the other features it adds
(automatically figuring out the dependencies for pkg-config, feature options,
etc), but that'll have to wait a bit for distros to catch up.

We've actually talked about removing these deprecation warnings in cases where
the minimum version doesn't have the recommended replacement, but that's hard.

Dylan

Quoting Eero Tamminen (2019-04-08 04:16:49)
> Hi,
> 
> On 6.4.2019 11.44, Khaled Emara wrote:
> > Sorry, I though LTS distros used old versions of mesa.
> > Got it.
> 
> Those *provide* older Mesa version, so naturally people want to build
> latest Mesa on them (especially if they've just bought HW that isn't
> supported by distro version of Mesa).  Building would fail if Mesa would
> require newer Meson version than the one in the distro.
> 
> 
> - Eero
> 
> PS. On Ubuntu 18.04 LTS, one can install 0.47 Meson binary package
> from 18.10, it works fine.  Maybe something similar can be done also
> on other LTS distros.
> 
> > On Sat, Apr 6, 2019 at 12:38 AM Dylan Baker  > > wrote:
> > 
> > Quoting Khaled Emara (2019-04-05 11:28:28)
> >  > Upgraded meson's minimum version from 0.45 to 0.47
> >  > Version 0.47 is required to use build_always_stale
> >  > ---
> >  >  meson.build | 2 +-
> >  >  1 file changed, 1 insertion(+), 1 deletion(-)
> >  >
> >  > diff --git a/meson.build b/meson.build
> >  > index 2c98e9e18a9..454928e244a 100644
> >  > --- a/meson.build
> >  > +++ b/meson.build
> >  > @@ -25,7 +25,7 @@ project(
> >  >      [find_program('python', 'python2', 'python3'),
> > 'bin/meson_get_version.py']
> >  >    ).stdout(),
> >  >    license : 'MIT',
> >  > -  meson_version : '>= 0.45',
> >  > +  meson_version : '>= 0.47',
> >  >    default_options : ['buildtype=debugoptimized',
> > 'b_ndebug=if-release', 'c_std=c99', 'cpp_std=c++11']
> >  >  )
> >  >
> >  > --
> >  > 2.21.0
> >  >
> >  > ___
> >  > mesa-dev mailing list
> >  > mesa-dev@lists.freedesktop.org
> > 
> >  > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > Unfortunately we can't bump the minimum version at the moment, there
> > are a
> > couple of LTS distros we need support for that only ship 0.45.x
> > currently. As an
> > upstream meson dev, we have no time table in place for the removal of
> > build_always.
> > 
> > Dylan
> > 
> > 
> > ___
> > 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


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] radeonsi: fix a crash when unbinding sampler states

[Dieter Nützel]

SOLVED it.

Thanks to both of you!

Dieter

Am 08.04.2019 21:12, schrieb James Zhu:

This patch is Acked-by: James Zhu 

On 2019-04-08 3:02 p.m., Marek Olšák wrote:


On Mon, Apr 8, 2019 at 2:45 PM James Zhu  wrote:

On 2019-04-08 2:39 p.m., Marek Olšák wrote:

On Mon, Apr 8, 2019 at 2:33 PM James Zhu  wrote:

On 2019-04-08 2:25 p.m., Marek Olšák wrote:

From: Marek Olšák 

---
src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c

b/src/gallium/drivers/radeonsi/si_descriptors.c

index 244ba5a7bec..ac40ed27f91 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -942,21 +942,21 @@ void si_update_ps_colorbuf0_slot(struct

si_context *sctx)

static void si_bind_sampler_states(struct pipe_context *ctx,
enum pipe_shader_type shader,
unsigned start, unsigned

count, void **states)

{
struct si_context *sctx = (struct si_context *)ctx;
struct si_samplers *samplers = &sctx->samplers[shader];
struct si_descriptors *desc =

si_sampler_and_image_descriptors(sctx, shader);

struct si_sampler_state **sstates = (struct

si_sampler_state**)states;

int i;

- if (!count || shader >= SI_NUM_SHADERS)
+ if (!count || shader >= SI_NUM_SHADERS || !sstates)


if sstates == NULL, it means we want to unbind
samplers->sampler_states
from current setting.

So I think it is better not just bypass it.

The driver never unbinds constant state objects. If sstates[i] ==
NULL, it's not unbound. sstates == NULL is a similar case.


Then we should not call unbind sampler state after compute shader
launch. Since it is doing nothing.
You are right.

Marek
___
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 00/26] RadeonSI: Primitive culling with async compute

[Dieter Nützel]

After you've recuperated from hopefully GREAT vacation,

is it time? ;-)

Greetings,
Dieter

Am 26.02.2019 03:31, schrieb Dieter Nützel:

Hello Marek,

do you plan to commit or rebase both set?

Dieter

Am 14.02.2019 07:29, schrieb Marek Olšák:

I have some fixes for Sea Islands that improve Radeon 290X performance
to 43 fps, moving it just below Radeon VII in the picture.

Marek

On Wed, Feb 13, 2019 at 12:16 AM Marek Olšák 
wrote:


Hi,

This patch series uses async compute to do primitive culling before
the vertex shader. It significantly improves performance for
applications
that use a lot of geometry that is invisible because primitives
don't
intersect sample points or there are a lot of back faces, etc.

It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100%
stable.
It supports all chips all the way from Sea Islands to Radeon VII.

As you can see in the results marked (ENABLED) in the picture below,
it destroys our competition (The GeForce results are from a Phoronix
article from 2017, the latest ones I could find):

Benchmark: ParaView - Many Spheres - 2560x1440
https://people.freedesktop.org/~mareko/prim-discard-cs-results.png

The last patch describes the implementation and functional
limitations
if you can find the huge code comment, so I'm not gonna do that
here.

I decided to enable this optimization on all Pro graphics cards.
The reason is that I haven't had time to benchmark games.
This decision may be changed based on community feedback, etc.

People using the Pro graphics cards can disable this by setting
AMD_DEBUG=nopd, and people using consumer graphics cards can enable
this by setting AMD_DEBUG=pd. So you always have a choice.

Eventually we might also enable this on consumer graphics cards for
those
games that benefit. It might decrease performance if there is not
enough
invisible geometry.

Branch:
https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs

Please review.

Thanks,
Marek

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

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

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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Maybe someone working on this, too.

I'm feeling fine again after a short 'trip' into the hospital...;-)

Dieter

Am 26.02.2019 07:36, schrieb Marek Olšák:

We need to extend the CS ioctl to allow submitting 2 command buffers
at the same time.

Marek

On Mon, Feb 25, 2019, 10:06 PM Dieter Nützel 
wrote:


Hello Marek,

you wrote with your series sent:

[-]
Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that
wasn't
there before.
[-]

Any ideas to speed this up, again?
glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
Or are micro benchmarks not worth more effort?

Dieter

SDMA
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0,
5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel
(git-a9b32aaa16)
===
[build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
[build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
[texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
[texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
[texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
[shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
[shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
[shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
[shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
[bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
[bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
[bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854
FrameTime:
0.101 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime:
0.118
ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop]
blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 5181 FrameTime: 0.193 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
[buffer]


columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 824 FrameTime: 1.214 ms
[buffer]


columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:


FPS: 1114 FrameTime: 0.898 ms
[buffer]


columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 899 FrameTime: 1.112 ms
[ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
[jellyfish] : FPS: 7992 FrameTime: 0.125 ms
[terrain] : FPS: 1796 FrameTime: 0.557 ms
[shadow] : FPS: 7350 FrameTime: 0.136 ms
[refract] : FPS: 3595 FrameTime: 0.278 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401 FrameTime:

0.106 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413 FrameTime:

0.106 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417 FrameTime:

0.106 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 9365
FrameTime: 0.107 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 9451
FrameTime: 0.106 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS:
9300
FrameTime: 0.108 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS:
9440
FrameTime: 0.106 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS:
9392
FrameTime: 0.106 ms
===
glmark2 Score: 7455
===

Before
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0,
4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel
(git-c49b3df3cb)
===
[build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms
[texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms
[texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms
[texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms
[shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms
[shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms
[shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms
[shading] shading=cel: FPS: 12735 FrameTime: 0.079 ms
[bump] bump-render=high-poly: FPS: 11412 FrameTime: 0.088 ms
[bump] bump-render=normals: FPS: 12467 FrameTime: 0.080 ms
[bump] bump-render=height: FPS: 12422 FrameTime: 0.081 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,

[Mesa-dev] [Bug 109615] 19.0.0_rc4 fails u_format_test on ppc64

[bugzilla-daemon]

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

--- Comment #7 from Matt Turner  ---
No surprise: it's endianness dependent. Passes on little endian; fails on big
endian.

-- 
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] intel/compiler/icl: Use tcs barrier id bits 24:30 instead of 24:27

[Anuj Phogat]

On Wed, Mar 27, 2019 at 9:47 AM Topi Pohjolainen
 wrote:
>
> Similarly to 1cc17fb731466c68586915acbb916586457b19bc
>
> Fixes gpu hangs with dEQP-VK.tessellation.shader_input_output.barrier
>
> CC: Anuj Phogat 
> CC: Clayton Craft 
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index 747529e72d8..ee8274de65a 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -2458,15 +2458,24 @@ fs_visitor::nir_emit_tcs_intrinsic(const fs_builder 
> &bld,
>bld.exec_all().MOV(m0, brw_imm_ud(0u));
>
>/* Copy "Barrier ID" from r0.2, bits 16:13 */
> -  chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
> -  brw_imm_ud(INTEL_MASK(16, 13)));
> +  if (devinfo->gen < 11) {
> + chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
> + brw_imm_ud(INTEL_MASK(16, 13)));
>
> -  /* Shift it up to bits 27:24. */
> -  chanbld.SHL(m0_2, m0_2, brw_imm_ud(11));
> + /* Shift it up to bits 27:24. */
> + chanbld.SHL(m0_2, m0_2, brw_imm_ud(11));
> +  } else {
> + chanbld.AND(m0_2, retype(brw_vec1_grf(0, 2), BRW_REGISTER_TYPE_UD),
> + brw_imm_ud(INTEL_MASK(30, 24)));
> +  }
>
>/* Set the Barrier Count and the enable bit */
> -  chanbld.OR(m0_2, m0_2,
> - brw_imm_ud(tcs_prog_data->instances << 9 | (1 << 15)));
> +  if (devinfo->gen < 11)
> + chanbld.OR(m0_2, m0_2,
> +brw_imm_ud(tcs_prog_data->instances << 9 | (1 << 15)));
> +  else
> + chanbld.OR(m0_2, m0_2,
> +brw_imm_ud(tcs_prog_data->instances << 8 | (1 << 15)));
>
>bld.emit(SHADER_OPCODE_BARRIER, bld.null_reg_ud(), m0);
>break;
> --
> 2.13.6
>

Fixes the gpu hang.
Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109615] 19.0.0_rc4 fails u_format_test on ppc64

[bugzilla-daemon]

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

--- Comment #8 from A. Wilcox  ---
Is this an actual endian bug in Mesa, or do the test constants need to be
adjusted based on byte order?

-- 
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 109615] 19.0.0_rc4 fails u_format_test on ppc64

[bugzilla-daemon]

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

A. Wilcox  changed:

   What|Removed |Added

 CC||awil...@adelielinux.org
Version|unspecified |19.0

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

Re: [Mesa-dev] gitlab: Let's delete a buildsystem

[Jan Vesely]

Hi,

is there a release with that change planned any time soon?

thanks,
Jan

On Mon, Apr 8, 2019 at 4:23 PM Dylan Baker  wrote:
>
> As per the discussion last time around, the last feature meson needed to grow 
> to
> be able to remove autotools was support for remembering PKG_CONFIG_PATH, since
> that has landed: https://github.com/mesonbuild/meson/pull/4931, so I'm sending
> this out again.
>
> The gitlab link for the PR is here:
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601
>
> Dylan
> ___
> 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 00/26] RadeonSI: Primitive culling with async compute

[Marek Olšák]

Hi Dieter,

The latest version is on gitlab as a merge request.

Marek

On Mon, Apr 8, 2019 at 6:06 PM Dieter Nützel  wrote:

> After you've recuperated from hopefully GREAT vacation,
>
> is it time? ;-)
>
> Greetings,
> Dieter
>
> Am 26.02.2019 03:31, schrieb Dieter Nützel:
> > Hello Marek,
> >
> > do you plan to commit or rebase both set?
> >
> > Dieter
> >
> > Am 14.02.2019 07:29, schrieb Marek Olšák:
> >> I have some fixes for Sea Islands that improve Radeon 290X performance
> >> to 43 fps, moving it just below Radeon VII in the picture.
> >>
> >> Marek
> >>
> >> On Wed, Feb 13, 2019 at 12:16 AM Marek Olšák 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> This patch series uses async compute to do primitive culling before
> >>> the vertex shader. It significantly improves performance for
> >>> applications
> >>> that use a lot of geometry that is invisible because primitives
> >>> don't
> >>> intersect sample points or there are a lot of back faces, etc.
> >>>
> >>> It passes 99.% of all tests (GL CTS, dEQP, piglit) and is 100%
> >>> stable.
> >>> It supports all chips all the way from Sea Islands to Radeon VII.
> >>>
> >>> As you can see in the results marked (ENABLED) in the picture below,
> >>> it destroys our competition (The GeForce results are from a Phoronix
> >>> article from 2017, the latest ones I could find):
> >>>
> >>> Benchmark: ParaView - Many Spheres - 2560x1440
> >>> https://people.freedesktop.org/~mareko/prim-discard-cs-results.png
> >>>
> >>> The last patch describes the implementation and functional
> >>> limitations
> >>> if you can find the huge code comment, so I'm not gonna do that
> >>> here.
> >>>
> >>> I decided to enable this optimization on all Pro graphics cards.
> >>> The reason is that I haven't had time to benchmark games.
> >>> This decision may be changed based on community feedback, etc.
> >>>
> >>> People using the Pro graphics cards can disable this by setting
> >>> AMD_DEBUG=nopd, and people using consumer graphics cards can enable
> >>> this by setting AMD_DEBUG=pd. So you always have a choice.
> >>>
> >>> Eventually we might also enable this on consumer graphics cards for
> >>> those
> >>> games that benefit. It might decrease performance if there is not
> >>> enough
> >>> invisible geometry.
> >>>
> >>> Branch:
> >>> https://cgit.freedesktop.org/~mareko/mesa/log/?h=prim-discard-cs
> >>>
> >>> Please review.
> >>>
> >>> Thanks,
> >>> Marek
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Marek Olšák]

I'm pretty sure I merged this series in February.

Marek

On Mon, Apr 8, 2019 at 6:10 PM Dieter Nützel  wrote:

> Maybe someone working on this, too.
>
> I'm feeling fine again after a short 'trip' into the hospital...;-)
>
> Dieter
>
> Am 26.02.2019 07:36, schrieb Marek Olšák:
> > We need to extend the CS ioctl to allow submitting 2 command buffers
> > at the same time.
> >
> > Marek
> >
> > On Mon, Feb 25, 2019, 10:06 PM Dieter Nützel 
> > wrote:
> >
> >> Hello Marek,
> >>
> >> you wrote with your series sent:
> >>
> >> [-]
> >> Trivial benchmarks such as glxgears can expect 20% decrease
> >> in performance due to the added cost of the SDMA CS ioctl that
> >> wasn't
> >> there before.
> >> [-]
> >>
> >> Any ideas to speed this up, again?
> >> glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
> >> Or are micro benchmarks not worth more effort?
> >>
> >> Dieter
> >>
> >> SDMA
> >> ===
> >> glmark2 2017.07
> >> ===
> >> OpenGL Information
> >> GL_VENDOR: X.Org
> >> GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0,
> >> 5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
> >> GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel
> >> (git-a9b32aaa16)
> >> ===
> >> [build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
> >> [build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
> >> [texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
> >> [texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
> >> [texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
> >> [shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
> >> [shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
> >> [shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
> >> [shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
> >> [bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
> >> [bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
> >> [bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
> >> libpng warning: iCCP: known incorrect sRGB profile
> >> [effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101 ms
> >> libpng warning: iCCP: known incorrect sRGB profile
> >> [effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854
> >> FrameTime:
> >> 0.101 ms
> >> [pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime:
> >> 0.118
> >> ms
> >> libpng warning: iCCP: known incorrect sRGB profile
> >> [desktop]
> >> blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
> >> FPS: 5181 FrameTime: 0.193 ms
> >> libpng warning: iCCP: known incorrect sRGB profile
> >> [desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
> >> [buffer]
> >>
> >
> columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:
> >>
> >> FPS: 824 FrameTime: 1.214 ms
> >> [buffer]
> >>
> >
> columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:
> >>
> >> FPS: 1114 FrameTime: 0.898 ms
> >> [buffer]
> >>
> >
> columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:
> >>
> >> FPS: 899 FrameTime: 1.112 ms
> >> [ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
> >> [jellyfish] : FPS: 7992 FrameTime: 0.125 ms
> >> [terrain] : FPS: 1796 FrameTime: 0.557 ms
> >> [shadow] : FPS: 7350 FrameTime: 0.136 ms
> >> [refract] : FPS: 3595 FrameTime: 0.278 ms
> >> [conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401 FrameTime:
> >>
> >> 0.106 ms
> >> [conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413 FrameTime:
> >>
> >> 0.106 ms
> >> [conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417 FrameTime:
> >>
> >> 0.106 ms
> >> [function] fragment-complexity=low:fragment-steps=5: FPS: 9365
> >> FrameTime: 0.107 ms
> >> [function] fragment-complexity=medium:fragment-steps=5: FPS: 9451
> >> FrameTime: 0.106 ms
> >> [loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS:
> >> 9300
> >> FrameTime: 0.108 ms
> >> [loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS:
> >> 9440
> >> FrameTime: 0.106 ms
> >> [loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS:
> >> 9392
> >> FrameTime: 0.106 ms
> >> ===
> >> glmark2 Score: 7455
> >> ===
> >>
> >> Before
> >> ===
> >> glmark2 2017.07
> >> ===
> >> OpenGL Information
> >> GL_VENDOR: X.Org
> >> GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0,
> >> 4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
> >> GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel
> >> (git-c49b3df3cb)
> >> ===
> >> [build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
> >> [build] use-vbo=true: FPS: 1

[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon

-- 
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] glsl: fix shader_storage_blocks_write_access for SSBO block arrays

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 9/4/19 7:21 am, Marek Olšák wrote:

From: Marek Olšák 

CTS: GL45-CTS.compute_shader.resources-max

Fixes: 4e1e8f684bf "glsl: remember which SSBOs are not read-only and pass it to 
gallium"
---
  src/compiler/glsl/link_uniforms.cpp | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/compiler/glsl/link_uniforms.cpp 
b/src/compiler/glsl/link_uniforms.cpp
index ef124111991..bbd71593948 100644
--- a/src/compiler/glsl/link_uniforms.cpp
+++ b/src/compiler/glsl/link_uniforms.cpp
@@ -537,22 +537,26 @@ public:
  for (unsigned i = 0; i < num_blks; i++) {
 if (strcmp(var->get_interface_type()->name, blks[i].Name) == 
0) {
buffer_block_index = i;
break;
 }
  }
   }
   assert(buffer_block_index != -1);
  
   if (var->is_in_shader_storage_block() &&

- !var->data.memory_read_only)
-shader_storage_blocks_write_access |= 1 << buffer_block_index;
+ !var->data.memory_read_only) {
+shader_storage_blocks_write_access |=
+   u_bit_consecutive(buffer_block_index,
+ var->type->is_array() ?
+var->type->array_size() : 1);
+ }
  
   /* Uniform blocks that were specified with an instance name must be

* handled a little bit differently.  The name of the variable is the
* name used to reference the uniform block instead of being the name
* of a variable within the block.  Therefore, searching for the name
* within the block will fail.
*/
   if (var->is_interface_instance()) {
  ubo_byte_offset = 0;
  process(var->get_interface_type(),


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

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Dieter Nützel]

Am 09.04.2019 02:42, schrieb Marek Olšák:

I'm pretty sure I merged this series in February.

Marek


Yes, of course you did (with my tb), but I meant... (see below)


On Mon, Apr 8, 2019 at 6:10 PM Dieter Nützel 
wrote:


Maybe someone working on this, too.

I'm feeling fine again after a short 'trip' into the hospital...;-)

Dieter

Am 26.02.2019 07:36, schrieb Marek Olšák:

We need to extend the CS ioctl to allow submitting 2 command

buffers

at the same time.


This additional work.

Dieter


Marek

On Mon, Feb 25, 2019, 10:06 PM Dieter Nützel



wrote:


Hello Marek,

you wrote with your series sent:

[-]
Trivial benchmarks such as glxgears can expect 20% decrease
in performance due to the added cost of the SDMA CS ioctl that
wasn't
there before.
[-]

Any ideas to speed this up, again?
glmark2 went from 9766 (best ever) down to 7455 (all with NIR).
Or are micro benchmarks not worth more effort?

Dieter

SDMA
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.30.0,
5.0.0-rc1-1.g7262353-default+, LLVM 9.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.0-devel
(git-a9b32aaa16)
===
[build] use-vbo=false: FPS: 3694 FrameTime: 0.271 ms
[build] use-vbo=true: FPS: 9341 FrameTime: 0.107 ms
[texture] texture-filter=nearest: FPS: 9140 FrameTime: 0.109 ms
[texture] texture-filter=linear: FPS: 9163 FrameTime: 0.109 ms
[texture] texture-filter=mipmap: FPS: 9161 FrameTime: 0.109 ms
[shading] shading=gouraud: FPS: 9234 FrameTime: 0.108 ms
[shading] shading=blinn-phong-inf: FPS: 9255 FrameTime: 0.108 ms
[shading] shading=phong: FPS: 9226 FrameTime: 0.108 ms
[shading] shading=cel: FPS: 9310 FrameTime: 0.107 ms
[bump] bump-render=high-poly: FPS: 9298 FrameTime: 0.108 ms
[bump] bump-render=normals: FPS: 9121 FrameTime: 0.110 ms
[bump] bump-render=height: FPS: 9120 FrameTime: 0.110 ms
libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 9858 FrameTime: 0.101

ms

libpng warning: iCCP: known incorrect sRGB profile
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 9854
FrameTime:
0.101 ms
[pulsar] light=false:quads=5:texture=false: FPS: 8468 FrameTime:
0.118
ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop]
blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 5181 FrameTime: 0.193 ms
libpng warning: iCCP: known incorrect sRGB profile
[desktop] effect=shadow:windows=4: FPS: 5374 FrameTime: 0.186 ms
[buffer]






columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 824 FrameTime: 1.214 ms
[buffer]






columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata:


FPS: 1114 FrameTime: 0.898 ms
[buffer]






columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map:


FPS: 899 FrameTime: 1.112 ms
[ideas] speed=duration: FPS: 3485 FrameTime: 0.287 ms
[jellyfish] : FPS: 7992 FrameTime: 0.125 ms
[terrain] : FPS: 1796 FrameTime: 0.557 ms
[shadow] : FPS: 7350 FrameTime: 0.136 ms
[refract] : FPS: 3595 FrameTime: 0.278 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 9401

FrameTime:


0.106 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 9413

FrameTime:


0.106 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 9417

FrameTime:


0.106 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 9365
FrameTime: 0.107 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 9451
FrameTime: 0.106 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS:
9300
FrameTime: 0.108 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5:

FPS:

9440
FrameTime: 0.106 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5:

FPS:

9392
FrameTime: 0.106 ms
===
glmark2 Score: 7455
===

Before
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Radeon RX 580 Series (POLARIS10, DRM 3.27.0,
4.20.0-rc3-1.g7262353-default+, LLVM 8.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.0.0-devel
(git-c49b3df3cb)
===
[build] use-vbo=false: FPS: 3373 FrameTime: 0.296 ms
[build] use-vbo=true: FPS: 13121 FrameTime: 0.076 ms
[texture] texture-filter=nearest: FPS: 12172 FrameTime: 0.082 ms
[texture] texture-filter=linear: FPS: 12557 FrameTime: 0.080 ms
[texture] texture-filter=mipmap: FPS: 12228 FrameTime: 0.082 ms
[shading] shading=gouraud: FPS: 12536 FrameTime: 0.080 ms
[shading] shading=blinn-phong-inf: FPS: 12782 FrameTime: 0.078 ms
[shading] shading=phong: FPS: 12619 FrameTime: 0.079 ms
[shading] shading=c

[Mesa-dev] [Bug 110337] Mesa 19.0.0(1)

[bugzilla-daemon]

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

Berg  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
  Component|Drivers/Gallium/radeonsi|Drivers/X11
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

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

[Mesa-dev] [Bug 110350] DOOM 2016 crash + severe artifacting on RADV + Vega VII

[bugzilla-daemon]

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

--- Comment #3 from Thomas Crider  ---
https://youtu.be/9dtlKTMGqTE

game didn't crash this time, and at least i was able to capture it

-- 
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] gallium: Add support for frame_cropping_flag of VAEncSequenceParameterBufferH264

[Sahu, Satyajit]

On 4/9/2019 12:34 AM, Liu, Leo wrote:
> On 4/8/19 1:17 AM, Sahu, Satyajit wrote:
>> From: suresh guttula 
>>
>> This patch will add support for frame_cropping when the input size is not
>> matched with aligned size. Currently vaapi driver ignores frame cropping
>> values provided by client. This change will update SPS nalu with proper
>> cropping values.
>>
>> Signed-off-by: suresh guttula 
>> Signed-off-by: Satyajit Sahu 
>> ---
>>src/gallium/drivers/radeon/radeon_vce_52.c   | 8 ++--
>>src/gallium/include/pipe/p_video_state.h | 5 +
>>src/gallium/state_trackers/va/picture_h264_enc.c | 8 
>>3 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/drivers/radeon/radeon_vce_52.c 
>> b/src/gallium/drivers/radeon/radeon_vce_52.c
>> index fc7ddc62a90..593730756d5 100644
>> --- a/src/gallium/drivers/radeon/radeon_vce_52.c
>> +++ b/src/gallium/drivers/radeon/radeon_vce_52.c
>> @@ -81,8 +81,12 @@ static void get_pic_control_param(struct rvce_encoder 
>> *enc, struct pipe_h264_enc
>>  unsigned encNumMBsPerSlice;
>>  encNumMBsPerSlice = align(enc->base.width, 16) / 16;
>>  encNumMBsPerSlice *= align(enc->base.height, 16) / 16;
>> -enc->enc_pic.pc.enc_crop_right_offset = (align(enc->base.width, 16) - 
>> enc->base.width) >> 1;
>> -enc->enc_pic.pc.enc_crop_bottom_offset = (align(enc->base.height, 16) - 
>> enc->base.height) >> 1;
> Shouldn't we need to keep this code path when the cropping info is not
> available, since VA spec says it's optional.
>
> Regards,
>
> Leo

As per H264 standard

When frame_cropping_flag is equal to 0, the values of 
frame_crop_left_offset, frame_crop_right_offset, frame_crop_top_offset, 
and frame_crop_bottom_offset shall be inferred to be equal to 0. 
(https://www.itu.int/rec/T-REC-H.264)

So I think it should be under frame_cropping_flag condition.

Regards,

Satyajit

>
>
>
>> +if (pic->pic_ctrl.enc_frame_cropping_flag) {
>> +enc->enc_pic.pc.enc_crop_left_offset = 
>> pic->pic_ctrl.enc_frame_crop_left_offset;
>> +enc->enc_pic.pc.enc_crop_right_offset = 
>> pic->pic_ctrl.enc_frame_crop_right_offset;
>> +enc->enc_pic.pc.enc_crop_top_offset = 
>> pic->pic_ctrl.enc_frame_crop_top_offset;
>> +enc->enc_pic.pc.enc_crop_bottom_offset = 
>> pic->pic_ctrl.enc_frame_crop_bottom_offset;
>> +}
>>  enc->enc_pic.pc.enc_num_mbs_per_slice = encNumMBsPerSlice;
>>  enc->enc_pic.pc.enc_b_pic_pattern = MAX2(enc->base.max_references, 1) - 
>> 1;
>>  enc->enc_pic.pc.enc_number_of_reference_frames = 
>> MIN2(enc->base.max_references, 2);
>> diff --git a/src/gallium/include/pipe/p_video_state.h 
>> b/src/gallium/include/pipe/p_video_state.h
>> index 05855a36e23..1369f1a8ca6 100644
>> --- a/src/gallium/include/pipe/p_video_state.h
>> +++ b/src/gallium/include/pipe/p_video_state.h
>> @@ -395,6 +395,11 @@ struct pipe_h264_enc_pic_control
>>{
>>   unsigned enc_cabac_enable;
>>   unsigned enc_constraint_set_flags;
>> +   unsigned enc_frame_cropping_flag;
>> +   unsigned enc_frame_crop_left_offset;
>> +   unsigned enc_frame_crop_right_offset;
>> +   unsigned enc_frame_crop_top_offset;
>> +   unsigned enc_frame_crop_bottom_offset;
>>};
>>
>>struct pipe_h264_enc_picture_desc
>> diff --git a/src/gallium/state_trackers/va/picture_h264_enc.c 
>> b/src/gallium/state_trackers/va/picture_h264_enc.c
>> index abfd39633de..f46b3425566 100644
>> --- a/src/gallium/state_trackers/va/picture_h264_enc.c
>> +++ b/src/gallium/state_trackers/va/picture_h264_enc.c
>> @@ -127,6 +127,14 @@ 
>> vlVaHandleVAEncSequenceParameterBufferTypeH264(vlVaDriver *drv, vlVaContext 
>> *con
>>   context->desc.h264enc.rate_ctrl.frame_rate_num = h264->time_scale / 2;
>>   context->desc.h264enc.rate_ctrl.frame_rate_den = 
>> h264->num_units_in_tick;
>>   context->desc.h264enc.pic_order_cnt_type = 
>> h264->seq_fields.bits.pic_order_cnt_type;
>> +
>> +   if (h264->frame_cropping_flag) {
>> +  context->desc.h264enc.pic_ctrl.enc_frame_cropping_flag = 
>> h264->frame_cropping_flag;
>> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_left_offset = 
>> h264->frame_crop_left_offset;
>> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_right_offset = 
>> h264->frame_crop_right_offset;
>> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_top_offset = 
>> h264->frame_crop_top_offset;
>> +  context->desc.h264enc.pic_ctrl.enc_frame_crop_bottom_offset = 
>> h264->frame_crop_bottom_offset;
>> +   }
>>   return VA_STATUS_SUCCESS;
>>}
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv: allow to force enable vsync with RADV_VSYNC=1

[Jason Ekstrand]

Why not just do this in a way that common to the two drivers? Forcing FIFO 
and MAILBOX both seem useful. For that matter, why not just 
MESA_VK_WSI_PRESENT_MODE=FIFO/mailbox/immediate?


On April 8, 2019 13:39:20 Samuel Pitoiset  wrote:


Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107391
Signed-off-by: Samuel Pitoiset 
---
src/amd/vulkan/radv_wsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2fd07447668..7651043b2b2 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -38,11 +38,13 @@ radv_wsi_proc_addr(VkPhysicalDevice physicalDevice, 
const char *pName)

VkResult
radv_init_wsi(struct radv_physical_device *physical_device)
{
+   bool vsync = !!env_var_as_unsigned("RADV_VSYNC", 0);
+
return wsi_device_init(&physical_device->wsi_device,
   radv_physical_device_to_handle(physical_device),
   radv_wsi_proc_addr,
   &physical_device->instance->alloc,
-  physical_device->master_fd, false);
+  physical_device->master_fd, vsync);
}

void
--
2.21.0

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




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

Re: [Mesa-dev] [PATCH v2] virgl: Use right key to insert resource to hash.

[Dave Airlie]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/605

Can you try that please and maybe discuss there as well? I cleaned up
the code a bit and realigned it with the radeon code.

Dave.

On Tue, 9 Apr 2019 at 04:44, Chia-I Wu  wrote:
>
>
>
> On Mon, Apr 8, 2019 at 11:24 AM Lepton Wu  wrote:
>>
>> On Mon, Apr 8, 2019 at 11:10 AM Chia-I Wu  wrote:
>> >
>> >
>> >
>> > On Mon, Apr 8, 2019 at 9:34 AM Lepton Wu  wrote:
>> >>
>> >> The old code could use gem name as key when inserting it to bo_handles
>> >> hash table while trying to remove it from hash table with bo_handle as
>> >> key in virgl_hw_res_destroy and then it fail to remove it from bo_handles
>> >> hash table. This triggers use after free. Also, we should insert resource
>> >> to bo_names hash table when handle type is SHARED.
>> >>
>> >> Signed-off-by: Lepton Wu 
>> >> ---
>> >>  .../winsys/virgl/drm/virgl_drm_winsys.c   | 24 +--
>> >>  1 file changed, 17 insertions(+), 7 deletions(-)
>> >>
>> >> diff --git a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c 
>> >> b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> >> index 2cf8b4ba076..af92b6a98fc 100644
>> >> --- a/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> >> +++ b/src/gallium/winsys/virgl/drm/virgl_drm_winsys.c
>> >> @@ -406,6 +406,12 @@ virgl_drm_winsys_resource_create_handle(struct 
>> >> virgl_winsys *qws,
>> >>return NULL;
>> >> }
>> >>
>> >> +   if (whandle->type != WINSYS_HANDLE_TYPE_FD &&
>> >> +   whandle->type != WINSYS_HANDLE_TYPE_SHARED) {
>> >> +  fprintf(stderr, "Unexpected handle type: %d\n", whandle->type);
>> >> +  return NULL;
>> >> +   }
>> >> +
>> >> mtx_lock(&qdws->bo_handles_mutex);
>> >>
>> >> if (whandle->type == WINSYS_HANDLE_TYPE_SHARED) {
>> >> @@ -424,13 +430,13 @@ virgl_drm_winsys_resource_create_handle(struct 
>> >> virgl_winsys *qws,
>> >>   res = NULL;
>> >>   goto done;
>> >>}
>> >> -   }
>> >>
>> >> -   res = util_hash_table_get(qdws->bo_handles, (void*)(uintptr_t)handle);
>> >> -   if (res) {
>> >> -  struct virgl_hw_res *r = NULL;
>> >> -  virgl_drm_resource_reference(qdws, &r, res);
>> >> -  goto done;
>> >> +  res = util_hash_table_get(qdws->bo_handles, 
>> >> (void*)(uintptr_t)handle);
>> >> +  if (res) {
>> >> + struct virgl_hw_res *r = NULL;
>> >> + virgl_drm_resource_reference(qdws, &r, res);
>> >> + goto done;
>> >> +  }
>> >> }
>> >>
>> > You can still run into troubles when asked to import a buffer by both its 
>> > prime fd and its flink name.
>> But it seems there is no way to fix it at user space, right? Every
>> time we got a flink name for
>> the first time, kernel will give a new handle and no way to  reuse any
>> res from hash table.
>
> Yeah, I think you are right... but that appears to be a kernel bug.  Once 
> kernel is fixed to return the same handle for the same flink name / prime fd, 
> we should be ready for that.  Let's see what Dave thinks.
>
>> >
>> >> res = CALLOC_STRUCT(virgl_hw_res);
>> >> @@ -448,6 +454,8 @@ virgl_drm_winsys_resource_create_handle(struct 
>> >> virgl_winsys *qws,
>> >>   goto done;
>> >>}
>> >>res->bo_handle = open_arg.handle;
>> >> +  res->flinked = true;
>> >> +  res->flink = whandle->handle;
>> >> }
>> >> res->name = handle;
>> >
>> > res->name has no user.  Remove it.
>> >
>> > It is also less confusing to make sure `handle' means GEM handle at this 
>> > point, by calling either GEM_OPEN or drmPrimeFDToHandle depending on the 
>> > handle type.
>> >
>> >>
>> >> @@ -469,7 +477,9 @@ virgl_drm_winsys_resource_create_handle(struct 
>> >> virgl_winsys *qws,
>> >> res->num_cs_references = 0;
>> >> res->fence_fd = -1;
>> >>
>> >> -   util_hash_table_set(qdws->bo_handles, (void *)(uintptr_t)handle, res);
>> >> +   util_hash_table_set(qdws->bo_handles, (void 
>> >> *)(uintptr_t)res->bo_handle, res);
>> >> +   if (whandle->type == WINSYS_HANDLE_TYPE_SHARED)
>> >> +  util_hash_table_set(qdws->bo_names, (void *)(uintptr_t)res->flink, 
>> >> res);
>> >>
>> >>  done:
>> >> mtx_unlock(&qdws->bo_handles_mutex);
>> >> --
>> >> 2.21.0.392.gf8f6787159e-goog
>> >>
>
> ___
> 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 v7 28/35] intel/compiler: implement SIMD16 restrictions for mixed-float instructions

[Iago Toral]

On Mon, 2019-04-08 at 12:00 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero"  writes:
> 
> > From: Iago Toral Quiroga 
> > 
> > v2: f32to16/f16to32 can use a :W destination (Curro)
> > ---
> >  src/intel/compiler/brw_fs.cpp | 71
> > +++
> >  1 file changed, 71 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_fs.cpp
> > b/src/intel/compiler/brw_fs.cpp
> > index d4803c63b93..48b5cc6c403 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -5606,6 +5606,48 @@ fs_visitor::lower_logical_sends()
> > return progress;
> >  }
> >  
> > +static bool
> > +is_mixed_float_with_fp32_dst(const fs_inst *inst)
> > +{
> > +   /* This opcode sometimes uses :W type on the source even if the
> > operand is
> > +* a :HF, because in gen7 there is no support for :HF, and thus
> > it uses :W.
> > +*/
> > +   if (inst->opcode == BRW_OPCODE_F16TO32)
> > +  return true;
> > +
> > +   if (inst->dst.type != BRW_REGISTER_TYPE_F)
> > +  return false;
> > +
> > +   for (int i = 0; i < inst->sources; i++) {
> > +  if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
> > + return true;
> > +   }
> > +
> > +   return false;
> > +}
> > +
> > +static bool
> > +is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
> > +{
> > +   /* This opcode sometimes uses :W type on the destination even
> > if the
> > +* destination is a :HF, because in gen7 there is no support
> > for :HF, and
> > +* thus it uses :W.
> > +*/
> > +   if (inst->opcode == BRW_OPCODE_F32TO16)
> 
> Don't you need to check whether the destination is packed here?

Yes, we also need that, like in the code below.

> > +  return true;
> > +
> > +   if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
> > +   inst->dst.stride != 1)
> > +  return false;
> > +
> > +   for (int i = 0; i < inst->sources; i++) {
> > +  if (inst->src[i].type == BRW_REGISTER_TYPE_F)
> > + return true;
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >  /**
> >   * Get the closest allowed SIMD width for instruction \p inst
> > accounting for
> >   * some common regioning and execution control restrictions that
> > apply to FPU
> > @@ -5768,6 +5810,35 @@ get_fpu_lowered_simd_width(const struct
> > gen_device_info *devinfo,
> >   max_width = MIN2(max_width, 4);
> > }
> >  
> > +   /* From the SKL PRM, Special Restrictions for Handling Mixed
> > Mode
> > +* Float Operations:
> > +*
> > +*"No SIMD16 in mixed mode when destination is f32.
> > Instruction
> > +* execution size must be no more than 8."
> > +*
> > +* FIXME: the simulator doesn't seem to complain if we don't do
> > this and
> > +* empirical testing with existing CTS tests show that they
> > pass just fine
> > +* without implementing this, however, since our interpretation
> > of the PRM
> > +* is that conversion MOVs between HF and F are still mixed-
> > float
> > +* instructions (and therefore subject to this restriction) we
> > decided to
> > +* split them to be safe. Might be useful to do additional
> > investigation to
> > +* lift the restriction if we can ensure that it is safe
> > though, since these
> > +* conversions are common when half-float types are involved
> > since many
> > +* instructions do not support HF types and conversions from/to
> > F are
> > +* required.
> > +*/
> > +   if (is_mixed_float_with_fp32_dst(inst))
> > +  max_width = MIN2(max_width, 8);
> > +
> > +   /* From the SKL PRM, Special Restrictions for Handling Mixed
> > Mode
> > +* Float Operations:
> > +*
> > +*"No SIMD16 in mixed mode when destination is packed f16
> > for both
> > +* Align1 and Align16."
> > +*/
> > +   if (is_mixed_float_with_packed_fp16_dst(inst))
> > +  max_width = MIN2(max_width, 8);
> > +
> > /* Only power-of-two execution sizes are representable in the
> > instruction
> >  * control fields.
> >  */
> > -- 
> > 2.20.1

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

Re: [Mesa-dev] [PATCH 2/2] radv: allow to force enable vsync with RADV_VSYNC=1

[Samuel Pitoiset]

On 4/9/19 6:45 AM, Jason Ekstrand wrote:
Why not just do this in a way that common to the two drivers? Forcing 
FIFO and MAILBOX both seem useful. For that matter, why not just 
MESA_VK_WSI_PRESENT_MODE=FIFO/mailbox/immediate?

Yes, looks fine.


On April 8, 2019 13:39:20 Samuel Pitoiset  
wrote:



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107391
Signed-off-by: Samuel Pitoiset 
---
src/amd/vulkan/radv_wsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_wsi.c b/src/amd/vulkan/radv_wsi.c
index 2fd07447668..7651043b2b2 100644
--- a/src/amd/vulkan/radv_wsi.c
+++ b/src/amd/vulkan/radv_wsi.c
@@ -38,11 +38,13 @@ radv_wsi_proc_addr(VkPhysicalDevice 
physicalDevice, const char *pName)

VkResult
radv_init_wsi(struct radv_physical_device *physical_device)
{
+    bool vsync = !!env_var_as_unsigned("RADV_VSYNC", 0);
+
return wsi_device_init(&physical_device->wsi_device,
radv_physical_device_to_handle(physical_device),
   radv_wsi_proc_addr,
   &physical_device->instance->alloc,
-   physical_device->master_fd, false);
+   physical_device->master_fd, vsync);
}

void
--
2.21.0

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





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

[Mesa-dev] [Bug 110356] install_megadrivers.py creates new dangling symlink [bisected]

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |fdo-b...@engestrom.ch
   |org |
 Status|NEW |ASSIGNED

--- Comment #1 from Eric Engestrom  ---
Thanks for the report!
I expect libmesa_dri_drivers, libgallium_dri, libva_gallium, and
libxvmc_gallium all have the same issue as well.

I'll add a check in bin/install_megadrivers.py to basically delete
`${master}.*`

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