[Mesa-dev] [Bug 105551] Unable to compile on FreeBSD 9.x and therefore derivatives... undefined reference to `loader_get_extensions_name'

[bugzilla-daemon]

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

--- Comment #3 from Michelle Sullivan  ---
It would appear that the -shared flag is being added by configure...

# FreeBSD 3 and greater uses gcc -shared to do shared libraries.
freebsd* | dragonfly*)
  archive_cmds='$CC -shared $pic_flag -o $lib $libobjs $deplibs
$compiler_flags'
  hardcode_libdir_flag_spec='-R$libdir'
  hardcode_direct=yes
  hardcode_shlibpath_var=no
  ;;

(around line 12723)

After pulling back even more (basically issuing a 'mv configure.orig configure'
before running configure) I noticed this...

/bin/sh ../../libtool  --tag=CC   --mode=link gcc48 -I../../include
-I../../src/loader -I../../src/gbm/main  -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DUSE_SSE41
-DUSE_GCC_ATOMIC_BUILTINS -DNDEBUG -DUSE_X86_64_ASM -DHAVE_XLOCALE_H
-DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_DLOPEN -DHAVE_DL_ITERATE_PHDR
-DHAVE_POSIX_MEMALIGN -DHAVE_LIBDRM -DGLX_USE_DRM -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DENABLE_SHADER_CACHE -DHAVE_MINCORE -DHAVE_LLVM=0x0400
-DMESA_LLVM_VERSION_PATCH=1 -fvisibility=hidden 
-DDEFAULT_DRIVER_DIR='"/usr/local/lib/dri"' -I/usr/local/include
-I/usr/local/include/libdrm   -pthread   -O2 -pipe -isystem /usr/local/include
-fstack-protector -Wl,-rpath=/usr/local/lib/gcc48 -fno-strict-aliasing -Wall
-std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-math-errno -fno-trapping-math  -no-undefined -version-info 1:0
-Wl,--gc-sections -Wl,--no-undefined -L/usr/local/lib
-Wl,-rpath=/usr/local/llvm40/lib -fstack-protector -rpath /usr/local/lib/gcc48
-L/usr/local/lib/gcc48 -o libgbm.la -rpath /usr/local/lib main/backend.lo
main/gbm.lo backends/dri/gbm_dri.lo ../../src/loader/libloader.la  
-L/usr/local/lib -ldrm   -pthread 

Which shows that libloader.la is being created.. the next line was to create a
shared lib for libloader.. the key to the problem being when it comes to
linking that to libgbm... the line before:

libtool: warning: ignoring multiple '-rpath's for a libtool library

Followed by:
libtool: link: gcc48 -shared  -fPIC -DPIC  main/.libs/backend.o
main/.libs/gbm.o backends/dri/.libs/gbm_dri.o   -Wl,-rpath
-Wl,/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/loader/.libs
-Wl,-rpath
-Wl,/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs
-Wl,-rpath -Wl,/usr/local/lib/gcc48
-L/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs
-L/usr/local/lib -L/usr/local/lib/gcc48 ../../src/loader/.libs/libloader.so
/wrkdirs/usr/ports/graphics/mesa-libs/work/mesa-17.1.0/src/mesa/drivers/dri/common/.libs/libxmlconfig.so
-lexpat -lm -ldrm  -pthread -O2 -fstack-protector
-Wl,-rpath=/usr/local/lib/gcc48 -Wl,--gc-sections -Wl,--no-undefined
-Wl,-rpath=/usr/local/llvm40/lib -fstack-protector -pthread   -pthread
-Wl,-soname -Wl,libgbm.so.1 -o .libs/libgbm.so.1.0.0

The problem is the 2 'rpath's brought about by the following make environmental
var:

LDFLAGS=-rpath ${_GCC_RUNTIME} -L${_GCC_RUNTIME}

...the build env has the following:

CC:=gcc${V}
CXX:=   g++${V}
CPP:=   cpp${V}
_GCC_RUNTIME:=  ${LOCALBASE}/lib/gcc${V}
CFLAGS+=-Wl,-rpath=${_GCC_RUNTIME}
CXXFLAGS+=  -Wl,-rpath=${_GCC_RUNTIME}
LDFLAGS+=  -rpath ${_GCC_RUNTIME} -L${_GCC_RUNTIME}

Commenting out the LDFLAGS rpath additional variable fixes it.

Reverting all the other changes to see if it still builds.. if it does
reverting back to 17.2.x and see if that builds...

Regards,

Michelle

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

Re: [Mesa-dev] [FLAG-DAY-PREP 0/9] nir: accessors for deref vars

[Jason Ekstrand]

On March 16, 2018 18:04:26 Rob Clark  wrote:


In ir3, and some of the lowering passes, pretty much 100% of the spots
we reach into deref chain is just to find the nir_variable.. in amd,
it is less (nir->llvm does a lot more with deref chains).. i965 was
kinda in the middle.  And from what I could tell, vc4/vc5 didn't
really care (tbf, most of the places ir3 needed to find the
nir_variable were compute related things which vc4/vc5 hasn't
implemented yet)


In that case, it may make more sense than I initially thought.  I'm sure 
I'll understand better once I get into some other drivers.  I've already 
come across a case or two where I need the variable and it's kind of a pain 
with the new derefs.


--Jason


tbh, I'm in favour of some helpers like this to abstract things a bit
better.. it doesn't make transition from deref chains to deref
instructions completely transparent for all the drivers (although it
nearly would for ir3 at least), but it seems like it would cut down
the churn.  It seems like too much open-coding makes refactoring
harder than it needs to be.

BR,
-R

On Fri, Mar 16, 2018 at 8:26 PM, Jason Ekstrand  wrote:

I'm honestly not sure how helpful this is.  At least in all the places where
this series affects our drivers, more serious changes are needed.


On Fri, Mar 16, 2018 at 3:45 PM, Bas Nieuwenhuizen 
wrote:


FWIW

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Thu, Mar 15, 2018 at 3:27 PM, Rob Clark  wrote:
> Since a fair bit of access to nir_deref_var's is just to chase down the
> nir_variable for an intrinsic (or texture/sampler vars for tex
> instructions), we can make the flag day slightly less painful with some
> accessors that could be re-implemented for deref instruction chains.
>
> It will still be a flag day, there are still a lot of access to the
> nir_deref_var's in intrinsic instructions (and to a slightly lesser
> extent, tex instructions).
>
> Looks like amd's nir->llvm does a lot w/ deref chains.. vc4/vc5 and ir3
> do not so much, other than tex related lowering pass, but I think that
> should be a trivial conversion to the brave new world of deref
> instructions (ie. just need a replacement for nir_deref_var_clone())
>
> This series has light testing w/ freedreno, but it is mostly mechanical
> changes.  If someone wants to feed it to automated testing, I have a
> branch here:
>
>   https://github.com/freedreno/mesa/commits/flag-day-prep
>
> Rob Clark (9):
>   nir: start to abstract deref chains/instructions
>   freedreno/ir3: use nir_intrinsic_var() accessor
>   amd: use nir_intrinsic_var() accessor
>   mesa/st: use nir_intrinsic_var() accessor
>   intel: use nir_intrinsic_var() accessor
>   nir: use nir_intrinsic_var() accessor
>   nir: use nir_tex_*_var() accessors
>   intel: use nir_tex_*_var() accessors
>   amd: use nir_tex_*_var() accessors
>
>  src/amd/common/ac_nir_to_llvm.c| 76
> --
>  src/amd/vulkan/radv_shader_info.c  | 22 ---
>  src/compiler/nir/nir.h | 34 ++
>  src/compiler/nir/nir_gather_info.c |  2 +-
>  src/compiler/nir/nir_inline_functions.c|  6 +-
>  src/compiler/nir/nir_instr_set.c   |  2 +-
>  src/compiler/nir/nir_linking_helpers.c | 10 ++-
>  src/compiler/nir/nir_lower_alpha_test.c|  2 +-
>  src/compiler/nir/nir_lower_atomics.c   | 11 ++--
>  src/compiler/nir/nir_lower_clamp_color_outputs.c   |  2 +-
>  src/compiler/nir/nir_lower_global_vars_to_local.c  |  2 +-
>  src/compiler/nir/nir_lower_indirect_derefs.c   |  4 +-
>  src/compiler/nir/nir_lower_io.c| 10 +--
>  src/compiler/nir/nir_lower_io_arrays_to_elements.c |  4 +-
>  src/compiler/nir/nir_lower_io_to_scalar.c  |  2 +-
>  src/compiler/nir/nir_lower_io_types.c  |  2 +-
>  src/compiler/nir/nir_lower_locals_to_regs.c|  4 +-
>  src/compiler/nir/nir_lower_phis_to_scalar.c|  9 +--
>  src/compiler/nir/nir_lower_samplers.c  |  6 +-
>  src/compiler/nir/nir_lower_system_values.c |  2 +-
>  src/compiler/nir/nir_lower_wpos_ytransform.c   |  4 +-
>  src/compiler/nir/nir_opt_peephole_select.c |  2 +-
>  src/compiler/nir/nir_propagate_invariant.c |  8 +--
>  src/compiler/nir/nir_remove_dead_variables.c   | 25 ---
>  src/compiler/nir/nir_validate.c| 22 ---
>  .../drivers/freedreno/ir3/ir3_compiler_nir.c   |  8 +--
>  src/gallium/drivers/freedreno/ir3/ir3_nir.c|  2 +-
>  src/gallium/drivers/radeonsi/si_shader_nir.c   |  4 +-
>  src/intel/compiler/brw_fs_nir.cpp  |  4 +-
>  src/intel/vulkan/anv_nir_apply_pipeline_layout.c   | 20 +++---
>  src/intel/vulkan/anv_nir_lower_input_attachments.c |  2 +-
>  src/intel/vulkan/anv_nir_lower_ycbcr_textures.c|  2 

[Mesa-dev] [PATCH] virgl: Implement seamless cube maps

[Stéphane Marchesin]

This was previously ignored.

Along with the virglrenderer patch, this fixes ~100 dEQP tests:
dEQP-GLES3.functional.texture.filtering.cube.*

Signed-off-by: Stéphane Marchesin 
---
 src/gallium/drivers/virgl/virgl_encode.c   | 3 ++-
 src/gallium/drivers/virgl/virgl_protocol.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/virgl/virgl_encode.c 
b/src/gallium/drivers/virgl/virgl_encode.c
index 80e60bc284..a6f6d13f85 100644
--- a/src/gallium/drivers/virgl/virgl_encode.c
+++ b/src/gallium/drivers/virgl/virgl_encode.c
@@ -566,7 +566,8 @@ int virgl_encode_sampler_state(struct virgl_context *ctx,
   VIRGL_OBJ_SAMPLE_STATE_S0_MIN_MIP_FILTER(state->min_mip_filter) |
   VIRGL_OBJ_SAMPLE_STATE_S0_MAG_IMG_FILTER(state->mag_img_filter) |
   VIRGL_OBJ_SAMPLE_STATE_S0_COMPARE_MODE(state->compare_mode) |
-  VIRGL_OBJ_SAMPLE_STATE_S0_COMPARE_FUNC(state->compare_func);
+  VIRGL_OBJ_SAMPLE_STATE_S0_COMPARE_FUNC(state->compare_func) |
+  VIRGL_OBJ_SAMPLE_STATE_S0_SEAMLESS_CUBE_MAP(state->seamless_cube_map);
 
virgl_encoder_write_dword(ctx->cbuf, tmp);
virgl_encoder_write_dword(ctx->cbuf, fui(state->lod_bias));
diff --git a/src/gallium/drivers/virgl/virgl_protocol.h 
b/src/gallium/drivers/virgl/virgl_protocol.h
index 7688ac5e8e..5dc2874d1d 100644
--- a/src/gallium/drivers/virgl/virgl_protocol.h
+++ b/src/gallium/drivers/virgl/virgl_protocol.h
@@ -330,6 +330,7 @@ enum virgl_context_cmd {
 #define VIRGL_OBJ_SAMPLE_STATE_S0_MAG_IMG_FILTER(x) (((x) & 0x3) << 13)
 #define VIRGL_OBJ_SAMPLE_STATE_S0_COMPARE_MODE(x) (((x) & 0x1) << 15)
 #define VIRGL_OBJ_SAMPLE_STATE_S0_COMPARE_FUNC(x) (((x) & 0x7) << 16)
+#define VIRGL_OBJ_SAMPLE_STATE_S0_SEAMLESS_CUBE_MAP(x) (((x) & 0x1) << 19)
 
 #define VIRGL_OBJ_SAMPLER_STATE_LOD_BIAS 3
 #define VIRGL_OBJ_SAMPLER_STATE_MIN_LOD 4
-- 
2.16.2.804.g6dcf76e118-goog

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

[Mesa-dev] [PATCH] nir/dead_cf: also remove useless ifs

[Caio Marcelo de Oliveira Filho]

Generalize the code for remove dead loops to also remove dead if
nodes. The conditions are the same in both cases, if the node (and
it's children) don't have side-effects AND the nodes after it don't
use the values produced by the node.

The only difference is when evaluating side effects: loops consider
only return jumps as a side-effect -- they can stop execution of nodes
after it; if nodes should consider all kinds of jumps (return, break,
continue) since all of them can cause execution of nodes after it to
be skipped.

After this patch, empty ifs (those which both then and else blocks are
empty) will be removed by nir_opt_dead_cf.

No changes to shader-db results, in part because the removal of empty
ifs is currently covered by nir_opt_peephole_select.
---

The motivation is a lowering pass I'm working for anv, that clones the
shader and makes certain changes to it, for which I want to use dead
control flow elimination.

 src/compiler/nir/nir_opt_dead_cf.c | 62 +++---
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/src/compiler/nir/nir_opt_dead_cf.c 
b/src/compiler/nir/nir_opt_dead_cf.c
index 53c92ecc28..15d219ac9d 100644
--- a/src/compiler/nir/nir_opt_dead_cf.c
+++ b/src/compiler/nir/nir_opt_dead_cf.c
@@ -60,12 +60,12 @@
  * }
  * ...
  *
- * Finally, we also handle removing useless loops, i.e. loops with no side
- * effects and without any definitions that are used elsewhere. This case is a
- * little different from the first two in that the code is actually run (it
- * just never does anything), but there are similar issues with needing to
- * be careful with restarting after deleting the cf_node (see dead_cf_list())
- * so this is a convenient place to remove them.
+ * Finally, we also handle removing useless loops and ifs, i.e. loops and ifs
+ * with no side effects and without any definitions that are used
+ * elsewhere. This case is a little different from the first two in that the
+ * code is actually run (it just never does anything), but there are similar
+ * issues with needing to be careful with restarting after deleting the
+ * cf_node (see dead_cf_list()) so this is a convenient place to remove them.
  */
 
 static void
@@ -135,18 +135,26 @@ opt_constant_if(nir_if *if_stmt, bool condition)
 static bool
 cf_node_has_side_effects(nir_cf_node *node)
 {
+   const bool inside_if_stmt = node->type == nir_cf_node_if;
+
nir_foreach_block_in_cf_node(block, node) {
   nir_foreach_instr(instr, block) {
  if (instr->type == nir_instr_type_call)
 return true;
 
- /* Return instructions can cause us to skip over other side-effecting
-  * instructions after the loop, so consider them to have side effects
-  * here.
+ /* For loops, return instructions can cause us to skip over other
+  * side-effecting instructions after the loop, so consider them to
+  * have side effects here.
+  *
+  * For ifs, all jumps can cause skip over other side effect
+  * instructions to be skipped.
+  *
+  * TODO: Fix the traversal to be less conservative. Loops inside if
+  * can break without necessarily causing side effects.
   */
 
  if (instr->type == nir_instr_type_jump &&
- nir_instr_as_jump(instr)->type == nir_jump_return)
+ (inside_if_stmt || nir_instr_as_jump(instr)->type == 
nir_jump_return))
 return true;
 
  if (instr->type != nir_instr_type_intrinsic)
@@ -171,36 +179,37 @@ def_not_live_out(nir_ssa_def *def, void *state)
 }
 
 /*
- * Test if a loop is dead. A loop is dead if:
+ * Test if a loop node or if node is dead. Such nodes are dead if:
  *
  * 1) It has no side effects (i.e. intrinsics which could possibly affect the
  * state of the program aside from producing an SSA value, indicated by a lack
  * of NIR_INTRINSIC_CAN_ELIMINATE).
  *
- * 2) It has no phi nodes after it, since those indicate values inside the
- * loop being used after the loop.
+ * 2) It has no phi instructions after it, since those indicate values inside
+ * the node are being used after the node.
+ *
+ * 3) None of the values defined inside the node is used outside the node,
+ * i.e. none of the definitions that dominate the node exit are used outside.
  *
- * 3) If there are no phi nodes after the loop, then the only way a value
- * defined inside the loop can be used outside the loop is if its definition
- * dominates the block after the loop. If none of the definitions that
- * dominate the loop exit are used outside the loop, then the loop is dead
- * and it can be deleted.
+ * If those conditions hold, then the node is dead and can be deleted.
  */
 
 static bool
-loop_is_dead(nir_loop *loop)
+node_is_dead(nir_cf_node *node)
 {
-   nir_block *before = nir_cf_node_as_block(nir_cf_node_prev(>cf_node));
-   nir_block *after = nir_cf_node_as_block(nir_cf_node_next(>cf_node));
+   assert(node->type == 

[Mesa-dev] [Bug 105171] performance regression (3x slower) running glamor with PutImage workload (radeonsi)

[bugzilla-daemon]

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

--- Comment #18 from Dieter Nützel  ---
(In reply to Dieter Nützel from comment #17)
> (In reply to Clemens Eisserer from comment #16)
> > some here, on my Kaveri 7650k results with the patch are basically unchanged
> > :
> > 
> > amdgpu:
> > 8557.942992 Ops/s; put composition (!); 32x32
> > 
> > should I test with radeon too?
> > 
> > Dieter: Just to be curious, which values do you obtain with your polaris 
> > GPU?
> 
> RX580 (DC enabled) 'cpupower frequency-set -g performance'
> 
> composit (faster): !!! ;-)
> ./JXRenderMark-1.0.1 3 32 3 32 3 32 3 32 3 32 3 32
> 29845.626072 Ops/s; put composition (!); 32x32  
> 
> 30745.957643 Ops/s; put composition (!); 32x32  
> 
> 30922.973502 Ops/s; put composition (!); 32x32  
> 
> 30460.302141 Ops/s; put composition (!); 32x32  
> 
> 30330.232018 Ops/s; put composition (!); 32x32  
> 
> 30757.257217 Ops/s; put composition (!); 32x32
> 
> without (slower):
> 28507.546115 Ops/s; put composition (!); 32x32  
> 
> 29570.588821 Ops/s; put composition (!); 32x32  
> 
> 29909.051450 Ops/s; put composition (!); 32x32  
> 
> 29839.934108 Ops/s; put composition (!); 32x32  
> 
> 30024.853684 Ops/s; put composition (!); 32x32  
> 
> 29852.673826 Ops/s; put composition (!); 32x32

This was with Marek's patch from Comment 14.

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

[Mesa-dev] [Bug 104926] swrast: Mesa 17.3.3 produces: HW cursor for format 875713089 not supported

[bugzilla-daemon]

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

--- Comment #5 from Wayne Blaszczyk  ---
The above patch has fixed the issue for me.

Thanks!

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

Re: [Mesa-dev] [FLAG-DAY-PREP 0/9] nir: accessors for deref vars

[Rob Clark]

In ir3, and some of the lowering passes, pretty much 100% of the spots
we reach into deref chain is just to find the nir_variable.. in amd,
it is less (nir->llvm does a lot more with deref chains).. i965 was
kinda in the middle.  And from what I could tell, vc4/vc5 didn't
really care (tbf, most of the places ir3 needed to find the
nir_variable were compute related things which vc4/vc5 hasn't
implemented yet)

tbh, I'm in favour of some helpers like this to abstract things a bit
better.. it doesn't make transition from deref chains to deref
instructions completely transparent for all the drivers (although it
nearly would for ir3 at least), but it seems like it would cut down
the churn.  It seems like too much open-coding makes refactoring
harder than it needs to be.

BR,
-R

On Fri, Mar 16, 2018 at 8:26 PM, Jason Ekstrand  wrote:
> I'm honestly not sure how helpful this is.  At least in all the places where
> this series affects our drivers, more serious changes are needed.
>
>
> On Fri, Mar 16, 2018 at 3:45 PM, Bas Nieuwenhuizen 
> wrote:
>>
>> FWIW
>>
>> Reviewed-by: Bas Nieuwenhuizen 
>>
>> for the series.
>>
>> On Thu, Mar 15, 2018 at 3:27 PM, Rob Clark  wrote:
>> > Since a fair bit of access to nir_deref_var's is just to chase down the
>> > nir_variable for an intrinsic (or texture/sampler vars for tex
>> > instructions), we can make the flag day slightly less painful with some
>> > accessors that could be re-implemented for deref instruction chains.
>> >
>> > It will still be a flag day, there are still a lot of access to the
>> > nir_deref_var's in intrinsic instructions (and to a slightly lesser
>> > extent, tex instructions).
>> >
>> > Looks like amd's nir->llvm does a lot w/ deref chains.. vc4/vc5 and ir3
>> > do not so much, other than tex related lowering pass, but I think that
>> > should be a trivial conversion to the brave new world of deref
>> > instructions (ie. just need a replacement for nir_deref_var_clone())
>> >
>> > This series has light testing w/ freedreno, but it is mostly mechanical
>> > changes.  If someone wants to feed it to automated testing, I have a
>> > branch here:
>> >
>> >   https://github.com/freedreno/mesa/commits/flag-day-prep
>> >
>> > Rob Clark (9):
>> >   nir: start to abstract deref chains/instructions
>> >   freedreno/ir3: use nir_intrinsic_var() accessor
>> >   amd: use nir_intrinsic_var() accessor
>> >   mesa/st: use nir_intrinsic_var() accessor
>> >   intel: use nir_intrinsic_var() accessor
>> >   nir: use nir_intrinsic_var() accessor
>> >   nir: use nir_tex_*_var() accessors
>> >   intel: use nir_tex_*_var() accessors
>> >   amd: use nir_tex_*_var() accessors
>> >
>> >  src/amd/common/ac_nir_to_llvm.c| 76
>> > --
>> >  src/amd/vulkan/radv_shader_info.c  | 22 ---
>> >  src/compiler/nir/nir.h | 34 ++
>> >  src/compiler/nir/nir_gather_info.c |  2 +-
>> >  src/compiler/nir/nir_inline_functions.c|  6 +-
>> >  src/compiler/nir/nir_instr_set.c   |  2 +-
>> >  src/compiler/nir/nir_linking_helpers.c | 10 ++-
>> >  src/compiler/nir/nir_lower_alpha_test.c|  2 +-
>> >  src/compiler/nir/nir_lower_atomics.c   | 11 ++--
>> >  src/compiler/nir/nir_lower_clamp_color_outputs.c   |  2 +-
>> >  src/compiler/nir/nir_lower_global_vars_to_local.c  |  2 +-
>> >  src/compiler/nir/nir_lower_indirect_derefs.c   |  4 +-
>> >  src/compiler/nir/nir_lower_io.c| 10 +--
>> >  src/compiler/nir/nir_lower_io_arrays_to_elements.c |  4 +-
>> >  src/compiler/nir/nir_lower_io_to_scalar.c  |  2 +-
>> >  src/compiler/nir/nir_lower_io_types.c  |  2 +-
>> >  src/compiler/nir/nir_lower_locals_to_regs.c|  4 +-
>> >  src/compiler/nir/nir_lower_phis_to_scalar.c|  9 +--
>> >  src/compiler/nir/nir_lower_samplers.c  |  6 +-
>> >  src/compiler/nir/nir_lower_system_values.c |  2 +-
>> >  src/compiler/nir/nir_lower_wpos_ytransform.c   |  4 +-
>> >  src/compiler/nir/nir_opt_peephole_select.c |  2 +-
>> >  src/compiler/nir/nir_propagate_invariant.c |  8 +--
>> >  src/compiler/nir/nir_remove_dead_variables.c   | 25 ---
>> >  src/compiler/nir/nir_validate.c| 22 ---
>> >  .../drivers/freedreno/ir3/ir3_compiler_nir.c   |  8 +--
>> >  src/gallium/drivers/freedreno/ir3/ir3_nir.c|  2 +-
>> >  src/gallium/drivers/radeonsi/si_shader_nir.c   |  4 +-
>> >  src/intel/compiler/brw_fs_nir.cpp  |  4 +-
>> >  src/intel/vulkan/anv_nir_apply_pipeline_layout.c   | 20 +++---
>> >  src/intel/vulkan/anv_nir_lower_input_attachments.c |  2 +-
>> >  src/intel/vulkan/anv_nir_lower_ycbcr_textures.c|  2 +-
>> >  src/mesa/state_tracker/st_nir_lower_builtin.c  |  2 +-
>> >  33 files changed, 184 

[Mesa-dev] [Bug 105171] performance regression (3x slower) running glamor with PutImage workload (radeonsi)

[bugzilla-daemon]

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

--- Comment #17 from Dieter Nützel  ---
(In reply to Clemens Eisserer from comment #16)
> some here, on my Kaveri 7650k results with the patch are basically unchanged
> :
> 
> amdgpu:
> 8557.942992 Ops/s; put composition (!); 32x32
> 
> should I test with radeon too?
> 
> Dieter: Just to be curious, which values do you obtain with your polaris GPU?

RX580 (DC enabled) 'cpupower frequency-set -g performance'

composit (faster): !!! ;-)
./JXRenderMark-1.0.1 3 32 3 32 3 32 3 32 3 32 3 32
29845.626072 Ops/s; put composition (!); 32x32  
30745.957643 Ops/s; put composition (!); 32x32  
30922.973502 Ops/s; put composition (!); 32x32  
30460.302141 Ops/s; put composition (!); 32x32  
30330.232018 Ops/s; put composition (!); 32x32  
30757.257217 Ops/s; put composition (!); 32x32

without (slower):
28507.546115 Ops/s; put composition (!); 32x32  
29570.588821 Ops/s; put composition (!); 32x32  
29909.051450 Ops/s; put composition (!); 32x32  
29839.934108 Ops/s; put composition (!); 32x32  
30024.853684 Ops/s; put composition (!); 32x32  
29852.673826 Ops/s; put composition (!); 32x32

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

Re: [Mesa-dev] [FLAG-DAY-PREP 0/9] nir: accessors for deref vars

[Jason Ekstrand]

I'm honestly not sure how helpful this is.  At least in all the places
where this series affects our drivers, more serious changes are needed.

On Fri, Mar 16, 2018 at 3:45 PM, Bas Nieuwenhuizen 
wrote:

> FWIW
>
> Reviewed-by: Bas Nieuwenhuizen 
>
> for the series.
>
> On Thu, Mar 15, 2018 at 3:27 PM, Rob Clark  wrote:
> > Since a fair bit of access to nir_deref_var's is just to chase down the
> > nir_variable for an intrinsic (or texture/sampler vars for tex
> > instructions), we can make the flag day slightly less painful with some
> > accessors that could be re-implemented for deref instruction chains.
> >
> > It will still be a flag day, there are still a lot of access to the
> > nir_deref_var's in intrinsic instructions (and to a slightly lesser
> > extent, tex instructions).
> >
> > Looks like amd's nir->llvm does a lot w/ deref chains.. vc4/vc5 and ir3
> > do not so much, other than tex related lowering pass, but I think that
> > should be a trivial conversion to the brave new world of deref
> > instructions (ie. just need a replacement for nir_deref_var_clone())
> >
> > This series has light testing w/ freedreno, but it is mostly mechanical
> > changes.  If someone wants to feed it to automated testing, I have a
> > branch here:
> >
> >   https://github.com/freedreno/mesa/commits/flag-day-prep
> >
> > Rob Clark (9):
> >   nir: start to abstract deref chains/instructions
> >   freedreno/ir3: use nir_intrinsic_var() accessor
> >   amd: use nir_intrinsic_var() accessor
> >   mesa/st: use nir_intrinsic_var() accessor
> >   intel: use nir_intrinsic_var() accessor
> >   nir: use nir_intrinsic_var() accessor
> >   nir: use nir_tex_*_var() accessors
> >   intel: use nir_tex_*_var() accessors
> >   amd: use nir_tex_*_var() accessors
> >
> >  src/amd/common/ac_nir_to_llvm.c| 76
> --
> >  src/amd/vulkan/radv_shader_info.c  | 22 ---
> >  src/compiler/nir/nir.h | 34 ++
> >  src/compiler/nir/nir_gather_info.c |  2 +-
> >  src/compiler/nir/nir_inline_functions.c|  6 +-
> >  src/compiler/nir/nir_instr_set.c   |  2 +-
> >  src/compiler/nir/nir_linking_helpers.c | 10 ++-
> >  src/compiler/nir/nir_lower_alpha_test.c|  2 +-
> >  src/compiler/nir/nir_lower_atomics.c   | 11 ++--
> >  src/compiler/nir/nir_lower_clamp_color_outputs.c   |  2 +-
> >  src/compiler/nir/nir_lower_global_vars_to_local.c  |  2 +-
> >  src/compiler/nir/nir_lower_indirect_derefs.c   |  4 +-
> >  src/compiler/nir/nir_lower_io.c| 10 +--
> >  src/compiler/nir/nir_lower_io_arrays_to_elements.c |  4 +-
> >  src/compiler/nir/nir_lower_io_to_scalar.c  |  2 +-
> >  src/compiler/nir/nir_lower_io_types.c  |  2 +-
> >  src/compiler/nir/nir_lower_locals_to_regs.c|  4 +-
> >  src/compiler/nir/nir_lower_phis_to_scalar.c|  9 +--
> >  src/compiler/nir/nir_lower_samplers.c  |  6 +-
> >  src/compiler/nir/nir_lower_system_values.c |  2 +-
> >  src/compiler/nir/nir_lower_wpos_ytransform.c   |  4 +-
> >  src/compiler/nir/nir_opt_peephole_select.c |  2 +-
> >  src/compiler/nir/nir_propagate_invariant.c |  8 +--
> >  src/compiler/nir/nir_remove_dead_variables.c   | 25 ---
> >  src/compiler/nir/nir_validate.c| 22 ---
> >  .../drivers/freedreno/ir3/ir3_compiler_nir.c   |  8 +--
> >  src/gallium/drivers/freedreno/ir3/ir3_nir.c|  2 +-
> >  src/gallium/drivers/radeonsi/si_shader_nir.c   |  4 +-
> >  src/intel/compiler/brw_fs_nir.cpp  |  4 +-
> >  src/intel/vulkan/anv_nir_apply_pipeline_layout.c   | 20 +++---
> >  src/intel/vulkan/anv_nir_lower_input_attachments.c |  2 +-
> >  src/intel/vulkan/anv_nir_lower_ycbcr_textures.c|  2 +-
> >  src/mesa/state_tracker/st_nir_lower_builtin.c  |  2 +-
> >  33 files changed, 184 insertions(+), 133 deletions(-)
> >
> > --
> > 2.14.3
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] i965: Add INTEL_DEBUG stages support for disk shader cache

[Jordan Justen]

Cc: Kenneth Graunke 
Cc: Matt Turner 
Signed-off-by: Jordan Justen 
---
 src/mesa/drivers/dri/i965/brw_disk_cache.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/brw_disk_cache.c 
b/src/mesa/drivers/dri/i965/brw_disk_cache.c
index 41f742e858f..0671dd20f85 100644
--- a/src/mesa/drivers/dri/i965/brw_disk_cache.c
+++ b/src/mesa/drivers/dri/i965/brw_disk_cache.c
@@ -31,6 +31,9 @@
 #include "util/macros.h"
 #include "util/mesa-sha1.h"
 
+#include "compiler/brw_eu.h"
+#include "common/gen_debug.h"
+
 #include "brw_context.h"
 #include "brw_program.h"
 #include "brw_cs.h"
@@ -39,6 +42,16 @@
 #include "brw_vs.h"
 #include "brw_wm.h"
 
+static bool
+debug_enabled_for_stage(gl_shader_stage stage)
+{
+   static const uint64_t stage_debug_flags[] = {
+  DEBUG_VS, DEBUG_TCS, DEBUG_TES, DEBUG_GS, DEBUG_WM, DEBUG_CS,
+   };
+   assert((int)stage >= 0 && stage < ARRAY_SIZE(stage_debug_flags));
+   return (INTEL_DEBUG & stage_debug_flags[stage]) != 0;
+}
+
 static void
 gen_shader_sha1(struct brw_context *brw, struct gl_program *prog,
 gl_shader_stage stage, void *key, unsigned char *out_sha1)
@@ -230,6 +243,19 @@ read_and_upload(struct brw_context *brw, struct disk_cache 
*cache,
 
brw_alloc_stage_scratch(brw, stage_state, prog_data->total_scratch);
 
+   if (unlikely(debug_enabled_for_stage(stage))) {
+  fprintf(stderr, "NIR for %s program %d loaded from disk shader cache:\n",
+  _mesa_shader_stage_to_abbrev(stage), brw_program(prog)->id);
+  brw_program_deserialize_nir(>ctx, prog, stage);
+  nir_shader *nir = prog->nir;
+  nir_print_shader(nir, stderr);
+  fprintf(stderr, "Native code for %s %s shader %s from disk cache:\n",
+  nir->info.label ? nir->info.label : "unnamed",
+  _mesa_shader_stage_to_string(nir->info.stage), nir->info.name);
+  brw_disassemble(>screen->devinfo, program, 0,
+  prog_data->program_size, stderr);
+   }
+
brw_upload_cache(>cache, cache_id, _key, brw_prog_key_size(stage),
 program, prog_data->program_size, prog_data,
 brw_prog_data_size(stage), _state->prog_offset,
-- 
2.16.2

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

[Mesa-dev] [Bug 105567] meson/ninja: 1. mesa/vdpau incorrect symlinks in DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path overrides DESTDIR

[bugzilla-daemon]

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

Bug ID: 105567
   Summary: meson/ninja: 1. mesa/vdpau incorrect symlinks in
DESTDIR and 2. Ddri-drivers-path Dvdpau-libs-path
overrides DESTDIR
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: bug0xa...@hushmail.com
QA Contact: mesa-dev@lists.freedesktop.org

A meson/ninja install using option, "-Ddri-drivers-path" overrides the DESTDIR
variable and install to the path specified by "-Ddri-drivers-path". Therefore
files don't get packaged or logged with the files that do get installed to
DESTDIR.

The above behaviour differs from an autotools build and install in which,
"--with-dri-driverdir" does not override DESTDIR.

Slackware installs dri modules in, "/usr/lib64/xorg/modules/dri".

Leaving, "-Ddri-drivers-path" to the default value allows DRI drivers to be
installed in the DESTDIR directory but then xorg-server will need to be
recompiled to find the new DRI driver location.

Meson/ninja installing vdpau libraries (two bugs in one):

1.Symlink bug
If using DESTDIR variable WITHOUT "-Dvdpau-libs-path" then the symlinks,
"libvdpau_radeonsi.so.1.0 libvdpau_radeonsi.so.1 libvdpau_radeonsi.so"
incorrectly point to, "${DESTDIR}/lib64/vdpau/libvdpau_radeonsi.so.1.0.0" and
not, "/usr/lib64/vdpau/vdpau_radeonsi.so.1.0.0".  Autotools building would have
symlinked to, "/usr/lib64/vdpau/vdpau_radeonsi.so.1.0.0" when installing to
DESTDIR.

2. DESTDIR bug/meson feature
If using DESTDIR variable WITH "-Dvdpau-libs-path" then all vdpau related files
and symlinks install to, "/usr/lib64/vdpau/". Symlinks correctly point to
"/usr/lib64/vdpau/libvdpau_radeonsi.so.1.0.0". If installing in this manner
then files and links cannot be packaged or logged with other files that do
install to DESTDIR.

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

Re: [Mesa-dev] [FLAG-DAY-PREP 0/9] nir: accessors for deref vars

[Bas Nieuwenhuizen]

FWIW

Reviewed-by: Bas Nieuwenhuizen 

for the series.

On Thu, Mar 15, 2018 at 3:27 PM, Rob Clark  wrote:
> Since a fair bit of access to nir_deref_var's is just to chase down the
> nir_variable for an intrinsic (or texture/sampler vars for tex
> instructions), we can make the flag day slightly less painful with some
> accessors that could be re-implemented for deref instruction chains.
>
> It will still be a flag day, there are still a lot of access to the
> nir_deref_var's in intrinsic instructions (and to a slightly lesser
> extent, tex instructions).
>
> Looks like amd's nir->llvm does a lot w/ deref chains.. vc4/vc5 and ir3
> do not so much, other than tex related lowering pass, but I think that
> should be a trivial conversion to the brave new world of deref
> instructions (ie. just need a replacement for nir_deref_var_clone())
>
> This series has light testing w/ freedreno, but it is mostly mechanical
> changes.  If someone wants to feed it to automated testing, I have a
> branch here:
>
>   https://github.com/freedreno/mesa/commits/flag-day-prep
>
> Rob Clark (9):
>   nir: start to abstract deref chains/instructions
>   freedreno/ir3: use nir_intrinsic_var() accessor
>   amd: use nir_intrinsic_var() accessor
>   mesa/st: use nir_intrinsic_var() accessor
>   intel: use nir_intrinsic_var() accessor
>   nir: use nir_intrinsic_var() accessor
>   nir: use nir_tex_*_var() accessors
>   intel: use nir_tex_*_var() accessors
>   amd: use nir_tex_*_var() accessors
>
>  src/amd/common/ac_nir_to_llvm.c| 76 
> --
>  src/amd/vulkan/radv_shader_info.c  | 22 ---
>  src/compiler/nir/nir.h | 34 ++
>  src/compiler/nir/nir_gather_info.c |  2 +-
>  src/compiler/nir/nir_inline_functions.c|  6 +-
>  src/compiler/nir/nir_instr_set.c   |  2 +-
>  src/compiler/nir/nir_linking_helpers.c | 10 ++-
>  src/compiler/nir/nir_lower_alpha_test.c|  2 +-
>  src/compiler/nir/nir_lower_atomics.c   | 11 ++--
>  src/compiler/nir/nir_lower_clamp_color_outputs.c   |  2 +-
>  src/compiler/nir/nir_lower_global_vars_to_local.c  |  2 +-
>  src/compiler/nir/nir_lower_indirect_derefs.c   |  4 +-
>  src/compiler/nir/nir_lower_io.c| 10 +--
>  src/compiler/nir/nir_lower_io_arrays_to_elements.c |  4 +-
>  src/compiler/nir/nir_lower_io_to_scalar.c  |  2 +-
>  src/compiler/nir/nir_lower_io_types.c  |  2 +-
>  src/compiler/nir/nir_lower_locals_to_regs.c|  4 +-
>  src/compiler/nir/nir_lower_phis_to_scalar.c|  9 +--
>  src/compiler/nir/nir_lower_samplers.c  |  6 +-
>  src/compiler/nir/nir_lower_system_values.c |  2 +-
>  src/compiler/nir/nir_lower_wpos_ytransform.c   |  4 +-
>  src/compiler/nir/nir_opt_peephole_select.c |  2 +-
>  src/compiler/nir/nir_propagate_invariant.c |  8 +--
>  src/compiler/nir/nir_remove_dead_variables.c   | 25 ---
>  src/compiler/nir/nir_validate.c| 22 ---
>  .../drivers/freedreno/ir3/ir3_compiler_nir.c   |  8 +--
>  src/gallium/drivers/freedreno/ir3/ir3_nir.c|  2 +-
>  src/gallium/drivers/radeonsi/si_shader_nir.c   |  4 +-
>  src/intel/compiler/brw_fs_nir.cpp  |  4 +-
>  src/intel/vulkan/anv_nir_apply_pipeline_layout.c   | 20 +++---
>  src/intel/vulkan/anv_nir_lower_input_attachments.c |  2 +-
>  src/intel/vulkan/anv_nir_lower_ycbcr_textures.c|  2 +-
>  src/mesa/state_tracker/st_nir_lower_builtin.c  |  2 +-
>  33 files changed, 184 insertions(+), 133 deletions(-)
>
> --
> 2.14.3
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH shaderdb] run: shader program file created via GetProgramBinary (v4)

[Dongwon Kim]

With optin '-b', shader-db now generates a shader program binary file
using GetProgramBinary(). This shader program binary can be loaded via
ProgramBinary() to be executed by an application later.

v2: 1. define MAX_LOG_LEN and use it as the size of gl log
2. define MAX_PROG_SIZE and use it as the max size of extracted
   shader_program
3. out_file is now pointer allocated by strdup for the file name

v3: 1. automatically using original shader test file's name +  ".bin"
   as a filename for program binary - better way to cover the case
   with batch compilation of many shader test files in the same
   directory
2. remove --out= since it is now unnecessary (due to v3-1.)
   to provide custom file name. Instead, option, "--bin", which is
   basically a flag that enables getting program binary as a file.
3. Now it tries to get the length of binary by reading program's
   GL_PROGRAM_BINARY_LENGTH_OES parameter

v4: 1. '--bin' -> '-b'
2. stop generating binary program when failing to retrieve the binary
   size
3. error checking after malloc for binary program
4. changed some of variable names
5. several consecutive fprintfs are consolidated
6. removed MAX_LOG_LEN and MAX_PROG_SIZE

Signed-off-by: Dongwon Kim 
---
 run.c | 81 ---
 1 file changed, 78 insertions(+), 3 deletions(-)

diff --git a/run.c b/run.c
index 69e64c7..bcec5ca 100644
--- a/run.c
+++ b/run.c
@@ -356,7 +356,8 @@ const struct platform platforms[] = {
 void print_usage(const char *prog_name)
 {
 fprintf(stderr,
-"Usage: %s [-d ] [-j ] [-o ] [-p 
] \n",
+"Usage: %s [-d ] [-j ] [-o ] "
+"[-p ] [-b] \n",
 prog_name);
 }
 
@@ -435,10 +436,11 @@ main(int argc, char **argv)
 char device_path[64];
 int device_id = 0;
 int opt;
+bool generate_prog_bin = 0;
 
 max_threads = omp_get_max_threads();
 
-while ((opt = getopt(argc, argv, "d:j:o:p:")) != -1) {
+while ((opt = getopt(argc, argv, "d:j:o:p:b")) != -1) {
 switch(opt) {
 case 'd': {
 char *endptr;
@@ -478,6 +480,9 @@ main(int argc, char **argv)
 case 'j':
 max_threads = atoi(optarg);
 break;
+case 'b':
+generate_prog_bin = 1;
+break;
 default:
 fprintf(stderr, "Unknown option: %x\n", opt);
 print_usage(argv[0]);
@@ -813,18 +818,24 @@ main(int argc, char **argv)
 const_text = text;
 GLuint prog = glCreateShaderProgramv(shader[i].type, 1,
  _text);
+
+if (generate_prog_bin)
+fprintf(stderr,
+"Currently, program binary generation "
+"doesn't support SSO.\n");
+
 glDeleteProgram(prog);
 free(text);
 }
 } else if (type == TYPE_CORE || type == TYPE_COMPAT || type == 
TYPE_ES) {
 GLuint prog = glCreateProgram();
+GLint param;
 
 for (unsigned i = 0; i < num_shaders; i++) {
 GLuint s = glCreateShader(shader[i].type);
 glShaderSource(s, 1, [i].text, [i].length);
 glCompileShader(s);
 
-GLint param;
 glGetShaderiv(s, GL_COMPILE_STATUS, );
 if (unlikely(!param)) {
 GLchar log[4096];
@@ -839,6 +850,70 @@ main(int argc, char **argv)
 }
 
 glLinkProgram(prog);
+
+glGetProgramiv(prog, GL_LINK_STATUS, );
+if (unlikely(!param)) {
+GLchar log[4096];
+GLsizei length;
+glGetProgramInfoLog(prog, sizeof(log), , log);
+
+fprintf(stderr, "ERROR: failed to link progam:\n%s\n",
+   log);
+} else if (generate_prog_bin) {
+/* generating shader program binary */
+char *prog_buf;
+GLenum format;
+GLsizei length = 0;
+FILE *fp;
+
+glGetProgramiv(prog, GL_PROGRAM_BINARY_LENGTH, );
+
+if (glGetError() != GL_NO_ERROR) {
+fprintf(stderr,
+"ERROR: failed to generate a program binary "
+"(invalid program size).\n");
+continue;
+}
+
+prog_buf = (char *)malloc(length);
+
+if (!prog_buf) {
+fprintf(stderr,
+"ERROR: failed to generate a program binary "
+

Re: [Mesa-dev] [PATCH 2/2] gk110/ir: always use limm form for log ops with immediates

[Karol Herbst]

On Fri, Mar 16, 2018 at 11:10 PM, Ilia Mirkin  wrote:
> You got the subjects backwards.
>
> On Fri, Mar 16, 2018 at 6:05 PM, Karol Herbst  wrote:
>> in the short imm form 0x8 was sign-extended to 0xfff8 which leads to
>> wrong results.
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
>> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
>> index 58594f02c7f..644bd11ec28 100644
>> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
>> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
>> @@ -887,7 +887,7 @@ CodeEmitterNVC0::emitLogicOp(const Instruction *i, 
>> uint8_t subOp)
>>}
>> } else
>> if (i->encSize == 8) {
>> -  if (isLIMM(i->src(1), TYPE_U32)) {
>> +  if (i->src(1).getFile() == FILE_IMMEDIATE) {
>>   emitForm_A(i, HEX64(3800, 0002));
>>
>>   if (i->flagsDef >= 0)
>
> Should probably assert i->src(1).mod == 0?

well maybe we could just do the fancy imm.applyTo() thing or something
as well as we do in the gk110 case. Sounds like a reasonable thing to
do instead putting asserts all over the code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] intel/blorp: Fix compiler warning about num_layers.

[Eric Anholt]

Lionel Landwerlin  writes:

> On 13/03/18 17:38, Eric Anholt wrote:
>> The compiler doesn't notice that the condition for num_layers to be
>> undefined already defined it above (as our assert checked in a debug
>> build).
>>
>> Cc: Jason Ekstrand 
>> ---
>>   src/mesa/drivers/dri/i965/brw_blorp.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
>> b/src/mesa/drivers/dri/i965/brw_blorp.c
>> index 1d586e5ef38d..2b8d913fa282 100644
>> --- a/src/mesa/drivers/dri/i965/brw_blorp.c
>> +++ b/src/mesa/drivers/dri/i965/brw_blorp.c
>> @@ -1408,6 +1408,7 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
>>assert(level == irb->mt_level);
>>assert(start_layer == irb->mt_layer);
>>assert(num_layers == fb->MaxNumLayers ? irb->layer_count : 1);
>> + num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
>> } else {
>>level = irb->mt_level;
>>start_layer = irb->mt_layer;
>
> I guess if we're going to assign it in both block, better put it 
> before/after the 2 blocks.
>
> What's your compiler? :)

Just gcc 7.3


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] intel/blorp: Fix compiler warning about num_layers.

[Eric Anholt]

The compiler doesn't notice that the condition for num_layers to be
undefined already defined it above (as our assert checked in a debug
build).

v2: Move the pair of assignments to one outside of the block.

Cc: Jason Ekstrand 
Cc: Lionel Landwerlin 
---
 src/mesa/drivers/dri/i965/brw_blorp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_blorp.c 
b/src/mesa/drivers/dri/i965/brw_blorp.c
index 72c5d194efec..72578b6ea5cc 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.c
+++ b/src/mesa/drivers/dri/i965/brw_blorp.c
@@ -1426,8 +1426,8 @@ brw_blorp_clear_depth_stencil(struct brw_context *brw,
   } else {
  level = irb->mt_level;
  start_layer = irb->mt_layer;
- num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
   }
+  num_layers = fb->MaxNumLayers ? irb->layer_count : 1;
 
   stencil_mask = ctx->Stencil.WriteMask[0] & 0xff;
 
-- 
2.16.2

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

Re: [Mesa-dev] [PATCH 2/2] gk110/ir: always use limm form for log ops with immediates

[Ilia Mirkin]

You got the subjects backwards.

On Fri, Mar 16, 2018 at 6:05 PM, Karol Herbst  wrote:
> in the short imm form 0x8 was sign-extended to 0xfff8 which leads to
> wrong results.
>
> Signed-off-by: Karol Herbst 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> index 58594f02c7f..644bd11ec28 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
> @@ -887,7 +887,7 @@ CodeEmitterNVC0::emitLogicOp(const Instruction *i, 
> uint8_t subOp)
>}
> } else
> if (i->encSize == 8) {
> -  if (isLIMM(i->src(1), TYPE_U32)) {
> +  if (i->src(1).getFile() == FILE_IMMEDIATE) {
>   emitForm_A(i, HEX64(3800, 0002));
>
>   if (i->flagsDef >= 0)

Should probably assert i->src(1).mod == 0?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/2] nvc0/ir: always use limm form for log ops with immediates

[Karol Herbst]

in the short imm form 0x8 was sign-extended to 0xfff8 which leads to
wrong results.

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
index 370427d0d13..a988f169bd4 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp
@@ -877,7 +877,7 @@ CodeEmitterGK110::emitLogicOp(const Instruction *i, uint8_t 
subOp)
  code[1] |= 7 << 10;
   }
} else
-   if (isLIMM(i->src(1), TYPE_S32)) {
+   if (i->src(1).getFile() == FILE_IMMEDIATE) {
   emitForm_L(i, 0x200, 0, i->src(1).mod);
   code[1] |= subOp << 24;
   NOT_(3a, 0);
-- 
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] gk110/ir: always use limm form for log ops with immediates

[Karol Herbst]

in the short imm form 0x8 was sign-extended to 0xfff8 which leads to
wrong results.

Signed-off-by: Karol Herbst 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
index 58594f02c7f..644bd11ec28 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp
@@ -887,7 +887,7 @@ CodeEmitterNVC0::emitLogicOp(const Instruction *i, uint8_t 
subOp)
   }
} else
if (i->encSize == 8) {
-  if (isLIMM(i->src(1), TYPE_U32)) {
+  if (i->src(1).getFile() == FILE_IMMEDIATE) {
  emitForm_A(i, HEX64(3800, 0002));
 
  if (i->flagsDef >= 0)
-- 
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: add some comparison simplifications

[Timothy Arceri]

Ok feel free to push your patch with :

Reviewed-by: Timothy Arceri 

On 17/03/18 02:19, Ian Romanick wrote:

On 03/16/2018 07:37 AM, Ian Romanick wrote:

I have basically the same patch setting in my simple-range-analysis tree.

https://cgit.freedesktop.org/~idr/mesa/commit/?h=simple-range-analysis=e9d29d71304347f8ff904294450a398e5838f49a

As Jason mentions, you don't need to explicitly mention the compares.
You don't need the @bool either... the source of b2[fi] is always bool.

IIRC, adding the b2f versions helps some other shaders too.  I'm
(re-)gathering shader-db stats right now...


The shader that lost SIMD16 is one of the Tomb Raider shaders that had a
loop unrolled.  The results on other Intel platforms are similar.

Skylake
total instructions in shared programs: 14391653 -> 14390468 (<.01%)
instructions in affected programs: 111891 -> 110706 (-1.06%)
helped: 501
HURT: 0
helped stats (abs) min: 1 max: 155 x̄: 2.37 x̃: 1
helped stats (rel) min: 0.05% max: 21.54% x̄: 1.61% x̃: 1.01%
95% mean confidence interval for instructions value: -3.23 -1.50
95% mean confidence interval for instructions %-change: -1.77% -1.45%
Instructions are helped.

total cycles in shared programs: 532793024 -> 532776598 (<.01%)
cycles in affected programs: 987682 -> 971256 (-1.66%)
helped: 348
HURT: 41
helped stats (abs) min: 1 max: 3074 x̄: 54.91 x̃: 18
helped stats (rel) min: 0.05% max: 32.24% x̄: 3.36% x̃: 1.68%
HURT stats (abs)   min: 1 max: 422 x̄: 65.39 x̃: 24
HURT stats (rel)   min: 0.09% max: 39.29% x̄: 9.50% x̃: 2.02%
95% mean confidence interval for cycles value: -64.08 -20.38
95% mean confidence interval for cycles %-change: -2.78% -1.23%
Cycles are helped.

total loops in shared programs: 4854 -> 4829 (-0.52%)
loops in affected programs: 27 -> 2 (-92.59%)
helped: 18
HURT: 0
helped stats (abs) min: 1 max: 8 x̄: 1.39 x̃: 1
helped stats (rel) min: 50.00% max: 100.00% x̄: 94.44% x̃: 100.00%
95% mean confidence interval for loops value: -2.21 -0.57
95% mean confidence interval for loops %-change: -102.49% -86.40%
Loops are helped.

LOST:   1
GAINED: 0


On 03/15/2018 08:53 PM, Timothy Arceri wrote:

These can be found in the Tomb Raider shaders, eliminating them
helps unroll more loops.
---
  src/compiler/nir/nir_opt_algebraic.py | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index c9575e6be4..56dfc53043 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -152,6 +152,10 @@ optimizations = [
 (('inot', ('ige', a, b)), ('ilt', a, b)),
 (('inot', ('ieq', a, b)), ('ine', a, b)),
 (('inot', ('ine', a, b)), ('ieq', a, b)),
+   (('ine', ('b2i', ('ige', a, b)), 0), ('ige', a, b)),
+   (('ine', ('b2i', ('ilt', a, b)), 0), ('ilt', a, b)),
+   (('ine', ('b2i', ('ult', a, b)), 0), ('ult', a, b)),
+   (('ine', ('b2i', ('ine', a, b)), 0), ('ine', a, b)),
  
 # 0.0 >= b2f(a)

 # b2f(a) <= 0.0



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




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

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Rob Clark]

On Fri, Mar 16, 2018 at 4:30 PM, Dylan Baker  wrote:
> Quoting Rob Clark (2018-03-16 12:20:10)
>> On Fri, Mar 16, 2018 at 3:13 PM, Jason Ekstrand  wrote:
>> > On Fri, Mar 16, 2018 at 11:53 AM, Dylan Baker  wrote:
>> >>
>> >> Quoting Jason Ekstrand (2018-03-16 11:38:47)
>> >> > On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker 
>> >> > wrote:
>> >> >
>> >> > intr_opcodes = {
>> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>> >> > ...
>> >> > }
>> >> >
>> >> > I prefer this since each dictionary is clearly created without a
>> >> > function
>> >> > obscuring what's actually going on. If you dislike having to repeat
>> >> > the
>> >> > name you
>> >> > could even do something like:
>> >> > intr_opcodes = [
>> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>> >> > ...
>> >> > ]
>> >> > intr_opcodes = {i.name: i for i in intr_opcodes}
>> >> >
>> >> >
>> >> > I'm not sure what I think about this.  On the one hand, having the
>> >> > dictionary
>> >> > explicitly declared is nice.  On the other hand, in nir_opcodes.py we
>> >> > have a
>> >> > bunch of other helper functions we declare along the way to help with
>> >> > specific
>> >> > kinds of opcodes.  It's not as practical to do this if everything is
>> >> > inside of
>> >> > a dictionary declaration.
>> >>
>> >> Why not?
>> >>
>> >> def make_op(name, *args):
>> >> return Intrinsic(name, foo='bar', *args)
>> >>
>> >> intr_opcodes = [
>> >> make_op('nop', ...),
>> >> ]
>> >
>> >
>> > Because it's nice to keep the definition of the wrapper close to where it's
>> > used.
>> >
>>
>> also, fwiw, I end up needing two sets (or possibly lists), a second
>> one for the builders that are generated for sysval intrinsics.. I'm
>> not entirely sure how that would work if everything was declared
>> inline instead of via helper fxns
>
> I'm missing where a helper function adds an intrinsic to more than one list.

system_value() adds to system_values table, after calling intrinsic()
which adds to the global table (this is the reason for the return
statement in intrinsic()

BR,
-R

>> (idk, maybe it is slightly poor form from py perspective.. but otoh
>> clarity for non-py experts who want need to understand the definition
>> of various intrinsics or add new intrinsics seems more important in
>> this case.)
>>
>> BR,
>> -R
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 105551] Unable to compile on FreeBSD 9.x and therefore derivatives... undefined reference to `loader_get_extensions_name'

[bugzilla-daemon]

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

--- Comment #2 from Michelle Sullivan  ---
Same thing happens without LLVM (first thing I did was strip it all back to the
bare minimum.)

This is the only one out of 1200 that fails, so there is something specific to
do with the setup of this one.

If I build with GCC 4.2 it works, but not GCC 4.8.5 and I have no clue about
FreeBSD 10/11 as I don't use either at the moment, but one would assume they do
work.  They are also built with clang and not GCC.

Will look for the -shared flag to see where it is being added, though I am a
little surprised that it would fail to link based on shared or not.

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

Re: [Mesa-dev] [PATCH 2/2] intel/compiler: Use gen_get_device_info() in test_eu_validate

[Dylan Baker]

Quoting Rafael Antognolli (2018-03-16 13:19:11)
> On Fri, Mar 16, 2018 at 10:56:24AM -0700, Matt Turner wrote:
> > Previously the unit test filled out a minimal devinfo struct. A previous
> > patch caused the test to begin assert failing because the devinfo was
> > not complete. Avoid this by using the real mechanism to create devinfo.
> > 
> > Note that we have to drop icl from the table, since we now rely on the
> > name -> PCI ID translation done by gen_device_name_to_pci_device_id(),
> > and ICL's PCI IDs are not upstream yet.
> > 
> > Fixes: f89e735719a6 ("intel/compiler: Check for unsupported register 
> > sizes.")
> 
> Oh, it makes sense to fail, but I don't know why I didn't see any error
> on CI when I submitted this. Is it part of some test not covered by
> percheckin?

It's part of the meson-buildtest. Master is yellow because of this.

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 v0] nir: mako all the intrinsics

[Dylan Baker]

Quoting Rob Clark (2018-03-16 12:20:10)
> On Fri, Mar 16, 2018 at 3:13 PM, Jason Ekstrand  wrote:
> > On Fri, Mar 16, 2018 at 11:53 AM, Dylan Baker  wrote:
> >>
> >> Quoting Jason Ekstrand (2018-03-16 11:38:47)
> >> > On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker 
> >> > wrote:
> >> >
> >> > intr_opcodes = {
> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> >> > ...
> >> > }
> >> >
> >> > I prefer this since each dictionary is clearly created without a
> >> > function
> >> > obscuring what's actually going on. If you dislike having to repeat
> >> > the
> >> > name you
> >> > could even do something like:
> >> > intr_opcodes = [
> >> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> >> > ...
> >> > ]
> >> > intr_opcodes = {i.name: i for i in intr_opcodes}
> >> >
> >> >
> >> > I'm not sure what I think about this.  On the one hand, having the
> >> > dictionary
> >> > explicitly declared is nice.  On the other hand, in nir_opcodes.py we
> >> > have a
> >> > bunch of other helper functions we declare along the way to help with
> >> > specific
> >> > kinds of opcodes.  It's not as practical to do this if everything is
> >> > inside of
> >> > a dictionary declaration.
> >>
> >> Why not?
> >>
> >> def make_op(name, *args):
> >> return Intrinsic(name, foo='bar', *args)
> >>
> >> intr_opcodes = [
> >> make_op('nop', ...),
> >> ]
> >
> >
> > Because it's nice to keep the definition of the wrapper close to where it's
> > used.
> >
> 
> also, fwiw, I end up needing two sets (or possibly lists), a second
> one for the builders that are generated for sysval intrinsics.. I'm
> not entirely sure how that would work if everything was declared
> inline instead of via helper fxns

I'm missing where a helper function adds an intrinsic to more than one list.

> (idk, maybe it is slightly poor form from py perspective.. but otoh
> clarity for non-py experts who want need to understand the definition
> of various intrinsics or add new intrinsics seems more important in
> this case.)
> 
> BR,
> -R


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 2/2] intel/compiler: Use gen_get_device_info() in test_eu_validate

[Rafael Antognolli]

On Fri, Mar 16, 2018 at 10:56:24AM -0700, Matt Turner wrote:
> Previously the unit test filled out a minimal devinfo struct. A previous
> patch caused the test to begin assert failing because the devinfo was
> not complete. Avoid this by using the real mechanism to create devinfo.
> 
> Note that we have to drop icl from the table, since we now rely on the
> name -> PCI ID translation done by gen_device_name_to_pci_device_id(),
> and ICL's PCI IDs are not upstream yet.
> 
> Fixes: f89e735719a6 ("intel/compiler: Check for unsupported register sizes.")

Oh, it makes sense to fail, but I don't know why I didn't see any error
on CI when I submitted this. Is it part of some test not covered by
percheckin?

Either way, both patches are

Reviewed-by: Rafael Antognolli 

> ---
>  src/intel/Makefile.compiler.am  |  1 +
>  src/intel/compiler/meson.build  |  2 +-
>  src/intel/compiler/test_eu_validate.cpp | 55 
> ++---
>  3 files changed, 19 insertions(+), 39 deletions(-)
> 
> diff --git a/src/intel/Makefile.compiler.am b/src/intel/Makefile.compiler.am
> index 45e7a6ccce8..af30a58a1d6 100644
> --- a/src/intel/Makefile.compiler.am
> +++ b/src/intel/Makefile.compiler.am
> @@ -48,6 +48,7 @@ TEST_LIBS = \
>   $(top_builddir)/src/gtest/libgtest.la \
>   compiler/libintel_compiler.la \
>   common/libintel_common.la \
> + dev/libintel_dev.la \
>   $(top_builddir)/src/compiler/nir/libnir.la \
>   $(top_builddir)/src/util/libmesautil.la \
>   $(top_builddir)/src/intel/isl/libisl.la \
> diff --git a/src/intel/compiler/meson.build b/src/intel/compiler/meson.build
> index 602206c725f..72b7a6796cb 100644
> --- a/src/intel/compiler/meson.build
> +++ b/src/intel/compiler/meson.build
> @@ -152,7 +152,7 @@ if with_tests
>  'test_@0@.cpp'.format(t),
>  include_directories : [inc_common, inc_intel],
>  link_with : [
> -  libintel_compiler, libintel_common, libmesa_util, libisl,
> +  libintel_compiler, libintel_common, libintel_dev, libmesa_util, 
> libisl,
>  ],
>  dependencies : [dep_thread, dep_dl, idep_gtest, idep_nir],
>)
> diff --git a/src/intel/compiler/test_eu_validate.cpp 
> b/src/intel/compiler/test_eu_validate.cpp
> index d987311ef84..161db994b2b 100644
> --- a/src/intel/compiler/test_eu_validate.cpp
> +++ b/src/intel/compiler/test_eu_validate.cpp
> @@ -25,38 +25,24 @@
>  #include "brw_eu.h"
>  #include "util/ralloc.h"
>  
> -enum subgen {
> -   IS_G45 = 1,
> -   IS_BYT,
> -   IS_HSW,
> -   IS_CHV,
> -   IS_BXT,
> -   IS_KBL,
> -   IS_GLK,
> -   IS_CFL,
> -};
> -
>  static const struct gen_info {
> const char *name;
> -   int gen;
> -   enum subgen subgen;
>  } gens[] = {
> -   { "brw", 4 },
> -   { "g45", 4, IS_G45 },
> -   { "ilk", 5 },
> -   { "snb", 6 },
> -   { "ivb", 7 },
> -   { "byt", 7, IS_BYT },
> -   { "hsw", 7, IS_HSW },
> -   { "bdw", 8 },
> -   { "chv", 8, IS_CHV },
> -   { "skl", 9 },
> -   { "bxt", 9, IS_BXT },
> -   { "kbl", 9, IS_KBL },
> -   { "glk", 9, IS_GLK },
> -   { "cfl", 9, IS_CFL },
> -   { "cnl", 10 },
> -   { "icl", 11 },
> +   { "brw", },
> +   { "g4x", },
> +   { "ilk", },
> +   { "snb", },
> +   { "ivb", },
> +   { "byt", },
> +   { "hsw", },
> +   { "bdw", },
> +   { "chv", },
> +   { "skl", },
> +   { "bxt", },
> +   { "kbl", },
> +   { "glk", },
> +   { "cfl", },
> +   { "cnl", },
>  };
>  
>  class validation_test: public ::testing::TestWithParam {
> @@ -84,16 +70,9 @@ validation_test::~validation_test()
>  void validation_test::SetUp()
>  {
> struct gen_info info = GetParam();
> +   int devid = gen_device_name_to_pci_device_id(info.name);
>  
> -   devinfo.gen   = info.gen;
> -   devinfo.is_g4x= info.subgen == IS_G45;
> -   devinfo.is_baytrail   = info.subgen == IS_BYT;
> -   devinfo.is_haswell= info.subgen == IS_HSW;
> -   devinfo.is_cherryview = info.subgen == IS_CHV;
> -   devinfo.is_broxton= info.subgen == IS_BXT;
> -   devinfo.is_kabylake   = info.subgen == IS_KBL;
> -   devinfo.is_geminilake = info.subgen == IS_GLK;
> -   devinfo.is_coffeelake = info.subgen == IS_CFL;
> +   gen_get_device_info(devid, );
>  
> brw_init_codegen(, p, p);
>  }
> -- 
> 2.16.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Rob Clark]

On Fri, Mar 16, 2018 at 3:13 PM, Jason Ekstrand  wrote:
> On Fri, Mar 16, 2018 at 11:53 AM, Dylan Baker  wrote:
>>
>> Quoting Jason Ekstrand (2018-03-16 11:38:47)
>> > On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker 
>> > wrote:
>> >
>> > intr_opcodes = {
>> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>> > ...
>> > }
>> >
>> > I prefer this since each dictionary is clearly created without a
>> > function
>> > obscuring what's actually going on. If you dislike having to repeat
>> > the
>> > name you
>> > could even do something like:
>> > intr_opcodes = [
>> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>> > ...
>> > ]
>> > intr_opcodes = {i.name: i for i in intr_opcodes}
>> >
>> >
>> > I'm not sure what I think about this.  On the one hand, having the
>> > dictionary
>> > explicitly declared is nice.  On the other hand, in nir_opcodes.py we
>> > have a
>> > bunch of other helper functions we declare along the way to help with
>> > specific
>> > kinds of opcodes.  It's not as practical to do this if everything is
>> > inside of
>> > a dictionary declaration.
>>
>> Why not?
>>
>> def make_op(name, *args):
>> return Intrinsic(name, foo='bar', *args)
>>
>> intr_opcodes = [
>> make_op('nop', ...),
>> ]
>
>
> Because it's nice to keep the definition of the wrapper close to where it's
> used.
>

also, fwiw, I end up needing two sets (or possibly lists), a second
one for the builders that are generated for sysval intrinsics.. I'm
not entirely sure how that would work if everything was declared
inline instead of via helper fxns

(idk, maybe it is slightly poor form from py perspective.. but otoh
clarity for non-py experts who want need to understand the definition
of various intrinsics or add new intrinsics seems more important in
this case.)

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

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Jason Ekstrand]

On Fri, Mar 16, 2018 at 11:53 AM, Dylan Baker  wrote:

> Quoting Jason Ekstrand (2018-03-16 11:38:47)
> > On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker 
> wrote:
> >
> > intr_opcodes = {
> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> > ...
> > }
> >
> > I prefer this since each dictionary is clearly created without a
> function
> > obscuring what's actually going on. If you dislike having to repeat
> the
> > name you
> > could even do something like:
> > intr_opcodes = [
> > 'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
> > ...
> > ]
> > intr_opcodes = {i.name: i for i in intr_opcodes}
> >
> >
> > I'm not sure what I think about this.  On the one hand, having the
> dictionary
> > explicitly declared is nice.  On the other hand, in nir_opcodes.py we
> have a
> > bunch of other helper functions we declare along the way to help with
> specific
> > kinds of opcodes.  It's not as practical to do this if everything is
> inside of
> > a dictionary declaration.
>
> Why not?
>
> def make_op(name, *args):
> return Intrinsic(name, foo='bar', *args)
>
> intr_opcodes = [
> make_op('nop', ...),
> ]
>

Because it's nice to keep the definition of the wrapper close to where it's
used.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Dylan Baker]

Quoting Rob Clark (2018-03-16 11:45:56)
> On Fri, Mar 16, 2018 at 2:28 PM, Dylan Baker  wrote:
> > Quoting Rob Clark (2018-03-15 18:43:28)
> >> I threatened to do this a long time ago.. I probably *should* have done
> >> it a long time ago when there where many fewer intrinsics.  But the
> >> system of macro/#include magic for dealing with intrinsics is a bit
> >> annoying, and python has the nice property of optional fxn params,
> >> making it possible to define new intrinsics while ignoring parameters
> >> that are not applicable (and naming optional params).  And not having to
> >> specify various array lengths explicitly is nice too.
> >>
> >> I think the end result makes it easier to add new intrinsics.
> >> ---
> >> I still need to update autotools build.. but it's late and my wrist
> >> needs a break so I thought I'd send it out as-is to solicit comments
> >> on the py bits, etc
> >>
> >>  src/compiler/nir/meson.build   |  22 +-
> >>  src/compiler/nir/nir.h |   9 -
> >>  src/compiler/nir/nir_builder.h |  27 +-
> >>  src/compiler/nir/nir_builder_opcodes_h.py  |  24 +-
> >>  src/compiler/nir/nir_intrinsics.h  | 540 
> >> 
> >>  src/compiler/nir/nir_intrinsics.py | 547 
> >> +
> >>  .../nir/{nir_intrinsics.c => nir_intrinsics_c.py}  |  56 +--
> >>  src/compiler/nir/nir_intrinsics_h.py   |  44 ++
> >>  8 files changed, 659 insertions(+), 610 deletions(-)
> >>  delete mode 100644 src/compiler/nir/nir_intrinsics.h
> >>  create mode 100644 src/compiler/nir/nir_intrinsics.py
> >>  rename src/compiler/nir/{nir_intrinsics.c => nir_intrinsics_c.py} (59%)
> >>  create mode 100644 src/compiler/nir/nir_intrinsics_h.py
> >>
> >> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> >> index a70c236b958..ca9237e2ba3 100644
> >> --- a/src/compiler/nir/meson.build
> >> +++ b/src/compiler/nir/meson.build
> >> @@ -65,6 +65,24 @@ nir_opt_algebraic_c = custom_target(
> >>depend_files : files('nir_algebraic.py'),
> >>  )
> >>
> >> +nir_intrinsics_h = custom_target(
> >> +  'nir_intrinsics.h',
> >> +  input : 'nir_intrinsics_h.py',
> >> +  output : 'nir_intrinsics.h',
> >> +  command : [prog_python2, '@INPUT@'],
> >> +  capture : true,
> >
> > Since we're writing a new generator can we not require capture? It has all 
> > sorts
> > of problems if you want to write symbols that an end user's terminal
> > cannot properly decode. (think UTF-8 for people who refuse to move on from 
> > the C
> > days)
> 
> tbh, I have no idea what capture does.. I just copy/pasta from the
> existing examples.  It does work more or less exactly the same way
> that the other py generated files work, so I guess if they need
> 'capture', this does to?

'capture' is meson's equivalent of autotools shell redirect, so if you print you
need capture. 

src/vulkan/util/gen_enum_to_str.py doesn't use capture, (and I wrote most of it,
so I know it's good :) ), if you want something to look at.

> 
> Ofc, give me hints about what needs to change in
> nir_intrinsics_[ch].py to not need this
> 
> (and even better, fix the other codegen cases so next idiot like me
> who comes along and clones an existing example dtrt ;-))

It's on my list of things to do, after meson gets settled (which it seems like
it's settling pretty well at this point.) :)

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 v0] nir: mako all the intrinsics

[Dylan Baker]

Quoting Jason Ekstrand (2018-03-16 11:38:47)
> On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker  wrote:
> 
> intr_opcodes = {
>     'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>     ...
> }
> 
> I prefer this since each dictionary is clearly created without a function
> obscuring what's actually going on. If you dislike having to repeat the
> name you
> could even do something like:
> intr_opcodes = [
>     'nop': Intrinsic('nop', flags=[CAN_ELIMINATE]),
>     ...
> ]
> intr_opcodes = {i.name: i for i in intr_opcodes}
> 
> 
> I'm not sure what I think about this.  On the one hand, having the dictionary
> explicitly declared is nice.  On the other hand, in nir_opcodes.py we have a
> bunch of other helper functions we declare along the way to help with specific
> kinds of opcodes.  It's not as practical to do this if everything is inside of
> a dictionary declaration.

Why not?

def make_op(name, *args):
return Intrinsic(name, foo='bar', *args)

intr_opcodes = [
make_op('nop', ...),
]

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 v0] nir: mako all the intrinsics

[Rob Clark]

On Fri, Mar 16, 2018 at 2:28 PM, Dylan Baker  wrote:
> Quoting Rob Clark (2018-03-15 18:43:28)
>> I threatened to do this a long time ago.. I probably *should* have done
>> it a long time ago when there where many fewer intrinsics.  But the
>> system of macro/#include magic for dealing with intrinsics is a bit
>> annoying, and python has the nice property of optional fxn params,
>> making it possible to define new intrinsics while ignoring parameters
>> that are not applicable (and naming optional params).  And not having to
>> specify various array lengths explicitly is nice too.
>>
>> I think the end result makes it easier to add new intrinsics.
>> ---
>> I still need to update autotools build.. but it's late and my wrist
>> needs a break so I thought I'd send it out as-is to solicit comments
>> on the py bits, etc
>>
>>  src/compiler/nir/meson.build   |  22 +-
>>  src/compiler/nir/nir.h |   9 -
>>  src/compiler/nir/nir_builder.h |  27 +-
>>  src/compiler/nir/nir_builder_opcodes_h.py  |  24 +-
>>  src/compiler/nir/nir_intrinsics.h  | 540 
>> 
>>  src/compiler/nir/nir_intrinsics.py | 547 
>> +
>>  .../nir/{nir_intrinsics.c => nir_intrinsics_c.py}  |  56 +--
>>  src/compiler/nir/nir_intrinsics_h.py   |  44 ++
>>  8 files changed, 659 insertions(+), 610 deletions(-)
>>  delete mode 100644 src/compiler/nir/nir_intrinsics.h
>>  create mode 100644 src/compiler/nir/nir_intrinsics.py
>>  rename src/compiler/nir/{nir_intrinsics.c => nir_intrinsics_c.py} (59%)
>>  create mode 100644 src/compiler/nir/nir_intrinsics_h.py
>>
>> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
>> index a70c236b958..ca9237e2ba3 100644
>> --- a/src/compiler/nir/meson.build
>> +++ b/src/compiler/nir/meson.build
>> @@ -65,6 +65,24 @@ nir_opt_algebraic_c = custom_target(
>>depend_files : files('nir_algebraic.py'),
>>  )
>>
>> +nir_intrinsics_h = custom_target(
>> +  'nir_intrinsics.h',
>> +  input : 'nir_intrinsics_h.py',
>> +  output : 'nir_intrinsics.h',
>> +  command : [prog_python2, '@INPUT@'],
>> +  capture : true,
>
> Since we're writing a new generator can we not require capture? It has all 
> sorts
> of problems if you want to write symbols that an end user's terminal
> cannot properly decode. (think UTF-8 for people who refuse to move on from 
> the C
> days)

tbh, I have no idea what capture does.. I just copy/pasta from the
existing examples.  It does work more or less exactly the same way
that the other py generated files work, so I guess if they need
'capture', this does to?

Ofc, give me hints about what needs to change in
nir_intrinsics_[ch].py to not need this

(and even better, fix the other codegen cases so next idiot like me
who comes along and clones an existing example dtrt ;-))


>
>> +  depend_files : files('nir_intrinsics.py'),
>> +)
>
> There's an idep_nir_headers in meson that has the other generated headers in 
> it,
> this target needs to be added as well.
>
>> +
>> +nir_intrinsics_c = custom_target(
>> +  'nir_intrinsic.c',
>> +  input : 'nir_intrinsics_c.py',
>> +  output : 'nir_intrinsics.c',
>> +  command : [prog_python2, '@INPUT@'],
>> +  capture: true,
>> +  depend_files : files('nir_intrinsics.py'),
>> +)
>> +
>>  spirv_info_c = custom_target(
>>'spirv_info.c',
>>input : files('../spirv/spirv_info_c.py', 
>> '../spirv/spirv.core.grammar.json'),
>> @@ -96,8 +114,6 @@ files_libnir = files(
>>'nir_inline_functions.c',
>>'nir_instr_set.c',
>>'nir_instr_set.h',
>> -  'nir_intrinsics.c',
>> -  'nir_intrinsics.h',
>>'nir_linking_helpers.c',
>>'nir_liveness.c',
>>'nir_loop_analyze.c',
>> @@ -201,7 +217,7 @@ libnir = static_library(
>>'nir',
>>[files_libnir, spirv_info_c, nir_opt_algebraic_c, nir_opcodes_c,
>> nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
>> -   vtn_gather_types_c],
>> +   vtn_gather_types_c, nir_intrinsics_c, nir_intrinsics_h],
>>include_directories : [inc_common, inc_compiler, 
>> include_directories('../spirv')],
>>c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
>>link_with : libcompiler,
>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>> index 1e2ab459bd6..9bcd24a1305 100644
>> --- a/src/compiler/nir/nir.h
>> +++ b/src/compiler/nir/nir.h
>> @@ -945,16 +945,7 @@ typedef struct {
>> struct nir_function *callee;
>>  } nir_call_instr;
>>
>> -#define INTRINSIC(name, num_srcs, src_components, has_dest, 
>> dest_components, \
>> -  num_variables, num_indices, idx0, idx1, idx2, flags) \
>> -   nir_intrinsic_##name,
>> -
>> -#define LAST_INTRINSIC(name) nir_last_intrinsic = nir_intrinsic_##name,
>> -
>> -typedef enum {
>>  #include "nir_intrinsics.h"
>> -   nir_num_intrinsics = nir_last_intrinsic + 1
>> -} nir_intrinsic_op;
>>
>>  #define NIR_INTRINSIC_MAX_CONST_INDEX 

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Jason Ekstrand]

On Fri, Mar 16, 2018 at 11:28 AM, Dylan Baker  wrote:

> Quoting Rob Clark (2018-03-15 18:43:28)
>
> > diff --git a/src/compiler/nir/nir_intrinsics.py b/src/compiler/nir/nir_
> intrinsics.py
> > new file mode 100644
> > index 000..6bb6603586e
> > --- /dev/null
> > +++ b/src/compiler/nir/nir_intrinsics.py
> > @@ -0,0 +1,547 @@
> > +#
> > +# Copyright (C) 2018 Red Hat
> > +# Copyright (C) 2014 Intel Corporation
> > +#
> > +# Permission is hereby granted, free of charge, to any person obtaining
> a
> > +# copy of this software and associated documentation files (the
> "Software"),
> > +# to deal in the Software without restriction, including without
> limitation
> > +# the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > +# and/or sell copies of the Software, and to permit persons to whom the
> > +# Software is furnished to do so, subject to the following conditions:
> > +#
> > +# The above copyright notice and this permission notice (including the
> next
> > +# paragraph) shall be included in all copies or substantial portions of
> the
> > +# Software.
> > +#
> > +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> > +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> > +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> > +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> > +# IN THE SOFTWARE.
> > +#
> > +
> > +# This file defines all the available intrinsics in one place.
> > +#
> > +# The Intrinsic class corresponds one-to-one with nir_intrinsic_info
> > +# structure.
> > +
> > +class Intrinsic(object):
> > +   """Class that represents all the information about an intrinsic
> opcode.
> > +   NOTE: this must be kept in sync with nir_intrinsic_info.
> > +   """
> > +   def __init__(self, name, src_components, dest_components,
> num_variables,
> > +indices, flags):
> > +   """Parameters:
> > +
> > +   - name: the intrinsic name
> > +   - src_components: list of the number of components per src, 0
> means
> > + vectorized instruction with number of components given in the
> > + num_components field in nir_intrinsic_instr.
> > +   - dest_components: number of destination components, -1 means no
> > + dest, 0 means number of components given in num_components
> field
> > + in nir_intrinsic_instr.
> > +   - num_variables: the number of variables
> > +   - indices: list of constant indicies
> > +   - flags: list of semantic flags
> > +   """
> > +   assert isinstance(name, str)
> > +   assert isinstance(src_components, list)
> > +   if len(src_components) > 0:
>
> if src_components:
>
> > +   assert isinstance(src_components[0], int)
> > +   assert isinstance(dest_components, int)
> > +   assert isinstance(num_variables, int)
> > +   assert isinstance(indices, list)
> > +   if len(indices) > 0:
>
> ditto
>
> > +   assert isinstance(indices[0], str)
> > +   assert isinstance(flags, list)
> > +   if len(flags) > 0:
>
> ditto
>
> > +   assert isinstance(flags[0], str)
> > +
> > +   self.name = name
> > +   self.num_srcs = len(src_components)
> > +   self.src_components = src_components
> > +   self.has_dest = (dest_components >= 0)
> > +   self.dest_components = dest_components
> > +   self.num_variables = num_variables
> > +   self.num_indices = len(indices)
> > +   self.indices = indices
> > +   self.flags = flags
> > +
> > +#
> > +# Possible indices:
> > +#
> > +
> > +# A constant 'base' value that is added to an offset src:
> > +BASE = "NIR_INTRINSIC_BASE"
> > +# For store instructions, a writemask:
> > +WRMASK = "NIR_INTRINSIC_WRMASK"
> > +# The stream-id for GS emit_vertex/end_primitive intrinsics:
> > +STREAM_ID = "NIR_INTRINSIC_STREAM_ID"
> > +# The clip-plane id for load_user_clip_plane intrinsics:
> > +UCP_ID = "NIR_INTRINSIC_UCP_ID"
> > +# The amount of data, starting from BASE, that this instruction
> > +# may access.  This is used to provide bounds if the offset is
> > +# not constant.
> > +RANGE = "NIR_INTRINSIC_RANGE"
> > +# The vulkan descriptor set binding for vulkan_resource_index
> > +# intrinsic
> > +DESC_SET = "NIR_INTRINSIC_DESC_SET"
> > +# The vulkan descriptor set binding for vulkan_resource_index
> > +# intrinsic
> > +BINDING = "NIR_INTRINSIC_BINDING"
> > +# Component offset
> > +COMPONENT = "NIR_INTRINSIC_COMPONENT"
> > +# Interpolation mode (only meaningful for FS inputs)
> > +INTERP_MODE = "NIR_INTRINSIC_INTERP_MODE"
> > +# A binary nir_op to use when performing a reduction or scan operation
> > +REDUCTION_OP = "NIR_INTRINSIC_REDUCTION_OP"
> > +# Cluster size for reduction operations

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 17:33 +0100, Gert Wollny wrote:
> Am Freitag, den 16.03.2018, 12:42 +0100 schrieb Juan A. Suarez Romero:
> > 
> > Gert Wollny (1):
> >   c7cadcbda4 r600: Take ALU_EXTENDED into account when evaluating
> > jump offsets
> > Reason: The commit requires earlier commit a03d456f5a41 which did not
> > land in branch.
> 
> This seems to be odd, a03d456f5a41 is a commit from 2010 that is in the
> 17.3 branch. I think the real reason is 1d871aa626815 because it moves
> the patched code by ~1800 lines so that "git cherry-pick" can't handle
> it anymore. "patch" can handle this propely though.
> 

My fault, indeed.

I'm checking it to try to include it in the final release.


J.A.

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

Re: [Mesa-dev] [PATCH mesa 1/3] egl: add Ozone section to eglplatform.h

[Eric Engestrom]

On March 16, 2018 5:49:12 PM UTC, Emil Velikov  wrote:
> On 16 March 2018 at 15:58, Eric Engestrom 
> wrote:
> > This pulls in commit a93f559e9c11fa53fb5f1cc255b8f75433f85d2a "Add
> Ozone
> > section to eglplatform.h" from Khronos [1] added by Brian Anderson
> [2]
> > a few months ago.
> >
> > [1]
> https://github.com/KhronosGroup/EGL-Registry/commit/a93f559e9c11fa53fb5f1cc255b8f75433f85d2a
> > [2] https://github.com/KhronosGroup/EGL-Registry/pull/26
> >
> > Signed-off-by: Eric Engestrom 
> > ---
> >  include/EGL/eglplatform.h | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
> > index bf9ec0bf5f4fbf7105cd..8a78a9eaddd2f47ff2c0 100644
> > --- a/include/EGL/eglplatform.h
> > +++ b/include/EGL/eglplatform.h
> > @@ -104,6 +104,12 @@ typedef struct ANativeWindow*  
> EGLNativeWindowType;
> >  typedef struct egl_native_pixmap_t* EGLNativePixmapType;
> >  typedef void*   EGLNativeDisplayType;
> >
> > +#elif defined(USE_OZONE)
> > +
> > +typedef intptr_t EGLNativeDisplayType;
> > +typedef intptr_t EGLNativeWindowType;
> > +typedef intptr_t EGLNativePixmapType;
> > +
> Eek, that looks nasty - signed intptr_t insteaf of the default void* +
> uintptr_t.

Yeah, I don't like it either, but it's what Google chose to push.

> 
> Which reminds me - need to join the EGL WG meetings and get
> EGL_USE_PLATFORM_* sorted [1].

Oh, I remember that series, why did you not land it? (The first part of it 
anyway)
Looking forward to "seeing" you on these calls :)

> Until then, the series looks good and is
> 
> Reviewed-by: Emil Velikov 

Thanks!

> 
> -Emil
> 
> [1] https://patchwork.freedesktop.org/series/12778/
> ___
> 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 v0] nir: mako all the intrinsics

[Dylan Baker]

Quoting Rob Clark (2018-03-15 18:43:28)
> I threatened to do this a long time ago.. I probably *should* have done
> it a long time ago when there where many fewer intrinsics.  But the
> system of macro/#include magic for dealing with intrinsics is a bit
> annoying, and python has the nice property of optional fxn params,
> making it possible to define new intrinsics while ignoring parameters
> that are not applicable (and naming optional params).  And not having to
> specify various array lengths explicitly is nice too.
> 
> I think the end result makes it easier to add new intrinsics.
> ---
> I still need to update autotools build.. but it's late and my wrist
> needs a break so I thought I'd send it out as-is to solicit comments
> on the py bits, etc
> 
>  src/compiler/nir/meson.build   |  22 +-
>  src/compiler/nir/nir.h |   9 -
>  src/compiler/nir/nir_builder.h |  27 +-
>  src/compiler/nir/nir_builder_opcodes_h.py  |  24 +-
>  src/compiler/nir/nir_intrinsics.h  | 540 
>  src/compiler/nir/nir_intrinsics.py | 547 
> +
>  .../nir/{nir_intrinsics.c => nir_intrinsics_c.py}  |  56 +--
>  src/compiler/nir/nir_intrinsics_h.py   |  44 ++
>  8 files changed, 659 insertions(+), 610 deletions(-)
>  delete mode 100644 src/compiler/nir/nir_intrinsics.h
>  create mode 100644 src/compiler/nir/nir_intrinsics.py
>  rename src/compiler/nir/{nir_intrinsics.c => nir_intrinsics_c.py} (59%)
>  create mode 100644 src/compiler/nir/nir_intrinsics_h.py
> 
> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
> index a70c236b958..ca9237e2ba3 100644
> --- a/src/compiler/nir/meson.build
> +++ b/src/compiler/nir/meson.build
> @@ -65,6 +65,24 @@ nir_opt_algebraic_c = custom_target(
>depend_files : files('nir_algebraic.py'),
>  )
>  
> +nir_intrinsics_h = custom_target(
> +  'nir_intrinsics.h',
> +  input : 'nir_intrinsics_h.py',
> +  output : 'nir_intrinsics.h',
> +  command : [prog_python2, '@INPUT@'],
> +  capture : true,

Since we're writing a new generator can we not require capture? It has all sorts
of problems if you want to write symbols that an end user's terminal
cannot properly decode. (think UTF-8 for people who refuse to move on from the C
days)

> +  depend_files : files('nir_intrinsics.py'),
> +)

There's an idep_nir_headers in meson that has the other generated headers in it,
this target needs to be added as well.

> +
> +nir_intrinsics_c = custom_target(
> +  'nir_intrinsic.c',
> +  input : 'nir_intrinsics_c.py',
> +  output : 'nir_intrinsics.c',
> +  command : [prog_python2, '@INPUT@'],
> +  capture: true,
> +  depend_files : files('nir_intrinsics.py'),
> +)
> +
>  spirv_info_c = custom_target(
>'spirv_info.c',
>input : files('../spirv/spirv_info_c.py', 
> '../spirv/spirv.core.grammar.json'),
> @@ -96,8 +114,6 @@ files_libnir = files(
>'nir_inline_functions.c',
>'nir_instr_set.c',
>'nir_instr_set.h',
> -  'nir_intrinsics.c',
> -  'nir_intrinsics.h',
>'nir_linking_helpers.c',
>'nir_liveness.c',
>'nir_loop_analyze.c',
> @@ -201,7 +217,7 @@ libnir = static_library(
>'nir',
>[files_libnir, spirv_info_c, nir_opt_algebraic_c, nir_opcodes_c,
> nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
> -   vtn_gather_types_c],
> +   vtn_gather_types_c, nir_intrinsics_c, nir_intrinsics_h],
>include_directories : [inc_common, inc_compiler, 
> include_directories('../spirv')],
>c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
>link_with : libcompiler,
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 1e2ab459bd6..9bcd24a1305 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -945,16 +945,7 @@ typedef struct {
> struct nir_function *callee;
>  } nir_call_instr;
>  
> -#define INTRINSIC(name, num_srcs, src_components, has_dest, dest_components, 
> \
> -  num_variables, num_indices, idx0, idx1, idx2, flags) \
> -   nir_intrinsic_##name,
> -
> -#define LAST_INTRINSIC(name) nir_last_intrinsic = nir_intrinsic_##name,
> -
> -typedef enum {
>  #include "nir_intrinsics.h"
> -   nir_num_intrinsics = nir_last_intrinsic + 1
> -} nir_intrinsic_op;
>  
>  #define NIR_INTRINSIC_MAX_CONST_INDEX 3
>  
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> index 36e0ae3ac63..8f7ddf1483c 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -610,32 +610,7 @@ nir_copy_var(nir_builder *build, nir_variable *dest, 
> nir_variable *src)
> nir_builder_instr_insert(build, >instr);
>  }
>  
> -/* Generic builder for system values. */
> -static inline nir_ssa_def *
> -nir_load_system_value(nir_builder *build, nir_intrinsic_op op, int index)
> -{
> -   nir_intrinsic_instr *load = nir_intrinsic_instr_create(build->shader, op);
> -   load->num_components = 

Re: [Mesa-dev] [PATCH v2 2/2] anv/pipeline: set active_stages early

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 15/03/18 20:09, Caio Marcelo de Oliveira Filho wrote:

Since the intermediate states of active_stages are not used,
i.e. active_stages is read only after all stages were set into it,
just set its value before compiling the shaders.

This will allow to conditionally run certain passes based on what
other shaders are being used, e.g. a certain pass might only be
applicable to the vertex shader if there's no geometry or tessellation
shader being used.

v2: Use vk_to_mesa_shader_stage. (Lionel)
---
  src/intel/vulkan/anv_pipeline.c  | 12 +---
  src/intel/vulkan/genX_pipeline.c |  1 +
  2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index cb34f3be77..4ca1e0be34 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -501,7 +501,6 @@ anv_pipeline_add_compiled_stage(struct anv_pipeline 
*pipeline,
  struct anv_shader_bin *shader)
  {
 pipeline->shaders[stage] = shader;
-   pipeline->active_stages |= mesa_to_vk_shader_stage(stage);
  }
  
  static VkResult

@@ -1334,11 +1333,18 @@ anv_pipeline_init(struct anv_pipeline *pipeline,
 const VkPipelineShaderStageCreateInfo *pStages[MESA_SHADER_STAGES] = {};
 struct anv_shader_module *modules[MESA_SHADER_STAGES] = {};
 for (uint32_t i = 0; i < pCreateInfo->stageCount; i++) {
-  gl_shader_stage stage = ffs(pCreateInfo->pStages[i].stage) - 1;
+  VkShaderStageFlagBits vk_stage = pCreateInfo->pStages[i].stage;
+  gl_shader_stage stage = vk_to_mesa_shader_stage(vk_stage);
pStages[stage] = >pStages[i];
modules[stage] = anv_shader_module_from_handle(pStages[stage]->module);
+  pipeline->active_stages |= vk_stage;
 }
  
+   if (pipeline->active_stages & VK_SHADER_STAGE_TESSELLATION_EVALUATION_BIT)

+  pipeline->active_stages |= VK_SHADER_STAGE_TESSELLATION_CONTROL_BIT;
+
+   assert(pipeline->active_stages & VK_SHADER_STAGE_VERTEX_BIT);
+
 if (modules[MESA_SHADER_VERTEX]) {
result = anv_pipeline_compile_vs(pipeline, cache, pCreateInfo,
 modules[MESA_SHADER_VERTEX],
@@ -1378,7 +1384,7 @@ anv_pipeline_init(struct anv_pipeline *pipeline,
   goto compile_fail;
 }
  
-   assert(pipeline->active_stages & VK_SHADER_STAGE_VERTEX_BIT);

+   assert(pipeline->shaders[MESA_SHADER_VERTEX]);
  
 anv_pipeline_setup_l3_config(pipeline, false);
  
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c

index 9c08bc2033..eb2d414735 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -1787,6 +1787,7 @@ compute_pipeline_create(
 pipeline->needs_data_cache = false;
  
 assert(pCreateInfo->stage.stage == VK_SHADER_STAGE_COMPUTE_BIT);

+   pipeline->active_stages |= VK_SHADER_STAGE_COMPUTE_BIT;
 ANV_FROM_HANDLE(anv_shader_module, module,  pCreateInfo->stage.module);
 result = anv_pipeline_compile_cs(pipeline, cache, pCreateInfo, module,
  pCreateInfo->stage.pName,



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

[Mesa-dev] [Bug 105551] Unable to compile on FreeBSD 9.x and therefore derivatives... undefined reference to `loader_get_extensions_name'

[bugzilla-daemon]

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

--- Comment #1 from Emil Velikov  ---
Something really funky is happening on your system.

A normal thing like:
/bin/sh ../../libtool  --tag=CC   --mode=link gcc48  -O2 -pipe $(includes)
$(warings) $(compiler_f_flags) $(some_rpaths) -o libloader.la  $(some).lo

Results in:
libtool: link: gcc48 -shared  -fPIC -DPIC  ... -Wl,-soname -Wl,libloader.so.0
-o .libs/libloader.so.0.0.0

In the above - -shared and -Wl,-soname should be missing. With the output
filename being libloader.la

Same applies for other static libraries.

A few things to try:
 - remove and/or build w/o LLVM
 - try a simple project which builds a bunch of static libs and links them into
a shared one
 - what is the latest supported Mesa on FreeBSD 9.3, does it build OK?
 - does the latest supported FreeBSD build fine?

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

Re: [Mesa-dev] [PATCH 2/2] anv/pipeline: set active_stages early

[Caio Marcelo de Oliveira Filho]

On Thu, Mar 15, 2018 at 10:31:58AM +, Lionel Landwerlin wrote:
> Looks good, just one tiny nit below.

Fixed that in v2.


> I assume allowing to conditionally run certain passes isn't implemented yet?

That is correct.


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

[Mesa-dev] [PATCH v5 2/2] gallium/winsys/kms: Add support for multi-planes

[Lepton Wu]

Add a new struct kms_sw_plane which delegate a plane and use it
in place of sw_displaytarget. Multiple planes share same underlying
kms_sw_displaytarget.

Change-Id: I0e9ca1d0ba0aa78c27dfdb50c30dc0c424fec172
Signed-off-by: Lepton Wu 
---
 .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 152 +-
 1 file changed, 112 insertions(+), 40 deletions(-)

diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index b4fb852833d..04756ad3073 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -59,13 +59,21 @@
 #define DEBUG_PRINT(msg, ...)
 #endif
 
+struct kms_sw_displaytarget;
 
-struct kms_sw_displaytarget
+struct kms_sw_plane
 {
-   enum pipe_format format;
unsigned width;
unsigned height;
unsigned stride;
+   unsigned offset;
+   struct kms_sw_displaytarget *dt;
+   struct list_head link;
+};
+
+struct kms_sw_displaytarget
+{
+   enum pipe_format format;
unsigned size;
 
uint32_t handle;
@@ -75,6 +83,7 @@ struct kms_sw_displaytarget
int ref_count;
int map_count;
struct list_head link;
+   struct list_head planes;
 };
 
 struct kms_sw_winsys
@@ -85,10 +94,16 @@ struct kms_sw_winsys
struct list_head bo_list;
 };
 
-static inline struct kms_sw_displaytarget *
-kms_sw_displaytarget( struct sw_displaytarget *dt )
+static inline struct kms_sw_plane *
+kms_sw_plane( struct sw_displaytarget *dt )
+{
+   return (struct kms_sw_plane *)dt;
+}
+
+static inline struct sw_displaytarget *
+sw_displaytarget( struct kms_sw_plane *pl)
 {
-   return (struct kms_sw_displaytarget *)dt;
+   return (struct sw_displaytarget *)pl;
 }
 
 static inline struct kms_sw_winsys *
@@ -107,6 +122,39 @@ kms_sw_is_displaytarget_format_supported( struct sw_winsys 
*ws,
return TRUE;
 }
 
+static struct kms_sw_plane *get_plane(struct kms_sw_displaytarget *kms_sw_dt,
+  enum pipe_format format,
+  unsigned width, unsigned height,
+  unsigned stride, unsigned offset)
+{
+   struct kms_sw_plane *plane = NULL;
+
+   if (offset + util_format_get_2d_size(format, stride, height) >
+   kms_sw_dt->size) {
+  DEBUG_PRINT("KMS-DEBUG: plane too big. format: %d stride: %d height: %d "
+  "offset: %d size:%d\n", format, stride, height, offset,
+  kms_sw_dt->size);
+  return NULL;
+   }
+
+   LIST_FOR_EACH_ENTRY(plane, _sw_dt->planes, link) {
+  if (plane->offset == offset)
+ return plane;
+   }
+
+   plane = CALLOC_STRUCT(kms_sw_plane);
+   if (!plane)
+  return NULL;
+
+   plane->width = width;
+   plane->height = height;
+   plane->stride = stride;
+   plane->offset = offset;
+   plane->dt = kms_sw_dt;
+   list_add(>link, _sw_dt->planes);
+   return plane;
+}
+
 static struct sw_displaytarget *
 kms_sw_displaytarget_create(struct sw_winsys *ws,
 unsigned tex_usage,
@@ -126,11 +174,10 @@ kms_sw_displaytarget_create(struct sw_winsys *ws,
if (!kms_sw_dt)
   goto no_dt;
 
+   list_inithead(_sw_dt->planes);
kms_sw_dt->ref_count = 1;
 
kms_sw_dt->format = format;
-   kms_sw_dt->width = width;
-   kms_sw_dt->height = height;
 
memset(_req, 0, sizeof(create_req));
create_req.bpp = 32;
@@ -140,16 +187,19 @@ kms_sw_displaytarget_create(struct sw_winsys *ws,
if (ret)
   goto free_bo;
 
-   kms_sw_dt->stride = create_req.pitch;
kms_sw_dt->size = create_req.size;
kms_sw_dt->handle = create_req.handle;
+   struct kms_sw_plane *plane = get_plane(kms_sw_dt, format, width, height,
+  create_req.pitch, 0);
+   if (!plane)
+  goto free_bo;
 
list_add(_sw_dt->link, _sw->bo_list);
 
DEBUG_PRINT("KMS-DEBUG: created buffer %u (size %u)\n", kms_sw_dt->handle, 
kms_sw_dt->size);
 
-   *stride = kms_sw_dt->stride;
-   return (struct sw_displaytarget *)kms_sw_dt;
+   *stride = create_req.pitch;
+   return sw_displaytarget(plane);
 
  free_bo:
memset(_req, 0, sizeof destroy_req);
@@ -165,7 +215,8 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
  struct sw_displaytarget *dt)
 {
struct kms_sw_winsys *kms_sw = kms_sw_winsys(ws);
-   struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
+   struct kms_sw_plane *plane = kms_sw_plane(dt);
+   struct kms_sw_displaytarget *kms_sw_dt = plane->dt;
struct drm_mode_destroy_dumb destroy_req;
 
kms_sw_dt->ref_count --;
@@ -188,6 +239,11 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
 
DEBUG_PRINT("KMS-DEBUG: destroyed buffer %u\n", kms_sw_dt->handle);
 
+   struct kms_sw_plane *tmp;
+   LIST_FOR_EACH_ENTRY_SAFE(plane, tmp, _sw_dt->planes, link) {
+  FREE(plane);
+   }
+
FREE(kms_sw_dt);
 }
 
@@ -197,7 +253,8 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
  

[Mesa-dev] [PATCH v5 1/2] gallium/winsys/kms: Fix possible leak in map/unmap.

[Lepton Wu]

If user calls map twice for kms_sw_displaytarget, the first mapped
buffer could get leaked. Instead of calling mmap every time, just
reuse previous mapping. Since user could map same displaytarget with
different flags, we have to keep two different pointers, one for rw
mapping and one for ro mapping. Also introduce reference count for
mapped buffer so we can unmap them at right time.

Change-Id: I65308f0ff2640bd57b2577c6a3469540c9722859
Signed-off-by: Lepton Wu 
---
 .../winsys/sw/kms-dri/kms_dri_sw_winsys.c | 44 +++
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c 
b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
index 22e1c936ac5..b4fb852833d 100644
--- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
+++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
@@ -70,8 +70,10 @@ struct kms_sw_displaytarget
 
uint32_t handle;
void *mapped;
+   void *ro_mapped;
 
int ref_count;
+   int map_count;
struct list_head link;
 };
 
@@ -170,6 +172,14 @@ kms_sw_displaytarget_destroy(struct sw_winsys *ws,
if (kms_sw_dt->ref_count > 0)
   return;
 
+   if (kms_sw_dt->map_count > 0) {
+  DEBUG_PRINT("KMS-DEBUG: fix leaked map buffer %u\n", kms_sw_dt->handle);
+  munmap(kms_sw_dt->mapped, kms_sw_dt->size);
+  kms_sw_dt->mapped = NULL;
+  munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
+  kms_sw_dt->ro_mapped = NULL;
+   }
+
memset(_req, 0, sizeof destroy_req);
destroy_req.handle = kms_sw_dt->handle;
drmIoctl(kms_sw->fd, DRM_IOCTL_MODE_DESTROY_DUMB, _req);
@@ -198,16 +208,21 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
   return NULL;
 
prot = (flags == PIPE_TRANSFER_READ) ? PROT_READ : (PROT_READ | PROT_WRITE);
-   kms_sw_dt->mapped = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
-kms_sw->fd, map_req.offset);
-
-   if (kms_sw_dt->mapped == MAP_FAILED)
-  return NULL;
+   void **ptr = (flags == PIPE_TRANSFER_READ) ? _sw_dt->ro_mapped : 
_sw_dt->mapped;
+   if (!*ptr) {
+  void *tmp = mmap(0, kms_sw_dt->size, prot, MAP_SHARED,
+   kms_sw->fd, map_req.offset);
+  if (tmp == MAP_FAILED)
+ return NULL;
+  *ptr = tmp;
+   }
 
DEBUG_PRINT("KMS-DEBUG: mapped buffer %u (size %u) at %p\n",
- kms_sw_dt->handle, kms_sw_dt->size, kms_sw_dt->mapped);
+ kms_sw_dt->handle, kms_sw_dt->size, *ptr);
+
+   kms_sw_dt->map_count++;
 
-   return kms_sw_dt->mapped;
+   return *ptr;
 }
 
 static struct kms_sw_displaytarget *
@@ -277,10 +292,23 @@ kms_sw_displaytarget_unmap(struct sw_winsys *ws,
 {
struct kms_sw_displaytarget *kms_sw_dt = kms_sw_displaytarget(dt);
 
-   DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", kms_sw_dt->handle, 
kms_sw_dt->mapped);
+   if (!kms_sw_dt->map_count)  {
+  DEBUG_PRINT("KMS-DEBUG: ignore duplicated unmap %u", kms_sw_dt->handle);
+  return;
+   }
+   kms_sw_dt->map_count--;
+   if (kms_sw_dt->map_count) {
+  DEBUG_PRINT("KMS-DEBUG: ignore unmap for busy buffer %u", 
kms_sw_dt->handle);
+  return;
+   }
 
+   DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", kms_sw_dt->handle, 
kms_sw_dt->mapped);
+   DEBUG_PRINT("KMS-DEBUG: unmapped buffer %u (was %p)\n", kms_sw_dt->handle, 
kms_sw_dt->ro_mapped);
+ 
munmap(kms_sw_dt->mapped, kms_sw_dt->size);
kms_sw_dt->mapped = NULL;
+   munmap(kms_sw_dt->ro_mapped, kms_sw_dt->size);
+   kms_sw_dt->ro_mapped = NULL;
 }
 
 static struct sw_displaytarget *
-- 
2.16.2.804.g6dcf76e118-goog

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

[Mesa-dev] [PATCH 2/2] intel/compiler: Use gen_get_device_info() in test_eu_validate

[Matt Turner]

Previously the unit test filled out a minimal devinfo struct. A previous
patch caused the test to begin assert failing because the devinfo was
not complete. Avoid this by using the real mechanism to create devinfo.

Note that we have to drop icl from the table, since we now rely on the
name -> PCI ID translation done by gen_device_name_to_pci_device_id(),
and ICL's PCI IDs are not upstream yet.

Fixes: f89e735719a6 ("intel/compiler: Check for unsupported register sizes.")
---
 src/intel/Makefile.compiler.am  |  1 +
 src/intel/compiler/meson.build  |  2 +-
 src/intel/compiler/test_eu_validate.cpp | 55 ++---
 3 files changed, 19 insertions(+), 39 deletions(-)

diff --git a/src/intel/Makefile.compiler.am b/src/intel/Makefile.compiler.am
index 45e7a6ccce8..af30a58a1d6 100644
--- a/src/intel/Makefile.compiler.am
+++ b/src/intel/Makefile.compiler.am
@@ -48,6 +48,7 @@ TEST_LIBS = \
$(top_builddir)/src/gtest/libgtest.la \
compiler/libintel_compiler.la \
common/libintel_common.la \
+   dev/libintel_dev.la \
$(top_builddir)/src/compiler/nir/libnir.la \
$(top_builddir)/src/util/libmesautil.la \
$(top_builddir)/src/intel/isl/libisl.la \
diff --git a/src/intel/compiler/meson.build b/src/intel/compiler/meson.build
index 602206c725f..72b7a6796cb 100644
--- a/src/intel/compiler/meson.build
+++ b/src/intel/compiler/meson.build
@@ -152,7 +152,7 @@ if with_tests
 'test_@0@.cpp'.format(t),
 include_directories : [inc_common, inc_intel],
 link_with : [
-  libintel_compiler, libintel_common, libmesa_util, libisl,
+  libintel_compiler, libintel_common, libintel_dev, libmesa_util, 
libisl,
 ],
 dependencies : [dep_thread, dep_dl, idep_gtest, idep_nir],
   )
diff --git a/src/intel/compiler/test_eu_validate.cpp 
b/src/intel/compiler/test_eu_validate.cpp
index d987311ef84..161db994b2b 100644
--- a/src/intel/compiler/test_eu_validate.cpp
+++ b/src/intel/compiler/test_eu_validate.cpp
@@ -25,38 +25,24 @@
 #include "brw_eu.h"
 #include "util/ralloc.h"
 
-enum subgen {
-   IS_G45 = 1,
-   IS_BYT,
-   IS_HSW,
-   IS_CHV,
-   IS_BXT,
-   IS_KBL,
-   IS_GLK,
-   IS_CFL,
-};
-
 static const struct gen_info {
const char *name;
-   int gen;
-   enum subgen subgen;
 } gens[] = {
-   { "brw", 4 },
-   { "g45", 4, IS_G45 },
-   { "ilk", 5 },
-   { "snb", 6 },
-   { "ivb", 7 },
-   { "byt", 7, IS_BYT },
-   { "hsw", 7, IS_HSW },
-   { "bdw", 8 },
-   { "chv", 8, IS_CHV },
-   { "skl", 9 },
-   { "bxt", 9, IS_BXT },
-   { "kbl", 9, IS_KBL },
-   { "glk", 9, IS_GLK },
-   { "cfl", 9, IS_CFL },
-   { "cnl", 10 },
-   { "icl", 11 },
+   { "brw", },
+   { "g4x", },
+   { "ilk", },
+   { "snb", },
+   { "ivb", },
+   { "byt", },
+   { "hsw", },
+   { "bdw", },
+   { "chv", },
+   { "skl", },
+   { "bxt", },
+   { "kbl", },
+   { "glk", },
+   { "cfl", },
+   { "cnl", },
 };
 
 class validation_test: public ::testing::TestWithParam {
@@ -84,16 +70,9 @@ validation_test::~validation_test()
 void validation_test::SetUp()
 {
struct gen_info info = GetParam();
+   int devid = gen_device_name_to_pci_device_id(info.name);
 
-   devinfo.gen   = info.gen;
-   devinfo.is_g4x= info.subgen == IS_G45;
-   devinfo.is_baytrail   = info.subgen == IS_BYT;
-   devinfo.is_haswell= info.subgen == IS_HSW;
-   devinfo.is_cherryview = info.subgen == IS_CHV;
-   devinfo.is_broxton= info.subgen == IS_BXT;
-   devinfo.is_kabylake   = info.subgen == IS_KBL;
-   devinfo.is_geminilake = info.subgen == IS_GLK;
-   devinfo.is_coffeelake = info.subgen == IS_CFL;
+   gen_get_device_info(devid, );
 
brw_init_codegen(, p, p);
 }
-- 
2.16.1

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

[Mesa-dev] [PATCH 1/2] intel: Add cfl to gen_device_name_to_pci_device_id()

[Matt Turner]

---
 src/intel/dev/gen_device_info.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 1773009d33c..3365bdd4dd6 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -55,6 +55,7 @@ gen_device_name_to_pci_device_id(const char *name)
   { "bxt", 0x5A85 },
   { "kbl", 0x5912 },
   { "glk", 0x3185 },
+  { "cfl", 0x3E9B },
   { "cnl", 0x5a52 },
   { "icl", 0x8a52 },
};
-- 
2.16.1

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

Re: [Mesa-dev] [PATCH mesa 1/3] egl: add Ozone section to eglplatform.h

[Emil Velikov]

On 16 March 2018 at 15:58, Eric Engestrom  wrote:
> This pulls in commit a93f559e9c11fa53fb5f1cc255b8f75433f85d2a "Add Ozone
> section to eglplatform.h" from Khronos [1] added by Brian Anderson [2]
> a few months ago.
>
> [1] 
> https://github.com/KhronosGroup/EGL-Registry/commit/a93f559e9c11fa53fb5f1cc255b8f75433f85d2a
> [2] https://github.com/KhronosGroup/EGL-Registry/pull/26
>
> Signed-off-by: Eric Engestrom 
> ---
>  include/EGL/eglplatform.h | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
> index bf9ec0bf5f4fbf7105cd..8a78a9eaddd2f47ff2c0 100644
> --- a/include/EGL/eglplatform.h
> +++ b/include/EGL/eglplatform.h
> @@ -104,6 +104,12 @@ typedef struct ANativeWindow*   
> EGLNativeWindowType;
>  typedef struct egl_native_pixmap_t* EGLNativePixmapType;
>  typedef void*   EGLNativeDisplayType;
>
> +#elif defined(USE_OZONE)
> +
> +typedef intptr_t EGLNativeDisplayType;
> +typedef intptr_t EGLNativeWindowType;
> +typedef intptr_t EGLNativePixmapType;
> +
Eek, that looks nasty - signed intptr_t insteaf of the default void* +
uintptr_t.

Which reminds me - need to join the EGL WG meetings and get
EGL_USE_PLATFORM_* sorted [1].
Until then, the series looks good and is

Reviewed-by: Emil Velikov 

-Emil

[1] https://patchwork.freedesktop.org/series/12778/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 17:39 +, Emil Velikov wrote:
> On 16 March 2018 at 16:56, Mark Janes  wrote:
> > "Juan A. Suarez Romero"  writes:
> > 
> > > On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote:
> > > > On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
> > > >  wrote:
> > > > > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
> > > > > > On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
> > > > > >  wrote:
> > > > > > > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
> > > > > > > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
> > > > > > > >  wrote:
> > > > > > > > > Nominated means that these patches does not enter in this 
> > > > > > > > > release due they
> > > > > > > > > arrived a bit late, but they are proposed to cherry-pick them 
> > > > > > > > > for the next
> > > > > > > > > release (in 1 or 2 weeks).
> > > > > > > > > 
> > > > > > > > > The reason is that some days before this pre-announcement is 
> > > > > > > > > sent, we close the
> > > > > > > > > list of patches that enter in the release, and we do a lot of 
> > > > > > > > > testing to verify
> > > > > > > > > nothing is broken). If there's some regression, we just try 
> > > > > > > > > to fix them. And
> > > > > > > > > when everything is ready, we send the pre-announcement email.
> > > > > > > > > 
> > > > > > > > > The nominated patches are those that arrive after we close 
> > > > > > > > > the list, and we are
> > > > > > > > > under the testing process. As we don't want to restart the 
> > > > > > > > > full process again
> > > > > > > > > and again, we just nominate them for the next release. 
> > > > > > > > > Otherwise that would
> > > > > > > > > delay the release too much.
> > > > > > > > 
> > > > > > > > Why not send the pre-announcement right when it's closed? Since 
> > > > > > > > your
> > > > > > > > testing doesn't cover all drivers, shouldn't everyone just be 
> > > > > > > > able to
> > > > > > > > test at the same time, and then be able to add to the existing 
> > > > > > > > list
> > > > > > > > with additional fixes (or removals of picked commits)?
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Because we want to propose a release candidate that has been 
> > > > > > > tested as much as
> > > > > > > possible, to avoid bothering people with a proposal that we need 
> > > > > > > to change
> > > > > > > because it is causing regressions (and believe me this is quite 
> > > > > > > common). So we
> > > > > > > do different tests, thanks to Intel CI which covers a lot of 
> > > > > > > tests and
> > > > > > > configurations, before doing the pre-announcement.
> > > > > > > 
> > > > > > > Note that between we start the testing and do the 
> > > > > > > pre-announcement there is a
> > > > > > > difference of few hours, and hence the list of nominated patches 
> > > > > > > is quite
> > > > > > > reduced (either none, or a couple of them). This time wasn't the 
> > > > > > > case, and it
> > > > > > > took some days. But it is not the usual case.
> > > > > > 
> > > > > > Hm. It feels like it's the usual case. Perhaps it's not meant to be.
> > > > > > Why not just pick up all the nominated patches right before you do 
> > > > > > the
> > > > > > couple hours of testing?
> > > > > > 
> > > > > 
> > > > > That is what we do. We pick up all the patches until the last minute, 
> > > > > just
> > > > > before starting the test. And as soon as we verify it is correct, we 
> > > > > write and
> > > > > send the pre-announcement email.
> > > > 
> > > > Then why can it be days in between? If the tests get delayed/messed
> > > > up/have to be done over again, just pick up all the nominated patches
> > > > and go again.
> > > > 
> > > 
> > > I think that days is very infrequent, and due exceptionally reasons. 
> > > Usually
> > > less than a day, and mainly due different time zones.
> > 
> > Examples of issues that can delay CI confirmation of the stable branch:
> > 
> >  - Regressions detected in the proposed release, which need to be
> >bisected, fixed, and retested.
> > 
> >  - Intel CI downtime.  This can be due to lab maintenance, or
> >instability with systems.
> > 
> > In this release iteration, we encountered both of these issues.  The
> > first proposed 17.3.7 was broken, as was the first fix after bisect.
> > Resolving the issue was delayed because we upgraded CI to Linux 4.14 to
> > support Vulkan 1.1, and that kernel has a bug that impacted our results.
> > 
> 
> I think with some of the proposed changes, we can attribute for those,
> while keeping other teams happy.
> 


Right. I'm checking the nominated patches, as well as Greg's rejected one, to
propose to enqueue them in the final release (of course, after checking
everything works fine).


J.A.

> -Emil
> 
___
mesa-dev mailing list

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Emil Velikov]

On 16 March 2018 at 16:56, Mark Janes  wrote:
> "Juan A. Suarez Romero"  writes:
>
>> On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote:
>>> On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
>>>  wrote:
>>> > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
>>> > > On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
>>> > >  wrote:
>>> > > > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
>>> > > > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
>>> > > > >  wrote:
>>> > > > > > Nominated means that these patches does not enter in this release 
>>> > > > > > due they
>>> > > > > > arrived a bit late, but they are proposed to cherry-pick them for 
>>> > > > > > the next
>>> > > > > > release (in 1 or 2 weeks).
>>> > > > > >
>>> > > > > > The reason is that some days before this pre-announcement is 
>>> > > > > > sent, we close the
>>> > > > > > list of patches that enter in the release, and we do a lot of 
>>> > > > > > testing to verify
>>> > > > > > nothing is broken). If there's some regression, we just try to 
>>> > > > > > fix them. And
>>> > > > > > when everything is ready, we send the pre-announcement email.
>>> > > > > >
>>> > > > > > The nominated patches are those that arrive after we close the 
>>> > > > > > list, and we are
>>> > > > > > under the testing process. As we don't want to restart the full 
>>> > > > > > process again
>>> > > > > > and again, we just nominate them for the next release. Otherwise 
>>> > > > > > that would
>>> > > > > > delay the release too much.
>>> > > > >
>>> > > > > Why not send the pre-announcement right when it's closed? Since your
>>> > > > > testing doesn't cover all drivers, shouldn't everyone just be able 
>>> > > > > to
>>> > > > > test at the same time, and then be able to add to the existing list
>>> > > > > with additional fixes (or removals of picked commits)?
>>> > > > >
>>> > > >
>>> > > >
>>> > > > Because we want to propose a release candidate that has been tested 
>>> > > > as much as
>>> > > > possible, to avoid bothering people with a proposal that we need to 
>>> > > > change
>>> > > > because it is causing regressions (and believe me this is quite 
>>> > > > common). So we
>>> > > > do different tests, thanks to Intel CI which covers a lot of tests and
>>> > > > configurations, before doing the pre-announcement.
>>> > > >
>>> > > > Note that between we start the testing and do the pre-announcement 
>>> > > > there is a
>>> > > > difference of few hours, and hence the list of nominated patches is 
>>> > > > quite
>>> > > > reduced (either none, or a couple of them). This time wasn't the 
>>> > > > case, and it
>>> > > > took some days. But it is not the usual case.
>>> > >
>>> > > Hm. It feels like it's the usual case. Perhaps it's not meant to be.
>>> > > Why not just pick up all the nominated patches right before you do the
>>> > > couple hours of testing?
>>> > >
>>> >
>>> > That is what we do. We pick up all the patches until the last minute, just
>>> > before starting the test. And as soon as we verify it is correct, we 
>>> > write and
>>> > send the pre-announcement email.
>>>
>>> Then why can it be days in between? If the tests get delayed/messed
>>> up/have to be done over again, just pick up all the nominated patches
>>> and go again.
>>>
>>
>> I think that days is very infrequent, and due exceptionally reasons. Usually
>> less than a day, and mainly due different time zones.
>
> Examples of issues that can delay CI confirmation of the stable branch:
>
>  - Regressions detected in the proposed release, which need to be
>bisected, fixed, and retested.
>
>  - Intel CI downtime.  This can be due to lab maintenance, or
>instability with systems.
>
> In this release iteration, we encountered both of these issues.  The
> first proposed 17.3.7 was broken, as was the first fix after bisect.
> Resolving the issue was delayed because we upgraded CI to Linux 4.14 to
> support Vulkan 1.1, and that kernel has a bug that impacted our results.
>
I think with some of the proposed changes, we can attribute for those,
while keeping other teams happy.

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

Re: [Mesa-dev] [PATCH 0/6] Shader cache; transform feedback; i965 program-binary

[Jordan Justen]

On 2018-03-16 04:52:55, Tapani Pälli wrote:
> 
> 
> On 03/15/2018 11:07 AM, Tapani Pälli wrote:
> > Patches 1-3:
> > Reviewed-by: Tapani Pälli 
> 
> Make that the whole series!

Thanks!

> I tested also briefly with app that uses glProgramBinary to implement 
> cache and verified result of GL_LINK_STATUS query with glGetProgramiv 
> after glProgramBinary.

If the app saves/loads the binary to a file, then you might see a
difference in the output for the second run when MESA_GLSL=cache_info
is set. (Before it would always say "Falling back to NIR")

-Jordan

> 
> > (also verified with xfb using app)
> > 
> > On 03/14/2018 09:26 AM, Jordan Justen wrote:
> >> git://people.freedesktop.org/~jljusten/mesa 
> >> shader-cache-xform-fb+prog-bin-v1
> >>
> >> Patches 1 - 3 remove the restriction preventing the disk shader cache
> >> from being enabled if transform feedback is enabled via the GL API.
> >> These patches affect all drivers that support shader cache.
> >>
> >> Patches 4 - 6 address an issue I found with i965 when running DOTA2
> >> with the shader cache enabled. It appears that if the shader cache is
> >> enabled, we will never use the shader cache for programs loaded with
> >> ProgramBinary.
> >>
> >> We had been setting the LinkStatus to LINKING_SUCCESS, and previously
> >> i965 would skip using the shader cache if the LinkStatus wasn't
> >> LINKING_SKIPPED. Either patch 5 or 6 should address this, but I think
> >> 6 still makes sense.
> >>
> >> I sent out a related series on Sunday. It turned out that series
> >> triggered issues where if ProgramBinary was used, and transform
> >> feedback was enabled. For this reason, I looked into the transform
> >> feedback limitation addressed in patches 1 - 3.
> >>
> >> Jordan Justen (6):
> >>    glsl/shader_cache: Allow shader cache usage with transform feedback
> >>    i965: Allow disk shader cache usage with transform feedback
> >>    glsl: Remove api_enabled tracking for transform feedback
> >>    glsl/serialize: Save shader program metadata sha1
> >>    i965: Allow disk shader cache usage with LINKING_SUCCESS status
> >>    main/program_binary: In ProgramBinary set link status as
> >>  LINKING_SKIPPED
> >>
> >>   src/compiler/glsl/link_varyings.cpp    |  2 --
> >>   src/compiler/glsl/linker.cpp   | 11 +--
> >>   src/compiler/glsl/serialize.cpp    |  4 
> >>   src/compiler/glsl/shader_cache.cpp |  6 ++
> >>   src/mesa/drivers/dri/i965/brw_disk_cache.c | 11 ---
> >>   src/mesa/main/mtypes.h |  3 ---
> >>   src/mesa/main/program_binary.c |  2 +-
> >>   7 files changed, 12 insertions(+), 27 deletions(-)
> >>
> > ___
> > 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] [ANNOUNCE] Mesa 17.3.7 release candidate

[Mark Janes]

"Juan A. Suarez Romero"  writes:

> On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote:
>> On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
>>  wrote:
>> > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
>> > > On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
>> > >  wrote:
>> > > > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
>> > > > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
>> > > > >  wrote:
>> > > > > > Nominated means that these patches does not enter in this release 
>> > > > > > due they
>> > > > > > arrived a bit late, but they are proposed to cherry-pick them for 
>> > > > > > the next
>> > > > > > release (in 1 or 2 weeks).
>> > > > > > 
>> > > > > > The reason is that some days before this pre-announcement is sent, 
>> > > > > > we close the
>> > > > > > list of patches that enter in the release, and we do a lot of 
>> > > > > > testing to verify
>> > > > > > nothing is broken). If there's some regression, we just try to fix 
>> > > > > > them. And
>> > > > > > when everything is ready, we send the pre-announcement email.
>> > > > > > 
>> > > > > > The nominated patches are those that arrive after we close the 
>> > > > > > list, and we are
>> > > > > > under the testing process. As we don't want to restart the full 
>> > > > > > process again
>> > > > > > and again, we just nominate them for the next release. Otherwise 
>> > > > > > that would
>> > > > > > delay the release too much.
>> > > > > 
>> > > > > Why not send the pre-announcement right when it's closed? Since your
>> > > > > testing doesn't cover all drivers, shouldn't everyone just be able to
>> > > > > test at the same time, and then be able to add to the existing list
>> > > > > with additional fixes (or removals of picked commits)?
>> > > > > 
>> > > > 
>> > > > 
>> > > > Because we want to propose a release candidate that has been tested as 
>> > > > much as
>> > > > possible, to avoid bothering people with a proposal that we need to 
>> > > > change
>> > > > because it is causing regressions (and believe me this is quite 
>> > > > common). So we
>> > > > do different tests, thanks to Intel CI which covers a lot of tests and
>> > > > configurations, before doing the pre-announcement.
>> > > > 
>> > > > Note that between we start the testing and do the pre-announcement 
>> > > > there is a
>> > > > difference of few hours, and hence the list of nominated patches is 
>> > > > quite
>> > > > reduced (either none, or a couple of them). This time wasn't the case, 
>> > > > and it
>> > > > took some days. But it is not the usual case.
>> > > 
>> > > Hm. It feels like it's the usual case. Perhaps it's not meant to be.
>> > > Why not just pick up all the nominated patches right before you do the
>> > > couple hours of testing?
>> > > 
>> > 
>> > That is what we do. We pick up all the patches until the last minute, just
>> > before starting the test. And as soon as we verify it is correct, we write 
>> > and
>> > send the pre-announcement email.
>> 
>> Then why can it be days in between? If the tests get delayed/messed
>> up/have to be done over again, just pick up all the nominated patches
>> and go again.
>> 
>
> I think that days is very infrequent, and due exceptionally reasons. Usually
> less than a day, and mainly due different time zones.

Examples of issues that can delay CI confirmation of the stable branch:

 - Regressions detected in the proposed release, which need to be
   bisected, fixed, and retested.

 - Intel CI downtime.  This can be due to lab maintenance, or
   instability with systems.

In this release iteration, we encountered both of these issues.  The
first proposed 17.3.7 was broken, as was the first fix after bisect.
Resolving the issue was delayed because we upgraded CI to Linux 4.14 to
support Vulkan 1.1, and that kernel has a bug that impacted our results.

> If we detect issues in the branch under testing, and we need to prepare a new
> one, usually I include all the new stable patches that arrived as part of the
> new queue to test. So we try to test all the nominated patches.
>
> Of course, if a new patch arrives after the testing started, and the test
> success, we just send the announcement, putting the patch as Nominated in the
> email. Because we don't want to start again, as it always arrives patches, and
> we want to avoid delaying the release.
>
>
>> > > > And finally, that is the reason why there is a couple of days between 
>> > > > the pre-
>> > > > announcement and the final announcement: for people to do more tests 
>> > > > with
>> > > > different configurations, and propose inclusions/removals.
>> > > 
>> > > What are the criteria for such inclusions? (Why do the nominated
>> > > patches not meet them?) IME such requests for inclusion are met with
>> > > "next release" replies (or "never").
>> > > 
>> > 
>> > I think this depends on the authors, and how 

[Mesa-dev] [Bug 105208] [regression] (e5ff036c67 st/dri: Add support for BGR[A/X]1010102 formats) broke the mouse in mutter/shell

[bugzilla-daemon]

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

Yanko Kaneti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #5 from Yanko Kaneti  ---
As far as mutter/shell go this bug is fixed there. I'll close.

If somebody needs to continue the "flip the 10-bit default" discussion, perhaps
its better if it continues somewhere else.

Thanks

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

Re: [Mesa-dev] [PATCH v2 3/7] nir: lower 64bit subgroup shuffle intrinsics

[Jason Ekstrand]

On Fri, Mar 16, 2018 at 2:50 AM, Daniel Schürmann <
daniel.schuerm...@campus.tu-berlin.de> wrote:

> Signed-off-by: Daniel Schürmann 
> ---
>  src/compiler/nir/nir.h |  1 +
>  src/compiler/nir/nir_lower_subgroups.c | 83
> +++---
>  2 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
> index 6a51b7c4ab..0e3c026efa 100644
> --- a/src/compiler/nir/nir.h
> +++ b/src/compiler/nir/nir.h
> @@ -2564,6 +2564,7 @@ typedef struct nir_lower_subgroups_options {
> bool lower_vote_eq_to_ballot:1;
> bool lower_subgroup_masks:1;
> bool lower_shuffle:1;
> +   bool lower_shuffle_to_32bit:1;
> bool lower_quad:1;
>  } nir_lower_subgroups_options;
>
> diff --git a/src/compiler/nir/nir_lower_subgroups.c
> b/src/compiler/nir/nir_lower_subgroups.c
> index 9dc7be7947..669168e830 100644
> --- a/src/compiler/nir/nir_lower_subgroups.c
> +++ b/src/compiler/nir/nir_lower_subgroups.c
> @@ -28,6 +28,37 @@
>   * \file nir_opt_intrinsics.c
>   */
>
> +static nir_intrinsic_instr 
> *ac_lower_subgroups_64bit_split_intrinsic(nir_builder
> *b, nir_intrinsic_instr *intrin, unsigned int component) {
>

Please put "static nir_intrinsic_instr *" and the "{" each on their own
line and wrap things so that we don't go over 80 characters.  Also, please
drop the ac_ prefix as this is no longer in radv code.


> +   nir_ssa_def *comp;
> +   if (component == 0)
> +  comp = nir_unpack_64_2x32_split_x(b, intrin->src[0].ssa);
> +   else
> +  comp = nir_unpack_64_2x32_split_y(b, intrin->src[0].ssa);
> +
> +   nir_intrinsic_instr *intr = nir_intrinsic_instr_create(b->shader,
> intrin->intrinsic);
> +   nir_ssa_dest_init(>instr, >dest, 1, 32, NULL);
> +   intr->src[0] = nir_src_for_ssa(comp);
> +
> +   intr->const_index[0] = intrin->const_index[0];
> +   intr->const_index[1] = intrin->const_index[1];
> +   if (intrin->intrinsic == nir_intrinsic_read_invocation ||
> +  intrin->intrinsic == nir_intrinsic_shuffle ||
> +  intrin->intrinsic == nir_intrinsic_quad_broadcast) {
>

You can use nir_intrinsic_infos[intrin->intrinsic].num_srcs to make this a
bit more general.


> +  nir_src_copy(>src[1], >src[1], intr);
> +   }
> +   intr->num_components = 1;
> +   nir_builder_instr_insert(b, >instr);
> +   return intr;
> +}
> +
> +static nir_ssa_def *
> +lower_64bit_to_32bit(nir_builder *b, nir_intrinsic_instr *intrin) {


"{" goes on it's own line.  Also, how about "lower_subgroup_op_to_32bit" to
match "lower_subgroup_op_to_scalar" below.


> +   assert(intrin->src[0].ssa->bit_size == 64);
> +   nir_intrinsic_instr *intr_x = ac_lower_subgroups_64bit_split_intrinsic(b,
> intrin, 0);
> +   nir_intrinsic_instr *intr_y = ac_lower_subgroups_64bit_split_intrinsic(b,
> intrin, 1);
> +   return nir_pack_64_2x32_split(b, _x->dest.ssa, _y->dest.ssa);
> +}
> +
>  static nir_ssa_def *
>  ballot_type_to_uint(nir_builder *b, nir_ssa_def *value, unsigned
> bit_size)
>  {
> @@ -80,7 +111,8 @@ uint_to_ballot_type(nir_builder *b, nir_ssa_def *value,
>  }
>
>  static nir_ssa_def *
> -lower_subgroup_op_to_scalar(nir_builder *b, nir_intrinsic_instr *intrin)
> +lower_subgroup_op_to_scalar(nir_builder *b, nir_intrinsic_instr *intrin,
> +bool lower_shuffle_to_32bit)
>

Just call this lower_to_32bit as it doesn't necessarily have anything to do
with shuffles.  Also, please align the parameter to the (


>  {
> /* This is safe to call on scalar things but it would be silly */
> assert(intrin->dest.ssa.num_components > 1);
> @@ -107,9 +139,12 @@ lower_subgroup_op_to_scalar(nir_builder *b,
> nir_intrinsic_instr *intrin)
>chan_intrin->const_index[0] = intrin->const_index[0];
>chan_intrin->const_index[1] = intrin->const_index[1];
>
> -  nir_builder_instr_insert(b, _intrin->instr);
> -
> -  reads[i] = _intrin->dest.ssa;
> +  if (lower_shuffle_to_32bit && chan_intrin->src[0].ssa->bit_size ==
> 64) {
> + reads[i] = lower_64bit_to_32bit(b, chan_intrin);
> +  } else {
> + nir_builder_instr_insert(b, _intrin->instr);
> + reads[i] = _intrin->dest.ssa;
> +  }
> }
>
> return nir_vec(b, reads, intrin->num_components);
> @@ -158,13 +193,19 @@ lower_vote_eq_to_ballot(nir_builder *b,
> nir_intrinsic_instr *intrin,
>  1, value->bit_size, NULL);
>rfi->num_components = 1;
>rfi->src[0] = nir_src_for_ssa(nir_channel(b, value, i));
> -  nir_builder_instr_insert(b, >instr);
> +  nir_ssa_def *first_lane;
> +  if (options->lower_shuffle_to_32bit && rfi->src[0].ssa->bit_size
> == 64) {
>

I don't really see how read_first_invocation is related to shuffles


> + first_lane = lower_64bit_to_32bit(b, rfi);
> +  } else {
> + nir_builder_instr_insert(b, >instr);
> + first_lane = >dest.ssa;
> +  }
>
>nir_ssa_def *is_eq;
>if (intrin->intrinsic == 

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Gert Wollny]

Am Freitag, den 16.03.2018, 12:42 +0100 schrieb Juan A. Suarez Romero:
> 
> Gert Wollny (1):
>   c7cadcbda4 r600: Take ALU_EXTENDED into account when evaluating
> jump offsets
> Reason: The commit requires earlier commit a03d456f5a41 which did not
> land in branch.
This seems to be odd, a03d456f5a41 is a commit from 2010 that is in the
17.3 branch. I think the real reason is 1d871aa626815 because it moves
the patched code by ~1800 lines so that "git cherry-pick" can't handle
it anymore. "patch" can handle this propely though.

Best, 
Gert 

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

[Mesa-dev] [Bug 105232] piglit regressions and crashes from gbm alpha masks

[bugzilla-daemon]

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

--- Comment #2 from Daniel Stone  ---
(In reply to Ilia Mirkin from comment #1)
> Theory: The tests didn't run prior to this commit because of the format
> matching fail, since the original commit that broke argb8 formats,
> 2ed344645d65. They have now started running again and are as broken now as
> they were prior to that commit.
> 
> Mark, does that theory hold water?

Any idea?

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 12:03 -0400, Ilia Mirkin wrote:
> On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
>  wrote:
> > On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
> > > On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
> > >  wrote:
> > > > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
> > > > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
> > > > >  wrote:
> > > > > > Nominated means that these patches does not enter in this release 
> > > > > > due they
> > > > > > arrived a bit late, but they are proposed to cherry-pick them for 
> > > > > > the next
> > > > > > release (in 1 or 2 weeks).
> > > > > > 
> > > > > > The reason is that some days before this pre-announcement is sent, 
> > > > > > we close the
> > > > > > list of patches that enter in the release, and we do a lot of 
> > > > > > testing to verify
> > > > > > nothing is broken). If there's some regression, we just try to fix 
> > > > > > them. And
> > > > > > when everything is ready, we send the pre-announcement email.
> > > > > > 
> > > > > > The nominated patches are those that arrive after we close the 
> > > > > > list, and we are
> > > > > > under the testing process. As we don't want to restart the full 
> > > > > > process again
> > > > > > and again, we just nominate them for the next release. Otherwise 
> > > > > > that would
> > > > > > delay the release too much.
> > > > > 
> > > > > Why not send the pre-announcement right when it's closed? Since your
> > > > > testing doesn't cover all drivers, shouldn't everyone just be able to
> > > > > test at the same time, and then be able to add to the existing list
> > > > > with additional fixes (or removals of picked commits)?
> > > > > 
> > > > 
> > > > 
> > > > Because we want to propose a release candidate that has been tested as 
> > > > much as
> > > > possible, to avoid bothering people with a proposal that we need to 
> > > > change
> > > > because it is causing regressions (and believe me this is quite 
> > > > common). So we
> > > > do different tests, thanks to Intel CI which covers a lot of tests and
> > > > configurations, before doing the pre-announcement.
> > > > 
> > > > Note that between we start the testing and do the pre-announcement 
> > > > there is a
> > > > difference of few hours, and hence the list of nominated patches is 
> > > > quite
> > > > reduced (either none, or a couple of them). This time wasn't the case, 
> > > > and it
> > > > took some days. But it is not the usual case.
> > > 
> > > Hm. It feels like it's the usual case. Perhaps it's not meant to be.
> > > Why not just pick up all the nominated patches right before you do the
> > > couple hours of testing?
> > > 
> > 
> > That is what we do. We pick up all the patches until the last minute, just
> > before starting the test. And as soon as we verify it is correct, we write 
> > and
> > send the pre-announcement email.
> 
> Then why can it be days in between? If the tests get delayed/messed
> up/have to be done over again, just pick up all the nominated patches
> and go again.
> 

I think that days is very infrequent, and due exceptionally reasons. Usually
less than a day, and mainly due different time zones.


If we detect issues in the branch under testing, and we need to prepare a new
one, usually I include all the new stable patches that arrived as part of the
new queue to test. So we try to test all the nominated patches.

Of course, if a new patch arrives after the testing started, and the test
success, we just send the announcement, putting the patch as Nominated in the
email. Because we don't want to start again, as it always arrives patches, and
we want to avoid delaying the release.


> > > > And finally, that is the reason why there is a couple of days between 
> > > > the pre-
> > > > announcement and the final announcement: for people to do more tests 
> > > > with
> > > > different configurations, and propose inclusions/removals.
> > > 
> > > What are the criteria for such inclusions? (Why do the nominated
> > > patches not meet them?) IME such requests for inclusion are met with
> > > "next release" replies (or "never").
> > > 
> > 
> > I think this depends on the authors, and how critical/urgent are those 
> > patches
> > that they can't wait for the next release (which happens every 2 weeks).
> 
> Except when it doesn't.
> 
> > By default, nominated patches are queued for next release. If the release 
> > is the
> > last one, then it is never (bear in mind that as said in a different email,
> > 17.3.7, is not the last one, and we need to update the calendar).
> > 
> > Exceptionally, people can request to include the nominated patch in the 
> > final
> > release if the problem it fixes is critical/urgent, that can't wait for the 
> > next
> > release. Likewise, if it is the last release I think it is fine for people 
> > to
> > request a new release more to include those changes.
> 
> 

Re: [Mesa-dev] [PATCH v2 2/7] nir/spirv: propagate constants of GroupNonUniformQuad instructions, eliminate warning and fix breaks

[Jason Ekstrand]

On Fri, Mar 16, 2018 at 2:50 AM, Daniel Schürmann <
daniel.schuerm...@campus.tu-berlin.de> wrote:

> Signed-off-by: Daniel Schürmann 
> ---
>  src/compiler/spirv/spirv_to_nir.c | 2 ++
>  src/compiler/spirv/vtn_subgroup.c | 8 ++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/spirv/spirv_to_nir.c
> b/src/compiler/spirv/spirv_to_nir.c
> index f06dca90ef..4454c1aca3 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -3340,10 +3340,12 @@ vtn_handle_preamble_instruction(struct
> vtn_builder *b, SpvOp opcode,
>
>case SpvCapabilityGroupNonUniformQuad:
>   spv_check_supported(subgroup_quad, cap);
> + break;
>
>case SpvCapabilityGroupNonUniformArithmetic:
>case SpvCapabilityGroupNonUniformClustered:
>   spv_check_supported(subgroup_arithmetic, cap);
> + break;
>
>case SpvCapabilityVariablePointersStorageBuffer:
>case SpvCapabilityVariablePointers:
> diff --git a/src/compiler/spirv/vtn_subgroup.c b/src/compiler/spirv/vtn_
> subgroup.c
> index bd3143962b..73420b7e43 100644
> --- a/src/compiler/spirv/vtn_subgroup.c
> +++ b/src/compiler/spirv/vtn_subgroup.c
> @@ -261,7 +261,9 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp
> opcode,
> case SpvOpGroupNonUniformQuadBroadcast:
>vtn_build_subgroup_instr(b, nir_intrinsic_quad_broadcast,
> val->ssa, vtn_ssa_value(b, w[4]),
> -   vtn_ssa_value(b, w[5])->def, 0, 0);
> +   vtn_ssa_value(b, w[5])->def,
> +   vtn_constant_value(b,
> w[5])->values[0].u32[0],
>

quad_broadcast has no constant value index.  See the comment below about
NIR not respecting it for copies etc.  If you want the constant value in
your back-end, nir_src_as_const_value will get that for you rather handily.


> +   0);
>break;
>
> case SpvOpGroupNonUniformQuadSwap: {
> @@ -277,9 +279,11 @@ vtn_handle_subgroup(struct vtn_builder *b, SpvOp
> opcode,
>case 2:
>   op = nir_intrinsic_quad_swap_diagonal;
>   break;
> +  default:
> + vtn_fail("Invalid constant value in OpGroupNonUniformQuadSwap");
>

The breaks and this vtn_fail are all ok.


>}
>vtn_build_subgroup_instr(b, op, val->ssa, vtn_ssa_value(b, w[4]),
> -   NULL, 0, 0);
> +   NULL, direction, 0);
>

The quad operations, as defined in NIR, have no "direction" index.  Sure,
you can set the field in the data structure, but you're liable to have it
go missing if you clone or [de]serialize the IR and not be respected for
things such as CSE.  If your back-end depneds on this being set, you're
most likely going to run into weird bugs.  Use the opcode instead.


>break;
> }
>
> --
> 2.14.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Ilia Mirkin]

On Fri, Mar 16, 2018 at 11:52 AM, Juan A. Suarez Romero
 wrote:
> On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
>> On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
>>  wrote:
>> > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
>> > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
>> > >  wrote:
>> > > > Nominated means that these patches does not enter in this release due 
>> > > > they
>> > > > arrived a bit late, but they are proposed to cherry-pick them for the 
>> > > > next
>> > > > release (in 1 or 2 weeks).
>> > > >
>> > > > The reason is that some days before this pre-announcement is sent, we 
>> > > > close the
>> > > > list of patches that enter in the release, and we do a lot of testing 
>> > > > to verify
>> > > > nothing is broken). If there's some regression, we just try to fix 
>> > > > them. And
>> > > > when everything is ready, we send the pre-announcement email.
>> > > >
>> > > > The nominated patches are those that arrive after we close the list, 
>> > > > and we are
>> > > > under the testing process. As we don't want to restart the full 
>> > > > process again
>> > > > and again, we just nominate them for the next release. Otherwise that 
>> > > > would
>> > > > delay the release too much.
>> > >
>> > > Why not send the pre-announcement right when it's closed? Since your
>> > > testing doesn't cover all drivers, shouldn't everyone just be able to
>> > > test at the same time, and then be able to add to the existing list
>> > > with additional fixes (or removals of picked commits)?
>> > >
>> >
>> >
>> > Because we want to propose a release candidate that has been tested as 
>> > much as
>> > possible, to avoid bothering people with a proposal that we need to change
>> > because it is causing regressions (and believe me this is quite common). 
>> > So we
>> > do different tests, thanks to Intel CI which covers a lot of tests and
>> > configurations, before doing the pre-announcement.
>> >
>> > Note that between we start the testing and do the pre-announcement there 
>> > is a
>> > difference of few hours, and hence the list of nominated patches is quite
>> > reduced (either none, or a couple of them). This time wasn't the case, and 
>> > it
>> > took some days. But it is not the usual case.
>>
>> Hm. It feels like it's the usual case. Perhaps it's not meant to be.
>> Why not just pick up all the nominated patches right before you do the
>> couple hours of testing?
>>
>
> That is what we do. We pick up all the patches until the last minute, just
> before starting the test. And as soon as we verify it is correct, we write and
> send the pre-announcement email.

Then why can it be days in between? If the tests get delayed/messed
up/have to be done over again, just pick up all the nominated patches
and go again.

>> > And finally, that is the reason why there is a couple of days between the 
>> > pre-
>> > announcement and the final announcement: for people to do more tests with
>> > different configurations, and propose inclusions/removals.
>>
>> What are the criteria for such inclusions? (Why do the nominated
>> patches not meet them?) IME such requests for inclusion are met with
>> "next release" replies (or "never").
>>
>
> I think this depends on the authors, and how critical/urgent are those patches
> that they can't wait for the next release (which happens every 2 weeks).

Except when it doesn't.

> By default, nominated patches are queued for next release. If the release is 
> the
> last one, then it is never (bear in mind that as said in a different email,
> 17.3.7, is not the last one, and we need to update the calendar).
>
> Exceptionally, people can request to include the nominated patch in the final
> release if the problem it fixes is critical/urgent, that can't wait for the 
> next
> release. Likewise, if it is the last release I think it is fine for people to
> request a new release more to include those changes.

I'm sure everyone thinks that their patches are fairly urgent. They
fix issues for users, and developers are the ones who end up doing a
lot of user support. Having things fixed leads to less headaches for
developers. Of course it's doubtful that millions of people would die
due to any particular patch not being in, so "urgent" is all relative.

> All in all, I appreciate a lot your comments for improving the release 
> process.
> Actually there is a thread about this improvement. Pretty sure you can add 
> also
> comments there.

I'm sure you've seen my comments in those threads. I see too much
decision power in the hands of the people doing releases, and not
enough in the hands of the developers who know the code, write the
patches, and support the users.

As you may be aware, my solution to this problem has been to stop
worrying about stable releases and tell users to use HEAD if they want
any support. But others may not be able to make use of such a
solution. And 

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
> On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
>  wrote:
> > Nominated means that these patches does not enter in this release due they
> > arrived a bit late, but they are proposed to cherry-pick them for the next
> > release (in 1 or 2 weeks).
> > 
> > The reason is that some days before this pre-announcement is sent, we close 
> > the
> > list of patches that enter in the release, and we do a lot of testing to 
> > verify
> > nothing is broken). If there's some regression, we just try to fix them. And
> > when everything is ready, we send the pre-announcement email.
> > 
> > The nominated patches are those that arrive after we close the list, and we 
> > are
> > under the testing process. As we don't want to restart the full process 
> > again
> > and again, we just nominate them for the next release. Otherwise that would
> > delay the release too much.
> 
> Why not send the pre-announcement right when it's closed? Since your
> testing doesn't cover all drivers, shouldn't everyone just be able to
> test at the same time, and then be able to add to the existing list
> with additional fixes (or removals of picked commits)?
> 


Because we want to propose a release candidate that has been tested as much as
possible, to avoid bothering people with a proposal that we need to change
because it is causing regressions (and believe me this is quite common). So we
do different tests, thanks to Intel CI which covers a lot of tests and
configurations, before doing the pre-announcement.

Note that between we start the testing and do the pre-announcement there is a
difference of few hours, and hence the list of nominated patches is quite
reduced (either none, or a couple of them). This time wasn't the case, and it
took some days. But it is not the usual case.

And finally, that is the reason why there is a couple of days between the pre-
announcement and the final announcement: for people to do more tests with
different configurations, and propose inclusions/removals.


Cheers,


J.A.

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

[Mesa-dev] [PATCH mesa 3/3] egl: pull update from Khronos and drop local define

[Eric Engestrom]

Added in Khronos in 2b6bb4ee45cc46c89d4a "EGL_MESA_drm_image: add
EGL_DRM_BUFFER_USE_CURSOR_MESA to egl.xml" [1] as part of PR #36 [2].

[1] 
https://github.com/KhronosGroup/EGL-Registry/commit/2b6bb4ee45cc46c89d4a4349f2ca94e80d77cd97
[2] https://github.com/KhronosGroup/EGL-Registry/pull/36

Signed-off-by: Eric Engestrom 
---
 include/EGL/eglext.h | 1 +
 include/EGL/eglmesaext.h | 7 ---
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
index f7dc66884ee9a673041e..2f990cc54d6d8202176e 100644
--- a/include/EGL/eglext.h
+++ b/include/EGL/eglext.h
@@ -933,6 +933,7 @@ EGLAPI EGLSurface EGLAPIENTRY eglCreatePixmapSurfaceHI 
(EGLDisplay dpy, EGLConfi
 #define EGL_DRM_BUFFER_STRIDE_MESA0x31D4
 #define EGL_DRM_BUFFER_USE_SCANOUT_MESA   0x0001
 #define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002
+#define EGL_DRM_BUFFER_USE_CURSOR_MESA0x0004
 typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay 
dpy, const EGLint *attrib_list);
 typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay 
dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
 #ifdef EGL_EGLEXT_PROTOTYPES
diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index 5bf6306a38e1904da1d8..f4332b279f879197d914 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -34,13 +34,6 @@ extern "C" {
 
 #include 
 
-#ifdef EGL_MESA_drm_image
-/* Mesa's extension to EGL_MESA_drm_image... */
-#ifndef EGL_DRM_BUFFER_USE_CURSOR_MESA
-#define EGL_DRM_BUFFER_USE_CURSOR_MESA 0x0004
-#endif
-#endif
-
 #ifndef EGL_WL_bind_wayland_display
 #define EGL_WL_bind_wayland_display 1
 
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 1/3] egl: add Ozone section to eglplatform.h

[Eric Engestrom]

This pulls in commit a93f559e9c11fa53fb5f1cc255b8f75433f85d2a "Add Ozone
section to eglplatform.h" from Khronos [1] added by Brian Anderson [2]
a few months ago.

[1] 
https://github.com/KhronosGroup/EGL-Registry/commit/a93f559e9c11fa53fb5f1cc255b8f75433f85d2a
[2] https://github.com/KhronosGroup/EGL-Registry/pull/26

Signed-off-by: Eric Engestrom 
---
 include/EGL/eglplatform.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
index bf9ec0bf5f4fbf7105cd..8a78a9eaddd2f47ff2c0 100644
--- a/include/EGL/eglplatform.h
+++ b/include/EGL/eglplatform.h
@@ -104,6 +104,12 @@ typedef struct ANativeWindow*   
EGLNativeWindowType;
 typedef struct egl_native_pixmap_t* EGLNativePixmapType;
 typedef void*   EGLNativeDisplayType;
 
+#elif defined(USE_OZONE)
+
+typedef intptr_t EGLNativeDisplayType;
+typedef intptr_t EGLNativeWindowType;
+typedef intptr_t EGLNativePixmapType;
+
 #elif defined(__unix__) || defined(__APPLE__)
 
 #if defined(MESA_EGL_NO_X11_HEADERS)
-- 
Cheers,
  Eric

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

[Mesa-dev] [PATCH mesa 2/3] egl: align the formatting of Haiku section of eglplatform.h with Khronos'

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 include/EGL/eglplatform.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/EGL/eglplatform.h b/include/EGL/eglplatform.h
index 8a78a9eaddd2f47ff2c0..b0541d52aed6584c63f2 100644
--- a/include/EGL/eglplatform.h
+++ b/include/EGL/eglplatform.h
@@ -130,11 +130,13 @@ typedef Window   EGLNativeWindowType;
 
 #endif /* MESA_EGL_NO_X11_HEADERS */
 
-#elif __HAIKU__
+#elif defined(__HAIKU__)
+
 #include 
-typedef void   *EGLNativeDisplayType;
-typedef khronos_uintptr_t   EGLNativePixmapType;
-typedef khronos_uintptr_t   EGLNativeWindowType;
+
+typedef void  *EGLNativeDisplayType;
+typedef khronos_uintptr_t  EGLNativePixmapType;
+typedef khronos_uintptr_t  EGLNativeWindowType;
 
 #else
 #error "Platform not recognized"
-- 
Cheers,
  Eric

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 11:38 -0400, Ilia Mirkin wrote:
> On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
>  wrote:
> > On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
> > > On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
> > >  wrote:
> > > > Nominated means that these patches does not enter in this release due 
> > > > they
> > > > arrived a bit late, but they are proposed to cherry-pick them for the 
> > > > next
> > > > release (in 1 or 2 weeks).
> > > > 
> > > > The reason is that some days before this pre-announcement is sent, we 
> > > > close the
> > > > list of patches that enter in the release, and we do a lot of testing 
> > > > to verify
> > > > nothing is broken). If there's some regression, we just try to fix 
> > > > them. And
> > > > when everything is ready, we send the pre-announcement email.
> > > > 
> > > > The nominated patches are those that arrive after we close the list, 
> > > > and we are
> > > > under the testing process. As we don't want to restart the full process 
> > > > again
> > > > and again, we just nominate them for the next release. Otherwise that 
> > > > would
> > > > delay the release too much.
> > > 
> > > Why not send the pre-announcement right when it's closed? Since your
> > > testing doesn't cover all drivers, shouldn't everyone just be able to
> > > test at the same time, and then be able to add to the existing list
> > > with additional fixes (or removals of picked commits)?
> > > 
> > 
> > 
> > Because we want to propose a release candidate that has been tested as much 
> > as
> > possible, to avoid bothering people with a proposal that we need to change
> > because it is causing regressions (and believe me this is quite common). So 
> > we
> > do different tests, thanks to Intel CI which covers a lot of tests and
> > configurations, before doing the pre-announcement.
> > 
> > Note that between we start the testing and do the pre-announcement there is 
> > a
> > difference of few hours, and hence the list of nominated patches is quite
> > reduced (either none, or a couple of them). This time wasn't the case, and 
> > it
> > took some days. But it is not the usual case.
> 
> Hm. It feels like it's the usual case. Perhaps it's not meant to be.
> Why not just pick up all the nominated patches right before you do the
> couple hours of testing?
> 

That is what we do. We pick up all the patches until the last minute, just
before starting the test. And as soon as we verify it is correct, we write and
send the pre-announcement email.

> > And finally, that is the reason why there is a couple of days between the 
> > pre-
> > announcement and the final announcement: for people to do more tests with
> > different configurations, and propose inclusions/removals.
> 
> What are the criteria for such inclusions? (Why do the nominated
> patches not meet them?) IME such requests for inclusion are met with
> "next release" replies (or "never").
> 

I think this depends on the authors, and how critical/urgent are those patches
that they can't wait for the next release (which happens every 2 weeks).

By default, nominated patches are queued for next release. If the release is the
last one, then it is never (bear in mind that as said in a different email,
17.3.7, is not the last one, and we need to update the calendar).

Exceptionally, people can request to include the nominated patch in the final
release if the problem it fixes is critical/urgent, that can't wait for the next
release. Likewise, if it is the last release I think it is fine for people to
request a new release more to include those changes.


All in all, I appreciate a lot your comments for improving the release process.
Actually there is a thread about this improvement. Pretty sure you can add also
comments there.

Thanks!

J.A.


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

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Rob Clark]

On Fri, Mar 16, 2018 at 11:18 AM, Emil Velikov  wrote:
> On 16 March 2018 at 12:41, Rob Clark  wrote:
>> Ok, I came up with:
>>
>>   https://hastebin.com/bulilojupo.cpp
>>
>> if you want to double check my methodology.
>>
>> It spotted a couple small mistakes, which I've fixed up locally.  Will
>> resend once I finish autotools build support.. hmm, and I guess there
>> is scons too.. *sigh*
>>
> autotools, scon and android.
>
> Unless you really want to I can prep something in the next day or two.
>

oh, right, android too..

If you have time, I'd defn appreciate some help w/
autotools/scons/android.. I am a bit short on time before heading to
linaro connect next week.

Fwiw, I've pushed the latest (which has a couple small fixes, but not
yet autotools/scons/android) to:

  https://github.com/freedreno/mesa/commits/mako-the-intrinsics

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

Re: [Mesa-dev] [PATCH 0/3] Meson patches for FreeBSD

[Daniel Stone]

Hi,

On 16 March 2018 at 15:23, Matt Turner  wrote:
> On Fri, Mar 16, 2018 at 8:07 AM, Emil Velikov  
> wrote:
>> On 16 March 2018 at 02:39, Matt Turner  wrote:
>>> All of your messages are going to spam on gmail:
>>>
>> Setting up a filter for 'list:"mesa-dev.lists.freedesktop.org"' will help 
>> there.
>
> I have that.

Yeah, I have the same. I missed Greg's messages to Wayland for quite a
long time for this reason. unrelenting.technology has DKIM set up,
meaning that no-one is allowed to send email from that domain but his
mail server. This completely breaks Mailman, and GMail is so strict
about it that it marks it as spam with either red or yellow warnings,
no matter what you do. There's no way to train it out of it.

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Ilia Mirkin]

On Fri, Mar 16, 2018 at 11:27 AM, Juan A. Suarez Romero
 wrote:
> On Fri, 2018-03-16 at 09:51 -0400, Ilia Mirkin wrote:
>> On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
>>  wrote:
>> > Nominated means that these patches does not enter in this release due they
>> > arrived a bit late, but they are proposed to cherry-pick them for the next
>> > release (in 1 or 2 weeks).
>> >
>> > The reason is that some days before this pre-announcement is sent, we 
>> > close the
>> > list of patches that enter in the release, and we do a lot of testing to 
>> > verify
>> > nothing is broken). If there's some regression, we just try to fix them. 
>> > And
>> > when everything is ready, we send the pre-announcement email.
>> >
>> > The nominated patches are those that arrive after we close the list, and 
>> > we are
>> > under the testing process. As we don't want to restart the full process 
>> > again
>> > and again, we just nominate them for the next release. Otherwise that would
>> > delay the release too much.
>>
>> Why not send the pre-announcement right when it's closed? Since your
>> testing doesn't cover all drivers, shouldn't everyone just be able to
>> test at the same time, and then be able to add to the existing list
>> with additional fixes (or removals of picked commits)?
>>
>
>
> Because we want to propose a release candidate that has been tested as much as
> possible, to avoid bothering people with a proposal that we need to change
> because it is causing regressions (and believe me this is quite common). So we
> do different tests, thanks to Intel CI which covers a lot of tests and
> configurations, before doing the pre-announcement.
>
> Note that between we start the testing and do the pre-announcement there is a
> difference of few hours, and hence the list of nominated patches is quite
> reduced (either none, or a couple of them). This time wasn't the case, and it
> took some days. But it is not the usual case.

Hm. It feels like it's the usual case. Perhaps it's not meant to be.
Why not just pick up all the nominated patches right before you do the
couple hours of testing?

>
> And finally, that is the reason why there is a couple of days between the pre-
> announcement and the final announcement: for people to do more tests with
> different configurations, and propose inclusions/removals.

What are the criteria for such inclusions? (Why do the nominated
patches not meet them?) IME such requests for inclusion are met with
"next release" replies (or "never").

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

Re: [Mesa-dev] [PATCH v2 8/8] i965: add performance query support on CNL

[Emil Velikov]

On 14 March 2018 at 17:19, Lionel Landwerlin
 wrote:
> v2: Add brw_oa_cnl.xml to EXTRA_DIST (Emil)
>
> Signed-off-by: Lionel Landwerlin 
> ---
This and 4/8 are
Reviewed-by: Emil Velikov 

It will cause some trivial conflicts with your other patch in the area.
FWIW I'd recommend landing that work first.

Then you'll only need to list the brw_oa_cnl.xml file in Makefile.sources.
No Makefile.am, no foo.[ch] changes ;-)

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

Re: [Mesa-dev] [PATCH 0/3] Meson patches for FreeBSD

[Matt Turner]

On Fri, Mar 16, 2018 at 8:07 AM, Emil Velikov  wrote:
> On 16 March 2018 at 02:39, Matt Turner  wrote:
>> On Tue, Mar 6, 2018 at 11:16 AM, Greg V  wrote:
>>> Hi! Here's a few more patches that let me successfully build, package
>>> and install fully working Meson-built Mesa-git on my FreeBSD box.
>>>
>>> Greg V (3):
>>>   meson: Use system_has_kms_drm in default driver selection
>>>   meson: use relative paths in megadriver symlinks
>>>   meson: make GLX_USE_TLS optional
>>>
>>>  bin/install_megadrivers.py |  2 +-
>>>  meson.build| 15 +--
>>>  meson_options.txt  |  6 ++
>>>  3 files changed, 16 insertions(+), 7 deletions(-)
>>
>> All of your messages are going to spam on gmail:
>>
> Setting up a filter for 'list:"mesa-dev.lists.freedesktop.org"' will help 
> there.

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

Re: [Mesa-dev] [PATCH] nir: add some comparison simplifications

[Ian Romanick]

On 03/16/2018 07:37 AM, Ian Romanick wrote:
> I have basically the same patch setting in my simple-range-analysis tree.
> 
> https://cgit.freedesktop.org/~idr/mesa/commit/?h=simple-range-analysis=e9d29d71304347f8ff904294450a398e5838f49a
> 
> As Jason mentions, you don't need to explicitly mention the compares.
> You don't need the @bool either... the source of b2[fi] is always bool.
> 
> IIRC, adding the b2f versions helps some other shaders too.  I'm
> (re-)gathering shader-db stats right now...

The shader that lost SIMD16 is one of the Tomb Raider shaders that had a
loop unrolled.  The results on other Intel platforms are similar.

Skylake
total instructions in shared programs: 14391653 -> 14390468 (<.01%)
instructions in affected programs: 111891 -> 110706 (-1.06%)
helped: 501
HURT: 0
helped stats (abs) min: 1 max: 155 x̄: 2.37 x̃: 1
helped stats (rel) min: 0.05% max: 21.54% x̄: 1.61% x̃: 1.01%
95% mean confidence interval for instructions value: -3.23 -1.50
95% mean confidence interval for instructions %-change: -1.77% -1.45%
Instructions are helped.

total cycles in shared programs: 532793024 -> 532776598 (<.01%)
cycles in affected programs: 987682 -> 971256 (-1.66%)
helped: 348
HURT: 41
helped stats (abs) min: 1 max: 3074 x̄: 54.91 x̃: 18
helped stats (rel) min: 0.05% max: 32.24% x̄: 3.36% x̃: 1.68%
HURT stats (abs)   min: 1 max: 422 x̄: 65.39 x̃: 24
HURT stats (rel)   min: 0.09% max: 39.29% x̄: 9.50% x̃: 2.02%
95% mean confidence interval for cycles value: -64.08 -20.38
95% mean confidence interval for cycles %-change: -2.78% -1.23%
Cycles are helped.

total loops in shared programs: 4854 -> 4829 (-0.52%)
loops in affected programs: 27 -> 2 (-92.59%)
helped: 18
HURT: 0
helped stats (abs) min: 1 max: 8 x̄: 1.39 x̃: 1
helped stats (rel) min: 50.00% max: 100.00% x̄: 94.44% x̃: 100.00%
95% mean confidence interval for loops value: -2.21 -0.57
95% mean confidence interval for loops %-change: -102.49% -86.40%
Loops are helped.

LOST:   1
GAINED: 0

> On 03/15/2018 08:53 PM, Timothy Arceri wrote:
>> These can be found in the Tomb Raider shaders, eliminating them
>> helps unroll more loops.
>> ---
>>  src/compiler/nir/nir_opt_algebraic.py | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
>> b/src/compiler/nir/nir_opt_algebraic.py
>> index c9575e6be4..56dfc53043 100644
>> --- a/src/compiler/nir/nir_opt_algebraic.py
>> +++ b/src/compiler/nir/nir_opt_algebraic.py
>> @@ -152,6 +152,10 @@ optimizations = [
>> (('inot', ('ige', a, b)), ('ilt', a, b)),
>> (('inot', ('ieq', a, b)), ('ine', a, b)),
>> (('inot', ('ine', a, b)), ('ieq', a, b)),
>> +   (('ine', ('b2i', ('ige', a, b)), 0), ('ige', a, b)),
>> +   (('ine', ('b2i', ('ilt', a, b)), 0), ('ilt', a, b)),
>> +   (('ine', ('b2i', ('ult', a, b)), 0), ('ult', a, b)),
>> +   (('ine', ('b2i', ('ine', a, b)), 0), ('ine', a, b)),
>>  
>> # 0.0 >= b2f(a)
>> # b2f(a) <= 0.0
>>
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 13:27 +, Alex Smith wrote:
> On 16 March 2018 at 12:46, Juan A. Suarez Romero  wrote:
> > On Fri, 2018-03-16 at 13:40 +0100, Juan A. Suarez Romero wrote:
> > > On Fri, 2018-03-16 at 12:17 +, Alex Smith wrote:
> > > > Hi Juan,
> > > >
> > > > On 16 March 2018 at 11:42, Juan A. Suarez Romero  
> > > > wrote:
> > > > > Hello list,
> > > > >
> > > > > The candidate for the Mesa 17.3.7 is now available. Currently we have:
> > > > >  - 53 queued
> > > > >  - 9 nominated (outstanding)
> > > > >  - and 6 rejected patches
> > > > >
> > > > >
> > > > > In the current queue we have lot of fixes, as the latest two releases 
> > > > > were
> > > > > emergency releases to fix major issues.
> > > > >
> > > > > The i965 receives quite a few of fixes. We have fixes for hangs on 
> > > > > GFXBench 5's
> > > > > Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another 
> > > > > fix for the
> > > > > number of input components, a fix for KHR_blend_equation_advanced, 
> > > > > another fix
> > > > > in the intel_from_planar, and some other fixes.
> > > > >
> > > > > In the RADV driver, there is a 3D images copying fix, another to 
> > > > > disable tc-
> > > > > compat on multisample d32s8, a fix related with HTILE, and a fix to 
> > > > > avoid hangs
> > > > > on Vega. Also, there is a couple of fixes regarding fences.
> > > > >
> > > > > R600 driver gets fixes for some hangs related with recip generation, 
> > > > > a fix for
> > > > > XFB stream check, another for indirect UBO access, and a final one 
> > > > > for cubemap
> > > > > arrays.
> > > > >
> > > > > In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, 
> > > > > which has been
> > > > > recently released. Besides those, there are another couple of fixes 
> > > > > too.
> > > > >
> > > > > Finally, there a some fixes for other drivers like Virgl, NVC0, 
> > > > > Winsys, and
> > > > > RadeonSI.
> > > > >
> > > > > Fixes also reach Wayland part. There's a fix to use the 
> > > > > wayland-egl-backend.h
> > > > > provided by Mesa itself, and a fix related with ARGB/XRGB 
> > > > > transposition.
> > > > >
> > > > > Just to continue, there are also other framework-specific fixes. 
> > > > > There are a
> > > > > bunch of fixes for NIR, fixes for GLSL component.
> > > > >
> > > > > Finally, and to avoid extending to much the list of fixes, there are 
> > > > > several
> > > > > fixes that touches different parts of Mesa that solves different bugs.
> > > > >
> > > > > Take a look at section "Mesa stable queue" for more information.
> > > > >
> > > > >
> > > > > Testing reports/general approval
> > > > > 
> > > > > Any testing reports (or general approval of the state of the branch) 
> > > > > will be
> > > > > greatly appreciated.
> > > > >
> > > > > The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly 
> > > > > after 12:00
> > > > > GMT.
> > > > >
> > > > > If you have any questions or suggestions - be that about the current 
> > > > > patch queue
> > > > > or otherwise, please go ahead.
> > > > >
> > > > >
> > > > > Trivial merge conflicts
> > > > > ---
> > > > >
> > > > > commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> > > > > Author: Dave Airlie 
> > > > >
> > > > > ac/nir: don't apply slice rounding on txf_ms
> > > > >
> > > > > (cherry picked from commit 
> > > > > 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> > > > >
> > > > >
> > > > > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > > > > Author: Daniel Stone 
> > > > >
> > > > > egl/wayland: Fix ARGB/XRGB transposition in config map
> > > > >
> > > > > (cherry picked from commit 
> > > > > 4fbd2d50b1c06a3c10f3a254e933646345123751)
> > > > >
> > > > >
> > > > > commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> > > > > Author: Bas Nieuwenhuizen 
> > > > >
> > > > > radeonsi: Export signalled sync file instead of -1.
> > > > >
> > > > > (cherry picked from commit 
> > > > > 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> > > > >
> > > > > squashed with
> > > > >
> > > > > configure/meson: Bump libdrm_amdgpu version requirement.
> > > > >
> > > > > (cherry picked from commit 
> > > > > 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> > > > >
> > > > >
> > > > > commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> > > > > Author: Bas Nieuwenhuizen 
> > > > >
> > > > > radv: Always lower indirect derefs after 
> > > > > nir_lower_global_vars_to_local.
> > > > >
> > > > > (cherry picked from commit 
> > > > > 05d84ed68add9e6adfcc602a274405e04226c1b7)
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > J.A.
> > > > >
> > > > >
> > > > >
> > > > > Mesa stable queue
> > > > > -
> > > > >
> > > > > Nominated (9)
> > > > > ==
> > > > >
> > > > > Alex Smith (1):
> > > > >   fcf267ba08 radv: Fix 

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Emil Velikov]

On 16 March 2018 at 12:41, Rob Clark  wrote:
> Ok, I came up with:
>
>   https://hastebin.com/bulilojupo.cpp
>
> if you want to double check my methodology.
>
> It spotted a couple small mistakes, which I've fixed up locally.  Will
> resend once I finish autotools build support.. hmm, and I guess there
> is scons too.. *sigh*
>
autotools, scon and android.

Unless you really want to I can prep something in the next day or two.

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

[Mesa-dev] [Bug 96955] SSH Account Request for Mesa related development

[bugzilla-daemon]

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

Daniel Stone  changed:

   What|Removed |Added

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

--- Comment #4 from Daniel Stone  ---
Thanks Brian! I've created it now, and it should be active in ~10min, giving
you access to push to ssh://git.freedesktop.org/git/mesa/mesa.

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

Re: [Mesa-dev] [PATCH 0/3] Meson patches for FreeBSD

[Emil Velikov]

On 16 March 2018 at 02:39, Matt Turner  wrote:
> On Tue, Mar 6, 2018 at 11:16 AM, Greg V  wrote:
>> Hi! Here's a few more patches that let me successfully build, package
>> and install fully working Meson-built Mesa-git on my FreeBSD box.
>>
>> Greg V (3):
>>   meson: Use system_has_kms_drm in default driver selection
>>   meson: use relative paths in megadriver symlinks
>>   meson: make GLX_USE_TLS optional
>>
>>  bin/install_megadrivers.py |  2 +-
>>  meson.build| 15 +--
>>  meson_options.txt  |  6 ++
>>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> All of your messages are going to spam on gmail:
>
Setting up a filter for 'list:"mesa-dev.lists.freedesktop.org"' will help there.

>> This message has a from address in unrelenting.technology but has failed 
>> unrelenting.technology's required tests for authentication.  Learn more
>
> I wouldn't expect anyone to review until you fix your mail server.

Me+Dylan actually spotted the emails, despite the funky server ;-)
Regardless, fixing that up is a must have IMHO.

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

Re: [Mesa-dev] [PATCH 2/2] i965: perf: reduce i965 binary size

[Lionel Landwerlin]

On 16/03/18 15:03, Lionel Landwerlin wrote:

Here are the savings in a meson build :

Before :
$ du -h ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so 
./build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old
43M ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so
47M ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old

$ size build/src/mesa/drivers/dri/libmesa_dri_drivers.so 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old
text   data  bss dechex filename
13054002 409424  671856 14135282 d7aff2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so
14550386 409552  671856 15631794 ee85b2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old


Arg... Drop this bit ->


$ size build/src/mesa/drivers/dri/libmesa_dri_drivers.so
  text data bss dec hex filename
  14550386   409552  671856 15631794 ee85b2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so


<-



As a side comment here is the size of the drivers if we remove all of
the metrics from the build :

$ du -sh build/src/mesa/drivers/dri/libmesa_dri_drivers.so
40M build/src/mesa/drivers/dri/libmesa_dri_drivers.so

v2: Fix an issue with hashing of counter equations (Lionel)
 Build system rework (Emil)



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

[Mesa-dev] [PATCH 2/2] i965: perf: reduce i965 binary size

[Lionel Landwerlin]

Performance metric numbers are calculated the following way :

   - out of the 256 bytes long OA reports, we accumulate the deltas
 into an array of uint64_t

   - the equations' generated code reads the accumulated uint64_t
 deltas and normalizes them for a particular platforms

Our hardware is such that a number of counters in the OA reports
always return the same values (i.e. they're not programmable), and
they return the same values even across generations, and as a result a
number of equations are identical in different metric sets across
different generations.

Up to now we've kept the generated code of the equations separated in
different files (per generation/GT), and didn't apply any
factorization of the common equations. We could have make some
improvement by reusing equations within a given metrics file, but we
can go even further and reuse across generations (i.e. all files).

This change changes the code generation to emit a single file in which
we reuse equations emitted code based on the hash of equations'
strings.

Here are the savings in a meson build :

Before :
   $ du -h ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so 
./build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old
   43M  ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so
   47M  ./build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old

   $ size build/src/mesa/drivers/dri/libmesa_dri_drivers.so 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old
   text   data  bss  dechex filename
   13054002 409424   671856 14135282 d7aff2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so
   14550386 409552   671856 15631794 ee85b2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so.old

   $ size build/src/mesa/drivers/dri/libmesa_dri_drivers.so
 text  data bss dec hex filename
 14550386409552  671856 15631794 ee85b2 
build/src/mesa/drivers/dri/libmesa_dri_drivers.so

As a side comment here is the size of the drivers if we remove all of
the metrics from the build :

   $ du -sh build/src/mesa/drivers/dri/libmesa_dri_drivers.so
   40M  build/src/mesa/drivers/dri/libmesa_dri_drivers.so

v2: Fix an issue with hashing of counter equations (Lionel)
Build system rework (Emil)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Emil Velikov  (build system part)
---
 src/mesa/drivers/dri/i965/Android.mk  |  11 +-
 src/mesa/drivers/dri/i965/Makefile.am |  21 +-
 src/mesa/drivers/dri/i965/Makefile.sources|  40 +-
 src/mesa/drivers/dri/i965/brw_oa.py   | 431 ++
 src/mesa/drivers/dri/i965/brw_performance_query.c |  13 +-
 src/mesa/drivers/dri/i965/meson.build |  37 +-
 6 files changed, 332 insertions(+), 221 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/Android.mk 
b/src/mesa/drivers/dri/i965/Android.mk
index 964313e6c5e..a3d010a5894 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -309,15 +309,18 @@ intermediates := $(call local-generated-sources-dir)
 LOCAL_GENERATED_SOURCES += $(addprefix $(intermediates)/, \
$(i965_oa_GENERATED_FILES))
 
-$(intermediates)/brw_oa_%.h: $(LOCAL_PATH)/brw_oa_%.xml $(LOCAL_PATH)/brw_oa.py
+i965_oa_xml_FILES := $(addprefix $(LOCAL_PATH)/, \
+   $(i965_oa_xml_FILES))
+
+$(intermediates)/brw_oa_metrics.h: $(LOCAL_PATH)/brw_oa.py $(i965_oa_xml_FILES)
@echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
@mkdir -p $(dir $@)
-   $(hide) $(MESA_PYTHON2) $(word 2, $^) --header=$@ --chipset=$(basename 
$*) $<
+   $(hide) $(MESA_PYTHON2) $< --header=$@ $(i965_oa_xml_FILES)
 
-$(intermediates)/brw_oa_%.c: $(LOCAL_PATH)/brw_oa_%.xml $(LOCAL_PATH)/brw_oa.py
+$(intermediates)/brw_oa_metrics.c: $(LOCAL_PATH)/brw_oa.py $(i965_oa_xml_FILES)
@echo "target Generated: $(PRIVATE_MODULE) <= $(notdir $(@))"
@mkdir -p $(dir $@)
-   $(hide) $(MESA_PYTHON2) $(word 2, $^) --code=$@ --chipset=$(basename 
$*) $<
+   $(hide) $(MESA_PYTHON2) $< --code=$@ $(i965_oa_xml_FILES)
 
 include $(MESA_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am 
b/src/mesa/drivers/dri/i965/Makefile.am
index 824882389ea..8c8ecc6d76b 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -110,26 +110,15 @@ BUILT_SOURCES = $(i965_oa_GENERATED_FILES)
 CLEANFILES = $(BUILT_SOURCES)
 
 EXTRA_DIST = \
-   brw_oa_hsw.xml \
-   brw_oa_bdw.xml \
-   brw_oa_chv.xml \
-   brw_oa_sklgt2.xml \
-   brw_oa_sklgt3.xml \
-   brw_oa_sklgt4.xml \
-   brw_oa_bxt.xml \
-   brw_oa_kblgt2.xml \
-   brw_oa_kblgt3.xml \
-   brw_oa_glk.xml \
-   brw_oa_cflgt2.xml \
-   brw_oa_cflgt3.xml \
brw_oa.py \
+   $(i965_oa_xml_FILES) \
meson.build
 
 # Note: we avoid using a multi target rule here and 

[Mesa-dev] [PATCH 0/2] i965: reduce driver binary size through metrics code reuse

[Lionel Landwerlin]

Hi,

Here is a v2 with a fixup commit from Emil. I've also fix another
issue related to hashing of normalization equations.

Cheers,

Lionel Landwerlin (2):
  i965: perf: fix a counter return type on hsw
  i965: perf: reduce i965 binary size

 src/mesa/drivers/dri/i965/Android.mk  |  11 +-
 src/mesa/drivers/dri/i965/Makefile.am |  21 +-
 src/mesa/drivers/dri/i965/Makefile.sources|  40 +-
 src/mesa/drivers/dri/i965/brw_oa.py   | 431 ++
 src/mesa/drivers/dri/i965/brw_oa_hsw.xml  |   2 +-
 src/mesa/drivers/dri/i965/brw_performance_query.c |  13 +-
 src/mesa/drivers/dri/i965/meson.build |  37 +-
 7 files changed, 333 insertions(+), 222 deletions(-)

--
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] i965: perf: fix a counter return type on hsw

[Lionel Landwerlin]

The equation code computes a float (percentage) yet the return type
was an uint64_t.

Signed-off-by: Lionel Landwerlin 
---
 src/mesa/drivers/dri/i965/brw_oa_hsw.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_oa_hsw.xml 
b/src/mesa/drivers/dri/i965/brw_oa_hsw.xml
index ebc2bd79143..861cc1212a7 100644
--- a/src/mesa/drivers/dri/i965/brw_oa_hsw.xml
+++ b/src/mesa/drivers/dri/i965/brw_oa_hsw.xml
@@ -1669,7 +1669,7 @@
  />
 https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] loader: Include include/drm-uapi in the autotools build

[Emil Velikov]

On 15 March 2018 at 21:29, Jason Ekstrand  wrote:
> We're already including it in the meson build.  This fixes build issues
> on systems which have a drm_fourcc.h that doesn't have modifiers.
> ---
>  src/loader/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
> index a0e52c1..7625256 100644
> --- a/src/loader/Makefile.am
> +++ b/src/loader/Makefile.am
> @@ -30,6 +30,7 @@ AM_CPPFLAGS = \
> -DUSE_DRICONF \
> $(DEFINES) \
> -I$(top_srcdir)/include \
> +   -I$(top_srcdir)/include/drm-uapi \
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] st/dri: don't set queryDmaBufFormats/queryDmaBufModifiers if the driver does not implement it

[Emil Velikov]

Cc-ing the author of the 'offending' commit - Nicolai

On 15 March 2018 at 16:27, Michal Srb  wrote:
> This is equivalent to commit a65db0ad1c3, but for dri_kms_init_screen. Without
> this gbm_dri_is_format_supported always returns false.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104926
> ---
Thanks for the nice work Michal. Patch looks spot on.

Fixes: e14fe41e0bf ("st/dri: implement createImageFromRenderbuffer(2)")
Reviewed-by: Emil Velikov 

In practise we should be able to unity/remove the duplication across
dri_kms_init_screen and dri2_init_screen.
The pipe_loader_drm_probe_fd vs pipe_loader_sw_probe_kms is the only
change. One might need to wire up the DRM_CONF_SHARE_FD for the
driver.

Any takers?

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

[Mesa-dev] [Bug 96955] SSH Account Request for Mesa related development

[bugzilla-daemon]

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

--- Comment #3 from Brian Paul  ---
It looks like Gwan-gyeong has authored nearly 30 patches in Mesa in 2016-17.
OK be me, Daniel.

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

Re: [Mesa-dev] [PATCH] nir: add some comparison simplifications

[Ian Romanick]

I have basically the same patch setting in my simple-range-analysis tree.

https://cgit.freedesktop.org/~idr/mesa/commit/?h=simple-range-analysis=e9d29d71304347f8ff904294450a398e5838f49a

As Jason mentions, you don't need to explicitly mention the compares.
You don't need the @bool either... the source of b2[fi] is always bool.

IIRC, adding the b2f versions helps some other shaders too.  I'm
(re-)gathering shader-db stats right now...

On 03/15/2018 08:53 PM, Timothy Arceri wrote:
> These can be found in the Tomb Raider shaders, eliminating them
> helps unroll more loops.
> ---
>  src/compiler/nir/nir_opt_algebraic.py | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/compiler/nir/nir_opt_algebraic.py 
> b/src/compiler/nir/nir_opt_algebraic.py
> index c9575e6be4..56dfc53043 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -152,6 +152,10 @@ optimizations = [
> (('inot', ('ige', a, b)), ('ilt', a, b)),
> (('inot', ('ieq', a, b)), ('ine', a, b)),
> (('inot', ('ine', a, b)), ('ieq', a, b)),
> +   (('ine', ('b2i', ('ige', a, b)), 0), ('ige', a, b)),
> +   (('ine', ('b2i', ('ilt', a, b)), 0), ('ilt', a, b)),
> +   (('ine', ('b2i', ('ult', a, b)), 0), ('ult', a, b)),
> +   (('ine', ('b2i', ('ine', a, b)), 0), ('ine', a, b)),
>  
> # 0.0 >= b2f(a)
> # b2f(a) <= 0.0
> 

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

Re: [Mesa-dev] [PATCH v2] nir: add a comparison simplification

[Ian Romanick]

On 03/16/2018 01:58 AM, Timothy Arceri wrote:
> 
> 
> On 16/03/18 19:34, Samuel Pitoiset wrote:
>>
>>
>> On 03/16/2018 09:15 AM, Timothy Arceri wrote:
>>> On 16/03/18 18:45, Samuel Pitoiset wrote:
 shader stats?
>>>
>>> I didn't bother posting them because they are misleading. There are a
>>> few instructions remove here and there but the main changes are due
>>> to loop unrolling.
>>>
>>> Totals from affected shaders:
>>> SGPRS: 640 -> 664 (3.75 %)
>>> VGPRS: 352 -> 368 (4.55 %)
>>> Spilled SGPRs: 6 -> 8 (33.33 %)
>>> Spilled VGPRs: 0 -> 0 (0.00 %)
>>> Private memory VGPRs: 0 -> 0 (0.00 %)
>>> Scratch size: 0 -> 0 (0.00 %) dwords per thread
>>> Code Size: 24200 -> 36216 (49.65 %) bytes
>>> LDS: 0 -> 0 (0.00 %) blocks
>>> Max Waves: 52 -> 51 (-1.92 %)
>>> Wait states: 0 -> 0 (0.00 %)
>>
>> Mmmh, the stats don't seem really good to me. Which games are affected
>> by this change?
> 
> Just Tomb Raider.
> 
>>
>> As you know, we shouldn't *always* trust shader stats. Though, it
>> would quite appreciated to run some benchmarks in this situation.
> 
> I've benchmarked it and there was no change. The stats are misleading
> because register and code size increase but that is an expected outcome
> of loop unrolling. At the end of the day this is a clear simplification
> of logic, any bad outcome would indicate we should tune loop unrolling
> rather than reject this patch IMO.

For Intel runs of shader-db, our script doesn't count shaders that had
loops change in the instruction count changes. :)

 On 03/16/2018 06:48 AM, Timothy Arceri wrote:
> These can be found in the Tomb Raider shaders, eliminating them
> helps unroll more loops.
> ---
>   src/compiler/nir/nir_opt_algebraic.py | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index c9575e6be4..2148bc121b 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -152,6 +152,7 @@ optimizations = [
>  (('inot', ('ige', a, b)), ('ilt', a, b)),
>  (('inot', ('ieq', a, b)), ('ine', a, b)),
>  (('inot', ('ine', a, b)), ('ieq', a, b)),
> +   (('ine', ('b2i', 'a@bool'), 0), 'a'),
>  # 0.0 >= b2f(a)
>  # b2f(a) <= 0.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [PATCH v2] egl/android: Implement the eglSwapinterval for Android.

[Emil Velikov]

On 16 March 2018 at 08:51, Wu, Zhongmin  wrote:
> Thanks very much Tomasz.
>
> So, who can help to commit such patch.
>
Fixed with s/dpy/disp/ (otherwise it won't even build) and pushed.

Please go through the patches list and update it.
I believe that all of those are superseded, do check them over.

https://patchwork.freedesktop.org/project/mesa/patches/?submitter=17018

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

[Mesa-dev] [Bug 105506] Vulkan MSAA is broken on SI

[bugzilla-daemon]

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

Turo Lamminen  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|REOPENED|RESOLVED

--- Comment #8 from Turo Lamminen  ---
Looks like this might have been my bug after all.

I was specifying subpass dependencies with separate VkSubpassDependency for
color and depthstencil attachments but the same srcSubPass and dstSubPass. The
idea was that the driver would be able to use finer-grained barriers if it
wanted. The other drivers treated these as union of dependencies, radv was only
taking the last one and missing some color writes. ORing everything together
makes this work.

In case my explanation was unclear here is the fix:
https://github.com/turol/smaaDemo/commit/34a79f076ebab7a661d8705c4adcb2d5b3258281

The Vulkan spec doesn't seem clear on whether this is allowed or not. I think
in theory it would be useful to specify for example that depth test/write can
proceed differently from color write.

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Ilia Mirkin]

On Fri, Mar 16, 2018 at 8:40 AM, Juan A. Suarez Romero
 wrote:
> Nominated means that these patches does not enter in this release due they
> arrived a bit late, but they are proposed to cherry-pick them for the next
> release (in 1 or 2 weeks).
>
> The reason is that some days before this pre-announcement is sent, we close 
> the
> list of patches that enter in the release, and we do a lot of testing to 
> verify
> nothing is broken). If there's some regression, we just try to fix them. And
> when everything is ready, we send the pre-announcement email.
>
> The nominated patches are those that arrive after we close the list, and we 
> are
> under the testing process. As we don't want to restart the full process again
> and again, we just nominate them for the next release. Otherwise that would
> delay the release too much.

Why not send the pre-announcement right when it's closed? Since your
testing doesn't cover all drivers, shouldn't everyone just be able to
test at the same time, and then be able to add to the existing list
with additional fixes (or removals of picked commits)?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Alex Smith]

On 16 March 2018 at 12:46, Juan A. Suarez Romero 
wrote:

> On Fri, 2018-03-16 at 13:40 +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2018-03-16 at 12:17 +, Alex Smith wrote:
> > > Hi Juan,
> > >
> > > On 16 March 2018 at 11:42, Juan A. Suarez Romero 
> wrote:
> > > > Hello list,
> > > >
> > > > The candidate for the Mesa 17.3.7 is now available. Currently we
> have:
> > > >  - 53 queued
> > > >  - 9 nominated (outstanding)
> > > >  - and 6 rejected patches
> > > >
> > > >
> > > > In the current queue we have lot of fixes, as the latest two
> releases were
> > > > emergency releases to fix major issues.
> > > >
> > > > The i965 receives quite a few of fixes. We have fixes for hangs on
> GFXBench 5's
> > > > Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another
> fix for the
> > > > number of input components, a fix for KHR_blend_equation_advanced,
> another fix
> > > > in the intel_from_planar, and some other fixes.
> > > >
> > > > In the RADV driver, there is a 3D images copying fix, another to
> disable tc-
> > > > compat on multisample d32s8, a fix related with HTILE, and a fix to
> avoid hangs
> > > > on Vega. Also, there is a couple of fixes regarding fences.
> > > >
> > > > R600 driver gets fixes for some hangs related with recip generation,
> a fix for
> > > > XFB stream check, another for indirect UBO access, and a final one
> for cubemap
> > > > arrays.
> > > >
> > > > In SWR/Rast driver we have a couple of fixes when using LLVM 6.0,
> which has been
> > > > recently released. Besides those, there are another couple of fixes
> too.
> > > >
> > > > Finally, there a some fixes for other drivers like Virgl, NVC0,
> Winsys, and
> > > > RadeonSI.
> > > >
> > > > Fixes also reach Wayland part. There's a fix to use the
> wayland-egl-backend.h
> > > > provided by Mesa itself, and a fix related with ARGB/XRGB
> transposition.
> > > >
> > > > Just to continue, there are also other framework-specific fixes.
> There are a
> > > > bunch of fixes for NIR, fixes for GLSL component.
> > > >
> > > > Finally, and to avoid extending to much the list of fixes, there are
> several
> > > > fixes that touches different parts of Mesa that solves different
> bugs.
> > > >
> > > > Take a look at section "Mesa stable queue" for more information.
> > > >
> > > >
> > > > Testing reports/general approval
> > > > 
> > > > Any testing reports (or general approval of the state of the branch)
> will be
> > > > greatly appreciated.
> > > >
> > > > The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly
> after 12:00
> > > > GMT.
> > > >
> > > > If you have any questions or suggestions - be that about the current
> patch queue
> > > > or otherwise, please go ahead.
> > > >
> > > >
> > > > Trivial merge conflicts
> > > > ---
> > > >
> > > > commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> > > > Author: Dave Airlie 
> > > >
> > > > ac/nir: don't apply slice rounding on txf_ms
> > > >
> > > > (cherry picked from commit 69495b30a38fbb01a937cdea6f7674
> f89a2e60e7)
> > > >
> > > >
> > > > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > > > Author: Daniel Stone 
> > > >
> > > > egl/wayland: Fix ARGB/XRGB transposition in config map
> > > >
> > > > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e93364
> 6345123751)
> > > >
> > > >
> > > > commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> > > > Author: Bas Nieuwenhuizen 
> > > >
> > > > radeonsi: Export signalled sync file instead of -1.
> > > >
> > > > (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf9
> 6c5ac18f0f)
> > > >
> > > > squashed with
> > > >
> > > > configure/meson: Bump libdrm_amdgpu version requirement.
> > > >
> > > > (cherry picked from commit 52be440f48ac7c337f6604846bb6f0
> cfd88e7118)
> > > >
> > > >
> > > > commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> > > > Author: Bas Nieuwenhuizen 
> > > >
> > > > radv: Always lower indirect derefs after
> nir_lower_global_vars_to_local.
> > > >
> > > > (cherry picked from commit 05d84ed68add9e6adfcc602a274405
> e04226c1b7)
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > J.A.
> > > >
> > > >
> > > >
> > > > Mesa stable queue
> > > > -
> > > >
> > > > Nominated (9)
> > > > ==
> > > >
> > > > Alex Smith (1):
> > > >   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and
> compressed
> > > > images
> > > >
> > > > Bas Nieuwenhuizen (1):
> > > >   997306c031 radv: Increase the number of dynamic uniform
> buffers.
> > >
> > > To clarify, does "nominated" mean that these will *not* be in 17.3.7?
> (I guess so since I don't see them on the branch)
> > >
> > > I'd like the above two changes in if possible.
> > >
> >
> > Nominated means that these patches does not enter in this release due
> they
> > arrived a bit late, but 

[Mesa-dev] [Bug 104926] swrast: Mesa 17.3.3 produces: HW cursor for format 875713089 not supported

[bugzilla-daemon]

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

--- Comment #4 from Stefan Dirsch  ---
https://lists.freedesktop.org/archives/mesa-dev/2018-March/189030.html

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

Re: [Mesa-dev] [PATCH 04/11] nir/spirv: add gl_spirv_validation method

[Rob Clark]

On Fri, Mar 16, 2018 at 7:48 AM, Alejandro Piñeiro  wrote:
> On 16/03/18 12:39, Rob Clark wrote:
>> On Fri, Mar 16, 2018 at 7:27 AM, Alejandro Piñeiro  
>> wrote:
>>> On 16/03/18 12:11, Rob Clark wrote:
 Just curious, how much different is this from what spirv-val does?
>>> Well, spirv-val does a full validation of the SPIR-V binary. Here we are
>>> just doing the basic validation required by the method
>>> glSpecializeShadeARB, introduced by ARB_gl_spirv. That's the reason the
>>> method is called gl_spirv_validation and not spirv_validation.
>>> Specifically the minimum enough to be able to raise the following
>>> possible errors from that method:
>>>
>>> "INVALID_VALUE is generated if  does not match the
>>>  of any OpEntryPoint declaration in the SPIR-V module
>>> associated with .
>>>
>>> INVALID_OPERATION is generated if the  of the
>>> OpEntryPoint indicated by  does not match the type
>>> of .
>>>
>>> INVALID_VALUE is generated if any element of 
>>> refers to a specialization constant that does not exist in the
>>> shader module contained in ."
>>>
>>>
>>> So plenty of invalid SPIR-V binaries would be able to pass that point.
>>> And that is "okish" to not check that. Also from ARB_gl_spirv spec:
>>>
>>>" The OpenGL API expects the SPIR-V module to have already
>>> been validated, and can return an error if it discovers anything invalid
>>> in the module. An invalid SPIR-V module is allowed to result in
>>> undefined behavior."
>> ok, if the spec doesn't require full validation and this doesn't
>> eventually evolve into a re-implementation of spirv-val, I'm not
>> really against it.
>
> Yes, if that happens, I agree that it doesn't make sense to re-implement
> spirv-val.
>> But just figured I should point out that I expect
>> eventually distro mesa builds will anyways depend on spirv-tools, so
>> if that was an easier path I don't see a big issue with a dependency
>> on spirv-tools
>
> Out of curiosity: why do you expect that for mesa? FWIW, in the
> short-medium term, we are going to send a proposal to piglit for the
> ARB_gl_spirv testing, that would include add a spirv-tools dependency on
> piglit. But using spirv-tools for the testing part sounds somewhat
> straightforward to me. I don't see so obvious the need for mesa, as both
> vulkan/ARB_gl_spirv allows a undefined behaviour for invalid SPIR-V.
> Unless we are interested in a kind of "safe-mode" were the driver does a
> full validation of the SPIR-V shader.
>

Not for mesa itself, but for clover.  Assuming distro's would be
generally enabling OpenCL for nouveau (or for arm builds,
freedreno/vc5 and some day etnaviv), which would involve
clc->spirv->nir->nvir.  AFAIU there is also a cl extension to allow
spirv kernels to be used directly (so spirv->nir->nvir).  Both paths
involve programmatically calling the validator.

(This is slightly more of a long-term thing, there is also some
dependency on llvm-spirv patches, etc)

BR,
-R

>>
>> BR,
>> -R
>>
  We
 are going to end up using spirv-tools from clover, so if all of this
 is just to avoid a dependency on spirv-tools, is it worth it?
>>> As I mentioned, this is basically because we don't need so such deep
>>> validation. Perhaps the name is slightly confusing even with the gl_
>>> prefix. In any case, note that with this patch we add a big comment
>>> (almost a test wall) for this method that explain what it is really
>>> validating.
 BR,
 -R

 On Thu, Mar 8, 2018 at 3:19 AM, Alejandro Piñeiro  
 wrote:
> ARB_gl_spirv adds the ability to use SPIR-V binaries, and a new
> method, glSpecializeShader. From OpenGL 4.6 spec, section 7.2.1
>"Shader Specialization", error table:
>
>  INVALID_VALUE is generated if  does not name a valid
>  entry point for .
>
>  INVALID_VALUE is generated if any element of 
>  refers to a specialization constant that does not exist in the
>  shader module contained in .""
>
> But we are not really interested on creating the nir shader at that
> point, and adding nir structures on the gl_program, so at that point
> we are just interested on the error checking.
>
> So we add a new method focused on just checking those errors. It still
> needs to parse the binary, but skips what it is not needed, and
> doesn't create the nir shader.
>
> v2: rebase update (spirv_to_nir options added, changes on the warning
> logging, and others)
>
> v3: include passing options on common initialization, doesn't call
> setjmp on common_initialization
>
> v4: (after Jason comments):
>   * Rename common_initialization to vtn_builder_create
>   * Move validation method and their helpers to own source file.
>   * Create own handle_constant_decoration_cb instead of 

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 13:40 +0100, Juan A. Suarez Romero wrote:
> On Fri, 2018-03-16 at 12:17 +, Alex Smith wrote:
> > Hi Juan,
> > 
> > On 16 March 2018 at 11:42, Juan A. Suarez Romero  
> > wrote:
> > > Hello list,
> > > 
> > > The candidate for the Mesa 17.3.7 is now available. Currently we have:
> > >  - 53 queued
> > >  - 9 nominated (outstanding)
> > >  - and 6 rejected patches
> > > 
> > > 
> > > In the current queue we have lot of fixes, as the latest two releases were
> > > emergency releases to fix major issues.
> > > 
> > > The i965 receives quite a few of fixes. We have fixes for hangs on 
> > > GFXBench 5's
> > > Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix 
> > > for the
> > > number of input components, a fix for KHR_blend_equation_advanced, 
> > > another fix
> > > in the intel_from_planar, and some other fixes.
> > > 
> > > In the RADV driver, there is a 3D images copying fix, another to disable 
> > > tc-
> > > compat on multisample d32s8, a fix related with HTILE, and a fix to avoid 
> > > hangs
> > > on Vega. Also, there is a couple of fixes regarding fences.
> > > 
> > > R600 driver gets fixes for some hangs related with recip generation, a 
> > > fix for
> > > XFB stream check, another for indirect UBO access, and a final one for 
> > > cubemap
> > > arrays.
> > > 
> > > In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which 
> > > has been
> > > recently released. Besides those, there are another couple of fixes too.
> > > 
> > > Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, 
> > > and
> > > RadeonSI.
> > > 
> > > Fixes also reach Wayland part. There's a fix to use the 
> > > wayland-egl-backend.h
> > > provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
> > > 
> > > Just to continue, there are also other framework-specific fixes. There 
> > > are a
> > > bunch of fixes for NIR, fixes for GLSL component.
> > > 
> > > Finally, and to avoid extending to much the list of fixes, there are 
> > > several
> > > fixes that touches different parts of Mesa that solves different bugs.
> > > 
> > > Take a look at section "Mesa stable queue" for more information.
> > > 
> > > 
> > > Testing reports/general approval
> > > 
> > > Any testing reports (or general approval of the state of the branch) will 
> > > be
> > > greatly appreciated.
> > > 
> > > The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after 
> > > 12:00
> > > GMT.
> > > 
> > > If you have any questions or suggestions - be that about the current 
> > > patch queue
> > > or otherwise, please go ahead.
> > > 
> > > 
> > > Trivial merge conflicts
> > > ---
> > > 
> > > commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> > > Author: Dave Airlie 
> > > 
> > > ac/nir: don't apply slice rounding on txf_ms
> > > 
> > > (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> > > 
> > > 
> > > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > > Author: Daniel Stone 
> > > 
> > > egl/wayland: Fix ARGB/XRGB transposition in config map
> > > 
> > > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> > > 
> > > 
> > > commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> > > Author: Bas Nieuwenhuizen 
> > > 
> > > radeonsi: Export signalled sync file instead of -1.
> > > 
> > > (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> > > 
> > > squashed with
> > > 
> > > configure/meson: Bump libdrm_amdgpu version requirement.
> > > 
> > > (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> > > 
> > > 
> > > commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> > > Author: Bas Nieuwenhuizen 
> > > 
> > > radv: Always lower indirect derefs after 
> > > nir_lower_global_vars_to_local.
> > > 
> > > (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
> > > 
> > > 
> > > Cheers,
> > > 
> > > J.A.
> > > 
> > > 
> > > 
> > > Mesa stable queue
> > > -
> > > 
> > > Nominated (9)
> > > ==
> > > 
> > > Alex Smith (1):
> > >   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and 
> > > compressed
> > > images
> > > 
> > > Bas Nieuwenhuizen (1):
> > >   997306c031 radv: Increase the number of dynamic uniform buffers.
> > 
> > To clarify, does "nominated" mean that these will *not* be in 17.3.7? (I 
> > guess so since I don't see them on the branch)
> > 
> > I'd like the above two changes in if possible.
> > 
> 
> Nominated means that these patches does not enter in this release due they
> arrived a bit late, but they are proposed to cherry-pick them for the next
> release (in 1 or 2 weeks).
> 
> 
> The reason is that some days before this pre-announcement is sent, we close 
> the
> list of patches that enter in the release, and we 

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 12:36 +, Emil Velikov wrote:
> On 16 March 2018 at 12:07, Daniel Stone  wrote:
> > Hi Juan,
> > 
> > On 16 March 2018 at 11:42, Juan A. Suarez Romero  
> > wrote:
> > > Trivial merge conflicts
> > > ---
> > > 
> > > [...]
> > > 
> > > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > > Author: Daniel Stone 
> > > 
> > > egl/wayland: Fix ARGB/XRGB transposition in config map
> > > 
> > > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> > 
> > This commit isn't in the 17.3 branch; was it rebased into another commit?
> > 
> 
> Seems like the sha's are off, although commits and contents seem sane IMHO.
> The corrected list is:
> 

Thanks for correcting them!


J.A.

> commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> Author: Bas Nieuwenhuizen 
> 
>radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
> 
>(cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
> 
> 
> commit 56a9c6541e96bb08f56c55c0a5047cbd14307d81
> Author: Bas Nieuwenhuizen 
> 
>radeonsi: Export signalled sync file instead of -1.
> 
>(cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> 
>Squashed with:
> 
>configure/meson: Bump libdrm_amdgpu version requirement.
> 
>(cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> 
> 
> commit 2e043c9bcf0182bb631a9ed0c4562775106cd1db
> Author: Daniel Stone 
> 
>egl/wayland: Fix ARGB/XRGB transposition in config map
> 
>(cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> 
> 
> commit 1288d1efa851f94ba3c2a591ca32febb6b447ada
> Author: Dave Airlie 
> 
>ac/nir: don't apply slice rounding on txf_ms
> 
>(cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> 
> 
> HTH
> Emil
> ___
> 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] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 12:17 +, Alex Smith wrote:
> Hi Juan,
> 
> On 16 March 2018 at 11:42, Juan A. Suarez Romero  wrote:
> > Hello list,
> > 
> > The candidate for the Mesa 17.3.7 is now available. Currently we have:
> >  - 53 queued
> >  - 9 nominated (outstanding)
> >  - and 6 rejected patches
> > 
> > 
> > In the current queue we have lot of fixes, as the latest two releases were
> > emergency releases to fix major issues.
> > 
> > The i965 receives quite a few of fixes. We have fixes for hangs on GFXBench 
> > 5's
> > Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix 
> > for the
> > number of input components, a fix for KHR_blend_equation_advanced, another 
> > fix
> > in the intel_from_planar, and some other fixes.
> > 
> > In the RADV driver, there is a 3D images copying fix, another to disable tc-
> > compat on multisample d32s8, a fix related with HTILE, and a fix to avoid 
> > hangs
> > on Vega. Also, there is a couple of fixes regarding fences.
> > 
> > R600 driver gets fixes for some hangs related with recip generation, a fix 
> > for
> > XFB stream check, another for indirect UBO access, and a final one for 
> > cubemap
> > arrays.
> > 
> > In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which has 
> > been
> > recently released. Besides those, there are another couple of fixes too.
> > 
> > Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, and
> > RadeonSI.
> > 
> > Fixes also reach Wayland part. There's a fix to use the 
> > wayland-egl-backend.h
> > provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
> > 
> > Just to continue, there are also other framework-specific fixes. There are a
> > bunch of fixes for NIR, fixes for GLSL component.
> > 
> > Finally, and to avoid extending to much the list of fixes, there are several
> > fixes that touches different parts of Mesa that solves different bugs.
> > 
> > Take a look at section "Mesa stable queue" for more information.
> > 
> > 
> > Testing reports/general approval
> > 
> > Any testing reports (or general approval of the state of the branch) will be
> > greatly appreciated.
> > 
> > The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after 
> > 12:00
> > GMT.
> > 
> > If you have any questions or suggestions - be that about the current patch 
> > queue
> > or otherwise, please go ahead.
> > 
> > 
> > Trivial merge conflicts
> > ---
> > 
> > commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> > Author: Dave Airlie 
> > 
> > ac/nir: don't apply slice rounding on txf_ms
> > 
> > (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> > 
> > 
> > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > Author: Daniel Stone 
> > 
> > egl/wayland: Fix ARGB/XRGB transposition in config map
> > 
> > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> > 
> > 
> > commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> > Author: Bas Nieuwenhuizen 
> > 
> > radeonsi: Export signalled sync file instead of -1.
> > 
> > (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> > 
> > squashed with
> > 
> > configure/meson: Bump libdrm_amdgpu version requirement.
> > 
> > (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> > 
> > 
> > commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> > Author: Bas Nieuwenhuizen 
> > 
> > radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
> > 
> > (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
> > 
> > 
> > Cheers,
> > 
> > J.A.
> > 
> > 
> > 
> > Mesa stable queue
> > -
> > 
> > Nominated (9)
> > ==
> > 
> > Alex Smith (1):
> >   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and compressed
> > images
> > 
> > Bas Nieuwenhuizen (1):
> >   997306c031 radv: Increase the number of dynamic uniform buffers.
> 
> To clarify, does "nominated" mean that these will *not* be in 17.3.7? (I 
> guess so since I don't see them on the branch)
> 
> I'd like the above two changes in if possible.
> 

Nominated means that these patches does not enter in this release due they
arrived a bit late, but they are proposed to cherry-pick them for the next
release (in 1 or 2 weeks).


The reason is that some days before this pre-announcement is sent, we close the
list of patches that enter in the release, and we do a lot of testing to verify
nothing is broken). If there's some regression, we just try to fix them. And
when everything is ready, we send the pre-announcement email.


The nominated patches are those that arrive after we close the list, and we are
under the testing process. As we don't want to restart the full process again
and again, we just nominate them for the next release. Otherwise that 

Re: [Mesa-dev] [PATCH v0] nir: mako all the intrinsics

[Rob Clark]

Ok, I came up with:

  https://hastebin.com/bulilojupo.cpp

if you want to double check my methodology.

It spotted a couple small mistakes, which I've fixed up locally.  Will
resend once I finish autotools build support.. hmm, and I guess there
is scons too.. *sigh*

Fwiw, one if the bugs was from this confusion about num_indices:

  /* src[] = { vertex, offset }. const_index[] = { base, component } */
  LOAD(per_vertex_output, 2, 1, BASE, COMPONENT, xx,
NIR_INTRINSIC_CAN_ELIMINATE)

;-)

I *guess* I should assume the original code was correct, and change this to:

  # src[] = { vertex, offset }. const_index[] = { base }
  load("per_vertex_output", 2, [BASE], [CAN_ELIMINATE])

?

BR,
-R


On Fri, Mar 16, 2018 at 7:08 AM, Rob Clark  wrote:
> I haven't done anything to verify yet, but I was thinking along the
> same lines of just hacking up a .c program to compare both sets of
> tables.  There are enough intrinsics, that somewhere I probably
> transcribed one wrong and visual inspection of the tables doesn't seem
> sane ;-)
>
> BR,
> -R
>
> On Fri, Mar 16, 2018 at 1:27 AM, Jason Ekstrand  wrote:
>> I think I like this in principal. One question would be what have you done
>> to verify everything is the same?  When I've done things like this in the
>> past, I've written a bit of C code to compare all the info struct to ensure
>> that the two generate the same thing.
>>
>>
>>
>> On March 15, 2018 18:43:59 Rob Clark  wrote:
>>
>>> I threatened to do this a long time ago.. I probably *should* have done
>>> it a long time ago when there where many fewer intrinsics.  But the
>>> system of macro/#include magic for dealing with intrinsics is a bit
>>> annoying, and python has the nice property of optional fxn params,
>>> making it possible to define new intrinsics while ignoring parameters
>>> that are not applicable (and naming optional params).  And not having to
>>> specify various array lengths explicitly is nice too.
>>>
>>> I think the end result makes it easier to add new intrinsics.
>>> ---
>>> I still need to update autotools build.. but it's late and my wrist
>>> needs a break so I thought I'd send it out as-is to solicit comments
>>> on the py bits, etc
>>>
>>>  src/compiler/nir/meson.build   |  22 +-
>>>  src/compiler/nir/nir.h |   9 -
>>>  src/compiler/nir/nir_builder.h |  27 +-
>>>  src/compiler/nir/nir_builder_opcodes_h.py  |  24 +-
>>>  src/compiler/nir/nir_intrinsics.h  | 540
>>> 
>>>  src/compiler/nir/nir_intrinsics.py | 547
>>> +
>>>  .../nir/{nir_intrinsics.c => nir_intrinsics_c.py}  |  56 +--
>>>  src/compiler/nir/nir_intrinsics_h.py   |  44 ++
>>>  8 files changed, 659 insertions(+), 610 deletions(-)
>>>  delete mode 100644 src/compiler/nir/nir_intrinsics.h
>>>  create mode 100644 src/compiler/nir/nir_intrinsics.py
>>>  rename src/compiler/nir/{nir_intrinsics.c => nir_intrinsics_c.py} (59%)
>>>  create mode 100644 src/compiler/nir/nir_intrinsics_h.py
>>>
>>> diff --git a/src/compiler/nir/meson.build b/src/compiler/nir/meson.build
>>> index a70c236b958..ca9237e2ba3 100644
>>> --- a/src/compiler/nir/meson.build
>>> +++ b/src/compiler/nir/meson.build
>>> @@ -65,6 +65,24 @@ nir_opt_algebraic_c = custom_target(
>>>depend_files : files('nir_algebraic.py'),
>>>  )
>>>
>>> +nir_intrinsics_h = custom_target(
>>> +  'nir_intrinsics.h',
>>> +  input : 'nir_intrinsics_h.py',
>>> +  output : 'nir_intrinsics.h',
>>> +  command : [prog_python2, '@INPUT@'],
>>> +  capture : true,
>>> +  depend_files : files('nir_intrinsics.py'),
>>> +)
>>> +
>>> +nir_intrinsics_c = custom_target(
>>> +  'nir_intrinsic.c',
>>> +  input : 'nir_intrinsics_c.py',
>>> +  output : 'nir_intrinsics.c',
>>> +  command : [prog_python2, '@INPUT@'],
>>> +  capture: true,
>>> +  depend_files : files('nir_intrinsics.py'),
>>> +)
>>> +
>>>  spirv_info_c = custom_target(
>>>'spirv_info.c',
>>>input : files('../spirv/spirv_info_c.py',
>>> '../spirv/spirv.core.grammar.json'),
>>> @@ -96,8 +114,6 @@ files_libnir = files(
>>>'nir_inline_functions.c',
>>>'nir_instr_set.c',
>>>'nir_instr_set.h',
>>> -  'nir_intrinsics.c',
>>> -  'nir_intrinsics.h',
>>>'nir_linking_helpers.c',
>>>'nir_liveness.c',
>>>'nir_loop_analyze.c',
>>> @@ -201,7 +217,7 @@ libnir = static_library(
>>>'nir',
>>>[files_libnir, spirv_info_c, nir_opt_algebraic_c, nir_opcodes_c,
>>> nir_opcodes_h, nir_constant_expressions_c, nir_builder_opcodes_h,
>>> -   vtn_gather_types_c],
>>> +   vtn_gather_types_c, nir_intrinsics_c, nir_intrinsics_h],
>>>include_directories : [inc_common, inc_compiler,
>>> include_directories('../spirv')],
>>>c_args : [c_vis_args, c_msvc_compat_args, no_override_init_args],
>>>link_with : libcompiler,
>>> diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
>>> index 

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Emil Velikov]

On 16 March 2018 at 12:07, Daniel Stone  wrote:
> Hi Juan,
>
> On 16 March 2018 at 11:42, Juan A. Suarez Romero  wrote:
>> Trivial merge conflicts
>> ---
>>
>> [...]
>>
>> commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
>> Author: Daniel Stone 
>>
>> egl/wayland: Fix ARGB/XRGB transposition in config map
>>
>> (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
>
> This commit isn't in the 17.3 branch; was it rebased into another commit?
>
Seems like the sha's are off, although commits and contents seem sane IMHO.
The corrected list is:

commit 6ddf838def69036a48524e2f5ae79fb01170e59c
Author: Bas Nieuwenhuizen 

   radv: Always lower indirect derefs after nir_lower_global_vars_to_local.

   (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)


commit 56a9c6541e96bb08f56c55c0a5047cbd14307d81
Author: Bas Nieuwenhuizen 

   radeonsi: Export signalled sync file instead of -1.

   (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)

   Squashed with:

   configure/meson: Bump libdrm_amdgpu version requirement.

   (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)


commit 2e043c9bcf0182bb631a9ed0c4562775106cd1db
Author: Daniel Stone 

   egl/wayland: Fix ARGB/XRGB transposition in config map

   (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)


commit 1288d1efa851f94ba3c2a591ca32febb6b447ada
Author: Dave Airlie 

   ac/nir: don't apply slice rounding on txf_ms

   (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)


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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 12:07 +, Daniel Stone wrote:
> Hi Juan,
> 
> On 16 March 2018 at 11:42, Juan A. Suarez Romero  wrote:
> > Trivial merge conflicts
> > ---
> > 
> > [...]
> > 
> > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > Author: Daniel Stone 
> > 
> > egl/wayland: Fix ARGB/XRGB transposition in config map
> > 
> > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> 
> This commit isn't in the 17.3 branch; was it rebased into another commit?
> 


Oh, apologies. I think I've committed a mistake when writing the email.

The commitid is wrong, the good one is:


commit 2e043c9bcf0182bb631a9ed0c4562775106cd1db
Author: Daniel Stone 

egl/wayland: Fix ARGB/XRGB transposition in config map

(cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)



J.A.


> Cheers,
> Daniel
> ___
> 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] [ANNOUNCE] Mesa 17.3.7 release candidate

[Emil Velikov]

On 16 March 2018 at 12:17, Alex Smith  wrote:
> Hi Juan,
>
> On 16 March 2018 at 11:42, Juan A. Suarez Romero 
> wrote:
>>
>> Hello list,
>>
>> The candidate for the Mesa 17.3.7 is now available. Currently we have:
>>  - 53 queued
>>  - 9 nominated (outstanding)
>>  - and 6 rejected patches
>>
>>
>> In the current queue we have lot of fixes, as the latest two releases were
>> emergency releases to fix major issues.
>>
>> The i965 receives quite a few of fixes. We have fixes for hangs on
>> GFXBench 5's
>> Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix
>> for the
>> number of input components, a fix for KHR_blend_equation_advanced, another
>> fix
>> in the intel_from_planar, and some other fixes.
>>
>> In the RADV driver, there is a 3D images copying fix, another to disable
>> tc-
>> compat on multisample d32s8, a fix related with HTILE, and a fix to avoid
>> hangs
>> on Vega. Also, there is a couple of fixes regarding fences.
>>
>> R600 driver gets fixes for some hangs related with recip generation, a fix
>> for
>> XFB stream check, another for indirect UBO access, and a final one for
>> cubemap
>> arrays.
>>
>> In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which
>> has been
>> recently released. Besides those, there are another couple of fixes too.
>>
>> Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys,
>> and
>> RadeonSI.
>>
>> Fixes also reach Wayland part. There's a fix to use the
>> wayland-egl-backend.h
>> provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
>>
>> Just to continue, there are also other framework-specific fixes. There are
>> a
>> bunch of fixes for NIR, fixes for GLSL component.
>>
>> Finally, and to avoid extending to much the list of fixes, there are
>> several
>> fixes that touches different parts of Mesa that solves different bugs.
>>
>> Take a look at section "Mesa stable queue" for more information.
>>
>>
>> Testing reports/general approval
>> 
>> Any testing reports (or general approval of the state of the branch) will
>> be
>> greatly appreciated.
>>
>> The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after
>> 12:00
>> GMT.
>>
>> If you have any questions or suggestions - be that about the current patch
>> queue
>> or otherwise, please go ahead.
>>
>>
>> Trivial merge conflicts
>> ---
>>
>> commit fc507dbfd193de5ef09ed2944090e9727820d9ea
>> Author: Dave Airlie 
>>
>> ac/nir: don't apply slice rounding on txf_ms
>>
>> (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
>>
>>
>> commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
>> Author: Daniel Stone 
>>
>> egl/wayland: Fix ARGB/XRGB transposition in config map
>>
>> (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
>>
>>
>> commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
>> Author: Bas Nieuwenhuizen 
>>
>> radeonsi: Export signalled sync file instead of -1.
>>
>> (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
>>
>> squashed with
>>
>> configure/meson: Bump libdrm_amdgpu version requirement.
>>
>> (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
>>
>>
>> commit 6ddf838def69036a48524e2f5ae79fb01170e59c
>> Author: Bas Nieuwenhuizen 
>>
>> radv: Always lower indirect derefs after
>> nir_lower_global_vars_to_local.
>>
>> (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
>>
>>
>> Cheers,
>>
>> J.A.
>>
>>
>>
>> Mesa stable queue
>> -
>>
>> Nominated (9)
>> ==
>>
>> Alex Smith (1):
>>   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and
>> compressed
>> images
>>
>> Bas Nieuwenhuizen (1):
>>   997306c031 radv: Increase the number of dynamic uniform buffers.
>
>
> To clarify, does "nominated" mean that these will *not* be in 17.3.7? (I
> guess so since I don't see them on the branch)
>
Yes, that's correct. The terminology used is explained here [1].
Improvement and alternative suggestions are welcome!

[1] https://www.mesa3d.org/releasing.html#prerelease

> I'd like the above two changes in if possible.
>
Should be fine IMHO - patches are well isolated and self contained.

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Alex Smith]

Hi Juan,

On 16 March 2018 at 11:42, Juan A. Suarez Romero 
wrote:

> Hello list,
>
> The candidate for the Mesa 17.3.7 is now available. Currently we have:
>  - 53 queued
>  - 9 nominated (outstanding)
>  - and 6 rejected patches
>
>
> In the current queue we have lot of fixes, as the latest two releases were
> emergency releases to fix major issues.
>
> The i965 receives quite a few of fixes. We have fixes for hangs on
> GFXBench 5's
> Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix
> for the
> number of input components, a fix for KHR_blend_equation_advanced, another
> fix
> in the intel_from_planar, and some other fixes.
>
> In the RADV driver, there is a 3D images copying fix, another to disable
> tc-
> compat on multisample d32s8, a fix related with HTILE, and a fix to avoid
> hangs
> on Vega. Also, there is a couple of fixes regarding fences.
>
> R600 driver gets fixes for some hangs related with recip generation, a fix
> for
> XFB stream check, another for indirect UBO access, and a final one for
> cubemap
> arrays.
>
> In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which
> has been
> recently released. Besides those, there are another couple of fixes too.
>
> Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, and
> RadeonSI.
>
> Fixes also reach Wayland part. There's a fix to use the
> wayland-egl-backend.h
> provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
>
> Just to continue, there are also other framework-specific fixes. There are
> a
> bunch of fixes for NIR, fixes for GLSL component.
>
> Finally, and to avoid extending to much the list of fixes, there are
> several
> fixes that touches different parts of Mesa that solves different bugs.
>
> Take a look at section "Mesa stable queue" for more information.
>
>
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch) will
> be
> greatly appreciated.
>
> The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after
> 12:00
> GMT.
>
> If you have any questions or suggestions - be that about the current patch
> queue
> or otherwise, please go ahead.
>
>
> Trivial merge conflicts
> ---
>
> commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> Author: Dave Airlie 
>
> ac/nir: don't apply slice rounding on txf_ms
>
> (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
>
>
> commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> Author: Daniel Stone 
>
> egl/wayland: Fix ARGB/XRGB transposition in config map
>
> (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
>
>
> commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> Author: Bas Nieuwenhuizen 
>
> radeonsi: Export signalled sync file instead of -1.
>
> (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
>
> squashed with
>
> configure/meson: Bump libdrm_amdgpu version requirement.
>
> (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
>
>
> commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> Author: Bas Nieuwenhuizen 
>
> radv: Always lower indirect derefs after nir_lower_global_vars_to_
> local.
>
> (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
>
>
> Cheers,
>
> J.A.
>
>
>
> Mesa stable queue
> -
>
> Nominated (9)
> ==
>
> Alex Smith (1):
>   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and compressed
> images
>
> Bas Nieuwenhuizen (1):
>   997306c031 radv: Increase the number of dynamic uniform buffers.
>

To clarify, does "nominated" mean that these will *not* be in 17.3.7? (I
guess so since I don't see them on the branch)

I'd like the above two changes in if possible.

Thanks,
Alex


>
> Dave Airlie (1):
>   5d4fbc2b54 r600: implement callstack workaround for evergreen.
>
> Jordan Justen (2):
>   06e3bd02c0 i965: Hard code CS scratch_ids_per_subslice for Cherryview
>   24b415270f intel/vulkan: Hard code CS scratch_ids_per_subslice for
> Cherryview
>
> Marek Olšák (3):
>   75c5d25f0f radeonsi: align command buffer starting address to fix
> some
> Raven hangs
>   2bdb54bce7 radeonsi: add a workaround for GFX9 hang with init_config
> alignment
>   5d0acff39e configure.ac: blacklist libdrm 2.4.90
>
> Samuel Pitoiset (1):
>   f02f1ad13f Revert "mesa: do not trigger _NEW_TEXTURE_STATE in
> glActiveTexture()"
>
>
> Queued (53)
> ===
>
> Andriy Khulap (1):
>   i965: Fix RELOC_WRITE typo in brw_store_data_imm64()
>
> Anuj Phogat (1):
>   isl: Don't use surface format R32_FLOAT for typed atomic integer
> operations
>
> Bas Nieuwenhuizen (5):
>   radv: Always lower indirect derefs after nir_lower_global_vars_to_
> local.
>   radeonsi: Export signalled sync file instead of -1.
>   

Re: [Mesa-dev] [PATCH] mesa: RGB9_E5 invalid for CopyTexSubImage* in GLES

[Tapani Pälli]

On 03/16/2018 02:10 PM, Juan A. Suarez Romero wrote:

On Fri, 2018-03-16 at 13:25 +0200, Tapani Pälli wrote:


On 03/16/2018 01:13 PM, Tapani Pälli wrote:



On 03/16/2018 01:01 PM, Juan A. Suarez Romero wrote:

On Fri, 2018-03-16 at 08:02 +0200, Tapani Pälli wrote:

On 03/15/2018 02:04 PM, Juan A. Suarez Romero wrote:

According to OpenGL ES 3.2, section 8.6, CopyTexSubImage* should return
an INVALID_OPERATION if the internalformat of the texture is RGB9_E5.

This fixes
dEQP-GLES31.functional.debug.negative_coverage.*.copytexsubimage2d_texture_internalformat.



These tests seem to be passing for me, I believe they fail in
texture_format_error_check_gles. What kind of configuration are you
running on?



Correct. The tests as they are pass, but turns out the tests are
wrong, as they
are not testing what it is supposed to test.

There's a patch to fix them:

https://android-review.googlesource.com/c/platform/external/deqp/+/630411

With the patch applied, now the tests would be failing, and the patch
I've sent
should fix them.



Thanks, this makes sense;
Reviewed-by: Tapani Pälli 


Having said that, it makes me wonder if we have errors in
_mesa_es3_error_check_format_and_type and should we try to fix this
there instead?




_mesa_es3_error_check_format_and_type() do error checking when creating the
texture with glTex[Sub]Image.

In this case, creating the texture with that format is incorrect. What it is
incorrect is trying to copy it later with glCopyTex[Sub]Image*D.

Hence why I'm not do ing the error checking there.


Ah right .. thanks, this fix is correct.



J.A.




 J.A.



---
src/mesa/main/teximage.c | 14 ++
1 file changed, 14 insertions(+)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 928e50d472d..9c13e6d7cf6 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2623,6 +2623,20 @@ copytexsubimage_error_check(struct gl_context
*ctx, GLuint dimensions,
  return GL_TRUE;
   }
+   /* From OpenGL ES 3.2 spec, section 8.6:
+*
+* "An INVALID_OPERATION error is generated by
CopyTexSubImage3D,
+*  CopyTexImage2D, or CopyTexSubImage2D if the
internalformat of the
+*  texture image being (re)specified is RGB9_E5"
+*/
+   if (texImage->InternalFormat == GL_RGB9_E5 &&
+   !_mesa_is_desktop_gl(ctx)) {
+  _mesa_error(ctx, GL_INVALID_OPERATION,
+  "%s(invalid internal format %s)", caller,
+  _mesa_enum_to_string(texImage->InternalFormat));
+  return GL_TRUE;
+   }
+
   if (!_mesa_source_buffer_exists(ctx, texImage->_BaseFormat)) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
  "%s(missing readbuffer, format=%s)", caller,






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




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

[Mesa-dev] [Bug 105551] Unable to compile on FreeBSD 9.x and therefore derivatives... undefined reference to `loader_get_extensions_name'

[bugzilla-daemon]

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

Bug ID: 105551
   Summary: Unable to compile on FreeBSD 9.x and therefore
derivatives... undefined reference to
`loader_get_extensions_name'
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: FreeBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: miche...@sorbs.net
QA Contact: mesa-dev@lists.freedesktop.org

[xexaxo1`] (evelikov@nat/collabora/x-mhqiibpllhmhzjys): Emil Velikov suggested
I should log this as a bug...

Compiling up on FreeBSD 9.3 and derivatives (yes FreeBSD 9.3 is unsupported and
out of release cycle, but I have a derivative based on the same source with the
identical problem.)

Compile fails with:

backends/dri/.libs/gbm_dri.o: In function `dri_open_driver.isra.4':
gbm_dri.c:(.text+0x1417): undefined reference to `loader_get_extensions_name'
backends/dri/.libs/gbm_dri.o: In function `dri_device_create':
gbm_dri.c:(.text+0x19c8): undefined reference to `loader_get_driver_for_fd'
collect2: error: ld returned 1 exit status
Makefile:836: recipe for target 'libgbm.la' failed
gmake: *** [libgbm.la] Error 1
*** [do-build] Error code 2

Logs of the build with V=1 and other logs from the build including the entire
part build tree tarball are here:

http://flashback.sorbs.net/packages/debug/

Problem occurs with 17.1.0 through 17.2.2 (same error on each)

FreeBSD libtool patching has been disabled for the logs.
Patches normally applied to the Source for FreeBSD are in the same directory. 

Thanks for any pointers...

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

Re: [Mesa-dev] [PATCH] mesa: RGB9_E5 invalid for CopyTexSubImage* in GLES

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 13:25 +0200, Tapani Pälli wrote:
> 
> On 03/16/2018 01:13 PM, Tapani Pälli wrote:
> > 
> > 
> > On 03/16/2018 01:01 PM, Juan A. Suarez Romero wrote:
> > > On Fri, 2018-03-16 at 08:02 +0200, Tapani Pälli wrote:
> > > > On 03/15/2018 02:04 PM, Juan A. Suarez Romero wrote:
> > > > > According to OpenGL ES 3.2, section 8.6, CopyTexSubImage* should 
> > > > > return
> > > > > an INVALID_OPERATION if the internalformat of the texture is RGB9_E5.
> > > > > 
> > > > > This fixes
> > > > > dEQP-GLES31.functional.debug.negative_coverage.*.copytexsubimage2d_texture_internalformat.
> > > > >  
> > > > > 
> > > > 
> > > > These tests seem to be passing for me, I believe they fail in
> > > > texture_format_error_check_gles. What kind of configuration are you
> > > > running on?
> > > > 
> > > 
> > > Correct. The tests as they are pass, but turns out the tests are 
> > > wrong, as they
> > > are not testing what it is supposed to test.
> > > 
> > > There's a patch to fix them:
> > > 
> > > https://android-review.googlesource.com/c/platform/external/deqp/+/630411
> > > 
> > > With the patch applied, now the tests would be failing, and the patch 
> > > I've sent
> > > should fix them.
> > > 
> > 
> > Thanks, this makes sense;
> > Reviewed-by: Tapani Pälli 
> 
> Having said that, it makes me wonder if we have errors in 
> _mesa_es3_error_check_format_and_type and should we try to fix this 
> there instead?
> 


_mesa_es3_error_check_format_and_type() do error checking when creating the
texture with glTex[Sub]Image.

In this case, creating the texture with that format is incorrect. What it is
incorrect is trying to copy it later with glCopyTex[Sub]Image*D.

Hence why I'm not do ing the error checking there.

J.A.

> > 
> > > J.A.
> > > 
> > > 
> > > > > ---
> > > > >src/mesa/main/teximage.c | 14 ++
> > > > >1 file changed, 14 insertions(+)
> > > > > 
> > > > > diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> > > > > index 928e50d472d..9c13e6d7cf6 100644
> > > > > --- a/src/mesa/main/teximage.c
> > > > > +++ b/src/mesa/main/teximage.c
> > > > > @@ -2623,6 +2623,20 @@ copytexsubimage_error_check(struct gl_context 
> > > > > *ctx, GLuint dimensions,
> > > > >  return GL_TRUE;
> > > > >   }
> > > > > +   /* From OpenGL ES 3.2 spec, section 8.6:
> > > > > +*
> > > > > +* "An INVALID_OPERATION error is generated by 
> > > > > CopyTexSubImage3D,
> > > > > +*  CopyTexImage2D, or CopyTexSubImage2D if the 
> > > > > internalformat of the
> > > > > +*  texture image being (re)specified is RGB9_E5"
> > > > > +*/
> > > > > +   if (texImage->InternalFormat == GL_RGB9_E5 &&
> > > > > +   !_mesa_is_desktop_gl(ctx)) {
> > > > > +  _mesa_error(ctx, GL_INVALID_OPERATION,
> > > > > +  "%s(invalid internal format %s)", caller,
> > > > > +  _mesa_enum_to_string(texImage->InternalFormat));
> > > > > +  return GL_TRUE;
> > > > > +   }
> > > > > +
> > > > >   if (!_mesa_source_buffer_exists(ctx, texImage->_BaseFormat)) {
> > > > >  _mesa_error(ctx, GL_INVALID_OPERATION,
> > > > >  "%s(missing readbuffer, format=%s)", caller,
> > > > > 
> > > > 
> > > > 
> > 
> > ___
> > 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] [ANNOUNCE] Mesa 17.3.7 release candidate

[Daniel Stone]

Hi Juan,

On 16 March 2018 at 11:42, Juan A. Suarez Romero  wrote:
> Trivial merge conflicts
> ---
>
> [...]
>
> commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> Author: Daniel Stone 
>
> egl/wayland: Fix ARGB/XRGB transposition in config map
>
> (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)

This commit isn't in the 17.3 branch; was it rebased into another commit?

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

Re: [Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

CCing Bas and Anuj.


J.A.

On Fri, 2018-03-16 at 12:49 +0100, Juan A. Suarez Romero wrote:
> On Fri, 2018-03-16 at 12:42 +0100, Juan A. Suarez Romero wrote:
> > Hello list,
> > 
> > The candidate for the Mesa 17.3.7 is now available. Currently we have:
> >  - 53 queued
> >  - 9 nominated (outstanding)
> >  - and 6 rejected patches
> > 
> > 
> > In the current queue we have lot of fixes, as the latest two releases were
> > emergency releases to fix major issues.
> > 
> > The i965 receives quite a few of fixes. We have fixes for hangs on GFXBench 
> > 5's
> > Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix 
> > for the
> > number of input components, a fix for KHR_blend_equation_advanced, another 
> > fix
> > in the intel_from_planar, and some other fixes.
> > 
> > In the RADV driver, there is a 3D images copying fix, another to disable tc-
> > compat on multisample d32s8, a fix related with HTILE, and a fix to avoid 
> > hangs
> > on Vega. Also, there is a couple of fixes regarding fences.
> > 
> > R600 driver gets fixes for some hangs related with recip generation, a fix 
> > for
> > XFB stream check, another for indirect UBO access, and a final one for 
> > cubemap
> > arrays.
> > 
> > In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which has 
> > been
> > recently released. Besides those, there are another couple of fixes too.
> > 
> > Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, and
> > RadeonSI.
> > 
> > Fixes also reach Wayland part. There's a fix to use the 
> > wayland-egl-backend.h
> > provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
> > 
> > Just to continue, there are also other framework-specific fixes. There are a
> > bunch of fixes for NIR, fixes for GLSL component.
> > 
> > Finally, and to avoid extending to much the list of fixes, there are several
> > fixes that touches different parts of Mesa that solves different bugs.
> > 
> > Take a look at section "Mesa stable queue" for more information.
> > 
> > 
> > Testing reports/general approval
> > 
> > Any testing reports (or general approval of the state of the branch) will be
> > greatly appreciated.
> > 
> > The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after 
> > 12:00
> > GMT.
> > 
> 
> The plan is to have 17.3.7 this Monday (19 Mar), around or shortly after 12.00
> GMT.
> 
> 
> > If you have any questions or suggestions - be that about the current patch 
> > queue
> > or otherwise, please go ahead.
> > 
> > 
> > Trivial merge conflicts
> > ---
> > 
> > commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> > Author: Dave Airlie 
> > 
> > ac/nir: don't apply slice rounding on txf_ms
> > 
> > (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> > 
> > 
> > commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> > Author: Daniel Stone 
> > 
> > egl/wayland: Fix ARGB/XRGB transposition in config map
> > 
> > (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> > 
> > 
> > commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> > Author: Bas Nieuwenhuizen 
> > 
> > radeonsi: Export signalled sync file instead of -1.
> > 
> > (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> > 
> > squashed with
> > 
> > configure/meson: Bump libdrm_amdgpu version requirement.
> > 
> > (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> > 
> > 
> > commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> > Author: Bas Nieuwenhuizen 
> > 
> > radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
> > 
> > (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
> > 
> > 
> > Cheers,
> > 
> > J.A.
> > 
> > 
> > 
> > Mesa stable queue
> > -
> > 
> > Nominated (9)
> > ==
> > 
> > Alex Smith (1):
> >   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and compressed
> > images
> > 
> > Bas Nieuwenhuizen (1):
> >   997306c031 radv: Increase the number of dynamic uniform buffers.
> > 
> > Dave Airlie (1):
> >   5d4fbc2b54 r600: implement callstack workaround for evergreen.
> > 
> > Jordan Justen (2):
> >   06e3bd02c0 i965: Hard code CS scratch_ids_per_subslice for Cherryview
> >   24b415270f intel/vulkan: Hard code CS scratch_ids_per_subslice for
> > Cherryview
> > 
> > Marek Olšák (3):
> >   75c5d25f0f radeonsi: align command buffer starting address to fix some
> > Raven hangs
> >   2bdb54bce7 radeonsi: add a workaround for GFX9 hang with init_config
> > alignment
> >   5d0acff39e configure.ac: blacklist libdrm 2.4.90
> > 
> > Samuel Pitoiset (1):
> >   f02f1ad13f Revert "mesa: do not trigger _NEW_TEXTURE_STATE in
> > glActiveTexture()"
> > 
> > 
> > Queued (53)
> > ===
> > 
> > Andriy Khulap (1):
> >   

Re: [Mesa-dev] [PATCH 0/6] Shader cache; transform feedback; i965 program-binary

[Tapani Pälli]

On 03/15/2018 11:07 AM, Tapani Pälli wrote:

Patches 1-3:
Reviewed-by: Tapani Pälli 


Make that the whole series!

I tested also briefly with app that uses glProgramBinary to implement 
cache and verified result of GL_LINK_STATUS query with glGetProgramiv 
after glProgramBinary.




(also verified with xfb using app)

On 03/14/2018 09:26 AM, Jordan Justen wrote:
git://people.freedesktop.org/~jljusten/mesa 
shader-cache-xform-fb+prog-bin-v1


Patches 1 - 3 remove the restriction preventing the disk shader cache
from being enabled if transform feedback is enabled via the GL API.
These patches affect all drivers that support shader cache.

Patches 4 - 6 address an issue I found with i965 when running DOTA2
with the shader cache enabled. It appears that if the shader cache is
enabled, we will never use the shader cache for programs loaded with
ProgramBinary.

We had been setting the LinkStatus to LINKING_SUCCESS, and previously
i965 would skip using the shader cache if the LinkStatus wasn't
LINKING_SKIPPED. Either patch 5 or 6 should address this, but I think
6 still makes sense.

I sent out a related series on Sunday. It turned out that series
triggered issues where if ProgramBinary was used, and transform
feedback was enabled. For this reason, I looked into the transform
feedback limitation addressed in patches 1 - 3.

Jordan Justen (6):
   glsl/shader_cache: Allow shader cache usage with transform feedback
   i965: Allow disk shader cache usage with transform feedback
   glsl: Remove api_enabled tracking for transform feedback
   glsl/serialize: Save shader program metadata sha1
   i965: Allow disk shader cache usage with LINKING_SUCCESS status
   main/program_binary: In ProgramBinary set link status as
 LINKING_SKIPPED

  src/compiler/glsl/link_varyings.cpp    |  2 --
  src/compiler/glsl/linker.cpp   | 11 +--
  src/compiler/glsl/serialize.cpp    |  4 
  src/compiler/glsl/shader_cache.cpp |  6 ++
  src/mesa/drivers/dri/i965/brw_disk_cache.c | 11 ---
  src/mesa/main/mtypes.h |  3 ---
  src/mesa/main/program_binary.c |  2 +-
  7 files changed, 12 insertions(+), 27 deletions(-)


___
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] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

On Fri, 2018-03-16 at 12:42 +0100, Juan A. Suarez Romero wrote:
> Hello list,
> 
> The candidate for the Mesa 17.3.7 is now available. Currently we have:
>  - 53 queued
>  - 9 nominated (outstanding)
>  - and 6 rejected patches
> 
> 
> In the current queue we have lot of fixes, as the latest two releases were
> emergency releases to fix major issues.
> 
> The i965 receives quite a few of fixes. We have fixes for hangs on GFXBench 
> 5's
> Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix for 
> the
> number of input components, a fix for KHR_blend_equation_advanced, another fix
> in the intel_from_planar, and some other fixes.
> 
> In the RADV driver, there is a 3D images copying fix, another to disable tc-
> compat on multisample d32s8, a fix related with HTILE, and a fix to avoid 
> hangs
> on Vega. Also, there is a couple of fixes regarding fences.
> 
> R600 driver gets fixes for some hangs related with recip generation, a fix for
> XFB stream check, another for indirect UBO access, and a final one for cubemap
> arrays.
> 
> In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which has 
> been
> recently released. Besides those, there are another couple of fixes too.
> 
> Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, and
> RadeonSI.
> 
> Fixes also reach Wayland part. There's a fix to use the wayland-egl-backend.h
> provided by Mesa itself, and a fix related with ARGB/XRGB transposition.
> 
> Just to continue, there are also other framework-specific fixes. There are a
> bunch of fixes for NIR, fixes for GLSL component.
> 
> Finally, and to avoid extending to much the list of fixes, there are several
> fixes that touches different parts of Mesa that solves different bugs.
> 
> Take a look at section "Mesa stable queue" for more information.
> 
> 
> Testing reports/general approval
> 
> Any testing reports (or general approval of the state of the branch) will be
> greatly appreciated.
> 
> The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after 12:00
> GMT.
> 

The plan is to have 17.3.7 this Monday (19 Mar), around or shortly after 12.00
GMT.


> If you have any questions or suggestions - be that about the current patch 
> queue
> or otherwise, please go ahead.
> 
> 
> Trivial merge conflicts
> ---
> 
> commit fc507dbfd193de5ef09ed2944090e9727820d9ea
> Author: Dave Airlie 
> 
> ac/nir: don't apply slice rounding on txf_ms
> 
> (cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)
> 
> 
> commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
> Author: Daniel Stone 
> 
> egl/wayland: Fix ARGB/XRGB transposition in config map
> 
> (cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)
> 
> 
> commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
> Author: Bas Nieuwenhuizen 
> 
> radeonsi: Export signalled sync file instead of -1.
> 
> (cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)
> 
> squashed with
> 
> configure/meson: Bump libdrm_amdgpu version requirement.
> 
> (cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)
> 
> 
> commit 6ddf838def69036a48524e2f5ae79fb01170e59c
> Author: Bas Nieuwenhuizen 
> 
> radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
> 
> (cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)
> 
> 
> Cheers,
> 
> J.A.
> 
> 
> 
> Mesa stable queue
> -
> 
> Nominated (9)
> ==
> 
> Alex Smith (1):
>   fcf267ba08 radv: Fix CmdCopyImage between uncompressed and compressed
> images
> 
> Bas Nieuwenhuizen (1):
>   997306c031 radv: Increase the number of dynamic uniform buffers.
> 
> Dave Airlie (1):
>   5d4fbc2b54 r600: implement callstack workaround for evergreen.
> 
> Jordan Justen (2):
>   06e3bd02c0 i965: Hard code CS scratch_ids_per_subslice for Cherryview
>   24b415270f intel/vulkan: Hard code CS scratch_ids_per_subslice for
> Cherryview
> 
> Marek Olšák (3):
>   75c5d25f0f radeonsi: align command buffer starting address to fix some
> Raven hangs
>   2bdb54bce7 radeonsi: add a workaround for GFX9 hang with init_config
> alignment
>   5d0acff39e configure.ac: blacklist libdrm 2.4.90
> 
> Samuel Pitoiset (1):
>   f02f1ad13f Revert "mesa: do not trigger _NEW_TEXTURE_STATE in
> glActiveTexture()"
> 
> 
> Queued (53)
> ===
> 
> Andriy Khulap (1):
>   i965: Fix RELOC_WRITE typo in brw_store_data_imm64()
> 
> Anuj Phogat (1):
>   isl: Don't use surface format R32_FLOAT for typed atomic integer
> operations
> 
> Bas Nieuwenhuizen (5):
>   radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
>   radeonsi: Export signalled sync file instead of -1.
>   radv: Implement WaitForFences with !waitAll.
>   radv: Implement waiting on 

Re: [Mesa-dev] [PATCH 04/11] nir/spirv: add gl_spirv_validation method

[Alejandro Piñeiro]

On 16/03/18 12:39, Rob Clark wrote:
> On Fri, Mar 16, 2018 at 7:27 AM, Alejandro Piñeiro  
> wrote:
>> On 16/03/18 12:11, Rob Clark wrote:
>>> Just curious, how much different is this from what spirv-val does?
>> Well, spirv-val does a full validation of the SPIR-V binary. Here we are
>> just doing the basic validation required by the method
>> glSpecializeShadeARB, introduced by ARB_gl_spirv. That's the reason the
>> method is called gl_spirv_validation and not spirv_validation.
>> Specifically the minimum enough to be able to raise the following
>> possible errors from that method:
>>
>> "INVALID_VALUE is generated if  does not match the
>>  of any OpEntryPoint declaration in the SPIR-V module
>> associated with .
>>
>> INVALID_OPERATION is generated if the  of the
>> OpEntryPoint indicated by  does not match the type
>> of .
>>
>> INVALID_VALUE is generated if any element of 
>> refers to a specialization constant that does not exist in the
>> shader module contained in ."
>>
>>
>> So plenty of invalid SPIR-V binaries would be able to pass that point.
>> And that is "okish" to not check that. Also from ARB_gl_spirv spec:
>>
>>" The OpenGL API expects the SPIR-V module to have already
>> been validated, and can return an error if it discovers anything invalid
>> in the module. An invalid SPIR-V module is allowed to result in
>> undefined behavior."
> ok, if the spec doesn't require full validation and this doesn't
> eventually evolve into a re-implementation of spirv-val, I'm not
> really against it.  

Yes, if that happens, I agree that it doesn't make sense to re-implement
spirv-val.
> But just figured I should point out that I expect
> eventually distro mesa builds will anyways depend on spirv-tools, so
> if that was an easier path I don't see a big issue with a dependency
> on spirv-tools

Out of curiosity: why do you expect that for mesa? FWIW, in the
short-medium term, we are going to send a proposal to piglit for the
ARB_gl_spirv testing, that would include add a spirv-tools dependency on
piglit. But using spirv-tools for the testing part sounds somewhat
straightforward to me. I don't see so obvious the need for mesa, as both
vulkan/ARB_gl_spirv allows a undefined behaviour for invalid SPIR-V.
Unless we are interested in a kind of "safe-mode" were the driver does a
full validation of the SPIR-V shader.

>
> BR,
> -R
>
>>>  We
>>> are going to end up using spirv-tools from clover, so if all of this
>>> is just to avoid a dependency on spirv-tools, is it worth it?
>> As I mentioned, this is basically because we don't need so such deep
>> validation. Perhaps the name is slightly confusing even with the gl_
>> prefix. In any case, note that with this patch we add a big comment
>> (almost a test wall) for this method that explain what it is really
>> validating.
>>> BR,
>>> -R
>>>
>>> On Thu, Mar 8, 2018 at 3:19 AM, Alejandro Piñeiro  
>>> wrote:
 ARB_gl_spirv adds the ability to use SPIR-V binaries, and a new
 method, glSpecializeShader. From OpenGL 4.6 spec, section 7.2.1
"Shader Specialization", error table:

  INVALID_VALUE is generated if  does not name a valid
  entry point for .

  INVALID_VALUE is generated if any element of 
  refers to a specialization constant that does not exist in the
  shader module contained in .""

 But we are not really interested on creating the nir shader at that
 point, and adding nir structures on the gl_program, so at that point
 we are just interested on the error checking.

 So we add a new method focused on just checking those errors. It still
 needs to parse the binary, but skips what it is not needed, and
 doesn't create the nir shader.

 v2: rebase update (spirv_to_nir options added, changes on the warning
 logging, and others)

 v3: include passing options on common initialization, doesn't call
 setjmp on common_initialization

 v4: (after Jason comments):
   * Rename common_initialization to vtn_builder_create
   * Move validation method and their helpers to own source file.
   * Create own handle_constant_decoration_cb instead of reuse existing one

 v5: put vtn_build_create refactoring to their own patch (Jason)
 ---
  src/compiler/Makefile.sources |   1 +
  src/compiler/nir/meson.build  |   1 +
  src/compiler/spirv/gl_spirv.c | 268 
 ++
  src/compiler/spirv/nir_spirv.h|   5 +
  src/compiler/spirv/spirv_to_nir.c |  35 +++--
  src/compiler/spirv/vtn_private.h  |   6 +
  6 files changed, 302 insertions(+), 14 deletions(-)
  create mode 100644 src/compiler/spirv/gl_spirv.c

 diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
 index 

[Mesa-dev] [ANNOUNCE] Mesa 17.3.7 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 17.3.7 is now available. Currently we have:
 - 53 queued
 - 9 nominated (outstanding)
 - and 6 rejected patches


In the current queue we have lot of fixes, as the latest two releases were
emergency releases to fix major issues.

The i965 receives quite a few of fixes. We have fixes for hangs on GFXBench 5's
Aztec Ruins benchmark, a fix for OpenGL CTS test in Haswell, another fix for the
number of input components, a fix for KHR_blend_equation_advanced, another fix
in the intel_from_planar, and some other fixes.

In the RADV driver, there is a 3D images copying fix, another to disable tc-
compat on multisample d32s8, a fix related with HTILE, and a fix to avoid hangs
on Vega. Also, there is a couple of fixes regarding fences.

R600 driver gets fixes for some hangs related with recip generation, a fix for
XFB stream check, another for indirect UBO access, and a final one for cubemap
arrays.

In SWR/Rast driver we have a couple of fixes when using LLVM 6.0, which has been
recently released. Besides those, there are another couple of fixes too.

Finally, there a some fixes for other drivers like Virgl, NVC0, Winsys, and
RadeonSI.

Fixes also reach Wayland part. There's a fix to use the wayland-egl-backend.h
provided by Mesa itself, and a fix related with ARGB/XRGB transposition.

Just to continue, there are also other framework-specific fixes. There are a
bunch of fixes for NIR, fixes for GLSL component.

Finally, and to avoid extending to much the list of fixes, there are several
fixes that touches different parts of Mesa that solves different bugs.

Take a look at section "Mesa stable queue" for more information.


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 17.3.7 this XXX (XXth Mar), around or shortly after 12:00
GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---

commit fc507dbfd193de5ef09ed2944090e9727820d9ea
Author: Dave Airlie 

ac/nir: don't apply slice rounding on txf_ms

(cherry picked from commit 69495b30a38fbb01a937cdea6f7674f89a2e60e7)


commit 5fd11359b66c8138d2c7ee29bd9740280b02d1e2
Author: Daniel Stone 

egl/wayland: Fix ARGB/XRGB transposition in config map

(cherry picked from commit 4fbd2d50b1c06a3c10f3a254e933646345123751)


commit 7f4a0a16284391f802a11717fa74ba5e13cbe43b
Author: Bas Nieuwenhuizen 

radeonsi: Export signalled sync file instead of -1.

(cherry picked from commit 5a3404d443e0c6e8e9a44d7f8dccf96c5ac18f0f)

squashed with

configure/meson: Bump libdrm_amdgpu version requirement.

(cherry picked from commit 52be440f48ac7c337f6604846bb6f0cfd88e7118)


commit 6ddf838def69036a48524e2f5ae79fb01170e59c
Author: Bas Nieuwenhuizen 

radv: Always lower indirect derefs after nir_lower_global_vars_to_local.

(cherry picked from commit 05d84ed68add9e6adfcc602a274405e04226c1b7)


Cheers,

J.A.



Mesa stable queue
-

Nominated (9)
==

Alex Smith (1):
  fcf267ba08 radv: Fix CmdCopyImage between uncompressed and compressed
images

Bas Nieuwenhuizen (1):
  997306c031 radv: Increase the number of dynamic uniform buffers.

Dave Airlie (1):
  5d4fbc2b54 r600: implement callstack workaround for evergreen.

Jordan Justen (2):
  06e3bd02c0 i965: Hard code CS scratch_ids_per_subslice for Cherryview
  24b415270f intel/vulkan: Hard code CS scratch_ids_per_subslice for
Cherryview

Marek Olšák (3):
  75c5d25f0f radeonsi: align command buffer starting address to fix some
Raven hangs
  2bdb54bce7 radeonsi: add a workaround for GFX9 hang with init_config
alignment
  5d0acff39e configure.ac: blacklist libdrm 2.4.90

Samuel Pitoiset (1):
  f02f1ad13f Revert "mesa: do not trigger _NEW_TEXTURE_STATE in
glActiveTexture()"


Queued (53)
===

Andriy Khulap (1):
  i965: Fix RELOC_WRITE typo in brw_store_data_imm64()

Anuj Phogat (1):
  isl: Don't use surface format R32_FLOAT for typed atomic integer
operations

Bas Nieuwenhuizen (5):
  radv: Always lower indirect derefs after nir_lower_global_vars_to_local.
  radeonsi: Export signalled sync file instead of -1.
  radv: Implement WaitForFences with !waitAll.
  radv: Implement waiting on non-submitted fences.
  radv: Fix copying from 3D images starting at non-zero depth.

Brian Paul (1):
  mesa: add missing switch case for EXTRA_VERSION_40 in check_extra()

Chuck Atkins (1):
  glx: Properly handle cases where screen creation fails

Daniel Stone (3):
  i965: Fix bugs in intel_from_planar
  egl/wayland: Fix ARGB/XRGB transposition in config map
  egl/wayland: Always use in-tree wayland-egl-backend.h

Dave Airlie (8):
  r600: