Re: [Mesa-dev] [PATCH v2] i965/sbe: fix number of inputs for active components

2018-02-28 Thread Iago Toral
On Wed, 2018-02-28 at 15:39 -0800, Kenneth Graunke wrote:
> On Monday, February 26, 2018 11:02:08 PM PST Iago Toral Quiroga
> wrote:
> > In 16631ca30ea6 we fixed gen9 active components to account for
> > padded
> > inputs in the URB, which we can have with SSO programs. To do that,
> > instead of going through the bitfield of inputs (which doesn't
> > include
> > padding information), we compute the number of inputs from the size
> > of the URB entry.
> > 
> > Unfortunately, there are some special inputs that are not stored in
> > the URB and that we also need to account for. These special inputs
> > are identified and handled during calculate_attr_overrides(), so
> > this
> > patch modifies this function to return a value with the total
> > number
> > of inputs, including the ones that are not stored in the URB, so we
> > can use that number to program the correct number of active
> > components.
> > 
> > This fixes a regression in a WebGL program that uses Point Sprite
> > functionality (specifically, VARYING_SLOT_PNTC).
> > 
> > v2:
> >  - Add 'Fixes' tag (Mark Janes)
> >  - make no_vue_inputs int instead of uint32_t, and add const
> > qualifier
> >to num_inputs variable (Ian)
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105224
> > Fixes: 16631ca30ea6 (i965/sbe: fix active components for SSO
> > programs with over 16 inputs)
> 
> Or you could just steal the code from anv and do:
> 
>for (unsigned i = 0; i < 32; i++)
>   sbe.AttributeActiveComponentFormat[i] = ACF_XYZW;
> 
> instead of trying to count correctly.


Yeah, I was wondering if that would have any performance impact, so I
have tried this approach with a couple of WebGL demos and I haven't
seen much of a difference. I have also tried a terrain demo that I have
around and gives me more precise frame timing and I seem to get ~0.03
more fps on average with the original patch, so I would say that
performance impact is negligible, if it exists at all.

Seeing how performance-wise there is not a clear difference I'll push
the patch with your recommendation if Jenkins doesn't report anything
weird, which I don't expect it to.

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


Re: [Mesa-dev] [Mesa-users] GraphicsFuzz metamorphic testing of shader compilers

2018-02-28 Thread Tapani Pälli

Hi;

Some feedback below ..

On 02/28/2018 02:21 PM, Hugues Evrard wrote:

Hi Brian, all,

Thanks for the follow-up, and congrats to the team for the prompt bug 
fix! We've just tweeted about it:

https://twitter.com/GraphicsFuzz/status/968815766681333760

We'll be pleased to report further Mesa issues as we find them, yet as a 
three-people team we unfortunately do not have the human resources to do 
proper testing of Mesa on various platforms right now.


It would be good for this test-suite to provide more meaningful report 
of the results. When a test fails, it could list what kind of shaders 
were given to the browser (before browser goes and mangles them before 
giving them to driver). This would help debugging individual failures.



Meanwhile, our public demo gives a nice excerpt of our test suite, and 
is easily ran via a web browser, so don't hesitate to try it on your 
devices:

http://www.graphicsfuzz.com/#demo

Please let us know if it triggers other issues in Mesa!

Many thanks,
Hugues


On 27 February 2018 at 23:40, Brian Paul > wrote:


On 02/27/2018 10:27 AM, Hugues Evrard wrote:

Hi all,

I have just reported a Mesa (i965) crash which was triggered by
a shader from the GraphicsFuzz demo (bug ID 105271), and I
wanted to give a broader context on that bug report.

We are three academics (Alastair, Paul and myself) from Imperial
College London who work on metamorphic testing of shader
compilers, last year we reported drivers bugs across all major
GPU vendors and wrote some blog posts about this
(https://medium.com/@afd_icl/689d15ce922b


>).
We also had the chance to visit some driver developers,
including the Intel Mesa team in Portland -- thanks again for
hosting us!

After months of further development and tedious paperwork, we
are now spinning GraphicsFuzz out of academia with the aim to
raise graphics drivers reliability across the board. Our first
effort focuses on the mobile landscape, you can see wrong images
and crashes due to graphics driver bugs in the Samsung S8s,
Nvidia Shields, Google NexusTV and Pixels, Huawei Honors and
Apple iPhones here (more to come!):
http://www.graphicsfuzz.com/#results


>

On the technical side, a summary of our testing approach is
here: http://www.graphicsfuzz.com/howitworks.html


>

We are looking forward to cover the Mesa drivers, but not
immediately given our current focus on mobile devices.
Meanwhile, anyone can easily try our demo, which executes 15 of
our test shaders, on any WebGL2-capable web browser. Today's bug
report comes from this demo, which crashes i956 (Mesa 17.3.3) on
my Intel HD 520:
http://www.graphicsfuzz.com/#demo




Re: [Mesa-dev] [PATCH] gallium/tests/trivial: fix viewport depth transform

2018-02-28 Thread Mathias Fröhlich
Hi,

On Thursday, 1 March 2018 04:00:15 CET Roland Scheidegger wrote:
> Am 01.03.2018 um 03:28 schrieb Ilia Mirkin:
> > On Wed, Feb 28, 2018 at 8:42 PM, Roland Scheidegger  
wrote:
[...]
> > Is this not the correct behavior? Or is it undefined what happens
> > outside of 0..1?
> I can't really see why clipping to always [0,1] would make sense (since
> you have to clip to near/far anyway too, and the [0,1] range is enforced
> when you call DepthRange already).

As one of you already said, the glDepthRangedNV would have allowed values 
beyond [0, 1]. Also OpenGL 4.2 glDepthRange allowed arbitrary values. But that 
was already taken back with OpenGL 4.3 or 4.4. So my impression was that 
NV_depth_buffer_float is about a dead end that was superseeded by 
ARB_depth_buffer_float.
When I tried to make NV_depth_buffer_float available some years ago we came 
across some funky corner cases in the nvidia extension against the arb 
extension with respect to when to clip to what range and when not. The nvidia 
blob traditionally handled that corners sensibly. IIRC the nvidia blob 
disabled any clamping in the output path from the fragment shader down to the 
depth buffer iff the depth buffer format is GL_DEPTH_BUFFER_FLOAT_MODE_NV 
instead of the float depth buffer enum from the arb extension which are 
distinct GLenum numbers.
Depth precision and thus z-fighting wise the nvidia approach was a great idea. 
But the main OpenGL standard decided to stick with clamping. Also today 
ARB_clip_control enables something comparable with only a about 2bits less 
precision in the complete pipeline including the final float valued depth 
buffer.

best
Mathias


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


[Mesa-dev] [Bug 105296] Account request for Chema Casanova

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105296

--- Comment #2 from Jason Ekstrand  ---
I can vouch for him.

-- 
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] vbo: Try to reuse the same VAO more often for successive dlists.

2018-02-28 Thread Mathias . Froehlich
From: Mathias Fröhlich 

Hi Brian,

that's what I mentioned yesterday.
You may want to test this change against your use cases of your recent
draw primitive optimization.
With one openscenegraph dlist based workload this change improves the
framerates on radeonsi by about 10% compared to without that change.

If it helps, please review...

best
Mathias


The change tries to catch more opportunities to reuse the same set
of VAO's when building up display lists. Instead of checking the
offset with respect to the beginning of the vertex buffer object
the change tries to apply this same optimization with respect to the
previous display list node.

Signed-off-by: Mathias Fröhlich 
---
 src/mesa/vbo/vbo_save_api.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
index 47ee355e72..c2a9921bb7 100644
--- a/src/mesa/vbo/vbo_save_api.c
+++ b/src/mesa/vbo/vbo_save_api.c
@@ -542,11 +542,18 @@ compile_vertex_list(struct gl_context *ctx)
 
/* Duplicate our template, increment refcounts to the storage structs:
 */
+   GLintptr old_offset = 0;
+   if (save->VAO[0]) {
+  old_offset = save->VAO[0]->BufferBinding[0].Offset
+ + save->VAO[0]->VertexAttrib[VERT_ATTRIB_POS].RelativeOffset;
+   }
const GLsizei stride = save->vertex_size*sizeof(GLfloat);
GLintptr buffer_offset =
(save->buffer_map - save->vertex_store->buffer_map) * sizeof(GLfloat);
+   assert(old_offset <= buffer_offset);
+   const GLintptr offset_diff = buffer_offset - old_offset;
GLuint start_offset = 0;
-   if (0 < buffer_offset && 0 < stride && buffer_offset % stride == 0) {
+   if (0 < offset_diff && 0 < stride && offset_diff % stride == 0) {
   /* The vertex size is an exact multiple of the buffer offset.
* This means that we can use zero-based vertex attribute pointers
* and specify the start of the primitive with the _mesa_prim::start
@@ -558,8 +565,9 @@ compile_vertex_list(struct gl_context *ctx)
   /* We cannot immediately update the primitives as some methods below
* still need the uncorrected start vertices
*/
-  start_offset = buffer_offset/stride;
-  buffer_offset = 0;
+  start_offset = offset_diff/stride;
+  assert(old_offset == buffer_offset - offset_diff);
+  buffer_offset = old_offset;
}
GLuint offsets[VBO_ATTRIB_MAX];
for (unsigned i = 0, offset = 0; i < VBO_ATTRIB_MAX; ++i) {
@@ -666,6 +674,9 @@ compile_vertex_list(struct gl_context *ctx)
*/
   free_vertex_store(ctx, save->vertex_store);
   save->vertex_store = NULL;
+  /* When we have a new vbo, we will for sure need a new vao */
+  for (gl_vertex_processing_mode vpm = 0; vpm < VP_MODE_MAX; ++vpm)
+ _mesa_reference_vao(ctx, >VAO[vpm], NULL);
 
   /* Allocate and map new store:
*/
-- 
2.14.3

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


[Mesa-dev] [PATCH] intel/fs: Set up sampler message headers in the visitor on gen7+

2018-02-28 Thread Jason Ekstrand
This gives the scheduler visibility into the headers which should
improve scheduling.  More importantly, however, it lets the scheduler
know that the header gets written.  As-is, the scheduler thinks that a
texture instruction only reads it's payload and is unaware that it may
write to the first register so it may reorder it with respect to a read
from that register.  This is causing issues in a couple of Dota 2 vertex
shaders.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104923
Cc: mesa-sta...@lists.freedesktop.org
---
 src/intel/compiler/brw_fs.cpp   | 40 +
 src/intel/compiler/brw_fs_generator.cpp | 21 +++--
 2 files changed, 39 insertions(+), 22 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 113f62c..ab8cc89 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -4192,17 +4192,15 @@ lower_sampler_logical_send_gen7(const fs_builder , 
fs_inst *inst, opcode op,
op == SHADER_OPCODE_SAMPLEINFO ||
is_high_sampler(devinfo, sampler)) {
   /* For general texture offsets (no txf workaround), we need a header to
-   * put them in.  Note that we're only reserving space for it in the
-   * message payload as it will be initialized implicitly by the
-   * generator.
+   * put them in.
*
* TG4 needs to place its channel select in the header, for interaction
* with ARB_texture_swizzle.  The sampler index is only 4-bits, so for
* larger sampler numbers we need to offset the Sampler State Pointer in
* the header.
*/
+  fs_reg header = retype(sources[0], BRW_REGISTER_TYPE_UD);
   header_size = 1;
-  sources[0] = fs_reg();
   length++;
 
   /* If we're requesting fewer than four channels worth of response,
@@ -4214,6 +4212,40 @@ lower_sampler_logical_send_gen7(const fs_builder , 
fs_inst *inst, opcode op,
  unsigned mask = ~((1 << (regs_written(inst) / reg_width)) - 1) & 0xf;
  inst->offset |= mask << 12;
   }
+
+  /* Build the actual header */
+  const fs_builder ubld = bld.exec_all().group(8, 0);
+  const fs_builder ubld1 = ubld.group(1, 0);
+  ubld.MOV(header, retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
+  if (inst->offset) {
+ ubld1.MOV(component(header, 2), brw_imm_ud(inst->offset));
+  } else if (bld.shader->stage != MESA_SHADER_VERTEX &&
+ bld.shader->stage != MESA_SHADER_FRAGMENT) {
+ /* The vertex and fragment stages have g0.2 set to 0, so
+  * header0.2 is 0 when g0 is copied. Other stages may not, so we
+  * must set it to 0 to avoid setting undesirable bits in the
+  * message.
+  */
+ ubld1.MOV(component(header, 2), brw_imm_ud(0));
+  }
+
+  if (is_high_sampler(devinfo, sampler)) {
+ if (sampler.file == BRW_IMMEDIATE_VALUE) {
+assert(sampler.ud >= 16);
+const int sampler_state_size = 16; /* 16 bytes */
+
+ubld1.ADD(component(header, 3),
+  retype(brw_vec1_grf(0, 3), BRW_REGISTER_TYPE_UD),
+  brw_imm_ud(16 * (sampler.ud / 16) * sampler_state_size));
+ } else {
+fs_reg tmp = ubld1.vgrf(BRW_REGISTER_TYPE_UD);
+ubld1.AND(tmp, sampler, brw_imm_ud(0x0f0));
+ubld1.SHL(tmp, tmp, brw_imm_ud(4));
+ubld1.ADD(component(header, 3),
+  retype(brw_vec1_grf(0, 3), BRW_REGISTER_TYPE_UD),
+  tmp);
+ }
+  }
}
 
if (shadow_c.file != BAD_FILE) {
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index b59c09f..a5a821a 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -1001,19 +1001,13 @@ fs_generator::generate_tex(fs_inst *inst, struct 
brw_reg dst, struct brw_reg src
 * we need to set it up explicitly and load the offset bitfield.
 * Otherwise, we can use an implied move from g0 to the first message reg.
 */
-   if (inst->header_size != 0) {
+   if (inst->header_size != 0 && devinfo->gen < 7) {
   if (devinfo->gen < 6 && !inst->offset) {
  /* Set up an implied move from g0 to the MRF. */
  src = retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UW);
   } else {
- struct brw_reg header_reg;
-
- if (devinfo->gen >= 7) {
-header_reg = src;
- } else {
-assert(inst->base_mrf != -1);
-header_reg = brw_message_reg(inst->base_mrf);
- }
+ assert(inst->base_mrf != -1);
+ struct brw_reg header_reg = brw_message_reg(inst->base_mrf);
 
  brw_push_insn_state(p);
  brw_set_default_exec_size(p, BRW_EXECUTE_8);
@@ -1027,17 +1021,8 @@ fs_generator::generate_tex(fs_inst *inst, struct brw_reg 
dst, struct brw_reg src
 /* Set the offset bits in DWord 

[Mesa-dev] [PATCH 1.5/2] ac: pass the unmodified number of components to load gs inputs

2018-02-28 Thread Timothy Arceri
Currently both users of this would overflow an array when the
input was a dual slot double as they expected the number of
components to be a max of 4.

Since we pass the type we can just let the functions handle
doubles in a way they choose.
---
 src/amd/common/ac_nir_to_llvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 0bbf0a9ecd..2bd1257a52 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3202,8 +3202,8 @@ static LLVMValueRef visit_load_var(struct ac_nir_context 
*ctx,
 
return ctx->abi->load_inputs(ctx->abi, 
instr->variables[0]->var->data.location,
 
instr->variables[0]->var->data.driver_location,
-
instr->variables[0]->var->data.location_frac, ve,
-vertex_index, const_index, 
type);
+
instr->variables[0]->var->data.location_frac,
+instr->num_components, 
vertex_index, const_index, type);
}
 
for (unsigned chan = comp; chan < ve + comp; chan++) {
-- 
2.14.3

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


[Mesa-dev] [PATCH 2/2] radeonsi/nir: fix handling of doubles for gs inputs

2018-02-28 Thread Timothy Arceri
Fixes piglit test:
tests/spec/arb_gpu_shader_fp64/execution/explicit-location-gs-fs-vs.shader_test
---
 src/gallium/drivers/radeonsi/si_shader.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index f3a37d71a0..2ae2544e3f 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1693,10 +1693,14 @@ static LLVMValueRef si_nir_load_input_gs(struct 
ac_shader_abi *abi,
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
 
-   LLVMValueRef value[8];
+   LLVMValueRef value[4];
for (unsigned i = component; i < num_components + component; i++) {
+   unsigned offset = i;
+   if (llvm_type_is_64bit(ctx, type))
+   offset *= 2;
+
value[i] = si_llvm_load_input_gs(>abi, driver_location  / 
4,
-vertex_index, type, i);
+vertex_index, type, offset);
}
 
return ac_build_varying_gather_values(>ac, value, num_components, 
component);
-- 
2.14.3

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


[Mesa-dev] [PATCH 1/2] radeonsi: move si_nir_load_input_gs() to si_shader.c

2018-02-28 Thread Timothy Arceri
All the tess shader and tgsi equivalents are here and it allows
use to use llvm_type_is_64bit() in the following patch without
exposing it externally.
---
 src/gallium/drivers/radeonsi/si_shader.c  | 20 
 src/gallium/drivers/radeonsi/si_shader_internal.h |  9 -
 src/gallium/drivers/radeonsi/si_shader_nir.c  | 20 
 3 files changed, 20 insertions(+), 29 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
b/src/gallium/drivers/radeonsi/si_shader.c
index 2a50b266f6..f3a37d71a0 100644
--- a/src/gallium/drivers/radeonsi/si_shader.c
+++ b/src/gallium/drivers/radeonsi/si_shader.c
@@ -1682,6 +1682,26 @@ LLVMValueRef si_llvm_load_input_gs(struct ac_shader_abi 
*abi,
return LLVMBuildBitCast(ctx->ac.builder, value, type, "");
 }
 
+static LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
+unsigned location,
+unsigned driver_location,
+unsigned component,
+unsigned num_components,
+unsigned vertex_index,
+unsigned const_index,
+LLVMTypeRef type)
+{
+   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
+
+   LLVMValueRef value[8];
+   for (unsigned i = component; i < num_components + component; i++) {
+   value[i] = si_llvm_load_input_gs(>abi, driver_location  / 
4,
+vertex_index, type, i);
+   }
+
+   return ac_build_varying_gather_values(>ac, value, num_components, 
component);
+}
+
 static LLVMValueRef fetch_input_gs(
struct lp_build_tgsi_context *bld_base,
const struct tgsi_full_src_register *reg,
diff --git a/src/gallium/drivers/radeonsi/si_shader_internal.h 
b/src/gallium/drivers/radeonsi/si_shader_internal.h
index dbe4f2e969..dc73517018 100644
--- a/src/gallium/drivers/radeonsi/si_shader_internal.h
+++ b/src/gallium/drivers/radeonsi/si_shader_internal.h
@@ -337,13 +337,4 @@ void si_llvm_load_input_fs(
 
 bool si_nir_build_llvm(struct si_shader_context *ctx, struct nir_shader *nir);
 
-LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
- unsigned location,
- unsigned driver_location,
- unsigned component,
- unsigned num_components,
- unsigned vertex_index,
- unsigned const_index,
- LLVMTypeRef type);
-
 #endif
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 2ca093e237..fc709d8546 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -771,26 +771,6 @@ static void declare_nir_input_fs(struct si_shader_context 
*ctx,
si_llvm_load_input_fs(ctx, input_index, out);
 }
 
-LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
- unsigned location,
- unsigned driver_location,
- unsigned component,
- unsigned num_components,
- unsigned vertex_index,
- unsigned const_index,
- LLVMTypeRef type)
-{
-   struct si_shader_context *ctx = si_shader_context_from_abi(abi);
-
-   LLVMValueRef value[8];
-   for (unsigned i = component; i < num_components + component; i++) {
-   value[i] = si_llvm_load_input_gs(>abi, driver_location  / 
4,
-vertex_index, type, i);
-   }
-
-   return ac_build_varying_gather_values(>ac, value, num_components, 
component);
-}
-
 LLVMValueRef
 si_nir_lookup_interp_param(struct ac_shader_abi *abi,
   enum glsl_interp_mode interp, unsigned location)
-- 
2.14.3

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


[Mesa-dev] [PATCH] r600/cayman: fix fragcood loading recip generation.

2018-02-28 Thread Dave Airlie
From: Dave Airlie 

This fixes some hangs seen where the recip_ieee opcodes would
end up split across the wrong slots.

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/r600/r600_shader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/r600/r600_shader.c 
b/src/gallium/drivers/r600/r600_shader.c
index 46eeb9021f5..4b44f661419 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -3768,7 +3768,7 @@ static int r600_shader_from_tgsi(struct r600_context 
*rctx,
alu.dst.sel = 
shader->input[ctx.fragcoord_input].gpr;
alu.dst.chan = j;
alu.dst.write = (j == 3);
-   alu.last = 1;
+   alu.last = (j == 3);
if ((r = r600_bytecode_add_alu(ctx.bc, )))
return r;
}
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH] gallium/tests/trivial: fix viewport depth transform

2018-02-28 Thread Roland Scheidegger
Am 01.03.2018 um 03:28 schrieb Ilia Mirkin:
> On Wed, Feb 28, 2018 at 8:42 PM, Roland Scheidegger  
> wrote:
>> I suppose that's ok (and safer), albeit I'm not sure why it wouldn't
>> work with nv50.
>> Depth clip is enabled, yes, but I can't see why the produced values
>> wouldn't be inside the view volume (which is defined by the near/far
>> values for z).
>> Granted values outside [0,1] are not permitted by standard GL, but
>> there's extensions for it (NV_depth_buffer_float), so I'm a bit confused.
> 
> Right. I think we have something enabled which clips to 0..1 in the
> view frustrum. Presumably if one were to use glDepthBoundsdNV() with a
> larger range, the driver would have to stop using that 0..1 flag in
> the clipping config.
> 
> Is this not the correct behavior? Or is it undefined what happens
> outside of 0..1?
I can't really see why clipping to always [0,1] would make sense (since
you have to clip to near/far anyway too, and the [0,1] range is enforced
when you call DepthRange already).
But that's why I said it might be safer, since some drivers might not be
able to cope with it, even if at gallium level it probably should work
(but certainly there's no cap bit). Actually at some point we thought it
would be needed for dx10, but dx10 doesn't support near/far values
outside [0,1] neither, so it remains a fringe extension.
Those trivial examples probably really weren't meant to test this
not-quite-supported functionality...

Roland


> 
>>
>> Reviewed-by: Roland Scheidegger 
> 
> Thanks!
> 
>>
>>
>> Am 01.03.2018 um 01:43 schrieb Ilia Mirkin:
>>> These were getting mapped off into outer space, which would cause nv50
>>> and nvc0 to clip the primitives (as depth_clip was enabled).
>>>
>>> Oddly enough, it worked with nv30 and llvmpipe though. Perhaps their
>>> frustrum clipping rules are a bit different?
>>>
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>  src/gallium/tests/trivial/quad-tex.c | 7 ---
>>>  src/gallium/tests/trivial/tri.c  | 6 +++---
>>>  2 files changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/src/gallium/tests/trivial/quad-tex.c 
>>> b/src/gallium/tests/trivial/quad-tex.c
>>> index df0e1301f5e..1f29306ec04 100644
>>> --- a/src/gallium/tests/trivial/quad-tex.c
>>> +++ b/src/gallium/tests/trivial/quad-tex.c
>>> @@ -27,8 +27,8 @@
>>>  #define USE_TRACE 0
>>>  #define WIDTH 300
>>>  #define HEIGHT 300
>>> -#define NEAR 30
>>> -#define FAR 1000
>>> +#define NEAR 0
>>> +#define FAR 1
>>>  #define FLIP 0
>>>
>>>  /* pipe_*_state structs */
>>> @@ -174,6 +174,7 @@ static void init_prog(struct program *p)
>>>   memset(, 0, sizeof(box));
>>>   box.width = 2;
>>>   box.height = 2;
>>> + box.depth = 1;
>>>
>>>   ptr = p->pipe->transfer_map(p->pipe, p->tex, 0, 
>>> PIPE_TRANSFER_WRITE, , );
>>>   ptr[0] = 0x;
>>> @@ -226,7 +227,7 @@ static void init_prog(struct program *p)
>>>   {
>>>   float x = 0;
>>>   float y = 0;
>>> - float z = FAR;
>>> + float z = NEAR;
>>>   float half_width = (float)WIDTH / 2.0f;
>>>   float half_height = (float)HEIGHT / 2.0f;
>>>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
>>> diff --git a/src/gallium/tests/trivial/tri.c 
>>> b/src/gallium/tests/trivial/tri.c
>>> index 71e97022752..87a335fba1e 100644
>>> --- a/src/gallium/tests/trivial/tri.c
>>> +++ b/src/gallium/tests/trivial/tri.c
>>> @@ -27,8 +27,8 @@
>>>  #define USE_TRACE 0
>>>  #define WIDTH 300
>>>  #define HEIGHT 300
>>> -#define NEAR 30
>>> -#define FAR 1000
>>> +#define NEAR 0
>>> +#define FAR 1
>>>  #define FLIP 0
>>>
>>>  /* pipe_*_state structs */
>>> @@ -171,7 +171,7 @@ static void init_prog(struct program *p)
>>>   {
>>>   float x = 0;
>>>   float y = 0;
>>> - float z = FAR;
>>> + float z = NEAR;
>>>   float half_width = (float)WIDTH / 2.0f;
>>>   float half_height = (float)HEIGHT / 2.0f;
>>>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
>>>
>>

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


[Mesa-dev] [PATCH] st/glsl_to_nir: simplify st_nir_assign_var_locations() and fix for fs outputs

2018-02-28 Thread Timothy Arceri
We only need to check for previously processed location on user
defined varyings as they are the only ones that support component
packing. Therefore a single instance of processed_locs can be
shared by regular varyings and patches.

For simplicity we make processed_locs an array in order to handle
dual source bleanding.

Fixes the follow piglit test on radeonsi:
tests/spec/arb_enhanced_layouts/execution/component-layout/fs-output.shader_test
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 2d17ee5696..0e5e49da2c 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -127,8 +127,10 @@ st_nir_assign_var_locations(struct exec_list *var_list, 
unsigned *size,
 {
unsigned location = 0;
unsigned assigned_locations[VARYING_SLOT_TESS_MAX];
-   uint64_t processed_locs = 0;
-   uint32_t processed_patch_locs = 0;
+   uint64_t processed_locs[2] = {0};
+
+   const int base = stage == MESA_SHADER_FRAGMENT ?
+  (int) FRAG_RESULT_DATA0 : (int) VARYING_SLOT_VAR0;
 
nir_foreach_variable(var, var_list) {
 
@@ -138,28 +140,22 @@ st_nir_assign_var_locations(struct exec_list *var_list, 
unsigned *size,
  type = glsl_get_array_element(type);
   }
 
+  /* Builtins don't allow component packing so we only need to worry about
+   * user defined varyings sharing the same location.
+   */
   bool processed = false;
-  if (var->data.patch &&
-  var->data.location != VARYING_SLOT_TESS_LEVEL_INNER &&
-  var->data.location != VARYING_SLOT_TESS_LEVEL_OUTER &&
-  var->data.location != VARYING_SLOT_BOUNDING_BOX0 &&
-  var->data.location != VARYING_SLOT_BOUNDING_BOX1) {
- unsigned patch_loc = var->data.location - VARYING_SLOT_PATCH0;
- if (processed_patch_locs & (1 << patch_loc))
+  if (var->data.location >= base) {
+ unsigned glsl_location = var->data.location - base;
+ if (processed_locs[var->data.index] & ((uint64_t)1 << glsl_location))
 processed = true;
-
- processed_patch_locs |= (1 << patch_loc);
-  } else {
- if (processed_locs & ((uint64_t)1 << var->data.location))
-processed = true;
-
- processed_locs |= ((uint64_t)1 << var->data.location);
+ else
+processed_locs[var->data.index] |= ((uint64_t)1 << glsl_location);
   }
 
   /* Because component packing allows varyings to share the same location
* we may have already have processed this location.
*/
-  if (processed && var->data.location >= VARYING_SLOT_VAR0) {
+  if (processed) {
  var->data.driver_location = assigned_locations[var->data.location];
  *size += type_size(type);
  continue;
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH] gallium/tests/trivial: fix viewport depth transform

2018-02-28 Thread Ilia Mirkin
On Wed, Feb 28, 2018 at 8:42 PM, Roland Scheidegger  wrote:
> I suppose that's ok (and safer), albeit I'm not sure why it wouldn't
> work with nv50.
> Depth clip is enabled, yes, but I can't see why the produced values
> wouldn't be inside the view volume (which is defined by the near/far
> values for z).
> Granted values outside [0,1] are not permitted by standard GL, but
> there's extensions for it (NV_depth_buffer_float), so I'm a bit confused.

Right. I think we have something enabled which clips to 0..1 in the
view frustrum. Presumably if one were to use glDepthBoundsdNV() with a
larger range, the driver would have to stop using that 0..1 flag in
the clipping config.

Is this not the correct behavior? Or is it undefined what happens
outside of 0..1?

>
> Reviewed-by: Roland Scheidegger 

Thanks!

>
>
> Am 01.03.2018 um 01:43 schrieb Ilia Mirkin:
>> These were getting mapped off into outer space, which would cause nv50
>> and nvc0 to clip the primitives (as depth_clip was enabled).
>>
>> Oddly enough, it worked with nv30 and llvmpipe though. Perhaps their
>> frustrum clipping rules are a bit different?
>>
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  src/gallium/tests/trivial/quad-tex.c | 7 ---
>>  src/gallium/tests/trivial/tri.c  | 6 +++---
>>  2 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/gallium/tests/trivial/quad-tex.c 
>> b/src/gallium/tests/trivial/quad-tex.c
>> index df0e1301f5e..1f29306ec04 100644
>> --- a/src/gallium/tests/trivial/quad-tex.c
>> +++ b/src/gallium/tests/trivial/quad-tex.c
>> @@ -27,8 +27,8 @@
>>  #define USE_TRACE 0
>>  #define WIDTH 300
>>  #define HEIGHT 300
>> -#define NEAR 30
>> -#define FAR 1000
>> +#define NEAR 0
>> +#define FAR 1
>>  #define FLIP 0
>>
>>  /* pipe_*_state structs */
>> @@ -174,6 +174,7 @@ static void init_prog(struct program *p)
>>   memset(, 0, sizeof(box));
>>   box.width = 2;
>>   box.height = 2;
>> + box.depth = 1;
>>
>>   ptr = p->pipe->transfer_map(p->pipe, p->tex, 0, 
>> PIPE_TRANSFER_WRITE, , );
>>   ptr[0] = 0x;
>> @@ -226,7 +227,7 @@ static void init_prog(struct program *p)
>>   {
>>   float x = 0;
>>   float y = 0;
>> - float z = FAR;
>> + float z = NEAR;
>>   float half_width = (float)WIDTH / 2.0f;
>>   float half_height = (float)HEIGHT / 2.0f;
>>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
>> diff --git a/src/gallium/tests/trivial/tri.c 
>> b/src/gallium/tests/trivial/tri.c
>> index 71e97022752..87a335fba1e 100644
>> --- a/src/gallium/tests/trivial/tri.c
>> +++ b/src/gallium/tests/trivial/tri.c
>> @@ -27,8 +27,8 @@
>>  #define USE_TRACE 0
>>  #define WIDTH 300
>>  #define HEIGHT 300
>> -#define NEAR 30
>> -#define FAR 1000
>> +#define NEAR 0
>> +#define FAR 1
>>  #define FLIP 0
>>
>>  /* pipe_*_state structs */
>> @@ -171,7 +171,7 @@ static void init_prog(struct program *p)
>>   {
>>   float x = 0;
>>   float y = 0;
>> - float z = FAR;
>> + float z = NEAR;
>>   float half_width = (float)WIDTH / 2.0f;
>>   float half_height = (float)HEIGHT / 2.0f;
>>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Rob Clark
On Wed, Feb 28, 2018 at 7:20 PM, Eric Anholt  wrote:
> Rob Clark  writes:
>
>> On Wed, Feb 28, 2018 at 4:09 PM, Eric Anholt  wrote:
>>> Matt Turner  writes:
>>>
 I find this script *really* annoying. Getting Cc'd on a random sample of
 a series is doing it wrong. Cc lists of 14 people is doing it wrong.

 Let's start the negotiation with "delete this script" and see if anyone
 can come up with a way of making this not so stupid.
>>>
>>> Patch submission done well IMO would be something like github PRs, with
>>> a bot that auto-tags people based on a MAINTAINERS-style opt-in for
>>> reviewing certain paths within the tree.
>>>
>>> I don't think get_reviewers.pl improves the git-send-email situation
>>> compared to maintainers needing to manage email filters.  It's not
>>> consistent, so you need to indoctrinate new submitters (more barriers to
>>> entry!) and maintainers need to maintain their mail filters anyway.
>>
>> Hmm, you have mail filters that parse paths in git patches?
>
> No, I actually skim all the patches.  But it's what you'd have to do if
> you want to actually see all patches to your area and not actually skim
> all the patches yourself, since get_reviewer.pl isn't (and won't ever
> be) used universally.

Well, not-withstanding a switch to a non-email based process, I've
found get_reviewer.pl semi-useful.. sometimes it has flagged someone I
wouldn't have thought to CC who provided useful review comments and
(presumably?) it has spammed me on things I wouldn't have noticed
otherwise..

That said, I'm not defending it's implementation.. it does seem to
come up with some crazy recommendations.  I use it in '-i' interactive
mode and try to trim off some of the more implausible suggestions it
makes (although tbh when it suggests someone who is a frequent mesa
contributor like Matt I tend to assume that was a correct choice and
not pay more attention).

I suppose part of my opinion on it is based on tending to jump between
kernel and mesa and other random things and not being very good at
paying attention to other lists when I am wearing the wrong hat unless
I get cc'd on something.. so I tend not to assume that just because a
patch hit list, that the relevant people will notice it.  And part is
because it seems to work reasonably well for kernel (although
admittedly on the kernel side there is the additional problem of
CC'ing the correct mailing list(s) which isn't a problem for mesa).

IMO changing it to only consider MAINTAINERS and not try to be clever
about git-blame and reviewer history, would be a reasonable solution
(at least given the current email based process).  At least then it is
an opt-in thing.  I'd at least like to be able to opt-in to being CC'd
on patches that touch certain parts of the code.

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


Re: [Mesa-dev] [PATCH] gallium/tests/trivial: fix viewport depth transform

2018-02-28 Thread Roland Scheidegger
I suppose that's ok (and safer), albeit I'm not sure why it wouldn't
work with nv50.
Depth clip is enabled, yes, but I can't see why the produced values
wouldn't be inside the view volume (which is defined by the near/far
values for z).
Granted values outside [0,1] are not permitted by standard GL, but
there's extensions for it (NV_depth_buffer_float), so I'm a bit confused.

Reviewed-by: Roland Scheidegger 


Am 01.03.2018 um 01:43 schrieb Ilia Mirkin:
> These were getting mapped off into outer space, which would cause nv50
> and nvc0 to clip the primitives (as depth_clip was enabled).
> 
> Oddly enough, it worked with nv30 and llvmpipe though. Perhaps their
> frustrum clipping rules are a bit different?
> 
> Signed-off-by: Ilia Mirkin 
> ---
>  src/gallium/tests/trivial/quad-tex.c | 7 ---
>  src/gallium/tests/trivial/tri.c  | 6 +++---
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/src/gallium/tests/trivial/quad-tex.c 
> b/src/gallium/tests/trivial/quad-tex.c
> index df0e1301f5e..1f29306ec04 100644
> --- a/src/gallium/tests/trivial/quad-tex.c
> +++ b/src/gallium/tests/trivial/quad-tex.c
> @@ -27,8 +27,8 @@
>  #define USE_TRACE 0
>  #define WIDTH 300
>  #define HEIGHT 300
> -#define NEAR 30
> -#define FAR 1000
> +#define NEAR 0
> +#define FAR 1
>  #define FLIP 0
>  
>  /* pipe_*_state structs */
> @@ -174,6 +174,7 @@ static void init_prog(struct program *p)
>   memset(, 0, sizeof(box));
>   box.width = 2;
>   box.height = 2;
> + box.depth = 1;
>  
>   ptr = p->pipe->transfer_map(p->pipe, p->tex, 0, 
> PIPE_TRANSFER_WRITE, , );
>   ptr[0] = 0x;
> @@ -226,7 +227,7 @@ static void init_prog(struct program *p)
>   {
>   float x = 0;
>   float y = 0;
> - float z = FAR;
> + float z = NEAR;
>   float half_width = (float)WIDTH / 2.0f;
>   float half_height = (float)HEIGHT / 2.0f;
>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
> diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c
> index 71e97022752..87a335fba1e 100644
> --- a/src/gallium/tests/trivial/tri.c
> +++ b/src/gallium/tests/trivial/tri.c
> @@ -27,8 +27,8 @@
>  #define USE_TRACE 0
>  #define WIDTH 300
>  #define HEIGHT 300
> -#define NEAR 30
> -#define FAR 1000
> +#define NEAR 0
> +#define FAR 1
>  #define FLIP 0
>  
>  /* pipe_*_state structs */
> @@ -171,7 +171,7 @@ static void init_prog(struct program *p)
>   {
>   float x = 0;
>   float y = 0;
> - float z = FAR;
> + float z = NEAR;
>   float half_width = (float)WIDTH / 2.0f;
>   float half_height = (float)HEIGHT / 2.0f;
>   float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
> 

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


Re: [Mesa-dev] [PATCH] i965: Allow 48-bit addressing on Gen8+.

2018-02-28 Thread Kenneth Graunke
On Wednesday, February 28, 2018 2:21:24 PM PST Emil Velikov wrote:
> On 27 February 2018 at 00:05, Kenneth Graunke  wrote:
> 
> > --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > @@ -203,12 +203,23 @@ brw_emit_surface_state(struct brw_context *brw,
> > * FIXME: move to the point of assignment.
> > */
> >assert((aux_offset & 0xfff) == 0);
> > -  uint32_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> > -  *aux_addr = brw_state_reloc(>batch,
> > -  *surf_offset +
> > -  brw->isl_dev.ss.aux_addr_offset,
> > -  aux_bo, *aux_addr,
> > -  reloc_flags);
> > +
> > +  if (devinfo->gen >= 8) {
> > + uint64_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> > + *aux_addr = brw_state_reloc(>batch,
> > + *surf_offset +
> > + brw->isl_dev.ss.aux_addr_offset,
> > + aux_bo, *aux_addr,
> > + reloc_flags);
> > +  } else {
> > + uint32_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> > + *aux_addr = brw_state_reloc(>batch,
> > + *surf_offset +
> > + brw->isl_dev.ss.aux_addr_offset,
> > + aux_bo, *aux_addr,
> > + reloc_flags);
> > +
> Hmm something looks funky here - is there another patch for
> brw_state_reloc somewhere?
> Currently it's declared as
> 
> uint64_t
> brw_state_reloc(struct intel_batchbuffer *batch, uint32_t
> state_offset,
> struct brw_bo *target, uint32_t target_offset,
> unsigned int reloc_flags);
> 
> So the new hunk a) caters for *aux_addr hitting an arithmetic
> overflow, or b) stores the full 64bit return value of the function
> only to discard it.
> If a) is the intended behaviour an explicit note might be a good idea.
> 
> HTH
> Emil

Pointers are 32-bit on Gen4-7.5 and 64-bit on Gen8+.  We changed
brw_state_reloc to return a uint64_t a while back, to handle the new
large size on new platforms.  On old platforms we need to write a 32-bit
value, and the high 32-bits of the value returned is 0.


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


Re: [Mesa-dev] [PATCH] glsl: Fix memory leak with known glsl_type instances

2018-02-28 Thread Kenneth Graunke
On Thursday, February 15, 2018 1:12:54 AM PST Tapani Pälli wrote:
> From: Simon Hausmann 
> 
> When looking up known glsl_type instances in the various hash tables, we
> end up leaking the key instances used for the lookup, as the glsl_type
> constructor allocates memory on the global mem_ctx. This patch changes
> glsl_type to manage its own memory, which fixes the leak and also allows
> getting rid of the global mem_ctx and its mutex.
> 
> v2: remove lambda usage (Tapani)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104884
> Signed-off-by: Simon Hausmann 
> Signed-off-by: Tapani Pälli 
> ---
>  src/compiler/glsl_types.cpp | 83 
> -
>  src/compiler/glsl_types.h   | 44 +++-
>  2 files changed, 41 insertions(+), 86 deletions(-)
> 
> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
> index 3cc5eb0495..81ff97b1f7 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -28,23 +28,12 @@
>  #include "util/hash_table.h"
>  
>  
> -mtx_t glsl_type::mem_mutex = _MTX_INITIALIZER_NP;
>  mtx_t glsl_type::hash_mutex = _MTX_INITIALIZER_NP;
>  hash_table *glsl_type::array_types = NULL;
>  hash_table *glsl_type::record_types = NULL;
>  hash_table *glsl_type::interface_types = NULL;
>  hash_table *glsl_type::function_types = NULL;
>  hash_table *glsl_type::subroutine_types = NULL;
> -void *glsl_type::mem_ctx = NULL;
> -
> -void
> -glsl_type::init_ralloc_type_ctx(void)
> -{
> -   if (glsl_type::mem_ctx == NULL) {
> -  glsl_type::mem_ctx = ralloc_context(NULL);
> -  assert(glsl_type::mem_ctx != NULL);
> -   }
> -}
>  
>  glsl_type::glsl_type(GLenum gl_type,
>   glsl_base_type base_type, unsigned vector_elements,
> @@ -63,14 +52,12 @@ glsl_type::glsl_type(GLenum gl_type,
> STATIC_ASSERT((unsigned(GLSL_TYPE_INT)   & 3) == unsigned(GLSL_TYPE_INT));
> STATIC_ASSERT((unsigned(GLSL_TYPE_FLOAT) & 3) == 
> unsigned(GLSL_TYPE_FLOAT));
>  
> -   mtx_lock(_type::mem_mutex);
> +   this->mem_ctx = ralloc_context(NULL);
> +   assert(this->mem_ctx != NULL);
>  
> -   init_ralloc_type_ctx();
> assert(name != NULL);
> this->name = ralloc_strdup(this->mem_ctx, name);
>  
> -   mtx_unlock(_type::mem_mutex);
> -
> /* Neither dimension is zero or both dimensions are zero.
>  */
> assert((vector_elements == 0) == (matrix_columns == 0));
> @@ -86,14 +73,12 @@ glsl_type::glsl_type(GLenum gl_type, glsl_base_type 
> base_type,
> sampler_array(array), interface_packing(0),
> interface_row_major(0), length(0)
>  {
> -   mtx_lock(_type::mem_mutex);
> +   this->mem_ctx = ralloc_context(NULL);
> +   assert(this->mem_ctx != NULL);
>  
> -   init_ralloc_type_ctx();
> assert(name != NULL);
> this->name = ralloc_strdup(this->mem_ctx, name);
>  
> -   mtx_unlock(_type::mem_mutex);
> -
> memset(& fields, 0, sizeof(fields));
>  
> matrix_columns = vector_elements = 1;
> @@ -110,9 +95,9 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
> unsigned num_fields,
>  {
> unsigned int i;
>  
> -   mtx_lock(_type::mem_mutex);
> +   this->mem_ctx = ralloc_context(NULL);
> +   assert(this->mem_ctx != NULL);
>  
> -   init_ralloc_type_ctx();
> assert(name != NULL);
> this->name = ralloc_strdup(this->mem_ctx, name);
> this->fields.structure = ralloc_array(this->mem_ctx,
> @@ -123,8 +108,6 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
> unsigned num_fields,
>this->fields.structure[i].name = ralloc_strdup(this->fields.structure,
>   fields[i].name);
> }
> -
> -   mtx_unlock(_type::mem_mutex);
>  }
>  
>  glsl_type::glsl_type(const glsl_struct_field *fields, unsigned num_fields,
> @@ -140,9 +123,9 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
> unsigned num_fields,
>  {
> unsigned int i;
>  
> -   mtx_lock(_type::mem_mutex);
> +   this->mem_ctx = ralloc_context(NULL);
> +   assert(this->mem_ctx != NULL);
>  
> -   init_ralloc_type_ctx();
> assert(name != NULL);
> this->name = ralloc_strdup(this->mem_ctx, name);
> this->fields.structure = rzalloc_array(this->mem_ctx,
> @@ -152,8 +135,6 @@ glsl_type::glsl_type(const glsl_struct_field *fields, 
> unsigned num_fields,
>this->fields.structure[i].name = ralloc_strdup(this->fields.structure,
>   fields[i].name);
> }
> -
> -   mtx_unlock(_type::mem_mutex);
>  }
>  
>  glsl_type::glsl_type(const glsl_type *return_type,
> @@ -167,9 +148,8 @@ glsl_type::glsl_type(const glsl_type *return_type,
>  {
> unsigned int i;
>  
> -   mtx_lock(_type::mem_mutex);
> -
> -   init_ralloc_type_ctx();
> +   this->mem_ctx = ralloc_context(NULL);
> +   assert(this->mem_ctx != NULL);
>  
> this->fields.parameters = rzalloc_array(this->mem_ctx,
> 

[Mesa-dev] [PATCH] [rfc] st/nir: handle components on fs outputs.

2018-02-28 Thread Dave Airlie
From: Dave Airlie 

fs outputs don't start above VARYING_SLOT_VAR0, but I assume
that is there for a reason, so make an exception for fragment
outputs.

This fixes with NIR:
tests/spec/arb_enhanced_layouts/execution/component-layout/fs-output.shader_test

Signed-off-by: Dave Airlie 
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 765c827d93..4e7d54e11d 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -123,13 +123,13 @@ st_nir_assign_vs_in_locations(struct gl_program *prog, 
nir_shader *nir)
 
 static void
 st_nir_assign_var_locations(struct exec_list *var_list, unsigned *size,
-gl_shader_stage stage)
+gl_shader_stage stage, bool outputs)
 {
unsigned location = 0;
unsigned assigned_locations[VARYING_SLOT_TESS_MAX];
uint64_t processed_locs = 0;
uint32_t processed_patch_locs = 0;
-
+   bool is_fs_output = outputs && (stage == MESA_SHADER_FRAGMENT);
nir_foreach_variable(var, var_list) {
 
   const struct glsl_type *type = var->type;
@@ -159,7 +159,7 @@ st_nir_assign_var_locations(struct exec_list *var_list, 
unsigned *size,
   /* Because component packing allows varyings to share the same location
* we may have already have processed this location.
*/
-  if (processed && var->data.location >= VARYING_SLOT_VAR0) {
+  if (processed && (var->data.location >= VARYING_SLOT_VAR0 || 
is_fs_output)) {
  var->data.driver_location = assigned_locations[var->data.location];
  *size += type_size(type);
  continue;
@@ -687,7 +687,7 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
   sort_varyings(>outputs);
   st_nir_assign_var_locations(>outputs,
   >num_outputs,
-  nir->info.stage);
+  nir->info.stage, true);
   st_nir_fixup_varying_slots(st, >outputs);
} else if (nir->info.stage == MESA_SHADER_GEOMETRY ||
   nir->info.stage == MESA_SHADER_TESS_CTRL ||
@@ -695,23 +695,23 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
   sort_varyings(>inputs);
   st_nir_assign_var_locations(>inputs,
   >num_inputs,
-  nir->info.stage);
+  nir->info.stage, false);
   st_nir_fixup_varying_slots(st, >inputs);
 
   sort_varyings(>outputs);
   st_nir_assign_var_locations(>outputs,
   >num_outputs,
-  nir->info.stage);
+  nir->info.stage, true);
   st_nir_fixup_varying_slots(st, >outputs);
} else if (nir->info.stage == MESA_SHADER_FRAGMENT) {
   sort_varyings(>inputs);
   st_nir_assign_var_locations(>inputs,
   >num_inputs,
-  nir->info.stage);
+  nir->info.stage, false);
   st_nir_fixup_varying_slots(st, >inputs);
   st_nir_assign_var_locations(>outputs,
   >num_outputs,
-  nir->info.stage);
+  nir->info.stage, true);
} else if (nir->info.stage == MESA_SHADER_COMPUTE) {
/* TODO? */
} else {
-- 
2.14.3

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


[Mesa-dev] [PATCH] gallium/tests/trivial: fix viewport depth transform

2018-02-28 Thread Ilia Mirkin
These were getting mapped off into outer space, which would cause nv50
and nvc0 to clip the primitives (as depth_clip was enabled).

Oddly enough, it worked with nv30 and llvmpipe though. Perhaps their
frustrum clipping rules are a bit different?

Signed-off-by: Ilia Mirkin 
---
 src/gallium/tests/trivial/quad-tex.c | 7 ---
 src/gallium/tests/trivial/tri.c  | 6 +++---
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/gallium/tests/trivial/quad-tex.c 
b/src/gallium/tests/trivial/quad-tex.c
index df0e1301f5e..1f29306ec04 100644
--- a/src/gallium/tests/trivial/quad-tex.c
+++ b/src/gallium/tests/trivial/quad-tex.c
@@ -27,8 +27,8 @@
 #define USE_TRACE 0
 #define WIDTH 300
 #define HEIGHT 300
-#define NEAR 30
-#define FAR 1000
+#define NEAR 0
+#define FAR 1
 #define FLIP 0
 
 /* pipe_*_state structs */
@@ -174,6 +174,7 @@ static void init_prog(struct program *p)
memset(, 0, sizeof(box));
box.width = 2;
box.height = 2;
+   box.depth = 1;
 
ptr = p->pipe->transfer_map(p->pipe, p->tex, 0, 
PIPE_TRANSFER_WRITE, , );
ptr[0] = 0x;
@@ -226,7 +227,7 @@ static void init_prog(struct program *p)
{
float x = 0;
float y = 0;
-   float z = FAR;
+   float z = NEAR;
float half_width = (float)WIDTH / 2.0f;
float half_height = (float)HEIGHT / 2.0f;
float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c
index 71e97022752..87a335fba1e 100644
--- a/src/gallium/tests/trivial/tri.c
+++ b/src/gallium/tests/trivial/tri.c
@@ -27,8 +27,8 @@
 #define USE_TRACE 0
 #define WIDTH 300
 #define HEIGHT 300
-#define NEAR 30
-#define FAR 1000
+#define NEAR 0
+#define FAR 1
 #define FLIP 0
 
 /* pipe_*_state structs */
@@ -171,7 +171,7 @@ static void init_prog(struct program *p)
{
float x = 0;
float y = 0;
-   float z = FAR;
+   float z = NEAR;
float half_width = (float)WIDTH / 2.0f;
float half_height = (float)HEIGHT / 2.0f;
float half_depth = ((float)FAR - (float)NEAR) / 2.0f;
-- 
2.16.1

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


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Matt Turner
On Wed, Feb 28, 2018 at 1:09 PM, Eric Anholt  wrote:
> Matt Turner  writes:
>
>> I find this script *really* annoying. Getting Cc'd on a random sample of
>> a series is doing it wrong. Cc lists of 14 people is doing it wrong.
>>
>> Let's start the negotiation with "delete this script" and see if anyone
>> can come up with a way of making this not so stupid.
>
> Patch submission done well IMO would be something like github PRs, with
> a bot that auto-tags people based on a MAINTAINERS-style opt-in for
> reviewing certain paths within the tree.
>
> I don't think get_reviewers.pl improves the git-send-email situation
> compared to maintainers needing to manage email filters.  It's not
> consistent, so you need to indoctrinate new submitters (more barriers to
> entry!) and maintainers need to maintain their mail filters anyway.
>
> Reviewed-by: Eric Anholt 

I'd be happy to give gitlab a try, and I see that we have an instance
on FDO: https://gitlab.freedesktop.org/

Maybe Daniel can tell us what the status is. I think I heard he was
working on it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Eric Anholt
Rob Clark  writes:

> On Wed, Feb 28, 2018 at 4:09 PM, Eric Anholt  wrote:
>> Matt Turner  writes:
>>
>>> I find this script *really* annoying. Getting Cc'd on a random sample of
>>> a series is doing it wrong. Cc lists of 14 people is doing it wrong.
>>>
>>> Let's start the negotiation with "delete this script" and see if anyone
>>> can come up with a way of making this not so stupid.
>>
>> Patch submission done well IMO would be something like github PRs, with
>> a bot that auto-tags people based on a MAINTAINERS-style opt-in for
>> reviewing certain paths within the tree.
>>
>> I don't think get_reviewers.pl improves the git-send-email situation
>> compared to maintainers needing to manage email filters.  It's not
>> consistent, so you need to indoctrinate new submitters (more barriers to
>> entry!) and maintainers need to maintain their mail filters anyway.
>
> Hmm, you have mail filters that parse paths in git patches?

No, I actually skim all the patches.  But it's what you'd have to do if
you want to actually see all patches to your area and not actually skim
all the patches yourself, since get_reviewer.pl isn't (and won't ever
be) used universally.


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] radeonsi/nir: increase values to 8 for gs fetch.

2018-02-28 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On 01/03/18 11:02, Dave Airlie wrote:

From: Dave Airlie 

This stops a crash when running (still fails):
tests/spec/arb_gpu_shader_fp64/execution/explicit-location-gs-fs-vs.shader_test

Signed-off-by: Dave Airlie 
---
  src/gallium/drivers/radeonsi/si_shader_nir.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index d410a6c2d6..147bd9511d 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -740,7 +740,7 @@ LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
  {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
  
-	LLVMValueRef value[4];

+   LLVMValueRef value[8];
for (unsigned i = component; i < num_components + component; i++) {
value[i] = si_llvm_load_input_gs(>abi, driver_location  / 
4,
 vertex_index, type, i);


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


Re: [Mesa-dev] [PATCH] anv: Always set has_context_priority

2018-02-28 Thread Kenneth Graunke
On Wednesday, February 28, 2018 3:29:00 PM PST Jason Ekstrand wrote:
> We don't zalloc the physical device so we need to unconditionally set
> everything.  Crucible helpfully initializes all allocations to 139 so it
> was getting true regardless of whether or not the kernel actually
> supports context priorities.
> 
> Fixes: 6d8ab53303331 "anv: implement VK_EXT_global_priority extension"
> Cc: Tapani Pälli 
> ---
>  src/intel/vulkan/anv_device.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 56c0c5f..3d44bfd 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -374,9 +374,7 @@ anv_physical_device_init(struct anv_physical_device 
> *device,
> device->has_syncobj = anv_gem_get_param(fd, 
> I915_PARAM_HAS_EXEC_FENCE_ARRAY);
> device->has_syncobj_wait = device->has_syncobj &&
>anv_gem_supports_syncobj_wait(fd);
> -
> -   if (anv_gem_has_context_priority(fd))
> -  device->has_context_priority = true;
> +   device->has_context_priority = anv_gem_has_context_priority(fd);
>  
> bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
>  
> 

Reviewed-by: Kenneth Graunke 


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


Re: [Mesa-dev] [PATCH v2] meson: fix LLVM version detection when <= 3.4

2018-02-28 Thread Dylan Baker
Quoting Emil Velikov (2018-02-28 15:49:37)
> On 28 February 2018 at 21:15, Andres Gomez  wrote:
> > 3 digits versions in LLVM only started from 3.4.1 on. Hence, if you
> > have installed 3.4 or below, meson will fail even when we may not make
> > use of LLVM.
> >
> > v2: Properly compare LLVM version and set patch version to 0
> > if < 3.4.1 (Eric).
> >
> > Cc: Dylan Baker 
> > Cc: Eric Engestrom 
> > Signed-off-by: Andres Gomez 
> > ---
> >  meson.build | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 308f64cf811..e9928a37931 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1037,7 +1037,14 @@ if with_llvm
> ># that for our version checks.
> ># svn suffixes are stripped by meson as of 0.43, and git suffixes are
> ># strippped as of 0.44, but we support older meson versions.
> > -  _llvm_patch = _llvm_version[2]
> > +
> > +  # 3 digits versions in LLVM only started from 3.4.1 on
> > +  if dep_llvm.version().version_compare('>= 3.4.1')
> > +_llvm_patch = _llvm_version[2]
> > +  else
> > +_llvm_patch = '0'
> > +  endif
> > +
> >if _llvm_patch.endswith('svn')
> >  _llvm_patch = _llvm_patch.split('s')[0]
> >elif _llvm_patch.contains('git')
> 
> Thanks for fixing this up Andres.
> Can you please confirm that version_compare() works correctly if the
> version string ends with svn/git - say "3.5.1svn"
> 
> If that's a yes,
> Reviewed-by: Emil Velikov 
> 
> -Emil

It does work correctly with 'svn' or 'git' appended, (at least when I tried it
it did).

Dylan


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


[Mesa-dev] [PATCH] radeonsi/nir: increase values to 8 for gs fetch.

2018-02-28 Thread Dave Airlie
From: Dave Airlie 

This stops a crash when running (still fails):
tests/spec/arb_gpu_shader_fp64/execution/explicit-location-gs-fs-vs.shader_test

Signed-off-by: Dave Airlie 
---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index d410a6c2d6..147bd9511d 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -740,7 +740,7 @@ LLVMValueRef si_nir_load_input_gs(struct ac_shader_abi *abi,
 {
struct si_shader_context *ctx = si_shader_context_from_abi(abi);
 
-   LLVMValueRef value[4];
+   LLVMValueRef value[8];
for (unsigned i = component; i < num_components + component; i++) {
value[i] = si_llvm_load_input_gs(>abi, driver_location  / 
4,
 vertex_index, type, i);
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH v2] travis: make Meson find the proper llvm-config

2018-02-28 Thread Emil Velikov
On 28 February 2018 at 21:18, Andres Gomez  wrote:
> Travis CI has moved to LLVM 5.0, and meson is detecting automatically
> the available version in /usr/local/bin based on the PATH env variable
> order preference.
>
> As for 0.44.x, Meson cannot receive the path to the llvm-config binary
> as a configuration parameter. See
> https://github.com/mesonbuild/meson/issues/2887 and
> https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a77eca3f1bcef
>
> We want to use the custom (APT) installed version. Therefore, let's
> make Meson find our wanted version sooner than the one at
> /usr/local/bin
>
> Once this is corrected, we would still need a patch similar to:
> https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html
>
> v2: Create the link only to the specificly wanted LLVM version (Gert).
>
> Cc: Eric Engestrom 
> Cc: Dylan Baker 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Cc: Gert Wollny 
> Cc: Jon Turney 
> Signed-off-by: Andres Gomez 
> Reviewed-and-Tested-by: Eric Engestrom 
> Reviewed-by: Dylan Baker 
> Reviewed-by: Juan A. Suarez 
> ---
>  .travis.yml | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/.travis.yml b/.travis.yml
> index 0ec08e5bff7..823111ca539 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -34,6 +34,8 @@ matrix:
>  - LABEL="meson Vulkan"
>  - BUILD=meson
>  - MESON_OPTIONS="-Ddri-drivers= -Dgallium-drivers="
> +- LLVM_VERSION=4.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>addons:
>  apt:
>sources:
> @@ -573,8 +575,28 @@ script:
>scons $SCONS_TARGET && eval $SCONS_CHECK_COMMAND;
>  fi
>
> -  - if test "x$BUILD" = xmeson; then
> -  export CFLAGS="$CFLAGS -isystem`pwd`";
> -  meson _build $MESON_OPTIONS;
> -  ninja -C _build;
> +  - |
> +if test "x$BUILD" = xmeson; then
> +
> +  # Travis CI has moved to LLVM 5.0, and meson is detecting
> +  # automatically the available version in /usr/local/bin based on
> +  # the PATH env variable order preference.
> +  #
> +  # As for 0.44.x, Meson cannot receive the path to the
> +  # llvm-config binary as a configuration parameter. See
> +  # https://github.com/mesonbuild/meson/issues/2887 and
> +  # 
> https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a77eca3f1bcef
> +  #
> +  # We want to use the custom (APT) installed version. Therefore,
> +  # let's make Meson find our wanted version sooner than the one
> +  # at /usr/local/bin
> +  #
> +  # Once this is corrected, we would still need a patch similar
> +  # to:
> +  # 
> https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html
> +  test -f /usr/bin/$LLVM_CONFIG && ln -s /usr/bin/$LLVM_CONFIG 
> $HOME/prefix/bin/llvm-config
> +
Patch looks good,
Reviewed-by: Emil Velikov 

Aside:
I'm not quite sure we need Eric's llvm-version toggle.

Haven't looked exactly what meson does now, but it seems like it
probes for specifics binaries/locations.
So having something like /opt/bin/llvm-config-host-4.0 won't cut it -
a sort of pattern fairly common when using OE/Yocto.

Let's keep that for another time,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] meson: fix LLVM version detection when <= 3.4

2018-02-28 Thread Emil Velikov
On 28 February 2018 at 21:15, Andres Gomez  wrote:
> 3 digits versions in LLVM only started from 3.4.1 on. Hence, if you
> have installed 3.4 or below, meson will fail even when we may not make
> use of LLVM.
>
> v2: Properly compare LLVM version and set patch version to 0
> if < 3.4.1 (Eric).
>
> Cc: Dylan Baker 
> Cc: Eric Engestrom 
> Signed-off-by: Andres Gomez 
> ---
>  meson.build | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 308f64cf811..e9928a37931 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1037,7 +1037,14 @@ if with_llvm
># that for our version checks.
># svn suffixes are stripped by meson as of 0.43, and git suffixes are
># strippped as of 0.44, but we support older meson versions.
> -  _llvm_patch = _llvm_version[2]
> +
> +  # 3 digits versions in LLVM only started from 3.4.1 on
> +  if dep_llvm.version().version_compare('>= 3.4.1')
> +_llvm_patch = _llvm_version[2]
> +  else
> +_llvm_patch = '0'
> +  endif
> +
>if _llvm_patch.endswith('svn')
>  _llvm_patch = _llvm_patch.split('s')[0]
>elif _llvm_patch.contains('git')

Thanks for fixing this up Andres.
Can you please confirm that version_compare() works correctly if the
version string ends with svn/git - say "3.5.1svn"

If that's a yes,
Reviewed-by: Emil Velikov 

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


Re: [Mesa-dev] [PATCH] ac/nir: fix shared atomic operations.

2018-02-28 Thread Timothy Arceri

On 01/03/18 10:39, Dave Airlie wrote:

From: Dave Airlie 

The nir->llvm conversion was using the wrong srcs.


Well that's embarrassing.

Reviewed-by: Timothy Arceri 



Fixes:
tests/spec/arb_compute_shader/execution/shared-atomics.shader_test

Signed-off-by: Dave Airlie 
---
  src/amd/common/ac_nir_to_llvm.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index bc72d2a6f1..f0361530dc 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3991,10 +3991,10 @@ visit_store_shared(struct ac_nir_context *ctx,
  
  static LLVMValueRef visit_var_atomic(struct ac_nir_context *ctx,

 const nir_intrinsic_instr *instr,
-LLVMValueRef ptr)
+LLVMValueRef ptr, int src_idx)
  {
LLVMValueRef result;
-   LLVMValueRef src = get_src(ctx, instr->src[0]);
+   LLVMValueRef src = get_src(ctx, instr->src[src_idx]);
  
  	if (instr->intrinsic == nir_intrinsic_var_atomic_comp_swap ||

instr->intrinsic == nir_intrinsic_shared_atomic_comp_swap) {
@@ -4574,8 +4574,8 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_shared_atomic_xor:
case nir_intrinsic_shared_atomic_exchange:
case nir_intrinsic_shared_atomic_comp_swap: {
-   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[1]);
-   result = visit_var_atomic(ctx, instr, ptr);
+   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[0]);
+   result = visit_var_atomic(ctx, instr, ptr, 1);
break;
}
case nir_intrinsic_var_atomic_add:
@@ -4589,7 +4589,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_var_atomic_exchange:
case nir_intrinsic_var_atomic_comp_swap: {
LLVMValueRef ptr = build_gep_for_deref(ctx, 
instr->variables[0]);
-   result = visit_var_atomic(ctx, instr, ptr);
+   result = visit_var_atomic(ctx, instr, ptr, 0);
break;
}
case nir_intrinsic_interp_var_at_centroid:


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


Re: [Mesa-dev] [PATCH] ac/nir: fix shared atomic operations.

2018-02-28 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

On Thu, Mar 1, 2018 at 12:39 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The nir->llvm conversion was using the wrong srcs.
>
> Fixes:
> tests/spec/arb_compute_shader/execution/shared-atomics.shader_test
>
> Signed-off-by: Dave Airlie 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index bc72d2a6f1..f0361530dc 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -3991,10 +3991,10 @@ visit_store_shared(struct ac_nir_context *ctx,
>
>  static LLVMValueRef visit_var_atomic(struct ac_nir_context *ctx,
>  const nir_intrinsic_instr *instr,
> -LLVMValueRef ptr)
> +LLVMValueRef ptr, int src_idx)
>  {
> LLVMValueRef result;
> -   LLVMValueRef src = get_src(ctx, instr->src[0]);
> +   LLVMValueRef src = get_src(ctx, instr->src[src_idx]);
>
> if (instr->intrinsic == nir_intrinsic_var_atomic_comp_swap ||
> instr->intrinsic == nir_intrinsic_shared_atomic_comp_swap) {
> @@ -4574,8 +4574,8 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
> case nir_intrinsic_shared_atomic_xor:
> case nir_intrinsic_shared_atomic_exchange:
> case nir_intrinsic_shared_atomic_comp_swap: {
> -   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[1]);
> -   result = visit_var_atomic(ctx, instr, ptr);
> +   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[0]);
> +   result = visit_var_atomic(ctx, instr, ptr, 1);
> break;
> }
> case nir_intrinsic_var_atomic_add:
> @@ -4589,7 +4589,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
> case nir_intrinsic_var_atomic_exchange:
> case nir_intrinsic_var_atomic_comp_swap: {
> LLVMValueRef ptr = build_gep_for_deref(ctx, 
> instr->variables[0]);
> -   result = visit_var_atomic(ctx, instr, ptr);
> +   result = visit_var_atomic(ctx, instr, ptr, 0);
> break;
> }
> case nir_intrinsic_interp_var_at_centroid:
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] i965/sbe: fix number of inputs for active components

2018-02-28 Thread Kenneth Graunke
On Monday, February 26, 2018 11:02:08 PM PST Iago Toral Quiroga wrote:
> In 16631ca30ea6 we fixed gen9 active components to account for padded
> inputs in the URB, which we can have with SSO programs. To do that,
> instead of going through the bitfield of inputs (which doesn't include
> padding information), we compute the number of inputs from the size
> of the URB entry.
> 
> Unfortunately, there are some special inputs that are not stored in
> the URB and that we also need to account for. These special inputs
> are identified and handled during calculate_attr_overrides(), so this
> patch modifies this function to return a value with the total number
> of inputs, including the ones that are not stored in the URB, so we
> can use that number to program the correct number of active components.
> 
> This fixes a regression in a WebGL program that uses Point Sprite
> functionality (specifically, VARYING_SLOT_PNTC).
> 
> v2:
>  - Add 'Fixes' tag (Mark Janes)
>  - make no_vue_inputs int instead of uint32_t, and add const qualifier
>to num_inputs variable (Ian)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105224
> Fixes: 16631ca30ea6 (i965/sbe: fix active components for SSO programs with 
> over 16 inputs)

Or you could just steal the code from anv and do:

   for (unsigned i = 0; i < 32; i++)
  sbe.AttributeActiveComponentFormat[i] = ACF_XYZW;

instead of trying to count correctly.


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


[Mesa-dev] [PATCH] ac/nir: fix shared atomic operations.

2018-02-28 Thread Dave Airlie
From: Dave Airlie 

The nir->llvm conversion was using the wrong srcs.

Fixes:
tests/spec/arb_compute_shader/execution/shared-atomics.shader_test

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index bc72d2a6f1..f0361530dc 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3991,10 +3991,10 @@ visit_store_shared(struct ac_nir_context *ctx,
 
 static LLVMValueRef visit_var_atomic(struct ac_nir_context *ctx,
 const nir_intrinsic_instr *instr,
-LLVMValueRef ptr)
+LLVMValueRef ptr, int src_idx)
 {
LLVMValueRef result;
-   LLVMValueRef src = get_src(ctx, instr->src[0]);
+   LLVMValueRef src = get_src(ctx, instr->src[src_idx]);
 
if (instr->intrinsic == nir_intrinsic_var_atomic_comp_swap ||
instr->intrinsic == nir_intrinsic_shared_atomic_comp_swap) {
@@ -4574,8 +4574,8 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_shared_atomic_xor:
case nir_intrinsic_shared_atomic_exchange:
case nir_intrinsic_shared_atomic_comp_swap: {
-   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[1]);
-   result = visit_var_atomic(ctx, instr, ptr);
+   LLVMValueRef ptr = get_memory_ptr(ctx, instr->src[0]);
+   result = visit_var_atomic(ctx, instr, ptr, 1);
break;
}
case nir_intrinsic_var_atomic_add:
@@ -4589,7 +4589,7 @@ static void visit_intrinsic(struct ac_nir_context *ctx,
case nir_intrinsic_var_atomic_exchange:
case nir_intrinsic_var_atomic_comp_swap: {
LLVMValueRef ptr = build_gep_for_deref(ctx, 
instr->variables[0]);
-   result = visit_var_atomic(ctx, instr, ptr);
+   result = visit_var_atomic(ctx, instr, ptr, 0);
break;
}
case nir_intrinsic_interp_var_at_centroid:
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH v2] i965/sbe: fix number of inputs for active components

2018-02-28 Thread Kenneth Graunke
On Monday, February 26, 2018 11:02:08 PM PST Iago Toral Quiroga wrote:
> In 16631ca30ea6 we fixed gen9 active components to account for padded
> inputs in the URB, which we can have with SSO programs. To do that,
> instead of going through the bitfield of inputs (which doesn't include
> padding information), we compute the number of inputs from the size
> of the URB entry.
> 
> Unfortunately, there are some special inputs that are not stored in
> the URB and that we also need to account for. These special inputs
> are identified and handled during calculate_attr_overrides(), so this
> patch modifies this function to return a value with the total number
> of inputs, including the ones that are not stored in the URB, so we
> can use that number to program the correct number of active components.
> 
> This fixes a regression in a WebGL program that uses Point Sprite
> functionality (specifically, VARYING_SLOT_PNTC).
> 
> v2:
>  - Add 'Fixes' tag (Mark Janes)
>  - make no_vue_inputs int instead of uint32_t, and add const qualifier
>to num_inputs variable (Ian)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105224
> Fixes: 16631ca30ea6 (i965/sbe: fix active components for SSO programs with 
> over 16 inputs)
> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 31 
> ---
>  1 file changed, 23 insertions(+), 8 deletions(-)

:(  Thanks for fixing this, Iago.

Reviewed-by: Kenneth Graunke 


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


Re: [Mesa-dev] [PATCH] ac/nir: don't apply slice rounding on txf_ms

2018-02-28 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

On Thu, Mar 1, 2018 at 12:33 AM, Timothy Arceri  wrote:
> Thanks!
>
> Reviewed-by: Timothy Arceri 
>
> On 01/03/18 10:26, Dave Airlie wrote:
>>
>> From: Dave Airlie 
>>
>> This matches the tgsi code.
>>
>> Fixes arb_texture_multisample texelFetch piglit tests.
>>
>> Signed-off-by: Dave Airlie 
>> ---
>>   src/amd/common/ac_nir_to_llvm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/amd/common/ac_nir_to_llvm.c
>> b/src/amd/common/ac_nir_to_llvm.c
>> index 8b662f884f..bc72d2a6f1 100644
>> --- a/src/amd/common/ac_nir_to_llvm.c
>> +++ b/src/amd/common/ac_nir_to_llvm.c
>> @@ -5105,7 +5105,7 @@ static void visit_tex(struct ac_nir_context *ctx,
>> nir_tex_instr *instr)
>>  instr->sampler_dim ==
>> GLSL_SAMPLER_DIM_SUBPASS ||
>>  instr->sampler_dim ==
>> GLSL_SAMPLER_DIM_SUBPASS_MS) &&
>> instr->is_array &&
>> -   instr->op != nir_texop_txf) {
>> +   instr->op != nir_texop_txf && instr->op !=
>> nir_texop_txf_ms) {
>> coords[2] = apply_round_slice(>ac,
>> coords[2]);
>> }
>> address[count++] = coords[2];
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] ac/nir: don't apply slice rounding on txf_ms

2018-02-28 Thread Timothy Arceri

Thanks!

Reviewed-by: Timothy Arceri 

On 01/03/18 10:26, Dave Airlie wrote:

From: Dave Airlie 

This matches the tgsi code.

Fixes arb_texture_multisample texelFetch piglit tests.

Signed-off-by: Dave Airlie 
---
  src/amd/common/ac_nir_to_llvm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 8b662f884f..bc72d2a6f1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5105,7 +5105,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
 instr->sampler_dim == GLSL_SAMPLER_DIM_SUBPASS ||
 instr->sampler_dim == GLSL_SAMPLER_DIM_SUBPASS_MS) 
&&
instr->is_array &&
-   instr->op != nir_texop_txf) {
+   instr->op != nir_texop_txf && instr->op != 
nir_texop_txf_ms) {
coords[2] = apply_round_slice(>ac, 
coords[2]);
}
address[count++] = coords[2];


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


[Mesa-dev] [PATCH] anv: Always set has_context_priority

2018-02-28 Thread Jason Ekstrand
We don't zalloc the physical device so we need to unconditionally set
everything.  Crucible helpfully initializes all allocations to 139 so it
was getting true regardless of whether or not the kernel actually
supports context priorities.

Fixes: 6d8ab53303331 "anv: implement VK_EXT_global_priority extension"
Cc: Tapani Pälli 
---
 src/intel/vulkan/anv_device.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 56c0c5f..3d44bfd 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -374,9 +374,7 @@ anv_physical_device_init(struct anv_physical_device *device,
device->has_syncobj = anv_gem_get_param(fd, 
I915_PARAM_HAS_EXEC_FENCE_ARRAY);
device->has_syncobj_wait = device->has_syncobj &&
   anv_gem_supports_syncobj_wait(fd);
-
-   if (anv_gem_has_context_priority(fd))
-  device->has_context_priority = true;
+   device->has_context_priority = anv_gem_has_context_priority(fd);
 
bool swizzled = anv_gem_get_bit6_swizzle(fd, I915_TILING_X);
 
-- 
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] ac/nir: don't apply slice rounding on txf_ms

2018-02-28 Thread Dave Airlie
From: Dave Airlie 

This matches the tgsi code.

Fixes arb_texture_multisample texelFetch piglit tests.

Signed-off-by: Dave Airlie 
---
 src/amd/common/ac_nir_to_llvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 8b662f884f..bc72d2a6f1 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -5105,7 +5105,7 @@ static void visit_tex(struct ac_nir_context *ctx, 
nir_tex_instr *instr)
 instr->sampler_dim == GLSL_SAMPLER_DIM_SUBPASS ||
 instr->sampler_dim == GLSL_SAMPLER_DIM_SUBPASS_MS) 
&&
instr->is_array &&
-   instr->op != nir_texop_txf) {
+   instr->op != nir_texop_txf && instr->op != 
nir_texop_txf_ms) {
coords[2] = apply_round_slice(>ac, 
coords[2]);
}
address[count++] = coords[2];
-- 
2.14.3

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


Re: [Mesa-dev] [PATCH] nir/serialize: handle var->name being NULL

2018-02-28 Thread Timothy Arceri

Reviewed-by: Timothy Arceri 

On 01/03/18 04:13, Alejandro Piñeiro wrote:

var->name could be true under ARB_gl_spirv for example. And in any
case, the code is already handing var name being NULL when reading a
variable, so it is consistent to do it writing a variable too.
---
  src/compiler/nir/nir_serialize.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_serialize.c b/src/compiler/nir/nir_serialize.c
index 9fe46a675f6..00df49c2ef3 100644
--- a/src/compiler/nir/nir_serialize.c
+++ b/src/compiler/nir/nir_serialize.c
@@ -137,7 +137,8 @@ write_variable(write_ctx *ctx, const nir_variable *var)
 write_add_object(ctx, var);
 encode_type_to_blob(ctx->blob, var->type);
 blob_write_uint32(ctx->blob, !!(var->name));
-   blob_write_string(ctx->blob, var->name);
+   if (var->name)
+  blob_write_string(ctx->blob, var->name);
 blob_write_bytes(ctx->blob, (uint8_t *) >data, sizeof(var->data));
 blob_write_uint32(ctx->blob, var->num_state_slots);
 blob_write_bytes(ctx->blob, (uint8_t *) var->state_slots,


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


[Mesa-dev] [PATCH] intel: Drop program size pointer from vec4/fs assembly getters.

2018-02-28 Thread Kenneth Graunke
These days, we're just passing a pointer to a prog_data field, which
we already have access to.  We can just use it directly.

(In the past, it was a pointer to a separate value.)
---
 src/intel/compiler/brw_fs.cpp  | 4 ++--
 src/intel/compiler/brw_fs.h| 2 +-
 src/intel/compiler/brw_fs_generator.cpp| 4 ++--
 src/intel/compiler/brw_shader.cpp  | 5 ++---
 src/intel/compiler/brw_vec4.cpp| 5 ++---
 src/intel/compiler/brw_vec4.h  | 3 +--
 src/intel/compiler/brw_vec4_generator.cpp  | 5 ++---
 src/intel/compiler/brw_vec4_gs_visitor.cpp | 9 +++--
 src/intel/compiler/brw_vec4_tcs.cpp| 5 ++---
 9 files changed, 17 insertions(+), 25 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index bed632d21b9..8f74660b59b 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6886,7 +6886,7 @@ brw_compile_fs(const struct brw_compiler *compiler, void 
*log_data,
   prog_data->reg_blocks_0 = brw_register_blocks(simd16_grf_used);
}
 
-   return g.get_assembly(_data->base.program_size);
+   return g.get_assembly();
 }
 
 fs_reg *
@@ -7109,7 +7109,7 @@ brw_compile_cs(const struct brw_compiler *compiler, void 
*log_data,
 
   g.generate_code(cfg, prog_data->simd_size);
 
-  ret = g.get_assembly(_data->base.program_size);
+  ret = g.get_assembly();
}
 
delete v8;
diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index 63373580ee4..ab8d0943d15 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -395,7 +395,7 @@ public:
 
void enable_debug(const char *shader_name);
int generate_code(const cfg_t *cfg, int dispatch_width);
-   const unsigned *get_assembly(unsigned int *assembly_size);
+   const unsigned *get_assembly();
 
 private:
void fire_fb_write(fs_inst *inst,
diff --git a/src/intel/compiler/brw_fs_generator.cpp 
b/src/intel/compiler/brw_fs_generator.cpp
index cd5be054f69..2385d03ed81 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2261,7 +2261,7 @@ fs_generator::generate_code(const cfg_t *cfg, int 
dispatch_width)
 }
 
 const unsigned *
-fs_generator::get_assembly(unsigned int *assembly_size)
+fs_generator::get_assembly()
 {
-   return brw_get_program(p, assembly_size);
+   return brw_get_program(p, _data->program_size);
 }
diff --git a/src/intel/compiler/brw_shader.cpp 
b/src/intel/compiler/brw_shader.cpp
index 1df4f35cd8e..f44d82ef398 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -1264,7 +1264,7 @@ brw_compile_tes(const struct brw_compiler *compiler,
 
   g.generate_code(v.cfg, 8);
 
-  assembly = g.get_assembly(_data->base.base.program_size);
+  assembly = g.get_assembly();
} else {
   brw::vec4_tes_visitor v(compiler, log_data, key, prog_data,
  nir, mem_ctx, shader_time_index);
@@ -1278,8 +1278,7 @@ brw_compile_tes(const struct brw_compiler *compiler,
 v.dump_instructions();
 
   assembly = brw_vec4_generate_assembly(compiler, log_data, mem_ctx, nir,
-_data->base, v.cfg,
-
_data->base.base.program_size);
+_data->base, v.cfg);
}
 
return assembly;
diff --git a/src/intel/compiler/brw_vec4.cpp b/src/intel/compiler/brw_vec4.cpp
index e95886349d8..fb69ab8fe59 100644
--- a/src/intel/compiler/brw_vec4.cpp
+++ b/src/intel/compiler/brw_vec4.cpp
@@ -2882,7 +2882,7 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
  g.enable_debug(debug_name);
   }
   g.generate_code(v.cfg, 8);
-  assembly = g.get_assembly(_data->base.base.program_size);
+  assembly = g.get_assembly();
}
 
if (!assembly) {
@@ -2898,8 +2898,7 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
   }
 
   assembly = brw_vec4_generate_assembly(compiler, log_data, mem_ctx,
-shader, _data->base, v.cfg,
-
_data->base.base.program_size);
+shader, _data->base, v.cfg);
}
 
return assembly;
diff --git a/src/intel/compiler/brw_vec4.h b/src/intel/compiler/brw_vec4.h
index 2e93ee2946f..39ce51c7dcf 100644
--- a/src/intel/compiler/brw_vec4.h
+++ b/src/intel/compiler/brw_vec4.h
@@ -45,8 +45,7 @@ brw_vec4_generate_assembly(const struct brw_compiler 
*compiler,
void *mem_ctx,
const nir_shader *nir,
struct brw_vue_prog_data *prog_data,
-   const struct cfg_t *cfg,
-   unsigned *out_assembly_size);
+   const struct cfg_t *cfg);
 
 #ifdef __cplusplus
 } /* extern "C" */
diff --git 

[Mesa-dev] [Bug 105291] r600 [CEDAR]: GPU stalls when running shadertoy "ladybug"

2018-02-28 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105291

mirh  changed:

   What|Removed |Added

 CC||m...@protonmail.ch

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


Re: [Mesa-dev] [PATCH v2] travis: make Meson find the proper llvm-config

2018-02-28 Thread Gert Wollny
Looks fine to me, 

Reviewed-By: Gert Wollny 

Am Mittwoch, den 28.02.2018, 23:18 +0200 schrieb Andres Gomez:
> Travis CI has moved to LLVM 5.0, and meson is detecting automatically
> the available version in /usr/local/bin based on the PATH env
> variable
> order preference.
> 
> As for 0.44.x, Meson cannot receive the path to the llvm-config
> binary
> as a configuration parameter. See
> https://github.com/mesonbuild/meson/issues/2887 and
> https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a7
> 7eca3f1bcef
> 
> We want to use the custom (APT) installed version. Therefore, let's
> make Meson find our wanted version sooner than the one at
> /usr/local/bin
> 
> Once this is corrected, we would still need a patch similar to:
> https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.
> html
> 
> v2: Create the link only to the specificly wanted LLVM version
> (Gert).
> 
> Cc: Eric Engestrom 
> Cc: Dylan Baker 
> Cc: Emil Velikov 
> Cc: Juan A. Suarez Romero 
> Cc: Gert Wollny 
> Cc: Jon Turney 
> Signed-off-by: Andres Gomez 
> Reviewed-and-Tested-by: Eric Engestrom 
> Reviewed-by: Dylan Baker 
> Reviewed-by: Juan A. Suarez 
> ---
>  .travis.yml | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 0ec08e5bff7..823111ca539 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -34,6 +34,8 @@ matrix:
>  - LABEL="meson Vulkan"
>  - BUILD=meson
>  - MESON_OPTIONS="-Ddri-drivers= -Dgallium-drivers="
> +- LLVM_VERSION=4.0
> +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
>addons:
>  apt:
>sources:
> @@ -573,8 +575,28 @@ script:
>scons $SCONS_TARGET && eval $SCONS_CHECK_COMMAND;
>  fi
>  
> -  - if test "x$BUILD" = xmeson; then
> -  export CFLAGS="$CFLAGS -isystem`pwd`";
> -  meson _build $MESON_OPTIONS;
> -  ninja -C _build;
> +  - |
> +if test "x$BUILD" = xmeson; then
> +
> +  # Travis CI has moved to LLVM 5.0, and meson is detecting
> +  # automatically the available version in /usr/local/bin based
> on
> +  # the PATH env variable order preference.
> +  #
> +  # As for 0.44.x, Meson cannot receive the path to the
> +  # llvm-config binary as a configuration parameter. See
> +  # https://github.com/mesonbuild/meson/issues/2887 and
> +  # https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7
> dcacc61a77eca3f1bcef
> +  #
> +  # We want to use the custom (APT) installed version.
> Therefore,
> +  # let's make Meson find our wanted version sooner than the one
> +  # at /usr/local/bin
> +  #
> +  # Once this is corrected, we would still need a patch similar
> +  # to:
> +  # https://lists.freedesktop.org/archives/mesa-dev/2017-Decembe
> r/180217.html
> +  test -f /usr/bin/$LLVM_CONFIG && ln -s /usr/bin/$LLVM_CONFIG
> $HOME/prefix/bin/llvm-config
> +
> +  export CFLAGS="$CFLAGS -isystem`pwd`"
> +  meson _build $MESON_OPTIONS
> +  ninja -C _build
>  fi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Allow 48-bit addressing on Gen8+.

2018-02-28 Thread Emil Velikov
On 27 February 2018 at 00:05, Kenneth Graunke  wrote:

> --- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> +++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> @@ -203,12 +203,23 @@ brw_emit_surface_state(struct brw_context *brw,
> * FIXME: move to the point of assignment.
> */
>assert((aux_offset & 0xfff) == 0);
> -  uint32_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> -  *aux_addr = brw_state_reloc(>batch,
> -  *surf_offset +
> -  brw->isl_dev.ss.aux_addr_offset,
> -  aux_bo, *aux_addr,
> -  reloc_flags);
> +
> +  if (devinfo->gen >= 8) {
> + uint64_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> + *aux_addr = brw_state_reloc(>batch,
> + *surf_offset +
> + brw->isl_dev.ss.aux_addr_offset,
> + aux_bo, *aux_addr,
> + reloc_flags);
> +  } else {
> + uint32_t *aux_addr = state + brw->isl_dev.ss.aux_addr_offset;
> + *aux_addr = brw_state_reloc(>batch,
> + *surf_offset +
> + brw->isl_dev.ss.aux_addr_offset,
> + aux_bo, *aux_addr,
> + reloc_flags);
> +
Hmm something looks funky here - is there another patch for
brw_state_reloc somewhere?
Currently it's declared as

uint64_t
brw_state_reloc(struct intel_batchbuffer *batch, uint32_t
state_offset,
struct brw_bo *target, uint32_t target_offset,
unsigned int reloc_flags);

So the new hunk a) caters for *aux_addr hitting an arithmetic
overflow, or b) stores the full 64bit return value of the function
only to discard it.
If a) is the intended behaviour an explicit note might be a good idea.

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


Re: [Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Rob Clark
hmm, I haven't tried passing a struct (rather than a pointer to a
struct) as a parameter, but if there were 8/16 bit fields in the
struct it would calculate the size incorrectly.

(otoh the more important question is whether this agrees with how
clover lays out the input buffer, as far as where the n+1'th parameter
starts, which I'm not sure about)

BR,
-R

On Wed, Feb 28, 2018 at 4:47 PM, Jason Ekstrand  wrote:
> I thought OpenCL used a different set of alignment rules for structs,
> unions, etc.  In particular, I thought it was very close to standard C.  If
> that's true, then std430 is not what you want.
>
> On Wed, Feb 28, 2018 at 1:44 PM, Karol Herbst  wrote:
>>
>> it isn't yet. But you would use it in your driver when calculating
>> your memory offsets for kernel arguments. In OpenCL things are aligned
>> in memory by the size of the type and we would use those functions to
>> calculate those.
>>
>> On Wed, Feb 28, 2018 at 10:39 PM, Jason Ekstrand 
>> wrote:
>> > Looking through commit titles, I don't see any obvious place where this
>> > would get used.
>> >
>> > On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
>> >>
>> >> Signed-off-by: Rob Clark 
>> >> ---
>> >>  src/compiler/nir_types.cpp | 12 
>> >>  src/compiler/nir_types.h   |  4 
>> >>  2 files changed, 16 insertions(+)
>> >>
>> >> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
>> >> index cbdd452dc81..0085a19248a 100644
>> >> --- a/src/compiler/nir_types.cpp
>> >> +++ b/src/compiler/nir_types.cpp
>> >> @@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
>> >> return type->arrays_of_arrays_size();
>> >>  }
>> >>
>> >> +unsigned
>> >> +glsl_std430_size(const struct glsl_type *type, bool row_major)
>> >> +{
>> >> +   return type->std430_size(row_major);
>> >> +}
>> >> +
>> >> +unsigned
>> >> +glsl_std430_base_alignment(const struct glsl_type *type, bool
>> >> row_major)
>> >> +{
>> >> +   return type->std430_base_alignment(row_major);
>> >> +}
>> >> +
>> >>  unsigned
>> >>  glsl_count_attribute_slots(const struct glsl_type *type,
>> >> bool is_vertex_input)
>> >> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
>> >> index e2dfd1ef5b7..5b5e09d137f 100644
>> >> --- a/src/compiler/nir_types.h
>> >> +++ b/src/compiler/nir_types.h
>> >> @@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type
>> >> *type);
>> >>
>> >>  unsigned glsl_get_aoa_size(const struct glsl_type *type);
>> >>
>> >> +unsigned glsl_std430_size(const struct glsl_type *type, bool
>> >> row_major);
>> >> +
>> >> +unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool
>> >> row_major);
>> >> +
>> >>  unsigned glsl_count_attribute_slots(const struct glsl_type *type,
>> >>  bool is_vertex_input);
>> >>
>> >> --
>> >> 2.14.3
>> >>
>> >> ___
>> >> mesa-dev mailing list
>> >> mesa-dev@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >
>> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/1] radv/gfx9: fix texture buffer objects and image buffers with IDXEN==0

2018-02-28 Thread Samuel Pitoiset



On 02/28/2018 10:39 PM, Emil Velikov wrote:

Hi Samuel,

On 20 February 2018 at 11:33, Samuel Pitoiset  wrote:

Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
Cc: 
---
  src/amd/vulkan/radv_image.c | 35 ---
  1 file changed, 32 insertions(+), 3 deletions(-)


JFYI, seems like this patch hasn't landed in master, hence it won't
land in stable just yet.


Yes, no worries. We have a better fix in mind but it will take more time 
than expected.




-Emil


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


Re: [Mesa-dev] [PATCH v2] meson: fix LLVM version detection when <= 3.4

2018-02-28 Thread Dylan Baker
Quoting Andres Gomez (2018-02-28 13:15:07)
> 3 digits versions in LLVM only started from 3.4.1 on. Hence, if you
> have installed 3.4 or below, meson will fail even when we may not make
> use of LLVM.
> 
> v2: Properly compare LLVM version and set patch version to 0
> if < 3.4.1 (Eric).
> 
> Cc: Dylan Baker 
> Cc: Eric Engestrom 
> Signed-off-by: Andres Gomez 
> ---
>  meson.build | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 308f64cf811..e9928a37931 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1037,7 +1037,14 @@ if with_llvm
># that for our version checks.
># svn suffixes are stripped by meson as of 0.43, and git suffixes are
># strippped as of 0.44, but we support older meson versions.
> -  _llvm_patch = _llvm_version[2]
> +
> +  # 3 digits versions in LLVM only started from 3.4.1 on
> +  if dep_llvm.version().version_compare('>= 3.4.1')
> +_llvm_patch = _llvm_version[2]
> +  else
> +_llvm_patch = '0'
> +  endif
> +
>if _llvm_patch.endswith('svn')
>  _llvm_patch = _llvm_patch.split('s')[0]
>elif _llvm_patch.contains('git')
> -- 
> 2.15.1
> 

Reviewed-by: Dylan Baker 


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


Re: [Mesa-dev] [Mesa-stable] [PATCH 2/6] i965/miptree: Loosen the format check in miptree_match_image

2018-02-28 Thread Jason Ekstrand
On Wed, Feb 28, 2018 at 1:41 PM, Emil Velikov 
wrote:

> Hi Jason,
>
> On 24 January 2018 at 23:46, Jason Ekstrand  wrote:
> > This function is used to determine when we need to re-allocate a
> > miptree.  Since we do nothing different in miptree allocation for
> > sRGB vs. linear, loosening this should be safe and may lead to less
> > copying and reallocating in some odd cases.
> >
> > Reviewed-by: Kenneth Graunke 
> > Reviewed-by: Chad Versace 
> > Cc: "17.3" 
> > ---
> This and another two patches from the series have landed, with the
> stable nomination explicitly removed.
> This is a way to self-reject patches, as mentioned in the documentation.
>
> Let me know if that was a mistake and we want these in any of the
> stable branches.
>

Thanks for checking.  No, none of the 6 patches should go into stable.

--Jason


> 344b57b10b8 i965/miptree: Loosen the format check in miptree_match_image
> 41d45eb21e5 i965/tex_image: Pull the tex format from the renderbuffer
> in intelSetTexBuffer2
> 24952160fde i965: Use finish_external instead of make_shareable in
> setTexBuffer2
>
> Thanks
> Emil
>
> [1] https://www.mesa3d.org/submittingpatches.html#nominations
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Jason Ekstrand
I thought OpenCL used a different set of alignment rules for structs,
unions, etc.  In particular, I thought it was very close to standard C.  If
that's true, then std430 is not what you want.

On Wed, Feb 28, 2018 at 1:44 PM, Karol Herbst  wrote:

> it isn't yet. But you would use it in your driver when calculating
> your memory offsets for kernel arguments. In OpenCL things are aligned
> in memory by the size of the type and we would use those functions to
> calculate those.
>
> On Wed, Feb 28, 2018 at 10:39 PM, Jason Ekstrand 
> wrote:
> > Looking through commit titles, I don't see any obvious place where this
> > would get used.
> >
> > On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  src/compiler/nir_types.cpp | 12 
> >>  src/compiler/nir_types.h   |  4 
> >>  2 files changed, 16 insertions(+)
> >>
> >> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> >> index cbdd452dc81..0085a19248a 100644
> >> --- a/src/compiler/nir_types.cpp
> >> +++ b/src/compiler/nir_types.cpp
> >> @@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
> >> return type->arrays_of_arrays_size();
> >>  }
> >>
> >> +unsigned
> >> +glsl_std430_size(const struct glsl_type *type, bool row_major)
> >> +{
> >> +   return type->std430_size(row_major);
> >> +}
> >> +
> >> +unsigned
> >> +glsl_std430_base_alignment(const struct glsl_type *type, bool
> row_major)
> >> +{
> >> +   return type->std430_base_alignment(row_major);
> >> +}
> >> +
> >>  unsigned
> >>  glsl_count_attribute_slots(const struct glsl_type *type,
> >> bool is_vertex_input)
> >> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
> >> index e2dfd1ef5b7..5b5e09d137f 100644
> >> --- a/src/compiler/nir_types.h
> >> +++ b/src/compiler/nir_types.h
> >> @@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type
> *type);
> >>
> >>  unsigned glsl_get_aoa_size(const struct glsl_type *type);
> >>
> >> +unsigned glsl_std430_size(const struct glsl_type *type, bool
> row_major);
> >> +
> >> +unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool
> >> row_major);
> >> +
> >>  unsigned glsl_count_attribute_slots(const struct glsl_type *type,
> >>  bool is_vertex_input);
> >>
> >> --
> >> 2.14.3
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/4] intel: Split gen_device_info out into libintel_dev

2018-02-28 Thread Jordan Justen
On 2018-02-28 12:53:01, Francisco Jerez wrote:
> Jordan Justen  writes:
> 
> > On 2018-02-28 01:58:24, Samuel Iglesias Gonsálvez wrote:
> >> What is the idea for src/intel/dev/ ?
> >> 
> >> I'm not against this patch, just asking.
> >
> > Ken noticed a lot of duplicate lines in the xml for surface formats.
> > (Patch 4). But, then we noticed that removing them makes aubinator
> > fail to nicely print out the surface format name.
> >
> 
> Isn't it a bit of a misfeature for the surface formats not to be
> represented in the XML anymore?  Why should one need to depend on isl in
> order to decode a batchbuffer?

I think we've sort of decided to make isl the focus for surface
related info. It is also a lot of duplicated entries in the xml. (See
patch 4)

> > I thought maybe we could have isl help get the format name, but then
> > Jason pointed out that isl depends on intel/common (for device info),
> > so we couldn't make the decoder code in intel/common depend on isl.
> >
> 
> Did you consider splitting off the decoder code from common if it really
> needs to depend on isl?

I think we should try to keep isl having minimal dependencies. Rather
than isl depending on the common/kitchen-sink library, which is likely
to continue growing in scope, I thought it would be better to split
out the small item that it depends on.

I am also considering adding something else to intel/common in the
future, but that item would depend on isl, so once again raising the
issue.

-Jordan

> 
> > My idea is to split out the device info so isl wouldn't have to depend
> > on intel/common, and now it will depend on the newer intel/dev device
> > info lib. This should allow the decoder in intel/common to use isl,
> > and then we can remove the genxml duplication.
> >
> > -Jordan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Rob Clark
I needed it in ir3, since nir->ir3 is .c code, and I need it to map
load_param offset to offset in constant registers.  Sorry, I didn't
think the ir3 patches were interesting to others so I didn't include
them in the patchset.

Tbh if we used uniforms to pass params, I might not need these in ir3
(but otoh if I were writing the pass to lower load_param to
load_uniform I'd prefer to write it in .c ;-))

BR,
-R

On Wed, Feb 28, 2018 at 4:39 PM, Jason Ekstrand  wrote:
> Looking through commit titles, I don't see any obvious place where this
> would get used.
>
> On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/compiler/nir_types.cpp | 12 
>>  src/compiler/nir_types.h   |  4 
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
>> index cbdd452dc81..0085a19248a 100644
>> --- a/src/compiler/nir_types.cpp
>> +++ b/src/compiler/nir_types.cpp
>> @@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
>> return type->arrays_of_arrays_size();
>>  }
>>
>> +unsigned
>> +glsl_std430_size(const struct glsl_type *type, bool row_major)
>> +{
>> +   return type->std430_size(row_major);
>> +}
>> +
>> +unsigned
>> +glsl_std430_base_alignment(const struct glsl_type *type, bool row_major)
>> +{
>> +   return type->std430_base_alignment(row_major);
>> +}
>> +
>>  unsigned
>>  glsl_count_attribute_slots(const struct glsl_type *type,
>> bool is_vertex_input)
>> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
>> index e2dfd1ef5b7..5b5e09d137f 100644
>> --- a/src/compiler/nir_types.h
>> +++ b/src/compiler/nir_types.h
>> @@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type *type);
>>
>>  unsigned glsl_get_aoa_size(const struct glsl_type *type);
>>
>> +unsigned glsl_std430_size(const struct glsl_type *type, bool row_major);
>> +
>> +unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool
>> row_major);
>> +
>>  unsigned glsl_count_attribute_slots(const struct glsl_type *type,
>>  bool is_vertex_input);
>>
>> --
>> 2.14.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Karol Herbst
it isn't yet. But you would use it in your driver when calculating
your memory offsets for kernel arguments. In OpenCL things are aligned
in memory by the size of the type and we would use those functions to
calculate those.

On Wed, Feb 28, 2018 at 10:39 PM, Jason Ekstrand  wrote:
> Looking through commit titles, I don't see any obvious place where this
> would get used.
>
> On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/compiler/nir_types.cpp | 12 
>>  src/compiler/nir_types.h   |  4 
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
>> index cbdd452dc81..0085a19248a 100644
>> --- a/src/compiler/nir_types.cpp
>> +++ b/src/compiler/nir_types.cpp
>> @@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
>> return type->arrays_of_arrays_size();
>>  }
>>
>> +unsigned
>> +glsl_std430_size(const struct glsl_type *type, bool row_major)
>> +{
>> +   return type->std430_size(row_major);
>> +}
>> +
>> +unsigned
>> +glsl_std430_base_alignment(const struct glsl_type *type, bool row_major)
>> +{
>> +   return type->std430_base_alignment(row_major);
>> +}
>> +
>>  unsigned
>>  glsl_count_attribute_slots(const struct glsl_type *type,
>> bool is_vertex_input)
>> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
>> index e2dfd1ef5b7..5b5e09d137f 100644
>> --- a/src/compiler/nir_types.h
>> +++ b/src/compiler/nir_types.h
>> @@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type *type);
>>
>>  unsigned glsl_get_aoa_size(const struct glsl_type *type);
>>
>> +unsigned glsl_std430_size(const struct glsl_type *type, bool row_major);
>> +
>> +unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool
>> row_major);
>> +
>>  unsigned glsl_count_attribute_slots(const struct glsl_type *type,
>>  bool is_vertex_input);
>>
>> --
>> 2.14.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] intel/compiler: Memory fence commit must always be enabled for gen10+

2018-02-28 Thread Emil Velikov
On 22 February 2018 at 19:23, Emil Velikov  wrote:
> Hi Anuj,
>
> On 7 February 2018 at 01:09, Anuj Phogat  wrote:
>> Commit bit in the message descriptor (Bit 13) must be always set
>> to true in CNL+ for memory fence messages. It also fixes a piglit
>> GPU hang on cnl+ in simulation environment.
>> Piglit test: arb_shader_image_load_store-shader-mem-barrier
>> See HSD ES # 1404612949
>>
>> Signed-off-by: Anuj Phogat 
>> Cc: mesa-sta...@lists.freedesktop.org
>
> While patch 2/2 from the series was dropped/superseded, this one
> doesn't seem to have landed in master.
> Has it been superseded as well or simply fell through the cracks?
>
Anuj, Curro, friendly poke.

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


Re: [Mesa-dev] [Mesa-stable] [PATCH 2/6] i965/miptree: Loosen the format check in miptree_match_image

2018-02-28 Thread Emil Velikov
Hi Jason,

On 24 January 2018 at 23:46, Jason Ekstrand  wrote:
> This function is used to determine when we need to re-allocate a
> miptree.  Since we do nothing different in miptree allocation for
> sRGB vs. linear, loosening this should be safe and may lead to less
> copying and reallocating in some odd cases.
>
> Reviewed-by: Kenneth Graunke 
> Reviewed-by: Chad Versace 
> Cc: "17.3" 
> ---
This and another two patches from the series have landed, with the
stable nomination explicitly removed.
This is a way to self-reject patches, as mentioned in the documentation.

Let me know if that was a mistake and we want these in any of the
stable branches.

344b57b10b8 i965/miptree: Loosen the format check in miptree_match_image
41d45eb21e5 i965/tex_image: Pull the tex format from the renderbuffer
in intelSetTexBuffer2
24952160fde i965: Use finish_external instead of make_shareable in setTexBuffer2

Thanks
Emil

[1] https://www.mesa3d.org/submittingpatches.html#nominations
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/1] radv/gfx9: fix texture buffer objects and image buffers with IDXEN==0

2018-02-28 Thread Emil Velikov
Hi Samuel,

On 20 February 2018 at 11:33, Samuel Pitoiset  wrote:
> Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> Cc: 
> ---
>  src/amd/vulkan/radv_image.c | 35 ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
>
JFYI, seems like this patch hasn't landed in master, hence it won't
land in stable just yet.

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


Re: [Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Jason Ekstrand
Looking through commit titles, I don't see any obvious place where this
would get used.

On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:

> Signed-off-by: Rob Clark 
> ---
>  src/compiler/nir_types.cpp | 12 
>  src/compiler/nir_types.h   |  4 
>  2 files changed, 16 insertions(+)
>
> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> index cbdd452dc81..0085a19248a 100644
> --- a/src/compiler/nir_types.cpp
> +++ b/src/compiler/nir_types.cpp
> @@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
> return type->arrays_of_arrays_size();
>  }
>
> +unsigned
> +glsl_std430_size(const struct glsl_type *type, bool row_major)
> +{
> +   return type->std430_size(row_major);
> +}
> +
> +unsigned
> +glsl_std430_base_alignment(const struct glsl_type *type, bool row_major)
> +{
> +   return type->std430_base_alignment(row_major);
> +}
> +
>  unsigned
>  glsl_count_attribute_slots(const struct glsl_type *type,
> bool is_vertex_input)
> diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
> index e2dfd1ef5b7..5b5e09d137f 100644
> --- a/src/compiler/nir_types.h
> +++ b/src/compiler/nir_types.h
> @@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type *type);
>
>  unsigned glsl_get_aoa_size(const struct glsl_type *type);
>
> +unsigned glsl_std430_size(const struct glsl_type *type, bool row_major);
> +
> +unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool
> row_major);
> +
>  unsigned glsl_count_attribute_slots(const struct glsl_type *type,
>  bool is_vertex_input);
>
> --
> 2.14.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Jason Ekstrand
On Wed, Feb 28, 2018 at 1:35 PM, Rob Clark  wrote:

> On Wed, Feb 28, 2018 at 4:18 PM, Karol Herbst  wrote:
> > On Wed, Feb 28, 2018 at 9:46 PM, Jason Ekstrand 
> wrote:
> >> I do not think this patch does what you think it does.  The old opcode
> >> allowed you to shift any bit size integer by a 32-bit integer.  The new
> >> version allows you to shift N bits by N bits.  In particular, you can't
> >> shift a 16-bit by a 32-bit value.
> >>
> >> I'm not sure what the best thing is to do here.  Really, the size of
> src1
> >> doesn't really matter as 8-bit is enough to do any shifting needed for a
> >> 64-bit src0.  You can always compose with a u2u32 to get any src1 bit
> size
> >> you want.  We picked 32 because it's been the GL default for a long
> time.
> >>
> >
> > Well the thing is we ended up with a shift in spirv having two 64 bit
> > parameters. Maybe we could just put a convert in it for such cases?
> >
>
> yeah, I'd overlooked that this was only changing the 2nd src param..
> u2u32 for 2nd src would make sense
>

For now, that definitely works.


> (arguably we might only want to do that if the 2nd src is 64b, ie. if
> 2nd src is already 16b or 8b no sense to up-convert it to 32b)
>

Yeah, in future, it may help to add some shift variants which take a
smaller src1.


> I'll drop this and make a vtn patch to replace it.
>
> BR,
> -R
>
> >> On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark 
> wrote:
> >>>
> >>> From: Karol Herbst 
> >>>
> >>> This is a thing for OpenCL kernels.
> >>>
> >>> Signed-off-by: Rob Clark 
> >>> ---
> >>>  src/compiler/nir/nir_opcodes.py | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/src/compiler/nir/nir_opcodes.py
> >>> b/src/compiler/nir/nir_opcodes.py
> >>> index 278562b2bd1..c4d2c7805eb 100644
> >>> --- a/src/compiler/nir/nir_opcodes.py
> >>> +++ b/src/compiler/nir/nir_opcodes.py
> >>> @@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 ==
> src1) ?
> >>> 1.0f : 0.0f") # Set on Equ
> >>>  binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") #
> Set
> >>> on Not Equal
> >>>
> >>>
> >>> -opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
> >>> -opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
> >>> -opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
> >>> +opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
> >>> +opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
> >>> +opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
> >>>
> >>>  # bitwise logic operators
> >>>  #
> >>> --
> >>> 2.14.3
> >>>
> >>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 18.0] swr/rast: Fix index buffer overfetch issue for non-indexed draws

2018-02-28 Thread Emil Velikov
On 28 February 2018 at 19:16, George Kyriazis  wrote:
> Populate pLastIndex, even for the non-indexed case.  An zero pLastIndex
> can cause the index offsets inside the fetcher to have non-sensical values
> that can be either very large positive or very large negative numbers.
>
> Cherry-pick of 539de78633 for 18.0.  Surrounding context is different for
> 18.0 branch, hence the need for a separate patch.
>
> cc: "18.0" 

Tweaked the commit message a tiny bit and applied for the 18.0 branch.
Fix will feature in the next release.

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


Re: [Mesa-dev] [PATCH 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Jason Ekstrand
On Wed, Feb 28, 2018 at 1:18 PM, Karol Herbst  wrote:

> On Wed, Feb 28, 2018 at 9:46 PM, Jason Ekstrand 
> wrote:
> > I do not think this patch does what you think it does.  The old opcode
> > allowed you to shift any bit size integer by a 32-bit integer.  The new
> > version allows you to shift N bits by N bits.  In particular, you can't
> > shift a 16-bit by a 32-bit value.
> >
> > I'm not sure what the best thing is to do here.  Really, the size of src1
> > doesn't really matter as 8-bit is enough to do any shifting needed for a
> > 64-bit src0.  You can always compose with a u2u32 to get any src1 bit
> size
> > you want.  We picked 32 because it's been the GL default for a long time.
> >
>
> Well the thing is we ended up with a shift in spirv having two 64 bit
> parameters. Maybe we could just put a convert in it for such cases?
>

I think the quick, easy, and correct solution is to make spirv_to_nir
insert a u2u32 if src1 isn't a 32-bit type.

--Jason


> > On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
> >>
> >> From: Karol Herbst 
> >>
> >> This is a thing for OpenCL kernels.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  src/compiler/nir/nir_opcodes.py | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/compiler/nir/nir_opcodes.py
> >> b/src/compiler/nir/nir_opcodes.py
> >> index 278562b2bd1..c4d2c7805eb 100644
> >> --- a/src/compiler/nir/nir_opcodes.py
> >> +++ b/src/compiler/nir/nir_opcodes.py
> >> @@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 == src1)
> ?
> >> 1.0f : 0.0f") # Set on Equ
> >>  binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") #
> Set
> >> on Not Equal
> >>
> >>
> >> -opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
> >> -opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
> >> -opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
> >> +opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
> >> +opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
> >> +opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
> >>
> >>  # bitwise logic operators
> >>  #
> >> --
> >> 2.14.3
> >>
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Rob Clark
On Wed, Feb 28, 2018 at 4:18 PM, Karol Herbst  wrote:
> On Wed, Feb 28, 2018 at 9:46 PM, Jason Ekstrand  wrote:
>> I do not think this patch does what you think it does.  The old opcode
>> allowed you to shift any bit size integer by a 32-bit integer.  The new
>> version allows you to shift N bits by N bits.  In particular, you can't
>> shift a 16-bit by a 32-bit value.
>>
>> I'm not sure what the best thing is to do here.  Really, the size of src1
>> doesn't really matter as 8-bit is enough to do any shifting needed for a
>> 64-bit src0.  You can always compose with a u2u32 to get any src1 bit size
>> you want.  We picked 32 because it's been the GL default for a long time.
>>
>
> Well the thing is we ended up with a shift in spirv having two 64 bit
> parameters. Maybe we could just put a convert in it for such cases?
>

yeah, I'd overlooked that this was only changing the 2nd src param..
u2u32 for 2nd src would make sense

(arguably we might only want to do that if the 2nd src is 64b, ie. if
2nd src is already 16b or 8b no sense to up-convert it to 32b)

I'll drop this and make a vtn patch to replace it.

BR,
-R

>> On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
>>>
>>> From: Karol Herbst 
>>>
>>> This is a thing for OpenCL kernels.
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  src/compiler/nir/nir_opcodes.py | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/compiler/nir/nir_opcodes.py
>>> b/src/compiler/nir/nir_opcodes.py
>>> index 278562b2bd1..c4d2c7805eb 100644
>>> --- a/src/compiler/nir/nir_opcodes.py
>>> +++ b/src/compiler/nir/nir_opcodes.py
>>> @@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 == src1) ?
>>> 1.0f : 0.0f") # Set on Equ
>>>  binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") # Set
>>> on Not Equal
>>>
>>>
>>> -opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
>>> -opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
>>> -opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
>>> +opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
>>> +opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
>>> +opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
>>>
>>>  # bitwise logic operators
>>>  #
>>> --
>>> 2.14.3
>>>
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 12/13] compiler: int8/uint8 support

2018-02-28 Thread Jason Ekstrand
On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:

> From: Karol Herbst 
>
> OpenCL kernels also have int8/uint8.
>
> Signed-off-by: Rob Clark 
> ---
>  src/compiler/builtin_type_macros.h  | 10 
>  src/compiler/glsl/ast_to_hir.cpp|  2 ++
>  src/compiler/glsl/ir_clone.cpp  |  2 ++
>  src/compiler/glsl/link_uniform_initializers.cpp |  2 ++
>  src/compiler/glsl_types.cpp | 33
> +
>  src/compiler/glsl_types.h   |  4 +++
>  src/compiler/nir/nir.h  |  4 +++
>  src/compiler/nir/nir_search.c   |  2 ++
>  src/compiler/nir_types.cpp  | 12 +
>  src/compiler/nir_types.h|  6 +
>  src/compiler/spirv/spirv_to_nir.c   | 24 ++
>  src/compiler/spirv/vtn_variables.c  | 14 +++
>  src/intel/compiler/brw_fs.cpp   |  3 +++
>  src/intel/compiler/brw_shader.cpp   |  4 +++
>  src/intel/compiler/brw_vec4_visitor.cpp |  2 ++
>  src/mesa/program/ir_to_mesa.cpp |  4 +++
>  src/mesa/state_tracker/st_glsl_types.cpp|  2 ++
>  17 files changed, 130 insertions(+)
>
> diff --git a/src/compiler/builtin_type_macros.h
> b/src/compiler/builtin_type_macros.h
> index e3a1cd29c87..807691824d3 100644
> --- a/src/compiler/builtin_type_macros.h
> +++ b/src/compiler/builtin_type_macros.h
> @@ -114,6 +114,16 @@ DECL_TYPE(u16vec2,  GL_UNSIGNED_INT16_VEC2_NV,
> GLSL_TYPE_UINT16, 2, 1)
>  DECL_TYPE(u16vec3,  GL_UNSIGNED_INT16_VEC3_NV, GLSL_TYPE_UINT16, 3, 1)
>  DECL_TYPE(u16vec4,  GL_UNSIGNED_INT16_VEC4_NV, GLSL_TYPE_UINT16, 4, 1)
>
> +DECL_TYPE(int8_t,   GL_INT8_NV,  GLSL_TYPE_INT8, 1, 1)
> +DECL_TYPE(i8vec2,   GL_INT8_VEC2_NV, GLSL_TYPE_INT8, 2, 1)
> +DECL_TYPE(i8vec3,   GL_INT8_VEC3_NV, GLSL_TYPE_INT8, 3, 1)
> +DECL_TYPE(i8vec4,   GL_INT8_VEC4_NV, GLSL_TYPE_INT8, 4, 1)
> +
> +DECL_TYPE(uint8_t,  GL_UNSIGNED_INT8_NV,  GLSL_TYPE_UINT8, 1, 1)
> +DECL_TYPE(u8vec2,   GL_UNSIGNED_INT8_VEC2_NV, GLSL_TYPE_UINT8, 2, 1)
> +DECL_TYPE(u8vec3,   GL_UNSIGNED_INT8_VEC3_NV, GLSL_TYPE_UINT8, 3, 1)
> +DECL_TYPE(u8vec4,   GL_UNSIGNED_INT8_VEC4_NV, GLSL_TYPE_UINT8, 4, 1)
> +
>  DECL_TYPE(sampler,   GL_SAMPLER_1D,
>  GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_VOID)
>  DECL_TYPE(sampler1D, GL_SAMPLER_1D,
>  GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_FLOAT)
>  DECL_TYPE(sampler2D, GL_SAMPLER_2D,
>  GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_2D,   0, 0, GLSL_TYPE_FLOAT)
> diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_
> hir.cpp
> index 41e74815f31..815e571097c 100644
> --- a/src/compiler/glsl/ast_to_hir.cpp
> +++ b/src/compiler/glsl/ast_to_hir.cpp
> @@ -1117,6 +1117,8 @@ do_comparison(void *mem_ctx, int operation,
> ir_rvalue *op0, ir_rvalue *op1)
> case GLSL_TYPE_INT64:
> case GLSL_TYPE_UINT16:
> case GLSL_TYPE_INT16:
> +   case GLSL_TYPE_UINT8:
> +   case GLSL_TYPE_INT8:
>return new(mem_ctx) ir_expression(operation, op0, op1);
>
> case GLSL_TYPE_ARRAY: {
> diff --git a/src/compiler/glsl/ir_clone.cpp b/src/compiler/glsl/ir_clone.
> cpp
> index f088b6aebd5..69441fae7de 100644
> --- a/src/compiler/glsl/ir_clone.cpp
> +++ b/src/compiler/glsl/ir_clone.cpp
> @@ -344,6 +344,8 @@ ir_constant::clone(void *mem_ctx, struct hash_table
> *ht) const
> case GLSL_TYPE_INT64:
> case GLSL_TYPE_UINT16:
> case GLSL_TYPE_INT16:
> +   case GLSL_TYPE_UINT8:
> +   case GLSL_TYPE_INT8:
> case GLSL_TYPE_SAMPLER:
> case GLSL_TYPE_IMAGE:
>return new(mem_ctx) ir_constant(this->type, >value);
> diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
> b/src/compiler/glsl/link_uniform_initializers.cpp
> index 35522f76467..d6d63bd61fc 100644
> --- a/src/compiler/glsl/link_uniform_initializers.cpp
> +++ b/src/compiler/glsl/link_uniform_initializers.cpp
> @@ -83,6 +83,8 @@ copy_constant_to_storage(union gl_constant_value
> *storage,
>case GLSL_TYPE_ERROR:
>case GLSL_TYPE_UINT16:
>case GLSL_TYPE_INT16:
> +  case GLSL_TYPE_UINT8:
> +  case GLSL_TYPE_INT8:
>case GLSL_TYPE_FLOAT16:
>   /* All other types should have already been filtered by other
>* paths in the caller.
> diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
> index 3cc5eb0495c..b1438300746 100644
> --- a/src/compiler/glsl_types.cpp
> +++ b/src/compiler/glsl_types.cpp
> @@ -623,6 +623,31 @@ glsl_type::u16vec(unsigned components)
> return ts[components - 1];
>  }
>
> +const glsl_type *
> +glsl_type::i8vec(unsigned components)
> +{
> +   if (components == 0 || components > 4)
> +  return error_type;
> +
> +   static const glsl_type *const ts[] = {
> +  int8_t_type, i8vec2_type, i8vec3_type, i8vec4_type
> +   };
> +   return ts[components - 1];
> 

Re: [Mesa-dev] [PATCH 02/13] nir: add load_param

2018-02-28 Thread Rob Clark
On Wed, Feb 28, 2018 at 4:16 PM, Eric Anholt  wrote:
> Rob Clark  writes:
>
>> From: Karol Herbst 
>>
>> OpenCL kernels have parameters (see pipe_grid_info::input), and so we
>> need a way to access them.
>>
>> Signed-off-by: Rob Clark 
>>
>> ---
>>  src/compiler/nir/nir_intrinsics.h |  2 ++
>>  src/compiler/nir/nir_lower_io.c   | 13 ++---
>>  2 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compiler/nir/nir_intrinsics.h 
>> b/src/compiler/nir/nir_intrinsics.h
>> index ede29277876..0915c5e809f 100644
>> --- a/src/compiler/nir/nir_intrinsics.h
>> +++ b/src/compiler/nir/nir_intrinsics.h
>> @@ -435,6 +435,8 @@ LOAD(ubo, 2, 0, xx, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE 
>> | NIR_INTRINSIC_CAN_REOR
>>  LOAD(input, 1, 2, BASE, COMPONENT, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
>> NIR_INTRINSIC_CAN_REORDER)
>>  /* src[] = { vertex, offset }. const_index[] = { base, component } */
>>  LOAD(per_vertex_input, 2, 2, BASE, COMPONENT, xx, 
>> NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
>> +/* src[] = { }. const_index[] = { base } */
>> +LOAD(param, 0, 1, BASE, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
>> NIR_INTRINSIC_CAN_REORDER)
>
> I know this is a new request compared to the existing pattern, but could
> you put a comment describing what load_param does in the code as well as
> the commit message?  Especially what the meaning of the base is.  We've
> been bad at this in NIR, and it makes learning how to write a new NIR
> backend more challenging than it should be.
>
> Also, what makes these params different from UBOs or default uniforms?

yeah, I guess makes sense to describe better in code.. but for now
base is just the parameter number (ie. first param base=0, second
param base=1, etc)

For ir3, I end up uploading these as uniforms.. I'm not sure how nv
does kernel params offhand.  Maybe if they just end up uniforms for
everyone we can change clover to use ctx->set_constant_buffer() and
use a pass to lower load_param to load_uniform.  At least that would
solve one awkward thing about the pipe driver and clover agreeing on
the layout of pipe_grid_info::input.

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


[Mesa-dev] [PATCH v2] travis: make Meson find the proper llvm-config

2018-02-28 Thread Andres Gomez
Travis CI has moved to LLVM 5.0, and meson is detecting automatically
the available version in /usr/local/bin based on the PATH env variable
order preference.

As for 0.44.x, Meson cannot receive the path to the llvm-config binary
as a configuration parameter. See
https://github.com/mesonbuild/meson/issues/2887 and
https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a77eca3f1bcef

We want to use the custom (APT) installed version. Therefore, let's
make Meson find our wanted version sooner than the one at
/usr/local/bin

Once this is corrected, we would still need a patch similar to:
https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html

v2: Create the link only to the specificly wanted LLVM version (Gert).

Cc: Eric Engestrom 
Cc: Dylan Baker 
Cc: Emil Velikov 
Cc: Juan A. Suarez Romero 
Cc: Gert Wollny 
Cc: Jon Turney 
Signed-off-by: Andres Gomez 
Reviewed-and-Tested-by: Eric Engestrom 
Reviewed-by: Dylan Baker 
Reviewed-by: Juan A. Suarez 
---
 .travis.yml | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 0ec08e5bff7..823111ca539 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -34,6 +34,8 @@ matrix:
 - LABEL="meson Vulkan"
 - BUILD=meson
 - MESON_OPTIONS="-Ddri-drivers= -Dgallium-drivers="
+- LLVM_VERSION=4.0
+- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
   addons:
 apt:
   sources:
@@ -573,8 +575,28 @@ script:
   scons $SCONS_TARGET && eval $SCONS_CHECK_COMMAND;
 fi
 
-  - if test "x$BUILD" = xmeson; then
-  export CFLAGS="$CFLAGS -isystem`pwd`";
-  meson _build $MESON_OPTIONS;
-  ninja -C _build;
+  - |
+if test "x$BUILD" = xmeson; then
+
+  # Travis CI has moved to LLVM 5.0, and meson is detecting
+  # automatically the available version in /usr/local/bin based on
+  # the PATH env variable order preference.
+  #
+  # As for 0.44.x, Meson cannot receive the path to the
+  # llvm-config binary as a configuration parameter. See
+  # https://github.com/mesonbuild/meson/issues/2887 and
+  # 
https://github.com/dcbaker/meson/commit/7c8b6ee3fa42f43c9ac7dcacc61a77eca3f1bcef
+  #
+  # We want to use the custom (APT) installed version. Therefore,
+  # let's make Meson find our wanted version sooner than the one
+  # at /usr/local/bin
+  #
+  # Once this is corrected, we would still need a patch similar
+  # to:
+  # 
https://lists.freedesktop.org/archives/mesa-dev/2017-December/180217.html
+  test -f /usr/bin/$LLVM_CONFIG && ln -s /usr/bin/$LLVM_CONFIG 
$HOME/prefix/bin/llvm-config
+
+  export CFLAGS="$CFLAGS -isystem`pwd`"
+  meson _build $MESON_OPTIONS
+  ninja -C _build
 fi
-- 
2.15.1

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


[Mesa-dev] [PATCH] nir/search: Support 8 and 16-bit constants

2018-02-28 Thread Jason Ekstrand
---
 src/compiler/nir/nir_search.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/src/compiler/nir/nir_search.c b/src/compiler/nir/nir_search.c
index dec56fe..c7c52ae 100644
--- a/src/compiler/nir/nir_search.c
+++ b/src/compiler/nir/nir_search.c
@@ -27,6 +27,7 @@
 
 #include 
 #include "nir_search.h"
+#include "util/half_float.h"
 
 struct match_state {
bool inexact_match;
@@ -194,6 +195,9 @@ match_value(const nir_search_value *value, nir_alu_instr 
*instr, unsigned src,
  for (unsigned i = 0; i < num_components; ++i) {
 double val;
 switch (load->def.bit_size) {
+case 16:
+   val = _mesa_half_to_float(load->value.u16[new_swizzle[i]]);
+   break;
 case 32:
val = load->value.f32[new_swizzle[i]];
break;
@@ -213,6 +217,22 @@ match_value(const nir_search_value *value, nir_alu_instr 
*instr, unsigned src,
   case nir_type_uint:
   case nir_type_bool32:
  switch (load->def.bit_size) {
+ case 8:
+for (unsigned i = 0; i < num_components; ++i) {
+   if (load->value.u8[new_swizzle[i]] !=
+   (uint8_t)const_val->data.u)
+  return false;
+}
+return true;
+
+ case 16:
+for (unsigned i = 0; i < num_components; ++i) {
+   if (load->value.u16[new_swizzle[i]] !=
+   (uint16_t)const_val->data.u)
+  return false;
+}
+return true;
+
  case 32:
 for (unsigned i = 0; i < num_components; ++i) {
if (load->value.u32[new_swizzle[i]] !=
-- 
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 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Karol Herbst
On Wed, Feb 28, 2018 at 9:46 PM, Jason Ekstrand  wrote:
> I do not think this patch does what you think it does.  The old opcode
> allowed you to shift any bit size integer by a 32-bit integer.  The new
> version allows you to shift N bits by N bits.  In particular, you can't
> shift a 16-bit by a 32-bit value.
>
> I'm not sure what the best thing is to do here.  Really, the size of src1
> doesn't really matter as 8-bit is enough to do any shifting needed for a
> 64-bit src0.  You can always compose with a u2u32 to get any src1 bit size
> you want.  We picked 32 because it's been the GL default for a long time.
>

Well the thing is we ended up with a shift in spirv having two 64 bit
parameters. Maybe we could just put a convert in it for such cases?

> On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:
>>
>> From: Karol Herbst 
>>
>> This is a thing for OpenCL kernels.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  src/compiler/nir/nir_opcodes.py | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/compiler/nir/nir_opcodes.py
>> b/src/compiler/nir/nir_opcodes.py
>> index 278562b2bd1..c4d2c7805eb 100644
>> --- a/src/compiler/nir/nir_opcodes.py
>> +++ b/src/compiler/nir/nir_opcodes.py
>> @@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 == src1) ?
>> 1.0f : 0.0f") # Set on Equ
>>  binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") # Set
>> on Not Equal
>>
>>
>> -opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
>> -opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
>> -opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
>> +opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
>> +opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
>> +opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
>>
>>  # bitwise logic operators
>>  #
>> --
>> 2.14.3
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Rob Clark
On Wed, Feb 28, 2018 at 4:09 PM, Eric Anholt  wrote:
> Matt Turner  writes:
>
>> I find this script *really* annoying. Getting Cc'd on a random sample of
>> a series is doing it wrong. Cc lists of 14 people is doing it wrong.
>>
>> Let's start the negotiation with "delete this script" and see if anyone
>> can come up with a way of making this not so stupid.
>
> Patch submission done well IMO would be something like github PRs, with
> a bot that auto-tags people based on a MAINTAINERS-style opt-in for
> reviewing certain paths within the tree.
>
> I don't think get_reviewers.pl improves the git-send-email situation
> compared to maintainers needing to manage email filters.  It's not
> consistent, so you need to indoctrinate new submitters (more barriers to
> entry!) and maintainers need to maintain their mail filters anyway.

Hmm, you have mail filters that parse paths in git patches?

Possibly tweaking the script to *only* consult MAINTAINERS file, as
Dylan suggested, would be a reasonable solution.

As far as indoctrinating new submitters, well it is the same as the
kernel process so it seemed natural to me, but I guess it depends on
what other projects a submitter contributes to..

BR,
-R


> Reviewed-by: Eric Anholt 
>
> ___
> 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 2/2] meson: Fix building gallium media libs without egl

2018-02-28 Thread Dylan Baker
Signed-off-by: Dylan Baker 
---
 meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 7cfd7f2183a..c565a81fe95 100644
--- a/meson.build
+++ b/meson.build
@@ -1188,7 +1188,8 @@ if with_platform_x11
 endif
 dep_glproto = dependency('glproto', version : '>= 1.4.14')
   endif
-  if with_egl
+  if with_egl or (with_gallium_vdpau or with_gallium_xvmc or with_gallium_omx 
or
+  with_gallium_xa)
 dep_xcb_xfixes = dependency('xcb-xfixes')
   endif
 endif
-- 
2.16.2

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


[Mesa-dev] [PATCH 1/2] meson: Allow building dri based EGL without GLX

2018-02-28 Thread Dylan Baker
It should be possible to build EGL without GLX, but the meson build
currently doesn't allow that because it too tightly couples glx and dri.
This patch eases dri and glx apart, so that EGL without GLX can be
built.

CC: Daniel Stone 
Signed-off-by: Dylan Baker 
---
 meson.build | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/meson.build b/meson.build
index 308f64cf811..7cfd7f2183a 100644
--- a/meson.build
+++ b/meson.build
@@ -1,4 +1,4 @@
-# Copyright © 2017 Intel Corporation
+# Copyright © 2017-2018 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
@@ -29,6 +29,8 @@ project(
   default_options : ['buildtype=debugoptimized', 'c_std=c99', 'cpp_std=c++11']
 )
 
+system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
+
 # Arguments for the preprocessor, put these in a separate array from the C and
 # C++ (cpp in meson terminology) arguments since they need to be added to the
 # default arguments for both C and C++.
@@ -172,6 +174,13 @@ if _drivers != ''
   with_gallium_virgl = _split.contains('virgl')
   with_gallium_swr = _split.contains('swr')
   with_gallium = true
+  if system_has_kms_drm
+_glx = get_option('glx')
+_egl = get_option('egl')
+if _glx == 'dri' or _egl == 'true' or (_glx == 'disabled' and _egl != 
'false')
+  with_dri = true
+endif
+  endif
 endif
 
 with_intel_vk = false
@@ -217,8 +226,6 @@ if with_dri_i915 or with_gallium_i915
   dep_libdrm_intel = dependency('libdrm_intel', version : '>= 2.4.75')
 endif
 
-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
-
 if host_machine.system() == 'darwin'
   with_dri_platform = 'apple'
 elif ['windows', 'cygwin'].contains(host_machine.system())
@@ -272,6 +279,7 @@ if with_glx == 'auto'
   elif with_gallium
 # Even when building just gallium drivers the user probably wants dri
 with_glx = 'dri'
+with_dri = true
   elif with_platform_x11 and with_any_opengl and not with_any_vk
 # The automatic behavior should not be to turn on xlib based glx when
 # building only vulkan drivers
@@ -280,11 +288,6 @@ if with_glx == 'auto'
 with_glx = 'disabled'
   endif
 endif
-if with_glx == 'dri'
-   if with_gallium
-  with_dri = true
-   endif
-endif
 
 if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
'gallium-xlib')
   with_gles1 = false
@@ -314,6 +317,8 @@ elif _egl == 'true'
 error('EGL requires shared-glapi')
   elif egl_native_platform == ''
 error('No platforms specified, consider -Dplatforms=drm,x11 at least')
+  elif not ['disabled', 'dri'].contains(with_glx)
+error('EGL requires dri, but a GLX is being built without dri')
   endif
   with_egl = true
 else
@@ -604,7 +609,7 @@ endif
 
 gl_pkgconfig_c_flags = []
 if with_platform_x11
-  if with_any_vk or (with_glx == 'dri' and with_dri_platform == 'drm')
+  if with_any_vk or with_egl or (with_glx == 'dri' and with_dri_platform == 
'drm')
 pre_args += '-DHAVE_X11_PLATFORM'
   endif
   if with_glx == 'xlib' or with_glx == 'gallium-xlib'
@@ -1166,7 +1171,7 @@ if with_platform_x11
 dep_xcb = dependency('xcb')
 dep_x11_xcb = dependency('x11-xcb')
   endif
-  if with_any_vk or (with_glx == 'dri' and with_dri_platform == 'drm')
+  if with_any_vk or with_egl or (with_glx == 'dri' and with_dri_platform == 
'drm')
 dep_xcb_dri2 = dependency('xcb-dri2', version : '>= 1.8')
 
 if with_dri3
-- 
2.16.2

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


Re: [Mesa-dev] [PATCH 02/13] nir: add load_param

2018-02-28 Thread Eric Anholt
Rob Clark  writes:

> From: Karol Herbst 
>
> OpenCL kernels have parameters (see pipe_grid_info::input), and so we
> need a way to access them.
>
> Signed-off-by: Rob Clark 
>
> ---
>  src/compiler/nir/nir_intrinsics.h |  2 ++
>  src/compiler/nir/nir_lower_io.c   | 13 ++---
>  2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_intrinsics.h 
> b/src/compiler/nir/nir_intrinsics.h
> index ede29277876..0915c5e809f 100644
> --- a/src/compiler/nir/nir_intrinsics.h
> +++ b/src/compiler/nir/nir_intrinsics.h
> @@ -435,6 +435,8 @@ LOAD(ubo, 2, 0, xx, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
> NIR_INTRINSIC_CAN_REOR
>  LOAD(input, 1, 2, BASE, COMPONENT, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
> NIR_INTRINSIC_CAN_REORDER)
>  /* src[] = { vertex, offset }. const_index[] = { base, component } */
>  LOAD(per_vertex_input, 2, 2, BASE, COMPONENT, xx, 
> NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
> +/* src[] = { }. const_index[] = { base } */
> +LOAD(param, 0, 1, BASE, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
> NIR_INTRINSIC_CAN_REORDER)

I know this is a new request compared to the existing pattern, but could
you put a comment describing what load_param does in the code as well as
the commit message?  Especially what the meaning of the base is.  We've
been bad at this in NIR, and it makes learning how to write a new NIR
backend more challenging than it should be.

Also, what makes these params different from UBOs or default uniforms?


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


[Mesa-dev] [PATCH v2] meson: fix LLVM version detection when <= 3.4

2018-02-28 Thread Andres Gomez
3 digits versions in LLVM only started from 3.4.1 on. Hence, if you
have installed 3.4 or below, meson will fail even when we may not make
use of LLVM.

v2: Properly compare LLVM version and set patch version to 0
if < 3.4.1 (Eric).

Cc: Dylan Baker 
Cc: Eric Engestrom 
Signed-off-by: Andres Gomez 
---
 meson.build | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 308f64cf811..e9928a37931 100644
--- a/meson.build
+++ b/meson.build
@@ -1037,7 +1037,14 @@ if with_llvm
   # that for our version checks.
   # svn suffixes are stripped by meson as of 0.43, and git suffixes are
   # strippped as of 0.44, but we support older meson versions.
-  _llvm_patch = _llvm_version[2]
+
+  # 3 digits versions in LLVM only started from 3.4.1 on
+  if dep_llvm.version().version_compare('>= 3.4.1')
+_llvm_patch = _llvm_version[2]
+  else
+_llvm_patch = '0'
+  endif
+
   if _llvm_patch.endswith('svn')
 _llvm_patch = _llvm_patch.split('s')[0]
   elif _llvm_patch.contains('git')
-- 
2.15.1

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


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Dylan Baker
Quoting Dylan Baker (2018-02-28 13:02:02)
> Quoting Rob Clark (2018-02-28 12:54:28)
> > On Wed, Feb 28, 2018 at 3:25 PM, Matt Turner  wrote:
> > > I find this script *really* annoying. Getting Cc'd on a random sample of
> > > a series is doing it wrong. Cc lists of 14 people is doing it wrong.
> > >
> > > Let's start the negotiation with "delete this script" and see if anyone
> > > can come up with a way of making this not so stupid.
> > 
> > tbh, if it were better about about not adding people to CC list just
> > because they had some commits around the effected code, I think that
> > would be better.  Better populating of REVIEWERS and higher weight to
> > REVIEWERS over git-blame would help, I think.  (It would be nice if it
> > wasn't a perl script, or at least that would make it easier for me to
> > fix that..)
> > 
> > As far as being CC'd on part of a patchset vs whole patchset, I'm not
> > really sure how to do that w/ git's cc-cmd.  I admit it would be nice
> > if it at least CC'd everyone on the cover letter for context, although
> > for a patchset that touched a lot of areas I think I'd prefer just to
> > be CC'd on cover letter plus individual patches.  I guess if there was
> > a way for letting get_reviewers script see the whole patchset upfront,
> > then inventing a way to get individual preferences about being cc'd on
> > whole patchset vs cover letters and individual patches would be an
> > option.
> > 
> > I do still like the general concept, to make it easier for the right
> > people to be CC'd on a patch, especially for drive-by submitters.
> > 
> > BR,
> > -R
> > 
> 
> What problem is this script trying to solve? Getting someone to look at 
> patches?
> Figuring out who's code you're fixing? Having someone generally knowledgeable
> about a specific area of mesa look at your code?
> 
> I don't think this script really does a good job at any of those. The last can
> be solved better by just looking at the REVIEWERS file I think (I'm not 
> opposed
> to a script that just looks at the REVIEWERS file). I don't think that the
> second problem is generally scriptable, and the first (if it's a problem) is a
> culture problem and can't be solved by technical means.
> 
> Dylan
> 

I meant to add, for wholesale deletion:
Reviewed-by: Dylan Baker 


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


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Eric Anholt
Matt Turner  writes:

> I find this script *really* annoying. Getting Cc'd on a random sample of
> a series is doing it wrong. Cc lists of 14 people is doing it wrong.
>
> Let's start the negotiation with "delete this script" and see if anyone
> can come up with a way of making this not so stupid.

Patch submission done well IMO would be something like github PRs, with
a bot that auto-tags people based on a MAINTAINERS-style opt-in for
reviewing certain paths within the tree.

I don't think get_reviewers.pl improves the git-send-email situation
compared to maintainers needing to manage email filters.  It's not
consistent, so you need to indoctrinate new submitters (more barriers to
entry!) and maintainers need to maintain their mail filters anyway.

Reviewed-by: Eric Anholt 


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] intel: Split gen_device_info out into libintel_dev

2018-02-28 Thread Francisco Jerez
Jordan Justen  writes:

> On 2018-02-28 01:58:24, Samuel Iglesias Gonsálvez wrote:
>> What is the idea for src/intel/dev/ ?
>> 
>> I'm not against this patch, just asking.
>
> Ken noticed a lot of duplicate lines in the xml for surface formats.
> (Patch 4). But, then we noticed that removing them makes aubinator
> fail to nicely print out the surface format name.
>

Isn't it a bit of a misfeature for the surface formats not to be
represented in the XML anymore?  Why should one need to depend on isl in
order to decode a batchbuffer?

> I thought maybe we could have isl help get the format name, but then
> Jason pointed out that isl depends on intel/common (for device info),
> so we couldn't make the decoder code in intel/common depend on isl.
>

Did you consider splitting off the decoder code from common if it really
needs to depend on isl?

> My idea is to split out the device info so isl wouldn't have to depend
> on intel/common, and now it will depend on the newer intel/dev device
> info lib. This should allow the decoder in intel/common to use isl,
> and then we can remove the genxml duplication.
>
> -Jordan
>
>> Patches 2-4 are,
>> 
>> Reviewed-by: Samuel Iglesias Gonsálvez 
>> 
>> Sam
>> 
>> 
>> On 27/02/18 21:32, Jordan Justen wrote:
>> > Signed-off-by: Jordan Justen 
>> > ---
>> >  src/intel/Android.dev.mk   | 35 
>> > ++
>> >  src/intel/Makefile.am  |  1 +
>> >  src/intel/Makefile.dev.am  | 31 
>> > +++
>> >  src/intel/Makefile.isl.am  |  2 +-
>> >  src/intel/Makefile.sources |  6 ++--
>> >  src/intel/Makefile.tools.am|  4 +++
>> >  src/intel/Makefile.vulkan.am   |  1 +
>> >  src/intel/blorp/blorp_genX_exec.h  |  2 +-
>> >  src/intel/common/gen_decoder.h |  2 +-
>> >  src/intel/common/gen_l3_config.h   |  2 +-
>> >  src/intel/common/meson.build   |  2 --
>> >  src/intel/compiler/brw_compiler.h  |  2 +-
>> >  src/intel/compiler/brw_inst.h  |  2 +-
>> >  src/intel/compiler/brw_reg_type.c  |  2 +-
>> >  src/intel/{common => dev}/gen_device_info.c|  0
>> >  src/intel/{common => dev}/gen_device_info.h|  0
>> >  src/intel/dev/meson.build  | 33 
>> > 
>> >  src/intel/genxml/gen_bits_header.py|  2 +-
>> >  src/intel/isl/isl_drm.c|  2 +-
>> >  src/intel/isl/isl_format.c |  2 +-
>> >  src/intel/isl/isl_priv.h   |  2 +-
>> >  src/intel/isl/meson.build  |  2 +-
>> >  .../isl/tests/isl_surf_get_image_offset_test.c |  2 +-
>> >  src/intel/meson.build  |  1 +
>> >  src/intel/tools/gen_disasm.h   |  2 +-
>> >  src/intel/tools/meson.build|  4 +--
>> >  src/intel/vulkan/anv_private.h |  2 +-
>> >  src/intel/vulkan/meson.build   |  8 ++---
>> >  src/mesa/drivers/dri/i965/Makefile.am  |  1 +
>> >  src/mesa/drivers/dri/i965/brw_bufmgr.c |  2 +-
>> >  src/mesa/drivers/dri/i965/genX_state_upload.c  |  2 +-
>> >  src/mesa/drivers/dri/i965/intel_screen.h   |  2 +-
>> >  src/mesa/drivers/dri/i965/meson.build  |  3 +-
>> >  33 files changed, 137 insertions(+), 29 deletions(-)
>> >  create mode 100644 src/intel/Android.dev.mk
>> >  create mode 100644 src/intel/Makefile.dev.am
>> >  rename src/intel/{common => dev}/gen_device_info.c (100%)
>> >  rename src/intel/{common => dev}/gen_device_info.h (100%)
>> >  create mode 100644 src/intel/dev/meson.build
>> >
>> > diff --git a/src/intel/Android.dev.mk b/src/intel/Android.dev.mk
>> > new file mode 100644
>> > index 000..956f32c119f
>> > --- /dev/null
>> > +++ b/src/intel/Android.dev.mk
>> > @@ -0,0 +1,35 @@
>> > +# Copyright © 2016 Intel Corporation
>> > +# Copyright © 2016 Mauro Rossi 
>> > +#
>> > +# 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 shall be included
>> > +# in all copies or substantial portions of the Software.
>> > +#
>> > +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> > 

Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Dylan Baker
Quoting Rob Clark (2018-02-28 12:54:28)
> On Wed, Feb 28, 2018 at 3:25 PM, Matt Turner  wrote:
> > I find this script *really* annoying. Getting Cc'd on a random sample of
> > a series is doing it wrong. Cc lists of 14 people is doing it wrong.
> >
> > Let's start the negotiation with "delete this script" and see if anyone
> > can come up with a way of making this not so stupid.
> 
> tbh, if it were better about about not adding people to CC list just
> because they had some commits around the effected code, I think that
> would be better.  Better populating of REVIEWERS and higher weight to
> REVIEWERS over git-blame would help, I think.  (It would be nice if it
> wasn't a perl script, or at least that would make it easier for me to
> fix that..)
> 
> As far as being CC'd on part of a patchset vs whole patchset, I'm not
> really sure how to do that w/ git's cc-cmd.  I admit it would be nice
> if it at least CC'd everyone on the cover letter for context, although
> for a patchset that touched a lot of areas I think I'd prefer just to
> be CC'd on cover letter plus individual patches.  I guess if there was
> a way for letting get_reviewers script see the whole patchset upfront,
> then inventing a way to get individual preferences about being cc'd on
> whole patchset vs cover letters and individual patches would be an
> option.
> 
> I do still like the general concept, to make it easier for the right
> people to be CC'd on a patch, especially for drive-by submitters.
> 
> BR,
> -R
> 

What problem is this script trying to solve? Getting someone to look at patches?
Figuring out who's code you're fixing? Having someone generally knowledgeable
about a specific area of mesa look at your code?

I don't think this script really does a good job at any of those. The last can
be solved better by just looking at the REVIEWERS file I think (I'm not opposed
to a script that just looks at the REVIEWERS file). I don't think that the
second problem is generally scriptable, and the first (if it's a problem) is a
culture problem and can't be solved by technical means.

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 18.0] swr/rast: Fix index buffer overfetch issue for non-indexed draws

2018-02-28 Thread Cherniak, Bruce
Reviewed-by: Bruce Cherniak  

> On Feb 28, 2018, at 1:16 PM, George Kyriazis  
> wrote:
> 
> Populate pLastIndex, even for the non-indexed case.  An zero pLastIndex
> can cause the index offsets inside the fetcher to have non-sensical values
> that can be either very large positive or very large negative numbers.
> 
> Cherry-pick of 539de78633 for 18.0.  Surrounding context is different for
> 18.0 branch, hence the need for a separate patch.
> 
> cc: "18.0" 
> ---
> src/gallium/drivers/swr/rasterizer/core/frontend.cpp | 15 +++
> 1 file changed, 15 insertions(+)
> 
> diff --git a/src/gallium/drivers/swr/rasterizer/core/frontend.cpp 
> b/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
> index 9600f78..ce6cb68 100644
> --- a/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
> +++ b/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
> @@ -1724,6 +1724,21 @@ void ProcessDraw(
> 
> if (i < endVertex)
> {
> +if (!IsIndexedT::value)
> +{
> +fetchInfo_lo.pLastIndex = fetchInfo_lo.pIndices;
> +uint32_t offset;
> +offset = std::min(endVertex-i, (uint32_t) 
> KNOB_SIMD16_WIDTH);
> +#if USE_SIMD16_SHADERS
> +fetchInfo_lo.pLastIndex += offset;
> +#else
> +fetchInfo_lo.pLastIndex += std::min(offset, (uint32_t) 
> KNOB_SIMD_WIDTH);
> +uint32_t offset2 = std::min(offset, (uint32_t) 
> KNOB_SIMD16_WIDTH)-KNOB_SIMD_WIDTH;
> +assert(offset >= 0);
> +fetchInfo_hi.pLastIndex = fetchInfo_hi.pIndices;
> +fetchInfo_hi.pLastIndex += offset2;
> +#endif
> +}
> // 1. Execute FS/VS for a single SIMD.
> AR_BEGIN(FEFetchShader, pDC->drawId);
> #if USE_SIMD16_SHADERS
> -- 
> 2.7.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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


Re: [Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Rob Clark
On Wed, Feb 28, 2018 at 3:25 PM, Matt Turner  wrote:
> I find this script *really* annoying. Getting Cc'd on a random sample of
> a series is doing it wrong. Cc lists of 14 people is doing it wrong.
>
> Let's start the negotiation with "delete this script" and see if anyone
> can come up with a way of making this not so stupid.

tbh, if it were better about about not adding people to CC list just
because they had some commits around the effected code, I think that
would be better.  Better populating of REVIEWERS and higher weight to
REVIEWERS over git-blame would help, I think.  (It would be nice if it
wasn't a perl script, or at least that would make it easier for me to
fix that..)

As far as being CC'd on part of a patchset vs whole patchset, I'm not
really sure how to do that w/ git's cc-cmd.  I admit it would be nice
if it at least CC'd everyone on the cover letter for context, although
for a patchset that touched a lot of areas I think I'd prefer just to
be CC'd on cover letter plus individual patches.  I guess if there was
a way for letting get_reviewers script see the whole patchset upfront,
then inventing a way to get individual preferences about being cc'd on
whole patchset vs cover letters and individual patches would be an
option.

I do still like the general concept, to make it easier for the right
people to be CC'd on a patch, especially for drive-by submitters.

BR,
-R

> ---
>  scripts/get_reviewer.pl | 2301 
> ---
>  1 file changed, 2301 deletions(-)
>  delete mode 100755 scripts/get_reviewer.pl
>
> diff --git a/scripts/get_reviewer.pl b/scripts/get_reviewer.pl
> deleted file mode 100755
> index 62deb922800..000
> --- a/scripts/get_reviewer.pl
> +++ /dev/null
> @@ -1,2301 +0,0 @@
> -#!/usr/bin/perl -w
> -# (c) 2007, Joe Perches 
> -#   created from checkpatch.pl
> -#
> -# Print selected REVIEWERS information for
> -# the files modified in a patch or for a file
> -#
> -# usage: perl scripts/get_reviewer.pl [OPTIONS] 
> -#perl scripts/get_reviewer.pl [OPTIONS] -f 
> -#
> -# A minimally modified version of get_maintainer.pl from the
> -# Linux source tree, adapted for use in mesa.
> -#
> -# Licensed under the terms of the GNU GPL License version 2
> -
> -use strict;
> -
> -my $P = $0;
> -my $V = '0.26';
> -
> -use Getopt::Long qw(:config no_auto_abbrev);
> -use Cwd;
> -
> -my $cur_path = fastgetcwd() . '/';
> -my $lk_path = "./";
> -my $email = 1;
> -my $email_usename = 1;
> -my $email_maintainer = 1;
> -my $email_reviewer = 1;
> -my $email_list = 1;
> -my $email_subscriber_list = 0;
> -my $email_git_penguin_chiefs = 0;
> -my $email_git = 0;
> -my $email_git_all_signature_types = 0;
> -my $email_git_blame = 0;
> -my $email_git_blame_signatures = 1;
> -my $email_git_fallback = 1;
> -my $email_git_min_signatures = 1;
> -my $email_git_max_maintainers = 5;
> -my $email_git_min_percent = 15;
> -my $email_git_since = "1-year-ago";
> -my $email_hg_since = "-365";
> -my $interactive = 0;
> -my $email_remove_duplicates = 1;
> -my $email_use_mailmap = 1;
> -my $output_multiline = 1;
> -my $output_separator = ", ";
> -my $output_roles = 0;
> -my $output_rolestats = 1;
> -my $output_section_maxlen = 50;
> -my $scm = 0;
> -my $web = 0;
> -my $subsystem = 0;
> -my $status = 0;
> -my $keywords = 1;
> -my $sections = 0;
> -my $file_emails = 0;
> -my $from_filename = 0;
> -my $pattern_depth = 0;
> -my $version = 0;
> -my $help = 0;
> -
> -my $vcs_used = 0;
> -
> -my $exit = 0;
> -
> -my %commit_author_hash;
> -my %commit_signer_hash;
> -
> -my @penguin_chief = ();
> -#push(@penguin_chief, "Linus Torvalds:torvalds\@linux-foundation.org");
> -#Andrew wants in on most everything - 2009/01/14
> -#push(@penguin_chief, "Andrew Morton:akpm\@linux-foundation.org");
> -
> -my @penguin_chief_names = ();
> -foreach my $chief (@penguin_chief) {
> -if ($chief =~ m/^(.*):(.*)/) {
> -   my $chief_name = $1;
> -   my $chief_addr = $2;
> -   push(@penguin_chief_names, $chief_name);
> -}
> -}
> -my $penguin_chiefs = "\(" . join("|", @penguin_chief_names) . "\)";
> -
> -# Signature types of people who are either
> -#  a) responsible for the code in question, or
> -#  b) familiar enough with it to give relevant feedback
> -my @signature_tags = ();
> -push(@signature_tags, "Signed-off-by:");
> -push(@signature_tags, "Reviewed-by:");
> -push(@signature_tags, "Acked-by:");
> -
> -my $signature_pattern = "\(" . join("|", @signature_tags) . "\)";
> -
> -# rfc822 email address - preloaded methods go here.
> -my $rfc822_lwsp = "(?:(?:\\r\\n)?[ \\t])";
> -my $rfc822_char = '[\\000-\\377]';
> -
> -# VCS command support: class-like functions and strings
> -
> -my %VCS_cmds;
> -
> -my %VCS_cmds_git = (
> -"execute_cmd" => \_execute_cmd,
> -"available" => '(which("git") ne "") && (-e ".git")',
> -"find_signers_cmd" =>
> -   "git log --no-color --follow --since=\$email_git_since " .
> - 

Re: [Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

2018-02-28 Thread Jason Ekstrand
Rb

On Wed, Feb 28, 2018 at 12:18 PM, Ian Romanick  wrote:

> From: Ian Romanick 
>
> This transformation is inexact because section 4.7.1 (Range and
> Precision) says:
>
> Operations and built-in functions that operate on a NaN are not
> required to return a NaN as the result.
>
> The fmin or fmax might not return NaN in cases where the original
> expression would be required to return NaN.
>
> v2: Reorder operands and mark as inexact.  The latter suggested by
> Jason.
>
> shader-db results:
>
> Haswell, Broadwell, and Skylake had similar results. (Skylake shown)
> total instructions in shared programs: 14514817 -> 14514808 (<.01%)
> instructions in affected programs: 229 -> 220 (-3.93%)
> helped: 3
> HURT: 0
> helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
> helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%
>
> total cycles in shared programs: 533145211 -> 533144939 (<.01%)
> cycles in affected programs: 37268 -> 36996 (-0.73%)
> helped: 8
> HURT: 0
> helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
> helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%
>
> Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge shown)
> total cycles in shared programs: 257618409 -> 257618403 (<.01%)
> cycles in affected programs: 12582 -> 12576 (-0.05%)
> helped: 3
> HURT: 0
> helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
> helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%
>
> No changes on Iron Lake or GM45.
>
> Signed-off-by: Ian Romanick 
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index d40d59b..17f4d9c 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -170,6 +170,8 @@ optimizations = [
> (('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
> (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
> (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
> +   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
> +   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
> (('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
> (('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
> (('bcsel', a, True, 'b@bool'), ('ior', a, b)),
> --
> 2.9.5
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Jason Ekstrand
I do not think this patch does what you think it does.  The old opcode
allowed you to shift any bit size integer by a 32-bit integer.  The new
version allows you to shift N bits by N bits.  In particular, you can't
shift a 16-bit by a 32-bit value.

I'm not sure what the best thing is to do here.  Really, the size of src1
doesn't really matter as 8-bit is enough to do any shifting needed for a
64-bit src0.  You can always compose with a u2u32 to get any src1 bit size
you want.  We picked 32 because it's been the GL default for a long time.

On Wed, Feb 28, 2018 at 11:51 AM, Rob Clark  wrote:

> From: Karol Herbst 
>
> This is a thing for OpenCL kernels.
>
> Signed-off-by: Rob Clark 
> ---
>  src/compiler/nir/nir_opcodes.py | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_
> opcodes.py
> index 278562b2bd1..c4d2c7805eb 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 == src1) ?
> 1.0f : 0.0f") # Set on Equ
>  binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") # Set
> on Not Equal
>
>
> -opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
> -opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
> -opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
> +opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
> +opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
> +opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
>
>  # bitwise logic operators
>  #
> --
> 2.14.3
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] radv: only emit cache flushes when the pool size is large enough

2018-02-28 Thread Bas Nieuwenhuizen
On Wed, Feb 28, 2018 at 9:41 PM, Samuel Pitoiset
 wrote:
>
>
> On 02/28/2018 09:06 PM, Bas Nieuwenhuizen wrote:
>>
>> On Wed, Feb 28, 2018 at 8:31 PM, Samuel Pitoiset
>>  wrote:
>>>
>>> This is an optimization which reduces the number of flushes for
>>> small pool buffers.
>>>
>>> Signed-off-by: Samuel Pitoiset 
>>> ---
>>>   src/amd/vulkan/radv_meta_buffer.c |  6 --
>>>   src/amd/vulkan/radv_private.h |  6 ++
>>>   src/amd/vulkan/radv_query.c   | 12 
>>>   3 files changed, 14 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/src/amd/vulkan/radv_meta_buffer.c
>>> b/src/amd/vulkan/radv_meta_buffer.c
>>> index e6ad235e93..2e1ba2c7b2 100644
>>> --- a/src/amd/vulkan/radv_meta_buffer.c
>>> +++ b/src/amd/vulkan/radv_meta_buffer.c
>>> @@ -4,12 +4,6 @@
>>>   #include "sid.h"
>>>   #include "radv_cs.h"
>>>
>>> -/*
>>> - * This is the point we switch from using CP to compute shader
>>> - * for certain buffer operations.
>>> - */
>>> -#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
>>> -
>>>   static nir_shader *
>>>   build_buffer_fill_shader(struct radv_device *dev)
>>>   {
>>> diff --git a/src/amd/vulkan/radv_private.h
>>> b/src/amd/vulkan/radv_private.h
>>> index 752b6a7592..0f8ddb2e10 100644
>>> --- a/src/amd/vulkan/radv_private.h
>>> +++ b/src/amd/vulkan/radv_private.h
>>> @@ -95,6 +95,12 @@ typedef uint32_t xcb_window_t;
>>>
>>>   #define NUM_DEPTH_CLEAR_PIPELINES 3
>>>
>>> +/*
>>> + * This is the point we switch from using CP to compute shader
>>> + * for certain buffer operations.
>>> + */
>>> +#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
>>> +
>>>   enum radv_mem_heap {
>>>  RADV_MEM_HEAP_VRAM,
>>>  RADV_MEM_HEAP_VRAM_CPU_ACCESS,
>>> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
>>> index 82831961ac..da2bcf5212 100644
>>> --- a/src/amd/vulkan/radv_query.c
>>> +++ b/src/amd/vulkan/radv_query.c
>>> @@ -1088,10 +1088,14 @@ void radv_CmdBeginQuery(
>>>  radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
>>>
>>>  if (cmd_buffer->pending_reset_query) {
>>> -   /* Make sure to flush caches if the query pool has been
>>> -* previously resetted using the compute shader path.
>>> -*/
>>> -   si_emit_cache_flush(cmd_buffer);
>>> +   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
>>> +   /* Only need to flush caches if the query pool
>>> size is
>>> +* large enough to be resetted using the compute
>>> shader
>>> +* path. Small pools don't need any cache flushes
>>> +* because we use a CP dma clear.
>>> +*/
>>> +   si_emit_cache_flush(cmd_buffer);
>>> +   }
>>>  cmd_buffer->pending_reset_query = false;
>>
>>
>> I think the pending query reset also need to be inside, as otherwise
>> we possibly forget to flush a larger query behind it?
>>
>> I think you can do a similar opt by only setting the reset bit if the
>> fill_buffer command returns non-zero. That way you don't set it for
>> small pools in the first place (though it does not replace this opt).
>
>
> Yes, good point.
>
> I'm going to send a v3 for the backport and I will update the rest later.
>
> Is the Rb for the whole series?

Yup, rest looked good to me.
>
>
>>
>> Otherwise
>>
>> Reviewed-by: Bas Nieuwenhuizen 
>>>
>>>  }
>>>
>>> --
>>> 2.16.2
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH v3] radv: make sure to emit cache flushes before starting a query

2018-02-28 Thread Samuel Pitoiset
If the query pool has been previously resetted using the compute
shader path.

v3: set pending_reset_query only for the compute shader path
v2: handle multiple commands buffers with same pool

Fixes: a41e2e9cf5 ("radv: allow to use a compute shader for resetting the query 
pool")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105292
Cc: "18.0" 
Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c |  7 +++
 src/amd/vulkan/radv_private.h|  5 +
 src/amd/vulkan/radv_query.c  | 28 +---
 3 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 2b41baea3d..cfdc531acd 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1930,6 +1930,13 @@ VkResult radv_BeginCommandBuffer(
 
cmd_buffer->status = RADV_CMD_BUFFER_STATUS_RECORDING;
 
+   /* Force cache flushes before starting a new query in case the
+* corresponding pool has been resetted from a different command
+* buffer. This is because we have to flush caches between reset and
+* begin if the compute shader path has been used.
+*/
+   cmd_buffer->pending_reset_query = true;
+
return result;
 }
 
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index c72df5a737..b76d2eb5cb 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1003,6 +1003,11 @@ struct radv_cmd_buffer {
uint32_t gfx9_fence_offset;
struct radeon_winsys_bo *gfx9_fence_bo;
uint32_t gfx9_fence_idx;
+
+   /**
+* Whether a query pool has been resetted and we have to flush caches.
+*/
+   bool pending_reset_query;
 };
 
 struct radv_image;
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index ace745e4e6..b1393a2ec7 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1058,17 +1058,23 @@ void radv_CmdResetQueryPool(
 {
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
RADV_FROM_HANDLE(radv_query_pool, pool, queryPool);
-   struct radv_cmd_state *state = _buffer->state;
+   uint32_t flush_bits = 0;
 
-   state->flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
- firstQuery * pool->stride,
- queryCount * pool->stride, 0);
+   flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
+  firstQuery * pool->stride,
+  queryCount * pool->stride, 0);
 
if (pool->type == VK_QUERY_TYPE_TIMESTAMP ||
pool->type == VK_QUERY_TYPE_PIPELINE_STATISTICS) {
-   state->flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
- pool->availability_offset 
+ firstQuery * 4,
- queryCount * 4, 0);
+   flush_bits |= radv_fill_buffer(cmd_buffer, pool->bo,
+  pool->availability_offset + 
firstQuery * 4,
+  queryCount * 4, 0);
+   }
+
+   if (flush_bits) {
+   /* Only need to flush caches for the compute shader path. */
+   cmd_buffer->pending_reset_query = true;
+   cmd_buffer->state.flush_bits |= flush_bits;
}
 }
 
@@ -1086,6 +1092,14 @@ void radv_CmdBeginQuery(
 
radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
 
+   if (cmd_buffer->pending_reset_query) {
+   /* Make sure to flush caches if the query pool has been
+* previously resetted using the compute shader path.
+*/
+   si_emit_cache_flush(cmd_buffer);
+   cmd_buffer->pending_reset_query = false;
+   }
+
switch (pool->type) {
case VK_QUERY_TYPE_OCCLUSION:
radeon_check_space(cmd_buffer->device->ws, cs, 7);
-- 
2.16.2

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


Re: [Mesa-dev] [PATCH 3/3] radv: only emit cache flushes when the pool size is large enough

2018-02-28 Thread Samuel Pitoiset



On 02/28/2018 09:06 PM, Bas Nieuwenhuizen wrote:

On Wed, Feb 28, 2018 at 8:31 PM, Samuel Pitoiset
 wrote:

This is an optimization which reduces the number of flushes for
small pool buffers.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_meta_buffer.c |  6 --
  src/amd/vulkan/radv_private.h |  6 ++
  src/amd/vulkan/radv_query.c   | 12 
  3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_buffer.c 
b/src/amd/vulkan/radv_meta_buffer.c
index e6ad235e93..2e1ba2c7b2 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -4,12 +4,6 @@
  #include "sid.h"
  #include "radv_cs.h"

-/*
- * This is the point we switch from using CP to compute shader
- * for certain buffer operations.
- */
-#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
-
  static nir_shader *
  build_buffer_fill_shader(struct radv_device *dev)
  {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 752b6a7592..0f8ddb2e10 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -95,6 +95,12 @@ typedef uint32_t xcb_window_t;

  #define NUM_DEPTH_CLEAR_PIPELINES 3

+/*
+ * This is the point we switch from using CP to compute shader
+ * for certain buffer operations.
+ */
+#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
+
  enum radv_mem_heap {
 RADV_MEM_HEAP_VRAM,
 RADV_MEM_HEAP_VRAM_CPU_ACCESS,
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 82831961ac..da2bcf5212 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1088,10 +1088,14 @@ void radv_CmdBeginQuery(
 radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);

 if (cmd_buffer->pending_reset_query) {
-   /* Make sure to flush caches if the query pool has been
-* previously resetted using the compute shader path.
-*/
-   si_emit_cache_flush(cmd_buffer);
+   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
+   /* Only need to flush caches if the query pool size is
+* large enough to be resetted using the compute shader
+* path. Small pools don't need any cache flushes
+* because we use a CP dma clear.
+*/
+   si_emit_cache_flush(cmd_buffer);
+   }
 cmd_buffer->pending_reset_query = false;


I think the pending query reset also need to be inside, as otherwise
we possibly forget to flush a larger query behind it?

I think you can do a similar opt by only setting the reset bit if the
fill_buffer command returns non-zero. That way you don't set it for
small pools in the first place (though it does not replace this opt).


Yes, good point.

I'm going to send a v3 for the backport and I will update the rest later.

Is the Rb for the whole series?



Otherwise

Reviewed-by: Bas Nieuwenhuizen 

 }

--
2.16.2

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

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


Re: [Mesa-dev] [PATCH 2/2] travis: make Meson find the proper llvm-config

2018-02-28 Thread Andres Gomez
On Wed, 2018-02-28 at 18:53 +0100, Gert Wollny wrote:
> Am Mittwoch, den 28.02.2018, 17:52 +0200 schrieb Andres Gomez:

[...]

> > 
+  test -f /usr/bin/llvm-config && ln -s /usr/bin/llvm-config
> > $HOME/prefix/bin
> 
> I'm not sure how the toolchain packages on travis are created and maybe
> what I'm writing here is irrelevant, but at least on Debian llvm-config 
> is provided by the package llvm that depends on llvm-X.Y with some
> version X.Y and it is a symlink to the corresponding llvm-config-X.Y
> file. Which version X.Y that actually is depends on what the
> maintainers of llvm decide to be the current default version. In
> current Debian/sid this is llvm-4.0.
> 
> Hence, to be sure to get the desired version X,Y of llvm I'd install
> the according llvm-X.Y package, set LLVM_CONFIG like it is already done
> for the make builds and then do:
> 
>   test -f /usr/bin/${LLVM_CONFIG} && \
>   ln -s /usr/bin/${LLVM_CONFIG}  $HOME/prefix/bin/llvm-config 

I think it makes sense. I will send a new version.

Thanks!

-- 
Br,

Andres

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


Re: [Mesa-dev] [PATCH 1/2] meson: fix LLVM version detection when <= 3.4

2018-02-28 Thread Andres Gomez
On Wed, 2018-02-28 at 17:12 +, Eric Engestrom wrote:
> On Wednesday, 2018-02-28 17:08:41 +, Eric Engestrom wrote:
> > On Wednesday, 2018-02-28 17:02:50 +, Eric Engestrom wrote:
> > > On Wednesday, 2018-02-28 17:52:05 +0200, Andres Gomez wrote:
> > > > 3 digits versions in LLVM only started from 3.4.1 on. Hence, if you
> > > > have installed 3.4 or below, meson will fail even when we may not make
> > > > use of LLVM.
> > > > 
> > > > Cc: Dylan Baker 
> > > > Cc: Eric Engestrom 
> > > > Signed-off-by: Andres Gomez 
> > > > ---
> > > >  meson.build | 13 -
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meson.build b/meson.build
> > > > index 308f64cf811..b8c0b04893c 100644
> > > > --- a/meson.build
> > > > +++ b/meson.build
> > > > @@ -1037,7 +1037,18 @@ if with_llvm
> > > ># that for our version checks.
> > > ># svn suffixes are stripped by meson as of 0.43, and git suffixes are
> > > ># strippped as of 0.44, but we support older meson versions.
> > > > -  _llvm_patch = _llvm_version[2]
> > > > +
> > > > +  # 3 digits versions in LLVM only started from 3.4.1 on
> > > > +  if dep_llvm.version() <= '3.3'
> > > 
> > > The correct 'meson way' to compare version strings is
> > >   if dep_llvm.version().version_compare('<= 3.3')
> > > 
> > > > +_llvm_patch = _llvm_version[1]
> > > > +  elif dep_llvm.version() >= '3.5'
> > > > +_llvm_patch = _llvm_version[2]
> > > > +  elif dep_llvm.version().startswith('3.4.1') or 
> > > > dep_llvm.version().startswith('3.4.2')
> > > > +_llvm_patch = _llvm_version[2]
> > > > +  else
> > > > +_llvm_patch = _llvm_version[1]
> > > > +  endif
> > > 
> > > This whole logic seems overly complicated, and I don't think duplicating
> > > the minor version as the patch version is the right thing either.

Ouch! Right, minor version should be 0 in those cases.

> > > How about this instead?
> > > 
> > >   if dep_llvm.version().version_compare('>= 3.4.1')
> > > _llvm_patch = _llvm_version[2]
> > >   else
> > > _llvm_patch = '0'
> > >   endif
> > 
> > Actually, do we still support llvm < 3.4? Didn't we just bump the
> > minimum to 4.0?
> > I think we did, in which case this patch is not necessary at all :)
> 
> Correction: the minimum is 3.9, which is still >= 3.4, so NAK on this
> patch, it would be dead code anyway :)

The purpose of this patch is not to provide support for older versions
of LLVM but avoiding meson to fail when an older version is present in
the system.

In other words, you can perfectly build with an old LLVM (< 3.4.1) in
the system while not needing LLVM at all (auto). When passing through
this detection code, meson will fail when accessing "_llvm_version[2]"
due to:

"Index 2 out of bounds of array of size 2."

You can see an example of this error at:
https://travis-ci.org/Igalia/release-mesa/builds/347267445


I'll send a new version following your snippet. Thanks! ☺

-- 
Br,

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


[Mesa-dev] [RFC PATCH] get_reviewer.pl: Delete

2018-02-28 Thread Matt Turner
I find this script *really* annoying. Getting Cc'd on a random sample of
a series is doing it wrong. Cc lists of 14 people is doing it wrong.

Let's start the negotiation with "delete this script" and see if anyone
can come up with a way of making this not so stupid.
---
 scripts/get_reviewer.pl | 2301 ---
 1 file changed, 2301 deletions(-)
 delete mode 100755 scripts/get_reviewer.pl

diff --git a/scripts/get_reviewer.pl b/scripts/get_reviewer.pl
deleted file mode 100755
index 62deb922800..000
--- a/scripts/get_reviewer.pl
+++ /dev/null
@@ -1,2301 +0,0 @@
-#!/usr/bin/perl -w
-# (c) 2007, Joe Perches 
-#   created from checkpatch.pl
-#
-# Print selected REVIEWERS information for
-# the files modified in a patch or for a file
-#
-# usage: perl scripts/get_reviewer.pl [OPTIONS] 
-#perl scripts/get_reviewer.pl [OPTIONS] -f 
-#
-# A minimally modified version of get_maintainer.pl from the
-# Linux source tree, adapted for use in mesa.
-#
-# Licensed under the terms of the GNU GPL License version 2
-
-use strict;
-
-my $P = $0;
-my $V = '0.26';
-
-use Getopt::Long qw(:config no_auto_abbrev);
-use Cwd;
-
-my $cur_path = fastgetcwd() . '/';
-my $lk_path = "./";
-my $email = 1;
-my $email_usename = 1;
-my $email_maintainer = 1;
-my $email_reviewer = 1;
-my $email_list = 1;
-my $email_subscriber_list = 0;
-my $email_git_penguin_chiefs = 0;
-my $email_git = 0;
-my $email_git_all_signature_types = 0;
-my $email_git_blame = 0;
-my $email_git_blame_signatures = 1;
-my $email_git_fallback = 1;
-my $email_git_min_signatures = 1;
-my $email_git_max_maintainers = 5;
-my $email_git_min_percent = 15;
-my $email_git_since = "1-year-ago";
-my $email_hg_since = "-365";
-my $interactive = 0;
-my $email_remove_duplicates = 1;
-my $email_use_mailmap = 1;
-my $output_multiline = 1;
-my $output_separator = ", ";
-my $output_roles = 0;
-my $output_rolestats = 1;
-my $output_section_maxlen = 50;
-my $scm = 0;
-my $web = 0;
-my $subsystem = 0;
-my $status = 0;
-my $keywords = 1;
-my $sections = 0;
-my $file_emails = 0;
-my $from_filename = 0;
-my $pattern_depth = 0;
-my $version = 0;
-my $help = 0;
-
-my $vcs_used = 0;
-
-my $exit = 0;
-
-my %commit_author_hash;
-my %commit_signer_hash;
-
-my @penguin_chief = ();
-#push(@penguin_chief, "Linus Torvalds:torvalds\@linux-foundation.org");
-#Andrew wants in on most everything - 2009/01/14
-#push(@penguin_chief, "Andrew Morton:akpm\@linux-foundation.org");
-
-my @penguin_chief_names = ();
-foreach my $chief (@penguin_chief) {
-if ($chief =~ m/^(.*):(.*)/) {
-   my $chief_name = $1;
-   my $chief_addr = $2;
-   push(@penguin_chief_names, $chief_name);
-}
-}
-my $penguin_chiefs = "\(" . join("|", @penguin_chief_names) . "\)";
-
-# Signature types of people who are either
-#  a) responsible for the code in question, or
-#  b) familiar enough with it to give relevant feedback
-my @signature_tags = ();
-push(@signature_tags, "Signed-off-by:");
-push(@signature_tags, "Reviewed-by:");
-push(@signature_tags, "Acked-by:");
-
-my $signature_pattern = "\(" . join("|", @signature_tags) . "\)";
-
-# rfc822 email address - preloaded methods go here.
-my $rfc822_lwsp = "(?:(?:\\r\\n)?[ \\t])";
-my $rfc822_char = '[\\000-\\377]';
-
-# VCS command support: class-like functions and strings
-
-my %VCS_cmds;
-
-my %VCS_cmds_git = (
-"execute_cmd" => \_execute_cmd,
-"available" => '(which("git") ne "") && (-e ".git")',
-"find_signers_cmd" =>
-   "git log --no-color --follow --since=\$email_git_since " .
-   '--numstat --no-merges ' .
-   '--format="GitCommit: %H%n' .
- 'GitAuthor: %an <%ae>%n' .
- 'GitDate: %aD%n' .
- 'GitSubject: %s%n' .
- '%b%n"' .
-   " -- \$file",
-"find_commit_signers_cmd" =>
-   "git log --no-color " .
-   '--numstat ' .
-   '--format="GitCommit: %H%n' .
- 'GitAuthor: %an <%ae>%n' .
- 'GitDate: %aD%n' .
- 'GitSubject: %s%n' .
- '%b%n"' .
-   " -1 \$commit",
-"find_commit_author_cmd" =>
-   "git log --no-color " .
-   '--numstat ' .
-   '--format="GitCommit: %H%n' .
- 'GitAuthor: %an <%ae>%n' .
- 'GitDate: %aD%n' .
- 'GitSubject: %s%n"' .
-   " -1 \$commit",
-"blame_range_cmd" => "git blame -l -L \$diff_start,+\$diff_length \$file",
-"blame_file_cmd" => "git blame -l \$file",
-"commit_pattern" => "^GitCommit: ([0-9a-f]{40,40})",
-"blame_commit_pattern" => "^([0-9a-f]+) ",
-"author_pattern" => "^GitAuthor: (.*)",
-"subject_pattern" => "^GitSubject: (.*)",
-"stat_pattern" => "^(\\d+)\\t(\\d+)\\t\$file\$",
-);
-
-my %VCS_cmds_hg = (
-"execute_cmd" => \_execute_cmd,
-"available" => '(which("hg") ne "") && (-d ".hg")',
-

[Mesa-dev] [PATCH 19/22 v3] i965/fs: Merge CMP and SEL into CSEL on Gen8+

2018-02-28 Thread Ian Romanick
From: Ian Romanick 

v2: Fix several problems handling inverted predicates.  Add a much
bigger comment around the BRW_CONDITIONAL_NZ case.

v3: Allow uniforms and shader inputs as sources for the original SEL and
CMP instructions.  This enables a LOT more shaders to receive CSEL
merging (5816 vs 8564 on SKL).

Broadwell and Skylake had similar results. (Broadwell shown)
helped: 8527
HURT: 0
helped stats (abs) min: 1 max: 27 x̄: 2.44 x̃: 1
helped stats (rel) min: 0.03% max: 17.80% x̄: 1.12% x̃: 0.70%
95% mean confidence interval for instructions value: -2.51 -2.36
95% mean confidence interval for instructions %-change: -1.15% -1.10%
Instructions are helped.

total cycles in shared programs: 559442317 -> 558288357 (-0.21%)
cycles in affected programs: 372699860 -> 371545900 (-0.31%)
helped: 6748
HURT: 1450
helped stats (abs) min: 1 max: 32000 x̄: 182.41 x̃: 12
helped stats (rel) min: <.01% max: 66.08% x̄: 3.42% x̃: 0.70%
HURT stats (abs)   min: 1 max: 2538 x̄: 53.08 x̃: 14
HURT stats (rel)   min: <.01% max: 96.72% x̄: 3.32% x̃: 0.90%
95% mean confidence interval for cycles value: -179.01 -102.51
95% mean confidence interval for cycles %-change: -2.37% -2.08%
Cycles are helped.

LOST:   0
GAINED: 6

No changes on earlier platforms.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs.cpp | 104 ++
 src/intel/compiler/brw_fs.h   |   1 +
 2 files changed, 105 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index accae1b..865e02e 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -2813,6 +2813,104 @@ mask_relative_to(const fs_reg , const fs_reg , 
unsigned ds)
 }
 
 bool
+fs_visitor::opt_peephole_csel()
+{
+   if (devinfo->gen < 8)
+  return false;
+
+   bool progress = false;
+
+   foreach_block_reverse(block, cfg) {
+  int ip = block->end_ip + 1;
+
+  foreach_inst_in_block_reverse_safe(fs_inst, inst, block) {
+ ip--;
+
+ if (inst->opcode != BRW_OPCODE_SEL ||
+ inst->predicate != BRW_PREDICATE_NORMAL ||
+ (inst->dst.type != BRW_REGISTER_TYPE_F &&
+  inst->dst.type != BRW_REGISTER_TYPE_D &&
+  inst->dst.type != BRW_REGISTER_TYPE_UD))
+continue;
+
+ /* Because it is a 3-src instruction, CSEL cannot have an immediate
+  * value as a source, but we can sometimes handle zero.
+  */
+ if ((inst->src[0].file != VGRF && inst->src[0].file != ATTR &&
+  inst->src[0].file != UNIFORM) ||
+ (inst->src[1].file != VGRF && inst->src[1].file != ATTR &&
+  inst->src[1].file != UNIFORM && !inst->src[1].is_zero()))
+continue;
+
+ foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst, inst) 
{
+if (!scan_inst->flags_written())
+   continue;
+
+if ((scan_inst->opcode != BRW_OPCODE_CMP &&
+ scan_inst->opcode != BRW_OPCODE_MOV) ||
+scan_inst->predicate != BRW_PREDICATE_NONE ||
+(scan_inst->src[0].file != VGRF &&
+ scan_inst->src[0].file != ATTR &&
+ scan_inst->src[0].file != UNIFORM) ||
+scan_inst->src[0].type != BRW_REGISTER_TYPE_F)
+   break;
+
+if (scan_inst->opcode == BRW_OPCODE_CMP && 
!scan_inst->src[1].is_zero())
+   break;
+
+const brw::fs_builder ibld(this, block, inst);
+
+const enum brw_conditional_mod cond =
+   inst->predicate_inverse
+   ? brw_negate_cmod(scan_inst->conditional_mod)
+   : scan_inst->conditional_mod;
+
+fs_inst *csel_inst = NULL;
+
+if (inst->src[1].file != IMM) {
+   csel_inst = ibld.CSEL(inst->dst,
+ inst->src[0],
+ inst->src[1],
+ scan_inst->src[0],
+ cond);
+} else if (cond == BRW_CONDITIONAL_NZ) {
+   /* Consider the sequence
+*
+* cmp.nz.f0  null<1>F   g3<8,8,1>F   0F
+* (+f0) sel  g124<1>UD  g2<8,8,1>UD  0xUD
+*
+* The sel will pick the immediate value 0 if r0 is ±0.0.
+* Therefore, this sequence is equivalent:
+*
+* cmp.nz.f0  null<1>F   g3<8,8,1>F   0F
+* (+f0) sel  g124<1>F   g2<8,8,1>F   (abs)g3<8,8,1>F
+*
+* The abs is ensures that the result is 0UD when g3 is -0.0F.
+* By normal cmp-sel merging, this is also equivalent:
+*
+* csel.nzg124<1>F   g2<4,4,1>F   (abs)g3<4,4,1>F  
g3<4,4,1>F
+*/
+   csel_inst = ibld.CSEL(inst->dst,
+  

[Mesa-dev] [PATCH 11.1/22] nir: Mark bcsel-to-fmin (or fmax) transformations as inexact

2018-02-28 Thread Ian Romanick
From: Ian Romanick 

These transformations are inexact because section 4.7.1 (Range and
Precision) says:

Operations and built-in functions that operate on a NaN are not
required to return a NaN as the result.

The fmin or fmax might not return NaN in cases where the original
expression would be required to return NaN.

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir_opt_algebraic.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 17f4d9c..b643cda 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -168,8 +168,8 @@ optimizations = [
(('flt(is_not_used_by_conditional)', ('fadd(is_used_once)', a, ('fneg', 
b)), 0.0), ('flt', a, b)),
 
(('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
-   (('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
-   (('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
+   (('~bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
+   (('~bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
(('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
(('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
(('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
-- 
2.9.5

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


[Mesa-dev] [PATCH 11/22 v2] nir: Recognize some more open-coded fmin / fmax

2018-02-28 Thread Ian Romanick
From: Ian Romanick 

This transformation is inexact because section 4.7.1 (Range and
Precision) says:

Operations and built-in functions that operate on a NaN are not
required to return a NaN as the result.

The fmin or fmax might not return NaN in cases where the original
expression would be required to return NaN.

v2: Reorder operands and mark as inexact.  The latter suggested by
Jason.

shader-db results:

Haswell, Broadwell, and Skylake had similar results. (Skylake shown)
total instructions in shared programs: 14514817 -> 14514808 (<.01%)
instructions in affected programs: 229 -> 220 (-3.93%)
helped: 3
HURT: 0
helped stats (abs) min: 1 max: 4 x̄: 3.00 x̃: 4
helped stats (rel) min: 2.86% max: 4.12% x̄: 3.70% x̃: 4.12%

total cycles in shared programs: 533145211 -> 533144939 (<.01%)
cycles in affected programs: 37268 -> 36996 (-0.73%)
helped: 8
HURT: 0
helped stats (abs) min: 2 max: 134 x̄: 34.00 x̃: 2
helped stats (rel) min: 0.02% max: 14.22% x̄: 3.53% x̃: 0.05%

Sandy Bridge and Ivy Bridge had similar results. (Ivy Bridge shown)
total cycles in shared programs: 257618409 -> 257618403 (<.01%)
cycles in affected programs: 12582 -> 12576 (-0.05%)
helped: 3
HURT: 0
helped stats (abs) min: 2 max: 2 x̄: 2.00 x̃: 2
helped stats (rel) min: 0.05% max: 0.05% x̄: 0.05% x̃: 0.05%

No changes on Iron Lake or GM45.

Signed-off-by: Ian Romanick 
---
 src/compiler/nir/nir_opt_algebraic.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index d40d59b..17f4d9c 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -170,6 +170,8 @@ optimizations = [
(('fge', ('fneg', ('fabs', a)), 0.0), ('feq', a, 0.0)),
(('bcsel', ('flt', b, a), b, a), ('fmin', a, b)),
(('bcsel', ('flt', a, b), b, a), ('fmax', a, b)),
+   (('~bcsel', ('fge', a, b), b, a), ('fmin', a, b)),
+   (('~bcsel', ('fge', b, a), b, a), ('fmax', a, b)),
(('bcsel', ('inot', a), b, c), ('bcsel', a, c, b)),
(('bcsel', a, ('bcsel', a, b, c), d), ('bcsel', a, b, d)),
(('bcsel', a, True, 'b@bool'), ('ior', a, b)),
-- 
2.9.5

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


Re: [Mesa-dev] [PATCH 3/3] radv: only emit cache flushes when the pool size is large enough

2018-02-28 Thread Bas Nieuwenhuizen
On Wed, Feb 28, 2018 at 8:31 PM, Samuel Pitoiset
 wrote:
> This is an optimization which reduces the number of flushes for
> small pool buffers.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_buffer.c |  6 --
>  src/amd/vulkan/radv_private.h |  6 ++
>  src/amd/vulkan/radv_query.c   | 12 
>  3 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_buffer.c 
> b/src/amd/vulkan/radv_meta_buffer.c
> index e6ad235e93..2e1ba2c7b2 100644
> --- a/src/amd/vulkan/radv_meta_buffer.c
> +++ b/src/amd/vulkan/radv_meta_buffer.c
> @@ -4,12 +4,6 @@
>  #include "sid.h"
>  #include "radv_cs.h"
>
> -/*
> - * This is the point we switch from using CP to compute shader
> - * for certain buffer operations.
> - */
> -#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
> -
>  static nir_shader *
>  build_buffer_fill_shader(struct radv_device *dev)
>  {
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 752b6a7592..0f8ddb2e10 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -95,6 +95,12 @@ typedef uint32_t xcb_window_t;
>
>  #define NUM_DEPTH_CLEAR_PIPELINES 3
>
> +/*
> + * This is the point we switch from using CP to compute shader
> + * for certain buffer operations.
> + */
> +#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
> +
>  enum radv_mem_heap {
> RADV_MEM_HEAP_VRAM,
> RADV_MEM_HEAP_VRAM_CPU_ACCESS,
> diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
> index 82831961ac..da2bcf5212 100644
> --- a/src/amd/vulkan/radv_query.c
> +++ b/src/amd/vulkan/radv_query.c
> @@ -1088,10 +1088,14 @@ void radv_CmdBeginQuery(
> radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
>
> if (cmd_buffer->pending_reset_query) {
> -   /* Make sure to flush caches if the query pool has been
> -* previously resetted using the compute shader path.
> -*/
> -   si_emit_cache_flush(cmd_buffer);
> +   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
> +   /* Only need to flush caches if the query pool size is
> +* large enough to be resetted using the compute 
> shader
> +* path. Small pools don't need any cache flushes
> +* because we use a CP dma clear.
> +*/
> +   si_emit_cache_flush(cmd_buffer);
> +   }
> cmd_buffer->pending_reset_query = false;

I think the pending query reset also need to be inside, as otherwise
we possibly forget to flush a larger query behind it?

I think you can do a similar opt by only setting the reset bit if the
fill_buffer command returns non-zero. That way you don't set it for
small pools in the first place (though it does not replace this opt).

Otherwise

Reviewed-by: Bas Nieuwenhuizen 
> }
>
> --
> 2.16.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/13] RFC: nir/vtn: "raw" pointer support

2018-02-28 Thread Rob Clark
An attempt to add physical pointer support to vtn.  I'm not totally
happy about the handling of logical pointers vs physical pointers.
So this is really more of an RFS (request for suggestions)
---
 src/compiler/spirv/spirv_to_nir.c  |  47 +++--
 src/compiler/spirv/vtn_private.h   |  19 +++-
 src/compiler/spirv/vtn_variables.c | 206 +
 3 files changed, 244 insertions(+), 28 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 2f261fbadd7..ca97ee49e08 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -570,6 +570,7 @@ vtn_types_compatible(struct vtn_builder *b,
  vtn_types_compatible(b, t1->array_element, t2->array_element);
 
case vtn_base_type_pointer:
+   case vtn_base_type_raw_pointer:
   return vtn_types_compatible(b, t1->deref, t2->deref);
 
case vtn_base_type_struct:
@@ -607,6 +608,7 @@ vtn_type_copy(struct vtn_builder *b, struct vtn_type *src)
case vtn_base_type_matrix:
case vtn_base_type_array:
case vtn_base_type_pointer:
+   case vtn_base_type_raw_pointer:
case vtn_base_type_image:
case vtn_base_type_sampler:
case vtn_base_type_sampled_image:
@@ -930,6 +932,14 @@ vtn_type_layout_std430(struct vtn_builder *b, struct 
vtn_type *type,
   return type;
}
 
+   case vtn_base_type_raw_pointer: {
+  uint32_t comp_size = b->ptr_size / 8;
+  vtn_assert(comp_size);
+  *size_out = comp_size;
+  *align_out = comp_size;
+  return type;
+   }
+
case vtn_base_type_vector: {
   uint32_t comp_size = glsl_get_bit_size(type->type) / 8;
   assert(type->length > 0 && type->length <= 4);
@@ -1157,16 +1167,19 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   val->type->storage_class = storage_class;
   val->type->deref = deref_type;
 
+// XXX handling the "fake" glsl pointers vs "raw" pointers in kernel
+// is a bit ugly..  need to understand how "pointers" are used in vk
+// and figure out something better
+
+if (!b->kernel_mode) {
   if (storage_class == SpvStorageClassUniform ||
   storage_class == SpvStorageClassStorageBuffer) {
  /* These can actually be stored to nir_variables and used as SSA
   * values so they need a real glsl_type.
   */
  val->type->type = glsl_vector_type(GLSL_TYPE_UINT, 2);
-  }
-
-  if (storage_class == SpvStorageClassWorkgroup &&
-  b->options->lower_workgroup_access_to_offsets) {
+  } else if (storage_class == SpvStorageClassWorkgroup &&
+ b->options->lower_workgroup_access_to_offsets) {
  uint32_t size, align;
  val->type->deref = vtn_type_layout_std430(b, val->type->deref,
, );
@@ -1177,6 +1190,20 @@ vtn_handle_type(struct vtn_builder *b, SpvOp opcode,
   */
  val->type->type = glsl_uint_type();
   }
+} else {
+ uint32_t size, align;
+ if (b->ptr_size == 64) {
+val->type->type = glsl_uint64_t_type();
+ } else {
+val->type->type = glsl_uint_type();
+ }
+ val->type->base_type = vtn_base_type_raw_pointer;
+ /* pointers can be accessed as array, so set the stride as size: */
+ val->type->deref = vtn_type_layout_std430(b, val->type->deref,
+   , );
+ val->type->stride = size;
+ val->type->align = align;
+  }
   break;
}
 
@@ -3242,9 +3269,16 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
   break;
 
case SpvOpMemoryModel:
-  vtn_assert(w[1] == SpvAddressingModelLogical);
+  vtn_assert(w[1] == SpvAddressingModelLogical ||
+ w[1] == SpvAddressingModelPhysical32 ||
+ w[1] == SpvAddressingModelPhysical64);
   vtn_assert(w[2] == SpvMemoryModelSimple ||
- w[2] == SpvMemoryModelGLSL450);
+ w[2] == SpvMemoryModelGLSL450 ||
+ w[2] == SpvMemoryModelOpenCL);
+  if (w[1] == SpvAddressingModelPhysical32)
+ b->ptr_size = 32;
+  else if (w[1] == SpvAddressingModelPhysical64)
+ b->ptr_size = 64;
   break;
 
case SpvOpEntryPoint: {
@@ -3631,6 +3665,7 @@ vtn_handle_body_instruction(struct vtn_builder *b, SpvOp 
opcode,
  sel_type = glsl_vector_type(GLSL_TYPE_BOOL, res_val->type->length);
  break;
   case vtn_base_type_pointer:
+  case vtn_base_type_raw_pointer:
  /* We need to have actual storage for pointer types */
  vtn_fail_if(res_val->type->type == NULL,
  "Invalid pointer result type for OpSelect");
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index 0d0c7bcc43a..7bdb95c47d8 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -262,7 +262,8 @@ enum vtn_base_type {

[Mesa-dev] [PATCH 12/13] compiler: int8/uint8 support

2018-02-28 Thread Rob Clark
From: Karol Herbst 

OpenCL kernels also have int8/uint8.

Signed-off-by: Rob Clark 
---
 src/compiler/builtin_type_macros.h  | 10 
 src/compiler/glsl/ast_to_hir.cpp|  2 ++
 src/compiler/glsl/ir_clone.cpp  |  2 ++
 src/compiler/glsl/link_uniform_initializers.cpp |  2 ++
 src/compiler/glsl_types.cpp | 33 +
 src/compiler/glsl_types.h   |  4 +++
 src/compiler/nir/nir.h  |  4 +++
 src/compiler/nir/nir_search.c   |  2 ++
 src/compiler/nir_types.cpp  | 12 +
 src/compiler/nir_types.h|  6 +
 src/compiler/spirv/spirv_to_nir.c   | 24 ++
 src/compiler/spirv/vtn_variables.c  | 14 +++
 src/intel/compiler/brw_fs.cpp   |  3 +++
 src/intel/compiler/brw_shader.cpp   |  4 +++
 src/intel/compiler/brw_vec4_visitor.cpp |  2 ++
 src/mesa/program/ir_to_mesa.cpp |  4 +++
 src/mesa/state_tracker/st_glsl_types.cpp|  2 ++
 17 files changed, 130 insertions(+)

diff --git a/src/compiler/builtin_type_macros.h 
b/src/compiler/builtin_type_macros.h
index e3a1cd29c87..807691824d3 100644
--- a/src/compiler/builtin_type_macros.h
+++ b/src/compiler/builtin_type_macros.h
@@ -114,6 +114,16 @@ DECL_TYPE(u16vec2,  GL_UNSIGNED_INT16_VEC2_NV, 
GLSL_TYPE_UINT16, 2, 1)
 DECL_TYPE(u16vec3,  GL_UNSIGNED_INT16_VEC3_NV, GLSL_TYPE_UINT16, 3, 1)
 DECL_TYPE(u16vec4,  GL_UNSIGNED_INT16_VEC4_NV, GLSL_TYPE_UINT16, 4, 1)
 
+DECL_TYPE(int8_t,   GL_INT8_NV,  GLSL_TYPE_INT8, 1, 1)
+DECL_TYPE(i8vec2,   GL_INT8_VEC2_NV, GLSL_TYPE_INT8, 2, 1)
+DECL_TYPE(i8vec3,   GL_INT8_VEC3_NV, GLSL_TYPE_INT8, 3, 1)
+DECL_TYPE(i8vec4,   GL_INT8_VEC4_NV, GLSL_TYPE_INT8, 4, 1)
+
+DECL_TYPE(uint8_t,  GL_UNSIGNED_INT8_NV,  GLSL_TYPE_UINT8, 1, 1)
+DECL_TYPE(u8vec2,   GL_UNSIGNED_INT8_VEC2_NV, GLSL_TYPE_UINT8, 2, 1)
+DECL_TYPE(u8vec3,   GL_UNSIGNED_INT8_VEC3_NV, GLSL_TYPE_UINT8, 3, 1)
+DECL_TYPE(u8vec4,   GL_UNSIGNED_INT8_VEC4_NV, GLSL_TYPE_UINT8, 4, 1)
+
 DECL_TYPE(sampler,   GL_SAMPLER_1D,   
GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_VOID)
 DECL_TYPE(sampler1D, GL_SAMPLER_1D,   
GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_1D,   0, 0, GLSL_TYPE_FLOAT)
 DECL_TYPE(sampler2D, GL_SAMPLER_2D,   
GLSL_TYPE_SAMPLER, GLSL_SAMPLER_DIM_2D,   0, 0, GLSL_TYPE_FLOAT)
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 41e74815f31..815e571097c 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -1117,6 +1117,8 @@ do_comparison(void *mem_ctx, int operation, ir_rvalue 
*op0, ir_rvalue *op1)
case GLSL_TYPE_INT64:
case GLSL_TYPE_UINT16:
case GLSL_TYPE_INT16:
+   case GLSL_TYPE_UINT8:
+   case GLSL_TYPE_INT8:
   return new(mem_ctx) ir_expression(operation, op0, op1);
 
case GLSL_TYPE_ARRAY: {
diff --git a/src/compiler/glsl/ir_clone.cpp b/src/compiler/glsl/ir_clone.cpp
index f088b6aebd5..69441fae7de 100644
--- a/src/compiler/glsl/ir_clone.cpp
+++ b/src/compiler/glsl/ir_clone.cpp
@@ -344,6 +344,8 @@ ir_constant::clone(void *mem_ctx, struct hash_table *ht) 
const
case GLSL_TYPE_INT64:
case GLSL_TYPE_UINT16:
case GLSL_TYPE_INT16:
+   case GLSL_TYPE_UINT8:
+   case GLSL_TYPE_INT8:
case GLSL_TYPE_SAMPLER:
case GLSL_TYPE_IMAGE:
   return new(mem_ctx) ir_constant(this->type, >value);
diff --git a/src/compiler/glsl/link_uniform_initializers.cpp 
b/src/compiler/glsl/link_uniform_initializers.cpp
index 35522f76467..d6d63bd61fc 100644
--- a/src/compiler/glsl/link_uniform_initializers.cpp
+++ b/src/compiler/glsl/link_uniform_initializers.cpp
@@ -83,6 +83,8 @@ copy_constant_to_storage(union gl_constant_value *storage,
   case GLSL_TYPE_ERROR:
   case GLSL_TYPE_UINT16:
   case GLSL_TYPE_INT16:
+  case GLSL_TYPE_UINT8:
+  case GLSL_TYPE_INT8:
   case GLSL_TYPE_FLOAT16:
  /* All other types should have already been filtered by other
   * paths in the caller.
diff --git a/src/compiler/glsl_types.cpp b/src/compiler/glsl_types.cpp
index 3cc5eb0495c..b1438300746 100644
--- a/src/compiler/glsl_types.cpp
+++ b/src/compiler/glsl_types.cpp
@@ -623,6 +623,31 @@ glsl_type::u16vec(unsigned components)
return ts[components - 1];
 }
 
+const glsl_type *
+glsl_type::i8vec(unsigned components)
+{
+   if (components == 0 || components > 4)
+  return error_type;
+
+   static const glsl_type *const ts[] = {
+  int8_t_type, i8vec2_type, i8vec3_type, i8vec4_type
+   };
+   return ts[components - 1];
+}
+
+
+const glsl_type *
+glsl_type::u8vec(unsigned components)
+{
+   if (components == 0 || components > 4)
+  return error_type;
+
+   static const glsl_type *const ts[] = {
+  uint8_t_type, u8vec2_type, u8vec3_type, u8vec4_type

[Mesa-dev] [PATCH 11/13] nir/vtn: implement BuiltInGlobalSize

2018-02-28 Thread Rob Clark
From: Karol Herbst 

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_lower_system_values.c | 8 
 src/compiler/shader_enums.c| 1 +
 src/compiler/shader_enums.h| 2 ++
 src/compiler/spirv/vtn_variables.c | 4 
 4 files changed, 15 insertions(+)

diff --git a/src/compiler/nir/nir_lower_system_values.c 
b/src/compiler/nir/nir_lower_system_values.c
index 3594f4ae5ce..f458a87e5aa 100644
--- a/src/compiler/nir/nir_lower_system_values.c
+++ b/src/compiler/nir/nir_lower_system_values.c
@@ -133,6 +133,14 @@ convert_block(nir_block *block, nir_builder *b)
  break;
   }
 
+  case SYSTEM_VALUE_GLOBAL_SIZE: {
+ nir_ssa_def *group_size = nir_load_local_group_size(b);
+ nir_ssa_def *num_work_groups = nir_load_num_work_groups(b);
+ sysval = nir_imul(b, group_size, num_work_groups);
+
+ break;
+  }
+
   default:
  break;
   }
diff --git a/src/compiler/shader_enums.c b/src/compiler/shader_enums.c
index 2179c475abd..aa80e1fb6cf 100644
--- a/src/compiler/shader_enums.c
+++ b/src/compiler/shader_enums.c
@@ -234,6 +234,7 @@ gl_system_value_name(gl_system_value sysval)
  ENUM(SYSTEM_VALUE_NUM_WORK_GROUPS),
  ENUM(SYSTEM_VALUE_VIEW_INDEX),
  ENUM(SYSTEM_VALUE_VERTEX_CNT),
+ ENUM(SYSTEM_VALUE_GLOBAL_SIZE),
};
STATIC_ASSERT(ARRAY_SIZE(names) == SYSTEM_VALUE_MAX);
return NAME(sysval);
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index ac83c65b30c..69afb7dfac4 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -567,6 +567,8 @@ typedef enum
 */
SYSTEM_VALUE_VERTEX_CNT,
 
+   SYSTEM_VALUE_GLOBAL_SIZE,
+
SYSTEM_VALUE_MAX /**< Number of values */
 } gl_system_value;
 
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 62f0592690b..9680d074131 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1294,6 +1294,10 @@ vtn_get_builtin_location(struct vtn_builder *b,
   *location = SYSTEM_VALUE_VIEW_INDEX;
   set_mode_system_value(b, mode);
   break;
+   case SpvBuiltInGlobalSize:
+  *location = SYSTEM_VALUE_GLOBAL_SIZE;
+  set_mode_system_value(b, mode);
+  break;
default:
   vtn_fail("unsupported builtin");
}
-- 
2.14.3

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


[Mesa-dev] [PATCH 08/13] nir/vtn: add OpLifetime*

2018-02-28 Thread Rob Clark
These are just hints so we can ignore them.

Signed-off-by: Rob Clark 
---
 src/compiler/spirv/spirv_to_nir.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index e539d944302..3e7ac46c639 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3771,6 +3771,10 @@ vtn_handle_body_instruction(struct vtn_builder *b, SpvOp 
opcode,
   vtn_handle_barrier(b, opcode, w, count);
   break;
 
+   case SpvOpLifetimeStart:
+   case SpvOpLifetimeStop:
+  break;
+
default:
   vtn_fail("Unhandled opcode");
}
-- 
2.14.3

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


[Mesa-dev] [PATCH 10/13] nir/vtn: print extension name in fail msg

2018-02-28 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 src/compiler/spirv/spirv_to_nir.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 3e7ac46c639..b9e5198e7bc 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -368,13 +368,14 @@ static void
 vtn_handle_extension(struct vtn_builder *b, SpvOp opcode,
  const uint32_t *w, unsigned count)
 {
+   const char *ext = (const char *)[2];
switch (opcode) {
case SpvOpExtInstImport: {
   struct vtn_value *val = vtn_push_value(b, w[1], 
vtn_value_type_extension);
-  if (strcmp((const char *)[2], "GLSL.std.450") == 0) {
+  if (strcmp(ext, "GLSL.std.450") == 0) {
  val->ext_handler = vtn_handle_glsl450_instruction;
   } else {
- vtn_fail("Unsupported extension");
+ vtn_fail("Unsupported extension: %s", ext);
   }
   break;
}
-- 
2.14.3

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


[Mesa-dev] [PATCH 04/13] nir: add load/store_global intrinsics

2018-02-28 Thread Rob Clark
From: Karol Herbst 

OpenCL kernels have raw pointers to global memory, so we need
instructions to load/store in order to dereference these pointers.
In some ways similar to other load/store intrinsics, but rather
than taking an offset as a src argument, they take a raw pointer
value (which can be 32b or 64b depending on the memory model).

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_intrinsics.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index 0915c5e809f..fb58271931e 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -453,6 +453,8 @@ LOAD(shared, 1, 1, BASE, xx, xx, 
NIR_INTRINSIC_CAN_ELIMINATE)
 /* src[] = { offset }. const_index[] = { base, range } */
 LOAD(push_constant, 1, 2, BASE, RANGE, xx,
  NIR_INTRINSIC_CAN_ELIMINATE | NIR_INTRINSIC_CAN_REORDER)
+/* src[] = { address }. No const_index */
+LOAD(global, 1, 0, xx, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE)
 
 /*
  * Stores work the same way as loads, except now the first source is the value
@@ -474,8 +476,10 @@ STORE(per_vertex_output, 3, 3, BASE, WRMASK, COMPONENT, 0)
 STORE(ssbo, 3, 1, WRMASK, xx, xx, 0)
 /* src[] = { value, offset }. const_index[] = { base, write_mask } */
 STORE(shared, 2, 2, BASE, WRMASK, xx, 0)
+/* src[] = { value, address }. const_index[] = { write_mask } */
+STORE(global, 2, 2, BASE, WRMASK, xx, 0)
 
-LAST_INTRINSIC(store_shared)
+LAST_INTRINSIC(store_global)
 
 #undef DEFINE_SYSTEM_VALUE
 #undef INTRINSIC
-- 
2.14.3

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


[Mesa-dev] [PATCH 09/13] nir/vtn: add OpConvertPtrToU

2018-02-28 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 src/compiler/spirv/vtn_alu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index d0c9e316935..9397240912b 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -592,6 +592,7 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
   vtn_handle_bitcast(b, val->ssa, src[0]);
   break;
 
+   case SpvOpConvertPtrToU:
case SpvOpFConvert: {
   nir_alu_type src_alu_type = 
nir_get_nir_type_for_glsl_type(vtn_src[0]->type);
   nir_alu_type dst_alu_type = nir_get_nir_type_for_glsl_type(type);
-- 
2.14.3

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


[Mesa-dev] [PATCH 07/13] nir/vtn: handle WorkGroupSize for kernels

2018-02-28 Thread Rob Clark
Unlike glsl/vk compute shaders, this isn't a builtin constant.

Signed-off-by: Rob Clark 
---
 src/compiler/spirv/spirv_to_nir.c  | 3 +++
 src/compiler/spirv/vtn_private.h   | 2 ++
 src/compiler/spirv/vtn_variables.c | 6 +++---
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index c6df764682e..e539d944302 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3054,6 +3054,9 @@ stage_for_execution_model(struct vtn_builder *b, 
SpvExecutionModel model)
   return MESA_SHADER_FRAGMENT;
case SpvExecutionModelGLCompute:
   return MESA_SHADER_COMPUTE;
+   case SpvExecutionModelKernel:
+  b->kernel_mode = true;
+  return MESA_SHADER_COMPUTE;
default:
   vtn_fail("Unsupported execution model");
}
diff --git a/src/compiler/spirv/vtn_private.h b/src/compiler/spirv/vtn_private.h
index 3e49df4dac8..0d0c7bcc43a 100644
--- a/src/compiler/spirv/vtn_private.h
+++ b/src/compiler/spirv/vtn_private.h
@@ -580,6 +580,8 @@ struct vtn_builder {
unsigned func_param_idx;
 
bool has_loop_continue;
+
+   bool kernel_mode;
 };
 
 nir_ssa_def *
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index 84d2f4f1b57..62f0592690b 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -1259,8 +1259,8 @@ vtn_get_builtin_location(struct vtn_builder *b,
   set_mode_system_value(b, mode);
   break;
case SpvBuiltInWorkgroupSize:
-  /* This should already be handled */
-  vtn_fail("unsupported builtin");
+  *location = SYSTEM_VALUE_LOCAL_GROUP_SIZE;
+  set_mode_system_value(b, mode);
   break;
case SpvBuiltInWorkgroupId:
   *location = SYSTEM_VALUE_WORK_GROUP_ID;
@@ -1341,7 +1341,7 @@ apply_var_decoration(struct vtn_builder *b, nir_variable 
*nir_var,
case SpvDecorationBuiltIn: {
   SpvBuiltIn builtin = dec->literals[0];
 
-  if (builtin == SpvBuiltInWorkgroupSize) {
+  if ((builtin == SpvBuiltInWorkgroupSize) && !b->kernel_mode) {
  /* This shouldn't be a builtin.  It's actually a constant. */
  nir_var->data.mode = nir_var_global;
  nir_var->data.read_only = true;
-- 
2.14.3

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


[Mesa-dev] [PATCH 06/13] nir/vtn: implement SpvOpCopyMemorySized

2018-02-28 Thread Rob Clark
I think a new intrinsic is the easiest way to do this.  We can lower
this to a sequence of load/stores after vtn.

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_intrinsics.h  |  2 ++
 src/compiler/spirv/vtn_variables.c | 17 -
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index fb58271931e..694ee2a5bd7 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -47,6 +47,8 @@ INTRINSIC(nop, 0, ARR(0), false, 0, 0, 0, xx, xx, xx,
 INTRINSIC(load_var, 0, ARR(0), true, 0, 1, 0, xx, xx, xx, 
NIR_INTRINSIC_CAN_ELIMINATE)
 INTRINSIC(store_var, 1, ARR(0), false, 0, 1, 1, WRMASK, xx, xx, 0)
 INTRINSIC(copy_var, 0, ARR(0), false, 0, 2, 0, xx, xx, xx, 0)
+/* src = { dst, src, size_in_bytes } */
+INTRINSIC(copy_mem, 3, ARR(1, 1, 1), false, 0, 0, 0, xx, xx, xx, 0)
 
 /*
  * Interpolation of input.  The interp_var_at* intrinsics are similar to the
diff --git a/src/compiler/spirv/vtn_variables.c 
b/src/compiler/spirv/vtn_variables.c
index ead68b47848..84d2f4f1b57 100644
--- a/src/compiler/spirv/vtn_variables.c
+++ b/src/compiler/spirv/vtn_variables.c
@@ -2022,6 +2022,22 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
+   case SpvOpCopyMemorySized: {
+  struct vtn_ssa_value *dest = vtn_ssa_value(b, w[1]);
+  struct vtn_ssa_value *src  = vtn_ssa_value(b, w[2]);
+  struct vtn_ssa_value *size = vtn_ssa_value(b, w[3]);
+  nir_intrinsic_op op = nir_intrinsic_copy_mem;
+
+  nir_intrinsic_instr *intrin = nir_intrinsic_instr_create(b->shader, op);
+  intrin->src[0] = nir_src_for_ssa(dest->def);
+  intrin->src[1] = nir_src_for_ssa(src->def);
+  intrin->src[2] = nir_src_for_ssa(size->def);
+
+  nir_builder_instr_insert(>nb, >instr);
+
+  break;
+   }
+
case SpvOpLoad: {
   struct vtn_type *res_type =
  vtn_value(b, w[1], vtn_value_type_type)->type;
@@ -2123,7 +2139,6 @@ vtn_handle_variables(struct vtn_builder *b, SpvOp opcode,
   break;
}
 
-   case SpvOpCopyMemorySized:
default:
   vtn_fail("Unhandled opcode");
}
-- 
2.14.3

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


[Mesa-dev] [PATCH 01/13] nir: allow 64 bit shifts

2018-02-28 Thread Rob Clark
From: Karol Herbst 

This is a thing for OpenCL kernels.

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_opcodes.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 278562b2bd1..c4d2c7805eb 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -479,9 +479,9 @@ binop("seq", tfloat32, commutative, "(src0 == src1) ? 1.0f 
: 0.0f") # Set on Equ
 binop("sne", tfloat32, commutative, "(src0 != src1) ? 1.0f : 0.0f") # Set on 
Not Equal
 
 
-opcode("ishl", 0, tint, [0, 0], [tint, tuint32], "", "src0 << src1")
-opcode("ishr", 0, tint, [0, 0], [tint, tuint32], "", "src0 >> src1")
-opcode("ushr", 0, tuint, [0, 0], [tuint, tuint32], "", "src0 >> src1")
+opcode("ishl", 0, tint, [0, 0], [tint, tuint], "", "src0 << src1")
+opcode("ishr", 0, tint, [0, 0], [tint, tuint], "", "src0 >> src1")
+opcode("ushr", 0, tuint, [0, 0], [tuint, tuint], "", "src0 >> src1")
 
 # bitwise logic operators
 #
-- 
2.14.3

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


[Mesa-dev] [PATCH 05/13] nir: expose 'C' wrappers for std430 size/alignment

2018-02-28 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 src/compiler/nir_types.cpp | 12 
 src/compiler/nir_types.h   |  4 
 2 files changed, 16 insertions(+)

diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index cbdd452dc81..0085a19248a 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -117,6 +117,18 @@ glsl_get_aoa_size(const struct glsl_type *type)
return type->arrays_of_arrays_size();
 }
 
+unsigned
+glsl_std430_size(const struct glsl_type *type, bool row_major)
+{
+   return type->std430_size(row_major);
+}
+
+unsigned
+glsl_std430_base_alignment(const struct glsl_type *type, bool row_major)
+{
+   return type->std430_base_alignment(row_major);
+}
+
 unsigned
 glsl_count_attribute_slots(const struct glsl_type *type,
bool is_vertex_input)
diff --git a/src/compiler/nir_types.h b/src/compiler/nir_types.h
index e2dfd1ef5b7..5b5e09d137f 100644
--- a/src/compiler/nir_types.h
+++ b/src/compiler/nir_types.h
@@ -71,6 +71,10 @@ unsigned glsl_get_length(const struct glsl_type *type);
 
 unsigned glsl_get_aoa_size(const struct glsl_type *type);
 
+unsigned glsl_std430_size(const struct glsl_type *type, bool row_major);
+
+unsigned glsl_std430_base_alignment(const struct glsl_type *type, bool 
row_major);
+
 unsigned glsl_count_attribute_slots(const struct glsl_type *type,
 bool is_vertex_input);
 
-- 
2.14.3

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


[Mesa-dev] [PATCH 02/13] nir: add load_param

2018-02-28 Thread Rob Clark
From: Karol Herbst 

OpenCL kernels have parameters (see pipe_grid_info::input), and so we
need a way to access them.

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir_intrinsics.h |  2 ++
 src/compiler/nir/nir_lower_io.c   | 13 ++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_intrinsics.h 
b/src/compiler/nir/nir_intrinsics.h
index ede29277876..0915c5e809f 100644
--- a/src/compiler/nir/nir_intrinsics.h
+++ b/src/compiler/nir/nir_intrinsics.h
@@ -435,6 +435,8 @@ LOAD(ubo, 2, 0, xx, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
NIR_INTRINSIC_CAN_REOR
 LOAD(input, 1, 2, BASE, COMPONENT, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
NIR_INTRINSIC_CAN_REORDER)
 /* src[] = { vertex, offset }. const_index[] = { base, component } */
 LOAD(per_vertex_input, 2, 2, BASE, COMPONENT, xx, NIR_INTRINSIC_CAN_ELIMINATE 
| NIR_INTRINSIC_CAN_REORDER)
+/* src[] = { }. const_index[] = { base } */
+LOAD(param, 0, 1, BASE, xx, xx, NIR_INTRINSIC_CAN_ELIMINATE | 
NIR_INTRINSIC_CAN_REORDER)
 /* src[] = { barycoord, offset }. const_index[] = { base, component } */
 INTRINSIC(load_interpolated_input, 2, ARR(2, 1), true, 0, 0,
   2, BASE, COMPONENT, xx,
diff --git a/src/compiler/nir/nir_lower_io.c b/src/compiler/nir/nir_lower_io.c
index df91febd68d..febd28b560e 100644
--- a/src/compiler/nir/nir_lower_io.c
+++ b/src/compiler/nir/nir_lower_io.c
@@ -199,6 +199,9 @@ lower_load(nir_intrinsic_instr *intrin, struct 
lower_io_state *state,
case nir_var_shared:
   op = nir_intrinsic_load_shared;
   break;
+   case nir_var_param:
+  op = nir_intrinsic_load_param;
+  break;
default:
   unreachable("Unknown variable mode");
}
@@ -207,7 +210,10 @@ lower_load(nir_intrinsic_instr *intrin, struct 
lower_io_state *state,
   nir_intrinsic_instr_create(state->builder.shader, op);
load->num_components = intrin->num_components;
 
-   nir_intrinsic_set_base(load, var->data.driver_location);
+   if (mode == nir_var_param)
+  nir_intrinsic_set_base(load, var->data.location);
+   else
+  nir_intrinsic_set_base(load, var->data.driver_location);
if (mode == nir_var_shader_in || mode == nir_var_shader_out)
   nir_intrinsic_set_component(load, component);
 
@@ -220,7 +226,7 @@ lower_load(nir_intrinsic_instr *intrin, struct 
lower_io_state *state,
} else if (barycentric) {
   load->src[0] = nir_src_for_ssa(barycentric);
   load->src[1] = nir_src_for_ssa(offset);
-   } else {
+   } else if (mode != nir_var_param) {
   load->src[0] = nir_src_for_ssa(offset);
}
 
@@ -407,7 +413,8 @@ nir_lower_io_block(nir_block *block,
   if (mode != nir_var_shader_in &&
   mode != nir_var_shader_out &&
   mode != nir_var_shared &&
-  mode != nir_var_uniform)
+  mode != nir_var_uniform &&
+  mode != nir_var_param)
  continue;
 
   b->cursor = nir_before_instr(instr);
-- 
2.14.3

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


[Mesa-dev] [PATCH 03/13] nir: kernel entrypoints can have arguments

2018-02-28 Thread Rob Clark
This assert is not valid for OpenCL kernels.

TODO can we somehow conditionally assert based on glsl vs cl??

Signed-off-by: Rob Clark 
---
 src/compiler/nir/nir.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 2acd9511f57..29181694a35 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -1954,7 +1954,6 @@ nir_shader_get_entrypoint(nir_shader *shader)
struct exec_node *func_node = exec_list_get_head(>functions);
nir_function *func = exec_node_data(nir_function, func_node, node);
assert(func->return_type == glsl_void_type());
-   assert(func->num_params == 0);
assert(func->impl);
return func->impl;
 }
-- 
2.14.3

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


[Mesa-dev] [PATCH 00/13] nir/vtn/compiler: first batch of compute support

2018-02-28 Thread Rob Clark
This is by no means everything needed for clover/OpenCL.. but I took
a bit of time this morning to extract some parts of our growing stack
of patches which where plausibly mergable (or at least not complete
hacks), with the idea that review could start in parallel with further
clover/compute hacking.

In particular, it could be useful to at least (once reviewed) merge the
new nir intrinsics, since those would unblock landing the corresponding
nvir and ir3 patches which implement the new intrinsics.

The new intrinsics are:
 - load_param - for compute kernels the entrypoint can have parameters
   and we need a way to load them
 - load/store_global - for dereferencing pointers

In the case of pointers, I punted on dealing with local vs global
pointers.  AFAIU with amd/nv GPUs local memory can be mapped into a
single address space alongside global pointers, so they might not really
have to care about pointers into local memory.  For ir3, there *are*
different instructions for local vs global.  One option could be to
emulate a flat address space using the high bits of a pointer (at least
that would work in 64b mode, not sure about 32b mode).  Other option is
"fat" pointers (ie. storing a pointer in a vec2 or two registers, where
one value indicates the pointer type), which at least works ok as long
as everything is in SSA.  But not sure how that would work if you had
to store a pointer value to memory.  But bigger fires, so I punted on
that for now.

The last patch, which adds load/store_global support to vtn, is just RFC.
Mostly looking for suggestions on how best to handle "logical" pointers
(ie. gfx/vk shaders) vs "physical" pointers (ie. compute/kernel).

Karol Herbst (5):
  nir: allow 64 bit shifts
  nir: add load_param
  nir: add load/store_global intrinsics
  nir/vtn: implement BuiltInGlobalSize
  compiler: int8/uint8 support

Rob Clark (8):
  nir: kernel entrypoints can have arguments
  nir: expose 'C' wrappers for std430 size/alignment
  nir/vtn: implement SpvOpCopyMemorySized
  nir/vtn: handle WorkGroupSize for kernels
  nir/vtn: add OpLifetime*
  nir/vtn: add OpConvertPtrToU
  nir/vtn: print extension name in fail msg
  RFC: nir/vtn: "raw" pointer support

 src/compiler/builtin_type_macros.h  |  10 +
 src/compiler/glsl/ast_to_hir.cpp|   2 +
 src/compiler/glsl/ir_clone.cpp  |   2 +
 src/compiler/glsl/link_uniform_initializers.cpp |   2 +
 src/compiler/glsl_types.cpp |  33 
 src/compiler/glsl_types.h   |   4 +
 src/compiler/nir/nir.h  |   5 +-
 src/compiler/nir/nir_intrinsics.h   |  10 +-
 src/compiler/nir/nir_lower_io.c |  13 +-
 src/compiler/nir/nir_lower_system_values.c  |   8 +
 src/compiler/nir/nir_opcodes.py |   6 +-
 src/compiler/nir/nir_search.c   |   2 +
 src/compiler/nir_types.cpp  |  24 +++
 src/compiler/nir_types.h|  10 +
 src/compiler/shader_enums.c |   1 +
 src/compiler/shader_enums.h |   2 +
 src/compiler/spirv/spirv_to_nir.c   |  83 +++-
 src/compiler/spirv/vtn_alu.c|   1 +
 src/compiler/spirv/vtn_private.h|  21 +-
 src/compiler/spirv/vtn_variables.c  | 247 +---
 src/intel/compiler/brw_fs.cpp   |   3 +
 src/intel/compiler/brw_shader.cpp   |   4 +
 src/intel/compiler/brw_vec4_visitor.cpp |   2 +
 src/mesa/program/ir_to_mesa.cpp |   4 +
 src/mesa/state_tracker/st_glsl_types.cpp|   2 +
 25 files changed, 459 insertions(+), 42 deletions(-)

-- 
2.14.3

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


[Mesa-dev] [PATCH 3/3] radv: only emit cache flushes when the pool size is large enough

2018-02-28 Thread Samuel Pitoiset
This is an optimization which reduces the number of flushes for
small pool buffers.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_buffer.c |  6 --
 src/amd/vulkan/radv_private.h |  6 ++
 src/amd/vulkan/radv_query.c   | 12 
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_buffer.c 
b/src/amd/vulkan/radv_meta_buffer.c
index e6ad235e93..2e1ba2c7b2 100644
--- a/src/amd/vulkan/radv_meta_buffer.c
+++ b/src/amd/vulkan/radv_meta_buffer.c
@@ -4,12 +4,6 @@
 #include "sid.h"
 #include "radv_cs.h"
 
-/*
- * This is the point we switch from using CP to compute shader
- * for certain buffer operations.
- */
-#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
-
 static nir_shader *
 build_buffer_fill_shader(struct radv_device *dev)
 {
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 752b6a7592..0f8ddb2e10 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -95,6 +95,12 @@ typedef uint32_t xcb_window_t;
 
 #define NUM_DEPTH_CLEAR_PIPELINES 3
 
+/*
+ * This is the point we switch from using CP to compute shader
+ * for certain buffer operations.
+ */
+#define RADV_BUFFER_OPS_CS_THRESHOLD 4096
+
 enum radv_mem_heap {
RADV_MEM_HEAP_VRAM,
RADV_MEM_HEAP_VRAM_CPU_ACCESS,
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 82831961ac..da2bcf5212 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1088,10 +1088,14 @@ void radv_CmdBeginQuery(
radv_cs_add_buffer(cmd_buffer->device->ws, cs, pool->bo, 8);
 
if (cmd_buffer->pending_reset_query) {
-   /* Make sure to flush caches if the query pool has been
-* previously resetted using the compute shader path.
-*/
-   si_emit_cache_flush(cmd_buffer);
+   if (pool->size >= RADV_BUFFER_OPS_CS_THRESHOLD) {
+   /* Only need to flush caches if the query pool size is
+* large enough to be resetted using the compute shader
+* path. Small pools don't need any cache flushes
+* because we use a CP dma clear.
+*/
+   si_emit_cache_flush(cmd_buffer);
+   }
cmd_buffer->pending_reset_query = false;
}
 
-- 
2.16.2

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


  1   2   >