Re: [Mesa-dev] [PATCH] llvmpipe : Fixed an issue where the display target texture was mapped multiple times.

2018-04-19 Thread 정성찬
Dear Roland Scheidegger

Thank you very much for your time and efforts.

First, I want to talk about the problem that I encountered.
I am currently developing a display server system using the llvmpipe driver
and the kms-dri winsys module. During the compositing process, winsys->
displaytarget_map () will be called continuously for the same resource. So
in the case of kms winsys, mmap () returns MAP_FAILED inside the
kms_sw_displaytarget_map function, and segfault terminates the process.

I also do not think this patch is perfect. As you said, the resource is
still
mapped. But in my opinion, this approach is a good way to solve the
aforementioned critical issues.

What do you think? I look forward to your reply.
Sincerely yours,

Seongchan Jeong.


2018-04-20 11:15 GMT+09:00 Roland Scheidegger :

> Am 19.04.2018 um 08:04 schrieb Seongchan Jeong:
> > The lp_setup_set_fragment_sampler_views function can be called
> > when the texture module is enabled. However, mapping can be
> > performed several times for one display target texture, but
> > unmapping does not proceed. So some logic have been added to
> > unmap the display target texture to prevent additional mappings
> > when the texture is already mapped.
> > ---
> >  src/gallium/drivers/llvmpipe/lp_setup.c   | 9 +
> >  src/gallium/drivers/llvmpipe/lp_texture.h | 2 ++
> >  2 files changed, 11 insertions(+)
> >
> > diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> > index c157323133..71ceafe2b7 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> > +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> > @@ -907,6 +907,13 @@ lp_setup_set_fragment_sampler_views(struct
> lp_setup_context *setup,
> >   */
> >  struct llvmpipe_screen *screen =
> llvmpipe_screen(res->screen);
> >  struct sw_winsys *winsys = screen->winsys;
> > +
> > +/* unmap the texture which is already mapped */
> > +if(lp_tex->mapped){
> > +winsys->displaytarget_unmap(winsys, lp_tex->dt);
> > +lp_tex->mapped = false;
> > +}
> > +
> >  jit_tex->base = winsys->displaytarget_map(winsys,
> lp_tex->dt,
> >
>  PIPE_TRANSFER_READ);
> >  jit_tex->row_stride[0] = lp_tex->row_stride[0];
> > @@ -917,6 +924,8 @@ lp_setup_set_fragment_sampler_views(struct
> lp_setup_context *setup,
> >  jit_tex->depth = res->depth0;
> >  jit_tex->first_level = jit_tex->last_level = 0;
> >  assert(jit_tex->base);
> > +
> > +lp_tex->mapped = true;
>
> I am not quite convinced this is the right fix.
> Clearly the code right now isn't right, and pretty much relies on the
> winsys->displaytarget_map() being a no-op there just giving the mapping
> without any side effects.
> The problem with this fix is it still would be kept mapped in the end
> after sampling (and, it can and probably will be mapped elsewhere too
> still).
>
> Do you hit any specific bug with the code as-is?
>
> Roland
>
>
> >   }
> >}
> >else {
> > diff --git a/src/gallium/drivers/llvmpipe/lp_texture.h
> b/src/gallium/drivers/llvmpipe/lp_texture.h
> > index 3d315bb9a7..9e39d31eb3 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_texture.h
> > +++ b/src/gallium/drivers/llvmpipe/lp_texture.h
> > @@ -75,6 +75,8 @@ struct llvmpipe_resource
> >  */
> > struct sw_displaytarget *dt;
> >
> > +   boolean mapped; /** status of displaytarget, map or unmap */
> > +
> > /**
> >  * Malloc'ed data for regular textures, or a mapping to dt above.
> >  */
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] egl/android: remove flink name support

2018-04-19 Thread Tomasz Figa
Hi Rob,

On Fri, Apr 20, 2018 at 6:09 AM Rob Herring  wrote:

> Maintaining both flink names and prime fd support which are provided by
> 2 different gralloc implementations is problematic because we have a
> dependency on a specific gralloc implementation header.

> This mostly removes the dependency on the gralloc implementation and
> headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains for
> now, but the definition is added locally to remove the header
> dependency.

> Signed-off-by: Rob Herring 
> ---
> With this plus Robert's probing patch, we remove any gralloc
> implementation dependency (other than it has to be a pre 1.0
> implementation...).

Big

Acked-by: Tomasz Figa 

from me. +/- 1 nit inline

This relic of the past should have disappeared long ago, together with all
the problems it brings. :)

[snip]
> @@ -1216,17 +1081,14 @@ dri2_initialize_android(_EGLDriver *drv,
_EGLDisplay *disp)
>  /* render nodes cannot use Gem names, and thus do not support
>   * the __DRI_DRI2_LOADER extension */
>  if (!dri2_dpy->is_render_node) {
> -  dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
> -  if (!dri2_load_driver(disp)) {
> - err = "DRI2: failed to load driver";
> - goto cleanup;
> -  }
> -   } else {
> -  dri2_dpy->loader_extensions = droid_image_loader_extensions;
> -  if (!dri2_load_driver_dri3(disp)) {
> - err = "DRI3: failed to load driver";
> - goto cleanup;
> -  }
> +  err = "DRI2: driver is not a render node";

Perhaps "device" or "handle" rather than "driver"?

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


Re: [Mesa-dev] [RFC] egl/android: Add DRM node probing and filtering

2018-04-19 Thread Tomasz Figa
Hi Rob,

On Thu, Apr 19, 2018 at 1:03 AM Robert Foss 
wrote:

> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.

> Currently the filtering is based just on the driver name,
> and the desired name is supplied using the "drm.gpu.vendor_name"
> Android property.

> The filtering itself is done using the newly introduced
> libdrm drmHandleMatch() call.

> Signed-off-by: Robert Foss 
> ---

> This patch is based on[1], which contains a new libdrm function,
> called drmHandleMatch(), which allows for matching an opened
> drm node handle against some desired properties.

> A choice that was made for this patch was to add support for
> falling back to to DRM nodes that have failed the filtering,
> if no node passes the filter.
> If this wouldn't be useful to anyone, I would suggest ripping it
> out since it is a little bit ugly&complex.

This is actually not only useful, but quite of a requirement for Chrome OS,
where we use the same Android image for devices with different GPU vendors.
(Technically we could hack it up by injecting some per-board properties,
but it would be painful from maintenance point of view.)

But actually, the way it is implemented in this patch will not work. The
code assumes that the first DRM node that could be opened
(loader_open_device()) is fine, but if you look at what we do in our
Chromium patch [2], it is actually necessary to check if Mesa includes a
driver for it (loader_get_driver_for_fd()).

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



> [1] https://www.spinics.net/lists/dri-devel/msg172497.html


>   src/egl/drivers/dri2/platform_android.c | 72
-
>   1 file changed, 62 insertions(+), 10 deletions(-)

> diff --git a/src/egl/drivers/dri2/platform_android.c
b/src/egl/drivers/dri2/platform_android.c
> index 7f1a496ea24..0b082fe5dcc 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -27,6 +27,7 @@
>* DEALINGS IN THE SOFTWARE.
>*/

> +#include 
>   #include 
>   #include 
>   #include 
> @@ -1117,18 +1118,69 @@ droid_add_configs_for_visuals(_EGLDriver *drv,
_EGLDisplay *dpy)
>   static int
>   droid_open_device(struct dri2_egl_display *dri2_dpy)
>   {
> -   int fd = -1, err = -EINVAL;
> -
> -   if (dri2_dpy->gralloc->perform)
> - err = dri2_dpy->gralloc->perform(dri2_dpy->gralloc,
> -
  GRALLOC_MODULE_PERFORM_GET_DRM_FD,
> -  &fd);
> -   if (err || fd < 0) {
> -  _eglLog(_EGL_WARNING, "fail to get drm fd");
> -  fd = -1;
> +   int prop_set, num_devices, ret;
> +   const int node_type = DRM_NODE_RENDER;
> +   int fd = -1, fallback_fd = -1;
> +
> +   const int MAX_DRM_DEVICES = 32;
> +   char vendor_name[PROPERTY_VALUE_MAX];
> +   prop_set = property_get("drm.gpu.vendor_name", vendor_name, NULL);
> +   drmVersion ver_filter;
> +   ver_filter.name = vendor_name;
> +
> +   drmDevicePtr devices[MAX_DRM_DEVICES];
> +   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
> +   if (num_devices < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to find any DRM devices");
> +  return -1;
> +   }
> +
> +   for (int i = 0; i < num_devices; i++) {
> +  /* Filter out DRM_NODE_ types we aren't interested in */
> +  if (!(devices[i]->available_nodes & (1 << node_type))) {
> + continue;
> +  }
> +
> +  /* Open DRM node FD */
> +  fd = loader_open_device(devices[i]->nodes[node_type]);
> +  if (fd == -1 && errno == EINVAL) {
> + _eglLog(_EGL_WARNING, "%s()  node #%d failed to open",
__func__, i);
> + continue;
> +  }

What should happen if (fd == -1 && errno != EINVAL)? I don't think we
should run the code below in such case.

> +
> +  /* See if FD matches the driver vendor we want */
> +  if (prop_set && !drmHandleMatch(fd, &ver_filter, NULL)){
> + _eglLog(_EGL_WARNING, "%s()  node #%d  FD=%d does not match
filter", __func__, i , fd);

How about printing the actual node (i.e. devices[i]->nodes[node_type]),
rather than index in devices array?

Also, should it be _EGL_DEBUG? I'd expect it to be a normal event, which
should not concern the user.

> + goto next;
> +  }
> +
> +  /* Successfully found matching FD */
> +  close(fallback_fd);
> +  fallback_fd = -1;
> +  break;
> +
> +next:
> +  if (fallback_fd == -1) {
> + fallback_fd = fd;
> + fd = -1;
> +  } else {
> + close(fd);
> + fd = -1;
> +  }
> +  continue;
> +   }

How about simplifying the code a bit:

+   for (int i = 0; i < num_devices; i++) {
+  /* Filter out DRM_NODE_ types we aren't interested in */
+  if (!(devices[i]->available_nodes & (1 << node_type))) {
+ continue;
+  }
+
+  /* Open DRM node FD */
+  fd = loader_open_device(devices[i]->nodes[node_type]);
+  if (fd < 0) {

Re: [Mesa-dev] [PATCH] i965: Allocate shadow batches to explicitly be the BO size.

2018-04-19 Thread Lionel Landwerlin

Looks good.

Do we need to add : Fixes: c7dcee58b5fe183e1653c13bff6a212f0d157b29 
(i965: Avoid problems from referencing orphaned BOs after growing.)

Which is the same as commit da25ae92bebb8921003c0df30820d06a5f5e3fef.

Regardless :

Reviewed-by: Lionel Landwerlin 

On 18/04/18 13:57, Kenneth Graunke wrote:

This unfortunately makes it malloc/realloc on every new batch, rather
than once at startup.  But it ensures that the shadow buffer's size will
absolutely match the BO size.  Otherwise, as we tune BATCH_SZ/STATE_SZ
or bufmgr cache bucket sizes, we may get a BO size that's rounded up,
and fail to allocate the shadow buffer large enough.

This doesn't fix any bugs today, as BATCH_SZ/STATE_SZ are the size of
a cache bucket, but it's better to be safe than sorry.

Reported-by: James Xiong 
---
  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +---
  1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index a29159e41ba..9dc9590138d 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -107,15 +107,11 @@ intel_batchbuffer_init(struct brw_context *brw)
  
 batch->use_shadow_copy = !devinfo->has_llc;
  
-   if (batch->use_shadow_copy) {

-  batch->batch.map = malloc(BATCH_SZ);
-  batch->map_next = batch->batch.map;
-  batch->state.map = malloc(STATE_SZ);
-   }
-
 init_reloc_list(&batch->batch_relocs, 250);
 init_reloc_list(&batch->state_relocs, 250);
  
+   batch->batch.map = NULL;

+   batch->state.map = NULL;
 batch->exec_count = 0;
 batch->exec_array_size = 100;
 batch->exec_bos =
@@ -196,7 +192,9 @@ recreate_growing_buffer(struct brw_context *brw,
 grow->partial_bo_map = NULL;
 grow->partial_bytes = 0;
  
-   if (!batch->use_shadow_copy)

+   if (batch->use_shadow_copy)
+  grow->map = realloc(grow->map, grow->bo->size);
+   else
grow->map = brw_bo_map(brw, grow->bo, MAP_READ | MAP_WRITE);
  }
  



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


Re: [Mesa-dev] [PATCH] llvmpipe : Fixed an issue where the display target texture was mapped multiple times.

2018-04-19 Thread Roland Scheidegger
Am 19.04.2018 um 08:04 schrieb Seongchan Jeong:
> The lp_setup_set_fragment_sampler_views function can be called
> when the texture module is enabled. However, mapping can be
> performed several times for one display target texture, but
> unmapping does not proceed. So some logic have been added to
> unmap the display target texture to prevent additional mappings
> when the texture is already mapped.
> ---
>  src/gallium/drivers/llvmpipe/lp_setup.c   | 9 +
>  src/gallium/drivers/llvmpipe/lp_texture.h | 2 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c 
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index c157323133..71ceafe2b7 100644
> --- a/src/gallium/drivers/llvmpipe/lp_setup.c
> +++ b/src/gallium/drivers/llvmpipe/lp_setup.c
> @@ -907,6 +907,13 @@ lp_setup_set_fragment_sampler_views(struct 
> lp_setup_context *setup,
>   */
>  struct llvmpipe_screen *screen = llvmpipe_screen(res->screen);
>  struct sw_winsys *winsys = screen->winsys;
> +
> +/* unmap the texture which is already mapped */
> +if(lp_tex->mapped){
> +winsys->displaytarget_unmap(winsys, lp_tex->dt);
> +lp_tex->mapped = false;
> +}
> +
>  jit_tex->base = winsys->displaytarget_map(winsys, lp_tex->dt,
>   PIPE_TRANSFER_READ);
>  jit_tex->row_stride[0] = lp_tex->row_stride[0];
> @@ -917,6 +924,8 @@ lp_setup_set_fragment_sampler_views(struct 
> lp_setup_context *setup,
>  jit_tex->depth = res->depth0;
>  jit_tex->first_level = jit_tex->last_level = 0;
>  assert(jit_tex->base);
> +
> +lp_tex->mapped = true;

I am not quite convinced this is the right fix.
Clearly the code right now isn't right, and pretty much relies on the
winsys->displaytarget_map() being a no-op there just giving the mapping
without any side effects.
The problem with this fix is it still would be kept mapped in the end
after sampling (and, it can and probably will be mapped elsewhere too
still).

Do you hit any specific bug with the code as-is?

Roland


>   }
>}
>else {
> diff --git a/src/gallium/drivers/llvmpipe/lp_texture.h 
> b/src/gallium/drivers/llvmpipe/lp_texture.h
> index 3d315bb9a7..9e39d31eb3 100644
> --- a/src/gallium/drivers/llvmpipe/lp_texture.h
> +++ b/src/gallium/drivers/llvmpipe/lp_texture.h
> @@ -75,6 +75,8 @@ struct llvmpipe_resource
>  */
> struct sw_displaytarget *dt;
>  
> +   boolean mapped; /** status of displaytarget, map or unmap */
> +
> /**
>  * Malloc'ed data for regular textures, or a mapping to dt above.
>  */
> 

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


Re: [Mesa-dev] [PATCH] clover: Fix host access validation for sub-buffer creation

2018-04-19 Thread Francisco Jerez
Aaron Watry  writes:

>   From CL 1.2 Section 5.2.1:
> CL_INVALID_VALUE if buffer was created with CL_MEM_HOST_WRITE_ONLY and
> flags specify CL_MEM_HOST_READ_ONLY , or if buffer was created with
> CL_MEM_HOST_READ_ONLY and flags specify CL_MEM_HOST_WRITE_ONLY , or if
> buffer was created with CL_MEM_HOST_NO_ACCESS and flags specify
> CL_MEM_HOST_READ_ONLY or CL_MEM_HOST_WRITE_ONLY .
>
> Fixes CL 1.2 CTS test/api get_buffer_info
>
> v2: Correct host_access_flags check (Francisco)
>
> Signed-off-by: Aaron Watry 
> Cc: Francisco Jerez 
> ---
>  src/gallium/state_trackers/clover/api/memory.cpp | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
> b/src/gallium/state_trackers/clover/api/memory.cpp
> index 9b3cd8b1f5..e83be0286a 100644
> --- a/src/gallium/state_trackers/clover/api/memory.cpp
> +++ b/src/gallium/state_trackers/clover/api/memory.cpp
> @@ -57,8 +57,12 @@ namespace {
>parent.flags() & host_access_flags) |
>   (parent.flags() & host_ptr_flags));
>  
> - if (~flags & parent.flags() &
> - ((dev_access_flags & ~CL_MEM_READ_WRITE) | host_access_flags))
> + if (~flags & parent.flags() & (dev_access_flags & 
> ~CL_MEM_READ_WRITE))
> +throw error(CL_INVALID_VALUE);
> +
> + //Check if new host access flags cause a mismatch between 
> host-read/write-only.

Space between '//' and comment, and limit to 80 columns.  With that
fixed:

Reviewed-by: Francisco Jerez 

> + if (!(flags & CL_MEM_HOST_NO_ACCESS) &&
> + (~flags & parent.flags() & host_access_flags))
>  throw error(CL_INVALID_VALUE);
>  
>   return flags;
> -- 
> 2.14.1


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


[Mesa-dev] [PATCH] clover: Fix host access validation for sub-buffer creation

2018-04-19 Thread Aaron Watry
  From CL 1.2 Section 5.2.1:
CL_INVALID_VALUE if buffer was created with CL_MEM_HOST_WRITE_ONLY and
flags specify CL_MEM_HOST_READ_ONLY , or if buffer was created with
CL_MEM_HOST_READ_ONLY and flags specify CL_MEM_HOST_WRITE_ONLY , or if
buffer was created with CL_MEM_HOST_NO_ACCESS and flags specify
CL_MEM_HOST_READ_ONLY or CL_MEM_HOST_WRITE_ONLY .

Fixes CL 1.2 CTS test/api get_buffer_info

v2: Correct host_access_flags check (Francisco)

Signed-off-by: Aaron Watry 
Cc: Francisco Jerez 
---
 src/gallium/state_trackers/clover/api/memory.cpp | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/clover/api/memory.cpp 
b/src/gallium/state_trackers/clover/api/memory.cpp
index 9b3cd8b1f5..e83be0286a 100644
--- a/src/gallium/state_trackers/clover/api/memory.cpp
+++ b/src/gallium/state_trackers/clover/api/memory.cpp
@@ -57,8 +57,12 @@ namespace {
   parent.flags() & host_access_flags) |
  (parent.flags() & host_ptr_flags));
 
- if (~flags & parent.flags() &
- ((dev_access_flags & ~CL_MEM_READ_WRITE) | host_access_flags))
+ if (~flags & parent.flags() & (dev_access_flags & ~CL_MEM_READ_WRITE))
+throw error(CL_INVALID_VALUE);
+
+ //Check if new host access flags cause a mismatch between 
host-read/write-only.
+ if (!(flags & CL_MEM_HOST_NO_ACCESS) &&
+ (~flags & parent.flags() & host_access_flags))
 throw error(CL_INVALID_VALUE);
 
  return flags;
-- 
2.14.1

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


[Mesa-dev] [PATCH] radv: Mark GTT memory as device local.

2018-04-19 Thread Bas Nieuwenhuizen
Otherwise a lot of games complain about not having enough memory,
and it is sort of local so this seems reasonable to me.

CC: 18.0 
---
 src/amd/vulkan/radv_device.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index b8313b26eb..8b8db7e1df 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -143,7 +143,7 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
gart_index = device->memory_properties.memoryHeapCount++;
device->memory_properties.memoryHeaps[gart_index] = 
(VkMemoryHeap) {
.size = device->rad_info.gart_size,
-   .flags = 0,
+   .flags = device->rad_info.has_dedicated_vram ? 0 : 
VK_MEMORY_HEAP_DEVICE_LOCAL_BIT,
};
}
 
@@ -160,7 +160,8 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
device->mem_type_indices[type_count] = 
RADV_MEM_TYPE_GTT_WRITE_COMBINE;
device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
.propertyFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
-   VK_MEMORY_PROPERTY_HOST_COHERENT_BIT,
+   VK_MEMORY_PROPERTY_HOST_COHERENT_BIT |
+   (device->rad_info.has_dedicated_vram ? 0 : 
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT),
.heapIndex = gart_index,
};
}
@@ -178,7 +179,8 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
device->memory_properties.memoryTypes[type_count++] = 
(VkMemoryType) {
.propertyFlags = VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT |
VK_MEMORY_PROPERTY_HOST_COHERENT_BIT |
-   VK_MEMORY_PROPERTY_HOST_CACHED_BIT,
+   VK_MEMORY_PROPERTY_HOST_CACHED_BIT |
+   (device->rad_info.has_dedicated_vram ? 0 : 
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT),
.heapIndex = gart_index,
};
}
-- 
2.17.0

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


[Mesa-dev] [Bug 106142] weston crashes on start up

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106142

Bug ID: 106142
   Summary: weston crashes on start up
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/swrast
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: madhurkira...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 138932
  --> https://bugs.freedesktop.org/attachment.cgi?id=138932&action=edit
GDB BACK TRACE

weston fails to load gl-render.so and seg faults. Application fails to make the
context current. Please check logs for more details.

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


Re: [Mesa-dev] [RFC] egl/android: Add DRM node probing and filtering

2018-04-19 Thread Rob Herring
On Wed, Apr 18, 2018 at 11:03 AM, Robert Foss  wrote:
> This patch both adds support for probing & filtering DRM nodes
> and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
> gralloc call.
>
> Currently the filtering is based just on the driver name,
> and the desired name is supplied using the "drm.gpu.vendor_name"
> Android property.
>
> The filtering itself is done using the newly introduced
> libdrm drmHandleMatch() call.
>
> Signed-off-by: Robert Foss 
> ---
>
> This patch is based on[1], which contains a new libdrm function,
> called drmHandleMatch(), which allows for matching an opened
> drm node handle against some desired properties.
>
> A choice that was made for this patch was to add support for
> falling back to to DRM nodes that have failed the filtering,
> if no node passes the filter.
> If this wouldn't be useful to anyone, I would suggest ripping it
> out since it is a little bit ugly&complex.

+1 for keeping it.

>
> [1] https://www.spinics.net/lists/dri-devel/msg172497.html
>
>
>  src/egl/drivers/dri2/platform_android.c | 72 
> -
>  1 file changed, 62 insertions(+), 10 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index 7f1a496ea24..0b082fe5dcc 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -27,6 +27,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1117,18 +1118,69 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *dpy)
>  static int
>  droid_open_device(struct dri2_egl_display *dri2_dpy)
>  {
> -   int fd = -1, err = -EINVAL;
> -
> -   if (dri2_dpy->gralloc->perform)
> - err = dri2_dpy->gralloc->perform(dri2_dpy->gralloc,
> -  GRALLOC_MODULE_PERFORM_GET_DRM_FD,
> -  &fd);
> -   if (err || fd < 0) {
> -  _eglLog(_EGL_WARNING, "fail to get drm fd");
> -  fd = -1;
> +   int prop_set, num_devices, ret;
> +   const int node_type = DRM_NODE_RENDER;
> +   int fd = -1, fallback_fd = -1;
> +
> +   const int MAX_DRM_DEVICES = 32;
> +   char vendor_name[PROPERTY_VALUE_MAX];
> +   prop_set = property_get("drm.gpu.vendor_name", vendor_name, NULL);

Is it really "vendor name" name that we match on? Isn't it a driver
name we want as a vendor could have multiple drivers.

> +   drmVersion ver_filter;
> +   ver_filter.name = vendor_name;
> +
> +   drmDevicePtr devices[MAX_DRM_DEVICES];
> +   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
> +   if (num_devices < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to find any DRM devices");
> +  return -1;
> +   }
> +
> +   for (int i = 0; i < num_devices; i++) {
> +  /* Filter out DRM_NODE_ types we aren't interested in */
> +  if (!(devices[i]->available_nodes & (1 << node_type))) {
> + continue;
> +  }

No braces needed here.

> +
> +  /* Open DRM node FD */
> +  fd = loader_open_device(devices[i]->nodes[node_type]);
> +  if (fd == -1 && errno == EINVAL) {
> + _eglLog(_EGL_WARNING, "%s()  node #%d failed to open", __func__, i);
> + continue;
> +  }
> +
> +  /* See if FD matches the driver vendor we want */
> +  if (prop_set && !drmHandleMatch(fd, &ver_filter, NULL)){
> + _eglLog(_EGL_WARNING, "%s()  node #%d  FD=%d does not match 
> filter", __func__, i , fd);
> + goto next;
> +  }
> +
> +  /* Successfully found matching FD */
> +  close(fallback_fd);
> +  fallback_fd = -1;
> +  break;
> +
> +next:
> +  if (fallback_fd == -1) {
> + fallback_fd = fd;
> + fd = -1;
> +  } else {
> + close(fd);
> + fd = -1;
> +  }
> +  continue;
> +   }
> +
> +   if (fallback_fd < 0 && fd < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to open any DRM handle");
> +  return -1;
> +   }
> +
> +   if (fd < 0) {
> +  _eglLog(_EGL_WARNING, "Failed to open desired DRM handle, using 
> fallback");
> +  return fallback_fd;
> }
>
> -   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
> +   return fd;
>  }
>
>  static const struct dri2_egl_display_vtbl droid_display_vtbl = {
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] egl/android: remove flink name support

2018-04-19 Thread Rob Herring
Maintaining both flink names and prime fd support which are provided by
2 different gralloc implementations is problematic because we have a
dependency on a specific gralloc implementation header.

This mostly removes the dependency on the gralloc implementation and
headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains for
now, but the definition is added locally to remove the header
dependency.

Signed-off-by: Rob Herring 
---
With this plus Robert's probing patch, we remove any gralloc 
implementation dependency (other than it has to be a pre 1.0 
implementation...).

 src/egl/drivers/dri2/egl_dri2.h |   1 -
 src/egl/drivers/dri2/platform_android.c | 172 
 2 files changed, 17 insertions(+), 156 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index cc76c73eab2f..d9e1f466fbeb 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -61,7 +61,6 @@ struct zwp_linux_dmabuf_v1;
 
 #include 
 #include 
-#include 
 
 #endif /* HAVE_ANDROID_PLATFORM */
 
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 4f25cb746915..68c85d7f99fa 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -37,7 +37,6 @@
 #include "loader.h"
 #include "egl_dri2.h"
 #include "egl_dri2_fallbacks.h"
-#include "gralloc_drm.h"
 
 #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
 
@@ -164,12 +163,6 @@ get_native_buffer_fd(struct ANativeWindowBuffer *buf)
return (handle && handle->numFds) ? handle->data[0] : -1;
 }
 
-static int
-get_native_buffer_name(struct ANativeWindowBuffer *buf)
-{
-   return gralloc_drm_get_gem_handle(buf->handle);
-}
-
 static EGLBoolean
 droid_window_dequeue_buffer(struct dri2_egl_surface *dri2_surf)
 {
@@ -822,50 +815,6 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
_EGLContext *ctx,
return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
 }
 
-static _EGLImage *
-droid_create_image_from_name(_EGLDisplay *disp, _EGLContext *ctx,
- struct ANativeWindowBuffer *buf)
-{
-   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
-   struct dri2_egl_image *dri2_img;
-   int name;
-   int format;
-
-   name = get_native_buffer_name(buf);
-   if (!name) {
-  _eglError(EGL_BAD_PARAMETER, "eglCreateEGLImageKHR");
-  return NULL;
-   }
-
-   format = get_format(buf->format);
-   if (format == -1)
-   return NULL;
-
-   dri2_img = calloc(1, sizeof(*dri2_img));
-   if (!dri2_img) {
-  _eglError(EGL_BAD_ALLOC, "droid_create_image_mesa_drm");
-  return NULL;
-   }
-
-   _eglInitImage(&dri2_img->base, disp);
-
-   dri2_img->dri_image =
-  dri2_dpy->image->createImageFromName(dri2_dpy->dri_screen,
-  buf->width,
-  buf->height,
-  format,
-  name,
-  buf->stride,
-  dri2_img);
-   if (!dri2_img->dri_image) {
-  free(dri2_img);
-  _eglError(EGL_BAD_ALLOC, "droid_create_image_mesa_drm");
-  return NULL;
-   }
-
-   return &dri2_img->base;
-}
-
 static EGLBoolean
 droid_query_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf,
 EGLint attribute, EGLint *value)
@@ -921,7 +870,7 @@ dri2_create_image_android_native_buffer(_EGLDisplay *disp,
if (fd >= 0)
   return droid_create_image_from_prime_fd(disp, ctx, buf, fd);
 
-   return droid_create_image_from_name(disp, ctx, buf);
+   return NULL;
 }
 
 static _EGLImage *
@@ -943,82 +892,6 @@ droid_flush_front_buffer(__DRIdrawable * driDrawable, void 
*loaderPrivate)
 {
 }
 
-static int
-droid_get_buffers_parse_attachments(struct dri2_egl_surface *dri2_surf,
-unsigned int *attachments, int count)
-{
-   int num_buffers = 0;
-
-   /* fill dri2_surf->buffers */
-   for (int i = 0; i < count * 2; i += 2) {
-  __DRIbuffer *buf, *local;
-
-  assert(num_buffers < ARRAY_SIZE(dri2_surf->buffers));
-  buf = &dri2_surf->buffers[num_buffers];
-
-  switch (attachments[i]) {
-  case __DRI_BUFFER_BACK_LEFT:
- if (dri2_surf->base.Type == EGL_WINDOW_BIT) {
-buf->attachment = attachments[i];
-buf->name = get_native_buffer_name(dri2_surf->buffer);
-buf->cpp = get_format_bpp(dri2_surf->buffer->format);
-buf->pitch = dri2_surf->buffer->stride * buf->cpp;
-buf->flags = 0;
-
-if (buf->name)
-   num_buffers++;
-
-break;
- }
- /* fall through for pbuffers */
-  case __DRI_BUFFER_DEPTH:
-  case __DRI_BUFFER_STENCIL:
-  case __DRI_BUFFER_ACCUM:
-  case __DRI_BUFFER_DEPTH_STENCIL:
-  case __DRI_BUFFER_HIZ:
- loca

[Mesa-dev] [Bug 106140] EGLconfigs returns with no match for glmark2-es2-x11

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106140

Bug ID: 106140
   Summary: EGLconfigs returns with no match for glmark2-es2-x11
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/swrast
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: madhurkira...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

glmark2-es2-x11 does not work out of the box when swrast is used. The default
EGL configs returns with zero match. Window manager used was matchbox.

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


[Mesa-dev] [PATCH] glsl/glcpp: Handle hex constants with 0X prefix

2018-04-19 Thread Vlad Golovkin
GLSL 4.6 spec describes hex constant as:

hexadecimal-constant:
0x hexadecimal-digit
0X hexadecimal-digit
hexadecimal-constant hexadecimal-digit

Right now if you have a shader with the following structure:

#if 0X1 // or any hex number with the 0X prefix
// some code
#endif

the code between #if and #endif gets removed because the checking is performed
only for "0x" prefix which results in strtoll being called with the base 8 and
after encountering the 'X' char the strtoll returns 0. Letting strtoll detect
the base makes this limitation go away and also makes code easier to read.

Also added 1 test for uppercase hex prefix.
---
 src/compiler/glsl/glcpp/glcpp-parse.y| 9 ++---
 src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c   | 5 +
 .../glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected   | 5 +
 3 files changed, 12 insertions(+), 7 deletions(-)
 create mode 100644 
src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
 create mode 100644 
src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected

diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y 
b/src/compiler/glsl/glcpp/glcpp-parse.y
index ccb3aa18d3..d83f99f1c7 100644
--- a/src/compiler/glsl/glcpp/glcpp-parse.y
+++ b/src/compiler/glsl/glcpp/glcpp-parse.y
@@ -462,13 +462,8 @@ control_line_error:
 
 integer_constant:
INTEGER_STRING {
-   if (strlen ($1) >= 3 && strncmp ($1, "0x", 2) == 0) {
-   $$ = strtoll ($1 + 2, NULL, 16);
-   } else if ($1[0] == '0') {
-   $$ = strtoll ($1, NULL, 8);
-   } else {
-   $$ = strtoll ($1, NULL, 10);
-   }
+   /* let strtoll detect the base */
+   $$ = strtoll ($1, NULL, 0);
}
 |  INTEGER {
$$ = $1;
diff --git a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c 
b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
new file mode 100644
index 00..1be9b28eb7
--- /dev/null
+++ b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c
@@ -0,0 +1,5 @@
+#if 0x1234abcd == 0X1234abcd
+success
+#else
+failure
+#endif
diff --git 
a/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected 
b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
new file mode 100644
index 00..4cf250f6bb
--- /dev/null
+++ b/src/compiler/glsl/glcpp/tests/149-hex-const-uppercase-prefix.c.expected
@@ -0,0 +1,5 @@
+
+success
+
+
+
-- 
2.14.1

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


Re: [Mesa-dev] [PATCH] i965/urb/cnl: Apply gen7 CS stall

2018-04-19 Thread Anuj Phogat
On Thu, Apr 19, 2018 at 7:44 AM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:

> This didn't actually help the failing tests I'm looking at
> but hopefully has teeth elsewhere.
>
> CC: Jason Ekstrand 
> CC: Jordan Justen 
> CC: Anuj Phogat 
> Signed-off-by: Topi Pohjolainen 
> ---
>  src/mesa/drivers/dri/i965/gen7_urb.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> index 2e5f8e6..9e12657 100644
> --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> @@ -145,8 +145,15 @@ gen7_emit_push_constant_state(struct brw_context
> *brw, unsigned vs_size,
>  * in the ring after this instruction.
>  *
>  * No such restriction exists for Haswell or Baytrail.
> +*
> +* From the CNL Bspec, Windower -
> +* 3DSTATE_PUSH_CONSTANT_ALLOC_PS/VS/GS/DS/HS:
> +*
> +* This command must be followed by a PIPE_CONTROL with CS Stall
> bit
> +* set.
>  */
> -   if (devinfo->gen < 8 && !devinfo->is_haswell && !devinfo->is_baytrail)
> +   if ((devinfo->gen < 8 && !devinfo->is_haswell &&
> !devinfo->is_baytrail) ||
> +   devinfo->gen >= 10)
>gen7_emit_cs_stall_flush(brw);
>  }
>
> --
> 2.7.4
>
>
​Verified in BSpec.
​Reviewed-by: Anuj Phogat 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa/math: Allocate memory for GLmatrix elements and its inverse contiguously

2018-04-19 Thread Thomas Helland
2018-04-19 20:08 GMT+02:00 Vlad Golovkin :
> -- Forwarded message --
> From: Vlad Golovkin 
> Date: 2018-04-19 21:06 GMT+03:00
> Subject: Re: [Mesa-dev] [PATCH] mesa/math: Allocate memory for
> GLmatrix elements and its inverse contiguously
> To: Thomas Helland 
>
>
> 2018-04-17 8:55 GMT+03:00 Thomas Helland :
>> Hi, and thanks for the patch =)
>>
>> Have you done any performance testing on this to verify it
>> gives us a speedup of any kind? I'm asking because it seems like
>> this might be something that a decent compiler should be able to do.
>> Performance related patches, at least in core mesa, usually have
>> some justification with benchmark numbers in the commit message.
>
> Hi,
> I examined the resulting assembly for these 3 functions and it turns
> out that compiler wasn't merging these two blocks of memory into one
> (which compiler does that?).
> gcc tried to unroll memcpys to a series of movs which may seem to
> partially defeat the purpose of this patch, but after copying the
> block corresponding to m->m it had to switch destination and source
> registers to the next block resulting in 2 wasted movs.
> As a result we can save malloc and free call (in _math_matrix_ctr and
> _math_matrix_dtr) and 2 movs (when compiler tries to avoid memcpy -
> best case) or 1 memcpy call (in the worst case). It may seem that 2nd
> malloc can place m->inv in memory right after m->m but: 1) compiler
> can't rely on that behaviour 2) allocator will insert some private
> data before each block leading to more cache misses.
> I made some testing with Torcs and Yo Frankie blender game and
> according to perf in Yo Frankie _math_matrix_copy overhead reduced by
> 0.03% - 0.04% while Torcs didn't see any improvement.
>

Good analysis! While the gains are not huge, its probably worthwhile.
With some of the comments adressed this has my RB.
I'll pull it down this weekend, and add the comments if you don't
beat me to it, and then I'll push with my RB once we are past the
18.1 branching. Thanks for the patch =)

> Sorry for the duplicate emails.
>
>> Some style comments below
>>
>> 2018-04-17 1:03 GMT+02:00 Vlad Golovkin :
>>> When GLmatrix elements and its inverse are stored contiguously in memory it 
>>> is possible to
>>> allocate, free and copy these fields with 1 function call instead of 2.
>>> ---
>>>  src/mesa/math/m_matrix.c | 15 +--
>>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
>>> index 57a49533de..4ab78a1fb3 100644
>>> --- a/src/mesa/math/m_matrix.c
>>> +++ b/src/mesa/math/m_matrix.c
>>> @@ -1438,8 +1438,7 @@ _math_matrix_is_dirty( const GLmatrix *m )
>>>  void
>>>  _math_matrix_copy( GLmatrix *to, const GLmatrix *from )
>>>  {
>>> -   memcpy(to->m, from->m, 16 * sizeof(GLfloat));
>>> -   memcpy(to->inv, from->inv, 16 * sizeof(GLfloat));
>>> +   memcpy(to->m, from->m, 16 * 2 * sizeof(GLfloat));
>>> to->flags = from->flags;
>>> to->type = from->type;
>>>  }
>>> @@ -1470,12 +1469,17 @@ _math_matrix_loadf( GLmatrix *mat, const GLfloat *m 
>>> )
>>>  void
>>>  _math_matrix_ctr( GLmatrix *m )
>>>  {
>>> -   m->m = _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
>>> +   m->m = _mesa_align_malloc( 16 * 2 * sizeof(GLfloat), 16 );
>>> if (m->m)
>>> +   {
>>
>> Our style guides says to keep the curly bracket after an if on the same line.
>>
>>> +  m->inv = m->m + 16;
>>>memcpy( m->m, Identity, sizeof(Identity) );
>>> -   m->inv = _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
>>> -   if (m->inv)
>>>memcpy( m->inv, Identity, sizeof(Identity) );
>>> +   }
>>> +   else
>>> +   {
>>
>> } else {
>>
>> Although I see that this file defaults to;
>>
>> {
>> else {
>>
>> for some reason. Feel free to follow existing style, or adjust to my 
>> comments.
>> Also, if we want to do this change it deserves a comment in the source.
>>> +  m->inv = NULL;
>>> +   }
>>> m->type = MATRIX_IDENTITY;
>>> m->flags = 0;
>>>  }
>>> @@ -1493,7 +1497,6 @@ _math_matrix_dtr( GLmatrix *m )
>>> _mesa_align_free( m->m );
>>> m->m = NULL;
>>>
>>> -   _mesa_align_free( m->inv );
>>> m->inv = NULL;
>>>  }
>>>
>>> --
>>> 2.14.1
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965/fs: retype offset_reg to UD at load_ssbo

2018-04-19 Thread Chema Casanova
On 19/04/18 19:50, Ian Romanick wrote:
> On 04/18/2018 01:57 PM, Jose Maria Casanova Crespo wrote:
>> All operations with offset_reg at do_vector_read are done
>> with UD type. So copy propagation was not working through
>> the generated MOVs:
>>
>> mov(8) vgrf9:UD, vgrf7:D
> 
> I have noticed other cases of this.  Copy propagation doesn't work
> across moves that change the type because int->float and float->int
> actually change the bit pattern.  unsigned->signed doesn't do anything,
> so it seems like we should allow that case.  This is a few steps down on
> my to-do list, but if someone else gets to it first...

I have a pending visit to copy propagation because of some 16-bit
strange behaviours. So I can put it also im my to-do and check if
allowing it doesn't generate any problem.

Chema

>> This change allows removing the MOV generated for reading the
>> first components for 16-bit and 64-bit ssbo reads with
>> non-constant offsets.
>> ---
>>  src/intel/compiler/brw_fs_nir.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
>> b/src/intel/compiler/brw_fs_nir.cpp
>> index 6c4bcd1c113..0ebaab96634 100644
>> --- a/src/intel/compiler/brw_fs_nir.cpp
>> +++ b/src/intel/compiler/brw_fs_nir.cpp
>> @@ -4142,7 +4142,7 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
>> nir_intrinsic_instr *instr
>>if (const_offset) {
>>   offset_reg = brw_imm_ud(const_offset->u32[0]);
>>} else {
>> - offset_reg = get_nir_src(instr->src[1]);
>> + offset_reg = retype(get_nir_src(instr->src[1]), 
>> BRW_REGISTER_TYPE_UD);
>>}
>>  
>>/* Read the vector */
>>
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105904

--- Comment #5 from Snubb  ---
My computer reproduced bug!! 

64 bit cube.exe working and 32 bit cube.exe and 32 bit dxvk not working before
deleting ~./cache/radv_builtin_shaders

I don't know why or how but i grabbed some output so you can try figure it out
:-)


Driver versions = 18.1~git1804190730.0e1079~oibaf~b


Wine error window from running 32 bit cube.exe before deleting
radv_builtin_shaders:

Unhandled exception: divide by zero in 32-bit code (0x7d39e95c).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:7d39e95c ESP:0033e9e8 EBP: EFLAGS:00010246(  R- --  I  Z- -P- )
 EAX:0100 EBX:7be45300 ECX:0024 EDX:
 ESI:7be44fcc EDI:
Stack dump:
0x0033e9e8:  0480 7be44fe4 7d8d7d2c 7d8d7e44
0x0033e9f8:  7be44cb0 7d576000 7d576000 7d3a3708
0x0033ea08:  7be44cb0 7d3a3774 7d92c9a8 f7ef13ec
0x0033ea18:  7d576000   0033f388
0x0033ea28:  000a 7d66c114 0033f0f8 7d33a001
0x0033ea38:  7be45690 0011 0002 7d8d69f0
Backtrace:
=>0 0x7d39e95c in libvulkan_radeon.so (+0x6695c) (0x)
  1 0x7d3a3774 in libvulkan_radeon.so (+0x6b773) (0x7be44cb0)
  2 0x7d3a437e in libvulkan_radeon.so (+0x6c37d) (0x7d8d6a14)
  3 0x7d36f388 in libvulkan_radeon.so (+0x37387) (0x0033f7b8)
  4 0x7d365707 in libvulkan_radeon.so (+0x2d706) (0x)
  5 0x7d35811c in libvulkan_radeon.so (+0x2011b) (0x7d8d69f0)
  6 0x7dc60cfb in libvulkan.so.1 (+0x18cfa) (0x0033f9f8)
  7 0x7dc69b15 in libvulkan.so.1 (+0x21b14) (0x0033fad8)
  8 0x7dc6dbf5 vkCreateDevice+0x244() in libvulkan.so.1 (0x0033fb20)
  9 0x7dd76f7d wine_vkCreateDevice+0x1ac() in winevulkan (0x0033fbe8)
  10 0x100395bf in vulkan-1 (+0x395be) (0x0033fc78)
  11 0x10029be4 in vulkan-1 (+0x29be3) (0x0033fd1c)
  12 0x1003fc00 in vulkan-1 (+0x3fbff) (0x0033fd54)
  13 0x00416e74 in cube (+0x16e73) (0x0033fdc8)
  14 0x00418f6e in cube (+0x18f6d) (0x0033fe20)
  15 0x004162fe in cube (+0x162fd) (0x0033fe74)
  16 0x0041ec98 in cube (+0x1ec97) (0x0033fec0)
  17 0x7b46279c call_process_entry+0xb() in kernel32 (0x0033fed8)
  18 0x7b4641ce in kernel32 (+0x441cd) (0x0033ffd8)
  19 0x7b4627aa call_process_entry+0x19() in kernel32 (0x0033ffec)
0x7d39e95c: divl0x14(%ebx),%eax
Modules:
Module  Address Debug info  Name (86 modules)
PE40-  498000   Export  cube
PE  1000-100cd000   Export  vulkan-1
ELF 4215-4229b000   Deferredlibx11.so.6
ELF 42fc-42fd5000   Deferredlibxext.so.6
ELF 42fd8000-42feb000   Deferredlibxi.so.6
ELF 43028000-4302f000   Deferredlibxfixes.so.3
ELF 43038000-43045000   Deferredlibxrandr.so.2
ELF 43048000-43054000   Deferredlibxrender.so.1
ELF 430d8000-430dc000   Deferredlibxau.so.6
ELF 430e-430e4000   Deferredlibxcomposite.so.1
ELF 430f-430f4000   Deferredlibxinerama.so.1
ELF 77468000-7b3fb000   Deferredlibllvm-6.0.so.1
ELF 7b40-7b7eb000   Dwarf   kernel32
  \-PE  7b42-7b7eb000   \   kernel32
ELF 7bc0-7bcfa000   Deferredntdll
  \-PE  7bc1-7bcfa000   \   ntdll
ELF 7c00-7c004000   Deferred
ELF 7cfc-7d333000   Deferredlibvulkan_intel.so
ELF 7d338000-7d578000   Dwarf   libvulkan_radeon.so
ELF 7d678000-7d6af000   Deferredlibedit.so.2
ELF 7d988000-7d991000   Deferredlibffi.so.6
ELF 7d998000-7d9b6000   Deferredlibgcc_s.so.1
ELF 7dbf-7dbfd000   Deferredlibwayland-client.so.0
ELF 7dc0-7dc03000   Deferredlibxshmfence.so.1
ELF 7dc48000-7dc9f000   Dwarf   libvulkan.so.1
ELF 7dca8000-7dcb   Deferredlibxcb-sync.so.1
ELF 7dcb-7dcb4000   Deferredlibxcb-present.so.0
ELF 7dcb8000-7dcbd000   Deferredlibxcb-dri3.so.0
ELF 7dcc-7dcc3000   Deferredlibx11-xcb.so.1
ELF 7dcc8000-7dcdc000   Deferredlibdrm.so.2
ELF 7dce-7dcec000   Deferredlibxcursor.so.1
ELF 7dcf-7dcf7000   Deferredlibxxf86vm.so.1
ELF 7dcf8000-7dd02000   Deferredlibrt.so.1
ELF 7dd08000-7dd23000   Deferredlibbsd.so.0
ELF 7dd28000-7dd2f000   Deferredlibxdmcp.so.6
ELF 7dd3-7dd5c000   Deferredlibxcb.so.1
ELF 7dd6-7dd92000   Dwarf   winevulkan
  \-PE  7dd7-7dd92000   \   winevulkan
ELF 7dda-7de3   Deferredwinex11
  \-PE  7ddb-7de3   \   winex11
ELF 7de38000-7de44000   Deferredlibdrm_amdgpu.so.1
ELF 7de48000-7de66000   Deferredlibelf.so.1
ELF 7de68000-7de7c000   Deferred   
api-ms-win-core-localization-l1-2-1
  \-PE

Re: [Mesa-dev] [PATCH 1/2] bin/install_megadrivers: fix DESTDIR and -D*-path

2018-04-19 Thread Dylan Baker
Quoting Dylan Baker (2018-04-16 14:28:42)
> Quoting Dylan Baker (2018-04-13 08:46:46)
> > Quoting Dylan Baker (2018-04-09 14:02:51)
> > > This fixes -Ddri-drivers-path, -Dvdpau-libs-path, etc. with DESTDIR when
> > > those paths are absolute. Currently due to the way python's os.path.join
> > > handles absolute paths these will ignore DESTDIR, which is bad. This
> > > fixes them to be relative to DESTDIR if that is set.
> > > 
> > > Fixes: 3218056e0eb375eeda470058d06add1532acd6d4
> > >("meson: Build i965 and dri stack")
> > > Signed-off-by: Dylan Baker 
> > > ---
> > >  bin/install_megadrivers.py | 8 ++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/bin/install_megadrivers.py b/bin/install_megadrivers.py
> > > index 7931a544bd2..c04a2a3eb34 100755
> > > --- a/bin/install_megadrivers.py
> > > +++ b/bin/install_megadrivers.py
> > > @@ -1,6 +1,6 @@
> > >  #!/usr/bin/env python
> > >  # encoding=utf-8
> > > -# Copyright © 2017 Intel Corporation
> > > +# Copyright © 2017-2018 Intel Corporation
> > >  
> > >  # Permission is hereby granted, free of charge, to any person obtaining 
> > > a copy
> > >  # of this software and associated documentation files (the "Software"), 
> > > to deal
> > > @@ -35,7 +35,11 @@ def main():
> > >  parser.add_argument('drivers', nargs='+')
> > >  args = parser.parse_args()
> > >  
> > > -to = os.path.join(os.environ.get('MESON_INSTALL_DESTDIR_PREFIX'), 
> > > args.libdir)
> > > +if os.path.isabs(args.libdir):
> > > +to = os.path.join(os.environ.get('DESTDIR', '/'), 
> > > args.libdir[1:])
> > > +else:
> > > +to = os.path.join(os.environ['MESON_INSTALL_DESTDIR_PREFIX'], 
> > > args.libdir)
> > > +
> > >  master = os.path.join(to, os.path.basename(args.megadriver))
> > >  
> > >  if not os.path.exists(to):
> > > -- 
> > > 2.17.0
> > > 
> > 
> > ping. The first patch is really needed for 18.0.1
> > 
> > Dylan
> 
> anybody?
> 

I'm pushing these today if no one speaks up.

Dylan


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


[Mesa-dev] Fwd: [PATCH] mesa/math: Allocate memory for GLmatrix elements and its inverse contiguously

2018-04-19 Thread Vlad Golovkin
-- Forwarded message --
From: Vlad Golovkin 
Date: 2018-04-19 21:06 GMT+03:00
Subject: Re: [Mesa-dev] [PATCH] mesa/math: Allocate memory for
GLmatrix elements and its inverse contiguously
To: Thomas Helland 


2018-04-17 8:55 GMT+03:00 Thomas Helland :
> Hi, and thanks for the patch =)
>
> Have you done any performance testing on this to verify it
> gives us a speedup of any kind? I'm asking because it seems like
> this might be something that a decent compiler should be able to do.
> Performance related patches, at least in core mesa, usually have
> some justification with benchmark numbers in the commit message.

Hi,
I examined the resulting assembly for these 3 functions and it turns
out that compiler wasn't merging these two blocks of memory into one
(which compiler does that?).
gcc tried to unroll memcpys to a series of movs which may seem to
partially defeat the purpose of this patch, but after copying the
block corresponding to m->m it had to switch destination and source
registers to the next block resulting in 2 wasted movs.
As a result we can save malloc and free call (in _math_matrix_ctr and
_math_matrix_dtr) and 2 movs (when compiler tries to avoid memcpy -
best case) or 1 memcpy call (in the worst case). It may seem that 2nd
malloc can place m->inv in memory right after m->m but: 1) compiler
can't rely on that behaviour 2) allocator will insert some private
data before each block leading to more cache misses.
I made some testing with Torcs and Yo Frankie blender game and
according to perf in Yo Frankie _math_matrix_copy overhead reduced by
0.03% - 0.04% while Torcs didn't see any improvement.

Sorry for the duplicate emails.

> Some style comments below
>
> 2018-04-17 1:03 GMT+02:00 Vlad Golovkin :
>> When GLmatrix elements and its inverse are stored contiguously in memory it 
>> is possible to
>> allocate, free and copy these fields with 1 function call instead of 2.
>> ---
>>  src/mesa/math/m_matrix.c | 15 +--
>>  1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
>> index 57a49533de..4ab78a1fb3 100644
>> --- a/src/mesa/math/m_matrix.c
>> +++ b/src/mesa/math/m_matrix.c
>> @@ -1438,8 +1438,7 @@ _math_matrix_is_dirty( const GLmatrix *m )
>>  void
>>  _math_matrix_copy( GLmatrix *to, const GLmatrix *from )
>>  {
>> -   memcpy(to->m, from->m, 16 * sizeof(GLfloat));
>> -   memcpy(to->inv, from->inv, 16 * sizeof(GLfloat));
>> +   memcpy(to->m, from->m, 16 * 2 * sizeof(GLfloat));
>> to->flags = from->flags;
>> to->type = from->type;
>>  }
>> @@ -1470,12 +1469,17 @@ _math_matrix_loadf( GLmatrix *mat, const GLfloat *m )
>>  void
>>  _math_matrix_ctr( GLmatrix *m )
>>  {
>> -   m->m = _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
>> +   m->m = _mesa_align_malloc( 16 * 2 * sizeof(GLfloat), 16 );
>> if (m->m)
>> +   {
>
> Our style guides says to keep the curly bracket after an if on the same line.
>
>> +  m->inv = m->m + 16;
>>memcpy( m->m, Identity, sizeof(Identity) );
>> -   m->inv = _mesa_align_malloc( 16 * sizeof(GLfloat), 16 );
>> -   if (m->inv)
>>memcpy( m->inv, Identity, sizeof(Identity) );
>> +   }
>> +   else
>> +   {
>
> } else {
>
> Although I see that this file defaults to;
>
> {
> else {
>
> for some reason. Feel free to follow existing style, or adjust to my comments.
> Also, if we want to do this change it deserves a comment in the source.
>> +  m->inv = NULL;
>> +   }
>> m->type = MATRIX_IDENTITY;
>> m->flags = 0;
>>  }
>> @@ -1493,7 +1497,6 @@ _math_matrix_dtr( GLmatrix *m )
>> _mesa_align_free( m->m );
>> m->m = NULL;
>>
>> -   _mesa_align_free( m->inv );
>> m->inv = NULL;
>>  }
>>
>> --
>> 2.14.1
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965/fs: retype offset_reg to UD at load_ssbo

2018-04-19 Thread Ian Romanick
On 04/18/2018 01:57 PM, Jose Maria Casanova Crespo wrote:
> All operations with offset_reg at do_vector_read are done
> with UD type. So copy propagation was not working through
> the generated MOVs:
> 
> mov(8) vgrf9:UD, vgrf7:D

I have noticed other cases of this.  Copy propagation doesn't work
across moves that change the type because int->float and float->int
actually change the bit pattern.  unsigned->signed doesn't do anything,
so it seems like we should allow that case.  This is a few steps down on
my to-do list, but if someone else gets to it first...

> This change allows removing the MOV generated for reading the
> first components for 16-bit and 64-bit ssbo reads with
> non-constant offsets.
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp 
> b/src/intel/compiler/brw_fs_nir.cpp
> index 6c4bcd1c113..0ebaab96634 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -4142,7 +4142,7 @@ fs_visitor::nir_emit_intrinsic(const fs_builder &bld, 
> nir_intrinsic_instr *instr
>if (const_offset) {
>   offset_reg = brw_imm_ud(const_offset->u32[0]);
>} else {
> - offset_reg = get_nir_src(instr->src[1]);
> + offset_reg = retype(get_nir_src(instr->src[1]), 
> BRW_REGISTER_TYPE_UD);
>}
>  
>/* Read the vector */
> 

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


[Mesa-dev] [Bug 106133] make check "OSError: [Errno 24] Too many open files"

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106133

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

--- Comment #1 from Dylan Baker  ---
I'll look into this and see what I can do. I have an idea of how I might fix
it, but I'll have to see if I can reproduce this on my mac.

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


[Mesa-dev] [PATCH 2/3] tegra: Fix scanout resources without modifiers

2018-04-19 Thread Thierry Reding
From: Thierry Reding 

Resources created for scanout but without modifiers need to be treated
as pitch-linear. This is because applications that don't use modifiers
to create resources must be assumed to not understand modifiers and in
turn won't be able to create a DRM framebuffer and passing along which
modifiers were picked by the implementation.

Signed-off-by: Thierry Reding 
---
 src/gallium/drivers/tegra/tegra_screen.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 41bf2052f945..8b61c0901600 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -260,6 +260,7 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
  const struct pipe_resource *template)
 {
struct tegra_screen *screen = to_tegra_screen(pscreen);
+   uint64_t modifier = DRM_FORMAT_MOD_INVALID;
struct tegra_resource *resource;
int err;
 
@@ -267,7 +268,23 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
if (!resource)
   return NULL;
 
-   resource->gpu = screen->gpu->resource_create(screen->gpu, template);
+   /*
+* Applications that create scanout resources without modifiers are very
+* unlikely to support modifiers at all. In that case the resources need
+* to be created with a pitch-linear layout so that they can be properly
+* shared with scanout hardware.
+*
+* Technically it is possible for applications to create resources without
+* specifying a modifier but still query the modifier associated with the
+* resource (e.g. using gbm_bo_get_modifier()) before handing it to the
+* framebuffer creation API (such as the DRM_IOCTL_MODE_ADDFB2 IOCTL).
+*/
+   if (template->bind & PIPE_BIND_SCANOUT)
+  modifier = DRM_FORMAT_MOD_LINEAR;
+
+   resource->gpu = screen->gpu->resource_create_with_modifiers(screen->gpu,
+   template,
+   &modifier, 1);
if (!resource->gpu)
   goto free;
 
-- 
2.16.3

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


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

2018-04-19 Thread Thierry Reding
From: Thierry Reding 

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

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

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 669f22a19449..41bf2052f945 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -219,11 +219,9 @@ free:
 }
 
 static int tegra_screen_import_resource(struct tegra_screen *screen,
-struct tegra_resource *resource,
-bool has_modifiers)
+struct tegra_resource *resource)
 {
unsigned usage = PIPE_HANDLE_USAGE_READ;
-   struct drm_tegra_gem_set_tiling args;
struct winsys_handle handle;
boolean status;
int fd, err;
@@ -254,67 +252,6 @@ static int tegra_screen_import_resource(struct 
tegra_screen *screen,
 
close(fd);
 
-   if (!has_modifiers) {
-  memset(&args, 0, sizeof(args));
-  args.handle = resource->handle;
-
-  switch (handle.modifier) {
- case DRM_FORMAT_MOD_NVIDIA_TEGRA_TILED:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_TILED;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_ONE_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 0;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_TWO_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 1;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_FOUR_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 2;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_EIGHT_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 3;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_SIXTEEN_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 4;
-break;
-
- case DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK_THIRTYTWO_GOB:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_BLOCK;
-args.value = 5;
-break;
-
- default:
-debug_printf("unsupported modifier %" PRIx64 ", assuming linear\n",
- handle.modifier);
-/* fall-through */
-
- case DRM_FORMAT_MOD_LINEAR:
-args.mode = DRM_TEGRA_GEM_TILING_MODE_PITCH;
-break;
-  }
-
-  err = drmIoctl(screen->fd, DRM_IOCTL_TEGRA_GEM_SET_TILING, &args);
-  if (err < 0) {
- fprintf(stderr, "failed to set tiling parameters: %s\n",
- strerror(errno));
- err = -errno;
- goto out;
-  }
-   }
-
-   return 0;
-
-out:
return err;
 }
 
@@ -336,7 +273,7 @@ tegra_screen_resource_create(struct pipe_screen *pscreen,
 
/* import scanout buffers for display */
if (template->bind & PIPE_BIND_SCANOUT) {
-  err = tegra_screen_import_resource(screen, resource, false);
+  err = tegra_screen_import_resource(screen, resource);
   if (err < 0)
  goto destroy;
}
@@ -575,7 +512,7 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
if (!resource->gpu)
   goto free;
 
-   err = tegra_screen_import_resource(screen, resource, true);
+   err = tegra_screen_import_resource(screen, resource);
if (err < 0)
   goto destroy;
 
-- 
2.16.3

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


[Mesa-dev] [PATCH 3/3] tegra: Treat resources with modifiers as scanout

2018-04-19 Thread Thierry Reding
From: Thierry Reding 

Resources created with modifiers are treated as scanout because there is
no way for applications to specify the usage (though that capability may
be useful to have in the future). Currently all the resources created by
applications with modifiers are for scanout, so make sure they have bind
flags set accordingly.

This is necessary in order to properly export buffers for such resources
so that they can be shared with scanout hardware.

Signed-off-by: Thierry Reding 
---
 src/gallium/drivers/tegra/tegra_screen.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/tegra/tegra_screen.c 
b/src/gallium/drivers/tegra/tegra_screen.c
index 8b61c0901600..e03e71f81a2a 100644
--- a/src/gallium/drivers/tegra/tegra_screen.c
+++ b/src/gallium/drivers/tegra/tegra_screen.c
@@ -515,6 +515,7 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
 int count)
 {
struct tegra_screen *screen = to_tegra_screen(pscreen);
+   struct pipe_resource tmpl = *template;
struct tegra_resource *resource;
int err;
 
@@ -522,8 +523,18 @@ tegra_screen_resource_create_with_modifiers(struct 
pipe_screen *pscreen,
if (!resource)
   return NULL;
 
+   /*
+* Assume that resources created with modifiers will always be used for
+* scanout. This is necessary because some of the APIs that are used to
+* create resources with modifiers (e.g. gbm_bo_create_with_modifiers())
+* can't pass along usage information. Adding that capability might be
+* worth adding to remove this ambiguity. Not all future use-cases that
+* involve modifiers may always be targetting scanout hardware.
+*/
+   tmpl.bind |= PIPE_BIND_SCANOUT;
+
resource->gpu = screen->gpu->resource_create_with_modifiers(screen->gpu,
-   template,
+   &tmpl,
modifiers,
count);
if (!resource->gpu)
-- 
2.16.3

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


[Mesa-dev] [PATCH 1/3] meson: don't build classic mesa tests without dri_drivers

2018-04-19 Thread Dylan Baker
Since mesa_classic is not build-on-demand the tests will create a demand
and add a bunch of extra compilation.

Fixes: 43a6e84927e3b1290f6f211f5dfb184dfe5a719e
   ("meson: build mesa test.")
Signed-off-by: Dylan Baker 
---
 src/mesa/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index 30954beac54..3100dfc50f6 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -732,6 +732,6 @@ endif
 if with_glx == 'xlib'
   subdir('drivers/x11')
 endif
-if with_tests
+if with_tests and dri_drivers != []
   subdir('main/tests')
 endif
-- 
2.17.0

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


[Mesa-dev] [PATCH 3/3] meson: fix graw-xlib after auxiliary consolidation

2018-04-19 Thread Dylan Baker
This one's completely my fault, I didn't do good enough testing after
rebasing and this got missed.

Fixes: d28c24650110c130008be3d3fe584520ff00ceb1
   ("meson: build graw tests")
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/graw-xlib/meson.build | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/targets/graw-xlib/meson.build 
b/src/gallium/targets/graw-xlib/meson.build
index 4716c543cbc..aab99ba64c1 100644
--- a/src/gallium/targets/graw-xlib/meson.build
+++ b/src/gallium/targets/graw-xlib/meson.build
@@ -21,10 +21,9 @@
 libgraw_xlib = shared_library(
   'graw_xlib',
   ['graw_xlib.c'],
-  c_args : ['-DGALLIUM_TRACE', '-DGALLIUM_RBUG'],
   include_directories : [inc_common, inc_gallium_drivers, inc_gallium_winsys],
   link_with : [
-libgraw_util, libtrace, librbug, libmesa_util, libgallium, libws_xlib
+libgraw_util, libmesa_util, libgallium, libws_xlib
   ],
   dependencies : [dep_thread, driver_swrast],
   version : '1.0',
-- 
2.17.0

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


[Mesa-dev] [PATCH 2/3] meson: only build mesa_st tests when build-tests is true

2018-04-19 Thread Dylan Baker
Since we have an option to turn test building on and off, we should
honor that.

Fixes: 34cb4d0ebc14663113705beae63dd52b9d1b2d87
   ("meson: build tests for gallium mesa state tracker")
Signed-off-by: Dylan Baker 
---
 src/meson.build | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/meson.build b/src/meson.build
index 5d8d554d711..c2566b7a687 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -82,7 +82,9 @@ if with_gallium
   subdir('gallium')
   # This has to be here since it requires libgallium, and subdir cannot
   # contain ..
-  subdir('mesa/state_tracker/tests')
+  if with_tests
+subdir('mesa/state_tracker/tests')
+  endif
 endif
 
 # This must be after at least mesa, glx, and gallium, since libgl will be
-- 
2.17.0

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


[Mesa-dev] [Bug 106131] meson/ninja build missing file gtest.h

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106131

Dylan Baker  changed:

   What|Removed |Added

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

--- Comment #2 from Dylan Baker  ---
dffdef67370..051fddb4a9e  master -> master

-- 
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] meson: Build st_tests_common with gtest

2018-04-19 Thread Dylan Baker
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106131
Reviewed-by: Dylan Baker 

I'll go ahead and push this with the added bugzilla tag, thanks!

Dylan

Quoting Mike Lothian (2018-04-19 02:02:39)
> Fixes: 34cb4d0ebc1 ("meson: build tests for gallium mesa state tracker")
> 
> Signed-off-by: Mike Lothian 
> ---
>  src/mesa/state_tracker/tests/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/state_tracker/tests/meson.build 
> b/src/mesa/state_tracker/tests/meson.build
> index f62039ef1e..0f84513209 100644
> --- a/src/mesa/state_tracker/tests/meson.build
> +++ b/src/mesa/state_tracker/tests/meson.build
> @@ -22,7 +22,7 @@ libmesa_st_test_common = static_library(
>'mesa_st_test_common',
>['st_tests_common.cpp', ir_expression_operation_h],
>include_directories : inc_common,
> -  dependencies : dep_thread,
> +  dependencies : [dep_thread, idep_gtest],
>  )
>  
>  test(
> -- 
> 2.17.0
> 


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


[Mesa-dev] [PATCH v2 2/3] radv: use a global BO list only for VK_EXT_descriptor_indexing

2018-04-19 Thread Samuel Pitoiset
Maintaining two different paths is annoying but this gets
rid of the performance regression introduced by the global
BO list.

We might find a better solution in the future, but for now
just keeps two paths.

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

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 14ecbd02001..2c643ae086b 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1299,8 +1299,14 @@ radv_bo_list_finish(struct radv_bo_list *bo_list)
pthread_mutex_destroy(&bo_list->mutex);
 }
 
-static VkResult radv_bo_list_add(struct radv_bo_list *bo_list, struct 
radeon_winsys_bo *bo)
+static VkResult radv_bo_list_add(struct radv_device *device,
+struct radeon_winsys_bo *bo)
 {
+   struct radv_bo_list *bo_list = &device->bo_list;
+
+   if (unlikely(!device->use_global_bo_list))
+   return VK_SUCCESS;
+
pthread_mutex_lock(&bo_list->mutex);
if (bo_list->list.count == bo_list->capacity) {
unsigned capacity = MAX2(4, bo_list->capacity * 2);
@@ -1320,8 +1326,14 @@ static VkResult radv_bo_list_add(struct radv_bo_list 
*bo_list, struct radeon_win
return VK_SUCCESS;
 }
 
-static void radv_bo_list_remove(struct radv_bo_list *bo_list, struct 
radeon_winsys_bo *bo)
+static void radv_bo_list_remove(struct radv_device *device,
+   struct radeon_winsys_bo *bo)
 {
+   struct radv_bo_list *bo_list = &device->bo_list;
+
+   if (unlikely(!device->use_global_bo_list))
+   return;
+
pthread_mutex_lock(&bo_list->mutex);
for(unsigned i = 0; i < bo_list->list.count; ++i) {
if (bo_list->list.bos[i] == bo) {
@@ -1430,6 +1442,12 @@ VkResult radv_CreateDevice(
 
keep_shader_info = device->enabled_extensions.AMD_shader_info;
 
+   /* With update after bind we can't attach bo's to the command buffer
+* from the descriptor set anymore, so we have to use a global BO list.
+*/
+   device->use_global_bo_list =
+   device->enabled_extensions.EXT_descriptor_indexing;
+
mtx_init(&device->shader_slab_mutex, mtx_plain);
list_inithead(&device->shader_slabs);
 
@@ -2502,14 +2520,16 @@ VkResult radv_QueueSubmit(
sem_info.cs_emit_wait = j == 0;
sem_info.cs_emit_signal = j + advance == 
pSubmits[i].commandBufferCount;
 
-   pthread_mutex_lock(&queue->device->bo_list.mutex);
+   if (unlikely(queue->device->use_global_bo_list))
+   
pthread_mutex_lock(&queue->device->bo_list.mutex);
 
ret = queue->device->ws->cs_submit(ctx, 
queue->queue_idx, cs_array + j,
advance, 
initial_preamble, continue_preamble_cs,
&sem_info, 
&queue->device->bo_list.list,
can_patch, base_fence);
 
-   pthread_mutex_unlock(&queue->device->bo_list.mutex);
+   if (unlikely(queue->device->use_global_bo_list))
+   
pthread_mutex_unlock(&queue->device->bo_list.mutex);
 
if (ret) {
radv_loge("failed to submit CS %d\n", i);
@@ -2757,7 +2777,7 @@ static VkResult radv_alloc_memory(struct radv_device 
*device,
mem->type_index = mem_type_index;
}
 
-   result = radv_bo_list_add(&device->bo_list, mem->bo);
+   result = radv_bo_list_add(device, mem->bo);
if (result != VK_SUCCESS)
goto fail_bo;
 
@@ -2794,7 +2814,7 @@ void radv_FreeMemory(
if (mem == NULL)
return;
 
-   radv_bo_list_remove(&device->bo_list, mem->bo);
+   radv_bo_list_remove(device, mem->bo);
device->ws->buffer_destroy(mem->bo);
mem->bo = NULL;
 
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index dfe4c5f9422..883342ede88 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -670,6 +670,9 @@ struct radv_device {
 
struct radv_device_extension_table enabled_extensions;
 
+   /* Whether the driver uses a global BO list. */
+   bool use_global_bo_list;
+
struct radv_bo_list bo_list;
 };
 
-- 
2.17.0

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


[Mesa-dev] [PATCH v2 1/3] Revert "radv: Don't store buffer references in the descriptor set."

2018-04-19 Thread Samuel Pitoiset
In order to reduce a performance regression introduced by
4b13fe55a4 ("radv: Keep a global BO list for VkMemory."),
we are going to maintain two different paths.

One when VK_EXT_descriptor_indexing is enabled by the
application because we need to have a global BO list, and
one (the old one) when it's not enabled.

With Talos on Polaris, the global BO list reduces performance
by 10% which is too much for me.

This reverts commit ab6cadd3ecc7fbdd9079808b407674e0b19c52f0.
---
 src/amd/vulkan/radv_cmd_buffer.c |  4 ++
 src/amd/vulkan/radv_debug.c  |  3 +
 src/amd/vulkan/radv_descriptor_set.c | 82 +++-
 src/amd/vulkan/radv_descriptor_set.h |  4 ++
 src/amd/vulkan/radv_private.h|  2 +
 5 files changed, 82 insertions(+), 13 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f6b23f6e739..72fb6d63576 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2206,6 +2206,10 @@ radv_bind_descriptor_set(struct radv_cmd_buffer 
*cmd_buffer,
 
assert(!(set->layout->flags & 
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR));
 
+   for (unsigned j = 0; j < set->layout->buffer_count; ++j)
+   if (set->descriptors[j])
+   radv_cs_add_buffer(ws, cmd_buffer->cs, 
set->descriptors[j], 7);
+
if(set->bo)
radv_cs_add_buffer(ws, cmd_buffer->cs, set->bo, 8);
 }
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index 2e9e0165237..368bc4b5d05 100644
--- a/src/amd/vulkan/radv_debug.c
+++ b/src/amd/vulkan/radv_debug.c
@@ -250,6 +250,7 @@ radv_dump_descriptor_set(enum chip_class chip_class,
fprintf(f, "\tshader_stages: %x\n", layout->shader_stages);
fprintf(f, "\tdynamic_shader_stages: %x\n",
layout->dynamic_shader_stages);
+   fprintf(f, "\tbuffer_count: %d\n", layout->buffer_count);
fprintf(f, "\tdynamic_offset_count: %d\n",
layout->dynamic_offset_count);
fprintf(f, "\n");
@@ -265,6 +266,8 @@ radv_dump_descriptor_set(enum chip_class chip_class,
layout->binding[i].array_size);
fprintf(f, "\t\toffset: %d\n",
layout->binding[i].offset);
+   fprintf(f, "\t\tbuffer_offset: %d\n",
+   layout->binding[i].buffer_offset);
fprintf(f, "\t\tdynamic_offset_offset: %d\n",
layout->binding[i].dynamic_offset_offset);
fprintf(f, "\t\tdynamic_offset_count: %d\n",
diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index 55b4aaa388c..4b08a1f0f80 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -117,12 +117,14 @@ VkResult radv_CreateDescriptorSetLayout(
 
memset(set_layout->binding, 0, size - sizeof(struct 
radv_descriptor_set_layout));
 
+   uint32_t buffer_count = 0;
uint32_t dynamic_offset_count = 0;
 
for (uint32_t j = 0; j < pCreateInfo->bindingCount; j++) {
const VkDescriptorSetLayoutBinding *binding = bindings + j;
uint32_t b = binding->binding;
uint32_t alignment;
+   unsigned binding_buffer_count = 0;
 
switch (binding->descriptorType) {
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC:
@@ -131,6 +133,7 @@ VkResult radv_CreateDescriptorSetLayout(
set_layout->binding[b].dynamic_offset_count = 1;
set_layout->dynamic_shader_stages |= 
binding->stageFlags;
set_layout->binding[b].size = 0;
+   binding_buffer_count = 1;
alignment = 1;
break;
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER:
@@ -138,6 +141,7 @@ VkResult radv_CreateDescriptorSetLayout(
case VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER:
case VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER:
set_layout->binding[b].size = 16;
+   binding_buffer_count = 1;
alignment = 16;
break;
case VK_DESCRIPTOR_TYPE_STORAGE_IMAGE:
@@ -145,11 +149,13 @@ VkResult radv_CreateDescriptorSetLayout(
case VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT:
/* main descriptor + fmask descriptor */
set_layout->binding[b].size = 64;
+   binding_buffer_count = 1;
alignment = 32;
break;
case VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER:
/* main descriptor + fmask descriptor + sampler */
set_layout->binding[b].size = 96;
+   binding_buffer_count = 1;
alignment = 32;
break;

[Mesa-dev] [PATCH v2 3/3] radv/winsys: allow local BOs on APUs

2018-04-19 Thread Samuel Pitoiset
Ported from RadeonSI.

Local BOs ignore BO priorities, and we don't need those on APUs.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index 32f263adddc..e2060651e48 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -347,7 +347,8 @@ radv_amdgpu_winsys_bo_create(struct radeon_winsys *_ws,
request.flags |= AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (!(flags & RADEON_FLAG_IMPLICIT_SYNC) && ws->info.drm_minor >= 22)
request.flags |= AMDGPU_GEM_CREATE_EXPLICIT_SYNC;
-   if (flags & RADEON_FLAG_NO_INTERPROCESS_SHARING && ws->info.drm_minor 
>= 20 && ws->use_local_bos) {
+   if (flags & RADEON_FLAG_NO_INTERPROCESS_SHARING &&
+   ws->info.has_local_buffers && ws->use_local_bos) {
bo->base.is_local = true;
request.flags |= AMDGPU_GEM_CREATE_VM_ALWAYS_VALID;
}
-- 
2.17.0

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


[Mesa-dev] [PATCH v3 1/3] intel: fix check for 48b ppgtt support

2018-04-19 Thread Scott D Phillips
The previous logic of the supports_48b_addresses wasn't actually
checking if i915.ko was running with full_48bit_ppgtt. The ENOENT
it was checking for was actually coming from the invalid context
id provided in the test execbuffer.  There is no path in the
kernel driver where the presence of
EXEC_OBJECT_SUPPORTS_48B_ADDRESS leads to an error.

Instead, check the default context's GTT_SIZE param for a value
greater than 4 GiB

v2 (Ken): Fix in i965 as well.
v3 Check GTT_SIZE instead of HAS_ALIASING_PPGTT (Chris Wilson)
---
 src/intel/vulkan/anv_device.c  | 42 +++---
 src/intel/vulkan/anv_gem.c | 18 ---
 src/intel/vulkan/anv_gem_stubs.c   |  6 -
 src/intel/vulkan/anv_private.h |  1 -
 src/mesa/drivers/dri/i965/brw_bufmgr.c | 28 ---
 5 files changed, 34 insertions(+), 61 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 7522b7865c2..a28ed3fbaaf 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -58,23 +58,8 @@ compiler_perf_log(void *data, const char *fmt, ...)
 }
 
 static VkResult
-anv_compute_heap_size(int fd, uint64_t *heap_size)
+anv_compute_heap_size(int fd, uint64_t gtt_size, uint64_t *heap_size)
 {
-   uint64_t gtt_size;
-   if (anv_gem_get_context_param(fd, 0, I915_CONTEXT_PARAM_GTT_SIZE,
- >t_size) == -1) {
-  /* If, for whatever reason, we can't actually get the GTT size from the
-   * kernel (too old?) fall back to the aperture size.
-   */
-  anv_perf_warn(NULL, NULL,
-"Failed to get I915_CONTEXT_PARAM_GTT_SIZE: %m");
-
-  if (anv_gem_get_aperture(fd, >t_size) == -1) {
- return vk_errorf(NULL, NULL, VK_ERROR_INITIALIZATION_FAILED,
-  "failed to get aperture size: %m");
-  }
-   }
-
/* Query the total ram from the system */
struct sysinfo info;
sysinfo(&info);
@@ -103,15 +88,26 @@ anv_compute_heap_size(int fd, uint64_t *heap_size)
 static VkResult
 anv_physical_device_init_heaps(struct anv_physical_device *device, int fd)
 {
-   /* The kernel query only tells us whether or not the kernel supports the
-* EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag and not whether or not the
-* hardware has actual 48bit address support.
-*/
-   device->supports_48bit_addresses =
-  (device->info.gen >= 8) && anv_gem_supports_48b_addresses(fd);
+   uint64_t gtt_size;
+   if (anv_gem_get_context_param(fd, 0, I915_CONTEXT_PARAM_GTT_SIZE,
+ >t_size) == -1) {
+  /* If, for whatever reason, we can't actually get the GTT size from the
+   * kernel (too old?) fall back to the aperture size.
+   */
+  anv_perf_warn(NULL, NULL,
+"Failed to get I915_CONTEXT_PARAM_GTT_SIZE: %m");
+
+  if (anv_gem_get_aperture(fd, >t_size) == -1) {
+ return vk_errorf(NULL, NULL, VK_ERROR_INITIALIZATION_FAILED,
+  "failed to get aperture size: %m");
+  }
+   }
+
+   device->supports_48bit_addresses = (device->info.gen >= 8) &&
+  gtt_size > (4ULL << 30 /* GiB */);
 
uint64_t heap_size = 0;
-   VkResult result = anv_compute_heap_size(fd, &heap_size);
+   VkResult result = anv_compute_heap_size(fd, gtt_size, &heap_size);
if (result != VK_SUCCESS)
   return result;
 
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 2a8f8b14b7e..3ba6d198a8a 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -377,24 +377,6 @@ anv_gem_get_aperture(int fd, uint64_t *size)
return 0;
 }
 
-bool
-anv_gem_supports_48b_addresses(int fd)
-{
-   struct drm_i915_gem_exec_object2 obj = {
-  .flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS,
-   };
-
-   struct drm_i915_gem_execbuffer2 execbuf = {
-  .buffers_ptr = (uintptr_t)&obj,
-  .buffer_count = 1,
-  .rsvd1 = 0xffu,
-   };
-
-   int ret = anv_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
-
-   return ret == -1 && errno == ENOENT;
-}
-
 int
 anv_gem_gpu_get_reset_stats(struct anv_device *device,
 uint32_t *active, uint32_t *pending)
diff --git a/src/intel/vulkan/anv_gem_stubs.c b/src/intel/vulkan/anv_gem_stubs.c
index 0f4a3f5da00..5093bd5db1a 100644
--- a/src/intel/vulkan/anv_gem_stubs.c
+++ b/src/intel/vulkan/anv_gem_stubs.c
@@ -170,12 +170,6 @@ anv_gem_get_aperture(int fd, uint64_t *size)
unreachable("Unused");
 }
 
-bool
-anv_gem_supports_48b_addresses(int fd)
-{
-   unreachable("Unused");
-}
-
 int
 anv_gem_gpu_get_reset_stats(struct anv_device *device,
 uint32_t *active, uint32_t *pending)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 52d4ba58dc9..d8b34b149e4 100644
--- a/src/intel/vulkan/anv_private.h
+++ b/src/intel/vulkan/anv_private.h
@@ -956,7 +956,6 @@ int anv_gem_get_param(int fd, uint32_t param);
 int anv_gem_get_tiling(struct

[Mesa-dev] [PATCH] i965/urb/cnl: Apply gen7 CS stall

2018-04-19 Thread Topi Pohjolainen
This didn't actually help the failing tests I'm looking at
but hopefully has teeth elsewhere.

CC: Jason Ekstrand 
CC: Jordan Justen 
CC: Anuj Phogat 
Signed-off-by: Topi Pohjolainen 
---
 src/mesa/drivers/dri/i965/gen7_urb.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c 
b/src/mesa/drivers/dri/i965/gen7_urb.c
index 2e5f8e6..9e12657 100644
--- a/src/mesa/drivers/dri/i965/gen7_urb.c
+++ b/src/mesa/drivers/dri/i965/gen7_urb.c
@@ -145,8 +145,15 @@ gen7_emit_push_constant_state(struct brw_context *brw, 
unsigned vs_size,
 * in the ring after this instruction.
 *
 * No such restriction exists for Haswell or Baytrail.
+*
+* From the CNL Bspec, Windower -
+* 3DSTATE_PUSH_CONSTANT_ALLOC_PS/VS/GS/DS/HS:
+* 
+* This command must be followed by a PIPE_CONTROL with CS Stall bit
+* set.
 */
-   if (devinfo->gen < 8 && !devinfo->is_haswell && !devinfo->is_baytrail)
+   if ((devinfo->gen < 8 && !devinfo->is_haswell && !devinfo->is_baytrail) ||
+   devinfo->gen >= 10)
   gen7_emit_cs_stall_flush(brw);
 }
 
-- 
2.7.4

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


Re: [Mesa-dev] [PATCH] travis: radv needs LLVM 4.0

2018-04-19 Thread Bas Nieuwenhuizen
No clue about travis, but from RADV side

Acked-by: Bas Nieuwenhuizen 

Thanks!

On Thu, Apr 19, 2018 at 4:18 PM, Juan A. Suarez Romero
 wrote:
> This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
> need LLVM 4.0") that fixes Travis build with meson + vulkan.
>
> CC: 18.0 
> ---
>  .travis.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 84de1353859..e4858dc9173 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -39,12 +39,12 @@ matrix:
>addons:
>  apt:
>sources:
> -- llvm-toolchain-trusty-3.9
> +- llvm-toolchain-trusty-4.0
>packages:
>  # LLVM packaging is broken and misses these dependencies
>  - libedit-dev
>  # From sources above
> -- llvm-3.9-dev
> +- llvm-4.0-dev
>  # Common
>  - xz-utils
>  - libexpat1-dev
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] travis: radv needs LLVM 4.0

2018-04-19 Thread Juan A. Suarez Romero
Sorry, sent this very same patch twice.

J.A.

On Thu, 2018-04-19 at 16:18 +0200, Juan A. Suarez Romero wrote:
> This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
> need LLVM 4.0") that fixes Travis build with meson + vulkan.
> 
> CC: 18.0 
> ---
>  .travis.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 84de1353859..e4858dc9173 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -39,12 +39,12 @@ matrix:
>addons:
>  apt:
>sources:
> -- llvm-toolchain-trusty-3.9
> +- llvm-toolchain-trusty-4.0
>packages:
>  # LLVM packaging is broken and misses these dependencies
>  - libedit-dev
>  # From sources above
> -- llvm-3.9-dev
> +- llvm-4.0-dev
>  # Common
>  - xz-utils
>  - libexpat1-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] travis: radv needs LLVM 4.0

2018-04-19 Thread Juan A. Suarez Romero
This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
need LLVM 4.0") that fixes Travis build with meson + vulkan.

CC: "18.0" 
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 84de1353859..e4858dc9173 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -39,12 +39,12 @@ matrix:
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-3.9
+- llvm-toolchain-trusty-4.0
   packages:
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-3.9-dev
+- llvm-4.0-dev
 # Common
 - xz-utils
 - libexpat1-dev
-- 
2.14.3

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


[Mesa-dev] [PATCH] travis: radv needs LLVM 4.0

2018-04-19 Thread Juan A. Suarez Romero
This is a backport for 18.0 from 6ce400782c ("travis: radeonsi and radv
need LLVM 4.0") that fixes Travis build with meson + vulkan.

CC: 18.0 
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 84de1353859..e4858dc9173 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -39,12 +39,12 @@ matrix:
   addons:
 apt:
   sources:
-- llvm-toolchain-trusty-3.9
+- llvm-toolchain-trusty-4.0
   packages:
 # LLVM packaging is broken and misses these dependencies
 - libedit-dev
 # From sources above
-- llvm-3.9-dev
+- llvm-4.0-dev
 # Common
 - xz-utils
 - libexpat1-dev
-- 
2.14.3

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


[Mesa-dev] [PATCH 4/4] radv/winsys: allow local BOs on APUs

2018-04-19 Thread Samuel Pitoiset
Ported from RadeonSI.

Local BOs ignore BO priorities, and we don't need those on APUs.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c 
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
index 32f263addd..e2060651e4 100644
--- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
+++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_bo.c
@@ -347,7 +347,8 @@ radv_amdgpu_winsys_bo_create(struct radeon_winsys *_ws,
request.flags |= AMDGPU_GEM_CREATE_CPU_GTT_USWC;
if (!(flags & RADEON_FLAG_IMPLICIT_SYNC) && ws->info.drm_minor >= 22)
request.flags |= AMDGPU_GEM_CREATE_EXPLICIT_SYNC;
-   if (flags & RADEON_FLAG_NO_INTERPROCESS_SHARING && ws->info.drm_minor 
>= 20 && ws->use_local_bos) {
+   if (flags & RADEON_FLAG_NO_INTERPROCESS_SHARING &&
+   ws->info.has_local_buffers && ws->use_local_bos) {
bo->base.is_local = true;
request.flags |= AMDGPU_GEM_CREATE_VM_ALWAYS_VALID;
}
-- 
2.17.0

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


[Mesa-dev] [PATCH] svga: Fix incorrect advertizing of EGL_KHR_gl_colorspace

2018-04-19 Thread Thomas Hellstrom
When advertizing this extension, egl_dri2 uses the DRI2_RENDERER_QUERY
extension to query whether an sRGB format is supported. That extension will
query our driver with the BIND flag PIPE_BIND_RENDER_TARGET rather than
PIPE_BIND_DISPLAY_TARGET which is used when building the configs.
We only return the correct value for PIPE_BIND_DISPLAY_TARGET.

The inconsistency causes EGL to crash at surface initialization if sRGB is
not supported. Fix this by supporting both bind flags.

Testing done:
piglit egl_gl_colorspace srgb

Cc: 
Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Charmaine Lee 
---
 src/gallium/drivers/svga/svga_format.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index 20a6e6b159f..c9adee11afb 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -2107,7 +2107,7 @@ svga_is_format_supported(struct pipe_screen *screen,
 
if (!ss->sws->have_vgpu10 &&
util_format_is_srgb(format) &&
-   (bindings & PIPE_BIND_DISPLAY_TARGET)) {
+   (bindings & (PIPE_BIND_DISPLAY_TARGET | PIPE_BIND_RENDER_TARGET))) {
/* We only support sRGB rendering with vgpu10 */
   return FALSE;
}
-- 
2.14.3

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


[Mesa-dev] [PATCH 2/4] radv: add radv_cmd_buffer_add_buffer() helper

2018-04-19 Thread Samuel Pitoiset
This helper adds buffers created by the application to the
global BO list, while radv_cs_add_buffer() is called directly
for adding BOs created by the driver. This will allow us to
improve the global BO list path a little bit.

Because the priority is quite useless I removed the parameter.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 40 +---
 src/amd/vulkan/radv_descriptor_set.c |  6 ++---
 src/amd/vulkan/radv_meta_buffer.c|  8 +++---
 src/amd/vulkan/radv_private.h| 13 +
 4 files changed, 39 insertions(+), 28 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 72fb6d6357..412c35c1ca 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -839,13 +839,13 @@ radv_emit_graphics_pipeline(struct radv_cmd_buffer 
*cmd_buffer)
if (!pipeline->shaders[i])
continue;
 
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
-  pipeline->shaders[i]->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer,
+  pipeline->shaders[i]->bo);
}
 
if (radv_pipeline_has_gs(pipeline))
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
-  pipeline->gs_copy_shader->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer,
+  pipeline->gs_copy_shader->bo);
 
if (unlikely(cmd_buffer->device->trace_bo))
radv_save_pipeline(cmd_buffer, pipeline, RING_GFX);
@@ -1255,7 +1255,7 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
*cmd_buffer)
struct radv_image *image = att->attachment->image;
VkImageLayout layout = subpass->color_attachments[i].layout;
 
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs, 
att->attachment->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer, att->attachment->bo);
 
assert(att->attachment->aspect_mask & 
VK_IMAGE_ASPECT_COLOR_BIT);
radv_emit_fb_color_state(cmd_buffer, i, att, image, layout);
@@ -1268,7 +1268,7 @@ radv_emit_framebuffer_state(struct radv_cmd_buffer 
*cmd_buffer)
VkImageLayout layout = subpass->depth_stencil_attachment.layout;
struct radv_attachment_info *att = 
&framebuffer->attachments[idx];
struct radv_image *image = att->attachment->image;
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs, 
att->attachment->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer, att->attachment->bo);
MAYBE_UNUSED uint32_t queue_mask = 
radv_image_queue_family_mask(image,

cmd_buffer->queue_family_index,

cmd_buffer->queue_family_index);
@@ -2152,8 +2152,7 @@ void radv_CmdBindVertexBuffers(
vb[idx].buffer = radv_buffer_from_handle(pBuffers[i]);
vb[idx].offset = pOffsets[i];
 
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs,
-  vb[idx].buffer->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer, vb[idx].buffer->bo);
}
 
if (!changed) {
@@ -2189,7 +2188,7 @@ void radv_CmdBindIndexBuffer(
int index_size_shift = cmd_buffer->state.index_type ? 2 : 1;
cmd_buffer->state.max_index_count = (index_buffer->size - offset) >> 
index_size_shift;
cmd_buffer->state.dirty |= RADV_CMD_DIRTY_INDEX_BUFFER;
-   radv_cs_add_buffer(cmd_buffer->device->ws, cmd_buffer->cs, 
index_buffer->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer, index_buffer->bo);
 }
 
 
@@ -2198,8 +2197,6 @@ radv_bind_descriptor_set(struct radv_cmd_buffer 
*cmd_buffer,
 VkPipelineBindPoint bind_point,
 struct radv_descriptor_set *set, unsigned idx)
 {
-   struct radeon_winsys *ws = cmd_buffer->device->ws;
-
radv_set_descriptor_set(cmd_buffer, bind_point, set, idx);
if (!set)
return;
@@ -2208,10 +2205,11 @@ radv_bind_descriptor_set(struct radv_cmd_buffer 
*cmd_buffer,
 
for (unsigned j = 0; j < set->layout->buffer_count; ++j)
if (set->descriptors[j])
-   radv_cs_add_buffer(ws, cmd_buffer->cs, 
set->descriptors[j], 7);
+   radv_cmd_buffer_add_buffer(cmd_buffer,
+  set->descriptors[j]);
 
if(set->bo)
-   radv_cs_add_buffer(ws, cmd_buffer->cs, set->bo, 8);
+   radv_cmd_buffer_add_buffer(cmd_buffer, set->bo);
 }
 
 void radv_CmdBindDescriptorSets(
@@ -2425,8 +2423,8 @@ radv_emit_compute_pipeline(struct radv_cmd_buffe

[Mesa-dev] [PATCH 3/4] radv: use a global BO list only for VK_EXT_descriptor_indexing

2018-04-19 Thread Samuel Pitoiset
Maintaining two different paths is annoying but this gets
rid of the performance regression introduced by the global
BO list.

We might find a better solution in the future, but for now
just keeps two paths.

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

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 14ecbd0200..2c643ae086 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1299,8 +1299,14 @@ radv_bo_list_finish(struct radv_bo_list *bo_list)
pthread_mutex_destroy(&bo_list->mutex);
 }
 
-static VkResult radv_bo_list_add(struct radv_bo_list *bo_list, struct 
radeon_winsys_bo *bo)
+static VkResult radv_bo_list_add(struct radv_device *device,
+struct radeon_winsys_bo *bo)
 {
+   struct radv_bo_list *bo_list = &device->bo_list;
+
+   if (unlikely(!device->use_global_bo_list))
+   return VK_SUCCESS;
+
pthread_mutex_lock(&bo_list->mutex);
if (bo_list->list.count == bo_list->capacity) {
unsigned capacity = MAX2(4, bo_list->capacity * 2);
@@ -1320,8 +1326,14 @@ static VkResult radv_bo_list_add(struct radv_bo_list 
*bo_list, struct radeon_win
return VK_SUCCESS;
 }
 
-static void radv_bo_list_remove(struct radv_bo_list *bo_list, struct 
radeon_winsys_bo *bo)
+static void radv_bo_list_remove(struct radv_device *device,
+   struct radeon_winsys_bo *bo)
 {
+   struct radv_bo_list *bo_list = &device->bo_list;
+
+   if (unlikely(!device->use_global_bo_list))
+   return;
+
pthread_mutex_lock(&bo_list->mutex);
for(unsigned i = 0; i < bo_list->list.count; ++i) {
if (bo_list->list.bos[i] == bo) {
@@ -1430,6 +1442,12 @@ VkResult radv_CreateDevice(
 
keep_shader_info = device->enabled_extensions.AMD_shader_info;
 
+   /* With update after bind we can't attach bo's to the command buffer
+* from the descriptor set anymore, so we have to use a global BO list.
+*/
+   device->use_global_bo_list =
+   device->enabled_extensions.EXT_descriptor_indexing;
+
mtx_init(&device->shader_slab_mutex, mtx_plain);
list_inithead(&device->shader_slabs);
 
@@ -2502,14 +2520,16 @@ VkResult radv_QueueSubmit(
sem_info.cs_emit_wait = j == 0;
sem_info.cs_emit_signal = j + advance == 
pSubmits[i].commandBufferCount;
 
-   pthread_mutex_lock(&queue->device->bo_list.mutex);
+   if (unlikely(queue->device->use_global_bo_list))
+   
pthread_mutex_lock(&queue->device->bo_list.mutex);
 
ret = queue->device->ws->cs_submit(ctx, 
queue->queue_idx, cs_array + j,
advance, 
initial_preamble, continue_preamble_cs,
&sem_info, 
&queue->device->bo_list.list,
can_patch, base_fence);
 
-   pthread_mutex_unlock(&queue->device->bo_list.mutex);
+   if (unlikely(queue->device->use_global_bo_list))
+   
pthread_mutex_unlock(&queue->device->bo_list.mutex);
 
if (ret) {
radv_loge("failed to submit CS %d\n", i);
@@ -2757,7 +2777,7 @@ static VkResult radv_alloc_memory(struct radv_device 
*device,
mem->type_index = mem_type_index;
}
 
-   result = radv_bo_list_add(&device->bo_list, mem->bo);
+   result = radv_bo_list_add(device, mem->bo);
if (result != VK_SUCCESS)
goto fail_bo;
 
@@ -2794,7 +2814,7 @@ void radv_FreeMemory(
if (mem == NULL)
return;
 
-   radv_bo_list_remove(&device->bo_list, mem->bo);
+   radv_bo_list_remove(device, mem->bo);
device->ws->buffer_destroy(mem->bo);
mem->bo = NULL;
 
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 7c896b0d0e..3ff0d1200f 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -670,6 +670,9 @@ struct radv_device {
 
struct radv_device_extension_table enabled_extensions;
 
+   /* Whether the driver uses a global BO list. */
+   bool use_global_bo_list;
+
struct radv_bo_list bo_list;
 };
 
@@ -1047,6 +1050,9 @@ radv_cmd_buffer_add_buffer(struct radv_cmd_buffer 
*cmd_buffer,
struct radeon_winsys *ws = cmd_buffer->device->ws;
struct radeon_winsys_cs *cs = cmd_buffer->cs;
 
+   if (unlikely(cmd_buffer->device->use_global_bo_list))
+   return;
+
ws->cs_add_buffer(cs, bo, 8);
 }
 
-- 
2.17.0

___
mesa-dev mai

[Mesa-dev] [PATCH 1/4] Revert "radv: Don't store buffer references in the descriptor set."

2018-04-19 Thread Samuel Pitoiset
In order to reduce a performance regression introduced by
4b13fe55a4 ("radv: Keep a global BO list for VkMemory."),
we are going to maintain two different paths.

One when VK_EXT_descriptor_indexing is enabled by the
application because we need to have a global BO list, and
one (the old one) when it's not enabled.

With Talos on Polaris, the global BO list reduces performance
by 10% which is too much for me.

This reverts commit ab6cadd3ecc7fbdd9079808b407674e0b19c52f0.
---
 src/amd/vulkan/radv_cmd_buffer.c |  4 ++
 src/amd/vulkan/radv_debug.c  |  3 +
 src/amd/vulkan/radv_descriptor_set.c | 82 +++-
 src/amd/vulkan/radv_descriptor_set.h |  4 ++
 src/amd/vulkan/radv_private.h|  2 +
 5 files changed, 82 insertions(+), 13 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f6b23f6e73..72fb6d6357 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2206,6 +2206,10 @@ radv_bind_descriptor_set(struct radv_cmd_buffer 
*cmd_buffer,
 
assert(!(set->layout->flags & 
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR));
 
+   for (unsigned j = 0; j < set->layout->buffer_count; ++j)
+   if (set->descriptors[j])
+   radv_cs_add_buffer(ws, cmd_buffer->cs, 
set->descriptors[j], 7);
+
if(set->bo)
radv_cs_add_buffer(ws, cmd_buffer->cs, set->bo, 8);
 }
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index 2e9e016523..368bc4b5d0 100644
--- a/src/amd/vulkan/radv_debug.c
+++ b/src/amd/vulkan/radv_debug.c
@@ -250,6 +250,7 @@ radv_dump_descriptor_set(enum chip_class chip_class,
fprintf(f, "\tshader_stages: %x\n", layout->shader_stages);
fprintf(f, "\tdynamic_shader_stages: %x\n",
layout->dynamic_shader_stages);
+   fprintf(f, "\tbuffer_count: %d\n", layout->buffer_count);
fprintf(f, "\tdynamic_offset_count: %d\n",
layout->dynamic_offset_count);
fprintf(f, "\n");
@@ -265,6 +266,8 @@ radv_dump_descriptor_set(enum chip_class chip_class,
layout->binding[i].array_size);
fprintf(f, "\t\toffset: %d\n",
layout->binding[i].offset);
+   fprintf(f, "\t\tbuffer_offset: %d\n",
+   layout->binding[i].buffer_offset);
fprintf(f, "\t\tdynamic_offset_offset: %d\n",
layout->binding[i].dynamic_offset_offset);
fprintf(f, "\t\tdynamic_offset_count: %d\n",
diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index 55b4aaa388..4b08a1f0f8 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -117,12 +117,14 @@ VkResult radv_CreateDescriptorSetLayout(
 
memset(set_layout->binding, 0, size - sizeof(struct 
radv_descriptor_set_layout));
 
+   uint32_t buffer_count = 0;
uint32_t dynamic_offset_count = 0;
 
for (uint32_t j = 0; j < pCreateInfo->bindingCount; j++) {
const VkDescriptorSetLayoutBinding *binding = bindings + j;
uint32_t b = binding->binding;
uint32_t alignment;
+   unsigned binding_buffer_count = 0;
 
switch (binding->descriptorType) {
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC:
@@ -131,6 +133,7 @@ VkResult radv_CreateDescriptorSetLayout(
set_layout->binding[b].dynamic_offset_count = 1;
set_layout->dynamic_shader_stages |= 
binding->stageFlags;
set_layout->binding[b].size = 0;
+   binding_buffer_count = 1;
alignment = 1;
break;
case VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER:
@@ -138,6 +141,7 @@ VkResult radv_CreateDescriptorSetLayout(
case VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER:
case VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER:
set_layout->binding[b].size = 16;
+   binding_buffer_count = 1;
alignment = 16;
break;
case VK_DESCRIPTOR_TYPE_STORAGE_IMAGE:
@@ -145,11 +149,13 @@ VkResult radv_CreateDescriptorSetLayout(
case VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT:
/* main descriptor + fmask descriptor */
set_layout->binding[b].size = 64;
+   binding_buffer_count = 1;
alignment = 32;
break;
case VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER:
/* main descriptor + fmask descriptor + sampler */
set_layout->binding[b].size = 96;
+   binding_buffer_count = 1;
alignment = 32;
break;
  

[Mesa-dev] [Bug 100629] No mans sky renders white screen under wine in linux

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100629

--- Comment #14 from freedesk...@bremsspur.org ---
(In reply to Timothy Arceri from comment #13)
> The trace is complaining when I try to run it in compat.
> 
> "error: context mismatch: expected OpenGL 4.4 core, but got OpenGL 4.5
> compat"
> 
> You probably need to capture it with these set also:
> 
> MESA_GL_VERSION_OVERRIDE=4.5COMPAT MESA_GLSL_VERSION_OVERRIDE=450
> 
> I noticed above you didn't try with the GLSL override you might want give
> that a go before making a new trace.

Oh sorry, I just forgot to set GLSL when I run the trace.
A new trace, both overrides where set now
https://drive.google.com/open?id=1v9aBmPWPGNrBiBDu5VW7MczpsDR4cbs6

-- 
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] i965/fs: retype offset_reg to UD at load_ssbo

2018-04-19 Thread Iago Toral
Reviewed-by: Iago Toral Quiroga 

On Wed, 2018-04-18 at 22:57 +0200, Jose Maria Casanova Crespo wrote:
> All operations with offset_reg at do_vector_read are done
> with UD type. So copy propagation was not working through
> the generated MOVs:
> 
> mov(8) vgrf9:UD, vgrf7:D
> 
> This change allows removing the MOV generated for reading the
> first components for 16-bit and 64-bit ssbo reads with
> non-constant offsets.
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 6c4bcd1c113..0ebaab96634 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -4142,7 +4142,7 @@ fs_visitor::nir_emit_intrinsic(const fs_builder
> &bld, nir_intrinsic_instr *instr
>if (const_offset) {
>   offset_reg = brw_imm_ud(const_offset->u32[0]);
>} else {
> - offset_reg = get_nir_src(instr->src[1]);
> + offset_reg = retype(get_nir_src(instr->src[1]),
> BRW_REGISTER_TYPE_UD);
>}
>  
>/* Read the vector */
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] meson: Build st_tests_common with gtest

2018-04-19 Thread Mike Lothian
Fixes: 34cb4d0ebc1 ("meson: build tests for gallium mesa state tracker")

Signed-off-by: Mike Lothian 
---
 src/mesa/state_tracker/tests/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/tests/meson.build 
b/src/mesa/state_tracker/tests/meson.build
index f62039ef1e..0f84513209 100644
--- a/src/mesa/state_tracker/tests/meson.build
+++ b/src/mesa/state_tracker/tests/meson.build
@@ -22,7 +22,7 @@ libmesa_st_test_common = static_library(
   'mesa_st_test_common',
   ['st_tests_common.cpp', ir_expression_operation_h],
   include_directories : inc_common,
-  dependencies : dep_thread,
+  dependencies : [dep_thread, idep_gtest],
 )
 
 test(
-- 
2.17.0

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


Re: [Mesa-dev] [PATCH] radv: fix multisample image copies

2018-04-19 Thread Matthew Nicholls

On 18/04/18 22:56, Dave Airlie wrote:


On 18 April 2018 at 00:31, Matthew Nicholls
 wrote:

Previously before fb077b0728, the LOD parameter was being used in place of the
sample index, which would only copy the first sample to all samples in the
destination image. After that multisample image copies wouldn't copy anything
from my observations.

Fix this properly by copying each sample in a separate radv_CmdDraw and using a
pipeline with the correct rasterizationSamples for the destination image.

Have you run CTS on this?
I ran the CTS tests under dEQP-VK.api.copy_and_blit.core.* and didn't 
see any

changes. There were 6 failures both with and without this patch however:

dEQP-VK.api.copy_and_blit.core.resolve_image.{whole_array_image,whole_copy_before_resolving}.{2,4,8}_bit

This is on an RX 460.

Matthew.


I wrote something similiar (I'm on holidays at the moment so can't
confirm how similiar)
but it failed some CTS tests for me.

Dave.


---
  src/amd/vulkan/radv_meta_blit2d.c | 279 --
  src/amd/vulkan/radv_private.h |  18 +--
  2 files changed, 189 insertions(+), 108 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_blit2d.c 
b/src/amd/vulkan/radv_meta_blit2d.c
index e163056257..d953241b55 100644
--- a/src/amd/vulkan/radv_meta_blit2d.c
+++ b/src/amd/vulkan/radv_meta_blit2d.c
@@ -100,7 +100,8 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
  struct radv_meta_blit2d_buffer *src_buf,
  struct blit2d_src_temps *tmp,
  enum blit2d_src_type src_type, VkFormat depth_format,
-VkImageAspectFlagBits aspects)
+VkImageAspectFlagBits aspects,
+uint32_t log2_samples)
  {
 struct radv_device *device = cmd_buffer->device;

@@ -108,7 +109,7 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
 create_bview(cmd_buffer, src_buf, &tmp->bview, depth_format);

 radv_meta_push_descriptor_set(cmd_buffer, 
VK_PIPELINE_BIND_POINT_GRAPHICS,
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   0, /* set */
   1, /* descriptorWriteCount */
   (VkWriteDescriptorSet[]) {
@@ -123,7 +124,7 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
   });

 radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   VK_SHADER_STAGE_FRAGMENT_BIT, 16, 4,
   &src_buf->pitch);
 } else {
@@ -131,12 +132,12 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,

 if (src_type == BLIT2D_SRC_TYPE_IMAGE_3D)
 
radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   VK_SHADER_STAGE_FRAGMENT_BIT, 
16, 4,
   &src_img->layer);

 radv_meta_push_descriptor_set(cmd_buffer, 
VK_PIPELINE_BIND_POINT_GRAPHICS,
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   0, /* set */
   1, /* descriptorWriteCount */
   (VkWriteDescriptorSet[]) {
@@ -190,10 +191,11 @@ blit2d_bind_dst(struct radv_cmd_buffer *cmd_buffer,

  static void
  bind_pipeline(struct radv_cmd_buffer *cmd_buffer,
-  enum blit2d_src_type src_type, unsigned fs_key)
+  enum blit2d_src_type src_type, unsigned fs_key,
+  uint32_t log2_samples)
  {
 VkPipeline pipeline =
-   
cmd_buffer->device->meta_state.blit2d.pipelines[src_type][fs_key];
+   
cmd_buffer->device->meta_state.blit2d[log2_samples].pipelines[src_type][fs_key];

 radv_CmdBindPipeline(radv_cmd_buffer_to_handle(cmd_buffer),
  VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);
@@ -201,10 +203,11 @@ bind_pipeline(struct radv_cmd_buffer *cmd_buffer,

  static void
  bind_depth_pipeline(struct radv_cmd_buffer *cmd_buffer,
-   enum blit2d_src_type src_type)
+   enum blit2d_src_type src_type,
+

Re: [Mesa-dev] [PATCH 0/9] RadeonSI LLVM crash workaround for Ubuntu 18.04

2018-04-19 Thread Juan A. Suarez Romero
On Wed, 2018-04-18 at 15:41 -0400, Marek Olšák wrote:
> On Wed, Apr 18, 2018 at 8:00 AM, Juan A. Suarez Romero  
> wrote:
> > On Mon, 2018-04-16 at 20:52 -0400, Marek Olšák wrote:
> > > Hi,
> > > 
> > > This cleanup is motivated by a Mesa/LLVM crash on Ubuntu 18.04.
> > > It happens inside gallivm_dispose_target_library_info and only
> > > LLVM 5.0 and 6.0 seem to be affected.
> > 
> > Should this series (or part of this) be nominated for stable?
> 
> Patches for 18.0 will be submitted separately. For now, they are in this 
> branch:
> https://cgit.freedesktop.org/~mareko/mesa/log/?h=amd-18.0
> (the top 7 commits)
> 


Nice. Thanks


J.A.

> Marek
>  
> > 
> > J.A.
> > 
> > > 
> > > The workaround is to move target_library_info into the context
> > > (1 instance) and the screen (1 instance per compiler thread) to reduce
> > > the number of times it's created and deleted, and then simply leak
> > > it because we can't destroy it without a crash.
> > > 
> > > The series might also result in some non-measurable compile time
> > > savings, andd the last patch decreases shader-db run times
> > > significantly on many-core CPUs. (there is no expected effect on apps)
> > > 
> > > Please review.
> > > 
> > > Thanks,
> > > Marek
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] gm107/ir: add emission for BAR

2018-04-19 Thread Tom de Vries

On 04/17/2018 01:12 PM, Tom de Vries wrote:
[ Quoted text copied from 
https://lists.freedesktop.org/archives/mesa-dev/2016-March/108926.html ]


Hi,

I've been playing around with bar.sync in ptx, JIT-compiling it to GM107 
(my quadro m1200 card), and disassembling with cuobjdump -sass.


I looked at nv50_ir_emit_gm107.cpp to understand the instruction encoding.


[Mesa-dev] [PATCH] gm107/ir: add emission for BAR
Samuel Pitoiset samuel.pitoiset at gmail.com
Tue Mar 1 17:44:42 UTC 2016

+   // barrier id
+   if (insn->src(0).getFile() == FILE_GPR) {
+  emitGPR(0x08, insn->src(0));
+   } else {
+  ImmediateValue *imm = insn->getSrc(0)->asImm();
+  assert(imm);
+  emitField(0x08, 8, imm->reg.data.u32);
+  emitField(0x2b, 1, 1);
+   }
+
+   // thread count
+   if (insn->src(1).getFile() == FILE_GPR) {
+  emitGPR(0x14, insn->src(1));
+   } else {
+  ImmediateValue *imm = insn->getSrc(0)->asImm();


This should probably be using getSrc(1) ?


+  assert(imm);
+  emitField(0x14, 12, imm->reg.data.u32);
+  emitField(0x2c, 1, 1);
+   }

 From these examples:
...
     x    x
BAR.SYNC 0x0;  /* 0xf0a81b87 */
BAR.SYNC 0xf;  /* 0xf0a81b870f00 */
BAR.SYNC R0;   /* 0xf0a80b87 */
BAR.SYNC R2;   /* 0xf0a80b870200 */
...
I derive these offsets:
- barrier id   : 0x08
- barrier id imm vs reg: 0x2c

and from these examples:
...
  x    x
BAR.SYNC 0x0;  /* 0xf0a81b87 */
BAR.SYNC 0x0, R2;  /* 0xf0a813800027 */
...
I derive these offsets:
- thread count   : 0x14
- thread count imm vs reg: 0x2b


But when looking at the code snippet above, the roles seem reversed: 
0x2b is used for barrier id, and 0x2c is used for the thread count.


This seems worth to double-check.


filed as PR106132 - "bar.sync encoding incorrect for GM107" ( 
https://bugs.freedesktop.org/show_bug.cgi?id=106132 ).


Thanks,
- Tom

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


[Mesa-dev] [Bug 105464] Reading per-patch outputs in Tessellation Control Shader returns undefined values

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105464

--- Comment #11 from Samuel Pitoiset  ---
Hi,

Well, you can still re-enable the previous behaviour with "enable-ds128" and I
expect performance to be similar.

Otherwise, if you want to reproduce the problem you have to clone
https://github.com/SaschaWillems/Vulkan and to run the tessellationshader demo
using RADV.

-- 
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] radv: Add bound checking workaround for dynamic buffers.

2018-04-19 Thread Samuel Pitoiset



On 04/19/2018 07:31 AM, Bas Nieuwenhuizen wrote:

I have seen a few applications and games do the dynamic buffer bounds 
incorrectly, this
make it easier to work around, e.g. for debugging.


Example?

Either way:

Reviewed-by: Samuel Pitoiset 


---
  src/amd/vulkan/radv_cmd_buffer.c | 4 +++-
  src/amd/vulkan/radv_debug.h  | 1 +
  src/amd/vulkan/radv_device.c | 1 +
  3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index f6b23f6e73..1afdeda486 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2224,6 +2224,8 @@ void radv_CmdBindDescriptorSets(
RADV_FROM_HANDLE(radv_pipeline_layout, layout, _layout);
unsigned dyn_idx = 0;
  
+	const bool no_dynamic_bounds = cmd_buffer->device->instance->debug_flags & RADV_DEBUG_NO_DYNAMIC_BOUNDS;

+
for (unsigned i = 0; i < descriptorSetCount; ++i) {
unsigned idx = i + firstSet;
RADV_FROM_HANDLE(radv_descriptor_set, set, pDescriptorSets[i]);
@@ -2238,7 +2240,7 @@ void radv_CmdBindDescriptorSets(
uint64_t va = range->va + pDynamicOffsets[dyn_idx];
dst[0] = va;
dst[1] = S_008F04_BASE_ADDRESS_HI(va >> 32);
-   dst[2] = range->size;
+   dst[2] = no_dynamic_bounds ? 0xu : range->size;
dst[3] = S_008F0C_DST_SEL_X(V_008F0C_SQ_SEL_X) |
 S_008F0C_DST_SEL_Y(V_008F0C_SQ_SEL_Y) |
 S_008F0C_DST_SEL_Z(V_008F0C_SQ_SEL_Z) |
diff --git a/src/amd/vulkan/radv_debug.h b/src/amd/vulkan/radv_debug.h
index f35991fa4e..f9034c62e1 100644
--- a/src/amd/vulkan/radv_debug.h
+++ b/src/amd/vulkan/radv_debug.h
@@ -43,6 +43,7 @@ enum {
RADV_DEBUG_SYNC_SHADERS  = 0x2000,
RADV_DEBUG_NO_SISCHED= 0x4000,
RADV_DEBUG_PREOPTIR  = 0x8000,
+   RADV_DEBUG_NO_DYNAMIC_BOUNDS = 0x1,
  };
  
  enum {

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index fd11cedcbf..a7a2b6b63f 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -383,6 +383,7 @@ static const struct debug_control radv_debug_options[] = {
{"syncshaders", RADV_DEBUG_SYNC_SHADERS},
{"nosisched", RADV_DEBUG_NO_SISCHED},
{"preoptir", RADV_DEBUG_PREOPTIR},
+   {"nodynamicbounds", RADV_DEBUG_NO_DYNAMIC_BOUNDS},
{NULL, 0}
  };
  


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


Re: [Mesa-dev] [PATCH] radv: Add Vega M support.

2018-04-19 Thread Samuel Pitoiset

Reviewed-by: Samuel Pitoiset 

On 04/19/2018 06:36 AM, Bas Nieuwenhuizen wrote:

---
  src/amd/vulkan/radv_device.c   | 5 -
  src/amd/vulkan/radv_pipeline.c | 3 ++-
  src/amd/vulkan/radv_shader.c   | 1 +
  src/amd/vulkan/si_cmd_buffer.c | 4 
  4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index fd11cedcbf..aed7b6b67c 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -101,6 +101,7 @@ radv_get_device_name(enum radeon_family family, char *name, 
size_t name_len)
case CHIP_POLARIS11: chip_string = "AMD RADV POLARIS11"; break;
case CHIP_POLARIS12: chip_string = "AMD RADV POLARIS12"; break;
case CHIP_STONEY: chip_string = "AMD RADV STONEY"; break;
+   case CHIP_VEGAM: chip_string = "AMD RADV VEGA M"; break;
case CHIP_VEGA10: chip_string = "AMD RADV VEGA10"; break;
case CHIP_VEGA12: chip_string = "AMD RADV VEGA12"; break;
case CHIP_RAVEN: chip_string = "AMD RADV RAVEN"; break;
@@ -1012,7 +1013,8 @@ void radv_GetPhysicalDeviceProperties2(
pdevice->rad_info.family == CHIP_ICELAND ||
pdevice->rad_info.family == CHIP_POLARIS10 ||
pdevice->rad_info.family == CHIP_POLARIS11 ||
-   pdevice->rad_info.family == CHIP_POLARIS12 ? 8 
: 10;
+   pdevice->rad_info.family == CHIP_POLARIS12 ||
+   pdevice->rad_info.family == CHIP_VEGAM ? 8 : 10;
properties->wavefrontSize = 64;
  
  			/* SGPR. */

@@ -1353,6 +1355,7 @@ radv_device_init_gs_info(struct radv_device *device)
case CHIP_POLARIS10:
case CHIP_POLARIS11:
case CHIP_POLARIS12:
+   case CHIP_VEGAM:
case CHIP_VEGA10:
case CHIP_VEGA12:
case CHIP_RAVEN:
diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index fce3201c19..feee547d1b 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -3254,7 +3254,8 @@ radv_compute_ia_multi_vgt_param_helpers(struct 
radv_pipeline *pipeline,
device->physical_device->rad_info.family == 
CHIP_FIJI ||
device->physical_device->rad_info.family == 
CHIP_POLARIS10 ||
device->physical_device->rad_info.family == 
CHIP_POLARIS11 ||
-   device->physical_device->rad_info.family == 
CHIP_POLARIS12)
+   device->physical_device->rad_info.family == 
CHIP_POLARIS12 ||
+   device->physical_device->rad_info.family == 
CHIP_VEGAM)
ia_multi_vgt_param.partial_vs_wave = 
true;
} else {
ia_multi_vgt_param.partial_vs_wave = true;
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index ac36cecb67..8e8a32f025 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -620,6 +620,7 @@ generate_shader_stats(struct radv_device *device,
case CHIP_POLARIS10:
case CHIP_POLARIS11:
case CHIP_POLARIS12:
+   case CHIP_VEGAM:
max_simd_waves = 8;
break;
default:
diff --git a/src/amd/vulkan/si_cmd_buffer.c b/src/amd/vulkan/si_cmd_buffer.c
index 15edaa4b2b..80c819af49 100644
--- a/src/amd/vulkan/si_cmd_buffer.c
+++ b/src/amd/vulkan/si_cmd_buffer.c
@@ -279,6 +279,10 @@ si_set_raster_config(struct radv_physical_device 
*physical_device,
raster_config = 0x1612;
raster_config_1 = 0x;
break;
+   case CHIP_VEGAM:
+   raster_config = 0x3a00161a;
+   raster_config_1 = 0x002e;
+   break;
case CHIP_TONGA:
raster_config = 0x1612;
raster_config_1 = 0x002a;


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


[Mesa-dev] [Bug 106133] make check "OSError: [Errno 24] Too many open files"

2018-04-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106133

Bug ID: 106133
   Summary: make check "OSError: [Errno 24] Too many open files"
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: baker.dyla...@gmail.com

make check fails glsl/glcpp/tests/glcpp-test-cr-lf.sh test.

$ ./glsl/glcpp/tests/glcpp_test.py ./glsl/glcpp/glcpp glsl/glcpp/tests
--windows --oldmac
[...]
  File "./glsl/glcpp/tests/glcpp_test.py", line 221, in 
main()
  File "./glsl/glcpp/tests/glcpp_test.py", line 211, in main
success = success and test_oldmac(args)
  File "./glsl/glcpp/tests/glcpp_test.py", line 169, in test_oldmac
return _replace_test(args, '\r')
  File "./glsl/glcpp/tests/glcpp_test.py", line 144, in _replace_test
args.glcpp, tmpfile, testfile + '.expected', nl_format=replace)
  File "./glsl/glcpp/tests/glcpp_test.py", line 65, in test_output
stdin=subprocess.PIPE)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 710, in __init__
errread, errwrite)
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 1223, in _execute_child
errpipe_read, errpipe_write = self.pipe_cloexec()
  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py",
line 1175, in pipe_cloexec
r, w = os.pipe()
OSError: [Errno 24] Too many open files

-- 
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] radv: fix multisample image copies

2018-04-19 Thread Samuel Pitoiset



On 04/18/2018 11:56 PM, Dave Airlie wrote:

On 18 April 2018 at 00:31, Matthew Nicholls
 wrote:

Previously before fb077b0728, the LOD parameter was being used in place of the
sample index, which would only copy the first sample to all samples in the
destination image. After that multisample image copies wouldn't copy anything
from my observations.

Fix this properly by copying each sample in a separate radv_CmdDraw and using a
pipeline with the correct rasterizationSamples for the destination image.


Have you run CTS on this?

I wrote something similiar (I'm on holidays at the moment so can't
confirm how similiar)
but it failed some CTS tests for me.


I did run CTS on this, but no changes.



Dave.


---
  src/amd/vulkan/radv_meta_blit2d.c | 279 --
  src/amd/vulkan/radv_private.h |  18 +--
  2 files changed, 189 insertions(+), 108 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_blit2d.c 
b/src/amd/vulkan/radv_meta_blit2d.c
index e163056257..d953241b55 100644
--- a/src/amd/vulkan/radv_meta_blit2d.c
+++ b/src/amd/vulkan/radv_meta_blit2d.c
@@ -100,7 +100,8 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
  struct radv_meta_blit2d_buffer *src_buf,
  struct blit2d_src_temps *tmp,
  enum blit2d_src_type src_type, VkFormat depth_format,
-VkImageAspectFlagBits aspects)
+VkImageAspectFlagBits aspects,
+uint32_t log2_samples)
  {
 struct radv_device *device = cmd_buffer->device;

@@ -108,7 +109,7 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
 create_bview(cmd_buffer, src_buf, &tmp->bview, depth_format);

 radv_meta_push_descriptor_set(cmd_buffer, 
VK_PIPELINE_BIND_POINT_GRAPHICS,
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   0, /* set */
   1, /* descriptorWriteCount */
   (VkWriteDescriptorSet[]) {
@@ -123,7 +124,7 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,
   });

 radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   VK_SHADER_STAGE_FRAGMENT_BIT, 16, 4,
   &src_buf->pitch);
 } else {
@@ -131,12 +132,12 @@ blit2d_bind_src(struct radv_cmd_buffer *cmd_buffer,

 if (src_type == BLIT2D_SRC_TYPE_IMAGE_3D)
 
radv_CmdPushConstants(radv_cmd_buffer_to_handle(cmd_buffer),
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   VK_SHADER_STAGE_FRAGMENT_BIT, 
16, 4,
   &src_img->layer);

 radv_meta_push_descriptor_set(cmd_buffer, 
VK_PIPELINE_BIND_POINT_GRAPHICS,
- 
device->meta_state.blit2d.p_layouts[src_type],
+ 
device->meta_state.blit2d[log2_samples].p_layouts[src_type],
   0, /* set */
   1, /* descriptorWriteCount */
   (VkWriteDescriptorSet[]) {
@@ -190,10 +191,11 @@ blit2d_bind_dst(struct radv_cmd_buffer *cmd_buffer,

  static void
  bind_pipeline(struct radv_cmd_buffer *cmd_buffer,
-  enum blit2d_src_type src_type, unsigned fs_key)
+  enum blit2d_src_type src_type, unsigned fs_key,
+  uint32_t log2_samples)
  {
 VkPipeline pipeline =
-   
cmd_buffer->device->meta_state.blit2d.pipelines[src_type][fs_key];
+   
cmd_buffer->device->meta_state.blit2d[log2_samples].pipelines[src_type][fs_key];

 radv_CmdBindPipeline(radv_cmd_buffer_to_handle(cmd_buffer),
  VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);
@@ -201,10 +203,11 @@ bind_pipeline(struct radv_cmd_buffer *cmd_buffer,

  static void
  bind_depth_pipeline(struct radv_cmd_buffer *cmd_buffer,
-   enum blit2d_src_type src_type)
+   enum blit2d_src_type src_type,
+   uint32_t log2_samples)
  {
 VkPipeline pipeline =
-   
cmd_buffer->device->meta_state.blit2d.depth_only_pipeline[src_type];
+   
cmd_buffer->device->meta_state.blit2d[log2_samples].depth_only_pipeline[src