[Mesa-dev] [Bug 107822] Just Cause 3 Flickering Textures with AMD RADV

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107822

Samuel Pitoiset  changed:

   What|Removed |Added

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

--- Comment #10 from Samuel Pitoiset  ---
Last time I tried to investigate the game crashed inside Proton. I will try
again.

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

[Mesa-dev] [Bug 107822] Just Cause 3 Flickering Textures with AMD RADV

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107822

Alexander Vereeken  changed:

   What|Removed |Added

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

--- Comment #9 from Alexander Vereeken  ---
I'm closing this bug now because I'm not interested in the game anymore and I'm
sure nothing will change here.

-- 
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 3/8] android: anv: fix improper use of LOCAL_WHOLE_STATIC_LIBRARIES

2019-06-25 Thread Eric Engestrom
On Tuesday, 2019-06-25 18:08:29 +0800, Chih-Wei Huang wrote:
> The libmesa_anv_entrypoints and libmesa_genxml are dummy libraries.
> There is no reason to put them into LOCAL_WHOLE_STATIC_LIBRARIES.
> 
> Move libmesa_vulkan_util to the vulkan HAL which really needs it.
> 
> Signed-off-by: Chih-Wei Huang 
> ---
>  src/intel/Android.vulkan.mk | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
> index 8d978c3..4fff842 100644
> --- a/src/intel/Android.vulkan.mk
> +++ b/src/intel/Android.vulkan.mk
> @@ -128,7 +128,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=70
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -149,7 +149,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=75
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -170,7 +170,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=80
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -191,7 +191,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=90
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -212,7 +212,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=100
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -233,7 +233,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=110
>  
>  LOCAL_C_INCLUDES := $(ANV_INCLUDES)
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
> +LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> @@ -257,7 +257,7 @@ LOCAL_C_INCLUDES := \
>   $(ANV_INCLUDES) \
>   $(MESA_TOP)/src/compiler
>  
> -LOCAL_WHOLE_STATIC_LIBRARIES := \
> +LOCAL_STATIC_LIBRARIES := \
>   libmesa_anv_entrypoints \
>   libmesa_genxml \
>   libmesa_git_sha1 \
> @@ -326,14 +326,14 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
>   libmesa_intel_common \
>   libmesa_intel_dev \
>   libmesa_vulkan_common \
> + libmesa_vulkan_util \
>   libmesa_anv_gen7 \
>   libmesa_anv_gen75 \
>   libmesa_anv_gen8 \
>   libmesa_anv_gen9 \
>   libmesa_anv_gen10 \
>   libmesa_anv_gen11 \
> - libmesa_intel_compiler \
> - libmesa_anv_entrypoints
> + libmesa_intel_compiler

This removal of libmesa_anv_entrypoints belongs in patch 6/8, right?

I don't have much knowledge of the way android.mk works, but this all
looks reasonable; series is
Acked-by: Eric Engestrom 

>  
>  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libz libsync liblog
>  LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
> -- 
> 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] intel_stub: Wrap fcntl64

2019-06-25 Thread Ian Romanick
On 6/25/19 10:23 AM, Jason Ekstrand wrote:
> I needed this patch today so I've pushed it.  FYI, we do have MRs for
> shader-db which are a bit easier to find than a needle in the hay-stack
> that is mesa-dev.

Ah... that's good to know.  After I sent this patch, I completely forgot
about it. :)

> --Jason
> 
> On Fri, Jun 7, 2019 at 11:27 AM Emil Velikov  > wrote:
> 
> On Fri, 7 Jun 2019 at 00:30, Ian Romanick  > wrote:
> >
> > From: Ian Romanick  >
> >
> > This makes the wrapper work on glibc 2.29 on Fedora 30.
> > ---
> AFAICT this patch is for shader-db and looks spot on.
> Reviewed-by: Emil Velikov  >
> 
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

[Mesa-dev] [PATCH] panfrost: Update copyright identifiers

2019-06-25 Thread Alyssa Rosenzweig
"Collabora, Ltd." should be listed in lieu of simply "Collabora"

Signed-off-by: Alyssa Rosenzweig 
Suggested-by: Daniel Stone 
---
 src/gallium/drivers/panfrost/include/panfrost-job.h| 2 +-
 src/gallium/drivers/panfrost/midgard/midgard_ra.c  | 2 +-
 src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c | 2 +-
 src/gallium/drivers/panfrost/pan_afbc.c| 2 +-
 src/gallium/drivers/panfrost/pan_blit.c| 2 +-
 src/gallium/drivers/panfrost/pan_resource.c| 2 +-
 src/gallium/drivers/panfrost/pan_scoreboard.c  | 2 +-
 src/gallium/drivers/panfrost/pan_screen.c  | 2 +-
 src/gallium/drivers/panfrost/pan_screen.h  | 2 +-
 src/gallium/drivers/panfrost/pan_tiler.c   | 2 +-
 src/gallium/drivers/panfrost/pan_tiler.h   | 2 +-
 src/gallium/drivers/panfrost/pan_util.h| 2 +-
 src/gallium/drivers/panfrost/pandecode/common.c| 2 +-
 src/gallium/drivers/panfrost/pandecode/decode.c| 2 +-
 14 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h 
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index fbef4efdc32..f647313ed8f 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -2,7 +2,7 @@
  * © Copyright 2017-2018 Alyssa Rosenzweig
  * © Copyright 2017-2018 Connor Abbott
  * © Copyright 2017-2018 Lyude Paul
- * © Copyright2019 Collabora
+ * © Copyright2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_ra.c 
b/src/gallium/drivers/panfrost/midgard/midgard_ra.c
index 7fd5e5b49e3..77ec65b4eae 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_ra.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_ra.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2018-2019 Alyssa Rosenzweig 
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c 
b/src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c
index d4187edc0c8..6622c2bc534 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_ra_pipeline.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2019 Alyssa Rosenzweig 
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/pan_afbc.c 
b/src/gallium/drivers/panfrost/pan_afbc.c
index 5621d1f333a..077e0dcba66 100644
--- a/src/gallium/drivers/panfrost/pan_afbc.c
+++ b/src/gallium/drivers/panfrost/pan_afbc.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/pan_blit.c 
b/src/gallium/drivers/panfrost/pan_blit.c
index 5859f92f9d1..17f6a5d5bed 100644
--- a/src/gallium/drivers/panfrost/pan_blit.c
+++ b/src/gallium/drivers/panfrost/pan_blit.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2014 Broadcom
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/pan_resource.c 
b/src/gallium/drivers/panfrost/pan_resource.c
index 1a691a5be34..fda0b1367a5 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -2,7 +2,7 @@
  * Copyright (C) 2008 VMware, Inc.
  * Copyright (C) 2014 Broadcom
  * Copyright (C) 2018-2019 Alyssa Rosenzweig
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
diff --git a/src/gallium/drivers/panfrost/pan_scoreboard.c 
b/src/gallium/drivers/panfrost/pan_scoreboard.c
index 2e9c7b5074c..0c4cbfe5d9b 100644
--- a/src/gallium/drivers/panfrost/pan_scoreboard.c
+++ b/src/gallium/drivers/panfrost/pan_scoreboard.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2019 Collabora
+ * Copyright (C) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "So

[Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code

2019-06-25 Thread Alyssa Rosenzweig
Rather than using a magic lookup table with no explanations, let's add
liberal comments to the code to explain what this tiling scheme is and
how to encode/decode it efficiently.

It's not so mysterious after all -- just reordering bits with some XORs
thrown in.

v2: Correct copyright identifier. Fix spelling error. Switch space_4 to
a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
generic rather than split up unaligned writes.

Signed-off-by: Alyssa Rosenzweig 
Cc: Vasily Khoruzhick 
---
 src/panfrost/shared/pan_tiling.c | 290 ---
 1 file changed, 189 insertions(+), 101 deletions(-)

diff --git a/src/panfrost/shared/pan_tiling.c b/src/panfrost/shared/pan_tiling.c
index 413cd89420b..c8b09887037 100644
--- a/src/panfrost/shared/pan_tiling.c
+++ b/src/panfrost/shared/pan_tiling.c
@@ -2,6 +2,7 @@
  * Copyright (c) 2011-2013 Luc Verhaegen 
  * Copyright (c) 2018 Alyssa Rosenzweig 
  * Copyright (c) 2018 Vasily Khoruzhick 
+ * Copyright (c) 2019 Collabora, Ltd.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -24,129 +25,212 @@
  *
  */
 
+#include 
 #include "pan_tiling.h"
 
-uint32_t space_filler[16][16] = {
-   { 0,   1,   4,   5,   16,  17,  20,  21,  64,  65,  68,  69,  80,  81,  84, 
 85, },
-   { 3,   2,   7,   6,   19,  18,  23,  22,  67,  66,  71,  70,  83,  82,  87, 
 86, },
-   { 12,  13,  8,   9,   28,  29,  24,  25,  76,  77,  72,  73,  92,  93,  88, 
 89, },
-   { 15,  14,  11,  10,  31,  30,  27,  26,  79,  78,  75,  74,  95,  94,  91, 
 90, },
-   { 48,  49,  52,  53,  32,  33,  36,  37,  112, 113, 116, 117, 96,  97,  
100, 101, },
-   { 51,  50,  55,  54,  35,  34,  39,  38,  115, 114, 119, 118, 99,  98,  
103, 102, },
-   { 60,  61,  56,  57,  44,  45,  40,  41,  124, 125, 120, 121, 108, 109, 
104, 105, },
-   { 63,  62,  59,  58,  47,  46,  43,  42,  127, 126, 123, 122, 111, 110, 
107, 106, },
-   { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145, 
148, 149, },
-   { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146, 
151, 150, },
-   { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157, 
152, 153, },
-   { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158, 
155, 154, },
-   { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161, 
164, 165, },
-   { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162, 
167, 166, },
-   { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173, 
168, 169, },
-   { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174, 
171, 170, },
+/* This file implements software encode/decode of the tiling format used for
+ * textures and framebuffers primarily on Utgard GPUs. Names for this format
+ * include "Utgard-style tiling", "(Mali) swizzled textures", and
+ * "U-interleaved" (the former two names being used in the community
+ * Lima/Panfrost drivers; the latter name used internally at Arm).
+ * Conceptually, like any tiling scheme, the pixel reordering attempts to 2D
+ * spatial locality, to improve cache locality in both horizontal and vertical
+ * directions.
+ *
+ * This format is tiled: first, the image dimensions must be aligned to 16
+ * pixels in each axis. Once aligned, the image is divided into 16x16 tiles.
+ * This size harmonizes with other properties of the GPU; on Midgard,
+ * framebuffer tiles are logically 16x16 (this is the tile size used in
+ * Transaction Elimination and the minimum tile size used in Hierarchical
+ * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
+ * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
+ * size.
+ *
+ * Within each 16x16 block, the bits are reordered according to this pattern:
+ *
+ * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
+ *
+ * Basically, interleaving the X and Y bits, with XORs thrown in for every
+ * adjacent bit pair.
+ *
+ * This is cheap to implement both encode/decode in both hardware and software.
+ * In hardware, lines are simply rerouted to reorder and some XOR gates are
+ * thrown in. Software has to be a bit more clever.
+ *
+ * In software, the trick is to divide the pattern into two lines:
+ *
+ *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
+ *  ^ |  0 | x3 |  0 | x2 |  0 | x1 |  0 | x0 |
+ *
+ * That is, duplicate the bits of the Y and space out the bits of the X. The
+ * top line is a function only of Y, so it can be calculated once per row and
+ * stored in a register. The bottom line is simply X with the bits spaced out.
+ * Spacing out the X is easy enough with a LUT, or by subtracting+ANDing the
+ * mask pattern (abusing carry bits).
+ *
+ * This format is also supported on Midgard GPUs, where it *can* be used for
+ * textures and framebuffers. That said, in practice it is usually as a
+ * fallback layout; Midgard introduces 

Re: [Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code

2019-06-25 Thread Daniel Stone
Hi Alyssa,

On Tue, 25 Jun 2019 at 19:54, Alyssa Rosenzweig
 wrote:
> @@ -2,6 +2,7 @@
>   * Copyright (c) 2011-2013 Luc Verhaegen 
>   * Copyright (c) 2018 Alyssa Rosenzweig 
>   * Copyright (c) 2018 Vasily Khoruzhick 
> + * Copyright (c) 2019 Collabora

Please use 'Collabora, Ltd.' as that's our full legal form.

Afraid I have no feelings on the actual code however. ;)

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

[Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code

2019-06-25 Thread Alyssa Rosenzweig
Rather than using a magic lookup table with no explanations, let's add
liberal comments to the code to explain what this tiling scheme is and
how to encode/decode it efficiently.

It's not so mysterious after all -- just reordering bits with some XORs
thrown in.

Signed-off-by: Alyssa Rosenzweig 
Cc: Vasily Khoruzhick 
---
 src/panfrost/shared/pan_tiling.c | 330 +--
 1 file changed, 229 insertions(+), 101 deletions(-)

diff --git a/src/panfrost/shared/pan_tiling.c b/src/panfrost/shared/pan_tiling.c
index 413cd89420b..de0d6812831 100644
--- a/src/panfrost/shared/pan_tiling.c
+++ b/src/panfrost/shared/pan_tiling.c
@@ -2,6 +2,7 @@
  * Copyright (c) 2011-2013 Luc Verhaegen 
  * Copyright (c) 2018 Alyssa Rosenzweig 
  * Copyright (c) 2018 Vasily Khoruzhick 
+ * Copyright (c) 2019 Collabora
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -26,127 +27,230 @@
 
 #include "pan_tiling.h"
 
-uint32_t space_filler[16][16] = {
-   { 0,   1,   4,   5,   16,  17,  20,  21,  64,  65,  68,  69,  80,  81,  84, 
 85, },
-   { 3,   2,   7,   6,   19,  18,  23,  22,  67,  66,  71,  70,  83,  82,  87, 
 86, },
-   { 12,  13,  8,   9,   28,  29,  24,  25,  76,  77,  72,  73,  92,  93,  88, 
 89, },
-   { 15,  14,  11,  10,  31,  30,  27,  26,  79,  78,  75,  74,  95,  94,  91, 
 90, },
-   { 48,  49,  52,  53,  32,  33,  36,  37,  112, 113, 116, 117, 96,  97,  
100, 101, },
-   { 51,  50,  55,  54,  35,  34,  39,  38,  115, 114, 119, 118, 99,  98,  
103, 102, },
-   { 60,  61,  56,  57,  44,  45,  40,  41,  124, 125, 120, 121, 108, 109, 
104, 105, },
-   { 63,  62,  59,  58,  47,  46,  43,  42,  127, 126, 123, 122, 111, 110, 
107, 106, },
-   { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145, 
148, 149, },
-   { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146, 
151, 150, },
-   { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157, 
152, 153, },
-   { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158, 
155, 154, },
-   { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161, 
164, 165, },
-   { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162, 
167, 166, },
-   { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173, 
168, 169, },
-   { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174, 
171, 170, },
+/* This file implements software encode/decode of the tiling format used for
+ * textures and framebuffers primarily on Utgard GPUs. Names for this format
+ * include "Utgard-style tiling", "(Mali) swizzled textures", and
+ * "U-interleaved" (the former two names being used in the community
+ * Lima/Panfrost drivers; the latter name used internally at Arm).
+ * Conceptually, like any tiling scheme, the pixel reordering attempts to 2D
+ * spatial locality, to improve cache locality in both horizontal and vertical
+ * directions.
+ *
+ * This format is tiled: first, the image dimensions must be aligned to 16
+ * pixels in each axis. Once aligned, the image is divided into 16x16 tiles.
+ * This size harmonizes with other properties of the GPU; on Midgard,
+ * framebuffer tiles are logically 16x16 (this is the tile size used in
+ * Transaction Elimination and the minimum tile size used in Hierarchical
+ * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
+ * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
+ * size.
+ *
+ * Within each 16x16 block, the bits are reordered according to this pattern:
+ *
+ * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
+ *
+ * Basically, interleaving the X and Y bits, with XORs thrown in for every
+ * adjacent bit pair.
+ *
+ * This is cheap to implement both encode/decode in both hardware and software.
+ * In hardware, lines are simply rerouted to reorder and some XOR gates are
+ * thrown in. Software has to be a bit more clever.
+ *
+ * In software, the trick is to divide the pattern into two lines:
+ *
+ *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
+ *  ^ |  0 | x3 |  0 | x2 |  0 | x1 |  0 | x0 |
+ *
+ * That is, duplicate the bits of the Y and space out the bits of the X. The
+ * top line is a function only of Y, so it can be calculated once per row and
+ * stored in a register. The bottom line is simply X with the bits spaced out.
+ * The initial value can be calculated once at the beginning, and then after
+ * each pixel it can incremented by subtracting a mask pattern and ANDing with
+ * the mask pattern (abusing carry bits, where the mask pattern is the mask of
+ * bits we care about, so 0b01010101).
+ *
+ * Alternatively, the 16 indices can be precalculated for each row and reused
+ * across the row, which may be amenable to easier vectorization.
+ *
+ * This format is also supported on Midgard GPUs, where it *can* be used for
+ * textures and fra

Re: [Mesa-dev] [PATCH] intel_stub: Wrap fcntl64

2019-06-25 Thread Jason Ekstrand
I needed this patch today so I've pushed it.  FYI, we do have MRs for
shader-db which are a bit easier to find than a needle in the hay-stack
that is mesa-dev.

--Jason

On Fri, Jun 7, 2019 at 11:27 AM Emil Velikov 
wrote:

> On Fri, 7 Jun 2019 at 00:30, Ian Romanick  wrote:
> >
> > From: Ian Romanick 
> >
> > This makes the wrapper work on glibc 2.29 on Fedora 30.
> > ---
> AFAICT this patch is for shader-db and looks spot on.
> Reviewed-by: Emil Velikov 
>
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/5] dri_interface: add DRI2_BufferDamage interface

2019-06-25 Thread Daniel Stone
On Tue, 25 Jun 2019 at 17:46, Boris Brezillon
 wrote:
> On Tue, 25 Jun 2019 18:37:46 +0200 Boris Brezillon 
>  wrote:
> > Add a new DRI2_BufferDamage interface to support the
> > EGL_KHR_partial_update extension, informing the driver of an overriding
> > scissor region for a particular drawable.
> >
> > Based on a commit originally authored by:
> > Harish Krupo 
> > renamed extension, retargeted at DRI drawable instead of context,
> > rewritten description
>
> Oops, this patch is missing Daniel's SoB.

Oops indeed!

Signed-off-by: Daniel Stone 

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

Re: [Mesa-dev] [PATCH v4 2/5] dri_interface: add DRI2_BufferDamage interface

2019-06-25 Thread Boris Brezillon
On Tue, 25 Jun 2019 18:37:46 +0200
Boris Brezillon  wrote:

> From: Daniel Stone 
> 
> Add a new DRI2_BufferDamage interface to support the
> EGL_KHR_partial_update extension, informing the driver of an overriding
> scissor region for a particular drawable.
> 
> Based on a commit originally authored by:
> Harish Krupo 
> renamed extension, retargeted at DRI drawable instead of context,
> rewritten description
> 

Oops, this patch is missing Daniel's SoB.

> Signed-off-by: Boris Brezillon 
> ---
>  include/GL/internal/dri_interface.h | 43 +
>  1 file changed, 43 insertions(+)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index af0ee9c56670..ada78c5d53d6 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -85,6 +85,7 @@ typedef struct __DRI2throttleExtensionRec   
> __DRI2throttleExtension;
>  typedef struct __DRI2fenceExtensionRec  __DRI2fenceExtension;
>  typedef struct __DRI2interopExtensionRec __DRI2interopExtension;
>  typedef struct __DRI2blobExtensionRec   __DRI2blobExtension;
> +typedef struct __DRI2bufferDamageExtensionRec   __DRI2bufferDamageExtension;
>  
>  typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
>  typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
> @@ -488,6 +489,48 @@ struct __DRI2interopExtensionRec {
>  struct mesa_glinterop_export_out *out);
>  };
>  
> +
> +/**
> + * Extension for limiting window system back buffer rendering to user-defined
> + * scissor region.
> + */
> +
> +#define __DRI2_BUFFER_DAMAGE "DRI2_BufferDamage"
> +#define __DRI2_BUFFER_DAMAGE_VERSION 1
> +
> +struct __DRI2bufferDamageExtensionRec {
> +   __DRIextension base;
> +
> +   /**
> +* Provides an array of rectangles representing an overriding scissor 
> region
> +* for rendering operations performed to the specified drawable. These
> +* rectangles do not replace client API scissor regions or draw
> +* co-ordinates, but instead inform the driver of the overall bounds of 
> all
> +* operations which will be issued before the next flush.
> +*
> +* Any rendering operations writing pixels outside this region to the
> +* drawable will have an undefined effect on the entire drawable.
> +*
> +* This entrypoint may only be called after the drawable has been either 
> been
> +* newly created or flushed, and before any rendering operations which 
> write
> +* pixels to the drawable. Calling this entrypoint at any other time will
> +* have an undefined effect on the entire drawable.
> +*
> +* Calling this entrypoint with @size 0 and @rects NULL will reset the
> +* region to the buffer's full size. This entrypoint may be called once to
> +* reset the region, followed by a second call with a populated region,
> +* before a rendering call is made.
> +*
> +* Used to implement EGL_KHR_partial_update.
> +*
> +* \param drawable affected drawable
> +* \param size number of rectangles provided
> +* \param rectsthe array of rectangles, lower-left origin
> +*/
> +   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> + int *rects);
> +};
> +
>  /*@}*/
>  
>  /**

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

[Mesa-dev] [PATCH v4 4/5] st/dri2: Implement DRI2bufferDamageExtension

2019-06-25 Thread Boris Brezillon
From: Daniel Stone 

Add a pipe_screen->set_damage_region() hook to propagate
set-damage-region requests to the driver, it's then up to the driver to
decide what to do with this piece of information.

If the hook is left unassigned, the buffer-damage extension is
considered unsupported.

Signed-off-by: Daniel Stone 
Signed-off-by: Boris Brezillon 
---
 src/gallium/include/pipe/p_screen.h   |  7 +++
 src/gallium/state_trackers/dri/dri2.c | 22 ++
 2 files changed, 29 insertions(+)

diff --git a/src/gallium/include/pipe/p_screen.h 
b/src/gallium/include/pipe/p_screen.h
index 3f9bad470950..8df12ee4f865 100644
--- a/src/gallium/include/pipe/p_screen.h
+++ b/src/gallium/include/pipe/p_screen.h
@@ -464,6 +464,13 @@ struct pipe_screen {
bool (*is_parallel_shader_compilation_finished)(struct pipe_screen *screen,
void *shader,
unsigned shader_type);
+
+   /**
+* Set damage region.
+*/
+   void (*set_damage_region)(struct pipe_screen *screen,
+ struct pipe_resource *resource,
+ unsigned int nrects, int *rects);
 };
 
 
diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
index 5caaa9deac41..df22e7c41642 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1806,6 +1806,23 @@ static const __DRI2interopExtension dri2InteropExtension 
= {
.export_object = dri2_interop_export_object
 };
 
+/**
+ * \brief the DRI2bufferDamageExtension set_damage_region method
+ */
+static void
+dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int *rects)
+{
+   struct dri_drawable *drawable = dri_drawable(dPriv);
+   struct pipe_resource *resource = 
drawable->textures[ST_ATTACHMENT_BACK_LEFT];
+   struct pipe_screen *screen = resource->screen;
+
+   screen->set_damage_region(screen, resource, nrects, rects);
+}
+
+static __DRI2bufferDamageExtension dri2BufferDamageExtension = {
+   .base = { __DRI2_BUFFER_DAMAGE, 1 },
+};
+
 /**
  * \brief the DRI2ConfigQueryExtension configQueryb method
  */
@@ -1907,6 +1924,7 @@ static const __DRIextension *dri_screen_extensions[] = {
&dri2GalliumConfigQueryExtension.base,
&dri2ThrottleExtension.base,
&dri2FenceExtension.base,
+   &dri2BufferDamageExtension.base,
&dri2InteropExtension.base,
&dri2NoErrorExtension.base,
&driBlobExtension.base,
@@ -1922,6 +1940,7 @@ static const __DRIextension 
*dri_robust_screen_extensions[] = {
&dri2ThrottleExtension.base,
&dri2FenceExtension.base,
&dri2InteropExtension.base,
+   &dri2BufferDamageExtension.base,
&dri2Robustness.base,
&dri2NoErrorExtension.base,
&driBlobExtension.base,
@@ -1982,6 +2001,9 @@ dri2_init_screen(__DRIscreen * sPriv)
   }
}
 
+   if (pscreen->set_damage_region)
+  dri2BufferDamageExtension.set_damage_region = dri2_set_damage_region;
+
if (pscreen->get_param(pscreen, PIPE_CAP_DEVICE_RESET_STATUS_QUERY)) {
   sPriv->extensions = dri_robust_screen_extensions;
   screen->has_reset_status_query = true;
-- 
2.20.1

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

[Mesa-dev] [PATCH v4 0/5] EGL_KHR_partial_update support

2019-06-25 Thread Boris Brezillon
This is an attempt at resurrecting Daniel's MR [1] which was already
resurrecting Harish's EGL_KHR_partial_update series [2]. This version
implements Marek's suggestion to pass the set_damage_region() directly
to the gallium driver and let it decide how to handle the request. Some
drivers might just calculate the damage extent (as done in Daniel's
initial proposal and in the panfrost implementation), others might do
extra optimizations like trying to reduce the area we're supposed to
reload (only valid for tile-based rendering) even further.

This patch series has been tested with weston (see Daniel's MR[3]) on
panfrost. Note that the panfrost implementation is rather simple (just
limits the rendering area to the damage extent and picks the biggest
damage rect as the only damage region) but we can improve it if we feel
the need.

Any feedback and suggestions on how to do it better are welcome.

Regards,

Boris

[1]https://gitlab.freedesktop.org/mesa/mesa/merge_requests/227
[2]https://patchwork.freedesktop.org/series/45915/#rev2
[3]https://gitlab.freedesktop.org/wayland/weston/merge_requests/106

Boris Brezillon (1):
  panfrost: Add support for KHR_partial_update()

Daniel Stone (2):
  dri_interface: add DRI2_BufferDamage interface
  st/dri2: Implement DRI2bufferDamageExtension

Harish Krupo (2):
  egl/android: Delete set_damage_region from egl dri vtbl
  egl/dri: Use __DRI2_DAMAGE extension for KHR_partial_update

 include/GL/internal/dri_interface.h | 43 +++
 src/egl/drivers/dri2/egl_dri2.c | 54 +--
 src/egl/drivers/dri2/egl_dri2.h |  5 +-
 src/egl/drivers/dri2/egl_dri2_fallbacks.h   |  9 
 src/egl/drivers/dri2/platform_android.c | 45 
 src/egl/drivers/dri2/platform_device.c  |  1 -
 src/egl/drivers/dri2/platform_drm.c |  1 -
 src/egl/drivers/dri2/platform_surfaceless.c |  1 -
 src/egl/drivers/dri2/platform_wayland.c |  1 -
 src/egl/drivers/dri2/platform_x11.c |  2 -
 src/egl/drivers/dri2/platform_x11_dri3.c|  1 -
 src/gallium/drivers/panfrost/pan_blit.c | 14 ++---
 src/gallium/drivers/panfrost/pan_context.c  | 49 -
 src/gallium/drivers/panfrost/pan_job.c  | 11 
 src/gallium/drivers/panfrost/pan_job.h  |  5 ++
 src/gallium/drivers/panfrost/pan_resource.c | 58 +
 src/gallium/drivers/panfrost/pan_resource.h | 12 -
 src/gallium/drivers/panfrost/pan_screen.c   |  1 +
 src/gallium/include/pipe/p_screen.h |  7 +++
 src/gallium/state_trackers/dri/dri2.c   | 22 
 20 files changed, 263 insertions(+), 79 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH v4 1/5] egl/android: Delete set_damage_region from egl dri vtbl

2019-06-25 Thread Boris Brezillon
From: Harish Krupo 

The intension of the KHR_partial_update was not to send the damage back
to the platform but to send the damage to the driver to ensure that the
following rendering could be restricted to those regions.
This patch removes the set_damage_region from the egl_dri vtbl and all
the platfrom_*.c files.
Then upcomming patches add a new dri2 interface for the drivers to
implement

Signed-off-by: Harish Krupo 
Reviewed-by: Daniel Stone 
Signed-off-by: Boris Brezillon 
---
 src/egl/drivers/dri2/egl_dri2.c |  3 +-
 src/egl/drivers/dri2/egl_dri2.h |  4 --
 src/egl/drivers/dri2/egl_dri2_fallbacks.h   |  9 -
 src/egl/drivers/dri2/platform_android.c | 45 -
 src/egl/drivers/dri2/platform_device.c  |  1 -
 src/egl/drivers/dri2/platform_drm.c |  1 -
 src/egl/drivers/dri2/platform_surfaceless.c |  1 -
 src/egl/drivers/dri2/platform_wayland.c |  1 -
 src/egl/drivers/dri2/platform_x11.c |  2 -
 src/egl/drivers/dri2/platform_x11_dri3.c|  1 -
 10 files changed, 1 insertion(+), 67 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index ee4faaab34f4..3c33b2cf27f8 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1691,8 +1691,7 @@ static EGLBoolean
 dri2_set_damage_region(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf,
EGLint *rects, EGLint n_rects)
 {
-   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   return dri2_dpy->vtbl->set_damage_region(drv, disp, surf, rects, n_rects);
+   return false;
 }
 
 static EGLBoolean
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 943ff1808619..f9237dbe2559 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -119,10 +119,6 @@ struct dri2_egl_display_vtbl {
   _EGLSurface *surface,
   const EGLint *rects, EGLint n_rects);
 
-   EGLBoolean (*set_damage_region)(_EGLDriver *drv, _EGLDisplay *disp,
-   _EGLSurface *surface,
-   const EGLint *rects, EGLint n_rects);
-
EGLBoolean (*swap_buffers_region)(_EGLDriver *drv, _EGLDisplay *disp,
  _EGLSurface *surf, EGLint numRects,
  const EGLint *rects);
diff --git a/src/egl/drivers/dri2/egl_dri2_fallbacks.h 
b/src/egl/drivers/dri2/egl_dri2_fallbacks.h
index 6c2c4bbe595e..d975b7a8b130 100644
--- a/src/egl/drivers/dri2/egl_dri2_fallbacks.h
+++ b/src/egl/drivers/dri2/egl_dri2_fallbacks.h
@@ -62,7 +62,6 @@ dri2_fallback_swap_buffers_with_damage(_EGLDriver *drv, 
_EGLDisplay *disp,
   const EGLint *rects, EGLint n_rects)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   dri2_dpy->vtbl->set_damage_region(drv, disp, surf, rects, n_rects);
return dri2_dpy->vtbl->swap_buffers(drv, disp, surf);
 }
 
@@ -90,14 +89,6 @@ dri2_fallback_copy_buffers(_EGLDriver *drv, _EGLDisplay 
*disp,
return _eglError(EGL_BAD_NATIVE_PIXMAP, "no support for native pixmaps");
 }
 
-static inline EGLBoolean
-dri2_fallback_set_damage_region(_EGLDriver *drv, _EGLDisplay *disp,
-_EGLSurface *surf,
-const EGLint *rects, EGLint n_rects)
-{
-   return EGL_FALSE;
-}
-
 static inline EGLint
 dri2_fallback_query_buffer_age(_EGLDriver *drv, _EGLDisplay *disp,
_EGLSurface *surf)
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index db6ba4a4b4d6..6ce04d250c8d 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -728,43 +728,6 @@ droid_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *draw)
return EGL_TRUE;
 }
 
-#if ANDROID_API_LEVEL >= 23
-static EGLBoolean
-droid_set_damage_region(_EGLDriver *drv,
-_EGLDisplay *disp,
-_EGLSurface *draw, const EGLint* rects, EGLint n_rects)
-{
-   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   struct dri2_egl_surface *dri2_surf = dri2_egl_surface(draw);
-   android_native_rect_t* droid_rects = NULL;
-   int ret;
-
-   if (n_rects == 0)
-  return EGL_TRUE;
-
-   droid_rects = malloc(n_rects * sizeof(android_native_rect_t));
-   if (droid_rects == NULL)
- return _eglError(EGL_BAD_ALLOC, "eglSetDamageRegionKHR");
-
-   for (EGLint num_drects = 0; num_drects < n_rects; num_drects++) {
-  EGLint i = num_drects * 4;
-  droid_rects[num_drects].left = rects[i];
-  droid_rects[num_drects].bottom = rects[i + 1];
-  droid_rects[num_drects].right = rects[i] + rects[i + 2];
-  droid_rects[num_drects].top = rects[i + 1] + rects[i + 3];
-   }
-
-   /*
-* XXX/TODO: Need to check for other return values
-*/
-

[Mesa-dev] [PATCH v4 3/5] egl/dri: Use __DRI2_DAMAGE extension for KHR_partial_update

2019-06-25 Thread Boris Brezillon
From: Harish Krupo 

Use the DRI2 interface callback to pass the damage rects to
the driver.

Signed-off-by: Harish Krupo 
Signed-off-by: Boris Brezillon 
---
 src/egl/drivers/dri2/egl_dri2.c | 55 ++---
 src/egl/drivers/dri2/egl_dri2.h |  1 +
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 3c33b2cf27f8..fcafcfd73c63 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -452,6 +452,7 @@ static const struct dri2_extension_match 
optional_core_extensions[] = {
{ __DRI2_NO_ERROR, 1, offsetof(struct dri2_egl_display, no_error) },
{ __DRI2_CONFIG_QUERY, 1, offsetof(struct dri2_egl_display, config) },
{ __DRI2_FENCE, 1, offsetof(struct dri2_egl_display, fence) },
+   { __DRI2_BUFFER_DAMAGE, 1, offsetof(struct dri2_egl_display, buffer_damage) 
},
{ __DRI2_RENDERER_QUERY, 1, offsetof(struct dri2_egl_display, 
rendererQuery) },
{ __DRI2_INTEROP, 1, offsetof(struct dri2_egl_display, interop) },
{ __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
@@ -721,6 +722,9 @@ dri2_setup_screen(_EGLDisplay *disp)
 
if (dri2_dpy->flush_control)
   disp->Extensions.KHR_context_flush_control = EGL_TRUE;
+
+   if (dri2_dpy->buffer_damage && dri2_dpy->buffer_damage->set_damage_region)
+  disp->Extensions.KHR_partial_update = EGL_TRUE;
 }
 
 void
@@ -1658,11 +1662,22 @@ static EGLBoolean
 dri2_swap_buffers(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
_EGLContext *ctx = _eglGetCurrentContext();
+   EGLBoolean ret;
 
if (ctx && surf)
   dri2_surf_update_fence_fd(ctx, disp, surf);
-   return dri2_dpy->vtbl->swap_buffers(drv, disp, surf);
+   ret = dri2_dpy->vtbl->swap_buffers(drv, disp, surf);
+
+   /* SwapBuffers marks the end of the frame; reset the damage region for
+* use again next time.
+*/
+   if (ret && dri2_dpy->buffer_damage &&
+   dri2_dpy->buffer_damage->set_damage_region)
+  dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
+
+   return ret;
 }
 
 static EGLBoolean
@@ -1671,12 +1686,23 @@ dri2_swap_buffers_with_damage(_EGLDriver *drv, 
_EGLDisplay *disp,
   const EGLint *rects, EGLint n_rects)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
_EGLContext *ctx = _eglGetCurrentContext();
+   EGLBoolean ret;
 
if (ctx && surf)
   dri2_surf_update_fence_fd(ctx, disp, surf);
-   return dri2_dpy->vtbl->swap_buffers_with_damage(drv, disp, surf,
-   rects, n_rects);
+   ret = dri2_dpy->vtbl->swap_buffers_with_damage(drv, disp, surf,
+  rects, n_rects);
+
+   /* SwapBuffers marks the end of the frame; reset the damage region for
+* use again next time.
+*/
+   if (ret && dri2_dpy->buffer_damage &&
+   dri2_dpy->buffer_damage->set_damage_region)
+  dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
+
+   return ret;
 }
 
 static EGLBoolean
@@ -1684,14 +1710,33 @@ dri2_swap_buffers_region(_EGLDriver *drv, _EGLDisplay 
*disp, _EGLSurface *surf,
  EGLint numRects, const EGLint *rects)
 {
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   return dri2_dpy->vtbl->swap_buffers_region(drv, disp, surf, numRects, 
rects);
+   __DRIdrawable *dri_drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
+   EGLBoolean ret;
+
+   ret = dri2_dpy->vtbl->swap_buffers_region(drv, disp, surf, numRects, rects);
+
+   /* SwapBuffers marks the end of the frame; reset the damage region for
+* use again next time.
+*/
+   if (ret && dri2_dpy->buffer_damage &&
+   dri2_dpy->buffer_damage->set_damage_region)
+  dri2_dpy->buffer_damage->set_damage_region(dri_drawable, 0, NULL);
+
+   return ret;
 }
 
 static EGLBoolean
 dri2_set_damage_region(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface *surf,
EGLint *rects, EGLint n_rects)
 {
-   return false;
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
+   __DRIdrawable *drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
+
+   if (!dri2_dpy->buffer_damage || !dri2_dpy->buffer_damage->set_damage_region)
+  return EGL_FALSE;
+
+   dri2_dpy->buffer_damage->set_damage_region(drawable, n_rects, rects);
+   return EGL_TRUE;
 }
 
 static EGLBoolean
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index f9237dbe2559..00bce2285d3e 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -178,6 +178,7 @@ struct dri2_egl_display
const __DRInoErrorExtension*no_error;
const __DRI2configQueryExtension *config;
const __DRI2fenceE

[Mesa-dev] [PATCH v4 5/5] panfrost: Add support for KHR_partial_update()

2019-06-25 Thread Boris Brezillon
Implement ->set_damage_region() region to support partial updates.

This is a dummy implementation in that it does not try to merge
damage rects. It also does not deal with distinct regions and instead
pick the largest quad as the only damage rect and generate up to 4
reload rects out of it (the left/right/top/bottom regions surrounding
the biggest damage rect).

We also do not try to reduce the number of draws by passing all quad
vertices to the blit request (would require extending u_blitter)

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_blit.c | 14 ++---
 src/gallium/drivers/panfrost/pan_context.c  | 49 -
 src/gallium/drivers/panfrost/pan_job.c  | 11 
 src/gallium/drivers/panfrost/pan_job.h  |  5 ++
 src/gallium/drivers/panfrost/pan_resource.c | 58 +
 src/gallium/drivers/panfrost/pan_resource.h | 12 -
 src/gallium/drivers/panfrost/pan_screen.c   |  1 +
 7 files changed, 141 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_blit.c 
b/src/gallium/drivers/panfrost/pan_blit.c
index 5859f92f9d1b..3a45277ee287 100644
--- a/src/gallium/drivers/panfrost/pan_blit.c
+++ b/src/gallium/drivers/panfrost/pan_blit.c
@@ -105,18 +105,18 @@ panfrost_blit(struct pipe_context *pipe,
  */
 
 void
-panfrost_blit_wallpaper(struct panfrost_context *ctx)
+panfrost_blit_wallpaper(struct panfrost_context *ctx, struct pipe_box *rect)
 {
 struct pipe_blit_info binfo = { };
 
 panfrost_blitter_save(ctx);
 
-   binfo.src.resource = binfo.dst.resource = 
ctx->pipe_framebuffer.cbufs[0]->texture;
-   binfo.src.level = binfo.dst.level = 0;
-   binfo.src.box.x = binfo.dst.box.x = 0;
-   binfo.src.box.y = binfo.dst.box.y = 0;
-   binfo.src.box.width = binfo.dst.box.width = ctx->pipe_framebuffer.width;
-   binfo.src.box.height = binfo.dst.box.height = 
ctx->pipe_framebuffer.height;
+binfo.src.resource = binfo.dst.resource = 
ctx->pipe_framebuffer.cbufs[0]->texture;
+binfo.src.level = binfo.dst.level = 0;
+binfo.src.box.x = binfo.dst.box.x = rect->x;
+binfo.src.box.y = binfo.dst.box.y = rect->y;
+binfo.src.box.width = binfo.dst.box.width = rect->width;
+binfo.src.box.height = binfo.dst.box.height = rect->height;
 
/* This avoids an assert due to missing nir_texop_txb support */
//binfo.src.box.depth = binfo.dst.box.depth = 1;
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index de6dd38c5566..c1075c6693e8 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1528,7 +1528,54 @@ panfrost_draw_wallpaper(struct pipe_context *pipe)
 struct panfrost_job *batch = panfrost_get_job_for_fbo(ctx);
 
 ctx->wallpaper_batch = batch;
-panfrost_blit_wallpaper(ctx);
+
+/* Clamp the rendering area to the damage extent. The
+ * KHR_partial_update() spec states that trying to render outside of
+ * the damage region is "undefined behavior", so we should be safe.
+ */
+panfrost_job_intersection_scissor(batch, rsrc->damage.extent.minx,
+  rsrc->damage.extent.miny,
+  rsrc->damage.extent.maxx,
+  rsrc->damage.extent.maxy);
+
+struct pipe_scissor_state damage;
+struct pipe_box rects[4];
+
+/* Clamp the damage box to the rendering area. */
+damage.minx = MAX2(batch->minx, rsrc->damage.biggest_rect.x);
+damage.miny = MAX2(batch->miny, rsrc->damage.biggest_rect.y);
+damage.maxx = MIN2(batch->maxx,
+   rsrc->damage.biggest_rect.x +
+   rsrc->damage.biggest_rect.width);
+damage.maxy = MIN2(batch->maxy,
+   rsrc->damage.biggest_rect.y +
+   rsrc->damage.biggest_rect.height);
+
+/* One damage rectangle means we can end up with at most 4 reload
+ * regions:
+ * 1: left region, only exists if damage.x > 0
+ * 2: right region, only exists if damage.x + damage.width < fb->width
+ * 3: top region, only exists if damage.y > 0. The intersection with
+ *the left and right regions are dropped
+ * 4: bottom region, only exists if damage.y + damage.height < 
fb->height.
+ *The intersection with the left and right regions are dropped
+ */
+u_box_2d(batch->minx, batch->miny, damage.minx - batch->minx,
+ batch->maxy - batch->miny, &rects[0]);
+u_box_2d(damage.maxx, batch->miny, batch->maxx - damage.maxx,
+ batch->maxy - batch->miny, &rects[1]);
+u_box_2d(damage.minx, batch->miny, damage.maxx - damage.minx,
+ damage.miny - batch->miny, &rects[2]);
+u_box_2d(damage.minx, damage.maxy, dam

[Mesa-dev] [PATCH v4 2/5] dri_interface: add DRI2_BufferDamage interface

2019-06-25 Thread Boris Brezillon
From: Daniel Stone 

Add a new DRI2_BufferDamage interface to support the
EGL_KHR_partial_update extension, informing the driver of an overriding
scissor region for a particular drawable.

Based on a commit originally authored by:
Harish Krupo 
renamed extension, retargeted at DRI drawable instead of context,
rewritten description

Signed-off-by: Boris Brezillon 
---
 include/GL/internal/dri_interface.h | 43 +
 1 file changed, 43 insertions(+)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index af0ee9c56670..ada78c5d53d6 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -85,6 +85,7 @@ typedef struct __DRI2throttleExtensionRec 
__DRI2throttleExtension;
 typedef struct __DRI2fenceExtensionRec  __DRI2fenceExtension;
 typedef struct __DRI2interopExtensionRec   __DRI2interopExtension;
 typedef struct __DRI2blobExtensionRec   __DRI2blobExtension;
+typedef struct __DRI2bufferDamageExtensionRec   __DRI2bufferDamageExtension;
 
 typedef struct __DRIimageLoaderExtensionRec __DRIimageLoaderExtension;
 typedef struct __DRIimageDriverExtensionRec __DRIimageDriverExtension;
@@ -488,6 +489,48 @@ struct __DRI2interopExtensionRec {
 struct mesa_glinterop_export_out *out);
 };
 
+
+/**
+ * Extension for limiting window system back buffer rendering to user-defined
+ * scissor region.
+ */
+
+#define __DRI2_BUFFER_DAMAGE "DRI2_BufferDamage"
+#define __DRI2_BUFFER_DAMAGE_VERSION 1
+
+struct __DRI2bufferDamageExtensionRec {
+   __DRIextension base;
+
+   /**
+* Provides an array of rectangles representing an overriding scissor region
+* for rendering operations performed to the specified drawable. These
+* rectangles do not replace client API scissor regions or draw
+* co-ordinates, but instead inform the driver of the overall bounds of all
+* operations which will be issued before the next flush.
+*
+* Any rendering operations writing pixels outside this region to the
+* drawable will have an undefined effect on the entire drawable.
+*
+* This entrypoint may only be called after the drawable has been either 
been
+* newly created or flushed, and before any rendering operations which write
+* pixels to the drawable. Calling this entrypoint at any other time will
+* have an undefined effect on the entire drawable.
+*
+* Calling this entrypoint with @size 0 and @rects NULL will reset the
+* region to the buffer's full size. This entrypoint may be called once to
+* reset the region, followed by a second call with a populated region,
+* before a rendering call is made.
+*
+* Used to implement EGL_KHR_partial_update.
+*
+* \param drawable affected drawable
+* \param size number of rectangles provided
+* \param rectsthe array of rectangles, lower-left origin
+*/
+   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
+ int *rects);
+};
+
 /*@}*/
 
 /**
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-25 Thread Eric Anholt
Daniel Stone  writes:

> Hi,
>
> On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand  wrote:
>> On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone  wrote:
>>> On Tue, 25 Jun 2019 at 07:26, Simon Ser  wrote:
>>> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
>>> > > have usage at first but it was removed during the review. I'm having
>>> > > trouble digging what was the reason for this?
>>> >
>>> > I'm not sure either. Daniel said it was a mistake.
>>> >
>>> > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
>>> > the details?
>>>
>>> We decided to remove it since we decided that modifiers were a good
>>> enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
>>> because we already get the scanout modifiers from KMS and the texture
>>> modifiers from EGL.
>>>
>>> In hindsight, I think this was a mistake since it only handles buffer
>>> layout, and not buffer placement or cache configuration.
>>
>>
>> It's not great but modifiers should be able to handle that as well.  You can 
>> have _CONTIGUOUS versions of the modifiers supported by scanout and scanout 
>> will only advertise those and the caller has to know to place them in 
>> contiguous memory.  That's just an example but I think it would probably 
>> work for a lot of the cases.  If not, I'd love to know why not.
>
> Sometimes it's _CONTIGUOUS, sometimes it's _ON_THIS_PCIE_DEVICE.
> Either way, it does seem like a bit of an abuse: it has nothing to do
> with internal buffer layout, but how and where the backing pages are
> sourced.
>
> Given that it's completely orthogonal, I wouldn't like to go trying to
> combine it into the same namespace.

Agreed.


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

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-25 Thread Eric Anholt
Elie Tournier  writes:

> On Mon, Jun 24, 2019 at 11:41:55AM -0700, Eric Anholt wrote:
>> Elie Tournier  writes:
>> 
>> > Hi there,
>> >
>> > Great topic. For the past few days, I was looking at a CI for Mesa:
>> > https://gitlab.freedesktop.org/hopetech/tracie
>> > OK, it's in a very very alpha stage. ;)
>> 
>> I did one of those things using apitrace diff-images in piglit:
>> 
>> https://gitlab.freedesktop.org/mesa/piglit/tree/master/tests/apitrace
>> 
>> https://github.com/anholt/trace-db
>> 
>> It was bad.  diff-images is too picky and you end up needing to bless
>> new images constantly.  I have decided to not pursue this line of
>> testing any further because it was so unproductive.
> For now, my plan is to run the CI only once a week.
> So efficiency is not my top priority right now. But it will at some point.
>
> I'm trying to figure out which tools is the best for this job:
> Correctness *and* perf testing.
>
>> 
>> What I *am* interested in trying with traces for correctness testing is
>> using a single driver to replay trace keyframes multiple times and make
>> sure the image is invariant.  This could catch a large class of UB in
>> real world applications without needing continuous human intervention.
> So what's happening if an object is not render in all frame?

That would not be something that the tool I want to build could catch,
but also I don't think you'll manage to build a tool to do that that
doesn't involve a lot of human intervention.


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

Re: [Mesa-dev] [PATCH] radv: rename and re-document cache flush flags

2019-06-25 Thread Bas Nieuwenhuizen
r-b

On Tue, Jun 25, 2019 at 5:54 PM Samuel Pitoiset
 wrote:
>
> SMEM and VMEM caches are L0 on gfx10. Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c| 16 -
>  src/amd/vulkan/radv_device.c| 12 +++
>  src/amd/vulkan/radv_meta_buffer.c   |  4 +--
>  src/amd/vulkan/radv_meta_clear.c|  4 +--
>  src/amd/vulkan/radv_meta_fast_clear.c   |  2 +-
>  src/amd/vulkan/radv_meta_fmask_expand.c |  2 +-
>  src/amd/vulkan/radv_meta_resolve_cs.c   |  4 +--
>  src/amd/vulkan/radv_private.h   | 44 ++---
>  src/amd/vulkan/radv_query.c |  8 ++---
>  src/amd/vulkan/si_cmd_buffer.c  | 24 +++---
>  10 files changed, 62 insertions(+), 58 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 29f2e0c8a60..8ffd3989634 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -2576,7 +2576,7 @@ radv_src_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> case VK_ACCESS_SHADER_WRITE_BIT:
> case VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT:
> case VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT:
> -   flush_bits |= RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
> +   flush_bits |= RADV_CMD_FLAG_WB_L2;
> break;
> case VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT:
> flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
> @@ -2591,7 +2591,7 @@ radv_src_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> case VK_ACCESS_TRANSFER_WRITE_BIT:
> flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
>   RADV_CMD_FLAG_FLUSH_AND_INV_DB |
> - RADV_CMD_FLAG_INV_GLOBAL_L2;
> + RADV_CMD_FLAG_INV_L2;
>
> if (flush_CB_meta)
> flush_bits |= 
> RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
> @@ -2648,19 +2648,19 @@ radv_dst_access_flush(struct radv_cmd_buffer 
> *cmd_buffer,
> case VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT:
> break;
> case VK_ACCESS_UNIFORM_READ_BIT:
> -   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 | 
> RADV_CMD_FLAG_INV_SMEM_L1;
> +   flush_bits |= RADV_CMD_FLAG_INV_VCACHE | 
> RADV_CMD_FLAG_INV_SCACHE;
> break;
> case VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT:
> case VK_ACCESS_TRANSFER_READ_BIT:
> case VK_ACCESS_INPUT_ATTACHMENT_READ_BIT:
> -   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 |
> - RADV_CMD_FLAG_INV_GLOBAL_L2;
> +   flush_bits |= RADV_CMD_FLAG_INV_VCACHE |
> + RADV_CMD_FLAG_INV_L2;
> break;
> case VK_ACCESS_SHADER_READ_BIT:
> -   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1;
> +   flush_bits |= RADV_CMD_FLAG_INV_VCACHE;
>
> if (!image_is_coherent)
> -   flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2;
> +   flush_bits |= RADV_CMD_FLAG_INV_L2;
> break;
> case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
> if (flush_CB)
> @@ -3355,7 +3355,7 @@ VkResult radv_EndCommandBuffer(
>
> if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER) {
> if (cmd_buffer->device->physical_device->rad_info.chip_class 
> == GFX6)
> -   cmd_buffer->state.flush_bits |= 
> RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH | 
> RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
> +   cmd_buffer->state.flush_bits |= 
> RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH | 
> RADV_CMD_FLAG_WB_L2;
>
> /* Make sure to sync all pending active queries at the end of
>  * command buffer.
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index f12b8bde1f9..8d4964073cf 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -2704,9 +2704,9 @@ radv_get_preamble_cs(struct radv_queue *queue,
>  
> queue->device->physical_device->rad_info.chip_class >= GFX7,
>(queue->queue_family_index == 
> RADV_QUEUE_COMPUTE ? RADV_CMD_FLAG_CS_PARTIAL_FLUSH : 
> (RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH)) |
>RADV_CMD_FLAG_INV_ICACHE |
> -  RADV_CMD_FLAG_INV_SMEM_L1 |
> - 

[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110995

--- Comment #2 from tempel.jul...@gmail.com ---
It's an additional loss on top of DXVK vs. native D3D11 performance, so it sums
up to something worse. :)

I could bisect it to this commit:
https://github.com/mesa3d/mesa/commit/0a313cc285c2939de9cac07f045b0b699bc208ca
With it reverted, performance in mesa-master is normal.

-- 
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] radv: rename and re-document cache flush flags

2019-06-25 Thread Samuel Pitoiset
SMEM and VMEM caches are L0 on gfx10. Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c| 16 -
 src/amd/vulkan/radv_device.c| 12 +++
 src/amd/vulkan/radv_meta_buffer.c   |  4 +--
 src/amd/vulkan/radv_meta_clear.c|  4 +--
 src/amd/vulkan/radv_meta_fast_clear.c   |  2 +-
 src/amd/vulkan/radv_meta_fmask_expand.c |  2 +-
 src/amd/vulkan/radv_meta_resolve_cs.c   |  4 +--
 src/amd/vulkan/radv_private.h   | 44 ++---
 src/amd/vulkan/radv_query.c |  8 ++---
 src/amd/vulkan/si_cmd_buffer.c  | 24 +++---
 10 files changed, 62 insertions(+), 58 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 29f2e0c8a60..8ffd3989634 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2576,7 +2576,7 @@ radv_src_access_flush(struct radv_cmd_buffer *cmd_buffer,
case VK_ACCESS_SHADER_WRITE_BIT:
case VK_ACCESS_TRANSFORM_FEEDBACK_WRITE_BIT_EXT:
case VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT:
-   flush_bits |= RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
+   flush_bits |= RADV_CMD_FLAG_WB_L2;
break;
case VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT:
flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB;
@@ -2591,7 +2591,7 @@ radv_src_access_flush(struct radv_cmd_buffer *cmd_buffer,
case VK_ACCESS_TRANSFER_WRITE_BIT:
flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
  RADV_CMD_FLAG_FLUSH_AND_INV_DB |
- RADV_CMD_FLAG_INV_GLOBAL_L2;
+ RADV_CMD_FLAG_INV_L2;
 
if (flush_CB_meta)
flush_bits |= 
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
@@ -2648,19 +2648,19 @@ radv_dst_access_flush(struct radv_cmd_buffer 
*cmd_buffer,
case VK_ACCESS_TRANSFORM_FEEDBACK_COUNTER_WRITE_BIT_EXT:
break;
case VK_ACCESS_UNIFORM_READ_BIT:
-   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 | 
RADV_CMD_FLAG_INV_SMEM_L1;
+   flush_bits |= RADV_CMD_FLAG_INV_VCACHE | 
RADV_CMD_FLAG_INV_SCACHE;
break;
case VK_ACCESS_VERTEX_ATTRIBUTE_READ_BIT:
case VK_ACCESS_TRANSFER_READ_BIT:
case VK_ACCESS_INPUT_ATTACHMENT_READ_BIT:
-   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1 |
- RADV_CMD_FLAG_INV_GLOBAL_L2;
+   flush_bits |= RADV_CMD_FLAG_INV_VCACHE |
+ RADV_CMD_FLAG_INV_L2;
break;
case VK_ACCESS_SHADER_READ_BIT:
-   flush_bits |= RADV_CMD_FLAG_INV_VMEM_L1;
+   flush_bits |= RADV_CMD_FLAG_INV_VCACHE;
 
if (!image_is_coherent)
-   flush_bits |= RADV_CMD_FLAG_INV_GLOBAL_L2;
+   flush_bits |= RADV_CMD_FLAG_INV_L2;
break;
case VK_ACCESS_COLOR_ATTACHMENT_READ_BIT:
if (flush_CB)
@@ -3355,7 +3355,7 @@ VkResult radv_EndCommandBuffer(
 
if (cmd_buffer->queue_family_index != RADV_QUEUE_TRANSFER) {
if (cmd_buffer->device->physical_device->rad_info.chip_class == 
GFX6)
-   cmd_buffer->state.flush_bits |= 
RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH | 
RADV_CMD_FLAG_WRITEBACK_GLOBAL_L2;
+   cmd_buffer->state.flush_bits |= 
RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH | 
RADV_CMD_FLAG_WB_L2;
 
/* Make sure to sync all pending active queries at the end of
 * command buffer.
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index f12b8bde1f9..8d4964073cf 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -2704,9 +2704,9 @@ radv_get_preamble_cs(struct radv_queue *queue,
 
queue->device->physical_device->rad_info.chip_class >= GFX7,
   (queue->queue_family_index == 
RADV_QUEUE_COMPUTE ? RADV_CMD_FLAG_CS_PARTIAL_FLUSH : 
(RADV_CMD_FLAG_CS_PARTIAL_FLUSH | RADV_CMD_FLAG_PS_PARTIAL_FLUSH)) |
   RADV_CMD_FLAG_INV_ICACHE |
-  RADV_CMD_FLAG_INV_SMEM_L1 |
-  RADV_CMD_FLAG_INV_VMEM_L1 |
-  RADV_CMD_FLAG_INV_GLOBAL_L2 |
+  RADV_CMD_FLAG_INV_SCACHE |
+ 

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-25 Thread Daniel Stone
Hi,

On Tue, 25 Jun 2019 at 16:07, Jason Ekstrand  wrote:
> On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone  wrote:
>> On Tue, 25 Jun 2019 at 07:26, Simon Ser  wrote:
>> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
>> > > have usage at first but it was removed during the review. I'm having
>> > > trouble digging what was the reason for this?
>> >
>> > I'm not sure either. Daniel said it was a mistake.
>> >
>> > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
>> > the details?
>>
>> We decided to remove it since we decided that modifiers were a good
>> enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
>> because we already get the scanout modifiers from KMS and the texture
>> modifiers from EGL.
>>
>> In hindsight, I think this was a mistake since it only handles buffer
>> layout, and not buffer placement or cache configuration.
>
>
> It's not great but modifiers should be able to handle that as well.  You can 
> have _CONTIGUOUS versions of the modifiers supported by scanout and scanout 
> will only advertise those and the caller has to know to place them in 
> contiguous memory.  That's just an example but I think it would probably work 
> for a lot of the cases.  If not, I'd love to know why not.

Sometimes it's _CONTIGUOUS, sometimes it's _ON_THIS_PCIE_DEVICE.
Either way, it does seem like a bit of an abuse: it has nothing to do
with internal buffer layout, but how and where the backing pages are
sourced.

Given that it's completely orthogonal, I wouldn't like to go trying to
combine it into the same namespace.

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

Re: [Mesa-dev] [PATCH] gallivm: Improve lp_build_rcp_refine.

2019-06-25 Thread Roland Scheidegger
Looks good to me, albeit it's potentially minimally slower, so I'm
wondering if the higher precision is actually useful?
I guess though the last two steps could use lp_build_fmuladd?
Reviewed-by: Roland Scheidegger 



Am 25.06.19 um 11:17 schrieb Jose Fonseca:
> Use the alternative more accurate expression from
> https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%80%93Raphson_division
> 
> Tested by enabling this code path, and running gloss mesa demo.
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_arit.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> index 02fb81afe51..8aa5931eb69 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
> @@ -2707,11 +2707,11 @@ lp_build_sqrt(struct lp_build_context *bld,
>  /**
>   * Do one Newton-Raphson step to improve reciprocate precision:
>   *
> - *   x_{i+1} = x_i * (2 - a * x_i)
> + *   x_{i+1} = x_i + x_i * (1 - a * x_i)
>   *
>   * XXX: Unfortunately this won't give IEEE-754 conformant results for 0 or
>   * +/-Inf, giving NaN instead.  Certain applications rely on this behavior,
> - * such as Google Earth, which does RCP(RSQRT(0.0) when drawing the Earth's
> + * such as Google Earth, which does RCP(RSQRT(0.0)) when drawing the Earth's
>   * halo. It would be necessary to clamp the argument to prevent this.
>   *
>   * See also:
> @@ -2724,12 +2724,13 @@ lp_build_rcp_refine(struct lp_build_context *bld,
>  LLVMValueRef rcp_a)
>  {
> LLVMBuilderRef builder = bld->gallivm->builder;
> -   LLVMValueRef two = lp_build_const_vec(bld->gallivm, bld->type, 2.0);
> LLVMValueRef res;
>  
> res = LLVMBuildFMul(builder, a, rcp_a, "");
> -   res = LLVMBuildFSub(builder, two, res, "");
> +   res = LLVMBuildFSub(builder, bld->one, res, "");
> +
> res = LLVMBuildFMul(builder, rcp_a, res, "");
> +   res = LLVMBuildFAdd(builder, rcp_a, res, "");
>  
> return res;
>  }
> 

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

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-25 Thread Jason Ekstrand
On Tue, Jun 25, 2019 at 4:04 AM Daniel Stone  wrote:

> Hi,
>
> On Tue, 25 Jun 2019 at 07:26, Simon Ser  wrote:
> > > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
> > > have usage at first but it was removed during the review. I'm having
> > > trouble digging what was the reason for this?
> >
> > I'm not sure either. Daniel said it was a mistake.
> >
> > Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
> > the details?
>
> We decided to remove it since we decided that modifiers were a good
> enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
> because we already get the scanout modifiers from KMS and the texture
> modifiers from EGL.
>
> In hindsight, I think this was a mistake since it only handles buffer
> layout, and not buffer placement or cache configuration.
>

It's not great but modifiers should be able to handle that as well.  You
can have _CONTIGUOUS versions of the modifiers supported by scanout and
scanout will only advertise those and the caller has to know to place them
in contiguous memory.  That's just an example but I think it would probably
work for a lot of the cases.  If not, I'd love to know why not.

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

[Mesa-dev] [Bug 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110995

--- Comment #1 from Samuel Pitoiset  ---
Can you try to revert 410759091173fa61436ba46baeb20a79d5767849 ?

Btw, 158 vs 168 is really a small diff.

-- 
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: set DISABLE_CONSTANT_ENCODE_REG to 1 for Raven2

2019-06-25 Thread Bas Nieuwenhuizen
r-b

On Tue, Jun 25, 2019 at 4:13 PM Samuel Pitoiset
 wrote:
>
> Ported from RadeonSI, will be emitted for GFX10 too.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 5 -
>  src/amd/vulkan/radv_device.c | 2 ++
>  src/amd/vulkan/radv_private.h| 3 +++
>  3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 215ccced144..45c4d20e4fe 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1876,6 +1876,8 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
>S_028208_BR_Y(framebuffer->height));
>
> if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX8) 
> {
> +   bool disable_constant_encode =
> +   
> cmd_buffer->device->physical_device->has_dcc_constant_encode;
> uint8_t watermark = 4; /* Default value for GFX8. */
>
> /* For optimal DCC performance. */
> @@ -1889,7 +1891,8 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
> *cmd_buffer)
>
> radeon_set_context_reg(cmd_buffer->cs, 
> R_028424_CB_DCC_CONTROL,
>
> S_028424_OVERWRITE_COMBINER_MRT_SHARING_DISABLE(1) |
> -  
> S_028424_OVERWRITE_COMBINER_WATERMARK(watermark));
> +  
> S_028424_OVERWRITE_COMBINER_WATERMARK(watermark) |
> +  
> S_028424_DISABLE_CONSTANT_ENCODE_REG(disable_constant_encode));
> }
>
> if (cmd_buffer->device->dfsm_allowed) {
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 26b31cff9f1..f12b8bde1f9 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -371,6 +371,8 @@ radv_physical_device_init(struct radv_physical_device 
> *device,
>(device->rad_info.chip_class >= GFX8 &&
> device->rad_info.me_fw_feature >= 41);
>
> +   device->has_dcc_constant_encode = device->rad_info.family == 
> CHIP_RAVEN2;
> +
> device->use_shader_ballot = device->instance->perftest_flags & 
> RADV_PERFTEST_SHADER_BALLOT;
>
> radv_physical_device_init_mem_types(device);
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 1249ad0445d..c983be0d378 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -319,6 +319,9 @@ struct radv_physical_device {
> /* Whether to enable the AMD_shader_ballot extension */
> bool use_shader_ballot;
>
> +   /* Whether DISABLE_CONSTANT_ENCODE_REG is supported. */
> +   bool has_dcc_constant_encode;
> +
> /* This is the drivers on-disk cache used as a fallback as opposed to
>  * the pipeline cache defined by apps.
>  */
> --
> 2.22.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 110995] performance regression in Heroes of the Storm with Mesa 19.1.1 & Polaris

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110995

Bug ID: 110995
   Summary: performance regression in Heroes of the Storm with
Mesa 19.1.1 & Polaris
   Product: Mesa
   Version: 19.1
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: tempel.jul...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

I lose at least 10 fps with 19.1.1 vs. 19.0 on RX 580.

19.1 (at least 168 fps):
https://abload.de/img/screenshot_20190625_16akrb.png

19.1.1 (not more than 158fps):
https://abload.de/img/screenshot_20190625_1kij8n.png


Performance regressions first occured in mesa-git around a week ago which is
why I switched to stable 19.0. mesa-git was even worse though with ~150fps.
Probably related to work regarding DCC?


linux 5.1
dxvk-git
both LLVM 8 & 9

-- 
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 95022] error: GLSL 1.50 is not supported.

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=95022

--- Comment #7 from Glenda Rolfson  ---
Special educator job is not a simple job rather it requires more patience as
compared to any other job. Coping https://penzu.com/public/64b7c502 and the
special needs of students requires a lot of patience. Tackling such issues
takes a plenty of time.

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

Re: [Mesa-dev] [PATCH 1/2] radv: fix setting CB_DCC_BASE if the base level doesn't enable DCC

2019-06-25 Thread Samuel Pitoiset


On 6/25/19 1:38 AM, Bas Nieuwenhuizen wrote:

why?

We should be regulating enabling it with S_028C70_DCC_ENABLE.

Correct. Please ignore this patch, it's not wrong, just useless.


On Mon, Jun 24, 2019 at 5:00 PM Samuel Pitoiset
 wrote:

CB_DCC_BASE should be 0 if no DCC.

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

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 26b31cff9f1..dc5de683050 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4342,15 +4342,16 @@ radv_initialise_color_surface(struct radv_device 
*device,
 va += iview->image->cmask.offset;
 cb->cb_color_cmask = va >> 8;

-   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
-   va += iview->image->dcc_offset;
+   if (radv_dcc_enabled(iview->image, iview->base_mip)) {
+   va = radv_buffer_get_va(iview->bo) + iview->image->offset;
+   va += iview->image->dcc_offset;

-   if (radv_dcc_enabled(iview->image, iview->base_mip) &&
-   device->physical_device->rad_info.chip_class <= GFX8)
-   va += plane->surface.u.legacy.level[iview->base_mip].dcc_offset;
+   if (device->physical_device->rad_info.chip_class <= GFX8)
+   va += 
plane->surface.u.legacy.level[iview->base_mip].dcc_offset;

-   cb->cb_dcc_base = va >> 8;
-   cb->cb_dcc_base |= surf->tile_swizzle;
+   cb->cb_dcc_base = va >> 8;
+   cb->cb_dcc_base |= surf->tile_swizzle;
+   }

 uint32_t max_slice = radv_surface_max_layer_count(iview) - 1;
 cb->cb_color_view = S_028C6C_SLICE_START(iview->base_layer) |
--
2.22.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] [PATCH] radv: set DISABLE_CONSTANT_ENCODE_REG to 1 for Raven2

2019-06-25 Thread Samuel Pitoiset
Ported from RadeonSI, will be emitted for GFX10 too.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 5 -
 src/amd/vulkan/radv_device.c | 2 ++
 src/amd/vulkan/radv_private.h| 3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 215ccced144..45c4d20e4fe 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1876,6 +1876,8 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
*cmd_buffer)
   S_028208_BR_Y(framebuffer->height));
 
if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX8) {
+   bool disable_constant_encode =
+   
cmd_buffer->device->physical_device->has_dcc_constant_encode;
uint8_t watermark = 4; /* Default value for GFX8. */
 
/* For optimal DCC performance. */
@@ -1889,7 +1891,8 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
*cmd_buffer)
 
radeon_set_context_reg(cmd_buffer->cs, R_028424_CB_DCC_CONTROL,
   
S_028424_OVERWRITE_COMBINER_MRT_SHARING_DISABLE(1) |
-  
S_028424_OVERWRITE_COMBINER_WATERMARK(watermark));
+  
S_028424_OVERWRITE_COMBINER_WATERMARK(watermark) |
+  
S_028424_DISABLE_CONSTANT_ENCODE_REG(disable_constant_encode));
}
 
if (cmd_buffer->device->dfsm_allowed) {
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 26b31cff9f1..f12b8bde1f9 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -371,6 +371,8 @@ radv_physical_device_init(struct radv_physical_device 
*device,
   (device->rad_info.chip_class >= GFX8 &&
device->rad_info.me_fw_feature >= 41);
 
+   device->has_dcc_constant_encode = device->rad_info.family == 
CHIP_RAVEN2;
+
device->use_shader_ballot = device->instance->perftest_flags & 
RADV_PERFTEST_SHADER_BALLOT;
 
radv_physical_device_init_mem_types(device);
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 1249ad0445d..c983be0d378 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -319,6 +319,9 @@ struct radv_physical_device {
/* Whether to enable the AMD_shader_ballot extension */
bool use_shader_ballot;
 
+   /* Whether DISABLE_CONSTANT_ENCODE_REG is supported. */
+   bool has_dcc_constant_encode;
+
/* This is the drivers on-disk cache used as a fallback as opposed to
 * the pipeline cache defined by apps.
 */
-- 
2.22.0

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

Re: [Mesa-dev] [PATCH 1/4] panfrost/decode: Print AFBC struct when appropriate

2019-06-25 Thread Alyssa Rosenzweig
This series is:

Reviewed-by: Alyssa Rosenzweig 

---

I will caution you about the fault_pointer -- it doesn't do what you
think it does. I once spent about a week chasing a bug in the FBD, since
that's what the fault_pointer said. It was in the mali_viewport. It was
the right *job* -- still the TILER -- but the pointer itself was bad,
not enough granularity I guess.

So it's good to have those pointers available but don't lean on it too
hard?


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

Re: [Mesa-dev] renderdoc-traces: like shader-db for runtime

2019-06-25 Thread Eero Tamminen

Hi,

On 24.6.2019 19.36, Elie Tournier wrote:

Great topic. For the past few days, I was looking at a CI for Mesa:
https://gitlab.freedesktop.org/hopetech/tracie
OK, it's in a very very alpha stage. ;)

My idea was to use apitrace to dump and replay traces then compare images with 
reference
images or images dump the previous week.
Apitrace was a good choice for a "correctness CI", maybe not for the "performance 
CI".

@eric Out of curiosity, did you looked at apitrace or did you go straight with 
renderdoc?


Note: ezBench supports both Apitrace & vktrace.



I add below some comments based on what I learned playing with the CI.


On Sat, Jun 22, 2019 at 10:59:34AM -0700, Rob Clark wrote:

On Thu, Jun 20, 2019 at 12:26 PM Eric Anholt  wrote:


Hey folks, I wanted to show you this follow-on to shader-db I've been
working on:

https://gitlab.freedesktop.org/anholt/renderdoc-traces


"On each frame drawn, renderdoccmd replay sets up the initial GL state 
again. This will include compiling programs."


Ouch.  This makes it pretty much useless for performance testing.



For x86 development I've got a collection of ad-hoc scripts to capture
FPS numbers from various moderately interesting open source apps so I
could compare-perf them.  I was only looking at specific apps when they
seemed relevant, so it would be easy to miss regressions.

Starting work on freedreno, one of the first questions I ran into was
"does this change to the command stream make the driver faster?".  I
don't have my old set of apps on my debian ARM systems, and even less so
for Chrome OS.  Ultimately, users will be judging us based on web
browser and android app performance, not whatever I've got laying around
on my debian system.  And, I'd love to fix that "I ignore apps unless I
think of them" thing.

So, I've used renderdoc to capture some traces from Android apps.  With
an unlocked phone, it's pretty easy.  Tossing those in a repo (not
shared here), I can then run driver changes past them to see what
happens.  See
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1134 for some
results.

Where is this repo going from here?

- I add a runner for doing frame-to-frame consistency tests.  We could
   catch UB in a lot of circumstances by replaying a few times and making
   sure that results are consistent.  Comparing frames between drivers
   might also be interesting, though for that you would need human
   validation since pixel values and pixels lit will change on many
   shader optimization changes.

Comparing frames between drivers is hard. I try comparing LLVMpipe, sotfpipe 
and i965.
They all produce different frames.
For the human validation, it's sadly hard to avoid. One of the idea Erik come 
of with
was to use a mask.


Statistical approach could be better (like error is handled in video
compression).



I think we should first focus on comparing frame from the same driver and 
extend later.
The subject is hard enough. ;)


Note that there are some benchmarks which don't produce stable rendering
results because they include random input, so you can't do automated
rendering differences detection for them.  I would suggest just dropping
those (I don't anymore remember which benchmarks were such, but Martin
Peres might).



- Need to collect more workloads for the public repo:

I would be happy to help here.
We should create a list of FOSS games/apps to dump based on there OGL 
requirement.


   - I've tried to capture webgl on Chrome and Firefox on Linux with no
 luck. WebGL on ff is supposed to work under apitrace, maybe I could
 do that and then replay on top of renderdoc to capture.


perhaps worth a try capturing these on android?

I have managed to apitrace chromium-browser in the past.. it ends up a
bit weird because there are multiple contexts, but apitrace has
managed to replay them.  Maybe the multiple ctx thing is confusing
renderdoc?

(tbh I've not really played w/ renderdoc yet.. I should probably do so..)


   - Mozilla folks tell me that firefox's WebRender display lists can be
 captured in browser and then replayed from the WR repo under
 apitrace or rendredoc.

   - I tried capturing Mozilla's new Pathfinder (think SVG renderer), but
 it wouldn't play the demo under renderdoc.

   Do you have some apps that should be represented here?

- Add microbenchmarks?  Looks like it would be pretty easy to grab
   piglit drawoverhead results, not using renderdoc.  Capturing from
   arbitrary apps expands the scope of the repo in a way I'm not sure I'm
   excited about (Do we do different configs in those apps?  Then we need
   config infrastructure.  Ugh).

- I should probably add an estimate of "does this overall improve or
   hurt perf?"  Yay doing more stats.


Good way to measure perf could be repeating specific frame in a trace
(when that doesn't include re-compiling the shaders).

If I remember correctly, that's already supported by vktrace and
(apitrace based) frameretrace.



Sure. Sadly mo

[Mesa-dev] [Bug 110921] virgl on OpenGL 3.3 host regressed to OpenGL 2.1

2019-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110921

Juan A. Suarez  changed:

   What|Removed |Added

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

--- Comment #8 from Juan A. Suarez  ---
The MR was merged, and the fix included in Mesa 19.1.1.

-- 
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] [ANNOUNCE] Mesa 19.1.1

2019-06-25 Thread Juan A. Suarez Romero
Mesa 19.1.1 is now available.

In this release we have:

Mostly in fixes for different drivers (RADV, ANV,
Nouveau, Virgl, V3D, R300g, ...)

Also different fixes for different parts (Meson build, GLX,
etc).


Alejandro Piñeiro (1):
  v3d: fix checking twice auf flag

Bas Nieuwenhuizen (5):
  radv: Skip transitions coming from external queue.
  radv: Decompress DCC when the image format is not allowed for buffers.
  radv: Fix vulkan build in meson.
  anv: Fix vulkan build in meson.
  meson: Allow building radeonsi with just the android platform.

Dave Airlie (1):
  nouveau: fix frees in unsupported IR error paths.

Eduardo Lima Mitev (1):
  freedreno/a5xx: Fix indirect draw max_indices calculation

Eric Engestrom (3):
  util/futex: fix dangling pointer use
  glx: fix glvnd pointer types
  util/os_file: resize buffer to what was actually needed

Gert Wollny (1):
  virgl: Assume sRGB write control for older guest kernels or virglrenderer 
hosts

Haihao Xiang (1):
  i965: support UYVY for external import only

Jason Ekstrand (1):
  anv: Set STATE_BASE_ADDRESS upper bounds on gen7

Juan A. Suarez Romero (3):
  docs: Add SHA256 sums for 19.1.0
  Update version to 19.1.1
  docs: add release notes for 19.1.1

Kenneth Graunke (2):
  glsl: Fix out of bounds read in shader_cache_read_program_metadata
  iris: Fix iris_flush_and_dirty_history to actually dirty history.

Kevin Strasser (2):
  gallium/winsys/kms: Fix dumb buffer bpp
  st/mesa: Add rgbx handling for fp formats

Lionel Landwerlin (2):
  anv: do not parse genxml data without INTEL_DEBUG=bat
  intel/dump: fix segfault when the app hasn't accessed the device

Mathias Fröhlich (1):
  egl: Don't add hardware device if there is no render node v2.

Richard Thier (1):
  r300g: restore performance after RADEON_FLAG_NO_INTERPROCESS_SHARING was 
added

Rob Clark (1):
  freedreno/a6xx: un-swap X24S8_UINT

Samuel Pitoiset (4):
  radv: fix occlusion queries on VegaM
  radv: fix VK_EXT_memory_budget if one heap isn't available
  radv: fix FMASK expand with SRGB formats
  radv: disable viewport clamping even if FS doesn't write Z

git tag: mesa-19.1.1

https://mesa.freedesktop.org/archive/mesa-19.1.1.tar.xz
MD5:  07cd8cd79de28ec1a374ee3a06e47789  mesa-19.1.1.tar.xz
SHA1: b906dd39d6cd3aca523429e705c79dabc97ea96d  mesa-19.1.1.tar.xz
SHA256: 72114b16b4a84373b2acda060fe2bb1d45ea2598efab3ef2d44bdeda74f15581  
mesa-19.1.1.tar.xz
SHA512: 
73b190eeb0b5809217c04f39d90edc0844dac476d8284543013a4a8889a4be805bc15b43c91bbf0d3a36f35dc576e7085255f7012d207c74466e81cee7f67922
  mesa-19.1.1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.1.tar.xz.sig



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

[Mesa-dev] [PATCH 4/8] android: radv: fix improper use of LOCAL_WHOLE_STATIC_LIBRARIES

2019-06-25 Thread Chih-Wei Huang
The libmesa_git_sha1 is a dummy library. There is no reason to put
it into LOCAL_WHOLE_STATIC_LIBRARIES.

Move libmesa_vulkan_util to the vulkan.radv which really needs it.

Signed-off-by: Chih-Wei Huang 
---
 src/amd/vulkan/Android.mk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index a7c31d4..4290cc0 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -74,7 +74,7 @@ LOCAL_C_INCLUDES := \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := \
+LOCAL_STATIC_LIBRARIES := \
libmesa_vulkan_util \
libmesa_git_sha1
 
@@ -158,7 +158,8 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_compiler \
libmesa_amdgpu_addrlib \
libmesa_amd_common \
-   libmesa_radv_common
+   libmesa_radv_common \
+   libmesa_vulkan_util
 
 LOCAL_SHARED_LIBRARIES += $(RADV_SHARED_LIBRARIES) libz libsync liblog
 
-- 
2.7.4

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

[Mesa-dev] [PATCH 8/8] android: radv: import include paths from used libraries

2019-06-25 Thread Chih-Wei Huang
It's unnecessary to manually add these include paths since they could
be imported automatically.

Signed-off-by: Chih-Wei Huang 
---
 src/amd/vulkan/Android.mk | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 52993cc..322620f 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -33,8 +33,6 @@ RADV_COMMON_INCLUDES := \
$(MESA_TOP)/src/vulkan/wsi \
$(MESA_TOP)/src/vulkan/util \
$(MESA_TOP)/src/amd \
-   $(MESA_TOP)/src/amd/common \
-   $(MESA_TOP)/src/compiler \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/mesa \
$(MESA_TOP)/src/mesa/drivers/dri/common \
@@ -66,14 +64,12 @@ LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
 
 $(call mesa-build-with-llvm)
 
-LOCAL_C_INCLUDES := \
-   $(RADV_COMMON_INCLUDES) \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_amd_common,,)/common \
-   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,) \
-   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
+LOCAL_C_INCLUDES := $(RADV_COMMON_INCLUDES)
 
 LOCAL_STATIC_LIBRARIES := \
+   libmesa_amd_common \
+   libmesa_nir \
+   libmesa_util \
libmesa_vulkan_util \
libmesa_git_sha1
 
@@ -146,9 +142,7 @@ LOCAL_CFLAGS += -DVK_USE_PLATFORM_ANDROID_KHR
 
 $(call mesa-build-with-llvm)
 
-LOCAL_C_INCLUDES := \
-   $(RADV_COMMON_INCLUDES) \
-   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,)
+LOCAL_C_INCLUDES := $(RADV_COMMON_INCLUDES)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_util \
-- 
2.7.4

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

[Mesa-dev] [PATCH 5/8] android: vulkan/util: fix export path

2019-06-25 Thread Chih-Wei Huang
Export the correct include path so that the libraries use it can
get it automatically.

Signed-off-by: Chih-Wei Huang 
---
 src/amd/vulkan/Android.mk   | 1 -
 src/intel/Android.vulkan.mk | 1 -
 src/vulkan/Android.mk   | 3 +--
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 4290cc0..52993cc 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -71,7 +71,6 @@ LOCAL_C_INCLUDES := \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_amd_common,,)/common \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,) \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
 
 LOCAL_STATIC_LIBRARIES := \
diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 4fff842..5083fec 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -107,7 +107,6 @@ ANV_INCLUDES := \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_anv_entrypoints,,)/vulkan \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_common,,)/vulkan \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
 
 ANV_SHARED_LIBRARIES := libdrm
 
diff --git a/src/vulkan/Android.mk b/src/vulkan/Android.mk
index 99dd3f5..c3230d8 100644
--- a/src/vulkan/Android.mk
+++ b/src/vulkan/Android.mk
@@ -62,8 +62,7 @@ $(LOCAL_GENERATED_SOURCES): 
$(MESA_TOP)/src/vulkan/util/gen_enum_to_str.py \
--xml $(vulkan_api_xml) \
--outdir $(dir $@)
 
-LOCAL_EXPORT_C_INCLUDE_DIRS := \
-$(intermediates)
+LOCAL_EXPORT_C_INCLUDE_DIRS := $(intermediates)/util
 
 ifeq ($(filter $(MESA_ANDROID_MAJOR_VERSION), 4 5 6 7),)
 LOCAL_SHARED_LIBRARIES += libnativewindow
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/8] android: anv: remove unused LOCAL_EXPORT_C_INCLUDE_DIRS

2019-06-25 Thread Chih-Wei Huang
The vulkan module is the final HAL. No need to export its headers
since none will import it.

Signed-off-by: Chih-Wei Huang 
---
 src/intel/Android.vulkan.mk | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 3c257e5..8d978c3 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -316,8 +316,6 @@ LOCAL_C_INCLUDES := \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_anv_entrypoints,,)/vulkan \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_common,,)/vulkan
 
-LOCAL_EXPORT_C_INCLUDE_DIRS := $(MESA_TOP)/src/intel/vulkan
-
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_nir \
libmesa_isl \
-- 
2.7.4

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

[Mesa-dev] [PATCH 6/8] android: anv: eliminate libmesa_anv_entrypoints

2019-06-25 Thread Chih-Wei Huang
The dummy library libmesa_anv_entrypoints is totally unnecessary.
The four VULKAN_GENERATED_FILES could be generated and built in
libmesa_vulkan_common directly. The libraries using the generated
headers should get it via the exported include path.

Signed-off-by: Chih-Wei Huang 
---
 src/intel/Android.vulkan.mk | 82 +++--
 1 file changed, 20 insertions(+), 62 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 5083fec..450cf2e 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -53,60 +53,9 @@ VULKAN_COMMON_HEADER_LIBRARIES := \
libhardware_headers
 endif
 
-# libmesa_anv_entrypoints with header and dummy.c
-#
-# This static library is built to pull entrypoints header
-# for multiple gen specific build targets below. The c file
-# is generated separately for libmesa_vulkan_common to avoid
-# duplicate symbols when linking the anv libraries.
-
-include $(CLEAR_VARS)
-LOCAL_MODULE := libmesa_anv_entrypoints
-LOCAL_MODULE_CLASS := STATIC_LIBRARIES
-
-intermediates := $(call local-generated-sources-dir)
-
-LOCAL_C_INCLUDES := \
-   $(VULKAN_COMMON_INCLUDES)
-
-LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_entrypoints.h
-LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/dummy.c
-LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
-
-$(intermediates)/vulkan/dummy.c:
-   @mkdir -p $(dir $@)
-   @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
-   $(hide) touch $@
-
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
-  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
-  $(ANV_EXTENSIONS_SCRIPT) \
-  $(VULKAN_API_XML)
-   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
-   --outdir $(dir $@) \
-   --xml $(VULKAN_API_XML)
-
-$(intermediates)/vulkan/anv_extensions.h: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
- $(ANV_EXTENSIONS_SCRIPT) \
- $(VULKAN_API_XML)
-   @mkdir -p $(dir $@)
-   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
-   --xml $(VULKAN_API_XML) \
-   --out-h $@
-
-LOCAL_EXPORT_C_INCLUDE_DIRS := \
-$(intermediates)
-
-LOCAL_SHARED_LIBRARIES := libdrm
-
-include $(MESA_COMMON_MK)
-include $(BUILD_STATIC_LIBRARY)
-
 ANV_INCLUDES := \
$(VULKAN_COMMON_INCLUDES) \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_anv_entrypoints,,)/vulkan \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_common,,)/vulkan \
 
 ANV_SHARED_LIBRARIES := libdrm
 
@@ -127,7 +76,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=70
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -148,7 +97,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=75
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -169,7 +118,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=80
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -190,7 +139,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=90
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -211,7 +160,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=100
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -232,7 +181,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=110
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -252,12 +201,14 @@ intermediates := $(call local-generated-sources-dir)
 
 LOCAL_SRC_FILES := $(VULKAN_FILES)
 

[Mesa-dev] [PATCH 0/8] Android makefiles clean up

2019-06-25 Thread Chih-Wei Huang
There are several issues in the current Android makefiles. Though they
may not affect the functionalities, it's ugly and unprofessional.

* Add unnecessary LOCAL_EXPORT_C_INCLUDE_DIRS
* Not export necessary include paths
* Add dummy libraries to LOCAL_WHOLE_STATIC_LIBRARIES
* Use unnecessary dummy library to generate headers
* Add include paths which could be imported automatically

This is a series of patches to clean up these issues.


Chih-Wei Huang (8):
  android: anv: remove unused LOCAL_EXPORT_C_INCLUDE_DIRS
  android: radv: remove unused LOCAL_EXPORT_C_INCLUDE_DIRS
  android: anv: fix improper use of LOCAL_WHOLE_STATIC_LIBRARIES
  android: radv: fix improper use of LOCAL_WHOLE_STATIC_LIBRARIES
  android: vulkan/util: fix export path
  android: anv: eliminate libmesa_anv_entrypoints
  android: anv: import include path of libmesa_nir
  android: radv: import include paths from used libraries

 src/amd/vulkan/Android.mk   |  26 +++---
 src/intel/Android.vulkan.mk | 115 ++--
 src/vulkan/Android.mk   |   3 +-
 3 files changed, 44 insertions(+), 100 deletions(-)

-- 
2.7.4

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

[Mesa-dev] [PATCH 7/8] android: anv: import include path of libmesa_nir

2019-06-25 Thread Chih-Wei Huang
Add libmesa_nir to a common LOCAL_STATIC_LIBRARIES defined by
ANV_STATIC_LIBRARIES so that its include path can be imported
automatically. Then ANV_INCLUDES is unnecessary and could be
eliminated.

Signed-off-by: Chih-Wei Huang 
---
 src/intel/Android.vulkan.mk | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 450cf2e..5d2ec4f 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -38,7 +38,6 @@ VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/src/vulkan/util \
$(MESA_TOP)/src/intel \
$(MESA_TOP)/src/intel/vulkan \
-   $(MESA_TOP)/src/compiler \
frameworks/native/vulkan/include
 
 ifeq ($(shell test $(PLATFORM_SDK_VERSION) -ge 27; echo $$?), 0)
@@ -53,9 +52,10 @@ VULKAN_COMMON_HEADER_LIBRARIES := \
libhardware_headers
 endif
 
-ANV_INCLUDES := \
-   $(VULKAN_COMMON_INCLUDES) \
-   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
+ANV_STATIC_LIBRARIES := \
+   libmesa_vulkan_common \
+   libmesa_genxml \
+   libmesa_nir
 
 ANV_SHARED_LIBRARIES := libdrm
 
@@ -74,9 +74,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN7_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=70
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -95,9 +95,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN75_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=75
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -116,9 +116,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN8_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=80
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -137,9 +137,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN9_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=90
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -158,9 +158,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN10_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=100
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -179,9 +179,9 @@ LOCAL_MODULE_CLASS := STATIC_LIBRARIES
 LOCAL_SRC_FILES := $(VULKAN_GEN11_FILES)
 LOCAL_CFLAGS := -DGEN_VERSIONx10=110
 
-LOCAL_C_INCLUDES := $(ANV_INCLUDES)
+LOCAL_C_INCLUDES := $(VULKAN_COMMON_INCLUDES)
 
-LOCAL_STATIC_LIBRARIES := libmesa_vulkan_common libmesa_genxml
+LOCAL_STATIC_LIBRARIES := $(ANV_STATIC_LIBRARIES)
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -205,10 +205,10 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := $(intermediates)/vulkan
 
 LOCAL_C_INCLUDES := \
$(LOCAL_EXPORT_C_INCLUDE_DIRS) \
-   $(ANV_INCLUDES) \
-   $(MESA_TOP)/src/compiler
+   $(VULKAN_COMMON_INCLUDES)
 
 LOCAL_STATIC_LIBRARIES := \
+   libmesa_nir \
libmesa_genxml \
libmesa_git_sha1 \
libmesa_vulkan_util
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/8] android: radv: remove unused LOCAL_EXPORT_C_INCLUDE_DIRS

2019-06-25 Thread Chih-Wei Huang
The vulkan module is the final HAL. No need to export its headers
since none will import it.

Signed-off-by: Chih-Wei Huang 
---
 src/amd/vulkan/Android.mk | 4 
 1 file changed, 4 deletions(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 0725fea..a7c31d4 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -151,10 +151,6 @@ LOCAL_C_INCLUDES := \
$(RADV_COMMON_INCLUDES) \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,)
 
-LOCAL_EXPORT_C_INCLUDE_DIRS := \
-   $(MESA_TOP)/src/amd/vulkan \
-   $(intermediates)
-
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_util \
libmesa_nir \
-- 
2.7.4

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

[Mesa-dev] [PATCH 3/8] android: anv: fix improper use of LOCAL_WHOLE_STATIC_LIBRARIES

2019-06-25 Thread Chih-Wei Huang
The libmesa_anv_entrypoints and libmesa_genxml are dummy libraries.
There is no reason to put them into LOCAL_WHOLE_STATIC_LIBRARIES.

Move libmesa_vulkan_util to the vulkan HAL which really needs it.

Signed-off-by: Chih-Wei Huang 
---
 src/intel/Android.vulkan.mk | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 8d978c3..4fff842 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -128,7 +128,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=70
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -149,7 +149,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=75
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -170,7 +170,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=80
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -191,7 +191,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=90
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -212,7 +212,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=100
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -233,7 +233,7 @@ LOCAL_CFLAGS := -DGEN_VERSIONx10=110
 
 LOCAL_C_INCLUDES := $(ANV_INCLUDES)
 
-LOCAL_WHOLE_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
+LOCAL_STATIC_LIBRARIES := libmesa_anv_entrypoints libmesa_genxml
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
@@ -257,7 +257,7 @@ LOCAL_C_INCLUDES := \
$(ANV_INCLUDES) \
$(MESA_TOP)/src/compiler
 
-LOCAL_WHOLE_STATIC_LIBRARIES := \
+LOCAL_STATIC_LIBRARIES := \
libmesa_anv_entrypoints \
libmesa_genxml \
libmesa_git_sha1 \
@@ -326,14 +326,14 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_common \
libmesa_intel_dev \
libmesa_vulkan_common \
+   libmesa_vulkan_util \
libmesa_anv_gen7 \
libmesa_anv_gen75 \
libmesa_anv_gen8 \
libmesa_anv_gen9 \
libmesa_anv_gen10 \
libmesa_anv_gen11 \
-   libmesa_intel_compiler \
-   libmesa_anv_entrypoints
+   libmesa_intel_compiler
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libz libsync liblog
 LOCAL_HEADER_LIBRARIES += $(VULKAN_COMMON_HEADER_LIBRARIES)
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] android: virgl: fix libmesa_virgil_common build and dependencies

2019-06-25 Thread Chih-Wei Huang
Mauro Rossi  於 2019年6月25日 週二 下午5:52寫道:
>
> Hi,
>
> On Mon, Jun 24, 2019 at 8:55 AM Chih-Wei Huang  
> wrote:
>>
>> Mauro Rossi  於 2019年6月15日 週六 下午1:39寫道:
>> >
>> > Fixes the following building errors and resolves Bug 110922
>> > Fixes gallium_dri target missing symbols at linking.
>> >
>> > external/mesa/src/gallium/winsys/virgl/drm/Android.mk:
>> > error: libmesa_winsys_virgl (STATIC_LIBRARIES android-x86_64) missing 
>> > libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
>> > ...
>> > external/mesa/src/gallium/winsys/virgl/vtest/Android.mk:
>> > error: libmesa_winsys_virgl_vtest (STATIC_LIBRARIES android-x86_64) 
>> > missing libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
>> > ...
>> > build/core/main.mk:728: error: exiting from previous errors.
>> >
>> > In file included from 
>> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c:34:
>> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
>> > fatal error: 'virgl_resource_cache.h' file not found
>> >  ^~~~
>> > 1 error generated.
>> >
>> > In file included from 
>> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c:32:
>> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
>> > fatal error: 'virgl_resource_cache.h' file not found
>> > #include "virgl_resource_cache.h"
>> >  ^~~~
>> > 1 error generated.
>> >
>> > Fixes: b18f09a ("virgl: Introduce virgl_resource_cache")
>> > Signed-off-by: Mauro Rossi 
>> > ---
>> >  src/gallium/Android.mk| 2 +-
>> >  src/gallium/drivers/virgl/Android.mk  | 2 +-
>> >  src/gallium/winsys/virgl/drm/Android.mk   | 2 ++
>> >  src/gallium/winsys/virgl/vtest/Android.mk | 2 ++
>> >  4 files changed, 6 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
>> > index 3a3f042c7a..37e923c225 100644
>> > --- a/src/gallium/Android.mk
>> > +++ b/src/gallium/Android.mk
>> > @@ -43,7 +43,7 @@ SUBDIRS += winsys/radeon/drm drivers/r300
>> >  SUBDIRS += winsys/radeon/drm drivers/r600
>> >  SUBDIRS += winsys/radeon/drm winsys/amdgpu/drm drivers/radeonsi
>> >  SUBDIRS += winsys/vc4/drm drivers/vc4
>> > -SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
>> > +SUBDIRS += winsys/virgl/common winsys/virgl/drm winsys/virgl/vtest 
>> > drivers/virgl
>> >  SUBDIRS += winsys/svga/drm drivers/svga
>> >  SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
>> >  SUBDIRS += state_trackers/dri
>> > diff --git a/src/gallium/drivers/virgl/Android.mk 
>> > b/src/gallium/drivers/virgl/Android.mk
>> > index 0067dfa702..a6fe53fbe9 100644
>> > --- a/src/gallium/drivers/virgl/Android.mk
>> > +++ b/src/gallium/drivers/virgl/Android.mk
>> > @@ -35,5 +35,5 @@ include $(BUILD_STATIC_LIBRARY)
>> >
>> >  ifneq ($(HAVE_GALLIUM_VIRGL),)
>> >  GALLIUM_TARGET_DRIVERS += virtio_gpu
>> > -$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl 
>> > libmesa_winsys_virgl_vtest)
>> > +$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl_common 
>> > libmesa_winsys_virgl libmesa_winsys_virgl_vtest)
>> >  endif
>> > diff --git a/src/gallium/winsys/virgl/drm/Android.mk 
>> > b/src/gallium/winsys/virgl/drm/Android.mk
>> > index 5e2500774e..398a7645bc 100644
>> > --- a/src/gallium/winsys/virgl/drm/Android.mk
>> > +++ b/src/gallium/winsys/virgl/drm/Android.mk
>> > @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
>> >
>> >  LOCAL_SRC_FILES := $(C_SOURCES)
>> >
>> > +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
>>
>> This should be unnecessary.
>> The include path should be imported automatically.
>> However, there is a typo in Android.mk of libmesa_winsys_virgl_common
>> that prevents it from working. We should fix the typo instead of adding this.
>> Will send a patch later.
>
>
> I was also thinking the LOCAL_C_INCLUDES un-necessary,
> but for some reason fatal error: '*.h' file not found was happening without 
> this
>
> I double checked prior to submit the patch with the LOCAL_C_INCLUDES
>
>>
>>
>> > +
>> >  LOCAL_MODULE := libmesa_winsys_virgl
>> >
>> >  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
>> > diff --git a/src/gallium/winsys/virgl/vtest/Android.mk 
>> > b/src/gallium/winsys/virgl/vtest/Android.mk
>> > index 5b33f67711..6d35223c8e 100644
>> > --- a/src/gallium/winsys/virgl/vtest/Android.mk
>> > +++ b/src/gallium/winsys/virgl/vtest/Android.mk
>> > @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
>> >
>> >  LOCAL_SRC_FILES := $(C_SOURCES)
>> >
>> > +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
>>
>> Ditto
>
>
> Same comment here
> The patch has been already commited to master to at least avoid the building 
> errors
>
> If you find more correct way, please submit new patch to mesa-dev

As said, the more correct way is to fix the typo
in Android.mk of libmesa_winsys_virgl_common.
I've submitted the patch.

https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg219133.html


-- 
Chih-Wei
Andro

Re: [Mesa-dev] [PATCH] android: virgl: fix generated virgl_driinfo.h building rules

2019-06-25 Thread Mauro Rossi
Hi Chih-Wei,

On Mon, Jun 24, 2019 at 7:26 AM Chih-Wei Huang 
wrote:

> Mauro Rossi  於 2019年6月22日 週六 上午2:06寫道:
> >
> > Changelog in Android makefile:
> > - Add LOCAL_MODULE_CLASS, intermediates and LOCAL_GENERATED_SOURCES
> > - Use LOCAL_EXPORT_C_INCLUDE_DIRS to export $(intermediates) path
> > - Move generated header rules before 'include $(BUILD_STATIC_LIBRARY)'
> >
> > Fixes the following building error:
> >
> > In file included from external/mesa/src/gallium/targets/dri/target.c:1:
> > external/mesa/src/gallium/auxiliary/target-helpers/drm_helper.h:257:16:
> > fatal error: 'virgl/virgl_driinfo.h' file not found
> >   #include "virgl/virgl_driinfo.h"
> >^~~
> > 1 error generated.
> >
> > Fixes: cf800998a ("virgl: Add driinfo file and tie it into the build")
> > Signed-off-by: Mauro Rossi 
> > ---
> >  src/gallium/drivers/virgl/Android.mk | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/drivers/virgl/Android.mk
> b/src/gallium/drivers/virgl/Android.mk
> > index f77bcf196e..585ed7b2ce 100644
> > --- a/src/gallium/drivers/virgl/Android.mk
> > +++ b/src/gallium/drivers/virgl/Android.mk
> > @@ -30,8 +30,9 @@ LOCAL_SRC_FILES := \
> >
> >  LOCAL_MODULE := libmesa_pipe_virgl
> >
> > -include $(GALLIUM_COMMON_MK)
> > -include $(BUILD_STATIC_LIBRARY)
> > +LOCAL_MODULE_CLASS := STATIC_LIBRARIES
> > +intermediates := $(call local-generated-sources-dir)
> > +LOCAL_GENERATED_SOURCES += $(intermediates)/virgl/virgl_driinfo.h
> >
> >  GEN_DRIINFO_INPUTS := \
> > $(MESA_TOP)/src/gallium/auxiliary/pipe-loader/driinfo_gallium.h \
> > @@ -44,6 +45,11 @@ $(intermediates)/virgl/virgl_driinfo.h:
> $(MERGE_DRIINFO) $(GEN_DRIINFO_INPUTS)
> > @echo "Gen Header: $(PRIVATE_MODULE) <= $(notdir $(@))"
> > $(hide) $(MESA_PYTHON2) $(MERGE_DRIINFO) $(GEN_DRIINFO_INPUTS) >
> $@ || ($(RM) $@; false)
> >
> > +LOCAL_EXPORT_C_INCLUDE_DIRS += $(intermediates)
> > +
> > +include $(GALLIUM_COMMON_MK)
> > +include $(BUILD_STATIC_LIBRARY)
> > +
> >  ifneq ($(HAVE_GALLIUM_VIRGL),)
> >  GALLIUM_TARGET_DRIVERS += virtio_gpu
> >  $(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl_common
> libmesa_winsys_virgl libmesa_winsys_virgl_vtest)
> > --
>
> I suggest to use := instead of += in
> LOCAL_GENERATED_SOURCES and LOCAL_EXPORT_C_INCLUDE_DIRS
> since they don't catenate others.
>

Thanks a lot, I did not know that, I will correct in the final version.


> Except that, the patch looks good to me.
>
> Review-by: Chih-Wei Huang 
>

Thanks for the review
Mauro
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] android: virgl: fix libmesa_virgil_common build and dependencies

2019-06-25 Thread Mauro Rossi
Hi,

On Mon, Jun 24, 2019 at 8:55 AM Chih-Wei Huang 
wrote:

> Mauro Rossi  於 2019年6月15日 週六 下午1:39寫道:
> >
> > Fixes the following building errors and resolves Bug 110922
> > Fixes gallium_dri target missing symbols at linking.
> >
> > external/mesa/src/gallium/winsys/virgl/drm/Android.mk:
> > error: libmesa_winsys_virgl (STATIC_LIBRARIES android-x86_64) missing
> libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
> > ...
> > external/mesa/src/gallium/winsys/virgl/vtest/Android.mk:
> > error: libmesa_winsys_virgl_vtest (STATIC_LIBRARIES android-x86_64)
> missing libmesa_winsys_virgl_common (STATIC_LIBRARIES android-x86_64)
> > ...
> > build/core/main.mk:728: error: exiting from previous errors.
> >
> > In file included from
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_socket.c:34:
> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
> > fatal error: 'virgl_resource_cache.h' file not found
> >  ^~~~
> > 1 error generated.
> >
> > In file included from
> external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c:32:
> > external/mesa/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.h:35:10:
> > fatal error: 'virgl_resource_cache.h' file not found
> > #include "virgl_resource_cache.h"
> >  ^~~~
> > 1 error generated.
> >
> > Fixes: b18f09a ("virgl: Introduce virgl_resource_cache")
> > Signed-off-by: Mauro Rossi 
> > ---
> >  src/gallium/Android.mk| 2 +-
> >  src/gallium/drivers/virgl/Android.mk  | 2 +-
> >  src/gallium/winsys/virgl/drm/Android.mk   | 2 ++
> >  src/gallium/winsys/virgl/vtest/Android.mk | 2 ++
> >  4 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
> > index 3a3f042c7a..37e923c225 100644
> > --- a/src/gallium/Android.mk
> > +++ b/src/gallium/Android.mk
> > @@ -43,7 +43,7 @@ SUBDIRS += winsys/radeon/drm drivers/r300
> >  SUBDIRS += winsys/radeon/drm drivers/r600
> >  SUBDIRS += winsys/radeon/drm winsys/amdgpu/drm drivers/radeonsi
> >  SUBDIRS += winsys/vc4/drm drivers/vc4
> > -SUBDIRS += winsys/virgl/drm winsys/virgl/vtest drivers/virgl
> > +SUBDIRS += winsys/virgl/common winsys/virgl/drm winsys/virgl/vtest
> drivers/virgl
> >  SUBDIRS += winsys/svga/drm drivers/svga
> >  SUBDIRS += winsys/etnaviv/drm drivers/etnaviv drivers/renderonly
> >  SUBDIRS += state_trackers/dri
> > diff --git a/src/gallium/drivers/virgl/Android.mk
> b/src/gallium/drivers/virgl/Android.mk
> > index 0067dfa702..a6fe53fbe9 100644
> > --- a/src/gallium/drivers/virgl/Android.mk
> > +++ b/src/gallium/drivers/virgl/Android.mk
> > @@ -35,5 +35,5 @@ include $(BUILD_STATIC_LIBRARY)
> >
> >  ifneq ($(HAVE_GALLIUM_VIRGL),)
> >  GALLIUM_TARGET_DRIVERS += virtio_gpu
> > -$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl
> libmesa_winsys_virgl_vtest)
> > +$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_virgl_common
> libmesa_winsys_virgl libmesa_winsys_virgl_vtest)
> >  endif
> > diff --git a/src/gallium/winsys/virgl/drm/Android.mk
> b/src/gallium/winsys/virgl/drm/Android.mk
> > index 5e2500774e..398a7645bc 100644
> > --- a/src/gallium/winsys/virgl/drm/Android.mk
> > +++ b/src/gallium/winsys/virgl/drm/Android.mk
> > @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
> >
> >  LOCAL_SRC_FILES := $(C_SOURCES)
> >
> > +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
>
> This should be unnecessary.
> The include path should be imported automatically.
> However, there is a typo in Android.mk of libmesa_winsys_virgl_common
> that prevents it from working. We should fix the typo instead of adding
> this.
> Will send a patch later.
>

I was also thinking the LOCAL_C_INCLUDES un-necessary,
but for some reason fatal error: '*.h' file not found was happening without
this

I double checked prior to submit the patch with the LOCAL_C_INCLUDES


>
> > +
> >  LOCAL_MODULE := libmesa_winsys_virgl
> >
> >  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
> > diff --git a/src/gallium/winsys/virgl/vtest/Android.mk
> b/src/gallium/winsys/virgl/vtest/Android.mk
> > index 5b33f67711..6d35223c8e 100644
> > --- a/src/gallium/winsys/virgl/vtest/Android.mk
> > +++ b/src/gallium/winsys/virgl/vtest/Android.mk
> > @@ -27,6 +27,8 @@ include $(CLEAR_VARS)
> >
> >  LOCAL_SRC_FILES := $(C_SOURCES)
> >
> > +LOCAL_C_INCLUDES := $(GALLIUM_TOP)/winsys/virgl/common
>
> Ditto
>

Same comment here
The patch has been already commited to master to at least avoid the
building errors

If you find more correct way, please submit new patch to mesa-dev
Thanks

Mauro


>
> > +
> >  LOCAL_MODULE := libmesa_winsys_virgl_vtest
> >
> >  LOCAL_STATIC_LIBRARIES := libmesa_winsys_virgl_common
> > --
>
>
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallivm: Improve lp_build_rcp_refine.

2019-06-25 Thread Jose Fonseca
Use the alternative more accurate expression from
https://en.wikipedia.org/wiki/Division_algorithm#Newton%E2%80%93Raphson_division

Tested by enabling this code path, and running gloss mesa demo.
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index 02fb81afe51..8aa5931eb69 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -2707,11 +2707,11 @@ lp_build_sqrt(struct lp_build_context *bld,
 /**
  * Do one Newton-Raphson step to improve reciprocate precision:
  *
- *   x_{i+1} = x_i * (2 - a * x_i)
+ *   x_{i+1} = x_i + x_i * (1 - a * x_i)
  *
  * XXX: Unfortunately this won't give IEEE-754 conformant results for 0 or
  * +/-Inf, giving NaN instead.  Certain applications rely on this behavior,
- * such as Google Earth, which does RCP(RSQRT(0.0) when drawing the Earth's
+ * such as Google Earth, which does RCP(RSQRT(0.0)) when drawing the Earth's
  * halo. It would be necessary to clamp the argument to prevent this.
  *
  * See also:
@@ -2724,12 +2724,13 @@ lp_build_rcp_refine(struct lp_build_context *bld,
 LLVMValueRef rcp_a)
 {
LLVMBuilderRef builder = bld->gallivm->builder;
-   LLVMValueRef two = lp_build_const_vec(bld->gallivm, bld->type, 2.0);
LLVMValueRef res;
 
res = LLVMBuildFMul(builder, a, rcp_a, "");
-   res = LLVMBuildFSub(builder, two, res, "");
+   res = LLVMBuildFSub(builder, bld->one, res, "");
+
res = LLVMBuildFMul(builder, rcp_a, res, "");
+   res = LLVMBuildFAdd(builder, rcp_a, res, "");
 
return res;
 }
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-25 Thread Daniel Stone
Hi,

On Mon, 24 Jun 2019 at 19:51, Simon Ser  wrote:
> +GBM_EXPORT struct gbm_bo *
> +gbm_bo_create_with_modifiers2(struct gbm_device *gbm,
> +  uint32_t width, uint32_t height,
> +  uint32_t format,
> +  const uint64_t *modifiers,
> +  const unsigned int count,
> +  uint32_t usage)
> +{
> +   if (width == 0 || height == 0) {
> +  errno = EINVAL;
> +  return NULL;
> +   }
> +
> +   if ((count && !modifiers) || (modifiers && !count)) {
> +  errno = EINVAL;
> +  return NULL;
> +   }
> +
> +   return gbm->bo_create(gbm, width, height, format, usage, modifiers, 
> count);

This will trip an assert inside gbm_dri_bo_create:
   /* Callers of this may specify a modifier, or a dri usage, but not both. The
* newer modifier interface deprecates the older usage flags.
*/
   assert(!(usage && count));

You can fix this without modifying the libgbm <-> backend interface,
given that the two should be tightly coupled together. But within
Mesa, you'll need a new version of the DRIimageExtension, adding a
createImageWithModifiers2() which re-adds the flags, given that
they're not there in the current createImageWithModifiers() hook.

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

Re: [Mesa-dev] [PATCH] gbm: add gbm_{bo, surface}_create_with_modifiers2

2019-06-25 Thread Daniel Stone
Hi,

On Tue, 25 Jun 2019 at 07:26, Simon Ser  wrote:
> > I noticed that original patch (v1) for gbm_bo_create_with_modifiers did
> > have usage at first but it was removed during the review. I'm having
> > trouble digging what was the reason for this?
>
> I'm not sure either. Daniel said it was a mistake.
>
> Adding the 63bd2ae7452d4 folks to the discussion. Ben, do you remember
> the details?

We decided to remove it since we decided that modifiers were a good
enough proxy for usage; no need to pass SCANOUT or TEXTURE anymore,
because we already get the scanout modifiers from KMS and the texture
modifiers from EGL.

In hindsight, I think this was a mistake since it only handles buffer
layout, and not buffer placement or cache configuration.

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

[Mesa-dev] [PATCH 4/4] panfrost/decode: Mention the address of a few descriptors

2019-06-25 Thread Tomeu Vizoso
When the fault_pointer field in the header is set, we can get some idea
of which descriptor the HW isn't happy with if we know their addresses.

Signed-off-by: Tomeu Vizoso 
---
 .../drivers/panfrost/pandecode/decode.c   | 24 +--
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 2a21f072639e..587c00dd2460 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -450,7 +450,7 @@ pandecode_replay_sfbd(uint64_t gpu_va, int job_no)
 struct pandecode_mapped_memory *mem = 
pandecode_find_mapped_gpu_mem_containing(gpu_va);
 const struct mali_single_framebuffer *PANDECODE_PTR_VAR(s, mem, 
(mali_ptr) gpu_va);
 
-pandecode_log("struct mali_single_framebuffer framebuffer_%d = {\n", 
job_no);
+pandecode_log("struct mali_single_framebuffer framebuffer_%"PRIx64"_%d 
= {\n", gpu_va, job_no);
 pandecode_indent++;
 
 pandecode_prop("unknown1 = 0x%" PRIx32, s->unknown1);
@@ -555,7 +555,7 @@ pandecode_compute_fbd(uint64_t gpu_va, int job_no)
 struct pandecode_mapped_memory *mem = 
pandecode_find_mapped_gpu_mem_containing(gpu_va);
 const struct mali_compute_fbd *PANDECODE_PTR_VAR(s, mem, (mali_ptr) 
gpu_va);
 
-pandecode_log("struct mali_compute_fbd framebuffer_%d = {\n", job_no);
+pandecode_log("struct mali_compute_fbd framebuffer_%"PRIx64"_%d = 
{\n", gpu_va, job_no);
 pandecode_indent++;
 
 SHORT_SLIDE(1);
@@ -605,7 +605,7 @@ pandecode_rt_format(struct mali_rt_format format)
 static void
 pandecode_render_target(uint64_t gpu_va, unsigned job_no, const struct 
bifrost_framebuffer *fb)
 {
-pandecode_log("struct bifrost_render_target rts_list_%d[] = {\n", 
job_no);
+pandecode_log("struct bifrost_render_target rts_list_%"PRIx64"_%d[] = 
{\n", gpu_va, job_no);
 pandecode_indent++;
 
 for (int i = 0; i < MALI_NEGATIVE(fb->rt_count_1); i++) {
@@ -704,7 +704,7 @@ pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no, bool 
with_render_targets)
 pandecode_log("};\n");
 }
 
-pandecode_log("struct bifrost_framebuffer framebuffer_%d = {\n", 
job_no);
+pandecode_log("struct bifrost_framebuffer framebuffer_%"PRIx64"_%d = 
{\n", gpu_va, job_no);
 pandecode_indent++;
 
 pandecode_prop("unk0 = 0x%x", fb->unk0);
@@ -775,7 +775,7 @@ pandecode_replay_mfbd_bfr(uint64_t gpu_va, int job_no, bool 
with_render_targets)
 mem = pandecode_find_mapped_gpu_mem_containing(gpu_va);
 const struct bifrost_fb_extra *PANDECODE_PTR_VAR(fbx, mem, 
(mali_ptr) gpu_va);
 
-pandecode_log("struct bifrost_fb_extra fb_extra_%d = {\n", 
job_no);
+pandecode_log("struct bifrost_fb_extra fb_extra_%"PRIx64"_%d = 
{\n", gpu_va, job_no);
 pandecode_indent++;
 
 MEMORY_PROP(fbx, checksum);
@@ -1271,7 +1271,7 @@ pandecode_replay_scratchpad(uintptr_t pscratchpad, int 
job_no, char *suffix)
 if (scratchpad->zero)
 pandecode_msg("XXX scratchpad zero tripped");
 
-pandecode_log("struct bifrost_scratchpad scratchpad_%d%s = {\n", 
job_no, suffix);
+pandecode_log("struct bifrost_scratchpad scratchpad_%"PRIx64"_%d%s = 
{\n", pscratchpad, job_no, suffix);
 pandecode_indent++;
 
 pandecode_prop("flags = 0x%x", scratchpad->flags);
@@ -1336,7 +1336,7 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 struct pandecode_mapped_memory *smem = 
pandecode_find_mapped_gpu_mem_containing(shader_meta_ptr);
 struct mali_shader_meta *PANDECODE_PTR_VAR(s, smem, 
shader_meta_ptr);
 
-pandecode_log("struct mali_shader_meta shader_meta_%d%s = 
{\n", job_no, suffix);
+pandecode_log("struct mali_shader_meta 
shader_meta_%"PRIx64"_%d%s = {\n", shader_meta_ptr, job_no, suffix);
 pandecode_indent++;
 
 /* Save for dumps */
@@ -1624,7 +1624,7 @@ pandecode_replay_vertex_tiler_postfix_pre(const struct 
mali_vertex_tiler_postfix
 if (tmem) {
 struct mali_texture_descriptor 
*PANDECODE_PTR_VAR(t, tmem, *u);
 
-pandecode_log("struct 
mali_texture_descriptor texture_descriptor_%d_%d = {\n", job_no, tex);
+pandecode_log("struct 
mali_texture_descriptor texture_descriptor_%"PRIx64"_%d_%d = {\n", *u, job_no, 
tex);
 pandecode_indent++;
 
 pandecode_prop("width = 
MALI_POSITIVE(%" PRId16 ")", t->width + 1);
@@ -2090,8 +2090,7 @@ pandecode_replay_fragment_job(const struct 
pandecode_mapped_memory *mem,
 }
 
 uintptr_t p 

[Mesa-dev] [PATCH 3/4] panfrost/decode: Wait for a job to finish before dumping

2019-06-25 Thread Tomeu Vizoso
Then we can get some information back about any exception that might
have happened.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pan_drm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 2602acea2988..a69d2aa39551 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -245,9 +245,11 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64 
job_desc, int reqs, st
}
 
 /* Trace the job if we're doing that */
-
-if (pan_debug & PAN_DBG_TRACE)
+if (pan_debug & PAN_DBG_TRACE) {
+/* Wait so we can get errors reported back */
+drmSyncobjWait(screen->fd, &ctx->out_sync, 1, INT64_MAX, 0, 
NULL);
 pandecode_replay_jc(submit.jc, FALSE);
+}
 
return 0;
 }
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/4] panfrost/decode: Decode exception status

2019-06-25 Thread Tomeu Vizoso
Arm's kernel driver mentions how to decode this field, which makes a bit
clearer what had happened.

Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pandecode/decode.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index d468e10140b7..2a21f072639e 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -2171,8 +2171,12 @@ pandecode_replay_jc(mali_ptr jc_gpu_va, bool bifrost)
 if (h->job_descriptor_size)
 pandecode_prop("job_descriptor_size = %d", 
h->job_descriptor_size);
 
-if (h->exception_status)
-pandecode_prop("exception_status = %d", 
h->exception_status);
+if (h->exception_status != 0x1)
+pandecode_prop("exception_status = %x (source ID: 0x%x 
access: 0x%x exception: 0x%x)",
+   h->exception_status,
+   (h->exception_status >> 16) & 0x,
+   (h->exception_status >> 8) & 0x3,
+   h->exception_status  & 0xFF);
 
 if (h->first_incomplete_task)
 pandecode_prop("first_incomplete_task = %d", 
h->first_incomplete_task);
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/4] panfrost/decode: Print AFBC struct when appropriate

2019-06-25 Thread Tomeu Vizoso
Signed-off-by: Tomeu Vizoso 
---
 src/gallium/drivers/panfrost/pandecode/decode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 7f58ad033669..d468e10140b7 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -619,8 +619,7 @@ pandecode_render_target(uint64_t gpu_va, unsigned job_no, 
const struct bifrost_f
 
 pandecode_rt_format(rt->format);
 
-/* TODO: How the actual heck does AFBC enabling work here? */
-if (0) {
+if (rt->format.block == MALI_MFBD_BLOCK_AFBC) {
 pandecode_log(".afbc = {\n");
 pandecode_indent++;
 
-- 
2.20.1

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

Re: [Mesa-dev] about building radeonsi drivers with meson

2019-06-25 Thread cloudwin
It works, thank you!








At 2019-06-24 16:17:41, "Eric Engestrom"  wrote:
>On 2019-06-24 at 08:21, cloudwin  wrote:
>> Hi
>> I used to build radeonsi drivers, like radeonsi_dri.so and 
>> radeonsi_drv_video.so by autogen in old version mesa, but when I switch 
>> to meson which is the only way to build mesa driver now, I find 
>> radeonsi_dri.so can not be generated, I used this to build drivers:
>>  meson -Dgallium-drivers=radeonsi ./build
>> cd ./build
>> ninja
>> 
>> but only ./src/gallium/targets/dri/libgallium_dri.so and 
>> ./src/gallium/targets/va/libgallium_drv_video.so are generated, how can 
>> I get radeonsi_dri.so and radeonsi_drv_video.so with meson?
>> Thanks!
>
>Hi!
>
>You need to install the driver to get the various *_dri.so links.
>
>Run `ninja install` to do so, with `export DESTDIR=/path/to/local/install` 
>first
>if you don't want to overwrite your system install.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev