[Mesa-dev] [PATCH] intel/compiler/fs/icl: Use dummy masked urb write for tess eval

[Topi Pohjolainen]

One cannot write the URB arbitrarily and therefore the message
has to be carefully constructed. The clever tricks originate
from Kenneth and Jason, I'm just writing the patch.

Fixes GPU hangs on ICL with Vulkan CTS.

CC: Kenneth Graunke 
CC: Jason Ekstrand 
CC: Anuj Phogat 
CC: Clayton Craft 
Signed-off-by: Topi Pohjolainen 
---
 src/intel/compiler/brw_fs_visitor.cpp | 51 ++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_fs_visitor.cpp 
b/src/intel/compiler/brw_fs_visitor.cpp
index af9f803fb68..6509868f1c3 100644
--- a/src/intel/compiler/brw_fs_visitor.cpp
+++ b/src/intel/compiler/brw_fs_visitor.cpp
@@ -821,7 +821,13 @@ fs_visitor::emit_urb_writes(const fs_reg &gs_vertex_count)
header_size);
 
  fs_inst *inst = abld.emit(opcode, reg_undef, payload);
- inst->eot = slot == last_slot && stage != MESA_SHADER_GEOMETRY;
+
+ /* For ICL WA 1805992985 one needs additional write in the end. */
+ if (devinfo->gen == 11 && stage == MESA_SHADER_TESS_EVAL)
+inst->eot = false;
+ else
+inst->eot = slot == last_slot && stage != MESA_SHADER_GEOMETRY;
+
  inst->mlen = length + header_size;
  inst->offset = urb_offset;
  urb_offset = starting_urb_offset + slot + 1;
@@ -857,6 +863,49 @@ fs_visitor::emit_urb_writes(const fs_reg &gs_vertex_count)
   inst->mlen = 2;
   inst->offset = 1;
   return;
+   } 
+ 
+   /* ICL WA 1805992985:
+*
+* ICLLP GPU hangs on one of tessellation vkcts tests with DS not done. The
+* send cycle, which is a urb write with an eot must be 4 phases long and
+* all 8 lanes must valid.
+*/
+   if (devinfo->gen == 11 && stage == MESA_SHADER_TESS_EVAL) {
+  fs_reg payload = fs_reg(VGRF, alloc.allocate(6), BRW_REGISTER_TYPE_UD);
+
+  /* Workaround requires all 8 channels (lanes) to be valid. This is
+   * understood to mean they all need to be alive. First trick is to find
+   * a live channel and copy its urb handle for all the other channels to
+   * make sure all handles are valid.
+   */
+  bld.exec_all().MOV(payload, bld.emit_uniformize(urb_handle));
+
+  /* Second trick is to use masked URB write where one can tell the HW to
+   * actually write data only for selected channels even though all are
+   * active.
+   * Third trick is to take advantage of the must-be-zero (MBZ) area in
+   * the very beginning of the URB.
+   *
+   * One masks data to be written only for the first channel and uses
+   * offset zero explicitly to land data to the MBZ area avoiding trashing
+   * any other part of the URB.
+   *
+   * Since the WA says that the write needs to be 4 phases long one uses
+   * 4 slots data. All are explicitly zeros in order to to keep the MBZ
+   * area written as zeros.
+   */
+  bld.exec_all().MOV(offset(payload, bld, 1), brw_imm_ud(0x1u));
+  bld.exec_all().MOV(offset(payload, bld, 2), brw_imm_ud(0u));
+  bld.exec_all().MOV(offset(payload, bld, 3), brw_imm_ud(0u));
+  bld.exec_all().MOV(offset(payload, bld, 4), brw_imm_ud(0u));
+  bld.exec_all().MOV(offset(payload, bld, 5), brw_imm_ud(0u));
+
+  fs_inst *inst = bld.exec_all().emit(SHADER_OPCODE_URB_WRITE_SIMD8_MASKED,
+  reg_undef, payload);
+  inst->eot = true;
+  inst->mlen = 6;
+  inst->offset = 0;
}
 }
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH v2] st: require compatible driver in autotools

[Emil Velikov]

On Tue, 23 Apr 2019 at 23:10, Alyssa Ross  wrote:
>
> > Off the top of my head - none of the VL code should be build when we
> > have only a swrast driver.
> > Can you try and kill that bug, or shall I?
>
> Isn't that what this patch does?
>
> If there's only swrast, this patch prevents enabling any of the state
> trackers, so need_gallium_vl won't be set, and VL won't be built.

How about instead of tracking each driver and combination do somethings like:

if no_gallium_drivers or gallium_drivers=swrast; then
 all_vl_state_trackers=off

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

[Mesa-dev] [PATCH 1/1] radv: consider MESA_VK_VERSION_OVERRIDE when setting the api version

[Eleni Maria Stea]

Before setting the physical device API version, we should check if the
MESA_VK_VERSION_OVERRIDE environment variable is set and take it into
account.
---
 src/amd/vulkan/radv_extensions.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 9743ce1a774..8f29f4ca40f 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -333,9 +333,13 @@ VkResult radv_EnumerateInstanceVersion(
 uint32_t
 radv_physical_device_api_version(struct radv_physical_device *dev)
 {
+uint32_t override = vk_get_version_override();
+uint32_t version = VK_MAKE_VERSION(1, 0, 68);
+
 if (!ANDROID && dev->rad_info.has_syncobj_wait_for_submit)
-return ${MAX_API_VERSION.c_vk_version()};
-return VK_MAKE_VERSION(1, 0, 68);
+version = ${MAX_API_VERSION.c_vk_version()};
+
+return override ? MIN2(override, version) : version;
 }
 """)
 
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 1/1] radv: consider MESA_VK_VERSION_OVERRIDE when setting the api version

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 

On Wed, Apr 24, 2019 at 2:40 PM Eleni Maria Stea  wrote:
>
> Before setting the physical device API version, we should check if the
> MESA_VK_VERSION_OVERRIDE environment variable is set and take it into
> account.
> ---
>  src/amd/vulkan/radv_extensions.py | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_extensions.py 
> b/src/amd/vulkan/radv_extensions.py
> index 9743ce1a774..8f29f4ca40f 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -333,9 +333,13 @@ VkResult radv_EnumerateInstanceVersion(
>  uint32_t
>  radv_physical_device_api_version(struct radv_physical_device *dev)
>  {
> +uint32_t override = vk_get_version_override();
> +uint32_t version = VK_MAKE_VERSION(1, 0, 68);
> +
>  if (!ANDROID && dev->rad_info.has_syncobj_wait_for_submit)
> -return ${MAX_API_VERSION.c_vk_version()};
> -return VK_MAKE_VERSION(1, 0, 68);
> +version = ${MAX_API_VERSION.c_vk_version()};
> +
> +return override ? MIN2(override, version) : version;
>  }
>  """)
>
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/8] radeonsi: add si_debug_options for convenient adding/removing of options

[Nicolai Hähnle]

From: Nicolai Hähnle 

Move the definition of radeonsi_clear_db_cache_before_clear there,
as well as radeonsi_enable_nir.

This removes the AMD_DEBUG=nir option.

We currently still have two places for options: the driconf machinery
and AMD_DEBUG/R600_DEBUG. If we are to have a single place for options,
then the driconf machinery should be preferred since it's more flexible.

The only downside of the driconf machinery was that adding new options
was quite inconvenient. With this change, a simple boolean option can
be added with a single line of code, same as for AMD_DEBUG.

One technical limitation of this particular implementation is that while
almost all driconf features are available, the translation machinery doesn't
pick up the description strings for options added in si_debvug_options. In
practice, translations haven't been provided anyway, and this is intended
for developer options, so I'm not too worried. It could always be added
later if anybody really cares.
---
 .../drivers/radeonsi/driinfo_radeonsi.h   | 12 +++-
 src/gallium/drivers/radeonsi/si_clear.c   |  2 +-
 .../drivers/radeonsi/si_debug_options.inc |  4 ++
 src/gallium/drivers/radeonsi/si_get.c |  6 +-
 src/gallium/drivers/radeonsi/si_pipe.c| 22 ---
 src/gallium/drivers/radeonsi/si_pipe.h|  7 ++-
 src/util/merge_driinfo.py | 58 +--
 src/util/xmlpool/t_options.h  |  9 ---
 8 files changed, 89 insertions(+), 31 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h 
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index edf8edba035..d92883b9c38 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -4,13 +4,21 @@ DRI_CONF_SECTION_QUALITY
 DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_PERFORMANCE
 DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
 DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
 DRI_CONF_RADEONSI_COMMUTATIVE_BLEND_ADD("false")
 DRI_CONF_RADEONSI_ZERO_ALL_VRAM_ALLOCS("false")
 DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_DEBUG
-   DRI_CONF_RADEONSI_CLEAR_DB_CACHE_BEFORE_CLEAR("false")
-   DRI_CONF_RADEONSI_ENABLE_NIR("false")
+
+//= BEGIN VERBATIM
+#define OPT_BOOL(name, dflt, description) \
+   DRI_CONF_OPT_BEGIN_B(radeonsi_##name, #dflt) \
+   DRI_CONF_DESC(en, description) \
+   DRI_CONF_OPT_END
+
+#include "radeonsi/si_debug_options.inc"
+//= END VERBATIM
+
 DRI_CONF_SECTION_END
diff --git a/src/gallium/drivers/radeonsi/si_clear.c 
b/src/gallium/drivers/radeonsi/si_clear.c
index e1805f2a1c9..a4ebd5cf2a5 100644
--- a/src/gallium/drivers/radeonsi/si_clear.c
+++ b/src/gallium/drivers/radeonsi/si_clear.c
@@ -631,21 +631,21 @@ static void si_clear(struct pipe_context *ctx, unsigned 
buffers,
 * a coincidence and the root cause is elsewhere.
 *
 * The corruption can be fixed by putting the DB flush before
 * or after the depth clear. (surprisingly)
 *
 * https://bugs.freedesktop.org/show_bug.cgi?id=102955 
(apitrace)
 *
 * This hack decreases back-to-back ClearDepth performance.
 */
if ((sctx->db_depth_clear || sctx->db_stencil_clear) &&
-   sctx->screen->clear_db_cache_before_clear)
+   sctx->screen->options.clear_db_cache_before_clear)
sctx->flags |= SI_CONTEXT_FLUSH_AND_INV_DB;
}
 
si_blitter_begin(sctx, SI_CLEAR);
util_blitter_clear(sctx->blitter, fb->width, fb->height,
   util_framebuffer_get_num_layers(fb),
   buffers, color, depth, stencil);
si_blitter_end(sctx);
 
if (sctx->db_depth_clear) {
diff --git a/src/gallium/drivers/radeonsi/si_debug_options.inc 
b/src/gallium/drivers/radeonsi/si_debug_options.inc
new file mode 100644
index 000..165dba8baf5
--- /dev/null
+++ b/src/gallium/drivers/radeonsi/si_debug_options.inc
@@ -0,0 +1,4 @@
+OPT_BOOL(clear_db_cache_before_clear, false, "Clear DB cache before fast depth 
clear")
+OPT_BOOL(enable_nir, false, "Enable NIR")
+
+#undef OPT_BOOL
diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 67fbc50998b..fda71da16e6 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -203,21 +203,21 @@ static int si_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY:
return !sscreen->info.has_unaligned_shader_loads;
 
case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
return sscreen->info.has_sparse_vm_mappings ?
RADEON_SPARSE_PAGE_SIZE : 0;
 
c

[Mesa-dev] [PATCH 2/8] util/u_log: flush auto loggers before starting a new page

[Nicolai Hähnle]

From: Nicolai Hähnle 

Without this, command stream dumps of radeonsi may misleadingly end up
in a later page.
---
 src/gallium/auxiliary/util/u_log.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_log.c 
b/src/gallium/auxiliary/util/u_log.c
index 90fd24ca394..095421edd06 100644
--- a/src/gallium/auxiliary/util/u_log.c
+++ b/src/gallium/auxiliary/util/u_log.c
@@ -180,35 +180,39 @@ u_log_chunk(struct u_log_context *ctx, const struct 
u_log_chunk_type *type,
 out_of_memory:
fprintf(stderr, "Gallium: u_log: out of memory\n");
 }
 
 /**
  * Convenience helper that starts a new page and prints the previous one.
  */
 void
 u_log_new_page_print(struct u_log_context *ctx, FILE *stream)
 {
+   u_log_flush(ctx);
+
if (ctx->cur) {
   u_log_page_print(ctx->cur, stream);
   u_log_page_destroy(ctx->cur);
   ctx->cur = NULL;
}
 }
 
 /**
  * Return the current page from the logging context and start a new one.
  *
  * The caller is responsible for destroying the returned page.
  */
 struct u_log_page *
 u_log_new_page(struct u_log_context *ctx)
 {
+   u_log_flush(ctx);
+
struct u_log_page *page = ctx->cur;
ctx->cur = NULL;
return page;
 }
 
 /**
  * Free all data associated with \p page.
  */
 void
 u_log_page_destroy(struct u_log_page *page)
-- 
2.20.1

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

[Mesa-dev] [PATCH 0/8] ddebug, radeonsi: misc changes to help debugging

[Nicolai Hähnle]

Hi folks,

this is a collection of assorted patches that should help with driver
debugging:

- add driconf-style debug options in a convenient way
- some minor ddebug cleanups
- allow dumping aux context command streams
- allow force-syncing of compile threads

Please review!

Thanks,
Nicolai
--
 .../auxiliary/driver_ddebug/dd_draw.c| 165 ++---
 .../auxiliary/driver_ddebug/dd_pipe.h|   6 +
 .../auxiliary/driver_ddebug/dd_util.h|  66 +--
 src/gallium/auxiliary/util/u_log.c   |   4 +
 .../drivers/radeonsi/driinfo_radeonsi.h  |  12 +-
 src/gallium/drivers/radeonsi/si_clear.c  |   2 +-
 src/gallium/drivers/radeonsi/si_debug.c  |  17 ++
 .../drivers/radeonsi/si_debug_options.inc|   6 +
 src/gallium/drivers/radeonsi/si_get.c|   6 +-
 src/gallium/drivers/radeonsi/si_pipe.c   |  36 +++-
 src/gallium/drivers/radeonsi/si_pipe.h   |   7 +-
 .../drivers/radeonsi/si_state_shaders.c  |  13 +-
 src/util/merge_driinfo.py|  58 +-
 src/util/xmlpool/t_options.h |   9 -
 14 files changed, 288 insertions(+), 119 deletions(-)


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

[Mesa-dev] [PATCH 8/8] radeonsi: add radeonsi_sync_compile option

[Nicolai Hähnle]

From: Nicolai Hähnle 

Force the driver thread to sync immediately with a compiler thread (but
compilation still happens in a separate thread).

This can be useful to simplify debugging compiler issues.
---
 src/gallium/drivers/radeonsi/si_debug_options.inc |  1 +
 src/gallium/drivers/radeonsi/si_state_shaders.c   | 13 ++---
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug_options.inc 
b/src/gallium/drivers/radeonsi/si_debug_options.inc
index f4c3e19ed95..019256ca1d1 100644
--- a/src/gallium/drivers/radeonsi/si_debug_options.inc
+++ b/src/gallium/drivers/radeonsi/si_debug_options.inc
@@ -1,5 +1,6 @@
 OPT_BOOL(clear_db_cache_before_clear, false, "Clear DB cache before fast depth 
clear")
 OPT_BOOL(enable_nir, false, "Enable NIR")
 OPT_BOOL(aux_debug, false, "Generate ddebug_dumps for the auxiliary context")
+OPT_BOOL(sync_compile, false, "Always compile synchronously (will cause 
stalls)")
 
 #undef OPT_BOOL
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 5bdfd4f6ac1..f57e7730905 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1945,20 +1945,24 @@ current_not_ready:
sel->first_variant = shader;
sel->last_variant = shader;
} else {
sel->last_variant->next_variant = shader;
sel->last_variant = shader;
}
 
/* Use the default (unoptimized) shader for now. */
memset(&key->opt, 0, sizeof(key->opt));
mtx_unlock(&sel->mutex);
+
+   if (sscreen->options.sync_compile)
+   util_queue_fence_wait(&shader->ready);
+
goto again;
}
 
/* Reset the fence before adding to the variant list. */
util_queue_fence_reset(&shader->ready);
 
if (!sel->last_variant) {
sel->first_variant = shader;
sel->last_variant = shader;
} else {
@@ -2157,38 +2161,41 @@ static void si_init_shader_selector_async(void *job, 
int thread_index)
 }
 
 void si_schedule_initial_compile(struct si_context *sctx, unsigned processor,
 struct util_queue_fence *ready_fence,
 struct si_compiler_ctx_state 
*compiler_ctx_state,
 void *job, util_queue_execute_func execute)
 {
util_queue_fence_init(ready_fence);
 
struct util_async_debug_callback async_debug;
-   bool wait =
+   bool debug =
(sctx->debug.debug_message && !sctx->debug.async) ||
sctx->is_debug ||
si_can_dump_shader(sctx->screen, processor);
 
-   if (wait) {
+   if (debug) {
u_async_debug_init(&async_debug);
compiler_ctx_state->debug = async_debug.base;
}
 
util_queue_add_job(&sctx->screen->shader_compiler_queue, job,
   ready_fence, execute, NULL);
 
-   if (wait) {
+   if (debug) {
util_queue_fence_wait(ready_fence);
u_async_debug_drain(&async_debug, &sctx->debug);
u_async_debug_cleanup(&async_debug);
}
+
+   if (sctx->screen->options.sync_compile)
+   util_queue_fence_wait(ready_fence);
 }
 
 /* Return descriptor slot usage masks from the given shader info. */
 void si_get_active_slot_masks(const struct tgsi_shader_info *info,
  uint32_t *const_and_shader_buffers,
  uint64_t *samplers_and_images)
 {
unsigned start, num_shaderbufs, num_constbufs, num_images, num_samplers;
 
num_shaderbufs = util_last_bit(info->shader_buffers_declared);
-- 
2.20.1

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

[Mesa-dev] [PATCH 5/8] ddebug: dump driver state into a separate file

[Nicolai Hähnle]

From: Nicolai Hähnle 

Due to asynchronous execution, it's not clear which of the draws the state
may refer to.

This also works around an issue encountered with radeonsi where dumping
the driver state itself caused a hang.
---
 src/gallium/auxiliary/driver_ddebug/dd_draw.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c 
b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
index bda1891c49b..98e7a6bb99f 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
@@ -981,36 +981,43 @@ dd_report_hang(struct dd_context *dctx)
 
   FILE *f = fopen(name, "w");
   if (!f) {
  fprintf(stderr, "fopen failed\n");
   } else {
  fprintf(stderr, "%s\n", name);
 
  dd_write_header(f, dscreen->screen, 
record->draw_state.base.apitrace_call_number);
  dd_write_record(f, record);
 
- if (!encountered_hang) {
-dd_dump_driver_state(dctx, f, PIPE_DUMP_DEVICE_STATUS_REGISTERS);
-dd_dump_dmesg(f);
- }
-
  fclose(f);
   }
 
   if (top_not_reached)
  stop_output = true;
   encountered_hang = true;
}
 
if (num_later)
   fprintf(stderr, "... and %u additional draws.\n", num_later);
 
+   char name[512];
+   dd_get_debug_filename_and_mkdir(name, sizeof(name), false);
+   FILE *f = fopen(name, "w");
+   if (!f) {
+  fprintf(stderr, "fopen failed\n");
+   } else {
+  dd_write_header(f, dscreen->screen, 0);
+  dd_dump_driver_state(dctx, f, PIPE_DUMP_DEVICE_STATUS_REGISTERS);
+  dd_dump_dmesg(f);
+  fclose(f);
+   }
+
fprintf(stderr, "\nDone.\n");
dd_kill_process();
 }
 
 int
 dd_thread_main(void *input)
 {
struct dd_context *dctx = (struct dd_context *)input;
struct dd_screen *dscreen = dd_screen(dctx->base.screen);
struct pipe_screen *screen = dscreen->screen;
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/8] ddebug: set thread name

[Nicolai Hähnle]

From: Nicolai Hähnle 

For better debuggability.
---
 src/gallium/auxiliary/driver_ddebug/dd_draw.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c 
b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
index f5b94356119..4eb0dd096f4 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
@@ -26,20 +26,21 @@
  **/
 
 #include "dd_pipe.h"
 
 #include "util/u_dump.h"
 #include "util/u_format.h"
 #include "util/u_framebuffer.h"
 #include "util/u_helpers.h"
 #include "util/u_inlines.h"
 #include "util/u_memory.h"
+#include "util/u_process.h"
 #include "tgsi/tgsi_parse.h"
 #include "tgsi/tgsi_scan.h"
 #include "util/os_time.h"
 #include 
 #include "pipe/p_config.h"
 
 
 static void
 dd_write_header(FILE *f, struct pipe_screen *screen, unsigned 
apitrace_call_number)
 {
@@ -995,20 +996,29 @@ dd_report_hang(struct dd_context *dctx)
dd_kill_process();
 }
 
 int
 dd_thread_main(void *input)
 {
struct dd_context *dctx = (struct dd_context *)input;
struct dd_screen *dscreen = dd_screen(dctx->base.screen);
struct pipe_screen *screen = dscreen->screen;
 
+   const char *process_name = util_get_process_name();
+   if (process_name) {
+  char threadname[16];
+  util_snprintf(threadname, sizeof(threadname), "%.*s:ddbg",
+(int)MIN2(strlen(process_name), sizeof(threadname) - 6),
+process_name);
+  u_thread_setname(threadname);
+   }
+
mtx_lock(&dctx->mutex);
 
for (;;) {
   struct list_head records;
   list_replace(&dctx->records, &records);
   list_inithead(&dctx->records);
   dctx->num_records = 0;
 
   if (dctx->api_stalled)
  cnd_signal(&dctx->cond);
-- 
2.20.1

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

[Mesa-dev] [PATCH 7/8] radeonsi: add radeonsi_aux_debug option for aux context debug dumps

[Nicolai Hähnle]

From: Nicolai Hähnle 

Enabling this option will create ddebug-style dumps for the aux context,
except that instead of intercepting the pipe_context layer
we just dump the IB contents on flush.
---
 src/gallium/drivers/radeonsi/si_debug.c | 17 +
 .../drivers/radeonsi/si_debug_options.inc   |  1 +
 src/gallium/drivers/radeonsi/si_pipe.c  | 14 +-
 3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_debug.c 
b/src/gallium/drivers/radeonsi/si_debug.c
index 07de96057dc..9a4494a98fe 100644
--- a/src/gallium/drivers/radeonsi/si_debug.c
+++ b/src/gallium/drivers/radeonsi/si_debug.c
@@ -475,20 +475,37 @@ void si_auto_log_cs(void *data, struct u_log_context *log)
struct si_context *ctx = (struct si_context *)data;
si_log_cs(ctx, log, false);
 }
 
 void si_log_hw_flush(struct si_context *sctx)
 {
if (!sctx->log)
return;
 
si_log_cs(sctx, sctx->log, true);
+
+   if (&sctx->b == sctx->screen->aux_context) {
+   /* The aux context isn't captured by the ddebug wrapper,
+* so we dump it on a flush-by-flush basis here.
+*/
+   FILE *f = dd_get_debug_file(false);
+   if (!f) {
+   fprintf(stderr, "radeonsi: error opening aux context 
dump file.\n");
+   } else {
+   dd_write_header(f, &sctx->screen->b, 0);
+
+   fprintf(f, "Aux context dump:\n\n");
+   u_log_new_page_print(sctx->log, f);
+
+   fclose(f);
+   }
+   }
 }
 
 static const char *priority_to_string(enum radeon_bo_priority priority)
 {
 #define ITEM(x) [RADEON_PRIO_##x] = #x
static const char *table[64] = {
ITEM(FENCE),
ITEM(TRACE),
ITEM(SO_FILLED_SIZE),
ITEM(QUERY),
diff --git a/src/gallium/drivers/radeonsi/si_debug_options.inc 
b/src/gallium/drivers/radeonsi/si_debug_options.inc
index 165dba8baf5..f4c3e19ed95 100644
--- a/src/gallium/drivers/radeonsi/si_debug_options.inc
+++ b/src/gallium/drivers/radeonsi/si_debug_options.inc
@@ -1,4 +1,5 @@
 OPT_BOOL(clear_db_cache_before_clear, false, "Clear DB cache before fast depth 
clear")
 OPT_BOOL(enable_nir, false, "Enable NIR")
+OPT_BOOL(aux_debug, false, "Generate ddebug_dumps for the auxiliary context")
 
 #undef OPT_BOOL
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9f8bd2039ee..10566a9b8d5 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -718,20 +718,26 @@ static void si_destroy_screen(struct pipe_screen* pscreen)
}
}
mtx_destroy(&sscreen->shader_parts_mutex);
si_destroy_shader_cache(sscreen);
 
si_destroy_perfcounters(sscreen);
si_gpu_load_kill_thread(sscreen);
 
mtx_destroy(&sscreen->gpu_load_mutex);
mtx_destroy(&sscreen->aux_context_lock);
+   struct u_log_context *aux_log = ((struct si_context 
*)sscreen->aux_context)->log;
+   if (aux_log) {
+   sscreen->aux_context->set_log_context(sscreen->aux_context, 
NULL);
+   u_log_context_destroy(aux_log);
+   FREE(aux_log);
+   }
sscreen->aux_context->destroy(sscreen->aux_context);
 
slab_destroy_parent(&sscreen->pool_transfers);
 
disk_cache_destroy(sscreen->disk_shader_cache);
sscreen->ws->destroy(sscreen->ws);
FREE(sscreen);
 }
 
 static void si_init_gs_info(struct si_screen *sscreen)
@@ -1176,21 +1182,27 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
sscreen->eqaa_force_color_samples = f;
}
}
 
for (i = 0; i < num_comp_hi_threads; i++)
si_init_compiler(sscreen, &sscreen->compiler[i]);
for (i = 0; i < num_comp_lo_threads; i++)
si_init_compiler(sscreen, &sscreen->compiler_lowp[i]);
 
/* Create the auxiliary context. This must be done last. */
-   sscreen->aux_context = si_create_context(&sscreen->b, 0);
+   sscreen->aux_context = si_create_context(
+   &sscreen->b, sscreen->options.aux_debug ? PIPE_CONTEXT_DEBUG : 
0);
+   if (sscreen->options.aux_debug) {
+   struct u_log_context *log = CALLOC_STRUCT(u_log_context);
+   u_log_context_init(log);
+   sscreen->aux_context->set_log_context(sscreen->aux_context, 
log);
+   }
 
if (sscreen->debug_flags & DBG(TEST_DMA))
si_test_dma(sscreen);
 
if (sscreen->debug_flags & DBG(TEST_DMA_PERF)) {
si_test_dma_perf(sscreen);
}
 
if (sscreen->debug_flags & (DBG(TEST_VMFAULT_CP) |
  DBG(TEST_VMFAULT_SDMA) |
-- 
2.20.1

___
mesa-dev mail

[Mesa-dev] [PATCH 6/8] ddebug: expose some helper functions as non-inline

[Nicolai Hähnle]

From: Nicolai Hähnle 

---
 src/gallium/auxiliary/driver_ddebug/dd_draw.c | 63 +-
 src/gallium/auxiliary/driver_ddebug/dd_util.h | 66 +++
 2 files changed, 70 insertions(+), 59 deletions(-)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c 
b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
index 98e7a6bb99f..eef44a7c348 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
@@ -33,22 +33,83 @@
 #include "util/u_helpers.h"
 #include "util/u_inlines.h"
 #include "util/u_memory.h"
 #include "util/u_process.h"
 #include "tgsi/tgsi_parse.h"
 #include "tgsi/tgsi_scan.h"
 #include "util/os_time.h"
 #include 
 #include "pipe/p_config.h"
 
+void
+dd_get_debug_filename_and_mkdir(char *buf, size_t buflen, bool verbose)
+{
+   static unsigned index;
+   char proc_name[128], dir[256];
 
-static void
+   if (!os_get_process_name(proc_name, sizeof(proc_name))) {
+  fprintf(stderr, "dd: can't get the process name\n");
+  strcpy(proc_name, "unknown");
+   }
+
+   util_snprintf(dir, sizeof(dir), "%s/"DD_DIR, debug_get_option("HOME", "."));
+
+   if (mkdir(dir, 0774) && errno != EEXIST)
+  fprintf(stderr, "dd: can't create a directory (%i)\n", errno);
+
+   util_snprintf(buf, buflen, "%s/%s_%u_%08u", dir, proc_name, getpid(),
+ p_atomic_inc_return(&index) - 1);
+
+   if (verbose)
+  fprintf(stderr, "dd: dumping to file %s\n", buf);
+}
+
+FILE *
+dd_get_debug_file(bool verbose)
+{
+   char name[512];
+   FILE *f;
+
+   dd_get_debug_filename_and_mkdir(name, sizeof(name), verbose);
+   f = fopen(name, "w");
+   if (!f) {
+  fprintf(stderr, "dd: can't open file %s\n", name);
+  return NULL;
+   }
+
+   return f;
+}
+
+void
+dd_parse_apitrace_marker(const char *string, int len, unsigned *call_number)
+{
+   unsigned num;
+   char *s;
+
+   if (len <= 0)
+  return;
+
+   /* Make it zero-terminated. */
+   s = alloca(len + 1);
+   memcpy(s, string, len);
+   s[len] = 0;
+
+   /* Parse the number. */
+   errno = 0;
+   num = strtol(s, NULL, 10);
+   if (errno)
+  return;
+
+   *call_number = num;
+}
+
+void
 dd_write_header(FILE *f, struct pipe_screen *screen, unsigned 
apitrace_call_number)
 {
char cmd_line[4096];
if (os_get_command_line(cmd_line, sizeof(cmd_line)))
   fprintf(f, "Command: %s\n", cmd_line);
fprintf(f, "Driver vendor: %s\n", screen->get_vendor(screen));
fprintf(f, "Device vendor: %s\n", screen->get_device_vendor(screen));
fprintf(f, "Device name: %s\n\n", screen->get_name(screen));
 
if (apitrace_call_number)
diff --git a/src/gallium/auxiliary/driver_ddebug/dd_util.h 
b/src/gallium/auxiliary/driver_ddebug/dd_util.h
index 20aca94cc67..d3a1a36af62 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_util.h
+++ b/src/gallium/auxiliary/driver_ddebug/dd_util.h
@@ -44,73 +44,23 @@
 #elif defined(PIPE_OS_WINDOWS)
 #include 
 #include 
 #define mkdir(dir, mode) _mkdir(dir)
 #endif
 
 
 /* name of the directory in home */
 #define DD_DIR "ddebug_dumps"
 
-static inline void
-dd_get_debug_filename_and_mkdir(char *buf, size_t buflen, bool verbose)
-{
-   static unsigned index;
-   char proc_name[128], dir[256];
+void
+dd_get_debug_filename_and_mkdir(char *buf, size_t buflen, bool verbose);
 
-   if (!os_get_process_name(proc_name, sizeof(proc_name))) {
-  fprintf(stderr, "dd: can't get the process name\n");
-  strcpy(proc_name, "unknown");
-   }
+FILE *
+dd_get_debug_file(bool verbose);
 
-   util_snprintf(dir, sizeof(dir), "%s/"DD_DIR, debug_get_option("HOME", "."));
+void
+dd_parse_apitrace_marker(const char *string, int len, unsigned *call_number);
 
-   if (mkdir(dir, 0774) && errno != EEXIST)
-  fprintf(stderr, "dd: can't create a directory (%i)\n", errno);
-
-   util_snprintf(buf, buflen, "%s/%s_%u_%08u", dir, proc_name, getpid(),
- p_atomic_inc_return(&index) - 1);
-
-   if (verbose)
-  fprintf(stderr, "dd: dumping to file %s\n", buf);
-}
-
-static inline FILE *
-dd_get_debug_file(bool verbose)
-{
-   char name[512];
-   FILE *f;
-
-   dd_get_debug_filename_and_mkdir(name, sizeof(name), verbose);
-   f = fopen(name, "w");
-   if (!f) {
-  fprintf(stderr, "dd: can't open file %s\n", name);
-  return NULL;
-   }
-
-   return f;
-}
-
-static inline void
-dd_parse_apitrace_marker(const char *string, int len, unsigned *call_number)
-{
-   unsigned num;
-   char *s;
-
-   if (len <= 0)
-  return;
-
-   /* Make it zero-terminated. */
-   s = alloca(len + 1);
-   memcpy(s, string, len);
-   s[len] = 0;
-
-   /* Parse the number. */
-   errno = 0;
-   num = strtol(s, NULL, 10);
-   if (errno)
-  return;
-
-   *call_number = num;
-}
+void
+dd_write_header(FILE *f, struct pipe_screen *screen, unsigned 
apitrace_call_number);
 
 #endif /* DD_UTIL_H */
-- 
2.20.1

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

[Mesa-dev] [PATCH] Revert "intel/compiler: split is_partial_write() into two variants"

[Juan A. Suarez Romero]

This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.

It is not clear that this commit was entirely correct, and unfortunately
it was pushed by error.

CC: Jason Ekstrand 
---

Jason, we agreed on leaving this out of the VK_KHR_shader_float16_int8
patchset, but due a mistake I've pushed it with the other patches.

So here is the revert.


 src/intel/compiler/brw_fs.cpp | 31 ---
 .../compiler/brw_fs_cmod_propagation.cpp  | 20 ++--
 .../compiler/brw_fs_copy_propagation.cpp  |  8 ++---
 src/intel/compiler/brw_fs_cse.cpp |  3 +-
 .../compiler/brw_fs_dead_code_eliminate.cpp   |  2 +-
 src/intel/compiler/brw_fs_live_variables.cpp  |  2 +-
 src/intel/compiler/brw_fs_reg_allocate.cpp|  2 +-
 .../compiler/brw_fs_register_coalesce.cpp |  2 +-
 .../compiler/brw_fs_saturate_propagation.cpp  |  7 ++---
 src/intel/compiler/brw_fs_sel_peephole.cpp|  4 +--
 src/intel/compiler/brw_ir_fs.h|  3 +-
 11 files changed, 30 insertions(+), 54 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 22eefd4ef49..335eaa0e934 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -734,33 +734,14 @@ fs_visitor::limit_dispatch_width(unsigned n, const char 
*msg)
  * it.
  */
 bool
-fs_inst::is_partial_reg_write() const
+fs_inst::is_partial_write() const
 {
return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
+   (this->exec_size * type_sz(this->dst.type)) < 32 ||
!this->dst.is_contiguous() ||
-   (this->exec_size * type_sz(this->dst.type)) < REG_SIZE ||
this->dst.offset % REG_SIZE != 0);
 }
 
-/**
- * Returns true if the instruction has a flag that means it won't
- * update an entire variable for the given dispatch width.
- *
- * This is only different from is_partial_reg_write() for SIMD8
- * dispatches of 16-bit (or smaller) instructions.
- */
-bool
-fs_inst::is_partial_var_write(uint32_t dispatch_width) const
-{
-   const uint32_t type_size = type_sz(this->dst.type);
-   uint32_t var_size = MIN2(REG_SIZE, dispatch_width * type_size);
-
-   return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
-   !this->dst.is_contiguous() ||
-   (this->exec_size * type_sz(this->dst.type)) < var_size ||
-   this->dst.offset % var_size != 0);
-}
-
 unsigned
 fs_inst::components_read(unsigned i) const
 {
@@ -2943,7 +2924,7 @@ fs_visitor::opt_register_renaming()
   if (depth == 0 &&
   inst->dst.file == VGRF &&
   alloc.sizes[inst->dst.nr] * REG_SIZE == inst->size_written &&
-  !inst->is_partial_reg_write()) {
+  !inst->is_partial_write()) {
  if (remap[dst] == ~0u) {
 remap[dst] = dst;
  } else {
@@ -3147,7 +3128,7 @@ fs_visitor::compute_to_mrf()
   next_ip++;
 
   if (inst->opcode != BRW_OPCODE_MOV ||
- inst->is_partial_reg_write() ||
+ inst->is_partial_write() ||
  inst->dst.file != MRF || inst->src[0].file != VGRF ||
  inst->dst.type != inst->src[0].type ||
  inst->src[0].abs || inst->src[0].negate ||
@@ -3180,7 +3161,7 @@ fs_visitor::compute_to_mrf()
 * that writes that reg, but it would require smarter
 * tracking.
 */
-   if (scan_inst->is_partial_reg_write())
+   if (scan_inst->is_partial_write())
   break;
 
 /* Handling things not fully contained in the source of the copy
@@ -3498,7 +3479,7 @@ fs_visitor::remove_duplicate_mrf_writes()
   if (inst->opcode == BRW_OPCODE_MOV &&
  inst->dst.file == MRF &&
  inst->src[0].file != ARF &&
- !inst->is_partial_reg_write()) {
+ !inst->is_partial_write()) {
  last_mrf_move[inst->dst.nr] = inst;
   }
}
diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp 
b/src/intel/compiler/brw_fs_cmod_propagation.cpp
index a2c11e0959c..c9725263929 100644
--- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
+++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
@@ -50,13 +50,13 @@
 
 static bool
 cmod_propagate_cmp_to_add(const gen_device_info *devinfo, bblock_t *block,
-  fs_inst *inst, unsigned dispatch_width)
+  fs_inst *inst)
 {
bool read_flag = false;
 
foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst, inst) {
   if (scan_inst->opcode == BRW_OPCODE_ADD &&
-  !scan_inst->is_partial_var_write(dispatch_width) &&
+  !scan_inst->is_partial_write() &&
   scan_inst->exec_size == inst->exec_size) {
  bool negate;
 
@@ -126,7 +126,7 @@ cmod_propagate_cmp_to_add(const gen_device_info *devinfo, 
bblock_t *block,
  */
 static bool
 cmod_propagate_not(const gen_device_info *devinfo, bblock_t *block,
-   fs_inst *inst, unsigned dispatch_width)
+   fs_inst *inst)
 {
const enum brw_conditional_mod cond = 
b

[Mesa-dev] [PATCH 4/8] ddebug: log calls to pipe->flush

[Nicolai Hähnle]

From: Nicolai Hähnle 

This can be useful when internal draws lead to a hang.
---
 src/gallium/auxiliary/driver_ddebug/dd_draw.c | 75 ++-
 src/gallium/auxiliary/driver_ddebug/dd_pipe.h |  6 ++
 2 files changed, 61 insertions(+), 20 deletions(-)

diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c 
b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
index 4eb0dd096f4..bda1891c49b 100644
--- a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
+++ b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
@@ -275,20 +275,27 @@ dd_dump_shader(struct dd_draw_state *dstate, enum 
pipe_shader_type sh, FILE *f)
for (i = 0; i < PIPE_MAX_SHADER_BUFFERS; i++)
   if (dstate->shader_buffers[sh][i].buffer) {
  DUMP_I(shader_buffer, &dstate->shader_buffers[sh][i], i);
  if (dstate->shader_buffers[sh][i].buffer)
 DUMP_M(resource, &dstate->shader_buffers[sh][i], buffer);
   }
 
fprintf(f, COLOR_SHADER "end shader: %s" COLOR_RESET "\n\n", 
shader_str[sh]);
 }
 
+static void
+dd_dump_flush(struct dd_draw_state *dstate, struct call_flush *info, FILE *f)
+{
+   fprintf(f, "%s:\n", __func__+8);
+   DUMP_M(hex, info, flags);
+}
+
 static void
 dd_dump_draw_vbo(struct dd_draw_state *dstate, struct pipe_draw_info *info, 
FILE *f)
 {
int sh, i;
 
DUMP(draw_info, info);
if (info->count_from_stream_output)
   DUMP_M(stream_output_target, info,
  count_from_stream_output);
if (info->indirect) {
@@ -550,20 +557,23 @@ dd_dump_driver_state(struct dd_context *dctx, FILE *f, 
unsigned flags)
 "***\n");
   fprintf(f, "Driver-specific state:\n\n");
   dctx->pipe->dump_debug_state(dctx->pipe, f, flags);
}
 }
 
 static void
 dd_dump_call(FILE *f, struct dd_draw_state *state, struct dd_call *call)
 {
switch (call->type) {
+   case CALL_FLUSH:
+  dd_dump_flush(state, &call->info.flush, f);
+  break;
case CALL_DRAW_VBO:
   dd_dump_draw_vbo(state, &call->info.draw_vbo.draw, f);
   break;
case CALL_LAUNCH_GRID:
   dd_dump_launch_grid(state, &call->info.launch_grid, f);
   break;
case CALL_RESOURCE_COPY_REGION:
   dd_dump_resource_copy_region(state,
&call->info.resource_copy_region, f);
   break;
@@ -621,20 +631,22 @@ dd_kill_process(void)
fprintf(stderr, "dd: Aborting the process...\n");
fflush(stdout);
fflush(stderr);
exit(1);
 }
 
 static void
 dd_unreference_copy_of_call(struct dd_call *dst)
 {
switch (dst->type) {
+   case CALL_FLUSH:
+  break;
case CALL_DRAW_VBO:
   
pipe_so_target_reference(&dst->info.draw_vbo.draw.count_from_stream_output, 
NULL);
   pipe_resource_reference(&dst->info.draw_vbo.indirect.buffer, NULL);
   
pipe_resource_reference(&dst->info.draw_vbo.indirect.indirect_draw_count, NULL);
   if (dst->info.draw_vbo.draw.index_size &&
   !dst->info.draw_vbo.draw.has_user_indices)
  pipe_resource_reference(&dst->info.draw_vbo.draw.index.resource, 
NULL);
   else
  dst->info.draw_vbo.draw.index.user = NULL;
   break;
@@ -1086,27 +1098,37 @@ dd_create_record(struct dd_context *dctx)
util_queue_fence_init(&record->driver_finished);
util_queue_fence_reset(&record->driver_finished);
 
dd_init_copy_of_draw_state(&record->draw_state);
dd_copy_draw_state(&record->draw_state.base, &dctx->draw_state);
 
return record;
 }
 
 static void
-dd_context_flush(struct pipe_context *_pipe,
- struct pipe_fence_handle **fence, unsigned flags)
+dd_add_record(struct dd_context *dctx, struct dd_draw_record *record)
 {
-   struct dd_context *dctx = dd_context(_pipe);
-   struct pipe_context *pipe = dctx->pipe;
+   mtx_lock(&dctx->mutex);
+   if (unlikely(dctx->num_records > 1)) {
+  dctx->api_stalled = true;
+  /* Since this is only a heuristic to prevent the API thread from getting
+   * too far ahead, we don't need a loop here. */
+  cnd_wait(&dctx->cond, &dctx->mutex);
+  dctx->api_stalled = false;
+   }
 
-   pipe->flush(pipe, fence, flags);
+   if (list_empty(&dctx->records))
+  cnd_signal(&dctx->cond);
+
+   list_addtail(&record->list, &dctx->records);
+   dctx->num_records++;
+   mtx_unlock(&dctx->mutex);
 }
 
 static void
 dd_before_draw(struct dd_context *dctx, struct dd_draw_record *record)
 {
struct dd_screen *dscreen = dd_screen(dctx->base.screen);
struct pipe_context *pipe = dctx->pipe;
struct pipe_screen *screen = dscreen->screen;
 
record->time_before = os_time_get_nano();
@@ -1118,35 +1140,21 @@ dd_before_draw(struct dd_context *dctx, struct 
dd_draw_record *record)
   } else {
  pipe->flush(pipe, &record->prev_bottom_of_pipe,
  PIPE_FLUSH_DEFERRED | PIPE_FLUSH_BOTTOM_OF_PIPE);
  pipe->flush(pipe, &record->top_of_pipe,
  PIPE_FLUSH_DEFERRED | PIPE_FLUSH_TOP_OF_PIPE);
   }
} else if (dscreen->flush_

[Mesa-dev] [PATCH] android: radv: fix necessary dependecies

[Mauro Rossi]

Fixes building errors due to missing libmesa_util generated files include
and libexpat dependencies:

In file included from external/mesa/src/amd/vulkan/radv_device.c:52:
external/mesa/src/util/xmlpool.h:115:10: fatal error: 'xmlpool/options.h' file 
not found
 ^~~
1 error generated.

FAILED: 
out/target/product/x86_64/obj_x86/SHARED_LIBRARIES/vulkan.radv_intermediates/LINKED/vulkan.radv.so
...
external/mesa/src/util/xmlconfig.c:670: error: undefined reference to 
'XML_ParserCreate'
...
clang.real: error: linker command failed with exit code 1 (use -v to see 
invocation)

Fixes: 3c2e826 ("radv: Add support for driconf.")
Signed-off-by: Mauro Rossi 
---
 src/amd/vulkan/Android.mk | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/Android.mk b/src/amd/vulkan/Android.mk
index 9574bf54e5..ab39ba3b72 100644
--- a/src/amd/vulkan/Android.mk
+++ b/src/amd/vulkan/Android.mk
@@ -71,7 +71,8 @@ LOCAL_C_INCLUDES := \
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_amd_common,,) 
\
$(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_nir,,)/nir \
$(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_radv_common,,) \
-   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util
+   $(call 
generated-sources-dir-for,STATIC_LIBRARIES,libmesa_vulkan_util,,)/util \
+   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_util,,)
 
 LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_vulkan_util \
@@ -165,5 +166,14 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
 
 LOCAL_SHARED_LIBRARIES += $(RADV_SHARED_LIBRARIES) libz libsync liblog
 
+# If Android version >=8 MESA should static link libexpat else should dynamic 
link
+ifeq ($(shell test $(PLATFORM_SDK_VERSION) -ge 27; echo $$?), 0)
+LOCAL_STATIC_LIBRARIES := \
+   libexpat
+else
+LOCAL_SHARED_LIBRARIES += \
+   libexpat
+endif
+
 include $(MESA_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
2.20.1

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

[Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Daniel Vetter]

Clear rules avoid arguing.

Note that this just aims to document current expectations. If that
shifts (e.g. because gl isn't the main api anymore, replaced by vk),
then we need to update this text.

I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to be a standard, and the list of userspace
projects we've accepted in the past is constantly shifting and
adjusting. So I figured I'll leave that as an exercise for later on.

v2: Try to clarify that we don't want a mesa driver just for mesa's
sake, and more clearly exclude anything that just doesn't make sense
technically.  Example would be a compute driver that makes sense to be
merged into drm (for kernel side code-sharing), but where the intended
use is some single-source CUDA-style compute without ever bothering
about any of the 3D/rendering side baggage that comes with gl/vk.

v3: Drop vulkan for now, the situation there isn't as obviously
clear-cut as on the gl side, and I don't want to tank this idea on a
hot discussion about vk and mesa. Plus I think once we have 1-2 more
vk drivers in mesa the situation on the vk side is clear-cut too, and
we can do a follow-up patch to add vk to the list where we expect the
userspace to be in upstream mesa. That's would give nice precedence to
make it clear that this isn't cast in stone, but meant to reflect
reality and should be adjusted as needed.

v4: Fix typo.

v5: Add a note to the commit message that this text needs to be
updated when the situation changes.

v6: Add a sentence why mesa will give the most meaningful review on gl
stuff - it's a very active project with lots of developers.

Acked-by: Dave Airlie  (v4)
Acked-by: Eric Anholt  (v4)
Acked-by: Alex Deucher  (v5)
Acked-by: Sean Paul  (v5)
Acked-by: Kenneth Graunke  (v5)
Acked-by: Karol Herbst  (v5)
Acked-by: Rob Clark 
Acked-by: Jérôme Glisse 
Acked-by: Bas Nieuwenhuizen 
Acked-by: Ben Skeggs 
Cc: Dave Airlie 
Cc: Eric Anholt 
Cc: Alex Deucher 
Cc: Sean Paul 
Cc: Kenneth Graunke 
Cc: Karol Herbst 
Cc: Rob Clark 
Cc: Jérôme Glisse 
Cc: Bas Nieuwenhuizen 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
I chatted with a pile of people in private, and there's clearly some
solid support for this. But there's also some big concerns brought up
by other people. The main one summed up is "what if everyone just
ships vk, with a generic gl-on-vk like ANGLE?", but there's other
concerns too.

So all together I think this doesn't clear the bar of (almost)
unanimous support which we need to make documentation actually help
with clarifying what's expected. And if/when someone comes up with a
more creative userspace approach for gl/vk we'll need to figure this
all out with the time honored tradition of having a few massive
threads on dri-devel :-)

Hence this is more fyi as a guidance I guess, not a strict&hard rule.
And I don't plan on merging this.

Cheers, Daniel
---
 Documentation/gpu/drm-uapi.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..0f767cfd5db6 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with 
multiple different uAPIs
 for the same thing co-existing. If we add a few more complete mistakes into the
 mix every year it would be entirely unmanageable.
 
+Below some clarifications what this means for specific areas in DRM.
+
+Compute&Rendering Userspace
+---
+
+Userspace API for enabling compute and rendering blocks which are capable of at
+least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
+be enabled in the upstream `Mesa3D project`.
+
+Mesa3D is the canonical upstream for these areas because it is a fully
+compliant, performant and cross-vendor implementation that supports all kernel
+drivers in DRM. It is also an active project with plenty of developers who
+can perform meaningful review. It is therefore the best platform to validate
+userspace API and especially make sure that cross-vendor interoperation is
+assured.
+
+Other userspace is only admissible if exposing a given feature through OpenGL 
or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage.
+
+Other areas, like media codec, which Mesa3D supports for just some drivers, but
+isn't the clear universal choice, are excluded from this policy. Driver teams
+are still encourage to aim for shared, cross-vendor infrastructure in userspace
+as much as possible.
+
 .. _drm_render_node:
 
 Render nodes
-- 
2.20.1

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

[Mesa-dev] [Bug 110356] install_megadrivers.py creates new dangling symlink [bisected]

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Engestrom  ---
Fixed by:

commit c77acc3ceba711ec3790fb674aeb8c6a25433741
Author: Eric Engestrom 
Date:   Tue Apr 9 09:28:17 2019 +0100

meson: remove meson-created megadrivers symlinks

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110356
Fixes: aa7afe324c2092fb31f9 "meson: strip rpath from megadrivers"
Signed-off-by: Eric Engestrom 
Tested-by: Mike Lothian 
Reviewed-by: Eric Anholt 

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

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Zhou, David(ChunMing)]

Will linux be only mesa-linux? I thought linux is an  open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
reject?
2. one hw feature that opengl/amdvlk developers work on that but no mesa 
developers work on, cannot upstream as well?

I think above two would easily happen, because there are many employees working 
on company project with many customer kinds of reqiurements, but mesa not.

-David

 Original Message 
Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
From: Daniel Vetter
To: DRI Development ,Mesa Dev
CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs 
,Daniel Vetter ,Sean Paul

Clear rules avoid arguing.

Note that this just aims to document current expectations. If that
shifts (e.g. because gl isn't the main api anymore, replaced by vk),
then we need to update this text.

I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to be a standard, and the list of userspace
projects we've accepted in the past is constantly shifting and
adjusting. So I figured I'll leave that as an exercise for later on.

v2: Try to clarify that we don't want a mesa driver just for mesa's
sake, and more clearly exclude anything that just doesn't make sense
technically.  Example would be a compute driver that makes sense to be
merged into drm (for kernel side code-sharing), but where the intended
use is some single-source CUDA-style compute without ever bothering
about any of the 3D/rendering side baggage that comes with gl/vk.

v3: Drop vulkan for now, the situation there isn't as obviously
clear-cut as on the gl side, and I don't want to tank this idea on a
hot discussion about vk and mesa. Plus I think once we have 1-2 more
vk drivers in mesa the situation on the vk side is clear-cut too, and
we can do a follow-up patch to add vk to the list where we expect the
userspace to be in upstream mesa. That's would give nice precedence to
make it clear that this isn't cast in stone, but meant to reflect
reality and should be adjusted as needed.

v4: Fix typo.

v5: Add a note to the commit message that this text needs to be
updated when the situation changes.

v6: Add a sentence why mesa will give the most meaningful review on gl
stuff - it's a very active project with lots of developers.

Acked-by: Dave Airlie  (v4)
Acked-by: Eric Anholt  (v4)
Acked-by: Alex Deucher  (v5)
Acked-by: Sean Paul  (v5)
Acked-by: Kenneth Graunke  (v5)
Acked-by: Karol Herbst  (v5)
Acked-by: Rob Clark 
Acked-by: Jérôme Glisse 
Acked-by: Bas Nieuwenhuizen 
Acked-by: Ben Skeggs 
Cc: Dave Airlie 
Cc: Eric Anholt 
Cc: Alex Deucher 
Cc: Sean Paul 
Cc: Kenneth Graunke 
Cc: Karol Herbst 
Cc: Rob Clark 
Cc: Jérôme Glisse 
Cc: Bas Nieuwenhuizen 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
I chatted with a pile of people in private, and there's clearly some
solid support for this. But there's also some big concerns brought up
by other people. The main one summed up is "what if everyone just
ships vk, with a generic gl-on-vk like ANGLE?", but there's other
concerns too.

So all together I think this doesn't clear the bar of (almost)
unanimous support which we need to make documentation actually help
with clarifying what's expected. And if/when someone comes up with a
more creative userspace approach for gl/vk we'll need to figure this
all out with the time honored tradition of having a few massive
threads on dri-devel :-)

Hence this is more fyi as a guidance I guess, not a strict&hard rule.
And I don't plan on merging this.

Cheers, Daniel
---
 Documentation/gpu/drm-uapi.rst | 25 +
 1 file changed, 25 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index c9fd23efd957..0f767cfd5db6 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with 
multiple different uAPIs
 for the same thing co-existing. If we add a few more complete mistakes into the
 mix every year it would be entirely unmanageable.

+Below some clarifications what this means for specific areas in DRM.
+
+Compute&Rendering Userspace
+---
+
+Userspace API for enabling compute and rendering blocks which are capable of at
+least supporting one of the OpenGL or OpenGL ES standards from Khronos need to
+be enabled in the upstream `Mesa3D project`.
+
+Mesa3D is the canonical upstream for these areas because it is a fully
+compliant, performant and cross-vendor implementation that supports all kernel
+drivers in DRM. It is also an active project with plenty of developers who
+can perform meaningful review. It is therefore the best platform to validate
+userspace API and especially make sure that cross-vendor interoperation is
+assured.
+
+Other userspace is only admissible if exposing a given

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Daniel Vetter]

On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
 wrote:
> Will linux be only mesa-linux? I thought linux is an  open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
> reject?
> 2. one hw feature that opengl/amdvlk developers work on that but no mesa 
> developers work on, cannot upstream as well?
>
> I think above two would easily happen, because there are many employees 
> working on company project with many customer kinds of reqiurements, but mesa 
> not.

Well those are the questions I tried to have a clear answer for, to
avoid confusion, but looks like the agreement isn't perfect. But
there's pretty clear favour towards cross vendor userspace that's
collaboratively and openly developed like mesa. So whenever one of the
above cases you bring up happen we'll get to have a big thread on
dri-devel I guess.
-Daniel


> -David
>
>  Original Message 
> Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
> From: Daniel Vetter
> To: DRI Development ,Mesa Dev
> CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs 
> ,Daniel Vetter ,Sean Paul
>
> Clear rules avoid arguing.
>
> Note that this just aims to document current expectations. If that
> shifts (e.g. because gl isn't the main api anymore, replaced by vk),
> then we need to update this text.
>
> I think it'd be good to have an equally solid list on the kms side.
> But kms is much more meant to be a standard, and the list of userspace
> projects we've accepted in the past is constantly shifting and
> adjusting. So I figured I'll leave that as an exercise for later on.
>
> v2: Try to clarify that we don't want a mesa driver just for mesa's
> sake, and more clearly exclude anything that just doesn't make sense
> technically.  Example would be a compute driver that makes sense to be
> merged into drm (for kernel side code-sharing), but where the intended
> use is some single-source CUDA-style compute without ever bothering
> about any of the 3D/rendering side baggage that comes with gl/vk.
>
> v3: Drop vulkan for now, the situation there isn't as obviously
> clear-cut as on the gl side, and I don't want to tank this idea on a
> hot discussion about vk and mesa. Plus I think once we have 1-2 more
> vk drivers in mesa the situation on the vk side is clear-cut too, and
> we can do a follow-up patch to add vk to the list where we expect the
> userspace to be in upstream mesa. That's would give nice precedence to
> make it clear that this isn't cast in stone, but meant to reflect
> reality and should be adjusted as needed.
>
> v4: Fix typo.
>
> v5: Add a note to the commit message that this text needs to be
> updated when the situation changes.
>
> v6: Add a sentence why mesa will give the most meaningful review on gl
> stuff - it's a very active project with lots of developers.
>
> Acked-by: Dave Airlie  (v4)
> Acked-by: Eric Anholt  (v4)
> Acked-by: Alex Deucher  (v5)
> Acked-by: Sean Paul  (v5)
> Acked-by: Kenneth Graunke  (v5)
> Acked-by: Karol Herbst  (v5)
> Acked-by: Rob Clark 
> Acked-by: Jérôme Glisse 
> Acked-by: Bas Nieuwenhuizen 
> Acked-by: Ben Skeggs 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Alex Deucher 
> Cc: Sean Paul 
> Cc: Kenneth Graunke 
> Cc: Karol Herbst 
> Cc: Rob Clark 
> Cc: Jérôme Glisse 
> Cc: Bas Nieuwenhuizen 
> Cc: Ben Skeggs 
> Signed-off-by: Daniel Vetter 
> ---
> I chatted with a pile of people in private, and there's clearly some
> solid support for this. But there's also some big concerns brought up
> by other people. The main one summed up is "what if everyone just
> ships vk, with a generic gl-on-vk like ANGLE?", but there's other
> concerns too.
>
> So all together I think this doesn't clear the bar of (almost)
> unanimous support which we need to make documentation actually help
> with clarifying what's expected. And if/when someone comes up with a
> more creative userspace approach for gl/vk we'll need to figure this
> all out with the time honored tradition of having a few massive
> threads on dri-devel :-)
>
> Hence this is more fyi as a guidance I guess, not a strict&hard rule.
> And I don't plan on merging this.
>
> Cheers, Daniel
> ---
>  Documentation/gpu/drm-uapi.rst | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index c9fd23efd957..0f767cfd5db6 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -105,6 +105,31 @@ is already rather painful for the DRM subsystem, with 
> multiple different uAPIs
>  for the same thing co-existing. If we add a few more complete mistakes into 
> the
>  mix every year it would be entirely unmanageable.
>
> +Below some clarifications what this means for specific areas in DRM.
> +
> +Compute&Rendering Userspace
> +---
> +
> +Userspace API for enabling compute and rend

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Daniel Vetter]

On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter  wrote:
>
> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
>  wrote:
> > Will linux be only mesa-linux? I thought linux is an  open linux.
> > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> > 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
> > reject?
> > 2. one hw feature that opengl/amdvlk developers work on that but no mesa 
> > developers work on, cannot upstream as well?
> >
> > I think above two would easily happen, because there are many employees 
> > working on company project with many customer kinds of reqiurements, but 
> > mesa not.
>
> Well those are the questions I tried to have a clear answer for, to
> avoid confusion, but looks like the agreement isn't perfect. But
> there's pretty clear favour towards cross vendor userspace that's
> collaboratively and openly developed like mesa. So whenever one of the
> above cases you bring up happen we'll get to have a big thread on
> dri-devel I guess.

Aside, I think there's a pretty huge difference between rocm and
amdvlk. rocm is developed openly and all that, the one nit there is is
that it's not cross vendor. But then, there is no other vendor really
(but amd still controls it all despite the usual "totally an open
standard" lipstick in the marketing material). amdvlk otoh is open
source in the narrowest legal sense only, and nothing else. And yes
intel has some equally bad projects on the openess metric too with
some of the more recent-ish changes in the userspace stack.
-Daniel

> -Daniel
>
>
> > -David
> >
> >  Original Message 
> > Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
> > From: Daniel Vetter
> > To: DRI Development ,Mesa Dev
> > CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs 
> > ,Daniel Vetter ,Sean Paul
> >
> > Clear rules avoid arguing.
> >
> > Note that this just aims to document current expectations. If that
> > shifts (e.g. because gl isn't the main api anymore, replaced by vk),
> > then we need to update this text.
> >
> > I think it'd be good to have an equally solid list on the kms side.
> > But kms is much more meant to be a standard, and the list of userspace
> > projects we've accepted in the past is constantly shifting and
> > adjusting. So I figured I'll leave that as an exercise for later on.
> >
> > v2: Try to clarify that we don't want a mesa driver just for mesa's
> > sake, and more clearly exclude anything that just doesn't make sense
> > technically.  Example would be a compute driver that makes sense to be
> > merged into drm (for kernel side code-sharing), but where the intended
> > use is some single-source CUDA-style compute without ever bothering
> > about any of the 3D/rendering side baggage that comes with gl/vk.
> >
> > v3: Drop vulkan for now, the situation there isn't as obviously
> > clear-cut as on the gl side, and I don't want to tank this idea on a
> > hot discussion about vk and mesa. Plus I think once we have 1-2 more
> > vk drivers in mesa the situation on the vk side is clear-cut too, and
> > we can do a follow-up patch to add vk to the list where we expect the
> > userspace to be in upstream mesa. That's would give nice precedence to
> > make it clear that this isn't cast in stone, but meant to reflect
> > reality and should be adjusted as needed.
> >
> > v4: Fix typo.
> >
> > v5: Add a note to the commit message that this text needs to be
> > updated when the situation changes.
> >
> > v6: Add a sentence why mesa will give the most meaningful review on gl
> > stuff - it's a very active project with lots of developers.
> >
> > Acked-by: Dave Airlie  (v4)
> > Acked-by: Eric Anholt  (v4)
> > Acked-by: Alex Deucher  (v5)
> > Acked-by: Sean Paul  (v5)
> > Acked-by: Kenneth Graunke  (v5)
> > Acked-by: Karol Herbst  (v5)
> > Acked-by: Rob Clark 
> > Acked-by: Jérôme Glisse 
> > Acked-by: Bas Nieuwenhuizen 
> > Acked-by: Ben Skeggs 
> > Cc: Dave Airlie 
> > Cc: Eric Anholt 
> > Cc: Alex Deucher 
> > Cc: Sean Paul 
> > Cc: Kenneth Graunke 
> > Cc: Karol Herbst 
> > Cc: Rob Clark 
> > Cc: Jérôme Glisse 
> > Cc: Bas Nieuwenhuizen 
> > Cc: Ben Skeggs 
> > Signed-off-by: Daniel Vetter 
> > ---
> > I chatted with a pile of people in private, and there's clearly some
> > solid support for this. But there's also some big concerns brought up
> > by other people. The main one summed up is "what if everyone just
> > ships vk, with a generic gl-on-vk like ANGLE?", but there's other
> > concerns too.
> >
> > So all together I think this doesn't clear the bar of (almost)
> > unanimous support which we need to make documentation actually help
> > with clarifying what's expected. And if/when someone comes up with a
> > more creative userspace approach for gl/vk we'll need to figure this
> > all out with the time honored tradition of having a few massive
> > threads on dri-devel :-)
> >
> > Hence this is more fyi as a guidance I guess, not a strict&hard ru

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Chunming Zhou]

在 2019/4/24 22:36, Daniel Vetter 写道:
> On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter  wrote:
>> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
>>  wrote:
>>> Will linux be only mesa-linux? I thought linux is an  open linux.
>>> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
>>> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
>>> reject?
>>> 2. one hw feature that opengl/amdvlk developers work on that but no mesa 
>>> developers work on, cannot upstream as well?
>>>
>>> I think above two would easily happen, because there are many employees 
>>> working on company project with many customer kinds of reqiurements, but 
>>> mesa not.
>> Well those are the questions I tried to have a clear answer for, to
>> avoid confusion, but looks like the agreement isn't perfect. But
>> there's pretty clear favour towards cross vendor userspace that's
>> collaboratively and openly developed like mesa. So whenever one of the
>> above cases you bring up happen we'll get to have a big thread on
>> dri-devel I guess.
> Aside, I think there's a pretty huge difference between rocm and
> amdvlk. rocm is developed openly and all that, the one nit there is is
> that it's not cross vendor. But then, there is no other vendor really
> (but amd still controls it all despite the usual "totally an open
> standard" lipstick in the marketing material). amdvlk otoh is open
> source in the narrowest legal sense only, and nothing else.

Do you mean if amdvlk is developed openly like Rocm does, amdvlk will be 
able to drive uapi without mesa admissable?


-David

>   And yes
> intel has some equally bad projects on the openess metric too with
> some of the more recent-ish changes in the userspace stack.
> -Daniel
>
>> -Daniel
>>
>>
>>> -David
>>>
>>>  Original Message 
>>> Subject: [PATCH] gpu/docs: Clarify what userspace means for gl
>>> From: Daniel Vetter
>>> To: DRI Development ,Mesa Dev
>>> CC: Jérôme Glisse ,Daniel Vetter ,Karol Herbst ,Kenneth Graunke ,Ben Skeggs 
>>> ,Daniel Vetter ,Sean Paul
>>>
>>> Clear rules avoid arguing.
>>>
>>> Note that this just aims to document current expectations. If that
>>> shifts (e.g. because gl isn't the main api anymore, replaced by vk),
>>> then we need to update this text.
>>>
>>> I think it'd be good to have an equally solid list on the kms side.
>>> But kms is much more meant to be a standard, and the list of userspace
>>> projects we've accepted in the past is constantly shifting and
>>> adjusting. So I figured I'll leave that as an exercise for later on.
>>>
>>> v2: Try to clarify that we don't want a mesa driver just for mesa's
>>> sake, and more clearly exclude anything that just doesn't make sense
>>> technically.  Example would be a compute driver that makes sense to be
>>> merged into drm (for kernel side code-sharing), but where the intended
>>> use is some single-source CUDA-style compute without ever bothering
>>> about any of the 3D/rendering side baggage that comes with gl/vk.
>>>
>>> v3: Drop vulkan for now, the situation there isn't as obviously
>>> clear-cut as on the gl side, and I don't want to tank this idea on a
>>> hot discussion about vk and mesa. Plus I think once we have 1-2 more
>>> vk drivers in mesa the situation on the vk side is clear-cut too, and
>>> we can do a follow-up patch to add vk to the list where we expect the
>>> userspace to be in upstream mesa. That's would give nice precedence to
>>> make it clear that this isn't cast in stone, but meant to reflect
>>> reality and should be adjusted as needed.
>>>
>>> v4: Fix typo.
>>>
>>> v5: Add a note to the commit message that this text needs to be
>>> updated when the situation changes.
>>>
>>> v6: Add a sentence why mesa will give the most meaningful review on gl
>>> stuff - it's a very active project with lots of developers.
>>>
>>> Acked-by: Dave Airlie  (v4)
>>> Acked-by: Eric Anholt  (v4)
>>> Acked-by: Alex Deucher  (v5)
>>> Acked-by: Sean Paul  (v5)
>>> Acked-by: Kenneth Graunke  (v5)
>>> Acked-by: Karol Herbst  (v5)
>>> Acked-by: Rob Clark 
>>> Acked-by: Jérôme Glisse 
>>> Acked-by: Bas Nieuwenhuizen 
>>> Acked-by: Ben Skeggs 
>>> Cc: Dave Airlie 
>>> Cc: Eric Anholt 
>>> Cc: Alex Deucher 
>>> Cc: Sean Paul 
>>> Cc: Kenneth Graunke 
>>> Cc: Karol Herbst 
>>> Cc: Rob Clark 
>>> Cc: Jérôme Glisse 
>>> Cc: Bas Nieuwenhuizen 
>>> Cc: Ben Skeggs 
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>> I chatted with a pile of people in private, and there's clearly some
>>> solid support for this. But there's also some big concerns brought up
>>> by other people. The main one summed up is "what if everyone just
>>> ships vk, with a generic gl-on-vk like ANGLE?", but there's other
>>> concerns too.
>>>
>>> So all together I think this doesn't clear the bar of (almost)
>>> unanimous support which we need to make documentation actually help
>>> with clarifying what's expected. And if/when someone comes up with a
>>> more creative userspace approach for gl/vk

Re: [Mesa-dev] [PATCH 1/1] radv: consider MESA_VK_VERSION_OVERRIDE when setting the api version

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 4/24/19 2:54 PM, Bas Nieuwenhuizen wrote:

Reviewed-by: Bas Nieuwenhuizen 

On Wed, Apr 24, 2019 at 2:40 PM Eleni Maria Stea  wrote:

Before setting the physical device API version, we should check if the
MESA_VK_VERSION_OVERRIDE environment variable is set and take it into
account.
---
  src/amd/vulkan/radv_extensions.py | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 9743ce1a774..8f29f4ca40f 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -333,9 +333,13 @@ VkResult radv_EnumerateInstanceVersion(
  uint32_t
  radv_physical_device_api_version(struct radv_physical_device *dev)
  {
+uint32_t override = vk_get_version_override();
+uint32_t version = VK_MAKE_VERSION(1, 0, 68);
+
  if (!ANDROID && dev->rad_info.has_syncobj_wait_for_submit)
-return ${MAX_API_VERSION.c_vk_version()};
-return VK_MAKE_VERSION(1, 0, 68);
+version = ${MAX_API_VERSION.c_vk_version()};
+
+return override ? MIN2(override, version) : version;
  }
  """)

--
2.20.1

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

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

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

Re: [Mesa-dev] [PATCH] radeonsi: use CP DMA for the null const buffer clear on CIK

[Dylan Baker]

Thanks guys, I've replaced my attempt with Marek's for the release.

Dylan

Quoting Marek Olšák (2019-04-23 13:16:15)
> No, the correct backport is attached.
> 
> Marek
> 
> On Tue, Apr 23, 2019 at 2:51 PM Dylan Baker  wrote:
> 
> Hi Marek and Samuel,
> 
> I've staged this for 19.0, but I had to fix some very minor rebase
> conflicts.
> I'm getting ready to make a release, could one of you take a peak at the
> tip of
> the staging/19.0 branch and let me know if what I did looks okay?
> 
> Thanks,
> Dylan
> 
> Quoting Samuel Pitoiset (2019-04-16 08:24:01)
> > I don't have much context for that issue, so:
> >
> > Acked-by: Samuel Pitoiset 
> >
> > On 4/12/19 10:15 PM, Marek Ol\u0161 k wrote:
> >
> >     Done locally.
> >
> >     Marek
> >
> >     On Fri, Apr 12, 2019 at 12:20 PM Samuel Pitoiset <
> samuel.pitoi...@gmail.com
> >     > wrote:
> >
> >         I would suggest to document that workaround somewhere in the
> code.
> >
> >         On 4/12/19 5:17 PM, Marek Ol\u0161 k wrote:
> >         > From: Marek Ol\u0161 k 
> >         >
> >         > This is a workaround for a thread deadlock that I have no idea
> >         > why it occurs.
> >         >
> >         > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108879
> >         > Fixes: 9b331e462e5021d994859756d46cd2519d9c9c6e
> >         > ---
> >         >   src/gallium/drivers/radeonsi/si_clear.c        | 6 +++---
> >         >   src/gallium/drivers/radeonsi/si_compute_blit.c | 8 +---
> >         >   src/gallium/drivers/radeonsi/si_pipe.c         | 2 +-
> >         >   src/gallium/drivers/radeonsi/si_pipe.h         | 3 ++-
> >         >   src/gallium/drivers/radeonsi/si_test_dma.c     | 2 +-
> >         >   5 files changed, 12 insertions(+), 9 deletions(-)
> >         >
> >         > diff --git a/src/gallium/drivers/radeonsi/si_clear.c b/src/
> gallium/
> >         drivers/radeonsi/si_clear.c
> >         > index e1805f2a1c9..ead680b857b 100644
> >         > --- a/src/gallium/drivers/radeonsi/si_clear.c
> >         > +++ b/src/gallium/drivers/radeonsi/si_clear.c
> >         > @@ -256,21 +256,21 @@ void vi_dcc_clear_level(struct 
> si_context
> >         *sctx,
> >         >                * would be more efficient than separate
> per-layer
> >         clear operations.
> >         >                */
> >         >               assert(tex->buffer.b.b.nr_storage_samples <= 2 
> ||
> >         num_layers == 1);
> >         >   
> >         >               dcc_offset += tex->surface.u.legacy.level
> >         [level].dcc_offset;
> >         >               clear_size = tex->surface.u.legacy.level
> >         [level].dcc_fast_clear_size *
> >         >                            num_layers;
> >         >       }
> >         >   
> >         >       si_clear_buffer(sctx, dcc_buffer, dcc_offset, 
> clear_size,
> >         > -                     &clear_value, 4, SI_COHERENCY_CB_META);
> >         > +                     &clear_value, 4, SI_COHERENCY_CB_META,
> false);
> >         >   }
> >         >   
> >         >   /* Set the same micro tile mode as the destination of the
> last MSAA
> >         resolve.
> >         >    * This allows hitting the MSAA resolve fast path, which
> requires
> >         that both
> >         >    * src and dst micro tile modes match.
> >         >    */
> >         >   static void si_set_optimal_micro_tile_mode(struct si_screen
> >         *sscreen,
> >         >                                          struct si_texture
> *tex)
> >         >   {
> >         >       if (tex->buffer.b.is_shared ||
> >         > @@ -489,21 +489,21 @@ static void 
> si_do_fast_color_clear(struct
> >         si_context *sctx,
> >         >   
> >         >                       /* DCC fast clear with MSAA should clear
> CMASK
> >         to 0xC. */
> >         >                       if (tex->buffer.b.b.nr_samples >= 2 &&
> tex->
> >         cmask_buffer) {
> >         >                               /* TODO: This doesn't work with
> MSAA. *
> >         /
> >         >                               if (eliminate_needed)
> >         >                                       continue;
> >         >   
> >         >                               uint32_t clear_value =
> 0x;
> >         >                               si_clear_buffer(sctx, &tex->
> >         cmask_buffer->b.b,
> >         >                                               tex->
> cmask_offset,
> >         tex->surface.cmask_size,
> >         > -                                             &clear_value, 4,
> >         SI_COHERENCY_CB_META);
> > 

Re: [Mesa-dev] Mesa (master): radeonsi: delay adding BOs at the beginning of IBs until the first draw

[Michel Dänzer]

On 2019-04-23 5:39 p.m., GitLab Mirror wrote:
> Module: Mesa
> Branch: master
> Commit: 951d60f8cdc886adff09201ff65002e3ee1a4c61
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=951d60f8cdc886adff09201ff65002e3ee1a4c61
> 
> Author: Marek Olšák 
> Date:   Wed Feb 27 21:13:15 2019 -0500
> 
> radeonsi: delay adding BOs at the beginning of IBs until the first draw
> 
> so that bound compute shader resources won't be added when they are not
> needed and same for graphics.
> 
> Acked-by: Nicolai Hähnle 

This broke a bunch of piglit tests for me with Bonaire (using the amdgpu
kernel driver), e.g. shaders@glsl-max-varyings:

Vertical axis: Increasing numbers of varyings.
Horizontal axis: Which of the varyings contains the color.
GL_MAX_VARYING_FLOATS = 128
Probe color at (2,2)
  Expected: 0 255 0
  Observed: 0 0 0
  Failure with 1 vec4 varyings used in varying index 0


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

Re: [Mesa-dev] [PATCH v2] st: require compatible driver in autotools

[Emil Velikov]

On Wed, 24 Apr 2019 at 13:09, Emil Velikov  wrote:
>
> On Tue, 23 Apr 2019 at 23:10, Alyssa Ross  wrote:
> >
> > > Off the top of my head - none of the VL code should be build when we
> > > have only a swrast driver.
> > > Can you try and kill that bug, or shall I?
> >
> > Isn't that what this patch does?
> >
> > If there's only swrast, this patch prevents enabling any of the state
> > trackers, so need_gallium_vl won't be set, and VL won't be built.
>
> How about instead of tracking each driver and combination do somethings like:
>
> if no_gallium_drivers or gallium_drivers=swrast; then
>  all_vl_state_trackers=off
>
Having a closer look such code exists already at [1]

if test -n "$with_gallium_drivers" -a "x$with_gallium_drivers" != xswrast; then
if test "x$enable_xvmc" = xauto -a "x$have_xvmc_platform" = xyes; then
PKG_CHECK_EXISTS([xvmc >= $XVMC_REQUIRED], [enable_xvmc=yes],
[enable_xvmc=no])
fi
...
fi

Thus auto-detection will disable xvmc and other VL state-trackers,
when no gallium drivers or swrast only is set.
Thus the NEED_GALLIUM_VL_WINSYS shortly afterwords is set to
no/disabled, and vl_winsys_dri.c et al is not build.

A random old checkout commit 7be26976b8e8bc34fa7d0014197ed2af488f
seems happy with the following:

mkdir aa; cd aa;
../autogen.sh  --enable-autotools \
 --with-platforms=x11 \
 --with-dri-drivers= \
 --with-gallium-drivers=swrast \
 --disable-glx \
 --disable-dri3 \
 --disable-gbm

Am I missing something?
-Emil

[1] 
https://cgit.freedesktop.org/mesa/mesa/tree/configure.ac?h=19.0&id=d41acb4c9e46306e3e9cebe9c23de77c6f26ff93#n2322
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glsl: fix and clean up NV_compute_shader_derivatives support

[Marek Olšák]

From: Marek Olšák 

---
 src/compiler/glsl/builtin_functions.cpp | 78 -
 1 file changed, 24 insertions(+), 54 deletions(-)

diff --git a/src/compiler/glsl/builtin_functions.cpp 
b/src/compiler/glsl/builtin_functions.cpp
index c8d9e1c9af3..b1ffafa1acf 100644
--- a/src/compiler/glsl/builtin_functions.cpp
+++ b/src/compiler/glsl/builtin_functions.cpp
@@ -125,23 +125,21 @@ gs_only(const _mesa_glsl_parse_state *state)
 static bool
 v110(const _mesa_glsl_parse_state *state)
 {
return !state->es_shader;
 }
 
 static bool
 v110_derivatives_only(const _mesa_glsl_parse_state *state)
 {
return !state->es_shader &&
-  (state->stage == MESA_SHADER_FRAGMENT ||
-   (state->stage == MESA_SHADER_COMPUTE &&
-state->NV_compute_shader_derivatives_enable));
+  derivatives_only(state);
 }
 
 static bool
 v120(const _mesa_glsl_parse_state *state)
 {
return state->is_version(120, 300);
 }
 
 static bool
 v130(const _mesa_glsl_parse_state *state)
@@ -158,38 +156,34 @@ v130_desktop(const _mesa_glsl_parse_state *state)
 static bool
 v460_desktop(const _mesa_glsl_parse_state *state)
 {
return state->is_version(460, 0);
 }
 
 static bool
 v130_derivatives_only(const _mesa_glsl_parse_state *state)
 {
return state->is_version(130, 300) &&
-  (state->stage == MESA_SHADER_FRAGMENT ||
-   (state->stage == MESA_SHADER_COMPUTE &&
-state->NV_compute_shader_derivatives_enable));
+  derivatives_only(state);
 }
 
 static bool
 v140_or_es3(const _mesa_glsl_parse_state *state)
 {
return state->is_version(140, 300);
 }
 
 static bool
 v400_derivatives_only(const _mesa_glsl_parse_state *state)
 {
return state->is_version(400, 0) &&
-  (state->stage == MESA_SHADER_FRAGMENT ||
-   (state->stage == MESA_SHADER_COMPUTE &&
-state->NV_compute_shader_derivatives_enable));
+  derivatives_only(state);
 }
 
 static bool
 texture_rectangle(const _mesa_glsl_parse_state *state)
 {
return state->ARB_texture_rectangle_enable;
 }
 
 static bool
 texture_external(const _mesa_glsl_parse_state *state)
@@ -333,23 +327,21 @@ static bool
 gpu_shader4_tbo_integer(const _mesa_glsl_parse_state *state)
 {
return gpu_shader4_tbo(state) &&
   state->ctx->Extensions.EXT_texture_integer;
 }
 
 static bool
 gpu_shader4_derivs_only(const _mesa_glsl_parse_state *state)
 {
return state->EXT_gpu_shader4_enable &&
-  (state->stage == MESA_SHADER_FRAGMENT ||
-   (state->stage == MESA_SHADER_COMPUTE &&
-state->NV_compute_shader_derivatives_enable));
+  derivatives_only(state);
 }
 
 static bool
 gpu_shader4_integer_derivs_only(const _mesa_glsl_parse_state *state)
 {
return gpu_shader4_derivs_only(state) &&
   state->ctx->Extensions.EXT_texture_integer;
 }
 
 static bool
@@ -435,37 +427,35 @@ fs_interpolate_at(const _mesa_glsl_parse_state *state)
 
 static bool
 texture_array_lod(const _mesa_glsl_parse_state *state)
 {
return lod_exists_in_stage(state) &&
   (state->EXT_texture_array_enable ||
(state->EXT_gpu_shader4_enable &&
 state->ctx->Extensions.EXT_texture_array));
 }
 
-static bool
-fs_texture_array(const _mesa_glsl_parse_state *state)
-{
-   return state->stage == MESA_SHADER_FRAGMENT &&
-  (state->EXT_texture_array_enable ||
-   (state->EXT_gpu_shader4_enable &&
-state->ctx->Extensions.EXT_texture_array));
-}
-
 static bool
 texture_array(const _mesa_glsl_parse_state *state)
 {
return state->EXT_texture_array_enable ||
   (state->EXT_gpu_shader4_enable &&
state->ctx->Extensions.EXT_texture_array);
 }
 
+static bool
+texture_array_derivs_only(const _mesa_glsl_parse_state *state)
+{
+   return derivatives_only(state) &&
+  texture_array(state);
+}
+
 static bool
 texture_multisample(const _mesa_glsl_parse_state *state)
 {
return state->is_version(150, 310) ||
   state->ARB_texture_multisample_enable;
 }
 
 static bool
 texture_multisample_array(const _mesa_glsl_parse_state *state)
 {
@@ -485,42 +475,40 @@ static bool
 texture_samples_identical_array(const _mesa_glsl_parse_state *state)
 {
return texture_multisample_array(state) &&
   state->EXT_shader_samples_identical_enable;
 }
 
 static bool
 derivatives_texture_cube_map_array(const _mesa_glsl_parse_state *state)
 {
return state->has_texture_cube_map_array() &&
-  (state->stage == MESA_SHADER_FRAGMENT ||
-   (state->stage == MESA_SHADER_COMPUTE &&
-state->NV_compute_shader_derivatives_enable));
+  derivatives_only(state);
 }
 
 static bool
 texture_cube_map_array(const _mesa_glsl_parse_state *state)
 {
return state->has_texture_cube_map_array();
 }
 
 static bool
 texture_query_levels(const _mesa_glsl_parse_state *state)
 {
return state->is_version(430, 0) ||
   state->ARB_texture_query_levels_enable;
 }
 
 static bool
 texture_que

[Mesa-dev] [ANNOUNCE] mesa 19.0.3

[Dylan Baker]

Hi everyone,

I'd like to announce the availability of mesa 19.0.3, the third bugfix release
of the 19.0 cycle. It's continued to be a quiet release with just 19 patches
(excluding release churn) since 19.0.2. No one sub componenet was touched too
much, but there are the normal suspects: virgl, glsl, nir, intel, radeonsi,
radv, ac, and gallivm all received a few patches.

Dylan

Shortlob:

Andres Gomez (1):
  glsl/linker: location aliasing requires types to have the same width

Bas Nieuwenhuizen (1):
  ac: Move has_local_buffers disable to radeonsi.

Chia-I Wu (1):
  virgl: fix fence fd version check

Danylo Piliaiev (1):
  intel/compiler: Do not reswizzle dst if instruction writes to flag 
register

Dylan Baker (2):
  Bump version for 19.0.3
  docs: add relnotes for 19.0.3

Eric Anholt (1):
  nir: Fix deref offset calculation for structs.

Eric Engestrom (1):
  meson: remove meson-created megadrivers symlinks

Jason Ekstrand (2):
  anv/pipeline: Fix MEDIA_VFE_STATE::PerThreadScratchSpace on gen7
  anv: Add a #define for the max binding table size

Juan A. Suarez Romero (1):
  meson: Add dependency on genxml to anvil genfiles

Kenneth Graunke (2):
  glsl: Set location on structure-split sampler uniform variables
  Revert "glsl: Set location on structure-split sampler uniform variables"

Lionel Landwerlin (2):
  anv: fix uninitialized pthread cond clock domain
  intel/devinfo: fix missing num_thread_per_eu on ICL

Lubomir Rintel (2):
  gallivm: guess CPU features also on ARM
  gallivm: disable NEON instructions if they are not supported

Marek Olšák (1):
  radeonsi: use CP DMA for the null const buffer clear on CIK

Rhys Perry (1):
  nir,ac/nir: fix cube_face_coord

Roland Scheidegger (1):
  gallivm: fix bogus assert in get_indirect_index

Samuel Pitoiset (2):
  ac/nir: only use the new raw/struct image atomic intrinsics with LLVM 9+
  radv: do not load vertex attributes that are not provided by the pipeline


git tag: mesa-19.0.3

https://mesa.freedesktop.org/archive/mesa-19.0.3.tar.gz
MD5:  7dc3a505f16615d137934501e6270e97  mesa-19.0.3.tar.gz
SHA1: f8452f4119beb37dcea2f6e5bd0bc95f02d99733  mesa-19.0.3.tar.gz
SHA256: 59543ec3c9f8c72990e77887f13d1678cb6739e5d5f56abc21ebf9e772389c5e  
mesa-19.0.3.tar.gz
SHA512: 
b115481cdf0fc85fae763f81c4c30e3250425d0e17f4a1a463ebee5cee5f334b84d1dfaff5db80d4a336536faa054d6175b9ad95c07a6a6bd8f13109c4be19d4
  mesa-19.0.3.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.3.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-19.0.3.tar.xz
MD5:  d03bf14e42c0e54ebae5730712ccc408  mesa-19.0.3.tar.xz
SHA1: e028365fb8c7ae73bb0f01807c9137ec856c8e52  mesa-19.0.3.tar.xz
SHA256: f027244e38dc309a4c12db45ef79be81ab62c797a50a88d566e4edb6159fc4d5  
mesa-19.0.3.tar.xz
SHA512: 
aa170577252aa4157e4bd49076bbf6207e4aada9fc9f23b255de332e816f9c63e5661f752f2f276dd43e232a8926866004e2a2ff9ad4b411330969c2a9a7ffa0
  mesa-19.0.3.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.3.tar.xz.sig



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

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[Eric Anholt]

"Zhou, David(ChunMing)"  writes:

> Will linux be only mesa-linux? I thought linux is an  open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
> reject?
> 2. one hw feature that opengl/amdvlk developers work on that but no mesa
> developers work on, cannot upstream as well?

I believe these questions are already covered by

"+Other userspace is only admissible if exposing a given feature through OpenGL
or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage."

If OpenGL needs the interface, then you need a Mesa implementation.
It's time for you to work with the community to build that or get it
built.  Or, in AMD's case, work with the Mesa developers that you
already employ.

If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
clear policy in place, and this patch doesn't change that.  I would
personally say that AMDVLK doesn't qualify given that as far as I know
there is not open review of proposed patches to the project as they're
being developed.


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

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

[AppVeyor]

Build mesa 10877 failed


Commit 69430d7e59 by Jiang, Sonny on 4/2/2019 5:44 PM:

va: use a compute shader for the blit\n\nSigned-off-by: Sonny Jiang \nSigned-off-by: Marek Olšák 


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH 1/3] radeonsi/gfx9: set that window_rectangles always roll the context

[Marek Olšák]

Ping

On Thu, Apr 18, 2019 at 5:46 PM Marek Olšák  wrote:

> From: Marek Olšák 
>
> Cc: 19.0 
> ---
>  src/gallium/drivers/radeonsi/si_state.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state.h
> b/src/gallium/drivers/radeonsi/si_state.h
> index 311e1a428ae..119558b8674 100644
> --- a/src/gallium/drivers/radeonsi/si_state.h
> +++ b/src/gallium/drivers/radeonsi/si_state.h
> @@ -217,21 +217,22 @@ static inline unsigned
> si_atoms_that_always_roll_context(void)
> return (SI_ATOM_BIT(streamout_begin) |
> SI_ATOM_BIT(streamout_enable) |
> SI_ATOM_BIT(framebuffer) |
> SI_ATOM_BIT(msaa_sample_locs) |
> SI_ATOM_BIT(sample_mask) |
> SI_ATOM_BIT(blend_color) |
> SI_ATOM_BIT(clip_state) |
> SI_ATOM_BIT(scissors) |
> SI_ATOM_BIT(viewports) |
> SI_ATOM_BIT(stencil_ref) |
> -   SI_ATOM_BIT(scratch_state));
> +   SI_ATOM_BIT(scratch_state) |
> +   SI_ATOM_BIT(window_rectangles));
>  }
>
>  struct si_shader_data {
> uint32_tsh_base[SI_NUM_SHADERS];
>  };
>
>  /* The list of registers whose emitted values are remembered by
> si_context. */
>  enum si_tracked_reg {
> SI_TRACKED_DB_RENDER_CONTROL, /* 2 consecutive registers */
> SI_TRACKED_DB_COUNT_CONTROL,
> --
> 2.17.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radeonsi: add BOs after need_cs_space

[Marek Olšák]

From: Marek Olšák 

need_cs_space may clear the buffer list.

Fixes: 951d60f8cdc88 "radeonsi: delay adding BOs at the beginning of IBs until 
the first draw"
---
 src/gallium/drivers/radeonsi/si_compute.c| 6 +++---
 src/gallium/drivers/radeonsi/si_state_draw.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
b/src/gallium/drivers/radeonsi/si_compute.c
index 2f444a3a1b8..541d7e6f118 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -878,40 +878,40 @@ static void si_launch_grid(
 
if (sctx->has_graphics) {
if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
si_update_fb_dirtiness_after_rendering(sctx);
sctx->last_num_draw_calls = sctx->num_draw_calls;
}
 
si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
}
 
-   if (sctx->bo_list_add_all_compute_resources)
-   si_compute_resources_add_all_to_bo_list(sctx);
-
/* Add buffer sizes for memory checking in need_cs_space. */
si_context_add_resource_size(sctx, &program->shader.bo->b.b);
/* TODO: add the scratch buffer */
 
if (info->indirect) {
si_context_add_resource_size(sctx, info->indirect);
 
/* Indirect buffers use TC L2 on GFX9, but not older hw. */
if (sctx->chip_class <= VI &&
si_resource(info->indirect)->TC_L2_dirty) {
sctx->flags |= SI_CONTEXT_WRITEBACK_GLOBAL_L2;
si_resource(info->indirect)->TC_L2_dirty = false;
}
}
 
si_need_gfx_cs_space(sctx);
 
+   if (sctx->bo_list_add_all_compute_resources)
+   si_compute_resources_add_all_to_bo_list(sctx);
+
if (!sctx->cs_shader_state.initialized)
si_initialize_compute(sctx);
 
if (sctx->flags)
si_emit_cache_flush(sctx);
 
if (!si_switch_compute_shader(sctx, program, &program->shader,
code_object, info->pc))
return;
 
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index d2c74152337..8e01e1b35e1 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -1287,23 +1287,20 @@ static void si_draw_vbo(struct pipe_context *ctx, const 
struct pipe_draw_info *i
sctx->last_dirty_tex_counter = dirty_tex_counter;
sctx->framebuffer.dirty_cbufs |=
((1 << sctx->framebuffer.state.nr_cbufs) - 1);
sctx->framebuffer.dirty_zsbuf = true;
si_mark_atom_dirty(sctx, &sctx->atoms.s.framebuffer);
si_update_all_texture_descriptors(sctx);
}
 
si_decompress_textures(sctx, u_bit_consecutive(0, 
SI_NUM_GRAPHICS_SHADERS));
 
-   if (sctx->bo_list_add_all_gfx_resources)
-   si_gfx_resources_add_all_to_bo_list(sctx);
-
/* Set the rasterization primitive type.
 *
 * This must be done after si_decompress_textures, which can call
 * draw_vbo recursively, and before si_update_shaders, which uses
 * current_rast_prim for this draw_vbo call. */
if (sctx->gs_shader.cso)
rast_prim = sctx->gs_shader.cso->gs_output_prim;
else if (sctx->tes_shader.cso) {
if 
(sctx->tes_shader.cso->info.properties[TGSI_PROPERTY_TES_POINT_MODE])
rast_prim = PIPE_PRIM_POINTS;
@@ -1431,20 +1428,23 @@ static void si_draw_vbo(struct pipe_context *ctx, const 
struct pipe_draw_info *i
if (indirect->indirect_draw_count &&

si_resource(indirect->indirect_draw_count)->TC_L2_dirty) {
sctx->flags |= SI_CONTEXT_WRITEBACK_GLOBAL_L2;

si_resource(indirect->indirect_draw_count)->TC_L2_dirty = false;
}
}
}
 
si_need_gfx_cs_space(sctx);
 
+   if (sctx->bo_list_add_all_gfx_resources)
+   si_gfx_resources_add_all_to_bo_list(sctx);
+
/* Since we've called si_context_add_resource_size for vertex buffers,
 * this must be called after si_need_cs_space, because we must let
 * need_cs_space flush before we add buffers to the buffer list.
 */
if (!si_upload_vertex_buffer_descriptors(sctx))
goto return_cleanup;
 
/* Vega10/Raven scissor bug workaround. When any context register is
 * written (i.e. the GPU rolls the context), PA_SC_VPORT_SCISSOR
 * registers must be written too.
-- 
2.17.1

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

Re: [Mesa-dev] Mesa (master): radeonsi: delay adding BOs at the beginning of IBs until the first draw

[Marek Olšák]

It should be fixed by the patch "radeonsi: add BOs after need_cs_space".

Marek

On Wed, Apr 24, 2019 at 12:17 PM Michel Dänzer  wrote:

> On 2019-04-23 5:39 p.m., GitLab Mirror wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 951d60f8cdc886adff09201ff65002e3ee1a4c61
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=951d60f8cdc886adff09201ff65002e3ee1a4c61
> >
> > Author: Marek Olšák 
> > Date:   Wed Feb 27 21:13:15 2019 -0500
> >
> > radeonsi: delay adding BOs at the beginning of IBs until the first draw
> >
> > so that bound compute shader resources won't be added when they are not
> > needed and same for graphics.
> >
> > Acked-by: Nicolai Hähnle 
>
> This broke a bunch of piglit tests for me with Bonaire (using the amdgpu
> kernel driver), e.g. shaders@glsl-max-varyings:
>
> Vertical axis: Increasing numbers of varyings.
> Horizontal axis: Which of the varyings contains the color.
> GL_MAX_VARYING_FLOATS = 128
> Probe color at (2,2)
>   Expected: 0 255 0
>   Observed: 0 0 0
>   Failure with 1 vec4 varyings used in varying index 0
>
>
> --
> Earthling Michel Dänzer   |  https://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[bugzilla-daemon]

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

--- Comment #17 from Jan Vesely  ---
(In reply to Timur Kristóf from comment #16)
> Can you guys try this branch?
> 
> https://gitlab.freedesktop.org/Venemo/mesa/commits/nir-lower-samplers
> 
> It seems to work for me at least on radeonsi, but I haven't been able to
> test it thoroughly yet.

Hi Timur,

thanks for working on this. Since autotools has been removed I'm not sure how
valid this bug is.
My guess is that the current behavior would be similar to #109659 (resulting
binaries have undefined symbols).
I'll try to take a look over the weekend to see if that's the case and if your
patch removes those undefined symbols.
Ideally, meson would use '-Wl,--no-undefined' by default to catch this kind of
errors.

-- 
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] [AppVeyor] mesa staging/19.0 #10882 completed

[AppVeyor]

Build mesa 10882 completed



Commit 08f3ce4c7d by Lionel Landwerlin on 4/12/2019 10:05 AM:

anv: leave the top 4Gb of the high heap VMA unused\n\nIn 628c9ca9089789 I forgot to apply the same -4Gb of the high address\nof the high heap VMA. This was previously computed in the\nHIGH_HEAP_MAX_ADDRESS.\n\nMany thanks to James for pointing this out.\n\nSigned-off-by: Lionel Landwerlin \nReported-by: Xiong, James \nFixes: 628c9ca9089789 ("anv: store heap address bounds when initializing physical device")\nReviewed-by: Jason Ekstrand \n(cherry picked from commit 9e7b0988d6e98690eb8902e477b51713a6ef9cae)


Configure your notification preferences

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

Re: [Mesa-dev] [PATCH] radeonsi: add BOs after need_cs_space

[Bas Nieuwenhuizen]

R-b

On Wed, Apr 24, 2019, 11:36 PM Marek Olšák  wrote:

> From: Marek Olšák 
>
> need_cs_space may clear the buffer list.
>
> Fixes: 951d60f8cdc88 "radeonsi: delay adding BOs at the beginning of IBs
> until the first draw"
> ---
>  src/gallium/drivers/radeonsi/si_compute.c| 6 +++---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 2f444a3a1b8..541d7e6f118 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -878,40 +878,40 @@ static void si_launch_grid(
>
> if (sctx->has_graphics) {
> if (sctx->last_num_draw_calls != sctx->num_draw_calls) {
> si_update_fb_dirtiness_after_rendering(sctx);
> sctx->last_num_draw_calls = sctx->num_draw_calls;
> }
>
> si_decompress_textures(sctx, 1 << PIPE_SHADER_COMPUTE);
> }
>
> -   if (sctx->bo_list_add_all_compute_resources)
> -   si_compute_resources_add_all_to_bo_list(sctx);
> -
> /* Add buffer sizes for memory checking in need_cs_space. */
> si_context_add_resource_size(sctx, &program->shader.bo->b.b);
> /* TODO: add the scratch buffer */
>
> if (info->indirect) {
> si_context_add_resource_size(sctx, info->indirect);
>
> /* Indirect buffers use TC L2 on GFX9, but not older hw. */
> if (sctx->chip_class <= VI &&
> si_resource(info->indirect)->TC_L2_dirty) {
> sctx->flags |= SI_CONTEXT_WRITEBACK_GLOBAL_L2;
> si_resource(info->indirect)->TC_L2_dirty = false;
> }
> }
>
> si_need_gfx_cs_space(sctx);
>
> +   if (sctx->bo_list_add_all_compute_resources)
> +   si_compute_resources_add_all_to_bo_list(sctx);
> +
> if (!sctx->cs_shader_state.initialized)
> si_initialize_compute(sctx);
>
> if (sctx->flags)
> si_emit_cache_flush(sctx);
>
> if (!si_switch_compute_shader(sctx, program, &program->shader,
> code_object, info->pc))
> return;
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index d2c74152337..8e01e1b35e1 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -1287,23 +1287,20 @@ static void si_draw_vbo(struct pipe_context *ctx,
> const struct pipe_draw_info *i
> sctx->last_dirty_tex_counter = dirty_tex_counter;
> sctx->framebuffer.dirty_cbufs |=
> ((1 << sctx->framebuffer.state.nr_cbufs) - 1);
> sctx->framebuffer.dirty_zsbuf = true;
> si_mark_atom_dirty(sctx, &sctx->atoms.s.framebuffer);
> si_update_all_texture_descriptors(sctx);
> }
>
> si_decompress_textures(sctx, u_bit_consecutive(0,
> SI_NUM_GRAPHICS_SHADERS));
>
> -   if (sctx->bo_list_add_all_gfx_resources)
> -   si_gfx_resources_add_all_to_bo_list(sctx);
> -
> /* Set the rasterization primitive type.
>  *
>  * This must be done after si_decompress_textures, which can call
>  * draw_vbo recursively, and before si_update_shaders, which uses
>  * current_rast_prim for this draw_vbo call. */
> if (sctx->gs_shader.cso)
> rast_prim = sctx->gs_shader.cso->gs_output_prim;
> else if (sctx->tes_shader.cso) {
> if
> (sctx->tes_shader.cso->info.properties[TGSI_PROPERTY_TES_POINT_MODE])
> rast_prim = PIPE_PRIM_POINTS;
> @@ -1431,20 +1428,23 @@ static void si_draw_vbo(struct pipe_context *ctx,
> const struct pipe_draw_info *i
> if (indirect->indirect_draw_count &&
>
> si_resource(indirect->indirect_draw_count)->TC_L2_dirty) {
> sctx->flags |=
> SI_CONTEXT_WRITEBACK_GLOBAL_L2;
>
> si_resource(indirect->indirect_draw_count)->TC_L2_dirty = false;
> }
> }
> }
>
> si_need_gfx_cs_space(sctx);
>
> +   if (sctx->bo_list_add_all_gfx_resources)
> +   si_gfx_resources_add_all_to_bo_list(sctx);
> +
> /* Since we've called si_context_add_resource_size for vertex
> buffers,
>  * this must be called after si_need_cs_space, because we must let
>  * need_cs_space flush before we add buffers to the buffer list.
>  */
> if (!si_upload_vertex_buffer_descriptors(sctx))
> goto return_cleanup;
>
> /* Vega10/Raven scissor bug workaround. When any context register
> is
>  * written (i.e. the GPU rolls the context), PA_SC_VPORT_S

Re: [Mesa-dev] [PATCH] Revert "intel/compiler: split is_partial_write() into two variants"

[Jason Ekstrand]

ACK

On Wed, Apr 24, 2019 at 8:15 AM Juan A. Suarez Romero 
wrote:

> This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.
>
> It is not clear that this commit was entirely correct, and unfortunately
> it was pushed by error.
>
> CC: Jason Ekstrand 
> ---
>
> Jason, we agreed on leaving this out of the VK_KHR_shader_float16_int8
> patchset, but due a mistake I've pushed it with the other patches.
>
> So here is the revert.
>
>
>  src/intel/compiler/brw_fs.cpp | 31 ---
>  .../compiler/brw_fs_cmod_propagation.cpp  | 20 ++--
>  .../compiler/brw_fs_copy_propagation.cpp  |  8 ++---
>  src/intel/compiler/brw_fs_cse.cpp |  3 +-
>  .../compiler/brw_fs_dead_code_eliminate.cpp   |  2 +-
>  src/intel/compiler/brw_fs_live_variables.cpp  |  2 +-
>  src/intel/compiler/brw_fs_reg_allocate.cpp|  2 +-
>  .../compiler/brw_fs_register_coalesce.cpp |  2 +-
>  .../compiler/brw_fs_saturate_propagation.cpp  |  7 ++---
>  src/intel/compiler/brw_fs_sel_peephole.cpp|  4 +--
>  src/intel/compiler/brw_ir_fs.h|  3 +-
>  11 files changed, 30 insertions(+), 54 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 22eefd4ef49..335eaa0e934 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -734,33 +734,14 @@ fs_visitor::limit_dispatch_width(unsigned n, const
> char *msg)
>   * it.
>   */
>  bool
> -fs_inst::is_partial_reg_write() const
> +fs_inst::is_partial_write() const
>  {
> return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
> +   (this->exec_size * type_sz(this->dst.type)) < 32 ||
> !this->dst.is_contiguous() ||
> -   (this->exec_size * type_sz(this->dst.type)) < REG_SIZE ||
> this->dst.offset % REG_SIZE != 0);
>  }
>
> -/**
> - * Returns true if the instruction has a flag that means it won't
> - * update an entire variable for the given dispatch width.
> - *
> - * This is only different from is_partial_reg_write() for SIMD8
> - * dispatches of 16-bit (or smaller) instructions.
> - */
> -bool
> -fs_inst::is_partial_var_write(uint32_t dispatch_width) const
> -{
> -   const uint32_t type_size = type_sz(this->dst.type);
> -   uint32_t var_size = MIN2(REG_SIZE, dispatch_width * type_size);
> -
> -   return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
> -   !this->dst.is_contiguous() ||
> -   (this->exec_size * type_sz(this->dst.type)) < var_size ||
> -   this->dst.offset % var_size != 0);
> -}
> -
>  unsigned
>  fs_inst::components_read(unsigned i) const
>  {
> @@ -2943,7 +2924,7 @@ fs_visitor::opt_register_renaming()
>if (depth == 0 &&
>inst->dst.file == VGRF &&
>alloc.sizes[inst->dst.nr] * REG_SIZE == inst->size_written &&
> -  !inst->is_partial_reg_write()) {
> +  !inst->is_partial_write()) {
>   if (remap[dst] == ~0u) {
>  remap[dst] = dst;
>   } else {
> @@ -3147,7 +3128,7 @@ fs_visitor::compute_to_mrf()
>next_ip++;
>
>if (inst->opcode != BRW_OPCODE_MOV ||
> - inst->is_partial_reg_write() ||
> + inst->is_partial_write() ||
>   inst->dst.file != MRF || inst->src[0].file != VGRF ||
>   inst->dst.type != inst->src[0].type ||
>   inst->src[0].abs || inst->src[0].negate ||
> @@ -3180,7 +3161,7 @@ fs_visitor::compute_to_mrf()
>  * that writes that reg, but it would require smarter
>  * tracking.
>  */
> -   if (scan_inst->is_partial_reg_write())
> +   if (scan_inst->is_partial_write())
>break;
>
>  /* Handling things not fully contained in the source of the
> copy
> @@ -3498,7 +3479,7 @@ fs_visitor::remove_duplicate_mrf_writes()
>if (inst->opcode == BRW_OPCODE_MOV &&
>   inst->dst.file == MRF &&
>   inst->src[0].file != ARF &&
> - !inst->is_partial_reg_write()) {
> + !inst->is_partial_write()) {
>   last_mrf_move[inst->dst.nr] = inst;
>}
> }
> diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
> b/src/intel/compiler/brw_fs_cmod_propagation.cpp
> index a2c11e0959c..c9725263929 100644
> --- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
> +++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
> @@ -50,13 +50,13 @@
>
>  static bool
>  cmod_propagate_cmp_to_add(const gen_device_info *devinfo, bblock_t *block,
> -  fs_inst *inst, unsigned dispatch_width)
> +  fs_inst *inst)
>  {
> bool read_flag = false;
>
> foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst, inst) {
>if (scan_inst->opcode == BRW_OPCODE_ADD &&
> -  !scan_inst->is_partial_var_write(dispatch_width) &&
> +  !scan_inst->is_partial_write() &&
>scan_inst->exec_size == inst->exec_size) {
>   bool negate;
>
> @@ -126,7 +126,7 @@ cmod

Re: [Mesa-dev] [PATCH] intel/compiler/fs/icl: Use dummy masked urb write for tess eval

[Kenneth Graunke]

On Wednesday, April 24, 2019 2:29:21 AM PDT Topi Pohjolainen wrote:
> One cannot write the URB arbitrarily and therefore the message
> has to be carefully constructed. The clever tricks originate
> from Kenneth and Jason, I'm just writing the patch.
> 
> Fixes GPU hangs on ICL with Vulkan CTS.
> 
> CC: Kenneth Graunke 
> CC: Jason Ekstrand 
> CC: Anuj Phogat 
> CC: Clayton Craft 
> Signed-off-by: Topi Pohjolainen 

Thanks Topi!

Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [PATCH] nir: fix nir_remove_unused_varyings()

[Timothy Arceri]

We were only setting the used mask for the first component of a
varying. Since the linking opts split vectors into scalars this
has mostly worked ok.

However this causes an issue where for example if we split a
struct on one side of the interface but not the other, then we
can possibly end up removing the first components on the side
that was split and then incorrectly remove the whole struct
on the other side of the varying.

With this change we simply mark all 4 components for each slot
used by a struct. We could possibly make this more fine gained
but that would require a more complex change.

This fixes a bug in Strange Brigade on RADV when tessellation
is enabled, all credit goes to Samuel Pitoiset for tracking down
the cause of the bug.

Fixes: f1eb5e639997 ("nir: add component level support to 
remove_unused_io_vars()")
---
 src/compiler/nir/nir_linking_helpers.c | 51 +-
 1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index f4494c78f98..ef0f94baf47 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -59,6 +59,15 @@ get_variable_io_mask(nir_variable *var, gl_shader_stage 
stage)
return ((1ull << slots) - 1) << location;
 }
 
+static uint8_t
+get_num_components(nir_variable *var)
+{
+   if (glsl_type_is_struct_or_ifc(glsl_without_array(var->type)))
+  return 4;
+
+   return glsl_get_vector_elements(glsl_without_array(var->type));
+}
+
 static void
 tcs_add_output_reads(nir_shader *shader, uint64_t *read, uint64_t 
*patches_read)
 {
@@ -80,12 +89,14 @@ tcs_add_output_reads(nir_shader *shader, uint64_t *read, 
uint64_t *patches_read)
continue;
 
 nir_variable *var = nir_deref_instr_get_variable(deref);
-if (var->data.patch) {
-   patches_read[var->data.location_frac] |=
-  get_variable_io_mask(var, shader->info.stage);
-} else {
-   read[var->data.location_frac] |=
-  get_variable_io_mask(var, shader->info.stage);
+for (unsigned i = 0; i < get_num_components(var); i++) {
+   if (var->data.patch) {
+  patches_read[var->data.location_frac + i] |=
+ get_variable_io_mask(var, shader->info.stage);
+   } else {
+  read[var->data.location_frac + i] |=
+ get_variable_io_mask(var, shader->info.stage);
+   }
 }
  }
   }
@@ -161,22 +172,26 @@ nir_remove_unused_varyings(nir_shader *producer, 
nir_shader *consumer)
uint64_t patches_read[4] = { 0 }, patches_written[4] = { 0 };
 
nir_foreach_variable(var, &producer->outputs) {
-  if (var->data.patch) {
- patches_written[var->data.location_frac] |=
-get_variable_io_mask(var, producer->info.stage);
-  } else {
- written[var->data.location_frac] |=
-get_variable_io_mask(var, producer->info.stage);
+  for (unsigned i = 0; i < get_num_components(var); i++) {
+ if (var->data.patch) {
+patches_written[var->data.location_frac + i] |=
+   get_variable_io_mask(var, producer->info.stage);
+ } else {
+written[var->data.location_frac + i] |=
+   get_variable_io_mask(var, producer->info.stage);
+ }
   }
}
 
nir_foreach_variable(var, &consumer->inputs) {
-  if (var->data.patch) {
- patches_read[var->data.location_frac] |=
-get_variable_io_mask(var, consumer->info.stage);
-  } else {
- read[var->data.location_frac] |=
-get_variable_io_mask(var, consumer->info.stage);
+  for (unsigned i = 0; i < get_num_components(var); i++) {
+ if (var->data.patch) {
+patches_read[var->data.location_frac + i] |=
+   get_variable_io_mask(var, consumer->info.stage);
+ } else {
+read[var->data.location_frac + i] |=
+   get_variable_io_mask(var, consumer->info.stage);
+ }
   }
}
 
-- 
2.20.1

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

[Mesa-dev] [Bug 110431] Please add support for GL_EXT_gpu_shader4 (including on non-core profiles)

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #3 from Timothy Arceri  ---
Should be fixed as of:

commit  e71936a731a93ddfb3325c41a5a9756175020ee9
author  Marek Olšák 

   st/mesa: expose EXT_gpu_shader4 if GLSL 1.40 is supported

   Tested-by: Dieter Nützel 
   Reviewed-by: Eric Anholt 

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

Re: [Mesa-dev] [PATCH 1/8] radeonsi: add si_debug_options for convenient adding/removing of options

[Marek Olšák]

On Wed, Apr 24, 2019 at 9:14 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> Move the definition of radeonsi_clear_db_cache_before_clear there,
> as well as radeonsi_enable_nir.
>
> This removes the AMD_DEBUG=nir option.
>
> We currently still have two places for options: the driconf machinery
> and AMD_DEBUG/R600_DEBUG. If we are to have a single place for options,
> then the driconf machinery should be preferred since it's more flexible.
>
> The only downside of the driconf machinery was that adding new options
> was quite inconvenient. With this change, a simple boolean option can
> be added with a single line of code, same as for AMD_DEBUG.
>
> One technical limitation of this particular implementation is that while
> almost all driconf features are available, the translation machinery
> doesn't
> pick up the description strings for options added in si_debvug_options. In
> practice, translations haven't been provided anyway, and this is intended
> for developer options, so I'm not too worried. It could always be added
> later if anybody really cares.
> ---
>  .../drivers/radeonsi/driinfo_radeonsi.h   | 12 +++-
>  src/gallium/drivers/radeonsi/si_clear.c   |  2 +-
>  .../drivers/radeonsi/si_debug_options.inc |  4 ++
>  src/gallium/drivers/radeonsi/si_get.c |  6 +-
>  src/gallium/drivers/radeonsi/si_pipe.c| 22 ---
>  src/gallium/drivers/radeonsi/si_pipe.h|  7 ++-
>  src/util/merge_driinfo.py | 58 +--
>  src/util/xmlpool/t_options.h  |  9 ---
>  8 files changed, 89 insertions(+), 31 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
> b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
> index edf8edba035..d92883b9c38 100644
> --- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
> +++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
> @@ -4,13 +4,21 @@ DRI_CONF_SECTION_QUALITY
>  DRI_CONF_SECTION_END
>
>  DRI_CONF_SECTION_PERFORMANCE
>  DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
>  DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
>  DRI_CONF_RADEONSI_COMMUTATIVE_BLEND_ADD("false")
>  DRI_CONF_RADEONSI_ZERO_ALL_VRAM_ALLOCS("false")
>  DRI_CONF_SECTION_END
>
>  DRI_CONF_SECTION_DEBUG
> -   DRI_CONF_RADEONSI_CLEAR_DB_CACHE_BEFORE_CLEAR("false")
> -   DRI_CONF_RADEONSI_ENABLE_NIR("false")
> +
> +//= BEGIN VERBATIM
> +#define OPT_BOOL(name, dflt, description) \
> +   DRI_CONF_OPT_BEGIN_B(radeonsi_##name, #dflt) \
> +   DRI_CONF_DESC(en, description) \
> +   DRI_CONF_OPT_END
> +
> +#include "radeonsi/si_debug_options.inc"
> +//= END VERBATIM
> +
>  DRI_CONF_SECTION_END
> diff --git a/src/gallium/drivers/radeonsi/si_clear.c
> b/src/gallium/drivers/radeonsi/si_clear.c
> index e1805f2a1c9..a4ebd5cf2a5 100644
> --- a/src/gallium/drivers/radeonsi/si_clear.c
> +++ b/src/gallium/drivers/radeonsi/si_clear.c
> @@ -631,21 +631,21 @@ static void si_clear(struct pipe_context *ctx,
> unsigned buffers,
>  * a coincidence and the root cause is elsewhere.
>  *
>  * The corruption can be fixed by putting the DB flush
> before
>  * or after the depth clear. (surprisingly)
>  *
>  * https://bugs.freedesktop.org/show_bug.cgi?id=102955
> (apitrace)
>  *
>  * This hack decreases back-to-back ClearDepth performance.
>  */
> if ((sctx->db_depth_clear || sctx->db_stencil_clear) &&
> -   sctx->screen->clear_db_cache_before_clear)
> +   sctx->screen->options.clear_db_cache_before_clear)
> sctx->flags |= SI_CONTEXT_FLUSH_AND_INV_DB;
> }
>
> si_blitter_begin(sctx, SI_CLEAR);
> util_blitter_clear(sctx->blitter, fb->width, fb->height,
>util_framebuffer_get_num_layers(fb),
>buffers, color, depth, stencil);
> si_blitter_end(sctx);
>
> if (sctx->db_depth_clear) {
> diff --git a/src/gallium/drivers/radeonsi/si_debug_options.inc
> b/src/gallium/drivers/radeonsi/si_debug_options.inc
> new file mode 100644
> index 000..165dba8baf5
> --- /dev/null
> +++ b/src/gallium/drivers/radeonsi/si_debug_options.inc
> @@ -0,0 +1,4 @@
> +OPT_BOOL(clear_db_cache_before_clear, false, "Clear DB cache before fast
> depth clear")
> +OPT_BOOL(enable_nir, false, "Enable NIR")
> +
> +#undef OPT_BOOL
> diff --git a/src/gallium/drivers/radeonsi/si_get.c
> b/src/gallium/drivers/radeonsi/si_get.c
> index 67fbc50998b..fda71da16e6 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -203,21 +203,21 @@ static int si_get_param(struct pipe_screen *pscreen,
> enum pipe_cap param)
> case PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_BUFFER_STRIDE_4BYTE_ALIGNED_ONLY:
> case PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE

Re: [Mesa-dev] [PATCH 8/8] radeonsi: add radeonsi_sync_compile option

[Marek Olšák]

For patches 2 - 8:

Reviewed-by: Marek Olšák 

Marek

On Wed, Apr 24, 2019 at 9:15 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> Force the driver thread to sync immediately with a compiler thread (but
> compilation still happens in a separate thread).
>
> This can be useful to simplify debugging compiler issues.
> ---
>  src/gallium/drivers/radeonsi/si_debug_options.inc |  1 +
>  src/gallium/drivers/radeonsi/si_state_shaders.c   | 13 ++---
>  2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_debug_options.inc
> b/src/gallium/drivers/radeonsi/si_debug_options.inc
> index f4c3e19ed95..019256ca1d1 100644
> --- a/src/gallium/drivers/radeonsi/si_debug_options.inc
> +++ b/src/gallium/drivers/radeonsi/si_debug_options.inc
> @@ -1,5 +1,6 @@
>  OPT_BOOL(clear_db_cache_before_clear, false, "Clear DB cache before fast
> depth clear")
>  OPT_BOOL(enable_nir, false, "Enable NIR")
>  OPT_BOOL(aux_debug, false, "Generate ddebug_dumps for the auxiliary
> context")
> +OPT_BOOL(sync_compile, false, "Always compile synchronously (will cause
> stalls)")
>
>  #undef OPT_BOOL
> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
> b/src/gallium/drivers/radeonsi/si_state_shaders.c
> index 5bdfd4f6ac1..f57e7730905 100644
> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c
> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
> @@ -1945,20 +1945,24 @@ current_not_ready:
> sel->first_variant = shader;
> sel->last_variant = shader;
> } else {
> sel->last_variant->next_variant = shader;
> sel->last_variant = shader;
> }
>
> /* Use the default (unoptimized) shader for now. */
> memset(&key->opt, 0, sizeof(key->opt));
> mtx_unlock(&sel->mutex);
> +
> +   if (sscreen->options.sync_compile)
> +   util_queue_fence_wait(&shader->ready);
> +
> goto again;
> }
>
> /* Reset the fence before adding to the variant list. */
> util_queue_fence_reset(&shader->ready);
>
> if (!sel->last_variant) {
> sel->first_variant = shader;
> sel->last_variant = shader;
> } else {
> @@ -2157,38 +2161,41 @@ static void si_init_shader_selector_async(void
> *job, int thread_index)
>  }
>
>  void si_schedule_initial_compile(struct si_context *sctx, unsigned
> processor,
>  struct util_queue_fence *ready_fence,
>  struct si_compiler_ctx_state
> *compiler_ctx_state,
>  void *job, util_queue_execute_func
> execute)
>  {
> util_queue_fence_init(ready_fence);
>
> struct util_async_debug_callback async_debug;
> -   bool wait =
> +   bool debug =
> (sctx->debug.debug_message && !sctx->debug.async) ||
> sctx->is_debug ||
> si_can_dump_shader(sctx->screen, processor);
>
> -   if (wait) {
> +   if (debug) {
> u_async_debug_init(&async_debug);
> compiler_ctx_state->debug = async_debug.base;
> }
>
> util_queue_add_job(&sctx->screen->shader_compiler_queue, job,
>ready_fence, execute, NULL);
>
> -   if (wait) {
> +   if (debug) {
> util_queue_fence_wait(ready_fence);
> u_async_debug_drain(&async_debug, &sctx->debug);
> u_async_debug_cleanup(&async_debug);
> }
> +
> +   if (sctx->screen->options.sync_compile)
> +   util_queue_fence_wait(ready_fence);
>  }
>
>  /* Return descriptor slot usage masks from the given shader info. */
>  void si_get_active_slot_masks(const struct tgsi_shader_info *info,
>   uint32_t *const_and_shader_buffers,
>   uint64_t *samplers_and_images)
>  {
> unsigned start, num_shaderbufs, num_constbufs, num_images,
> num_samplers;
>
> num_shaderbufs = util_last_bit(info->shader_buffers_declared);
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gpu/docs: Clarify what userspace means for gl

[zhoucm1]

On 2019年04月25日 03:22, Eric Anholt wrote:

"Zhou, David(ChunMing)"  writes:


Will linux be only mesa-linux? I thought linux is an  open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? 
reject?
2. one hw feature that opengl/amdvlk developers work on that but no mesa
developers work on, cannot upstream as well?

I believe these questions are already covered by

"+Other userspace is only admissible if exposing a given feature through OpenGL
or
+OpenGL ES would result in a technically unsound design, incomplete driver or
+an implementation which isn't useful in real world usage."

If OpenGL needs the interface, then you need a Mesa implementation.
It's time for you to work with the community to build that or get it
built.  Or, in AMD's case, work with the Mesa developers that you
already employ.

If OpenGL doesn't need it, but Vulkan needs it, then we don't have a
clear policy in place, and this patch doesn't change that.  I would
personally say that AMDVLK doesn't qualify given that as far as I know
there is not open review of proposed patches to the project as they're
being developed.
Can I understand what you mean is, as soon as the stack is openly 
developed, then which will be able to drive new UAPI?


-David

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

Re: [Mesa-dev] [PATCH] nir: fix nir_remove_unused_varyings()

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

Thanks fo the fix Tim!

On 4/25/19 3:17 AM, Timothy Arceri wrote:

We were only setting the used mask for the first component of a
varying. Since the linking opts split vectors into scalars this
has mostly worked ok.

However this causes an issue where for example if we split a
struct on one side of the interface but not the other, then we
can possibly end up removing the first components on the side
that was split and then incorrectly remove the whole struct
on the other side of the varying.

With this change we simply mark all 4 components for each slot
used by a struct. We could possibly make this more fine gained
but that would require a more complex change.

This fixes a bug in Strange Brigade on RADV when tessellation
is enabled, all credit goes to Samuel Pitoiset for tracking down
the cause of the bug.

Fixes: f1eb5e639997 ("nir: add component level support to 
remove_unused_io_vars()")
---
  src/compiler/nir/nir_linking_helpers.c | 51 +-
  1 file changed, 33 insertions(+), 18 deletions(-)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index f4494c78f98..ef0f94baf47 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -59,6 +59,15 @@ get_variable_io_mask(nir_variable *var, gl_shader_stage 
stage)
 return ((1ull << slots) - 1) << location;
  }
  
+static uint8_t

+get_num_components(nir_variable *var)
+{
+   if (glsl_type_is_struct_or_ifc(glsl_without_array(var->type)))
+  return 4;
+
+   return glsl_get_vector_elements(glsl_without_array(var->type));
+}
+
  static void
  tcs_add_output_reads(nir_shader *shader, uint64_t *read, uint64_t 
*patches_read)
  {
@@ -80,12 +89,14 @@ tcs_add_output_reads(nir_shader *shader, uint64_t *read, 
uint64_t *patches_read)
 continue;
  
  nir_variable *var = nir_deref_instr_get_variable(deref);

-if (var->data.patch) {
-   patches_read[var->data.location_frac] |=
-  get_variable_io_mask(var, shader->info.stage);
-} else {
-   read[var->data.location_frac] |=
-  get_variable_io_mask(var, shader->info.stage);
+for (unsigned i = 0; i < get_num_components(var); i++) {
+   if (var->data.patch) {
+  patches_read[var->data.location_frac + i] |=
+ get_variable_io_mask(var, shader->info.stage);
+   } else {
+  read[var->data.location_frac + i] |=
+ get_variable_io_mask(var, shader->info.stage);
+   }
  }
   }
}
@@ -161,22 +172,26 @@ nir_remove_unused_varyings(nir_shader *producer, 
nir_shader *consumer)
 uint64_t patches_read[4] = { 0 }, patches_written[4] = { 0 };
  
 nir_foreach_variable(var, &producer->outputs) {

-  if (var->data.patch) {
- patches_written[var->data.location_frac] |=
-get_variable_io_mask(var, producer->info.stage);
-  } else {
- written[var->data.location_frac] |=
-get_variable_io_mask(var, producer->info.stage);
+  for (unsigned i = 0; i < get_num_components(var); i++) {
+ if (var->data.patch) {
+patches_written[var->data.location_frac + i] |=
+   get_variable_io_mask(var, producer->info.stage);
+ } else {
+written[var->data.location_frac + i] |=
+   get_variable_io_mask(var, producer->info.stage);
+ }
}
 }
  
 nir_foreach_variable(var, &consumer->inputs) {

-  if (var->data.patch) {
- patches_read[var->data.location_frac] |=
-get_variable_io_mask(var, consumer->info.stage);
-  } else {
- read[var->data.location_frac] |=
-get_variable_io_mask(var, consumer->info.stage);
+  for (unsigned i = 0; i < get_num_components(var); i++) {
+ if (var->data.patch) {
+patches_read[var->data.location_frac + i] |=
+   get_variable_io_mask(var, consumer->info.stage);
+ } else {
+read[var->data.location_frac + i] |=
+   get_variable_io_mask(var, consumer->info.stage);
+ }
}
 }
  

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