[Mesa-dev] [PATCH 4/6] egl/drm: Use modifiers for backbuffer creation

2017-03-13 Thread Ben Widawsky
Split into a separate patch from the previous patch as requested by
Emil.

Requeted-by: Emil Velikov 
Signed-off-by: Ben Widawsky 
---
 src/egl/drivers/dri2/platform_drm.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index e5e8c60596..cf35ce8a1f 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -230,10 +230,21 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
 
if (dri2_surf->back == NULL)
   return -1;
-   if (dri2_surf->back->bo == NULL)
-  dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_dri->base.base,
- surf->base.width, surf->base.height,
- surf->base.format, surf->base.flags);
+   if (dri2_surf->back->bo == NULL) {
+  if (surf->base.modifiers)
+ dri2_surf->back->bo = 
gbm_bo_create_with_modifiers(_dpy->gbm_dri->base.base,
+surf->base.width, 
surf->base.height,
+surf->base.format,
+
surf->base.modifiers,
+surf->base.count);
+  else
+ dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_dri->base.base,
+ surf->base.width,
+ surf->base.height,
+ surf->base.format,
+ surf->base.flags);
+
+   }
if (dri2_surf->back->bo == NULL)
   return -1;
 
-- 
2.12.0

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


[Mesa-dev] [PATCH 1/6] dri: Add an image creation with modifiers

2017-03-13 Thread Ben Widawsky
Modifiers will be obtained or guessed by the client and passed in during
image creation/import. In guessing, a client might decide to simply pass
along all known modifiers

This requires bumping the DRIimage version.

As of this patch, the modifiers aren't plumbed all the way down, this
patch simply makes sure the interface level stuff is correct.

v2: Don't allow usage + modifiers

v3: Make NAND actually NAND. Bug introduced in v2. (Jason)

v4:
- s/obtains/obtained (Jason)
- Pull out i965 imlemnentation into a later patch (Emil)

Cc: Jason Ekstrand 
Cc: Emil Velikov 
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 include/GL/internal/dri_interface.h | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index 598d111f33..53fac6fc3c 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1136,7 +1136,7 @@ struct __DRIdri2ExtensionRec {
  * extensions.
  */
 #define __DRI_IMAGE "DRI_IMAGE"
-#define __DRI_IMAGE_VERSION 13
+#define __DRI_IMAGE_VERSION 14
 
 /**
  * These formats correspond to the similarly named MESA_FORMAT_*
@@ -1257,6 +1257,8 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_NUM_PLANES   0x2009 /* available in versions 11 */
 
 #define __DRI_IMAGE_ATTRIB_OFFSET 0x200A /* available in versions 13 */
+#define __DRI_IMAGE_ATTRIB_MODIFIER_LOWER 0x200B /* available in versions 14 */
+#define __DRI_IMAGE_ATTRIB_MODIFIER_UPPER 0x200C /* available in versions 14 */
 
 enum __DRIYUVColorSpace {
__DRI_YUV_COLOR_SPACE_UNDEFINED = 0,
@@ -1468,6 +1470,29 @@ struct __DRIimageExtensionRec {
 */
void (*unmapImage)(__DRIcontext *context, __DRIimage *image, void *data);
 
+
+   /**
+* Creates an image with implementation's favorite modifiers.
+*
+* This acts like createImage except there is a list of modifiers passed in
+* which the implementation may selectively use to create the DRIimage. The
+* result should be the implementation selects one modifier (perhaps it 
would
+* hold on to a few and later pick).
+*
+* The created image should be destroyed with destroyImage().
+*
+* Returns the new DRIimage. The chosen modifier can be obtained later on
+* and passed back to things like the kernel's AddFB2 interface.
+*
+* \sa __DRIimageRec::createImage
+*
+* \since 14
+*/
+   __DRIimage *(*createImageWithModifiers)(__DRIscreen *screen,
+   int width, int height, int format,
+   const uint64_t *modifiers,
+   const unsigned int modifier_count,
+   void *loaderPrivate);
 };
 
 
-- 
2.12.0

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


[Mesa-dev] [PATCH 2/6] i965: Implement basic modifier image creation

2017-03-13 Thread Ben Widawsky
This is just a stub for now and will be filled in later.

This was split out of an earlier patch

Requested-by: Emil Velikov 
Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 38 
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 21786eb54a..39289967cd 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -510,10 +510,12 @@ intel_destroy_image(__DRIimage *image)
 }
 
 static __DRIimage *
-intel_create_image(__DRIscreen *dri_screen,
-  int width, int height, int format,
-  unsigned int use,
-  void *loaderPrivate)
+intel_create_image_common(__DRIscreen *dri_screen,
+  int width, int height, int format,
+  unsigned int use,
+  const uint64_t *modifiers,
+  unsigned count,
+  void *loaderPrivate)
 {
__DRIimage *image;
struct intel_screen *screen = dri_screen->driverPrivate;
@@ -521,6 +523,12 @@ intel_create_image(__DRIscreen *dri_screen,
int cpp;
unsigned long pitch;
 
+   /* Callers of this may specify a modifier, or a dri usage, but not both. The
+* newer modifier interface deprecates the older usage flags newer modifier
+* interface deprecates the older usage flags.
+*/
+   assert(!(use && count));
+
tiling = I915_TILING_X;
if (use & __DRI_IMAGE_USE_CURSOR) {
   if (width != 64 || height != 64)
@@ -550,6 +558,27 @@ intel_create_image(__DRIscreen *dri_screen,
return image;
 }
 
+static __DRIimage *
+intel_create_image(__DRIscreen *dri_screen,
+  int width, int height, int format,
+  unsigned int use,
+  void *loaderPrivate)
+{
+   return intel_create_image_common(dri_screen, width, height, format, use, 
NULL, 0,
+   loaderPrivate);
+}
+
+static __DRIimage *
+intel_create_image_with_modifiers(__DRIscreen *dri_screen,
+  int width, int height, int format,
+  const uint64_t *modifiers,
+  const unsigned count,
+  void *loaderPrivate)
+{
+   return intel_create_image_common(dri_screen, width, height, format, 0, NULL,
+0, loaderPrivate);
+}
+
 static GLboolean
 intel_query_image(__DRIimage *image, int attrib, int *value)
 {
@@ -840,6 +869,7 @@ static const __DRIimageExtension intelImageExtension = {
 .getCapabilities= NULL,
 .mapImage   = NULL,
 .unmapImage = NULL,
+.createImageWithModifiers   = intel_create_image_with_modifiers,
 };
 
 static int
-- 
2.12.0

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


[Mesa-dev] [PATCH 3/6] gbm: Introduce modifiers into surface/bo creation

2017-03-13 Thread Ben Widawsky
The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.

A getter() will be added later so that the user GBM will be able to
query what modifier should be used.

Only in surface creation, the modifiers are stored until the BO is
actually allocated. In regular buffer allocation, the correct modifier
can (will be, in future patches be chosen at creation time.

v2: Make sure to check if count is non-zero in addition to testing if
calloc fails. (Daniel)

v3: Remove "usage" and "flags" from modifier creation. Requested by
Kristian.

v4: Take advantage of the "INVALID" modifier added by the GET_PLANE2
series.

v5: Don't bother with storing modifiers for gbm_bo_create because that's
a synchronous operation and we can actually select the correct modifier
at create time (done in a later patch) (Jason)

Cc: Kristian Høgsberg 
Cc: Jason Ekstrand 
References (v4): 
https://lists.freedesktop.org/archives/intel-gfx/2017-January/116636.html
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 src/gbm/backends/dri/gbm_dri.c | 62 --
 src/gbm/gbm-symbols-check  |  2 ++
 src/gbm/main/gbm.c | 39 --
 src/gbm/main/gbm.h | 12 
 src/gbm/main/gbmint.h  | 12 ++--
 5 files changed, 115 insertions(+), 12 deletions(-)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 7106dc1229..1224ce4476 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1023,13 +1023,20 @@ free_bo:
 static struct gbm_bo *
 gbm_dri_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
-  uint32_t format, uint32_t usage)
+  uint32_t format, uint32_t usage,
+  const uint64_t *modifiers,
+  const unsigned int count)
 {
struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_bo *bo;
int dri_format;
unsigned dri_use = 0;
 
+   /* Callers of this may specify a modifier, or a dri usage, but not both. The
+* newer modifier interface deprecates the older usage flags.
+*/
+   assert(!(usage && count));
+
if (usage & GBM_BO_USE_WRITE || dri->image == NULL)
   return create_dumb(gbm, width, height, format, usage);
 
@@ -1087,11 +1094,24 @@ gbm_dri_bo_create(struct gbm_device *gbm,
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;
 
-   bo->image =
-  dri->image->createImage(dri->screen,
-  width, height,
-  dri_format, dri_use,
-  bo);
+   if (!dri->image || dri->image->base.version < 14 ||
+   !dri->image->createImageWithModifiers) {
+  if (modifiers) {
+ fprintf(stderr, "Modifiers specified, but DRI is too old\n");
+ errno = ENOSYS;
+ goto failed;
+  }
+
+  bo->image = dri->image->createImage(dri->screen, width, height,
+  dri_format, dri_use, bo);
+   } else {
+  bo->image =
+ dri->image->createImageWithModifiers(dri->screen,
+  width, height,
+  dri_format,
+  modifiers, count,
+  bo);
+   }
if (bo->image == NULL)
   goto failed;
 
@@ -1165,19 +1185,44 @@ gbm_dri_bo_unmap(struct gbm_bo *_bo, void *map_data)
 static struct gbm_surface *
 gbm_dri_surface_create(struct gbm_device *gbm,
uint32_t width, uint32_t height,
-  uint32_t format, uint32_t flags)
+  uint32_t format, uint32_t flags,
+   const uint64_t *modifiers, const unsigned count)
 {
+   struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_surface *surf;
 
+   if (modifiers &&
+   (!dri->image || dri->image->base.version < 14 ||
+!dri->image->createImageWithModifiers)) {
+  errno = ENOSYS;
+  return NULL;
+   }
+
surf = calloc(1, sizeof *surf);
-   if (surf == NULL)
+   if (surf == NULL) {
+  errno = ENOMEM;
   return NULL;
+   }
 
surf->base.gbm = gbm;
surf->base.width = width;
surf->base.height = height;
surf->base.format = format;
surf->base.flags = flags;
+   if (!modifiers) {
+  assert(!count);
+  return >base;
+   }
+
+   surf->base.modifiers = calloc(count, sizeof(*modifiers));
+   if (count && !surf->base.modifiers) {
+  errno = ENOMEM;
+  

[Mesa-dev] [PATCH 6/6] gbm: Export a get modifiers

2017-03-13 Thread Ben Widawsky
This patch originally had i965 specific code and was named:
commit 61cd3c52b868cf8cb90b06e53a382a921eb42754
Author: Ben Widawsky 
Date:   Thu Oct 20 18:21:24 2016 -0700

gbm: Get modifiers from DRI

To accomplish this, two new query tokens are added to the extension:
__DRI_IMAGE_ATTRIB_MODIFIER_UPPER
__DRI_IMAGE_ATTRIB_MODIFIER_LOWER

The query extension only supported 32b queries, and modifiers are 64b,
so we needed two of them.

NOTE: The extension version is still set to 13, so none of this will
actually be called.

v2: Error handling of queryImage (Emil)

Signed-off-by: Ben Widawsky 
Reviewed-by: Jason Ekstrand 
Reviewed-by: Emil Velikov 
---
 src/gbm/backends/dri/gbm_dri.c | 42 ++
 src/gbm/gbm-symbols-check  |  1 +
 src/gbm/main/gbm.c | 19 +++
 src/gbm/main/gbm.h |  3 +++
 src/gbm/main/gbmint.h  |  1 +
 5 files changed, 66 insertions(+)

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 1224ce4476..dbeb3ad907 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include  /* dri_interface needs GL types */
 #include 
@@ -53,6 +54,14 @@
 #include "../../../egl/wayland/wayland-drm/wayland-drm.h"
 #endif
 
+#ifndef DRM_FORMAT_MOD_INVALID
+#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
+#endif
+
+#ifndef DRM_FORMAT_MOD_LINEAR
+#define DRM_FORMAT_MOD_LINEAR 0
+#endif
+
 static __DRIimage *
 dri_lookup_egl_image(__DRIscreen *screen, void *image, void *data)
 {
@@ -735,6 +744,38 @@ gbm_dri_bo_get_offset(struct gbm_bo *_bo, int plane)
return (uint32_t)offset;
 }
 
+static uint64_t
+gbm_dri_bo_get_modifier(struct gbm_bo *_bo)
+{
+   struct gbm_dri_device *dri = gbm_dri_device(_bo->gbm);
+   struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
+
+   if (!dri->image || dri->image->base.version < 14) {
+  errno = ENOSYS;
+  return DRM_FORMAT_MOD_INVALID;
+   }
+
+   /* Dumb buffers have no modifiers */
+   if (!bo->image)
+  return DRM_FORMAT_MOD_LINEAR;
+
+   uint64_t ret = 0;
+   int mod;
+   if (!dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_MODIFIER_UPPER,
+   ))
+  return DRM_FORMAT_MOD_INVALID;
+
+   ret = (uint64_t)mod << 32;
+
+   if (!dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_MODIFIER_LOWER,
+   ))
+  return DRM_FORMAT_MOD_INVALID;
+
+   ret |= mod;
+
+   return ret;
+}
+
 static void
 gbm_dri_bo_destroy(struct gbm_bo *_bo)
 {
@@ -1277,6 +1318,7 @@ dri_device_create(int fd)
dri->base.base.bo_get_handle = gbm_dri_bo_get_handle_for_plane;
dri->base.base.bo_get_stride = gbm_dri_bo_get_stride;
dri->base.base.bo_get_offset = gbm_dri_bo_get_offset;
+   dri->base.base.bo_get_modifier = gbm_dri_bo_get_modifier;
dri->base.base.bo_destroy = gbm_dri_bo_destroy;
dri->base.base.destroy = dri_destroy;
dri->base.base.surface_create = gbm_dri_surface_create;
diff --git a/src/gbm/gbm-symbols-check b/src/gbm/gbm-symbols-check
index 0550baddc4..6a9af0c59d 100755
--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check
@@ -23,6 +23,7 @@ gbm_bo_get_handle
 gbm_bo_get_fd
 gbm_bo_get_plane_count
 gbm_bo_get_handle_for_plane
+gbm_bo_get_modifier
 gbm_bo_write
 gbm_bo_set_user_data
 gbm_bo_get_user_data
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 7bacd8b86a..19dc5db901 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -280,6 +280,25 @@ gbm_bo_get_handle_for_plane(struct gbm_bo *bo, int plane)
return bo->gbm->bo_get_handle(bo, plane);
 }
 
+/**
+ * Get the chosen modifier for the buffer object
+ *
+ * This function returns the modifier that was chosen for the object. These
+ * properties may be generic, or platform/implementation dependent.
+ *
+ * \param bo The buffer object
+ * \return Returns the selected modifier (chosen by the implementation) for the
+ * BO.
+ * \sa gbm_bo_create_with_modifiers() where possible modifiers are set
+ * \sa gbm_surface_create_with_modifiers() where possible modifiers are set
+ * \sa define DRM_FORMAT_MOD_* in drm_fourcc.h for possible modifiers
+ */
+GBM_EXPORT uint64_t
+gbm_bo_get_modifier(struct gbm_bo *bo)
+{
+   return bo->gbm->bo_get_modifier(bo);
+}
+
 /** Write data into the buffer object
  *
  * If the buffer object was created with the GBM_BO_USE_WRITE flag,
diff --git a/src/gbm/main/gbm.h b/src/gbm/main/gbm.h
index 5f588dab58..a774b50951 100644
--- a/src/gbm/main/gbm.h
+++ b/src/gbm/main/gbm.h
@@ -327,6 +327,9 @@ gbm_bo_get_handle(struct gbm_bo *bo);
 int
 gbm_bo_get_fd(struct gbm_bo *bo);
 
+uint64_t
+gbm_bo_get_modifier(struct gbm_bo *bo);
+
 int
 gbm_bo_get_plane_count(struct gbm_bo *bo);
 
diff --git a/src/gbm/main/gbmint.h b/src/gbm/main/gbmint.h
index d8c9f6e5d7..5ad85cc80f 100644
--- a/src/gbm/main/gbmint.h
+++ 

[Mesa-dev] [PATCH 5/6] i965: introduce modifier selection.

2017-03-13 Thread Ben Widawsky
Nothing special here other than a brief introduction to modifier
selection. Originally this was part of another patch but was split out
from
gbm: Introduce modifiers into surface/bo creation by request of Emil.

Requested-by: Emil Velikov 
Signed-off-by: Ben Widawsky 
---
 src/mesa/drivers/dri/i965/intel_screen.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 39289967cd..cc695d383b 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -41,6 +41,10 @@
 #include "utils.h"
 #include "xmlpool.h"
 
+#ifndef DRM_FORMAT_MOD_INVALID
+#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
+#endif
+
 static const __DRIconfigOptionsExtension brw_config_options = {
.base = { __DRI_CONFIG_OPTIONS, 1 },
.xml =
@@ -509,6 +513,15 @@ intel_destroy_image(__DRIimage *image)
free(image);
 }
 
+static uint64_t
+select_best_modifier(struct gen_device_info *devinfo,
+ const uint64_t *modifiers,
+ const unsigned count)
+{
+   /* Modifiers are not supported by this DRI driver */
+   return DRM_FORMAT_MOD_INVALID;
+}
+
 static __DRIimage *
 intel_create_image_common(__DRIscreen *dri_screen,
   int width, int height, int format,
@@ -529,6 +542,12 @@ intel_create_image_common(__DRIscreen *dri_screen,
 */
assert(!(use && count));
 
+   uint64_t modifier = select_best_modifier(>devinfo, modifiers, 
count);
+   assert(modifier == DRM_FORMAT_MOD_INVALID);
+
+   /* Historically, X-tiled was the default, and so lack of modifier means
+* X-tiled.
+*/
tiling = I915_TILING_X;
if (use & __DRI_IMAGE_USE_CURSOR) {
   if (width != 64 || height != 64)
-- 
2.12.0

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


Re: [Mesa-dev] [PATCH] radv: trivial tidy ups

2017-03-13 Thread Edward O'Callaghan
Reviewed-by: Edward O'Callaghan 

On 03/14/2017 03:50 PM, Timothy Arceri wrote:
> ---
>  src/amd/vulkan/radv_pipeline.c   | 6 +-
>  src/amd/vulkan/radv_pipeline_cache.c | 1 +
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 723c32c..06e7446 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -34,20 +34,21 @@
>  #include 
>  #include 
>  
>  #include "sid.h"
>  #include "r600d_common.h"
>  #include "ac_binary.h"
>  #include "ac_llvm_util.h"
>  #include "ac_nir_to_llvm.h"
>  #include "vk_format.h"
>  #include "util/debug.h"
> +
>  void radv_shader_variant_destroy(struct radv_device *device,
>   struct radv_shader_variant *variant);
>  
>  static const struct nir_shader_compiler_options nir_options = {
>   .vertex_id_zero_based = true,
>   .lower_scmp = true,
>   .lower_flrp32 = true,
>   .lower_fsat = true,
>   .lower_pack_snorm_2x16 = true,
>   .lower_pack_snorm_4x8 = true,
> @@ -243,28 +244,24 @@ radv_shader_compile_to_nir(struct radv_device *device,
>   /* Now that we've deleted all but the main function, we can go 
> ahead and
>* lower the rest of the constant initializers.
>*/
>   NIR_PASS_V(nir, nir_lower_constant_initializers, ~0);
>   NIR_PASS_V(nir, nir_lower_system_values);
>   }
>  
>   /* Vulkan uses the separate-shader linking model */
>   nir->info->separate_shader = true;
>  
> - //   nir = brw_preprocess_nir(compiler, nir);
> -
>   nir_shader_gather_info(nir, entry_point->impl);
>  
>   nir_variable_mode indirect_mask = 0;
> - //   if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
>   indirect_mask |= nir_var_shader_in;
> - //   if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
>   indirect_mask |= nir_var_local;
>  
>   nir_lower_indirect_derefs(nir, indirect_mask);
>  
>   static const nir_lower_tex_options tex_options = {
> .lower_txp = ~0,
>   };
>  
>   nir_lower_tex(nir, _options);
>  
> @@ -1524,21 +1521,20 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
>   const VkPipelineShaderStageCreateInfo *pStages[MESA_SHADER_STAGES] = { 
> 0, };
>   struct radv_shader_module *modules[MESA_SHADER_STAGES] = { 0, };
>   for (uint32_t i = 0; i < pCreateInfo->stageCount; i++) {
>   gl_shader_stage stage = ffs(pCreateInfo->pStages[i].stage) - 1;
>   pStages[stage] = >pStages[i];
>   modules[stage] = 
> radv_shader_module_from_handle(pStages[stage]->module);
>   }
>  
>   radv_pipeline_init_blend_state(pipeline, pCreateInfo, extra);
>  
> - /* */
>   if (modules[MESA_SHADER_VERTEX]) {
>   bool as_es = modules[MESA_SHADER_GEOMETRY] != NULL;
>   union ac_shader_variant_key key = 
> radv_compute_vs_key(pCreateInfo, as_es);
>  
>   pipeline->shaders[MESA_SHADER_VERTEX] =
>radv_pipeline_compile(pipeline, cache, 
> modules[MESA_SHADER_VERTEX],
>  
> pStages[MESA_SHADER_VERTEX]->pName,
>  MESA_SHADER_VERTEX,
>  
> pStages[MESA_SHADER_VERTEX]->pSpecializationInfo,
>  pipeline->layout, );
> diff --git a/src/amd/vulkan/radv_pipeline_cache.c 
> b/src/amd/vulkan/radv_pipeline_cache.c
> index 7fc4e78..296301d 100644
> --- a/src/amd/vulkan/radv_pipeline_cache.c
> +++ b/src/amd/vulkan/radv_pipeline_cache.c
> @@ -298,20 +298,21 @@ radv_pipeline_cache_insert_shader(struct 
> radv_pipeline_cache *cache,
>   return variant;
>  }
>  
>  struct cache_header {
>   uint32_t header_size;
>   uint32_t header_version;
>   uint32_t vendor_id;
>   uint32_t device_id;
>   uint8_t  uuid[VK_UUID_SIZE];
>  };
> +
>  void
>  radv_pipeline_cache_load(struct radv_pipeline_cache *cache,
>const void *data, size_t size)
>  {
>   struct radv_device *device = cache->device;
>   struct cache_header header;
>  
>   if (size < sizeof(header))
>   return;
>   memcpy(, data, sizeof(header));
> 



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


[Mesa-dev] [PATCH] radv: trivial tidy ups

2017-03-13 Thread Timothy Arceri
---
 src/amd/vulkan/radv_pipeline.c   | 6 +-
 src/amd/vulkan/radv_pipeline_cache.c | 1 +
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 723c32c..06e7446 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -34,20 +34,21 @@
 #include 
 #include 
 
 #include "sid.h"
 #include "r600d_common.h"
 #include "ac_binary.h"
 #include "ac_llvm_util.h"
 #include "ac_nir_to_llvm.h"
 #include "vk_format.h"
 #include "util/debug.h"
+
 void radv_shader_variant_destroy(struct radv_device *device,
  struct radv_shader_variant *variant);
 
 static const struct nir_shader_compiler_options nir_options = {
.vertex_id_zero_based = true,
.lower_scmp = true,
.lower_flrp32 = true,
.lower_fsat = true,
.lower_pack_snorm_2x16 = true,
.lower_pack_snorm_4x8 = true,
@@ -243,28 +244,24 @@ radv_shader_compile_to_nir(struct radv_device *device,
/* Now that we've deleted all but the main function, we can go 
ahead and
 * lower the rest of the constant initializers.
 */
NIR_PASS_V(nir, nir_lower_constant_initializers, ~0);
NIR_PASS_V(nir, nir_lower_system_values);
}
 
/* Vulkan uses the separate-shader linking model */
nir->info->separate_shader = true;
 
-   //   nir = brw_preprocess_nir(compiler, nir);
-
nir_shader_gather_info(nir, entry_point->impl);
 
nir_variable_mode indirect_mask = 0;
-   //   if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
indirect_mask |= nir_var_shader_in;
-   //   if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
indirect_mask |= nir_var_local;
 
nir_lower_indirect_derefs(nir, indirect_mask);
 
static const nir_lower_tex_options tex_options = {
  .lower_txp = ~0,
};
 
nir_lower_tex(nir, _options);
 
@@ -1524,21 +1521,20 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
const VkPipelineShaderStageCreateInfo *pStages[MESA_SHADER_STAGES] = { 
0, };
struct radv_shader_module *modules[MESA_SHADER_STAGES] = { 0, };
for (uint32_t i = 0; i < pCreateInfo->stageCount; i++) {
gl_shader_stage stage = ffs(pCreateInfo->pStages[i].stage) - 1;
pStages[stage] = >pStages[i];
modules[stage] = 
radv_shader_module_from_handle(pStages[stage]->module);
}
 
radv_pipeline_init_blend_state(pipeline, pCreateInfo, extra);
 
-   /* */
if (modules[MESA_SHADER_VERTEX]) {
bool as_es = modules[MESA_SHADER_GEOMETRY] != NULL;
union ac_shader_variant_key key = 
radv_compute_vs_key(pCreateInfo, as_es);
 
pipeline->shaders[MESA_SHADER_VERTEX] =
 radv_pipeline_compile(pipeline, cache, 
modules[MESA_SHADER_VERTEX],
   
pStages[MESA_SHADER_VERTEX]->pName,
   MESA_SHADER_VERTEX,
   
pStages[MESA_SHADER_VERTEX]->pSpecializationInfo,
   pipeline->layout, );
diff --git a/src/amd/vulkan/radv_pipeline_cache.c 
b/src/amd/vulkan/radv_pipeline_cache.c
index 7fc4e78..296301d 100644
--- a/src/amd/vulkan/radv_pipeline_cache.c
+++ b/src/amd/vulkan/radv_pipeline_cache.c
@@ -298,20 +298,21 @@ radv_pipeline_cache_insert_shader(struct 
radv_pipeline_cache *cache,
return variant;
 }
 
 struct cache_header {
uint32_t header_size;
uint32_t header_version;
uint32_t vendor_id;
uint32_t device_id;
uint8_t  uuid[VK_UUID_SIZE];
 };
+
 void
 radv_pipeline_cache_load(struct radv_pipeline_cache *cache,
 const void *data, size_t size)
 {
struct radv_device *device = cache->device;
struct cache_header header;
 
if (size < sizeof(header))
return;
memcpy(, data, sizeof(header));
-- 
2.9.3

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


[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

2017-03-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100073

--- Comment #38 from Timothy Arceri  ---
This bug report is closed. Please stop spamming it. We have already discussed
collisions on the mailing list [1] where these discussions belong.

https://lists.freedesktop.org/archives/mesa-dev/2017-February/145993.html

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


[Mesa-dev] Lets try that again. Proposal for merging GL dispatch (aka glthread)

2017-03-13 Thread Timothy Arceri

Hi all,

There hasn't been any major comments on V2 of the series [1] so I'll 
assume that's a good thing.


It seemed the biggest objection to not merging V1 was that some piglit 
tests were crashing, since that has been addressed I'm proposing we 
merge V2 as is.


The only opposition to merging V1 seemed to come from some Intel dev's 
and since there is no plan to enable it there I don't see anything else 
that should block this.


Tim

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

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


Re: [Mesa-dev] [PATCH] gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass expectations.

2017-03-13 Thread Roland Scheidegger
On second thought, you're quite right this is inconsistent. Especially
because the inputs must be "typeless" when there's no modifiers (the
instruction is not allowed to alter bits of the sources like ordinary
float instructions, since otherwise NaNs/denorms could get altered,
which of course would mean it couldn't be used for ints). Though mov is
quite similar there (just doesn't have that other input which really
isn't float...), and with mov we definitely need those float modifiers.
So yes, if not for some other api it probably wouldn't have ended up
like that. But OTOH I can't really see what's wrong with sources of
different types - src/dst can have different type certainly too, so this
isn't that much different.
And it looks noone else really has much of an opinion here :-).

So, thanks for fixing this,
Reviewed-by: Roland Scheidegger 

Am 14.03.2017 um 02:42 schrieb Francisco Jerez:
> Currently the GLSL-to-TGSI translation pass assumes it can use
> floating point source modifiers on the UCMP instruction.  See the bug
> report linked below for an example where an unrelated change in the
> GLSL built-in lowering code for atan2 (e9ffd12827ac11a2d2002a42fa8eb1)
> caused the generation of floating-point ir_unop_neg instructions
> followed by ir_triop_csel, which is translated into UCMP with a negate
> modifier on back-ends with native integer support.
> 
> Allowing floating-point source modifiers on an integer instruction
> seems like rather dubious design for a transport IR, since the same
> semantics could be represented as a sequence of MOV+UCMP instructions
> instead, but supposedly this matches the expectations of TGSI
> back-ends other than tgsi_exec, and the expectations of the DX10 API.
> I take no responsibility for future headaches caused by this
> inconsistency.
> 
> Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
> the above-mentioned glsl front-end commit.  Even though the commit
> that triggered the regression doesn't seem to have made it to any
> stable branches yet, this might be worth back-porting since I don't
> see any reason why the bug couldn't have been reproduced before that
> point.
> 
> Suggested-by: Roland Scheidegger 
> Bugzilla: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D99817=DwIBAg=uilaK90D4TOVoH58JNXRgQ=_QIjpv-UJ77xEQY8fIYoQtr5qv8wKrPJc7v7_-CYAb0=hkmif85VQrc5fwDTaj_73C02kjNzSg07RLEcuMm4iQc=Sgf_xfDN3C27aNU0MZAziGAjzORHSHvdgMYXND2348c=
>  
> ---
>  src/gallium/auxiliary/tgsi/tgsi_exec.c | 54 
> ++
>  src/gallium/docs/source/tgsi.rst   |  8 +++--
>  2 files changed, 46 insertions(+), 16 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
> b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> index 3c15306..48d91af 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> @@ -3359,6 +3359,46 @@ exec_up2h(struct tgsi_exec_machine *mach,
>  }
>  
>  static void
> +micro_ucmp(union tgsi_exec_channel *dst,
> +   const union tgsi_exec_channel *src0,
> +   const union tgsi_exec_channel *src1,
> +   const union tgsi_exec_channel *src2)
> +{
> +   dst->f[0] = src0->u[0] ? src1->f[0] : src2->f[0];
> +   dst->f[1] = src0->u[1] ? src1->f[1] : src2->f[1];
> +   dst->f[2] = src0->u[2] ? src1->f[2] : src2->f[2];
> +   dst->f[3] = src0->u[3] ? src1->f[3] : src2->f[3];
> +}
> +
> +static void
> +exec_ucmp(struct tgsi_exec_machine *mach,
> +  const struct tgsi_full_instruction *inst)
> +{
> +   unsigned int chan;
> +   struct tgsi_exec_vector dst;
> +
> +   for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
> +  if (inst->Dst[0].Register.WriteMask & (1 << chan)) {
> + union tgsi_exec_channel src[3];
> +
> + fetch_source(mach, [0], >Src[0], chan,
> +  TGSI_EXEC_DATA_UINT);
> + fetch_source(mach, [1], >Src[1], chan,
> +  TGSI_EXEC_DATA_FLOAT);
> + fetch_source(mach, [2], >Src[2], chan,
> +  TGSI_EXEC_DATA_FLOAT);
> + micro_ucmp([chan], [0], [1], [2]);
> +  }
> +   }
> +   for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
> +  if (inst->Dst[0].Register.WriteMask & (1 << chan)) {
> + store_dest(mach, [chan], >Dst[0], inst, chan,
> +TGSI_EXEC_DATA_FLOAT);
> +  }
> +   }
> +}
> +
> +static void
>  exec_scs(struct tgsi_exec_machine *mach,
>   const struct tgsi_full_instruction *inst)
>  {
> @@ -4997,18 +5037,6 @@ micro_uarl(union tgsi_exec_channel *dst,
> dst->i[3] = src->u[3];
>  }
>  
> -static void
> -micro_ucmp(union tgsi_exec_channel *dst,
> -   const union tgsi_exec_channel *src0,
> -   const union tgsi_exec_channel *src1,
> -   const union tgsi_exec_channel *src2)
> -{
> -   dst->u[0] = src0->u[0] ? src1->u[0] : src2->u[0];
> -   dst->u[1] = src0->u[1] ? src1->u[1] : src2->u[1];
> 

[Mesa-dev] [Bug 100073] Shader Disk Cache 32/64 bit detection has a flaw. Missed existence of x32 ABI

2017-03-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100073

--- Comment #37 from oia...@gmail.com ---
(In reply to Marek Olšák from comment #36)
> The build id and GPU id can be compared directly after the hash lookup and
> decompression to prevent collisions when two shaders with different IDs have
> the same hash. Thus we only have to worry about collisions between shaders
> having the same IDs.

This read we will deal with a collisions instead of avoiding collisions by
using more cpu cycles every time a shader is loaded this does not sound
particularly good for performance.

Build-id and gpu-id could be directories in the cache.   This would reduce the
number of entries you need to search for hits in and you would not find matches
with invalid values of build-id or gpu-id in the first place.   This means you
could skip checking for those value when loading a shader from cache because
only the correct files should in those directories unless user has done
something stupid.

If build-id and gpu-id were directories cache cleaning would be simpler.   Why
you could rm -rf the no longer required directories.   This would still keep
file names fairly clean.

Marek Olšák is really valid to waste cpu cycles checking Build-id and Gpu-id
when it can be done once when opening the directory to search for cache
entries.  I think not.   So I don't think build-id and gpu-id mixed into hash
would be a good thing.   

Build-id and gpu-id could be in the shader entries to detect if user has done
something bad to the cache with a audit tool but this is not something that has
to be run when a game is running.   But you do have to be careful with build-id
like appending the build-id on the end of the file past the point the hash was
calculated to so that collision are consistent.  Also keeping collision
possibilities consistent make it possible for application developers to work
around them if they ever happen.   

Performance does mean worrying about wasting cycles.   Reducing possibility of
collisions by design reduces how many cpu cycles you have to waste preventing
collision based errors.   You really don't want to have to be doing any extra
checks every time you access the cache thinking a shader cache should be
reasonably heavily used at times.

-- 
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] MESA and KOTOR

2017-03-13 Thread Brian Paul
Looks like my KOTOR patch never made it to master.  I'm attaching it 
below so you can try it.  I should commit it master.  In any case, let 
me know if it helps.


-Brian

On 03/13/2017 10:55 AM, Federico Dossena wrote:

Hi Jose, thanks for replying, I've seen your name inside many files in
mesa ;)

I have tried mesa master (previously I was using 17.0.1) but it still
crashes for the same null pointer.
Do you have a link to that patch you've mentioned for kotor?

I have used apitrace and took traces of both the nvidia driver (which
runs kotor) and mesa (up until the crash).
Here's a link to them:
https://drive.google.com/file/d/0B6qj91UlSYlYa3dIM0FtaHNULW8/view?usp=sharing


I tried reading them with the dump function but it's way above my
comprehension.

I know that some applications use wglGetProcAddress to check if an
extension if available, but I've seen KOTOR check for the
WGL_ARB_render_texture, and when it's present it enables frame buffer
effects and soft shadows, which use wglMakeContextCurrentARB (not
wglBindTexImageARB, I was wrong in my previous mail), which for some
reason is a null pointer.




Il 2017-03-13 14:39, Jose Fonseca ha scritto:

On 13/03/17 11:09, Emil Velikov wrote:

On 11 March 2017 at 11:51, Federico Dossena 
wrote:

In the last week I've been trying to bring an "old" game back to
life, Star
Wars Knights of the old republic (KOTOR, for short). It's from 2003
and uses
OpenGL 1.4.

I have used Mesa, libtxc_dxtn and some trickery to decompress the
textures
to boost performance, and right now I have it up and running
smoothly with
Gallium on LLVMPipe, compiled on Windows. (I can upload a copy if
someone is
interested). This took me about 2 days of compiling and figuring out
stuff.

Here's where the weirdness begins:
Turning on framebuffer effects or soft shadows make the game crash
right
after the menu. Using a disassembler and debugger and what little
knowledge
I have of reverse engineering, I managed to track down the issue to a
function which uses wglGetProcAddress to get the addresses of
several OpenGL
functions. Some of these calls return a null pointer (even if there
is a
valid context and it is current), and when the game tries to call
them, it
crashes. The first one that makes it crash is a pointer to
wglBindTexImageARB, but there are a few others. NOPing the offending
instructions did not work, and returning a nop function just makes
the game
display artifacts.


Strange - afaict mesa (st/wgl) exposes both wglBindTexImageARB and the
WGL_ARB_render_texture extension.
You can break on DrvGetProcAddress and trace where/how we end up with
NULL function pointer.

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



Federico,

You should be using latest master for this.   There have been recent
changes/fixes to our WGL implementation.


Last fall Brian Paul fixed an issue with WGL extension seen on KOTOR.
I'm not sure the the issue has been crossported to Mesa master yet,
and it might be unrelated.


Generally speaking, wglGetProcAddress returning NULL by itself is not
a problem.  Many games wrongly rely on wglGetProcAddress NULL results
to detect whether an GL/WGL extension is present (which goes against
the spec).  Other libraries try to bindly get every possible
entrypoint through wglGetProcAddress, then check which ones to use
based on supported extensions (which is actually fine by the spec.)


For the record, getting an apitrace is usually useful to debug this
sort of issues.  One can use apitrace straigh from windows or with
WINE -- https://github.com/apitrace/apitrace/wiki/WINE


Jose




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA=u9OxTt6a0b4XxAVoFjjG7RmQNYLAIe3smaD2NtY0mhE=jnsrLdbWwBr7d8cUeUr_dxHK8sN25_6TfLQjoVbMCj8=



>From 848472856ee20f324008f5dba7754c95ba4ff13c Mon Sep 17 00:00:00 2001
From: Brian Paul 
Date: Mon, 10 Oct 2016 15:54:09 -0600
Subject: [PATCH] stw/wgl: add null context check in wglBindTexImageARB()

To avoid dereferencing a null pointer in case wglMakeCurrent() wasn't
called.  Found while debugging SWKOTOR game.

Reviewed-by: Neha Bhende 
Reviewed-by: Charmaine Lee 
---
 src/gallium/state_trackers/wgl/stw_ext_rendertexture.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/gallium/state_trackers/wgl/stw_ext_rendertexture.c 

[Mesa-dev] [PATCH] nir: Rewrite nir_type_conversion_op

2017-03-13 Thread Jason Ekstrand
The original version was very convoluted and tried way too hard to not
just have the nested switch statement that it needs.  Let's just write
the obvious code and then we know it's correct.  This fixes a bunch of
missing cases particularly with int64.

---
This patch has to be inserted before the earlier patch I wrote to
glsl_to_nir which makes it use this function.  The function was sufficiently
broken that making glsl_to_nir use it regresses a bunch of stuff.

 src/compiler/nir/nir.c | 155 +
 1 file changed, 92 insertions(+), 63 deletions(-)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index a9fac96..37fd9cb 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1967,87 +1967,116 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type 
dst)
unsigned src_bitsize = nir_alu_type_get_type_size(src);
unsigned dst_bitsize = nir_alu_type_get_type_size(dst);
 
-   if (src_base_type == dst_base_type) {
-  if (src_bitsize == dst_bitsize)
- return (src_base_type == nir_type_float) ? nir_op_fmov : nir_op_imov;
-
-  assert(src_bitsize == 64 || dst_bitsize == 64);
-  if (src_base_type == nir_type_float)
- /* TODO: implement support for float16 */
- return (src_bitsize == 64) ? nir_op_d2f : nir_op_f2d;
-  else if (src_base_type == nir_type_uint)
- return (src_bitsize == 64) ? nir_op_imov : nir_op_u2u64;
-  else if (src_base_type == nir_type_int)
- return (src_bitsize == 64) ? nir_op_imov : nir_op_i2i64;
-  unreachable("Invalid conversion");
-   }
-
-   /* Different base type but same bit_size */
if (src_bitsize == dst_bitsize) {
-  /* TODO: This does not include specific conversions between
-   * signed or unsigned integer types of bit size different than 32 yet.
-   */
-  assert(src_bitsize == 32);
   switch (src_base_type) {
-  case nir_type_uint:
- return (dst_base_type == nir_type_float) ? nir_op_u2f : nir_op_imov;
   case nir_type_int:
- return (dst_base_type == nir_type_float) ? nir_op_i2f : nir_op_imov;
-  case nir_type_bool:
- return (dst_base_type == nir_type_float) ? nir_op_b2f : nir_op_b2i;
+  case nir_type_uint:
+ if (dst_base_type == nir_type_uint || dst_base_type == nir_type_int)
+return nir_op_imov;
+ break;
   case nir_type_float:
- switch (dst_base_type) {
- case nir_type_uint:
-return nir_op_f2u;
- case nir_type_bool:
-return nir_op_f2b;
- default:
-return nir_op_f2i;
- };
+ if (dst_base_type == nir_type_float)
+return nir_op_fmov;
+ break;
+  case nir_type_bool:
+ if (dst_base_type == nir_type_bool)
+return nir_op_imov;
+ break;
   default:
  unreachable("Invalid conversion");
-  };
+  }
}
 
-   /* Different bit_size and different base type */
-   /* TODO: Implement integer support for types with bit_size != 32 */
switch (src_base_type) {
-   case nir_type_uint:
-  if (dst == nir_type_float64)
- return nir_op_u2d;
-  else if (dst == nir_type_int64)
- return nir_op_u2i64;
-  break;
case nir_type_int:
-  if (dst == nir_type_float64)
- return nir_op_i2d;
-  else if (dst == nir_type_uint64)
- return nir_op_i2i64;
-  break;
-   case nir_type_bool:
-  assert(dst == nir_type_float64);
-  return nir_op_u2d;
-   case nir_type_float:
-  assert(src_bitsize == 32 || src_bitsize == 64);
-  if (src_bitsize != 64) {
- assert(dst == nir_type_float64);
- return nir_op_f2d;
+  switch (dst_base_type) {
+  case nir_type_int:
+ assert(src_bitsize != dst_bitsize);
+ return (dst_bitsize == 32) ? nir_op_i2i32 : nir_op_i2i64;
+  case nir_type_uint:
+ assert(src_bitsize != dst_bitsize);
+ return (dst_bitsize == 32) ? nir_op_i2u32 : nir_op_i2u64;
+  case nir_type_float:
+ switch (src_bitsize) {
+ case 32:
+return (dst_bitsize == 32) ? nir_op_i2f : nir_op_i2d;
+ case 64:
+return (dst_bitsize == 32) ? nir_op_i642f : nir_op_i642d;
+ default:
+unreachable("Invalid conversion");
+ }
+  case nir_type_bool:
+ return (src_bitsize == 32) ? nir_op_i2b : nir_op_i642b;
+  default:
+ unreachable("Invalid conversion");
   }
-  assert(dst_bitsize == 32);
+
+   case nir_type_uint:
   switch (dst_base_type) {
+  case nir_type_int:
+ assert(src_bitsize != dst_bitsize);
+ return (dst_bitsize == 32) ? nir_op_u2i32 : nir_op_u2i64;
   case nir_type_uint:
- return nir_op_d2u;
+ assert(src_bitsize != dst_bitsize);
+ return (dst_bitsize == 32) ? nir_op_u2u32 : nir_op_u2u64;
+  case nir_type_float:
+ switch (src_bitsize) {
+ case 32:

[Mesa-dev] [PATCH v2 15/18] anv: Pull the guts of cmd_buffer_execbuf into a helper

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_batch_chain.c | 55 +-
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index e5cc21d..c55938a 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -1223,21 +1223,18 @@ relocate_cmd_buffer(struct anv_cmd_buffer *cmd_buffer,
return true;
 }
 
-VkResult
-anv_cmd_buffer_execbuf(struct anv_device *device,
-   struct anv_cmd_buffer *cmd_buffer)
+static void
+setup_execbuf_for_cmd_buffer(struct anv_execbuf *execbuf,
+ struct anv_cmd_buffer *cmd_buffer)
 {
struct anv_batch *batch = _buffer->batch;
struct anv_block_pool *ss_pool =
   _buffer->device->surface_state_block_pool;
 
-   struct anv_execbuf execbuf;
-   anv_execbuf_init();
-
adjust_relocations_from_state_pool(ss_pool, _buffer->surface_relocs,
   cmd_buffer->last_ss_pool_center);
-   anv_execbuf_add_bo(, _pool->bo, _buffer->surface_relocs,
-  >alloc);
+   anv_execbuf_add_bo(execbuf, _pool->bo, _buffer->surface_relocs,
+  _buffer->device->alloc);
 
/* First, we walk over all of the bos we've seen and add them and their
 * relocations to the validate list.
@@ -1247,8 +1244,8 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   adjust_relocations_to_state_pool(ss_pool, &(*bbo)->bo, &(*bbo)->relocs,
cmd_buffer->last_ss_pool_center);
 
-  anv_execbuf_add_bo(, &(*bbo)->bo, &(*bbo)->relocs,
- >alloc);
+  anv_execbuf_add_bo(execbuf, &(*bbo)->bo, &(*bbo)->relocs,
+ _buffer->device->alloc);
}
 
/* Now that we've adjusted all of the surface state relocations, we need to
@@ -1265,19 +1262,19 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
 * corresponding to the first batch_bo in the chain with the last
 * element in the list.
 */
-   if (first_batch_bo->bo.index != execbuf.bo_count - 1) {
+   if (first_batch_bo->bo.index != execbuf->bo_count - 1) {
   uint32_t idx = first_batch_bo->bo.index;
-  uint32_t last_idx = execbuf.bo_count - 1;
+  uint32_t last_idx = execbuf->bo_count - 1;
 
-  struct drm_i915_gem_exec_object2 tmp_obj = execbuf.objects[idx];
-  assert(execbuf.bos[idx] == _batch_bo->bo);
+  struct drm_i915_gem_exec_object2 tmp_obj = execbuf->objects[idx];
+  assert(execbuf->bos[idx] == _batch_bo->bo);
 
-  execbuf.objects[idx] = execbuf.objects[last_idx];
-  execbuf.bos[idx] = execbuf.bos[last_idx];
-  execbuf.bos[idx]->index = idx;
+  execbuf->objects[idx] = execbuf->objects[last_idx];
+  execbuf->bos[idx] = execbuf->bos[last_idx];
+  execbuf->bos[idx]->index = idx;
 
-  execbuf.objects[last_idx] = tmp_obj;
-  execbuf.bos[last_idx] = _batch_bo->bo;
+  execbuf->objects[last_idx] = tmp_obj;
+  execbuf->bos[last_idx] = _batch_bo->bo;
   first_batch_bo->bo.index = last_idx;
}
 
@@ -1298,9 +1295,9 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   }
}
 
-   execbuf.execbuf = (struct drm_i915_gem_execbuffer2) {
-  .buffers_ptr = (uintptr_t) execbuf.objects,
-  .buffer_count = execbuf.bo_count,
+   execbuf->execbuf = (struct drm_i915_gem_execbuffer2) {
+  .buffers_ptr = (uintptr_t) execbuf->objects,
+  .buffer_count = execbuf->bo_count,
   .batch_start_offset = 0,
   .batch_len = batch->next - batch->start,
   .cliprects_ptr = 0,
@@ -1313,7 +1310,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   .rsvd2 = 0,
};
 
-   if (relocate_cmd_buffer(cmd_buffer, )) {
+   if (relocate_cmd_buffer(cmd_buffer, execbuf)) {
   /* If we were able to successfully relocate everything, tell the kernel
* that it can skip doing relocations. The requirement for using
* NO_RELOC is:
@@ -1338,7 +1335,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
* the RENDER_SURFACE_STATE matches presumed_offset, so it should be
* safe for the kernel to relocate them as needed.
*/
-  execbuf.execbuf.flags |= I915_EXEC_NO_RELOC;
+  execbuf->execbuf.flags |= I915_EXEC_NO_RELOC;
} else {
   /* In the case where we fall back to doing kernel relocations, we need
* to ensure that the relocation list is valid.  All relocations on the
@@ -1352,6 +1349,16 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
   for (size_t i = 0; i < cmd_buffer->surface_relocs.num_relocs; i++)
  cmd_buffer->surface_relocs.relocs[i].presumed_offset = -1;
}
+}
+
+VkResult
+anv_cmd_buffer_execbuf(struct anv_device *device,
+   struct anv_cmd_buffer *cmd_buffer)
+{
+   struct anv_execbuf execbuf;
+   anv_execbuf_init();
+
+   setup_execbuf_for_cmd_buffer(, cmd_buffer);
 
VkResult result = anv_device_execbuf(device, , execbuf.bos);
 

[Mesa-dev] [PATCH v2 12/18] anv: Implement VK_KHX_external_semaphore_capabilities

2017-03-13 Thread Jason Ekstrand
This just stubs things out.  Real external semaphore support will come
with VK_KHX_external_semaphore_fd.
---
 src/intel/vulkan/anv_device.c   |  4 
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 src/intel/vulkan/anv_queue.c| 13 +
 3 files changed, 18 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3b7ff7b..3674029 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -288,6 +288,10 @@ static const VkExtensionProperties global_extensions[] = {
   .extensionName = VK_KHX_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_SEMAPHORE_CAPABILITIES_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static const VkExtensionProperties device_extensions[] = {
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index 7d7ea5e..562ee49 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -42,6 +42,7 @@ supported_extensions = [
'VK_KHX_external_memory',
'VK_KHX_external_memory_capabilities',
'VK_KHX_external_memory_fd',
+   'VK_KHX_external_semaphore_capabilities',
 ]
 
 # We generate a static hash table for entry point lookup
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index 0bd0ca8..dfb54bc 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -488,3 +488,16 @@ void anv_DestroySemaphore(
 
vk_free2(>alloc, pAllocator, semaphore);
 }
+
+void anv_GetPhysicalDeviceExternalSemaphorePropertiesKHX(
+VkPhysicalDevicephysicalDevice,
+const VkPhysicalDeviceExternalSemaphoreInfoKHX* pExternalSemaphoreInfo,
+VkExternalSemaphorePropertiesKHX*   pExternalSemaphoreProperties)
+{
+   switch (pExternalSemaphoreInfo->handleType) {
+   default:
+  pExternalSemaphoreProperties->exportFromImportedHandleTypes = 0;
+  pExternalSemaphoreProperties->compatibleHandleTypes = 0;
+  pExternalSemaphoreProperties->externalSemaphoreFeatures = 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] [PATCH v2 13/18] anv: Implement VK_KHX_external_semaphore

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_device.c   | 4 
 src/intel/vulkan/anv_entrypoints_gen.py | 1 +
 src/intel/vulkan/anv_queue.c| 8 
 3 files changed, 13 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3674029..e9d919d 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -327,6 +327,10 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHX_EXTERNAL_MEMORY_FD_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_SEMAPHORE_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index 562ee49..c463eff 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -42,6 +42,7 @@ supported_extensions = [
'VK_KHX_external_memory',
'VK_KHX_external_memory_capabilities',
'VK_KHX_external_memory_fd',
+   'VK_KHX_external_semaphore',
'VK_KHX_external_semaphore_capabilities',
 ]
 
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index dfb54bc..fe640eb 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -463,6 +463,14 @@ VkResult anv_CreateSemaphore(
if (semaphore == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
+   const VkExportSemaphoreCreateInfoKHX *export =
+  vk_find_struct_const(pCreateInfo->pNext, 
EXPORT_SEMAPHORE_CREATE_INFO_KHX);
+VkExternalSemaphoreHandleTypeFlagsKHX handleTypes =
+  export ? export->handleTypes : 0;
+
+   /* External semaphores are not yet supported */
+   assert(handleTypes == 0);
+
/* The DRM execbuffer ioctl always execute in-oder, even between
 * different rings. As such, a dummy no-op semaphore is a perfectly
 * valid implementation.
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 17/18] anv/gem: Use EXECBUFFER2_WR when the FENCE_OUT flag is set

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_gem.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 0dde6d9..d8beab1 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -168,7 +168,10 @@ int
 anv_gem_execbuffer(struct anv_device *device,
struct drm_i915_gem_execbuffer2 *execbuf)
 {
-   return anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf);
+   if (execbuf->flags & I915_EXEC_FENCE_OUT)
+  return anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2_WR, execbuf);
+   else
+  return anv_ioctl(device->fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf);
 }
 
 int
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 14/18] anv/cmd_buffer: Use the device allocator for QueueSubmit

2017-03-13 Thread Jason Ekstrand
The command is really operating on a Queue not a command buffer and the
nearest object to that with an allocator is VkDevice.

Cc: "17.0" 
---
 src/intel/vulkan/anv_batch_chain.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index 3f6039e..e5cc21d 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -1237,7 +1237,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
adjust_relocations_from_state_pool(ss_pool, _buffer->surface_relocs,
   cmd_buffer->last_ss_pool_center);
anv_execbuf_add_bo(, _pool->bo, _buffer->surface_relocs,
-  _buffer->pool->alloc);
+  >alloc);
 
/* First, we walk over all of the bos we've seen and add them and their
 * relocations to the validate list.
@@ -1248,7 +1248,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
cmd_buffer->last_ss_pool_center);
 
   anv_execbuf_add_bo(, &(*bbo)->bo, &(*bbo)->relocs,
- _buffer->pool->alloc);
+ >alloc);
}
 
/* Now that we've adjusted all of the surface state relocations, we need to
@@ -1355,7 +1355,7 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
 
VkResult result = anv_device_execbuf(device, , execbuf.bos);
 
-   anv_execbuf_finish(, _buffer->pool->alloc);
+   anv_execbuf_finish(, >alloc);
 
return result;
 }
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 08/18] anv: Use the BO cache for DeviceMemory allocations

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_device.c  | 27 ---
 src/intel/vulkan/anv_image.c   |  2 +-
 src/intel/vulkan/anv_intel.c   | 14 ++
 src/intel/vulkan/anv_private.h |  4 +++-
 src/intel/vulkan/anv_wsi.c |  6 +++---
 5 files changed, 29 insertions(+), 24 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 385a806..aef9792 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1126,10 +1126,14 @@ VkResult anv_CreateDevice(
 
anv_bo_pool_init(>batch_bo_pool, device);
 
+   result = anv_bo_cache_init(>bo_cache);
+   if (result != VK_SUCCESS)
+  goto fail_batch_bo_pool;
+
result = anv_block_pool_init(>dynamic_state_block_pool, device,
 16384);
if (result != VK_SUCCESS)
-  goto fail_batch_bo_pool;
+  goto fail_bo_cache;
 
anv_state_pool_init(>dynamic_state_pool,
>dynamic_state_block_pool);
@@ -1201,6 +1205,8 @@ VkResult anv_CreateDevice(
  fail_dynamic_state_pool:
anv_state_pool_finish(>dynamic_state_pool);
anv_block_pool_finish(>dynamic_state_block_pool);
+ fail_bo_cache:
+   anv_bo_cache_finish(>bo_cache);
  fail_batch_bo_pool:
anv_bo_pool_finish(>batch_bo_pool);
pthread_cond_destroy(>queue_submit);
@@ -1248,6 +1254,8 @@ void anv_DestroyDevice(
anv_state_pool_finish(>dynamic_state_pool);
anv_block_pool_finish(>dynamic_state_block_pool);
 
+   anv_bo_cache_finish(>bo_cache);
+
anv_bo_pool_finish(>batch_bo_pool);
 
pthread_cond_destroy(>queue_submit);
@@ -1491,7 +1499,8 @@ VkResult anv_AllocateMemory(
/* The kernel is going to give us whole pages anyway */
uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize, 4096);
 
-   result = anv_bo_init_new(>bo, device, alloc_size);
+   result = anv_bo_cache_alloc(device, >bo_cache,
+   alloc_size, >bo, >alloc);
if (result != VK_SUCCESS)
   goto fail;
 
@@ -1524,11 +1533,7 @@ void anv_FreeMemory(
if (mem->map)
   anv_UnmapMemory(_device, _mem);
 
-   if (mem->bo.map)
-  anv_gem_munmap(mem->bo.map, mem->bo.size);
-
-   if (mem->bo.gem_handle != 0)
-  anv_gem_close(device, mem->bo.gem_handle);
+   anv_bo_cache_release(device, >bo_cache, mem->bo, >alloc);
 
vk_free2(>alloc, pAllocator, mem);
 }
@@ -1550,7 +1555,7 @@ VkResult anv_MapMemory(
}
 
if (size == VK_WHOLE_SIZE)
-  size = mem->bo.size - offset;
+  size = mem->bo->size - offset;
 
/* From the Vulkan spec version 1.0.32 docs for MapMemory:
 *
@@ -1560,7 +1565,7 @@ VkResult anv_MapMemory(
 *equal to the size of the memory minus offset
 */
assert(size > 0);
-   assert(offset + size <= mem->bo.size);
+   assert(offset + size <= mem->bo->size);
 
/* FIXME: Is this supposed to be thread safe? Since vkUnmapMemory() only
 * takes a VkDeviceMemory pointer, it seems like only one map of the memory
@@ -1580,7 +1585,7 @@ VkResult anv_MapMemory(
/* Let's map whole pages */
map_size = align_u64(map_size, 4096);
 
-   void *map = anv_gem_mmap(device, mem->bo.gem_handle,
+   void *map = anv_gem_mmap(device, mem->bo->gem_handle,
 map_offset, map_size, gem_flags);
if (map == MAP_FAILED)
   return vk_error(VK_ERROR_MEMORY_MAP_FAILED);
@@ -1732,7 +1737,7 @@ VkResult anv_BindBufferMemory(
ANV_FROM_HANDLE(anv_buffer, buffer, _buffer);
 
if (mem) {
-  buffer->bo = >bo;
+  buffer->bo = mem->bo;
   buffer->offset = memoryOffset;
} else {
   buffer->bo = NULL;
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index b28d135..b878a5f 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -336,7 +336,7 @@ VkResult anv_BindImageMemory(
ANV_FROM_HANDLE(anv_image, image, _image);
 
if (mem) {
-  image->bo = >bo;
+  image->bo = mem->bo;
   image->offset = memoryOffset;
} else {
   image->bo = NULL;
diff --git a/src/intel/vulkan/anv_intel.c b/src/intel/vulkan/anv_intel.c
index c356e84..977b937 100644
--- a/src/intel/vulkan/anv_intel.c
+++ b/src/intel/vulkan/anv_intel.c
@@ -49,15 +49,13 @@ VkResult anv_CreateDmaBufImageINTEL(
if (mem == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
-   uint32_t gem_handle = anv_gem_fd_to_handle(device, pCreateInfo->fd);
-   if (!gem_handle) {
-  result = vk_error(VK_ERROR_OUT_OF_DEVICE_MEMORY);
-  goto fail;
-   }
-
uint64_t size = (uint64_t)pCreateInfo->strideInBytes * 
pCreateInfo->extent.height;
 
-   anv_bo_init(>bo, gem_handle, size);
+   result = anv_bo_cache_import(device, >bo_cache,
+pCreateInfo->fd, size, >bo,
+>alloc);
+   if (result != VK_SUCCESS)
+  goto fail;
 
anv_image_create(_device,
   &(struct anv_image_create_info) {
@@ -80,7 +78,7 @@ VkResult anv_CreateDmaBufImageINTEL(
   pAllocator, _h);
 
image = 

[Mesa-dev] [PATCH v2 18/18] anv: Implement support for exporting semaphores as FENCE_FD

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_batch_chain.c | 86 --
 src/intel/vulkan/anv_device.c  | 26 
 src/intel/vulkan/anv_gem.c | 36 
 src/intel/vulkan/anv_private.h | 24 ---
 src/intel/vulkan/anv_queue.c   | 61 +--
 5 files changed, 221 insertions(+), 12 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index 3f6b767..ac43888 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -1352,6 +1352,23 @@ setup_execbuf_for_cmd_buffer(struct anv_execbuf *execbuf,
}
 }
 
+static void
+setup_empty_execbuf(struct anv_execbuf *execbuf, struct anv_device *device)
+{
+   anv_execbuf_add_bo(execbuf, >trivial_batch_bo, NULL, 0,
+  >alloc);
+
+   execbuf->execbuf = (struct drm_i915_gem_execbuffer2) {
+  .buffers_ptr = (uintptr_t) execbuf->objects,
+  .buffer_count = execbuf->bo_count,
+  .batch_start_offset = 0,
+  .batch_len = 8, /* GEN8_MI_BATCH_BUFFER_END and NOOP */
+  .flags = I915_EXEC_HANDLE_LUT | I915_EXEC_RENDER,
+  .rsvd1 = device->context_id,
+  .rsvd2 = 0,
+   };
+}
+
 VkResult
 anv_cmd_buffer_execbuf(struct anv_device *device,
struct anv_cmd_buffer *cmd_buffer,
@@ -1363,22 +1380,50 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
struct anv_execbuf execbuf;
anv_execbuf_init();
 
+   int in_fence = -1;
for (uint32_t i = 0; i < num_in_semaphores; i++) {
   ANV_FROM_HANDLE(anv_semaphore, semaphore, in_semaphores[i]);
-  assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
-  struct anv_semaphore_impl *impl = >permanent;
+  struct anv_semaphore_impl *impl =
+ semaphore->temporary.type != ANV_SEMAPHORE_TYPE_NONE ?
+ >temporary : >permanent;
 
   switch (impl->type) {
   case ANV_SEMAPHORE_TYPE_BO:
  anv_execbuf_add_bo(, impl->bo, NULL, 0, >alloc);
  break;
+  case ANV_SEMAPHORE_TYPE_SYNC_FILE:
+ if (in_fence == -1) {
+in_fence = impl->fd;
+ } else {
+int merge = anv_gem_sync_file_merge(device, in_fence, impl->fd);
+if (merge == -1)
+   return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
+
+close(impl->fd);
+close(in_fence);
+in_fence = merge;
+ }
+
+ impl->fd = -1;
   default:
  break;
   }
+
+  /* Waiting on a semaphore with temporary state implicitly resets it back
+   * to the permanent state.
+   */
+  if (semaphore->temporary.type != ANV_SEMAPHORE_TYPE_NONE) {
+ assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_SYNC_FILE);
+ semaphore->temporary.type = ANV_SEMAPHORE_TYPE_NONE;
+  }
}
 
+   bool need_out_fence = false;
for (uint32_t i = 0; i < num_out_semaphores; i++) {
   ANV_FROM_HANDLE(anv_semaphore, semaphore, out_semaphores[i]);
+  /* Out fences can't have temporary state because that would imply
+   * that we imported a sync file and are trying to signal it.
+   */
   assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
   struct anv_semaphore_impl *impl = >permanent;
 
@@ -1387,15 +1432,50 @@ anv_cmd_buffer_execbuf(struct anv_device *device,
  anv_execbuf_add_bo(, impl->bo, NULL, EXEC_OBJECT_WRITE,
 >alloc);
  break;
+
+  case ANV_SEMAPHORE_TYPE_SYNC_FILE:
+ need_out_fence = true;
+ break;
+
   default:
  break;
   }
}
 
-   setup_execbuf_for_cmd_buffer(, cmd_buffer);
+   if (cmd_buffer) {
+  setup_execbuf_for_cmd_buffer(, cmd_buffer);
+   } else {
+  setup_empty_execbuf(, device);
+   }
+
+   if (in_fence != -1) {
+  execbuf.execbuf.flags |= I915_EXEC_FENCE_IN;
+  execbuf.execbuf.rsvd2 |= (uint32_t)in_fence;
+   }
+
+   if (need_out_fence)
+  execbuf.execbuf.flags |= I915_EXEC_FENCE_OUT;
 
VkResult result = anv_device_execbuf(device, , execbuf.bos);
 
+   if (result == VK_SUCCESS && need_out_fence) {
+  int out_fence = execbuf.execbuf.rsvd2 >> 32;
+  for (uint32_t i = 0; i < num_out_semaphores; i++) {
+ ANV_FROM_HANDLE(anv_semaphore, semaphore, out_semaphores[i]);
+ /* Out fences can't have temporary state because that would imply
+  * that we imported a sync file and are trying to signal it.
+  */
+ assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
+ struct anv_semaphore_impl *impl = >permanent;
+
+ if (impl->type == ANV_SEMAPHORE_TYPE_SYNC_FILE) {
+assert(impl->fd == -1);
+impl->fd = dup(out_fence);
+ }
+  }
+  close(out_fence);
+   }
+
anv_execbuf_finish(, >alloc);
 
return result;
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index e393596..2cce07d 100644
--- 

[Mesa-dev] [PATCH v2 16/18] anv: Implement VK_KHX_external_semaphore_fd

2017-03-13 Thread Jason Ekstrand
This implementation allocates a 4k BO for each semaphore that can be
exported using OPAQUE_FD and uses the kernel's already-existing
synchronization mechanism on BOs.
---
 src/intel/vulkan/anv_batch_chain.c  |  44 +--
 src/intel/vulkan/anv_device.c   |   4 +
 src/intel/vulkan/anv_entrypoints_gen.py |   1 +
 src/intel/vulkan/anv_private.h  |  16 +++-
 src/intel/vulkan/anv_queue.c| 132 ++--
 5 files changed, 182 insertions(+), 15 deletions(-)

diff --git a/src/intel/vulkan/anv_batch_chain.c 
b/src/intel/vulkan/anv_batch_chain.c
index c55938a..3f6b767 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/src/intel/vulkan/anv_batch_chain.c
@@ -955,6 +955,7 @@ static VkResult
 anv_execbuf_add_bo(struct anv_execbuf *exec,
struct anv_bo *bo,
struct anv_reloc_list *relocs,
+   uint32_t flags,
const VkAllocationCallbacks *alloc)
 {
struct drm_i915_gem_exec_object2 *obj = NULL;
@@ -1009,7 +1010,7 @@ anv_execbuf_add_bo(struct anv_execbuf *exec,
   obj->relocs_ptr = 0;
   obj->alignment = 0;
   obj->offset = bo->offset;
-  obj->flags = bo->is_winsys_bo ? EXEC_OBJECT_WRITE : 0;
+  obj->flags = flags | (bo->is_winsys_bo ? EXEC_OBJECT_WRITE : 0);
   obj->rsvd1 = 0;
   obj->rsvd2 = 0;
}
@@ -1025,7 +1026,7 @@ anv_execbuf_add_bo(struct anv_execbuf *exec,
   for (size_t i = 0; i < relocs->num_relocs; i++) {
  /* A quick sanity check on relocations */
  assert(relocs->relocs[i].offset < bo->size);
- anv_execbuf_add_bo(exec, relocs->reloc_bos[i], NULL, alloc);
+ anv_execbuf_add_bo(exec, relocs->reloc_bos[i], NULL, flags, alloc);
   }
}
 
@@ -1233,7 +1234,7 @@ setup_execbuf_for_cmd_buffer(struct anv_execbuf *execbuf,
 
adjust_relocations_from_state_pool(ss_pool, _buffer->surface_relocs,
   cmd_buffer->last_ss_pool_center);
-   anv_execbuf_add_bo(execbuf, _pool->bo, _buffer->surface_relocs,
+   anv_execbuf_add_bo(execbuf, _pool->bo, _buffer->surface_relocs, 0,
   _buffer->device->alloc);
 
/* First, we walk over all of the bos we've seen and add them and their
@@ -1244,7 +1245,7 @@ setup_execbuf_for_cmd_buffer(struct anv_execbuf *execbuf,
   adjust_relocations_to_state_pool(ss_pool, &(*bbo)->bo, &(*bbo)->relocs,
cmd_buffer->last_ss_pool_center);
 
-  anv_execbuf_add_bo(execbuf, &(*bbo)->bo, &(*bbo)->relocs,
+  anv_execbuf_add_bo(execbuf, &(*bbo)->bo, &(*bbo)->relocs, 0,
  _buffer->device->alloc);
}
 
@@ -1353,11 +1354,44 @@ setup_execbuf_for_cmd_buffer(struct anv_execbuf 
*execbuf,
 
 VkResult
 anv_cmd_buffer_execbuf(struct anv_device *device,
-   struct anv_cmd_buffer *cmd_buffer)
+   struct anv_cmd_buffer *cmd_buffer,
+   const VkSemaphore *in_semaphores,
+   uint32_t num_in_semaphores,
+   const VkSemaphore *out_semaphores,
+   uint32_t num_out_semaphores)
 {
struct anv_execbuf execbuf;
anv_execbuf_init();
 
+   for (uint32_t i = 0; i < num_in_semaphores; i++) {
+  ANV_FROM_HANDLE(anv_semaphore, semaphore, in_semaphores[i]);
+  assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
+  struct anv_semaphore_impl *impl = >permanent;
+
+  switch (impl->type) {
+  case ANV_SEMAPHORE_TYPE_BO:
+ anv_execbuf_add_bo(, impl->bo, NULL, 0, >alloc);
+ break;
+  default:
+ break;
+  }
+   }
+
+   for (uint32_t i = 0; i < num_out_semaphores; i++) {
+  ANV_FROM_HANDLE(anv_semaphore, semaphore, out_semaphores[i]);
+  assert(semaphore->temporary.type == ANV_SEMAPHORE_TYPE_NONE);
+  struct anv_semaphore_impl *impl = >permanent;
+
+  switch (impl->type) {
+  case ANV_SEMAPHORE_TYPE_BO:
+ anv_execbuf_add_bo(, impl->bo, NULL, EXEC_OBJECT_WRITE,
+>alloc);
+ break;
+  default:
+ break;
+  }
+   }
+
setup_execbuf_for_cmd_buffer(, cmd_buffer);
 
VkResult result = anv_device_execbuf(device, , execbuf.bos);
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index e9d919d..e393596 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -331,6 +331,10 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHX_EXTERNAL_SEMAPHORE_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index c463eff..8945f04 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -44,6 +44,7 @@ 

[Mesa-dev] [PATCH v2 11/18] anv: Add a real semaphore struct

2017-03-13 Thread Jason Ekstrand
It's just a dummy for now, but we'll flesh it out as needed for external
semaphores.
---
 src/intel/vulkan/anv_private.h | 28 
 src/intel/vulkan/anv_queue.c   | 32 ++--
 2 files changed, 54 insertions(+), 6 deletions(-)

diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 10136c8..291a3e2 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -1496,6 +1496,33 @@ struct anv_event {
struct anv_state state;
 };
 
+enum anv_semaphore_type {
+   ANV_SEMAPHORE_TYPE_NONE = 0,
+   ANV_SEMAPHORE_TYPE_DUMMY
+};
+
+struct anv_semaphore_impl {
+   enum anv_semaphore_type type;
+};
+
+struct anv_semaphore {
+   /* Permanent semaphore state.  Every semaphore has some form of permanent
+* state (type != ANV_SEMAPHORE_TYPE_NONE).  This may be a BO to fence on
+* (for cross-process semaphores0 or it could just be a dummy for use
+* internally.
+*/
+   struct anv_semaphore_impl permanent;
+
+   /* Temporary semaphore state.  A semaphore *may* have temporary state.
+* That state is added to the semaphore by an import operation and is reset
+* back to ANV_SEMAPHORE_TYPE_NONE when the semaphore is waited on.  A
+* semaphore with temporary state cannot be signaled because the semaphore
+* must already be signaled before the temporary state can be exported from
+* the semaphore in the other process and imported here.
+*/
+   struct anv_semaphore_impl temporary;
+};
+
 struct anv_shader_module {
unsigned charsha1[20];
uint32_t size;
@@ -2102,6 +2129,7 @@ ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_pipeline_layout, 
VkPipelineLayout)
 ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_query_pool, VkQueryPool)
 ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_render_pass, VkRenderPass)
 ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_sampler, VkSampler)
+ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_semaphore, VkSemaphore)
 ANV_DEFINE_NONDISP_HANDLE_CASTS(anv_shader_module, VkShaderModule)
 
 /* Gen-specific function declarations */
diff --git a/src/intel/vulkan/anv_queue.c b/src/intel/vulkan/anv_queue.c
index a628f59..0bd0ca8 100644
--- a/src/intel/vulkan/anv_queue.c
+++ b/src/intel/vulkan/anv_queue.c
@@ -448,23 +448,43 @@ VkResult anv_WaitForFences(
 // Queue semaphore functions
 
 VkResult anv_CreateSemaphore(
-VkDevicedevice,
+VkDevice_device,
 const VkSemaphoreCreateInfo*pCreateInfo,
 const VkAllocationCallbacks*pAllocator,
 VkSemaphore*pSemaphore)
 {
-   /* The DRM execbuffer ioctl always execute in-oder, even between different
-* rings. As such, there's nothing to do for the user space semaphore.
+   ANV_FROM_HANDLE(anv_device, device, _device);
+   struct anv_semaphore *semaphore;
+
+   assert(pCreateInfo->sType == VK_STRUCTURE_TYPE_SEMAPHORE_CREATE_INFO);
+
+   semaphore = vk_alloc2(>alloc, pAllocator, sizeof(*semaphore), 8,
+ VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+   if (semaphore == NULL)
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+   /* The DRM execbuffer ioctl always execute in-oder, even between
+* different rings. As such, a dummy no-op semaphore is a perfectly
+* valid implementation.
 */
+   semaphore->permanent.type = ANV_SEMAPHORE_TYPE_DUMMY;
+   semaphore->temporary.type = ANV_SEMAPHORE_TYPE_NONE;
 
-   *pSemaphore = (VkSemaphore)1;
+   *pSemaphore = anv_semaphore_to_handle(semaphore);
 
return VK_SUCCESS;
 }
 
 void anv_DestroySemaphore(
-VkDevicedevice,
-VkSemaphore semaphore,
+VkDevice_device,
+VkSemaphore _semaphore,
 const VkAllocationCallbacks*pAllocator)
 {
+   ANV_FROM_HANDLE(anv_device, device, _device);
+   ANV_FROM_HANDLE(anv_semaphore, semaphore, _semaphore);
+
+   if (semaphore == NULL)
+  return;
+
+   vk_free2(>alloc, pAllocator, semaphore);
 }
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 10/18] anv: Move queues, events, and semaphores to their own file

2017-03-13 Thread Jason Ekstrand
Things are about to get more complicated, especially as far as
semaphores are concerned.
---
 src/intel/Makefile.sources|   1 +
 src/intel/vulkan/Makefile.sources |  86 +++
 src/intel/vulkan/anv_device.c | 440 ---
 src/intel/vulkan/anv_queue.c  | 470 ++
 4 files changed, 557 insertions(+), 440 deletions(-)
 create mode 100644 src/intel/vulkan/Makefile.sources
 create mode 100644 src/intel/vulkan/anv_queue.c

diff --git a/src/intel/Makefile.sources b/src/intel/Makefile.sources
index 1337574..4382d79 100644
--- a/src/intel/Makefile.sources
+++ b/src/intel/Makefile.sources
@@ -184,6 +184,7 @@ VULKAN_FILES := \
vulkan/anv_pipeline.c \
vulkan/anv_pipeline_cache.c \
vulkan/anv_private.h \
+   vulkan/anv_queue.c \
vulkan/anv_util.c \
vulkan/anv_wsi.c \
vulkan/vk_format_info.h
diff --git a/src/intel/vulkan/Makefile.sources 
b/src/intel/vulkan/Makefile.sources
new file mode 100644
index 000..aa243a1
--- /dev/null
+++ b/src/intel/vulkan/Makefile.sources
@@ -0,0 +1,86 @@
+# Copyright © 2015 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.
+
+VULKAN_FILES := \
+   anv_allocator.c \
+   anv_batch_chain.c \
+   anv_blorp.c \
+   anv_cmd_buffer.c \
+   anv_descriptor_set.c \
+   anv_device.c \
+   anv_dump.c \
+   anv_formats.c \
+   anv_genX.h \
+   anv_image.c \
+   anv_intel.c \
+   anv_nir.h \
+   anv_nir_apply_dynamic_offsets.c \
+   anv_nir_apply_pipeline_layout.c \
+   anv_nir_lower_input_attachments.c \
+   anv_nir_lower_push_constants.c \
+   anv_pass.c \
+   anv_pipeline.c \
+   anv_pipeline_cache.c \
+   anv_private.h \
+   anv_queue.c \
+   anv_util.c \
+   anv_wsi.c \
+   vk_format_info.h
+
+VULKAN_WSI_WAYLAND_FILES := \
+   anv_wsi_wayland.c
+
+VULKAN_WSI_X11_FILES := \
+   anv_wsi_x11.c
+
+VULKAN_GEM_FILES := \
+   anv_gem.c
+
+VULKAN_GEM_STUB_FILES := \
+   anv_gem_stubs.c
+
+VULKAN_GENERATED_FILES := \
+   anv_entrypoints.c \
+   anv_entrypoints.h
+
+GENX_FILES := \
+   genX_blorp_exec.c \
+   genX_cmd_buffer.c \
+   genX_gpu_memcpy.c \
+   genX_pipeline.c \
+   genX_query.c \
+   genX_state.c
+
+GEN7_FILES := \
+   gen7_cmd_buffer.c \
+$(GENX_FILES)
+
+GEN75_FILES := \
+   gen7_cmd_buffer.c \
+$(GENX_FILES)
+
+GEN8_FILES := \
+   gen8_cmd_buffer.c \
+$(GENX_FILES)
+
+GEN9_FILES := \
+   gen8_cmd_buffer.c \
+$(GENX_FILES)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d9a32f4..3b7ff7b 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -976,70 +976,6 @@ anv_device_init_border_colors(struct anv_device *device)
 border_colors);
 }
 
-VkResult
-anv_device_submit_simple_batch(struct anv_device *device,
-   struct anv_batch *batch)
-{
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 exec2_objects[1];
-   struct anv_bo bo, *exec_bos[1];
-   VkResult result = VK_SUCCESS;
-   uint32_t size;
-   int64_t timeout;
-   int ret;
-
-   /* Kernel driver requires 8 byte aligned batch length */
-   size = align_u32(batch->next - batch->start, 8);
-   result = anv_bo_pool_alloc(>batch_bo_pool, , size);
-   if (result != VK_SUCCESS)
-  return result;
-
-   memcpy(bo.map, batch->start, size);
-   if (!device->info.has_llc)
-  anv_flush_range(bo.map, size);
-
-   exec_bos[0] = 
-   exec2_objects[0].handle = bo.gem_handle;
-   exec2_objects[0].relocation_count = 0;
-   exec2_objects[0].relocs_ptr = 0;
-   exec2_objects[0].alignment = 0;
-   exec2_objects[0].offset = bo.offset;
-   exec2_objects[0].flags = 0;
-   exec2_objects[0].rsvd1 = 0;
-   

[Mesa-dev] [PATCH v2 09/18] anv: Implement VK_KHX_external_memory_fd

2017-03-13 Thread Jason Ekstrand
v2 (chadv):
  - Rebase.
  - Fix vkGetPhysicalDeviceImageFormatProperties2KHR when
handleType == 0.
  - Move handleType-independency comments out of handleType-switch, in
vkGetPhysicalDeviceExternalBufferPropertiesKHX.  Reduces diff in
future dma_buf patches.

Co-authored-with: Chad Versace 
---
 src/intel/vulkan/anv_device.c   | 71 -
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 src/intel/vulkan/anv_formats.c  | 59 +++
 3 files changed, 113 insertions(+), 18 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index aef9792..d9a32f4 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -319,6 +319,10 @@ static const VkExtensionProperties device_extensions[] = {
   .extensionName = VK_KHX_EXTERNAL_MEMORY_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_MEMORY_FD_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
@@ -1478,7 +1482,7 @@ VkResult anv_AllocateMemory(
 {
ANV_FROM_HANDLE(anv_device, device, _device);
struct anv_device_memory *mem;
-   VkResult result;
+   VkResult result = VK_SUCCESS;
 
assert(pAllocateInfo->sType == VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO);
 
@@ -1496,19 +1500,36 @@ VkResult anv_AllocateMemory(
if (mem == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
-   /* The kernel is going to give us whole pages anyway */
-   uint64_t alloc_size = align_u64(pAllocateInfo->allocationSize, 4096);
-
-   result = anv_bo_cache_alloc(device, >bo_cache,
-   alloc_size, >bo, >alloc);
-   if (result != VK_SUCCESS)
-  goto fail;
-
mem->type_index = pAllocateInfo->memoryTypeIndex;
-
mem->map = NULL;
mem->map_size = 0;
 
+   const VkImportMemoryFdInfoKHX *fd_info =
+  vk_find_struct_const(pAllocateInfo->pNext, IMPORT_MEMORY_FD_INFO_KHX);
+
+   /* The Vulkan spec permits handleType to be 0, in which case the struct is
+* ignored.
+*/
+   if (fd_info && fd_info->handleType) {
+  /* At the moment, we only support the OPAQUE_FD memory type which is
+   * just a GEM buffer.
+   */
+  assert(fd_info->handleType ==
+ VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHX);
+
+  result = anv_bo_cache_import(device, >bo_cache,
+   fd_info->fd, pAllocateInfo->allocationSize,
+   >bo, >alloc);
+  if (result != VK_SUCCESS)
+ goto fail;
+   } else {
+  result = anv_bo_cache_alloc(device, >bo_cache,
+  pAllocateInfo->allocationSize,
+  >bo, >alloc);
+  if (result != VK_SUCCESS)
+ goto fail;
+   }
+
*pMem = anv_device_memory_to_handle(mem);
 
return VK_SUCCESS;
@@ -1519,6 +1540,36 @@ VkResult anv_AllocateMemory(
return result;
 }
 
+VkResult anv_GetMemoryFdKHX(
+VkDevicedevice_h,
+VkDeviceMemory  memory_h,
+VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
+int*pFd)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   ANV_FROM_HANDLE(anv_device_memory, mem, memory_h);
+
+   /* We support only one handle type. */
+   assert(handleType == VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT_KHX);
+
+   return anv_bo_cache_export(dev, >bo_cache, mem->bo, pFd);
+}
+
+VkResult anv_GetMemoryFdPropertiesKHX(
+VkDevicedevice_h,
+VkExternalMemoryHandleTypeFlagBitsKHX   handleType,
+int fd,
+VkMemoryFdPropertiesKHX*pMemoryFdProperties)
+{
+   /* The valid usage section for this function says:
+*
+*"handleType must not be one of the handle types defined as opaque."
+*
+* Since we only handle opaque handles for now, there are no FD properties.
+*/
+   return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX;
+}
+
 void anv_FreeMemory(
 VkDevice_device,
 VkDeviceMemory  _mem,
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index e8cdfb7..7d7ea5e 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -41,6 +41,7 @@ supported_extensions = [
'VK_KHR_xlib_surface',
'VK_KHX_external_memory',
'VK_KHX_external_memory_capabilities',
+   'VK_KHX_external_memory_fd',
 ]
 
 # We generate a static hash table for entry point lookup
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index b250931..4c930ed 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -656,6 +656,17 @@ VkResult anv_GetPhysicalDeviceImageFormatProperties(
   

[Mesa-dev] [PATCH v2 07/18] anv/allocator: Add a BO cache

2017-03-13 Thread Jason Ekstrand
This cache allows us to easily ensure that we have a unique anv_bo for
each gem handle.  We'll need this in order to support multiple-import of
memory objects and semaphores.
---
 src/intel/vulkan/anv_allocator.c | 212 +++
 src/intel/vulkan/anv_private.h   |  26 +
 2 files changed, 238 insertions(+)

diff --git a/src/intel/vulkan/anv_allocator.c b/src/intel/vulkan/anv_allocator.c
index 45c663b..84364a6 100644
--- a/src/intel/vulkan/anv_allocator.c
+++ b/src/intel/vulkan/anv_allocator.c
@@ -34,6 +34,8 @@
 
 #include "anv_private.h"
 
+#include "util/hash_table.h"
+
 #ifdef HAVE_VALGRIND
 #define VG_NOACCESS_READ(__ptr) ({   \
VALGRIND_MAKE_MEM_DEFINED((__ptr), sizeof(*(__ptr))); \
@@ -976,3 +978,213 @@ anv_scratch_pool_alloc(struct anv_device *device, struct 
anv_scratch_pool *pool,
 
return >bo;
 }
+
+struct anv_cached_bo {
+   struct anv_bo bo;
+
+   uint32_t refcount;
+};
+
+static uint32_t
+hash_uint32_t(const void *key)
+{
+   return (uint32_t)(uintptr_t)key;
+}
+
+static bool
+uint32_t_equal(const void *a, const void *b)
+{
+   return a == b;
+}
+
+VkResult
+anv_bo_cache_init(struct anv_bo_cache *cache)
+{
+   cache->bo_map = _mesa_hash_table_create(NULL, hash_uint32_t, 
uint32_t_equal);
+   if (!cache->bo_map)
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+   if (pthread_mutex_init(>mutex, NULL)) {
+  _mesa_hash_table_destroy(cache->bo_map, NULL);
+  return vk_errorf(VK_ERROR_OUT_OF_HOST_MEMORY,
+   "pthread_mutex_inti failed: %m");
+   }
+
+   return VK_SUCCESS;
+}
+
+void
+anv_bo_cache_finish(struct anv_bo_cache *cache)
+{
+   _mesa_hash_table_destroy(cache->bo_map, NULL);
+   pthread_mutex_destroy(>mutex);
+}
+
+static struct anv_cached_bo *
+anv_bo_cache_lookup_locked(struct anv_bo_cache *cache, uint32_t gem_handle)
+{
+   struct hash_entry *entry =
+  _mesa_hash_table_search(cache->bo_map,
+  (const void *)(uintptr_t)gem_handle);
+   if (!entry)
+  return NULL;
+
+   struct anv_cached_bo *bo = (struct anv_cached_bo *)entry->data;
+   assert(bo->bo.gem_handle == gem_handle);
+
+   return bo;
+}
+
+VkResult
+anv_bo_cache_alloc(struct anv_device *device,
+   struct anv_bo_cache *cache,
+   uint64_t size, struct anv_bo **bo_out,
+   VkAllocationCallbacks *alloc)
+{
+   struct anv_cached_bo *bo =
+  vk_alloc(alloc, size, 8, VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+   if (!bo)
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+   bo->refcount = 1;
+
+   /* The kernel is going to give us whole pages anyway */
+   size = align_u64(size, 4096);
+
+   VkResult result = anv_bo_init_new(>bo, device, size);
+   if (result != VK_SUCCESS) {
+  vk_free(alloc, bo);
+  return result;
+   }
+
+   assert(bo->bo.gem_handle);
+
+   pthread_mutex_lock(>mutex);
+
+   _mesa_hash_table_insert(cache->bo_map,
+   (void *)(uintptr_t)bo->bo.gem_handle, bo);
+
+   pthread_mutex_unlock(>mutex);
+
+   *bo_out = >bo;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_bo_cache_import(struct anv_device *device,
+struct anv_bo_cache *cache,
+int fd, uint64_t size, struct anv_bo **bo_out,
+VkAllocationCallbacks *alloc)
+{
+   pthread_mutex_lock(>mutex);
+
+   /* The kernel is going to give us whole pages anyway */
+   size = align_u64(size, 4096);
+
+   uint32_t gem_handle = anv_gem_fd_to_handle(device, fd);
+   if (!gem_handle) {
+  pthread_mutex_unlock(>mutex);
+  return vk_error(VK_ERROR_INVALID_EXTERNAL_HANDLE_KHX);
+   }
+
+   struct anv_cached_bo *bo = anv_bo_cache_lookup_locked(cache, gem_handle);
+   if (bo) {
+  assert(bo->bo.size == size);
+  __sync_fetch_and_add(>refcount, 1);
+   } else {
+  struct anv_cached_bo *bo =
+ vk_alloc(alloc, size, 8, VK_SYSTEM_ALLOCATION_SCOPE_OBJECT);
+  if (!bo) {
+ anv_gem_close(device, gem_handle);
+ pthread_mutex_unlock(>mutex);
+ return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+  }
+
+  bo->refcount = 1;
+
+  anv_bo_init(>bo, gem_handle, size);
+
+  _mesa_hash_table_insert(cache->bo_map, (void *)(uintptr_t)gem_handle, 
bo);
+   }
+
+   pthread_mutex_unlock(>mutex);
+
+   /* From the Vulkan spec:
+*
+*"Importing memory from a file descriptor transfers ownership of
+*the file descriptor from the application to the Vulkan
+*implementation. The application must not perform any operations on
+*the file descriptor after a successful import."
+*
+* If the import fails, we leave the file descriptor open.
+*/
+   close(fd);
+
+   *bo_out = >bo;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_bo_cache_export(struct anv_device *device,
+struct anv_bo_cache *cache,
+struct anv_bo *bo_in, int *fd_out)
+{
+   assert(anv_bo_cache_lookup(cache, bo_in->gem_handle) == bo_in);
+ 

[Mesa-dev] [PATCH v2 02/18] anv: Refactor device_get_cache_uuid into physical_device_init_uuids

2017-03-13 Thread Jason Ekstrand
---
 src/intel/vulkan/anv_device.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 5db0a6c..13c1c50 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -53,30 +53,34 @@ compiler_perf_log(void *data, const char *fmt, ...)
va_end(args);
 }
 
-static bool
-anv_device_get_cache_uuid(void *uuid, uint16_t pci_id)
+static VkResult
+anv_physical_device_init_uuids(struct anv_physical_device *device)
 {
const struct build_id_note *note = build_id_find_nhdr("libvulkan_intel.so");
-   if (!note)
-  return false;
+   if (!note) {
+  return vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
+   "Failed to find build-id");
+   }
 
unsigned build_id_len = build_id_length(note);
-   if (build_id_len < 20) /* It should be a SHA-1 */
-  return false;
+   if (build_id_len < 20) {
+  return vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
+   "build-id too short.  It needs to be a SHA");
+   }
 
uint8_t sha1[20];
STATIC_ASSERT(VK_UUID_SIZE <= sizeof(sha1));
 
struct mesa_sha1 *sha1_ctx = _mesa_sha1_init();
if (sha1_ctx == NULL)
-  return false;
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
_mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
-   _mesa_sha1_update(sha1_ctx, _id, sizeof(pci_id));
+   _mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
_mesa_sha1_final(sha1_ctx, sha1);
+   memcpy(device->uuid, sha1, VK_UUID_SIZE);
 
-   memcpy(uuid, sha1, VK_UUID_SIZE);
-   return true;
+   return VK_SUCCESS;
 }
 
 static VkResult
@@ -160,11 +164,10 @@ anv_physical_device_init(struct anv_physical_device 
*device,
   goto fail;
}
 
-   if (!anv_device_get_cache_uuid(device->uuid, device->chipset_id)) {
-  result = vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
- "cannot generate UUID");
+   result = anv_physical_device_init_uuids(device);
+   if (result != VK_SUCCESS)
   goto fail;
-   }
+
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
 
/* GENs prior to 8 do not support EU/Subslice info */
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 03/18] anv/physical_device: Rename uuid to pipeline_cache_uuid

2017-03-13 Thread Jason Ekstrand
We're about to have more UUIDs for different things so this one really
needs to be properly labeled.
---
 src/intel/vulkan/anv_device.c | 5 +++--
 src/intel/vulkan/anv_pipeline_cache.c | 4 ++--
 src/intel/vulkan/anv_private.h| 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 13c1c50..89b2d91 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -78,7 +78,7 @@ anv_physical_device_init_uuids(struct anv_physical_device 
*device)
_mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
_mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
_mesa_sha1_final(sha1_ctx, sha1);
-   memcpy(device->uuid, sha1, VK_UUID_SIZE);
+   memcpy(device->pipeline_cache_uuid, sha1, VK_UUID_SIZE);
 
return VK_SUCCESS;
 }
@@ -680,7 +680,8 @@ void anv_GetPhysicalDeviceProperties(
};
 
strcpy(pProperties->deviceName, pdevice->name);
-   memcpy(pProperties->pipelineCacheUUID, pdevice->uuid, VK_UUID_SIZE);
+   memcpy(pProperties->pipelineCacheUUID,
+  pdevice->pipeline_cache_uuid, VK_UUID_SIZE);
 }
 
 void anv_GetPhysicalDeviceProperties2KHR(
diff --git a/src/intel/vulkan/anv_pipeline_cache.c 
b/src/intel/vulkan/anv_pipeline_cache.c
index a8ea80f..e40a6b4 100644
--- a/src/intel/vulkan/anv_pipeline_cache.c
+++ b/src/intel/vulkan/anv_pipeline_cache.c
@@ -350,7 +350,7 @@ anv_pipeline_cache_load(struct anv_pipeline_cache *cache,
   return;
if (header.device_id != device->chipset_id)
   return;
-   if (memcmp(header.uuid, pdevice->uuid, VK_UUID_SIZE) != 0)
+   if (memcmp(header.uuid, pdevice->pipeline_cache_uuid, VK_UUID_SIZE) != 0)
   return;
 
const void *end = data + size;
@@ -497,7 +497,7 @@ VkResult anv_GetPipelineCacheData(
header->header_version = VK_PIPELINE_CACHE_HEADER_VERSION_ONE;
header->vendor_id = 0x8086;
header->device_id = device->chipset_id;
-   memcpy(header->uuid, pdevice->uuid, VK_UUID_SIZE);
+   memcpy(header->uuid, pdevice->pipeline_cache_uuid, VK_UUID_SIZE);
p += align_u32(header->header_size, 8);
 
uint32_t *count = p;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 3855416..3eba921 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -527,7 +527,7 @@ struct anv_physical_device {
 uint32_teu_total;
 uint32_tsubslice_total;
 
-uint8_t uuid[VK_UUID_SIZE];
+uint8_t 
pipeline_cache_uuid[VK_UUID_SIZE];
 
 struct wsi_device   wsi_device;
 int local_fd;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 01/18] anv: Add the pci_id into the shader cache UUID

2017-03-13 Thread Jason Ekstrand
This prevents a user from using a cache created on one hardware
generation on a different one.  Of course, with Intel hardware, this
requires moving their drive from one machine to another but it's still
possible and we should prevent it.

Reviewed-by: Chad Versace 
---
 src/intel/vulkan/anv_device.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index be2b2f3..5db0a6c 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -32,6 +32,7 @@
 #include "util/strtod.h"
 #include "util/debug.h"
 #include "util/build_id.h"
+#include "util/mesa-sha1.h"
 #include "util/vk_util.h"
 
 #include "genxml/gen7_pack.h"
@@ -53,17 +54,28 @@ compiler_perf_log(void *data, const char *fmt, ...)
 }
 
 static bool
-anv_device_get_cache_uuid(void *uuid)
+anv_device_get_cache_uuid(void *uuid, uint16_t pci_id)
 {
const struct build_id_note *note = build_id_find_nhdr("libvulkan_intel.so");
if (!note)
   return false;
 
-   unsigned len = build_id_length(note);
-   if (len < VK_UUID_SIZE)
+   unsigned build_id_len = build_id_length(note);
+   if (build_id_len < 20) /* It should be a SHA-1 */
   return false;
 
-   memcpy(uuid, build_id_data(note), VK_UUID_SIZE);
+   uint8_t sha1[20];
+   STATIC_ASSERT(VK_UUID_SIZE <= sizeof(sha1));
+
+   struct mesa_sha1 *sha1_ctx = _mesa_sha1_init();
+   if (sha1_ctx == NULL)
+  return false;
+
+   _mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
+   _mesa_sha1_update(sha1_ctx, _id, sizeof(pci_id));
+   _mesa_sha1_final(sha1_ctx, sha1);
+
+   memcpy(uuid, sha1, VK_UUID_SIZE);
return true;
 }
 
@@ -148,7 +160,7 @@ anv_physical_device_init(struct anv_physical_device *device,
   goto fail;
}
 
-   if (!anv_device_get_cache_uuid(device->uuid)) {
+   if (!anv_device_get_cache_uuid(device->uuid, device->chipset_id)) {
   result = vk_errorf(VK_ERROR_INITIALIZATION_FAILED,
  "cannot generate UUID");
   goto fail;
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 05/18] anv: Implement VK_KHX_external_memory_capabilities

2017-03-13 Thread Jason Ekstrand
From: Chad Versace 

This is a complete but trivial implementation. It's trivial becasue We
support no external memory capabilities yet.  Most of the real work in
this commit is in reworking the UUIDs advertised by the driver.

v2 (chadv):
  - Fix chain traversal in vkGetPhysicalDeviceImageFormatProperties2KHR.
Extract VkPhysicalDeviceExternalImageFormatInfoKHX from the chain of
input structs, not the chain of output structs.
  - In vkGetPhysicalDeviceImageFormatProperties2KHR, iterate over the
input chain and the output chain separately. Reduces diff in future
dma_buf patches.

Co-authored-with: Jason Ekstrand 
---
 src/intel/vulkan/anv_device.c   | 53 ---
 src/intel/vulkan/anv_entrypoints_gen.py |  1 +
 src/intel/vulkan/anv_formats.c  | 75 +
 src/intel/vulkan/anv_private.h  |  2 +
 4 files changed, 117 insertions(+), 14 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 89b2d91..f92a313 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -75,11 +75,37 @@ anv_physical_device_init_uuids(struct anv_physical_device 
*device)
if (sha1_ctx == NULL)
   return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
 
+   /* The pipeline cache UUID is used for determining when a pipeline cache is
+* invalid.  It needs both a driver build and the PCI ID of the device.
+*/
_mesa_sha1_update(sha1_ctx, build_id_data(note), build_id_len);
_mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
_mesa_sha1_final(sha1_ctx, sha1);
memcpy(device->pipeline_cache_uuid, sha1, VK_UUID_SIZE);
 
+   /* The driver UUID is used for determining sharability of images and memory
+* between two Vulkan instances in separate processes.  People who want to
+* share memory need to also check the device UUID (below) so all this
+* needs to be is the build-id.
+*/
+   memcpy(device->driver_uuid, build_id_data(note), VK_UUID_SIZE);
+
+   sha1_ctx = _mesa_sha1_init();
+   if (sha1_ctx == NULL)
+  return vk_error(VK_ERROR_OUT_OF_HOST_MEMORY);
+
+   /* The device UUID uniquely identifies the given device within the machine.
+* Since we never have more than one device, this doesn't need to be a real
+* UUID.  However, on the off-chance that someone tries to use this to
+* cache pre-tiled images or something of the like, we use the PCI ID and
+* some bits if ISL info to ensure that this is safe.
+*/
+   _mesa_sha1_update(sha1_ctx, >chipset_id, 
sizeof(device->chipset_id));
+   _mesa_sha1_update(sha1_ctx, >isl_dev.has_bit6_swizzling,
+ sizeof(device->isl_dev.has_bit6_swizzling));
+   _mesa_sha1_final(sha1_ctx, sha1);
+   memcpy(device->device_uuid, sha1, VK_UUID_SIZE);
+
return VK_SUCCESS;
 }
 
@@ -164,10 +190,6 @@ anv_physical_device_init(struct anv_physical_device 
*device,
   goto fail;
}
 
-   result = anv_physical_device_init_uuids(device);
-   if (result != VK_SUCCESS)
-  goto fail;
-
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
 
/* GENs prior to 8 do not support EU/Subslice info */
@@ -207,14 +229,18 @@ anv_physical_device_init(struct anv_physical_device 
*device,
device->compiler->shader_debug_log = compiler_debug_log;
device->compiler->shader_perf_log = compiler_perf_log;
 
+   isl_device_init(>isl_dev, >info, swizzled);
+
+   result = anv_physical_device_init_uuids(device);
+   if (result != VK_SUCCESS)
+  goto fail;
+
result = anv_init_wsi(device);
if (result != VK_SUCCESS) {
   ralloc_free(device->compiler);
   goto fail;
}
 
-   isl_device_init(>isl_dev, >info, swizzled);
-
device->local_fd = fd;
return VK_SUCCESS;
 
@@ -258,6 +284,10 @@ static const VkExtensionProperties global_extensions[] = {
   .extensionName = VK_KHR_GET_PHYSICAL_DEVICE_PROPERTIES_2_EXTENSION_NAME,
   .specVersion = 1,
},
+   {
+  .extensionName = VK_KHX_EXTERNAL_MEMORY_CAPABILITIES_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static const VkExtensionProperties device_extensions[] = {
@@ -688,10 +718,21 @@ void anv_GetPhysicalDeviceProperties2KHR(
 VkPhysicalDevicephysicalDevice,
 VkPhysicalDeviceProperties2KHR* pProperties)
 {
+   ANV_FROM_HANDLE(anv_physical_device, pdevice, physicalDevice);
+
anv_GetPhysicalDeviceProperties(physicalDevice, >properties);
 
vk_foreach_struct(ext, pProperties->pNext) {
   switch (ext->sType) {
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ID_PROPERTIES_KHX: {
+ VkPhysicalDeviceIDPropertiesKHX *id_props =
+(VkPhysicalDeviceIDPropertiesKHX *)ext;
+ memcpy(id_props->deviceUUID, pdevice->device_uuid, VK_UUID_SIZE);
+ memcpy(id_props->driverUUID, pdevice->driver_uuid, VK_UUID_SIZE);
+ /* The LUID is for Windows. */
+ 

[Mesa-dev] [PATCH v2 06/18] anv: Implement VK_KHX_external_memory

2017-03-13 Thread Jason Ekstrand
There's really nothing for us to do here.  So long as the user doesn't
set any crazy environment variables such as INTEL_VK_HIZ=false, all of
the compression formats etc. should "just work" at least for opaque
handle types.
---
 src/intel/vulkan/anv_device.c   | 6 +-
 src/intel/vulkan/anv_entrypoints_gen.py | 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 f92a313..385a806 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -314,7 +314,11 @@ static const VkExtensionProperties device_extensions[] = {
{
   .extensionName = VK_KHR_DESCRIPTOR_UPDATE_TEMPLATE_EXTENSION_NAME,
   .specVersion = 1,
-   }
+   },
+   {
+  .extensionName = VK_KHX_EXTERNAL_MEMORY_EXTENSION_NAME,
+  .specVersion = 1,
+   },
 };
 
 static void *
diff --git a/src/intel/vulkan/anv_entrypoints_gen.py 
b/src/intel/vulkan/anv_entrypoints_gen.py
index 2c084ae..e8cdfb7 100644
--- a/src/intel/vulkan/anv_entrypoints_gen.py
+++ b/src/intel/vulkan/anv_entrypoints_gen.py
@@ -39,6 +39,7 @@ supported_extensions = [
'VK_KHR_wayland_surface',
'VK_KHR_xcb_surface',
'VK_KHR_xlib_surface',
+   'VK_KHX_external_memory',
'VK_KHX_external_memory_capabilities',
 ]
 
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH v2 00/18] anv: Implement VK_KHX_external_*

2017-03-13 Thread Jason Ekstrand
This series is a second revision on my earlier two series to implement the
following extensions:

 - VK_KHX_external_memory_capabilities
 - VK_KHX_external_memory
 - VK_KHX_external_memory_fd
 - VK_KHX_external_semaphore_capabilities
 - VK_KHX_external_semaphore
 - VK_KHX_external_semaphore_fd

This series has a few bug fixes from Chad and Chris.  The main difference,
however, is the presence of the new anv_bo_cache.  This makes duplicate
imports work correctly.

The one remaining issue that I'm not quite sure how we want to sort out is
that you can export a semaphore and import it as memory or vice versa and
it will work just fine.  We should probably be returning INVALID_HANDLE_KHX
if the user tries to do that.

Chad Versace (1):
  anv: Implement VK_KHX_external_memory_capabilities

Jason Ekstrand (17):
  anv: Add the pci_id into the shader cache UUID
  anv: Refactor device_get_cache_uuid into physical_device_init_uuids
  anv/physical_device: Rename uuid to pipeline_cache_uuid
  util/vk: Add helpers for finding an extension struct
  anv: Implement VK_KHX_external_memory
  anv/allocator: Add a BO cache
  anv: Use the BO cache for DeviceMemory allocations
  anv: Implement VK_KHX_external_memory_fd
  anv: Move queues, events, and semaphores to their own file
  anv: Add a real semaphore struct
  anv: Implement VK_KHX_external_semaphore_capabilities
  anv: Implement VK_KHX_external_semaphore
  anv/cmd_buffer: Use the device allocator for QueueSubmit
  anv: Pull the guts of cmd_buffer_execbuf into a helper
  anv: Implement VK_KHX_external_semaphore_fd
  anv/gem: Use EXECBUFFER2_WR when the FENCE_OUT flag is set
  anv: Implement support for exporting semaphores as FENCE_FD

 src/intel/Makefile.sources  |   1 +
 src/intel/vulkan/Makefile.sources   |  86 
 src/intel/vulkan/anv_allocator.c| 212 ++
 src/intel/vulkan/anv_batch_chain.c  | 175 ++--
 src/intel/vulkan/anv_device.c   | 655 +-
 src/intel/vulkan/anv_entrypoints_gen.py |   6 +
 src/intel/vulkan/anv_formats.c  | 118 +-
 src/intel/vulkan/anv_gem.c  |  41 +-
 src/intel/vulkan/anv_image.c|   2 +-
 src/intel/vulkan/anv_intel.c|  14 +-
 src/intel/vulkan/anv_pipeline_cache.c   |   4 +-
 src/intel/vulkan/anv_private.h  |  88 -
 src/intel/vulkan/anv_queue.c| 682 
 src/intel/vulkan/anv_wsi.c  |   6 +-
 src/util/vk_util.h  |  17 +
 15 files changed, 1584 insertions(+), 523 deletions(-)
 create mode 100644 src/intel/vulkan/Makefile.sources
 create mode 100644 src/intel/vulkan/anv_queue.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] [PATCH v2 04/18] util/vk: Add helpers for finding an extension struct

2017-03-13 Thread Jason Ekstrand
---
 src/util/vk_util.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/util/vk_util.h b/src/util/vk_util.h
index e0b5d0b..0b9cb47 100644
--- a/src/util/vk_util.h
+++ b/src/util/vk_util.h
@@ -40,4 +40,21 @@ struct vk_struct_common {
for (const struct vk_struct_common *__iter = (const struct vk_struct_common 
*)(__start); \
 __iter; __iter = __iter->pNext)
 
+static inline void *
+__vk_find_struct(void *start, VkStructureType sType)
+{
+   vk_foreach_struct(s, start) {
+  if (s->sType == sType)
+ return s;
+   }
+
+   return NULL;
+}
+
+#define vk_find_struct(__start, __sType) \
+   __vk_find_struct((__start), VK_STRUCTURE_TYPE_##__sType)
+
+#define vk_find_struct_const(__start, __sType) \
+   (const void *)__vk_find_struct((void *)(__start), 
VK_STRUCTURE_TYPE_##__sType)
+
 #endif /* VK_UTIL_H */
-- 
2.5.0.400.gff86faf

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


[Mesa-dev] [PATCH 1/5] util/disk_cache: seed rand

2017-03-13 Thread Timothy Arceri
Otherwise we will always remove old cache entries from the same dirs.
---
 src/util/disk_cache.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 2a1024a..dc65d52 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -402,20 +402,22 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp)
cache->max_size = max_size;
 
/* A limit of 32 jobs was choosen as observations of Deus Ex start-up times
 * showed that we reached at most 11 jobs on an Intel i5-6400 CPU@2.70GHz
 * (a fairly modist desktop CPU). 1 thread was choosen because we don't
 * really care about getting things to disk quickly just that it's not
 * blocking other tasks.
 */
util_queue_init(>cache_queue, "disk_cache", 32, 1);
 
+   srand(time(NULL));
+
ralloc_free(local);
 
return cache;
 
  fail:
if (fd != -1)
   close(fd);
if (cache)
   ralloc_free(cache);
ralloc_free(local);
-- 
2.9.3

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


[Mesa-dev] [PATCH 2/5] util/disk_cache: don't fallback to an empty cache dir on evict

2017-03-13 Thread Timothy Arceri
If we fail to randomly select a two letter cache dir, don't select
an empty dir on fallback.

In real world use we should never hit the fallback path but it can
be hit by tests when the cache is set to a very small max value.
---
 src/util/disk_cache.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index dc65d52..5b4f12b 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -577,47 +577,68 @@ unlink_random_file_from_directory(const char *path)
filename = choose_random_file_matching(path, is_regular_non_tmp_file);
if (filename == NULL)
   return 0;
 
if (stat(filename, ) == -1) {
   free (filename);
   return 0;
}
 
unlink(filename);
-
free (filename);
 
return sb.st_size;
 }
 
 /* Is entry a directory with a two-character name, (and not the
- * special name of "..")
+ * special name of ".."). We also return false if the dir is empty.
  */
 static bool
 is_two_character_sub_directory(const struct dirent *entry, const char *path)
 {
char *subdir;
if (asprintf(, "%s/%s", path, entry->d_name) == -1)
   return false;
 
struct stat sb;
int res = stat(subdir, );
-   free(subdir);
+   if (res == -1 || !S_ISDIR(sb.st_mode)) {
+  free(subdir);
+  return false;
+   }
 
-   if (res == -1 || !S_ISDIR(sb.st_mode))
+   if (strlen(entry->d_name) != 2) {
+  free(subdir);
   return false;
+   }
 
-   if (strlen(entry->d_name) != 2)
+   if (strcmp(entry->d_name, "..") == 0) {
+  free(subdir);
   return false;
+   }
+
+   DIR *dir = opendir(subdir);
+   free(subdir);
+
+   if (dir == NULL)
+ return false;
+
+   unsigned subdir_entries = 0;
+   struct dirent *d;
+   while ((d = readdir(dir)) != NULL) {
+  if(++subdir_entries > 2)
+ break;
+   }
+   closedir(dir);
 
-   if (strcmp(entry->d_name, "..") == 0)
+   /* If dir only contains '.' and '..' it must be empty */
+   if (subdir_entries <= 2)
   return false;
 
return true;
 }
 
 static void
 evict_random_item(struct disk_cache *cache)
 {
const char hex[] = "0123456789abcde";
char *dir_path;
-- 
2.9.3

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


[Mesa-dev] [PATCH 4/5] util/disk_cache: actually enforce cache size

2017-03-13 Thread Timothy Arceri
From: Alan Swanson 

Currently only a one in one out eviction so if at max_size and
cache files were to constantly increase in size then so would the
cache. Restrict to limit of 8 evictions per new cache entry.

V2: (Timothy Arceri) fix make check tests
---
 src/compiler/glsl/tests/cache_test.c | 22 +++---
 src/util/disk_cache.c|  6 +-
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 10505d4..5ad438c 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -345,30 +345,38 @@ test_put_and_get(void)
 * finish.
 */
wait_until_file_written(cache, one_KB_key);
 
result = disk_cache_get(cache, one_KB_key, );
expect_non_null(result, "3rd disk_cache_get of existing item (pointer)");
expect_equal(size, 1024, "3rd disk_cache_get of existing item (size)");
 
free(result);
 
-   /* Ensure eviction happened by checking that only one of the two
-* previously-added items can still be fetched.
+   /* Ensure eviction happened by checking that both of the previous
+* cache itesm were evicted.
 */
+   bool contains_1KB_file = false;
count = 0;
if (does_cache_contain(cache, blob_key))
count++;
 
if (does_cache_contain(cache, string_key))
count++;
 
+   if (does_cache_contain(cache, one_KB_key)) {
+  count++;
+  contains_1KB_file = true;
+   }
+
+   expect_true(contains_1KB_file,
+   "disk_cache_put eviction last file == MAX_SIZE (1KB)");
expect_equal(count, 1, "disk_cache_put eviction with MAX_SIZE=1K");
 
/* Now increase the size to 1M, add back both items, and ensure all
 * three that have been added are available via disk_cache_get.
 */
disk_cache_destroy(cache);
 
setenv("MESA_GLSL_CACHE_MAX_SIZE", "1M", 1);
cache = disk_cache_create("test", "make_check");
 
@@ -399,31 +407,39 @@ test_put_and_get(void)
_mesa_sha1_compute(one_MB, 1024 * 1024, one_MB_key);
one_MB_key[0] = blob_key_byte_zero;;
 
disk_cache_put(cache, one_MB_key, one_MB, 1024 * 1024, one_MB);
 
/* disk_cache_put() hands things off to a thread give it some time to
 * finish.
 */
wait_until_file_written(cache, one_MB_key);
 
+   bool contains_1MB_file = false;
count = 0;
if (does_cache_contain(cache, blob_key))
count++;
 
if (does_cache_contain(cache, string_key))
count++;
 
if (does_cache_contain(cache, one_KB_key))
count++;
 
-   expect_equal(count, 2, "eviction after overflow with MAX_SIZE=1M");
+   if (does_cache_contain(cache, one_MB_key)) {
+  count++;
+  contains_1MB_file = true;
+   }
+
+   expect_true(contains_1MB_file,
+   "disk_cache_put eviction last file == MAX_SIZE (1MB)");
+   expect_equal(count, 1, "eviction after overflow with MAX_SIZE=1M");
 
disk_cache_destroy(cache);
 }
 
 static void
 test_put_key_and_get_key(void)
 {
struct disk_cache *cache;
bool result;
 
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 2ab236a..7fc35f1 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -801,20 +801,21 @@ struct cache_entry_file_data {
uint32_t crc32;
uint32_t uncompressed_size;
 };
 
 static void
 cache_put(void *job, int thread_index)
 {
assert(job);
 
int fd = -1, fd_final = -1, err, ret;
+   unsigned i = 0;
size_t len;
char *filename = NULL, *filename_tmp = NULL;
struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *) job;
 
filename = get_cache_file(dc_job->cache, dc_job->key);
if (filename == NULL)
   goto done;
 
/* Write to a temporary file to allow for an atomic rename to the
 * final destination filename, (to prevent any readers from seeing
@@ -856,22 +857,25 @@ cache_put(void *job, int thread_index)
if (fd_final != -1)
   goto done;
 
/* OK, we're now on the hook to write out a file that we know is
 * not in the cache, and is also not being written out to the cache
 * by some other process.
 *
 * Before we do that, if the cache is too large, evict something
 * else first.
 */
-   if (*dc_job->cache->size + dc_job->size > dc_job->cache->max_size)
+   while ((*dc_job->cache->size + dc_job->size > dc_job->cache->max_size) &&
+  i < 8) {
   evict_lru_item(dc_job->cache);
+  i++;
+   }
 
/* Create CRC of the data and store at the start of the file. We will
 * read this when restoring the cache and use it to check for corruption.
 */
struct cache_entry_file_data cf_data;
cf_data.crc32 = util_hash_crc32(dc_job->data, dc_job->size);
cf_data.uncompressed_size = dc_job->size;
 
size_t cf_data_size = sizeof(cf_data);
for (len = 0; len < cf_data_size; len += ret) {
-- 
2.9.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH 5/5] util/disk_cache: scale cache according to filesystem size

2017-03-13 Thread Timothy Arceri
From: Alan Swanson 

Select higher of current 1G default or 10% of filesystem where
cache is located.

Acked-by: Timothy Arceri 
---
 src/util/disk_cache.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 7fc35f1..9929701 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -24,34 +24,36 @@
 #ifdef ENABLE_SHADER_CACHE
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include "zlib.h"
 
 #include "util/crc32.h"
 #include "util/u_atomic.h"
 #include "util/u_queue.h"
 #include "util/mesa-sha1.h"
 #include "util/ralloc.h"
 #include "main/errors.h"
+#include "util/macros.h"
 
 #include "disk_cache.h"
 
 /* Number of bits to mask off from a cache key to get an index. */
 #define CACHE_INDEX_KEY_BITS 16
 
 /* Mask for computing an index from a key. */
 #define CACHE_INDEX_KEY_MASK ((1 << CACHE_INDEX_KEY_BITS) - 1)
 
 /* The number of keys that can be stored in the index. */
@@ -227,20 +229,21 @@ create_mesa_cache_dir(void *mem_ctx, const char *path, 
const char *timestamp,
 
 struct disk_cache *
 disk_cache_create(const char *gpu_name, const char *timestamp)
 {
void *local;
struct disk_cache *cache = NULL;
char *path, *max_size_str;
uint64_t max_size;
int fd = -1;
struct stat sb;
+   struct statvfs vfs = { 0 };
size_t size;
 
/* If running as a users other than the real user disable cache */
if (geteuid() != getuid())
   return NULL;
 
/* A ralloc context for transient data during this invocation. */
local = ralloc_context(NULL);
if (local == NULL)
   goto fail;
@@ -388,23 +391,25 @@ disk_cache_create(const char *gpu_name, const char 
*timestamp)
  case '\0':
  case 'G':
  case 'g':
  default:
 max_size *= 1024*1024*1024;
 break;
  }
   }
}
 
-   /* Default to 1GB for maximum cache size. */
-   if (max_size == 0)
-  max_size = 1024*1024*1024;
+   /* Default to 1GB or 10% of filesystem for maximum cache size. */
+   if (max_size == 0) {
+  statvfs(path, );
+  max_size = MAX2(1024*1024*1024, vfs.f_blocks * vfs.f_bsize / 10);
+   }
 
cache->max_size = max_size;
 
/* A limit of 32 jobs was choosen as observations of Deus Ex start-up times
 * showed that we reached at most 11 jobs on an Intel i5-6400 CPU@2.70GHz
 * (a fairly modist desktop CPU). 1 thread was choosen because we don't
 * really care about getting things to disk quickly just that it's not
 * blocking other tasks.
 */
util_queue_init(>cache_queue, "disk_cache", 32, 1);
-- 
2.9.3

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


[Mesa-dev] [PATCH 3/5] util/disk_cache: use LRU eviction rather than random eviction

2017-03-13 Thread Timothy Arceri
From: Alan Swanson 

Still using fast random selection of two-character subdirectory in
which to check cache files rather than scanning entire cache.

v2: Factor out double strlen call
v3: C99 declaration of variables where used

Reviewed-by: Grazvydas Ignotas 
Reviewed-by: Timothy Arceri 
---
 src/util/disk_cache.c | 77 +++
 1 file changed, 34 insertions(+), 43 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 5b4f12b..2ab236a 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -467,84 +467,73 @@ make_cache_file_directory(struct disk_cache *cache, const 
cache_key key)
char buf[41];
 
_mesa_sha1_format(buf, key);
if (asprintf(, "%s/%c%c", cache->path, buf[0], buf[1]) == -1)
   return;
 
mkdir_if_needed(dir);
free(dir);
 }
 
-/* Given a directory path and predicate function, count all entries in
- * that directory for which the predicate returns true. Then choose a
- * random entry from among those counted.
+/* Given a directory path and predicate function, find the entry with
+ * the oldest access time in that directory for which the predicate
+ * returns true.
  *
  * Returns: A malloc'ed string for the path to the chosen file, (or
  * NULL on any error). The caller should free the string when
  * finished.
  */
 static char *
-choose_random_file_matching(const char *dir_path,
-bool (*predicate)(const struct dirent *,
-  const char *dir_path))
+choose_lru_file_matching(const char *dir_path,
+ bool (*predicate)(const struct dirent *,
+   const char *dir_path))
 {
DIR *dir;
struct dirent *entry;
-   unsigned int count, victim;
char *filename;
+   char *lru_name = NULL;
+   time_t lru_atime = 0;
 
dir = opendir(dir_path);
if (dir == NULL)
   return NULL;
 
-   count = 0;
-
while (1) {
   entry = readdir(dir);
   if (entry == NULL)
  break;
   if (!predicate(entry, dir_path))
  continue;
 
-  count++;
-   }
-
-   if (count == 0) {
-  closedir(dir);
-  return NULL;
-   }
-
-   victim = rand() % count;
-
-   rewinddir(dir);
-   count = 0;
-
-   while (1) {
-  entry = readdir(dir);
-  if (entry == NULL)
- break;
-  if (!predicate(entry, dir_path))
- continue;
-  if (count == victim)
- break;
-
-  count++;
+  struct stat sb;
+  if (fstatat(dirfd(dir), entry->d_name, , 0) == 0) {
+ if (!lru_atime || (sb.st_atime < lru_atime)) {
+size_t len = strlen(entry->d_name) + 1;
+char *tmp = realloc(lru_name, len);
+if (tmp) {
+   lru_name = tmp;
+   memcpy(lru_name, entry->d_name, len);
+   lru_atime = sb.st_atime;
+}
+ }
+  }
}
 
-   if (entry == NULL) {
+   if (lru_name == NULL) {
   closedir(dir);
   return NULL;
}
 
-   if (asprintf(, "%s/%s", dir_path, entry->d_name) < 0)
+   if (asprintf(, "%s/%s", dir_path, lru_name) < 0)
   filename = NULL;
 
+   free(lru_name);
closedir(dir);
 
return filename;
 }
 
 /* Is entry a regular file, and not having a name with a trailing
  * ".tmp"
  */
 static bool
 is_regular_non_tmp_file(const struct dirent *entry, const char *path)
@@ -562,26 +551,26 @@ is_regular_non_tmp_file(const struct dirent *entry, const 
char *path)
 
size_t len = strlen (entry->d_name);
if (len >= 4 && strcmp(>d_name[len-4], ".tmp") == 0)
   return false;
 
return true;
 }
 
 /* Returns the size of the deleted file, (or 0 on any error). */
 static size_t
-unlink_random_file_from_directory(const char *path)
+unlink_lru_file_from_directory(const char *path)
 {
struct stat sb;
char *filename;
 
-   filename = choose_random_file_matching(path, is_regular_non_tmp_file);
+   filename = choose_lru_file_matching(path, is_regular_non_tmp_file);
if (filename == NULL)
   return 0;
 
if (stat(filename, ) == -1) {
   free (filename);
   return 0;
}
 
unlink(filename);
free (filename);
@@ -631,59 +620,61 @@ is_two_character_sub_directory(const struct dirent 
*entry, const char *path)
closedir(dir);
 
/* If dir only contains '.' and '..' it must be empty */
if (subdir_entries <= 2)
   return false;
 
return true;
 }
 
 static void
-evict_random_item(struct disk_cache *cache)
+evict_lru_item(struct disk_cache *cache)
 {
const char hex[] = "0123456789abcde";
char *dir_path;
int a, b;
size_t size;
 
/* With a reasonably-sized, full cache, (and with keys generated
 * from a cryptographic hash), we can choose two random hex digits
 * and reasonably expect the directory to exist with a file in it.
+* Provides pseudo-LRU eviction to reduce checking all cache 

[Mesa-dev] [PATCH V3] util/disk_cache: use a thread queue to write to shader cache

2017-03-13 Thread Timothy Arceri
This should help reduce any overhead added by the shader cache
when programs are not found in the cache.

To avoid creating any special function just for the sake of the
tests we add a one second delay whenever we call dick_cache_put()
to give it time to finish.

V2: poll for file when waiting for thread in test
V3: fix poll delay to really be 100ms, and simplify the wait function
---
 src/compiler/glsl/tests/cache_test.c | 63 
 src/util/disk_cache.c| 41 +++
 2 files changed, 85 insertions(+), 19 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 6451e65..10505d4 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -25,20 +25,21 @@
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "util/mesa-sha1.h"
 #include "util/disk_cache.h"
 
 bool error = false;
 
 #ifdef ENABLE_SHADER_CACHE
 
 static void
@@ -224,20 +225,40 @@ does_cache_contain(struct disk_cache *cache, cache_key 
key)
 
if (result) {
   free(result);
   return true;
}
 
return false;
 }
 
 static void
+wait_until_file_written(struct disk_cache *cache, cache_key key)
+{
+   struct timespec req;
+   struct timespec rem;
+
+   /* Set 100ms delay */
+   req.tv_sec = 0;
+   req.tv_nsec = 1;
+
+   unsigned retries = 0;
+   while (retries++ < 20) {
+  if (does_cache_contain(cache, key)) {
+ break;
+  }
+
+  nanosleep(, );
+   }
+}
+
+static void
 test_put_and_get(void)
 {
struct disk_cache *cache;
/* If the text of this blob is changed, then blob_key_byte_zero
 * also needs to be updated.
 */
char blob[] = "This is a blob of thirty-seven bytes";
uint8_t blob_key[20];
uint8_t blob_key_byte_zero = 0xca;
char string[] = "While this string has thirty-four";
@@ -253,35 +274,49 @@ test_put_and_get(void)
_mesa_sha1_compute(blob, sizeof(blob), blob_key);
 
/* Ensure that disk_cache_get returns nothing before anything is added. */
result = disk_cache_get(cache, blob_key, );
expect_null(result, "disk_cache_get with non-existent item (pointer)");
expect_equal(size, 0, "disk_cache_get with non-existent item (size)");
 
/* Simple test of put and get. */
disk_cache_put(cache, blob_key, blob, sizeof(blob), NULL);
 
+   /* disk_cache_put() hands things off to a thread give it some time to
+* finsih.
+*/
+   wait_until_file_written(cache, blob_key);
+
result = disk_cache_get(cache, blob_key, );
-   expect_equal_str(blob, result, "disk_cache_get of existing item (pointer)");
-   expect_equal(size, sizeof(blob), "disk_cache_get of existing item (size)");
+   if (result) {
+  expect_equal_str(blob, result, "disk_cache_get of existing item 
(pointer)");
+  expect_equal(size, sizeof(blob), "disk_cache_get of existing item 
(size)");
 
-   free(result);
+  free(result);
+   }
 
/* Test put and get of a second item. */
_mesa_sha1_compute(string, sizeof(string), string_key);
disk_cache_put(cache, string_key, string, sizeof(string), NULL);
 
+   /* disk_cache_put() hands things off to a thread give it some time to
+* finsih.
+*/
+   wait_until_file_written(cache, string_key);
+
result = disk_cache_get(cache, string_key, );
-   expect_equal_str(result, string, "2nd disk_cache_get of existing item 
(pointer)");
-   expect_equal(size, sizeof(string), "2nd disk_cache_get of existing item 
(size)");
+   if (result) {
+  expect_equal_str(result, string, "2nd disk_cache_get of existing item 
(pointer)");
+  expect_equal(size, sizeof(string), "2nd disk_cache_get of existing item 
(size)");
 
-   free(result);
+  free(result);
+   }
 
/* Set the cache size to 1KB and add a 1KB item to force an eviction. */
disk_cache_destroy(cache);
 
setenv("MESA_GLSL_CACHE_MAX_SIZE", "1K", 1);
cache = disk_cache_create("test", "make_check");
 
one_KB = calloc(1, 1024);
 
/* Obviously the SHA-1 hash of 1024 zero bytes isn't particularly
@@ -299,20 +334,25 @@ test_put_and_get(void)
 * interestingly full than that).
 *
 * For this test, we force this signature to land in the same
 * directory as the original blob first written to the cache.
 */
_mesa_sha1_compute(one_KB, 1024, one_KB_key);
one_KB_key[0] = blob_key_byte_zero;
 
disk_cache_put(cache, one_KB_key, one_KB, 1024, one_KB);
 
+   /* disk_cache_put() hands things off to a thread give it some time to
+* finish.
+*/
+   wait_until_file_written(cache, one_KB_key);
+
result = disk_cache_get(cache, one_KB_key, );
expect_non_null(result, "3rd disk_cache_get of existing item (pointer)");
expect_equal(size, 1024, "3rd disk_cache_get of existing item (size)");
 
free(result);
 
/* Ensure eviction happened by checking that only one of the two
 * 

Re: [Mesa-dev] [PATCH 2/3] gbm: Introduce modifiers into surface/bo creation

2017-03-13 Thread Ben Widawsky

On 17-03-10 11:32:35, Emil Velikov wrote:

On 10 March 2017 at 01:48, Ben Widawsky  wrote:

The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.

A getter() will be added later so that the user GBM will be able to
query what modifier should be used.

Only in surface creation, the modifiers are stored until the BO is
actually allocated. In regular buffer allocation, the correct modifier
can (will be, in future patches be chosen at creation time.

v2: Make sure to check if count is non-zero in addition to testing if
calloc fails. (Daniel)

v3: Remove "usage" and "flags" from modifier creation. Requested by
Kristian.

v4: Take advantage of the "INVALID" modifier added by the GET_PLANE2
series.

v5: Don't bother with storing modifiers for gbm_bo_create because that's
a synchronous operation and we can actually select the correct modifier
at create time (done in a later patch) (Jason)

Cc: Kristian Høgsberg 
Cc: Jason Ekstrand 
References (v4): 
https://lists.freedesktop.org/archives/intel-gfx/2017-January/116636.html
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 



---
 src/egl/drivers/dri2/platform_drm.c  | 19 ---

Worth splitting the patches - patch N+1


 src/gbm/backends/dri/gbm_dri.c   | 42 ++--
 src/gbm/gbm-symbols-check|  2 ++
 src/gbm/main/gbm.c   | 29 --
 src/gbm/main/gbm.h   | 12 +
 src/gbm/main/gbmint.h| 12 +++--

Patch N


 src/mesa/drivers/dri/i965/intel_screen.c | 18 ++

Patch N+Y


--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1023,13 +1023,20 @@ free_bo:
 static struct gbm_bo *
 gbm_dri_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
-  uint32_t format, uint32_t usage)
+  uint32_t format, uint32_t usage,
+  const uint64_t *modifiers,
+  const unsigned int count)
 {
struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_bo *bo;
int dri_format;
unsigned dri_use = 0;

+   /* Callers of this may specify a modifier, or a dri usage, but not both. The
+* newer modifier interface deprecates the older usage flags.
+*/
+   assert(!(usage && count));
+

Similar to last patch - XOR ?



I don't believe so, I still think NAND is right, but I guess I can't say
indisputably that dri_use == 0 is valid.


if (usage & GBM_BO_USE_WRITE || dri->image == NULL)
   return create_dumb(gbm, width, height, format, usage);

@@ -1087,11 +1094,21 @@ gbm_dri_bo_create(struct gbm_device *gbm,
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;

-   bo->image =
-  dri->image->createImage(dri->screen,
-  width, height,
-  dri_format, dri_use,
-  bo);
+   if (!dri->image || dri->image->base.version < 14 ||
+   !dri->image->createImageWithModifiers) {
+  if (modifiers)
+ fprintf(stderr, "Modifiers specified, but DRI is too old\n");
+
+  bo->image = dri->image->createImage(dri->screen, width, height,
+  dri_format, dri_use, bo);

With the "modifiers or use" above how do we get sane value for dri_use
in this fall-back ?
Seems like things we'll miss/ignore the scanout/curson/linear flags.

Perhaps it's worth simply bailing out ?



Yes, I think you're right. Jason said basically the same thing, but the way
you've presented it, it's more obvious to me that baling out is the right thing
to do.

So I've changed this locally.

Same thing basically for gbm_dri_surface_create()




--- a/src/gbm/gbm-symbols-check
+++ b/src/gbm/gbm-symbols-check



+gbm_bo_create_with_modifiers



+gbm_surface_create_with_modifiers

Thank you :-)



+GBM_EXPORT struct gbm_bo *
+gbm_bo_create_with_modifiers(struct gbm_device *gbm,
+ uint32_t width, uint32_t height,
+ uint32_t format,
+ const uint64_t *modifiers,
+ const unsigned int count)
+{
+   if (width == 0 || height == 0) {
+  errno = EINVAL;
+  return NULL;
+   }
+

Should we validate modifiers and/or count at this level as well ?




Yeah, I suppose that makes sense. I got this change locally.

I honestly think almost no validation should be done at this level so that the
implementation can do whatever weird stuff it wants to do, 

[Mesa-dev] [PATCH] gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass expectations.

2017-03-13 Thread Francisco Jerez
Currently the GLSL-to-TGSI translation pass assumes it can use
floating point source modifiers on the UCMP instruction.  See the bug
report linked below for an example where an unrelated change in the
GLSL built-in lowering code for atan2 (e9ffd12827ac11a2d2002a42fa8eb1)
caused the generation of floating-point ir_unop_neg instructions
followed by ir_triop_csel, which is translated into UCMP with a negate
modifier on back-ends with native integer support.

Allowing floating-point source modifiers on an integer instruction
seems like rather dubious design for a transport IR, since the same
semantics could be represented as a sequence of MOV+UCMP instructions
instead, but supposedly this matches the expectations of TGSI
back-ends other than tgsi_exec, and the expectations of the DX10 API.
I take no responsibility for future headaches caused by this
inconsistency.

Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
the above-mentioned glsl front-end commit.  Even though the commit
that triggered the regression doesn't seem to have made it to any
stable branches yet, this might be worth back-porting since I don't
see any reason why the bug couldn't have been reproduced before that
point.

Suggested-by: Roland Scheidegger 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99817
---
 src/gallium/auxiliary/tgsi/tgsi_exec.c | 54 ++
 src/gallium/docs/source/tgsi.rst   |  8 +++--
 2 files changed, 46 insertions(+), 16 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index 3c15306..48d91af 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -3359,6 +3359,46 @@ exec_up2h(struct tgsi_exec_machine *mach,
 }
 
 static void
+micro_ucmp(union tgsi_exec_channel *dst,
+   const union tgsi_exec_channel *src0,
+   const union tgsi_exec_channel *src1,
+   const union tgsi_exec_channel *src2)
+{
+   dst->f[0] = src0->u[0] ? src1->f[0] : src2->f[0];
+   dst->f[1] = src0->u[1] ? src1->f[1] : src2->f[1];
+   dst->f[2] = src0->u[2] ? src1->f[2] : src2->f[2];
+   dst->f[3] = src0->u[3] ? src1->f[3] : src2->f[3];
+}
+
+static void
+exec_ucmp(struct tgsi_exec_machine *mach,
+  const struct tgsi_full_instruction *inst)
+{
+   unsigned int chan;
+   struct tgsi_exec_vector dst;
+
+   for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
+  if (inst->Dst[0].Register.WriteMask & (1 << chan)) {
+ union tgsi_exec_channel src[3];
+
+ fetch_source(mach, [0], >Src[0], chan,
+  TGSI_EXEC_DATA_UINT);
+ fetch_source(mach, [1], >Src[1], chan,
+  TGSI_EXEC_DATA_FLOAT);
+ fetch_source(mach, [2], >Src[2], chan,
+  TGSI_EXEC_DATA_FLOAT);
+ micro_ucmp([chan], [0], [1], [2]);
+  }
+   }
+   for (chan = 0; chan < TGSI_NUM_CHANNELS; chan++) {
+  if (inst->Dst[0].Register.WriteMask & (1 << chan)) {
+ store_dest(mach, [chan], >Dst[0], inst, chan,
+TGSI_EXEC_DATA_FLOAT);
+  }
+   }
+}
+
+static void
 exec_scs(struct tgsi_exec_machine *mach,
  const struct tgsi_full_instruction *inst)
 {
@@ -4997,18 +5037,6 @@ micro_uarl(union tgsi_exec_channel *dst,
dst->i[3] = src->u[3];
 }
 
-static void
-micro_ucmp(union tgsi_exec_channel *dst,
-   const union tgsi_exec_channel *src0,
-   const union tgsi_exec_channel *src1,
-   const union tgsi_exec_channel *src2)
-{
-   dst->u[0] = src0->u[0] ? src1->u[0] : src2->u[0];
-   dst->u[1] = src0->u[1] ? src1->u[1] : src2->u[1];
-   dst->u[2] = src0->u[2] ? src1->u[2] : src2->u[2];
-   dst->u[3] = src0->u[3] ? src1->u[3] : src2->u[3];
-}
-
 /**
  * Signed bitfield extract (i.e. sign-extend the extracted bits)
  */
@@ -5911,7 +5939,7 @@ exec_instruction(
   break;
 
case TGSI_OPCODE_UCMP:
-  exec_vector_trinary(mach, inst, micro_ucmp, TGSI_EXEC_DATA_UINT, 
TGSI_EXEC_DATA_UINT);
+  exec_ucmp(mach, inst);
   break;
 
case TGSI_OPCODE_IABS:
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 32ec4ef..37fb304 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -28,9 +28,11 @@ Modifiers
 
 TGSI supports modifiers on inputs (as well as saturate modifier on 
instructions).
 
-For inputs which have a floating point type, both absolute value and negation
-modifiers are supported (with absolute value being applied first).
-TGSI_OPCODE_MOV is considered to have float input type for applying modifiers.
+For inputs which have a floating point type, both absolute value and
+negation modifiers are supported (with absolute value being applied
+first).  The only source of TGSI_OPCODE_MOV and the second and third
+sources of TGSI_OPCODE_UCMP are considered to have float type for
+applying modifiers.
 
 For inputs which have signed or unsigned type only the negate 

Re: [Mesa-dev] [PATCH] anv/blorp: Only set a clear color for resolves if fast-cleared

2017-03-13 Thread Jason Ekstrand
On Mon, Mar 13, 2017 at 5:34 PM, Emil Velikov 
wrote:

> On 13 March 2017 at 19:08, Jason Ekstrand  wrote:
> > On Mon, Mar 13, 2017 at 11:19 AM, Emil Velikov  >
> > wrote:
> >>
> >> On 5 March 2017 at 16:36, Eduardo Lima Mitev  wrote:
> >> > Reviewed-by: Eduardo Lima Mitev 
> >> >
> >> > On 03/04/2017 01:56 AM, Jason Ekstrand wrote:
> >> >> Cc: "17.0" 
> >> >> ---
> >> >>  src/intel/vulkan/anv_blorp.c | 3 ++-
> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> Is there anything wrong with the patch or it simply fell through the
> >> cracks ?
> >
> >
> > There was a small issue but both this patch and the fix landed this
> morning.
> >
> Right so the patch is superseded [by 6b644e571e2 ("anv: Stall before
> fast-clear operations")] - I wasn't too sure.
>

No, it isn't.  They're completely separate patches.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH V2] util/disk_cache: use a thread queue to write to shader cache

2017-03-13 Thread Timothy Arceri
This should help reduce any overhead added by the shader cache
when programs are not found in the cache.

To avoid creating any special function just for the sake of the
tests we add a one second delay whenever we call dick_cache_put()
to give it time to finish.

V2: poll for file when waiting for thread in test
---
 src/compiler/glsl/tests/cache_test.c | 75 +---
 src/util/disk_cache.c| 41 +---
 2 files changed, 97 insertions(+), 19 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 6451e65..224353e 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -25,20 +25,21 @@
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "util/mesa-sha1.h"
 #include "util/disk_cache.h"
 
 bool error = false;
 
 #ifdef ENABLE_SHADER_CACHE
 
 static void
@@ -224,64 +225,110 @@ does_cache_contain(struct disk_cache *cache, cache_key 
key)
 
if (result) {
   free(result);
   return true;
}
 
return false;
 }
 
 static void
+wait_until_file_written(cache_key key)
+{
+   struct timespec req;
+   struct timespec rem;
+
+   /* Set 100ms delay */
+   req.tv_sec = 0;
+   req.tv_nsec = 10;
+
+   char *cache_path = getenv("MESA_GLSL_CACHE_DIR");
+
+   char buf[41];
+   _mesa_sha1_format(buf, key);
+
+   char *path_to_file;
+   asprintf(_to_file, "%s/mesa/%s/make_check/test/%c%c/%s", cache_path,
+get_arch_bitness_str(), buf[0], buf[1], buf + 2);
+
+   unsigned retries = 0;
+   while (retries++ < 20) {
+  if (access(path_to_file, F_OK) != -1)
+ break;
+
+  nanosleep(, );
+   }
+
+   free(path_to_file);
+}
+
+static void
 test_put_and_get(void)
 {
struct disk_cache *cache;
/* If the text of this blob is changed, then blob_key_byte_zero
 * also needs to be updated.
 */
char blob[] = "This is a blob of thirty-seven bytes";
uint8_t blob_key[20];
uint8_t blob_key_byte_zero = 0xca;
char string[] = "While this string has thirty-four";
uint8_t string_key[20];
char *result;
size_t size;
uint8_t *one_KB, *one_MB;
uint8_t one_KB_key[20], one_MB_key[20];
int count;
 
+   setenv("MESA_GLSL_CACHE_DIR", CACHE_TEST_TMP "/mesa-glsl-cache-dir", 1);
+
cache = disk_cache_create("test", "make_check");
 
_mesa_sha1_compute(blob, sizeof(blob), blob_key);
 
/* Ensure that disk_cache_get returns nothing before anything is added. */
result = disk_cache_get(cache, blob_key, );
expect_null(result, "disk_cache_get with non-existent item (pointer)");
expect_equal(size, 0, "disk_cache_get with non-existent item (size)");
 
/* Simple test of put and get. */
disk_cache_put(cache, blob_key, blob, sizeof(blob), NULL);
 
+   /* disk_cache_put() hands things off to a thread give it some time to
+* finsih.
+*/
+   wait_until_file_written(blob_key);
+
result = disk_cache_get(cache, blob_key, );
-   expect_equal_str(blob, result, "disk_cache_get of existing item (pointer)");
-   expect_equal(size, sizeof(blob), "disk_cache_get of existing item (size)");
+   if (result) {
+  expect_equal_str(blob, result, "disk_cache_get of existing item 
(pointer)");
+  expect_equal(size, sizeof(blob), "disk_cache_get of existing item 
(size)");
 
-   free(result);
+  free(result);
+   }
 
/* Test put and get of a second item. */
_mesa_sha1_compute(string, sizeof(string), string_key);
disk_cache_put(cache, string_key, string, sizeof(string), NULL);
 
+   /* disk_cache_put() hands things off to a thread give it some time to
+* finsih.
+*/
+   wait_until_file_written(string_key);
+
result = disk_cache_get(cache, string_key, );
-   expect_equal_str(result, string, "2nd disk_cache_get of existing item 
(pointer)");
-   expect_equal(size, sizeof(string), "2nd disk_cache_get of existing item 
(size)");
+   if (result) {
+  expect_equal_str(result, string, "2nd disk_cache_get of existing item 
(pointer)");
+  expect_equal(size, sizeof(string), "2nd disk_cache_get of existing item 
(size)");
 
-   free(result);
+  free(result);
+   }
 
/* Set the cache size to 1KB and add a 1KB item to force an eviction. */
disk_cache_destroy(cache);
 
setenv("MESA_GLSL_CACHE_MAX_SIZE", "1K", 1);
cache = disk_cache_create("test", "make_check");
 
one_KB = calloc(1, 1024);
 
/* Obviously the SHA-1 hash of 1024 zero bytes isn't particularly
@@ -299,20 +346,25 @@ test_put_and_get(void)
 * interestingly full than that).
 *
 * For this test, we force this signature to land in the same
 * directory as the original blob first written to the cache.
 */
_mesa_sha1_compute(one_KB, 1024, one_KB_key);
one_KB_key[0] = blob_key_byte_zero;
 
disk_cache_put(cache, one_KB_key, one_KB, 1024, one_KB);
 
+   /* disk_cache_put() hands things 

Re: [Mesa-dev] [PATCH 2/3] gbm: Introduce modifiers into surface/bo creation

2017-03-13 Thread Ben Widawsky

On 17-03-09 18:52:52, Jason Ekstrand wrote:

On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky  wrote:


The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.

A getter() will be added later so that the user GBM will be able to
query what modifier should be used.

Only in surface creation, the modifiers are stored until the BO is
actually allocated. In regular buffer allocation, the correct modifier
can (will be, in future patches be chosen at creation time.

v2: Make sure to check if count is non-zero in addition to testing if
calloc fails. (Daniel)

v3: Remove "usage" and "flags" from modifier creation. Requested by
Kristian.

v4: Take advantage of the "INVALID" modifier added by the GET_PLANE2
series.

v5: Don't bother with storing modifiers for gbm_bo_create because that's
a synchronous operation and we can actually select the correct modifier
at create time (done in a later patch) (Jason)

Cc: Kristian Høgsberg 
Cc: Jason Ekstrand 
References (v4): https://lists.freedesktop.org/
archives/intel-gfx/2017-January/116636.html
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 src/egl/drivers/dri2/platform_drm.c  | 19 ---
 src/gbm/backends/dri/gbm_dri.c   | 42
++--
 src/gbm/gbm-symbols-check|  2 ++
 src/gbm/main/gbm.c   | 29 --
 src/gbm/main/gbm.h   | 12 +
 src/gbm/main/gbmint.h| 12 +++--
 src/mesa/drivers/dri/i965/intel_screen.c | 18 ++
 7 files changed, 119 insertions(+), 15 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index e5e8c60596..cf35ce8a1f 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -230,10 +230,21 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)

if (dri2_surf->back == NULL)
   return -1;
-   if (dri2_surf->back->bo == NULL)
-  dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_dri->base.base,
- surf->base.width,
surf->base.height,
- surf->base.format,
surf->base.flags);
+   if (dri2_surf->back->bo == NULL) {
+  if (surf->base.modifiers)
+ dri2_surf->back->bo = gbm_bo_create_with_modifiers(&
dri2_dpy->gbm_dri->base.base,
+
surf->base.width, surf->base.height,
+
surf->base.format,
+
surf->base.modifiers,
+
surf->base.count);
+  else
+ dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_d
ri->base.base,
+ surf->base.width,
+ surf->base.height,
+ surf->base.format,
+ surf->base.flags);
+
+   }
if (dri2_surf->back->bo == NULL)
   return -1;

diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri
.c
index 7106dc1229..d45ba94080 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1023,13 +1023,20 @@ free_bo:
 static struct gbm_bo *
 gbm_dri_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
-  uint32_t format, uint32_t usage)
+  uint32_t format, uint32_t usage,
+  const uint64_t *modifiers,
+  const unsigned int count)
 {
struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_bo *bo;
int dri_format;
unsigned dri_use = 0;

+   /* Callers of this may specify a modifier, or a dri usage, but not
both. The
+* newer modifier interface deprecates the older usage flags.
+*/
+   assert(!(usage && count));
+
if (usage & GBM_BO_USE_WRITE || dri->image == NULL)
   return create_dumb(gbm, width, height, format, usage);

@@ -1087,11 +1094,21 @@ gbm_dri_bo_create(struct gbm_device *gbm,
/* Gallium drivers requires shared in order to get the handle/stride */
dri_use |= __DRI_IMAGE_USE_SHARE;

-   bo->image =
-  dri->image->createImage(dri->screen,
-  width, height,
-  dri_format, dri_use,
-  bo);
+   if (!dri->image || dri->image->base.version < 14 ||
+   !dri->image->createImageWithModifiers) {
+  if (modifiers)
+ fprintf(stderr, "Modifiers specified, but DRI is too old\n");



This seems a bit on the sketchy side.  Do we want to fail, set errno to
ENOSYS, and return NULL in this case?  I'm not really sure how GBM
versioning works.  Daniel?  Kristian?




I 

Re: [Mesa-dev] MESA and KOTOR

2017-03-13 Thread Federico Dossena
Hi Jose, thanks for replying, I've seen your name inside many files in 
mesa ;)


I have tried mesa master (previously I was using 17.0.1) but it still 
crashes for the same null pointer.

Do you have a link to that patch you've mentioned for kotor?

I have used apitrace and took traces of both the nvidia driver (which 
runs kotor) and mesa (up until the crash).
Here's a link to them: 
https://drive.google.com/file/d/0B6qj91UlSYlYa3dIM0FtaHNULW8/view?usp=sharing


I tried reading them with the dump function but it's way above my 
comprehension.


I know that some applications use wglGetProcAddress to check if an 
extension if available, but I've seen KOTOR check for the 
WGL_ARB_render_texture, and when it's present it enables frame buffer 
effects and soft shadows, which use wglMakeContextCurrentARB (not 
wglBindTexImageARB, I was wrong in my previous mail), which for some 
reason is a null pointer.





Il 2017-03-13 14:39, Jose Fonseca ha scritto:

On 13/03/17 11:09, Emil Velikov wrote:
On 11 March 2017 at 11:51, Federico Dossena  
wrote:
In the last week I've been trying to bring an "old" game back to 
life, Star
Wars Knights of the old republic (KOTOR, for short). It's from 2003 
and uses

OpenGL 1.4.

I have used Mesa, libtxc_dxtn and some trickery to decompress the 
textures
to boost performance, and right now I have it up and running 
smoothly with
Gallium on LLVMPipe, compiled on Windows. (I can upload a copy if 
someone is
interested). This took me about 2 days of compiling and figuring out 
stuff.


Here's where the weirdness begins:
Turning on framebuffer effects or soft shadows make the game crash 
right
after the menu. Using a disassembler and debugger and what little 
knowledge

I have of reverse engineering, I managed to track down the issue to a
function which uses wglGetProcAddress to get the addresses of 
several OpenGL
functions. Some of these calls return a null pointer (even if there 
is a
valid context and it is current), and when the game tries to call 
them, it

crashes. The first one that makes it crash is a pointer to
wglBindTexImageARB, but there are a few others. NOPing the offending
instructions did not work, and returning a nop function just makes 
the game

display artifacts.


Strange - afaict mesa (st/wgl) exposes both wglBindTexImageARB and the
WGL_ARB_render_texture extension.
You can break on DrvGetProcAddress and trace where/how we end up with
NULL function pointer.

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



Federico,

You should be using latest master for this.   There have been recent 
changes/fixes to our WGL implementation.



Last fall Brian Paul fixed an issue with WGL extension seen on KOTOR. 
I'm not sure the the issue has been crossported to Mesa master yet, 
and it might be unrelated.



Generally speaking, wglGetProcAddress returning NULL by itself is not 
a problem.  Many games wrongly rely on wglGetProcAddress NULL results 
to detect whether an GL/WGL extension is present (which goes against 
the spec).  Other libraries try to bindly get every possible 
entrypoint through wglGetProcAddress, then check which ones to use 
based on supported extensions (which is actually fine by the spec.)



For the record, getting an apitrace is usually useful to debug this 
sort of issues.  One can use apitrace straigh from windows or with 
WINE -- https://github.com/apitrace/apitrace/wiki/WINE



Jose


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


Re: [Mesa-dev] [PATCH] Convert sed(1) syntax to be compatible with FreeBSD and OpenBSD

2017-03-13 Thread Jan Beich
Eric Engestrom  writes:

> On Monday, 2017-03-13 11:56:45 +, Jan Beich wrote:
>
>> Eric Engestrom  writes:
>> 
>> >> +echo " `$1`" | sed -E \
>> >> +-e 's/[[[:space:]]]+-m[[^[:space:]]]*//g' \
[...]
>> Do you want me to quote the whole function (including whitespace)
>> instead?
>> 
>> https://www.gnu.org/software/autoconf/manual/autoconf.html#M4-Quotation
>
> No, your change is right, my r-b apply as is, and I'll do an actual
> am+test after lunch and add my t-b.

Thanks. I've only tested the patch against Mesa 17.0.1 downstream:
- build on FreeBSD 10.3, 11.0, 12.0
- runtime via glxgears (and a few games) + i965 + Skylake GT2

>
> Do you want me to push your patch?

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


Re: [Mesa-dev] MESA and KOTOR

2017-03-13 Thread Federico Dossena
If I put printf("HELLO MESA\n"); into wglGetProcAddress it prints it, so 
some code from Mesa is certainly being executed.


The reason why I suspect that I have a windows dll loaded is that when 
it calls wglGetProcAddress("wglMakeContextCurrentARB") it seems to be 
inside a small DLL, while mesa is like 18mbytes. It doesn't look like 
mesa's dll at all to me... Is there any way I can tell for sure?



Il 2017-03-13 12:59, Emil Velikov ha scritto:

[Adding back mesa-dev, since it seems like you've dropped it by accident]

On 13 March 2017 at 11:42, Federico Dossena  wrote:

Thanks for the reply.

Ok, I have a few new findings:
- It seems that I was wrong, the function that it fails to get the address
of is actually wglMakeContextCurrentARB!

Afacit Mesa (st/wgl) does not advertise WGL_ARB_make_current_read,
hence why the function pointer is NULL.

if the program does not check for the extension alongside the
eglGetProcAddress, then it's broken and you'd need to either
a) address that in the program
b) or, add support for the extension in st/wgl


- Inside opengl32.dll I see it keeps getting the pointer and deleting it
until it finally returns 0
- The thing is... I don't know if that's Mesa or windows's opengl32.dll. I
am very sorry, I really suck at debugging low level code


Simple printf("HELLO MESA\n"); or similar will tell you exactly
where/what you're using.


If someone here has some skill at using stuff like IDA pro, I will happily
send all the files so we can work together.


Since you've got the code for Mesa you really don't need any such
tools. But if anyone's interested to help you out they know how to
contact you.
I won't be able to offer much more help, I'm afraid.

-Emil


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


[Mesa-dev] [PATCH] drm-atomic: Include header file

2017-03-13 Thread Gary Bisson
Include  header file to fix the following build
error:
drm-atomic.c: In function ‘get_plane_id’:
drm-atomic.c:290:44: error: ‘DRM_MODE_OBJECT_PLANE’ undeclared (first
use in this function)
 drmModeObjectGetProperties(drm.fd, id, DRM_MODE_OBJECT_PLANE);

This error only happens when using a toolchain with kernel headers
< 4.7 since the DRM_MODE_OBJECT_* have been moved to uapi headers
in 4.7 [1].

This error was therefore seen with Linaro 2017.02 ARM gnueabihf
toolchain [2].

It has been tested that this patch doesn't affect users using a
toolchain with headers >= 4.7.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8812f38141
[2] 
https://releases.linaro.org/components/toolchain/binaries/latest-6/arm-linux-gnueabihf/gcc-linaro-6.3.1-2017.02-x86_64_arm-linux-gnueabihf.tar.xz

Signed-off-by: Gary Bisson 
---
Hi all,

This issue was discovered using Buildroot and discussed here:
http://lists.busybox.net/pipermail/buildroot/2017-March/186282.html

Let me know if you'd rather have another solution for this problem.

Regards,
Gary
---
 drm-atomic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drm-atomic.c b/drm-atomic.c
index 0b38c32..7c353f5 100644
--- a/drm-atomic.c
+++ b/drm-atomic.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0

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


Re: [Mesa-dev] [PATCH] Convert sed(1) syntax to be compatible with FreeBSD and OpenBSD

2017-03-13 Thread Jan Beich
Eric Engestrom  writes:

>> +echo " `$1`" | sed -E \
>> +-e 's/[[[:space:]]]+-m[[^[:space:]]]*//g' \
>
> These only work for me if I remove the outermost `[]` on each line,
> leaving one pair around `:space:` and one for the set.
> The above line, for instance, becomes:
>   -e 's/[[:space:]]+-m[^[:space:]]*//g' \
>
> Are those outer brackets necessary on *BSD? I don't have one available
> to test this myself.

configure.ac is written in autoconf, so some characters have to be quoted.
`[' and `]' are quote markers, so one layer is stripped. Do you want me
to quote the whole function (including whitespace) instead?

https://www.gnu.org/software/autoconf/manual/autoconf.html#M4-Quotation
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2 3/3] util/sha1: drop _mesa_sha1_{update, format} return type

2017-03-13 Thread Grazvydas Ignotas
On Tue, Mar 14, 2017 at 2:28 AM, Emil Velikov  wrote:
> On 13 March 2017 at 22:38, Grazvydas Ignotas  wrote:
>> On Mon, Mar 13, 2017 at 6:52 PM, Emil Velikov  
>> wrote:
>>> ...
>>> diff --git a/src/util/mesa-sha1.h b/src/util/mesa-sha1.h
>>> index f927d5772d..ecbc708b5e 100644
>>> --- a/src/util/mesa-sha1.h
>>> +++ b/src/util/mesa-sha1.h
>>> @@ -34,7 +34,7 @@ extern "C" {
>>>
>>>  #define _mesa_sha1_init SHA1Init
>>>
>>> -int
>>> +void
>>>  _mesa_sha1_update(struct mesa_sha1 *ctx, const void *data, int size);
>>
>> This has become rather inconsistent, _mesa_sha1_init() is a macro to
>> SHA1Init(), _mesa_sha1_update() is a prototype for a trivial
>> implementation, and _mesa_sha1_final() is an inline function. Maybe
>> make all 3 inlines instead, so the names appear in debug stack dumps?
>>
> v1 did that, but after rebasing earlier GCC started throwing an angry
> error due to the different type of data.
> Wanted to get these out asap, since they make your patches easier.
> Will take a look why/how that happens in a bit.

It's probably while compiling c++ code, where type checking is more
strict and you must cast void * pointers to other pointer types,
unlike in C where you don't have to.

>> In either case:
>> Reviewed-by: Grazvydas Ignotas 

... for the series.

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


Re: [Mesa-dev] [PATCH] anv/blorp: Only set a clear color for resolves if fast-cleared

2017-03-13 Thread Emil Velikov
On 13 March 2017 at 19:08, Jason Ekstrand  wrote:
> On Mon, Mar 13, 2017 at 11:19 AM, Emil Velikov 
> wrote:
>>
>> On 5 March 2017 at 16:36, Eduardo Lima Mitev  wrote:
>> > Reviewed-by: Eduardo Lima Mitev 
>> >
>> > On 03/04/2017 01:56 AM, Jason Ekstrand wrote:
>> >> Cc: "17.0" 
>> >> ---
>> >>  src/intel/vulkan/anv_blorp.c | 3 ++-
>> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> Is there anything wrong with the patch or it simply fell through the
>> cracks ?
>
>
> There was a small issue but both this patch and the fix landed this morning.
>
Right so the patch is superseded [by 6b644e571e2 ("anv: Stall before
fast-clear operations")] - I wasn't too sure.
Ftr the new patch depends on many others which have not landed in 13.0
so, I'm leaning that we should avoid it there.

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


Re: [Mesa-dev] [PATCH 2/3] gbm: Introduce modifiers into surface/bo creation

2017-03-13 Thread Ben Widawsky

On 17-03-10 11:34:19, Jason Ekstrand wrote:

On Thu, Mar 9, 2017 at 6:52 PM, Jason Ekstrand  wrote:


On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky  wrote:


The idea behind modifiers like this is that the user of GBM will have
some mechanism to query what properties the hardware supports for its BO
or surface. This information is directly passed in (and stored) so that
the DRI implementation can create an image with the appropriate
attributes.

A getter() will be added later so that the user GBM will be able to
query what modifier should be used.

Only in surface creation, the modifiers are stored until the BO is
actually allocated. In regular buffer allocation, the correct modifier
can (will be, in future patches be chosen at creation time.

v2: Make sure to check if count is non-zero in addition to testing if
calloc fails. (Daniel)

v3: Remove "usage" and "flags" from modifier creation. Requested by
Kristian.

v4: Take advantage of the "INVALID" modifier added by the GET_PLANE2
series.

v5: Don't bother with storing modifiers for gbm_bo_create because that's
a synchronous operation and we can actually select the correct modifier
at create time (done in a later patch) (Jason)

Cc: Kristian Høgsberg 
Cc: Jason Ekstrand 
References (v4): https://lists.freedesktop.org/
archives/intel-gfx/2017-January/116636.html
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 src/egl/drivers/dri2/platform_drm.c  | 19 ---
 src/gbm/backends/dri/gbm_dri.c   | 42
++--
 src/gbm/gbm-symbols-check|  2 ++
 src/gbm/main/gbm.c   | 29 --
 src/gbm/main/gbm.h   | 12 +
 src/gbm/main/gbmint.h| 12 +++--
 src/mesa/drivers/dri/i965/intel_screen.c | 18 ++
 7 files changed, 119 insertions(+), 15 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c
b/src/egl/drivers/dri2/platform_drm.c
index e5e8c60596..cf35ce8a1f 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -230,10 +230,21 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)

if (dri2_surf->back == NULL)
   return -1;
-   if (dri2_surf->back->bo == NULL)
-  dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_dri->base.base,
- surf->base.width,
surf->base.height,
- surf->base.format,
surf->base.flags);
+   if (dri2_surf->back->bo == NULL) {
+  if (surf->base.modifiers)
+ dri2_surf->back->bo = gbm_bo_create_with_modifiers(&
dri2_dpy->gbm_dri->base.base,
+
surf->base.width, surf->base.height,
+
surf->base.format,
+
surf->base.modifiers,
+
surf->base.count);
+  else
+ dri2_surf->back->bo = gbm_bo_create(_dpy->gbm_d
ri->base.base,
+ surf->base.width,
+ surf->base.height,
+ surf->base.format,
+ surf->base.flags);
+
+   }
if (dri2_surf->back->bo == NULL)
   return -1;

diff --git a/src/gbm/backends/dri/gbm_dri.c
b/src/gbm/backends/dri/gbm_dri.c
index 7106dc1229..d45ba94080 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -1023,13 +1023,20 @@ free_bo:
 static struct gbm_bo *
 gbm_dri_bo_create(struct gbm_device *gbm,
   uint32_t width, uint32_t height,
-  uint32_t format, uint32_t usage)
+  uint32_t format, uint32_t usage,
+  const uint64_t *modifiers,
+  const unsigned int count)
 {
struct gbm_dri_device *dri = gbm_dri_device(gbm);
struct gbm_dri_bo *bo;
int dri_format;
unsigned dri_use = 0;

+   /* Callers of this may specify a modifier, or a dri usage, but not
both. The
+* newer modifier interface deprecates the older usage flags.
+*/
+   assert(!(usage && count));
+
if (usage & GBM_BO_USE_WRITE || dri->image == NULL)
   return create_dumb(gbm, width, height, format, usage);

@@ -1087,11 +1094,21 @@ gbm_dri_bo_create(struct gbm_device *gbm,
/* Gallium drivers requires shared in order to get the handle/stride
*/
dri_use |= __DRI_IMAGE_USE_SHARE;

-   bo->image =
-  dri->image->createImage(dri->screen,
-  width, height,
-  dri_format, dri_use,
-  bo);
+   if (!dri->image || dri->image->base.version < 14 ||
+   !dri->image->createImageWithModifiers) {
+  if (modifiers)
+ fprintf(stderr, "Modifiers specified, but DRI is too old\n");



This seems a bit on the sketchy side.  Do we want to fail, set errno to
ENOSYS, and return NULL in this 

Re: [Mesa-dev] [PATCH v2 3/3] util/sha1: drop _mesa_sha1_{update, format} return type

2017-03-13 Thread Emil Velikov
On 13 March 2017 at 22:38, Grazvydas Ignotas  wrote:
> On Mon, Mar 13, 2017 at 6:52 PM, Emil Velikov  
> wrote:
>> ...
>> diff --git a/src/util/mesa-sha1.h b/src/util/mesa-sha1.h
>> index f927d5772d..ecbc708b5e 100644
>> --- a/src/util/mesa-sha1.h
>> +++ b/src/util/mesa-sha1.h
>> @@ -34,7 +34,7 @@ extern "C" {
>>
>>  #define _mesa_sha1_init SHA1Init
>>
>> -int
>> +void
>>  _mesa_sha1_update(struct mesa_sha1 *ctx, const void *data, int size);
>
> This has become rather inconsistent, _mesa_sha1_init() is a macro to
> SHA1Init(), _mesa_sha1_update() is a prototype for a trivial
> implementation, and _mesa_sha1_final() is an inline function. Maybe
> make all 3 inlines instead, so the names appear in debug stack dumps?
>
v1 did that, but after rebasing earlier GCC started throwing an angry
error due to the different type of data.
Wanted to get these out asap, since they make your patches easier.
Will take a look why/how that happens in a bit.

> In either case:
> Reviewed-by: Grazvydas Ignotas 

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


[Mesa-dev] [PATCH] android: intel/compiler: fix include paths

2017-03-13 Thread Mauro Rossi
Fixes the following building error:

out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libmesa_intel_compiler_intermediates/compiler/brw_nir_trig_workarounds.c:1:10:
 fatal error: 'brw_nir.h' file not found
 ^
1 error generated.

Fixes: 700bebb "i965: Move the back-end compiler to src/intel/compiler"
---
 src/intel/Android.compiler.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/Android.compiler.mk b/src/intel/Android.compiler.mk
index 8bbfb1c..48a19a0 100644
--- a/src/intel/Android.compiler.mk
+++ b/src/intel/Android.compiler.mk
@@ -43,7 +43,8 @@ LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/gallium/include \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,)/glsl \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
-   $(MESA_TOP)/src/compiler/nir
+   $(MESA_TOP)/src/compiler/nir \
+   $(MESA_TOP)/src/intel/compiler
 
 LOCAL_SHARED_LIBRARIES := \
libdrm_intel
-- 
2.10.2

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


Re: [Mesa-dev] [PATCH] radv: setup llvm target data layout

2017-03-13 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

On Mon, Mar 13, 2017 at 9:52 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Ported from radeonsi, pointed out by Tom.
>
> "This prevents LLVM from using sext instructions for local memory
> offsets and allows the backend to fold immediate offsets into the
> instruction. This also prevents some incorrect code generation for
> ptrtoint and inttoptr instructions."
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 47091a2..417b34e 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -4911,6 +4911,13 @@ LLVMModuleRef 
> ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
> memset(shader_info, 0, sizeof(*shader_info));
>
> LLVMSetTarget(ctx.module, options->supports_spill ? 
> "amdgcn-mesa-mesa3d" : "amdgcn--");
> +
> +   LLVMTargetDataRef data_layout = LLVMCreateTargetDataLayout(tm);
> +   char *data_layout_str = LLVMCopyStringRepOfTargetData(data_layout);
> +   LLVMSetDataLayout(ctx.module, data_layout_str);
> +   LLVMDisposeTargetData(data_layout);
> +   LLVMDisposeMessage(data_layout_str);
> +
> setup_types();
>
> ctx.builder = LLVMCreateBuilderInContext(ctx.context);
> --
> 2.9.3
>
> ___
> 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 3/4] util/disk_cache: have disk_cache_put() optionally free memory

2017-03-13 Thread Timothy Arceri



On 13/03/17 21:16, Grazvydas Ignotas wrote:

On Mon, Mar 13, 2017 at 3:01 AM, Timothy Arceri  wrote:

The following patch will move disk_cache_put() into a thread queue
so we need to be sure memory is not freed before the thread is
completed. Here we move responsibility for releasing the memory
onto the disk cache.


I think this is a fragile interface and very easy to mess up, cache
should just make a copy instead. You already do that at one callsite
anyway.

You could even do that while creating struct disk_cache_put_job to
avoid an extra malloc:

struct disk_cache_put_job {
   ...
   size_t size;
   uint8_t mem[0];
};
...
create_put_job(struct disk_cache *cache, const cache_key key,
   const void *data, size_t size)
{
   struct disk_cache_put_job *dc_job = malloc(sizeof(*dc_job) + size);
   ...
   memcpy(dc_job->mem, data, size);
   ...
}

That's of course just my opinion, I hope somebody (Marek?) joins in.


I'm not all that happy with the interface by IMO it's better than than 
doing an extra memcpy. These have the potential to be around 200KB+ and 
this can be happening at draw time.


IMO the slightly awkward interface is the better option, it's not like 
it's going to be a common function to implement, besides the common code 
(which is done) each driver should only have to call it once.


We are forced to do the copy for radeonsi, but those copies as far as I 
know should be rather small.


Anyway happy to hear other opinions on this.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/4] util/disk_cache: use a thread queue to write to shader cache

2017-03-13 Thread Grazvydas Ignotas
On Tue, Mar 14, 2017 at 12:20 AM, Timothy Arceri  wrote:
>
>
> On 13/03/17 22:53, Grazvydas Ignotas wrote:
>>
>> On Mon, Mar 13, 2017 at 3:01 AM, Timothy Arceri 
>> wrote:
>>>
>>> This should help reduce any overhead added by the shader cache
>>> when programs are not found in the cache.
>>>
>>> To avoid creating any special function just for the sake of the
>>> tests we add a one second delay whenever we call dick_cache_put()
>>> to give it time to finish.
>>> ---
>>>  src/compiler/glsl/tests/cache_test.c | 49
>>> +++-
>>>  src/util/disk_cache.c| 41 --
>>>  2 files changed, 71 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/src/compiler/glsl/tests/cache_test.c
>>> b/src/compiler/glsl/tests/cache_test.c
>>> index 6451e65..f8259e0 100644
>>> --- a/src/compiler/glsl/tests/cache_test.c
>>> +++ b/src/compiler/glsl/tests/cache_test.c
>>> @@ -25,20 +25,21 @@
>>>
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  #include "util/mesa-sha1.h"
>>>  #include "util/disk_cache.h"
>>>
>>>  bool error = false;
>>>
>>>  #ifdef ENABLE_SHADER_CACHE
>>>
>>>  static void
>>> @@ -224,20 +225,27 @@ does_cache_contain(struct disk_cache *cache,
>>> cache_key key)
>>>
>>> if (result) {
>>>free(result);
>>>return true;
>>> }
>>>
>>> return false;
>>>  }
>>>
>>>  static void
>>> +wait_one_second()
>>> +{
>>> +unsigned wait_time = time(0) + 1;
>>> +while (time(0) < wait_time);
>>> +}
>>
>>
>> If you enter this function at an unfortunate time (just as the second
>> is about to change) the function will not wait at all, so this will
>> cause spurious test failures. If you just sleep() it will waste
>> everyone's time on make check.
>>
>> It looks like flushing the queue in disk_cache_get() should solve
>> this, it might be needed anyway because the app may request something
>> while the thread is still writing it out?
>>
>
> I agree the wait is not ideal but it's more ideal that adding code just to
> pass tests. It's very unlikely an app will try to relink the same shader
> combination while we are still writing out and if it does I'm happy for this
> to trigger a relink, rather than adding more code which is unlikely to ever
> be used. If it's stuck waiting on I/O it's likely better to just recompile
> anyway.
>
> I guess the only options other than the wait are a flush helper that is only
> used by the test or expose the cache struct and access the queue directly in
> the test. Not really sure which of those is better.

I agree an interface just for the test might be too much. Could maybe
use a polling loop checking if the entry landed every 100ms or so and
giving up after some retries? Could also just stick a 300ms (or
similar) sleep but I fear it may cause spurious test failures on busy
systems. I think wine has that problem with their tests as they rely
on things happening after fixed sleep periods a lot.

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


Re: [Mesa-dev] [PATCH] radv: Reinitialise loaderMagic when allocating a cached command buffer

2017-03-13 Thread Bas Nieuwenhuizen
Thanks. Pushed.

- Bas

On Mon, Mar 13, 2017 at 2:28 PM, Alex Smith  wrote:
> This must be set to ICD_LOADER_MAGIC by vkAllocateCommandBuffers, which
> was being done when allocating a new buffer but not when reusing an
> existing one in the cache. This would hit an assertion and crash in
> debug builds of the Vulkan loader.
>
> Fixes: 682248db451f ("radv: Cache command buffers in command pool.")
> Signed-off-by: Alex Smith 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 10c5142..17be0a1 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -1662,6 +1662,7 @@ VkResult radv_AllocateCommandBuffers(
> list_addtail(_buffer->pool_link, 
> >cmd_buffers);
>
> radv_reset_cmd_buffer(cmd_buffer);
> +   cmd_buffer->_loader_data.loaderMagic = 
> ICD_LOADER_MAGIC;
> cmd_buffer->level = pAllocateInfo->level;
>
> pCommandBuffers[i] = 
> radv_cmd_buffer_to_handle(cmd_buffer);
> --
> 2.9.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/4] util/disk_cache: add helpers for creating/destroying disk cache put jobs

2017-03-13 Thread Grazvydas Ignotas
On Tue, Mar 14, 2017 at 12:06 AM, Timothy Arceri  wrote:
> On 13/03/17 22:55, Grazvydas Ignotas wrote:
>>
>> On Mon, Mar 13, 2017 at 3:01 AM, Timothy Arceri 
>> wrote:
>>>
>>> ---
>>>  src/util/disk_cache.c | 48
>>> 
>>>  1 file changed, 48 insertions(+)
>>>
>>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
>>> index 3b1cffc..160774a 100644
>>> --- a/src/util/disk_cache.c
>>> +++ b/src/util/disk_cache.c
>>> @@ -71,20 +71,40 @@ struct disk_cache {
>>> /* Pointer to total size of all objects in cache (within index_mmap)
>>> */
>>> uint64_t *size;
>>>
>>> /* Pointer to stored keys, (within index_mmap). */
>>> uint8_t *stored_keys;
>>>
>>> /* Maximum size of all cached objects (in bytes). */
>>> uint64_t max_size;
>>>  };
>>>
>>> +struct disk_cache_put_job {
>>> +   struct util_queue_fence fence;
>>> +
>>> +   struct disk_cache *cache;
>>> +
>>> +   cache_key key;
>>> +
>>> +   /* Cache data to be compressed and written. */
>>> +   const void *data;
>>> +
>>> +   /* Size of data to be compressed and written. */
>>> +   size_t size;
>>> +
>>> +   /* Memory to be freed by util_queue_execute_func cleanup.
>>> +*
>>> +* Note: The memory is expected to have been created with ralloc.
>>> +*/
>>> +   void *mem;
>>> +};
>>> +
>>>  /* Create a directory named 'path' if it does not already exist.
>>>   *
>>>   * Returns: 0 if path already exists as a directory or if created.
>>>   * -1 in all other cases.
>>>   */
>>>  static int
>>>  mkdir_if_needed(const char *path)
>>>  {
>>> struct stat sb;
>>>
>>> @@ -728,20 +748,48 @@ deflate_and_write_to_disk(const void *in_data,
>>> size_t in_data_size, int dest,
>>> } while (flush != Z_FINISH);
>>>
>>> /* stream should be complete */
>>> assert(ret == Z_STREAM_END);
>>>
>>> /* clean up and return */
>>> (void)deflateEnd();
>>> return compressed_size;
>>>  }
>>>
>>> +static struct disk_cache_put_job *
>>> +create_put_job(struct disk_cache *cache, const cache_key key,
>>> +   const void *data, size_t size, void *mem)
>>> +{
>>> +   struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *)
>>> +  malloc(sizeof(struct disk_cache_put_job));
>>> +
>>> +   if (dc_job) {
>>> +  dc_job->cache = cache;
>>> +  memcpy(dc_job->key, key, sizeof(cache_key));
>>> +  dc_job->data = data;
>>> +  dc_job->size = size;
>>> +  dc_job->mem = mem;
>>> +   }
>>> +
>>> +   return dc_job;
>>> +}
>>> +
>>> +static void
>>> +destroy_put_job(void *job, int thread_index)
>>
>>
>> It looks like thread_index is unused by the series.
>>
>
> Right but that's the interface of u_queue, are you suggesting a change? I
> don't think it matters much.

Hmm no, haven't noticed it's in the interface.

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


Re: [Mesa-dev] [PATCH v2 3/3] util/sha1: drop _mesa_sha1_{update, format} return type

2017-03-13 Thread Grazvydas Ignotas
On Mon, Mar 13, 2017 at 6:52 PM, Emil Velikov  wrote:
> ...
> diff --git a/src/util/mesa-sha1.h b/src/util/mesa-sha1.h
> index f927d5772d..ecbc708b5e 100644
> --- a/src/util/mesa-sha1.h
> +++ b/src/util/mesa-sha1.h
> @@ -34,7 +34,7 @@ extern "C" {
>
>  #define _mesa_sha1_init SHA1Init
>
> -int
> +void
>  _mesa_sha1_update(struct mesa_sha1 *ctx, const void *data, int size);

This has become rather inconsistent, _mesa_sha1_init() is a macro to
SHA1Init(), _mesa_sha1_update() is a prototype for a trivial
implementation, and _mesa_sha1_final() is an inline function. Maybe
make all 3 inlines instead, so the names appear in debug stack dumps?

In either case:
Reviewed-by: Grazvydas Ignotas 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] radv: setup llvm target data layout

2017-03-13 Thread Tom Stellard
On Tue, Mar 14, 2017 at 06:52:19AM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Ported from radeonsi, pointed out by Tom.
> 
> "This prevents LLVM from using sext instructions for local memory
> offsets and allows the backend to fold immediate offsets into the
> instruction. This also prevents some incorrect code generation for
> ptrtoint and inttoptr instructions."
> 
> Signed-off-by: Dave Airlie 

Reviewed-by: Tom Stellard 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 47091a2..417b34e 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -4911,6 +4911,13 @@ LLVMModuleRef 
> ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
>   memset(shader_info, 0, sizeof(*shader_info));
>  
>   LLVMSetTarget(ctx.module, options->supports_spill ? 
> "amdgcn-mesa-mesa3d" : "amdgcn--");
> +
> + LLVMTargetDataRef data_layout = LLVMCreateTargetDataLayout(tm);
> + char *data_layout_str = LLVMCopyStringRepOfTargetData(data_layout);
> + LLVMSetDataLayout(ctx.module, data_layout_str);
> + LLVMDisposeTargetData(data_layout);
> + LLVMDisposeMessage(data_layout_str);
> +
>   setup_types();
>  
>   ctx.builder = LLVMCreateBuilderInContext(ctx.context);
> -- 
> 2.9.3
> 
> ___
> 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] android: i965: generate code for OA counter queries

2017-03-13 Thread Mauro Rossi
2017-03-13 14:00 GMT+01:00 Emil Velikov :

> On 12 March 2017 at 23:01, Mauro Rossi  wrote:
> > Automake generation rules are replicated for android.
> > $* macro was expected to return "hsw" but instead gives "hsw.{h,c}"
> > so $(basename $*) is used as a workaround
> > to set the correct --chipset option for brw_oa.py script.
> >
> > Build tested with nougat-x86
> >
> > Fixes: e565505 "i965: Add script to gen code for OA counter queries"
>
> Let copy/pasta continue ... sigh, seems like people want to
> deliberatelly make their lives harder :-(
>

Hi Emil,

I don't see how just doing an include of Makefile.gen
 with current automake generation rules
would "cheat" Android Build System as we speak.

The generated files need to go in $OUT/gen/{STATIC,SHARED}_
LIBRARIES/[module_name]_intermediates
or Android Build System will just not care and throw a bunch of errors,
because it will check LOCAL_GENERATED_SOURCES list (with absolute path)
against the declared generation rules

In my understanding Makefile.gen as extrapolation of current am generation
rules,
will not suffice, would you please show a working PoC,
even for just one (medium/complex) prototype generation rule of your choice?

Thanks

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


[Mesa-dev] [PATCH 4/7] isl: Validate the calculated row pitch

2017-03-13 Thread Chad Versace
Validate that it fits in RENDER_SURFACE_STATE::SurfacePitch or, if it's
an aux surface, AuxiliarySurfacePitch.
---
 src/intel/isl/isl.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 784566749b4..405f5b917fe 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1089,18 +1089,39 @@ isl_calc_min_row_pitch(const struct isl_device *dev,
}
 }
 
-static uint32_t
+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 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;
+
+   /* Check that the pitch fits in RENDER_SURFACE_STATE::SurfacePitch or
+* AuxiliarySurfacePitch.
+*/
+   if (dim_layout == ISL_DIM_LAYOUT_GEN9_1D) {
+  /* SurfacePitch is ignored for this layout.
+   * FINISHME: How to validate row pitch for ISL_DIM_LAYOUT_GEN9_1D?
+   */
+   } else if (isl_tiling_is_aux(tile_info->tiling)) {
+  if (row_pitch_tiles > (1 << 9))
+ return false;
+   } else if (row_pitch > (1 << 17)) {
+  return false;
+   }
+
+   *out_row_pitch = row_pitch;
+   return true;
 }
 
 /**
@@ -1275,8 +1296,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 1/7] isl: Drop misplaced comment about padding

2017-03-13 Thread Chad Versace
isl has a giant comment that explains the hardware's padding
requirements. (Hint: Cache lines and page faults). But the comment is in
the wrong place, in isl_calc_linear_row_pitch(), which is unrelated to
padding.

The important parts of that comment were copied to
isl_apply_surface_padding() long ago. So drop the misplaced comment.
---
 src/intel/isl/isl.c | 46 --
 1 file changed, 46 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 6eb1e93efd9..ebc8d84be0f 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1004,53 +1004,7 @@ isl_calc_linear_row_pitch(const struct isl_device *dev,
   const struct isl_extent2d *phys_slice0_sa)
 {
const struct isl_format_layout *fmtl = isl_format_get_layout(info->format);
-
uint32_t row_pitch = info->min_pitch;
-
-   /* First, align the surface to a cache line boundary, as the PRM explains
-* below.
-*
-* From the Broadwell PRM >> Volume 5: Memory Views >> Common Surface
-* Formats >> Surface Padding Requirements >> Render Target and Media
-* Surfaces:
-*
-*The data port accesses data (pixels) outside of the surface if they
-*are contained in the same cache request as pixels that are within the
-*surface. These pixels will not be returned by the requesting message,
-*however if these pixels lie outside of defined pages in the GTT,
-*a GTT error will result when the cache request is processed. In order
-*to avoid these GTT errors, “padding” at the bottom of the surface is
-*sometimes necessary.
-*
-* From the Broadwell PRM >> Volume 5: Memory Views >> Common Surface
-* Formats >> Surface Padding Requirements >> Sampling Engine Surfaces:
-*
-*The sampling engine accesses texels outside of the surface if they
-*are contained in the same cache line as texels that are within the
-*surface.  These texels will not participate in any calculation
-*performed by the sampling engine and will not affect the result of
-*any sampling engine operation, however if these texels lie outside of
-*defined pages in the GTT, a GTT error will result when the cache line
-*is accessed. In order to avoid these GTT errors, “padding” at the
-*bottom and right side of a sampling engine surface is sometimes
-*necessary.
-*
-*It is possible that a cache line will straddle a page boundary if the
-*base address or pitch is not aligned. All pages included in the cache
-*lines that are part of the surface must map to valid GTT entries to
-*avoid errors. To determine the necessary padding on the bottom and
-*right side of the surface, refer to the table in  Alignment Unit Size
-*section for the i and j parameters for the surface format in use. The
-*surface must then be extended to the next multiple of the alignment
-*unit size in each dimension, and all texels contained in this
-*extended surface must have valid GTT entries.
-*
-*For example, suppose the surface size is 15 texels by 10 texels and
-*the alignment parameters are i=4 and j=2. In this case, the extended
-*surface would be 16 by 10. Note that these calculations are done in
-*texels, and must be converted to bytes based on the surface format
-*being used to determine whether additional pages need to be defined.
-*/
assert(phys_slice0_sa->w % fmtl->bw == 0);
const uint32_t bs = fmtl->bpb / 8;
row_pitch = MAX(row_pitch, bs * (phys_slice0_sa->w / fmtl->bw));
-- 
2.12.0

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


[Mesa-dev] [PATCH 3/7] isl: Add func isl_tiling_is_aux()

2017-03-13 Thread Chad Versace
---
 src/intel/isl/isl.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index 9d92906ca71..b79793b0c93 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -473,6 +473,9 @@ typedef uint32_t isl_tiling_flags_t;
 /** The Skylake BSpec refers to Yf and Ys as "standard tiling formats". */
 #define ISL_TILING_STD_Y_MASK (ISL_TILING_Yf_BIT | \
ISL_TILING_Ys_BIT)
+
+#define ISL_TILING_AUX_MASK   (ISL_TILING_HIZ_BIT | \
+   ISL_TILING_CCS_BIT)
 /** @} */
 
 /**
@@ -1182,6 +1185,12 @@ isl_tiling_is_std_y(enum isl_tiling tiling)
return (1u << tiling) & ISL_TILING_STD_Y_MASK;
 }
 
+static inline bool
+isl_tiling_is_aux(enum isl_tiling tiling)
+{
+   return (1u << tiling) & ISL_TILING_AUX_MASK;
+}
+
 struct isl_extent2d ATTRIBUTE_CONST
 isl_get_interleaved_msaa_px_size_sa(uint32_t samples);
 
-- 
2.12.0

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


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

2017-03-13 Thread Chad Versace
The caller does so by setting the new field
isl_surf_init_info::row_pitch.

v2:
  - Validate the requested row_pitch.
---
 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 405f5b917fe..0e0eb35ef52 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1100,10 +1100,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;
 
/* Check that the pitch fits in RENDER_SURFACE_STATE::SurfacePitch or
diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
index b79793b0c93..fb2bcfaec10 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -816,6 +816,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 6/7] intel: Fix requests for exact surface row pitch

2017-03-13 Thread 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.

Reviewed-by: Nanley Chery 
Reviewed-by: Anuj Phogat 
---
 src/intel/blorp/blorp_blit.c | 3 +--
 src/intel/vulkan/anv_blorp.c | 3 +--
 src/intel/vulkan/anv_image.c | 2 +-
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 0cc5a840338..a3d7937825d 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -1419,13 +1419,12 @@ 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);
 
/* 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 8de339cf09e..be2b1bd51dc 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -159,11 +159,10 @@ get_blorp_surf_for_anv_buffer(struct anv_device *device,
  .levels = 1,
  .array_len = 1,
  .samples = 1,
- .min_pitch = row_pitch,
+ .row_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);
 }
 
 static void
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 5f17351e66a..e742d0565d4 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 7/7] isl: Drop unused isl_surf_init_info::min_pitch

2017-03-13 Thread Chad Versace
Reviewed-by: Nanley Chery 
Reviewed-by: Anuj Phogat 
---
 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 0e0eb35ef52..9ef078d654a 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1041,11 +1041,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
@@ -1066,11 +1062,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 fb2bcfaec10..22069134ef8 100644
--- a/src/intel/isl/isl.h
+++ b/src/intel/isl/isl.h
@@ -813,9 +813,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/7] isl: Refactor row pitch calculation (v2)

2017-03-13 Thread Chad Versace
The calculations of row_pitch, the row pitch's alignment, surface size,
and base_alignment were mixed together. This patch moves the calculation
of row_pitch and its alignment to occur before the calculation of
surface_size and base_alignment.

This simplifies a follow-on patch that adds a new member, 'row_pitch',
to struct isl_surf_init_info.

v2:
  - Also extract the row pitch alignment.
  - More helper functions that will later help validate the row pitch.
---
 src/intel/isl/isl.c | 122 ++--
 1 file changed, 89 insertions(+), 33 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index ebc8d84be0f..784566749b4 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -995,19 +995,12 @@ isl_calc_array_pitch_el_rows(const struct isl_device *dev,
return pitch_el_rows;
 }
 
-/**
- * Calculate the pitch of each surface row, in bytes.
- */
 static uint32_t
-isl_calc_linear_row_pitch(const struct isl_device *dev,
-  const struct isl_surf_init_info *restrict info,
-  const struct isl_extent2d *phys_slice0_sa)
+isl_calc_row_pitch_alignment(const struct isl_surf_init_info *surf_info,
+ const struct isl_tile_info *tile_info)
 {
-   const struct isl_format_layout *fmtl = isl_format_get_layout(info->format);
-   uint32_t row_pitch = info->min_pitch;
-   assert(phys_slice0_sa->w % fmtl->bw == 0);
-   const uint32_t bs = fmtl->bpb / 8;
-   row_pitch = MAX(row_pitch, bs * (phys_slice0_sa->w / fmtl->bw));
+   if (tile_info->tiling != ISL_TILING_LINEAR)
+  return tile_info->phys_extent_B.width;
 
/* From the Broadwel PRM >> Volume 2d: Command Reference: Structures >>
 * RENDER_SURFACE_STATE Surface Pitch (p349):
@@ -1023,15 +1016,91 @@ isl_calc_linear_row_pitch(const struct isl_device *dev,
 *- For other linear surfaces, the pitch can be any multiple of
 *  bytes.
 */
-   if (info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) {
-  if (isl_format_is_yuv(info->format)) {
- row_pitch = isl_align_npot(row_pitch, 2 * bs);
+   const struct isl_format_layout *fmtl = 
isl_format_get_layout(surf_info->format);
+   const uint32_t bs = fmtl->bpb / 8;
+
+   if (surf_info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) {
+  if (isl_format_is_yuv(surf_info->format)) {
+ return 2 * bs;
   } else  {
- row_pitch = isl_align_npot(row_pitch, bs);
+ return bs;
   }
}
 
-   return row_pitch;
+   return 1;
+}
+
+static uint32_t
+isl_calc_linear_min_row_pitch(const struct isl_device *dev,
+  const struct isl_surf_init_info *info,
+  const struct isl_extent2d *phys_slice0_sa,
+  uint32_t alignment)
+{
+   const struct isl_format_layout *fmtl = isl_format_get_layout(info->format);
+   const uint32_t bs = fmtl->bpb / 8;
+
+   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;
+}
+
+static uint32_t
+isl_calc_tiled_min_row_pitch(const struct isl_device *dev,
+ const struct isl_surf_init_info *surf_info,
+ const struct isl_tile_info *tile_info,
+ const struct isl_extent2d *phys_slice0_sa,
+ uint32_t alignment)
+{
+   const struct isl_format_layout *fmtl = 
isl_format_get_layout(surf_info->format);
+
+   assert(fmtl->bpb % tile_info->format_bpb == 0);
+   assert(phys_slice0_sa->w % fmtl->bw == 0);
+
+   const uint32_t tile_el_scale = fmtl->bpb / tile_info->format_bpb;
+   const uint32_t total_w_el = phys_slice0_sa->width / fmtl->bw;
+   const uint32_t total_w_tl =
+  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;
+}
+
+static uint32_t
+isl_calc_min_row_pitch(const struct isl_device *dev,
+   const struct isl_surf_init_info *surf_info,
+   const struct isl_tile_info *tile_info,
+   const struct isl_extent2d *phys_slice0_sa,
+   uint32_t alignment)
+{
+   if (tile_info->tiling == ISL_TILING_LINEAR) {
+  return isl_calc_linear_min_row_pitch(dev, surf_info, phys_slice0_sa,
+   alignment);
+   } else {
+  return isl_calc_tiled_min_row_pitch(dev, surf_info, tile_info,
+  phys_slice0_sa, alignment);
+   }
+}
+
+static uint32_t
+isl_calc_row_pitch(const struct isl_device *dev,
+ 

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

2017-03-13 Thread 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-v02
gitweb: 
http://git.kiwitree.net/cgit/~chadv/mesa/tag/?h=chadv/review/isl-request-exact-row-pitch-v02

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

Testing:
  I'm locally running dEQP-VK.
  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 (7):
  isl: Drop misplaced comment about padding
  isl: Refactor row pitch calculation (v2)
  isl: Add func isl_tiling_is_aux()
  isl: Validate the calculated row pitch
  isl: Let isl_surf_init's caller set the exact row pitch (v2)
  intel: Fix requests for exact surface row pitch
  isl: Drop unused isl_surf_init_info::min_pitch

 src/intel/blorp/blorp_blit.c |   3 +-
 src/intel/isl/isl.c  | 196 ++-
 src/intel/isl/isl.h  |  16 +++-
 src/intel/vulkan/anv_blorp.c |   3 +-
 src/intel/vulkan/anv_image.c |   2 +-
 5 files changed, 134 insertions(+), 86 deletions(-)

-- 
2.12.0

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


Re: [Mesa-dev] [PATCH 4/4] util/disk_cache: use a thread queue to write to shader cache

2017-03-13 Thread Timothy Arceri



On 13/03/17 22:53, Grazvydas Ignotas wrote:

On Mon, Mar 13, 2017 at 3:01 AM, Timothy Arceri  wrote:

This should help reduce any overhead added by the shader cache
when programs are not found in the cache.

To avoid creating any special function just for the sake of the
tests we add a one second delay whenever we call dick_cache_put()
to give it time to finish.
---
 src/compiler/glsl/tests/cache_test.c | 49 +++-
 src/util/disk_cache.c| 41 --
 2 files changed, 71 insertions(+), 19 deletions(-)

diff --git a/src/compiler/glsl/tests/cache_test.c 
b/src/compiler/glsl/tests/cache_test.c
index 6451e65..f8259e0 100644
--- a/src/compiler/glsl/tests/cache_test.c
+++ b/src/compiler/glsl/tests/cache_test.c
@@ -25,20 +25,21 @@

 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "util/mesa-sha1.h"
 #include "util/disk_cache.h"

 bool error = false;

 #ifdef ENABLE_SHADER_CACHE

 static void
@@ -224,20 +225,27 @@ does_cache_contain(struct disk_cache *cache, cache_key 
key)

if (result) {
   free(result);
   return true;
}

return false;
 }

 static void
+wait_one_second()
+{
+unsigned wait_time = time(0) + 1;
+while (time(0) < wait_time);
+}


If you enter this function at an unfortunate time (just as the second
is about to change) the function will not wait at all, so this will
cause spurious test failures. If you just sleep() it will waste
everyone's time on make check.

It looks like flushing the queue in disk_cache_get() should solve
this, it might be needed anyway because the app may request something
while the thread is still writing it out?



I agree the wait is not ideal but it's more ideal that adding code just 
to pass tests. It's very unlikely an app will try to relink the same 
shader combination while we are still writing out and if it does I'm 
happy for this to trigger a relink, rather than adding more code which 
is unlikely to ever be used. If it's stuck waiting on I/O it's likely 
better to just recompile anyway.


I guess the only options other than the wait are a flush helper that is 
only used by the test or expose the cache struct and access the queue 
directly in the test. Not really sure which of those is better.

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


Re: [Mesa-dev] [PATCH 2/3] anv: Use vk_outarray in vkEnumeratePhysicalDevices

2017-03-13 Thread Chad Versace
On Mon 13 Mar 2017, Chad Versace wrote:
> On Mon 13 Mar 2017, Jason Ekstrand wrote:
> > On Mon, Mar 13, 2017 at 2:32 PM, Jason Ekstrand 
> > wrote:
> > 
> > > On Mon, Mar 13, 2017 at 2:23 PM, Chad Versace 
> > > wrote:
> > >
> > >> No intended change in behavior. Just a refactor.
> > >> ---
> > >>  src/intel/vulkan/anv_device.c | 32 ++--
> > >>  1 file changed, 6 insertions(+), 26 deletions(-)
> > >>
> 
> 
> > >> +   if (vk_outarray_is_incomple())
> > >> +  return VK_INCOMPLETE;
> > >>
> > >
> > > I still think I'd prefer a vk_outarray_status() helper and this would be
> > > "return vk_outarray_status()".  But meh...
> 
> Ok. I'll change that to `return vk_outarray_status()`.
> 
> > With or without that suggestion,
> > 
> > Reviewed-by: Jason Ekstrand 

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


Re: [Mesa-dev] [PATCH 2/3] anv: Use vk_outarray in vkEnumeratePhysicalDevices

2017-03-13 Thread Chad Versace
On Mon 13 Mar 2017, Jason Ekstrand wrote:
> On Mon, Mar 13, 2017 at 2:32 PM, Jason Ekstrand 
> wrote:
> 
> > On Mon, Mar 13, 2017 at 2:23 PM, Chad Versace 
> > wrote:
> >
> >> No intended change in behavior. Just a refactor.
> >> ---
> >>  src/intel/vulkan/anv_device.c | 32 ++--
> >>  1 file changed, 6 insertions(+), 26 deletions(-)
> >>


> >> +   if (vk_outarray_is_incomple())
> >> +  return VK_INCOMPLETE;
> >>
> >
> > I still think I'd prefer a vk_outarray_status() helper and this would be
> > "return vk_outarray_status()".  But meh...

Ok. I'll change that to `return vk_outarray_status()`.

> With or without that suggestion,
> 
> Reviewed-by: Jason Ekstrand 

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

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


Re: [Mesa-dev] [PATCH 2/4] util/disk_cache: add helpers for creating/destroying disk cache put jobs

2017-03-13 Thread Timothy Arceri

On 13/03/17 22:55, Grazvydas Ignotas wrote:

On Mon, Mar 13, 2017 at 3:01 AM, Timothy Arceri  wrote:

---
 src/util/disk_cache.c | 48 
 1 file changed, 48 insertions(+)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index 3b1cffc..160774a 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -71,20 +71,40 @@ struct disk_cache {
/* Pointer to total size of all objects in cache (within index_mmap) */
uint64_t *size;

/* Pointer to stored keys, (within index_mmap). */
uint8_t *stored_keys;

/* Maximum size of all cached objects (in bytes). */
uint64_t max_size;
 };

+struct disk_cache_put_job {
+   struct util_queue_fence fence;
+
+   struct disk_cache *cache;
+
+   cache_key key;
+
+   /* Cache data to be compressed and written. */
+   const void *data;
+
+   /* Size of data to be compressed and written. */
+   size_t size;
+
+   /* Memory to be freed by util_queue_execute_func cleanup.
+*
+* Note: The memory is expected to have been created with ralloc.
+*/
+   void *mem;
+};
+
 /* Create a directory named 'path' if it does not already exist.
  *
  * Returns: 0 if path already exists as a directory or if created.
  * -1 in all other cases.
  */
 static int
 mkdir_if_needed(const char *path)
 {
struct stat sb;

@@ -728,20 +748,48 @@ deflate_and_write_to_disk(const void *in_data, size_t 
in_data_size, int dest,
} while (flush != Z_FINISH);

/* stream should be complete */
assert(ret == Z_STREAM_END);

/* clean up and return */
(void)deflateEnd();
return compressed_size;
 }

+static struct disk_cache_put_job *
+create_put_job(struct disk_cache *cache, const cache_key key,
+   const void *data, size_t size, void *mem)
+{
+   struct disk_cache_put_job *dc_job = (struct disk_cache_put_job *)
+  malloc(sizeof(struct disk_cache_put_job));
+
+   if (dc_job) {
+  dc_job->cache = cache;
+  memcpy(dc_job->key, key, sizeof(cache_key));
+  dc_job->data = data;
+  dc_job->size = size;
+  dc_job->mem = mem;
+   }
+
+   return dc_job;
+}
+
+static void
+destroy_put_job(void *job, int thread_index)


It looks like thread_index is unused by the series.



Right but that's the interface of u_queue, are you suggesting a change? 
I don't think it matters much.

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


Re: [Mesa-dev] [PATCH] [RFC] clover: flush event queue when sequencing new event

2017-03-13 Thread Francisco Jerez
Vedran Miletić  writes:

> OpenMM holds events created during runtime in the queue and destroys
> them at the end, which causes a stack overflow in nontrivial examples.

Did you manange to get a backtrace?

> This patch forces flushing of the event queue and destruction of
> events which are CL_COMPLETE.
>
> I am pretty sure this isn't the nicest solution and probably not
> performance optimal either. Should flushing be done elsewhere? If yes,
> where?
>

This introduces a full command queue flush for every CL command so I
don't think we can use it in production, what the right fix is depends
on what the exact reason is for the stack overflow.

> P.S.
> This patch also fixes cl/custom/r600-create-release-buffer-bug.c test
> in Piglit, but I haven't looked into why exactly that happens.
> ---
>  src/gallium/state_trackers/clover/core/queue.cpp | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/gallium/state_trackers/clover/core/queue.cpp 
> b/src/gallium/state_trackers/clover/core/queue.cpp
> index c91b97a..7503eea 100644
> --- a/src/gallium/state_trackers/clover/core/queue.cpp
> +++ b/src/gallium/state_trackers/clover/core/queue.cpp
> @@ -94,6 +94,8 @@ command_queue::profiling_enabled() const {
>  
>  void
>  command_queue::sequence(hard_event ) {
> +   flush();
> +
> std::lock_guard lock(queued_events_mutex);
> if (!queued_events.empty())
>queued_events.back()().chain(ev);
> -- 
> 2.9.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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


Re: [Mesa-dev] [PATCH 1/3] dri: Add an image creation with modifiers

2017-03-13 Thread Ben Widawsky

On 17-03-10 10:28:42, Emil Velikov wrote:

Hi Ben,

Mostly pointing out a few things that look strange, pardon if some
seem too pedantic.

On 10 March 2017 at 01:48, Ben Widawsky  wrote:


---
 include/GL/internal/dri_interface.h  | 27 ++-

Split the Infra from the i965 implementation ?



Sure. Doesn't matter to me.


 src/gallium/state_trackers/dri/dri2.c|  1 +

Not needed.



Yeah, whoops.


 src/mesa/drivers/dri/i965/intel_screen.c | 32 +++-

Patch should come as/after __DRI_IMAGE_ATTRIB_MODIFIER_* are honoured.
Or modifiers and modifiers count in general.



Assuming this also means split the infra from implementation, sure.


--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1413,6 +1413,7 @@ static __DRIimageExtension dri2ImageExtension = {
 .getCapabilities  = dri2_get_capabilities,
 .mapImage = dri2_map_image,
 .unmapImage   = dri2_unmap_image,
+.createImageWithModifiers = NULL,
 };


Not needed - drop ?




Gone.


diff --git a/src/mesa/drivers/dri/i965/intel_screen.c 
b/src/mesa/drivers/dri/i965/intel_screen.c
index 21786eb54a..3452572874 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -510,9 +510,11 @@ intel_destroy_image(__DRIimage *image)
 }

 static __DRIimage *
-intel_create_image(__DRIscreen *dri_screen,
+__intel_create_image(__DRIscreen *dri_screen,

Don't think there's (m)any functions that start with __ in 965.
Perhaps append "_common" ?




Sure.


int cpp;
unsigned long pitch;

+   /* Callers of this may specify a modifier, or a dri usage, but not both. The
+* newer modifier interface deprecates the older usage flags newer modifier
+* interface deprecates the older usage flags.
+*/
+   assert(!(use && count));
+

What would happen if we don't have either old (use) or new (modifiers) ?
Shouldn't this be XOR ?



Not having either is fine. It's like the previous case of supporting use flags
but passing in none, which is allowed.




@@ -840,6 +869,7 @@ static const __DRIimageExtension intelImageExtension = {

Afaict, nothing in this series bumps the version to 14.
So you either missed a patch or we have a bug somewhere ?



Well, it bumps the version in dri_interface.h. Formerly, before splitting things
up, this patch had the i965 version bumped too, but that's gone now. I'm happy
to reword this however you'd like.


-Emil

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


Re: [Mesa-dev] MESA and KOTOR

2017-03-13 Thread Jan Vesely
On Mon, 2017-03-13 at 11:40 +0200, Grazvydas Ignotas wrote:
> On Sat, Mar 11, 2017 at 1:51 PM, Federico Dossena  
> wrote:
> > This issue is not new: a guy named Miklós Máté, here in the Mesa mailing
> > list somehow managed to fix it in Mesa 11, but his patches do not seem to
> > work anymore
> > (https://lists.freedesktop.org/archives/mesa-dev/2016-February/106695.html).
> 
> He was using wine on Linux, I guess wine provides an implementation of
> that function. You could try running the game on Linux too.

runs mostly OK using wine here. Intel(skylake) driver suffers terrible
performance and displays artifacts in certain locations. nouveau(950m)
works nicely. llvmpipe+llvm3.7 also works, albeit the performance is
terrible.

Jan

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

-- 
Jan Vesely 

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


Re: [Mesa-dev] [PATCH 2/3] anv: Use vk_outarray in vkEnumeratePhysicalDevices

2017-03-13 Thread Jason Ekstrand
On Mon, Mar 13, 2017 at 2:32 PM, Jason Ekstrand 
wrote:

> On Mon, Mar 13, 2017 at 2:23 PM, Chad Versace 
> wrote:
>
>> No intended change in behavior. Just a refactor.
>> ---
>>  src/intel/vulkan/anv_device.c | 32 ++--
>>  1 file changed, 6 insertions(+), 26 deletions(-)
>>
>> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.
>> c
>> index f04e11e..35c5a4645ff 100644
>> --- a/src/intel/vulkan/anv_device.c
>> +++ b/src/intel/vulkan/anv_device.c
>> @@ -390,6 +390,7 @@ VkResult anv_EnumeratePhysicalDevices(
>>  VkPhysicalDevice*   pPhysicalDevices)
>>  {
>> ANV_FROM_HANDLE(anv_instance, instance, _instance);
>> +   VK_OUTARRAY_MAKE(out, pPhysicalDevices, pPhysicalDeviceCount);
>> VkResult result;
>>
>> if (instance->physicalDeviceCount < 0) {
>> @@ -411,34 +412,13 @@ VkResult anv_EnumeratePhysicalDevices(
>>}
>> }
>>
>> -   /* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is
>> NULL;
>> -* otherwise it's an inout parameter.
>> -*
>> -* The Vulkan spec (git aaed022) says:
>> -*
>> -*pPhysicalDeviceCount is a pointer to an unsigned integer
>> variable
>> -*that is initialized with the number of devices the application
>> is
>> -*prepared to receive handles to. pname:pPhysicalDevices is
>> pointer to
>> -*an array of at least this many VkPhysicalDevice handles [...].
>> -*
>> -*Upon success, if pPhysicalDevices is NULL,
>> vkEnumeratePhysicalDevices
>> -*overwrites the contents of the variable pointed to by
>> -*pPhysicalDeviceCount with the number of physical devices in in
>> the
>> -*instance; otherwise, vkEnumeratePhysicalDevices overwrites
>> -*pPhysicalDeviceCount with the number of physical handles
>> written to
>> -*pPhysicalDevices.
>> -*/
>> -   if (!pPhysicalDevices) {
>> -  *pPhysicalDeviceCount = instance->physicalDeviceCount;
>> -   } else if (*pPhysicalDeviceCount >= 1) {
>> -  pPhysicalDevices[0] = anv_physical_device_to_handle(
>> >physicalDevice);
>> -  *pPhysicalDeviceCount = 1;
>> -   } else if (*pPhysicalDeviceCount < instance->physicalDeviceCount) {
>> -  return VK_INCOMPLETE;
>> -   } else {
>> -  *pPhysicalDeviceCount = 0;
>> +   vk_outarray_append(, i) {
>> +  *i = anv_physical_device_to_handle(>physicalDevice);
>> }
>>
>> +   if (vk_outarray_is_incomple())
>> +  return VK_INCOMPLETE;
>>
>
> I still think I'd prefer a vk_outarray_status() helper and this would be
> "return vk_outarray_status()".  But meh...
>

With or without that suggestion,

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


Re: [Mesa-dev] [PATCH 2/3] anv: Use vk_outarray in vkEnumeratePhysicalDevices

2017-03-13 Thread Jason Ekstrand
On Mon, Mar 13, 2017 at 2:23 PM, Chad Versace 
wrote:

> No intended change in behavior. Just a refactor.
> ---
>  src/intel/vulkan/anv_device.c | 32 ++--
>  1 file changed, 6 insertions(+), 26 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index f04e11e..35c5a4645ff 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -390,6 +390,7 @@ VkResult anv_EnumeratePhysicalDevices(
>  VkPhysicalDevice*   pPhysicalDevices)
>  {
> ANV_FROM_HANDLE(anv_instance, instance, _instance);
> +   VK_OUTARRAY_MAKE(out, pPhysicalDevices, pPhysicalDeviceCount);
> VkResult result;
>
> if (instance->physicalDeviceCount < 0) {
> @@ -411,34 +412,13 @@ VkResult anv_EnumeratePhysicalDevices(
>}
> }
>
> -   /* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is
> NULL;
> -* otherwise it's an inout parameter.
> -*
> -* The Vulkan spec (git aaed022) says:
> -*
> -*pPhysicalDeviceCount is a pointer to an unsigned integer variable
> -*that is initialized with the number of devices the application is
> -*prepared to receive handles to. pname:pPhysicalDevices is
> pointer to
> -*an array of at least this many VkPhysicalDevice handles [...].
> -*
> -*Upon success, if pPhysicalDevices is NULL,
> vkEnumeratePhysicalDevices
> -*overwrites the contents of the variable pointed to by
> -*pPhysicalDeviceCount with the number of physical devices in in
> the
> -*instance; otherwise, vkEnumeratePhysicalDevices overwrites
> -*pPhysicalDeviceCount with the number of physical handles written
> to
> -*pPhysicalDevices.
> -*/
> -   if (!pPhysicalDevices) {
> -  *pPhysicalDeviceCount = instance->physicalDeviceCount;
> -   } else if (*pPhysicalDeviceCount >= 1) {
> -  pPhysicalDevices[0] = anv_physical_device_to_handle(
> >physicalDevice);
> -  *pPhysicalDeviceCount = 1;
> -   } else if (*pPhysicalDeviceCount < instance->physicalDeviceCount) {
> -  return VK_INCOMPLETE;
> -   } else {
> -  *pPhysicalDeviceCount = 0;
> +   vk_outarray_append(, i) {
> +  *i = anv_physical_device_to_handle(>physicalDevice);
> }
>
> +   if (vk_outarray_is_incomple())
> +  return VK_INCOMPLETE;
>

I still think I'd prefer a vk_outarray_status() helper and this would be
"return vk_outarray_status()".  But meh...


> +
> return VK_SUCCESS;
>  }
>
> --
> 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


Re: [Mesa-dev] [PATCH 1/3] dri: Add an image creation with modifiers

2017-03-13 Thread Ben Widawsky

On 17-03-09 18:38:15, Jason Ekstrand wrote:

On Thu, Mar 9, 2017 at 5:48 PM, Ben Widawsky  wrote:


Modifiers will be obtains or guessed by the client and passed in during



"obtained"




Got it.


image creation/import.

This requires bumping the DRIimage version.

As of this patch, the modifiers aren't plumbed all the way down, this
patch simply makes sure the interface level stuff is correct.

v2: Don't allow usage + modifiers

v3: Make NAND actually NAND. Bug introduced in v2. (Jason)

Cc: Kristian Høgsberg 
Cc: Jason Ekstrand 
Signed-off-by: Ben Widawsky 
Reviewed-by: Eric Engestrom  (v1)
Acked-by: Daniel Stone 
---
 include/GL/internal/dri_interface.h  | 27 ++-
 src/gallium/state_trackers/dri/dri2.c|  1 +
 src/mesa/drivers/dri/i965/intel_screen.c | 32
+++-
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 598d111f33..53fac6fc3c 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1136,7 +1136,7 @@ struct __DRIdri2ExtensionRec {
  * extensions.
  */
 #define __DRI_IMAGE "DRI_IMAGE"
-#define __DRI_IMAGE_VERSION 13
+#define __DRI_IMAGE_VERSION 14

 /**
  * These formats correspond to the similarly named MESA_FORMAT_*
@@ -1257,6 +1257,8 @@ struct __DRIdri2ExtensionRec {
 #define __DRI_IMAGE_ATTRIB_NUM_PLANES   0x2009 /* available in versions
11 */

 #define __DRI_IMAGE_ATTRIB_OFFSET 0x200A /* available in versions 13 */
+#define __DRI_IMAGE_ATTRIB_MODIFIER_LOWER 0x200B /* available in
versions 14 */
+#define __DRI_IMAGE_ATTRIB_MODIFIER_UPPER 0x200C /* available in
versions 14 */

 enum __DRIYUVColorSpace {
__DRI_YUV_COLOR_SPACE_UNDEFINED = 0,
@@ -1468,6 +1470,29 @@ struct __DRIimageExtensionRec {
 */
void (*unmapImage)(__DRIcontext *context, __DRIimage *image, void
*data);

+
+   /**
+* Creates an image with implementation's favorite modifiers.
+*
+* This acts like createImage except there is a list of modifiers
passed in
+* which the implementation may selectively use to create the
DRIimage. The
+* result should be the implementation selects one modifier (perhaps
it would
+* hold on to a few and later pick).
+*
+* The created image should be destroyed with destroyImage().
+*
+* Returns the new DRIimage. The chosen modifier can be obtained later
on
+* and passed back to things like the kernel's AddFB2 interface.
+*
+* \sa __DRIimageRec::createImage
+*
+* \since 14
+*/
+   __DRIimage *(*createImageWithModifiers)(__DRIscreen *screen,
+   int width, int height, int
format,
+   const uint64_t *modifiers,
+   const unsigned int
modifier_count,
+   void *loaderPrivate);
 };


diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index b50e096443..12e466c6f1 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -1413,6 +1413,7 @@ static __DRIimageExtension dri2ImageExtension = {
 .getCapabilities  = dri2_get_capabilities,
 .mapImage = dri2_map_image,
 .unmapImage   = dri2_unmap_image,
+.createImageWithModifiers = NULL,
 };


diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 21786eb54a..3452572874 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -510,9 +510,11 @@ intel_destroy_image(__DRIimage *image)
 }

 static __DRIimage *
-intel_create_image(__DRIscreen *dri_screen,
+__intel_create_image(__DRIscreen *dri_screen,
   int width, int height, int format,
   unsigned int use,
+   const uint64_t *modifiers,
+   unsigned count,
   void *loaderPrivate)
 {
__DRIimage *image;
@@ -521,6 +523,12 @@ intel_create_image(__DRIscreen *dri_screen,
int cpp;
unsigned long pitch;

+   /* Callers of this may specify a modifier, or a dri usage, but not
both. The
+* newer modifier interface deprecates the older usage flags newer
modifier
+* interface deprecates the older usage flags.
+*/
+   assert(!(use && count));
+
tiling = I915_TILING_X;
if (use & __DRI_IMAGE_USE_CURSOR) {
   if (width != 64 || height != 64)
@@ -550,6 +558,27 @@ intel_create_image(__DRIscreen *dri_screen,
return image;
 }

+static __DRIimage *
+intel_create_image(__DRIscreen *dri_screen,
+  int width, int height, int format,
+  unsigned int use,
+  void *loaderPrivate)
+{
+   return 

[Mesa-dev] [PATCH 0/3] anv: Add an vk_outarray_append() macro (v2)

2017-03-13 Thread Chad Versace
The macro vk_outarray_append() deduplicates a lot of nit-picky
boilerplate code. It appends to a Vulkan output array, handling null
pointers and overflow correctly. (A Vulkan output array, as I'm using
the term, is one that follows the convention of the parameters to
vkGetPhysicalDeviceQueueFamilyProperties()).

This series prepares for VK_MESAX_external_image_dma_buf, which
introduces three new output arrays for DRM format modifiers. I separated
these prep patches from the VK_MESAX_external_image_dma_buf patches to
make review less burdensome, and to begin upstreaming pathes asap.

This patch series lives at:
git://git.kiwitree.net/~chadv/mesa
refs/tags/chadv/review/anv-outarray-v02
gitweb: 
http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=chadv/review/anv-outarray-v02

v2:
  - Rename anv_outarray -> vk_outarray and move it to
util/vk_util.h.  For Jason.

Chad Versace (3):
  util/vulkan: Add vk_outarray
  anv: Use vk_outarray in vkEnumeratePhysicalDevices
  anv: Use vk_outarray in vkGetPhysicalDeviceQueueFamilyProperties

 src/intel/vulkan/anv_device.c | 105 ---
 src/util/vk_util.h| 140 ++
 2 files changed, 164 insertions(+), 81 deletions(-)

-- 
2.12.0

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


[Mesa-dev] [PATCH 2/3] anv: Use vk_outarray in vkEnumeratePhysicalDevices

2017-03-13 Thread Chad Versace
No intended change in behavior. Just a refactor.
---
 src/intel/vulkan/anv_device.c | 32 ++--
 1 file changed, 6 insertions(+), 26 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index f04e11e..35c5a4645ff 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -390,6 +390,7 @@ VkResult anv_EnumeratePhysicalDevices(
 VkPhysicalDevice*   pPhysicalDevices)
 {
ANV_FROM_HANDLE(anv_instance, instance, _instance);
+   VK_OUTARRAY_MAKE(out, pPhysicalDevices, pPhysicalDeviceCount);
VkResult result;
 
if (instance->physicalDeviceCount < 0) {
@@ -411,34 +412,13 @@ VkResult anv_EnumeratePhysicalDevices(
   }
}
 
-   /* pPhysicalDeviceCount is an out parameter if pPhysicalDevices is NULL;
-* otherwise it's an inout parameter.
-*
-* The Vulkan spec (git aaed022) says:
-*
-*pPhysicalDeviceCount is a pointer to an unsigned integer variable
-*that is initialized with the number of devices the application is
-*prepared to receive handles to. pname:pPhysicalDevices is pointer to
-*an array of at least this many VkPhysicalDevice handles [...].
-*
-*Upon success, if pPhysicalDevices is NULL, vkEnumeratePhysicalDevices
-*overwrites the contents of the variable pointed to by
-*pPhysicalDeviceCount with the number of physical devices in in the
-*instance; otherwise, vkEnumeratePhysicalDevices overwrites
-*pPhysicalDeviceCount with the number of physical handles written to
-*pPhysicalDevices.
-*/
-   if (!pPhysicalDevices) {
-  *pPhysicalDeviceCount = instance->physicalDeviceCount;
-   } else if (*pPhysicalDeviceCount >= 1) {
-  pPhysicalDevices[0] = 
anv_physical_device_to_handle(>physicalDevice);
-  *pPhysicalDeviceCount = 1;
-   } else if (*pPhysicalDeviceCount < instance->physicalDeviceCount) {
-  return VK_INCOMPLETE;
-   } else {
-  *pPhysicalDeviceCount = 0;
+   vk_outarray_append(, i) {
+  *i = anv_physical_device_to_handle(>physicalDevice);
}
 
+   if (vk_outarray_is_incomple())
+  return VK_INCOMPLETE;
+
return VK_SUCCESS;
 }
 
-- 
2.12.0

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


[Mesa-dev] [PATCH 1/3] util/vulkan: Add vk_outarray

2017-03-13 Thread Chad Versace
This is a wrapper for a Vulkan output array. A Vulkan output array is
one that follows the convention of the parameters to
vkGetPhysicalDeviceQueueFamilyProperties().
---
 src/util/vk_util.h | 140 +
 1 file changed, 140 insertions(+)

diff --git a/src/util/vk_util.h b/src/util/vk_util.h
index e0b5d0b22c0..b79e61a386a 100644
--- a/src/util/vk_util.h
+++ b/src/util/vk_util.h
@@ -40,4 +40,144 @@ struct vk_struct_common {
for (const struct vk_struct_common *__iter = (const struct vk_struct_common 
*)(__start); \
 __iter; __iter = __iter->pNext)
 
+/**
+ * A wrapper for a Vulkan output array. A Vulkan output array is one that
+ * follows the convention of the parameters to
+ * vkGetPhysicalDeviceQueueFamilyProperties().
+ *
+ * Example Usage:
+ *
+ *VkResult
+ *vkGetPhysicalDeviceQueueFamilyProperties(
+ *   VkPhysicalDevice   physicalDevice,
+ *   uint32_t*  pQueueFamilyPropertyCount,
+ *   VkQueueFamilyProperties*   pQueueFamilyProperties)
+ *{
+ *   VK_OUTARRAY_MAKE(props, pQueueFamilyProperties,
+ * pQueueFamilyPropertyCount);
+ *
+ *   vk_outarray_append(, p) {
+ *  p->queueFlags = ...;
+ *  p->queueCount = ...;
+ *   }
+ *
+ *   vk_outarray_append(, p) {
+ *  p->queueFlags = ...;
+ *  p->queueCount = ...;
+ *   }
+ *
+ *   if (vk_outarray_is_incomple())
+ *  return VK_INCOMPLETE;
+ *
+ *   return VK_SUCCESS;
+ *}
+ */
+struct __vk_outarray {
+   /** May be null. */
+   void *data;
+
+   /**
+* Capacity, in number of elements. Capacity is unlimited (UINT32_MAX) if
+* data is null.
+*/
+   uint32_t cap;
+
+   /**
+* Count of elements successfully written to the array. Every write is
+* considered successful if data is null.
+*/
+   uint32_t *filled_len;
+
+   /**
+* Count of elements that would have been written to the array if its
+* capacity were sufficient. Vulkan functions often return VK_INCOMPLETE
+* when `*filled_len < wanted_len`.
+*/
+   uint32_t wanted_len;
+};
+
+static inline void
+__vk_outarray_init(struct __vk_outarray *a,
+   void *data, uint32_t *restrict len)
+{
+   a->data = data;
+   a->cap = *len;
+   a->filled_len = len;
+   *a->filled_len = 0;
+   a->wanted_len = 0;
+
+   if (a->data == NULL)
+  a->cap = UINT32_MAX;
+}
+
+static inline bool
+__vk_outarray_is_incomplete(const struct __vk_outarray *a)
+{
+   return *a->filled_len < a->wanted_len;
+}
+
+static inline void *
+__vk_outarray_next(struct __vk_outarray *a, size_t elem_size)
+{
+   void *p = NULL;
+
+   a->wanted_len += 1;
+
+   if (*a->filled_len >= a->cap)
+  return NULL;
+
+   if (a->data != NULL)
+  p = a->data + (*a->filled_len) * elem_size;
+
+   *a->filled_len += 1;
+
+   return p;
+}
+
+#define vk_outarray(elem_t) \
+   struct { \
+  struct __vk_outarray base; \
+  elem_t meta[]; \
+   }
+
+#define vk_outarray_typeof_elem(a) __typeof__((a)->meta[0])
+#define vk_outarray_sizeof_elem(a) sizeof((a)->meta[0])
+
+#define vk_outarray_init(a, data, len) \
+   __vk_outarray_init(&(a)->base, (data), (len))
+
+#define VK_OUTARRAY_MAKE(name, data, len) \
+   vk_outarray(__typeof__((data)[0])) name; \
+   vk_outarray_init(, (data), (len))
+
+#define vk_outarray_is_incomple(a) \
+   __vk_outarray_is_incomplete(&(a)->base)
+
+#define vk_outarray_next(a) \
+   ((vk_outarray_typeof_elem(a) *) \
+  __vk_outarray_next(&(a)->base, vk_outarray_sizeof_elem(a)))
+
+/**
+ * Append to a Vulkan output array.
+ *
+ * This is a block-based macro. For example:
+ *
+ *vk_outarray_append(, elem) {
+ *   elem->foo = ...;
+ *   elem->bar = ...;
+ *}
+ *
+ * The array `a` has type `vk_outarray(elem_t) *`. It is usually declared with
+ * VK_OUTARRAY_MAKE(). The variable `elem` is block-scoped and has type
+ * `elem_t *`.
+ *
+ * The macro unconditionally increments the array's `wanted_len`. If the array
+ * is not full, then the macro also increment its `filled_len` and then
+ * executes the block. When the block is executed, `elem` is non-null and
+ * points to the newly appended element.
+ */
+#define vk_outarray_append(a, elem) \
+   for (vk_outarray_typeof_elem(a) *elem = vk_outarray_next(a); \
+elem != NULL; elem = NULL)
+
 #endif /* VK_UTIL_H */
-- 
2.12.0

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


[Mesa-dev] [PATCH 3/3] anv: Use vk_outarray in vkGetPhysicalDeviceQueueFamilyProperties

2017-03-13 Thread Chad Versace
No intended change in behavior. Just a refactor.
---
 src/intel/vulkan/anv_device.c | 73 +++
 1 file changed, 18 insertions(+), 55 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 35c5a4645ff..21130feac82 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -663,43 +663,27 @@ void anv_GetPhysicalDeviceProperties2KHR(
}
 }
 
-static void
-anv_get_queue_family_properties(struct anv_physical_device *phys_dev,
-VkQueueFamilyProperties *props)
-{
-   *props = (VkQueueFamilyProperties) {
-  .queueFlags = VK_QUEUE_GRAPHICS_BIT |
-VK_QUEUE_COMPUTE_BIT |
-VK_QUEUE_TRANSFER_BIT,
-  .queueCount = 1,
-  .timestampValidBits = 36, /* XXX: Real value here */
-  .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
-   };
-}
+/* We support exactly one queue family. */
+static const VkQueueFamilyProperties
+anv_queue_family_properties = {
+   .queueFlags = VK_QUEUE_GRAPHICS_BIT |
+ VK_QUEUE_COMPUTE_BIT |
+ VK_QUEUE_TRANSFER_BIT,
+   .queueCount = 1,
+   .timestampValidBits = 36, /* XXX: Real value here */
+   .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
+};
 
 void anv_GetPhysicalDeviceQueueFamilyProperties(
 VkPhysicalDevicephysicalDevice,
 uint32_t*   pCount,
 VkQueueFamilyProperties*pQueueFamilyProperties)
 {
-   ANV_FROM_HANDLE(anv_physical_device, phys_dev, physicalDevice);
+   VK_OUTARRAY_MAKE(out, pQueueFamilyProperties, pCount);
 
-   if (pQueueFamilyProperties == NULL) {
-  *pCount = 1;
-  return;
+   vk_outarray_append(, p) {
+  *p = anv_queue_family_properties;
}
-
-   /* The spec implicitly allows the incoming count to be 0. From the Vulkan
-* 1.0.38 spec, Section 4.1 Physical Devices:
-*
-* If the value referenced by pQueueFamilyPropertyCount is not 0 [then
-* do stuff].
-*/
-   if (*pCount == 0)
-  return;
-
-   *pCount = 1;
-   anv_get_queue_family_properties(phys_dev, pQueueFamilyProperties);
 }
 
 void anv_GetPhysicalDeviceQueueFamilyProperties2KHR(
@@ -708,34 +692,13 @@ void anv_GetPhysicalDeviceQueueFamilyProperties2KHR(
 VkQueueFamilyProperties2KHR*pQueueFamilyProperties)
 {
 
-   ANV_FROM_HANDLE(anv_physical_device, phys_dev, physicalDevice);
-
-   if (pQueueFamilyProperties == NULL) {
-  *pQueueFamilyPropertyCount = 1;
-  return;
-   }
+   VK_OUTARRAY_MAKE(out, pQueueFamilyProperties, pQueueFamilyPropertyCount);
 
-   /* The spec implicitly allows the incoming count to be 0. From the Vulkan
-* 1.0.38 spec, Section 4.1 Physical Devices:
-*
-* If the value referenced by pQueueFamilyPropertyCount is not 0 [then
-* do stuff].
-*/
-   if (*pQueueFamilyPropertyCount == 0)
-  return;
+   vk_outarray_append(, p) {
+  p->queueFamilyProperties = anv_queue_family_properties;
 
-   /* We support exactly one queue family. So need to traverse only the first
-* array element's pNext chain.
-*/
-   *pQueueFamilyPropertyCount = 1;
-   anv_get_queue_family_properties(phys_dev,
- >queueFamilyProperties);
-
-   vk_foreach_struct(ext, pQueueFamilyProperties->pNext) {
-  switch (ext->sType) {
-  default:
- anv_debug_ignored_stype(ext->sType);
- break;
+  vk_foreach_struct(s, p->pNext) {
+ anv_debug_ignored_stype(s->sType);
   }
}
 }
-- 
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/3] anv: Add anv_outarray

2017-03-13 Thread Chad Versace
On Wed 08 Mar 2017, Chad Versace wrote:
> On Mon 06 Mar 2017, Jason Ekstrand wrote:
> > On Mon, Mar 6, 2017 at 10:25 AM, Chad Versace 
> > wrote:
> > 
> > > anv_outarray is a wrapper for a Vulkan output array. A Vulkan output
> > > array is one that follows the convention of the parameters to
> > > vkGetPhysicalDeviceQueueFamilyProperties().
> > >
> > > In the upcoming dma_buf extensions, anv_outarray will simplify the code
> > > for querying the DRM format modifiers.
> > > ---
> > >  src/intel/vulkan/anv_private.h | 140 ++
> > > +++
> > >  1 file changed, 140 insertions(+)


> > > +static inline bool
> > > +__anv_outarray_is_incomplete(const struct __anv_outarray *a)
> > > +{
> > > +   return *a->filled_len < a->wanted_len;
> > >
> > 
> > We could implement this as
> > 
> > return a->data && *a->filled_len < a->cap

No. VK_INCOMPLETE means "overflow", not "underflow". Comparint to
capacity can't tell you about overflow.

With that realization, I kept the filled_len and wanted_len fields
unchanged in v2.

> > Or, better yet, we could add a "VkResult status" to the outarray struct and
> > set that VK_INCOMPLETE in __anv_outarray_next.  Then the status check is
> > just "return out.status".  How does that sound?
> 
> When I rewrite the patch to remove 'wanted_len', I'll play around with
> that, and see what results in the cleanest code.
> 
> > 
> > Also, this looks like a really good candidate for common Vulkan code.
> 
> Agreed. I'll resend this as a patch to vk_util.h.
> 
> > Thanks for doing this by the way!  I've been wanting someone to figure out
> > how to make output arrays less painful and this seems like a very good way.
> 
> Thanks :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] radv: setup llvm target data layout

2017-03-13 Thread Dave Airlie
From: Dave Airlie 

Ported from radeonsi, pointed out by Tom.

"This prevents LLVM from using sext instructions for local memory
offsets and allows the backend to fold immediate offsets into the
instruction. This also prevents some incorrect code generation for
ptrtoint and inttoptr instructions."

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 47091a2..417b34e 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4911,6 +4911,13 @@ LLVMModuleRef 
ac_translate_nir_to_llvm(LLVMTargetMachineRef tm,
memset(shader_info, 0, sizeof(*shader_info));
 
LLVMSetTarget(ctx.module, options->supports_spill ? 
"amdgcn-mesa-mesa3d" : "amdgcn--");
+
+   LLVMTargetDataRef data_layout = LLVMCreateTargetDataLayout(tm);
+   char *data_layout_str = LLVMCopyStringRepOfTargetData(data_layout);
+   LLVMSetDataLayout(ctx.module, data_layout_str);
+   LLVMDisposeTargetData(data_layout);
+   LLVMDisposeMessage(data_layout_str);
+
setup_types();
 
ctx.builder = LLVMCreateBuilderInContext(ctx.context);
-- 
2.9.3

___
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

2017-03-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 84663, which changed state.

Bug 84663 Summary: high cpu usage, poor performance in Borderlands 2 with 
radeonsi, PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=84663

   What|Removed |Added

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

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


[Mesa-dev] [PATCH] [RFC] clover: flush event queue when sequencing new event

2017-03-13 Thread Vedran Miletić
OpenMM holds events created during runtime in the queue and destroys
them at the end, which causes a stack overflow in nontrivial examples.
This patch forces flushing of the event queue and destruction of
events which are CL_COMPLETE.

I am pretty sure this isn't the nicest solution and probably not
performance optimal either. Should flushing be done elsewhere? If yes,
where?

P.S.
This patch also fixes cl/custom/r600-create-release-buffer-bug.c test
in Piglit, but I haven't looked into why exactly that happens.
---
 src/gallium/state_trackers/clover/core/queue.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/gallium/state_trackers/clover/core/queue.cpp 
b/src/gallium/state_trackers/clover/core/queue.cpp
index c91b97a..7503eea 100644
--- a/src/gallium/state_trackers/clover/core/queue.cpp
+++ b/src/gallium/state_trackers/clover/core/queue.cpp
@@ -94,6 +94,8 @@ command_queue::profiling_enabled() const {
 
 void
 command_queue::sequence(hard_event ) {
+   flush();
+
std::lock_guard lock(queued_events_mutex);
if (!queued_events.empty())
   queued_events.back()().chain(ev);
-- 
2.9.3

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


Re: [Mesa-dev] [PATCH 0/3] GBM modifier plumbing

2017-03-13 Thread Daniel Stone
Hi,

On Mon, 13 Mar 2017 at 7:08 pm, Jason Ekstrand  wrote:

> On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen <
> k...@bitplanet.net> wrote:
>
> Daniel Stone  writes:
>
> > I guess it depends on how much asymmetry there is between texture and
> > render formats ... if there isn't much, then we could focus on landing
> > Varad's work and use that as a jumping-off point. I was under the
> > impression that there was a pretty big difference for some hardware,
> > though I guess the GBM implementation would still rank by optimality
> > when allocating ...
>
> Right, but if it's more complicated than what
> EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to
> that logic into gbm?
>
>
> The GBM API I was thinking of was basically a GBM version of that.  The
> primary addition to the above extension being some set of usage flags.
> There shouldn't be a huge asymmetry between texture and render.  What
> concerns me more is if you tie some other API into EGL that does media or
> something (OpenMAX?) you may run into issues where something works for
> render but not for media decode.  If we don't care about anything other
> than 3D tying into EGL, then the above API should be ok.
>
OK, great. Let's just go with that then; I think any more complicated
multi-device usecases really fall under the allocator domain, and I'd
rather not reinvent that under GBM.

At the moment, the only users we care about are allocating directly for
scanout (so can go through GBM + GetPlane2), or solely for GPU, where EGL
modifiers query + GBM allocation is fine.

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


Re: [Mesa-dev] [PATCH kmscube] drm-common.h: forward-declare needed structs

2017-03-13 Thread Emil Velikov
On 13 March 2017 at 17:14, Eric Engestrom  wrote:
> drm-common.h:63:49: warning: ‘struct egl’ declared inside parameter list will 
> not be
> visible outside of this definition or declaration
>   int (*run)(const struct gbm *gbm, const struct egl *egl);
>  ^~~
> drm-common.h:63:26: warning: ‘struct gbm’ declared inside parameter list will 
> not be
> visible outside of this definition or declaration
>   int (*run)(const struct gbm *gbm, const struct egl *egl);
>   ^~~
>
Was going to say "how ?" only to notice that WARN_CFLAGS is unused.
Might as well cut it down to -Wall -Wextra and make sure it's used ?

> Signed-off-by: Eric Engestrom 
Reviewed-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH] anv/blorp: Only set a clear color for resolves if fast-cleared

2017-03-13 Thread Jason Ekstrand
On Mon, Mar 13, 2017 at 11:19 AM, Emil Velikov 
wrote:

> On 5 March 2017 at 16:36, Eduardo Lima Mitev  wrote:
> > Reviewed-by: Eduardo Lima Mitev 
> >
> > On 03/04/2017 01:56 AM, Jason Ekstrand wrote:
> >> Cc: "17.0" 
> >> ---
> >>  src/intel/vulkan/anv_blorp.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> Is there anything wrong with the patch or it simply fell through the
> cracks ?
>

There was a small issue but both this patch and the fix landed this
morning.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/3] GBM modifier plumbing

2017-03-13 Thread Jason Ekstrand
On Mon, Mar 13, 2017 at 11:53 AM, Kristian H. Kristensen 
wrote:

> Daniel Stone  writes:
>
> > Hey Kristian,
> >
> > On 13 March 2017 at 17:31, Kristian H. Kristensen 
> wrote:
> >> Jason Ekstrand  writes:
> >>> I was talking to Daniel today and I think we also need another some
> sort of
> >>> GL or GBM api that gives you the modifiers supported for
> >>> rendering/texturing.  One option would be a gbm_get_modifiers_for_use()
> >>> entrypoint that takes a usage and gives you a set of modifiers that's
> >>> guaranteed to work for that usage.  For scanout, it would return
> LINEAR, X,
> >>> and Y on SKL+ and LINEAR and X on BDW-; it wouldn't return CCS because
> that
> >>> only works on a limited number of planes.  I say this now because we
> may
> >>> want to do that with the same DRI version bump as the rest of it.
> >>
> >> Are you aware of
> >>
> >> https://www.khronos.org/registry/EGL/extensions/EXT/
> EGL_EXT_image_dma_buf_import_modifiers.txt
> >>
> >> If you talked to Daniel, he probably brought it up - what's missing?
>

Hey, Look!  An API!  That appears to mostly do what we want.


> > I guess it depends on how much asymmetry there is between texture and
> > render formats ... if there isn't much, then we could focus on landing
> > Varad's work and use that as a jumping-off point. I was under the
> > impression that there was a pretty big difference for some hardware,
> > though I guess the GBM implementation would still rank by optimality
> > when allocating ...
>
> Right, but if it's more complicated than what
> EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to
> that logic into gbm?
>

The GBM API I was thinking of was basically a GBM version of that.  The
primary addition to the above extension being some set of usage flags.
There shouldn't be a huge asymmetry between texture and render.  What
concerns me more is if you tie some other API into EGL that does media or
something (OpenMAX?) you may run into issues where something works for
render but not for media decode.  If we don't care about anything other
than 3D tying into EGL, then the above API should be ok.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/3] GBM modifier plumbing

2017-03-13 Thread Kristian H. Kristensen
Daniel Stone  writes:

> Hey Kristian,
>
> On 13 March 2017 at 17:31, Kristian H. Kristensen  wrote:
>> Jason Ekstrand  writes:
>>> I was talking to Daniel today and I think we also need another some sort of
>>> GL or GBM api that gives you the modifiers supported for
>>> rendering/texturing.  One option would be a gbm_get_modifiers_for_use()
>>> entrypoint that takes a usage and gives you a set of modifiers that's
>>> guaranteed to work for that usage.  For scanout, it would return LINEAR, X,
>>> and Y on SKL+ and LINEAR and X on BDW-; it wouldn't return CCS because that
>>> only works on a limited number of planes.  I say this now because we may
>>> want to do that with the same DRI version bump as the rest of it.
>>
>> Are you aware of
>>
>> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
>>
>> If you talked to Daniel, he probably brought it up - what's missing?
>
> I guess it depends on how much asymmetry there is between texture and
> render formats ... if there isn't much, then we could focus on landing
> Varad's work and use that as a jumping-off point. I was under the
> impression that there was a pretty big difference for some hardware,
> though I guess the GBM implementation would still rank by optimality
> when allocating ...

Right, but if it's more complicated than what
EGL_EXT_image_dma_buf_import_modifiers exposes, do really we want to
that logic into gbm?

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


Re: [Mesa-dev] [PATCH] anv/blorp: Only set a clear color for resolves if fast-cleared

2017-03-13 Thread Emil Velikov
On 5 March 2017 at 16:36, Eduardo Lima Mitev  wrote:
> Reviewed-by: Eduardo Lima Mitev 
>
> On 03/04/2017 01:56 AM, Jason Ekstrand wrote:
>> Cc: "17.0" 
>> ---
>>  src/intel/vulkan/anv_blorp.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
Is there anything wrong with the patch or it simply fell through the cracks ?

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


Re: [Mesa-dev] [PATCH v3 4/6] i965/fs: Re-arrange conversion operations

2017-03-13 Thread Pohjolainen, Topi
On Mon, Mar 13, 2017 at 09:18:13AM -0700, Jason Ekstrand wrote:
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 67 
> ++-
>  1 file changed, 31 insertions(+), 36 deletions(-)

Reviewed-by: Topi Pohjolainen 

> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index b392895..ef569b5 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -643,8 +643,6 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
> switch (instr->op) {
> case nir_op_i2f:
> case nir_op_u2f:
> -   case nir_op_i642d:
> -   case nir_op_u642d:
>if (optimize_extract_to_float(instr, result))
>   return;
>inst = bld.MOV(result, op[0]);
> @@ -678,13 +676,14 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
>   break;
>}
>/* fallthrough */
> +   case nir_op_i642d:
> +   case nir_op_u642d:
> case nir_op_f2i64:
> case nir_op_f2u64:
> case nir_op_i2i64:
> case nir_op_i2u64:
> case nir_op_u2i64:
> case nir_op_u2u64:
> -   case nir_op_b2i64:
> case nir_op_d2f:
> case nir_op_d2i:
> case nir_op_d2u:
> @@ -694,17 +693,10 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
> case nir_op_i2i32:
> case nir_op_u2u32:
> case nir_op_i2u32:
> -  if (instr->op == nir_op_b2i64) {
> - bld.MOV(result, negate(op[0]));
> -  } else {
> - inst = bld.MOV(result, op[0]);
> - inst->saturate = instr->dest.saturate;
> -  }
> -  break;
> -
> case nir_op_f2i:
> case nir_op_f2u:
> -  bld.MOV(result, op[0]);
> +  inst = bld.MOV(result, op[0]);
> +  inst->saturate = instr->dest.saturate;
>break;
>  
> case nir_op_fsign: {
> @@ -1085,40 +1077,43 @@ fs_visitor::nir_emit_alu(const fs_builder , 
> nir_alu_instr *instr)
>inst->saturate = instr->dest.saturate;
>break;
>  
> +   case nir_op_b2i64:
> case nir_op_b2i:
> case nir_op_b2f:
>bld.MOV(result, negate(op[0]));
>break;
>  
> +   case nir_op_i2b:
> case nir_op_f2b:
> -  bld.CMP(result, op[0], brw_imm_f(0.0f), BRW_CONDITIONAL_NZ);
> -  break;
> -
> case nir_op_i642b:
> -   case nir_op_d2b: {
> -  /* two-argument instructions can't take 64-bit immediates */
> -  fs_reg zero;
> -  fs_reg tmp;
> +   case nir_op_d2b:
> +  if (nir_src_bit_size(instr->src[0].src) == 64) {
> + /* two-argument instructions can't take 64-bit immediates */
> + fs_reg zero;
> + fs_reg tmp;
> +
> + if (instr->op == nir_op_d2b) {
> +zero = vgrf(glsl_type::double_type);
> +tmp = vgrf(glsl_type::double_type);
> + } else {
> +zero = vgrf(glsl_type::int64_t_type);
> +tmp = vgrf(glsl_type::int64_t_type);
> + }
>  
> -  if (instr->op == nir_op_d2b) {
> - zero = vgrf(glsl_type::double_type);
> - tmp = vgrf(glsl_type::double_type);
> + bld.MOV(zero, setup_imm_df(bld, 0.0));
> + /* A SIMD16 execution needs to be split in two instructions, so use
> +  * a vgrf instead of the flag register as dst so instruction 
> splitting
> +  * works
> +  */
> + bld.CMP(tmp, op[0], zero, BRW_CONDITIONAL_NZ);
> + bld.MOV(result, subscript(tmp, BRW_REGISTER_TYPE_UD, 0));
>} else {
> - zero = vgrf(glsl_type::int64_t_type);
> - tmp = vgrf(glsl_type::int64_t_type);
> + if (instr->op == nir_op_f2b) {
> +bld.CMP(result, op[0], brw_imm_f(0.0f), BRW_CONDITIONAL_NZ);
> + } else {
> +bld.CMP(result, op[0], brw_imm_d(0), BRW_CONDITIONAL_NZ);
> + }
>}
> -
> -  bld.MOV(zero, setup_imm_df(bld, 0.0));
> -  /* A SIMD16 execution needs to be split in two instructions, so use
> -   * a vgrf instead of the flag register as dst so instruction splitting
> -   * works
> -   */
> -  bld.CMP(tmp, op[0], zero, BRW_CONDITIONAL_NZ);
> -  bld.MOV(result, subscript(tmp, BRW_REGISTER_TYPE_UD, 0));
> -  break;
> -   }
> -   case nir_op_i2b:
> -  bld.CMP(result, op[0], brw_imm_d(0), BRW_CONDITIONAL_NZ);
>break;
>  
> case nir_op_ftrunc:
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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] Mesa 17.0.1 release candidate

2017-03-13 Thread Ilia Mirkin
On Mon, Mar 13, 2017 at 2:13 PM, Matt Turner  wrote:
> I think Bcc'ing also means my gmail filters wouldn't know it came from
> the announce list.

listid:mesa-announce.freedesktop.org should pick it up - even though
it's bcc'd, the mailing list distribution logic should still throw in
its List-Id and other headers.

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


Re: [Mesa-dev] [PATCH 0/3] GBM modifier plumbing

2017-03-13 Thread Daniel Stone
Hey Kristian,

On 13 March 2017 at 17:31, Kristian H. Kristensen  wrote:
> Jason Ekstrand  writes:
>> I was talking to Daniel today and I think we also need another some sort of
>> GL or GBM api that gives you the modifiers supported for
>> rendering/texturing.  One option would be a gbm_get_modifiers_for_use()
>> entrypoint that takes a usage and gives you a set of modifiers that's
>> guaranteed to work for that usage.  For scanout, it would return LINEAR, X,
>> and Y on SKL+ and LINEAR and X on BDW-; it wouldn't return CCS because that
>> only works on a limited number of planes.  I say this now because we may
>> want to do that with the same DRI version bump as the rest of it.
>
> Are you aware of
>
> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
>
> If you talked to Daniel, he probably brought it up - what's missing?

I guess it depends on how much asymmetry there is between texture and
render formats ... if there isn't much, then we could focus on landing
Varad's work and use that as a jumping-off point. I was under the
impression that there was a pretty big difference for some hardware,
though I guess the GBM implementation would still rank by optimality
when allocating ...

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


Re: [Mesa-dev] Mesa 17.0.1 release candidate

2017-03-13 Thread Matt Turner
On Mon, Mar 13, 2017 at 2:04 AM, Michel Dänzer  wrote:
> On 03/03/17 11:53 AM, Michel Dänzer wrote:
>> On 03/03/17 03:38 AM, Matt Turner wrote:
>>> On Wed, Mar 1, 2017 at 7:44 PM, Michel Dänzer  wrote:
 P.S. It would be better to put the mesa-announce list only in Bcc on
 this kind of e-mails, to prevent accidental followups there. Reply-to:
 mesa-dev seems useless for that.
>>>
>>> GMail seems to ignore Reply-to.
>>
>> That would be shocking, though not entirely surprising. Anyway, the
>> issue with Reply-To isn't limited to gmail. Reply-To merely replaces the
>> original message's From address in the followup, any mailer will still
>> include other recipients (with reply-to-all or similar).
>>
>>
>>> Putting mesa-announce@ in Bcc seems like the wrong thing to do.
>>
>> Why?
>
> Still curious why you think it's wrong.

Oh, sorry. I missed the reply.

I don't think it should be necessary. I'm on multiple *-announce
lists, and this is the only one that has this problem. I think it's a
misconfiguration of mesa-announce@ to not be a moderated list.

I think Bcc'ing also means my gmail filters wouldn't know it came from
the announce list.

>>> mesa-announce@ should just be moderated, like xorg-announce@ is.
>>
>> That probably makes sense. Adam, Daniel, is this implemented in
>> xorg-announce via the "emergency" option, or something else?
>
> Since I haven't heard back, I've enabled this option for the
> mesa-announce list. Let's see how it goes.

Thank you!

>> BTW, in that case it might be good to have more volunteers to process
>> the moderation queue. It's really easy with the listadmin tool.
>
> Any takers?

Yeah, I'm happy to help. What do I need to do to get started?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 99467] [radv] DOOM 2016 + wine. Green screen everywhere (but can be started)

2017-03-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99467

--- Comment #20 from Vedran Miletić  ---
(In reply to Sebastian Jug from comment #19)
> I would like to see these patches go mainline as well so we can all play.

I believe the issue is whether Doom Vulkan implementation follows the standard.
In case it does not, the game should be fixed. We _really_ shouldn't start
going down the road of workarounds with Vulkan like we did with OpenGL...

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


Re: [Mesa-dev] [PATCH] android: i965: generate code for OA counter queries

2017-03-13 Thread Robert Bragg
Acked-by: Robert Bragg 

On Sun, Mar 12, 2017 at 11:01 PM, Mauro Rossi  wrote:
> Automake generation rules are replicated for android.
> $* macro was expected to return "hsw" but instead gives "hsw.{h,c}"
> so $(basename $*) is used as a workaround
> to set the correct --chipset option for brw_oa.py script.
>
> Build tested with nougat-x86
>
> Fixes: e565505 "i965: Add script to gen code for OA counter queries"
> ---
>  src/mesa/drivers/dri/i965/Android.mk | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/Android.mk 
> b/src/mesa/drivers/dri/i965/Android.mk
> index 7dea3c2..6668930 100644
> --- a/src/mesa/drivers/dri/i965/Android.mk
> +++ b/src/mesa/drivers/dri/i965/Android.mk
> @@ -221,5 +221,22 @@ LOCAL_GENERATED_SOURCES := \
> $(MESA_DRI_OPTIONS_H) \
> $(MESA_GEN_NIR_H)
>
> +LOCAL_MODULE_CLASS := SHARED_LIBRARIES
> +
> +intermediates := $(call local-generated-sources-dir)
> +
> +LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, \
> +   $(i965_oa_GENERATED_FILES))
> +
> +$(intermediates)/brw_oa_%.h: $(LOCAL_PATH)/brw_oa_%.xml 
> $(LOCAL_PATH)/brw_oa.py
> +   @echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
> +   @mkdir -p $(dir $@)
> +   $(hide) $(MESA_PYTHON2) $(word 2, $^) --header=$@ 
> --chipset=$(basename $*) $<
> +
> +$(intermediates)/brw_oa_%.c: $(LOCAL_PATH)/brw_oa_%.xml 
> $(LOCAL_PATH)/brw_oa.py
> +   @echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
> +   @mkdir -p $(dir $@)
> +   $(hide) $(MESA_PYTHON2) $(word 2, $^) --code=$@ --chipset=$(basename 
> $*) $<
> +
>  include $(MESA_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --
> 2.10.2
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   3   >