[Mesa-dev] [PATCH] radv: add missing initializations since VK_EXT_pipeline_creation_feedback

[Samuel Pitoiset]

This fixes the world.

Fixes: 5f5ac19f138 ("radv: Implement VK_EXT_pipeline_creation_feedback.")"
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 91537db1ac5..83a06226ada 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3669,7 +3669,7 @@ radv_pipeline_init(struct radv_pipeline *pipeline,
VkPipelineCreationFeedbackEXT *pipeline_feedback = creation_feedback ? 
creation_feedback->pPipelineCreationFeedback : NULL;
 
const VkPipelineShaderStageCreateInfo *pStages[MESA_SHADER_STAGES] = { 
0, };
-   VkPipelineCreationFeedbackEXT *stage_feedbacks[MESA_SHADER_STAGES];
+   VkPipelineCreationFeedbackEXT *stage_feedbacks[MESA_SHADER_STAGES] = { 
0 };
for (uint32_t i = 0; i < pCreateInfo->stageCount; i++) {
gl_shader_stage stage = ffs(pCreateInfo->pStages[i].stage) - 1;
pStages[stage] = >pStages[i];
@@ -3901,7 +3901,7 @@ static VkResult radv_compute_pipeline_create(
RADV_FROM_HANDLE(radv_device, device, _device);
RADV_FROM_HANDLE(radv_pipeline_cache, cache, _cache);
const VkPipelineShaderStageCreateInfo *pStages[MESA_SHADER_STAGES] = { 
0, };
-   VkPipelineCreationFeedbackEXT *stage_feedbacks[MESA_SHADER_STAGES];
+   VkPipelineCreationFeedbackEXT *stage_feedbacks[MESA_SHADER_STAGES] = { 
0 };
struct radv_pipeline *pipeline;
VkResult result;
 
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] st/nine: enable csmt per default on iris

[Andre Heider]

On 20/03/2019 23:47, Axel Davy wrote:

On 20/03/2019 21:38, Andre Heider wrote:

iris is thread safe, enable csmt for a ~5% performace boost.

Signed-off-by: Andre Heider 
---
  src/gallium/state_trackers/nine/device9.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/gallium/state_trackers/nine/device9.c 
b/src/gallium/state_trackers/nine/device9.c

index 24c8ce062b3..db1c3a1d23d 100644
--- a/src/gallium/state_trackers/nine/device9.c
+++ b/src/gallium/state_trackers/nine/device9.c
@@ -266,13 +266,15 @@ NineDevice9_ctor( struct NineDevice9 *This,
  }
  /* Initialize CSMT */
+    /* r600, radeonsi and iris are thread safe. */
  if (pCTX->csmt_force == 1)
  This->csmt_active = true;
  else if (pCTX->csmt_force == 0)
  This->csmt_active = false;
-    else
-    /* r600 and radeonsi are thread safe. */
-    This->csmt_active = strstr(pScreen->get_name(pScreen), "AMD") 
!= NULL;

+    else if (strstr(pScreen->get_name(pScreen), "AMD") != NULL)
+    This->csmt_active = true;
+    else if (strstr(pScreen->get_name(pScreen), "Intel") != NULL)
+    This->csmt_active = true;
  /* We rely on u_upload_mgr using persistent coherent buffers 
(which don't
   * require flush to work in multi-pipe_context scenario) for 
vertex and



Could have been an || inside the same if, but maybe it is easier to read 
that way.


Yeah, I chose this way just for cosmetically reasons ;)


Reviewed-by: Axel Davy 


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

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Ernst Sjöstrand]

What's the expected change in behavior? Does it fix any bugs?

Regards
//Ernst

Den ons 20 mars 2019 kl 16:42 skrev Liu, Leo :
>
> The wait here is unnecessary since we got a pool of back buffers,
> and the wait for swap buffer will happen before the present pixmap,
> at the same time the previous back buffer will be put back to pool
> for reuse after the check for PresentIdleNotify event
>
> Signed-off-by: Leo Liu 
> ---
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 152d28e59fc..1558d832555 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -88,7 +88,6 @@ struct vl_dri3_screen
> uint64_t send_sbc, recv_sbc;
> int64_t last_ust, ns_frame, last_msc, next_msc;
>
> -   bool flushed;
> bool is_different_gpu;
>  };
>
> @@ -570,11 +569,9 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
> if (!back)
> return;
>
> -   if (scrn->flushed) {
> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> - if (!dri3_wait_present_events(scrn))
> -return;
> -   }
> +   while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> +  if (!dri3_wait_present_events(scrn))
> + return;
>
> rectangle.x = 0;
> rectangle.y = 0;
> @@ -610,8 +607,6 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>
> xcb_flush(scrn->conn);
>
> -   scrn->flushed = true;
> -
> return;
>  }
>
> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
> *vscreen, void *drawable)
> if (!dri3_set_drawable(scrn, (Drawable)drawable))
>return NULL;
>
> -   if (scrn->flushed) {
> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> - if (!dri3_wait_present_events(scrn))
> -return NULL;
> -   }
> -   scrn->flushed = false;
> -
> buffer = (scrn->is_pixmap) ?
>  dri3_get_front_buffer(scrn) :
>  dri3_get_back_buffer(scrn);
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac: add 16-bit support to fract

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index b5bb399eef1..2c6fecb91db 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2434,7 +2434,10 @@ LLVMValueRef ac_build_fract(struct ac_llvm_context *ctx, 
LLVMValueRef src0,
LLVMTypeRef type;
char *intr;
 
-   if (bitsize == 32) {
+   if (bitsize == 16) {
+   intr = "llvm.amdgcn.fract.f16";
+   type = ctx->f16;
+   } else if (bitsize == 32) {
intr = "llvm.amdgcn.fract.f32";
type = ctx->f32;
} else {
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

doh, it seems I used reply-list instead of reply-all, sending again with 
original author of the patch ..


On 3/21/19 9:14 AM, Tapani Pälli wrote:

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
  src/util/u_process.c | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
  __getProgramName()
  {
 char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into 
argv[0].

+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just 
wanted to mention, it might be not trivial to fix since I guess not all 
variants of __getProgramName will allocate?



+
+  if (path && strncmp(path, program_invocation_name, 
strlen(path)) == 0) {

+ /* This shouldn't be null because path is a a prefix,
+  * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+    return name + 1;
+  }
+
    return arg+1;
+   }
 /* If there was no '/' at all we likely have a windows like path 
from

  * a wine application.


___
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] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected

[Dieter Nützel]

Hello Bas,

sorry but your latest commit #5f5ac19f138
radv: Implement VK_EXT_pipeline_creation_feedback.

sigfault with every Vulkan apps for me.

Reverting it SOLVED it.

5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit
commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a
Author: Bas Nieuwenhuizen 
Date:   Tue Mar 19 02:30:33 2019 +0100

radv: Implement VK_EXT_pipeline_creation_feedback.

Does what it says on the tin.

The per stage time is only an approximation due to linking and
the Vega merged stages.

Reviewed-by: Samuel Pitoiset 

:04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 
0924580849d9bc268e47be1248311ff3b5488c86 M src


I'm on the 'old' way compiling today:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


/home/dieter> vkcube
Speicherschutzverletzung (core dumped)
/home/dieter> vkcubepp
Speicherschutzverletzung (core dumped)

[46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 
7ff795146569 sp 7ffda7d3d070 error 7 in 
libvulkan_radeon.so[7ff7950e4000+1cf000]
[46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 
0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb 
ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00


[46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 
7fde85cb9569 sp 7ffeb679dfc0 error 7 in 
libvulkan_radeon.so[7fde85c57000+1cf000]
[46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 f3 
0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 39 fb 
ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 00 00


/home/dieter> vulkaninfo | less
Speicherschutzverletzung (core dumped)

==
VULKANINFO
==

Vulkan Instance Version: 1.1.98



Instance Extensions:

Instance Extensions count = 16
VK_EXT_acquire_xlib_display : extension revision  1
VK_EXT_debug_report : extension revision  9
VK_EXT_debug_utils  : extension revision  1
VK_EXT_direct_mode_display  : extension revision  1
VK_EXT_display_surface_counter  : extension revision  1
VK_KHR_device_group_creation: extension revision  1
VK_KHR_display  : extension revision 23
VK_KHR_external_fence_capabilities  : extension revision  1
VK_KHR_external_memory_capabilities : extension revision  1
VK_KHR_external_semaphore_capabilities: extension revision  1
VK_KHR_get_display_properties2  : extension revision  1
VK_KHR_get_physical_device_properties2: extension revision  1
VK_KHR_get_surface_capabilities2: extension revision  1
VK_KHR_surface  : extension revision 25
VK_KHR_xcb_surface  : extension revision  6
VK_KHR_xlib_surface : extension revision  6
Layers: count = 0
===
Presentable Surfaces:
=
GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xcb_surface
Formats:count = 2
B8G8R8A8_SRGB
B8G8R8A8_UNORM
Present Modes:  count = 3
IMMEDIATE_KHR
MAILBOX_KHR
FIFO_KHR
VkSurfaceCapabilitiesKHR:
minImageCount   = 2
maxImageCount   = 0
currentExtent:
width   = 256
height  = 256
minImageExtent:
width   = 256
height  = 256
maxImageExtent:
width   = 256
height  = 256
maxImageArrayLayers = 1
supportedTransform:
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
currentTransform:
VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
supportedCompositeAlpha:
VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
supportedUsageFlags:
VK_IMAGE_USAGE_TRANSFER_SRC_BIT
VK_IMAGE_USAGE_TRANSFER_DST_BIT
VK_IMAGE_USAGE_SAMPLED_BIT
VK_IMAGE_USAGE_STORAGE_BIT
VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
supportedSurfaceCounters:
None

GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xlib_surface
Formats:count = 2
B8G8R8A8_SRGB
B8G8R8A8_UNORM
Present Modes:  count = 3
IMMEDIATE_KHR
MAILBOX_KHR
FIFO_KHR

Stops, here.

BTW
'vulkaninfo' sigfault for some days even without this commit for me.

[-]
VK_KHR_shader_draw_parameters   : extension revision  1
VK_KHR_storage_buffer_storage_class : extension revision  1

Re: [Mesa-dev] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected

[Samuel Pitoiset]

Yeah, my bad... I have just sent a fix.

Thanks

On 3/21/19 7:22 AM, Dieter Nützel wrote:

Hello Bas,

sorry but your latest commit #5f5ac19f138
radv: Implement VK_EXT_pipeline_creation_feedback.

sigfault with every Vulkan apps for me.

Reverting it SOLVED it.

5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit
commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a
Author: Bas Nieuwenhuizen 
Date:   Tue Mar 19 02:30:33 2019 +0100

    radv: Implement VK_EXT_pipeline_creation_feedback.

    Does what it says on the tin.

    The per stage time is only an approximation due to linking and
    the Vega merged stages.

    Reviewed-by: Samuel Pitoiset 

:04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 
0924580849d9bc268e47be1248311ff3b5488c86 M src


I'm on the 'old' way compiling today:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


/home/dieter> vkcube
Speicherschutzverletzung (core dumped)
/home/dieter> vkcubepp
Speicherschutzverletzung (core dumped)

[46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 
7ff795146569 sp 7ffda7d3d070 error 7 in 
libvulkan_radeon.so[7ff7950e4000+1cf000]
[46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


[46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 
7fde85cb9569 sp 7ffeb679dfc0 error 7 in 
libvulkan_radeon.so[7fde85c57000+1cf000]
[46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


/home/dieter> vulkaninfo | less
Speicherschutzverletzung (core dumped)

==
VULKANINFO
==

Vulkan Instance Version: 1.1.98



Instance Extensions:

Instance Extensions count = 16
    VK_EXT_acquire_xlib_display : extension revision 1
    VK_EXT_debug_report : extension revision 9
    VK_EXT_debug_utils  : extension revision 1
    VK_EXT_direct_mode_display  : extension revision 1
    VK_EXT_display_surface_counter  : extension revision 1
    VK_KHR_device_group_creation    : extension revision 1
    VK_KHR_display  : extension revision 23
    VK_KHR_external_fence_capabilities  : extension revision 1
    VK_KHR_external_memory_capabilities : extension revision 1
    VK_KHR_external_semaphore_capabilities: extension revision  1
    VK_KHR_get_display_properties2  : extension revision 1
    VK_KHR_get_physical_device_properties2: extension revision  1
    VK_KHR_get_surface_capabilities2    : extension revision 1
    VK_KHR_surface  : extension revision 25
    VK_KHR_xcb_surface  : extension revision 6
    VK_KHR_xlib_surface : extension revision 6
Layers: count = 0
===
Presentable Surfaces:
=
GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xcb_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR
VkSurfaceCapabilitiesKHR:
    minImageCount   = 2
    maxImageCount   = 0
    currentExtent:
    width   = 256
    height  = 256
    minImageExtent:
    width   = 256
    height  = 256
    maxImageExtent:
    width   = 256
    height  = 256
    maxImageArrayLayers = 1
    supportedTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    currentTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    supportedCompositeAlpha:
    VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
    VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
    supportedUsageFlags:
    VK_IMAGE_USAGE_TRANSFER_SRC_BIT
    VK_IMAGE_USAGE_TRANSFER_DST_BIT
    VK_IMAGE_USAGE_SAMPLED_BIT
    VK_IMAGE_USAGE_STORAGE_BIT
    VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
    supportedSurfaceCounters:
    None

GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xlib_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR

Stops, here.

BTW
'vulkaninfo' sigfault for some days even without this commit for me.

[-]
    VK_KHR_shader_draw_parameters   : extension revision 1
  

Re: [Mesa-dev] [PATCH v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
  src/util/u_process.c | 23 ++-
  1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
  __getProgramName()
  {
 char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into argv[0].
+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just 
wanted to mention, it might be not trivial to fix since I guess not all 
variants of __getProgramName will allocate?



+
+  if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+  * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+  }
+
return arg+1;
+   }
  
 /* If there was no '/' at all we likely have a windows like path from

  * a wine application.


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

[Mesa-dev] Vulcan ToDo for AMD

[nick]

Samuel,

The get_reviewer script mentioned you as the reviewer for the src/amd/vulcan 
directory. I was wondering
what is directly TODO. Don't know if that script is correct but if not I CCed 
the list to let other's
chip in.

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

Re: [Mesa-dev] [PATCH] ac: add 16-bit support to fract

[Bas Nieuwenhuizen]

r-b

On Thu, Mar 21, 2019 at 9:16 AM Samuel Pitoiset
 wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index b5bb399eef1..2c6fecb91db 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -2434,7 +2434,10 @@ LLVMValueRef ac_build_fract(struct ac_llvm_context 
> *ctx, LLVMValueRef src0,
> LLVMTypeRef type;
> char *intr;
>
> -   if (bitsize == 32) {
> +   if (bitsize == 16) {
> +   intr = "llvm.amdgcn.fract.f16";
> +   type = ctx->f16;
> +   } else if (bitsize == 32) {
> intr = "llvm.amdgcn.fract.f32";
> type = ctx->f32;
> } else {
> --
> 2.21.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] ac: fix 16-bit shifts

[Bas Nieuwenhuizen]

On Thu, Mar 21, 2019 at 11:59 AM Samuel Pitoiset
 wrote:
>
> This fixes the following LLVM error when ckeckir is set:
> Type too small for ZExt
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 33 +
>  1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 3681c07c364..925073efb85 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -671,22 +671,31 @@ static void visit_alu(struct ac_nir_context *ctx, const 
> nir_alu_instr *instr)
> result = LLVMBuildXor(ctx->ac.builder, src[0], src[1], "");
> break;
> case nir_op_ishl:
> -   result = LLVMBuildShl(ctx->ac.builder, src[0],
> - LLVMBuildZExt(ctx->ac.builder, src[1],
> -   LLVMTypeOf(src[0]), ""),
> - "");
> +   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
> ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
> +   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
> +  LLVMTypeOf(src[0]), "");
> +   else

Maybe make this an "else if" with the reverse check so we don't do
anything in the == case, for all three instructions?

Otherwise, r-b
> +   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
> +   LLVMTypeOf(src[0]), "");
> +   result = LLVMBuildShl(ctx->ac.builder, src[0], src[1], "");
> break;
> case nir_op_ishr:
> -   result = LLVMBuildAShr(ctx->ac.builder, src[0],
> -  LLVMBuildZExt(ctx->ac.builder, src[1],
> -LLVMTypeOf(src[0]), ""),
> -  "");
> +   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
> ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
> +   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
> +  LLVMTypeOf(src[0]), "");
> +   else
> +   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
> +   LLVMTypeOf(src[0]), "");
> +   result = LLVMBuildAShr(ctx->ac.builder, src[0], src[1], "");
> break;
> case nir_op_ushr:
> -   result = LLVMBuildLShr(ctx->ac.builder, src[0],
> -  LLVMBuildZExt(ctx->ac.builder, src[1],
> -LLVMTypeOf(src[0]), ""),
> -  "");
> +   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
> ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
> +   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
> +  LLVMTypeOf(src[0]), "");
> +   else
> +   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
> +   LLVMTypeOf(src[0]), "");
> +   result = LLVMBuildLShr(ctx->ac.builder, src[0], src[1], "");
> break;
> case nir_op_ilt32:
> result = emit_int_cmp(>ac, LLVMIntSLT, src[0], src[1]);
> --
> 2.21.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] vl/dri3: remove the wait before getting back buffer

[Michel Dänzer]

On 2019-03-20 4:42 p.m., Liu, Leo wrote:
> The wait here is unnecessary since we got a pool of back buffers,
> and the wait for swap buffer will happen before the present pixmap,
> at the same time the previous back buffer will be put back to pool
> for reuse after the check for PresentIdleNotify event
> 
> Signed-off-by: Leo Liu 
> 
>  [...]
> 
> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
> *vscreen, void *drawable)
> if (!dri3_set_drawable(scrn, (Drawable)drawable))
>return NULL;
>  
> -   if (scrn->flushed) {
> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> - if (!dri3_wait_present_events(scrn))
> -return NULL;
> -   }
> -   scrn->flushed = false;
> -
> buffer = (scrn->is_pixmap) ?
>  dri3_get_front_buffer(scrn) :
>  dri3_get_back_buffer(scrn);
> 

Hmm. Is the wait here not necessary before getting a pixmap's front
buffer either though? Maybe wait only here for a pixmap, and only in
vl_dri3_flush_frontbuffer for a window?

Sorry I didn't realize this earlier.


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

[Mesa-dev] [PATCH 1/2] ac: add f16_0 and f16_1 constants

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 2 ++
 src/amd/common/ac_llvm_build.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 2c6fecb91db..608f16a78f8 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -95,6 +95,8 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
ctx->i64_0 = LLVMConstInt(ctx->i64, 0, false);
ctx->i64_1 = LLVMConstInt(ctx->i64, 1, false);
+   ctx->f16_0 = LLVMConstReal(ctx->f16, 0.0);
+   ctx->f16_1 = LLVMConstReal(ctx->f16, 1.0);
ctx->f32_0 = LLVMConstReal(ctx->f32, 0.0);
ctx->f32_1 = LLVMConstReal(ctx->f32, 1.0);
ctx->f64_0 = LLVMConstReal(ctx->f64, 0.0);
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index aa6e913c6c6..9151c743bed 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -82,6 +82,8 @@ struct ac_llvm_context {
LLVMValueRef i32_1;
LLVMValueRef i64_0;
LLVMValueRef i64_1;
+   LLVMValueRef f16_0;
+   LLVMValueRef f16_1;
LLVMValueRef f32_0;
LLVMValueRef f32_1;
LLVMValueRef f64_0;
-- 
2.21.0

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

[Mesa-dev] [PATCH 2/2] ac: add 16-bit support fo fsign

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 608f16a78f8..8701d2ca43a 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2475,7 +2475,11 @@ LLVMValueRef ac_build_fsign(struct ac_llvm_context *ctx, 
LLVMValueRef src0,
LLVMValueRef cmp, val, zero, one;
LLVMTypeRef type;
 
-   if (bitsize == 32) {
+   if (bitsize == 16) {
+   type = ctx->f16;
+   zero = ctx->f16_0;
+   one = ctx->f16_1;
+   } else if (bitsize == 32) {
type = ctx->f32;
zero = ctx->f32_0;
one = ctx->f32_1;
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH 1/2] ac: add f16_0 and f16_1 constants

[Bas Nieuwenhuizen]

r-b for both.

On Thu, Mar 21, 2019 at 10:11 AM Samuel Pitoiset
 wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 2 ++
>  src/amd/common/ac_llvm_build.h | 2 ++
>  2 files changed, 4 insertions(+)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 2c6fecb91db..608f16a78f8 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -95,6 +95,8 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
> ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
> ctx->i64_0 = LLVMConstInt(ctx->i64, 0, false);
> ctx->i64_1 = LLVMConstInt(ctx->i64, 1, false);
> +   ctx->f16_0 = LLVMConstReal(ctx->f16, 0.0);
> +   ctx->f16_1 = LLVMConstReal(ctx->f16, 1.0);
> ctx->f32_0 = LLVMConstReal(ctx->f32, 0.0);
> ctx->f32_1 = LLVMConstReal(ctx->f32, 1.0);
> ctx->f64_0 = LLVMConstReal(ctx->f64, 0.0);
> diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
> index aa6e913c6c6..9151c743bed 100644
> --- a/src/amd/common/ac_llvm_build.h
> +++ b/src/amd/common/ac_llvm_build.h
> @@ -82,6 +82,8 @@ struct ac_llvm_context {
> LLVMValueRef i32_1;
> LLVMValueRef i64_0;
> LLVMValueRef i64_1;
> +   LLVMValueRef f16_0;
> +   LLVMValueRef f16_1;
> LLVMValueRef f32_0;
> LLVMValueRef f32_1;
> LLVMValueRef f64_0;
> --
> 2.21.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] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Józef Kucia]

On Tue, Mar 12, 2019 at 4:11 PM Józef Kucia  wrote:
>  src/mesa/main/get.c | 3 +++
>  1 file changed, 3 insertions(+)

Ping.

The patch fixes glGetIntegerv(GL_NUM_DEVICE_UUIDS_EXT, ...).
GL_NUM_DEVICE_UUIDS_EXT is implemented in the same way in
find_value_indexed().
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: enable VK_AMD_gpu_shader_half_float

[Samuel Pitoiset]

On 3/21/19 11:09 AM, Bas Nieuwenhuizen wrote:

Honestly the zero tests is worrying me. This is a pretty big extension
and I have questions like:

to 16-bit loads + 16-bit ALU actually work together or have we been
silently relying on the fact there is always a ZExt cast after and
that did not care about input size?


Yeah... It's clearly untested, I think it works but it's just a guess.

Maybe we should implement crucible tests?



On Thu, Mar 21, 2019 at 10:03 AM Samuel Pitoiset
 wrote:

Should be safe to enable as all instructions seem to support 16-bit.
Unfortunately, there is no CTS test.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_extensions.py | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 421f8b926ea..23106765c2a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -122,6 +122,7 @@ EXTENSIONS = [
  Extension('VK_EXT_vertex_attribute_divisor',  3, True),
  Extension('VK_AMD_draw_indirect_count',   1, True),
  Extension('VK_AMD_gcn_shader',1, True),
+Extension('VK_AMD_gpu_shader_half_float', 1, 'device->rad_info.chip_class 
>= VI && HAVE_LLVM >= 0x0800'),
  Extension('VK_AMD_rasterization_order',   1, 
'device->has_out_of_order_rast'),
  Extension('VK_AMD_shader_core_properties',1, True),
  Extension('VK_AMD_shader_info',   1, True),
--
2.21.0

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

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #3 from Pierre Labastie  ---
Thanks for the quick fix.

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

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Liu, Leo]

On 2019-03-21 4:15 a.m., Ernst Sjöstrand wrote:
> What's the expected change in behavior?

The change will make vl_dri3_screen_texture_from_drawable() call not to 
hold the pipeline. Because of the multiple of back buffers,  we can get 
the texture of the ongoing presented back buffer, and no need to wait 
the last presenting back buffer.

> Does it fix any bugs?

Yeah. With some of relatively slower hardware to play 4k@60fps, the 
presentation will miss the targeted time, and make the duration of the 
playback longer than the actual. esp. like VDPAU with scheduled 
presentation.


Thanks,

Leo


>
> Regards
> //Ernst
>
> Den ons 20 mars 2019 kl 16:42 skrev Liu, Leo :
>> The wait here is unnecessary since we got a pool of back buffers,
>> and the wait for swap buffer will happen before the present pixmap,
>> at the same time the previous back buffer will be put back to pool
>> for reuse after the check for PresentIdleNotify event
>>
>> Signed-off-by: Leo Liu 
>> ---
>>   src/gallium/auxiliary/vl/vl_winsys_dri3.c | 18 +++---
>>   1 file changed, 3 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
>> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> index 152d28e59fc..1558d832555 100644
>> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>> @@ -88,7 +88,6 @@ struct vl_dri3_screen
>>  uint64_t send_sbc, recv_sbc;
>>  int64_t last_ust, ns_frame, last_msc, next_msc;
>>
>> -   bool flushed;
>>  bool is_different_gpu;
>>   };
>>
>> @@ -570,11 +569,9 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>>  if (!back)
>>  return;
>>
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return;
>> -   }
>> +   while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> +  if (!dri3_wait_present_events(scrn))
>> + return;
>>
>>  rectangle.x = 0;
>>  rectangle.y = 0;
>> @@ -610,8 +607,6 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>>
>>  xcb_flush(scrn->conn);
>>
>> -   scrn->flushed = true;
>> -
>>  return;
>>   }
>>
>> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
>> *vscreen, void *drawable)
>>  if (!dri3_set_drawable(scrn, (Drawable)drawable))
>> return NULL;
>>
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return NULL;
>> -   }
>> -   scrn->flushed = false;
>> -
>>  buffer = (scrn->is_pixmap) ?
>>   dri3_get_front_buffer(scrn) :
>>   dri3_get_back_buffer(scrn);
>> --
>> 2.17.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac: fix incorrect argument type for tbuffer.{load, store} with LLVM 7

[Samuel Pitoiset]

GLC/SLC are boolean.

This fixes the following LLVM error when checkir is set:
Intrinsic has incorrect argument type!
void (i32, <4 x i32>, i32, i32, i32, i32, i32, i32, i32, i32)* 
@llvm.amdgcn.tbuffer.store.i32

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8701d2ca43a..1123dce2cc8 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1537,8 +1537,8 @@ ac_build_tbuffer_load(struct ac_llvm_context *ctx,
immoffset,
LLVMConstInt(ctx->i32, dfmt, false),
LLVMConstInt(ctx->i32, nfmt, false),
-   LLVMConstInt(ctx->i32, glc, false),
-   LLVMConstInt(ctx->i32, slc, false),
+   LLVMConstInt(ctx->i1, glc, false),
+   LLVMConstInt(ctx->i1, slc, false),
};
unsigned func = CLAMP(num_channels, 1, 3) - 1;
LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v4i32};
@@ -1699,8 +1699,8 @@ ac_build_tbuffer_store(struct ac_llvm_context *ctx,
immoffset,
LLVMConstInt(ctx->i32, dfmt, false),
LLVMConstInt(ctx->i32, nfmt, false),
-   LLVMConstInt(ctx->i32, glc, false),
-   LLVMConstInt(ctx->i32, slc, false),
+   LLVMConstInt(ctx->i1, glc, false),
+   LLVMConstInt(ctx->i1, slc, false),
};
unsigned func = CLAMP(num_channels, 1, 3) - 1;
const char *type_names[] = {"i32", "v2i32", "v4i32"};
-- 
2.21.0

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #5 from Dylan Baker  ---
:(

Yes, I know how to fix it. Just need more code.

I'm on mobile, please excuse autocorrect fail.

On Thu, Mar 21, 2019, 04:34  wrote:

> *Comment # 4  on
> bug 110211  from
> Rafael Castillo  *
>
> Hi, dylan your patch broke ArchLinux PKGBUILD for mesa since your patch for
> some reason bypass fakeinstall paths and try to install directly in /usr/lib,
> any suggestions?
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
>

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

[Mesa-dev] [Bug 110216] radv: Segfault when compiling compute shaders from Assassin's Creed Odyssey (regression, bisected)

[bugzilla-daemon]

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

Bug ID: 110216
   Summary: radv: Segfault when compiling compute shaders from
Assassin's Creed Odyssey (regression, bisected)
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: philip.rebo...@tu-dortmund.de
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 143744
  --> https://bugs.freedesktop.org/attachment.cgi?id=143744=edit
Compute shader that triggers the crash

Hello,

trying to compile the attached compute shader (among others) causes the driver
to segfault. The commit which introduced the issue is:


commit 3235a942c16b61849bc16a710c53f0a7a5566f0d (HEAD, refs/bisect/bad)
Author: Timothy Arceri 
Date:   Thu Dec 6 16:00:40 2018 +1100

nir: find induction/limit vars in iand instruction


Please let me know if you need more info.

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

Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Tapani Pälli]

On 3/21/19 1:47 PM, Józef Kucia wrote:

On Tue, Mar 12, 2019 at 4:11 PM Józef Kucia  wrote:

  src/mesa/main/get.c | 3 +++
  1 file changed, 3 insertions(+)


Ping.

The patch fixes glGetIntegerv(GL_NUM_DEVICE_UUIDS_EXT, ...).
GL_NUM_DEVICE_UUIDS_EXT is implemented in the same way in
find_value_indexed().


Yeah, checked that value matches of find_value_indexed;

Reviewed-by: Tapani Pälli 

Does this affect 'ext_semaphore-api-errors' Piglit test that calls this 
in any way?




___
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 v7 1/5] util: Get program name based on path when possible

[Eric Engestrom]

On Thursday, 2019-03-21 09:14:15 +0200, Tapani Pälli wrote:
> Hello;
> 
> One *very late* comment below ..
> 
> On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:
> > Some programs start with the path and command line arguments in
> > argv[0] (program_invocation_name). Chromium is an example of
> > an application using mesa that does this.
> > 
> > This tries to query the real path for the symbolic link /proc/self/exe
> > to find the program name instead. It only uses the realpath if it
> > was a prefix of the invocation to avoid breaking wine programs.
> > 
> > Cc: Timothy Arceri 
> > Signed-off-by: Nicholas Kazlauskas 
> > Reviewed-by: Eric Engestrom 
> > ---
> >   src/util/u_process.c | 23 ++-
> >   1 file changed, 22 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/util/u_process.c b/src/util/u_process.c
> > index 5e5927678d..a1667e7807 100644
> > --- a/src/util/u_process.c
> > +++ b/src/util/u_process.c
> > @@ -41,8 +41,29 @@ static const char *
> >   __getProgramName()
> >   {
> >  char * arg = strrchr(program_invocation_name, '/');
> > -   if (arg)
> > +   if (arg) {
> > +  /* If the / character was found this is likely a linux path or
> > +   * an invocation path for a 64-bit wine program.
> > +   *
> > +   * However, some programs pass command line arguments into argv[0].
> > +   * Strip these arguments out by using the realpath only if it was
> > +   * a prefix of the invocation name.
> > +   */
> > +  static char *path;
> > +
> > +  if (!path)
> > + path = realpath("/proc/self/exe", NULL);
> 
> realpath allocates memory that we will leak, it's not much but just wanted
> to mention, it might be not trivial to fix since I guess not all variants of
> __getProgramName will allocate?

Yeah, I was aware of this, but it will only be called once and will live
for the lifetime of the app, so it doesn't hurt much, and when I looked
it seemed like a hard thing to fix, so I decided to just ignore it.

If this is a problem somewhere, you can raise a bug and/or add a FIXME
comment on the line, if only to document it.
___
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

--- Comment #32 from Samuel Pitoiset  ---
Does this still happen with mesa 19.0 ?

-- 
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 110216] radv: Segfault when compiling compute shaders from Assassin's Creed Odyssey (regression, bisected)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #1 from Timothy Arceri  ---
Sorry, it's been fixed I'm waiting on someone to review the patch.

https://patchwork.freedesktop.org/patch/292850/

-- 
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 110216] radv: Segfault when compiling compute shaders from Assassin's Creed Odyssey (regression, bisected)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #2 from Timothy Arceri  ---
Fixed by:

commit 427a6fee439b2df96edc813c56572169385772a6
Author: Timothy Arceri 
Date:   Tue Mar 19 12:09:36 2019 +1100

nir: only override previous alu during loop analysis if supported

Users of this function expect alu to be a supported comparision
if the induction variable is not NULL. Since we attempt to
override the return values if the first limit is not a const, we
must make sure we are dealing with a valid comparision before
overriding the alu instruction.

Fixes an unreachable in inverse_comparison() with the game
Assasins Creed Odyssey.

Fixes: 3235a942c16b ("nir: find induction/limit vars in iand instructions")

Acked-by: Samuel Pitoiset 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110216

-- 
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] ac: fix 16-bit shifts

[Samuel Pitoiset]

This fixes the following LLVM error when ckeckir is set:
Type too small for ZExt

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_nir_to_llvm.c | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 3681c07c364..925073efb85 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -671,22 +671,31 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
result = LLVMBuildXor(ctx->ac.builder, src[0], src[1], "");
break;
case nir_op_ishl:
-   result = LLVMBuildShl(ctx->ac.builder, src[0],
- LLVMBuildZExt(ctx->ac.builder, src[1],
-   LLVMTypeOf(src[0]), ""),
- "");
+   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
+   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
+  LLVMTypeOf(src[0]), "");
+   else
+   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
+   LLVMTypeOf(src[0]), "");
+   result = LLVMBuildShl(ctx->ac.builder, src[0], src[1], "");
break;
case nir_op_ishr:
-   result = LLVMBuildAShr(ctx->ac.builder, src[0],
-  LLVMBuildZExt(ctx->ac.builder, src[1],
-LLVMTypeOf(src[0]), ""),
-  "");
+   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
+   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
+  LLVMTypeOf(src[0]), "");
+   else
+   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
+   LLVMTypeOf(src[0]), "");
+   result = LLVMBuildAShr(ctx->ac.builder, src[0], src[1], "");
break;
case nir_op_ushr:
-   result = LLVMBuildLShr(ctx->ac.builder, src[0],
-  LLVMBuildZExt(ctx->ac.builder, src[1],
-LLVMTypeOf(src[0]), ""),
-  "");
+   if (ac_get_elem_bits(>ac, LLVMTypeOf(src[1])) < 
ac_get_elem_bits(>ac, LLVMTypeOf(src[0])))
+   src[1] = LLVMBuildZExt(ctx->ac.builder, src[1],
+  LLVMTypeOf(src[0]), "");
+   else
+   src[1] = LLVMBuildTrunc(ctx->ac.builder, src[1],
+   LLVMTypeOf(src[0]), "");
+   result = LLVMBuildLShr(ctx->ac.builder, src[0], src[1], "");
break;
case nir_op_ilt32:
result = emit_int_cmp(>ac, LLVMIntSLT, src[0], src[1]);
-- 
2.21.0

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #4 from Rafael Castillo  ---
Hi, dylan your patch broke ArchLinux PKGBUILD for mesa since your patch for
some reason bypass fakeinstall paths and try to install directly in /usr/lib,
any suggestions?

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

[Mesa-dev] [PATCH] radv: enable VK_AMD_gpu_shader_half_float

[Samuel Pitoiset]

Should be safe to enable as all instructions seem to support 16-bit.
Unfortunately, there is no CTS test.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_extensions.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 421f8b926ea..23106765c2a 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -122,6 +122,7 @@ EXTENSIONS = [
 Extension('VK_EXT_vertex_attribute_divisor',  3, True),
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_gcn_shader',1, True),
+Extension('VK_AMD_gpu_shader_half_float', 1, 
'device->rad_info.chip_class >= VI && HAVE_LLVM >= 0x0800'),
 Extension('VK_AMD_rasterization_order',   1, 
'device->has_out_of_order_rast'),
 Extension('VK_AMD_shader_core_properties',1, True),
 Extension('VK_AMD_shader_info',   1, True),
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH] radv: enable VK_AMD_gpu_shader_half_float

[Bas Nieuwenhuizen]

Honestly the zero tests is worrying me. This is a pretty big extension
and I have questions like:

to 16-bit loads + 16-bit ALU actually work together or have we been
silently relying on the fact there is always a ZExt cast after and
that did not care about input size?

On Thu, Mar 21, 2019 at 10:03 AM Samuel Pitoiset
 wrote:
>
> Should be safe to enable as all instructions seem to support 16-bit.
> Unfortunately, there is no CTS test.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_extensions.py | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/amd/vulkan/radv_extensions.py 
> b/src/amd/vulkan/radv_extensions.py
> index 421f8b926ea..23106765c2a 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -122,6 +122,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>  Extension('VK_AMD_draw_indirect_count',   1, True),
>  Extension('VK_AMD_gcn_shader',1, True),
> +Extension('VK_AMD_gpu_shader_half_float', 1, 
> 'device->rad_info.chip_class >= VI && HAVE_LLVM >= 0x0800'),
>  Extension('VK_AMD_rasterization_order',   1, 
> 'device->has_out_of_order_rast'),
>  Extension('VK_AMD_shader_core_properties',1, True),
>  Extension('VK_AMD_shader_info',   1, True),
> --
> 2.21.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] ac: fix incorrect argument type for tbuffer.{load, store} with LLVM 7

[Bas Nieuwenhuizen]

r-b

On Thu, Mar 21, 2019 at 12:41 PM Samuel Pitoiset
 wrote:
>
> GLC/SLC are boolean.
>
> This fixes the following LLVM error when checkir is set:
> Intrinsic has incorrect argument type!
> void (i32, <4 x i32>, i32, i32, i32, i32, i32, i32, i32, i32)* 
> @llvm.amdgcn.tbuffer.store.i32
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 8701d2ca43a..1123dce2cc8 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -1537,8 +1537,8 @@ ac_build_tbuffer_load(struct ac_llvm_context *ctx,
> immoffset,
> LLVMConstInt(ctx->i32, dfmt, false),
> LLVMConstInt(ctx->i32, nfmt, false),
> -   LLVMConstInt(ctx->i32, glc, false),
> -   LLVMConstInt(ctx->i32, slc, false),
> +   LLVMConstInt(ctx->i1, glc, false),
> +   LLVMConstInt(ctx->i1, slc, false),
> };
> unsigned func = CLAMP(num_channels, 1, 3) - 1;
> LLVMTypeRef types[] = {ctx->i32, ctx->v2i32, ctx->v4i32};
> @@ -1699,8 +1699,8 @@ ac_build_tbuffer_store(struct ac_llvm_context *ctx,
> immoffset,
> LLVMConstInt(ctx->i32, dfmt, false),
> LLVMConstInt(ctx->i32, nfmt, false),
> -   LLVMConstInt(ctx->i32, glc, false),
> -   LLVMConstInt(ctx->i32, slc, false),
> +   LLVMConstInt(ctx->i1, glc, false),
> +   LLVMConstInt(ctx->i1, slc, false),
> };
> unsigned func = CLAMP(num_channels, 1, 3) - 1;
> const char *type_names[] = {"i32", "v2i32", "v4i32"};
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] freedreno: add ESSL cap

[Rob Clark]

Report 320 for a6xx, which isn't *quite* true (no geom/tess, in
particular), but other caps keep the reported GL and GLSL versions
correct (3.1 / 3.10 es).  But reporting 320 will switch on
EXT_gpu_shader5, which is the goal.

Signed-off-by: Rob Clark 
---
 src/gallium/drivers/freedreno/freedreno_screen.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 98f720afbf0..62f65369cc7 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -279,6 +279,13 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return 120;
return is_ir3(screen) ? 140 : 120;
 
+   case PIPE_CAP_ESSL_FEATURE_LEVEL:
+   /* we can probably enable 320 for a5xx too, but need to test: */
+   if (is_a6xx(screen)) return 320;
+   if (is_a5xx(screen)) return 310;
+   if (is_ir3(screen))  return 300;
+   return 120;
+
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
if (is_a6xx(screen)) return 64;
if (is_a5xx(screen)) return 4;
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_ESSL_FEATURE_LEVEL

[Rob Clark]

Adds a new cap to allow drivers to expose higher shading language
versions in GLES contexts, to avoid having to report an artificially
low version for the benefit of GL contexts.

The motivation is to expose EXT_gpu_shader5 even though a driver may
not support all the features needed for the corresponding GL extension
(ARB_gpu_shader5).

Signed-off-by: Rob Clark 
---
 src/gallium/auxiliary/util/u_screen.c | 4 
 src/gallium/docs/source/screen.rst| 9 +
 src/gallium/include/pipe/p_defines.h  | 1 +
 3 files changed, 14 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_screen.c 
b/src/gallium/auxiliary/util/u_screen.c
index b902c083ad4..9f0be8060ee 100644
--- a/src/gallium/auxiliary/util/u_screen.c
+++ b/src/gallium/auxiliary/util/u_screen.c
@@ -107,6 +107,10 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
*pscreen,
   /* Minimum GLSL level implemented by gallium drivers. */
   return 120;
 
+   case PIPE_CAP_ESSL_FEATURE_LEVEL:
+  /* Tell state-tracker to fallback to PIPE_CAP_GLSL_FEATURE_LEVEL */
+  return 0;
+
case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
case PIPE_CAP_USER_VERTEX_BUFFERS:
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 60ba9bcbde0..a4d6a9557c0 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -105,6 +105,15 @@ The integer capabilities:
   The only legacy features that Gallium drivers must implement are
   the legacy shader inputs and outputs (colors, texcoords, fog, clipvertex,
   edgeflag).
+* ``PIPE_CAP_ESSL_FEATURE_LEVEL``: An optional cap to allow drivers to
+  report a higher GLSL version for GLES contexts.  This is useful when a
+  driver does not support all the required features for a higher GL version,
+  but does support the required features for a higher GLES version.  A driver
+  is allowed to return ``0`` in which case ``PIPE_CAP_GLSL_FEATURE_LEVEL`` is
+  used.
+  Note that simply returning the same value as the GLSL feature level cap is
+  incorrect.  For example, GLSL version 3.30 does not require 
``ARB_gpu_shader5``,
+  but ESSL version 3.20 es does require ``EXT_gpu_shader5``
 * ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads adhere 
to
   the flatshade_first setting in ``pipe_rasterizer_state``.
 * ``PIPE_CAP_USER_VERTEX_BUFFERS``: Whether the driver supports user vertex
diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index ebc44d7a75e..3dbdea035e4 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -718,6 +718,7 @@ enum pipe_cap
PIPE_CAP_VERTEX_COLOR_CLAMPED,
PIPE_CAP_GLSL_FEATURE_LEVEL,
PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY,
+   PIPE_CAP_ESSL_FEATURE_LEVEL,
PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION,
PIPE_CAP_USER_VERTEX_BUFFERS,
PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY,
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5

[Rob Clark]

For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
sufficiently high ESSL feature level, even if the GLSL feature level
isn't high enough.

This allows drivers to support EXT_gpu_shader5 in GLES contexts before
they support all the additional features of ARB_gpu_shader5 in GL
contexts.

We can also use this cap to enable ARB_ES3_1_compatibility.

Signed-off-by: Rob Clark 
---
 src/mesa/state_tracker/st_extensions.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index c953bfd9f7a..92450d88acf 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
consts->GLSLVersionCompat =
   screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
 
+   const unsigned ESSLVersion =
+  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
const unsigned GLSLVersion =
   api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
  consts->GLSLVersion;
@@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
 
consts->AllowGLSLCrossStageInterpolationMismatch = 
options->allow_glsl_cross_stage_interpolation_mismatch;
 
+   /* Technically we are turning on the EXT_gpu_shader5 extension,
+* ARB_gpu_shader5 does not exist in GLES, but this flag is what
+* switches on EXT_gpu_shader5:
+*/
+   if (api == API_OPENGLES2 && ESSLVersion >= 320)
+  extensions->ARB_gpu_shader5 = GL_TRUE;
+
if (GLSLVersion >= 400)
   extensions->ARB_gpu_shader5 = GL_TRUE;
if (GLSLVersion >= 410)
@@ -1539,6 +1548,9 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->ARB_gpu_shader5 &&
   extensions->EXT_shader_integer_mix;
 
+   if (ESSLVersion >= 310)
+  extensions->ARB_ES3_1_compatibility = GL__TRUE;
+
extensions->OES_texture_cube_map_array =
   extensions->ARB_ES3_1_compatibility &&
   extensions->OES_geometry_shader &&
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Józef Kucia]

On Thu, Mar 21, 2019 at 1:24 PM Tapani Pälli  wrote:
> Yeah, checked that value matches of find_value_indexed;
>
> Reviewed-by: Tapani Pälli 

I don't have commits rights. Please push the patch for me.

> Does this affect 'ext_semaphore-api-errors' Piglit test that calls this
> in any way?

No. Before the patch numDevices is 0 and 1 is invalid index anyway.

glGetUnsignedBytei_vEXT(GL_DEVICE_UUID_EXT, numDevices + 1, data);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swr: Fix build with llvm-9.0.

[Hota, Alok]

Reviewed-by: Alok Hota l

> -Original Message-
> From: Vinson Lee [mailto:v...@freedesktop.org]
> Sent: Monday, March 18, 2019 2:11 PM
> To: Kyriazis, George ; Hota, Alok
> 
> Cc: Philip Meulengracht ; mesa-
> d...@lists.freedesktop.org
> Subject: [PATCH] swr: Fix build with llvm-9.0.
> 
> Fix build error after llvm-9.0svn r352827 ("[opaque pointer types] Add a
> FunctionCallee wrapper type, and use it.").
> 
> In file included from ./rasterizer/jitter/builder.h:158:0,
>  from swr_shader.cpp:35:
> ./rasterizer/jitter/gen_builder_meta.hpp: In member function ‘llvm::Value*
> SwrJit::Builder::VGATHERPD(llvm::Value*, llvm::Value*, llvm::Value*,
> llvm::Value*, llvm::Value*, const llvm:
> :Twine&)’:
> ./rasterizer/jitter/gen_builder_meta.hpp:51:117: error: no matching function
> for call to ‘cast(llvm::FunctionCallee)’
>  Function* pFunc = cast(JM()->mpCurrentModule-
> >getOrInsertFunction("meta.intrinsic.VGATHERPD", pFuncTy));
>   
>^
> 
> Suggested-by: Philip Meulengracht 
> Signed-off-by: Vinson Lee 
> ---
>  .../codegen/templates/gen_builder.hpp |  4 
>  .../swr/rasterizer/jitter/builder_misc.cpp| 20 +++
>  2 files changed, 24 insertions(+)
> 
> diff --git
> a/src/gallium/drivers/swr/rasterizer/codegen/templates/gen_builder.hpp
> b/src/gallium/drivers/swr/rasterizer/codegen/templates/gen_builder.hpp
> index 5182bc4259f0..a59fb10902b9 100644
> ---
> a/src/gallium/drivers/swr/rasterizer/codegen/templates/gen_builder.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/codegen/templates/gen_builder.h
> +++ pp
> @@ -50,7 +50,11 @@ ${func['decl']}
>  %else:
>  FunctionType* pFuncTy = FunctionType::get(${ func['returnType'] }, {},
> false);
>  %endif:
> +#if LLVM_VERSION_MAJOR >= 9
> +Function* pFunc =
> +cast(JM()->mpCurrentModule-
> >getOrInsertFunction("meta.intrins
> +ic.${func['name']}", pFuncTy).getCallee()); #else
>  Function* pFunc = cast(JM()->mpCurrentModule-
> >getOrInsertFunction("meta.intrinsic.${func['name']}", pFuncTy));
> +#endif
>  return CALL(pFunc, std::initializer_list{${argList}}, name);  
> %elif
> isIntrin:
>  %if len(func['types']) != 0:
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_misc.cpp
> b/src/gallium/drivers/swr/rasterizer/jitter/builder_misc.cpp
> index 24b733a28ae8..93a30b2cb452 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/builder_misc.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_misc.cpp
> @@ -445,7 +445,11 @@ namespace SwrJit
>  args.push_back(PointerType::get(mInt8Ty, 0));
>  FunctionType* callPrintTy = FunctionType::get(Type::getVoidTy(JM()-
> >mContext), args, true);
>  Function* callPrintFn =
> +#if LLVM_VERSION_MAJOR >= 9
> +
> +cast(JM()->mpCurrentModule->getOrInsertFunction("CallPrint",
> +callPrintTy).getCallee()); #else
>  cast(JM()->mpCurrentModule-
> >getOrInsertFunction("CallPrint", callPrintTy));
> +#endif
> 
>  // if we haven't yet added the symbol to the symbol table
>  if ((sys::DynamicLibrary::SearchForAddressOfSymbol("CallPrint")) ==
> nullptr) @@ -614,7 +618,11 @@ namespace SwrJit
>  {
>  FunctionType* pFuncTy   = FunctionType::get(mFP32Ty, mInt16Ty);
>  Function* pCvtPh2Ps = cast(
> +#if LLVM_VERSION_MAJOR >= 9
> +
> +JM()->mpCurrentModule-
> >getOrInsertFunction("ConvertFloat16ToFloat32",
> +pFuncTy).getCallee()); #else
>  JM()->mpCurrentModule-
> >getOrInsertFunction("ConvertFloat16ToFloat32", pFuncTy));
> +#endif
> 
>  if
> (sys::DynamicLibrary::SearchForAddressOfSymbol("ConvertFloat16ToFloat32
> ") == nullptr)
>  {
> @@ -650,7 +658,11 @@ namespace SwrJit
>  // call scalar C function for now
>  FunctionType* pFuncTy   = FunctionType::get(mInt16Ty, mFP32Ty);
>  Function* pCvtPs2Ph = cast(
> +#if LLVM_VERSION_MAJOR >= 9
> +
> +JM()->mpCurrentModule-
> >getOrInsertFunction("ConvertFloat32ToFloat16",
> +pFuncTy).getCallee()); #else
>  JM()->mpCurrentModule-
> >getOrInsertFunction("ConvertFloat32ToFloat16", pFuncTy));
> +#endif
> 
>  if
> (sys::DynamicLibrary::SearchForAddressOfSymbol("ConvertFloat32ToFloat16
> ") == nullptr)
>  {
> @@ -928,7 +940,11 @@ namespace SwrJit
> 
>  FunctionType* pFuncTy = FunctionType::get(Type::getVoidTy(JM()-
> >mContext), args, false);
>  Function* pFunc   = cast(
> +#if LLVM_VERSION_MAJOR >= 9
> +
> +JM()->mpCurrentModule-
> >getOrInsertFunction("BucketManager_StartBucket",
> +pFuncTy).getCallee()); #else
>  JM()->mpCurrentModule-
> >getOrInsertFunction("BucketManager_StartBucket", pFuncTy));
> +#endif
>  if
> (sys::DynamicLibrary::SearchForAddressOfSymbol("BucketManager_StartBu
> cket") ==
>  nullptr)
>  

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5

[Rob Clark]

On Thu, Mar 21, 2019 at 10:09 AM Ilia Mirkin  wrote:
>
> On Thu, Mar 21, 2019 at 9:55 AM Rob Clark  wrote:
> >
> > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > sufficiently high ESSL feature level, even if the GLSL feature level
> > isn't high enough.
> >
> > This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> > they support all the additional features of ARB_gpu_shader5 in GL
> > contexts.
> >
> > We can also use this cap to enable ARB_ES3_1_compatibility.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  src/mesa/state_tracker/st_extensions.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c 
> > b/src/mesa/state_tracker/st_extensions.c
> > index c953bfd9f7a..92450d88acf 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> > consts->GLSLVersionCompat =
> >screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
> >
> > +   const unsigned ESSLVersion =
> > +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> > const unsigned GLSLVersion =
> >api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
> >   consts->GLSLVersion;
> > @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
> >
> > consts->AllowGLSLCrossStageInterpolationMismatch = 
> > options->allow_glsl_cross_stage_interpolation_mismatch;
> >
> > +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> > +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> > +* switches on EXT_gpu_shader5:
> > +*/
> > +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> > +  extensions->ARB_gpu_shader5 = GL_TRUE;
> > +
> > if (GLSLVersion >= 400)
> >extensions->ARB_gpu_shader5 = GL_TRUE;
> > if (GLSLVersion >= 410)
> > @@ -1539,6 +1548,9 @@ void st_init_extensions(struct pipe_screen *screen,
> >extensions->ARB_gpu_shader5 &&
> >extensions->EXT_shader_integer_mix;
> >
> > +   if (ESSLVersion >= 310)
> > +  extensions->ARB_ES3_1_compatibility = GL__TRUE;
>
> I'd make this also conditional on api == API_OPENGLES2 as well. This
> extension nominally requires GL 4.4, and I think it'd be VERY awkward
> to provide prior to GL 4.0 (which includes ARB_gpu_shader5 as a
> component of it).

hmm, I'd just added this since I noticed this extension went away
compared to my earlier hack soln of reporting 400 for the GSLS feature
level cap.  (Maybe that is a separate bug that it was getting exposed
despite only exposing GL 3.1?)  At any rate, I guess this extension
doesn't exist in GLES contexts, so I can just drop this hunk.

It is kinda lols that a driver can support GLES 3.1 but not a high
enough GL version to expose the ES3_1_compat extensions..

BR,
-R

>
> Sorry for leaving a bit of a mess with ARB_gpu_shader5 enablement.
> It's just a _lot_ of different features, and it was daunting to add
> checks for every bit of it. Looking again, I don't think the situation
> has changed much. OES_gpu_shader5 is a small subset of ARB_gpu_shader5
> (a lot of the bits are in core ESSL 3.10, some are in various
> OES_multisample-related exts), but it's still a lot of unrelated and
> annoying-to-describe things. So I think your current approach, or a
> variant of it, is definitely the right way forward.
>
> Cheers,
>
>   -ilia
>
>
>   -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #8 from Pierre Labastie  ---
(In reply to Benoit Pierre from comment #6)
> Created attachment 143747 [details] [review]
> fix DESTDIR handling in install_megadrivers.py
> 
> This how I fixed it locally. I only tested the PKGBUILD on Arch Linux (so
> with DESTDIR set). I tried to ensure Windows is correctly supported to (with
> the correct drive being used in all cases).

Looks like your patch comes back to the original issue:
This is Ok if DESTDIR is not set, or if DESTDIR is set to a non empty string,
but not if DESTDIR is set to an empty string. Note that this is because
os.path.join is not consistent:
a slash is inserted when doing os.path.join('a','b'), but not when doing
os.path.joint('','b')!

Note that the fix I proposed is bad (sorry): 
if you do, for instance, "to = os.path.join('/sources/install','/usr/lib/dri')"
in python, then "to" is set to '/usr/lib/dri'... My bad (I thought I had
tried).

Maybe something like (I'm not sure what to do with win32):
---
if os.path.isabs(args.libdir):
destdir=os.environ.get('DESTDIR','')
if len(destdir) == 0:
destdir = '/'
to = os.path.join(destdir, args.libdir[1:])
  else:
...

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #9 from Dylan Baker  ---
---
if os.path.isabs(args.libdir):
destdir=os.environ.get('DESTDIR','')
if len(destdir) == 0:
destdir = '/'
to = os.path.join(destdir, args.libdir[1:])
  else:
...

Don't use len there, len() for testing emptiness is a python antipattern :)

just `if not destdir:`

However, I think doing something like

destdir = os.environ.get('DESTDIR')
to = args.libdir
if destdir
to = os.path.join(destdir, to)

is probably sufficient.

Just FYI, we don't do patch review in bugzilla, if you'd like to propose a
patch either an MR at gitlab.freedesktop.org/mesa/mesa or a patch sent to
mesa-dev@lists.freedesktop.org is the proper way.

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #10 from Luke A. Guest  ---
(In reply to Dylan Baker from comment #9)
> ---
> if os.path.isabs(args.libdir):
> destdir=os.environ.get('DESTDIR','')
> if len(destdir) == 0:
> destdir = '/'
> to = os.path.join(destdir, args.libdir[1:])
>   else:
> ...

This fixes it for me.

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

Re: [Mesa-dev] [PATCH 1/2] softpipe: fix 32-bit bitfield extract

[Brian Paul]

All four patches look good to me

Reviewed-by: Brian Paul 

On 03/20/2019 10:16 PM, Dave Airlie wrote:

From: Dave Airlie 

These didn't deal with the width == 32 case that TGSI is defined with.

Fixes piglit tests if ARB_gpu_shader5 is enabled.
---
  src/gallium/auxiliary/tgsi/tgsi_exec.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index e1181aa1932..c93e4e26e40 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -4944,8 +4944,13 @@ micro_ibfe(union tgsi_exec_channel *dst,
  {
 int i;
 for (i = 0; i < 4; i++) {
-  int width = src2->i[i] & 0x1f;
+  int width = src2->i[i];
int offset = src1->i[i] & 0x1f;
+  if (width == 32 && offset == 0) {
+ dst->i[i] = src0->i[i];
+ continue;
+  }
+  width &= 0x1f;
if (width == 0)
   dst->i[i] = 0;
else if (width + offset < 32)
@@ -4966,8 +4971,13 @@ micro_ubfe(union tgsi_exec_channel *dst,
  {
 int i;
 for (i = 0; i < 4; i++) {
-  int width = src2->u[i] & 0x1f;
+  int width = src2->u[i];
int offset = src1->u[i] & 0x1f;
+  if (width == 32 && offset == 0) {
+ dst->u[i] = src0->u[i];
+ continue;
+  }
+  width &= 0x1f;
if (width == 0)
   dst->u[i] = 0;
else if (width + offset < 32)



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

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5

[Ilia Mirkin]

On Thu, Mar 21, 2019 at 10:18 AM Rob Clark  wrote:
>
> On Thu, Mar 21, 2019 at 10:09 AM Ilia Mirkin  wrote:
> >
> > On Thu, Mar 21, 2019 at 9:55 AM Rob Clark  wrote:
> > >
> > > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > > sufficiently high ESSL feature level, even if the GLSL feature level
> > > isn't high enough.
> > >
> > > This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> > > they support all the additional features of ARB_gpu_shader5 in GL
> > > contexts.
> > >
> > > We can also use this cap to enable ARB_ES3_1_compatibility.
> > >
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  src/mesa/state_tracker/st_extensions.c | 12 
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/src/mesa/state_tracker/st_extensions.c 
> > > b/src/mesa/state_tracker/st_extensions.c
> > > index c953bfd9f7a..92450d88acf 100644
> > > --- a/src/mesa/state_tracker/st_extensions.c
> > > +++ b/src/mesa/state_tracker/st_extensions.c
> > > @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> > > consts->GLSLVersionCompat =
> > >screen->get_param(screen, 
> > > PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
> > >
> > > +   const unsigned ESSLVersion =
> > > +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> > > const unsigned GLSLVersion =
> > >api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
> > >   consts->GLSLVersion;
> > > @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
> > >
> > > consts->AllowGLSLCrossStageInterpolationMismatch = 
> > > options->allow_glsl_cross_stage_interpolation_mismatch;
> > >
> > > +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> > > +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> > > +* switches on EXT_gpu_shader5:
> > > +*/
> > > +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> > > +  extensions->ARB_gpu_shader5 = GL_TRUE;
> > > +
> > > if (GLSLVersion >= 400)
> > >extensions->ARB_gpu_shader5 = GL_TRUE;
> > > if (GLSLVersion >= 410)
> > > @@ -1539,6 +1548,9 @@ void st_init_extensions(struct pipe_screen *screen,
> > >extensions->ARB_gpu_shader5 &&
> > >extensions->EXT_shader_integer_mix;
> > >
> > > +   if (ESSLVersion >= 310)
> > > +  extensions->ARB_ES3_1_compatibility = GL__TRUE;
> >
> > I'd make this also conditional on api == API_OPENGLES2 as well. This
> > extension nominally requires GL 4.4, and I think it'd be VERY awkward
> > to provide prior to GL 4.0 (which includes ARB_gpu_shader5 as a
> > component of it).
>
> hmm, I'd just added this since I noticed this extension went away
> compared to my earlier hack soln of reporting 400 for the GSLS feature
> level cap.  (Maybe that is a separate bug that it was getting exposed
> despite only exposing GL 3.1?)  At any rate, I guess this extension
> doesn't exist in GLES contexts, so I can just drop this hunk.

I think stuff further down depends on this bit being enabled, so you
do need it. It's used as a proxy for "at least ESSL 3.10" further
down. It's a bit circular since the exts determine the version, but
some exts kinda want to know that at least some version is supported.
So I ended up using proxies for "the GL version" by saying
"ES3_1_compat" is supported. But you could flip that to the
ESSLVersion instead.

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

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5

[Ilia Mirkin]

On Thu, Mar 21, 2019 at 9:55 AM Rob Clark  wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
> This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> they support all the additional features of ARB_gpu_shader5 in GL
> contexts.
>
> We can also use this cap to enable ARB_ES3_1_compatibility.
>
> Signed-off-by: Rob Clark 
> ---
>  src/mesa/state_tracker/st_extensions.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index c953bfd9f7a..92450d88acf 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> consts->GLSLVersionCompat =
>screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
>
> +   const unsigned ESSLVersion =
> +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> const unsigned GLSLVersion =
>api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
>   consts->GLSLVersion;
> @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
>
> consts->AllowGLSLCrossStageInterpolationMismatch = 
> options->allow_glsl_cross_stage_interpolation_mismatch;
>
> +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> +* switches on EXT_gpu_shader5:
> +*/
> +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> +  extensions->ARB_gpu_shader5 = GL_TRUE;
> +
> if (GLSLVersion >= 400)
>extensions->ARB_gpu_shader5 = GL_TRUE;
> if (GLSLVersion >= 410)
> @@ -1539,6 +1548,9 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->ARB_gpu_shader5 &&
>extensions->EXT_shader_integer_mix;
>
> +   if (ESSLVersion >= 310)
> +  extensions->ARB_ES3_1_compatibility = GL__TRUE;

I'd make this also conditional on api == API_OPENGLES2 as well. This
extension nominally requires GL 4.4, and I think it'd be VERY awkward
to provide prior to GL 4.0 (which includes ARB_gpu_shader5 as a
component of it).

Sorry for leaving a bit of a mess with ARB_gpu_shader5 enablement.
It's just a _lot_ of different features, and it was daunting to add
checks for every bit of it. Looking again, I don't think the situation
has changed much. OES_gpu_shader5 is a small subset of ARB_gpu_shader5
(a lot of the bits are in core ESSL 3.10, some are in various
OES_multisample-related exts), but it's still a lot of unrelated and
annoying-to-describe things. So I think your current approach, or a
variant of it, is definitely the right way forward.

Cheers,

  -ilia


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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #7 from Denis  ---
agree, also faced with this issue. Reproduced it on Ubuntu 18.04 and Manjaro.

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #11 from Dylan Baker  ---
Have a look at this MR, which is basically the same patch with some style
cleanups:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/505

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

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v2)

[Rob Clark]

On Thu, Mar 21, 2019 at 2:19 PM Ilia Mirkin  wrote:
>
> On Thu, Mar 21, 2019 at 1:45 PM Rob Clark  wrote:
> >
> > For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> > sufficiently high ESSL feature level, even if the GLSL feature level
> > isn't high enough.
> >
> > This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> > they support all the additional features of ARB_gpu_shader5 in GL
> > contexts.
> >
> > We can also use this cap to enable ARB_ES3_1_compatibility.
>
> I believe this is no longer the case, so probably remove that line.
> Also, all the cool people talk about the OES_* variants of the exts...
> Doesn't really matter, of course. They're identical.
>
> >
> > Signed-off-by: Rob Clark 
> > ---
> > This kinda morphed into also fixing OES_viewport_array (which should
> > depend on GLES 3.2)
> >
> >  src/mesa/state_tracker/st_extensions.c | 24 +---
> >  1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/src/mesa/state_tracker/st_extensions.c 
> > b/src/mesa/state_tracker/st_extensions.c
> > index c953bfd9f7a..7c3b98c1ba6 100644
> > --- a/src/mesa/state_tracker/st_extensions.c
> > +++ b/src/mesa/state_tracker/st_extensions.c
> > @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> > consts->GLSLVersionCompat =
> >screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
> >
> > +   const unsigned ESSLVersion =
> > +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> > const unsigned GLSLVersion =
> >api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
> >   consts->GLSLVersion;
> > @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
> >
> > consts->AllowGLSLCrossStageInterpolationMismatch = 
> > options->allow_glsl_cross_stage_interpolation_mismatch;
> >
> > +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> > +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> > +* switches on EXT_gpu_shader5:
> > +*/
> > +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> > +  extensions->ARB_gpu_shader5 = GL_TRUE;
> > +
> > if (GLSLVersion >= 400)
> >extensions->ARB_gpu_shader5 = GL_TRUE;
> > if (GLSLVersion >= 410)
> > @@ -1540,16 +1549,12 @@ void st_init_extensions(struct pipe_screen *screen,
> >extensions->EXT_shader_integer_mix;
> >
> > extensions->OES_texture_cube_map_array =
> > -  extensions->ARB_ES3_1_compatibility &&
> > +  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
>
> It's a bit more work, but if you get all the drivers to properly
> expose this cap, you could make this *just* ESSLVersion >= x, instead
> of also relying on the ARB_* thing. Totally your call, just wanted to
> make the observation.
>
> >extensions->OES_geometry_shader &&
> >extensions->ARB_texture_cube_map_array;
> >
> > -   extensions->OES_viewport_array =
> > -  extensions->ARB_ES3_1_compatibility &&
> > -  extensions->OES_geometry_shader &&
> > -  extensions->ARB_viewport_array;
> > -
> > -   extensions->OES_primitive_bounding_box = 
> > extensions->ARB_ES3_1_compatibility;
> > +   extensions->OES_primitive_bounding_box =
> > +  extensions->ARB_ES3_1_compatibility || (ESSLVersion >= 310);
> > consts->NoPrimitiveBoundingBoxOutput = true;
> >
> > extensions->ANDROID_extension_pack_es31a =
> > @@ -1590,6 +1595,11 @@ void st_init_extensions(struct pipe_screen *screen,
> >extensions->ARB_texture_stencil8 &&
> >extensions->ARB_texture_multisample;
> >
> > +   extensions->OES_viewport_array =
> > +  (extensions->ARB_ES3_2_compatibility || ESSLVersion >= 320) &&
>
> Why is this getting bumped up to needing ES 3.2? Did you mean to leave
> this at ES3_1_compat || ESSL >= 310?
>
> "OpenGL ES 3.2, EXT_geometry_shader or OES_geometry_shader is
> required." (Note the "or". Otherwise it'd make no sense since ES 3.2
> includes geometry shaders as core functionality.)

yeah, moving it was intentional, but maybe based on mis-parsing the
spec dependencies and applying the 'C' order of operator precedence to
english.. :-P

BR,
-R

>
>
> > +  extensions->OES_geometry_shader &&
> > +  extensions->ARB_viewport_array;
> > +
> > if (screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES) &&
> > screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES) &&
> > screen->get_param(screen, 
> > PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE)) {
> > --
> > 2.20.1
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] drm-shim for faking GEM drivers using simulators or noop.

[Eric Anholt]

I've just put up a new repo that I'm hoping to use to enable automatic
shader-db results for various drivers on Gitlab CI merge requests (and
maybe with some more work, delete the simulator backends of vc4 and v3d).

https://gitlab.freedesktop.org/anholt/drm-shim

I've copied a bit of Mesa stuff out for convenience, but that ends up
actually being most of the code in the repo since it's not really that
much work.  Alternatively, I have a branch of most of it, inside of
Mesa, if we wanted to just add it in as one of the tools.

Does anyone have any strong feelings about where it should go?
mesa/mesa, mesa/drm-shim, or anholt/drm-shim?


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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #6 from Benoit Pierre  ---
Created attachment 143747
  --> https://bugs.freedesktop.org/attachment.cgi?id=143747=edit
fix DESTDIR handling in install_megadrivers.py

This how I fixed it locally. I only tested the PKGBUILD on Arch Linux (so with
DESTDIR set). I tried to ensure Windows is correctly supported to (with the
correct drive being used in all cases).

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

Re: [Mesa-dev] [PATCH] mesa: Fix GL_NUM_DEVICE_UUIDS_EXT

[Tapani Pälli]

On 3/21/19 4:03 PM, Józef Kucia wrote:

On Thu, Mar 21, 2019 at 1:24 PM Tapani Pälli  wrote:

Yeah, checked that value matches of find_value_indexed;

Reviewed-by: Tapani Pälli 


I don't have commits rights. Please push the patch for me.


sure


Does this affect 'ext_semaphore-api-errors' Piglit test that calls this
in any way?


No. Before the patch numDevices is 0 and 1 is invalid index anyway.

glGetUnsignedBytei_vEXT(GL_DEVICE_UUID_EXT, numDevices + 1, data);



Right :/ I find it a bit bad that the return value is not checked at 
all, maybe should update that test, ideally it would have caught this one.


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

[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v2)

[Rob Clark]

For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
sufficiently high ESSL feature level, even if the GLSL feature level
isn't high enough.

This allows drivers to support EXT_gpu_shader5 in GLES contexts before
they support all the additional features of ARB_gpu_shader5 in GL
contexts.

We can also use this cap to enable ARB_ES3_1_compatibility.

Signed-off-by: Rob Clark 
---
This kinda morphed into also fixing OES_viewport_array (which should
depend on GLES 3.2)

 src/mesa/state_tracker/st_extensions.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index c953bfd9f7a..7c3b98c1ba6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
consts->GLSLVersionCompat =
   screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
 
+   const unsigned ESSLVersion =
+  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
const unsigned GLSLVersion =
   api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
  consts->GLSLVersion;
@@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
 
consts->AllowGLSLCrossStageInterpolationMismatch = 
options->allow_glsl_cross_stage_interpolation_mismatch;
 
+   /* Technically we are turning on the EXT_gpu_shader5 extension,
+* ARB_gpu_shader5 does not exist in GLES, but this flag is what
+* switches on EXT_gpu_shader5:
+*/
+   if (api == API_OPENGLES2 && ESSLVersion >= 320)
+  extensions->ARB_gpu_shader5 = GL_TRUE;
+
if (GLSLVersion >= 400)
   extensions->ARB_gpu_shader5 = GL_TRUE;
if (GLSLVersion >= 410)
@@ -1540,16 +1549,12 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->EXT_shader_integer_mix;
 
extensions->OES_texture_cube_map_array =
-  extensions->ARB_ES3_1_compatibility &&
+  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
   extensions->OES_geometry_shader &&
   extensions->ARB_texture_cube_map_array;
 
-   extensions->OES_viewport_array =
-  extensions->ARB_ES3_1_compatibility &&
-  extensions->OES_geometry_shader &&
-  extensions->ARB_viewport_array;
-
-   extensions->OES_primitive_bounding_box = 
extensions->ARB_ES3_1_compatibility;
+   extensions->OES_primitive_bounding_box =
+  extensions->ARB_ES3_1_compatibility || (ESSLVersion >= 310);
consts->NoPrimitiveBoundingBoxOutput = true;
 
extensions->ANDROID_extension_pack_es31a =
@@ -1590,6 +1595,11 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->ARB_texture_stencil8 &&
   extensions->ARB_texture_multisample;
 
+   extensions->OES_viewport_array =
+  (extensions->ARB_ES3_2_compatibility || ESSLVersion >= 320) &&
+  extensions->OES_geometry_shader &&
+  extensions->ARB_viewport_array;
+
if (screen->get_param(screen, 
PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES) &&
screen->get_param(screen, 
PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES) &&
screen->get_param(screen, 
PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE)) {
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v2)

[Ilia Mirkin]

On Thu, Mar 21, 2019 at 1:45 PM Rob Clark  wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
> This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> they support all the additional features of ARB_gpu_shader5 in GL
> contexts.
>
> We can also use this cap to enable ARB_ES3_1_compatibility.

I believe this is no longer the case, so probably remove that line.
Also, all the cool people talk about the OES_* variants of the exts...
Doesn't really matter, of course. They're identical.

>
> Signed-off-by: Rob Clark 
> ---
> This kinda morphed into also fixing OES_viewport_array (which should
> depend on GLES 3.2)
>
>  src/mesa/state_tracker/st_extensions.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index c953bfd9f7a..7c3b98c1ba6 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> consts->GLSLVersionCompat =
>screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
>
> +   const unsigned ESSLVersion =
> +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> const unsigned GLSLVersion =
>api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
>   consts->GLSLVersion;
> @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
>
> consts->AllowGLSLCrossStageInterpolationMismatch = 
> options->allow_glsl_cross_stage_interpolation_mismatch;
>
> +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> +* switches on EXT_gpu_shader5:
> +*/
> +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> +  extensions->ARB_gpu_shader5 = GL_TRUE;
> +
> if (GLSLVersion >= 400)
>extensions->ARB_gpu_shader5 = GL_TRUE;
> if (GLSLVersion >= 410)
> @@ -1540,16 +1549,12 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->EXT_shader_integer_mix;
>
> extensions->OES_texture_cube_map_array =
> -  extensions->ARB_ES3_1_compatibility &&
> +  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&

It's a bit more work, but if you get all the drivers to properly
expose this cap, you could make this *just* ESSLVersion >= x, instead
of also relying on the ARB_* thing. Totally your call, just wanted to
make the observation.

>extensions->OES_geometry_shader &&
>extensions->ARB_texture_cube_map_array;
>
> -   extensions->OES_viewport_array =
> -  extensions->ARB_ES3_1_compatibility &&
> -  extensions->OES_geometry_shader &&
> -  extensions->ARB_viewport_array;
> -
> -   extensions->OES_primitive_bounding_box = 
> extensions->ARB_ES3_1_compatibility;
> +   extensions->OES_primitive_bounding_box =
> +  extensions->ARB_ES3_1_compatibility || (ESSLVersion >= 310);
> consts->NoPrimitiveBoundingBoxOutput = true;
>
> extensions->ANDROID_extension_pack_es31a =
> @@ -1590,6 +1595,11 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->ARB_texture_stencil8 &&
>extensions->ARB_texture_multisample;
>
> +   extensions->OES_viewport_array =
> +  (extensions->ARB_ES3_2_compatibility || ESSLVersion >= 320) &&

Why is this getting bumped up to needing ES 3.2? Did you mean to leave
this at ES3_1_compat || ESSL >= 310?

"OpenGL ES 3.2, EXT_geometry_shader or OES_geometry_shader is
required." (Note the "or". Otherwise it'd make no sense since ES 3.2
includes geometry shaders as core functionality.)


> +  extensions->OES_geometry_shader &&
> +  extensions->ARB_viewport_array;
> +
> if (screen->get_param(screen, 
> PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_TRIANGLES) &&
> screen->get_param(screen, 
> PIPE_CAP_CONSERVATIVE_RASTER_POST_SNAP_POINTS_LINES) &&
> screen->get_param(screen, 
> PIPE_CAP_CONSERVATIVE_RASTER_POST_DEPTH_COVERAGE)) {
> --
> 2.20.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] gallium: add PIPE_CAP_ESSL_FEATURE_LEVEL

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

On Thu, Mar 21, 2019 at 9:55 AM Rob Clark  wrote:
>
> Adds a new cap to allow drivers to expose higher shading language
> versions in GLES contexts, to avoid having to report an artificially
> low version for the benefit of GL contexts.
>
> The motivation is to expose EXT_gpu_shader5 even though a driver may
> not support all the features needed for the corresponding GL extension
> (ARB_gpu_shader5).
>
> Signed-off-by: Rob Clark 
> ---
>  src/gallium/auxiliary/util/u_screen.c | 4 
>  src/gallium/docs/source/screen.rst| 9 +
>  src/gallium/include/pipe/p_defines.h  | 1 +
>  3 files changed, 14 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_screen.c 
> b/src/gallium/auxiliary/util/u_screen.c
> index b902c083ad4..9f0be8060ee 100644
> --- a/src/gallium/auxiliary/util/u_screen.c
> +++ b/src/gallium/auxiliary/util/u_screen.c
> @@ -107,6 +107,10 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
> *pscreen,
>/* Minimum GLSL level implemented by gallium drivers. */
>return 120;
>
> +   case PIPE_CAP_ESSL_FEATURE_LEVEL:
> +  /* Tell state-tracker to fallback to PIPE_CAP_GLSL_FEATURE_LEVEL */
> +  return 0;
> +
> case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION:
> case PIPE_CAP_USER_VERTEX_BUFFERS:
> case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index 60ba9bcbde0..a4d6a9557c0 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -105,6 +105,15 @@ The integer capabilities:
>The only legacy features that Gallium drivers must implement are
>the legacy shader inputs and outputs (colors, texcoords, fog, clipvertex,
>edgeflag).
> +* ``PIPE_CAP_ESSL_FEATURE_LEVEL``: An optional cap to allow drivers to
> +  report a higher GLSL version for GLES contexts.  This is useful when a
> +  driver does not support all the required features for a higher GL version,
> +  but does support the required features for a higher GLES version.  A driver
> +  is allowed to return ``0`` in which case ``PIPE_CAP_GLSL_FEATURE_LEVEL`` is
> +  used.
> +  Note that simply returning the same value as the GLSL feature level cap is
> +  incorrect.  For example, GLSL version 3.30 does not require 
> ``ARB_gpu_shader5``,
> +  but ESSL version 3.20 es does require ``EXT_gpu_shader5``
>  * ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION``: Whether quads 
> adhere to
>the flatshade_first setting in ``pipe_rasterizer_state``.
>  * ``PIPE_CAP_USER_VERTEX_BUFFERS``: Whether the driver supports user vertex
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index ebc44d7a75e..3dbdea035e4 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -718,6 +718,7 @@ enum pipe_cap
> PIPE_CAP_VERTEX_COLOR_CLAMPED,
> PIPE_CAP_GLSL_FEATURE_LEVEL,
> PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY,
> +   PIPE_CAP_ESSL_FEATURE_LEVEL,
> PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION,
> PIPE_CAP_USER_VERTEX_BUFFERS,
> PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY,
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v3)

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

Thanks for bearing with my nits.

On Thu, Mar 21, 2019 at 2:43 PM Rob Clark  wrote:
>
> For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
> sufficiently high ESSL feature level, even if the GLSL feature level
> isn't high enough.
>
> This allows drivers to support EXT_gpu_shader5 in GLES contexts before
> they support all the additional features of ARB_gpu_shader5 in GL
> contexts.
>
> Signed-off-by: Rob Clark 
> ---
>  src/mesa/state_tracker/st_extensions.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index c953bfd9f7a..405fc21b3ad 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
> consts->GLSLVersionCompat =
>screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
>
> +   const unsigned ESSLVersion =
> +  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
> const unsigned GLSLVersion =
>api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
>   consts->GLSLVersion;
> @@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
>
> consts->AllowGLSLCrossStageInterpolationMismatch = 
> options->allow_glsl_cross_stage_interpolation_mismatch;
>
> +   /* Technically we are turning on the EXT_gpu_shader5 extension,
> +* ARB_gpu_shader5 does not exist in GLES, but this flag is what
> +* switches on EXT_gpu_shader5:
> +*/
> +   if (api == API_OPENGLES2 && ESSLVersion >= 320)
> +  extensions->ARB_gpu_shader5 = GL_TRUE;
> +
> if (GLSLVersion >= 400)
>extensions->ARB_gpu_shader5 = GL_TRUE;
> if (GLSLVersion >= 410)
> @@ -1540,16 +1549,18 @@ void st_init_extensions(struct pipe_screen *screen,
>extensions->EXT_shader_integer_mix;
>
> extensions->OES_texture_cube_map_array =
> -  extensions->ARB_ES3_1_compatibility &&
> +  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
>extensions->OES_geometry_shader &&
>extensions->ARB_texture_cube_map_array;
>
> extensions->OES_viewport_array =
> -  extensions->ARB_ES3_1_compatibility &&
> +  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
>extensions->OES_geometry_shader &&
>extensions->ARB_viewport_array;
>
> -   extensions->OES_primitive_bounding_box = 
> extensions->ARB_ES3_1_compatibility;
> +   extensions->OES_primitive_bounding_box =
> +  extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310;
> +
> consts->NoPrimitiveBoundingBoxOutput = true;
>
> extensions->ANDROID_extension_pack_es31a =
> --
> 2.20.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Liu, Leo]

On 2019-03-20 1:56 p.m., Michel Dänzer wrote:
> On 2019-03-20 4:42 p.m., Liu, Leo wrote:
>> The wait here is unnecessary since we got a pool of back buffers,
>> and the wait for swap buffer will happen before the present pixmap,
>> at the same time the previous back buffer will be put back to pool
>> for reuse after the check for PresentIdleNotify event
>>
>> Signed-off-by: Leo Liu 
>>
>>   [...]
>>
>> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
>> *vscreen, void *drawable)
>>  if (!dri3_set_drawable(scrn, (Drawable)drawable))
>> return NULL;
>>   
>> -   if (scrn->flushed) {
>> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
>> - if (!dri3_wait_present_events(scrn))
>> -return NULL;
>> -   }
>> -   scrn->flushed = false;
>> -
>>  buffer = (scrn->is_pixmap) ?
>>   dri3_get_front_buffer(scrn) :
>>   dri3_get_back_buffer(scrn);
>>
> Hmm. Is the wait here not necessary before getting a pixmap's front
> buffer either though? Maybe wait only here for a pixmap, and only in
> vl_dri3_flush_frontbuffer for a window?
>
> Sorry I didn't realize this earlier.
>
The pixmap case is used by Totem player, or previous GLX case for MPV 
player, and the front buffer of the pixmap is a temporary buffer, and 
later as source for GL to present.

For pixmap case, there is no need to wait,  and the dri3 present wait 
before dri3_get_front_buffer() is not get called, because scrn->flushed 
will never be true, since our presentation flush code is not used by 
this case.

Thanks,

Leo

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

[Mesa-dev] [PATCH 2/3] mesa/st: use ESSL cap top enable gpu_shader5 (v3)

[Rob Clark]

For GLES2+ contexts, enable EXT_gpu_shader5 if the driver exposes a
sufficiently high ESSL feature level, even if the GLSL feature level
isn't high enough.

This allows drivers to support EXT_gpu_shader5 in GLES contexts before
they support all the additional features of ARB_gpu_shader5 in GL
contexts.

Signed-off-by: Rob Clark 
---
 src/mesa/state_tracker/st_extensions.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index c953bfd9f7a..405fc21b3ad 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -1056,6 +1056,8 @@ void st_init_extensions(struct pipe_screen *screen,
consts->GLSLVersionCompat =
   screen->get_param(screen, PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY);
 
+   const unsigned ESSLVersion =
+  screen->get_param(screen, PIPE_CAP_ESSL_FEATURE_LEVEL);
const unsigned GLSLVersion =
   api == API_OPENGL_COMPAT ? consts->GLSLVersionCompat :
  consts->GLSLVersion;
@@ -1077,6 +1079,13 @@ void st_init_extensions(struct pipe_screen *screen,
 
consts->AllowGLSLCrossStageInterpolationMismatch = 
options->allow_glsl_cross_stage_interpolation_mismatch;
 
+   /* Technically we are turning on the EXT_gpu_shader5 extension,
+* ARB_gpu_shader5 does not exist in GLES, but this flag is what
+* switches on EXT_gpu_shader5:
+*/
+   if (api == API_OPENGLES2 && ESSLVersion >= 320)
+  extensions->ARB_gpu_shader5 = GL_TRUE;
+
if (GLSLVersion >= 400)
   extensions->ARB_gpu_shader5 = GL_TRUE;
if (GLSLVersion >= 410)
@@ -1540,16 +1549,18 @@ void st_init_extensions(struct pipe_screen *screen,
   extensions->EXT_shader_integer_mix;
 
extensions->OES_texture_cube_map_array =
-  extensions->ARB_ES3_1_compatibility &&
+  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
   extensions->OES_geometry_shader &&
   extensions->ARB_texture_cube_map_array;
 
extensions->OES_viewport_array =
-  extensions->ARB_ES3_1_compatibility &&
+  (extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310) &&
   extensions->OES_geometry_shader &&
   extensions->ARB_viewport_array;
 
-   extensions->OES_primitive_bounding_box = 
extensions->ARB_ES3_1_compatibility;
+   extensions->OES_primitive_bounding_box =
+  extensions->ARB_ES3_1_compatibility || ESSLVersion >= 310;
+
consts->NoPrimitiveBoundingBoxOutput = true;
 
extensions->ANDROID_extension_pack_es31a =
-- 
2.20.1

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

[Mesa-dev] [Bug 110211] If DESTDIR is set to an empty string, the dri drivers are not installed

[bugzilla-daemon]

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

--- Comment #12 from Pierre Labastie  ---
I told you I was not a Python geek :) The MR seems to work in all cases I can
imagine (unset DESTDIR, empty DESTDIR, DESTDIR set to non-empty) when
abs.libdir starts with '/' (sorry if this is not the place to comment on the
MR). Thanks for the Python lesson, it's my first day with Python (almost) ;)

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

[Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues

[Brian Paul]

When we destroy a context, we need to temporarily make that context
the current one for the thread.

That's because during context tear-down we make many calls to
_mesa_reference_texobj(, NULL).  Note there's no context
parameter.  If the texture's refcount goes to zero and we need to
delete it, we use the thread's current context.  But if that context
isn't the context we're tearing down, we get into trouble when
deallocating sampler views.  See patch 593e36f956 ("st/mesa:
implement "zombie" sampler views (v2)") for background information.

Also, we need to release any sampler views attached to the fallback
textures.

Fixes a crash on exit with a glretrace of the Nobel Clinician
application.
---
 src/mesa/state_tracker/st_context.c | 46 +++--
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index f037384..9b23d75 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st)
 {
struct gl_context *ctx = st->ctx;
struct st_framebuffer *stfb, *next;
+   struct gl_framebuffer *save_drawbuffer;
+   struct gl_framebuffer *save_readbuffer;
+
+   /* Save the current context and draw/read buffers*/
+   GET_CURRENT_CONTEXT(save_ctx);
+   if (save_ctx) {
+  save_drawbuffer = save_ctx->WinSysDrawBuffer;
+  save_readbuffer = save_ctx->WinSysReadBuffer;
+   } else {
+  save_drawbuffer = save_readbuffer = NULL;
+   }
 
-   GET_CURRENT_CONTEXT(curctx);
+   /*
+* We need to bind the context we're deleting so that
+* _mesa_reference_texobj_() uses this context when deleting textures.
+* Similarly for framebuffer objects, etc.
+*/
+   _mesa_make_current(ctx, NULL, NULL);
 
-   if (curctx == NULL) {
-  /* No current context, but we need one to release
-   * renderbuffer surface when we release framebuffer.
-   * So temporarily bind the context.
-   */
-  _mesa_make_current(ctx, NULL, NULL);
+   /* This must be called first so that glthread has a chance to finish */
+   _mesa_glthread_destroy(ctx);
+
+   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
+
+   /* For the fallback textures, free any sampler views belonging to this
+* context.
+*/
+   for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) {
+  struct st_texture_object *stObj =
+ st_texture_object(ctx->Shared->FallbackTex[i]);
+  if (stObj) {
+ st_texture_release_context_sampler_view(st, stObj);
+  }
}
 
st_context_free_zombie_objects(st);
@@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st)
mtx_destroy(>zombie_sampler_views.mutex);
mtx_destroy(>zombie_shaders.mutex);
 
-   /* This must be called first so that glthread has a chance to finish */
-   _mesa_glthread_destroy(ctx);
-
-   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
-
st_reference_fragprog(st, >fp, NULL);
st_reference_prog(st, >gp, NULL);
st_reference_vertprog(st, >vp, NULL);
@@ -965,4 +984,7 @@ st_destroy_context(struct st_context *st)
st = NULL;
 
free(ctx);
+
+   /* Restore the current context and draw/read buffers */
+   _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer);
 }
-- 
1.8.5.6

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

Re: [Mesa-dev] [PATCH] nir: fix a few signed/unsigned comparison warnings

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Thu, Mar 21, 2019 at 8:20 PM Brian Paul  wrote:

> ---
>  src/compiler/nir_types.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> index aff575c..3bf93c5 100644
> --- a/src/compiler/nir_types.cpp
> +++ b/src/compiler/nir_types.cpp
> @@ -690,7 +690,7 @@ glsl_type_get_sampler_count(const struct glsl_type
> *type)
>
> if (glsl_type_is_struct_or_ifc(type)) {
>unsigned count = 0;
> -  for (int i = 0; i < glsl_get_length(type); i++)
> +  for (unsigned i = 0; i < glsl_get_length(type); i++)
>   count += glsl_type_get_sampler_count(glsl_get_struct_field(type,
> i));
>return count;
> }
> @@ -711,7 +711,7 @@ glsl_type_get_image_count(const struct glsl_type *type)
>
> if (glsl_type_is_struct_or_ifc(type)) {
>unsigned count = 0;
> -  for (int i = 0; i < glsl_get_length(type); i++)
> +  for (unsigned i = 0; i < glsl_get_length(type); i++)
>   count += glsl_type_get_image_count(glsl_get_struct_field(type,
> i));
>return count;
> }
> --
> 1.8.5.6
>
> ___
> 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] nir: fix a few signed/unsigned comparison warnings

[Brian Paul]

---
 src/compiler/nir_types.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index aff575c..3bf93c5 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -690,7 +690,7 @@ glsl_type_get_sampler_count(const struct glsl_type *type)
 
if (glsl_type_is_struct_or_ifc(type)) {
   unsigned count = 0;
-  for (int i = 0; i < glsl_get_length(type); i++)
+  for (unsigned i = 0; i < glsl_get_length(type); i++)
  count += glsl_type_get_sampler_count(glsl_get_struct_field(type, i));
   return count;
}
@@ -711,7 +711,7 @@ glsl_type_get_image_count(const struct glsl_type *type)
 
if (glsl_type_is_struct_or_ifc(type)) {
   unsigned count = 0;
-  for (int i = 0; i < glsl_get_length(type); i++)
+  for (unsigned i = 0; i < glsl_get_length(type); i++)
  count += glsl_type_get_image_count(glsl_get_struct_field(type, i));
   return count;
}
-- 
1.8.5.6

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

Re: [Mesa-dev] [PATCH 2/2] softpipe: handle 32-bit bitfield inserts

[Roland Scheidegger]

Am 21.03.19 um 05:16 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> Fixes piglits if ARB_gpu_shader5 is enabled
> ---
>  src/gallium/auxiliary/tgsi/tgsi_exec.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c 
> b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> index c93e4e26e40..78159fc1d9f 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
> @@ -4999,10 +4999,14 @@ micro_bfi(union tgsi_exec_channel *dst,
>  {
> int i;
> for (i = 0; i < 4; i++) {
> -  int width = src3->u[i] & 0x1f;
> +  int width = src3->u[i];
>int offset = src2->u[i] & 0x1f;
> -  int bitmask = ((1 << width) - 1) << offset;
> -  dst->u[i] = ((src1->u[i] << offset) & bitmask) | (src0->u[i] & 
> ~bitmask);
> +  if (width == 32) {
> + dst->u[i] = src1->u[i];
> +  } else {
> + int bitmask = ((1 << width) - 1) << offset;
> + dst->u[i] = ((src1->u[i] << offset) & bitmask) | (src0->u[i] & 
> ~bitmask);
> +  }
> }
>  }
>  
> 

I think this is a really highly annoying difference between d3d11 and GL
there for bitfieldInsert/Extract...
But in any case, all 4 patches look good to me.
Reviewed-by: Roland Scheidegger 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] radv: Implement VK_EXT_pipeline_creation_feedback. - sigfault - bisected

[Dieter Nützel]

The world is saved...
you rocket man!

Greetings.

Dieter

Am 21.03.2019 09:00, schrieb Samuel Pitoiset:

Yeah, my bad... I have just sent a fix.

Thanks

On 3/21/19 7:22 AM, Dieter Nützel wrote:

Hello Bas,

sorry but your latest commit #5f5ac19f138
radv: Implement VK_EXT_pipeline_creation_feedback.

sigfault with every Vulkan apps for me.

Reverting it SOLVED it.

5f5ac19f138125b04d8ddedd6334b996f8925a4a is the first bad commit
commit 5f5ac19f138125b04d8ddedd6334b996f8925a4a
Author: Bas Nieuwenhuizen 
Date:   Tue Mar 19 02:30:33 2019 +0100

    radv: Implement VK_EXT_pipeline_creation_feedback.

    Does what it says on the tin.

    The per stage time is only an approximation due to linking and
    the Vega merged stages.

    Reviewed-by: Samuel Pitoiset 

:04 04 ea08bcac9b3630e10bf333c79227bcd0ed9a894b 
0924580849d9bc268e47be1248311ff3b5488c86 M src


I'm on the 'old' way compiling today:
./autogen.sh --prefix=/usr/local --with-dri-drivers="" 
--with-platforms=drm,x11 --with-gallium-drivers=r600,radeonsi,swrast 
--with-vulkan-drivers=radeon --enable-nine --enable-opencl 
--disable-opencl_icd --enable-libglvnd --enable-autotools


/home/dieter> vkcube
Speicherschutzverletzung (core dumped)
/home/dieter> vkcubepp
Speicherschutzverletzung (core dumped)

[46339.977530] vkcube[29027]: segfault at 7ff7951ae840 ip 
7ff795146569 sp 7ffda7d3d070 error 7 in 
libvulkan_radeon.so[7ff7950e4000+1cf000]
[46339.977536] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


[46341.772768] vkcubepp[29040]: segfault at 7fde85d21840 ip 
7fde85cb9569 sp 7ffeb679dfc0 error 7 in 
libvulkan_radeon.so[7fde85c57000+1cf000]
[46341.772775] Code: d2 f3 0f 10 25 5c 78 17 00 0f 55 d9 f3 0f 2a d0 
f3 0f c2 c2 06 0f 54 c4 f3 0f 58 c2 0f 56 c3 eb ab 53 48 89 fb e8 c7 
39 fb ff  03 01 00 00 00 48 29 43 08 5b c3 66 66 2e 0f 1f 84 00 00 
00 00


/home/dieter> vulkaninfo | less
Speicherschutzverletzung (core dumped)

==
VULKANINFO
==

Vulkan Instance Version: 1.1.98



Instance Extensions:

Instance Extensions count = 16
    VK_EXT_acquire_xlib_display : extension revision 1
    VK_EXT_debug_report : extension revision 9
    VK_EXT_debug_utils  : extension revision 1
    VK_EXT_direct_mode_display  : extension revision 1
    VK_EXT_display_surface_counter  : extension revision 1
    VK_KHR_device_group_creation    : extension revision 1
    VK_KHR_display  : extension revision 23
    VK_KHR_external_fence_capabilities  : extension revision 1
    VK_KHR_external_memory_capabilities : extension revision 1
    VK_KHR_external_semaphore_capabilities: extension revision  1
    VK_KHR_get_display_properties2  : extension revision 1
    VK_KHR_get_physical_device_properties2: extension revision  1
    VK_KHR_get_surface_capabilities2    : extension revision 1
    VK_KHR_surface  : extension revision 25
    VK_KHR_xcb_surface  : extension revision 6
    VK_KHR_xlib_surface : extension revision 6
Layers: count = 0
===
Presentable Surfaces:
=
GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xcb_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR
VkSurfaceCapabilitiesKHR:
    minImageCount   = 2
    maxImageCount   = 0
    currentExtent:
    width   = 256
    height  = 256
    minImageExtent:
    width   = 256
    height  = 256
    maxImageExtent:
    width   = 256
    height  = 256
    maxImageArrayLayers = 1
    supportedTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    currentTransform:
    VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR
    supportedCompositeAlpha:
    VK_COMPOSITE_ALPHA_OPAQUE_BIT_KHR
    VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR
    supportedUsageFlags:
    VK_IMAGE_USAGE_TRANSFER_SRC_BIT
    VK_IMAGE_USAGE_TRANSFER_DST_BIT
    VK_IMAGE_USAGE_SAMPLED_BIT
    VK_IMAGE_USAGE_STORAGE_BIT
    VK_IMAGE_USAGE_COLOR_ATTACHMENT_BIT
VkSurfaceCapabilities2EXT:
    supportedSurfaceCounters:
    None

GPU id   : 0 (AMD RADV POLARIS10 (LLVM 9.0.0))
Surface type : VK_KHR_xlib_surface
Formats:    count = 2
    B8G8R8A8_SRGB
    B8G8R8A8_UNORM
Present Modes:  count = 3
    IMMEDIATE_KHR
    MAILBOX_KHR
    FIFO_KHR

Stops, here.

BTW
'vulkaninfo' sigfault for some days even 

[Mesa-dev] [PATCH] nir: Fix anonymous union initialization with older GCC.

[Vinson Lee]

Fix this build error with GCC 4.4.7.

  CC nir/nir_opt_copy_prop_vars.lo
nir/nir_opt_copy_prop_vars.c: In function ‘load_element_from_ssa_entry_value’:
nir/nir_opt_copy_prop_vars.c:454: error: unknown field ‘ssa’ specified in 
initializer
nir/nir_opt_copy_prop_vars.c:455: error: unknown field ‘def’ specified in 
initializer
nir/nir_opt_copy_prop_vars.c:456: error: unknown field ‘component’ specified in 
initializer
nir/nir_opt_copy_prop_vars.c:456: error: extra brace group at end of initializer
nir/nir_opt_copy_prop_vars.c:456: error: (near initialization for 
‘(anonymous).’)
nir/nir_opt_copy_prop_vars.c:456: warning: excess elements in union initializer
nir/nir_opt_copy_prop_vars.c:456: warning: (near initialization for 
‘(anonymous).’)

Fixes: 96c32d77763c ("nir/copy_prop_vars: handle load/store of vector elements")
Signed-off-by: Vinson Lee 
---
 src/compiler/nir/nir_opt_copy_prop_vars.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c 
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 19003cc..94bc8af 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -451,10 +451,12 @@ load_element_from_ssa_entry_value(struct 
copy_prop_var_state *state,
 
*value = (struct value) {
   .is_ssa = true,
-  .ssa = {
- .def = { def },
- .component = { 0 },
-  },
+  {
+   .ssa = {
+ .def = { def },
+ .component = { 0 },
+   },
+  }
};
 
return true;
-- 
1.7.1

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

Re: [Mesa-dev] [PATCH] st/mesa: fix texture deletion context mix-up issues

[Neha Bhende]

Thanks for the fix!

Reviewed-by: Neha Bhende 

Regards,
Neha


From: Brian Paul 
Sent: Thursday, March 21, 2019 6:19 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [PATCH] st/mesa: fix texture deletion context mix-up issues

When we destroy a context, we need to temporarily make that context
the current one for the thread.

That's because during context tear-down we make many calls to
_mesa_reference_texobj(, NULL).  Note there's no context
parameter.  If the texture's refcount goes to zero and we need to
delete it, we use the thread's current context.  But if that context
isn't the context we're tearing down, we get into trouble when
deallocating sampler views.  See patch 593e36f956 ("st/mesa:
implement "zombie" sampler views (v2)") for background information.

Also, we need to release any sampler views attached to the fallback
textures.

Fixes a crash on exit with a glretrace of the Nobel Clinician
application.
---
 src/mesa/state_tracker/st_context.c | 46 +++--
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index f037384..9b23d75 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -917,15 +917,39 @@ st_destroy_context(struct st_context *st)
 {
struct gl_context *ctx = st->ctx;
struct st_framebuffer *stfb, *next;
+   struct gl_framebuffer *save_drawbuffer;
+   struct gl_framebuffer *save_readbuffer;
+
+   /* Save the current context and draw/read buffers*/
+   GET_CURRENT_CONTEXT(save_ctx);
+   if (save_ctx) {
+  save_drawbuffer = save_ctx->WinSysDrawBuffer;
+  save_readbuffer = save_ctx->WinSysReadBuffer;
+   } else {
+  save_drawbuffer = save_readbuffer = NULL;
+   }

-   GET_CURRENT_CONTEXT(curctx);
+   /*
+* We need to bind the context we're deleting so that
+* _mesa_reference_texobj_() uses this context when deleting textures.
+* Similarly for framebuffer objects, etc.
+*/
+   _mesa_make_current(ctx, NULL, NULL);

-   if (curctx == NULL) {
-  /* No current context, but we need one to release
-   * renderbuffer surface when we release framebuffer.
-   * So temporarily bind the context.
-   */
-  _mesa_make_current(ctx, NULL, NULL);
+   /* This must be called first so that glthread has a chance to finish */
+   _mesa_glthread_destroy(ctx);
+
+   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
+
+   /* For the fallback textures, free any sampler views belonging to this
+* context.
+*/
+   for (unsigned i = 0; i < NUM_TEXTURE_TARGETS; i++) {
+  struct st_texture_object *stObj =
+ st_texture_object(ctx->Shared->FallbackTex[i]);
+  if (stObj) {
+ st_texture_release_context_sampler_view(st, stObj);
+  }
}

st_context_free_zombie_objects(st);
@@ -933,11 +957,6 @@ st_destroy_context(struct st_context *st)
mtx_destroy(>zombie_sampler_views.mutex);
mtx_destroy(>zombie_shaders.mutex);

-   /* This must be called first so that glthread has a chance to finish */
-   _mesa_glthread_destroy(ctx);
-
-   _mesa_HashWalk(ctx->Shared->TexObjects, destroy_tex_sampler_cb, st);
-
st_reference_fragprog(st, >fp, NULL);
st_reference_prog(st, >gp, NULL);
st_reference_vertprog(st, >vp, NULL);
@@ -965,4 +984,7 @@ st_destroy_context(struct st_context *st)
st = NULL;

free(ctx);
+
+   /* Restore the current context and draw/read buffers */
+   _mesa_make_current(save_ctx, save_drawbuffer, save_readbuffer);
 }
--
1.8.5.6

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

Re: [Mesa-dev] [PATCH v7 1/5] util: Get program name based on path when possible

[Tapani Pälli]

On 3/21/19 12:02 PM, Eric Engestrom wrote:

On Thursday, 2019-03-21 09:14:15 +0200, Tapani Pälli wrote:

Hello;

One *very late* comment below ..

On 10/23/18 6:38 PM, Nicholas Kazlauskas wrote:

Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.

This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.

Cc: Timothy Arceri 
Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Engestrom 
---
   src/util/u_process.c | 23 ++-
   1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
   __getProgramName()
   {
  char * arg = strrchr(program_invocation_name, '/');
-   if (arg)
+   if (arg) {
+  /* If the / character was found this is likely a linux path or
+   * an invocation path for a 64-bit wine program.
+   *
+   * However, some programs pass command line arguments into argv[0].
+   * Strip these arguments out by using the realpath only if it was
+   * a prefix of the invocation name.
+   */
+  static char *path;
+
+  if (!path)
+ path = realpath("/proc/self/exe", NULL);


realpath allocates memory that we will leak, it's not much but just wanted
to mention, it might be not trivial to fix since I guess not all variants of
__getProgramName will allocate?


Yeah, I was aware of this, but it will only be called once and will live
for the lifetime of the app, so it doesn't hurt much, and when I looked
it seemed like a hard thing to fix, so I decided to just ignore it.

If this is a problem somewhere, you can raise a bug and/or add a FIXME
comment on the line, if only to document it.



Yeah, should not be a real problem. I just happened to notice as I was 
trying to reach 0 leaks.


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