Re: [Mesa-dev] [PATCH 1/3] vbo: Reestablish VAO limit checking on imm VAOs.

[Mathias Fröhlich]

Hi Christian,

On Sunday, 3 June 2018 20:08:14 CEST Christian Gmeiner wrote:
> Am Sa., 2. Juni 2018 um 08:53 Uhr schrieb :
> >
> > From: Mathias Fröhlich 
> >
> > Bail out with out of memory, when the required stride exceeds the
> > maximum possible stride as stored in Const.MaxVertexAttribStride.
> > Etnaviv can only handle less than the OpenGL standard mandated
> > minimum of 2048. For this one, at least give some 'resource
> > exhaustion error' to the application.
> > The virgl driver provides 0 for Const.MaxVertexAttribStride
> > as it may not be able to query the relevant informatition from the
> > underlying OpenGL stack. In this case we just make the assumption
> > that the underlying OpenGL stack is able to cope with then commonly
> > seen small strides. Note that this is the same than what applications
> > had to do before the queries to GL_MAX_VERTEX_ATTRIB_STRIDE, they had to
> > hope for the best that the driver and hardware can safely handle the
> > used stride values.
> >
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >  src/mesa/vbo/vbo_exec_draw.c | 24 +++-
> >  1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
> > index 8d74725db3..0ab9a0d3ea 100644
> > --- a/src/mesa/vbo/vbo_exec_draw.c
> > +++ b/src/mesa/vbo/vbo_exec_draw.c
> > @@ -177,6 +177,29 @@ vbo_exec_bind_arrays(struct gl_context *ctx)
> > struct gl_vertex_array_object *vao = vbo->VAO;
> > struct vbo_exec_context *exec = >exec;
> >
> > +   const GLuint stride = exec->vtx.vertex_size*sizeof(GLfloat);
> > +
> > +   /* Bail out with out of memory, when the required stride exceeds the
> > +* maximum possible stride.
> > +* Etnaviv can only handle less than the OpenGL standard mandated
> > +* minimum of 2048. For this one, at least give some 'resource
> > +* exhaustion error' to the application.
> > +* The virgl driver provides 0 for Const.MaxVertexAttribStride
> > +* as it may not be able to query the relevant informatition from the
> > +* underlying OpenGL stack. In this case we just make the assumption
> > +* that the underlying OpenGL stack is able to cope with then commonly
> > +* seen small strides. Note that this is the same than what applications
> > +* had to do before the queries to GL_MAX_VERTEX_ATTRIB_STRIDE, they 
> > had to
> > +* hope for the best that the driver and hardware can safely handle the
> > +* used stride values.
> > +*/
> 
> Do we really need to duplicate the commit message text here? If the driver 
> fetch
> up e.g. by supporting other/newer GPUs with a more sane limit the patch author
> needs to update this comment too.

No, we do not need to duplicate that.
What I wanted to do here initially is to describe which cases the code below is
supposed to handle. Then, to back up why these cases are needed name the driver
backends that currently need that behavior.
Still, I would consider virgil something special as it may not be able to know 
the limit.

So, how about:

  /* Bail out with out of memory, when the required stride exceeds the
   * maximum possible stride.
   * Note that mesa currently has drivers that can only handle less than
   * the OpenGL standard mandated minimum of 2048. For these, at least give
   * some 'resource exhaustion error' to the application.
   * The virgl driver provides 0 for Const.MaxVertexAttribStride

*/


best

Mathias




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

[Mesa-dev] [Bug 106594] [regression, apitrace, bisected] Prison Architect rendered unplayable by multicoloured flickering triangles and overlayed triangles when performing certain actions

[bugzilla-daemon]

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

Kai  changed:

   What|Removed |Added

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

--- Comment #10 from Kai  ---
Fixed by the following commit on master:
> commit 1ac4439d6278e6c5f9da5499bbc50362f0c6759b
> Author: Mathias Fröhlich 
> Date:   Fri Jun 1 19:10:08 2018 +0200
> 
> mesa: Make sure that imm draws are flushed before other draws execute.
> 
> The recent patch
> 
> mesa: Remove FLUSH_VERTICES from VAO state changes.
> 
> Pending draw calls on immediate mode or display list calls do
> not depend on changes of the VAO state. So, remove calls to
> FLUSH_VERTICES and flag _NEW_ARRAY as appropriate.
> 
> uncovered a problem that non immediate mode draw calls do only
> flush outstanding immediate mode draws if FLUSH_UPDATE_CURRENT
> is set in ctx->Driver.NeedFlush.
> In that case, due to the sequence of _mesa_set_draw_vao commands
> we could end up with the VAO from the FLUSH_VERTICES call set
> into gl_context::Array._DrawVAO when the array draw is executed.
> So the change pulls FLUSH_CURRENT out of _mesa_validate_* calls
> into the array draw calls being validated.
> The change introduces a new macro FLUSH_FOR_DRAW beside FLUSH_VERTICES
> and FLUSH_CURRENT that flushes on changed current attributes as well
> as on outstanding immediate mode draw calls. Use FLUSH_FOR_DRAW
> in the non immediate mode draw code paths.
> 
> Reviewed-by: Marek Olšák 
> Tested-by: Kai Wasserbäch 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106594
> Signed-off-by: Mathias Fröhlich 

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

[bugzilla-daemon]

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

Bug 106594 Summary: [regression,apitrace,bisected] Prison Architect rendered 
unplayable by multicoloured flickering triangles and overlayed triangles when 
performing certain actions
https://bugs.freedesktop.org/show_bug.cgi?id=106594

   What|Removed |Added

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

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

Re: [Mesa-dev] [PATCH] mesa: Make sure that imm draws are flushed before other draws execute.

[Mathias Fröhlich]

Hi,

That's pushed now!
Thanks for the review and testing!

best

Mathias



On Saturday, 2 June 2018 14:57:48 CEST Kai Wasserbäch wrote:
> Hey Mathias,
> mathias.froehl...@gmx.net wrote on 02.06.2018 08:51:
> > The below patch fixes a recently introduced failure of my VAO rework.
> > I could finally reproduce the problem using the provided apitrace
> > (thanks Kai for the hint with the lower left corner).
> 
> yw, thanks for looking into this!
> 
> > The change is slightly different than what I put initially into the
> > bugreport.
> > The patch survived piglit quick and dEQP in radeonsi and did not
> > introduce regressions to the base version with intels CI system.
> > 
> > Please review!
> 
> I just confirmed that this version of the patch still resolves the bug with 
> the
> following graphics stack (fully updated Debian testing as a base):
> - GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
> - Mesa: Git:master/8841c2cda5 + 
> 
> - libdrm: 2.4.92-1
> - LLVM: SVN:trunk/r333817 (7.0 devel)
> - X.Org: 2:1.19.6-1
> - Linux: 4.16.13
> - Firmware (firmware-amd-graphics): 20170823-1
> - libclc: Git:master/a2118d58fc
> - DDX (xserver-xorg-video-amdgpu): 18.0.1-1
> Therefore you can (still) have my
>   Tested-by: Kai Wasserbäch 
> 
> Cheers,
> Kai
> 




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

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Dave Airlie]

On 5 June 2018 at 03:27, Gurchetan Singh  wrote:
> I sent out a patch that adds capability bits to this struct, and the
> first bit is the tgsi invariant capability.  It's dependent on this
> patch to apply correctly to master.

Oops I dropped the ball there,I saw the renderer patches had landed
and assumed the mesa side had also landed.

I've pushed the renderer and mesa patches now.

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

[Mesa-dev] [PATCH] virgl: enable ARB_gpu_shader_fp64

[Dave Airlie]

From: Dave Airlie 

This enables ARB_gpu_shader_fp64 if the host provides it.
---
 src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index e8d1c751779..2ba9708ebac 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -213,6 +213,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
   return vscreen->caps.caps.v1.bset.transform_feedback_overflow_query;
case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
   return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
+   case PIPE_CAP_DOUBLES:
+  return vscreen->caps.caps.v1.bset.has_fp64;
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
@@ -268,7 +270,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_POLYGON_MODE_FILL_RECTANGLE:
case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
case PIPE_CAP_TGSI_BALLOT:
-   case PIPE_CAP_DOUBLES:
case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
case PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTION:
-- 
2.14.3

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

[Mesa-dev] [PATCH] intel/blorp: Don't vertex fetch directly from clear values

[Jason Ekstrand]

On gen8+, we have to VF cache flush whenever a vertex binding aliases a
previous binding at the same index modulo 4GiB.  We deal with this in
Vulkan by ensuring that vertex buffers and the dynamic state (from which
BLORP pulls its vertex buffers) are in the same 4GiB region of the
address space.  That doesn't work if we're reading clear colors with the
VF unit.  In order to work around this we switch to using MI commands to
copy the clear value into the vertex buffer we allocate for the normal
constant data.

Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/blorp/blorp_genX_exec.h | 66 +--
 1 file changed, 27 insertions(+), 39 deletions(-)

diff --git a/src/intel/blorp/blorp_genX_exec.h 
b/src/intel/blorp/blorp_genX_exec.h
index 446743b5910..323ca9de1e5 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blorp/blorp_genX_exec.h
@@ -200,6 +200,14 @@ emit_urb_config(struct blorp_batch *batch,
blorp_emit_urb_config(batch, vs_entry_size, sf_entry_size);
 }
 
+#if GEN_GEN >= 7
+static void
+blorp_emit_memcpy(struct blorp_batch *batch,
+  struct blorp_address dst,
+  struct blorp_address src,
+  uint32_t size);
+#endif
+
 static void
 blorp_emit_vertex_data(struct blorp_batch *batch,
const struct blorp_params *params,
@@ -298,6 +306,7 @@ blorp_emit_vertex_buffers(struct blorp_batch *batch,
   const struct blorp_params *params)
 {
struct GENX(VERTEX_BUFFER_STATE) vb[3];
+   uint32_t num_vbs = 2;
memset(vb, 0, sizeof(vb));
 
struct blorp_address addr;
@@ -308,13 +317,20 @@ blorp_emit_vertex_buffers(struct blorp_batch *batch,
blorp_emit_input_varying_data(batch, params, , );
blorp_fill_vertex_buffer_state(batch, vb, 1, addr, size, 0);
 
-   uint32_t num_vbs = 2;
+   /* The clear color value starts 16B into the input VB */
+   struct blorp_address clear_color_input_addr = addr;
+   clear_color_input_addr.offset += 16;
+
if (params->dst_clear_color_as_input) {
+#if GEN_GEN >= 7
   const unsigned clear_color_size =
  GEN_GEN < 10 ? batch->blorp->isl_dev->ss.clear_value_size : 4 * 4;
-  blorp_fill_vertex_buffer_state(batch, vb, num_vbs++,
- params->dst.clear_color_addr,
- clear_color_size, 0);
+  blorp_emit_memcpy(batch, clear_color_input_addr,
+params->dst.clear_color_addr,
+clear_color_size);
+#else
+  unreachable("MCS partial resolve is not a thing on SNB and earlier");
+#endif
}
 
const unsigned num_dwords = 1 + num_vbs * GENX(VERTEX_BUFFER_STATE_length);
@@ -449,49 +465,21 @@ blorp_emit_vertex_elements(struct blorp_batch *batch,
};
slot++;
 
-   if (params->dst_clear_color_as_input) {
-  /* If the caller wants the destination indirect clear color, redirect
-   * to vertex buffer 2 where we stored it earlier.  The only users of
-   * an indirect clear color source have that as their only vertex
-   * attribute.
-   */
-  assert(num_varyings == 1);
+   for (unsigned i = 0; i < num_varyings; ++i) {
   ve[slot] = (struct GENX(VERTEX_ELEMENT_STATE)) {
- .VertexBufferIndex = 2,
+ .VertexBufferIndex = 1,
  .Valid = true,
- .SourceElementOffset = 0,
- .Component0Control = VFCOMP_STORE_SRC,
-#if GEN_GEN >= 9
  .SourceElementFormat = ISL_FORMAT_R32G32B32A32_FLOAT,
+ .SourceElementOffset = 16 + i * 4 * sizeof(float),
+ .Component0Control = VFCOMP_STORE_SRC,
  .Component1Control = VFCOMP_STORE_SRC,
  .Component2Control = VFCOMP_STORE_SRC,
  .Component3Control = VFCOMP_STORE_SRC,
-#else
- /* Clear colors on gen7-8 are for bits out of one dword */
- .SourceElementFormat = ISL_FORMAT_R32_FLOAT,
- .Component1Control = VFCOMP_STORE_0,
- .Component2Control = VFCOMP_STORE_0,
- .Component3Control = VFCOMP_STORE_0,
+#if GEN_GEN <= 5
+ .DestinationElementOffset = slot * 4,
 #endif
   };
   slot++;
-   } else {
-  for (unsigned i = 0; i < num_varyings; ++i) {
- ve[slot] = (struct GENX(VERTEX_ELEMENT_STATE)) {
-.VertexBufferIndex = 1,
-.Valid = true,
-.SourceElementFormat = ISL_FORMAT_R32G32B32A32_FLOAT,
-.SourceElementOffset = 16 + i * 4 * sizeof(float),
-.Component0Control = VFCOMP_STORE_SRC,
-.Component1Control = VFCOMP_STORE_SRC,
-.Component2Control = VFCOMP_STORE_SRC,
-.Component3Control = VFCOMP_STORE_SRC,
-#if GEN_GEN <= 5
-.DestinationElementOffset = slot * 4,
-#endif
- };
- slot++;
-  }
}
 
const unsigned num_dwords =
@@ -1244,7 +1232,7 @@ blorp_emit_pipeline(struct blorp_batch *batch,
 
 #endif /* GEN_GEN >= 6 */
 
-#if GEN_GEN >= 7 && GEN_GEN < 10
+#if GEN_GEN >= 7
 static void
 

Re: [Mesa-dev] [PATCH 000/129] AMD Fixups for the deref patches.

[Jason Ekstrand]

I have updated my wip/nir-deref-instr branch with the recommended changes.
I haven't actually squashed any fixup commits yet because I want to make
sure everyone is happy with them before I do.

On Sun, Jun 3, 2018 at 4:10 PM, Bas Nieuwenhuizen 
wrote:

> These are some fixes for v4 of Jasons deref instruction series.
>
> Furthermore patches 107-119:
>
> radv: Remove image_var stores.
> radv: Use deref instructions for tex derefs in meta shaders.
> radeonsi: Add deref support to the nir scan pass.
> ac/nir: Add deref interp support.
> ac/nir: Add shared atomic deref instr support.
> radv: Gather info for deref instr based load/store.
> ac/nir: Add deref based var loads/stores.
> radv: Add shader info support for image deref instructions.
> ac/nir: Add deref support to image intrinsics.
> ac/nir: Implement derefs for integer gather4 lowering.
> ac/nir: Support deref instructions in tex instructions.
> ac/nir: Support deref instructions in get_sampler_desc.
> ac/nir: Implement the deref instr for shared memory.
>
>
> have to be moved to directly before patch 54
> ("anv/pipeline: Do less deref instruction lowering").
>
> With that the series has no regressions and should be fully
> bisectable without regressions on radv.
> ___
> 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 038.1/129] FIXUP: nir: Support deref instructions in opt_undef

[Jason Ekstrand]

LGTM

On Sun, Jun 3, 2018 at 4:10 PM, Bas Nieuwenhuizen 
wrote:

> ---
>  src/compiler/nir/nir_opt_undef.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_undef.c b/src/compiler/nir/nir_opt_
> undef.c
> index 1439ca9c165..e42a9af2bdf 100644
> --- a/src/compiler/nir/nir_opt_undef.c
> +++ b/src/compiler/nir/nir_opt_undef.c
> @@ -107,20 +107,24 @@ opt_undef_vecN(nir_builder *b, nir_alu_instr *alu)
>  static bool
>  opt_undef_store(nir_intrinsic_instr *intrin)
>  {
> +   int arg_index;
> switch (intrin->intrinsic) {
> case nir_intrinsic_store_deref:
> +  arg_index = 1;
> +  break;
> case nir_intrinsic_store_var:
> case nir_intrinsic_store_output:
> case nir_intrinsic_store_per_vertex_output:
> case nir_intrinsic_store_ssbo:
> case nir_intrinsic_store_shared:
> +  arg_index =  0;
>break;
> default:
>return false;
> }
>
> -   if (!intrin->src[0].is_ssa ||
> -   intrin->src[0].ssa->parent_instr->type !=
> nir_instr_type_ssa_undef)
> +   if (!intrin->src[arg_index].is_ssa ||
> +   intrin->src[arg_index].ssa->parent_instr->type !=
> nir_instr_type_ssa_undef)
>return false;
>
> nir_instr_remove(>instr);
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: Do not hardcode fast clear formats.

[Dave Airlie]

On 5 June 2018 at 08:53, Bas Nieuwenhuizen  wrote:
> except for the odd one out.
>
> This should support many more formats.

I suppose we should have done this back at the start, but I think I was lazy.

Looks like a good idea, assuming it doesn't break anything in CTS,

Reviewed-by: Dave Airlie 

> ---
>  src/amd/vulkan/radv_formats.c | 253 ++
>  1 file changed, 73 insertions(+), 180 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index aafe331f27d..50ec904d514 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -880,194 +880,87 @@ bool radv_format_pack_clear_color(VkFormat format,
>   uint32_t clear_vals[2],
>   VkClearColorValue *value)
>  {
> -   uint8_t r = 0, g = 0, b = 0, a = 0;
> const struct vk_format_description *desc = 
> vk_format_description(format);
>
> -   if (vk_format_get_component_bits(format, VK_FORMAT_COLORSPACE_RGB, 0) 
> <= 8) {
> -   if (desc->colorspace == VK_FORMAT_COLORSPACE_RGB) {
> -   r = float_to_ubyte(value->float32[0]);
> -   g = float_to_ubyte(value->float32[1]);
> -   b = float_to_ubyte(value->float32[2]);
> -   a = float_to_ubyte(value->float32[3]);
> -   } else if (desc->colorspace == VK_FORMAT_COLORSPACE_SRGB) {
> -   r = 
> util_format_linear_float_to_srgb_8unorm(value->float32[0]);
> -   g = 
> util_format_linear_float_to_srgb_8unorm(value->float32[1]);
> -   b = 
> util_format_linear_float_to_srgb_8unorm(value->float32[2]);
> -   a = float_to_ubyte(value->float32[3]);
> -   }
> -   }
> -   switch (format) {
> -   case VK_FORMAT_R8_UNORM:
> -   case VK_FORMAT_R8_SRGB:
> -   clear_vals[0] = r;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8_UNORM:
> -   case VK_FORMAT_R8G8_SRGB:
> -   clear_vals[0] = r | g << 8;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8B8A8_SRGB:
> -   case VK_FORMAT_R8G8B8A8_UNORM:
> -   clear_vals[0] = r | g << 8 | b << 16 | a << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_B8G8R8A8_SRGB:
> -   case VK_FORMAT_B8G8R8A8_UNORM:
> -   clear_vals[0] = b | g << 8 | r << 16 | a << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_A8B8G8R8_UNORM_PACK32:
> -   case VK_FORMAT_A8B8G8R8_SRGB_PACK32:
> -   clear_vals[0] = r | g << 8 | b << 16 | a << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8_UINT:
> -   clear_vals[0] = value->uint32[0] & 0xff;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8_SINT:
> -   clear_vals[0] = value->int32[0] & 0xff;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R16_UINT:
> -   clear_vals[0] = value->uint32[0] & 0x;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8_UINT:
> -   clear_vals[0] = value->uint32[0] & 0xff;
> -   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8_SINT:
> -   clear_vals[0] = value->int32[0] & 0xff;
> -   clear_vals[0] |= (value->int32[1] & 0xff) << 8;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8B8A8_UINT:
> -   clear_vals[0] = value->uint32[0] & 0xff;
> -   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
> -   clear_vals[0] |= (value->uint32[2] & 0xff) << 16;
> -   clear_vals[0] |= (value->uint32[3] & 0xff) << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R8G8B8A8_SINT:
> -   clear_vals[0] = value->int32[0] & 0xff;
> -   clear_vals[0] |= (value->int32[1] & 0xff) << 8;
> -   clear_vals[0] |= (value->int32[2] & 0xff) << 16;
> -   clear_vals[0] |= (value->int32[3] & 0xff) << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_A8B8G8R8_UINT_PACK32:
> -   clear_vals[0] = value->uint32[0] & 0xff;
> -   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
> -   clear_vals[0] |= (value->uint32[2] & 0xff) << 16;
> -   clear_vals[0] |= (value->uint32[3] & 0xff) << 24;
> -   clear_vals[1] = 0;
> -   break;
> -   case VK_FORMAT_R16G16_UINT:
> -   clear_vals[0] = value->uint32[0] & 0x;
> -   clear_vals[0] 

[Mesa-dev] [Bug 106778] Files missing from tarball - intel_sanitize_gpu.*

[bugzilla-daemon]

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

Stuart Young  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |scott.d.phill...@intel.com
   |org |

--- Comment #3 from Stuart Young  ---
Scott, you worked on bringing this code in to the mesa tree (based on the
commit log). Are you able to update src/intel/Makefile.tools.am with the
necessary build instructions so it can be built using Autotools?

If so, please add this line to allow the scripts to pick it up:
Fixes: cc41603d6da4552f0aaf "intel/tools: new intel_sanitize_gpu tool"

If not, I'll submit a patch that simply adds these files to the EXTRA_DIST
field in src/intel/Makefile.tools.am to solve this for the moment.

-- 
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 shader-db 1/2] intel_stub: Wrap mmap64.

[Ian Romanick]

This fixes the problem I encountered.  Thanks!

Series is

Reviewed-by: Ian Romanick 

On 06/04/2018 04:26 PM, Kenneth Graunke wrote:
> Otherwise our fake GEM bo mappings don't work.
> ---
>  intel_stub.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/intel_stub.c b/intel_stub.c
> index ab046e5..a3316b1 100644
> --- a/intel_stub.c
> +++ b/intel_stub.c
> @@ -39,6 +39,8 @@
>  
>  static void *(*libc_mmap)(void *addr, size_t len, int prot, int flags,
>int fildes, off_t off);
> +static void *(*libc_mmap64)(void *addr, size_t len, int prot, int flags,
> +int fildes, off_t off);
>  static int (*libc_open)(const char *pathname, int flags, mode_t mode);
>  static int (*libc_open64)(const char *pathname, int flags, mode_t mode);
>  static int (*libc_close)(int fd);
> @@ -208,6 +210,19 @@ mmap(void *addr, size_t len, int prot, int flags,
>  }
>  }
>  
> +__attribute__ ((visibility ("default"))) void *
> +mmap64(void *addr, size_t len, int prot, int flags,
> +   int fildes, off_t off)
> +{
> +if (fildes == drm_fd) {
> +return libc_mmap64(NULL, len, prot, flags | MAP_ANONYMOUS,
> +   -1, 0);
> +} else {
> +return libc_mmap64(addr, len, prot, flags, fildes, off);
> +}
> +}
> +
> +
>  __attribute__ ((visibility ("default"))) ssize_t
>  readlink(const char *pathname, char *buf, size_t bufsiz)
>  {
> @@ -305,5 +320,6 @@ init(void)
>   libc__fxstat64 = dlsym(RTLD_NEXT, "__fxstat64");
>   libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
>   libc_mmap = dlsym(RTLD_NEXT, "mmap");
> + libc_mmap64 = dlsym(RTLD_NEXT, "mmap64");
>   libc_readlink = dlsym(RTLD_NEXT, "readlink");
>  }
> 

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

[Mesa-dev] [PATCH shader-db 1/2] intel_stub: Wrap mmap64.

[Kenneth Graunke]

Otherwise our fake GEM bo mappings don't work.
---
 intel_stub.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/intel_stub.c b/intel_stub.c
index ab046e5..a3316b1 100644
--- a/intel_stub.c
+++ b/intel_stub.c
@@ -39,6 +39,8 @@
 
 static void *(*libc_mmap)(void *addr, size_t len, int prot, int flags,
   int fildes, off_t off);
+static void *(*libc_mmap64)(void *addr, size_t len, int prot, int flags,
+int fildes, off_t off);
 static int (*libc_open)(const char *pathname, int flags, mode_t mode);
 static int (*libc_open64)(const char *pathname, int flags, mode_t mode);
 static int (*libc_close)(int fd);
@@ -208,6 +210,19 @@ mmap(void *addr, size_t len, int prot, int flags,
 }
 }
 
+__attribute__ ((visibility ("default"))) void *
+mmap64(void *addr, size_t len, int prot, int flags,
+   int fildes, off_t off)
+{
+if (fildes == drm_fd) {
+return libc_mmap64(NULL, len, prot, flags | MAP_ANONYMOUS,
+   -1, 0);
+} else {
+return libc_mmap64(addr, len, prot, flags, fildes, off);
+}
+}
+
+
 __attribute__ ((visibility ("default"))) ssize_t
 readlink(const char *pathname, char *buf, size_t bufsiz)
 {
@@ -305,5 +320,6 @@ init(void)
libc__fxstat64 = dlsym(RTLD_NEXT, "__fxstat64");
libc_ioctl = dlsym(RTLD_NEXT, "ioctl");
libc_mmap = dlsym(RTLD_NEXT, "mmap");
+   libc_mmap64 = dlsym(RTLD_NEXT, "mmap64");
libc_readlink = dlsym(RTLD_NEXT, "readlink");
 }
-- 
2.17.0

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

[Mesa-dev] [PATCH shader-db 2/2] intel_stub: Make intel_run wrapper script set -o i965.

[Kenneth Graunke]

I don't think anybody is using this script with any other driver.

Also take a $DEBUGGER variable so you can do:

   $ DEBUGGER='gdb -q --args' ./intel_run shaders
---
 intel_run | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/intel_run b/intel_run
index 5a162f8..ad9986d 100755
--- a/intel_run
+++ b/intel_run
@@ -1,5 +1,5 @@
 #!/bin/bash
 # -*- mode: sh -*-
 
-LD_PRELOAD=${PWD}/intel_stub.so${LD_PRELOAD:+:${LD_PRELOAD}} \
- exec ./run $@
+export LD_PRELOAD=${PWD}/intel_stub.so${LD_PRELOAD:+:${LD_PRELOAD}}
+exec $DEBUGGER ./run -o i965 $@
-- 
2.17.0

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

[Mesa-dev] [PATCH] radv: Do not hardcode fast clear formats.

[Bas Nieuwenhuizen]

except for the odd one out.

This should support many more formats.
---
 src/amd/vulkan/radv_formats.c | 253 ++
 1 file changed, 73 insertions(+), 180 deletions(-)

diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index aafe331f27d..50ec904d514 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -880,194 +880,87 @@ bool radv_format_pack_clear_color(VkFormat format,
  uint32_t clear_vals[2],
  VkClearColorValue *value)
 {
-   uint8_t r = 0, g = 0, b = 0, a = 0;
const struct vk_format_description *desc = 
vk_format_description(format);
 
-   if (vk_format_get_component_bits(format, VK_FORMAT_COLORSPACE_RGB, 0) 
<= 8) {
-   if (desc->colorspace == VK_FORMAT_COLORSPACE_RGB) {
-   r = float_to_ubyte(value->float32[0]);
-   g = float_to_ubyte(value->float32[1]);
-   b = float_to_ubyte(value->float32[2]);
-   a = float_to_ubyte(value->float32[3]);
-   } else if (desc->colorspace == VK_FORMAT_COLORSPACE_SRGB) {
-   r = 
util_format_linear_float_to_srgb_8unorm(value->float32[0]);
-   g = 
util_format_linear_float_to_srgb_8unorm(value->float32[1]);
-   b = 
util_format_linear_float_to_srgb_8unorm(value->float32[2]);
-   a = float_to_ubyte(value->float32[3]);
-   }
-   }
-   switch (format) {
-   case VK_FORMAT_R8_UNORM:
-   case VK_FORMAT_R8_SRGB:
-   clear_vals[0] = r;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8_UNORM:
-   case VK_FORMAT_R8G8_SRGB:
-   clear_vals[0] = r | g << 8;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8B8A8_SRGB:
-   case VK_FORMAT_R8G8B8A8_UNORM:
-   clear_vals[0] = r | g << 8 | b << 16 | a << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_B8G8R8A8_SRGB:
-   case VK_FORMAT_B8G8R8A8_UNORM:
-   clear_vals[0] = b | g << 8 | r << 16 | a << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_A8B8G8R8_UNORM_PACK32:
-   case VK_FORMAT_A8B8G8R8_SRGB_PACK32:
-   clear_vals[0] = r | g << 8 | b << 16 | a << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8_UINT:
-   clear_vals[0] = value->uint32[0] & 0xff;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8_SINT:
-   clear_vals[0] = value->int32[0] & 0xff;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R16_UINT:
-   clear_vals[0] = value->uint32[0] & 0x;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8_UINT:
-   clear_vals[0] = value->uint32[0] & 0xff;
-   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8_SINT:
-   clear_vals[0] = value->int32[0] & 0xff;
-   clear_vals[0] |= (value->int32[1] & 0xff) << 8;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8B8A8_UINT:
-   clear_vals[0] = value->uint32[0] & 0xff;
-   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
-   clear_vals[0] |= (value->uint32[2] & 0xff) << 16;
-   clear_vals[0] |= (value->uint32[3] & 0xff) << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R8G8B8A8_SINT:
-   clear_vals[0] = value->int32[0] & 0xff;
-   clear_vals[0] |= (value->int32[1] & 0xff) << 8;
-   clear_vals[0] |= (value->int32[2] & 0xff) << 16;
-   clear_vals[0] |= (value->int32[3] & 0xff) << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_A8B8G8R8_UINT_PACK32:
-   clear_vals[0] = value->uint32[0] & 0xff;
-   clear_vals[0] |= (value->uint32[1] & 0xff) << 8;
-   clear_vals[0] |= (value->uint32[2] & 0xff) << 16;
-   clear_vals[0] |= (value->uint32[3] & 0xff) << 24;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R16G16_UINT:
-   clear_vals[0] = value->uint32[0] & 0x;
-   clear_vals[0] |= (value->uint32[1] & 0x) << 16;
-   clear_vals[1] = 0;
-   break;
-   case VK_FORMAT_R16G16B16A16_UINT:
-   clear_vals[0] = value->uint32[0] & 0x;
-   clear_vals[0] |= (value->uint32[1] & 0x) << 16;
-   clear_vals[1] = value->uint32[2] & 0x;
-   clear_vals[1] |= (value->uint32[3] & 0x) << 16;
-   break;
-   case 

Re: [Mesa-dev] [Piglit] GitLab migration of Piglit

[Eric Anholt]

Jason Ekstrand  writes:

> All,
>
> Sorry for the mess of GitLab e-mails but there are a lot of questions to
> ask as this process moves forward.  Today, we're discussing piglit.  I've
> included both the mesa and piglit list in the hopes that people will
> actually see this e-mail.
>
> Honestly, I expect the migration of piglit to have much less impact on most
> people's daily lives than moving the mesa repo.
>
> The biggest question I have is whether we actually want to continue to have
> a separate "piglit" group.  With GitLab, we can already give someone
> developer access to piglit without giving them developer access to mesa.
> Mostly, this is a question of whether we consider piglit to be it's own
> project on freedesktop or a sub-project of mesa.  I don't know the answer
> to that question.

So far, having it be a separate group has just been a pain in getting
people to contribute to piglit, when we mistakenly forget to add mesa
devs to it.  I don't think we need it to be a separate committer group.


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

Re: [Mesa-dev] GitLab migration of Piglit

[Dylan Baker]

As we discussed offline, I think it should be part of the mesa project. As I
understand your explanation: if piglit becomes a mesa group project then anyone
in the mesa group would automatically get piglit write access, but we can still
give specific people write access to the piglit repo (without mesa, libdrm, etc
access). That seems like the right solution to me.

Dylan

Quoting Jason Ekstrand (2018-06-04 08:48:53)
> All,
> 
> Sorry for the mess of GitLab e-mails but there are a lot of questions to ask 
> as
> this process moves forward.  Today, we're discussing piglit.  I've included
> both the mesa and piglit list in the hopes that people will actually see this
> e-mail.
> 
> Honestly, I expect the migration of piglit to have much less impact on most
> people's daily lives than moving the mesa repo.
> 
> The biggest question I have is whether we actually want to continue to have a
> separate "piglit" group.  With GitLab, we can already give someone developer
> access to piglit without giving them developer access to mesa.  Mostly, this 
> is
> a question of whether we consider piglit to be it's own project on freedesktop
> or a sub-project of mesa.  I don't know the answer to that question.
> 
> Thoughts?
> 
> --Jason Ekstrand


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

[Mesa-dev] [Bug 106776] vma_random unrecognized command line option "-std=c++11"

[bugzilla-daemon]

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

--- Comment #2 from Vinson Lee  ---
(In reply to Scott D Phillips from comment #1)
> Created attachment 139959 [details] [review]
> 0001-util-tests-vma-test-depends-on-C-11-support.patch
> 
> I think this should do it. It looks like in the meson build, c++11 support
> is required.

Tested-by: Vinson Lee 

-- 
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 106756] Wine 3.9 crashes with DXVK on Just Cause 3 and Quantum Break on VEGA but works ON POLARIS

[bugzilla-daemon]

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

--- Comment #7 from Samuel Pitoiset  ---
Did you build mesa in debug mode (ie. --enable-debug)?

-- 
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 2/2] i965: Implement ARB_compute_variable_group_size.

[Plamena Manolova]

On Mon, 4 Jun 2018 at 21:36, Ilia Mirkin  wrote:

> On Mon, Jun 4, 2018 at 4:30 PM, Plamena Manolova
>  wrote:
> > Thank you for the review Ilia!
> >
> > On Fri, 1 Jun 2018 at 23:44, Ilia Mirkin  wrote:
> >>
> >> On Fri, Jun 1, 2018 at 6:21 PM, Plamena Manolova
> >>  wrote:
> >> > +  /*
> >> > +   * If the local work group size is variable we have to use a
> >> > dispatch
> >> > +   * width of 32 here, since at this point we don't know the
> actual
> >> > size of
> >> > +   * the workload.
> >> > +   */
> >> > +  min_dispatch_width = 32;
> >>
> >> Is that a good idea? You are able to specify a different maximum when
> >> using a variable size (MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB)
> >> s.t. this is 16 (or even 8, although that may be too few for practical
> >> use) -- that way you would just set the max to 768 or whatever on
> >> gen8+.
> >
> >
> > That's a good point, MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB is the
> > same on all platforms, so it makes sense to use simd16 instead. Thank you
> > for noticing that.
>
> Well IIRC gen7/gen7.5 can do something like 1536 invocations with
> SIMD16, while gen8 are down to 768. Either way, not forcing SIMD32 may
> be nice -- but that's something for you Intel folk to decide. I just
> wanted to point out that you could have different max's for "regular"
> compute (where the min max is 1024) and variable-size groups.
>

Ah, I see what you mean now. I took a closer look at
MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB and it's
related to the maximum number of CS threads (which of course varies).


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

Re: [Mesa-dev] [PATCH 4/4] i965: Use intel_bufferobj_buffer() wrapper in image surface state setup.

[Nanley Chery]

On Fri, May 11, 2018 at 04:55:27PM -0700, Nanley Chery wrote:
> On Mon, Mar 19, 2018 at 11:26:59AM -0700, Francisco Jerez wrote:
> > Instead of directly using intel_obj->buffer.  Among other things
> > intel_bufferobj_buffer() will update intel_buffer_object::
> > gpu_active_start/end, which are used by glBufferSubData() to decide
> > which path to take.  Fixes a failure in the Piglit
> > ARB_shader_image_load_store-host-mem-barrier Buffer Update/WaW tests,
> > which could be reproduced with a non-standard glGetTexSubImage
> > implementation (see bug report).
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105351
> 
> What do you think about leaving the bug open until we create a piglit
> test to reproduce it? We could create a new bug otherwise.
> 

Nevermind about leaving this open and creating another report. I'll
close the bug. Thanks!

-Nanley

> > Reported-by: Nanley Chery 
> > Cc: mesa-sta...@lists.freedesktop.org
> > ---
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > index 2ab15af793a..5d4c84bb55a 100644
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -1510,14 +1510,16 @@ update_image_surface(struct brw_context *brw,
> >const unsigned format = get_image_format(brw, u->_ActualFormat, 
> > access);
> >  
> >if (obj->Target == GL_TEXTURE_BUFFER) {
> > - struct intel_buffer_object *intel_obj =
> > -intel_buffer_object(obj->BufferObject);
> >   const unsigned texel_size = (format == ISL_FORMAT_RAW ? 1 :
> >
> > _mesa_get_format_bytes(u->_ActualFormat));
> >   const unsigned buffer_size = buffer_texture_range_size(brw, obj);
> > + struct brw_bo *const bo = !obj->BufferObject ? NULL :
> 
> Interesting. Did the old code wrongly assume that
> obj->BufferObject != NULL? Maybe we need a test that tries to do image
> load/store on a texture buffer without a backing buffer object?
> 
> > +intel_bufferobj_buffer(brw, 
> > intel_buffer_object(obj->BufferObject),
> > +   obj->BufferOffset, buffer_size,
> > +   access != GL_READ_ONLY);
> >  
> 
> Looks right to me. The comment above the helper function says:
>[...]
>* Anywhere that uses buffer objects in the pipeline should be using this to
>* mark the range of the buffer that is being accessed by the pipeline.
>*/
>   
> ...and that is what we're doing here. This patch is
> Reviewed-by: Nanley Chery 
> 
> >   brw_emit_buffer_surface_state(
> > -brw, surf_offset, intel_obj->buffer, obj->BufferOffset,
> > +brw, surf_offset, bo, obj->BufferOffset,
> >  format, buffer_size, texel_size,
> >  access != GL_READ_ONLY ? RELOC_WRITE : 0);
> >  
> > -- 
> > 2.16.1
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Implement ARB_compute_variable_group_size.

[Ilia Mirkin]

On Mon, Jun 4, 2018 at 4:30 PM, Plamena Manolova
 wrote:
> Thank you for the review Ilia!
>
> On Fri, 1 Jun 2018 at 23:44, Ilia Mirkin  wrote:
>>
>> On Fri, Jun 1, 2018 at 6:21 PM, Plamena Manolova
>>  wrote:
>> > +  /*
>> > +   * If the local work group size is variable we have to use a
>> > dispatch
>> > +   * width of 32 here, since at this point we don't know the actual
>> > size of
>> > +   * the workload.
>> > +   */
>> > +  min_dispatch_width = 32;
>>
>> Is that a good idea? You are able to specify a different maximum when
>> using a variable size (MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB)
>> s.t. this is 16 (or even 8, although that may be too few for practical
>> use) -- that way you would just set the max to 768 or whatever on
>> gen8+.
>
>
> That's a good point, MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB is the
> same on all platforms, so it makes sense to use simd16 instead. Thank you
> for noticing that.

Well IIRC gen7/gen7.5 can do something like 1536 invocations with
SIMD16, while gen8 are down to 768. Either way, not forcing SIMD32 may
be nice -- but that's something for you Intel folk to decide. I just
wanted to point out that you could have different max's for "regular"
compute (where the min max is 1024) and variable-size groups.

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

Re: [Mesa-dev] [PATCH 2/2] i965: Implement ARB_compute_variable_group_size.

[Plamena Manolova]

Thank you for the review Ilia!

On Fri, 1 Jun 2018 at 23:44, Ilia Mirkin  wrote:

> On Fri, Jun 1, 2018 at 6:21 PM, Plamena Manolova
>  wrote:
> > This patch adds the implentation of ARB_compute_variable_group_size
> > for i965. We do this by storing the group size in a buffer surface,
> > similarly to the work group number.
> >
> > Signed-off-by: Plamena Manolova 
> > ---
> >  docs/features.txt|  2 +-
> >  docs/relnotes/18.2.0.html|  1 +
> >  src/compiler/nir/nir_lower_system_values.c   | 14 
> >  src/intel/compiler/brw_compiler.h|  2 +
> >  src/intel/compiler/brw_fs.cpp| 45 
> >  src/intel/compiler/brw_fs_nir.cpp| 20 ++
> >  src/intel/compiler/brw_nir_lower_cs_intrinsics.c | 87
> +---
> >  src/mesa/drivers/dri/i965/brw_compute.c  | 25 ++-
> >  src/mesa/drivers/dri/i965/brw_context.h  |  1 +
> >  src/mesa/drivers/dri/i965/brw_cs.c   |  4 ++
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 27 +++-
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
> >  12 files changed, 187 insertions(+), 42 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index ed4050cf98..7c3c856d73 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -298,7 +298,7 @@ Khronos, ARB, and OES extensions that are not part
> of any OpenGL or OpenGL ES ve
> >
> >GL_ARB_bindless_texture   DONE (nvc0,
> radeonsi)
> >GL_ARB_cl_event   not started
> > -  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi)
> > +  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi, i965)
> >GL_ARB_ES3_2_compatibilityDONE
> (i965/gen8+)
> >GL_ARB_fragment_shader_interlock  DONE (i965)
> >GL_ARB_gpu_shader_int64   DONE
> (i965/gen8+, nvc0, radeonsi, softpipe, llvmpipe)
> > diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
> > index a3f44a29dc..4ceeb7471f 100644
> > --- a/docs/relnotes/18.2.0.html
> > +++ b/docs/relnotes/18.2.0.html
> > @@ -45,6 +45,7 @@ Note: some of the new features are only available with
> certain drivers.
> >
> >  
> >  GL_ARB_fragment_shader_interlock on i965
> > +GL_ARB_compute_variable_group_size on i965
> >  
> >
> >  Bug fixes
> > diff --git a/src/compiler/nir/nir_lower_system_values.c
> b/src/compiler/nir/nir_lower_system_values.c
> > index 487da04262..0af6d69426 100644
> > --- a/src/compiler/nir/nir_lower_system_values.c
> > +++ b/src/compiler/nir/nir_lower_system_values.c
> > @@ -57,6 +57,15 @@ convert_block(nir_block *block, nir_builder *b)
> >*gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID"
> >*/
> >
> > +
> > +  /*
> > +   * If the local work group size is variable we can't lower
> the global
> > +   * invocation id here.
> > +   */
> > +  if (b->shader->info.cs.local_size_variable) {
> > + break;
> > +  }
> > +
>
> There appears to be some tabs vs spaces thing here.
>
> >   nir_const_value local_size;
> >   memset(_size, 0, sizeof(local_size));
> >   local_size.u32[0] = b->shader->info.cs.local_size[0];
> > @@ -102,6 +111,11 @@ convert_block(nir_block *block, nir_builder *b)
> >}
> >
> >case SYSTEM_VALUE_LOCAL_GROUP_SIZE: {
> > + /* If the local work group size is variable we can't lower it
> here */
> > + if (b->shader->info.cs.local_size_variable) {
> > +break;
> > + }
> > +
> >   nir_const_value local_size;
> >   memset(_size, 0, sizeof(local_size));
> >   local_size.u32[0] = b->shader->info.cs.local_size[0];
> > diff --git a/src/intel/compiler/brw_compiler.h
> b/src/intel/compiler/brw_compiler.h
> > index 8b4e6fe2e2..f54952c28f 100644
> > --- a/src/intel/compiler/brw_compiler.h
> > +++ b/src/intel/compiler/brw_compiler.h
> > @@ -759,6 +759,7 @@ struct brw_cs_prog_data {
> > unsigned threads;
> > bool uses_barrier;
> > bool uses_num_work_groups;
> > +   bool uses_variable_group_size;
> >
> > struct {
> >struct brw_push_const_block cross_thread;
> > @@ -771,6 +772,7 @@ struct brw_cs_prog_data {
> > * surface indices the CS-specific surfaces
> > */
> >uint32_t work_groups_start;
> > +  uint32_t work_group_size_start;
> >/** @} */
> > } binding_table;
> >  };
> > diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> > index d67c0a4192..28730af47b 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -7228,18 +7228,32 @@ brw_compile_cs(const struct brw_compiler
> *compiler, void *log_data,
> > int shader_time_index,
> >

[Mesa-dev] [Bug 106778] Files missing from tarball - intel_sanitize_gpu.*

[bugzilla-daemon]

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

Kevin Rogovin  changed:

   What|Removed |Added

   Assignee|kevin.rogo...@intel.com |mesa-dev@lists.freedesktop.
   ||org

-- 
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 106778] Files missing from tarball - intel_sanitize_gpu.*

[bugzilla-daemon]

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

--- Comment #2 from Kevin Rogovin  ---
Hi,

 I am no longer involved with Mesa development; I suggest assigning the bug to
whoever the git log lists as the author for the git commit that added those
files.

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

Re: [Mesa-dev] [PATCH 2/2] i965: Implement ARB_compute_variable_group_size.

[Plamena Manolova]

Thank you for reviewing this Jordan!

On Fri, 1 Jun 2018 at 23:45, Jordan Justen 
wrote:

> On 2018-06-01 15:21:34, Plamena Manolova wrote:
> > This patch adds the implentation of ARB_compute_variable_group_size
> > for i965. We do this by storing the group size in a buffer surface,
> > similarly to the work group number.
> >
> > Signed-off-by: Plamena Manolova 
> > ---
> >  docs/features.txt|  2 +-
> >  docs/relnotes/18.2.0.html|  1 +
> >  src/compiler/nir/nir_lower_system_values.c   | 14 
> >  src/intel/compiler/brw_compiler.h|  2 +
> >  src/intel/compiler/brw_fs.cpp| 45 
> >  src/intel/compiler/brw_fs_nir.cpp| 20 ++
> >  src/intel/compiler/brw_nir_lower_cs_intrinsics.c | 87
> +---
> >  src/mesa/drivers/dri/i965/brw_compute.c  | 25 ++-
> >  src/mesa/drivers/dri/i965/brw_context.h  |  1 +
> >  src/mesa/drivers/dri/i965/brw_cs.c   |  4 ++
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 27 +++-
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
> >  12 files changed, 187 insertions(+), 42 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index ed4050cf98..7c3c856d73 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -298,7 +298,7 @@ Khronos, ARB, and OES extensions that are not part
> of any OpenGL or OpenGL ES ve
> >
> >GL_ARB_bindless_texture   DONE (nvc0,
> radeonsi)
> >GL_ARB_cl_event   not started
> > -  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi)
> > +  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi, i965)
> >GL_ARB_ES3_2_compatibilityDONE
> (i965/gen8+)
> >GL_ARB_fragment_shader_interlock  DONE (i965)
> >GL_ARB_gpu_shader_int64   DONE
> (i965/gen8+, nvc0, radeonsi, softpipe, llvmpipe)
> > diff --git a/docs/relnotes/18.2.0.html b/docs/relnotes/18.2.0.html
> > index a3f44a29dc..4ceeb7471f 100644
> > --- a/docs/relnotes/18.2.0.html
> > +++ b/docs/relnotes/18.2.0.html
> > @@ -45,6 +45,7 @@ Note: some of the new features are only available with
> certain drivers.
> >
> >  
> >  GL_ARB_fragment_shader_interlock on i965
> > +GL_ARB_compute_variable_group_size on i965
> >  
> >
> >  Bug fixes
> > diff --git a/src/compiler/nir/nir_lower_system_values.c
> b/src/compiler/nir/nir_lower_system_values.c
> > index 487da04262..0af6d69426 100644
> > --- a/src/compiler/nir/nir_lower_system_values.c
> > +++ b/src/compiler/nir/nir_lower_system_values.c
> > @@ -57,6 +57,15 @@ convert_block(nir_block *block, nir_builder *b)
> >*gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID"
> >*/
> >
> > +
>
> Extra line.
>
> > +  /*
> > +   * If the local work group size is variable we can't lower
> the global
> > +   * invocation id here.
> > +   */
> > +  if (b->shader->info.cs.local_size_variable) {
> > + break;
> > +  }
> > +
>
> The indent looks off here. One extra space?
>
> >   nir_const_value local_size;
> >   memset(_size, 0, sizeof(local_size));
> >   local_size.u32[0] = b->shader->info.cs.local_size[0];
> > @@ -102,6 +111,11 @@ convert_block(nir_block *block, nir_builder *b)
> >}
> >
> >case SYSTEM_VALUE_LOCAL_GROUP_SIZE: {
> > + /* If the local work group size is variable we can't lower it
> here */
> > + if (b->shader->info.cs.local_size_variable) {
> > +break;
> > + }
> > +
> >   nir_const_value local_size;
> >   memset(_size, 0, sizeof(local_size));
> >   local_size.u32[0] = b->shader->info.cs.local_size[0];
> > diff --git a/src/intel/compiler/brw_compiler.h
> b/src/intel/compiler/brw_compiler.h
> > index 8b4e6fe2e2..f54952c28f 100644
> > --- a/src/intel/compiler/brw_compiler.h
> > +++ b/src/intel/compiler/brw_compiler.h
> > @@ -759,6 +759,7 @@ struct brw_cs_prog_data {
> > unsigned threads;
> > bool uses_barrier;
> > bool uses_num_work_groups;
> > +   bool uses_variable_group_size;
> >
> > struct {
> >struct brw_push_const_block cross_thread;
> > @@ -771,6 +772,7 @@ struct brw_cs_prog_data {
> > * surface indices the CS-specific surfaces
> > */
> >uint32_t work_groups_start;
> > +  uint32_t work_group_size_start;
> >/** @} */
> > } binding_table;
> >  };
> > diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> > index d67c0a4192..28730af47b 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -7228,18 +7228,32 @@ brw_compile_cs(const struct brw_compiler
> *compiler, void *log_data,
> > int shader_time_index,
> > 

Re: [Mesa-dev] GitLab migration of Piglit

[Marek Olšák]

I would say it's a sub-project of Mesa.

Marek

On Mon, Jun 4, 2018 at 11:48 AM, Jason Ekstrand 
wrote:

> All,
>
> Sorry for the mess of GitLab e-mails but there are a lot of questions to
> ask as this process moves forward.  Today, we're discussing piglit.  I've
> included both the mesa and piglit list in the hopes that people will
> actually see this e-mail.
>
> Honestly, I expect the migration of piglit to have much less impact on
> most people's daily lives than moving the mesa repo.
>
> The biggest question I have is whether we actually want to continue to
> have a separate "piglit" group.  With GitLab, we can already give someone
> developer access to piglit without giving them developer access to mesa.
> Mostly, this is a question of whether we consider piglit to be it's own
> project on freedesktop or a sub-project of mesa.  I don't know the answer
> to that question.
>
> Thoughts?
>
> --Jason Ekstrand
>
> ___
> 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] i965: Implement ARB_compute_variable_group_size.

[Plamena Manolova]

Ah, that's true, I'll switch them around. Thank you for reviewing Matt!

On Sat, 2 Jun 2018 at 04:58, Matt Turner  wrote:

> On Fri, Jun 1, 2018 at 3:21 PM, Plamena Manolova
>  wrote:
> > This patch adds the implentation of ARB_compute_variable_group_size
> > for i965. We do this by storing the group size in a buffer surface,
> > similarly to the work group number.
> >
> > Signed-off-by: Plamena Manolova 
> > ---
> >  docs/features.txt|  2 +-
> >  docs/relnotes/18.2.0.html|  1 +
> >  src/compiler/nir/nir_lower_system_values.c   | 14 
> >  src/intel/compiler/brw_compiler.h|  2 +
> >  src/intel/compiler/brw_fs.cpp| 45 
> >  src/intel/compiler/brw_fs_nir.cpp| 20 ++
> >  src/intel/compiler/brw_nir_lower_cs_intrinsics.c | 87
> +---
> >  src/mesa/drivers/dri/i965/brw_compute.c  | 25 ++-
> >  src/mesa/drivers/dri/i965/brw_context.h  |  1 +
> >  src/mesa/drivers/dri/i965/brw_cs.c   |  4 ++
> >  src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 27 +++-
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
> >  12 files changed, 187 insertions(+), 42 deletions(-)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index ed4050cf98..7c3c856d73 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -298,7 +298,7 @@ Khronos, ARB, and OES extensions that are not part
> of any OpenGL or OpenGL ES ve
> >
> >GL_ARB_bindless_texture   DONE (nvc0,
> radeonsi)
> >GL_ARB_cl_event   not started
> > -  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi)
> > +  GL_ARB_compute_variable_group_sizeDONE (nvc0,
> radeonsi, i965)
>
> I think these are typically in alphabetical order, so i965 goes first.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] trace: Fix trace_context_transfer_unmap methods.

[Jose Fonseca]

Right.  The issue is that transfer_map/transfer_unmap, just by 
themselves don't imply changing data.  So the way trace driver works is 
that it emits fake buffer_subdata/transfer_subdata when unmapping write 
transfers.  (Originally, it used pipe_transfer_inline method, before it 
was rename/refactored.)


Another alternative would be to record transfer_map/unmap, and then emit 
fake memcpy calls (this is how apitrace work, but not trace drive.r)


Jose

On 04/06/18 17:06, Roland Scheidegger wrote:

Alright, this now has all the right bits buffer/texture_subdata would use.
That said, I'm still a bit confused why this is necessary. Is that just
so the dumped output looks like it's the same as if you called
texture/buffer_subdata? Makes sense then, but in reality it still was a
transfer.

Reviewed-by: Roland Scheidegger 


Am 04.06.2018 um 15:01 schrieb Jose Fonseca:

The emitted buffer_subdata/texture_subdata call didn't match the
respective signatures.

v2: Actually emit buffer_subdata call.
---
  .../auxiliary/driver_trace/tr_context.c   | 60 +--
  1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c 
b/src/gallium/auxiliary/driver_trace/tr_context.c
index 6d918d42a38..dc091aee2e9 100644
--- a/src/gallium/auxiliary/driver_trace/tr_context.c
+++ b/src/gallium/auxiliary/driver_trace/tr_context.c
@@ -1430,35 +1430,59 @@ trace_context_transfer_unmap(struct pipe_context 
*_context,
 */
  
struct pipe_resource *resource = transfer->resource;

-  unsigned level = transfer->level;
unsigned usage = transfer->usage;
const struct pipe_box *box = >box;
unsigned stride = transfer->stride;
unsigned layer_stride = transfer->layer_stride;
  
-  if (resource->target == PIPE_BUFFER)

+  if (resource->target == PIPE_BUFFER) {
+ unsigned offset = box->x;
+ unsigned size = box->width;
+
   trace_dump_call_begin("pipe_context", "buffer_subdata");
-  else
+
+ trace_dump_arg(ptr, context);
+ trace_dump_arg(ptr, resource);
+ trace_dump_arg(uint, usage);
+ trace_dump_arg(uint, offset);
+ trace_dump_arg(uint, size);
+
+ trace_dump_arg_begin("data");
+ trace_dump_box_bytes(tr_trans->map,
+  resource,
+  box,
+  stride,
+  layer_stride);
+ trace_dump_arg_end();
+
+ trace_dump_arg(uint, stride);
+ trace_dump_arg(uint, layer_stride);
+
+ trace_dump_call_end();
+  } else {
+ unsigned level = transfer->level;
+
   trace_dump_call_begin("pipe_context", "texture_subdata");
  
-  trace_dump_arg(ptr, context);

-  trace_dump_arg(ptr, resource);
-  trace_dump_arg(uint, level);
-  trace_dump_arg(uint, usage);
-  trace_dump_arg(box, box);
+ trace_dump_arg(ptr, context);
+ trace_dump_arg(ptr, resource);
+ trace_dump_arg(uint, level);
+ trace_dump_arg(uint, usage);
+ trace_dump_arg(box, box);
  
-  trace_dump_arg_begin("data");

-  trace_dump_box_bytes(tr_trans->map,
-   resource,
-   box,
-   stride,
-   layer_stride);
-  trace_dump_arg_end();
+ trace_dump_arg_begin("data");
+ trace_dump_box_bytes(tr_trans->map,
+  resource,
+  box,
+  stride,
+  layer_stride);
+ trace_dump_arg_end();
  
-  trace_dump_arg(uint, stride);

-  trace_dump_arg(uint, layer_stride);
+ trace_dump_arg(uint, stride);
+ trace_dump_arg(uint, layer_stride);
  
-  trace_dump_call_end();

+ trace_dump_call_end();
+  }
  
tr_trans->map = NULL;

 }





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

[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

--- Comment #15 from pritzl3...@gmail.com ---
Hi Alex,

I gave it a try now with the new update to ROTTR and the game still hangs in
the same way.

I am now on kernel 4.17.0
Mesa and llvm from git updated about 2 hours ago.

OpenGL renderer string: Radeon RX Vega (VEGA10, DRM 3.25.0, 4.17.0-gentoo, LLVM
7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel
(git-b3ba47c592)

-- 
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 v2] meson: fix private libs when building without glx

[Lukas Rusak]

I noticed that the generated pkg-config files will include
glx and x11 dependencies even when x11 isn't a selected platform.

This fixes the private libs and was tested by building kmscube

V2:
  - check if gallium-xlib is being used for glx

Reviewed-by: Dylan Baker 
---
 meson.build | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/meson.build b/meson.build
index 4aafba802a..b1ab9d6a20 100644
--- a/meson.build
+++ b/meson.build
@@ -1339,18 +1339,24 @@ endforeach
 
 inc_include = include_directories('include')
 
-gl_priv_reqs = [
-  'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
-  'xcb-glx >= 1.8.1']
+gl_priv_reqs = []
+
+if with_glx == 'xlib' or with_glx == 'gallium-xlib'
+  gl_priv_reqs += ['x11', 'xext', 'xcb']
+elif with_glx == 'dri'
+  gl_priv_reqs += [
+'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
+'xcb-glx >= 1.8.1']
+  if with_dri_platform == 'drm'
+gl_priv_reqs += 'xcb-dri2 >= 1.8'
+  endif
+endif
 if dep_libdrm.found()
   gl_priv_reqs += 'libdrm >= 2.4.75'
 endif
 if dep_xxf86vm.found()
   gl_priv_reqs += 'xxf86vm'
 endif
-if with_dri_platform == 'drm'
-  gl_priv_reqs += 'xcb-dri2 >= 1.8'
-endif
 
 gl_priv_libs = []
 if dep_thread.found()
-- 
2.17.0

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

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #8 from fred...@rinnestam.se ---
(In reply to Dylan Baker from comment #7)
> Those are just build-time dependencies, you can uninstall them afterwards.

It's not really practical in a source based distribution (yes a few still
exist).

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

Re: [Mesa-dev] [PATCH mesa] configure: radv depends on mako

[Bas Nieuwenhuizen]

Acked-by: Bas Nieuwenhuizen 

On Mon, Jun 4, 2018 at 1:12 PM, Eric Engestrom  wrote:
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106784
> Fixes: 17201a2eb0b1b85387136 "radv: port to using updated anv
>   entrypoint/extension generator."
> Signed-off-by: Eric Engestrom 
> ---
>  configure.ac | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 02dca4547c8482a0b164..600127af8f68e1bd5c25 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2099,6 +2099,9 @@ if test -n "$with_vulkan_drivers"; then
>  PKG_CHECK_MODULES([AMDGPU], [libdrm >= $LIBDRM_AMDGPU_REQUIRED 
> libdrm_amdgpu >= $LIBDRM_AMDGPU_REQUIRED])
>  radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
>  require_x11_dri3 "radv"
> +if test "x$acv_mako_found" = xno; then
> +AC_MSG_ERROR([Python mako module v$PYTHON_MAKO_REQUIRED or 
> higher not found])
> +fi
>  HAVE_RADEON_VULKAN=yes
>  ;;
>  *)
> --
> Cheers,
>   Eric
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #7 from Dylan Baker  ---
Those are just build-time dependencies, you can uninstall them afterwards.

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

Re: [Mesa-dev] [PATCH] meson: fix private libs when building without glx

[Dylan Baker]

Quoting Lukas Rusak (2018-06-03 22:57:31)
> I noticed that the generated pkg-config files will include
> glx and x11 dependencies even when x11 isn't a selected platform.
> 
> This fixes the private libs and was tested by building kmscube
> ---
>  meson.build | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 4aafba802a..80bb8746b2 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1339,18 +1339,24 @@ endforeach
>  
>  inc_include = include_directories('include')
>  
> -gl_priv_reqs = [
> -  'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
> -  'xcb-glx >= 1.8.1']
> +gl_priv_reqs = []
> +
> +if with_glx == 'xlib'

if with_glx == 'xlib' or with_glx == 'gallium-xlib'

> +  gl_priv_reqs += ['x11', 'xext', 'xcb']
> +elif with_glx == 'dri'
> +  gl_priv_reqs += [
> +'x11', 'xext', 'xdamage >= 1.1', 'xfixes', 'x11-xcb', 'xcb',
> +'xcb-glx >= 1.8.1']
> +  if with_dri_platform == 'drm'
> +gl_priv_reqs += 'xcb-dri2 >= 1.8'
> +  endif
> +endif
>  if dep_libdrm.found()
>gl_priv_reqs += 'libdrm >= 2.4.75'
>  endif
>  if dep_xxf86vm.found()
>gl_priv_reqs += 'xxf86vm'
>  endif
> -if with_dri_platform == 'drm'
> -  gl_priv_reqs += 'xcb-dri2 >= 1.8'
> -endif
>  
>  gl_priv_libs = []
>  if dep_thread.found()
> -- 
> 2.17.0
> 

With the one nit,
Reviewed-by: Dylan Baker 


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

Re: [Mesa-dev] [PATCH mesa] autotools: add missing android file to package

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2018-06-04 10:09:55)
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106779
> Fixes: ff904978a1d299a36b587 "gallium/util: Android backtrace support"
> Signed-off-by: Eric Engestrom 
> ---
>  src/gallium/auxiliary/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/auxiliary/Makefile.am 
> b/src/gallium/auxiliary/Makefile.am
> index 07856e5a5289e00dd3d2..6b048b8eebf6380389d4 100644
> --- a/src/gallium/auxiliary/Makefile.am
> +++ b/src/gallium/auxiliary/Makefile.am
> @@ -118,6 +118,7 @@ EXTRA_DIST = \
> postprocess/ADDING \
> rbug/README \
> target-helpers \
> +   util/u_debug_stack_android.cpp \
> util/u_format.csv \
> util/u_format_pack.py \
> util/u_format_parse.py \
> -- 
> Cheers,
>   Eric
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #5 from Bas Nieuwenhuizen  ---
Some of those files (radv_icd.py) uses the install path, you can't really put
the result of that in a release tarball.


so either we need to stop using mako for that and use something else, or we
still need mako.

Just curious though what are the main reasons against mako? Intel has been
depending on them like this for a while.

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

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #6 from fred...@rinnestam.se ---
(In reply to Bas Nieuwenhuizen from comment #5)
> Just curious though what are the main reasons against mako? Intel has been
> depending on them like this for a while.

My only "objection" is additional dependency bloat:

These are new deps to run mesa3d 18.1 on my system:

-- Packages installed
python-appdirs
python-pyparsing
python-six
python-pip
python-packaging
python-setuptools
mako

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Daniel Stone]

On 4 June 2018 at 19:29, Dylan Baker  wrote:
> Quoting Daniel Stone (2018-06-04 11:20:45)
>> Is git-lfs mainly about supporting large individual files, or large
>> collections of relatively small files? The tarballs aren't massive,
>> there are just tons of them. If it does seem like a good idea, I'll
>> get it set up in our instance.
>
> It's just for dealing with binary files in general. The advantage is that the
> binaries live on a generic file server so you don't have to fetch them if you
> don't want them (they show up as a text file with a hash until you fetch 
> them).
> I don't know if it's necessary I've just had good luck with it in the past for
> handling binaries.

Yeah, that sounds exactly like what we want then! I'll get it set up
during the week.

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Dylan Baker]

Quoting Daniel Stone (2018-06-04 11:20:45)
> Hi Dylan,
> 
> On 4 June 2018 at 19:18, Dylan Baker  wrote:
> > Quoting Daniel Stone (2018-06-03 13:19:51)
> >> One thing I've just remembered is that https://www.mesa3d.org/archive/
> >> serves all the tarballs for Mesa releases. Given how Pages is
> >> structured, we don't have a good way to redirect these to the old
> >> server, so the Pages repository needs to hold all the tarballs. This
> >> probably suggests to me that the site should live in a different repo,
> >> where we can just commit all the tarballs.
> >>
> >> I reflexively didn't love the idea of committing tarballs to a git
> >> repository, but the more I think about it, the more I like the idea.
> >> It makes it more clear where they're coming from, makes the provenance
> >> easier to verify, gives us audit logs of who put them in, and so on.
> >
> > Have you considered git-lfs? I don't know if we've got it set up, but gitlab
> > supports it and it's pretty nice for dealing with repos with large binary 
> > files.
> 
> Is git-lfs mainly about supporting large individual files, or large
> collections of relatively small files? The tarballs aren't massive,
> there are just tons of them. If it does seem like a good idea, I'll
> get it set up in our instance.
> 
> Cheers,
> Daniel

It's just for dealing with binary files in general. The advantage is that the
binaries live on a generic file server so you don't have to fetch them if you
don't want them (they show up as a text file with a hash until you fetch them).
I don't know if it's necessary I've just had good luck with it in the past for
handling binaries.

Dylan


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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Daniel Stone]

Hi Dylan,

On 4 June 2018 at 19:18, Dylan Baker  wrote:
> Quoting Daniel Stone (2018-06-03 13:19:51)
>> One thing I've just remembered is that https://www.mesa3d.org/archive/
>> serves all the tarballs for Mesa releases. Given how Pages is
>> structured, we don't have a good way to redirect these to the old
>> server, so the Pages repository needs to hold all the tarballs. This
>> probably suggests to me that the site should live in a different repo,
>> where we can just commit all the tarballs.
>>
>> I reflexively didn't love the idea of committing tarballs to a git
>> repository, but the more I think about it, the more I like the idea.
>> It makes it more clear where they're coming from, makes the provenance
>> easier to verify, gives us audit logs of who put them in, and so on.
>
> Have you considered git-lfs? I don't know if we've got it set up, but gitlab
> supports it and it's pretty nice for dealing with repos with large binary 
> files.

Is git-lfs mainly about supporting large individual files, or large
collections of relatively small files? The tarballs aren't massive,
there are just tons of them. If it does seem like a good idea, I'll
get it set up in our instance.

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Dylan Baker]

Quoting Daniel Stone (2018-06-03 13:19:51)
> Hi Laura,
> 
> On 25 May 2018 at 01:27, Laura Ekstrand  wrote:
> > When reviewing these patches, please note:
> > 1. This patch series does *not* touch content.  Please do not 
> > bikeshed
> >the content of webpages here.  That will be addressed in later
> >commits.
> > 2. Please do *not* bikeshed website style here.  We are using the
> >classic ReadTheDocs style for now and we will update style in a
> >future commit.
> > 3. I've done my best to make your current content look beautiful.  
> > If
> >there's a problem, please let me know.
> > 4. There were some commits to the website between when I started 
> > this
> >series and now. I've done my best to incorporate your changes.
> >So if you changed your content in the past two weeks, take a look
> >at your page.
> 
> One thing I've just remembered is that https://www.mesa3d.org/archive/
> serves all the tarballs for Mesa releases. Given how Pages is
> structured, we don't have a good way to redirect these to the old
> server, so the Pages repository needs to hold all the tarballs. This
> probably suggests to me that the site should live in a different repo,
> where we can just commit all the tarballs.
> 
> I reflexively didn't love the idea of committing tarballs to a git
> repository, but the more I think about it, the more I like the idea.
> It makes it more clear where they're coming from, makes the provenance
> easier to verify, gives us audit logs of who put them in, and so on.
> 
> Cheers,
> Daniel

Have you considered git-lfs? I don't know if we've got it set up, but gitlab
supports it and it's pretty nice for dealing with repos with large binary files.

Dylan


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

Re: [Mesa-dev] GitLab personal repos

[Adam Jackson]

On Sat, 2018-06-02 at 13:10 -0400, Rob Clark wrote:
> On Sat, Jun 2, 2018 at 12:07 PM, Jason Ekstrand  wrote:
> >  1) Forks share objects behind the user's back so it should use
> > significantly less space on the GitLab server if everyone's personal mesa
> > repo is an actual GitLab fork and not a bare repo that they pushed.

It'd be cool if gitlab could figure out object sharing without this,
but I totally understand why that's hard.

> kinda on the topic, but not directly related to mesa.. at least a few
> of us have private kernel trees on p.fd.o, and kernel git trees are
> *much* bigger.  Will there be (or is there already) a gitlab kernel
> tree that we could recreate our private kernel trees from, to share
> objects?
> 
> I guess since it is mostly stuff that feeds into drm-next, maybe
> Dave's drm-next tree should move to gitlab, and then others fork off
> of that?

A fresh clone's linux/.git is about 2.3G at the moment. That's probably
not a huge burden in terms of just storage, but might be bad in terms
of I/O (since identical data competing for page cache is silly), so
having a standard kernel tree mirror does sound wise.

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

Re: [Mesa-dev] [PATCH mesa] meson: fix platforms check for `-D egl=true`

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Eric Engestrom (2018-06-04 03:46:32)
> Fixes: 0ed6a87a106b6e2266e0 "meson: fix platforms=[]"
> Reported-by: Christoph Haag 
> Signed-off-by: Eric Engestrom 
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 7b7c118d77b11cc38f7b..1d1b2a979b1de80ddd06 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -292,7 +292,7 @@ elif _egl == 'true'
>  error('EGL requires dri')
>elif not with_shared_glapi
>  error('EGL requires shared-glapi')
> -  elif with_platforms
> +  elif not with_platforms
>  error('No platforms specified, consider -Dplatforms=drm,x11 at least')
>elif not ['disabled', 'dri'].contains(with_glx)
>  error('EGL requires dri, but a GLX is being built without dri')
> -- 
> Cheers,
>   Eric
> 


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

Re: [Mesa-dev] [PATCH] glx: Fix number of property values to read in glXImportContextEXT

[Adam Jackson]

On Fri, 2018-06-01 at 19:01 +0200, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> We were trying to read twice as many as the X server sent us, which
> upset XCB:
> 
> [xcb] Too much data requested from _XRead
> [xcb] This is most likely caused by a broken X extension library
> [xcb] Aborting, sorry about that.
> glx-free-context: ../../src/xcb_io.c:732: _XRead: Assertion 
> `!xcb_xlib_too_much_data_requested' failed.
> 
> Fixing this takes 3 GLX piglit tests from crash to pass.
> 
> Fixes: 085216295033 "glx: Be more tolerant in glXImportContext (v2)"
> Signed-off-by: Michel Dänzer 

Ugh. Truly embarrassing.

Reviewed-by: Adam Jackson 

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

[Mesa-dev] [Bug 106778] Files missing from tarball - intel_sanitize_gpu.*

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |kevin.rogo...@intel.com
   |org |

--- Comment #1 from Eric Engestrom  ---
(In reply to Stuart Young from comment #0)
>  src/intel/tools/meson.build lists these files, but they're inside an if
> statement, so I suspect they're not being parsed when the tarball is being
> built (eg: using `ninja dist` ?).

The tarballs are generated with autotools for now (see
https://mesa3d.org/releasing.html#release), and the issue here is that these
files are only used to build a program meson builds, not autotools.

Kevin, can you either add the build instructions to
src/intel/Makefile.tools.am, or add the two files to EXTRA_DIST (in that same
makefile)?
Either way, please add this line to allow the scripts to pick it up:
Fixes: cc41603d6da4552f0aaf "intel/tools: new intel_sanitize_gpu tool"

Thanks :)

-- 
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] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

I sent out a patch that adds capability bits to this struct, and the
first bit is the tgsi invariant capability.  It's dependent on this
patch to apply correctly to master.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 CC||airl...@freedesktop.org,
   ||b...@basnieuwenhuizen.nl

--- Comment #4 from Eric Engestrom  ---
(In reply to fredrik from comment #2)
> Bummer! No workaround available to avoid mako? It does introduce a lot of
> previously unneeded depencencies.

Those dependencies will be needed even for tarball builds once we switch to
meson for building tarballs (it takes a snapshot of the git tree), so any
workaround would be temporary anyway.


(In reply to Michael Olbrich from comment #3)
> Why not ship the generated files in the tarball like it's done in other
> parts of mesa?

It could be possible, I didn't look into this; I'll let Dave and Bas (cc'ed on
the patch) decide what is best.

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

[Mesa-dev] [PATCH 2/2] virgl: use bits in caps set v2

[gurchetansi...@chromium.org]

Let's add another field to caps v2, that can help report boolean
values.

Suggested-by: Gert Wollny 
Suggested-by: Dave Airlie 
---
 src/gallium/drivers/virgl/virgl_hw.h | 5 +
 src/gallium/drivers/virgl/virgl_winsys.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index a2c70bf86b..ee58520f9b 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -197,6 +197,10 @@ enum virgl_formats {
VIRGL_FORMAT_MAX,
 };
 
+/* These are used by the capability_bits field in virgl_caps_v2. */
+#define VIRGL_CAP_NONE 0
+#define VIRGL_CAP_TGSI_INVARIANT   (1 << 0)
+
 #define VIRGL_BIND_DEPTH_STENCIL (1 << 0)
 #define VIRGL_BIND_RENDER_TARGET (1 << 1)
 #define VIRGL_BIND_SAMPLER_VIEW  (1 << 3)
@@ -293,6 +297,7 @@ struct virgl_caps_v2 {
 uint32_t texture_buffer_offset_alignment;
 uint32_t uniform_buffer_offset_alignment;
 uint32_t shader_buffer_offset_alignment;
+uint32_t capability_bits;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 83cb93138a..9ebb31a1e4 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -135,5 +135,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.texture_buffer_offset_alignment = 0;
caps->caps.v2.uniform_buffer_offset_alignment = 256;
caps->caps.v2.shader_buffer_offset_alignment = 32;
+   caps->caps.v2.capability_bits = 0;
 }
 #endif
-- 
2.13.5

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

[Mesa-dev] [PATCH mesa] autotools: add missing android file to package

[Eric Engestrom]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106779
Fixes: ff904978a1d299a36b587 "gallium/util: Android backtrace support"
Signed-off-by: Eric Engestrom 
---
 src/gallium/auxiliary/Makefile.am | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/auxiliary/Makefile.am 
b/src/gallium/auxiliary/Makefile.am
index 07856e5a5289e00dd3d2..6b048b8eebf6380389d4 100644
--- a/src/gallium/auxiliary/Makefile.am
+++ b/src/gallium/auxiliary/Makefile.am
@@ -118,6 +118,7 @@ EXTRA_DIST = \
postprocess/ADDING \
rbug/README \
target-helpers \
+   util/u_debug_stack_android.cpp \
util/u_format.csv \
util/u_format_pack.py \
util/u_format_parse.py \
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH mesa 1/3] egl: rewire the build systems to use libwayland-egl

[Matt Turner]

On Mon, Jun 4, 2018 at 9:47 AM, Eric Engestrom  wrote:
> On Monday, 2018-06-04 09:15:06 -0700, Matt Turner wrote:
>> On Thu, May 31, 2018 at 10:22 AM, Emil Velikov  
>> wrote:
>> > On 29 May 2018 at 15:41, Eric Engestrom  wrote:
>> >> Cc: Emil Velikov 
>> >> Cc: Daniel Stone 
>> >> Signed-off-by: Eric Engestrom 
>> >> ---
>> >> A couple things worth mentioning:
>> >> - I chose to add libwayland-egl as a separate dependency for EGL rather
>> >>   than bumping the libwayland required version, so that old libwayland
>> >>   can still be used if EGL is not needed. I'm happy to squash those if
>> >>   we'd rather simply bump the libwayland version.
>> >> - There is one non-build-system change in there, in platform_wayland.c,
>> >>   because the wayland-egl-backend.h we had and the one in wayland have
>> >>   diverged (for C++ compatibility IIRC, which we didn't need). I'm
>> >>   thinking it might be best to split this out as a separate change
>> >>   before the move in this commit, but it would probably involve so much
>> >>   changes (like the testing scripts) that I preferred to just squash it
>> >>   in here.
>> > IMHO keeping Wayland 1.15 optional is fine for the time being. I would
>> > strongly recommend we make it compulsory around the 18.2 branch point.
>> >
>> > This way:
>> > a) devs using master will be less frustrated when their distro is missing 
>> > 1.15
>> > b) less code and no "hidden" dependency that sometimes cause problems
>> >
>> > Since there's a handful of bits that need sorting, I'm re-spinning the 
>> > series.
>> > I will send it to the backburner in a couple of minutes and it will be
>> > on the list ~10 mins later.
>>
>> As a distro maintainer, I'm really tired of waiting. The associated
>> patch has been in Wayland for almost four months and in a release for
>> nearly two. Can we just land the patches that Eric took over, and you
>> can finish up anything you see separately?
>
> I think I'll land my series tomorrow at lunch (with your comment about
> s/libwayland/wayland/) if Emil hasn't sent his changes by then; sounds good?

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

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

Got it, thanks.  Let me send a patch to virglrenderer to change
tgsi_invariant to some sort of bitset, since when it lands it'll just
need one bit.
On Mon, Jun 4, 2018 at 9:39 AM Gert Wollny  wrote:
>
> Am Montag, den 04.06.2018, 09:07 -0700 schrieb Gurchetan Singh:
> > The tgsi_invariant code never landed in the Mesa side.  Is the caps
> > code is resilient enough to handle this case?  From my understanding
> > the guest caps and host caps don't have to match exactly, and the
> > "right thing" will be done.
>
> I don't think so. When I implemented what I sent as RFC to the virgl
> list, the tgsi_invariant and shader_buffer_offset_alignment were in the
> virglrenderer caps.v2 struct but not in the guest side version of the
> struct, and since I added the new values after these two in
> virglrenderer the output was garbage, but after adding these two values
> also in the guest side struct the output was okay.
>
> Brousing through the qemu code it seems to me that the caps structure
> is simply send as a blob, and both sides have to know the layout to
> make sense of it.
>
> Best,
> Gert
>
> > On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny 
> > wrote:
> > >
> > > Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
> > > gurchetansi...@chromium.org:
> > > > This is the SSBO analogue to fe0647. User supplied data must
> > > > be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> > > >
> > > > This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches
> > > > with
> > > > Nvidia hardware, but this patch standalone can applied to master.
> > > > The
> > > > alignment restriction on Nvidia is 32, hence the default value.
> > > >
> > > > Example tests:
> > > >dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
> > > >dEQP-
> > > > GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std
> > > > 430
> > > >
> > > > v2: Move to a better place in case statement
> > > > ---
> > > >  src/gallium/drivers/virgl/virgl_hw.h | 1 +
> > > >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> > > >  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> > > >  3 files changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> > > > b/src/gallium/drivers/virgl/virgl_hw.h
> > > > index 93849c03dd..624be3b271 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_hw.h
> > > > +++ b/src/gallium/drivers/virgl/virgl_hw.h
> > > > @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
> > > >  int32_t max_texture_gather_offset;
> > > >  uint32_t texture_buffer_offset_alignment;
> > > >  uint32_t uniform_buffer_offset_alignment;
> > > > +uint32_t shader_buffer_offset_alignment;
> > > >  };
> > >
> > > This conflicts with
> > >
> > >https://patchwork.freedesktop.org/patch/216081/
> > >
> > > (Dave, you wrote there that this landed,  but I don't see it on the
> > > mesa side).
> > >
> > > In virglrenderer the order is
> > > ...
> > > uint32_t uniform_buffer_offset_alignment;
> > > uint32_t tgsi_invariant;
> > > uint32_t shader_buffer_offset_alignment;
> > >
> > > Best,
> > > Gert
> > >
> > > >
> > > >  union virgl_caps {
> > > > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > > > b/src/gallium/drivers/virgl/virgl_screen.c
> > > > index 02613f1866..f183752d63 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > > > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > > > @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen,
> > > > enum
> > > > pipe_cap param)
> > > >return vscreen->caps.caps.v1.bset.has_sample_shading;
> > > > case PIPE_CAP_CULL_DISTANCE:
> > > >return vscreen->caps.caps.v1.bset.has_cull;
> > > > +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > > > +  return vscreen-
> > > > >caps.caps.v2.shader_buffer_offset_alignment;
> > > > case PIPE_CAP_TEXTURE_GATHER_SM5:
> > > > case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> > > > case PIPE_CAP_FAKE_SW_MSAA:
> > > > @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen,
> > > > enum
> > > > pipe_cap param)
> > > > case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
> > > > case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> > > > case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> > > > -   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > > > case PIPE_CAP_INVALIDATE_BUFFER:
> > > > case PIPE_CAP_GENERATE_MIPMAP:
> > > > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> > > > diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> > > > b/src/gallium/drivers/virgl/virgl_winsys.h
> > > > index 99e98ad9c9..c36b957aba 100644
> > > > --- a/src/gallium/drivers/virgl/virgl_winsys.h
> > > > +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> > > > @@ -134,5 +134,6 @@ static inline void
> > > > virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> > > > caps->caps.v2.max_texture_gather_offset = 7;
> > > > caps->caps.v2.texture_buffer_offset_alignment = 32;
> > > > 

Re: [Mesa-dev] [PATCH mesa 1/3] egl: rewire the build systems to use libwayland-egl

[Eric Engestrom]

On Monday, 2018-06-04 09:15:06 -0700, Matt Turner wrote:
> On Thu, May 31, 2018 at 10:22 AM, Emil Velikov  
> wrote:
> > On 29 May 2018 at 15:41, Eric Engestrom  wrote:
> >> Cc: Emil Velikov 
> >> Cc: Daniel Stone 
> >> Signed-off-by: Eric Engestrom 
> >> ---
> >> A couple things worth mentioning:
> >> - I chose to add libwayland-egl as a separate dependency for EGL rather
> >>   than bumping the libwayland required version, so that old libwayland
> >>   can still be used if EGL is not needed. I'm happy to squash those if
> >>   we'd rather simply bump the libwayland version.
> >> - There is one non-build-system change in there, in platform_wayland.c,
> >>   because the wayland-egl-backend.h we had and the one in wayland have
> >>   diverged (for C++ compatibility IIRC, which we didn't need). I'm
> >>   thinking it might be best to split this out as a separate change
> >>   before the move in this commit, but it would probably involve so much
> >>   changes (like the testing scripts) that I preferred to just squash it
> >>   in here.
> > IMHO keeping Wayland 1.15 optional is fine for the time being. I would
> > strongly recommend we make it compulsory around the 18.2 branch point.
> >
> > This way:
> > a) devs using master will be less frustrated when their distro is missing 
> > 1.15
> > b) less code and no "hidden" dependency that sometimes cause problems
> >
> > Since there's a handful of bits that need sorting, I'm re-spinning the 
> > series.
> > I will send it to the backburner in a couple of minutes and it will be
> > on the list ~10 mins later.
> 
> As a distro maintainer, I'm really tired of waiting. The associated
> patch has been in Wayland for almost four months and in a release for
> nearly two. Can we just land the patches that Eric took over, and you
> can finish up anything you see separately?

I think I'll land my series tomorrow at lunch (with your comment about
s/libwayland/wayland/) if Emil hasn't sent his changes by then; sounds good?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gert Wollny]

Am Montag, den 04.06.2018, 09:07 -0700 schrieb Gurchetan Singh:
> The tgsi_invariant code never landed in the Mesa side.  Is the caps
> code is resilient enough to handle this case?  From my understanding
> the guest caps and host caps don't have to match exactly, and the
> "right thing" will be done.

I don't think so. When I implemented what I sent as RFC to the virgl
list, the tgsi_invariant and shader_buffer_offset_alignment were in the
virglrenderer caps.v2 struct but not in the guest side version of the
struct, and since I added the new values after these two in 
virglrenderer the output was garbage, but after adding these two values
also in the guest side struct the output was okay.

Brousing through the qemu code it seems to me that the caps structure 
is simply send as a blob, and both sides have to know the layout to
make sense of it. 

Best, 
Gert

> On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny 
> wrote:
> > 
> > Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
> > gurchetansi...@chromium.org:
> > > This is the SSBO analogue to fe0647. User supplied data must
> > > be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> > > 
> > > This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches
> > > with
> > > Nvidia hardware, but this patch standalone can applied to master.
> > > The
> > > alignment restriction on Nvidia is 32, hence the default value.
> > > 
> > > Example tests:
> > >dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
> > >dEQP-
> > > GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std
> > > 430
> > > 
> > > v2: Move to a better place in case statement
> > > ---
> > >  src/gallium/drivers/virgl/virgl_hw.h | 1 +
> > >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> > >  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> > >  3 files changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> > > b/src/gallium/drivers/virgl/virgl_hw.h
> > > index 93849c03dd..624be3b271 100644
> > > --- a/src/gallium/drivers/virgl/virgl_hw.h
> > > +++ b/src/gallium/drivers/virgl/virgl_hw.h
> > > @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
> > >  int32_t max_texture_gather_offset;
> > >  uint32_t texture_buffer_offset_alignment;
> > >  uint32_t uniform_buffer_offset_alignment;
> > > +uint32_t shader_buffer_offset_alignment;
> > >  };
> > 
> > This conflicts with
> > 
> >https://patchwork.freedesktop.org/patch/216081/
> > 
> > (Dave, you wrote there that this landed,  but I don't see it on the
> > mesa side).
> > 
> > In virglrenderer the order is
> > ...
> > uint32_t uniform_buffer_offset_alignment;
> > uint32_t tgsi_invariant;
> > uint32_t shader_buffer_offset_alignment;
> > 
> > Best,
> > Gert
> > 
> > > 
> > >  union virgl_caps {
> > > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > > b/src/gallium/drivers/virgl/virgl_screen.c
> > > index 02613f1866..f183752d63 100644
> > > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > > @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen,
> > > enum
> > > pipe_cap param)
> > >return vscreen->caps.caps.v1.bset.has_sample_shading;
> > > case PIPE_CAP_CULL_DISTANCE:
> > >return vscreen->caps.caps.v1.bset.has_cull;
> > > +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > > +  return vscreen-
> > > >caps.caps.v2.shader_buffer_offset_alignment;
> > > case PIPE_CAP_TEXTURE_GATHER_SM5:
> > > case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> > > case PIPE_CAP_FAKE_SW_MSAA:
> > > @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen,
> > > enum
> > > pipe_cap param)
> > > case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
> > > case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> > > case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> > > -   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > > case PIPE_CAP_INVALIDATE_BUFFER:
> > > case PIPE_CAP_GENERATE_MIPMAP:
> > > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> > > diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> > > b/src/gallium/drivers/virgl/virgl_winsys.h
> > > index 99e98ad9c9..c36b957aba 100644
> > > --- a/src/gallium/drivers/virgl/virgl_winsys.h
> > > +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> > > @@ -134,5 +134,6 @@ static inline void
> > > virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> > > caps->caps.v2.max_texture_gather_offset = 7;
> > > caps->caps.v2.texture_buffer_offset_alignment = 32;
> > > caps->caps.v2.uniform_buffer_offset_alignment = 256;
> > > +   caps->caps.v2.shader_buffer_offset_alignment = 32;
> > >  }
> > >  #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa 1/3] egl: rewire the build systems to use libwayland-egl

[Matt Turner]

On Thu, May 31, 2018 at 10:22 AM, Emil Velikov  wrote:
> On 29 May 2018 at 15:41, Eric Engestrom  wrote:
>> Cc: Emil Velikov 
>> Cc: Daniel Stone 
>> Signed-off-by: Eric Engestrom 
>> ---
>> A couple things worth mentioning:
>> - I chose to add libwayland-egl as a separate dependency for EGL rather
>>   than bumping the libwayland required version, so that old libwayland
>>   can still be used if EGL is not needed. I'm happy to squash those if
>>   we'd rather simply bump the libwayland version.
>> - There is one non-build-system change in there, in platform_wayland.c,
>>   because the wayland-egl-backend.h we had and the one in wayland have
>>   diverged (for C++ compatibility IIRC, which we didn't need). I'm
>>   thinking it might be best to split this out as a separate change
>>   before the move in this commit, but it would probably involve so much
>>   changes (like the testing scripts) that I preferred to just squash it
>>   in here.
> IMHO keeping Wayland 1.15 optional is fine for the time being. I would
> strongly recommend we make it compulsory around the 18.2 branch point.
>
> This way:
> a) devs using master will be less frustrated when their distro is missing 1.15
> b) less code and no "hidden" dependency that sometimes cause problems
>
> Since there's a handful of bits that need sorting, I'm re-spinning the series.
> I will send it to the backburner in a couple of minutes and it will be
> on the list ~10 mins later.

As a distro maintainer, I'm really tired of waiting. The associated
patch has been in Wayland for almost four months and in a release for
nearly two. Can we just land the patches that Eric took over, and you
can finish up anything you see separately?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[Gurchetan Singh]

The tgsi_invariant code never landed in the Mesa side.  Is the caps
code is resilient enough to handle this case?  From my understanding
the guest caps and host caps don't have to match exactly, and the
"right thing" will be done.
On Mon, Jun 4, 2018 at 6:03 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
> gurchetansi...@chromium.org:
> > This is the SSBO analogue to fe0647. User supplied data must
> > be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> >
> > This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
> > Nvidia hardware, but this patch standalone can applied to master. The
> > alignment restriction on Nvidia is 32, hence the default value.
> >
> > Example tests:
> >dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
> >dEQP-
> > GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
> >
> > v2: Move to a better place in case statement
> > ---
> >  src/gallium/drivers/virgl/virgl_hw.h | 1 +
> >  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
> >  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
> >  3 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> > b/src/gallium/drivers/virgl/virgl_hw.h
> > index 93849c03dd..624be3b271 100644
> > --- a/src/gallium/drivers/virgl/virgl_hw.h
> > +++ b/src/gallium/drivers/virgl/virgl_hw.h
> > @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
> >  int32_t max_texture_gather_offset;
> >  uint32_t texture_buffer_offset_alignment;
> >  uint32_t uniform_buffer_offset_alignment;
> > +uint32_t shader_buffer_offset_alignment;
> >  };
> This conflicts with
>
>https://patchwork.freedesktop.org/patch/216081/
>
> (Dave, you wrote there that this landed,  but I don't see it on the
> mesa side).
>
> In virglrenderer the order is
> ...
> uint32_t uniform_buffer_offset_alignment;
> uint32_t tgsi_invariant;
> uint32_t shader_buffer_offset_alignment;
>
> Best,
> Gert
>
> >
> >  union virgl_caps {
> > diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> > b/src/gallium/drivers/virgl/virgl_screen.c
> > index 02613f1866..f183752d63 100644
> > --- a/src/gallium/drivers/virgl/virgl_screen.c
> > +++ b/src/gallium/drivers/virgl/virgl_screen.c
> > @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen, enum
> > pipe_cap param)
> >return vscreen->caps.caps.v1.bset.has_sample_shading;
> > case PIPE_CAP_CULL_DISTANCE:
> >return vscreen->caps.caps.v1.bset.has_cull;
> > +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > +  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
> > case PIPE_CAP_TEXTURE_GATHER_SM5:
> > case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> > case PIPE_CAP_FAKE_SW_MSAA:
> > @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen, enum
> > pipe_cap param)
> > case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
> > case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> > case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> > -   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> > case PIPE_CAP_INVALIDATE_BUFFER:
> > case PIPE_CAP_GENERATE_MIPMAP:
> > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> > diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> > b/src/gallium/drivers/virgl/virgl_winsys.h
> > index 99e98ad9c9..c36b957aba 100644
> > --- a/src/gallium/drivers/virgl/virgl_winsys.h
> > +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> > @@ -134,5 +134,6 @@ static inline void
> > virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> > caps->caps.v2.max_texture_gather_offset = 7;
> > caps->caps.v2.texture_buffer_offset_alignment = 32;
> > caps->caps.v2.uniform_buffer_offset_alignment = 256;
> > +   caps->caps.v2.shader_buffer_offset_alignment = 32;
> >  }
> >  #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] trace: Fix trace_context_transfer_unmap methods.

[Roland Scheidegger]

Alright, this now has all the right bits buffer/texture_subdata would use.
That said, I'm still a bit confused why this is necessary. Is that just
so the dumped output looks like it's the same as if you called
texture/buffer_subdata? Makes sense then, but in reality it still was a
transfer.

Reviewed-by: Roland Scheidegger 


Am 04.06.2018 um 15:01 schrieb Jose Fonseca:
> The emitted buffer_subdata/texture_subdata call didn't match the
> respective signatures.
> 
> v2: Actually emit buffer_subdata call.
> ---
>  .../auxiliary/driver_trace/tr_context.c   | 60 +--
>  1 file changed, 42 insertions(+), 18 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c 
> b/src/gallium/auxiliary/driver_trace/tr_context.c
> index 6d918d42a38..dc091aee2e9 100644
> --- a/src/gallium/auxiliary/driver_trace/tr_context.c
> +++ b/src/gallium/auxiliary/driver_trace/tr_context.c
> @@ -1430,35 +1430,59 @@ trace_context_transfer_unmap(struct pipe_context 
> *_context,
> */
>  
>struct pipe_resource *resource = transfer->resource;
> -  unsigned level = transfer->level;
>unsigned usage = transfer->usage;
>const struct pipe_box *box = >box;
>unsigned stride = transfer->stride;
>unsigned layer_stride = transfer->layer_stride;
>  
> -  if (resource->target == PIPE_BUFFER)
> +  if (resource->target == PIPE_BUFFER) {
> + unsigned offset = box->x;
> + unsigned size = box->width;
> +
>   trace_dump_call_begin("pipe_context", "buffer_subdata");
> -  else
> +
> + trace_dump_arg(ptr, context);
> + trace_dump_arg(ptr, resource);
> + trace_dump_arg(uint, usage);
> + trace_dump_arg(uint, offset);
> + trace_dump_arg(uint, size);
> +
> + trace_dump_arg_begin("data");
> + trace_dump_box_bytes(tr_trans->map,
> +  resource,
> +  box,
> +  stride,
> +  layer_stride);
> + trace_dump_arg_end();
> +
> + trace_dump_arg(uint, stride);
> + trace_dump_arg(uint, layer_stride);
> +
> + trace_dump_call_end();
> +  } else {
> + unsigned level = transfer->level;
> +
>   trace_dump_call_begin("pipe_context", "texture_subdata");
>  
> -  trace_dump_arg(ptr, context);
> -  trace_dump_arg(ptr, resource);
> -  trace_dump_arg(uint, level);
> -  trace_dump_arg(uint, usage);
> -  trace_dump_arg(box, box);
> + trace_dump_arg(ptr, context);
> + trace_dump_arg(ptr, resource);
> + trace_dump_arg(uint, level);
> + trace_dump_arg(uint, usage);
> + trace_dump_arg(box, box);
>  
> -  trace_dump_arg_begin("data");
> -  trace_dump_box_bytes(tr_trans->map,
> -   resource,
> -   box,
> -   stride,
> -   layer_stride);
> -  trace_dump_arg_end();
> + trace_dump_arg_begin("data");
> + trace_dump_box_bytes(tr_trans->map,
> +  resource,
> +  box,
> +  stride,
> +  layer_stride);
> + trace_dump_arg_end();
>  
> -  trace_dump_arg(uint, stride);
> -  trace_dump_arg(uint, layer_stride);
> + trace_dump_arg(uint, stride);
> + trace_dump_arg(uint, layer_stride);
>  
> -  trace_dump_call_end();
> + trace_dump_call_end();
> +  }
>  
>tr_trans->map = NULL;
> }
> 

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

[Mesa-dev] [PATCH] virgl: add shader offset alignment to to v2 caps struct

[gurchetansi...@chromium.org]

This is the SSBO analogue to fe0647. User supplied data must
be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.

This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
Nvidia hardware, but this patch standalone can applied to master. The
alignment restriction on Nvidia is 32, hence the default value.

Example tests:
   dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
   dEQP-GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430

v2: Move to a better place in case statement
v3: Rebase
---
 src/gallium/drivers/virgl/virgl_hw.h | 1 +
 src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
 src/gallium/drivers/virgl/virgl_winsys.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index 261b690f53..a2c70bf86b 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -292,6 +292,7 @@ struct virgl_caps_v2 {
 int32_t max_texture_gather_offset;
 uint32_t texture_buffer_offset_alignment;
 uint32_t uniform_buffer_offset_alignment;
+uint32_t shader_buffer_offset_alignment;
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index b5f5d9921a..e8d1c75177 100644
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -211,6 +211,8 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
   return vscreen->caps.caps.v1.bset.polygon_offset_clamp;
case PIPE_CAP_QUERY_SO_OVERFLOW:
   return vscreen->caps.caps.v1.bset.transform_feedback_overflow_query;
+   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
+  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
case PIPE_CAP_TEXTURE_GATHER_SM5:
case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
case PIPE_CAP_FAKE_SW_MSAA:
@@ -236,7 +238,6 @@ virgl_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
-   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_GENERATE_MIPMAP:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
diff --git a/src/gallium/drivers/virgl/virgl_winsys.h 
b/src/gallium/drivers/virgl/virgl_winsys.h
index 690e610e19..83cb93138a 100644
--- a/src/gallium/drivers/virgl/virgl_winsys.h
+++ b/src/gallium/drivers/virgl/virgl_winsys.h
@@ -134,5 +134,6 @@ static inline void virgl_ws_fill_new_caps_defaults(struct 
virgl_drm_caps *caps)
caps->caps.v2.max_texture_gather_offset = 7;
caps->caps.v2.texture_buffer_offset_alignment = 0;
caps->caps.v2.uniform_buffer_offset_alignment = 256;
+   caps->caps.v2.shader_buffer_offset_alignment = 32;
 }
 #endif
-- 
2.13.5

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

[Mesa-dev] GitLab migration of Piglit

[Jason Ekstrand]

All,

Sorry for the mess of GitLab e-mails but there are a lot of questions to
ask as this process moves forward.  Today, we're discussing piglit.  I've
included both the mesa and piglit list in the hopes that people will
actually see this e-mail.

Honestly, I expect the migration of piglit to have much less impact on most
people's daily lives than moving the mesa repo.

The biggest question I have is whether we actually want to continue to have
a separate "piglit" group.  With GitLab, we can already give someone
developer access to piglit without giving them developer access to mesa.
Mostly, this is a question of whether we consider piglit to be it's own
project on freedesktop or a sub-project of mesa.  I don't know the answer
to that question.

Thoughts?

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

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #3 from Michael Olbrich  ---
Why not ship the generated files in the tarball like it's done in other parts
of mesa?

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

[Mesa-dev] [Bug 106151] [amdgpu][vulkan] GPU hang (Vega 56) while running game (Rise of the Tomb Raider)

[bugzilla-daemon]

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

--- Comment #14 from Alex Smith  ---
If you're still seeing a hang, could you try the latest game update (released
today)?

-- 
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] virgl: add shader offset alignment to to v2 caps struct

[Gert Wollny]

Am Donnerstag, den 12.04.2018, 18:11 -0700 schrieb
gurchetansi...@chromium.org:
> This is the SSBO analogue to fe0647. User supplied data must
> be a multiple of GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT.
> 
> This fixes 44 GLES31 tests on airlied@'s GLES31 sketch branches with
> Nvidia hardware, but this patch standalone can applied to master. The
> alignment restriction on Nvidia is 32, hence the default value.
> 
> Example tests:
>dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.0
>dEQP-
> GLES31.functional.ssbo.layout.multi_basic_types.single_buffer.std430
> 
> v2: Move to a better place in case statement
> ---
>  src/gallium/drivers/virgl/virgl_hw.h | 1 +
>  src/gallium/drivers/virgl/virgl_screen.c | 3 ++-
>  src/gallium/drivers/virgl/virgl_winsys.h | 1 +
>  3 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/virgl/virgl_hw.h
> b/src/gallium/drivers/virgl/virgl_hw.h
> index 93849c03dd..624be3b271 100644
> --- a/src/gallium/drivers/virgl/virgl_hw.h
> +++ b/src/gallium/drivers/virgl/virgl_hw.h
> @@ -286,6 +286,7 @@ struct virgl_caps_v2 {
>  int32_t max_texture_gather_offset;
>  uint32_t texture_buffer_offset_alignment;
>  uint32_t uniform_buffer_offset_alignment;
> +uint32_t shader_buffer_offset_alignment;
>  };
This conflicts with 

   https://patchwork.freedesktop.org/patch/216081/

(Dave, you wrote there that this landed,  but I don't see it on the
mesa side). 

In virglrenderer the order is 
... 
uint32_t uniform_buffer_offset_alignment;
uint32_t tgsi_invariant;
uint32_t shader_buffer_offset_alignment;

Best, 
Gert 

>  
>  union virgl_caps {
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c
> b/src/gallium/drivers/virgl/virgl_screen.c
> index 02613f1866..f183752d63 100644
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -198,6 +198,8 @@ virgl_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
>return vscreen->caps.caps.v1.bset.has_sample_shading;
> case PIPE_CAP_CULL_DISTANCE:
>return vscreen->caps.caps.v1.bset.has_cull;
> +   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> +  return vscreen->caps.caps.v2.shader_buffer_offset_alignment;
> case PIPE_CAP_TEXTURE_GATHER_SM5:
> case PIPE_CAP_BUFFER_MAP_PERSISTENT_COHERENT:
> case PIPE_CAP_FAKE_SW_MSAA:
> @@ -227,7 +229,6 @@ virgl_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> case PIPE_CAP_TGSI_PACK_HALF_FLOAT:
> case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL:
> case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL:
> -   case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT:
> case PIPE_CAP_INVALIDATE_BUFFER:
> case PIPE_CAP_GENERATE_MIPMAP:
> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
> diff --git a/src/gallium/drivers/virgl/virgl_winsys.h
> b/src/gallium/drivers/virgl/virgl_winsys.h
> index 99e98ad9c9..c36b957aba 100644
> --- a/src/gallium/drivers/virgl/virgl_winsys.h
> +++ b/src/gallium/drivers/virgl/virgl_winsys.h
> @@ -134,5 +134,6 @@ static inline void
> virgl_ws_fill_new_caps_defaults(struct virgl_drm_caps *caps)
> caps->caps.v2.max_texture_gather_offset = 7;
> caps->caps.v2.texture_buffer_offset_alignment = 32;
> caps->caps.v2.uniform_buffer_offset_alignment = 256;
> +   caps->caps.v2.shader_buffer_offset_alignment = 32;
>  }
>  #endif
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] trace: Fix trace_context_transfer_unmap methods.

[Jose Fonseca]

The emitted buffer_subdata/texture_subdata call didn't match the
respective signatures.

v2: Actually emit buffer_subdata call.
---
 .../auxiliary/driver_trace/tr_context.c   | 60 +--
 1 file changed, 42 insertions(+), 18 deletions(-)

diff --git a/src/gallium/auxiliary/driver_trace/tr_context.c 
b/src/gallium/auxiliary/driver_trace/tr_context.c
index 6d918d42a38..dc091aee2e9 100644
--- a/src/gallium/auxiliary/driver_trace/tr_context.c
+++ b/src/gallium/auxiliary/driver_trace/tr_context.c
@@ -1430,35 +1430,59 @@ trace_context_transfer_unmap(struct pipe_context 
*_context,
*/
 
   struct pipe_resource *resource = transfer->resource;
-  unsigned level = transfer->level;
   unsigned usage = transfer->usage;
   const struct pipe_box *box = >box;
   unsigned stride = transfer->stride;
   unsigned layer_stride = transfer->layer_stride;
 
-  if (resource->target == PIPE_BUFFER)
+  if (resource->target == PIPE_BUFFER) {
+ unsigned offset = box->x;
+ unsigned size = box->width;
+
  trace_dump_call_begin("pipe_context", "buffer_subdata");
-  else
+
+ trace_dump_arg(ptr, context);
+ trace_dump_arg(ptr, resource);
+ trace_dump_arg(uint, usage);
+ trace_dump_arg(uint, offset);
+ trace_dump_arg(uint, size);
+
+ trace_dump_arg_begin("data");
+ trace_dump_box_bytes(tr_trans->map,
+  resource,
+  box,
+  stride,
+  layer_stride);
+ trace_dump_arg_end();
+
+ trace_dump_arg(uint, stride);
+ trace_dump_arg(uint, layer_stride);
+
+ trace_dump_call_end();
+  } else {
+ unsigned level = transfer->level;
+
  trace_dump_call_begin("pipe_context", "texture_subdata");
 
-  trace_dump_arg(ptr, context);
-  trace_dump_arg(ptr, resource);
-  trace_dump_arg(uint, level);
-  trace_dump_arg(uint, usage);
-  trace_dump_arg(box, box);
+ trace_dump_arg(ptr, context);
+ trace_dump_arg(ptr, resource);
+ trace_dump_arg(uint, level);
+ trace_dump_arg(uint, usage);
+ trace_dump_arg(box, box);
 
-  trace_dump_arg_begin("data");
-  trace_dump_box_bytes(tr_trans->map,
-   resource,
-   box,
-   stride,
-   layer_stride);
-  trace_dump_arg_end();
+ trace_dump_arg_begin("data");
+ trace_dump_box_bytes(tr_trans->map,
+  resource,
+  box,
+  stride,
+  layer_stride);
+ trace_dump_arg_end();
 
-  trace_dump_arg(uint, stride);
-  trace_dump_arg(uint, layer_stride);
+ trace_dump_arg(uint, stride);
+ trace_dump_arg(uint, layer_stride);
 
-  trace_dump_call_end();
+ trace_dump_call_end();
+  }
 
   tr_trans->map = NULL;
}
-- 
2.17.0

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3] radv: Set active_stages the same whether or not shaders were cached

[Alex Smith]

On 1 June 2018 at 22:51, Dylan Baker  wrote:

> Quoting Samuel Pitoiset (2018-06-01 08:58:42)
> >
> >
> > On 06/01/2018 05:48 PM, Dylan Baker wrote:
> > > Quoting Alex Smith (2018-06-01 07:56:38)
> > >> On 1 June 2018 at 15:48, Dylan Baker  wrote:
> > >>
> > >>  Quoting Alex Smith (2018-05-31 08:44:18)
> > >>  > With GFX9 merged shaders, active_stages would be set to the
> original
> > >>  > stages specified if shaders were not cached, but to the stages
> still
> > >>  > present after merging if they were.
> > >>  >
> > >>  > Be consistent and use the original stages.
> > >>  >
> > >>  > Signed-off-by: Alex Smith 
> > >>  > Cc: "18.1" 
> > >>  > ---
> > >>  >  src/amd/vulkan/radv_pipeline.c | 7 ++-
> > >>  >  1 file changed, 2 insertions(+), 5 deletions(-)
> > >>  >
> > >>  > diff --git a/src/amd/vulkan/radv_pipeline.c
> b/src/amd/vulkan/radv_
> > >>  pipeline.c
> > >>  > index 52734a308a..18dcc43ebe 100644
> > >>  > --- a/src/amd/vulkan/radv_pipeline.c
> > >>  > +++ b/src/amd/vulkan/radv_pipeline.c
> > >>  > @@ -1964,6 +1964,8 @@ void radv_create_shaders(struct
> radv_pipeline
> > >>  *pipeline,
> > >>  > _mesa_sha1_compute(modules[i]
> ->nir->
> > >>  info.name,
> > >>  >
> strlen(modules[i]->
> > >>  nir->info.name),
> > >>  >
> modules[i]->sha1);
> > >>  > +
> > >>  > +   pipeline->active_stages |=
> > >>  mesa_to_vk_shader_stage(i);
> > >>  > }
> > >>  > }
> > >>  >
> > >>  > @@ -1979,10 +1981,6 @@ void radv_create_shaders(struct
> radv_pipeline
> > >>  *pipeline,
> > >>  >
> > >>  > if (radv_create_shader_variants_
> from_pipeline_cache(device,
> > >>  cache, hash, pipeline->shaders) &&
> > >>  > (!modules[MESA_SHADER_GEOMETRY] ||
> pipeline->gs_copy_shader))
> > >>  {
> > >>  > -   for (unsigned i = 0; i < MESA_SHADER_STAGES;
> ++i) {
> > >>  > -   if (pipeline->shaders[i])
> > >>  > -   pipeline->active_stages |=
> > >>  mesa_to_vk_shader_stage(i);
> > >>  > -   }
> > >>  > return;
> > >>  > }
> > >>  >
> > >>  > @@ -2015,7 +2013,6 @@ void radv_create_shaders(struct
> radv_pipeline
> > >>  *pipeline,
> > >>  > stage ?
> stage->pName
> > >>  : "main", i,
> > >>  > stage ?
> stage->
> > >>  pSpecializationInfo : NULL,
> > >>  > flags);
> > >>  > -   pipeline->active_stages |=
> mesa_to_vk_shader_stage(i);
> > >>  >
> > >>  > /* We don't want to alter meta shaders IR
> directly so
> > >>  clone it
> > >>  >  * first.
> > >>  > --
> > >>  > 2.14.3
> > >>  >
> > >>  > ___
> > >>  > mesa-stable mailing list
> > >>  > mesa-sta...@lists.freedesktop.org
> > >>  > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> > >>
> > >>  Hi Alex,
> > >>
> > >>  This doesn't apply cleanly to the 18.1 tree with the following
> collision:
> > >>
> > >>  ++<<< HEAD
> > >>
> > >>   +  stage ?
> stage->
> > >>  pSpecializationInfo : NULL);
> > >>   +  pipeline->active_stages |=
> mesa_to_vk_shader_stage(i);
> > >>
> > >>  ++===
> > >>
> > >>  +   stage ?
> stage->
> > >>  pSpecializationInfo : NULL,
> > >>  +   flags);
> > >>
> > >>  ++>>> 0fa51bfdbe5... radv: Set active_stages the same
> whether or not
> > >>  shaders were cached
> > >>
> > >>  I can remove the flags field (which doesn't exist in 18.1)
> before merging
> > >>  if you
> > >>  think that's the right thing to do. Does that seem reasonable?
> > >>
> > >>
> > >> Yes, that's correct. Should just be removing the
> pipeline->active_stages line
> > >> at that point.
> > >>
> > >> Thanks,
> > >> Alex
> > >
> > > Thanks! This is in the tree for 18.1.2.
> >
> > Apparently, this series regresses some CTS on my side, Bas will
> > investigate, would be nice to not release 18.1.2 without this fixed. :)
> >
>
> Let me know what you all want to do, 18.1.1 happened today, and 18.1.2 is
> planned for release on the 15th, so you have some time to figure it out.
>

This commit fixes the issue:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=2835b6baf446d0ff3b3df6eefc57b248a505af36

Thanks,
Alex


>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 5/6] r600g: some -Wsign-compare fixes

[Konstantin Kharlamov]

On 03.06.2018 16:03, Gert Wollny wrote:

Patches 2-4 Reviewed-By: Gert Wollny 
I can't push them though

I'd like to add that for the future it would be better to

   - send the patches for st and r600 as separate series, this would
 make it easier to find reviewers
   - when fixing warning to add the specific warnings you fixed  to
 the commit messages (actually Ian Romanick gave me that hint)

Best,
Gert


Thank you for R-bs, and tips!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 6/6] r600g: fix unused variable warning

[Konstantin Kharlamov]

On 03.06.2018 15:41, Gert Wollny wrote:

This patch doesn't apply, the "int i" was deleted already; I didn't
find the commit though.


Oh, well. Good thing somebody that cleaned it up already :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] wayland/egl: initialize window surface size to window size

[Daniel Stone]

Hi Juan,

On 4 June 2018 at 12:43, Juan A. Suarez Romero  wrote:
> On Fri, 2018-06-01 at 16:32 +0100, Daniel Stone wrote:
>> I think you're right, and this needs more rework to be consistent.
>>
>> wl_egl_window_get_attached_size() always returns the size of the last
>> attached buffer (if there have been any); that is good and consistent.
>
> Let's focus now on this, as I already sent a V2 patch to properly initialize
> surface Width/Height values.

Right, but in doing so it introduces an inconsistency. As below:
wl_egl_create_window(w1, h1);
eglCreateSurface();
eglQuerySurface(EGL_{WIDTH,HEIGHT});
wl_egl_resize_window(w2, h2);
eglQuerySurface(EGL_{WIDTH,HEIGHT});
glClear();
eglSwapBuffers();
wl_egl_resize_window(w3, h3);
eglQuerySurface(EGL_{WIDTH,HEIGHT});
glClear();
eglQuerySurface(EGL_{WIDTH,HEIGHT});
eglSwapBuffers();

The first query will correctly return (w1,h1). The second query will
incorrectly also return (w1,h1), even though the surface will never
have that size. The third query will return (w2,h2) as the
last-attached size, even though the surface will be (w3,h3) on next
draw. The fourth query will correctly return (w3,h3).

I would like this to be consistent: my suggestion is that a query for
the surface size always returns the size that the surface will become
on the next eglSwapBuffers.

> In dEQP-EGL.functional.resize.surface_size.* , this is what the test does
> initially:
>
> wl_egl_window_create(w1, h1);
> eglCreateWindowSurface();
> egl.makeCurrent()
> wl_egl_window_get_attached_size();
>
> The failing part is the results for wl_egl_window_get_attached_size(): test
> assumes it will return (w1, h1) (and this is what Nvidia implementation seems 
> to
> return), but Mesa returns (0, 0).
>
> If I understand correctly, Mesa returns (0, 0) because there is no buffer
> attached. If we call before eglSwapBuffers() (which internally calls
> wl_surface_attach()) and afterwards wl_egl_window_get_attached_size(), then 
> Mesa
> would return (w1, h1) because now the buffer is attached to the window.
>
> Am I correct?

Yep, that is correct.

> Because it seems like NVidia implementation is returning (w1,h1) because at 
> that
> moment it has an attached buffer. Wondering if eglMakeCurrent() is performing
> such attachment.

Yes, that's correct, and I believe eglMakeCurrent() does perform that
attachment. The NVIDIA/EGLStreams implementation is extremely broken
in that regard, in a way which does break genuine real-world
applications. We had a long discussion on wayland-devel@ when the
EGLStreams implementation was first posted, detailing the ways in
which their implementation causes genuine problems for real-world
users, and can provoke client deadlocks. I am very opposed to
supporting or codifying that behaviour.

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

Re: [Mesa-dev] [PATCH][v2] wayland/egl: initialize window surface size to window size

[Juan A. Suarez Romero]

Forgot to say this is an V2 patch.


J.A.


On Mon, 2018-06-04 at 12:27 +0200, Juan A. Suarez Romero wrote:
> When creating a windows surface with eglCreateWindowSurface(), the
> width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is
> invalid until buffers are updated (like calling glClear()).
> 
> But according to EGL 1.5 spec, section 3.5.6 ("Surface Attributes"):
> 
>   "Querying EGL_WIDTH and EGL_HEIGHT returns respectively the width and
>height, in pixels, of the surface. For a window or pixmap surface,
>these values are initially equal to the width and height of the
>native window or pixmap with respect to which the surface was
>created"
> 
> This fixes dEQP-EGL.functional.color_clears.* CTS tests
> 
> v2:
> - Do not modify attached_{width,height} (Daniel)
> - Do not update size on resizing window (Brendan)
> 
> CC: Daniel Stone 
> CC: Brendan King 
> ---
>  src/egl/drivers/dri2/platform_wayland.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index 63da21cdf55..f62cbbc5c02 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -255,6 +255,9 @@ dri2_wl_create_window_surface(_EGLDriver *drv, 
> _EGLDisplay *disp,
>goto cleanup_surf;
> }
>  
> +   dri2_surf->base.Width = window->width;
> +   dri2_surf->base.Height = window->height;
> +
> visual_idx = dri2_wl_visual_idx_from_config(dri2_dpy, config);
> assert(visual_idx != -1);
>  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] wayland/egl: initialize window surface size to window size

[Juan A. Suarez Romero]

On Fri, 2018-06-01 at 16:32 +0100, Daniel Stone wrote:
> Hi,
> 
> On 1 June 2018 at 15:35, Brendan King  wrote:
> > IMG has a similar patch to the one you describe, but without the changes to
> > the resize_callback, so just this bit:
> > 
> > @@ -255,6 +257,12 @@ dri2_wl_create_window_surface(_EGLDriver *drv,
> > _EGLDisplay *disp,
> >goto cleanup_surf;
> > }
> > 
> > +   dri2_surf->base.Width = window->width;
> > +   dri2_surf->base.Height = window->height;
> > +
> > 
> > I don't think the resize_callback changes are necessary.
> 
> I think you're right, and this needs more rework to be consistent.
> 
> wl_egl_window_get_attached_size() always returns the size of the last
> attached buffer (if there have been any); that is good and consistent.
> 

Let's focus now on this, as I already sent a V2 patch to properly initialize
surface Width/Height values.


In dEQP-EGL.functional.resize.surface_size.* , this is what the test does
initially:

wl_egl_window_create(w1, h1);
eglCreateWindowSurface();
egl.makeCurrent()
wl_egl_window_get_attached_size();

The failing part is the results for wl_egl_window_get_attached_size(): test
assumes it will return (w1, h1) (and this is what Nvidia implementation seems to
return), but Mesa returns (0, 0). 

If I understand correctly, Mesa returns (0, 0) because there is no buffer
attached. If we call before eglSwapBuffers() (which internally calls
wl_surface_attach()) and afterwards wl_egl_window_get_attached_size(), then Mesa
would return (w1, h1) because now the buffer is attached to the window.

Am I correct?

Because it seems like NVidia implementation is returning (w1,h1) because at that
moment it has an attached buffer. Wondering if eglMakeCurrent() is performing
such attachment.

J.A.



> It seems like the desired semantic for handling EGL surface-size
> queries, is that the query returns the size of the buffer that will be
> attached at the next eglSwapBuffers. For example, if you issue
> wl_egl_window_resize() in between eglSwapBuffers() and the first draw
> call, the surface-size query should reflect this new size immediately
> after the function returns. However, if you issue
> wl_egl_window_resize() after a frame's first draw call has been made,
> querying the surface size should return the old size until
> eglSwapBuffers() has been called, since the resize call has no effect
> on the buffer which will actually be attached when calling SwapBuffers
> in that frame.
> 
> Cheers,
> Daniel
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #2 from fred...@rinnestam.se ---
Bummer! No workaround available to avoid mako? It does introduce a lot of
previously unneeded depencencies.

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

[Mesa-dev] [Bug 106784] 18.1.1 autotools build fail without mako

[bugzilla-daemon]

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

--- Comment #1 from Eric Engestrom  ---
I just sent a patch to the ML that should fix it; unfortunately for you, the
fix is that it should've failed earlier, you do need mako when building radv.
(cc'ed you on the patch so that you can confirm the configure step now fails)

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

[Mesa-dev] [PATCH mesa] configure: radv depends on mako

[Eric Engestrom]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106784
Fixes: 17201a2eb0b1b85387136 "radv: port to using updated anv
  entrypoint/extension generator."
Signed-off-by: Eric Engestrom 
---
 configure.ac | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure.ac b/configure.ac
index 02dca4547c8482a0b164..600127af8f68e1bd5c25 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2099,6 +2099,9 @@ if test -n "$with_vulkan_drivers"; then
 PKG_CHECK_MODULES([AMDGPU], [libdrm >= $LIBDRM_AMDGPU_REQUIRED 
libdrm_amdgpu >= $LIBDRM_AMDGPU_REQUIRED])
 radeon_llvm_check $LLVM_REQUIRED_RADV "radv"
 require_x11_dri3 "radv"
+if test "x$acv_mako_found" = xno; then
+AC_MSG_ERROR([Python mako module v$PYTHON_MAKO_REQUIRED or 
higher not found])
+fi
 HAVE_RADEON_VULKAN=yes
 ;;
 *)
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [PATCH] i965: Fix batch-last mode to properly swap BOs.

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 04/06/18 11:18, Kenneth Graunke wrote:

On pre-4.13 kernels, which don't support I915_EXEC_BATCH_FIRST, we move
the validation list entry to the end...but incorrectly left the exec_bo
array alone, causing a mismatch where exec_bos[0] no longer corresponded
with validation_list[0] (and similarly for the last entry).

One example of resulting breakage is that we'd update bo->gtt_offset
based on the wrong buffer.  This wreaked total havoc when trying to use
softpin, and likely caused unnecessary relocations in the normal case.

Fixes: 29ba502a4e28471f67e4e904ae503157087efd20 (i965: Use 
I915_EXEC_BATCH_FIRST when available.)
---
  src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 2cee2376c0e..462789e8cfb 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -798,11 +798,16 @@ submit_batch(struct brw_context *brw, int in_fence_fd, 
int *out_fence_fd)
} else {
   /* Move the batch to the end of the validation list */
   struct drm_i915_gem_exec_object2 tmp;
+ struct brw_bo *tmp_bo;
   const unsigned index = batch->exec_count - 1;
  
   tmp = *entry;

   *entry = batch->validation_list[index];
   batch->validation_list[index] = tmp;
+
+ tmp_bo = batch->exec_bos[0];
+ batch->exec_bos[0] = batch->exec_bos[index];
+ batch->exec_bos[index] = tmp_bo;
}
  
ret = execbuffer(dri_screen->fd, batch, brw->hw_ctx,



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

Re: [Mesa-dev] [PATCH] radv: Don't pass a TESS_EVAL shader when tesselation is not enabled.

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 06/02/2018 02:31 PM, Bas Nieuwenhuizen wrote:

Otherwise on pre-GFX9, if the constant layout allows both TESS_EVAL and
GEOMETRY shaders, but the PIPELINE has only GEOMETRY, it would return the
GEOMETRY shader for the TESS_EVAL shader.

This would cause the flush_constants code to emit the GEOMETRY constants
to the TESS_EVAL registers and then conclude that it did not need to set
the GEOMETRY shader registers.

Fixes: dfff9fb6f8d "radv: Handle GFX9 merged shaders in radv_flush_constants()"
CC: 18.1 
CC: Alex Smith 
CC: Samuel Pitoiset 
---
  src/amd/vulkan/radv_pipeline.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index ff647ed9af3..375f7c357d3 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1594,6 +1594,8 @@ radv_get_shader(struct radv_pipeline *pipeline,
if (pipeline->shaders[MESA_SHADER_GEOMETRY])
return pipeline->shaders[MESA_SHADER_GEOMETRY];
} else if (stage == MESA_SHADER_TESS_EVAL) {
+   if (!radv_pipeline_has_tess(pipeline))
+   return NULL;
if (pipeline->shaders[MESA_SHADER_TESS_EVAL])
return pipeline->shaders[MESA_SHADER_TESS_EVAL];
if (pipeline->shaders[MESA_SHADER_GEOMETRY])


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

[Mesa-dev] [PATCH mesa] meson: fix platforms check for `-D egl=true`

[Eric Engestrom]

Fixes: 0ed6a87a106b6e2266e0 "meson: fix platforms=[]"
Reported-by: Christoph Haag 
Signed-off-by: Eric Engestrom 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 7b7c118d77b11cc38f7b..1d1b2a979b1de80ddd06 100644
--- a/meson.build
+++ b/meson.build
@@ -292,7 +292,7 @@ elif _egl == 'true'
 error('EGL requires dri')
   elif not with_shared_glapi
 error('EGL requires shared-glapi')
-  elif with_platforms
+  elif not with_platforms
 error('No platforms specified, consider -Dplatforms=drm,x11 at least')
   elif not ['disabled', 'dri'].contains(with_glx)
 error('EGL requires dri, but a GLX is being built without dri')
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH] i965: Fix fractional viewport coordinates handling on gen8+

[Danylo Piliaiev]

On gen8+ fractional translation of viewport moved it by a whole integer.
The behaviour in this case isn't defined anywhere but some apps like
Wine may depend on viewport's width and height being ceiled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106526
Signed-off-by: Danylo Piliaiev 
---
 src/mesa/drivers/dri/i965/genX_state_upload.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
b/src/mesa/drivers/dri/i965/genX_state_upload.c
index 88fde9d..886290f 100644
--- a/src/mesa/drivers/dri/i965/genX_state_upload.c
+++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
@@ -2586,12 +2586,11 @@ genX(upload_sf_clip_viewport)(struct brw_context *brw)
* pipeline stall so we're better off just being a little more clever
* with our viewport so we can emit it once at context creation time.
*/
-  const float viewport_Xmin = MAX2(ctx->ViewportArray[i].X, 0);
-  const float viewport_Ymin = MAX2(ctx->ViewportArray[i].Y, 0);
-  const float viewport_Xmax =
- MIN2(ctx->ViewportArray[i].X + ctx->ViewportArray[i].Width, fb_width);
-  const float viewport_Ymax =
- MIN2(ctx->ViewportArray[i].Y + ctx->ViewportArray[i].Height, 
fb_height);
+  const struct gl_viewport_attrib *vp = >ViewportArray[i];
+  const float viewport_Xmin = MAX2(vp->X, 0);
+  const float viewport_Ymin = MAX2(vp->Y, 0);
+  const float viewport_Xmax = MIN2(ceilf(vp->X + vp->Width), fb_width);
+  const float viewport_Ymax = MIN2(ceilf(vp->Y + vp->Height), fb_height);
 
   if (render_to_fbo) {
  sfv.XMinViewPort = viewport_Xmin;
-- 
2.7.4

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

[Mesa-dev] [PATCH] wayland/egl: initialize window surface size to window size

[Juan A. Suarez Romero]

When creating a windows surface with eglCreateWindowSurface(), the
width and height returned by eglQuerySurface(EGL_{WIDTH,HEIGHT}) is
invalid until buffers are updated (like calling glClear()).

But according to EGL 1.5 spec, section 3.5.6 ("Surface Attributes"):

  "Querying EGL_WIDTH and EGL_HEIGHT returns respectively the width and
   height, in pixels, of the surface. For a window or pixmap surface,
   these values are initially equal to the width and height of the
   native window or pixmap with respect to which the surface was
   created"

This fixes dEQP-EGL.functional.color_clears.* CTS tests

v2:
- Do not modify attached_{width,height} (Daniel)
- Do not update size on resizing window (Brendan)

CC: Daniel Stone 
CC: Brendan King 
---
 src/egl/drivers/dri2/platform_wayland.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/egl/drivers/dri2/platform_wayland.c 
b/src/egl/drivers/dri2/platform_wayland.c
index 63da21cdf55..f62cbbc5c02 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -255,6 +255,9 @@ dri2_wl_create_window_surface(_EGLDriver *drv, _EGLDisplay 
*disp,
   goto cleanup_surf;
}
 
+   dri2_surf->base.Width = window->width;
+   dri2_surf->base.Height = window->height;
+
visual_idx = dri2_wl_visual_idx_from_config(dri2_dpy, config);
assert(visual_idx != -1);
 
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] i965: Fix batch-last mode to properly swap BOs.

[Chris Wilson]

Quoting Kenneth Graunke (2018-06-04 11:18:37)
> On pre-4.13 kernels, which don't support I915_EXEC_BATCH_FIRST, we move
> the validation list entry to the end...but incorrectly left the exec_bo
> array alone, causing a mismatch where exec_bos[0] no longer corresponded
> with validation_list[0] (and similarly for the last entry).
> 
> One example of resulting breakage is that we'd update bo->gtt_offset
> based on the wrong buffer.  This wreaked total havoc when trying to use
> softpin, and likely caused unnecessary relocations in the normal case.
> 
> Fixes: 29ba502a4e28471f67e4e904ae503157087efd20 (i965: Use 
> I915_EXEC_BATCH_FIRST when available.)

Reviewed-by: Chris Wilson 

One thing that may have helped is if we do the post-execbuf processing
in submit_batch; execbuffer() then just becomes stuffing the pointers
into struct drm_i915_gem_execbuffer2 and calling the ioctl. At the
moment, it isn't clear where batch->exec_bos was being used again, as
one expects it to be consumed by submit_batch().
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Fix batch-last mode to properly swap BOs.

[Kenneth Graunke]

On pre-4.13 kernels, which don't support I915_EXEC_BATCH_FIRST, we move
the validation list entry to the end...but incorrectly left the exec_bo
array alone, causing a mismatch where exec_bos[0] no longer corresponded
with validation_list[0] (and similarly for the last entry).

One example of resulting breakage is that we'd update bo->gtt_offset
based on the wrong buffer.  This wreaked total havoc when trying to use
softpin, and likely caused unnecessary relocations in the normal case.

Fixes: 29ba502a4e28471f67e4e904ae503157087efd20 (i965: Use 
I915_EXEC_BATCH_FIRST when available.)
---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 2cee2376c0e..462789e8cfb 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -798,11 +798,16 @@ submit_batch(struct brw_context *brw, int in_fence_fd, 
int *out_fence_fd)
   } else {
  /* Move the batch to the end of the validation list */
  struct drm_i915_gem_exec_object2 tmp;
+ struct brw_bo *tmp_bo;
  const unsigned index = batch->exec_count - 1;
 
  tmp = *entry;
  *entry = batch->validation_list[index];
  batch->validation_list[index] = tmp;
+
+ tmp_bo = batch->exec_bos[0];
+ batch->exec_bos[0] = batch->exec_bos[index];
+ batch->exec_bos[index] = tmp_bo;
   }
 
   ret = execbuffer(dri_screen->fd, batch, brw->hw_ctx,
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH] radeonsi/gfx9: fix si_get_buffer_from_descriptors for 48-bit pointers

[Samuel Pitoiset]

Reviewed-by: Samuel Pitoiset 

On 06/02/2018 01:31 AM, Marek Olšák wrote:

From: Marek Olšák 

This fixes:
GL45-CTS.pipeline_statistics_query_tests_ARB.functional_compute_shader_invocations

Cc: 18.0 18.1 
---
  src/gallium/drivers/radeonsi/si_descriptors.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 1d14c9df1e1..57a312463c9 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -87,21 +87,21 @@ static uint32_t null_texture_descriptor[8] = {
  
  static uint32_t null_image_descriptor[8] = {

0,
0,
0,
S_008F1C_TYPE(V_008F1C_SQ_RSRC_IMG_1D)
/* the rest must contain zeros, which is also used by the buffer
 * descriptor */
  };
  
-static uint64_t si_desc_extract_buffer_address(uint32_t *desc)

+static uint64_t si_desc_extract_buffer_address(const uint32_t *desc)
  {
uint64_t va = desc[0] |
  ((uint64_t)G_008F04_BASE_ADDRESS_HI(desc[1]) << 32);
  
  	/* Sign-extend the 48-bit address. */

if (va & (1ull << 47))
va |= 0xull << 48;
return va;
  }
  
@@ -1047,21 +1047,21 @@ static void si_get_buffer_from_descriptors(struct si_buffer_resources *buffers,

  {
pipe_resource_reference(buf, buffers->buffers[idx]);
if (*buf) {
struct r600_resource *res = r600_resource(*buf);
const uint32_t *desc = descs->list + idx * 4;
uint64_t va;
  
  		*size = desc[2];
  
  		assert(G_008F04_STRIDE(desc[1]) == 0);

-   va = ((uint64_t)desc[1] << 32) | desc[0];
+   va = si_desc_extract_buffer_address(desc);
  
  		assert(va >= res->gpu_address && va + *size <= res->gpu_address + res->bo_size);

*offset = va - res->gpu_address;
}
  }
  
  /* VERTEX BUFFERS */
  
  static void si_vertex_buffers_begin_new_cs(struct si_context *sctx)

  {


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

[Mesa-dev] [Bug 106807] Failed to parse macro "#line"

[bugzilla-daemon]

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

Kenneth Graunke  changed:

   What|Removed |Added

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

--- Comment #1 from Kenneth Graunke  ---
I don't have links to details handy, but sometime between September 20-22, 2017
Khronos voted to make #line expression behavior undefined (including failure to
parse), with the intention of making it explicitly an error in future GLSL
versions.

This test is invalid and should be removed from dEQP.  We will not accept
patches to implement this behavior in Mesa.

Historically, some people shipped a hack to make this invalid test pass:
https://github.com/intel/external-mesa/commit/81bb0a1474d98620a69a20396631dc63e324bf34

The right thing to do now is delete the test.

-- 
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 1/2] anv/android: Set the BO flags in bo_cache_import (v2)

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 04/06/18 01:38, Mauro Rossi wrote:

Changes to avoid building error:

external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
 ~~~^
1 error generated.

(v2) Set the correct bo_flags based on support of 48bit addresses and soft-pin

Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
Signed-off-by: Mauro Rossi 
---
  src/intel/vulkan/anv_android.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..8611e77b82 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
  */
 int dma_buf = gralloc_info->handle->data[0];
  
-   result = anv_bo_cache_import(device, >bo_cache, dma_buf, );

+   uint64_t bo_flags = 0;
+   if (device->instance->physicalDevice.supports_48bit_addresses)
+  bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   if (device->instance->physicalDevice.use_softpin)
+  bo_flags |= EXEC_OBJECT_PINNED;
+
+   result = anv_bo_cache_import(device, >bo_cache, dma_buf, bo_flags, 
);
 if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
 "failed to import dma-buf from VkNativeBufferANDROID");



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

Re: [Mesa-dev] [PATCH] anv/android: Set the BO flags in bo_cache_import (v2)

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 04/06/18 01:48, Mauro Rossi wrote:

Changes to avoid building error:

external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
result = anv_bo_cache_import(device, >bo_cache, dma_buf, );
 ~~~^
1 error generated.

(v2) Set the correct bo_flags based on support of 48bit addresses and soft-pin

Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in bo_cache_alloc/import")
Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
Signed-off-by: Mauro Rossi 
---
  src/intel/vulkan/anv_android.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..6e4d5a6d27 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
  */
 int dma_buf = gralloc_info->handle->data[0];
  
-   result = anv_bo_cache_import(device, >bo_cache, dma_buf, );

+   uint64_t bo_flags = 0;
+   if (device->instance->physicalDevice.supports_48bit_addresses)
+  bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   if (device->instance->physicalDevice.use_softpin)
+  bo_flags |= EXEC_OBJECT_PINNED;
+
+   result = anv_bo_cache_import(device, >bo_cache, dma_buf, bo_flags, 
);
 if (result != VK_SUCCESS) {
return vk_errorf(device->instance, device, result,
 "failed to import dma-buf from VkNativeBufferANDROID");



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

Re: [Mesa-dev] [PATCH 1/4] intel/eu: Add some brw_get_default_ helpers

[Kenneth Graunke]

On Tuesday, May 29, 2018 5:02:51 PM PDT Jason Ekstrand wrote:
> This is much cleaner than everything that wants a default value poking
> at the bits of p->current directly.
> ---
>  src/intel/compiler/brw_eu.c | 29 ++
>  src/intel/compiler/brw_eu.h |  3 +
>  src/intel/compiler/brw_eu_emit.c| 98 
> +++--
>  src/intel/compiler/brw_fs_generator.cpp |  4 +-
>  4 files changed, 79 insertions(+), 55 deletions(-)

This is much nicer!

Please add
Cc: mesa-sta...@lists.freedesktop.org
to this patch too because it's required for the 2-3, which you CC'd to
stable.  That will help the release managers out a bit, I believe.

Series is:
Reviewed-by: Kenneth Graunke 


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

[Mesa-dev] [Bug 106807] Failed to parse macro "#line"

[bugzilla-daemon]

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

Zhaowei Yuan  changed:

   What|Removed |Added

Summary|Failed to parse macor   |Failed to parse macro
   |"#line" |"#line"

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

[Mesa-dev] [Bug 106807] Failed to parse macor "#line"

[bugzilla-daemon]

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

Zhaowei Yuan  changed:

   What|Removed |Added

Summary|Failed to parser macor  |Failed to parse macor
   |"#line" |"#line"

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

[Mesa-dev] [Bug 106807] Failed to parser macor "#line"

[bugzilla-daemon]

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

Bug ID: 106807
   Summary: Failed to parser macor "#line"
   Product: Mesa
   Version: 17.1
  Hardware: ARM
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: glsl-compiler
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: zhaowei.y...@samsung.com
QA Contact: intel-3d-b...@lists.freedesktop.org

GLES CTS test case:
dEQP-GLES2.functional.shaders.preprocessor.builtin.line_expression_vertex
checks if GLSL compiler can parse macro "#line" successfully, following is the
shader code:
precision mediump float;
attribute highp vec4 dEQP_Position;
varying float out0;

void main()
{
#line +20
out0 = float(__LINE__);
gl_Position = dEQP_Position;

}

yyerror() will be called while parsing #line which casue the case fails

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

[Mesa-dev] [Bug 106590] Wrong line numbers expanded while compiling shaders

[bugzilla-daemon]

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

--- Comment #2 from Zhaowei Yuan  ---
(In reply to Timothy Arceri from comment #1)
> Thanks for the patch! However you should sign up to the mesa mailing list
> [1] and send it there for review.
> 
> [1] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> See also: https://www.mesa3d.org/submittingpatches.html

I have posted a patch here: https://patchwork.freedesktop.org/patch/225818/
but it hasn't been reviewed by anybody yet

-- 
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 1/2] i965/miptree: Rename a parameter to create_for_dri_image

[Kenneth Graunke]

On Thursday, May 31, 2018 5:04:43 PM PDT Jason Ekstrand wrote:
> Instead of having it be a general "is this a winsys image" boolean, make
> it more specific to the actual purpose.
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 6 +++---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)

These two patches are:
Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH 1/2] anv/android: Set the BO flags in bo_cache_import (v2)

[Tapani Pälli]

On 06/04/2018 08:50 AM, Jason Ekstrand wrote:
Looks good to me.  Tapani (CCd) would know wheter we want 
EXEC_OBJECT_ASYNC or not.  Either way (not setting EXEC_OBJECT_ASYNC 
won't hurt),


Currently after import we set EXEC_OBJECT_WRITE and remove 
EXEC_OBJECT_ASYNC (further down the function), IIRC this is what 
happened also on other WSI implementations at that point of time.


Reviewed-by: Jason Ekstrand >


Sorry for the mess and thanks for fixing it!

--Jason


On Sun, Jun 3, 2018 at 5:38 PM, Mauro Rossi > wrote:


Changes to avoid building error:

external/mesa/src/intel/vulkan/anv_android.c:131:72:
error: too few arguments to function call, expected 5, have 4
    result = anv_bo_cache_import(device, >bo_cache, dma_buf,
);
             ~~~   
     ^

1 error generated.

(v2) Set the correct bo_flags based on support of 48bit addresses
and soft-pin

Fixes: b0d50247a7 ("anv/allocator: Set the BO flags in
bo_cache_alloc/import")
Fixes: e7d0378bd9 ("anv: Soft-pin client-allocated memory")
Signed-off-by: Mauro Rossi mailto:issor.or...@gmail.com>>
---
  src/intel/vulkan/anv_android.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_android.c
b/src/intel/vulkan/anv_android.c
index 7e07dbaaa4..8611e77b82 100644
--- a/src/intel/vulkan/anv_android.c
+++ b/src/intel/vulkan/anv_android.c
@@ -128,7 +128,13 @@ anv_image_from_gralloc(VkDevice device_h,
      */
     int dma_buf = gralloc_info->handle->data[0];

-   result = anv_bo_cache_import(device, >bo_cache, dma_buf,
);
+   uint64_t bo_flags = 0;
+   if (device->instance->physicalDevice.supports_48bit_addresses)
+      bo_flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+   if (device->instance->physicalDevice.use_softpin)
+      bo_flags |= EXEC_OBJECT_PINNED;
+
+   result = anv_bo_cache_import(device, >bo_cache, dma_buf,
bo_flags, );
     if (result != VK_SUCCESS) {
        return vk_errorf(device->instance, device, result,
                         "failed to import dma-buf from
VkNativeBufferANDROID");
-- 
2.17.0


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





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


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

Re: [Mesa-dev] [PATCH] radv: Don't pass a TESS_EVAL shader when tesselation is not enabled.

[Alex Smith]

Oops. Thanks for tracking that down.

Reviewed-by: Alex Smith 

On 2 June 2018 at 13:31, Bas Nieuwenhuizen  wrote:

> Otherwise on pre-GFX9, if the constant layout allows both TESS_EVAL and
> GEOMETRY shaders, but the PIPELINE has only GEOMETRY, it would return the
> GEOMETRY shader for the TESS_EVAL shader.
>
> This would cause the flush_constants code to emit the GEOMETRY constants
> to the TESS_EVAL registers and then conclude that it did not need to set
> the GEOMETRY shader registers.
>
> Fixes: dfff9fb6f8d "radv: Handle GFX9 merged shaders in
> radv_flush_constants()"
> CC: 18.1 
> CC: Alex Smith 
> CC: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_
> pipeline.c
> index ff647ed9af3..375f7c357d3 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -1594,6 +1594,8 @@ radv_get_shader(struct radv_pipeline *pipeline,
> if (pipeline->shaders[MESA_SHADER_GEOMETRY])
> return pipeline->shaders[MESA_SHADER_GEOMETRY];
> } else if (stage == MESA_SHADER_TESS_EVAL) {
> +   if (!radv_pipeline_has_tess(pipeline))
> +   return NULL;
> if (pipeline->shaders[MESA_SHADER_TESS_EVAL])
> return pipeline->shaders[MESA_SHADER_TESS_EVAL];
> if (pipeline->shaders[MESA_SHADER_GEOMETRY])
> --
> 2.17.0
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 106806] Fast clear for VK_FORMAT_R8G8_SNORM not implemented

[bugzilla-daemon]

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

Bug ID: 106806
   Summary: Fast clear for VK_FORMAT_R8G8_SNORM not implemented
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: enhancement
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: pavel.ondra...@email.cz
QA Contact: mesa-dev@lists.freedesktop.org

Kingdom Come: Deliverance with DXVK spams console with "failed to fast clear
17". Some grepping shows that this comes from radv_format_pack_clear_color and
corresponds to the VK_FORMAT_R8G8_SNORM format.

This is with latest mesa and llvm, with OLAND GPU.

-- 
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] compiler/spirv: reject invalid shader code properly

[Martin Pelikán]

After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder
which can longjmp(3) to it through its vtx_assert()s.  This corrupts
the stack and creates confusing core dumps, so we need to avoid it.

While there, I decided to print the offending values for debugability.
---
 src/compiler/spirv/spirv_to_nir.c | 39 +++
 src/compiler/spirv/vtn_private.h  |  4 
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 78437428aa..1685ddc34b 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -129,6 +129,18 @@ _vtn_warn(struct vtn_builder *b, const char *file, 
unsigned line,
va_end(args);
 }
 
+void
+_vtn_err(struct vtn_builder *b, const char *file, unsigned line,
+  const char *fmt, ...)
+{
+   va_list args;
+
+   va_start(args, fmt);
+   vtn_log_err(b, NIR_SPIRV_DEBUG_LEVEL_ERROR, "SPIR-V ERROR:\n",
+   file, line, fmt, args);
+   va_end(args);
+}
+
 void
 _vtn_fail(struct vtn_builder *b, const char *file, unsigned line,
   const char *fmt, ...)
@@ -4011,19 +4023,36 @@ vtn_create_builder(const uint32_t *words, size_t 
word_count,
b->entry_point_name = entry_point_name;
b->options = options;
 
-   /* Handle the SPIR-V header (first 4 dwords)  */
-   vtn_assert(word_count > 5);
+   /*
+* Handle the SPIR-V header (first 4 dwords).
+* Can't use vtx_assert() as the setjmp(3) target isn't initialized yet.
+*/
+   if (word_count <= 5)
+  goto fail;
+
+   if (words[0] != SpvMagicNumber) {
+  vtn_err("words[0] was 0x%x, want 0x%x", words[0], SpvMagicNumber);
+  goto fail;
+   }
+   if (words[1] < 0x1) {
+  vtn_err("words[1] was 0x%x, want >= 0x1", words[1]);
+  goto fail;
+   }
 
-   vtn_assert(words[0] == SpvMagicNumber);
-   vtn_assert(words[1] >= 0x1);
/* words[2] == generator magic */
unsigned value_id_bound = words[3];
-   vtn_assert(words[4] == 0);
+   if (words[4] != 0) {
+  vtn_err("words[4] was %u, want 0", words[4]);
+  goto fail;
+   }
 
b->value_id_bound = value_id_bound;
b->values = rzalloc_array(b, struct vtn_value, value_id_bound);
 
return b;
+ fail:
+   ralloc_free(b);
+   return NULL;
 }
 
 nir_function *
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index b501bbf9b4..3146d8eeb5 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -51,6 +51,10 @@ void _vtn_warn(struct vtn_builder *b, const char *file, 
unsigned line,
const char *fmt, ...) PRINTFLIKE(4, 5);
 #define vtn_warn(...) _vtn_warn(b, __FILE__, __LINE__, __VA_ARGS__)
 
+void _vtn_err(struct vtn_builder *b, const char *file, unsigned line,
+   const char *fmt, ...) PRINTFLIKE(4, 5);
+#define vtn_err(...) _vtn_err(b, __FILE__, __LINE__, __VA_ARGS__)
+
 /** Fail SPIR-V parsing
  *
  * This function logs an error and then bails out of the shader compile using
-- 
2.17.0.921.gf22659ad46-goog

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

[Mesa-dev] [PATCH 1/1] vulkan/wsi: Destroy swapchain images after terminating FIFO queues

[Cameron Kumar]

The queue_manager thread can access the images from x11_present_to_x11,
hence this reorder prevents dereferencing of dangling pointers.

Cc: "18.1" 
---
 src/vulkan/wsi/wsi_common_x11.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 1bfbc7c300..20d7cf5a2c 100644
--- a/src/vulkan/wsi/wsi_common_x11.c
+++ b/src/vulkan/wsi/wsi_common_x11.c
@@ -1235,9 +1235,6 @@ x11_swapchain_destroy(struct wsi_swapchain *anv_chain,
struct x11_swapchain *chain = (struct x11_swapchain *)anv_chain;
xcb_void_cookie_t cookie;
 
-   for (uint32_t i = 0; i < chain->base.image_count; i++)
-  x11_image_finish(chain, pAllocator, >images[i]);
-
if (chain->threaded) {
   chain->status = VK_ERROR_OUT_OF_DATE_KHR;
   /* Push a UINT32_MAX to wake up the manager */
@@ -1247,6 +1244,9 @@ x11_swapchain_destroy(struct wsi_swapchain *anv_chain,
   wsi_queue_destroy(>present_queue);
}
 
+   for (uint32_t i = 0; i < chain->base.image_count; i++)
+  x11_image_finish(chain, pAllocator, >images[i]);
+
xcb_unregister_for_special_event(chain->conn, chain->special_event);
cookie = xcb_present_select_input_checked(chain->conn, chain->event_id,
  chain->window,
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 2/2] nir: add opt_if_loop_terminator()

[Timothy Arceri]

On 02/06/18 04:34, Ian Romanick wrote:


On 05/31/2018 10:37 PM, Timothy Arceri wrote:

This pass detects potential loop terminators and moves intructions
from the non breaking branch after the if.

This enables both the new opt_if_simplification() pass and loop
unrolling to potentially progress further.

Unexpectedly this change speed up shader-db run times by ~3%

Ivy Bridge shader-db results (all changes in dolphin/ubershaders):

I was going to look at the changes in the generated code, but the
smallest of these shaders is > 2300 instructions.

Do you have any idea if any piglit or CTS tests hit this optimization path?


Ok I've sent a loop unrolling piglit test for this:

https://patchwork.freedesktop.org/patch/227292/

Which also found a loop unrolling bug which requires the following mesa 
patch to pass:


https://patchwork.freedesktop.org/patch/227299/



One tiny nit below...


total instructions in shared programs: 9995662 -> 9995338 (-0.00%)
instructions in affected programs: 87845 -> 87521 (-0.37%)
helped: 27
HURT: 0

total cycles in shared programs: 230931495 -> 230925015 (-0.00%)
cycles in affected programs: 56391385 -> 56384905 (-0.01%)
helped: 27
HURT: 0
---
  src/compiler/nir/nir_opt_if.c | 68 +++
  1 file changed, 68 insertions(+)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index b03657a4244..1edeefdd5d1 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -24,6 +24,7 @@
  #include "nir.h"
  #include "nir/nir_builder.h"
  #include "nir_control_flow.h"
+#include "nir_loop_analyze.h"
  
  /**

   * This optimization detects if statements at the tops of loops where the
@@ -283,6 +284,72 @@ opt_if_simplification(nir_builder *b, nir_if *nif)
 return true;
  }
  
+/**

+ * This optimization simplifies potential loop terminators which then allows
+ * other passes such as opt_if_simplification() and loop unrolling to progress
+ * further:
+ *
+ * if (cond) {
+ *... then block instructions ...
+ * } else {
+ * ...
+ *break;
+ * }
+ *
+ * into:
+ *
+ * if (cond) {
+ * } else {
+ * ...
+ *break;
+ * }
+ * ... then block instructions ...
+ */
+static bool
+opt_if_loop_terminator(nir_if *nif)
+{
+   nir_block *break_blk = NULL;
+   nir_block *continue_from_blk = NULL;
+   bool continue_from_then = true;
+
+   nir_block *last_then = nir_if_last_then_block(nif);
+   nir_block *last_else = nir_if_last_else_block(nif);
+
+   if (nir_block_ends_in_break(last_then)) {
+  break_blk = last_then;
+  continue_from_blk = last_else;
+  continue_from_then = false;
+   } else if (nir_block_ends_in_break(last_else)) {
+  break_blk = last_else;
+  continue_from_blk = last_then;
+   }
+
+   /* Continue if the if contained no jumps at all */

In prose, I like to use if-statement because I think it reads more
easily.  "Continue if the if-statement..."


+   if (!break_blk)
+  return false;
+
+   /* If the continue from block is empty then return as there is nothing to
+* move.
+*/
+   nir_block *first_continue_from_blk = continue_from_then ?
+  nir_if_first_then_block(nif) :
+  nir_if_first_else_block(nif);
+   if (is_block_empty(first_continue_from_blk))
+  return false;
+
+   if (!nir_is_trivial_loop_if(nif, break_blk))
+  return false;
+
+   /* Finally, move the continue from branch after the if. */
+   nir_cf_list tmp;
+   nir_cf_extract(, nir_before_block(first_continue_from_blk),
+nir_after_block(continue_from_blk));
+   nir_cf_reinsert(, nir_after_cf_node(>cf_node));
+   nir_cf_delete();
+
+   return true;
+}
+
  static bool
  opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
  {
@@ -296,6 +363,7 @@ opt_if_cf_list(nir_builder *b, struct exec_list *cf_list)
   nir_if *nif = nir_cf_node_as_if(cf_node);
   progress |= opt_if_cf_list(b, >then_list);
   progress |= opt_if_cf_list(b, >else_list);
+ progress |= opt_if_loop_terminator(nif);
   progress |= opt_if_simplification(b, nif);
   break;
}



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

[Mesa-dev] [PATCH] nir: fix selection of loop terminator when two or more have the same limit

[Timothy Arceri]

We need to add loop terminators to the list in the order we come
across them otherwise if two or more have the same exit condition
we will select that last one rather than the first one even though
its unreachable.

This fix is for simple unrolls where we only have a single exit
point. When unrolling these type of loops the unreachable
terminators and their unreachable branch are removed prior to
unrolling. Because of the logic change we also switch some
list access in the complex unrolling logic to avoid breakage.

Fixes: 6772a17acc8e ("nir: Add a loop analysis pass")
---
 src/compiler/nir/nir_loop_analyze.c| 4 ++--
 src/compiler/nir/nir_opt_loop_unroll.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/compiler/nir/nir_loop_analyze.c 
b/src/compiler/nir/nir_loop_analyze.c
index d5281a5faa4..8f726986dac 100644
--- a/src/compiler/nir/nir_loop_analyze.c
+++ b/src/compiler/nir/nir_loop_analyze.c
@@ -330,8 +330,8 @@ find_loop_terminators(loop_info_state *state)
  nir_loop_terminator *terminator =
 rzalloc(state->loop->info, nir_loop_terminator);
 
- list_add(>loop_terminator_link,
-  >loop->info->loop_terminator_list);
+ list_addtail(>loop_terminator_link,
+  >loop->info->loop_terminator_list);
 
  terminator->nif = nif;
  terminator->break_block = break_blk;
diff --git a/src/compiler/nir/nir_opt_loop_unroll.c 
b/src/compiler/nir/nir_opt_loop_unroll.c
index ff27c06cc01..b8efbb5ee93 100644
--- a/src/compiler/nir/nir_opt_loop_unroll.c
+++ b/src/compiler/nir/nir_opt_loop_unroll.c
@@ -530,14 +530,14 @@ process_loops(nir_shader *sh, nir_cf_node *cf_node, bool 
*innermost_loop)
  if (num_lt == 2) {
 bool limiting_term_second = true;
 nir_loop_terminator *terminator =
-   list_last_entry(>info->loop_terminator_list,
+   list_first_entry(>info->loop_terminator_list,
 nir_loop_terminator, loop_terminator_link);
 
 
 if (terminator->nif == loop->info->limiting_terminator->nif) {
limiting_term_second = false;
terminator =
-  list_first_entry(>info->loop_terminator_list,
+  list_last_entry(>info->loop_terminator_list,
   nir_loop_terminator, loop_terminator_link);
 }
 
-- 
2.14.3

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Jason Ekstrand]

On Sun, Jun 3, 2018 at 4:36 PM, Stuart Young  wrote:

> Perhaps just have the archive as a separate repo that gets pulled in by
> the main ci yaml at build, just to populate the archives directory?
>

I was thinking something along those lines too.  It would be easy enough to
have a git repo for the tarballs and just combine the two as part of the CI
script.

--Jason



> This avoids any possible submodule breakage (just not worth it here IMO),
> with no chance of accidentally pulling down all the archives. I know a
> few people who have git shortcuts that update submodules by default for
> example, whether they exist or not.
>
> Also I personally think the archives dir needs a bit of re-org/cleanup to
> make it a bit more persistent over time (eg: like moving the old stuff into
> the older-versions dir effectively breaks links for distros, etc). That's
> getting more into content, but it'd be worth exploring if that should/would
> get done before or after the move to a git repo (ie: would it being in git
> make the process harder/a nightmare if it was to happen).
>
>
> On 4 June 2018 at 06:19, Daniel Stone  wrote:
>
>> Hi Laura,
>>
>> On 25 May 2018 at 01:27, Laura Ekstrand  wrote:
>> > When reviewing these patches, please note:
>> > 1. This patch series does *not* touch content.  Please do not
>> bikeshed
>> >the content of webpages here.  That will be addressed in
>> later
>> >commits.
>> > 2. Please do *not* bikeshed website style here.  We are using
>> the
>> >classic ReadTheDocs style for now and we will update style
>> in a
>> >future commit.
>> > 3. I've done my best to make your current content look
>> beautiful.  If
>> >there's a problem, please let me know.
>> > 4. There were some commits to the website between when I
>> started this
>> >series and now. I've done my best to incorporate your
>> changes.
>> >So if you changed your content in the past two weeks, take a
>> look
>> >at your page.
>>
>> One thing I've just remembered is that https://www.mesa3d.org/archive/
>> serves all the tarballs for Mesa releases. Given how Pages is
>> structured, we don't have a good way to redirect these to the old
>> server, so the Pages repository needs to hold all the tarballs. This
>> probably suggests to me that the site should live in a different repo,
>> where we can just commit all the tarballs.
>>
>> I reflexively didn't love the idea of committing tarballs to a git
>> repository, but the more I think about it, the more I like the idea.
>> It makes it more clear where they're coming from, makes the provenance
>> easier to verify, gives us audit logs of who put them in, and so on.
>>
>> Cheers,
>> Daniel
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
>
> --
> Stuart Young (aka Cefiar)
>
> ___
> 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] anv/android: Use an address for each anv_image plane

[Jason Ekstrand]

Reviewed-by: Jason Ekstrand 

On Sun, Jun 3, 2018 at 11:41 AM, Mauro Rossi  wrote:

> Fixes to avoid building error after change in image->planes[] structure,
> {bo,bo_offset} has to be replaced by address.{bo,offset}
> and update is needed also in the assert() for debug builds.
>
> external/mesa/src/intel/vulkan/anv_android.c:188:21:
> error: no member named 'bo' in 'struct anv_image::(anonymous at
> external/mesa/src/intel/vulkan/anv_private.h:2647:4)'
>image->planes[0].bo = bo;
> ^
> 1 error generated.
>
> Fixes: bf34ef16ac ("anv: Use an address for each anv_image plane")
> Signed-off-by: Mauro Rossi 
> ---
>  src/intel/vulkan/anv_android.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_android.c b/src/intel/vulkan/anv_
> android.c
> index ed5da5b537..45a21dcfc3 100644
> --- a/src/intel/vulkan/anv_android.c
> +++ b/src/intel/vulkan/anv_android.c
> @@ -183,9 +183,9 @@ anv_image_from_gralloc(VkDevice device_h,
> }
>
> assert(image->n_planes == 1);
> -   assert(image->planes[0].bo_offset == 0);
> +   assert(image->planes[0].address.offset == 0);
>
> -   image->planes[0].bo = bo;
> +   image->planes[0].address.bo = bo;
> image->planes[0].bo_is_owned = true;
>
> /* We need to set the WRITE flag on window system buffers so that GEM
> will
> --
> 2.17.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev