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

[Marek Olšák]

Yeah, I'll try to add descriptive commit messages next time.

Marek

On Wed, May 1, 2019 at 11:22 PM Timothy Arceri 
wrote:

> I feel like I've asked this before but can you please try to add commit
> proper commit messages. Not adding a proper commit message might save
> you a minute or two but it cost much more than a minute or two for those
> trying to review a patch or that have bisect to the commit, used git
> blame, git log etc to find out why a change was made.
>
> I started reviewing the patch when you first sent it but it wasn't
> immediately obvious what the fix was vs tidy ups. I didn't want to go
> looking over specs either, all the relevant information should have been
> here in the commit message.
>
> Thanks,
> Tim
>
>
> On 2/5/19 11:17 am, Marek Olšák wrote:
> > Ping
> >
> > On Wed, Apr 24, 2019 at 1:30 PM Marek Olšák  > > wrote:
> >
> > From: Marek Olšák mailto:marek.ol...@amd.com>>
> >
> > ---
> >   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 &&
> >   

[Mesa-dev] [PATCH] radv: call constant folding before opt algebraic

[Timothy Arceri]

The pattern of calling opt algebraic first seems to have originated
in i965. The order in OpenGL drivers generally doesn't matter
because the GLSL IR optimisations do constant folding before
opt algebraic.

However in Vulkan drivers calling opt algebraic first can result
in missed constant folding opportunities.

vkpipeline-db results (VEGA64):

Totals from affected shaders:
SGPRS: 3160 -> 3176 (0.51 %)
VGPRS: 3588 -> 3580 (-0.22 %)
Spilled SGPRs: 52 -> 44 (-15.38 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 12 -> 12 (0.00 %) dwords per thread
Code Size: 261812 -> 261036 (-0.30 %) bytes
LDS: 7 -> 7 (0.00 %) blocks
Max Waves: 346 -> 348 (0.58 %)
Wait states: 0 -> 0 (0.00 %)
---
 src/amd/vulkan/radv_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index cd5a9f2afb4..ad7b2439735 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -162,8 +162,8 @@ radv_optimize_nir(struct nir_shader *shader, bool 
optimize_conservatively,
 NIR_PASS(progress, shader, nir_opt_dead_cf);
 NIR_PASS(progress, shader, nir_opt_cse);
 NIR_PASS(progress, shader, nir_opt_peephole_select, 8, true, 
true);
-NIR_PASS(progress, shader, nir_opt_algebraic);
 NIR_PASS(progress, shader, nir_opt_constant_folding);
+NIR_PASS(progress, shader, nir_opt_algebraic);
 NIR_PASS(progress, shader, nir_opt_undef);
 NIR_PASS(progress, shader, nir_opt_conditional_discard);
 if (shader->options->max_unroll_iterations) {
-- 
2.20.1

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

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

[Caio Marcelo de Oliveira Filho]

Sorry, missed this one.

It seems
https://github.com/KhronosGroup/GLSL/blob/master/extensions/nv/GLSL_NV_compute_shader_derivatives.txt
don't explicitly mention the interaction with EXT_texture_array but
seems reasonable to enable those.

This patch is

Reviewed-by: Caio Marcelo de Oliveira Filho 


On Wed, May 01, 2019 at 09:17:05PM -0400, Marek Olšák wrote:
> Ping
> 
> On Wed, Apr 24, 2019 at 1:30 PM Marek Olšák  wrote:
> 
> > 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) ||
> >

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

[Timothy Arceri]

I feel like I've asked this before but can you please try to add commit 
proper commit messages. Not adding a proper commit message might save 
you a minute or two but it cost much more than a minute or two for those 
trying to review a patch or that have bisect to the commit, used git 
blame, git log etc to find out why a change was made.


I started reviewing the patch when you first sent it but it wasn't 
immediately obvious what the fix was vs tidy ups. I didn't want to go 
looking over specs either, all the relevant information should have been 
here in the commit message.


Thanks,
Tim


On 2/5/19 11:17 am, Marek Olšák wrote:

Ping

On Wed, Apr 24, 2019 at 1:30 PM Marek Olšák > wrote:


From: Marek Olšák mailto:marek.ol...@amd.com>>

---
  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 

[Mesa-dev] [PATCH] panfrost: Support RGB565 FBOs

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pan_context.c  | 67 +++--
 src/gallium/drivers/panfrost/pan_mfbd.c | 11 +++-
 src/gallium/drivers/panfrost/pan_resource.c | 21 +--
 src/gallium/drivers/panfrost/pan_screen.c   |  8 +--
 4 files changed, 78 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index c50c546a399..770f6960c11 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -40,6 +40,7 @@
 #include "util/u_format.h"
 #include "indices/u_primconvert.h"
 #include "tgsi/tgsi_parse.h"
+#include "util/u_math.h"
 
 #include "pan_screen.h"
 #include "pan_blending.h"
@@ -53,6 +54,22 @@ extern const char *pan_counters_base;
 /* Do not actually send anything to the GPU; merely generate the cmdstream as 
fast as possible. Disables framebuffer writes */
 //#define DRY_RUN
 
+/* Can a given format support AFBC? Not all can. */
+
+static bool
+panfrost_can_afbc(enum pipe_format format)
+{
+const struct util_format_description *desc =
+util_format_description(format);
+
+if (util_format_is_rgba8_variant(desc))
+return true;
+
+/* TODO: AFBC of other formats */
+
+return false;
+}
+
 /* AFBC is enabled on a per-resource basis (AFBC enabling is theoretically
  * indepdent between color buffers and depth/stencil). To enable, we allocate
  * the AFBC metadata buffer and mark that it is enabled. We do -not- actually
@@ -228,11 +245,36 @@ panfrost_is_scanout(struct panfrost_context *ctx)
ctx->pipe_framebuffer.cbufs[0]->texture->bind & 
PIPE_BIND_SHARED;
 }
 
-/* Maps float 0.0-1.0 to int 0x00-0xFF */
-static uint8_t
-normalised_float_to_u8(float f)
+static uint32_t
+pan_pack_color(const union pipe_color_union *color, enum pipe_format format)
 {
-return (uint8_t) (int) (f * 255.0f);
+/* Alpha magicked to 1.0 if there is no alpha */
+
+bool has_alpha = util_format_has_alpha(format);
+float clear_alpha = has_alpha ? color->f[3] : 1.0f;
+
+/* Packed color depends on the framebuffer format */
+
+const struct util_format_description *desc =
+util_format_description(format);
+
+if (util_format_is_rgba8_variant(desc)) {
+return (float_to_ubyte(clear_alpha) << 24) |
+   (float_to_ubyte(color->f[2]) << 16) |
+   (float_to_ubyte(color->f[1]) <<  8) |
+   (float_to_ubyte(color->f[0]) <<  0);
+} else if (format == PIPE_FORMAT_B5G6R5_UNORM) {
+/* First, we convert the components to R5, G6, B5 separately */
+unsigned r5 = CLAMP(color->f[0], 0.0, 1.0) * 31.0;
+unsigned g6 = CLAMP(color->f[1], 0.0, 1.0) * 63.0;
+unsigned b5 = CLAMP(color->f[2], 0.0, 1.0) * 31.0;
+
+/* Then we pack into a sparse u32. TODO: Why these shifts? */
+return (b5 << 25) | (g6 << 14) | (r5 << 5);
+} else {
+/* Unknown format */
+assert(0);
+}
 }
 
 static void
@@ -246,18 +288,8 @@ panfrost_clear(
 struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
 
 if (buffers & PIPE_CLEAR_COLOR) {
-/* Alpha clear only meaningful without alpha channel, TODO 
less ad hoc */
-bool has_alpha = 
util_format_has_alpha(ctx->pipe_framebuffer.cbufs[0]->format);
-float clear_alpha = has_alpha ? color->f[3] : 1.0f;
-
-uint32_t packed_color =
-(normalised_float_to_u8(clear_alpha) << 24) |
-(normalised_float_to_u8(color->f[2]) << 16) |
-(normalised_float_to_u8(color->f[1]) <<  8) |
-(normalised_float_to_u8(color->f[0]) <<  0);
-
-job->clear_color = packed_color;
-
+enum pipe_format format = 
ctx->pipe_framebuffer.cbufs[0]->format;
+job->clear_color = pan_pack_color(color, format);
 }
 
 if (buffers & PIPE_CLEAR_DEPTH) {
@@ -2071,9 +2103,10 @@ panfrost_set_framebuffer_state(struct pipe_context *pctx,
 panfrost_attach_vt_framebuffer(ctx);
 
 struct panfrost_resource *tex = ((struct panfrost_resource *) 
ctx->pipe_framebuffer.cbufs[i]->texture);
+enum pipe_format format = 
ctx->pipe_framebuffer.cbufs[i]->format;
 bool is_scanout = panfrost_is_scanout(ctx);
 
-if (!is_scanout && tex->bo->layout != PAN_AFBC) {
+if (!is_scanout && tex->bo->layout != PAN_AFBC && 
panfrost_can_afbc(format)) {
 /* The blob is aggressive about enabling AFBC. As such,
  * it's pretty much necessary to use it here, since we
  * have no traces of 

Re: [Mesa-dev] [PATCH] st/dri: decrease input lag by syncing sooner in SwapBuffers

[Marek Olšák]

If there is no other feedback, I'll push this tomorrow.

Marek

On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák  wrote:

> This patch might improve performance, because less submitted unfinished
> work means less used memory by the unfinished work.
>
> Marek
>
> On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer  wrote:
>
>> On 2019-04-27 6:13 p.m., Rob Clark wrote:
>> > On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák  wrote:
>> >>
>> >> From: Marek Olšák 
>> >>
>> >> It's done by:
>> >> - decrease the number of frames in flight by 1
>> >> - flush before throttling in SwapBuffers
>> >>   (instead of wait-then-flush, do flush-then-wait)
>> >>
>> >> The improvement is apparent with Unigine Heaven.
>> >>
>> >> Previously:
>> >> draw frame 2
>> >> wait frame 0
>> >> flush frame 2
>> >> present frame 2
>> >>
>> >> The input lag is 2 frames.
>> >>
>> >> Now:
>> >> draw frame 2
>> >> flush frame 2
>> >> wait frame 1
>> >> present frame 2
>> >>
>> >> The input lag is 1 frame. Flushing is done before waiting, because
>> >> otherwise the device would be idle after waiting.
>> >>
>> >> Nine is affected because it also uses the pipe cap.
>> >> ---
>> >>  src/gallium/auxiliary/util/u_screen.c |  2 +-
>> >>  src/gallium/state_trackers/dri/dri_drawable.c | 20 +--
>> >>  2 files changed, 11 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/src/gallium/auxiliary/util/u_screen.c
>> b/src/gallium/auxiliary/util/u_screen.c
>> >> index 27f51e0898e..410f17421e6 100644
>> >> --- a/src/gallium/auxiliary/util/u_screen.c
>> >> +++ b/src/gallium/auxiliary/util/u_screen.c
>> >> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct
>> pipe_screen *pscreen,
>> >> case PIPE_CAP_MAX_VARYINGS:
>> >>return 8;
>> >>
>> >> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
>> >>return 0;
>> >>
>> >> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
>> >>return 0;
>> >>
>> >> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
>> >> -  return 2;
>> >> +  return 1;
>> >
>> > would it be safer to leave the current default and let drivers opt-in
>> > to the lower # individually?  I guess triple buffering would still be
>> > better for some of the smaller gpu's?
>>
>> This patch doesn't prevent triple buffering. The application can still
>> prepare up to one frame worth of GPU commands before the GPU has
>> finished processing the commands of the previous frame (while the
>> pre-previous frame is being displayed).
>>
>> I just think the term "in flight" should maybe be defined a bit better,
>> but it's not a blocker and could be done in a follow-up patch.
>>
>>
>> --
>> 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] glsl: fix and clean up NV_compute_shader_derivatives support

[Marek Olšák]

Ping

On Wed, Apr 24, 2019 at 1:30 PM Marek Olšák  wrote:

> 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));
> +  

Re: [Mesa-dev] Mesa (staging/19.0): radv: enable descriptor indexing capabilities

[Bas Nieuwenhuizen]

Well, kinda a fix.  Jason noticed that there were parts of the ext I
disabled but apparently implementations are required to enable them
(see 028ce527395642b68612d10c6030be5d4706a65e).

Though, I think this was backported under the assumption that
028ce527395642b68612d10c6030be5d4706a65e also was, and it looks like I
did not CC that to 19.0, partially because of a lot of dependencies.
Might make more sense to disable the ext on the 19.0 branch.


On Wed, May 1, 2019 at 9:56 PM Samuel Pitoiset
 wrote:
>
> wait what? Are we backporting a new feature into a stable branch? Do we
> really need that?
>
> On 5/1/19 6:35 PM, GitLab Mirror wrote:
> > Module: Mesa
> > Branch: staging/19.0
> > Commit: a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d
> >
> > Author: Juan A. Suarez Romero 
> > Date:   Mon Apr 29 17:05:13 2019 +0200
> >
> > radv: enable descriptor indexing capabilities
> >
> > This enables the remaining capabilities in SPV_EXT_descriptor_indexing.
> >
> > Fixes: 0e10790558b "radv: Enable VK_EXT_descriptor_indexing."
> >
> > Reviewed-by: Jason Ekstrand 
> > Reviewed-by: Bas Nieuwenhuizen 
> > (cherry picked from commit 06c9d7f9f94d9ab44a2b6148d9b5ec3f76c8d3db)
> >
> > ---
> >
> >   src/amd/vulkan/radv_shader.c | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> > index 2b45576bd41..7dd2fa2105c 100644
> > --- a/src/amd/vulkan/radv_shader.c
> > +++ b/src/amd/vulkan/radv_shader.c
> > @@ -222,6 +222,8 @@ radv_shader_compile_to_nir(struct radv_device *device,
> >   .lower_ubo_ssbo_access_to_offsets = true,
> >   .caps = {
> >   .descriptor_array_dynamic_indexing = true,
> > + .descriptor_array_non_uniform_indexing = true,
> > + .descriptor_indexing = true,
> >   .device_group = true,
> >   .draw_parameters = true,
> >   .float64 = true,
> >
> > ___
> > mesa-commit mailing list
> > mesa-com...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-commit
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] svga: add SVGA_NO_LOGGING env var (v2)

[Neha Bhende]

For series,
Reviewed-by: Neha Bhende 

Regards,
Neha


From: Brian Paul 
Sent: Wednesday, May 1, 2019 2:55 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Charmaine Lee; Deepak Singh Rawat; Thomas Hellstrom; 
mesa-sta...@lists.freedesktop.org
Subject: [PATCH 2/2] svga: add SVGA_NO_LOGGING env var (v2)

valgrind crashes when we try to initialize host logging.  This
env var can be used to disable logging.

v2: rebase onto "svga: move host logging to winsys".

Cc: mesa-sta...@lists.freedesktop.org
---
 docs/envvars.html  |  3 +++
 src/gallium/drivers/svga/svga_screen.c | 16 +++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index c9733e6..43d3a6c 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options.
 for details.
 SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file,
 such as the OpenGL program's name and command line arguments.
+SVGA_NO_LOGGING - if set, disables logging to the vmware.log file.
+This is useful when using Valgrind because it otherwise crashes when
+initializing the host log feature.
 See the driver code for other, lesser-used variables.
 

diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 664b9bf..f747ff7 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -917,6 +917,16 @@ init_logging(struct pipe_screen *screen)
 }


+/**
+ * no-op logging function to use when SVGA_NO_LOGGING is set.
+ */
+static void
+nop_host_log(struct svga_winsys_screen *sws, const char *message)
+{
+   /* nothing */
+}
+
+
 static void
 svga_destroy_screen( struct pipe_screen *screen )
 {
@@ -1134,7 +1144,11 @@ svga_screen_create(struct svga_winsys_screen *sws)

svga_screen_cache_init(svgascreen);

-   init_logging(screen);
+   if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == TRUE) {
+  svgascreen->sws->host_log = nop_host_log;
+   } else {
+  init_logging(screen);
+   }

return screen;
 error2:
--
1.8.5.6

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

[Mesa-dev] [PATCH 1/2] svga: move host logging to winsys

[Brian Paul]

From: Charmaine Lee 

This patch adds a host_log interface to svga_winsys and
moves the host logging code to the winsys layer.

Reviewed-by: Brian Paul 
---
 src/gallium/drivers/svga/Makefile.sources |   2 -
 src/gallium/drivers/svga/meson.build  |   1 -
 src/gallium/drivers/svga/svga_msg.c   | 451 --
 src/gallium/drivers/svga/svga_msg.h   |  42 ---
 src/gallium/drivers/svga/svga_screen.c|  12 +-
 src/gallium/drivers/svga/svga_winsys.h|   5 +
 src/gallium/winsys/svga/drm/Makefile.sources  |   2 +
 src/gallium/winsys/svga/drm/meson.build   |   1 +
 src/gallium/winsys/svga/drm/vmw_msg.c | 448 +
 src/gallium/winsys/svga/drm/vmw_msg.h |  41 +++
 src/gallium/winsys/svga/drm/vmw_screen_svga.c |   3 +
 11 files changed, 506 insertions(+), 502 deletions(-)
 delete mode 100755 src/gallium/drivers/svga/svga_msg.c
 delete mode 100644 src/gallium/drivers/svga/svga_msg.h
 create mode 100644 src/gallium/winsys/svga/drm/vmw_msg.c
 create mode 100644 src/gallium/winsys/svga/drm/vmw_msg.h

diff --git a/src/gallium/drivers/svga/Makefile.sources 
b/src/gallium/drivers/svga/Makefile.sources
index 72024cf..229d286 100644
--- a/src/gallium/drivers/svga/Makefile.sources
+++ b/src/gallium/drivers/svga/Makefile.sources
@@ -15,8 +15,6 @@ C_SOURCES := \
svga_hw_reg.h \
svga_link.c \
svga_link.h \
-   svga_msg.c \
-   svga_msg.h \
svga_mksstats.h \
svga_pipe_blend.c \
svga_pipe_blit.c \
diff --git a/src/gallium/drivers/svga/meson.build 
b/src/gallium/drivers/svga/meson.build
index 7981e29..4d3207a 100644
--- a/src/gallium/drivers/svga/meson.build
+++ b/src/gallium/drivers/svga/meson.build
@@ -27,7 +27,6 @@ files_svga = files(
   'svga_draw_elements.c',
   'svga_format.c',
   'svga_link.c',
-  'svga_msg.c',
   'svga_pipe_blend.c',
   'svga_pipe_blit.c',
   'svga_pipe_clear.c',
diff --git a/src/gallium/drivers/svga/svga_msg.c 
b/src/gallium/drivers/svga/svga_msg.c
deleted file mode 100755
index 8b63132..000
--- a/src/gallium/drivers/svga/svga_msg.c
+++ /dev/null
@@ -1,451 +0,0 @@
-/*
- * Copyright © 2016 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- */
-
-#include "util/u_math.h" /* for MAX2/MIN2 */
-#include "util/u_debug.h"
-#include "util/u_memory.h"
-#include "util/u_string.h"
-#include "pipe/p_defines.h"
-#include "svga_msg.h"
-
-
-#define MESSAGE_STATUS_SUCCESS  0x0001
-#define MESSAGE_STATUS_DORECV   0x0002
-#define MESSAGE_STATUS_CPT  0x0010
-#define MESSAGE_STATUS_HB   0x0080
-
-#define RPCI_PROTOCOL_NUM   0x49435052
-#define GUESTMSG_FLAG_COOKIE0x8000
-
-#define RETRIES 3
-
-#define VMW_HYPERVISOR_MAGIC0x564D5868
-#define VMW_HYPERVISOR_PORT 0x5658
-#define VMW_HYPERVISOR_HB_PORT  0x5659
-
-#define VMW_PORT_CMD_MSG30
-#define VMW_PORT_CMD_HB_MSG 0
-#define VMW_PORT_CMD_OPEN_CHANNEL  (MSG_TYPE_OPEN << 16 | VMW_PORT_CMD_MSG)
-#define VMW_PORT_CMD_CLOSE_CHANNEL (MSG_TYPE_CLOSE << 16 | VMW_PORT_CMD_MSG)
-#define VMW_PORT_CMD_SENDSIZE   (MSG_TYPE_SENDSIZE << 16 | VMW_PORT_CMD_MSG)
-#define VMW_PORT_CMD_RECVSIZE   (MSG_TYPE_RECVSIZE << 16 | VMW_PORT_CMD_MSG)
-#define VMW_PORT_CMD_RECVSTATUS (MSG_TYPE_RECVSTATUS << 16 | VMW_PORT_CMD_MSG)
-
-#define HIGH_WORD(X) ((X & 0x) >> 16)
-
-
-#if defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION > 502)
-
-/**
- * Hypervisor-specific bi-directional communication channel.  Should never
- * execute on bare metal hardware.  The caller must make sure to check for
- * supported hypervisor before using these macros.
- *
- * The last two parameters are both input and output and must be initialized.
- *
- * @cmd: [IN] Message Cmd
- * @in_bx: [IN] Message Len, through BX
- * @in_si: [IN] Input argument through SI, set to 0 if 

[Mesa-dev] [PATCH 2/2] svga: add SVGA_NO_LOGGING env var (v2)

[Brian Paul]

valgrind crashes when we try to initialize host logging.  This
env var can be used to disable logging.

v2: rebase onto "svga: move host logging to winsys".

Cc: mesa-sta...@lists.freedesktop.org
---
 docs/envvars.html  |  3 +++
 src/gallium/drivers/svga/svga_screen.c | 16 +++-
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index c9733e6..43d3a6c 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options.
 for details.
 SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file,
 such as the OpenGL program's name and command line arguments.
+SVGA_NO_LOGGING - if set, disables logging to the vmware.log file.
+This is useful when using Valgrind because it otherwise crashes when
+initializing the host log feature.
 See the driver code for other, lesser-used variables.
 
 
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 664b9bf..f747ff7 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -917,6 +917,16 @@ init_logging(struct pipe_screen *screen)
 }
 
 
+/**
+ * no-op logging function to use when SVGA_NO_LOGGING is set.
+ */
+static void
+nop_host_log(struct svga_winsys_screen *sws, const char *message)
+{
+   /* nothing */
+}
+
+
 static void
 svga_destroy_screen( struct pipe_screen *screen )
 {
@@ -1134,7 +1144,11 @@ svga_screen_create(struct svga_winsys_screen *sws)
 
svga_screen_cache_init(svgascreen);
 
-   init_logging(screen);
+   if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == TRUE) {
+  svgascreen->sws->host_log = nop_host_log;
+   } else {
+  init_logging(screen);
+   }
 
return screen;
 error2:
-- 
1.8.5.6

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

[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

[bugzilla-daemon]

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

Viktor Jägersküpper  changed:

   What|Removed |Added

 CC||viktor_jaegerskuepper@freen
   ||et.de

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

Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware

[Dave Airlie]

On Thu, 2 May 2019 at 05:36, Viktor Jaegerskuepper
 wrote:
>
> Dave Airlie:
> > On Wed, 1 May 2019 at 12:34, Ilia Mirkin  wrote:
> >>
> >> On Tue, Apr 30, 2019 at 10:42 AM Ilia Mirkin  wrote:
> >>>
> >>> On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie  wrote:
> 
>  On Tue, 30 Apr 2019 at 08:47, Dave Airlie  wrote:
> >
> > On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin  wrote:
> >>
> >> Thing is, I think that would not be enough - with the "recent" (like
> >> past 2 years) CSO/state change detection changes, I think that you can
> >> end up with no sampler set for a buffer view. Perhaps someone with the
> >> hw can investigate what goes wrong?
> >
> > I'm trying to get a live r600/700 machine, I plugged in my rv635 and
> > rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll
> > try and get up to date.
> 
>  I've found a working rv770 and reproduced it here. This isn't an
>  indication I'll get to fix it soon, but I will try.
> >>>
> >>> When I was debugging this issue on nouveau (and trying to nail down
> >>> specifically what didn't work and what was required to make it work),
> >>> I found that using a gallium test to debug this made the issues at
> >>> hand quite obvious, and I didn't have to worry about how to force the
> >>> st to assign mappings here or there for views or samplers. I'm not
> >>> sure if I still have those left over, but I'll have a look tonight.
> >>> They're also not terribly difficult to write.
> >>
> >> In case it's helpful:
> >> https://people.freedesktop.org/~imirkin/tbo-tex.c which fits together
> >> with the other gallium/tests/trivial ones.
> >>
> >> I think there were associated Makefile.am changes, but with the
> >> removal of autoconf, I probably lost the local changes.
> >>
> >> In its current form, it doesn't create a sampler, but you can see how
> >> trivial/quad-tex.c does it if you want to play around with having
> >> samplers around. You might also have to use PIPE_FORMAT_R8G8B8A8_UNORM
> >> instead of the BGRA variant for the view's format (iirc r600 has some
> >> limitations around swizzling and buffer textures).
> >>
> >
> > Thanks for test, but I ended up installing firefox and watching the
> > pain, then found it by accident.
> >
> > https://patchwork.freedesktop.org/patch/302675/
> >
> > For Viktor to test.
>
> Tested with RV770, the patch fixes the bug for Firefox Beta and Nightly.
>
> So was this really a bug in the old r600 code or is the patch a
> workaround for a Firefox/WebRender bug?

It's a bug in the old r600/rv770 specific codepaths that was uncovered
by the mesa state tracker change, but also relied on specific
webrender behaviour patterns to trigger, but it was a driver bug none
the less.

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

Re: [Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug

[Neha Bhende]

LGTM

Reviewed-by: Neha Bhende 

Regards,
Neha


From: Brian Paul 
Sent: Wednesday, May 1, 2019 1:28 PM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Jose Fonseca; Charmaine Lee
Subject: [PATCH] glsl: work around MinGW 7.x compiler bug

I'm not sure what triggered this, but building with
scons platform=windows toolchain=crossmingw machine=x86 build=profile
with MinGW g++ 7.3 or 7.4 causes an internal compiler error.

We can work around it by forcing -O1 optimization.
---
 src/compiler/glsl/builtin_variables.cpp | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 17ee80c..1b9963a 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -21,6 +21,21 @@
  * DEALINGS IN THE SOFTWARE.
  */

+
+/**
+ * Building this file with MinGW g++ 7.3 or 7.4 with:
+ *   scons platform=windows toolchain=crossmingw machine=x86 build=profile
+ * triggers an internal compiler error.
+ * Overriding the optimization level to -O1 works around the issue.
+ * MinGW 5.3.1 does not seem to have the bug, neither does 8.3.  So for now
+ * we're simply testing for version 7.x here.
+ */
+#if defined(__MINGW32__) && __GNUC__ == 7
+#warning "disabling optimizations for this file to work around compiler bug in 
MiGW gcc 7.x"
+#pragma GCC optimize("O1")
+#endif
+
+
 #include "ir.h"
 #include "ir_builder.h"
 #include "linker.h"
--
1.8.5.6

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

Re: [Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug

[Jose Fonseca]

Looks good to me.

Reviewed-by: Jose Fonseca 



From: Brian Paul 
Sent: Wednesday, May 1, 2019 21:28
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende; Jose Fonseca; Charmaine Lee
Subject: [PATCH] glsl: work around MinGW 7.x compiler bug

I'm not sure what triggered this, but building with
scons platform=windows toolchain=crossmingw machine=x86 build=profile
with MinGW g++ 7.3 or 7.4 causes an internal compiler error.

We can work around it by forcing -O1 optimization.
---
 src/compiler/glsl/builtin_variables.cpp | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 17ee80c..1b9963a 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -21,6 +21,21 @@
  * DEALINGS IN THE SOFTWARE.
  */

+
+/**
+ * Building this file with MinGW g++ 7.3 or 7.4 with:
+ *   scons platform=windows toolchain=crossmingw machine=x86 build=profile
+ * triggers an internal compiler error.
+ * Overriding the optimization level to -O1 works around the issue.
+ * MinGW 5.3.1 does not seem to have the bug, neither does 8.3.  So for now
+ * we're simply testing for version 7.x here.
+ */
+#if defined(__MINGW32__) && __GNUC__ == 7
+#warning "disabling optimizations for this file to work around compiler bug in 
MiGW gcc 7.x"
+#pragma GCC optimize("O1")
+#endif
+
+
 #include "ir.h"
 #include "ir_builder.h"
 #include "linker.h"
--
1.8.5.6

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

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #3 from james.dut...@gmail.com ---
I have the same issue, bisected to the same commit as you.
I have a Vega 56 and LLVM 8 also.

FYI. If you edit it back to be
if (HAVE_LLVM >= 0x800) {

The artifacts and crashing disappear.

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

[Mesa-dev] [PATCH] glsl: work around MinGW 7.x compiler bug

[Brian Paul]

I'm not sure what triggered this, but building with
scons platform=windows toolchain=crossmingw machine=x86 build=profile
with MinGW g++ 7.3 or 7.4 causes an internal compiler error.

We can work around it by forcing -O1 optimization.
---
 src/compiler/glsl/builtin_variables.cpp | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/compiler/glsl/builtin_variables.cpp 
b/src/compiler/glsl/builtin_variables.cpp
index 17ee80c..1b9963a 100644
--- a/src/compiler/glsl/builtin_variables.cpp
+++ b/src/compiler/glsl/builtin_variables.cpp
@@ -21,6 +21,21 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+
+/**
+ * Building this file with MinGW g++ 7.3 or 7.4 with:
+ *   scons platform=windows toolchain=crossmingw machine=x86 build=profile
+ * triggers an internal compiler error.
+ * Overriding the optimization level to -O1 works around the issue.
+ * MinGW 5.3.1 does not seem to have the bug, neither does 8.3.  So for now
+ * we're simply testing for version 7.x here.
+ */
+#if defined(__MINGW32__) && __GNUC__ == 7
+#warning "disabling optimizations for this file to work around compiler bug in 
MiGW gcc 7.x"
+#pragma GCC optimize("O1")
+#endif
+
+
 #include "ir.h"
 #include "ir_builder.h"
 #include "linker.h"
-- 
1.8.5.6

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

Re: [Mesa-dev] Mesa (staging/19.0): radv: enable descriptor indexing capabilities

[Samuel Pitoiset]

wait what? Are we backporting a new feature into a stable branch? Do we 
really need that?


On 5/1/19 6:35 PM, GitLab Mirror wrote:

Module: Mesa
Branch: staging/19.0
Commit: a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a1cdab7bd4ecad7c1c518fb8430613a7559d4f9d

Author: Juan A. Suarez Romero 
Date:   Mon Apr 29 17:05:13 2019 +0200

radv: enable descriptor indexing capabilities

This enables the remaining capabilities in SPV_EXT_descriptor_indexing.

Fixes: 0e10790558b "radv: Enable VK_EXT_descriptor_indexing."

Reviewed-by: Jason Ekstrand 
Reviewed-by: Bas Nieuwenhuizen 
(cherry picked from commit 06c9d7f9f94d9ab44a2b6148d9b5ec3f76c8d3db)

---

  src/amd/vulkan/radv_shader.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 2b45576bd41..7dd2fa2105c 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -222,6 +222,8 @@ radv_shader_compile_to_nir(struct radv_device *device,
.lower_ubo_ssbo_access_to_offsets = true,
.caps = {
.descriptor_array_dynamic_indexing = true,
+   .descriptor_array_non_uniform_indexing = true,
+   .descriptor_indexing = true,
.device_group = true,
.draw_parameters = true,
.float64 = true,

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

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

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Marek Olšák]

BTW, swrast doesn't have to exist on the system. It's not uncommon for me
to have no swrast on my development system.

Marek

On Wed, May 1, 2019 at 4:30 AM Mathias Fröhlich 
wrote:

> Hi Marek, Emil,
>
> On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> > On Mon, 29 Apr 2019 at 22:50, Marek Olšák  wrote:
> > >
> > > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen 
> wrote:
> > >>
> > >> On Sat, 27 Apr 2019 09:38:27 -0400
> > >> Marek Olšák  wrote:
> > >>
> > >> > Those are all valid reasons, but I don't wanna expose swrast for
> AMD's
> > >> > customers.
> > >>
> > >> Hi Marek,
> > >>
> > >> is you objection that you will never want to see any software renderer
> > >> in the list, or that you don't want to see a software renderer only as
> > >> long as it doesn't actually work?
> > >>
> > >> Why do you not "wanna expose swrast for AMD's customers"?
> > >>
> > >> Are you talking about swrast specifically or all the software
> renderers
> > >> in Mesa?
> > >>
> > >> I'm not an AMD customer if you mean someone paying for support rather
> > >> than just buying their hardware, so I cannot speak for them. However,
> I
> > >> would be very happy to have a software renderer available to be picked
> > >> the same way as any other hardware renderer, so that I can use it in
> > >> graphical test suites (a point from Anholt) testing also the EGL glue
> > >> in addition to the pixels produced.
> > >>
> > >> The thing will be run on boxes with AMD GPUs, and in those cases there
> > >> must be a way to *not* use the AMD GPU, and use the software renderer
> > >> instead when wanted. Not by environment variables or anything hacky
> > >> like that, but by deliberately choosing the software renderer in the
> > >> program. It will need an EGLSurface too.
> > >>
> > >> How would this be made to work in the future?
> > >
> > >
> > > A software renderer could be exposed by adding a new EGL function on
> top of EGL_EXT_device_base, for example:
> > >
> > > // EGL_MESA_device_software
> > >
> > > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice);
> > >
> > >
> > > You would get the swrast device from that function instead of
> eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps
> everything else the same.
> > >
> > IMHO the current EGL_MESA_device_software approach is perfectly valid.
> > The Query API provides the devices and one can query their
> > capabilities/device extensions.
>
> I agree with that. Well to repeat myself.
>
> For me there is also a basic consistency argument behind.
> So, Marek, you propose that the swrast device should only show
> up when there is no other device. That means swrast qualifies in
> principle as a 'device'.
> But if there is an other 'device' then swrast is not a 'device' anymore?
> I can not quite understand that from the outside.
> Means if swrast qualifies as a device in one configuration if should also
> be a device in any other configuration.
>
> There is also a next problem. I can understand that AMD wants to avoid
> for a customer to grab the swrast device by accident and get worse
> performance.
> But where do you draw the line then? Do you want to block out a drm device
> that comes up as a administration console device in such a typical compute
> cluster when there is an AMD device available? I mean for the same reason,
> where you want to avoid an application to grab the matrox device on that
> board
> that is put there for some sort of framebuffer console? If does AMD then
> negotiate with
> the Intel guys if their chip qualifies as 'device' in this sense?
> Do you then maintain a list of 'hardware devices' that qualify for a 'real
> device' then?
>
> As I said I can understand that the first device should be a GPU hardware
> backed device
> when possible to catch those simple example programs that only grab the
> first device.
> And I am still in favor of sorting this device list in a different way
> than it is today.
>
> Looking at that, it's probably a bit more educative to have the swrast
> device there in
> any case. That makes the average developer making use of that api aware
> that he has to
> look a bit closer at the devices before blindly using the first one. This
> awareness makes
> the administrative console device case being handled in the using
> application. That in turn
> will probably lead to the final effect that I would like to see as a GPU
> vendor, that is
> applications grab a GPU backed device and users are happy with the
> performance.
>
> As Emil mentions, you can find out if you grabed a swrast device or not.
> There is the case that your device is DRM backed, or swrast, or nothing -
> then its nvidia closed.
>
> > As far as I can see you have valid concerns:
> >  - HW devices should be the first/default
> >  - the SW device should work, if exposed
> >  - one may want to omit the SW one all together
> >
> > At the same time:
> >  - the device_base extension is explicit that at least one device must
> > be present
> 

Re: [Mesa-dev] Change in Mesa triggers bug in Firefox Nightly with WebRender on old AMD hardware

[Viktor Jaegerskuepper]

Dave Airlie:
> On Wed, 1 May 2019 at 12:34, Ilia Mirkin  wrote:
>>
>> On Tue, Apr 30, 2019 at 10:42 AM Ilia Mirkin  wrote:
>>>
>>> On Tue, Apr 30, 2019 at 2:48 AM Dave Airlie  wrote:

 On Tue, 30 Apr 2019 at 08:47, Dave Airlie  wrote:
>
> On Tue, 30 Apr 2019 at 08:42, Ilia Mirkin  wrote:
>>
>> Thing is, I think that would not be enough - with the "recent" (like
>> past 2 years) CSO/state change detection changes, I think that you can
>> end up with no sampler set for a buffer view. Perhaps someone with the
>> hw can investigate what goes wrong?
>
> I'm trying to get a live r600/700 machine, I plugged in my rv635 and
> rv740 gpus, and they both seemed toast, I've got an rv635 laptop I'll
> try and get up to date.

 I've found a working rv770 and reproduced it here. This isn't an
 indication I'll get to fix it soon, but I will try.
>>>
>>> When I was debugging this issue on nouveau (and trying to nail down
>>> specifically what didn't work and what was required to make it work),
>>> I found that using a gallium test to debug this made the issues at
>>> hand quite obvious, and I didn't have to worry about how to force the
>>> st to assign mappings here or there for views or samplers. I'm not
>>> sure if I still have those left over, but I'll have a look tonight.
>>> They're also not terribly difficult to write.
>>
>> In case it's helpful:
>> https://people.freedesktop.org/~imirkin/tbo-tex.c which fits together
>> with the other gallium/tests/trivial ones.
>>
>> I think there were associated Makefile.am changes, but with the
>> removal of autoconf, I probably lost the local changes.
>>
>> In its current form, it doesn't create a sampler, but you can see how
>> trivial/quad-tex.c does it if you want to play around with having
>> samplers around. You might also have to use PIPE_FORMAT_R8G8B8A8_UNORM
>> instead of the BGRA variant for the view's format (iirc r600 has some
>> limitations around swizzling and buffer textures).
>>
> 
> Thanks for test, but I ended up installing firefox and watching the
> pain, then found it by accident.
> 
> https://patchwork.freedesktop.org/patch/302675/
> 
> For Viktor to test.

Tested with RV770, the patch fixes the bug for Firefox Beta and Nightly.

So was this really a bug in the old r600 code or is the patch a
workaround for a Firefox/WebRender bug?

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

[Mesa-dev] [Bug 110350] DOOM 2016 crash + severe artifacting on RADV + Vega VII

[bugzilla-daemon]

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

--- Comment #9 from ant...@gmx.de ---
could you try reverting:

https://github.com/mesa3d/mesa/commit/b5ea4378c3260ff003532c8138a81a57091bdaa0#diff-078b981b454c93e62531f44768fca61d

ac/nir: only use the new raw/struct image atomic intrinsics with LLVM 9+
b5ea4378c3260ff003532c8138a81a57091bdaa0

and see if this fixes your issue?

-- 
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 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #2 from ant...@gmx.de ---
Just FYI currently on running LLVM 8

-- 
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 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

--- Comment #1 from ant...@gmx.de ---
I narrowed the issue to a specific commit:

https://github.com/mesa3d/mesa/commit/b5ea4378c3260ff003532c8138a81a57091bdaa0#diff-078b981b454c93e62531f44768fca61d

ac/nir: only use the new raw/struct image atomic intrinsics with LLVM 9+
b5ea4378c3260ff003532c8138a81a57091bdaa0

-- 
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] llvmpipe: init some vars to NULL to silence MinGW compiler warnings

[Neha Bhende]

LGTM.

Reviewed-by: Neha Bhende 

Regards,
Neha


From: mesa-dev  on behalf of Brian Paul 

Sent: Wednesday, May 1, 2019 9:48 AM
To: mesa-dev@lists.freedesktop.org
Cc: Neha Bhende
Subject: [Mesa-dev] [PATCH] llvmpipe: init some vars to NULL to silence MinGW 
compiler warnings

---
 src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 9561c34..90b2be9 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -2191,7 +2191,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
*gallivm,
   rgba = LLVMGetUndef(i128_vectype);

   for (count = 0; count < n / 4; count++) {
- LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
+ LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;

  i4 = lp_build_extract_range(gallivm, i, count * 4, 4);
  j4 = lp_build_extract_range(gallivm, j, count * 4, 4);
@@ -2230,7 +2230,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
*gallivm,
   rgba = LLVMBuildBitCast(builder, rgba, i8_vectype, "");
}
else {
-  LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
+  LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;

   lp_build_gather_s3tc(gallivm, n, format_desc, , ,
_lo, _hi, base_ptr, offset);
--
1.8.5.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbhenden%40vmware.com%7C7ecdd0d590fb4d22d32408d6ce54f538%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636923261641738945sdata=kw%2F%2BkO%2FLSjMh%2FcW8eHicq2VSHJ2wRdpjHsPtWg4rc10%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] svga: add SVGA_NO_LOGGING env var

[Neha Bhende]

Looks reasonable to me.

Reviewed-by: Neha Bhende 

Regards,
Neha


From: mesa-dev  on behalf of Brian Paul 

Sent: Wednesday, May 1, 2019 9:48 AM
To: mesa-dev@lists.freedesktop.org
Cc: mesa-sta...@lists.freedesktop.org; Neha Bhende; Deepak Singh Rawat
Subject: [Mesa-dev] [PATCH] svga: add SVGA_NO_LOGGING env var

valgrind crashes when we try to initialize host logging.  This
env var can be used to disable logging.

Cc: mesa-sta...@lists.freedesktop.org
---
 docs/envvars.html  | 3 +++
 src/gallium/drivers/svga/svga_screen.c | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index c9733e6..43d3a6c 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options.
 for details.
 SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file,
 such as the OpenGL program's name and command line arguments.
+SVGA_NO_LOGGING - if set, disables logging to the vmware.log file.
+This is useful when using Valgrind because it otherwise crashes when
+initializing the host log feature.
 See the driver code for other, lesser-used variables.
 

diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 6cb5a14..8158950 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -1134,7 +1134,9 @@ svga_screen_create(struct svga_winsys_screen *sws)

svga_screen_cache_init(svgascreen);

-   init_logging(screen);
+   if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == FALSE) {
+  init_logging(screen);
+   }

return screen;
 error2:
--
1.8.5.6

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbhenden%40vmware.com%7Cfd9f3e778e56480cc64708d6ce54d0f9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C636923261021926972sdata=c3YZTbcPzMc5HYTO%2FB%2FGWrztCwBXhKBnB21XUfLg0n0%3Dreserved=0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110573] Mesa vulkan-radeon 19.0.3 system freeze and visual artifacts (RADV)

[bugzilla-daemon]

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

Bug ID: 110573
   Summary: Mesa vulkan-radeon 19.0.3 system freeze and visual
artifacts (RADV)
   Product: Mesa
   Version: 19.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: ant...@gmx.de
QA Contact: mesa-dev@lists.freedesktop.org

Since mesa vulkan-radeon-19.0.3 (RADV) playing AC Odyssey via lutris and DXVK
(version of DXVK does not matter) the system hangs after finishing to load the
savegame. The loading screen shows flickering and blotchy particle effects of
the fire pit.
Reverting to 19.0.2 immediately fixes the issues, no particle issues and no
system hang.


I have also tested the current master and the issue is still persistent there.
Is there any trace I can deliver to help getting this fixed?

System:

Sapphire AMD Vega 56
model name  : AMD Ryzen 7 1700X Eight-Core Processor

Linux antergos 5.0.10-arch1-1-ARCH #1 SMP PREEMPT

-- 
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] svga: add SVGA_NO_LOGGING env var

[Deepak Singh Rawat]

Hi Brian,

I belive svgascreen->sws->host_log is causing this issue, am I right?
If so shoudn't we handle this in vmw_svga_winsys_host_log if host_log
is called from other places as well? Other than this

Reviewed-by: Deepak Rawat 

On Wed, 2019-05-01 at 10:48 -0600, Brian Paul wrote:
> valgrind crashes when we try to initialize host logging.  This
> env var can be used to disable logging.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  docs/envvars.html  | 3 +++
>  src/gallium/drivers/svga/svga_screen.c | 4 +++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/envvars.html b/docs/envvars.html
> index c9733e6..43d3a6c 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other
> options.
>  for details.
>  SVGA_EXTRA_LOGGING - if set, enables extra logging to the
> vmware.log file,
>  such as the OpenGL program's name and command line arguments.
> +SVGA_NO_LOGGING - if set, disables logging to the vmware.log
> file.
> +This is useful when using Valgrind because it otherwise crashes when
> +initializing the host log feature.
>  See the driver code for other, lesser-used variables.
>  
>  
> diff --git a/src/gallium/drivers/svga/svga_screen.c
> b/src/gallium/drivers/svga/svga_screen.c
> index 6cb5a14..8158950 100644
> --- a/src/gallium/drivers/svga/svga_screen.c
> +++ b/src/gallium/drivers/svga/svga_screen.c
> @@ -1134,7 +1134,9 @@ svga_screen_create(struct svga_winsys_screen
> *sws)
>  
> svga_screen_cache_init(svgascreen);
>  
> -   init_logging(screen);
> +   if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == FALSE) {
> +  init_logging(screen);
> +   }
>  
> return screen;
>  error2:

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

[Mesa-dev] [PATCH] llvmpipe: init some vars to NULL to silence MinGW compiler warnings

[Brian Paul]

---
 src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
index 9561c34..90b2be9 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_s3tc.c
@@ -2191,7 +2191,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
*gallivm,
   rgba = LLVMGetUndef(i128_vectype);
 
   for (count = 0; count < n / 4; count++) {
- LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
+ LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;
 
  i4 = lp_build_extract_range(gallivm, i, count * 4, 4);
  j4 = lp_build_extract_range(gallivm, j, count * 4, 4);
@@ -2230,7 +2230,7 @@ lp_build_fetch_s3tc_rgba_aos(struct gallivm_state 
*gallivm,
   rgba = LLVMBuildBitCast(builder, rgba, i8_vectype, "");
}
else {
-  LLVMValueRef colors, codewords, alpha_lo, alpha_hi;
+  LLVMValueRef colors, codewords, alpha_lo = NULL, alpha_hi = NULL;
 
   lp_build_gather_s3tc(gallivm, n, format_desc, , ,
_lo, _hi, base_ptr, offset);
-- 
1.8.5.6

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

[Mesa-dev] [PATCH] svga: add SVGA_NO_LOGGING env var

[Brian Paul]

valgrind crashes when we try to initialize host logging.  This
env var can be used to disable logging.

Cc: mesa-sta...@lists.freedesktop.org
---
 docs/envvars.html  | 3 +++
 src/gallium/drivers/svga/svga_screen.c | 4 +++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/docs/envvars.html b/docs/envvars.html
index c9733e6..43d3a6c 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -338,6 +338,9 @@ See src/mesa/state_tracker/st_debug.c for other options.
 for details.
 SVGA_EXTRA_LOGGING - if set, enables extra logging to the vmware.log file,
 such as the OpenGL program's name and command line arguments.
+SVGA_NO_LOGGING - if set, disables logging to the vmware.log file.
+This is useful when using Valgrind because it otherwise crashes when
+initializing the host log feature.
 See the driver code for other, lesser-used variables.
 
 
diff --git a/src/gallium/drivers/svga/svga_screen.c 
b/src/gallium/drivers/svga/svga_screen.c
index 6cb5a14..8158950 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -1134,7 +1134,9 @@ svga_screen_create(struct svga_winsys_screen *sws)
 
svga_screen_cache_init(svgascreen);
 
-   init_logging(screen);
+   if (debug_get_bool_option("SVGA_NO_LOGGING", FALSE) == FALSE) {
+  init_logging(screen);
+   }
 
return screen;
 error2:
-- 
1.8.5.6

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

Re: [Mesa-dev] [PATCH] util: include missing stdlib header

[Eric Engestrom]

On 2019-05-01 at 08:18, Juan A. Suarez Romero  wrote:
> Fixes scons/mingw building:
> 
> src/util/os_file.c: In function ‘os_read_file’:
> src/util/os_file.c:126:11: error: ‘NULL’ undeclared (first use in this 
> function); did you mean ‘_DLL’?
> return NULL;
>^~~~
>_DLL
> src/util/os_file.c:126:11: note: each undeclared identifier is reported 
> only once for each function it appears in
> 
> Fixes: 316964709e2 ("util: add os_read_file() helper")
> CC: Eric Engestrom 
> ---
>  src/util/os_file.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/util/os_file.h b/src/util/os_file.h
> index 2f97c19ed55..97c42b0aefc 100644
> --- a/src/util/os_file.h
> +++ b/src/util/os_file.h
> @@ -12,6 +12,7 @@
>  extern "C" {
>  #endif
>  
> +#include 

There is no `NULL` in this file, but os_file.c does have it.
It already has the right include though, I just mistakenly put it in the `#if 
linux` block.

I've just sent MR !778 to move the #include a couple lines up:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/778

Thanks for the report! I really need to add a mingw build to the CI :/

>  /*
>   * Read a file.
>   * Returns a char* that the caller must free(), or NULL and sets errno.
> -- 
> 2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109784] rasterizer/archrast/eventmanager.h:58:21: error: ‘EventHandler’ has not been declared

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Engestrom  ---
Closing this autotools issue, as autotools has now been deleted (see
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601).

If you think I may have made a mistake and this issue still needs fixing, feel
free to reopen it :)

-- 
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 101933] autotools: wayland-protocols used even if not found

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Eric Engestrom  ---
Closing this autotools issue, as autotools has now been deleted (see
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601).

If you think I may have made a mistake and this issue still needs fixing, feel
free to reopen it :)

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

[Mesa-dev] [PATCH] radv: do not need to force emit the TCS regs on Vega20

[Samuel Pitoiset]

This chip doesn't need the fixup. This fixes a bunch of
dEQP-VK.tessellation tests and avoid random GPU hangs.

Cc: "19.0" 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_nir_to_llvm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index adf158e30e1..b4a19aa2e5d 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -3691,6 +3691,7 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct 
ac_llvm_compiler *ac_llvm,
ac_init_exec_full_mask();
 
if (ctx.ac.chip_class == GFX9 &&
+   ctx.ac.family != CHIP_VEGA20 &&
shaders[shader_count - 1]->info.stage == MESA_SHADER_TESS_CTRL)
ac_nir_fixup_ls_hs_input_vgprs();
 
-- 
2.21.0

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

[Mesa-dev] [Bug 80848] [dri3] Building mesa fails with dri3 enabled

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #31 from Eric Engestrom  ---
Closing this autotools issue, as autotools has now been deleted (see
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/601).

If you think I may have made a mistake and this issue still needs fixing, feel
free to reopen it :)

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

Re: [Mesa-dev] [PATCH] r600: reset tex array override even when no view bound

[Ilia Mirkin]

On Wed, May 1, 2019 at 12:30 AM Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> If no view is bound we still should reset the override to 0
> and array mode.
>
> This should fix misrendering in firefox WebRender since
> the pbo sampler was removed.
>
> Fixes: 1250383e36 (st/mesa: remove sampler associated with buffer texture in 
> pbo logic)
> ---
>  src/gallium/drivers/r600/r600_state.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index f86764f5220..86c1ca96e0f 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -1839,16 +1839,16 @@ static void r600_emit_sampler_states(struct 
> r600_context *rctx,
>  * filtering between layers.
>  * Don't update TEX_ARRAY_OVERRIDE if we don't have the 
> sampler view.
>  */

Probably want to update this comment... I guess the issue is a
transition of 2D_ARRAY -> nothing -> TBO. The sampler is unset at the
-> nothing transition but the TEX_ARRAY_OVERRIDE isn't reset since
rview is NULL at that point. And then when setting the TBO, the rview
exists, but this logic doesn't get hit since the sampler isn't dirty.

Seems right otherwise, keeping in mind that I know nothing about the HW itself.

> -   if (rview) {
> -   enum pipe_texture_target target = 
> rview->base.texture->target;
> -   if (target == PIPE_TEXTURE_1D_ARRAY ||
> -   target == PIPE_TEXTURE_2D_ARRAY) {
> -   rstate->tex_sampler_words[0] |= 
> S_03C000_TEX_ARRAY_OVERRIDE(1);
> -   texinfo->is_array_sampler[i] = true;
> -   } else {
> -   rstate->tex_sampler_words[0] &= 
> C_03C000_TEX_ARRAY_OVERRIDE;
> -   texinfo->is_array_sampler[i] = false;
> -   }
> +   enum pipe_texture_target target = PIPE_BUFFER;
> +   if (rview)
> +   target = rview->base.texture->target;
> +   if (target == PIPE_TEXTURE_1D_ARRAY ||
> +   target == PIPE_TEXTURE_2D_ARRAY) {
> +   rstate->tex_sampler_words[0] |= 
> S_03C000_TEX_ARRAY_OVERRIDE(1);
> +   texinfo->is_array_sampler[i] = true;
> +   } else {
> +   rstate->tex_sampler_words[0] &= 
> C_03C000_TEX_ARRAY_OVERRIDE;
> +   texinfo->is_array_sampler[i] = false;
> }
>
> radeon_emit(cs, PKT3(PKT3_SET_SAMPLER, 3, 0));
> --
> 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] [Bug 109599] small shadows are not drawn in various games (shadow map bias issue?)

[bugzilla-daemon]

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

--- Comment #27 from tempel.jul...@gmail.com ---
Yey, it seems it is fixed without any drawbacks, as far as I can tell. :)

HotS:
amdvlk:
https://abload.de/img/amdvlkbjjv9.png

radv old:
https://abload.de/img/radvoldl3kd3.png

radv new:
https://abload.de/img/radvnewd8k1o.png



Hitman 2:
amdvlk:
https://abload.de/img/amdvlkbyjub.png

radv old:
https://abload.de/img/radvopjos.png

radv new:
https://abload.de/img/radvnewy2ks5.png


Once again: Thanks big time! :)

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

Re: [Mesa-dev] [PATCH] anv/query: ensure visibility of reset before copying query results

[Lionel Landwerlin]

I've uploaded this MR : 
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/776


Which actually highlights a bigger issue with our queries.

-Lionel

On 01/05/2019 11:58, Lionel Landwerlin wrote:
Experimenting a bit with the visibility of PIPE_CONTROL writes & MI_* 
commands I realized those are not coherent.
Essentially anything written with a PIPE_CONTROL will be visible to 
MI_* commands only after some time.
In my experiment I had to insert 2 MI instructions after the 
PIPE_CONTROL write to actually have the following MI_COPY_MEM_MEM 
command pick up what was written by the pipe control.


So my recommendation would be to always write the availability with 
the same part of the command streamer (PIPE_CONTROL).
So that the sequences of writes to the same location are not subject 
to complicated synchronization rules.


Essentially just make emit_query_availability() take an additional 
boolean and then use it in CmdResetQueryPool().


-Lionel

On 30/04/2019 18:18, Lionel Landwerlin wrote:

Let me check the new tests and see if where the problem is.
Thanks for letting us know!

-Lionel

On 30/04/2019 13:43, Iago Toral Quiroga wrote:

Specifically, vkCmdCopyQueryPoolResults is required to see the effect
of a previous vkCmdResetQueryPool. This may not work currently when
query execution is still on going, as some of the queries may become
available asynchronously after the reset.

Fixes new CTS tests:
dEQP-VK.query_pool.statistics_query.reset_before_copy.*
---

Jason, do you have any better ideas?

  src/intel/vulkan/genX_query.c | 13 +
  1 file changed, 13 insertions(+)

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

index 146435c3f8f..08b013f6351 100644
--- a/src/intel/vulkan/genX_query.c
+++ b/src/intel/vulkan/genX_query.c
@@ -383,6 +383,19 @@ void genX(CmdResetQueryPool)(
 ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
 ANV_FROM_HANDLE(anv_query_pool, pool, queryPool);
  +   /* From the Vulkan spec:
+    *
+    *    "vkCmdCopyQueryPoolResults is guaranteed to see the effect of
+    * previous uses of vkCmdResetQueryPool in the same queue, 
without
+    * any additional synchronization. Thus, the results will 
always

+    * reflect the most recent use of the query."
+    *
+    * So we need to make sure that any on-going queries are 
finished by

+    * the time we emit the reset.
+    */
+   cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
+   genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
+
 for (uint32_t i = 0; i < queryCount; i++) {
    anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), 
sdm) {

   sdm.Address = anv_query_address(pool, firstQuery + i);



___
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] anv/query: ensure visibility of reset before copying query results

[Lionel Landwerlin]

Experimenting a bit with the visibility of PIPE_CONTROL writes & MI_* 
commands I realized those are not coherent.
Essentially anything written with a PIPE_CONTROL will be visible to MI_* 
commands only after some time.
In my experiment I had to insert 2 MI instructions after the 
PIPE_CONTROL write to actually have the following MI_COPY_MEM_MEM 
command pick up what was written by the pipe control.


So my recommendation would be to always write the availability with the 
same part of the command streamer (PIPE_CONTROL).
So that the sequences of writes to the same location are not subject to 
complicated synchronization rules.


Essentially just make emit_query_availability() take an additional 
boolean and then use it in CmdResetQueryPool().


-Lionel

On 30/04/2019 18:18, Lionel Landwerlin wrote:

Let me check the new tests and see if where the problem is.
Thanks for letting us know!

-Lionel

On 30/04/2019 13:43, Iago Toral Quiroga wrote:

Specifically, vkCmdCopyQueryPoolResults is required to see the effect
of a previous vkCmdResetQueryPool. This may not work currently when
query execution is still on going, as some of the queries may become
available asynchronously after the reset.

Fixes new CTS tests:
dEQP-VK.query_pool.statistics_query.reset_before_copy.*
---

Jason, do you have any better ideas?

  src/intel/vulkan/genX_query.c | 13 +
  1 file changed, 13 insertions(+)

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

index 146435c3f8f..08b013f6351 100644
--- a/src/intel/vulkan/genX_query.c
+++ b/src/intel/vulkan/genX_query.c
@@ -383,6 +383,19 @@ void genX(CmdResetQueryPool)(
 ANV_FROM_HANDLE(anv_cmd_buffer, cmd_buffer, commandBuffer);
 ANV_FROM_HANDLE(anv_query_pool, pool, queryPool);
  +   /* From the Vulkan spec:
+    *
+    *    "vkCmdCopyQueryPoolResults is guaranteed to see the effect of
+    * previous uses of vkCmdResetQueryPool in the same queue, 
without

+    * any additional synchronization. Thus, the results will always
+    * reflect the most recent use of the query."
+    *
+    * So we need to make sure that any on-going queries are finished by
+    * the time we emit the reset.
+    */
+   cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
+   genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
+
 for (uint32_t i = 0; i < queryCount; i++) {
    anv_batch_emit(_buffer->batch, GENX(MI_STORE_DATA_IMM), 
sdm) {

   sdm.Address = anv_query_address(pool, firstQuery + i);



___
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 109599] small shadows are not drawn in various games (shadow map bias issue?)

[bugzilla-daemon]

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

--- Comment #26 from Samuel Pitoiset  ---
Created attachment 144120
  --> https://bugs.freedesktop.org/attachment.cgi?id=144120=edit
bias change

Can you try with this change applied?

-- 
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/3] mesa: rework error handling in glDrawBuffers

[Mathias Fröhlich]

Hi Marek,

On Tuesday, 30 April 2019 01:10:42 CEST Marek Olšák wrote:
> I'm adding this hunk, which makes the test pass:
> 
> diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> index 1ac0d5d0798..a46599a2872 100644
> --- a/src/mesa/main/buffers.c
> +++ b/src/mesa/main/buffers.c
> @@ -485,7 +485,9 @@ draw_buffers(struct gl_context *ctx, struct
> gl_framebuffer *fb, GLsizei n,
>   } else if (buffers[output] == GL_FRONT ||
>  buffers[output] == GL_LEFT ||
>  buffers[output] == GL_RIGHT ||
> -buffers[output] == GL_FRONT_AND_BACK) {
> +buffers[output] == GL_FRONT_AND_BACK ||
> +(buffers[output] == GL_BACK &&
> + _mesa_is_desktop_gl(ctx))) {
>  _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
>  caller, _mesa_enum_to_string(buffers[output]));
>  return;

If we finally go that route by this series then this patch looks good to me.
Lets see if we need a better overall fix for pbuffers.

best
Mathias

> 
> Marek
> 
> On Sat, Apr 27, 2019 at 10:23 AM Mathias Fröhlich 
> wrote:
> 
> > Hi Marek,
> >
> > one comment/failure inline:
> >
> > On Saturday, 27 April 2019 05:31:45 CEST Marek Olšák wrote:
> > > From: Marek Olšák 
> > >
> > > It's needed by the next pbuffer fix, which changes the behavior of
> > > draw_buffer_enum_to_bitmask, so it can't be used to help with error
> > > checking.
> > > ---
> > >  src/mesa/main/buffers.c | 53 ++---
> > >  1 file changed, 29 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/src/mesa/main/buffers.c b/src/mesa/main/buffers.c
> > > index d98c015bb24..2148fa1316c 100644
> > > --- a/src/mesa/main/buffers.c
> > > +++ b/src/mesa/main/buffers.c
> > > @@ -430,65 +430,70 @@ draw_buffers(struct gl_context *ctx, struct
> > gl_framebuffer *fb, GLsizei n,
> > >   _mesa_error(ctx, GL_INVALID_OPERATION, "%s(invalid buffers)",
> > caller);
> > >   return;
> > >}
> > > }
> > >
> > > supportedMask = supported_buffer_bitmask(ctx, fb);
> > > usedBufferMask = 0x0;
> > >
> > > /* complicated error checking... */
> > > for (output = 0; output < n; output++) {
> > > -  destMask[output] = draw_buffer_enum_to_bitmask(ctx,
> > buffers[output]);
> > > -
> > >if (!no_error) {
> > > - /* From the OpenGL 3.0 specification, page 258:
> > > -  * "Each buffer listed in bufs must be one of the values from
> > tables
> > > -  *  4.5 or 4.6.  Otherwise, an INVALID_ENUM error is generated.
> > > -  */
> > > - if (destMask[output] == BAD_MASK) {
> > > -_mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer %s)",
> > > -caller, _mesa_enum_to_string(buffers[output]));
> > > -return;
> > > - }
> > > -
> > >   /* From the OpenGL 4.5 specification, page 493 (page 515 of
> > the PDF)
> > >* "An INVALID_ENUM error is generated if any value in bufs is
> > FRONT,
> > >* LEFT, RIGHT, or FRONT_AND_BACK . This restriction applies
> > to both
> > >* the default framebuffer and framebuffer objects, and exists
> > because
> > >* these constants may themselves refer to multiple buffers,
> > as shown
> > >* in table 17.4."
> > >*
> > > -  * And on page 492 (page 514 of the PDF):
> > > +  * From the OpenGL 4.5 specification, page 492 (page 514 of
> > the PDF):
> > >* "If the default framebuffer is affected, then each of the
> > constants
> > >* must be one of the values listed in table 17.6 or the
> > special value
> > >* BACK. When BACK is used, n must be 1 and color values are
> > written
> > >* into the left buffer for single-buffered contexts, or into
> > the back
> > >* left buffer for double-buffered contexts."
> > >*
> > >* Note "special value BACK". GL_BACK also refers to multiple
> > buffers,
> > >* but it is consider a special case here. This is a change on
> > 4.5.
> > >* For OpenGL 4.x we check that behaviour. For any previous
> > version we
> > >* keep considering it wrong (as INVALID_ENUM).
> > >*/
> > > - if (util_bitcount(destMask[output]) > 1) {
> > > -if (_mesa_is_winsys_fbo(fb) && ctx->Version >= 40 &&
> > > -buffers[output] == GL_BACK) {
> > > -   if (n != 1) {
> > > -  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(with
> > GL_BACK n must be 1)",
> > > -  caller);
> > > -  return;
> > > -   }
> > > -} else {
> > > -   _mesa_error(ctx, GL_INVALID_ENUM, "%s(invalid buffer
> > %s)",
> > > -   caller,
> > _mesa_enum_to_string(buffers[output]));
> > 

Re: [Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

[Mathias Fröhlich]

Hi Marek, Emil,

On Tuesday, 30 April 2019 15:36:08 CEST Emil Velikov wrote:
> On Mon, 29 Apr 2019 at 22:50, Marek Olšák  wrote:
> >
> > On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen  wrote:
> >>
> >> On Sat, 27 Apr 2019 09:38:27 -0400
> >> Marek Olšák  wrote:
> >>
> >> > Those are all valid reasons, but I don't wanna expose swrast for AMD's
> >> > customers.
> >>
> >> Hi Marek,
> >>
> >> is you objection that you will never want to see any software renderer
> >> in the list, or that you don't want to see a software renderer only as
> >> long as it doesn't actually work?
> >>
> >> Why do you not "wanna expose swrast for AMD's customers"?
> >>
> >> Are you talking about swrast specifically or all the software renderers
> >> in Mesa?
> >>
> >> I'm not an AMD customer if you mean someone paying for support rather
> >> than just buying their hardware, so I cannot speak for them. However, I
> >> would be very happy to have a software renderer available to be picked
> >> the same way as any other hardware renderer, so that I can use it in
> >> graphical test suites (a point from Anholt) testing also the EGL glue
> >> in addition to the pixels produced.
> >>
> >> The thing will be run on boxes with AMD GPUs, and in those cases there
> >> must be a way to *not* use the AMD GPU, and use the software renderer
> >> instead when wanted. Not by environment variables or anything hacky
> >> like that, but by deliberately choosing the software renderer in the
> >> program. It will need an EGLSurface too.
> >>
> >> How would this be made to work in the future?
> >
> >
> > A software renderer could be exposed by adding a new EGL function on top of 
> > EGL_EXT_device_base, for example:
> >
> > // EGL_MESA_device_software
> >
> > EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice);
> >
> >
> > You would get the swrast device from that function instead of 
> > eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps 
> > everything else the same.
> >
> IMHO the current EGL_MESA_device_software approach is perfectly valid.
> The Query API provides the devices and one can query their
> capabilities/device extensions.

I agree with that. Well to repeat myself.

For me there is also a basic consistency argument behind.
So, Marek, you propose that the swrast device should only show
up when there is no other device. That means swrast qualifies in
principle as a 'device'.
But if there is an other 'device' then swrast is not a 'device' anymore?
I can not quite understand that from the outside.
Means if swrast qualifies as a device in one configuration if should also
be a device in any other configuration.

There is also a next problem. I can understand that AMD wants to avoid
for a customer to grab the swrast device by accident and get worse performance.
But where do you draw the line then? Do you want to block out a drm device
that comes up as a administration console device in such a typical compute
cluster when there is an AMD device available? I mean for the same reason,
where you want to avoid an application to grab the matrox device on that board
that is put there for some sort of framebuffer console? If does AMD then 
negotiate with
the Intel guys if their chip qualifies as 'device' in this sense?
Do you then maintain a list of 'hardware devices' that qualify for a 'real 
device' then?

As I said I can understand that the first device should be a GPU hardware 
backed device
when possible to catch those simple example programs that only grab the first 
device.
And I am still in favor of sorting this device list in a different way than it 
is today.

Looking at that, it's probably a bit more educative to have the swrast device 
there in
any case. That makes the average developer making use of that api aware that he 
has to
look a bit closer at the devices before blindly using the first one. This 
awareness makes
the administrative console device case being handled in the using application. 
That in turn
will probably lead to the final effect that I would like to see as a GPU 
vendor, that is
applications grab a GPU backed device and users are happy with the performance.

As Emil mentions, you can find out if you grabed a swrast device or not.
There is the case that your device is DRM backed, or swrast, or nothing - then 
its nvidia closed.

> As far as I can see you have valid concerns:
>  - HW devices should be the first/default
>  - the SW device should work, if exposed
>  - one may want to omit the SW one all together
> 
> At the same time:
>  - the device_base extension is explicit that at least one device must
> be present
>  - manipulating the EGL client extension string, before we determine
> the driver is a PITA
> 
> How about:
>  - whip a quick (admittedly gross) hack that makes SW work
>  - flip the order so SW is always the last one in the list
>  - add a hack that disables SW all-together?

I would vote for reordering the device list to have swrast in the last position.

> 
> The first two 

[Mesa-dev] [PATCH] util: include missing stdlib header

[Juan A. Suarez Romero]

Fixes scons/mingw building:

src/util/os_file.c: In function ‘os_read_file’:
src/util/os_file.c:126:11: error: ‘NULL’ undeclared (first use in this 
function); did you mean ‘_DLL’?
return NULL;
   ^~~~
   _DLL
src/util/os_file.c:126:11: note: each undeclared identifier is reported only 
once for each function it appears in

Fixes: 316964709e2 ("util: add os_read_file() helper")
CC: Eric Engestrom 
---
 src/util/os_file.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/os_file.h b/src/util/os_file.h
index 2f97c19ed55..97c42b0aefc 100644
--- a/src/util/os_file.h
+++ b/src/util/os_file.h
@@ -12,6 +12,7 @@
 extern "C" {
 #endif
 
+#include 
 /*
  * Read a file.
  * Returns a char* that the caller must free(), or NULL and sets errno.
-- 
2.20.1

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