[Mesa-dev] [Bug 107563] [RADV] Broken rendering in Unity demos

[bugzilla-daemon]

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

--- Comment #4 from Alexander Tsoy  ---
Also both demos causes VM faults:

[39619.603973] amdgpu :01:00.0: GPU fault detected: 146 0x0e68240c
[39619.610244] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001197CD
[39619.617749] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0202400C
[39619.625251] amdgpu :01:00.0: VM fault (0x0c, vmid 1) at page 1152973,
read from 'DB2' (0x44423200) (36)
[39619.635022] amdgpu :01:00.0: GPU fault detected: 146 0x0e28240c
[39619.641280] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x001197C7
[39619.648762] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x020D400C
[39619.656242] amdgpu :01:00.0: VM fault (0x0c, vmid 1) at page 1152967,
read from 'DB7' (0x44423700) (212)
[39633.831895] amdgpu :01:00.0: GPU fault detected: 146 0x0828540c
[39633.838168] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0011D105
[39633.845644] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0405400C
[39633.853116] amdgpu :01:00.0: VM fault (0x0c, vmid 2) at page 1167621,
read from 'DB1' (0x44423100) (84)
[39633.862864] amdgpu :01:00.0: GPU fault detected: 146 0x0318d40c
[39633.869123] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0011D30B
[39633.876603] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x040A400C
[39633.884084] amdgpu :01:00.0: VM fault (0x0c, vmid 2) at page 1168139,
read from 'DB4' (0x44423400) (164)

-- 
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 107564] AttributeError: 'module' object has no attribute 'combinations_with_replacement'

[bugzilla-daemon]

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

Bug ID: 107564
   Summary: AttributeError: 'module' object has no attribute
'combinations_with_replacement'
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Keywords: bisected, regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: baker.dyla...@gmail.com, boche...@daitauha.fr

Build error with Python 2.6.

  GENnir/nir_opt_algebraic.c
Traceback (most recent call last):
  File "./nir/nir_opt_algebraic.py", line 726, in 
for left, right in itertools.combinations_with_replacement(invert.keys(),
2):
AttributeError: 'module' object has no attribute
'combinations_with_replacement'


commit d9ca4a172e8e8a42217588ca1b83a7ceb5bf3f76
Author: Mathieu Bridon 
Date:   Thu Aug 9 10:27:19 2018 +0200

python: Use the right function for the job

The code was just reimplementing itertools.combinations_with_replacement
in a less efficient way.

This does change the order of the results slightly, but it should be ok.

Signed-off-by: Mathieu Bridon 
Reviewed-by: Dylan Baker 

-- 
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] virgl: ARB_texture_barrier support

[Tomeu Vizoso]

Reviewed-by: Tomeu Vizoso 

On 14 August 2018 at 07:40, Dave Airlie  wrote:
> ping?
> On Wed, 8 Aug 2018 at 08:46, Dave Airlie  wrote:
>>
>> From: Dave Airlie 
>>
>> ---
>>  src/gallium/drivers/virgl/virgl_context.c  | 9 +++--
>>  src/gallium/drivers/virgl/virgl_encode.c   | 8 
>>  src/gallium/drivers/virgl/virgl_encode.h   | 2 ++
>>  src/gallium/drivers/virgl/virgl_hw.h   | 1 +
>>  src/gallium/drivers/virgl/virgl_protocol.h | 5 +
>>  src/gallium/drivers/virgl/virgl_screen.c   | 2 +-
>>  6 files changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
>> b/src/gallium/drivers/virgl/virgl_context.c
>> index 03c0fd7cd50..dc1dd2d3c29 100644
>> --- a/src/gallium/drivers/virgl/virgl_context.c
>> +++ b/src/gallium/drivers/virgl/virgl_context.c
>> @@ -805,9 +805,14 @@ static void virgl_set_sampler_views(struct pipe_context 
>> *ctx,
>>  }
>>
>>  static void
>> -virgl_texture_barrier(struct pipe_context *pctx, unsigned flags)
>> +virgl_texture_barrier(struct pipe_context *ctx, unsigned flags)
>>  {
>> -   /* stub */
>> +   struct virgl_context *vctx = virgl_context(ctx);
>> +   struct virgl_screen *rs = virgl_screen(ctx->screen);
>> +
>> +   if (!(rs->caps.caps.v2.capability_bits & VIRGL_CAP_TEXTURE_BARRIER))
>> +  return;
>> +   virgl_encode_texture_barrier(vctx, flags);
>>  }
>>
>>  static void virgl_destroy_sampler_view(struct pipe_context *ctx,
>> diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
>> b/src/gallium/drivers/virgl/virgl_encode.c
>> index 670c5fe6c3d..190c338f458 100644
>> --- a/src/gallium/drivers/virgl/virgl_encode.c
>> +++ b/src/gallium/drivers/virgl/virgl_encode.c
>> @@ -1009,3 +1009,11 @@ int virgl_encode_launch_grid(struct virgl_context 
>> *ctx,
>> virgl_encoder_write_dword(ctx->cbuf, grid_info->indirect_offset);
>> return 0;
>>  }
>> +
>> +int virgl_encode_texture_barrier(struct virgl_context *ctx,
>> + unsigned flags)
>> +{
>> +   virgl_encoder_write_cmd_dword(ctx, 
>> VIRGL_CMD0(VIRGL_CCMD_TEXTURE_BARRIER, 0, 1));
>> +   virgl_encoder_write_dword(ctx->cbuf, flags);
>> +   return 0;
>> +}
>> diff --git a/src/gallium/drivers/virgl/virgl_encode.h 
>> b/src/gallium/drivers/virgl/virgl_encode.h
>> index c982eb954f3..749cd330120 100644
>> --- a/src/gallium/drivers/virgl/virgl_encode.h
>> +++ b/src/gallium/drivers/virgl/virgl_encode.h
>> @@ -272,4 +272,6 @@ int virgl_encode_memory_barrier(struct virgl_context 
>> *ctx,
>>  unsigned flags);
>>  int virgl_encode_launch_grid(struct virgl_context *ctx,
>>   const struct pipe_grid_info *grid_info);
>> +int virgl_encode_texture_barrier(struct virgl_context *ctx,
>> + unsigned flags);
>>  #endif
>> diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
>> b/src/gallium/drivers/virgl/virgl_hw.h
>> index 1df9d0e77d1..b56f554b001 100644
>> --- a/src/gallium/drivers/virgl/virgl_hw.h
>> +++ b/src/gallium/drivers/virgl/virgl_hw.h
>> @@ -229,6 +229,7 @@ enum virgl_formats {
>>  #define VIRGL_CAP_ROBUST_BUFFER_ACCESS (1 << 9)
>>  #define VIRGL_CAP_TGSI_FBFETCH (1 << 10)
>>  #define VIRGL_CAP_SHADER_CLOCK (1 << 11)
>> +#define VIRGL_CAP_TEXTURE_BARRIER  (1 << 12)
>>
>>  /* virgl bind flags - these are compatible with mesa 10.5 gallium.
>>   * but are fixed, no other should be passed to virgl either.
>> diff --git a/src/gallium/drivers/virgl/virgl_protocol.h 
>> b/src/gallium/drivers/virgl/virgl_protocol.h
>> index 982bc5c8c2b..0a41c0174f2 100644
>> --- a/src/gallium/drivers/virgl/virgl_protocol.h
>> +++ b/src/gallium/drivers/virgl/virgl_protocol.h
>> @@ -91,6 +91,7 @@ enum virgl_context_cmd {
>> VIRGL_CCMD_MEMORY_BARRIER,
>> VIRGL_CCMD_LAUNCH_GRID,
>> VIRGL_CCMD_SET_FRAMEBUFFER_STATE_NO_ATTACH,
>> +   VIRGL_CCMD_TEXTURE_BARRIER,
>>  };
>>
>>  /*
>> @@ -539,4 +540,8 @@ enum virgl_context_cmd {
>>  #define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_LAYERS(x) (x & 0x)
>>  #define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_SAMPLES(x) ((x >> 16) & 0xff)
>>
>> +/* texture barrier */
>> +#define VIRGL_TEXTURE_BARRIER_SIZE 1
>> +#define VIRGL_TEXTURE_BARRIER_FLAGS 1
>> +
>>  #endif
>> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
>> b/src/gallium/drivers/virgl/virgl_screen.c
>> index 421fde5249d..87ce3b7355d 100644
>> --- a/src/gallium/drivers/virgl/virgl_screen.c
>> +++ b/src/gallium/drivers/virgl/virgl_screen.c
>> @@ -124,7 +124,7 @@ virgl_get_param(struct pipe_screen *screen, enum 
>> pipe_cap param)
>> case PIPE_CAP_CONDITIONAL_RENDER:
>>return vscreen->caps.caps.v1.bset.conditional_render;
>> case PIPE_CAP_TEXTURE_BARRIER:
>> -  return 0;
>> +  return vscreen->caps.caps.v2.capability_bits & 
>> VIRGL_CAP_TEXTURE_BARRIER;
>> case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
>>return 1;
>> case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
>> --
>> 2.14.3
>>
>> ___
>> mesa-

[Mesa-dev] [Bug 107563] [RADV] Broken rendering in Unity demos

[bugzilla-daemon]

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

--- Comment #3 from Alexander Tsoy  ---
This is a regression in mesa-18.2. Demos rendered just fine on the same system
with mesa-18.1.

-- 
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] [V2] i965: Context aware user space EU control through application

[aravindan . muthukumar]

From: "Muthukumar, Aravindan" 

 The Patch here is to give control to user/ application to really
 decide what's the max GPU load it would put. If that can be
 known in advance, rpcs can be programmed accordingly.
 This solution has changes across i915,
 drm and mesa (not limited only to kernel).

 Here, we pass gpu_load_type = {high, medium, low} from application
 while context is created. Default here is 'High' and applications
 roughly know if they are going to eat up entire GPU. The typical
 usecase of 'Low' is idle screen or minor mouse movements. Users can
 read meaning of high/medium/low for their platform  & then program
 contexts accordingly. Here gpu_load_type directly translates to
 number of shader cores/EUs a particular GPU has.

 V2 : changes for setting the loadtype through setparam.

 Signed-off-by: Aravindan Muthukumar 
 Signed-off-by: Kedar J Karanje 
 Signed-off-by: Praveen Diwakar 
 Signed-off-by: Yogesh Marathe 
---
 include/drm-uapi/i915_drm.h |  1 +
 src/mesa/drivers/dri/i965/brw_bufmgr.c  | 20 
 src/mesa/drivers/dri/i965/brw_bufmgr.h  |  4 
 src/mesa/drivers/dri/i965/brw_context.c |  8 +++-
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 16e452a..737e78e 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -1453,6 +1453,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
 #define I915_CONTEXT_PARAM_BANNABLE0x5
 #define I915_CONTEXT_PARAM_PRIORITY0x6
+#define I915_CONTEXT_PARAM_LOAD_TYPE0x7
 #define   I915_CONTEXT_MAX_USER_PRIORITY   1023 /* inclusive */
 #define   I915_CONTEXT_DEFAULT_PRIORITY0
 #define   I915_CONTEXT_MIN_USER_PRIORITY   -1023 /* inclusive */
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c 
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 8ba915b..8dd4bab 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -1332,6 +1332,26 @@ brw_create_hw_context(struct brw_bufmgr *bufmgr)
return create.ctx_id;
 }
 
+/* DYNAMIC EU CONTROL */
+int
+brw_hw_context_load_type(struct brw_bufmgr *bufmgr,
+uint32_t ctx_id,
+int load_type)
+{
+   struct drm_i915_gem_context_param p = {
+   .ctx_id = ctx_id,
+   .param  = I915_CONTEXT_PARAM_LOAD_TYPE,
+   .value = load_type,
+   };
+   int err;
+
+   err = 0;
+   if(drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &p))
+   err = -errno;
+
+   return err;
+}
+
 int
 brw_hw_context_set_priority(struct brw_bufmgr *bufmgr,
 uint32_t ctx_id,
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h 
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index 68f5e0c..9e9419b 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -313,6 +313,10 @@ int brw_bo_wait(struct brw_bo *bo, int64_t timeout_ns);
 
 uint32_t brw_create_hw_context(struct brw_bufmgr *bufmgr);
 
+int brw_hw_context_load_type(struct brw_bufmgr *bufmgr,
+ uint32_t ctx_id,
+ int load_type);
+
 int brw_hw_context_set_priority(struct brw_bufmgr *bufmgr,
 uint32_t ctx_id,
 int priority);
diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 01a3e16..2ef21b6 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -888,7 +888,8 @@ brwCreateContext(gl_api api,
 
if (ctx_config->attribute_mask &
~(__DRIVER_CONTEXT_ATTRIB_RESET_STRATEGY |
- __DRIVER_CONTEXT_ATTRIB_PRIORITY)) {
+ __DRIVER_CONTEXT_ATTRIB_PRIORITY |
+ __DRIVER_CONTEXT_ATTRIB_LOAD_TYPE)) {
   *dri_ctx_error = __DRI_CTX_ERROR_UNKNOWN_ATTRIBUTE;
   return false;
}
@@ -1005,6 +1006,11 @@ brwCreateContext(gl_api api,
  return false;
   }
 
+  if(ctx_config->attribute_mask & __DRIVER_CONTEXT_ATTRIB_LOAD_TYPE) {
+ brw_hw_context_load_type(brw->bufmgr,
+  brw->hw_ctx,ctx_config->load_type);
+  }
+
   int hw_priority = GEN_CONTEXT_MEDIUM_PRIORITY;
   if (ctx_config->attribute_mask & __DRIVER_CONTEXT_ATTRIB_PRIORITY) {
  switch (ctx_config->priority) {
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] virgl: ARB_texture_barrier support

[Dave Airlie]

ping?
On Wed, 8 Aug 2018 at 08:46, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> ---
>  src/gallium/drivers/virgl/virgl_context.c  | 9 +++--
>  src/gallium/drivers/virgl/virgl_encode.c   | 8 
>  src/gallium/drivers/virgl/virgl_encode.h   | 2 ++
>  src/gallium/drivers/virgl/virgl_hw.h   | 1 +
>  src/gallium/drivers/virgl/virgl_protocol.h | 5 +
>  src/gallium/drivers/virgl/virgl_screen.c   | 2 +-
>  6 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/virgl/virgl_context.c 
> b/src/gallium/drivers/virgl/virgl_context.c
> index 03c0fd7cd50..dc1dd2d3c29 100644
> --- a/src/gallium/drivers/virgl/virgl_context.c
> +++ b/src/gallium/drivers/virgl/virgl_context.c
> @@ -805,9 +805,14 @@ static void virgl_set_sampler_views(struct pipe_context 
> *ctx,
>  }
>
>  static void
> -virgl_texture_barrier(struct pipe_context *pctx, unsigned flags)
> +virgl_texture_barrier(struct pipe_context *ctx, unsigned flags)
>  {
> -   /* stub */
> +   struct virgl_context *vctx = virgl_context(ctx);
> +   struct virgl_screen *rs = virgl_screen(ctx->screen);
> +
> +   if (!(rs->caps.caps.v2.capability_bits & VIRGL_CAP_TEXTURE_BARRIER))
> +  return;
> +   virgl_encode_texture_barrier(vctx, flags);
>  }
>
>  static void virgl_destroy_sampler_view(struct pipe_context *ctx,
> diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
> b/src/gallium/drivers/virgl/virgl_encode.c
> index 670c5fe6c3d..190c338f458 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.c
> +++ b/src/gallium/drivers/virgl/virgl_encode.c
> @@ -1009,3 +1009,11 @@ int virgl_encode_launch_grid(struct virgl_context *ctx,
> virgl_encoder_write_dword(ctx->cbuf, grid_info->indirect_offset);
> return 0;
>  }
> +
> +int virgl_encode_texture_barrier(struct virgl_context *ctx,
> + unsigned flags)
> +{
> +   virgl_encoder_write_cmd_dword(ctx, VIRGL_CMD0(VIRGL_CCMD_TEXTURE_BARRIER, 
> 0, 1));
> +   virgl_encoder_write_dword(ctx->cbuf, flags);
> +   return 0;
> +}
> diff --git a/src/gallium/drivers/virgl/virgl_encode.h 
> b/src/gallium/drivers/virgl/virgl_encode.h
> index c982eb954f3..749cd330120 100644
> --- a/src/gallium/drivers/virgl/virgl_encode.h
> +++ b/src/gallium/drivers/virgl/virgl_encode.h
> @@ -272,4 +272,6 @@ int virgl_encode_memory_barrier(struct virgl_context *ctx,
>  unsigned flags);
>  int virgl_encode_launch_grid(struct virgl_context *ctx,
>   const struct pipe_grid_info *grid_info);
> +int virgl_encode_texture_barrier(struct virgl_context *ctx,
> + unsigned flags);
>  #endif
> diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
> b/src/gallium/drivers/virgl/virgl_hw.h
> index 1df9d0e77d1..b56f554b001 100644
> --- a/src/gallium/drivers/virgl/virgl_hw.h
> +++ b/src/gallium/drivers/virgl/virgl_hw.h
> @@ -229,6 +229,7 @@ enum virgl_formats {
>  #define VIRGL_CAP_ROBUST_BUFFER_ACCESS (1 << 9)
>  #define VIRGL_CAP_TGSI_FBFETCH (1 << 10)
>  #define VIRGL_CAP_SHADER_CLOCK (1 << 11)
> +#define VIRGL_CAP_TEXTURE_BARRIER  (1 << 12)
>
>  /* virgl bind flags - these are compatible with mesa 10.5 gallium.
>   * but are fixed, no other should be passed to virgl either.
> diff --git a/src/gallium/drivers/virgl/virgl_protocol.h 
> b/src/gallium/drivers/virgl/virgl_protocol.h
> index 982bc5c8c2b..0a41c0174f2 100644
> --- a/src/gallium/drivers/virgl/virgl_protocol.h
> +++ b/src/gallium/drivers/virgl/virgl_protocol.h
> @@ -91,6 +91,7 @@ enum virgl_context_cmd {
> VIRGL_CCMD_MEMORY_BARRIER,
> VIRGL_CCMD_LAUNCH_GRID,
> VIRGL_CCMD_SET_FRAMEBUFFER_STATE_NO_ATTACH,
> +   VIRGL_CCMD_TEXTURE_BARRIER,
>  };
>
>  /*
> @@ -539,4 +540,8 @@ enum virgl_context_cmd {
>  #define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_LAYERS(x) (x & 0x)
>  #define VIRGL_SET_FRAMEBUFFER_STATE_NO_ATTACH_SAMPLES(x) ((x >> 16) & 0xff)
>
> +/* texture barrier */
> +#define VIRGL_TEXTURE_BARRIER_SIZE 1
> +#define VIRGL_TEXTURE_BARRIER_FLAGS 1
> +
>  #endif
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 421fde5249d..87ce3b7355d 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -124,7 +124,7 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
> param)
> case PIPE_CAP_CONDITIONAL_RENDER:
>return vscreen->caps.caps.v1.bset.conditional_render;
> case PIPE_CAP_TEXTURE_BARRIER:
> -  return 0;
> +  return vscreen->caps.caps.v2.capability_bits & 
> VIRGL_CAP_TEXTURE_BARRIER;
> case PIPE_CAP_VERTEX_COLOR_UNCLAMPED:
>return 1;
> case PIPE_CAP_FRAGMENT_COLOR_CLAMPED:
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [Bug 107563] [RADV] Broken rendering in Unity demos

[bugzilla-daemon]

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

--- Comment #2 from Alexander Tsoy  ---
Created attachment 141076
  --> https://bugs.freedesktop.org/attachment.cgi?id=141076&action=edit
VikingVillage.png

-- 
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 107563] [RADV] Broken rendering in Unity demos

[bugzilla-daemon]

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

--- Comment #1 from Alexander Tsoy  ---
Created attachment 141075
  --> https://bugs.freedesktop.org/attachment.cgi?id=141075&action=edit
CorridorLightingExample.png

-- 
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 107563] [RADV] Broken rendering in Unity demos

[bugzilla-daemon]

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

Bug ID: 107563
   Summary: [RADV] Broken rendering in Unity demos
   Product: Mesa
   Version: 18.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: alexan...@tsoy.me
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 141074
  --> https://bugs.freedesktop.org/attachment.cgi?id=141074&action=edit
vulkaninfo

Broken rendering in Unity vulkan demos. See screenshots.

linux-4.14.62, mesa-18.2.0-rc2, llvm-6.0.1

GPU:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (rev f1) (prog-if 00 [VGA
controller])

-- 
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 3/3] radv: Add on-demand compilation of built-in shaders.

[Dave Airlie]

On Tue, 14 Aug 2018 at 09:01, Bas Nieuwenhuizen  
wrote:
>
> In environments where we cannot cache, e.g. Android (no homedir),
> ChromeOS (readonly rootfs) or sandboxes (cannot open cache), the
> startup cost of creating a device in radv is rather high, due
> to compiling all possible built-in pipelines up front. This meant
> depending on the CPU a 1-4 sec cost of creating a Device.
>
> For CTS this cost is unacceptable, and likely for starting random
> apps too.
>
> So if there is no cache, with this patch radv will compile shaders
> on demand. Once there is a cache from the first run, even if
> incomplete, the driver knows that it can likely write the cache
> and precompiles everything.
>
> Note that I did not switch the buffer and itob/btoi compute pipelines
> to on-demand, since you cannot really do anything in Vulkan without
> them and there are only a few.
>
> This reduces the CTS runtime for the no caches scenario on my
> threadripper from 32 minutes to 8 minutes.
> ---
>  src/amd/vulkan/radv_meta.c| 35 ++
>  src/amd/vulkan/radv_meta.h| 18 ++---
>  src/amd/vulkan/radv_meta_blit.c   | 86 ++--
>  src/amd/vulkan/radv_meta_blit2d.c | 69 ++-
>  src/amd/vulkan/radv_meta_clear.c  | 96 +--
>  src/amd/vulkan/radv_meta_decompress.c | 32 -
>  src/amd/vulkan/radv_meta_fast_clear.c | 29 +++-
>  src/amd/vulkan/radv_meta_resolve.c| 48 +-
>  src/amd/vulkan/radv_meta_resolve_cs.c | 34 --
>  src/amd/vulkan/radv_meta_resolve_fs.c | 31 +++--
>  src/amd/vulkan/radv_pipeline_cache.c  | 16 +++--
>  src/amd/vulkan/radv_private.h |  8 ++-
>  src/amd/vulkan/radv_query.c   | 32 +++--
>  13 files changed, 454 insertions(+), 80 deletions(-)


> -   result = radv_device_init_meta_fast_clear_flush_state(device);
> +   result = radv_device_init_meta_fast_clear_flush_state(device, 
> on_demand);
> if (result != VK_SUCCESS)
> goto fail_fast_clear;
>
> -   result = radv_device_init_meta_resolve_compute_state(device);
> +   result = radv_device_init_meta_resolve_compute_state(device, 
> on_demand);
> if (result != VK_SUCCESS)
> goto fail_resolve_compute;
>
> -   result = radv_device_init_meta_resolve_fragment_state(device);
> +   result = radv_device_init_meta_resolve_fragment_state(device, 
> on_demand);
> if (result != VK_SUCCESS)
> goto fail_resolve_fragment;
> return VK_SUCCESS;
> @@ -407,6 +413,7 @@ fail_blit:
>  fail_resolve:
> radv_device_finish_meta_clear_state(device);
>  fail_clear:
> +   mtx_destroy(&device->meta_state.mtx);


You destroy the mutex here in the error path, but you don't destroy it
in the normal cleanup
path from what I can see.

>
> +static enum glsl_sampler_dim
> +translate_sampler_dim(VkImageType type) {
> +   switch(type) {
> +   case VK_IMAGE_TYPE_1D:
> +   return GLSL_SAMPLER_DIM_1D;
> +   case VK_IMAGE_TYPE_2D:
> +   return GLSL_SAMPLER_DIM_2D;
> +   case VK_IMAGE_TYPE_3D:
> +   return GLSL_SAMPLER_DIM_3D;
> +   default:
> +   unreachable("Unhandled image type");
> +   }
> +}
> +
>  static void
>  meta_emit_blit(struct radv_cmd_buffer *cmd_buffer,
> struct radv_image *src_image,
> @@ -333,11 +354,12 @@ meta_emit_blit(struct radv_cmd_buffer *cmd_buffer,
>.height = dst_height,
>.layers = 1,
> }, &cmd_buffer->pool->alloc, &fb);
> -   VkPipeline pipeline;
> +   VkPipeline* pipeline = NULL;
> +   unsigned fs_key = 0;
> switch (src_iview->aspect_mask) {
> case VK_IMAGE_ASPECT_COLOR_BIT: {
> -   unsigned fs_key = 
> radv_format_meta_fs_key(dest_image->vk_format);
> unsigned dst_layout = 
> radv_meta_dst_layout_from_layout(dest_image_layout);
> +   fs_key = radv_format_meta_fs_key(dest_image->vk_format);
>
> radv_CmdBeginRenderPass(radv_cmd_buffer_to_handle(cmd_buffer),
>   &(VkRenderPassBeginInfo) {
> @@ -353,13 +375,13 @@ meta_emit_blit(struct radv_cmd_buffer *cmd_buffer,
>}, 
> VK_SUBPASS_CONTENTS_INLINE);
> switch (src_image->type) {
> case VK_IMAGE_TYPE_1D:
> -   pipeline = 
> device->meta_state.blit.pipeline_1d_src[fs_key];
> +   pipeline = 
> &device->meta_state.blit.pipeline_1d_src[fs_key];
> break;
> case VK_IMAGE_TYPE_2D:
> -   pipeline = 
> device->meta_state.blit.pipeline_2d_src[fs_key];
> +   pipeline = 
> &device->meta_state.blit.pipeline_2d_src[fs_key];
> break;
>

[Mesa-dev] [PATCH] virgl: bump 3D texture limit to 2048, as GL4.1 requires

[Gurchetan Singh]

This is virgl analogue to cf6dad.

Fixes:
  dEQP-GLES31.functional.image_load_store.3d.atomic.*

Example test cases:
  dEQP-GLES31.functional.image_load_store.3d.atomic.add_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.min_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.max_r32ui_return_value
  dEQP-GLES31.functional.image_load_store.3d.atomic.and_r32ui_return_value
---
 src/gallium/drivers/virgl/virgl_screen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index 421fde5249..745a502189 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -36,7 +36,7 @@
 #include "virgl_context.h"
 
 #define SP_MAX_TEXTURE_2D_LEVELS 15  /* 16K x 16K */
-#define SP_MAX_TEXTURE_3D_LEVELS 9   /* 512 x 512 x 512 */
+#define SP_MAX_TEXTURE_3D_LEVELS 12   /* 2048 x 2048 x 2048 */
 #define SP_MAX_TEXTURE_CUBE_LEVELS 13  /* 4K x 4K */
 
 static const char *
-- 
2.16.4

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

Re: [Mesa-dev] [PATCH] anv: add VK_EXT_sampler_filter_minmax support

[Jason Ekstrand]

On August 10, 2018 19:18:53 Yunchao He  wrote:


This extension can be supported on SKL+. With this patch,
all corresponding tests (6K+) in CTS can pass. No test fails.

I verified CTS with the command below:
deqp-vk --deqp-case=dEQP-VK.pipeline.sampler.view_type.*reduce*
---
src/intel/vulkan/anv_device.c  |  8 
src/intel/vulkan/anv_extensions.py |  1 +
src/intel/vulkan/anv_formats.c |  6 ++
src/intel/vulkan/genX_state.c  | 27 +++
4 files changed, 42 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 04fd6a829e..e45ba4b3af 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1116,6 +1116,14 @@ void anv_GetPhysicalDeviceProperties2(
 break;
  }

+  case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT: {

+ VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT *properties =
+(VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT *)ext;
+ properties->filterMinmaxImageComponentMapping = pdevice->info.gen 
>= 9;

+ properties->filterMinmaxSingleComponentFormats = true;
+ break;
+  }
+
  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_PROPERTIES: {
 VkPhysicalDeviceSubgroupProperties *properties = (void *)ext;

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py

index ea837744b4..e165bd371d 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -125,6 +125,7 @@ EXTENSIONS = [
Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),

Extension('VK_EXT_vertex_attribute_divisor',  2, True),
Extension('VK_EXT_post_depth_coverage',   1, 'device->info.gen 
>= 9'),
+Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->info.gen >= 9'),

]

class VkVersion:
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 815b320a82..b0eb4c6afa 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -489,6 +489,9 @@ get_image_format_features(const struct gen_device_info 
*devinfo,

  if (aspects == VK_IMAGE_ASPECT_DEPTH_BIT || devinfo->gen >= 8)
 flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT;

+  if (aspects == VK_IMAGE_ASPECT_DEPTH_BIT && devinfo->gen >= 9)
+ flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
+
  flags |= VK_FORMAT_FEATURE_BLIT_SRC_BIT |
   VK_FORMAT_FEATURE_BLIT_DST_BIT |
   VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR |
@@ -521,6 +524,9 @@ get_image_format_features(const struct gen_device_info 
*devinfo,

   if (isl_format_supports_sampling(devinfo, plane_format.isl_format)) {
  flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT;

+if (devinfo->gen >= 9)
+ flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;


Something is indented wrong here


+
  if (isl_format_supports_filtering(devinfo, plane_format.isl_format))
 flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT;
   }
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index b1014d9e79..e095cb4cc0 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -245,6 +245,14 @@ static const uint32_t vk_to_gen_shadow_compare_op[] = {
   [VK_COMPARE_OP_ALWAYS]   = PREFILTEROPNEVER,
};

+#if GEN_GEN >= 9
+static const uint32_t vk_to_gen_sampler_reduction_mode[] = {
+   [VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT] = STD_FILTER,
+   [VK_SAMPLER_REDUCTION_MODE_MIN_EXT]  = MINIMUM,
+   [VK_SAMPLER_REDUCTION_MODE_MAX_EXT]  = MAXIMUM,
+};
+#endif
+
VkResult genX(CreateSampler)(
VkDevice_device,
const VkSamplerCreateInfo*  pCreateInfo,
@@ -266,6 +274,10 @@ VkResult genX(CreateSampler)(
   uint32_t border_color_offset = device->border_colors.offset +
  pCreateInfo->borderColor * 64;

+#if GEN_GEN >= 9
+   unsigned sampler_reduction_mode = STD_FILTER;
+#endif
+
   vk_foreach_struct(ext, pCreateInfo->pNext) {
  switch (ext->sType) {
  case VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO: {
@@ -281,6 +293,16 @@ VkResult genX(CreateSampler)(
 sampler->conversion = conversion;
 break;
  }
+#if GEN_GEN >= 9
+  case VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT: {
+   struct VkSamplerReductionModeCreateInfoEXT *sampler_reduction =
+  (struct VkSamplerReductionModeCreateInfoEXT *) ext;
+ if (sampler_reduction)
+sampler_reduction_mode =
+   
vk_to_gen_sampler_reduction_mode[sampler_reduction->reductionMode];

+ break;
+  }
+#endif
  default:
 anv_debug_ignored_stype(ext->sType);
 break;
@@ -348,6 +370,11 @@ VkResult genX(CreateSampler)(
 .TCXAddre

Re: [Mesa-dev] [PATCH] anv: add VK_EXT_sampler_filter_minmax support

[Jason Ekstrand]

On August 10, 2018 19:18:53 Yunchao He  wrote:


This extension can be supported on SKL+. With this patch,
all corresponding tests (6K+) in CTS can pass. No test fails.

I verified CTS with the command below:
deqp-vk --deqp-case=dEQP-VK.pipeline.sampler.view_type.*reduce*
---
src/intel/vulkan/anv_device.c  |  8 
src/intel/vulkan/anv_extensions.py |  1 +
src/intel/vulkan/anv_formats.c |  6 ++
src/intel/vulkan/genX_state.c  | 27 +++
4 files changed, 42 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 04fd6a829e..e45ba4b3af 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1116,6 +1116,14 @@ void anv_GetPhysicalDeviceProperties2(
 break;
  }

+  case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT: {

+ VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT *properties =
+(VkPhysicalDeviceSamplerFilterMinmaxPropertiesEXT *)ext;
+ properties->filterMinmaxImageComponentMapping = pdevice->info.gen 
>= 9;

+ properties->filterMinmaxSingleComponentFormats = true;
+ break;
+  }
+
  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SUBGROUP_PROPERTIES: {
 VkPhysicalDeviceSubgroupProperties *properties = (void *)ext;

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py

index ea837744b4..e165bd371d 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -125,6 +125,7 @@ EXTENSIONS = [
Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),

Extension('VK_EXT_vertex_attribute_divisor',  2, True),
Extension('VK_EXT_post_depth_coverage',   1, 'device->info.gen 
>= 9'),
+Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->info.gen >= 9'),

]

class VkVersion:
diff --git a/src/intel/vulkan/anv_formats.c b/src/intel/vulkan/anv_formats.c
index 815b320a82..b0eb4c6afa 100644
--- a/src/intel/vulkan/anv_formats.c
+++ b/src/intel/vulkan/anv_formats.c
@@ -489,6 +489,9 @@ get_image_format_features(const struct gen_device_info 
*devinfo,

  if (aspects == VK_IMAGE_ASPECT_DEPTH_BIT || devinfo->gen >= 8)
 flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT;

+  if (aspects == VK_IMAGE_ASPECT_DEPTH_BIT && devinfo->gen >= 9)


I believe you want "if ((aspects & VK_IMAGE_ASPECT_DEPTH_BIT) && 
devinfo->gen >= 9)" here since we can support it on any depth format not 
just those that don't contain stencil.



+ flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
+
  flags |= VK_FORMAT_FEATURE_BLIT_SRC_BIT |
   VK_FORMAT_FEATURE_BLIT_DST_BIT |
   VK_FORMAT_FEATURE_TRANSFER_SRC_BIT_KHR |
@@ -521,6 +524,9 @@ get_image_format_features(const struct gen_device_info 
*devinfo,

   if (isl_format_supports_sampling(devinfo, plane_format.isl_format)) {
  flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT;

+if (devinfo->gen >= 9)
+ flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT;
+
  if (isl_format_supports_filtering(devinfo, plane_format.isl_format))
 flags |= VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT;
   }
diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
index b1014d9e79..e095cb4cc0 100644
--- a/src/intel/vulkan/genX_state.c
+++ b/src/intel/vulkan/genX_state.c
@@ -245,6 +245,14 @@ static const uint32_t vk_to_gen_shadow_compare_op[] = {
   [VK_COMPARE_OP_ALWAYS]   = PREFILTEROPNEVER,
};

+#if GEN_GEN >= 9
+static const uint32_t vk_to_gen_sampler_reduction_mode[] = {
+   [VK_SAMPLER_REDUCTION_MODE_WEIGHTED_AVERAGE_EXT] = STD_FILTER,
+   [VK_SAMPLER_REDUCTION_MODE_MIN_EXT]  = MINIMUM,
+   [VK_SAMPLER_REDUCTION_MODE_MAX_EXT]  = MAXIMUM,
+};
+#endif
+
VkResult genX(CreateSampler)(
VkDevice_device,
const VkSamplerCreateInfo*  pCreateInfo,
@@ -266,6 +274,10 @@ VkResult genX(CreateSampler)(
   uint32_t border_color_offset = device->border_colors.offset +
  pCreateInfo->borderColor * 64;

+#if GEN_GEN >= 9
+   unsigned sampler_reduction_mode = STD_FILTER;
+#endif
+
   vk_foreach_struct(ext, pCreateInfo->pNext) {
  switch (ext->sType) {
  case VK_STRUCTURE_TYPE_SAMPLER_YCBCR_CONVERSION_INFO: {
@@ -281,6 +293,16 @@ VkResult genX(CreateSampler)(
 sampler->conversion = conversion;
 break;
  }
+#if GEN_GEN >= 9
+  case VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT: {
+   struct VkSamplerReductionModeCreateInfoEXT *sampler_reduction =
+  (struct VkSamplerReductionModeCreateInfoEXT *) ext;
+ if (sampler_reduction)
+sampler_reduction_mode =
+   
vk_to_gen_sampler_reduction_mode[sampler_reduction->reductionMode];

+ break;
+  }
+#endif

Re: [Mesa-dev] [PATCH 2/2] blorp: Properly handle Z24X8 blits.

[Jason Ekstrand]

On August 10, 2018 04:18:51 Kenneth Graunke  wrote:


One of the reasons we didn't notice that R24_UNORM_X8_TYPELESS
destinations were broken was that an earlier layer was swapping it
out for B8G8R8A8_UNORM.  That made Z24X8 -> Z24X8 blits work.

However, R32_FLOAT -> R24_UNORM_X8_TYPELESS was still totally broken.
The old code only considered one format at a time, without thinking
that format conversion may need to occur.

This patch moves the translation out to a place where it can consider
both formats.  If both are Z24X8, we continue using B8G8R8A8_UNORM to
avoid having to do shader math workarounds.  If we have a Z24X8
destination, but a non-matching source, we use our shader hacks to
actually render to it properly.


Is the hack even all that useful? It's one more blorp shader compile.  I 
could see scaled depth blits being a thing people care about.  In fact, I 
know they will fairly soon if you catch my drift. :-)  Mind just dropping 
it completely?


--Jason



---
src/intel/blorp/blorp.c  | 12 
src/intel/blorp/blorp_blit.c | 11 +++
2 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/src/intel/blorp/blorp.c b/src/intel/blorp/blorp.c
index c36ec703b18..ffe26076e16 100644
--- a/src/intel/blorp/blorp.c
+++ b/src/intel/blorp/blorp.c
@@ -75,18 +75,6 @@ brw_blorp_surface_info_init(struct blorp_context *blorp,
   if (format == ISL_FORMAT_UNSUPPORTED)
  format = surf->surf->format;

-   if (format == ISL_FORMAT_R24_UNORM_X8_TYPELESS) {
-  /* Unfortunately, ISL_FORMAT_R24_UNORM_X8_TYPELESS it isn't supported as
-   * a render target, which would prevent us from blitting to 24-bit
-   * depth.  The miptree consists of 32 bits per pixel, arranged as 24-bit
-   * depth values interleaved with 8 "don't care" bits.  Since depth
-   * values don't require any blending, it doesn't matter how we interpret
-   * the bit pattern as long as we copy the right amount of data, so just
-   * map it as 8-bit BGRA.
-   */
-  format = ISL_FORMAT_B8G8R8A8_UNORM;
-   }
-
   info->surf = *surf->surf;
   info->addr = surf->addr;

diff --git a/src/intel/blorp/blorp_blit.c b/src/intel/blorp/blorp_blit.c
index 7b49f9afa35..3b84e634bd9 100644
--- a/src/intel/blorp/blorp_blit.c
+++ b/src/intel/blorp/blorp_blit.c
@@ -2241,6 +2241,17 @@ blorp_blit(struct blorp_batch *batch,
  }
   }

+   /* ISL_FORMAT_R24_UNORM_X8_TYPELESS it isn't supported as a render target,
+* which requires shader math to render to it.  Blitting Z24X8 to Z24X8
+* is fairly common though, so we'd like to avoid it.  Since we don't need
+* to blend depth values, we can simply pick a renderable format with the
+* right number of bits-per-pixel, like 8-bit BGRA.
+*/
+   if (dst_surf->surf->format == ISL_FORMAT_R24_UNORM_X8_TYPELESS &&
+   src_surf->surf->format == ISL_FORMAT_R24_UNORM_X8_TYPELESS) {
+  src_format = dst_format = ISL_FORMAT_B8G8R8A8_UNORM;
+   }
+
   brw_blorp_surface_info_init(batch->blorp, ¶ms.src, src_surf, src_level,
   src_layer, src_format, false);
   brw_blorp_surface_info_init(batch->blorp, ¶ms.dst, dst_surf, dst_level,
--
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 1/2] intel: decoder: handle 0 sized structs

[Lionel Landwerlin]

Gen7.5 has a BLEND_STATE of size 0 which includes a variable length
group. We did not deal with that very well, leading to an endless
loop.

Signed-off-by: Lionel Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107544
---
 src/intel/common/gen_decoder.c | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/src/intel/common/gen_decoder.c b/src/intel/common/gen_decoder.c
index ec0a486b101..daaf772a59f 100644
--- a/src/intel/common/gen_decoder.c
+++ b/src/intel/common/gen_decoder.c
@@ -991,7 +991,7 @@ gen_field_iterator_init(struct gen_field_iterator *iter,
iter->p_bit = p_bit;
 
int length = gen_group_get_length(iter->group, iter->p);
-   iter->p_end = length > 0 ? &p[length] : NULL;
+   iter->p_end = length >= 0 ? &p[length] : NULL;
iter->print_colors = print_colors;
 }
 
@@ -1000,16 +1000,32 @@ gen_field_iterator_next(struct gen_field_iterator *iter)
 {
/* Initial condition */
if (!iter->field) {
-  if (iter->group->fields)
+  if (iter->group->fields) {
+ /* We have an instruction/struct with at least one field. */
  iter->field = iter->group->fields;
-  else
+  } else if (iter->group->next) {
+ /* We have an instruction/struct with no fields but at least a
+  * group.
+  */
  iter->field = iter->group->next->fields;
+ iter->struct_desc =
+gen_spec_find_struct(iter->group->spec,
+ iter->field->type.gen_struct->name);
+  } else {
+ /* Please fix genxml. */
+ unreachable("Empty struct/instruction");
+ return false;
+  }
 
   bool result = iter_decode_field(iter);
-  if (iter->p_end)
- assert(result);
+  if (!result && iter->p_end) {
+ /* We're dealing with a non empty struct of length=0 (BLEND_STATE on
+  * Gen 7.5)
+  */
+ assert(iter->group->dw_length == 0);
+  }
 
-  return true;
+  return result;
}
 
if (!iter_advance_field(iter))
-- 
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] intel: batch-decoder: fix parsing of BLEND_STATE

[Lionel Landwerlin]

The previous implementation seemed to imply that
3DSTATE_BLEND_STATE_POINTERS had a pointer to an array of BLEND_STATE.
This is true on Gen7.5 but not on Gen8+. The actual array is made up
of BLEND_STATE_ENTRY elements following BLEND_STATE (which is empty on
Gen7.5).

Signed-off-by: Lionel Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107544
---
 src/intel/common/gen_batch_decoder.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/src/intel/common/gen_batch_decoder.c 
b/src/intel/common/gen_batch_decoder.c
index f5be0018afc..715eeaa159c 100644
--- a/src/intel/common/gen_batch_decoder.c
+++ b/src/intel/common/gen_batch_decoder.c
@@ -691,7 +691,31 @@ static void
 decode_3dstate_blend_state_pointers(struct gen_batch_decode_ctx *ctx,
 const uint32_t *p)
 {
-   decode_dynamic_state_pointers(ctx, "BLEND_STATE", p, 1);
+   struct gen_group *inst = gen_spec_find_instruction(ctx->spec, p);
+   struct gen_group *state = gen_spec_find_struct(ctx->spec, "BLEND_STATE");
+   struct gen_group *state_entry = gen_spec_find_struct(ctx->spec, 
"BLEND_STATE_ENTRY");
+   uint32_t state_offset = 0;
+
+   struct gen_field_iterator iter;
+   gen_field_iterator_init(&iter, inst, p, 0, false);
+   while (gen_field_iterator_next(&iter)) {
+  if (str_ends_with(iter.name, "Pointer")) {
+ state_offset = iter.raw_value;
+ break;
+  }
+   }
+
+   uint64_t state_addr = ctx->dynamic_base + state_offset;
+   struct gen_batch_decode_bo bo = ctx_get_bo(ctx, state_addr);
+   const void *state_map = bo.map;
+
+   ctx_print_group(ctx, state, state_offset, state_map);
+
+   state_addr += state->dw_length;
+   state_map += state->dw_length;
+
+   fprintf(ctx->fp, "%s 0\n", state_entry->name);
+   ctx_print_group(ctx, state_entry, state_offset, state_map);
 }
 
 static void
-- 
2.18.0

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

[Mesa-dev] [PATCH 1/5] intel/compiler: Silence unused parameter warning

[Ian Romanick]

From: Ian Romanick 

A later commit would have added the warning below.  All of the other
brw_*_desc take and use a gen_device_info parameter.  All of the
functions are static and inline, so the compiler optimizes the parameter
away.  To maintain the pattern, just mark the parameter UNUSED.

In file included from src/intel/compiler/brw_fs_nir.cpp:28:0:
src/intel/compiler/brw_eu.h: In function ‘uint32_t brw_pixel_interp_desc(const 
gen_device_info*, unsigned int, bool, unsigned int, unsigned int)’:
src/intel/compiler/brw_eu.h:372:53: warning: unused parameter ‘devinfo’ 
[-Wunused-parameter]
 brw_pixel_interp_desc(const struct gen_device_info *devinfo,
 ^~~

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_eu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 3824ab2ec6a..9fc9112a29d 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -369,7 +369,7 @@ brw_dp_surface_desc(const struct gen_device_info *devinfo,
  * interpolator function controls.
  */
 static inline uint32_t
-brw_pixel_interp_desc(const struct gen_device_info *devinfo,
+brw_pixel_interp_desc(UNUSED const struct gen_device_info *devinfo,
   unsigned msg_type,
   bool noperspective,
   unsigned simd_mode,
-- 
2.14.4

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

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

[Ian Romanick]

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.

Iron Lake
total instructions in shared programs: 7730019 -> 7731893 (0.02%)
instructions in affected programs: 139980 -> 141854 (1.34%)
helped: 262
HURT: 329
helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 3
helped stats (rel) min: 0.11% max: 4.69% x̄: 1.70% x̃: 1.30%
HURT stats (abs)   min: 1 max: 19 x̄: 8.09 x̃: 7
HURT stats (rel)   min: 0.32% max: 23.53% x̄: 5.10% x̃: 4.74%
95% mean confidence interval for instructions value: 2.62 3.72
95% mean confidence interval for instructions %-change: 1.73% 2.44%
Instructions are HURT.

total cycles in shared programs: 177866190 -> 177851638 (<.01%)
cycles in affected programs: 18970354 -> 18955802 (-0.08%)
helped: 1700
HURT: 962
helped stats (abs) min: 2 max: 70 x̄: 17.40 x̃: 16
helped stats (rel) min: <.01% max: 3.36% x̄: 0.37% x̃: 0.23%
HURT stats (abs)   min: 2 max: 114 x̄: 15.62 x̃: 6
HURT stats (rel)   min: <.01% max: 10.50% x̄: 0.98% x̃: 0.39%
95% mean confidence interval for cycles value: -6.33 -4.60
95% mean confidence interval for cycles %-change: 0.07% 0.16%
Inconclusive result (value mean confidence interval and %-change mean 
confidence interval disagree).

total loops in shared programs: 854 -> 850 (-0.47%)
loops in affected programs: 4 -> 0
helped: 4
HURT: 0
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 100.00% max: 100.00% x̄: 100.00% x̃: 100.00%
95% mean confidence interval for loops value: -1.00 -1.00
95% mean confidence interval for loops %-change: -100.00% -100.00%
Loops are helped.

GM45
total instructions in shared programs: 4769335 -> 4770019 (0.01%)
instructions in affected programs: 90821 -> 91505 (0.75%)
helped: 219
HURT: 167
helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 3
helped stats (rel) min: 0.11% max: 4.35% x̄: 1.70% x̃: 1.30%
HURT stats (abs)   min: 1 max: 19 x̄: 8.02 x̃: 7
HURT stats (rel)   min: 0.32% max: 22.86% x̄: 4.95% x̃: 4.57%
95% mean confidence interval for instructions value: 1.12 2.43
95% mean confidence interval for instructions %-change: 0.77% 1.59%
Instructions are HURT.

total cycles in shared programs: 121980262 -> 121970888 (<.01%)
cycles in affected programs: 12861602 -> 12852228 (-0.07%)
helped: 1040
HURT: 492
helped stats (abs) min: 2 max: 70 x̄: 17.65 x̃: 16
helped stats (rel) min: <.01% max: 3.36% x̄: 0.32% x̃: 0.21%
HURT stats (abs)   min: 2 max: 114 x̄: 18.26 x̃: 6
HURT stats (rel)   min: <.01% max: 10.50% x̄: 1.00% x̃: 0.35%
95% mean confidence interval for cycles value: -7.34 -4.89
95% mean confidence interval for cycles %-change: 0.05% 0.17%
Inconclusive result (value mean confidence interval and %-change mean 
confidence interval disagree).

total loops in shared programs: 631 -> 629 (-0.32%)
loops in affected programs: 2 -> 0
helped: 2
HURT: 0

Signed-off-by: Ian Romanick 
Cc: Marek Olšák 
Cc: Rob Clark 
Cc: Eric Anholt 
---
 src/compiler/nir/nir_opt_algebraic.py | 30 --
 1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index f11a987c462..54f901e6cad 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -120,8 +120,6 @@ optimizations = [
(('flrp@64', 1.0, b, c), ('fadd', ('fsub', 1.0, c), ('fmul', b, c)), 
'options->lower_flrp64'),
(('flrp@32', a, 1.0, c), ('fadd', a, ('fmul', c, ('fsub', 1.0, a))), 
'options->lower_flrp32'),
(('flrp@64', a, 1.0, c), ('fadd', a, ('fmul', c, ('fsub', 1.0, a))), 
'options->lower_flrp64'),
-   (('flrp@32', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp32'),
-   (('flrp@64', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp64'),
(('ffract', a), ('fsub', a, ('ffloor', a)), 'options->lower_ffract'),
(('~fadd', ('fmul', a, ('fadd', 1.0, ('fneg', ('b2f', c, ('fmul', b, 
('b2f', c))), ('bcsel', c, b, a), 'options->lower_flrp32'),
(('~fadd@32', ('fmul', a, ('fadd', 1.0, ('fneg', c ))), ('fmul', b, 
c )), ('flrp', a, b, c), '!options->lower_flrp32'),
@@ -134,6 +132,30 @@ optimizations = [
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
 
+   # flrp(a, b, c) * flrp(d, e, c)
+   # (a(1-c) + bc)) * (d(1-c) + ec)
+   #
+   # Since (1-d) is common, it is one operation less than the other
+   #  expansion.
+   (('fm

[Mesa-dev] [PATCH 4/5] nir: Lower flrp(1.0, b, c) and flrp(a, 1.0, c) differently

[Ian Romanick]

From: Ian Romanick 

Instead of lowering as (a + c(b - a)), lower as (a(1 - c) + bc).  Since
either a or b is 1.0, some of the multiplications drop out.

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.

Iron Lake
total instructions in shared programs: 7745041 -> 7731595 (-0.17%)
instructions in affected programs: 1647106 -> 1633660 (-0.82%)
helped: 5522
HURT: 281
helped stats (abs) min: 1 max: 12 x̄: 2.53 x̃: 2
helped stats (rel) min: 0.14% max: 12.00% x̄: 1.45% x̃: 0.99%
HURT stats (abs)   min: 1 max: 5 x̄: 1.94 x̃: 2
HURT stats (rel)   min: 0.13% max: 4.17% x̄: 0.74% x̃: 0.68%
95% mean confidence interval for instructions value: -2.35 -2.28
95% mean confidence interval for instructions %-change: -1.38% -1.31%
Instructions are helped.

total cycles in shared programs: 178004318 -> 177937186 (-0.04%)
cycles in affected programs: 31813800 -> 31746668 (-0.21%)
helped: 5420
HURT: 631
helped stats (abs) min: 2 max: 168 x̄: 13.15 x̃: 12
helped stats (rel) min: 0.01% max: 6.37% x̄: 0.67% x̃: 0.30%
HURT stats (abs)   min: 2 max: 328 x̄: 6.57 x̃: 4
HURT stats (rel)   min: 0.01% max: 2.78% x̄: 0.16% x̃: 0.11%
95% mean confidence interval for cycles value: -11.35 -10.84
95% mean confidence interval for cycles %-change: -0.60% -0.56%
Cycles are helped.

GM45
total instructions in shared programs: 4777279 -> 4770160 (-0.15%)
instructions in affected programs: 928555 -> 921436 (-0.77%)
helped: 2902
HURT: 149
helped stats (abs) min: 1 max: 12 x̄: 2.55 x̃: 2
helped stats (rel) min: 0.14% max: 11.11% x̄: 1.38% x̃: 0.91%
HURT stats (abs)   min: 1 max: 5 x̄: 1.93 x̃: 2
HURT stats (rel)   min: 0.13% max: 4.00% x̄: 0.72% x̃: 0.68%
95% mean confidence interval for instructions value: -2.38 -2.28
95% mean confidence interval for instructions %-change: -1.33% -1.23%
Instructions are helped.

total cycles in shared programs: 122063992 -> 122021958 (-0.03%)
cycles in affected programs: 20838672 -> 20796638 (-0.20%)
helped: 2921
HURT: 454
helped stats (abs) min: 2 max: 168 x̄: 15.40 x̃: 14
helped stats (rel) min: 0.01% max: 6.37% x̄: 0.67% x̃: 0.29%
HURT stats (abs)   min: 2 max: 328 x̄: 6.49 x̃: 4
HURT stats (rel)   min: 0.02% max: 2.78% x̄: 0.16% x̃: 0.11%
95% mean confidence interval for cycles value: -12.86 -12.04
95% mean confidence interval for cycles %-change: -0.59% -0.53%
Cycles are helped.

Signed-off-by: Ian Romanick 
Cc: Marek Olšák 
Cc: Rob Clark 
Cc: Eric Anholt 
---
 src/compiler/nir/nir_opt_algebraic.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index e770a61d9ff..f11a987c462 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -116,6 +116,10 @@ optimizations = [
(('~flrp', 0.0, a, b), ('fmul', a, b)),
(('~flrp', a, b, ('b2f', c)), ('bcsel', c, b, a), 'options->lower_flrp32'),
(('~flrp', a, 0.0, c), ('fadd', ('fmul', ('fneg', a), c), a)),
+   (('flrp@32', 1.0, b, c), ('fadd', ('fsub', 1.0, c), ('fmul', b, c)), 
'options->lower_flrp32'),
+   (('flrp@64', 1.0, b, c), ('fadd', ('fsub', 1.0, c), ('fmul', b, c)), 
'options->lower_flrp64'),
+   (('flrp@32', a, 1.0, c), ('fadd', a, ('fmul', c, ('fsub', 1.0, a))), 
'options->lower_flrp32'),
+   (('flrp@64', a, 1.0, c), ('fadd', a, ('fmul', c, ('fsub', 1.0, a))), 
'options->lower_flrp64'),
(('flrp@32', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp32'),
(('flrp@64', a, b, c), ('fadd', ('fmul', c, ('fsub', b, a)), a), 
'options->lower_flrp64'),
(('ffract', a), ('fsub', a, ('ffloor', a)), 'options->lower_ffract'),
@@ -125,6 +129,8 @@ optimizations = [
(('~fadd', a, ('fmul', ('b2f', c), ('fadd', b, ('fneg', a, ('bcsel', c, 
b, a), 'options->lower_flrp32'),
(('~fadd@32', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp', 
a, b, c), '!options->lower_flrp32'),
(('~fadd@64', a, ('fmul', c , ('fadd', b, ('fneg', a, ('flrp', 
a, b, c), '!options->lower_flrp64'),
+   (('~fadd@32', 1.0, ('fmul',   c , ('fadd', b,   -1.0 ))), ('fadd', 
('fsub', 1.0, c), ('fmul', b, c)), 'options->lower_flrp32'),
+   (('~fadd@64', 1.0, ('fmul',   c , ('fadd', b,   -1.0 ))), ('fadd', 
('fsub', 1.0, c), ('fmul', b, c)), 'options->lower_flrp64'),
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
 
-- 
2.14.4

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

[Mesa-dev] [PATCH 3/5] intel/compiler: Don't emit flrp for Gen4 or Gen5

[Ian Romanick]

From: Ian Romanick 

No changes on any Gen6+ platform.

The shaders with loops hurt are SIMD8 and SIMD16 shaders for a
text-identical fragment shader.  The loops are unrolled again in a later
patch that may or may not be included in the final series (nir: Lower
flrp differently when the alpha value is reused).

Iron Lake
total instructions in shared programs: 036 -> 7735975 (-0.53%)
instructions in affected programs: 4328363 -> 4287302 (-0.95%)
helped: 16404
HURT: 3099
helped stats (abs) min: 1 max: 155 x̄: 2.87 x̃: 2
helped stats (rel) min: 0.03% max: 35.48% x̄: 1.68% x̃: 1.25%
HURT stats (abs)   min: 1 max: 10 x̄: 1.96 x̃: 2
HURT stats (rel)   min: 0.16% max: 13.64% x̄: 1.63% x̃: 1.04%
95% mean confidence interval for instructions value: -2.16 -2.05
95% mean confidence interval for instructions %-change: -1.18% -1.12%
Instructions are helped.

total cycles in shared programs: 177812870 -> 177650934 (-0.09%)
cycles in affected programs: 99773058 -> 99611122 (-0.16%)
helped: 15939
HURT: 3997
helped stats (abs) min: 2 max: 930 x̄: 13.49 x̃: 6
helped stats (rel) min: <.01% max: 44.61% x̄: 0.70% x̃: 0.32%
HURT stats (abs)   min: 2 max: 148 x̄: 13.28 x̃: 8
HURT stats (rel)   min: <.01% max: 10.80% x̄: 0.58% x̃: 0.30%
95% mean confidence interval for cycles value: -8.48 -7.76
95% mean confidence interval for cycles %-change: -0.46% -0.43%
Cycles are helped.

total loops in shared programs: 850 -> 854 (0.47%)
loops in affected programs: 0 -> 4
helped: 0
HURT: 4
HURT stats (abs)   min: 1 max: 1 x̄: 1.00 x̃: 1
HURT stats (rel)   min: 0.00% max: 0.00% x̄: 0.00% x̃: 0.00%
95% mean confidence interval for loops value: 1.00 1.00
95% mean confidence interval for loops %-change: 0.00% 0.00%
Loops are HURT.

LOST:   0
GAINED: 17

GM45
total instructions in shared programs: 4790213 -> 4768928 (-0.44%)
instructions in affected programs: 2306120 -> 2284835 (-0.92%)
helped: 8348
HURT: 1569
helped stats (abs) min: 1 max: 155 x̄: 2.92 x̃: 2
helped stats (rel) min: 0.03% max: 34.38% x̄: 1.64% x̃: 1.21%
HURT stats (abs)   min: 1 max: 10 x̄: 1.96 x̃: 2
HURT stats (rel)   min: 0.15% max: 12.50% x̄: 1.58% x̃: 1.01%
95% mean confidence interval for instructions value: -2.22 -2.07
95% mean confidence interval for instructions %-change: -1.17% -1.09%
Instructions are helped.

total cycles in shared programs: 121844398 -> 121739752 (-0.09%)
cycles in affected programs: 61211048 -> 61106402 (-0.17%)
helped: 8198
HURT: 2017
helped stats (abs) min: 2 max: 930 x̄: 16.49 x̃: 10
helped stats (rel) min: <.01% max: 41.03% x̄: 0.75% x̃: 0.33%
HURT stats (abs)   min: 2 max: 148 x̄: 15.16 x̃: 12
HURT stats (rel)   min: <.01% max: 10.51% x̄: 0.62% x̃: 0.28%
95% mean confidence interval for cycles value: -10.84 -9.65
95% mean confidence interval for cycles %-change: -0.51% -0.46%
Cycles are helped.

total loops in shared programs: 629 -> 631 (0.32%)
loops in affected programs: 0 -> 2
helped: 0
HURT: 2

total fills in shared programs: 93 -> 94 (1.08%)
fills in affected programs: 81 -> 82 (1.23%)
helped: 0
HURT: 1

LOST:   17
GAINED: 17

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_compiler.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_compiler.c 
b/src/intel/compiler/brw_compiler.c
index 6df9621fe42..730819476e4 100644
--- a/src/intel/compiler/brw_compiler.c
+++ b/src/intel/compiler/brw_compiler.c
@@ -161,7 +161,7 @@ brw_compiler_create(void *mem_ctx, const struct 
gen_device_info *devinfo)
 
   if (is_scalar) {
  compiler->glsl_compiler_options[i].NirOptions =
-devinfo->gen < 11 ? &scalar_nir_options : 
&scalar_nir_options_gen11;
+devinfo->gen < 11 && devinfo->gen > 5 ? &scalar_nir_options : 
&scalar_nir_options_gen11;
   } else {
  compiler->glsl_compiler_options[i].NirOptions =
 devinfo->gen < 6 ? &vector_nir_options : &vector_nir_options_gen6;
-- 
2.14.4

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

[Mesa-dev] [PATCH 2/5] intel/compiler: Repeat nir_opt_algebraic_late until no more progress

[Ian Romanick]

From: Ian Romanick 

Withouth this, a pattern that creates a sequence that another pattern
can match will never perform the second match.  This can mean either
lost optimization opportunity (and a lot of frustration... "Why the
%@#$ isn't my optimization happening?!?") or, even worse, missed
lowering.

No shader-db changes on any platform.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_nir.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 31ffbe613ec..4a6e9560643 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -776,7 +776,10 @@ brw_postprocess_nir(nir_shader *nir, const struct 
brw_compiler *compiler,
   OPT(brw_nir_opt_peephole_ffma);
}
 
-   OPT(nir_opt_algebraic_late);
+   do {
+  progress = false;
+  OPT(nir_opt_algebraic_late);
+   } while (progress);
 
OPT(nir_lower_to_source_mods);
OPT(nir_copy_prop);
-- 
2.14.4

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

[Mesa-dev] [PATCH 0/5] Do better for flrp on platforms that lack flrp instruction

[Ian Romanick]

This series is a prerequisite for the optimizations that I actually
wanted to do.  That series, which affects the use of nir_op_flrp, will
come later.

For some reason, Intel Gen5 and earlier platforms don't lower flrp
instructions in NIR.  Instead these instructions are lowered when
converting from NIR to Gen assembly.  This would be understandable if
the backend lowering used the strict, by the spec lowering to a(1-c)+bc,
but it doesn't.  The backend uses the same a+c(b-a) lowering as NIR.

Lowering in NIR enables existing NIR optimizations.  It also provides an
opportunity for new nir_opt_algebraic optimizations based on the "a" and
"b" parameters of the flrp.  The final results are pretty good.

Across the whole series for Iron Lake:

total instructions in shared programs: 7781330 -> 7728593 (-0.68%)
instructions in affected programs: 4378493 -> 4325756 (-1.20%)
helped: 17807
HURT: 1643
helped stats (abs) min: 1 max: 155 x̄: 3.21 x̃: 2
helped stats (rel) min: 0.07% max: 35.48% x̄: 1.80% x̃: 1.32%
HURT stats (abs)   min: 1 max: 17 x̄: 2.68 x̃: 1
HURT stats (rel)   min: 0.19% max: 12.00% x̄: 1.71% x̃: 1.11%
95% mean confidence interval for instructions value: -2.77 -2.65
95% mean confidence interval for instructions %-change: -1.53% -1.47%
Instructions are helped.

total cycles in shared programs: 177879330 -> 177635216 (-0.14%)
cycles in affected programs: 100176772 -> 99932658 (-0.24%)
helped: 17882
HURT: 2009
helped stats (abs) min: 2 max: 930 x̄: 15.21 x̃: 8
helped stats (rel) min: <.01% max: 44.61% x̄: 0.74% x̃: 0.36%
HURT stats (abs)   min: 2 max: 126 x̄: 13.90 x̃: 6
HURT stats (rel)   min: <.01% max: 11.27% x̄: 0.56% x̃: 0.21%
95% mean confidence interval for cycles value: -12.64 -11.91
95% mean confidence interval for cycles %-change: -0.63% -0.59%
Cycles are helped.

LOST:   0
GAINED: 17

Across the whole series for GM45:

total instructions in shared programs: 4792461 -> 4764706 (-0.58%)
instructions in affected programs: 2357852 -> 2330097 (-1.18%)
helped: 9156
HURT: 834
helped stats (abs) min: 1 max: 155 x̄: 3.27 x̃: 2
helped stats (rel) min: 0.07% max: 34.38% x̄: 1.75% x̃: 1.29%
HURT stats (abs)   min: 1 max: 17 x̄: 2.67 x̃: 1
HURT stats (rel)   min: 0.19% max: 11.69% x̄: 1.66% x̃: 1.08%
95% mean confidence interval for instructions value: -2.86 -2.69
95% mean confidence interval for instructions %-change: -1.51% -1.43%
Instructions are helped.

total cycles in shared programs: 121883478 -> 121727206 (-0.13%)
cycles in affected programs: 62107848 -> 61951576 (-0.25%)
helped: 9276
HURT: 1094
helped stats (abs) min: 2 max: 930 x̄: 18.63 x̃: 12
helped stats (rel) min: <.01% max: 41.03% x̄: 0.79% x̃: 0.37%
HURT stats (abs)   min: 2 max: 126 x̄: 15.10 x̃: 6
HURT stats (rel)   min: <.01% max: 10.51% x̄: 0.55% x̃: 0.18%
95% mean confidence interval for cycles value: -15.66 -14.48
95% mean confidence interval for cycles %-change: -0.67% -0.62%
Cycles are helped.

total fills in shared programs: 93 -> 94 (1.08%)
fills in affected programs: 81 -> 82 (1.23%)
helped: 0
HURT: 1

LOST:   17
GAINED: 17


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

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Kristian Høgsberg]

On Mon, Aug 13, 2018 at 3:53 AM Emil Velikov  wrote:
>
> Hi Adam,
>
> Thanks for the extensive write-up.
>
> On 9 August 2018 at 20:30, Adam Jackson  wrote:
> > On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:
> >
> >> In the GLX case, it's required due to server-side rendering. One needs
> >> a separate primitive for each pbuffer, thus the information can be
> >> passed long the wire.
> >
> > I can't parse this. "Primitive"?
> >
> > So, backstory time. GLX_SGIX_pbuffer was the genesis of pbuffers.
> > Here's what it has to say about how a pbuffer is unlike other GLX
> > drawables (some of which is a comment about how things happened to work
> > on IRIX):
> >
> > "GLXPbuffers are equivalent to GLXPixmaps with the following
> > exceptions:
> >
> > 1.  There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
> > resource, it may not be possible to render to it using X or an
> > X extension other than GLX.
> >
> > 2.  The format of the color buffers and the type and size of any
> > associated ancillary buffers for a GLXPbuffer can only be
> > described with a GLXFBConfig -- an X Visual cannot be used.
> >
> > 3.  It is possible to create a GLXPbuffer whose contents may be
> > asynchronously lost at any time.
> >
> > 4.  GLXPbuffers can be rendered to using either direct or indirect
> > rendering contexts.
> >
> > 5.  The allocation of a GLXPbuffer can fail if there are insufficient
> > resources (i.e., all the pbuffer memory has been allocated and
> > the implementation does not virtualize pbuffer memory.)"
> >
> > In contrast, a GLXPixmap _must_ be renderable by X11, cannot lose its
> > contents, and _may_ not be renderable by direct contexts. All of this
> > dates to like 1997, so we didn't have FBOs yet, and any rendering
> > surface would have been allocated by "the server" [1]. That extension
> > was merged into GLX 1.3 pretty much unchanged, and GLX 1.3 was 1998.
> >
> > Xorg didn't get GLX 1.3 working until like 2007 [2]. As an
> > implementation choice, Xorg _does_ back pbuffers with pixmaps, both in
> > that it calls ->CreatePixmap internally to make them and that it tracks
> > them as actual pixmaps [3]. We never clobber pbuffers, we have no
> > problem rendering to pbuffers from X11, and we have no problem
> > rendering to GLXPixmaps from direct contexts. Effectively, other than
> > the resource type, the difference between a pbuffer and a glxpixmap is
> > that the latter takes two XIDs and two resource creation calls.
> >
> So if I understood you correctly [and the spec] there is no
> requirement (nor ban) on rendering to pbuffers from X11.
> It's an implementation decision to allow it.

You can't render to the underlying pixmaps, since the drawable ID is
internal to the GLX implementation.

> > EGL dates to 2003, which means it predates even EXT_framebuffer_object,
> > so the pbuffer bit of GLX was kept in the new API. The EGL spec says a
> > pbuffer has no associated native window or native window type - no
> > kidding, it's not a window - but it does not require that a pbuffer
> > have no native object backing it at all.
> >
> I> Now, direct rendering in GLX is underspecified; the implementation is
> > free to use whatever subset of GLX, and whatever private protocol, it
> > wants. In principle the client could allocate the pbuffer's storage
> > from the "server" (the drm, here), and pass that handle and its new XID
> > name to the X server to bind them together so indirect contexts can
> > name it as well.
> >
> > An EGL implementation could take even more liberties. Even on an X11
> > window system there's no intrinsic reason that an EGL pbuffer need to
> > exist as a native winsys object; all that's required is that pbuffers
> > work with any API that takes an EGLSurface parameter. You might choose
> > to mirror EGL surfaces as GLX objects, or not, whatever your
> > implementation finds convenient. In practice, we back pbuffers with
> > pixmaps because we also back pixmaps with pixmaps, and there's no
> > reason to make those paths diverge more than they have to.
> >
> I was thinking in the opposite direction - we already have pbuffer
> implementation, which is duplicated across egl/android and
> egl/surfaceless.
> We could trivially make that a helper function and reuse across the board.
>
> No need to special case X11, Android, etc - far less code and
> divergence across platforms.
> Using the same codepath across all EGL won't be that bad, right?

I think that's good clean up at this point, but when I wrote the
pbuffer support it was the other way around - we already had pixmaps
and it was easy to use those for pbuffers.

Kristian

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

[Mesa-dev] [PATCH 2/3] radv: Refactor blit pipeline creation.

[Bas Nieuwenhuizen]

---
 src/amd/vulkan/radv_meta_blit.c | 525 +++-
 1 file changed, 175 insertions(+), 350 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/radv_meta_blit.c
index f68496d3202..370d4fcd831 100644
--- a/src/amd/vulkan/radv_meta_blit.c
+++ b/src/amd/vulkan/radv_meta_blit.c
@@ -715,15 +715,169 @@ radv_device_finish_meta_blit_state(struct radv_device 
*device)
 }
 
 static VkResult
-radv_device_init_meta_blit_color(struct radv_device *device,
-struct radv_shader_module *vs)
+build_pipeline(struct radv_device *device,
+   VkImageAspectFlagBits aspect,
+   enum glsl_sampler_dim tex_dim,
+   unsigned fs_key,
+   VkPipeline *pipeline)
 {
-   struct radv_shader_module fs_1d = {0}, fs_2d = {0}, fs_3d = {0};
-   VkResult result;
+   VkResult result = VK_SUCCESS;
+   struct radv_shader_module fs = {0};
+   struct radv_shader_module vs = {.nir = build_nir_vertex_shader()};
+   VkRenderPass rp;
+
+   switch(aspect) {
+   case VK_IMAGE_ASPECT_COLOR_BIT:
+   fs.nir = build_nir_copy_fragment_shader(tex_dim);
+   rp = device->meta_state.blit.render_pass[fs_key][0];
+   break;
+   case VK_IMAGE_ASPECT_DEPTH_BIT:
+   fs.nir = build_nir_copy_fragment_shader_depth(tex_dim);
+   rp = device->meta_state.blit.depth_only_rp[0];
+   break;
+   case VK_IMAGE_ASPECT_STENCIL_BIT:
+   fs.nir = build_nir_copy_fragment_shader_stencil(tex_dim);
+   rp = device->meta_state.blit.stencil_only_rp[0];
+   break;
+   default:
+   unreachable("Unhandled aspect");
+   }
+   VkPipelineVertexInputStateCreateInfo vi_create_info = {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO,
+   .vertexBindingDescriptionCount = 0,
+   .vertexAttributeDescriptionCount = 0,
+   };
+
+   VkPipelineShaderStageCreateInfo pipeline_shader_stages[] = {
+   {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO,
+   .stage = VK_SHADER_STAGE_VERTEX_BIT,
+   .module = radv_shader_module_to_handle(&vs),
+   .pName = "main",
+   .pSpecializationInfo = NULL
+   }, {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_SHADER_STAGE_CREATE_INFO,
+   .stage = VK_SHADER_STAGE_FRAGMENT_BIT,
+   .module = radv_shader_module_to_handle(&fs),
+   .pName = "main",
+   .pSpecializationInfo = NULL
+   },
+   };
+
+   VkGraphicsPipelineCreateInfo vk_pipeline_info = {
+   .sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO,
+   .stageCount = ARRAY_SIZE(pipeline_shader_stages),
+   .pStages = pipeline_shader_stages,
+   .pVertexInputState = &vi_create_info,
+   .pInputAssemblyState = 
&(VkPipelineInputAssemblyStateCreateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_INPUT_ASSEMBLY_STATE_CREATE_INFO,
+   .topology = VK_PRIMITIVE_TOPOLOGY_TRIANGLE_STRIP,
+   .primitiveRestartEnable = false,
+   },
+   .pViewportState = &(VkPipelineViewportStateCreateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_VIEWPORT_STATE_CREATE_INFO,
+   .viewportCount = 1,
+   .scissorCount = 1,
+   },
+   .pRasterizationState = 
&(VkPipelineRasterizationStateCreateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_RASTERIZATION_STATE_CREATE_INFO,
+   .rasterizerDiscardEnable = false,
+   .polygonMode = VK_POLYGON_MODE_FILL,
+   .cullMode = VK_CULL_MODE_NONE,
+   .frontFace = VK_FRONT_FACE_COUNTER_CLOCKWISE
+   },
+   .pMultisampleState = &(VkPipelineMultisampleStateCreateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_MULTISAMPLE_STATE_CREATE_INFO,
+   .rasterizationSamples = 1,
+   .sampleShadingEnable = false,
+   .pSampleMask = (VkSampleMask[]) { UINT32_MAX },
+   },
+   .pDynamicState = &(VkPipelineDynamicStateCreateInfo) {
+   .sType = 
VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO,
+   .dynamicStateCount = 4,
+   .pDynamicStates = (VkDynamicState[]) {
+   VK_DYNAMIC_STATE_VIEWPORT,
+   VK_DYNAMIC_STATE_SCISSOR,
+   VK_DYNAMIC_STATE_LINE_WIDTH,
+   VK_DYNAMIC_STATE_BLEND_CONSTAN

[Mesa-dev] [PATCH 1/3] radv: Make fs key exemplars ordered to be a reverse fs_key lookup.

[Bas Nieuwenhuizen]

While at it, share the exemplars and account for a non-occurring
fs key.
---
 src/amd/vulkan/radv_meta_blit.c   | 21 +++--
 src/amd/vulkan/radv_meta_blit2d.c | 19 ++-
 src/amd/vulkan/radv_meta_clear.c  | 19 ++-
 src/amd/vulkan/radv_meta_resolve.c| 19 ++-
 src/amd/vulkan/radv_meta_resolve_fs.c | 19 ++-
 src/amd/vulkan/radv_pipeline.c| 27 ++-
 src/amd/vulkan/radv_private.h |  3 ++-
 7 files changed, 39 insertions(+), 88 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_blit.c b/src/amd/vulkan/radv_meta_blit.c
index 67c26aabdb3..f68496d3202 100644
--- a/src/amd/vulkan/radv_meta_blit.c
+++ b/src/amd/vulkan/radv_meta_blit.c
@@ -714,21 +714,6 @@ radv_device_finish_meta_blit_state(struct radv_device 
*device)
state->blit.ds_layout, &state->alloc);
 }
 
-static VkFormat pipeline_formats[] = {
-   VK_FORMAT_R8G8B8A8_UNORM,
-   VK_FORMAT_R8G8B8A8_UINT,
-   VK_FORMAT_R8G8B8A8_SINT,
-   VK_FORMAT_A2R10G10B10_UINT_PACK32,
-   VK_FORMAT_A2R10G10B10_SINT_PACK32,
-   VK_FORMAT_R16G16B16A16_UNORM,
-   VK_FORMAT_R16G16B16A16_SNORM,
-   VK_FORMAT_R16G16B16A16_UINT,
-   VK_FORMAT_R16G16B16A16_SINT,
-   VK_FORMAT_R32_SFLOAT,
-   VK_FORMAT_R32G32_SFLOAT,
-   VK_FORMAT_R32G32B32A32_SFLOAT
-};
-
 static VkResult
 radv_device_init_meta_blit_color(struct radv_device *device,
 struct radv_shader_module *vs)
@@ -740,8 +725,8 @@ radv_device_init_meta_blit_color(struct radv_device *device,
fs_2d.nir = build_nir_copy_fragment_shader(GLSL_SAMPLER_DIM_2D);
fs_3d.nir = build_nir_copy_fragment_shader(GLSL_SAMPLER_DIM_3D);
 
-   for (unsigned i = 0; i < ARRAY_SIZE(pipeline_formats); ++i) {
-   unsigned key = radv_format_meta_fs_key(pipeline_formats[i]);
+   for (unsigned i = 0; i < NUM_META_FS_KEYS; ++i) {
+   unsigned key = 
radv_format_meta_fs_key(radv_fs_key_format_exemplars[i]);
for(unsigned j = 0; j < RADV_META_DST_LAYOUT_COUNT; ++j) {
VkImageLayout layout = 
radv_meta_dst_layout_to_layout(j);
result = 
radv_CreateRenderPass(radv_device_to_handle(device),
@@ -749,7 +734,7 @@ radv_device_init_meta_blit_color(struct radv_device *device,
.sType = 
VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO,

.attachmentCount = 1,
.pAttachments = 
&(VkAttachmentDescription) {
-   .format = 
pipeline_formats[i],
+   .format = 
radv_fs_key_format_exemplars[i],
.loadOp = 
VK_ATTACHMENT_LOAD_OP_LOAD,
.storeOp = 
VK_ATTACHMENT_STORE_OP_STORE,
.initialLayout 
= layout,
diff --git a/src/amd/vulkan/radv_meta_blit2d.c 
b/src/amd/vulkan/radv_meta_blit2d.c
index cac0a4dd55f..79652856942 100644
--- a/src/amd/vulkan/radv_meta_blit2d.c
+++ b/src/amd/vulkan/radv_meta_blit2d.c
@@ -1239,21 +1239,6 @@ blit2d_init_stencil_only_pipeline(struct radv_device 
*device,
return result;
 }
 
-static VkFormat pipeline_formats[] = {
-   VK_FORMAT_R8G8B8A8_UNORM,
-   VK_FORMAT_R8G8B8A8_UINT,
-   VK_FORMAT_R8G8B8A8_SINT,
-   VK_FORMAT_A2R10G10B10_UINT_PACK32,
-   VK_FORMAT_A2R10G10B10_SINT_PACK32,
-   VK_FORMAT_R16G16B16A16_UNORM,
-   VK_FORMAT_R16G16B16A16_SNORM,
-   VK_FORMAT_R16G16B16A16_UINT,
-   VK_FORMAT_R16G16B16A16_SINT,
-   VK_FORMAT_R32_SFLOAT,
-   VK_FORMAT_R32G32_SFLOAT,
-   VK_FORMAT_R32G32B32A32_SFLOAT
-};
-
 static VkResult
 meta_blit2d_create_pipe_layout(struct radv_device *device,
   int idx,
@@ -1320,8 +1305,8 @@ radv_device_init_meta_blit2d_state(struct radv_device 
*device)
if (result != VK_SUCCESS)
goto fail;
 
-   for (unsigned j = 0; j < ARRAY_SIZE(pipeline_formats); 
++j) {
-   result = blit2d_init_color_pipeline(device, 
src, pipeline_formats[j], log2_samples);
+   for (unsigned j = 0; j < NUM_META_FS_KEYS; ++j) {
+   result = blit2d_init_color_pipeline(device, 
src, radv_fs_key_format_exemplars[j], log2_samples);
if (result != VK_SUCCESS)
goto fail;
}
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index d7c98497343..4f77e32b83f 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -757,21 +757,6 @@ fail:
ret

[Mesa-dev] [PATCH 3/3] radv: Add on-demand compilation of built-in shaders.

[Bas Nieuwenhuizen]

In environments where we cannot cache, e.g. Android (no homedir),
ChromeOS (readonly rootfs) or sandboxes (cannot open cache), the
startup cost of creating a device in radv is rather high, due
to compiling all possible built-in pipelines up front. This meant
depending on the CPU a 1-4 sec cost of creating a Device.

For CTS this cost is unacceptable, and likely for starting random
apps too.

So if there is no cache, with this patch radv will compile shaders
on demand. Once there is a cache from the first run, even if
incomplete, the driver knows that it can likely write the cache
and precompiles everything.

Note that I did not switch the buffer and itob/btoi compute pipelines
to on-demand, since you cannot really do anything in Vulkan without
them and there are only a few.

This reduces the CTS runtime for the no caches scenario on my
threadripper from 32 minutes to 8 minutes.
---
 src/amd/vulkan/radv_meta.c| 35 ++
 src/amd/vulkan/radv_meta.h| 18 ++---
 src/amd/vulkan/radv_meta_blit.c   | 86 ++--
 src/amd/vulkan/radv_meta_blit2d.c | 69 ++-
 src/amd/vulkan/radv_meta_clear.c  | 96 +--
 src/amd/vulkan/radv_meta_decompress.c | 32 -
 src/amd/vulkan/radv_meta_fast_clear.c | 29 +++-
 src/amd/vulkan/radv_meta_resolve.c| 48 +-
 src/amd/vulkan/radv_meta_resolve_cs.c | 34 --
 src/amd/vulkan/radv_meta_resolve_fs.c | 31 +++--
 src/amd/vulkan/radv_pipeline_cache.c  | 16 +++--
 src/amd/vulkan/radv_private.h |  8 ++-
 src/amd/vulkan/radv_query.c   | 32 +++--
 13 files changed, 454 insertions(+), 80 deletions(-)

diff --git a/src/amd/vulkan/radv_meta.c b/src/amd/vulkan/radv_meta.c
index a59f38fb21d..aaf70b87554 100644
--- a/src/amd/vulkan/radv_meta.c
+++ b/src/amd/vulkan/radv_meta.c
@@ -257,7 +257,7 @@ radv_builtin_cache_path(char *path)
return true;
 }
 
-static void
+static bool
 radv_load_meta_pipeline(struct radv_device *device)
 {
char path[PATH_MAX + 1];
@@ -265,11 +265,11 @@ radv_load_meta_pipeline(struct radv_device *device)
void *data = NULL;
 
if (!radv_builtin_cache_path(path))
-   return;
+   return false;
 
int fd = open(path, O_RDONLY);
if (fd < 0)
-   return;
+   return false;
if (fstat(fd, &st))
goto fail;
data = malloc(st.st_size);
@@ -278,10 +278,11 @@ radv_load_meta_pipeline(struct radv_device *device)
if(read(fd, data, st.st_size) == -1)
goto fail;
 
-   radv_pipeline_cache_load(&device->meta_state.cache, data, st.st_size);
+   return radv_pipeline_cache_load(&device->meta_state.cache, data, 
st.st_size);
 fail:
free(data);
close(fd);
+   return false;
 }
 
 static void
@@ -330,6 +331,8 @@ radv_device_init_meta(struct radv_device *device)
 {
VkResult result;
 
+   memset(&device->meta_state, 0, sizeof(device->meta_state));
+
device->meta_state.alloc = (VkAllocationCallbacks) {
.pUserData = device,
.pfnAllocation = meta_alloc,
@@ -339,21 +342,24 @@ radv_device_init_meta(struct radv_device *device)
 
device->meta_state.cache.alloc = device->meta_state.alloc;
radv_pipeline_cache_init(&device->meta_state.cache, device);
-   radv_load_meta_pipeline(device);
+   bool loaded_cache = radv_load_meta_pipeline(device);
+   bool on_demand = !loaded_cache;
+
+   mtx_init(&device->meta_state.mtx, mtx_plain);
 
-   result = radv_device_init_meta_clear_state(device);
+   result = radv_device_init_meta_clear_state(device, on_demand);
if (result != VK_SUCCESS)
goto fail_clear;
 
-   result = radv_device_init_meta_resolve_state(device);
+   result = radv_device_init_meta_resolve_state(device, on_demand);
if (result != VK_SUCCESS)
goto fail_resolve;
 
-   result = radv_device_init_meta_blit_state(device);
+   result = radv_device_init_meta_blit_state(device, on_demand);
if (result != VK_SUCCESS)
goto fail_blit;
 
-   result = radv_device_init_meta_blit2d_state(device);
+   result = radv_device_init_meta_blit2d_state(device, on_demand);
if (result != VK_SUCCESS)
goto fail_blit2d;
 
@@ -361,7 +367,7 @@ radv_device_init_meta(struct radv_device *device)
if (result != VK_SUCCESS)
goto fail_bufimage;
 
-   result = radv_device_init_meta_depth_decomp_state(device);
+   result = radv_device_init_meta_depth_decomp_state(device, on_demand);
if (result != VK_SUCCESS)
goto fail_depth_decomp;
 
@@ -369,19 +375,19 @@ radv_device_init_meta(struct radv_device *device)
if (result != VK_SUCCESS)
goto fail_buffer;
 
-   result = radv_device_init_meta_query_state(device);
+   result = radv_device_init_meta_que

Re: [Mesa-dev] [RFC][PATCH 3/5] mesa: Add support for AMD_depth_clamp_separate

[Ian Romanick]

On 08/09/2018 01:09 PM, Marek Olšák wrote:
> On Wed, Aug 1, 2018 at 11:31 PM, Sagar Ghuge  wrote:
>> enable _mesa_PushAttrib() and _mesa_PopAttrib()
>> to handle GL_DEPTH_CLAMP_NEAR_AMD and
>> GL_DEPTH_CLAMP_FAR_AMD tokens.
>>
>> Signed-off-by: Sagar Ghuge 
>> ---
>>  src/mesa/main/attrib.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
>> index cbe93ab6fa..d9f165b428 100644
>> --- a/src/mesa/main/attrib.c
>> +++ b/src/mesa/main/attrib.c
>> @@ -73,6 +73,8 @@ struct gl_enable_attrib
>> GLboolean ColorMaterial;
>> GLboolean CullFace;
>> GLboolean DepthClamp;
>> +   GLboolean DepthClampNear;
>> +   GLboolean DepthClampFar;
> 
> The first patch uses this. Also, DepthClamp can be removed, because
> DepthClampNear+Far replace it, right?

Based on your comment on patch 4 and my comments on patch 0, maybe we
should:

- Remove DepthClamp.  Add _DepthClamp, DepthClampNear, and DepthClampFar.

- If GL_DEPTH_CLAMP is set, set all three.  If GL_DEPTH_CLAMP is
cleared, clear all three.

- If either of GL_DEPTH_CLAMP_FAR_AMD or GL_DEPTH_CLAMP_NEAR_AMD
changes, change _DepthClamp to DepthClampNear || DepthClampFar.

- Drivers that enable AMD_depth_clamp_separate will only ever look at
DepthClampNear and DepthClampFar.

I think that gets all the cases correct with the minimum fuss.  Marek,
what do you think?

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

Re: [Mesa-dev] [RFC][PATCH 3/5] mesa: Add support for AMD_depth_clamp_separate

[Ian Romanick]

On 08/09/2018 01:14 PM, Sagar Ghuge wrote:
> 
> 
> On 08/09/2018 01:09 PM, Marek Olšák wrote:
>> On Wed, Aug 1, 2018 at 11:31 PM, Sagar Ghuge  wrote:
>>> enable _mesa_PushAttrib() and _mesa_PopAttrib()
>>> to handle GL_DEPTH_CLAMP_NEAR_AMD and
>>> GL_DEPTH_CLAMP_FAR_AMD tokens.
>>>
>>> Signed-off-by: Sagar Ghuge 
>>> ---
>>>  src/mesa/main/attrib.c | 16 
>>>  1 file changed, 16 insertions(+)
>>>
>>> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
>>> index cbe93ab6fa..d9f165b428 100644
>>> --- a/src/mesa/main/attrib.c
>>> +++ b/src/mesa/main/attrib.c
>>> @@ -73,6 +73,8 @@ struct gl_enable_attrib
>>> GLboolean ColorMaterial;
>>> GLboolean CullFace;
>>> GLboolean DepthClamp;
>>> +   GLboolean DepthClampNear;
>>> +   GLboolean DepthClampFar;
>>
>> The first patch uses this. Also, DepthClamp can be removed, because
>> DepthClampNear+Far replace it, right?
> 
> Yes, that's true. 

Since this is your first significant patch series... we have an
unwritten (maybe actually written somewhere?) rule that a patch series
should build at every commit.  If a patch in the middle of a series
doesn't build, doing git-bisect on a (possibly unrelated) later problem
can be very painful.

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

Re: [Mesa-dev] [RFC][PATCH 0/5] mesa: Add types for AMD_depth_clamp_separate.

[Sagar Ghuge]

Hi everyone,

I am kind of stuck on this part actually. I don't have 
latest AMD graphics card to test following behavior which
Ian and Marek suggested me. 

I have written a piglit test :
https://gitlab.freedesktop.org/sagarghuge/piglit/blob/320b91ffb131b380f1d27d9c05ab141e0cd9e557/tests/spec/amd_depth_clamp_separate/depth_clamp_get_test.c

It would be great if someone can help me or test it in their 
spare time on latest AMD graphics card and provide some input
on the extension behavior on AMD's closed source driver. 


On 08/09/2018 01:11 PM, Marek Olšák wrote:
> On Thu, Aug 2, 2018 at 2:44 PM, Ian Romanick  wrote:
>> On 08/02/2018 11:30 AM, Ian Romanick wrote:
>>> On 08/01/2018 08:31 PM, Sagar Ghuge wrote:
 Add some basic types and storage for the
 AMD_depth_clamp_separate extension.
>>
>> I mentioned this on patch 5, but you should word wrap the commit message
>> to 70 or 72 columns.
>>
>> More substantive comments are below...
>>
 Signed-off-by: Sagar Ghuge 
 ---
  include/GL/glcorearb.h   | 2 ++
  src/mesa/main/extensions_table.h | 1 +
  src/mesa/main/mtypes.h   | 9 +
  3 files changed, 12 insertions(+)

 diff --git a/include/GL/glcorearb.h b/include/GL/glcorearb.h
 index a78bbb6e18..d73ca5a8df 100644
 --- a/include/GL/glcorearb.h
 +++ b/include/GL/glcorearb.h
 @@ -1558,6 +1558,8 @@ typedef int64_t GLint64;
  #define GL_MAX_FRAGMENT_INPUT_COMPONENTS  0x9125
  #define GL_CONTEXT_PROFILE_MASK   0x9126
  #define GL_DEPTH_CLAMP0x864F
 +#define GL_DEPTH_CLAMP_NEAR_AMD   0x901E
 +#define GL_DEPTH_CLAMP_FAR_AMD0x901F
  #define GL_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION 0x8E4C
  #define GL_FIRST_VERTEX_CONVENTION0x8E4D
  #define GL_LAST_VERTEX_CONVENTION 0x8E4E
>>>
>>> We should just import the updated versions of the Khronos headers.  I
>>> think Marek sent out a patch to do this.  Does that work?
>>>
 diff --git a/src/mesa/main/extensions_table.h 
 b/src/mesa/main/extensions_table.h
 index 3f01896cae..8dc668e087 100644
 --- a/src/mesa/main/extensions_table.h
 +++ b/src/mesa/main/extensions_table.h
 @@ -9,6 +9,7 @@
  EXT(3DFX_texture_compression_FXT1   , 
 TDFX_texture_compression_FXT1  , GLL, GLC,  x ,  x , 1999)

  EXT(AMD_conservative_depth  , ARB_conservative_depth  
, GLL, GLC,  x ,  x , 2009)
 +EXT(AMD_depth_clamp_separate, AMD_depth_clamp_separate
,  x , GLC,  x ,  x , 2009)
  EXT(AMD_draw_buffers_blend  , ARB_draw_buffers_blend  
, GLL, GLC,  x ,  x , 2009)
  EXT(AMD_performance_monitor , AMD_performance_monitor 
, GLL, GLC,  x , ES2, 2007)
  EXT(AMD_pinned_memory   , AMD_pinned_memory   
, GLL, GLC,  x ,  x , 2013)
 diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
 index d71872835d..406746a84c 100644
 --- a/src/mesa/main/mtypes.h
 +++ b/src/mesa/main/mtypes.h
 @@ -1280,6 +1280,8 @@ struct gl_transform_attrib
 GLboolean RescaleNormals;/**< 
 GL_EXT_rescale_normal */
 GLboolean RasterPositionUnclipped;   /**< 
 GL_IBM_rasterpos_clip */
 GLboolean DepthClamp;/**< GL_ARB_depth_clamp */
 +   GLboolean DepthClampNear;/**< 
 GL_AMD_depth_clamp_separate */
 +   GLboolean DepthClampFar; /**< 
 GL_AMD_depth_clamp_separate */
>>
>> I think we actually need two more flags here: _DepthClampNear and
>> _DepthClampFar.  The spec is a little unclear, so you may need to test
>> on some AMD closed-source drivers.  Specifically, the spec says
>>
>> "In addition to DEPTH_CLAMP_NEAR_AMD and DEPTH_CLAMP_FAR_AMD, the
>> token DEPTH_CLAMP may be used to simultaneously enable or disable
>> depth clamping at both the near and far planes."
>>
>> Based on that, I'm not sure what you're supposed to get if you do:
>>
>> glDisable(GL_DEPTH_CLAMP_NEAR_AMD);
>> glEnable(GL_DEPTH_CLAMP);
>> glGetIntegerv(GL_DEPTH_CLAMP_NEAR_AMD, &v);
>>
>> Should v contain GL_TRUE or GL_FALSE?  It seems clear that rendering
>> should have the near plane clamped.
>>
>> Depending on the results of testing on AMD drivers, we either need
>> enable / disable of GL_DEPTH_CLAMP to set / reset
>> gl_transform_attrib::DepthClampNear and
>> gl_transform_attrib::DepthClampFar or we need to add _DepthClampNear and
>> _DepthClampFar that get modified.  In the latter case, the driver would
>> only ever look at _DepthClampNear and _DepthClampFar.
>>
 /** GL_ARB_clip_control */
 GLenum16 ClipOrigin;   /**< GL_LOWER_LEFT or GL_UPPER_LEFT */
 GLenum16 ClipDepthMode;/**< GL_NEGATIVE_ONE_TO_ONE or GL_ZERO_TO_ONE */
>>>

Re: [Mesa-dev] [PATCH 00/13] Implement INTEL_shader_atomic_float_minmax

[Ian Romanick]

bump.

I've pushed a rebased version of the branch to the cgit below.

On 06/22/2018 10:03 PM, Ian Romanick wrote:
> I initially started implementing support for NV_shader_atomic_float.  I
> had misunderstood the hardware specs, and Intel hardware cannot actually
> do that extension.  It does have some floating-point atomic support, so
> I decided to create an extension based on what the hardware actually can
> do.  I discussed this with some guys at AMD and NVIDIA, and it seems
> nobody else can do these things.
> 
> Tests have been sent to the piglit mailing list.  SPIR-V and Vulkan
> extensions are also on the way, but they are taking a bit longer to
> author.  I've already encountered on rebase related problem, so I don't
> want to sit on this much longer.
> 
> The code is here:
> 
> 
> https://cgit.freedesktop.org/~idr/mesa/log/?h=INTEL_shader_atomic_float_minmax
> 
> and the tests are here:
> 
> 
> https://cgit.freedesktop.org/~idr/piglit/log/?h=INTEL_shader_atomic_float_minmax
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Robert Foss]

Hey again

On 13/08/2018 21.01, Robert Foss wrote:

Hey Emil,

On 13/08/2018 16.44, Emil Velikov wrote:

From: Emil Velikov 

Replace the manual handling of /dev/dri in famour of the drmDevice API.
The latter provides a consistent way of enumerating the devices,
providing device details as needed.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
If using VGEM the following patch is needed [1]. It's been on the list
for ages - will double-check and commmit it to drm-misc.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
---
  src/egl/drivers/dri2/platform_android.c | 23 +--
  1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c

index cc16fd8118f..685851acfc2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1290,6 +1290,7 @@ static int
  droid_open_device(_EGLDisplay *disp)
  {
 const int MAX_DRM_DEVICES = 32;
+   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };


The android-8.0.0_r35 AOSP checkout I'm running doesn't want to compile the 
above line.


external/mesa3d/src/egl/drivers/dri2/platform_android.c:1259:33: error: 
variable-sized object may not be initialized

    drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
     ^~~


external/mesa3d/src/egl/drivers/dri2/platform_android.c:1282:28: error: use of 
undeclared identifier 'dev_path'

  __func__, dev_path);



Sorry about the churn, but this error of course doesn't relate to the above one.
Still, this error string needs to be fixed.





 int prop_set, num_devices;
 int fd = -1, fallback_fd = -1;
@@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)
 if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
    vendor_name = vendor_buf;
-   const char *drm_dir_name = "/dev/dri";
-   DIR *sysdir = opendir(drm_dir_name);
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  return num_devices;
-   if (!sysdir)
-   return -errno;
+   for (int i = 0; i < num_devices; i++) {
+  device = devices[i];
-   struct dirent *dent;
-   while ((dent = readdir(sysdir))) {
-  char dev_path[128];
-  const char render_dev_prefix[] = "renderD";
-  size_t prefix_len = sizeof(render_dev_prefix) - 1;
-
-  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
+  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
   continue;
-  snprintf(dev_path, sizeof(dev_path), "%s/%s", drm_dir_name, 
dent->d_name);
-  fd = loader_open_device(dev_path);
+  fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
    if (fd < 0) {
   _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
   __func__, dev_path);
@@ -1341,7 +1336,7 @@ droid_open_device(_EGLDisplay *disp)
 }
  success:
-   closedir(sysdir);
+   drmFreeDevices(devices, num_devices);
 if (fallback_fd < 0 && fd < 0) {
    _eglLog(_EGL_WARNING, "Failed to open any DRM device");


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

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

Re: [Mesa-dev] [PATCH 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Robert Foss]

Hey Emil,

On 13/08/2018 16.44, Emil Velikov wrote:

From: Emil Velikov 

Replace the manual handling of /dev/dri in famour of the drmDevice API.
The latter provides a consistent way of enumerating the devices,
providing device details as needed.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
If using VGEM the following patch is needed [1]. It's been on the list
for ages - will double-check and commmit it to drm-misc.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
---
  src/egl/drivers/dri2/platform_android.c | 23 +--
  1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index cc16fd8118f..685851acfc2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1290,6 +1290,7 @@ static int
  droid_open_device(_EGLDisplay *disp)
  {
 const int MAX_DRM_DEVICES = 32;
+   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };


The android-8.0.0_r35 AOSP checkout I'm running doesn't want to compile the 
above line.


external/mesa3d/src/egl/drivers/dri2/platform_android.c:1259:33: error: 
variable-sized object may not be initialized

   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
^~~
external/mesa3d/src/egl/drivers/dri2/platform_android.c:1282:28: error: use of 
undeclared identifier 'dev_path'

 __func__, dev_path);



 int prop_set, num_devices;
 int fd = -1, fallback_fd = -1;
  
@@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)

 if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
vendor_name = vendor_buf;
  
-   const char *drm_dir_name = "/dev/dri";

-   DIR *sysdir = opendir(drm_dir_name);
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  return num_devices;
  
-   if (!sysdir)

-   return -errno;
+   for (int i = 0; i < num_devices; i++) {
+  device = devices[i];
  
-   struct dirent *dent;

-   while ((dent = readdir(sysdir))) {
-  char dev_path[128];
-  const char render_dev_prefix[] = "renderD";
-  size_t prefix_len = sizeof(render_dev_prefix) - 1;
-
-  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
+  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
   continue;
  
-  snprintf(dev_path, sizeof(dev_path), "%s/%s", drm_dir_name, dent->d_name);

-  fd = loader_open_device(dev_path);
+  fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
if (fd < 0) {
   _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
   __func__, dev_path);
@@ -1341,7 +1336,7 @@ droid_open_device(_EGLDisplay *disp)
 }
  
  success:

-   closedir(sysdir);
+   drmFreeDevices(devices, num_devices);
  
 if (fallback_fd < 0 && fd < 0) {

_eglLog(_EGL_WARNING, "Failed to open any DRM device");


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

Re: [Mesa-dev] [PATCH] mesa/glspirv: fix compilation with MSVC

[Dylan Baker]

This probably should have a Fixes tag?

Quoting Alejandro Piñeiro (2018-08-13 07:50:38)
> From AppVeyor #8582, it seems that MSVC doesn't like uint, so this
> patch replaces it with unsigned.
> ---
> 
> Note that Im not sure if this is the usual solution. As far as I see,
> uint is used on other source files. Having said so, just replacing for
> unsigned seems the easier way to fix this.
> 
>  src/mesa/main/glspirv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index 4fc80b72181..1c5b7dd17f3 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -188,7 +188,7 @@ nir_compute_double_inputs(nir_shader *shader,
>  {
> nir_foreach_variable(var, &shader->inputs) {
>if (glsl_type_is_dual_slot(glsl_without_array(var->type))) {
> - for (uint i = 0; i < glsl_count_attribute_slots(var->type, true); 
> i++) {
> + for (unsigned i = 0; i < glsl_count_attribute_slots(var->type, 
> true); i++) {
>  uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
>  shader->info.vs.double_inputs |= bitfield;
>   }
> -- 
> 2.14.1
> 
> ___
> 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 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Robert Foss]

Hey,

On 13/08/2018 16.44, Emil Velikov wrote:

From: Emil Velikov 

Replace the manual handling of /dev/dri in famour of the drmDevice API.
The latter provides a consistent way of enumerating the devices,
providing device details as needed.


Thanks for coding this up, it's neater and the way to go since vitio-gpu
support landed in libdrm.

Reviewed-by: Robert Foss 



Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
If using VGEM the following patch is needed [1]. It's been on the list
for ages - will double-check and commmit it to drm-misc.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
---
  src/egl/drivers/dri2/platform_android.c | 23 +--
  1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index cc16fd8118f..685851acfc2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1290,6 +1290,7 @@ static int
  droid_open_device(_EGLDisplay *disp)
  {
 const int MAX_DRM_DEVICES = 32;
+   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
 int prop_set, num_devices;
 int fd = -1, fallback_fd = -1;
  
@@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)

 if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
vendor_name = vendor_buf;
  
-   const char *drm_dir_name = "/dev/dri";

-   DIR *sysdir = opendir(drm_dir_name);
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  return num_devices;
  
-   if (!sysdir)

-   return -errno;
+   for (int i = 0; i < num_devices; i++) {
+  device = devices[i];
  
-   struct dirent *dent;

-   while ((dent = readdir(sysdir))) {
-  char dev_path[128];
-  const char render_dev_prefix[] = "renderD";
-  size_t prefix_len = sizeof(render_dev_prefix) - 1;
-
-  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
+  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
   continue;
  
-  snprintf(dev_path, sizeof(dev_path), "%s/%s", drm_dir_name, dent->d_name);

-  fd = loader_open_device(dev_path);
+  fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
if (fd < 0) {
   _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
   __func__, dev_path);
@@ -1341,7 +1336,7 @@ droid_open_device(_EGLDisplay *disp)
 }
  
  success:

-   closedir(sysdir);
+   drmFreeDevices(devices, num_devices);
  
 if (fallback_fd < 0 && fd < 0) {

_eglLog(_EGL_WARNING, "Failed to open any DRM device");


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

Re: [Mesa-dev] [PATCH] glsl: Avoid calling get_array_element for scalar constants

[Ian Romanick]

On 08/13/2018 08:57 AM, Danylo Piliaiev wrote:
> Accessing scalar constant as an array in function call or
> initializer list triggered assert in get_array_element.
> Examples:
>func(0[0]);
>vec2 t = { 0[0], 0 };

Do we have tests like this in piglit?  What happens if 0[0] syntax is
used other places?  What do happens in these cases after this change?
Some sort of graceful compile-time error, I hope...

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107550
> 
> Signed-off-by: Danylo Piliaiev 
> ---
>  src/compiler/glsl/ir_constant_expression.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/compiler/glsl/ir_constant_expression.cpp 
> b/src/compiler/glsl/ir_constant_expression.cpp
> index 4a0aff72c6..c9788c7053 100644
> --- a/src/compiler/glsl/ir_constant_expression.cpp
> +++ b/src/compiler/glsl/ir_constant_expression.cpp
> @@ -826,7 +826,7 @@ ir_dereference_array::constant_expression_value(void 
> *mem_ctx,
>   const unsigned component = idx->value.u[0];
>  
>   return new(mem_ctx) ir_constant(array, component);
> -  } else {
> +  } else if (array->type->is_array()) {
>   const unsigned index = idx->value.u[0];
>   return array->get_array_element(index)->clone(mem_ctx, NULL);
>}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/11] glsl: add arithmetic builtin functions for EXT_gpu_shader4

[Ian Romanick]

On 08/07/2018 10:42 PM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/compiler/glsl/builtin_functions.cpp | 48 ++---
>  1 file changed, 35 insertions(+), 13 deletions(-)
> 
> diff --git a/src/compiler/glsl/builtin_functions.cpp 
> b/src/compiler/glsl/builtin_functions.cpp
> index 7119903795f..1370245ff91 100644
> --- a/src/compiler/glsl/builtin_functions.cpp
> +++ b/src/compiler/glsl/builtin_functions.cpp
> @@ -264,20 +264,32 @@ shader_packing_or_es3(const _mesa_glsl_parse_state 
> *state)
>  }
>  
>  static bool
>  shader_packing_or_es3_or_gpu_shader5(const _mesa_glsl_parse_state *state)
>  {
> return state->ARB_shading_language_packing_enable ||
>state->ARB_gpu_shader5_enable ||
>state->is_version(400, 300);
>  }
>  
> +static bool
> +gpu_shader4(const _mesa_glsl_parse_state *state)
> +{
> +   return state->EXT_gpu_shader4_enable;
> +}
> +
> +static bool
> +v130_gpu_shader4(const _mesa_glsl_parse_state *state)

The other things like this use "or" in the name.  Maybe
v130_or_gpu_shader4?  With that changed, this patch is

Reviewed-by: Ian Romanick 

> +{
> +   return state->is_version(130, 300) || state->EXT_gpu_shader4_enable;
> +}
> +
>  static bool
>  gpu_shader5(const _mesa_glsl_parse_state *state)
>  {
> return state->is_version(400, 0) || state->ARB_gpu_shader5_enable;
>  }
>  
>  static bool
>  gpu_shader5_es(const _mesa_glsl_parse_state *state)
>  {
> return state->is_version(400, 320) ||
> @@ -786,20 +798,21 @@ private:
> B1(pow)
> B1(exp)
> B1(log)
> B1(exp2)
> B1(log2)
> BA1(sqrt)
> BA1(inversesqrt)
> BA1(abs)
> BA1(sign)
> BA1(floor)
> +   BA1(truncate)
> BA1(trunc)
> BA1(round)
> BA1(roundEven)
> BA1(ceil)
> BA1(fract)
> BA2(mod)
> BA1(modf)
> BA2(min)
> BA2(max)
> BA2(clamp)
> @@ -1384,23 +1397,23 @@ builtin_builder::create_builtins()
>  #define FIUD_VEC(NAME)\
> add_function(#NAME,\
>  _##NAME(always_available, glsl_type::vec2_type),  \
>  _##NAME(always_available, glsl_type::vec3_type),  \
>  _##NAME(always_available, glsl_type::vec4_type),  \
>\
>  _##NAME(always_available, glsl_type::ivec2_type), \
>  _##NAME(always_available, glsl_type::ivec3_type), \
>  _##NAME(always_available, glsl_type::ivec4_type), \
>\
> -_##NAME(v130, glsl_type::uvec2_type), \
> -_##NAME(v130, glsl_type::uvec3_type), \
> -_##NAME(v130, glsl_type::uvec4_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec2_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec3_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec4_type), \
>  _##NAME(fp64, glsl_type::dvec2_type),  \
>  _##NAME(fp64, glsl_type::dvec3_type),  \
>  _##NAME(fp64, glsl_type::dvec4_type),  \
>  _##NAME(int64, glsl_type::int64_t_type), \
>  _##NAME(int64, glsl_type::i64vec2_type),  \
>  _##NAME(int64, glsl_type::i64vec3_type),  \
>  _##NAME(int64, glsl_type::i64vec4_type),  \
>  _##NAME(int64, glsl_type::uint64_t_type), \
>  _##NAME(int64, glsl_type::u64vec2_type),  \
>  _##NAME(int64, glsl_type::u64vec3_type),  \
> @@ -1423,23 +1436,23 @@ builtin_builder::create_builtins()
>  #define FIUBD_VEC(NAME)   \
> add_function(#NAME,\
>  _##NAME(always_available, glsl_type::vec2_type),  \
>  _##NAME(always_available, glsl_type::vec3_type),  \
>  _##NAME(always_available, glsl_type::vec4_type),  \
>\
>  _##NAME(always_available, glsl_type::ivec2_type), \
>  _##NAME(always_available, glsl_type::ivec3_type), \
>  _##NAME(always_available, glsl_type::ivec4_type), \
>\
> -_##NAME(v130, glsl_type::uvec2_type), \
> -_##NAME(v130, glsl_type::uvec3_type), \
> -_##NAME(v130, glsl_type::uvec4_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec2_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec3_type), \
> +_##NAME(v130_gpu_shader4, glsl_type::uvec4_type), \
>\
>  _##NAME(always_available, glsl

Re: [Mesa-dev] [PATCH 01/11] mesa: fix glGet for EXT_gpu_shader4

[Ian Romanick]

Patches 1 through 4, 6, 7, and 9 are:

Reviewed-by: Ian Romanick 

I sent comments on 5, 8, and 10.  I don't have any opinion about 11. :)

On 08/07/2018 10:41 PM, Marek Olšák wrote:
> From: Marek Olšák 
> 
> ---
>  src/mapi/glapi/gen/EXT_gpu_shader4.xml | 4 
>  src/mesa/main/get.c| 3 ++-
>  src/mesa/main/get_hash_params.py   | 4 ++--
>  3 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/src/mapi/glapi/gen/EXT_gpu_shader4.xml 
> b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> index b4120b9c192..55437c0de2c 100644
> --- a/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> +++ b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> @@ -25,24 +25,20 @@
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> -
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index f870b217db5..f31d7f838b0 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -308,23 +308,24 @@ static const int extra_flush_current[] = {
> EXTRA_FLUSH_CURRENT,
> EXTRA_END
>  };
>  
>  static const int extra_EXT_texture_integer_and_new_buffers[] = {
> EXT(EXT_texture_integer),
> EXTRA_NEW_BUFFERS,
> EXTRA_END
>  };
>  
> -static const int extra_GLSL_130_es3[] = {
> +static const int extra_GLSL_130_es3_gpushader4[] = {
> EXTRA_GLSL_130,
> EXTRA_API_ES3,
> +   EXT(EXT_gpu_shader4),
> EXTRA_END
>  };
>  
>  static const int extra_texture_buffer_object[] = {
> EXT(ARB_texture_buffer_object),
> EXTRA_END
>  };
>  
>  static const int extra_ARB_transform_feedback2_api_es3[] = {
> EXT(ARB_transform_feedback2),
> diff --git a/src/mesa/main/get_hash_params.py 
> b/src/mesa/main/get_hash_params.py
> index 5c672a33123..f11e6778214 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -429,22 +429,22 @@ descriptor=[
>  
>  # GL_ARB_vertex_shader
>[ "MAX_VERTEX_UNIFORM_COMPONENTS_ARB", 
> "CONTEXT_INT(Const.Program[MESA_SHADER_VERTEX].MaxUniformComponents), 
> extra_ARB_vertex_shader" ],
>[ "MAX_VARYING_FLOATS_ARB", "LOC_CUSTOM, TYPE_INT, 0, 
> extra_ARB_vertex_shader" ],
>  
>  # GL_EXT_framebuffer_blit
>  # NOTE: GL_DRAW_FRAMEBUFFER_BINDING_EXT == GL_FRAMEBUFFER_BINDING_EXT
>[ "READ_FRAMEBUFFER_BINDING_EXT", "LOC_CUSTOM, TYPE_INT, 0, NO_EXTRA" ],
>  
>  # GL_EXT_gpu_shader4 / GLSL 1.30
> -  [ "MIN_PROGRAM_TEXEL_OFFSET", "CONTEXT_INT(Const.MinProgramTexelOffset), 
> extra_GLSL_130_es3" ],
> -  [ "MAX_PROGRAM_TEXEL_OFFSET", "CONTEXT_INT(Const.MaxProgramTexelOffset), 
> extra_GLSL_130_es3" ],
> +  [ "MIN_PROGRAM_TEXEL_OFFSET", "CONTEXT_INT(Const.MinProgramTexelOffset), 
> extra_GLSL_130_es3_gpushader4" ],
> +  [ "MAX_PROGRAM_TEXEL_OFFSET", "CONTEXT_INT(Const.MaxProgramTexelOffset), 
> extra_GLSL_130_es3_gpushader4" ],
>  
>  # GL_EXT_pixel_buffer_object
>[ "PIXEL_PACK_BUFFER_BINDING_EXT", "LOC_CUSTOM, TYPE_INT, 0, 
> extra_EXT_pixel_buffer_object" ],
>[ "PIXEL_UNPACK_BUFFER_BINDING_EXT", "LOC_CUSTOM, TYPE_INT, 0, 
> extra_EXT_pixel_buffer_object" ],
>  
># GL_EXT_texture_array
>[ "TEXTURE_BINDING_2D_ARRAY", "LOC_CUSTOM, TYPE_INT, 
> TEXTURE_2D_ARRAY_INDEX, extra_EXT_texture_array_es3" ],
>[ "MAX_ARRAY_TEXTURE_LAYERS_EXT", 
> "CONTEXT_INT(Const.MaxArrayTextureLayers), extra_EXT_texture_array_es3" ],
>  
>  # GL_EXT_transform_feedback
> 

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

Re: [Mesa-dev] [PATCH 05/11] glsl: enable types for EXT_gpu_shader4

[Ian Romanick]

On 08/07/2018 10:42 PM, Marek Olšák wrote:
> From: Chris Forbes 
> 
> ---
>  src/compiler/glsl/builtin_types.cpp | 32 ++
>  src/compiler/glsl/glsl_lexer.ll | 50 ++---
>  2 files changed, 57 insertions(+), 25 deletions(-)
> 
> diff --git a/src/compiler/glsl/builtin_types.cpp 
> b/src/compiler/glsl/builtin_types.cpp
> index 7a01cb48bc8..2e141447252 100644
> --- a/src/compiler/glsl/builtin_types.cpp
> +++ b/src/compiler/glsl/builtin_types.cpp
> @@ -317,20 +317,52 @@ _mesa_glsl_initialize_types(struct 
> _mesa_glsl_parse_state *state)
>add_type(symbols, glsl_type::sampler2DMSArray_type);
>add_type(symbols, glsl_type::isampler2DMSArray_type);
>add_type(symbols, glsl_type::usampler2DMSArray_type);
> }
>  
> if (state->ARB_texture_rectangle_enable) {
>add_type(symbols, glsl_type::sampler2DRect_type);
>add_type(symbols, glsl_type::sampler2DRectShadow_type);
> }
>  
> +   if (state->EXT_gpu_shader4_enable) {
> +  add_type(symbols, glsl_type::uint_type);
> +  add_type(symbols, glsl_type::uvec2_type);
> +  add_type(symbols, glsl_type::uvec3_type);
> +  add_type(symbols, glsl_type::uvec4_type);
> +
> +  add_type(symbols, glsl_type::sampler1DArray_type);
> +  add_type(symbols, glsl_type::sampler2DArray_type);
> +  add_type(symbols, glsl_type::sampler1DArrayShadow_type);
> +  add_type(symbols, glsl_type::sampler2DArrayShadow_type);
> +  add_type(symbols, glsl_type::samplerCubeShadow_type);
> +  add_type(symbols, glsl_type::samplerBuffer_type);
> +
> +  add_type(symbols, glsl_type::isampler1D_type);
> +  add_type(symbols, glsl_type::isampler2D_type);
> +  add_type(symbols, glsl_type::isampler3D_type);
> +  add_type(symbols, glsl_type::isamplerCube_type);
> +  add_type(symbols, glsl_type::isampler2DRect_type);
> +  add_type(symbols, glsl_type::isampler1DArray_type);
> +  add_type(symbols, glsl_type::isampler2DArray_type);
> +  add_type(symbols, glsl_type::isamplerBuffer_type);
> +
> +  add_type(symbols, glsl_type::usampler1D_type);
> +  add_type(symbols, glsl_type::usampler2D_type);
> +  add_type(symbols, glsl_type::usampler3D_type);
> +  add_type(symbols, glsl_type::usamplerCube_type);
> +  add_type(symbols, glsl_type::usampler2DRect_type);
> +  add_type(symbols, glsl_type::usampler1DArray_type);
> +  add_type(symbols, glsl_type::usampler2DArray_type);
> +  add_type(symbols, glsl_type::usamplerBuffer_type);
> +   }
> +
> if (state->EXT_texture_array_enable) {
>add_type(symbols, glsl_type::sampler1DArray_type);
>add_type(symbols, glsl_type::sampler2DArray_type);
>add_type(symbols, glsl_type::sampler1DArrayShadow_type);
>add_type(symbols, glsl_type::sampler2DArrayShadow_type);
> }
>  
> if (state->OES_EGL_image_external_enable ||
> state->OES_EGL_image_external_essl3_enable) {
>add_type(symbols, glsl_type::samplerExternalOES_type);
> diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
> index 65c5b414a2d..67c33d6f1c9 100644
> --- a/src/compiler/glsl/glsl_lexer.ll
> +++ b/src/compiler/glsl/glsl_lexer.ll
> @@ -347,23 +347,23 @@ for return FOR;
>  if   return IF;
>  discard  return DISCARD;
>  return   return RETURN;
>  
>  bvec2{ yylval->type = glsl_type::bvec2_type; return 
> BASIC_TYPE_TOK; }
>  bvec3{ yylval->type = glsl_type::bvec3_type; return 
> BASIC_TYPE_TOK; }
>  bvec4{ yylval->type = glsl_type::bvec4_type; return 
> BASIC_TYPE_TOK; }
>  ivec2{ yylval->type = glsl_type::ivec2_type; return 
> BASIC_TYPE_TOK; }
>  ivec3{ yylval->type = glsl_type::ivec3_type; return 
> BASIC_TYPE_TOK; }
>  ivec4{ yylval->type = glsl_type::ivec4_type; return 
> BASIC_TYPE_TOK; }
> -uvec2TYPE(130, 300, 130, 300, glsl_type::uvec2_type);
> -uvec3TYPE(130, 300, 130, 300, glsl_type::uvec3_type);
> -uvec4TYPE(130, 300, 130, 300, glsl_type::uvec4_type);
> +uvec2TYPE_WITH_ALT(130, 300, 130, 300, 
> yyextra->EXT_gpu_shader4_enable, glsl_type::uvec2_type);
> +uvec3TYPE_WITH_ALT(130, 300, 130, 300, 
> yyextra->EXT_gpu_shader4_enable, glsl_type::uvec3_type);
> +uvec4TYPE_WITH_ALT(130, 300, 130, 300, 
> yyextra->EXT_gpu_shader4_enable, glsl_type::uvec4_type);
>  vec2 { yylval->type = glsl_type::vec2_type; return BASIC_TYPE_TOK; }
>  vec3 { yylval->type = glsl_type::vec3_type; return BASIC_TYPE_TOK; }
>  vec4 { yylval->type = glsl_type::vec4_type; return BASIC_TYPE_TOK; }
>  mat2 { yylval->type = glsl_type::mat2_type; return BASIC_TYPE_TOK; }
>  mat3 { yylval->type = glsl_type::mat3_type; return BASIC_TYPE_TOK; }
>  mat4 { yylval->type = glsl_type::mat4_type; return BASIC_TYPE_TOK; }
>  mat

[Mesa-dev] [ANNOUNCE] mesa 18.1.6

[Dylan Baker]

Hi list,

I'm announcing the general availability of the 18.1.6 release. This is an 18.1
bugfix release. There are two more 18.1 bug fix releases planned at this time.

We've had another busy cycle the last two weeks, there have been roughly 3 dozen
fixes in this release. In brief:

- autotools fixes for libglvnd, libgl naming, and pkgconfig
- meson fixed its handling of stale symlinks wrt megadrivers
- windows relaged fixes
- some bug fixes for clover
- plenty of egl, wayland, glx, and dri3 fixes
- a couple of nir fixes
- and on the driver side, radv, intel, vc4, etnaviv, swr, r600, amd, and
  nouveau all had a few fixes

Dylan

git tag: mesa-18.1.6

https://mesa.freedesktop.org/archive/mesa-18.1.6.tar.gz
MD5:  f54b24108f3554ffae84a80f02dfc732  mesa-18.1.6.tar.gz
SHA1: 107427ae87510114a94e4a045f3334e4efaa56a3  mesa-18.1.6.tar.gz
SHA256: 580e03328ffefe1fd43b19ab7669f20d931601a1c0a4c0f8b9c65d6e81a06df3  
mesa-18.1.6.tar.gz
SHA512: 
21ab4a7fc245903fcddfaa4febd1ae5c5cfdb6bd98a0580fe31b58865483505609d46769c55234220678fc4bb1d75c96e7cbef7c522e6de6d89020e01d3ca177
  mesa-18.1.6.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.6.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-18.1.6.tar.xz
MD5:  f798814c0b93ca3c1cf395bb936db3e0  mesa-18.1.6.tar.xz
SHA1: 8d4daf725f20404f980b981c9693b58756ba6c48  mesa-18.1.6.tar.xz
SHA256: bb7ce759069801804fcfb8152da3457f76cd7b4e0096e4870ff5adcb5c894289  
mesa-18.1.6.tar.xz
SHA512: 
2966210800215f5ced2720691063a8519b51ebeab9fb1e99bde4b1bd7ccc719d6395a1c29f25c88efe62d1592cf14ceafc163aca349490b1f8cee81070d46fcc
  mesa-18.1.6.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-18.1.6.tar.xz.sig



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

[Mesa-dev] [PATCH 6/5] egl/android: continue to next device if dri2_create_screen fails

[Emil Velikov]

From: Emil Velikov 

Unlike the other platforms, here we aim do guess if the device that we
somewhat arbitrarily picked, is supported or not.

It seems a bit fiddly, but considering EGL_EXT_explicit_device and
EGL_MESA_query_renderer are MIA, this is the best we can do for the
moment.

With those (proposed) extensions userspace will be able to create a
separate EGL display for each device, query device details and make the
conscious decision which one to use.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 29 -
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 50dd7a5e1b4..cac59847b89 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1295,6 +1295,25 @@ droid_open_device(_EGLDisplay *disp)
  continue;
   }
   /* Found a device */
+
+  /* Check that the device is supported, by attempting to:
+   * - load the dri module
+   * - and, create a screen
+   */
+  if (!droid_load_driver(disp)) {
+ _eglLog(_EGL_WARNING, "DRI2: failed to load driver");
+ close(fd);
+ fd = -1;
+ continue;
+  }
+
+  if (!dri2_create_screen(disp)) {
+ _eglLog(_EGL_WARNING, "DRI2: failed to create screen");
+ close(fd);
+ fd = -1;
+ continue;
+  }
+
   break;
}
drmFreeDevices(devices, num_devices);
@@ -1346,16 +1365,6 @@ dri2_initialize_android(_EGLDriver *drv, _EGLDisplay 
*disp)
   goto cleanup;
}
 
-   if (!droid_load_driver(disp)) {
-  err = "DRI2: failed to load driver";
-  goto cleanup;
-   }
-
-   if (!dri2_create_screen(disp)) {
-  err = "DRI2: failed to create screen";
-  goto cleanup;
-   }
-
if (!dri2_setup_extensions(disp)) {
   err = "DRI2: failed to setup extensions";
   goto cleanup;
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Emil Velikov]

On 13 August 2018 at 16:37, Frank Binns  wrote:
> Hi Emil,
>
> Emil Velikov  writes:
>
>> From: Emil Velikov 
>>
>> Replace the manual handling of /dev/dri in famour of the drmDevice API.
>
> s/famour/favour/
>
>> The latter provides a consistent way of enumerating the devices,
>> providing device details as needed.
>>
>> Cc: Robert Foss 
>> Cc: Tomasz Figa 
>> Signed-off-by: Emil Velikov 
>> ---
>> If using VGEM the following patch is needed [1]. It's been on the list
>> for ages - will double-check and commmit it to drm-misc.
>>
>> [1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
>> ---
>>  src/egl/drivers/dri2/platform_android.c | 23 +--
>>  1 file changed, 9 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/egl/drivers/dri2/platform_android.c 
>> b/src/egl/drivers/dri2/platform_android.c
>> index cc16fd8118f..685851acfc2 100644
>> --- a/src/egl/drivers/dri2/platform_android.c
>> +++ b/src/egl/drivers/dri2/platform_android.c
>> @@ -1290,6 +1290,7 @@ static int
>>  droid_open_device(_EGLDisplay *disp)
>>  {
>> const int MAX_DRM_DEVICES = 32;
>> +   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
>> int prop_set, num_devices;
>> int fd = -1, fallback_fd = -1;
>>
>> @@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)
>> if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
>>vendor_name = vendor_buf;
>>
>> -   const char *drm_dir_name = "/dev/dri";
>> -   DIR *sysdir = opendir(drm_dir_name);
>> +   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
>
> It would be more robust to use ARRAY_SIZE here instead of
> MAX_DRM_DEVICES.
>
Thanks Frank - fixed both locally.

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

Re: [Mesa-dev] [PATCH 10/11] mesa: expose EXT_texture_buffer_object

[Ian Romanick]

On 08/10/2018 08:14 PM, Marek Olšák wrote:
> On Fri, Aug 10, 2018 at 9:04 PM, Ian Romanick  wrote:
>> On 08/07/2018 10:42 PM, Marek Olšák wrote:
>>> From: Marek Olšák 
>>>
>>> This is needed for exposing the samplerBuffer functions under
>>> EXT_gpu_shader4.
>>>
>>> glTexBufferEXT is defined in glapi, but "make check" fails.
>>> What am I doing wrong?
>>> ---
>>>  docs/relnotes/18.3.0.html   | 1 +
>>>  src/mesa/main/extensions_table.h| 1 +
>>>  src/mesa/main/tests/dispatch_sanity.cpp | 1 +
>>>  3 files changed, 3 insertions(+)
>>>
>>> diff --git a/docs/relnotes/18.3.0.html b/docs/relnotes/18.3.0.html
>>> index 786145ad8da..6274c9147a1 100644
>>> --- a/docs/relnotes/18.3.0.html
>>> +++ b/docs/relnotes/18.3.0.html
>>> @@ -45,20 +45,21 @@ TBD.
>>>
>>>
>>>  New features
>>>
>>>  
>>>  Note: some of the new features are only available with certain drivers.
>>>  
>>>
>>>  
>>>  GL_AMD_framebuffer_multisample_advanced on radeonsi.
>>> +GL_EXT_texture_buffer_object on i965, nv50, nvc0, r600, radeonsi.
>>>  
>>>
>>>  Bug fixes
>>>
>>>  
>>>  TBD
>>>  
>>>
>>>  Changes
>>>
>>> diff --git a/src/mesa/main/extensions_table.h 
>>> b/src/mesa/main/extensions_table.h
>>> index bdba49d5380..5eb5c3278e9 100644
>>> --- a/src/mesa/main/extensions_table.h
>>> +++ b/src/mesa/main/extensions_table.h
>>> @@ -263,20 +263,21 @@ EXT(EXT_shadow_funcs, 
>>> ARB_shadow
>>>  EXT(EXT_stencil_two_side, EXT_stencil_two_side 
>>>   , GLL,  x ,  x ,  x , 2001)
>>>  EXT(EXT_stencil_wrap, dummy_true   
>>>   , GLL,  x ,  x ,  x , 2002)
>>>  EXT(EXT_subtexture  , dummy_true   
>>>   , GLL,  x ,  x ,  x , 1995)
>>>  EXT(EXT_tessellation_point_size , ARB_tessellation_shader  
>>>   ,  x ,  x ,  x ,  31, 2013)
>>>  EXT(EXT_tessellation_shader , ARB_tessellation_shader  
>>>   ,  x ,  x ,  x ,  31, 2013)
>>>  EXT(EXT_texture , dummy_true   
>>>   , GLL,  x ,  x ,  x , 1996)
>>>  EXT(EXT_texture3D   , dummy_true   
>>>   , GLL,  x ,  x ,  x , 1996)
>>>  EXT(EXT_texture_array   , EXT_texture_array
>>>   , GLL, GLC,  x ,  x , 2006)
>>>  EXT(EXT_texture_border_clamp, ARB_texture_border_clamp 
>>>   ,  x ,  x ,  x , ES2, 2014)
>>>  EXT(EXT_texture_buffer  , OES_texture_buffer   
>>>   ,  x ,  x ,  x ,  31, 2014)
>>> +EXT(EXT_texture_buffer_object   , ARB_texture_buffer_object
>>>   , GLL, GLC,  x ,  x , 2007)
>>
>> I doubt we want to actually expose this extension or GL_EXT_gpu_shader4
>> in core profile.  Do you know of any applications on any platform that
>> need this?  If there are any, I want to shame them. :)
> 
> What's the issue with the core profile?
> 
> I'm only adding what our closed driver supports. EXT_gpu_shader4
> wouldn't be complete without it.

Which I also think we should also remove from core profile.  The problem
is EXT_gpu_shader4 depends on GLSL 1.20 which does not exist in core
profile.  Both GLSL 1.20 and EXT_gpu_shader4 depend on a bunch of legacy
GL state that doesn't exist in core.  It's an ill-defined mess.

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

[Mesa-dev] [AppVeyor] mesa 18.1 #8585 completed

[AppVeyor]

Build mesa 8585 completed



Commit 5343019cfa by Dylan Baker on 8/13/2018 3:36 PM:

docs: Add release notes for 18.1.6


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 3/4] anv: Use central api generation scripts.

[Dylan Baker]

Quoting Bas Nieuwenhuizen (2018-08-13 09:25:01)
> On Mon, Aug 13, 2018 at 5:54 PM, Dylan Baker  wrote:
> > Quoting Emil Velikov (2018-08-13 03:38:13)
> >> On 10 August 2018 at 00:57, Dylan Baker  wrote:
> >> > Quoting Chad Versace (2018-08-09 10:37:33)
> >> >> On Tue 07 Aug 2018, Dylan Baker wrote:
> >> >> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
> >> >> > >
> >> >> > >  anv_extensions_c = custom_target(
> >> >> > > @@ -36,10 +37,11 @@ anv_extensions_c = custom_target(
> >> >> > >input : ['anv_extensions_gen.py', vk_api_xml],
> >> >> > >output : 'anv_extensions.c',
> >> >> > >command : [
> >> >> > > +   'env', 'PYTHONPATH=@0@'.format(join_paths(meson.source_root(), 
> >> >> > > 'src/vulkan/util/')),
> >> >> >
> >> >> > This is really gross, you're adding a dependency on a unix console 
> >> >> > command. I
> >> >> > know that anv is only built on Unix-like oses, but this will 
> >> >> > eventually end up
> >> >> > being used in some code that needs to run on Windows (or mac, does 
> >> >> > mac have
> >> >> > env?).
> >> >> >
> >> >> > I know that some people will object, but IMHO a better solution than 
> >> >> > mucking
> >> >> > with the python path (either through sys.path or through PYTHONPATH, 
> >> >> > is to
> >> >> > put all of the generators in a src/generators directory and be done 
> >> >> > with it.
> >> >> > Sure the intel specific bits (for example) aren't in the src/intel 
> >> >> > folder,
> >> >> > that's a small price to avoid having to call env just to run a python 
> >> >> > script.
> >> >>
> >> >> Dylan, I think we should avoid introducing complexity in the build
> >> >> system for the benefit of operating systems not supported by the driver.
> >> >> That feels like a serious premature optimazation, to me.  Anvil's usage
> >> >> of ioctls is highly specific to Linux/Unix, will not work on MacOS, and
> >> >> definitely does not work on Windows.
> >> >
> >> > I agree completely. I think where we disagree is on whether mucking with
> >> > PYTHONPATH and using env is more complex or putting our generators in a 
> >> > single
> >> > directory is more complex. I think using env is extremely gross and 
> >> > complex, I
> >> > think mucking with PYTHONPATH is extremely gross and complex, and I 
> >> > think having
> >> > to reference a file from another directory is a *lot* less gross and 
> >> > *much* less
> >> > complex.
> >> >
> >> Can we reuse the NIR approach seen here [1] [2]?
> >> Moving files around just to appease python feels wrong on many levels :-(
> >>
> >> Thanks
> >> Emil
> >>
> >> [1] 
> >> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/compiler/meson.build#L120
> >> [2] 
> >> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/freedreno/meson.build#L21
> >
> > I would begrudgingly accept that.
> >
> > I really don't understand why this is such a big deal. Imagine for a moment 
> > that
> > a there was a driver for "Magical Unicorn" hardware existed. Imagine it had 
> > some
> > very odd instructions and the developers of the Magic Unicorn driver wanted 
> > some
> > special NIR passes for their hardware. Now lets imagine that they insisted 
> > that
> > those passes must live in src/unicorn, but should be linked into libnir. No 
> > one
> > would accept that, they would be told either to keep the passes in their 
> > backend
> > or to move them into src/compiler/nir. I believe this is an analogous 
> > situation.
> > We want to share code, so we're putting it in src/util/vulkan, but then 
> > instead
> > of calling a generator out of src/util/vulkan in src/intel and src/amd (we
> > already call python scripts from different directories all over the build
> > system), we do some elaborate environment variable manipulation which can 
> > have
> > unforseen side effects (like that google sets PYTHONPATH in their distro) 
> > and
> > have to wrap our actual callable with `env`, just so that we could put the
> > callable in src/intel and src/amd instead of having a callable in
> > src/util/vulkan. Does no one else think that this is a bit crazy?
> 
> For the main functions of the generators scripts I agree and can merge
> them a bit further. However the one where I think moving it is
> somewhat crazy is the {radv,anv}_extensions.py, in particular the list
> of supported extensions and the (driver-specific) conditions in which
> they should be enabled. That seems way driver-specific to put in a
> shared directory.

Okay, that's a fair point.

What about having a file that is a list of extensions that could live in
src/$vendor, which the script takes as an argument?

Dylan


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

Re: [Mesa-dev] [PATCH 3/4] anv: Use central api generation scripts.

[Emil Velikov]

On 13 August 2018 at 17:25, Bas Nieuwenhuizen  wrote:
> On Mon, Aug 13, 2018 at 5:54 PM, Dylan Baker  wrote:
>> Quoting Emil Velikov (2018-08-13 03:38:13)
>>> On 10 August 2018 at 00:57, Dylan Baker  wrote:
>>> > Quoting Chad Versace (2018-08-09 10:37:33)
>>> >> On Tue 07 Aug 2018, Dylan Baker wrote:
>>> >> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
>>> >> > >
>>> >> > >  anv_extensions_c = custom_target(
>>> >> > > @@ -36,10 +37,11 @@ anv_extensions_c = custom_target(
>>> >> > >input : ['anv_extensions_gen.py', vk_api_xml],
>>> >> > >output : 'anv_extensions.c',
>>> >> > >command : [
>>> >> > > +   'env', 'PYTHONPATH=@0@'.format(join_paths(meson.source_root(), 
>>> >> > > 'src/vulkan/util/')),
>>> >> >
>>> >> > This is really gross, you're adding a dependency on a unix console 
>>> >> > command. I
>>> >> > know that anv is only built on Unix-like oses, but this will 
>>> >> > eventually end up
>>> >> > being used in some code that needs to run on Windows (or mac, does mac 
>>> >> > have
>>> >> > env?).
>>> >> >
>>> >> > I know that some people will object, but IMHO a better solution than 
>>> >> > mucking
>>> >> > with the python path (either through sys.path or through PYTHONPATH, 
>>> >> > is to
>>> >> > put all of the generators in a src/generators directory and be done 
>>> >> > with it.
>>> >> > Sure the intel specific bits (for example) aren't in the src/intel 
>>> >> > folder,
>>> >> > that's a small price to avoid having to call env just to run a python 
>>> >> > script.
>>> >>
>>> >> Dylan, I think we should avoid introducing complexity in the build
>>> >> system for the benefit of operating systems not supported by the driver.
>>> >> That feels like a serious premature optimazation, to me.  Anvil's usage
>>> >> of ioctls is highly specific to Linux/Unix, will not work on MacOS, and
>>> >> definitely does not work on Windows.
>>> >
>>> > I agree completely. I think where we disagree is on whether mucking with
>>> > PYTHONPATH and using env is more complex or putting our generators in a 
>>> > single
>>> > directory is more complex. I think using env is extremely gross and 
>>> > complex, I
>>> > think mucking with PYTHONPATH is extremely gross and complex, and I think 
>>> > having
>>> > to reference a file from another directory is a *lot* less gross and 
>>> > *much* less
>>> > complex.
>>> >
>>> Can we reuse the NIR approach seen here [1] [2]?
>>> Moving files around just to appease python feels wrong on many levels :-(
>>>
>>> Thanks
>>> Emil
>>>
>>> [1] 
>>> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/compiler/meson.build#L120
>>> [2] 
>>> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/freedreno/meson.build#L21
>>
>> I would begrudgingly accept that.
>>
>> I really don't understand why this is such a big deal. Imagine for a moment 
>> that
>> a there was a driver for "Magical Unicorn" hardware existed. Imagine it had 
>> some
>> very odd instructions and the developers of the Magic Unicorn driver wanted 
>> some
>> special NIR passes for their hardware. Now lets imagine that they insisted 
>> that
>> those passes must live in src/unicorn, but should be linked into libnir. No 
>> one
>> would accept that, they would be told either to keep the passes in their 
>> backend
>> or to move them into src/compiler/nir. I believe this is an analogous 
>> situation.
>> We want to share code, so we're putting it in src/util/vulkan, but then 
>> instead
>> of calling a generator out of src/util/vulkan in src/intel and src/amd (we
>> already call python scripts from different directories all over the build
>> system), we do some elaborate environment variable manipulation which can 
>> have
>> unforseen side effects (like that google sets PYTHONPATH in their distro) and
>> have to wrap our actual callable with `env`, just so that we could put the
>> callable in src/intel and src/amd instead of having a callable in
>> src/util/vulkan. Does no one else think that this is a bit crazy?
>
> For the main functions of the generators scripts I agree and can merge
> them a bit further. However the one where I think moving it is
> somewhat crazy is the {radv,anv}_extensions.py, in particular the list
> of supported extensions and the (driver-specific) conditions in which
> they should be enabled. That seems way driver-specific to put in a
> shared directory.
>
Precisely what I was thinking. Thanks for saying it so much clearer than me Bas!

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

Re: [Mesa-dev] [PATCH 3/4] anv: Use central api generation scripts.

[Bas Nieuwenhuizen]

On Mon, Aug 13, 2018 at 5:54 PM, Dylan Baker  wrote:
> Quoting Emil Velikov (2018-08-13 03:38:13)
>> On 10 August 2018 at 00:57, Dylan Baker  wrote:
>> > Quoting Chad Versace (2018-08-09 10:37:33)
>> >> On Tue 07 Aug 2018, Dylan Baker wrote:
>> >> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
>> >> > >
>> >> > >  anv_extensions_c = custom_target(
>> >> > > @@ -36,10 +37,11 @@ anv_extensions_c = custom_target(
>> >> > >input : ['anv_extensions_gen.py', vk_api_xml],
>> >> > >output : 'anv_extensions.c',
>> >> > >command : [
>> >> > > +   'env', 'PYTHONPATH=@0@'.format(join_paths(meson.source_root(), 
>> >> > > 'src/vulkan/util/')),
>> >> >
>> >> > This is really gross, you're adding a dependency on a unix console 
>> >> > command. I
>> >> > know that anv is only built on Unix-like oses, but this will eventually 
>> >> > end up
>> >> > being used in some code that needs to run on Windows (or mac, does mac 
>> >> > have
>> >> > env?).
>> >> >
>> >> > I know that some people will object, but IMHO a better solution than 
>> >> > mucking
>> >> > with the python path (either through sys.path or through PYTHONPATH, is 
>> >> > to
>> >> > put all of the generators in a src/generators directory and be done 
>> >> > with it.
>> >> > Sure the intel specific bits (for example) aren't in the src/intel 
>> >> > folder,
>> >> > that's a small price to avoid having to call env just to run a python 
>> >> > script.
>> >>
>> >> Dylan, I think we should avoid introducing complexity in the build
>> >> system for the benefit of operating systems not supported by the driver.
>> >> That feels like a serious premature optimazation, to me.  Anvil's usage
>> >> of ioctls is highly specific to Linux/Unix, will not work on MacOS, and
>> >> definitely does not work on Windows.
>> >
>> > I agree completely. I think where we disagree is on whether mucking with
>> > PYTHONPATH and using env is more complex or putting our generators in a 
>> > single
>> > directory is more complex. I think using env is extremely gross and 
>> > complex, I
>> > think mucking with PYTHONPATH is extremely gross and complex, and I think 
>> > having
>> > to reference a file from another directory is a *lot* less gross and 
>> > *much* less
>> > complex.
>> >
>> Can we reuse the NIR approach seen here [1] [2]?
>> Moving files around just to appease python feels wrong on many levels :-(
>>
>> Thanks
>> Emil
>>
>> [1] 
>> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/compiler/meson.build#L120
>> [2] 
>> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/freedreno/meson.build#L21
>
> I would begrudgingly accept that.
>
> I really don't understand why this is such a big deal. Imagine for a moment 
> that
> a there was a driver for "Magical Unicorn" hardware existed. Imagine it had 
> some
> very odd instructions and the developers of the Magic Unicorn driver wanted 
> some
> special NIR passes for their hardware. Now lets imagine that they insisted 
> that
> those passes must live in src/unicorn, but should be linked into libnir. No 
> one
> would accept that, they would be told either to keep the passes in their 
> backend
> or to move them into src/compiler/nir. I believe this is an analogous 
> situation.
> We want to share code, so we're putting it in src/util/vulkan, but then 
> instead
> of calling a generator out of src/util/vulkan in src/intel and src/amd (we
> already call python scripts from different directories all over the build
> system), we do some elaborate environment variable manipulation which can have
> unforseen side effects (like that google sets PYTHONPATH in their distro) and
> have to wrap our actual callable with `env`, just so that we could put the
> callable in src/intel and src/amd instead of having a callable in
> src/util/vulkan. Does no one else think that this is a bit crazy?

For the main functions of the generators scripts I agree and can merge
them a bit further. However the one where I think moving it is
somewhat crazy is the {radv,anv}_extensions.py, in particular the list
of supported extensions and the (driver-specific) conditions in which
they should be enabled. That seems way driver-specific to put in a
shared directory.

>
> Dylan
>
> ___
> 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] mesa/glspirv: fix compilation with MSVC

[Roland Scheidegger]

Am 13.08.2018 um 16:50 schrieb Alejandro Piñeiro:
> From AppVeyor #8582, it seems that MSVC doesn't like uint, so this
> patch replaces it with unsigned.

Reviewed-by: Roland Scheidegger 


> ---
> 
> Note that Im not sure if this is the usual solution. As far as I see,
> uint is used on other source files. Having said so, just replacing for
> unsigned seems the easier way to fix this.
> 
>  src/mesa/main/glspirv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index 4fc80b72181..1c5b7dd17f3 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -188,7 +188,7 @@ nir_compute_double_inputs(nir_shader *shader,
>  {
> nir_foreach_variable(var, &shader->inputs) {
>if (glsl_type_is_dual_slot(glsl_without_array(var->type))) {
> - for (uint i = 0; i < glsl_count_attribute_slots(var->type, true); 
> i++) {
> + for (unsigned i = 0; i < glsl_count_attribute_slots(var->type, 
> true); i++) {
>  uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
>  shader->info.vs.double_inputs |= bitfield;
>   }
> 

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

Re: [Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Tomasz Figa]

On Tue, Aug 14, 2018 at 12:47 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:21, Tomasz Figa  wrote:
> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> > wrote:
> >>
> >> From: Emil Velikov 
> >>
> >> The name string is guaranteed to be NULL terminated. Drop the explicit
> >> length check that comes with strncmp().
> >
> > Is there anything wrong with that length check? I feel like it's a
> > good practice to keep it anyway.
> >
> Consider the a long DRM driver name, that goes over PROPERTY_VALUE_MAX.
> One could replace it with min(PROP.., version::name_len), although it
> does seem over pedantic.
>
> I'm yet to see a single instance that does strncmp for the name.

Fair enough. Sorry for the noise.

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

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

On Tue, Aug 14, 2018 at 1:09 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:43, Tomasz Figa  wrote:
> > On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  
> > wrote:
> >>
> >> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> >> > Hi Emil,
> >> >
> >> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> >> > wrote:
> >> >>
> >> >> From: Emil Velikov 
> >> >>
> >> >> The function name is misleading - it effectively checks if
> >> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
> >> >> error - a close to impossible scenario.
> >> >
> >> > How about a DRI node which doesn't have a driver in Mesa?
> >> >
> >> Can you elaborate a bit - are you thinking of any of the following or
> >> something else:
> >>  - no support for vendor X
> >>  - supported vendor, missing vendor/device pci id for device X
> >>  - supported vendor, built w/o it
> >>
> >> All these are fairly different cases, with somewhat different solution
> >> for each one.
> >
> > Let's say "no support for vendor X", but supported vendor Y GPU next
> > to it. We want this code to skip vendor X DRI node and choose vendor Y
> > DRI node.
> >
> >>
> >> Fwiw the function loader_get_driver_for_fd does:
> >>  - gets the vendor/device pci id and maps that to a driver_name
> >>  - if device not a pci device (or query fails) - fallback to the name
> >> as returned in drmGetVersion
> >
> > Good catch. Looks like I misunderstood what it does when reviewing
> > Rob's series and existing code doesn't work as I expected. I think it
> > would just error out in the case above, right?
> >
> Determining if a device is "supported" is fairly subtle:
> For example, even if you open the foo_dri.so the driver can fail due
> to old kernel module, LLVM version, etc.
> One solution is to continue loading up-to dri2_create_screen() - if it
> fails fall-back to the next device.
>
> Any objections if I do that as follow-up patch, if you agree of course?

Our downstream patch [1] actually loaded until
dri2_load_driver(_dri3)() in probe, but if you think
dri2_create_screen() could make more sense, I'm okay with it. Thanks.

[1] 
https://chromium-review.googlesource.com/c/chromiumos/third_party/mesa/+/558138

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

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Emil Velikov]

On 13 August 2018 at 16:43, Tomasz Figa  wrote:
> On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  
> wrote:
>>
>> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
>> > Hi Emil,
>> >
>> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
>> > wrote:
>> >>
>> >> From: Emil Velikov 
>> >>
>> >> The function name is misleading - it effectively checks if
>> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
>> >> error - a close to impossible scenario.
>> >
>> > How about a DRI node which doesn't have a driver in Mesa?
>> >
>> Can you elaborate a bit - are you thinking of any of the following or
>> something else:
>>  - no support for vendor X
>>  - supported vendor, missing vendor/device pci id for device X
>>  - supported vendor, built w/o it
>>
>> All these are fairly different cases, with somewhat different solution
>> for each one.
>
> Let's say "no support for vendor X", but supported vendor Y GPU next
> to it. We want this code to skip vendor X DRI node and choose vendor Y
> DRI node.
>
>>
>> Fwiw the function loader_get_driver_for_fd does:
>>  - gets the vendor/device pci id and maps that to a driver_name
>>  - if device not a pci device (or query fails) - fallback to the name
>> as returned in drmGetVersion
>
> Good catch. Looks like I misunderstood what it does when reviewing
> Rob's series and existing code doesn't work as I expected. I think it
> would just error out in the case above, right?
>
Determining if a device is "supported" is fairly subtle:
For example, even if you open the foo_dri.so the driver can fail due
to old kernel module, LLVM version, etc.
One solution is to continue loading up-to dri2_create_screen() - if it
fails fall-back to the next device.

Any objections if I do that as follow-up patch, if you agree of course?

Feels a bit dirty, but will work until we get something like
EGL_EXT_explicit_device and EGL_MESA_query_renderer.

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

[Mesa-dev] [PATCH] glsl: Avoid calling get_array_element for scalar constants

[Danylo Piliaiev]

Accessing scalar constant as an array in function call or
initializer list triggered assert in get_array_element.
Examples:
   func(0[0]);
   vec2 t = { 0[0], 0 };

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

Signed-off-by: Danylo Piliaiev 
---
 src/compiler/glsl/ir_constant_expression.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ir_constant_expression.cpp 
b/src/compiler/glsl/ir_constant_expression.cpp
index 4a0aff72c6..c9788c7053 100644
--- a/src/compiler/glsl/ir_constant_expression.cpp
+++ b/src/compiler/glsl/ir_constant_expression.cpp
@@ -826,7 +826,7 @@ ir_dereference_array::constant_expression_value(void 
*mem_ctx,
  const unsigned component = idx->value.u[0];
 
  return new(mem_ctx) ir_constant(array, component);
-  } else {
+  } else if (array->type->is_array()) {
  const unsigned index = idx->value.u[0];
  return array->get_array_element(index)->clone(mem_ctx, NULL);
   }
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH 3/4] anv: Use central api generation scripts.

[Dylan Baker]

Quoting Emil Velikov (2018-08-13 03:38:13)
> On 10 August 2018 at 00:57, Dylan Baker  wrote:
> > Quoting Chad Versace (2018-08-09 10:37:33)
> >> On Tue 07 Aug 2018, Dylan Baker wrote:
> >> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
> >> > >
> >> > >  anv_extensions_c = custom_target(
> >> > > @@ -36,10 +37,11 @@ anv_extensions_c = custom_target(
> >> > >input : ['anv_extensions_gen.py', vk_api_xml],
> >> > >output : 'anv_extensions.c',
> >> > >command : [
> >> > > +   'env', 'PYTHONPATH=@0@'.format(join_paths(meson.source_root(), 
> >> > > 'src/vulkan/util/')),
> >> >
> >> > This is really gross, you're adding a dependency on a unix console 
> >> > command. I
> >> > know that anv is only built on Unix-like oses, but this will eventually 
> >> > end up
> >> > being used in some code that needs to run on Windows (or mac, does mac 
> >> > have
> >> > env?).
> >> >
> >> > I know that some people will object, but IMHO a better solution than 
> >> > mucking
> >> > with the python path (either through sys.path or through PYTHONPATH, is 
> >> > to
> >> > put all of the generators in a src/generators directory and be done with 
> >> > it.
> >> > Sure the intel specific bits (for example) aren't in the src/intel 
> >> > folder,
> >> > that's a small price to avoid having to call env just to run a python 
> >> > script.
> >>
> >> Dylan, I think we should avoid introducing complexity in the build
> >> system for the benefit of operating systems not supported by the driver.
> >> That feels like a serious premature optimazation, to me.  Anvil's usage
> >> of ioctls is highly specific to Linux/Unix, will not work on MacOS, and
> >> definitely does not work on Windows.
> >
> > I agree completely. I think where we disagree is on whether mucking with
> > PYTHONPATH and using env is more complex or putting our generators in a 
> > single
> > directory is more complex. I think using env is extremely gross and 
> > complex, I
> > think mucking with PYTHONPATH is extremely gross and complex, and I think 
> > having
> > to reference a file from another directory is a *lot* less gross and *much* 
> > less
> > complex.
> >
> Can we reuse the NIR approach seen here [1] [2]?
> Moving files around just to appease python feels wrong on many levels :-(
> 
> Thanks
> Emil
> 
> [1] 
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/compiler/meson.build#L120
> [2] 
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/freedreno/meson.build#L21

I would begrudgingly accept that.

I really don't understand why this is such a big deal. Imagine for a moment that
a there was a driver for "Magical Unicorn" hardware existed. Imagine it had some
very odd instructions and the developers of the Magic Unicorn driver wanted some
special NIR passes for their hardware. Now lets imagine that they insisted that
those passes must live in src/unicorn, but should be linked into libnir. No one
would accept that, they would be told either to keep the passes in their backend
or to move them into src/compiler/nir. I believe this is an analogous situation.
We want to share code, so we're putting it in src/util/vulkan, but then instead
of calling a generator out of src/util/vulkan in src/intel and src/amd (we
already call python scripts from different directories all over the build
system), we do some elaborate environment variable manipulation which can have
unforseen side effects (like that google sets PYTHONPATH in their distro) and
have to wrap our actual callable with `env`, just so that we could put the
callable in src/intel and src/amd instead of having a callable in
src/util/vulkan. Does no one else think that this is a bit crazy?

Dylan


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

Re: [Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Emil Velikov]

On 13 August 2018 at 16:21, Tomasz Figa  wrote:
> On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> wrote:
>>
>> From: Emil Velikov 
>>
>> The name string is guaranteed to be NULL terminated. Drop the explicit
>> length check that comes with strncmp().
>
> Is there anything wrong with that length check? I feel like it's a
> good practice to keep it anyway.
>
Consider the a long DRM driver name, that goes over PROPERTY_VALUE_MAX.
One could replace it with min(PROP.., version::name_len), although it
does seem over pedantic.

I'm yet to see a single instance that does strncmp for the name.

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

Re: [Mesa-dev] [PATCH 1/3] egl/drm: use gbm_dri_device() wrapper

[Daniel Stone]

Hi,

On Mon, 13 Aug 2018 at 15:46, Emil Velikov  wrote:
> Remove the explicit cast, using the appropriate wrapper instead.
>
> Signed-off-by: Emil Velikov 

I just compile-tested this, and it went OK - still a bunch of random
unrelated warnings throughout the build but this didn't add any new
ones. So, series is:
Acked-by: Daniel Stone 

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

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

On Tue, Aug 14, 2018 at 12:35 AM Emil Velikov  wrote:
>
> On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> > Hi Emil,
> >
> > On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> > wrote:
> >>
> >> From: Emil Velikov 
> >>
> >> The function name is misleading - it effectively checks if
> >> loader_get_driver_for_fd fails. Which can happen only only on strdup
> >> error - a close to impossible scenario.
> >
> > How about a DRI node which doesn't have a driver in Mesa?
> >
> Can you elaborate a bit - are you thinking of any of the following or
> something else:
>  - no support for vendor X
>  - supported vendor, missing vendor/device pci id for device X
>  - supported vendor, built w/o it
>
> All these are fairly different cases, with somewhat different solution
> for each one.

Let's say "no support for vendor X", but supported vendor Y GPU next
to it. We want this code to skip vendor X DRI node and choose vendor Y
DRI node.

>
> Fwiw the function loader_get_driver_for_fd does:
>  - gets the vendor/device pci id and maps that to a driver_name
>  - if device not a pci device (or query fails) - fallback to the name
> as returned in drmGetVersion

Good catch. Looks like I misunderstood what it does when reviewing
Rob's series and existing code doesn't work as I expected. I think it
would just error out in the case above, right?

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

Re: [Mesa-dev] [PATCH 1/3] egl/drm: use gbm_dri_device() wrapper

[Eric Engestrom]

On Monday, 2018-08-13 15:42:21 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Remove the explicit cast, using the appropriate wrapper instead.
> 
> Signed-off-by: Emil Velikov 

Series is:
Reviewed-by: Eric Engestrom 

> ---
>  src/egl/drivers/dri2/platform_drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_drm.c 
> b/src/egl/drivers/dri2/platform_drm.c
> index 35bc4b5b1ac..d42ef6b2f95 100644
> --- a/src/egl/drivers/dri2/platform_drm.c
> +++ b/src/egl/drivers/dri2/platform_drm.c
> @@ -45,7 +45,7 @@ lock_front_buffer(struct gbm_surface *_surf)
>  {
> struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
> struct dri2_egl_surface *dri2_surf = surf->dri_private;
> -   struct gbm_dri_device *device = (struct gbm_dri_device *) _surf->gbm;
> +   struct gbm_dri_device *device = gbm_dri_device(_surf->gbm);
> struct gbm_bo *bo;
>  
> if (dri2_surf->current == NULL) {
> -- 
> 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 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Frank Binns]

Hi Emil,

Emil Velikov  writes:

> From: Emil Velikov 
>
> Replace the manual handling of /dev/dri in famour of the drmDevice API.

s/famour/favour/

> The latter provides a consistent way of enumerating the devices,
> providing device details as needed.
>
> Cc: Robert Foss 
> Cc: Tomasz Figa 
> Signed-off-by: Emil Velikov 
> ---
> If using VGEM the following patch is needed [1]. It's been on the list
> for ages - will double-check and commmit it to drm-misc.
>
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
> ---
>  src/egl/drivers/dri2/platform_android.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index cc16fd8118f..685851acfc2 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1290,6 +1290,7 @@ static int
>  droid_open_device(_EGLDisplay *disp)
>  {
> const int MAX_DRM_DEVICES = 32;
> +   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
> int prop_set, num_devices;
> int fd = -1, fallback_fd = -1;
>  
> @@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)
> if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
>vendor_name = vendor_buf;
>  
> -   const char *drm_dir_name = "/dev/dri";
> -   DIR *sysdir = opendir(drm_dir_name);
> +   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);

It would be more robust to use ARRAY_SIZE here instead of
MAX_DRM_DEVICES.

Thanks
Frank

> +   if (num_devices < 0)
> +  return num_devices;
>  
> -   if (!sysdir)
> -   return -errno;
> +   for (int i = 0; i < num_devices; i++) {
> +  device = devices[i];
>  
> -   struct dirent *dent;
> -   while ((dent = readdir(sysdir))) {
> -  char dev_path[128];
> -  const char render_dev_prefix[] = "renderD";
> -  size_t prefix_len = sizeof(render_dev_prefix) - 1;
> -
> -  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
> +  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
>   continue;
>  
> -  snprintf(dev_path, sizeof(dev_path), "%s/%s", drm_dir_name, 
> dent->d_name);
> -  fd = loader_open_device(dev_path);
> +  fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
>if (fd < 0) {
>   _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
>   __func__, dev_path);
> @@ -1341,7 +1336,7 @@ droid_open_device(_EGLDisplay *disp)
> }
>  
>  success:
> -   closedir(sysdir);
> +   drmFreeDevices(devices, num_devices);
>  
> if (fallback_fd < 0 && fd < 0) {
>_eglLog(_EGL_WARNING, "Failed to open any DRM device");

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

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Emil Velikov]

On 13 August 2018 at 16:16, Tomasz Figa  wrote:
> Hi Emil,
>
> On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  
> wrote:
>>
>> From: Emil Velikov 
>>
>> The function name is misleading - it effectively checks if
>> loader_get_driver_for_fd fails. Which can happen only only on strdup
>> error - a close to impossible scenario.
>
> How about a DRI node which doesn't have a driver in Mesa?
>
Can you elaborate a bit - are you thinking of any of the following or
something else:
 - no support for vendor X
 - supported vendor, missing vendor/device pci id for device X
 - supported vendor, built w/o it

All these are fairly different cases, with somewhat different solution
for each one.

Fwiw the function loader_get_driver_for_fd does:
 - gets the vendor/device pci id and maps that to a driver_name
 - if device not a pci device (or query fails) - fallback to the name
as returned in drmGetVersion

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

Re: [Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Tomasz Figa]

On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> The name string is guaranteed to be NULL terminated. Drop the explicit
> length check that comes with strncmp().

Is there anything wrong with that length check? I feel like it's a
good practice to keep it anyway.

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

Re: [Mesa-dev] [PATCH] mesa/glspirv: fix compilation with MSVC

[Emil Velikov]

On 13 August 2018 at 15:56, Alejandro Piñeiro  wrote:
>
>
> On 13/08/18 16:50, Alejandro Piñeiro wrote:
>> From AppVeyor #8582, it seems that MSVC doesn't like uint, so this
>> patch replaces it with unsigned.
>> ---
>>
>> Note that Im not sure if this is the usual solution. As far as I see,
>> uint is used on other source files. Having said so, just replacing for
>> unsigned seems the easier way to fix this.
>
> Note2: I don't have a way to really test this patch on MSVC. I assume
> that it would fix it, but it is a kind of blind-assumption.
>
The AppVeyor + github integration is as trivial as travis + github.
Simply login click a few times and watch the build issues on git push.

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

Re: [Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Tomasz Figa]

Hi Emil,

On Mon, Aug 13, 2018 at 11:48 PM Emil Velikov  wrote:
>
> From: Emil Velikov 
>
> The function name is misleading - it effectively checks if
> loader_get_driver_for_fd fails. Which can happen only only on strdup
> error - a close to impossible scenario.

How about a DRI node which doesn't have a driver in Mesa?

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

Re: [Mesa-dev] [PATCH] mesa/glspirv: fix compilation with MSVC

[Alejandro Piñeiro]

On 13/08/18 16:50, Alejandro Piñeiro wrote:
> From AppVeyor #8582, it seems that MSVC doesn't like uint, so this
> patch replaces it with unsigned.
> ---
>
> Note that Im not sure if this is the usual solution. As far as I see,
> uint is used on other source files. Having said so, just replacing for
> unsigned seems the easier way to fix this.

Note2: I don't have a way to really test this patch on MSVC. I assume
that it would fix it, but it is a kind of blind-assumption.


>
>  src/mesa/main/glspirv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
> index 4fc80b72181..1c5b7dd17f3 100644
> --- a/src/mesa/main/glspirv.c
> +++ b/src/mesa/main/glspirv.c
> @@ -188,7 +188,7 @@ nir_compute_double_inputs(nir_shader *shader,
>  {
> nir_foreach_variable(var, &shader->inputs) {
>if (glsl_type_is_dual_slot(glsl_without_array(var->type))) {
> - for (uint i = 0; i < glsl_count_attribute_slots(var->type, true); 
> i++) {
> + for (unsigned i = 0; i < glsl_count_attribute_slots(var->type, 
> true); i++) {
>  uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
>  shader->info.vs.double_inputs |= bitfield;
>   }

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

[Mesa-dev] [PATCH] mesa/glspirv: fix compilation with MSVC

[Alejandro Piñeiro]

From AppVeyor #8582, it seems that MSVC doesn't like uint, so this
patch replaces it with unsigned.
---

Note that Im not sure if this is the usual solution. As far as I see,
uint is used on other source files. Having said so, just replacing for
unsigned seems the easier way to fix this.

 src/mesa/main/glspirv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/glspirv.c b/src/mesa/main/glspirv.c
index 4fc80b72181..1c5b7dd17f3 100644
--- a/src/mesa/main/glspirv.c
+++ b/src/mesa/main/glspirv.c
@@ -188,7 +188,7 @@ nir_compute_double_inputs(nir_shader *shader,
 {
nir_foreach_variable(var, &shader->inputs) {
   if (glsl_type_is_dual_slot(glsl_without_array(var->type))) {
- for (uint i = 0; i < glsl_count_attribute_slots(var->type, true); 
i++) {
+ for (unsigned i = 0; i < glsl_count_attribute_slots(var->type, true); 
i++) {
 uint64_t bitfield = BITFIELD64_BIT(var->data.location + i);
 shader->info.vs.double_inputs |= bitfield;
  }
-- 
2.14.1

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

[Mesa-dev] [PATCH 3/5] egl/android: remove droid_probe_driver()

[Emil Velikov]

From: Emil Velikov 

The function name is misleading - it effectively checks if
loader_get_driver_for_fd fails. Which can happen only only on strdup
error - a close to impossible scenario.

Drop the function - we call the loader API at at later stage.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index bea06fd55dd..9f2124fe349 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1236,19 +1236,6 @@ error:
return false;
 }
 
-static bool
-droid_probe_driver(int fd)
-{
-   char *driver_name;
-
-   driver_name = loader_get_driver_for_fd(fd);
-   if (driver_name == NULL)
-  return false;
-
-   free(driver_name);
-   return true;
-}
-
 typedef enum {
probe_fail = -1,
probe_success = 0,
@@ -1274,11 +1261,6 @@ droid_probe_device(_EGLDisplay *disp, int fd, const char 
*vendor)
   goto cleanup;
}
 
-   if (!droid_probe_driver(fd)) {
-  ret = probe_fail;
-  goto cleanup;
-   }
-
ret = probe_success;
 
 cleanup:
-- 
2.18.0

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

[Mesa-dev] [PATCH 4/5] egl/android: remove drmVersion::name NULL check

[Emil Velikov]

From: Emil Velikov 

The name string is guaranteed to be non-NULL.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 9f2124fe349..02bb0b55f03 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1251,11 +1251,6 @@ droid_probe_device(_EGLDisplay *disp, int fd, const char 
*vendor)
if (!ver)
   return probe_fail;
 
-   if (!ver->name) {
-  ret = probe_fail;
-  goto cleanup;
-   }
-
if (vendor && strcmp(vendor, ver->name) != 0) {
   ret = probe_filtered_out;
   goto cleanup;
-- 
2.18.0

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

[Mesa-dev] [PATCH 2/5] egl/android: use strcmp with drmVersion::name

[Emil Velikov]

From: Emil Velikov 

The name string is guaranteed to be NULL terminated. Drop the explicit
length check that comes with strncmp().

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 685851acfc2..bea06fd55dd 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1269,7 +1269,7 @@ droid_probe_device(_EGLDisplay *disp, int fd, const char 
*vendor)
   goto cleanup;
}
 
-   if (vendor && strncmp(vendor, ver->name, PROPERTY_VALUE_MAX) != 0) {
+   if (vendor && strcmp(vendor, ver->name) != 0) {
   ret = probe_filtered_out;
   goto cleanup;
}
-- 
2.18.0

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

[Mesa-dev] [PATCH 5/5] egl/android: simplify device open/probe

[Emil Velikov]

From: Emil Velikov 

Currently droid_probe_device, does not do any 'probing' but filtering
out a device if it doesn't match the vendor string given.

Rename the function, straighten the return type and call it only as
needed - an actual vendor string is provided.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 52 +
 1 file changed, 18 insertions(+), 34 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 02bb0b55f03..ad160d6886f 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1236,31 +1236,20 @@ error:
return false;
 }
 
-typedef enum {
-   probe_fail = -1,
-   probe_success = 0,
-   probe_filtered_out = 1,
-} probe_ret_t;
-
-static probe_ret_t
-droid_probe_device(_EGLDisplay *disp, int fd, const char *vendor)
+static int
+droid_filter_device(_EGLDisplay *disp, int fd, const char *vendor)
 {
-   int ret;
-
drmVersionPtr ver = drmGetVersion(fd);
if (!ver)
-  return probe_fail;
+  return -1;
 
-   if (vendor && strcmp(vendor, ver->name) != 0) {
-  ret = probe_filtered_out;
-  goto cleanup;
+   if (strcmp(vendor, ver->name) != 0) {
+  drmFreeVersion(ver);
+  return -1;
}
 
-   ret = probe_success;
-
-cleanup:
drmFreeVersion(ver);
-   return ret;
+   return 0;
 }
 
 static int
@@ -1294,25 +1283,20 @@ droid_open_device(_EGLDisplay *disp)
  continue;
   }
 
-  int ret = droid_probe_device(disp, fd, vendor_name);
-  switch (ret) {
-  case probe_success:
- goto success;
-  case probe_filtered_out:
- /* Set as fallback */
- if (fallback_fd == -1)
+  if (vendor_name && droid_filter_device(disp, fd, vendor_name)) {
+ /* Match requested, but not found - set as fallback */
+ if (fallback_fd == -1) {
 fallback_fd = fd;
- break;
-  case probe_fail:
- break;
-  }
+ } else {
+close(fd);
+fd = -1;
+ }
 
-  if (fallback_fd != fd)
- close(fd);
-  fd = -1;
+ continue;
+  }
+  /* Found a device */
+  break;
}
-
-success:
drmFreeDevices(devices, num_devices);
 
if (fallback_fd < 0 && fd < 0) {
-- 
2.18.0

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

[Mesa-dev] [PATCH 1/5] egl/android: use drmDevice instead of the manual /dev/dri iteration

[Emil Velikov]

From: Emil Velikov 

Replace the manual handling of /dev/dri in famour of the drmDevice API.
The latter provides a consistent way of enumerating the devices,
providing device details as needed.

Cc: Robert Foss 
Cc: Tomasz Figa 
Signed-off-by: Emil Velikov 
---
If using VGEM the following patch is needed [1]. It's been on the list
for ages - will double-check and commmit it to drm-misc.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-March/170944.html
---
 src/egl/drivers/dri2/platform_android.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index cc16fd8118f..685851acfc2 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1290,6 +1290,7 @@ static int
 droid_open_device(_EGLDisplay *disp)
 {
const int MAX_DRM_DEVICES = 32;
+   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
int prop_set, num_devices;
int fd = -1, fallback_fd = -1;
 
@@ -1299,23 +1300,17 @@ droid_open_device(_EGLDisplay *disp)
if (property_get("drm.gpu.vendor_name", vendor_buf, NULL) > 0)
   vendor_name = vendor_buf;
 
-   const char *drm_dir_name = "/dev/dri";
-   DIR *sysdir = opendir(drm_dir_name);
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  return num_devices;
 
-   if (!sysdir)
-   return -errno;
+   for (int i = 0; i < num_devices; i++) {
+  device = devices[i];
 
-   struct dirent *dent;
-   while ((dent = readdir(sysdir))) {
-  char dev_path[128];
-  const char render_dev_prefix[] = "renderD";
-  size_t prefix_len = sizeof(render_dev_prefix) - 1;
-
-  if (strncmp(render_dev_prefix, dent->d_name, prefix_len) != 0)
+  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
  continue;
 
-  snprintf(dev_path, sizeof(dev_path), "%s/%s", drm_dir_name, 
dent->d_name);
-  fd = loader_open_device(dev_path);
+  fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
   if (fd < 0) {
  _eglLog(_EGL_WARNING, "%s() Failed to open DRM device %s",
  __func__, dev_path);
@@ -1341,7 +1336,7 @@ droid_open_device(_EGLDisplay *disp)
}
 
 success:
-   closedir(sysdir);
+   drmFreeDevices(devices, num_devices);
 
if (fallback_fd < 0 && fd < 0) {
   _eglLog(_EGL_WARNING, "Failed to open any DRM device");
-- 
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] egl/drm: use gbm_dri_surface() wrapper

[Emil Velikov]

From: Emil Velikov 

Remove the explicit cast, using the appropriate wrapper instead.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index d42ef6b2f95..a0b4862e837 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -43,7 +43,7 @@
 static struct gbm_bo *
 lock_front_buffer(struct gbm_surface *_surf)
 {
-   struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
+   struct gbm_dri_surface *surf = gbm_dri_surface(_surf);
struct dri2_egl_surface *dri2_surf = surf->dri_private;
struct gbm_dri_device *device = gbm_dri_device(_surf->gbm);
struct gbm_bo *bo;
@@ -66,7 +66,7 @@ lock_front_buffer(struct gbm_surface *_surf)
 static void
 release_buffer(struct gbm_surface *_surf, struct gbm_bo *bo)
 {
-   struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
+   struct gbm_dri_surface *surf = gbm_dri_surface(_surf);
struct dri2_egl_surface *dri2_surf = surf->dri_private;
 
for (unsigned i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++) {
@@ -80,7 +80,7 @@ release_buffer(struct gbm_surface *_surf, struct gbm_bo *bo)
 static int
 has_free_buffers(struct gbm_surface *_surf)
 {
-   struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
+   struct gbm_dri_surface *surf = gbm_dri_surface(_surf);
struct dri2_egl_surface *dri2_surf = surf->dri_private;
 
for (unsigned i = 0; i < ARRAY_SIZE(dri2_surf->color_buffers); i++)
-- 
2.18.0

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

[Mesa-dev] [PATCH 3/3] egl/drm: use gbm_dri_bo() wrapper

[Emil Velikov]

From: Emil Velikov 

Remove the explicit cast, using the appropriate wrapper instead.

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

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index a0b4862e837..7538b3c7a45 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -305,7 +305,7 @@ back_bo_to_dri_buffer(struct dri2_egl_surface *dri2_surf, 
__DRIbuffer *buffer)
struct gbm_dri_bo *bo;
int name, pitch;
 
-   bo = (struct gbm_dri_bo *) dri2_surf->back->bo;
+   bo = gbm_dri_bo(dri2_surf->back->bo);
 
dri2_dpy->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_NAME, &name);
dri2_dpy->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_STRIDE, &pitch);
@@ -409,7 +409,7 @@ dri2_drm_image_get_buffers(__DRIdrawable *driDrawable,
if (get_back_bo(dri2_surf) < 0)
   return 0;
 
-   bo = (struct gbm_dri_bo *) dri2_surf->back->bo;
+   bo = gbm_dri_bo(dri2_surf->back->bo);
buffers->image_mask = __DRI_IMAGE_BUFFER_BACK;
buffers->back = bo->image;
 
-- 
2.18.0

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

[Mesa-dev] [PATCH 1/3] egl/drm: use gbm_dri_device() wrapper

[Emil Velikov]

From: Emil Velikov 

Remove the explicit cast, using the appropriate wrapper instead.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_drm.c 
b/src/egl/drivers/dri2/platform_drm.c
index 35bc4b5b1ac..d42ef6b2f95 100644
--- a/src/egl/drivers/dri2/platform_drm.c
+++ b/src/egl/drivers/dri2/platform_drm.c
@@ -45,7 +45,7 @@ lock_front_buffer(struct gbm_surface *_surf)
 {
struct gbm_dri_surface *surf = (struct gbm_dri_surface *) _surf;
struct dri2_egl_surface *dri2_surf = surf->dri_private;
-   struct gbm_dri_device *device = (struct gbm_dri_device *) _surf->gbm;
+   struct gbm_dri_device *device = gbm_dri_device(_surf->gbm);
struct gbm_bo *bo;
 
if (dri2_surf->current == NULL) {
-- 
2.18.0

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

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

[AppVeyor]

Build mesa 8582 failed


Commit c91a5f70fb by Neil Roberts on 7/31/2018 1:44 PM:

i965/nir: Use the nir copy of shader_info to handle gl_PatchVerticesIn\n\nInstead of using the copy of shader_info stored in gl_program, it now\nuses the one in nir_shader. This is needed for SPIR-V because the\ninfo.tess.tcs_vertices_out is filled in via _mesa_spirv_to_nir which\nhappens much later than with a GLSL shader. The copy of shader_data in\ngl_program is only updated later via brw_shader_gather_info but that\nis too late.\n\nFor GLSL this shouldn't create any problems because the nir copy of\nthe shader_info is immediately copied from the gl_program in\nglsl_to_nir.\n\nv2: updated after commit "i965: Combine both gl_PatchVerticesIn\nlowering passes." (488972) (Alejandro Piñeiro)\n\nReviewed-by: Timothy Arceri 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 02/10] spirv: Make VertexIndex and VertexId both non-zero-based

[Alejandro Piñeiro]

On 13/08/18 16:14, Jason Ekstrand wrote:
> I think this is ok.  The difference in implementation is a bit of an
> artifact of history.  When we were working on Vulkan 1.0, we wanted to
> make things consistent.  One suggestion for how to do that was to have
> Vertex/InstanceId which was zero-based and Vertex/InstanceIndex which
> included the base offset.  Then people decided that having two wasn't
> worth the bother so we threw out the ID variants and just kept the
> index variants.  In Vulkan VertexId and InstanceId have no meaning and
> are pretty much just reserved for GL at this point.
>
> On Mon, Aug 13, 2018 at 8:08 AM Alejandro Piñeiro
> mailto:apinhe...@igalia.com>> wrote:
>
> This is the only pending patch from this series, would appreciate a
> review. As everything involving the VertexIndex/Id, it is somewhat
> tricky. I'm CCing Kenneth too as he was involved on the OpenGL
> mess with
> gl_VertexId and similar.
>
> FWIW, I already executed the Intel CI, and there are no regressions.
>
>
> On 09/08/18 15:43, Alejandro Piñeiro wrote:
> > From: Neil Roberts  >
> >
> > GLSL has gl_VertexID which is supposed to be non-zero-based.
> >
> > SPIR-V has both VertexIndex and VertexId builtins whose meanings are
> > defined by the APIs.
> >
> > Vulkan defines VertexIndex as being non-zero-based. I can’t find
> > any mention of what VertexId is supposed to be.
> >
> > GL_ARB_spirv removes VertexIndex and defines VertexId to be the same
> > as gl_VertexId (which is alo non-zero-based).
> >
> > Previously in Mesa it was treating VertexIndex as non-zero-based and
> > VertexId as zero-based, so it was breaking for GL. This
> behaviour was
> > apparently based on Khronos bug 14255. However that bug doesn’t seem
> > to have made a final decision for VertexId.
> >
> > Assuming there really is no other definition for VertexId for Vulkan
> > it seems better to just make them both have the same
> > value.
> > ---
> >  src/compiler/spirv/vtn_variables.c | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/compiler/spirv/vtn_variables.c
> b/src/compiler/spirv/vtn_variables.c
> > index 8dab86abd74..b92bda59828 100644
> > --- a/src/compiler/spirv/vtn_variables.c
> > +++ b/src/compiler/spirv/vtn_variables.c
> > @@ -1011,15 +1011,16 @@ vtn_get_builtin_location(struct
> vtn_builder *b,
> >     case SpvBuiltInCullDistance:
> >        *location = VARYING_SLOT_CULL_DIST0;
> >        break;
> > -   case SpvBuiltInVertexIndex:
> > -      *location = SYSTEM_VALUE_VERTEX_ID;
> > -      set_mode_system_value(b, mode);
> > -      break;
> >     case SpvBuiltInVertexId:
> > -      /* Vulkan defines VertexID to be zero-based and reserves
> the new
> > -       * builtin keyword VertexIndex to indicate the
> non-zero-based value.
> > +   case SpvBuiltInVertexIndex:
> > +      /* For whatever reason, both of these are defined in the
> SPIR-V spec.
> > +       * The Vulkan spec defines VertexIndex to be
> non-zero-based and doesn’t
> > +       * mention VertexId. The ARB_gl_spirv spec defines
> VertexId to be the
> > +       * same as gl_VertexID, which is non-zero-based, and removes
> > +       * VertexIndex. Assuming there is no use for VertexId in
> Vulkan yet, we
> > +       * can just make them both be the same.
>
>
> I'd rewrite this comment more-or-less as follows:
>
> The Vulkan spec defines VertexIndex to be non-zero-based and doesn't
> allowe VertexId.  The ARB_gl_spirv spec defines VertexId to be the
> same as gl_VertexID, which is non-zer-based, and removes VertexIndex. 
> Since they're both defined to be non-zero-based, we use
> SYSTEM_VALUE_VERTEX_ID for both.
>
> With that,
>
> Reviewed-by: Jason Ekstrand  >

Thanks for the explanation and quick review. Based on your explanation
at the top, and the updated comment, I also tweaked a little the git
commit message.

Just pushed the series.

Again, thanks.

>  
>
> >         */
> > -      *location = SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
> > +      *location = SYSTEM_VALUE_VERTEX_ID;
> >        set_mode_system_value(b, mode);
> >        break;
> >     case SpvBuiltInInstanceIndex:
>

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

[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106877] The game Rise of the Tomb Raider lead to GPU hang when I try in same place jump into the hole.

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Blocks||77449


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Depends on||100069, 101978, 104602,
   ||106151, 106877, 106287,
   ||106875, 106224, 100400,
   ||103915, 101675, 101384


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=100069
[Bug 100069] Dirt: Showdown bad performance and broken rendering with enabled
advanced lightning
https://bugs.freedesktop.org/show_bug.cgi?id=100400
[Bug 100400] [Solved] Game Valhalla Hills crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=101384
[Bug 101384] [Hero Siege] si_shader: segfault in libLLVM-5.0.so.1
https://bugs.freedesktop.org/show_bug.cgi?id=101675
[Bug 101675] Peace, Death! crashed on start-up
https://bugs.freedesktop.org/show_bug.cgi?id=101978
[Bug 101978] [bisected] war thunder performance reduced by ~28%
https://bugs.freedesktop.org/show_bug.cgi?id=103915
[Bug 103915] Undertale crashes on startup (compiling shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=104602
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=106151
[Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of
the Tomb Raider)
https://bugs.freedesktop.org/show_bug.cgi?id=106224
[Bug 106224] "Medieval 2 Total War" will sometimes crash system on a R9 270
card
https://bugs.freedesktop.org/show_bug.cgi?id=106287
[Bug 106287] 18.0.1 introduced glitches in Dying Light
https://bugs.freedesktop.org/show_bug.cgi?id=106875
[Bug 106875] The game Anima Gate of Memories has artefects on Vega 56
https://bugs.freedesktop.org/show_bug.cgi?id=106877
[Bug 106877] The game Rise of the Tomb Raider lead to GPU hang when I try in
same place jump into the hole.
-- 
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 02/10] spirv: Make VertexIndex and VertexId both non-zero-based

[Jason Ekstrand]

I think this is ok.  The difference in implementation is a bit of an
artifact of history.  When we were working on Vulkan 1.0, we wanted to make
things consistent.  One suggestion for how to do that was to have
Vertex/InstanceId which was zero-based and Vertex/InstanceIndex which
included the base offset.  Then people decided that having two wasn't worth
the bother so we threw out the ID variants and just kept the index
variants.  In Vulkan VertexId and InstanceId have no meaning and are pretty
much just reserved for GL at this point.

On Mon, Aug 13, 2018 at 8:08 AM Alejandro Piñeiro 
wrote:

> This is the only pending patch from this series, would appreciate a
> review. As everything involving the VertexIndex/Id, it is somewhat
> tricky. I'm CCing Kenneth too as he was involved on the OpenGL mess with
> gl_VertexId and similar.
>
> FWIW, I already executed the Intel CI, and there are no regressions.
>
>
> On 09/08/18 15:43, Alejandro Piñeiro wrote:
> > From: Neil Roberts 
> >
> > GLSL has gl_VertexID which is supposed to be non-zero-based.
> >
> > SPIR-V has both VertexIndex and VertexId builtins whose meanings are
> > defined by the APIs.
> >
> > Vulkan defines VertexIndex as being non-zero-based. I can’t find
> > any mention of what VertexId is supposed to be.
> >
> > GL_ARB_spirv removes VertexIndex and defines VertexId to be the same
> > as gl_VertexId (which is alo non-zero-based).
> >
> > Previously in Mesa it was treating VertexIndex as non-zero-based and
> > VertexId as zero-based, so it was breaking for GL. This behaviour was
> > apparently based on Khronos bug 14255. However that bug doesn’t seem
> > to have made a final decision for VertexId.
> >
> > Assuming there really is no other definition for VertexId for Vulkan
> > it seems better to just make them both have the same
> > value.
> > ---
> >  src/compiler/spirv/vtn_variables.c | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/compiler/spirv/vtn_variables.c
> b/src/compiler/spirv/vtn_variables.c
> > index 8dab86abd74..b92bda59828 100644
> > --- a/src/compiler/spirv/vtn_variables.c
> > +++ b/src/compiler/spirv/vtn_variables.c
> > @@ -1011,15 +1011,16 @@ vtn_get_builtin_location(struct vtn_builder *b,
> > case SpvBuiltInCullDistance:
> >*location = VARYING_SLOT_CULL_DIST0;
> >break;
> > -   case SpvBuiltInVertexIndex:
> > -  *location = SYSTEM_VALUE_VERTEX_ID;
> > -  set_mode_system_value(b, mode);
> > -  break;
> > case SpvBuiltInVertexId:
> > -  /* Vulkan defines VertexID to be zero-based and reserves the new
> > -   * builtin keyword VertexIndex to indicate the non-zero-based
> value.
> > +   case SpvBuiltInVertexIndex:
> > +  /* For whatever reason, both of these are defined in the SPIR-V
> spec.
> > +   * The Vulkan spec defines VertexIndex to be non-zero-based and
> doesn’t
> > +   * mention VertexId. The ARB_gl_spirv spec defines VertexId to be
> the
> > +   * same as gl_VertexID, which is non-zero-based, and removes
> > +   * VertexIndex. Assuming there is no use for VertexId in Vulkan
> yet, we
> > +   * can just make them both be the same.
>

I'd rewrite this comment more-or-less as follows:

The Vulkan spec defines VertexIndex to be non-zero-based and doesn't allowe
VertexId.  The ARB_gl_spirv spec defines VertexId to be the same as
gl_VertexID, which is non-zer-based, and removes VertexIndex.  Since
they're both defined to be non-zero-based, we use SYSTEM_VALUE_VERTEX_ID
for both.

With that,

Reviewed-by: Jason Ekstrand 


> > */
> > -  *location = SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
> > +  *location = SYSTEM_VALUE_VERTEX_ID;
> >set_mode_system_value(b, mode);
> >break;
> > case SpvBuiltInInstanceIndex:
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 02/10] spirv: Make VertexIndex and VertexId both non-zero-based

[Alejandro Piñeiro]

This is the only pending patch from this series, would appreciate a
review. As everything involving the VertexIndex/Id, it is somewhat
tricky. I'm CCing Kenneth too as he was involved on the OpenGL mess with
gl_VertexId and similar.

FWIW, I already executed the Intel CI, and there are no regressions.


On 09/08/18 15:43, Alejandro Piñeiro wrote:
> From: Neil Roberts 
>
> GLSL has gl_VertexID which is supposed to be non-zero-based.
>
> SPIR-V has both VertexIndex and VertexId builtins whose meanings are
> defined by the APIs.
>
> Vulkan defines VertexIndex as being non-zero-based. I can’t find
> any mention of what VertexId is supposed to be.
>
> GL_ARB_spirv removes VertexIndex and defines VertexId to be the same
> as gl_VertexId (which is alo non-zero-based).
>
> Previously in Mesa it was treating VertexIndex as non-zero-based and
> VertexId as zero-based, so it was breaking for GL. This behaviour was
> apparently based on Khronos bug 14255. However that bug doesn’t seem
> to have made a final decision for VertexId.
>
> Assuming there really is no other definition for VertexId for Vulkan
> it seems better to just make them both have the same
> value.
> ---
>  src/compiler/spirv/vtn_variables.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/src/compiler/spirv/vtn_variables.c 
> b/src/compiler/spirv/vtn_variables.c
> index 8dab86abd74..b92bda59828 100644
> --- a/src/compiler/spirv/vtn_variables.c
> +++ b/src/compiler/spirv/vtn_variables.c
> @@ -1011,15 +1011,16 @@ vtn_get_builtin_location(struct vtn_builder *b,
> case SpvBuiltInCullDistance:
>*location = VARYING_SLOT_CULL_DIST0;
>break;
> -   case SpvBuiltInVertexIndex:
> -  *location = SYSTEM_VALUE_VERTEX_ID;
> -  set_mode_system_value(b, mode);
> -  break;
> case SpvBuiltInVertexId:
> -  /* Vulkan defines VertexID to be zero-based and reserves the new
> -   * builtin keyword VertexIndex to indicate the non-zero-based value.
> +   case SpvBuiltInVertexIndex:
> +  /* For whatever reason, both of these are defined in the SPIR-V spec.
> +   * The Vulkan spec defines VertexIndex to be non-zero-based and doesn’t
> +   * mention VertexId. The ARB_gl_spirv spec defines VertexId to be the
> +   * same as gl_VertexID, which is non-zero-based, and removes
> +   * VertexIndex. Assuming there is no use for VertexId in Vulkan yet, we
> +   * can just make them both be the same.
> */
> -  *location = SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
> +  *location = SYSTEM_VALUE_VERTEX_ID;
>set_mode_system_value(b, mode);
>break;
> case SpvBuiltInInstanceIndex:

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

Re: [Mesa-dev] [PATCH] glx: fill out GLX_DONT_CARE values

[Eric Engestrom]

On Saturday, 2018-08-11 17:19:04 +0100, Lionel Landwerlin wrote:
> When associating a template GLX config to a DRI one (filled out by the
> driver), we need to update the GLX_DONT_CARE fields (like yInverted
> for example). Otherwise those fields will report GLX_DONT_CARE to the
> application which is not what the driver is actually doing.
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  src/glx/dri_common.c | 34 ++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index ab5d6c5bc03..c49c1a43c12 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -339,6 +339,39 @@ driConfigEqual(const __DRIcoreExtension *core,
> return GL_TRUE;
>  }
>  
> +static void
> +driUpdateDontCareValues(const __DRIcoreExtension *core,
> +struct glx_config *config,
> +const __DRIconfig *driConfig)
> +{
> +   unsigned int attrib, value;
> +   int i, j;
> +
> +   i = 0;
> +   while (core->indexConfigAttrib(driConfig, i++, &attrib, &value)) {

The `i++` hidden in the middle there bothers me; what about a for loop instead?

  for (int i = 0; core->indexConfigAttrib(driConfig, i, &attrib, &value); i++)

Either way:
Reviewed-by: Eric Engestrom 

> +  switch (attrib) {
> +  case __DRI_ATTRIB_RENDER_TYPE:
> +  case __DRI_ATTRIB_CONFIG_CAVEAT:
> +  case __DRI_ATTRIB_BIND_TO_TEXTURE_TARGETS:
> +  case __DRI_ATTRIB_SWAP_METHOD:
> + break;
> +
> +  default: {
> + for (j = 0; j < ARRAY_SIZE(attribMap); j++)
> +if (attribMap[j].attrib == attrib) {
> +   unsigned *glxValue =
> +  (unsigned int *) ((char *) config + attribMap[j].offset);
> +
> +   if (*glxValue == GLX_DONT_CARE)
> +  *glxValue = value;
> +}
> +
> + break;
> +  }
> +  }

The curly braces in `default:` are unnecessary, and at first glance
seeing two sets of braces closing on the same level looks like a bug.

> +   }
> +}
> +
>  static struct glx_config *
>  createDriMode(const __DRIcoreExtension * core,
> struct glx_config *config, const __DRIconfig **driConfigs)
> @@ -360,6 +393,7 @@ createDriMode(const __DRIcoreExtension * core,
>  
> driConfig->base = *config;
> driConfig->driConfig = driConfigs[i];
> +   driUpdateDontCareValues(core, &driConfig->base, driConfig->driConfig);
>  
> return &driConfig->base;
>  }
> -- 
> 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 mesa] travis: install correct version of mako for each build system

[Eric Engestrom]

Meson now uses python3, so let's add a block for Autotools, move that
line into the buildsys-specific blocks, and set the correct version for
Meson.

Fixes: 2ee1c86d71bee5ddca2c "meson: Build with Python 3"
Signed-off-by: Eric Engestrom 
---
 .travis.yml | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 430c159c9c5c946280a4..32cd8602e6f06a97f37b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -493,18 +493,23 @@ before_install:
 fi
 
 install:
-  - pip2 install --user mako
-
   # Install a more modern meson from pip, since the version in the
   # ubuntu repos is often quite old. Avoid >=0.45.0 as it needs python
   # 3.5+
   - if test "x$BUILD" = xmeson; then
   pip3 install --user "meson<0.45.0";
+  pip3 install --user mako;
+fi
+
+  # Install autotools build dependencies
+  - if test "x$BUILD" = xmake; then
+  pip2 install --user mako;
 fi
 
   # Install a more modern scons from pip.
   - if test "x$BUILD" = xscons; then
   pip2 install --user "scons>=2.4";
+  pip2 install --user mako;
 fi
 
   # Since libdrm gets updated in configure.ac regularly, try to pick up the
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] Why are pbuffers backed by a pixmaps (Was Re: [PATCH] egl: Fix leak of X11 pixmaps backing pbuffers in DRI3.)

[Emil Velikov]

Hi Adam,

Thanks for the extensive write-up.

On 9 August 2018 at 20:30, Adam Jackson  wrote:
> On Thu, 2018-08-09 at 18:22 +0100, Emil Velikov wrote:
>
>> In the GLX case, it's required due to server-side rendering. One needs
>> a separate primitive for each pbuffer, thus the information can be
>> passed long the wire.
>
> I can't parse this. "Primitive"?
>
> So, backstory time. GLX_SGIX_pbuffer was the genesis of pbuffers.
> Here's what it has to say about how a pbuffer is unlike other GLX
> drawables (some of which is a comment about how things happened to work
> on IRIX):
>
> "GLXPbuffers are equivalent to GLXPixmaps with the following
> exceptions:
>
> 1.  There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
> resource, it may not be possible to render to it using X or an
> X extension other than GLX.
>
> 2.  The format of the color buffers and the type and size of any
> associated ancillary buffers for a GLXPbuffer can only be
> described with a GLXFBConfig -- an X Visual cannot be used.
>
> 3.  It is possible to create a GLXPbuffer whose contents may be
> asynchronously lost at any time.
>
> 4.  GLXPbuffers can be rendered to using either direct or indirect
> rendering contexts.
>
> 5.  The allocation of a GLXPbuffer can fail if there are insufficient
> resources (i.e., all the pbuffer memory has been allocated and
> the implementation does not virtualize pbuffer memory.)"
>
> In contrast, a GLXPixmap _must_ be renderable by X11, cannot lose its
> contents, and _may_ not be renderable by direct contexts. All of this
> dates to like 1997, so we didn't have FBOs yet, and any rendering
> surface would have been allocated by "the server" [1]. That extension
> was merged into GLX 1.3 pretty much unchanged, and GLX 1.3 was 1998.
>
> Xorg didn't get GLX 1.3 working until like 2007 [2]. As an
> implementation choice, Xorg _does_ back pbuffers with pixmaps, both in
> that it calls ->CreatePixmap internally to make them and that it tracks
> them as actual pixmaps [3]. We never clobber pbuffers, we have no
> problem rendering to pbuffers from X11, and we have no problem
> rendering to GLXPixmaps from direct contexts. Effectively, other than
> the resource type, the difference between a pbuffer and a glxpixmap is
> that the latter takes two XIDs and two resource creation calls.
>
So if I understood you correctly [and the spec] there is no
requirement (nor ban) on rendering to pbuffers from X11.
It's an implementation decision to allow it.

> EGL dates to 2003, which means it predates even EXT_framebuffer_object,
> so the pbuffer bit of GLX was kept in the new API. The EGL spec says a
> pbuffer has no associated native window or native window type - no
> kidding, it's not a window - but it does not require that a pbuffer
> have no native object backing it at all.
>
I> Now, direct rendering in GLX is underspecified; the implementation is
> free to use whatever subset of GLX, and whatever private protocol, it
> wants. In principle the client could allocate the pbuffer's storage
> from the "server" (the drm, here), and pass that handle and its new XID
> name to the X server to bind them together so indirect contexts can
> name it as well.
>
> An EGL implementation could take even more liberties. Even on an X11
> window system there's no intrinsic reason that an EGL pbuffer need to
> exist as a native winsys object; all that's required is that pbuffers
> work with any API that takes an EGLSurface parameter. You might choose
> to mirror EGL surfaces as GLX objects, or not, whatever your
> implementation finds convenient. In practice, we back pbuffers with
> pixmaps because we also back pixmaps with pixmaps, and there's no
> reason to make those paths diverge more than they have to.
>
I was thinking in the opposite direction - we already have pbuffer
implementation, which is duplicated across egl/android and
egl/surfaceless.
We could trivially make that a helper function and reuse across the board.

No need to special case X11, Android, etc - far less code and
divergence across platforms.
Using the same codepath across all EGL won't be that bad, right?

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

Re: [Mesa-dev] [PATCH 3/4] anv: Use central api generation scripts.

[Emil Velikov]

On 10 August 2018 at 00:57, Dylan Baker  wrote:
> Quoting Chad Versace (2018-08-09 10:37:33)
>> On Tue 07 Aug 2018, Dylan Baker wrote:
>> > Quoting Bas Nieuwenhuizen (2018-08-07 16:14:33)
>> > >
>> > >  anv_extensions_c = custom_target(
>> > > @@ -36,10 +37,11 @@ anv_extensions_c = custom_target(
>> > >input : ['anv_extensions_gen.py', vk_api_xml],
>> > >output : 'anv_extensions.c',
>> > >command : [
>> > > +   'env', 'PYTHONPATH=@0@'.format(join_paths(meson.source_root(), 
>> > > 'src/vulkan/util/')),
>> >
>> > This is really gross, you're adding a dependency on a unix console 
>> > command. I
>> > know that anv is only built on Unix-like oses, but this will eventually 
>> > end up
>> > being used in some code that needs to run on Windows (or mac, does mac have
>> > env?).
>> >
>> > I know that some people will object, but IMHO a better solution than 
>> > mucking
>> > with the python path (either through sys.path or through PYTHONPATH, is to
>> > put all of the generators in a src/generators directory and be done with 
>> > it.
>> > Sure the intel specific bits (for example) aren't in the src/intel folder,
>> > that's a small price to avoid having to call env just to run a python 
>> > script.
>>
>> Dylan, I think we should avoid introducing complexity in the build
>> system for the benefit of operating systems not supported by the driver.
>> That feels like a serious premature optimazation, to me.  Anvil's usage
>> of ioctls is highly specific to Linux/Unix, will not work on MacOS, and
>> definitely does not work on Windows.
>
> I agree completely. I think where we disagree is on whether mucking with
> PYTHONPATH and using env is more complex or putting our generators in a single
> directory is more complex. I think using env is extremely gross and complex, I
> think mucking with PYTHONPATH is extremely gross and complex, and I think 
> having
> to reference a file from another directory is a *lot* less gross and *much* 
> less
> complex.
>
Can we reuse the NIR approach seen here [1] [2]?
Moving files around just to appease python feels wrong on many levels :-(

Thanks
Emil

[1] 
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/intel/compiler/meson.build#L120
[2] 
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/freedreno/meson.build#L21
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers

[bugzilla-daemon]

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

--- Comment #10 from Gert Wollny  ---
I had a look at VSM versus ESM, and I see a difference that would indicate an
error in the ESM shader (be it in blender or the drivers), but there is no
specific output (like given in this bug) that would indicate where the problem
lies. 

If you have an example that gives this output like given above, then please add
the steps to reproduce this view in blender. 

For all other failures please add such comments to the other bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=107454

You can also try to create a rendering trace by using apitrace: 

  https://github.com/apitrace/apitrace

run "apitrace trace blender"), get to the point where things go wrong in
blender, and after it has made visible you can just close blender and then try
to attach the resulting blender.trace file to the bug. 

It is best to open a new bug for each issue. 

Best, 
Gert

-- 
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 105371] r600_shader_from_tgsi - GPR limit exceeded - shader requires 360 registers

[bugzilla-daemon]

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

--- Comment #9 from Gert Wollny  ---
@amonpaike thanks for pointing out the problems with blender, yes did a bit of
playing around with it, so I hope I'll be able to get some insight of what
might go wrong. However, there are some limits on how the r600 drivers were
written that might make it difficult to fix all issues.

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