date:20190611

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

Timothy Arceri  changed:

   What|Removed |Added

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

-- 
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] include: update GL headers from the registry

2019-06-11 Thread Marek Olšák

PLE_LOCATION_SUBPIXEL_BITS_NV 0x933D
@@ -5477,6 +5583,18 @@ GLAPI void APIENTRY glResolveDepthValuesNV (void);
 #define GL_NV_sample_mask_override_coverage 1
 #endif /* GL_NV_sample_mask_override_coverage */
 
+#ifndef GL_NV_scissor_exclusive
+#define GL_NV_scissor_exclusive 1
+#define GL_SCISSOR_TEST_EXCLUSIVE_NV  0x9555
+#define GL_SCISSOR_BOX_EXCLUSIVE_NV   0x9556
+typedef void (APIENTRYP PFNGLSCISSOREXCLUSIVENVPROC) (GLint x, GLint y, 
GLsizei width, GLsizei height);
+typedef void (APIENTRYP PFNGLSCISSOREXCLUSIVEARRAYVNVPROC) (GLuint first, 
GLsizei count, const GLint *v);
+#ifdef GL_GLEXT_PROTOTYPES
+GLAPI void APIENTRY glScissorExclusiveNV (GLint x, GLint y, GLsizei width, 
GLsizei height);
+GLAPI void APIENTRY glScissorExclusiveArrayvNV (GLuint first, GLsizei count, 
const GLint *v);
+#endif
+#endif /* GL_NV_scissor_exclusive */
+
 #ifndef GL_NV_shader_atomic_counters
 #define GL_NV_shader_atomic_counters 1
 #endif /* GL_NV_shader_atomic_counters */
@@ -5539,6 +5657,10 @@ GLAPI void APIENTRY glProgramUniformui64vNV (GLuint 
program, GLint location, GLs
 #define GL_SHADER_GLOBAL_ACCESS_BARRIER_BIT_NV 0x0010
 #endif /* GL_NV_shader_buffer_store */
 
+#ifndef GL_NV_shader_texture_footprint
+#define GL_NV_shader_texture_footprint 1
+#endif /* GL_NV_shader_texture_footprint */
+
 #ifndef GL_NV_shader_thread_group
 #define GL_NV_shader_thread_group 1
 #define GL_WARP_SIZE_NV   0x9339
@@ -5550,6 +5672,47 @@ GLAPI void APIENTRY glProgramUniformui64vNV (GLuint 
program, GLint location, GLs
 #define GL_NV_shader_thread_shuffle 1
 #endif /* GL_NV_shader_thread_shuffle */
 
+#ifndef GL_NV_shading_rate_image
+#define GL_NV_shading_rate_image 1
+#define GL_SHADING_RATE_IMAGE_NV  0x9563
+#define GL_SHADING_RATE_NO_INVOCATIONS_NV 0x9564
+#define GL_SHADING_RATE_1_INVOCATION_PER_PIXEL_NV 0x9565
+#define GL_SHADING_RATE_1_INVOCATION_PER_1X2_PIXELS_NV 0x9566
+#define GL_SHADING_RATE_1_INVOCATION_PER_2X1_PIXELS_NV 0x9567
+#define GL_SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV 0x9568
+#define GL_SHADING_RATE_1_INVOCATION_PER_2X4_PIXELS_NV 0x9569
+#define GL_SHADING_RATE_1_INVOCATION_PER_4X2_PIXELS_NV 0x956A
+#define GL_SHADING_RATE_1_INVOCATION_PER_4X4_PIXELS_NV 0x956B
+#define GL_SHADING_RATE_2_INVOCATIONS_PER_PIXEL_NV 0x956C
+#define GL_SHADING_RATE_4_INVOCATIONS_PER_PIXEL_NV 0x956D
+#define GL_SHADING_RATE_8_INVOCATIONS_PER_PIXEL_NV 0x956E
+#define GL_SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV 0x956F
+#define GL_SHADING_RATE_IMAGE_BINDING_NV  0x955B
+#define GL_SHADING_RATE_IMAGE_TEXEL_WIDTH_NV 0x955C
+#define GL_SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV 0x955D
+#define GL_SHADING_RATE_IMAGE_PALETTE_SIZE_NV 0x955E
+#define GL_MAX_COARSE_FRAGMENT_SAMPLES_NV 0x955F
+#define GL_SHADING_RATE_SAMPLE_ORDER_DEFAULT_NV 0x95AE
+#define GL_SHADING_RATE_SAMPLE_ORDER_PIXEL_MAJOR_NV 0x95AF
+#define GL_SHADING_RATE_SAMPLE_ORDER_SAMPLE_MAJOR_NV 0x95B0
+typedef void (APIENTRYP PFNGLBINDSHADINGRATEIMAGENVPROC) (GLuint texture);
+typedef void (APIENTRYP PFNGLGETSHADINGRATEIMAGEPALETTENVPROC) (GLuint 
viewport, GLuint entry, GLenum *rate);
+typedef void (APIENTRYP PFNGLGETSHADINGRATESAMPLELOCATIONIVNVPROC) (GLenum 
rate, GLuint samples, GLuint index, GLint *location);
+typedef void (APIENTRYP PFNGLSHADINGRATEIMAGEBARRIERNVPROC) (GLboolean 
synchronize);
+typedef void (APIENTRYP PFNGLSHADINGRATEIMAGEPALETTENVPROC) (GLuint viewport, 
GLuint first, GLsizei count, const GLenum *rates);
+typedef void (APIENTRYP PFNGLSHADINGRATESAMPLEORDERNVPROC) (GLenum order);
+typedef void (APIENTRYP PFNGLSHADINGRATESAMPLEORDERCUSTOMNVPROC) (GLenum rate, 
GLuint samples, const GLint *locations);
+#ifdef GL_GLEXT_PROTOTYPES
+GLAPI void APIENTRY glBindShadingRateImageNV (GLuint texture);
+GLAPI void APIENTRY glGetShadingRateImagePaletteNV (GLuint viewport, GLuint 
entry, GLenum *rate);
+GLAPI void APIENTRY glGetShadingRateSampleLocationivNV (GLenum rate, GLuint 
samples, GLuint index, GLint *location);
+GLAPI void APIENTRY glShadingRateImageBarrierNV (GLboolean synchronize);
+GLAPI void APIENTRY glShadingRateImagePaletteNV (GLuint viewport, GLuint 
first, GLsizei count, const GLenum *rates);
+GLAPI void APIENTRY glShadingRateSampleOrderNV (GLenum order);
+GLAPI void APIENTRY glShadingRateSampleOrderCustomNV (GLenum rate, GLuint 
samples, const GLint *locations);
+#endif
+#endif /* GL_NV_shading_rate_image */
+
 #ifndef GL_NV_stereo_view_rendering
 #define GL_NV_stereo_view_rendering 1
 #endif /* GL_NV_stereo_view_rendering */
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 181df28d3bb..1743aae86d0 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -51,7 +51,9 @@ extern "C" {
 #define GLAPI extern
 #endif
 
-#define GL_GLEXT_VERSION 20180725
+#define GL_GLEXT_VERSION 20190611
+
+#include 
 
 /* Generated C header for:
  * API: gl
@@ -464,7 +466,6 @@ GLAPI void APIENTRY glBlendEquation (GLenum mode);
 
 #ifndef GL_VERSION_1_5
 #define GL_VERSION_1_5 1
-#include 
 typedef khronos_ssize_t GLsizeiptr;
 type

Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available

2019-06-11 Thread Bas Nieuwenhuizen

So can we rephrase this entire thing based on
physical_devices->mem_type_indices, instead of opencoding ordering &
detection?

On Tue, Jun 11, 2019 at 4:43 PM Samuel Pitoiset
 wrote:
>
> On VegaM, the visible VRAM size is equal to the VRAM size, which
> means only two heaps are exposed.
>
> This fixes dEQP-VK.api.info.device.memory_budget.
>
> Cc: 19.0 19.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 358fc7cb30a..31b9b4e9875 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1489,9 +1489,11 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
> VkPhysicalDeviceMemoryProperties *memory_properties = 
> >memory_properties;
> uint64_t visible_vram_size = radv_get_visible_vram_size(device);
> +   int vram_index = -1, visible_vram_index = -1, gtt_index = -1;
> uint64_t vram_size = radv_get_vram_size(device);
> uint64_t gtt_size = device->rad_info.gart_size;
> uint64_t heap_budget, heap_usage;
> +   uint32_t heap_count = 0;
>
> /* For all memory heaps, the computation of budget is as follow:
>  *  heap_budget = heap_size - global_heap_usage + app_heap_usage
> @@ -1503,6 +1505,7 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
>  * in presence of shared buffers).
>  */
> if (vram_size) {
> +   vram_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  RADEON_ALLOCATED_VRAM);
>
> @@ -1510,11 +1513,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, 
> RADEON_VRAM_USAGE) +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
> +   memoryBudget->heapBudget[vram_index] = heap_budget;
> +   memoryBudget->heapUsage[vram_index] = heap_usage;
> }
>
> if (visible_vram_size) {
> +   visible_vram_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  
> RADEON_ALLOCATED_VRAM_VIS);
>
> @@ -1522,11 +1526,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, 
> RADEON_VRAM_VIS_USAGE) +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
> heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
> heap_usage;
> +   memoryBudget->heapBudget[visible_vram_index] = heap_budget;
> +   memoryBudget->heapUsage[visible_vram_index] = heap_usage;
> }
>
> if (gtt_size) {
> +   gtt_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  RADEON_ALLOCATED_GTT);
>
> @@ -1534,8 +1539,8 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, RADEON_GTT_USAGE) 
> +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
> +   memoryBudget->heapBudget[gtt_index] = heap_budget;
> +   memoryBudget->heapUsage[gtt_index++] = heap_usage;
> }
>
> /* The heapBudget and heapUsage values must be zero for array elements
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] radv: fix occlusion queries on VegaM

2019-06-11 Thread Bas Nieuwenhuizen

So allowing disabled render backends without pre-setting them in the
reset procedure will break the OCCLUSION_QUERY packet. Luckily we
don't seem to use it for radv (yet?). Maybe find a way to comment that
somewhere?

Otherwise, r-b

On Tue, Jun 11, 2019 at 4:43 PM Samuel Pitoiset
 wrote:
>
> The number of render backends is 16 but the enabled mask is 0x.
>
> This fixes dEQP-VK.query_pool.* and dEQP-VK.multiview.*.
>
> Cc: 19.0 19.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_query.c | 48 +
>  1 file changed, 27 insertions(+), 21 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index ff9ceceb3ed..3bbd10cbb34 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -40,18 +40,6 @@
>  static const int pipelinestat_block_size = 11 * 8;
>  static const unsigned pipeline_statistics_indices[] = {7, 6, 3, 4, 5, 2, 1, 
> 0, 8, 9, 10};
>
> -static unsigned get_max_db(struct radv_device *device)
> -{
> -   unsigned num_db = 
> device->physical_device->rad_info.num_render_backends;
> -   MAYBE_UNUSED unsigned rb_mask = 
> device->physical_device->rad_info.enabled_rb_mask;
> -
> -   /* Otherwise we need to change the query reset procedure */
> -   assert(rb_mask == ((1ull << num_db) - 1));
> -
> -   return num_db;
> -}
> -
> -
>  static nir_ssa_def *nir_test_flag(nir_builder *b, nir_ssa_def *flags, 
> uint32_t flag)
>  {
> return nir_i2b(b, nir_iand(b, flags, nir_imm_int(b, flag)));
> @@ -108,12 +96,14 @@ build_occlusion_query_shader(struct radv_device *device) 
> {
>  *  uint64_t dst_offset = dst_stride * global_id.x;
>  *  bool available = true;
>  *  for (int i = 0; i < db_count; ++i) {
> -*  uint64_t start = src_buf[src_offset + 16 * i];
> -*  uint64_t end = src_buf[src_offset + 16 * i + 8];
> -*  if ((start & (1ull << 63)) && (end & (1ull << 63)))
> -*  result += end - start;
> -*  else
> -*  available = false;
> +*  if (enabled_rb_mask & (1 << i)) {
> +*  uint64_t start = src_buf[src_offset + 16 * i];
> +*  uint64_t end = src_buf[src_offset + 16 * i + 
> 8];
> +*  if ((start & (1ull << 63)) && (end & (1ull << 
> 63)))
> +*  result += end - start;
> +*  else
> +*  available = false;
> +*  }
>  *  }
>  *  uint32_t elem_size = flags & VK_QUERY_RESULT_64_BIT ? 8 : 4;
>  *  if ((flags & VK_QUERY_RESULT_PARTIAL_BIT) || available) {
> @@ -139,7 +129,8 @@ build_occlusion_query_shader(struct radv_device *device) {
> nir_variable *start = nir_local_variable_create(b.impl, 
> glsl_uint64_t_type(), "start");
> nir_variable *end = nir_local_variable_create(b.impl, 
> glsl_uint64_t_type(), "end");
> nir_variable *available = nir_local_variable_create(b.impl, 
> glsl_bool_type(), "available");
> -   unsigned db_count = get_max_db(device);
> +   unsigned enabled_rb_mask = 
> device->physical_device->rad_info.enabled_rb_mask;
> +   unsigned db_count = 
> device->physical_device->rad_info.num_render_backends;
>
> nir_ssa_def *flags = radv_load_push_int(, 0, "flags");
>
> @@ -187,6 +178,16 @@ build_occlusion_query_shader(struct radv_device *device) 
> {
> nir_ssa_def *current_outer_count = nir_load_var(, outer_counter);
> radv_break_on_count(, outer_counter, nir_imm_int(, db_count));
>
> +   nir_ssa_def *enabled_cond =
> +   nir_iand(, nir_imm_int(, enabled_rb_mask),
> +nir_ishl(, nir_imm_int(, 1), 
> current_outer_count));
> +
> +   nir_if *enabled_if = nir_if_create(b.shader);
> +   enabled_if->condition = nir_src_for_ssa(nir_i2b(, enabled_cond));
> +   nir_cf_node_insert(b.cursor, _if->cf_node);
> +
> +   b.cursor = nir_after_cf_list(_if->then_list);
> +
> nir_ssa_def *load_offset = nir_imul(, current_outer_count, 
> nir_imm_int(, 16));
> load_offset = nir_iadd(, input_base, load_offset);
>
> @@ -1042,7 +1043,7 @@ VkResult radv_CreateQueryPool(
>
> switch(pCreateInfo->queryType) {
> case VK_QUERY_TYPE_OCCLUSION:
> -   pool->stride = 16 * get_max_db(device);
> +   pool->stride = 16 * 
> device->physical_device->rad_info.num_render_backends;
> break;
> case VK_QUERY_TYPE_PIPELINE_STATISTICS:
> pool->stride = pipelinestat_block_size * 2;
> @@ -1147,12 +1148,17 @@ VkResult radv_GetQueryPoolResults(
> }
> case VK_QUERY_TYPE_OCCLUSION: {
> volatile uint64_t const *src64 = (volatile

[Mesa-dev] [Bug 110810] Vulkan spec break: VkCommandBufferInheritanceInfo.framebuffer is NOT optional

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

--- Comment #4 from Samuel Pitoiset  ---
Yeah, I will fix.

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

[Mesa-dev] [Bug 110761] Huge problems between Mesa and Electron engine apps

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

--- Comment #3 from Jakub Okoński  ---
I can confirm that 19.0.6 is fixed, and I had these problems before on 19.0.5.

-- 
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] panfrost: Replace pantrace with direct decoding

History lesson! In the early days of a Panfrost, we had a library
independent of the driver called `panwrap` which would be LD_PRELOAD'ed
into a driver to decode its cmdstream in real-time. When upstreaming
Panfrost, we realized that we would much rather have this decode
functionality maintained in-tree to avoid divergence, but that we could
not upstream panwrap because of its use with the legacy API. So we
instead dumped GPU memory to the filesystem with an out-of-tree panwrap,
and decoded that with the in-tree pandecode module. When we migrated to
the new kernel, we just added support for doing this memory dump
directly from the driver (via a module "pantrace").

This works, but dumping memory every frame is sloow and
error-prone. I figured if we have pandecode in-tree, we might as well
link to it directly in the driver, allowing us to decode Panfrost's
command streams without dumping memory to the filesystem first. This
cleans up the code *substantially* and improves dumping performance by a
HUGE margin. I'm talking "several seconds per frame" to "dumping in
real-time" kind of jump.

Note to users: this removes the environmental option "PANTRACE_BASE".
Instead, for equivalent functionality set "PAN_MESA_DEBUG=trace" and
redirect stdout to the file of your choosing.

This should be debugging Panfrost much more pleasant.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/meson.build  |   5 +-
 src/gallium/drivers/panfrost/pan_drm.c|  20 +--
 src/gallium/drivers/panfrost/pan_screen.c |  13 +-
 src/gallium/drivers/panfrost/pan_screen.h |   1 -
 src/gallium/drivers/panfrost/pan_trace.c  | 146 --
 src/gallium/drivers/panfrost/pan_trace.h  |  33 
 src/gallium/drivers/panfrost/pan_util.h   |   1 +
 .../drivers/panfrost/pandecode/cmdline.c  |  64 +---
 .../drivers/panfrost/pandecode/common.c   | 102 
 .../drivers/panfrost/pandecode/decode.c   |   2 +-
 .../panfrost/pandecode/{mmap.h => decode.h}   |  12 +-
 11 files changed, 140 insertions(+), 259 deletions(-)
 delete mode 100644 src/gallium/drivers/panfrost/pan_trace.c
 delete mode 100644 src/gallium/drivers/panfrost/pan_trace.h
 create mode 100644 src/gallium/drivers/panfrost/pandecode/common.c
 rename src/gallium/drivers/panfrost/pandecode/{mmap.h => decode.h} (91%)

diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index d01c132eb70..006449fc48f 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -42,11 +42,13 @@ files_panfrost = files(
 
   'bifrost/disassemble.c',
 
+  'pandecode/common.c',
+  'pandecode/decode.c',
+
   'pan_context.c',
   'pan_afbc.c',
   'pan_blit.c',
   'pan_job.c',
-  'pan_trace.c',
   'pan_drm.c',
   'pan_allocate.c',
   'pan_assemble.c',
@@ -135,6 +137,7 @@ bifrost_compiler = executable(
 
 files_pandecode = files(
   'pandecode/cmdline.c',
+  'pandecode/common.c',
   'pandecode/decode.c',
 
   'pan_pretty_print.c',
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 981b1c6ce13..3ceff41e25c 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -36,7 +36,8 @@
 #include "pan_resource.h"
 #include "pan_context.h"
 #include "pan_drm.h"
-#include "pan_trace.h"
+#include "pan_util.h"
+#include "pandecode/decode.h"
 
 struct panfrost_drm {
struct panfrost_driver base;
@@ -91,8 +92,8 @@ panfrost_drm_allocate_slab(struct panfrost_screen *screen,
}
 
 /* Record the mmap if we're tracing */
-if (!(extra_flags & PAN_ALLOCATE_GROWABLE))
-pantrace_mmap(mem->gpu, mem->cpu, mem->size, NULL);
+if (pan_debug & PAN_DBG_TRACE)
+pandecode_inject_mmap(mem->gpu, mem->cpu, mem->size, NULL);
 }
 
 static void
@@ -159,7 +160,8 @@ panfrost_drm_import_bo(struct panfrost_screen *screen, 
struct winsys_handle *wha
}
 
 /* Record the mmap if we're tracing */
-pantrace_mmap(bo->gpu, bo->cpu, bo->size, NULL);
+if (pan_debug & PAN_DBG_TRACE)
+pandecode_inject_mmap(bo->gpu, bo->cpu, bo->size, NULL);
 
 return bo;
 }
@@ -237,17 +239,15 @@ panfrost_drm_submit_job(struct panfrost_context *ctx, u64 
job_desc, int reqs, st
bo_handles[submit.bo_handle_count++] = ctx->misc_0.gem_handle;
submit.bo_handles = (u64) (uintptr_t) bo_handles;
 
-/* Dump memory _before_ submitting so we're not corrupted with actual 
GPU results */
-pantrace_dump_memory();
-
if (drmIoctl(drm->fd, DRM_IOCTL_PANFROST_SUBMIT, )) {
fprintf(stderr, "Error submitting: %m\n");
return errno;
}
 
-/* Trace the job if we're doing that and do a memory dump. We may
- * want to adjust this logic once we're ready to trace FBOs */
-pantrace_submit_job(submit.jc, submit.requirements,

[Mesa-dev] [Bug 110884] can't start GDM when building mesa master branch with LTO

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

--- Comment #4 from Marcos Simental  ---
(In reply to Thiago Macieira from comment #3)
> This patch appears to fix the problem:
> 
> From 49607f0524539cb836065b626bb3d3946061c486 Mon Sep 17 00:00:00 2001
> From: Thiago Macieira 
> Date: Mon, 10 Jun 2019 19:13:12 -0700
> Subject: [PATCH] Attempt at fixing strict aliasing violation in dequeueing
>  packets
> 
> lp_scene_dequeue() calls util_ringbuffer_dequeue() with a payload that
> isn't an array of struct util_packets. When util_ringbuffer_dequeue()
> made the direct copy, the compiler discarded because it wasn't writing
> the right type.
> 
> Signed-off-by: Thiago Macieira 
> ---
>  src/gallium/auxiliary/util/u_ringbuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_ringbuffer.c
> b/src/gallium/auxiliary/util/u_ringbuffer.c
> index f6bb910671e..cebb908410c 100644
> --- a/src/gallium/auxiliary/util/u_ringbuffer.c
> +++ b/src/gallium/auxiliary/util/u_ringbuffer.c
> @@ -146,7 +146,7 @@ enum pipe_error util_ringbuffer_dequeue( struct
> util_ringbuffer *ring,
> /* Copy data from ring:
>  */
> for (i = 0; i < ring_packet->dwords; i++) {
> -  packet[i] = ring->buf[ring->tail];
> +  memcpy(packet + i, ring->buf + ring->tail, sizeof(*packet));
>ring->tail++;
>ring->tail &= ring->mask;
> }
> -- 
> 2.22.0

This patch works for me

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #15 from Samuel Pitoiset  ---
Oh okay, I see :-)

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #14 from tempel.jul...@gmail.com ---
I've highlighted the artifacts:
https://abload.de/img/screenshot_20190611_2jqkx1.png

It looks quite worse in motion, as these bright spots shift their shape, wander
etc.

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #13 from Samuel Pitoiset  ---
I don't see what's wrong?

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #12 from tempel.jul...@gmail.com ---
After turning off the minimap in the game's options, the "shadowmap holes" are
still there with radv (look a bit like drops in this screenshot):

https://abload.de/img/screenshot_20190611_28wkhv.png

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #11 from Samuel Pitoiset  ---
The artifacts with RADV are only with the minimap right?

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #10 from tempel.jul...@gmail.com ---
A screenshot with amdvlk without the artifacts:
https://abload.de/img/screenshot_20190611_2elj3e.png

The issue is most prominent with radv when the sun is shining.

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #9 from tempel.jul...@gmail.com ---
With amdvlk, the shadows look correct (no weird bright spots that wander with
the camera).
There is an issue with amdvlk though related to the game's effect of the
level's borders, but that seems totally unrelated to any shadow issues, I'd
say.

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

[Mesa-dev] [PATCH 6/6] panfrost/midgard: Differentiate vertex/fragment texture tags

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/helpers.h  | 2 ++
 src/gallium/drivers/panfrost/midgard/midgard_emit.c | 8 +---
 src/gallium/drivers/panfrost/midgard/midgard_schedule.c | 9 -
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h 
b/src/gallium/drivers/panfrost/midgard/helpers.h
index b6ab3c86c97..a2cc7e67eaf 100644
--- a/src/gallium/drivers/panfrost/midgard/helpers.h
+++ b/src/gallium/drivers/panfrost/midgard/helpers.h
@@ -86,6 +86,7 @@
 
 /* 4-bit type tags */
 
+#define TAG_TEXTURE_4_VTX 0x2
 #define TAG_TEXTURE_4 0x3
 #define TAG_LOAD_STORE_4 0x5
 #define TAG_ALU_4 0x8
@@ -100,6 +101,7 @@ quadword_size(int tag)
 case TAG_ALU_4:
 case TAG_LOAD_STORE_4:
 case TAG_TEXTURE_4:
+case TAG_TEXTURE_4_VTX:
 return 1;
 case TAG_ALU_8:
 return 2;
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_emit.c 
b/src/gallium/drivers/panfrost/midgard/midgard_emit.c
index 5ddcee419bf..bf6ee4508f5 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_emit.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_emit.c
@@ -203,13 +203,15 @@ emit_binary_bundle(compiler_context *ctx,
 break;
 }
 
-case TAG_TEXTURE_4: {
+case TAG_TEXTURE_4:
+case TAG_TEXTURE_4_VTX: {
 /* Texture instructions are easy, since there is no pipelining
- * nor VLIW to worry about. We may need to set .last flag */
+ * nor VLIW to worry about. We may need to set .cont/.last
+ * flags. */
 
 midgard_instruction *ins = bundle->instructions[0];
 
-ins->texture.type = TAG_TEXTURE_4;
+ins->texture.type = bundle->tag;
 ins->texture.next_type = next_tag;
 
 ctx->texture_op_count--;
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_schedule.c 
b/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
index 9d4ce2a97d5..3d6c7f9cf53 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
@@ -370,8 +370,15 @@ schedule_bundle(compiler_context *ctx, midgard_block 
*block, midgard_instruction
 break;
 }
 
+case TAG_TEXTURE_4: {
+/* Which tag we use depends on the shader stage */
+bool in_frag = ctx->stage == MESA_SHADER_FRAGMENT;
+bundle.tag = in_frag ? TAG_TEXTURE_4 : TAG_TEXTURE_4_VTX;
+break;
+}
+
 default:
-/* Texture ops default to single-op-per-bundle scheduling */
+unreachable("Unknown tag");
 break;
 }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/6] panfrost/midgard: Set minimal swizzle on texture input

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index c328d2d69f9..5d21ae2f844 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -83,6 +83,7 @@ midgard_block_add_successor(midgard_block *block, 
midgard_block *successor)
 
 #define EMIT(op, ...) emit_mir_instruction(ctx, v_##op(__VA_ARGS__));
 #define SWIZZLE_XYZW SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z, 
COMPONENT_W)
+#define SWIZZLE_XYXX SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_X, 
COMPONENT_X)
 #define SWIZZLE_ SWIZZLE(COMPONENT_X, COMPONENT_X, COMPONENT_X, 
COMPONENT_X)
 #define SWIZZLE_ SWIZZLE(COMPONENT_W, COMPONENT_W, COMPONENT_W, 
COMPONENT_W)
 
@@ -1407,7 +1408,7 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 
 /* TODO: half */
 .in_reg_full = 1,
-.in_reg_swizzle = SWIZZLE_XYZW,
+.in_reg_swizzle = SWIZZLE_XYXX,
 .out_full = 1,
 
 /* Always 1 */
-- 
2.20.1

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

[Mesa-dev] [PATCH 2/6] panfrost/midgard: Implement txl

This follows the txb implementation, but requires an adjustment to how
the cont/last flags are set.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 10 +-
 src/gallium/drivers/panfrost/midgard/midgard_emit.c|  9 ++---
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 7dc6530afec..5ccb2ef4837 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1309,6 +1309,8 @@ midgard_tex_op(nir_texop op)
 case nir_texop_tex:
 case nir_texop_txb:
 return TEXTURE_OP_NORMAL;
+case nir_texop_txl:
+return TEXTURE_OP_LOD;
 default:
 unreachable("Unhanlded texture op");
 }
@@ -1368,7 +1370,8 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 break;
 }
 
-case nir_tex_src_bias: {
+case nir_tex_src_bias:
+case nir_tex_src_lod: {
 /* To keep RA simple, we put the bias/LOD into the w
  * component of the input source, which is otherwise 
in xy */
 
@@ -1408,9 +1411,6 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 
 /* Always 1 */
 .unknown7 = 1,
-
-/* Assume we can continue; hint it out later */
-.cont = 1,
 }
 };
 
@@ -1421,7 +1421,7 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 /* Setup bias/LOD if necessary. Only register mode support right now.
  * TODO: Immediate mode for performance gains */
 
-if (instr->op == nir_texop_txb) {
+if (instr->op == nir_texop_txb || instr->op == nir_texop_txl) {
 ins.texture.lod_register = true;
 
 midgard_tex_register_select sel = {
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_emit.c 
b/src/gallium/drivers/panfrost/midgard/midgard_emit.c
index ffa08735ff0..5ddcee419bf 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_emit.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_emit.c
@@ -214,9 +214,12 @@ emit_binary_bundle(compiler_context *ctx,
 
 ctx->texture_op_count--;
 
-if (!ctx->texture_op_count) {
-ins->texture.cont = 0;
-ins->texture.last = 1;
+if (ins->texture.op == TEXTURE_OP_NORMAL) {
+bool continues = ctx->texture_op_count > 0;
+ins->texture.cont = continues;
+ins->texture.last = !continues;
+} else {
+ins->texture.cont = ins->texture.last = 1;
 }
 
 util_dynarray_append(emission, midgard_texture_word, 
ins->texture);
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/6] panfrost/midgard: More texturing functions

Using the knowledge of texture instructions gained in the previous
series, we can now implement the remaining texturing functions required
in GLES (including texturing in a vertex shader, which is neat).

Doesn't do much for conformance yet; mipmaps are a prerequisite for most
of the affected tests.

Alyssa Rosenzweig (6):
  panfrost/midgard: Implement txb op
  panfrost/midgard: Implement txl
  panfrost/midgard: Lower texture projectors
  panfrost/midgard: Set minimal swizzle on texture input
  panfrost/midgard: Assert on unknown texture source
  panfrost/midgard: Differentiate vertex/fragment texture tags

 .../drivers/panfrost/midgard/helpers.h|  2 +
 .../panfrost/midgard/midgard_compile.c| 82 ++-
 .../drivers/panfrost/midgard/midgard_emit.c   | 17 ++--
 .../panfrost/midgard/midgard_schedule.c   |  9 +-
 4 files changed, 84 insertions(+), 26 deletions(-)

-- 
2.20.1

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

[Mesa-dev] [PATCH 5/6] panfrost/midgard: Assert on unknown texture source

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 5d21ae2f844..39b8fb9760f 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1385,11 +1385,8 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 break;
};
 
-default: {
-DBG("Unknown source type\n");
-//assert(0);
-break;
-}
+default:
+unreachable("Unknown texture source type\n");
 }
 }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/6] panfrost/midgard: Lower texture projectors

We do have native support for perspective division on the load/store
unit, but this is for the future, something ideally we would select
generally, not just for textures. Meanwhile, flipping on projector
lowering works now.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 5ccb2ef4837..c328d2d69f9 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -356,7 +356,8 @@ optimise_nir(nir_shader *nir)
 NIR_PASS(progress, nir, nir_lower_idiv);
 
 nir_lower_tex_options lower_tex_options = {
-.lower_rect = true
+.lower_rect = true,
+.lower_txp = ~0
 };
 
 NIR_PASS(progress, nir, nir_lower_tex, _tex_options);
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/6] panfrost/midgard: Implement txb op

We refactor the main tex handling to fit a bias argument in as well.

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 65 ---
 1 file changed, 55 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 651cdd61a5b..7dc6530afec 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -83,6 +83,8 @@ midgard_block_add_successor(midgard_block *block, 
midgard_block *successor)
 
 #define EMIT(op, ...) emit_mir_instruction(ctx, v_##op(__VA_ARGS__));
 #define SWIZZLE_XYZW SWIZZLE(COMPONENT_X, COMPONENT_Y, COMPONENT_Z, 
COMPONENT_W)
+#define SWIZZLE_ SWIZZLE(COMPONENT_X, COMPONENT_X, COMPONENT_X, 
COMPONENT_X)
+#define SWIZZLE_ SWIZZLE(COMPONENT_W, COMPONENT_W, COMPONENT_W, 
COMPONENT_W)
 
 #define M_LOAD_STORE(name, rname, uname) \
static midgard_instruction m_##name(unsigned ssa, unsigned address) { \
@@ -1300,13 +1302,24 @@ midgard_tex_format(enum glsl_sampler_dim dim)
 }
 }
 
+static unsigned
+midgard_tex_op(nir_texop op)
+{
+switch (op) {
+case nir_texop_tex:
+case nir_texop_txb:
+return TEXTURE_OP_NORMAL;
+default:
+unreachable("Unhanlded texture op");
+}
+}
+
 static void
 emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 {
 /* TODO */
 //assert (!instr->sampler);
 //assert (!instr->texture_array_size);
-assert (instr->op == nir_texop_tex);
 
 /* Allocate registers via a round robin scheme to alternate between 
the two registers */
 int reg = ctx->texture_op_count & 1;
@@ -1321,18 +1334,17 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 int sampler_index = texture_index;
 
 for (unsigned i = 0; i < instr->num_srcs; ++i) {
+int reg = SSA_FIXED_REGISTER(REGISTER_TEXTURE_BASE + in_reg);
+int index = nir_src_index(ctx, >src[i].src);
+midgard_vector_alu_src alu_src = blank_alu_src;
+
 switch (instr->src[i].src_type) {
 case nir_tex_src_coord: {
-int index = nir_src_index(ctx, >src[i].src);
-
-midgard_vector_alu_src alu_src = blank_alu_src;
-
-int reg = SSA_FIXED_REGISTER(REGISTER_TEXTURE_BASE + 
in_reg);
-
 if (instr->sampler_dim == GLSL_SAMPLER_DIM_CUBE) {
 /* For cubemaps, we need to load coords into
  * special r27, and then use a special ld/st op
- * to copy into the texture register */
+ * to select the face and copy the xy into the
+ * texture register */
 
 alu_src.swizzle = SWIZZLE(COMPONENT_X, 
COMPONENT_Y, COMPONENT_Z, COMPONENT_X);
 
@@ -1341,7 +1353,7 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 
 midgard_instruction st = 
m_st_cubemap_coords(reg, 0);
 st.load_store.unknown = 0x24; /* XXX: What is 
this? */
-st.load_store.mask = 0x3; /* xy? */
+st.load_store.mask = 0x3; /* xy */
 st.load_store.swizzle = alu_src.swizzle;
 emit_mir_instruction(ctx, st);
 
@@ -1349,12 +1361,25 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 alu_src.swizzle = SWIZZLE(COMPONENT_X, 
COMPONENT_Y, COMPONENT_X, COMPONENT_X);
 
 midgard_instruction ins = v_fmov(index, 
alu_src, reg);
+ins.alu.mask = expand_writemask(0x3); /* xy */
 emit_mir_instruction(ctx, ins);
 }
 
 break;
 }
 
+case nir_tex_src_bias: {
+/* To keep RA simple, we put the bias/LOD into the w
+ * component of the input source, which is otherwise 
in xy */
+
+alu_src.swizzle = SWIZZLE_;
+
+midgard_instruction ins = v_fmov(index, alu_src, reg);
+ins.alu.mask = expand_writemask(1 << COMPONENT_W);
+emit_mir_instruction(ctx, ins);
+break;
+   };
+
 default: {
 DBG("Unknown source type\n");
 //assert(0);
@@ -1367,7 +1392,7 @@ emit_tex(compiler_context *ctx, nir_tex_instr *instr)
 midgard_instruction ins = {
 .type = TAG_TEXTURE_4,
 .texture = {
-

[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

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

--- Comment #21 from Timur Kristóf  ---
The issue is not really autotools specific. Even though meson is able to build
it, ideally TTN shouldn't need to use GL(SL), as Michel said above.

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

[Mesa-dev] [Bug 110662] shadow artifacts in Assassin's Creed: Unity

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

--- Comment #8 from Samuel Pitoiset  ---
How does it look with AMDVLK?

-- 
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] mirroring ogl-sample source code in gitlab?

2019-06-11 Thread Adam Jackson

On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:

> So here's the question: How does people feel about hosting this under 
> https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with
> this, I will make that happen, and send out a patch to update the link
> we have in our FAQ once that's done.

Sounds fine to me. I've needed to refer to the SI more than once, I'd
be happy to have it in a well-known location.

Vaguely related: Old-timers may remember that DRI used to have its own
CVS repo on dri.sourceforge.net. If you want a git import of that tree,
you can find it here:

https://gitlab.freedesktop.org/ajax/dri

I'd be happy to move this under mesa/ too if we want.

> I would further propose we mark the repo as archived, which would
> clearly mark that we're not maintaining it and also prevent it from
> appearing in searches.

Enh. Less sold on this, though if it's linked from the FAQ I guess it's
okay. I find that gitlab's archive makes things a little too hard to
find, I would often prefer to see archived results in searches. But
there's not really a better way to make a repo read-only, so I won't
object too strongly.

- ajax

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

[Mesa-dev] [Bug 110625] [TRACKER] Mesa 19.1 release tracker

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

Juan A. Suarez  changed:

   What|Removed |Added

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

--- Comment #2 from Juan A. Suarez  ---
Mesa 19.1.0 has been released.

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

[Mesa-dev] [Bug 110761] Huge problems between Mesa and Electron engine apps

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

--- Comment #2 from Juan A. Suarez  ---
Could you check if this issue is now fixed in Mesa 19.1.0?

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

[Mesa-dev] [Bug 110655] VK_LAYER_MESA_OVERLAY_CONFIG=draw, fps renders sporadically

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

Juan A. Suarez  changed:

   What|Removed |Added

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

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

[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

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

--- Comment #20 from Juan A. Suarez  ---
Autotools has been removed in Mesa 19.1.0.

Should we close this?

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

[Mesa-dev] [Bug 110655] VK_LAYER_MESA_OVERLAY_CONFIG=draw, fps renders sporadically

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

--- Comment #5 from Juan A. Suarez  ---
Mesa 19.1.0 has been released, which includes the fixes for this issue.

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

[Mesa-dev] [ANNOUNCE] mesa 19.1.0

2019-06-11 Thread Juan A. Suarez Romero

Mesa 19.1.0 is now available.

This release consists of approximately 3700 commits from 158
developers.

Huge thanks to all the developers, testers and users for their
ongoing work and support shaping up the 19.1.0 release.

The top highlights include:

 - GL_ARB_parallel_shader_compile for all drivers.
-  GL_EXT_gpu_shader4 on all GL 3.1 drivers.
-  GL_EXT_shader_image_load_formatted on radeonsi.
-  GL_EXT_texture_buffer_object on all GL 3.1 drivers.
-  GL_EXT_texture_compression_s3tc_srgb on Gallium and i965 drivers (ES 
extension).
-  GL_NV_compute_shader_derivatives on Iris and i965 drivers.
-  GL_KHR_parallel_shader_compile on all drivers.
-  GL_INTEL_conservative_rasterization on Iris.


Additional features:

ANV
 - VK_EXT_buffer_device_address
 - VK_EXT_depth_clip_enable
 - VK_KHR_ycbcr_image_arrays
 - VK_EXT_inline_uniform_block
 - VK_EXT_external_memory_host
 - VK_EXT_host_query_reset
 - VK_KHR_surface_protected_capabilities
 - VK_EXT_pipeline_creation_feedback
 - VK_NV_compute_shader_derivatives
 - VK_KHR_shader_float16_int8
 - VK_KHR_shader_atomic_int64
 - VK_EXT_descriptor_indexing
 - VK_EXT_memory_budget
 
RADV 
 - VK_EXT_buffer_device_address
 - VK_EXT_depth_clip_enable
 - VK_EXT_inline_uniform_block
 - VK_EXT_host_query_reset
 - VK_KHR_surface_protected_capabilities
 - VK_EXT_pipeline_creation_feedback
 - VK_KHR_8bit_storage
 - VK_AMD_gpu_shader_int16
 - VK_AMD_gpu_shader_half_float
 - VK_KHR_shader_float16_int8


For the full log see:
   git log 19.0-branchpoint..mesa-19.1.0


Changes since rc5:

Bas Nieuwenhuizen (1):
  radv: Prevent out of bound shift on 32-bit builds.

Charmaine Lee (1):
  svga: Remove unnecessary check for the pre flush bit for setting vertex 
buffers

Deepak Rawat (2):
  winsys/drm: Fix out of scope variable usage
  winsys/svga/drm: Fix 32-bit RPCI send message

Emil Velikov (3):
  egl/dri: flesh out and use dri2_create_drawable()
  mapi: add static_date offset to MaxShaderCompilerThreadsKHR
  mapi: correctly handle the full offset table

Eric Engestrom (1):
  util/os_file: actually return the error read() gave us

Jason Ekstrand (1):
  nir/propagate_invariant: Don't add NULL vars to the hash table

Juan A. Suarez Romero (2):
  Update version to 19.1.0
  docs: Add release notes for 19.1.0

Kenneth Graunke (1):
  egl/x11: calloc dri2_surf so it's properly zeroed

Lionel Landwerlin (2):
  intel/perf: fix EuThreadsCount value in performance equations
  intel/perf: improve dynamic loading config detection

Nanley Chery (1):
  anv/cmd_buffer: Initalize the clear color struct for CNL+

Nataraj Deshpande (1):
  anv: Fix check for isl_fmt in assert

Rob Clark (2):
  freedreno/a6xx: fix issues with gallium HUD
  freedreno/a6xx: fix hangs with newer sqe fw

Samuel Pitoiset (2):
  radv: fix alpha-to-coverage when there is unused color attachments
  radv: fix setting CB_SHADER_MASK for dual source blending

git tag: mesa-19.1.0

https://mesa.freedesktop.org/archive/mesa-19.1.0.tar.xz
MD5:  090cd351cf938fc1729dee983520216a  mesa-19.1.0.tar.xz
SHA1: e2088e1d4fd9c113c5fc4ee416702f35f32ce668  mesa-19.1.0.tar.xz
SHA256: 2a6c3af3a803389183168e449c536304cf03e0f82c4c9333077933543b9d02f3  
mesa-19.1.0.tar.xz
SHA512: 
25b186ae8037dedea5691e0b77b22f2065f3c877838378651726dfa1b34ef49dcc56f1dbd124e99285e5f14489db936a886a6740495b5b279e8363424bfb3433
  mesa-19.1.0.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0.tar.xz.sig



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

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set, Reset}Event on gen7

2019-06-11 Thread Jason Ekstrand

Feel free to call it a bugfix and CC stable if you'd like.

On Tue, Jun 11, 2019 at 10:54 AM Jason Ekstrand 
wrote:

>
>
> On Mon, Jun 10, 2019 at 6:21 AM Ville Syrjala <
> ville.syrj...@linux.intel.com> wrote:
>
>> From: Ville Syrjälä 
>>
>> Modern DXVK requires event support [1], but looks like it only
>> uses vkCmdSetEvent() + vkGetEventStatus(). So we can just
>> borrow the relevant code from gen8, leaving CmdWaitEvents still
>> unimplemented.
>>
>> [1]
>> https://github.com/doitsujin/dxvk/commit/8c3900c533d83d12c970b905183d17a1d3e8df1f
>>
>> v2: Also move CmdWaitEvents into genX_cmd_buffer.c (Jason)
>>
>> Signed-off-by: Ville Syrjälä 
>> ---
>>  src/intel/vulkan/gen7_cmd_buffer.c |  38 --
>>  src/intel/vulkan/gen8_cmd_buffer.c | 102 ---
>>  src/intel/vulkan/genX_cmd_buffer.c | 107 +
>>  3 files changed, 107 insertions(+), 140 deletions(-)
>>
>> diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
>> b/src/intel/vulkan/gen7_cmd_buffer.c
>> index 380283bdd563..115d12b35362 100644
>> --- a/src/intel/vulkan/gen7_cmd_buffer.c
>> +++ b/src/intel/vulkan/gen7_cmd_buffer.c
>> @@ -286,41 +286,3 @@ genX(cmd_buffer_enable_pma_fix)(struct
>> anv_cmd_buffer *cmd_buffer,
>>  {
>> /* The NP PMA fix doesn't exist on gen7 */
>>  }
>> -
>> -void genX(CmdSetEvent)(
>> -VkCommandBuffer commandBuffer,
>> -VkEvent event,
>> -VkPipelineStageFlagsstageMask)
>> -{
>> -   anv_finishme("Implement events on gen7");
>> -}
>> -
>> -void genX(CmdResetEvent)(
>> -VkCommandBuffer commandBuffer,
>> -VkEvent event,
>> -VkPipelineStageFlagsstageMask)
>> -{
>> -   anv_finishme("Implement events on gen7");
>> -}
>> -
>> -void genX(CmdWaitEvents)(
>> -VkCommandBuffer commandBuffer,
>> -uint32_teventCount,
>> -const VkEvent*  pEvents,
>> -VkPipelineStageFlagssrcStageMask,
>> -VkPipelineStageFlagsdestStageMask,
>> -uint32_tmemoryBarrierCount,
>> -const VkMemoryBarrier*  pMemoryBarriers,
>> -uint32_tbufferMemoryBarrierCount,
>> -const VkBufferMemoryBarrier*pBufferMemoryBarriers,
>> -uint32_timageMemoryBarrierCount,
>> -const VkImageMemoryBarrier* pImageMemoryBarriers)
>> -{
>> -   anv_finishme("Implement events on gen7");
>> -
>> -   genX(CmdPipelineBarrier)(commandBuffer, srcStageMask, destStageMask,
>> -false, /* byRegion */
>> -memoryBarrierCount, pMemoryBarriers,
>> -bufferMemoryBarrierCount,
>> pBufferMemoryBarriers,
>> -imageMemoryBarrierCount,
>> pImageMemoryBarriers);
>> -}
>> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
>> b/src/intel/vulkan/gen8_cmd_buffer.c
>> index 6568d2c75113..2e6d9de9f4a8 100644
>> --- a/src/intel/vulkan/gen8_cmd_buffer.c
>> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
>> @@ -565,105 +565,3 @@ void genX(CmdBindIndexBuffer)(
>>
>> cmd_buffer->state.gfx.dirty |= ANV_CMD_DIRTY_INDEX_BUFFER;
>>  }
>> -
>> -/* Set of stage bits for which are pipelined, i.e. they get queued by the
>> - * command streamer for later execution.
>> - */
>> -#define ANV_PIPELINE_STAGE_PIPELINED_BITS \
>> -   (VK_PIPELINE_STAGE_VERTEX_INPUT_BIT | \
>> -VK_PIPELINE_STAGE_VERTEX_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | \
>> -VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT | \
>> -VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | \
>> -VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT | \
>> -VK_PIPELINE_STAGE_TRANSFER_BIT | \
>> -VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT | \
>> -VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT | \
>> -VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)
>> -
>> -void genX(CmdSetEvent)(
>> -VkCommandBuffer commandBuffer,
>> -VkEvent _event,
>> -VkPipelineStageFlagsstageMask)
>> -{
>> -   ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
>> -   ANV_FROM_HANDLE(anv_event, event, _event);
>> -
>> -   anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
>> -  if (stageMask & ANV_PIPELINE_STAGE_PIPELINED_BITS) {
>> - pc.StallAtPixelScoreboard = true;
>> - pc.CommandStreamerStallEnable = true;
>> -  }
>> -
>> -  pc.DestinationAddressType  =

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: Reuse gen8 Cmd{Set, Reset}Event on gen7

2019-06-11 Thread Jason Ekstrand

On Mon, Jun 10, 2019 at 6:21 AM Ville Syrjala 
wrote:

> From: Ville Syrjälä 
>
> Modern DXVK requires event support [1], but looks like it only
> uses vkCmdSetEvent() + vkGetEventStatus(). So we can just
> borrow the relevant code from gen8, leaving CmdWaitEvents still
> unimplemented.
>
> [1]
> https://github.com/doitsujin/dxvk/commit/8c3900c533d83d12c970b905183d17a1d3e8df1f
>
> v2: Also move CmdWaitEvents into genX_cmd_buffer.c (Jason)
>
> Signed-off-by: Ville Syrjälä 
> ---
>  src/intel/vulkan/gen7_cmd_buffer.c |  38 --
>  src/intel/vulkan/gen8_cmd_buffer.c | 102 ---
>  src/intel/vulkan/genX_cmd_buffer.c | 107 +
>  3 files changed, 107 insertions(+), 140 deletions(-)
>
> diff --git a/src/intel/vulkan/gen7_cmd_buffer.c
> b/src/intel/vulkan/gen7_cmd_buffer.c
> index 380283bdd563..115d12b35362 100644
> --- a/src/intel/vulkan/gen7_cmd_buffer.c
> +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> @@ -286,41 +286,3 @@ genX(cmd_buffer_enable_pma_fix)(struct anv_cmd_buffer
> *cmd_buffer,
>  {
> /* The NP PMA fix doesn't exist on gen7 */
>  }
> -
> -void genX(CmdSetEvent)(
> -VkCommandBuffer commandBuffer,
> -VkEvent event,
> -VkPipelineStageFlagsstageMask)
> -{
> -   anv_finishme("Implement events on gen7");
> -}
> -
> -void genX(CmdResetEvent)(
> -VkCommandBuffer commandBuffer,
> -VkEvent event,
> -VkPipelineStageFlagsstageMask)
> -{
> -   anv_finishme("Implement events on gen7");
> -}
> -
> -void genX(CmdWaitEvents)(
> -VkCommandBuffer commandBuffer,
> -uint32_teventCount,
> -const VkEvent*  pEvents,
> -VkPipelineStageFlagssrcStageMask,
> -VkPipelineStageFlagsdestStageMask,
> -uint32_tmemoryBarrierCount,
> -const VkMemoryBarrier*  pMemoryBarriers,
> -uint32_tbufferMemoryBarrierCount,
> -const VkBufferMemoryBarrier*pBufferMemoryBarriers,
> -uint32_timageMemoryBarrierCount,
> -const VkImageMemoryBarrier* pImageMemoryBarriers)
> -{
> -   anv_finishme("Implement events on gen7");
> -
> -   genX(CmdPipelineBarrier)(commandBuffer, srcStageMask, destStageMask,
> -false, /* byRegion */
> -memoryBarrierCount, pMemoryBarriers,
> -bufferMemoryBarrierCount,
> pBufferMemoryBarriers,
> -imageMemoryBarrierCount,
> pImageMemoryBarriers);
> -}
> diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
> b/src/intel/vulkan/gen8_cmd_buffer.c
> index 6568d2c75113..2e6d9de9f4a8 100644
> --- a/src/intel/vulkan/gen8_cmd_buffer.c
> +++ b/src/intel/vulkan/gen8_cmd_buffer.c
> @@ -565,105 +565,3 @@ void genX(CmdBindIndexBuffer)(
>
> cmd_buffer->state.gfx.dirty |= ANV_CMD_DIRTY_INDEX_BUFFER;
>  }
> -
> -/* Set of stage bits for which are pipelined, i.e. they get queued by the
> - * command streamer for later execution.
> - */
> -#define ANV_PIPELINE_STAGE_PIPELINED_BITS \
> -   (VK_PIPELINE_STAGE_VERTEX_INPUT_BIT | \
> -VK_PIPELINE_STAGE_VERTEX_SHADER_BIT | \
> -VK_PIPELINE_STAGE_TESSELLATION_CONTROL_SHADER_BIT | \
> -VK_PIPELINE_STAGE_TESSELLATION_EVALUATION_SHADER_BIT | \
> -VK_PIPELINE_STAGE_GEOMETRY_SHADER_BIT | \
> -VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT | \
> -VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT | \
> -VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT | \
> -VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT | \
> -VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT | \
> -VK_PIPELINE_STAGE_TRANSFER_BIT | \
> -VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT | \
> -VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT | \
> -VK_PIPELINE_STAGE_ALL_COMMANDS_BIT)
> -
> -void genX(CmdSetEvent)(
> -VkCommandBuffer commandBuffer,
> -VkEvent _event,
> -VkPipelineStageFlagsstageMask)
> -{
> -   ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
> -   ANV_FROM_HANDLE(anv_event, event, _event);
> -
> -   anv_batch_emit(_buffer->batch, GENX(PIPE_CONTROL), pc) {
> -  if (stageMask & ANV_PIPELINE_STAGE_PIPELINED_BITS) {
> - pc.StallAtPixelScoreboard = true;
> - pc.CommandStreamerStallEnable = true;
> -  }
> -
> -  pc.DestinationAddressType  = DAT_PPGTT,
> -  pc.PostSyncOperation   = WriteImmediateData,
> -  pc.Address = (struct anv_address) {
> - cmd_buffer->device->dynamic_state_pool.block_pool.bo,
> - event->state.offset
> -  };
> -  pc.ImmediateData   = VK_EVENT_SET;
>

Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available



On 6/11/19 4:56 PM, Alex Deucher wrote:

On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset
 wrote:

On VegaM, the visible VRAM size is equal to the VRAM size, which
means only two heaps are exposed.

FWIW, this is not VegaM specific.  The vram size could be equal to the
visible vram size on any asic depending on whether the platform
supports large or resizeable BARs or not.
Yeah, not saying it's specific to VegaM. It's just the first time I hit 
this, so I included that patch in the VegaM series. :-)


Alex


This fixes dEQP-VK.api.info.device.memory_budget.

Cc: 19.0 19.1 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_device.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 358fc7cb30a..31b9b4e9875 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1489,9 +1489,11 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
 RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
 VkPhysicalDeviceMemoryProperties *memory_properties = 
>memory_properties;
 uint64_t visible_vram_size = radv_get_visible_vram_size(device);
+   int vram_index = -1, visible_vram_index = -1, gtt_index = -1;
 uint64_t vram_size = radv_get_vram_size(device);
 uint64_t gtt_size = device->rad_info.gart_size;
 uint64_t heap_budget, heap_usage;
+   uint32_t heap_count = 0;

 /* For all memory heaps, the computation of budget is as follow:
  *  heap_budget = heap_size - global_heap_usage + app_heap_usage
@@ -1503,6 +1505,7 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
  * in presence of shared buffers).
  */
 if (vram_size) {
+   vram_index = heap_count++;
 heap_usage = device->ws->query_value(device->ws,
  RADEON_ALLOCATED_VRAM);

@@ -1510,11 +1513,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
 device->ws->query_value(device->ws, RADEON_VRAM_USAGE) 
+
 heap_usage;

-   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
+   memoryBudget->heapBudget[vram_index] = heap_budget;
+   memoryBudget->heapUsage[vram_index] = heap_usage;
 }

 if (visible_vram_size) {
+   visible_vram_index = heap_count++;
 heap_usage = device->ws->query_value(device->ws,
  
RADEON_ALLOCATED_VRAM_VIS);

@@ -1522,11 +1526,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
 device->ws->query_value(device->ws, 
RADEON_VRAM_VIS_USAGE) +
 heap_usage;

-   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_usage;
+   memoryBudget->heapBudget[visible_vram_index] = heap_budget;
+   memoryBudget->heapUsage[visible_vram_index] = heap_usage;
 }

 if (gtt_size) {
+   gtt_index = heap_count++;
 heap_usage = device->ws->query_value(device->ws,
  RADEON_ALLOCATED_GTT);

@@ -1534,8 +1539,8 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
 device->ws->query_value(device->ws, RADEON_GTT_USAGE) +
 heap_usage;

-   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
+   memoryBudget->heapBudget[gtt_index] = heap_budget;
+   memoryBudget->heapUsage[gtt_index++] = heap_usage;
 }

 /* The heapBudget and heapUsage values must be zero for array elements
--
2.22.0

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

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

Re: [Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available

2019-06-11 Thread Alex Deucher

On Tue, Jun 11, 2019 at 10:43 AM Samuel Pitoiset
 wrote:
>
> On VegaM, the visible VRAM size is equal to the VRAM size, which
> means only two heaps are exposed.

FWIW, this is not VegaM specific.  The vram size could be equal to the
visible vram size on any asic depending on whether the platform
supports large or resizeable BARs or not.

Alex

>
> This fixes dEQP-VK.api.info.device.memory_budget.
>
> Cc: 19.0 19.1 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_device.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 358fc7cb30a..31b9b4e9875 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -1489,9 +1489,11 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
> VkPhysicalDeviceMemoryProperties *memory_properties = 
> >memory_properties;
> uint64_t visible_vram_size = radv_get_visible_vram_size(device);
> +   int vram_index = -1, visible_vram_index = -1, gtt_index = -1;
> uint64_t vram_size = radv_get_vram_size(device);
> uint64_t gtt_size = device->rad_info.gart_size;
> uint64_t heap_budget, heap_usage;
> +   uint32_t heap_count = 0;
>
> /* For all memory heaps, the computation of budget is as follow:
>  *  heap_budget = heap_size - global_heap_usage + app_heap_usage
> @@ -1503,6 +1505,7 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
>  * in presence of shared buffers).
>  */
> if (vram_size) {
> +   vram_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  RADEON_ALLOCATED_VRAM);
>
> @@ -1510,11 +1513,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, 
> RADEON_VRAM_USAGE) +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
> +   memoryBudget->heapBudget[vram_index] = heap_budget;
> +   memoryBudget->heapUsage[vram_index] = heap_usage;
> }
>
> if (visible_vram_size) {
> +   visible_vram_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  
> RADEON_ALLOCATED_VRAM_VIS);
>
> @@ -1522,11 +1526,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, 
> RADEON_VRAM_VIS_USAGE) +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
> heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
> heap_usage;
> +   memoryBudget->heapBudget[visible_vram_index] = heap_budget;
> +   memoryBudget->heapUsage[visible_vram_index] = heap_usage;
> }
>
> if (gtt_size) {
> +   gtt_index = heap_count++;
> heap_usage = device->ws->query_value(device->ws,
>  RADEON_ALLOCATED_GTT);
>
> @@ -1534,8 +1539,8 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
> physicalDevice,
> device->ws->query_value(device->ws, RADEON_GTT_USAGE) 
> +
> heap_usage;
>
> -   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
> -   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
> +   memoryBudget->heapBudget[gtt_index] = heap_budget;
> +   memoryBudget->heapUsage[gtt_index++] = heap_usage;
> }
>
> /* The heapBudget and heapUsage values must be zero for array elements
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] panfrost/midgard: Decode LOD/bias registers

For constant LODs/biases, we can use an immediate embedded in the
texture (already decoded); for non-constant, we have to use a register
squeezed into the usual immediate field, which is decoded here.

Signed-off-by: Alyssa Rosenzweig 
---
 .../drivers/panfrost/midgard/disassemble.c| 22 +-
 .../drivers/panfrost/midgard/midgard.h| 41 +--
 2 files changed, 58 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/disassemble.c 
b/src/gallium/drivers/panfrost/midgard/disassemble.c
index 4eb490ff681..88202a93923 100644
--- a/src/gallium/drivers/panfrost/midgard/disassemble.c
+++ b/src/gallium/drivers/panfrost/midgard/disassemble.c
@@ -1179,9 +1179,27 @@ print_texture_word(uint32_t *word, unsigned tabs)
 printf(", ");
 }
 
+char lod_operand = texture_op_takes_bias(texture->op) ? '+' : '=';
+
 if (texture->lod_register) {
-/* TODO: Decode */
-printf("lod/bias/grad reg 0x%X (%X), ", texture->bias, 
texture->bias_int);
+midgard_tex_register_select sel;
+uint8_t raw = texture->bias;
+memcpy(, , sizeof(raw));
+
+unsigned c = (sel.component_hi << 1) | sel.component_lo;
+
+printf("lod %c ", lod_operand);
+print_texture_reg(sel.full, sel.select, sel.upper);
+printf(".%c, ", components[c]);
+
+if (!sel.component_hi)
+printf(" /* gradient? */");
+
+if (texture->bias_int)
+printf(" /* bias_int = 0x%X */", texture->bias_int);
+
+if (sel.zero)
+printf(" /* sel.zero = 0x%X */", sel.zero);
 } else if (texture->op == TEXTURE_OP_TEXEL_FETCH) {
 /* For texel fetch, the int LOD is in the fractional place and
  * there is no fraction / possibility of bias. We *always* have
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h 
b/src/gallium/drivers/panfrost/midgard/midgard.h
index 532734820e9..79933973b25 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -489,6 +489,37 @@ __attribute__((__packed__))
 }
 midgard_load_store;
 
+/* 8-bit register selector used in texture ops to select a bias/LOD/gradient
+ * register, shoved into the `bias` field */
+
+typedef struct
+__attribute__((__packed__))
+{
+/* Combines with component_hi to form 2-bit component select out of
+ * xyzw, as the component for bias/LOD and the starting component of a
+ * gradient vector */
+
+unsigned component_lo : 1;
+
+/* Register select between r28/r29 */
+unsigned select : 1;
+
+/* For a half-register, selects the upper half */
+unsigned upper : 1;
+
+/* Specifies a full-register, clear for a half-register. Mutually
+ * exclusive with upper. */
+unsigned full : 1;
+
+/* Higher half of component_lo. Always seen to be set for LOD/bias
+ * and clear for processed gradients, but I'm not sure if that's a
+ * hardware requirement. */
+unsigned component_hi : 1;
+
+/* Padding to make this 8-bit */
+unsigned zero : 3;
+} midgard_tex_register_select;
+
 /* Texture pipeline results are in r28-r29 */
 #define REG_TEX_BASE 28
 
@@ -572,10 +603,14 @@ __attribute__((__packed__))
 signed offset_y : 4;
 signed offset_z : 4;
 
-/* Texture bias or LOD, depending on whether it is executed in a
- * fragment/vertex shader respectively. Compute as int(2^8 * biasf).
+/* In immediate bias mode, for a normal texture op, this is
+ * texture bias, computed as int(2^8 * frac(biasf)), with
+ * bias_int = floor(bias). For a textureLod, it's that, but
+ * s/bias/lod. For a texel fetch, this is the LOD as-is.
  *
- * For texel fetch, this is the LOD as is. */
+ * In register mode, this is a midgard_tex_register_select
+ * structure and bias_int is zero */
+
 unsigned bias : 8;
 unsigned bias_int  : 8;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/2] radv: fix occlusion queries on VegaM

The number of render backends is 16 but the enabled mask is 0x.

This fixes dEQP-VK.query_pool.* and dEQP-VK.multiview.*.

Cc: 19.0 19.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_query.c | 48 +
 1 file changed, 27 insertions(+), 21 deletions(-)

diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index ff9ceceb3ed..3bbd10cbb34 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -40,18 +40,6 @@
 static const int pipelinestat_block_size = 11 * 8;
 static const unsigned pipeline_statistics_indices[] = {7, 6, 3, 4, 5, 2, 1, 0, 
8, 9, 10};
 
-static unsigned get_max_db(struct radv_device *device)
-{
-   unsigned num_db = device->physical_device->rad_info.num_render_backends;
-   MAYBE_UNUSED unsigned rb_mask = 
device->physical_device->rad_info.enabled_rb_mask;
-
-   /* Otherwise we need to change the query reset procedure */
-   assert(rb_mask == ((1ull << num_db) - 1));
-
-   return num_db;
-}
-
-
 static nir_ssa_def *nir_test_flag(nir_builder *b, nir_ssa_def *flags, uint32_t 
flag)
 {
return nir_i2b(b, nir_iand(b, flags, nir_imm_int(b, flag)));
@@ -108,12 +96,14 @@ build_occlusion_query_shader(struct radv_device *device) {
 *  uint64_t dst_offset = dst_stride * global_id.x;
 *  bool available = true;
 *  for (int i = 0; i < db_count; ++i) {
-*  uint64_t start = src_buf[src_offset + 16 * i];
-*  uint64_t end = src_buf[src_offset + 16 * i + 8];
-*  if ((start & (1ull << 63)) && (end & (1ull << 63)))
-*  result += end - start;
-*  else
-*  available = false;
+*  if (enabled_rb_mask & (1 << i)) {
+*  uint64_t start = src_buf[src_offset + 16 * i];
+*  uint64_t end = src_buf[src_offset + 16 * i + 8];
+*  if ((start & (1ull << 63)) && (end & (1ull << 
63)))
+*  result += end - start;
+*  else
+*  available = false;
+*  }
 *  }
 *  uint32_t elem_size = flags & VK_QUERY_RESULT_64_BIT ? 8 : 4;
 *  if ((flags & VK_QUERY_RESULT_PARTIAL_BIT) || available) {
@@ -139,7 +129,8 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_variable *start = nir_local_variable_create(b.impl, 
glsl_uint64_t_type(), "start");
nir_variable *end = nir_local_variable_create(b.impl, 
glsl_uint64_t_type(), "end");
nir_variable *available = nir_local_variable_create(b.impl, 
glsl_bool_type(), "available");
-   unsigned db_count = get_max_db(device);
+   unsigned enabled_rb_mask = 
device->physical_device->rad_info.enabled_rb_mask;
+   unsigned db_count = 
device->physical_device->rad_info.num_render_backends;
 
nir_ssa_def *flags = radv_load_push_int(, 0, "flags");
 
@@ -187,6 +178,16 @@ build_occlusion_query_shader(struct radv_device *device) {
nir_ssa_def *current_outer_count = nir_load_var(, outer_counter);
radv_break_on_count(, outer_counter, nir_imm_int(, db_count));
 
+   nir_ssa_def *enabled_cond =
+   nir_iand(, nir_imm_int(, enabled_rb_mask),
+nir_ishl(, nir_imm_int(, 1), 
current_outer_count));
+
+   nir_if *enabled_if = nir_if_create(b.shader);
+   enabled_if->condition = nir_src_for_ssa(nir_i2b(, enabled_cond));
+   nir_cf_node_insert(b.cursor, _if->cf_node);
+
+   b.cursor = nir_after_cf_list(_if->then_list);
+
nir_ssa_def *load_offset = nir_imul(, current_outer_count, 
nir_imm_int(, 16));
load_offset = nir_iadd(, input_base, load_offset);
 
@@ -1042,7 +1043,7 @@ VkResult radv_CreateQueryPool(
 
switch(pCreateInfo->queryType) {
case VK_QUERY_TYPE_OCCLUSION:
-   pool->stride = 16 * get_max_db(device);
+   pool->stride = 16 * 
device->physical_device->rad_info.num_render_backends;
break;
case VK_QUERY_TYPE_PIPELINE_STATISTICS:
pool->stride = pipelinestat_block_size * 2;
@@ -1147,12 +1148,17 @@ VkResult radv_GetQueryPoolResults(
}
case VK_QUERY_TYPE_OCCLUSION: {
volatile uint64_t const *src64 = (volatile uint64_t 
const *)src;
+   uint32_t db_count = 
device->physical_device->rad_info.num_render_backends;
+   uint32_t enabled_rb_mask = 
device->physical_device->rad_info.enabled_rb_mask;
uint64_t sample_count = 0;
-   int db_count = get_max_db(device);
available = 1;
 
for (int i = 0; i < db_count; ++i) {
uint64_t start, end;
+
+

[Mesa-dev] [PATCH 2/2] radv: fix VK_EXT_memory_budget if one heap isn't available

On VegaM, the visible VRAM size is equal to the VRAM size, which
means only two heaps are exposed.

This fixes dEQP-VK.api.info.device.memory_budget.

Cc: 19.0 19.1 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_device.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 358fc7cb30a..31b9b4e9875 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1489,9 +1489,11 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
RADV_FROM_HANDLE(radv_physical_device, device, physicalDevice);
VkPhysicalDeviceMemoryProperties *memory_properties = 
>memory_properties;
uint64_t visible_vram_size = radv_get_visible_vram_size(device);
+   int vram_index = -1, visible_vram_index = -1, gtt_index = -1;
uint64_t vram_size = radv_get_vram_size(device);
uint64_t gtt_size = device->rad_info.gart_size;
uint64_t heap_budget, heap_usage;
+   uint32_t heap_count = 0;
 
/* For all memory heaps, the computation of budget is as follow:
 *  heap_budget = heap_size - global_heap_usage + app_heap_usage
@@ -1503,6 +1505,7 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
 * in presence of shared buffers).
 */
if (vram_size) {
+   vram_index = heap_count++;
heap_usage = device->ws->query_value(device->ws,
 RADEON_ALLOCATED_VRAM);
 
@@ -1510,11 +1513,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
device->ws->query_value(device->ws, RADEON_VRAM_USAGE) +
heap_usage;
 
-   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM] = heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM] = heap_usage;
+   memoryBudget->heapBudget[vram_index] = heap_budget;
+   memoryBudget->heapUsage[vram_index] = heap_usage;
}
 
if (visible_vram_size) {
+   visible_vram_index = heap_count++;
heap_usage = device->ws->query_value(device->ws,
 RADEON_ALLOCATED_VRAM_VIS);
 
@@ -1522,11 +1526,12 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
device->ws->query_value(device->ws, 
RADEON_VRAM_VIS_USAGE) +
heap_usage;
 
-   memoryBudget->heapBudget[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_VRAM_CPU_ACCESS] = 
heap_usage;
+   memoryBudget->heapBudget[visible_vram_index] = heap_budget;
+   memoryBudget->heapUsage[visible_vram_index] = heap_usage;
}
 
if (gtt_size) {
+   gtt_index = heap_count++;
heap_usage = device->ws->query_value(device->ws,
 RADEON_ALLOCATED_GTT);
 
@@ -1534,8 +1539,8 @@ radv_get_memory_budget_properties(VkPhysicalDevice 
physicalDevice,
device->ws->query_value(device->ws, RADEON_GTT_USAGE) +
heap_usage;
 
-   memoryBudget->heapBudget[RADV_MEM_HEAP_GTT] = heap_budget;
-   memoryBudget->heapUsage[RADV_MEM_HEAP_GTT] = heap_usage;
+   memoryBudget->heapBudget[gtt_index] = heap_budget;
+   memoryBudget->heapUsage[gtt_index++] = heap_usage;
}
 
/* The heapBudget and heapUsage values must be zero for array elements
-- 
2.22.0

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

[Mesa-dev] [PATCH 0/2] radv: two fixes for Intel NUC

Hi,

This series contains two fixes for VegaM, the first one is quite important
while the second one is only useful if VK_EXT_memory_budget is used.

There is still some TC-compat failures that I need to figure out.

With these two patches, we only have ~40 CTS failures.

Please review,
Thanks!

Samuel Pitoiset (2):
  radv: fix occlusion queries on VegaM
  radv: fix VK_EXT_memory_budget if one heap isn't available

 src/amd/vulkan/radv_device.c | 17 -
 src/amd/vulkan/radv_query.c  | 48 
 2 files changed, 38 insertions(+), 27 deletions(-)

-- 
2.22.0

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

Re: [Mesa-dev] [PATCH v2] radv: assert on inline uniform blocks in radv_CmdPushDescriptorSetKHR()


Looks reasonable.

Reviewed-by: Samuel Pitoiset 

On 6/11/19 4:03 PM, Samuel Iglesias Gonsálvez wrote:

According to the Vulkan spec, inline uniform blocks are not allowed
to be updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
  that descriptor sets must not be allocated using this layout, and
  descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
  VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
  elements of pBindings must not have a descriptorType of
  VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
  src/amd/vulkan/radv_cmd_buffer.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 3faaf94eb99..d69bec60bb8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3245,6 +3245,14 @@ void radv_CmdPushDescriptorSetKHR(
   pipelineBindPoint))
return;
  
+	/* Check that there are no inline uniform block updates when calling vkCmdPushDescriptorSetKHR()

+* because it is invalid, according to Vulkan spec.
+*/
+   for (int i = 0; i < descriptorWriteCount; i++) {
+   const VkWriteDescriptorSet *writeset = [i];
+   assert(writeset->descriptorType != 
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT);
+   }
+
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
descriptorWriteCount, pDescriptorWrites, 0, 
NULL);

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

Re: [Mesa-dev] [PATCH 1/2] anv: ignore inline uniform blocks in anv_CmdPushDescriptorSetKHR()

2019-06-11 Thread Jason Ekstrand


Alright then.

Reviewed-by: Jason Ekstrand 

On June 11, 2019 04:57:27 Samuel Iglesias Gonsálvez  
wrote:



According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor sets must not be allocated using this layout, and
descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pBindings must not have a descriptorType of
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
src/intel/vulkan/anv_cmd_buffer.c | 13 -
1 file changed, 13 deletions(-)

diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c

index b0ce00f6daf..3c020a1d5b2 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -1081,19 +1081,6 @@ void anv_CmdPushDescriptorSetKHR(
 }
 break;

-  case VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT: {
- const VkWriteDescriptorSetInlineUniformBlockEXT *inline_write =
-vk_find_struct_const(write->pNext,
- 
WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT);

- assert(inline_write->dataSize == write->descriptorCount);
- anv_descriptor_set_write_inline_uniform_data(cmd_buffer->device, set,
-  write->dstBinding,
-  inline_write->pData,
-  write->dstArrayElement,
-  inline_write->dataSize);
- break;
-  }
-
  default:
 break;
  }
--
2.17.1

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




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

[Mesa-dev] [PATCH v2] radv: assert on inline uniform blocks in radv_CmdPushDescriptorSetKHR()

According to the Vulkan spec, inline uniform blocks are not allowed
to be updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
 that descriptor sets must not be allocated using this layout, and
 descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
 VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
 elements of pBindings must not have a descriptorType of
 VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/amd/vulkan/radv_cmd_buffer.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 3faaf94eb99..d69bec60bb8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3245,6 +3245,14 @@ void radv_CmdPushDescriptorSetKHR(
   pipelineBindPoint))
return;
 
+   /* Check that there are no inline uniform block updates when calling 
vkCmdPushDescriptorSetKHR()
+* because it is invalid, according to Vulkan spec.
+*/
+   for (int i = 0; i < descriptorWriteCount; i++) {
+   const VkWriteDescriptorSet *writeset = [i];
+   assert(writeset->descriptorType != 
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT);
+   }
+
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
descriptorWriteCount, pDescriptorWrites, 0, 
NULL);
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] radv: Change memory type order for GPUs without dedicated VRAM

2019-06-11 Thread Christian König


Am 10.06.19 um 15:56 schrieb Bas Nieuwenhuizen:

On Sat, Jun 8, 2019 at 3:36 PM Alex Smith  wrote:

On Mon, 3 Jun 2019 at 13:27, Koenig, Christian  wrote:

Am 03.06.19 um 14:21 schrieb Alex Smith:

On Mon, 3 Jun 2019 at 11:57, Koenig, Christian  wrote:

Am 02.06.19 um 12:32 schrieb Alex Smith:

Put the uncached GTT type at a higher index than the visible VRAM type,
rather than having GTT first.

When we don't have dedicated VRAM, we don't have a non-visible VRAM
type, and the property flags for GTT and visible VRAM are identical.
According to the spec, for types with identical flags, we should give
the one with better performance a lower index.

Previously, apps which follow the spec guidance for choosing a memory
type would have picked the GTT type in preference to visible VRAM (all
Feral games will do this), and end up with lower performance.

On a Ryzen 5 2500U laptop (Raven Ridge), this improves average FPS in
the Rise of the Tomb Raider benchmark by up to ~30%. Tested a couple of
other (Feral) games and saw similar improvement on those as well.

Well that patch doesn't looks like a good idea to me.

Using VRAM over uncached GTT should have something between no and only
minimal performance difference on APU.

To make things even worse VRAM is still needed for scanout and newer
laptops have only a very very low default setting (32 or 16MB). So you
can end up in VRAM clashing on those systems.

Can you check some kernel statistics to figure out what exactly is going
on here?


What statistics should I look at?


First of all take a look at amdgpu_gem_info file in the debugfs directory while 
using GTT and match that to using VRAM. You should see a lot more of GTT ... 
CPU_GTT_USWC entries with the GTT variant. If the CPU_GTT_USWC flag is missing 
we have found the problem.

If that looks ok, then take a look at the ttm_page_pool or ttm_dma_page_pool 
file and see how many wc/uc and wc/uc huge pages you got. Huge pages should be 
used for anything larger than 2MB, if not we have found the problem.

If that still isn't the issue I need to take a look at the VM code again and 
see if we still map VRAM/GTT differently on APUs.


OK, got around to looking at this. amdgpu_gem_info does have more USWC entries 
when using GTT. I've attached the output from VRAM vs GTT in case you can spot 
anything else in there.

ttm_page_pool has 9806 wc, 238 wc huge, no uc or uc huge.

To add to this, I tried rounding up the size all application GTT
allocations to a multiple of 2 megabytes (+ a suballocator for buffers
< 2M). This increased performance a bit but not nearly what going from
GTT->"VRAM" brings.


I need to dig deeper when I have a bit more time.

The logs Alex provided didn't showed anything obviously wrong, so no 
idea what's the actual problem here.


Anyway feel free to go ahead with this approach, but please keep in mind 
that this might cause problems on some systems.


Christian.




FWIW this was from kernel 5.0.10, I just upgraded to 5.1.6 and still the same 
perf difference there.

Thanks,
Alex



Thanks,
Christian.


Thanks,
Alex



Regards,
Christian.


Signed-off-by: Alex Smith 
---
I noticed that the memory types advertised on my Raven laptop looked a
bit odd so played around with it and found this. I'm not sure if it is
actually expected that the performance difference between visible VRAM
and GTT is so large, seeing as it's not dedicated VRAM, but the results
are clear (and consistent, tested multiple times).
---
   src/amd/vulkan/radv_device.c | 18 +++---
   1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 3cf050ed220..d36ee226ebd 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -171,12 +171,11 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
   .heapIndex = vram_index,
   };
   }
- if (gart_index >= 0) {
+ if (gart_index >= 0 && device->rad_info.has_dedicated_vram) {
   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 |
- (device->rad_info.has_dedicated_vram ? 0 : 
VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT),
+ VK_MEMORY_PROPERTY_HOST_COHERENT_BIT,
   .heapIndex = gart_index,
   };
   }
@@ -189,6 +188,19 @@ radv_physical_device_init_mem_types(struct 
radv_physical_device *device)
   .heapIndex = visible_vram_index,
   };
   }
+ if (gart_index >= 0 && !device->rad_info.has_dedicated_vram) {
+ /* Put GTT after visible VRAM for GPUs without dedicated VRAM
+  * as they have identical property flags, and according to the

Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()



On 6/11/19 12:19 PM, Samuel Iglesias Gonsálvez wrote:

On 6/11/19 12:05 PM, Józef Kucia wrote:

On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
 wrote:

According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
  that descriptor sets must not be allocated using this layout, and
  descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
  VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
  elements of pBindings must not have a descriptorType of
  VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---

My only doubt is I did well in the case of
radv_meta_push_descriptor_set(), let me know if you prefer to change
it to false.


Perhaps I'm missing something, but what is the point to add the
additional checks for invalid usage? A correct program must not use
inline uniform blocks with push descriptors.


Right, it should be detected by the Validation Layers. However it is
arguable what to do in the driver's side. We can just keep it as it is
now, ignore inline uniform block updates (this patch) or even add an
assert if it affects stability of the HW (it is not the case here, we
tested it). I think ignoring the updates it's the best option, but I am
OK with what RADV developers prefer to do.

Adding an assertion looks better to me as well.


Sam



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

Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()

2019-06-11 Thread Józef Kucia

On Tue, Jun 11, 2019 at 12:19 PM Samuel Iglesias Gonsálvez
 wrote:
> Right, it should be detected by the Validation Layers. However it is
> arguable what to do in the driver's side. We can just keep it as it is
> now, ignore inline uniform block updates (this patch) or even add an
> assert if it affects stability of the HW (it is not the case here, we
> tested it). I think ignoring the updates it's the best option, but I am
> OK with what RADV developers prefer to do.

IMHO the code should be left as it is. An assert could be a good
addition, but an additional bool parameter only for handling invalid
usage doesn't seem right.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()

On 6/11/19 12:05 PM, Józef Kucia wrote:
> On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
>  wrote:
>> According to the Vulkan spec, uniform blocks are not allowed to be
>> updated through vkCmdPushDescriptorSetKHR().
>>
>> There are these spec quotes from "13.2.1. Descriptor Set Layout"
>> that are relevant for this case:
>>
>> "VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
>>  that descriptor sets must not be allocated using this layout, and
>>  descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
>>
>> "If flags contains
>>  VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
>>  elements of pBindings must not have a descriptorType of
>>  VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
>>
>> There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
>> this case but it is implied in the creation of the descriptor set
>> layout as aforementioned.
>>
>> Signed-off-by: Samuel Iglesias Gonsálvez 
>> ---
>>
>> My only doubt is I did well in the case of
>> radv_meta_push_descriptor_set(), let me know if you prefer to change
>> it to false.
>>
> Perhaps I'm missing something, but what is the point to add the
> additional checks for invalid usage? A correct program must not use
> inline uniform blocks with push descriptors.
>
Right, it should be detected by the Validation Layers. However it is
arguable what to do in the driver's side. We can just keep it as it is
now, ignore inline uniform block updates (this patch) or even add an
assert if it affects stability of the HW (it is not the case here, we
tested it). I think ignoring the updates it's the best option, but I am
OK with what RADV developers prefer to do.

Sam




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

Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()

2019-06-11 Thread Józef Kucia

On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez
 wrote:
>
> According to the Vulkan spec, uniform blocks are not allowed to be
> updated through vkCmdPushDescriptorSetKHR().
>
> There are these spec quotes from "13.2.1. Descriptor Set Layout"
> that are relevant for this case:
>
> "VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
>  that descriptor sets must not be allocated using this layout, and
>  descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
>
> "If flags contains
>  VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
>  elements of pBindings must not have a descriptorType of
>  VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
>
> There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
> this case but it is implied in the creation of the descriptor set
> layout as aforementioned.
>
> Signed-off-by: Samuel Iglesias Gonsálvez 
> ---
>
> My only doubt is I did well in the case of
> radv_meta_push_descriptor_set(), let me know if you prefer to change
> it to false.
>

Perhaps I'm missing something, but what is the point to add the
additional checks for invalid usage? A correct program must not use
inline uniform blocks with push descriptors.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()

According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
 that descriptor sets must not be allocated using this layout, and
 descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
 VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
 elements of pBindings must not have a descriptorType of
 VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---

My only doubt is I did well in the case of
radv_meta_push_descriptor_set(), let me know if you prefer to change
it to false.

 src/amd/vulkan/radv_cmd_buffer.c |  4 ++--
 src/amd/vulkan/radv_descriptor_set.c | 11 ---
 src/amd/vulkan/radv_private.h|  3 ++-
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 3faaf94eb99..38a2d0d0efe 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3219,7 +3219,7 @@ void radv_meta_push_descriptor_set(
 
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
-   descriptorWriteCount, pDescriptorWrites, 0, 
NULL);
+   descriptorWriteCount, pDescriptorWrites, 0, 
NULL, true);
 
radv_set_descriptor_set(cmd_buffer, pipelineBindPoint, push_set, set);
 }
@@ -3247,7 +3247,7 @@ void radv_CmdPushDescriptorSetKHR(
 
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
-   descriptorWriteCount, pDescriptorWrites, 0, 
NULL);
+   descriptorWriteCount, pDescriptorWrites, 0, 
NULL, true);
 
radv_set_descriptor_set(cmd_buffer, pipelineBindPoint, push_set, set);
descriptors_state->push_dirty = true;
diff --git a/src/amd/vulkan/radv_descriptor_set.c 
b/src/amd/vulkan/radv_descriptor_set.c
index bd00f68a3cb..04bbafb1ed5 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -939,7 +939,8 @@ void radv_update_descriptor_sets(
uint32_tdescriptorWriteCount,
const VkWriteDescriptorSet* pDescriptorWrites,
uint32_tdescriptorCopyCount,
-   const VkCopyDescriptorSet*  pDescriptorCopies)
+   const VkCopyDescriptorSet*  pDescriptorCopies,
+   const bool  isPushDescriptorSet)
 {
uint32_t i, j;
for (i = 0; i < descriptorWriteCount; i++) {
@@ -961,7 +962,11 @@ void radv_update_descriptor_sets(
ptr += binding_layout->offset / 4;
 
if (writeset->descriptorType == 
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT) {
-   write_block_descriptor(device, cmd_buffer, 
(uint8_t*)ptr + writeset->dstArrayElement, writeset);
+   /* Ignore inline uniform block updates when called from 
vkCmdPushDescriptorSetKHR()
+* because it is invalid, according to Vulkan spec.
+*/
+   if (!isPushDescriptorSet)
+   write_block_descriptor(device, cmd_buffer, 
(uint8_t*)ptr + writeset->dstArrayElement, writeset);
continue;
}
 
@@ -1094,7 +1099,7 @@ void radv_UpdateDescriptorSets(
RADV_FROM_HANDLE(radv_device, device, _device);
 
radv_update_descriptor_sets(device, NULL, VK_NULL_HANDLE, 
descriptorWriteCount, pDescriptorWrites,
-   descriptorCopyCount, pDescriptorCopies);
+   descriptorCopyCount, pDescriptorCopies, 
false);
 }
 
 VkResult radv_CreateDescriptorUpdateTemplate(VkDevice _device,
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 8f2e80b3017..bead0867119 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1976,7 +1976,8 @@ radv_update_descriptor_sets(struct radv_device *device,
 uint32_t descriptorWriteCount,
 const VkWriteDescriptorSet *pDescriptorWrites,
 uint32_t descriptorCopyCount,
-const VkCopyDescriptorSet *pDescriptorCopies);
+const VkCopyDescriptorSet *pDescriptorCopies,
+const bool isPushDescriptorSet);

[Mesa-dev] [PATCH 1/2] anv: ignore inline uniform blocks in anv_CmdPushDescriptorSetKHR()

According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().

There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:

"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor sets must not be allocated using this layout, and
descriptors are instead pushed by vkCmdPushDescriptorSetKHR."

"If flags contains
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pBindings must not have a descriptorType of
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".

There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/vulkan/anv_cmd_buffer.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/src/intel/vulkan/anv_cmd_buffer.c 
b/src/intel/vulkan/anv_cmd_buffer.c
index b0ce00f6daf..3c020a1d5b2 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -1081,19 +1081,6 @@ void anv_CmdPushDescriptorSetKHR(
  }
  break;
 
-  case VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT: {
- const VkWriteDescriptorSetInlineUniformBlockEXT *inline_write =
-vk_find_struct_const(write->pNext,
- 
WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT);
- assert(inline_write->dataSize == write->descriptorCount);
- anv_descriptor_set_write_inline_uniform_data(cmd_buffer->device, set,
-  write->dstBinding,
-  inline_write->pData,
-  write->dstArrayElement,
-  inline_write->dataSize);
- break;
-  }
-
   default:
  break;
   }
-- 
2.17.1

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

[Mesa-dev] mirroring ogl-sample source code in gitlab?

2019-06-11 Thread Erik Faye-Lund

While looking into dead-links on our website, I noticed that the OpenGL
Sample Implementation that SGI open sourced lacks a proper public
mirror. So I'm looking to fix this.

The tarballs are currently available from here:
http://www.servu.org/mirror/old/mirrors.bufferoverflow.xyz/oss.sgi.com/projects/ogl-sample/download/

Additionally, Jeff Muizelaar of Mozilla provides a github-mirror here:
https://github.com/jrmuizel/ogl-sample

I downloaded the tarballs from servu.org, and imported them to a git-
repo here:
https://gitlab.freedesktop.org/kusma/ogl-sample

I've verified that the trees are identical to those of Jeff Muizelaar.
But unlike his mirror, I've made sure the commits have time-stamps that
match the time-stamp of the arcives, as well as attributing the
authorship to SGI (using "Silicon Graphics International Corp <
ogl-sam...@oss.sgi.com>" as the git author).

The code is all licensed under SGI's FreeB license, which is the same
license as is used for the GLX code we have in Mesa. It should be fine
to redistribute like this as far as I can tell.

Now, I would prefer not to host this under my own user, as this isn't
really related to me other than me doing the actual archive.

So here's the question: How does people feel about hosting this under
https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK with
this, I will make that happen, and send out a patch to update the link
we have in our FAQ once that's done.

I would further propose we mark the repo as archived, which would
clearly mark that we're not maintaining it and also prevent it from
appearing in searches.

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

[Mesa-dev] [Bug 110697] glXWaitForMscOML and glXWaitVideoSyncSGI may block indefinitely