[Mesa-dev] [PATCH] anv: reduce maxFragmentInputComponents

[Samuel Iglesias Gonsálvez]

If the application asks for the maximum number of fragment input
components (128), use all of them plus some builtins that are
passed in the VUE, then we exceed the maximum number of used VUE
slots (32) and we break one assert that checks this limit.

Also, with separate shader objects, we add CLIP_DIST0, CLIP_DIST1
builtins in brw_compute_vue_map() because we don't know if
gl_ClipDistance is going to be read/write by an adjacent stage.

Fixes VK-GL-CTS CL#2569.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/vulkan/anv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 374fc16c4c9..87c0d0cb4a6 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -898,7 +898,7 @@ void anv_GetPhysicalDeviceProperties(
   .maxGeometryOutputComponents  = 128,
   .maxGeometryOutputVertices= 256,
   .maxGeometryTotalOutputComponents = 1024,
-  .maxFragmentInputComponents   = 128,
+  .maxFragmentInputComponents   = 112, /* 128 components - 
(POS, PSIZ, CLIP_DIST0, CLIP_DIST1) */
   .maxFragmentOutputAttachments = 8,
   .maxFragmentDualSrcAttachments= 1,
   .maxFragmentCombinedOutputResources   = 8,
-- 
2.17.0

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

[Mesa-dev] [RFC 2/6] anv: add from/to helpers with android and vulkan formats

[Tapani Pälli]

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/vk_format_info.h | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/src/intel/vulkan/vk_format_info.h 
b/src/intel/vulkan/vk_format_info.h
index a1cc6952c8..0ae0a2d43e 100644
--- a/src/intel/vulkan/vk_format_info.h
+++ b/src/intel/vulkan/vk_format_info.h
@@ -27,6 +27,49 @@
 #include 
 #include 
 
+#ifdef ANDROID
+#include 
+static inline VkFormat
+vk_format_from_android(unsigned android_format)
+{
+   switch (android_format) {
+   case AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM:
+   case AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM:
+  return VK_FORMAT_R8G8B8A8_UNORM;
+   case AHARDWAREBUFFER_FORMAT_R8G8B8_UNORM:
+  return VK_FORMAT_R8G8B8_UNORM;
+   case AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM:
+  return VK_FORMAT_R5G6B5_UNORM_PACK16;
+   case AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT:
+  return VK_FORMAT_R16G16B16A16_SFLOAT;
+   case AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM:
+  return VK_FORMAT_A2B10G10R10_UNORM_PACK32;
+   case AHARDWAREBUFFER_FORMAT_BLOB:
+   default:
+  return VK_FORMAT_UNDEFINED;
+   }
+}
+
+static inline unsigned
+android_format_from_vk(unsigned vk_format)
+{
+   switch (vk_format) {
+   case VK_FORMAT_R8G8B8A8_UNORM:
+  return AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM;
+   case VK_FORMAT_R8G8B8_UNORM:
+  return AHARDWAREBUFFER_FORMAT_R8G8B8_UNORM;
+   case VK_FORMAT_R5G6B5_UNORM_PACK16:
+  return AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM;
+   case VK_FORMAT_R16G16B16A16_SFLOAT:
+  return AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT;
+   case VK_FORMAT_A2B10G10R10_UNORM_PACK32:
+  return AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM;
+   default:
+  return AHARDWAREBUFFER_FORMAT_BLOB;
+   }
+}
+#endif
+
 static inline VkImageAspectFlags
 vk_format_aspects(VkFormat format)
 {
-- 
2.14.3

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

[Mesa-dev] [RFC 1/6] anv: make anv_get_image_format_features public

[Tapani Pälli]

This will be utilized later by GetAndroidHardwareBufferPropertiesANDROID.

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_formats.c | 22 +++---
 src/intel/vulkan/anv_private.h |  5 +
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 0c5b8d3a2c..5a96e38d42 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -467,11 +467,11 @@ anv_get_format_plane(const struct gen_device_info 
*devinfo, VkFormat vk_format,
 
 // Format capabilities
 
-static VkFormatFeatureFlags
-get_image_format_features(const struct gen_device_info *devinfo,
-  VkFormat vk_format,
-  const struct anv_format *anv_format,
-  VkImageTiling vk_tiling)
+VkFormatFeatureFlags
+anv_get_image_format_features(const struct gen_device_info *devinfo,
+  VkFormat vk_format,
+  const struct anv_format *anv_format,
+  VkImageTiling vk_tiling)
 {
VkFormatFeatureFlags flags = 0;
 
@@ -704,11 +704,11 @@ void anv_GetPhysicalDeviceFormatProperties(
 
*pFormatProperties = (VkFormatProperties) {
   .linearTilingFeatures =
- get_image_format_features(devinfo, vk_format, anv_format,
-   VK_IMAGE_TILING_LINEAR),
+ anv_get_image_format_features(devinfo, vk_format, anv_format,
+   VK_IMAGE_TILING_LINEAR),
   .optimalTilingFeatures =
- get_image_format_features(devinfo, vk_format, anv_format,
-   VK_IMAGE_TILING_OPTIMAL),
+ anv_get_image_format_features(devinfo, vk_format, anv_format,
+   VK_IMAGE_TILING_OPTIMAL),
   .bufferFeatures =
  get_buffer_format_features(devinfo, vk_format, anv_format),
};
@@ -754,8 +754,8 @@ anv_get_image_format_properties(
if (format == NULL)
   goto unsupported;
 
-   format_feature_flags = get_image_format_features(devinfo, info->format,
-format, info->tiling);
+   format_feature_flags = anv_get_image_format_features(devinfo, info->format,
+format, info->tiling);
 
switch (info->type) {
default:
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index c10af14ead..df769a13c6 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -2905,6 +2905,11 @@ anv_sanitize_image_offset(const VkImageType imageType,
}
 }
 
+VkFormatFeatureFlags
+anv_get_image_format_features(const struct gen_device_info *devinfo,
+  VkFormat vk_format,
+  const struct anv_format *anv_format,
+  VkImageTiling vk_tiling);
 
 void anv_fill_buffer_surface_state(struct anv_device *device,
struct anv_state state,
-- 
2.14.3

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

[Mesa-dev] [RFC 4/6] anv/android: support import/export of AHardwareBuffer objects

[Tapani Pälli]

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_android.c | 97 ++
 src/intel/vulkan/anv_device.c  | 48 -
 src/intel/vulkan/anv_private.h | 18 
 3 files changed, 162 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 6c0c8cc793..d1eb0b2e8b 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -187,6 +187,103 @@ anv_GetAndroidHardwareBufferPropertiesANDROID(
return VK_SUCCESS;
 }
 
+VkResult
+anv_GetMemoryAndroidHardwareBufferANDROID(
+   VkDevice device_h,
+   const VkMemoryGetAndroidHardwareBufferInfoANDROID *pInfo,
+   struct AHardwareBuffer **pBuffer)
+{
+   ANV_FROM_HANDLE(anv_device_memory, mem, pInfo->memory);
+
+   /* Some quotes from Vulkan spec:
+*
+* "If the device memory was created by importing an Android hardware
+* buffer, vkGetMemoryAndroidHardwareBufferANDROID must return that same
+* Android hardware buffer object."
+*
+* "VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID must
+* have been included in VkExportMemoryAllocateInfoKHR::handleTypes when
+* memory was created."
+*/
+   if (mem->ahw) {
+  *pBuffer = mem->ahw;
+  /* Increase refcount. */
+  AHardwareBuffer_acquire(mem->ahw);
+  return VK_SUCCESS;
+   }
+
+   return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+}
+
+/*
+ * Called from anv_AllocateMemory when import AHardwareBuffer.
+ */
+VkResult
+anv_import_ahw_memory(VkDevice device_h,
+  struct anv_device_memory *mem,
+  const VkImportAndroidHardwareBufferInfoANDROID *info)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Get a description of buffer contents. */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(info->buffer, &desc);
+   VkResult result = VK_SUCCESS;
+
+   /* Import from AHardwareBuffer to anv_device_memory. */
+   const native_handle_t *handle =
+  AHardwareBuffer_getNativeHandle(info->buffer);
+
+   int dma_buf = (handle && handle->numFds) ? handle->data[0] : -1;
+   if (dma_buf < 0)
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   result = anv_bo_cache_import(device, &device->bo_cache,
+dma_buf, &mem->bo);
+   if (result != VK_SUCCESS)
+  return result;
+
+   close(dma_buf);
+
+   /* "If the vkAllocateMemory command succeeds, the implementation must
+* acquire a reference to the imported hardware buffer, which it must
+* release when the device memory object is freed. If the command fails,
+* the implementation must not retain a reference."
+*/
+   AHardwareBuffer_acquire(info->buffer);
+   mem->ahw = info->buffer;
+
+   return result;
+}
+
+VkResult
+anv_create_ahw_memory(VkDevice device_h,
+  struct anv_device_memory *mem,
+  const VkMemoryDedicatedAllocateInfo *info)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   ANV_FROM_HANDLE(anv_image, image, info->image);
+
+   struct AHardwareBuffer *ahw = NULL;
+
+   /* Copy properties from the image. */
+   struct AHardwareBuffer_Desc desc = {
+  .width = image->extent.width,
+  .height = image->extent.height,
+  .layers = 1,
+  .format = android_format_from_vk(image->vk_format),
+  .usage = AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT,
+  .stride = 0,
+};
+
+   if (AHardwareBuffer_allocate(&desc, &ahw) != 0)
+  return VK_ERROR_OUT_OF_HOST_MEMORY;
+
+   mem->ahw = ahw;
+
+   return VK_SUCCESS;
+}
+
 VkResult
 anv_image_from_gralloc(VkDevice device_h,
const VkImageCreateInfo *base_info,
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 374fc16c4c..63e3ddf171 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1929,14 +1929,55 @@ VkResult anv_AllocateMemory(
mem->type = &pdevice->memory.types[pAllocateInfo->memoryTypeIndex];
mem->map = NULL;
mem->map_size = 0;
+   mem->ahw = NULL;
+
+   /* Check if we need to support Android HW buffer export. If so,
+* create AHardwareBuffer and import memory from it.
+*/
+   bool android_export = false;
+   const VkExportMemoryAllocateInfo *export_info =
+  vk_find_struct_const(pAllocateInfo->pNext,
+   EXPORT_MEMORY_ALLOCATE_INFO);
+
+   if (export_info && export_info->handleTypes &
+   VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID)
+  android_export = true;
+
+   const VkMemoryDedicatedAllocateInfo *dedicated_info =
+  vk_find_struct_const(pAllocateInfo->pNext,
+   MEMORY_DEDICATED_ALLOCATE_INFO);
+
+   /* Android memory import. */
+   const struct VkImportAndroidHardwareBufferInfoANDROID *ahw_info =
+  vk_find_struct_const(pAllocateInfo->pNext,
+   IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID);
 
const VkImportMemoryFdInfoKHR *fd_info =

[Mesa-dev] [RFC 0/6] VK_ANDROID_external_memory_android_hardware_buffer

[Tapani Pälli]

Hi;

Here's RFC for the extension. I've tested the import/export functionality
with RGBA images on Android Celadon with a custom NDK app that draws a 
textured cube using AHardwareBuffer contents. Export feature I tested
by creating just a regular image (LunarG cube texture) and then exporting
that as AHardwareBuffer, modifying buffer and then rendering the
results.

I wanted to send this RFC to get some comments on what's missing and if
I have understood the specification correctly. If supporting only RGBA
for now is fine, I believe we could go forward with these bits.

Any comments appreciated!

Thanks;

// Tapani

Tapani Pälli (6):
  anv: make anv_get_image_format_features public
  anv: add from/to helpers with android and vulkan formats
  anv/android: add GetAndroidHardwareBufferPropertiesANDROID WIP
  anv/android: support import/export of AHardwareBuffer objects
  anv/android: support creating images from external format
  anv/android: turn on
VK_ANDROID_external_memory_android_hardware_buffer

 src/intel/vulkan/anv_android.c | 228 +
 src/intel/vulkan/anv_device.c  |  48 +++-
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_formats.c |  22 ++--
 src/intel/vulkan/anv_image.c   | 115 +++
 src/intel/vulkan/anv_private.h |  33 ++
 src/intel/vulkan/vk_format_info.h  |  43 +++
 7 files changed, 478 insertions(+), 12 deletions(-)

-- 
2.14.3

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

[Mesa-dev] [RFC 6/6] anv/android: turn on VK_ANDROID_external_memory_android_hardware_buffer

[Tapani Pälli]

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_extensions.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index b5bee0881c..9128d62fa5 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -68,6 +68,7 @@ MAX_API_VERSION = None # Computed later
 # the those extension strings, then tests dEQP-VK.api.info.instance.extensions
 # and dEQP-VK.api.info.device fail due to the duplicated strings.
 EXTENSIONS = [
+Extension('VK_ANDROID_external_memory_android_hardware_buffer', 3, 
'ANDROID'),
 Extension('VK_ANDROID_native_buffer', 5, 'ANDROID'),
 Extension('VK_KHR_16bit_storage', 1, 'device->info.gen 
>= 8'),
 Extension('VK_KHR_bind_memory2',  1, True),
-- 
2.14.3

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

[Mesa-dev] [RFC 3/6] anv/android: add GetAndroidHardwareBufferPropertiesANDROID WIP

[Tapani Pälli]

TODO - need to figure out implementation-defined external format identifier
 - YUV support

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_android.c | 91 ++
 1 file changed, 91 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..6c0c8cc793 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -29,6 +29,8 @@
 #include 
 
 #include "anv_private.h"
+#include "vk_format_info.h"
+#include "vk_util.h"
 
 static int anv_hal_open(const struct hw_module_t* mod, const char* id, struct 
hw_device_t** dev);
 static int anv_hal_close(struct hw_device_t *dev);
@@ -96,6 +98,95 @@ anv_hal_close(struct hw_device_t *dev)
return -1;
 }
 
+static VkResult
+get_ahw_buffer_format_properties(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferFormatPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+
+   /* Get a description of buffer contents . */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(buffer, &desc);
+
+   /* Verify description. */
+   uint64_t gpu_usage =
+  AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE |
+  AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT |
+  AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER;
+
+   /* "Buffer must be a valid Android hardware buffer object with at least
+* one of the AHARDWAREBUFFER_USAGE_GPU_* usage flags."
+*/
+   if (!(desc.usage & (gpu_usage)))
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* Fill properties fields based on description. */
+   VkAndroidHardwareBufferFormatPropertiesANDROID *p = pProperties;
+
+   p->pNext = NULL;
+   p->format = vk_format_from_android(desc.format);
+   p->externalFormat = 1; /* XXX */
+
+   const struct anv_format *anv_format = anv_get_format(p->format);
+   struct anv_physical_device *physical_device =
+  &device->instance->physicalDevice;
+   const struct gen_device_info *devinfo = &physical_device->info;
+
+   p->formatFeatures =
+  anv_get_image_format_features(devinfo, p->format,
+anv_format, VK_IMAGE_TILING_OPTIMAL);
+
+   p->samplerYcbcrConversionComponents.r = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.g = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.b = VK_COMPONENT_SWIZZLE_IDENTITY;
+   p->samplerYcbcrConversionComponents.a = VK_COMPONENT_SWIZZLE_IDENTITY;
+
+   p->suggestedYcbcrModel = VK_SAMPLER_YCBCR_MODEL_CONVERSION_RGB_IDENTITY;
+   p->suggestedYcbcrRange = VK_SAMPLER_YCBCR_RANGE_ITU_FULL;
+   p->suggestedXChromaOffset = VK_CHROMA_LOCATION_COSITED_EVEN;
+   p->suggestedYChromaOffset = VK_CHROMA_LOCATION_COSITED_EVEN;
+
+   return VK_SUCCESS;
+}
+
+VkResult
+anv_GetAndroidHardwareBufferPropertiesANDROID(
+   VkDevice device_h,
+   const struct AHardwareBuffer *buffer,
+   VkAndroidHardwareBufferPropertiesANDROID *pProperties)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+   struct anv_physical_device *pdevice = &dev->instance->physicalDevice;
+
+   const VkExternalFormatANDROID *format_prop =
+  vk_find_struct_const(pProperties->pNext,
+   ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROID);
+
+   /* Fill format properties of an Android hardware buffer. */
+   if (format_prop)
+  get_ahw_buffer_format_properties(device_h, buffer, format_prop);
+
+   /* Get a description of buffer contents . */
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(buffer, &desc);
+
+   const native_handle_t *handle =
+  AHardwareBuffer_getNativeHandle(buffer);
+   int dma_buf = (handle && handle->numFds) ? handle->data[0] : -1;
+   if (dma_buf < 0)
+  return VK_ERROR_INVALID_EXTERNAL_HANDLE_KHR;
+
+   /* All memory types. */
+   uint32_t memory_types = (1ull << pdevice->memory.type_count) - 1;
+
+   pProperties->allocationSize = lseek(dma_buf, 0, SEEK_END);
+   pProperties->memoryTypeBits = memory_types;
+
+   return VK_SUCCESS;
+}
+
 VkResult
 anv_image_from_gralloc(VkDevice device_h,
const VkImageCreateInfo *base_info,
-- 
2.14.3

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

[Mesa-dev] [RFC 5/6] anv/android: support creating images from external format

[Tapani Pälli]

Since we don't know the exact format at creation time, some initialization
is done only when bound with memory in vkBindImageMemory.

Signed-off-by: Tapani Pälli 
---
 src/intel/vulkan/anv_android.c |  40 ++
 src/intel/vulkan/anv_image.c   | 115 +
 src/intel/vulkan/anv_private.h |  10 
 3 files changed, 165 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index d1eb0b2e8b..c7e9d70e6d 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -284,6 +284,46 @@ anv_create_ahw_memory(VkDevice device_h,
return VK_SUCCESS;
 }
 
+VkResult
+anv_image_from_external(
+   VkDevice device_h,
+   const VkImageCreateInfo *base_info,
+   const struct VkExternalMemoryImageCreateInfo *create_info,
+   const VkAllocationCallbacks *alloc,
+   VkImage *out_image_h)
+{
+   ANV_FROM_HANDLE(anv_device, device, device_h);
+   VkImage image_h = VK_NULL_HANDLE;
+   struct anv_image *image = NULL;
+   VkResult result = VK_SUCCESS;
+
+   /* Note, we can't set format, stride and such yet. */
+   struct anv_image_create_info anv_info = {
+  .vk_info = base_info,
+  .isl_extra_usage_flags = ISL_SURF_USAGE_DISABLE_AUX_BIT,
+  .external_format = true,
+   };
+
+   const struct VkExternalFormatANDROID *ext_info =
+  vk_find_struct_const(base_info->pNext, EXTERNAL_FORMAT_ANDROID);
+
+   if (ext_info && ext_info->externalFormat != 0) {
+  assert(base_info->format == VK_FORMAT_UNDEFINED);
+  assert(base_info->imageType == VK_IMAGE_TYPE_2D);
+  assert(base_info->usage == VK_IMAGE_USAGE_SAMPLED_BIT);
+  assert(base_info->tiling == VK_IMAGE_TILING_OPTIMAL);
+   }
+
+   result = anv_image_create(device_h, &anv_info, alloc, &image_h);
+   image = anv_image_from_handle(image_h);
+   if (result != VK_SUCCESS)
+  return result;
+
+   *out_image_h = image_h;
+
+   return result;
+}
+
 VkResult
 anv_image_from_gralloc(VkDevice device_h,
const VkImageCreateInfo *base_info,
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 42496b6414..5aa67718da 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -595,6 +595,15 @@ anv_image_create(VkDevice _device,
image->drm_format_mod = isl_mod_info ? isl_mod_info->modifier :
   DRM_FORMAT_MOD_INVALID;
 
+   /* In case of external format, We don't know format yet,
+* so skip the rest for now.
+*/
+   if (create_info->external_format) {
+  image->external_format = true;
+  *pImage = anv_image_to_handle(image);
+  return VK_SUCCESS;
+   }
+
const struct anv_format *format = anv_get_format(image->vk_format);
assert(format != NULL);
 
@@ -630,6 +639,14 @@ anv_CreateImage(VkDevice device,
 VkImage *pImage)
 {
 #ifdef ANDROID
+   const struct VkExternalMemoryImageCreateInfo *create_info =
+  vk_find_struct_const(pCreateInfo->pNext, 
EXTERNAL_MEMORY_IMAGE_CREATE_INFO);
+
+   if (create_info && create_info->handleTypes &
+   VK_EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROID)
+  return anv_image_from_external(device, pCreateInfo, create_info,
+ pAllocator, pImage);
+
const VkNativeBufferANDROID *gralloc_info =
   vk_find_struct_const(pCreateInfo->pNext, NATIVE_BUFFER_ANDROID);
 
@@ -684,6 +701,99 @@ static void anv_image_bind_memory_plane(struct anv_device 
*device,
image->planes[plane].bo_offset = memory_offset;
 }
 
+#ifdef ANDROID
+/* We are binding AHardwareBuffer. Get a description and
+ * prepare anv_image properly.
+ */
+static void
+prepare_ahw_image(struct anv_device *device,
+  struct anv_image *image,
+  struct anv_device_memory *mem)
+{
+   assert(mem->ahw);
+
+   AHardwareBuffer_Desc desc;
+   AHardwareBuffer_describe(mem->ahw, &desc);
+
+   /* Check tiling. */
+   int i915_tiling = anv_gem_get_tiling(device, mem->bo->gem_handle);
+   VkImageTiling vk_tiling = 2;
+
+   isl_tiling_flags_t isl_tiling_flags = 0;
+
+   switch (i915_tiling) {
+   case I915_TILING_NONE:
+  vk_tiling = VK_IMAGE_TILING_LINEAR;
+  isl_tiling_flags = ISL_TILING_LINEAR_BIT;
+  break;
+   case I915_TILING_X:
+  vk_tiling = VK_IMAGE_TILING_OPTIMAL;
+  isl_tiling_flags = ISL_TILING_X_BIT;
+  break;
+   case I915_TILING_Y:
+  vk_tiling = VK_IMAGE_TILING_OPTIMAL;
+  isl_tiling_flags = ISL_TILING_Y0_BIT;
+  break;
+   case -1:
+   default:
+  unreachable("Invalid tiling flags.");
+   }
+
+   assert(vk_tiling == VK_IMAGE_TILING_LINEAR ||
+  vk_tiling == VK_IMAGE_TILING_OPTIMAL);
+
+   /* Check format. */
+   VkFormat vk_format = vk_format_from_android(desc.format);
+   enum isl_format isl_fmt = anv_get_isl_format(&device->info,
+vk_format,
+VK_IMAGE_ASPECT_COLOR_BIT,
+ 

Re: [Mesa-dev] [PATCH v2 1/4] i965: Add virtual memory allocator infrastructure to brw_bufmgr.

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2018-05-27 21:35:40, Kenneth Graunke wrote:
> This introduces a new fast virtual memory allocator integrated with our
> BO cache bucketing.  For larger objects, it falls back to the simple
> free-list allocator (util_vma).
> 
> This puts the allocators in place but doesn't enable softpin yet.
> 
> v2:
>  (feedback from Chris Wilson)
>  - Check (bo->kflags & EXEC_OBJECT_PINNED) instead of a global flag
>  - Avoid vma_free(0ull) on the err_free path.
>  - Only enable if the kernel says we have full PPGTT support
>  - Make bucketing allocators more resistant to failing to grow arrays
>  (feedback from Scott Phillips)
>  - Don't use node after popping it from the list.
>  - Avoid undefined behavior in canonicalization by reusing new helper
>  - Comment updates
>  (feedback from myself)
>  - Avoid __vma_alloc vs. vma_alloc by making a zero_high_bits helper
>to return a non-canonical address with the high bits zeroed.
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 291 -
>  src/mesa/drivers/dri/i965/brw_bufmgr.h |   2 +
>  2 files changed, 292 insertions(+), 1 deletion(-)
> 
> I plan to land this series this week, barring any major objections.
> Scott reviewed it all (from my v1.9 branch), but I wasn't positive
> whether some of his reviews still applied...so I figured I'd play it
> safe and send it out one more time.
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 66828f319be..13d32255715 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -54,12 +54,15 @@
>  #endif
>  #include "common/gen_clflush.h"
>  #include "common/gen_debug.h"
> +#include "common/gen_gem.h"
>  #include "dev/gen_device_info.h"
>  #include "libdrm_macros.h"
>  #include "main/macros.h"
>  #include "util/macros.h"
>  #include "util/hash_table.h"
>  #include "util/list.h"
> +#include "util/u_dynarray.h"
> +#include "util/vma.h"
>  #include "brw_bufmgr.h"
>  #include "brw_context.h"
>  #include "string.h"
> @@ -98,9 +101,41 @@ atomic_add_unless(int *v, int add, int unless)
> return c == unless;
>  }
>  
> +/**
> + * i965 fixed-size bucketing VMA allocator.
> + *
> + * The BO cache maintains "cache buckets" for buffers of various sizes.
> + * All buffers in a given bucket are identically sized - when allocating,
> + * we always round up to the bucket size.  This means that virtually all
> + * allocations are fixed-size; only buffers which are too large to fit in
> + * a bucket can be variably-sized.
> + *
> + * We create an allocator for each bucket.  Each contains a free-list, where
> + * each node contains a  pair.  Each bit
> + * represents a bucket-sized block of memory.  (At the first level, each
> + * bit corresponds to a page.  For the second bucket, bits correspond to
> + * two pages, and so on.)  1 means a block is free, and 0 means it's in-use.
> + * The lowest bit in the bitmap is for the first block.
> + *
> + * This makes allocations cheap - any bit of any node will do.  We can pick
> + * the head of the list and use ffs() to find a free block.  If there are
> + * none, we allocate 64 blocks from a larger allocator - either a bigger
> + * bucketing allocator, or a fallback top-level allocator for large objects.
> + */
> +struct vma_bucket_node {
> +   uint64_t start_address;
> +   uint64_t bitmap;
> +};
> +
>  struct bo_cache_bucket {
> +   /** List of cached BOs. */
> struct list_head head;
> +
> +   /** Size of this bucket, in bytes. */
> uint64_t size;
> +
> +   /** List of vma_bucket_nodes. */
> +   struct util_dynarray vma_list[BRW_MEMZONE_COUNT];
>  };
>  
>  struct brw_bufmgr {
> @@ -116,6 +151,8 @@ struct brw_bufmgr {
> struct hash_table *name_table;
> struct hash_table *handle_table;
>  
> +   struct util_vma_heap vma_allocator[BRW_MEMZONE_COUNT];
> +
> bool has_llc:1;
> bool has_mmap_wc:1;
> bool bo_reuse:1;
> @@ -128,6 +165,17 @@ static int bo_set_tiling_internal(struct brw_bo *bo, 
> uint32_t tiling_mode,
>  
>  static void bo_free(struct brw_bo *bo);
>  
> +static uint64_t
> +zero_high_bits(uint64_t addr)
> +{
> +   /* Un-canonicalize the address, zeroing out the high bits. */
> +   return addr & ((1ull << 48) - 1);
> +}
> +
> +static uint64_t vma_alloc(struct brw_bufmgr *bufmgr,
> +  enum brw_memory_zone memzone,
> +  uint64_t size, uint64_t alignment);
> +
>  static uint32_t
>  key_hash_uint(const void *key)
>  {
> @@ -222,6 +270,187 @@ bucket_for_size(struct brw_bufmgr *bufmgr, uint64_t 
> size)
>&bufmgr->cache_bucket[index] : NULL;
>  }
>  
> +static enum brw_memory_zone
> +memzone_for_address(uint64_t address)
> +{
> +   const uint64_t _4GB = 1ull << 32;
> +
> +   if (address >= _4GB)
> +  return BRW_MEMZONE_OTHER;
> +
> +   return BRW_MEMZONE_LOW_4G;
> +}
> +
> +static uint64_t
> +bucket_vma_alloc(struct brw_bufmgr *bufmgr,
> + st

[Mesa-dev] [Bug 106696] repeatable drm:amdgpu_job_timedout with vulkan toy

[bugzilla-daemon]

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

Dave Gilbert  changed:

   What|Removed |Added

 Resolution|NOTABUG |---
 Status|RESOLVED|REOPENED

--- Comment #4 from Dave Gilbert  ---
(In reply to Christian König from comment #3)
> GPU reset and recovery can be enabled using amdgpu.gpu_recovery=1.
> 
> Otherwise a shader with an endless loop will just keep running forever.

Hmm; that's a dangerous situation.

1) Recovery doesn't work - I tried it, and it did at least make the machine
rebootable, but the GPU state was very broken after the reset attempt.

2) An unprivileged user being able to make the system need & fail to reboot by
default is a security issue; couldn't this be triggered by something like
WebGL?

-- 
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] [1/3] tegra: Remove usage of non-stable UAPI

[Daniel Kolesa]

Hello,

On 2018/04/19 18:31, Thierry Reding wrote:

From: Thierry Reding 

This code path is no longer required with framebuffer modifier support.


This patch series fixes Xorg 1.20 startup (since 1.20, it does not 
modeset with upstream Mesa tegra driver unless xserver commit c8c276c9 
is reverted) as well as the need to revert a patch in the upstream 
kernel (4ae4b5c0) at very least on my Tegra X1 device, therefore:


Tested-by: Daniel Kolesa 

It looks to me like a bugfix series, can this get in an 18.1 bugfix 
release or will it have to wait for 18.2?


Regards,

Daniel



Signed-off-by: Thierry Reding 
---
  src/gallium/drivers/tegra/tegra_screen.c | 69 ++--
  1 file changed, 3 insertions(+), 66 deletions(-)


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

Re: [Mesa-dev] [PATCH] i965: Disable guardband clipping on SandyBridge for odd dimensions

[Vadym Shovkoplias]

ping

On Thu, May 24, 2018 at 2:02 PM, vadym.shovkoplias <
vadim.shovkopl...@gmail.com> wrote:

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104388
> Signed-off-by: Andriy Khulap 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index b485e2c..5aa8033 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2473,6 +2473,17 @@ brw_calculate_guardband_size(uint32_t fb_width,
> uint32_t fb_height,
>  */
> const float gb_size = GEN_GEN >= 7 ? 16384.0f : 8192.0f;
>
> +   /* Workaround: prevent gpu hangs on SandyBridge
> +* by disabling guardband clipping for odd dimensions.
> +*/
> +   if (GEN_GEN == 6 && (fb_width & 1 || fb_height & 1)) {
> +  *xmin = -1.0f;
> +  *xmax =  1.0f;
> +  *ymin = -1.0f;
> +  *ymax =  1.0f;
> +  return;
> +   }
> +
> if (m00 != 0 && m11 != 0) {
>/* First, we compute the screen-space render area */
>const float ss_ra_xmin = MIN3(0, m30 + m00, m30 - m00);
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 

Vadym Shovkoplias | Senior Software Engineer
GlobalLogic
P +380.57.766.7667  M +3.8050.931.7304  S vadym.shovkoplias
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: don't call Driver.TexEnv with invalid arguments

[Tapani Pälli]

Patch skips useless and possibly dangerous calls down to the driver
in case invalid arguments were given. I noticed this would be happening
with demo of Darwinia game. AFAIK this does not fix anything but makes
this path safer and more like how other API functions are implemented.

Signed-off-by: Tapani Pälli 
---
 src/mesa/main/texenv.c | 54 +++---
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
index 22fc8da1ca..a69c8dd743 100644
--- a/src/mesa/main/texenv.c
+++ b/src/mesa/main/texenv.c
@@ -103,7 +103,7 @@ set_env_color(struct gl_context *ctx,
 
 
 /** Set an RGB or A combiner mode/function */
-static void
+static bool
 set_combiner_mode(struct gl_context *ctx,
   struct gl_fixedfunc_texture_unit *texUnit,
   GLenum pname, GLenum mode)
@@ -144,32 +144,35 @@ set_combiner_mode(struct gl_context *ctx,
 
if (!legal) {
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", mode);
-  return;
+  return false;
}
 
switch (pname) {
case GL_COMBINE_RGB:
   if (texUnit->Combine.ModeRGB == mode)
- return;
+ return true;
   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
   texUnit->Combine.ModeRGB = mode;
   break;
 
case GL_COMBINE_ALPHA:
   if (texUnit->Combine.ModeA == mode)
- return;
+ return true;
   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
   texUnit->Combine.ModeA = mode;
   break;
default:
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
+  return false;
}
+
+   return true;
 }
 
 
 
 /** Set an RGB or A combiner source term */
-static void
+static bool
 set_combiner_source(struct gl_context *ctx,
 struct gl_fixedfunc_texture_unit *texUnit,
 GLenum pname, GLenum param)
@@ -199,13 +202,13 @@ set_combiner_source(struct gl_context *ctx,
   break;
default:
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
-  return;
+  return false;
}
 
if ((term == 3) && (ctx->API != API_OPENGL_COMPAT
|| !ctx->Extensions.NV_texture_env_combine4)) {
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
-  return;
+  return false;
}
 
assert(term < MAX_COMBINER_TERMS);
@@ -246,7 +249,7 @@ set_combiner_source(struct gl_context *ctx,
 
if (!legal) {
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", param);
-  return;
+  return false;
}
 
FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
@@ -255,11 +258,13 @@ set_combiner_source(struct gl_context *ctx,
   texUnit->Combine.SourceA[term] = param;
else
   texUnit->Combine.SourceRGB[term] = param;
+
+   return true;
 }
 
 
 /** Set an RGB or A combiner operand term */
-static void
+static bool
 set_combiner_operand(struct gl_context *ctx,
  struct gl_fixedfunc_texture_unit *texUnit,
  GLenum pname, GLenum param)
@@ -286,13 +291,13 @@ set_combiner_operand(struct gl_context *ctx,
   break;
default:
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
-  return;
+  return false;
}
 
if ((term == 3) && (ctx->API != API_OPENGL_COMPAT
|| !ctx->Extensions.NV_texture_env_combine4)) {
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
-  return;
+  return false;
}
 
assert(term < MAX_COMBINER_TERMS);
@@ -328,7 +333,7 @@ set_combiner_operand(struct gl_context *ctx,
 
if (!legal) {
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", param);
-  return;
+  return false;
}
 
FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
@@ -337,10 +342,12 @@ set_combiner_operand(struct gl_context *ctx,
   texUnit->Combine.OperandA[term] = param;
else
   texUnit->Combine.OperandRGB[term] = param;
+
+   return true;
 }
 
 
-static void
+static bool
 set_combiner_scale(struct gl_context *ctx,
struct gl_fixedfunc_texture_unit *texUnit,
GLenum pname, GLfloat scale)
@@ -359,25 +366,28 @@ set_combiner_scale(struct gl_context *ctx,
else {
   _mesa_error( ctx, GL_INVALID_VALUE,
"glTexEnv(GL_RGB_SCALE not 1, 2 or 4)" );
-  return;
+  return false;
}
 
switch (pname) {
case GL_RGB_SCALE:
   if (texUnit->Combine.ScaleShiftRGB == shift)
- return;
+ return true;
   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
   texUnit->Combine.ScaleShiftRGB = shift;
   break;
case GL_ALPHA_SCALE:
   if (texUnit->Combine.ScaleShiftA == shift)
- return;
+ return true;
   FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
   texUnit->Combine.ScaleShiftA = shift;
   break;
default:
   TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
+  return false;
}
+
+   return true;
 }
 
 
@@ -418,7 +428,8 @@ _mesa_TexEnvfv( GLenum target, GLenum pn

Re: [Mesa-dev] [PATCH v2] nir/print: fix printing of 8/16 bit constant variables

[Chema Casanova]

El 29/05/18 a las 02:14, Karol Herbst escribió:
> v2 (Chema Casanova ): add float16 support
> 
> Signed-off-by: Karol Herbst 
> ---
>  src/compiler/nir/nir_print.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_print.c b/src/compiler/nir/nir_print.c
> index 97b2d6164cd..bb2d4e52067 100644
> --- a/src/compiler/nir/nir_print.c
> +++ b/src/compiler/nir/nir_print.c
> @@ -299,6 +299,28 @@ print_constant(nir_constant *c, const struct glsl_type 
> *type, print_state *state
> unsigned i, j;
>  
> switch (glsl_get_base_type(type)) {
> +   case GLSL_TYPE_UINT8:
> +   case GLSL_TYPE_INT8:
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (i = 0; i < rows; i++) {
> + if (i > 0) fprintf(fp, ", ");
> + fprintf(fp, "0x%02x", c->values[0].u8[i]);
> +  }
> +  break;
> +
> +   case GLSL_TYPE_UINT16:
> +   case GLSL_TYPE_INT16:
> +  /* Only float base types can be matrices. */
> +  assert(cols == 1);
> +
> +  for (i = 0; i < rows; i++) {
> + if (i > 0) fprintf(fp, ", ");
> + fprintf(fp, "0x%04x", c->values[0].u16[i]);
> +  }
> +  break;
> +
> case GLSL_TYPE_UINT:
> case GLSL_TYPE_INT:
> case GLSL_TYPE_BOOL:
> @@ -311,6 +333,15 @@ print_constant(nir_constant *c, const struct glsl_type 
> *type, print_state *state
>}
>break;
>  
> +   case GLSL_TYPE_FLOAT16:
> +  for (i = 0; i < cols; i++) {
> + for (j = 0; j < rows; j++) {
> +if (i + j > 0) fprintf(fp, ", ");
> +fprintf(fp, "%f", _mesa_half_to_float(c->values[i].u16[i]));

It should be:

 fprintf(fp, "%f", _mesa_half_to_float(c->values[i].u16[j]));

With that fixed.

Reviewed-by: Jose Maria Casanova Crespo 


> + }
> +  }
> +  break;
> +
> case GLSL_TYPE_FLOAT:
>for (i = 0; i < cols; i++) {
>   for (j = 0; j < rows; j++) {
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [AppVeyor] mesa master #7797 failed

[AppVeyor]

Build mesa 7797 failed


Commit 56792a0876 by Karol Herbst on 5/10/2018 8:20 AM:

nir/print: fix printing of 8/16 bit constant variables\n\nv2 (Jose Maria Casanova Crespo ): add float16 support\n\nSigned-off-by: Karol Herbst \nReviewed-by: Jose Maria Casanova Crespo 


Configure your notification preferences

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

Re: [Mesa-dev] Gitlab migration

[Daniel Stone]

Hi Mark,

On 26 May 2018 at 00:47, Mark Janes  wrote:
> Daniel Stone  writes:
>> We had a go at using Jenkins for some of this: Intel's been really
>> quite successful at doing it internally, but our community efforts
>> have been a miserable failure. After a few years I've concluded that
>> it's not going to change - even with Jenkins 2.0. [...]
>
> I agree with some of your Jenkins critiques.  I have implemented CI on
> *many* different frameworks over the past 15 years, and I think that
> every implementation has its fans and haters.
>
> It is wise to create automation which is mostly independent of the CI
> framework.  Mesa i965 CI could immediately switch from Jenkins to
> BuildBot or GitLab, if there was a reason to do so.  It may be that
> GitLab is superior to Jenkins by now, but the selection of the CI
> framework is a minor detail anyways.

I don't think there'd be any benefit, to be honest. You have an
experienced and capable team who can and have been dealing with
Jenkins successfully for years; the system works. For the above
reasons, I think it's totally inappropriate for fd.o to be offering as
a general service to all our projects; this is very different to Intel
offering a very specific and targeted service receiving full-time paid
attention.

> CI frameworks are often based on build/test pipelines, which I think is
> exactly the wrong concept for the domain.  Flexible CI is best thought
> of as a multiplatform `make` system.  Setting up a "pipeline" is similar
> to building your project with a shell script instead of a makefile.

Unless I've totally misunderstood you, I agree.

>> GitLab CI fixes all of these things. Pipelines are strongly and
>> directly correlated with commits in repositories, though you can also
>> trigger them manually or on a schedule. Permissions are that of the
>> repository, and just like Travis, people can fork and work on CI
>> improvements in their own sandbox without impacting anything else. The
>> job configuration is in relatively clean YAML, and it strongly
>> suggests idiomatic form rather than a forest of thousands of
>> unmaintained plugins.
>>
>> Jobs get run in clean containers, rather than special unicorn workers
>> pre-configured just so, meaning that the builds are totally
>> reproducible locally and you can use whatever build dependencies you
>> want without having to bug the admins to install LLVM in some
>> particular chroot. Those containers can be stored in a registry
>> attached to the project, with their own lifetime/ownership/etc
>> tracking. Jenkins can use Docker if you have an external registry, but
>> again this requires setting up external authentication and
>> permissions, not to mention that there's no lifetime/ownership/expiry
>> tracking, so you have to write more special admin cronjob scripts to
>> clean up old images in the registry.
>
> GitLab may be perfectly suitable for CI, but please do not select Mesa
> dev infrastructure based on CI features.
>
> Any Mesa CI needs to trigger from multiple projects: drm, dEQP, Piglit,
> VulkanCTS, SPIRV-Tools, crucible, glslang.  They are not all going to be
> in GitLab.
>
> The cart (CI) follows the horse (upstream development process).  CI
> automation is cheap and flexible, and can easily adapt to changes in the
> driver implementation / dev process.

Sure, though it depends of course on your definition. If you're taking
'CI' to mean 'exactly the thing Intel does today' (i.e. building
dozens of different modules with completely disconnected development
streams and testing driver behaviour on a huge farm of hardware
maintained specifically for that purpose), then yes, it's totally
unsuitable, and I wouldn't advise anyone to try. If using that
definition, 'cheap and flexible' also doesn't fit at all, because the
actual maintenance of the hardware (especially if using a system which
doesn't account for hardware failure), and accounting for the
combinatorial explosion of components is several full-time jobs, as
you know.

I'm suggesting that using GitLab CI as a visible and obvious part of
the community development process would be useful for a far more
limited suite of automated tasks run to provide feedback to developers
on the suitability of their code for merging.

>> It _is_ possible to bend Jenkins to your will - Mark's excellent and
>> super-helpful work with Intel's CI is testament to that - and in some
>> environments it's fine, but after a few years of trying, I just don't
>> think it's suitable to run on fd.o, and I also don't think it's a good
>> fit for what Mesa wants to be doing with CI as a community. (That was
>> much longer than expected, sorry: the wound is still raw, I guess.)
>
> CI may not be suitable for running on fd.o at all.  Similar systems have
> large staff and generally provide far poorer results than i965 CI.  Even
> when done well, it takes a lot of work and hardware.
>
> If an entity like the Linux Foundation were to underwrite an effort
> where dedicated staff

Re: [Mesa-dev] Gitlab migration

[Daniel Stone]

Hi,

On 26 May 2018 at 07:42, Marek Olšák  wrote:
> On Thu, May 24, 2018 at 6:46 AM, Daniel Stone  wrote:
>> cgit and anongit will not be orphaned: they remain as push mirrors so
>> are updated simultaneously with GItLab pushes, as will the GitHub
>> mirrors. Realistically, we can't deprecate anongit for a (very) long
>> time due to the millions of Yocto forks which have that URL embedded
>> in their build recipes. Running cgit alongside that is fairly
>> low-intervention. And hey, if we look at the logs in five years' time
>> and see 90% of people still using cgit to browse and not GitLab,
>> that's a pretty strong hint that we should put effort into keeping it.
>
> Well, I don't know what people are talking about.
>
> [...]

Probably because it's about subjective opinion rather than objective fact? :)

> OK, that was harsh, but there is a lot of truth to it. I guess GitLab is
> great for admins and I get that. Speaking of the web UI, at least the
> read-only view is impressively unimpressive.

Personally, I much prefer it. My browser content window is around
3200x1700, so I have no problem fitting information in, but I do have
to smash the zoom level up whenever I look at a cgit log; GitLab's
view is about the right density for both my laptop and my phone.
Seeing avatars also helps me skim by quicker visual recognition. If I
ever need to do particularly intense reading or searching which would
take any length of time, I've always just pulled the branch and used
my regular local git tools to examine the repository.

YMMV, and that's fine. But each to their own.

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

Re: [Mesa-dev] Gitlab migration

[Daniel Stone]

Hey,

On 27 May 2018 at 16:35, Rob Clark  wrote:
> On Sun, May 27, 2018 at 10:47 AM, Jason Ekstrand  wrote:
>> Given the number of people who have said they still like the mailing list,
>> that's probably a discussion for another email thread.
>
> It would be kinda clever if gitlab could automagically send patches to
> list when you open a PR.. even more clever if it could link replies to
> those patches on list back to the PR, although maybe that would be
> harder to implement.. that would seem like having our cake and eating
> it too ;-)

Honestly, I can't ever see this happening. GitLab's UI gives you the
ability to place comments at certain positions within the code, to
start and later resolve individual discussions (individually
enumerated subthreads), to open more general discussions or comments,
etc. Given the difficulty we had teaching Patchwork to recognise a)
what a patch was, b) what a group of patches was, c) what comments
were, and d) who made them, I wouldn't trust it to place it correctly
within the GitLab UI.

Basically you fall into the uncanny valley, where the web users are
upset that anyone using mail breaks things completely, and the mail
users are upset that it's much more janky than a pure-mail workflow.

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

[Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

GL_LIB expands to GLX_mesa, but applications should not link against
that. -lGL is never wrong, just hardcode it.

Signed-off-by: Adam Jackson 
---
 src/mesa/gl.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
index 181724b97b..8c7b7da8d7 100644
--- a/src/mesa/gl.pc.in
+++ b/src/mesa/gl.pc.in
@@ -7,7 +7,7 @@ Name: gl
 Description: Mesa OpenGL library
 Requires.private: @GL_PC_REQ_PRIV@
 Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -l@GL_LIB@
+Libs: -L${libdir} -lGL
 Libs.private: @GL_PC_LIB_PRIV@
 Cflags: -I${includedir} @GL_PC_CFLAGS@
 glx_tls: @GLX_TLS@
-- 
2.17.0

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

[Mesa-dev] [AppVeyor] mesa master #7798 completed

[AppVeyor]

Build mesa 7798 completed



Commit e6a1aca0b2 by Eric Engestrom on 5/29/2018 1:47 PM:

docs: add missing html closing tag\n\nSigned-off-by: Eric Engestrom 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Eric Engestrom]

On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
> GL_LIB expands to GLX_mesa, but applications should not link against
> that. -lGL is never wrong, just hardcode it.

Agreed, and Archlinux has had this patch since basically forever:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa

> 
> Signed-off-by: Adam Jackson 

Acked-by: Eric Engestrom 
Tested-by: Eric Engestrom 

> ---
>  src/mesa/gl.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
> index 181724b97b..8c7b7da8d7 100644
> --- a/src/mesa/gl.pc.in
> +++ b/src/mesa/gl.pc.in
> @@ -7,7 +7,7 @@ Name: gl
>  Description: Mesa OpenGL library
>  Requires.private: @GL_PC_REQ_PRIV@
>  Version: @PACKAGE_VERSION@
> -Libs: -L${libdir} -l@GL_LIB@
> +Libs: -L${libdir} -lGL
>  Libs.private: @GL_PC_LIB_PRIV@
>  Cflags: -I${includedir} @GL_PC_CFLAGS@
>  glx_tls: @GLX_TLS@
> -- 
> 2.17.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] egl/x11: Move dri2_format_for_depth prototype.

[Eric Engestrom]

On Tuesday, 2018-05-29 05:21:02 +0100, Marathe, Yogesh wrote:
> Hi Vinson, Eric,
> 
> > -Original Message-
> > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf
> > Of Vinson Lee
> > Sent: Sunday, May 27, 2018 1:34 PM
> > To: Engestrom, Eric 
> > Cc: Daniel Stone ; Emil Velikov
> > ; Eric Engestrom ; Marathe,
> > Yogesh ; ML mesa-dev  > d...@lists.freedesktop.org>
> > Subject: Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth
> > prototype.
> > 
> > On Fri, May 25, 2018 at 9:42 AM, Eric Engestrom 
> > wrote:
> > > On Friday, 2018-05-25 16:06:26 +0100, Eric Engestrom wrote:
> > >> On Friday, 2018-05-25 06:52:25 +, Vinson Lee wrote:
> > >> > Fix build error without DRI3.
> > >>
> > >> D'uh!
> > >> I forgot building dri3 was optional, sorry :/
> > >>
> > >> Reviewed-by: Eric Engestrom 
> > >
> > > Actually, wait no, this doesn't look right, the function should be
> > > named something else if it's exposed to everyone, since it's quite
> > > specific to x11's case, or it should not be exposed to everyone.
> > >
> > > I feel like the best thing to do here is to just copy the prototype to
> > > platform_x11.c:
> > >
> > > ---8<---
> > > diff --git a/src/egl/drivers/dri2/platform_x11.c
> > > b/src/egl/drivers/dri2/platform_x11.c
> > > index b2a3000b252ec0ddb12f..ea9b0cc6d6fd04804d2a 100644
> > > --- a/src/egl/drivers/dri2/platform_x11.c
> > > +++ b/src/egl/drivers/dri2/platform_x11.c
> > > @@ -55,6 +55,9 @@ static EGLBoolean
> > >  dri2_x11_swap_interval(_EGLDriver *drv, _EGLDisplay *disp, _EGLSurface
> > *surf,
> > > EGLint interval);
> > >
> > > +uint32_t
> > > +dri2_format_for_depth(uint32_t depth); u
> > >  static void
> > >  swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
> > >   struct dri2_egl_surface * dri2_surf)
> > > --->8---
> > >
> > 
> > This also fixes the build error.
> > 
> > Tested-by: Vinson Lee 
> > 
> 
> Did we also check dri3 build after this?

I checked with my usual "everything is enabled" build as well as the
default meson configuration.

> I see platform_x11_dri3.c using it and we've removed it from
> platform_x11_dri3.h, dri2_format_for_depth() prototype with extern in
> platform_x11_dri3.c shall help?

I'm not sure I follow, but I think you're talking about adding my inline
platform_x11.c patch on top of vlee's original patch, which is not what
I suggested; my suggestion was to replace his patch with mine.
Does that answer your question?

> 
> If not extern I'm inclining towards better name for the function in egl_dri2.h
> 
> > >>
> > >> >
> > >> >   CC   drivers/dri2/platform_x11.lo
> > >> > drivers/dri2/platform_x11.c:1010:1: error: no previous prototype
> > >> > for function 'dri2_format_for_depth' [-Werror,-Wmissing-prototypes]
> > >> > dri2_format_for_depth(uint32_t depth) ^
> > >> >
> > >> > Fixes: 473af0b541b2 ("egl/x11: deduplicate depth-to-format logic")
> > >> > Signed-off-by: Vinson Lee 
> > >> > ---
> > >> >  src/egl/drivers/dri2/egl_dri2.h  | 3 +++
> > >> >  src/egl/drivers/dri2/platform_x11_dri3.h | 3 ---
> > >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > >> >
> > >> > diff --git a/src/egl/drivers/dri2/egl_dri2.h
> > >> > b/src/egl/drivers/dri2/egl_dri2.h index adabc527f85b..b91a899e476c
> > >> > 100644
> > >> > --- a/src/egl/drivers/dri2/egl_dri2.h
> > >> > +++ b/src/egl/drivers/dri2/egl_dri2.h
> > >> > @@ -523,4 +523,7 @@ dri2_init_surface(_EGLSurface *surf,
> > >> > _EGLDisplay *dpy, EGLint type,  void  dri2_fini_surface(_EGLSurface
> > >> > *surf);
> > >> >
> > >> > +uint32_t
> > >> > +dri2_format_for_depth(uint32_t depth);
> > >> > +
> > >> >  #endif /* EGL_DRI2_INCLUDED */
> > >> > diff --git a/src/egl/drivers/dri2/platform_x11_dri3.h
> > >> > b/src/egl/drivers/dri2/platform_x11_dri3.h
> > >> > index e6fd01366978..96e7ee972d9f 100644
> > >> > --- a/src/egl/drivers/dri2/platform_x11_dri3.h
> > >> > +++ b/src/egl/drivers/dri2/platform_x11_dri3.h
> > >> > @@ -38,7 +38,4 @@ extern struct dri2_egl_display_vtbl
> > >> > dri3_x11_display_vtbl;  EGLBoolean  dri3_x11_connect(struct
> > >> > dri2_egl_display *dri2_dpy);
> > >> >
> > >> > -uint32_t
> > >> > -dri2_format_for_depth(uint32_t depth);
> > >> > -
> > >> >  #endif
> > >> > --
> > >> > 2.17.0
> > >> >
> > >> > ___
> > >> > mesa-dev mailing list
> > >> > mesa-dev@lists.freedesktop.org
> > >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Daniel Stone]

On 29 May 2018 at 15:17, Eric Engestrom  wrote:
> On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
>> GL_LIB expands to GLX_mesa, but applications should not link against
>> that. -lGL is never wrong, just hardcode it.
>
> Agreed, and Archlinux has had this patch since basically forever:
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa

Ugh. There's also this patch from February doing a similar thing:
https://patchwork.freedesktop.org/patch/206547/

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

[Mesa-dev] [Bug 106472] Some applications randomly stuck under xorg server 1.20 (and rc's) for example steam client

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Version|unspecified |18.0
 QA Contact|xorg-t...@lists.x.org   |mesa-dev@lists.freedesktop.
   ||org
Product|Wayland |Mesa
  Component|XWayland|Mesa core
 Resolution|--- |FIXED
   Assignee|wayland-bugs@lists.freedesk |mesa-dev@lists.freedesktop.
   |top.org |org
 Status|NEW |RESOLVED

--- Comment #2 from Michel Dänzer  ---
Should be fixed with
https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458
.

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

[Mesa-dev] [PATCH mesa 2/3] egl: remove wayland-egl now that we're using libwayland-egl

[Eric Engestrom]

Cc: Emil Velikov 
Cc: Daniel Stone 
Signed-off-by: Eric Engestrom 
---
 src/egl/wayland/wayland-egl/Makefile.am   |  24 --
 src/egl/wayland/wayland-egl/meson.build   |  50 
 .../wayland-egl/wayland-egl-abi-check.c   | 235 --
 .../wayland/wayland-egl/wayland-egl-backend.h |  63 -
 .../wayland-egl/wayland-egl-symbols-check |  24 --
 src/egl/wayland/wayland-egl/wayland-egl.c | 109 
 src/egl/wayland/wayland-egl/wayland-egl.pc.in |  11 -
 7 files changed, 516 deletions(-)
 delete mode 100644 src/egl/wayland/wayland-egl/Makefile.am
 delete mode 100644 src/egl/wayland/wayland-egl/meson.build
 delete mode 100644 src/egl/wayland/wayland-egl/wayland-egl-abi-check.c
 delete mode 100644 src/egl/wayland/wayland-egl/wayland-egl-backend.h
 delete mode 100755 src/egl/wayland/wayland-egl/wayland-egl-symbols-check
 delete mode 100644 src/egl/wayland/wayland-egl/wayland-egl.c
 delete mode 100644 src/egl/wayland/wayland-egl/wayland-egl.pc.in

diff --git a/src/egl/wayland/wayland-egl/Makefile.am 
b/src/egl/wayland/wayland-egl/Makefile.am
deleted file mode 100644
index 31dcca9e10f99a4a7e1b..
--- a/src/egl/wayland/wayland-egl/Makefile.am
+++ /dev/null
@@ -1,24 +0,0 @@
-pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = wayland-egl.pc
-
-AM_CFLAGS = $(DEFINES) \
-   $(VISIBILITY_CFLAGS) \
-   $(WAYLAND_CLIENT_CFLAGS)
-
-lib_LTLIBRARIES = libwayland-egl.la
-noinst_HEADERS = wayland-egl-backend.h
-libwayland_egl_la_SOURCES = wayland-egl.c
-libwayland_egl_la_LDFLAGS = \
-   -no-undefined \
-   -version-info 1 \
-   $(GC_SECTIONS) \
-   $(LD_NO_UNDEFINED)
-
-TESTS = wayland-egl-symbols-check \
-wayland-egl-abi-check
-
-EXTRA_DIST = wayland-egl-symbols-check meson.build
-
-check_PROGRAMS = wayland-egl-abi-check
-
-include $(top_srcdir)/install-lib-links.mk
diff --git a/src/egl/wayland/wayland-egl/meson.build 
b/src/egl/wayland/wayland-egl/meson.build
deleted file mode 100644
index d0a7521da915580a6a7c..
--- a/src/egl/wayland/wayland-egl/meson.build
+++ /dev/null
@@ -1,50 +0,0 @@
-# Copyright © 2017 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 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.
-
-
-libwayland_egl = shared_library(
-  'wayland-egl',
-  'wayland-egl.c',
-  c_args : [c_vis_args],
-  link_args : ld_args_gc_sections,
-  dependencies : dep_wayland_client,
-  version : '1.0.0',
-  install : true,
-)
-
-pkg.generate(
-  name : 'wayland-egl',
-  description : 'Mesa wayland-egl library',
-  libraries : libwayland_egl,
-  version : meson.project_version(),
-  requires : 'wayland-client',
-)
-
-if with_tests
-  test('wayland-egl-symbols-check',
-find_program('wayland-egl-symbols-check'),
-env : env_test,
-args : libwayland_egl
-  )
-  test(
-'wayland-egl-abi-check',
-executable('wayland-egl-abi-check', 'wayland-egl-abi-check.c')
-  )
-endif
diff --git a/src/egl/wayland/wayland-egl/wayland-egl-abi-check.c 
b/src/egl/wayland/wayland-egl/wayland-egl-abi-check.c
deleted file mode 100644
index 62c51a22605b1b4c8457..
--- a/src/egl/wayland/wayland-egl/wayland-egl-abi-check.c
+++ /dev/null
@@ -1,235 +0,0 @@
-/*
- * Copyright (c) 2017, NVIDIA CORPORATION. All rights reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including 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 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 WAR

[Mesa-dev] [PATCH mesa 1/3] egl: rewire the build systems to use libwayland-egl

[Eric Engestrom]

Cc: Emil Velikov 
Cc: Daniel Stone 
Signed-off-by: Eric Engestrom 
---
A couple things worth mentioning:
- I chose to add libwayland-egl as a separate dependency for EGL rather
  than bumping the libwayland required version, so that old libwayland
  can still be used if EGL is not needed. I'm happy to squash those if
  we'd rather simply bump the libwayland version.
- There is one non-build-system change in there, in platform_wayland.c,
  because the wayland-egl-backend.h we had and the one in wayland have
  diverged (for C++ compatibility IIRC, which we didn't need). I'm
  thinking it might be best to split this out as a separate change
  before the move in this commit, but it would probably involve so much
  changes (like the testing scripts) that I preferred to just squash it
  in here.
---
 configure.ac   |  6 --
 meson.build|  3 +++
 src/Makefile.am|  5 -
 src/egl/Makefile.am|  3 ++-
 src/egl/drivers/dri2/platform_wayland.c|  7 +++
 src/egl/meson.build| 10 ++
 src/gallium/state_trackers/omx/tizonia/Makefile.am |  2 +-
 7 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/configure.ac b/configure.ac
index 62063c1c8a7690bbea72..b13cbfb8a95b8f21aa4b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -90,6 +90,7 @@ LIBOMXIL_TIZONIA_REQUIRED=0.10.0
 LIBVA_REQUIRED=0.39.0
 VDPAU_REQUIRED=1.1
 WAYLAND_REQUIRED=1.11
+WAYLAND_EGL_REQUIRED=1.15
 WAYLAND_PROTOCOLS_REQUIRED=1.8
 XCB_REQUIRED=1.9.3
 XCBDRI2_REQUIRED=1.8
@@ -1808,6 +1809,9 @@ for plat in $platforms; do
 PKG_CHECK_MODULES([WAYLAND_CLIENT], [wayland-client >= 
$WAYLAND_REQUIRED])
 PKG_CHECK_MODULES([WAYLAND_SERVER], [wayland-server >= 
$WAYLAND_REQUIRED])
 PKG_CHECK_MODULES([WAYLAND_PROTOCOLS], [wayland-protocols >= 
$WAYLAND_PROTOCOLS_REQUIRED])
+if test "x$enable_egl" = xyes; then
+  PKG_CHECK_MODULES([WAYLAND_EGL], [wayland-egl >= 
$WAYLAND_EGL_REQUIRED])
+fi
 WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
 
 PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
@@ -3019,8 +3023,6 @@ AC_CONFIG_FILES([Makefile
  src/egl/Makefile
  src/egl/main/egl.pc
  src/egl/wayland/wayland-drm/Makefile
- src/egl/wayland/wayland-egl/Makefile
- src/egl/wayland/wayland-egl/wayland-egl.pc
  src/gallium/Makefile
  src/gallium/auxiliary/Makefile
  src/gallium/auxiliary/pipe-loader/Makefile
diff --git a/meson.build b/meson.build
index d0cb896163814873eb5f..551dea1371803657ce07 100644
--- a/meson.build
+++ b/meson.build
@@ -1231,6 +1231,9 @@ if with_platform_wayland
   dep_wl_protocols = dependency('wayland-protocols', version : '>= 1.8')
   dep_wayland_client = dependency('wayland-client', version : '>=1.11')
   dep_wayland_server = dependency('wayland-server', version : '>=1.11')
+  if with_egl
+dep_wayland_egl = dependency('wayland-egl', version : '>=1.15')
+  endif
   wayland_dmabuf_xml = join_paths(
 dep_wl_protocols.get_pkgconfig_variable('pkgdatadir'), 'unstable',
 'linux-dmabuf', 'linux-dmabuf-unstable-v1.xml'
diff --git a/src/Makefile.am b/src/Makefile.am
index fd5ae445502c710c726e..9bb3bce3c07717186883 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -95,11 +95,6 @@ if HAVE_GBM
 SUBDIRS += gbm
 endif
 
-## Optionally required by EGL
-if HAVE_PLATFORM_WAYLAND
-SUBDIRS += egl/wayland/wayland-egl
-endif
-
 if HAVE_EGL
 SUBDIRS += egl
 endif
diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 086a4a1e63020caa8c05..be3547d968fb0304414c 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -84,6 +84,8 @@ drivers/dri2/egl_dri2.lo: 
drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.
 AM_CFLAGS += $(WAYLAND_CLIENT_CFLAGS)
 libEGL_common_la_LIBADD += $(WAYLAND_CLIENT_LIBS)
 libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
+AM_CFLAGS += $(WAYLAND_EGL_CFLAGS)
+libEGL_common_la_LIBADD += $(WAYLAND_EGL_LIBS)
 AM_CFLAGS += $(WAYLAND_SERVER_CFLAGS)
 libEGL_common_la_LIBADD += 
$(top_builddir)/src/egl/wayland/wayland-drm/libwayland-drm.la
 libEGL_common_la_LIBADD += $(WAYLAND_SERVER_LIBS)
@@ -114,7 +116,6 @@ AM_CFLAGS += \
-I$(top_builddir)/src/egl/drivers/dri2 \
-I$(top_srcdir)/src/egl/drivers/dri2 \
-I$(top_srcdir)/src/gbm/backends/dri \
-   -I$(top_srcdir)/src/egl/wayland/wayland-egl \
-I$(top_builddir)/src/egl/wayland/wayland-drm \
-I$(top_srcdir)/src/egl/wayland/wayland-drm \
-DDEFAULT_DRIVER_DIR=\"$(DRI_DRIVER_SEARCH_DIR)\" \
diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 63da21cdf557d0dcc3e0..11026f9fbf4ba0ed0749 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platfo

[Mesa-dev] [PATCH mesa 3/3] docs: add note about moving to libwayland-egl in 18.2.0

[Eric Engestrom]

Cc: Emil Velikov 
Cc: Daniel Stone 
Cc: Andres Gomez 
Cc: Dylan Baker 
Signed-off-by: Eric Engestrom 
---
 docs/relnotes/18.2.0.html | 8 
 1 file changed, 8 insertions(+)

diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
index 00b253c076fd0f5bef00..94bc17e0082ce6f22fa2 100644
--- a/docs/relnotes/18.2.0.html
+++ b/docs/relnotes/18.2.0.html
@@ -30,6 +30,13 @@ Mesa 18.2.0 Release Notes / TBD
 Compatibility contexts may report a lower version depending on each driver.
 
 
+
+libwayland-egl is now distributed by libwayland (since 1.15,
+https://lists.freedesktop.org/archives/wayland-devel/2018-April/037767.html";>see
 announcement),
+and has been removed from Mesa in this release. Make sure you're using
+an up-to-date version of libwayland to keep the functionality.
+
+
 
 SHA256 checksums
 
@@ -57,6 +64,7 @@ Changes
 
 
 Removed GL_EXT_polygon_offset applications should use glPolygonOffset 
instead.
+Removed libwayland-egl, now part of libwayland
 
 
 
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [1/3] tegra: Remove usage of non-stable UAPI

[Thierry Reding]

On Tue, May 29, 2018 at 12:46:35PM +0200, Daniel Kolesa wrote:
> Hello,
> 
> On 2018/04/19 18:31, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This code path is no longer required with framebuffer modifier support.
> 
> This patch series fixes Xorg 1.20 startup (since 1.20, it does not modeset
> with upstream Mesa tegra driver unless xserver commit c8c276c9 is reverted)
> as well as the need to revert a patch in the upstream kernel (4ae4b5c0) at
> very least on my Tegra X1 device, therefore:
> 
> Tested-by: Daniel Kolesa 
> 
> It looks to me like a bugfix series, can this get in an 18.1 bugfix release
> or will it have to wait for 18.2?

I've pushed these to the master branch with your Tested-by and a Cc:
mesa-stable tag, so they should find their way into a bugfix release.

Thierry


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] [1/3] tegra: Remove usage of non-stable UAPI

[Daniel Kolesa]

On Tue, May 29, 2018, at 16:50, Thierry Reding wrote:
> On Tue, May 29, 2018 at 12:46:35PM +0200, Daniel Kolesa wrote:
> > Hello,
> > 
> > On 2018/04/19 18:31, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > This code path is no longer required with framebuffer modifier support.
> > 
> > This patch series fixes Xorg 1.20 startup (since 1.20, it does not modeset
> > with upstream Mesa tegra driver unless xserver commit c8c276c9 is reverted)
> > as well as the need to revert a patch in the upstream kernel (4ae4b5c0) at
> > very least on my Tegra X1 device, therefore:
> > 
> > Tested-by: Daniel Kolesa 
> > 
> > It looks to me like a bugfix series, can this get in an 18.1 bugfix release
> > or will it have to wait for 18.2?
> 
> I've pushed these to the master branch with your Tested-by and a Cc:
> mesa-stable tag, so they should find their way into a bugfix release.

Perfect, thanks.

Daniel

> 
> Thierry
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 32/53] intel/fs: Mark LINTERP opcode as writing accumulator on platforms without PLN

[Jason Ekstrand]

On Mon, May 28, 2018 at 10:50 AM, Francisco Jerez 
wrote:

> Jason Ekstrand  writes:
>
> > On Sat, May 26, 2018 at 6:33 PM, Francisco Jerez 
> > wrote:
> >
> >> Jason Ekstrand  writes:
> >>
> >> > On Sat, May 26, 2018 at 3:36 PM, Francisco Jerez <
> curroje...@riseup.net>
> >> > wrote:
> >> >
> >> >> Jason Ekstrand  writes:
> >> >>
> >> >> > On Sat, May 26, 2018 at 2:03 PM, Francisco Jerez <
> >> curroje...@riseup.net>
> >> >> > wrote:
> >> >> >
> >> >> >> Jason Ekstrand  writes:
> >> >> >>
> >> >> >> > On Sat, May 26, 2018 at 12:21 PM, Francisco Jerez <
> >> >> curroje...@riseup.net
> >> >> >> >
> >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> Jason Ekstrand  writes:
> >> >> >> >>
> >> >> >> >> > On Sat, May 26, 2018 at 11:10 AM, Francisco Jerez <
> >> >> >> curroje...@riseup.net
> >> >> >> >> >
> >> >> >> >> > wrote:
> >> >> >> >> >
> >> >> >> >> >> Jason Ekstrand  writes:
> >> >> >> >> >>
> >> >> >> >> >> > From: Francisco Jerez 
> >> >> >> >> >> >
> >> >> >> >> >> > When we don't have PLN (gen4 and gen11+), we implement
> >> LINTERP
> >> >> as
> >> >> >> >> either
> >> >> >> >> >> > LINE+MAC or a pair of MADs.  In both cases, the
> accumulator
> >> is
> >> >> >> written
> >> >> >> >> >> > by the first of the two instructions and read by the
> second.
> >> >> Even
> >> >> >> >> >> > though the accumulator value isn't actually ever used
> from a
> >> >> >> logical
> >> >> >> >> >> > instruction perspective, it is trashed so we need to make
> the
> >> >> >> >> scheduler
> >> >> >> >> >> > aware.  Otherwise, the scheduler could end up re-ordering
> >> >> >> instructions
> >> >> >> >> >> > and putting a LINTERP between another an instruction which
> >> >> writes
> >> >> >> the
> >> >> >> >> >> > accumulator and another which tries to use that result.
> >> >> >> >> >> >
> >> >> >> >> >> > Cc: mesa-sta...@lists.freedesktop.org
> >> >> >> >> >> > ---
> >> >> >> >> >> >  src/intel/compiler/brw_shader.cpp | 3 ++-
> >> >> >> >> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >> >> >> >> >
> >> >> >> >> >> > diff --git a/src/intel/compiler/brw_shader.cpp
> >> >> >> >> b/src/intel/compiler/brw_
> >> >> >> >> >> shader.cpp
> >> >> >> >> >> > index 141b64e..dfd2c5c 100644
> >> >> >> >> >> > --- a/src/intel/compiler/brw_shader.cpp
> >> >> >> >> >> > +++ b/src/intel/compiler/brw_shader.cpp
> >> >> >> >> >> > @@ -984,7 +984,8 @@ backend_instruction::writes_
> >> >> >> >> accumulator_implicitly(const
> >> >> >> >> >> struct gen_device_info
> >> >> >> >> >> > return writes_accumulator ||
> >> >> >> >> >> >(devinfo->gen < 6 &&
> >> >> >> >> >> > ((opcode >= BRW_OPCODE_ADD && opcode <
> >> >> BRW_OPCODE_NOP)
> >> >> >> ||
> >> >> >> >> >> > -(opcode >= FS_OPCODE_DDX_COARSE && opcode <=
> >> >> >> >> >> FS_OPCODE_LINTERP)));
> >> >> >> >> >> > +(opcode >= FS_OPCODE_DDX_COARSE && opcode <=
> >> >> >> >> >> FS_OPCODE_LINTERP))) ||
> >> >> >> >> >> > +  (opcode == FS_OPCODE_LINTERP &&
> >> !devinfo->has_pln);
> >> >> >> >> >>
> >> >> >> >> >> The devinfo->has_pln condition is technically inaccurate,
> >> because
> >> >> >> even
> >> >> >> >> >> SNB will fall back to the non-PLN path which overwrites the
> >> >> >> accumulator
> >> >> >> >> >> for certain valid IR, which yeah I'm aware is not
> *typically*
> >> >> >> >> >> encountered before this series,
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > I'm pretty sure it's impossible before this series because,
> >> without
> >> >> >> >> SIMD32,
> >> >> >> >> > the barycentric coordinates always start at g2 and get
> >> incremented
> >> >> by
> >> >> >> 2
> >> >> >> >> > every time.  The only other way to get something into the
> >> >> coordinates
> >> >> >> >> > source of the PLN is with a pixel interpolator message.  For
> >> that,
> >> >> the
> >> >> >> >> > register allocator has a workaround to ensure that it's
> >> assigned an
> >> >> >> even
> >> >> >> >> > register on SNB.  One of the early patches in my series
> replaces
> >> >> the
> >> >> >> >> broken
> >> >> >> >> > gen4.5-6 PLN fall-back (it didn't work in SIMD16 because it
> >> assumed
> >> >> >> the
> >> >> >> >> > wrong register layout for coordinates) with an assert and
> >> Jenkins
> >> >> is
> >> >> >> just
> >> >> >> >> > fine with the assert.
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> I know the conditions for the non-PLN fall-back are not
> typically
> >> >> >> >> encountered on Gen5-6, but it's still valid IR, so this
> >> >> implementation
> >> >> >> >> of writes_accumulator_implicitly() relies on the behavior of
> the
> >> >> >> >> register allocator, the NIR-to-i965 translation pass and the
> rest
> >> of
> >> >> the
> >> >> >> >> visitor being exactly what you expect in every possible
> codepath
> >> for
> >> >> >> >> correctness.
> >> >> >> >
> >> >> >> >
> >> >> >> > It's already relied on for correctness because the LINE+MAC
> >> fallback
> >> >> that
> >> >> >> > we had before is wrong in SIMD16 (see patch 33).
> >> >> >> >
> >> >>

Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth prototype.

[Marathe, Yogesh]

> -Original Message-
> From: Engestrom, Eric
> Sent: Tuesday, May 29, 2018 7:48 PM
> To: Marathe, Yogesh 
> Cc: Vinson Lee ; Daniel Stone
> ; Emil Velikov ; Eric
> Engestrom ; ML mesa-dev  d...@lists.freedesktop.org>
> Subject: Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth
> prototype.
> 
> On Tuesday, 2018-05-29 05:21:02 +0100, Marathe, Yogesh wrote:
> > Hi Vinson, Eric,
> >
> > > -Original Message-
> > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > > Behalf Of Vinson Lee
> > > Sent: Sunday, May 27, 2018 1:34 PM
> > > To: Engestrom, Eric 
> > > Cc: Daniel Stone ; Emil Velikov
> > > ; Eric Engestrom ;
> > > Marathe, Yogesh ; ML mesa-dev  > > d...@lists.freedesktop.org>
> > > Subject: Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth
> > > prototype.
> > >
> > > On Fri, May 25, 2018 at 9:42 AM, Eric Engestrom
> > > 
> > > wrote:
> > > > On Friday, 2018-05-25 16:06:26 +0100, Eric Engestrom wrote:
> > > >> On Friday, 2018-05-25 06:52:25 +, Vinson Lee wrote:
> > > >> > Fix build error without DRI3.
> > > >>
> > > >> D'uh!
> > > >> I forgot building dri3 was optional, sorry :/
> > > >>
> > > >> Reviewed-by: Eric Engestrom 
> > > >
> > > > Actually, wait no, this doesn't look right, the function should be
> > > > named something else if it's exposed to everyone, since it's quite
> > > > specific to x11's case, or it should not be exposed to everyone.
> > > >
> > > > I feel like the best thing to do here is to just copy the
> > > > prototype to
> > > > platform_x11.c:
> > > >
> > > > ---8<---
> > > > diff --git a/src/egl/drivers/dri2/platform_x11.c
> > > > b/src/egl/drivers/dri2/platform_x11.c
> > > > index b2a3000b252ec0ddb12f..ea9b0cc6d6fd04804d2a 100644
> > > > --- a/src/egl/drivers/dri2/platform_x11.c
> > > > +++ b/src/egl/drivers/dri2/platform_x11.c
> > > > @@ -55,6 +55,9 @@ static EGLBoolean
> > > > dri2_x11_swap_interval(_EGLDriver *drv, _EGLDisplay *disp,
> > > > _EGLSurface
> > > *surf,
> > > > EGLint interval);
> > > >
> > > > +uint32_t
> > > > +dri2_format_for_depth(uint32_t depth); u
> > > >  static void
> > > >  swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
> > > >   struct dri2_egl_surface * dri2_surf)
> > > > --->8---
> > > >
> > >
> > > This also fixes the build error.
> > >
> > > Tested-by: Vinson Lee 
> > >
> >
> > Did we also check dri3 build after this?
> 
> I checked with my usual "everything is enabled" build as well as the default
> meson configuration.
> 
> > I see platform_x11_dri3.c using it and we've removed it from
> > platform_x11_dri3.h, dri2_format_for_depth() prototype with extern in
> > platform_x11_dri3.c shall help?
> 
> I'm not sure I follow, but I think you're talking about adding my inline
> platform_x11.c patch on top of vlee's original patch, which is not what I
> suggested; my suggestion was to replace his patch with mine.
> Does that answer your question?
> 

Yes, I'm good. It means for dri3 prototype still resides in platform_x11_dri3.h 
Sorry, I missed words _just copy_ in your mail. 

Reviewed-by: Yogesh Marathe 

> >
> > If not extern I'm inclining towards better name for the function in
> > egl_dri2.h
> >
> > > >>
> > > >> >
> > > >> >   CC   drivers/dri2/platform_x11.lo
> > > >> > drivers/dri2/platform_x11.c:1010:1: error: no previous
> > > >> > prototype for function 'dri2_format_for_depth'
> > > >> > [-Werror,-Wmissing-prototypes] dri2_format_for_depth(uint32_t
> > > >> > depth) ^
> > > >> >
> > > >> > Fixes: 473af0b541b2 ("egl/x11: deduplicate depth-to-format
> > > >> > logic")
> > > >> > Signed-off-by: Vinson Lee 
> > > >> > ---
> > > >> >  src/egl/drivers/dri2/egl_dri2.h  | 3 +++
> > > >> >  src/egl/drivers/dri2/platform_x11_dri3.h | 3 ---
> > > >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > > >> >
> > > >> > diff --git a/src/egl/drivers/dri2/egl_dri2.h
> > > >> > b/src/egl/drivers/dri2/egl_dri2.h index
> > > >> > adabc527f85b..b91a899e476c
> > > >> > 100644
> > > >> > --- a/src/egl/drivers/dri2/egl_dri2.h
> > > >> > +++ b/src/egl/drivers/dri2/egl_dri2.h
> > > >> > @@ -523,4 +523,7 @@ dri2_init_surface(_EGLSurface *surf,
> > > >> > _EGLDisplay *dpy, EGLint type,  void
> > > >> > dri2_fini_surface(_EGLSurface *surf);
> > > >> >
> > > >> > +uint32_t
> > > >> > +dri2_format_for_depth(uint32_t depth);
> > > >> > +
> > > >> >  #endif /* EGL_DRI2_INCLUDED */ diff --git
> > > >> > a/src/egl/drivers/dri2/platform_x11_dri3.h
> > > >> > b/src/egl/drivers/dri2/platform_x11_dri3.h
> > > >> > index e6fd01366978..96e7ee972d9f 100644
> > > >> > --- a/src/egl/drivers/dri2/platform_x11_dri3.h
> > > >> > +++ b/src/egl/drivers/dri2/platform_x11_dri3.h
> > > >> > @@ -38,7 +38,4 @@ extern struct dri2_egl_display_vtbl
> > > >> > dri3_x11_display_vtbl;  EGLBoolean  dri3_x11_connect(struct
> > > >> > dri2_egl_display *dri2_dpy);
> > > >> >
> > > >> > -uint32_t
> > > >> > -dri2_format_for_depth(uint32_t depth);
> > > >> > -
> > > >> >  #endif

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

[Eero Tamminen]

Hi,

On 25.05.2018 00:55, Jason Ekstrand wrote:

This patch series adds back-end compiler support for SIMD32 fragment
shaders.  Support is added and everything works but it's currently hidden
behind INTEL_DEBUG=do32.  We know that it improves performance in some
cases but we do not yet have a good enough heuristic to start turning it on
by default.  The objective of this series is to just to get the compiler
infrastructure landed so that it stops bit-rotting in Curro's branch.


Tested v3 on BXT & SKL.  Everything seems to work otherwise fine.

Tested-by Eero Tamminen 



Figuring out a good heuristic is left as an exercise to the reader. :-)


Simple heuristic that just enables SIMD32 for everything that isn't
MRT shader, gives nice perf improvements on BXT J4205:
* +30% GfxBench ALU2
* +25% SynMark PSPom
* +10% GpuTest Julia32
* +9% GfxBench CarChase
* +7% GfxBench Manhattan 3.0
* +3-7% GLB T-Rex, SynMark ShMapVsm, GpuTest Triangle
* +1-3% GfxBench Manhattan 3.1 & T-Rex, Unigine Heaven, GpuTest FurMark
* -1-2% GfxBench Aztec Ruins, MemBW Write, SynMark DeferredAA, Fill*, 
VSInstancing & ZBuffer

* -2-3% GLB 2.7 Fill
* -4-5% MemBW Blend

On SKL, perf differences are smaller.

SIMD32 can cause write bound tests to trash, which is visible as perf
regression in fully write bound tests above (that's also the reason
why SIMD32 is good to disable with MRT shaders).

As to reads, SIMD32 improves cache locality until it starts trashing.
In above GfxBench tests, and amount of texture sampling they do, this
shows in HW counters as increased texture cache misses (trashing), but
less L3 misses (better locality).  Along with (more important) better
latency compensation, these explain why SIMD32 improves performance in
them.


More advanced heuristics that try to avoid the SIMD32 performance
regressions, unfortunately also get rid of clear part of the above
improvements.  Such heuristics would need improved instruction scheduler
that provides feedback on which shaders have latency issues where SIMD32
would help.

(A potential run-time heuristics would be disabling SIMD32 when too
large textures are bound for draw.)


- Eero


Francisco Jerez (34):
   intel/eu: Remove brw_codegen::compressed_stack.
   intel/fs: Rename a local variable so it doesn't shadow component()
   intel/fs: Use the ATTR file for FS inputs
   intel/fs: Replace the CINTERP opcode with a simple MOV
   intel/fs: Add explicit last_rt flag to fb writes orthogonal to eot.
   intel/fs: Fix Gen4-5 FB write AA data payload munging for non-EOT
 writes.
   intel/eu: Return new instruction to caller from brw_fb_WRITE().
   intel/fs: Fix fs_inst::flags_written() for Gen4-5 FB writes.
   intel/fs: Fix implied_mrf_writes() for headerless FB writes.
   intel/fs: Remove program key argument from generator.
   intel/fs: Disable SIMD32 dispatch on Gen4-6 with control flow
   intel/fs: Disable SIMD32 dispatch for fragment shaders with discard.
   intel/eu: Fix pixel interpolator queries for SIMD32.
   intel/fs: Fix codegen of FS_OPCODE_SET_SAMPLE_ID for SIMD32.
   intel/fs: Don't enable dual source blend if no outputs are written
   intel/fs: Fix FB write message control codegen for SIMD32.
   intel/fs: Fix logical FB write lowering for SIMD32
   intel/fs: Fix FB read header setup for SIMD32.
   intel/fs: Rework INTERPOLATE_AT_PER_SLOT_OFFSET
   intel/fs: Mark LINTERP opcode as writing accumulator implicitly on
 pre-Gen7.
   intel/fs: Disable opt_sampler_eot() in 32-wide dispatch.
   i965: Add plumbing for shader time in 32-wide FS dispatch mode.
   intel/fs: Simplify fs_visitor::emit_samplepos_setup
   intel/fs: Use fs_regs instead of brw_regs in the unlit centroid
 workaround
   intel/fs: Wrap FS payload register look-up in a helper function.
   intel/fs: Extend thread payload layout to SIMD32
   intel/fs: Implement 32-wide FS payload setup on Gen6+
   intel/fs: Fix Gen7 compressed source region alignment restriction for
 SIMD32
   intel/fs: Fix sample id setup for SIMD32.
   intel/fs: Generalize the unlit centroid workaround
   intel/fs: Fix Gen6+ interpolation setup for SIMD32
   intel/fs: Fix fs_builder::sample_mask_reg() for 32-wide FS dispatch.
   intel/fs: Fix nir_intrinsic_load_helper_invocation for SIMD32.
   intel/fs: Build 32-wide FS shaders.

Jason Ekstrand (19):
   intel/fs: Assert that the gen4-6 plane restrictions are followed
   intel/fs: Use groups for SIMD16 LINTERP on gen11+
   intel/fs: FS_OPCODE_REP_FB_WRITE has side effects
   intel/fs: Properly track implied header regs read by FB writes
   intel/fs: Pull FB write implied headers from src[0]
   intel/fs: Set up FB write message headers in the visitor
   i965: Re-arrange shader kernel setup in WM state
   intel/compiler: Add and use helpers for working with KSP indices
   intel/fs: Rework KSP data to be SIMD width-based
   intel/fs: Split instructions low to high in lower_simd_width
   intel/fs: Properly copy default flag reg for 3src instrucitons
   intel/fs: Add the gr

Re: [Mesa-dev] [PATCH 00/53] intel/fs: SIMD32 support for fragment shaders

[Eero Tamminen]

Hi,

On 29.05.2018 18:58, Eero Tamminen wrote:

On 25.05.2018 00:55, Jason Ekstrand wrote:

This patch series adds back-end compiler support for SIMD32 fragment
shaders.  Support is added and everything works but it's currently hidden
behind INTEL_DEBUG=do32.  We know that it improves performance in some
cases but we do not yet have a good enough heuristic to start turning 
it on

by default.  The objective of this series is to just to get the compiler
infrastructure landed so that it stops bit-rotting in Curro's branch.


Tested v3 on BXT & SKL.  Everything seems to work otherwise fine.


s/otherwise//


- Eero

(regardless of how many times one reads a mail before sending, there
always seems to be some leftover one misses.)


Tested-by Eero Tamminen 



Figuring out a good heuristic is left as an exercise to the reader. :-)


Simple heuristic that just enables SIMD32 for everything that isn't
MRT shader, gives nice perf improvements on BXT J4205:
* +30% GfxBench ALU2
* +25% SynMark PSPom
* +10% GpuTest Julia32
* +9% GfxBench CarChase
* +7% GfxBench Manhattan 3.0
* +3-7% GLB T-Rex, SynMark ShMapVsm, GpuTest Triangle
* +1-3% GfxBench Manhattan 3.1 & T-Rex, Unigine Heaven, GpuTest FurMark
* -1-2% GfxBench Aztec Ruins, MemBW Write, SynMark DeferredAA, Fill*, 
VSInstancing & ZBuffer

* -2-3% GLB 2.7 Fill
* -4-5% MemBW Blend

On SKL, perf differences are smaller.

SIMD32 can cause write bound tests to trash, which is visible as perf
regression in fully write bound tests above (that's also the reason
why SIMD32 is good to disable with MRT shaders).

As to reads, SIMD32 improves cache locality until it starts trashing.
In above GfxBench tests, and amount of texture sampling they do, this
shows in HW counters as increased texture cache misses (trashing), but
less L3 misses (better locality).  Along with (more important) better
latency compensation, these explain why SIMD32 improves performance in
them.


More advanced heuristics that try to avoid the SIMD32 performance
regressions, unfortunately also get rid of clear part of the above
improvements.  Such heuristics would need improved instruction scheduler
that provides feedback on which shaders have latency issues where SIMD32
would help.

(A potential run-time heuristics would be disabling SIMD32 when too
large textures are bound for draw.)


 - Eero


Francisco Jerez (34):
   intel/eu: Remove brw_codegen::compressed_stack.
   intel/fs: Rename a local variable so it doesn't shadow component()
   intel/fs: Use the ATTR file for FS inputs
   intel/fs: Replace the CINTERP opcode with a simple MOV
   intel/fs: Add explicit last_rt flag to fb writes orthogonal to eot.
   intel/fs: Fix Gen4-5 FB write AA data payload munging for non-EOT
 writes.
   intel/eu: Return new instruction to caller from brw_fb_WRITE().
   intel/fs: Fix fs_inst::flags_written() for Gen4-5 FB writes.
   intel/fs: Fix implied_mrf_writes() for headerless FB writes.
   intel/fs: Remove program key argument from generator.
   intel/fs: Disable SIMD32 dispatch on Gen4-6 with control flow
   intel/fs: Disable SIMD32 dispatch for fragment shaders with discard.
   intel/eu: Fix pixel interpolator queries for SIMD32.
   intel/fs: Fix codegen of FS_OPCODE_SET_SAMPLE_ID for SIMD32.
   intel/fs: Don't enable dual source blend if no outputs are written
   intel/fs: Fix FB write message control codegen for SIMD32.
   intel/fs: Fix logical FB write lowering for SIMD32
   intel/fs: Fix FB read header setup for SIMD32.
   intel/fs: Rework INTERPOLATE_AT_PER_SLOT_OFFSET
   intel/fs: Mark LINTERP opcode as writing accumulator implicitly on
 pre-Gen7.
   intel/fs: Disable opt_sampler_eot() in 32-wide dispatch.
   i965: Add plumbing for shader time in 32-wide FS dispatch mode.
   intel/fs: Simplify fs_visitor::emit_samplepos_setup
   intel/fs: Use fs_regs instead of brw_regs in the unlit centroid
 workaround
   intel/fs: Wrap FS payload register look-up in a helper function.
   intel/fs: Extend thread payload layout to SIMD32
   intel/fs: Implement 32-wide FS payload setup on Gen6+
   intel/fs: Fix Gen7 compressed source region alignment restriction for
 SIMD32
   intel/fs: Fix sample id setup for SIMD32.
   intel/fs: Generalize the unlit centroid workaround
   intel/fs: Fix Gen6+ interpolation setup for SIMD32
   intel/fs: Fix fs_builder::sample_mask_reg() for 32-wide FS dispatch.
   intel/fs: Fix nir_intrinsic_load_helper_invocation for SIMD32.
   intel/fs: Build 32-wide FS shaders.

Jason Ekstrand (19):
   intel/fs: Assert that the gen4-6 plane restrictions are followed
   intel/fs: Use groups for SIMD16 LINTERP on gen11+
   intel/fs: FS_OPCODE_REP_FB_WRITE has side effects
   intel/fs: Properly track implied header regs read by FB writes
   intel/fs: Pull FB write implied headers from src[0]
   intel/fs: Set up FB write message headers in the visitor
   i965: Re-arrange shader kernel setup in WM state
   intel/compiler: Add and use helpers for working with KSP indices
   intel/fs: 

Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth prototype.

[Eric Engestrom]

On Tuesday, 2018-05-29 16:34:48 +0100, Marathe, Yogesh wrote:
> > -Original Message-
> > From: Engestrom, Eric
> > Sent: Tuesday, May 29, 2018 7:48 PM
> > To: Marathe, Yogesh 
> > Cc: Vinson Lee ; Daniel Stone
> > ; Emil Velikov ; Eric
> > Engestrom ; ML mesa-dev  > d...@lists.freedesktop.org>
> > Subject: Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth
> > prototype.
> > 
> > On Tuesday, 2018-05-29 05:21:02 +0100, Marathe, Yogesh wrote:
> > > Hi Vinson, Eric,
> > >
> > > > -Original Message-
> > > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > > > Behalf Of Vinson Lee
> > > > Sent: Sunday, May 27, 2018 1:34 PM
> > > > To: Engestrom, Eric 
> > > > Cc: Daniel Stone ; Emil Velikov
> > > > ; Eric Engestrom ;
> > > > Marathe, Yogesh ; ML mesa-dev  > > > d...@lists.freedesktop.org>
> > > > Subject: Re: [Mesa-dev] [PATCH] egl/x11: Move dri2_format_for_depth
> > > > prototype.
> > > >
> > > > On Fri, May 25, 2018 at 9:42 AM, Eric Engestrom
> > > > 
> > > > wrote:
> > > > > On Friday, 2018-05-25 16:06:26 +0100, Eric Engestrom wrote:
> > > > >> On Friday, 2018-05-25 06:52:25 +, Vinson Lee wrote:
> > > > >> > Fix build error without DRI3.
> > > > >>
> > > > >> D'uh!
> > > > >> I forgot building dri3 was optional, sorry :/
> > > > >>
> > > > >> Reviewed-by: Eric Engestrom 
> > > > >
> > > > > Actually, wait no, this doesn't look right, the function should be
> > > > > named something else if it's exposed to everyone, since it's quite
> > > > > specific to x11's case, or it should not be exposed to everyone.
> > > > >
> > > > > I feel like the best thing to do here is to just copy the
> > > > > prototype to
> > > > > platform_x11.c:
> > > > >
> > > > > ---8<---
> > > > > diff --git a/src/egl/drivers/dri2/platform_x11.c
> > > > > b/src/egl/drivers/dri2/platform_x11.c
> > > > > index b2a3000b252ec0ddb12f..ea9b0cc6d6fd04804d2a 100644
> > > > > --- a/src/egl/drivers/dri2/platform_x11.c
> > > > > +++ b/src/egl/drivers/dri2/platform_x11.c
> > > > > @@ -55,6 +55,9 @@ static EGLBoolean
> > > > > dri2_x11_swap_interval(_EGLDriver *drv, _EGLDisplay *disp,
> > > > > _EGLSurface
> > > > *surf,
> > > > > EGLint interval);
> > > > >
> > > > > +uint32_t
> > > > > +dri2_format_for_depth(uint32_t depth); u
> > > > >  static void
> > > > >  swrastCreateDrawable(struct dri2_egl_display * dri2_dpy,
> > > > >   struct dri2_egl_surface * dri2_surf)
> > > > > --->8---
> > > > >
> > > >
> > > > This also fixes the build error.
> > > >
> > > > Tested-by: Vinson Lee 
> > > >
> > >
> > > Did we also check dri3 build after this?
> > 
> > I checked with my usual "everything is enabled" build as well as the default
> > meson configuration.
> > 
> > > I see platform_x11_dri3.c using it and we've removed it from
> > > platform_x11_dri3.h, dri2_format_for_depth() prototype with extern in
> > > platform_x11_dri3.c shall help?
> > 
> > I'm not sure I follow, but I think you're talking about adding my inline
> > platform_x11.c patch on top of vlee's original patch, which is not what I
> > suggested; my suggestion was to replace his patch with mine.
> > Does that answer your question?
> > 
> 
> Yes, I'm good. It means for dri3 prototype still resides in 
> platform_x11_dri3.h 
> Sorry, I missed words _just copy_ in your mail. 
> 
> Reviewed-by: Yogesh Marathe 

Thanks; pushed as 1945231b48df8ffcfa2e "egl/x11: fix build with DRI3 disabled"

> 
> > >
> > > If not extern I'm inclining towards better name for the function in
> > > egl_dri2.h
> > >
> > > > >>
> > > > >> >
> > > > >> >   CC   drivers/dri2/platform_x11.lo
> > > > >> > drivers/dri2/platform_x11.c:1010:1: error: no previous
> > > > >> > prototype for function 'dri2_format_for_depth'
> > > > >> > [-Werror,-Wmissing-prototypes] dri2_format_for_depth(uint32_t
> > > > >> > depth) ^
> > > > >> >
> > > > >> > Fixes: 473af0b541b2 ("egl/x11: deduplicate depth-to-format
> > > > >> > logic")
> > > > >> > Signed-off-by: Vinson Lee 
> > > > >> > ---
> > > > >> >  src/egl/drivers/dri2/egl_dri2.h  | 3 +++
> > > > >> >  src/egl/drivers/dri2/platform_x11_dri3.h | 3 ---
> > > > >> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > > > >> >
> > > > >> > diff --git a/src/egl/drivers/dri2/egl_dri2.h
> > > > >> > b/src/egl/drivers/dri2/egl_dri2.h index
> > > > >> > adabc527f85b..b91a899e476c
> > > > >> > 100644
> > > > >> > --- a/src/egl/drivers/dri2/egl_dri2.h
> > > > >> > +++ b/src/egl/drivers/dri2/egl_dri2.h
> > > > >> > @@ -523,4 +523,7 @@ dri2_init_surface(_EGLSurface *surf,
> > > > >> > _EGLDisplay *dpy, EGLint type,  void
> > > > >> > dri2_fini_surface(_EGLSurface *surf);
> > > > >> >
> > > > >> > +uint32_t
> > > > >> > +dri2_format_for_depth(uint32_t depth);
> > > > >> > +
> > > > >> >  #endif /* EGL_DRI2_INCLUDED */ diff --git
> > > > >> > a/src/egl/drivers/dri2/platform_x11_dri3.h
> > > > >> > b/src/egl/drivers/dri2/platform_x11_dri3.h
> > > > >> > index e6fd01366978..96e7ee972d9f 100644
> > 

[Mesa-dev] [PATCH mesa] anv: return true only if all the writes succeed, not just the last one

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 src/intel/vulkan/anv_pipeline_cache.c | 38 +--
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline_cache.c 
b/src/intel/vulkan/anv_pipeline_cache.c
index 82551e9f81f293ecadbe..6c0edaf1ec1b773802e1 100644
--- a/src/intel/vulkan/anv_pipeline_cache.c
+++ b/src/intel/vulkan/anv_pipeline_cache.c
@@ -96,29 +96,29 @@ static bool
 anv_shader_bin_write_to_blob(const struct anv_shader_bin *shader,
  struct blob *blob)
 {
-   bool ok;
+   bool ok = true;
 
-   ok = blob_write_uint32(blob, shader->key->size);
-   ok = blob_write_bytes(blob, shader->key->data, shader->key->size);
+   ok &= blob_write_uint32(blob, shader->key->size);
+   ok &= blob_write_bytes(blob, shader->key->data, shader->key->size);
 
-   ok = blob_write_uint32(blob, shader->kernel_size);
-   ok = blob_write_bytes(blob, shader->kernel.map, shader->kernel_size);
+   ok &= blob_write_uint32(blob, shader->kernel_size);
+   ok &= blob_write_bytes(blob, shader->kernel.map, shader->kernel_size);
 
-   ok = blob_write_uint32(blob, shader->prog_data_size);
-   ok = blob_write_bytes(blob, shader->prog_data, shader->prog_data_size);
-   ok = blob_write_bytes(blob, shader->prog_data->param,
-   shader->prog_data->nr_params *
-   sizeof(*shader->prog_data->param));
+   ok &= blob_write_uint32(blob, shader->prog_data_size);
+   ok &= blob_write_bytes(blob, shader->prog_data, shader->prog_data_size);
+   ok &= blob_write_bytes(blob, shader->prog_data->param,
+shader->prog_data->nr_params *
+sizeof(*shader->prog_data->param));
 
-   ok = blob_write_uint32(blob, shader->bind_map.surface_count);
-   ok = blob_write_uint32(blob, shader->bind_map.sampler_count);
-   ok = blob_write_uint32(blob, shader->bind_map.image_count);
-   ok = blob_write_bytes(blob, shader->bind_map.surface_to_descriptor,
-   shader->bind_map.surface_count *
-   
sizeof(*shader->bind_map.surface_to_descriptor));
-   ok = blob_write_bytes(blob, shader->bind_map.sampler_to_descriptor,
-   shader->bind_map.sampler_count *
-   
sizeof(*shader->bind_map.sampler_to_descriptor));
+   ok &= blob_write_uint32(blob, shader->bind_map.surface_count);
+   ok &= blob_write_uint32(blob, shader->bind_map.sampler_count);
+   ok &= blob_write_uint32(blob, shader->bind_map.image_count);
+   ok &= blob_write_bytes(blob, shader->bind_map.surface_to_descriptor,
+shader->bind_map.surface_count *
+
sizeof(*shader->bind_map.surface_to_descriptor));
+   ok &= blob_write_bytes(blob, shader->bind_map.sampler_to_descriptor,
+shader->bind_map.sampler_count *
+
sizeof(*shader->bind_map.sampler_to_descriptor));
 
return ok;
 }
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH] nv50/ir, nvc0: add debug options for shader replacement

[Rhys Perry]

Changes in v4:
- Move code to nv50_ir_dump.cpp
- Dump headers of nvc0 programs
- Use CRC-32 instead of a truncated SHA1
- Set prog->maxGPR to targ->getFileSize() - 1 and set prog->tlsSize
- Don't compile the program if a replacement is offered
This has the consequence that a program is not dumped when it's replaced
Changes in v3:
- Fixed messed up patch description and diff
- Use the checksum of the TGSI instead of the binary if possible
Changes in v2:
- move "#ifdef DEBUG" from above dumpProgram to above createDumpFilename

The NV50_PROG_DUMP environment variable specifies a (already created)
directory to dump shader binaries, headers and tgsi code. The
NV50_PROG_REPLACE environment variable specifies a (already created)
directory that is searched to find replacement binaries and headers. This
is all much like MESA_SHADER_DUMP_PATH and MESA_SHADER_READ_PATH expect
using CRC-32 checksums instead of program IDs and chip-specific binaries
instead of GLSL.

Signed-off-by: Rhys Perry 
---
 src/gallium/auxiliary/tgsi/tgsi_util.h |   1 +
 src/gallium/drivers/nouveau/Makefile.sources   |   2 +
 src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  40 +++--
 .../drivers/nouveau/codegen/nv50_ir_driver.h   |   1 +
 .../drivers/nouveau/codegen/nv50_ir_dump.cpp   | 171 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_dump.h |  70 +
 src/gallium/drivers/nouveau/meson.build|   2 +
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c| 138 +++--
 8 files changed, 360 insertions(+), 65 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/codegen/nv50_ir_dump.cpp
 create mode 100644 src/gallium/drivers/nouveau/codegen/nv50_ir_dump.h

diff --git a/src/gallium/auxiliary/tgsi/tgsi_util.h 
b/src/gallium/auxiliary/tgsi/tgsi_util.h
index 686b90f467..81cf955d8f 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_util.h
+++ b/src/gallium/auxiliary/tgsi/tgsi_util.h
@@ -28,6 +28,7 @@
 #ifndef TGSI_UTIL_H
 #define TGSI_UTIL_H
 
+#include "pipe/p_compiler.h"
 #include "pipe/p_shader_tokens.h"
 
 #if defined __cplusplus
diff --git a/src/gallium/drivers/nouveau/Makefile.sources 
b/src/gallium/drivers/nouveau/Makefile.sources
index 65f08c7d8d..e867221818 100644
--- a/src/gallium/drivers/nouveau/Makefile.sources
+++ b/src/gallium/drivers/nouveau/Makefile.sources
@@ -114,6 +114,8 @@ NV50_CODEGEN_SOURCES := \
codegen/nv50_ir_build_util.cpp \
codegen/nv50_ir_build_util.h \
codegen/nv50_ir_driver.h \
+   codegen/nv50_ir_dump.cpp \
+   codegen/nv50_ir_dump.h \
codegen/nv50_ir_emit_nv50.cpp \
codegen/nv50_ir_from_tgsi.cpp \
codegen/nv50_ir_graph.cpp \
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index c987da9908..b1782bb4f2 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -23,6 +23,7 @@
 #include "codegen/nv50_ir.h"
 #include "codegen/nv50_ir_target.h"
 #include "codegen/nv50_ir_driver.h"
+#include "codegen/nv50_ir_dump.h"
 
 extern "C" {
 #include "nouveau_debug.h"
@@ -1244,30 +1245,35 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
   prog->print();
 
targ->parseDriverInfo(info);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
 
-   prog->convertToSSA();
+   if (!nv50_ir::replaceProgramCode(prog)) {
+  prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
 
-   if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)
-  prog->print();
+  prog->convertToSSA();
 
-   prog->optimizeSSA(info->optLevel);
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
+  if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)
+ prog->print();
 
-   if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
-  prog->print();
+  prog->optimizeSSA(info->optLevel);
+  prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_SSA);
 
-   if (!prog->registerAllocation()) {
-  ret = -4;
-  goto out;
-   }
-   prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
+  if (prog->dbgFlags & NV50_IR_DEBUG_BASIC)
+ prog->print();
 
-   prog->optimizePostRA(info->optLevel);
+  if (!prog->registerAllocation()) {
+ ret = -4;
+ goto out;
+  }
+  prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_POST_RA);
 
-   if (!prog->emitBinary(info)) {
-  ret = -5;
-  goto out;
+  prog->optimizePostRA(info->optLevel);
+
+  if (!prog->emitBinary(info)) {
+ ret = -5;
+ goto out;
+  }
+
+  nv50_ir::dumpProgramCodeAndIR(prog);
}
 
 out:
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index 3d0782f86b..9c23c74628 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -93,6 +93,7 @@ struct nv50_ir_prog_in

Re: [Mesa-dev] [PATCH v2 4/4] i965: Require softpin support for Cannonlake and later.

[Jordan Justen]

3-4 Reviewed-by: Jordan Justen 

On 2018-05-27 21:35:43, Kenneth Graunke wrote:
> This isn't strictly necessary, but anyone running Cannonlake will
> already have Kernel 4.5 or later, so there's no reason to support
> the relocation model on Gen10+.
> 
> This will let us avoid dealing with them for new features.
> 
> Reviewed-by: Scott D Phillips 
> ---
>  src/mesa/drivers/dri/i965/brw_bufmgr.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 80bfc7c75db..2fb0a4453ff 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -1738,6 +1738,16 @@ brw_bufmgr_init(struct gen_device_info *devinfo, int 
> fd)
>  4096, _4GB);
>   util_vma_heap_init(&bufmgr->vma_allocator[BRW_MEMZONE_OTHER],
>  1 * _4GB, gtt_size - 1 * _4GB);
> +  } else if (devinfo->gen >= 10) {
> + /* Softpin landed in 4.5, but GVT used an aliasing PPGTT until
> +  * kernel commit 6b3816d69628becb7ff35978aa0751798b4a940a in
> +  * 4.14.  Gen10+ GVT hasn't landed yet, so it's not actually a
> +  * problem - but extending this requirement back to earlier gens
> +  * might actually mean requiring 4.14.
> +  */
> + fprintf(stderr, "i965 requires softpin (Kernel 4.5) on Gen10+.");
> + free(bufmgr);
> + return NULL;
>}
> }
>  
> -- 
> 2.17.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Only emit VF cache invalidations when the high bits changes

[Chris Wilson]

Commit 92f01fc5f914 ("i965: Emit VF cache invalidates for 48-bit
addressing bugs with softpin.") tried to only emit the VF invalidate if
the high bits changed, but it accidentally always set need_invalidate to
true; causing it to emit unconditionally emit the pipe control before
every primitive.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106708
Cc: Kenneth Graunke 
Cc: Scott D Phillips 
Cc: Eero Tamminen 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index b485e2cf811..88fde9d12fd 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -504,7 +504,7 @@ static void
 vf_invalidate_for_vb_48bit_transitions(struct brw_context *brw)
 {
 #if GEN_GEN >= 8
-   bool need_invalidate = true;
+   bool need_invalidate = false;
unsigned i;
 
for (i = 0; i < brw->vb.nr_buffers; i++) {
-- 
2.17.0

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

[Mesa-dev] [Bug 106673] [bisected] Steam is unusable since commit 5c33e8c7

[bugzilla-daemon]

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

--- Comment #2 from Alexandre Demers  ---
(In reply to Timothy Arceri from comment #1)
> I assume you mean when using the NIR backend? Anyway I've pushed the revert
> of this change as it was breaking other drivers also.

Obviously. I'll test it later today. Thank you.

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

Re: [Mesa-dev] [PATCH v2 4/5] nvc0: add support for programmable sample locations

[Rhys Perry]

EvaluateDepthValuesARB()/ResolveDepthValuesNV() is a hint for the
driver to decompress the depth buffer if needed. This can be needed
because the decompressed result can depend on the current sample
locations.

Fiddling around with the current state of the patches, I could not
find a case where it seemed that compressed depth values depended
on the sample locations. I figured the depth values in the test were
rather compressible, but I don't know any details about Nvidia's
depth compression.

I wouldn't mind running a trace of the blob and see if it does
anything though, if you want to be more sure.

As for the MS=1 thing, it's for the unlikely case that someone wants
to create a single sample texture through some other API than OpenGL
or just direct gallium and wants to program the sample locations.
It doesn't matter much, though I think it's pretty harmless.

On Mon, May 28, 2018 at 9:05 PM, Ilia Mirkin  wrote:
> ARB_sample_locaitons has all this stuff about a resolve of some sort
> when you switch around the locations. I don't see anything here about
> that. Thoughts?
>
> Also some more specific comments inline:
>
> On Thu, May 10, 2018 at 12:28 PM, Rhys Perry  wrote:
>> Signed-off-by: Rhys Perry 
>> ---
>>  .../drivers/nouveau/codegen/nv50_ir_driver.h   |   2 +
>>  .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp  |   7 +
>>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp  |  91 +--
>>  .../nouveau/codegen/nv50_ir_lowering_nvc0.h|   2 +
>>  src/gallium/drivers/nouveau/nv50/nv50_miptree.c|   1 +
>>  src/gallium/drivers/nouveau/nv50/nv50_resource.h   |   1 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_context.h|  15 +-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c|   1 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c|   3 +
>>  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |  33 +++-
>>  src/gallium/drivers/nouveau/nvc0/nvc0_state.c  |  17 +-
>>  .../drivers/nouveau/nvc0/nvc0_state_validate.c | 174 
>> +
>>  12 files changed, 301 insertions(+), 46 deletions(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
>> index 3d0782f86b..7c835ceab8 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
>> @@ -73,6 +73,7 @@ struct nv50_ir_prog_symbol
>>  #define NVISA_GK104_CHIPSET0xe0
>>  #define NVISA_GK20A_CHIPSET0xea
>>  #define NVISA_GM107_CHIPSET0x110
>> +#define NVISA_GM200_CHIPSET0x120
>>
>>  struct nv50_ir_prog_info
>>  {
>> @@ -145,6 +146,7 @@ struct nv50_ir_prog_info
>>   bool persampleInvocation;
>>   bool usesSampleMaskIn;
>>   bool readsFramebuffer;
>> + bool readsSampleLocations;
>>} fp;
>>struct {
>>   uint32_t inputOffset; /* base address for user args */
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> index 3c5bad05fe..d7844d7381 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp
>> @@ -1520,6 +1520,10 @@ void Source::scanInstructionSrc(const Instruction& 
>> insn,
>>   info->out[src.getIndex(0)].oread = 1;
>>}
>> }
>> +   if (src.getFile() == TGSI_FILE_SYSTEM_VALUE) {
>> +  if (info->sv[src.getIndex(0)].sn == TGSI_SEMANTIC_SAMPLEPOS)
>> + info->prop.fp.readsSampleLocations = true;
>> +   }
>> if (src.getFile() != TGSI_FILE_INPUT)
>>return;
>>
>> @@ -1560,6 +1564,9 @@ bool Source::scanInstruction(const struct 
>> tgsi_full_instruction *inst)
>> if (insn.getOpcode() == TGSI_OPCODE_FBFETCH)
>>info->prop.fp.readsFramebuffer = true;
>>
>> +   if (insn.getOpcode() == TGSI_OPCODE_INTERP_SAMPLE)
>> +  info->prop.fp.readsSampleLocations = true;
>> +
>> if (insn.dstCount()) {
>>Instruction::DstRegister dst = insn.getDst(0);
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> index 29f674b451..5f5298777e 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
>> @@ -2662,17 +2662,33 @@ NVC0LoweringPass::handleRDSV(Instruction *i)
>>ld->subOp = NV50_IR_SUBOP_PIXLD_SAMPLEID;
>>break;
>> case SV_SAMPLE_POS: {
>> -  Value *off = new_LValue(func, FILE_GPR);
>> -  ld = bld.mkOp1(OP_PIXLD, TYPE_U32, i->getDef(0), bld.mkImm(0));
>> +  Value *sampleID = bld.getScratch();
>> +  ld = bld.mkOp1(OP_PIXLD, TYPE_U32, sampleID, bld.mkImm(0));
>>ld->subOp = NV50_IR_SUBOP_PIXLD_SAMPLEID;
>> -  bld.mkOp2(OP_SHL, TYPE_U32, off, i->getDef(0), bld.mkImm(3));
>> -  bld.mkLoad(TYPE_F32,
>> - i->getDef(0),
>> -

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Dylan Baker]

Quoting Adam Jackson (2018-05-29 06:50:46)
> GL_LIB expands to GLX_mesa, but applications should not link against
> that. -lGL is never wrong, just hardcode it.

Actually There is this really stupid option in the autotools build called
--gl-lib-name. We should remove that.

Emil and I had also discussed that glvnd should provide the gl.pc file when used
instead of mesa. It appears he never got around to that, but it seems like a
useful thing to do.

Dylan

> 
> Signed-off-by: Adam Jackson 
> ---
>  src/mesa/gl.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/gl.pc.in b/src/mesa/gl.pc.in
> index 181724b97b..8c7b7da8d7 100644
> --- a/src/mesa/gl.pc.in
> +++ b/src/mesa/gl.pc.in
> @@ -7,7 +7,7 @@ Name: gl
>  Description: Mesa OpenGL library
>  Requires.private: @GL_PC_REQ_PRIV@
>  Version: @PACKAGE_VERSION@
> -Libs: -L${libdir} -l@GL_LIB@
> +Libs: -L${libdir} -lGL
>  Libs.private: @GL_PC_LIB_PRIV@
>  Cflags: -I${includedir} @GL_PC_CFLAGS@
>  glx_tls: @GLX_TLS@
> -- 
> 2.17.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH mesa] anv: return true only if all the writes succeed, not just the last one

[Jason Ekstrand]

Does this fix something?  If I understand correctly, the first blob_write
to fail will set out_of_memory and all subsequent blob_writes will fail.

On Tue, May 29, 2018 at 9:12 AM, Eric Engestrom 
wrote:

> Signed-off-by: Eric Engestrom 
> ---
>  src/intel/vulkan/anv_pipeline_cache.c | 38 +--
>  1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_pipeline_cache.c b/src/intel/vulkan/anv_
> pipeline_cache.c
> index 82551e9f81f293ecadbe..6c0edaf1ec1b773802e1 100644
> --- a/src/intel/vulkan/anv_pipeline_cache.c
> +++ b/src/intel/vulkan/anv_pipeline_cache.c
> @@ -96,29 +96,29 @@ static bool
>  anv_shader_bin_write_to_blob(const struct anv_shader_bin *shader,
>   struct blob *blob)
>  {
> -   bool ok;
> +   bool ok = true;
>
> -   ok = blob_write_uint32(blob, shader->key->size);
> -   ok = blob_write_bytes(blob, shader->key->data, shader->key->size);
> +   ok &= blob_write_uint32(blob, shader->key->size);
> +   ok &= blob_write_bytes(blob, shader->key->data, shader->key->size);
>
> -   ok = blob_write_uint32(blob, shader->kernel_size);
> -   ok = blob_write_bytes(blob, shader->kernel.map, shader->kernel_size);
> +   ok &= blob_write_uint32(blob, shader->kernel_size);
> +   ok &= blob_write_bytes(blob, shader->kernel.map, shader->kernel_size);
>
> -   ok = blob_write_uint32(blob, shader->prog_data_size);
> -   ok = blob_write_bytes(blob, shader->prog_data, shader->prog_data_size);
> -   ok = blob_write_bytes(blob, shader->prog_data->param,
> -   shader->prog_data->nr_params *
> -   sizeof(*shader->prog_data->param));
> +   ok &= blob_write_uint32(blob, shader->prog_data_size);
> +   ok &= blob_write_bytes(blob, shader->prog_data,
> shader->prog_data_size);
> +   ok &= blob_write_bytes(blob, shader->prog_data->param,
> +shader->prog_data->nr_params *
> +sizeof(*shader->prog_data->param));
>
> -   ok = blob_write_uint32(blob, shader->bind_map.surface_count);
> -   ok = blob_write_uint32(blob, shader->bind_map.sampler_count);
> -   ok = blob_write_uint32(blob, shader->bind_map.image_count);
> -   ok = blob_write_bytes(blob, shader->bind_map.surface_to_descriptor,
> -   shader->bind_map.surface_count *
> -   sizeof(*shader->bind_map.
> surface_to_descriptor));
> -   ok = blob_write_bytes(blob, shader->bind_map.sampler_to_descriptor,
> -   shader->bind_map.sampler_count *
> -   sizeof(*shader->bind_map.
> sampler_to_descriptor));
> +   ok &= blob_write_uint32(blob, shader->bind_map.surface_count);
> +   ok &= blob_write_uint32(blob, shader->bind_map.sampler_count);
> +   ok &= blob_write_uint32(blob, shader->bind_map.image_count);
> +   ok &= blob_write_bytes(blob, shader->bind_map.surface_to_descriptor,
> +shader->bind_map.surface_count *
> +sizeof(*shader->bind_map.
> surface_to_descriptor));
> +   ok &= blob_write_bytes(blob, shader->bind_map.sampler_to_descriptor,
> +shader->bind_map.sampler_count *
> +sizeof(*shader->bind_map.
> sampler_to_descriptor));
>
> return ok;
>  }
> --
> Cheers,
>   Eric
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Gitlab migration

[Mark Janes]

Daniel Stone  writes:

> On 26 May 2018 at 00:47, Mark Janes  wrote:
>
>> I am eager to make Intel CI results more visible.  Can I push our
>> artifacts to an fd.o directory, and have GitLab display them to users as
>> if the build ran on fd.o?  A typical build produces ~500MB of junit test
>> output with ~4M results.
>
> Not currently, though it is on their radar:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/17081
>
> Even if it were though, I don't think parsing a 500MB XML file
> server-side is a particularly good idea; same goes for Piglit's JSON,
> which is nicely human readable but far too verbose to be usable at
> scale. Think about scaling it out to the hundreds of projects (with
> however many repos) hosted by fd.o as a whole; all the forks thereof,
> the platforms and configurations they care about, and the number of
> developers and submissions. Even if we write off the 1.5 petabytes
> required to store results from this year's Mesa commits (ignoring
> pre-commit submissions) as workable, the server load to parse and
> display those results is just not workable for a large public service.

The files would be much smaller without the XML formatting.  Jenkins
parses the XML server-side whenever the website needs to display
results, which is why their implementation is not scalable.

We need something like Android's Cherry tool that stores results in a
database, and displays them to users:

  https://android.googlesource.com/platform/external/cherry

No one here has looked into how scalable that implementation is.  If
anyone has suggestions on how to provide really large test sets in a web
ui, I'm eager to get advice.

I would like to get *something* like this hosted externally, so
developers can get more out of our CI.

> There are some other things we could do though, such as:
>   - share common build configurations, build those for MRs and commits
> providing full feedback to developers for build errors in various
> configurations, and expose them (for a limited time) as downloadable
> artifacts
>   - have Intel Jenkins reuse those builds in order to run its various
> test suites on real hardware
>   - accept and display summary results (e.g. 'all tests successful' or
> a note of which tests regressed, etc)
>   - a link to download a reasonably-compressed result set stored as an
> artifact (e.g. the last 10MB results.tar.xz I got mailed back from the
> Intel CI is fine)
>
> Does that sound like something reasonable to aim for?

Maybe?  I'm not sure how valuable it is to share compiled binaries
between 2 systems.  Compiling is nearly free for us, but our external
network connection is not as good as I'd like.

We can publish matching test artifacts to your system if you think that
would help.

IMO the tarball is not very useful compared to a mature test result UI.
In particular, viewing the history of test results for a mesa branch is
a common use case for figuring out when regressions were introduced.
Unfortunately, we need a scalable implementation...

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

Re: [Mesa-dev] [PATCH v2 32/53] intel/fs: Mark LINTERP opcode as writing accumulator on platforms without PLN

[Francisco Jerez]

Jason Ekstrand  writes:

> On Mon, May 28, 2018 at 10:50 AM, Francisco Jerez 
> wrote:
>
>> Jason Ekstrand  writes:
>>
>> > On Sat, May 26, 2018 at 6:33 PM, Francisco Jerez 
>> > wrote:
>> >
>> >> Jason Ekstrand  writes:
>> >>
>> >> > On Sat, May 26, 2018 at 3:36 PM, Francisco Jerez <
>> curroje...@riseup.net>
>> >> > wrote:
>> >> >
>> >> >> Jason Ekstrand  writes:
>> >> >>
>> >> >> > On Sat, May 26, 2018 at 2:03 PM, Francisco Jerez <
>> >> curroje...@riseup.net>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Jason Ekstrand  writes:
>> >> >> >>
>> >> >> >> > On Sat, May 26, 2018 at 12:21 PM, Francisco Jerez <
>> >> >> curroje...@riseup.net
>> >> >> >> >
>> >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >> Jason Ekstrand  writes:
>> >> >> >> >>
>> >> >> >> >> > On Sat, May 26, 2018 at 11:10 AM, Francisco Jerez <
>> >> >> >> curroje...@riseup.net
>> >> >> >> >> >
>> >> >> >> >> > wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Jason Ekstrand  writes:
>> >> >> >> >> >>
>> >> >> >> >> >> > From: Francisco Jerez 
>> >> >> >> >> >> >
>> >> >> >> >> >> > When we don't have PLN (gen4 and gen11+), we implement
>> >> LINTERP
>> >> >> as
>> >> >> >> >> either
>> >> >> >> >> >> > LINE+MAC or a pair of MADs.  In both cases, the
>> accumulator
>> >> is
>> >> >> >> written
>> >> >> >> >> >> > by the first of the two instructions and read by the
>> second.
>> >> >> Even
>> >> >> >> >> >> > though the accumulator value isn't actually ever used
>> from a
>> >> >> >> logical
>> >> >> >> >> >> > instruction perspective, it is trashed so we need to make
>> the
>> >> >> >> >> scheduler
>> >> >> >> >> >> > aware.  Otherwise, the scheduler could end up re-ordering
>> >> >> >> instructions
>> >> >> >> >> >> > and putting a LINTERP between another an instruction which
>> >> >> writes
>> >> >> >> the
>> >> >> >> >> >> > accumulator and another which tries to use that result.
>> >> >> >> >> >> >
>> >> >> >> >> >> > Cc: mesa-sta...@lists.freedesktop.org
>> >> >> >> >> >> > ---
>> >> >> >> >> >> >  src/intel/compiler/brw_shader.cpp | 3 ++-
>> >> >> >> >> >> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >> >> >> >> >> >
>> >> >> >> >> >> > diff --git a/src/intel/compiler/brw_shader.cpp
>> >> >> >> >> b/src/intel/compiler/brw_
>> >> >> >> >> >> shader.cpp
>> >> >> >> >> >> > index 141b64e..dfd2c5c 100644
>> >> >> >> >> >> > --- a/src/intel/compiler/brw_shader.cpp
>> >> >> >> >> >> > +++ b/src/intel/compiler/brw_shader.cpp
>> >> >> >> >> >> > @@ -984,7 +984,8 @@ backend_instruction::writes_
>> >> >> >> >> accumulator_implicitly(const
>> >> >> >> >> >> struct gen_device_info
>> >> >> >> >> >> > return writes_accumulator ||
>> >> >> >> >> >> >(devinfo->gen < 6 &&
>> >> >> >> >> >> > ((opcode >= BRW_OPCODE_ADD && opcode <
>> >> >> BRW_OPCODE_NOP)
>> >> >> >> ||
>> >> >> >> >> >> > -(opcode >= FS_OPCODE_DDX_COARSE && opcode <=
>> >> >> >> >> >> FS_OPCODE_LINTERP)));
>> >> >> >> >> >> > +(opcode >= FS_OPCODE_DDX_COARSE && opcode <=
>> >> >> >> >> >> FS_OPCODE_LINTERP))) ||
>> >> >> >> >> >> > +  (opcode == FS_OPCODE_LINTERP &&
>> >> !devinfo->has_pln);
>> >> >> >> >> >>
>> >> >> >> >> >> The devinfo->has_pln condition is technically inaccurate,
>> >> because
>> >> >> >> even
>> >> >> >> >> >> SNB will fall back to the non-PLN path which overwrites the
>> >> >> >> accumulator
>> >> >> >> >> >> for certain valid IR, which yeah I'm aware is not
>> *typically*
>> >> >> >> >> >> encountered before this series,
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > I'm pretty sure it's impossible before this series because,
>> >> without
>> >> >> >> >> SIMD32,
>> >> >> >> >> > the barycentric coordinates always start at g2 and get
>> >> incremented
>> >> >> by
>> >> >> >> 2
>> >> >> >> >> > every time.  The only other way to get something into the
>> >> >> coordinates
>> >> >> >> >> > source of the PLN is with a pixel interpolator message.  For
>> >> that,
>> >> >> the
>> >> >> >> >> > register allocator has a workaround to ensure that it's
>> >> assigned an
>> >> >> >> even
>> >> >> >> >> > register on SNB.  One of the early patches in my series
>> replaces
>> >> >> the
>> >> >> >> >> broken
>> >> >> >> >> > gen4.5-6 PLN fall-back (it didn't work in SIMD16 because it
>> >> assumed
>> >> >> >> the
>> >> >> >> >> > wrong register layout for coordinates) with an assert and
>> >> Jenkins
>> >> >> is
>> >> >> >> just
>> >> >> >> >> > fine with the assert.
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> I know the conditions for the non-PLN fall-back are not
>> typically
>> >> >> >> >> encountered on Gen5-6, but it's still valid IR, so this
>> >> >> implementation
>> >> >> >> >> of writes_accumulator_implicitly() relies on the behavior of
>> the
>> >> >> >> >> register allocator, the NIR-to-i965 translation pass and the
>> rest
>> >> of
>> >> >> the
>> >> >> >> >> visitor being exactly what you expect in every possible
>> codepath
>> >> for
>> >> >> >> >> correctness.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> 

Re: [Mesa-dev] [PATCH 3/3] docs/releasing: Add note about using a staging branch

[Emil Velikov]

On 21 May 2018 at 18:34, Dylan Baker  wrote:
> ---
>  docs/releasing.html | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/docs/releasing.html b/docs/releasing.html
> index 07f100caae1..20fc4579a32 100644
> --- a/docs/releasing.html
> +++ b/docs/releasing.html
> @@ -249,6 +249,25 @@ Now go to
>   href="https://bugs.freedesktop.org/editversions.cgi?action=add&product=Mesa";
>  target="_parent">Bugzilla and add the new Mesa version X.Y.
>  
>
> +
> +Use a stanging branch:
> +
> +
> +git checkout X.Y
> +git checkout -b X.Y-proposed
s|X.Y-proposed|wip/X.Y|

IIRC there was some git workflow tips that explicitly mentioned
keeping wip branches for ones that are (or can be) rebased.
An added bonus is that the name is shorter, and perhaps easier to parse ;-)

Other than that, thanks for the neat doc update. With the nitpicks
others have spotted, the series is
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] docs: update release calendar for 18.1 series

[Emil Velikov]

On 25 May 2018 at 10:05, Juan A. Suarez Romero  wrote:
> On Tue, 2018-05-22 at 10:48 -0700, Dylan Baker wrote:
>> This looks good to me. I'm also opened to doing the 18.1.x releases if Emil
>> would rather not do them (and I have been updating my 18.1-proposed branch
>> either way).
>>
>
> I'm fine if you do 18.1.x releases. In fact, I think it would be a good idea 
> if
> the same person takes care of a full release cycle, from feature releases to 
> the
> stable releases.
>
Dylan, thanks for stepping up for 18.1.x.

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

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Emil Velikov]

On 29 May 2018 at 15:29, Daniel Stone  wrote:
> On 29 May 2018 at 15:17, Eric Engestrom  wrote:
>> On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
>>> GL_LIB expands to GLX_mesa, but applications should not link against
>>> that. -lGL is never wrong, just hardcode it.
>>
>> Agreed, and Archlinux has had this patch since basically forever:
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa
>
> Ugh. There's also this patch from February doing a similar thing:
> https://patchwork.freedesktop.org/patch/206547/
>
Almost s/similar/better/ ;-)

Unless I've missed something handful of the patches are still
unreviewed and applicable as-is.
Would have pushed the lot (with the cosmetics spotted by Dylan) yet
last time last few times there were plenty of unhappy people.

You know unreviewed being and all :-\
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

On Tue, 2018-05-29 at 18:35 +0100, Emil Velikov wrote:
> On 29 May 2018 at 15:29, Daniel Stone  wrote:
> > On 29 May 2018 at 15:17, Eric Engestrom  wrote:
> > > On Tuesday, 2018-05-29 09:50:46 -0400, Adam Jackson wrote:
> > > > GL_LIB expands to GLX_mesa, but applications should not link against
> > > > that. -lGL is never wrong, just hardcode it.
> > > 
> > > Agreed, and Archlinux has had this patch since basically forever:
> > > https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-glvnd-fix-gl.pc.patch?h=packages/mesa
> > 
> > Ugh. There's also this patch from February doing a similar thing:
> > https://patchwork.freedesktop.org/patch/206547/
> > 
> 
> Almost s/similar/better/ ;-)
> 
> Unless I've missed something handful of the patches are still
> unreviewed and applicable as-is.
> Would have pushed the lot (with the cosmetics spotted by Dylan) yet
> last time last few times there were plenty of unhappy people.

I put my name down as maintainer for src/glx/ and yet I don't get cc'd
on things...

That series has my:

Reviewed-by: Adam Jackson 

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

Re: [Mesa-dev] [PATCH] radeonsi: set GLC on stores to write-only memory

[Marek Olšák]

On Mon, May 28, 2018 at 3:52 AM, Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> The only effect this has is that written cache lines are immediately
> freed in L1$. We're not going to read the data again, so it's better
> to leave room for other things in the cache.
> ---
>  src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> index f4140bb0e2d..c06d0c6edfa 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
> @@ -714,20 +714,26 @@ static void store_emit_buffer(
> offset = base_offset;
> if (start != 0) {
> offset = LLVMBuildAdd(
> builder, offset,
> LLVMConstInt(ctx->i32, start * 4, 0), "");
> }
>
> emit_data->args[0] = data;
> emit_data->args[3] = offset;
>
> +   if (writeonly_memory) {
> +   /* Set GLC for write-only memory, so that we don't
> +* leave cache lines in L1$. */
> +   emit_data->args[3] = ctx->ac.i1true;
> +   }
> +
> lp_build_intrinsic(
> builder, intrinsic_name, emit_data->dst_type,
> emit_data->args, emit_data->arg_count,
> ac_get_store_intr_attribs(writeonly_memory));
> }
>  }
>
>  static void store_emit_memory(
> struct si_shader_context *ctx,
> struct lp_build_emit_data *emit_data)
> @@ -793,24 +799,28 @@ static void store_emit(
> args.opcode = ac_image_store;
> args.data[0] = emit_data->args[0];
> args.resource = emit_data->args[1];
> memcpy(args.coords, &emit_data->args[2],
> sizeof(args.coords));
> args.dim = ac_image_dim_from_tgsi_target(ctx->screen,
> inst->Memory.Texture);
> args.attributes = ac_get_store_intr_attribs(
> writeonly_memory);
> args.dmask = 0xf;
>

There is one more store above this block, but anyway:

Reviewed-by: Marek Olšák 

Marek


>
> /* Workaround for 8bit/16bit TC L1 write corruption bug on
> SI.
>  * All store opcodes not aligned to a dword are affected.
> +*
> +* Also set GLC for writeonly memory, so that we don't
> leave
> +* cache lines in L1.
>  */
> bool force_glc = ctx->screen->info.chip_class == SI;
> if (force_glc ||
> -   inst->Memory.Qualifier & (TGSI_MEMORY_COHERENT |
> TGSI_MEMORY_VOLATILE))
> +   inst->Memory.Qualifier & (TGSI_MEMORY_COHERENT |
> TGSI_MEMORY_VOLATILE) ||
> +   writeonly_memory)
> args.cache_policy = ac_glc;
>
> emit_data->output[emit_data->chan] =
> ac_build_image_opcode(&ctx->ac, &args);
> }
>  }
>
>  static void atomic_fetch_args(
> struct lp_build_tgsi_context * bld_base,
> struct lp_build_emit_data * emit_data)
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] gallium/winsys: rename DRM_API_HANDLE_* to WINSYS_HANDLE_*

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, May 28, 2018 at 9:26 PM, Dave Airlie  wrote:

> From: Dave Airlie 
>
> This just renames this as we want to add an shm handle which
> isn't really drm related.
>
> Originally by: Marc-André Lureau 
> (airlied: I used this sed script instead)
> This was generated with:
>  git grep -l 'DRM_API_' | xargs sed -i 's/DRM_API_/WINSYS_/g'
> ---
>  src/gallium/auxiliary/renderonly/renderonly.c |  4 +--
>  src/gallium/auxiliary/renderonly/renderonly.h |  2 +-
>  src/gallium/auxiliary/vl/vl_winsys_dri.c  |  2 +-
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c |  4 +--
>  .../drivers/etnaviv/etnaviv_resource.c|  8 ++---
>  src/gallium/drivers/etnaviv/etnaviv_screen.c  |  4 +--
>  .../drivers/freedreno/freedreno_screen.c  | 12 
>  src/gallium/drivers/nouveau/nouveau_screen.c  | 12 
>  src/gallium/drivers/radeonsi/si_texture.c |  2 +-
>  src/gallium/drivers/tegra/tegra_screen.c  |  4 +--
>  src/gallium/drivers/v3d/v3d_resource.c| 10 +++
>  src/gallium/drivers/vc4/vc4_resource.c| 10 +++
>  src/gallium/include/pipe/p_screen.h   |  6 ++--
>  .../include/state_tracker/winsys_handle.h |  6 ++--
>  src/gallium/state_trackers/dri/dri2.c | 30 +--
>  src/gallium/state_trackers/nine/swapchain9.c  |  2 +-
>  src/gallium/state_trackers/va/buffer.c|  2 +-
>  src/gallium/state_trackers/va/surface.c   |  4 +--
>  src/gallium/state_trackers/vdpau/output.c |  2 +-
>  src/gallium/state_trackers/vdpau/surface.c|  2 +-
>  src/gallium/state_trackers/xa/xa_tracker.c|  8 ++---
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 10 +++
>  src/gallium/winsys/i915/drm/i915_drm_buffer.c | 12 
>  src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 14 -
>  src/gallium/winsys/svga/drm/vmw_screen_dri.c  | 14 -
>  .../winsys/svga/drm/vmw_screen_ioctl.c|  6 ++--
>  .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 12 
>  .../winsys/virgl/drm/virgl_drm_winsys.c   | 12 
>  src/mesa/state_tracker/st_cb_memoryobjects.c  |  2 +-
>  src/mesa/state_tracker/st_vdpau.c |  2 +-
>  30 files changed, 110 insertions(+), 110 deletions(-)
>
> diff --git a/src/gallium/auxiliary/renderonly/renderonly.c
> b/src/gallium/auxiliary/renderonly/renderonly.c
> index d31f458845c..f83910a9404 100644
> --- a/src/gallium/auxiliary/renderonly/renderonly.c
> +++ b/src/gallium/auxiliary/renderonly/renderonly.c
> @@ -98,7 +98,7 @@ renderonly_create_kms_dumb_buffer_for_resource(struct
> pipe_resource *rsc,
>
> /* fill in winsys handle */
> memset(out_handle, 0, sizeof(*out_handle));
> -   out_handle->type = DRM_API_HANDLE_TYPE_FD;
> +   out_handle->type = WINSYS_HANDLE_TYPE_FD;
> out_handle->stride = create_dumb.pitch;
>
> err = drmPrimeHandleToFD(ro->kms_fd, create_dumb.handle, O_CLOEXEC,
> @@ -130,7 +130,7 @@ renderonly_create_gpu_import_for_resource(struct
> pipe_resource *rsc,
> boolean status;
> int fd, err;
> struct winsys_handle handle = {
> -  .type = DRM_API_HANDLE_TYPE_FD
> +  .type = WINSYS_HANDLE_TYPE_FD
> };
>
> scanout = CALLOC_STRUCT(renderonly_scanout);
> diff --git a/src/gallium/auxiliary/renderonly/renderonly.h
> b/src/gallium/auxiliary/renderonly/renderonly.h
> index 6a89c29e2ef..a8d6a686ed4 100644
> --- a/src/gallium/auxiliary/renderonly/renderonly.h
> +++ b/src/gallium/auxiliary/renderonly/renderonly.h
> @@ -85,7 +85,7 @@ renderonly_get_handle(struct renderonly_scanout *scanout,
> if (!scanout)
>return FALSE;
>
> -   assert(handle->type == DRM_API_HANDLE_TYPE_KMS);
> +   assert(handle->type == WINSYS_HANDLE_TYPE_KMS);
> handle->handle = scanout->handle;
> handle->stride = scanout->stride;
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri.c
> index 79ebf750cdb..bb1ff504886 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
> @@ -231,7 +231,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen
> *vscreen, void *drawable)
> }
>
> memset(&dri2_handle, 0, sizeof(dri2_handle));
> -   dri2_handle.type = DRM_API_HANDLE_TYPE_SHARED;
> +   dri2_handle.type = WINSYS_HANDLE_TYPE_SHARED;
> dri2_handle.handle = back_left->name;
> dri2_handle.stride = back_left->pitch;
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 8251087f3f9..8e3c4a0e04d 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -271,7 +271,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
>pixmap_buffer_texture = buffer->texture;
> }
> memset(&whandle, 0, sizeof(whandle));
> -   whandle.type= DRM_API_HANDLE_TYPE_FD;
> +   whandle.type= WINSYS_HANDLE_TYPE_FD;
> usage = PIPE_HANDLE_USAGE_EXPLICIT_FLUSH | PIPE_HANDLE_USAGE_READ;
> scrn->b

Re: [Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

[Adam Jackson]

On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote:
> Quoting Adam Jackson (2018-05-29 06:50:46)
> > GL_LIB expands to GLX_mesa, but applications should not link against
> > that. -lGL is never wrong, just hardcode it.
> 
> Actually There is this really stupid option in the autotools build called
> --gl-lib-name. We should remove that.
> 
> Emil and I had also discussed that glvnd should provide the gl.pc file when 
> used
> instead of mesa. It appears he never got around to that, but it seems like a
> useful thing to do.

https://github.com/NVIDIA/libglvnd/pull/86

Branch is a bit stale but better than reinventing everything.

Part of the reason I didn't get much further on that is the question of
distributing the _headers_. It would be a bit awkward if glvnd provided
the library you link to but not the headers defining its interface -
though, I guess no more awkward than the current situation. At any rate
glvnd doesn't install any, and there's no way to generate 
from the Khronos scripts at the moment (it's assumed to be a platform
implementation detail, and the version in Mesa is just handcoded
history).

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

Re: [Mesa-dev] [PATCH] mesa: don't call Driver.TexEnv with invalid arguments

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Tue, May 29, 2018 at 7:24 AM, Tapani Pälli 
wrote:

> Patch skips useless and possibly dangerous calls down to the driver
> in case invalid arguments were given. I noticed this would be happening
> with demo of Darwinia game. AFAIK this does not fix anything but makes
> this path safer and more like how other API functions are implemented.
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/mesa/main/texenv.c | 54 ++
> +---
>  1 file changed, 34 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/main/texenv.c b/src/mesa/main/texenv.c
> index 22fc8da1ca..a69c8dd743 100644
> --- a/src/mesa/main/texenv.c
> +++ b/src/mesa/main/texenv.c
> @@ -103,7 +103,7 @@ set_env_color(struct gl_context *ctx,
>
>
>  /** Set an RGB or A combiner mode/function */
> -static void
> +static bool
>  set_combiner_mode(struct gl_context *ctx,
>struct gl_fixedfunc_texture_unit *texUnit,
>GLenum pname, GLenum mode)
> @@ -144,32 +144,35 @@ set_combiner_mode(struct gl_context *ctx,
>
> if (!legal) {
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", mode);
> -  return;
> +  return false;
> }
>
> switch (pname) {
> case GL_COMBINE_RGB:
>if (texUnit->Combine.ModeRGB == mode)
> - return;
> + return true;
>FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
>texUnit->Combine.ModeRGB = mode;
>break;
>
> case GL_COMBINE_ALPHA:
>if (texUnit->Combine.ModeA == mode)
> - return;
> + return true;
>FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
>texUnit->Combine.ModeA = mode;
>break;
> default:
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
> +  return false;
> }
> +
> +   return true;
>  }
>
>
>
>  /** Set an RGB or A combiner source term */
> -static void
> +static bool
>  set_combiner_source(struct gl_context *ctx,
>  struct gl_fixedfunc_texture_unit *texUnit,
>  GLenum pname, GLenum param)
> @@ -199,13 +202,13 @@ set_combiner_source(struct gl_context *ctx,
>break;
> default:
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
> -  return;
> +  return false;
> }
>
> if ((term == 3) && (ctx->API != API_OPENGL_COMPAT
> || !ctx->Extensions.NV_texture_env_combine4)) {
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
> -  return;
> +  return false;
> }
>
> assert(term < MAX_COMBINER_TERMS);
> @@ -246,7 +249,7 @@ set_combiner_source(struct gl_context *ctx,
>
> if (!legal) {
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", param);
> -  return;
> +  return false;
> }
>
> FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
> @@ -255,11 +258,13 @@ set_combiner_source(struct gl_context *ctx,
>texUnit->Combine.SourceA[term] = param;
> else
>texUnit->Combine.SourceRGB[term] = param;
> +
> +   return true;
>  }
>
>
>  /** Set an RGB or A combiner operand term */
> -static void
> +static bool
>  set_combiner_operand(struct gl_context *ctx,
>   struct gl_fixedfunc_texture_unit *texUnit,
>   GLenum pname, GLenum param)
> @@ -286,13 +291,13 @@ set_combiner_operand(struct gl_context *ctx,
>break;
> default:
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
> -  return;
> +  return false;
> }
>
> if ((term == 3) && (ctx->API != API_OPENGL_COMPAT
> || !ctx->Extensions.NV_texture_env_combine4)) {
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(pname=%s)", pname);
> -  return;
> +  return false;
> }
>
> assert(term < MAX_COMBINER_TERMS);
> @@ -328,7 +333,7 @@ set_combiner_operand(struct gl_context *ctx,
>
> if (!legal) {
>TE_ERROR(GL_INVALID_ENUM, "glTexEnv(param=%s)", param);
> -  return;
> +  return false;
> }
>
> FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
> @@ -337,10 +342,12 @@ set_combiner_operand(struct gl_context *ctx,
>texUnit->Combine.OperandA[term] = param;
> else
>texUnit->Combine.OperandRGB[term] = param;
> +
> +   return true;
>  }
>
>
> -static void
> +static bool
>  set_combiner_scale(struct gl_context *ctx,
> struct gl_fixedfunc_texture_unit *texUnit,
> GLenum pname, GLfloat scale)
> @@ -359,25 +366,28 @@ set_combiner_scale(struct gl_context *ctx,
> else {
>_mesa_error( ctx, GL_INVALID_VALUE,
> "glTexEnv(GL_RGB_SCALE not 1, 2 or 4)" );
> -  return;
> +  return false;
> }
>
> switch (pname) {
> case GL_RGB_SCALE:
>if (texUnit->Combine.ScaleShiftRGB == shift)
> - return;
> + return true;
>FLUSH_VERTICES(ctx, _NEW_TEXTURE_STATE);
>texUnit->Combine.ScaleShiftRGB = shift;
>break;
> case GL_ALPHA_SCALE:
>if (texUnit-

Re: [Mesa-dev] drisw Xshm support

[Adam Jackson]

On Tue, 2018-05-29 at 13:08 +1000, Dave Airlie wrote:
> This is a rebased version of Marc-Andre's patches, I'll put my
> r-b on them but I thought it would be nice to have others have a look.
> 
> The only difference are I added a patch on the end, and the interface
> version is now 4 instead of 3.
> 
> I've also tested it works against an cirrus fbdev packed 24bpp X server.

Thanks for dusting these off. Series is:

Reviewed-by: Adam Jackson 

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

Re: [Mesa-dev] [PATCH] i965: Only emit VF cache invalidations when the high bits changes

[Kenneth Graunke]

On Tuesday, May 29, 2018 9:28:07 AM PDT Chris Wilson wrote:
> Commit 92f01fc5f914 ("i965: Emit VF cache invalidates for 48-bit
> addressing bugs with softpin.") tried to only emit the VF invalidate if
> the high bits changed, but it accidentally always set need_invalidate to
> true; causing it to emit unconditionally emit the pipe control before
> every primitive.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106708
> Cc: Kenneth Graunke 
> Cc: Scott D Phillips 
> Cc: Eero Tamminen 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index b485e2cf811..88fde9d12fd 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -504,7 +504,7 @@ static void
>  vf_invalidate_for_vb_48bit_transitions(struct brw_context *brw)
>  {
>  #if GEN_GEN >= 8
> -   bool need_invalidate = true;
> +   bool need_invalidate = false;
> unsigned i;
>  
> for (i = 0; i < brw->vb.nr_buffers; i++) {
> 

*facepalm*...thanks Chris!

Reviewed-by: Kenneth Graunke 

Pushed:

To ssh://git.freedesktop.org/git/mesa/mesa
   e4fe2fd3bb2..3ac5fbadfd8  master -> master


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

[Mesa-dev] [Bug 106619] [OpenCL][llvm-svn]build failure addPassesToEmitFile candidate expects 6 arguments, 3 provided

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Blocks||99553
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Jan Vesely  ---
Fixed by d424be0feda503307692db8447f5989fa8e4a843
"clover: Fix build after llvm r332881."


Referenced Bugs:

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

Re: [Mesa-dev] [PATCH] mesa: add display listy support for glPatchParameter{i, fv}()

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, May 28, 2018 at 7:20 AM, Timothy Arceri 
wrote:

> This is required for tessellation shader Compat profile support.
> ---
>  src/mesa/main/dlist.c | 78 +++
>  1 file changed, 78 insertions(+)
>
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index 8be223559ab..4fc451000b5 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -365,6 +365,11 @@ typedef enum
> OPCODE_UNIFORM_3UIV,
> OPCODE_UNIFORM_4UIV,
>
> +   /* OpenGL 4.0 / GL_ARB_tessellation_shader */
> +   OPCODE_PATCH_PARAMETER_I,
> +   OPCODE_PATCH_PARAMETER_FV_INNER,
> +   OPCODE_PATCH_PARAMETER_FV_OUTER,
> +
> /* OpenGL 4.2 / GL_ARB_separate_shader_objects */
> OPCODE_USE_PROGRAM_STAGES,
> OPCODE_PROGRAM_UNIFORM_1F,
> @@ -3271,6 +3276,54 @@ save_Ortho(GLdouble left, GLdouble right,
>  }
>
>
> +static void GLAPIENTRY
> +save_PatchParameteri(GLenum pname, const GLint value)
> +{
> +   GET_CURRENT_CONTEXT(ctx);
> +   Node *n;
> +   ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
> +   n = alloc_instruction(ctx, OPCODE_PATCH_PARAMETER_I, 2);
> +   if (n) {
> +  n[1].e = pname;
> +  n[2].i = value;
> +   }
> +   if (ctx->ExecuteFlag) {
> +  CALL_PatchParameteri(ctx->Exec, (pname, value));
> +   }
> +}
> +
> +
> +static void GLAPIENTRY
> +save_PatchParameterfv(GLenum pname, const GLfloat *params)
> +{
> +   GET_CURRENT_CONTEXT(ctx);
> +   Node *n;
> +   ASSERT_OUTSIDE_SAVE_BEGIN_END_AND_FLUSH(ctx);
> +
> +   if (pname == GL_PATCH_DEFAULT_OUTER_LEVEL) {
> +  n = alloc_instruction(ctx, OPCODE_PATCH_PARAMETER_FV_OUTER, 5);
> +   } else {
> +  assert(pname == GL_PATCH_DEFAULT_INNER_LEVEL);
> +  n = alloc_instruction(ctx, OPCODE_PATCH_PARAMETER_FV_INNER, 3);
> +   }
> +   if (n) {
> +  n[1].e = pname;
> +  if (pname == GL_PATCH_DEFAULT_OUTER_LEVEL) {
> + n[2].f = params[0];
> + n[3].f = params[1];
> + n[4].f = params[2];
> + n[5].f = params[3];
> +  } else {
> + n[2].f = params[0];
> + n[3].f = params[1];
> +  }
> +   }
> +   if (ctx->ExecuteFlag) {
> +  CALL_PatchParameterfv(ctx->Exec, (pname, params));
> +   }
> +}
> +
> +
>  static void GLAPIENTRY
>  save_PixelMapfv(GLenum map, GLint mapsize, const GLfloat *values)
>  {
> @@ -8401,6 +8454,27 @@ execute_list(struct gl_context *ctx, GLuint list)
>   case OPCODE_PASSTHROUGH:
>  CALL_PassThrough(ctx->Exec, (n[1].f));
>  break;
> + case OPCODE_PATCH_PARAMETER_I:
> +CALL_PatchParameteri(ctx->Exec, (n[1].e, n[2].i));
> +break;
> + case OPCODE_PATCH_PARAMETER_FV_INNER:
> +{
> +   GLfloat params[2];
> +   params[0] = n[2].f;
> +   params[1] = n[3].f;
> +   CALL_PatchParameterfv(ctx->Exec, (n[1].e, params));
> +}
> +break;
> + case OPCODE_PATCH_PARAMETER_FV_OUTER:
> +{
> +   GLfloat params[4];
> +   params[0] = n[2].f;
> +   params[1] = n[3].f;
> +   params[2] = n[4].f;
> +   params[3] = n[5].f;
> +   CALL_PatchParameterfv(ctx->Exec, (n[1].e, params));
> +}
> +break;
>   case OPCODE_PIXEL_MAP:
>  CALL_PixelMapfv(ctx->Exec,
>  (n[1].e, n[2].i, get_pointer(&n[3])));
> @@ -9847,6 +9921,10 @@ _mesa_initialize_save_table(const struct
> gl_context *ctx)
> SET_PointParameterf(table, save_PointParameterfEXT);
> SET_PointParameterfv(table, save_PointParameterfvEXT);
>
> +   /* 91. GL_ARB_tessellation_shader */
> +   SET_PatchParameteri(table, save_PatchParameteri);
> +   SET_PatchParameterfv(table, save_PatchParameterfv);
> +
> /* 173. GL_EXT_blend_func_separate */
> SET_BlendFuncSeparate(table, save_BlendFuncSeparateEXT);
>
> --
> 2.17.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 02/16] docs: Add python script that converts html to rst.

[Laura Ekstrand]

Nevermind, Jason used a git revert trick to get it to work.  The v2 will
have the diff and preserve the git file history.

On Fri, May 25, 2018 at 7:58 PM, Laura Ekstrand 
wrote:

> I specifically tried forcing a rename earlier, but it doesn't work.  Git
> sees too much change.  The only way I could get it to work was manually
> renaming the HTML files to rst first, then committing, then converting to
> rst.
>
> The problem with that strategy is that then the Pandoc command for
> converting to rst doesn't make sense.  (.rst to .rst? What?)
>
> Laura
>
> On Fri, May 25, 2018, 4:26 AM Eric Engestrom 
> wrote:
>
>> On Thursday, 2018-05-24 17:27:05 -0700, Laura Ekstrand wrote:
>> > Use Beautiful Soup to fix bad html, then use pandoc for converting to
>> > rst.
>> > ---
>> >  docs/rstConverter.py | 23 +++
>> >  1 file changed, 23 insertions(+)
>> >  create mode 100755 docs/rstConverter.py
>> >
>> > diff --git a/docs/rstConverter.py b/docs/rstConverter.py
>> > new file mode 100755
>> > index 00..5321fdde8b
>> > --- /dev/null
>> > +++ b/docs/rstConverter.py
>> > @@ -0,0 +1,23 @@
>> > +#!/usr/bin/python3
>> > +import glob
>> > +import subprocess
>> > +from bs4 import BeautifulSoup
>> > +
>> > +pages = glob.glob("*.html")
>> > +pages += glob.glob("relnotes/*.html")
>> > +for filename in pages:
>> > +# Fix some annoyingly bad html.
>> > +with open(filename) as f:
>> > +soup = BeautifulSoup(f, 'html5lib')
>> > +soup.find("div", "header").extract() # Get rid of old header
>> > +soup.iframe.extract() # Get rid of old contents bar.
>> > +soup.find("div", "content").unwrap() # Strip the content div.
>>
>> Good call on using beautifulsoup to clean the html before converting it!
>>
>> > +
>> > +# Write out the better html.
>> > +with open(filename, 'wt') as f:
>> > +f.write(str(soup))
>> > +
>> > +# Convert to rst with pandoc.
>> > +name = filename.split(".html")[0]
>> > +bashCmd = "pandoc " + filename + " -o " + name + ".rst"
>> > +subprocess.run(bashCmd.split())
>>
>> Idea: remove the old html at the same time as we introduce the rst
>> (commit-wise), so that git picks it up as a rename with changes, which
>> hopefully would be easier to check as a 1:1 of any given conversion?
>>
>> (In case this is as unclear as I think it is, I'm thinking about how we
>> can review individual pages conversions; say index.html -> index.rst, to
>> see that no release has been dropped in the process. If git shows this
>> as a rename with changes, I expect it will be easier to check than if
>> one commit creates all the rst files and another deletes all the html)
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 3/3] docs: add note about moving to libwayland-egl in 18.2.0

[Matt Turner]

On Tue, May 29, 2018 at 7:41 AM, Eric Engestrom
 wrote:
> Cc: Emil Velikov 
> Cc: Daniel Stone 
> Cc: Andres Gomez 
> Cc: Dylan Baker 
> Signed-off-by: Eric Engestrom 
> ---
>  docs/relnotes/18.2.0.html | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
> index 00b253c076fd0f5bef00..94bc17e0082ce6f22fa2 100644
> --- a/docs/relnotes/18.2.0.html
> +++ b/docs/relnotes/18.2.0.html
> @@ -30,6 +30,13 @@ Mesa 18.2.0 Release Notes / TBD
>  Compatibility contexts may report a lower version depending on each driver.
>  
>
> +
> +libwayland-egl is now distributed by libwayland (since 1.15,
> + href="https://lists.freedesktop.org/archives/wayland-devel/2018-April/037767.html";>see
>  announcement),
> +and has been removed from Mesa in this release. Make sure you're using
> +an up-to-date version of libwayland to keep the functionality.
> +
> +
>
>  SHA256 checksums
>  
> @@ -57,6 +64,7 @@ Changes
>
>  
>  Removed GL_EXT_polygon_offset applications should use glPolygonOffset 
> instead.
> +Removed libwayland-egl, now part of libwayland

I can imagine readers being confused by this statement, wondering
whether libwayland-egl merged into Wayland or libwayland itself.
Probably best to s/libwayland/Wayland/.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] intel/eu: Switch to a logical state stack

[Jason Ekstrand]

Instead of the state stack that's based on copying a dummy instruction
around, we start using a logical stack of brw_insn_states.  This uses a
bit less memory and is way less conceptually bogus.
---
 src/intel/compiler/brw_eu.c  | 90 +---
 src/intel/compiler/brw_eu.h  | 34 ++-
 src/intel/compiler/brw_eu_emit.c | 74 ++---
 3 files changed, 72 insertions(+), 126 deletions(-)

diff --git a/src/intel/compiler/brw_eu.c b/src/intel/compiler/brw_eu.c
index 5375209..d0e4ea2 100644
--- a/src/intel/compiler/brw_eu.c
+++ b/src/intel/compiler/brw_eu.c
@@ -129,91 +129,76 @@ brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, 
unsigned swz)
 unsigned
 brw_get_default_exec_size(struct brw_codegen *p)
 {
-   return brw_inst_exec_size(p->devinfo, p->current);
+   return p->current->exec_size;
 }
 
 unsigned
 brw_get_default_group(struct brw_codegen *p)
 {
-   if (p->devinfo->gen >= 6) {
-  unsigned group = brw_inst_qtr_control(p->devinfo, p->current) * 8;
-  if (p->devinfo->gen >= 7)
- group += brw_inst_nib_control(p->devinfo, p->current) * 4;
-  return group;
-   } else {
-  unsigned qtr_control = brw_inst_qtr_control(p->devinfo, p->current);
-  if (qtr_control == BRW_COMPRESSION_COMPRESSED)
- return 0;
-  else
- return qtr_control * 8;
-   }
+   return p->current->group;
 }
 
 unsigned
 brw_get_default_access_mode(struct brw_codegen *p)
 {
-   return brw_inst_access_mode(p->devinfo, p->current);
+   return p->current->access_mode;
 }
 
 void
 brw_set_default_exec_size(struct brw_codegen *p, unsigned value)
 {
-   brw_inst_set_exec_size(p->devinfo, p->current, value);
+   p->current->exec_size = value;
 }
 
 void brw_set_default_predicate_control( struct brw_codegen *p, unsigned pc )
 {
-   brw_inst_set_pred_control(p->devinfo, p->current, pc);
+   p->current->predicate = pc;
 }
 
 void brw_set_default_predicate_inverse(struct brw_codegen *p, bool 
predicate_inverse)
 {
-   brw_inst_set_pred_inv(p->devinfo, p->current, predicate_inverse);
+   p->current->pred_inv = predicate_inverse;
 }
 
 void brw_set_default_flag_reg(struct brw_codegen *p, int reg, int subreg)
 {
-   if (p->devinfo->gen >= 7)
-  brw_inst_set_flag_reg_nr(p->devinfo, p->current, reg);
-
-   brw_inst_set_flag_subreg_nr(p->devinfo, p->current, subreg);
+   assert(subreg < 2);
+   p->current->flag_subreg = reg * 2 + subreg;
 }
 
 void brw_set_default_access_mode( struct brw_codegen *p, unsigned access_mode )
 {
-   brw_inst_set_access_mode(p->devinfo, p->current, access_mode);
+   p->current->access_mode = access_mode;
 }
 
 void
 brw_set_default_compression_control(struct brw_codegen *p,
enum brw_compression compression_control)
 {
-   if (p->devinfo->gen >= 6) {
-  /* Since we don't use the SIMD32 support in gen6, we translate
-   * the pre-gen6 compression control here.
+   switch (compression_control) {
+   case BRW_COMPRESSION_NONE:
+  /* This is the "use the first set of bits of dmask/vmask/arf
+   * according to execsize" option.
*/
-  switch (compression_control) {
-  case BRW_COMPRESSION_NONE:
-/* This is the "use the first set of bits of dmask/vmask/arf
- * according to execsize" option.
- */
- brw_inst_set_qtr_control(p->devinfo, p->current, GEN6_COMPRESSION_1Q);
-break;
-  case BRW_COMPRESSION_2NDHALF:
-/* For SIMD8, this is "use the second set of 8 bits." */
- brw_inst_set_qtr_control(p->devinfo, p->current, GEN6_COMPRESSION_2Q);
-break;
-  case BRW_COMPRESSION_COMPRESSED:
-/* For SIMD16 instruction compression, use the first set of 16 bits
- * since we don't do SIMD32 dispatch.
- */
- brw_inst_set_qtr_control(p->devinfo, p->current, GEN6_COMPRESSION_1H);
-break;
-  default:
- unreachable("not reached");
-  }
-   } else {
-  brw_inst_set_qtr_control(p->devinfo, p->current, compression_control);
+  p->current->group = 0;
+  break;
+   case BRW_COMPRESSION_2NDHALF:
+  /* For SIMD8, this is "use the second set of 8 bits." */
+  p->current->group = 8;
+  break;
+   case BRW_COMPRESSION_COMPRESSED:
+  /* For SIMD16 instruction compression, use the first set of 16 bits
+   * since we don't do SIMD32 dispatch.
+   */
+  p->current->group = 0;
+  break;
+   default:
+  unreachable("not reached");
+   }
+
+   if (p->devinfo->gen <= 6) {
+  p->current->compressed =
+ (compression_control == BRW_COMPRESSION_COMPRESSED);
}
 }
 
@@ -246,7 +231,7 @@ brw_inst_set_compression(const struct gen_device_info 
*devinfo,
 void
 brw_set_default_compression(struct brw_codegen *p, bool on)
 {
-   brw_inst_set_compression(p->devinfo, p->current, on);
+   p->current->compressed = on;
 }
 
 /**
@@ -283,23 +268,22 @@ brw_inst_set_group(const struct gen_device_info *devinfo,
 void
 brw_se

[Mesa-dev] [PATCH 3/4] intel/eu: Set flag [sub]register number differently for 3src

[Jason Ekstrand]

Prior to gen8, the flag [sub]register number is in a different spot on
3src instructions than on other instructions.  Starting with Broadwell,
they made it consistent.  This commit fixes bugs that occur when a
conditional modifier gets propagated into a 3src instruction such as a
MAD.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/compiler/brw_eu_emit.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index b2bce0e..0dfe26a 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -701,9 +701,16 @@ brw_inst_set_state(const struct gen_device_info *devinfo,
brw_inst_set_pred_control(devinfo, insn, state->predicate);
brw_inst_set_pred_inv(devinfo, insn, state->pred_inv);
 
-   brw_inst_set_flag_subreg_nr(devinfo, insn, state->flag_subreg % 2);
-   if (devinfo->gen >= 7)
-  brw_inst_set_flag_reg_nr(devinfo, insn, state->flag_subreg / 2);
+   if (is_3src(devinfo, brw_inst_opcode(devinfo, insn)) &&
+   state->access_mode == BRW_ALIGN_16) {
+  brw_inst_set_3src_a16_flag_subreg_nr(devinfo, insn, state->flag_subreg % 
2);
+  if (devinfo->gen >= 7)
+ brw_inst_set_3src_a16_flag_reg_nr(devinfo, insn, state->flag_subreg / 
2);
+   } else {
+  brw_inst_set_flag_subreg_nr(devinfo, insn, state->flag_subreg % 2);
+  if (devinfo->gen >= 7)
+ brw_inst_set_flag_reg_nr(devinfo, insn, state->flag_subreg / 2);
+   }
 
if (devinfo->gen >= 6)
   brw_inst_set_acc_wr_control(devinfo, insn, state->acc_wr_control);
-- 
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 2/4] intel/eu: Copy fields manually in brw_next_insn

[Jason Ekstrand]

Instead of doing a memcpy, this moves us to start with a blank
instruction (memset to zero) and copy the fields over one at a time.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/compiler/brw_eu_emit.c | 95 +++-
 1 file changed, 94 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 35a4de7..b2bce0e 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -621,6 +621,94 @@ gen7_set_dp_scratch_message(struct brw_codegen *p,
brw_inst_set_scratch_addr_offset(devinfo, inst, addr_offset);
 }
 
+struct brw_insn_state {
+   /* One of BRW_EXECUTE_* */
+   unsigned exec_size:3;
+
+   /* Group in units of channels */
+   unsigned group:5;
+
+   /* Compression control on gen4-5 */
+   bool compressed:1;
+
+   /* One of BRW_MASK_* */
+   unsigned mask_control:1;
+
+   bool saturate:1;
+
+   /* One of BRW_ALIGN_* */
+   unsigned access_mode:1;
+
+   /* One of BRW_PREDICATE_* */
+   enum brw_predicate predicate:4;
+
+   bool pred_inv:1;
+
+   /* Flag subreg.  Bottom bit is subreg, top bit is reg */
+   unsigned flag_subreg:2;
+
+   bool acc_wr_control:1;
+};
+
+static struct brw_insn_state
+brw_inst_get_state(const struct gen_device_info *devinfo,
+   const brw_inst *insn)
+{
+   struct brw_insn_state state = { };
+
+   state.exec_size = brw_inst_exec_size(devinfo, insn);
+   if (devinfo->gen >= 6) {
+  state.group = brw_inst_qtr_control(devinfo, insn) * 8;
+  if (devinfo->gen >= 7)
+ state.group += brw_inst_nib_control(devinfo, insn) * 4;
+   } else {
+  unsigned qtr_control = brw_inst_qtr_control(devinfo, insn);
+  if (qtr_control == BRW_COMPRESSION_COMPRESSED) {
+ state.group = 0;
+ state.compressed = true;
+  } else {
+ state.group = qtr_control * 8;
+ state.compressed = false;
+  }
+   }
+   state.access_mode = brw_inst_access_mode(devinfo, insn);
+   state.mask_control = brw_inst_mask_control(devinfo, insn);
+   state.saturate = brw_inst_saturate(devinfo, insn);
+   state.predicate = brw_inst_pred_control(devinfo, insn);
+   state.pred_inv = brw_inst_pred_inv(devinfo, insn);
+
+   state.flag_subreg = brw_inst_flag_subreg_nr(devinfo, insn);
+   if (devinfo->gen >= 7)
+  state.flag_subreg += brw_inst_flag_reg_nr(devinfo, insn) * 2;
+
+   if (devinfo->gen >= 6)
+  state.acc_wr_control = brw_inst_acc_wr_control(devinfo, insn);
+
+   return state;
+}
+
+static void
+brw_inst_set_state(const struct gen_device_info *devinfo,
+   brw_inst *insn,
+   const struct brw_insn_state *state)
+{
+   brw_inst_set_exec_size(devinfo, insn, state->exec_size);
+   brw_inst_set_group(devinfo, insn, state->group);
+   brw_inst_set_compression(devinfo, insn, state->compressed);
+   brw_inst_set_access_mode(devinfo, insn, state->access_mode);
+   brw_inst_set_mask_control(devinfo, insn, state->mask_control);
+   brw_inst_set_saturate(devinfo, insn, state->saturate);
+   brw_inst_set_pred_control(devinfo, insn, state->predicate);
+   brw_inst_set_pred_inv(devinfo, insn, state->pred_inv);
+
+   brw_inst_set_flag_subreg_nr(devinfo, insn, state->flag_subreg % 2);
+   if (devinfo->gen >= 7)
+  brw_inst_set_flag_reg_nr(devinfo, insn, state->flag_subreg / 2);
+
+   if (devinfo->gen >= 6)
+  brw_inst_set_acc_wr_control(devinfo, insn, state->acc_wr_control);
+}
+
 #define next_insn brw_next_insn
 brw_inst *
 brw_next_insn(struct brw_codegen *p, unsigned opcode)
@@ -635,9 +723,14 @@ brw_next_insn(struct brw_codegen *p, unsigned opcode)
 
p->next_insn_offset += 16;
insn = &p->store[p->nr_insn++];
-   memcpy(insn, p->current, sizeof(*insn));
 
+   memset(insn, 0, sizeof(*insn));
brw_inst_set_opcode(devinfo, insn, opcode);
+
+   /* Apply the default instruction state */
+   struct brw_insn_state current = brw_inst_get_state(devinfo, p->current);
+   brw_inst_set_state(devinfo, insn, ¤t);
+
return insn;
 }
 
-- 
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/4] intel/eu: Add some brw_get_default_ helpers

[Jason Ekstrand]

This is much cleaner than everything that wants a default value poking
at the bits of p->current directly.
---
 src/intel/compiler/brw_eu.c | 29 ++
 src/intel/compiler/brw_eu.h |  3 +
 src/intel/compiler/brw_eu_emit.c| 98 +++--
 src/intel/compiler/brw_fs_generator.cpp |  4 +-
 4 files changed, 79 insertions(+), 55 deletions(-)

diff --git a/src/intel/compiler/brw_eu.c b/src/intel/compiler/brw_eu.c
index 3646076..5375209 100644
--- a/src/intel/compiler/brw_eu.c
+++ b/src/intel/compiler/brw_eu.c
@@ -126,6 +126,35 @@ brw_swizzle_immediate(enum brw_reg_type type, uint32_t x, 
unsigned swz)
}
 }
 
+unsigned
+brw_get_default_exec_size(struct brw_codegen *p)
+{
+   return brw_inst_exec_size(p->devinfo, p->current);
+}
+
+unsigned
+brw_get_default_group(struct brw_codegen *p)
+{
+   if (p->devinfo->gen >= 6) {
+  unsigned group = brw_inst_qtr_control(p->devinfo, p->current) * 8;
+  if (p->devinfo->gen >= 7)
+ group += brw_inst_nib_control(p->devinfo, p->current) * 4;
+  return group;
+   } else {
+  unsigned qtr_control = brw_inst_qtr_control(p->devinfo, p->current);
+  if (qtr_control == BRW_COMPRESSION_COMPRESSED)
+ return 0;
+  else
+ return qtr_control * 8;
+   }
+}
+
+unsigned
+brw_get_default_access_mode(struct brw_codegen *p)
+{
+   return brw_inst_access_mode(p->devinfo, p->current);
+}
+
 void
 brw_set_default_exec_size(struct brw_codegen *p, unsigned value)
 {
diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 2655cdb..cfbb537 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -106,6 +106,9 @@ struct brw_codegen {
 
 void brw_pop_insn_state( struct brw_codegen *p );
 void brw_push_insn_state( struct brw_codegen *p );
+unsigned brw_get_default_exec_size(struct brw_codegen *p);
+unsigned brw_get_default_group(struct brw_codegen *p);
+unsigned brw_get_default_access_mode(struct brw_codegen *p);
 void brw_set_default_exec_size(struct brw_codegen *p, unsigned value);
 void brw_set_default_mask_control( struct brw_codegen *p, unsigned value );
 void brw_set_default_saturate( struct brw_codegen *p, bool enable );
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 6d81c63..35a4de7 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -997,7 +997,7 @@ brw_MOV(struct brw_codegen *p, struct brw_reg dest, struct 
brw_reg src0)
 * each element twice.
 */
if (devinfo->gen == 7 && !devinfo->is_haswell &&
-   brw_inst_access_mode(devinfo, p->current) == BRW_ALIGN_1 &&
+   brw_get_default_access_mode(p) == BRW_ALIGN_1 &&
dest.type == BRW_REGISTER_TYPE_DF &&
(src0.type == BRW_REGISTER_TYPE_F ||
 src0.type == BRW_REGISTER_TYPE_D ||
@@ -1119,7 +1119,7 @@ brw_inst *
 brw_F32TO16(struct brw_codegen *p, struct brw_reg dst, struct brw_reg src)
 {
const struct gen_device_info *devinfo = p->devinfo;
-   const bool align16 = brw_inst_access_mode(devinfo, p->current) == 
BRW_ALIGN_16;
+   const bool align16 = brw_get_default_access_mode(p) == BRW_ALIGN_16;
/* The F32TO16 instruction doesn't support 32-bit destination types in
 * Align1 mode, and neither does the Gen8 implementation in terms of a
 * converting MOV.  Gen7 does zero out the high 16 bits in Align16 mode as
@@ -1166,7 +1166,7 @@ brw_inst *
 brw_F16TO32(struct brw_codegen *p, struct brw_reg dst, struct brw_reg src)
 {
const struct gen_device_info *devinfo = p->devinfo;
-   bool align16 = brw_inst_access_mode(devinfo, p->current) == BRW_ALIGN_16;
+   bool align16 = brw_get_default_access_mode(p) == BRW_ALIGN_16;
 
if (align16) {
   assert(src.type == BRW_REGISTER_TYPE_UD);
@@ -1337,8 +1337,7 @@ gen6_IF(struct brw_codegen *p, enum brw_conditional_mod 
conditional,
insn = next_insn(p, BRW_OPCODE_IF);
 
brw_set_dest(p, insn, brw_imm_w(0));
-   brw_inst_set_exec_size(devinfo, insn,
-  brw_inst_exec_size(devinfo, p->current));
+   brw_inst_set_exec_size(devinfo, insn, brw_get_default_exec_size(p));
brw_inst_set_gen6_jump_count(devinfo, insn, 0);
brw_set_src0(p, insn, src0);
brw_set_src1(p, insn, src1);
@@ -1624,8 +1623,7 @@ brw_BREAK(struct brw_codegen *p)
   p->if_depth_in_loop[p->loop_stack_depth]);
}
brw_inst_set_qtr_control(devinfo, insn, BRW_COMPRESSION_NONE);
-   brw_inst_set_exec_size(devinfo, insn,
-  brw_inst_exec_size(devinfo, p->current));
+   brw_inst_set_exec_size(devinfo, insn, brw_get_default_exec_size(p));
 
return insn;
 }
@@ -1650,8 +1648,7 @@ brw_CONT(struct brw_codegen *p)
   p->if_depth_in_loop[p->loop_stack_depth]);
}
brw_inst_set_qtr_control(devinfo, insn, BRW_COMPRESSION_NONE);
-   brw_inst_set_exec_size(devinfo, insn,
-  brw_inst_exec_size(devinfo, p->current));
+   brw_

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Jordan Justen]

On 2018-05-24 17:37:09, Laura Ekstrand wrote:
> A few of the commits are quite large and awaiting list approval.  I suggest
> that you take a look at the code here:
> https://gitlab.freedesktop.org/ldeks/mesa/tree/website1_75,
> and the new website here: https://mesa-test.freedesktop.org/index.html

I think the theme should be changed to look somewhat close to the
current mesa3d.org website before changing the main site. (Color
scheme and missing icons.)

Right now the test website looks like a million other sphinx websites,
including every readthedocs book.

Based on http://www.sphinx-doc.org/en/master/ and
https://www.python.org/, I would say sphinx gives a lot of
opportunities for a custom look.

-Jordan

> On Thu, May 24, 2018 at 5:27 PM, Laura Ekstrand 
> wrote:
> 
> > It's time to move the Mesa-3d.org website into the 21st century. We have
> > chosen to move to Sphinx and resStructured text for a number of reasons:
> >   1. Syntax highlighting for code snippets.
> >   2. Snazzy highlighting for variables and function names.
> >   3. Consistency with the Gallium drivers, which host their documentation
> > on
> >  ReadTheDocs.
> >   4. Ultimately less work for us, because writing content in reStructured
> > Text
> >  is simpler and Sphinx turns it into beautiful, readable pages without
> > us
> >  having to manually fix problems in html and css.
> >   5. With Gitlab, the Sphinx website is auto-generated every time the Mesa
> >  code repository is pushed to Gitlab without us having to
> >  build and deploy it.
> >
> > The new website is currently hosted at mesa-test.freedesktop.org.  When
> > these
> > patches are merged, Daniel Stone will point our Gitlab CI system at
> > mesa-3d.org.
> >
> > When reviewing these patches, please note:
> > 1. This patch series does *not* touch content.  Please do not
> > bikeshed
> >the content of webpages here.  That will be addressed in later
> >commits.
> > 2. Please do *not* bikeshed website style here.  We are using the
> >classic ReadTheDocs style for now and we will update style in a
> >future commit.
> > 3. I've done my best to make your current content look beautiful.
> > If
> >there's a problem, please let me know.
> > 4. There were some commits to the website between when I started
> > this
> >series and now. I've done my best to incorporate your changes.
> >So if you changed your content in the past two weeks, take a
> > look
> >at your page.
> >
> > I hope you'll agree that the resulting pages are much cleaner and easier to
> > read.  I've learned a lot by reading these pages.
> >
> > Thanks.
> >
> > Laura Ekstrand
> > ---
> >
> > Jean Hertel (3):
> >   docs: Add Sphinx configuration file.
> >   docs: Add a navigation sidebar.
> >   docs: Add toctree to relnotes
> >
> > Laura Ekstrand (13):
> >   Added ci yaml file for Gitlab.
> >   docs: Add python script that converts html to rst.
> >   docs: Remove contents.html
> >   docs: Result of script fixing html with Beautiful Soup.
> >   docs: Add results of script - pandoc-generated rst pages.
> >   docs: Add command for Sphinx build.
> >   docs: Toctree for systems.rst as in jhertel docs.
> >   docs: Remove html files.
> >   docs: Fix Sphinx compile errors.
> >   docs: Edits to fix toctrees.
> >   docs: Major manual edits to environment vars.
> >   docs: Human edits to the website code for clarity.
> >   docs: Remove unneeded mesa css file.
> >
> >  .gitlab-ci.yml   |   11 +
> >  docs/application-issues.html |   83 --
> >  docs/application-issues.rst  |   48 +
> >  docs/autoconf.html   |  257 
> >  docs/autoconf.rst|  209 +++
> >  docs/bugs.html   |   64 -
> >  docs/bugs.rst|   33 +
> >  docs/codingstyle.html|  142 --
> >  docs/codingstyle.rst |  124 ++
> >  docs/conf.py |  162 +++
> >  docs/conform.html|  703 --
> >  docs/conform.rst |  675 ++
> >  docs/contents.html   |  108 --
> >  docs/debugging.html  |   47 -
> >  docs/debugging.rst   |   21 +
> >  docs/developers.html |   58 -
> >  docs/developers.rst  |   25 +
> >  docs/devinfo.html|   83 --
> >  docs/devinfo.rst |   43 +
> >  docs/dispatch.html   |  278 
> >  docs/dispatch.rst|  257 
> >  docs/download.html   |  112 --
> >  docs/download.rst|   73 ++
> >  docs/egl.html|  259 
> >  docs/egl.rst |  117 ++
> >  docs/envvars.html|  383 --
> >  docs/envvars.rst |  615 +
> >  docs/extensions.html |   51 -
> >  docs/extensions.rst  |   31 +
> >  docs/faq.html|  392 --
> >  docs/faq.rst |  308 +
> >  docs/helpwanted.html |   88

[Mesa-dev] [PATCH] radv: Only expose subgroups shuflles on VI+.

[Bas Nieuwenhuizen]

Fixes: f2c6a550611 "radv: enable subgroup capabilities"
---
 src/amd/vulkan/radv_device.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 61b4fba23f8..93b6e611067 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -963,9 +963,12 @@ void radv_GetPhysicalDeviceProperties2(

VK_SUBGROUP_FEATURE_BASIC_BIT |

VK_SUBGROUP_FEATURE_BALLOT_BIT |

VK_SUBGROUP_FEATURE_QUAD_BIT |
-   
VK_SUBGROUP_FEATURE_SHUFFLE_BIT |
-   
VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT |

VK_SUBGROUP_FEATURE_VOTE_BIT;
+   if (pdevice->rad_info.chip_class >= VI) {
+   properties->supportedOperations |=
+   
VK_SUBGROUP_FEATURE_SHUFFLE_BIT |
+   
VK_SUBGROUP_FEATURE_SHUFFLE_RELATIVE_BIT;
+   }
properties->quadOperationsInAllStages = true;
break;
}
-- 
2.17.0

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