[Mesa-dev] [Bug 106231] llvmpipe blends produce bad code after llvm patch https://reviews.llvm.org/D44785

[bugzilla-daemon]

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

Roland Scheidegger  changed:

   What|Removed |Added

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

--- Comment #4 from Roland Scheidegger  ---
Fixed by 8e1be9a34ac8ce6f115eaf2ab0d99b6a0ce37630.

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

[Mesa-dev] [PATCH] docs/relnotes: Mark NV_fragment_shader_interlock support in i965

[kevin . rogovin]

From: Kevin Rogovin 

---
 docs/relnotes/18.3.0.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html
index 594b0624a5..afcb044817 100644
--- a/docs/relnotes/18.3.0.html
+++ b/docs/relnotes/18.3.0.html
@@ -59,6 +59,7 @@ Note: some of the new features are only available with 
certain drivers.
 GL_EXT_vertex_attrib_64bit on i965, nvc0, radeonsi.
 GL_EXT_window_rectangles on radeonsi.
 GL_KHR_texture_compression_astc_sliced_3d on radeonsi.
+GL_NV_fragment_shader_interlock on i965.
 
 
 Bug fixes
-- 
2.17.1

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

[Mesa-dev] [PATCH] docs/relnotes: Mark NV_fragment_shader_interlock support in i965

[kevin . rogovin]

From: Kevin Rogovin 

---
 docs/relnotes/18.3.0.html | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html
index 594b0624a5..afcb044817 100644
--- a/docs/relnotes/18.3.0.html
+++ b/docs/relnotes/18.3.0.html
@@ -59,6 +59,7 @@ Note: some of the new features are only available with 
certain drivers.
 GL_EXT_vertex_attrib_64bit on i965, nvc0, radeonsi.
 GL_EXT_window_rectangles on radeonsi.
 GL_KHR_texture_compression_astc_sliced_3d on radeonsi.
+GL_NV_fragment_shader_interlock on i965.
 
 
 Bug fixes
-- 
2.17.1

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

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

[bugzilla-daemon]

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

--- Comment #3 from Roland Scheidegger  ---
Isn't this mapped as WC?
In this case I'd expect the direction to make little difference, since write
combine of any decent cpu should be able to combine the writes regardless the
order?
Although if it's UC I suppose someone needs to ensure that the maximum possible
size is picked...

-- 
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 5/8] anv/android: support import/export of AHardwareBuffer objects

[Tapani Pälli]

On 08/22/2018 05:28 PM, Jason Ekstrand wrote:
On Tue, Aug 21, 2018 at 3:27 AM Tapani Pälli > wrote:


v2: add support for non-image buffers (AHARDWAREBUFFER_FORMAT_BLOB)
v3: properly handle usage bits when creating from image

Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
  src/intel/vulkan/anv_android.c | 149
+
  src/intel/vulkan/anv_device.c  |  46 -
  src/intel/vulkan/anv_private.h |  18 +
  3 files changed, 212 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_android.c
b/src/intel/vulkan/anv_android.c
index 7d0eb588e2b..6f90649847d 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -195,6 +195,155 @@ 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;
+
+   uint64_t bo_flags = 0;
+   if (device->instance->physicalDevice.supports_48bit_addresses)
+      bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   if (device->instance->physicalDevice.use_softpin)
+      bo_flags |= EXEC_OBJECT_PINNED;
+
+   result = anv_bo_cache_import(device, &device->bo_cache,
+                                dma_buf, bo_flags, &mem->bo);
+   if (result != VK_SUCCESS)
+      return result;
+
+   /* "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 VkMemoryAllocateInfo *pAllocateInfo)
+{
+   ANV_FROM_HANDLE(anv_device, dev, device_h);
+
+   const VkMemoryDedicatedAllocateInfo *dedicated_info =
+      vk_find_struct_const(pAllocateInfo->pNext,
+                           MEMORY_DEDICATED_ALLOCATE_INFO);
+
+   uint32_t w = 0;
+   uint32_t h = 1;
+   uint32_t format = 0;
+   uint64_t usage = 0;
+
+   /* If caller passed dedicated information. */
+   if (dedicated_info && dedicated_info->image) {
+      ANV_FROM_HANDLE(anv_image, image, dedicated_info->image);
+      w = image->extent.width;
+      h = image->extent.height;
+      format = android_format_from_vk(image->vk_format);
+
+      /* Construct usage mask from image usage bits, see
+       * 'AHardwareBuffer Usage Equivalence' in spec.
+       */
+      if (image->usage & VK_IMAGE_USAGE_SAMPLED_BIT)
+         usage |= AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE;
+
+      if (image->usage & VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT)
+         usage |= AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE;
+
+      if (image->usa

Re: [Mesa-dev] [PATCH 3/8] anv/android: add GetAndroidHardwareBufferPropertiesANDROID

[Tapani Pälli]

On 08/22/2018 05:18 PM, Jason Ekstrand wrote:
On Tue, Aug 21, 2018 at 3:27 AM Tapani Pälli > wrote:


When adding YUV support, we need to figure out implementation-defined
external format identifier.

Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
  src/intel/vulkan/anv_android.c | 99
++
  1 file changed, 99 insertions(+)

diff --git a/src/intel/vulkan/anv_android.c
b/src/intel/vulkan/anv_android.c
index 46c41d57861..7d0eb588e2b 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,103 @@ 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;


You shouldn't be overwriting pNext.  That's used by the client to let 
them chain in multiple structs to fill out in case Google ever extends 
this extension.  Also, while we're here, it'd be good to throw in an 
assert that p->sType is the right thing.


Yes of course, will remove.


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


If all you need is devinfo, that's avilable in the device; you don't 
need to get the physical device for it.  Should be device->info.


OK


+
+   p->formatFeatures =
+      anv_get_image_format_features(devinfo, p->format,
+                                    anv_format,
VK_IMAGE_TILING_OPTIMAL);
+
+   /* "The formatFeatures member *must* include
+    *  VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT and at least one of
+    *  VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT or
+    *  VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT"
+    */
+   p->formatFeatures |=
+      VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT;


Uh... Why not just throw in SAMPLED_BIT?  For that matter, all of the 
formats you have in your conversion helpers support sampling.  Maybe 
just replace that with an assert for now.


Yeah, VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT is there. Well thing is that 
dEQP checks explicitly that either 
VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT or 
VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT exists (independent of 
surface format). TBH I'm not sure what to do about that.




+
+   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;
+
+   VkAndroidHardwareBufferFormatPropertiesANDROID *format_prop =
+      vk_find_

Re: [Mesa-dev] [PATCH 2/8] anv: add from/to helpers with android and vulkan formats

[Tapani Pälli]

On 08/22/2018 05:11 PM, Jason Ekstrand wrote:
On Tue, Aug 21, 2018 at 3:27 AM Tapani Pälli > wrote:


Signed-off-by: Tapani Pälli mailto:tapani.pa...@intel.com>>
---
  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 a1cc6952c8f..0ae0a2d43ee 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:


How do you plan on handling the X?  Also, what are the semantics of it?  
Are images created with this format expected to act as if they have no 
alpha channel?  If so, then you may want to declare it as R8G8B8_UNORM 
and we have logic in anv_image to turn that into R8G8B8A8_UNORM and 
whack blending to treat it as if there is no alpha channel.


Thanks, yes the case is that it should 'ignore alpha' and be always 
opaque. Will change.




+      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.4


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


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

Re: [Mesa-dev] [PATCH] Add NV_fragment_shader_interlock support.

[Kevin Rogovin]

Thankyou for pushing; I will post the one liner for the release notes
shortly.

Best Regards,
-Kevin Rogovin

On Fri, 24 Aug 2018 at 3.44, Jason Ekstrand  wrote:

> Your first version has already landed; Ken pushed it:
>
>
> https://cgit.freedesktop.org/mesa/mesa/commit/src?id=7ec308d978019dd9aa0e7a756b5919e34431196d
>
> Mind making a patch with just the release notes update?
>
> Thanks!
>
> --Jason
>
> On August 22, 2018 22:57:42 Kevin Rogovin  wrote:
>
>> Hi,
>>
>>  My request for an account was NAK'd by the i965 maintainer. As such, I
>> will post a v2 with the update to release notes requested and I hope
>> Plamena can push that for me.
>>
>> Best Regards,
>>  -Kevin Rogovin
>>
>> On Tue, Aug 21, 2018 at 12:39 PM Emil Velikov 
>> wrote:
>>
>>> Hi Kevin,
>>>
>>> On 20 August 2018 at 15:11, Kevin Rogovin 
>>> wrote:
>>> > Hi Plamena,
>>> >
>>> >  Thankyou for the fast review. Can you push it or have someone push
>>> it? (I
>>> > do not have push rights)
>>> >
>>> You have contributed a number of good patches in Mesa, always
>>> listening to feedback.
>>> I would welcome if you're given commit access to the repository.
>>>
>>> https://www.mesa3d.org/repository.html#developer
>>> https://bugs.freedesktop.org/show_bug.cgi?id=99601
>>>
>>> That said, can you please add a note about the new extension in the
>>> release notes.
>>>
>>> Thanks
>>> Emil
>>>
>> ___
>>
> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #9 from Clément Guérin  ---
Created attachment 141267
  --> https://bugs.freedesktop.org/attachment.cgi?id=141267&action=edit
Smoke glitches

Great. I can confirm that the game no longer crashes at ultra settings with
this patch. However, I'm seeing some graphical glitches on smoke, see
screenshot attached.

Unfortunately I won't be able to get an apitrace today.

-- 
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 v4 3/7] mesa: Add support for AMD_depth_clamp_separate

[Marek Olšák]

Looks good.

Marek

On Thu, Aug 23, 2018 at 11:16 PM, Sagar Ghuge  wrote:
> Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
> GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.
>
> Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
> as suggested by Marek Olsak.
>
> Driver that enables AMD_depth_clamp_separate will only ever look at
> DepthClampNear and DepthClampFar, as suggested by Ian Romanick.
>
> v2: 1) Remove unnecessary parentheses (Marek Olsak)
> 2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE
>GL_DEPTH_CLAMP only (Marek Olsak)
> 3) Clamp against near and far plane separately (Marek Olsak)
> 4) Clip point separately for near and far Z clipping plane (Marek
>Olsak)
>
> v3: Clamp raster position zw to the range [min(n,f), 0] for near plane
> and [0, max(n,f)] for far plane (Marek Olsak)
>
> v4: Use MIN2 and MAX2 instead of CLAMP (Marek Olsak)
>
> Signed-off-by: Sagar Ghuge 
> Reviewed-by: Ian Romanick 
> Reviewed-by: Marek Olšák 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 ++--
>  src/mesa/main/attrib.c| 40 +++---
>  src/mesa/main/enable.c|  9 ++-
>  src/mesa/main/get.c   |  4 ++
>  src/mesa/main/get_hash_params.py  |  2 +-
>  src/mesa/main/mtypes.h|  1 -
>  src/mesa/main/rastpos.c   | 55 ---
>  src/mesa/state_tracker/st_atom_rasterizer.c   |  3 +-
>  src/mesa/state_tracker/st_cb_drawpixels.c |  3 +-
>  src/mesa/swrast/s_span.c  |  2 +-
>  src/mesa/tnl/t_vb_program.c   |  6 +-
>  src/mesa/tnl/t_vb_vertex.c|  8 ++-
>  12 files changed, 111 insertions(+), 33 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index c051848985..dc54cb67af 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -1399,7 +1399,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>clip.ScreenSpaceViewportYMax = 1;
>
>clip.ViewportXYClipTestEnable = true;
> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
> +   ctx->Transform.DepthClampFar);
>
>/* _NEW_TRANSFORM */
>if (GEN_GEN == 5 || GEN_IS_G4X) {
> @@ -1493,7 +1494,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>clip.UserClipDistanceCullTestEnableBitmask =
>   brw_vue_prog_data(brw->vs.base.prog_data)->cull_distance_mask;
>
> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
> +   ctx->Transform.DepthClampFar);
>  #endif
>
>/* _NEW_LIGHT */
> @@ -2338,7 +2340,7 @@ genX(upload_cc_viewport)(struct brw_context *brw)
> for (unsigned i = 0; i < viewport_count; i++) {
>/* _NEW_VIEWPORT | _NEW_TRANSFORM */
>const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
> -  if (ctx->Transform.DepthClamp) {
> +  if (ctx->Transform.DepthClampNear && ctx->Transform.DepthClampFar) {
>   ccv.MinimumDepth = MIN2(vp->Near, vp->Far);
>   ccv.MaximumDepth = MAX2(vp->Near, vp->Far);
>} else {
> @@ -4605,7 +4607,8 @@ genX(upload_raster)(struct brw_context *brw)
>raster.ScissorRectangleEnable = ctx->Scissor.EnableFlags;
>
>/* _NEW_TRANSFORM */
> -  if (!ctx->Transform.DepthClamp) {
> +  if (!(ctx->Transform.DepthClampNear &&
> +ctx->Transform.DepthClampFar)) {
>  #if GEN_GEN >= 9
>   raster.ViewportZFarClipTestEnable = true;
>   raster.ViewportZNearClipTestEnable = true;
> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
> index cbe93ab6fa..a46fec73fd 100644
> --- a/src/mesa/main/attrib.c
> +++ b/src/mesa/main/attrib.c
> @@ -72,7 +72,8 @@ struct gl_enable_attrib
> GLbitfield ClipPlanes;
> GLboolean ColorMaterial;
> GLboolean CullFace;
> -   GLboolean DepthClamp;
> +   GLboolean DepthClampNear;
> +   GLboolean DepthClampFar;
> GLboolean DepthTest;
> GLboolean Dither;
> GLboolean Fog;
> @@ -336,7 +337,8 @@ _mesa_PushAttrib(GLbitfield mask)
>attr->ClipPlanes = ctx->Transform.ClipPlanesEnabled;
>attr->ColorMaterial = ctx->Light.ColorMaterialEnabled;
>attr->CullFace = ctx->Polygon.CullFlag;
> -  attr->DepthClamp = ctx->Transform.DepthClamp;
> +  attr->DepthClampNear = ctx->Transform.DepthClampNear;
> +  attr->DepthClampFar = ctx->Transform.DepthClampFar;
>attr->DepthTest = ctx->Depth.Test;
>attr->Dither = ctx->Color.DitherFlag;
>attr->Fog = ctx->Fog.Enabled;
> @@ -627,8 +629,18 @@ pop_enable_group(struct gl_context *ctx, const struct 
> gl_en

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

[Ilia Mirkin]

This breaks the build for me. It selects python3 instead of python2,
and gen_xmlpool.py bails out when trying to print \xf3 to stdout with
a LANG=C locale. Revert until scripts are fixed and try again?

On Thu, Aug 23, 2018 at 10:34 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Pretty much all of the scripts are python2+3 compatible.
> Check and allow using python3, while adjusting the PYTHON2 refs.
>
> Note:
>  - python3.4 is used as it's the earliest supported version
>  - python3 is chosen prior to python2
>
> Signed-off-by: Emil Velikov 
> ---
>  configure.ac |  8 +++-
>  m4/ax_check_python_mako_module.m4|  2 +-
>  src/Makefile.am  |  2 +-
>  src/amd/Makefile.common.am   |  2 +-
>  src/amd/vulkan/Makefile.am   | 10 +-
>  src/broadcom/Makefile.am |  2 +-
>  src/compiler/Makefile.am |  2 +-
>  src/compiler/Makefile.glsl.am|  2 +-
>  src/compiler/glsl/glcpp/tests/glcpp-test.sh  |  2 +-
>  src/compiler/glsl/tests/optimization-test.sh |  2 +-
>  src/compiler/glsl/tests/warnings-test.sh |  2 +-
>  src/egl/Makefile.am  |  2 +-
>  src/gallium/auxiliary/Makefile.am|  2 +-
>  src/gallium/drivers/freedreno/Makefile.am|  2 +-
>  src/gallium/drivers/r600/Makefile.am |  2 +-
>  src/gallium/drivers/radeonsi/Makefile.am |  2 +-
>  src/gallium/drivers/swr/Makefile.am  |  2 +-
>  src/intel/Makefile.am|  2 +-
>  src/intel/Makefile.compiler.am   |  2 +-
>  src/intel/Makefile.vulkan.am | 10 +-
>  src/mapi/Makefile.am |  2 +-
>  src/mapi/glapi/gen/Makefile.am   |  2 +-
>  src/mesa/Makefile.am |  2 +-
>  src/mesa/drivers/dri/i965/Makefile.am|  2 +-
>  src/util/Makefile.am |  2 +-
>  src/util/xmlpool/Makefile.am |  2 +-
>  src/vulkan/Makefile.am   |  2 +-
>  27 files changed, 37 insertions(+), 39 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index f8bb131cb63..8dea87fa6a8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -125,9 +125,7 @@ AC_PROG_GREP
>  AC_PROG_NM
>  AM_PROG_AS
>  AX_CHECK_GNU_MAKE
> -AM_PATH_PYTHON([2.7],, [:])
> -PYTHON2=$PYTHON
> -AC_SUBST([PYTHON2])
> +AM_PATH_PYTHON([3.4],, [AM_PATH_PYTHON([2.7],, [:])])
>
>  AC_PROG_SED
>  AC_PROG_MKDIR_P
> @@ -160,7 +158,7 @@ fi
>
>  AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
>
> -if test "$PYTHON2" = ":"; then
> +if test "$PYTHON" = ":"; then
>  if test ! -f "$srcdir/src/util/format_srgb.c"; then
>  AC_MSG_ERROR([Python not found - unable to generate sources])
>  fi
> @@ -3348,7 +3346,7 @@ if test "x$enable_llvm" = xyes; then
>  echo "LLVM_LDFLAGS:$LLVM_LDFLAGS"
>  echo ""
>  fi
> -echo "PYTHON2: $PYTHON2"
> +echo "PYTHON: $PYTHON"
>
>  echo ""
>  echo "Run '${MAKE-make}' to build Mesa"
> diff --git a/m4/ax_check_python_mako_module.m4 
> b/m4/ax_check_python_mako_module.m4
> index 1d293d821c3..d6484e722fd 100644
> --- a/m4/ax_check_python_mako_module.m4
> +++ b/m4/ax_check_python_mako_module.m4
> @@ -52,7 +52,7 @@ else:
>  ver_req = distutils.version.LooseVersion('$1')
>  ver_act = distutils.version.LooseVersion(mako.__version__)
>  sys.exit(int(ver_req > ver_act))
> -" | $PYTHON2 -
> +" | $PYTHON -
>
>  if test $? -ne 0 ; then
> AC_MSG_RESULT(no)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index c4fcd8a9248..c91e63efa13 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -22,7 +22,7 @@
>  .PHONY: git_sha1.h
>  git_sha1.h:
> @echo "updating $@"
> -   @$(PYTHON2) $(top_srcdir)/bin/git_sha1_gen.py --output $@
> +   @$(PYTHON) $(top_srcdir)/bin/git_sha1_gen.py --output $@
>
>  BUILT_SOURCES = git_sha1.h
>  CLEANFILES = $(BUILT_SOURCES)
> diff --git a/src/amd/Makefile.common.am b/src/amd/Makefile.common.am
> index d62e9d41cf4..453d23c3ac9 100644
> --- a/src/amd/Makefile.common.am
> +++ b/src/amd/Makefile.common.am
> @@ -66,6 +66,6 @@ common_libamd_common_la_LIBADD = $(LIBELF_LIBS)
>
>  common/sid_tables.h: $(srcdir)/common/sid_tables.py $(srcdir)/common/sid.h 
> $(srcdir)/common/gfx9d.h
> $(AM_V_at)$(MKDIR_P) $(@D)
> -   $(AM_V_GEN) $(PYTHON2) $(srcdir)/common/sid_tables.py 
> $(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
> +   $(AM_V_GEN) $(PYTHON) $(srcdir)/common/sid_tables.py 
> $(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
>
>  BUILT_SOURCES = $(AMD_GENERATED_FILES)
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index e28f032cbee..2522171dacf 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -140,7 +140,7 @@ vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
>
>  radv_entrypoints.c: radv_ent

Re: [Mesa-dev] [PATCH] xmlpool: fix script to write bytes instead of locale-formatted strings

[Ilia Mirkin]

Withdrawn. This doesn't actually work. Will follow up with something that does.

On Thu, Aug 23, 2018 at 11:08 PM, Ilia Mirkin  wrote:
> With LANG=C, print won't output any non-ascii characters. Since we're
> trying to get specific bytes onto stdout, we can just write these
> directly.
>
> Signed-off-by: Ilia Mirkin 
> ---
>  src/util/xmlpool/gen_xmlpool.py | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
> index 56a67bcab55..640b1bc7d42 100644
> --- a/src/util/xmlpool/gen_xmlpool.py
> +++ b/src/util/xmlpool/gen_xmlpool.py
> @@ -144,7 +144,8 @@ def expandMatches (matches, translations, end=None):
>  if sys.version_info.major == 2:
>  text = text.encode('utf-8')
>
> -print(text)
> +sys.stdout.write(text)
> +sys.stdout.write('\n')
>
>  # Expand any subsequent enum lines
>  for match in matches[1:]:
> @@ -157,11 +158,12 @@ def expandMatches (matches, translations, end=None):
>  if sys.version_info.major == 2:
>  text = text.encode('utf-8')
>
> -print(text)
> +sys.stdout.write(text)
> +sys.stdout.write('\n')
>
>  # Expand description end
>  if end:
> -print(end, end='')
> +sys.stdout.write(end)
>
>  # Compile a list of translation classes to all supported languages.
>  # The first translation is always a NullTranslations.
> @@ -182,9 +184,9 @@ reENUM   = re.compile 
> (r'(\s*DRI_CONF_ENUM\s*\([^,]+,\s*)(gettext\s*\(\s*")(
>  reDESC_END   = re.compile (r'\s*DRI_CONF_DESC_END')
>
>  # Print a header
> -print("/***\n"
>  \
> +sys.stdout.write("/***\n"
>  \
>  " ***THIS FILE IS GENERATED AUTOMATICALLY. DON'T EDIT!***\n" 
> \
> -" ***/")
> +" 
> ***/\n")
>
>  # Process the options template and generate options.h with all
>  # translations.
> @@ -206,7 +208,7 @@ for line in template:
>  continue
>  if reLibintl_h.search (line):
>  # Ignore (comment out) #include 
> -print("/* %s * commented out by gen_xmlpool.py */" % line)
> +sys.stdout.write("/* %s * commented out by gen_xmlpool.py */\n" % 
> line)
>  continue
>  matchDESC   = reDESC  .match (line)
>  matchDESC_BEGIN = reDESC_BEGIN.match (line)
> @@ -222,7 +224,7 @@ for line in template:
>  if sys.version_info.major == 2:
> line = line.encode('utf-8')
>
> -print(line, end='')
> +sys.stdout.write(line)
>
>  template.close()
>
> --
> 2.16.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v4 3/7] mesa: Add support for AMD_depth_clamp_separate

[Sagar Ghuge]

Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.

Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
as suggested by Marek Olsak.

Driver that enables AMD_depth_clamp_separate will only ever look at
DepthClampNear and DepthClampFar, as suggested by Ian Romanick.

v2: 1) Remove unnecessary parentheses (Marek Olsak)
2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE
   GL_DEPTH_CLAMP only (Marek Olsak)
3) Clamp against near and far plane separately (Marek Olsak)
4) Clip point separately for near and far Z clipping plane (Marek
   Olsak)

v3: Clamp raster position zw to the range [min(n,f), 0] for near plane
and [0, max(n,f)] for far plane (Marek Olsak)

v4: Use MIN2 and MAX2 instead of CLAMP (Marek Olsak)

Signed-off-by: Sagar Ghuge 
Reviewed-by: Ian Romanick 
Reviewed-by: Marek Olšák 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 11 ++--
 src/mesa/main/attrib.c| 40 +++---
 src/mesa/main/enable.c|  9 ++-
 src/mesa/main/get.c   |  4 ++
 src/mesa/main/get_hash_params.py  |  2 +-
 src/mesa/main/mtypes.h|  1 -
 src/mesa/main/rastpos.c   | 55 ---
 src/mesa/state_tracker/st_atom_rasterizer.c   |  3 +-
 src/mesa/state_tracker/st_cb_drawpixels.c |  3 +-
 src/mesa/swrast/s_span.c  |  2 +-
 src/mesa/tnl/t_vb_program.c   |  6 +-
 src/mesa/tnl/t_vb_vertex.c|  8 ++-
 12 files changed, 111 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index c051848985..dc54cb67af 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -1399,7 +1399,8 @@ genX(upload_clip_state)(struct brw_context *brw)
   clip.ScreenSpaceViewportYMax = 1;
 
   clip.ViewportXYClipTestEnable = true;
-  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
+  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
+   ctx->Transform.DepthClampFar);
 
   /* _NEW_TRANSFORM */
   if (GEN_GEN == 5 || GEN_IS_G4X) {
@@ -1493,7 +1494,8 @@ genX(upload_clip_state)(struct brw_context *brw)
   clip.UserClipDistanceCullTestEnableBitmask =
  brw_vue_prog_data(brw->vs.base.prog_data)->cull_distance_mask;
 
-  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
+  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
+   ctx->Transform.DepthClampFar);
 #endif
 
   /* _NEW_LIGHT */
@@ -2338,7 +2340,7 @@ genX(upload_cc_viewport)(struct brw_context *brw)
for (unsigned i = 0; i < viewport_count; i++) {
   /* _NEW_VIEWPORT | _NEW_TRANSFORM */
   const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
-  if (ctx->Transform.DepthClamp) {
+  if (ctx->Transform.DepthClampNear && ctx->Transform.DepthClampFar) {
  ccv.MinimumDepth = MIN2(vp->Near, vp->Far);
  ccv.MaximumDepth = MAX2(vp->Near, vp->Far);
   } else {
@@ -4605,7 +4607,8 @@ genX(upload_raster)(struct brw_context *brw)
   raster.ScissorRectangleEnable = ctx->Scissor.EnableFlags;
 
   /* _NEW_TRANSFORM */
-  if (!ctx->Transform.DepthClamp) {
+  if (!(ctx->Transform.DepthClampNear &&
+ctx->Transform.DepthClampFar)) {
 #if GEN_GEN >= 9
  raster.ViewportZFarClipTestEnable = true;
  raster.ViewportZNearClipTestEnable = true;
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index cbe93ab6fa..a46fec73fd 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -72,7 +72,8 @@ struct gl_enable_attrib
GLbitfield ClipPlanes;
GLboolean ColorMaterial;
GLboolean CullFace;
-   GLboolean DepthClamp;
+   GLboolean DepthClampNear;
+   GLboolean DepthClampFar;
GLboolean DepthTest;
GLboolean Dither;
GLboolean Fog;
@@ -336,7 +337,8 @@ _mesa_PushAttrib(GLbitfield mask)
   attr->ClipPlanes = ctx->Transform.ClipPlanesEnabled;
   attr->ColorMaterial = ctx->Light.ColorMaterialEnabled;
   attr->CullFace = ctx->Polygon.CullFlag;
-  attr->DepthClamp = ctx->Transform.DepthClamp;
+  attr->DepthClampNear = ctx->Transform.DepthClampNear;
+  attr->DepthClampFar = ctx->Transform.DepthClampFar;
   attr->DepthTest = ctx->Depth.Test;
   attr->Dither = ctx->Color.DitherFlag;
   attr->Fog = ctx->Fog.Enabled;
@@ -627,8 +629,18 @@ pop_enable_group(struct gl_context *ctx, const struct 
gl_enable_attrib *enable)
TEST_AND_UPDATE(ctx->Light.ColorMaterialEnabled, enable->ColorMaterial,
GL_COLOR_MATERIAL);
TEST_AND_UPDATE(ctx->Polygon.CullFlag, enable->CullFace, GL_CULL_FACE);
-   TEST_AND_UPDATE(ctx->Transform.DepthClamp, enable->DepthCl

[Mesa-dev] [PATCH] xmlpool: fix script to write bytes instead of locale-formatted strings

[Ilia Mirkin]

With LANG=C, print won't output any non-ascii characters. Since we're
trying to get specific bytes onto stdout, we can just write these
directly.

Signed-off-by: Ilia Mirkin 
---
 src/util/xmlpool/gen_xmlpool.py | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/src/util/xmlpool/gen_xmlpool.py b/src/util/xmlpool/gen_xmlpool.py
index 56a67bcab55..640b1bc7d42 100644
--- a/src/util/xmlpool/gen_xmlpool.py
+++ b/src/util/xmlpool/gen_xmlpool.py
@@ -144,7 +144,8 @@ def expandMatches (matches, translations, end=None):
 if sys.version_info.major == 2:
 text = text.encode('utf-8')
 
-print(text)
+sys.stdout.write(text)
+sys.stdout.write('\n')
 
 # Expand any subsequent enum lines
 for match in matches[1:]:
@@ -157,11 +158,12 @@ def expandMatches (matches, translations, end=None):
 if sys.version_info.major == 2:
 text = text.encode('utf-8')
 
-print(text)
+sys.stdout.write(text)
+sys.stdout.write('\n')
 
 # Expand description end
 if end:
-print(end, end='')
+sys.stdout.write(end)
 
 # Compile a list of translation classes to all supported languages.
 # The first translation is always a NullTranslations.
@@ -182,9 +184,9 @@ reENUM   = re.compile 
(r'(\s*DRI_CONF_ENUM\s*\([^,]+,\s*)(gettext\s*\(\s*")(
 reDESC_END   = re.compile (r'\s*DRI_CONF_DESC_END')
 
 # Print a header
-print("/***\n"
 \
+sys.stdout.write("/***\n"
 \
 " ***THIS FILE IS GENERATED AUTOMATICALLY. DON'T EDIT!***\n" \
-" ***/")
+" ***/\n")
 
 # Process the options template and generate options.h with all
 # translations.
@@ -206,7 +208,7 @@ for line in template:
 continue
 if reLibintl_h.search (line):
 # Ignore (comment out) #include 
-print("/* %s * commented out by gen_xmlpool.py */" % line)
+sys.stdout.write("/* %s * commented out by gen_xmlpool.py */\n" % line)
 continue
 matchDESC   = reDESC  .match (line)
 matchDESC_BEGIN = reDESC_BEGIN.match (line)
@@ -222,7 +224,7 @@ for line in template:
 if sys.version_info.major == 2:
line = line.encode('utf-8')
 
-print(line, end='')
+sys.stdout.write(line)
 
 template.close()
 
-- 
2.16.4

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

Re: [Mesa-dev] [PATCH v3 3/7] mesa: Add support for AMD_depth_clamp_separate

[Sagar Ghuge]

Thank you for reviewing the patch.

On 08/23/2018 06:17 PM, Marek Olšák wrote:
> On Thu, Aug 23, 2018 at 8:18 PM, Sagar Ghuge  wrote:
>> Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
>> GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.
>>
>> Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
>> as suggested by Marek Olsak.
>>
>> Driver that enables AMD_depth_clamp_separate will only ever look at
>> DepthClampNear and DepthClampFar, as suggested by Ian Romanick.
>>
>> v2: 1) Remove unnecessary parentheses (Marek Olsak)
>> 2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE
>>GL_DEPTH_CLAMP only (Marek Olsak)
>> 3) Clamp against near and far plane separately (Marek Olsak)
>> 4) Clip point separately for near and far Z clipping plane (Marek
>>Olsak)
>>
>> v3: Clamp raster position zw to the range [min(n,f), 0] for near plane
>> and [0, max(n,f)] for far plane (Marek Olsak)
>>
>> Signed-off-by: Sagar Ghuge 
>> Reviewed-by: Ian Romanick 
>> ---
>>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 ++--
>>  src/mesa/main/attrib.c| 40 ++---
>>  src/mesa/main/enable.c|  9 ++-
>>  src/mesa/main/get.c   |  4 ++
>>  src/mesa/main/get_hash_params.py  |  2 +-
>>  src/mesa/main/mtypes.h|  1 -
>>  src/mesa/main/rastpos.c   | 59 ---
>>  src/mesa/state_tracker/st_atom_rasterizer.c   |  3 +-
>>  src/mesa/state_tracker/st_cb_drawpixels.c |  3 +-
>>  src/mesa/swrast/s_span.c  |  2 +-
>>  src/mesa/tnl/t_vb_program.c   |  6 +-
>>  src/mesa/tnl/t_vb_vertex.c|  8 ++-
>>  12 files changed, 115 insertions(+), 33 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
>> b/src/mesa/drivers/dri/i965/genX_state_upload.c
>> index c051848985..dc54cb67af 100644
>> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
>> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
>> @@ -1399,7 +1399,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>>clip.ScreenSpaceViewportYMax = 1;
>>
>>clip.ViewportXYClipTestEnable = true;
>> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
>> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
>> +   ctx->Transform.DepthClampFar);
>>
>>/* _NEW_TRANSFORM */
>>if (GEN_GEN == 5 || GEN_IS_G4X) {
>> @@ -1493,7 +1494,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>>clip.UserClipDistanceCullTestEnableBitmask =
>>   brw_vue_prog_data(brw->vs.base.prog_data)->cull_distance_mask;
>>
>> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
>> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
>> +   ctx->Transform.DepthClampFar);
>>  #endif
>>
>>/* _NEW_LIGHT */
>> @@ -2338,7 +2340,7 @@ genX(upload_cc_viewport)(struct brw_context *brw)
>> for (unsigned i = 0; i < viewport_count; i++) {
>>/* _NEW_VIEWPORT | _NEW_TRANSFORM */
>>const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
>> -  if (ctx->Transform.DepthClamp) {
>> +  if (ctx->Transform.DepthClampNear && ctx->Transform.DepthClampFar) {
>>   ccv.MinimumDepth = MIN2(vp->Near, vp->Far);
>>   ccv.MaximumDepth = MAX2(vp->Near, vp->Far);
>>} else {
>> @@ -4605,7 +4607,8 @@ genX(upload_raster)(struct brw_context *brw)
>>raster.ScissorRectangleEnable = ctx->Scissor.EnableFlags;
>>
>>/* _NEW_TRANSFORM */
>> -  if (!ctx->Transform.DepthClamp) {
>> +  if (!(ctx->Transform.DepthClampNear &&
>> +ctx->Transform.DepthClampFar)) {
>>  #if GEN_GEN >= 9
>>   raster.ViewportZFarClipTestEnable = true;
>>   raster.ViewportZNearClipTestEnable = true;
>> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
>> index cbe93ab6fa..a46fec73fd 100644
>> --- a/src/mesa/main/attrib.c
>> +++ b/src/mesa/main/attrib.c
>> @@ -72,7 +72,8 @@ struct gl_enable_attrib
>> GLbitfield ClipPlanes;
>> GLboolean ColorMaterial;
>> GLboolean CullFace;
>> -   GLboolean DepthClamp;
>> +   GLboolean DepthClampNear;
>> +   GLboolean DepthClampFar;
>> GLboolean DepthTest;
>> GLboolean Dither;
>> GLboolean Fog;
>> @@ -336,7 +337,8 @@ _mesa_PushAttrib(GLbitfield mask)
>>attr->ClipPlanes = ctx->Transform.ClipPlanesEnabled;
>>attr->ColorMaterial = ctx->Light.ColorMaterialEnabled;
>>attr->CullFace = ctx->Polygon.CullFlag;
>> -  attr->DepthClamp = ctx->Transform.DepthClamp;
>> +  attr->DepthClampNear = ctx->Transform.DepthClampNear;
>> +  attr->DepthClampFar = ctx->Transform.DepthClampFar;
>>attr->DepthTest = ctx->Depth.Test;
>>attr->Dither = ctx->Color.DitherFlag;
>>attr->Fog = ctx->Fog.Enabled;
>> @@ -

Re: [Mesa-dev] [PATCH 5/5] nir: Lower flrp differently when the alpha value is reused

[Eric Anholt]

Ian Romanick  writes:

> From: Ian Romanick 
>
> For some reason, if I did not move the regular lowering to late
> optimizations, the new lowering would never trigger.  This also means
> that the fsub lowering had to be added to late optimizations, and this
> requires "intel/compiler: Repeat nir_opt_algebraic_late until no more
> progress".
>
> The loops removed by this patch are the same loops added by
> "intel/compiler: Don't emit flrp for Gen4 or Gen5"
>
> I am CC'ing people who are responsible for drivers that set lower_flrp32
> as this patch will likely affect shader-db results for those drivers.
>
> No changes on any Gen6+ platform.

No change on vc4 in the previous patch, but this patch seems to cause
flrps to be left in my NIR, so a bunch of traces crash.


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

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

[bugzilla-daemon]

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

--- Comment #2 from i...@yahoo.com ---
(In reply to Timothy Arceri from comment #1)
> There already is asm optimized version of memcpy() in glibc. Why would we
> want to reinvent that in Mesa?
> 
> glibc should pick the right implementation for you system.

Because some implementations copy data backwards and this creates a huge
problem when it is written over PCIe.

To be clear:
for(i=0;i=0;i--) dst[i]=src[i]; // backwards copy

-- 
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 08/11] nir: Add a array-of-vector variable shrinking pass

[Jason Ekstrand]

On Thu, Aug 23, 2018 at 8:16 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> On Sat, Jul 28, 2018 at 10:44:39PM -0700, Jason Ekstrand wrote:
> > This pass looks for variables with vector or array-of-vector types and
> > narrows the type to only the components used.
> > ---
> >  src/compiler/nir/nir.h|   1 +
> >  src/compiler/nir/nir_split_vars.c | 694 ++
> >  2 files changed, 695 insertions(+)
>
> This patch and the one that enables the pass are
>
> Reviewed-by: Caio Marcelo de Oliveira Filho 
>

Thanks!


> I have some suggestions below, pick the ones you like.
>

I took all but one.  Thanks for your careful review.


> (...)
>
> > +static void
> > +mark_deref_used(nir_deref_instr *deref,
> > +nir_component_mask_t comps_read,
> > +nir_component_mask_t comps_written,
> > +nir_deref_instr *copy_deref,
> > +struct hash_table *var_usage_map,
> > +nir_variable_mode modes,
> > +void *mem_ctx)
> > +{
> > +   if (!(deref->mode & modes))
> > +  return;
> > +
> > +   nir_variable *var = nir_deref_instr_get_variable(deref);
> > +
> > +   struct vec_var_usage *usage =
> > +  get_vec_var_usage(var, var_usage_map, true, mem_ctx);
> > +   if (!usage)
> > +  return;
> > +
> > +   const unsigned num_var_components =
> > +  glsl_get_components(glsl_without_array_or_matrix(var->type));
>
> Consider at vec_var_usage creation time, setting a usage->comps (or
> similar) to "(1u << num_var_components) - 1".  Some cheap savings here
> and in other passes, also would result in less noise lines here and
> there.
>

I considered it at one point but decided against it.  After going through
the exercise at your suggestion, there were a lot more occurrences than I
thought.  Thanks!


> > +
> > +   usage->comps_read |= comps_read & ((1u << num_var_components) - 1);
> > +   usage->comps_written |= comps_written & ((1u << num_var_components)
> - 1);
> > +
> > +   struct vec_var_usage *copy_usage = NULL;
> > +   if (copy_deref) {
> > +  copy_usage = get_vec_deref_usage(copy_deref, var_usage_map, modes,
> > +   true, mem_ctx);
> > +  if (copy_usage) {
> > + if (usage->vars_copied == NULL) {
> > +usage->vars_copied = _mesa_set_create(mem_ctx,
> _mesa_hash_pointer,
> > +
> _mesa_key_pointer_equal);
> > + }
> > + _mesa_set_add(usage->vars_copied, copy_usage);
> > +  } else {
> > + usage->has_external_copy = true;
> > +  }
> > +   }
> > +
> > +   nir_deref_path path;
> > +   nir_deref_path_init(&path, deref, mem_ctx);
> > +
> > +   nir_deref_path copy_path;
> > +   if (copy_usage)
> > +  nir_deref_path_init(©_path, copy_deref, mem_ctx);
> > +
> > +   unsigned copy_i = 0;
> > +   for (unsigned i = 0; i < usage->num_levels; i++) {
> > +  struct array_level_usage *level = &usage->levels[i];
> > +  nir_deref_instr *deref = path.path[i + 1];
> > +  assert(deref->deref_type == nir_deref_type_array ||
> > + deref->deref_type == nir_deref_type_array_wildcard);
> > +
> > +  unsigned max_used;
> > +  if (deref->deref_type == nir_deref_type_array) {
> > + nir_const_value *const_index =
> > +nir_src_as_const_value(deref->arr.index);
> > + max_used = const_index ? const_index->u32[0] : UINT_MAX;
> > +  } else {
> > + /* For wildcards, we read or wrote the whole thing. */
> > + assert(deref->deref_type == nir_deref_type_array_wildcard);
> > + max_used = level->array_len - 1;
> > +
> > + if (copy_usage) {
> > +/* Match each wildcard level with the level on copy_usage */
> > +for (; copy_path.path[copy_i + 1]; copy_i++) {
> > +   if (copy_path.path[copy_i + 1]->deref_type ==
> > +   nir_deref_type_array_wildcard)
> > +  break;
> > +}
> > +struct array_level_usage *copy_level =
> > +   ©_usage->levels[copy_i++];
> > +
> > +if (level->levels_copied == NULL) {
> > +   level->levels_copied =
> > +  _mesa_set_create(mem_ctx, _mesa_hash_pointer,
> > +   _mesa_key_pointer_equal);
> > +}
> > +_mesa_set_add(level->levels_copied, copy_level);
>
> Since once level->has_external_copy is set we don't really use the
> levels_copied, maybe wrap the bootstrap/set block with if
> (!level->has_external_copy)?
>

_mesa_set_add is cheap and I think I'd rather keep track of all the
internal copies for now in case this pass changes to need them.  I could
see this triggering some time but then it's very dependent on the external
copy being hit before the internal copy.  I think I'd rather leave this one
as-is if you don't mind.


> > + } else {
> > +/* We have a wildcard and we don't know where this co

Re: [Mesa-dev] [PATCH v2 11/11] intel/nir: Enable nir_opt_find_array_copies

[Jason Ekstrand]

On Thu, Aug 23, 2018 at 5:42 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:

> On Sat, Jul 28, 2018 at 10:44:42PM -0700, Jason Ekstrand wrote:
> > We have to be a bit careful with this one because we want it to run in
> > the optimization loop but only in the first brw_nir_optimize call.
> > Later calls assume that we've lowered away copy_deref instructions and
> > we don't want to introduce any more.
> >
> > Shader-db results on Kaby Lake:
> >
> > total instructions in shared programs: 15176942 -> 15176942 (0.00%)
> > instructions in affected programs: 0 -> 0
> > helped: 0
> > HURT: 0
> >
> > In spite of the lack of any shader-db improvement, this patch completely
> > eliminates spilling in the Batman: Arkham City tessellation shaders.
> > This is because we are now able to detect that the temporary array
> > created by DXVK for storing TCS inputs is a copy of the input arrays and
> > use indirect URB reads instead of making a copy of 4.5 KiB of input data
> > and then indirecting on it with if-ladders.
> > ---
> >  src/intel/compiler/brw_nir.c | 16 +---
> >  src/intel/compiler/brw_nir.h |  3 ++-
> >  2 files changed, 11 insertions(+), 8 deletions(-)
>
> Given the comment mentioned below is added. This patch is
>
> Reviewed-by: Caio Marcelo de Oliveira Filho 
>
> There's also an optional suggestion.
>
>
>
> > diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> > index 5e9da9e1ef2..2417c0cd618 100644
> > --- a/src/intel/compiler/brw_nir.c
> > +++ b/src/intel/compiler/brw_nir.c
> > @@ -533,7 +533,7 @@ brw_nir_no_indirect_mask(const struct brw_compiler
> *compiler,
> >
> >  nir_shader *
> >  brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
> > - bool is_scalar)
> > + bool is_scalar, bool allow_copies)
> >  {
> > nir_variable_mode indirect_mask =
> >brw_nir_no_indirect_mask(compiler, nir->info.stage);
> > @@ -544,6 +544,8 @@ brw_nir_optimize(nir_shader *nir, const struct
> brw_compiler *compiler,
> >OPT(nir_split_array_vars, nir_var_local);
> >OPT(nir_shrink_vec_array_vars, nir_var_local);
> >OPT(nir_lower_vars_to_ssa);
> > +  if (allow_copies)
> > + OPT(nir_opt_find_array_copies);
> >OPT(nir_opt_copy_prop_vars);
> >
> >if (is_scalar) {
>
> Adding a comment here with a subset of your first paragraph in the commit
> message will make reduce the chance of future changes to optimize mess
> things up
>

Done.


> > @@ -664,7 +666,7 @@ brw_preprocess_nir(const struct brw_compiler
> *compiler, nir_shader *nir)
> >  nir_lower_isign64 |
> >  nir_lower_divmod64);
> >
> > -   nir = brw_nir_optimize(nir, compiler, is_scalar);
> > +   nir = brw_nir_optimize(nir, compiler, is_scalar, true);
> >
> > /* This needs to be run after the first optimization pass but before
> we
> >  * lower indirect derefs away
> > @@ -701,7 +703,7 @@ brw_preprocess_nir(const struct brw_compiler
> *compiler, nir_shader *nir)
> > nir_lower_indirect_derefs(nir, indirect_mask);
> >
> > /* Get rid of split copies */
> > -   nir = brw_nir_optimize(nir, compiler, is_scalar);
> > +   nir = brw_nir_optimize(nir, compiler, is_scalar, false);
>
> Optional: the call-sites usually have a "is_scalar" variable around,
> making that boolean parameter "self-documenting".  This is not the
> case for allow_copies.  One idea is to make this last argument a flag,
> and add an enum for the ALLOW_CREATE_DEREF_COPIES or something like.
>

I thought seriously about doing that the first time around.  Maybe I'll
cook up a follow-on patch.

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

[Mesa-dev] [Bug 107669] [bisected] wflinfo fails ctx->Const.MaxCombinedTextureImageUnits assertion

[bugzilla-daemon]

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

--- Comment #1 from Marek Olšák  ---
Here's your fix:

diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 6ba64e4e06d..51cae9dc637 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -422,7 +422,7 @@ brw_initialize_context_constants(struct brw_context *brw)
};

unsigned num_stages = 0;
-   for (int i = 0; i < MESA_SHADER_STAGES; i++) {
+   for (int i = 0; i <= MESA_SHADER_FRAGMENT; i++) {
   if (stage_exists[i])
  num_stages++;
}

Feel free to push that.

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

Re: [Mesa-dev] [PATCH v3 3/7] mesa: Add support for AMD_depth_clamp_separate

[Marek Olšák]

On Thu, Aug 23, 2018 at 8:18 PM, Sagar Ghuge  wrote:
> Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
> GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.
>
> Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
> as suggested by Marek Olsak.
>
> Driver that enables AMD_depth_clamp_separate will only ever look at
> DepthClampNear and DepthClampFar, as suggested by Ian Romanick.
>
> v2: 1) Remove unnecessary parentheses (Marek Olsak)
> 2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE
>GL_DEPTH_CLAMP only (Marek Olsak)
> 3) Clamp against near and far plane separately (Marek Olsak)
> 4) Clip point separately for near and far Z clipping plane (Marek
>Olsak)
>
> v3: Clamp raster position zw to the range [min(n,f), 0] for near plane
> and [0, max(n,f)] for far plane (Marek Olsak)
>
> Signed-off-by: Sagar Ghuge 
> Reviewed-by: Ian Romanick 
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 11 ++--
>  src/mesa/main/attrib.c| 40 ++---
>  src/mesa/main/enable.c|  9 ++-
>  src/mesa/main/get.c   |  4 ++
>  src/mesa/main/get_hash_params.py  |  2 +-
>  src/mesa/main/mtypes.h|  1 -
>  src/mesa/main/rastpos.c   | 59 ---
>  src/mesa/state_tracker/st_atom_rasterizer.c   |  3 +-
>  src/mesa/state_tracker/st_cb_drawpixels.c |  3 +-
>  src/mesa/swrast/s_span.c  |  2 +-
>  src/mesa/tnl/t_vb_program.c   |  6 +-
>  src/mesa/tnl/t_vb_vertex.c|  8 ++-
>  12 files changed, 115 insertions(+), 33 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index c051848985..dc54cb67af 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -1399,7 +1399,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>clip.ScreenSpaceViewportYMax = 1;
>
>clip.ViewportXYClipTestEnable = true;
> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
> +   ctx->Transform.DepthClampFar);
>
>/* _NEW_TRANSFORM */
>if (GEN_GEN == 5 || GEN_IS_G4X) {
> @@ -1493,7 +1494,8 @@ genX(upload_clip_state)(struct brw_context *brw)
>clip.UserClipDistanceCullTestEnableBitmask =
>   brw_vue_prog_data(brw->vs.base.prog_data)->cull_distance_mask;
>
> -  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
> +  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
> +   ctx->Transform.DepthClampFar);
>  #endif
>
>/* _NEW_LIGHT */
> @@ -2338,7 +2340,7 @@ genX(upload_cc_viewport)(struct brw_context *brw)
> for (unsigned i = 0; i < viewport_count; i++) {
>/* _NEW_VIEWPORT | _NEW_TRANSFORM */
>const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
> -  if (ctx->Transform.DepthClamp) {
> +  if (ctx->Transform.DepthClampNear && ctx->Transform.DepthClampFar) {
>   ccv.MinimumDepth = MIN2(vp->Near, vp->Far);
>   ccv.MaximumDepth = MAX2(vp->Near, vp->Far);
>} else {
> @@ -4605,7 +4607,8 @@ genX(upload_raster)(struct brw_context *brw)
>raster.ScissorRectangleEnable = ctx->Scissor.EnableFlags;
>
>/* _NEW_TRANSFORM */
> -  if (!ctx->Transform.DepthClamp) {
> +  if (!(ctx->Transform.DepthClampNear &&
> +ctx->Transform.DepthClampFar)) {
>  #if GEN_GEN >= 9
>   raster.ViewportZFarClipTestEnable = true;
>   raster.ViewportZNearClipTestEnable = true;
> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
> index cbe93ab6fa..a46fec73fd 100644
> --- a/src/mesa/main/attrib.c
> +++ b/src/mesa/main/attrib.c
> @@ -72,7 +72,8 @@ struct gl_enable_attrib
> GLbitfield ClipPlanes;
> GLboolean ColorMaterial;
> GLboolean CullFace;
> -   GLboolean DepthClamp;
> +   GLboolean DepthClampNear;
> +   GLboolean DepthClampFar;
> GLboolean DepthTest;
> GLboolean Dither;
> GLboolean Fog;
> @@ -336,7 +337,8 @@ _mesa_PushAttrib(GLbitfield mask)
>attr->ClipPlanes = ctx->Transform.ClipPlanesEnabled;
>attr->ColorMaterial = ctx->Light.ColorMaterialEnabled;
>attr->CullFace = ctx->Polygon.CullFlag;
> -  attr->DepthClamp = ctx->Transform.DepthClamp;
> +  attr->DepthClampNear = ctx->Transform.DepthClampNear;
> +  attr->DepthClampFar = ctx->Transform.DepthClampFar;
>attr->DepthTest = ctx->Depth.Test;
>attr->Dither = ctx->Color.DitherFlag;
>attr->Fog = ctx->Fog.Enabled;
> @@ -627,8 +629,18 @@ pop_enable_group(struct gl_context *ctx, const struct 
> gl_enable_attrib *enable)
> TEST_AND_UPDATE(ctx->Light.ColorMaterialEnabled, enable->ColorMaterial,
>   

Re: [Mesa-dev] [PATCH v2 08/11] nir: Add a array-of-vector variable shrinking pass

[Caio Marcelo de Oliveira Filho]

On Sat, Jul 28, 2018 at 10:44:39PM -0700, Jason Ekstrand wrote:
> This pass looks for variables with vector or array-of-vector types and
> narrows the type to only the components used.
> ---
>  src/compiler/nir/nir.h|   1 +
>  src/compiler/nir/nir_split_vars.c | 694 ++
>  2 files changed, 695 insertions(+)

This patch and the one that enables the pass are

Reviewed-by: Caio Marcelo de Oliveira Filho 

I have some suggestions below, pick the ones you like.


(...)

> +static void
> +mark_deref_used(nir_deref_instr *deref,
> +nir_component_mask_t comps_read,
> +nir_component_mask_t comps_written,
> +nir_deref_instr *copy_deref,
> +struct hash_table *var_usage_map,
> +nir_variable_mode modes,
> +void *mem_ctx)
> +{
> +   if (!(deref->mode & modes))
> +  return;
> +
> +   nir_variable *var = nir_deref_instr_get_variable(deref);
> +
> +   struct vec_var_usage *usage =
> +  get_vec_var_usage(var, var_usage_map, true, mem_ctx);
> +   if (!usage)
> +  return;
> +
> +   const unsigned num_var_components =
> +  glsl_get_components(glsl_without_array_or_matrix(var->type));

Consider at vec_var_usage creation time, setting a usage->comps (or
similar) to "(1u << num_var_components) - 1".  Some cheap savings here
and in other passes, also would result in less noise lines here and
there.

> +
> +   usage->comps_read |= comps_read & ((1u << num_var_components) - 1);
> +   usage->comps_written |= comps_written & ((1u << num_var_components) - 1);
> +
> +   struct vec_var_usage *copy_usage = NULL;
> +   if (copy_deref) {
> +  copy_usage = get_vec_deref_usage(copy_deref, var_usage_map, modes,
> +   true, mem_ctx);
> +  if (copy_usage) {
> + if (usage->vars_copied == NULL) {
> +usage->vars_copied = _mesa_set_create(mem_ctx, 
> _mesa_hash_pointer,
> +  _mesa_key_pointer_equal);
> + }
> + _mesa_set_add(usage->vars_copied, copy_usage);
> +  } else {
> + usage->has_external_copy = true;
> +  }
> +   }
> +
> +   nir_deref_path path;
> +   nir_deref_path_init(&path, deref, mem_ctx);
> +
> +   nir_deref_path copy_path;
> +   if (copy_usage)
> +  nir_deref_path_init(©_path, copy_deref, mem_ctx);
> +
> +   unsigned copy_i = 0;
> +   for (unsigned i = 0; i < usage->num_levels; i++) {
> +  struct array_level_usage *level = &usage->levels[i];
> +  nir_deref_instr *deref = path.path[i + 1];
> +  assert(deref->deref_type == nir_deref_type_array ||
> + deref->deref_type == nir_deref_type_array_wildcard);
> +
> +  unsigned max_used;
> +  if (deref->deref_type == nir_deref_type_array) {
> + nir_const_value *const_index =
> +nir_src_as_const_value(deref->arr.index);
> + max_used = const_index ? const_index->u32[0] : UINT_MAX;
> +  } else {
> + /* For wildcards, we read or wrote the whole thing. */
> + assert(deref->deref_type == nir_deref_type_array_wildcard);
> + max_used = level->array_len - 1;
> +
> + if (copy_usage) {
> +/* Match each wildcard level with the level on copy_usage */
> +for (; copy_path.path[copy_i + 1]; copy_i++) {
> +   if (copy_path.path[copy_i + 1]->deref_type ==
> +   nir_deref_type_array_wildcard)
> +  break;
> +}
> +struct array_level_usage *copy_level =
> +   ©_usage->levels[copy_i++];
> +
> +if (level->levels_copied == NULL) {
> +   level->levels_copied =
> +  _mesa_set_create(mem_ctx, _mesa_hash_pointer,
> +   _mesa_key_pointer_equal);
> +}
> +_mesa_set_add(level->levels_copied, copy_level);

Since once level->has_external_copy is set we don't really use the
levels_copied, maybe wrap the bootstrap/set block with if
(!level->has_external_copy)?


> + } else {
> +/* We have a wildcard and we don't know where this copy came 
> from,
> + * flag it and we'll know to not shorten this array.
> + */

Maybe instead of "we don't know" say that it comes from a variable
from other mode.


> +level->has_external_copy = true;
> + }
> +  }
> +
> +  if (comps_written)
> + level->max_written = MAX2(level->max_written, max_used);
> +  if (comps_read)
> + level->max_read = MAX2(level->max_read, max_used);
> +   }
> +}

(...)

> +static void
> +find_used_components_impl(nir_function_impl *impl,
> +  struct hash_table *var_usage_map,
> +  nir_variable_mode modes,
> +  void *mem_ctx)
> +{
> +   nir_foreach_block(block, impl) {
> +  nir_foreach_instr_safe(instr, block) {

Unless I'm missing

Re: [Mesa-dev] [PATCH] Add NV_fragment_shader_interlock support.

[Jason Ekstrand]

Your first version has already landed; Ken pushed it:

https://cgit.freedesktop.org/mesa/mesa/commit/src?id=7ec308d978019dd9aa0e7a756b5919e34431196d

Mind making a patch with just the release notes update?

Thanks!

--Jason

On August 22, 2018 22:57:42 Kevin Rogovin  wrote:

Hi,

My request for an account was NAK'd by the i965 maintainer. As such, I will 
post a v2 with the update to release notes requested and I hope Plamena can 
push that for me.


Best Regards,
-Kevin Rogovin

On Tue, Aug 21, 2018 at 12:39 PM Emil Velikov  wrote:
Hi Kevin,

On 20 August 2018 at 15:11, Kevin Rogovin  wrote:

Hi Plamena,

 Thankyou for the fast review. Can you push it or have someone push it? (I
do not have push rights)


You have contributed a number of good patches in Mesa, always
listening to feedback.
I would welcome if you're given commit access to the repository.

https://www.mesa3d.org/repository.html#developer
https://bugs.freedesktop.org/show_bug.cgi?id=99601

That said, can you please add a note about the new extension in the
release notes.

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


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

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

[bugzilla-daemon]

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

--- Comment #1 from Timothy Arceri  ---
There already is asm optimized version of memcpy() in glibc. Why would we want
to reinvent that in Mesa?

glibc should pick the right implementation for you system.

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

[Mesa-dev] [PATCH v3 3/7] mesa: Add support for AMD_depth_clamp_separate

[Sagar Ghuge]

Enable _mesa_PushAttrib() and _mesa_PopAttrib() to handle
GL_DEPTH_CLAMP_NEAR_AMD and GL_DEPTH_CLAMP_FAR_AMD tokens.

Remove DepthClamp, because DepthClampNear + DepthClampFar replaces it,
as suggested by Marek Olsak.

Driver that enables AMD_depth_clamp_separate will only ever look at
DepthClampNear and DepthClampFar, as suggested by Ian Romanick.

v2: 1) Remove unnecessary parentheses (Marek Olsak)
2) if AMD_depth_clamp_separate is unsupported, TEST_AND_UPDATE
   GL_DEPTH_CLAMP only (Marek Olsak)
3) Clamp against near and far plane separately (Marek Olsak)
4) Clip point separately for near and far Z clipping plane (Marek
   Olsak)

v3: Clamp raster position zw to the range [min(n,f), 0] for near plane
and [0, max(n,f)] for far plane (Marek Olsak)

Signed-off-by: Sagar Ghuge 
Reviewed-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 11 ++--
 src/mesa/main/attrib.c| 40 ++---
 src/mesa/main/enable.c|  9 ++-
 src/mesa/main/get.c   |  4 ++
 src/mesa/main/get_hash_params.py  |  2 +-
 src/mesa/main/mtypes.h|  1 -
 src/mesa/main/rastpos.c   | 59 ---
 src/mesa/state_tracker/st_atom_rasterizer.c   |  3 +-
 src/mesa/state_tracker/st_cb_drawpixels.c |  3 +-
 src/mesa/swrast/s_span.c  |  2 +-
 src/mesa/tnl/t_vb_program.c   |  6 +-
 src/mesa/tnl/t_vb_vertex.c|  8 ++-
 12 files changed, 115 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index c051848985..dc54cb67af 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -1399,7 +1399,8 @@ genX(upload_clip_state)(struct brw_context *brw)
   clip.ScreenSpaceViewportYMax = 1;
 
   clip.ViewportXYClipTestEnable = true;
-  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
+  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
+   ctx->Transform.DepthClampFar);
 
   /* _NEW_TRANSFORM */
   if (GEN_GEN == 5 || GEN_IS_G4X) {
@@ -1493,7 +1494,8 @@ genX(upload_clip_state)(struct brw_context *brw)
   clip.UserClipDistanceCullTestEnableBitmask =
  brw_vue_prog_data(brw->vs.base.prog_data)->cull_distance_mask;
 
-  clip.ViewportZClipTestEnable = !ctx->Transform.DepthClamp;
+  clip.ViewportZClipTestEnable = !(ctx->Transform.DepthClampNear &&
+   ctx->Transform.DepthClampFar);
 #endif
 
   /* _NEW_LIGHT */
@@ -2338,7 +2340,7 @@ genX(upload_cc_viewport)(struct brw_context *brw)
for (unsigned i = 0; i < viewport_count; i++) {
   /* _NEW_VIEWPORT | _NEW_TRANSFORM */
   const struct gl_viewport_attrib *vp = &ctx->ViewportArray[i];
-  if (ctx->Transform.DepthClamp) {
+  if (ctx->Transform.DepthClampNear && ctx->Transform.DepthClampFar) {
  ccv.MinimumDepth = MIN2(vp->Near, vp->Far);
  ccv.MaximumDepth = MAX2(vp->Near, vp->Far);
   } else {
@@ -4605,7 +4607,8 @@ genX(upload_raster)(struct brw_context *brw)
   raster.ScissorRectangleEnable = ctx->Scissor.EnableFlags;
 
   /* _NEW_TRANSFORM */
-  if (!ctx->Transform.DepthClamp) {
+  if (!(ctx->Transform.DepthClampNear &&
+ctx->Transform.DepthClampFar)) {
 #if GEN_GEN >= 9
  raster.ViewportZFarClipTestEnable = true;
  raster.ViewportZNearClipTestEnable = true;
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index cbe93ab6fa..a46fec73fd 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -72,7 +72,8 @@ struct gl_enable_attrib
GLbitfield ClipPlanes;
GLboolean ColorMaterial;
GLboolean CullFace;
-   GLboolean DepthClamp;
+   GLboolean DepthClampNear;
+   GLboolean DepthClampFar;
GLboolean DepthTest;
GLboolean Dither;
GLboolean Fog;
@@ -336,7 +337,8 @@ _mesa_PushAttrib(GLbitfield mask)
   attr->ClipPlanes = ctx->Transform.ClipPlanesEnabled;
   attr->ColorMaterial = ctx->Light.ColorMaterialEnabled;
   attr->CullFace = ctx->Polygon.CullFlag;
-  attr->DepthClamp = ctx->Transform.DepthClamp;
+  attr->DepthClampNear = ctx->Transform.DepthClampNear;
+  attr->DepthClampFar = ctx->Transform.DepthClampFar;
   attr->DepthTest = ctx->Depth.Test;
   attr->Dither = ctx->Color.DitherFlag;
   attr->Fog = ctx->Fog.Enabled;
@@ -627,8 +629,18 @@ pop_enable_group(struct gl_context *ctx, const struct 
gl_enable_attrib *enable)
TEST_AND_UPDATE(ctx->Light.ColorMaterialEnabled, enable->ColorMaterial,
GL_COLOR_MATERIAL);
TEST_AND_UPDATE(ctx->Polygon.CullFlag, enable->CullFace, GL_CULL_FACE);
-   TEST_AND_UPDATE(ctx->Transform.DepthClamp, enable->DepthClamp,
-   GL_DEPTH_CLAMP);
+
+   if (!ctx->Extensions.AMD_depth_cl

[Mesa-dev] [Bug 107670] Massive slowdown under specific memcpy implementations (32bit, no-SIMD, backward copy).

[bugzilla-daemon]

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

Bug ID: 107670
   Summary: Massive slowdown under specific memcpy implementations
(32bit, no-SIMD, backward copy).
   Product: Mesa
   Version: unspecified
  Hardware: x86 (IA32)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: i...@yahoo.com
QA Contact: mesa-dev@lists.freedesktop.org

I've traced the massive slowdown to the memcpy() in
"mesa/src/gallium/auxiliary/util/u_upload_mgr.c::u_upload_data()" that seems to
be used to move data from the host memory into the video card memory.

The slowdown could be observed if non-SIMD version of the glibc-2.27 function
is used (like the one that comes with the 32 bit Slackware-current). The system
mesa3d package does not exhibit the same slowdown, but it seems to be linked to
glibc-2.5.

I do suspect that the slowdown is caused by memcpy() implementation that copies
data backwards, starting from the end and moving to the beginning. This is
likely treated as non-sequential data transfer over the PCI bus (it probably
sends the full 32 bit address for every 32 bits of data).
Using SSE2 memcpy seems to avoid this problem, but I have no idea if it is
because it copies more data at once or because it copies forward.

In my benchmarks, `perf top` showed that the problematic memcpy() consumes 25%
CPU time. In a particular game benchmark, I was getting 50fps instead of 70fps.


Just replacing that memcpy() with memmove() fixed the issue for me, without
having to recompile and replace glibc.
However I do not consider it reliable fix, as there is nothing guaranteeing
that memmove() would do the right thing.


I think that the correct solution would be to create a new function
memcpy_to_pci() and having assembly implementation(s) that are specifically
crafted to maximize PCI/PCIe throughput.
The kernel has memcpy_toio/fromio(), but they don't seem to be asm optimized.
I've seen MPlayer MMX optimized mem2agpcpy() in aclib_template.c .

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

[Mesa-dev] [Bug 107669] [bisected] wflinfo fails ctx->Const.MaxCombinedTextureImageUnits assertion

[bugzilla-daemon]

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

Bug ID: 107669
   Summary: [bisected] wflinfo fails
ctx->Const.MaxCombinedTextureImageUnits assertion
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mar...@gmail.com
  Reporter: clayton.a.cr...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org

$ wflinfo --platform=gbm -a gl
ERROR: command failed
STDERR: wflinfo: ../src/mesa/main/context.c:777: check_context_limits:
Assertion `ctx->Const.MaxCombinedTextureImageUnits <=
MAX_COMBINED_TEXTURE_IMAGE_UNITS' failed.


I've bisected this failure to this commit:

commit 45f87a48f94148b484961f18a4f1ccf86f066b1c (refs/bisect/bad)
Author: Marek Olšák 
Date:   Mon Aug 6 08:32:23 2018 -0400

mesa: don't include compute resources in MAX_COMBINED_* limits

5 is the maximum number of shader stages that can be used by 1 execution
call at the same time (e.g. a draw call). The limit ensures that each
stage can use all of its binding points.

Compute is separate and doesn't need the 5x multiplier.

Tested-by: Dieter Nützel 

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

[Mesa-dev] [Bug 90311] Fail to build libglx with clang at linking stage

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

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

[Mesa-dev] [Bug 98831] Constantly increasing memory consumption in JavaFX applications

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #13 from Timothy Arceri  ---
Closing as fixed as per comment 12

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

[Mesa-dev] [Bug 103449] Mesa 17.2 cannot be built with clang and libc++

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

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

[Mesa-dev] [Bug 105904] Needed to delete mesa shader cache after driver upgrade for 32 bit wine vulkan programs to work.

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Timothy Arceri  ---
Should be fixed by:

commit  356f6673d695eb98c42d80f3c2b30fad746cdbba

radv: place pointer length into cache uuid

Thanks to reproducible builds, binary file timestamps may be identical
for both 32bit and 64bit packages when built from the same source.
This means radv will use the same cache for both 32 and 64 bit
processes, which leads to crashes.

Conveniently there is a spare byte in cache_uuid, let's place the
pointer size there.

Fixes: f4e499ec79 "radv: add initial non-conformant radv vulkan driver"

CC: 18.1 18.2 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107601
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105904
Reviewed-by: Bas Nieuwenhuizen 

-- 
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 11/11] intel/nir: Enable nir_opt_find_array_copies

[Caio Marcelo de Oliveira Filho]

On Sat, Jul 28, 2018 at 10:44:42PM -0700, Jason Ekstrand wrote:
> We have to be a bit careful with this one because we want it to run in
> the optimization loop but only in the first brw_nir_optimize call.
> Later calls assume that we've lowered away copy_deref instructions and
> we don't want to introduce any more.
> 
> Shader-db results on Kaby Lake:
> 
> total instructions in shared programs: 15176942 -> 15176942 (0.00%)
> instructions in affected programs: 0 -> 0
> helped: 0
> HURT: 0
> 
> In spite of the lack of any shader-db improvement, this patch completely
> eliminates spilling in the Batman: Arkham City tessellation shaders.
> This is because we are now able to detect that the temporary array
> created by DXVK for storing TCS inputs is a copy of the input arrays and
> use indirect URB reads instead of making a copy of 4.5 KiB of input data
> and then indirecting on it with if-ladders.
> ---
>  src/intel/compiler/brw_nir.c | 16 +---
>  src/intel/compiler/brw_nir.h |  3 ++-
>  2 files changed, 11 insertions(+), 8 deletions(-)

Given the comment mentioned below is added. This patch is

Reviewed-by: Caio Marcelo de Oliveira Filho 

There's also an optional suggestion.



> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index 5e9da9e1ef2..2417c0cd618 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -533,7 +533,7 @@ brw_nir_no_indirect_mask(const struct brw_compiler 
> *compiler,
>  
>  nir_shader *
>  brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
> - bool is_scalar)
> + bool is_scalar, bool allow_copies)
>  {
> nir_variable_mode indirect_mask =
>brw_nir_no_indirect_mask(compiler, nir->info.stage);
> @@ -544,6 +544,8 @@ brw_nir_optimize(nir_shader *nir, const struct 
> brw_compiler *compiler,
>OPT(nir_split_array_vars, nir_var_local);
>OPT(nir_shrink_vec_array_vars, nir_var_local);
>OPT(nir_lower_vars_to_ssa);
> +  if (allow_copies)
> + OPT(nir_opt_find_array_copies);
>OPT(nir_opt_copy_prop_vars);
>  
>if (is_scalar) {

Adding a comment here with a subset of your first paragraph in the commit
message will make reduce the chance of future changes to optimize mess
things up.



> @@ -664,7 +666,7 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
> nir_shader *nir)
>  nir_lower_isign64 |
>  nir_lower_divmod64);
>  
> -   nir = brw_nir_optimize(nir, compiler, is_scalar);
> +   nir = brw_nir_optimize(nir, compiler, is_scalar, true);
>  
> /* This needs to be run after the first optimization pass but before we
>  * lower indirect derefs away
> @@ -701,7 +703,7 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
> nir_shader *nir)
> nir_lower_indirect_derefs(nir, indirect_mask);
>  
> /* Get rid of split copies */
> -   nir = brw_nir_optimize(nir, compiler, is_scalar);
> +   nir = brw_nir_optimize(nir, compiler, is_scalar, false);

Optional: the call-sites usually have a "is_scalar" variable around,
making that boolean parameter "self-documenting".  This is not the
case for allow_copies.  One idea is to make this last argument a flag,
and add an enum for the ALLOW_CREATE_DEREF_COPIES or something like.


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

Re: [Mesa-dev] OpenCL Support on older AMD GPUs

[Jan Vesely]

On Thu, 2018-08-23 at 18:11 +0300, Benson Muite wrote:
> Hi,
> 
> Is there likely to be support for OpenCL on older AMD GPUs? I have tried 
> running an OpenCL benchmark 
> (https://github.com/mpicbg-scicomp/gearshifft) on an AMD A6-6420K APU 
> running Fedora 28. The code seems to partially run, but gives incorrect 
> results.
The righland APU uses VLIW4 architecture and afaik, no one with such
card has worked on clover, so bugs are expected.

was there any error during compilation or did all kernels compile OK?


> Would it be challenging to add full OpenCL 1.1 support? The GPU 
> of particular interest to me is Radeon HD 8470, caicos, which appears to 
> have WIP:
> 
> https://www.x.org/wiki/RadeonFeature
> 
> How can one help move this forward?

One immediate thing to try is to run with more up to date libclc[0].
It has seen quite a lot of activity earlier this year, and last time I
checked Fedora has not picked that up.

If that does not help, then the LLVM generates wrong code.
identifying the wrong parts and sendinng an LLVM patch (or even
reporting bug) would help there.

Contributions to LLVM would need some level of understanding the ISA
(see documents that Alex pointed to [1,2])

Jan

[0] https://git.llvm.org/git/libclc
[1] http://developer.amd.com/wordpress/media/2012/10/AMD_Evergreen-Fam
ily_Instruction_Set_Architecture.pdf
[2] http://developer.amd.com/wordpress/media/2012/10/AMD_HD_6900_Serie
s_Instruction_Set_Architecture.pdf

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

-- 
Jan Vesely 

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

[Mesa-dev] [Bug 107667] [regression, bisected] 2.5% performance drop in Middle Earth: Shadow of Mordor

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 CC||e...@anholt.net,
   ||t_arc...@yahoo.com.au

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

[Mesa-dev] [Bug 107667] [regression, bisected] 2.5% performance drop in Middle Earth: Shadow of Mordor

[bugzilla-daemon]

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

Bug ID: 107667
   Summary: [regression, bisected] 2.5% performance drop in Middle
Earth: Shadow of Mordor
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: gr.mue...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

I see a small drop of performance with current git in Shadow of Mordor using
R600_DEBUG=nir,sisched (faster option over stock).

Shadow of Mordor internal benchmark:
before: 74.7fps
after:  72.9fps
current git: 73.2fps
current git with patch reverted: 74.9fps

Above numbers are from the second run, where the shader cache is warm. The
numbers of the first run with cold cache are a lot more random even though for
some reason the fps is higher (usually between 75.2 and 76.3 fps). Thats even
more strange as the game with cold cache has short hangs when explosions
appear. 

There is also a random freeze during the benchmark run hard hanging my machine.
I dont know if the bisected patch is the cause of that but it is happening a
lot now with current git. In my testing I didnt encounter the problem before
the patch. Still could be just noise. I still dont know how to reproduce. If
anyone wants to see dmesg:
https://bugs.freedesktop.org/show_bug.cgi?id=107367#c9

glxinfo -B:

  Vendor: X.Org (0x1002)
Device: AMD Radeon HD 7900 Series (TAHITI, DRM 3.27.0,
4.18.0-2-amd-staging-drm-next-git, LLVM 8.0.0) (0x6798)
Version: 18.2.0
Accelerated: yes
Video memory: 3072MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.4
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1

git bisect bad:

dbd52585fa9fe79aabea3560cb3aaefffe544af9 is the first bad commit
commit dbd52585fa9fe79aabea3560cb3aaefffe544af9
Author: Eric Anholt 
Date:   Wed Jun 20 13:26:52 2018 -0700

st/nir: Disable varying packing when doing transform feedback.

The varying packing would result in st_nir_assign_var_locations() picking
new driver_locations, despite the pipe_stream_output already being set up
for the old driver location.  This left the gallium driver with no way to
work back to what varying was referenced by pipe_stream_output.

Fixes these tests on V3D:
dEQP-GLES3.functional.transform_feedback.random.separate.points.3
dEQP-GLES3.functional.transform_feedback.random.separate.points.7
dEQP-GLES3.functional.transform_feedback.random.separate.points.9
dEQP-GLES3.functional.transform_feedback.random.separate.triangles.3
dEQP-GLES3.functional.transform_feedback.random.separate.triangles.8

Reviewed-by: Timothy Arceri 

:04 04 67b42f008c50da7b17a15816ba76aca99e395133
2ac10eeaa23aaacc3986d91b27eef4e58375a6a8 M  src

-- 
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] gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0

[Roland Scheidegger]

Am 23.08.2018 um 22:13 schrieb Jose Fonseca:
> On 23/08/18 18:53, srol...@vmware.com wrote:
>> From: Roland Scheidegger 
>>
>> These have been removed. Unfortunately auto-upgrade doesn't work for
>> jit. (Worse, it seems we don't get a compilation error anymore when
>> compiling the shader, rather llvm will just do a call to a null
>> function in the jitted shaders making it difficult to detect when
>> intrinsics vanish.)
>>
>> Luckily the signed ones are still there, I helped convincing llvm
>> removing them is a bad idea for now, since while the unsigned ones have
>> sort of agreed-upon simplest patterns to replace them with, this is not
>> the case for the signed ones, and they require _significantly_ more
>> complex patterns - to the point that the recognition is IMHO probably
>> unlikely to ever work reliably in practice (due to other optimizations
>> interfering). (Even for the relatively trivial unsigned patterns, llvm
>> already added test cases where recognition doesn't work, unsaturated
>> add followed by saturated add may produce atrocious code.)
>> Nevertheless, it seems there's a serious quest to squash all
>> cpu-specific intrinsics going on, so I'd expect patches to nuke them as
>> well to resurface.
>>
>> Adapt the existing fallback code to match the simple patterns llvm uses
>> and hope for the best. I've verified with lp_test_blend that it does
>> produce the expected saturated assembly instructions. Though our
>> cmp/select build helpers don't use boolean masks, but it doesn't seem
>> to interfere with llvm's ability to recognize the pattern.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106231
>> ---
>>   src/gallium/auxiliary/gallivm/lp_bld_arit.c | 87 ++---
>>   1 file changed, 60 insertions(+), 27 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> index e922474ef61..f348833206b 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
>> @@ -557,23 +557,27 @@ lp_build_add(struct lp_build_context *bld,
>>     if (!type.floating && !type.fixed) {
>>    if (type.width * type.length == 128) {
>>   if (util_cpu_caps.has_sse2) {
>> -  if (type.width == 8)
>> -    intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
>> "llvm.x86.sse2.paddus.b";
>> -  if (type.width == 16)
>> -    intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
>> "llvm.x86.sse2.paddus.w";
>> +   if (type.width == 8)
>> + intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
>> + HAVE_LLVM < 0x0800 ?
>> "llvm.x86.sse2.paddus.b" : NULL;
>> +   if (type.width == 16)
>> + intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
>> + HAVE_LLVM < 0x0800 ?
>> "llvm.x86.sse2.paddus.w" : NULL;
>>   } else if (util_cpu_caps.has_altivec) {
>> -  if (type.width == 8)
>> - intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" :
>> "llvm.ppc.altivec.vaddubs";
>> -  if (type.width == 16)
>> - intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" :
>> "llvm.ppc.altivec.vadduhs";
>> +   if (type.width == 8)
>> +  intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs"
>> : "llvm.ppc.altivec.vaddubs";
>> +   if (type.width == 16)
>> +  intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs"
>> : "llvm.ppc.altivec.vadduhs";
>>   }
>>    }
>>    if (type.width * type.length == 256) {
>>   if (util_cpu_caps.has_avx2) {
>> -  if (type.width == 8)
>> -    intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
>> "llvm.x86.avx2.paddus.b";
>> -  if (type.width == 16)
>> -    intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
>> "llvm.x86.avx2.paddus.w";
>> +   if (type.width == 8)
>> +  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
>> +  HAVE_LLVM < 0x0800 ?
>> "llvm.x86.avx2.paddus.b" : NULL;
>> +   if (type.width == 16)
>> +  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
>> +  HAVE_LLVM < 0x0800 ?
>> "llvm.x86.avx2.paddus.w" : NULL;
>>   }
>>    }
>>     }
>> @@ -592,8 +596,6 @@ lp_build_add(struct lp_build_context *bld,
>>    LLVMValueRef a_clamp_max = lp_build_min_simple(bld, a,
>> LLVMBuildSub(builder, max_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
>>    LLVMValueRef a_clamp_min = lp_build_max_simple(bld, a,
>> LLVMBuildSub(builder, min_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
>>    a = lp_build_select(bld, lp_build_cmp(bld,
>> PIPE_FUNC_GREATER, b, bld->zero), a_clamp_max, a_clamp_min);
>> -  } else {
>>

Re: [Mesa-dev] [PATCH] gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0

[Jose Fonseca]

On 23/08/18 18:53, srol...@vmware.com wrote:

From: Roland Scheidegger 

These have been removed. Unfortunately auto-upgrade doesn't work for
jit. (Worse, it seems we don't get a compilation error anymore when
compiling the shader, rather llvm will just do a call to a null
function in the jitted shaders making it difficult to detect when
intrinsics vanish.)

Luckily the signed ones are still there, I helped convincing llvm
removing them is a bad idea for now, since while the unsigned ones have
sort of agreed-upon simplest patterns to replace them with, this is not
the case for the signed ones, and they require _significantly_ more
complex patterns - to the point that the recognition is IMHO probably
unlikely to ever work reliably in practice (due to other optimizations
interfering). (Even for the relatively trivial unsigned patterns, llvm
already added test cases where recognition doesn't work, unsaturated
add followed by saturated add may produce atrocious code.)
Nevertheless, it seems there's a serious quest to squash all
cpu-specific intrinsics going on, so I'd expect patches to nuke them as
well to resurface.

Adapt the existing fallback code to match the simple patterns llvm uses
and hope for the best. I've verified with lp_test_blend that it does
produce the expected saturated assembly instructions. Though our
cmp/select build helpers don't use boolean masks, but it doesn't seem
to interfere with llvm's ability to recognize the pattern.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106231
---
  src/gallium/auxiliary/gallivm/lp_bld_arit.c | 87 ++---
  1 file changed, 60 insertions(+), 27 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index e922474ef61..f348833206b 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -557,23 +557,27 @@ lp_build_add(struct lp_build_context *bld,
if (!type.floating && !type.fixed) {
   if (type.width * type.length == 128) {
  if (util_cpu_caps.has_sse2) {
-  if (type.width == 8)
-intrinsic = type.sign ? "llvm.x86.sse2.padds.b" : 
"llvm.x86.sse2.paddus.b";
-  if (type.width == 16)
-intrinsic = type.sign ? "llvm.x86.sse2.padds.w" : 
"llvm.x86.sse2.paddus.w";
+   if (type.width == 8)
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
+ HAVE_LLVM < 0x0800 ? 
"llvm.x86.sse2.paddus.b" : NULL;
+   if (type.width == 16)
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
+ HAVE_LLVM < 0x0800 ? 
"llvm.x86.sse2.paddus.w" : NULL;
  } else if (util_cpu_caps.has_altivec) {
-  if (type.width == 8)
- intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
"llvm.ppc.altivec.vaddubs";
-  if (type.width == 16)
- intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" : 
"llvm.ppc.altivec.vadduhs";
+   if (type.width == 8)
+  intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
"llvm.ppc.altivec.vaddubs";
+   if (type.width == 16)
+  intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" : 
"llvm.ppc.altivec.vadduhs";
  }
   }
   if (type.width * type.length == 256) {
  if (util_cpu_caps.has_avx2) {
-  if (type.width == 8)
-intrinsic = type.sign ? "llvm.x86.avx2.padds.b" : 
"llvm.x86.avx2.paddus.b";
-  if (type.width == 16)
-intrinsic = type.sign ? "llvm.x86.avx2.padds.w" : 
"llvm.x86.avx2.paddus.w";
+   if (type.width == 8)
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
+  HAVE_LLVM < 0x0800 ? 
"llvm.x86.avx2.paddus.b" : NULL;
+   if (type.width == 16)
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
+  HAVE_LLVM < 0x0800 ? 
"llvm.x86.avx2.paddus.w" : NULL;
  }
   }
}
@@ -592,8 +596,6 @@ lp_build_add(struct lp_build_context *bld,
   LLVMValueRef a_clamp_max = lp_build_min_simple(bld, a, LLVMBuildSub(builder, 
max_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
   LLVMValueRef a_clamp_min = lp_build_max_simple(bld, a, LLVMBuildSub(builder, 
min_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
   a = lp_build_select(bld, lp_build_cmp(bld, PIPE_FUNC_GREATER, b, 
bld->zero), a_clamp_max, a_clamp_min);
-  } else {
- a = lp_build_min_simple(bld, a, lp_build_comp(bld, b), 
GALLIVM_NAN_BEHAVIOR_UNDEFINED);


Why you removed this?


}
 }
  
@@ -612,6 +614,24 @@ lp_build_add(struct lp_build_context *bld,

 if(bld->type.norm && (bld->type.floating || bld->type.fixed))
res = lp_build_min_simple(bld, r

[Mesa-dev] [PATCH] i965: Replace checks for rb->Name with FlipY (v2)

[Fritz Koenig]

In the GL_MESA_framebuffer_flip_y implementation
_mesa_is_winsys_fbo checks were replaced with
FlipY checks.  rb->Name is also used to determine
if a buffer is winsys.

v2: Fixes annotation [for emil]

Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
---
 src/mesa/drivers/dri/i965/brw_blorp.c| 20 +---
 src/mesa/drivers/dri/i965/intel_pixel_read.c |  4 ++--
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 7476cee43a..7c232f6ba9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1220,12 +1220,12 @@ do_single_blorp_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
x0 = fb->_Xmin;
x1 = fb->_Xmax;
-   if (rb->Name != 0) {
-  y0 = fb->_Ymin;
-  y1 = fb->_Ymax;
-   } else {
+   if (fb->FlipY) {
   y0 = rb->Height - fb->_Ymax;
   y1 = rb->Height - fb->_Ymin;
+   } else {
+  y0 = fb->_Ymin;
+  y1 = fb->_Ymax;
}
 
/* If the clear region is empty, just return. */
@@ -1411,9 +1411,8 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
if (!(mask & (BUFFER_BITS_DEPTH_STENCIL)))
   return;
 
-   uint32_t x0, x1, y0, y1, rb_name, rb_height;
+   uint32_t x0, x1, y0, y1, rb_height;
if (depth_rb) {
-  rb_name = depth_rb->Name;
   rb_height = depth_rb->Height;
   if (stencil_rb) {
  assert(depth_rb->Width == stencil_rb->Width);
@@ -1421,18 +1420,17 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
   }
} else {
   assert(stencil_rb);
-  rb_name = stencil_rb->Name;
   rb_height = stencil_rb->Height;
}
 
x0 = fb->_Xmin;
x1 = fb->_Xmax;
-   if (rb_name != 0) {
-  y0 = fb->_Ymin;
-  y1 = fb->_Ymax;
-   } else {
+   if (fb->FlipY) {
   y0 = rb_height - fb->_Ymax;
   y1 = rb_height - fb->_Ymin;
+   } else {
+  y0 = fb->_Ymin;
+  y1 = fb->_Ymax;
}
 
/* If the clear region is empty, just return. */
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c 
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index 6ed7895bc7..8a90b207ad 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -181,7 +181,7 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
 * tiled_to_linear a negative pitch so that it walks through the
 * client's data backwards as it walks through the renderbufer forwards.
 */
-   if (rb->Name == 0) {
+   if (ctx->ReadBuffer->FlipY) {
   yoffset = rb->Height - yoffset - height;
   pixels += (ptrdiff_t) (height - 1) * dst_pitch;
   dst_pitch = -dst_pitch;
@@ -249,7 +249,7 @@ intel_readpixels_blorp(struct gl_context *ctx,
return brw_blorp_download_miptree(brw, irb->mt, rb->Format, swizzle,
  irb->mt_level, x, y, irb->mt_layer,
  w, h, 1, GL_TEXTURE_2D, format, type,
- rb->Name == 0, pixels, packing);
+ ctx->ReadBuffer->FlipY, pixels, packing);
 }
 
 void
-- 
2.18.0.1017.ga543ac7ca45-goog

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

Re: [Mesa-dev] [PATCH] i965: Replace checks for rb->Name with FlipY

[Fritz Koenig]

On Thu, Aug 23, 2018 at 11:01 AM Emil Velikov  wrote:
>
> On Thu, 23 Aug 2018 at 18:41, Emil Velikov  wrote:
> >
> > Hi Fritz,
> >
> > On Wed, 22 Aug 2018 at 23:01, Fritz Koenig  wrote:
> > >
> > > In the GL_MESA_framebuffer_flip_y implementation
> > > _mesa_is_winsys_fbo checks were replaced with
> > > FlipY checks.  rb->Name is also used to determine
> > > if a buffer is winsys.
> >
> > This seems like it fixes your earlier patch, so you normally want a
> > fixes tag. Something like the following should be fine.
> > It adds nice reference tracking, allowing the release manager to track
> > and land in the correct stable branches.
> >
> > Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")

Thanks for the heads up on this, I'll work on getting a changed commit
message out.

> >
> Quick grep shows a number of rb->Name instances in intel_fbo.c - DBG
> and assert statements.
> If they should stay as-is, perhaps it'll be better to add some comments?
>

The one assert I see is in intel_alloc_window_storage and that one
should stay.  That function should only be called with a windows
system framebuffer.

The debug statements are a little trickier.  In intel_map_renderbuffer
it is trivial to change to printing the flip_y out, but in
intel_unmap_renderbuffer it's harder to do because flip_y is not
present.  It's associated with a framebuffer, not a renderbuffer.  I
don't think adding flip_y and removing rb->Name is desired here.
rb->Name is an integer, those two statements usefulness appears to
come from correlating mapping and unmapping of buffers.  So I don't
think removing rb->Name would be worthwhile.


> Just a fly-by idea.
> -Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Replace checks for rb->Name with FlipY

[Emil Velikov]

On Thu, 23 Aug 2018 at 18:41, Emil Velikov  wrote:
>
> Hi Fritz,
>
> On Wed, 22 Aug 2018 at 23:01, Fritz Koenig  wrote:
> >
> > In the GL_MESA_framebuffer_flip_y implementation
> > _mesa_is_winsys_fbo checks were replaced with
> > FlipY checks.  rb->Name is also used to determine
> > if a buffer is winsys.
>
> This seems like it fixes your earlier patch, so you normally want a
> fixes tag. Something like the following should be fine.
> It adds nice reference tracking, allowing the release manager to track
> and land in the correct stable branches.
>
> Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
>
Quick grep shows a number of rb->Name instances in intel_fbo.c - DBG
and assert statements.
If they should stay as-is, perhaps it'll be better to add some comments?

Just a fly-by idea.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 1/4] gallium: Add a helper for implementing PIPE_CAP_* default values.

[Eric Anholt]

One of the pains of implementing a gallium driver is filling in a million
pipe caps you don't know about yet when you're just starting out.  One of
the pains of working on gallium is copy-and-pasting your new PIPE_CAP into
each driver.  We can fix both of these by having each driver call into the
default helper from their default case, so that both sides can ignore each
other until they need to.

v2: fix i915g build, revert swr change to avoid breaking scons build
(https://travis-ci.org/anholt/mesa/jobs/419739857)

Reviewed-by: Marek Olšák  (v1)
Cc: Bruce Cherniak 
Cc: George Kyriazis 
Cc: Kenneth Graunke 
---
 src/gallium/auxiliary/Makefile.sources|   2 +
 src/gallium/auxiliary/meson.build |   2 +
 src/gallium/auxiliary/util/u_screen.c | 316 ++
 src/gallium/auxiliary/util/u_screen.h |  29 ++
 src/gallium/drivers/etnaviv/etnaviv_screen.c  |   6 +-
 .../drivers/freedreno/freedreno_screen.c  |   5 +-
 src/gallium/drivers/i915/i915_screen.c|   5 +-
 src/gallium/drivers/llvmpipe/lp_screen.c  |   7 +-
 .../drivers/nouveau/nv30/nv30_screen.c|   6 +-
 .../drivers/nouveau/nv50/nv50_screen.c|   6 +-
 .../drivers/nouveau/nvc0/nvc0_screen.c|   6 +-
 src/gallium/drivers/r300/r300_screen.c|   4 +-
 src/gallium/drivers/r600/r600_pipe.c  |   4 +-
 src/gallium/drivers/radeonsi/si_get.c |   5 +-
 src/gallium/drivers/softpipe/sp_screen.c  |   6 +-
 src/gallium/drivers/svga/svga_screen.c|   6 +-
 src/gallium/drivers/v3d/v3d_screen.c  |   4 +-
 src/gallium/drivers/vc4/vc4_screen.c  |   4 +-
 src/gallium/drivers/virgl/virgl_screen.c  |   6 +-
 19 files changed, 394 insertions(+), 35 deletions(-)
 create mode 100644 src/gallium/auxiliary/util/u_screen.c
 create mode 100644 src/gallium/auxiliary/util/u_screen.h

diff --git a/src/gallium/auxiliary/Makefile.sources 
b/src/gallium/auxiliary/Makefile.sources
index 626cde123afd..d66fa85f798d 100644
--- a/src/gallium/auxiliary/Makefile.sources
+++ b/src/gallium/auxiliary/Makefile.sources
@@ -317,6 +317,8 @@ C_SOURCES := \
util/u_ringbuffer.h \
util/u_sampler.c \
util/u_sampler.h \
+   util/u_screen.c \
+   util/u_screen.h \
util/u_simple_shaders.c \
util/u_simple_shaders.h \
util/u_split_prim.h \
diff --git a/src/gallium/auxiliary/meson.build 
b/src/gallium/auxiliary/meson.build
index 858c9d0c79c0..be558e07b279 100644
--- a/src/gallium/auxiliary/meson.build
+++ b/src/gallium/auxiliary/meson.build
@@ -337,6 +337,8 @@ files_libgallium = files(
   'util/u_ringbuffer.h',
   'util/u_sampler.c',
   'util/u_sampler.h',
+  'util/u_screen.c',
+  'util/u_screen.h',
   'util/u_simple_shaders.c',
   'util/u_simple_shaders.h',
   'util/u_split_prim.h',
diff --git a/src/gallium/auxiliary/util/u_screen.c 
b/src/gallium/auxiliary/util/u_screen.c
new file mode 100644
index ..18475fcf1377
--- /dev/null
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -0,0 +1,316 @@
+/*
+ * Copyright © 2018 Broadcom
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "pipe/p_screen.h"
+#include "util/u_screen.h"
+
+/**
+ * Helper to use from a pipe_screen->get_param() implementation to return
+ * default values for unsupported PIPE_CAPs.
+ *
+ * Call this function from your pipe_screen->get_param() implementation's
+ * default case, so that implementors of new pipe caps don't need to
+ */
+int
+u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,
+ enum pipe_cap param)
+{
+   /* Let's keep these sorted by position in p_defines.h. */
+   switch (param) {
+   case PIPE_CAP_NPOT_TEXTURES:
+   case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
+   case PIPE_CAP_ANISOTROPIC_FILTER:
+   case PIPE_CAP_POINT_SPRITE:
+  return 0;
+
+   case PIPE_CAP_MAX_RENDER_TARGETS:
+  return 1;
+
+   case PIPE_C

[Mesa-dev] [PATCH v2 2/4] vc4: Drop a bunch of duplicated gallium PIPE_CAP default code.

[Eric Anholt]

Now that we have the util function for the default values, we can get rid
of the boilerplate.

v2: drop GLSL level in favor of defaults.
---
 src/gallium/auxiliary/util/u_screen.c |   6 +-
 src/gallium/drivers/vc4/vc4_screen.c  | 175 --
 2 files changed, 1 insertion(+), 180 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_screen.c 
b/src/gallium/auxiliary/util/u_screen.c
index 18475fcf1377..f74dbb2e0f71 100644
--- a/src/gallium/auxiliary/util/u_screen.c
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -63,11 +63,7 @@ u_pipe_screen_get_param_defaults(struct pipe_screen *pscreen,
case PIPE_CAP_PRIMITIVE_RESTART:
case PIPE_CAP_INDEP_BLEND_ENABLE:
case PIPE_CAP_INDEP_BLEND_FUNC:
-  return 0;
-
-   case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS:
-  unreachable("driver must implement these.");
-
+   case PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS: /* Enables GL_EXT_texture_array */
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index feed9a97f31b..13fd5ac54401 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -144,8 +144,6 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_BLEND_EQUATION_SEPARATE:
 case PIPE_CAP_TEXTURE_MULTISAMPLE:
 case PIPE_CAP_TEXTURE_SWIZZLE:
-case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
-case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
 case PIPE_CAP_TEXTURE_BARRIER:
 return 1;
 
@@ -161,16 +159,6 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_POINT_SPRITE:
 return 1;
 
-case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
-return 256;
-
-case PIPE_CAP_GLSL_FEATURE_LEVEL:
-   case PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY:
-return 120;
-
-case PIPE_CAP_MAX_VIEWPORTS:
-return 1;
-
 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
 case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
 return 1;
@@ -179,143 +167,6 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
 return 1;
 
-/* Unsupported features. */
-case PIPE_CAP_ANISOTROPIC_FILTER:
-case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
-case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
-case PIPE_CAP_CUBE_MAP_ARRAY:
-case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
-case PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR:
-case PIPE_CAP_MIXED_COLORBUFFER_FORMATS:
-case PIPE_CAP_SEAMLESS_CUBE_MAP:
-case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
-case PIPE_CAP_TGSI_INSTANCEID:
-case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_COMPUTE:
-case PIPE_CAP_START_INSTANCE:
-case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
-case PIPE_CAP_SHADER_STENCIL_EXPORT:
-case PIPE_CAP_TGSI_TEXCOORD:
-case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
-case PIPE_CAP_CONDITIONAL_RENDER:
-case PIPE_CAP_PRIMITIVE_RESTART:
-case PIPE_CAP_SM3:
-case PIPE_CAP_INDEP_BLEND_ENABLE:
-case PIPE_CAP_INDEP_BLEND_FUNC:
-case PIPE_CAP_DEPTH_CLIP_DISABLE:
-case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
-case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
-case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER:
-case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
-case PIPE_CAP_USER_VERTEX_BUFFERS:
-case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
-case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
-case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
-case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
-case PIPE_CAP_TEXTURE_GATHER_SM5:
-case PIPE_CAP_FAKE_SW_MSAA:
-case PIPE_CAP_TEXTURE_QUERY_LOD:
-case PIPE_CAP_SAMPLE_SHADING:
-case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
-case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
-case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
-case PIPE_CAP_MAX_TEXEL_OFFSET:
-case PIPE_CAP_MAX_VERTEX_STREAMS:
-case PIPE_CAP_DRAW_INDIRECT:
-case PIPE_CAP_MULTI_DRAW_INDIRECT:
-case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
-case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
-case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
-case PIPE_CAP_SAMPLER_VIEW_TARGET:
-case PIPE_CAP_CLIP_HALFZ:
-case PIPE_CAP_VERTEXID_NOBASE:
-case PIPE_CAP_POLYGON_OFFSET_CLAMP:
-case PIPE_CAP_MULTISAMPLE_Z_RESO

[Mesa-dev] [PATCH v2 4/4] freedreno: Drop a bunch of duplicated gallium PIPE_CAP default code.

[Eric Anholt]

Now that we have the util function for the default values, we can get rid
of the boilerplate.

Cc: Rob Clark 
---
 .../drivers/freedreno/freedreno_screen.c  | 103 +-
 1 file changed, 2 insertions(+), 101 deletions(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index d62f02e04f85..4e972aea1b06 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -210,11 +210,7 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_COMPUTE:
return has_compute(screen);
 
-   case PIPE_CAP_SHADER_STENCIL_EXPORT:
-   case PIPE_CAP_TGSI_TEXCOORD:
case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
-   case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
-   case PIPE_CAP_QUERY_MEMORY_INFO:
case PIPE_CAP_PCI_GROUP:
case PIPE_CAP_PCI_BUS:
case PIPE_CAP_PCI_DEVICE:
@@ -247,8 +243,6 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_POLYGON_OFFSET_CLAMP:
return is_a5xx(screen) || is_a6xx(screen);
 
-   case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
-   return 0;
case PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENT:
if (is_a3xx(screen)) return 16;
if (is_a4xx(screen)) return 32;
@@ -298,79 +292,11 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return 4;
return 0;
 
-   /* Unsupported features. */
-   case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
-   case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
-   case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
-   case PIPE_CAP_USER_VERTEX_BUFFERS:
-   case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
-   case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
-   case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
-   case PIPE_CAP_TEXTURE_GATHER_SM5:
-   case PIPE_CAP_SAMPLE_SHADING:
-   case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
-   case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
-   case PIPE_CAP_MULTI_DRAW_INDIRECT:
-   case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
-   case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
-   case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
-   case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
-   case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-   case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
-   case PIPE_CAP_DEPTH_BOUNDS_TEST:
-   case PIPE_CAP_TGSI_TXQS:
/* TODO if we need this, do it in nir/ir3 backend to avoid breaking 
precompile: */
case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
-   case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
-   case PIPE_CAP_CLEAR_TEXTURE:
-   case PIPE_CAP_DRAW_PARAMETERS:
-   case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
-   case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
-   case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
-   case PIPE_CAP_GENERATE_MIPMAP:
-   case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
-   case PIPE_CAP_ROBUST_BUFFER_ACCESS_BEHAVIOR:
-   case PIPE_CAP_CULL_DISTANCE:
-   case PIPE_CAP_PRIMITIVE_RESTART_FOR_PATCHES:
-   case PIPE_CAP_TGSI_VOTE:
-   case PIPE_CAP_MAX_WINDOW_RECTANGLES:
-   case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
-   case PIPE_CAP_VIEWPORT_SUBPIXEL_BITS:
-   case PIPE_CAP_TGSI_ARRAY_COMPONENTS:
-   case PIPE_CAP_TGSI_CAN_READ_OUTPUTS:
-   case PIPE_CAP_TGSI_FS_FBFETCH:
-   case PIPE_CAP_TGSI_MUL_ZERO_WINS:
-   case PIPE_CAP_DOUBLES:
-   case PIPE_CAP_INT64:
-   case PIPE_CAP_INT64_DIVMOD:
-   case PIPE_CAP_TGSI_TEX_TXF_LZ:
-   case PIPE_CAP_TGSI_CLOCK:
-   case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
-   case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
-   case PIPE_CAP_TGSI_BALLOT:
-   case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
-   case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
+   return 0;
+
case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
-   case PIPE_CAP_POST_DEPTH_COVERAGE:
-   case PIPE_CAP_BINDLESS_TEXTURE:
-   case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
-   case PIPE_CAP_QUERY_SO_OVERFLOW:
-   case PIPE_CAP_MEMOBJ:
-   case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
-   case PIPE_CAP_TILE_RASTER_ORDER:
-   case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
-   case PIPE_CAP_FRAMEBUFFER_MSAA_CONSTRAINTS:
-   case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
-   case PIPE_CAP_FENCE_SIGNAL:
-   case PIPE_CAP_CONSTBUF0_FLAGS:
-   case PIPE_CAP_PACKED_UNIFORMS:
-   case PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES:
-   case PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES:
-   case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_TRIANGLES:
-   case PIPE_CAP_CONSERVATIVE_RASTER_PRE_SNAP_POINTS_LINES:
-   case PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE:
-   case PIPE_CAP_MAX_CONSERVATIVE_RASTER_SUBPIXEL_PRECISION

[Mesa-dev] [PATCH v2 3/4] v3d: Drop a bunch of duplicated gallium PIPE_CAP default code.

[Eric Anholt]

Now that we have the util function for the default values, we can get rid
of the boilerplate.
---
 src/gallium/drivers/v3d/v3d_screen.c | 147 ---
 1 file changed, 147 deletions(-)

diff --git a/src/gallium/drivers/v3d/v3d_screen.c 
b/src/gallium/drivers/v3d/v3d_screen.c
index b305dac4b6c9..252ebb379f87 100644
--- a/src/gallium/drivers/v3d/v3d_screen.c
+++ b/src/gallium/drivers/v3d/v3d_screen.c
@@ -101,11 +101,9 @@ v3d_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_SM3:
 case PIPE_CAP_TEXTURE_QUERY_LOD:
 case PIPE_CAP_PRIMITIVE_RESTART:
-case PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY:
 case PIPE_CAP_OCCLUSION_QUERY:
 case PIPE_CAP_POINT_SPRITE:
 case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
-case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
 case PIPE_CAP_COMPUTE:
 case PIPE_CAP_DRAW_INDIRECT:
 case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
@@ -128,9 +126,6 @@ v3d_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY:
return 140;
 
-case PIPE_CAP_MAX_VIEWPORTS:
-return 1;
-
 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
 return 1;
 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_LOWER_LEFT:
@@ -151,134 +146,8 @@ v3d_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_MIXED_COLOR_DEPTH_BITS:
 return 1;
 
-
-/* Stream output. */
 case PIPE_CAP_MAX_STREAM_OUTPUT_BUFFERS:
 return 4;
-case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
-case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
-return 64;
-
-case PIPE_CAP_MIN_TEXEL_OFFSET:
-case PIPE_CAP_MIN_TEXTURE_GATHER_OFFSET:
-return -8;
-case PIPE_CAP_MAX_TEXEL_OFFSET:
-case PIPE_CAP_MAX_TEXTURE_GATHER_OFFSET:
-return 7;
-
-/* Unsupported features. */
-case PIPE_CAP_ANISOTROPIC_FILTER:
-case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
-case PIPE_CAP_BUFFER_SAMPLER_VIEW_RGBA_ONLY:
-case PIPE_CAP_CUBE_MAP_ARRAY:
-case PIPE_CAP_TEXTURE_MIRROR_CLAMP:
-case PIPE_CAP_SEAMLESS_CUBE_MAP:
-case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
-case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS:
-case PIPE_CAP_SHADER_STENCIL_EXPORT:
-case PIPE_CAP_TGSI_TEXCOORD:
-case PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER:
-case PIPE_CAP_CONDITIONAL_RENDER:
-case PIPE_CAP_TEXTURE_BARRIER:
-case PIPE_CAP_INDEP_BLEND_FUNC:
-case PIPE_CAP_DEPTH_CLIP_DISABLE:
-case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE:
-case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
-case PIPE_CAP_USER_VERTEX_BUFFERS:
-case PIPE_CAP_QUERY_PIPELINE_STATISTICS:
-case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK:
-case PIPE_CAP_TGSI_VS_LAYER_VIEWPORT:
-case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
-case PIPE_CAP_MAX_TEXTURE_GATHER_COMPONENTS:
-case PIPE_CAP_TEXTURE_GATHER_SM5:
-case PIPE_CAP_FAKE_SW_MSAA:
-case PIPE_CAP_SAMPLE_SHADING:
-case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
-case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
-case PIPE_CAP_MAX_VERTEX_STREAMS:
-case PIPE_CAP_MULTI_DRAW_INDIRECT:
-case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS:
-case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
-case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
-case PIPE_CAP_SAMPLER_VIEW_TARGET:
-case PIPE_CAP_CLIP_HALFZ:
-case PIPE_CAP_VERTEXID_NOBASE:
-case PIPE_CAP_POLYGON_OFFSET_CLAMP:
-case PIPE_CAP_MULTISAMPLE_Z_RESOLVE:
-case PIPE_CAP_RESOURCE_FROM_USER_MEMORY:
-case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
-case PIPE_CAP_MAX_SHADER_PATCH_VARYINGS:
-case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
-case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
-case PIPE_CAP_DEPTH_BOUNDS_TEST:
-case PIPE_CAP_TGSI_TXQS:
-case PIPE_CAP_FORCE_PERSAMPLE_INTERP:
-case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
-case PIPE_CAP_CLEAR_TEXTURE:
-case PIPE_CAP_DRAW_PARAMETERS:
-case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
-case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
-case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
-case PIPE_CAP_INVALIDATE_BUFFER:
-case PIPE_CAP_GENERATE_MIPMAP:
-case PIPE_CAP_STRING_MARKER:
-case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
-case PIPE_CAP_QUERY_BUFFER_OBJECT:
-case PIPE_CAP_QUERY_MEMORY_INFO:
-case PIPE_CAP_PCI_GROUP:
-case PIPE_CAP_PCI_BUS

[Mesa-dev] [PATCH] gallivm: don't use saturated unsigned add/sub intrinsics for llvm 8.0

[sroland]

From: Roland Scheidegger 

These have been removed. Unfortunately auto-upgrade doesn't work for
jit. (Worse, it seems we don't get a compilation error anymore when
compiling the shader, rather llvm will just do a call to a null
function in the jitted shaders making it difficult to detect when
intrinsics vanish.)

Luckily the signed ones are still there, I helped convincing llvm
removing them is a bad idea for now, since while the unsigned ones have
sort of agreed-upon simplest patterns to replace them with, this is not
the case for the signed ones, and they require _significantly_ more
complex patterns - to the point that the recognition is IMHO probably
unlikely to ever work reliably in practice (due to other optimizations
interfering). (Even for the relatively trivial unsigned patterns, llvm
already added test cases where recognition doesn't work, unsaturated
add followed by saturated add may produce atrocious code.)
Nevertheless, it seems there's a serious quest to squash all
cpu-specific intrinsics going on, so I'd expect patches to nuke them as
well to resurface.

Adapt the existing fallback code to match the simple patterns llvm uses
and hope for the best. I've verified with lp_test_blend that it does
produce the expected saturated assembly instructions. Though our
cmp/select build helpers don't use boolean masks, but it doesn't seem
to interfere with llvm's ability to recognize the pattern.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106231
---
 src/gallium/auxiliary/gallivm/lp_bld_arit.c | 87 ++---
 1 file changed, 60 insertions(+), 27 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_arit.c 
b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
index e922474ef61..f348833206b 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_arit.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_arit.c
@@ -557,23 +557,27 @@ lp_build_add(struct lp_build_context *bld,
   if (!type.floating && !type.fixed) {
  if (type.width * type.length == 128) {
 if (util_cpu_caps.has_sse2) {
-  if (type.width == 8)
-intrinsic = type.sign ? "llvm.x86.sse2.padds.b" : 
"llvm.x86.sse2.paddus.b";
-  if (type.width == 16)
-intrinsic = type.sign ? "llvm.x86.sse2.padds.w" : 
"llvm.x86.sse2.paddus.w";
+   if (type.width == 8)
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.b" :
+ HAVE_LLVM < 0x0800 ? 
"llvm.x86.sse2.paddus.b" : NULL;
+   if (type.width == 16)
+ intrinsic = type.sign ? "llvm.x86.sse2.padds.w" :
+ HAVE_LLVM < 0x0800 ? 
"llvm.x86.sse2.paddus.w" : NULL;
 } else if (util_cpu_caps.has_altivec) {
-  if (type.width == 8)
- intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
"llvm.ppc.altivec.vaddubs";
-  if (type.width == 16)
- intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" : 
"llvm.ppc.altivec.vadduhs";
+   if (type.width == 8)
+  intrinsic = type.sign ? "llvm.ppc.altivec.vaddsbs" : 
"llvm.ppc.altivec.vaddubs";
+   if (type.width == 16)
+  intrinsic = type.sign ? "llvm.ppc.altivec.vaddshs" : 
"llvm.ppc.altivec.vadduhs";
 }
  }
  if (type.width * type.length == 256) {
 if (util_cpu_caps.has_avx2) {
-  if (type.width == 8)
-intrinsic = type.sign ? "llvm.x86.avx2.padds.b" : 
"llvm.x86.avx2.paddus.b";
-  if (type.width == 16)
-intrinsic = type.sign ? "llvm.x86.avx2.padds.w" : 
"llvm.x86.avx2.paddus.w";
+   if (type.width == 8)
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.b" :
+  HAVE_LLVM < 0x0800 ? 
"llvm.x86.avx2.paddus.b" : NULL;
+   if (type.width == 16)
+  intrinsic = type.sign ? "llvm.x86.avx2.padds.w" :
+  HAVE_LLVM < 0x0800 ? 
"llvm.x86.avx2.paddus.w" : NULL;
 }
  }
   }
@@ -592,8 +596,6 @@ lp_build_add(struct lp_build_context *bld,
  LLVMValueRef a_clamp_max = lp_build_min_simple(bld, a, 
LLVMBuildSub(builder, max_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
  LLVMValueRef a_clamp_min = lp_build_max_simple(bld, a, 
LLVMBuildSub(builder, min_val, b, ""), GALLIVM_NAN_BEHAVIOR_UNDEFINED);
  a = lp_build_select(bld, lp_build_cmp(bld, PIPE_FUNC_GREATER, b, 
bld->zero), a_clamp_max, a_clamp_min);
-  } else {
- a = lp_build_min_simple(bld, a, lp_build_comp(bld, b), 
GALLIVM_NAN_BEHAVIOR_UNDEFINED);
   }
}
 
@@ -612,6 +614,24 @@ lp_build_add(struct lp_build_context *bld,
if(bld->type.norm && (bld->type.floating || bld->type.fixed))
   res = lp_build_min_simple(bld, res, bld->one, 
GALLIVM_NAN_BEHAVIOR_UNDEFINED);
 
+   if (type.norm && !type.floating && !type.

Re: [Mesa-dev] [PATCH] i965: Replace checks for rb->Name with FlipY

[Emil Velikov]

Hi Fritz,

On Wed, 22 Aug 2018 at 23:01, Fritz Koenig  wrote:
>
> In the GL_MESA_framebuffer_flip_y implementation
> _mesa_is_winsys_fbo checks were replaced with
> FlipY checks.  rb->Name is also used to determine
> if a buffer is winsys.

This seems like it fixes your earlier patch, so you normally want a
fixes tag. Something like the following should be fine.
It adds nice reference tracking, allowing the release manager to track
and land in the correct stable branches.

Fixes: ab05dd183cc ("i965: implement GL_MESA_framebuffer_flip_y [v3]")

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

Re: [Mesa-dev] [PATCH] autotools: include git_sha1.h in dist tarball

[Emil Velikov]

On Thu, 23 Aug 2018 at 18:31, Eric Anholt  wrote:
>
> "Juan A. Suarez Romero"  writes:
>
> > On Mon, 2018-08-20 at 21:32 +0100, Eric Engestrom wrote:
> >> On Monday, 2018-08-20 14:23:28 +, Juan A. Suarez Romero wrote:
> >> > This fixes `make distcheck`.
> >> >
> >> > Fixes: 471f708ed6 ("git_sha1: simplify logic")
> >> > CC: Eric Engestrom 
> >> > ---
> >> >  src/Makefile.am | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/src/Makefile.am b/src/Makefile.am
> >> > index 396865cbe55..412510f435b 100644
> >> > --- a/src/Makefile.am
> >> > +++ b/src/Makefile.am
> >> > @@ -26,7 +26,7 @@ git_sha1.h:
> >> >
> >> >  BUILT_SOURCES = git_sha1.h
> >> >  CLEANFILES = $(BUILT_SOURCES)
> >> > -EXTRA_DIST = git_sha1.h.in meson.build
> >> > +EXTRA_DIST = git_sha1.h meson.build
> >>
> >> Hmm, I need to double-check (tomorrow), but this feels wrong to me:
> >> shouldn't we drop it from the EXTRA_DIST, so that it gets regenerated
> >> on
> >> the system using the release tarball, instead of shipping the one
> >> built
> >> from git?
> >>
> >
> > Hmm. Good question. I thought this file was generated using git
> > information, and as git is not in the distributed tarball, we should
> > distribute the generated file. There are other cases where the dist
> > tarball contains generated files, instead of regenerating them when
> > building the tarball.
> >
> > In any case, it would be good if you can double check it. I already
> > pushed this commit (as this fixes `make distcheck`) but removing the
> > file from EXTRA_DIST is straight forward.
>
> If we're building outside of a git tree (such as a tarball) I don't
> think we should include git commit IDs in our version strings, as there
> are likely random other patches on top of the tarball and thus this will
> give the mistaken impression that git_sha1.h represents the tree that
> was built.

Indeed,. Eric Engestrom addressed that with 6ff1c479968, shortly after
this patch was pushed.

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

Re: [Mesa-dev] [PATCH] autotools: include git_sha1.h in dist tarball

[Eric Anholt]

"Juan A. Suarez Romero"  writes:

> On Mon, 2018-08-20 at 21:32 +0100, Eric Engestrom wrote:
>> On Monday, 2018-08-20 14:23:28 +, Juan A. Suarez Romero wrote:
>> > This fixes `make distcheck`.
>> > 
>> > Fixes: 471f708ed6 ("git_sha1: simplify logic")
>> > CC: Eric Engestrom 
>> > ---
>> >  src/Makefile.am | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/src/Makefile.am b/src/Makefile.am
>> > index 396865cbe55..412510f435b 100644
>> > --- a/src/Makefile.am
>> > +++ b/src/Makefile.am
>> > @@ -26,7 +26,7 @@ git_sha1.h:
>> >  
>> >  BUILT_SOURCES = git_sha1.h
>> >  CLEANFILES = $(BUILT_SOURCES)
>> > -EXTRA_DIST = git_sha1.h.in meson.build
>> > +EXTRA_DIST = git_sha1.h meson.build
>> 
>> Hmm, I need to double-check (tomorrow), but this feels wrong to me:
>> shouldn't we drop it from the EXTRA_DIST, so that it gets regenerated
>> on
>> the system using the release tarball, instead of shipping the one
>> built
>> from git?
>> 
>
> Hmm. Good question. I thought this file was generated using git
> information, and as git is not in the distributed tarball, we should
> distribute the generated file. There are other cases where the dist
> tarball contains generated files, instead of regenerating them when
> building the tarball.
>
> In any case, it would be good if you can double check it. I already
> pushed this commit (as this fixes `make distcheck`) but removing the
> file from EXTRA_DIST is straight forward.

If we're building outside of a git tree (such as a tarball) I don't
think we should include git commit IDs in our version strings, as there
are likely random other patches on top of the tarball and thus this will
give the mistaken impression that git_sha1.h represents the tree that
was built.


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

Re: [Mesa-dev] [PATCH v4 12/49] meson: don't build glx or dri by default on windows

[Dylan Baker]

Quoting Eric Engestrom (2018-08-23 10:13:17)
> On Wednesday, 2018-08-22 10:04:35 -0700, Dylan Baker wrote:
> > Signed-off-by: Dylan Baker 
> > Reviewed-by: Eric Anholt 
> > ---
> >  meson.build | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 1af610573d5..5102ffe0c7c 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -264,8 +264,12 @@ if with_glx == 'auto'
> >elif with_platform_haiku
> >  with_glx = 'disabled'
> 
> How about simply adding it here, before the with_gallium check?
> 
>   +  elif host_machine.system() == 'windows'
>   +with_glx = 'disabled'
> 
> Otherwise this opens the door to a weird `(gallium + x11 + gl - vk) on
> windows` bug here.

I'm trying to understand the bug, if you build with windows dri you'll get
glx? It seems like then really we should have the first option be "if
with_dri and with_dri_platform == 'drm'" (or should it be "with_dri and not
['windows', 'apple'].contains(with_dri_platform)"?) and instead of simply
with_dri, or am I missing something?

Dylan

> With that:
> Reviewed-by: Eric Engestrom 
> 
> >elif with_gallium
> > -# Even when building just gallium drivers the user probably wants dri
> > -with_glx = 'dri'
> > +if host_machine.system() == 'windows'
> > +  with_glx = 'disabled'
> > +else
> > +  # Even when building just gallium drivers the user probably wants dri
> > +  with_glx = 'dri'
> > +endif
> >elif with_platform_x11 and with_any_opengl and not with_any_vk
> >  # The automatic behavior should not be to turn on xlib based glx when
> >  # building only vulkan drivers
> > -- 
> > 2.18.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 v4 12/49] meson: don't build glx or dri by default on windows

[Eric Engestrom]

On Wednesday, 2018-08-22 10:04:35 -0700, Dylan Baker wrote:
> Signed-off-by: Dylan Baker 
> Reviewed-by: Eric Anholt 
> ---
>  meson.build | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 1af610573d5..5102ffe0c7c 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -264,8 +264,12 @@ if with_glx == 'auto'
>elif with_platform_haiku
>  with_glx = 'disabled'

How about simply adding it here, before the with_gallium check?

  +  elif host_machine.system() == 'windows'
  +with_glx = 'disabled'

Otherwise this opens the door to a weird `(gallium + x11 + gl - vk) on
windows` bug here.

With that:
Reviewed-by: Eric Engestrom 

>elif with_gallium
> -# Even when building just gallium drivers the user probably wants dri
> -with_glx = 'dri'
> +if host_machine.system() == 'windows'
> +  with_glx = 'disabled'
> +else
> +  # Even when building just gallium drivers the user probably wants dri
> +  with_glx = 'dri'
> +endif
>elif with_platform_x11 and with_any_opengl and not with_any_vk
>  # The automatic behavior should not be to turn on xlib based glx when
>  # building only vulkan drivers
> -- 
> 2.18.0
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #8 from Samuel Pitoiset  ---
Created attachment 141256
  --> https://bugs.freedesktop.org/attachment.cgi?id=141256&action=edit
possible fix

Can you apply this patch? It should fix the LLVM IR error.

-- 
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 v4 46/49] appveyor: use chocolatey (cinst) to install winflexbison

[Dylan Baker]

Quoting Jose Fonseca (2018-08-22 11:39:12)
> On 22/08/18 18:05, Dylan Baker wrote:
> > v2: - fix typos in commit message
> > ---
> >   appveyor.yml | 6 +-
> >   1 file changed, 1 insertion(+), 5 deletions(-)
> > 
> > diff --git a/appveyor.yml b/appveyor.yml
> > index 15a31da9411..b26a3c624e8 100644
> > --- a/appveyor.yml
> > +++ b/appveyor.yml
> > @@ -34,7 +34,6 @@ branches:
> >   clone_depth: 100
> >   
> >   cache:
> > -- win_flex_bison-2.5.9.zip
> >   - llvm-5.0.1-msvc2015-mtd.7z
> >   - subprojects\packagecache
> >   
> > @@ -46,7 +45,6 @@ init:
> >   - git config --global core.autocrlf true
> >   
> >   environment:
> > -  WINFLEXBISON_ARCHIVE: win_flex_bison-2.5.9.zip
> > LLVM_ARCHIVE: llvm-5.0.1-msvc2015-mtd.7z
> > matrix:
> >   - BUILD_SYSTEM: meson
> > @@ -72,9 +70,7 @@ install:
> >   - if "%BUILD_SYSTEM%"=="meson" ninja --version
> >   - if "%BUILD_SYSTEM%"=="meson" call "C:\Program Files (x86)\Microsoft 
> > Visual Studio 14.0\VC\vcvarsall.bat" x86
> >   # Install flex/bison
> > -- if not exist "%WINFLEXBISON_ARCHIVE%" appveyor DownloadFile 
> > "https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdownloads.sourceforge.net%2Fproject%2Fwinflexbison%2Fold_versions%2F%25WINFLEXBISON_ARCHIVE%25&data=02%7C01%7Cjfonseca%40vmware.com%7C075d2af0e3d4415da59f08d6085217c0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636705546029228240&sdata=yX%2BTOaizEhvzgHGwArmD4BQcJ54Tr5FCo8H6jFX1DN0%3D&reserved=0";
> > -- 7z x -y -owinflexbison\ "%WINFLEXBISON_ARCHIVE%" > nul
> > -- set Path=%CD%\winflexbison;%Path%
> > +- cinst -y winflexbison
> >   - win_flex --version
> >   - win_bison --version
> >   # Download and extract LLVM
> > 
> 
> I'm afraid this is a bad idea, because AppVeyor -> SourceForge downloads 
> are not very reliable.
> 
> IIRC, we used to get winflex via cinst, but abandoned because of this.
> 
> Jose

That is very unfortunate, manually downloading and unpacking files and setting
PATH is such a pain compared to a simple cinst. I'll go ahead and drop this
patch.

Dylan


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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

Kristoffer  changed:

   What|Removed |Added

 CC||bri...@outlook.com

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

Re: [Mesa-dev] OpenCL Support on older AMD GPUs

[Alex Deucher]

On Thu, Aug 23, 2018 at 11:30 AM Benson Muite  wrote:
>
> Hi,
>
> Is there likely to be support for OpenCL on older AMD GPUs? I have tried 
> running an OpenCL benchmark (https://github.com/mpicbg-scicomp/gearshifft) on 
> an AMD A6-6420K APU running Fedora 28. The code seems to partially run, but 
> gives incorrect results. Would it be challenging to add full OpenCL 1.1 
> support? The GPU of particular interest to me is Radeon HD 8470, caicos, 
> which appears to have WIP:
>
> https://www.x.org/wiki/RadeonFeature
>
> How can one help move this forward?

Improve the OpenCL driver in mesa.  The shader ISA documents are
available on developer.amd.com and you can use the compute shader
support in the r600 OpenGL driver as a reference.

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

[Mesa-dev] [Bug 106187] Vulkan apps run on secondary GPU on multi-GPU system

[bugzilla-daemon]

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||s...@whiz.se

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

Re: [Mesa-dev] [PATCH 2/3] configure: allow building with python3

[Emil Velikov]

On Thu, 23 Aug 2018 at 15:59, Eric Engestrom  wrote:
>
> On Thursday, 2018-08-23 15:34:29 +0100, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > Pretty much all of the scripts are python2+3 compatible.
> > Check and allow using python3, while adjusting the PYTHON2 refs.
> >
> > Note:
> >  - python3.4 is used as it's the earliest supported version
> >  - python3 is chosen prior to python2
> >
> > Signed-off-by: Emil Velikov 
>
> Not fully double-checked, but +1 on the idea and a skim through didn't
> notice anything.
>
> Acked-by: Eric Engestrom 
>
Thanks. A quick sanity check with git grep -w PYTHON2.
And an extra on top is a Travis run [1]

I'll push these in a moment.
-Emil

[1] https://travis-ci.org/evelikov/Mesa/builds/419665154
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] vulkan/alloc: Add a vk_strdup helper

[Jason Ekstrand]

On Thu, Aug 23, 2018 at 10:34 AM Grazvydas Ignotas 
wrote:

> On Thu, Aug 23, 2018 at 6:13 PM, Jason Ekstrand 
> wrote:
> > ---
> >  src/vulkan/util/vk_alloc.h | 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/src/vulkan/util/vk_alloc.h b/src/vulkan/util/vk_alloc.h
> > index f58a80625a8..bc2bb7509e4 100644
> > --- a/src/vulkan/util/vk_alloc.h
> > +++ b/src/vulkan/util/vk_alloc.h
> > @@ -67,6 +67,23 @@ vk_free(const VkAllocationCallbacks *alloc, void
> *data)
> > alloc->pfnFree(alloc->pUserData, data);
> >  }
> >
> > +static inline char *
> > +vk_strdup(const VkAllocationCallbacks *alloc, const char *s,
> > +  VkSystemAllocationScope scope)
> > +{
> > +   if (s == NULL)
> > +  return NULL;
> > +
> > +   size_t len = strlen(s);
> > +   char *copy = vk_alloc(alloc, len, 1, scope);
> > +   if (copy == NULL)
> > +  return NULL;
> > +
> > +   memcpy(copy, s, len);
>
> Don't you need the nul char?
>

Yes.  Not sure how I missed that. :(
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #7 from Clément Guérin  ---
Created attachment 141250
  --> https://bugs.freedesktop.org/attachment.cgi?id=141250&action=edit
shaders,preoptir,spirv.log

Here's the output logs.

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

Re: [Mesa-dev] [PATCH 1/3] vulkan/alloc: Add a vk_strdup helper

[Grazvydas Ignotas]

On Thu, Aug 23, 2018 at 6:13 PM, Jason Ekstrand  wrote:
> ---
>  src/vulkan/util/vk_alloc.h | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/src/vulkan/util/vk_alloc.h b/src/vulkan/util/vk_alloc.h
> index f58a80625a8..bc2bb7509e4 100644
> --- a/src/vulkan/util/vk_alloc.h
> +++ b/src/vulkan/util/vk_alloc.h
> @@ -67,6 +67,23 @@ vk_free(const VkAllocationCallbacks *alloc, void *data)
> alloc->pfnFree(alloc->pUserData, data);
>  }
>
> +static inline char *
> +vk_strdup(const VkAllocationCallbacks *alloc, const char *s,
> +  VkSystemAllocationScope scope)
> +{
> +   if (s == NULL)
> +  return NULL;
> +
> +   size_t len = strlen(s);
> +   char *copy = vk_alloc(alloc, len, 1, scope);
> +   if (copy == NULL)
> +  return NULL;
> +
> +   memcpy(copy, s, len);

Don't you need the nul char?

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

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #6 from Clément Guérin  ---
Created attachment 141249
  --> https://bugs.freedesktop.org/attachment.cgi?id=141249&action=edit
checkir.log

-- 
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] OpenCL Support on older AMD GPUs

[Benson Muite]

Hi,

Is there likely to be support for OpenCL on older AMD GPUs? I have tried 
running an OpenCL benchmark 
(https://github.com/mpicbg-scicomp/gearshifft) on an AMD A6-6420K APU 
running Fedora 28. The code seems to partially run, but gives incorrect 
results. Would it be challenging to add full OpenCL 1.1 support? The GPU 
of particular interest to me is Radeon HD 8470, caicos, which appears to 
have WIP:


https://www.x.org/wiki/RadeonFeature

How can one help move this forward?

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

[Mesa-dev] [PATCH 2/3] anv: Copy the appliation info into the instance

[Jason Ekstrand]

---
 src/intel/vulkan/anv_device.c  | 27 ---
 src/intel/vulkan/anv_private.h | 11 ++-
 2 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index d85615caaed..0357fc7c0ea 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -610,20 +610,33 @@ VkResult anv_CreateInstance(
else
   instance->alloc = default_alloc;
 
-   if (pCreateInfo->pApplicationInfo &&
-   pCreateInfo->pApplicationInfo->apiVersion != 0) {
-  instance->apiVersion = pCreateInfo->pApplicationInfo->apiVersion;
-   } else {
-  anv_EnumerateInstanceVersion(&instance->apiVersion);
+   instance->app_info = (struct anv_app_info) { .api_version = 0 };
+   if (pCreateInfo->pApplicationInfo) {
+  const VkApplicationInfo *app = pCreateInfo->pApplicationInfo;
+
+  instance->app_info.app_name =
+ vk_strdup(&instance->alloc, app->pApplicationName,
+   VK_SYSTEM_ALLOCATION_SCOPE_INSTANCE);
+  instance->app_info.app_version = app->applicationVersion;
+
+  instance->app_info.engine_name =
+ vk_strdup(&instance->alloc, app->pEngineName,
+   VK_SYSTEM_ALLOCATION_SCOPE_INSTANCE);
+  instance->app_info.engine_version = app->engineVersion;
+
+  instance->app_info.api_version = app->apiVersion;
}
 
+   if (instance->app_info.api_version == 0)
+  anv_EnumerateInstanceVersion(&instance->app_info.api_version);
+
instance->enabled_extensions = enabled_extensions;
 
for (unsigned i = 0; i < ARRAY_SIZE(instance->dispatch.entrypoints); i++) {
   /* Vulkan requires that entrypoints for extensions which have not been
* enabled must not be advertised.
*/
-  if (!anv_entrypoint_is_enabled(i, instance->apiVersion,
+  if (!anv_entrypoint_is_enabled(i, instance->app_info.api_version,
  &instance->enabled_extensions, NULL)) {
  instance->dispatch.entrypoints[i] = NULL;
   } else if (anv_dispatch_table.entrypoints[i] != NULL) {
@@ -1496,7 +1509,7 @@ anv_device_init_dispatch(struct anv_device *device)
   /* Vulkan requires that entrypoints for extensions which have not been
* enabled must not be advertised.
*/
-  if (!anv_entrypoint_is_enabled(i, device->instance->apiVersion,
+  if (!anv_entrypoint_is_enabled(i, device->instance->app_info.api_version,
  &device->instance->enabled_extensions,
  &device->enabled_extensions)) {
  device->dispatch.entrypoints[i] = NULL;
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 2ced8afcabe..5537c8cab57 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -882,12 +882,21 @@ struct anv_physical_device {
 int master_fd;
 };
 
+struct anv_app_info {
+   const char*app_name;
+   uint32_t   app_version;
+   const char*engine_name;
+   uint32_t   engine_version;
+   uint32_t   api_version;
+};
+
 struct anv_instance {
 VK_LOADER_DATA  _loader_data;
 
 VkAllocationCallbacks   alloc;
 
-uint32_tapiVersion;
+struct anv_app_info app_info;
+
 struct anv_instance_extension_table enabled_extensions;
 struct anv_dispatch_table   dispatch;
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/3] vulkan/alloc: Add a vk_strdup helper

[Jason Ekstrand]

---
 src/vulkan/util/vk_alloc.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/vulkan/util/vk_alloc.h b/src/vulkan/util/vk_alloc.h
index f58a80625a8..bc2bb7509e4 100644
--- a/src/vulkan/util/vk_alloc.h
+++ b/src/vulkan/util/vk_alloc.h
@@ -67,6 +67,23 @@ vk_free(const VkAllocationCallbacks *alloc, void *data)
alloc->pfnFree(alloc->pUserData, data);
 }
 
+static inline char *
+vk_strdup(const VkAllocationCallbacks *alloc, const char *s,
+  VkSystemAllocationScope scope)
+{
+   if (s == NULL)
+  return NULL;
+
+   size_t len = strlen(s);
+   char *copy = vk_alloc(alloc, len, 1, scope);
+   if (copy == NULL)
+  return NULL;
+
+   memcpy(copy, s, len);
+
+   return copy;
+}
+
 static inline void *
 vk_alloc2(const VkAllocationCallbacks *parent_alloc,
   const VkAllocationCallbacks *alloc,
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/3] anv: Claim to support depthBounds for ID games

[Jason Ekstrand]

---
 src/intel/vulkan/anv_device.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 0357fc7c0ea..5a63592f7ca 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -854,6 +854,15 @@ void anv_GetPhysicalDeviceFeatures(
pFeatures->vertexPipelineStoresAndAtomics =
   pdevice->compiler->scalar_stage[MESA_SHADER_VERTEX] &&
   pdevice->compiler->scalar_stage[MESA_SHADER_GEOMETRY];
+
+   struct anv_app_info *app_info = &pdevice->instance->app_info;
+
+   /* The new DOOM and Wolfenstein games require depthBounds without
+* checking for it.  They seem to run fine without it so just claim it's
+* there and accept the consequences.
+*/
+   if (app_info->engine_name && strcmp(app_info->engine_name, "idTech") == 0)
+  pFeatures->depthBounds = true;
 }
 
 void anv_GetPhysicalDeviceFeatures2(
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 3/3] travis: use python3 for the autoconf builds

[Eric Engestrom]

On Thursday, 2018-08-23 15:34:30 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

> ---
>  .travis.yml | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 90f9ec40e12..4ef0286a68f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -90,6 +90,7 @@ matrix:
>  - libx11-xcb-dev
>  - libxdamage-dev
>  - libxfixes-dev
> +- python3-pip
>  - env:
>  # NOTE: Building SWR is 2x (yes two) times slower than all the other
>  # gallium drivers combined.
> @@ -122,6 +123,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  - LABEL="make Gallium Drivers RadeonSI"
>  - BUILD=make
> @@ -151,6 +153,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  - LABEL="make Gallium Drivers Other"
>  - BUILD=make
> @@ -183,6 +186,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  # NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-3.9"
> @@ -222,6 +226,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  # NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-4.0"
> @@ -258,6 +263,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  # NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-5.0"
> @@ -294,6 +300,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  # NOTE: Analogous to SWR above, building Clover is quite slow.
>  - LABEL="make Gallium ST Clover LLVM-6.0"
> @@ -327,6 +334,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  - LABEL="make Gallium ST Other"
>  - BUILD=make
> @@ -363,6 +371,7 @@ matrix:
>  - libx11-xcb-dev
>  - libelf-dev
>  - libunwind8-dev
> +- python3-pip
>  - env:
>  - LABEL="make Vulkan"
>  - BUILD=make
> @@ -391,6 +400,7 @@ matrix:
>  - libexpat1-dev
>  - libx11-xcb-dev
>  - libelf-dev
> +- python3-pip
>  - env:
>  - LABEL="scons"
>  - BUILD=scons
> @@ -499,7 +509,7 @@ install:
>  
># Install autotools build dependencies
>- if test "x$BUILD" = xmake; then
> -  pip2 install --user mako;
> +  pip3 install --user mako;
>  fi
>  
># Install a more modern scons from pip.
> -- 
> 2.18.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 2/3] configure: allow building with python3

[Eric Engestrom]

On Thursday, 2018-08-23 15:34:29 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Pretty much all of the scripts are python2+3 compatible.
> Check and allow using python3, while adjusting the PYTHON2 refs.
> 
> Note:
>  - python3.4 is used as it's the earliest supported version
>  - python3 is chosen prior to python2
> 
> Signed-off-by: Emil Velikov 

Not fully double-checked, but +1 on the idea and a skim through didn't
notice anything.

Acked-by: Eric Engestrom 

> ---
>  configure.ac |  8 +++-
>  m4/ax_check_python_mako_module.m4|  2 +-
>  src/Makefile.am  |  2 +-
>  src/amd/Makefile.common.am   |  2 +-
>  src/amd/vulkan/Makefile.am   | 10 +-
>  src/broadcom/Makefile.am |  2 +-
>  src/compiler/Makefile.am |  2 +-
>  src/compiler/Makefile.glsl.am|  2 +-
>  src/compiler/glsl/glcpp/tests/glcpp-test.sh  |  2 +-
>  src/compiler/glsl/tests/optimization-test.sh |  2 +-
>  src/compiler/glsl/tests/warnings-test.sh |  2 +-
>  src/egl/Makefile.am  |  2 +-
>  src/gallium/auxiliary/Makefile.am|  2 +-
>  src/gallium/drivers/freedreno/Makefile.am|  2 +-
>  src/gallium/drivers/r600/Makefile.am |  2 +-
>  src/gallium/drivers/radeonsi/Makefile.am |  2 +-
>  src/gallium/drivers/swr/Makefile.am  |  2 +-
>  src/intel/Makefile.am|  2 +-
>  src/intel/Makefile.compiler.am   |  2 +-
>  src/intel/Makefile.vulkan.am | 10 +-
>  src/mapi/Makefile.am |  2 +-
>  src/mapi/glapi/gen/Makefile.am   |  2 +-
>  src/mesa/Makefile.am |  2 +-
>  src/mesa/drivers/dri/i965/Makefile.am|  2 +-
>  src/util/Makefile.am |  2 +-
>  src/util/xmlpool/Makefile.am |  2 +-
>  src/vulkan/Makefile.am   |  2 +-
>  27 files changed, 37 insertions(+), 39 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f8bb131cb63..8dea87fa6a8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -125,9 +125,7 @@ AC_PROG_GREP
>  AC_PROG_NM
>  AM_PROG_AS
>  AX_CHECK_GNU_MAKE
> -AM_PATH_PYTHON([2.7],, [:])
> -PYTHON2=$PYTHON
> -AC_SUBST([PYTHON2])
> +AM_PATH_PYTHON([3.4],, [AM_PATH_PYTHON([2.7],, [:])])
>  
>  AC_PROG_SED
>  AC_PROG_MKDIR_P
> @@ -160,7 +158,7 @@ fi
>  
>  AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
>  
> -if test "$PYTHON2" = ":"; then
> +if test "$PYTHON" = ":"; then
>  if test ! -f "$srcdir/src/util/format_srgb.c"; then
>  AC_MSG_ERROR([Python not found - unable to generate sources])
>  fi
> @@ -3348,7 +3346,7 @@ if test "x$enable_llvm" = xyes; then
>  echo "LLVM_LDFLAGS:$LLVM_LDFLAGS"
>  echo ""
>  fi
> -echo "PYTHON2: $PYTHON2"
> +echo "PYTHON: $PYTHON"
>  
>  echo ""
>  echo "Run '${MAKE-make}' to build Mesa"
> diff --git a/m4/ax_check_python_mako_module.m4 
> b/m4/ax_check_python_mako_module.m4
> index 1d293d821c3..d6484e722fd 100644
> --- a/m4/ax_check_python_mako_module.m4
> +++ b/m4/ax_check_python_mako_module.m4
> @@ -52,7 +52,7 @@ else:
>  ver_req = distutils.version.LooseVersion('$1')
>  ver_act = distutils.version.LooseVersion(mako.__version__)
>  sys.exit(int(ver_req > ver_act))
> -" | $PYTHON2 -
> +" | $PYTHON -
>  
>  if test $? -ne 0 ; then
> AC_MSG_RESULT(no)
> diff --git a/src/Makefile.am b/src/Makefile.am
> index c4fcd8a9248..c91e63efa13 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -22,7 +22,7 @@
>  .PHONY: git_sha1.h
>  git_sha1.h:
>   @echo "updating $@"
> - @$(PYTHON2) $(top_srcdir)/bin/git_sha1_gen.py --output $@
> + @$(PYTHON) $(top_srcdir)/bin/git_sha1_gen.py --output $@
>  
>  BUILT_SOURCES = git_sha1.h
>  CLEANFILES = $(BUILT_SOURCES)
> diff --git a/src/amd/Makefile.common.am b/src/amd/Makefile.common.am
> index d62e9d41cf4..453d23c3ac9 100644
> --- a/src/amd/Makefile.common.am
> +++ b/src/amd/Makefile.common.am
> @@ -66,6 +66,6 @@ common_libamd_common_la_LIBADD = $(LIBELF_LIBS)
>  
>  common/sid_tables.h: $(srcdir)/common/sid_tables.py $(srcdir)/common/sid.h 
> $(srcdir)/common/gfx9d.h
>   $(AM_V_at)$(MKDIR_P) $(@D)
> - $(AM_V_GEN) $(PYTHON2) $(srcdir)/common/sid_tables.py 
> $(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
> + $(AM_V_GEN) $(PYTHON) $(srcdir)/common/sid_tables.py 
> $(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
>  
>  BUILT_SOURCES = $(AMD_GENERATED_FILES)
> diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
> index e28f032cbee..2522171dacf 100644
> --- a/src/amd/vulkan/Makefile.am
> +++ b/src/amd/vulkan/Makefile.am
> @@ -140,7 +140,7 @@ vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
>  
>  radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
> $(vulkan_api_xml)
>   $(MKDIR

Re: [Mesa-dev] [PATCH 1/3] bin/git_sha1_gen.py: remove execute bit/shebang

[Eric Engestrom]

On Thursday, 2018-08-23 15:34:28 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The script is executed explicitly via the build system, that uses
> PYTHON/prog_python and equivalent.

All 4 build systems actually do the same thing there, almost hard
to believe :]

Reviewed-by: Eric Engestrom 

> 
> Signed-off-by: Emil Velikov 
> ---
>  bin/git_sha1_gen.py | 2 --
>  1 file changed, 2 deletions(-)
>  mode change 100755 => 100644 bin/git_sha1_gen.py
> 
> diff --git a/bin/git_sha1_gen.py b/bin/git_sha1_gen.py
> old mode 100755
> new mode 100644
> index 7741159816b..c6fbf490302
> --- a/bin/git_sha1_gen.py
> +++ b/bin/git_sha1_gen.py
> @@ -1,5 +1,3 @@
> -#!/usr/bin/env python
> -
>  """
>  Generate the contents of the git_sha1.h file.
>  The output of this script goes to stdout.
> -- 
> 2.18.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 3/3] travis: use python3 for the autoconf builds

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 .travis.yml | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 90f9ec40e12..4ef0286a68f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -90,6 +90,7 @@ matrix:
 - libx11-xcb-dev
 - libxdamage-dev
 - libxfixes-dev
+- python3-pip
 - env:
 # NOTE: Building SWR is 2x (yes two) times slower than all the other
 # gallium drivers combined.
@@ -122,6 +123,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 - LABEL="make Gallium Drivers RadeonSI"
 - BUILD=make
@@ -151,6 +153,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 - LABEL="make Gallium Drivers Other"
 - BUILD=make
@@ -183,6 +186,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 # NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-3.9"
@@ -222,6 +226,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 # NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-4.0"
@@ -258,6 +263,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 # NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-5.0"
@@ -294,6 +300,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 # NOTE: Analogous to SWR above, building Clover is quite slow.
 - LABEL="make Gallium ST Clover LLVM-6.0"
@@ -327,6 +334,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 - LABEL="make Gallium ST Other"
 - BUILD=make
@@ -363,6 +371,7 @@ matrix:
 - libx11-xcb-dev
 - libelf-dev
 - libunwind8-dev
+- python3-pip
 - env:
 - LABEL="make Vulkan"
 - BUILD=make
@@ -391,6 +400,7 @@ matrix:
 - libexpat1-dev
 - libx11-xcb-dev
 - libelf-dev
+- python3-pip
 - env:
 - LABEL="scons"
 - BUILD=scons
@@ -499,7 +509,7 @@ install:
 
   # Install autotools build dependencies
   - if test "x$BUILD" = xmake; then
-  pip2 install --user mako;
+  pip3 install --user mako;
 fi
 
   # Install a more modern scons from pip.
-- 
2.18.0

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

[Mesa-dev] [PATCH 2/3] configure: allow building with python3

[Emil Velikov]

From: Emil Velikov 

Pretty much all of the scripts are python2+3 compatible.
Check and allow using python3, while adjusting the PYTHON2 refs.

Note:
 - python3.4 is used as it's the earliest supported version
 - python3 is chosen prior to python2

Signed-off-by: Emil Velikov 
---
 configure.ac |  8 +++-
 m4/ax_check_python_mako_module.m4|  2 +-
 src/Makefile.am  |  2 +-
 src/amd/Makefile.common.am   |  2 +-
 src/amd/vulkan/Makefile.am   | 10 +-
 src/broadcom/Makefile.am |  2 +-
 src/compiler/Makefile.am |  2 +-
 src/compiler/Makefile.glsl.am|  2 +-
 src/compiler/glsl/glcpp/tests/glcpp-test.sh  |  2 +-
 src/compiler/glsl/tests/optimization-test.sh |  2 +-
 src/compiler/glsl/tests/warnings-test.sh |  2 +-
 src/egl/Makefile.am  |  2 +-
 src/gallium/auxiliary/Makefile.am|  2 +-
 src/gallium/drivers/freedreno/Makefile.am|  2 +-
 src/gallium/drivers/r600/Makefile.am |  2 +-
 src/gallium/drivers/radeonsi/Makefile.am |  2 +-
 src/gallium/drivers/swr/Makefile.am  |  2 +-
 src/intel/Makefile.am|  2 +-
 src/intel/Makefile.compiler.am   |  2 +-
 src/intel/Makefile.vulkan.am | 10 +-
 src/mapi/Makefile.am |  2 +-
 src/mapi/glapi/gen/Makefile.am   |  2 +-
 src/mesa/Makefile.am |  2 +-
 src/mesa/drivers/dri/i965/Makefile.am|  2 +-
 src/util/Makefile.am |  2 +-
 src/util/xmlpool/Makefile.am |  2 +-
 src/vulkan/Makefile.am   |  2 +-
 27 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/configure.ac b/configure.ac
index f8bb131cb63..8dea87fa6a8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -125,9 +125,7 @@ AC_PROG_GREP
 AC_PROG_NM
 AM_PROG_AS
 AX_CHECK_GNU_MAKE
-AM_PATH_PYTHON([2.7],, [:])
-PYTHON2=$PYTHON
-AC_SUBST([PYTHON2])
+AM_PATH_PYTHON([3.4],, [AM_PATH_PYTHON([2.7],, [:])])
 
 AC_PROG_SED
 AC_PROG_MKDIR_P
@@ -160,7 +158,7 @@ fi
 
 AX_CHECK_PYTHON_MAKO_MODULE($PYTHON_MAKO_REQUIRED)
 
-if test "$PYTHON2" = ":"; then
+if test "$PYTHON" = ":"; then
 if test ! -f "$srcdir/src/util/format_srgb.c"; then
 AC_MSG_ERROR([Python not found - unable to generate sources])
 fi
@@ -3348,7 +3346,7 @@ if test "x$enable_llvm" = xyes; then
 echo "LLVM_LDFLAGS:$LLVM_LDFLAGS"
 echo ""
 fi
-echo "PYTHON2: $PYTHON2"
+echo "PYTHON: $PYTHON"
 
 echo ""
 echo "Run '${MAKE-make}' to build Mesa"
diff --git a/m4/ax_check_python_mako_module.m4 
b/m4/ax_check_python_mako_module.m4
index 1d293d821c3..d6484e722fd 100644
--- a/m4/ax_check_python_mako_module.m4
+++ b/m4/ax_check_python_mako_module.m4
@@ -52,7 +52,7 @@ else:
 ver_req = distutils.version.LooseVersion('$1')
 ver_act = distutils.version.LooseVersion(mako.__version__)
 sys.exit(int(ver_req > ver_act))
-" | $PYTHON2 -
+" | $PYTHON -
 
 if test $? -ne 0 ; then
AC_MSG_RESULT(no)
diff --git a/src/Makefile.am b/src/Makefile.am
index c4fcd8a9248..c91e63efa13 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -22,7 +22,7 @@
 .PHONY: git_sha1.h
 git_sha1.h:
@echo "updating $@"
-   @$(PYTHON2) $(top_srcdir)/bin/git_sha1_gen.py --output $@
+   @$(PYTHON) $(top_srcdir)/bin/git_sha1_gen.py --output $@
 
 BUILT_SOURCES = git_sha1.h
 CLEANFILES = $(BUILT_SOURCES)
diff --git a/src/amd/Makefile.common.am b/src/amd/Makefile.common.am
index d62e9d41cf4..453d23c3ac9 100644
--- a/src/amd/Makefile.common.am
+++ b/src/amd/Makefile.common.am
@@ -66,6 +66,6 @@ common_libamd_common_la_LIBADD = $(LIBELF_LIBS)
 
 common/sid_tables.h: $(srcdir)/common/sid_tables.py $(srcdir)/common/sid.h 
$(srcdir)/common/gfx9d.h
$(AM_V_at)$(MKDIR_P) $(@D)
-   $(AM_V_GEN) $(PYTHON2) $(srcdir)/common/sid_tables.py 
$(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
+   $(AM_V_GEN) $(PYTHON) $(srcdir)/common/sid_tables.py 
$(srcdir)/common/sid.h $(srcdir)/common/gfx9d.h > $@
 
 BUILT_SOURCES = $(AMD_GENERATED_FILES)
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index e28f032cbee..2522171dacf 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -140,7 +140,7 @@ vulkan_api_xml = $(top_srcdir)/src/vulkan/registry/vk.xml
 
 radv_entrypoints.c: radv_entrypoints_gen.py radv_extensions.py 
$(vulkan_api_xml)
$(MKDIR_GEN)
-   $(AM_V_GEN)$(PYTHON2) $(srcdir)/radv_entrypoints_gen.py \
+   $(AM_V_GEN)$(PYTHON) $(srcdir)/radv_entrypoints_gen.py \
--xml $(vulkan_api_xml) \
--outdir $(builddir)
 radv_entrypoints.h: radv_entrypoints.c
@@ -148,7 +148,7 @@ radv_entrypoints.h: radv_entrypoints.c
 radv_extensions.c: radv_extensions.py \
 $(vulkan_api_xml)
$(MKDIR_GEN)

[Mesa-dev] [PATCH 1/3] bin/git_sha1_gen.py: remove execute bit/shebang

[Emil Velikov]

From: Emil Velikov 

The script is executed explicitly via the build system, that uses
PYTHON/prog_python and equivalent.

Signed-off-by: Emil Velikov 
---
 bin/git_sha1_gen.py | 2 --
 1 file changed, 2 deletions(-)
 mode change 100755 => 100644 bin/git_sha1_gen.py

diff --git a/bin/git_sha1_gen.py b/bin/git_sha1_gen.py
old mode 100755
new mode 100644
index 7741159816b..c6fbf490302
--- a/bin/git_sha1_gen.py
+++ b/bin/git_sha1_gen.py
@@ -1,5 +1,3 @@
-#!/usr/bin/env python
-
 """
 Generate the contents of the git_sha1.h file.
 The output of this script goes to stdout.
-- 
2.18.0

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

[Mesa-dev] [PATCH 2/2] radv: only flush CB/DB metadata for subpass barriers when needed

[Samuel Pitoiset]

Shouldn't be required when the framebuffer doesn't use
CB or DB metadata.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 42 
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 2d66098873..933fcb9711 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1969,7 +1969,8 @@ static void radv_stage_flush(struct radv_cmd_buffer 
*cmd_buffer,
 static enum radv_cmd_flush_bits
 radv_src_access_flush(struct radv_cmd_buffer *cmd_buffer,
  VkAccessFlags src_flags,
- struct radv_image *image)
+ struct radv_image *image,
+ bool subpass)
 {
bool flush_CB_meta = true, flush_DB_meta = true;
enum radv_cmd_flush_bits flush_bits = 0;
@@ -1980,6 +1981,16 @@ radv_src_access_flush(struct radv_cmd_buffer *cmd_buffer,
flush_CB_meta = false;
if (!radv_image_has_htile(image))
flush_DB_meta = false;
+   } else if (subpass) {
+   struct radv_framebuffer *framebuffer =
+   cmd_buffer->state.framebuffer;
+
+   if (framebuffer) {
+   if (!framebuffer->has_CB_metadata)
+   flush_CB_meta = false;
+   if (!framebuffer->has_DB_metadata)
+   flush_DB_meta = false;
+   }
}
 
for_each_bit(b, src_flags) {
@@ -2017,7 +2028,8 @@ radv_src_access_flush(struct radv_cmd_buffer *cmd_buffer,
 static enum radv_cmd_flush_bits
 radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
   VkAccessFlags dst_flags,
-  struct radv_image *image)
+  struct radv_image *image,
+ bool subpass)
 {
bool flush_CB_meta = true, flush_DB_meta = true;
enum radv_cmd_flush_bits flush_bits = 0;
@@ -2048,6 +2060,16 @@ radv_dst_access_flush(struct radv_cmd_buffer *cmd_buffer,
image_is_coherent = true;
}
}
+   } else if (subpass) {
+   struct radv_framebuffer *framebuffer =
+   cmd_buffer->state.framebuffer;
+
+   if (framebuffer) {
+   if (!framebuffer->has_CB_metadata)
+   flush_CB_meta = false;
+   if (!framebuffer->has_DB_metadata)
+   flush_DB_meta = false;
+   }
}
 
for_each_bit(b, dst_flags) {
@@ -2093,10 +2115,10 @@ void radv_subpass_barrier(struct radv_cmd_buffer 
*cmd_buffer,
  const struct radv_subpass_barrier *barrier)
 {
cmd_buffer->state.flush_bits |= radv_src_access_flush(cmd_buffer, 
barrier->src_access_mask,
- NULL);
+ NULL, true);
radv_stage_flush(cmd_buffer, barrier->src_stage_mask);
cmd_buffer->state.flush_bits |= radv_dst_access_flush(cmd_buffer, 
barrier->dst_access_mask,
- NULL);
+ NULL, true);
 }
 
 static void radv_handle_subpass_image_transition(struct radv_cmd_buffer 
*cmd_buffer,
@@ -4282,25 +4304,25 @@ radv_barrier(struct radv_cmd_buffer *cmd_buffer,
 
for (uint32_t i = 0; i < memoryBarrierCount; i++) {
src_flush_bits |= radv_src_access_flush(cmd_buffer, 
pMemoryBarriers[i].srcAccessMask,
-   NULL);
+   NULL, false);
dst_flush_bits |= radv_dst_access_flush(cmd_buffer, 
pMemoryBarriers[i].dstAccessMask,
-   NULL);
+   NULL, false);
}
 
for (uint32_t i = 0; i < bufferMemoryBarrierCount; i++) {
src_flush_bits |= radv_src_access_flush(cmd_buffer, 
pBufferMemoryBarriers[i].srcAccessMask,
-   NULL);
+   NULL, false);
dst_flush_bits |= radv_dst_access_flush(cmd_buffer, 
pBufferMemoryBarriers[i].dstAccessMask,
-   NULL);
+   NULL, false);
}
 
for (uint32_t i = 0; i < imageMemoryBarrierCount; i++) {
RADV_FROM_HANDLE(radv_image, image, 
pImageMemoryBarriers[i].image);
 
src_flush_bits |= radv_src_access_flush(cmd_buffer, 
pImageMemoryBarriers[i].srcAccessMask,
-   

[Mesa-dev] [PATCH 1/2] radv: record if the framebuffer has CB/DB metadata

[Samuel Pitoiset]

For further optimizations.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c  | 7 +++
 src/amd/vulkan/radv_private.h | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 79dbbd886d..be4c9719c1 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -4201,14 +4201,21 @@ VkResult radv_CreateFramebuffer(
framebuffer->width = pCreateInfo->width;
framebuffer->height = pCreateInfo->height;
framebuffer->layers = pCreateInfo->layers;
+   framebuffer->has_CB_metadata = false;
+   framebuffer->has_DB_metadata = false;
+
for (uint32_t i = 0; i < pCreateInfo->attachmentCount; i++) {
VkImageView _iview = pCreateInfo->pAttachments[i];
struct radv_image_view *iview = 
radv_image_view_from_handle(_iview);
framebuffer->attachments[i].attachment = iview;
if (iview->aspect_mask & VK_IMAGE_ASPECT_COLOR_BIT) {
radv_initialise_color_surface(device, 
&framebuffer->attachments[i].cb, iview);
+   if (radv_image_has_CB_metadata(iview->image))
+   framebuffer->has_CB_metadata = true;
} else if (iview->aspect_mask & (VK_IMAGE_ASPECT_DEPTH_BIT | 
VK_IMAGE_ASPECT_STENCIL_BIT)) {
radv_initialise_ds_surface(device, 
&framebuffer->attachments[i].ds, iview);
+   if (radv_image_has_htile(iview->image))
+   framebuffer->has_DB_metadata = true;
}
framebuffer->width = MIN2(framebuffer->width, 
iview->extent.width);
framebuffer->height = MIN2(framebuffer->height, 
iview->extent.height);
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 01a5a698a0..17660439d5 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1715,6 +1715,9 @@ struct radv_framebuffer {
uint32_t height;
uint32_t layers;
 
+   bool has_CB_metadata;
+   bool has_DB_metadata;
+
uint32_t attachment_count;
struct radv_attachment_info  attachments[0];
 };
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH] i965/gen6/xfb: handle case where transform feedback is not active

[Samuel Iglesias Gonsálvez]

The patch seems fine to me. I also tested it on Intel CI and there were
no regressions.

Reviewed-by: Samuel Iglesias Gonsálvez 

Thanks,

Sam

On 15/08/18 17:20, asimiklit.w...@gmail.com wrote:
> From: Andrii Simiklit 
>
> When the SVBI Payload Enable is false I guess the register R1.4
> which contains the Maximum Streamed Vertex Buffer Index is filled by zero
> and GS stops to write transform feedback when the transform feedback 
> is not active.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107579
> Signed-off-by: Andrii Simiklit 
> ---
>  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 ea5ad55..0f82500 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2806,7 +2806,7 @@ genX(upload_gs_state)(struct brw_context *brw)
>  #if GEN_GEN < 7
>   gs.SOStatisticsEnable = true;
>   if (gs_prog->info.has_transform_feedback_varyings)
> -gs.SVBIPayloadEnable = true;
> +gs.SVBIPayloadEnable = _mesa_is_xfb_active_and_unpaused(ctx);
>  
>   /* GEN6_GS_SPF_MODE and GEN6_GS_VECTOR_MASK_ENABLE are enabled as it
>* was previously done for gen6.



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

[Mesa-dev] [PATCH] intel: compiler: remove dead local variables at optimization pass

[Lionel Landwerlin]

We're hitting an assert in gfxbench because one of the local variable
is a sampler (according to Jason this isn't valid) :

testfw_app: ../src/compiler/nir_types.cpp:551: void 
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*, unsigned 
int*): Assertion `!"type does not have a natural size"' failed.

Since this particular variable isn't used and it can be eliminated by
removing unused local variables in the optimization pass. This makes
sense also for valid local variables.

Signed-off-by: Lionel Landwerlin 
---
 src/intel/compiler/brw_nir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 29ad68fdb2a..ede341c8f3a 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -586,6 +586,7 @@ brw_nir_optimize(nir_shader *nir, const struct brw_compiler 
*compiler,
  nir_lower_dround_even |
  nir_lower_dmod);
   OPT(nir_lower_pack);
+  OPT(nir_remove_dead_variables, nir_var_local);
} while (progress);
 
return nir;
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH] compiler: nir: opt_large_constants: don't consider empty sized variables

[Lionel Landwerlin]

On 23/08/2018 13:50, Jason Ekstrand wrote:
On Thu, Aug 23, 2018 at 7:04 AM Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


We're hitting an assert in gfxbench because one of the local
variable is a sampler :


Of course we were That's because gfxbench does illegal things like 
creating local variables which are samplers. :-(  I don't think such a 
variable is being used so maybe we can just ensure that dead_variables 
is run on locals before opt_large_constants.  Or maybe we can improve 
the spirv_to_nir hack to never add the variable to the IR in the first 
place.



Indeed, it's not used.

Let me send a more sensible workaround/fix.



testfw_app: ../src/compiler/nir_types.cpp:551: void
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*,
unsigned int*): Assertion `!"type does not have a natural size"'
failed.

Signed-off-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>
Fixes: 1235850522cd5e ("nir: Add a large constants optimization pass")
---
 src/compiler/nir/nir_opt_large_constants.c | 10 +-
 src/compiler/nir_types.cpp                 |  4 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_large_constants.c
b/src/compiler/nir/nir_opt_large_constants.c
index 25a921963df..5dfb07aed27 100644
--- a/src/compiler/nir/nir_opt_large_constants.c
+++ b/src/compiler/nir/nir_opt_large_constants.c
@@ -178,11 +178,19 @@ nir_opt_large_constants(nir_shader *shader,
             nir_variable *var =
nir_deref_instr_get_variable(dst_deref);
             assert(var->data.mode == nir_var_local);

+            struct var_info *info = &var_infos[var->data.index];
+            /* Variable with empty natural size (samplers,
images, etc...) are
+             * not considered constant.
+             */
+            unsigned var_size, var_align;
+            size_align(var->type, &var_size, &var_align);
+            if (!var_size)
+               info->is_constant = false;
+
             /* We only consider variables constant if they only
have constant
              * stores, all the stores come before any reads, and
all stores
              * come in the first block.  We also can't handle
indirect stores.
              */
-            struct var_info *info = &var_infos[var->data.index];
             if (!src_is_const || info->found_read || !first_block ||
                 nir_deref_instr_has_indirect(dst_deref))
                info->is_constant = false;
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index c8a29404969..e3a2fc2eac0 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -548,7 +548,9 @@ glsl_get_natural_size_align_bytes(const struct
glsl_type *type,
    case GLSL_TYPE_ERROR:
    case GLSL_TYPE_INTERFACE:
    case GLSL_TYPE_FUNCTION:
-      unreachable("type does not have a natural size");
+      *align = 1;
+      *size = 0;
+      break;
    }
 }

-- 
2.18.0




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

Re: [Mesa-dev] [PATCH] compiler: nir: opt_large_constants: don't consider empty sized variables

[Jason Ekstrand]

On Thu, Aug 23, 2018 at 7:04 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> We're hitting an assert in gfxbench because one of the local variable is a
> sampler :
>

Of course we were That's because gfxbench does illegal things like
creating local variables which are samplers. :-(  I don't think such a
variable is being used so maybe we can just ensure that dead_variables is
run on locals before opt_large_constants.  Or maybe we can improve the
spirv_to_nir hack to never add the variable to the IR in the first place.


> testfw_app: ../src/compiler/nir_types.cpp:551: void
> glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*, unsigned
> int*): Assertion `!"type does not have a natural size"' failed.
>
> Signed-off-by: Lionel Landwerlin 
> Fixes: 1235850522cd5e ("nir: Add a large constants optimization pass")
> ---
>  src/compiler/nir/nir_opt_large_constants.c | 10 +-
>  src/compiler/nir_types.cpp |  4 +++-
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_large_constants.c
> b/src/compiler/nir/nir_opt_large_constants.c
> index 25a921963df..5dfb07aed27 100644
> --- a/src/compiler/nir/nir_opt_large_constants.c
> +++ b/src/compiler/nir/nir_opt_large_constants.c
> @@ -178,11 +178,19 @@ nir_opt_large_constants(nir_shader *shader,
>  nir_variable *var = nir_deref_instr_get_variable(dst_deref);
>  assert(var->data.mode == nir_var_local);
>
> +struct var_info *info = &var_infos[var->data.index];
> +/* Variable with empty natural size (samplers, images,
> etc...) are
> + * not considered constant.
> + */
> +unsigned var_size, var_align;
> +size_align(var->type, &var_size, &var_align);
> +if (!var_size)
> +   info->is_constant = false;
> +
>  /* We only consider variables constant if they only have
> constant
>   * stores, all the stores come before any reads, and all
> stores
>   * come in the first block.  We also can't handle indirect
> stores.
>   */
> -struct var_info *info = &var_infos[var->data.index];
>  if (!src_is_const || info->found_read || !first_block ||
>  nir_deref_instr_has_indirect(dst_deref))
> info->is_constant = false;
> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> index c8a29404969..e3a2fc2eac0 100644
> --- a/src/compiler/nir_types.cpp
> +++ b/src/compiler/nir_types.cpp
> @@ -548,7 +548,9 @@ glsl_get_natural_size_align_bytes(const struct
> glsl_type *type,
> case GLSL_TYPE_ERROR:
> case GLSL_TYPE_INTERFACE:
> case GLSL_TYPE_FUNCTION:
> -  unreachable("type does not have a natural size");
> +  *align = 1;
> +  *size = 0;
> +  break;
> }
>  }
>
> --
> 2.18.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] compiler: nir: opt_large_constants: don't consider empty sized variables

[Lionel Landwerlin]

We're hitting an assert in gfxbench because one of the local variable is a 
sampler :

testfw_app: ../src/compiler/nir_types.cpp:551: void 
glsl_get_natural_size_align_bytes(const glsl_type*, unsigned int*, unsigned 
int*): Assertion `!"type does not have a natural size"' failed.

Signed-off-by: Lionel Landwerlin 
Fixes: 1235850522cd5e ("nir: Add a large constants optimization pass")
---
 src/compiler/nir/nir_opt_large_constants.c | 10 +-
 src/compiler/nir_types.cpp |  4 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_large_constants.c 
b/src/compiler/nir/nir_opt_large_constants.c
index 25a921963df..5dfb07aed27 100644
--- a/src/compiler/nir/nir_opt_large_constants.c
+++ b/src/compiler/nir/nir_opt_large_constants.c
@@ -178,11 +178,19 @@ nir_opt_large_constants(nir_shader *shader,
 nir_variable *var = nir_deref_instr_get_variable(dst_deref);
 assert(var->data.mode == nir_var_local);
 
+struct var_info *info = &var_infos[var->data.index];
+/* Variable with empty natural size (samplers, images, etc...) are
+ * not considered constant.
+ */
+unsigned var_size, var_align;
+size_align(var->type, &var_size, &var_align);
+if (!var_size)
+   info->is_constant = false;
+
 /* We only consider variables constant if they only have constant
  * stores, all the stores come before any reads, and all stores
  * come in the first block.  We also can't handle indirect stores.
  */
-struct var_info *info = &var_infos[var->data.index];
 if (!src_is_const || info->found_read || !first_block ||
 nir_deref_instr_has_indirect(dst_deref))
info->is_constant = false;
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index c8a29404969..e3a2fc2eac0 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -548,7 +548,9 @@ glsl_get_natural_size_align_bytes(const struct glsl_type 
*type,
case GLSL_TYPE_ERROR:
case GLSL_TYPE_INTERFACE:
case GLSL_TYPE_FUNCTION:
-  unreachable("type does not have a natural size");
+  *align = 1;
+  *size = 0;
+  break;
}
 }
 
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH] glsl: Do not propagate 'precise' and 'invariant' on read-only variables

[Danylo Piliaiev]

Hi Jason,

On 8/22/18 7:07 PM, Jason Ekstrand wrote:
I think this would be correct to do and would fix the bug at hand but 
there may be other bugs lurking deeper.  In particular, if you have 
multiple shaders for the same stage that share some global variables 
and get linked together, I think you could run into the same issue 
only with a read-write global.  If this is indeed possible, then I'm 
not sure what to do.  We have to run this pass prior to doing any 
optimization because we depend on it to get precise and invariant 
correct.  On the other hand, it has to be run after linking. :-/  
Maybe we just have to assume precise and invariant for all pre-linking 
optimizations and then run this post-linking.


I didn't check this case, thanks for pointing it out. Now I have looked 
at relevant code and saw that invariant propagation (linker.cpp:5024 in 
linker_optimisation_loop) is done after 'link_intrastage_shaders' 
(linker.cpp:4868) which combines a group of shaders for a single stage. 
Actually invariant propagation is also done once before linking. In 
addition I've done some tests and invariance from variable in one vertex 
shader is propagated on variables directly used only in other vertex 
shader.


However I have found other issue - cross_validate_globals is called in 
link_intrastage_shaders and throws error if 'invariant' qualifier 
doesn't match between shaders in same stage which happens when variable 
in one shader becomes invariant before the 'link_intrastage_shaders' 
call. This could be fixed separately.


Or there is another way to solve these issues: divide 'invariant' 
qualifier into explicit and implicit 'invariant', where explicit is for 
'invariant' set by user in shader and implicit is for 'invariant' 
propagated from other invariants. Thus in interface checking we will be 
able to check only for explicit invariance which besides two previous 
issues with solve another one: if out variable is marked as invariant 
due to invariance propagation this variable will be required to have 
invariant qualifier in the next stage even though user never marked it 
as such anywhere. And when the invariance will actually matter we will 
check both implicit and explicit one. What do you think about such solution?


- Danil.



On Wed, Aug 22, 2018 at 7:51 AM Danylo Piliaiev 
mailto:danylo.pilia...@gmail.com>> wrote:


Read-only variables could be considered inherently invariant and
precise
since no expression in shader affects them.
Explicitly marking them as such is unnecessary and can cause issues,
e.g. uniform marked as invariant may require the same uniform in other
stage to be invariant too but uniforms cannot have "invariant"
qualifier.

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

Signed-off-by: Danylo Piliaiev mailto:danylo.pilia...@globallogic.com>>
---
My assumption is that variable being read_only means that it either
loads a value from an external source or is initialized from
constant value.
From what I saw in code it's true but it may be wrong to depend on it.

 src/compiler/glsl/propagate_invariance.cpp | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/compiler/glsl/propagate_invariance.cpp
b/src/compiler/glsl/propagate_invariance.cpp
index b3f1d810cd..0e4233aa9f 100644
--- a/src/compiler/glsl/propagate_invariance.cpp
+++ b/src/compiler/glsl/propagate_invariance.cpp
@@ -96,6 +96,16 @@
ir_invariance_propagation_visitor::visit(ir_dereference_variable *ir)
    if (this->dst_var == NULL)
       return visit_continue;

+   /* Read-only variables could be considered inherently
+    * invariant and precise since no expression in shader affects
them.
+    * Explicitly marking them as such is unnecessary and can cause
+    * issues, e.g. uniform marked as invariant may require the same
+    * uniform in other stage to be invariant too but uniforms cannot
+    * have "invariant" qualifier.
+    */
+   if (ir->var->data.read_only)
+      return visit_continue;
+
    if (this->dst_var->data.invariant) {
       if (!ir->var->data.invariant)
          this->progress = true;
-- 
2.18.0


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

Re: [Mesa-dev] [PATCH] python: Remove shebang and executable bit

[Emil Velikov]

On Thu, 23 Aug 2018 at 11:11, Eric Engestrom  wrote:
>
> On Wednesday, 2018-08-22 18:58:26 +0200, Mathieu Bridon wrote:
> > Since the script is never executed directly, but launched by Meson as an
> > argument to the Python interpreter, those are not needed any more.
> >
> > In addition, they are the reason this script was missed when I moved the
> > Meson buildsystem to Python 3, so removing them helps avoiding future
> > confusion.
>
> Reviewed-by: Eric Engestrom 
>
Thanks,, and one from  me.
Reviewed-by: Emil Velikov 

I'll push it alongside my other python patches in a moment. Want to
double-check I don't break things ;-)

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

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #5 from Samuel Pitoiset  ---
Actually, I would need the SPIRV too in order to reproduce the problem myself.
Can you try with RADV_DEBUG=shaders,preoptir,spirv and attach the output?

You will need spirv-dis in your path. Thanks!

-- 
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] intel/decoder: Decode SFIXED values.

[Lionel Landwerlin]

On 23/08/2018 09:07, Kenneth Graunke wrote:

This lets us example SAMPLER_STATE's LOD Bias field, among other things.



Thanks Ken!


Reviewed-by: Lionel Landwerlin 



---
  src/intel/common/gen_decoder.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index ec0a486b101..a276f37835b 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -943,10 +943,14 @@ iter_decode_field(struct gen_field_iterator *iter)
snprintf(iter->value, sizeof(iter->value), "%f",
 (float) v.qw / (1 << iter->field->type.f));
break;
-   case GEN_TYPE_SFIXED:
-  /* FIXME: Sign extend extracted field. */
-  snprintf(iter->value, sizeof(iter->value), "%s", "foo");
+   case GEN_TYPE_SFIXED: {
+  /* Sign extend before converting */
+  int bits = iter->field->type.i + iter->field->type.f + 1;
+  int64_t v_sign_extend = ((int64_t)(v.qw << (64 - bits))) >> (64 - bits);
+  snprintf(iter->value, sizeof(iter->value), "%f",
+   (float) v_sign_extend / (1 << iter->field->type.f));
break;
+   }
 case GEN_TYPE_MBO:
 break;
 case GEN_TYPE_ENUM: {



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

[Mesa-dev] [PATCH v2] glsl/linker: Allow unused in blocks which are not declated on previous stage

[vadym.shovkoplias]

From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:

"Only the input variables that are actually read need to be written
 by the previous stage; it is allowed to have superfluous
 declarations of input variables."

Fixes:
* interstage-multiple-shader-objects.shader_test

v2:
  Update comment in ir.h since the usage of "used" field
  has been extended.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101247
Signed-off-by: Vadym Shovkoplias 
---
 src/compiler/glsl/ir.h  | 4 ++--
 src/compiler/glsl/link_interface_blocks.cpp | 8 +++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index 67b38f48ef..d05d1998a5 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -667,8 +667,8 @@ public:
* variable has been used.  For example, it is an error to redeclare a
* variable as invariant after it has been used.
*
-   * This is only maintained in the ast_to_hir.cpp path, not in
-   * Mesa's fixed function or ARB program paths.
+   * This is maintained in the ast_to_hir.cpp path and during linking,
+   * but not in Mesa's fixed function or ARB program paths.
*/
   unsigned used:1;
 
diff --git a/src/compiler/glsl/link_interface_blocks.cpp 
b/src/compiler/glsl/link_interface_blocks.cpp
index e5eca9460e..801fbcd5d9 100644
--- a/src/compiler/glsl/link_interface_blocks.cpp
+++ b/src/compiler/glsl/link_interface_blocks.cpp
@@ -417,9 +417,15 @@ validate_interstage_inout_blocks(struct gl_shader_program 
*prog,
* write to any of the pre-defined outputs (e.g. if the vertex shader
* does not write to gl_Position, etc), which is allowed and results in
* undefined behavior.
+   *
+   * From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:
+   *
+   *"Only the input variables that are actually read need to be written
+   * by the previous stage; it is allowed to have superfluous
+   * declarations of input variables."
*/
   if (producer_def == NULL &&
-  !is_builtin_gl_in_block(var, consumer->Stage)) {
+  !is_builtin_gl_in_block(var, consumer->Stage) && var->data.used) {
  linker_error(prog, "Input block `%s' is not an output of "
   "the previous stage\n", var->get_interface_type()->name);
  return;
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH] python: Remove shebang and executable bit

[Eric Engestrom]

On Wednesday, 2018-08-22 18:58:26 +0200, Mathieu Bridon wrote:
> Since the script is never executed directly, but launched by Meson as an
> argument to the Python interpreter, those are not needed any more.
> 
> In addition, they are the reason this script was missed when I moved the
> Meson buildsystem to Python 3, so removing them helps avoiding future
> confusion.

Reviewed-by: Eric Engestrom 

> ---
>  bin/install_megadrivers.py | 1 -
>  1 file changed, 1 deletion(-)
>  mode change 100755 => 100644 bin/install_megadrivers.py
> 
> diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
> old mode 100755
> new mode 100644
> index 551e385d1a5..d29b1911218
> --- a/bin/install_megadrivers.py
> +++ b/bin/install_megadrivers.py
> @@ -1,4 +1,3 @@
> -#!/usr/bin/env python
>  # encoding=utf-8
>  # Copyright © 2017-2018 Intel Corporation
>  
> -- 
> 2.17.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

[Mesa-dev] [Bug 107477] [DXVK] Setting high shader quality in GTA V results in LLVM error

[bugzilla-daemon]

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

--- Comment #4 from Samuel Pitoiset  ---
Can you also try with RADV_DEBUG=checkir and show me the output please?

-- 
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] glsl/linker: Allow unused in blocks which are not declated on previous stage

[Alejandro Piñeiro]

On 23/08/18 01:51, Timothy Arceri wrote:
> On 21/08/18 19:42, Vadym Shovkoplias wrote:
>> Hi Timothy, Alejandro,
>>
>> Thanks for the review comments!
>> I'd just like to mention that the same approach is already used
>> in link_varyings.cpp file in
>> function cross_validate_outputs_to_inputs(). Here is a code snippet:
>>
>>     if (*input->data.used *&& !input->get_interface_type() &&
>>                  !input->data.explicit_location &&
>>     !prog->SeparateShader)
>>                 linker_error(prog,
>>                              "%s shader input `%s' "
>>                              "has no matching output in the previous
>>     stage\n",
>>        
>> _mesa_shader_stage_to_string(consumer->Stage),
>>                              input->name);
>>
>>
>> This code is used for the same purpose to validate input and output
>> variables which is also done during linking stage.
>> So basically I just used the same check but for interface blocks.
>>
>> This was implemented some time ago in the following patch:
>>
>>     commit 18004c338f6be8af2e36d2f54972c60136229aeb
>>     Author: Samuel Iglesias Gonsalvez >     >
>>     Date:   Fri Nov 28 11:23:20 2014 +0100
>>
>>      glsl: fail when a shader's input var has not an equivalent out
>>     var in previous
>>
>>
>>
>> Suggest please does this mean that it is safe to use "used" field
>> while linking ?
>
> I don't think it is but I'm willing to put this in the who cares
> basket. Worst case scenario we get an error message when we probably
> shouldn't.
>
> I believe the spec text is worded this way so these unused blockes can
> be removed by opts during linking before validation is done. Ideally
> that is what we would do too. For now this patch is:
>
> Reviewed-by: Timothy Arceri 
>
> However I don't think you should update the comment Alejandro is
> taking about because I believe it is still correct. used is not set
> for fixed function or ARB asm style programs.

Sorry I didn't explain myself properly. Yes I agree that it is not used
for fixed functions or ARB programs, so that part would remain. IMHO,
the sentence that needs some tweaking is "This is only maintained in the
ast_to_hir.cpp path", as it seems to suggest that it is only
updated/valid during that pass, and now we are using it later, during
linking. Unless Im over-reading.

>
>>
>> On Tue, Aug 21, 2018 at 12:00 PM, Alejandro Piñeiro
>> mailto:apinhe...@igalia.com>> wrote:
>>
>>     On 21/08/18 03:02, Timothy Arceri wrote:
>>  > On 20/08/18 23:31, vadym.shovkoplias wrote:
>>  >>  From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:
>>  >>
>>  >>  "Only the input variables that are actually read need to be
>>     written
>>  >>   by the previous stage; it is allowed to have superfluous
>>  >>   declarations of input variables."
>>  >>
>>  >> Fixes:
>>  >>  * interstage-multiple-shader-objects.shader_test
>>  >>
>>  >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101247
>>     
>>  >> Signed-off-by: Vadym Shovkoplias
>>     >     >
>>  >> ---
>>  >>   src/compiler/glsl/link_interface_blocks.cpp | 8 +++-
>>  >>   1 file changed, 7 insertions(+), 1 deletion(-)
>>  >>
>>  >> diff --git a/src/compiler/glsl/link_interface_blocks.cpp
>>  >> b/src/compiler/glsl/link_interface_blocks.cpp
>>  >> index e5eca9460e..801fbcd5d9 100644
>>  >> --- a/src/compiler/glsl/link_interface_blocks.cpp
>>  >> +++ b/src/compiler/glsl/link_interface_blocks.cpp
>>  >> @@ -417,9 +417,15 @@ validate_interstage_inout_blocks(struct
>>  >> gl_shader_program *prog,
>>  >>  * write to any of the pre-defined outputs (e.g. if the
>>  >> vertex shader
>>  >>  * does not write to gl_Position, etc), which is
>> allowed and
>>  >> results in
>>  >>  * undefined behavior.
>>  >> +   *
>>  >> +   * From Section 4.3.4 (Inputs) of the GLSL 1.50 spec:
>>  >> +   *
>>  >> +   *    "Only the input variables that are actually read
>>     need to
>>  >> be written
>>  >> +   * by the previous stage; it is allowed to have
>>     superfluous
>>  >> +   * declarations of input variables."
>>  >>  */
>>  >>     if (producer_def == NULL &&
>>  >> -  !is_builtin_gl_in_block(var, consumer->Stage)) {
>>  >> +  !is_builtin_gl_in_block(var, consumer->Stage) &&
>>  >> var->data.used) {
>>  >
>>  > This concerns me a little. As far as I remember 'used' was
>> added to
>>  > make compiler warning better but it's not 100% reliable.
>>
>>     +1 on the concerns thing. In addition to be used mostly for
>> warnings, we
>>     need to take into account his description comment at ir.h:
>>
>>   "
>>    

Re: [Mesa-dev] EGL_MESA_query_renderer

[Emil Velikov]

On Wed, 22 Aug 2018 at 19:12, Rob Clark  wrote:
>
> On Wed, Aug 22, 2018 at 1:43 PM Emil Velikov  wrote:
> >
> > On 21 August 2018 at 14:40, Rob Clark  wrote:
> > > On Tue, Aug 21, 2018 at 5:19 AM Emil Velikov  
> > > wrote:
> > >>
> > >> HI all,
> > >>
> > >> On 20 August 2018 at 20:01, Rob Clark  wrote:
> > >> > +Emil since he had some interest in this extension too
> > >> >
> > >> >
> > >> Bth since I did not hear anything last week, so I sat down and wrote
> > >> the spec, implementation and tests on Sunday ;-)
> > >> I'll try to find some time to cleanup and sent out the patches later 
> > >> today.
> > >>
> > >> To reiterate my earlier suggestion
> > >>
> > >> "He can work on it in parallel and compare/cross-review one another's 
> > >> work.
> > >>
> > >> If people are not keen on the duplication effort, the time could be
> > >> invested that into other parts of the project (distro/flatpak
> > >> packaging, etc.)"
> > >>
> > >>
> > >> > On Mon, Aug 20, 2018 at 1:55 AM Veluri Mithun 
> > >> >  wrote:
> > >> >>
> > >> >> Hi Nicolai and Rob,
> > >> >>
> > >> >> I've started to work on the extension and once finish writing 
> > >> >> procedures, functions and spec file related this, I'll create pull 
> > >> >> request to Khronos official Registry source code repo at Github.
> > >> >>
> > >> >> I'm following the steps present here 
> > >> >> https://www.mesa3d.org/devinfo.html
> > >> >> it has instructions for GL extensions and I feel that only a few 
> > >> >> differences will be there and the rest it will be similar for EGL 
> > >> >> extension
> > >> >>
> > >> >> To add a new GL extension to Mesa you have to do at least the 
> > >> >> following.
> > >> >>
> > >> >> If glext.h doesn't define the extension, edit include/GL/gl.h and add 
> > >> >> code like this:
> > >> >>
> > >> >>  #ifndef GL_EXT_the_extension_name
> > >> >>  #define GL_EXT_the_extension_name 1
> > >> >>  /* declare the new enum tokens */
> > >> >>  /* prototype the new functions */
> > >> >>  /* TYPEDEFS for the new functions */
> > >> >>  #endif
> > >> >>
> > >> >>
> > >> >> here for my confirmation I need to ask that I should define it in 
> > >> >> include/EGL/eglmesaext.h right?
> > >> >
> > >> > So, looks like eglmesaext.h basically just exists for extensions that
> > >> > haven't showed up in eglext.h from Khronos yet.  So I guess this would
> > >> > be the place.
> > >> >
> > >> That's what I've done yes.
> > >>
> > >> > At any rate, probably the first step is to write an initial version of
> > >> > docs/specs/EGL_MESA_query_renderer.txt and send that out for review.
> > >> >
> > >> Personally, I'd suggest working on an glXGetScreenDriver and
> > >> glXGetDriverConfig equivalent for EGL.
> > >> That in itself will be a _fairly_ laborious task, which seems to have
> > >> been underestimated/missed in the initial plan.
> > >
> > > so, it was earlier discussed that
> > > glXGetScreenDriver()/glXGetDriverConfig() equivalents could be lumped
> > > into this extension, which is I guess not what you have done.  (I'm
> > > not too picky, it could be a separate extension, we just kinda lumped
> > > it all together)
> > >
> > Personal suggestion is to keep them separate - they are somewhat unrelated.
> > An EGL extension which maps to the GLX one, and something else for the
> > glX hacks.
> >
> > In either case, designing is the most important/time consuming thing.
> > Checking that the API is sane and can work with GLVND is crucial IMHO.
> > This thread lists some details about the incompat. with the glX and GLVND.
> >
> > https://lists.freedesktop.org/archives/mesa-dev/2017-May/155838.html
> >
> >
> > >> It would involve a) writing another EGL extension or b) Wayland
> > >> protocol or c) other mechanism.
> > >
> > > I haven't looked into the details, but I guess in the EGL on x11 case,
> > > it would re-use however these work with glx?
> > >
> > In theory ... looking at the implementation glXGetScreenDriver
> > It calls back via the DRI1/DRI2 protocol asking for the driver name.
> > So the DRI3 (only) case is broken.
>
> iirc, dri3 is similar case to wayland, where we should enumerate the
> rendernodes, since there is no relationship between the screen and the
> gpu, ie. buffers are allocated on client side and pushed to server.
>
Hm I'm either failing to understand what you mean, or you haven't
looked through the code in a while.
In particular
src/egl/drivers/dri2/egl_dri.h, and
git grep -i drivername -- src/glx

Both of these have the node fd and/or driver name,of the device
allocating the buffers ;-)

> > We should be able to fix that by storing the driver_name (if we don't
> > already) in the [GLX]Display.
> > With similar approach on the EGL side.
> >
> > Haven't looked at the other API.
> >
> > > And in the EGL on wayland case, we can enumerate the drm rendernode
> > > devices on the client side.. there shouldn't really be any display
> > > server side component, so I guess we don't need any protocol.
> >

[Mesa-dev] [PATCH] intel/decoder: Decode SFIXED values.

[Kenneth Graunke]

This lets us example SAMPLER_STATE's LOD Bias field, among other things.
---
 src/intel/common/gen_decoder.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index ec0a486b101..a276f37835b 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -943,10 +943,14 @@ iter_decode_field(struct gen_field_iterator *iter)
   snprintf(iter->value, sizeof(iter->value), "%f",
(float) v.qw / (1 << iter->field->type.f));
   break;
-   case GEN_TYPE_SFIXED:
-  /* FIXME: Sign extend extracted field. */
-  snprintf(iter->value, sizeof(iter->value), "%s", "foo");
+   case GEN_TYPE_SFIXED: {
+  /* Sign extend before converting */
+  int bits = iter->field->type.i + iter->field->type.f + 1;
+  int64_t v_sign_extend = ((int64_t)(v.qw << (64 - bits))) >> (64 - bits);
+  snprintf(iter->value, sizeof(iter->value), "%f",
+   (float) v_sign_extend / (1 << iter->field->type.f));
   break;
+   }
case GEN_TYPE_MBO:
break;
case GEN_TYPE_ENUM: {
-- 
2.18.0

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

Re: [Mesa-dev] ANDROID: eglCreateImageKHR missing modifiers

[Tapani Pälli]

On 08/22/2018 07:56 PM, Emil Velikov wrote:

Hi all,

Pardon for dropping in so late. I've seems to have missed this.

On 24 July 2018 at 14:24, Martin Fuzzey  wrote:

Hi Thomasz,

thanks for your reply

On 21/07/18 04:27, Tomasz Figa wrote:



As you noticed, this adds back the dependency on gralloc handle
structure. Moreover, it actually adds a dependency on the handle
having a binary format compatible with gralloc_gbm_handle_t. This is
not something that we can do in upstream Mesa, since there are more
platforms running gralloc implementations other than gbm_gralloc.



Looking at it a bit more is it really that bad?


Note that there are at least three different implementations - the
"original" drm_gralloc, gbm_gralloc (props to RobH) and an another one
used in CrOS (or was it Android?)


Chrome OS and Android Celadon use gralloc implemented in minigbm 
library. I think proposal from Tomasz is the best one, implement API 
between Mesa and gralloc to query modifiers. This makes it possible to 
use multiple gralloc implementations.





The compile time dependency is on gralloc_handle.h which is actually part of
libdrm not a specific gralloc implementation.
Does mesa need to compile with old versions of libdrm?
0r is the structure going to be removed from libdrm?


I think you missed gbm in gralloc_*gbm*_handle_t. The header
gralloc_handle.h was added to libdrm by Robert Foss, explicitly to aim
and standardise things.




Unfortunately, I don't have a very good solution for this. In Chrome
OS we just don't support modifiers in EGL/GLES on Android. Obviously
it would be a good idea to have some way to query gralloc for the
modifier, but I don't see Android providing any generic way to do it.

The least evil I can think of as a makeshift for now could be an
optional gralloc0 perform call that returns the modifier for given
buffer.



An advantage of a new perform call would be that other gralloc
implementations could be extended to support it without changing their
handle structure but is that really likely?


I did not keep track of the gralloc_handle_t discussion, but Rob
(cc'd) should have some info.
 From vague memory the standardized handle had means to track modifiers
amongst others.

That is obviously somewhat orthogonal to Android making it use of it ;-)

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


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

Re: [Mesa-dev] [PATCH] glapi: actually implement GL_EXT_robustness for GLES

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

On 08/23/2018 12:56 AM, Marek Olšák wrote:

From: Marek Olšák 

The extension was exposed but not the functions.

This fixes:
 
dEQP-GLES31.functional.debug.negative_coverage.get_error.buffer.readn_pixels
 
dEQP-GLES31.functional.debug.negative_coverage.get_error.state.get_nuniformfv
 
dEQP-GLES31.functional.debug.negative_coverage.get_error.state.get_nuniformiv

Cc: 18.1 18.2 
---
  src/mapi/glapi/gen/KHR_robustness_es.xml | 32 
  1 file changed, 32 insertions(+)

diff --git a/src/mapi/glapi/gen/KHR_robustness_es.xml 
b/src/mapi/glapi/gen/KHR_robustness_es.xml
index 84f6fd2cdb9..82b7edf31a7 100644
--- a/src/mapi/glapi/gen/KHR_robustness_es.xml
+++ b/src/mapi/glapi/gen/KHR_robustness_es.xml
@@ -53,11 +53,43 @@
  
  

  
  
  
  
  
  
  
  
+

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
  


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