[Mesa-dev] [Bug 107022] [RADV] The Witcher 3: Trembling of trees

2018-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107022

soredake  changed:

   What|Removed |Added

 CC||fds...@krutt.org

-- 
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] Testing drm_hwcomposer in RPi

2018-06-25 Thread chris simmonds
Hi.

I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me to a
howto or something that tells me how?

FYI, this is part of a side project to port drm_hwcomposer to BeagleBones
and other things based on TI SoCs

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


[Mesa-dev] [Bug 106958] Mass Effect Andromeda renders correctly on RX480 POLARIS but BAD ON RX VEGA 64 on wine 3.10 stagingf with DXVK

2018-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106958

--- Comment #8 from Samuel Pitoiset  ---
Don't you see the renderdoc overlay?

-- 
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 v3] i965/gen6/gs: Handle case where a GS doesn't allocate VUE

2018-06-25 Thread Iago Toral
Thanks for testing Mark.

Andrii, I'll add my Reviewed-by and and push the patch to master later
today (I'll also queue it for the next stable release).

Thanks for fixing this!

Iago

On Fri, 2018-06-22 at 13:18 -0700, Mark Janes wrote:
> Tested-by: Mark Janes 
> 
> Iago Toral  writes:
> 
> > Thanks Andrii, this version looks good to me.
> > 
> > Mark: this change fixes a GPU hang in sandy bridge with geometry
> > shaders (the change itself affects a path in the driver that is
> > only
> > executed in SNB with GS, so nothing else is affected). While I
> > think
> > the change in here is correct according to the PRMs and in fact it
> > seems to fix the GPU hang reported in Bugzilla, since this is
> > tinkering
> > with the way in which we allocate and free VUEs for SNB GS I
> > believe
> > that if this breaks anything it might produce a GPU hang and in
> > that
> > case I would rather not hang Jenkins for everyone else until you
> > have a
> > chance to restore it, so in order to minimize that risk, could you
> > run
> > this through Jenkins when you are available? If that is
> > inconvenient
> > for you just let me know and I will send it myself late in my day
> > on
> > Monday to minimize the risk.
> > 
> > Thanks,
> > Iago
> > 
> > On Fri, 2018-06-22 at 10:59 +0300, Andrii Simiklit wrote:
> > > We can not use the VUE Dereference flags combination for EOT
> > > message under ILK and SNB because the threads are not initialized
> > > there with initial VUE handle unlike Pre-IL.
> > > So to avoid GPU hangs on SNB and ILK we need
> > > to avoid usage of the VUE Dereference flags combination.
> > > (Was tested only on SNB but according to the specification
> > > SNB Volume 2 Part 1: 1.6.5.3, 1.6.5.6
> > > the ILK must behave itself in the similar way)
> > > 
> > > v2: Approach to fix this issue was changed.
> > > Instead of different EOT flags in the program end
> > > we will create VUE every time even if GS produces no output.
> > > 
> > > v3: Clean up the patch.
> > > Signed-off-by: Andrii Simiklit 
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105399
> > > 
> > > ---
> > >  src/intel/compiler/gen6_gs_visitor.cpp | 42 +---
> > > 
> > > --
> > >  1 file changed, 21 insertions(+), 21 deletions(-)
> > > 
> > > diff --git a/src/intel/compiler/gen6_gs_visitor.cpp
> > > b/src/intel/compiler/gen6_gs_visitor.cpp
> > > index 66c69fb..c9571cc 100644
> > > --- a/src/intel/compiler/gen6_gs_visitor.cpp
> > > +++ b/src/intel/compiler/gen6_gs_visitor.cpp
> > > @@ -350,27 +350,27 @@ gen6_gs_visitor::emit_thread_end()
> > > int max_usable_mrf = FIRST_SPILL_MRF(devinfo->gen);
> > >  
> > > /* Issue the FF_SYNC message and obtain the initial VUE
> > > handle.
> > > */
> > > +   this->current_annotation = "gen6 thread end: ff_sync";
> > > +
> > > +   vec4_instruction *inst = NULL;
> > > +   if (prog->info.has_transform_feedback_varyings) {
> > > +  src_reg sol_temp(this, glsl_type::uvec4_type);
> > > +  emit(GS_OPCODE_FF_SYNC_SET_PRIMITIVES,
> > > +   dst_reg(this->svbi),
> > > +   this->vertex_count,
> > > +   this->prim_count,
> > > +   sol_temp);
> > > +  inst = emit(GS_OPCODE_FF_SYNC,
> > > +  dst_reg(this->temp), this->prim_count, this-
> > > > svbi);
> > > 
> > > +   } else {
> > > +  inst = emit(GS_OPCODE_FF_SYNC,
> > > +  dst_reg(this->temp), this->prim_count,
> > > brw_imm_ud(0u));
> > > +   }
> > > +   inst->base_mrf = base_mrf;
> > > +
> > > emit(CMP(dst_null_ud(), this->vertex_count, brw_imm_ud(0u),
> > > BRW_CONDITIONAL_G));
> > > emit(IF(BRW_PREDICATE_NORMAL));
> > > {
> > > -  this->current_annotation = "gen6 thread end: ff_sync";
> > > -
> > > -  vec4_instruction *inst;
> > > -  if (prog->info.has_transform_feedback_varyings) {
> > > - src_reg sol_temp(this, glsl_type::uvec4_type);
> > > - emit(GS_OPCODE_FF_SYNC_SET_PRIMITIVES,
> > > -  dst_reg(this->svbi),
> > > -  this->vertex_count,
> > > -  this->prim_count,
> > > -  sol_temp);
> > > - inst = emit(GS_OPCODE_FF_SYNC,
> > > - dst_reg(this->temp), this->prim_count,
> > > this-
> > > > svbi);
> > > 
> > > -  } else {
> > > - inst = emit(GS_OPCODE_FF_SYNC,
> > > - dst_reg(this->temp), this->prim_count,
> > > brw_imm_ud(0u));
> > > -  }
> > > -  inst->base_mrf = base_mrf;
> > > -
> > >/* Loop over all buffered vertices and emit URB write
> > > messages
> > > */
> > >this->current_annotation = "gen6 thread end: urb writes
> > > init";
> > >src_reg vertex(this, glsl_type::uint_type);
> > > @@ -414,7 +414,7 @@ gen6_gs_visitor::emit_thread_end()
> > > dst_reg reg = dst_reg(MRF, mrf);
> > > reg.type = output_reg[varying][0].type;
> > > data.type = reg.type;
> > > -   vec4_instruction *inst = emit(

[Mesa-dev] [PATCH] travis: use https for all the links

2018-06-25 Thread Emil Velikov
From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 .travis.yml | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 012cc9139e0..903bd2dc8fc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -9,9 +9,9 @@ cache:
 
 env:
   global:
-- XORG_RELEASES=http://xorg.freedesktop.org/releases/individual
-- XCB_RELEASES=http://xcb.freedesktop.org/dist
-- WAYLAND_RELEASES=http://wayland.freedesktop.org/releases
+- XORG_RELEASES=https://xorg.freedesktop.org/releases/individual
+- XCB_RELEASES=https://xcb.freedesktop.org/dist
+- WAYLAND_RELEASES=https://wayland.freedesktop.org/releases
 - XORGMACROS_VERSION=util-macros-1.19.0
 - GLPROTO_VERSION=glproto-1.4.17
 - DRI2PROTO_VERSION=dri2proto-2.8
@@ -541,7 +541,7 @@ install:
   tar -jxvf $LIBPCIACCESS_VERSION.tar.bz2
   (cd $LIBPCIACCESS_VERSION && ./configure --prefix=$HOME/prefix && make 
install)
 
-  wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
+  wget https://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
   tar -jxvf $LIBDRM_VERSION.tar.bz2
   (cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
--enable-freedreno --enable-etnaviv-experimental-api && make install)
 
@@ -557,11 +557,11 @@ install:
   tar -jxvf $LIBXSHMFENCE_VERSION.tar.bz2
   (cd $LIBXSHMFENCE_VERSION && ./configure --prefix=$HOME/prefix && make 
install)
 
-  wget 
http://people.freedesktop.org/~aplattner/vdpau/$LIBVDPAU_VERSION.tar.bz2
+  wget 
https://people.freedesktop.org/~aplattner/vdpau/$LIBVDPAU_VERSION.tar.bz2
   tar -jxvf $LIBVDPAU_VERSION.tar.bz2
   (cd $LIBVDPAU_VERSION && ./configure --prefix=$HOME/prefix && make 
install)
 
-  wget 
http://www.freedesktop.org/software/vaapi/releases/libva/$LIBVA_VERSION.tar.bz2
+  wget 
https://www.freedesktop.org/software/vaapi/releases/libva/$LIBVA_VERSION.tar.bz2
   tar -jxvf $LIBVA_VERSION.tar.bz2
   (cd $LIBVA_VERSION && ./configure --prefix=$HOME/prefix 
--disable-wayland --disable-dummy-driver && make install)
 
-- 
2.17.1

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


[Mesa-dev] [PATCH 4/5] mesa: add compat profile support for ARB_multi_draw_indirect

2018-06-25 Thread Timothy Arceri
---
 src/mesa/main/extensions_table.h |  2 +-
 src/mesa/vbo/vbo_exec_array.c| 75 +++-
 2 files changed, 74 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index cba1ef6ba7c..1a4014c646b 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -88,7 +88,7 @@ EXT(ARB_invalidate_subdata  , dummy_true
 EXT(ARB_map_buffer_alignment, dummy_true   
  , GLL, GLC,  x ,  x , 2011)
 EXT(ARB_map_buffer_range, ARB_map_buffer_range 
  , GLL, GLC,  x ,  x , 2008)
 EXT(ARB_multi_bind  , dummy_true   
  , GLL, GLC,  x ,  x , 2013)
-EXT(ARB_multi_draw_indirect , ARB_draw_indirect
  ,  x , GLC,  x ,  x , 2012)
+EXT(ARB_multi_draw_indirect , ARB_draw_indirect
  , GLL, GLC,  x ,  x , 2012)
 EXT(ARB_multisample , dummy_true   
  , GLL,  x ,  x ,  x , 1994)
 EXT(ARB_multitexture, dummy_true   
  , GLL,  x ,  x ,  x , 1998)
 EXT(ARB_occlusion_query , ARB_occlusion_query  
  , GLL,  x ,  x ,  x , 2001)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 0d92de2e3ad..4e24cdcf263 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -1744,7 +1744,36 @@ vbo_exec_MultiDrawArraysIndirect(GLenum mode, const 
GLvoid *indirect,
 
/* If  is zero, the array elements are treated as tightly packed. */
if (stride == 0)
-  stride = 4 * sizeof(GLuint);  /* sizeof(DrawArraysIndirectCommand) */
+  stride = sizeof(DrawArraysIndirectCommand);
+
+   /* From the ARB_draw_indirect spec:
+*
+*"Initially zero is bound to DRAW_INDIRECT_BUFFER. In the
+*compatibility profile, this indicates that DrawArraysIndirect and
+*DrawElementsIndirect are to source their arguments directly from the
+*pointer passed as their  parameters."
+*/
+   if (ctx->API == API_OPENGL_COMPAT &&
+   !_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
+
+  if (!_mesa_valid_draw_indirect_multi(ctx, primcount, stride,
+   "glMultiDrawArraysIndirect"))
+ return;
+
+  const ubyte *ptr = (const ubyte *) indirect;
+  for (unsigned i = 0; i < primcount; i++) {
+ DrawArraysIndirectCommand *cmd = (DrawArraysIndirectCommand *) ptr;
+ _mesa_DrawArraysInstanced(mode, cmd->first, cmd->count, 
cmd->primCount);
+
+ if (stride == 0) {
+ptr += sizeof(DrawArraysIndirectCommand);
+ } else {
+ptr += stride;
+ }
+  }
+
+  return;
+   }
 
FLUSH_FOR_DRAW(ctx);
 
@@ -1783,7 +1812,49 @@ vbo_exec_MultiDrawElementsIndirect(GLenum mode, GLenum 
type,
 
/* If  is zero, the array elements are treated as tightly packed. */
if (stride == 0)
-  stride = 5 * sizeof(GLuint);  /* sizeof(DrawElementsIndirectCommand) 
*/
+  stride = sizeof(DrawElementsIndirectCommand);
+
+
+   /* From the ARB_draw_indirect spec:
+*
+*"Initially zero is bound to DRAW_INDIRECT_BUFFER. In the
+*compatibility profile, this indicates that DrawArraysIndirect and
+*DrawElementsIndirect are to source their arguments directly from the
+*pointer passed as their  parameters."
+*/
+   if (ctx->API == API_OPENGL_COMPAT &&
+   !_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
+  /*
+   * Unlike regular DrawElementsInstancedBaseVertex commands, the indices
+   * may not come from a client array and must come from an index buffer.
+   * If no element array buffer is bound, an INVALID_OPERATION error is
+   * generated.
+   */
+  if (!_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glMultiDrawElementsIndirect(no buffer bound "
+ "to GL_ELEMENT_ARRAY_BUFFER)");
+
+ return;
+  }
+
+  if (!_mesa_valid_draw_indirect_multi(ctx, primcount, stride,
+   "glMultiDrawArraysIndirect"))
+ return;
+
+  const ubyte *ptr = (const ubyte *) indirect;
+  for (unsigned i = 0; i < primcount; i++) {
+ vbo_exec_DrawElementsIndirect(mode, type, ptr);
+
+ if (stride == 0) {
+ptr += sizeof(DrawElementsIndirectCommand);
+ } else {
+ptr += stride;
+ }
+  }
+
+  return;
+   }
 
FLUSH_FOR_DRAW(ctx);
 
-- 
2.17.1

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


[Mesa-dev] Radeonsi OpenGL 4.0 compat profile

2018-06-25 Thread Timothy Arceri
This series is intended to be applied on top of my previous compat 
series [1]. Note I'm going to drop the last two patches from that 
series, patch 10 was sent by mistake and I've submitted a spec bug 
in regards to patch 11.

I originally planned not to send this series until 
ARB_vertex_attrib_64bit was done and we could enable 4.4. However
it seems that extension will require a fair number of changes.

[1] https://patchwork.freedesktop.org/series/45232/

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


[Mesa-dev] [PATCH 1/5] mesa: generate GL_INVALID_OPERATION using draw indirect in dlist

2018-06-25 Thread Timothy Arceri
The spec doesn't explicitly say to generate an error but since
DrawArraysInstanced* and DrawElementsInstanced* do, it makes
sense to do it for these functions also.
---
 src/mesa/main/dlist.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index c11b4c06fe5..7098f19d849 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -1950,6 +1950,47 @@ save_DrawElementsInstancedBaseVertexBaseInstance(UNUSED 
GLenum mode,
"glDrawElementsInstancedBaseVertexBaseInstance() during display 
list compile");
 }
 
+static void APIENTRY
+save_DrawArraysIndirect(UNUSED GLenum mode,
+UNUSED const void *indirect)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+   "glDrawArraysIndirect() during display list compile");
+}
+
+static void APIENTRY
+save_DrawElementsIndirect(UNUSED GLenum mode,
+  UNUSED GLenum type,
+  UNUSED const void *indirect)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+   "glDrawElementsIndirect() during display list compile");
+}
+
+static void APIENTRY
+save_MultiDrawArraysIndirect(UNUSED GLenum mode,
+ UNUSED const void *indirect,
+ UNUSED GLsizei primcount,
+ UNUSED GLsizei stride)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+   "glMultiDrawArraysIndirect() during display list compile");
+}
+
+static void APIENTRY
+save_MultiDrawElementsIndirect(UNUSED GLenum mode,
+   UNUSED GLenum type,
+   UNUSED const void *indirect,
+   UNUSED GLsizei primcount,
+   UNUSED GLsizei stride)
+{
+   GET_CURRENT_CONTEXT(ctx);
+   _mesa_error(ctx, GL_INVALID_OPERATION,
+   "glMultiDrawElementsIndirect() during display list compile");
+}
 
 /**
  * While building a display list we cache some OpenGL state.
@@ -11458,6 +11499,12 @@ _mesa_initialize_save_table(const struct gl_context 
*ctx)
SET_DrawElementsInstancedBaseInstance(table, 
save_DrawElementsInstancedBaseInstance);
SET_DrawElementsInstancedBaseVertexBaseInstance(table, 
save_DrawElementsInstancedBaseVertexBaseInstance);
 
+   /* GL_ARB_draw_indirect / GL_ARB_multi_draw_indirect */
+   SET_DrawArraysIndirect(table, save_DrawArraysIndirect);
+   SET_DrawElementsIndirect(table, save_DrawElementsIndirect);
+   SET_MultiDrawArraysIndirect(table, save_MultiDrawArraysIndirect);
+   SET_MultiDrawElementsIndirect(table, save_MultiDrawElementsIndirect);
+
/* OpenGL 4.2 / GL_ARB_separate_shader_objects */
SET_UseProgramStages(table, save_UseProgramStages);
SET_ProgramUniform1f(table, save_ProgramUniform1f);
-- 
2.17.1

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


[Mesa-dev] [PATCH 2/5] mesa: add ARB_draw_indirect support to compat profile

2018-06-25 Thread Timothy Arceri
---
 src/mesa/main/bufferobj.c|  3 +-
 src/mesa/main/extensions_table.h |  2 +-
 src/mesa/vbo/vbo_exec_array.c| 66 +++-
 3 files changed, 67 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 67f9cd0a902..1d1e51bc015 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -129,8 +129,7 @@ get_buffer_target(struct gl_context *ctx, GLenum target)
  return &ctx->QueryBuffer;
   break;
case GL_DRAW_INDIRECT_BUFFER:
-  if ((ctx->API == API_OPENGL_CORE &&
-   ctx->Extensions.ARB_draw_indirect) ||
+  if ((_mesa_is_desktop_gl(ctx) && ctx->Extensions.ARB_draw_indirect) ||
_mesa_is_gles31(ctx)) {
  return &ctx->DrawIndirectBuffer;
   }
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 9100f4a04c7..cba1ef6ba7c 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -58,7 +58,7 @@ EXT(ARB_direct_state_access , dummy_true
 EXT(ARB_draw_buffers, dummy_true   
  , GLL, GLC,  x ,  x , 2002)
 EXT(ARB_draw_buffers_blend  , ARB_draw_buffers_blend   
  , GLL, GLC,  x ,  x , 2009)
 EXT(ARB_draw_elements_base_vertex   , ARB_draw_elements_base_vertex
  , GLL, GLC,  x ,  x , 2009)
-EXT(ARB_draw_indirect   , ARB_draw_indirect
  ,  x , GLC,  x ,  x , 2010)
+EXT(ARB_draw_indirect   , ARB_draw_indirect
  , GLL, GLC,  x ,  x , 2010)
 EXT(ARB_draw_instanced  , ARB_draw_instanced   
  , GLL, GLC,  x ,  x , 2008)
 EXT(ARB_enhanced_layouts, ARB_enhanced_layouts 
  , GLL, GLC,  x ,  x , 2013)
 EXT(ARB_explicit_attrib_location, ARB_explicit_attrib_location 
  , GLL, GLC,  x ,  x , 2009)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index 792907ac044..0d92de2e3ad 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -39,6 +39,21 @@
 #include "main/macros.h"
 #include "main/transformfeedback.h"
 
+typedef struct {
+   GLuint count;
+   GLuint primCount;
+   GLuint first;
+   GLuint reservedMustBeZero;
+} DrawArraysIndirectCommand;
+
+typedef struct {
+   GLuint count;
+   GLuint primCount;
+   GLuint firstIndex;
+   GLint  baseVertex;
+   GLuint reservedMustBeZero;
+} DrawElementsIndirectCommand;
+
 
 /**
  * Check that element 'j' of the array has reasonable data.
@@ -1616,6 +1631,20 @@ vbo_exec_DrawArraysIndirect(GLenum mode, const GLvoid 
*indirect)
   _mesa_debug(ctx, "glDrawArraysIndirect(%s, %p)\n",
   _mesa_enum_to_string(mode), indirect);
 
+   /* From the ARB_draw_indirect spec:
+*
+*"Initially zero is bound to DRAW_INDIRECT_BUFFER. In the
+*compatibility profile, this indicates that DrawArraysIndirect and
+*DrawElementsIndirect are to source their arguments directly from the
+*pointer passed as their  parameters."
+*/
+   if (ctx->API == API_OPENGL_COMPAT &&
+   !_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
+  DrawArraysIndirectCommand *cmd = (DrawArraysIndirectCommand *) indirect;
+  _mesa_DrawArraysInstanced(mode, cmd->first, cmd->count, cmd->primCount);
+  return;
+   }
+
FLUSH_FOR_DRAW(ctx);
 
if (_mesa_is_no_error_enabled(ctx)) {
@@ -1647,6 +1676,41 @@ vbo_exec_DrawElementsIndirect(GLenum mode, GLenum type, 
const GLvoid *indirect)
   _mesa_enum_to_string(mode),
   _mesa_enum_to_string(type), indirect);
 
+   /* From the ARB_draw_indirect spec:
+*
+*"Initially zero is bound to DRAW_INDIRECT_BUFFER. In the
+*compatibility profile, this indicates that DrawArraysIndirect and
+*DrawElementsIndirect are to source their arguments directly from the
+*pointer passed as their  parameters."
+*/
+   if (ctx->API == API_OPENGL_COMPAT &&
+   !_mesa_is_bufferobj(ctx->DrawIndirectBuffer)) {
+  /*
+   * Unlike regular DrawElementsInstancedBaseVertex commands, the indices
+   * may not come from a client array and must come from an index buffer.
+   * If no element array buffer is bound, an INVALID_OPERATION error is
+   * generated.
+   */
+  if (!_mesa_is_bufferobj(ctx->Array.VAO->IndexBufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glDrawElementsIndirect(no buffer bound "
+ "to GL_ELEMENT_ARRAY_BUFFER)");
+  } else {
+ DrawElementsIndirectCommand *cmd =
+(DrawElementsIndirectCommand *) indirect;
+
+ /* Convert offset to pointer */
+ void *offset = (void *)
+((cmd->firstIndex * _mesa_sizeof_type(type)) & 0xUL);
+
+ vbo_exec_DrawElementsInstancedBaseVertex(mode, cmd->coun

[Mesa-dev] [PATCH 5/5] radeonsi: enable OpenGL 4.0 compat profile

2018-06-25 Thread Timothy Arceri
---
 src/gallium/drivers/radeonsi/si_get.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_get.c 
b/src/gallium/drivers/radeonsi/si_get.c
index 0e8617d0fee..a99626416e7 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -215,7 +215,7 @@ static int si_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
return 420;
 
case PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY:
-   return 330;
+   return 400;
 
case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
return MIN2(sscreen->info.max_alloc_size, INT_MAX);
-- 
2.17.1

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


[Mesa-dev] [PATCH 3/5] mesa: make valid_draw_indirect_multi() accessible externally

2018-06-25 Thread Timothy Arceri
We will use this to add compat support to ARB_multi_draw_indirect
in the following patch.
---
 src/mesa/main/draw_validate.c | 24 
 src/mesa/main/draw_validate.h |  3 +++
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/src/mesa/main/draw_validate.c b/src/mesa/main/draw_validate.c
index 352263c5c78..c0a234a2bc2 100644
--- a/src/mesa/main/draw_validate.c
+++ b/src/mesa/main/draw_validate.c
@@ -1192,10 +1192,10 @@ valid_draw_indirect_elements(struct gl_context *ctx,
return valid_draw_indirect(ctx, mode, indirect, size, name);
 }
 
-static inline GLboolean
-valid_draw_indirect_multi(struct gl_context *ctx,
-  GLsizei primcount, GLsizei stride,
-  const char *name)
+GLboolean
+_mesa_valid_draw_indirect_multi(struct gl_context *ctx,
+GLsizei primcount, GLsizei stride,
+const char *name)
 {
 
/* From the ARB_multi_draw_indirect specification:
@@ -1259,8 +1259,8 @@ _mesa_validate_MultiDrawArraysIndirect(struct gl_context 
*ctx,
/* caller has converted stride==0 to drawArraysNumParams * sizeof(GLuint) */
assert(stride != 0);
 
-   if (!valid_draw_indirect_multi(ctx, primcount, stride,
-  "glMultiDrawArraysIndirect"))
+   if (!_mesa_valid_draw_indirect_multi(ctx, primcount, stride,
+"glMultiDrawArraysIndirect"))
   return GL_FALSE;
 
/* number of bytes of the indirect buffer which will be read */
@@ -1287,8 +1287,8 @@ _mesa_validate_MultiDrawElementsIndirect(struct 
gl_context *ctx,
/* caller has converted stride==0 to drawElementsNumParams * sizeof(GLuint) 
*/
assert(stride != 0);
 
-   if (!valid_draw_indirect_multi(ctx, primcount, stride,
-  "glMultiDrawElementsIndirect"))
+   if (!_mesa_valid_draw_indirect_multi(ctx, primcount, stride,
+"glMultiDrawElementsIndirect"))
   return GL_FALSE;
 
/* number of bytes of the indirect buffer which will be read */
@@ -1366,8 +1366,8 @@ _mesa_validate_MultiDrawArraysIndirectCount(struct 
gl_context *ctx,
/* caller has converted stride==0 to drawArraysNumParams * sizeof(GLuint) */
assert(stride != 0);
 
-   if (!valid_draw_indirect_multi(ctx, maxdrawcount, stride,
-  "glMultiDrawArraysIndirectCountARB"))
+   if (!_mesa_valid_draw_indirect_multi(ctx, maxdrawcount, stride,
+"glMultiDrawArraysIndirectCountARB"))
   return GL_FALSE;
 
/* number of bytes of the indirect buffer which will be read */
@@ -1397,8 +1397,8 @@ _mesa_validate_MultiDrawElementsIndirectCount(struct 
gl_context *ctx,
/* caller has converted stride==0 to drawElementsNumParams * sizeof(GLuint) 
*/
assert(stride != 0);
 
-   if (!valid_draw_indirect_multi(ctx, maxdrawcount, stride,
-  "glMultiDrawElementsIndirectCountARB"))
+   if (!_mesa_valid_draw_indirect_multi(ctx, maxdrawcount, stride,
+"glMultiDrawElementsIndirectCountARB"))
   return GL_FALSE;
 
/* number of bytes of the indirect buffer which will be read */
diff --git a/src/mesa/main/draw_validate.h b/src/mesa/main/draw_validate.h
index 7a181153fb7..d015c7e830e 100644
--- a/src/mesa/main/draw_validate.h
+++ b/src/mesa/main/draw_validate.h
@@ -44,6 +44,9 @@ _mesa_is_valid_prim_mode(const struct gl_context *ctx, GLenum 
mode);
 extern GLboolean
 _mesa_valid_prim_mode(struct gl_context *ctx, GLenum mode, const char *name);
 
+extern GLboolean
+_mesa_valid_draw_indirect_multi(struct gl_context *ctx, GLsizei primcount,
+GLsizei stride, const char *name);
 
 extern GLboolean
 _mesa_validate_DrawArrays(struct gl_context *ctx, GLenum mode, GLsizei count);
-- 
2.17.1

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


Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

2018-06-25 Thread Timothy Arceri
Please note I've fixed up make check where is was broken when enabling 
some of these extensions. You can see all of the latests compat patches 
here:


https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64

On 22/06/18 18:47, Timothy Arceri wrote:

I've send all of these patches out already. The only change is to the
first 2 patches which fixes things so we store a double as 2 unsigned ints
rather than 2 floats.

Everything here has corresponding piglit tests all of which are now
upstream with the exception of the compute shader display list test.

Our current TODO list has 2 remaining extensions on it before it
should be ok to enable OpenGL 4.4 compat contexts in radeonsi.


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


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


[Mesa-dev] [PATCH] radv: fix HTILE metadata initialization in presence of subpass clears

2018-06-25 Thread Samuel Pitoiset
If the driver ends up by performing a slow depthstencil clear,
the HTILE metadata won't be initialized correctly.

This fixes random VM faults on Polaris while running CTS
with Bas's runner. This doesn't seem to regress performance.

CC: 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8bd41bc41a..0388e4b6e0 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3987,14 +3987,7 @@ static void radv_handle_depth_image_transition(struct 
radv_cmd_buffer *cmd_buffe
if (!radv_image_has_htile(image))
return;
 
-   if (dst_layout == VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL &&
-   (pending_clears & vk_format_aspects(image->vk_format)) == 
vk_format_aspects(image->vk_format) &&
-   cmd_buffer->state.render_area.offset.x == 0 && 
cmd_buffer->state.render_area.offset.y == 0 &&
-   cmd_buffer->state.render_area.extent.width == image->info.width &&
-   cmd_buffer->state.render_area.extent.height == image->info.height) {
-   /* The clear will initialize htile. */
-   return;
-   } else if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
+   if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
   radv_layout_has_htile(image, dst_layout, dst_queue_mask)) {
/* TODO: merge with the clear if applicable */
radv_initialize_htile(cmd_buffer, image, range, 0);
-- 
2.18.0

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


[Mesa-dev] [RESEND PATCH v5 1/3] gallium/util: Fix build error due to cast to different size

2018-06-25 Thread Robert Foss
Signed-off-by: Robert Foss 
Reviewed-by: Tomasz Figa 
Reviewed-by: Marek Olšák 
---

Changes since v4:
 - Added r-b from Marek

Changes since v3:
 - Added r-b from Tomasz


 src/gallium/auxiliary/util/u_debug_stack_android.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_debug_stack_android.cpp 
b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
index b3d56aebe6..395a1fe911 100644
--- a/src/gallium/auxiliary/util/u_debug_stack_android.cpp
+++ b/src/gallium/auxiliary/util/u_debug_stack_android.cpp
@@ -49,10 +49,10 @@ debug_backtrace_capture(debug_stack_frame *mesa_backtrace,
   backtrace_table = _mesa_hash_table_create(NULL, _mesa_hash_pointer,
 _mesa_key_pointer_equal);
 
-   backtrace_entry = _mesa_hash_table_search(backtrace_table, (void*) tid);
+   backtrace_entry = _mesa_hash_table_search(backtrace_table, (void*) 
(uintptr_t)tid);
if (!backtrace_entry) {
   backtrace = Backtrace::Create(getpid(), tid);
-  _mesa_hash_table_insert(backtrace_table, (void*) tid, backtrace);
+  _mesa_hash_table_insert(backtrace_table, (void*) (uintptr_t)tid, 
backtrace);
} else {
   backtrace = (Backtrace *) backtrace_entry->data;
}
-- 
2.17.1

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


[Mesa-dev] [RESEND PATCH v5 0/3] egl/android: Add DRM node probing and filtering

2018-06-25 Thread Robert Foss
[RESEND] due to the previous version sent to the ML mistakenly being
v4 again. Please excuse the spam.

This series replaces the dependency on
GRALLOC_MODULE_PERFORM_GET_DRM_FD with DRM node
probing and disables the support for drm_gralloc.

The series has been tested on Qemu+AOSP, where a
virtio gpu was successfully probed for and
opened.

The current branch can be found here:
https://gitlab.collabora.com/robertfoss/mesa/tree/drm_probing_v5

Changes since v4:
 - Removed dead continue statement
 - Switched function argument to const char* from char*

Changes since v3:
 - Reduced number of probing return codes
 - Simplified driver vendor check in droid_probe_device()
 - Fixed type with ';' prepended to a if-statement
 - Removed a strlen call
 - Switched a sprintf to snprintf
 - Replaced fd == -1 check with < 0
 - Simplified switch+goto statements

Changes since v2:
 - Fixed whitespace issue
 - Diversified return codes from probing functions
 - Switched away from using drmGetDevices2, to iterating over
   /dev/dir/renderD nodes manually

Changes since v1:
 - Added fix for build issue
 - Do not rely on libdrm for probing
 - Distinguish between errors and when no drm devices are found

Changes since RFC:
 - Rebased work on the libdrm patch [2].
 - Included patch from Rob Herring disabling drm_gralloc/flink
   support by default.
 - Added device handler driver probing.


Rob Herring (1):
  egl/android: #ifdef out flink name support

Robert Foss (2):
  gallium/util: Fix build error due to cast to different size
  egl/android: Add DRM node probing and filtering

 src/egl/Android.mk|   6 +-
 src/egl/drivers/dri2/egl_dri2.h   |   2 -
 src/egl/drivers/dri2/platform_android.c   | 227 +++---
 .../auxiliary/util/u_debug_stack_android.cpp  |   4 +-
 4 files changed, 195 insertions(+), 44 deletions(-)

-- 
2.17.1

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


[Mesa-dev] [RESEND PATCH v5 2/3] egl/android: #ifdef out flink name support

2018-06-25 Thread Robert Foss
From: Rob Herring 

Maintaining both flink names and prime fd support which are provided by
2 different gralloc implementations is problematic because we have a
dependency on a specific gralloc implementation header.

This mostly disables the dependency on the gralloc implementation and
headers. The dependency on GRALLOC_MODULE_PERFORM_GET_DRM_FD remains for
now, but the definition is added locally to remove the header
dependency.

drm_gralloc support can be enabled by setting
BOARD_USES_DRM_GRALLOC=true in BoardConfig.mk.

Signed-off-by: Rob Herring 
Signed-off-by: Robert Foss 
Reviewed-by: Tomasz Figa 
---


Changes since v3:
 - Added r-b from Tomasz

 src/egl/Android.mk  |  6 ++-
 src/egl/drivers/dri2/egl_dri2.h |  2 -
 src/egl/drivers/dri2/platform_android.c | 56 +++--
 3 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/src/egl/Android.mk b/src/egl/Android.mk
index 11818694f4..8412aeb798 100644
--- a/src/egl/Android.mk
+++ b/src/egl/Android.mk
@@ -57,9 +57,13 @@ LOCAL_SHARED_LIBRARIES := \
libhardware \
liblog \
libcutils \
-   libgralloc_drm \
libsync
 
+ifeq ($(BOARD_USES_DRM_GRALLOC),true)
+   LOCAL_CFLAGS += -DHAVE_DRM_GRALLOC
+   LOCAL_SHARED_LIBRARIES += libgralloc_drm
+endif
+
 ifeq ($(filter $(MESA_ANDROID_MAJOR_VERSION), 4 5 6 7),)
 LOCAL_SHARED_LIBRARIES += libnativewindow
 endif
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index adabc527f8..5d8fbfa235 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -67,8 +67,6 @@ struct zwp_linux_dmabuf_v1;
 
 #include 
 #include 
-#include 
-
 #endif /* HAVE_ANDROID_PLATFORM */
 
 #include "eglconfig.h"
diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 1d6ed92bd6..4ba96aad90 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -37,7 +37,11 @@
 #include "loader.h"
 #include "egl_dri2.h"
 #include "egl_dri2_fallbacks.h"
+
+#ifdef HAVE_DRM_GRALLOC
+#include 
 #include "gralloc_drm.h"
+#endif /* HAVE_DRM_GRALLOC */
 
 #define ALIGN(val, align)  (((val) + (align) - 1) & ~((align) - 1))
 
@@ -164,11 +168,13 @@ get_native_buffer_fd(struct ANativeWindowBuffer *buf)
return (handle && handle->numFds) ? handle->data[0] : -1;
 }
 
+#ifdef HAVE_DRM_GRALLOC
 static int
 get_native_buffer_name(struct ANativeWindowBuffer *buf)
 {
return gralloc_drm_get_gem_handle(buf->handle);
 }
+#endif /* HAVE_DRM_GRALLOC */
 
 static EGLBoolean
 droid_window_dequeue_buffer(struct dri2_egl_surface *dri2_surf)
@@ -838,6 +844,7 @@ droid_create_image_from_prime_fd(_EGLDisplay *disp, 
_EGLContext *ctx,
return dri2_create_image_dma_buf(disp, ctx, NULL, attr_list);
 }
 
+#ifdef HAVE_DRM_GRALLOC
 static _EGLImage *
 droid_create_image_from_name(_EGLDisplay *disp, _EGLContext *ctx,
  struct ANativeWindowBuffer *buf)
@@ -881,6 +888,7 @@ droid_create_image_from_name(_EGLDisplay *disp, _EGLContext 
*ctx,
 
return &dri2_img->base;
 }
+#endif /* HAVE_DRM_GRALLOC */
 
 static EGLBoolean
 droid_query_surface(_EGLDriver *drv, _EGLDisplay *dpy, _EGLSurface *surf,
@@ -937,7 +945,11 @@ dri2_create_image_android_native_buffer(_EGLDisplay *disp,
if (fd >= 0)
   return droid_create_image_from_prime_fd(disp, ctx, buf, fd);
 
+#ifdef HAVE_DRM_GRALLOC
return droid_create_image_from_name(disp, ctx, buf);
+#else
+   return NULL;
+#endif
 }
 
 static _EGLImage *
@@ -959,6 +971,7 @@ droid_flush_front_buffer(__DRIdrawable * driDrawable, void 
*loaderPrivate)
 {
 }
 
+#ifdef HAVE_DRM_GRALLOC
 static int
 droid_get_buffers_parse_attachments(struct dri2_egl_surface *dri2_surf,
 unsigned int *attachments, int count)
@@ -1034,6 +1047,7 @@ droid_get_buffers_with_format(__DRIdrawable * driDrawable,
 
return dri2_surf->buffers;
 }
+#endif /* HAVE_DRM_GRALLOC */
 
 static unsigned
 droid_get_capability(void *loaderPrivate, enum dri_loader_cap cap)
@@ -1116,6 +1130,14 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *dpy)
return (config_count != 0);
 }
 
+enum {
+/* perform(const struct gralloc_module_t *mod,
+ * int op,
+ * int *fd);
+ */
+GRALLOC_MODULE_PERFORM_GET_DRM_FD = 0x4002,
+};
+
 static int
 droid_open_device(struct dri2_egl_display *dri2_dpy)
 {
@@ -1158,6 +1180,7 @@ static const struct dri2_egl_display_vtbl 
droid_display_vtbl = {
.get_dri_drawable = dri2_surface_get_dri_drawable,
 };
 
+#ifdef HAVE_DRM_GRALLOC
 static const __DRIdri2LoaderExtension droid_dri2_loader_extension = {
.base = { __DRI_DRI2_LOADER, 4 },
 
@@ -1166,6 +1189,7 @@ static const __DRIdri2LoaderExtension 
droid_dri2_loader_extension = {
.getBuffersWithFormat = droid_get_buffers_with_format,
.getCapability= droid_get_capability,
 };
+#endif /* HAVE_DRM_GRALLOC */
 
 static

[Mesa-dev] [RESEND PATCH v5 3/3] egl/android: Add DRM node probing and filtering

2018-06-25 Thread Robert Foss
This patch both adds support for probing & filtering DRM nodes
and switches away from using the GRALLOC_MODULE_PERFORM_GET_DRM_FD
gralloc call.

Currently the filtering is based just on the driver name,
and the desired name is supplied using the "drm.gpu.vendor_name"
Android property.

Signed-off-by: Robert Foss 
Reviewed-by: Tomasz Figa 
---

Changes since v4:
 - Removed dead continue statement
 - Switched function argument to const char* from char*
 - Added r-b from Tomasz

Changes since v3:
 - Reduced number of probing return codes
 - Simplified driver vendor check in droid_probe_device()
 - Fixed type with ';' prepended to a if-statement
 - Removed a strlen call
 - Switched a sprintf to snprintf
 - Replaced fd == -1 check with < 0
 - Simplified switch+goto statements

Changes since v2:
 - Switch from drmGetDevices2 to manual renderD node iteration
 - Add probe_res enum to communicate probing results better
 - Avoid using _eglError() in internal static functions
 - Avoid actually loading the driver while probing, just verify
   that it exists.
 - Replace strlen call with the assumed length PROPERTY_VALUE_MAX

Changes since v1:
 - Do not rely on libdrm for probing
 - Distinguish between errors and when no drm devices are found

Changes since RFC:
 - Rebased on newer libdrm drmHandleMatch patch
 - Added support for driver probing


 src/egl/drivers/dri2/platform_android.c | 223 ++--
 1 file changed, 170 insertions(+), 53 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 4ba96aad90..cc16fd8118 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -27,12 +27,16 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "loader.h"
 #include "egl_dri2.h"
@@ -1130,31 +1134,6 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *dpy)
return (config_count != 0);
 }
 
-enum {
-/* perform(const struct gralloc_module_t *mod,
- * int op,
- * int *fd);
- */
-GRALLOC_MODULE_PERFORM_GET_DRM_FD = 0x4002,
-};
-
-static int
-droid_open_device(struct dri2_egl_display *dri2_dpy)
-{
-   int fd = -1, err = -EINVAL;
-
-   if (dri2_dpy->gralloc->perform)
- err = dri2_dpy->gralloc->perform(dri2_dpy->gralloc,
-  GRALLOC_MODULE_PERFORM_GET_DRM_FD,
-  &fd);
-   if (err || fd < 0) {
-  _eglLog(_EGL_WARNING, "fail to get drm fd");
-  fd = -1;
-   }
-
-   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
-}
-
 static const struct dri2_egl_display_vtbl droid_display_vtbl = {
.authenticate = NULL,
.create_window_surface = droid_create_window_surface,
@@ -1215,6 +1194,169 @@ static const __DRIextension 
*droid_image_loader_extensions[] = {
NULL,
 };
 
+EGLBoolean
+droid_load_driver(_EGLDisplay *disp)
+{
+   struct dri2_egl_display *dri2_dpy = disp->DriverData;
+   const char *err;
+
+   dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+   if (dri2_dpy->driver_name == NULL)
+  return false;
+
+   dri2_dpy->is_render_node = drmGetNodeTypeFromFd(dri2_dpy->fd) == 
DRM_NODE_RENDER;
+
+   if (!dri2_dpy->is_render_node) {
+   #ifdef HAVE_DRM_GRALLOC
+   /* Handle control nodes using __DRI_DRI2_LOADER extension and GEM names
+* for backwards compatibility with drm_gralloc. (Do not use on new
+* systems.) */
+   dri2_dpy->loader_extensions = droid_dri2_loader_extensions;
+   if (!dri2_load_driver(disp)) {
+  err = "DRI2: failed to load driver";
+  goto error;
+   }
+   #else
+   err = "DRI2: handle is not for a render node";
+   goto error;
+   #endif
+   } else {
+   dri2_dpy->loader_extensions = droid_image_loader_extensions;
+   if (!dri2_load_driver_dri3(disp)) {
+  err = "DRI3: failed to load driver";
+  goto error;
+   }
+}
+
+   return true;
+
+error:
+   free(dri2_dpy->driver_name);
+   dri2_dpy->driver_name = NULL;
+   return false;
+}
+
+static bool
+droid_probe_driver(int fd)
+{
+   char *driver_name;
+
+   driver_name = loader_get_driver_for_fd(fd);
+   if (driver_name == NULL)
+  return false;
+
+   free(driver_name);
+   return true;
+}
+
+typedef enum {
+   probe_fail = -1,
+   probe_success = 0,
+   probe_filtered_out = 1,
+} probe_ret_t;
+
+static probe_ret_t
+droid_probe_device(_EGLDisplay *disp, int fd, const char *vendor)
+{
+   int ret;
+
+   drmVersionPtr ver = drmGetVersion(fd);
+   if (!ver)
+  return probe_fail;
+
+   if (!ver->name) {
+  ret = probe_fail;
+  goto cleanup;
+   }
+
+   if (vendor && strncmp(vendor, ver->name, PROPERTY_VALUE_MAX) != 0) {
+  ret = probe_filtered_out;
+  goto cleanup;
+   }
+
+   if (!droid_probe_driver(fd)) {
+  ret = probe_fail;
+  goto c

Re: [Mesa-dev] [PATCH] radv: fix HTILE metadata initialization in presence of subpass clears

2018-06-25 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

Still not sure why that would cause VM faults though.

On Mon, Jun 25, 2018 at 1:34 PM, Samuel Pitoiset
 wrote:
> If the driver ends up by performing a slow depthstencil clear,
> the HTILE metadata won't be initialized correctly.
>
> This fixes random VM faults on Polaris while running CTS
> with Bas's runner. This doesn't seem to regress performance.
>
> CC: 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 8bd41bc41a..0388e4b6e0 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -3987,14 +3987,7 @@ static void radv_handle_depth_image_transition(struct 
> radv_cmd_buffer *cmd_buffe
> if (!radv_image_has_htile(image))
> return;
>
> -   if (dst_layout == VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL &&
> -   (pending_clears & vk_format_aspects(image->vk_format)) == 
> vk_format_aspects(image->vk_format) &&
> -   cmd_buffer->state.render_area.offset.x == 0 && 
> cmd_buffer->state.render_area.offset.y == 0 &&
> -   cmd_buffer->state.render_area.extent.width == image->info.width &&
> -   cmd_buffer->state.render_area.extent.height == 
> image->info.height) {
> -   /* The clear will initialize htile. */
> -   return;
> -   } else if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
> +   if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
>radv_layout_has_htile(image, dst_layout, dst_queue_mask)) {
> /* TODO: merge with the clear if applicable */
> radv_initialize_htile(cmd_buffer, image, range, 0);
> --
> 2.18.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: fix HTILE metadata initialization in presence of subpass clears

2018-06-25 Thread Samuel Pitoiset



On 06/25/2018 01:51 PM, Bas Nieuwenhuizen wrote:

Reviewed-by: Bas Nieuwenhuizen 

Still not sure why that would cause VM faults though.


Me neither, especially because the VM faults only happen when running 
CTS with multithreads...




On Mon, Jun 25, 2018 at 1:34 PM, Samuel Pitoiset
 wrote:

If the driver ends up by performing a slow depthstencil clear,
the HTILE metadata won't be initialized correctly.

This fixes random VM faults on Polaris while running CTS
with Bas's runner. This doesn't seem to regress performance.

CC: 
Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 9 +
  1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8bd41bc41a..0388e4b6e0 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3987,14 +3987,7 @@ static void radv_handle_depth_image_transition(struct 
radv_cmd_buffer *cmd_buffe
 if (!radv_image_has_htile(image))
 return;

-   if (dst_layout == VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL &&
-   (pending_clears & vk_format_aspects(image->vk_format)) == 
vk_format_aspects(image->vk_format) &&
-   cmd_buffer->state.render_area.offset.x == 0 && 
cmd_buffer->state.render_area.offset.y == 0 &&
-   cmd_buffer->state.render_area.extent.width == image->info.width &&
-   cmd_buffer->state.render_area.extent.height == image->info.height) {
-   /* The clear will initialize htile. */
-   return;
-   } else if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
+   if (src_layout == VK_IMAGE_LAYOUT_UNDEFINED &&
radv_layout_has_htile(image, dst_layout, dst_queue_mask)) {
 /* TODO: merge with the clear if applicable */
 radv_initialize_htile(cmd_buffer, image, range, 0);
--
2.18.0

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

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


[Mesa-dev] [PATCH] nir: fixup intrinsic comment

2018-06-25 Thread Rob Clark
Now the deref is the first src.

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_intrinsics.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_intrinsics.py 
b/src/compiler/nir/nir_intrinsics.py
index e38d94b2d8a..4ec2aab574b 100644
--- a/src/compiler/nir/nir_intrinsics.py
+++ b/src/compiler/nir/nir_intrinsics.py
@@ -289,7 +289,7 @@ atomic3("atomic_counter_comp_swap")
 # and layout qualifiers that influence the semantics of the intrinsic.
 #
 # All image intrinsics take a four-coordinate vector and a sample index as
-# first two sources, determining the location within the image that will be
+# 2nd and 3rd sources, determining the location within the image that will be
 # accessed by the intrinsic.  Components not applicable to the image target
 # in use are undefined.  Image store takes an additional four-component
 # argument with the value to be written, and image atomic operations take
-- 
2.17.1

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


Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

2018-06-25 Thread Mike Lothian
I'll test these tonight, Dying Light in particular required an override -
hopefully that won't be necessary any more

On Mon, 25 Jun 2018 at 12:26 Timothy Arceri  wrote:

> Please note I've fixed up make check where is was broken when enabling
> some of these extensions. You can see all of the latests compat patches
> here:
>
> https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64
>
> On 22/06/18 18:47, Timothy Arceri wrote:
> > I've send all of these patches out already. The only change is to the
> > first 2 patches which fixes things so we store a double as 2 unsigned
> ints
> > rather than 2 floats.
> >
> > Everything here has corresponding piglit tests all of which are now
> > upstream with the exception of the compute shader display list test.
> >
> > Our current TODO list has 2 remaining extensions on it before it
> > should be ok to enable OpenGL 4.4 compat contexts in radeonsi.
> >
> >
> > ___
> > 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 mesa 2/4] vulkan: add VK_EXT_display_control [v8]

2018-06-25 Thread Danylo Piliaiev

Hello Keith,

I am not able to build Mesa after this patch:

wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’ 
specified in initializer

    .sequence_handler = wsi_display_sequence_handler,
    ^
wsi/wsi_common_display.c:991:24: warning: initialization from 
incompatible pointer type [-Wincompatible-pointer-types]

    .sequence_handler = wsi_display_sequence_handler,
    ^
wsi/wsi_common_display.c:991:24: note: (near initialization for 
‘event_context.page_flip_handler’)

wsi/wsi_common_display.c: In function ‘wsi_register_vblank_event’:
wsi/wsi_common_display.c:1373:17: error: implicit declaration of 
function ‘drmCrtcQueueSequence’ [-Werror=implicit-function-declaration]

   int ret = drmCrtcQueueSequence(wsi->fd, connector->crtc_id,
 ^
wsi/wsi_common_display.c: In function ‘wsi_acquire_xlib_display’:
wsi/wsi_common_display.c:2164:4: error: unknown type name 
‘xcb_randr_lease_t’

    xcb_randr_lease_t lease = xcb_generate_id(connection);
    ^
wsi/wsi_common_display.c:2165:4: error: unknown type name 
‘xcb_randr_create_lease_cookie_t’

    xcb_randr_create_lease_cookie_t cl_c =
    ^
wsi/wsi_common_display.c:2166:7: error: implicit declaration of function 
‘xcb_randr_create_lease’ [-Werror=implicit-function-declaration]

   xcb_randr_create_lease(connection, root, lease, 1, 1,
   ^
wsi/wsi_common_display.c:2168:4: error: unknown type name 
‘xcb_randr_create_lease_reply_t’

    xcb_randr_create_lease_reply_t *cl_r =
    ^
wsi/wsi_common_display.c:2169:7: error: implicit declaration of function 
‘xcb_randr_create_lease_reply’ [-Werror=implicit-function-declaration]

   xcb_randr_create_lease_reply(connection, cl_c, NULL);
   ^
wsi/wsi_common_display.c:2169:7: warning: initialization makes pointer 
from integer without a cast [-Wint-conversion]
wsi/wsi_common_display.c:2174:12: error: request for member ‘nfd’ in 
something not a structure or union

    if (cl_r->nfd > 0) {
    ^
wsi/wsi_common_display.c:2175:20: error: implicit declaration of 
function ‘xcb_randr_create_lease_reply_fds’ 
[-Werror=implicit-function-declaration]

   int *rcl_f = xcb_randr_create_lease_reply_fds(connection, cl_r);
    ^
wsi/wsi_common_display.c:2175:20: warning: initialization makes pointer 
from integer without a cast [-Wint-conversion]

wsi/wsi_common_display.c: In function ‘wsi_get_swapchain_counter’:
wsi/wsi_common_display.c:2313:14: error: implicit declaration of 
function ‘drmCrtcGetSequence’ [-Werror=implicit-function-declaration]

    int ret = drmCrtcGetSequence(wsi->fd, connector->crtc_id, value, NULL);

And before the patch Mesa compilation was also broken due to the 
xcb-randr dependency, please see bug 106976 
.
Without vulkan support Mesa compiles fine at the moment. I'm using 
Ubuntu 16.04 and my libs are seem older than expected. If it's ok that 
vulkan shouldn't compile with old libs then it's probably should be 
reflected in autoconf/meson.


- Danil

On 21.06.18 01:52, Keith Packard wrote:

This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.

v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
 been removed from the proposed kernel API.

 Add NULL parameter to drmCrtcQueueSequence ioctl as we
 don't care what sequence the event was actually queued to.

v3: Adapt to pthread clock switch to MONOTONIC

v4: Fix scope for wsi_display_mode andwsi_display_connector allocs

 Suggested-by: Jason Ekstrand 

v5: Adopt Jason Ekstrand's coding conventions

 Declare variables at first use, eliminate extra whitespace between
 types and names. Wrap lines to 80 columns.

 Use wsi_rel_to_abs_time helper function to convert relative
 timeouts to absolute timeouts without causing overflow.

 Suggested-by: Jason Ekstrand 

v6:
 Change WSI fence wait function to return VkResult instead of
 bool. This makes the meaning of the return value easier to
 understand, and allows for the indication of failure.

 Also change the WSI fence wait function to take only absolute
 timeouts and not provide an option for a relative timeout. No
 users wanted relative timeouts, and it's simpler if that option
 isn't available.

 Terminate the DPMS property loop once we've found the property.

 Assert that the fence hasn't already been destroyed in
 wsi_display_fence_destroy.

 Rearrange the event handler function order in the file to place
 routines in an easier to find order.

 Suggested-by: Jason Ekstrand 

v7:
 Adapt to API changes for surface_get_capabilities

v8:
 Use wsi->alloc in register_display_event so that callers
 don't have to dig out an allocator for us.

Signed-off-by: Keith Packard 
---
  src/vulkan/wsi/wsi_common.h |  10 +
  src/vulkan

[Mesa-dev] [PATCH] radv: enable VK_EXT_shader_stencil_export

2018-06-25 Thread Samuel Pitoiset
The driver already supports exporting the stencil value.

The following CTS test now pass:
dEQP-VK.pipeline.shader_stencil_export.op_replace

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_extensions.py | 1 +
 src/amd/vulkan/radv_shader.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index ebc3f6bc2b..a0f1038110 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -100,6 +100,7 @@ EXTENSIONS = [
 Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
 Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->rad_info.chip_class >= CIK'),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
+Extension('VK_EXT_shader_stencil_export', 1, True),
 Extension('VK_EXT_vertex_attribute_divisor',  1, True),
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_gcn_shader',1, True),
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 03185de304..c7ffd47c0b 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -222,6 +222,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.shader_viewport_index_layer = true,
.descriptor_array_dynamic_indexing = true,
.runtime_descriptor_array = true,
+   .stencil_export = true,
},
};
entry_point = spirv_to_nir(spirv, module->size / 4,
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH] nir: fixup intrinsic comment

2018-06-25 Thread Samuel Iglesias Gonsálvez
Reviewed-by: Samuel Iglesias Gonsálvez 


On 25/06/18 14:17, Rob Clark wrote:
> Now the deref is the first src.
>
> Signed-off-by: Rob Clark 
> ---
>  src/compiler/nir/nir_intrinsics.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compiler/nir/nir_intrinsics.py 
> b/src/compiler/nir/nir_intrinsics.py
> index e38d94b2d8a..4ec2aab574b 100644
> --- a/src/compiler/nir/nir_intrinsics.py
> +++ b/src/compiler/nir/nir_intrinsics.py
> @@ -289,7 +289,7 @@ atomic3("atomic_counter_comp_swap")
>  # and layout qualifiers that influence the semantics of the intrinsic.
>  #
>  # All image intrinsics take a four-coordinate vector and a sample index as
> -# first two sources, determining the location within the image that will be
> +# 2nd and 3rd sources, determining the location within the image that will be
>  # accessed by the intrinsic.  Components not applicable to the image target
>  # in use are undefined.  Image store takes an additional four-component
>  # argument with the value to be written, and image atomic operations take



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


[Mesa-dev] [PATCH] radv: ignore pInheritanceInfo for primary command buffers

2018-06-25 Thread Samuel Pitoiset
From the Vulkan spec:
"If this is a primary command buffer, then this value is ignored."

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 8bd41bc41a..6d3309ff1e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -2285,7 +2285,8 @@ VkResult radv_BeginCommandBuffer(
}
}
 
-   if (pBeginInfo->flags & 
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT) {
+   if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_SECONDARY &&
+   (pBeginInfo->flags & 
VK_COMMAND_BUFFER_USAGE_RENDER_PASS_CONTINUE_BIT)) {
assert(pBeginInfo->pInheritanceInfo);
cmd_buffer->state.framebuffer = 
radv_framebuffer_from_handle(pBeginInfo->pInheritanceInfo->framebuffer);
cmd_buffer->state.pass = 
radv_render_pass_from_handle(pBeginInfo->pInheritanceInfo->renderPass);
-- 
2.18.0

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


Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

2018-06-25 Thread Keith Packard
Danylo Piliaiev  writes:

> Hello Keith,
>
> I am not able to build Mesa after this patch:
>
> wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’ 
> specified in initializer
>      .sequence_handler = wsi_display_sequence_handler,

Sounds like you need a newer libdrm that includes
DRM_EVENT_CONTEXT_VERSION 4

-- 
-keith


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


[Mesa-dev] [PATCH 0/4] fixes primarily for LLVM trunk support v2

2018-06-25 Thread Alok Hota
These code changes were made in between some of the formatting changes.
Unforunately we do have another formatting patch coming in after this,
but I will keep that separate.

These patches are primarily focused on enhancing the BuilderGfxMem in
our internal rasterizer and to support changes in the LLVM trunk going
into version 7.0.0

v2 : accidentally included the wrong commits into the patch. Previous
version included the formatting commit that was supposed to come after
this patch, and did not include the first commit prior to adding
SCATTERPS functionality

Alok Hota (3):
  swr/rast: Adding Read/Write specifier to TranslateGfxAddress stack
  swr/rast: Adding SCATTERPS functionality to BuilderGfxMem
  swr/rast: Handling removed LLVM intrinsics in trunk

Vinson Lee (1):
  swr/rast: Fix addPassesToEmitFile usage with llvm-7.0.

 .../swr/rasterizer/jitter/JitManager.cpp  |  4 ++
 .../swr/rasterizer/jitter/builder_gfx_mem.cpp | 31 -
 .../swr/rasterizer/jitter/builder_gfx_mem.h   | 43 ---
 .../jitter/functionpasses/lower_x86.cpp   | 40 +
 4 files changed, 91 insertions(+), 27 deletions(-)

-- 
2.17.1

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


[Mesa-dev] [PATCH 3/4] swr/rast: Handling removed LLVM intrinsics in trunk

2018-06-25 Thread Alok Hota
- Functionality replaced with emulated intrinsics
- Fixes Bug 106558
---
 .../jitter/functionpasses/lower_x86.cpp   | 40 +++
 1 file changed, 40 insertions(+)

diff --git 
a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
index 2a01c706b9..c561c8076d 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp
@@ -92,6 +92,8 @@ namespace SwrJit
 VROUND_EMU(LowerX86 *pThis, TargetArch arch, TargetWidth width, CallInst 
*pCallInst);
 Instruction *
 VHSUB_EMU(LowerX86 *pThis, TargetArch arch, TargetWidth width, CallInst 
*pCallInst);
+Instruction *
+VCONVERT_EMU(LowerX86 *pThis, TargetArch arch, TargetWidth width, CallInst 
*pCallInst);
 
 Instruction *DOUBLE_EMU(LowerX86 *pThis,
 TargetArcharch,
@@ -146,6 +148,7 @@ namespace SwrJit
 // AVX512
 {"meta.intrinsic.VRCPPS",
  {{Intrinsic::x86_avx512_rcp14_ps_256, 
Intrinsic::x86_avx512_rcp14_ps_512}, NO_EMU}},
+#if LLVM_VERSION_MAJOR < 7
 {"meta.intrinsic.VPERMPS",
  {{Intrinsic::x86_avx512_mask_permvar_sf_256,
Intrinsic::x86_avx512_mask_permvar_sf_512},
@@ -154,15 +157,26 @@ namespace SwrJit
  {{Intrinsic::x86_avx512_mask_permvar_si_256,
Intrinsic::x86_avx512_mask_permvar_si_512},
   NO_EMU}},
+#else
+{"meta.intrinsic.VPERMPS",
+ {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VPERM_EMU}},
+{"meta.intrinsic.VPERMD",
+ {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VPERM_EMU}},
+#endif
 {"meta.intrinsic.VGATHERPD",
  {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VGATHER_EMU}},
 {"meta.intrinsic.VGATHERPS",
  {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VGATHER_EMU}},
 {"meta.intrinsic.VGATHERDD",
  {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VGATHER_EMU}},
+#if LLVM_VERSION_MAJOR < 7
 {"meta.intrinsic.VCVTPD2PS",
  {{Intrinsic::x86_avx512_mask_cvtpd2ps_256, 
Intrinsic::x86_avx512_mask_cvtpd2ps_512},
   NO_EMU}},
+#else
+{"meta.intrinsic.VCVTPD2PS",
+ {{Intrinsic::not_intrinsic, Intrinsic::not_intrinsic}, 
VCONVERT_EMU}},
+#endif
 {"meta.intrinsic.VCVTPH2PS",
  {{Intrinsic::x86_avx512_mask_vcvtph2ps_256, 
Intrinsic::x86_avx512_mask_vcvtph2ps_512},
   NO_EMU}},
@@ -662,6 +676,32 @@ namespace SwrJit
 return nullptr;
 }
 
+Instruction *VCONVERT_EMU(LowerX86* pThis, TargetArch arch, TargetWidth 
width, CallInst* pCallInst)
+{
+SWR_ASSERT(arch == AVX512);
+
+auto B = pThis->B;
+auto vf32Src = pCallInst->getOperand(0);
+
+if (width == W256)
+{
+auto vf32SrcRound = 
Intrinsic::getDeclaration(B->JM()->mpCurrentModule, 
Intrinsic::x86_avx_round_ps_256);
+return cast(B->FP_TRUNC(vf32SrcRound, B->mFP32Ty));
+}
+else if (width == W512)
+{
+// 512 can use intrinsic
+auto pfnFunc = Intrinsic::getDeclaration(B->JM()->mpCurrentModule, 
Intrinsic::x86_avx512_mask_cvtpd2ps_512);
+return cast(B->CALL(pfnFunc, vf32Src));
+}
+else
+{
+SWR_ASSERT(false, "Unimplemented vector width.");
+}
+
+return nullptr;
+}
+
 // No support for hsub in AVX512
 Instruction *VHSUB_EMU(LowerX86 *pThis, TargetArch arch, TargetWidth 
width, CallInst *pCallInst)
 {
-- 
2.17.1

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


[Mesa-dev] [PATCH 2/4] swr/rast: Adding SCATTERPS functionality to BuilderGfxMem

2018-06-25 Thread Alok Hota
---
 .../swr/rasterizer/jitter/builder_gfx_mem.cpp   | 13 +
 .../drivers/swr/rasterizer/jitter/builder_gfx_mem.h |  6 ++
 2 files changed, 19 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
index 8706bfa66b..df11914db1 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
@@ -108,6 +108,19 @@ namespace SwrJit
 return vGather;
 }
 
+void BuilderGfxMem::SCATTERPS(
+Value* pDst, Value* vSrc, Value* vOffsets, Value* vMask, 
JIT_MEM_CLIENT usage)
+{
+
+// address may be coming in as 64bit int now so get the pointer
+if (pDst->getType() == mInt64Ty)
+{
+pDst = INT_TO_PTR(pDst, PointerType::get(mInt8Ty, 0));
+}
+
+Builder::SCATTERPS(pDst, vSrc, vOffsets, vMask, usage);
+}
+
 
 Value *BuilderGfxMem::OFFSET_TO_NEXT_COMPONENT(Value *base, Constant 
*offset)
 {
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h 
b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
index a552ff9b26..dd20c06afe 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
+++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
@@ -88,6 +88,12 @@ namespace SwrJit
 uint8_tscale = 1,
 JIT_MEM_CLIENT usage = MEM_CLIENT_INTERNAL);
 
+virtual void SCATTERPS(Value* pDst,
+   Value* vSrc,
+   Value* vOffsets,
+   Value* vMask,
+   JIT_MEM_CLIENT usage = MEM_CLIENT_INTERNAL);
+
 
 Value *TranslateGfxAddressForRead(Value *xpGfxAddress,
   Type * PtrTy = nullptr,
-- 
2.17.1

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


[Mesa-dev] [PATCH 4/4] swr/rast: Fix addPassesToEmitFile usage with llvm-7.0.

2018-06-25 Thread Alok Hota
From: Vinson Lee 

Fix build error after llvm-7.0svn r332881 ("CodeGen: Add a dwo output
file argument to addPassesToEmitFile and hook it up to dwo output.").

  CXX  rasterizer/jitter/libmesaswr_la-JitManager.lo
rasterizer/jitter/JitManager.cpp:368:93: error: too few arguments to function 
call, expected at least 4, have 3
pTarget->addPassesToEmitFile(*pMPasses, filestream, 
TargetMachine::CGFT_AssemblyFile);

^
---
 src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index 5cf527ecd8..5bacf55126 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -414,7 +414,11 @@ void JitManager::DumpAsm(Function *pFunction, const char 
*fileName)
 legacy::PassManager *pMPasses = new legacy::PassManager();
 auto *   pTarget  = mpExec->getTargetMachine();
 pTarget->Options.MCOptions.AsmVerbose = true;
+#if LLVM_VERSION_MAJOR >= 7
+pTarget->addPassesToEmitFile(*pMPasses, filestream, nullptr, 
TargetMachine::CGFT_AssemblyFile);
+#else
 pTarget->addPassesToEmitFile(*pMPasses, filestream, 
TargetMachine::CGFT_AssemblyFile);
+#endif
 pMPasses->run(*pModule);
 delete pMPasses;
 pTarget->Options.MCOptions.AsmVerbose = false;
-- 
2.17.1

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


[Mesa-dev] [PATCH 1/4] swr/rast: Adding Read/Write specifier to TranslateGfxAddress stack

2018-06-25 Thread Alok Hota
- Removing unused generic translate function
- Requiring read/write specifier in builder_gfx_mem
---
 .../swr/rasterizer/jitter/builder_gfx_mem.cpp | 18 -
 .../swr/rasterizer/jitter/builder_gfx_mem.h   | 37 ++-
 2 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
index 3f4b090cfc..8706bfa66b 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.cpp
@@ -40,7 +40,8 @@ namespace SwrJit
 BuilderGfxMem::BuilderGfxMem(JitManager *pJitMgr) : Builder(pJitMgr)
 {
 mpTranslationFuncTy = nullptr;
-mpfnTranslateGfxAddress = nullptr;
+mpfnTranslateGfxAddressForRead = nullptr;
+mpfnTranslateGfxAddressForWrite = nullptr;
 mpParamSimDC= nullptr;
 
 }
@@ -221,7 +222,7 @@ namespace SwrJit
 return Builder::MASKED_LOAD(Ptr, Align, Mask, PassThru, Name, Ty, 
usage);
 }
 
-Value *BuilderGfxMem::TranslateGfxAddress(Value *  xpGfxAddress,
+Value *BuilderGfxMem::TranslateGfxAddressForRead(Value *  xpGfxAddress,
   Type *   PtrTy,
   const Twine &Name,
   JIT_MEM_CLIENT /* usage */)
@@ -232,4 +233,17 @@ namespace SwrJit
 }
 return INT_TO_PTR(xpGfxAddress, PtrTy, Name);
 }
+
+Value *BuilderGfxMem::TranslateGfxAddressForWrite(Value *  
xpGfxAddress,
+ Type *   PtrTy,
+ const Twine &Name,
+ JIT_MEM_CLIENT /* usage 
*/)
+{
+if (PtrTy == nullptr)
+{
+PtrTy = mInt8PtrTy;
+}
+return INT_TO_PTR(xpGfxAddress, PtrTy, Name);
+}
+
 } // namespace SwrJit
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h 
b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
index ab6f78ee81..a552ff9b26 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
+++ b/src/gallium/drivers/swr/rasterizer/jitter/builder_gfx_mem.h
@@ -89,29 +89,14 @@ namespace SwrJit
 JIT_MEM_CLIENT usage = MEM_CLIENT_INTERNAL);
 
 
-Value *TranslateGfxAddress(Value *xpGfxAddress,
-   Type * PtrTy = nullptr,
-   const Twine &  Name  = "",
-   JIT_MEM_CLIENT usage = MEM_CLIENT_INTERNAL);
-template 
-Value *TranslateGfxAddress(Value * 
xpGfxBaseAddress,
-   const std::initializer_list &offset,
-   Type *  PtrTy = 
nullptr,
-   const Twine &   Name  = "",
-   JIT_MEM_CLIENT  usage = 
GFX_MEM_CLIENT_SHADER)
-{
-AssertGFXMemoryParams(xpGfxBaseAddress, usage);
-SWR_ASSERT(xpGfxBaseAddress->getType()->isPointerTy() == false);
-
-if (!PtrTy)
-{
-PtrTy = mInt8PtrTy;
-}
-
-Value *ptr = INT_TO_PTR(xpGfxBaseAddress, PtrTy);
-ptr= GEP(ptr, offset);
-return TranslateGfxAddress(PTR_TO_INT(ptr, mInt64Ty), PtrTy, Name, 
usage);
-}
+Value *TranslateGfxAddressForRead(Value *xpGfxAddress,
+  Type * PtrTy = nullptr,
+  const Twine &  Name  = "",
+  JIT_MEM_CLIENT usage = 
MEM_CLIENT_INTERNAL);
+Value *TranslateGfxAddressForWrite(Value *xpGfxAddress,
+   Type * PtrTy = nullptr,
+   const Twine &  Name  = "",
+   JIT_MEM_CLIENT usage = 
MEM_CLIENT_INTERNAL);
 
 
 protected:
@@ -124,13 +109,15 @@ namespace SwrJit
 Value *TranslationHelper(Value *Ptr, Type *Ty);
 
 FunctionType *GetTranslationFunctionType() { return 
mpTranslationFuncTy; }
-Value *   GetTranslationFunction() { return 
mpfnTranslateGfxAddress; }
+Value *   GetTranslationFunctionForRead() { return 
mpfnTranslateGfxAddressForRead; }
+Value *   GetTranslationFunctionForWrite() { return 
mpfnTranslateGfxAddressForWrite; }
 Value *   GetParamSimDC() { return mpParamSimDC; }
 
 
 private:
 FunctionType *mpTranslationFuncTy;
-Value *   mpfnTranslateGfxAddress;
+Value *   mpfnTranslateGfxAddressForRead;
+

Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

2018-06-25 Thread Danylo Piliaiev

Thanks, then should this dependency be expressed in autoconf and meson?

- Danil

On 25.06.18 17:32, Keith Packard wrote:

Danylo Piliaiev  writes:


Hello Keith,

I am not able to build Mesa after this patch:

wsi/wsi_common_display.c:991:4: error: unknown field ‘sequence_handler’
specified in initializer
      .sequence_handler = wsi_display_sequence_handler,

Sounds like you need a newer libdrm that includes
DRM_EVENT_CONTEXT_VERSION 4



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


[Mesa-dev] [PATCH] virgl: Add support for glGetMultisample

2018-06-25 Thread Gert Wollny
Use caps to obtain the multisample sample positions for up to 16
positions and implement the according Gallium interface.

Signed-off-by: Gert Wollny 
---
This patch requires another patch against virglrenderer to work. 

 src/gallium/drivers/virgl/virgl_context.c | 48 +++
 src/gallium/drivers/virgl/virgl_hw.h  |  1 +
 src/gallium/drivers/virgl/virgl_screen.c  |  8 +---
 3 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 8d701bb8f4..fedd9786c0 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -858,6 +858,52 @@ virgl_context_destroy( struct pipe_context *ctx )
FREE(vctx);
 }
 
+static void virgl_get_sample_position(struct pipe_context *ctx,
+  unsigned sample_count,
+  unsigned index,
+  float *out_value)
+{
+   struct virgl_context *vctx = virgl_context(ctx);
+   struct virgl_screen *vs = virgl_screen(vctx->base.screen);
+
+   int sample_count_selector = 1;
+
+   if (sample_count > vs->caps.caps.v1.max_samples) {
+  debug_printf("VIRGL: requested %d MSAA samples, but only %d supported\n",
+   sample_count, vs->caps.caps.v1.max_samples);
+  return;
+   }
+
+   /* For non-power of two sample counts pick the next higher power of two
+* to base the sample positions on */
+   while (sample_count_selector < sample_count)
+  sample_count_selector <<= 1;
+
+   /* The following is basically copied from dri/i965gen6_get_sample_position
+* The only addition is that we hold the msaa positions for all sample
+* counts in a flat array. */
+   uint32_t bits = 0;
+   switch (sample_count_selector) {
+   case 1:
+  out_value[0] = out_value[1] = 0.5f;
+  return;
+   case 2:
+  bits = vs->caps.caps.v2.msaa_sample_positions[0] >> (8 * index);
+  break;
+   case 4:
+  bits = vs->caps.caps.v2.msaa_sample_positions[1] >> (8 * index);
+  break;
+   case 8:
+  bits = vs->caps.caps.v2.msaa_sample_positions[2 + (index >> 2)] >> (8 * 
(index & 3));
+  break;
+   case 16:
+  bits = vs->caps.caps.v2.msaa_sample_positions[4 + (index >> 2)] >> (8 * 
(index & 3));
+  break;
+   }
+   out_value[0] = ((bits >> 4) & 0xf) / 16.0f;
+   out_value[1] = (bits & 0xf) / 16.0f;
+}
+
 struct pipe_context *virgl_context_create(struct pipe_screen *pscreen,
   void *priv,
   unsigned flags)
@@ -925,6 +971,8 @@ struct pipe_context *virgl_context_create(struct 
pipe_screen *pscreen,
 
vctx->base.set_blend_color = virgl_set_blend_color;
 
+   vctx->base.get_sample_position = virgl_get_sample_position;
+
vctx->base.resource_copy_region = virgl_resource_copy_region;
vctx->base.flush_resource = virgl_flush_resource;
vctx->base.blit =  virgl_blit;
diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index ee58520f9b..82cbb8aed1 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -298,6 +298,7 @@ struct virgl_caps_v2 {
 uint32_t uniform_buffer_offset_alignment;
 uint32_t shader_buffer_offset_alignment;
 uint32_t capability_bits;
+uint32_t msaa_sample_positions[8];
 };
 
 union virgl_caps {
diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
b/src/gallium/drivers/virgl/virgl_screen.c
index c9d8b84062..e8d1c75177 100755
--- a/src/gallium/drivers/virgl/virgl_screen.c
+++ b/src/gallium/drivers/virgl/virgl_screen.c
@@ -49,13 +49,7 @@ virgl_get_vendor(struct pipe_screen *screen)
 static const char *
 virgl_get_name(struct pipe_screen *screen)
 {
-   static char driver_name[120];
-   struct virgl_screen *vscreen = virgl_screen(screen);
-   snprintf(driver_name, 119, "virgl (Host: %s, vrend: %s)",
-vscreen->caps.caps.v2.host_gl_version_string,
-vscreen->caps.caps.v2.host_virglrenderer_version);
-   driver_name[119] = 0;
-   return driver_name;
+   return "virgl";
 }
 
 static int
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] virgl: Add support for glGetMultisample

2018-06-25 Thread Ilia Mirkin
On Mon, Jun 25, 2018 at 10:55 AM, Gert Wollny  wrote:
> diff --git a/src/gallium/drivers/virgl/virgl_screen.c 
> b/src/gallium/drivers/virgl/virgl_screen.c
> index c9d8b84062..e8d1c75177 100755
> --- a/src/gallium/drivers/virgl/virgl_screen.c
> +++ b/src/gallium/drivers/virgl/virgl_screen.c
> @@ -49,13 +49,7 @@ virgl_get_vendor(struct pipe_screen *screen)
>  static const char *
>  virgl_get_name(struct pipe_screen *screen)
>  {
> -   static char driver_name[120];
> -   struct virgl_screen *vscreen = virgl_screen(screen);
> -   snprintf(driver_name, 119, "virgl (Host: %s, vrend: %s)",
> -vscreen->caps.caps.v2.host_gl_version_string,
> -vscreen->caps.caps.v2.host_virglrenderer_version);
> -   driver_name[119] = 0;
> -   return driver_name;
> +   return "virgl";
>  }
>
>  static int

This hunk seems unrelated to multisample positions...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

2018-06-25 Thread Keith Packard
Danylo Piliaiev  writes:

> Thanks, then should this dependency be expressed in autoconf and
> meson?

Yup; looks like we missed a step.

-- 
-keith


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


[Mesa-dev] [PATCH] virgl: Add support for glGetMultisample (v2)

2018-06-25 Thread Gert Wollny
Use caps to obtain the multisample sample positions for up to 16
positions and implement the according Gallium interface.

v2: remove unrelated chunk (thanks Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
This patch requires another patch against virglrenderer to work. 

 src/gallium/drivers/virgl/virgl_context.c | 48 +++
 src/gallium/drivers/virgl/virgl_hw.h  |  1 +
 src/gallium/drivers/virgl/virgl_screen.c  |  8 +---
 3 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/src/gallium/drivers/virgl/virgl_context.c 
b/src/gallium/drivers/virgl/virgl_context.c
index 8d701bb8f4..fedd9786c0 100644
--- a/src/gallium/drivers/virgl/virgl_context.c
+++ b/src/gallium/drivers/virgl/virgl_context.c
@@ -858,6 +858,52 @@ virgl_context_destroy( struct pipe_context *ctx )
FREE(vctx);
 }
 
+static void virgl_get_sample_position(struct pipe_context *ctx,
+  unsigned sample_count,
+  unsigned index,
+  float *out_value)
+{
+   struct virgl_context *vctx = virgl_context(ctx);
+   struct virgl_screen *vs = virgl_screen(vctx->base.screen);
+
+   int sample_count_selector = 1;
+
+   if (sample_count > vs->caps.caps.v1.max_samples) {
+  debug_printf("VIRGL: requested %d MSAA samples, but only %d supported\n",
+   sample_count, vs->caps.caps.v1.max_samples);
+  return;
+   }
+
+   /* For non-power of two sample counts pick the next higher power of two
+* to base the sample positions on */
+   while (sample_count_selector < sample_count)
+  sample_count_selector <<= 1;
+
+   /* The following is basically copied from dri/i965gen6_get_sample_position
+* The only addition is that we hold the msaa positions for all sample
+* counts in a flat array. */
+   uint32_t bits = 0;
+   switch (sample_count_selector) {
+   case 1:
+  out_value[0] = out_value[1] = 0.5f;
+  return;
+   case 2:
+  bits = vs->caps.caps.v2.msaa_sample_positions[0] >> (8 * index);
+  break;
+   case 4:
+  bits = vs->caps.caps.v2.msaa_sample_positions[1] >> (8 * index);
+  break;
+   case 8:
+  bits = vs->caps.caps.v2.msaa_sample_positions[2 + (index >> 2)] >> (8 * 
(index & 3));
+  break;
+   case 16:
+  bits = vs->caps.caps.v2.msaa_sample_positions[4 + (index >> 2)] >> (8 * 
(index & 3));
+  break;
+   }
+   out_value[0] = ((bits >> 4) & 0xf) / 16.0f;
+   out_value[1] = (bits & 0xf) / 16.0f;
+}
+
 struct pipe_context *virgl_context_create(struct pipe_screen *pscreen,
   void *priv,
   unsigned flags)
@@ -925,6 +971,8 @@ struct pipe_context *virgl_context_create(struct 
pipe_screen *pscreen,
 
vctx->base.set_blend_color = virgl_set_blend_color;
 
+   vctx->base.get_sample_position = virgl_get_sample_position;
+
vctx->base.resource_copy_region = virgl_resource_copy_region;
vctx->base.flush_resource = virgl_flush_resource;
vctx->base.blit =  virgl_blit;
diff --git a/src/gallium/drivers/virgl/virgl_hw.h 
b/src/gallium/drivers/virgl/virgl_hw.h
index ee58520f9b..82cbb8aed1 100644
--- a/src/gallium/drivers/virgl/virgl_hw.h
+++ b/src/gallium/drivers/virgl/virgl_hw.h
@@ -298,6 +298,7 @@ struct virgl_caps_v2 {
 uint32_t uniform_buffer_offset_alignment;
 uint32_t shader_buffer_offset_alignment;
 uint32_t capability_bits;
+uint32_t msaa_sample_positions[8];
 };
 
 union virgl_caps {-- 
2.17.1

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


Re: [Mesa-dev] [PATCH mesa 2/4] vulkan: add VK_EXT_display_control [v8]

2018-06-25 Thread Danylo Piliaiev
Also to fix a part of the issue in autoconf (with xcb-randr) I sent the 
patch  previously. I 
believe it won't merge cleanly now, should I remake it?


And I noticed that in meson build xcb-randr dependency is set to >= 1.12 :

dep_xcb_xrandr = dependency('xcb-randr', version : '>= 1.12')

When I checked it appeared only version 1.13 has required functionality.

On 25.06.18 18:13, Keith Packard wrote:

Danylo Piliaiev  writes:


Thanks, then should this dependency be expressed in autoconf and
meson?

Yup; looks like we missed a step.



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


Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

2018-06-25 Thread Roland Scheidegger
I didn't actually get the original email for some reason, so can't
comment inline as I'm just looking it up at patchwork...
But the array offset stuff (the first patch) looks completely bogus to
me, array textures do not support offsets for the array index, at least
not in any shader language I know of.

I'm not really sure about the 2nd patch, what exactly is the difference
with the ordinary rounding and the new one? Is there just a difference
for values exactly between 2 integers (e.g. 1.5 etc.)? In this case I
would suspect the driver is allowed to pick either value and the test is
bogus.
If that's not the case, it looks like it actually needs to be one patch?
You're adding the 0.5 offset in one but adjust the sampler state which
probably needs to match in another?

Roland

Am 25.06.2018 um 07:54 schrieb Dave Airlie:
> /home/airlied/devel/piglit/bin/textureGather fs nonconst r 0 float
> 2DArray repeat
> 
> amongst others appears to regress with these two.
> 
> Dave.
> 
> 
> On 22 June 2018 at 19:37, Gert Wollny  wrote:
>> these two patches correct the offets and the rounding modes for the
>> index evaluation when accessing texture arrays. The patches were tested
>> with the gles3 test suite where they fix a number of tests related to 2D
>> texture arrays and didn't show any regressions.
>>
>> Best,
>> Gert
>>
>> Gert Wollny (2):
>>   r600: correct texture offset for array index lookup
>>   r600: set rounding mode for texture array layer selection
>>
>>  src/gallium/drivers/r600/evergreen_state.c | 21 ++
>>  src/gallium/drivers/r600/r600_shader.c | 64 
>> +-
>>  2 files changed, 84 insertions(+), 1 deletion(-)
>>
>> --
>> 2.16.4
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=02%7C01%7Csroland%40vmware.com%7C038ae632c8354209810c08d5da601219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C1%7C636655028533194684&sdata=gvQB0DNGvaNwBN5EHlJNrXED4biq3xC4rFqNEYqS3xs%3D&reserved=0
> 

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


Re: [Mesa-dev] [PATCH 3/4] glsl/glcpp/tests: reinstate srcdir/abs_builddir blurb

2018-06-25 Thread Dylan Baker
Quoting Dylan Baker (2018-06-21 08:15:20)
> Quoting Emil Velikov (2018-04-24 10:49:21)
> > From: Emil Velikov 
> > 
> > Bring back the "detection" of the said variables, to allow
> > standalone execution.
> > 
> > Fixes: db8cd8e36771 ("glcpp/tests: Convert shell scripts to a python
> > script")
> > Cc: Dylan Baker 
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/compiler/glsl/glcpp/tests/glcpp-test.sh | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/src/compiler/glsl/glcpp/tests/glcpp-test.sh 
> > b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> > index 7ca8aa26a8..b8397ec890 100755
> > --- a/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> > +++ b/src/compiler/glsl/glcpp/tests/glcpp-test.sh
> > @@ -1,3 +1,16 @@
> >  #!/bin/sh
> >  
> > +if [ -z "$srcdir" -o -z "$abs_builddir" ]; then
> > +echo ""
> > +echo "Warning: you're invoking the script manually and things may 
> > fail."
> > +echo "Attempting to determine/set srcdir and abs_builddir variables."
> > +echo ""
> > +
> > +# Should point to `dirname Makefile.glsl.am`
> > +srcdir=./../../../
> > +cd `dirname "$0"`
> > +# Should point to `dirname Makefile` equivalent to the above.
> > +abs_builddir=`pwd`/../../../
> > +fi
> > +
> >  $PYTHON2 $srcdir/glsl/glcpp/tests/glcpp_test.py 
> > $abs_builddir/glsl/glcpp/glcpp $srcdir/glsl/glcpp/tests --unix --windows 
> > --oldmac --bizarro
> > -- 
> > 2.16.0
> > 
> 
> Hi Emil,
> 
> This doesn't apply cleanly to 18.1 because it needs the previous patch. Would
> you like me to pull that as well, or drop this?
> 
> Dylan
> 

Ping.


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: Unconditionally enable floating-point textures

2018-06-25 Thread Chuck Atkins
I know I'm a bit late to the party here, but WooHoo!  We've been waiting
for this to go away for years now.  While we still probably need to keep
some workaround code around for a bit since various "system" versions won't
have it for a while, we can finally start reliably depending on floating
point textures in our distributed binaries without assuming shifting legal
risk

--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.



On Sat, Jun 16, 2018 at 9:10 PM Ian Romanick  wrote:

> Reviewed-by: Ian Romanick 
>
> I'd also be in favor of a patch for stable that just removes
> docs/patents.txt and the references to it by the build system.  Since we
> don't like to enable new features in stable, the flag would need to stay.
>
> On 06/16/2018 05:00 PM, Timothy Arceri wrote:
> > ARB_texture_float references US Patent #6,650,327 [1] which has a filing
> date
> > of June 16 1998.
> >
> > According to [2], patents filed after 1995 expire 20 years from the
> filing
> > date, giving an expiration of June 17 2018.
> >
> > [1] https://www.google.com/patents/US6650327
> > [2] https://en.wikipedia.org/wiki/Term_of_patent_in_the_United_States
> > ---
> >  configure.ac  | 15 -
> >  docs/patents.txt  | 31 ---
> >  meson.build   |  4 
> >  meson_options.txt |  6 --
> >  scons/gallium.py  |  4 
> >  src/gallium/auxiliary/util/u_format.c |  9 
> >  src/mesa/main/extensions.c|  2 --
> >  7 files changed, 71 deletions(-)
> >  delete mode 100644 docs/patents.txt
> >
> > diff --git a/configure.ac b/configure.ac
> > index 3f747bf38cc..7a0e4754208 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -763,21 +763,6 @@ esac
> >
> >  AC_SUBST([LIB_EXT])
> >
> > -dnl
> > -dnl potentially-infringing-but-nobody-knows-for-sure stuff
> > -dnl
> > -AC_ARG_ENABLE([texture-float],
> > -[AS_HELP_STRING([--enable-texture-float],
> > -[enable floating-point textures and renderbuffers
> @<:@default=disabled@:>@])],
> > -[enable_texture_float="$enableval"],
> > -[enable_texture_float=no]
> > -)
> > -if test "x$enable_texture_float" = xyes; then
> > -AC_MSG_WARN([Floating-point textures enabled.])
> > -AC_MSG_WARN([Please consult docs/patents.txt with your lawyer
> before building Mesa.])
> > -DEFINES="$DEFINES -DTEXTURE_FLOAT_ENABLED"
> > -fi
> > -
> >  dnl
> >  dnl Arch/platform-specific settings
> >  dnl
> > diff --git a/docs/patents.txt b/docs/patents.txt
> > deleted file mode 100644
> > index 91c5757d14d..000
> > --- a/docs/patents.txt
> > +++ /dev/null
> > @@ -1,31 +0,0 @@
> > -ARB_texture_float:
> > -
> > -Silicon Graphics, Inc. owns US Patent #6,650,327, issued November
> 18,
> > -2003 [1].
> > -
> > -SGI believes this patent contains necessary IP for graphics systems
> > -implementing floating point rasterization and floating point
> > -framebuffer capabilities described in ARB_texture_float extension,
> and
> > -will discuss licensing on RAND terms, on an individual basis with
> > -companies wishing to use this IP in the context of conformant OpenGL
> > -implementations [2].
> > -
> > -The source code to implement ARB_texture_float extension is included
> > -and can be toggled on at compile time, for those who purchased a
> > -license from SGI, or are in a country where the patent does not
> apply,
> > -etc.
> > -
> > -The software is provided "as is", without warranty of any kind,
> express
> > -or implied, including but not limited to the warranties of
> > -merchantability, fitness for a particular purpose and
> noninfringement.
> > -In no event shall the authors or copyright holders be liable for any
> > -claim, damages or other liability, whether in an action of contract,
> > -tort or otherwise, arising from, out of or in connection with the
> > -software or the use or other dealings in the software.
> > -
> > -You should contact a lawyer or SGI's legal department if you want to
> > -enable this extension.
> > -
> > -
> > -[1] https://patents.google.com/patent/US6650327B1
> > -[2] https://www.opengl.org/registry/specs/ARB/texture_float.txt
> > diff --git a/meson.build b/meson.build
> > index 22e7a6d6cda..cd124c7bbe7 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -60,10 +60,6 @@ with_tools = get_option('tools')
> >  if with_tools.contains('all')
> >with_tools = ['freedreno', 'glsl', 'intel', 'nir', 'nouveau']
> >  endif
> > -if get_option('texture-float')
> > -  pre_args += '-DTEXTURE_FLOAT_ENABLED'
> > -  warning('Floating-point texture enabled. Please consult
> docs/patents.txt and your lawyer before building mesa.')
> > -endif
> >
> >  dri_drivers_path = get_option('dri-drivers-path')
> >  if dri_drivers_path == ''
> > diff --git a/meson_options.txt b/meson_options.txt
> > index bfe2290868f.

[Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

2018-06-25 Thread Jason Ekstrand
These two patches are fixes for call instructions that get the basemark
shaders to pass NIR validation.  Since the deref instruction stuff has
landed, these will have to go straight to stable without ever hitting
master.

Dylan, please merge to whatever place you merge stable things once they've
had review.

Cc: Dylan Baker 

Jason Ekstrand (2):
  nir: Handle call instructions in foreach_src
  nir/validate: Use the type from the tail of call parameter derefs

 src/compiler/nir/nir.c  | 17 -
 src/compiler/nir/nir_validate.c |  6 --
 2 files changed, 20 insertions(+), 3 deletions(-)

-- 
2.17.1

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


[Mesa-dev] [PATCH 1/2] nir: Handle call instructions in foreach_src

2018-06-25 Thread Jason Ekstrand
Even though they don't have regular sources, they do have derefs and
those may have implied sources that should be handled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980
---
 src/compiler/nir/nir.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 36a79f57ee5..baeb3490e67 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1373,6 +1373,20 @@ visit_tex_src(nir_tex_instr *instr, nir_foreach_src_cb 
cb, void *state)
return true;
 }
 
+static bool
+visit_call_src(nir_call_instr *instr, nir_foreach_src_cb cb, void *state)
+{
+   if (instr->return_deref && !visit_deref_src(instr->return_deref, cb, state))
+  return false;
+
+   for (unsigned i = 0; i < instr->num_params; i++) {
+  if (!visit_deref_src(instr->params[i], cb, state))
+ return false;
+   }
+
+   return true;
+}
+
 static bool
 visit_intrinsic_src(nir_intrinsic_instr *instr, nir_foreach_src_cb cb,
 void *state)
@@ -1449,7 +1463,8 @@ nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, 
void *state)
  return false;
   break;
case nir_instr_type_call:
-  /* Call instructions have no regular sources */
+  if (!visit_call_src(nir_instr_as_call(instr), cb, state))
+ return false;
   break;
case nir_instr_type_load_const:
   /* Constant load instructions have no regular sources */
-- 
2.17.1

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


[Mesa-dev] [PATCH 1/2] nir: Handle call instructions in foreach_src

2018-06-25 Thread Jason Ekstrand
Even though they don't have regular sources, they do have derefs and
those may have implied sources that should be handled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980
---
 src/compiler/nir/nir.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 36a79f57ee5..baeb3490e67 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1373,6 +1373,20 @@ visit_tex_src(nir_tex_instr *instr, nir_foreach_src_cb 
cb, void *state)
return true;
 }
 
+static bool
+visit_call_src(nir_call_instr *instr, nir_foreach_src_cb cb, void *state)
+{
+   if (instr->return_deref && !visit_deref_src(instr->return_deref, cb, state))
+  return false;
+
+   for (unsigned i = 0; i < instr->num_params; i++) {
+  if (!visit_deref_src(instr->params[i], cb, state))
+ return false;
+   }
+
+   return true;
+}
+
 static bool
 visit_intrinsic_src(nir_intrinsic_instr *instr, nir_foreach_src_cb cb,
 void *state)
@@ -1449,7 +1463,8 @@ nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, 
void *state)
  return false;
   break;
case nir_instr_type_call:
-  /* Call instructions have no regular sources */
+  if (!visit_call_src(nir_instr_as_call(instr), cb, state))
+ return false;
   break;
case nir_instr_type_load_const:
   /* Constant load instructions have no regular sources */
-- 
2.17.1

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


[Mesa-dev] [PATCH 2/2] nir/validate: Use the type from the tail of call parameter derefs

2018-06-25 Thread Jason Ekstrand
Otherwise, if what gets passed into the function call is a deref chain
longer than just a variable deref, we would use the type of the entire
variable rather than the type of the thing being dereferenced.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980
---
 src/compiler/nir/nir_validate.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index abfd1712b39..a5fec7dd2d9 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -559,14 +559,16 @@ validate_call_instr(nir_call_instr *instr, validate_state 
*state)
if (instr->return_deref == NULL) {
   validate_assert(state, glsl_type_is_void(instr->callee->return_type));
} else {
-  validate_assert(state, instr->return_deref->deref.type == 
instr->callee->return_type);
+  validate_assert(state, instr->callee->return_type ==
+ 
nir_deref_tail(&instr->return_deref->deref)->type);
   validate_deref_var(instr, instr->return_deref, state);
}
 
validate_assert(state, instr->num_params == instr->callee->num_params);
 
for (unsigned i = 0; i < instr->num_params; i++) {
-  validate_assert(state, instr->callee->params[i].type == 
instr->params[i]->deref.type);
+  validate_assert(state, instr->callee->params[i].type ==
+ nir_deref_tail(&instr->params[i]->deref)->type);
   validate_deref_var(instr, instr->params[i], state);
}
 }
-- 
2.17.1

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


[Mesa-dev] [PATCH 2/2] nir/validate: Use the type from the tail of call parameter derefs

2018-06-25 Thread Jason Ekstrand
Otherwise, if what gets passed into the function call is a deref chain
longer than just a variable deref, we would use the type of the entire
variable rather than the type of the thing being dereferenced.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980
---
 src/compiler/nir/nir_validate.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index abfd1712b39..a5fec7dd2d9 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -559,14 +559,16 @@ validate_call_instr(nir_call_instr *instr, validate_state 
*state)
if (instr->return_deref == NULL) {
   validate_assert(state, glsl_type_is_void(instr->callee->return_type));
} else {
-  validate_assert(state, instr->return_deref->deref.type == 
instr->callee->return_type);
+  validate_assert(state, instr->callee->return_type ==
+ 
nir_deref_tail(&instr->return_deref->deref)->type);
   validate_deref_var(instr, instr->return_deref, state);
}
 
validate_assert(state, instr->num_params == instr->callee->num_params);
 
for (unsigned i = 0; i < instr->num_params; i++) {
-  validate_assert(state, instr->callee->params[i].type == 
instr->params[i]->deref.type);
+  validate_assert(state, instr->callee->params[i].type ==
+ nir_deref_tail(&instr->params[i]->deref)->type);
   validate_deref_var(instr, instr->params[i], state);
}
 }
-- 
2.17.1

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


[Mesa-dev] [Bug 106980] Basemark GPU vulkan benchmark fails.

2018-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106980

--- Comment #5 from Jason Ekstrand  ---
I just sent two patches for stable which fix the validation issues.  Turns out
there's nothing wrong with spirv_to_nir, just the validator having issues. 
Sadly, that means the hang is likely real. :-(

-- 
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 v2 1/4] mesa: add header for share bptc decompress functions

2018-06-25 Thread Marek Olšák
This looks OK, but did you try to build other gallium state trackers?
They don't link with anything in src/mesa, so the build will fail,
because the bptc functions are missing. The solution used for other
formats was to put all functions into header files, see
texcompress_*_tmp.h. Another solution would be to move the functions
to src/util, which is shared by all Mesa components.

Also, all the function names (like compress_rgb_float) are too
generic. All non-static non-inline function names are global and
shouldn't conflict with anything else in Mesa, so they need to be more
unique. It's generally a good idea to make public inline function
names look unique to minimize name conflicts.

Marek



On Sat, Jun 23, 2018 at 9:19 AM, Denis Pauk  wrote:
> Make functions public:
> * fetch_rgba_unorm_from_block
> * fetch_rgb_float_from_block
> * compress_rgba_unorm
> * compress_rgb_float
>
> Create decompress functions:
> * decompress_rgba_unorm
> * decompress_rgb_float
>
> Functions will be reused in gallium/auxiliary code.
>
> v2: Add block decompress function
>
> Signed-off-by: Denis Pauk 
> CC: Marek Olšák 
> ---
>  src/mesa/Makefile.sources  |   1 +
>  src/mesa/main/texcompress_bptc.c   | 303 -
>  src/mesa/main/texcompress_bptc_share.h |  58 +
>  3 files changed, 358 insertions(+), 4 deletions(-)
>  create mode 100644 src/mesa/main/texcompress_bptc_share.h
>
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index 00aba0a2f7..d644112e6a 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -216,6 +216,7 @@ MAIN_FILES = \
> main/texcompress.c \
> main/texcompress_bptc.c \
> main/texcompress_bptc.h \
> +   main/texcompress_bptc_share.h \
> main/texcompress_cpal.c \
> main/texcompress_cpal.h \
> main/texcompress_etc.c \
> diff --git a/src/mesa/main/texcompress_bptc.c 
> b/src/mesa/main/texcompress_bptc.c
> index fd37be97f3..74828d63db 100644
> --- a/src/mesa/main/texcompress_bptc.c
> +++ b/src/mesa/main/texcompress_bptc.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include "texcompress.h"
>  #include "texcompress_bptc.h"
> +#include "texcompress_bptc_share.h"
>  #include "util/format_srgb.h"
>  #include "util/half_float.h"
>  #include "texstore.h"
> @@ -535,7 +536,7 @@ apply_rotation(int rotation,
> result[3] = t;
>  }
>
> -static void
> +void
>  fetch_rgba_unorm_from_block(const uint8_t *block,
>  uint8_t *result,
>  int texel)
> @@ -657,6 +658,173 @@ fetch_rgba_unorm_from_block(const uint8_t *block,
> apply_rotation(rotation, result);
>  }
>
> +static void
> +decompress_rgba_unorm_block(int src_width, int src_height,
> +const uint8_t *block,
> +uint8_t *dst_row, int dst_rowstride)
> +{
> +   int mode_num = ffs(block[0]);
> +   const struct bptc_unorm_mode *mode;
> +   int bit_offset, secondary_bit_offset;
> +   int partition_num;
> +   int subset_num;
> +   int rotation;
> +   int index_selection;
> +   int index_bits;
> +   int indices[2];
> +   int index;
> +   int anchors_before_texel;
> +   bool anchor;
> +   uint8_t endpoints[3 * 2][4];
> +   uint32_t subsets;
> +   int component;
> +   unsigned x, y;
> +
> +   if (mode_num == 0) {
> +  /* According to the spec this mode is reserved and shouldn't be used. 
> */
> +  for(y = 0; y < src_height; y += 1) {
> + uint8_t *result = dst_row;
> + memset(result, 0, 4 * src_width);
> + for(x = 0; x < src_width; x += 1) {
> +result[3] = 0xff;
> +result += 4;
> + }
> + dst_row += dst_rowstride;
> +  }
> +  return;
> +   }
> +
> +   mode = bptc_unorm_modes + mode_num - 1;
> +   bit_offset = mode_num;
> +
> +   partition_num = extract_bits(block, bit_offset, mode->n_partition_bits);
> +   bit_offset += mode->n_partition_bits;
> +
> +   switch (mode->n_subsets) {
> +   case 1:
> +  subsets = 0;
> +  break;
> +   case 2:
> +  subsets = partition_table1[partition_num];
> +  break;
> +   case 3:
> +  subsets = partition_table2[partition_num];
> +  break;
> +   default:
> +  assert(false);
> +  return;
> +   }
> +
> +   if (mode->has_rotation_bits) {
> +  rotation = extract_bits(block, bit_offset, 2);
> +  bit_offset += 2;
> +   } else {
> +  rotation = 0;
> +   }
> +
> +   if (mode->has_index_selection_bit) {
> +  index_selection = extract_bits(block, bit_offset, 1);
> +  bit_offset++;
> +   } else {
> +  index_selection = 0;
> +   }
> +
> +   bit_offset = extract_unorm_endpoints(mode, block, bit_offset, endpoints);
> +
> +   for(y = 0; y < src_height; y += 1) {
> +  uint8_t *result = dst_row;
> +  for(x = 0; x < src_width; x += 1) {
> + int texel;
> + texel = x + y * 4;
> +
> + anchors_before_texel = count_anchors_before_texel(mode->n_subsets,
> + 

Re: [Mesa-dev] [RESEND PATCH v5 0/3] egl/android: Add DRM node probing and filtering

2018-06-25 Thread Robert Foss

Pushed.

On 2018-06-25 13:39, Robert Foss wrote:

[RESEND] due to the previous version sent to the ML mistakenly being
v4 again. Please excuse the spam.

This series replaces the dependency on
GRALLOC_MODULE_PERFORM_GET_DRM_FD with DRM node
probing and disables the support for drm_gralloc.

The series has been tested on Qemu+AOSP, where a
virtio gpu was successfully probed for and
opened.

The current branch can be found here:
https://gitlab.collabora.com/robertfoss/mesa/tree/drm_probing_v5

Changes since v4:
  - Removed dead continue statement
  - Switched function argument to const char* from char*

Changes since v3:
  - Reduced number of probing return codes
  - Simplified driver vendor check in droid_probe_device()
  - Fixed type with ';' prepended to a if-statement
  - Removed a strlen call
  - Switched a sprintf to snprintf
  - Replaced fd == -1 check with < 0
  - Simplified switch+goto statements

Changes since v2:
  - Fixed whitespace issue
  - Diversified return codes from probing functions
  - Switched away from using drmGetDevices2, to iterating over
/dev/dir/renderD nodes manually

Changes since v1:
  - Added fix for build issue
  - Do not rely on libdrm for probing
  - Distinguish between errors and when no drm devices are found

Changes since RFC:
  - Rebased work on the libdrm patch [2].
  - Included patch from Rob Herring disabling drm_gralloc/flink
support by default.
  - Added device handler driver probing.


Rob Herring (1):
   egl/android: #ifdef out flink name support

Robert Foss (2):
   gallium/util: Fix build error due to cast to different size
   egl/android: Add DRM node probing and filtering

  src/egl/Android.mk|   6 +-
  src/egl/drivers/dri2/egl_dri2.h   |   2 -
  src/egl/drivers/dri2/platform_android.c   | 227 +++---
  .../auxiliary/util/u_debug_stack_android.cpp  |   4 +-
  4 files changed, 195 insertions(+), 44 deletions(-)


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


Re: [Mesa-dev] Testing drm_hwcomposer in RPi

2018-06-25 Thread Stefan Schake
Hey Chris,

On Fri, Jun 22, 2018 at 12:09 PM, chris simmonds  wrote:
> Hi.
>
> I would like to try out drm_hwcomposer on a RPi 3. Can anyone point me to a
> howto or something that tells me how?
>
> FYI, this is part of a side project to port drm_hwcomposer to BeagleBones
> and other things based on TI SoCs
>
> Thanks,
> Chris Simmonds

So Mesa is really only transitively related to drm_hwc, in that you need
a graphics driver with Android native fence support. For Mesa and the VC4
GPU on the RPi specifically, that's supported in a very recent Mesa version
in combination with a very recent kernel that has the VC4 syncobj support.
The earliest kernel version that has this is 4.18-rc1, but it can be
backported relatively painlessly to 4.14, which is what the android-kernel
tree uses and works on Oreo upwards. No released Mesa version has the
support yet, but master can be made to work with AOSP.

As you can tell, there is no howto or anything - this is all pretty
bleeding edge and you'll need to do some indepth sleuthing to get it
to work. If you hit any specific problems, the best point to get help
is the drm-hwcomposer project on the freedesktop gitlab:

https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer

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


[Mesa-dev] [PATCH 1/6] i965/vec4: Silence unused parameter warnings in vec4 compiler tests

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

src/intel/compiler/test_vec4_copy_propagation.cpp: In member function ‘virtual 
brw::dst_reg* copy_propagation_vec4_visitor::make_reg_for_system_value(int)’:
src/intel/compiler/test_vec4_copy_propagation.cpp:57:51: warning: unused 
parameter ‘location’ [-Wunused-parameter]
virtual dst_reg *make_reg_for_system_value(int location)
   ^~~~
src/intel/compiler/test_vec4_copy_propagation.cpp: In member function ‘virtual 
void copy_propagation_vec4_visitor::emit_urb_write_header(int)’:
src/intel/compiler/test_vec4_copy_propagation.cpp:77:43: warning: unused 
parameter ‘mrf’ [-Wunused-parameter]
virtual void emit_urb_write_header(int mrf)
   ^~~
src/intel/compiler/test_vec4_copy_propagation.cpp: In member function ‘virtual 
brw::vec4_instruction* 
copy_propagation_vec4_visitor::emit_urb_write_opcode(bool)’:
src/intel/compiler/test_vec4_copy_propagation.cpp:82:57: warning: unused 
parameter ‘complete’ [-Wunused-parameter]
virtual vec4_instruction *emit_urb_write_opcode(bool complete)
 ^~~~
src/intel/compiler/test_vec4_register_coalesce.cpp: In member function ‘virtual 
brw::dst_reg* register_coalesce_vec4_visitor::make_reg_for_system_value(int)’:
src/intel/compiler/test_vec4_register_coalesce.cpp:60:51: warning: unused 
parameter ‘location’ [-Wunused-parameter]
virtual dst_reg *make_reg_for_system_value(int location)
   ^~~~
src/intel/compiler/test_vec4_register_coalesce.cpp: In member function ‘virtual 
void register_coalesce_vec4_visitor::emit_urb_write_header(int)’:
src/intel/compiler/test_vec4_register_coalesce.cpp:80:43: warning: unused 
parameter ‘mrf’ [-Wunused-parameter]
virtual void emit_urb_write_header(int mrf)
   ^~~
src/intel/compiler/test_vec4_register_coalesce.cpp: In member function ‘virtual 
brw::vec4_instruction* 
register_coalesce_vec4_visitor::emit_urb_write_opcode(bool)’:
src/intel/compiler/test_vec4_register_coalesce.cpp:85:57: warning: unused 
parameter ‘complete’ [-Wunused-parameter]
virtual vec4_instruction *emit_urb_write_opcode(bool complete)
 ^~~~
src/intel/compiler/test_vec4_cmod_propagation.cpp: In member function ‘virtual 
brw::dst_reg* cmod_propagation_vec4_visitor::make_reg_for_system_value(int)’:
src/intel/compiler/test_vec4_cmod_propagation.cpp:60:51: warning: unused 
parameter ‘location’ [-Wunused-parameter]
virtual dst_reg *make_reg_for_system_value(int location)
   ^~~~
src/intel/compiler/test_vec4_cmod_propagation.cpp: In member function ‘virtual 
void cmod_propagation_vec4_visitor::emit_urb_write_header(int)’:
src/intel/compiler/test_vec4_cmod_propagation.cpp:85:43: warning: unused 
parameter ‘mrf’ [-Wunused-parameter]
virtual void emit_urb_write_header(int mrf)
   ^~~
src/intel/compiler/test_vec4_cmod_propagation.cpp: In member function ‘virtual 
brw::vec4_instruction* 
cmod_propagation_vec4_visitor::emit_urb_write_opcode(bool)’:
src/intel/compiler/test_vec4_cmod_propagation.cpp:90:57: warning: unused 
parameter ‘complete’ [-Wunused-parameter]
virtual vec4_instruction *emit_urb_write_opcode(bool complete)
 ^~~~

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/test_vec4_cmod_propagation.cpp  | 6 +++---
 src/intel/compiler/test_vec4_copy_propagation.cpp  | 6 +++---
 src/intel/compiler/test_vec4_register_coalesce.cpp | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/intel/compiler/test_vec4_cmod_propagation.cpp 
b/src/intel/compiler/test_vec4_cmod_propagation.cpp
index 7d9792b4a55..e27c937ecdc 100644
--- a/src/intel/compiler/test_vec4_cmod_propagation.cpp
+++ b/src/intel/compiler/test_vec4_cmod_propagation.cpp
@@ -57,7 +57,7 @@ public:
 
 protected:
/* Dummy implementation for pure virtual methods */
-   virtual dst_reg *make_reg_for_system_value(int location)
+   virtual dst_reg *make_reg_for_system_value(int /* location */)
{
   unreachable("Not reached");
}
@@ -82,12 +82,12 @@ protected:
   unreachable("Not reached");
}
 
-   virtual void emit_urb_write_header(int mrf)
+   virtual void emit_urb_write_header(int /* mrf */)
{
   unreachable("Not reached");
}
 
-   virtual vec4_instruction *emit_urb_write_opcode(bool complete)
+   virtual vec4_instruction *emit_urb_write_opcode(bool /* complete */)
{
   unreachable("Not reached");
}
diff --git a/src/intel/compiler/test_vec4_copy_propagation.cpp 
b/src/intel/compiler/test_vec4_copy_propagation.cpp
index f4f91d8c8c7..5f3f3e525f2 100644
--- a/src/intel/compiler/test_vec4_copy_propagation.cpp
+++ b/src/intel/compiler/test_vec4_copy_propagation.cpp

[Mesa-dev] [PATCH 2/6] i965/vec4/dce: Don't narrow the write mask if the flags are used

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

In an instruction sequence like

cmp(8).ge.f0.0 vgrf17:D, vgrf2.:D, vgrf9.:D
(+f0.0) sel(8) vgrf1:UD, vgrf8.xyzw:UD, vgrf1.xyzw:UD

The other fields of vgrf17 may be unused, but the CMP still needs to
generate the other flag bits.

To my surprise, nothing in shader-db or any test suite appears to hit
this.  However, I have a change to brw_vec4_cmod_propagation that
creates cases where this can happen.  This fix prevents a couple dozen
regressions in that patch.

Signed-off-by: Ian Romanick 
---
 src/intel/Makefile.compiler.am |   5 +
 .../compiler/brw_vec4_dead_code_eliminate.cpp  |  47 --
 src/intel/compiler/meson.build |   3 +-
 .../compiler/test_vec4_dead_code_eliminate.cpp | 163 +
 4 files changed, 208 insertions(+), 10 deletions(-)
 create mode 100644 src/intel/compiler/test_vec4_dead_code_eliminate.cpp

diff --git a/src/intel/Makefile.compiler.am b/src/intel/Makefile.compiler.am
index 46711fe71b7..2d66883f35a 100644
--- a/src/intel/Makefile.compiler.am
+++ b/src/intel/Makefile.compiler.am
@@ -64,6 +64,7 @@ COMPILER_TESTS = \
compiler/test_vf_float_conversions \
compiler/test_vec4_cmod_propagation \
compiler/test_vec4_copy_propagation \
+   compiler/test_vec4_dead_code_eliminate \
compiler/test_vec4_register_coalesce
 
 TESTS += $(COMPILER_TESTS)
@@ -97,6 +98,10 @@ compiler_test_vec4_cmod_propagation_SOURCES = \
compiler/test_vec4_cmod_propagation.cpp
 compiler_test_vec4_cmod_propagation_LDADD = $(TEST_LIBS)
 
+compiler_test_vec4_dead_code_eliminate_SOURCES = \
+   compiler/test_vec4_dead_code_eliminate.cpp
+compiler_test_vec4_dead_code_eliminate_LDADD = $(TEST_LIBS)
+
 # Strictly speaking this is neither a C++ test nor using gtest - we can address
 # address that at a later point. Until then, this allows us a to simplify 
things.
 compiler_test_eu_compact_SOURCES = \
diff --git a/src/intel/compiler/brw_vec4_dead_code_eliminate.cpp 
b/src/intel/compiler/brw_vec4_dead_code_eliminate.cpp
index c09a3d7ebe9..99e4c9cacaf 100644
--- a/src/intel/compiler/brw_vec4_dead_code_eliminate.cpp
+++ b/src/intel/compiler/brw_vec4_dead_code_eliminate.cpp
@@ -81,17 +81,46 @@ vec4_visitor::dead_code_eliminate()
result_live[3] = result;
 }
 
-for (int c = 0; c < 4; c++) {
-   if (!result_live[c] && inst->dst.writemask & (1 << c)) {
-  inst->dst.writemask &= ~(1 << c);
+if (inst->writes_flag()) {
+   /* Independently calculate the usage of the flag components and
+* the destination value components.
+*/
+   uint8_t flag_mask = inst->dst.writemask;
+   uint8_t dest_mask = inst->dst.writemask;
+
+   for (int c = 0; c < 4; c++) {
+  if (!result_live[c] && dest_mask & (1 << c))
+ dest_mask &= ~(1 << c);
+
+  if (!BITSET_TEST(flag_live, c))
+ flag_mask &= ~(1 << c);
+   }
+
+   if (inst->dst.writemask != (flag_mask | dest_mask)) {
   progress = true;
+  inst->dst.writemask = flag_mask | dest_mask;
+   }
 
-  if (inst->dst.writemask == 0) {
- if (inst->writes_accumulator || inst->writes_flag()) {
-inst->dst = dst_reg(retype(brw_null_reg(), 
inst->dst.type));
- } else {
-inst->opcode = BRW_OPCODE_NOP;
-break;
+   /* If none of the destination components are read, replace the
+* destination register with the NULL register.
+*/
+   if (dest_mask == 0) {
+  progress = true;
+  inst->dst = dst_reg(retype(brw_null_reg(), inst->dst.type));
+   }
+} else {
+   for (int c = 0; c < 4; c++) {
+  if (!result_live[c] && inst->dst.writemask & (1 << c)) {
+ inst->dst.writemask &= ~(1 << c);
+ progress = true;
+
+ if (inst->dst.writemask == 0) {
+if (inst->writes_accumulator) {
+   inst->dst = dst_reg(retype(brw_null_reg(), 
inst->dst.type));
+} else {
+   inst->opcode = BRW_OPCODE_NOP;
+   break;
+}
  }
   }
}
diff --git a/src/intel/compiler/meson.build b/src/intel/compiler/meson.build
index 72b7a6796cb..1ebc0cd2799 100644
--- a/src/intel/compiler/meson.build
+++ b/src/intel/compiler/meson.build
@@ -144,7 +144,8 @@ if with_tests
   foreach t : ['fs_cmod_propagation', 'fs_copy_propagation',
'fs_saturate_propagation', 'vf_float_conversions',
'v

[Mesa-dev] [PATCH 0/6] More cmod propagation and CSEL instructions

2018-06-25 Thread Ian Romanick
Patch series also available at:

https://cgit.freedesktop.org/~idr/mesa/log/?h=cmod-propagation-work

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


[Mesa-dev] [PATCH 3/6] i965/fs: Eliminate unary op on operand of compare-with-zero

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

All Gen7+ platforms had similar results. (Broadwell shown)
total instructions in shared programs: 14715715 -> 14715709 (<.01%)
instructions in affected programs: 474 -> 468 (-1.27%)
helped: 6
HURT: 0
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 1.12% max: 1.35% x̄: 1.28% x̃: 1.35%
95% mean confidence interval for instructions value: -1.00 -1.00
95% mean confidence interval for instructions %-change: -1.40% -1.15%
Instructions are helped.

total cycles in shared programs: 559569911 -> 559569809 (<.01%)
cycles in affected programs: 5963 -> 5861 (-1.71%)
helped: 6
HURT: 0
helped stats (abs) min: 16 max: 18 x̄: 17.00 x̃: 17
helped stats (rel) min: 1.45% max: 1.88% x̄: 1.73% x̃: 1.85%
95% mean confidence interval for cycles value: -18.15 -15.85
95% mean confidence interval for cycles %-change: -1.95% -1.51%
Cycles are helped.

Iron Lake and Sandy Bridge had similar results. (Iron Lake shown)
total instructions in shared programs: 7780915 -> 7780913 (<.01%)
instructions in affected programs: 246 -> 244 (-0.81%)
helped: 2
HURT: 0

total cycles in shared programs: 177876108 -> 177876106 (<.01%)
cycles in affected programs: 3636 -> 3634 (-0.06%)
helped: 1
HURT: 0

GM45
total instructions in shared programs: 4799152 -> 4799151 (<.01%)
instructions in affected programs: 126 -> 125 (-0.79%)
helped: 1
HURT: 0

total cycles in shared programs: 122052654 -> 122052652 (<.01%)
cycles in affected programs: 3640 -> 3638 (-0.05%)
helped: 1
HURT: 0

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs.cpp   | 19 ++-
 src/intel/compiler/brw_vec4.cpp | 12 
 2 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 5c95e260aad..a4086a8dd7f 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2359,6 +2359,16 @@ fs_visitor::opt_algebraic()
foreach_block_and_inst(block, fs_inst, inst, cfg) {
   switch (inst->opcode) {
   case BRW_OPCODE_MOV:
+ if ((inst->conditional_mod == BRW_CONDITIONAL_Z ||
+  inst->conditional_mod == BRW_CONDITIONAL_NZ) &&
+ inst->dst.is_null() &&
+ (inst->src[0].abs || inst->src[0].negate)) {
+inst->src[0].abs = false;
+inst->src[0].negate = false;
+progress = true;
+break;
+ }
+
  if (inst->src[0].file != IMM)
 break;
 
@@ -2454,13 +2464,12 @@ fs_visitor::opt_algebraic()
  }
  break;
   case BRW_OPCODE_CMP:
- if (inst->conditional_mod == BRW_CONDITIONAL_GE &&
- inst->src[0].abs &&
- inst->src[0].negate &&
- inst->src[1].is_zero()) {
+ if ((inst->conditional_mod == BRW_CONDITIONAL_Z ||
+  inst->conditional_mod == BRW_CONDITIONAL_NZ) &&
+ inst->src[1].is_zero() &&
+ (inst->src[0].abs || inst->src[0].negate)) {
 inst->src[0].abs = false;
 inst->src[0].negate = false;
-inst->conditional_mod = BRW_CONDITIONAL_Z;
 progress = true;
 break;
  }
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index d1c46d610d9..092007dc6ea 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -862,18 +862,6 @@ vec4_visitor::opt_algebraic()
 progress = true;
 }
 break;
-  case BRW_OPCODE_CMP:
- if (inst->conditional_mod == BRW_CONDITIONAL_GE &&
- inst->src[0].abs &&
- inst->src[0].negate &&
- inst->src[1].is_zero()) {
-inst->src[0].abs = false;
-inst->src[0].negate = false;
-inst->conditional_mod = BRW_CONDITIONAL_Z;
-progress = true;
-break;
- }
- break;
   case SHADER_OPCODE_BROADCAST:
  if (is_uniform(inst->src[0]) ||
  inst->src[1].is_zero()) {
-- 
2.14.4

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


[Mesa-dev] [PATCH 5/6] i965/fs: Allow Boolean conditions in CSEL generation

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

This can increase register pressure.  I think there may be some ways to
mitigate this, but that will take more work.

By percentage of instructions reduced, the most helped shader had a
block of code like:

cmp.z.f0(8) g51<1>D g21<8,8,1>D 1D
(+f0) sel(8)g23<1>UDg4.1<0,1,0>UD   g4<0,1,0>UD
cmp.z.f0(8) g24<1>D g21<8,8,1>D 2D
(+f0) sel(8)g25<1>UDg4.2<0,1,0>UD   g23<8,8,1>UD
cmp.z.f0(8) g26<1>D g21<8,8,1>D 3D
(+f0) sel(8)g17<1>UDg4.3<0,1,0>UD   g25<8,8,1>UD
cmp.nz.f0(8)null<1>Dg51<8,8,1>D 0D
(+f0) sel(8)g28<1>UDg4.5<0,1,0>UD   g4.4<0,1,0>UD
cmp.nz.f0(8)null<1>Dg24<8,8,1>D 0D
(+f0) sel(8)g29<1>UDg4.6<0,1,0>UD   g28<8,8,1>UD
cmp.nz.f0(8)null<1>Dg26<8,8,1>D 0D
(+f0) sel(8)g18<1>UDg4.7<0,1,0>UD   g29<8,8,1>UD
cmp.nz.f0(8)null<1>Dg51<8,8,1>D 0D
(+f0) sel(8)g31<1>UDg5.1<0,1,0>UD   g5<0,1,0>UD
cmp.nz.f0(8)null<1>Dg24<8,8,1>D 0D
(+f0) sel(8)g32<1>UDg5.2<0,1,0>UD   g31<8,8,1>UD
cmp.nz.f0(8)null<1>Dg26<8,8,1>D 0D
(+f0) sel(8)g19<1>UDg5.3<0,1,0>UD   g32<8,8,1>UD

All of the cmp.nz instructions could be eliminated by just moving the
selects.

Interestingly, this shader ends up looking like:

cmp.z.f0(8) g51<1>D g28<8,8,1>D 1D
(+f0) sel(8)g32<1>UDg4.1<0,1,0>UD   g4<0,1,0>UD
csel.nz(8)  g21<1>F g4.5<0,1,0>Fg4.4<0,1,0>Fg51<4,4,1>F
csel.nz(8)  g31<1>F g5.1<0,1,0>Fg5.0<0,1,0>Fg51<4,4,1>F
cmp.z.f0(8) g24<1>D g28<8,8,1>D 2D
(+f0) sel(8)g25<1>UDg4.2<0,1,0>UD   g32<8,8,1>UD
csel.nz(8)  g29<1>F g4.6<0,1,0>Fg21<4,4,1>F g24<4,4,1>F
csel.nz(8)  g23<1>F g5.2<0,1,0>Fg31<4,4,1>F g24<4,4,1>F
cmp.z.f0(8) g26<1>D g28<8,8,1>D 3D
(+f0) sel(8)g17<1>UDg4.3<0,1,0>UD   g25<8,8,1>UD
csel.nz(8)  g18<1>F g4.7<0,1,0>Fg29<4,4,1>F g26<4,4,1>F
csel.nz(8)  g19<1>F g5.3<0,1,0>Fg23<4,4,1>F g26<4,4,1>F

At this point, we may as well convert the CSELs back to regular SELs.

Broadwell and Skylake had similar results. (Skylake shown)
total instructions in shared programs: 14398211 -> 14395514 (-0.02%)
instructions in affected programs: 312588 -> 309891 (-0.86%)
helped: 1173
HURT: 1
helped stats (abs) min: 1 max: 66 x̄: 4.04 x̃: 3
helped stats (rel) min: 0.13% max: 13.95% x̄: 1.80% x̃: 1.36%
HURT stats (abs)   min: 2046 max: 2046 x̄: 2046.00 x̃: 2046
HURT stats (rel)   min: 33.71% max: 33.71% x̄: 33.71% x̃: 33.71%
95% mean confidence interval for instructions value: -5.73 1.14
95% mean confidence interval for instructions %-change: -1.87% -1.67%
Inconclusive result (value mean confidence interval includes 0).

total cycles in shared programs: 532959388 -> 532813589 (-0.03%)
cycles in affected programs: 4824963 -> 4679164 (-3.02%)
helped: 963
HURT: 175
helped stats (abs) min: 1 max: 18800 x̄: 175.14 x̃: 85
helped stats (rel) min: 0.02% max: 57.14% x̄: 7.96% x̃: 5.77%
HURT stats (abs)   min: 1 max: 13496 x̄: 130.63 x̃: 14
HURT stats (rel)   min: 0.05% max: 60.02% x̄: 2.82% x̃: 1.20%
95% mean confidence interval for cycles value: -178.35 -77.89
95% mean confidence interval for cycles %-change: -6.83% -5.77%
Cycles are helped.

total spills in shared programs: 8044 -> 8329 (3.54%)
spills in affected programs: 363 -> 648 (78.51%)
helped: 0
HURT: 1

total fills in shared programs: 10950 -> 11272 (2.94%)
fills in affected programs: 512 -> 834 (62.89%)
helped: 0
HURT: 1

LOST:   2
GAINED: 2

No changes on pre-Gen8 platforms because they all lack the CSEL
instruction.

Signed-off-by: Ian Romanick 
---

There is still quite a bit of potential future work here.

A lot of the cases that were helped by this were things like

cmp.z.f0 g51F g21F g20F
... lots of instructions
cmp.nz.f0nullDg51D 0D
(+f0) selg28UDg45UDg44UD

If this pattern is the only use of the result from the first compare, we
could convert this to

add.z.f0 g51F -g21Fg20F
... lots of instructions
csel.nz  g28F g45F g44F g51F

I also saw a number of cases like

and  g51D g21D 7D
...
cmp.nz.f0nullDg51D 0D
(+f0) selg28UDg45UDg44UD

This pass does not convert those to use CSEL, but, assuming we can
determine the denorm behavior, it seems like it could.

As alluded in the commit message, we may also want a pass the converts
CSEL instructions back into SEL instructions.  This may help with
register pressure.

 src/intel/compiler/brw_fs.cpp | 56 +++
 1 file changed, 51 insertions(+), 5 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index a4086a8dd7f..f683b4fd4d0 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/c

[Mesa-dev] [PATCH 4/6] i965/fs: Relax type matching rules in cmod propagation from MOV instructions

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

To allow cmod propagation from a MOV in a sequence like:

and(16) g31<1>UD   g20<8,8,1>UD   g22<8,8,1>UD
mov.nz.f0(16)   null<1>F   g31<8,8,1>D

A similar change to the vec4 backend had no effect.

The SIMD8 and SIMD16 shaders in two UE4 demos are helped.

All Gen7+ platforms had similar results. (Haswell shown)
total instructions in shared programs: 12973823 -> 12973791 (<.01%)
instructions in affected programs: 4487 -> 4455 (-0.71%)
helped: 20
HURT: 0
helped stats (abs) min: 1 max: 2 x̄: 1.60 x̃: 2
helped stats (rel) min: 0.30% max: 6.90% x̄: 1.57% x̃: 1.00%
95% mean confidence interval for instructions value: -1.84 -1.36
95% mean confidence interval for instructions %-change: -2.47% -0.68%
Instructions are helped.

total cycles in shared programs: 410348115 -> 410347641 (<.01%)
cycles in affected programs: 69104 -> 68630 (-0.69%)
helped: 16
HURT: 0
helped stats (abs) min: 6 max: 70 x̄: 29.62 x̃: 32
helped stats (rel) min: 0.15% max: 20.59% x̄: 2.99% x̃: 1.07%
95% mean confidence interval for cycles value: -38.61 -20.64
95% mean confidence interval for cycles %-change: -5.65% -0.34%
Cycles are helped.

Sandy Bridge
total instructions in shared programs: 10427842 -> 10427834 (<.01%)
instructions in affected programs: 2574 -> 2566 (-0.31%)
helped: 4
HURT: 0
helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
helped stats (rel) min: 0.28% max: 0.34% x̄: 0.31% x̃: 0.31%
95% mean confidence interval for instructions value: -2.00 -2.00
95% mean confidence interval for instructions %-change: -0.37% -0.26%
Instructions are helped.

total cycles in shared programs: 146154861 -> 146154725 (<.01%)
cycles in affected programs: 116854 -> 116718 (-0.12%)
helped: 4
HURT: 0
helped stats (abs) min: 32 max: 36 x̄: 34.00 x̃: 34
helped stats (rel) min: 0.12% max: 0.12% x̄: 0.12% x̃: 0.12%
95% mean confidence interval for cycles value: -37.67 -30.33
95% mean confidence interval for cycles %-change: -0.12% -0.11%
Cycles are helped.

No changes on Iron Lake or GM45.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs_cmod_propagation.cpp | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp 
b/src/intel/compiler/brw_fs_cmod_propagation.cpp
index 5b74f267359..17abcf05d8a 100644
--- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
+++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
@@ -248,10 +248,25 @@ opt_cmod_propagation_local(const gen_device_info 
*devinfo, bblock_t *block)
break;
 
 /* Comparisons operate differently for ints and floats */
-if (scan_inst->dst.type != inst->dst.type &&
-(scan_inst->dst.type == BRW_REGISTER_TYPE_F ||
- inst->dst.type == BRW_REGISTER_TYPE_F))
-   break;
+if (scan_inst->dst.type != inst->dst.type) {
+   /* We should propagate from a MOV to another instruction in a
+* sequence like:
+*
+*and(16) g31<1>UD   g20<8,8,1>UD   g22<8,8,1>UD
+*mov.nz.f0(16)   null<1>F   g31<8,8,1>D
+*/
+   if (inst->opcode == BRW_OPCODE_MOV) {
+  if ((inst->src[0].type != BRW_REGISTER_TYPE_D &&
+   inst->src[0].type != BRW_REGISTER_TYPE_UD) ||
+  (scan_inst->dst.type != BRW_REGISTER_TYPE_D &&
+   scan_inst->dst.type != BRW_REGISTER_TYPE_UD)) {
+ break;
+  }
+   } else if (scan_inst->dst.type == BRW_REGISTER_TYPE_F ||
+  inst->dst.type == BRW_REGISTER_TYPE_F) {
+  break;
+   }
+}
 
 /* If the instruction generating inst's source also wrote the
  * flag, and inst is doing a simple .nz comparison, then inst
-- 
2.14.4

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


[Mesa-dev] [PATCH 6/6] i965/vec4: Propagate conditional modifiers from more compares to other compares

2018-06-25 Thread Ian Romanick
From: Ian Romanick 

If there is a CMP.NZ that compares a single component (via a .
swizzle, for example) with 0, it can propagate its conditional modifier
back to a previous CMP that writes only that component.  The specific
case that I saw was:

cmp.l.f0(8) g42<1>.xF   g61<4>.xF   (abs)g18<4>.zF
...
cmp.nz.f0(8)null<1>Dg42<4>.xD   0D

In this case we can just delete the second CMP.

No changes on Broadwell or Skylake.  Also no changes on GM45 or Iron
Lake.

Sandy Bridge, Ivy Bridge, and Haswell had similar results. (Sandy Bridge shown)
total instructions in shared programs: 10427834 -> 10423577 (-0.04%)
instructions in affected programs: 226882 -> 222625 (-1.88%)
helped: 1305
HURT: 0
helped stats (abs) min: 1 max: 7 x̄: 3.26 x̃: 4
helped stats (rel) min: 0.11% max: 6.67% x̄: 1.94% x̃: 1.86%
95% mean confidence interval for instructions value: -3.37 -3.16
95% mean confidence interval for instructions %-change: -1.99% -1.89%
Instructions are helped.

total cycles in shared programs: 146154725 -> 146097503 (-0.04%)
cycles in affected programs: 2487836 -> 2430614 (-2.30%)
helped: 1098
HURT: 53
helped stats (abs) min: 2 max: 134 x̄: 52.27 x̃: 64
helped stats (rel) min: 0.12% max: 12.70% x̄: 3.46% x̃: 2.23%
HURT stats (abs)   min: 2 max: 16 x̄: 3.13 x̃: 2
HURT stats (rel)   min: 0.18% max: 0.83% x̄: 0.63% x̃: 0.71%
95% mean confidence interval for cycles value: -51.63 -47.80
95% mean confidence interval for cycles %-change: -3.44% -3.11%
Cycles are helped.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_vec4_cmod_propagation.cpp | 110 +--
 1 file changed, 104 insertions(+), 6 deletions(-)

diff --git a/src/intel/compiler/brw_vec4_cmod_propagation.cpp 
b/src/intel/compiler/brw_vec4_cmod_propagation.cpp
index 5205da4983c..9560cc3b6f7 100644
--- a/src/intel/compiler/brw_vec4_cmod_propagation.cpp
+++ b/src/intel/compiler/brw_vec4_cmod_propagation.cpp
@@ -36,7 +36,7 @@
 namespace brw {
 
 static bool
-opt_cmod_propagation_local(bblock_t *block)
+opt_cmod_propagation_local(bblock_t *block, vec4_visitor *v)
 {
bool progress = false;
int ip = block->end_ip + 1;
@@ -132,13 +132,111 @@ opt_cmod_propagation_local(bblock_t *block)
  scan_inst->dst, scan_inst->size_written)) {
 if ((scan_inst->predicate && scan_inst->opcode != BRW_OPCODE_SEL) 
||
 scan_inst->dst.offset != inst->src[0].offset ||
-(scan_inst->dst.writemask != WRITEMASK_X &&
+scan_inst->exec_size != inst->exec_size ||
+scan_inst->group != inst->group) {
+   break;
+}
+
+/* If scan_inst is a CMP that produces a single value and inst is
+ * a CMP.NZ that consumes only that value, remove inst.
+ */
+if (inst->conditional_mod == BRW_CONDITIONAL_NZ &&
+(inst->src[0].type == BRW_REGISTER_TYPE_D ||
+ inst->src[0].type == BRW_REGISTER_TYPE_UD) &&
+(inst->opcode == BRW_OPCODE_CMP ||
+ inst->opcode == BRW_OPCODE_MOV) &&
+scan_inst->opcode == BRW_OPCODE_CMP &&
+((inst->src[0].swizzle == BRW_SWIZZLE_ &&
+  scan_inst->dst.writemask == WRITEMASK_X) ||
+ (inst->src[0].swizzle == BRW_SWIZZLE_ &&
+  scan_inst->dst.writemask == WRITEMASK_Y) ||
+ (inst->src[0].swizzle == BRW_SWIZZLE_ &&
+  scan_inst->dst.writemask == WRITEMASK_Z) ||
+ (inst->src[0].swizzle == BRW_SWIZZLE_ &&
+  scan_inst->dst.writemask == WRITEMASK_W))) {
+   if (inst->dst.writemask != scan_inst->dst.writemask) {
+  src_reg temp(v, glsl_type::vec4_type, 1);
+
+  /* Given a sequence like:
+   *
+   *cmp.ge.f0(8)  g21<1>.xF  g20<4>.xF  g18<4>.xF
+   *...
+   *cmp.nz.f0(8)  null<1>D   g21<4>.xD  0D
+   *
+   * Replace it with something like:
+   *
+   *cmp.ge.f0(8)  g22<1>Fg20<4>.xF  g18<4>.xF
+   *mov(8)g21<1>.xF  g22<1>.F
+   *
+   * The added MOV will most likely be removed later.  In the
+   * worst case, it should be cheaper to schedule.
+   */
+  temp.swizzle = inst->src[0].swizzle;
+  temp.type = scan_inst->src[0].type;
+
+  vec4_instruction *mov = v->MOV(scan_inst->dst, temp);
+
+  /* Modify the source swizzles on scan_inst.  If scan_inst
+   * was
+   *
+   *cmp.ge.f0(8)  g21<1>.zF  g20<4>.wzyxF   
g18<4>.yxwzF
+   *
+   * replace it with
+   *
+

Re: [Mesa-dev] [PATCH 0/1] swr/rast: last swr formatting changes for a while

2018-06-25 Thread Eric Engestrom
On Friday, 2018-06-22 09:11:25 -0500, Alok Hota wrote:
> Sorry for the churn on these patches. They had to be split in three due
> to some code changes in between a mass formatting change. Anyway this
> patch contains only formatting changes for the files that were updated
> in the last patch

It's probably a good idea to commit the .clang-format so that everyone
else can format it correctly too. (separate patch of course)

> 
> Alok Hota (1):
>   swr/rast: Updating code style based on current clang-format rules
> 
>  .../swr/rasterizer/jitter/JitManager.cpp  | 133 ++--
>  .../swr/rasterizer/jitter/builder_gfx_mem.cpp |  90 +
>  .../swr/rasterizer/jitter/builder_gfx_mem.h   | 101 +-
>  .../jitter/functionpasses/lower_x86.cpp   | 189 +-
>  4 files changed, 260 insertions(+), 253 deletions(-)
> 
> -- 
> 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] nir: add lowering for gl_HelperInvocation

2018-06-25 Thread Ian Romanick
On 06/19/2018 08:24 AM, Rob Clark wrote:
> v2: reword comment about lower_helper_invocations to be more clear
> that it might not work on all hardware
> v3: add special variant of load_sample_id which does not imply per-
> sample shading
> 
> Signed-off-by: Rob Clark 
> ---
> Yeah, new intrinsic name is a bit funny sounding, but I couldn't
> think of anything better.
> 
>  src/compiler/nir/nir.h  | 12 
>  src/compiler/nir/nir_intrinsics.py  |  3 +++
>  src/compiler/nir/nir_lower_system_values.c  | 17 +
>  .../drivers/freedreno/ir3/ir3_compiler_nir.c|  1 +
>  src/gallium/drivers/freedreno/ir3/ir3_nir.c |  1 +
>  5 files changed, 34 insertions(+)
> 
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 2d620454796..cb9a4af64cf 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -1981,6 +1981,18 @@ typedef struct nir_shader_compiler_options {
>  */
> bool lower_base_vertex;
>  
> +   /**
> +* If enabled, gl_HelperInvocation will be lowered as:
> +*
> +*   !((1 << sample_id) & sample_mask_in))

I recently encountered something related to this.  Issue #22 of the
GL_ARB_shader_image_load_store spec suggests using (gl_SampleMaskIn[0]
== 0) to detect a helper invocation.  There's a note that
implementations that support > 32 samples will also need to check
gl_SampleMaskIn[1].  Did you try that?  It should generate less code.

See also piglit commit c89439fcaba7259b25d090df43a6bf2aac6483d7.

> +*
> +* This depends on some possibly hw implementation details, which may
> +* not be true for all hw.  In particular that the FS is only executed
> +* for covered samples or for helper invocations.  So, do not blindly
> +* enable this option.
> +*/
> +   bool lower_helper_invocation;
> +
> bool lower_cs_local_index_from_id;
>  
> bool lower_device_index_to_zero;
> diff --git a/src/compiler/nir/nir_intrinsics.py 
> b/src/compiler/nir/nir_intrinsics.py
> index 484b2d4fd68..5523243a564 100644
> --- a/src/compiler/nir/nir_intrinsics.py
> +++ b/src/compiler/nir/nir_intrinsics.py
> @@ -422,6 +422,9 @@ system_value("instance_id", 1)
>  system_value("base_instance", 1)
>  system_value("draw_id", 1)
>  system_value("sample_id", 1)
> +# sample_id_no_per_sample is like sample_id but does not imply per-
> +# sample shading.  See the lower_helper_invocation option.
> +system_value("sample_id_no_per_sample", 1)
>  system_value("sample_pos", 2)
>  system_value("sample_mask_in", 1)
>  system_value("primitive_id", 1)
> diff --git a/src/compiler/nir/nir_lower_system_values.c 
> b/src/compiler/nir/nir_lower_system_values.c
> index 487da042620..8c5fdbb1f54 100644
> --- a/src/compiler/nir/nir_lower_system_values.c
> +++ b/src/compiler/nir/nir_lower_system_values.c
> @@ -136,6 +136,23 @@ convert_block(nir_block *block, nir_builder *b)
>nir_load_first_vertex(b));
>   break;
>  
> +  case SYSTEM_VALUE_HELPER_INVOCATION:
> + if (b->shader->options->lower_helper_invocation) {
> +nir_ssa_def *tmp;
> +
> +tmp = nir_ishl(b,
> +   nir_imm_int(b, 1),
> +   nir_load_sample_id_no_per_sample(b));
> +
> +tmp = nir_iand(b,
> +   nir_load_sample_mask_in(b),
> +   tmp);
> +
> +sysval = nir_inot(b, nir_i2b(b, tmp));
> + }
> +
> + break;
> +
>case SYSTEM_VALUE_INSTANCE_INDEX:
>   sysval = nir_iadd(b,
> nir_load_instance_id(b),
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c 
> b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> index ed87eff9976..9cad7c6e559 100644
> --- a/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c
> @@ -2360,6 +2360,7 @@ emit_intrinsic(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
>   dst[0] = ctx->instance_id;
>   break;
>   case nir_intrinsic_load_sample_id:
> + case nir_intrinsic_load_sample_id_no_per_sample:
>   if (!ctx->samp_id) {
>   ctx->samp_id = create_input(b, 0);
>   ctx->samp_id->regs[0]->flags |= IR3_REG_HALF;
> diff --git a/src/gallium/drivers/freedreno/ir3/ir3_nir.c 
> b/src/gallium/drivers/freedreno/ir3/ir3_nir.c
> index 9ada3889eb9..e665fb933b9 100644
> --- a/src/gallium/drivers/freedreno/ir3/ir3_nir.c
> +++ b/src/gallium/drivers/freedreno/ir3/ir3_nir.c
> @@ -52,6 +52,7 @@ static const nir_shader_compiler_options options = {
>   .lower_extract_byte = true,
>   .lower_extract_word = true,
>   .lower_all_io_to_temps = true,
> + .lower_helper_invocation = true,
>  };
>  
>  struct nir_shader *
> 

___
mesa-dev mailing list
mesa-dev@

Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

2018-06-25 Thread Ilia Mirkin
On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick  wrote:
> On 06/19/2018 08:24 AM, Rob Clark wrote:
>> v2: reword comment about lower_helper_invocations to be more clear
>> that it might not work on all hardware
>> v3: add special variant of load_sample_id which does not imply per-
>> sample shading
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Yeah, new intrinsic name is a bit funny sounding, but I couldn't
>> think of anything better.
>>
>>  src/compiler/nir/nir.h  | 12 
>>  src/compiler/nir/nir_intrinsics.py  |  3 +++
>>  src/compiler/nir/nir_lower_system_values.c  | 17 +
>>  .../drivers/freedreno/ir3/ir3_compiler_nir.c|  1 +
>>  src/gallium/drivers/freedreno/ir3/ir3_nir.c |  1 +
>>  5 files changed, 34 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index 2d620454796..cb9a4af64cf 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -1981,6 +1981,18 @@ typedef struct nir_shader_compiler_options {
>>  */
>> bool lower_base_vertex;
>>
>> +   /**
>> +* If enabled, gl_HelperInvocation will be lowered as:
>> +*
>> +*   !((1 << sample_id) & sample_mask_in))
>
> I recently encountered something related to this.  Issue #22 of the
> GL_ARB_shader_image_load_store spec suggests using (gl_SampleMaskIn[0]
> == 0) to detect a helper invocation.  There's a note that
> implementations that support > 32 samples will also need to check
> gl_SampleMaskIn[1].  Did you try that?  It should generate less code.
>
> See also piglit commit c89439fcaba7259b25d090df43a6bf2aac6483d7.

Based on what I've seen of adreno, that sysval is likely actually not
gl_SampleMaskIn, but rather a full pixel coverage mask. This only
matters with sample-rate shading which I don't think Rob has
investigated yet.

I think gl_SampleMaskIn[0] == 0 should work in the general case, but I
suspect that freedreno will have to implement gl_SampleMaskIn as
covmask & (1 << sampleid) for sample-rate shading.

Cheers,

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


Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

2018-06-25 Thread Rob Clark
On Mon, Jun 25, 2018 at 2:29 PM, Ilia Mirkin  wrote:
> On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick  wrote:
>> On 06/19/2018 08:24 AM, Rob Clark wrote:
>>> v2: reword comment about lower_helper_invocations to be more clear
>>> that it might not work on all hardware
>>> v3: add special variant of load_sample_id which does not imply per-
>>> sample shading
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> Yeah, new intrinsic name is a bit funny sounding, but I couldn't
>>> think of anything better.
>>>
>>>  src/compiler/nir/nir.h  | 12 
>>>  src/compiler/nir/nir_intrinsics.py  |  3 +++
>>>  src/compiler/nir/nir_lower_system_values.c  | 17 +
>>>  .../drivers/freedreno/ir3/ir3_compiler_nir.c|  1 +
>>>  src/gallium/drivers/freedreno/ir3/ir3_nir.c |  1 +
>>>  5 files changed, 34 insertions(+)
>>>
>>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>>> index 2d620454796..cb9a4af64cf 100644
>>> --- a/src/compiler/nir/nir.h
>>> +++ b/src/compiler/nir/nir.h
>>> @@ -1981,6 +1981,18 @@ typedef struct nir_shader_compiler_options {
>>>  */
>>> bool lower_base_vertex;
>>>
>>> +   /**
>>> +* If enabled, gl_HelperInvocation will be lowered as:
>>> +*
>>> +*   !((1 << sample_id) & sample_mask_in))
>>
>> I recently encountered something related to this.  Issue #22 of the
>> GL_ARB_shader_image_load_store spec suggests using (gl_SampleMaskIn[0]
>> == 0) to detect a helper invocation.  There's a note that
>> implementations that support > 32 samples will also need to check
>> gl_SampleMaskIn[1].

note that for adreno I just have up to 4x samples.. in fact, do any
mesa drivers support > 32 samples?

>  Did you try that?  It should generate less code.
>>
>> See also piglit commit c89439fcaba7259b25d090df43a6bf2aac6483d7.
>
> Based on what I've seen of adreno, that sysval is likely actually not
> gl_SampleMaskIn, but rather a full pixel coverage mask. This only
> matters with sample-rate shading which I don't think Rob has
> investigated yet.
>
> I think gl_SampleMaskIn[0] == 0 should work in the general case, but I
> suspect that freedreno will have to implement gl_SampleMaskIn as
> covmask & (1 << sampleid) for sample-rate shading.
>

I didn't try that but I think gl_SampleMaskIn[0] will work as long as
there isn't sample-rate shading.  Blob always does 'covmask & (1 <<
sampleid)'.  But I guess as long as there isn't any GL state that can
also trigger sample-rate shading (?), I could switch lowering based on
whether shader reads sample_id, and use the simpler
gl_SampleMaskIn[0]==0 in the non-sample-rate case...

BR,
-R

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


Re: [Mesa-dev] [PATCH] nir: add lowering for gl_HelperInvocation

2018-06-25 Thread Ilia Mirkin
On Mon, Jun 25, 2018 at 2:38 PM, Rob Clark  wrote:
> On Mon, Jun 25, 2018 at 2:29 PM, Ilia Mirkin  wrote:
>> On Mon, Jun 25, 2018 at 2:23 PM, Ian Romanick  wrote:
>>> On 06/19/2018 08:24 AM, Rob Clark wrote:
 v2: reword comment about lower_helper_invocations to be more clear
 that it might not work on all hardware
 v3: add special variant of load_sample_id which does not imply per-
 sample shading

 Signed-off-by: Rob Clark 
 ---
 Yeah, new intrinsic name is a bit funny sounding, but I couldn't
 think of anything better.

  src/compiler/nir/nir.h  | 12 
  src/compiler/nir/nir_intrinsics.py  |  3 +++
  src/compiler/nir/nir_lower_system_values.c  | 17 +
  .../drivers/freedreno/ir3/ir3_compiler_nir.c|  1 +
  src/gallium/drivers/freedreno/ir3/ir3_nir.c |  1 +
  5 files changed, 34 insertions(+)

 diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
 index 2d620454796..cb9a4af64cf 100644
 --- a/src/compiler/nir/nir.h
 +++ b/src/compiler/nir/nir.h
 @@ -1981,6 +1981,18 @@ typedef struct nir_shader_compiler_options {
  */
 bool lower_base_vertex;

 +   /**
 +* If enabled, gl_HelperInvocation will be lowered as:
 +*
 +*   !((1 << sample_id) & sample_mask_in))
>>>
>>> I recently encountered something related to this.  Issue #22 of the
>>> GL_ARB_shader_image_load_store spec suggests using (gl_SampleMaskIn[0]
>>> == 0) to detect a helper invocation.  There's a note that
>>> implementations that support > 32 samples will also need to check
>>> gl_SampleMaskIn[1].
>
> note that for adreno I just have up to 4x samples.. in fact, do any
> mesa drivers support > 32 samples?
>
>>  Did you try that?  It should generate less code.
>>>
>>> See also piglit commit c89439fcaba7259b25d090df43a6bf2aac6483d7.
>>
>> Based on what I've seen of adreno, that sysval is likely actually not
>> gl_SampleMaskIn, but rather a full pixel coverage mask. This only
>> matters with sample-rate shading which I don't think Rob has
>> investigated yet.
>>
>> I think gl_SampleMaskIn[0] == 0 should work in the general case, but I
>> suspect that freedreno will have to implement gl_SampleMaskIn as
>> covmask & (1 << sampleid) for sample-rate shading.
>>
>
> I didn't try that but I think gl_SampleMaskIn[0] will work as long as
> there isn't sample-rate shading.  Blob always does 'covmask & (1 <<
> sampleid)'.  But I guess as long as there isn't any GL state that can
> also trigger sample-rate shading (?), I could switch lowering based on
> whether shader reads sample_id, and use the simpler
> gl_SampleMaskIn[0]==0 in the non-sample-rate case...

Reading gl_SampleID (or gl_SamplePosition) automatically triggers
sample-rate shading.

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


[Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

2018-06-25 Thread Nicholas Miell
FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved
into display lists or restored on glPopAttrib(GL_FOG_BIT).

Signed-off-by: Nicholas Miell 
---
 src/mesa/main/attrib.c | 4 
 src/mesa/main/dlist.c  | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index cbe93ab6faa..29d7089989e 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1177,6 +1177,10 @@ _mesa_PopAttrib(void)
_mesa_Fogf(GL_FOG_END, fog->End);
_mesa_Fogf(GL_FOG_INDEX, fog->Index);
_mesa_Fogi(GL_FOG_MODE, fog->Mode);
+   _mesa_Fogi(GL_FOG_COORD_SRC, fog->FogCoordinateSource);
+
+   if (ctx->Extensions.NV_fog_distance)
+ _mesa_Fogi(GL_FOG_DISTANCE_MODE_NV, fog->FogDistanceMode);
 }
 break;
  case GL_HINT_BIT:
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 4fc451000b5..8428791f9e8 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -2611,6 +2611,8 @@ save_Fogiv(GLenum pname, const GLint *params)
case GL_FOG_START:
case GL_FOG_END:
case GL_FOG_INDEX:
+   case GL_FOG_COORD_SRC:
+   case GL_FOG_DISTANCE_MODE_NV:
   p[0] = (GLfloat) *params;
   p[1] = 0.0f;
   p[2] = 0.0f;
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] mesa: Save and restore NV_fog_distance & FOG_COORD_SRC state

2018-06-25 Thread Ian Romanick
On 06/25/2018 11:53 AM, Nicholas Miell wrote:
> FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved
> into display lists or restored on glPopAttrib(GL_FOG_BIT).

Good catch.  How did you detect this?  Do we have any test cases?

> 
> Signed-off-by: Nicholas Miell 
> ---
>  src/mesa/main/attrib.c | 4 
>  src/mesa/main/dlist.c  | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
> index cbe93ab6faa..29d7089989e 100644
> --- a/src/mesa/main/attrib.c
> +++ b/src/mesa/main/attrib.c
> @@ -1177,6 +1177,10 @@ _mesa_PopAttrib(void)
> _mesa_Fogf(GL_FOG_END, fog->End);
> _mesa_Fogf(GL_FOG_INDEX, fog->Index);
> _mesa_Fogi(GL_FOG_MODE, fog->Mode);
> +   _mesa_Fogi(GL_FOG_COORD_SRC, fog->FogCoordinateSource);
> +
> +   if (ctx->Extensions.NV_fog_distance)
> + _mesa_Fogi(GL_FOG_DISTANCE_MODE_NV, fog->FogDistanceMode);

Presumably _mesa_PushAttrib already does the right thing?

>  }
>  break;
>   case GL_HINT_BIT:
> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
> index 4fc451000b5..8428791f9e8 100644
> --- a/src/mesa/main/dlist.c
> +++ b/src/mesa/main/dlist.c
> @@ -2611,6 +2611,8 @@ save_Fogiv(GLenum pname, const GLint *params)
> case GL_FOG_START:
> case GL_FOG_END:
> case GL_FOG_INDEX:
> +   case GL_FOG_COORD_SRC:
> +   case GL_FOG_DISTANCE_MODE_NV:
>p[0] = (GLfloat) *params;
>p[1] = 0.0f;
>p[2] = 0.0f;
> 

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


Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

2018-06-25 Thread Dylan Baker
Quoting Jason Ekstrand (2018-06-25 09:13:03)
> These two patches are fixes for call instructions that get the basemark
> shaders to pass NIR validation.  Since the deref instruction stuff has
> landed, these will have to go straight to stable without ever hitting
> master.
> 
> Dylan, please merge to whatever place you merge stable things once they've
> had review.

FYI, the best ways to ensure something get to stable are to (in order):

Add a Fixes: abcdef123456789 ("nir: do things")

Or, if your fixes don't fix a specific commit:

CC: "18.1" 

There are scripts that look over the master branch, and generate a list of
commits to pull into the stable branch based on that.

Dylan

> 
> Cc: Dylan Baker 
> 
> Jason Ekstrand (2):
>   nir: Handle call instructions in foreach_src
>   nir/validate: Use the type from the tail of call parameter derefs
> 
>  src/compiler/nir/nir.c  | 17 -
>  src/compiler/nir/nir_validate.c |  6 --
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 
> -- 
> 2.17.1
> 


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: Save and restore NV_fog_distance & FOG_COORD_SRC state

2018-06-25 Thread Nicholas Miell
On 06/25/2018 12:04 PM, Ian Romanick wrote:
> On 06/25/2018 11:53 AM, Nicholas Miell wrote:
>> FOG_DISTANCE_MODE_NV & FOG_COORD_SRC weren't getting saved
>> into display lists or restored on glPopAttrib(GL_FOG_BIT).
> 
> Good catch.  How did you detect this?  Do we have any test cases?
> 

I honestly don't remember, I've been sitting on this patch for years and
only dusted it off and updated it now that that there's an actual effort
to implement the 4.6 compat profile.

I think at some point I realized that my initial implementation of
NV_fog_distance was incomplete and at the same time I noticed that the
existing EXT_fog_coord implementation was broken in the same way.

Writing extension specs as a change list against the OpenGL spec is a
terrible way to convey information. The extensions adds entries to
tables, but don't mention that e.g. the table in question is the
comprehensive listing of all fog state or that elsewhere in the OpenGL
spec that table is referenced in the discussion of what must be saved by
PushAttrib.

>>
>> Signed-off-by: Nicholas Miell 
>> ---
>>  src/mesa/main/attrib.c | 4 
>>  src/mesa/main/dlist.c  | 2 ++
>>  2 files changed, 6 insertions(+)
>>
>> diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
>> index cbe93ab6faa..29d7089989e 100644
>> --- a/src/mesa/main/attrib.c
>> +++ b/src/mesa/main/attrib.c
>> @@ -1177,6 +1177,10 @@ _mesa_PopAttrib(void)
>> _mesa_Fogf(GL_FOG_END, fog->End);
>> _mesa_Fogf(GL_FOG_INDEX, fog->Index);
>> _mesa_Fogi(GL_FOG_MODE, fog->Mode);
>> +   _mesa_Fogi(GL_FOG_COORD_SRC, fog->FogCoordinateSource);
>> +
>> +   if (ctx->Extensions.NV_fog_distance)
>> + _mesa_Fogi(GL_FOG_DISTANCE_MODE_NV, fog->FogDistanceMode);
> 
> Presumably _mesa_PushAttrib already does the right thing?
> 

PushAttrib is just a memcpy of the gl_fog_attrib struct, so the
individual elements always get saved. Its only in PopAttrib where the
driver needs to be informed.

>>  }
>>  break;
>>   case GL_HINT_BIT:
>> diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
>> index 4fc451000b5..8428791f9e8 100644
>> --- a/src/mesa/main/dlist.c
>> +++ b/src/mesa/main/dlist.c
>> @@ -2611,6 +2611,8 @@ save_Fogiv(GLenum pname, const GLint *params)
>> case GL_FOG_START:
>> case GL_FOG_END:
>> case GL_FOG_INDEX:
>> +   case GL_FOG_COORD_SRC:
>> +   case GL_FOG_DISTANCE_MODE_NV:
>>p[0] = (GLfloat) *params;
>>p[1] = 0.0f;
>>p[2] = 0.0f;
>>
> 

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


Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

2018-06-25 Thread Jason Ekstrand

On June 25, 2018 12:09:50 Dylan Baker  wrote:


Quoting Jason Ekstrand (2018-06-25 09:13:03)

These two patches are fixes for call instructions that get the basemark
shaders to pass NIR validation.  Since the deref instruction stuff has
landed, these will have to go straight to stable without ever hitting
master.

Dylan, please merge to whatever place you merge stable things once they've
had review.


FYI, the best ways to ensure something get to stable are to (in order):

Add a Fixes: abcdef123456789 ("nir: do things")

Or, if your fixes don't fix a specific commit:

CC: "18.1" 

There are scripts that look over the master branch, and generate a list of
commits to pull into the stable branch based on that.


Above, I clearly stated that these patches will never hurt the master 
branch. They will need to go directly to stable.


--Jason




Dylan



Cc: Dylan Baker 

Jason Ekstrand (2):
nir: Handle call instructions in foreach_src
nir/validate: Use the type from the tail of call parameter derefs

src/compiler/nir/nir.c  | 17 -
src/compiler/nir/nir_validate.c |  6 --
2 files changed, 20 insertions(+), 3 deletions(-)

--
2.17.1




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


[Mesa-dev] Does Mesa have a policy for OpenGL token naming?

2018-06-25 Thread Nicholas Miell
When extensions get promoted into OpenGL itself, they keep the same
token names minus the _EXT or whatever postfix, which means grepping for
the tokens in the OpenGL specification will find the implementation in
the Mesa source even if it still uses the original token names from the
extension.

Unfortunately, the OpenGL spec also gratuitously renames tokens on
occasion, which means e.g. the OpenGL 4.6 compatability spec discussion
of what used to be the EXT_fog_coord extension uses a completely
different set of token names than what's found in the Mesa source.

OpenGL 1.5 renames several tokens, 2.0 does one, 3.0 does a few, 3.2
does one, 4.1 does one, 4.2 has a Changed Tokens section that is empty,
4.3 does one, and 4.4 fixes the 4.2 Changed Tokens section to list a few
but does none for itself. The 4.2 changes are particularly weird because
they introduce new renamed tokens for some contexts but also retain the
old tokens for other contexts.

Does Mesa have a policy of which version of the tokens should be used in
the source?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/2] Two stable fixes for call instructions

2018-06-25 Thread Dylan Baker
Quoting Jason Ekstrand (2018-06-25 12:36:39)
> On June 25, 2018 12:09:50 Dylan Baker  wrote:
> 
> > Quoting Jason Ekstrand (2018-06-25 09:13:03)
> >> These two patches are fixes for call instructions that get the basemark
> >> shaders to pass NIR validation.  Since the deref instruction stuff has
> >> landed, these will have to go straight to stable without ever hitting
> >> master.
> >>
> >> Dylan, please merge to whatever place you merge stable things once they've
> >> had review.
> >
> > FYI, the best ways to ensure something get to stable are to (in order):
> >
> > Add a Fixes: abcdef123456789 ("nir: do things")
> >
> > Or, if your fixes don't fix a specific commit:
> >
> > CC: "18.1" 
> >
> > There are scripts that look over the master branch, and generate a list of
> > commits to pull into the stable branch based on that.
> 
> Above, I clearly stated that these patches will never hurt the master 
> branch. They will need to go directly to stable.

Ah, sorry, I misread that.


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] travis: use https for all the links

2018-06-25 Thread Eric Engestrom
On Monday, 2018-06-25 11:03:04 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Signed-off-by: Emil Velikov 

Good idea :)

Reviewed-by: Eric Engestrom 

> ---
>  .travis.yml | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 012cc9139e0..903bd2dc8fc 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -9,9 +9,9 @@ cache:
>  
>  env:
>global:
> -- XORG_RELEASES=http://xorg.freedesktop.org/releases/individual
> -- XCB_RELEASES=http://xcb.freedesktop.org/dist
> -- WAYLAND_RELEASES=http://wayland.freedesktop.org/releases
> +- XORG_RELEASES=https://xorg.freedesktop.org/releases/individual
> +- XCB_RELEASES=https://xcb.freedesktop.org/dist
> +- WAYLAND_RELEASES=https://wayland.freedesktop.org/releases
>  - XORGMACROS_VERSION=util-macros-1.19.0
>  - GLPROTO_VERSION=glproto-1.4.17
>  - DRI2PROTO_VERSION=dri2proto-2.8
> @@ -541,7 +541,7 @@ install:
>tar -jxvf $LIBPCIACCESS_VERSION.tar.bz2
>(cd $LIBPCIACCESS_VERSION && ./configure --prefix=$HOME/prefix && make 
> install)
>  
> -  wget http://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
> +  wget https://dri.freedesktop.org/libdrm/$LIBDRM_VERSION.tar.bz2
>tar -jxvf $LIBDRM_VERSION.tar.bz2
>(cd $LIBDRM_VERSION && ./configure --prefix=$HOME/prefix --enable-vc4 
> --enable-freedreno --enable-etnaviv-experimental-api && make install)
>  
> @@ -557,11 +557,11 @@ install:
>tar -jxvf $LIBXSHMFENCE_VERSION.tar.bz2
>(cd $LIBXSHMFENCE_VERSION && ./configure --prefix=$HOME/prefix && make 
> install)
>  
> -  wget 
> http://people.freedesktop.org/~aplattner/vdpau/$LIBVDPAU_VERSION.tar.bz2
> +  wget 
> https://people.freedesktop.org/~aplattner/vdpau/$LIBVDPAU_VERSION.tar.bz2
>tar -jxvf $LIBVDPAU_VERSION.tar.bz2
>(cd $LIBVDPAU_VERSION && ./configure --prefix=$HOME/prefix && make 
> install)
>  
> -  wget 
> http://www.freedesktop.org/software/vaapi/releases/libva/$LIBVA_VERSION.tar.bz2
> +  wget 
> https://www.freedesktop.org/software/vaapi/releases/libva/$LIBVA_VERSION.tar.bz2
>tar -jxvf $LIBVA_VERSION.tar.bz2
>(cd $LIBVA_VERSION && ./configure --prefix=$HOME/prefix 
> --disable-wayland --disable-dummy-driver && make install)
>  
> -- 
> 2.17.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

2018-06-25 Thread Gert Wollny
Am Montag, den 25.06.2018, 17:36 +0200 schrieb Roland Scheidegger:
> I didn't actually get the original email for some reason, so can't
> comment inline as I'm just looking it up at patchwork...
> But the array offset stuff (the first patch) looks completely bogus
> to me, array textures do not support offsets for the array index, at
> least not in any shader language I know of.
It is legal to derive the texture array slice index from float value
and the formula given in the standard is "floor(z + 0.5)". 

The normal rounding mode doesn't handle this, probably because it
actually does "round-nearest-even to n.6 and drop fraction when point
sampling", so it doesn't really round to integers, but to some fixed
point format that then might get truncated. (It is not written what is
done if the TEX_Z_FILTER_NONE is set, but I assume it must be trunc
just like with TEX_Z_FILTER_POINT). When looking at the test results I
figured out that the slice selection must be off, and voila,  half of
the tests are fixed by adding 0.5 to the z-coordinate, be it by
injecting the code into the shader that adds this value to the
coordinate or by putting this value into the offsets. The first
approach is obviously cheaper, because it doesn't add any instruction.
I don't think that it is relevant whether the shader language supports
this, because in the end this gets translated to byte code that needs
to communicate the intent to the hardware.

> I'm not really sure about the 2nd patch, what exactly is the
> difference with the ordinary rounding and the new one? Is there just
> a difference for values exactly between 2 integers (e.g. 1.5 etc.)?
> In this case I would suspect the driver is allowed to pick either
> value and the test is bogus.
The remaining tests fail for an inaccuracy in the rounding mode (These
tests explicitly check rounding by varying the slice index from 1.4
to 1.50001). The default rounding mode that rounds to n.6 fixed point
can not capturere this accuracy, and therefore these tests fail. Using
trunc, which for positive values is equal to floor, fixes this, and
given that the standard is explicitely written to use floor, I don't
think that the tests are bogous. One could probably achieve the same in
the shader, but again, programming the sampler like this saves
instructions in the shader. 

> If that's not the case, it looks like it actually needs to be one
> patch?
> You're adding the 0.5 offset in one but adjust the sampler state
> which probably needs to match in another?
Well, it is two patches because that's how I went forward fixing these
tests (like described above), but it would probably okay to squash
them. I'll have to revise the first patch anyway.  

best, 
Gert

> Roland
> 
> Am 25.06.2018 um 07:54 schrieb Dave Airlie:
> > /home/airlied/devel/piglit/bin/textureGather fs nonconst r 0 float
> > 2DArray repeat
> > 
> > amongst others appears to regress with these two.
> > 
> > Dave.
> > 
> > 
> > On 22 June 2018 at 19:37, Gert Wollny 
> > wrote:
> > > these two patches correct the offets and the rounding modes for
> > > the
> > > index evaluation when accessing texture arrays. The patches were
> > > tested
> > > with the gles3 test suite where they fix a number of tests
> > > related to 2D
> > > texture arrays and didn't show any regressions.
> > > 
> > > Best,
> > > Gert
> > > 
> > > Gert Wollny (2):
> > >   r600: correct texture offset for array index lookup
> > >   r600: set rounding mode for texture array layer selection
> > > 
> > >  src/gallium/drivers/r600/evergreen_state.c | 21 ++
> > >  src/gallium/drivers/r600/r600_shader.c | 64
> > > +-
> > >  2 files changed, 84 insertions(+), 1 deletion(-)
> > > 
> > > --
> > > 2.16.4
> > > 
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > sts.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-
> > dev&data=02%7C01%7Csroland%40vmware.com%7C038ae632c8354209810c08d5d
> > a601219%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C1%7C63665502853319
> > 4684&sdata=gvQB0DNGvaNwBN5EHlJNrXED4biq3xC4rFqNEYqS3xs%3D&reserved=
> > 0
> > 
> 
> 

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


[Mesa-dev] [Bug 106595] [RADV] Rendering distortions only when MSAA is enabled

2018-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106595

--- Comment #19 from Philip Rebohle  ---
The DXVK bug causing the aspect mask to be 0 was introduced on June 12th and
was fixed a few days ago, but apparently the issue persists.

-- 
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 1/2] nouveau: Add basic memory object support

2018-06-25 Thread Miguel Angel Vico


On Fri, 22 Jun 2018 20:37:19 -0400
Ilia Mirkin  wrote:

> On Fri, Jun 22, 2018 at 8:22 PM, Miguel Angel Vico  
> wrote:
> >
> >
> > On Thu, 21 Jun 2018 22:09:14 -0400
> > Ilia Mirkin  wrote:
> >  
> >> Hi Miguel,
> >>
> >> Preface: I know little about this ext, so feel free to educate me on
> >> the wrongness of my thinking.
> >>
> >> On Thu, Jun 21, 2018 at 10:01 PM, Miguel A. Vico  
> >> wrote:  
> >> > Add memory object support for nvc0 and nv50
> >> >
> >> > Signed-off-by: Miguel A Vico Moya 
> >> > ---
> >> >  .../drivers/nouveau/nv50/nv50_miptree.c   | 49 +
> >> >  .../drivers/nouveau/nv50/nv50_resource.c  | 52 +++
> >> >  .../drivers/nouveau/nv50/nv50_resource.h  | 33 
> >> >  .../drivers/nouveau/nvc0/nvc0_resource.c  | 22 
> >> >  4 files changed, 146 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c 
> >> > b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> >> > index f2e304fde6..91007d3dac 100644
> >> > --- a/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> >> > +++ b/src/gallium/drivers/nouveau/nv50/nv50_miptree.c
> >> > @@ -397,13 +397,13 @@ nv50_miptree_create(struct pipe_screen *pscreen,
> >> > return pt;
> >> >  }
> >> >
> >> > -struct pipe_resource *
> >> > -nv50_miptree_from_handle(struct pipe_screen *pscreen,
> >> > - const struct pipe_resource *templ,
> >> > - struct winsys_handle *whandle)
> >> > +static struct pipe_resource *
> >> > +nv50_miptree_from_bo(struct pipe_screen *pscreen,
> >> > + const struct pipe_resource *templ,
> >> > + struct nouveau_bo *bo,
> >> > + uint32_t stride)
> >> >  {
> >> > struct nv50_miptree *mt;
> >> > -   unsigned stride;
> >> >
> >> > /* only supports 2D, non-mipmapped textures for the moment */  
> >>
> >> Won't this be a drag, since you're supposed to be able to "place" 3d
> >> textures, as well as mip-mapped ones?
> >>
> >> The reason I haven't looked at doing VK for nouveau yet is that the
> >> nouveau kernel API does not allow explicit userspace-side VA
> >> management, which would be required to allow something like this. I
> >> believe it would also be required to implement this GL extension. Feel
> >> free to correct my thinking.  
> >
> > My understanding is that EXT_external_objects itself only presents a
> > generic interface for applications to feed external memory handles to
> > OpenGL. It doesn't specify what properties those handles need to
> > satisfy, or whether the memory comes from user-space or any other
> > driver component. It is up for specific extensions to define new memory
> > objects, their properties, and how they can be imported/exported.
> >
> > As I understand it, the initial motivation for putting together this
> > extension was indeed Vulkan-OpenGL interoperability, but it is not
> > limited to that.
> >
> > This initial implementation of the extension adds the logic to allow
> > applications to feed opaque handles to OpenGL, but there's no API that
> > can create compatible opaque handles for the nouveau driver yet.
> >
> > Just to add a bit more context, here's a prototype of an extension
> > defining one of such handles:
> >
> >   
> > https://gitlab.freedesktop.org/mvicomoya/mesa/tree/wip/NVX_unix_allocator_import
> >
> > It is used by the the kmscube prototype that uses the generic allocator
> > to allocate buffers:
> >
> >   https://gitlab.freedesktop.org/allocator/kmscube/merge_requests/1
> >
> > And EXT_external_objects is just a pre-requisite for that.  
> 
> So by exposing GL_EXT_memory_object, the function
> glTexStorageMem3DEXT() becomes available. I don't think that will work
> with nouveau (without further changes), so the extension can't be
> exposed. Right?

Yes, exposing EXT_memory_object, several functions such as
glTexStorageMem3DEXT() become available, but they would not be usable at
all without at least one accompanying platform-specific extension that
defines how memory objects can be imported (e.g.
https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_objects_win32.txt),
am I correct?

In any case, we can keep the extension disabled by not applying patch
2/2 in this series, but maybe patch 1/2 is still good as a stepping
stone?

Thanks.

> 
> [I totally get that this is not your desired use-case, but we can't
> expose half-working extensions...]
> 
>   -ilia


-- 
Miguel


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


Re: [Mesa-dev] [PATCH 0/2] r600: Fix array texture slice index evaluation

2018-06-25 Thread Roland Scheidegger
Am 25.06.2018 um 22:13 schrieb Gert Wollny:
> Am Montag, den 25.06.2018, 17:36 +0200 schrieb Roland Scheidegger:
>> I didn't actually get the original email for some reason, so can't
>> comment inline as I'm just looking it up at patchwork...
>> But the array offset stuff (the first patch) looks completely bogus
>> to me, array textures do not support offsets for the array index, at
>> least not in any shader language I know of.
> It is legal to derive the texture array slice index from float value
> and the formula given in the standard is "floor(z + 0.5)". 
> 
> The normal rounding mode doesn't handle this, probably because it
> actually does "round-nearest-even to n.6 and drop fraction when point
> sampling", so it doesn't really round to integers, but to some fixed
> point format that then might get truncated. (It is not written what is
> done if the TEX_Z_FILTER_NONE is set, but I assume it must be trunc
> just like with TEX_Z_FILTER_POINT). When looking at the test results I
> figured out that the slice selection must be off, and voila,  half of
> the tests are fixed by adding 0.5 to the z-coordinate, be it by
> injecting the code into the shader that adds this value to the
> coordinate or by putting this value into the offsets. The first
> approach is obviously cheaper, because it doesn't add any instruction.
> I don't think that it is relevant whether the shader language supports
> this, because in the end this gets translated to byte code that needs
> to communicate the intent to the hardware.
Alright albeit you have logic to handle incoming z offsets, whereas that
should always be 0.
To be honest I'm actually kind of surprised the hw would honor texel
offsets for array coordinates (the term "texel offset" wouldn't even
apply) - this is done after denormalization and coord wrapping, neither
of which apply to the array coord.

Would be surprising if the hw did trunc instead of round (or
+0.5/floor), are you sure that's really (always) the case? I'm wondering
if there could be some (bogus) dependency on other texture/sampler state
(similar to the gather issues when selecting the wrong texels for int
textures).
At a quick glance radeonsi doesn't seem to do anything like this, and
generally I think the sampler hw shares most of the bugs, at least for
early gcn chips... (albeit I don't know if the tests would pass there
neither).

But anyway, if the hw really does trunc and not round for array slice
selection then that is the right thing to do indeed (a directed test
should easily reveal the switch-over points).


> 
>> I'm not really sure about the 2nd patch, what exactly is the
>> difference with the ordinary rounding and the new one? Is there just
>> a difference for values exactly between 2 integers (e.g. 1.5 etc.)?
>> In this case I would suspect the driver is allowed to pick either
>> value and the test is bogus.
> The remaining tests fail for an inaccuracy in the rounding mode (These
> tests explicitly check rounding by varying the slice index from 1.4
> to 1.50001). The default rounding mode that rounds to n.6 fixed point
> can not capturere this accuracy, and therefore these tests fail. Using
> trunc, which for positive values is equal to floor, fixes this, and
> given that the standard is explicitely written to use floor, I don't
> think that the tests are bogous. One could probably achieve the same in
> the shader, but again, programming the sampler like this saves
> instructions in the shader. 
> 
>> If that's not the case, it looks like it actually needs to be one
>> patch?
>> You're adding the 0.5 offset in one but adjust the sampler state
>> which probably needs to match in another?
> Well, it is two patches because that's how I went forward fixing these
> tests (like described above), but it would probably okay to squash
> them. I'll have to revise the first patch anyway.

I suppose I was misinterpreting what this does, I thought you needed to
add 0.5 because of using different Z_FILTER and TRUNC_COORD values, not
to fix another issue.

Although TRUNCATE_COORD would apply to all coords, which seems like a
bad idea (regardless what the hell those z_filter/truncate_coord values
actually do...). (Among other things, it would mean with point
filtering, you could actually get different texels selected depending if
you declared a texture as 2d or as 2d array with 1 layer - not good.)

Regardless the "bogus" test, that is simply based on GL not actually
requiring any specific precision in that area, therefore it's not
reasonable to expect 100% accurate (to float) results. That is, I think
it would be well allowed to round 1.4 to 2 there. So imho there's no
value in trying to fix this just to allow the test to pass.

Roland



> 
> best, 
> Gert
> 
>> Roland
>>
>> Am 25.06.2018 um 07:54 schrieb Dave Airlie:
>>> /home/airlied/devel/piglit/bin/textureGather fs nonconst r 0 float
>>> 2DArray repeat
>>>
>>> amongst others appears to regress with these two.
>>>
>>> Dave.
>>>
>>>
>>> On 22 Ju

Re: [Mesa-dev] Does Mesa have a policy for OpenGL token naming?

2018-06-25 Thread Ian Romanick
On 06/25/2018 12:41 PM, Nicholas Miell wrote:
> When extensions get promoted into OpenGL itself, they keep the same
> token names minus the _EXT or whatever postfix, which means grepping for
> the tokens in the OpenGL specification will find the implementation in
> the Mesa source even if it still uses the original token names from the
> extension.
> 
> Unfortunately, the OpenGL spec also gratuitously renames tokens on
> occasion, which means e.g. the OpenGL 4.6 compatability spec discussion
> of what used to be the EXT_fog_coord extension uses a completely
> different set of token names than what's found in the Mesa source.
> 
> OpenGL 1.5 renames several tokens, 2.0 does one, 3.0 does a few, 3.2
> does one, 4.1 does one, 4.2 has a Changed Tokens section that is empty,
> 4.3 does one, and 4.4 fixes the 4.2 Changed Tokens section to list a few
> but does none for itself. The 4.2 changes are particularly weird because
> they introduce new renamed tokens for some contexts but also retain the
> old tokens for other contexts.
> 
> Does Mesa have a policy of which version of the tokens should be used in
> the source?

Generally new code should be written to use the "current" spelling of
the name.  For the most part, we don't go back an rename things when
they change, but I do have a patch somewhere that removes the suffixes
from all the GL_EXT_framebuffer_object tokens...

Part of the reason we don't do mass renames is that it makes cherry
picking patches back to stable releases more annoying.  The renames
won't get cherry picked back, so any patches that come after a rename
may have extra conflicts.

> ___
> 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 0/2] Two stable fixes for call instructions

2018-06-25 Thread Ian Romanick
Series is

Reviewed-by: Ian Romanick 

On 06/25/2018 09:13 AM, Jason Ekstrand wrote:
> These two patches are fixes for call instructions that get the basemark
> shaders to pass NIR validation.  Since the deref instruction stuff has
> landed, these will have to go straight to stable without ever hitting
> master.
> 
> Dylan, please merge to whatever place you merge stable things once they've
> had review.
> 
> Cc: Dylan Baker 
> 
> Jason Ekstrand (2):
>   nir: Handle call instructions in foreach_src
>   nir/validate: Use the type from the tail of call parameter derefs
> 
>  src/compiler/nir/nir.c  | 17 -
>  src/compiler/nir/nir_validate.c |  6 --
>  2 files changed, 20 insertions(+), 3 deletions(-)
> 

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


Re: [Mesa-dev] [PATCH] Plumb invariant output attrib thru TGSI

2018-06-25 Thread Robert Tarasov
ping...

On Wed, Jun 20, 2018 at 5:55 PM, Robert Tarasov 
wrote:

> From: "Joe M. Kniss" 
>
> Add support for glsl 'invariant' modifier for output data declarations.
> Gallium drivers that use TGSI serialization currently loose invariant
> modifiers in glsl shaders.
>
> v2: use boolean for invariant instead of unsigned.
>
> Change-Id: Ieac8639116def45233513b6867a847cf7fda2f55
> Tested: chromiumos on qemu with virglrenderer.
> ---
>  src/gallium/auxiliary/tgsi/tgsi_strings.c  |  2 ++
>  src/gallium/auxiliary/tgsi/tgsi_strings.h  |  2 ++
>  src/gallium/auxiliary/tgsi/tgsi_text.c | 18 ++
>  src/gallium/auxiliary/tgsi/tgsi_ureg.c | 28 +++---
>  src/gallium/auxiliary/tgsi/tgsi_ureg.h |  4 +++-
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  8 +--
>  6 files changed, 46 insertions(+), 16 deletions(-)
>
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.c
> b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> index 4f28b49ce8a..434871273f2 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.c
> @@ -185,6 +185,8 @@ const char 
> *tgsi_interpolate_locations[TGSI_INTERPOLATE_LOC_COUNT]
> =
> "SAMPLE",
>  };
>
> +const char *tgsi_invariant_name = "INVARIANT";
> +
>  const char *tgsi_primitive_names[PIPE_PRIM_MAX] =
>  {
> "POINTS",
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_strings.h
> b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> index bb2d3458dde..20e3f7127f6 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_strings.h
> +++ b/src/gallium/auxiliary/tgsi/tgsi_strings.h
> @@ -52,6 +52,8 @@ extern const char *tgsi_interpolate_names[TGSI_
> INTERPOLATE_COUNT];
>
>  extern const char *tgsi_interpolate_locations[
> TGSI_INTERPOLATE_LOC_COUNT];
>
> +extern const char *tgsi_invariant_name;
> +
>  extern const char *tgsi_primitive_names[PIPE_PRIM_MAX];
>
>  extern const char *tgsi_fs_coord_origin_names[2];
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c
> b/src/gallium/auxiliary/tgsi/tgsi_text.c
> index 02241a66bfe..815b1ee65db 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_text.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c
> @@ -1586,10 +1586,6 @@ static boolean parse_declaration( struct
> translate_ctx *ctx )
>  break;
>   }
>}
> -  if (i == TGSI_INTERPOLATE_COUNT) {
> - report_error( ctx, "Expected semantic or interpolate attribute"
> );
> - return FALSE;
> -  }
> }
>
> cur = ctx->cur;
> @@ -1609,6 +1605,20 @@ static boolean parse_declaration( struct
> translate_ctx *ctx )
>}
> }
>
> +   cur = ctx->cur;
> +   eat_opt_white( &cur );
> +   if (*cur == ',' && !is_vs_input) {
> +  cur++;
> +  eat_opt_white( &cur );
> +  if (str_match_nocase_whole( &cur, tgsi_invariant_name )) {
> + decl.Declaration.Invariant = 1;
> + ctx->cur = cur;
> +  } else {
> + report_error( ctx, "Expected semantic, interpolate attribute, or
> invariant ");
> + return FALSE;
> +  }
> +   }
> +
> advance = tgsi_build_full_declaration(
>&decl,
>ctx->tokens_cur,
> diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> index 7d2b9af140d..f1bebe1e155 100644
> --- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> +++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
> @@ -140,6 +140,7 @@ struct ureg_program
>unsigned first;
>unsigned last;
>unsigned array_id;
> +  boolean invariant;
> } output[UREG_MAX_OUTPUT];
> unsigned nr_outputs, nr_output_regs;
>
> @@ -427,7 +428,8 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>  unsigned index,
>  unsigned usage_mask,
>  unsigned array_id,
> -unsigned array_size)
> +unsigned array_size,
> +boolean invariant)
>  {
> unsigned i;
>
> @@ -455,6 +457,7 @@ ureg_DECL_output_layout(struct ureg_program *ureg,
>ureg->output[i].first = index;
>ureg->output[i].last = index + array_size - 1;
>ureg->output[i].array_id = array_id;
> +  ureg->output[i].invariant = invariant;
>ureg->nr_output_regs = MAX2(ureg->nr_output_regs, index +
> array_size);
>ureg->nr_outputs++;
> }
> @@ -480,7 +483,8 @@ ureg_DECL_output_masked(struct ureg_program *ureg,
>  unsigned array_size)
>  {
> return ureg_DECL_output_layout(ureg, name, index, 0,
> -  ureg->nr_output_regs, usage_mask,
> array_id, array_size);
> +  ureg->nr_output_regs, usage_mask,
> array_id,
> +  array_size, FALSE);
>  }
>
>
> @@ -1512,7 +1516,8 @@ emit_decl_semantic(struct ureg_program *ureg,
> unsigned semantic_index,
> unsigned streams,
> unsigned usage_mask,
> -   unsigned ar

[Mesa-dev] [PATCH] nir/opt_if: Remove unneeded phis if we make progress

2018-06-25 Thread Jason Ekstrand
Now that SSA values can be derefs and they have special rules, we have
to be a bit more careful about our LCSSA phis.  In particular, we need
to clean up in case LCSSA ended up creating a phi node for a deref.
This fixes validation issues with some Vulkan CTS tests with the new
deref instructions.

Cc: Samuel Iglesias Gonsálvez 
---
 src/compiler/nir/nir.h | 1 +
 src/compiler/nir/nir_opt_if.c  | 7 +++
 src/compiler/nir/nir_opt_remove_phis.c | 6 +++---
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index be7b92dd7d2..c16ce547642 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2903,6 +2903,7 @@ bool nir_opt_move_load_ubo(nir_shader *shader);
 
 bool nir_opt_peephole_select(nir_shader *shader, unsigned limit);
 
+bool nir_opt_remove_phis_impl(nir_function_impl *impl);
 bool nir_opt_remove_phis(nir_shader *shader);
 
 bool nir_opt_shrink_load(nir_shader *shader);
diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 863ca630fbd..ec5bf1c9027 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -403,6 +403,13 @@ nir_opt_if(nir_shader *shader)
   * that don't dominate their uses.
   */
  nir_lower_regs_to_ssa_impl(function->impl);
+
+ /* Calling nir_convert_loop_to_lcssa() in opt_peel_loop_initial_if()
+  * adds extra phi nodes which may not be valid if they're used for
+  * something such as a deref.  Remove any unneeded phis.
+  */
+ nir_opt_remove_phis_impl(function->impl);
+
  progress = true;
   }
}
diff --git a/src/compiler/nir/nir_opt_remove_phis.c 
b/src/compiler/nir/nir_opt_remove_phis.c
index b20ff729156..e2d3994c49e 100644
--- a/src/compiler/nir/nir_opt_remove_phis.c
+++ b/src/compiler/nir/nir_opt_remove_phis.c
@@ -139,8 +139,8 @@ remove_phis_block(nir_block *block, nir_builder *b)
return progress;
 }
 
-static bool
-remove_phis_impl(nir_function_impl *impl)
+bool
+nir_opt_remove_phis_impl(nir_function_impl *impl)
 {
bool progress = false;
nir_builder bld;
@@ -165,7 +165,7 @@ nir_opt_remove_phis(nir_shader *shader)
 
nir_foreach_function(function, shader)
   if (function->impl)
- progress = remove_phis_impl(function->impl) || progress;
+ progress = nir_opt_remove_phis_impl(function->impl) || progress;
 
return progress;
 }
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

2018-06-25 Thread Dieter Nützel

Hello Marek,

after this series landed I get this:

Making all in targets/pipe-loader
make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird 
betreten

  CXXLDpipe_r600.la
../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_surface.o): 
In function `radeon_winsys_surface_init':
/opt/mesa/src/gallium/winsys/radeon/drm/radeon_drm_surface.c:307: 
undefined reference to `ac_compute_cmask'

collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:970: pipe_r600.la] Fehler 1

Didn't have more time for digging, yet.

Dieter

Am 23.06.2018 00:31, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c  | 30 +--
 src/gallium/drivers/radeonsi/si_shader.h  |  1 -
 .../drivers/radeonsi/si_shader_internal.h |  3 --
 .../drivers/radeonsi/si_state_shaders.c   |  7 +++--
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index e7e2a12a7b0..677853af60b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5047,22 +5047,21 @@ static void create_function(struct
si_shader_context *ctx)
break;
default:
assert(0 && "unimplemented shader");
return;
}

si_create_function(ctx, "main", returns, num_returns, &fninfo,
   si_get_max_workgroup_size(shader));

 	/* Reserve register locations for VGPR inputs the PS prolog may need. 
*/

-   if (ctx->type == PIPE_SHADER_FRAGMENT &&
-   ctx->separate_prolog) {
+	if (ctx->type == PIPE_SHADER_FRAGMENT && !ctx->shader->is_monolithic) 
{

ac_llvm_add_target_dep_function_attr(ctx->main_fn,
 "InitialPSInputAddr",
 
S_0286D0_PERSP_SAMPLE_ENA(1) |
 
S_0286D0_PERSP_CENTER_ENA(1) |
 
S_0286D0_PERSP_CENTROID_ENA(1) |
 
S_0286D0_LINEAR_SAMPLE_ENA(1) |
 
S_0286D0_LINEAR_CENTER_ENA(1) |
 
S_0286D0_LINEAR_CENTROID_ENA(1) |
 S_0286D0_FRONT_FACE_ENA(1) 
|
 S_0286D0_ANCILLARY_ENA(1) |
@@ -6049,22 +6048,21 @@ static void si_init_exec_from_input(struct
si_shader_context *ctx,
 }

 static bool si_vs_needs_prolog(const struct si_shader_selector *sel,
   const struct si_vs_prolog_bits *key)
 {
 	/* VGPR initialization fixup for Vega10 and Raven is always done in 
the

 * VS prolog. */
return sel->vs_needs_prolog || key->ls_vgpr_fix;
 }

-static bool si_compile_tgsi_main(struct si_shader_context *ctx,
-bool is_monolithic)
+static bool si_compile_tgsi_main(struct si_shader_context *ctx)
 {
struct si_shader *shader = ctx->shader;
struct si_shader_selector *sel = shader->selector;
struct lp_build_tgsi_context *bld_base = &ctx->bld_base;

// TODO clean all this up!
switch (ctx->type) {
case PIPE_SHADER_VERTEX:
ctx->load_input = declare_input_vs;
if (shader->key.as_ls)
@@ -6135,31 +6133,31 @@ static bool si_compile_tgsi_main(struct
si_shader_context *ctx,
 * - Add a barrier before the second shader.
 * - In the second shader, reset EXEC to ~0 and wrap the main part in
 *   an if-statement. This is required for correctness in geometry
 *   shaders, to ensure that empty GS waves do not send GS_EMIT and
 *   GS_CUT messages.
 *
 * For monolithic merged shaders, the first shader is wrapped in an
 * if-block together with its prolog in si_build_wrapper_function.
 */
if (ctx->screen->info.chip_class >= GFX9) {
-   if (!is_monolithic &&
+   if (!shader->is_monolithic &&
sel->info.num_instructions > 1 && /* not empty shader */
(shader->key.as_es || shader->key.as_ls) &&
(ctx->type == PIPE_SHADER_TESS_EVAL ||
 (ctx->type == PIPE_SHADER_VERTEX &&
  !si_vs_needs_prolog(sel, &shader->key.part.vs.prolog {
si_init_exec_from_input(ctx,
ctx->param_merged_wave_info, 0);
} else if (ctx->type == PIPE_SHADER_TESS_CTRL ||
   ctx->type == PIPE_SHADER_GEOMETRY) {
-   if (!is_monolithic)
+   if (!shader->is_monolithic)
ac_init_exec_full_mask(&ctx->ac);

   

Re: [Mesa-dev] [PATCH 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

2018-06-25 Thread Dieter Nützel

If I disable 'r600' all is fine, but...
--with-gallium-drivers=radeonsi,swrast

--with-gallium-drivers=r600,radeonsi,swrast
Worked before OK.

Dieter

Am 26.06.2018 01:51, schrieb Dieter Nützel:

Hello Marek,

after this series landed I get this:

Making all in targets/pipe-loader
make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird 
betreten

  CXXLDpipe_r600.la
../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_surface.o):
In function `radeon_winsys_surface_init':
/opt/mesa/src/gallium/winsys/radeon/drm/radeon_drm_surface.c:307:
undefined reference to `ac_compute_cmask'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:970: pipe_r600.la] Fehler 1

Didn't have more time for digging, yet.

Dieter

Am 23.06.2018 00:31, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c  | 30 
+--

 src/gallium/drivers/radeonsi/si_shader.h  |  1 -
 .../drivers/radeonsi/si_shader_internal.h |  3 --
 .../drivers/radeonsi/si_state_shaders.c   |  7 +++--
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index e7e2a12a7b0..677853af60b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5047,22 +5047,21 @@ static void create_function(struct
si_shader_context *ctx)
break;
default:
assert(0 && "unimplemented shader");
return;
}

si_create_function(ctx, "main", returns, num_returns, &fninfo,
   si_get_max_workgroup_size(shader));

 	/* Reserve register locations for VGPR inputs the PS prolog may 
need. */

-   if (ctx->type == PIPE_SHADER_FRAGMENT &&
-   ctx->separate_prolog) {
+	if (ctx->type == PIPE_SHADER_FRAGMENT && 
!ctx->shader->is_monolithic) {

ac_llvm_add_target_dep_function_attr(ctx->main_fn,
 "InitialPSInputAddr",
 
S_0286D0_PERSP_SAMPLE_ENA(1) |
 
S_0286D0_PERSP_CENTER_ENA(1) |
 
S_0286D0_PERSP_CENTROID_ENA(1) |
 
S_0286D0_LINEAR_SAMPLE_ENA(1) |
 
S_0286D0_LINEAR_CENTER_ENA(1) |
 
S_0286D0_LINEAR_CENTROID_ENA(1) |
 S_0286D0_FRONT_FACE_ENA(1) 
|
 S_0286D0_ANCILLARY_ENA(1) |
@@ -6049,22 +6048,21 @@ static void si_init_exec_from_input(struct
si_shader_context *ctx,
 }

 static bool si_vs_needs_prolog(const struct si_shader_selector *sel,
   const struct si_vs_prolog_bits *key)
 {
 	/* VGPR initialization fixup for Vega10 and Raven is always done in 
the

 * VS prolog. */
return sel->vs_needs_prolog || key->ls_vgpr_fix;
 }

-static bool si_compile_tgsi_main(struct si_shader_context *ctx,
-bool is_monolithic)
+static bool si_compile_tgsi_main(struct si_shader_context *ctx)
 {
struct si_shader *shader = ctx->shader;
struct si_shader_selector *sel = shader->selector;
struct lp_build_tgsi_context *bld_base = &ctx->bld_base;

// TODO clean all this up!
switch (ctx->type) {
case PIPE_SHADER_VERTEX:
ctx->load_input = declare_input_vs;
if (shader->key.as_ls)
@@ -6135,31 +6133,31 @@ static bool si_compile_tgsi_main(struct
si_shader_context *ctx,
 * - Add a barrier before the second shader.
 	 * - In the second shader, reset EXEC to ~0 and wrap the main part 
in

 *   an if-statement. This is required for correctness in geometry
 *   shaders, to ensure that empty GS waves do not send GS_EMIT and
 *   GS_CUT messages.
 *
 * For monolithic merged shaders, the first shader is wrapped in an
 * if-block together with its prolog in si_build_wrapper_function.
 */
if (ctx->screen->info.chip_class >= GFX9) {
-   if (!is_monolithic &&
+   if (!shader->is_monolithic &&
sel->info.num_instructions > 1 && /* not empty shader */
(shader->key.as_es || shader->key.as_ls) &&
(ctx->type == PIPE_SHADER_TESS_EVAL ||
 (ctx->type == PIPE_SHADER_VERTEX &&
  !si_vs_needs_prolog(sel, &shader->key.part.vs.prolog {
si_init_exec_from_input(ctx,
ctx->param_merged_wave_info, 0);
} else if (ctx->type == PIPE_SHADER_TESS_CTRL ||
   ctx->type == PIP

[Mesa-dev] [Bug 105699] s3tc fbo-generatemipmap-formats tests fail unless optimized

2018-06-25 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105699

Mark Janes  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Mark Janes  ---
I can't repro this anymore either.

-- 
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 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

2018-06-25 Thread Timothy Arceri

On 26/06/18 09:51, Dieter Nützel wrote:

Hello Marek,

after this series landed I get this:

Making all in targets/pipe-loader
make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird 
betreten

   CXXLD    pipe_r600.la
../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_surface.o): 
In function `radeon_winsys_surface_init':
/opt/mesa/src/gallium/winsys/radeon/drm/radeon_drm_surface.c:307: 
undefined reference to `ac_compute_cmask'

collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:970: pipe_r600.la] Fehler 1

Didn't have more time for digging, yet.


r600 probably doesn't get linked to the amd common (ac) code that is 
normally just shared between radv and radeonsi.




Dieter

Am 23.06.2018 00:31, schrieb Marek Olšák:

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/si_shader.c  | 30 +--
 src/gallium/drivers/radeonsi/si_shader.h  |  1 -
 .../drivers/radeonsi/si_shader_internal.h |  3 --
 .../drivers/radeonsi/si_state_shaders.c   |  7 +++--
 4 files changed, 18 insertions(+), 23 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index e7e2a12a7b0..677853af60b 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -5047,22 +5047,21 @@ static void create_function(struct
si_shader_context *ctx)
 break;
 default:
 assert(0 && "unimplemented shader");
 return;
 }

 si_create_function(ctx, "main", returns, num_returns, &fninfo,
    si_get_max_workgroup_size(shader));

 /* Reserve register locations for VGPR inputs the PS prolog may 
need. */

-    if (ctx->type == PIPE_SHADER_FRAGMENT &&
-    ctx->separate_prolog) {
+    if (ctx->type == PIPE_SHADER_FRAGMENT && 
!ctx->shader->is_monolithic) {

 ac_llvm_add_target_dep_function_attr(ctx->main_fn,
  "InitialPSInputAddr",
  S_0286D0_PERSP_SAMPLE_ENA(1) |
  S_0286D0_PERSP_CENTER_ENA(1) |
  S_0286D0_PERSP_CENTROID_ENA(1) |
  S_0286D0_LINEAR_SAMPLE_ENA(1) |
  S_0286D0_LINEAR_CENTER_ENA(1) |
  S_0286D0_LINEAR_CENTROID_ENA(1) |
  S_0286D0_FRONT_FACE_ENA(1) |
  S_0286D0_ANCILLARY_ENA(1) |
@@ -6049,22 +6048,21 @@ static void si_init_exec_from_input(struct
si_shader_context *ctx,
 }

 static bool si_vs_needs_prolog(const struct si_shader_selector *sel,
    const struct si_vs_prolog_bits *key)
 {
 /* VGPR initialization fixup for Vega10 and Raven is always done 
in the

  * VS prolog. */
 return sel->vs_needs_prolog || key->ls_vgpr_fix;
 }

-static bool si_compile_tgsi_main(struct si_shader_context *ctx,
- bool is_monolithic)
+static bool si_compile_tgsi_main(struct si_shader_context *ctx)
 {
 struct si_shader *shader = ctx->shader;
 struct si_shader_selector *sel = shader->selector;
 struct lp_build_tgsi_context *bld_base = &ctx->bld_base;

 // TODO clean all this up!
 switch (ctx->type) {
 case PIPE_SHADER_VERTEX:
 ctx->load_input = declare_input_vs;
 if (shader->key.as_ls)
@@ -6135,31 +6133,31 @@ static bool si_compile_tgsi_main(struct
si_shader_context *ctx,
  * - Add a barrier before the second shader.
  * - In the second shader, reset EXEC to ~0 and wrap the main 
part in

  *   an if-statement. This is required for correctness in geometry
  *   shaders, to ensure that empty GS waves do not send GS_EMIT and
  *   GS_CUT messages.
  *
  * For monolithic merged shaders, the first shader is wrapped in an
  * if-block together with its prolog in si_build_wrapper_function.
  */
 if (ctx->screen->info.chip_class >= GFX9) {
-    if (!is_monolithic &&
+    if (!shader->is_monolithic &&
 sel->info.num_instructions > 1 && /* not empty shader */
 (shader->key.as_es || shader->key.as_ls) &&
 (ctx->type == PIPE_SHADER_TESS_EVAL ||
  (ctx->type == PIPE_SHADER_VERTEX &&
   !si_vs_needs_prolog(sel, &shader->key.part.vs.prolog {
 si_init_exec_from_input(ctx,
 ctx->param_merged_wave_info, 0);
 } else if (ctx->type == PIPE_SHADER_TESS_CTRL ||
    ctx->type == PIPE_SHADER_GEOMETRY) {
-    if (!is_monolithic)
+    if (!shader->is_monolithic)
 ac_init_exec_full_mask(&ctx->ac);

 LLVMValueRef num_threads = si_unpack_param(ctx,
ctx->param_merged_wave_info, 8, 8);
 LLVMValueRef ena =
 LLVMBuildICmp(ctx->ac.builder, LLVMIntULT,
 ac_get_thread_id(&ctx->ac), num_threads, "");
 lp_build_if(&ctx->merged_wrap_if_state, &ctx->gallivm, ena

[Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

2018-06-25 Thread Dave Airlie
From: Dave Airlie 

The radeon winsys isn't linked against the ac code, I have vague
memories of this causing some problems before, for now fix the build
but just duplicating the code.
---
 .../winsys/radeon/drm/radeon_drm_surface.c| 62 ++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
index 5e6978c58ef..d528a6fe638 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
@@ -220,6 +220,66 @@ static void surf_drm_to_winsys(struct radeon_drm_winsys 
*ws,
  surf_ws->micro_tile_mode == 
RADEON_MICRO_MODE_ROTATED;
 }
 
+static void si_compute_cmask(const struct radeon_info *info,
+ const struct ac_surf_config *config,
+ struct radeon_surf *surf)
+{
+   unsigned pipe_interleave_bytes = info->pipe_interleave_bytes;
+   unsigned num_pipes = info->num_tile_pipes;
+   unsigned cl_width, cl_height;
+
+   if (surf->flags & RADEON_SURF_Z_OR_SBUFFER)
+   return;
+
+   assert(info->chip_class <= VI);
+
+   switch (num_pipes) {
+   case 2:
+   cl_width = 32;
+   cl_height = 16;
+   break;
+   case 4:
+   cl_width = 32;
+   cl_height = 32;
+   break;
+   case 8:
+   cl_width = 64;
+   cl_height = 32;
+   break;
+   case 16: /* Hawaii */
+   cl_width = 64;
+   cl_height = 64;
+   break;
+   default:
+   assert(0);
+   return;
+   }
+
+   unsigned base_align = num_pipes * pipe_interleave_bytes;
+
+   unsigned width = align(config->info.width, cl_width*8);
+   unsigned height = align(config->info.height, cl_height*8);
+   unsigned slice_elements = (width * height) / (8*8);
+
+   /* Each element of CMASK is a nibble. */
+   unsigned slice_bytes = slice_elements / 2;
+
+   surf->u.legacy.cmask_slice_tile_max = (width * height) / (128*128);
+   if (surf->u.legacy.cmask_slice_tile_max)
+   surf->u.legacy.cmask_slice_tile_max -= 1;
+
+   unsigned num_layers;
+   if (config->is_3d)
+   num_layers = config->info.depth;
+   else if (config->is_cube)
+   num_layers = 6;
+   else
+   num_layers = config->info.array_size;
+
+   surf->cmask_alignment = MAX2(256, base_align);
+   surf->cmask_size = align(slice_bytes, base_align) * num_layers;
+}
+
 static int radeon_winsys_surface_init(struct radeon_winsys *rws,
   const struct pipe_resource *tex,
   unsigned num_color_samples,
@@ -304,7 +364,7 @@ static int radeon_winsys_surface_init(struct radeon_winsys 
*rws,
config.is_3d = !!(tex->target == PIPE_TEXTURE_3D);
config.is_cube = !!(tex->target == PIPE_TEXTURE_CUBE);
 
-   ac_compute_cmask(&ws->info, &config, surf_ws);
+   si_compute_cmask(&ws->info, &config, surf_ws);
 }
 return 0;
 }
-- 
2.17.1

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


Re: [Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

2018-06-25 Thread Dieter Nützel

Compiling tested. (Didn't have any r600 hw in my box currently.)
could be tb ;-)
Thanks for your fast fix!

Dieter

Am 26.06.2018 02:50, schrieb Dave Airlie:

From: Dave Airlie 

The radeon winsys isn't linked against the ac code, I have vague
memories of this causing some problems before, for now fix the build
but just duplicating the code.
---
 .../winsys/radeon/drm/radeon_drm_surface.c| 62 ++-
 1 file changed, 61 insertions(+), 1 deletion(-)

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
index 5e6978c58ef..d528a6fe638 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
@@ -220,6 +220,66 @@ static void surf_drm_to_winsys(struct
radeon_drm_winsys *ws,
  surf_ws->micro_tile_mode == 
RADEON_MICRO_MODE_ROTATED;
 }

+static void si_compute_cmask(const struct radeon_info *info,
+ const struct ac_surf_config *config,
+ struct radeon_surf *surf)
+{
+   unsigned pipe_interleave_bytes = info->pipe_interleave_bytes;
+   unsigned num_pipes = info->num_tile_pipes;
+   unsigned cl_width, cl_height;
+
+   if (surf->flags & RADEON_SURF_Z_OR_SBUFFER)
+   return;
+
+   assert(info->chip_class <= VI);
+
+   switch (num_pipes) {
+   case 2:
+   cl_width = 32;
+   cl_height = 16;
+   break;
+   case 4:
+   cl_width = 32;
+   cl_height = 32;
+   break;
+   case 8:
+   cl_width = 64;
+   cl_height = 32;
+   break;
+   case 16: /* Hawaii */
+   cl_width = 64;
+   cl_height = 64;
+   break;
+   default:
+   assert(0);
+   return;
+   }
+
+   unsigned base_align = num_pipes * pipe_interleave_bytes;
+
+   unsigned width = align(config->info.width, cl_width*8);
+   unsigned height = align(config->info.height, cl_height*8);
+   unsigned slice_elements = (width * height) / (8*8);
+
+   /* Each element of CMASK is a nibble. */
+   unsigned slice_bytes = slice_elements / 2;
+
+   surf->u.legacy.cmask_slice_tile_max = (width * height) / (128*128);
+   if (surf->u.legacy.cmask_slice_tile_max)
+   surf->u.legacy.cmask_slice_tile_max -= 1;
+
+   unsigned num_layers;
+   if (config->is_3d)
+   num_layers = config->info.depth;
+   else if (config->is_cube)
+   num_layers = 6;
+   else
+   num_layers = config->info.array_size;
+
+   surf->cmask_alignment = MAX2(256, base_align);
+   surf->cmask_size = align(slice_bytes, base_align) * num_layers;
+}
+
 static int radeon_winsys_surface_init(struct radeon_winsys *rws,
   const struct pipe_resource *tex,
   unsigned num_color_samples,
@@ -304,7 +364,7 @@ static int radeon_winsys_surface_init(struct
radeon_winsys *rws,
config.is_3d = !!(tex->target == PIPE_TEXTURE_3D);
config.is_cube = !!(tex->target == PIPE_TEXTURE_CUBE);

-   ac_compute_cmask(&ws->info, &config, surf_ws);
+   si_compute_cmask(&ws->info, &config, surf_ws);
 }
 return 0;
 }

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


Re: [Mesa-dev] [PATCH] radeon: duplicate cmask surface for now.

2018-06-25 Thread Marek Olšák
Reviewed-by: Marek Olšák 

Thanks!

Marek

On Mon, Jun 25, 2018 at 8:50 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The radeon winsys isn't linked against the ac code, I have vague
> memories of this causing some problems before, for now fix the build
> but just duplicating the code.
> ---
>  .../winsys/radeon/drm/radeon_drm_surface.c| 62 ++-
>  1 file changed, 61 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c 
> b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
> index 5e6978c58ef..d528a6fe638 100644
> --- a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
> @@ -220,6 +220,66 @@ static void surf_drm_to_winsys(struct radeon_drm_winsys 
> *ws,
>   surf_ws->micro_tile_mode == 
> RADEON_MICRO_MODE_ROTATED;
>  }
>
> +static void si_compute_cmask(const struct radeon_info *info,
> + const struct ac_surf_config *config,
> + struct radeon_surf *surf)
> +{
> +   unsigned pipe_interleave_bytes = info->pipe_interleave_bytes;
> +   unsigned num_pipes = info->num_tile_pipes;
> +   unsigned cl_width, cl_height;
> +
> +   if (surf->flags & RADEON_SURF_Z_OR_SBUFFER)
> +   return;
> +
> +   assert(info->chip_class <= VI);
> +
> +   switch (num_pipes) {
> +   case 2:
> +   cl_width = 32;
> +   cl_height = 16;
> +   break;
> +   case 4:
> +   cl_width = 32;
> +   cl_height = 32;
> +   break;
> +   case 8:
> +   cl_width = 64;
> +   cl_height = 32;
> +   break;
> +   case 16: /* Hawaii */
> +   cl_width = 64;
> +   cl_height = 64;
> +   break;
> +   default:
> +   assert(0);
> +   return;
> +   }
> +
> +   unsigned base_align = num_pipes * pipe_interleave_bytes;
> +
> +   unsigned width = align(config->info.width, cl_width*8);
> +   unsigned height = align(config->info.height, cl_height*8);
> +   unsigned slice_elements = (width * height) / (8*8);
> +
> +   /* Each element of CMASK is a nibble. */
> +   unsigned slice_bytes = slice_elements / 2;
> +
> +   surf->u.legacy.cmask_slice_tile_max = (width * height) / (128*128);
> +   if (surf->u.legacy.cmask_slice_tile_max)
> +   surf->u.legacy.cmask_slice_tile_max -= 1;
> +
> +   unsigned num_layers;
> +   if (config->is_3d)
> +   num_layers = config->info.depth;
> +   else if (config->is_cube)
> +   num_layers = 6;
> +   else
> +   num_layers = config->info.array_size;
> +
> +   surf->cmask_alignment = MAX2(256, base_align);
> +   surf->cmask_size = align(slice_bytes, base_align) * num_layers;
> +}
> +
>  static int radeon_winsys_surface_init(struct radeon_winsys *rws,
>const struct pipe_resource *tex,
>unsigned num_color_samples,
> @@ -304,7 +364,7 @@ static int radeon_winsys_surface_init(struct 
> radeon_winsys *rws,
> config.is_3d = !!(tex->target == PIPE_TEXTURE_3D);
> config.is_cube = !!(tex->target == PIPE_TEXTURE_CUBE);
>
> -   ac_compute_cmask(&ws->info, &config, surf_ws);
> +   si_compute_cmask(&ws->info, &config, surf_ws);
>  }
>  return 0;
>  }
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] swr: bump minimum supported LLVM version to 5.0

2018-06-25 Thread Marek Olšák
Good timing. I have a patch that removes LLVM 5.0 support from AMD
Mesa drivers. :)

Marek

On Thu, Jun 21, 2018 at 5:51 AM, Eric Engestrom
 wrote:
> On Thursday, 2018-06-21 11:42:29 +0200, Juan A. Suarez Romero wrote:
>> On Tue, 2018-06-19 at 11:53 +0200, Juan A. Suarez Romero wrote:
>> > On Mon, 2018-06-18 at 16:29 +0100, Eric Engestrom wrote:
>> > > On Monday, 2018-06-18 16:23:41 +0200, Juan A. Suarez Romero wrote:
>> > > > RADV now requires LLVM 5.0 or greater, and thus we can't build dist
>> > > > tarball because swr requires LLVM 4.0.
>> > > >
>> > > > Let's bump required LLVM to 5.0 in swr too.
>> > > >
>> > > > Fixes: f9eb1ef870 ("amd: remove support for LLVM 4.0")
>> > > > Cc: George Kyriazis 
>> > > > Cc: Tim Rowley 
>> > > > Cc: Emil Velikov 
>> > > > Cc: Dylan Baker 
>> > > > Cc: Eric Engestrom 
>> > >
>> > > s/imgtec/intel/ :)
>> > > (I moved)
>> > >
>> >
>> > Fixed :)
>> >
>> > > > ---
>> > > >  .travis.yml | 12 ++--
>> > > >  configure.ac|  7 ---
>> > > >  meson.build |  4 +---
>> > > >  src/gallium/drivers/swr/Makefile.am |  6 +++---
>> > > >  src/gallium/drivers/swr/SConscript  |  4 ++--
>> > > >  5 files changed, 16 insertions(+), 17 deletions(-)
>> > > >
>> > > > diff --git a/.travis.yml b/.travis.yml
>> > > > index b1fc7de9587..c9a30fa0ef5 100644
>> > > > --- a/.travis.yml
>> > > > +++ b/.travis.yml
>> > > > @@ -92,7 +92,7 @@ matrix:
>> > > >  - BUILD=make
>> > > >  - MAKEFLAGS="-j4"
>> > > >  - MAKE_CHECK_COMMAND="true"
>> > > > -- LLVM_VERSION=4.0
>> > > > +- LLVM_VERSION=5.0
>> > > >  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>> > > >  - OVERRIDE_CC="gcc-4.8"
>> > > >  - OVERRIDE_CXX="g++-4.8"
>> > > > @@ -105,12 +105,12 @@ matrix:
>> > > >addons:
>> > > >  apt:
>> > > >sources:
>> > > > -- llvm-toolchain-trusty-4.0
>> > > > +- llvm-toolchain-trusty-5.0
>> > > >packages:
>> > > >  # LLVM packaging is broken and misses these dependencies
>> > > >  - libedit-dev
>> > > >  # From sources above
>> > > > -- llvm-4.0-dev
>> > > > +- llvm-5.0-dev
>> > > >  # Common
>> > > >  - xz-utils
>> > > >  - x11proto-xf86vidmode-dev
>> > > > @@ -432,7 +432,7 @@ matrix:
>> > > >  - BUILD=scons
>> > > >  - SCONSFLAGS="-j4"
>> > > >  - SCONS_TARGET="swr=1"
>> > > > -- LLVM_VERSION=4.0
>> > > > +- LLVM_VERSION=5.0
>> > > >  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>> > > >  # Keep it symmetrical to the make build. There's no actual 
>> > > > SWR, yet.
>> > > >  - SCONS_CHECK_COMMAND="true"
>> > > > @@ -441,13 +441,13 @@ matrix:
>> > > >addons:
>> > > >  apt:
>> > > >sources:
>> > > > -- llvm-toolchain-trusty-4.0
>> > > > +- llvm-toolchain-trusty-5.0
>> > > >packages:
>> > > >  - scons
>> > > >  # LLVM packaging is broken and misses these dependencies
>> > > >  - libedit-dev
>> > > >  # From sources above
>> > > > -- llvm-4.0-dev
>> > > > +- llvm-5.0-dev
>> > > >  # Common
>> > > >  - xz-utils
>> > > >  - x11proto-xf86vidmode-dev
>> > > > diff --git a/configure.ac b/configure.ac
>> > > > index 7a0e4754208..543b6fe061b 100644
>> > > > --- a/configure.ac
>> > > > +++ b/configure.ac
>> > > > @@ -110,7 +110,7 @@ LLVM_REQUIRED_OPENCL=3.9.0
>> > > >  LLVM_REQUIRED_R600=3.9.0
>> > > >  LLVM_REQUIRED_RADEONSI=5.0.0
>> > > >  LLVM_REQUIRED_RADV=5.0.0
>> > > > -LLVM_REQUIRED_SWR=4.0.0
>> > > > +LLVM_REQUIRED_SWR=5.0.0
>> > > >
>> > > >  dnl Check for progs
>> > > >  AC_PROG_CPP
>> > > > @@ -2755,8 +2755,9 @@ if test -n "$with_gallium_drivers"; then
>> > > >  fi
>> > > >
>> > > >  # XXX: Keep in sync with LLVM_REQUIRED_SWR
>> > > > -AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != 
>> > > > x4.0.0 -a \
>> > > > -  "x$LLVM_VERSION" != 
>> > > > x4.0.1)
>> > > > +AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != 
>> > > > x5.0.0 -a \
>> > > > +  "x$LLVM_VERSION" != 
>> > > > x5.0.1 -a \
>> > > > +  "x$LLVM_VERSION" != 
>> > > > x5.0.2)
>> > >
>> > > That check seems designed to break every time something in mesa changes
>> > > supported llvm version. Is there a reason for it not to be a simple
>> > > `>= 4.0` check?
>> > >
>> >
>> > Because gen_builder.hpp is a generated file and it contains information 
>> > that is
>> > specific to the LLVM version it originates from. Apparently, this file is
>> > forward compatible, but not backward, and it is included in dist tarball.
>> >
>> > I guess the problem is that if you en

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

2018-06-25 Thread Dieter Nützel

Am 25.06.2018 13:26, schrieb Timothy Arceri:

Please note I've fixed up make check where is was broken when enabling
some of these extensions. You can see all of the latests compat
patches here:

https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64


For the whole series

(1-9 from this set,
Radeonsi OpenGL 4.0 compat profile, 1-5
and
mesa: add missing display list support for ARB_compute_shader)

your 'whole' ARB_gpu_shader_fp64 branch

Tested-by: Dieter Nützel 

with KDE Plasma 5, UH, UV, glmark2

OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.25.0, 
4.17.2-3.g2290680-default, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel 
(git-6e8bf98e7e)

OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.0-devel 
(git-6e8bf98e7e)

OpenGL shading language version string: 4.40
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.0-devel 
(git-6e8bf98e7e)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 
3.10

OpenGL ES profile extensions:

Dieter


On 22/06/18 18:47, Timothy Arceri wrote:

I've send all of these patches out already. The only change is to the
first 2 patches which fixes things so we store a double as 2 unsigned 
ints

rather than 2 floats.

Everything here has corresponding piglit tests all of which are now
upstream with the exception of the compute shader display list test.

Our current TODO list has 2 remaining extensions on it before it
should be ok to enable OpenGL 4.4 compat contexts in radeonsi.


___
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 01/19] radeonsi: clean up passing the is_monolithic flag for compilation

2018-06-25 Thread Dylan Baker
R300 had the same problem. Linking to amd_common ends up pulling in addrlib 
too. Jfyi

On June 25, 2018 5:48:51 PM PDT, Timothy Arceri  wrote:
>On 26/06/18 09:51, Dieter Nützel wrote:
>> Hello Marek,
>> 
>> after this series landed I get this:
>> 
>> Making all in targets/pipe-loader
>> make[4]: Verzeichnis „/opt/mesa/src/gallium/targets/pipe-loader“ wird
>
>> betreten
>>    CXXLD    pipe_r600.la
>>
>../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a(radeon_drm_surface.o):
>
>> In function `radeon_winsys_surface_init':
>> /opt/mesa/src/gallium/winsys/radeon/drm/radeon_drm_surface.c:307: 
>> undefined reference to `ac_compute_cmask'
>> collect2: error: ld returned 1 exit status
>> make[4]: *** [Makefile:970: pipe_r600.la] Fehler 1
>> 
>> Didn't have more time for digging, yet.
>
>r600 probably doesn't get linked to the amd common (ac) code that is 
>normally just shared between radv and radeonsi.
>
>> 
>> Dieter
>> 
>> Am 23.06.2018 00:31, schrieb Marek Olšák:
>>> From: Marek Olšák 
>>>
>>> ---
>>>  src/gallium/drivers/radeonsi/si_shader.c  | 30
>+--
>>>  src/gallium/drivers/radeonsi/si_shader.h  |  1 -
>>>  .../drivers/radeonsi/si_shader_internal.h |  3 --
>>>  .../drivers/radeonsi/si_state_shaders.c   |  7 +++--
>>>  4 files changed, 18 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/radeonsi/si_shader.c
>>> b/src/gallium/drivers/radeonsi/si_shader.c
>>> index e7e2a12a7b0..677853af60b 100644
>>> --- a/src/gallium/drivers/radeonsi/si_shader.c
>>> +++ b/src/gallium/drivers/radeonsi/si_shader.c
>>> @@ -5047,22 +5047,21 @@ static void create_function(struct
>>> si_shader_context *ctx)
>>>  break;
>>>  default:
>>>  assert(0 && "unimplemented shader");
>>>  return;
>>>  }
>>>
>>>  si_create_function(ctx, "main", returns, num_returns, &fninfo,
>>>     si_get_max_workgroup_size(shader));
>>>
>>>  /* Reserve register locations for VGPR inputs the PS prolog may
>
>>> need. */
>>> -    if (ctx->type == PIPE_SHADER_FRAGMENT &&
>>> -    ctx->separate_prolog) {
>>> +    if (ctx->type == PIPE_SHADER_FRAGMENT && 
>>> !ctx->shader->is_monolithic) {
>>>  ac_llvm_add_target_dep_function_attr(ctx->main_fn,
>>>   "InitialPSInputAddr",
>>>   S_0286D0_PERSP_SAMPLE_ENA(1) |
>>>   S_0286D0_PERSP_CENTER_ENA(1) |
>>>   S_0286D0_PERSP_CENTROID_ENA(1) |
>>>   S_0286D0_LINEAR_SAMPLE_ENA(1) |
>>>   S_0286D0_LINEAR_CENTER_ENA(1) |
>>>   S_0286D0_LINEAR_CENTROID_ENA(1) |
>>>   S_0286D0_FRONT_FACE_ENA(1) |
>>>   S_0286D0_ANCILLARY_ENA(1) |
>>> @@ -6049,22 +6048,21 @@ static void si_init_exec_from_input(struct
>>> si_shader_context *ctx,
>>>  }
>>>
>>>  static bool si_vs_needs_prolog(const struct si_shader_selector
>*sel,
>>>     const struct si_vs_prolog_bits *key)
>>>  {
>>>  /* VGPR initialization fixup for Vega10 and Raven is always
>done 
>>> in the
>>>   * VS prolog. */
>>>  return sel->vs_needs_prolog || key->ls_vgpr_fix;
>>>  }
>>>
>>> -static bool si_compile_tgsi_main(struct si_shader_context *ctx,
>>> - bool is_monolithic)
>>> +static bool si_compile_tgsi_main(struct si_shader_context *ctx)
>>>  {
>>>  struct si_shader *shader = ctx->shader;
>>>  struct si_shader_selector *sel = shader->selector;
>>>  struct lp_build_tgsi_context *bld_base = &ctx->bld_base;
>>>
>>>  // TODO clean all this up!
>>>  switch (ctx->type) {
>>>  case PIPE_SHADER_VERTEX:
>>>  ctx->load_input = declare_input_vs;
>>>  if (shader->key.as_ls)
>>> @@ -6135,31 +6133,31 @@ static bool si_compile_tgsi_main(struct
>>> si_shader_context *ctx,
>>>   * - Add a barrier before the second shader.
>>>   * - In the second shader, reset EXEC to ~0 and wrap the main 
>>> part in
>>>   *   an if-statement. This is required for correctness in
>geometry
>>>   *   shaders, to ensure that empty GS waves do not send GS_EMIT
>and
>>>   *   GS_CUT messages.
>>>   *
>>>   * For monolithic merged shaders, the first shader is wrapped
>in an
>>>   * if-block together with its prolog in
>si_build_wrapper_function.
>>>   */
>>>  if (ctx->screen->info.chip_class >= GFX9) {
>>> -    if (!is_monolithic &&
>>> +    if (!shader->is_monolithic &&
>>>  sel->info.num_instructions > 1 && /* not empty shader
>*/
>>>  (shader->key.as_es || shader->key.as_ls) &&
>>>  (ctx->type == PIPE_SHADER_TESS_EVAL ||
>>>   (ctx->type == PIPE_SHADER_VERTEX &&
>>>    !si_vs_needs_prolog(sel,
>&shader->key.part.vs.prolog {
>>>  si_init_exec_from_input(ctx,
>>>  ctx->param_merged_wave_info, 0);
>>>  

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

2018-06-25 Thread Mike Lothian
Hi

I can confirm I no longer need to pass MESA_GL_VERSION_OVERRIDE to Dying
Light

Tested-by: Mike Lothian 

Cheers

Mike

On Tue, 26 Jun 2018 at 04:41 Dieter Nützel  wrote:

> Am 25.06.2018 13:26, schrieb Timothy Arceri:
> > Please note I've fixed up make check where is was broken when enabling
> > some of these extensions. You can see all of the latests compat
> > patches here:
> >
> > https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64
>
> For the whole series
>
> (1-9 from this set,
> Radeonsi OpenGL 4.0 compat profile, 1-5
> and
> mesa: add missing display list support for ARB_compute_shader)
>
> your 'whole' ARB_gpu_shader_fp64 branch
>
> Tested-by: Dieter Nützel 
>
> with KDE Plasma 5, UH, UV, glmark2
>
> OpenGL vendor string: X.Org
> OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.25.0,
> 4.17.2-3.g2290680-default, LLVM 7.0.0)
> OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL shading language version string: 4.40
> OpenGL context flags: (none)
> OpenGL profile mask: compatibility profile
> OpenGL extensions:
> OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES
> 3.10
> OpenGL ES profile extensions:
>
> Dieter
>
> > On 22/06/18 18:47, Timothy Arceri wrote:
> >> I've send all of these patches out already. The only change is to the
> >> first 2 patches which fixes things so we store a double as 2 unsigned
> >> ints
> >> rather than 2 floats.
> >>
> >> Everything here has corresponding piglit tests all of which are now
> >> upstream with the exception of the compute shader display list test.
> >>
> >> Our current TODO list has 2 remaining extensions on it before it
> >> should be ok to enable OpenGL 4.4 compat contexts in radeonsi.
> >>
> >>
> >> ___
> >> 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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev