[Mesa-dev] [Bug 100960] Special block from Minecraft mod rendered out of place

[bugzilla-daemon]

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

--- Comment #21 from Sergii Romantsov  ---
(In reply to Fabian Maurer from comment #19)
> 
> Sidenote, why i965_dri.so? I though I'm using radeonsi.

Hello, Fabian.
Actually, its common "issue" for i965 and redaonsi and generally saying its
common for Mesa.

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

[Mesa-dev] [PATCH] iris: Fix assertion in iris_resource_from_handle() tiling usage

[Rhys Kidd]

Assertion error:

  iris_resource_from_handle: Assertion `res->bo->tiling_mode ==
  isl_tiling_to_i915_tiling(res->surf.tiling)' failed.

This patch fixes 16 piglit tests on KBL:
glx/glx-multithread-texture
glx/glx-query-drawable-glx_fbconfig_id-glxpbuffer
glx/glx-query-drawable-glx_fbconfig_id-glxpixmap
glx/glx-query-drawable-glx_preserved_contents
glx/glx-query-drawable-glxpbuffer-glx_height
glx/glx-query-drawable-glxpbuffer-glx_width
glx/glx-query-drawable-glxpixmap-glx_height
glx/glx-query-drawable-glxpixmap-glx_width
glx/glx-swap-pixmap
glx/glx-swap-pixmap-bad
glx/glx-tfp
glx/glx-visuals-depth -pixmap
glx/glx-visuals-stencil -pixmap
spec/egl 1.4/eglcreatepbuffersurface and then glclear
spec/egl 1.4/largest possible eglcreatepbuffersurface and then glclear
spec/egl_nok_texture_from_pixmap/basic

Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Signed-off-by: Rhys Kidd 
---
 src/gallium/drivers/iris/iris_resource.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/gallium/drivers/iris/iris_resource.c 
b/src/gallium/drivers/iris/iris_resource.c
index f3516ae8900..e717fafb1e6 100644
--- a/src/gallium/drivers/iris/iris_resource.c
+++ b/src/gallium/drivers/iris/iris_resource.c
@@ -467,8 +467,7 @@ iris_resource_from_handle(struct pipe_screen *pscreen,
   isl_drm_modifier_get_info(modifier);
assert(mod_info);
 
-   // XXX: usage...
-   isl_surf_usage_flags_t isl_usage = ISL_SURF_USAGE_DISPLAY_BIT;
+   isl_surf_usage_flags_t isl_usage = pipe_bind_to_isl_usage(templ->bind);
 
const struct iris_format_info fmt =
   iris_format_for_usage(devinfo, templ->format, isl_usage);
-- 
2.19.1

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

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Sun, Dec 16, 2018 at 9:19 PM Marek Olšák  wrote:

> On Thu, Dec 13, 2018 at 7:48 PM Dylan Baker  wrote:
>
>> Quoting Marek Olšák (2018-12-13 11:28:10)
>> > Another issue with meson is this:
>> >
>> > I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I
>> do
>> > meson configure --clearcache and then type "ninja", it will
>> reconfigure, but
>> > will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
>> when ninja
>> > is run, which will fail to link.
>> >
>> > Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
>> > --clearcache.
>> >
>> > Additionally, it would be nice if the default build type was release
>> instead of
>> > plain.
>> >
>> > Thanks,
>> > Marek
>> >
>> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker 
>> wrote:
>> >
>> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
>> make
>> > the
>> > final call for autotools. My patch is so massive that it's a huge
>> pain to
>> > send
>> > to the list, the latest versions is here:
>> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
>> >
>> > Dylan
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
>>
>> I've had much better luck using a cross file for doing x86 builds on
>> x86_64, I
>> believe I've posted my cross file before but I can do so again.
>>
>
> Can this possibly be documented in the Mesa docs? The current
> documentation is misleading (LLVM and PKG_CONFIG_PATH sections) and missing
> other information.
>

I think one of the serious usability issues is that environment variables
such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not saved by
meson for future reconfigures. I think meson should ignore the variables
completely, or the Mesa documentation should discourage users from the
setting the variables. The current situation would be acceptable to me if
users were warned that setting environment variables is a trap.

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

Re: [Mesa-dev] [PATCH 25/25] radeonsi: const-ify the si_query_ops

[Marek Olšák]

Except for patch 3, the series is:

Reviewed-by: Marek Olšák 

Marek

On Thu, Dec 6, 2018 at 9:01 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> ---
>  src/gallium/drivers/radeonsi/si_perfcounter.c | 2 +-
>  src/gallium/drivers/radeonsi/si_query.c   | 6 +++---
>  src/gallium/drivers/radeonsi/si_query.h   | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_perfcounter.c
> b/src/gallium/drivers/radeonsi/si_perfcounter.c
> index 65197c0daa4..fc2c58854bc 100644
> --- a/src/gallium/drivers/radeonsi/si_perfcounter.c
> +++ b/src/gallium/drivers/radeonsi/si_perfcounter.c
> @@ -908,21 +908,21 @@ static bool si_pc_query_get_result(struct si_context
> *sctx, struct si_query *rqu
>
> while (results_base != qbuf->results_end) {
> si_pc_query_add_result(query, map + results_base,
> result);
> results_base += query->result_size;
> }
> }
>
> return true;
>  }
>
> -static struct si_query_ops batch_query_ops = {
> +static const struct si_query_ops batch_query_ops = {
> .destroy = si_pc_query_destroy,
> .begin = si_pc_query_begin,
> .end = si_pc_query_end,
> .get_result = si_pc_query_get_result,
>
> .suspend = si_pc_query_suspend,
> .resume = si_pc_query_resume,
>  };
>
>  static struct si_query_group *get_group_state(struct si_screen *screen,
> diff --git a/src/gallium/drivers/radeonsi/si_query.c
> b/src/gallium/drivers/radeonsi/si_query.c
> index 5b0fba0ed92..093643bf684 100644
> --- a/src/gallium/drivers/radeonsi/si_query.c
> +++ b/src/gallium/drivers/radeonsi/si_query.c
> @@ -27,21 +27,21 @@
>  #include "si_pipe.h"
>  #include "si_query.h"
>  #include "util/u_memory.h"
>  #include "util/u_upload_mgr.h"
>  #include "util/os_time.h"
>  #include "util/u_suballoc.h"
>  #include "amd/common/sid.h"
>
>  #define SI_MAX_STREAMS 4
>
> -static struct si_query_ops query_hw_ops;
> +static const struct si_query_ops query_hw_ops;
>
>  struct si_hw_query_params {
> unsigned start_offset;
> unsigned end_offset;
> unsigned fence_offset;
> unsigned pair_stride;
> unsigned pair_count;
>  };
>
>  /* Queries without buffer handling or suspend/resume. */
> @@ -492,21 +492,21 @@ static bool si_query_sw_get_result(struct si_context
> *sctx,
> case SI_QUERY_CURRENT_GPU_SCLK:
> case SI_QUERY_CURRENT_GPU_MCLK:
> result->u64 *= 100;
> break;
> }
>
> return true;
>  }
>
>
> -static struct si_query_ops sw_query_ops = {
> +static const struct si_query_ops sw_query_ops = {
> .destroy = si_query_sw_destroy,
> .begin = si_query_sw_begin,
> .end = si_query_sw_end,
> .get_result = si_query_sw_get_result,
> .get_result_resource = NULL
>  };
>
>  static struct pipe_query *si_query_sw_create(unsigned query_type)
>  {
> struct si_query_sw *query;
> @@ -1336,21 +1336,21 @@ static void si_query_hw_add_result(struct
> si_screen *sscreen,
>  void si_query_hw_suspend(struct si_context *sctx, struct si_query *query)
>  {
> si_query_hw_emit_stop(sctx, (struct si_query_hw *)query);
>  }
>
>  void si_query_hw_resume(struct si_context *sctx, struct si_query *query)
>  {
> si_query_hw_emit_start(sctx, (struct si_query_hw *)query);
>  }
>
> -static struct si_query_ops query_hw_ops = {
> +static const struct si_query_ops query_hw_ops = {
> .destroy = si_query_hw_destroy,
> .begin = si_query_hw_begin,
> .end = si_query_hw_end,
> .get_result = si_query_hw_get_result,
> .get_result_resource = si_query_hw_get_result_resource,
>
> .suspend = si_query_hw_suspend,
> .resume = si_query_hw_resume,
>  };
>
> diff --git a/src/gallium/drivers/radeonsi/si_query.h
> b/src/gallium/drivers/radeonsi/si_query.h
> index 63af760a271..0bc1d56f78a 100644
> --- a/src/gallium/drivers/radeonsi/si_query.h
> +++ b/src/gallium/drivers/radeonsi/si_query.h
> @@ -134,21 +134,21 @@ struct si_query_ops {
> int index,
> struct pipe_resource *resource,
> unsigned offset);
>
> void (*suspend)(struct si_context *, struct si_query *);
> void (*resume)(struct si_context *, struct si_query *);
>  };
>
>  struct si_query {
> struct threaded_query b;
> -   struct si_query_ops *ops;
> +   const struct si_query_ops *ops;
>
> /* The PIPE_QUERY_xxx type of query */
> unsigned type;
>
> /* The number of dwords for suspend. */
> unsigned num_cs_dw_suspend;
>
> /* Linked list of queries that must be suspended at end of CS. */
> struct list_head active_list;
>  };
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> 

Re: [Mesa-dev] [PATCH 03/25] amd/common: cleanup DATA_FORMAT/NUM_FORMAT field names

[Marek Olšák]

The definitions weren't changed, but the values were. The names need to be
different, so that si_debug.c prints both the GFX6 and GFX9 values.

Marek

On Thu, Dec 6, 2018 at 9:01 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> The definition wasn't actually changed in gfx9, so having the suffix
> makes no sense.
> ---
>  src/amd/common/ac_nir_to_llvm.c   |  2 +-
>  src/amd/common/gfx9d.h| 12 ++--
>  src/amd/common/sid.h  | 12 ++--
>  src/amd/vulkan/radv_image.c   |  8 
>  src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c |  6 +++---
>  src/gallium/drivers/radeonsi/si_state.c   | 10 +-
>  6 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c
> b/src/amd/common/ac_nir_to_llvm.c
> index fe65dfff8f3..cbb5be4b1a2 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1238,21 +1238,21 @@ static LLVMValueRef lower_gather4_integer(struct
> ac_llvm_context *ctx,
> if (stype == GLSL_TYPE_UINT)
> /* Create a NUM FORMAT - 0x2 or 0x4 - USCALED or
> UINT */
> tmp = LLVMBuildSelect(ctx->builder,
> compare_cube_wa, LLVMConstInt(ctx->i32, 0x800, false),
>   LLVMConstInt(ctx->i32,
> 0x1000, false), "");
> else
> /* Create a NUM FORMAT - 0x3 or 0x5 - SSCALED or
> SINT */
> tmp = LLVMBuildSelect(ctx->builder,
> compare_cube_wa, LLVMConstInt(ctx->i32, 0xc00, false),
>   LLVMConstInt(ctx->i32,
> 0x1400, false), "");
>
> /* replace the NUM FORMAT in the descriptor */
> -   tmp2 = LLVMBuildAnd(ctx->builder, tmp2,
> LLVMConstInt(ctx->i32, C_008F14_NUM_FORMAT_GFX6, false), "");
> +   tmp2 = LLVMBuildAnd(ctx->builder, tmp2,
> LLVMConstInt(ctx->i32, C_008F14_NUM_FORMAT, false), "");
> tmp2 = LLVMBuildOr(ctx->builder, tmp2, tmp, "");
>
> args->resource = LLVMBuildInsertElement(ctx->builder,
> args->resource, tmp2, ctx->i32_1, "");
>
> /* don't modify the coordinates for this case */
> for (unsigned c = 0; c < 2; ++c)
> args->coords[c] = LLVMBuildSelect(
> ctx->builder, compare_cube_wa,
> orig_coords[c], args->coords[c], "");
> }
> diff --git a/src/amd/common/gfx9d.h b/src/amd/common/gfx9d.h
> index 2e790c54699..5d3de5842a1 100644
> --- a/src/amd/common/gfx9d.h
> +++ b/src/amd/common/gfx9d.h
> @@ -1262,23 +1262,23 @@
>  #define   S_030F14_COUNT_HI(x)
> (((unsigned)(x) & 0x7FFF) << 0)
>  #define   G_030F14_COUNT_HI(x)
> (((x) >> 0) & 0x7FFF)
>  #define   C_030F14_COUNT_HI
>  0x8000
>  #define R_008F14_SQ_IMG_RSRC_WORD1
> 0x008F14
>  #define   S_008F14_BASE_ADDRESS_HI(x)
>  (((unsigned)(x) & 0xFF) << 0)
>  #define   G_008F14_BASE_ADDRESS_HI(x)
>  (((x) >> 0) & 0xFF)
>  #define   C_008F14_BASE_ADDRESS_HI
> 0xFF00
>  #define   S_008F14_MIN_LOD(x)
>  (((unsigned)(x) & 0xFFF) << 8)
>  #define   G_008F14_MIN_LOD(x)
>  (((x) >> 8) & 0xFFF)
>  #define   C_008F14_MIN_LOD
> 0xFFF000FF
> -#define   S_008F14_DATA_FORMAT_GFX9(x)
> (((unsigned)(x) & 0x3F) << 20)
> -#define   G_008F14_DATA_FORMAT_GFX9(x)
> (((x) >> 20) & 0x3F)
> -#define   C_008F14_DATA_FORMAT_GFX9
>  0xFC0F
> +#define   S_008F14_DATA_FORMAT(x)
>  (((unsigned)(x) & 0x3F) << 20)
> +#define   G_008F14_DATA_FORMAT(x)
>  (((x) >> 20) & 0x3F)
> +#define   C_008F14_DATA_FORMAT
> 0xFC0F
>  #define V_008F14_IMG_DATA_FORMAT_INVALID0x00
>  #define V_008F14_IMG_DATA_FORMAT_8  0x01
>  #define V_008F14_IMG_DATA_FORMAT_16 0x02
>  #define V_008F14_IMG_DATA_FORMAT_8_80x03
>  #define V_008F14_IMG_DATA_FORMAT_32 0x04
>  #define V_008F14_IMG_DATA_FORMAT_16_16  0x05
>  #define V_008F14_IMG_DATA_FORMAT_10_11_11   0x06
>  #define V_008F14_IMG_DATA_FORMAT_11_11_10   0x07
>  #define V_008F14_IMG_DATA_FORMAT_10_10_10_2 0x08
>  #define V_008F14_IMG_DATA_FORMAT_2_10_10_10 0x09
> @@ -1329,23 +1329,23 @@
>  #define V_008F14_IMG_DATA_FORMAT_N_IN_16_16_16_16   0x36
>  #define V_008F14_IMG_DATA_FORMAT_N_IN_16_AS_16_16_16_16 0x37
>  #define V_008F14_IMG_DATA_FORMAT_RESERVED_560x38
>  #define V_008F14_IMG_DATA_FORMAT_4_40x39
>  #define V_008F14_IMG_DATA_FORMAT_6_5_5  0x3A
>  #define V_008F14_IMG_DATA_FORMAT_S8_16  0x3B
>  #define 

Re: [Mesa-dev] [PATCH] st/mesa: remove sampler associated with buffer texture in pbo logic

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Dec 14, 2018 at 8:43 PM Ilia Mirkin  wrote:

> A long time ago, when this was first implemented, not having a sampler
> bound would cause problems on Fermi. I didn't work out the reasons, but
> the solution was simple -- just put the samplers back in.
>
> Since then, regular texturing paths appear to have lost their associated
> samplers which required a fuller investigation and fix in nouveau. Now
> that this is done, this code should no longer need a sampler state for
> fetching texels from a buffer texture.
>
> Signed-off-by: Ilia Mirkin 
> ---
>
> This was introduced in 2b938a390 which fixed a number of legitimate
> issues, as well as this which ultimately was an issue in nouveau which
> in turn were fixed in 153d3fc5f9.
>
> At the time this was the only way for the condition to occur. However
> now more bits have changed and a txf on a buffer could end up happening
> without a sampler bound under "usual" circumstances, which necessitated
> an investigation and proper fix.
>
>  src/mesa/state_tracker/st_cb_texture.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index b8cc616d8f2..45918e425ac 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -1192,7 +1192,6 @@ try_pbo_upload_common(struct gl_context *ctx,
>return false;
>
> cso_save_state(cso, (CSO_BIT_FRAGMENT_SAMPLER_VIEWS |
> -CSO_BIT_FRAGMENT_SAMPLERS |
>  CSO_BIT_VERTEX_ELEMENTS |
>  CSO_BIT_AUX_VERTEX_BUFFER_SLOT |
>  CSO_BIT_FRAMEBUFFER |
> @@ -1216,8 +1215,6 @@ try_pbo_upload_common(struct gl_context *ctx,
> {
>struct pipe_sampler_view templ;
>struct pipe_sampler_view *sampler_view;
> -  struct pipe_sampler_state sampler = {0};
> -  const struct pipe_sampler_state *samplers[1] = {};
>
>memset(, 0, sizeof(templ));
>templ.target = PIPE_BUFFER;
> @@ -1237,8 +1234,6 @@ try_pbo_upload_common(struct gl_context *ctx,
>cso_set_sampler_views(cso, PIPE_SHADER_FRAGMENT, 1, _view);
>
>pipe_sampler_view_reference(_view, NULL);
> -
> -  cso_set_samplers(cso, PIPE_SHADER_FRAGMENT, 1, samplers);
> }
>
> /* Framebuffer_state */
> --
> 2.18.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 1/2] ddebug: simplify watchdog loop and fix crash in the no-timeout case

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Thu, Dec 6, 2018 at 7:57 AM Nicolai Hähnle  wrote:

> From: Nicolai Hähnle 
>
> The following race condition could occur in the no-timeout case:
>
>   API thread   Gallium threadWatchdog
>   --   --
>   dd_before_draw
>   u_threaded_context draw
>   dd_after_draw
> add to dctx->records
> signal watchdog
>  dump & destroy record
>execute draw
>dd_after_draw_async
>  use-after-free!
>
> Alternatively, the same scenario would assert in a debug build when
> destroying the record because record->driver_finished has not signaled.
>
> Fix this and simplify the logic at the same time by
> - handing the record pointers off to the watchdog thread *before* each
>   draw call and
> - waiting on the driver_finished fence in the watchdog thread
> ---
>  .../auxiliary/driver_ddebug/dd_context.c  |   1 -
>  src/gallium/auxiliary/driver_ddebug/dd_draw.c | 103 --
>  src/gallium/auxiliary/driver_ddebug/dd_pipe.h |  21 ++--
>  3 files changed, 52 insertions(+), 73 deletions(-)
>
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> index a9ac6ef14ab..15efeccf879 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_context.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_context.c
> @@ -589,21 +589,20 @@ static void
>  dd_context_destroy(struct pipe_context *_pipe)
>  {
> struct dd_context *dctx = dd_context(_pipe);
> struct pipe_context *pipe = dctx->pipe;
>
> dd_thread_join(dctx);
> mtx_destroy(>mutex);
> cnd_destroy(>cond);
>
> assert(list_empty(>records));
> -   assert(!dctx->record_pending);
>
> if (pipe->set_log_context) {
>pipe->set_log_context(pipe, NULL);
>
>if (dd_screen(dctx->base.screen)->dump_mode == DD_DUMP_ALL_CALLS) {
>   FILE *f = dd_get_file_stream(dd_screen(dctx->base.screen), 0);
>   if (f) {
>  fprintf(f, "Remainder of driver log:\n\n");
>   }
>
> diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
> b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
> index cb5db8ab83b..a930299ebb7 100644
> --- a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
> +++ b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
> @@ -981,80 +981,75 @@ dd_report_hang(struct dd_context *dctx)
>   }
>
>   fclose(f);
>}
>
>if (top_not_reached)
>   stop_output = true;
>encountered_hang = true;
> }
>
> -   if (num_later || dctx->record_pending) {
> -  fprintf(stderr, "... and %u%s additional draws.\n", num_later,
> -  dctx->record_pending ? "+1 (pending)" : "");
> -   }
> +   if (num_later)
> +  fprintf(stderr, "... and %u additional draws.\n", num_later);
>
> 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;
>
> mtx_lock(>mutex);
>
> for (;;) {
>struct list_head records;
> -  struct pipe_fence_handle *fence;
> -  struct pipe_fence_handle *fence2 = NULL;
> -
>list_replace(>records, );
>list_inithead(>records);
>dctx->num_records = 0;
>
>if (dctx->api_stalled)
>   cnd_signal(>cond);
>
> -  if (!list_empty()) {
> - /* Wait for the youngest draw. This means hangs can take a bit
> longer
> -  * to detect, but it's more efficient this way. */
> - struct dd_draw_record *youngest =
> -LIST_ENTRY(struct dd_draw_record, records.prev, list);
> - fence = youngest->bottom_of_pipe;
> -  } else if (dctx->record_pending) {
> - /* Wait for pending fences, in case the driver ends up hanging
> internally. */
> - fence = dctx->record_pending->prev_bottom_of_pipe;
> - fence2 = dctx->record_pending->top_of_pipe;
> -  } else if (dctx->kill_thread) {
> - break;
> -  } else {
> +  if (list_empty()) {
> + if (dctx->kill_thread)
> +break;
> +
>   cnd_wait(>cond, >mutex);
>   continue;
>}
> +
>mtx_unlock(>mutex);
>
> -  /* Fences can be NULL legitimately when timeout detection is
> disabled. */
> -  if ((fence &&
> -   !screen->fence_finish(screen, NULL, fence,
> - (uint64_t)dscreen->timeout_ms *
> 1000*1000)) ||
> -  (fence2 &&
> -   !screen->fence_finish(screen, NULL, fence2,
> - (uint64_t)dscreen->timeout_ms *
> 1000*1000))) {
> - mtx_lock(>mutex);
> - list_splice(, >records);
> - dd_report_hang(dctx);
> 

Re: [Mesa-dev] [PATCH 4/8] st/mesa: expose GL_NV_shader_atomic_float when ATOMFADD is supported

[Marek Olšák]

For patches 1-4:

Reviewed-by: Marek Olšák 

Marek

On Wed, Dec 5, 2018 at 12:29 AM Ilia Mirkin  wrote:

> Signed-off-by: Ilia Mirkin 
> ---
>  src/mesa/state_tracker/st_extensions.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 002866d4cdb..8d0e8e0292f 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -759,6 +759,7 @@ void st_init_extensions(struct pipe_screen *screen,
>{ o(NV_conditional_render),PIPE_CAP_CONDITIONAL_RENDER
>  },
>{ o(NV_fill_rectangle),
> PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE  },
>{ o(NV_primitive_restart), PIPE_CAP_PRIMITIVE_RESTART
>   },
> +  { o(NV_shader_atomic_float),   PIPE_CAP_TGSI_ATOMFADD
>   },
>{ o(NV_texture_barrier),   PIPE_CAP_TEXTURE_BARRIER
>   },
>{ o(NVX_gpu_memory_info),  PIPE_CAP_QUERY_MEMORY_INFO
>   },
>/* GL_NV_point_sprite is not supported by gallium because we don't
> --
> 2.18.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] last call for autotools

[Marek Olšák]

On Thu, Dec 13, 2018 at 7:48 PM Dylan Baker  wrote:

> Quoting Marek Olšák (2018-12-13 11:28:10)
> > Another issue with meson is this:
> >
> > I have to set PKG_CONFIG_PATH when I type meson for 32-bit builds. If I
> do
> > meson configure --clearcache and then type "ninja", it will reconfigure,
> but
> > will use 64-bit libraries instead because PKG_CONFIG_PATH is not set
> when ninja
> > is run, which will fail to link.
> >
> > Luckily, at least CC="gcc -m32" and CXX="g++ -m32" weren't wiped out by
> > --clearcache.
> >
> > Additionally, it would be nice if the default build type was release
> instead of
> > plain.
> >
> > Thanks,
> > Marek
> >
> > On Mon, Dec 10, 2018 at 6:11 PM Dylan Baker  wrote:
> >
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to
> make
> > the
> > final call for autotools. My patch is so massive that it's a huge
> pain to
> > send
> > to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> >
> > Dylan
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> I've had much better luck using a cross file for doing x86 builds on
> x86_64, I
> believe I've posted my cross file before but I can do so again.
>

Can this possibly be documented in the Mesa docs? The current documentation
is misleading (LLVM and PKG_CONFIG_PATH sections) and missing other
information.

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

Re: [Mesa-dev] PSA: Please send MRs to the mailing list

[Ilia Mirkin]

A diffstat would also be nice as it would better inform people reading
emails whether they need to care or not.
On Sun, Dec 16, 2018 at 7:53 PM Jason Ekstrand  wrote:
>
> One of these days, we will hopefully have a script to just do this for us.  
> In the mean-time, manual isn't too bad.
>
> On Sun, Dec 16, 2018 at 6:52 PM Jason Ekstrand  wrote:
>>
>> I don't know if it was actually in the doc that Jordan wrote up but it's 
>> courteous of you to send a quick e-mail to the mailing list when you create 
>> a new MR so that people who aren't regularly trolling the list of MRs are at 
>> least aware that it exists.  Of the 20 MRs that have been posted so far, I 
>> think I'm the only one doing this.  I'm a big fan of MRs but I also don't 
>> want us MR fans to anger the list. :-)
>>
>> --Jason
>
> ___
> 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] PSA: Please send MRs to the mailing list

[Jason Ekstrand]

One of these days, we will hopefully have a script to just do this for us.
In the mean-time, manual isn't too bad.

On Sun, Dec 16, 2018 at 6:52 PM Jason Ekstrand  wrote:

> I don't know if it was actually in the doc that Jordan wrote up but it's
> courteous of you to send a quick e-mail to the mailing list when you create
> a new MR so that people who aren't regularly trolling the list of MRs are
> at least aware that it exists.  Of the 20 MRs that have been posted so far,
> I think I'm the only one doing this.  I'm a big fan of MRs but I also don't
> want us MR fans to anger the list. :-)
>
> --Jason
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] PSA: Please send MRs to the mailing list

[Jason Ekstrand]

I don't know if it was actually in the doc that Jordan wrote up but it's
courteous of you to send a quick e-mail to the mailing list when you create
a new MR so that people who aren't regularly trolling the list of MRs are
at least aware that it exists.  Of the 20 MRs that have been posted so far,
I think I'm the only one doing this.  I'm a big fan of MRs but I also don't
want us MR fans to anger the list. :-)

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

Re: [Mesa-dev] Suggestions for improving meson-based builds

[Jason Ekstrand]

On Sun, Dec 16, 2018 at 1:49 PM Ilia Mirkin  wrote:

> 1. Build creation command recovery. With autotools, "head config.log"
> will tell you how you configured it. This is important when things get
> screwed up, and so has to be available in plain text somewhere. There
> are a variety of other occasions where this can be useful -- debugging
> someone else's build, creating a second build for yourself with a few
> options changed, etc.
>

I'm not sure that this is necessary but I agree that it is useful.  I think
Dylan said someone was working on this?


> 2. Summary at the end. This is not strictly an autotools-specific
> issue, but rather how mesa has used it. That summary at the end is
> very useful to make sure you (or someone you're helping) hasn't
> screwed something up.
>

Run "meson configure" with no options.  It will dump out a full
configuration.  Sure, it's not the same format but, unless I'm
misunderstanding something, all of the information from the old summary and
more is available there.  Or are you concerned with various derived or
auto-configured values?  Or is it your concern that it get dumped out at
the end of a configure rather than having to ask for it?  It'd be helpful
if you'd be more specific about what you want than "the autotools thing".


> 3. Have a configure helper which makes it look like autotools.
> Everyone knows how to use autotools, in part because it's so very easy
> to use. No one wants to figure out how to operate some random
> project's build system (and while meson may have world-dominating
> aspirations, it's certainly not there yet). This is one of the reasons
> I avoid doing anything of substance with cmake-based projects. A few
> bits which ought to work: "./configure --help", "./configure
> --with-gallium-drivers=..." and so on, similar to the existing logic,
> "./configure CFLAGS=-O0" and so on. Those environment variables need
> to be baked into the build, and it should be able to bake in things
> like PKG_CONFIG_PATH in a way that affects meson's operations, not
> just the build-time bits. This should default to a particular build
> directory (perhaps creatively called "build"), with some way to
> specify an alternate (e.g. add a --builddir=...). I think it's fine to
> have a dummy Makefile generated in this case which just says "run
> ninja" without actually running it.
>

On the surface, I think this is a bad idea.  We currently have two build
systems that duplicate all these options and information and you're
effectively asking for a third.  Perhaps we could write a bit of python
which autogenerates it from meson_options.txt in which case it might be
ok.  However, I'm not at all a fan of duplicating all the information in a
shell script just so people can run ./configure instead of calling meson
directly.

For whatever it's worth, I used to also think this would be a good idea.
More recently, however, I've come to the conclusion that it'd just be a
crutch to help people continue pretending meson doesn't exist.  If we
provide ./configure and Make what are people going to want next?  In-tree
builds?  Also, when are we going to get to delete the ./configure script?
Probably never.


> 4. No matter what happens to the system, re-running "ninja" or
> "configure" should not cause failures. This can't always be prevented
> (bugs happen, I get it), but you get like one screwup every 5 years --
> it should be avoided as much as possible. If the solution is that the
> tool re-runs itself using the old configuration, that's fine -- but it
> can't just die saying "oh no, you're screwed", which it currently does
> when updating meson on the system.
>

Yes,I agree that this is a failing of meson and needs to be sorted.  Meson
could do a much better job of reconfiguring by itself when it detects an
incompatible update.


> 5. Cross-files are a clever way of solving the issue by offloading it
> as "not-my-problem". And the configuration for cross-compiling project
> A is going to be identical to project B. I understand all this.
> However in declaring it as "not-my-problem", meson makes it the user's
> problem. These files are currently not shipped as part of
> cross-compiling setups, and asking each user to figure out how to set
> them up is excessive -- cross builds are complex enough, and this is
> yet-another thing in the path to success. The configure wrapper should
> be able to take the standard parameters (--build, --host, etc) and
> have it work (e.g. by generating a cross-file on the fly).
>

I have seen multiple times now people vastly over-simplify how "automatic"
autotools makes cross-building.  The crossfile contains a lot more than
just --build and --host; it has actual paths to compilers and pkg-config,
extra options, and a few other things.  Then how does autotools make it so
simple?  Because distros ship patched versions of autotools with the
distro-specific bits hacked in.  On Fedora, for instance, they've hacked it
up so that --prefix=/usr on a 64-bit 

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Jason Ekstrand]

On Sun, Dec 16, 2018 at 11:40 AM Ilia Mirkin  wrote:

> On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny  wrote:
> >
> > Since Meson will eventually be the only build system deprecate autotools
> > now. It can still be used by invoking configure with the flag
> >   --enable-autotools
> >
> > Signed-off-by: Gert Wollny 
> > ---
> > IMO autotools should be properly deprecated prior it its removal, so here
> > is a patch to do just that. I think autotools should be marked as
> deprecated
> > for the 19.0 release and, depending on feedback, it could be removed
> with 19.1.
> > Anyway, in the end it's up to the release team how to handle this.
>
> I think too many usability issues are left over in meson to make it
> the recommended build system, and remove the system that everyone
> knows how to use. If people want to use meson that's fine, but a
> number of concerns have been surfaced which make it currently
> unsuitable. I plan on doing a longer write-up covering some of the
> things I've mentioned in the past along with some new ones.
>

This patch doesn't remove anything, it just changes the recommendation and
annoys people who use autotools.  Unless I've missed something, all of the
issues stated so far have been usability annoyances having to do with
re-building.  Nothing remains which prevents you from building the project
and some user who comes along randomly and wants to build mesa should be
able to use meson just fine.


> If the concern is that there are 2 build systems and it's unclear
> which to use, I'd definitely err on the side of making meson the one
> requiring extra hoops to jump through.
>

Right now, we have a chicken and egg problem.  Dylan has worked like crazy
to solve the blocking issues and, at this point, mesa is buildable with
meson in more-or-less all the configurations as autotools allows.  What
remains are a few useability issues.  The only way we'll solve those issues
is if people try meson and report them.  Given that most of the excited
early adopters are now pretty happy with it, what remains is to solve the
useability issues of those less excited.  As long as meson remains an
optional thing and autotools safe for the indefinite future, those less
excited will continue to ignore meson, use autotools, and not have their
problems solved.  As long as people insist on meson being deprecated until
100% of the issues are solved, the people trying to make meson happen have
a moving target and we'll keep running around in circles forever.  I don't
know how to move things forward without somehow forcing the issue a bit.  I
think Dylan's e-mail was reasonably effective at flushing out some of those
issues; this patch just goes a bit further.

I'm not trying to belittle the issues you've had in any way.  However,
we've had the meson build system in the works for over a year now and some
of us have been using almost nothing else for the 8 or 10 months of that.
The fact that some of these issues are just now surfacing is a bit
disappointing.  What we need is a concrete point at which we can declare
meson good enough and get rid of the legacy system.  Previously, Dylan and
the rest had been working under the assumption that the relevant milestone
was the ability to build mesa on Linux with all the same combinations as
were supported by autotools minus the couple which we decided to drop.
That milestone has been achieved.  Some of the feedback we heard on the
previous e-mail thread was that that isn't sufficient.  That's fine but the
question remains, what is sufficient?  It would be helpful if, along with
your list of issues, you would provide an indication of what you think the
"good enough" point is.

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

[Mesa-dev] [PATCH 3/6] st/nine: Fix volumetexture dtor on ctor failure

[Axel Davy]

The dtor is called on allocation failure,
thus we must check the volumes are allocated
before trying to release them.

Signed-off-by: Axel Davy 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/state_trackers/nine/volumetexture9.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/volumetexture9.c 
b/src/gallium/state_trackers/nine/volumetexture9.c
index 5dec4844864..c7191bce688 100644
--- a/src/gallium/state_trackers/nine/volumetexture9.c
+++ b/src/gallium/state_trackers/nine/volumetexture9.c
@@ -141,7 +141,8 @@ NineVolumeTexture9_dtor( struct NineVolumeTexture9 *This )
 
 if (This->volumes) {
 for (l = 0; l <= This->base.base.info.last_level; ++l)
-NineUnknown_Destroy(>volumes[l]->base);
+if (This->volumes[l])
+NineUnknown_Destroy(>volumes[l]->base);
 FREE(This->volumes);
 }
 
-- 
2.19.2

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

[Mesa-dev] [PATCH 4/6] st/nine: Bind src not dst in nine_context_box_upload

[Axel Davy]

nine_context_box_upload uploads a ram buffer (from src)
to a pipe_resource (dst).
We already have a refcount on the pipe_resource,
what needs to be protected from release is the ram buffer,
thus a reference to src.

Signed-off-by: Axel Davy 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/state_trackers/nine/nine_state.c | 6 +++---
 src/gallium/state_trackers/nine/nine_state.h | 2 +-
 src/gallium/state_trackers/nine/surface9.c   | 2 +-
 src/gallium/state_trackers/nine/volume9.c| 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_state.c 
b/src/gallium/state_trackers/nine/nine_state.c
index 273be88e2b8..4872e24f439 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -2434,7 +2434,7 @@ CSMT_ITEM_NO_WAIT_WITH_COUNTER(nine_context_range_upload,
 }
 
 CSMT_ITEM_NO_WAIT_WITH_COUNTER(nine_context_box_upload,
-   ARG_BIND_REF(struct NineUnknown, dst),
+   ARG_BIND_REF(struct NineUnknown, src_ref),
ARG_BIND_RES(struct pipe_resource, res),
ARG_VAL(unsigned, level),
ARG_COPY_REF(struct pipe_box, dst_box),
@@ -2449,8 +2449,8 @@ CSMT_ITEM_NO_WAIT_WITH_COUNTER(nine_context_box_upload,
 struct pipe_transfer *transfer = NULL;
 uint8_t *map;
 
-/* We just bind dst for the bind count */
-(void)dst;
+/* Binding src_ref avoids release before upload */
+(void)src_ref;
 
 map = pipe->transfer_map(pipe,
  res,
diff --git a/src/gallium/state_trackers/nine/nine_state.h 
b/src/gallium/state_trackers/nine/nine_state.h
index 51e5e326527..8de9f84a256 100644
--- a/src/gallium/state_trackers/nine/nine_state.h
+++ b/src/gallium/state_trackers/nine/nine_state.h
@@ -568,7 +568,7 @@ nine_context_range_upload(struct NineDevice9 *device,
 void
 nine_context_box_upload(struct NineDevice9 *device,
 unsigned *counter,
-struct NineUnknown *dst,
+struct NineUnknown *src_ref,
 struct pipe_resource *res,
 unsigned level,
 const struct pipe_box *dst_box,
diff --git a/src/gallium/state_trackers/nine/surface9.c 
b/src/gallium/state_trackers/nine/surface9.c
index 5fd662fa049..10518219a0a 100644
--- a/src/gallium/state_trackers/nine/surface9.c
+++ b/src/gallium/state_trackers/nine/surface9.c
@@ -660,7 +660,7 @@ NineSurface9_CopyMemToDefault( struct NineSurface9 *This,
 
 nine_context_box_upload(This->base.base.device,
 >pending_uploads_counter,
-(struct NineUnknown *)This,
+(struct NineUnknown *)From,
 r_dst,
 This->level,
 _box,
diff --git a/src/gallium/state_trackers/nine/volume9.c 
b/src/gallium/state_trackers/nine/volume9.c
index ec811aeba13..840f01dae10 100644
--- a/src/gallium/state_trackers/nine/volume9.c
+++ b/src/gallium/state_trackers/nine/volume9.c
@@ -449,7 +449,7 @@ NineVolume9_CopyMemToDefault( struct NineVolume9 *This,
 
 nine_context_box_upload(This->base.device,
 >pending_uploads_counter,
-(struct NineUnknown *)This,
+(struct NineUnknown *)From,
 r_dst,
 This->level,
 _box,
-- 
2.19.2

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

[Mesa-dev] [PATCH 5/6] st/nine: Add src reference to nine_context_range_upload

[Axel Davy]

Just like nine_context_box_upload, nine_context_range_upload
should reference the src, which holds the ram source buffer.

Fixes: https://github.com/iXit/Mesa-3D/issues/327
Signed-off-by: Axel Davy 
Cc: mesa-sta...@lists.freedesktop.org
---
 src/gallium/state_trackers/nine/buffer9.h| 4 +++-
 src/gallium/state_trackers/nine/nine_state.c | 4 
 src/gallium/state_trackers/nine/nine_state.h | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/buffer9.h 
b/src/gallium/state_trackers/nine/buffer9.h
index b04a0a721bb..1803d8d6405 100644
--- a/src/gallium/state_trackers/nine/buffer9.h
+++ b/src/gallium/state_trackers/nine/buffer9.h
@@ -104,7 +104,9 @@ NineBuffer9_Upload( struct NineBuffer9 *This )
 struct NineDevice9 *device = This->base.base.device;
 
 assert(This->base.pool == D3DPOOL_MANAGED && This->managed.dirty);
-nine_context_range_upload(device, >managed.pending_upload, 
This->base.resource,
+nine_context_range_upload(device, >managed.pending_upload,
+  (struct NineUnknown *)This,
+  This->base.resource,
   This->managed.dirty_box.x,
   This->managed.dirty_box.width,
   (char *)This->managed.data + 
This->managed.dirty_box.x);
diff --git a/src/gallium/state_trackers/nine/nine_state.c 
b/src/gallium/state_trackers/nine/nine_state.c
index 4872e24f439..02673c1f6ed 100644
--- a/src/gallium/state_trackers/nine/nine_state.c
+++ b/src/gallium/state_trackers/nine/nine_state.c
@@ -2423,6 +2423,7 @@ CSMT_ITEM_NO_WAIT(nine_context_gen_mipmap,
 }
 
 CSMT_ITEM_NO_WAIT_WITH_COUNTER(nine_context_range_upload,
+   ARG_BIND_REF(struct NineUnknown, src_ref),
ARG_BIND_RES(struct pipe_resource, res),
ARG_VAL(unsigned, offset),
ARG_VAL(unsigned, size),
@@ -2430,6 +2431,9 @@ CSMT_ITEM_NO_WAIT_WITH_COUNTER(nine_context_range_upload,
 {
 struct nine_context *context = >context;
 
+/* Binding src_ref avoids release before upload */
+(void)src_ref;
+
 context->pipe->buffer_subdata(context->pipe, res, 0, offset, size, data);
 }
 
diff --git a/src/gallium/state_trackers/nine/nine_state.h 
b/src/gallium/state_trackers/nine/nine_state.h
index 8de9f84a256..55960007bfb 100644
--- a/src/gallium/state_trackers/nine/nine_state.h
+++ b/src/gallium/state_trackers/nine/nine_state.h
@@ -560,6 +560,7 @@ nine_context_gen_mipmap(struct NineDevice9 *device,
 void
 nine_context_range_upload(struct NineDevice9 *device,
   unsigned *counter,
+  struct NineUnknown *src_ref,
   struct pipe_resource *res,
   unsigned offset,
   unsigned size,
-- 
2.19.2

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

[Mesa-dev] [PATCH 2/6] st/nine: Switch to presentation buffer if resize is detected

[Axel Davy]

This enables to match the window size
on resize on all cases, as it only works
currently with presentation buffers.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/swapchain9.c | 37 +++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/nine/swapchain9.c 
b/src/gallium/state_trackers/nine/swapchain9.c
index 138e8816a05..6c22be24c7c 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -715,7 +715,7 @@ present( struct NineSwapChain9 *This,
 struct pipe_fence_handle *fence;
 HRESULT hr;
 struct pipe_blit_info blit;
-int target_width, target_height, target_depth;
+int target_width, target_height, target_depth, i;
 
 DBG("present: This=%p pSourceRect=%p pDestRect=%p "
 "pDirtyRegion=%p hDestWindowOverride=%p"
@@ -753,6 +753,41 @@ present( struct NineSwapChain9 *This,
 ID3DPresent_GetWindowInfo(This->present, hDestWindowOverride, 
_width, _height, _depth);
 (void)target_depth;
 
+/* Switch to using presentation buffers on window resize.
+ * Note: Most apps should resize the d3d back buffers when
+ * a window resize is detected, which will result in a call to
+ * NineSwapChain9_Resize. Thus everything will get released,
+ * and it will switch back to not using separate presentation
+ * buffers. */
+if (!This->present_buffers[0] &&
+(target_width != resource->width0 || target_height != 
resource->height0)) {
+BOOL failure = false;
+struct pipe_resource *new_resource[This->num_back_buffers];
+D3DWindowBuffer *new_handles[This->num_back_buffers];
+for (i = 0; i < This->num_back_buffers; i++) {
+/* Note: if (!new_handles[i]), new_resource[i]
+ * gets released and contains NULL */
+create_present_buffer(This, target_width, target_height, 
_resource[i], _handles[i]);
+if (!new_handles[i])
+failure = true;
+}
+if (failure) {
+for (i = 0; i < This->num_back_buffers; i++) {
+if (new_resource[i])
+pipe_resource_reference(_resource[i], NULL);
+if (new_handles[i])
+D3DWindowBuffer_release(This, new_handles[i]);
+}
+} else {
+for (i = 0; i < This->num_back_buffers; i++) {
+D3DWindowBuffer_release(This, This->present_handles[i]);
+This->present_handles[i] = new_handles[i];
+pipe_resource_reference(>present_buffers[i], 
new_resource[i]);
+pipe_resource_reference(_resource[i], NULL);
+}
+}
+}
+
 pipe = NineDevice9_GetPipe(This->base.device);
 
 if (This->present_buffers[0]) {
-- 
2.19.2

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

[Mesa-dev] [PATCH 6/6] st/nine: Increase the limit of cached ff shaders

[Axel Davy]

100 is too small for some games, which triggers recompilations
every frame. Increase to 1024.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/nine_ff.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/state_trackers/nine/nine_ff.c 
b/src/gallium/state_trackers/nine/nine_ff.c
index 261be276ad8..cb77d6915b9 100644
--- a/src/gallium/state_trackers/nine/nine_ff.c
+++ b/src/gallium/state_trackers/nine/nine_ff.c
@@ -2138,7 +2138,7 @@ nine_ff_prune_vs(struct NineDevice9 *device)
 {
 struct nine_context *context = >context;
 
-if (device->ff.num_vs > 100) {
+if (device->ff.num_vs > 1024) {
 /* could destroy the bound one here, so unbind */
 context->pipe->bind_vs_state(context->pipe, NULL);
 util_hash_table_foreach(device->ff.ht_vs, nine_ff_ht_delete_cb, NULL);
@@ -2152,7 +2152,7 @@ nine_ff_prune_ps(struct NineDevice9 *device)
 {
 struct nine_context *context = >context;
 
-if (device->ff.num_ps > 100) {
+if (device->ff.num_ps > 1024) {
 /* could destroy the bound one here, so unbind */
 context->pipe->bind_fs_state(context->pipe, NULL);
 util_hash_table_foreach(device->ff.ht_ps, nine_ff_ht_delete_cb, NULL);
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/6] st/nine: Use helper to release swapchain buffers later

[Axel Davy]

This patch introduces a structure to release the
present_handles only when they are fully released
by the server, thus making
"DestroyD3DWindowBuffer" actually release the buffer
right away when called.

Signed-off-by: Axel Davy 
---
 src/gallium/state_trackers/nine/swapchain9.c | 49 
 src/gallium/state_trackers/nine/swapchain9.h |  1 +
 2 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/src/gallium/state_trackers/nine/swapchain9.c 
b/src/gallium/state_trackers/nine/swapchain9.c
index d330c855726..138e8816a05 100644
--- a/src/gallium/state_trackers/nine/swapchain9.c
+++ b/src/gallium/state_trackers/nine/swapchain9.c
@@ -128,6 +128,40 @@ D3DWindowBuffer_create(struct NineSwapChain9 *This,
 return ret;
 }
 
+static void
+D3DWindowBuffer_release(struct NineSwapChain9 *This,
+D3DWindowBuffer *present_handle)
+{
+int i;
+/* Add it to the 'pending release' list */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (!This->present_handles_pending_release[i]) {
+This->present_handles_pending_release[i] = present_handle;
+break;
+}
+}
+if (i == (D3DPRESENT_BACK_BUFFERS_MAX_EX + 1)) {
+ERR("Server not releasing buffers...\n");
+assert(false);
+}
+
+/* Destroy elements of the list released by the server */
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i] &&
+ID3DPresent_IsBufferReleased(This->present, 
This->present_handles_pending_release[i])) {
+/* WaitBufferReleased also waits the presentation feedback
+ * (which should arrive at about the same time),
+ * while IsBufferReleased doesn't. DestroyD3DWindowBuffer 
unfortunately
+ * checks it to release immediately all data, else the release
+ * is postponed for This->present release. To avoid leaks (we may 
handle
+ * a lot of resize), call WaitBufferReleased. */
+ID3DPresent_WaitBufferReleased(This->present, 
This->present_handles_pending_release[i]);
+ID3DPresent_DestroyD3DWindowBuffer(This->present, 
This->present_handles_pending_release[i]);
+This->present_handles_pending_release[i] = NULL;
+}
+}
+}
+
 static int
 NineSwapChain9_GetBackBufferCountForParams( struct NineSwapChain9 *This,
 D3DPRESENT_PARAMETERS *pParams );
@@ -291,7 +325,7 @@ NineSwapChain9_Resize( struct NineSwapChain9 *This,
 This->enable_threadpool = FALSE;
 
 for (i = 0; i < oldBufferCount; i++) {
-ID3DPresent_DestroyD3DWindowBuffer(This->present, 
This->present_handles[i]);
+D3DWindowBuffer_release(This, This->present_handles[i]);
 This->present_handles[i] = NULL;
 if (This->present_buffers[i])
 pipe_resource_reference(&(This->present_buffers[i]), NULL);
@@ -519,6 +553,11 @@ NineSwapChain9_dtor( struct NineSwapChain9 *This )
 FREE(This->pending_presentation[i]);
 }
 
+for (i = 0; i < D3DPRESENT_BACK_BUFFERS_MAX_EX + 1; i++) {
+if (This->present_handles_pending_release[i])
+ID3DPresent_DestroyD3DWindowBuffer(This->present, 
This->present_handles_pending_release[i]);
+}
+
 for (i = 0; i < This->num_back_buffers; i++) {
 if (This->buffers[i])
 NineUnknown_Detach(NineUnknown(This->buffers[i]));
@@ -738,13 +777,7 @@ present( struct NineSwapChain9 *This,
 create_present_buffer(This, target_width, target_height, 
_resource, _handle);
 /* Switch to the new buffer */
 if (new_handle) {
-/* WaitBufferReleased also waits the presentation feedback,
- * while IsBufferReleased doesn't. DestroyD3DWindowBuffer 
unfortunately
- * checks it to release immediately all data, else the release
- * is postponed for This->present release. To avoid leaks (we 
may handle
- * a lot of resize), call WaitBufferReleased. */
-ID3DPresent_WaitBufferReleased(This->present, 
This->present_handles[0]);
-ID3DPresent_DestroyD3DWindowBuffer(This->present, 
This->present_handles[0]);
+D3DWindowBuffer_release(This, This->present_handles[0]);
 This->present_handles[0] = new_handle;
 pipe_resource_reference(>present_buffers[0], 
new_resource);
 pipe_resource_reference(_resource, NULL);
diff --git a/src/gallium/state_trackers/nine/swapchain9.h 
b/src/gallium/state_trackers/nine/swapchain9.h
index 0fa0589d3b7..a6146445bdd 100644
--- a/src/gallium/state_trackers/nine/swapchain9.h
+++ b/src/gallium/state_trackers/nine/swapchain9.h
@@ -57,6 +57,7 @@ struct NineSwapChain9
 struct NineSurface9 *buffers[D3DPRESENT_BACK_BUFFERS_MAX_EX + 1]; /* 0 to 
BackBufferCount-1 : the back buffers. BackBufferCount : additional 

[Mesa-dev] Suggestions for improving meson-based builds

[Ilia Mirkin]

Hello all,

There has been some discussion of late about dropping autotools or
making it a second-class citizen. I firmly believe such discussions
are premature.

I've had a chance to try meson recently. First off, I'd like to
commend the meson team (both the core project as well as the mesa
developers who have been pushing it) for being responsive to
build-prevention concerns (e.g. "the build doesn't work"). It does now
build successfully for me, which it did not when these efforts were
starting out.

In those tests, however, I noticed some shortcomings, which I believe
require being addressed before meson can be used in a major project
such as mesa. I'd like to outline some bits that any autotools
replacement needs to have (be it meson or anything else), in order to
be viable. This is all obviously on top of "produce correct build
results", which I take as a given. These are mostly in order that they
happened to occur to me rather than  prioritized by importance.

1. Build creation command recovery. With autotools, "head config.log"
will tell you how you configured it. This is important when things get
screwed up, and so has to be available in plain text somewhere. There
are a variety of other occasions where this can be useful -- debugging
someone else's build, creating a second build for yourself with a few
options changed, etc.

2. Summary at the end. This is not strictly an autotools-specific
issue, but rather how mesa has used it. That summary at the end is
very useful to make sure you (or someone you're helping) hasn't
screwed something up.

3. Have a configure helper which makes it look like autotools.
Everyone knows how to use autotools, in part because it's so very easy
to use. No one wants to figure out how to operate some random
project's build system (and while meson may have world-dominating
aspirations, it's certainly not there yet). This is one of the reasons
I avoid doing anything of substance with cmake-based projects. A few
bits which ought to work: "./configure --help", "./configure
--with-gallium-drivers=..." and so on, similar to the existing logic,
"./configure CFLAGS=-O0" and so on. Those environment variables need
to be baked into the build, and it should be able to bake in things
like PKG_CONFIG_PATH in a way that affects meson's operations, not
just the build-time bits. This should default to a particular build
directory (perhaps creatively called "build"), with some way to
specify an alternate (e.g. add a --builddir=...). I think it's fine to
have a dummy Makefile generated in this case which just says "run
ninja" without actually running it.

4. No matter what happens to the system, re-running "ninja" or
"configure" should not cause failures. This can't always be prevented
(bugs happen, I get it), but you get like one screwup every 5 years --
it should be avoided as much as possible. If the solution is that the
tool re-runs itself using the old configuration, that's fine -- but it
can't just die saying "oh no, you're screwed", which it currently does
when updating meson on the system.

5. Cross-files are a clever way of solving the issue by offloading it
as "not-my-problem". And the configuration for cross-compiling project
A is going to be identical to project B. I understand all this.
However in declaring it as "not-my-problem", meson makes it the user's
problem. These files are currently not shipped as part of
cross-compiling setups, and asking each user to figure out how to set
them up is excessive -- cross builds are complex enough, and this is
yet-another thing in the path to success. The configure wrapper should
be able to take the standard parameters (--build, --host, etc) and
have it work (e.g. by generating a cross-file on the fly).

Some of you reading who have made it this far (congratulations!) might
be thinking that all this "make meson look like autoconf" is just
silliness from someone who doesn't want to adapt to some new thing.
You're right - it is. But I don't think I'm alone. To those who are
looking for builds to be faster, you'll still get all your improvement
from having improved speed/caching of system settings and ninja's
improved parallelism. To the casual user, mesa will look like any
other project that doesn't require additional hoops to jump through.

Like it or not, autotools is currently the standard. The current
in-tree meson proposal is trying to change too much at once.

Cheers,

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Matt Turner]

On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny  wrote:
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
>   --enable-autotools
>
> Signed-off-by: Gert Wollny 
> ---
> IMO autotools should be properly deprecated prior it its removal, so here
> is a patch to do just that. I think autotools should be marked as deprecated
> for the 19.0 release and, depending on feedback, it could be removed with 
> 19.1.
> Anyway, in the end it's up to the release team how to handle this.
>
> Best,
> Gert
>
>  configure.ac | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 9b437a252c..73f5978bb7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -52,6 +52,19 @@ mingw*)
>  ;;
>  esac
>
> +AC_ARG_ENABLE(autotools,
> +   [AS_HELP_STRING([--enable-autotools],
> +   [Enable the use of this autotools based build 
> configuration])],
> +   [enable_autotools=$enableval], [enable_autotools=no])
> +
> +if test "x$enable_autotools" != "xyes" ; then
> +AC_MSG_ERROR([the autotools build system has been deprecated in favour of
> +meson and will be removed eventually. For instructions on how to use 
> meson
> +see https://www.mesa3d.org/meson.html.
> +If you still want to use the autotools build, then add --enable-autotools
> +to the configure command line.])
> +fi
> +

Fine by me.

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

Re: [Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Ilia Mirkin]

On Sun, Dec 16, 2018 at 6:24 AM Gert Wollny  wrote:
>
> Since Meson will eventually be the only build system deprecate autotools
> now. It can still be used by invoking configure with the flag
>   --enable-autotools
>
> Signed-off-by: Gert Wollny 
> ---
> IMO autotools should be properly deprecated prior it its removal, so here
> is a patch to do just that. I think autotools should be marked as deprecated
> for the 19.0 release and, depending on feedback, it could be removed with 
> 19.1.
> Anyway, in the end it's up to the release team how to handle this.

I think too many usability issues are left over in meson to make it
the recommended build system, and remove the system that everyone
knows how to use. If people want to use meson that's fine, but a
number of concerns have been surfaced which make it currently
unsuitable. I plan on doing a longer write-up covering some of the
things I've mentioned in the past along with some new ones.

If the concern is that there are 2 build systems and it's unclear
which to use, I'd definitely err on the side of making meson the one
requiring extra hoops to jump through.

Cheers,

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

Re: [Mesa-dev] [PATCH] radv: Fix a stupid if in gather_intrinsic_info

[Bas Nieuwenhuizen]

Reviewed-by: Bas Nieuwenhuizen 
On Sun, Dec 16, 2018 at 7:59 AM Jason Ekstrand  wrote:
>
> ---
>  src/amd/vulkan/radv_shader_info.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_shader_info.c 
> b/src/amd/vulkan/radv_shader_info.c
> index f7888ec6a6a..c2e005e63dd 100644
> --- a/src/amd/vulkan/radv_shader_info.c
> +++ b/src/amd/vulkan/radv_shader_info.c
> @@ -270,15 +270,15 @@ gather_intrinsic_info(const nir_shader *nir, const 
> nir_intrinsic_instr *instr,
> }
> mark_sampler_desc(var, info);
>
> -   if (nir_intrinsic_image_deref_store ||
> -   nir_intrinsic_image_deref_atomic_add ||
> -   nir_intrinsic_image_deref_atomic_min ||
> -   nir_intrinsic_image_deref_atomic_max ||
> -   nir_intrinsic_image_deref_atomic_and ||
> -   nir_intrinsic_image_deref_atomic_or ||
> -   nir_intrinsic_image_deref_atomic_xor ||
> -   nir_intrinsic_image_deref_atomic_exchange ||
> -   nir_intrinsic_image_deref_atomic_comp_swap) {
> +   if (instr->intrinsic == nir_intrinsic_image_deref_store ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_add 
> ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_min 
> ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_max 
> ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_and 
> ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_or ||
> +   instr->intrinsic == nir_intrinsic_image_deref_atomic_xor 
> ||
> +   instr->intrinsic == 
> nir_intrinsic_image_deref_atomic_exchange ||
> +   instr->intrinsic == 
> nir_intrinsic_image_deref_atomic_comp_swap) {
> if (nir->info.stage == MESA_SHADER_FRAGMENT)
> info->ps.writes_memory = true;
> }
> --
> 2.19.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

--- Comment #49 from erhar...@mailbox.org ---
Created attachment 142827
  --> https://bugs.freedesktop.org/attachment.cgi?id=142827=edit
coredump lp_test_conv (ppc64), Talos II

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

erhar...@mailbox.org changed:

   What|Removed |Added

 Attachment #140431|0   |1
is obsolete||
 Attachment #140432|0   |1
is obsolete||
 Attachment #140435|0   |1
is obsolete||

--- Comment #48 from erhar...@mailbox.org ---
Created attachment 142826
  --> https://bugs.freedesktop.org/attachment.cgi?id=142826=edit
coredump lp_test_format (ppc64), Talos II

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

--- Comment #47 from erhar...@mailbox.org ---
Created attachment 142825
  --> https://bugs.freedesktop.org/attachment.cgi?id=142825=edit
output from failed lp_tests (ppc64, Mesa 18.3.1), Talos II

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

--- Comment #46 from erhar...@mailbox.org ---
Created attachment 142824
  --> https://bugs.freedesktop.org/attachment.cgi?id=142824=edit
output from failed lp_tests (ppc64, Mesa 18.3.1), G5

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

--- Comment #45 from erhar...@mailbox.org ---
Created attachment 142823
  --> https://bugs.freedesktop.org/attachment.cgi?id=142823=edit
test-suite.log (ppc64, Mesa 18.3.1) standard build, G5

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.3.1 fails lp_test_format, lp_test_arit, lp_test_conv

[bugzilla-daemon]

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

erhar...@mailbox.org changed:

   What|Removed |Added

Summary|[llvmpipe] Mesa 18.1.2  |[llvmpipe] Mesa 18.3.1
   |fails lp_test_format,   |fails lp_test_format,
   |lp_test_arit,   |lp_test_arit, lp_test_conv
   |lp_test_blend,  |
   |lp_test_printf, |
   |lp_test_conv tests  |

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

[Mesa-dev] [Bug 106644] [llvmpipe] Mesa 18.1.2 fails lp_test_format, lp_test_arit, lp_test_blend, lp_test_printf, lp_test_conv tests

[bugzilla-daemon]

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

--- Comment #44 from erhar...@mailbox.org ---
Created attachment 142822
  --> https://bugs.freedesktop.org/attachment.cgi?id=142822=edit
test-suite.log (ppc64, Mesa 18.3.1) standard build, Talos II

Re-tested with 18.3.1 and a more recent toolchain (gcc 7.4.0, glibc 2.27,
binutils 2.30, llvm 6.0.1) on the G5 (POWER4) and addidtionally on a Talos II
(POWER9).

On both machines I build with:
export LIBGL_DEBUG=verbose && export MESA_DEBUG=verbose && export MESA_GLSL=""
&& export MESA_GLSL="dump log uniform useprog errors" && export
GALLIVM_DEBUG="tgsi ir asm dumpbc" && export ST_DEBUG=tgsi
./configure --enable-llvm --with-llvm-prefix=/usr/lib/llvm/6/ --disable-gles1
--with-gallium-drivers=r300,r600,swrast --enable-debug && make -j3 && make
check

Talos II failed 3 out of 5: lp_test_format, lp_test_arit, lp_test_conv
  G5 failed 2 out of 5: lp_test_format, lp_test_arit

Which is an improvement over 18.1.4 and 18.2.0_rc2! And as lp_test_format,
lp_test_arit fail on both POWER4 and POWER9 I guess it rules out the
possibility that this happens because of VSX instructions.

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

[Mesa-dev] [Bug 106769] radv: add support for shaderStorageImageMultisample

[bugzilla-daemon]

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

--- Comment #3 from mais...@archlinux.us ---
I would also like this feature to be implemented. We need this feature in the
Beetle PSX emulator for enabling MSAA support.

-- 
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] last call for autotools

[Gert Wollny]

Am Freitag, den 14.12.2018, 13:11 +0100 schrieb Gert Wollny:
> Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > I have to say that the user experience for autotools is WAY better
> > than for meson. As a concrete example, I had a meson build. Then I
> > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> > meson
> > --reconfigure (which presumably is what ninja would end up running)
> > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> 
> I think that was fixed with this PR (although I so far I didn't try
> to use this new feature, so I don't know how well it works):
>   https://github.com/mesonbuild/meson/pull/4356
> The error message should probably be updated accordingly. 

Today I updated to 0.49 (from 0.47) and there it didn't work (the file
meson-private/cmd_line.txt was missing), so my guess this is only
availabe for builds that were already created with 0.49.

However, there it doesn't work for me: 
https://bugs.freedesktop.org/show_bug.cgi?id=109071

Best,
Gert

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

[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"

[bugzilla-daemon]

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

Bug ID: 109071
   Summary: meson --wipe   results in Exception:
"FileNotFoundError: [Errno 2] No such file or
directory"
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: gw.foss...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142820
  --> https://bugs.freedesktop.org/attachment.cgi?id=142820=edit
The options file created by the original configuration

After successfully configuring the project, running "meson --wipe ..." results
in this FileNotFoundError, log below and the working directory seems to have
has changed to something that doesn't exist and build.ninja is not created. I
report this here,  but somehow my guess is that this is actually a meson
upstream bug. 

The Meson build system
Version: 0.49.0
Source dir: /home/gerddie/src/Collabora/Qemu2/samba/mesa
Build dir: /home/gerddie/src/Collabora/Qemu2/build/mesa-debug
Build type: native build
Program python found: YES (/usr/bin/python)
Project name: mesa
Project version: 19.0.0-devel
Appending CFLAGS from environment: '-Wall -Wextra -Wdeprecated-declarations -O2
-g -funroll-loops -ftree-vectorize -pthread -march=native -mtune=native
-mno-xop'
Native C compiler: gcc (gcc 7.3.0 "gcc (Gentoo 7.3.0-r3 p1.4) 7.3.0")
Appending CXXFLAGS from environment: '-Wall -Wextra -Wdeprecated-declarations
-O2 -g -funroll-loops -ftree-vectorize -pthread -march=native -mtune=native
-mno-xop'
Native C++ compiler: g++ (gcc 7.3.0 "g++ (Gentoo 7.3.0-r3 p1.4) 7.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Program pkg-config found: YES (/usr/bin/pkg-config)
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Dependency vdpau found: YES 1.1.1
Dependency xvmc found: YES 1.0.10
WARNING: Found CMake '/usr/bin/cmake' but couldn't run it
Found CMake: NO
Dependency libomxil-bellagio found: NO (tried pkgconfig and cmake)
Dependency libtizonia found: NO (tried pkgconfig and cmake)
Dependency libtizplatform found: NO (tried pkgconfig and cmake)
Dependency tizilheaders found: NO (tried pkgconfig and cmake)
Dependency libva found: YES 0.39.4
DEPRECATION: Project targetting '>= 0.45' but tried to use feature deprecated
since '0.48.0': python3 module
Checking for function "bswap32" : YES
Checking for function "bswap64" : YES
Checking for function "clz" : YES
Checking for function "clzll" : YES
Checking for function "ctz" : YES
Checking for function "expect" : YES
Checking for function "ffs" : YES
Checking for function "ffsll" : YES
Checking for function "popcount" : YES
Checking for function "popcountll" : YES
Checking for function "unreachable" : YES
Checking if "__attribute__((const))" compiles: YES
Checking if "__attribute__((flatten))" compiles: YES
Checking if "__attribute__((malloc))" compiles: YES
Checking if "__attribute__((pure))" compiles: YES
Checking if "__attribute__((unused))" compiles: YES
Checking if "__attribute__((warn_unused_result))" compiles: YES
Checking if "__attribute__((weak))" compiles: YES
Checking if "__attribute__((format(...)))" compiles: YES
Checking if "__attribute__((packed))" compiles: YES
Checking if "__attribute__((returns_nonnull))" compiles: YES
Checking if "__attribute__((visibility(...)))" compiles: YES
Checking if "__attribute__((alias(...)))" compiles: YES
Checking if "__attribute__((__noreturn__))" compiles: YES
Compiler for C supports arguments -Werror=implicit-function-declaration: YES
Compiler for C supports arguments -Werror=missing-prototypes: YES
Compiler for C supports arguments -Werror=return-type: YES
Compiler for C supports arguments -fno-math-errno: YES
Compiler for C supports arguments -fno-trapping-math: YES
Compiler for C supports arguments -Qunused-arguments: NO
Compiler for C supports arguments -Wmissing-field-initializers: YES
Compiler for C supports arguments -Wformat-truncation: YES
Compiler for C supports arguments -fvisibility=hidden: YESbuild 
Compiler for C++ supports arguments -Werror=return-type: YES
Compiler for C++ supports arguments -fno-math-errno: YES
Compiler for C++ supports arguments -fno-trapping-math: YES
Compiler for C++ supports arguments -Qunused-arguments: NO
Compiler for C++ supports arguments -Wnon-virtual-dtor: YES
Compiler for C++ supports arguments -Wmissing-field-initializers: YES
Compiler for C++ supports arguments -Wformat-truncation: YES
Compiler for C supports arguments -Woverride-init: YES
Compiler for C supports arguments -Winitializer-overrides: NO
Compiler for C++ supports arguments -fvisibility=hidden: YES
Compiler for C supports arguments -Werror=pointer-arith: YES
Compiler for C++ supports arguments -Werror=pointer-arith: YES
Compiler for C supports arguments -Werror=vla: YES
Compiler for C++ supports arguments 

Re: [Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Jan Vesely]

On Sun, 2018-12-16 at 10:36 +0100, Kai Wasserbäch wrote:
> Jan Vesely wrote on 13.12.18 22:17:
> > CodeGenOptions were moved to Basic.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
> > Signed-off-by: Jan Vesely 
> 
> Since this is the same as my patch
> () but older than mine, you 
> can
> have my:
> 
>  Reviewed-by: Kai Wasserbäch 

Thank you both,
Jan

> 
> Cheers,
> Kai
> 
> 
> > ---
> >  src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> > b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > index 975012cbda..b91cb95a29 100644
> > --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> > +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> > @@ -58,9 +58,14 @@
> >  #include 
> >  
> >  #include 
> > -#include 
> >  #include 
> >  
> > +#if HAVE_LLVM >= 0x0800
> > +#include 
> > +#else
> > +#include 
> > +#endif
> > +
> >  namespace clover {
> > namespace llvm {
> >namespace compat {
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-- 
Jan Vesely 

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] [Bug 109039] [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such file or directory

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Vesely  ---
Fixed in e4f9a37ace750646fd75fbbdff9b5e77a0b26cfb.

clover: Fix build after clang r348827

CodeGenOptions were moved to Basic.

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

[Mesa-dev] [Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 109039, which changed state.

Bug 109039 Summary: [CLOVER][CLANG-SVN] build failure CodeGenOptions.h: No such 
file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=109039

   What|Removed |Added

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

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

[Mesa-dev] [PATCH] autotools: Deprecate the use of autotools

[Gert Wollny]

Since Meson will eventually be the only build system deprecate autotools
now. It can still be used by invoking configure with the flag
  --enable-autotools

Signed-off-by: Gert Wollny 
---
IMO autotools should be properly deprecated prior it its removal, so here 
is a patch to do just that. I think autotools should be marked as deprecated 
for the 19.0 release and, depending on feedback, it could be removed with 19.1.
Anyway, in the end it's up to the release team how to handle this. 

Best,
Gert

 configure.ac | 13 +
 1 file changed, 13 insertions(+)

diff --git a/configure.ac b/configure.ac
index 9b437a252c..73f5978bb7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -52,6 +52,19 @@ mingw*)
 ;;
 esac
 
+AC_ARG_ENABLE(autotools,
+   [AS_HELP_STRING([--enable-autotools],
+   [Enable the use of this autotools based build 
configuration])],
+   [enable_autotools=$enableval], [enable_autotools=no])
+
+if test "x$enable_autotools" != "xyes" ; then
+AC_MSG_ERROR([the autotools build system has been deprecated in favour of
+meson and will be removed eventually. For instructions on how to use meson
+see https://www.mesa3d.org/meson.html.
+If you still want to use the autotools build, then add --enable-autotools
+to the configure command line.])
+fi
+
 # Support silent build rules, requires at least automake-1.11. Disable
 # by either passing --disable-silent-rules to configure or passing V=1
 # to make
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 2/3] nv50/ir: optimize slct(b, c, set(a, 0)) to slct(b, c, a)

[Karol Herbst]

 for
On Sat, Dec 15, 2018 at 7:58 PM Ilia Mirkin  wrote:
>
> On Fri, Dec 14, 2018 at 6:12 PM Karol Herbst  wrote:
> >
> > From: Karol Herbst 
> >
> > helps mainly feral ported games
> >
> > shader-db changes:
> > total instructions in shared programs : 7614782 -> 7565661 (-0.65%)
> > total gprs used in shared programs: 798045 -> 797213 (-0.10%)
> > total shared used in shared programs  : 639636 -> 639636 (0.00%)
> > total local used in shared programs   : 24648 -> 24648 (0.00%)
> > total bytes used in shared programs   : 81330696 -> 80806160 (-0.64%)
> >
> > local sharedgpr   inst  bytes
> > helped  0  0701   7940   7940
> >   hurt  0  0 44  4  4
> >
> > Signed-off-by: Karol Herbst 
> > ---
> >  .../nouveau/codegen/nv50_ir_peephole.cpp  | 47 +--
> >  1 file changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
> > b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > index a8bd4f868bf..37e9edc49f4 100644
> > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> > @@ -1763,7 +1763,8 @@ private:
> > bool tryADDToMADOrSAD(Instruction *, operation toOp);
> > void handleMINMAX(Instruction *);
> > void handleRCP(Instruction *);
> > -   void handleSLCT(Instruction *);
> > +   void handleSLCT(CmpInstruction *);
> > +   bool tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set);
>
> SLCT_SET or SET_SLCT. Otherwise it all runs together.
>
> > void handleLOGOP(Instruction *);
> > void handleCVT_NEG(Instruction *);
> > void handleCVT_CVT(Instruction *);
> > @@ -1956,8 +1957,12 @@ AlgebraicOpt::handleRCP(Instruction *rcp)
> >  }
> >
> >  void
> > -AlgebraicOpt::handleSLCT(Instruction *slct)
> > +AlgebraicOpt::handleSLCT(CmpInstruction *slct)
> >  {
> > +   Instruction *insn = slct->getSrc(2)->getInsn();
> > +   while(insn && insn->op == OP_SET && tryMergeSLCTSET(slct, 
> > insn->asCmp())) {
>
> while (
>
> > +  insn = slct->getSrc(2)->getInsn();
> > +   }
> > if (slct->getSrc(2)->reg.file == FILE_IMMEDIATE) {
> >if (slct->getSrc(2)->asImm()->compare(slct->asCmp()->setCond, 0.0f))
> >   slct->setSrc(0, slct->getSrc(1));
> > @@ -1970,6 +1975,42 @@ AlgebraicOpt::handleSLCT(Instruction *slct)
> > slct->setSrc(2, NULL);
> >  }
> >
> > +bool
> > +AlgebraicOpt::tryMergeSLCTSET(CmpInstruction *slct, CmpInstruction *set)
> > +{
> > +   assert(slct->op == OP_SLCT && set->op == OP_SET);
> > +
> > +   if (typeSizeof(set->sType) != 4)
> > +  return false;
> > +
> > +   CondCode setCC = set->getCondition();
> > +   CondCode slctCC = slct->getCondition();
> > +   CondCode newCC = setCC;
> > +
> > +   if (slctCC != CC_NE && slctCC != CC_EQ)
> > +  return false;
> > +
> > +   ImmediateValue imm0;
> > +   int s;
> > +
> > +   if (set->src(0).getImmediate(imm0) && imm0.isInteger(0))
> > +  s = 1;
> > +   else if (set->src(1).getImmediate(imm0) && imm0.isInteger(0))
> > +  s = 0;
> > +   else
> > +  return false;
> > +
> > +   slct->setSrc(2, set->getSrc(s));
> > +   if (s)
> > +  newCC = reverseCondCode(newCC);
> > +   if (slctCC == CC_EQ)
> > +  newCC = inverseCondCode(newCC);
>
> While not wrong, this is all pretty confusing. I won't require it, but
> I'd like to encourage you to write a paragraph about the theory about
> wtf is going on here.

I think this isn't directly correct though. We can't just flip a CC_EQ
over to a CC_NE or vice versa for floats, it has to be CC_EQU <=>
CC_NE and CC_EQ <=> CC_NEU. Need to think about this a bit more
carefully. Which might also mean that whenever we use inverseCondCode
for fp operations could be incorrect.

>
> > +
> > +   slct->sType = set->sType;
> > +   slct->setCondition(newCC);
> > +   return true;
> > +}
> > +
> >  void
> >  AlgebraicOpt::handleLOGOP(Instruction *logop)
> >  {
> > @@ -2340,7 +2381,7 @@ AlgebraicOpt::visit(BasicBlock *bb)
> >   handleMINMAX(i);
> >   break;
> >case OP_SLCT:
> > - handleSLCT(i);
> > + handleSLCT(i->asCmp());
> >   break;
> >case OP_AND:
> >case OP_OR:
> > --
> > 2.19.2
> >
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/1] clover: Fix build after clang r348827

[Kai Wasserbäch]

Jan Vesely wrote on 13.12.18 22:17:
> CodeGenOptions were moved to Basic.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109039
> Signed-off-by: Jan Vesely 

Since this is the same as my patch
() but older than mine, you can
have my:

 Reviewed-by: Kai Wasserbäch 

Cheers,
Kai


> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp 
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index 975012cbda..b91cb95a29 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -58,9 +58,14 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  
> +#if HAVE_LLVM >= 0x0800
> +#include 
> +#else
> +#include 
> +#endif
> +
>  namespace clover {
> namespace llvm {
>namespace compat {



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