Re: [Mesa-dev] [PATCH] i965: Don't leak gen_spec from INTEL_DEBUG=bat handling.

[Jason Ekstrand]

Is the whole spec really a flat thing you an free with a single free()?  If 
not, maybe we should consider pulling in ralloc to help out.



On March 22, 2017 22:25:40 Kenneth Graunke  wrote:


We were loading the XML descriptions on every batchbuffer and leaking
them each time.  Now, we load it once at screen init time and free it
at screen destroy time.  Caught by Coverity.

CID: 1403203
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 src/mesa/drivers/dri/i965/intel_screen.c  | 8 
 src/mesa/drivers/dri/i965/intel_screen.h  | 4 
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c

index 49a00c12ba2..e3fb071300c 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -202,7 +202,7 @@ static void
 do_batch_dump(struct brw_context *brw)
 {
struct intel_batchbuffer *batch = >batch;
-   struct gen_spec *spec = gen_spec_load(>screen->devinfo);
+   struct gen_spec *spec = brw->screen->decoder_spec;

if (batch->ring != RENDER_RING)
   return;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c

index c7f111d04af..c8c6698a756 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -38,6 +38,7 @@
 #include "util/ralloc.h"
 #include "brw_defines.h"
 #include "compiler/nir/nir.h"
+#include "common/gen_decoder.h"

 #include "utils.h"
 #include "xmlpool.h"
@@ -1106,6 +1107,8 @@ intelDestroyScreen(__DRIscreen * sPriv)
dri_bufmgr_destroy(screen->bufmgr);
driDestroyOptionInfo(>optionCache);

+   free(screen->decoder_spec);
+
ralloc_free(screen);
sPriv->driverPrivate = NULL;
 }
@@ -1764,6 +1767,11 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)

brw_process_intel_debug_variable();

+#ifdef DEBUG
+   if (INTEL_DEBUG & DEBUG_BATCH)
+  screen->decoder_spec = gen_spec_load(devinfo);
+#endif
+
if (INTEL_DEBUG & DEBUG_BUFMGR)
   dri_bufmgr_set_debug(screen->bufmgr, true);

diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h

index d8cda58c964..29ce94d6756 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -41,6 +41,8 @@
 extern "C" {
 #endif

+struct gen_spec;
+
 struct intel_screen
 {
int deviceID;
@@ -103,6 +105,8 @@ struct intel_screen
 * Number of EUs reported by the I915_PARAM_EU_TOTAL parameter
 */
int eu_total;
+
+   struct gen_spec *decoder_spec;
 };

 extern void intelDestroyContext(__DRIcontext * driContextPriv);
--
2.12.0

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



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

[Mesa-dev] [PATCH] i965: Don't leak gen_spec from INTEL_DEBUG=bat handling.

[Kenneth Graunke]

We were loading the XML descriptions on every batchbuffer and leaking
them each time.  Now, we load it once at screen init time and free it
at screen destroy time.  Caught by Coverity.

CID: 1403203
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
 src/mesa/drivers/dri/i965/intel_screen.c  | 8 
 src/mesa/drivers/dri/i965/intel_screen.h  | 4 
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 49a00c12ba2..e3fb071300c 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -202,7 +202,7 @@ static void
 do_batch_dump(struct brw_context *brw)
 {
struct intel_batchbuffer *batch = >batch;
-   struct gen_spec *spec = gen_spec_load(>screen->devinfo);
+   struct gen_spec *spec = brw->screen->decoder_spec;
 
if (batch->ring != RENDER_RING)
   return;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index c7f111d04af..c8c6698a756 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -38,6 +38,7 @@
 #include "util/ralloc.h"
 #include "brw_defines.h"
 #include "compiler/nir/nir.h"
+#include "common/gen_decoder.h"
 
 #include "utils.h"
 #include "xmlpool.h"
@@ -1106,6 +1107,8 @@ intelDestroyScreen(__DRIscreen * sPriv)
dri_bufmgr_destroy(screen->bufmgr);
driDestroyOptionInfo(>optionCache);
 
+   free(screen->decoder_spec);
+
ralloc_free(screen);
sPriv->driverPrivate = NULL;
 }
@@ -1764,6 +1767,11 @@ __DRIconfig **intelInitScreen2(__DRIscreen *dri_screen)
 
brw_process_intel_debug_variable();
 
+#ifdef DEBUG
+   if (INTEL_DEBUG & DEBUG_BATCH)
+  screen->decoder_spec = gen_spec_load(devinfo);
+#endif
+
if (INTEL_DEBUG & DEBUG_BUFMGR)
   dri_bufmgr_set_debug(screen->bufmgr, true);
 
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h 
b/src/mesa/drivers/dri/i965/intel_screen.h
index d8cda58c964..29ce94d6756 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -41,6 +41,8 @@
 extern "C" {
 #endif
 
+struct gen_spec;
+
 struct intel_screen
 {
int deviceID;
@@ -103,6 +105,8 @@ struct intel_screen
 * Number of EUs reported by the I915_PARAM_EU_TOTAL parameter
 */
int eu_total;
+
+   struct gen_spec *decoder_spec;
 };
 
 extern void intelDestroyContext(__DRIcontext * driContextPriv);
-- 
2.12.0

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

Re: [Mesa-dev] [PATCH v2] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

On Thu, Mar 23, 2017 at 03:24:16PM +1100, Jonathan Gray wrote:
> Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
> for a seed first use getentropy() for systems that have a kernel
> interface to get a seed such as OpenBSD.  This interface is also
> present in other systems such as Solaris and even Linux with a recent
> version of glibc.
> 
> v2: check for/use the different header Solaris and glibc use
> 
> Signed-off-by: Jonathan Gray 

The functions should really be split for random and deterministic
as well, but that is hard to cleanup without being able to assume
arc4random or equivalent is present.

diff --git a/configure.ac b/configure.ac
index c27646ca4c..a1a62482d9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -792,6 +792,9 @@ AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES 
-DHAVE_POSIX_MEMALIGN"])
 dnl See if getentropy is available
 AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
 
+dnl See if arc4random_buf is available
+AC_CHECK_FUNC([arc4random_buf], [DEFINES="$DEFINES -DHAVE_ARC4RANDOM_BUF"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/gallium/drivers/radeon/r600_test_dma.c 
b/src/gallium/drivers/radeon/r600_test_dma.c
index 3c23b09329..0cdd24d1c0 100644
--- a/src/gallium/drivers/radeon/r600_test_dma.c
+++ b/src/gallium/drivers/radeon/r600_test_dma.c
@@ -77,7 +77,7 @@ static void set_random_pixels(struct pipe_context *ctx,
 
for (x = 0; x < size; x++) {
*ptr++ = *ptr_cpu++ =
-   
rand_xorshift128plus(seed_xorshift128plus);
+   
rand_xorshift128plus_deterministic(seed_xorshift128plus);
}
}
}
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index c613371f67..db642dae54 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -37,6 +37,10 @@
 #include 
 #endif
 
+#ifdef HAVE_ARC4RANDOM_BUF
+#include 
+#endif
+
 #include "rand_xor.h"
 
 /* Super fast random number generator.
@@ -45,7 +49,7 @@
  * to the public domain.
  */
 uint64_t
-rand_xorshift128plus(uint64_t *seed)
+rand_xorshift128plus_deterministic(uint64_t *seed)
 {
uint64_t *s = seed;
 
@@ -58,6 +62,18 @@ rand_xorshift128plus(uint64_t *seed)
return s[1] + s0;
 }
 
+uint64_t
+rand_xorshift128plus(uint64_t *seed)
+{
+#ifdef HAVE_ARC4RANDOM_BUF
+  uint64_t buf;
+  arc4random_buf(, sizeof(buf));
+  return buf;
+#else
+  return rand_xorshift128plus_deterministic(seed);
+#endif
+}
+
 void
 s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
 {
diff --git a/src/util/rand_xor.h b/src/util/rand_xor.h
index 532d549bcd..0fbf4d3a8a 100644
--- a/src/util/rand_xor.h
+++ b/src/util/rand_xor.h
@@ -31,6 +31,9 @@
 uint64_t
 rand_xorshift128plus(uint64_t *seed);
 
+uint64_t
+rand_xorshift128plus_deterministic(uint64_t *seed);
+
 void
 s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed);
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
for a seed first use getentropy() for systems that have a kernel
interface to get a seed such as OpenBSD.  This interface is also
present in other systems such as Solaris and even Linux with a recent
version of glibc.

v2: check for/use the different header Solaris and glibc use

Signed-off-by: Jonathan Gray 
---
 configure.ac|  4 
 src/util/rand_xor.c | 17 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bc9c304c8d..c27646ca4c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -756,6 +756,7 @@ fi
 AC_HEADER_MAJOR
 AC_CHECK_HEADER([xlocale.h], [DEFINES="$DEFINES -DHAVE_XLOCALE_H"])
 AC_CHECK_HEADER([sys/sysctl.h], [DEFINES="$DEFINES -DHAVE_SYS_SYSCTL_H"])
+AC_CHECK_HEADER([sys/random.h], [DEFINES="$DEFINES -DHAVE_SYS_RANDOM_H"])
 AC_CHECK_FUNC([strtof], [DEFINES="$DEFINES -DHAVE_STRTOF"])
 AC_CHECK_FUNC([mkostemp], [DEFINES="$DEFINES -DHAVE_MKOSTEMP"])
 
@@ -788,6 +789,9 @@ esac
 dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
+dnl See if getentropy is available
+AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index de05fa64b3..c613371f67 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -22,7 +22,15 @@
  *
  */
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+
+#ifdef HAVE_SYS_RANDOM_H
+#include 
+#else
+#include 
+#endif
+
+#elif defined(__linux__)
 #include 
 #include 
 #else
@@ -56,7 +64,12 @@ s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
if (!randomised_seed)
   goto fixed_seed;
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+   size_t seed_size = sizeof(uint64_t) * 2;
+   if (getentropy(seed, seed_size) == -1)
+  goto fixed_seed;
+   return;
+#elif defined(__linux__)
int fd = open("/dev/urandom", O_RDONLY);
if (fd < 0)
   goto fixed_seed;
-- 
2.12.0

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

[Mesa-dev] [RFC 12/12] anv: Enable VK_KHX_multiview and SPV_KHR_multiview

[Jason Ekstrand]

---
 src/intel/vulkan/anv_device.c   | 6 +-
 src/intel/vulkan/anv_pipeline.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 4d24e3b..c104db8 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -270,7 +270,11 @@ static const VkExtensionProperties device_extensions[] = {
{
   .extensionName = VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME,
   .specVersion = 1,
-   }
+   },
+   {
+  .extensionName = VK_KHX_MULTIVIEW_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 23815a9..8242128 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -126,6 +126,7 @@ anv_shader_compile_to_nir(struct anv_device *device,
   .tessellation = true,
   .draw_parameters = true,
   .image_write_without_format = true,
+  .multiview = true,
};
 
nir_function *entry_point =
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 10/12] anv/cmd_buffer: Pull indirect draw parameter loading into a helper

[Jason Ekstrand]

---
 src/intel/vulkan/genX_cmd_buffer.c | 34 --
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index e2364db..aafe7fd 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -1767,6 +1767,28 @@ void genX(CmdDrawIndexed)(
 #define GEN7_3DPRIM_START_INSTANCE  0x243C
 #define GEN7_3DPRIM_BASE_VERTEX 0x2440
 
+static void
+load_indirect_parameters(struct anv_cmd_buffer *cmd_buffer,
+ struct anv_buffer *buffer, uint64_t offset,
+ bool indexed)
+{
+   struct anv_batch *batch = _buffer->batch;
+   struct anv_bo *bo = buffer->bo;
+   uint32_t bo_offset = buffer->offset + offset;
+
+   emit_lrm(batch, GEN7_3DPRIM_VERTEX_COUNT, bo, bo_offset);
+   emit_lrm(batch, GEN7_3DPRIM_INSTANCE_COUNT, bo, bo_offset + 4);
+   emit_lrm(batch, GEN7_3DPRIM_START_VERTEX, bo, bo_offset + 8);
+
+   if (indexed) {
+  emit_lrm(batch, GEN7_3DPRIM_BASE_VERTEX, bo, bo_offset + 12);
+  emit_lrm(batch, GEN7_3DPRIM_START_INSTANCE, bo, bo_offset + 16);
+   } else {
+  emit_lrm(batch, GEN7_3DPRIM_START_INSTANCE, bo, bo_offset + 12);
+  emit_lri(batch, GEN7_3DPRIM_BASE_VERTEX, 0);
+   }
+}
+
 void genX(CmdDrawIndirect)(
 VkCommandBuffer commandBuffer,
 VkBuffer_buffer,
@@ -1791,11 +1813,7 @@ void genX(CmdDrawIndirect)(
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
 
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_VERTEX_COUNT, bo, bo_offset);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_INSTANCE_COUNT, bo, bo_offset + 4);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_START_VERTEX, bo, bo_offset + 8);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_START_INSTANCE, bo, bo_offset + 
12);
-   emit_lri(_buffer->batch, GEN7_3DPRIM_BASE_VERTEX, 0);
+   load_indirect_parameters(cmd_buffer, buffer, offset, false);
 
anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
   prim.IndirectParameterEnable  = true;
@@ -1829,11 +1847,7 @@ void genX(CmdDrawIndexedIndirect)(
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
 
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_VERTEX_COUNT, bo, bo_offset);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_INSTANCE_COUNT, bo, bo_offset + 4);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_START_VERTEX, bo, bo_offset + 8);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_BASE_VERTEX, bo, bo_offset + 12);
-   emit_lrm(_buffer->batch, GEN7_3DPRIM_START_INSTANCE, bo, bo_offset + 
16);
+   load_indirect_parameters(cmd_buffer, buffer, offset, true);
 
anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
   prim.IndirectParameterEnable  = true;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 11/12] anv/cmd_buffer: Emit instanced draws for multiple views

[Jason Ekstrand]

---
 src/intel/vulkan/anv_private.h |   6 ++
 src/intel/vulkan/genX_cmd_buffer.c | 141 -
 src/intel/vulkan/genX_pipeline.c   |  10 ++-
 3 files changed, 152 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index b402bc3..253dce2 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1980,6 +1980,12 @@ struct anv_subpass {
bool has_resolve;
 };
 
+static inline unsigned
+anv_subpass_view_count(const struct anv_subpass *subpass)
+{
+   return MAX2(1, _mesa_bitcount(subpass->view_mask));
+}
+
 enum anv_subpass_usage {
ANV_SUBPASS_USAGE_DRAW = (1 << 0),
ANV_SUBPASS_USAGE_INPUT =(1 << 1),
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index aafe7fd..8c21c33 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -26,6 +26,7 @@
 
 #include "anv_private.h"
 #include "vk_format_info.h"
+#include "util/vk_util.h"
 
 #include "common/gen_l3_config.h"
 #include "genxml/gen_macros.h"
@@ -50,6 +51,17 @@ emit_lri(struct anv_batch *batch, uint32_t reg, uint32_t imm)
}
 }
 
+#if GEN_IS_HASWELL || GEN_GEN >= 8
+static void
+emit_lrr(struct anv_batch *batch, uint32_t dst, uint32_t src)
+{
+   anv_batch_emit(batch, GENX(MI_LOAD_REGISTER_REG), lrr) {
+  lrr.SourceRegisterAddress= src;
+  lrr.DestinationRegisterAddress   = dst;
+   }
+}
+#endif
+
 void
 genX(cmd_buffer_emit_state_base_address)(struct anv_cmd_buffer *cmd_buffer)
 {
@@ -1525,7 +1537,13 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer 
*cmd_buffer)
 .MemoryObjectControlState = GENX(MOCS),
 #else
 .BufferAccessType = pipeline->instancing_enable[vb] ? INSTANCEDATA 
: VERTEXDATA,
-.InstanceDataStepRate = 1,
+/* Our implementation of VK_KHR_multiview uses instancing to draw
+ * the different views.  If the client asks for instancing, we
+ * need to use the Instance Data Step Rate to ensure that we
+ * repeat the client's per-instance data once for each view.
+ */
+.InstanceDataStepRate =
+   _mesa_bitcount(pipeline->subpass->view_mask),
 .VertexBufferMemoryObjectControlState = GENX(MOCS),
 #endif
 
@@ -1715,6 +1733,11 @@ void genX(CmdDraw)(
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
 
+   /* Our implementation of VK_KHR_multiview uses instancing to draw the
+* different views.  We need to multiply instanceCount by the view count.
+*/
+   instanceCount *= anv_subpass_view_count(cmd_buffer->state.subpass);
+
anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
   prim.VertexAccessType = SEQUENTIAL;
   prim.PrimitiveTopologyType= pipeline->topology;
@@ -1748,6 +1771,11 @@ void genX(CmdDrawIndexed)(
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
 
+   /* Our implementation of VK_KHR_multiview uses instancing to draw the
+* different views.  We need to multiply instanceCount by the view count.
+*/
+   instanceCount *= anv_subpass_view_count(cmd_buffer->state.subpass);
+
anv_batch_emit(_buffer->batch, GENX(3DPRIMITIVE), prim) {
   prim.VertexAccessType = RANDOM;
   prim.PrimitiveTopologyType= pipeline->topology;
@@ -1767,6 +1795,90 @@ void genX(CmdDrawIndexed)(
 #define GEN7_3DPRIM_START_INSTANCE  0x243C
 #define GEN7_3DPRIM_BASE_VERTEX 0x2440
 
+/* MI_MATH only exists on Haswell+ */
+#if GEN_IS_HASWELL || GEN_GEN >= 8
+
+#define alu_opcode(v)   __gen_uint((v),  20, 31)
+#define alu_operand1(v) __gen_uint((v),  10, 19)
+#define alu_operand2(v) __gen_uint((v),   0,  9)
+#define alu(opcode, operand1, operand2) \
+   alu_opcode(opcode) | alu_operand1(operand1) | alu_operand2(operand2)
+
+#define OPCODE_NOOP  0x000
+#define OPCODE_LOAD  0x080
+#define OPCODE_LOADINV   0x480
+#define OPCODE_LOAD0 0x081
+#define OPCODE_LOAD1 0x481
+#define OPCODE_ADD   0x100
+#define OPCODE_SUB   0x101
+#define OPCODE_AND   0x102
+#define OPCODE_OR0x103
+#define OPCODE_XOR   0x104
+#define OPCODE_STORE 0x180
+#define OPCODE_STOREINV  0x580
+
+#define OPERAND_R0   0x00
+#define OPERAND_R1   0x01
+#define OPERAND_R2   0x02
+#define OPERAND_R3   0x03
+#define OPERAND_R4   0x04
+#define OPERAND_SRCA 0x20
+#define OPERAND_SRCB 0x21
+#define OPERAND_ACCU 0x31
+#define OPERAND_ZF   0x32
+#define OPERAND_CF   0x33
+
+#define CS_GPR(n) (0x2600 + (n) * 8)
+
+/* Emit dwords to multiply GPR0 by N */
+static void
+build_alu_multiply_gpr0(uint32_t *dw, unsigned *dw_count, uint32_t N)
+{
+   VK_OUTARRAY_MAKE(out, dw, dw_count);
+
+#define append_alu(opcode, operand1, operand2) \
+   vk_outarray_append(, alu_dw) *alu_dw = alu(opcode, operand1, operand2)
+
+   assert(N > 0);
+   unsigned top_bit = 31 - 

[Mesa-dev] [RFC 09/12] anv/pipeline: Add shader lowering for multiview

[Jason Ekstrand]

---
 src/intel/Makefile.sources |   1 +
 src/intel/vulkan/anv_nir.h |   2 +
 src/intel/vulkan/anv_nir_lower_multiview.c | 235 +
 src/intel/vulkan/anv_pipeline.c|   2 +
 4 files changed, 240 insertions(+)
 create mode 100644 src/intel/vulkan/anv_nir_lower_multiview.c

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 839ea47..51cf482 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -180,6 +180,7 @@ VULKAN_FILES := \
vulkan/anv_nir.h \
vulkan/anv_nir_apply_pipeline_layout.c \
vulkan/anv_nir_lower_input_attachments.c \
+   vulkan/anv_nir_lower_multiview.c \
vulkan/anv_nir_lower_push_constants.c \
vulkan/anv_pass.c \
vulkan/anv_pipeline.c \
diff --git a/src/intel/vulkan/anv_nir.h b/src/intel/vulkan/anv_nir.h
index 3f97701..5d3fbfd 100644
--- a/src/intel/vulkan/anv_nir.h
+++ b/src/intel/vulkan/anv_nir.h
@@ -35,6 +35,8 @@ void anv_nir_lower_input_attachments(nir_shader *shader);
 
 void anv_nir_lower_push_constants(nir_shader *shader);
 
+bool anv_nir_lower_multiview(nir_shader *shader, struct anv_subpass *subpass);
+
 void anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
nir_shader *shader,
struct brw_stage_prog_data *prog_data,
diff --git a/src/intel/vulkan/anv_nir_lower_multiview.c 
b/src/intel/vulkan/anv_nir_lower_multiview.c
new file mode 100644
index 000..933d6d7
--- /dev/null
+++ b/src/intel/vulkan/anv_nir_lower_multiview.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "anv_nir.h"
+#include "nir/nir_builder.h"
+
+/**
+ * This file implements the lowering required for VK_KHR_multiview.  We
+ * implement multiview using instanced rendering.  The number of instances in
+ * each draw call is multiplied by the number of views in the subpass.  Then,
+ * in the shader, we divide gl_InstanceId by the number of views and use
+ * gl_InstanceId % view_count to compute the actual ViewIndex.
+ */
+
+struct lower_multiview_state {
+   nir_builder builder;
+
+   struct anv_subpass *subpass;
+
+   nir_ssa_def *instance_id;
+   nir_ssa_def *view_index;
+};
+
+static nir_ssa_def *
+build_instance_id(struct lower_multiview_state *state)
+{
+   assert(state->builder.shader->stage == MESA_SHADER_VERTEX);
+
+   if (state->instance_id == NULL) {
+  nir_builder *b = >builder;
+
+  b->cursor = nir_before_block(nir_start_block(b->impl));
+
+  /* We use instancing for implementing multiview.  The actual instance id
+   * is given by dividing instance_id by the number of views in this
+   * subpass.
+   */
+  state->instance_id =
+ nir_idiv(b, nir_load_instance_id(b),
+ nir_imm_int(b, 
_mesa_bitcount(state->subpass->view_mask)));
+   }
+
+   return state->instance_id;
+}
+
+static nir_ssa_def *
+build_view_index(struct lower_multiview_state *state)
+{
+   if (state->view_index == NULL) {
+  nir_builder *b = >builder;
+
+  b->cursor = nir_before_block(nir_start_block(b->impl));
+
+  if (0 && anv_subpass_view_count(state->subpass) == 1) {
+ state->view_index = nir_imm_int(b, 0);
+  } else if (state->builder.shader->stage == MESA_SHADER_VERTEX) {
+ uint32_t view_mask = state->subpass->view_mask;
+
+ /* We only support 16 viewports */
+ assert((view_mask & 0x) == 0);
+
+ /* We use instancing for implementing multiview.  The compacted view
+  * id is given by instance_id % view_count.  We then have to convert
+  * that to an actual view id.
+  */
+ nir_ssa_def *compacted =
+nir_umod(b, nir_load_instance_id(b),
+nir_imm_int(b, _mesa_bitcount(view_mask)));

[Mesa-dev] [RFC 06/12] anv/pass: Store the per-subpass view mask

[Jason Ekstrand]

---
 src/intel/vulkan/anv_pass.c| 19 +++
 src/intel/vulkan/anv_private.h |  2 ++
 2 files changed, 21 insertions(+)

diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index 4a1a340..42321db 100644
--- a/src/intel/vulkan/anv_pass.c
+++ b/src/intel/vulkan/anv_pass.c
@@ -23,6 +23,8 @@
 
 #include "anv_private.h"
 
+#include "util/vk_util.h"
+
 VkResult anv_CreateRenderPass(
 VkDevice_device,
 const VkRenderPassCreateInfo*   pCreateInfo,
@@ -111,6 +113,7 @@ VkResult anv_CreateRenderPass(
   subpass->input_count = desc->inputAttachmentCount;
   subpass->color_count = desc->colorAttachmentCount;
   subpass->attachments = p;
+  subpass->view_mask = 0;
 
   if (desc->inputAttachmentCount > 0) {
  subpass->input_attachments = p;
@@ -186,6 +189,22 @@ VkResult anv_CreateRenderPass(
   }
}
 
+   vk_foreach_struct(ext, pCreateInfo->pNext) {
+  switch (ext->sType) {
+  case VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHX: {
+ VkRenderPassMultiviewCreateInfoKHX *mv = (void *)ext;
+
+ for (uint32_t i = 0; i < mv->subpassCount; i++) {
+pass->subpasses[i].view_mask = mv->pViewMasks[i];
+ }
+ break;
+  }
+
+  default:
+ anv_debug_ignored_stype(ext->sType);
+  }
+   }
+
*pRenderPass = anv_render_pass_to_handle(pass);
 
return VK_SUCCESS;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index fd82ce9..d578c69 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1970,6 +1970,8 @@ struct anv_subpass {
 
VkAttachmentReferencedepth_stencil_attachment;
 
+   uint32_t view_mask;
+
/** Subpass has a depth/stencil self-dependency */
bool has_ds_self_dep;
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 08/12] anv/pipeline: Add a subpass field to anv_pipeline

[Jason Ekstrand]

This simplifies the code a variety of places.
---
 src/intel/vulkan/anv_pipeline.c | 12 +++-
 src/intel/vulkan/anv_private.h  |  1 +
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 8d7cc3e..9a6eae0 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -277,7 +277,6 @@ populate_wm_prog_key(const struct anv_pipeline *pipeline,
  struct brw_wm_prog_key *key)
 {
const struct gen_device_info *devinfo = >device->info;
-   ANV_FROM_HANDLE(anv_render_pass, render_pass, info->renderPass);
 
memset(key, 0, sizeof(*key));
 
@@ -295,8 +294,7 @@ populate_wm_prog_key(const struct anv_pipeline *pipeline,
/* XXX Vulkan doesn't appear to specify */
key->clamp_fragment_color = false;
 
-   key->nr_color_regions =
-  render_pass->subpasses[info->subpass].color_count;
+   key->nr_color_regions = pipeline->subpass->color_count;
 
key->replicate_alpha = key->nr_color_regions > 1 &&
   info->pMultisampleState &&
@@ -987,8 +985,7 @@ copy_non_dynamic_state(struct anv_pipeline *pipeline,
const VkGraphicsPipelineCreateInfo *pCreateInfo)
 {
anv_cmd_dirty_mask_t states = ANV_CMD_DIRTY_DYNAMIC_ALL;
-   ANV_FROM_HANDLE(anv_render_pass, pass, pCreateInfo->renderPass);
-   struct anv_subpass *subpass = >subpasses[pCreateInfo->subpass];
+   struct anv_subpass *subpass = pipeline->subpass;
 
pipeline->dynamic_state = default_dynamic_state;
 
@@ -1191,6 +1188,11 @@ anv_pipeline_init(struct anv_pipeline *pipeline,
   alloc = >alloc;
 
pipeline->device = device;
+
+   ANV_FROM_HANDLE(anv_render_pass, render_pass, pCreateInfo->renderPass);
+   assert(pCreateInfo->subpass < render_pass->subpass_count);
+   pipeline->subpass = _pass->subpasses[pCreateInfo->subpass];
+
pipeline->layout = anv_pipeline_layout_from_handle(pCreateInfo->layout);
 
result = anv_reloc_list_init(>batch_relocs, alloc);
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index d578c69..b402bc3 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1605,6 +1605,7 @@ struct anv_pipeline {
uint32_t dynamic_state_mask;
struct anv_dynamic_state dynamic_state;
 
+   struct anv_subpass * subpass;
struct anv_pipeline_layout * layout;
 
bool needs_data_cache;
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 07/12] anv/pipeline: Call nir_gather_info later

[Jason Ekstrand]

We want to insert more lowering code that may insert system values and
we need to gather info after that lowering.
---
 src/intel/vulkan/anv_pipeline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 23274ef..8d7cc3e 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -179,8 +179,6 @@ anv_shader_compile_to_nir(struct anv_device *device,
if (stage == MESA_SHADER_FRAGMENT)
   NIR_PASS_V(nir, anv_nir_lower_input_attachments);
 
-   nir_shader_gather_info(nir, entry_point->impl);
-
return nir;
 }
 
@@ -341,6 +339,8 @@ anv_pipeline_compile(struct anv_pipeline *pipeline,
 
NIR_PASS_V(nir, anv_nir_lower_push_constants);
 
+   nir_shader_gather_info(nir, nir_shader_get_entrypoint(nir));
+
/* Figure out the number of parameters */
prog_data->nr_params = 0;
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 05/12] anv: Add the KHX_multiview boilerplate

[Jason Ekstrand]

---
 src/intel/vulkan/anv_device.c   | 17 +
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 2 files changed, 18 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index bbf7a38..4d24e3b 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -513,6 +513,15 @@ void anv_GetPhysicalDeviceFeatures2KHR(
 
vk_foreach_struct(ext, pFeatures->pNext) {
   switch (ext->sType) {
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHX: {
+ VkPhysicalDeviceMultiviewFeaturesKHX *features =
+(VkPhysicalDeviceMultiviewFeaturesKHX *)ext;
+ features->multiview = true;
+ features->multiviewGeometryShader = true;
+ features->multiviewTessellationShader = true;
+ break;
+  }
+
   default:
  anv_debug_ignored_stype(ext->sType);
  break;
@@ -677,6 +686,14 @@ void anv_GetPhysicalDeviceProperties2KHR(
  break;
   }
 
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHX: {
+ VkPhysicalDeviceMultiviewPropertiesKHX *properties =
+(VkPhysicalDeviceMultiviewPropertiesKHX *)ext;
+ properties->maxMultiviewViewCount = 16;
+ properties->maxMultiviewInstanceIndex = UINT32_MAX / 16;
+ break;
+  }
+
   default:
  anv_debug_ignored_stype(ext->sType);
  break;
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index 203df45..22b8e04 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -44,6 +44,7 @@ SUPPORTED_EXTENSIONS = [
 'VK_KHR_wayland_surface',
 'VK_KHR_xcb_surface',
 'VK_KHR_xlib_surface',
+'VK_KHX_multiview',
 ]
 
 # We generate a static hash table for entry point lookup
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 03/12] spirv: Add support for SPV_KHR_multiview

[Jason Ekstrand]

---
 src/compiler/spirv/nir_spirv.h | 1 +
 src/compiler/spirv/spirv_to_nir.c  | 4 
 src/compiler/spirv/vtn_variables.c | 4 
 3 files changed, 9 insertions(+)

diff --git a/src/compiler/spirv/nir_spirv.h b/src/compiler/spirv/nir_spirv.h
index 1779d1c..7f16866 100644
--- a/src/compiler/spirv/nir_spirv.h
+++ b/src/compiler/spirv/nir_spirv.h
@@ -50,6 +50,7 @@ struct nir_spirv_supported_extensions {
bool image_read_without_format;
bool image_write_without_format;
bool int64;
+   bool multiview;
 };
 
 nir_function *spirv_to_nir(const uint32_t *words, size_t word_count,
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index d3ad2d1..c120ad6 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2730,6 +2730,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(image_write_without_format, cap);
  break;
 
+  case SpvCapabilityMultiView:
+ spv_check_supported(multiview, cap);
+ break;
+
   default:
  unreachable("Unhandled capability");
   }
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 293d07d..365e562 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1036,6 +1036,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
   *location = SYSTEM_VALUE_DRAW_ID;
   set_mode_system_value(mode);
   break;
+   case SpvBuiltInViewIndex:
+  *location = SYSTEM_VALUE_VIEW_INDEX;
+  set_mode_system_value(mode);
+  break;
case SpvBuiltInHelperInvocation:
default:
   unreachable("unsupported builtin");
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 04/12] anv/nir: Delete the apply_dynamic_offsets prototype

[Jason Ekstrand]

That pass hasn't existed since dd4db84640bbb694f180dd50850c3388f67228be
but the prototype stuck around for no reason.
---
 src/intel/vulkan/anv_nir.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/intel/vulkan/anv_nir.h b/src/intel/vulkan/anv_nir.h
index a929dd9..3f97701 100644
--- a/src/intel/vulkan/anv_nir.h
+++ b/src/intel/vulkan/anv_nir.h
@@ -35,9 +35,6 @@ void anv_nir_lower_input_attachments(nir_shader *shader);
 
 void anv_nir_lower_push_constants(nir_shader *shader);
 
-void anv_nir_apply_dynamic_offsets(struct anv_pipeline *pipeline,
-   nir_shader *shader,
-   struct brw_stage_prog_data *prog_data);
 void anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
nir_shader *shader,
struct brw_stage_prog_data *prog_data,
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 02/12] spirv: Bump the SPIR-V header to the latest public version

[Jason Ekstrand]

---
 src/compiler/spirv/spirv.h | 34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv.h b/src/compiler/spirv/spirv.h
index 769c102..89354c0 100644
--- a/src/compiler/spirv/spirv.h
+++ b/src/compiler/spirv/spirv.h
@@ -1,5 +1,5 @@
 /*
-** Copyright (c) 2014-2016 The Khronos Group Inc.
+** Copyright (c) 2014-2017 The Khronos Group Inc.
 ** 
 ** Permission is hereby granted, free of charge, to any person obtaining a copy
 ** of this software and/or associated documentation files (the "Materials"),
@@ -51,11 +51,11 @@
 typedef unsigned int SpvId;
 
 #define SPV_VERSION 0x10100
-#define SPV_REVISION 4
+#define SPV_REVISION 6
 
 static const unsigned int SpvMagicNumber = 0x07230203;
 static const unsigned int SpvVersion = 0x00010100;
-static const unsigned int SpvRevision = 4;
+static const unsigned int SpvRevision = 6;
 static const unsigned int SpvOpCodeMask = 0x;
 static const unsigned int SpvWordCountShift = 16;
 
@@ -383,6 +383,10 @@ typedef enum SpvDecoration_ {
 SpvDecorationInputAttachmentIndex = 43,
 SpvDecorationAlignment = 44,
 SpvDecorationMaxByteOffset = 45,
+SpvDecorationOverrideCoverageNV = 5248,
+SpvDecorationPassthroughNV = 5250,
+SpvDecorationViewportRelativeNV = 5252,
+SpvDecorationSecondaryViewportRelativeNV = 5256,
 SpvDecorationMax = 0x7fff,
 } SpvDecoration;
 
@@ -436,6 +440,13 @@ typedef enum SpvBuiltIn_ {
 SpvBuiltInBaseVertex = 4424,
 SpvBuiltInBaseInstance = 4425,
 SpvBuiltInDrawIndex = 4426,
+SpvBuiltInDeviceIndex = 4438,
+SpvBuiltInViewIndex = 4440,
+SpvBuiltInViewportMaskNV = 5253,
+SpvBuiltInSecondaryPositionNV = 5257,
+SpvBuiltInSecondaryViewportMaskNV = 5258,
+SpvBuiltInPositionPerViewNV = 5261,
+SpvBuiltInViewportMaskPerViewNV = 5262,
 SpvBuiltInMax = 0x7fff,
 } SpvBuiltIn;
 
@@ -620,6 +631,19 @@ typedef enum SpvCapability_ {
 SpvCapabilityPipeStorage = 60,
 SpvCapabilitySubgroupBallotKHR = 4423,
 SpvCapabilityDrawParameters = 4427,
+SpvCapabilitySubgroupVoteKHR = 4431,
+SpvCapabilityStorageUniformBufferBlock16 = 4433,
+SpvCapabilityStorageUniform16 = 4434,
+SpvCapabilityStoragePushConstant16 = 4435,
+SpvCapabilityStorageInputOutput16 = 4436,
+SpvCapabilityDeviceGroup = 4437,
+SpvCapabilityMultiView = 4439,
+SpvCapabilitySampleMaskOverrideCoverageNV = 5249,
+SpvCapabilityGeometryShaderPassthroughNV = 5251,
+SpvCapabilityShaderViewportIndexLayerNV = 5254,
+SpvCapabilityShaderViewportMaskNV = 5255,
+SpvCapabilityShaderStereoViewNV = 5259,
+SpvCapabilityPerViewAttributesNV = 5260,
 SpvCapabilityMax = 0x7fff,
 } SpvCapability;
 
@@ -930,6 +954,10 @@ typedef enum SpvOp_ {
 SpvOpModuleProcessed = 330,
 SpvOpSubgroupBallotKHR = 4421,
 SpvOpSubgroupFirstInvocationKHR = 4422,
+SpvOpSubgroupAllKHR = 4428,
+SpvOpSubgroupAnyKHR = 4429,
+SpvOpSubgroupAllEqualKHR = 4430,
+SpvOpSubgroupReadInvocationKHR = 4432,
 SpvOpMax = 0x7fff,
 } SpvOp;
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 01/12] compiler: Add a system value and varying for ViewIndex

[Jason Ekstrand]

---
 src/compiler/nir/nir.c| 4 
 src/compiler/nir/nir_intrinsics.h | 1 +
 src/compiler/shader_enums.c   | 2 ++
 src/compiler/shader_enums.h   | 4 
 4 files changed, 11 insertions(+)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 937b630..39a74a2 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1903,6 +1903,8 @@ nir_intrinsic_from_system_value(gl_system_value val)
   return nir_intrinsic_load_patch_vertices_in;
case SYSTEM_VALUE_HELPER_INVOCATION:
   return nir_intrinsic_load_helper_invocation;
+   case SYSTEM_VALUE_VIEW_INDEX:
+  return nir_intrinsic_load_view_index;
default:
   unreachable("system value does not directly correspond to intrinsic");
}
@@ -1954,6 +1956,8 @@ nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
   return SYSTEM_VALUE_VERTICES_IN;
case nir_intrinsic_load_helper_invocation:
   return SYSTEM_VALUE_HELPER_INVOCATION;
+   case nir_intrinsic_load_view_index:
+  return SYSTEM_VALUE_VIEW_INDEX;
default:
   unreachable("intrinsic doesn't produce a system value");
}
diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index 105c56f..6a38865 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -329,6 +329,7 @@ SYSTEM_VALUE(helper_invocation, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(channel_num, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(alpha_ref_float, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(layer_id, 1, 0, xx, xx, xx)
+SYSTEM_VALUE(view_index, 1, 0, xx, xx, xx)
 
 /* Blend constant color values.  Float values are clamped. */
 SYSTEM_VALUE(blend_const_color_r_float, 1, 0, xx, xx, xx)
diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index e704c95..1539dbf 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -162,6 +162,7 @@ gl_varying_slot_name(gl_varying_slot slot)
   ENUM(VARYING_SLOT_TESS_LEVEL_INNER),
   ENUM(VARYING_SLOT_BOUNDING_BOX0),
   ENUM(VARYING_SLOT_BOUNDING_BOX1),
+  ENUM(VARYING_SLOT_VIEW_INDEX),
   ENUM(VARYING_SLOT_VAR0),
   ENUM(VARYING_SLOT_VAR1),
   ENUM(VARYING_SLOT_VAR2),
@@ -225,6 +226,7 @@ gl_system_value_name(gl_system_value sysval)
  ENUM(SYSTEM_VALUE_GLOBAL_INVOCATION_ID),
  ENUM(SYSTEM_VALUE_WORK_GROUP_ID),
  ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
+ ENUM(SYSTEM_VALUE_VIEW_INDEX),
  ENUM(SYSTEM_VALUE_VERTEX_CNT),
};
STATIC_ASSERT(ARRAY_SIZE(names) == SYSTEM_VALUE_MAX);
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index 98565c8..a4668a7 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -217,6 +217,7 @@ typedef enum
VARYING_SLOT_TESS_LEVEL_INNER, /* Only appears as TCS output. */
VARYING_SLOT_BOUNDING_BOX0, /* Only appears as TCS output. */
VARYING_SLOT_BOUNDING_BOX1, /* Only appears as TCS output. */
+   VARYING_SLOT_VIEW_INDEX,
VARYING_SLOT_VAR0, /* First generic varying slot */
/* the remaining are simply for the benefit of gl_varying_slot_name()
 * and not to be construed as an upper bound:
@@ -476,6 +477,9 @@ typedef enum
SYSTEM_VALUE_LOCAL_GROUP_SIZE,
/*@}*/
 
+   /** Required for VK_KHX_multiview */
+   SYSTEM_VALUE_VIEW_INDEX,
+
/**
 * Driver internal vertex-count, used (for example) for drivers to
 * calculate stride for stream-out outputs.  Not externally visible.
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [RFC 00/12] anv: A first pass at VK_KHX_multiview

[Jason Ekstrand]

This little series is a first pass at implementing the VK_KHX_multiview
extension.  The basic method employed is to multiply the number of
instances in each draw call by the number of views in the subpass.  We then
emit shader code to sort out the gl_InstanceId and gl_ViewIndex builtin
variables.  Properly computing gl_ViewIndex takes a bit of work because
gl_InstanceId % bitcount(subpass->view_mask) is not quite the view index we
want.  We have to convert from this "compacted" view index to the actual
view index by use of a remap table.

This implementation is good enough to get us going with the extension and
passes the currently available CTS tests.  However, it does not yet support
input attachments.

Jason Ekstrand (12):
  compiler: Add a system value and varying for ViewIndex
  spirv: Bump the SPIR-V header to the latest public version
  spirv: Add support for SPV_KHR_multiview
  anv/nir: Delete the apply_dynamic_offsets prototype
  anv: Add the KHX_multiview boilerplate
  anv/pass: Store the per-subpass view mask
  anv/pipeline: Call nir_gather_info later
  anv/pipeline: Add a subpass field to anv_pipeline
  anv/pipeline: Add shader lowering for multiview
  anv/cmd_buffer: Pull indirect draw parameter loading into a helper
  anv/cmd_buffer: Emit instanced draws for multiple views
  anv: Enable VK_KHX_multiview and SPV_KHR_multiview

 src/compiler/nir/nir.c |   4 +
 src/compiler/nir/nir_intrinsics.h  |   1 +
 src/compiler/shader_enums.c|   2 +
 src/compiler/shader_enums.h|   4 +
 src/compiler/spirv/nir_spirv.h |   1 +
 src/compiler/spirv/spirv.h |  34 -
 src/compiler/spirv/spirv_to_nir.c  |   4 +
 src/compiler/spirv/vtn_variables.c |   4 +
 src/intel/Makefile.sources |   1 +
 src/intel/vulkan/anv_device.c  |  23 ++-
 src/intel/vulkan/anv_entrypoints_gen.py|   1 +
 src/intel/vulkan/anv_nir.h |   5 +-
 src/intel/vulkan/anv_nir_lower_multiview.c | 235 +
 src/intel/vulkan/anv_pass.c|  19 +++
 src/intel/vulkan/anv_pipeline.c|  19 ++-
 src/intel/vulkan/anv_private.h |   9 ++
 src/intel/vulkan/genX_cmd_buffer.c | 173 +++--
 src/intel/vulkan/genX_pipeline.c   |  10 +-
 18 files changed, 521 insertions(+), 28 deletions(-)
 create mode 100644 src/intel/vulkan/anv_nir_lower_multiview.c

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 99856] OpenCL Hello world returns "unsupported call to function get_local_size"

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Blocks||99553


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] util/rand_xor: seed with getentropy when available

[Jonathan Gray]

Instead of using using /dev/urandom on Linux and time(NULL) elsewhere
for a seed first use getentropy() for systems that have a kernel
interface to get a seed such as OpenBSD.  This interface is also
present in other systems such as Solaris and even Linux with a recent
version of glibc.

Signed-off-by: Jonathan Gray 
---
 configure.ac|  3 +++
 src/util/rand_xor.c | 11 +--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index bc9c304c8d..1a2f58feaf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -788,6 +788,9 @@ esac
 dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
+dnl See if getentropy is available
+AC_CHECK_FUNC([getentropy], [DEFINES="$DEFINES -DHAVE_GETENTROPY"])
+
 dnl Check for zlib
 PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
 
diff --git a/src/util/rand_xor.c b/src/util/rand_xor.c
index de05fa64b3..b71492b8fd 100644
--- a/src/util/rand_xor.c
+++ b/src/util/rand_xor.c
@@ -22,7 +22,9 @@
  *
  */
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+#include 
+#elif defined(__linux__)
 #include 
 #include 
 #else
@@ -56,7 +58,12 @@ s_rand_xorshift128plus(uint64_t *seed, bool randomised_seed)
if (!randomised_seed)
   goto fixed_seed;
 
-#if defined(__linux__)
+#ifdef HAVE_GETENTROPY
+   size_t seed_size = sizeof(uint64_t) * 2;
+   if (getentropy(seed, seed_size) == -1)
+  goto fixed_seed;
+   return;
+#elif defined(__linux__)
int fd = open("/dev/urandom", O_RDONLY);
if (fd < 0)
   goto fixed_seed;
-- 
2.12.0

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

Re: [Mesa-dev] [llvm] r298336 - Fix evaluation of LLVM_DEFINITIONS

[Michel Dänzer]

On 22/03/17 09:20 PM, Serge Pavlov wrote:
> Hi Michel,
> 
> Thank you for analysis. Should be fixed in r298498.

Indeed, it's fixed, thanks!


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
>> > I guess I'm a little late to the party here, but I haven't had time to
>> > really let all of this sink in and actually look at meson.  It doesn't
>> > seem so bad with a quick look and I think I could probably sort it out
>> > when the time came, but there would still be a bit of a learning
>> > curve.  While that may not be a big deal at the micro level, I have
>> > concerns at the macro level.
>> >
>> > First, I'm concerned it may discourage casual developers and
>> > packagers.  autotools isn't great, but most people are familiar enough
>> > with it that they can get by.  Most people have enough knowledge of
>> > autotools that they can pretty easily diagnose a configuration based
>> > failure. There are a lot of resources for autotools.  I'm not sure
>> > that would be the case for meson.  Do we as a community feel we have
>> > enough meson experience to get people over the hump?  Anything that
>> > makes it harder for someone to try a new build or do a bisect is a big
>> > problem in my opinion.
>>
>> One of the things that's prompted this on our side (I've talked this over 
>> with
>> other people at Intel before starting), was that clearly we *don't* know
>> autotools well enough to get it right. Emil almost always finds cases were 
>> we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same logic.
>>
>> > Next, my bigger concern is for distro and casual packagers and people
>> > that maintain large build systems with lots of existing custom
>> > configurations.  Changing from autotools would basically require many
>> > of these existing tools and systems to be rewritten and then deal with
>> > the debugging and fall out from that.  The potential decreased build
>> > time is a nice bonus, but frankly a lot of people/companies have years
>> > of investment in existing tools.
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is using it
>> already, libepoxy is using it, gstreamer is using it. There are patches for
>> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
>> there
>> are some other projects in the graphics sphere that people are working on. So
>> even if we as a community decide that meson isn't for us, it's not going 
>> away.
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack.  In the case of libepoxy it was added by a new maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>

but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> > I guess I'm a little late to the party here, but I haven't had time to
> > really let all of this sink in and actually look at meson.  It doesn't
> > seem so bad with a quick look and I think I could probably sort it out
> > when the time came, but there would still be a bit of a learning
> > curve.  While that may not be a big deal at the micro level, I have
> > concerns at the macro level.
> >
> > First, I'm concerned it may discourage casual developers and
> > packagers.  autotools isn't great, but most people are familiar enough
> > with it that they can get by.  Most people have enough knowledge of
> > autotools that they can pretty easily diagnose a configuration based
> > failure. There are a lot of resources for autotools.  I'm not sure
> > that would be the case for meson.  Do we as a community feel we have
> > enough meson experience to get people over the hump?  Anything that
> > makes it harder for someone to try a new build or do a bisect is a big
> > problem in my opinion.
> 
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases were 
> we've
> done things *almost*, but not quite right.
> 
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic. 
> 
> > Next, my bigger concern is for distro and casual packagers and people
> > that maintain large build systems with lots of existing custom
> > configurations.  Changing from autotools would basically require many
> > of these existing tools and systems to be rewritten and then deal with
> > the debugging and fall out from that.  The potential decreased build
> > time is a nice bonus, but frankly a lot of people/companies have years
> > of investment in existing tools.
> 
> Sure, but we're also not the only ones investigating meson. Gnome is using it
> already, libepoxy is using it, gstreamer is using it. There are patches for
> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
> there
> are some other projects in the graphics sphere that people are working on. So
> even if we as a community decide that meson isn't for us, it's not going away.

It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.

> 
> Quoting Rob Clark (2017-03-22 10:07:54)
> > I guess an interesting question (from someone who doesn't know meson
> > yet) would be whether meson could slurp in the Makefile.sources type
> > stuff that we have, which are shared so far between
> > android/scons/autotools (and for the most part, kept developers from
> > having to care *too* much about the different build systems)
> 
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
> 
> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
> 
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
> 
> [1] https://godoc.org/github.com/google/blueprint
> > 
> > If so, that makes it easier to coexist with existing build systems.  I
> > don't think it would be a good idea to remove the autotools build
> > anytime soon.. that should be the last one removed, after meson has
> > replaced scons (and hopefully android?)
> 
> I would imagine that if we did merge meson, we would make at the very least 
> one
> release with meson and autotools (scons is VMWare's thing, they can migrate at
> their leisure), if not two, to 

Re: [Mesa-dev] [PATCH] glsl: Link tests with CLOCK_LIB.

[Matt Turner]

On Wed, Mar 22, 2017 at 5:02 PM, Vinson Lee  wrote:
> I don't think this is a CentOS 6 specific issue but an issue with
> older GCC, such as GCC 4.4.

glibc 2.17 and newer have clock_gettime in libc, and 2.16 and older
have it in librt.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/9] genxml: New generated header genX_bits.h (v2)

[Chad Versace]

genX_bits.h contains the sizes of bitfields in genxml instructions,
structures, and registers. It also defines some functions to query those
sizes.

isl_surf_init() will use the new header to validate that requested
pitches fit in their destination bitfields.

What's currently in genX_bits.h:

  - For each CONTAINER::Field in gen{n}.xml whose name matches
/.*Surface(Q?)Pitch_bits$/, genX_bits.h contains the line:

  #define GEN{n}_CONTAINER_Field_bits {number of bits in field}

STREAMOUT fields are omitted because isl doesn't care about them.

  - For each set of macros whose name, after stripping the GEN prefix,
is the same, genX_bits.h contains the query function:

  static inline uint32_t __attribute__((const))
  CONTAINER_Field_bits(int gen_10x)
  {
 switch (gen_10x) {
 case {n0}: return GEN{n0}_CONTAINER_Field_bits;
 case {n1}: return GEN{n1}_CONTAINER_Field_bits;
 ...
 default: return 0;
  }

v2: Parse the XML instead of scraping the generated gen*_pack.h headers.
[for jekstrand]

Jason and I tentatively agreed that I should just hand-write the
header. But my conscience refused. The XML way is the right way.
Anyway, the generator script are about the same number of lines (259
vs 222), so the generator is the clear winner in my opinion.
---
 src/intel/Makefile.genxml.am|   6 +-
 src/intel/Makefile.sources  |   6 +-
 src/intel/genxml/.gitignore |   1 +
 src/intel/genxml/gen_bits_header.py | 259 
 4 files changed, 270 insertions(+), 2 deletions(-)
 create mode 100644 src/intel/genxml/gen_bits_header.py

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 01a02b63b44..4e59a918618 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -30,7 +30,7 @@ EXTRA_DIST += \
 
 SUFFIXES = _pack.h _xml.h .xml
 
-$(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
+$(GENXML_GENERATED_PACK_FILES): genxml/gen_pack_header.py
 
 .xml_pack.h:
$(MKDIR_GEN)
@@ -42,6 +42,10 @@ $(AUBINATOR_GENERATED_FILES): genxml/gen_zipped_file.py
$(MKDIR_GEN)
$(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py $< > $@ || 
($(RM) $@; false)
 
+genxml/genX_bits.h: genxml/gen_bits_header.py $(GENXML_XML_FILES)
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $< -o $@ $(GENXML_XML_FILES)
+
 EXTRA_DIST += \
genxml/genX_pack.h \
genxml/gen_macros.h \
diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 801797d2768..ec43f06a495 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -117,7 +117,7 @@ GENXML_XML_FILES = \
genxml/gen8.xml \
genxml/gen9.xml
 
-GENXML_GENERATED_FILES = \
+GENXML_GENERATED_PACK_FILES = \
genxml/gen4_pack.h \
genxml/gen45_pack.h \
genxml/gen5_pack.h \
@@ -127,6 +127,10 @@ GENXML_GENERATED_FILES = \
genxml/gen8_pack.h \
genxml/gen9_pack.h
 
+GENXML_GENERATED_FILES = \
+   $(GENXML_GENERATED_PACK_FILES) \
+   genxml/genX_bits.h
+
 AUBINATOR_GENERATED_FILES = \
genxml/gen6_xml.h \
genxml/gen7_xml.h \
diff --git a/src/intel/genxml/.gitignore b/src/intel/genxml/.gitignore
index c5672b5595c..3e2f1cfa9f0 100644
--- a/src/intel/genxml/.gitignore
+++ b/src/intel/genxml/.gitignore
@@ -1,2 +1,3 @@
+gen*_bits.h
 gen*_pack.h
 gen*_xml.h
diff --git a/src/intel/genxml/gen_bits_header.py 
b/src/intel/genxml/gen_bits_header.py
new file mode 100644
index 000..0315c6251e7
--- /dev/null
+++ b/src/intel/genxml/gen_bits_header.py
@@ -0,0 +1,259 @@
+#encoding=utf-8
+
+from __future__ import (
+absolute_import, division, print_function, unicode_literals
+)
+
+import argparse
+import io
+import os
+import os.path
+import re
+import sys
+from sys import stdout, stderr
+from textwrap import dedent
+import xml.parsers.expat
+
+def safe_token(t):
+t = t.replace(' ', '')
+if t[0].isdigit():
+t = '_' + t
+return t
+
+class Gen(object):
+
+def __init__(self, z):
+# Convert potential "major.minor" string
+z = float(z)
+if z < 10:
+z *= 10
+self._10x = int(z)
+
+def prefix(self, token):
+gen = self._10x
+
+if gen % 10 == 0:
+gen //= 10
+
+if token[0] == '_':
+token = token[1:]
+
+return 'GEN{}_{}'.format(gen, token)
+
+class Header(object):
+
+def __init__(self, buf):
+self.buf = buf
+self.cpp_guard = os.path.basename(buf.name).upper().replace('.', '_')
+
+def write(self, *args, **kwargs):
+self.buf.write(*args, **kwargs)
+
+def write_prologue(self):
+self.write(dedent("""\
+/*
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a
+ * copy of this software and associated documentation 

[Mesa-dev] [PATCH 7/9] isl: Let isl_surf_init's caller set the exact row pitch (v2)

[Chad Versace]

The caller does so by setting the new field
isl_surf_init_info::row_pitch.

v2: Validate the requested row_pitch.

Reviewed-by: Jason Ekstrand  (v2)
---
 src/intel/isl/isl.c | 14 +-
 src/intel/isl/isl.h |  6 ++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index f86ca4f9212..357f98f6b24 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1120,10 +1120,22 @@ isl_calc_row_pitch(const struct isl_device *dev,
const uint32_t alignment =
   isl_calc_row_pitch_alignment(surf_info, tile_info);
 
-   const uint32_t row_pitch =
+   const uint32_t min_row_pitch =
   isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_slice0_sa,
  alignment);
 
+   uint32_t row_pitch = min_row_pitch;
+
+   if (surf_info->row_pitch != 0) {
+  row_pitch = surf_info->row_pitch;
+
+  if (row_pitch < min_row_pitch)
+ return false;
+
+  if (row_pitch % alignment != 0)
+ return false;
+   }
+
const uint32_t row_pitch_tiles = row_pitch / tile_info->phys_extent_B.width;
 
if (row_pitch == 0)
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 9d92906ca71..012be7b98e7 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -813,6 +813,12 @@ struct isl_surf_init_info {
/** Lower bound for isl_surf::pitch, in bytes. */
uint32_t min_pitch;
 
+   /**
+* Exact value for isl_surf::row_pitch. Ignored if zero.  isl_surf_init()
+* will fail if this is misaligned or out of bounds.
+*/
+   uint32_t row_pitch;
+
isl_surf_usage_flags_t usage;
 
/** Flags that alter how ISL selects isl_surf::tiling.  */
-- 
2.12.0

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

[Mesa-dev] [PATCH 5/9] intel/common: Add func gen_get_version_10x()

[Chad Versace]

It does the obvious.
bdw => 80
hsw => 75
ivb => 70
...
g4x => 45
---
 src/intel/common/gen_device_info.c | 11 +++
 src/intel/common/gen_device_info.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/src/intel/common/gen_device_info.c 
b/src/intel/common/gen_device_info.c
index 209b293e510..611ef3db2a9 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/gen_device_info.c
@@ -604,3 +604,14 @@ gen_get_device_name(int devid)
   return NULL;
}
 }
+
+int
+gen_get_version_10x(const struct gen_device_info *devinfo)
+{
+   int v = 10 * devinfo->gen;
+
+   if (devinfo->is_haswell || devinfo->is_g4x)
+  v += 5;
+
+   return v;
+}
diff --git a/src/intel/common/gen_device_info.h 
b/src/intel/common/gen_device_info.h
index 80676d0e003..190c9bff3be 100644
--- a/src/intel/common/gen_device_info.h
+++ b/src/intel/common/gen_device_info.h
@@ -27,6 +27,8 @@
 
 #include 
 
+#include "util/macros.h"
+
 /**
  * Intel hardware information and quirks
  */
@@ -176,5 +178,6 @@ struct gen_device_info
 
 bool gen_get_device_info(int devid, struct gen_device_info *devinfo);
 const char *gen_get_device_name(int devid);
+int gen_get_version_10x(const struct gen_device_info *devinfo) ATTRIBUTE_PURE;
 
 #endif /* GEN_DEVICE_INFO_H */
-- 
2.12.0

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

[Mesa-dev] [PATCH 8/9] intel: Fix requests for exact surface row pitch (v2)

[Chad Versace]

All callers of isl_surf_init() that set 'min_row_pitch' wanted to
request an *exact* row pitch, as evidenced by nearby asserts, but isl
lacked API for doing so. Now that isl has an API for that, update the
code to use it.

v2: Assert that isl_surf_init() succeeds because the callers assume
it.  [for jekstrand]

Reviewed-by: Nanley Chery  (v1)
Reviewed-by: Anuj Phogat  (v1)
Reviewed-by: Jason Ekstrand  (v2)
---
 src/intel/blorp/blorp_blit.c |  8 +---
 src/intel/vulkan/anv_blorp.c | 29 +++--
 src/intel/vulkan/anv_image.c |  2 +-
 3 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 280b76ab70c..691564c8788 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1375,6 +1375,8 @@ static void
 surf_convert_to_single_slice(const struct isl_device *isl_dev,
  struct brw_blorp_surface_info *info)
 {
+   bool ok UNUSED;
+
/* Just bail if we have nothing to do. */
if (info->surf.dim == ISL_SURF_DIM_2D &&
info->view.base_level == 0 && info->view.base_array_layer == 0 &&
@@ -1421,13 +1423,13 @@ surf_convert_to_single_slice(const struct isl_device 
*isl_dev,
   .levels = 1,
   .array_len = 1,
   .samples = info->surf.samples,
-  .min_pitch = info->surf.row_pitch,
+  .row_pitch = info->surf.row_pitch,
   .usage = info->surf.usage,
   .tiling_flags = 1 << info->surf.tiling,
};
 
-   isl_surf_init_s(isl_dev, >surf, _info);
-   assert(info->surf.row_pitch == init_info.min_pitch);
+   ok = isl_surf_init_s(isl_dev, >surf, _info);
+   assert(ok);
 
/* The view is also different now. */
info->view.base_level = 0;
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 1f4fec5f35b..80ab4339ffe 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -133,6 +133,7 @@ get_blorp_surf_for_anv_buffer(struct anv_device *device,
 {
const struct isl_format_layout *fmtl =
   isl_format_get_layout(format);
+   bool ok UNUSED;
 
/* ASTC is the only format which doesn't support linear layouts.
 * Create an equivalently sized surface with ISL to get around this.
@@ -155,20 +156,20 @@ get_blorp_surf_for_anv_buffer(struct anv_device *device,
   },
};
 
-   isl_surf_init(>isl_dev, isl_surf,
- .dim = ISL_SURF_DIM_2D,
- .format = format,
- .width = width,
- .height = height,
- .depth = 1,
- .levels = 1,
- .array_len = 1,
- .samples = 1,
- .min_pitch = row_pitch,
- .usage = ISL_SURF_USAGE_TEXTURE_BIT |
-  ISL_SURF_USAGE_RENDER_TARGET_BIT,
- .tiling_flags = ISL_TILING_LINEAR_BIT);
-   assert(isl_surf->row_pitch == row_pitch);
+   ok = isl_surf_init(>isl_dev, isl_surf,
+ .dim = ISL_SURF_DIM_2D,
+ .format = format,
+ .width = width,
+ .height = height,
+ .depth = 1,
+ .levels = 1,
+ .array_len = 1,
+ .samples = 1,
+ .row_pitch = row_pitch,
+ .usage = ISL_SURF_USAGE_TEXTURE_BIT |
+  ISL_SURF_USAGE_RENDER_TARGET_BIT,
+ .tiling_flags = ISL_TILING_LINEAR_BIT);
+   assert(ok);
 }
 
 static void
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 33499abca1a..cf34dbe3b0a 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -166,7 +166,7 @@ make_surface(const struct anv_device *dev,
   .array_len = vk_info->arrayLayers,
   .samples = vk_info->samples,
   .min_alignment = 0,
-  .min_pitch = anv_info->stride,
+  .row_pitch = anv_info->stride,
   .usage = choose_isl_surf_usage(image->usage, aspect),
   .tiling_flags = tiling_flags);
 
-- 
2.12.0

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

[Mesa-dev] [PATCH 6/9] isl: Validate the calculated row pitch (v2)

[Chad Versace]

Validate that isl_surf::row_pitch fits in the below bitfields,
if applicable based on isl_surf::usage.

RENDER_SURFACE_STATE::SurfacePitch
RENDER_SURFACE_STATE::AuxiliarySurfacePitch
3DSTATE_DEPTH_BUFFER::SurfacePitch
3DSTATE_HIER_DEPTH_BUFFER::SurfacePitch

v2: Add a Makefile dependency on generated header genX_bits.h.
---
 src/intel/Makefile.isl.am |  3 ++
 src/intel/isl/isl.c   | 72 +++
 2 files changed, 69 insertions(+), 6 deletions(-)

diff --git a/src/intel/Makefile.isl.am b/src/intel/Makefile.isl.am
index ee2215df1d1..09a10281b45 100644
--- a/src/intel/Makefile.isl.am
+++ b/src/intel/Makefile.isl.am
@@ -63,6 +63,9 @@ isl/isl_format_layout.c: isl/gen_format_layout.py \
$(PYTHON_GEN) $(srcdir)/isl/gen_format_layout.py \
--csv $(srcdir)/isl/isl_format_layout.csv --out $@
 
+# Dependencies on generated files
+$(builddir)/isl/isl.o: $(srcdir)/genxml/genX_bits.h
+
 # 
 #  Tests
 # 
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 81f40b6a6fb..f86ca4f9212 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 
+#include "genxml/genX_bits.h"
+
 #include "isl.h"
 #include "isl_gen4.h"
 #include "isl_gen6.h"
@@ -1089,18 +1091,74 @@ isl_calc_min_row_pitch(const struct isl_device *dev,
}
 }
 
-static uint32_t
+/**
+ * Is `pitch` in the valid range for a hardware bitfield, if the bitfield's
+ * size is `bits` bits?
+ *
+ * Hardware pitch fields are offset by 1. For example, if the size of
+ * RENDER_SURFACE_STATE::SurfacePitch is B bits, then the range of valid
+ * pitches is [1, 2^b] inclusive.  If the surface pitch is N, then
+ * RENDER_SURFACE_STATE::SurfacePitch must be set to N-1.
+ */
+static bool
+pitch_in_range(uint32_t n, uint32_t bits)
+{
+   assert(n != 0);
+   return likely(bits != 0 && 1 <= n && n <= (1 << bits));
+}
+
+static bool
 isl_calc_row_pitch(const struct isl_device *dev,
const struct isl_surf_init_info *surf_info,
const struct isl_tile_info *tile_info,
enum isl_dim_layout dim_layout,
-   const struct isl_extent2d *phys_slice0_sa)
+   const struct isl_extent2d *phys_slice0_sa,
+   uint32_t *out_row_pitch)
 {
+   const int gen_10x = gen_get_version_10x(dev->info);
+
const uint32_t alignment =
   isl_calc_row_pitch_alignment(surf_info, tile_info);
 
-   return isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_slice0_sa,
- alignment);
+   const uint32_t row_pitch =
+  isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_slice0_sa,
+ alignment);
+
+   const uint32_t row_pitch_tiles = row_pitch / tile_info->phys_extent_B.width;
+
+   if (row_pitch == 0)
+  return false;
+
+   if (dim_layout == ISL_DIM_LAYOUT_GEN9_1D) {
+  /* SurfacePitch is ignored for this layout.How should we validate it? */
+  isl_finishme("validate row pitch for ISL_DIM_LAYOUT_GEN9_1D");
+  goto done;
+   }
+
+   if (((surf_info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) ||
+(surf_info->usage & ISL_SURF_USAGE_TEXTURE_BIT)) &&
+   !pitch_in_range(row_pitch, 
RENDER_SURFACE_STATE_SurfacePitch_bits(gen_10x)))
+  return false;
+
+   if (((surf_info->usage & ISL_SURF_USAGE_CCS_BIT) ||
+(surf_info->usage & ISL_SURF_USAGE_MCS_BIT)) &&
+   !pitch_in_range(row_pitch_tiles, 
RENDER_SURFACE_STATE_AuxiliarySurfacePitch_bits(gen_10x)))
+  return false;
+
+   if ((surf_info->usage & ISL_SURF_USAGE_DEPTH_BIT) &&
+   !pitch_in_range(row_pitch, 
_3DSTATE_DEPTH_BUFFER_SurfacePitch_bits(gen_10x)))
+  return false;
+
+   if ((surf_info->usage & ISL_SURF_USAGE_HIZ_BIT) &&
+   !pitch_in_range(row_pitch, 
_3DSTATE_HIER_DEPTH_BUFFER_SurfacePitch_bits(gen_10x)))
+  return false;
+
+   if (surf_info->usage & ISL_SURF_USAGE_STENCIL_BIT)
+  isl_finishme("validate row pitch of stencil surfaces");
+
+ done:
+   *out_row_pitch = row_pitch;
+   return true;
 }
 
 /**
@@ -1275,8 +1333,10 @@ isl_surf_init_s(const struct isl_device *dev,
uint32_t pad_bytes;
isl_apply_surface_padding(dev, info, _info, _h_el, _bytes);
 
-   const uint32_t row_pitch = isl_calc_row_pitch(dev, info, _info,
- dim_layout, _slice0_sa);
+   uint32_t row_pitch;
+   if (!isl_calc_row_pitch(dev, info, _info, dim_layout,
+   _slice0_sa, _pitch))
+  return false;
 
uint32_t size, base_alignment;
if (tiling == ISL_TILING_LINEAR) {
-- 
2.12.0

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

[Mesa-dev] [PATCH 9/9] isl: Drop unused isl_surf_init_info::min_pitch

[Chad Versace]

Reviewed-by: Nanley Chery 
Reviewed-by: Anuj Phogat 
Reviewed-by: Jason Ekstrand 
---
 src/intel/isl/isl.c | 13 +++--
 src/intel/isl/isl.h |  3 ---
 2 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 357f98f6b24..22ef57a561a 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1043,11 +1043,7 @@ isl_calc_linear_min_row_pitch(const struct isl_device 
*dev,
 
assert(phys_slice0_sa->w % fmtl->bw == 0);
 
-   uint32_t min_row_pitch = bs * (phys_slice0_sa->w / fmtl->bw);
-   min_row_pitch = MAX2(min_row_pitch, info->min_pitch);
-   min_row_pitch = isl_align_npot(min_row_pitch, alignment);
-
-   return min_row_pitch;
+   return isl_align_npot(bs * (phys_slice0_sa->w / fmtl->bw), alignment);
 }
 
 static uint32_t
@@ -1068,11 +1064,8 @@ isl_calc_tiled_min_row_pitch(const struct isl_device 
*dev,
   isl_align_div(total_w_el * tile_el_scale,
 tile_info->logical_extent_el.width);
 
-   uint32_t min_row_pitch = total_w_tl * tile_info->phys_extent_B.width;
-   min_row_pitch = MAX2(min_row_pitch, surf_info->min_pitch);
-   min_row_pitch = isl_align_npot(min_row_pitch, alignment);
-
-   return min_row_pitch;
+   assert(alignment == tile_info->phys_extent_B.width);
+   return total_w_tl * tile_info->phys_extent_B.width;
 }
 
 static uint32_t
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 012be7b98e7..17b52cf2f4f 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -810,9 +810,6 @@ struct isl_surf_init_info {
/** Lower bound for isl_surf::alignment, in bytes. */
uint32_t min_alignment;
 
-   /** Lower bound for isl_surf::pitch, in bytes. */
-   uint32_t min_pitch;
-
/**
 * Exact value for isl_surf::row_pitch. Ignored if zero.  isl_surf_init()
 * will fail if this is misaligned or out of bounds.
-- 
2.12.0

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

[Mesa-dev] [PATCH 2/9] genxml: Fix gen_zipped_file.py dependency

[Chad Versace]

The gen*_xml.h files depend on gen_zipped_file.py, not the gen*_pack.h
files.
---
 src/intel/Makefile.genxml.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index eab6ccd208d..01a02b63b44 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -36,7 +36,7 @@ $(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/genxml/gen_pack_header.py $< > $@ || ($(RM) $@; 
false)
 
-$(GENXML_GENERATED_FILES): genxml/gen_zipped_file.py
+$(AUBINATOR_GENERATED_FILES): genxml/gen_zipped_file.py
 
 .xml_xml.h:
$(MKDIR_GEN)
-- 
2.12.0

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

[Mesa-dev] [PATCH 4/9] genxml: Add 3DSTATE_DEPTH_BUFFER to gen5.xml

[Chad Versace]

isl will use this for validating the depth buffer pitch.
---
 src/intel/genxml/gen5.xml | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/src/intel/genxml/gen5.xml b/src/intel/genxml/gen5.xml
index 39fec3723f6..97c13699673 100644
--- a/src/intel/genxml/gen5.xml
+++ b/src/intel/genxml/gen5.xml
@@ -54,4 +54,60 @@
 
 
   
+
+  
+
+
+
+
+
+
+
+
+
+  
+  
+  
+  
+  
+
+
+
+  
+
+
+  
+  
+  
+
+
+
+
+  
+  
+  
+  
+  
+
+
+
+
+
+
+
+
+
+  
+  
+
+
+
+
+
+
+
+
+
+
+  
 
-- 
2.12.0

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

[Mesa-dev] [PATCH 0/9] isl: Fix requests for exact row pitch (v4)

[Chad Versace]

All callers of isl_surf_init() that set 'min_pitch' wanted to
request an *exact* row pitch, as evidenced by nearby asserts, but isl
lacked API for doing so. This series fixes that by adding a field,
isl_surf_init_info::row_pitch.

This prepares for VK_MESAX_external_image_dma_buf, which requires
support for create VkImages with an exact, user-provided row pitch.

This patch series lives at:
git://git.kiwitree.net/~chadv/mesa
refs/tags/chadv/review/isl-request-exact-row-pitch-v04
gitweb: 
http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/isl-request-exact-row-pitch-v04

v2:
  - Validate the requested row pitch. This required more extensive
refactors in patch 2.

v3:
  - New generated genxml header genX_bits.h.
  - Fix the pitch validation. Inspect the surface's usage bits instead
of its tiling to determine the pitch constraints. Use the bitfield
sizes from genX_bits.h.

v4:
  - When generating genX_bits.h, parse the XML instead of scraping the
gen*_pack.h headers.  [for jekstrand]

Jason and I tentatively agreed that I should just hand-write the
header. But my conscience refused. The XML way is the right way.
Anyway, the generator script are about the same number of lines (259
vs 222), so the generator is the clear winner in my opinion.

Testing:
  I'm locally running dEQP-VK on Skylake.
dEQP-VK.memory.*: 0 failures
dEQP-VK.api.*: still running

  I also pushed this to my 'jenkins' branch. But I no longer know to
  view the Jenkins results, because they're behind the Intel firewall.

Chad Versace (9):
  genxml: Define GENXML_XML_FILES in Makefile.sources
  genxml: Fix gen_zipped_file.py dependency
  genxml: New generated header genX_bits.h (v2)
  genxml: Add 3DSTATE_DEPTH_BUFFER to gen5.xml
  intel/common: Add func gen_get_version_10x()
  isl: Validate the calculated row pitch (v2)
  isl: Let isl_surf_init's caller set the exact row pitch (v2)
  intel: Fix requests for exact surface row pitch (v2)
  isl: Drop unused isl_surf_init_info::min_pitch

 src/intel/Makefile.genxml.am|  17 +--
 src/intel/Makefile.isl.am   |   3 +
 src/intel/Makefile.sources  |  16 ++-
 src/intel/blorp/blorp_blit.c|   8 +-
 src/intel/common/gen_device_info.c  |  11 ++
 src/intel/common/gen_device_info.h  |   3 +
 src/intel/genxml/.gitignore |   1 +
 src/intel/genxml/gen5.xml   |  56 
 src/intel/genxml/gen_bits_header.py | 259 
 src/intel/isl/isl.c |  97 +++---
 src/intel/isl/isl.h |   7 +-
 src/intel/vulkan/anv_blorp.c|  29 ++--
 src/intel/vulkan/anv_image.c|   2 +-
 13 files changed, 462 insertions(+), 47 deletions(-)
 create mode 100644 src/intel/genxml/gen_bits_header.py

-- 
2.12.0

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

[Mesa-dev] [PATCH 1/9] genxml: Define GENXML_XML_FILES in Makefile.sources

[Chad Versace]

The future header genX_bits.h will depend on GENXML_XML_FILES.
---
 src/intel/Makefile.genxml.am |  9 +
 src/intel/Makefile.sources   | 10 ++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index bea0aab817f..eab6ccd208d 100644
--- a/src/intel/Makefile.genxml.am
+++ b/src/intel/Makefile.genxml.am
@@ -24,6 +24,7 @@ BUILT_SOURCES += \
$(AUBINATOR_GENERATED_FILES)
 
 EXTRA_DIST += \
+   $(GENXML_XML_FILES) \
$(GENXML_GENERATED_FILES) \
$(AUBINATOR_GENERATED_FILES)
 
@@ -42,14 +43,6 @@ $(GENXML_GENERATED_FILES): genxml/gen_zipped_file.py
$(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py $< > $@ || 
($(RM) $@; false)
 
 EXTRA_DIST += \
-   genxml/gen4.xml \
-   genxml/gen45.xml \
-   genxml/gen5.xml \
-   genxml/gen6.xml \
-   genxml/gen7.xml \
-   genxml/gen75.xml \
-   genxml/gen8.xml \
-   genxml/gen9.xml \
genxml/genX_pack.h \
genxml/gen_macros.h \
genxml/gen_pack_header.py \
diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 839ea47d752..801797d2768 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -107,6 +107,16 @@ COMPILER_FILES = \
 COMPILER_GENERATED_FILES = \
compiler/brw_nir_trig_workarounds.c
 
+GENXML_XML_FILES = \
+   genxml/gen4.xml \
+   genxml/gen45.xml \
+   genxml/gen5.xml \
+   genxml/gen6.xml \
+   genxml/gen7.xml \
+   genxml/gen75.xml \
+   genxml/gen8.xml \
+   genxml/gen9.xml
+
 GENXML_GENERATED_FILES = \
genxml/gen4_pack.h \
genxml/gen45_pack.h \
-- 
2.12.0

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

Re: [Mesa-dev] [PATCH 1/2] st/nine: Fix issue with surface and volume dtors and csmt

[James Harvey]

Hi Axel,

EVE Online is no longer crashing for me with these patches.
Thanks!

Tested-by: James Harvey 

On 03/15/2017 02:56 PM, Axel Davy wrote:
> Surfaces and Volumes can be freed in the worker thread.
> 
> This fixes these dtor.
> Especially if they were freed by nine_context_box_upload,
> the counter was decremented after the destructions, which
> lead to deadlock.
> 
> Fixes bugzilla 99246.
> 
> CC: "17.0" 
> Signed-off-by: Axel Davy 
> ---
>  src/gallium/state_trackers/nine/nine_csmt_helper.h |  2 +-
>  src/gallium/state_trackers/nine/surface9.c | 10 --
>  src/gallium/state_trackers/nine/volume9.c  | 10 --
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/nine/nine_csmt_helper.h 
> b/src/gallium/state_trackers/nine/nine_csmt_helper.h
> index b0bbc054fc..dc46bbd3a2 100644
> --- a/src/gallium/state_trackers/nine/nine_csmt_helper.h
> +++ b/src/gallium/state_trackers/nine/nine_csmt_helper.h
> @@ -233,8 +233,8 @@ name##_rx( struct NineDevice9 *device, struct 
> csmt_instruction *instr ) \
>  name##_priv( \
>  device ARGS_FOR_CALL( __VA_ARGS__ ) \
>  ); \
> -ARGS_FOR_UNBIND( __VA_ARGS__ ) \
>  p_atomic_dec(args->counter); \
> +ARGS_FOR_UNBIND( __VA_ARGS__ ) \
>  return 0; \
>  } \
>  \
> diff --git a/src/gallium/state_trackers/nine/surface9.c 
> b/src/gallium/state_trackers/nine/surface9.c
> index 836369cafd..d917fa1f86 100644
> --- a/src/gallium/state_trackers/nine/surface9.c
> +++ b/src/gallium/state_trackers/nine/surface9.c
> @@ -204,9 +204,15 @@ NineSurface9_dtor( struct NineSurface9 *This )
>  {
>  DBG("This=%p\n", This);
>  
> -if (This->transfer)
> -NineSurface9_UnlockRect(This);
> +if (This->transfer) {
> +struct pipe_context *pipe = 
> nine_context_get_pipe_multithread(This->base.base.device);
> +pipe->transfer_unmap(pipe, This->transfer);
> +This->transfer = NULL;
> +}
>  
> +/* Note: Following condition cannot happen currently, since we
> + * refcount the surface in the functions increasing
> + * pending_uploads_counter. */
>  if (p_atomic_read(>pending_uploads_counter))
>  nine_csmt_process(This->base.base.device);
>  
> diff --git a/src/gallium/state_trackers/nine/volume9.c 
> b/src/gallium/state_trackers/nine/volume9.c
> index 11236a02e7..62af3e6225 100644
> --- a/src/gallium/state_trackers/nine/volume9.c
> +++ b/src/gallium/state_trackers/nine/volume9.c
> @@ -142,9 +142,15 @@ NineVolume9_dtor( struct NineVolume9 *This )
>  {
>  DBG("This=%p\n", This);
>  
> -if (This->transfer)
> -NineVolume9_UnlockBox(This);
> +if (This->transfer) {
> +struct pipe_context *pipe = 
> nine_context_get_pipe_multithread(This->base.device);
> +pipe->transfer_unmap(pipe, This->transfer);
> +This->transfer = NULL;
> +}
>  
> +/* Note: Following condition cannot happen currently, since we
> + * refcount the volume in the functions increasing
> + * pending_uploads_counter. */
>  if (p_atomic_read(>pending_uploads_counter))
>  nine_csmt_process(This->base.device);
>  
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa 1/2] REVIEWERS: add myself as a reviewer for EGL and docs

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 REVIEWERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/REVIEWERS b/REVIEWERS
index 6bd1676cb9..40db33f67f 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -58,6 +58,7 @@ F:src/compiler/nir/
 
 DOCUMENTATION
 R: Emil Velikov 
+R: Eric Engestrom 
 F: docs/
 F: doxygen/
 
@@ -69,6 +70,10 @@ DRI LOADER
 R: Emil Velikov 
 F: src/loader/
 
+EGL
+R: Eric Engestrom 
+F: src/egl/
+
 GALLIUM LOADER
 R: Emil Velikov 
 F: src/gallium/auxiliary/pipe-loader/
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 2/2] REVIEWERS: add autogen.sh to the autoconf group

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 REVIEWERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/REVIEWERS b/REVIEWERS
index 40db33f67f..0b5d9a4fd3 100644
--- a/REVIEWERS
+++ b/REVIEWERS
@@ -85,6 +85,7 @@ F: src/gallium/targets/
 
 AUTOCONF BUILD
 R: Emil Velikov 
+F: autogen.sh
 F: configure.ac
 F: */Automake.inc
 F: */Makefile.*am
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [llvm] r298336 - Fix evaluation of LLVM_DEFINITIONS

[Serge Pavlov]

Hi Michel,

Thank you for analysis. Should be fixed in r298498.

Thanks,
--Serge

2017-03-22 15:01 GMT+07:00 Michel Dänzer :

>
> Hi Serge,
>
>
> On 21/03/17 01:03 PM, Serge Pavlov via llvm-commits wrote:
> > Author: sepavloff
> > Date: Mon Mar 20 23:03:24 2017
> > New Revision: 298336
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=298336=rev
> > Log:
> > Fix evaluation of LLVM_DEFINITIONS
>
> This change broke the build of at least libclc and Mesa, because
> llvm-config --cxxflags contains multiple flags concatenated without
> spaces, e.g. "-fdata-sections-O3" or "-fno-rtti-DLLVM_BUILD_GLOBAL_ISEL".
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 1/1] clover: use pipe_resource references

[Francisco Jerez]

Jan Vesely  writes:

> v2: buffers are created with one reference.
> v3: add pipe_resource reference to mapping object
>
> CC: "17.0 13.0" 
>
> Signed-off-by: Jan Vesely 
> ---
>  src/gallium/state_trackers/clover/core/resource.cpp | 11 ---
>  src/gallium/state_trackers/clover/core/resource.hpp |  7 ---
>  2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/core/resource.cpp 
> b/src/gallium/state_trackers/clover/core/resource.cpp
> index 06fd3f6..83e3c26 100644
> --- a/src/gallium/state_trackers/clover/core/resource.cpp
> +++ b/src/gallium/state_trackers/clover/core/resource.cpp
> @@ -25,6 +25,7 @@
>  #include "pipe/p_screen.h"
>  #include "util/u_sampler.h"
>  #include "util/u_format.h"
> +#include "util/u_inlines.h"
>  
>  using namespace clover;
>  
> @@ -176,7 +177,7 @@ root_resource::root_resource(clover::device , 
> memory_obj ,
>  }
>  
>  root_resource::~root_resource() {
> -   device().pipe->resource_destroy(device().pipe, pipe);
> +   pipe_resource_reference(>pipe, NULL);
>  }
>  
>  sub_resource::sub_resource(resource , const vector ) :
> @@ -202,18 +203,21 @@ mapping::mapping(command_queue , resource ,
>pxfer = NULL;
>throw error(CL_OUT_OF_RESOURCES);
> }
> +   pipe_resource_reference(, r.pipe);
>  }
>  
>  mapping::mapping(mapping &) :
> -   pctx(m.pctx), pxfer(m.pxfer), p(m.p) {
> +   pctx(m.pctx), pxfer(m.pxfer), res(m.res), p(m.p) {
> m.pctx = NULL;
> m.pxfer = NULL;
> +   m.res = NULL;
> m.p = NULL;
>  }
>  
>  mapping::~mapping() {
> if (pxfer) {
>pctx->transfer_unmap(pctx, pxfer);
> }
> +   pipe_resource_reference(, NULL);
>  }
>  
> @@ -222,5 +226,6 @@ mapping::operator=(mapping m) {
> std::swap(pctx, m.pctx);
> std::swap(pxfer, m.pxfer);
> +   std::swap(res, m.res);
> std::swap(p, m.p);
> return *this;
>  }
> diff --git a/src/gallium/state_trackers/clover/core/resource.hpp 
> b/src/gallium/state_trackers/clover/core/resource.hpp
> index 9993dcb..cea9617 100644
> --- a/src/gallium/state_trackers/clover/core/resource.hpp
> +++ b/src/gallium/state_trackers/clover/core/resource.hpp
> @@ -123,9 +123,10 @@ namespace clover {
>}
>  
> private:
> -  pipe_context *pctx;
> -  pipe_transfer *pxfer;
> -  void *p;
> +  pipe_context *pctx = NULL;
> +  pipe_transfer *pxfer = NULL;
> +  pipe_resource *res = NULL;

I'd rename this to 'pres' in order to match the naming of other data
members.  I'm generally okay with using inline member initializers but
the existing members are already getting initialized from the
constructor so this change seems kind of redundant and unrelated, you
could just initialize pres from the mapping::mapping constructor.

> +  void *p = NULL;
> };
>  }
>  
> -- 
> 2.9.3


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 v3 1/1] clover: use pipe_resource references

[Francisco Jerez]

Vedran Miletić  writes:

> On 03/17/2017 05:20 AM, Jan Vesely wrote:
>> On Thu, 2017-03-16 at 18:07 -0700, Francisco Jerez wrote:
>>> Jan Vesely  writes:
>>>
 On Thu, 2017-03-16 at 17:22 -0700, Francisco Jerez wrote:
> Jan Vesely  writes:
>
>> On Thu, 2017-03-16 at 15:24 -0700, Francisco Jerez wrote:
>>> Jan Vesely  writes:
>>>
 v2: buffers are created with one reference.
 v3: add pipe_resource reference to mapping object

>>>
>>> Mapping objects are supposed to be short-lived, they're logically part
>>> of the parent resource object so they shouldn't ever out-live it.  What
>>> is this useful for?
>>
>> currently they can outlive the underlying pipe_resource. pipe_resource
>> is destroyed in root_resource destructor, while the list of mappings is
>> destroyed after resource destructor.
>
> Right.  I guess the problem is that the pipe_transfer object associated
> to the clover::mapping object holds a pointer to the backing
> pipe_resource object but it fails to increment its reference count?  I
> guess that's the reason why v2 didn't help?

 yes, though the pointer is hidden somewhere. I thought pxfer->resource
 might be it, but it's not, and digging deeper into the structure didn't
 sound like a good idea to me.

>>>
>>> What is pxfer->resource about in that case?
>> 
>> that's a good question, so I did a bit of digging. for EG global
>> buffers are shadowed in global buffer memory pool, so mapping uses
>> memory pool's pipe_resource. I'm still not 100% sure where exactly
>> unmapping the global pool accesses the original buffer's pipe_resource,
>> but I don't think it matters that much. It's not required for pxfer-
>>> resource to be equal to resource->pipe. we need to guarantee that
>> resource->pipe outlives all mappings.
>> either explicitly, or by grabbing reference.
>> 
>> Jan
>> 
>
> Jan's v3 solves the problem, as does my version.
>
> Francisco, do you have a particular preference how should we proceed?
>

I'm okay either way -- Though I'll send some codestyle-related
suggestions to Jan's patch in a minute.

> Regards,
> Vedran
>
> -- 
> Vedran Miletić
> vedran.miletic.net


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] glsl: Link tests with CLOCK_LIB.

[Vinson Lee]

On Wed, Mar 22, 2017 at 4:17 PM, Timothy Arceri  wrote:
> On 23/03/17 09:29, Vinson Lee wrote:
>>
>> Fix 'make check' linking errors on CentOS 6.
>
>
> Hi Vinson,
>
> Red Hat Enterprise Linux 6 enters Production Phase 3 on May 10, 2017. I've
> confirmed with Dave this means no more Mesa backports. Perhaps you
> might want to consider moving to testing CentOS 7?
>
> From what I can tell this should also fix the zlib min version problem.
>
>

Hi, Timothy.

I don't think this is a CentOS 6 specific issue but an issue with
older GCC, such as GCC 4.4.

Will we remove build support with GCC 4.4 soon as well?

>>
>>   CXXLD  glsl/glsl_test
>> glsl/.libs/libglsl.a(libmesautil_la-u_queue.o): In function
>> `u_thread_get_time_nano':
>> src/util/../../src/util/u_thread.h:84: undefined reference to
>> `clock_gettime'
>>
>> Signed-off-by: Vinson Lee 
>> ---
>>  src/compiler/Makefile.glsl.am |9 ++---
>>  1 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
>> index 761fb93..43fd6a9 100644
>> --- a/src/compiler/Makefile.glsl.am
>> +++ b/src/compiler/Makefile.glsl.am
>> @@ -66,7 +66,8 @@ glsl_tests_cache_test_CFLAGS =
>> \
>> $(PTHREAD_CFLAGS)
>>  glsl_tests_cache_test_LDADD =  \
>> glsl/libglsl.la \
>> -   $(PTHREAD_LIBS)
>> +   $(PTHREAD_LIBS) \
>> +   $(CLOCK_LIB)
>>
>>  glsl_tests_general_ir_test_SOURCES =   \
>> glsl/tests/array_refcount_test.cpp  \
>> @@ -83,7 +84,8 @@ glsl_tests_general_ir_test_LDADD =\
>> glsl/libglsl.la \
>> glsl/libstandalone.la   \
>> $(top_builddir)/src/libglsl_util.la \
>> -   $(PTHREAD_LIBS)
>> +   $(PTHREAD_LIBS) \
>> +   $(CLOCK_LIB)
>>
>>  glsl_tests_uniform_initializer_test_SOURCES =  \
>> glsl/tests/copy_constant_to_storage_tests.cpp   \
>> @@ -159,7 +161,8 @@ glsl_glsl_test_LDADD =
>> \
>> glsl/libglsl.la \
>> glsl/libstandalone.la   \
>> $(top_builddir)/src/libglsl_util.la \
>> -   $(PTHREAD_LIBS)
>> +   $(PTHREAD_LIBS) \
>> +   $(CLOCK_LIB)
>>
>>  # We write our own rules for yacc and lex below. We'd rather use
>> automake,
>>  # but automake makes it especially difficult for a number of reasons:
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/mesa: Fix missing-braces warning.

[Vinson Lee]

  CXX  state_tracker/st_glsl_to_nir.lo
state_tracker/st_glsl_to_nir.cpp:250:57: warning: suggest braces around 
initialization of subobject [-Wmissing-braces]
  nir_lower_wpos_ytransform_options wpos_options = {0};
^
{}

Signed-off-by: Vinson Lee 
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 674ccd07a4..e863bab4e7 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -247,7 +247,7 @@ st_glsl_to_nir(struct st_context *st, struct gl_program 
*prog,
   static const gl_state_index wposTransformState[STATE_LENGTH] = {
  STATE_INTERNAL, STATE_FB_WPOS_Y_TRANSFORM
   };
-  nir_lower_wpos_ytransform_options wpos_options = {0};
+  nir_lower_wpos_ytransform_options wpos_options = { { 0 } };
   struct pipe_screen *pscreen = st->pipe->screen;
 
   memcpy(wpos_options.state_tokens, wposTransformState,
-- 
2.11.0

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

Re: [Mesa-dev] [PATCH] glsl: Link tests with CLOCK_LIB.

[Timothy Arceri]

On 23/03/17 09:29, Vinson Lee wrote:

Fix 'make check' linking errors on CentOS 6.


Hi Vinson,

Red Hat Enterprise Linux 6 enters Production Phase 3 on May 10, 2017. 
I've confirmed with Dave this means no more Mesa backports. Perhaps you

might want to consider moving to testing CentOS 7?

From what I can tell this should also fix the zlib min version problem.



  CXXLD  glsl/glsl_test
glsl/.libs/libglsl.a(libmesautil_la-u_queue.o): In function 
`u_thread_get_time_nano':
src/util/../../src/util/u_thread.h:84: undefined reference to `clock_gettime'

Signed-off-by: Vinson Lee 
---
 src/compiler/Makefile.glsl.am |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index 761fb93..43fd6a9 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -66,7 +66,8 @@ glsl_tests_cache_test_CFLAGS =
\
$(PTHREAD_CFLAGS)
 glsl_tests_cache_test_LDADD =  \
glsl/libglsl.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)

 glsl_tests_general_ir_test_SOURCES =   \
glsl/tests/array_refcount_test.cpp  \
@@ -83,7 +84,8 @@ glsl_tests_general_ir_test_LDADD =\
glsl/libglsl.la \
glsl/libstandalone.la   \
$(top_builddir)/src/libglsl_util.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)

 glsl_tests_uniform_initializer_test_SOURCES =  \
glsl/tests/copy_constant_to_storage_tests.cpp   \
@@ -159,7 +161,8 @@ glsl_glsl_test_LDADD =  
\
glsl/libglsl.la \
glsl/libstandalone.la   \
$(top_builddir)/src/libglsl_util.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)

 # We write our own rules for yacc and lex below. We'd rather use automake,
 # but automake makes it especially difficult for a number of reasons:


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

Re: [Mesa-dev] [PATCH v4 19/28] i965/vec4: fix SIMD-width lowering for VEC4_OPCODE_FROM_DOUBLE

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> Now the VEC4_OPCODE_FROM_DOUBLE's destination data is written with
> stride 2. We need to take into account this when doing the split
> so we don't overwrite data.
>

You should probably fix the destination type of your
VEC4_OPCODE_FROM_DOUBLE instructions in PATCH 17 instead so you don't
need to special-case VEC4_OPCODE_FROM_DOUBLE in this lowering pass.

> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/intel/compiler/brw_vec4.cpp | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
> index b26f8035811..f4eea954404 100644
> --- a/src/intel/compiler/brw_vec4.cpp
> +++ b/src/intel/compiler/brw_vec4.cpp
> @@ -2198,6 +2198,7 @@ vec4_visitor::lower_simd_width()
>   linst->group = channel_offset;
>   linst->size_written = size_written;
>  
> + bool d2f_pass = (inst->opcode == VEC4_OPCODE_FROM_DOUBLE && n > 0);
>   /* Compute split dst region */
>   dst_reg dst;
>   if (needs_temp) {
> @@ -2212,7 +2213,11 @@ vec4_visitor::lower_simd_width()
> inst->insert_before(block, copy);
>  }
>   } else {
> -dst = horiz_offset(inst->dst, channel_offset);
> +/* d2x conversion is done with a destination's stride of 2. We 
> need
> + * to take into account when splitting it.
> + */
> +unsigned stride = d2f_pass ? 2 : 1;
> +dst = horiz_offset(inst->dst, stride * channel_offset);
>   }
>   linst->dst = dst;
>  
> -- 
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH v4 08/28] i965/fs: rename lower_d2x to lower_narrow_conversions

[Francisco Jerez]

I'd rename this to lower_conversions instead since after your previous
patch it's going to take care of handling unsupported conversions which
aren't necessarily to a narrower type.

Samuel Iglesias Gonsálvez  writes:

> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/intel/Makefile.sources  | 2 
> +-
>  src/intel/compiler/brw_fs.cpp   | 2 
> +-
>  src/intel/compiler/brw_fs.h | 2 
> +-
>  .../{brw_fs_lower_d2x.cpp => brw_fs_lower_narrow_conversions.cpp}   | 2 
> +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>  rename src/intel/compiler/{brw_fs_lower_d2x.cpp => 
> brw_fs_lower_narrow_conversions.cpp} (99%)
>
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 4eaf380492f..a9810887f80 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -42,7 +42,7 @@ COMPILER_FILES = \
>   compiler/brw_fs.h \
>   compiler/brw_fs_live_variables.cpp \
>   compiler/brw_fs_live_variables.h \
> - compiler/brw_fs_lower_d2x.cpp \
> + compiler/brw_fs_lower_narrow_conversions.cpp \
>   compiler/brw_fs_lower_pack.cpp \
>   compiler/brw_fs_nir.cpp \
>   compiler/brw_fs_reg_allocate.cpp \
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 8612a83805d..61ac981842e 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5740,7 +5740,7 @@ fs_visitor::optimize()
>OPT(dead_code_eliminate);
> }
>  
> -   if (OPT(lower_d2x)) {
> +   if (OPT(lower_narrow_conversions)) {
>OPT(opt_copy_propagation);
>OPT(dead_code_eliminate);
>OPT(lower_simd_width);
> diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
> index f3d36848e54..416397fabcd 100644
> --- a/src/intel/compiler/brw_fs.h
> +++ b/src/intel/compiler/brw_fs.h
> @@ -160,7 +160,7 @@ public:
> void lower_uniform_pull_constant_loads();
> bool lower_load_payload();
> bool lower_pack();
> -   bool lower_d2x();
> +   bool lower_narrow_conversions();
> bool lower_logical_sends();
> bool lower_integer_multiplication();
> bool lower_minmax();
> diff --git a/src/intel/compiler/brw_fs_lower_d2x.cpp 
> b/src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
> similarity index 99%
> rename from src/intel/compiler/brw_fs_lower_d2x.cpp
> rename to src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
> index fa25d313dcd..02a60b07eec 100644
> --- a/src/intel/compiler/brw_fs_lower_d2x.cpp
> +++ b/src/intel/compiler/brw_fs_lower_narrow_conversions.cpp
> @@ -44,7 +44,7 @@ supports_type_conversion(fs_inst *inst) {
>  }
>  
>  bool
> -fs_visitor::lower_d2x()
> +fs_visitor::lower_narrow_conversions()
>  {
> bool progress = false;
>  
> -- 
> 2.11.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH v4 07/28] i965/fs: generalize the legalization d2x pass

[Francisco Jerez]

Samuel Iglesias Gonsálvez  writes:

> Generalize it to lower any unsupported narrower conversion.
>
> v2 (Curro):
> - Add supports_type_conversion()
> - Reuse existing intruction instead of cloning it.
> - Generalize d2x to narrower and equal size conversions.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>  src/intel/compiler/brw_fs.cpp   | 11 ++--
>  src/intel/compiler/brw_fs_lower_d2x.cpp | 97 
> -
>  2 files changed, 77 insertions(+), 31 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 6da23b17107..8612a83805d 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5694,11 +5694,6 @@ fs_visitor::optimize()
>OPT(dead_code_eliminate);
> }
>  
> -   if (OPT(lower_d2x)) {
> -  OPT(opt_copy_propagation);
> -  OPT(dead_code_eliminate);
> -   }
> -
> OPT(lower_simd_width);
>  
> /* After SIMD lowering just in case we had to unroll the EOT send. */
> @@ -5745,6 +5740,12 @@ fs_visitor::optimize()
>OPT(dead_code_eliminate);
> }
>  
> +   if (OPT(lower_d2x)) {
> +  OPT(opt_copy_propagation);
> +  OPT(dead_code_eliminate);
> +  OPT(lower_simd_width);
> +   }
> +
> lower_uniform_pull_constant_loads();
>  
> validate();
> diff --git a/src/intel/compiler/brw_fs_lower_d2x.cpp 
> b/src/intel/compiler/brw_fs_lower_d2x.cpp
> index a2db1154615..fa25d313dcd 100644
> --- a/src/intel/compiler/brw_fs_lower_d2x.cpp
> +++ b/src/intel/compiler/brw_fs_lower_d2x.cpp
> @@ -27,47 +27,92 @@
>  
>  using namespace brw;
>  
> +static bool
> +supports_type_conversion(fs_inst *inst) {

Pointer should be marked const.

> +   switch(inst->opcode) {
> +   case BRW_OPCODE_MOV:
> +   case SHADER_OPCODE_MOV_INDIRECT:
> +  return true;
> +   case BRW_OPCODE_SEL:
> +  return false;

I suggest you return 'inst->dst.type == get_exec_type_size(inst)' here
in order to simplify the logic below and restructure things in a way
that allows you to make opcode-specific decisions here based on the
actual execution and destination types.

> +   default:
> +  /* FIXME: We assume the opcodes don't explicitly mentioned
> +   * before just work fine with arbitrary conversions.
> +   */
> +  return true;
> +   }
> +}
> +
>  bool
>  fs_visitor::lower_d2x()
>  {
> bool progress = false;
>  
> foreach_block_and_inst_safe(block, fs_inst, inst, cfg) {
> -  if (inst->opcode != BRW_OPCODE_MOV)
> - continue;
> +  bool inst_support_conversion = supports_type_conversion(inst);
> +  bool supported_conversion =
> + inst_support_conversion &&
> + (get_exec_type_size(inst) != 8 ||
> +  type_sz(inst->dst.type) > 4 ||
> +  type_sz(inst->dst.type) >= get_exec_type_size(inst));
>
> -  if (inst->dst.type != BRW_REGISTER_TYPE_F &&
> -  inst->dst.type != BRW_REGISTER_TYPE_D &&
> -  inst->dst.type != BRW_REGISTER_TYPE_UD)
> +  /* If the conversion is supported or there is no conversion then
> +   * do nothing.
> +   */
> +  if (supported_conversion ||
> +  (!inst_support_conversion && inst->dst.type == inst->src[0].type) 
> ||

You should be using the execution type here (and below where you
allocate the temp0 and temp1 vgrfs) instead of assuming it matches the
type of the first source.  Also I'm not 100% certain that the
combination of this conditional continue, the one below, the if/else
branches below and the supported_conversion definitions above catch the
exact set of cases where you need to apply lowering.  This would be a
lot easier to follow (most of the above goes away) if you did something
along the lines of:

| if (supports_type_conversion(inst)) {
|if (get_exec_type_size(inst) == 8 && type_sz(inst->dst.type) < 8) {
|   // Apply strided move workaround...
|   progress = true;
|}
| } else {
|// Apply general conversion workaround...
|progress = true;
| }

> +  inst->dst.file == BAD_FILE || inst->src[0].file == BAD_FILE)

I don't think the 'inst->dst.file == BAD_FILE || inst->src[0].file ==
BAD_FILE' terms of this expression are correct or useful, the
'inst->src[0].file' term because there might be a destination region
conversion regardless of what the file of the first source is, the
'inst->dst.file == BAD_FILE' term because you could just rely on DCE
instead...

>   continue;
>  
> -  if (inst->src[0].type != BRW_REGISTER_TYPE_DF &&
> -  inst->src[0].type != BRW_REGISTER_TYPE_UQ &&
> -  inst->src[0].type != BRW_REGISTER_TYPE_Q)
> - continue;
> +  /* This pass only supports conversion to narrower or equal size types. 
> */
> +  if (get_exec_type_size(inst) < type_sz(inst->dst.type))
> +  continue;
>  

I think you need to apply this condition to the if branch below that
deals with DF to F conversions *only*, the else branch you 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Eric Anholt (2017-03-22 15:15:46)
> Rob Clark  writes:
> 
> > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> >> Here's a not so complete list: 
> >> https://github.com/mesonbuild/meson/wiki/Users
> >>
> >> Notably gnome is moving to meson (and some parts already use it), weston 
> >> and
> >> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> >> can't say for sure it's going to be around forever, but its been in 
> >> development
> >> since late 2012 and still lands several patches a day, they were 
> >> responsive to
> >> me when I sent a patch (that I still need to respin), and they seem to be
> >> picking up momentum from downstreams.
> >
> >
> > btw, possibly newbie question, but from what I can tell so far in
> > meson docs, there are separate 'meson build && cd build && ninja'
> > steps.. one nice thing about autotools is 'git pull && make' (and it
> > somehow magically figures out whether to re-automake/autoconf).  Not
> > sure if there is a way to do something like that in meson.
> 
> Consider meson build to be ./autogen.sh.  After that point you can git
> pull && make.

Additionally, ninja has the same -C flag as make. So that can be 'meson build &&
ninja -C build' and 'git pull && ninja -C build'


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

[Mesa-dev] [PATCH] glsl: Link tests with CLOCK_LIB.

[Vinson Lee]

Fix 'make check' linking errors on CentOS 6.

  CXXLD  glsl/glsl_test
glsl/.libs/libglsl.a(libmesautil_la-u_queue.o): In function 
`u_thread_get_time_nano':
src/util/../../src/util/u_thread.h:84: undefined reference to `clock_gettime'

Signed-off-by: Vinson Lee 
---
 src/compiler/Makefile.glsl.am |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index 761fb93..43fd6a9 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -66,7 +66,8 @@ glsl_tests_cache_test_CFLAGS =
\
$(PTHREAD_CFLAGS)
 glsl_tests_cache_test_LDADD =  \
glsl/libglsl.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)
 
 glsl_tests_general_ir_test_SOURCES =   \
glsl/tests/array_refcount_test.cpp  \
@@ -83,7 +84,8 @@ glsl_tests_general_ir_test_LDADD =\
glsl/libglsl.la \
glsl/libstandalone.la   \
$(top_builddir)/src/libglsl_util.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)
 
 glsl_tests_uniform_initializer_test_SOURCES =  \
glsl/tests/copy_constant_to_storage_tests.cpp   \
@@ -159,7 +161,8 @@ glsl_glsl_test_LDADD =  
\
glsl/libglsl.la \
glsl/libstandalone.la   \
$(top_builddir)/src/libglsl_util.la \
-   $(PTHREAD_LIBS)
+   $(PTHREAD_LIBS) \
+   $(CLOCK_LIB)
 
 # We write our own rules for yacc and lex below. We'd rather use automake,
 # but automake makes it especially difficult for a number of reasons:
-- 
1.7.1

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Alex Deucher  writes:

> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
>> Why bother, and why would we want this?  
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D= more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

Meson is so much nicer for the casual contributor than autoconf.  I've
been hacking at converting the X Server for two days, and I'm now far
more capable at meson than have ever been at autotools, and I've been
doing autotools for 15 years (I don't know how many autotools build
systems I've written over that time, but it's in the tens at least).

I think meson is a win for new users already.  I think we get into even
bigger wins when we consider the use of wrap when there's no distro copy
of a library -- just imagine never having to write instructions like the
"X Server" or "Mesa" parts of this page again:
https://github.com/anholt/mesa/wiki/VC4-complete-Raspbian-upgrade


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

[Mesa-dev] [PATCH] i965: Require Kernel 3.6 for Gen4-5 platforms.

[Kenneth Graunke]

We've already required Kernel 3.6 on Gen6+ since Mesa 9.2 (May 2013,
commit 92d2f5acfadea672417b6785710c9e8b7f605e41).  It seems reasonable
to require it for Gen4-5 as well, bumping the requirement from 2.6.39.

This is necessary for glClientWaitSync with a timeout to work, which
is a feature we expose on Gen4-5.  Without it, we would fall back to an
infinite wait, which is pretty bad.

See kernel commit 172cf15d18889313bf2c3bfb81fcea08369274ef in 3.6+.

Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_context.c  | 2 +-
 src/mesa/drivers/dri/i965/intel_screen.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 648ae508145..e4e8b30c9f0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1094,7 +1094,7 @@ brwCreateContext(gl_api api,
   brw->hw_ctx = drm_intel_gem_context_create(brw->bufmgr);
 
   if (!brw->hw_ctx) {
- fprintf(stderr, "Gen6+ requires Kernel 3.6 or later.\n");
+ fprintf(stderr, "Failed to create hardware context.\n");
  intelDestroyContext(driContextPriv);
  return false;
   }
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index a35cf69eede..2c5e502e5ef 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1273,8 +1273,8 @@ intel_init_bufmgr(struct intel_screen *screen)
 
drm_intel_bufmgr_gem_enable_fenced_relocs(screen->bufmgr);
 
-   if (!intel_get_boolean(screen, I915_PARAM_HAS_RELAXED_DELTA)) {
-  fprintf(stderr, "[%s: %u] Kernel 2.6.39 required.\n", __func__, 
__LINE__);
+   if (!intel_get_boolean(screen, I915_PARAM_HAS_WAIT_TIMEOUT)) {
+  fprintf(stderr, "[%s: %u] Kernel 3.6 required.\n", __func__, __LINE__);
   return false;
}
 
-- 
2.12.0

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Rob Clark  writes:

> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
>> can't say for sure it's going to be around forever, but its been in 
>> development
>> since late 2012 and still lands several patches a day, they were responsive 
>> to
>> me when I sent a patch (that I still need to respin), and they seem to be
>> picking up momentum from downstreams.
>
>
> btw, possibly newbie question, but from what I can tell so far in
> meson docs, there are separate 'meson build && cd build && ninja'
> steps.. one nice thing about autotools is 'git pull && make' (and it
> somehow magically figures out whether to re-automake/autoconf).  Not
> sure if there is a way to do something like that in meson.

Consider meson build to be ./autogen.sh.  After that point you can git
pull && make.


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] anv/nir: Delete the apply_dynamic_offsets prototype

[Jason Ekstrand]

That pass hasn't existed since dd4db84640bbb694f180dd50850c3388f67228be
but the prototype stuck around for no reason.
---
 src/intel/vulkan/anv_nir.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/intel/vulkan/anv_nir.h b/src/intel/vulkan/anv_nir.h
index a929dd9..3f97701 100644
--- a/src/intel/vulkan/anv_nir.h
+++ b/src/intel/vulkan/anv_nir.h
@@ -35,9 +35,6 @@ void anv_nir_lower_input_attachments(nir_shader *shader);
 
 void anv_nir_lower_push_constants(nir_shader *shader);
 
-void anv_nir_apply_dynamic_offsets(struct anv_pipeline *pipeline,
-   nir_shader *shader,
-   struct brw_stage_prog_data *prog_data);
 void anv_nir_apply_pipeline_layout(struct anv_pipeline *pipeline,
nir_shader *shader,
struct brw_stage_prog_data *prog_data,
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in 
> development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.


btw, possibly newbie question, but from what I can tell so far in
meson docs, there are separate 'meson build && cd build && ninja'
steps.. one nice thing about autotools is 'git pull && make' (and it
somehow magically figures out whether to re-automake/autoconf).  Not
sure if there is a way to do something like that in meson.

(I nearly always use separate build and debug builddirs w/ autotools,
so that part I don't mind.. you can git-pull from a subdir fo the git
tree)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> Quoting Rob Clark (2017-03-22 10:07:54)
>> I guess an interesting question (from someone who doesn't know meson
>> yet) would be whether meson could slurp in the Makefile.sources type
>> stuff that we have, which are shared so far between
>> android/scons/autotools (and for the most part, kept developers from
>> having to care *too* much about the different build systems)
>
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.

I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
>
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.

I guess from my PoV with my developer hat on, as long as simple things
like adding/removing src files to an existing .so or .a require just
editing one build file for all build systems, that pretty much
guarantees that I don't forget to update one and anger
windows/android/$other_random_thing builders ;-)

(with my $enterprise_distro hat on, I think *probably* the main thing
is that we don't drop autotools build support before
gnome/gstreamer/etc.. not 100% sure about the py3 dependency but I
guess if we aren't the only one that needs it to build, that helps..)

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

Re: [Mesa-dev] [PATCH 2/8] genxml: Generate header genX_bits.h

[Chad Versace]

On Wed 22 Mar 2017, Jason Ekstrand wrote:
> On Wed, Mar 22, 2017 at 2:02 PM, Chad Versace 
> wrote:
> 
> > On Wed 22 Mar 2017, Jason Ekstrand wrote:
> > > Wow... This is an impressive quantity of infastructure just to get the
> > > number of bits in a field...
> >
> > In the initial patch, I hand-wrote macros and functions. And I made
> > mistakes. That's when I decided to eliminate the mistakes with
> > generation. That's why we have the genxml, after all.
> >
> > > On Tue, Mar 21, 2017 at 4:02 PM, Chad Versace 
> > > wrote:
> >
> >
> > > > +REGEX = re.compile('^#define (?PGEN(?P[0-
> > > > 9]+)_(?P\w*Surface(Q?)Pitch)_bits).*$')
> > > >
> > >
> > > Can we please not use XML to generate a header and then use regex to
> > parse
> > > the header?  Let's just use XML for both.
> > >
> > > I hate to ask for a rewrite, but you should have seen that coming...
> >
> > Argh... yes, I knew it was coming. Yes, I knew I shouldn't have. But it
> > was S easy.
> >
> > Now that I've had time to ponder my sin, I no longer want to maintain
> > a giant pile of Python "just to get the number of bits in a field". Let
> > me propose an alternative: Keep the Python changes to gen_pack_header.py
> > that emits the GEN_*Pitch_bits macros, but hand-write the genX_bits.h
> > headers. I think that's good compromise. What do you think?
> >
> 
> Seems reasonable.  You can even do a #define like so:
> 
> #define GENX_BITS_DECLARE_LOOKUP(field) \
>static inline uint32_t \
>field##_bits(const struct gen_device_info *devinfo) \
>{ \
>   switch (devinfo->gen) {
>   case 4: return devinfo->is_g4x ? GEN4_##field##_bits :
> GEN45_##field##_bits;
>   case 5: return GEN5_##field##_bits;
>   case 6: return GEN6_##field##_bits;
>   case 7: return devinfo->is_haswell ? GEN75_##field##_bits :
> GEN7_##field##_bits;
>   case 8: return GEN8_##field##_bits;
>   case 9: return GEN9_##field##_bits;
>   }
>}
> 
> GENX_BITS_DECLARE_LOOKUP(RENDER_SURFACE_STATE_SurfacePitch)

For the sake of ctags and grep, I'm going to avoid the macro.

> Unfortunately, this won't be able to deal with field renames but I think
> the right way to deal with that is to just fix the XML.  Also, I didn't
> think you actually could include all of the genX_pack headers at the same
> time due to name conflicts.  Is this not true?

Right. The gen*_pack.h headers conflict with each other.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/8] genxml: Generate header genX_bits.h

[Jason Ekstrand]

On Wed, Mar 22, 2017 at 2:02 PM, Chad Versace 
wrote:

> On Wed 22 Mar 2017, Jason Ekstrand wrote:
> > Wow... This is an impressive quantity of infastructure just to get the
> > number of bits in a field...
>
> In the initial patch, I hand-wrote macros and functions. And I made
> mistakes. That's when I decided to eliminate the mistakes with
> generation. That's why we have the genxml, after all.
>
> > On Tue, Mar 21, 2017 at 4:02 PM, Chad Versace 
> > wrote:
>
>
> > > +REGEX = re.compile('^#define (?PGEN(?P[0-
> > > 9]+)_(?P\w*Surface(Q?)Pitch)_bits).*$')
> > >
> >
> > Can we please not use XML to generate a header and then use regex to
> parse
> > the header?  Let's just use XML for both.
> >
> > I hate to ask for a rewrite, but you should have seen that coming...
>
> Argh... yes, I knew it was coming. Yes, I knew I shouldn't have. But it
> was S easy.
>
> Now that I've had time to ponder my sin, I no longer want to maintain
> a giant pile of Python "just to get the number of bits in a field". Let
> me propose an alternative: Keep the Python changes to gen_pack_header.py
> that emits the GEN_*Pitch_bits macros, but hand-write the genX_bits.h
> headers. I think that's good compromise. What do you think?
>

Seems reasonable.  You can even do a #define like so:

#define GENX_BITS_DECLARE_LOOKUP(field) \
   static inline uint32_t \
   field##_bits(const struct gen_device_info *devinfo) \
   { \
  switch (devinfo->gen) {
  case 4: return devinfo->is_g4x ? GEN4_##field##_bits :
GEN45_##field##_bits;
  case 5: return GEN5_##field##_bits;
  case 6: return GEN6_##field##_bits;
  case 7: return devinfo->is_haswell ? GEN75_##field##_bits :
GEN7_##field##_bits;
  case 8: return GEN8_##field##_bits;
  case 9: return GEN9_##field##_bits;
  }
   }

GENX_BITS_DECLARE_LOOKUP(RENDER_SURFACE_STATE_SurfacePitch)

Unfortunately, this won't be able to deal with field renames but I think
the right way to deal with that is to just fix the XML.  Also, I didn't
think you actually could include all of the genX_pack headers at the same
time due to name conflicts.  Is this not true?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker  wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python projects don't seem to take this very seriously. Either having
> >> conditionals in build files to support building with several meson
> >> versions or always requiring the latest and greatest version would be
> >> rather annoying.
> >
> > Meson makes backwards compatible changes, and the version can be
> > queried using `meson.version()`, which works using meson's version
> > comparison mechanism. I would say this about meson, it's not a 'python
> > project', it's 'a project written in python',
> 
> This is what I meant above, although I clearly didn't write it that way.

I don't think I was exactly clear in what I said either, I would describe SCons
as a "python project", and meson as a "project written in python", since SCons
is python and has some of the warts that make backwards compatibility in python
projects hard (changes that work in the majority case break in some niche use
cases), where meson has a parser/generator written in python.

> > and they've taken great pains to not expose python in meson, and
> > reserve the right to reimplement in a different language if python
> > becomes an issue.
> 
> Right. That helps avoid many of the issues e.g. Sphinx has with the
> configuration files being pure python.

Yes, sphinx's configuration files are awful for just that reason.

Dylan


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

Re: [Mesa-dev] [PATCH 2/8] genxml: Generate header genX_bits.h

[Chad Versace]

On Wed 22 Mar 2017, Emil Velikov wrote:
> Hi Chad,
> 
> Please keep Tapani in Cc for the next revision - I think he can manage
> the Android bits required.

Will do.

Also, I'm currently doing an initial build of android-ia, so I can stay
on top of the Android changes along with Tapani.

> There's a few small requests below, but don't bother if they're too
> time consuming.
> 
> On 21 March 2017 at 23:02, Chad Versace  wrote:
> 
> > +genxml/genX_bits.h: genxml/gen_bits_header.py
> > +genxml/genX_bits.h: $(GENXML_PACK_GENERATED_FILES)
> > +   $(MKDIR_GEN)
> > +   $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_bits_header.py \
> > +   $(GENXML_PACK_GENERATED_FILES) > $@ || ($(RM) $@; false)

> Please provide the file[name] directly to the script rather than
> piping stdout to file.

Sure. I can add an '-o' option. That is, if I don't discard the script
in v4 of the series.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/8] genxml: Generate header genX_bits.h

[Chad Versace]

On Wed 22 Mar 2017, Jason Ekstrand wrote:
> Wow... This is an impressive quantity of infastructure just to get the
> number of bits in a field...

In the initial patch, I hand-wrote macros and functions. And I made
mistakes. That's when I decided to eliminate the mistakes with
generation. That's why we have the genxml, after all.

> On Tue, Mar 21, 2017 at 4:02 PM, Chad Versace 
> wrote:


> > +REGEX = re.compile('^#define (?PGEN(?P[0-
> > 9]+)_(?P\w*Surface(Q?)Pitch)_bits).*$')
> >
> 
> Can we please not use XML to generate a header and then use regex to parse
> the header?  Let's just use XML for both.
> 
> I hate to ask for a rewrite, but you should have seen that coming...

Argh... yes, I knew it was coming. Yes, I knew I shouldn't have. But it
was S easy.

Now that I've had time to ponder my sin, I no longer want to maintain
a giant pile of Python "just to get the number of bits in a field". Let
me propose an alternative: Keep the Python changes to gen_pack_header.py
that emits the GEN_*Pitch_bits macros, but hand-write the genX_bits.h
headers. I think that's good compromise. What do you think?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two.  Meson supports
> > Windows so that's good.  But the big issue is our automated build
> > system.  Replacing SCons with Meson could be a big deal in that
> > context.  It would at least involve pulling Meson into our toolchain and
> > rewriting a bunch of Python code to grok Meson.  I'd have to go off and
> > investigate that to even see if it's a possibility.  Maybe next week.
> 
> 
> I don't have any experience with Meson.  But for the record I don't have 
> much love for SCons.  I long stopped using SCons for anything but Mesa.
> 
> And my have good experience with cmake + ninja/msvc is positive.  So 
> tools with similar architecture sound good overall.
> 
> In fact, knowing what I know now, if I could go back in time, to when I 
> evaluated CMake and SCons, I'd chose CMake.
> 
> 
> BTW, it seems that newer SCons will drop Python 2 support [1], which 
> might force us to rewrite a lot of SConsfiles/scripts any way.  So 
> perhaps that's a good time to evaluate migrating to something else.
> 
> 
> 
> That said, moving to another build system is always a herculian task. 
> Thought the benefit of having a single build system is appealing and 
> might save time down the line.
>
>
>
> But there are many questions I have about Meson:  how confident are we 
> on Meson?  Are big projects using it?  How sure are we that it won't 
> become abandonware in a few years time?  How does it compare with other 
> newer gen build systems?
> 

Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.

> 
> We also have special requirements: one is cross-build from Linux to 
> MinGW, which on Mesa case requires building portions of the tree twice 
> -- once for host -- another for cross-mingw.

Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2]. 

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation

Dylan


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

[Mesa-dev] [Bug 100218] [Clover] Handle -g passed as a compile option

[bugzilla-daemon]

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

--- Comment #2 from Jan Vesely  ---
Opencl defines are handled by clang and should not be set on command line, they
are also target specific (although cl_storage_class_specifiers is enabled on
all targets).

you can get the list of defines by running:
clang -dM -E -x cl -cl-std=cl1.1  - < /dev/null

for turks GPU:clang -cc1 -dM -E -x cl  -cl-std=cl1.1 -triple
r600-unknown-unknown -target-cpu turks - < /dev/null

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

Re: [Mesa-dev] [PATCH v2] nouveau: enable glsl/tgsi on-disk cache

[Timothy Arceri]

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

[Mesa-dev] [Bug 100201] llvmpipe Windows scons build with Visual Studio 2015 toolchain and LLVM 4.0 fails

[bugzilla-daemon]

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

Charles Huber  changed:

   What|Removed |Added

 CC||genpfa...@gmail.com

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic. 

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.

Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.

Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)

Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.

I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)

If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.

[1] https://godoc.org/github.com/google/blueprint
> 
> If so, that makes it easier to coexist with existing build systems.  I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)

I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.

Dylan


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

Re: [Mesa-dev] [PATCH] radeonsi: disable sinking common instructions down to the end block

[Andy Furniss]

Samuel Pitoiset wrote:

This patch has a minor issue for me using radeonsi on tonga.

ffmpeg vaapi hwdecode by cli or via mpv now produces the message

mesa: for the -simplifycfg-sink-common option: may only occur zero or 
one times!




On 03/15/2017 02:01 PM, Marek Olšák wrote:

On Wed, Mar 15, 2017 at 1:56 PM, Samuel Pitoiset
 wrote:



On 03/15/2017 01:51 PM, Marek Olšák wrote:


On Wed, Mar 15, 2017 at 1:21 AM, Samuel Pitoiset
 wrote:


Initially this was a workaround for a bug introduced in LLVM 4.0
in the SimplifyCFG pass that caused image instrinsics to disappear
(because they were badly sunk). Finally, this is a win because it
decreases SGPR spilling and increases the number of waves a bit.

Although, shader-db results are good I think we might want to
remove it in the future once the issue is fixed. For now, enable
it for LLVM >= 4.0.

This also fixes a rendering issue with the speedometer in Dirt Rally.

More information can be found here https://reviews.llvm.org/D26348.

Thanks to Dave Airlie for the patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99484
Signed-off-by: Samuel Pitoiset 
---

For those interested, here's the full shader-db report:

https://hastebin.com/osepehehat.pas

 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 5c63b732b3..4fb7a126e4 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 

 /* Data for if/else/endif and bgnloop/endloop control flow
structures.
  */
@@ -124,6 +125,11 @@ static void init_amdgpu_target()
LLVMInitializeAMDGPUTarget();
LLVMInitializeAMDGPUTargetMC();
LLVMInitializeAMDGPUAsmPrinter();
+
+#if HAVE_LLVM >= 0x0400
+   const char *argv[2] = {"mesa",
"-simplifycfg-sink-common=false"};
+   LLVMParseCommandLineOptions(2, argv, NULL);
+#endif



Would it possible to do:
if (HAVE_LLVM >= 0x0400) {
...
}

Also, Cc stable?



Your call. But if the issue is fixed at some point in 4.0.1 or 5.0 we
will
need to backport one more patch.


Since this only disables the problematic optimization, we can keep it
in stable and we won't have to backport anything else. (optimizations
are usually not accepted in stable)


Fine by me. I will add the cc tag and the FIXME comment before pushing.
Thanks.



Marek


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


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

Re: [Mesa-dev] [PATCH v2 2/5] intel: Move tools/decoder.[ch] to common/gen_decoder.[ch].

[Rob Herring]

On Wed, Mar 22, 2017 at 6:50 AM, Emil Velikov  wrote:
> n 21 March 2017 at 20:58, Kenneth Graunke  wrote:
>> On Tuesday, March 21, 2017 4:40:26 AM PDT Emil Velikov wrote:
>>> On 21 March 2017 at 11:14, Emil Velikov  wrote:
>>> > On 20 March 2017 at 22:04, Kenneth Graunke  wrote:
>>> >> This way they become part of libintel_common.la so I can use them in
>>> >> the i965 driver.
>>> >> ---
>>> >>  src/intel/Makefile.sources  | 2 ++
>>> >>  src/intel/Makefile.tools.am | 2 --
>>> >>  src/intel/{tools/decoder.c => common/gen_decoder.c} | 2 +-
>>> >>  src/intel/{tools/decoder.h => common/gen_decoder.h} | 6 +++---
>>> >>  src/intel/tools/aubinator.c | 2 +-
>>> >>  5 files changed, 7 insertions(+), 7 deletions(-)
>>> >>  rename src/intel/{tools/decoder.c => common/gen_decoder.c} (99%)
>>> >>  rename src/intel/{tools/decoder.h => common/gen_decoder.h} (98%)
>>> >>
>>> >> I'd forgotten than I still had my gross symlinking hack in the first
>>> >> version of this series.  Here's a new spin which does this "properly" :)
>>> >>
>>> > You can do the symlink if you want to - I don't mind. This approach
>>> > will "bloat" every binary that links with libintel_common, since we
>>> > don't ask the linker to garbage collect.
>>> > Admittedly we only care about the ANV case, so I'll just follow-up and
>>> > add the GC toggle ;-)
>>> >
>>> Scratch that we do enabled it for ANV ;-)
>>>
>>> You really nicely reworked [in 3/5] making the code "debug only", so
>>> perhaps can we guard the code in gen_decoder.c the same way ? ... But
>>> that may interact badly with aubinator :-\
>>> Another option would be to guard the code in ifndef ANDROID - like toggle.
>>>
>>> Otherwise one will need to copy the _xml.h rules in Android, alongside
>>> a dummy libmesa_genxml-like library. The latter of which will need to
>>> be added as LOCAL_WHOLE_STATIC_LIBRARIES [for libmesa_intel_common] to
>>> pull/generate the headers. At the same time none of it is used since
>>> Android never defines DEBUG ... nor does it use the linker garbage
>>> collector (GC_SECTIONS)
>>> Tapani feel free to grep mesa for GC_SECTIONS and use in Android.
>>
>> Ugh, good point - I forgot about Android (and SCons, but thankfully we
>> don't care about SCons here).  I don't have any clue how to test Android
>> builds, so I'm going to go ahead and land it as is (sorry!).
>>
> No need to apologise - I'm not expecting !Android people to have the
> setup and/or do Android builds.

Could we at least expect the !Android people to not commit things that
are known to break Android until the issue is solved?

I can't keep up with the breakage on Intel, so I guess I'll stop caring.

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

Re: [Mesa-dev] [PATCH] egl: Fix for not setting EGL_BAD_ALLOC on try to create multiple window surfaces on single window v2.

[Daniel Stone]

Hi Adrian,
Thanks for the patch! Some comments inline.

On 22 March 2017 at 13:40, Adrian Pielech  wrote:
> +struct list_head window_list = {NULL, NULL};
> +
> +/* Checks if a EGLWindow already have a created surface */
> +static inline bool
> +is_window_associated_with_surface(EGLNativeWindowType window)
> +{
> +   list_for_each_entry(struct window_list_item, item, _list, link) {
> +  if (item->native_window = window) {

This must be changed to == rather than =. Right now it will always
return a false positive.

> + return true;
> +  }
> +   }
> +
> +   return false;
> +}

I also can't see any locking associated with these (mutex/spinlock),
so this would in fact fail when multiple threads are
creating/destroying surfaces/displays simultaneously. Can you please
add some locking so that concurrent access succeeds?

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

[Mesa-dev] [PATCH] glx: Remove #include

[Adam Jackson]

We're not using anything in it, and we don't want to inherit struct
definitions from some other package anyway.

Signed-off-by: Adam Jackson 
---
 src/glx/glxconfig.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/glx/glxconfig.c b/src/glx/glxconfig.c
index e5718b1..0e1643f 100644
--- a/src/glx/glxconfig.c
+++ b/src/glx/glxconfig.c
@@ -32,7 +32,6 @@
  */
 
 #include 
-#include "GL/glxint.h"
 #include 
 #include 
 
-- 
2.9.3

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 17/03/17 02:28, Brian Paul wrote:

On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand > wrote:

On March 16, 2017 5:41:24 PM Emil Velikov > wrote:

On 17 March 2017 at 00:21, Dylan Baker > wrote:

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)

While I can see you're impressed by Meson, I would
kindly urge you to
not use it here. As you look closely you can see that
one could
trivially improve the times, yet the biggest thing is
that most of the
code in libdrm must go ;-)


Perhaps I wasn't clear enough, I don't really expect this to
land ever. I sent
it out more because I'd written it and it works and is a
useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds
isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be
4 minutes to 1
minute, and that is a huge difference in time.

You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any
situation.


Yes, you can't just linearly apply any scaling factor.  However,
when you build mesa on a machine with a decent number of threads (I
think our build machine for the CI system has 32 threads),
autotools+make is slow as mud.  Also, there's very little you can do
to speed up configure since it's a pile of shell and perl that
inherently runs single-threaded and is fairly complex due to mesa's
complicated dependencies.

As the port is not 1:1 wrt the autoconf one, the
performance numbers
above are comparing apples to oranges.


I fail to see what I'm missing from meson that would have an
effect on the
times I reported. There are some files that are installed by
autoconf that I
didn't bother to install with meson (because I don't expect
this to land). Since
I didn't time installs, I don't see how it isn't an apples
to apples comparison.

You already (explicitly) mentioned some differences. Admittedly
not a
deal breaker.

I understand that libdrm is a pessimal case for
recursive-make since most
sub folders contain < 5 C files, However, even if you were
to flatten the make
files meson+ninja would still be faster when you consider
that meson
configures and builds faster than autotools configures.

That's correct. If is so concerned - they should slim down the
configure.ac  ;-)


There are real limits as to what you can do there.

If you/others are unhappy with the build times of libdrm
- poke me on
IRC. I will give you some easy tips on how to improve those.

You have some good python knowledge - I would kindly
urge you to
improve/rewrite the slow and/or hacky python scripts we
have in mesa.
This is a topic that was mentioned multiple times, and a
part where
everyone will be glad to see some progress.

Thanks
Emil


The real goal here is to do mesa (in case I didn't make that
clear either), and
the advantage for mesa is not just performance, it's that
meson supports visual
studio on windows; which means that we could hopefully not
just get faster
builds, but also replace both autotools and scons with a
single build system.

Yes that was more than clear. Yet it won't fly, I'm afraid.

The VMWare people like their SCons,


??



How much?  I would really rather the VMWare people speak on behalf
of VMWare.  Meson is the single best shot we've ever had for
replacing both with one build system.  I'm sure the VMware people
would like to have a build system that gets maintained by the
community as a whole.


Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build
system.  Replacing SCons with Meson could be a big deal in that
context.  It would at least involve pulling Meson into our toolchain and
rewriting a bunch of Python code to grok Meson.  I'd have to go off and
investigate that to even see if it's a possibility.  Maybe next week.



I 

Re: [Mesa-dev] [PATCH v2 0/5] Android build clean-up and fixes

[Emil Velikov]

On 21 March 2017 at 18:51, Rob Herring  wrote:
> This is a series of clean-ups and fixes to get Mesa master building on
> AOSP master again. AOSP master recently changed from X.Y.Z versioning to
> just the letter commonly used. Primarily, dropping KitKat and earlier
> support removes most of the version number dependencies and fixes the
> build.
>
> I've dropped the hack for libmesa_amd_common. r600g and radeonsi are
> pretty broken and the hack alone is not enough. More work is needed.
>
Ack. Thank you for the update !
R-b and pushed to master.

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

Re: [Mesa-dev] Need to know which branch

[Anuj Phogat]

Hi,

The default branch is 'master' when you clone the Mesa git repository
and that's what we use for development. Branches other than master
are for stable releases, proof of concept and developer's choice.

-Anuj

On Wed, Mar 22, 2017 at 10:44 AM, swapnil  wrote:
> Hi,
>
> I want to know which branch should I start working I have no idea. I read
> the doc.When I check there are lots of branches. But one is specific no
> idea.
>
> Thanks
> Swapnil
> ___
> 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] Need to know which branch

[Matt Turner]

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

Re: [Mesa-dev] [PATCH] egl: Fix for not setting EGL_BAD_ALLOC on try to create multiple window surfaces on single window v2.

[Emil Velikov]

Hi Adrian,

Welcome to Mesa !

On 22 March 2017 at 13:40, Adrian Pielech  wrote:
> According to the EGL 1.5 spec, section 3.5.1, page 34,35
> eglCreateWindowSurface should return EGL_BAD_ALLOC if there is already
> surface for given window. Similarly it is written in EGL 1.4 spec,
> section 3.5.1, page 29.
>
> I apologize for small mistakes on earlier message...
>
... and there's no need to apologize ;-)

In case Eric's reply comes a bit overwhelming:

There's nothing fundamentally wrong with your work, it just doesn't
follow the surrounding coding style/conventions.
Please give it a bit of polish for v2.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Marek Olšák]

On Wed, Mar 22, 2017 at 6:26 PM, Jose Fonseca  wrote:
> On 16/03/17 22:36, Marek Olšák wrote:
>>
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> wouldn't like any project that I might be involved in to require ninja
>> for building.

I also use Qt Creator.

Here is the ninja branch that keeps errors in stderr:
https://github.com/dendy/ninja/tree/segmented-output

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

[Mesa-dev] Need to know which branch

[swapnil]

Hi,

I want to know which branch should I start working I have no idea. I 
read the doc.When I check there are lots of branches. But one is 
specific no idea.


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

Re: [Mesa-dev] [PATCH 2/8] genxml: Generate header genX_bits.h

[Emil Velikov]

Hi Chad,

Please keep Tapani in Cc for the next revision - I think he can manage
the Android bits required.

There's a few small requests below, but don't bother if they're too
time consuming.

On 21 March 2017 at 23:02, Chad Versace  wrote:

> +genxml/genX_bits.h: genxml/gen_bits_header.py
> +genxml/genX_bits.h: $(GENXML_PACK_GENERATED_FILES)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_bits_header.py \
> +   $(GENXML_PACK_GENERATED_FILES) > $@ || ($(RM) $@; false)
Please provide the file[name] directly to the script rather than
piping stdout to file.

> +/* THIS FILE HAS BEEN GENERATED, DO NOT HAND EDIT.
> + *
> + * Sizes of bitfields in genxml instructions, structures, and registers.
> + */
> +
> +#ifndef GENX_BITS_H
> +#define GENX_BITS_H
> +

> +
> +#endif /* GENX_BITS_H */
Here one can use the filename.

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

Re: [Mesa-dev] [PATCH] mesa/main: remove unused strndup.h include

[Juha-Pekka Heikkilä]

Reviewed-by: Juha-Pekka Heikkila 

:)

/Juha-Pekka


22. maaliskuuta 2017 18.58.13 GMT+02:00 Emil Velikov  
kirjoitti:
>From: Emil Velikov 
>
>No longer needed as of commit ac257f1070a ("glsl: calculate
>TOP_LEVEL_ARRAY_SIZE and STRIDE when adding resources")
>
>Cc: Juha-Pekka Heikkila 
>Reported-by: Juha-Pekka Heikkila 
>Signed-off-by: Emil Velikov 
>---
> src/mesa/main/shader_query.cpp | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/src/mesa/main/shader_query.cpp
>b/src/mesa/main/shader_query.cpp
>index 6e077623e15..6efbc379656 100644
>--- a/src/mesa/main/shader_query.cpp
>+++ b/src/mesa/main/shader_query.cpp
>@@ -38,7 +38,6 @@
> #include "compiler/glsl/ir.h"
> #include "compiler/glsl/program.h"
> #include "util/string_to_uint_map.h"
>-#include "util/strndup.h"
> 
> 
> static GLint
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 16/03/17 22:36, Marek Olšák wrote:

Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?

I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involved in to require ninja
for building.

Marek


Yes, that's an annoying behavior from ninja.

I use a simple shell script for IDEs that care about that (e.g., with 
QtCreator):


  $ cat `which ninja-stderr `
  #!/bin/sh
  ninja "$@" 1>&2

There's a rationale for ninja to behave like that -- ninja buffers the 
whole program output, but and they use a combined buffer for both stderr 
and stdout so lines appear in same order.  Still, it would be nice if 
they fixed this for everybody.


Jose

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 19:10, Matt Turner  wrote:
> On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov  
> wrote:
>> On 21 March 2017 at 18:06, Matt Turner  wrote:
>>> (1) Non-recursive automake is necessary for parallel build performance
>> Fully agree
>>
>>> (2) Non-recursive automake is intractably unmaintainable for
>>> sufficiently large projects
>> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable 
>> ?
>
> Not by itself.
>
> src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.
>
Perfect - I can sort out the ~60 gallium Makefiles which constitutes
in ~half of mesa quite quickly.
As those are sorted I'll look at the more picky ones and ensuring that
the contains remain as trivial as possible.

Will you/anyone be interested in skimming through the patches ?

>> Does it have "dist", "check", "distcheck" or less commonly used
>
> Our thinking is that by switching to a build system that doesn't
> require large amounts of generated code (configure, Makefile.in, etc),
> we will stop shipping the code generated by the build system in the
> tarballs (which would just be created by git archive). None of that is
> set in stone.
>
Where can I read-up on the discussion ?

Would be great if we don't bring back the flex/bison/other requirement
for people building from tarballs. Still ... there may be some good
arguments against that.

>> "ctags" "cscope"  targets ?
>
> I don't know.
>
>>> And it has momentum: libepoxy already has a Meson build system. Others
>>> in the X.Org community are experimenting with it for libinput, Wayland
>>> and Weston, and the xserver.
>>>
>>> All of that makes Meson very compelling.
>> That's the thing - I'm never said that it's _not_ a very compelling project.
>> I'm saying that it's not there yet - mostly due to the list above.
>
> Perfect. Since no one claimed it's "there yet" there is nothing to
> disagree about.

Ack. In the interim we can make our existing build more performant, right ?

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
>> Why bother, and why would we want this?  
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D= more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.
>
> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.
>

I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)

If so, that makes it easier to 

Re: [Mesa-dev] [PATCH 00/18] Good bye pragma once

[Emil Velikov]

On 22 March 2017 at 11:02, Juha-Pekka Heikkila
 wrote:
> On 20.03.2017 18:12, Emil Velikov wrote:
>>
>> Hi all,
>>
>> We have a strange mix of pragma once vs ifndef guards in-tree.
>>
>> Since the former is less common, and concluded as the 'wrong' way,
>> I've went ahead and purged them. As a since side effect I also fixed
>> all the headers in the respective folders which did not have either
>> guard.
>>
>> With this in mind, we have one instance remaining in i965 (props to a
>> python generator), and SWR driver is left untouched.
>>
>> The whole thing build fine on Linux (autotools, scons native and scons
>> cross compile with mingw) and Windows (via Appveyor).
>>
>> I don't expect any real reviews here but an Ack or two will be
>> appreciated.
>>
>
> I read them through and all look good, they also compile all ok on my box.
> Acked-by: Juha-Pekka Heikkila 
>
Perfect ! Thank you Juha-Pekka/others for taking a look !

> I noticed "util/strndup.h" is included only into linker.cpp and
> shader_query.cpp of which I didn't spot strndup being used anywhere in
> shader_query.cpp.
>
There should be patch for that in your inbox ;-)

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

[Mesa-dev] [PATCH] mesa/main: remove unused strndup.h include

[Emil Velikov]

From: Emil Velikov 

No longer needed as of commit ac257f1070a ("glsl: calculate
TOP_LEVEL_ARRAY_SIZE and STRIDE when adding resources")

Cc: Juha-Pekka Heikkila 
Reported-by: Juha-Pekka Heikkila 
Signed-off-by: Emil Velikov 
---
 src/mesa/main/shader_query.cpp | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 6e077623e15..6efbc379656 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -38,7 +38,6 @@
 #include "compiler/glsl/ir.h"
 #include "compiler/glsl/program.h"
 #include "util/string_to_uint_map.h"
-#include "util/strndup.h"
 
 
 static GLint
-- 
2.11.1

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||98238


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98238
[Bug 98238] Witcher 2: objects are black when changing lod on Radeon Pitcairn
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||98272


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98272
[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to
display anything on Radeon Polaris
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||98848


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98848
[Bug 98848] Master of Orion flickering / window destroy
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||98856


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98856
[Bug 98856] DIRT: Showdown broken graphics with Mesa built with -Ofast
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||98996


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98996
[Bug 98996] Counter Strike: Global Offensive performance on Radeon Polaris
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99136


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99136
[Bug 99136] Blood Effects corrupt graphics in Total War: Warhammer
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99656


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99656
[Bug 99656] strange planets on star conflict and game crashes if textures set
to high
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99730


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99730
[Bug 99730] Metro Redux game(s) needs override for midshader extension
declaration
-- 
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 99730] Metro Redux game(s) needs override for midshader extension declaration

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99813


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99813
[Bug 99813] F1 2015 rendering broken at medium quality
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99923


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99923
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light
room.
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||99762


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99762
[Bug 99762] "Black Mesa" not launching
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||5


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=5
[Bug 5] Dirt showdown very low fps (~3fps) after update mesa
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||100089


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=100089
[Bug 100089] [regression] [bisected] Space Run rendering issues
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||100239


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=100239
[Bug 100239] Incorrect rendering in CS:GO
-- 
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 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 Depends on||100019


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=100019
[Bug 100019] [bdw] GPU hang and application crash in Pillars of Eternity
(steam)
-- 
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 2/8] genxml: Generate header genX_bits.h

[Jason Ekstrand]

Wow... This is an impressive quantity of infastructure just to get the
number of bits in a field...

On Tue, Mar 21, 2017 at 4:02 PM, Chad Versace 
wrote:

> genX_bits.h contains the sizes of bitfields in genxml instructions,
> structures, and registers. It also defines some functions to query those
> sizes.
>
> Currently, the bitfields in genX_bits.h are those whose name matches
> /.*Surface(Q?)Pitch/.
>
> isl_surf_init() will use the new header to validate that requested
> pitches fit in their destination bitfields.
>
> What's currently in genX_bits.h:
>
>   - Each macro in gen*_pack.h that whose name matches
> /.*Surface(Q?)Pitch_bits$/ is also in genX_bits.h.
>
>   - For each set of macros whose name, after stripping the GEN prefix,
> is the same, genX_bits.h contains a query function. See the examples
> below.
>
> The generated file is not committed, so here are some excerpts:
>
> Example: The GEN7 and GEN6 sections:
>
> #define GEN7_RENDER_SURFACE_STATE_SurfacePitch_bits  18
> #define GEN7_RENDER_SURFACE_STATE_MCSSurfacePitch_bits9
> #define GEN7_3DSTATE_DEPTH_BUFFER_SurfacePitch_bits  18
> #define GEN7_3DSTATE_HIER_DEPTH_BUFFER_SurfacePitch_bits 17
> #define GEN7_3DSTATE_STENCIL_BUFFER_SurfacePitch_bits17
>
> #define GEN6_RENDER_SURFACE_STATE_SurfacePitch_bits  17
> #define GEN6_3DSTATE_DEPTH_BUFFER_SurfacePitch_bits  17
> #define GEN6_3DSTATE_HIER_DEPTH_BUFFER_SurfacePitch_bits 17
> #define GEN6_3DSTATE_STENCIL_BUFFER_SurfacePitch_bits17
>
> Example: The SurfacePitch and AuxiliarySurfacePitch functions for
> RENDER_SURFACE_STATE:
>
>static inline uint32_t __attribute__((const))
>RENDER_SURFACE_STATE_SurfacePitch_bits(int gen_10x)
>{
>   switch (gen_10x) {
>   case 90: return GEN9_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 80: return GEN8_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 75: return GEN75_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 70: return GEN7_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 60: return GEN6_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 50: return GEN5_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 45: return GEN45_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   case 40: return GEN4_RENDER_SURFACE_STATE_SurfacePitch_bits;
>   default: return 0;
>   }
>}
>
>static inline uint32_t __attribute__((const))
>RENDER_SURFACE_STATE_AuxiliarySurfacePitch_bits(int gen_10x)
>{
>   switch (gen_10x) {
>   case 90: return GEN9_RENDER_SURFACE_STATE_
> AuxiliarySurfacePitch_bits;
>   case 80: return GEN8_RENDER_SURFACE_STATE_
> AuxiliarySurfacePitch_bits;
>   case 75: return GEN75_RENDER_SURFACE_STATE_MCSSurfacePitch_bits;
>   case 70: return GEN7_RENDER_SURFACE_STATE_MCSSurfacePitch_bits;
>   default: return 0;
>   }
>}
> ---
>  src/intel/Makefile.genxml.am|   9 +-
>  src/intel/Makefile.sources  |   6 +-
>  src/intel/genxml/.gitignore |   1 +
>  src/intel/genxml/gen_bits_header.py | 164 ++
> ++
>  4 files changed, 178 insertions(+), 2 deletions(-)
>  create mode 100644 src/intel/genxml/gen_bits_header.py
>
> diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
> index bea0aab817f..586e551e79b 100644
> --- a/src/intel/Makefile.genxml.am
> +++ b/src/intel/Makefile.genxml.am
> @@ -29,7 +29,7 @@ EXTRA_DIST += \
>
>  SUFFIXES = _pack.h _xml.h .xml
>
> -$(GENXML_GENERATED_FILES): genxml/gen_pack_header.py
> +$(GENXML_PACK_GENERATED_FILES): genxml/gen_pack_header.py
>
>  .xml_pack.h:
> $(MKDIR_GEN)
> @@ -41,6 +41,12 @@ $(GENXML_GENERATED_FILES): genxml/gen_zipped_file.py
> $(MKDIR_GEN)
> $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_zipped_file.py $< >
> $@ || ($(RM) $@; false)
>
> +genxml/genX_bits.h: genxml/gen_bits_header.py
> +genxml/genX_bits.h: $(GENXML_PACK_GENERATED_FILES)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN) $(PYTHON2) $(srcdir)/genxml/gen_bits_header.py \
> +   $(GENXML_PACK_GENERATED_FILES) > $@ || ($(RM) $@; false)
> +
>  EXTRA_DIST += \
> genxml/gen4.xml \
> genxml/gen45.xml \
> @@ -50,6 +56,7 @@ EXTRA_DIST += \
> genxml/gen75.xml \
> genxml/gen8.xml \
> genxml/gen9.xml \
> +   genxml/genX_bits.h \
> genxml/genX_pack.h \
> genxml/gen_macros.h \
> genxml/gen_pack_header.py \
> diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
> index 839ea47d752..af85d448eb8 100644
> --- a/src/intel/Makefile.sources
> +++ b/src/intel/Makefile.sources
> @@ -107,7 +107,7 @@ COMPILER_FILES = \
>  COMPILER_GENERATED_FILES = \
> compiler/brw_nir_trig_workarounds.c
>
> -GENXML_GENERATED_FILES = \
> +GENXML_PACK_GENERATED_FILES = \
> genxml/gen4_pack.h \
> genxml/gen45_pack.h \
> 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Alex Deucher]

On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
> Why bother, and why would we want this?   
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson


I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.

Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.

my 2 cents.

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

[Mesa-dev] [Bug 69101] DRI PRIME: black window on Intel + Radeon Whistler

[bugzilla-daemon]

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

Vedran Miletić  changed:

   What|Removed |Added

 QA Contact||mesa-dev@lists.freedesktop.
   ||org
Summary|prime: black window |DRI PRIME: black window on
   ||Intel + Radeon Whistler

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