date:20190305

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

Bug 109860 Summary: vulkan component not working
https://bugs.freedesktop.org/show_bug.cgi?id=109860

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are on the CC list for the bug.
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 109860] vulkan component not working

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

-- 
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 109867] vulkan component not working

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

Samuel Pitoiset  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

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

[Mesa-dev] [Bug 109791] The mesa release config doesn't define NDEBUG when building using meson 0.45.0

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

--- Comment #4 from Malik Riaz  ---
BHai awaz aa rahi hay meri?

-- 
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 109860] vulkan component not working

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

--- Comment #1 from Malik Riaz  ---
BHai awaz aa rahi hay meri?

-- 
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 109867] vulkan component not working

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

Bug ID: 109867
   Summary: vulkan component not working
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mijlal...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org
CC: mesa-dev@lists.freedesktop.org
Depends on: 109860

+++ This bug was initially created as a clone of Bug #109860 +++

this is a clone of a bug from vulkan drivers that is supported for radeon


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109860
[Bug 109860] vulkan component not working
-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109860] vulkan component not working

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

Ijlal Asif  changed:

   What|Removed |Added

 Blocks||109867


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109867
[Bug 109867] vulkan component not working
-- 
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 109860] vulkan component not working

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

Bug ID: 109860
   Summary: vulkan component not working
   Product: Mesa
   Version: 18.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mijlal...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

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

[Mesa-dev] [Bug 109858] Bug report for learning purposes

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

Osama Mumtaz  changed:

   What|Removed |Added

  Alias||musharib.saji...@gmail.com

-- 
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 109858] Bug report for learning purposes

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

Bug ID: 109858
   Summary: Bug report for learning purposes
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: NEW
  Severity: minor
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: osamamumta...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

We are learning reporting of bug in bugzilla.

-- 
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 109791] The mesa release config doesn't define NDEBUG when building using meson 0.45.0

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

Tayyab Ali  changed:

   What|Removed |Added

 CC||tayyabali3...@gmail.com

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

[Mesa-dev] [Bug 44239] spring rts crashes with r300g

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

Salik  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |sujuvi...@techgroup.top
   |org |

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

[Mesa-dev] [Bug 109851] DGC is interlocking with SDIKS

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

Kamal Hasan  changed:

   What|Removed |Added

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

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

[Mesa-dev] [Bug 44239] spring rts crashes with r300g

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

Salik  changed:

   What|Removed |Added

URL||google.com

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

[Mesa-dev] [Bug 109851] DGC is interlocking with SDIKS

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

Malik Riaz  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |sujuvi...@techgroup.top
   |org |
   Keywords||bisected

-- 
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 109851] DGC is interlocking with SDIKS

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

Bug ID: 109851
   Summary: DGC is interlocking with SDIKS
   Product: Mesa
   Version: 10.0
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: EGL
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: linawut...@web-experts.net
QA Contact: mesa-dev@lists.freedesktop.org

ON PRIORITY 
DGC is interlocking with SDIKS.
It might be due to failure of recognition of GGD

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

Re: [Mesa-dev] [PATCH 2/2] gallium/util: add some const qualifiers in u_bitmask.c

2019-03-05 Thread Jose Fonseca


On 05/03/2019 23:56, Brian Paul wrote:

And add/update comments.
---
  src/gallium/auxiliary/util/u_bitmask.c | 16 ++--
  1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_bitmask.c 
b/src/gallium/auxiliary/util/u_bitmask.c
index 397b497..433a09d 100644
--- a/src/gallium/auxiliary/util/u_bitmask.c
+++ b/src/gallium/auxiliary/util/u_bitmask.c
@@ -90,7 +90,7 @@ static inline boolean
  util_bitmask_resize(struct util_bitmask *bm,
  unsigned minimum_index)
  {
-   unsigned minimum_size = minimum_index + 1;
+   const unsigned minimum_size = minimum_index + 1;
 unsigned new_size;
 util_bitmask_word *new_words;
  
@@ -131,7 +131,7 @@ util_bitmask_resize(struct util_bitmask *bm,
  
  
  /**

- * Lazily update the filled.
+ * Check if we can increment the filled counter.
   */
  static inline void
  util_bitmask_filled_set(struct util_bitmask *bm,
@@ -146,6 +146,10 @@ util_bitmask_filled_set(struct util_bitmask *bm,
 }
  }
  
+

+/**
+ * Check if we need to decrement the filled counter.
+ */
  static inline void
  util_bitmask_filled_unset(struct util_bitmask *bm,
unsigned index)
@@ -167,7 +171,7 @@ util_bitmask_add(struct util_bitmask *bm)
  
 assert(bm);
  
-   /* linear search for an empty index */

+   /* linear search for an empty index, starting at filled position */
 word = bm->filled / UTIL_BITMASK_BITS_PER_WORD;
 bit  = bm->filled % UTIL_BITMASK_BITS_PER_WORD;
 mask = 1 << bit;
@@ -249,9 +253,9 @@ boolean
  util_bitmask_get(struct util_bitmask *bm,
   unsigned index)
  {
-   unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
-   unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
-   util_bitmask_word mask = 1 << bit;
+   const unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
+   const unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
+   const util_bitmask_word mask = 1 << bit;
  
 assert(bm);
  



Series is

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

Re: [Mesa-dev] [PATCH 3/3] winsys/svga: use new pb_usage_flags enum type

2019-03-05 Thread Neha Bhende

For the series,

Reviewed-by: Neha Bhende 


Regards,

Neha


From: Brian Paul 
Sent: Tuesday, March 5, 2019 7:48 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Deepak Singh Rawat; Thomas Hellstrom
Subject: [PATCH 3/3] winsys/svga: use new pb_usage_flags enum type

And add a comment that we're implicitly converting PIPE_TRANSFER_
flags to PB_USAGE_ flags in one place.  And statically assert that
the enum values match.
---
 src/gallium/winsys/svga/drm/vmw_buffer.c  | 27 +++
 src/gallium/winsys/svga/drm/vmw_buffer.h  |  1 +
 src/gallium/winsys/svga/drm/vmw_context.c |  4 ++--
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.c 
b/src/gallium/winsys/svga/drm/vmw_buffer.c
index 3ac80c7..91b5b25 100644
--- a/src/gallium/winsys/svga/drm/vmw_buffer.c
+++ b/src/gallium/winsys/svga/drm/vmw_buffer.c
@@ -90,6 +90,11 @@ static inline struct vmw_gmr_bufmgr *
 vmw_gmr_bufmgr(struct pb_manager *mgr)
 {
assert(mgr);
+
+   /* Make sure our extra flags don't collide with pipebuffer's flags */
+   STATIC_ASSERT((VMW_BUFFER_USAGE_SHARED & PB_USAGE_ALL) == 0);
+   STATIC_ASSERT((VMW_BUFFER_USAGE_SYNC & PB_USAGE_ALL) == 0);
+
return (struct vmw_gmr_bufmgr *)mgr;
 }

@@ -109,7 +114,7 @@ vmw_gmr_buffer_destroy(struct pb_buffer *_buf)

 static void *
 vmw_gmr_buffer_map(struct pb_buffer *_buf,
-   unsigned flags,
+   enum pb_usage_flags flags,
void *flush_ctx)
 {
struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
@@ -140,7 +145,7 @@ static void
 vmw_gmr_buffer_unmap(struct pb_buffer *_buf)
 {
struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
-   unsigned flags = buf->map_flags;
+   enum pb_usage_flags flags = buf->map_flags;

if ((_buf->usage & VMW_BUFFER_USAGE_SYNC) &&
!(flags & PB_USAGE_UNSYNCHRONIZED)) {
@@ -164,7 +169,7 @@ vmw_gmr_buffer_get_base_buffer(struct pb_buffer *buf,
 static enum pipe_error
 vmw_gmr_buffer_validate( struct pb_buffer *_buf,
  struct pb_validate *vl,
- unsigned flags )
+ enum pb_usage_flags flags )
 {
/* Always pinned */
return PIPE_OK;
@@ -338,7 +343,7 @@ vmw_svga_winsys_buffer_destroy(struct svga_winsys_screen 
*sws,
 void *
 vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
struct svga_winsys_buffer *buf,
-   unsigned flags)
+   enum pipe_transfer_usage flags)
 {
void *map;

@@ -346,6 +351,20 @@ vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
if (flags & PIPE_TRANSFER_UNSYNCHRONIZED)
   flags &= ~PIPE_TRANSFER_DONTBLOCK;

+   /* NOTE: we're passing PIPE_TRANSFER_x flags instead of
+* PB_USAGE_x flags here.  We should probably fix that.
+*/
+   STATIC_ASSERT((unsigned) PB_USAGE_CPU_READ ==
+ (unsigned) PIPE_TRANSFER_READ);
+   STATIC_ASSERT((unsigned) PB_USAGE_CPU_WRITE ==
+ (unsigned) PIPE_TRANSFER_WRITE);
+   STATIC_ASSERT((unsigned) PB_USAGE_GPU_READ ==
+ (unsigned) PIPE_TRANSFER_MAP_DIRECTLY);
+   STATIC_ASSERT((unsigned) PB_USAGE_DONTBLOCK ==
+ (unsigned) PIPE_TRANSFER_DONTBLOCK);
+   STATIC_ASSERT((unsigned) PB_USAGE_UNSYNCHRONIZED ==
+ (unsigned) PIPE_TRANSFER_UNSYNCHRONIZED);
+
map = pb_map(vmw_pb_buffer(buf), flags, NULL);

 #ifdef DEBUG
diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.h 
b/src/gallium/winsys/svga/drm/vmw_buffer.h
index 6e1151e..8ed56d4 100644
--- a/src/gallium/winsys/svga/drm/vmw_buffer.h
+++ b/src/gallium/winsys/svga/drm/vmw_buffer.h
@@ -33,6 +33,7 @@
 #include "util/u_debug_flush.h"


+/* These extra flags are used wherever the pb_usage_flags enum type is used */
 #define VMW_BUFFER_USAGE_SHARED(1 << 20)
 #define VMW_BUFFER_USAGE_SYNC  (1 << 21)

diff --git a/src/gallium/winsys/svga/drm/vmw_context.c 
b/src/gallium/winsys/svga/drm/vmw_context.c
index c0ee833..59963ff 100644
--- a/src/gallium/winsys/svga/drm/vmw_context.c
+++ b/src/gallium/winsys/svga/drm/vmw_context.c
@@ -161,10 +161,10 @@ vmw_svga_winsys_context(struct svga_winsys_context *swc)
 }


-static inline unsigned
+static inline enum pb_usage_flags
 vmw_translate_to_pb_flags(unsigned flags)
 {
-   unsigned f = 0;
+   enum pb_usage_flags f = 0;
if (flags & SVGA_RELOC_READ)
   f |= PB_USAGE_GPU_READ;

--
1.8.5.6

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

Re: [Mesa-dev] dumb meson questions

2019-03-05 Thread Dave Airlie

On Wed, 6 Mar 2019 at 14:01, Brian Paul  wrote:
>
>
> I guess I don't fully understand a few things about the new meson build.
>
> 1. I'm trying to build the gallium VMware driver with this:
>
> export BUILD_DIR=build-meson-dri
>
> mkdir "${BUILD_DIR}"
>
> meson -Dshared-llvm=false \
>   -Dplatforms=x11,drm \
>   -Dgallium-drivers=svga \
>   -Dvulkan-drivers= \
>   "${BUILD_DIR}"
>
> ninja -C "${BUILD_DIR}"
>
> When it's done, there is no vmwgfx_dri.so driver file. So libGL
> complains that it can't find the svga driver (nor swrast).  I must be
> missing something.

I don't think meson got the install in place stuff carried over, so I
think everyone does --prefix= somewhere
and that should create the vmwgfx_dri.so which will be a link to the
libgallium_dri.so you've found.

> 2. When the build completes I see that there's a libgallium_dri.so file
> that's HUGE:
>
> $ ls -l build-meson-dri/src/gallium/targets/dri/libgallium_dri.so
>
> -rwxr-xr-x 1 brianp users 726507584 Mar  5 20:47
> build-meson-dri/src/gallium/targets/dri/libgallium_dri.so*
>
>
> 726MB seems a bit excessive.  The libvdpau_gallium.so and
> libxatracker.so libraries are also about that size.  What's the story there?

meson build debug by default, I expect you've gotten a bunch of that.

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

[Mesa-dev] dumb meson questions



I guess I don't fully understand a few things about the new meson build.

1. I'm trying to build the gallium VMware driver with this:

export BUILD_DIR=build-meson-dri

mkdir "${BUILD_DIR}"

meson -Dshared-llvm=false \
 -Dplatforms=x11,drm \
 -Dgallium-drivers=svga \
 -Dvulkan-drivers= \
 "${BUILD_DIR}"

ninja -C "${BUILD_DIR}"

When it's done, there is no vmwgfx_dri.so driver file. So libGL 
complains that it can't find the svga driver (nor swrast).  I must be 
missing something.




2. When the build completes I see that there's a libgallium_dri.so file 
that's HUGE:


$ ls -l build-meson-dri/src/gallium/targets/dri/libgallium_dri.so

-rwxr-xr-x 1 brianp users 726507584 Mar  5 20:47 
build-meson-dri/src/gallium/targets/dri/libgallium_dri.so*



726MB seems a bit excessive.  The libvdpau_gallium.so and 
libxatracker.so libraries are also about that size.  What's the story there?


Thanks!

-Brian


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

[Mesa-dev] [PATCH 1/3] pipebuffer: use new pb_usage_flags enum type

Use a new enum type instead of 'unsigned' to make things a bit more
understandable.
---
 src/gallium/auxiliary/pipebuffer/pb_buffer.h   | 34 ++
 .../auxiliary/pipebuffer/pb_buffer_fenced.c|  6 ++--
 .../auxiliary/pipebuffer/pb_buffer_malloc.c|  4 +--
 src/gallium/auxiliary/pipebuffer/pb_bufmgr_cache.c |  4 +--
 src/gallium/auxiliary/pipebuffer/pb_bufmgr_debug.c |  6 ++--
 src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c|  4 +--
 .../auxiliary/pipebuffer/pb_bufmgr_ondemand.c  |  4 +--
 src/gallium/auxiliary/pipebuffer/pb_bufmgr_pool.c  |  5 ++--
 src/gallium/auxiliary/pipebuffer/pb_bufmgr_slab.c  |  6 ++--
 src/gallium/auxiliary/pipebuffer/pb_validate.c |  2 +-
 src/gallium/auxiliary/pipebuffer/pb_validate.h |  2 +-
 11 files changed, 45 insertions(+), 32 deletions(-)

diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer.h 
b/src/gallium/auxiliary/pipebuffer/pb_buffer.h
index 33c2306..11f70ea 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer.h
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer.h
@@ -59,13 +59,22 @@ struct pb_vtbl;
 struct pb_validate;
 struct pipe_fence_handle;
 
+enum pb_usage_flags {
+   PB_USAGE_CPU_READ = (1 << 0),
+   PB_USAGE_CPU_WRITE = (1 << 1),
+   PB_USAGE_GPU_READ = (1 << 2),
+   PB_USAGE_GPU_WRITE = (1 << 3),
+   PB_USAGE_DONTBLOCK = (1 << 9),
+   PB_USAGE_UNSYNCHRONIZED = (1 << 10),
+};
 
-#define PB_USAGE_CPU_READ  (1 << 0)
-#define PB_USAGE_CPU_WRITE (1 << 1)
-#define PB_USAGE_GPU_READ  (1 << 2)
-#define PB_USAGE_GPU_WRITE (1 << 3)
-#define PB_USAGE_UNSYNCHRONIZED (1 << 10)
-#define PB_USAGE_DONTBLOCK (1 << 9)
+/* For error checking elsewhere */
+#define PB_USAGE_ALL (PB_USAGE_CPU_READ | \
+  PB_USAGE_CPU_WRITE | \
+  PB_USAGE_GPU_READ | \
+  PB_USAGE_GPU_WRITE | \
+  PB_USAGE_DONTBLOCK | \
+  PB_USAGE_UNSYNCHRONIZED)
 
 #define PB_USAGE_CPU_READ_WRITE \
( PB_USAGE_CPU_READ | PB_USAGE_CPU_WRITE )
@@ -82,7 +91,7 @@ struct pipe_fence_handle;
 struct pb_desc
 {
unsigned alignment;
-   unsigned usage;
+   enum pb_usage_flags usage;
 };
 
 
@@ -100,7 +109,7 @@ struct pb_buffer
struct pipe_reference  reference;
unsigned   alignment;
pb_sizesize;
-   unsigned   usage;
+   enum pb_usage_flagsusage;
 
/**
 * Pointer to the virtual function table.
@@ -126,13 +135,13 @@ struct pb_vtbl
 * flags is bitmask of PB_USAGE_CPU_READ/WRITE. 
 */
void *(*map)( struct pb_buffer *buf, 
- unsigned flags, void *flush_ctx );
+ enum pb_usage_flags flags, void *flush_ctx );

void (*unmap)( struct pb_buffer *buf );
 
enum pipe_error (*validate)( struct pb_buffer *buf, 
 struct pb_validate *vl,
-unsigned flags );
+enum pb_usage_flags flags );
 
void (*fence)( struct pb_buffer *buf, 
   struct pipe_fence_handle *fence );
@@ -160,7 +169,7 @@ struct pb_vtbl
  */
 static inline void *
 pb_map(struct pb_buffer *buf, 
-   unsigned flags, void *flush_ctx)
+   enum pb_usage_flags flags, void *flush_ctx)
 {
assert(buf);
if (!buf)
@@ -201,7 +210,8 @@ pb_get_base_buffer( struct pb_buffer *buf,
 
 
 static inline enum pipe_error 
-pb_validate(struct pb_buffer *buf, struct pb_validate *vl, unsigned flags)
+pb_validate(struct pb_buffer *buf, struct pb_validate *vl,
+enum pb_usage_flags flags)
 {
assert(buf);
if (!buf)
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c 
b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
index 7421741..53b9ce0 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer_fenced.c
@@ -139,7 +139,7 @@ struct fenced_buffer
 * A bitmask of PB_USAGE_CPU/GPU_READ/WRITE describing the current
 * buffer usage.
 */
-   unsigned flags;
+   enum pb_usage_flags flags;
 
unsigned mapcount;
 
@@ -662,7 +662,7 @@ fenced_buffer_destroy(struct pb_buffer *buf)
 
 static void *
 fenced_buffer_map(struct pb_buffer *buf,
-  unsigned flags, void *flush_ctx)
+  enum pb_usage_flags flags, void *flush_ctx)
 {
struct fenced_buffer *fenced_buf = fenced_buffer(buf);
struct fenced_manager *fenced_mgr = fenced_buf->mgr;
@@ -739,7 +739,7 @@ fenced_buffer_unmap(struct pb_buffer *buf)
 static enum pipe_error
 fenced_buffer_validate(struct pb_buffer *buf,
struct pb_validate *vl,
-   unsigned flags)
+   enum pb_usage_flags flags)
 {
struct fenced_buffer *fenced_buf = fenced_buffer(buf);
struct fenced_manager *fenced_mgr = fenced_buf->mgr;
diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer_malloc.c 
b/src/gallium/auxiliary/pipebuffer/pb_buffer_malloc.c
index ea2f2fa..d83e8e4 100644
---

[Mesa-dev] [PATCH 2/3] pipebuffer: whitespace fixes in pb_buffer.h

---
 src/gallium/auxiliary/pipebuffer/pb_buffer.h | 101 +--
 1 file changed, 49 insertions(+), 52 deletions(-)

diff --git a/src/gallium/auxiliary/pipebuffer/pb_buffer.h 
b/src/gallium/auxiliary/pipebuffer/pb_buffer.h
index 11f70ea..bd60eba 100644
--- a/src/gallium/auxiliary/pipebuffer/pb_buffer.h
+++ b/src/gallium/auxiliary/pipebuffer/pb_buffer.h
@@ -28,15 +28,15 @@
 /**
  * \file
  * Generic code for buffers.
- * 
- * Behind a pipe buffle handle there can be DMA buffers, client (or user) 
- * buffers, regular malloced buffers, etc. This file provides an abstract base 
- * buffer handle that allows the driver to cope with all those kinds of 
buffers 
+ *
+ * Behind a pipe buffle handle there can be DMA buffers, client (or user)
+ * buffers, regular malloced buffers, etc. This file provides an abstract base
+ * buffer handle that allows the driver to cope with all those kinds of buffers
  * in a more flexible way.
- * 
+ *
  * There is no obligation of a winsys driver to use this library. And a pipe
  * driver should be completly agnostic about it.
- * 
+ *
  * \author Jose Fonseca 
  */
 
@@ -76,16 +76,14 @@ enum pb_usage_flags {
   PB_USAGE_DONTBLOCK | \
   PB_USAGE_UNSYNCHRONIZED)
 
-#define PB_USAGE_CPU_READ_WRITE \
-   ( PB_USAGE_CPU_READ | PB_USAGE_CPU_WRITE )
-#define PB_USAGE_GPU_READ_WRITE \
-   ( PB_USAGE_GPU_READ | PB_USAGE_GPU_WRITE )
-#define PB_USAGE_WRITE \
-   ( PB_USAGE_CPU_WRITE | PB_USAGE_GPU_WRITE )
+#define PB_USAGE_CPU_READ_WRITE  (PB_USAGE_CPU_READ | PB_USAGE_CPU_WRITE)
+#define PB_USAGE_GPU_READ_WRITE  (PB_USAGE_GPU_READ | PB_USAGE_GPU_WRITE)
+#define PB_USAGE_WRITE   (PB_USAGE_CPU_WRITE | PB_USAGE_GPU_WRITE)
+
 
 /**
  * Buffer description.
- * 
+ *
  * Used when allocating the buffer.
  */
 struct pb_desc
@@ -104,7 +102,7 @@ typedef uint64_t pb_size;
 /**
  * Base class for all pb_* buffers.
  */
-struct pb_buffer 
+struct pb_buffer
 {
struct pipe_reference  reference;
unsigned   alignment;
@@ -114,8 +112,8 @@ struct pb_buffer
/**
 * Pointer to the virtual function table.
 *
-* Avoid accessing this table directly. Use the inline functions below 
-* instead to avoid mistakes. 
+* Avoid accessing this table directly. Use the inline functions below
+* instead to avoid mistakes.
 */
const struct pb_vtbl *vtbl;
 };
@@ -123,44 +121,43 @@ struct pb_buffer
 
 /**
  * Virtual function table for the buffer storage operations.
- * 
+ *
  * Note that creation is not done through this table.
  */
 struct pb_vtbl
 {
-   void (*destroy)( struct pb_buffer *buf );
+   void (*destroy)(struct pb_buffer *buf);
 
-   /** 
+   /**
 * Map the entire data store of a buffer object into the client's address.
-* flags is bitmask of PB_USAGE_CPU_READ/WRITE. 
+* flags is bitmask of PB_USAGE_CPU_READ/WRITE.
 */
-   void *(*map)( struct pb_buffer *buf, 
- enum pb_usage_flags flags, void *flush_ctx );
-   
-   void (*unmap)( struct pb_buffer *buf );
+   void *(*map)(struct pb_buffer *buf,
+enum pb_usage_flags flags, void *flush_ctx);
+
+   void (*unmap)(struct pb_buffer *buf);
 
-   enum pipe_error (*validate)( struct pb_buffer *buf, 
-struct pb_validate *vl,
-enum pb_usage_flags flags );
+   enum pipe_error (*validate)(struct pb_buffer *buf,
+   struct pb_validate *vl,
+   enum pb_usage_flags flags);
 
-   void (*fence)( struct pb_buffer *buf, 
-  struct pipe_fence_handle *fence );
+   void (*fence)(struct pb_buffer *buf,
+ struct pipe_fence_handle *fence);
 
/**
 * Get the base buffer and the offset.
-* 
+*
 * A buffer can be subdivided in smaller buffers. This method should return
 * the underlaying buffer, and the relative offset.
-* 
-* Buffers without an underlaying base buffer should return themselves, 
with 
+*
+* Buffers without an underlaying base buffer should return themselves, with
 * a zero offset.
-* 
+*
 * Note that this will increase the reference count of the base buffer.
 */
-   void (*get_base_buffer)( struct pb_buffer *buf,
-struct pb_buffer **base_buf,
-pb_size *offset );
-   
+   void (*get_base_buffer)(struct pb_buffer *buf,
+   struct pb_buffer **base_buf,
+   pb_size *offset);
 };
 
 
@@ -168,8 +165,7 @@ struct pb_vtbl
 /* Accessor functions for pb->vtbl:
  */
 static inline void *
-pb_map(struct pb_buffer *buf, 
-   enum pb_usage_flags flags, void *flush_ctx)
+pb_map(struct pb_buffer *buf, enum pb_usage_flags flags, void *flush_ctx)
 {
assert(buf);
if (!buf)
@@ -179,7 +175,7 @@ pb_map(struct pb_buffer *buf,
 }
 
 
-static inline void 
+static inline void
 pb_unmap(struct pb_buffer *buf)
 {

[Mesa-dev] [PATCH 3/3] winsys/svga: use new pb_usage_flags enum type

And add a comment that we're implicitly converting PIPE_TRANSFER_
flags to PB_USAGE_ flags in one place.  And statically assert that
the enum values match.
---
 src/gallium/winsys/svga/drm/vmw_buffer.c  | 27 +++
 src/gallium/winsys/svga/drm/vmw_buffer.h  |  1 +
 src/gallium/winsys/svga/drm/vmw_context.c |  4 ++--
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.c 
b/src/gallium/winsys/svga/drm/vmw_buffer.c
index 3ac80c7..91b5b25 100644
--- a/src/gallium/winsys/svga/drm/vmw_buffer.c
+++ b/src/gallium/winsys/svga/drm/vmw_buffer.c
@@ -90,6 +90,11 @@ static inline struct vmw_gmr_bufmgr *
 vmw_gmr_bufmgr(struct pb_manager *mgr)
 {
assert(mgr);
+
+   /* Make sure our extra flags don't collide with pipebuffer's flags */
+   STATIC_ASSERT((VMW_BUFFER_USAGE_SHARED & PB_USAGE_ALL) == 0);
+   STATIC_ASSERT((VMW_BUFFER_USAGE_SYNC & PB_USAGE_ALL) == 0);
+
return (struct vmw_gmr_bufmgr *)mgr;
 }
 
@@ -109,7 +114,7 @@ vmw_gmr_buffer_destroy(struct pb_buffer *_buf)
 
 static void *
 vmw_gmr_buffer_map(struct pb_buffer *_buf,
-   unsigned flags,
+   enum pb_usage_flags flags,
void *flush_ctx)
 {
struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
@@ -140,7 +145,7 @@ static void
 vmw_gmr_buffer_unmap(struct pb_buffer *_buf)
 {
struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
-   unsigned flags = buf->map_flags;
+   enum pb_usage_flags flags = buf->map_flags;
 
if ((_buf->usage & VMW_BUFFER_USAGE_SYNC) &&
!(flags & PB_USAGE_UNSYNCHRONIZED)) {
@@ -164,7 +169,7 @@ vmw_gmr_buffer_get_base_buffer(struct pb_buffer *buf,
 static enum pipe_error
 vmw_gmr_buffer_validate( struct pb_buffer *_buf, 
  struct pb_validate *vl,
- unsigned flags )
+ enum pb_usage_flags flags )
 {
/* Always pinned */
return PIPE_OK;
@@ -338,7 +343,7 @@ vmw_svga_winsys_buffer_destroy(struct svga_winsys_screen 
*sws,
 void *
 vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
struct svga_winsys_buffer *buf,
-   unsigned flags)
+   enum pipe_transfer_usage flags)
 {
void *map;
 
@@ -346,6 +351,20 @@ vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
if (flags & PIPE_TRANSFER_UNSYNCHRONIZED)
   flags &= ~PIPE_TRANSFER_DONTBLOCK;
 
+   /* NOTE: we're passing PIPE_TRANSFER_x flags instead of
+* PB_USAGE_x flags here.  We should probably fix that.
+*/
+   STATIC_ASSERT((unsigned) PB_USAGE_CPU_READ ==
+ (unsigned) PIPE_TRANSFER_READ);
+   STATIC_ASSERT((unsigned) PB_USAGE_CPU_WRITE ==
+ (unsigned) PIPE_TRANSFER_WRITE);
+   STATIC_ASSERT((unsigned) PB_USAGE_GPU_READ ==
+ (unsigned) PIPE_TRANSFER_MAP_DIRECTLY);
+   STATIC_ASSERT((unsigned) PB_USAGE_DONTBLOCK ==
+ (unsigned) PIPE_TRANSFER_DONTBLOCK);
+   STATIC_ASSERT((unsigned) PB_USAGE_UNSYNCHRONIZED ==
+ (unsigned) PIPE_TRANSFER_UNSYNCHRONIZED);
+
map = pb_map(vmw_pb_buffer(buf), flags, NULL);
 
 #ifdef DEBUG
diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.h 
b/src/gallium/winsys/svga/drm/vmw_buffer.h
index 6e1151e..8ed56d4 100644
--- a/src/gallium/winsys/svga/drm/vmw_buffer.h
+++ b/src/gallium/winsys/svga/drm/vmw_buffer.h
@@ -33,6 +33,7 @@
 #include "util/u_debug_flush.h"
 
 
+/* These extra flags are used wherever the pb_usage_flags enum type is used */
 #define VMW_BUFFER_USAGE_SHARED(1 << 20)
 #define VMW_BUFFER_USAGE_SYNC  (1 << 21)
 
diff --git a/src/gallium/winsys/svga/drm/vmw_context.c 
b/src/gallium/winsys/svga/drm/vmw_context.c
index c0ee833..59963ff 100644
--- a/src/gallium/winsys/svga/drm/vmw_context.c
+++ b/src/gallium/winsys/svga/drm/vmw_context.c
@@ -161,10 +161,10 @@ vmw_svga_winsys_context(struct svga_winsys_context *swc)
 }
 
 
-static inline unsigned
+static inline enum pb_usage_flags
 vmw_translate_to_pb_flags(unsigned flags)
 {
-   unsigned f = 0;
+   enum pb_usage_flags f = 0;
if (flags & SVGA_RELOC_READ)
   f |= PB_USAGE_GPU_READ;
 
-- 
1.8.5.6

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

Re: [Mesa-dev] [virglrenderer-devel] virglrenderer on gles, format conversion

2019-03-05 Thread Dave Airlie

On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund
 wrote:
>
> When we try to do a vrend transfer from a renderable texture, we end up
> using glReadPixels to read the data. However, OpenGL ES has
> restrictions on what formats are allowed to be used for glReadPixels.
> In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
> supported (for OpenGL ES 2.0; for OpenGL ES 3.x there's some other
> variants for integer and float textures - it seems we can rely on the
> destination format having at least as much range/precision as the
> source format).
>
> But vrend transfers expect no format conversion at all, they want to
> read the data verbatim.
>
> I thought the obvious choice was to modify virglrenderer to convert
> back from RGBA to the source format. After a typing out a lot of code,
> I realized that even though we have util_format_translate in
> u_format.h, the actual implementation was deleted in d01f462[1].
>
> OK, so that leaves me with a couple of choices:
>
> 1) Restore the format conversion code in virglrenderer.
> 2) Use some 3rd party pixel-format conversion code instead.
> 3) Do format-conversion back to the desired format in Mesa.
>
> I gave 1) a go by reverting the removal, but this conflicted pretty
> badly due to the 3 years of development that has happened since. It
> might be possible to continue this effort, but I also don't really like
> the idea of crash-prone format converion code in virglrenderer. You
> know, for security reasons; virglrenderer runs inside the virtual
> machine manager, which makes it pretty high priviledge code. If we
> don't do 1), I have sent a MR[2] that removes the rest of the format
> conversion, so others won't be led astray in the future.

It's likely we should just pull that in anyways, and start from a
clean base if you decide that is the best path.

I agree I don't think this could should be in the host layer if we can avoid it.

>
> I have relatively low expectations that we'd find a good fit for 3) as
> we have a very specific and *big* set of formats we need to support.
> Format conversion across APIs is often a big pain-point in my
> experience.
>
> As for 3), it's not quite as easily said as done, because we currently
> only have protocol commands for reading a format verbatim. So I guess
> we'd have to add a new format, and inform the Mesa driver that we're
> limited in what formats we support. With this approach, we don't need
> conversion code both in mesa *and* in virglrenderer, and we don't have
> to actively maintain a fork of the pixel-format code separately.
>
> I'm currently leaning towards 3) for now, but I would like input from
> the list, as I feel this is a rather important directional choice.

I think we'd need to define a list of formats we can readback, and
then somehow convince the guest mesa to do the conversions for us, it
should have all the necessary code already shouldn't it?

> I'm also intererested in if someone has some alternative approaches.
> Perhaps we could use some lower-level API (GBM? Some sort of PBuffer or
> EGLimage?) to create a lockable, linear surface of the same format,
> blit to that and read the result from there? Does something like this
> exist? If so, can we depend on this?

I'm not sure there's a nice low level generic way to do it, it's
likely we'd have to do something else for nvidia driver anyways.

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

[Mesa-dev] [PATCH] panfrost: Fix bug/cruft calling tgsi_to_nir

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_assemble.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_assemble.c 
b/src/gallium/drivers/panfrost/pan_assemble.c
index f3b339d8184..7e2f24edd71 100644
--- a/src/gallium/drivers/panfrost/pan_assemble.c
+++ b/src/gallium/drivers/panfrost/pan_assemble.c
@@ -32,8 +32,6 @@
 #include "midgard/midgard_compile.h"
 #include "util/u_dynarray.h"
 
-#include "tgsi/tgsi_dump.h"
-
 void
 panfrost_shader_compile(struct panfrost_context *ctx, struct mali_shader_meta 
*meta, const char *src, int type, struct panfrost_shader_state *state)
 {
@@ -47,8 +45,7 @@ panfrost_shader_compile(struct panfrost_context *ctx, struct 
mali_shader_meta *m
 s = nir_shader_clone(NULL, cso->ir.nir);
 } else {
 assert (cso->type == PIPE_SHADER_IR_TGSI);
-//tgsi_dump(cso->tokens, 0);
-s = tgsi_to_nir(cso->tokens, >base.screen);
+s = tgsi_to_nir(cso->tokens, ctx->base.screen);
 }
 
 s->info.stage = type == JOB_TYPE_VERTEX ? MESA_SHADER_VERTEX : 
MESA_SHADER_FRAGMENT;
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 2/2] gallium/util: add some const qualifiers in u_bitmask.c

2019-03-05 Thread Timothy Arceri


Series:

Reviewed-by: Timothy Arceri 

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

[Mesa-dev] [PATCH 1/3] svga: keep a list of contexts for the screen

This will allow us to query whether a context is valid.

In addition to keeping a list of contexts, we need to give each
context we create a unique ID which is never re-used.  The screen
also contains a bitmask to track which IDs are valid.  We need the
ID since a context pointer could be recycled by the memory allocator.
---
 src/gallium/drivers/svga/svga_context.c |  7 +++
 src/gallium/drivers/svga/svga_context.h |  6 +++
 src/gallium/drivers/svga/svga_screen.c  | 86 +
 src/gallium/drivers/svga/svga_screen.h  | 23 +
 4 files changed, 122 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 7b3e9e8..1284d2f 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -57,6 +57,7 @@ DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple, 
"SVGA_FORCE_HW_LINE_STIPPLE",
 static void
 svga_destroy(struct pipe_context *pipe)
 {
+   struct svga_screen *svgascreen = svga_screen(pipe->screen);
struct svga_context *svga = svga_context(pipe);
unsigned shader, i;
 
@@ -97,6 +98,9 @@ svga_destroy(struct pipe_context *pipe)
 
svga->swc->destroy(svga->swc);
 
+   /* remove this context from the screen's list */
+   svga_screen_remove_context(svgascreen, svga);
+
util_bitmask_destroy(svga->blend_object_id_bm);
util_bitmask_destroy(svga->ds_object_id_bm);
util_bitmask_destroy(svga->input_element_object_id_bm);
@@ -300,6 +304,9 @@ svga_context_create(struct pipe_screen *screen, void *priv, 
unsigned flags)
svga->pred.query_id = SVGA3D_INVALID_ID;
svga->disable_rasterizer = FALSE;
 
+   /* add this context to the screen's list */
+   svga_screen_save_context(svgascreen, svga);
+
goto done;
 
 cleanup:
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index fc63ec3..2ec6b3f 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -441,6 +441,12 @@ struct svga_context
struct u_upload_mgr *const0_upload;
struct u_upload_mgr *tex_upload;
 
+   /** used for svga_screen's list of contexts */
+   struct list_head context_node;
+
+   /** A per-context ID which is never reused */
+   unsigned context_id;
+
struct {
   boolean no_swtnl;
   boolean force_swtnl;
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 6cb5a14..6f4e8fc 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -24,6 +24,7 @@
  **/
 
 #include "git_sha1.h" /* For MESA_GIT_SHA1 */
+#include "util/u_bitmask.h"
 #include "util/u_format.h"
 #include "util/u_memory.h"
 #include "util/u_inlines.h"
@@ -1129,6 +1130,11 @@ svga_screen_create(struct svga_winsys_screen *sws)
   debug_printf("svga: msaa samples mask: 0x%x\n", svgascreen->ms_samples);
}
 
+   LIST_INITHEAD(>contexts);
+   mtx_init(>contexts_mutex, mtx_plain);
+
+   svgascreen->context_id_bm = util_bitmask_create();
+
(void) mtx_init(>tex_mutex, mtx_plain);
(void) mtx_init(>swc_mutex, mtx_recursive);
 
@@ -1144,6 +1150,86 @@ error1:
 }
 
 
+/*
+ * Add the given context to the screen's list.
+ * This should be done once when a context is created.
+ */
+void
+svga_screen_save_context(struct svga_screen *svgascreen,
+ struct svga_context *svga)
+{
+   /* This context should not already be in the list */
+   assert(!svga_screen_context_exists(svgascreen, svga));
+
+   /* the context ID should not be set yet */
+   assert(svga->context_id == 0);
+
+   mtx_lock(>contexts_mutex);
+
+   /* Assign a unique ID to the svga context.  The ID is never reused */
+   svga->context_id = svgascreen->context_counter++;
+
+   util_bitmask_set(svgascreen->context_id_bm, svga->context_id);
+
+   LIST_ADDTAIL(>context_node, >contexts);
+
+   mtx_unlock(>contexts_mutex);
+}
+
+
+/*
+ * Remove the given context from the screen's list.
+ * This should be done once when a context is destroyed;
+ */
+void
+svga_screen_remove_context(struct svga_screen *svgascreen,
+   struct svga_context *svga)
+{
+   /* This context should be in the list */
+   assert(svga_screen_context_exists(svgascreen, svga));
+
+   mtx_lock(>contexts_mutex);
+
+   /* remove the ID from the bitmask */
+   util_bitmask_clear(svgascreen->context_id_bm, svga->context_id);
+
+   LIST_DEL(>context_node);
+
+   mtx_unlock(>contexts_mutex);
+}
+
+
+/*
+ * Return true if the context exists in the screen's list and its ID
+ * is valid, false otherwise.
+ */
+boolean
+svga_screen_context_exists(struct svga_screen *svgascreen,
+   const struct svga_context *svga)
+{
+   struct svga_context *ctx;
+   boolean found = FALSE;
+
+   mtx_lock(>contexts_mutex);
+
+   LIST_FOR_EACH_ENTRY(ctx, >contexts, context_node) {
+  if (ctx == svga) {
+ /* Also check

[Mesa-dev] [PATCH 2/3] svga: only free sampler views from the context which created it

Some applications, like google-chrome, cause the state tracker to
destroy sampler/resource views from a context other than the one
which was used to create it.  Previously, we just leaked the view.

Now, when we're in this situation we declare the view a zombie and
add it to a list of zombie views associated with the context which
created the context.

VMware bug 2274734.
---
 src/gallium/drivers/svga/svga_context.c  | 67 
 src/gallium/drivers/svga/svga_context.h  | 21 +
 src/gallium/drivers/svga/svga_pipe_sampler.c | 45 +++
 3 files changed, 115 insertions(+), 18 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 1284d2f..6b5f023 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -54,6 +54,63 @@ DEBUG_GET_ONCE_BOOL_OPTION(no_line_width, 
"SVGA_NO_LINE_WIDTH", FALSE);
 DEBUG_GET_ONCE_BOOL_OPTION(force_hw_line_stipple, 
"SVGA_FORCE_HW_LINE_STIPPLE", FALSE);
 
 
+/*
+ * In some circumstances (such as running google-chrome) the state
+ * tracker may try to delete a resource view from a context different
+ * than when it was created.  We don't want to do that.
+ * In that situation, svga_sampler_view_destroy() calls this function
+ * to save the view for later deletion.  The context here is expected
+ * to be the context which created the view.
+ */
+void
+svga_save_zombie_view(struct svga_context *svga,
+  struct pipe_sampler_view *view)
+{
+   struct svga_pipe_sampler_view *sv = svga_pipe_sampler_view(view);
+   struct svga_zombie_view_list *entry;
+
+   assert(view->context == >pipe);
+
+   entry = MALLOC_STRUCT(svga_zombie_view_list);
+   if (!entry)
+  return;
+
+   entry->view = sv;
+
+   /* We need a mutex since this function may be called from one thread
+* while free_zombie_resource_views() is called from another.
+*/
+   mtx_lock(>zombie_view_mutex);
+   LIST_ADDTAIL(>node, >zombie_views);
+   mtx_unlock(>zombie_view_mutex);
+}
+
+
+/*
+ * This function is called periodically (currently from svga_flush)
+ * to free any zombie resource views attached to the context.
+ */
+static void
+free_zombie_resource_views(struct svga_context *svga)
+{
+   struct pipe_context *pipe = >pipe;
+   struct svga_zombie_view_list *entry, *next;
+
+   mtx_lock(>zombie_view_mutex);
+
+   LIST_FOR_EACH_ENTRY_SAFE(entry, next, >zombie_views, node) {
+  LIST_DEL(>node);  // remove this entry from the list
+  assert(entry->view->base.context == pipe);
+  pipe->sampler_view_destroy(pipe, >view->base);
+  FREE(entry);
+   }
+
+   assert(LIST_IS_EMPTY(>zombie_views));
+
+   mtx_unlock(>zombie_view_mutex);
+}
+
+
 static void
 svga_destroy(struct pipe_context *pipe)
 {
@@ -61,6 +118,9 @@ svga_destroy(struct pipe_context *pipe)
struct svga_context *svga = svga_context(pipe);
unsigned shader, i;
 
+   free_zombie_resource_views(svga);
+   mtx_destroy(>zombie_view_mutex);
+
/* free any alternate rasterizer states used for point sprite */
for (i = 0; i < ARRAY_SIZE(svga->rasterizer_no_cull); i++) {
   if (svga->rasterizer_no_cull[i]) {
@@ -141,6 +201,8 @@ svga_context_create(struct pipe_screen *screen, void *priv, 
unsigned flags)
   goto done;
 
LIST_INITHEAD(>dirty_buffers);
+   LIST_INITHEAD(>zombie_views);
+   mtx_init(>zombie_view_mutex, mtx_plain);
 
svga->pipe.screen = screen;
svga->pipe.priv = priv;
@@ -414,6 +476,11 @@ svga_context_flush(struct svga_context *svga,
 
svgascreen->sws->fence_reference(svgascreen->sws, , NULL);
 
+   /* We want to call this function periodically.  This seems to
+* be a reasonable place to do so.
+*/
+   free_zombie_resource_views(svga);
+
SVGA_STATS_TIME_POP(svga_sws(svga));
 }
 
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index 2ec6b3f..8c86018 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -231,6 +231,18 @@ svga_pipe_sampler_view(struct pipe_sampler_view *v)
 }
 
 
+/*
+ * For keeping a list of zombie sampler views.  A zombie sampler view is
+ * one that is supposed to be deleted, but the view's parent context is not
+ * the context passed to pipe_context::sampler_view_destroy().
+ */
+struct svga_zombie_view_list
+{
+   struct svga_pipe_sampler_view *view;
+   struct list_head node;  // there's a linked list of these structs
+};
+
+
 struct svga_velems_state {
unsigned count;
struct pipe_vertex_element velem[PIPE_MAX_ATTRIBS];
@@ -542,6 +554,10 @@ struct svga_context
/** List of buffers with queued transfers */
struct list_head dirty_buffers;
 
+   /** List of zombie resource views */
+   struct list_head zombie_views;
+   mtx_t zombie_view_mutex;
+
/** performance / info queries for HUD */
struct {
   uint64_t num_draw_calls;  /**< SVGA_QUERY_DRAW_CALLS */
@@ -689,6 +705,11 @@

[Mesa-dev] [PATCH 3/3] svga: only free shader variants from the context which created it

Since OpenGL shaders may be shared among contexts, we can wind up
with variants of a shader created with different contexts.
When we go to destroy a shader variant, we want to free it with the
same context that it was created with.

This patch implements solves that problem.

The Redway3D Watch demo exhibits this problem.
---
 src/gallium/drivers/svga/svga_context.c | 65 -
 src/gallium/drivers/svga/svga_context.h | 20 ++
 src/gallium/drivers/svga/svga_shader.c  | 16 +++-
 src/gallium/drivers/svga/svga_shader.h  |  3 ++
 4 files changed, 102 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/svga/svga_context.c 
b/src/gallium/drivers/svga/svga_context.c
index 6b5f023..5857140 100644
--- a/src/gallium/drivers/svga/svga_context.c
+++ b/src/gallium/drivers/svga/svga_context.c
@@ -38,6 +38,7 @@
 #include "svga_resource_texture.h"
 #include "svga_resource_buffer.h"
 #include "svga_resource.h"
+#include "svga_shader.h"
 #include "svga_winsys.h"
 #include "svga_swtnl.h"
 #include "svga_draw.h"
@@ -111,6 +112,61 @@ free_zombie_resource_views(struct svga_context *svga)
 }
 
 
+/*
+ * Since OpenGL shaders may be shared among contexts, we can wind up
+ * with variants of a shader created with different contexts.
+ * When we go to destroy a shader variant, we want to free it with the
+ * same context that it was created with.  In svga_destroy_shader_variant()
+ * if the calling context doesn't match the variant's context, we call
+ * this function to add the variant to this context's list.
+ */
+void
+svga_save_zombie_shader_variant(struct svga_context *svga,
+struct svga_shader_variant *variant)
+{
+   struct svga_zombie_shader_variant_list *entry;
+
+   assert(variant->context == svga);
+
+   entry = MALLOC_STRUCT(svga_zombie_shader_variant_list);
+   if (!entry)
+  return;
+
+   entry->variant = variant;
+
+   /* We need a mutex since this function may be called from one thread
+* while free_zombie_shader_variant() is called from another.
+*/
+   mtx_lock(>zombie_shader_variant_mutex);
+   LIST_ADDTAIL(>node, >zombie_shader_variants);
+   mtx_unlock(>zombie_shader_variant_mutex);
+}
+
+
+/*
+ * This function is called periodically (currently from svga_flush)
+ * to free any zombie shader variants attached to the context.
+ */
+static void
+free_zombie_shader_variants(struct svga_context *svga)
+{
+   struct svga_zombie_shader_variant_list *entry, *next;
+
+   mtx_lock(>zombie_shader_variant_mutex);
+
+   LIST_FOR_EACH_ENTRY_SAFE(entry, next, >zombie_shader_variants, node) {
+  LIST_DEL(>node);  // remove this entry from the list
+  assert(entry->variant->context == svga);
+  svga_destroy_shader_variant(svga, entry->variant);
+  FREE(entry);
+   }
+
+   assert(LIST_IS_EMPTY(>zombie_shader_variants));
+
+   mtx_unlock(>zombie_shader_variant_mutex);
+}
+
+
 static void
 svga_destroy(struct pipe_context *pipe)
 {
@@ -121,6 +177,9 @@ svga_destroy(struct pipe_context *pipe)
free_zombie_resource_views(svga);
mtx_destroy(>zombie_view_mutex);
 
+   free_zombie_shader_variants(svga);
+   mtx_destroy(>zombie_shader_variant_mutex);
+
/* free any alternate rasterizer states used for point sprite */
for (i = 0; i < ARRAY_SIZE(svga->rasterizer_no_cull); i++) {
   if (svga->rasterizer_no_cull[i]) {
@@ -204,6 +263,9 @@ svga_context_create(struct pipe_screen *screen, void *priv, 
unsigned flags)
LIST_INITHEAD(>zombie_views);
mtx_init(>zombie_view_mutex, mtx_plain);
 
+   LIST_INITHEAD(>zombie_shader_variants);
+   mtx_init(>zombie_shader_variant_mutex, mtx_plain);
+
svga->pipe.screen = screen;
svga->pipe.priv = priv;
svga->pipe.destroy = svga_destroy;
@@ -476,10 +538,11 @@ svga_context_flush(struct svga_context *svga,
 
svgascreen->sws->fence_reference(svgascreen->sws, , NULL);
 
-   /* We want to call this function periodically.  This seems to
+   /* We want to call these functions periodically.  This seems to
 * be a reasonable place to do so.
 */
free_zombie_resource_views(svga);
+   free_zombie_shader_variants(svga);
 
SVGA_STATS_TIME_POP(svga_sws(svga));
 }
diff --git a/src/gallium/drivers/svga/svga_context.h 
b/src/gallium/drivers/svga/svga_context.h
index 8c86018..99032c4 100644
--- a/src/gallium/drivers/svga/svga_context.h
+++ b/src/gallium/drivers/svga/svga_context.h
@@ -243,6 +243,18 @@ struct svga_zombie_view_list
 };
 
 
+/*
+ * For keeping a list of zombie shader variants.  A zombie shader variant is
+ * one that is supposed to be deleted, but the variant's parent context does
+ * not match the context passed to svga_destroy_shader_variant().
+ */
+struct svga_zombie_shader_variant_list
+{
+   struct svga_shader_variant *variant;
+   struct list_head node;  // there's a linked list of these structs
+};
+
+
 struct svga_velems_state {
unsigned count;
struct pipe_vertex_element velem[PIPE_MAX_ATTRIBS];
@@ -558,6 +570,10 @@ struct

[Mesa-dev] [PATCH 2/2] gallium/util: add some const qualifiers in u_bitmask.c

And add/update comments.
---
 src/gallium/auxiliary/util/u_bitmask.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_bitmask.c 
b/src/gallium/auxiliary/util/u_bitmask.c
index 397b497..433a09d 100644
--- a/src/gallium/auxiliary/util/u_bitmask.c
+++ b/src/gallium/auxiliary/util/u_bitmask.c
@@ -90,7 +90,7 @@ static inline boolean
 util_bitmask_resize(struct util_bitmask *bm,
 unsigned minimum_index)
 {
-   unsigned minimum_size = minimum_index + 1;
+   const unsigned minimum_size = minimum_index + 1;
unsigned new_size;
util_bitmask_word *new_words;
 
@@ -131,7 +131,7 @@ util_bitmask_resize(struct util_bitmask *bm,
 
 
 /**
- * Lazily update the filled.
+ * Check if we can increment the filled counter.
  */
 static inline void
 util_bitmask_filled_set(struct util_bitmask *bm,
@@ -146,6 +146,10 @@ util_bitmask_filled_set(struct util_bitmask *bm,
}
 }
 
+
+/**
+ * Check if we need to decrement the filled counter.
+ */
 static inline void
 util_bitmask_filled_unset(struct util_bitmask *bm,
   unsigned index)
@@ -167,7 +171,7 @@ util_bitmask_add(struct util_bitmask *bm)
 
assert(bm);
 
-   /* linear search for an empty index */
+   /* linear search for an empty index, starting at filled position */
word = bm->filled / UTIL_BITMASK_BITS_PER_WORD;
bit  = bm->filled % UTIL_BITMASK_BITS_PER_WORD;
mask = 1 << bit;
@@ -249,9 +253,9 @@ boolean
 util_bitmask_get(struct util_bitmask *bm,
  unsigned index)
 {
-   unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
-   unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
-   util_bitmask_word mask = 1 << bit;
+   const unsigned word = index / UTIL_BITMASK_BITS_PER_WORD;
+   const unsigned bit  = index % UTIL_BITMASK_BITS_PER_WORD;
+   const util_bitmask_word mask = 1 << bit;
 
assert(bm);
 
-- 
1.8.5.6

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

[Mesa-dev] [PATCH 1/2] gallium/util: whitespace cleanups in u_bitmask.[ch]

---
 src/gallium/auxiliary/util/u_bitmask.c | 129 +
 src/gallium/auxiliary/util/u_bitmask.h |  40 +-
 2 files changed, 85 insertions(+), 84 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_bitmask.c 
b/src/gallium/auxiliary/util/u_bitmask.c
index b15dfd8..397b497 100644
--- a/src/gallium/auxiliary/util/u_bitmask.c
+++ b/src/gallium/auxiliary/util/u_bitmask.c
@@ -1,8 +1,8 @@
 /**
- * 
+ *
  * Copyright 2009 VMware, Inc.
  * All Rights Reserved.
- * 
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the
  * "Software"), to deal in the Software without restriction, including
@@ -10,11 +10,11 @@
  * distribute, sub license, and/or sell copies of the Software, and to
  * permit persons to whom the Software is furnished to do so, subject to
  * the following conditions:
- * 
+ *
  * The above copyright notice and this permission notice (including the
  * next paragraph) shall be included in all copies or substantial portions
  * of the Software.
- * 
+ *
  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
  * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
@@ -22,13 +22,13 @@
  * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
  * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
  * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- * 
+ *
  **/
 
 /**
  * @file
  * Generic bitmask implementation.
- *  
+ *
  * @author Jose Fonseca 
  */
 
@@ -40,7 +40,7 @@
 #include "util/u_bitmask.h"
 
 
-typedef uint32_t util_bitmask_word;  
+typedef uint32_t util_bitmask_word;
 
 
 #define UTIL_BITMASK_INITIAL_WORDS 16
@@ -51,10 +51,10 @@ typedef uint32_t util_bitmask_word;
 struct util_bitmask
 {
util_bitmask_word *words;
-   
+
/** Number of bits we can currently hold */
unsigned size;
-   
+
/** Number of consecutive bits set at the start of the bitmask */
unsigned filled;
 };
@@ -64,26 +64,27 @@ struct util_bitmask *
 util_bitmask_create(void)
 {
struct util_bitmask *bm;
-   
+
bm = MALLOC_STRUCT(util_bitmask);
if (!bm)
   return NULL;
-   
-   bm->words = (util_bitmask_word *)CALLOC(UTIL_BITMASK_INITIAL_WORDS, 
sizeof(util_bitmask_word));
-   if(!bm->words) {
+
+   bm->words = (util_bitmask_word *)
+  CALLOC(UTIL_BITMASK_INITIAL_WORDS, sizeof(util_bitmask_word));
+   if (!bm->words) {
   FREE(bm);
   return NULL;
}
-   
+
bm->size = UTIL_BITMASK_INITIAL_WORDS * UTIL_BITMASK_BITS_PER_WORD;
bm->filled = 0;
-   
+
return bm;
 }
 
 
 /**
- * Resize the bitmask if necessary 
+ * Resize the bitmask if necessary
  */
 static inline boolean
 util_bitmask_resize(struct util_bitmask *bm,
@@ -94,36 +95,37 @@ util_bitmask_resize(struct util_bitmask *bm,
util_bitmask_word *new_words;
 
/* Check integer overflow */
-   if(!minimum_size)
+   if (!minimum_size)
   return FALSE;
-  
-   if(bm->size >= minimum_size)
+
+   if (bm->size >= minimum_size)
   return TRUE;
 
assert(bm->size % UTIL_BITMASK_BITS_PER_WORD == 0);
new_size = bm->size;
-   while(new_size < minimum_size) {
+   while (new_size < minimum_size) {
   new_size *= 2;
   /* Check integer overflow */
-  if(new_size < bm->size)
+  if (new_size < bm->size)
  return FALSE;
}
assert(new_size);
assert(new_size % UTIL_BITMASK_BITS_PER_WORD == 0);
-   
-   new_words = (util_bitmask_word *)REALLOC((void *)bm->words,
-bm->size / 
UTIL_BITMASK_BITS_PER_BYTE,
-new_size / 
UTIL_BITMASK_BITS_PER_BYTE);
+
+   new_words = (util_bitmask_word *)
+  REALLOC((void *)bm->words,
+  bm->size / UTIL_BITMASK_BITS_PER_BYTE,
+  new_size / UTIL_BITMASK_BITS_PER_BYTE);
if (!new_words)
   return FALSE;
-   
-   memset(new_words + bm->size/UTIL_BITMASK_BITS_PER_WORD, 
-  0, 
+
+   memset(new_words + bm->size/UTIL_BITMASK_BITS_PER_WORD,
+  0,
   (new_size - bm->size)/UTIL_BITMASK_BITS_PER_BYTE);
-   
+
bm->size = new_size;
bm->words = new_words;
-   
+
return TRUE;
 }
 
@@ -137,8 +139,8 @@ util_bitmask_filled_set(struct util_bitmask *bm,
 {
assert(bm->filled <= bm->size);
assert(index < bm->size);
-   
-   if(index == bm->filled) {
+
+   if (index == bm->filled) {
   ++bm->filled;
   assert(bm->filled <= bm->size);
}
@@ -150,8 +152,8 @@ util_bitmask_filled_unset(struct util_bitmask *bm,
 {
assert(bm->filled <= bm->size);
assert(index < bm->size);
-   
-   if(index < bm->filled)
+
+   if (index < bm->filled)
   bm->filled = index;
 }
 
@@ -162,16 +164,16 @@

[Mesa-dev] [PATCH] nir/builder: Cast array indices in build_deref_follower

2019-03-05 Thread Jason Ekstrand

There's no guarantee when build_deref_follower is called that the two
derefs have the same bit size destination.  Insert a cast on the array
index in case we have differing bit sizes.  While we're here, insert
some asserts in build_deref_array and build_deref_ptr_as_array.  The
validator will catch violations here but they're easier to debug if we
catch them while building.

Cc: Karol Herbst 
---
 src/compiler/nir/nir_builder.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index 253ca5941cb..b9f27831b36 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -803,6 +803,8 @@ nir_build_deref_array(nir_builder *build, nir_deref_instr 
*parent,
   glsl_type_is_matrix(parent->type) ||
   glsl_type_is_vector(parent->type));
 
+   assert(index->bit_size == parent->dest.ssa.bit_size);
+
nir_deref_instr *deref =
   nir_deref_instr_create(build->shader, nir_deref_type_array);
 
@@ -828,6 +830,8 @@ nir_build_deref_ptr_as_array(nir_builder *build, 
nir_deref_instr *parent,
   parent->deref_type == nir_deref_type_ptr_as_array ||
   parent->deref_type == nir_deref_type_cast);
 
+   assert(index->bit_size == parent->dest.ssa.bit_size);
+
nir_deref_instr *deref =
   nir_deref_instr_create(build->shader, nir_deref_type_ptr_as_array);
 
@@ -944,7 +948,9 @@ nir_build_deref_follower(nir_builder *b, nir_deref_instr 
*parent,
 
   if (leader->deref_type == nir_deref_type_array) {
  assert(leader->arr.index.is_ssa);
- return nir_build_deref_array(b, parent, leader->arr.index.ssa);
+ nir_ssa_def *index = nir_i2i(b, leader->arr.index.ssa,
+ parent->dest.ssa.bit_size);
+ return nir_build_deref_array(b, parent, index);
   } else {
  return nir_build_deref_array_wildcard(b, parent);
   }
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] i965: Perform manual preemption checks between commands

2019-03-05 Thread Rafael Antognolli

On Tue, Mar 05, 2019 at 07:50:24PM +, Chris Wilson wrote:
> Quoting Rafael Antognolli (2019-03-05 19:33:03)
> > On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> > > Not all commands support being preempted as they execute, and for those
> > > make sure we at least check for being preempted before we start so as to
> > > try and minimise the latency of whomever is more important than
> > > ourselves.
> > > 
> > > Cc: Jari Tahvanainen ,
> > > Cc: Rafael Antognolli 
> > > Cc: Kenneth Graunke 
> > > ---
> > > Always double check before you hit send.
> > > ---
> > >  src/mesa/drivers/dri/i965/brw_defines.h | 1 +
> > >  src/mesa/drivers/dri/i965/brw_draw.c| 7 +++
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> > > b/src/mesa/drivers/dri/i965/brw_defines.h
> > > index 2729a54e144..ef71c556cca 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > > @@ -1420,6 +1420,7 @@ enum brw_pixel_shader_coverage_mask_mode {
> > >  
> > >  #define MI_NOOP  (CMD_MI | 0)
> > >  
> > > +#define MI_ARB_CHECK (CMD_MI | 0x5 << 23)
> > >  #define MI_BATCH_BUFFER_END  (CMD_MI | 0xA << 23)
> > >  
> > >  #define MI_FLUSH (CMD_MI | (4 << 23))
> > > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> > > b/src/mesa/drivers/dri/i965/brw_draw.c
> > > index d07349419cc..a04e334ffc4 100644
> > > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > > @@ -196,6 +196,13 @@ brw_emit_prim(struct brw_context *brw,
> > > if (verts_per_instance == 0 && !prim->is_indirect && !xfb_obj)
> > >return;
> > >  
> > > +   /* If this object is not itself preemptible, check before we begin. */
> > > +   if (!brw->object_preemption) {
> > > +  BEGIN_BATCH(1);
> > > +  OUT_BATCH(MI_ARB_CHECK);
> > > +  ADVANCE_BATCH();
> > > +   }
> > > +
> > 
> > "The command streamer will preempt in the case arbitration is enabled,
> > there is a pending execution list and this command is currently being
> > parsed."
> > 
> > If there is a pending execution list, shouldn't we have been preempted
> > already, since mid-batch preemption is supposed to be enabled?
> 
> No, it still only occurs on certain instructions, not every instruction
> boundary.

Sounds good. In that case,

Reviewed-by: Rafael Antognolli 

> -Chris
> ___
> 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] i965: Perform manual preemption checks between commands

2019-03-05 Thread Chris Wilson

Quoting Rafael Antognolli (2019-03-05 19:33:03)
> On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> > Not all commands support being preempted as they execute, and for those
> > make sure we at least check for being preempted before we start so as to
> > try and minimise the latency of whomever is more important than
> > ourselves.
> > 
> > Cc: Jari Tahvanainen ,
> > Cc: Rafael Antognolli 
> > Cc: Kenneth Graunke 
> > ---
> > Always double check before you hit send.
> > ---
> >  src/mesa/drivers/dri/i965/brw_defines.h | 1 +
> >  src/mesa/drivers/dri/i965/brw_draw.c| 7 +++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> > b/src/mesa/drivers/dri/i965/brw_defines.h
> > index 2729a54e144..ef71c556cca 100644
> > --- a/src/mesa/drivers/dri/i965/brw_defines.h
> > +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> > @@ -1420,6 +1420,7 @@ enum brw_pixel_shader_coverage_mask_mode {
> >  
> >  #define MI_NOOP  (CMD_MI | 0)
> >  
> > +#define MI_ARB_CHECK (CMD_MI | 0x5 << 23)
> >  #define MI_BATCH_BUFFER_END  (CMD_MI | 0xA << 23)
> >  
> >  #define MI_FLUSH (CMD_MI | (4 << 23))
> > diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> > b/src/mesa/drivers/dri/i965/brw_draw.c
> > index d07349419cc..a04e334ffc4 100644
> > --- a/src/mesa/drivers/dri/i965/brw_draw.c
> > +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> > @@ -196,6 +196,13 @@ brw_emit_prim(struct brw_context *brw,
> > if (verts_per_instance == 0 && !prim->is_indirect && !xfb_obj)
> >return;
> >  
> > +   /* If this object is not itself preemptible, check before we begin. */
> > +   if (!brw->object_preemption) {
> > +  BEGIN_BATCH(1);
> > +  OUT_BATCH(MI_ARB_CHECK);
> > +  ADVANCE_BATCH();
> > +   }
> > +
> 
> "The command streamer will preempt in the case arbitration is enabled,
> there is a pending execution list and this command is currently being
> parsed."
> 
> If there is a pending execution list, shouldn't we have been preempted
> already, since mid-batch preemption is supposed to be enabled?

No, it still only occurs on certain instructions, not every instruction
boundary.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Perform manual preemption checks between commands

2019-03-05 Thread Rafael Antognolli

On Tue, Mar 05, 2019 at 09:40:20AM +, Chris Wilson wrote:
> Not all commands support being preempted as they execute, and for those
> make sure we at least check for being preempted before we start so as to
> try and minimise the latency of whomever is more important than
> ourselves.
> 
> Cc: Jari Tahvanainen ,
> Cc: Rafael Antognolli 
> Cc: Kenneth Graunke 
> ---
> Always double check before you hit send.
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h | 1 +
>  src/mesa/drivers/dri/i965/brw_draw.c| 7 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 2729a54e144..ef71c556cca 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -1420,6 +1420,7 @@ enum brw_pixel_shader_coverage_mask_mode {
>  
>  #define MI_NOOP  (CMD_MI | 0)
>  
> +#define MI_ARB_CHECK (CMD_MI | 0x5 << 23)
>  #define MI_BATCH_BUFFER_END  (CMD_MI | 0xA << 23)
>  
>  #define MI_FLUSH (CMD_MI | (4 << 23))
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index d07349419cc..a04e334ffc4 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -196,6 +196,13 @@ brw_emit_prim(struct brw_context *brw,
> if (verts_per_instance == 0 && !prim->is_indirect && !xfb_obj)
>return;
>  
> +   /* If this object is not itself preemptible, check before we begin. */
> +   if (!brw->object_preemption) {
> +  BEGIN_BATCH(1);
> +  OUT_BATCH(MI_ARB_CHECK);
> +  ADVANCE_BATCH();
> +   }
> +

"The command streamer will preempt in the case arbitration is enabled,
there is a pending execution list and this command is currently being
parsed."

If there is a pending execution list, shouldn't we have been preempted
already, since mid-batch preemption is supposed to be enabled?

> /* If we're set to always flush, do it before and after the primitive 
> emit.
>  * We want to catch both missed flushes that hurt instruction/state cache
>  * and missed flushes of the render cache as it heads to other parts of
> -- 
> 2.20.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

2019-03-05 Thread Eric Anholt

Alyssa Rosenzweig  writes:

>> Alyssa: do you see any problem if we change to submit only one atom per
>> ioctl?
>
> I don't think so; aesthetically I don't like the extra kernel traffic,
> but that's not a real concern, and it sounds like that's the correct
> approach anyway.
>
> A big reason we submit together on non-DRM is so we can get the kernel
> to deal with dependency tracking; if we have proper syncobjs/fences,
> that doesn't matter I don't think.
>
>> Guess syncobj refs are akin to GEM handles and fences to dmabuf buffers from
>> the userspace POV?
>
> *tries to figure out what the difference between GEM handles and dmabuf
> buffers*

GEM handles: per-DRM-fd small integer references to your BOs.
Non-refcounted (GEM_CLOSE frees that number).

dmabuf: fd reference to a BO.  May be imported/exported to/from a GEM
handle using the prime interfaces.  Watch out for how it'll hand you
back the same handle for a reimport of a buffer you already have a GEM
handle to!  The fd can be passed over unix domain sockets, which is how
we move references to buffers between processes.

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 8/8] panfrost: Add backend targeting the DRM driver

2019-03-05 Thread Eric Anholt

Kristian Høgsberg  writes:

> On Mon, Mar 4, 2019 at 6:29 PM Dave Airlie  wrote:
>>
>> On Tue, 5 Mar 2019 at 12:20, Kristian Høgsberg  wrote:
>> >
>> > On Mon, Mar 4, 2019 at 6:11 PM Alyssa Rosenzweig  
>> > wrote:
>> > >
>> > > > Why aren't we using regular dma-buf fences here? The submit ioctl
>> > > > should be able to take a number of in fences to wait on and return an
>> > > > out fence if requested.
>> > >
>> > > Ah-ha, that sounds like the "proper" approach for mainline. Much of this
>> > > was (incorrectly) inherited from the Arm driver. Thank you for the
>> > > pointer.
>> >
>> > I'm not sure - I mean, the submit should take in/out fences, but the
>> > atom mechanism here sounds more like it's for declaring the
>> > dependencies between multiple batches in a renderpass/frame to allow
>> > the kernel to shcedule them? The sync fd may be a little to heavy
>> > handed for that, and if you want to express that kind of dependency to
>> > allow the kernel to reschedule, maybe we need both?
>>
>> You should more likely be using syncobjects, not fences.
>>
>> You can convert syncobjs to fences, but fences consume an fd which you
>> only really want if inter-device.
>
> Fence fd's are also required for passing through protocol for explicit
> synchronization.

Yeah, but you can get a syncobj from a sync_file fence fd and export a
syncobj's fence to a sync_file.  I've been doing that successfully in
v3d and vc4 for our dependencies in the driver so you don't need
multiple fence types as input/output from the submit ioctl.


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

[Mesa-dev] [PATCH] radv: fix color conversions for normalized uint/sint formats

The hardware actually rounds before conversion. This now matches
what values are used when performing fast clears vs slow clears.

This fixes a rendering issue with Far Cry 3&4. This also fixes
a bunch of CTS tests that use a 8-bit UNORM format (only when
the 512*512 image size hint is manually disabled).

Cc: 18.3 19.0 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_formats.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 0a3ff9ebbd9..9c61e769ebd 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -990,10 +990,22 @@ bool radv_format_pack_clear_color(VkFormat format,
assert(channel->size == 8);
 
v = 
util_format_linear_float_to_srgb_8unorm(value->float32[c]);
-   } else if (channel->type == VK_FORMAT_TYPE_UNSIGNED) {
-   v = MAX2(MIN2(value->float32[c], 1.0f), 0.0f) * 
((1ULL << channel->size) - 1);
-   } else  {
-   v = MAX2(MIN2(value->float32[c], 1.0f), -1.0f) 
* ((1ULL << (channel->size - 1)) - 1);
+   } else {
+   float f = MIN2(value->float32[c], 1.0f);
+
+   if (channel->type == VK_FORMAT_TYPE_UNSIGNED) {
+   f = MAX2(f, 0.0f) * ((1ULL << 
channel->size) - 1);
+   } else {
+   f = MAX2(f, -1.0f) * ((1ULL << 
(channel->size - 1)) - 1);
+   }
+
+   /* The hardware rounds before conversion. */
+   if (f > 0)
+   f += 0.5f;
+   else
+   f -= 0.5f;
+
+   v = (uint64_t)f;
}
} else if (channel->type == VK_FORMAT_TYPE_FLOAT) {
if (channel->size == 32) {
-- 
2.21.0

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

[Mesa-dev] [PATCH] radv: fix binding transform feedback buffers

The mask should be accumulated if two calls are used for
binding two buffers at different indexes. Otherwise, the
driver only accounts for the last one.

Noticed while glancing at this code.

Cc: 18.3 19.0 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 5b66930d137..b8d8583c1b0 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4987,7 +4987,7 @@ void radv_CmdBindTransformFeedbackBuffersEXT(
enabled_mask |= 1 << idx;
}
 
-   cmd_buffer->state.streamout.enabled_mask = enabled_mask;
+   cmd_buffer->state.streamout.enabled_mask |= enabled_mask;
 
cmd_buffer->state.dirty |= RADV_CMD_DIRTY_STREAMOUT_BUFFER;
 }
-- 
2.21.0

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

[Mesa-dev] [PATCH v2] ac/nir: implement emit_{imul, umul}_2x32_64 opcodes

v2: - remove dead variables

Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 34 +
 1 file changed, 34 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index af7a95137c2..15c23d2084c 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -423,6 +423,30 @@ static LLVMValueRef emit_imul_high(struct ac_llvm_context 
*ctx,
return result;
 }
 
+static LLVMValueRef emit_umul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_umul_high(ctx, src0, src1);
+
+   LLVMValueRef res = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, res, ctx->i64, "");
+}
+
+static LLVMValueRef emit_imul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_imul_high(ctx, src0, src1);
+
+   LLVMValueRef res = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, res, ctx->i64, "");
+}
+
 static LLVMValueRef emit_bitfield_extract(struct ac_llvm_context *ctx,
  bool is_signed,
  const LLVMValueRef srcs[3])
@@ -977,6 +1001,16 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
src[1] = ac_to_integer(>ac, src[1]);
result = emit_imul_high(>ac, src[0], src[1]);
break;
+   case nir_op_umul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_umul_2x32_64(>ac, src[0], src[1]);
+   break;
+   case nir_op_imul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_imul_2x32_64(>ac, src[0], src[1]);
+   break;
case nir_op_pack_half_2x16:
result = emit_pack_half_2x16(>ac, src[0]);
break;
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] ac/nir: implement emit_{imul, umul}_2x32_64 opcodes



On 3/5/19 2:01 PM, Bas Nieuwenhuizen wrote:

On Tue, Mar 5, 2019 at 10:30 AM Samuel Pitoiset
 wrote:

Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 36 +
  1 file changed, 36 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index af7a95137c2..74ae690e845 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -423,6 +423,32 @@ static LLVMValueRef emit_imul_high(struct ac_llvm_context 
*ctx,
 return result;
  }

+static LLVMValueRef emit_umul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_umul_high(ctx, src0, src1);
+
+   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);

This tmp assignment is dead?

I will send a v2 with that removed.

+   tmp = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
+}
+
+static LLVMValueRef emit_imul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_imul_high(ctx, src0, src1);

If we do this lowering, why not just set options->lower_mul_2x32_64?

does it result in better code from LLVM if we convert both args to 64
bit and do a 64-bit mul?

No LLVM differences.



+
+   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);

This tmp assignment is dead?

+   tmp = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
+}
+
  static LLVMValueRef emit_bitfield_extract(struct ac_llvm_context *ctx,
   bool is_signed,
   const LLVMValueRef srcs[3])
@@ -977,6 +1003,16 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
 src[1] = ac_to_integer(>ac, src[1]);
 result = emit_imul_high(>ac, src[0], src[1]);
 break;
+   case nir_op_umul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_umul_2x32_64(>ac, src[0], src[1]);
+   break;
+   case nir_op_imul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_imul_2x32_64(>ac, src[0], src[1]);
+   break;
 case nir_op_pack_half_2x16:
 result = emit_pack_half_2x16(>ac, src[0]);
 break;
--
2.21.0

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

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

[Mesa-dev] [Bug 109443] Build failure with MSVC when using Scons >= 3.0.2

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

--- Comment #11 from William Deegan  ---
I've pushed out an alpha package for you to verify your issue is now resolved.

https://github.com/SCons/scons/releases/tag/3.0.5a2

Also available at:
pip install --index-url https://test.pypi.org/simple/ scons==3.0.5.a2

Please let us know if this works!

-- 
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 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

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

--- Comment #52 from asimiklit  ---
Created attachment 143535
  --> https://bugs.freedesktop.org/attachment.cgi?id=143535=edit
draft of a solution

Currently I am trying to find another way to fix this issue
to avoid removal of an optimization because this optimization
isn't only for minimization of the binding points usage but
it also helps to minimize usage of some other stuff,
however I'm not sure if this is even possible.

But all Intel CI tests are passed:
https://mesa-ci.01.org/global_logic/builds/101/group/63a9f0ea7bb98050796b649e85481845

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

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

> Alyssa: do you see any problem if we change to submit only one atom per
> ioctl?

I don't think so; aesthetically I don't like the extra kernel traffic,
but that's not a real concern, and it sounds like that's the correct
approach anyway.

A big reason we submit together on non-DRM is so we can get the kernel
to deal with dependency tracking; if we have proper syncobjs/fences,
that doesn't matter I don't think.

> Guess syncobj refs are akin to GEM handles and fences to dmabuf buffers from
> the userspace POV?

*tries to figure out what the difference between GEM handles and dmabuf
buffers*

As in, syncobjs are within the driver, whereas fences can be shared
across processes/parts of the chip and imported/exported?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] panfrost: Add DRM backend

> One is that with kbase I don't see any noticeable pauses during the very
> first scene in glmark2.

...That sounds like a good thing? :)

> Another is that with the DRM driver I don't see the wallpaper in GNOME Shell.

GNOME Shell is very broken under Panfrost; that's not a kernel-space
regression (but a userspace one).

Does glmark's -brefract and -bshadow demo work? I'm also curious about
performance, though honestly I wouldn't be surprised if we end up with a
slight advantage there when all is said and done..
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/8] panfrost: Fix BO import and export

> With non-DRM this code doesn't execute (at least on the workloads I tested
> with) because we don't support GEM handles for !scanout.

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

[Mesa-dev] virglrenderer on gles, format conversion

2019-03-05 Thread Erik Faye-Lund

When we try to do a vrend transfer from a renderable texture, we end up
using glReadPixels to read the data. However, OpenGL ES has
restrictions on what formats are allowed to be used for glReadPixels.
In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
supported (for OpenGL ES 2.0; for OpenGL ES 3.x there's some other
variants for integer and float textures - it seems we can rely on the
destination format having at least as much range/precision as the
source format).

But vrend transfers expect no format conversion at all, they want to
read the data verbatim.

I thought the obvious choice was to modify virglrenderer to convert
back from RGBA to the source format. After a typing out a lot of code,
I realized that even though we have util_format_translate in
u_format.h, the actual implementation was deleted in d01f462[1].

OK, so that leaves me with a couple of choices:

1) Restore the format conversion code in virglrenderer.
2) Use some 3rd party pixel-format conversion code instead.
3) Do format-conversion back to the desired format in Mesa.

I gave 1) a go by reverting the removal, but this conflicted pretty
badly due to the 3 years of development that has happened since. It
might be possible to continue this effort, but I also don't really like
the idea of crash-prone format converion code in virglrenderer. You
know, for security reasons; virglrenderer runs inside the virtual
machine manager, which makes it pretty high priviledge code. If we
don't do 1), I have sent a MR[2] that removes the rest of the format
conversion, so others won't be led astray in the future.

I have relatively low expectations that we'd find a good fit for 3) as
we have a very specific and *big* set of formats we need to support.
Format conversion across APIs is often a big pain-point in my
experience.

As for 3), it's not quite as easily said as done, because we currently
only have protocol commands for reading a format verbatim. So I guess
we'd have to add a new format, and inform the Mesa driver that we're
limited in what formats we support. With this approach, we don't need
conversion code both in mesa *and* in virglrenderer, and we don't have
to actively maintain a fork of the pixel-format code separately.

I'm currently leaning towards 3) for now, but I would like input from
the list, as I feel this is a rather important directional choice.

I'm also intererested in if someone has some alternative approaches.
Perhaps we could use some lower-level API (GBM? Some sort of PBuffer or
EGLimage?) to create a lockable, linear surface of the same format,
blit to that and read the result from there? Does something like this
exist? If so, can we depend on this?

[1]:
https://gitlab.freedesktop.org/virgl/virglrenderer/commit/d01f462c53f079e79b10617798abc56582e5124f
[2]:
https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/174

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

Re: [Mesa-dev] [PATCH 8/8] panfrost: Add backend targeting the DRM driver

2019-03-05 Thread Rob Herring

On Mon, Mar 4, 2019 at 6:43 PM Alyssa Rosenzweig  wrote:
>
> Wooo!!!
>
> Seeing this patch in my inbox has been some of the best news all day!
>
> Without further ado, my (solicited?) comments:
>
> > +/* Copyright 2018, Linaro, Ltd., Rob Herring  */
>
> Please triple check upstream that this license is okay; the other files
> in include/drm-uapi are BSDish.

There's a mixture of MIT and 'GPL-2.0 WITH Linux-syscall-note'. These
are the ones with GPL:

include/uapi/drm/armada_drm.h:/* SPDX-License-Identifier: GPL-2.0 WITH
Linux-syscall-note */
include/uapi/drm/etnaviv_drm.h:/* SPDX-License-Identifier: GPL-2.0
WITH Linux-syscall-note */
include/uapi/drm/exynos_drm.h:/* SPDX-License-Identifier: GPL-2.0+
WITH Linux-syscall-note */
include/uapi/drm/i810_drm.h:/* SPDX-License-Identifier: GPL-2.0 WITH
Linux-syscall-note */
include/uapi/drm/omap_drm.h:/* SPDX-License-Identifier: GPL-2.0 WITH
Linux-syscall-note */

I don't think it matters, but imagine all corporate entities would prefer MIT.

>
> > +/* timeouts are specified in clock-monotonic absolute times (to simplify
> > + * restarting interrupted ioctls).  The following struct is logically the
> > + * same as 'struct timespec' but 32/64b ABI safe.
> > + */
> > +struct drm_panfrost_timespec {
> > + __s64 tv_sec;  /* seconds */
> > + __s64 tv_nsec; /* nanoseconds */
> > +};
>
> What's this for -- is there not a shared struct for this if it's
> necessary? (I'm assuming this was copied from etna..?)

I couldn't find any common struct.

>
> > + __u32 flags;  /* in, mask of ETNA_BO_x */
>
> As Rob said, s/ETNA/PAN/g
>
> > + struct drm_panfrost_timespec timeout;   /* in */
>
> (Presumably we just want a timeout in one of nanoseconds / milliseconds
> / second, not the full timespec... 64-bit time gives a pretty wide range
> even for high-precision timeouts, which I don't know that we need. Also,
> it's signed for some reason...?)

Yes, but I was keeping it aligned with etnaviv. Changing to just u64
ns should be fine as I think rollover in 500 years is acceptable.

Arnd confirmed with me that a plain u64 nanoseconds is preferred.

> > + struct drm_panfrost_gem_submit_atom_dep deps[2];
>
> I'm concerned about hardcoding deps to 2 here. I know the Arm driver
> does it, but I'm super uncomfortable by them doing it too. Keep in mind,
> when they have complex dependencies they insert dummy "dependency-only"
> jobs into the graph, though I concede I haven't seen this yet.
>
> I'm not at all sure what the right number is, especially since the new
> kernel interface seems to support waiting on BOs? Or am I
> misinterpreting this?
>
> Regardless, this will start to matter when we implement support for more
> complex FBOs (where various FBOs samples from various other FBOs), which
> I think can have arbitrarily complicated dependency graphs. So
> hardcoding to [2] is inappropriate if we want to use deps for waiting on
> FBOs. On the other hand, if we use a kernel-side BO wait or fences or
> something to resolve dependencies, do we even need two deps, or just
> one?
>
> > + // TODO cache allocations
> > + // TODO properly handle errors
> > + // TODO take into account extra_flags
>
> Not a blocker at all for merge, but these should be taken care of before
> we drop support for the non-DRM stuff (since at least the
> lack of GROWABLE support represents a regression compared to the Arm
> driver).

Need to research how other drivers deal with this. Presumably other
drivers should need some heap as well? I found one case that has a
specific ioctl call to do allocate it (don't remember which one
offhand).

>
> > + // TODO map and unmap on demand?
>
> I don't know if this matters too much...? Usually if we're allocating a
> slab, that means we want it mapped immediately, unless we set the
> INVISIBLE flag which means we odn't want it mapped at all.

Map to what? The GPU or CPU?

> Maybe we'll have fancier scenarios in the future, but at the moment I
> think we can safely cross off at least the first half of the TODO.
>
> As you know I'm not a believer in unmapping/freeing resources ever, so I
> don't get an opinion there ;)
>
> > + gem_info.handle = gem_new.handle;
> > + ret = drmIoctl(drm->fd, DRM_IOCTL_PANFROST_GEM_INFO, _info);
> > + if (ret) {
> > +fprintf(stderr, "DRM_IOCTL_PANFROST_GEM_INFO failed: 
> > %d\n", ret);
> > + assert(0);
> > + }
>
> Maybe a question for Rob, but why isn't this info passed along with the
> allocate in the first place? I guess the extra roundtrip to the kernel
> isn't a huge deal, but it seems a little odd...?

It is. GEM_INFO should only be needed when you import a dmabuf.

>
> > +static uint8_t
> > +allocate_atom()
> > +{
> > + /* Use to allocate atom numbers for jobs. We probably want to 
> > overhaul this in kernel space at some point. */
> > + static uint8_t atom_counter = 0;
> > +
> > +atom_counter++;
> > +
> > +/*

Re: [Mesa-dev] [PATCH] radv: allocate enough space in cmdbuf when starting a subpass



On 3/5/19 2:34 PM, Bas Nieuwenhuizen wrote:

On Tue, Mar 5, 2019 at 10:42 AM Samuel Pitoiset
 wrote:

This fixes some CTS crashes with:
dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*

Ideally, we should check cmd_buffer->cs->max_dw because there is
likely enough space (the internal clear draws allocate space), but
keep that way for consistency.

Isn't this what check_space does?


I meant, at the end of that function.


Reviewed-by: Bas Nieuwenhuizen 

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ad0b934ddfc..3e652018499 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3446,7 +3446,7 @@ radv_cmd_buffer_begin_subpass(struct radv_cmd_buffer 
*cmd_buffer,
 struct radv_subpass *subpass = >pass->subpasses[subpass_id];

 MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws,
-  cmd_buffer->cs, 
2048);
+  cmd_buffer->cs, 
4096);

 radv_subpass_barrier(cmd_buffer, >start_barrier);

--
2.21.0

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

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

Re: [Mesa-dev] [PATCH] radv: allocate enough space in cmdbuf when starting a subpass

2019-03-05 Thread Bas Nieuwenhuizen

On Tue, Mar 5, 2019 at 10:42 AM Samuel Pitoiset
 wrote:
>
> This fixes some CTS crashes with:
> dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*
>
> Ideally, we should check cmd_buffer->cs->max_dw because there is
> likely enough space (the internal clear draws allocate space), but
> keep that way for consistency.

Isn't this what check_space does?

Reviewed-by: Bas Nieuwenhuizen 
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index ad0b934ddfc..3e652018499 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -3446,7 +3446,7 @@ radv_cmd_buffer_begin_subpass(struct radv_cmd_buffer 
> *cmd_buffer,
> struct radv_subpass *subpass = >pass->subpasses[subpass_id];
>
> MAYBE_UNUSED unsigned cdw_max = 
> radeon_check_space(cmd_buffer->device->ws,
> -  cmd_buffer->cs, 
> 2048);
> +  cmd_buffer->cs, 
> 4096);
>
> radv_subpass_barrier(cmd_buffer, >start_barrier);
>
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] ac/nir: implement emit_{imul, umul}_2x32_64 opcodes

2019-03-05 Thread Bas Nieuwenhuizen

On Tue, Mar 5, 2019 at 10:30 AM Samuel Pitoiset
 wrote:
>
> Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 36 +
>  1 file changed, 36 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index af7a95137c2..74ae690e845 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -423,6 +423,32 @@ static LLVMValueRef emit_imul_high(struct 
> ac_llvm_context *ctx,
> return result;
>  }
>
> +static LLVMValueRef emit_umul_2x32_64(struct ac_llvm_context *ctx,
> + LLVMValueRef src0, LLVMValueRef src1)
> +{
> +   LLVMValueRef result[2];
> +
> +   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
> +   result[1] = emit_umul_high(ctx, src0, src1);
> +
> +   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);

This tmp assignment is dead?
> +   tmp = ac_build_gather_values(ctx, result, 2);
> +   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
> +}
> +
> +static LLVMValueRef emit_imul_2x32_64(struct ac_llvm_context *ctx,
> + LLVMValueRef src0, LLVMValueRef src1)
> +{
> +   LLVMValueRef result[2];
> +
> +   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
> +   result[1] = emit_imul_high(ctx, src0, src1);

If we do this lowering, why not just set options->lower_mul_2x32_64?

does it result in better code from LLVM if we convert both args to 64
bit and do a 64-bit mul?

> +
> +   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);

This tmp assignment is dead?
> +   tmp = ac_build_gather_values(ctx, result, 2);
> +   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
> +}
> +
>  static LLVMValueRef emit_bitfield_extract(struct ac_llvm_context *ctx,
>   bool is_signed,
>   const LLVMValueRef srcs[3])
> @@ -977,6 +1003,16 @@ static void visit_alu(struct ac_nir_context *ctx, const 
> nir_alu_instr *instr)
> src[1] = ac_to_integer(>ac, src[1]);
> result = emit_imul_high(>ac, src[0], src[1]);
> break;
> +   case nir_op_umul_2x32_64:
> +   src[0] = ac_to_integer(>ac, src[0]);
> +   src[1] = ac_to_integer(>ac, src[1]);
> +   result = emit_umul_2x32_64(>ac, src[0], src[1]);
> +   break;
> +   case nir_op_imul_2x32_64:
> +   src[0] = ac_to_integer(>ac, src[0]);
> +   src[1] = ac_to_integer(>ac, src[1]);
> +   result = emit_imul_2x32_64(>ac, src[0], src[1]);
> +   break;
> case nir_op_pack_half_2x16:
> result = emit_pack_half_2x16(>ac, src[0]);
> break;
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] radv: properly align the fence and EOP bug VA on GFX9

2019-03-05 Thread Bas Nieuwenhuizen

Reviewed-by: Bas Nieuwenhuizen 

On Mon, Mar 4, 2019 at 2:22 PM Samuel Pitoiset
 wrote:
>
> If alignement is 0, offets returned by
> radv_cmd_buffer_upload_alloc() are always 0. These two
> virtual addresses were pointing at the same location.
>
> v2: - add an asertion that checks if alignment is power of two
>
> Cc: 18.3 19.0 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index ad0b934ddfc..7cc7b3b9195 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -338,14 +338,15 @@ radv_reset_cmd_buffer(struct radv_cmd_buffer 
> *cmd_buffer)
> unsigned fence_offset, eop_bug_offset;
> void *fence_ptr;
>
> -   radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 0, _offset,
> +   radv_cmd_buffer_upload_alloc(cmd_buffer, 8, 8, _offset,
>  _ptr);
> +
> cmd_buffer->gfx9_fence_va =
> radv_buffer_get_va(cmd_buffer->upload.upload_bo);
> cmd_buffer->gfx9_fence_va += fence_offset;
>
> /* Allocate a buffer for the EOP bug on GFX9. */
> -   radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 0,
> +   radv_cmd_buffer_upload_alloc(cmd_buffer, 16 * num_db, 8,
>  _bug_offset, _ptr);
> cmd_buffer->gfx9_eop_bug_va =
> radv_buffer_get_va(cmd_buffer->upload.upload_bo);
> @@ -416,6 +417,8 @@ radv_cmd_buffer_upload_alloc(struct radv_cmd_buffer 
> *cmd_buffer,
>  unsigned *out_offset,
>  void **ptr)
>  {
> +   assert(util_is_power_of_two_nonzero(alignment));
> +
> uint64_t offset = align(cmd_buffer->upload.offset, alignment);
> if (offset + size > cmd_buffer->upload.size) {
> if (!radv_cmd_buffer_resize_upload_buf(cmd_buffer, size))
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 4/5] main: avoid 'may be used uninitialized' warnings

2019-03-05 Thread andrey simiklit

Hello,

Could somebody take a look at this old patch?

Thanks,
Andrii.

On Tue, Nov 13, 2018 at 6:41 PM Eric Engestrom 
wrote:

> On Tuesday, 2018-11-13 14:19:31 +0200, asimiklit.w...@gmail.com wrote:
> > From: Andrii Simiklit 
> >
> > 1. main/texcompress_etc.c:1314:12:
> > warning: ‘*((void *)+2)’ may be used uninitialized in this
> function
> > 2. main/texcompress_etc.c:1354:12:
> > warning: ‘*((void *)+2)’ may be used uninitialized in this
> function
> > 3. main/texcompress_etc.c:1293:12:
> > warning: ‘dst’ may be used uninitialized in this function
> > 4. main/texcompress_etc.c:1335:12:
> > warning: ‘dst’ may be used uninitialized in this function
> > 5. main/texcompress_etc.c:1460:12:
> > warning: ‘*((void *)+1)’ may be used uninitialized in this
> function
> >
> > v2: Fixed by adding the unreachable case to the etc2_rgb8_fetch_texel
> >( Eric Engestrom  )
> > Changes for warning 'pixerrorcolorbest' were removed.
> >
> > Signed-off-by: Andrii Simiklit 
>
> This is the right way of fixing this code-wise, but I'm not 100% sure we
> can actually guarantee this logic-wise, so I'll let someone else review
> (and push) this patch.
>
> Acked-by: Eric Engestrom 
>
> > ---
> >  src/mesa/main/texcompress_etc.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/mesa/main/texcompress_etc.c
> b/src/mesa/main/texcompress_etc.c
> > index b39ab33d36..f1da4d0f11 100644
> > --- a/src/mesa/main/texcompress_etc.c
> > +++ b/src/mesa/main/texcompress_etc.c
> > @@ -548,6 +548,7 @@ etc2_rgb8_fetch_texel(const struct etc2_block *block,
> >if (punchthrough_alpha)
> >   dst[3] = 255;
> > }
> > +   else unreachable("unhandled block mode");
> >  }
> >
> >  static void
> > --
> > 2.17.1
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

2019-03-05 Thread Tapani Pälli




On 3/5/19 11:09 AM, Chih-Wei Huang wrote:

Tapani Pälli  於 2019年3月5日 週二 下午4:48寫道：


On 3/5/19 9:26 AM, Chih-Wei Huang wrote:

Mauro Rossi  於 2019年3月4日 週一 上午3:58寫道：


Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
   src/intel/Android.vulkan.mk | 38 +++--
   1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
   include $(CLEAR_VARS)
   include $(LOCAL_PATH)/Makefile.sources

-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml

   VULKAN_COMMON_INCLUDES := \
  $(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
  @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
  $(hide) touch $@

-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \


I know it was not introduced in this patch.
However, it makes no sense to let the header depend on a generated empty file.
This should be removed.


dummy.c is there to meet the Android build system's rules .. comment in
this file says:


I understand that.
I meant the header anv_entrypoints.h doesn't need to
depend on the generated dummy.c. That's clear.


Yeah is see, it is enough to have it in LOCAL_GENERATED_SOURCES and 
there is no need to depend on it to get it generated.



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

we have same hack applied also in following files within Mesa tree:

src/mesa/Android.libmesa_git_sha1.mk
src/intel/Android.genxml.mk
src/broadcom/Android.genxml.mk



+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
  --outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)

   LOCAL_EXPORT_C_INCLUDE_DIRS := \
   $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h

-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
  --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
  --outdir $(dir $@)

-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
  --out-c $@

-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
  @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \

[Mesa-dev] [PATCH] radv: allocate enough space in cmdbuf when starting a subpass

This fixes some CTS crashes with:
dEQP-VK.renderpass2.suballocation.attachment_write_mask.attachment_count_8.start_index_*

Ideally, we should check cmd_buffer->cs->max_dw because there is
likely enough space (the internal clear draws allocate space), but
keep that way for consistency.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ad0b934ddfc..3e652018499 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3446,7 +3446,7 @@ radv_cmd_buffer_begin_subpass(struct radv_cmd_buffer 
*cmd_buffer,
struct radv_subpass *subpass = >pass->subpasses[subpass_id];
 
MAYBE_UNUSED unsigned cdw_max = 
radeon_check_space(cmd_buffer->device->ws,
-  cmd_buffer->cs, 
2048);
+  cmd_buffer->cs, 
4096);
 
radv_subpass_barrier(cmd_buffer, >start_barrier);
 
-- 
2.21.0

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

[Mesa-dev] [PATCH] i965: Perform manual preemption checks between commands

2019-03-05 Thread Chris Wilson

Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.

Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli 
Cc: Kenneth Graunke 
---
Always double check before you hit send.
---
 src/mesa/drivers/dri/i965/brw_defines.h | 1 +
 src/mesa/drivers/dri/i965/brw_draw.c| 7 +++
 2 files changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 2729a54e144..ef71c556cca 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1420,6 +1420,7 @@ enum brw_pixel_shader_coverage_mask_mode {
 
 #define MI_NOOP(CMD_MI | 0)
 
+#define MI_ARB_CHECK   (CMD_MI | 0x5 << 23)
 #define MI_BATCH_BUFFER_END(CMD_MI | 0xA << 23)
 
 #define MI_FLUSH   (CMD_MI | (4 << 23))
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index d07349419cc..a04e334ffc4 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -196,6 +196,13 @@ brw_emit_prim(struct brw_context *brw,
if (verts_per_instance == 0 && !prim->is_indirect && !xfb_obj)
   return;
 
+   /* If this object is not itself preemptible, check before we begin. */
+   if (!brw->object_preemption) {
+  BEGIN_BATCH(1);
+  OUT_BATCH(MI_ARB_CHECK);
+  ADVANCE_BATCH();
+   }
+
/* If we're set to always flush, do it before and after the primitive emit.
 * We want to catch both missed flushes that hurt instruction/state cache
 * and missed flushes of the render cache as it heads to other parts of
-- 
2.20.1

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

[Mesa-dev] [PATCH] i965: Perform manual preemption checks between commands

2019-03-05 Thread Chris Wilson

Not all commands support being preempted as they execute, and for those
make sure we at least check for being preempted before we start so as to
try and minimise the latency of whomever is more important than
ourselves.

Cc: Jari Tahvanainen ,
Cc: Rafael Antognolli 
Cc: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_defines.h | 1 +
 src/mesa/drivers/dri/i965/brw_draw.c| 7 +++
 2 files changed, 8 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
b/src/mesa/drivers/dri/i965/brw_defines.h
index 2729a54e144..ef71c556cca 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1420,6 +1420,7 @@ enum brw_pixel_shader_coverage_mask_mode {
 
 #define MI_NOOP(CMD_MI | 0)
 
+#define MI_ARB_CHECK   (CMD_MI | 0x5 << 23)
 #define MI_BATCH_BUFFER_END(CMD_MI | 0xA << 23)
 
 #define MI_FLUSH   (CMD_MI | (4 << 23))
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index d07349419cc..49bb531ae7b 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -196,6 +196,13 @@ brw_emit_prim(struct brw_context *brw,
if (verts_per_instance == 0 && !prim->is_indirect && !xfb_obj)
   return;
 
+   /* If this object is not itself preemptible, check before we begin. */
+   if (!brw->object_preemption) {
+  BEGIN_BATCH(3);
+  OUT_BATCH(MI_ARB_CHECK);
+  ADVANCE_BATCH();
+   }
+
/* If we're set to always flush, do it before and after the primitive emit.
 * We want to catch both missed flushes that hurt instruction/state cache
 * and missed flushes of the render cache as it heads to other parts of
-- 
2.20.1

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

[Mesa-dev] [PATCH] ac/nir: implement emit_{imul, umul}_2x32_64 opcodes

Fixes: 58bcebd987b ("spirv: Allow [i/u]mulExtended to use new nir opcode")
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 36 +
 1 file changed, 36 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index af7a95137c2..74ae690e845 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -423,6 +423,32 @@ static LLVMValueRef emit_imul_high(struct ac_llvm_context 
*ctx,
return result;
 }
 
+static LLVMValueRef emit_umul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_umul_high(ctx, src0, src1);
+
+   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);
+   tmp = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
+}
+
+static LLVMValueRef emit_imul_2x32_64(struct ac_llvm_context *ctx,
+ LLVMValueRef src0, LLVMValueRef src1)
+{
+   LLVMValueRef result[2];
+
+   result[0] = LLVMBuildMul(ctx->builder, src0, src1, "");
+   result[1] = emit_imul_high(ctx, src0, src1);
+
+   LLVMValueRef tmp = LLVMGetUndef(ctx->v2i32);
+   tmp = ac_build_gather_values(ctx, result, 2);
+   return LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
+}
+
 static LLVMValueRef emit_bitfield_extract(struct ac_llvm_context *ctx,
  bool is_signed,
  const LLVMValueRef srcs[3])
@@ -977,6 +1003,16 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
src[1] = ac_to_integer(>ac, src[1]);
result = emit_imul_high(>ac, src[0], src[1]);
break;
+   case nir_op_umul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_umul_2x32_64(>ac, src[0], src[1]);
+   break;
+   case nir_op_imul_2x32_64:
+   src[0] = ac_to_integer(>ac, src[0]);
+   src[1] = ac_to_integer(>ac, src[1]);
+   result = emit_imul_2x32_64(>ac, src[0], src[1]);
+   break;
case nir_op_pack_half_2x16:
result = emit_pack_half_2x16(>ac, src[0]);
break;
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

2019-03-05 Thread Chih-Wei Huang

Tapani Pälli  於 2019年3月5日 週二 下午4:48寫道：
>
> On 3/5/19 9:26 AM, Chih-Wei Huang wrote:
> > Mauro Rossi  於 2019年3月4日 週一 上午3:58寫道：
> >>
> >> Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
> >> Rename the variable labels according to targets and python scripts
> >> Align the building rules as per Automake for simplification
> >>
> >> Fixes building errors during rebuils due to missing dependencies
> >>
> >> Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
> >> Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
> >> tables")
> >> Signed-off-by: Mauro Rossi 
> >> Cc: "19.0" 
> >> ---
> >>   src/intel/Android.vulkan.mk | 38 +++--
> >>   1 file changed, 24 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
> >> index 04c9d5b3e4..2e99ac6294 100644
> >> --- a/src/intel/Android.vulkan.mk
> >> +++ b/src/intel/Android.vulkan.mk
> >> @@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
> >>   include $(CLEAR_VARS)
> >>   include $(LOCAL_PATH)/Makefile.sources
> >>
> >> -VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
> >> $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
> >> -
> >> -VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
> >> $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
> >> +ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
> >> +ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
> >> +ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
> >> +VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
> >>
> >>   VULKAN_COMMON_INCLUDES := \
> >>  $(MESA_TOP)/include \
> >> @@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
> >>  @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
> >>  $(hide) touch $@
> >>
> >> -$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
> >> -   $(VK_ENTRYPOINTS_SCRIPT) \
> >> +$(intermediates)/vulkan/anv_entrypoints.h: 
> >> $(intermediates)/vulkan/dummy.c \
> >
> > I know it was not introduced in this patch.
> > However, it makes no sense to let the header depend on a generated empty 
> > file.
> > This should be removed.
>
> dummy.c is there to meet the Android build system's rules .. comment in
> this file says:

I understand that.
I meant the header anv_entrypoints.h doesn't need to
depend on the generated dummy.c. That's clear.

> # 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.
>
> we have same hack applied also in following files within Mesa tree:
>
> src/mesa/Android.libmesa_git_sha1.mk
> src/intel/Android.genxml.mk
> src/broadcom/Android.genxml.mk
>
>
> >> +  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> >> +  $(ANV_EXTENSIONS_SCRIPT) \
> >> +  $(VULKAN_API_XML)
> >> +   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> >>  --outdir $(dir $@) \
> >> -   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
> >> +   --xml $(VULKAN_API_XML)
> >>
> >>   LOCAL_EXPORT_C_INCLUDE_DIRS := \
> >>   $(intermediates)
> >> @@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
> >> $(intermediates)/vulkan/anv_entrypoints.c
> >>   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
> >>   LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
> >>
> >> -$(intermediates)/vulkan/anv_entrypoints.c:
> >> +$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> >> +  $(ANV_EXTENSIONS_SCRIPT) \
> >> +  $(VULKAN_API_XML)
> >>  @mkdir -p $(dir $@)
> >> -   $(VK_ENTRYPOINTS_SCRIPT) \
> >> +   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
> >>  --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
> >>  --outdir $(dir $@)
> >>
> >> -$(intermediates)/vulkan/anv_extensions.c:
> >> +$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
> >> + $(ANV_EXTENSIONS_SCRIPT) \
> >> + $(VULKAN_API_XML)
> >>  @mkdir -p $(dir $@)
> >> -   $(VK_EXTENSIONS_SCRIPT) \
> >> -   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
> >> +   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
> >> +   --xml $(VULKAN_API_XML) \
> >>  --out-c $@
> >>
> >> -$(intermediates)/vulkan/anv_extensions.h:
> >> +$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
> >> +  $(ANV_EXTENSIONS_SCRIPT) \
> >> +

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

2019-03-05 Thread Tapani Pälli




On 3/5/19 9:26 AM, Chih-Wei Huang wrote:

Mauro Rossi  於 2019年3月4日 週一 上午3:58寫道：


Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 38 +++--
  1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  include $(LOCAL_PATH)/Makefile.sources

-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml

  VULKAN_COMMON_INCLUDES := \
 $(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
 @echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
 $(hide) touch $@

-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \


I know it was not introduced in this patch.
However, it makes no sense to let the header depend on a generated empty file.
This should be removed.


dummy.c is there to meet the Android build system's rules .. comment in 
this file says:


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

we have same hack applied also in following files within Mesa tree:

src/mesa/Android.libmesa_git_sha1.mk
src/intel/Android.genxml.mk
src/broadcom/Android.genxml.mk



+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
 --outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)

  LOCAL_EXPORT_C_INCLUDE_DIRS := \
  $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h

-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
 --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
 --outdir $(dir $@)

-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
 --out-c $@

-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
 @mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
 --out-h $@

  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
--




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

[Mesa-dev] [PATCH 5/8] mesa: Remove _ae_{, un}map_vbos and dependencies.

From: Mathias Fröhlich 

Since mapping and unmapping the buffer objects in a VAO is handled
directly from the VAO, this part of the _NEW_ARRAY state is no longer
used. So remove this part of array element state.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 95 
 src/mesa/main/api_arrayelt.h |  5 --
 2 files changed, 100 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index ea91fbcabf5..1c086bbcda4 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -66,11 +66,6 @@ typedef struct {
AEarray arrays[32];
AEattrib attribs[VERT_ATTRIB_MAX + 1];
 
-   /* List of VBOs we need to map before executing ArrayElements */
-   struct gl_buffer_object *vbo[VERT_ATTRIB_MAX];
-   GLuint nr_vbos;
-   GLboolean mapped_vbos;  /**< Any currently mapped VBOs? */
-
bool dirty_state;
 } AEcontext;
 
@@ -1534,26 +1529,6 @@ _ae_destroy_context(struct gl_context *ctx)
 }
 
 
-/**
- * Check if the given vertex buffer object exists and is not mapped.
- * If so, add it to the list of buffers we must map before executing
- * an glArrayElement call.
- */
-static void
-check_vbo(AEcontext *actx, struct gl_buffer_object *vbo)
-{
-   if (_mesa_is_bufferobj(vbo) &&
-   !_mesa_bufferobj_mapped(vbo, MAP_INTERNAL)) {
-  GLuint i;
-  for (i = 0; i < actx->nr_vbos; i++)
- if (actx->vbo[i] == vbo)
-return;  /* already in the list, we're done */
-  assert(actx->nr_vbos < VERT_ATTRIB_MAX);
-  actx->vbo[actx->nr_vbos++] = vbo;
-   }
-}
-
-
 /**
  * Make a list of per-vertex functions to call for each glArrayElement call.
  * These functions access the array data (i.e. glVertex, glColor, glNormal,
@@ -1569,14 +1544,11 @@ _ae_update_state(struct gl_context *ctx)
GLuint i;
struct gl_vertex_array_object *vao = ctx->Array.VAO;
 
-   actx->nr_vbos = 0;
-
/* conventional vertex arrays */
if (vao->Enabled & VERT_BIT_COLOR_INDEX) {
   aa->array = >VertexAttrib[VERT_ATTRIB_COLOR_INDEX];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = IndexFuncs[TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1584,7 +1556,6 @@ _ae_update_state(struct gl_context *ctx)
   aa->array = >VertexAttrib[VERT_ATTRIB_EDGEFLAG];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = _gloffset_EdgeFlagv;
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1592,7 +1563,6 @@ _ae_update_state(struct gl_context *ctx)
   aa->array = >VertexAttrib[VERT_ATTRIB_NORMAL];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = NormalFuncs[TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1600,7 +1570,6 @@ _ae_update_state(struct gl_context *ctx)
   aa->array = >VertexAttrib[VERT_ATTRIB_COLOR0];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = 
ColorFuncs[aa->array->Format.Size-3][TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1608,7 +1577,6 @@ _ae_update_state(struct gl_context *ctx)
   aa->array = >VertexAttrib[VERT_ATTRIB_COLOR1];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = SecondaryColorFuncs[TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1616,7 +1584,6 @@ _ae_update_state(struct gl_context *ctx)
   aa->array = >VertexAttrib[VERT_ATTRIB_FOG];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset = FogCoordFuncs[TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
 
@@ -1634,7 +1601,6 @@ _ae_update_state(struct gl_context *ctx)
  [at->array->Format.Size-1]
  [TYPE_IDX(at->array->Format.Type)];
  at->index = VERT_ATTRIB_TEX0 + i;
-check_vbo(actx, at->binding->BufferObj);
  at++;
   }
}
@@ -1666,7 +1632,6 @@ _ae_update_state(struct gl_context *ctx)
 [TYPE_IDX(at->array->Format.Type)];
 
  at->index = i;
-check_vbo(actx, at->binding->BufferObj);
  at++;
   }
}
@@ -1680,19 +1645,15 @@ _ae_update_state(struct gl_context *ctx)
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   assert(aa->array->Format.Size >= 2); /* XXX fix someday? */
   aa->offset = 
VertexFuncs[aa->array->Format.Size-2][TYPE_IDX(aa->array->Format.Type)];
-  check_vbo(actx, aa->binding->BufferObj);
   aa++;
}
else if (vao->Enabled & VERT_BIT_POS) {
   aa->array = >VertexAttrib[VERT_ATTRIB_POS];
   aa->binding = >BufferBinding[aa->array->BufferBindingIndex];
   aa->offset =

[Mesa-dev] [PATCH 7/8] vbo: Fix basevertex handling in display list compiles.

From: Mathias Fröhlich 

The standard requires that the primitive restart comparison happens before
the basevertex value is added. Do this now, drop a reference to the standard
why this happens at this place.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save_api.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index bb578694e00..7f8c06b630c 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1373,8 +1373,15 @@ _save_OBE_MultiDrawArrays(GLenum mode, const GLint 
*first,
 
 
 static void
-array_element(struct gl_context *ctx, struct _glapi_table *disp, GLuint elt)
+array_element(struct gl_context *ctx, struct _glapi_table *disp,
+  GLint basevertex, GLuint elt)
 {
+   /* Section 10.3.5 Primitive Restart:
+* [...]
+*When one of the *BaseVertex drawing commands specified in section 10.5
+* is used, the primitive restart comparison occurs before the basevertex
+* offset is added to the array index.
+*/
/* If PrimitiveRestart is enabled and the index is the RestartIndex
 * then we call PrimitiveRestartNV and return.
 */
@@ -1383,7 +1390,7 @@ array_element(struct gl_context *ctx, struct _glapi_table 
*disp, GLuint elt)
   return;
}
 
-   _mesa_array_element(ctx, disp, elt);
+   _mesa_array_element(ctx, disp, basevertex + elt);
 }
 
 
@@ -1432,15 +1439,15 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
switch (type) {
case GL_UNSIGNED_BYTE:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), (basevertex + ((GLubyte *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), basevertex, ((GLubyte *) 
indices)[i]);
   break;
case GL_UNSIGNED_SHORT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), (basevertex + ((GLushort *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), basevertex, ((GLushort *) 
indices)[i]);
   break;
case GL_UNSIGNED_INT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), (basevertex + ((GLuint *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), basevertex, ((GLuint *) 
indices)[i]);
   break;
default:
   _mesa_error(ctx, GL_INVALID_ENUM, "glDrawElements(type)");
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/8] Half way to remove _NEW_ARRAY.

From: Mathias Fröhlich 

Hi all,

The following series introduces functions to map and unmap all
vbos stored in a vao. Make use of those functions where possible.
On that way cleanup and fix what comes up along the way.
The series also already removes half of the state that is tracked
using the _NEW_ARRAY bit. The rest of the _NEW_ARRAY state will
be removed past some more optimization in the vbo module.

The series is tested without regressions on radeonsi using piglit and deqp.

please review!
Thanks!

Mathias

Mathias Fröhlich (8):
  mesa: Implement helper functions to map and unmap a VAO.
  mesa: Factor out _mesa_array_element.
  mesa: Use _mesa_array_element in dlist save.
  mesa: Replace _ae_{,un}map_vbos with _mesa_vao_{,un}map_arrays
  mesa: Remove _ae_{,un}map_vbos and dependencies.
  mesa: Use mapping tools in debug prints.
  vbo: Fix basevertex handling in display list compiles.
  vbo: Fix GL_PRIMITIVE_RESTART_FIXED_INDEX in display list compiles.

 src/mesa/main/api_arrayelt.c | 136 +++
 src/mesa/main/api_arrayelt.h |   7 +-
 src/mesa/main/arrayobj.c |  84 ++
 src/mesa/main/arrayobj.h |  18 +
 src/mesa/main/draw.c |  57 ---
 src/mesa/vbo/vbo_save_api.c  |  46 +---
 6 files changed, 177 insertions(+), 171 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH 8/8] vbo: Fix GL_PRIMITIVE_RESTART_FIXED_INDEX in display list compiles.

From: Mathias Fröhlich 

The maximum value primitive restart index is different for each index data
type. Use the appropriate fixed restart index value.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save_api.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 7f8c06b630c..de0be4e3324 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1374,7 +1374,7 @@ _save_OBE_MultiDrawArrays(GLenum mode, const GLint *first,
 
 static void
 array_element(struct gl_context *ctx, struct _glapi_table *disp,
-  GLint basevertex, GLuint elt)
+  GLint basevertex, GLuint elt, unsigned index_size)
 {
/* Section 10.3.5 Primitive Restart:
 * [...]
@@ -1385,7 +1385,8 @@ array_element(struct gl_context *ctx, struct _glapi_table 
*disp,
/* If PrimitiveRestart is enabled and the index is the RestartIndex
 * then we call PrimitiveRestartNV and return.
 */
-   if (ctx->Array.PrimitiveRestart && elt == ctx->Array.RestartIndex) {
+   if (ctx->Array._PrimitiveRestart &&
+   elt == _mesa_primitive_restart_index(ctx, index_size)) {
   CALL_PrimitiveRestartNV(disp, ());
   return;
}
@@ -1439,15 +1440,18 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
switch (type) {
case GL_UNSIGNED_BYTE:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex, ((GLubyte *) 
indices)[i]);
+ array_element(ctx, GET_DISPATCH(), basevertex,
+   ((GLubyte *) indices)[i], 1);
   break;
case GL_UNSIGNED_SHORT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex, ((GLushort *) 
indices)[i]);
+ array_element(ctx, GET_DISPATCH(), basevertex,
+   ((GLushort *) indices)[i], 2);
   break;
case GL_UNSIGNED_INT:
   for (i = 0; i < count; i++)
- array_element(ctx, GET_DISPATCH(), basevertex, ((GLuint *) 
indices)[i]);
+ array_element(ctx, GET_DISPATCH(), basevertex,
+   ((GLuint *) indices)[i], 4);
   break;
default:
   _mesa_error(ctx, GL_INVALID_ENUM, "glDrawElements(type)");
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/8] mesa: Replace _ae_{, un}map_vbos with _mesa_vao_{, un}map_arrays

From: Mathias Fröhlich 

Due to the use of bitmaps, the _mesa_vao_{,un}map_arrays functions
should provide comparable runtime efficienty to the currently used
_ae_{,un}map_vbos functions. So use this functions and enable
further cleanup.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 12 
 src/mesa/vbo/vbo_save_api.c  | 12 +++-
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index cb0d2a28a6c..ea91fbcabf5 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1792,7 +1792,7 @@ _ae_ArrayElement(GLint elt)
GET_CURRENT_CONTEXT(ctx);
const AEcontext *actx = AE_CONTEXT(ctx);
const struct _glapi_table * const disp = GET_DISPATCH();
-   GLboolean do_map;
+   struct gl_vertex_array_object *vao;
 
/* If PrimitiveRestart is enabled and the index is the RestartIndex
 * then we call PrimitiveRestartNV and return.
@@ -1807,16 +1807,12 @@ _ae_ArrayElement(GLint elt)
   _ae_update_state(ctx);
}
 
-   /* Determine if we need to map/unmap VBOs */
-   do_map = actx->nr_vbos && !actx->mapped_vbos;
-
-   if (do_map)
-  _ae_map_vbos(ctx);
+   vao = ctx->Array.VAO;
+   _mesa_vao_map_arrays(ctx, vao, GL_MAP_READ_BIT);
 
_mesa_array_element(ctx, (struct _glapi_table *)disp, elt);
 
-   if (do_map)
-  _ae_unmap_vbos(ctx);
+   _mesa_vao_unmap_arrays(ctx, vao);
 }
 
 
diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 6122727bae9..bb578694e00 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1307,6 +1307,7 @@ static void GLAPIENTRY
 _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei count)
 {
GET_CURRENT_CONTEXT(ctx);
+   struct gl_vertex_array_object *vao = ctx->Array.VAO;
struct vbo_save_context *save = _context(ctx)->save;
GLint i;
 
@@ -1325,7 +1326,7 @@ _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei 
count)
/* Make sure to process any VBO binding changes */
_mesa_update_state(ctx);
 
-   _ae_map_vbos(ctx);
+   _mesa_vao_map_arrays(ctx, vao, GL_MAP_READ_BIT);
 
vbo_save_NotifyBegin(ctx, mode, true);
 
@@ -1333,7 +1334,7 @@ _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei 
count)
   _mesa_array_element(ctx, GET_DISPATCH(), start + i);
CALL_End(GET_DISPATCH(), ());
 
-   _ae_unmap_vbos(ctx);
+   _mesa_vao_unmap_arrays(ctx, vao);
 }
 
 
@@ -1395,7 +1396,8 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
 {
GET_CURRENT_CONTEXT(ctx);
struct vbo_save_context *save = _context(ctx)->save;
-   struct gl_buffer_object *indexbuf = ctx->Array.VAO->IndexBufferObj;
+   struct gl_vertex_array_object *vao = ctx->Array.VAO;
+   struct gl_buffer_object *indexbuf = vao->IndexBufferObj;
GLint i;
 
if (!_mesa_is_valid_prim_mode(ctx, mode)) {
@@ -1419,7 +1421,7 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
/* Make sure to process any VBO binding changes */
_mesa_update_state(ctx);
 
-   _ae_map_vbos(ctx);
+   _mesa_vao_map(ctx, vao, GL_MAP_READ_BIT);
 
if (_mesa_is_bufferobj(indexbuf))
   indices =
@@ -1447,7 +1449,7 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
 
CALL_End(GET_DISPATCH(), ());
 
-   _ae_unmap_vbos(ctx);
+   _mesa_vao_unmap(ctx, vao);
 }
 
 static void GLAPIENTRY
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/8] mesa: Factor out _mesa_array_element.

From: Mathias Fröhlich 

The factored out function handles emitting the vertex attributes
at the given index. The now public accessible function gets used
in the following patches.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/api_arrayelt.c | 49 ++--
 src/mesa/main/api_arrayelt.h |  2 ++
 2 files changed, 32 insertions(+), 19 deletions(-)

diff --git a/src/mesa/main/api_arrayelt.c b/src/mesa/main/api_arrayelt.c
index 2b59c478d9e..cb0d2a28a6c 100644
--- a/src/mesa/main/api_arrayelt.c
+++ b/src/mesa/main/api_arrayelt.c
@@ -1751,6 +1751,35 @@ _ae_unmap_vbos(struct gl_context *ctx)
 }
 
 
+void
+_mesa_array_element(struct gl_context *ctx,
+struct _glapi_table *disp, GLint elt)
+{
+   const AEcontext *actx = AE_CONTEXT(ctx);
+
+   if (actx->dirty_state)
+  _ae_update_state(ctx);
+
+   /* emit generic attribute elements */
+   for (const AEattrib *at = actx->attribs; at->func; at++) {
+  const GLubyte *src
+ = ADD_POINTERS(at->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
+_mesa_vertex_attrib_address(at->array, at->binding))
+ + elt * at->binding->Stride;
+  at->func(at->index, src);
+   }
+
+   /* emit conventional arrays elements */
+   for (const AEarray *aa = actx->arrays; aa->offset != -1 ; aa++) {
+  const GLubyte *src
+ = ADD_POINTERS(aa->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
+_mesa_vertex_attrib_address(aa->array, aa->binding))
+ + elt * aa->binding->Stride;
+  CALL_by_offset(disp, (array_func), aa->offset, ((const void *) src));
+   }
+}
+
+
 /**
  * Called via glArrayElement() and glDrawArrays().
  * Issue the glNormal, glVertex, glColor, glVertexAttrib, etc functions
@@ -1762,8 +1791,6 @@ _ae_ArrayElement(GLint elt)
 {
GET_CURRENT_CONTEXT(ctx);
const AEcontext *actx = AE_CONTEXT(ctx);
-   const AEarray *aa;
-   const AEattrib *at;
const struct _glapi_table * const disp = GET_DISPATCH();
GLboolean do_map;
 
@@ -1786,23 +1813,7 @@ _ae_ArrayElement(GLint elt)
if (do_map)
   _ae_map_vbos(ctx);
 
-   /* emit generic attribute elements */
-   for (at = actx->attribs; at->func; at++) {
-  const GLubyte *src
- = ADD_POINTERS(at->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(at->array, at->binding))
- + elt * at->binding->Stride;
-  at->func(at->index, src);
-   }
-
-   /* emit conventional arrays elements */
-   for (aa = actx->arrays; aa->offset != -1 ; aa++) {
-  const GLubyte *src
- = ADD_POINTERS(aa->binding->BufferObj->Mappings[MAP_INTERNAL].Pointer,
-_mesa_vertex_attrib_address(aa->array, aa->binding))
- + elt * aa->binding->Stride;
-  CALL_by_offset(disp, (array_func), aa->offset, ((const void *) src));
-   }
+   _mesa_array_element(ctx, (struct _glapi_table *)disp, elt);
 
if (do_map)
   _ae_unmap_vbos(ctx);
diff --git a/src/mesa/main/api_arrayelt.h b/src/mesa/main/api_arrayelt.h
index 6543a58f724..d0412806153 100644
--- a/src/mesa/main/api_arrayelt.h
+++ b/src/mesa/main/api_arrayelt.h
@@ -36,6 +36,8 @@ extern GLboolean _ae_create_context( struct gl_context *ctx );
 extern void _ae_destroy_context( struct gl_context *ctx );
 extern void _ae_invalidate_state(struct gl_context *ctx);
 extern bool _ae_is_state_dirty(struct gl_context *ctx);
+extern void _mesa_array_element(struct gl_context *ctx,
+struct _glapi_table *disp, GLint elt);
 extern void GLAPIENTRY _ae_ArrayElement( GLint elt );
 
 /* May optionally be called before a batch of element calls:
-- 
2.20.1

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

[Mesa-dev] [PATCH 6/8] mesa: Use mapping tools in debug prints.

From: Mathias Fröhlich 

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/draw.c | 57 ++--
 1 file changed, 12 insertions(+), 45 deletions(-)

diff --git a/src/mesa/main/draw.c b/src/mesa/main/draw.c
index bfc4b9c9373..fa70463eaee 100644
--- a/src/mesa/main/draw.c
+++ b/src/mesa/main/draw.c
@@ -73,12 +73,6 @@ check_array_data(struct gl_context *ctx, struct 
gl_vertex_array_object *vao,
   struct gl_buffer_object *bo = binding->BufferObj;
   const void *data = array->Ptr;
   if (_mesa_is_bufferobj(bo)) {
- if (!bo->Mappings[MAP_INTERNAL].Pointer) {
-/* need to map now */
-bo->Mappings[MAP_INTERNAL].Pointer =
-   ctx->Driver.MapBufferRange(ctx, 0, bo->Size,
-  GL_MAP_READ_BIT, bo, MAP_INTERNAL);
- }
  data = ADD_POINTERS(_mesa_vertex_attrib_address(array, binding),
  bo->Mappings[MAP_INTERNAL].Pointer);
   }
@@ -110,25 +104,6 @@ check_array_data(struct gl_context *ctx, struct 
gl_vertex_array_object *vao,
 }
 
 
-/**
- * Unmap the buffer object referenced by given array, if mapped.
- */
-static void
-unmap_array_buffer(struct gl_context *ctx, struct gl_vertex_array_object *vao,
-   GLuint attrib)
-{
-   const struct gl_array_attributes *array = >VertexAttrib[attrib];
-   if (vao->Enabled & VERT_BIT(attrib)) {
-  const struct gl_vertex_buffer_binding *binding =
- >BufferBinding[array->BufferBindingIndex];
-  struct gl_buffer_object *bo = binding->BufferObj;
-  if (_mesa_is_bufferobj(bo) && _mesa_bufferobj_mapped(bo, MAP_INTERNAL)) {
- ctx->Driver.UnmapBuffer(ctx, bo, MAP_INTERNAL);
-  }
-   }
-}
-
-
 static inline int
 sizeof_ib_type(GLenum type)
 {
@@ -156,17 +131,14 @@ check_draw_elements_data(struct gl_context *ctx, GLsizei 
count,
  GLint basevertex)
 {
struct gl_vertex_array_object *vao = ctx->Array.VAO;
-   const void *elemMap;
GLint i;
GLuint k;
 
-   if (_mesa_is_bufferobj(vao->IndexBufferObj)) {
-  elemMap = ctx->Driver.MapBufferRange(ctx, 0,
-   vao->IndexBufferObj->Size,
-   GL_MAP_READ_BIT,
-   vao->IndexBufferObj, MAP_INTERNAL);
-  elements = ADD_POINTERS(elements, elemMap);
-   }
+   _mesa_vao_map(ctx, vao, GL_MAP_READ_BIT);
+
+   if (_mesa_is_bufferobj(vao->IndexBufferObj))
+   elements =
+  ADD_POINTERS(vao->IndexBufferObj->Mappings[MAP_INTERNAL].Pointer, 
elements);
 
for (i = 0; i < count; i++) {
   GLuint j;
@@ -192,13 +164,7 @@ check_draw_elements_data(struct gl_context *ctx, GLsizei 
count,
   }
}
 
-   if (_mesa_is_bufferobj(vao->IndexBufferObj)) {
-  ctx->Driver.UnmapBuffer(ctx, vao->IndexBufferObj, MAP_INTERNAL);
-   }
-
-   for (k = 0; k < VERT_ATTRIB_MAX; k++) {
-  unmap_array_buffer(ctx, vao, k);
-   }
+   _mesa_vao_unmap(ctx, vao);
 }
 
 
@@ -272,11 +238,13 @@ static void
 print_draw_arrays(struct gl_context *ctx,
   GLenum mode, GLint start, GLsizei count)
 {
-   const struct gl_vertex_array_object *vao = ctx->Array.VAO;
+   struct gl_vertex_array_object *vao = ctx->Array.VAO;
 
printf("_mesa_DrawArrays(mode 0x%x, start %d, count %d):\n",
   mode, start, count);
 
+   _mesa_vao_map_arrays(ctx, vao, GL_MAP_READ_BIT);
+
GLbitfield mask = vao->Enabled;
while (mask) {
   const gl_vert_attrib i = u_bit_scan();
@@ -293,9 +261,7 @@ print_draw_arrays(struct gl_context *ctx,
  array->Ptr, bufObj->Name);
 
   if (_mesa_is_bufferobj(bufObj)) {
- GLubyte *p = ctx->Driver.MapBufferRange(ctx, 0, bufObj->Size,
- GL_MAP_READ_BIT, bufObj,
- MAP_INTERNAL);
+ GLubyte *p = bufObj->Mappings[MAP_INTERNAL].Pointer;
  int offset = (int) (GLintptr)
 _mesa_vertex_attrib_address(array, binding);
 
@@ -326,9 +292,10 @@ print_draw_arrays(struct gl_context *ctx,
printf("float[%d] = 0x%08x %f\n", i, k[i], f[i]);
 i++;
  } while (i < n);
- ctx->Driver.UnmapBuffer(ctx, bufObj, MAP_INTERNAL);
   }
}
+
+   _mesa_vao_unmap_arrays(ctx, vao);
 }
 
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/8] mesa: Implement helper functions to map and unmap a VAO.

From: Mathias Fröhlich 

Provide a set of functions that maps or unmaps all VBOs held
in a VAO. The functions will be used in the following patches.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/main/arrayobj.c | 84 
 src/mesa/main/arrayobj.h | 18 +
 2 files changed, 102 insertions(+)

diff --git a/src/mesa/main/arrayobj.c b/src/mesa/main/arrayobj.c
index 68d30aa9b1f..1f6c6904739 100644
--- a/src/mesa/main/arrayobj.c
+++ b/src/mesa/main/arrayobj.c
@@ -913,6 +913,90 @@ _mesa_all_buffers_are_unmapped(const struct 
gl_vertex_array_object *vao)
return true;
 }
 
+
+/**
+ * Map buffer objects used in attribute arrays.
+ */
+void
+_mesa_vao_map_arrays(struct gl_context *ctx, struct gl_vertex_array_object 
*vao,
+ GLbitfield access)
+{
+   GLbitfield mask = vao->Enabled & vao->VertexAttribBufferMask;
+   while (mask) {
+  /* Do not use u_bit_scan as we can walk multiple attrib arrays at once */
+  const gl_vert_attrib attr = ffs(mask) - 1;
+  const GLubyte bindex = vao->VertexAttrib[attr].BufferBindingIndex;
+  struct gl_vertex_buffer_binding *binding = >BufferBinding[bindex];
+  mask &= ~binding->_BoundArrays;
+
+  struct gl_buffer_object *bo = binding->BufferObj;
+  assert(_mesa_is_bufferobj(bo));
+  if (_mesa_bufferobj_mapped(bo, MAP_INTERNAL))
+ continue;
+
+  ctx->Driver.MapBufferRange(ctx, 0, bo->Size, access, bo, MAP_INTERNAL);
+   }
+}
+
+
+/**
+ * Map buffer objects used in the vao,
+ * attribute arrays and index buffer.
+ */
+void
+_mesa_vao_map(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+  GLbitfield access)
+{
+   struct gl_buffer_object *bo = vao->IndexBufferObj;
+
+   if (_mesa_is_bufferobj(bo) && !_mesa_bufferobj_mapped(bo, MAP_INTERNAL))
+  ctx->Driver.MapBufferRange(ctx, 0, bo->Size, access, bo, MAP_INTERNAL);
+
+   _mesa_vao_map_arrays(ctx, vao, access);
+}
+
+
+/**
+ * Unmap buffer objects used in attribute arrays.
+ */
+void
+_mesa_vao_unmap_arrays(struct gl_context *ctx,
+   struct gl_vertex_array_object *vao)
+{
+   GLbitfield mask = vao->Enabled & vao->VertexAttribBufferMask;
+   while (mask) {
+  /* Do not use u_bit_scan as we can walk multiple attrib arrays at once */
+  const gl_vert_attrib attr = ffs(mask) - 1;
+  const GLubyte bindex = vao->VertexAttrib[attr].BufferBindingIndex;
+  struct gl_vertex_buffer_binding *binding = >BufferBinding[bindex];
+  mask &= ~binding->_BoundArrays;
+
+  struct gl_buffer_object *bo = binding->BufferObj;
+  assert(_mesa_is_bufferobj(bo));
+  if (!_mesa_bufferobj_mapped(bo, MAP_INTERNAL))
+ continue;
+
+  ctx->Driver.UnmapBuffer(ctx, bo, MAP_INTERNAL);
+   }
+}
+
+
+/**
+ * Unmap buffer objects used in the vao,
+ * attribute arrays and index buffer.
+ */
+void
+_mesa_vao_unmap(struct gl_context *ctx, struct gl_vertex_array_object *vao)
+{
+   struct gl_buffer_object *bo = vao->IndexBufferObj;
+
+   if (_mesa_is_bufferobj(bo) && _mesa_bufferobj_mapped(bo, MAP_INTERNAL))
+  ctx->Driver.UnmapBuffer(ctx, bo, MAP_INTERNAL);
+
+   _mesa_vao_unmap_arrays(ctx, vao);
+}
+
+
 /**/
 /* API Functions  */
 /**/
diff --git a/src/mesa/main/arrayobj.h b/src/mesa/main/arrayobj.h
index ee87b4b6ba5..7516bae9e39 100644
--- a/src/mesa/main/arrayobj.h
+++ b/src/mesa/main/arrayobj.h
@@ -100,6 +100,24 @@ extern bool
 _mesa_all_buffers_are_unmapped(const struct gl_vertex_array_object *vao);
 
 
+extern void
+_mesa_vao_map_arrays(struct gl_context *ctx, struct gl_vertex_array_object 
*vao,
+ GLbitfield access);
+
+extern void
+_mesa_vao_map(struct gl_context *ctx, struct gl_vertex_array_object *vao,
+  GLbitfield access);
+
+
+extern void
+_mesa_vao_unmap_arrays(struct gl_context *ctx,
+   struct gl_vertex_array_object *vao);
+
+extern void
+_mesa_vao_unmap(struct gl_context *ctx,
+struct gl_vertex_array_object *vao);
+
+
 /**
  * Array to apply the position/generic0 aliasing map to
  * an attribute value used in vertex processing inputs to an attribute
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/8] mesa: Use _mesa_array_element in dlist save.

From: Mathias Fröhlich 

Make use of the newly factored out _mesa_array_element function
in display list compilation. For now that duplicates out the
primitive restart logic. But that turns out to need a fix in
display list handling anyhow.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save_api.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index fb8d68d5560..6122727bae9 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -1330,7 +1330,7 @@ _save_OBE_DrawArrays(GLenum mode, GLint start, GLsizei 
count)
vbo_save_NotifyBegin(ctx, mode, true);
 
for (i = 0; i < count; i++)
-  CALL_ArrayElement(GET_DISPATCH(), (start + i));
+  _mesa_array_element(ctx, GET_DISPATCH(), start + i);
CALL_End(GET_DISPATCH(), ());
 
_ae_unmap_vbos(ctx);
@@ -1371,6 +1371,21 @@ _save_OBE_MultiDrawArrays(GLenum mode, const GLint 
*first,
 }
 
 
+static void
+array_element(struct gl_context *ctx, struct _glapi_table *disp, GLuint elt)
+{
+   /* If PrimitiveRestart is enabled and the index is the RestartIndex
+* then we call PrimitiveRestartNV and return.
+*/
+   if (ctx->Array.PrimitiveRestart && elt == ctx->Array.RestartIndex) {
+  CALL_PrimitiveRestartNV(disp, ());
+  return;
+   }
+
+   _mesa_array_element(ctx, disp, elt);
+}
+
+
 /* Could do better by copying the arrays and element list intact and
  * then emitting an indexed prim at runtime.
  */
@@ -1415,15 +1430,15 @@ _save_OBE_DrawElementsBaseVertex(GLenum mode, GLsizei 
count, GLenum type,
switch (type) {
case GL_UNSIGNED_BYTE:
   for (i = 0; i < count; i++)
- CALL_ArrayElement(GET_DISPATCH(), (basevertex + ((GLubyte *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), (basevertex + ((GLubyte *) 
indices)[i]));
   break;
case GL_UNSIGNED_SHORT:
   for (i = 0; i < count; i++)
- CALL_ArrayElement(GET_DISPATCH(), (basevertex + ((GLushort *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), (basevertex + ((GLushort *) 
indices)[i]));
   break;
case GL_UNSIGNED_INT:
   for (i = 0; i < count; i++)
- CALL_ArrayElement(GET_DISPATCH(), (basevertex + ((GLuint *) 
indices)[i]));
+ array_element(ctx, GET_DISPATCH(), (basevertex + ((GLuint *) 
indices)[i]));
   break;
default:
   _mesa_error(ctx, GL_INVALID_ENUM, "glDrawElements(type)");
-- 
2.20.1

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

[Mesa-dev] [Bug 109818] wrong color rendering in SOULCALIBUR 6 using dxvk