Re: [Mesa-dev] [PATCH 00/17] i965 ARB_get_program_binary support

[Timothy Arceri]

On 09/11/17 21:46, Timothy Arceri wrote:

On 09/11/17 17:42, Jordan Justen wrote:

git://people.freedesktop.org/~jljusten/mesa i965-get-program-binary-v1

This series adds i965 support for ARB_get_program_binary with greater
than 0 supported formats. Today we support this extension, but
advertise support for 0 formats. This series allows i965 to advertise
support for 1 format.

This series defines a common Mesa format for ARB_get_program_binary,
along with helper functions to read and write the format. We also
define an OpenGL Mesa spec to be used with this binary format. The
binary saved can only be reloaded on the exact same Mesa build using
the exact same hardware.

The i965 implementation saves out a serialize nir represenation of the
program. Later we can add support for saving the gen binary program as
well. (We will still need the nir program for state based recompiles.)

This implementation passes piglit, deqp and glcts functions.


Nice to see this finally implemented :) Do the test suites actually test 
the extension? I'm assuming piglit doesn't.



It also
works with Dota 2, which appears to make use of the extension.


Would be interesting to try Dead Island with this if you have it. It 
should fix this bug: https://bugs.freedesktop.org/show_bug.cgi?id=85564


I can confirm Dead Island now works great (fast load times and no crash) 
with this series. Great work!


I'm going to resolve that bug as not our bug as it is clearly a game bug.



Dying Light is another game that uses the extension.



Jordan Justen (17):
   docs/specs: Add GL_MESA_program_binary_formats extension spec
   include/GL: Add GL_MESA_program_binary_formats
   compiler: Fold shader_cache in with libglsl sources
   glsl: Split out shader program serialization
   main, glsl: Add UniformDataDefaults which stores uniform defaults
   i965: Add brw_program_deserialize_nir
   i965: Free serialized nir after deserializing
   i965: Add brw_program_serialize_nir
   i965: Fix memory leak when serializing nir
   main: Allow non-zero NUM_PROGRAM_BINARY_FORMATS
   main: Support 1 Mesa format with get for GL_PROGRAM_BINARY_FORMATS
   main: Support calling driver for GL_PROGRAM_BINARY_LENGTH
   main: Support calling driver for GetProgramBinary
   main: Support calling driver for ProgramBinary
   main: Clear shader program data whenever ProgramBinary is called
   util: Add Mesa ARB_get_program_binary helper functions
   i965: Add ARB_get_program_binary support using nir_serialization

  docs/specs/MESA_program_binary_formats.txt  |   59 ++
  docs/specs/enums.txt    |    3 +
  include/GL/gl.h |    8 +
  src/compiler/Android.glsl.mk    |    3 +-
  src/compiler/Makefile.glsl.am   |    3 +-
  src/compiler/Makefile.sources   |    8 +-
  src/compiler/glsl/link_uniform_initializers.cpp |    2 +
  src/compiler/glsl/link_uniforms.cpp |    3 +
  src/compiler/glsl/meson.build   |    2 +
  src/compiler/glsl/serialize.cpp | 1252 
+++

  src/compiler/glsl/serialize.h   |   50 +
  src/compiler/glsl/shader_cache.cpp  | 1185 
+

  src/compiler/shader_info.h  |    1 +
  src/mapi/glapi/registry/gl.xml  |    2 +-
  src/mesa/drivers/dri/i965/Makefile.sources  |    1 +
  src/mesa/drivers/dri/i965/brw_context.c |    9 +
  src/mesa/drivers/dri/i965/brw_context.h |   16 +
  src/mesa/drivers/dri/i965/brw_disk_cache.c  |   31 +-
  src/mesa/drivers/dri/i965/brw_link.cpp  |    9 +-
  src/mesa/drivers/dri/i965/brw_program.c |   35 +
  src/mesa/drivers/dri/i965/brw_program.h |    7 +
  src/mesa/drivers/dri/i965/brw_program_binary.c  |  200 
  src/mesa/drivers/dri/i965/meson.build   |    1 +
  src/mesa/main/dd.h  |   20 +
  src/mesa/main/get.c |    9 +
  src/mesa/main/get_hash_params.py    |    4 +-
  src/mesa/main/mtypes.h  |    4 +
  src/mesa/main/shaderapi.c   |   63 +-
  src/util/Makefile.sources   |    2 +
  src/util/meson.build    |    2 +
  src/util/program_binary.c   |  322 ++
  src/util/program_binary.h   |   91 ++
  32 files changed, 2162 insertions(+), 1245 deletions(-)
  create mode 100644 docs/specs/MESA_program_binary_formats.txt
  create mode 100644 src/compiler/glsl/serialize.cpp
  create mode 100644 src/compiler/glsl/serialize.h
  create mode 100644 src/mesa/drivers/dri/i965/brw_program_binary.c
  create mode 100644 src/util/program_binary.c
  create mode 100644 src/util/program_binary.h


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

[Mesa-dev] [PATCH] freedreno/meson: Only build the compiler if building freedreno

[Jason Ekstrand]

Setting build_by_default to true makes it suddenly pull in freedreno and
all of gallium unconditionally.

Cc: Rob Clark 
Cc: Dylan Baker 
---
 src/gallium/drivers/freedreno/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/meson.build 
b/src/gallium/drivers/freedreno/meson.build
index 3fb94ed..b3a33da 100644
--- a/src/gallium/drivers/freedreno/meson.build
+++ b/src/gallium/drivers/freedreno/meson.build
@@ -224,5 +224,5 @@ ir3_compiler = executable(
 libglsl_standalone,
 libmesa_util,
   ],
-  build_by_default : true,
+  build_by_default : with_gallium_freedreno,
 )
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 1/2] nv50/ir: optimize signed integer modulo by pow-of-2

[Ilia Mirkin]

It's common to use signed int modulo in GLSL. As it happens, the GLSL
specs allow the result to be undefined, but that seems fairly
surprising. It's not that much more effort to get it right, at least for
positive modulo operators.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir.cpp|  8 +--
 .../drivers/nouveau/codegen/nv50_ir_peephole.cpp   | 27 +++---
 2 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
index 4076177e56d..657784163b3 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
@@ -429,13 +429,7 @@ ImmediateValue::isNegative() const
 bool
 ImmediateValue::isPow2() const
 {
-   switch (reg.type) {
-   case TYPE_U8:
-   case TYPE_U16:
-   case TYPE_U32: return util_is_power_of_two(reg.data.u32);
-   default:
-  return false;
-   }
+   return util_is_power_of_two(reg.data.u32);
 }
 
 void
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 7e4e193e3d2..fabac662e7f 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1163,10 +1163,31 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
   break;
 
case OP_MOD:
-  if (i->sType == TYPE_U32 && imm0.isPow2()) {
+  if (s == 1 && imm0.isPow2()) {
  bld.setPosition(i, false);
- i->op = OP_AND;
- i->setSrc(1, bld.loadImm(NULL, imm0.reg.data.u32 - 1));
+ if (i->sType == TYPE_U32) {
+i->op = OP_AND;
+i->setSrc(1, bld.loadImm(NULL, imm0.reg.data.u32 - 1));
+ } else if (i->sType == TYPE_S32) {
+// Do it on the absolute value of the input, and then restore the
+// sign. The only odd case is MIN_INT, but that should work out
+// as well, since MIN_INT mod any power of 2 is 0.
+//
+// Technically we don't have to do any of this since MOD is
+// undefined with negative arguments in GLSL, but this seems like
+// the nice thing to do.
+Value *abs = bld.mkOp1v(OP_ABS, TYPE_S32, bld.getSSA(), 
i->getSrc(0));
+Value *neg, *v1, *v2;
+bld.mkCmp(OP_SET, CC_LT, TYPE_S32, (neg = bld.getSSA(1, 
FILE_FLAGS)), TYPE_S32, i->getSrc(0), bld.loadImm(NULL, 0));
+Value *mod = bld.mkOp2v(OP_AND, TYPE_U32, bld.getSSA(), abs, 
bld.loadImm(NULL, imm0.reg.data.u32 - 1));
+bld.mkOp1(OP_NEG, TYPE_S32, (v1 = bld.getSSA()), mod)
+   ->setPredicate(CC_P, neg);
+bld.mkOp1(OP_MOV, TYPE_S32, (v2 = bld.getSSA()), mod)
+   ->setPredicate(CC_NOT_P, neg);
+newi = bld.mkOp2(OP_UNION, TYPE_S32, i->getDef(0), v1, v2);
+
+delete_Instruction(prog, i);
+ }
   }
   break;
 
-- 
2.13.6

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

[Mesa-dev] [PATCH 2/2] nv50/ir: add optimization for modulo by a non-power-of-2 value

[Ilia Mirkin]

We can still use the optimized division methods which make use of
multiplication with overflow.

Signed-off-by: Ilia Mirkin 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index fabac662e7f..56a50320816 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
@@ -1188,6 +1188,21 @@ ConstantFolding::opnd(Instruction *i, ImmediateValue 
, int s)
 
 delete_Instruction(prog, i);
  }
+  } else if (s == 1) {
+ // In this case, we still want the optimized lowering that we get
+ // from having division by an immediate.
+ //
+ // a % b == a - (a/b) * b
+ bld.setPosition(i, false);
+ Value *div = bld.mkOp2v(OP_DIV, i->sType, bld.getSSA(),
+ i->getSrc(0), i->getSrc(1));
+ newi = bld.mkOp2(OP_ADD, i->sType, i->getDef(0), i->getSrc(0),
+  bld.mkOp2v(OP_MUL, i->sType, bld.getSSA(), div, 
i->getSrc(1)));
+ // TODO: Check that target supports this. In this case, we know that
+ // all backends do.
+ newi->src(1).mod = Modifier(NV50_IR_MOD_NEG);
+
+ delete_Instruction(prog, i);
   }
   break;
 
-- 
2.13.6

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

Re: [Mesa-dev] [PATCH 0/5] Volatile and invariant LDS memory ops

[Marek Olšák]

On Fri, Nov 10, 2017 at 9:58 PM, Nicolai Hähnle  wrote:
> On 10.11.2017 19:24, Connor Abbott wrote:
>>
>> On Fri, Nov 10, 2017 at 1:19 PM, Marek Olšák  wrote:
>>>
>>> On Fri, Nov 10, 2017 at 6:55 PM, Nicolai Hähnle 
>>> wrote:

 On 10.11.2017 18:43, Marek Olšák wrote:
>
>
> On Fri, Nov 10, 2017 at 2:09 AM, Connor Abbott 
> wrote:
>>
>>
>> On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák  wrote:
>>>
>>>
>>> On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault 
>>> wrote:



> On Nov 10, 2017, at 07:41, Marek Olšák  wrote:
>
> Hi,
>
> This fixes the TCS gl_ClipDistance piglit failure that was
> uncovered
> by a recent LLVM change. The solution is to set volatile on loads
> and stores to enforce proper ordering.
>
> Please review.
>


 Every LDS access certainly should not be volatile. This kills all
 optimizations, like formation of ds_read2_b32. What ordering issue
 are you
 having?
>>>
>>>
>>>
>>> It might be caused by inttoptr(NULL) that we do to declare LDS. There
>>> is simply no ordering enforced, which is weird.
>>
>>
>>
>> As soon as you do inttoptr(NULL), you've generated a poison value (in
>> LLVM legalese), so LLVM will assume that you never dereference it and
>> optimize accordingly. I think a GEP instruction without the inbounds
>> parameter set will get rid of the poison value, although I'm not sure
>> about the case where the offset is known to be zero. At least, that's
>> my reading of the langref text for the GEP instruction
>> (https://llvm.org/docs/LangRef.html#id215). If zero is a valid address
>> in LDS, then it sounds like LLVM needs to be fixed to disable this
>> optimization for certain address spaces. On the other hand, if you're
>> doing inttoptr(NULL) + offset, where "offset" is the result of a
>> ptrtoint somewhere, you should be doing inttoptr(offset) instead, and
>> then LLVM should never misbehave.
>
>
>
> I don't think that using inttoptr before every load and store would be
> better than volatile. The must be a better solution.



 Can't we just allocate the required LDS memory explicitly like we did
 for
 the LDS-based derivative computations?

 It may require shuffling around a bit how/when we calculate the required
 sizes, but it doesn't seem impossible.
>>>
>>>
>>> We want to share the same declaration in TCS main and epilog parts.
>>>
>>> Does LLVM know that LDS declarations are pre-initialized?
>>> Do sized LDS declarations affect SIMD-occupancy-based optimizations?
>>> Because Mesa always declares 64kB of LDS and the real value is
>>> determined at runtime.
>>
>>
>> I don't know about the latter, but for the former, if you declare the
>> LDS variable as having external linkage, LLVM should assume that it
>> might be initialized beforehand -- exactly like a global non-static
>> variable in C.
>
>
> Makes sense.
>
> I don't think LLVM is really looking at LDS size too closely for anything,
> since LDS is per-thread group. But it's been a while since I checked.
>
> So just declaring a 64/32 KB memory block and then potentially not using all
> of it is probably fine and is probably the best short-term solution (if it
> works).
>
> It's a good point though that "shuffling around the computation of the
> required sizes" is potentially much more involved than I was thinking at
> first. It looks like if we wanted to be perfectly honest with LLVM about
> what's going on (and I believe we should, in the long run), we'd have to
> teach it a notion of "per-thread LDS memory". That requires more thought.

We can't tell LLVM the size of LDS, because we don't know it - it's
computed from 2 independent shaders (LS and HS, or ES and GS).

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

[Mesa-dev] [PATCH] docs: update llvmpipe.html build instructions

[Brian Paul]

---
 docs/llvmpipe.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html
index 2efbbd4..e467692 100644
--- a/docs/llvmpipe.html
+++ b/docs/llvmpipe.html
@@ -108,10 +108,10 @@ To build everything on Linux invoke scons as:
   scons build=debug libgl-xlib
 
 
-Alternatively, you can build it with GNU make, if you prefer, by invoking it as
-
+Alternatively, you can build it with autoconf/make with:
 
-  make linux-llvm
+  ./configure --enable-glx=gallium-xlib --with-gallium-drivers=swrast 
--disable-dri --disable-gbm --disable-egl
+  make
 
 
 but the rest of these instructions assume that scons is used.
-- 
1.9.1

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

[Mesa-dev] [PATCH] svga: issue debug warning for unsupported two-sided stencil state

[Brian Paul]

We only have a single stencil read mask and write mask.  Issue a
warning if different front/back values are used.  The Piglit
gl-2.0-two-sided-stencil test hits this.
---
 src/gallium/drivers/svga/svga_pipe_depthstencil.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/src/gallium/drivers/svga/svga_pipe_depthstencil.c 
b/src/gallium/drivers/svga/svga_pipe_depthstencil.c
index 1b62290..e5caa4b 100644
--- a/src/gallium/drivers/svga/svga_pipe_depthstencil.c
+++ b/src/gallium/drivers/svga/svga_pipe_depthstencil.c
@@ -172,6 +172,21 @@ svga_create_depth_stencil_state(struct pipe_context *pipe,
 
   ds->stencil_mask  = templ->stencil[1].valuemask & 0xff;
   ds->stencil_writemask = templ->stencil[1].writemask & 0xff;
+
+  if (templ->stencil[1].valuemask != templ->stencil[0].valuemask) {
+ pipe_debug_message(>debug.callback, CONFORMANCE,
+"two-sided stencil mask not supported "
+"(front=0x%x, back=0x%x)",
+templ->stencil[0].valuemask,
+templ->stencil[1].valuemask);
+  }
+  if (templ->stencil[1].writemask != templ->stencil[0].writemask) {
+ pipe_debug_message(>debug.callback, CONFORMANCE,
+"two-sided stencil writemask not supported "
+"(front=0x%x, back=0x%x)",
+templ->stencil[0].writemask,
+templ->stencil[1].writemask);
+  }
}
else {
   /* back face state is same as front-face state */
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/2] st/mesa: move st_init_driver_flags() earlier in file

[Brian Paul]

To get rid of forward declaration.
---
 src/mesa/state_tracker/st_context.c | 123 ++--
 1 file changed, 62 insertions(+), 61 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 8abf879..c52f42b 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -286,7 +286,68 @@ st_destroy_context_priv(struct st_context *st, bool 
destroy_pipe)
free( st );
 }
 
-static void st_init_driver_flags(struct st_context *st);
+
+static void st_init_driver_flags(struct st_context *st)
+{
+   struct gl_driver_flags *f = >ctx->DriverFlags;
+
+   f->NewArray = ST_NEW_VERTEX_ARRAYS;
+   f->NewRasterizerDiscard = ST_NEW_RASTERIZER;
+   f->NewTileRasterOrder = ST_NEW_RASTERIZER;
+   f->NewUniformBuffer = ST_NEW_UNIFORM_BUFFER;
+   f->NewDefaultTessLevels = ST_NEW_TESS_STATE;
+
+   /* Shader resources */
+   f->NewTextureBuffer = ST_NEW_SAMPLER_VIEWS;
+   if (st->has_hw_atomics)
+  f->NewAtomicBuffer = ST_NEW_HW_ATOMICS;
+   else
+  f->NewAtomicBuffer = ST_NEW_ATOMIC_BUFFER;
+   f->NewShaderStorageBuffer = ST_NEW_STORAGE_BUFFER;
+   f->NewImageUnits = ST_NEW_IMAGE_UNITS;
+
+   f->NewShaderConstants[MESA_SHADER_VERTEX] = ST_NEW_VS_CONSTANTS;
+   f->NewShaderConstants[MESA_SHADER_TESS_CTRL] = ST_NEW_TCS_CONSTANTS;
+   f->NewShaderConstants[MESA_SHADER_TESS_EVAL] = ST_NEW_TES_CONSTANTS;
+   f->NewShaderConstants[MESA_SHADER_GEOMETRY] = ST_NEW_GS_CONSTANTS;
+   f->NewShaderConstants[MESA_SHADER_FRAGMENT] = ST_NEW_FS_CONSTANTS;
+   f->NewShaderConstants[MESA_SHADER_COMPUTE] = ST_NEW_CS_CONSTANTS;
+
+   f->NewWindowRectangles = ST_NEW_WINDOW_RECTANGLES;
+   f->NewFramebufferSRGB = ST_NEW_FB_STATE;
+   f->NewScissorRect = ST_NEW_SCISSOR;
+   f->NewScissorTest = ST_NEW_SCISSOR | ST_NEW_RASTERIZER;
+   f->NewAlphaTest = ST_NEW_DSA;
+   f->NewBlend = ST_NEW_BLEND;
+   f->NewBlendColor = ST_NEW_BLEND_COLOR;
+   f->NewColorMask = ST_NEW_BLEND;
+   f->NewDepth = ST_NEW_DSA;
+   f->NewLogicOp = ST_NEW_BLEND;
+   f->NewStencil = ST_NEW_DSA;
+   f->NewMultisampleEnable = ST_NEW_BLEND | ST_NEW_RASTERIZER |
+ ST_NEW_SAMPLE_MASK | ST_NEW_SAMPLE_SHADING;
+   f->NewSampleAlphaToXEnable = ST_NEW_BLEND;
+   f->NewSampleMask = ST_NEW_SAMPLE_MASK;
+   f->NewSampleShading = ST_NEW_SAMPLE_SHADING;
+
+   /* This depends on what the gallium driver wants. */
+   if (st->force_persample_in_shader) {
+  f->NewMultisampleEnable |= ST_NEW_FS_STATE;
+  f->NewSampleShading |= ST_NEW_FS_STATE;
+   } else {
+  f->NewSampleShading |= ST_NEW_RASTERIZER;
+   }
+
+   f->NewClipControl = ST_NEW_VIEWPORT | ST_NEW_RASTERIZER;
+   f->NewClipPlane = ST_NEW_CLIP_STATE;
+   f->NewClipPlaneEnable = ST_NEW_RASTERIZER;
+   f->NewDepthClamp = ST_NEW_RASTERIZER;
+   f->NewLineState = ST_NEW_RASTERIZER;
+   f->NewPolygonState = ST_NEW_RASTERIZER;
+   f->NewPolygonStipple = ST_NEW_POLY_STIPPLE;
+   f->NewViewport = ST_NEW_VIEWPORT;
+}
+
 
 static struct st_context *
 st_create_context_priv( struct gl_context *ctx, struct pipe_context *pipe,
@@ -489,66 +550,6 @@ st_create_context_priv( struct gl_context *ctx, struct 
pipe_context *pipe,
return st;
 }
 
-static void st_init_driver_flags(struct st_context *st)
-{
-   struct gl_driver_flags *f = >ctx->DriverFlags;
-
-   f->NewArray = ST_NEW_VERTEX_ARRAYS;
-   f->NewRasterizerDiscard = ST_NEW_RASTERIZER;
-   f->NewTileRasterOrder = ST_NEW_RASTERIZER;
-   f->NewUniformBuffer = ST_NEW_UNIFORM_BUFFER;
-   f->NewDefaultTessLevels = ST_NEW_TESS_STATE;
-
-   /* Shader resources */
-   f->NewTextureBuffer = ST_NEW_SAMPLER_VIEWS;
-   if (st->has_hw_atomics)
-  f->NewAtomicBuffer = ST_NEW_HW_ATOMICS;
-   else
-  f->NewAtomicBuffer = ST_NEW_ATOMIC_BUFFER;
-   f->NewShaderStorageBuffer = ST_NEW_STORAGE_BUFFER;
-   f->NewImageUnits = ST_NEW_IMAGE_UNITS;
-
-   f->NewShaderConstants[MESA_SHADER_VERTEX] = ST_NEW_VS_CONSTANTS;
-   f->NewShaderConstants[MESA_SHADER_TESS_CTRL] = ST_NEW_TCS_CONSTANTS;
-   f->NewShaderConstants[MESA_SHADER_TESS_EVAL] = ST_NEW_TES_CONSTANTS;
-   f->NewShaderConstants[MESA_SHADER_GEOMETRY] = ST_NEW_GS_CONSTANTS;
-   f->NewShaderConstants[MESA_SHADER_FRAGMENT] = ST_NEW_FS_CONSTANTS;
-   f->NewShaderConstants[MESA_SHADER_COMPUTE] = ST_NEW_CS_CONSTANTS;
-
-   f->NewWindowRectangles = ST_NEW_WINDOW_RECTANGLES;
-   f->NewFramebufferSRGB = ST_NEW_FB_STATE;
-   f->NewScissorRect = ST_NEW_SCISSOR;
-   f->NewScissorTest = ST_NEW_SCISSOR | ST_NEW_RASTERIZER;
-   f->NewAlphaTest = ST_NEW_DSA;
-   f->NewBlend = ST_NEW_BLEND;
-   f->NewBlendColor = ST_NEW_BLEND_COLOR;
-   f->NewColorMask = ST_NEW_BLEND;
-   f->NewDepth = ST_NEW_DSA;
-   f->NewLogicOp = ST_NEW_BLEND;
-   f->NewStencil = ST_NEW_DSA;
-   f->NewMultisampleEnable = ST_NEW_BLEND | ST_NEW_RASTERIZER |
- ST_NEW_SAMPLE_MASK | ST_NEW_SAMPLE_SHADING;
-   f->NewSampleAlphaToXEnable = ST_NEW_BLEND;
-   f->NewSampleMask = ST_NEW_SAMPLE_MASK;
-   f->NewSampleShading = 

[Mesa-dev] [PATCH 2/2] st/mesa: move st_manager_destroy() earlier in file

[Brian Paul]

To avoid forward declaration.
---
 src/mesa/state_tracker/st_manager.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index aedbc13..8a933d4 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -69,7 +69,6 @@ struct st_manager_private
mtx_t st_mutex;
 };
 
-static void st_manager_destroy(struct st_manager *);
 
 /**
  * Map an attachment to a buffer index.
@@ -794,6 +793,21 @@ st_thread_finish(struct st_context_iface *stctxi)
_mesa_glthread_finish(st->ctx);
 }
 
+
+static void
+st_manager_destroy(struct st_manager *smapi)
+{
+   struct st_manager_private *smPriv = smapi->st_manager_private;
+
+   if (smPriv && smPriv->stfbi_ht) {
+  _mesa_hash_table_destroy(smPriv->stfbi_ht, NULL);
+  mtx_destroy(>st_mutex);
+  free(smPriv);
+  smapi->st_manager_private = NULL;
+   }
+}
+
+
 static struct st_context_iface *
 st_api_create_context(struct st_api *stapi, struct st_manager *smapi,
   const struct st_context_attribs *attribs,
@@ -1148,18 +1162,6 @@ st_manager_add_color_renderbuffer(struct st_context *st,
return TRUE;
 }
 
-static void
-st_manager_destroy(struct st_manager *smapi)
-{
-   struct st_manager_private *smPriv = smapi->st_manager_private;
-
-   if (smPriv && smPriv->stfbi_ht) {
-  _mesa_hash_table_destroy(smPriv->stfbi_ht, NULL);
-  mtx_destroy(>st_mutex);
-  free(smPriv);
-  smapi->st_manager_private = NULL;
-   }
-}
 
 static unsigned
 get_version(struct pipe_screen *screen,
-- 
1.9.1

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

Re: [Mesa-dev] [PATCH 16/17] util: Add Mesa ARB_get_program_binary helper functions

[Jordan Justen]

On 2017-11-09 19:40:40, Jordan Justen wrote:
> On 2017-11-09 08:07:57, Jose Fonseca wrote:
> > On 09/11/17 13:19, Emil Velikov wrote:
> > > On 9 November 2017 at 06:42, Jordan Justen  
> > > wrote:
> > >> Signed-off-by: Jordan Justen 
> > > Currently zlib is a dependency for !WIndows platforms.
> > > With this patch we add it to the Windows builds.
> > > 
> > > Brian, Jose any ideas how we can get zlib on Windows?
> > > 
> > > Thanks
> > > Emil
> > > 
> > 
> > Thanks for the heads up Emil!
> > 
> > The most effective way to get zlib on Windows would be to bundle the 
> > source code in mesa/src/zlib.
> > 
> > But it would be much simpler we did not add zlib as a required dependency.
> > 
> > Could we use some other checksum/hash?
> > 
> > Or instead of bundling the whole zlib, we could just bundle crc 
> > implementation.  I'm sure there are many BDS/MIT licensed out there. 
> > I've used some in apitrace -- 
> > https://github.com/apitrace/apitrace/tree/master/thirdparty/crc32c
> 
> We have bundled crc32 already.
> 
> I compress the program, but it is optional, and compression is not
> used if it actually doesn't produce a smaller result. I'll update the
> series such that if zlib is not available, then we'll always produce
> an uncompressed result.

Well, this plan pretty much ran off the tracks when I tried to make
the shader cache binary optionally compressed as well. :)

I guess I'll just not build this on windows like disk_cache.

Or ... as Tim suggested on irc, I could just not compress it. The data
is very compressible, so should we just trust that the application
probably will try to compress the returned binary?

For reference, I don't think anv bothers to compress the pipeline
binary...

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 17/21] intel/nir: Add a helper for getting the NoIndirect mask

[Timothy Arceri]

On 11/11/17 12:28, Andres Gomez wrote:

Jason, this series of nominated commits landed without mentioning any
specific stable queue.

 From what I'm seeing, they depend on 379b24a40d3 which didn't make it
for 17.2 so I'm dropping the 3 of them for that queue:

7364f080f9a272323ed3491f278a1eed3eb9b1a7 (intel/nir: Add a helper for getting 
the NoIndirect mask)
3e63cf893f096a7263eb1856d58417dd2d170d4b (intel/nir: Break the linking code 
into a helper in brw_nir.c)
951a5dc4cc29da996b54ae63eeba1915a3a65b4a (intel/nir: Use the correct indirect 
lowering masks in link_shaders)

Let me know what you think.


Yeah these should only be needed in 17.3




On Sat, 2017-10-28 at 11:36 -0700, Jason Ekstrand wrote:

Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/compiler/brw_nir.c | 33 +++--
  1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index e5ff6de..2d4ab50 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -521,18 +521,29 @@ brw_nir_lower_cs_shared(nir_shader *nir)
 this_progress;  \
  })
  
-nir_shader *

-brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
- bool is_scalar)
+static nir_variable_mode
+brw_nir_no_indirect_mask(const struct brw_compiler *compiler,
+ gl_shader_stage stage)
  {
 nir_variable_mode indirect_mask = 0;
-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectInput)
+
+   if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
indirect_mask |= nir_var_shader_in;
-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectOutput)
+   if (compiler->glsl_compiler_options[stage].EmitNoIndirectOutput)
indirect_mask |= nir_var_shader_out;
-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectTemp)
+   if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
indirect_mask |= nir_var_local;
  
+   return indirect_mask;

+}
+
+nir_shader *
+brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
+ bool is_scalar)
+{
+   nir_variable_mode indirect_mask =
+  brw_nir_no_indirect_mask(compiler, nir->info.stage);
+
 bool progress;
 do {
progress = false;
@@ -639,14 +650,8 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
nir_shader *nir)
  
 OPT(nir_lower_clip_cull_distance_arrays);
  
-   nir_variable_mode indirect_mask = 0;

-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectInput)
-  indirect_mask |= nir_var_shader_in;
-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectOutput)
-  indirect_mask |= nir_var_shader_out;
-   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectTemp)
-  indirect_mask |= nir_var_local;
-
+   nir_variable_mode indirect_mask =
+  brw_nir_no_indirect_mask(compiler, nir->info.stage);
 nir_lower_indirect_derefs(nir, indirect_mask);
  
 nir_lower_int64(nir, nir_lower_imul64 |

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 17/21] intel/nir: Add a helper for getting the NoIndirect mask

[Andres Gomez]

Jason, this series of nominated commits landed without mentioning any
specific stable queue.

From what I'm seeing, they depend on 379b24a40d3 which didn't make it
for 17.2 so I'm dropping the 3 of them for that queue:

7364f080f9a272323ed3491f278a1eed3eb9b1a7 (intel/nir: Add a helper for getting 
the NoIndirect mask)
3e63cf893f096a7263eb1856d58417dd2d170d4b (intel/nir: Break the linking code 
into a helper in brw_nir.c)
951a5dc4cc29da996b54ae63eeba1915a3a65b4a (intel/nir: Use the correct indirect 
lowering masks in link_shaders)

Let me know what you think.


On Sat, 2017-10-28 at 11:36 -0700, Jason Ekstrand wrote:
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/intel/compiler/brw_nir.c | 33 +++--
>  1 file changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
> index e5ff6de..2d4ab50 100644
> --- a/src/intel/compiler/brw_nir.c
> +++ b/src/intel/compiler/brw_nir.c
> @@ -521,18 +521,29 @@ brw_nir_lower_cs_shared(nir_shader *nir)
> this_progress;  \
>  })
>  
> -nir_shader *
> -brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
> - bool is_scalar)
> +static nir_variable_mode
> +brw_nir_no_indirect_mask(const struct brw_compiler *compiler,
> + gl_shader_stage stage)
>  {
> nir_variable_mode indirect_mask = 0;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectInput)
> +
> +   if (compiler->glsl_compiler_options[stage].EmitNoIndirectInput)
>indirect_mask |= nir_var_shader_in;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectOutput)
> +   if (compiler->glsl_compiler_options[stage].EmitNoIndirectOutput)
>indirect_mask |= nir_var_shader_out;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectTemp)
> +   if (compiler->glsl_compiler_options[stage].EmitNoIndirectTemp)
>indirect_mask |= nir_var_local;
>  
> +   return indirect_mask;
> +}
> +
> +nir_shader *
> +brw_nir_optimize(nir_shader *nir, const struct brw_compiler *compiler,
> + bool is_scalar)
> +{
> +   nir_variable_mode indirect_mask =
> +  brw_nir_no_indirect_mask(compiler, nir->info.stage);
> +
> bool progress;
> do {
>progress = false;
> @@ -639,14 +650,8 @@ brw_preprocess_nir(const struct brw_compiler *compiler, 
> nir_shader *nir)
>  
> OPT(nir_lower_clip_cull_distance_arrays);
>  
> -   nir_variable_mode indirect_mask = 0;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectInput)
> -  indirect_mask |= nir_var_shader_in;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectOutput)
> -  indirect_mask |= nir_var_shader_out;
> -   if (compiler->glsl_compiler_options[nir->info.stage].EmitNoIndirectTemp)
> -  indirect_mask |= nir_var_local;
> -
> +   nir_variable_mode indirect_mask =
> +  brw_nir_no_indirect_mask(compiler, nir->info.stage);
> nir_lower_indirect_derefs(nir, indirect_mask);
>  
> nir_lower_int64(nir, nir_lower_imul64 |
-- 
Br,

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

Re: [Mesa-dev] [PATCH] st/program: fix compute shader nir references

[Timothy Arceri]

Reviewed-by: Timothy Arceri 

On 11/11/17 00:46, Rob Clark wrote:

In case the IR is NIR, the driver takes reference to the nir_shader.
Also, because there are no variants, we need to clone the shader,
instead of sharing the reference with gl_program, which would result
in a double free in _mesa_delete_program().

Signed-off-by: Rob Clark 
Reviewed-by: Marek Olšák 
---
This shuffled around a bit and grew an extra fix after c980a3aa
"st/glsl_to_nir: generate NIR earlier"

  src/mesa/state_tracker/st_glsl_to_nir.cpp | 14 ++
  src/mesa/state_tracker/st_program.c   | 16 ++--
  2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 7f4651a3ccd..1912da2404a 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -441,34 +441,40 @@ st_nir_get_mesa_program(struct gl_context *ctx,
 struct st_fragment_program *stfp;
 struct st_compute_program *stcp;
  
+   nir_shader *nir = st_glsl_to_nir(st, prog, shader_program, shader->Stage);

+
 switch (shader->Stage) {
 case MESA_SHADER_VERTEX:
stvp = (struct st_vertex_program *)prog;
stvp->shader_program = shader_program;
+  stvp->tgsi.type = PIPE_SHADER_IR_NIR;
+  stvp->tgsi.ir.nir = nir;
break;
 case MESA_SHADER_GEOMETRY:
 case MESA_SHADER_TESS_CTRL:
 case MESA_SHADER_TESS_EVAL:
stp = (struct st_common_program *)prog;
stp->shader_program = shader_program;
+  stp->tgsi.type = PIPE_SHADER_IR_NIR;
+  stp->tgsi.ir.nir = nir;
break;
 case MESA_SHADER_FRAGMENT:
stfp = (struct st_fragment_program *)prog;
stfp->shader_program = shader_program;
+  stfp->tgsi.type = PIPE_SHADER_IR_NIR;
+  stfp->tgsi.ir.nir = nir;
break;
 case MESA_SHADER_COMPUTE:
stcp = (struct st_compute_program *)prog;
stcp->shader_program = shader_program;
+  stcp->tgsi.ir_type = PIPE_SHADER_IR_NIR;
+  stcp->tgsi.prog = nir_shader_clone(NULL, nir);
break;
 default:
assert(!"should not be reached");
return NULL;
 }
  
-   struct st_common_program *st_comm_prog = (struct st_common_program *)prog;

-   nir_shader *nir = st_glsl_to_nir(st, prog, shader_program, shader->Stage);
-   st_comm_prog->tgsi.type = PIPE_SHADER_IR_NIR;
-   st_comm_prog->tgsi.ir.nir = nir;
  
 return prog;

  }
diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index e3649a8b7cc..b0c69f30c15 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -360,8 +360,20 @@ st_release_cp_variants(struct st_context *st, struct 
st_compute_program *stcp)
 *variants = NULL;
  
 if (stcp->tgsi.prog) {

-  ureg_free_tokens(stcp->tgsi.prog);
-  stcp->tgsi.prog = NULL;
+  switch (stcp->tgsi.ir_type) {
+  case PIPE_SHADER_IR_TGSI:
+ ureg_free_tokens(stcp->tgsi.prog);
+ stcp->tgsi.prog = NULL;
+ break;
+  case PIPE_SHADER_IR_NIR:
+ /* pipe driver took ownership of prog */
+ break;
+  case PIPE_SHADER_IR_LLVM:
+  case PIPE_SHADER_IR_NATIVE:
+ /* ??? */
+  stcp->tgsi.prog = NULL;
+ break;
+  }
 }
  }
  


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

Re: [Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Jordan Justen]

On 2017-11-10 16:46:32, Matt Turner wrote:
> On Fri, Nov 10, 2017 at 4:44 PM, Timothy Arceri  wrote:
> > On 11/11/17 08:49, Jordan Justen wrote:
> >>
> >> On 2017-11-10 13:15:10, Matt Turner wrote:
> >>>
> >>> Why?
> >>
> >>
> >> For patch 4. Patch 4 can't happen unless zlib is optional because it's
> >> a pain to enable zlib on windows.
> >>
> >> No surprise, but the disk cache actually works without zlib. (Of
> >> course, Tim originally implemented it without compression.)
> >
> >
> > To be honest i really don't like this. Without compression the disk cache is
> > not great, for example Deus Ex shaders took up around 130MB (over 1/10 of
> > the default cache size). IMO we should just disable building the cache when
> > zlib is not found ... actually I'm pretty sure building this is already
> > disabled on windows because its very unixy.
> 
> I'm in favor of requiring zlib for the shader cache as well.

I didn't think anyone would ever have used shader cache with it
disabled. (Well, maybe someone would use it on windows, but nobody
that matters. :)

Anyway, I'll just drop this series and revise the program-binary code
to not build on windows (like disk_cache.c) since it also uses zlib.

Maybe if we get windows builds moved from scons to meson then we can
depend on zlib unconditionally and build these on windows as well.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] intel/fs: Use a pure vertical stride for large register strides

[Andres Gomez]

On Fri, 2017-11-10 at 16:26 -0800, Jason Ekstrand wrote:
> On Fri, Nov 10, 2017 at 4:12 PM, Andres Gomez 
> wrote:
> > Jason, having this into account, I'll leave this patch out of 17.2
> > so
> > far we don't have another one that fixes this regression (?)
> 
> This patch doesn't regress anything, it just isn't sufficient to fix
> the bug on little-core.

OK, so I clearly misunderstood Matt's message.

Thanks for the prompt answer! ☺


> 
> --Jason
>  
> > I noticed that the patch bisected by Mark is a different one so I'm
> > not
> > sure I'm understanding the status, though.
> > 
> > Let me know what you think.
> > 
> > On Thu, 2017-11-09 at 17:01 -0800, Jason Ekstrand wrote:
> > > On Thu, Nov 9, 2017 at 2:23 PM, Matt Turner 
> > wrote:
> > > > On Thu, Nov 2, 2017 at 3:54 PM, Jason Ekstrand  > d.net> wrote:
> > > > > Register strides higher than 4 are uncommon but they can
> > happen.  For
> > > > > instance, if you have a 64-bit extract_u8 operation, we turn
> > that into
> > > > > UB -> UQ MOV with a source stride of 8.  Our previous
> > calculation would
> > > > > try to generate a stride of <32;8,8>:ub which is invalid
> > because the
> > > > > maximum horizontal stride is 4.  To solve this problem, we
> > instead use a
> > > > > stride of <8;1,0>.  As noted in the comment, this does not
> > work as a
> > > > > destination but that's ok as very few things actually
> > generate that
> > > > > stride.
> > > >
> > > > Please put the tests you fixed in the commit message. It's not
> > okay to
> > > > leave that out for all the reasons that I'm sure you know.
> > >
> > > I didn't because the test passes before and after the patch.  I
> > guess I could have included that information though.
> > >
> > > > Looks like this doesn't work on CHV, BXT, GLK :(
> > > >
> > > > KHR-GL46.shader_ballot_tests.ShaderBallotBitmasks now fails on
> > CHV,
> > > > BXT, GLK with:
> > > >
> > > > mov(8)  g21<1>UQg19<8,1,0>UB   
> > { align1 1Q };
> > > > ERROR: Source and destination horizontal stride must
> > equal and
> > > > a multiple of a qword when the execution type is 64-bit
> > > > ERROR: Vstride must be Width * Hstride when the
> > execution type is 64-bit
> > > >
> > > > Modulo the typo in the first error, I think both of these are
> > correct.
> > > > I don't think we can extract_u8 to a 64-bit type on Atom :(
> > >
> > > That's unfortunate...  Quickly racking my brain, I don't see a
> > slick way to implement that opcode.  How would you feel about some
> > late opt_algebraic lowering?
> > >
> > > > This is filed as https://bugs.freedesktop.org/show_bug.cgi?id=1
> > 03628
> > >
> > > ___
> > > mesa-stable mailing list
> > > mesa-sta...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> > --
> > Br,
> > 
> > Andres
> 
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
-- 
Br,

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

[Mesa-dev] [PATCH 2/2] intel/tools: Fix program disassembly in aubinator_error_decode.

[Kenneth Graunke]

This indexing is bogus.  idx_program is the offset of the next program.
At this point, we've walked through the entire batch, and accumulated
all the programs.  So adding it again simply skips over 100% of the
programs.
---
 src/intel/tools/aubinator_error_decode.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index 2322bac8391..00e1a872bd0 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -601,15 +601,14 @@ read_data_file(FILE *file)
 printf("Disassembly of programs in instruction buffer at "
"0x%08"PRIx64":\n", gtt_offset);
 for (int i = 0; i < num_programs; i++) {
-   int idx = (idx_program + i) % MAX_NUM_PROGRAMS;
-   if (programs[idx].instruction_base_address == gtt_offset) {
+   if (programs[i].instruction_base_address == gtt_offset) {
 printf("\n%s (specified by %s at batch offset "
"0x%08"PRIx64") at offset 0x%08"PRIx64"\n",
-   programs[idx].type,
-   programs[idx].command,
-   programs[idx].command_offset,
-   programs[idx].ksp);
-gen_disasm_disassemble(disasm, data, programs[idx].ksp,
+   programs[i].type,
+   programs[i].command,
+   programs[i].command_offset,
+   programs[i].ksp);
+gen_disasm_disassemble(disasm, data, programs[i].ksp,
stdout);
}
 }
-- 
2.15.0

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

[Mesa-dev] [PATCH 1/2] intel/tools: Fix detection of enabled shader stages.

[Kenneth Graunke]

We renamed "Function Enable" to "Enable", which broke our detection
of whether shaders are enabled or not.  So, we'd see a bunch of HS/DS
packets with program offsets of 0, and think that was a valid TCS/TES.

Fixes: c032cae9ff77e (genxml: Rename "Function Enable" to "Enable".)
---
 src/intel/tools/aubinator_error_decode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/tools/aubinator_error_decode.c 
b/src/intel/tools/aubinator_error_decode.c
index 4035723b87d..2322bac8391 100644
--- a/src/intel/tools/aubinator_error_decode.c
+++ b/src/intel/tools/aubinator_error_decode.c
@@ -367,7 +367,7 @@ static void decode(struct gen_spec *spec,
is_simd8 = strcmp(iter.value, "true") == 0;
 } else if (strcmp(iter.name, "Dispatch Enable") == 0) {
is_simd8 = strcmp(iter.value, "SIMD8") == 0;
-} else if (strcmp(iter.name, "Function Enable") == 0) {
+} else if (strcmp(iter.name, "Enable") == 0) {
is_enabled = strcmp(iter.value, "true") == 0;
 }
  }
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Matt Turner]

On Fri, Nov 10, 2017 at 4:44 PM, Timothy Arceri  wrote:
> On 11/11/17 08:49, Jordan Justen wrote:
>>
>> On 2017-11-10 13:15:10, Matt Turner wrote:
>>>
>>> Why?
>>
>>
>> For patch 4. Patch 4 can't happen unless zlib is optional because it's
>> a pain to enable zlib on windows.
>>
>> No surprise, but the disk cache actually works without zlib. (Of
>> course, Tim originally implemented it without compression.)
>
>
> To be honest i really don't like this. Without compression the disk cache is
> not great, for example Deus Ex shaders took up around 130MB (over 1/10 of
> the default cache size). IMO we should just disable building the cache when
> zlib is not found ... actually I'm pretty sure building this is already
> disabled on windows because its very unixy.

I'm in favor of requiring zlib for the shader cache as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Timothy Arceri]

On 11/11/17 08:49, Jordan Justen wrote:

On 2017-11-10 13:15:10, Matt Turner wrote:

Why?


For patch 4. Patch 4 can't happen unless zlib is optional because it's
a pain to enable zlib on windows.

No surprise, but the disk cache actually works without zlib. (Of
course, Tim originally implemented it without compression.)


To be honest i really don't like this. Without compression the disk 
cache is not great, for example Deus Ex shaders took up around 130MB 
(over 1/10 of the default cache size). IMO we should just disable 
building the cache when zlib is not found ... actually I'm pretty sure 
building this is already disabled on windows because its very unixy.


Not having compression is fine for the program binary extension but I'd 
rather not do it for the disk cache.




-Jordan


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

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Zhang, Boyuan]

-Original Message-
From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On Behalf Of 
Christian König
Sent: November-09-17 12:19 PM
To: Mark Thompson; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header 
implementations

Am 09.11.2017 um 17:57 schrieb Mark Thompson:
>> On 08/11/17 18:08, boyuan.zh...@amd.com wrote:
>>> From: Boyuan Zhang 
>>>
>>> Implement encoding of sps, pps, and silce headers using the newly 
>>> added h.264 header coding descriptors functions based on h.264 specs.
>>>
>>> Signed-off-by: Boyuan Zhang 
>>> ---
>>>   src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 234 
>>> 
>>>   1 file changed, 234 insertions(+)
>> So, does this mean we could actually implement VAAPI encode properly with 
>> packed headers now rather than hard-coding all of this in the driver?

[Boyuan] Generally speaking, we are doing part of the slice header encoding 
work in driver side now. Previously for vce encode, all those works are done by 
firmware, and driver only provides required variables . Now for vcn encode, 
both driver and firmware do part of the work, and at the end firmware generate 
the entire slice header. For example, one of the questions you asked below that 
"who will set the value for slice_qp_delta?" It's actually that firmware will 
set the value, while driver side needs to instructs it. So in conclusion, we 
can't encode everything in driver side. All other questions/comments are 
answered below.

> At least that's the intention here.
> 
> BTW: Boyuan we already have a bitstream write in picture_mpeg4.c in the VA 
> state tracker.
> 
> Please unify all that stuff in a header in src/gallium/auxiliary/vl/.
> 
> Regards,
> Christian.

[Boyuan] I see. I would like to create a separate patch and move those stuff 
after these bringup patches set, does it sound fine to you? 

>>
>>> diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
>>> b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
>>> index 5170c67..c6dc420 100644
>>> --- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
>>> +++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
>>> @@ -362,6 +362,233 @@ static void radeon_enc_quality_params(struct 
>>> radeon_encoder *enc)
>>> RADEON_ENC_END();
>>>   }
>>>   
>>> +static void radeon_enc_nalu_sps(struct radeon_encoder *enc) {
>>> +   RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
>>> +   RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
>>> +   uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
>>> +   radeon_enc_reset(enc);
>>> +   radeon_enc_set_emulation_prevention(enc, false);
>>> +   radeon_enc_code_fixed_bits(enc, 0x0001, 32);
>>> +   radeon_enc_code_fixed_bits(enc, 0x67, 8);
>>> +   radeon_enc_byte_align(enc);
>>> +   radeon_enc_set_emulation_prevention(enc, true);
>>> +   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
>>> +   radeon_enc_code_fixed_bits(enc, 0x04, 8);
> >Please always set constraint_set1_flag when profile_idc is 66.  There are 
> >enough actually-constrained-baseline-but-not-marked-as-such streams in the 
> >world already to catch out decoders without full baseline support (that is, 
> >all of them).
>>
> >Also, "constraint_set5_flag shall be equal to 0 when profile_idc is not 
> >equal to 77, 88, 100, or 118".

[Boyuan] Thanks for pointing out. I modified the value to be 0x44 in the new 
patch (set1=1, and set5=1) since we only support constrained baseline for now.

>>
>>> +   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.level_idc, 8);
>>> +   radeon_enc_code_ue(enc, 0x0);
>>> +
>>> +   if(enc->enc_pic.spec_misc.profile_idc == 100 || 
>>> enc->enc_pic.spec_misc.profile_idc == 110 || 
>>> enc->enc_pic.spec_misc.profile_idc == 122 ||
>>> +   enc->enc_pic.spec_misc.profile_idc == 244 || 
>>> enc->enc_pic.spec_misc.profile_idc == 44 || 
>>> enc->enc_pic.spec_misc.profile_idc == 83 ||
>>> +   enc->enc_pic.spec_misc.profile_idc == 86 || 
>>> enc->enc_pic.spec_misc.profile_idc == 118 || 
>>> enc->enc_pic.spec_misc.profile_idc == 128 ||
>>> +   enc->enc_pic.spec_misc.profile_idc == 138) {
>>> +   radeon_enc_code_ue(enc, 0x1);
>>> +   radeon_enc_code_ue(enc, 0x0);
>>> +   radeon_enc_code_ue(enc, 0x0);
>>> +   radeon_enc_code_fixed_bits(enc, 0x0, 2);
>>> +   }
>>> +
>>> +   radeon_enc_code_ue(enc, 1);
>>> +   radeon_enc_code_ue(enc, enc->enc_pic.pic_order_cnt_type);
>>> +
>>> +   if (enc->enc_pic.pic_order_cnt_type == 0)
>>> +   radeon_enc_code_ue(enc, 1);
>> POC type can be 1 as well, which has more associated syntax.

[Boyuan] For now, we only support 0 and 2. And the implicit "else" is for 
poc_type==2 case.

>>
>>> +
>>> +   radeon_enc_code_ue(enc, (enc->base.max_references + 1));
>>> +   radeon_enc_code_fixed_bits(enc, 
>>> enc->enc_pic.layer_ctrl.max_num_temporal_layers > 1 

Re: [Mesa-dev] [PATCH 10/18] radeon/vcn: add encode header implementations

[Zhang, Boyuan]

From: Boyuan Zhang 

Implement encoding of sps, pps, and silce headers using the newly added h.264 
header coding descriptors functions based on h.264 specs.

Signed-off-by: Boyuan Zhang 
---
 src/gallium/drivers/radeon/radeon_vcn_enc.h |   1 +
 src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c | 240 
 2 files changed, 241 insertions(+)

diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc.h 
b/src/gallium/drivers/radeon/radeon_vcn_enc.h
index c04652b..0385860 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc.h
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc.h
@@ -346,6 +346,7 @@ struct radeon_enc_h264_enc_pic {
 
boolnot_referenced;
boolis_idr;
+   boolis_even_frame;
 
rvcn_enc_task_info_ttask_info;
rvcn_enc_session_init_t session_init;
diff --git a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c 
b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
index 5170c67..b985921 100644
--- a/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
+++ b/src/gallium/drivers/radeon/radeon_vcn_enc_1_2.c
@@ -362,6 +362,239 @@ static void radeon_enc_quality_params(struct 
radeon_encoder *enc)
RADEON_ENC_END();
 }
 
+static void radeon_enc_nalu_sps(struct radeon_encoder *enc)
+{
+   RADEON_ENC_BEGIN(RENCODE_IB_PARAM_DIRECT_OUTPUT_NALU);
+   RADEON_ENC_CS(RENCODE_DIRECT_OUTPUT_NALU_TYPE_SPS);
+   uint32_t *size_in_bytes = >cs->current.buf[enc->cs->current.cdw++];
+   radeon_enc_reset(enc);
+   radeon_enc_set_emulation_prevention(enc, false);
+   radeon_enc_code_fixed_bits(enc, 0x0001, 32);
+   radeon_enc_code_fixed_bits(enc, 0x67, 8);
+   radeon_enc_byte_align(enc);
+   radeon_enc_set_emulation_prevention(enc, true);
+   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.profile_idc, 8);
+   radeon_enc_code_fixed_bits(enc, 0x44, 8); //hardcode to constrained 
baseline
+   radeon_enc_code_fixed_bits(enc, enc->enc_pic.spec_misc.level_idc, 8);
+   radeon_enc_code_ue(enc, 0x0);
+
+   if(enc->enc_pic.spec_misc.profile_idc == 100 || 
enc->enc_pic.spec_misc.profile_idc == 110 || enc->enc_pic.spec_misc.profile_idc 
== 122 ||
+   enc->enc_pic.spec_misc.profile_idc == 244 || 
enc->enc_pic.spec_misc.profile_idc == 44 || enc->enc_pic.spec_misc.profile_idc 
== 83 ||
+   enc->enc_pic.spec_misc.profile_idc == 86 || 
enc->enc_pic.spec_misc.profile_idc == 118 || enc->enc_pic.spec_misc.profile_idc 
== 128 ||
+   enc->enc_pic.spec_misc.profile_idc == 138) {
+   radeon_enc_code_ue(enc, 0x1);
+   radeon_enc_code_ue(enc, 0x0);
+   radeon_enc_code_ue(enc, 0x0);
+   radeon_enc_code_fixed_bits(enc, 0x0, 2);
+   }
+
+   radeon_enc_code_ue(enc, 1);
+   radeon_enc_code_ue(enc, enc->enc_pic.pic_order_cnt_type);
+
+   if (enc->enc_pic.pic_order_cnt_type == 0)
+   radeon_enc_code_ue(enc, 1);
+
+   radeon_enc_code_ue(enc, (enc->base.max_references + 1));
+   radeon_enc_code_fixed_bits(enc, 
enc->enc_pic.layer_ctrl.max_num_temporal_layers > 1 ? 0x1 : 0x0, 1);
+   radeon_enc_code_ue(enc, 
(enc->enc_pic.session_init.aligned_picture_width / 16 - 1));
+   radeon_enc_code_ue(enc, 
(enc->enc_pic.session_init.aligned_picture_height / 16 - 1));
+   bool progressive_only = true;
+   radeon_enc_code_fixed_bits(enc, progressive_only ? 0x1 : 0x0, 1);
+
+   if (!progressive_only)
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+
+   radeon_enc_code_fixed_bits(enc, 0x1, 1);
+
+   if ((enc->enc_pic.crop_left != 0) || (enc->enc_pic.crop_right != 0) ||
+   (enc->enc_pic.crop_top != 0) || 
(enc->enc_pic.crop_bottom != 0)) {
+   radeon_enc_code_fixed_bits(enc, 0x1, 1);
+   radeon_enc_code_ue(enc, enc->enc_pic.crop_left);
+   radeon_enc_code_ue(enc, enc->enc_pic.crop_right);
+   radeon_enc_code_ue(enc, enc->enc_pic.crop_top);
+   radeon_enc_code_ue(enc, enc->enc_pic.crop_bottom);
+   } else
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+
+   radeon_enc_code_fixed_bits(enc, 0x1, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x0, 1);
+   radeon_enc_code_fixed_bits(enc, 0x1, 1);
+   radeon_enc_code_fixed_bits(enc, 0x1, 1);
+   radeon_enc_code_ue(enc, 0x0);
+   radeon_enc_code_ue(enc, 0x0);
+   radeon_enc_code_ue(enc, 16);
+   radeon_enc_code_ue(enc, 16);
+   radeon_enc_code_ue(enc, 0x0);
+   radeon_enc_code_ue(enc, (enc->base.max_references + 1));

Re: [Mesa-dev] [Mesa-stable] [PATCH] intel/fs: Use a pure vertical stride for large register strides

[Jason Ekstrand]

On Fri, Nov 10, 2017 at 4:12 PM, Andres Gomez  wrote:

> Jason, having this into account, I'll leave this patch out of 17.2 so
> far we don't have another one that fixes this regression (?)
>

This patch doesn't regress anything, it just isn't sufficient to fix the
bug on little-core.

--Jason


> I noticed that the patch bisected by Mark is a different one so I'm not
> sure I'm understanding the status, though.
>
> Let me know what you think.
>
> On Thu, 2017-11-09 at 17:01 -0800, Jason Ekstrand wrote:
> > On Thu, Nov 9, 2017 at 2:23 PM, Matt Turner  wrote:
> > > On Thu, Nov 2, 2017 at 3:54 PM, Jason Ekstrand 
> wrote:
> > > > Register strides higher than 4 are uncommon but they can happen.  For
> > > > instance, if you have a 64-bit extract_u8 operation, we turn that
> into
> > > > UB -> UQ MOV with a source stride of 8.  Our previous calculation
> would
> > > > try to generate a stride of <32;8,8>:ub which is invalid because the
> > > > maximum horizontal stride is 4.  To solve this problem, we instead
> use a
> > > > stride of <8;1,0>.  As noted in the comment, this does not work as a
> > > > destination but that's ok as very few things actually generate that
> > > > stride.
> > >
> > > Please put the tests you fixed in the commit message. It's not okay to
> > > leave that out for all the reasons that I'm sure you know.
> >
> > I didn't because the test passes before and after the patch.  I guess I
> could have included that information though.
> >
> > > Looks like this doesn't work on CHV, BXT, GLK :(
> > >
> > > KHR-GL46.shader_ballot_tests.ShaderBallotBitmasks now fails on CHV,
> > > BXT, GLK with:
> > >
> > > mov(8)  g21<1>UQg19<8,1,0>UB{
> align1 1Q };
> > > ERROR: Source and destination horizontal stride must equal and
> > > a multiple of a qword when the execution type is 64-bit
> > > ERROR: Vstride must be Width * Hstride when the execution type
> is 64-bit
> > >
> > > Modulo the typo in the first error, I think both of these are correct.
> > > I don't think we can extract_u8 to a 64-bit type on Atom :(
> >
> > That's unfortunate...  Quickly racking my brain, I don't see a slick way
> to implement that opcode.  How would you feel about some late opt_algebraic
> lowering?
> >
> > > This is filed as https://bugs.freedesktop.org/show_bug.cgi?id=103628
> >
> > ___
> > mesa-stable mailing list
> > mesa-sta...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-stable
> --
> Br,
>
> Andres
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] intel/fs: Use a pure vertical stride for large register strides

[Andres Gomez]

Jason, having this into account, I'll leave this patch out of 17.2 so
far we don't have another one that fixes this regression (?)

I noticed that the patch bisected by Mark is a different one so I'm not
sure I'm understanding the status, though.

Let me know what you think.

On Thu, 2017-11-09 at 17:01 -0800, Jason Ekstrand wrote:
> On Thu, Nov 9, 2017 at 2:23 PM, Matt Turner  wrote:
> > On Thu, Nov 2, 2017 at 3:54 PM, Jason Ekstrand  wrote:
> > > Register strides higher than 4 are uncommon but they can happen.  For
> > > instance, if you have a 64-bit extract_u8 operation, we turn that into
> > > UB -> UQ MOV with a source stride of 8.  Our previous calculation would
> > > try to generate a stride of <32;8,8>:ub which is invalid because the
> > > maximum horizontal stride is 4.  To solve this problem, we instead use a
> > > stride of <8;1,0>.  As noted in the comment, this does not work as a
> > > destination but that's ok as very few things actually generate that
> > > stride.
> > 
> > Please put the tests you fixed in the commit message. It's not okay to
> > leave that out for all the reasons that I'm sure you know.
> 
> I didn't because the test passes before and after the patch.  I guess I could 
> have included that information though.
>  
> > Looks like this doesn't work on CHV, BXT, GLK :(
> > 
> > KHR-GL46.shader_ballot_tests.ShaderBallotBitmasks now fails on CHV,
> > BXT, GLK with:
> > 
> > mov(8)  g21<1>UQg19<8,1,0>UB{ align1 1Q 
> > };
> > ERROR: Source and destination horizontal stride must equal and
> > a multiple of a qword when the execution type is 64-bit
> > ERROR: Vstride must be Width * Hstride when the execution type is 
> > 64-bit
> > 
> > Modulo the typo in the first error, I think both of these are correct.
> > I don't think we can extract_u8 to a 64-bit type on Atom :(
> 
> That's unfortunate...  Quickly racking my brain, I don't see a slick way to 
> implement that opcode.  How would you feel about some late opt_algebraic 
> lowering?
>  
> > This is filed as https://bugs.freedesktop.org/show_bug.cgi?id=103628
> 
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
-- 
Br,

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

Re: [Mesa-dev] [PATCH 05/10] nir: Use well-known power-of-two test instead of util_bitscan

[Matt Turner]

On Fri, Nov 10, 2017 at 4:02 PM, Ian Romanick  wrote:
> On 11/10/2017 04:54 PM, Matt Turner wrote:
>> On Fri, Nov 10, 2017 at 2:32 PM, Ian Romanick  wrote:
>>> From: Ian Romanick 
>>>
>>> This prevents the next change from breaking the build, and I felt that
>>> it was different enough from the rest of that patch to stand on its own.
>>>
>>> Signed-off-by: Ian Romanick 
>>> ---
>>>  src/compiler/nir/nir_validate.c | 5 +++--
>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/compiler/nir/nir_validate.c 
>>> b/src/compiler/nir/nir_validate.c
>>> index 9bf8c70..ca191d2 100644
>>> --- a/src/compiler/nir/nir_validate.c
>>> +++ b/src/compiler/nir/nir_validate.c
>>> @@ -979,8 +979,9 @@ validate_var_decl(nir_variable *var, bool is_global, 
>>> validate_state *state)
>>>
>>> validate_assert(state, is_global == nir_variable_is_global(var));
>>>
>>> -   /* Must have exactly one mode set */
>>> -   validate_assert(state, util_bitcount(var->data.mode) == 1);
>>> +   /* Must have exactly one mode set (i.e., is a power of two) */
>>> +   validate_assert(state, (var->data.mode != 0 &&
>>> +   !(var->data.mode & (var->data.mode - 1;
>>
>> We actually have two functions in Mesa for this: util_is_power_of_two
>> and _mesa_is_pow_two. Not sure which one is available to this code,
>> but assuming one is, we should use it.
>
> I don't think either is available in its current location, but I'd be in
> favor of having only one in a new location that is always available.
> Any suggestion where that might be?

src/util/... maybe src/util/bitscan.h? Seems like an okay place for it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] mesa/st: add missing copyright headers to memoryobjects files

[Andres Rodriguez]

Signed-off-by: Andres Rodriguez 
---
 src/mesa/state_tracker/st_cb_memoryobjects.c | 24 
 src/mesa/state_tracker/st_cb_memoryobjects.h | 24 
 2 files changed, 48 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_memoryobjects.c 
b/src/mesa/state_tracker/st_cb_memoryobjects.c
index 7a43763..63a8c2a 100644
--- a/src/mesa/state_tracker/st_cb_memoryobjects.c
+++ b/src/mesa/state_tracker/st_cb_memoryobjects.c
@@ -1,3 +1,27 @@
+/*
+ * Copyright © 2017 Red Hat.
+ * Copyright © 2017 Valve Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND 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.
+ */
+
 #include "main/imports.h"
 #include "main/mtypes.h"
 
diff --git a/src/mesa/state_tracker/st_cb_memoryobjects.h 
b/src/mesa/state_tracker/st_cb_memoryobjects.h
index 6606516..a8259cd 100644
--- a/src/mesa/state_tracker/st_cb_memoryobjects.h
+++ b/src/mesa/state_tracker/st_cb_memoryobjects.h
@@ -1,3 +1,27 @@
+/*
+ * Copyright © 2017 Red Hat.
+ * Copyright © 2017 Valve Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND 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.
+ */
+
 #ifndef ST_CB_MEMORYOBJECTS_H
 #define ST_CB_MEMORYOBJECTS_H
 
-- 
2.9.3

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

[Mesa-dev] [PATCH 2/3] mesa: minor tidy up for memory object error strings

[Andres Rodriguez]

Signed-off-by: Andres Rodriguez 
---
 src/mesa/main/externalobjects.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/src/mesa/main/externalobjects.c b/src/mesa/main/externalobjects.c
index e70280c..4e9f8f8 100644
--- a/src/mesa/main/externalobjects.c
+++ b/src/mesa/main/externalobjects.c
@@ -148,8 +148,7 @@ _mesa_CreateMemoryObjectsEXT(GLsizei n, GLuint 
*memoryObjects)
   _mesa_debug(ctx, "%s(%d, %p)", func, n, memoryObjects);
 
if (!ctx->Extensions.EXT_memory_object) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glCreateMemoryObjectsEXT(unsupported)");
+  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(unsupported)", func);
   return;
}
 
@@ -195,9 +194,10 @@ _mesa_MemoryObjectParameterivEXT(GLuint memoryObject,
GET_CURRENT_CONTEXT(ctx);
struct gl_memory_object *memObj;
 
+   const char *func = "glMemoryObjectParameterivEXT";
+
if (!ctx->Extensions.EXT_memory_object) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glMemoryObjectParameterivEXT(unsupported)");
+  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(unsupported)", func);
   return;
}
 
@@ -206,8 +206,7 @@ _mesa_MemoryObjectParameterivEXT(GLuint memoryObject,
   return;
 
if (memObj->Immutable) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glMemoryObjectParameterivEXT(memoryObject is immutable");
+  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(memoryObject is immutable", 
func);
   return;
}
 
@@ -224,8 +223,7 @@ _mesa_MemoryObjectParameterivEXT(GLuint memoryObject,
return;
 
 invalid_pname:
-   _mesa_error(ctx, GL_INVALID_ENUM,
-   "glMemoryObjectParameterivEXT(pname=0x%x)", pname);
+   _mesa_error(ctx, GL_INVALID_ENUM, "%s(pname=0x%x)", func, pname);
 }
 
 void GLAPIENTRY
@@ -236,9 +234,10 @@ _mesa_GetMemoryObjectParameterivEXT(GLuint memoryObject,
GET_CURRENT_CONTEXT(ctx);
struct gl_memory_object *memObj;
 
+   const char *func = "glMemoryObjectParameterivEXT";
+
if (!ctx->Extensions.EXT_memory_object) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glGetMemoryObjectParameterivEXT(unsupported)");
+  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(unsupported)", func);
   return;
}
 
@@ -259,8 +258,7 @@ _mesa_GetMemoryObjectParameterivEXT(GLuint memoryObject,
return;
 
 invalid_pname:
-   _mesa_error(ctx, GL_INVALID_ENUM,
-   "glGetMemoryObjectParameterivEXT(pname=0x%x)", pname);
+   _mesa_error(ctx, GL_INVALID_ENUM, "%s(pname=0x%x)", func, pname);
 }
 
 static struct gl_memory_object *
@@ -611,15 +609,15 @@ _mesa_ImportMemoryFdEXT(GLuint memory,
 {
GET_CURRENT_CONTEXT(ctx);
 
+   const char *func = "glImportMemoryFdEXT";
+
if (!ctx->Extensions.EXT_memory_object_fd) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glImportMemoryFdEXT(unsupported)");
+  _mesa_error(ctx, GL_INVALID_OPERATION, "%s(unsupported)", func);
   return;
}
 
if (handleType != GL_HANDLE_TYPE_OPAQUE_FD_EXT) {
-  _mesa_error(ctx, GL_INVALID_VALUE, "glImportMemoryFdEXT(handleType=%u)",
-  handleType);
+  _mesa_error(ctx, GL_INVALID_VALUE, "%s(handleType=%u)", func, 
handleType);
   return;
}
 
-- 
2.9.3

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

[Mesa-dev] [PATCH 1/3] broadcom/vc4: fix indentation in vc4_screen.c

[Andres Rodriguez]

Stumbled into this when adding a new PIPE_CAP.

Signed-off-by: Andres Rodriguez 
---
 src/gallium/drivers/vc4/vc4_screen.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/vc4/vc4_screen.c 
b/src/gallium/drivers/vc4/vc4_screen.c
index 1a9eaad..a42ba67 100644
--- a/src/gallium/drivers/vc4/vc4_screen.c
+++ b/src/gallium/drivers/vc4/vc4_screen.c
@@ -278,16 +278,16 @@ vc4_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
 case PIPE_CAP_SPARSE_BUFFER_PAGE_SIZE:
 case PIPE_CAP_TGSI_BALLOT:
 case PIPE_CAP_TGSI_TES_LAYER_VIEWPORT:
-   case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
+case PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEX:
 case PIPE_CAP_POST_DEPTH_COVERAGE:
 case PIPE_CAP_BINDLESS_TEXTURE:
 case PIPE_CAP_NIR_SAMPLERS_AS_DEREF:
 case PIPE_CAP_QUERY_SO_OVERFLOW:
-   case PIPE_CAP_MEMOBJ:
+case PIPE_CAP_MEMOBJ:
 case PIPE_CAP_LOAD_CONSTBUF:
-   case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
-   case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
-   case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
+case PIPE_CAP_TGSI_ANY_REG_AS_ADDRESS:
+case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
+case PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET:
 return 0;
 
 /* Stream output. */
@@ -445,11 +445,11 @@ vc4_screen_get_shader_param(struct pipe_screen *pscreen,
 return PIPE_SHADER_IR_NIR;
 case PIPE_SHADER_CAP_SUPPORTED_IRS:
 return 0;
-   case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
-   return 32;
+case PIPE_SHADER_CAP_MAX_UNROLL_ITERATIONS_HINT:
+return 32;
 case PIPE_SHADER_CAP_MAX_SHADER_BUFFERS:
 case PIPE_SHADER_CAP_MAX_SHADER_IMAGES:
-   case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
+case PIPE_SHADER_CAP_LOWER_IF_THRESHOLD:
 case PIPE_SHADER_CAP_TGSI_SKIP_MERGE_REGISTERS:
 case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTERS:
 case PIPE_SHADER_CAP_MAX_HW_ATOMIC_COUNTER_BUFFERS:
-- 
2.9.3

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

[Mesa-dev] [PATCH 0/3] Minor tidy ups

[Andres Rodriguez]

Split off some cleanup patches from my GL_EXT_semaphore series.

There are no functional changes in this series.

Andres Rodriguez (3):
  broadcom/vc4: fix indentation in vc4_screen.c
  mesa: minor tidy up for memory object error strings
  mesa/st: add missing copyright headers to memoryobjects files

 src/gallium/drivers/vc4/vc4_screen.c | 16 +++
 src/mesa/main/externalobjects.c  | 30 +---
 src/mesa/state_tracker/st_cb_memoryobjects.c | 24 ++
 src/mesa/state_tracker/st_cb_memoryobjects.h | 24 ++
 4 files changed, 70 insertions(+), 24 deletions(-)

-- 
2.9.3

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

Re: [Mesa-dev] [PATCH 05/10] nir: Use well-known power-of-two test instead of util_bitscan

[Ian Romanick]

On 11/10/2017 04:54 PM, Matt Turner wrote:
> On Fri, Nov 10, 2017 at 2:32 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> This prevents the next change from breaking the build, and I felt that
>> it was different enough from the rest of that patch to stand on its own.
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/compiler/nir/nir_validate.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/compiler/nir/nir_validate.c 
>> b/src/compiler/nir/nir_validate.c
>> index 9bf8c70..ca191d2 100644
>> --- a/src/compiler/nir/nir_validate.c
>> +++ b/src/compiler/nir/nir_validate.c
>> @@ -979,8 +979,9 @@ validate_var_decl(nir_variable *var, bool is_global, 
>> validate_state *state)
>>
>> validate_assert(state, is_global == nir_variable_is_global(var));
>>
>> -   /* Must have exactly one mode set */
>> -   validate_assert(state, util_bitcount(var->data.mode) == 1);
>> +   /* Must have exactly one mode set (i.e., is a power of two) */
>> +   validate_assert(state, (var->data.mode != 0 &&
>> +   !(var->data.mode & (var->data.mode - 1;
> 
> We actually have two functions in Mesa for this: util_is_power_of_two
> and _mesa_is_pow_two. Not sure which one is available to this code,
> but assuming one is, we should use it.

I don't think either is available in its current location, but I'd be in
favor of having only one in a new location that is always available.
Any suggestion where that might be?

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

Re: [Mesa-dev] [PATCH 02/13] i965: remove ARB_compute_shader extension override

[Jordan Justen]

On 2017-11-10 08:19:38, Emil Velikov wrote:
> On 7 November 2017 at 11:54, Emil Velikov  wrote:
> > From: Emil Velikov 
> >
> > Checking the override was useful in the early stages of developing the
> > extension.
> >
> > Now that everything is wired, where possible, we can drop the check.
> > Doing so allows us to simplify some of the related code.
> >
> > Cc: Jordan Justen 
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> > b/src/mesa/drivers/dri/i965/brw_context.c
> > index 1bf39b07382..3947a71a46a 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -348,8 +348,7 @@ brw_initialize_context_constants(struct brw_context 
> > *brw)
> >   (_mesa_is_desktop_gl(ctx) &&
> >ctx->Const.MaxComputeWorkGroupSize[0] >= 1024) ||
> >   (ctx->API == API_OPENGLES2 &&
> > -  ctx->Const.MaxComputeWorkGroupSize[0] >= 128) ||
> > - _mesa_extension_override_enables.ARB_compute_shader,
> > +  ctx->Const.MaxComputeWorkGroupSize[0] >= 128),
> 
> Jordan can you throw an Ack on this patch if it makes sense?
> Brian already reviewed the series, but I'd appreciate input from
> someone familiar with the Intel specifics.

Regarding patches 2 & 8, the point of those being non-static was so
the driver could take some action if the user requested an extension
override.

I can't remember, but maybe with SIMD32 being supported, this might no
longer affect any i965 devices.

I still think it could be good to allow the driver to easily know what
extensions were overridden, but I'll concede that it is not too
important. So, go ahead with the change if you want.

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

[Mesa-dev] [ANNOUNCE] mesa 17.2.5

[Andres Gomez]

Mesa 17.2.5 is now available.

In this release we have:

In Mesa Core a GL error related to the ARB_ES3_1_compatibility spec
noticed with the GFXBench 5 Aztec Ruins has been corrected. 

The GLSL compiler is not giving a linker error for mismatching uniform
precision with GLSL ES 1.00 any more. This enables, specially, several
Android applications which violate this rule, like Forge of Empires,
for example.

The SPIR-V compiler has corrected an assert triggered when support for
the simple memory model was claimed.

NIR has also received a correction related with
gl_SubGroupG{e,t}MaskARB.

The Intel drivers, specially i965, have received several fixes,
including a plug for a memory leak and another one in the compiler to
avoid GPU hangs on Broxton.

The gallium i915g driver for Intel has also seen an important
correction.

AMD drivers, mostly radv, have also received several fixes, including a
correction for a DCC corruption that was visible with Rust, breaking an
endless loop in r600, avoiding a GPU hang with vulkan dota2 in VR mode
and a plug for a memory leak.

Broadcom's vc4 has gotten a fix to compile out some non-debug code that
shouldn't be there for the release build.


Andres Gomez (9):
  docs: add sha256 checksums for 17.2.4
  cherry-ignore: radv: copy indirect lowering settings from radeonsi
  cherry-ignore: i965: fix blorp stage_prog_data->param leak
  cherry-ignore: etnaviv: don't do resolve-in-place without valid TS
  cherry-ignore: intel/fs: Alloc pull constants off mem_ctx
  cherry-ignore: added 17.3 nominations.
  cherry-ignore: automake: include git_sha1.h.in in release tarball
  Update version to 17.2.5
  docs: add release notes for 17.2.5

Bas Nieuwenhuizen (3):
  radv: Don't expose heaps with 0 memory.
  radv: Don't use vgpr indexing for outputs on GFX9.
  radv: Disallow indirect outputs for GS on GFX9 as well.

Dave Airlie (3):
  i915g: make gears run again.
  radv: free attachments on end command buffer.
  radv: add initial copy descriptor support. (v2)

Eric Engestrom (1):
  vc4: fix release build

Gert Wollny (1):
  r600/sb: bail out if prepare_alu_group() doesn't find a proper scheduling

Jason Ekstrand (4):
  spirv: Claim support for the simple memory model
  i965/blorp: Use blorp_to_isl_format for src_isl_format in blit_miptrees
  i965/blorp: Use more temporary isl_format variables
  i965/miptree: Take an isl_format in render_aux_usage

Kenneth Graunke (1):
  mesa: Accept GL_BACK in get_fb0_attachment with ARB_ES3_1_compatibility.

Leo Liu (1):
  radeon/video: add gfx9 offsets when rejoin the video surface

Marek Olšák (2):
  st/dri: don't expose modifiers in EGL if the driver doesn't implement them
  ac/surface/gfx9: don't allow DCC for the smallest mipmap levels

Nanley Chery (1):
  i965: Check CCS_E compatibility for texture view rendering

Neil Roberts (1):
  nir/opt_intrinsics: Fix values for gl_SubGroupG{e,t}MaskARB

Nicolai Hähnle (1):
  amd/common/gfx9: workaround DCC corruption more conservatively

Tapani Pälli (1):
  i965: unref push_const_bo in intelDestroyContext

Timothy Arceri (1):
  radv: copy indirect lowering settings from radeonsi

Tomasz Figa (1):
  glsl: Allow precision mismatch on dead data with GLSL ES 1.00

Topi Pohjolainen (1):
  intel/compiler/gen9: Pixel shader header only workaround

git tag: mesa-17.2.5

https://mesa.freedesktop.org/archive/mesa-17.2.5.tar.gz
MD5:  6c2984686516dc68ab64c1cb4063b270  mesa-17.2.5.tar.gz
SHA1: d4ccc398295dbef1d792d658e6b3179f6f8642f4  mesa-17.2.5.tar.gz
SHA256: 25b40e72fad64b096c2d8d6fe9579369954debe7970d4ad53e5033c7eec2918b  
mesa-17.2.5.tar.gz
SHA512: 
ad46902116ba44d89bac20bc91986a1955146ba518dab82d537134e9f7029861833ac9fb0b156509a0d3669b074eb0b62cf304f355a11bb304b931e3748a6447
  mesa-17.2.5.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.2.5.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-17.2.5.tar.xz
MD5:  ba649f82a066f710aa23655254a83eb8  mesa-17.2.5.tar.xz
SHA1: 1509bd00f32ee42128f29b63b4aaf26bf9abb63e  mesa-17.2.5.tar.xz
SHA256: 7f7f914b7b9ea0b15f2d9d01a4375e311b0e90e55683b8e8a67ce8691eb1070f  
mesa-17.2.5.tar.xz
SHA512: 
c4b0f7f48b0b57fdf610de3d61e127774f8223e755acfde6cf2649818eec985e8f925abf8a15d530ecdb882cb8d7268fd01e5d94c8ac6934551b8a74272353c7
  mesa-17.2.5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-17.2.5.tar.xz.sig

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

Re: [Mesa-dev] [PATCH 05/10] nir: Use well-known power-of-two test instead of util_bitscan

[Matt Turner]

On Fri, Nov 10, 2017 at 2:32 PM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> This prevents the next change from breaking the build, and I felt that
> it was different enough from the rest of that patch to stand on its own.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_validate.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
> index 9bf8c70..ca191d2 100644
> --- a/src/compiler/nir/nir_validate.c
> +++ b/src/compiler/nir/nir_validate.c
> @@ -979,8 +979,9 @@ validate_var_decl(nir_variable *var, bool is_global, 
> validate_state *state)
>
> validate_assert(state, is_global == nir_variable_is_global(var));
>
> -   /* Must have exactly one mode set */
> -   validate_assert(state, util_bitcount(var->data.mode) == 1);
> +   /* Must have exactly one mode set (i.e., is a power of two) */
> +   validate_assert(state, (var->data.mode != 0 &&
> +   !(var->data.mode & (var->data.mode - 1;

We actually have two functions in Mesa for this: util_is_power_of_two
and _mesa_is_pow_two. Not sure which one is available to this code,
but assuming one is, we should use it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] configure.ac: Define HAVE_ZLIB if zlib is found

[Emil Velikov]

On 10 November 2017 at 22:18, Jordan Justen  wrote:
> v2:
>  * Keep zlib required for autotools & meson (Emil)
>
> Cc: Emil Velikov 
> Cc: Dylan Baker 
> Signed-off-by: Jordan Justen 
> ---
>  configure.ac | 8 +++-
>  meson.build  | 6 +-
>  2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..5db39e5a68d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -900,7 +900,13 @@ dnl See if posix_memalign is available
>  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
>
>  dnl Check for zlib
> -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
> +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
> +  [have_zlib=yes], [have_zlib=no])
> +if test "x$have_zlib" = xyes; then
> +DEFINES="$DEFINES -DHAVE_ZLIB"
> +else
> +AC_MSG_ERROR([Building mesa on this platform requires zlib])
> +fi
>
By default PKG_CHECK_MODULES will error out, when the dependency is missing.
Thus you only need a single line:
DEFINES="$DEFINES -DHAVE_ZLIB"

>  dnl Check for pthreads
>  AX_PTHREAD
> diff --git a/meson.build b/meson.build
> index 855c80ed658..d3ab3f6181d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -661,8 +661,12 @@ if dep_libdrm.found()
>endif
>  endif
>
> -# TODO: some of these may be conditional
>  dep_zlib = dependency('zlib', version : '>= 1.2.3')
The meson manpage does not say if 'required' defaults to true or false.
If the former I'd explicitly set it to true, with a small note above
wrt Windows.
"Needs Windows integration for zlib"

Alternatively, one could drop the dep_zlib.found check.

Please squash the following

--- a/Android.common.mk
+++ b/Android.common.mk
@@ -65,6 +65,7 @@ LOCAL_CFLAGS += \
   -DHAVE_PTHREAD=1 \
   -DHAVE_DLADDR \
   -DHAVE_DL_ITERATE_PHDR \
+   -DHAVE_ZLIB \
   -DMAJOR_IN_SYSMACROS \
   -fvisibility=hidden \
   -Wno-sign-compare


With the above the patch is
Reviewed-by: Emil Velikov 

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

[Mesa-dev] [PATCH 10/10] spirv: Generate SPIR-V builder infrastructure

[Ian Romanick]

From: Ian Romanick 

v2: Don't try to automatically set SpvCapabilityGeometry or
SpvCapabilityTessellation.
---
 src/compiler/Makefile.sources |   2 +
 src/compiler/Makefile.spirv.am|   4 +
 src/compiler/spirv/.gitignore |   1 +
 src/compiler/spirv/meson.build|   7 +
 src/compiler/spirv/spirv_builder.h| 205 
 src/compiler/spirv/spirv_builder_h.py | 613 ++
 6 files changed, 832 insertions(+)
 create mode 100644 src/compiler/spirv/spirv_builder.h
 create mode 100644 src/compiler/spirv/spirv_builder_h.py

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 1d67cba..aea067f 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -287,6 +287,7 @@ NIR_FILES = \
nir/nir_worklist.h
 
 SPIRV_GENERATED_FILES = \
+   spirv/spirv_builder_functions.h \
spirv/spirv_capabilities.cpp \
spirv/spirv_capabilities.h \
spirv/spirv_info.c
@@ -295,6 +296,7 @@ SPIRV_FILES = \
spirv/GLSL.std.450.h \
spirv/nir_spirv.h \
spirv/spirv.h \
+   spirv/spirv_builder.h \
spirv/spirv_info.h \
spirv/spirv_to_nir.c \
spirv/vtn_alu.c \
diff --git a/src/compiler/Makefile.spirv.am b/src/compiler/Makefile.spirv.am
index 4bc684a..fa31313 100644
--- a/src/compiler/Makefile.spirv.am
+++ b/src/compiler/Makefile.spirv.am
@@ -20,6 +20,10 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 # IN THE SOFTWARE.
 
+spirv/spirv_builder_functions.h: spirv/spirv_builder_h.py 
spirv/spirv.core.grammar.json
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $(srcdir)/spirv/spirv_builder_h.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
+
 spirv/spirv_capabilities.cpp: spirv/spirv_capabilities_h.py 
spirv/spirv.core.grammar.json
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/spirv/spirv_capabilities_h.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
diff --git a/src/compiler/spirv/.gitignore b/src/compiler/spirv/.gitignore
index 6b5ef0a..a4753c8 100644
--- a/src/compiler/spirv/.gitignore
+++ b/src/compiler/spirv/.gitignore
@@ -1,3 +1,4 @@
+/spirv_builder_functions.h
 /spirv_capabilities.cpp
 /spirv_capabilities.h
 /spirv_info.c
diff --git a/src/compiler/spirv/meson.build b/src/compiler/spirv/meson.build
index e4ca3b6..9c3f134 100644
--- a/src/compiler/spirv/meson.build
+++ b/src/compiler/spirv/meson.build
@@ -38,3 +38,10 @@ spirv_capabilities_h = custom_target(
   output : 'spirv_capabilities.h',
   command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
 )
+
+spirv_builder_functions_h = custom_target(
+  'spirv_builder_functions.h',
+  input : files('spirv_builder_h.py', 'spirv.core.grammar.json'),
+  output : 'spirv_builder_functions.h',
+  command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
+)
diff --git a/src/compiler/spirv/spirv_builder.h 
b/src/compiler/spirv/spirv_builder.h
new file mode 100644
index 000..a97cfb7
--- /dev/null
+++ b/src/compiler/spirv/spirv_builder.h
@@ -0,0 +1,205 @@
+/* -*- c++ -*- */
+/*
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND 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.
+ */
+#ifndef SPIRV_BUILDER_H
+#define SPIRV_BUILDER_H
+
+#include 
+#include 
+#include 
+#include "spirv.h"
+#include "spirv_capabilities.h"
+
+#define INSTRUCTION_HEADER(op, size) (((size) << 16) | op)
+
+class spirv_program {
+public:
+   spirv_program(spirv_capability_set *_capabilities)
+  : capabilities(_capabilities), max_instruction(1024), instruction(0),
+begin(~0)
+   {
+  memory = (uint32_t *) calloc(max_instruction, sizeof(uint32_t));
+   }
+
+   ~spirv_program()
+   {
+  free(memory);
+   }
+
+   unsigned size_in_bytes() const
+   {
+  assert(instruction <= max_instruction);
+
+  return instruction * sizeof(uint32_t);
+   }
+
+   

[Mesa-dev] [PATCH 08/10] spirv: Move SPIR-V building to Makefile.spirv.am and spirv/meson.build

[Ian Romanick]

From: Ian Romanick 

Future changes will add generated files used only from
src/compiler/glsl.  These can't be built from Makefile.nir.am, and we
can't move all the rules from Makefile.nir.am to Makefile.spirv.am (and
it would be silly anyway).

v2: Do it for meson too.

Signed-off-by: Ian Romanick 
---
 src/compiler/Makefile.am   |  2 ++
 src/compiler/Makefile.nir.am   | 31 ++--
 src/compiler/Makefile.spirv.am | 54 ++
 src/compiler/meson.build   |  5 
 src/compiler/nir/meson.build   |  7 --
 src/compiler/spirv/meson.build | 26 
 6 files changed, 89 insertions(+), 36 deletions(-)
 create mode 100644 src/compiler/Makefile.spirv.am
 create mode 100644 src/compiler/spirv/meson.build

diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index 1f7a80b..3cc96df 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -63,6 +63,8 @@ EXTRA_DIST = SConscript
 MKDIR_GEN = $(AM_V_at)$(MKDIR_P) $(@D)
 PYTHON_GEN = $(AM_V_GEN)$(PYTHON2) $(PYTHON_FLAGS)
 
+include Makefile.spirv.am
+
 include Makefile.glsl.am
 
 include Makefile.nir.am
diff --git a/src/compiler/Makefile.nir.am b/src/compiler/Makefile.nir.am
index 1533ee5..0b9d419 100644
--- a/src/compiler/Makefile.nir.am
+++ b/src/compiler/Makefile.nir.am
@@ -52,29 +52,6 @@ nir/nir_opt_algebraic.c: nir/nir_opt_algebraic.py 
nir/nir_algebraic.py
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/nir/nir_opt_algebraic.py > $@ || ($(RM) $@; 
false)
 
-spirv/spirv_info.c: spirv/spirv_info_c.py spirv/spirv.core.grammar.json
-   $(MKDIR_GEN)
-   $(PYTHON_GEN) $(srcdir)/spirv/spirv_info_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
-
-noinst_PROGRAMS += spirv2nir
-
-spirv2nir_SOURCES = \
-   spirv/spirv2nir.c
-
-spirv2nir_CPPFLAGS =   \
-   $(AM_CPPFLAGS)  \
-   -I$(top_builddir)/src/compiler/nir  \
-   -I$(top_srcdir)/src/compiler/nir\
-   -I$(top_srcdir)/src/compiler/spirv
-
-spirv2nir_LDADD =  \
-   nir/libnir.la   \
-   $(top_builddir)/src/util/libmesautil.la \
-   -lm \
-   $(PTHREAD_LIBS)
-
-nodist_EXTRA_spirv2nir_SOURCES = dummy.cpp
-
 check_PROGRAMS += nir/tests/control_flow_tests
 
 nir_tests_control_flow_tests_CPPFLAGS = \
@@ -97,12 +74,10 @@ TESTS += nir/tests/control_flow_tests
 
 
 BUILT_SOURCES += \
-   $(NIR_GENERATED_FILES) \
-   $(SPIRV_GENERATED_FILES)
+   $(NIR_GENERATED_FILES)
 
 CLEANFILES += \
-   $(NIR_GENERATED_FILES) \
-   $(SPIRV_GENERATED_FILES)
+   $(NIR_GENERATED_FILES)
 
 EXTRA_DIST += \
nir/nir_algebraic.py\
@@ -114,6 +89,4 @@ EXTRA_DIST += \
nir/nir_opt_algebraic.py\
nir/tests \
nir/README \
-   spirv/spirv_info_c.py   \
-   spirv/spirv.core.grammar.json   \
SConscript.nir
diff --git a/src/compiler/Makefile.spirv.am b/src/compiler/Makefile.spirv.am
new file mode 100644
index 000..9841004
--- /dev/null
+++ b/src/compiler/Makefile.spirv.am
@@ -0,0 +1,54 @@
+#
+# Copyright (C) 2017 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND 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.
+
+spirv/spirv_info.c: spirv/spirv_info_c.py spirv/spirv.core.grammar.json
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $(srcdir)/spirv/spirv_info_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
+
+noinst_PROGRAMS += spirv2nir
+
+spirv2nir_SOURCES = \
+   spirv/spirv2nir.c
+
+spirv2nir_CPPFLAGS =   \
+   $(AM_CPPFLAGS)  \
+   

[Mesa-dev] [PATCH 09/10] spirv: Generate code to track SPIR-V capability dependencies

[Ian Romanick]

From: Ian Romanick 

v2: Clean ups.  Remove some functions that never ended up being used.

v3: After updating spirv.core.grammar.json, fix the handling of
ShaderViewportMaskNV.  See the comment around line 71 of
spirv_capabilities_h.py.

Signed-off-by: Ian Romanick 
---
 src/compiler/Makefile.sources  |   2 +
 src/compiler/Makefile.spirv.am |   8 +
 src/compiler/glsl/meson.build  |   3 +-
 src/compiler/spirv/.gitignore  |   2 +
 src/compiler/spirv/meson.build |  14 ++
 src/compiler/spirv/spirv_capabilities_h.py | 355 +
 6 files changed, 383 insertions(+), 1 deletion(-)
 create mode 100644 src/compiler/spirv/spirv_capabilities_h.py

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 2ab8e16..1d67cba 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -287,6 +287,8 @@ NIR_FILES = \
nir/nir_worklist.h
 
 SPIRV_GENERATED_FILES = \
+   spirv/spirv_capabilities.cpp \
+   spirv/spirv_capabilities.h \
spirv/spirv_info.c
 
 SPIRV_FILES = \
diff --git a/src/compiler/Makefile.spirv.am b/src/compiler/Makefile.spirv.am
index 9841004..4bc684a 100644
--- a/src/compiler/Makefile.spirv.am
+++ b/src/compiler/Makefile.spirv.am
@@ -20,6 +20,14 @@
 # FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 # IN THE SOFTWARE.
 
+spirv/spirv_capabilities.cpp: spirv/spirv_capabilities_h.py 
spirv/spirv.core.grammar.json
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $(srcdir)/spirv/spirv_capabilities_h.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
+
+spirv/spirv_capabilities.h: spirv/spirv_capabilities_h.py 
spirv/spirv.core.grammar.json
+   $(MKDIR_GEN)
+   $(PYTHON_GEN) $(srcdir)/spirv/spirv_capabilities_h.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
+
 spirv/spirv_info.c: spirv/spirv_info_c.py spirv/spirv.core.grammar.json
$(MKDIR_GEN)
$(PYTHON_GEN) $(srcdir)/spirv/spirv_info_c.py 
$(srcdir)/spirv/spirv.core.grammar.json $@ || ($(RM) $@; false)
diff --git a/src/compiler/glsl/meson.build b/src/compiler/glsl/meson.build
index 5b505c0..961bfb0 100644
--- a/src/compiler/glsl/meson.build
+++ b/src/compiler/glsl/meson.build
@@ -198,7 +198,8 @@ files_libglsl_standalone = files(
 libglsl = static_library(
   'glsl',
   [files_libglsl, glsl_parser, glsl_lexer_cpp, ir_expression_operation_h,
-   ir_expression_operation_strings_h, ir_expression_operation_constant_h],
+   ir_expression_operation_strings_h, ir_expression_operation_constant_h,
+   spirv_capabilities_cpp, spirv_capabilities_h],
   c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
   cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
   link_with : [libnir, libglcpp],
diff --git a/src/compiler/spirv/.gitignore b/src/compiler/spirv/.gitignore
index f723c31..6b5ef0a 100644
--- a/src/compiler/spirv/.gitignore
+++ b/src/compiler/spirv/.gitignore
@@ -1 +1,3 @@
+/spirv_capabilities.cpp
+/spirv_capabilities.h
 /spirv_info.c
diff --git a/src/compiler/spirv/meson.build b/src/compiler/spirv/meson.build
index 8f1a02e..e4ca3b6 100644
--- a/src/compiler/spirv/meson.build
+++ b/src/compiler/spirv/meson.build
@@ -24,3 +24,17 @@ spirv_info_c = custom_target(
   output : 'spirv_info.c',
   command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
 )
+
+spirv_capabilities_cpp = custom_target(
+  'spirv_capabilities.cpp',
+  input : files('spirv_capabilities_h.py', 'spirv.core.grammar.json'),
+  output : 'spirv_capabilities.cpp',
+  command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
+)
+
+spirv_capabilities_h = custom_target(
+  'spirv_capabilities.h',
+  input : files('spirv_capabilities_h.py', 'spirv.core.grammar.json'),
+  output : 'spirv_capabilities.h',
+  command : [prog_python2, '@INPUT0@', '@INPUT1@', '@OUTPUT@'],
+)
diff --git a/src/compiler/spirv/spirv_capabilities_h.py 
b/src/compiler/spirv/spirv_capabilities_h.py
new file mode 100644
index 000..3a4a5d7
--- /dev/null
+++ b/src/compiler/spirv/spirv_capabilities_h.py
@@ -0,0 +1,355 @@
+COPYRIGHT = """\
+/*
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE 

[Mesa-dev] [PATCH 05/10] nir: Use well-known power-of-two test instead of util_bitscan

[Ian Romanick]

From: Ian Romanick 

This prevents the next change from breaking the build, and I felt that
it was different enough from the rest of that patch to stand on its own.

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir_validate.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index 9bf8c70..ca191d2 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -979,8 +979,9 @@ validate_var_decl(nir_variable *var, bool is_global, 
validate_state *state)
 
validate_assert(state, is_global == nir_variable_is_global(var));
 
-   /* Must have exactly one mode set */
-   validate_assert(state, util_bitcount(var->data.mode) == 1);
+   /* Must have exactly one mode set (i.e., is a power of two) */
+   validate_assert(state, (var->data.mode != 0 &&
+   !(var->data.mode & (var->data.mode - 1;
 
if (var->data.compact) {
   /* The "compact" flag is only valid on arrays of scalars. */
-- 
2.9.5

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

[Mesa-dev] [PATCH 07/10] compiler: All leaf Makefile.am should use +=

[Ian Romanick]

From: Ian Romanick 

This slightly simplifies later changes that add more Makefile.*.am
files.

Signed-off-by: Ian Romanick 
---
 src/compiler/Makefile.am  | 1 +
 src/compiler/Makefile.glsl.am | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/Makefile.am b/src/compiler/Makefile.am
index 45b9cc5..1f7a80b 100644
--- a/src/compiler/Makefile.am
+++ b/src/compiler/Makefile.am
@@ -53,6 +53,7 @@ noinst_LTLIBRARIES = libcompiler.la
 
 libcompiler_la_SOURCES = $(LIBCOMPILER_FILES)
 
+noinst_PROGRAMS =
 check_PROGRAMS =
 TESTS =
 BUILT_SOURCES =
diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index 179f415..ad19b14 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -54,7 +54,7 @@ check_PROGRAMS += \
glsl/tests/sampler-types-test   \
glsl/tests/uniform-initializer-test
 
-noinst_PROGRAMS = glsl_compiler
+noinst_PROGRAMS += glsl_compiler
 
 glsl_tests_blob_test_SOURCES = \
glsl/tests/blob_test.c
-- 
2.9.5

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

[Mesa-dev] [PATCH 02/10] i965: Don't request GLSL IR lowering of gl_VertexID

[Ian Romanick]

From: Ian Romanick 

Let the lowering in NIR handle it instead.

This hurts one shader that occurs twice in shader-db (SynMark GSCloth)
on IVB and HSW.  No other shaders or platforms were affected.

total cycles in shared programs: 253438422 -> 253438426 (0.00%)
cycles in affected programs: 412 -> 416 (0.97%)
helped: 0
HURT: 2

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_context.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 19d5a2e..c690350 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -586,7 +586,6 @@ brw_initialize_context_constants(struct brw_context *brw)
   ctx->Const.QuadsFollowProvokingVertexConvention = false;
 
ctx->Const.NativeIntegers = true;
-   ctx->Const.VertexID_is_zero_based = true;
 
/* Regarding the CMP instruction, the Ivybridge PRM says:
 *
-- 
2.9.5

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

[Mesa-dev] [PATCH 04/10] spirv: Add SubgroupBallotKHR capability to SubgroupSize and SubgroupLocalInvocationId

[Ian Romanick]

From: Ian Romanick 

The SPV_KHR_shader_ballot spec says:

(Add the SubgroupBallotKHR capability to SubgroupSize.)

(Add the SubgroupBallotKHR capability to SubgroupLocalInvocationId.)

Yet the annotations are missing from the JSON.  See also
https://github.com/KhronosGroup/SPIRV-Headers/issues/44.
---
 src/compiler/spirv/spirv.core.grammar.json | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/spirv.core.grammar.json 
b/src/compiler/spirv/spirv.core.grammar.json
index f05be1c..a5da37a 100644
--- a/src/compiler/spirv/spirv.core.grammar.json
+++ b/src/compiler/spirv/spirv.core.grammar.json
@@ -5005,7 +5005,7 @@
 {
   "enumerant" : "SubgroupSize",
   "value" : 36,
-  "capabilities" : [ "Kernel" ]
+  "capabilities" : [ "Kernel", "SubgroupBallotKHR" ]
 },
 {
   "enumerant" : "SubgroupMaxSize",
@@ -5030,7 +5030,7 @@
 {
   "enumerant" : "SubgroupLocalInvocationId",
   "value" : 41,
-  "capabilities" : [ "Kernel" ]
+  "capabilities" : [ "Kernel", "SubgroupBallotKHR" ]
 },
 {
   "enumerant" : "VertexIndex",
-- 
2.9.5

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

[Mesa-dev] [PATCH 06/10] util: Include bitscan.h directly

[Ian Romanick]

From: Ian Romanick 

Previously bitset.h would include u_math.h to get bitscan.h.  u_math.h
lives in src/gallium/auxiliary/util while both bitset.h and bitscan.h
live in src/util.  Having the one file directly include another file
that lives in the same directory makes much more sense.

As a side-effect, several files need to directly include standard header
files that were previously indirectly included.

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir.c   | 1 +
 src/compiler/spirv/vtn_alu.c | 1 +
 src/compiler/spirv/vtn_glsl450.c | 1 +
 src/util/bitset.h| 2 +-
 4 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 7380bf4..ffe880c 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -27,6 +27,7 @@
 
 #include "nir.h"
 #include "nir_control_flow_private.h"
+#include 
 #include 
 
 nir_shader *
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index ecf9cbc..ad3f217 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -21,6 +21,7 @@
  * IN THE SOFTWARE.
  */
 
+#include 
 #include "vtn_private.h"
 
 /*
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index c30dcc7..0540d5b 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -25,6 +25,7 @@
  *
  */
 
+#include 
 #include "vtn_private.h"
 #include "GLSL.std.450.h"
 
diff --git a/src/util/bitset.h b/src/util/bitset.h
index 2404ce7..8c9e856 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -31,7 +31,7 @@
 #ifndef BITSET_H
 #define BITSET_H
 
-#include "util/u_math.h"
+#include "util/bitscan.h"
 
 /
  * generic bitset implementation
-- 
2.9.5

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

[Mesa-dev] [PATCH 03/10] spirv: Import the latest 1.0.12 header and JSON from Khronos

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/spirv/spirv.core.grammar.json | 417 -
 src/compiler/spirv/spirv.h |  56 ++--
 2 files changed, 201 insertions(+), 272 deletions(-)

diff --git a/src/compiler/spirv/spirv.core.grammar.json 
b/src/compiler/spirv/spirv.core.grammar.json
index e2950dd..f05be1c 100644
--- a/src/compiler/spirv/spirv.core.grammar.json
+++ b/src/compiler/spirv/spirv.core.grammar.json
@@ -26,8 +26,8 @@
   ],
   "magic_number" : "0x07230203",
   "major_version" : 1,
-  "minor_version" : 2,
-  "revision" : 1,
+  "minor_version" : 0,
+  "revision" : 12,
   "instructions" : [
 {
   "opname" : "OpNop",
@@ -2410,7 +2410,7 @@
 { "kind" : "IdResult" },
 { "kind" : "IdScope","name" : "'Execution'" },
 { "kind" : "GroupOperation", "name" : "'Operation'" },
-{ "kind" : "IdRef",  "name" : "X" }
+{ "kind" : "IdRef",  "name" : "'X'" }
   ],
   "capabilities" : [ "Groups" ]
 },
@@ -2434,7 +2434,7 @@
 { "kind" : "IdResult" },
 { "kind" : "IdScope","name" : "'Execution'" },
 { "kind" : "GroupOperation", "name" : "'Operation'" },
-{ "kind" : "IdRef",  "name" : "X" }
+{ "kind" : "IdRef",  "name" : "'X'" }
   ],
   "capabilities" : [ "Groups" ]
 },
@@ -2446,7 +2446,7 @@
 { "kind" : "IdResult" },
 { "kind" : "IdScope","name" : "'Execution'" },
 { "kind" : "GroupOperation", "name" : "'Operation'" },
-{ "kind" : "IdRef",  "name" : "X" }
+{ "kind" : "IdRef",  "name" : "'X'" }
   ],
   "capabilities" : [ "Groups" ]
 },
@@ -2458,7 +2458,7 @@
 { "kind" : "IdResult" },
 { "kind" : "IdScope","name" : "'Execution'" },
 { "kind" : "GroupOperation", "name" : "'Operation'" },
-{ "kind" : "IdRef",  "name" : "X" }
+{ "kind" : "IdRef",  "name" : "'X'" }
   ],
   "capabilities" : [ "Groups" ]
 },
@@ -2470,7 +2470,7 @@
 { "kind" : "IdResult" },
 { "kind" : "IdScope","name" : "'Execution'" },
 { "kind" : "GroupOperation", "name" : "'Operation'" },
-{ "kind" : "IdRef",  "name" : "X" }
+{ "kind" : "IdRef",  "name" : "'X'" }
   ],
   "capabilities" : [ "Groups" ]
 },
@@ -3013,124 +3013,6 @@
   "capabilities" : [ "SparseResidency" ]
 },
 {
-  "opname" : "OpSizeOf",
-  "opcode" : 321,
-  "operands" : [
-{ "kind" : "IdResultType" },
-{ "kind" : "IdResult" },
-{ "kind" : "IdRef","name" : "'Pointer'" }
-  ],
-  "capabilities" : [ "Addresses" ]
-},
-{
-  "opname" : "OpTypePipeStorage",
-  "opcode" : 322,
-  "operands" : [
-{ "kind" : "IdResult" }
-  ],
-  "capabilities" : [ "PipeStorage" ]
-},
-{
-  "opname" : "OpConstantPipeStorage",
-  "opcode" : 323,
-  "operands" : [
-{ "kind" : "IdResultType" },
-{ "kind" : "IdResult" },
-{ "kind" : "LiteralInteger", "name" : "'Packet Size'" },
-{ "kind" : "LiteralInteger", "name" : "'Packet Alignment'" },
-{ "kind" : "LiteralInteger", "name" : "'Capacity'" }
-  ],
-  "capabilities" : [ "PipeStorage" ]
-},
-{
-  "opname" : "OpCreatePipeFromPipeStorage",
-  "opcode" : 324,
-  "operands" : [
-{ "kind" : "IdResultType" },
-{ "kind" : "IdResult" },
-{ "kind" : "IdRef","name" : "'Pipe Storage'" }
-  ],
-  "capabilities" : [ "PipeStorage" ]
-},
-{
-  "opname" : "OpGetKernelLocalSizeForSubgroupCount",
-  "opcode" : 325,
-  "operands" : [
-{ "kind" : "IdResultType" },
-{ "kind" : "IdResult" },
-{ "kind" : "IdRef","name" : "'Subgroup Count'" },
-{ "kind" : "IdRef","name" : "'Invoke'" },
-{ "kind" : "IdRef","name" : "'Param'" },
-{ "kind" : "IdRef","name" : "'Param Size'" },
-{ "kind" : "IdRef","name" : "'Param Align'" }
-  ],
-  "capabilities" : [ "SubgroupDispatch" ]
-},
-{
-  "opname" : "OpGetKernelMaxNumSubgroups",
-  "opcode" : 326,
-  "operands" : [
-{ "kind" : "IdResultType" },
-{ "kind" : "IdResult" },
-{ "kind" : "IdRef","name" : "'Invoke'" },
-{ "kind" : "IdRef","name" : "'Param'" },
-{ "kind" : "IdRef","name" : "'Param Size'" },
-{ "kind" : "IdRef","name" : "'Param Align'" }
-  ],
-  "capabilities" : [ "SubgroupDispatch" ]
-},
-{
-  "opname" : "OpTypeNamedBarrier",
-  "opcode" : 327,
-  "operands" : [
-{ "kind" : "IdResult" }
-  ],
-  "capabilities" : [ "NamedBarrier" ]
-},
-{
-  "opname" : 

[Mesa-dev] [PATCH 01/10] i965: Silence "enumeral and non-enumeral type in conditional expression" warnings

[Ian Romanick]

From: Ian Romanick 

compiler/brw_inst.h: In function ‘brw_reg_type brw_inst_dst_type(const 
gen_device_info*, const brw_inst*)’:
compiler/brw_inst.h:801:55: warning: enumeral and non-enumeral type in 
conditional expression [-Wextra]
unsigned file = __builtin_strcmp("dst", #reg) == 0 ?   \
~~~^
BRW_GENERAL_REGISTER_FILE :\

brw_inst_##reg##_reg_file(devinfo, inst);  \

compiler/brw_inst.h:808:1: note: in expansion of macro ‘REG_TYPE’
 REG_TYPE(dst)
 ^~~~

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_inst.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_inst.h b/src/intel/compiler/brw_inst.h
index 99e637e..dcd955d 100644
--- a/src/intel/compiler/brw_inst.h
+++ b/src/intel/compiler/brw_inst.h
@@ -799,7 +799,7 @@ brw_inst_##reg##_type(const struct gen_device_info 
*devinfo,  \
   const brw_inst *inst)   \
 { \
unsigned file = __builtin_strcmp("dst", #reg) == 0 ?   \
-   BRW_GENERAL_REGISTER_FILE :\
+   (unsigned) BRW_GENERAL_REGISTER_FILE : \
brw_inst_##reg##_reg_file(devinfo, inst);  \
unsigned hw_type = brw_inst_##reg##_reg_hw_type(devinfo, inst);\
return brw_hw_type_to_reg_type(devinfo, (enum brw_reg_file)file, hw_type); \
-- 
2.9.5

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

[Mesa-dev] [PATCH 00/10] The first of the real SPIR-V work

[Ian Romanick]

This is the first block of patches to enable generating SPIR-V from
Mesa's GLSL compiler.  The initial use of this is for testing
GL_ARB_spirv, but it may eventually be useful in its own right.  A lot
more work will be necessary for that to happen, though.

Most of the work is done, but there are still some bits, notably UBOs
and images, left to do.  Of the ~46k shaders in my shader-db, I can
generate SPIR-V that passes the validator for nearly 10k.  Many shaders
fail because they use legacy features that cannot be represented in
SPIR-V.  I am sending this series out now to prime the review process.
The whole series is on the order of 80 patches, so I think it's valuable
to send things out in smaller, self-contained chunks.

The whole series (with some work-in-progress patches) is at

https://cgit.freedesktop.org/~idr/mesa/log/?h=emit-spirv

The implementation is divided into three layers, and this patch series
represents the bottom layer.

1. Raw SPIR-V emit code.  This layer has zero knowledge of GLSL IR or
   anything specific to Mesa.  It should be trivial for someone to pull
   this code out and use it in a separate project.  There are two parts.
   The first handles tracking and managing SPIR-V capabilities.  The
   second part implements a very low-level SPIR-V instruction builder
   sytled after ir_builder and nir_builder.  There are a couple rough
   bits here with respect to automatic setting of SPIR-V capabilites.
   There are cases where a SPIR-V feature requires any one of several
   capabilities, so it is impossible to pick one to enable.

2. Unstructured GLSL IR to SPIR-V.  This layer handles emitting single
   bits of GLSL IR in SPIR-V without knowledge of the global structure.
   This is mostly things like emitting glsl_type, ir_variable, and
   ir_function_signature.  At 38, this is the largest group of patches.
   This is mostly nailed down, but the UBO work is going to cause some
   changes.  I hope to finally wrap that up next week.

3. SPIR-V visitor.  This top-most layer handles the overall structure of
   the shader.  It uses a visitor in a similar fashion to glsl_to_mesa
   and glsl_to_tgsi.  Use a generator styled after nir_opt_algebraic has
   kept the amount of code here pretty small.

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

[Mesa-dev] [Bug 102891] [radv] glitches on rpcs3 emulator (green zones)

[bugzilla-daemon]

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

--- Comment #9 from jdr...@gmail.com ---
Created attachment 135388
  --> https://bugs.freedesktop.org/attachment.cgi?id=135388=edit
new qrenderdoc capture

I did an
export RADV_DEBUG=zerovram
before running qrenderdoc, but as I'm on mesa 17.2, I don't think this option
is activated.
Let me know if this capture is enough for you, else I'll see if I can switch to
mesa-git without too much pain (=breaking my system) (I'm on Arch).

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

Re: [Mesa-dev] [PATCH 2/2] anv/gen10: Enable float blend optimization

[Anuj Phogat]

On Fri, Nov 10, 2017 at 8:42 AM, Rafael Antognolli
 wrote:
> On Thu, Nov 09, 2017 at 11:14:43AM -0800, Anuj Phogat wrote:
>> On CNL this bit has been moved to CACHE_MODE_SS register.
>> We already have this enabled in OpenGL driver.
>> See Mesa commit 6c681b4cc1
>>
>> Signed-off-by: Anuj Phogat 
>> Cc: Nanley Chery 
>> Cc: Rafael Antognolli 
>> ---
>>  src/intel/genxml/gen10.xml| 12 
>>  src/intel/vulkan/genX_state.c | 12 
>>  2 files changed, 24 insertions(+)
>>
>> diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
>> index a7ae49ae65..a6b8f48fda 100644
>> --- a/src/intel/genxml/gen10.xml
>> +++ b/src/intel/genxml/gen10.xml
>> @@ -3752,4 +3752,16 @@
>>  > type="bool"/>
>>
>>
>> +  
>> +> type="bool"/>
>> +> start="1" end="1" type="bool"/>
>> +> type="bool"/>
>> +> type="bool"/>
>> +
>> +> end="16" type="bool"/>
>> +
>> +> type="bool"/>
>> +> type="bool"/>
>> +  
>> +
>>  
>
> I think we have been adding the genxml changes into their own commits, so it
> may be good to split this part into a separate one. Other than that, looks 
> good
> to me (again waiting on Jason or Nanley).
>
> With the above change,
>
Splitted this patch in to two:
[PATCH 1.5/2] intel/genxml: Add Cache Mode SubSlice Register to gen10.xml
[PATCH 2/2] anv/gen10: Enable float blend optimization

> Reviewed-by: Rafael Antognolli 
>
>> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
>> index f56c686ed3..54fb8634fd 100644
>> --- a/src/intel/vulkan/genX_state.c
>> +++ b/src/intel/vulkan/genX_state.c
>> @@ -121,6 +121,18 @@ genX(init_device_state)(struct anv_device *device)
>> }
>>  #endif
>>
>> +#if GEN_GEN == 10
>> +   uint32_t cache_mode_ss;
>> +   anv_pack_struct(_mode_ss, GENX(CACHE_MODE_SS),
>> +   .FloatBlendOptimizationEnable = true,
>> +   .FloatBlendOptimizationEnableMask = true);
>> +
>> +   anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
>> +  lri.RegisterOffset = GENX(CACHE_MODE_SS_num);
>> +  lri.DataDWord  = cache_mode_ss;
>> +   }
>> +#endif
>> +
>> anv_batch_emit(, GENX(3DSTATE_AA_LINE_PARAMETERS), aa);
>>
>> anv_batch_emit(, GENX(3DSTATE_DRAWING_RECTANGLE), rect) {
>> --
>> 2.13.5
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] add util_queue_fence_wait_timeout checkin breaks centos6 build

[Kyriazis, George]

Hmm..

Looking at /usr/include/time.h on ubuntu, I see the following:

#if (!defined __timespec_defined\
 && ((defined _TIME_H   \
  && (defined __USE_POSIX199309 \
  || defined __USE_ISOC11)) \
 || defined __need_timespec))
# define __timespec_defined 1

…

# ifdef __USE_ISOC11
/* Set TS to calendar time based in time base BASE.  */
extern int timespec_get (struct timespec *__ts, int __base)
 __THROW __nonnull ((1));
# endif


However, on centos6, I see:

#if !defined __timespec_defined &&  \
((defined _TIME_H &&\
  (defined __USE_POSIX199309 || defined __USE_MISC)) || \
  defined __need_timespec)
# define __timespec_defined 1

No definition for timespec_get().

So, the difference between the two looks like it’s the dependence of 
__USE_ISOC11.

The quick fix would be to depend on __USE_ISOC11 (or even better 
__timespec_defined && __USE_ISOC11), but I’m not sure how portable it is.

Of course, the most fool-proof solution would be a configure script check, but 
it could be redundant.

George

> On Nov 10, 2017, at 2:41 PM, Nicolai Hähnle  wrote:
> 
> On 10.11.2017 19:20, Kyriazis, George wrote:
>> Hello Nicolai,
>> Your commit e3a8013 (util/u_queue: add util_queue_fence_wait_timeout), 
>> breaks the centos6 build.
>> Specifically, I am getting:
>>   CC libmesautil_la-u_queue.lo
>> ../../../src/util/u_queue.c: In function '_util_queue_fence_wait_timeout':
>> ../../../src/util/u_queue.c:173:7: error: implicit declaration of function 
>> 'timespec_get' [-Werror=implicit-function-declaration]
>>timespec_get(, TIME_UTC);
>>^
>> cc1: some warnings being treated as errors
> 
> Thanks for the heads up. That's annoying. Any good ideas for how to test for 
> timespec_get availability? Some configure script check, I guess?
> 
> Cheers,
> Nicolai
> 
> 
>> Thanks!
>> George
> 
> 
> -- 
> Lerne, wie die Welt wirklich ist,
> Aber vergiss niemals, wie sie sein sollte.

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

[Mesa-dev] [PATCH v2] configure.ac: Define HAVE_ZLIB if zlib is found

[Jordan Justen]

v2:
 * Keep zlib required for autotools & meson (Emil)

Cc: Emil Velikov 
Cc: Dylan Baker 
Signed-off-by: Jordan Justen 
---
 configure.ac | 8 +++-
 meson.build  | 6 +-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..5db39e5a68d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -900,7 +900,13 @@ dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
 dnl Check for zlib
-PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
+PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
+  [have_zlib=yes], [have_zlib=no])
+if test "x$have_zlib" = xyes; then
+DEFINES="$DEFINES -DHAVE_ZLIB"
+else
+AC_MSG_ERROR([Building mesa on this platform requires zlib])
+fi
 
 dnl Check for pthreads
 AX_PTHREAD
diff --git a/meson.build b/meson.build
index 855c80ed658..d3ab3f6181d 100644
--- a/meson.build
+++ b/meson.build
@@ -661,8 +661,12 @@ if dep_libdrm.found()
   endif
 endif
 
-# TODO: some of these may be conditional
 dep_zlib = dependency('zlib', version : '>= 1.2.3')
+if dep_zlib.found()
+  pre_args += '-DHAVE_ZLIB'
+endif
+
+# TODO: some of these may be conditional
 dep_thread = dependency('threads')
 if dep_thread.found() and host_machine.system() == 'linux'
   pre_args += '-DHAVE_PTHREAD'
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH] i965/gen10: Use the correct form of | for the RCPFE workaround

[Anuj Phogat]

On Fri, Nov 10, 2017 at 1:39 PM, Jason Ekstrand  wrote:
> Found by inspection
>
> Fixes: d3d0fe4572f62474b86ef3a68405046c68b54062
> Cc: Anuj Phogat 
> ---
>  src/mesa/drivers/dri/i965/brw_pipe_control.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> index f5a9915..bae4ba7 100644
> --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> @@ -102,8 +102,8 @@ gen10_add_rcpfe_workaround_bits(uint32_t *flags)
> if (*flags & PIPE_CONTROL_RENDER_TARGET_FLUSH) {
>*flags = *flags | PIPE_CONTROL_STALL_AT_SCOREBOARD;
> } else if (*flags &
> - (PIPE_CONTROL_WRITE_IMMEDIATE ||
> -  PIPE_CONTROL_WRITE_DEPTH_COUNT ||
> + (PIPE_CONTROL_WRITE_IMMEDIATE |
> +  PIPE_CONTROL_WRITE_DEPTH_COUNT |
>PIPE_CONTROL_WRITE_TIMESTAMP)) {
>*flags = *flags | PIPE_CONTROL_DEPTH_STALL;
> }
> --
> 2.5.0.400.gff86faf
>
oops. Thanks for catching it.

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

Re: [Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Jordan Justen]

On 2017-11-10 13:15:10, Matt Turner wrote:
> Why?

For patch 4. Patch 4 can't happen unless zlib is optional because it's
a pain to enable zlib on windows.

No surprise, but the disk cache actually works without zlib. (Of
course, Tim originally implemented it without compression.)

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

Re: [Mesa-dev] [PATCH] i965/gen10: Use the correct form of | for the RCPFE workaround

[Rafael Antognolli]

It seems I missed that one when reviewing before, thank you.

Reviewed-by: Rafael Antognolli 

On Fri, Nov 10, 2017 at 01:39:22PM -0800, Jason Ekstrand wrote:
> Found by inspection
> 
> Fixes: d3d0fe4572f62474b86ef3a68405046c68b54062
> Cc: Anuj Phogat 
> ---
>  src/mesa/drivers/dri/i965/brw_pipe_control.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
> b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> index f5a9915..bae4ba7 100644
> --- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
> +++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
> @@ -102,8 +102,8 @@ gen10_add_rcpfe_workaround_bits(uint32_t *flags)
> if (*flags & PIPE_CONTROL_RENDER_TARGET_FLUSH) {
>*flags = *flags | PIPE_CONTROL_STALL_AT_SCOREBOARD;
> } else if (*flags &
> - (PIPE_CONTROL_WRITE_IMMEDIATE ||
> -  PIPE_CONTROL_WRITE_DEPTH_COUNT ||
> + (PIPE_CONTROL_WRITE_IMMEDIATE |
> +  PIPE_CONTROL_WRITE_DEPTH_COUNT |
>PIPE_CONTROL_WRITE_TIMESTAMP)) {
>*flags = *flags | PIPE_CONTROL_DEPTH_STALL;
> }
> -- 
> 2.5.0.400.gff86faf
> 
> ___
> 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] i965/gen10: Use the correct form of | for the RCPFE workaround

[Jason Ekstrand]

Found by inspection

Fixes: d3d0fe4572f62474b86ef3a68405046c68b54062
Cc: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/brw_pipe_control.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index f5a9915..bae4ba7 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -102,8 +102,8 @@ gen10_add_rcpfe_workaround_bits(uint32_t *flags)
if (*flags & PIPE_CONTROL_RENDER_TARGET_FLUSH) {
   *flags = *flags | PIPE_CONTROL_STALL_AT_SCOREBOARD;
} else if (*flags &
- (PIPE_CONTROL_WRITE_IMMEDIATE ||
-  PIPE_CONTROL_WRITE_DEPTH_COUNT ||
+ (PIPE_CONTROL_WRITE_IMMEDIATE |
+  PIPE_CONTROL_WRITE_DEPTH_COUNT |
   PIPE_CONTROL_WRITE_TIMESTAMP)) {
   *flags = *flags | PIPE_CONTROL_DEPTH_STALL;
}
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH] i965/gen10: Use the correct form of | for the RCPFE workaround

[Jason Ekstrand]

Found by inspection

Cc: Anuj Phogat 
---
 src/mesa/drivers/dri/i965/brw_pipe_control.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index f5a9915..bae4ba7 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -102,8 +102,8 @@ gen10_add_rcpfe_workaround_bits(uint32_t *flags)
if (*flags & PIPE_CONTROL_RENDER_TARGET_FLUSH) {
   *flags = *flags | PIPE_CONTROL_STALL_AT_SCOREBOARD;
} else if (*flags &
- (PIPE_CONTROL_WRITE_IMMEDIATE ||
-  PIPE_CONTROL_WRITE_DEPTH_COUNT ||
+ (PIPE_CONTROL_WRITE_IMMEDIATE |
+  PIPE_CONTROL_WRITE_DEPTH_COUNT |
   PIPE_CONTROL_WRITE_TIMESTAMP)) {
   *flags = *flags | PIPE_CONTROL_DEPTH_STALL;
}
-- 
2.5.0.400.gff86faf

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

Re: [Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Matt Turner]

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

Re: [Mesa-dev] [PATCH 0/5] Volatile and invariant LDS memory ops

[Nicolai Hähnle]

On 10.11.2017 19:24, Connor Abbott wrote:

On Fri, Nov 10, 2017 at 1:19 PM, Marek Olšák  wrote:

On Fri, Nov 10, 2017 at 6:55 PM, Nicolai Hähnle  wrote:

On 10.11.2017 18:43, Marek Olšák wrote:


On Fri, Nov 10, 2017 at 2:09 AM, Connor Abbott 
wrote:


On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák  wrote:


On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault 
wrote:




On Nov 10, 2017, at 07:41, Marek Olšák  wrote:

Hi,

This fixes the TCS gl_ClipDistance piglit failure that was uncovered
by a recent LLVM change. The solution is to set volatile on loads
and stores to enforce proper ordering.

Please review.




Every LDS access certainly should not be volatile. This kills all
optimizations, like formation of ds_read2_b32. What ordering issue are you
having?



It might be caused by inttoptr(NULL) that we do to declare LDS. There
is simply no ordering enforced, which is weird.



As soon as you do inttoptr(NULL), you've generated a poison value (in
LLVM legalese), so LLVM will assume that you never dereference it and
optimize accordingly. I think a GEP instruction without the inbounds
parameter set will get rid of the poison value, although I'm not sure
about the case where the offset is known to be zero. At least, that's
my reading of the langref text for the GEP instruction
(https://llvm.org/docs/LangRef.html#id215). If zero is a valid address
in LDS, then it sounds like LLVM needs to be fixed to disable this
optimization for certain address spaces. On the other hand, if you're
doing inttoptr(NULL) + offset, where "offset" is the result of a
ptrtoint somewhere, you should be doing inttoptr(offset) instead, and
then LLVM should never misbehave.



I don't think that using inttoptr before every load and store would be
better than volatile. The must be a better solution.



Can't we just allocate the required LDS memory explicitly like we did for
the LDS-based derivative computations?

It may require shuffling around a bit how/when we calculate the required
sizes, but it doesn't seem impossible.


We want to share the same declaration in TCS main and epilog parts.

Does LLVM know that LDS declarations are pre-initialized?
Do sized LDS declarations affect SIMD-occupancy-based optimizations?
Because Mesa always declares 64kB of LDS and the real value is
determined at runtime.


I don't know about the latter, but for the former, if you declare the
LDS variable as having external linkage, LLVM should assume that it
might be initialized beforehand -- exactly like a global non-static
variable in C.


Makes sense.

I don't think LLVM is really looking at LDS size too closely for 
anything, since LDS is per-thread group. But it's been a while since I 
checked.


So just declaring a 64/32 KB memory block and then potentially not using 
all of it is probably fine and is probably the best short-term solution 
(if it works).


It's a good point though that "shuffling around the computation of the 
required sizes" is potentially much more involved than I was thinking at 
first. It looks like if we wanted to be perfectly honest with LLVM about 
what's going on (and I believe we should, in the long run), we'd have to 
teach it a notion of "per-thread LDS memory". That requires more thought.


Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] add util_queue_fence_wait_timeout checkin breaks centos6 build

[Nicolai Hähnle]

On 10.11.2017 19:20, Kyriazis, George wrote:

Hello Nicolai,

Your commit e3a8013 (util/u_queue: add util_queue_fence_wait_timeout), breaks 
the centos6 build.

Specifically, I am getting:

   CC libmesautil_la-u_queue.lo
../../../src/util/u_queue.c: In function '_util_queue_fence_wait_timeout':
../../../src/util/u_queue.c:173:7: error: implicit declaration of function 
'timespec_get' [-Werror=implicit-function-declaration]
timespec_get(, TIME_UTC);
^
cc1: some warnings being treated as errors


Thanks for the heads up. That's annoying. Any good ideas for how to test 
for timespec_get availability? Some configure script check, I guess?


Cheers,
Nicolai





Thanks!

George




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/dri: fix deadlock when waiting on android fences

[Nicolai Hähnle]

On 10.11.2017 19:10, Marek Olšák wrote:

From: Marek Olšák 

Android fences can't be deferred, because st/dri calls fence_finish
with ctx = NULL, so the driver can't flush u_threaded_context.


Reviewed-by: Nicolai Hähnle 



---
  src/gallium/include/state_tracker/st_api.h   | 3 +--
  src/gallium/state_trackers/dri/dri_helpers.c | 3 +--
  src/mesa/state_tracker/st_manager.c  | 2 --
  3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 6cdaefc..a407b98 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -140,22 +140,21 @@ enum st_attachment_type {
  #define ST_ATTACHMENT_DEPTH_STENCIL_MASK  (1 << ST_ATTACHMENT_DEPTH_STENCIL)
  #define ST_ATTACHMENT_ACCUM_MASK  (1 << ST_ATTACHMENT_ACCUM)
  #define ST_ATTACHMENT_SAMPLE_MASK (1 << ST_ATTACHMENT_SAMPLE)
  
  /**

   * Flush flags.
   */
  #define ST_FLUSH_FRONT(1 << 0)
  #define ST_FLUSH_END_OF_FRAME (1 << 1)
  #define ST_FLUSH_WAIT (1 << 2)
-#define ST_FLUSH_DEFERRED (1 << 3)
-#define ST_FLUSH_FENCE_FD (1 << 4)
+#define ST_FLUSH_FENCE_FD (1 << 3)
  
  /**

   * Value to st_manager->get_param function.
   */
  enum st_manager_param {
 /**
  * The dri state tracker on old libGL's doesn't do the right thing
  * with regards to invalidating the framebuffers.
  *
  * For the mesa state tracker that means that it needs to invalidate
diff --git a/src/gallium/state_trackers/dri/dri_helpers.c 
b/src/gallium/state_trackers/dri/dri_helpers.c
index 4a61455..37ab2c2 100644
--- a/src/gallium/state_trackers/dri/dri_helpers.c
+++ b/src/gallium/state_trackers/dri/dri_helpers.c
@@ -109,22 +109,21 @@ dri2_create_fence(__DRIcontext *_ctx)
  
  static void *

  dri2_create_fence_fd(__DRIcontext *_ctx, int fd)
  {
 struct st_context_iface *stapi = dri_context(_ctx)->st;
 struct pipe_context *ctx = stapi->pipe;
 struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
  
 if (fd == -1) {

/* exporting driver created fence, flush: */
-  stapi->flush(stapi, ST_FLUSH_DEFERRED | ST_FLUSH_FENCE_FD,
-   >pipe_fence);
+  stapi->flush(stapi, ST_FLUSH_FENCE_FD, >pipe_fence);
 } else {
/* importing a foreign fence fd: */
ctx->create_fence_fd(ctx, >pipe_fence, fd);
 }
 if (!fence->pipe_fence) {
FREE(fence);
return NULL;
 }
  
 fence->driscreen = dri_screen(_ctx->driScreenPriv);

diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index 43d5dfd..4a1998c 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -627,22 +627,20 @@ st_framebuffers_purge(struct st_context *st)
  
  static void

  st_context_flush(struct st_context_iface *stctxi, unsigned flags,
   struct pipe_fence_handle **fence)
  {
 struct st_context *st = (struct st_context *) stctxi;
 unsigned pipe_flags = 0;
  
 if (flags & ST_FLUSH_END_OF_FRAME)

pipe_flags |= PIPE_FLUSH_END_OF_FRAME;
-   if (flags & ST_FLUSH_DEFERRED)
-  pipe_flags |= PIPE_FLUSH_DEFERRED;
 if (flags & ST_FLUSH_FENCE_FD)
pipe_flags |= PIPE_FLUSH_FENCE_FD;
  
 FLUSH_VERTICES(st->ctx, 0);

 FLUSH_CURRENT(st->ctx, 0);
 st_flush(st, fence, pipe_flags);
  
 if ((flags & ST_FLUSH_WAIT) && fence && *fence) {

st->pipe->screen->fence_finish(st->pipe->screen, NULL, *fence,
   PIPE_TIMEOUT_INFINITE);




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Jordan Justen]

On 2017-11-10 11:38:08, Emil Velikov wrote:
> On 10 November 2017 at 19:34, Emil Velikov  wrote:
> > On 10 November 2017 at 18:38, Dylan Baker  wrote:
> >> Quoting Jordan Justen (2017-11-10 10:24:36)
> >>> Cc: Emil Velikov 
> >>> Cc: Dylan Baker 
> >>> Signed-off-by: Jordan Justen 
> >>> ---
> >>>  configure.ac | 6 +-
> >>>  meson.build  | 6 +-
> >>>  2 files changed, 10 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/configure.ac b/configure.ac
> >>> index 411c4f6b3e0..213cfe132fb 100644
> >>> --- a/configure.ac
> >>> +++ b/configure.ac
> >>> @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
> >>>  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES 
> >>> -DHAVE_POSIX_MEMALIGN"])
> >>>
> >>>  dnl Check for zlib
> >>> -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
> >>> +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
> >>> +  [have_zlib=yes], [have_zlib=no])
> >>> +if test "x$have_zlib" = xyes; then
> >>> +DEFINES="$DEFINES -DHAVE_ZLIB"
> >>> +fi
> >>>
> >>>  dnl Check for pthreads
> >>>  AX_PTHREAD
> >>> diff --git a/meson.build b/meson.build
> >>> index 855c80ed658..4c27b3ba048 100644
> >>> --- a/meson.build
> >>> +++ b/meson.build
> >>> @@ -661,8 +661,12 @@ if dep_libdrm.found()
> >>>endif
> >>>  endif
> >>>
> >>> +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
> >>> +if dep_zlib.found()
> >>> +  pre_args += '-DHAVE_ZLIB'
> >>> +endif
> >>> +
> >>
> >> There's the gen_zipped_file.py in src/intel/genxml that uses zlib for 
> >> something,
> >> is not having zlib going to break that?
> >>
> > Those are the aubinator* family of tools. But more importantly, we
> > have compression of the disk cache.
> >
> > One solution is to opt for the disk cache approach -  ifdef the code
> > and build it only on !Windows platforms.
> > There should be others, but ^^ sounds like the shortest one.
> >
> Having read through the rest of the series:
> 
> The current HAVE_ZLIB approach looks good, modulo:
>  - keep zlib a hard requirement in autotools/meson, explicitly setting
> the define

Ok. I'll make this change.

Eventually, I think meson may replace scons, but it sounds like meson
has an easy way to pull in zlib on windows. I'll leave that to Dylan.
:)

>  - add missing guards in src/intel - only if you want to since the
> code is build on !Windows platforms anyway

I think I'll skip this for now. It'd need to be sent into the python
script, and really doesn't seem worth it. :)

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] i965: Make L3 configuration atom listen for TCS/TES program updates.

[Francisco Jerez]

Kenneth Graunke  writes:

> The L3 configuration code already considers the TCS and TES programs,
> but failed to listen for TCS/TES program changes.
>
> This was somehow missing.
>
> Cc: mesa-sta...@lists.freedesktop.org

Fixes: e9644cb1f96ccf7e155af09e90f6a7888f609a2d
Reviewed-by: Francisco Jerez 

> ---
>  src/mesa/drivers/dri/i965/gen7_l3_state.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c 
> b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> index 0b2d61f9e0f..06559f5db70 100644
> --- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
> +++ b/src/mesa/drivers/dri/i965/gen7_l3_state.c
> @@ -263,6 +263,8 @@ const struct brw_tracked_state gen7_l3_state = {
>   BRW_NEW_CS_PROG_DATA |
>   BRW_NEW_FS_PROG_DATA |
>   BRW_NEW_GS_PROG_DATA |
> + BRW_NEW_TCS_PROG_DATA |
> + BRW_NEW_TES_PROG_DATA |
>   BRW_NEW_VS_PROG_DATA,
> },
> .emit = emit_l3_state
> -- 
> 2.15.0
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable


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

Re: [Mesa-dev] [PATCH 5/5] meson: build gallium-xlib based glx

[Eric Anholt]

Dylan Baker  writes:

> [ Unknown signature status ]
> Quoting Eric Anholt (2017-11-08 13:26:12)
>> We shouldn't have to manually specify most of these deps, I think, since
>> they should be transitively pulled in by the static libraries using
>> them, right?  It's fine either way, though.
>> 
>> > +  install : true,
>> > +  version : '1.5.0',
>> 
>> Looks like this drops the MESA_MAJOR/MINOR/TINY version handling of the
>> automake version.  Other than this, and needing the build fix in patch
>> 3, the series is:
>> 
>> Reviewed-by: Eric Anholt 
>
> Matt and I did some git archeology and it appears that MESA_{MAJOR,MINOR,TINY}
> was removed in 2008 and this was never fixed.
>
> commit: 80f68e1b6a0e5bd2da799c659c963e213dbf9e66
>
> I think we should just remove those variables.

Excellent.


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

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Dylan Baker]

Quoting Jordan Justen (2017-11-10 11:43:45)
> On 2017-11-10 10:38:19, Dylan Baker wrote:
> > Quoting Jordan Justen (2017-11-10 10:24:36)
> > > Cc: Emil Velikov 
> > > Cc: Dylan Baker 
> > > Signed-off-by: Jordan Justen 
> > > ---
> > >  configure.ac | 6 +-
> > >  meson.build  | 6 +-
> > >  2 files changed, 10 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index 411c4f6b3e0..213cfe132fb 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
> > >  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES 
> > > -DHAVE_POSIX_MEMALIGN"])
> > >  
> > >  dnl Check for zlib
> > > -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
> > > +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
> > > +  [have_zlib=yes], [have_zlib=no])
> > > +if test "x$have_zlib" = xyes; then
> > > +DEFINES="$DEFINES -DHAVE_ZLIB"
> > > +fi
> > >  
> > >  dnl Check for pthreads
> > >  AX_PTHREAD
> > > diff --git a/meson.build b/meson.build
> > > index 855c80ed658..4c27b3ba048 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -661,8 +661,12 @@ if dep_libdrm.found()
> > >endif
> > >  endif
> > >  
> > > +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
> > > +if dep_zlib.found()
> > > +  pre_args += '-DHAVE_ZLIB'
> > > +endif
> > > +
> > 
> > There's the gen_zipped_file.py in src/intel/genxml that uses zlib for 
> > something,
> > is not having zlib going to break that?
> 
> I think not having zlib would break aubinator. So, I think zlib would
> need to be required if src/intel/tools is being built.
> 
> The only likely place where zlib wouldn't be found is windows.
> 
> One thing we could consider is bundling the MIT licensed miniz:
> 
> https://github.com/richgel999/miniz
> 
> instead of relying on an external zlib.
> 
> I'd prefer this HAVE_ZLIB change for now...

Meson has a wrap for zlib that is maintained by the meson project. So I think in
the long run we can just require zlib and have meson fetch and build it as part
of the windows build process.

I don't have a problem with this as-is for now, the aubinator tools are
non-default targets intended for developer use, and they're only useful on *nix
systems, where zlib is pretty much universally installed.

Dylan


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

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Jordan Justen]

On 2017-11-10 10:38:19, Dylan Baker wrote:
> Quoting Jordan Justen (2017-11-10 10:24:36)
> > Cc: Emil Velikov 
> > Cc: Dylan Baker 
> > Signed-off-by: Jordan Justen 
> > ---
> >  configure.ac | 6 +-
> >  meson.build  | 6 +-
> >  2 files changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 411c4f6b3e0..213cfe132fb 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
> >  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
> >  
> >  dnl Check for zlib
> > -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
> > +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
> > +  [have_zlib=yes], [have_zlib=no])
> > +if test "x$have_zlib" = xyes; then
> > +DEFINES="$DEFINES -DHAVE_ZLIB"
> > +fi
> >  
> >  dnl Check for pthreads
> >  AX_PTHREAD
> > diff --git a/meson.build b/meson.build
> > index 855c80ed658..4c27b3ba048 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -661,8 +661,12 @@ if dep_libdrm.found()
> >endif
> >  endif
> >  
> > +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
> > +if dep_zlib.found()
> > +  pre_args += '-DHAVE_ZLIB'
> > +endif
> > +
> 
> There's the gen_zipped_file.py in src/intel/genxml that uses zlib for 
> something,
> is not having zlib going to break that?

I think not having zlib would break aubinator. So, I think zlib would
need to be required if src/intel/tools is being built.

The only likely place where zlib wouldn't be found is windows.

One thing we could consider is bundling the MIT licensed miniz:

https://github.com/richgel999/miniz

instead of relying on an external zlib.

I'd prefer this HAVE_ZLIB change for now...

-Jordan

> >  # TODO: some of these may be conditional
> > -dep_zlib = dependency('zlib', version : '>= 1.2.3')
> >  dep_thread = dependency('threads')
> >  if dep_thread.found() and host_machine.system() == 'linux'
> >pre_args += '-DHAVE_PTHREAD'
> > -- 
> > 2.14.1
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Emil Velikov]

On 10 November 2017 at 19:34, Emil Velikov  wrote:
> On 10 November 2017 at 18:38, Dylan Baker  wrote:
>> Quoting Jordan Justen (2017-11-10 10:24:36)
>>> Cc: Emil Velikov 
>>> Cc: Dylan Baker 
>>> Signed-off-by: Jordan Justen 
>>> ---
>>>  configure.ac | 6 +-
>>>  meson.build  | 6 +-
>>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 411c4f6b3e0..213cfe132fb 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
>>>  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
>>>
>>>  dnl Check for zlib
>>> -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
>>> +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
>>> +  [have_zlib=yes], [have_zlib=no])
>>> +if test "x$have_zlib" = xyes; then
>>> +DEFINES="$DEFINES -DHAVE_ZLIB"
>>> +fi
>>>
>>>  dnl Check for pthreads
>>>  AX_PTHREAD
>>> diff --git a/meson.build b/meson.build
>>> index 855c80ed658..4c27b3ba048 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -661,8 +661,12 @@ if dep_libdrm.found()
>>>endif
>>>  endif
>>>
>>> +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
>>> +if dep_zlib.found()
>>> +  pre_args += '-DHAVE_ZLIB'
>>> +endif
>>> +
>>
>> There's the gen_zipped_file.py in src/intel/genxml that uses zlib for 
>> something,
>> is not having zlib going to break that?
>>
> Those are the aubinator* family of tools. But more importantly, we
> have compression of the disk cache.
>
> One solution is to opt for the disk cache approach -  ifdef the code
> and build it only on !Windows platforms.
> There should be others, but ^^ sounds like the shortest one.
>
Having read through the rest of the series:

The current HAVE_ZLIB approach looks good, modulo:
 - keep zlib a hard requirement in autotools/meson, explicitly setting
the define
 - add missing guards in src/intel - only if you want to since the
code is build on !Windows platforms anyway

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

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Emil Velikov]

On 10 November 2017 at 18:38, Dylan Baker  wrote:
> Quoting Jordan Justen (2017-11-10 10:24:36)
>> Cc: Emil Velikov 
>> Cc: Dylan Baker 
>> Signed-off-by: Jordan Justen 
>> ---
>>  configure.ac | 6 +-
>>  meson.build  | 6 +-
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 411c4f6b3e0..213cfe132fb 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
>>  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
>>
>>  dnl Check for zlib
>> -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
>> +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
>> +  [have_zlib=yes], [have_zlib=no])
>> +if test "x$have_zlib" = xyes; then
>> +DEFINES="$DEFINES -DHAVE_ZLIB"
>> +fi
>>
>>  dnl Check for pthreads
>>  AX_PTHREAD
>> diff --git a/meson.build b/meson.build
>> index 855c80ed658..4c27b3ba048 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -661,8 +661,12 @@ if dep_libdrm.found()
>>endif
>>  endif
>>
>> +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
>> +if dep_zlib.found()
>> +  pre_args += '-DHAVE_ZLIB'
>> +endif
>> +
>
> There's the gen_zipped_file.py in src/intel/genxml that uses zlib for 
> something,
> is not having zlib going to break that?
>
Those are the aubinator* family of tools. But more importantly, we
have compression of the disk cache.

One solution is to opt for the disk cache approach -  ifdef the code
and build it only on !Windows platforms.
There should be others, but ^^ sounds like the shortest one.

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

Re: [Mesa-dev] [PATCH 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

[Ian Romanick]

Reviewed-by: Ian Romanick 


On November 10, 2017 12:17:38 PM Jordan Justen  
wrote:



On 2017-11-10 08:43:37, Ian Romanick wrote:


The one thing I would add is an issues section with a single issue about
the decision to use a single enum for everything.


How does this sound?

diff --git a/docs/specs/MESA_program_binary_formats.txt 
b/docs/specs/MESA_program_binary_formats.txt

index 65bd1a1a739..65a2adab8b7 100644
--- a/docs/specs/MESA_program_binary_formats.txt
+++ b/docs/specs/MESA_program_binary_formats.txt
@@ -54,6 +54,26 @@ New State

 None.

+Issues
+
+(1) Should we have a different format for each driver?
+
+  RESOLVED. Since Mesa supports multiple hardware drivers, having
+  a single format may cause separate drivers to have to reject a
+  binary for another type of hardware on the same machine. This
+  could lead to an application having to invalidate and get a new
+  binary more often.
+
+  This extension, at least initially, does not to attempt to
+  define a new token for each driver since systems that run
+  multiple drivers are not the common case.
+
+  Additionally, drivers in Mesa are now gaining the ability to
+  transparently cache shader programs. Therefore, although they
+  may need to provide the application with a new binary more
+  often, they likely can retrieve the program from the cache
+  rather than performing an expensive recompile.
+
 Revision History

 #0110/28/2017Jordan Justen   First draft.





On November 9, 2017 12:42:58 AM Jordan Justen 
wrote:

> Similar idea to Tim's "spec: MESA_program_binary", but simplified and
> written to support both ARB_get_program_binary and
> OES_get_program_binary.
>
> Signed-off-by: Jordan Justen 
> Cc: Ian Romanick 
> Cc: Timothy Arceri 
> ---
>  docs/specs/MESA_program_binary_formats.txt | 59 
++

>  docs/specs/enums.txt   |  3 ++
>  src/mapi/glapi/registry/gl.xml |  2 +-
>  3 files changed, 63 insertions(+), 1 deletion(-)
>  create mode 100644 docs/specs/MESA_program_binary_formats.txt
>
> diff --git a/docs/specs/MESA_program_binary_formats.txt
> b/docs/specs/MESA_program_binary_formats.txt
> new file mode 100644
> index 000..65bd1a1a739
> --- /dev/null
> +++ b/docs/specs/MESA_program_binary_formats.txt
> @@ -0,0 +1,59 @@
> +Name
> +
> +MESA_program_binary_formats
> +
> +Name Strings
> +
> +GL_MESA_program_binary_formats
> +
> +Contact
> +
> +Jordan Justen (jordan.l.justen 'at' intel.com)
> +
> +Status
> +
> +Complete.
> +
> +Version
> +
> +Last Modified Date: October 28, 2017
> +Revision: #1
> +
> +Number
> +
> +TBD
> +
> +Dependencies
> +
> +For use with the OpenGL ARB_get_program_binary extension, or the
> +OpenGL ES OES_get_program_binary extension.
> +
> +Overview
> +
> +The get_program_binary exensions require a GLenum binaryFormat.
> +This extension documents that format for use with Mesa.
> +
> +New Procedures and Functions
> +
> +None.
> +
> +New Tokens
> +
> +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> +
> +For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> +returned from GetProgramBinary calls in the 
> +parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
> +
> +For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> +returned from GetProgramBinaryOES calls in the 
> +parameter and when retrieving the value of
> +PROGRAM_BINARY_FORMATS_OES.
> +
> +New State
> +
> +None.
> +
> +Revision History
> +
> +#0110/28/2017Jordan Justen   First draft.
> diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
> index 4b0485f3490..8109cc50f97 100644
> --- a/docs/specs/enums.txt
> +++ b/docs/specs/enums.txt
> @@ -63,6 +63,9 @@ GL_MESAX_texture_stack:
>   GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
>   GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
>
> +GL_MESA_program_binary_formats:
> +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> +
>  GL_MESA_program_debug
>   GL_FRAGMENT_PROGRAM_POSITION_MESA   0x8BB0
>   GL_FRAGMENT_PROGRAM_CALLBACK_MESA   0x8BB1
> diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
> index cbabe11b398..7360414bb35 100644
> --- a/src/mapi/glapi/registry/gl.xml
> +++ b/src/mapi/glapi/registry/gl.xml
> @@ -5505,7 +5505,7 @@ typedef unsigned int GLhandleARB;
>  
>  
>  
> -
> +
>  
>
>  
> --
> 2.14.1





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

Re: [Mesa-dev] [PATCH] anv: don't crash when creating a huge image

[Jason Ekstrand]

On Fri, Nov 10, 2017 at 10:48 AM, Chad Versace 
wrote:

> On Thu 09 Nov 2017, Jason Ekstrand wrote:
> > On Thu, Nov 9, 2017 at 4:23 PM, Chad Versace <[1]
> chadvers...@chromium.org>
> > wrote:
> >
> > On Wed 08 Nov 2017, Jason Ekstrand wrote:
> > > On Wed, Nov 8, 2017 at 1:34 AM, Samuel Iglesias Gonsálvez <[1]
> > > [2]sigles...@igalia.com> wrote:
> > >
> > > The HW has some limits but, according to the spec, we can
> create
> > > the image as it has not yet any memory backing it. When we
> allocate
> > > that memory, then we fail following what Vulkan spec, "10.2.
> Device
> > > Memory" says when talking about vkAllocateMemory():
> > >
> > > "Some platforms may have a limit on the maximum size of a
> single
> > >  allocation. For example, certain systems may fail to create
> > >  allocations with a size greater than or equal to 4GB. Such a
> limit
> > is
> > >  implementation-dependent, and if such a failure occurs then
> the
> > error
> > >  VK_ERROR_OUT_OF_DEVICE_MEMORY must be returned."
> > >
> > > Fixes the crashes on BDW for the following tests:
> > >
> > > dEQP-VK.pipeline.render_to_image.core.2d_array.huge.*
> > > dEQP-VK.pipeline.render_to_image.core.cube_array.huge.*
> > >
> > > Signed-off-by: Samuel Iglesias Gonsálvez <[2][3]
> sigles...@igalia.com>
> > > ---
> > >
> > > Jason, I was tempted to move this piece of code to
> anv_AllocateMemory
> > ()
> > > but then I found the kernel relocation limitation of 32-bit...
> Is
> > that
> > > limitation still applicable? Or was it from the BDW age and we
> forgot
> > > to update that limitation for gen9+?
> > >
> > >
> > > We're still using relocations on all hardware so it applies to
> everything
> > > today.  One of my 2018 projects is to fix that and get rid of
> relocations
> > on
> > > gen8+.
> > >
> > >
> > > Sam
> > >
> > >  src/intel/isl/isl.c | 22 --
> > >  1 file changed, 22 deletions(-)
> > >
> > > diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> > > index 59f512fc050..aaadcbaf991 100644
> > > --- a/src/intel/isl/isl.c
> > > +++ b/src/intel/isl/isl.c
> > > @@ -1472,28 +1472,6 @@ isl_surf_init_s(const struct isl_device
> *dev,
> > >base_alignment = MAX(info->min_alignment, tile_size);
> > > }
> > >
> > > -   if (ISL_DEV_GEN(dev) < 9) {
> > > -  /* From the Broadwell PRM Vol 5, Surface Layout:
> > > -   *
> > > -   *"In addition to restrictions on maximum height,
> width,
> > and
> > > depth,
> > > -   * surfaces are also restricted to a maximum size in
> > bytes. This
> > > -   * maximum is 2 GB for all products and all surface
> > types."
> > > -   *
> > > -   * This comment is applicable to all Pre-gen9 platforms.
> > > -   */
> > > -  if (size > (uint64_t) 1 << 31)
> > > - return false;
> > > -   } else {
> > > -  /* From the Skylake PRM Vol 5, Maximum Surface Size in
> Bytes:
> > > -   *"In addition to restrictions on maximum height,
> width,
> > and
> > > depth,
> > > -   * surfaces are also restricted to a maximum size
> of 2^38
> > bytes.
> > > -   * All pixels within the surface must be contained
> within
> > 2^38
> > > bytes
> > > -   * of the base address."
> > > -   */
> > > -  if (size > (uint64_t) 1 << 38)
> > > - return false;
> > > -   }
> >
> > I think it very unwise to delete code that enforces requirements
> defined
> > by the hardware spec. Deleting the code doesn't make the hardware
> > requirements go away :)
> >
> > > I'm not sure how I feel about removing this from ISL.  There are
> really
> > two
> > > limitations going on here.  One is a limitation imposed by
> relocations,
> > and the
> > > other is some sort of fundamental hardware surface size
> limitation.  Most
> > > likely, the surface size limitation has to do with how many bits
> they use
> > for
> > > image address computations in the hardware.  Most likely, on gen8,
> they
> > do all
> > > of the internal calculations in 32 bits and only convert to 48 at
> the end
> > when
> > > they need to add it to Surface Base Address.
> > >
> > > If my understanding is correct then we will still have this
> limitation on
> > gen8
> > > even after we get rid of relocations and remove the BO size
> limitation.
> > I see
> > > a couple of options, neither of which I like very much:
> > >

[Mesa-dev] [Bug 103412] gallium/wgl: Another fix to context creation without prior SetPixelFormat()

[bugzilla-daemon]

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

--- Comment #1 from Brian Paul  ---
Thanks.  Looks good AFAICT.  I'll do a little reformatting and testing before
pushing.

-- 
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] gallium/xlib: remove GL_{MAJOR,MINOR,TINY}

[Brian Paul]

On 11/10/2017 11:08 AM, Emil Velikov wrote:

On 10 November 2017 at 17:53, Dylan Baker  wrote:

These variables were removed from autotools in 2008 (sha:
80f68e1b6a0e5bd2da799c), but they have lived on here. The Scons build
meanwhile doesn't set a patch/tiny version at all, just major and minor.
This patch removes the unused variables and simply sets the version,
leaving patch/tiny as 0 since that's what the autotools build as been
doing forever. This shouldn't change any behavior.


Patch is
Reviewed-by: Emil Velikov 

I believe I poked Brian/Jose for clarification on the differing
version numbers, but cannot find it atm.
Brian can you some light on the topic? The Linux OpenGL ABI states
"libGL.so.1" and does not mention anything more on the topic.


Yeah, I don't recall the details any more.  I think all we need is 
libGL.so.1 to remain unchanged.



-Brian

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

Re: [Mesa-dev] [PATCH] anv: don't crash when creating a huge image

[Chad Versace]

On Thu 09 Nov 2017, Jason Ekstrand wrote:
> On Thu, Nov 9, 2017 at 4:23 PM, Chad Versace <[1]chadvers...@chromium.org>
> wrote:
> 
> On Wed 08 Nov 2017, Jason Ekstrand wrote:
> > On Wed, Nov 8, 2017 at 1:34 AM, Samuel Iglesias Gonsálvez <[1]
> > [2]sigles...@igalia.com> wrote:
> >
> >     The HW has some limits but, according to the spec, we can create
> >     the image as it has not yet any memory backing it. When we allocate
> >     that memory, then we fail following what Vulkan spec, "10.2. Device
> >     Memory" says when talking about vkAllocateMemory():
> >
> >     "Some platforms may have a limit on the maximum size of a single
> >      allocation. For example, certain systems may fail to create
> >      allocations with a size greater than or equal to 4GB. Such a limit
> is
> >      implementation-dependent, and if such a failure occurs then the
> error
> >      VK_ERROR_OUT_OF_DEVICE_MEMORY must be returned."
> >
> >     Fixes the crashes on BDW for the following tests:
> >
> >     dEQP-VK.pipeline.render_to_image.core.2d_array.huge.*
> >     dEQP-VK.pipeline.render_to_image.core.cube_array.huge.*
> >
> >     Signed-off-by: Samuel Iglesias Gonsálvez 
> <[2][3]sigles...@igalia.com>
> >     ---
> >
> >     Jason, I was tempted to move this piece of code to 
> anv_AllocateMemory
> ()
> >     but then I found the kernel relocation limitation of 32-bit... Is
> that
> >     limitation still applicable? Or was it from the BDW age and we 
> forgot
> >     to update that limitation for gen9+?
> >
> >
> > We're still using relocations on all hardware so it applies to 
> everything
> > today.  One of my 2018 projects is to fix that and get rid of 
> relocations
> on
> > gen8+.
> >  
> >
> >     Sam
> >
> >      src/intel/isl/isl.c | 22 --
> >      1 file changed, 22 deletions(-)
> >
> >     diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> >     index 59f512fc050..aaadcbaf991 100644
> >     --- a/src/intel/isl/isl.c
> >     +++ b/src/intel/isl/isl.c
> >     @@ -1472,28 +1472,6 @@ isl_surf_init_s(const struct isl_device *dev,
> >            base_alignment = MAX(info->min_alignment, tile_size);
> >         }
> >
> >     -   if (ISL_DEV_GEN(dev) < 9) {
> >     -      /* From the Broadwell PRM Vol 5, Surface Layout:
> >     -       *
> >     -       *    "In addition to restrictions on maximum height, width,
> and
> >     depth,
> >     -       *     surfaces are also restricted to a maximum size in
> bytes. This
> >     -       *     maximum is 2 GB for all products and all surface
> types."
> >     -       *
> >     -       * This comment is applicable to all Pre-gen9 platforms.
> >     -       */
> >     -      if (size > (uint64_t) 1 << 31)
> >     -         return false;
> >     -   } else {
> >     -      /* From the Skylake PRM Vol 5, Maximum Surface Size in Bytes:
> >     -       *    "In addition to restrictions on maximum height, width,
> and
> >     depth,
> >     -       *     surfaces are also restricted to a maximum size of 2^38
> bytes.
> >     -       *     All pixels within the surface must be contained within
> 2^38
> >     bytes
> >     -       *     of the base address."
> >     -       */
> >     -      if (size > (uint64_t) 1 << 38)
> >     -         return false;
> >     -   }
> 
> I think it very unwise to delete code that enforces requirements defined
> by the hardware spec. Deleting the code doesn't make the hardware
> requirements go away :)
>
> > I'm not sure how I feel about removing this from ISL.  There are really
> two
> > limitations going on here.  One is a limitation imposed by relocations,
> and the
> > other is some sort of fundamental hardware surface size limitation.  
> Most
> > likely, the surface size limitation has to do with how many bits they 
> use
> for
> > image address computations in the hardware.  Most likely, on gen8, they
> do all
> > of the internal calculations in 32 bits and only convert to 48 at the 
> end
> when
> > they need to add it to Surface Base Address.
> >
> > If my understanding is correct then we will still have this limitation 
> on
> gen8
> > even after we get rid of relocations and remove the BO size limitation. 
> I see
> > a couple of options, neither of which I like very much:
> >
> >  1) Take something like this patch and then keep the BO size limitation
> on BDW
> > to 2GiB when we get rid of relocations even though it's artificial.
> >  2) "Gracefully" handle isl_surf_init failure by doing a debug_log and
> > succeeding but setting the image size (that will be returned by
>

Re: [Mesa-dev] [PATCH] threads: fix MinGW build breakage

[Jon Turney]

On 10/11/2017 15:42, Nicolai Hähnle wrote:

On 10.11.2017 14:00, Jon Turney wrote:

On 09/11/2017 21:41, Nicolai Hähnle wrote:

Sorry for the mess.


I'm going to suggest that the fallback declaration of timespec_get() 
also needs to be provided for POSIX systems which don't have it.


Not noticed previously as it (or xtime_get()) doesn't seem to have had 
any users, prior to this series.


Patch attached.


Do you have a system where this is actually needed? Currently 
HAVE_TIMESPEC_GET is only defined in threads_win32.h, so some more 
detection logic somewhere would be required if this actually turns out 
to be an issue.


Hmm.. yes, I'd assumed that HAVE_TIMESPEC_GET was the result of an 
autoconf check, but it isn't.


Cygwin doesn't (currently) have timespec_get().

I'm thinking the correct solution here is actually to unconditionally 
declare timespec_get(), just like all the other C11 thread functions 
(and as the unused xtime_get() was, prior to 
f1a364878431c8c5f4fd38b40b9766449e49f552)?


Revised patch attached.
From f71d15ccab81af7dfb7393ed947827f02d333733 Mon Sep 17 00:00:00 2001
From: Jon Turney 
Date: Fri, 10 Nov 2017 12:22:25 +
Subject: [PATCH] Provide timespec_get() in C11 thread.h emulation on POSIX
 also

Signed-off-by: Jon Turney 
---
 include/c11/threads_posix.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 7bf6a0f6ef6..25076f1b6e5 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -382,7 +382,6 @@ tss_set(tss_t key, void *val)
 
 /* 7.25.7 Time functions */
 // 7.25.6.1
-#if 0
 static inline int
 timespec_get(struct timespec *ts, int base)
 {
@@ -393,4 +392,3 @@ timespec_get(struct timespec *ts, int base)
 }
 return 0;
 }
-#endif
-- 
2.15.0

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

Re: [Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Dylan Baker]

Quoting Jordan Justen (2017-11-10 10:24:36)
> Cc: Emil Velikov 
> Cc: Dylan Baker 
> Signed-off-by: Jordan Justen 
> ---
>  configure.ac | 6 +-
>  meson.build  | 6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 411c4f6b3e0..213cfe132fb 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -900,7 +900,11 @@ dnl See if posix_memalign is available
>  AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
>  
>  dnl Check for zlib
> -PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
> +PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
> +  [have_zlib=yes], [have_zlib=no])
> +if test "x$have_zlib" = xyes; then
> +DEFINES="$DEFINES -DHAVE_ZLIB"
> +fi
>  
>  dnl Check for pthreads
>  AX_PTHREAD
> diff --git a/meson.build b/meson.build
> index 855c80ed658..4c27b3ba048 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -661,8 +661,12 @@ if dep_libdrm.found()
>endif
>  endif
>  
> +dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
> +if dep_zlib.found()
> +  pre_args += '-DHAVE_ZLIB'
> +endif
> +

There's the gen_zipped_file.py in src/intel/genxml that uses zlib for something,
is not having zlib going to break that?

>  # TODO: some of these may be conditional
> -dep_zlib = dependency('zlib', version : '>= 1.2.3')
>  dep_thread = dependency('threads')
>  if dep_thread.found() and host_machine.system() == 'linux'
>pre_args += '-DHAVE_PTHREAD'
> -- 
> 2.14.1
> 


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

[Mesa-dev] [Bug 103674] u_queue.c:173:7: error: implicit declaration of function 'timespec_get' is invalid in C99

[bugzilla-daemon]

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

Bug ID: 103674
   Summary: u_queue.c:173:7: error: implicit declaration of
function 'timespec_get' is invalid in C99
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Mac OS X (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org

mesa: d1edf6e3962e187a1213dd4064ba3b6fb6c3ea4f (master 17.4.0-devel)

u_queue.c:173:7: error: implicit declaration of function 'timespec_get' is
invalid in C99 [-Werror,-Wimplicit-function-declaration]
  timespec_get(, TIME_UTC);
  ^

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

[Mesa-dev] [Bug 103671] os_time.c:104:4: error: implicit declaration of function 'usleep' is invalid in C99

[bugzilla-daemon]

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

Vinson Lee  changed:

   What|Removed |Added

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

--- Comment #2 from Vinson Lee  ---
commit 764f1e4d4509448797008c2b20956b31d8360ef0
Author: Jon Turney 
Date:   Fri Nov 10 11:41:13 2017 +

util: include unistd.h, which may be required for usleep prototype

This seems to be dropped in 222a2fb9 "util: move os_time.[ch] to src/util"

../../../src/util/os_time.c: In function ‘os_time_sleep’:
../../../src/util/os_time.c:104:4: error: implicit declaration of function
‘usleep’ [-Werror=implicit-function-declaration]

Signed-off-by: Jon Turney 
Reviewed-by: Nicolai Hähnle 

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

[Mesa-dev] [Bug 103671] os_time.c:104:4: error: implicit declaration of function 'usleep' is invalid in C99

[bugzilla-daemon]

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

Jon Turney  changed:

   What|Removed |Added

 CC||jon.tur...@dronecode.org.uk

--- Comment #1 from Jon Turney  ---
I guess this is fixed by 764f1e4d4509448797008c2b20956b31d8360ef0

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

[Mesa-dev] [PATCH 4/4] compiler: Fold shader_cache in with libglsl sources

[Jordan Justen]

It appears that we include the shader cache sources into libglsl
regardless.

The Meson build already does this.

Signed-off-by: Jordan Justen 
---
 src/compiler/Android.glsl.mk  | 3 +--
 src/compiler/Makefile.glsl.am | 3 +--
 src/compiler/Makefile.sources | 6 ++
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/compiler/Android.glsl.mk b/src/compiler/Android.glsl.mk
index 0aabafa2673..8533830833f 100644
--- a/src/compiler/Android.glsl.mk
+++ b/src/compiler/Android.glsl.mk
@@ -35,8 +35,7 @@ include $(CLEAR_VARS)
 
 LOCAL_SRC_FILES := \
$(LIBGLCPP_FILES) \
-   $(LIBGLSL_FILES) \
-   $(LIBGLSL_SHADER_CACHE_FILES)
+   $(LIBGLSL_FILES)
 
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
diff --git a/src/compiler/Makefile.glsl.am b/src/compiler/Makefile.glsl.am
index 179f415fe6f..11ff14b2852 100644
--- a/src/compiler/Makefile.glsl.am
+++ b/src/compiler/Makefile.glsl.am
@@ -134,8 +134,7 @@ glsl_libglsl_la_LIBADD = \
 
 glsl_libglsl_la_SOURCES =  \
$(LIBGLSL_GENERATED_FILES)  \
-   $(LIBGLSL_FILES)\
-   $(LIBGLSL_SHADER_CACHE_FILES)
+   $(LIBGLSL_FILES)
 
 glsl_libstandalone_la_SOURCES = \
$(GLSL_COMPILER_CXX_FILES)
diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 2ab8e163a26..afdfad82e56 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -140,13 +140,11 @@ LIBGLSL_FILES = \
glsl/propagate_invariance.cpp \
glsl/s_expression.cpp \
glsl/s_expression.h \
+   glsl/shader_cache.cpp \
+   glsl/shader_cache.h \
glsl/string_to_uint_map.cpp \
glsl/string_to_uint_map.h
 
-LIBGLSL_SHADER_CACHE_FILES = \
-   glsl/shader_cache.cpp \
-   glsl/shader_cache.h
-
 # glsl_compiler
 
 GLSL_COMPILER_CXX_FILES = \
-- 
2.14.1

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

[Mesa-dev] [PATCH 3/4] util/disk_cache: Make zlib support optional

[Jordan Justen]

Cc: Timothy Arceri 
Signed-off-by: Jordan Justen 
---
 src/util/disk_cache.c | 129 ++
 1 file changed, 15 insertions(+), 114 deletions(-)

diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
index fde6e2e0974..911ca8f9234 100644
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include "zlib.h"
 
 #include "util/crc32.h"
 #include "util/debug.h"
@@ -46,6 +45,7 @@
 #include "util/u_queue.h"
 #include "util/mesa-sha1.h"
 #include "util/ralloc.h"
+#include "util/u_zlib.h"
 #include "main/errors.h"
 
 #include "disk_cache.h"
@@ -702,75 +702,6 @@ write_all(int fd, const void *buf, size_t count)
return done;
 }
 
-/* From the zlib docs:
- *"If the memory is available, buffers sizes on the order of 128K or 256K
- *bytes should be used."
- */
-#define BUFSIZE 256 * 1024
-
-/**
- * Compresses cache entry in memory and writes it to disk. Returns the size
- * of the data written to disk.
- */
-static size_t
-deflate_and_write_to_disk(const void *in_data, size_t in_data_size, int dest,
-  const char *filename)
-{
-   unsigned char out[BUFSIZE];
-
-   /* allocate deflate state */
-   z_stream strm;
-   strm.zalloc = Z_NULL;
-   strm.zfree = Z_NULL;
-   strm.opaque = Z_NULL;
-   strm.next_in = (uint8_t *) in_data;
-   strm.avail_in = in_data_size;
-
-   int ret = deflateInit(, Z_BEST_COMPRESSION);
-   if (ret != Z_OK)
-   return 0;
-
-   /* compress until end of in_data */
-   size_t compressed_size = 0;
-   int flush;
-   do {
-  int remaining = in_data_size - BUFSIZE;
-  flush = remaining > 0 ? Z_NO_FLUSH : Z_FINISH;
-  in_data_size -= BUFSIZE;
-
-  /* Run deflate() on input until the output buffer is not full (which
-   * means there is no more data to deflate).
-   */
-  do {
- strm.avail_out = BUFSIZE;
- strm.next_out = out;
-
- ret = deflate(, flush);/* no bad return value */
- assert(ret != Z_STREAM_ERROR);  /* state not clobbered */
-
- size_t have = BUFSIZE - strm.avail_out;
- compressed_size += have;
-
- ssize_t written = write_all(dest, out, have);
- if (written == -1) {
-(void)deflateEnd();
-return 0;
- }
-  } while (strm.avail_out == 0);
-
-  /* all input should be used */
-  assert(strm.avail_in == 0);
-
-   } while (flush != Z_FINISH);
-
-   /* stream should be complete */
-   assert(ret == Z_STREAM_END);
-
-   /* clean up and return */
-   (void)deflateEnd();
-   return compressed_size;
-}
-
 static struct disk_cache_put_job *
 create_put_job(struct disk_cache *cache, const cache_key key,
const void *data, size_t size,
@@ -958,9 +889,12 @@ cache_put(void *job, int thread_index)
 * rename them atomically to the destination filename, and also
 * perform an atomic increment of the total cache size.
 */
-   size_t file_size = deflate_and_write_to_disk(dc_job->data, dc_job->size,
-fd, filename_tmp);
-   if (file_size == 0) {
+#ifdef HAVE_ZLIB
+   size_t file_size = zlib_deflate_to_fd(dc_job->data, dc_job->size, fd);
+#else
+   size_t file_size = write_all(fd, dc_job->data, dc_job->size);
+#endif
+   if (file_size <= 0) {
   unlink(filename_tmp);
   goto done;
}
@@ -1006,45 +940,6 @@ disk_cache_put(struct disk_cache *cache, const cache_key 
key,
}
 }
 
-/**
- * Decompresses cache entry, returns true if successful.
- */
-static bool
-inflate_cache_data(uint8_t *in_data, size_t in_data_size,
-   uint8_t *out_data, size_t out_data_size)
-{
-   z_stream strm;
-
-   /* allocate inflate state */
-   strm.zalloc = Z_NULL;
-   strm.zfree = Z_NULL;
-   strm.opaque = Z_NULL;
-   strm.next_in = in_data;
-   strm.avail_in = in_data_size;
-   strm.next_out = out_data;
-   strm.avail_out = out_data_size;
-
-   int ret = inflateInit();
-   if (ret != Z_OK)
-  return false;
-
-   ret = inflate(, Z_NO_FLUSH);
-   assert(ret != Z_STREAM_ERROR);  /* state not clobbered */
-
-   /* Unless there was an error we should have decompressed everything in one
-* go as we know the uncompressed file size.
-*/
-   if (ret != Z_STREAM_END) {
-  (void)inflateEnd();
-  return false;
-   }
-   assert(strm.avail_out == 0);
-
-   /* clean up and return */
-   (void)inflateEnd();
-   return true;
-}
-
 void *
 disk_cache_get(struct disk_cache *cache, const cache_key key, size_t *size)
 {
@@ -1130,11 +1025,17 @@ disk_cache_get(struct disk_cache *cache, const 
cache_key key, size_t *size)
if (ret == -1)
   goto fail;
 
+#ifdef HAVE_ZLIB
/* Uncompress the cache data */
uncompressed_data = malloc(cf_data.uncompressed_size);
-   if (!inflate_cache_data(data, cache_data_size, uncompressed_data,
-   cf_data.uncompressed_size))
+   if 

[Mesa-dev] [PATCH 2/4] util: Add u_zlib zlib wrappers

[Jordan Justen]

Signed-off-by: Jordan Justen 
---
 src/util/Makefile.sources |   4 +-
 src/util/meson.build  |   2 +
 src/util/u_zlib.c | 154 ++
 src/util/u_zlib.h |  50 +++
 4 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 src/util/u_zlib.c
 create mode 100644 src/util/u_zlib.h

diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index 104ecae8ed3..3666e536201 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -56,7 +56,9 @@ MESA_UTIL_FILES := \
u_string.h \
u_thread.h \
u_vector.c \
-   u_vector.h
+   u_vector.h \
+   u_zlib.c \
+   u_zlib.h
 
 MESA_UTIL_GENERATED_FILES = \
format_srgb.c
diff --git a/src/util/meson.build b/src/util/meson.build
index ac86c9e111e..340b07c265d 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -81,6 +81,8 @@ files_mesa_util = files(
   'u_thread.h',
   'u_vector.c',
   'u_vector.h',
+  'u_zlib.c',
+  'u_zlib.h',
 )
 
 install_data('drirc', install_dir : get_option('sysconfdir'))
diff --git a/src/util/u_zlib.c b/src/util/u_zlib.c
new file mode 100644
index 000..2d961cfaa75
--- /dev/null
+++ b/src/util/u_zlib.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND 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.
+ */
+
+#ifdef HAVE_ZLIB
+
+#include "u_zlib.h"
+
+#include 
+#include 
+#include 
+
+static ssize_t
+write_all(int fd, const void *buf, size_t count)
+{
+   const char *out = buf;
+   ssize_t written;
+   size_t done;
+
+   for (done = 0; done < count; done += written) {
+  written = write(fd, out + done, count - done);
+  if (written == -1)
+ return -1;
+   }
+   return done;
+}
+
+/* From the zlib docs:
+ *"If the memory is available, buffers sizes on the order of 128K or 256K
+ *bytes should be used."
+ */
+#define BUFSIZE 256 * 1024
+
+/**
+ * Compresses cache entry in memory and writes it to disk. Returns the size
+ * of the data written to disk.
+ */
+size_t
+zlib_deflate_to_fd(const void *in_data, size_t in_data_size, int fd)
+{
+   unsigned char out[BUFSIZE];
+
+   /* allocate deflate state */
+   z_stream strm;
+   strm.zalloc = Z_NULL;
+   strm.zfree = Z_NULL;
+   strm.opaque = Z_NULL;
+   strm.next_in = (uint8_t *) in_data;
+   strm.avail_in = in_data_size;
+
+   int ret = deflateInit(, Z_BEST_COMPRESSION);
+   if (ret != Z_OK)
+   return 0;
+
+   /* compress until end of in_data */
+   size_t compressed_size = 0;
+   int flush;
+   do {
+  int remaining = in_data_size - BUFSIZE;
+  flush = remaining > 0 ? Z_NO_FLUSH : Z_FINISH;
+  in_data_size -= BUFSIZE;
+
+  /* Run deflate() on input until the output buffer is not full (which
+   * means there is no more data to deflate).
+   */
+  do {
+ strm.avail_out = BUFSIZE;
+ strm.next_out = out;
+
+ ret = deflate(, flush);/* no bad return value */
+ assert(ret != Z_STREAM_ERROR);  /* state not clobbered */
+
+ size_t have = BUFSIZE - strm.avail_out;
+ compressed_size += have;
+
+ ssize_t written = write_all(fd, out, have);
+ if (written == -1) {
+(void)deflateEnd();
+return 0;
+ }
+  } while (strm.avail_out == 0);
+
+  /* all input should be used */
+  assert(strm.avail_in == 0);
+
+   } while (flush != Z_FINISH);
+
+   /* stream should be complete */
+   assert(ret == Z_STREAM_END);
+
+   /* clean up and return */
+   (void)deflateEnd();
+   return compressed_size;
+}
+
+/**
+ * Decompresses cache entry, returns true if successful.
+ */
+bool
+zlib_inflate(uint8_t *in_data, size_t in_data_size, uint8_t *out_data,
+ size_t out_data_size)
+{
+   z_stream strm;
+
+   /* allocate inflate state */
+   strm.zalloc = Z_NULL;
+   strm.zfree = Z_NULL;
+   

Re: [Mesa-dev] [PATCH 0/5] Volatile and invariant LDS memory ops

[Connor Abbott]

On Fri, Nov 10, 2017 at 1:19 PM, Marek Olšák  wrote:
> On Fri, Nov 10, 2017 at 6:55 PM, Nicolai Hähnle  wrote:
>> On 10.11.2017 18:43, Marek Olšák wrote:
>>>
>>> On Fri, Nov 10, 2017 at 2:09 AM, Connor Abbott 
>>> wrote:

 On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák  wrote:
>
> On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault 
> wrote:
>>
>>
>>> On Nov 10, 2017, at 07:41, Marek Olšák  wrote:
>>>
>>> Hi,
>>>
>>> This fixes the TCS gl_ClipDistance piglit failure that was uncovered
>>> by a recent LLVM change. The solution is to set volatile on loads
>>> and stores to enforce proper ordering.
>>>
>>> Please review.
>>>
>>
>>
>> Every LDS access certainly should not be volatile. This kills all
>> optimizations, like formation of ds_read2_b32. What ordering issue are 
>> you
>> having?
>
>
> It might be caused by inttoptr(NULL) that we do to declare LDS. There
> is simply no ordering enforced, which is weird.


 As soon as you do inttoptr(NULL), you've generated a poison value (in
 LLVM legalese), so LLVM will assume that you never dereference it and
 optimize accordingly. I think a GEP instruction without the inbounds
 parameter set will get rid of the poison value, although I'm not sure
 about the case where the offset is known to be zero. At least, that's
 my reading of the langref text for the GEP instruction
 (https://llvm.org/docs/LangRef.html#id215). If zero is a valid address
 in LDS, then it sounds like LLVM needs to be fixed to disable this
 optimization for certain address spaces. On the other hand, if you're
 doing inttoptr(NULL) + offset, where "offset" is the result of a
 ptrtoint somewhere, you should be doing inttoptr(offset) instead, and
 then LLVM should never misbehave.
>>>
>>>
>>> I don't think that using inttoptr before every load and store would be
>>> better than volatile. The must be a better solution.
>>
>>
>> Can't we just allocate the required LDS memory explicitly like we did for
>> the LDS-based derivative computations?
>>
>> It may require shuffling around a bit how/when we calculate the required
>> sizes, but it doesn't seem impossible.
>
> We want to share the same declaration in TCS main and epilog parts.
>
> Does LLVM know that LDS declarations are pre-initialized?
> Do sized LDS declarations affect SIMD-occupancy-based optimizations?
> Because Mesa always declares 64kB of LDS and the real value is
> determined at runtime.

I don't know about the latter, but for the former, if you declare the
LDS variable as having external linkage, LLVM should assume that it
might be initialized beforehand -- exactly like a global non-static
variable in C.

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

[Mesa-dev] [PATCH 1/4] configure.ac: Define HAVE_ZLIB if zlib is found

[Jordan Justen]

Cc: Emil Velikov 
Cc: Dylan Baker 
Signed-off-by: Jordan Justen 
---
 configure.ac | 6 +-
 meson.build  | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 411c4f6b3e0..213cfe132fb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -900,7 +900,11 @@ dnl See if posix_memalign is available
 AC_CHECK_FUNC([posix_memalign], [DEFINES="$DEFINES -DHAVE_POSIX_MEMALIGN"])
 
 dnl Check for zlib
-PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED])
+PKG_CHECK_MODULES([ZLIB], [zlib >= $ZLIB_REQUIRED],
+  [have_zlib=yes], [have_zlib=no])
+if test "x$have_zlib" = xyes; then
+DEFINES="$DEFINES -DHAVE_ZLIB"
+fi
 
 dnl Check for pthreads
 AX_PTHREAD
diff --git a/meson.build b/meson.build
index 855c80ed658..4c27b3ba048 100644
--- a/meson.build
+++ b/meson.build
@@ -661,8 +661,12 @@ if dep_libdrm.found()
   endif
 endif
 
+dep_zlib = dependency('zlib', version : '>= 1.2.3', required : false)
+if dep_zlib.found()
+  pre_args += '-DHAVE_ZLIB'
+endif
+
 # TODO: some of these may be conditional
-dep_zlib = dependency('zlib', version : '>= 1.2.3')
 dep_thread = dependency('threads')
 if dep_thread.found() and host_machine.system() == 'linux'
   pre_args += '-DHAVE_PTHREAD'
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] meson: don't us build_by_default for specific gallium drivers

[Lionel Landwerlin]

Fixes a build issue with gallium headers trying to include llvm ones 
(which I don't have installed).

Thanks!

Tested-by: Lionel Landwerlin 

On 10/11/17 17:23, Dylan Baker wrote:

Using build_by_default : false is convenient for dependencies that can
be pulled in by various diverse components of the build system, the
gallium hardware/software drivers and state trackers do not fit that
description. Instead, these should be guarded using the variable that tracks
whether that driver should be enabled.

This leaves a few helper libraries: trace, rbug, etc. as
build_by_default : false because there are a large number of gallium
components that pull them in. This fixes odd build errors since the
default drivers patch landed.

Fixes: 1873327c4b5a09 ("meson: implement default driver arguments")
Signed-off-by: Dylan Baker 
---
  src/gallium/drivers/freedreno/meson.build  |  1 -
  src/gallium/drivers/llvmpipe/meson.build   |  1 -
  src/gallium/drivers/nouveau/meson.build|  1 -
  src/gallium/drivers/radeon/meson.build |  1 -
  src/gallium/drivers/radeonsi/meson.build   |  1 -
  src/gallium/drivers/softpipe/meson.build   |  1 -
  src/gallium/drivers/vc5/meson.build|  1 -
  src/gallium/meson.build| 45 +-
  src/gallium/state_trackers/dri/meson.build |  1 -
  9 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/src/gallium/drivers/freedreno/meson.build 
b/src/gallium/drivers/freedreno/meson.build
index 3fb94ed8cff..6f74d9c35c0 100644
--- a/src/gallium/drivers/freedreno/meson.build
+++ b/src/gallium/drivers/freedreno/meson.build
@@ -205,7 +205,6 @@ libfreedreno = static_library(
c_args : [c_vis_args],
cpp_args : [cpp_vis_args],
dependencies : [dep_libdrm, dep_libdrm_freedreno],
-  build_by_default : false,
  )
  
  ir3_compiler = executable(

diff --git a/src/gallium/drivers/llvmpipe/meson.build 
b/src/gallium/drivers/llvmpipe/meson.build
index ca1d2aa797b..9d0edb0ac33 100644
--- a/src/gallium/drivers/llvmpipe/meson.build
+++ b/src/gallium/drivers/llvmpipe/meson.build
@@ -98,7 +98,6 @@ libllvmpipe = static_library(
cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
include_directories : [inc_gallium, inc_gallium_aux, inc_include, inc_src],
dependencies : dep_llvm,
-  build_by_default : false,
  )
  
  if with_tests and with_gallium_softpipe and with_llvm

diff --git a/src/gallium/drivers/nouveau/meson.build 
b/src/gallium/drivers/nouveau/meson.build
index 2bc6142879e..59fecfc5255 100644
--- a/src/gallium/drivers/nouveau/meson.build
+++ b/src/gallium/drivers/nouveau/meson.build
@@ -211,7 +211,6 @@ libnouveau = static_library(
c_args : [c_vis_args],
cpp_args : [cpp_vis_args],
dependencies : [dep_libdrm, dep_libdrm_nouveau],
-  build_by_default : false,
  )
  
  nouveau_compiler = executable(

diff --git a/src/gallium/drivers/radeon/meson.build 
b/src/gallium/drivers/radeon/meson.build
index b4d2832d016..f378b12e8e8 100644
--- a/src/gallium/drivers/radeon/meson.build
+++ b/src/gallium/drivers/radeon/meson.build
@@ -51,5 +51,4 @@ libradeon = static_library(
include_directories : [
  inc_include, inc_src, inc_gallium, inc_gallium_aux, inc_gallium_drivers,
],
-  build_by_default : false,
  )
diff --git a/src/gallium/drivers/radeonsi/meson.build 
b/src/gallium/drivers/radeonsi/meson.build
index 4392184dbb6..974004db67f 100644
--- a/src/gallium/drivers/radeonsi/meson.build
+++ b/src/gallium/drivers/radeonsi/meson.build
@@ -75,5 +75,4 @@ libradeonsi = static_library(
c_args : [c_vis_args],
cpp_args : [cpp_vis_args],
dependencies : dep_llvm,
-  build_by_default : false,
  )
diff --git a/src/gallium/drivers/softpipe/meson.build 
b/src/gallium/drivers/softpipe/meson.build
index 0cef15152e2..df23533c72c 100644
--- a/src/gallium/drivers/softpipe/meson.build
+++ b/src/gallium/drivers/softpipe/meson.build
@@ -81,5 +81,4 @@ libsoftpipe = static_library(
files_softpipe,
include_directories : [inc_gallium_aux, inc_gallium, inc_include, inc_src],
c_args : [c_vis_args, c_msvc_compat_args],
-  build_by_default : false,
  )
diff --git a/src/gallium/drivers/vc5/meson.build 
b/src/gallium/drivers/vc5/meson.build
index d066366fcc7..61059a15560 100644
--- a/src/gallium/drivers/vc5/meson.build
+++ b/src/gallium/drivers/vc5/meson.build
@@ -61,5 +61,4 @@ libvc5 = static_library(
c_args : [c_vis_args, v3dv3_c_args],
cpp_args : [cpp_vis_args],
dependencies : [dep_v3dv3, dep_libdrm, dep_valgrind],
-  build_by_default : false,
  )
diff --git a/src/gallium/meson.build b/src/gallium/meson.build
index 6edfe80321d..a4953617c86 100644
--- a/src/gallium/meson.build
+++ b/src/gallium/meson.build
@@ -27,39 +27,44 @@ subdir('drivers/ddebug')
  subdir('drivers/noop')
  subdir('drivers/trace')
  subdir('drivers/rbug')
-subdir('drivers/radeon')
-subdir('drivers/radeonsi')
-subdir('drivers/nouveau')
-subdir('drivers/freedreno')

[Mesa-dev] add util_queue_fence_wait_timeout checkin breaks centos6 build

[Kyriazis, George]

Hello Nicolai,

Your commit e3a8013 (util/u_queue: add util_queue_fence_wait_timeout), breaks 
the centos6 build.

Specifically, I am getting:

  CC libmesautil_la-u_queue.lo
../../../src/util/u_queue.c: In function '_util_queue_fence_wait_timeout':
../../../src/util/u_queue.c:173:7: error: implicit declaration of function 
'timespec_get' [-Werror=implicit-function-declaration]
   timespec_get(, TIME_UTC);
   ^
cc1: some warnings being treated as errors


Thanks!

George

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

Re: [Mesa-dev] [PATCH 0/5] Volatile and invariant LDS memory ops

[Marek Olšák]

On Fri, Nov 10, 2017 at 6:55 PM, Nicolai Hähnle  wrote:
> On 10.11.2017 18:43, Marek Olšák wrote:
>>
>> On Fri, Nov 10, 2017 at 2:09 AM, Connor Abbott 
>> wrote:
>>>
>>> On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák  wrote:

 On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault 
 wrote:
>
>
>> On Nov 10, 2017, at 07:41, Marek Olšák  wrote:
>>
>> Hi,
>>
>> This fixes the TCS gl_ClipDistance piglit failure that was uncovered
>> by a recent LLVM change. The solution is to set volatile on loads
>> and stores to enforce proper ordering.
>>
>> Please review.
>>
>
>
> Every LDS access certainly should not be volatile. This kills all
> optimizations, like formation of ds_read2_b32. What ordering issue are you
> having?


 It might be caused by inttoptr(NULL) that we do to declare LDS. There
 is simply no ordering enforced, which is weird.
>>>
>>>
>>> As soon as you do inttoptr(NULL), you've generated a poison value (in
>>> LLVM legalese), so LLVM will assume that you never dereference it and
>>> optimize accordingly. I think a GEP instruction without the inbounds
>>> parameter set will get rid of the poison value, although I'm not sure
>>> about the case where the offset is known to be zero. At least, that's
>>> my reading of the langref text for the GEP instruction
>>> (https://llvm.org/docs/LangRef.html#id215). If zero is a valid address
>>> in LDS, then it sounds like LLVM needs to be fixed to disable this
>>> optimization for certain address spaces. On the other hand, if you're
>>> doing inttoptr(NULL) + offset, where "offset" is the result of a
>>> ptrtoint somewhere, you should be doing inttoptr(offset) instead, and
>>> then LLVM should never misbehave.
>>
>>
>> I don't think that using inttoptr before every load and store would be
>> better than volatile. The must be a better solution.
>
>
> Can't we just allocate the required LDS memory explicitly like we did for
> the LDS-based derivative computations?
>
> It may require shuffling around a bit how/when we calculate the required
> sizes, but it doesn't seem impossible.

We want to share the same declaration in TCS main and epilog parts.

Does LLVM know that LDS declarations are pre-initialized?
Do sized LDS declarations affect SIMD-occupancy-based optimizations?
Because Mesa always declares 64kB of LDS and the real value is
determined at runtime.

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

Re: [Mesa-dev] [PATCH 01/17] docs/specs: Add GL_MESA_program_binary_formats extension spec

[Jordan Justen]

On 2017-11-10 08:43:37, Ian Romanick wrote:
> 
> The one thing I would add is an issues section with a single issue about 
> the decision to use a single enum for everything.

How does this sound?

diff --git a/docs/specs/MESA_program_binary_formats.txt 
b/docs/specs/MESA_program_binary_formats.txt
index 65bd1a1a739..65a2adab8b7 100644
--- a/docs/specs/MESA_program_binary_formats.txt
+++ b/docs/specs/MESA_program_binary_formats.txt
@@ -54,6 +54,26 @@ New State
 
 None.
 
+Issues
+
+(1) Should we have a different format for each driver?
+
+  RESOLVED. Since Mesa supports multiple hardware drivers, having
+  a single format may cause separate drivers to have to reject a
+  binary for another type of hardware on the same machine. This
+  could lead to an application having to invalidate and get a new
+  binary more often.
+
+  This extension, at least initially, does not to attempt to
+  define a new token for each driver since systems that run
+  multiple drivers are not the common case.
+
+  Additionally, drivers in Mesa are now gaining the ability to
+  transparently cache shader programs. Therefore, although they
+  may need to provide the application with a new binary more
+  often, they likely can retrieve the program from the cache
+  rather than performing an expensive recompile.
+
 Revision History
 
 #0110/28/2017Jordan Justen   First draft.



> 
> On November 9, 2017 12:42:58 AM Jordan Justen  
> wrote:
> 
> > Similar idea to Tim's "spec: MESA_program_binary", but simplified and
> > written to support both ARB_get_program_binary and
> > OES_get_program_binary.
> >
> > Signed-off-by: Jordan Justen 
> > Cc: Ian Romanick 
> > Cc: Timothy Arceri 
> > ---
> >  docs/specs/MESA_program_binary_formats.txt | 59 
> > ++
> >  docs/specs/enums.txt   |  3 ++
> >  src/mapi/glapi/registry/gl.xml |  2 +-
> >  3 files changed, 63 insertions(+), 1 deletion(-)
> >  create mode 100644 docs/specs/MESA_program_binary_formats.txt
> >
> > diff --git a/docs/specs/MESA_program_binary_formats.txt 
> > b/docs/specs/MESA_program_binary_formats.txt
> > new file mode 100644
> > index 000..65bd1a1a739
> > --- /dev/null
> > +++ b/docs/specs/MESA_program_binary_formats.txt
> > @@ -0,0 +1,59 @@
> > +Name
> > +
> > +MESA_program_binary_formats
> > +
> > +Name Strings
> > +
> > +GL_MESA_program_binary_formats
> > +
> > +Contact
> > +
> > +Jordan Justen (jordan.l.justen 'at' intel.com)
> > +
> > +Status
> > +
> > +Complete.
> > +
> > +Version
> > +
> > +Last Modified Date: October 28, 2017
> > +Revision: #1
> > +
> > +Number
> > +
> > +TBD
> > +
> > +Dependencies
> > +
> > +For use with the OpenGL ARB_get_program_binary extension, or the
> > +OpenGL ES OES_get_program_binary extension.
> > +
> > +Overview
> > +
> > +The get_program_binary exensions require a GLenum binaryFormat.
> > +This extension documents that format for use with Mesa.
> > +
> > +New Procedures and Functions
> > +
> > +None.
> > +
> > +New Tokens
> > +
> > +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> > +
> > +For ARB_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > +returned from GetProgramBinary calls in the 
> > +parameter and when retrieving the value of PROGRAM_BINARY_FORMATS.
> > +
> > +For OES_get_program_binary, GL_PROGRAM_BINARY_FORMAT_MESA may be
> > +returned from GetProgramBinaryOES calls in the 
> > +parameter and when retrieving the value of
> > +PROGRAM_BINARY_FORMATS_OES.
> > +
> > +New State
> > +
> > +None.
> > +
> > +Revision History
> > +
> > +#0110/28/2017Jordan Justen   First draft.
> > diff --git a/docs/specs/enums.txt b/docs/specs/enums.txt
> > index 4b0485f3490..8109cc50f97 100644
> > --- a/docs/specs/enums.txt
> > +++ b/docs/specs/enums.txt
> > @@ -63,6 +63,9 @@ GL_MESAX_texture_stack:
> >   GL_TEXTURE_1D_STACK_BINDING_MESAX0x875D
> >   GL_TEXTURE_2D_STACK_BINDING_MESAX0x875E
> >
> > +GL_MESA_program_binary_formats:
> > +GL_PROGRAM_BINARY_FORMAT_MESA   0x875F
> > +
> >  GL_MESA_program_debug
> >   GL_FRAGMENT_PROGRAM_POSITION_MESA   0x8BB0
> >   GL_FRAGMENT_PROGRAM_CALLBACK_MESA   0x8BB1
> > diff --git a/src/mapi/glapi/registry/gl.xml b/src/mapi/glapi/registry/gl.xml
> > index cbabe11b398..7360414bb35 100644
> > --- a/src/mapi/glapi/registry/gl.xml
> > +++ b/src/mapi/glapi/registry/gl.xml
> > @@ -5505,7 +5505,7 @@ typedef unsigned int GLhandleARB;
> >  
> >  
> >  
> > -
> > +
> >  
> >
> >  
> > --
> > 2.14.1
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/dri: fix deadlock when waiting on android fences

[Marek Olšák]

From: Marek Olšák 

Android fences can't be deferred, because st/dri calls fence_finish
with ctx = NULL, so the driver can't flush u_threaded_context.
---
 src/gallium/include/state_tracker/st_api.h   | 3 +--
 src/gallium/state_trackers/dri/dri_helpers.c | 3 +--
 src/mesa/state_tracker/st_manager.c  | 2 --
 3 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/gallium/include/state_tracker/st_api.h 
b/src/gallium/include/state_tracker/st_api.h
index 6cdaefc..a407b98 100644
--- a/src/gallium/include/state_tracker/st_api.h
+++ b/src/gallium/include/state_tracker/st_api.h
@@ -140,22 +140,21 @@ enum st_attachment_type {
 #define ST_ATTACHMENT_DEPTH_STENCIL_MASK  (1 << ST_ATTACHMENT_DEPTH_STENCIL)
 #define ST_ATTACHMENT_ACCUM_MASK  (1 << ST_ATTACHMENT_ACCUM)
 #define ST_ATTACHMENT_SAMPLE_MASK (1 << ST_ATTACHMENT_SAMPLE)
 
 /**
  * Flush flags.
  */
 #define ST_FLUSH_FRONT(1 << 0)
 #define ST_FLUSH_END_OF_FRAME (1 << 1)
 #define ST_FLUSH_WAIT (1 << 2)
-#define ST_FLUSH_DEFERRED (1 << 3)
-#define ST_FLUSH_FENCE_FD (1 << 4)
+#define ST_FLUSH_FENCE_FD (1 << 3)
 
 /**
  * Value to st_manager->get_param function.
  */
 enum st_manager_param {
/**
 * The dri state tracker on old libGL's doesn't do the right thing
 * with regards to invalidating the framebuffers.
 *
 * For the mesa state tracker that means that it needs to invalidate
diff --git a/src/gallium/state_trackers/dri/dri_helpers.c 
b/src/gallium/state_trackers/dri/dri_helpers.c
index 4a61455..37ab2c2 100644
--- a/src/gallium/state_trackers/dri/dri_helpers.c
+++ b/src/gallium/state_trackers/dri/dri_helpers.c
@@ -109,22 +109,21 @@ dri2_create_fence(__DRIcontext *_ctx)
 
 static void *
 dri2_create_fence_fd(__DRIcontext *_ctx, int fd)
 {
struct st_context_iface *stapi = dri_context(_ctx)->st;
struct pipe_context *ctx = stapi->pipe;
struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
 
if (fd == -1) {
   /* exporting driver created fence, flush: */
-  stapi->flush(stapi, ST_FLUSH_DEFERRED | ST_FLUSH_FENCE_FD,
-   >pipe_fence);
+  stapi->flush(stapi, ST_FLUSH_FENCE_FD, >pipe_fence);
} else {
   /* importing a foreign fence fd: */
   ctx->create_fence_fd(ctx, >pipe_fence, fd);
}
if (!fence->pipe_fence) {
   FREE(fence);
   return NULL;
}
 
fence->driscreen = dri_screen(_ctx->driScreenPriv);
diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index 43d5dfd..4a1998c 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -627,22 +627,20 @@ st_framebuffers_purge(struct st_context *st)
 
 static void
 st_context_flush(struct st_context_iface *stctxi, unsigned flags,
  struct pipe_fence_handle **fence)
 {
struct st_context *st = (struct st_context *) stctxi;
unsigned pipe_flags = 0;
 
if (flags & ST_FLUSH_END_OF_FRAME)
   pipe_flags |= PIPE_FLUSH_END_OF_FRAME;
-   if (flags & ST_FLUSH_DEFERRED)
-  pipe_flags |= PIPE_FLUSH_DEFERRED;
if (flags & ST_FLUSH_FENCE_FD)
   pipe_flags |= PIPE_FLUSH_FENCE_FD;
 
FLUSH_VERTICES(st->ctx, 0);
FLUSH_CURRENT(st->ctx, 0);
st_flush(st, fence, pipe_flags);
 
if ((flags & ST_FLUSH_WAIT) && fence && *fence) {
   st->pipe->screen->fence_finish(st->pipe->screen, NULL, *fence,
  PIPE_TIMEOUT_INFINITE);
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 0/9] Fix shader_draw_parameters CTS tests

[Neil Roberts]

Just to note, I made some Piglit patches to verify this new behaviour
too:

https://patchwork.freedesktop.org/series/33626/

This might make testing a little easier if someone wants to implement
the behaviour for other drivers too.

- Neil

Antia Puentes  writes:

> Hi,
>
> the series sets gl_BaseVertex to zero for gl*DrawArrays* in i965.
> Previously, its value was the value passed as  in the non-indexed
> draw call. This was convinient because the gl_VertexID was calculated as
> gl_VertexIDBaseZero + gl_BaseVertex.
>
> However, as gl_BaseVertex must be zero for non-indexed draw calls, this
> calculation is broken.
>
> Apart from setting the basevertex to zero in i965, the following patches add
> a new VS system value which will contain  or  as needed
> to make the gl_VertexID calculation right.
>
>
> The relevant bits of the OpenGL 4.6 specification involved here are:
>
> * 11.1.3.9 Shader Inputs
>
> "gl_BaseVertex holds the integer value passed to the baseVertex parameter to 
> the
> command that resulted in the current shader invocation. In the case where the
> command has no baseVertex parameter, the value of gl_BaseVertex is zero."
>
> "gl_VertexID holds the integer index i implicitly passed by DrawArrays or
> one of the other drawing commands defined in section 10.4."
>
> * 10.4. Drawing Commands Using Vertex Arrays:
>
>   - Page 352:
> "The index of any element transferred to the GL by DrawArraysOneInstance is
> referred to as its vertex ID, and may be read by a vertex shader as 
> gl_VertexID.
> The vertex ID of the ith element transferred is first + i."
>
>   - Page 355:
> "The index of any element transferred to the GL by DrawElementsOneInstance is
> referred to as its vertex ID, and may be read by a vertex shader as 
> gl_VertexID.
> The vertex ID of the ith element transferred is the sum of basevertex and the
> value stored in the currently bound element array buffer at offset indices + 
> i."
>
> Regards,
> Antia.
>
> Antia Puentes (5):
>   compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID
>   nir: Add SYSTEM_VALUE_BASE_VERTEX_ID instrinsics
>   i965: emit basevertexid as a vertex element component
>   i965: gl_BaseVertex must be zero for non-indexed draw calls
>   intel/compiler: implement the basevertex(id) load intrinsics
>
> Neil Roberts (4):
>   intel/compiler: Add a uses_basevertexid flag
>   nir: Offset vertex_id by base_vertex_id instead of base_vertex
>   i965: Let nir lower gl_VertexID instead of the linker
>   spirv: Lower BaseVertex to BASE_VERTEX_ID instead of BASE_VERTEX
>
>  src/compiler/nir/nir.c|  4 +++
>  src/compiler/nir/nir_gather_info.c|  1 +
>  src/compiler/nir/nir_intrinsics.h |  1 +
>  src/compiler/nir/nir_lower_system_values.c|  2 +-
>  src/compiler/shader_enums.c   |  1 +
>  src/compiler/shader_enums.h   | 15 +++
>  src/compiler/spirv/vtn_variables.c|  2 +-
>  src/intel/compiler/brw_compiler.h |  1 +
>  src/intel/compiler/brw_nir.c  | 12 ++---
>  src/intel/compiler/brw_vec4.cpp   | 18 -
>  src/intel/vulkan/genX_cmd_buffer.c|  8 +++---
>  src/intel/vulkan/genX_pipeline.c  |  4 +--
>  src/mesa/drivers/dri/i965/brw_context.c   |  3 ++-
>  src/mesa/drivers/dri/i965/brw_context.h   | 36 ++---
>  src/mesa/drivers/dri/i965/brw_draw.c  | 33 ---
>  src/mesa/drivers/dri/i965/brw_draw_upload.c   | 13 -
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 39 
> +++
>  17 files changed, 132 insertions(+), 61 deletions(-)
>
> -- 
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [PATCH] gallium/xlib: remove GL_{MAJOR,MINOR,TINY}

[Emil Velikov]

On 10 November 2017 at 17:53, Dylan Baker  wrote:
> These variables were removed from autotools in 2008 (sha:
> 80f68e1b6a0e5bd2da799c), but they have lived on here. The Scons build
> meanwhile doesn't set a patch/tiny version at all, just major and minor.
> This patch removes the unused variables and simply sets the version,
> leaving patch/tiny as 0 since that's what the autotools build as been
> doing forever. This shouldn't change any behavior.
>
Patch is
Reviewed-by: Emil Velikov 

I believe I poked Brian/Jose for clarification on the differing
version numbers, but cannot find it atm.
Brian can you some light on the topic? The Linux OpenGL ABI states
"libGL.so.1" and does not mention anything more on the topic.

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

Re: [Mesa-dev] [PATCH] meson: don't us build_by_default for specific gallium drivers

[Dylan Baker]

If fixed the typo in the subject locally.

Quoting Dylan Baker (2017-11-10 09:23:37)
> Using build_by_default : false is convenient for dependencies that can
> be pulled in by various diverse components of the build system, the
> gallium hardware/software drivers and state trackers do not fit that
> description. Instead, these should be guarded using the variable that tracks
> whether that driver should be enabled.
> 
> This leaves a few helper libraries: trace, rbug, etc. as
> build_by_default : false because there are a large number of gallium
> components that pull them in. This fixes odd build errors since the
> default drivers patch landed.
> 
> Fixes: 1873327c4b5a09 ("meson: implement default driver arguments")
> Signed-off-by: Dylan Baker 
> ---
>  src/gallium/drivers/freedreno/meson.build  |  1 -
>  src/gallium/drivers/llvmpipe/meson.build   |  1 -
>  src/gallium/drivers/nouveau/meson.build|  1 -
>  src/gallium/drivers/radeon/meson.build |  1 -
>  src/gallium/drivers/radeonsi/meson.build   |  1 -
>  src/gallium/drivers/softpipe/meson.build   |  1 -
>  src/gallium/drivers/vc5/meson.build|  1 -
>  src/gallium/meson.build| 45 
> +-
>  src/gallium/state_trackers/dri/meson.build |  1 -
>  9 files changed, 25 insertions(+), 28 deletions(-)
> 
> diff --git a/src/gallium/drivers/freedreno/meson.build 
> b/src/gallium/drivers/freedreno/meson.build
> index 3fb94ed8cff..6f74d9c35c0 100644
> --- a/src/gallium/drivers/freedreno/meson.build
> +++ b/src/gallium/drivers/freedreno/meson.build
> @@ -205,7 +205,6 @@ libfreedreno = static_library(
>c_args : [c_vis_args],
>cpp_args : [cpp_vis_args],
>dependencies : [dep_libdrm, dep_libdrm_freedreno],
> -  build_by_default : false,
>  )
>  
>  ir3_compiler = executable(
> diff --git a/src/gallium/drivers/llvmpipe/meson.build 
> b/src/gallium/drivers/llvmpipe/meson.build
> index ca1d2aa797b..9d0edb0ac33 100644
> --- a/src/gallium/drivers/llvmpipe/meson.build
> +++ b/src/gallium/drivers/llvmpipe/meson.build
> @@ -98,7 +98,6 @@ libllvmpipe = static_library(
>cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
>include_directories : [inc_gallium, inc_gallium_aux, inc_include, inc_src],
>dependencies : dep_llvm,
> -  build_by_default : false,
>  )
>  
>  if with_tests and with_gallium_softpipe and with_llvm
> diff --git a/src/gallium/drivers/nouveau/meson.build 
> b/src/gallium/drivers/nouveau/meson.build
> index 2bc6142879e..59fecfc5255 100644
> --- a/src/gallium/drivers/nouveau/meson.build
> +++ b/src/gallium/drivers/nouveau/meson.build
> @@ -211,7 +211,6 @@ libnouveau = static_library(
>c_args : [c_vis_args],
>cpp_args : [cpp_vis_args],
>dependencies : [dep_libdrm, dep_libdrm_nouveau],
> -  build_by_default : false,
>  )
>  
>  nouveau_compiler = executable(
> diff --git a/src/gallium/drivers/radeon/meson.build 
> b/src/gallium/drivers/radeon/meson.build
> index b4d2832d016..f378b12e8e8 100644
> --- a/src/gallium/drivers/radeon/meson.build
> +++ b/src/gallium/drivers/radeon/meson.build
> @@ -51,5 +51,4 @@ libradeon = static_library(
>include_directories : [
>  inc_include, inc_src, inc_gallium, inc_gallium_aux, inc_gallium_drivers,
>],
> -  build_by_default : false,
>  )
> diff --git a/src/gallium/drivers/radeonsi/meson.build 
> b/src/gallium/drivers/radeonsi/meson.build
> index 4392184dbb6..974004db67f 100644
> --- a/src/gallium/drivers/radeonsi/meson.build
> +++ b/src/gallium/drivers/radeonsi/meson.build
> @@ -75,5 +75,4 @@ libradeonsi = static_library(
>c_args : [c_vis_args],
>cpp_args : [cpp_vis_args],
>dependencies : dep_llvm,
> -  build_by_default : false,
>  )
> diff --git a/src/gallium/drivers/softpipe/meson.build 
> b/src/gallium/drivers/softpipe/meson.build
> index 0cef15152e2..df23533c72c 100644
> --- a/src/gallium/drivers/softpipe/meson.build
> +++ b/src/gallium/drivers/softpipe/meson.build
> @@ -81,5 +81,4 @@ libsoftpipe = static_library(
>files_softpipe,
>include_directories : [inc_gallium_aux, inc_gallium, inc_include, inc_src],
>c_args : [c_vis_args, c_msvc_compat_args],
> -  build_by_default : false,
>  )
> diff --git a/src/gallium/drivers/vc5/meson.build 
> b/src/gallium/drivers/vc5/meson.build
> index d066366fcc7..61059a15560 100644
> --- a/src/gallium/drivers/vc5/meson.build
> +++ b/src/gallium/drivers/vc5/meson.build
> @@ -61,5 +61,4 @@ libvc5 = static_library(
>c_args : [c_vis_args, v3dv3_c_args],
>cpp_args : [cpp_vis_args],
>dependencies : [dep_v3dv3, dep_libdrm, dep_valgrind],
> -  build_by_default : false,
>  )
> diff --git a/src/gallium/meson.build b/src/gallium/meson.build
> index 6edfe80321d..a4953617c86 100644
> --- a/src/gallium/meson.build
> +++ b/src/gallium/meson.build
> @@ -27,39 +27,44 @@ subdir('drivers/ddebug')
>  subdir('drivers/noop')
>  subdir('drivers/trace')
>  subdir('drivers/rbug')
> -subdir('drivers/radeon')
> -subdir('drivers/radeonsi')
> 

Re: [Mesa-dev] [PATCH] gallium/xlib: remove GL_{MAJOR,MINOR,TINY}

[Brian Paul]

On 11/10/2017 10:53 AM, Dylan Baker wrote:

These variables were removed from autotools in 2008 (sha:
80f68e1b6a0e5bd2da799c), but they have lived on here. The Scons build
meanwhile doesn't set a patch/tiny version at all, just major and minor.
This patch removes the unused variables and simply sets the version,
leaving patch/tiny as 0 since that's what the autotools build as been
doing forever. This shouldn't change any behavior.

cc: Brian Paul 
cc: Emil Velikov 
Signed-off-by: Dylan Baker 
---
  src/gallium/targets/libgl-xlib/Makefile.am | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/targets/libgl-xlib/Makefile.am 
b/src/gallium/targets/libgl-xlib/Makefile.am
index a29199fe784..263b0846a42 100644
--- a/src/gallium/targets/libgl-xlib/Makefile.am
+++ b/src/gallium/targets/libgl-xlib/Makefile.am
@@ -20,10 +20,6 @@
  # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  # DEALINGS IN THE SOFTWARE.

-GL_MAJOR = 1
-GL_MINOR = 5
-GL_TINY = $(MESA_MAJOR)$(MESA_MINOR)0$(MESA_TINY)
-
  if HAVE_SHARED_GLAPI
  SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la
  endif
@@ -51,7 +47,7 @@ nodist_EXTRA_lib@GL_LIB@_la_SOURCES = dummy.cpp
  lib@GL_LIB@_la_SOURCES = xlib.c
  lib@GL_LIB@_la_LDFLAGS = \
-no-undefined \
-   -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \
+   -version-number 1:5:0 \
$(BSYMBOLIC) \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)



Reviewed-by: Brian Paul 

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

Re: [Mesa-dev] [PATCH 0/5] Volatile and invariant LDS memory ops

[Nicolai Hähnle]

On 10.11.2017 18:43, Marek Olšák wrote:

On Fri, Nov 10, 2017 at 2:09 AM, Connor Abbott  wrote:

On Thu, Nov 9, 2017 at 7:17 PM, Marek Olšák  wrote:

On Fri, Nov 10, 2017 at 12:40 AM, Matt Arsenault  wrote:



On Nov 10, 2017, at 07:41, Marek Olšák  wrote:

Hi,

This fixes the TCS gl_ClipDistance piglit failure that was uncovered
by a recent LLVM change. The solution is to set volatile on loads
and stores to enforce proper ordering.

Please review.




Every LDS access certainly should not be volatile. This kills all 
optimizations, like formation of ds_read2_b32. What ordering issue are you 
having?


It might be caused by inttoptr(NULL) that we do to declare LDS. There
is simply no ordering enforced, which is weird.


As soon as you do inttoptr(NULL), you've generated a poison value (in
LLVM legalese), so LLVM will assume that you never dereference it and
optimize accordingly. I think a GEP instruction without the inbounds
parameter set will get rid of the poison value, although I'm not sure
about the case where the offset is known to be zero. At least, that's
my reading of the langref text for the GEP instruction
(https://llvm.org/docs/LangRef.html#id215). If zero is a valid address
in LDS, then it sounds like LLVM needs to be fixed to disable this
optimization for certain address spaces. On the other hand, if you're
doing inttoptr(NULL) + offset, where "offset" is the result of a
ptrtoint somewhere, you should be doing inttoptr(offset) instead, and
then LLVM should never misbehave.


I don't think that using inttoptr before every load and store would be
better than volatile. The must be a better solution.


Can't we just allocate the required LDS memory explicitly like we did 
for the LDS-based derivative computations?


It may require shuffling around a bit how/when we calculate the required 
sizes, but it doesn't seem impossible.


Cheers,
Nicolai




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




--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium/xlib: remove GL_{MAJOR,MINOR,TINY}

[Dylan Baker]

These variables were removed from autotools in 2008 (sha:
80f68e1b6a0e5bd2da799c), but they have lived on here. The Scons build
meanwhile doesn't set a patch/tiny version at all, just major and minor.
This patch removes the unused variables and simply sets the version,
leaving patch/tiny as 0 since that's what the autotools build as been
doing forever. This shouldn't change any behavior.

cc: Brian Paul 
cc: Emil Velikov 
Signed-off-by: Dylan Baker 
---
 src/gallium/targets/libgl-xlib/Makefile.am | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/gallium/targets/libgl-xlib/Makefile.am 
b/src/gallium/targets/libgl-xlib/Makefile.am
index a29199fe784..263b0846a42 100644
--- a/src/gallium/targets/libgl-xlib/Makefile.am
+++ b/src/gallium/targets/libgl-xlib/Makefile.am
@@ -20,10 +20,6 @@
 # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 # DEALINGS IN THE SOFTWARE.
 
-GL_MAJOR = 1
-GL_MINOR = 5
-GL_TINY = $(MESA_MAJOR)$(MESA_MINOR)0$(MESA_TINY)
-
 if HAVE_SHARED_GLAPI
 SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la
 endif
@@ -51,7 +47,7 @@ nodist_EXTRA_lib@GL_LIB@_la_SOURCES = dummy.cpp
 lib@GL_LIB@_la_SOURCES = xlib.c
 lib@GL_LIB@_la_LDFLAGS = \
-no-undefined \
-   -version-number $(GL_MAJOR):$(GL_MINOR):$(GL_TINY) \
+   -version-number 1:5:0 \
$(BSYMBOLIC) \
$(GC_SECTIONS) \
$(LD_NO_UNDEFINED)
-- 
2.15.0

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

[Mesa-dev] [PATCH 9/9] spirv: Lower BaseVertex to BASE_VERTEX_ID instead of BASE_VERTEX

[Antia Puentes]

From: Neil Roberts 

The base vertex in Vulkan is different from GL in that for non-indexed
primitives the value is taken from the firstVertex parameter instead
of being set to zero. This coincides with the new
SYSTEM_VALUE_BASE_VERTEX_ID instead of BASE_VERTEX.
---
 src/compiler/spirv/vtn_variables.c | 2 +-
 src/intel/vulkan/genX_cmd_buffer.c | 8 
 src/intel/vulkan/genX_pipeline.c   | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 1cf9d597cf0..82d04f2558b 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1155,7 +1155,7 @@ vtn_get_builtin_location(struct vtn_builder *b,
   set_mode_system_value(mode);
   break;
case SpvBuiltInBaseVertex:
-  *location = SYSTEM_VALUE_BASE_VERTEX;
+  *location = SYSTEM_VALUE_BASE_VERTEX_ID;
   set_mode_system_value(mode);
   break;
case SpvBuiltInBaseInstance:
diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
b/src/intel/vulkan/genX_cmd_buffer.c
index fbb5706606a..4e9b884d3ac 100644
--- a/src/intel/vulkan/genX_cmd_buffer.c
+++ b/src/intel/vulkan/genX_cmd_buffer.c
@@ -2175,7 +2175,7 @@ void genX(CmdDraw)(
 
genX(cmd_buffer_flush_state)(cmd_buffer);
 
-   if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+   if (vs_prog_data->uses_basevertexid || vs_prog_data->uses_baseinstance)
   emit_base_vertex_instance(cmd_buffer, firstVertex, firstInstance);
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
@@ -2213,7 +2213,7 @@ void genX(CmdDrawIndexed)(
 
genX(cmd_buffer_flush_state)(cmd_buffer);
 
-   if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+   if (vs_prog_data->uses_basevertexid || vs_prog_data->uses_baseinstance)
   emit_base_vertex_instance(cmd_buffer, vertexOffset, firstInstance);
if (vs_prog_data->uses_drawid)
   emit_draw_index(cmd_buffer, 0);
@@ -2369,7 +2369,7 @@ void genX(CmdDrawIndirect)(
   struct anv_bo *bo = buffer->bo;
   uint32_t bo_offset = buffer->offset + offset;
 
-  if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+  if (vs_prog_data->uses_basevertexid || vs_prog_data->uses_baseinstance)
  emit_base_vertex_instance_bo(cmd_buffer, bo, bo_offset + 8);
   if (vs_prog_data->uses_drawid)
  emit_draw_index(cmd_buffer, i);
@@ -2408,7 +2408,7 @@ void genX(CmdDrawIndexedIndirect)(
   uint32_t bo_offset = buffer->offset + offset;
 
   /* TODO: We need to stomp base vertex to 0 somehow */
-  if (vs_prog_data->uses_basevertex || vs_prog_data->uses_baseinstance)
+  if (vs_prog_data->uses_basevertexid || vs_prog_data->uses_baseinstance)
  emit_base_vertex_instance_bo(cmd_buffer, bo, bo_offset + 12);
   if (vs_prog_data->uses_drawid)
  emit_draw_index(cmd_buffer, i);
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 7e3a785c584..01e48ce4559 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -97,7 +97,7 @@ emit_vertex_input(struct anv_pipeline *pipeline,
const uint32_t elements_double = double_inputs_read >> VERT_ATTRIB_GENERIC0;
const bool needs_svgs_elem = vs_prog_data->uses_vertexid ||
 vs_prog_data->uses_instanceid ||
-vs_prog_data->uses_basevertex ||
+vs_prog_data->uses_basevertexid ||
 vs_prog_data->uses_baseinstance;
 
uint32_t elem_count = __builtin_popcount(elements) -
@@ -177,7 +177,7 @@ emit_vertex_input(struct anv_pipeline *pipeline,
* This means, that if we have BaseInstance, we need BaseVertex as
* well.  Just do all or nothing.
*/
-  uint32_t base_ctrl = (vs_prog_data->uses_basevertex ||
+  uint32_t base_ctrl = (vs_prog_data->uses_basevertexid ||
 vs_prog_data->uses_baseinstance) ?
VFCOMP_STORE_SRC : VFCOMP_STORE_0;
 
-- 
2.14.1

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

[Mesa-dev] [PATCH 8/9] i965: Let nir lower gl_VertexID instead of the linker

[Antia Puentes]

From: Neil Roberts 

---
 src/mesa/drivers/dri/i965/brw_context.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index 19d5a2e3503..01c8e8cb3cf 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -586,7 +586,8 @@ brw_initialize_context_constants(struct brw_context *brw)
   ctx->Const.QuadsFollowProvokingVertexConvention = false;
 
ctx->Const.NativeIntegers = true;
-   ctx->Const.VertexID_is_zero_based = true;
+   /* This is lowered by NIR instead */
+   ctx->Const.VertexID_is_zero_based = false;
 
/* Regarding the CMP instruction, the Ivybridge PRM says:
 *
-- 
2.14.1

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

[Mesa-dev] [PATCH 5/9] i965: gl_BaseVertex must be zero for non-indexed draw calls

[Antia Puentes]

- From the OpenGL 4.6 (11.1.3.9 Shader Inputs) specification:

"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."

- Fixes CTS tests:

* KHR-GL45.shader_draw_parameters_tests.ShaderDrawArraysParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderDrawArraysInstancedParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderMultiDrawArraysParameters
* KHR-GL45.shader_draw_parameters_tests.ShaderMultiDrawArraysIndirectParameters
* KHR-GL45.shader_draw_parameters_tests.MultiDrawArraysIndirectCountParameters

Reviewed-by: Neil Roberts 
---
 src/mesa/drivers/dri/i965/brw_draw.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8c26273035b..54d35c0522c 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -239,6 +239,13 @@ brw_emit_prim(struct brw_context *brw,
prim->indirect_offset + 12);
  brw_load_register_mem(brw, GEN7_3DPRIM_START_INSTANCE, bo,
prim->indirect_offset + 16);
+
+ if (brw->draw.derived_draw_params_bo != NULL) {
+brw_store_register_mem32(brw, brw->draw.derived_draw_params_bo,
+ GEN7_3DPRIM_BASE_VERTEX,
+ brw->draw.derived_draw_params_offset + 4);
+brw_emit_mi_flush(brw);
+ }
   } else {
  brw_load_register_mem(brw, GEN7_3DPRIM_START_INSTANCE, bo,
prim->indirect_offset + 12);
@@ -809,7 +816,7 @@ brw_draw_single_prim(struct gl_context *ctx,
 * valid vs_prog_data, but we always flag BRW_NEW_VERTICES before
 * the loop.
 */
-   const int new_basevertex = prim->indexed ? prim->basevertex : prim->start;
+   const int new_basevertex = prim->indexed ? prim->basevertex : 0;
 
if (prim_id > 0 &&
(vs_prog_data->uses_drawid ||
-- 
2.14.1

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

[Mesa-dev] [PATCH 4/9] i965: emit basevertexid as a vertex element component

[Antia Puentes]

The new basevertexid will be emitted in the position previously occupied by
gl_BaseVertex. This way we can keep pointing the indirect buffer for indirect
draw calls. The gl_BaseVertex is now emited as part of the draw_id
VERTEX_ELEMENT.

Reviewed-by: Neil Roberts 
---
 src/mesa/drivers/dri/i965/brw_context.h   | 36 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  | 26 +++---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 13 -
 src/mesa/drivers/dri/i965/genX_state_upload.c | 39 +++
 4 files changed, 72 insertions(+), 42 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 8aa0c5ff64c..8ad3cdd7ebd 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -807,28 +807,44 @@ struct brw_context
 
struct {
   struct {
- /** The value of gl_BaseVertex for the current _mesa_prim. */
- int gl_basevertex;
+ /**
+  * Either the value of gl_BaseVertex for indexed draw calls or the
+  * value of the argument  for non-indexed draw calls, for the
+  * current _mesa_prim.
+  */
+ int basevertexid;
 
  /** The value of gl_BaseInstance for the current _mesa_prim. */
  int gl_baseinstance;
   } params;
 
   /**
-   * Buffer and offset used for GL_ARB_shader_draw_parameters
-   * (for now, only gl_BaseVertex).
+   * Buffer and offset used for GL_ARB_shader_draw_parameters. For indirect
+   * draw calls it will point to the indirect buffer.
*/
   struct brw_bo *draw_params_bo;
   uint32_t draw_params_offset;
 
+  struct {
+ /** The value of gl_DrawID for the current _mesa_prim. */
+ int gl_drawid;
+
+ /**
+  * The value of gl_BaseVertex for the current _mesa_prim. It must be
+  * zero for non-indexed calls.
+  */
+ int gl_basevertex;
+  } derived_params;
+
   /**
-   * The value of gl_DrawID for the current _mesa_prim. This always comes
-   * in from it's own vertex buffer since it's not part of the indirect
-   * draw parameters.
+   * Buffer and offset also used for GL_ARB_shader_draw_parameters. As they
+   * are not part of the indirect buffer they will go in their own vertex
+   * element. Note that although gl_BaseVertex is part of the indirect
+   * buffer for indexed draw calls, that is not longer the case for
+   * non-indexed.
*/
-  int gl_drawid;
-  struct brw_bo *draw_id_bo;
-  uint32_t draw_id_offset;
+  struct brw_bo *derived_draw_params_bo;
+  uint32_t derived_draw_params_offset;
 
   /**
* Pointer to the the buffer storing the indirect draw parameters. It
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 809e7221b2d..8c26273035b 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -766,25 +766,25 @@ brw_draw_single_prim(struct gl_context *ctx,
 * always flag if the shader uses one of the values. For direct draws,
 * we only flag if the values change.
 */
-   const int new_basevertex =
+   const int new_basevertexid =
   prim->indexed ? prim->basevertex : prim->start;
const int new_baseinstance = prim->base_instance;
const struct brw_vs_prog_data *vs_prog_data =
   brw_vs_prog_data(brw->vs.base.prog_data);
if (prim_id > 0) {
   const bool uses_draw_parameters =
- vs_prog_data->uses_basevertex ||
+ vs_prog_data->uses_basevertexid ||
  vs_prog_data->uses_baseinstance;
 
   if ((uses_draw_parameters && prim->is_indirect) ||
-  (vs_prog_data->uses_basevertex &&
-   brw->draw.params.gl_basevertex != new_basevertex) ||
+  (vs_prog_data->uses_basevertexid &&
+   brw->draw.params.basevertexid != new_basevertexid) ||
   (vs_prog_data->uses_baseinstance &&
brw->draw.params.gl_baseinstance != new_baseinstance))
  brw->ctx.NewDriverState |= BRW_NEW_VERTICES;
}
 
-   brw->draw.params.gl_basevertex = new_basevertex;
+   brw->draw.params.basevertexid = new_basevertexid;
brw->draw.params.gl_baseinstance = new_baseinstance;
brw_bo_unreference(brw->draw.draw_params_bo);
 
@@ -809,12 +809,20 @@ brw_draw_single_prim(struct gl_context *ctx,
 * valid vs_prog_data, but we always flag BRW_NEW_VERTICES before
 * the loop.
 */
-   brw->draw.gl_drawid = prim->draw_id;
-   brw_bo_unreference(brw->draw.draw_id_bo);
-   brw->draw.draw_id_bo = NULL;
-   if (prim_id > 0 && vs_prog_data->uses_drawid)
+   const int new_basevertex = prim->indexed ? prim->basevertex : prim->start;
+
+   if (prim_id > 0 &&
+   (vs_prog_data->uses_drawid ||
+(vs_prog_data->uses_basevertex &&
+ brw->draw.derived_params.gl_basevertex != new_basevertex)))

[Mesa-dev] [PATCH 3/9] intel/compiler: Add a uses_basevertexid flag

[Antia Puentes]

From: Neil Roberts 

---
 src/intel/compiler/brw_compiler.h | 1 +
 src/intel/compiler/brw_vec4.cpp   | 4 
 2 files changed, 5 insertions(+)

diff --git a/src/intel/compiler/brw_compiler.h 
b/src/intel/compiler/brw_compiler.h
index df6ee018546..6b5b73a54f0 100644
--- a/src/intel/compiler/brw_compiler.h
+++ b/src/intel/compiler/brw_compiler.h
@@ -969,6 +969,7 @@ struct brw_vs_prog_data {
bool uses_vertexid;
bool uses_instanceid;
bool uses_basevertex;
+   bool uses_basevertexid;
bool uses_baseinstance;
bool uses_drawid;
 };
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index bbe4585e0c7..d996ab8c89f 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2795,6 +2795,10 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX))
   prog_data->uses_basevertex = true;
 
+   if (shader->info.system_values_read &
+   BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX_ID))
+  prog_data->uses_basevertexid = true;
+
if (shader->info.system_values_read &
BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE))
   prog_data->uses_baseinstance = true;
-- 
2.14.1

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

[Mesa-dev] [PATCH 7/9] nir: Offset vertex_id by base_vertex_id instead of base_vertex

[Antia Puentes]

From: Neil Roberts 

base_vertex will be zero for non-indexed calls, but we need it to
include the ‘first’ parameter. This is true for both GL and Vulkan.

I think this patch will also affect freedreno and radeonsi. I believe
if they are relying on this lowering then they are currently already
broken because they will have the wrong values for gl_BaseVertex.
However this patch will also make them break for gl_VertexID and they
will need to be fixed to use base_vertex_id instead.
---
 src/compiler/nir/nir_lower_system_values.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 3594f4ae5ce..5464a1b3980 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -105,7 +105,7 @@ convert_block(nir_block *block, nir_builder *b)
  if (b->shader->options->vertex_id_zero_based) {
 sysval = nir_iadd(b,
   nir_load_vertex_id_zero_base(b),
-  nir_load_base_vertex(b));
+  nir_load_base_vertex_id(b));
  } else {
 sysval = nir_load_vertex_id(b);
  }
-- 
2.14.1

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

[Mesa-dev] [PATCH 1/9] compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID

[Antia Puentes]

This VS system value will contain the value passed as 
for indexed draw calls or the value passed as  for non-indexed
draw calls. It will be used to calculate the gl_VertexID as
SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus SYSTEM_VALUE_BASE_VERTEX_ID.
Note that the current calculation which uses SYSTEM_VALUE_BASE_VERTEX
is not right, as gl_BaseVertex should be zero for non-indexed calls.

Reviewed-by: Neil Roberts 
---
 src/compiler/shader_enums.c |  1 +
 src/compiler/shader_enums.h | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index b2ca80b49c2..cd8c256f227 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -215,6 +215,7 @@ gl_system_value_name(gl_system_value sysval)
  ENUM(SYSTEM_VALUE_INSTANCE_ID),
  ENUM(SYSTEM_VALUE_INSTANCE_INDEX),
  ENUM(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE),
+ ENUM(SYSTEM_VALUE_BASE_VERTEX_ID),
  ENUM(SYSTEM_VALUE_BASE_VERTEX),
  ENUM(SYSTEM_VALUE_BASE_INSTANCE),
  ENUM(SYSTEM_VALUE_DRAW_ID),
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index 9d229d4199e..7437cccdd0a 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -474,6 +474,21 @@ typedef enum
 */
SYSTEM_VALUE_BASE_VERTEX,
 
+
+   /**
+* Depending on the type of the draw call (indexed or non-indexed),
+* is the value of \c basevertex passed to \c glDrawElementsBaseVertex and
+* similar, or is the value of \c first passed to \c glDrawArrays and
+* similar.
+*
+* \note
+* It can be used to calculate the \c SYSTEM_VALUE_VERTEX_ID as
+* \c SYSTEM_VALUE_VERTEX_ID_ZERO_BASE plus \c SYSTEM_VALUE_BASE_VERTEX_ID.
+*
+* \sa SYSTEM_VALUE_VERTEX_ID_ZERO_BASE, SYSTEM_VALUE_VERTEX_ID
+*/
+   SYSTEM_VALUE_BASE_VERTEX_ID,
+
/**
 * Value of \c baseinstance passed to instanced draw entry points
 *
-- 
2.14.1

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

[Mesa-dev] [PATCH 0/9] Fix shader_draw_parameters CTS tests

[Antia Puentes]

Hi,

the series sets gl_BaseVertex to zero for gl*DrawArrays* in i965.
Previously, its value was the value passed as  in the non-indexed
draw call. This was convinient because the gl_VertexID was calculated as
gl_VertexIDBaseZero + gl_BaseVertex.

However, as gl_BaseVertex must be zero for non-indexed draw calls, this
calculation is broken.

Apart from setting the basevertex to zero in i965, the following patches add
a new VS system value which will contain  or  as needed
to make the gl_VertexID calculation right.


The relevant bits of the OpenGL 4.6 specification involved here are:

* 11.1.3.9 Shader Inputs

"gl_BaseVertex holds the integer value passed to the baseVertex parameter to the
command that resulted in the current shader invocation. In the case where the
command has no baseVertex parameter, the value of gl_BaseVertex is zero."

"gl_VertexID holds the integer index i implicitly passed by DrawArrays or
one of the other drawing commands defined in section 10.4."

* 10.4. Drawing Commands Using Vertex Arrays:

  - Page 352:
"The index of any element transferred to the GL by DrawArraysOneInstance is
referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID.
The vertex ID of the ith element transferred is first + i."

  - Page 355:
"The index of any element transferred to the GL by DrawElementsOneInstance is
referred to as its vertex ID, and may be read by a vertex shader as gl_VertexID.
The vertex ID of the ith element transferred is the sum of basevertex and the
value stored in the currently bound element array buffer at offset indices + i."

Regards,
Antia.

Antia Puentes (5):
  compiler: Add new system value SYSTEM_VALUE_BASE_VERTEX_ID
  nir: Add SYSTEM_VALUE_BASE_VERTEX_ID instrinsics
  i965: emit basevertexid as a vertex element component
  i965: gl_BaseVertex must be zero for non-indexed draw calls
  intel/compiler: implement the basevertex(id) load intrinsics

Neil Roberts (4):
  intel/compiler: Add a uses_basevertexid flag
  nir: Offset vertex_id by base_vertex_id instead of base_vertex
  i965: Let nir lower gl_VertexID instead of the linker
  spirv: Lower BaseVertex to BASE_VERTEX_ID instead of BASE_VERTEX

 src/compiler/nir/nir.c|  4 +++
 src/compiler/nir/nir_gather_info.c|  1 +
 src/compiler/nir/nir_intrinsics.h |  1 +
 src/compiler/nir/nir_lower_system_values.c|  2 +-
 src/compiler/shader_enums.c   |  1 +
 src/compiler/shader_enums.h   | 15 +++
 src/compiler/spirv/vtn_variables.c|  2 +-
 src/intel/compiler/brw_compiler.h |  1 +
 src/intel/compiler/brw_nir.c  | 12 ++---
 src/intel/compiler/brw_vec4.cpp   | 18 -
 src/intel/vulkan/genX_cmd_buffer.c|  8 +++---
 src/intel/vulkan/genX_pipeline.c  |  4 +--
 src/mesa/drivers/dri/i965/brw_context.c   |  3 ++-
 src/mesa/drivers/dri/i965/brw_context.h   | 36 ++---
 src/mesa/drivers/dri/i965/brw_draw.c  | 33 ---
 src/mesa/drivers/dri/i965/brw_draw_upload.c   | 13 -
 src/mesa/drivers/dri/i965/genX_state_upload.c | 39 +++
 17 files changed, 132 insertions(+), 61 deletions(-)

-- 
2.14.1

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

[Mesa-dev] [PATCH 6/9] intel/compiler: implement the basevertex(id) load intrinsics

[Antia Puentes]

The gl_BaseVertex is in a new location now, and the new basevertexid occupies
the old gl_BaseVertex place.

Reviewed-by: Neil Roberts 
---
 src/intel/compiler/brw_nir.c| 12 
 src/intel/compiler/brw_vec4.cpp | 14 --
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 8f3f77f89ae..a4fe2f5eb14 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -240,8 +240,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 */
const bool has_sgvs =
   nir->info.system_values_read &
-  (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
-   BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
+  (BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID));
 
@@ -262,6 +261,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 nir_intrinsic_instr *intrin = nir_instr_as_intrinsic(instr);
 
 switch (intrin->intrinsic) {
+case nir_intrinsic_load_base_vertex_id:
 case nir_intrinsic_load_base_vertex:
 case nir_intrinsic_load_base_instance:
 case nir_intrinsic_load_vertex_id_zero_base:
@@ -279,7 +279,7 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
 
nir_intrinsic_set_base(load, num_inputs);
switch (intrin->intrinsic) {
-   case nir_intrinsic_load_base_vertex:
+   case nir_intrinsic_load_base_vertex_id:
   nir_intrinsic_set_component(load, 0);
   break;
case nir_intrinsic_load_base_instance:
@@ -292,11 +292,15 @@ brw_nir_lower_vs_inputs(nir_shader *nir,
   nir_intrinsic_set_component(load, 3);
   break;
case nir_intrinsic_load_draw_id:
+   case nir_intrinsic_load_base_vertex:
   /* gl_DrawID is stored right after gl_VertexID and friends
* if any of them exist.
*/
   nir_intrinsic_set_base(load, num_inputs + has_sgvs);
-  nir_intrinsic_set_component(load, 0);
+  if (intrin->intrinsic ==  nir_intrinsic_load_draw_id)
+ nir_intrinsic_set_component(load, 0);
+  else
+ nir_intrinsic_set_component(load, 1);
   break;
default:
   unreachable("Invalid system value intrinsic");
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index d996ab8c89f..5d86cc4ac7e 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2784,13 +2784,18 @@ brw_compile_vs(const struct brw_compiler *compiler, 
void *log_data,
 * incoming vertex attribute.  So, add an extra slot.
 */
if (shader->info.system_values_read &
-   (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
-BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
+   (BITFIELD64_BIT(SYSTEM_VALUE_BASE_INSTANCE) |
 BITFIELD64_BIT(SYSTEM_VALUE_VERTEX_ID_ZERO_BASE) |
 BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))) {
   nr_attribute_slots++;
}
 
+   if (shader->info.system_values_read &
+   (BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX) |
+BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID))) {
+  nr_attribute_slots++;
+   }
+
if (shader->info.system_values_read &
BITFIELD64_BIT(SYSTEM_VALUE_BASE_VERTEX))
   prog_data->uses_basevertex = true;
@@ -2811,12 +2816,9 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
BITFIELD64_BIT(SYSTEM_VALUE_INSTANCE_ID))
   prog_data->uses_instanceid = true;
 
-   /* gl_DrawID has its very own vec4 */
if (shader->info.system_values_read &
-   BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID)) {
+   BITFIELD64_BIT(SYSTEM_VALUE_DRAW_ID))
   prog_data->uses_drawid = true;
-  nr_attribute_slots++;
-   }
 
/* The 3DSTATE_VS documentation lists the lower bound on "Vertex URB Entry
 * Read Length" as 1 in vec4 mode, and 0 in SIMD8 mode.  Empirically, in
-- 
2.14.1

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

[Mesa-dev] [PATCH 2/9] nir: Add SYSTEM_VALUE_BASE_VERTEX_ID instrinsics

[Antia Puentes]

Reviewed-by: Neil Roberts 
---
 src/compiler/nir/nir.c | 4 
 src/compiler/nir/nir_gather_info.c | 1 +
 src/compiler/nir/nir_intrinsics.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/src/compiler/nir/nir.c b/src/compiler/nir/nir.c
index 7380bf436a8..6f0477b0676 100644
--- a/src/compiler/nir/nir.c
+++ b/src/compiler/nir/nir.c
@@ -1913,6 +1913,8 @@ nir_intrinsic_from_system_value(gl_system_value val)
   return nir_intrinsic_load_base_instance;
case SYSTEM_VALUE_VERTEX_ID_ZERO_BASE:
   return nir_intrinsic_load_vertex_id_zero_base;
+   case SYSTEM_VALUE_BASE_VERTEX_ID:
+  return nir_intrinsic_load_base_vertex_id;
case SYSTEM_VALUE_BASE_VERTEX:
   return nir_intrinsic_load_base_vertex;
case SYSTEM_VALUE_INVOCATION_ID:
@@ -1982,6 +1984,8 @@ nir_system_value_from_intrinsic(nir_intrinsic_op intrin)
   return SYSTEM_VALUE_BASE_INSTANCE;
case nir_intrinsic_load_vertex_id_zero_base:
   return SYSTEM_VALUE_VERTEX_ID_ZERO_BASE;
+   case nir_intrinsic_load_base_vertex_id:
+  return SYSTEM_VALUE_BASE_VERTEX_ID;
case nir_intrinsic_load_base_vertex:
   return SYSTEM_VALUE_BASE_VERTEX;
case nir_intrinsic_load_invocation_id:
diff --git a/src/compiler/nir/nir_gather_info.c 
b/src/compiler/nir/nir_gather_info.c
index 13cdae39eca..cf2abb8b8ed 100644
--- a/src/compiler/nir/nir_gather_info.c
+++ b/src/compiler/nir/nir_gather_info.c
@@ -232,6 +232,7 @@ gather_intrinsic_info(nir_intrinsic_instr *instr, 
nir_shader *shader)
case nir_intrinsic_load_vertex_id:
case nir_intrinsic_load_vertex_id_zero_base:
case nir_intrinsic_load_base_vertex:
+   case nir_intrinsic_load_base_vertex_id:
case nir_intrinsic_load_base_instance:
case nir_intrinsic_load_instance_id:
case nir_intrinsic_load_sample_id:
diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index 20bef339ac4..78123dd927a 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -326,6 +326,7 @@ SYSTEM_VALUE(frag_coord, 4, 0, xx, xx, xx)
 SYSTEM_VALUE(front_face, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(vertex_id, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(vertex_id_zero_base, 1, 0, xx, xx, xx)
+SYSTEM_VALUE(base_vertex_id, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(base_vertex, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(instance_id, 1, 0, xx, xx, xx)
 SYSTEM_VALUE(base_instance, 1, 0, xx, xx, xx)
-- 
2.14.1

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