Re: [Mesa-dev] [PATCH 35/38] ac,radv: run LLVM's SLP vectorizer

[Marek Olšák]

Can you remove AC_TM_SLP_VECTORIZE and run the pass unconditionally on >=
gfx9?

Thanks,
Marek

On Fri, Dec 7, 2018 at 12:23 PM Rhys Perry  wrote:

> Signed-off-by: Rhys Perry 
> ---
>  src/amd/common/ac_llvm_util.c | 9 ++---
>  src/amd/common/ac_llvm_util.h | 1 +
>  src/amd/vulkan/radv_shader.c  | 3 +++
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
> index dc9b684e9d..3219126188 100644
> --- a/src/amd/common/ac_llvm_util.c
> +++ b/src/amd/common/ac_llvm_util.c
> @@ -33,6 +33,7 @@
>  #if HAVE_LLVM >= 0x0700
>  #include 
>  #endif
> +#include 
>  #include "c11/threads.h"
>  #include "gallivm/lp_bld_misc.h"
>  #include "util/u_math.h"
> @@ -177,7 +178,7 @@ static LLVMTargetMachineRef
> ac_create_target_machine(enum radeon_family family,
>  }
>
>  static LLVMPassManagerRef ac_create_passmgr(LLVMTargetLibraryInfoRef
> target_library_info,
> -   bool check_ir)
> +   enum ac_target_machine_options
> tm_options)
>  {
> LLVMPassManagerRef passmgr = LLVMCreatePassManager();
> if (!passmgr)
> @@ -187,7 +188,7 @@ static LLVMPassManagerRef
> ac_create_passmgr(LLVMTargetLibraryInfoRef target_libr
> LLVMAddTargetLibraryInfo(target_library_info,
>  passmgr);
>
> -   if (check_ir)
> +   if (tm_options & AC_TM_CHECK_IR)
> LLVMAddVerifierPass(passmgr);
> LLVMAddAlwaysInlinerPass(passmgr);
> /* Normally, the pass manager runs all passes on one function
> before
> @@ -203,6 +204,8 @@ static LLVMPassManagerRef
> ac_create_passmgr(LLVMTargetLibraryInfoRef target_libr
> LLVMAddLICMPass(passmgr);
> LLVMAddAggressiveDCEPass(passmgr);
> LLVMAddCFGSimplificationPass(passmgr);
> +   if (tm_options & AC_TM_SLP_VECTORIZE)
> +   LLVMAddSLPVectorizePass(passmgr);
> /* This is recommended by the instruction combining pass. */
> LLVMAddEarlyCSEMemSSAPass(passmgr);
> LLVMAddInstructionCombiningPass(passmgr);
> @@ -332,7 +335,7 @@ ac_init_llvm_compiler(struct ac_llvm_compiler
> *compiler,
> }
>
> compiler->passmgr =
> ac_create_passmgr(compiler->target_library_info,
> - tm_options & AC_TM_CHECK_IR);
> + tm_options);
> if (!compiler->passmgr)
> goto fail;
>
> diff --git a/src/amd/common/ac_llvm_util.h b/src/amd/common/ac_llvm_util.h
> index eaf5f21876..35b12c6c6c 100644
> --- a/src/amd/common/ac_llvm_util.h
> +++ b/src/amd/common/ac_llvm_util.h
> @@ -65,6 +65,7 @@ enum ac_target_machine_options {
> AC_TM_CHECK_IR = (1 << 5),
> AC_TM_ENABLE_GLOBAL_ISEL = (1 << 6),
> AC_TM_CREATE_LOW_OPT = (1 << 7),
> +   AC_TM_SLP_VECTORIZE = (1 << 8),
>  };
>
>  enum ac_float_mode {
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 9ba20ac72e..a2ddf17680 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -598,6 +598,9 @@ shader_variant_create(struct radv_device *device,
> tm_options |= AC_TM_SISCHED;
> if (options->check_ir)
> tm_options |= AC_TM_CHECK_IR;
> +   /* vectorization is disabled on pre-GFX9 because it's not very
> useful there */
> +   if (device->physical_device->rad_info.chip_class >= GFX9)
> +   tm_options |= AC_TM_SLP_VECTORIZE;
>
> thread_compiler = !(device->instance->debug_flags &
> RADV_DEBUG_NOTHREADLLVM);
> radv_init_llvm_once();
> --
> 2.19.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 26/38] ac/nir: implement 8 and 16 bit ac_build_imsb

[Marek Olšák]

On Fri, Dec 7, 2018 at 12:23 PM Rhys Perry  wrote:

> Signed-off-by: Rhys Perry 
> ---
>  src/amd/common/ac_llvm_build.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> index 0123f3e31d..2172d81f8b 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -1640,6 +1640,10 @@ ac_build_imsb(struct ac_llvm_context *ctx,
>   LLVMValueRef arg,
>   LLVMTypeRef dst_type)
>  {
> +   //TODO: support 64-bit integers
>

I guess the C++ style comment is unintentional.

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

Re: [Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd

[Timo Aaltonen]

On 18.12.2018 7.52, Stuart Young wrote:
> Hi Dylan,
> 
> Can't speak on Timo's behalf, but looking at the build logs for 18.3.0
> (which is patched with these patches), it built fine on ppc64el (Little
> Endian PPC64), but hurd is having issues, tho it looks like it's not
> directly related to the patch you provided.

Yes, sorry about the delay.. the patches work, Hurd failure is not
related to meson anymore..

> Seems like the issue is that hurd is falling through the tests in
> src/util/os_misc.c: In function ‘os_get_total_physical_memory’
> 
> ...and ends up bailing out with:
> 
> src/util/os_misc.c:173:2: error: #error unexpected platform in os_sysinfo.c

..but that this was not built on Hurd before 18.3, so needs support for
it there.


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

Re: [Mesa-dev] [PATCH v2 29/29] nir/algebraic: Add some optimizations for D3D-style Booleans

[Timothy Arceri]

On 7/12/18 6:45 am, Jason Ekstrand wrote:

D3D Booleans use a 32-bit 0/-1 representation.  Because this previously
matched NIR exactly, we didn't have to really optimize for it.  Now that
we have 1-bit Booleans, we need some specific optimizations to chew
through the D3D12-style Booleans.

Shader-db results on Kaby Lake:

 total instructions in shared programs: 15136811 -> 14967944 (-1.12%)
 instructions in affected programs: 2457021 -> 2288154 (-6.87%)
 helped: 8318
 HURT: 10

 total cycles in shared programs: 373544524 -> 359701825 (-3.71%)
 cycles in affected programs: 151029683 -> 137186984 (-9.17%)
 helped: 7749
 HURT: 682

 total loops in shared programs: 4431 -> 4399 (-0.72%)
 loops in affected programs: 32 -> 0
 helped: 21
 HURT: 0

 total spills in shared programs: 10290 -> 10051 (-2.32%)
 spills in affected programs: 2532 -> 2293 (-9.44%)
 helped: 18
 HURT: 18

 total fills in shared programs: 22203 -> 21732 (-2.12%)
 fills in affected programs: 3319 -> 2848 (-14.19%)
 helped: 18
 HURT: 18

Note that a large chunk of the improvement fixing regressions caused by
switching to 1-bit Booleans.  Previously, our ability to optimize D3D
booleans was improved by using the D3D representation directly in NIR.
How that NIR does 1-bit bools, we need a few more optimizations.

Reviewed-by: Bas Nieuwenhuizen 
---
  src/compiler/nir/nir_opt_algebraic.py | 13 +
  1 file changed, 13 insertions(+)

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 3c8af4692b5..506d45e55b5 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -534,6 +534,19 @@ optimizations = [
 (('bcsel', a, b, b), b),
 (('fcsel', a, b, b), b),
  
+   # D3D Boolean emulation

+   (('bcsel', a, -1, 0), ('ineg', ('b2i', 'a@1'))),
+   (('bcsel', a, 0, -1), ('ineg', ('b2i', ('inot', a,
+   (('iand', ('ineg', ('b2i', 'a@1')), ('ineg', ('b2i', 'b@1'))),
+('ineg', ('b2i', ('iand', a, b,
+   (('ior', ('ineg', ('b2i','a@1')), ('ineg', ('b2i', 'b@1'))),
+('ineg', ('b2i', ('ior', a, b,
+   (('ieq', ('ineg', ('b2i', 'a@1')), 0), ('inot', a)),
+   (('ieq', ('ineg', ('b2i', 'a@1')), -1), a),
+   (('ine', ('ineg', ('b2i', 'a@1')), 0), a),
+   (('ine', ('ineg', ('b2i', 'a@1')), -1), ('inot', a)),
+   (('iand', ('ineg', ('b2i', a)), '1.0@32'), ('b2f', a)),


Hi Jason,

It seems the '1.0@32' matching has been broken somewhere along the line 
in the recent rewrites. See my comments in the RADV bug for more info.


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




+
 # Conversions
 (('i2b32', ('b2i', 'a@32')), a),
 (('f2i', ('ftrunc', a)), ('f2i', a)),


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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #4 from Timothy Arceri  ---
It looks like the '1.0@32' part of the search is failing. It also seems this is
the only opt that looks for a constant in the whole file. Everything else looks
for variables or ops e.g. 'a@32', 'bcsel@32'

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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #3 from Timothy Arceri  ---
Maybe getting stuck in a infinite loop?

There is a loop exit condition in the witcher where the optimise the following: 

/* preds: block_3 */
vec2 32 ssa_114 = vec2 ssa_105, ssa_4
vec4 32 ssa_115 = txf ssa_95 (texture_deref), ssa_114 (coord),
ssa_4 (lod), 0 (sampler), 
vec1 1 ssa_120 = flt ssa_115.x, ssa_93
vec1 1 ssa_121 = flt ssa_115.y, ssa_94
vec1 32 ssa_122 = b2i32 ssa_120
vec1 32 ssa_123 = ineg ssa_122
vec1 32 ssa_125 = b2i32 ssa_121
vec1 32 ssa_126 = ineg ssa_125
vec1 1 ssa_128 = flt ssa_93, ssa_115.z
vec1 1 ssa_129 = flt ssa_94, ssa_115.w
vec1 32 ssa_130 = b2i32 ssa_128
vec1 32 ssa_131 = ineg ssa_130
vec1 32 ssa_133 = b2i32 ssa_129
vec1 32 ssa_134 = ineg ssa_133
vec1 32 ssa_136 = iand ssa_123, ssa_131
vec1 32 ssa_137 = iand ssa_126, ssa_136
vec1 32 ssa_138 = iand ssa_134, ssa_137
vec1 1 ssa_139 = ine ssa_138, ssa_4

to:

vec2 32 ssa_87 = vec2 ssa_84, ssa_4
vec4 32 ssa_88 = txf ssa_82 (texture_deref), ssa_87 (coord),
ssa_4 (lod), 0 (sampler),
vec1 1 ssa_89 = flt ssa_88.x, ssa_80
vec1 1 ssa_90 = flt ssa_88.y, ssa_81
vec1 32 ssa_91 = b2i32 ssa_89
vec1 32 ssa_92 = ineg ssa_91
vec1 32 ssa_93 = b2i32 ssa_90
vec1 32 ssa_94 = ineg ssa_93
vec1 1 ssa_95 = flt ssa_80, ssa_88.z
vec1 1 ssa_96 = flt ssa_81, ssa_88.w
vec1 32 ssa_97 = b2i32 ssa_95
vec1 32 ssa_98 = ineg ssa_97
vec1 32 ssa_99 = b2i32 ssa_96
vec1 32 ssa_100 = ineg ssa_99
vec1 1 ssa_101 = iand ssa_89, ssa_95
vec1 32 ssa_102 = b2i32 ssa_101
vec1 32 ssa_103 = ineg ssa_102
vec1 32 ssa_104 = imov ssa_103
vec1 32 ssa_105 = b2f32 ssa_90
vec1 32 ssa_106 = imov ssa_105
vec1 32 ssa_107 = b2f32 ssa_96
vec1 32 ssa_108 = imov ssa_107
vec1 1 ssa_109 = ine ssa_108, ssa_4

Which ends up as:

vec2 32 ssa_71 = vec2 ssa_69, ssa_4
vec4 32 ssa_72 = txf ssa_67 (texture_deref), ssa_71 (coord),
ssa_4 (lod), 0 (sampler), 
vec1 32 ssa_73 = flt32 ssa_66, ssa_72.w
vec1 32 ssa_74 = b2f32 ssa_73
vec1 32 ssa_75 = ine32 ssa_74, ssa_4

With the offending opt commented out we end up with:

vec2 32 ssa_76 = vec2 ssa_74, ssa_4
vec4 32 ssa_77 = txf ssa_72 (texture_deref), ssa_76 (coord),
ssa_4 (lod), 0 (sampler), 
vec1 32 ssa_78 = flt32 ssa_77.x, ssa_70
vec1 32 ssa_79 = flt32 ssa_77.y, ssa_71
vec1 32 ssa_80 = flt32 ssa_70, ssa_77.z
vec1 32 ssa_81 = flt32 ssa_71, ssa_77.w
vec1 32 ssa_82 = iand ssa_78, ssa_80
vec1 32 ssa_83 = iand ssa_79, ssa_82
vec1 32 ssa_84 = iand ssa_81, ssa_83

-- 
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 0/5] Fixueps for ppc64 and gnu hurd

[Stuart Young]

Hi Dylan,

Can't speak on Timo's behalf, but looking at the build logs for 18.3.0
(which is patched with these patches), it built fine on ppc64el (Little
Endian PPC64), but hurd is having issues, tho it looks like it's not
directly related to the patch you provided.

Seems like the issue is that hurd is falling through the tests in
src/util/os_misc.c: In function ‘os_get_total_physical_memory’

...and ends up bailing out with:

src/util/os_misc.c:173:2: error: #error unexpected platform in os_sysinfo.c

Build log output for that specific build on hurd here:
https://buildd.debian.org/status/fetch.php?pkg=mesa=hurd-i386=18.3.0-1=1544515311=0


On Tue, 18 Dec 2018 at 04:11, Dylan Baker  wrote:

> Quoting Timo Aaltonen (2018-12-05 03:56:54)
> > On 4.12.2018 23.52, Dylan Baker wrote:
> > > This little series is aimed at fixing problems reported by fedora and
> debian
> > > when using meson, there's a couple of patches in here for fixing ppc64
> detection
> > > (tested without llvm), and a couple for gnu hurd (not tested).
> > >
> > > Dylan Baker (5):
> > >   meson: remove duplicate definition
> > >   meson: Fix ppc64 little endian detection
> > >   meson: Override C++ standard to gnu++11 when building with altivec on
> > > ppc64le
> > >   meson: Add support for gnu hurd
> > >   meson: Add toggle for glx-direct
> > >
> > >  meson.build   | 33 ---
> > >  meson_options.txt |  6 
> > >  src/gallium/state_trackers/clover/meson.build |  3 ++
> > >  3 files changed, 31 insertions(+), 11 deletions(-)
> > >
> >
> > Thanks, I'll give these a try soon.
> >
> > --
> > t
>
> Ping
>


-- 
Stuart Young (aka Cefiar)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #2 from Jason Ekstrand  ---
This is really weird because, of all the optimizations in that commit, that is
the one that's NOT new.  It wasn't in that exact form but we definitely had
that optimization before my 1-bit booleans series.  Maybe some other change
made it suddenly trigger in a new place and cascade into additional
optimization?

-- 
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 7/7] nir/dead_write_vars: Get modes directly from derefs

[Timothy Arceri]

Series:

Reviewed-by: Timothy Arceri 

On 18/12/18 3:44 pm, Jason Ekstrand wrote:

Instead of going all the way back to the variable, just look at the
deref.  The modes are guaranteed to be the same by nir_validate whenever
the variable can be found.  This fixes clear_unused_for_modes for
derefs that don't have an accessible variable.
---
  src/compiler/nir/nir_opt_dead_write_vars.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_dead_write_vars.c 
b/src/compiler/nir/nir_opt_dead_write_vars.c
index d43bf5c1193..2ae5f78b791 100644
--- a/src/compiler/nir/nir_opt_dead_write_vars.c
+++ b/src/compiler/nir/nir_opt_dead_write_vars.c
@@ -56,8 +56,7 @@ static void
  clear_unused_for_modes(struct util_dynarray *unused_writes, nir_variable_mode 
modes)
  {
 util_dynarray_foreach_reverse(unused_writes, struct write_entry, entry) {
-  nir_variable *var = nir_deref_instr_get_variable(entry->dst);
-  if (var->data.mode & modes)
+  if (entry->dst->mode & modes)
   *entry = util_dynarray_pop(unused_writes, struct write_entry);
 }
  }


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

[Mesa-dev] [PATCH 3/7] nir/lower_io_arrays_to_elements: Look at derefs for modes

[Jason Ekstrand]

This is instead of looking all the way back to the variable which may
not exist for all derefs.  This makes this code properly ignore casts
with modes other than the mode[s] we care about (where casts aren't
allowed).
---
 src/compiler/nir/nir_lower_io_arrays_to_elements.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/compiler/nir/nir_lower_io_arrays_to_elements.c 
b/src/compiler/nir/nir_lower_io_arrays_to_elements.c
index b9b3cdb2335..34020249199 100644
--- a/src/compiler/nir/nir_lower_io_arrays_to_elements.c
+++ b/src/compiler/nir/nir_lower_io_arrays_to_elements.c
@@ -227,11 +227,11 @@ create_indirects_mask(nir_shader *shader, uint64_t 
*indirects,
   continue;
 
nir_deref_instr *deref = nir_src_as_deref(intr->src[0]);
-   nir_variable *var = nir_deref_instr_get_variable(deref);
-
-   if (var->data.mode != mode)
+   if (deref->mode != mode)
   continue;
 
+   nir_variable *var = nir_deref_instr_get_variable(deref);
+
nir_deref_path path;
nir_deref_path_init(, deref, NULL);
 
@@ -276,8 +276,11 @@ lower_io_arrays_to_elements(nir_shader *shader, 
nir_variable_mode mask,
intr->intrinsic != nir_intrinsic_interp_deref_at_offset)
   continue;
 
-   nir_variable *var =
-  nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));
+   nir_deref_instr *deref = nir_src_as_deref(intr->src[0]);
+   if (!(deref->mode & mask))
+  continue;
+
+   nir_variable *var = nir_deref_instr_get_variable(deref);
 
/* Skip indirects */
uint64_t loc_mask = ((uint64_t)1) << var->data.location;
-- 
2.19.2

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

[Mesa-dev] [PATCH 6/7] nir/copy_prop_vars: Get modes directly from derefs

[Jason Ekstrand]

Instead of going all the way back to the variable, just look at the
deref.  The modes are guaranteed to be the same by nir_validate whenever
the variable can be found.  This fixes apply_barrier_for_modes for
derefs that don't have an accessible variable.
---
 src/compiler/nir/nir_opt_copy_prop_vars.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c 
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 8a015eabf95..533bdba52a5 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -337,12 +337,8 @@ apply_barrier_for_modes(struct util_dynarray *copies,
 nir_variable_mode modes)
 {
util_dynarray_foreach_reverse(copies, struct copy_entry, iter) {
-  nir_variable *dst_var = nir_deref_instr_get_variable(iter->dst);
-  nir_variable *src_var = iter->src.is_ssa ? NULL :
- nir_deref_instr_get_variable(iter->src.deref);
-
-  if ((dst_var->data.mode & modes) ||
-  (src_var && (src_var->data.mode & modes)))
+  if ((iter->dst->mode & modes) ||
+  (iter->src.is_ssa && (iter->src.deref->mode & modes)))
  copy_entry_remove(copies, iter);
}
 }
-- 
2.19.2

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

[Mesa-dev] [PATCH 7/7] nir/dead_write_vars: Get modes directly from derefs

[Jason Ekstrand]

Instead of going all the way back to the variable, just look at the
deref.  The modes are guaranteed to be the same by nir_validate whenever
the variable can be found.  This fixes clear_unused_for_modes for
derefs that don't have an accessible variable.
---
 src/compiler/nir/nir_opt_dead_write_vars.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_dead_write_vars.c 
b/src/compiler/nir/nir_opt_dead_write_vars.c
index d43bf5c1193..2ae5f78b791 100644
--- a/src/compiler/nir/nir_opt_dead_write_vars.c
+++ b/src/compiler/nir/nir_opt_dead_write_vars.c
@@ -56,8 +56,7 @@ static void
 clear_unused_for_modes(struct util_dynarray *unused_writes, nir_variable_mode 
modes)
 {
util_dynarray_foreach_reverse(unused_writes, struct write_entry, entry) {
-  nir_variable *var = nir_deref_instr_get_variable(entry->dst);
-  if (var->data.mode & modes)
+  if (entry->dst->mode & modes)
  *entry = util_dynarray_pop(unused_writes, struct write_entry);
}
 }
-- 
2.19.2

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

[Mesa-dev] [PATCH 5/7] nir/lower_wpos_center: Look at derefs for modes

[Jason Ekstrand]

This is instead of looking all the way back to the variable which may
not exist for all derefs.  This makes this code properly ignore casts
with modes other than the mode[s] we care about (where casts aren't
allowed).
---
 src/compiler/nir/nir_lower_wpos_center.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_lower_wpos_center.c 
b/src/compiler/nir/nir_lower_wpos_center.c
index 74f4d2a9701..3c114936f7e 100644
--- a/src/compiler/nir/nir_lower_wpos_center.c
+++ b/src/compiler/nir/nir_lower_wpos_center.c
@@ -82,10 +82,12 @@ lower_wpos_center_block(nir_builder *b, nir_block *block,
  nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
  if (intr->intrinsic == nir_intrinsic_load_deref) {
 nir_deref_instr *deref = nir_src_as_deref(intr->src[0]);
+if (deref->mode != nir_var_shader_in)
+   continue;
+
 nir_variable *var = nir_deref_instr_get_variable(deref);
 
-if (var->data.mode == nir_var_shader_in &&
-var->data.location == VARYING_SLOT_POS) {
+if (var->data.location == VARYING_SLOT_POS) {
/* gl_FragCoord should not have array/struct derefs: */
assert(deref->deref_type == nir_deref_type_var);
update_fragcoord(b, intr, for_sample_shading);
-- 
2.19.2

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

[Mesa-dev] [PATCH 0/7] nir: Prepare various passes for cast derefs

[Jason Ekstrand]

In order to be able to use derefs for UBOs and SSBOs and actually pass them
through optimizations, various things need to be fixed up to properly
handle casts.  Because casts are only going to be allowed on UBOs, SSBOs,
and maybe shared variables at present, most of the time it's as simple as
making pass bail a tiny bit earlier by checking the deref mode before
looking for the variable.

Cc: Timothy Arceri 

Jason Ekstrand (7):
  nir/propagate_invariant: Skip unknown vars
  nir/linking_helpers: Look at derefs for modes
  nir/lower_io_arrays_to_elements: Look at derefs for modes
  nir/lower_io_to_scalar: Look at derefs for modes
  nir/lower_wpos_center: Look at derefs for modes
  nir/copy_prop_vars: Get modes directly from derefs
  nir/dead_write_vars: Get modes directly from derefs

 src/compiler/nir/nir_linking_helpers.c| 23 +--
 .../nir/nir_lower_io_arrays_to_elements.c | 13 +++
 src/compiler/nir/nir_lower_io_to_scalar.c |  9 +---
 src/compiler/nir/nir_lower_wpos_center.c  |  6 +++--
 src/compiler/nir/nir_opt_copy_prop_vars.c |  8 ++-
 src/compiler/nir/nir_opt_dead_write_vars.c|  3 +--
 src/compiler/nir/nir_propagate_invariant.c|  2 +-
 7 files changed, 33 insertions(+), 31 deletions(-)

-- 
2.19.2

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

[Mesa-dev] [PATCH 4/7] nir/lower_io_to_scalar: Look at derefs for modes

[Jason Ekstrand]

This is instead of looking all the way back to the variable which may
not exist for all derefs.  This makes this code properly ignore casts
with modes other than the mode[s] we care about (where casts aren't
allowed).
---
 src/compiler/nir/nir_lower_io_to_scalar.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_lower_io_to_scalar.c 
b/src/compiler/nir/nir_lower_io_to_scalar.c
index 929761fa888..d58805294b5 100644
--- a/src/compiler/nir/nir_lower_io_to_scalar.c
+++ b/src/compiler/nir/nir_lower_io_to_scalar.c
@@ -308,9 +308,12 @@ nir_lower_io_to_scalar_early(nir_shader *shader, 
nir_variable_mode mask)
intr->intrinsic != nir_intrinsic_interp_deref_at_offset)
   continue;
 
-   nir_variable *var =
-  nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));
-   nir_variable_mode mode = var->data.mode;
+   nir_deref_instr *deref = nir_src_as_deref(intr->src[0]);
+   nir_variable_mode mode = deref->mode;
+   if (!(mode & mask))
+  continue;
+
+   nir_variable *var = nir_deref_instr_get_variable(deref);
 
/* TODO: add patch support */
if (var->data.patch)
-- 
2.19.2

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

[Mesa-dev] [PATCH 2/7] nir/linking_helpers: Look at derefs for modes

[Jason Ekstrand]

This is instead of looking all the way back to the variable which may
not exist for all derefs.  This makes this code properly ignore casts
with modes other than the mode[s] we care about (where casts aren't
allowed).
---
 src/compiler/nir/nir_linking_helpers.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index 1ab9c095657..ffe2d370226 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -75,12 +75,11 @@ tcs_add_output_reads(nir_shader *shader, uint64_t *read, 
uint64_t *patches_read)
 if (intrin->intrinsic != nir_intrinsic_load_deref)
continue;
 
-nir_variable *var =
-   nir_deref_instr_get_variable(nir_src_as_deref(intrin->src[0]));
-
-if (var->data.mode != nir_var_shader_out)
+nir_deref_instr *deref = nir_src_as_deref(intrin->src[0]);
+if (deref->mode != nir_var_shader_out)
continue;
 
+nir_variable *var = nir_deref_instr_get_variable(deref);
 if (var->data.patch) {
patches_read[var->data.location_frac] |=
   get_variable_io_mask(var, shader->info.stage);
@@ -565,12 +564,12 @@ static bool
 try_replace_constant_input(nir_shader *shader,
nir_intrinsic_instr *store_intr)
 {
-   nir_variable *out_var =
-  nir_deref_instr_get_variable(nir_src_as_deref(store_intr->src[0]));
-
-   if (out_var->data.mode != nir_var_shader_out)
+   nir_deref_instr *out_deref = nir_src_as_deref(store_intr->src[0]);
+   if (out_deref->mode != nir_var_shader_out)
   return false;
 
+   nir_variable *out_var = nir_deref_instr_get_variable(out_deref);
+
/* Skip types that require more complex handling.
 * TODO: add support for these types.
 */
@@ -605,12 +604,12 @@ try_replace_constant_input(nir_shader *shader,
  if (intr->intrinsic != nir_intrinsic_load_deref)
 continue;
 
- nir_variable *in_var =
-nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));
-
- if (in_var->data.mode != nir_var_shader_in)
+ nir_deref_instr *in_deref = nir_src_as_deref(intr->src[0]);
+ if (in_deref->mode != nir_var_shader_in)
 continue;
 
+ nir_variable *in_var = nir_deref_instr_get_variable(in_deref);
+
  if (in_var->data.location != out_var->data.location ||
  in_var->data.location_frac != out_var->data.location_frac)
 continue;
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/7] nir/propagate_invariant: Skip unknown vars

[Jason Ekstrand]

If we can't find the variable from the deref, just assume it isn't
invariant and continue on.  This can happen if, for instance, we're
writing to a deref that points into an SSBO.
---
 src/compiler/nir/nir_propagate_invariant.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_propagate_invariant.c 
b/src/compiler/nir/nir_propagate_invariant.c
index eb858f50f03..7e253492ba8 100644
--- a/src/compiler/nir/nir_propagate_invariant.c
+++ b/src/compiler/nir/nir_propagate_invariant.c
@@ -71,7 +71,7 @@ add_var(nir_variable *var, struct set *invariants)
 static bool
 var_is_invariant(nir_variable *var, struct set * invariants)
 {
-   return var->data.invariant || _mesa_set_search(invariants, var);
+   return var && (var->data.invariant || _mesa_set_search(invariants, var));
 }
 
 static void
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 4/4] nir: link time opt duplicate varyings

[Jason Ekstrand]

On Mon, Dec 10, 2018 at 10:28 PM Timothy Arceri 
wrote:

> If we are outputting the same value to more than one output
> component rewrite the inputs to read from a single component.
>
> This will allow the duplicate varying components to be optimised
> away by the existing opts.
>
> shader-db results i965 (SKL):
>
> total instructions in shared programs: 12869230 -> 12860886 (-0.06%)
> instructions in affected programs: 322601 -> 314257 (-2.59%)
> helped: 3080
> HURT: 8
>
> total cycles in shared programs: 317792574 -> 317730593 (-0.02%)
> cycles in affected programs: 2584925 -> 2522944 (-2.40%)
> helped: 2975
> HURT: 477
>
> shader-db results radeonsi (VEGA):
>
> Totals from affected shaders:
> SGPRS: 30960 -> 31056 (0.31 %)
> VGPRS: 17052 -> 16672 (-2.23 %)
> Spilled SGPRs: 184 -> 167 (-9.24 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 562532 -> 549404 (-2.33 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 6011 -> 6110 (1.65 %)
> Wait states: 0 -> 0 (0.00 %)
>
> vkpipeline-db results RADV (VEGA):
>
> Totals from affected shaders:
> SGPRS: 14880 -> 15080 (1.34 %)
> VGPRS: 10872 -> 10888 (0.15 %)
> Spilled SGPRs: 0 -> 0 (0.00 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 674016 -> 668396 (-0.83 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 2708 -> 2704 (-0.15 %)
> Wait states: 0 -> 0 (0.00 %
> ---
>  src/compiler/nir/nir_linking_helpers.c | 95 ++
>  1 file changed, 95 insertions(+)
>
> diff --git a/src/compiler/nir/nir_linking_helpers.c
> b/src/compiler/nir/nir_linking_helpers.c
> index 37644d339f..bdfa7b8c4d 100644
> --- a/src/compiler/nir/nir_linking_helpers.c
> +++ b/src/compiler/nir/nir_linking_helpers.c
> @@ -700,6 +700,27 @@ nir_link_xfb_varyings(nir_shader *producer,
> nir_shader *consumer)
> }
>  }
>
> +static nir_variable *
> +get_matching_input_var(nir_shader *consumer, nir_variable *out_var)
> +{
> +   nir_variable *input_var = NULL;
> +   nir_foreach_variable(var, >inputs) {
> +  if (var->data.location >= VARYING_SLOT_VAR0 &&
> +  var->data.location - VARYING_SLOT_VAR0 < MAX_VARYING) {
>

Why is this not redundant with the checks below?  If it's not redundant,
I'd add a comment and make this one a continue because it's obviously
skipping over something.  Looking at patch 3 and the current code, I'm very
sure this isn't actually needed.  Maybe just assert that the above is true
of out_var->data.location and just let the check below handle it for var?


> +
> + if (var->data.location == out_var->data.location &&
> + var->data.location_frac == out_var->data.location_frac &&
> + var->data.interpolation == out_var->data.interpolation &&
> + get_interp_loc(var) == get_interp_loc(out_var)) {
> +input_var = var;
>

return var; ?


> +break;
> + }
> +  }
> +   }
> +
> +   return input_var;
> +}
> +
>  static bool
>  can_replace_varying(nir_variable *out_var, nir_intrinsic_instr
> *store_intr)
>  {
> @@ -782,6 +803,57 @@ try_replace_constant_input(nir_shader *shader,
> return progress;
>  }
>
> +static bool
> +try_replace_duplicate_input(nir_shader *shader, nir_variable *input_var,
> +nir_intrinsic_instr *dup_store_intr)
> +{
> +   assert(input_var);
> +
> +   nir_variable *dup_out_var =
> +
> nir_deref_instr_get_variable(nir_src_as_deref(dup_store_intr->src[0]));
> +
> +   if (!can_replace_varying(dup_out_var, dup_store_intr))
> +  return false;
>

This isn't much of a "try" function if it's just got one single check at
the top.


> +
> +   nir_function_impl *impl = nir_shader_get_entrypoint(shader);
> +
> +   nir_builder b;
> +   nir_builder_init(, impl);
> +
> +   bool progress = false;
> +   nir_foreach_block(block, impl) {
> +  nir_foreach_instr(instr, block) {
> + if (instr->type != nir_instr_type_intrinsic)
> +continue;
> +
> + nir_intrinsic_instr *intr = nir_instr_as_intrinsic(instr);
> + if (intr->intrinsic != nir_intrinsic_load_deref)
> +continue;
> +
> + nir_variable *in_var =
> +nir_deref_instr_get_variable(nir_src_as_deref(intr->src[0]));
>

Please do something like this instead:

nir_deref_instr *in_deref = nir_src_as_deref(instr->src[0]);
if (in_deref->mode != nir_var_shader_in)
   continue;

nir_variable *in_var = nir_deref_instr_get_variable(in_deref);

By checking the mode on the deref instead of the variable, the pass will
work even in the presence of derefs which you can't chase back to the
variable as long as they aren't on an input.  For some of my UBO/SSBO deref
stuff, I've got patches that make exactly this change for about four other
linking passes.


> +
> + if (in_var->data.mode != nir_var_shader_in)
> +continue;
> +
> + if 

Re: [Mesa-dev] [PATCH 01/38] ac: add various helpers for float16/int16/int8

[Marek Olšák]

On Fri, Dec 7, 2018 at 12:22 PM Rhys Perry  wrote:

> Signed-off-by: Rhys Perry 
> ---
>  src/amd/common/ac_llvm_build.c  | 123 ++--
>  src/amd/common/ac_llvm_build.h  |  22 +-
>  src/amd/common/ac_nir_to_llvm.c |  30 
>  3 files changed, 154 insertions(+), 21 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c
> b/src/amd/common/ac_llvm_build.c
> index 154cc696a2..cc7c6da5a4 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -87,12 +87,16 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
> ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
> ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
>
> +   ctx->i8_0 = LLVMConstInt(ctx->i8, 0, false);
> +   ctx->i8_1 = LLVMConstInt(ctx->i8, 1, false);
> ctx->i16_0 = LLVMConstInt(ctx->i16, 0, false);
> ctx->i16_1 = LLVMConstInt(ctx->i16, 1, false);
> ctx->i32_0 = LLVMConstInt(ctx->i32, 0, false);
> ctx->i32_1 = LLVMConstInt(ctx->i32, 1, false);
> ctx->i64_0 = LLVMConstInt(ctx->i64, 0, false);
> ctx->i64_1 = LLVMConstInt(ctx->i64, 1, false);
> +   ctx->f16_0 = LLVMConstReal(ctx->f16, 0.0);
> +   ctx->f16_1 = LLVMConstReal(ctx->f16, 1.0);
> ctx->f32_0 = LLVMConstReal(ctx->f32, 0.0);
> ctx->f32_1 = LLVMConstReal(ctx->f32, 1.0);
> ctx->f64_0 = LLVMConstReal(ctx->f64, 0.0);
> @@ -201,7 +205,9 @@ ac_get_type_size(LLVMTypeRef type)
>
>  static LLVMTypeRef to_integer_type_scalar(struct ac_llvm_context *ctx,
> LLVMTypeRef t)
>  {
> -   if (t == ctx->f16 || t == ctx->i16)
> +   if (t == ctx->i8)
> +   return ctx->i8;
> +   else if (t == ctx->f16 || t == ctx->i16)
> return ctx->i16;
> else if (t == ctx->f32 || t == ctx->i32)
> return ctx->i32;
> @@ -268,6 +274,110 @@ ac_to_float(struct ac_llvm_context *ctx,
> LLVMValueRef v)
> return LLVMBuildBitCast(ctx->builder, v, ac_to_float_type(ctx,
> type), "");
>  }
>
> +LLVMValueRef ac_get_zerof(struct ac_llvm_context *ctx, LLVMTypeRef t)
> +{
> +   if (t == ctx->f16)
> +   return ctx->f16_0;
> +   else if (t == ctx->f32)
> +   return ctx->f32_0;
> +   else if (t == ctx->f64)
> +   return ctx->f64_0;
> +   else
> +   unreachable("Unhandled float size");
> +}
> +
> +LLVMValueRef ac_get_onef(struct ac_llvm_context *ctx, LLVMTypeRef t)
> +{
> +   if (t == ctx->f16)
> +   return ctx->f16_1;
> +   else if (t == ctx->f32)
> +   return ctx->f32_1;
> +   else if (t == ctx->f64)
> +   return ctx->f64_1;
> +   else
> +   unreachable("Unhandled float size");
> +}
> +
> +LLVMValueRef ac_get_zero(struct ac_llvm_context *ctx, LLVMTypeRef t)
> +{
> +   if (t == ctx->i8)
> +   return ctx->i8_0;
> +   else if (t == ctx->i16)
> +   return ctx->i16_0;
> +   else if (t == ctx->i32)
> +   return ctx->i32_0;
> +   else if (t == ctx->i64)
> +   return ctx->i64_0;
> +   else
> +   unreachable("Unhandled bit size");
> +}
> +
> +LLVMValueRef ac_get_one(struct ac_llvm_context *ctx, LLVMTypeRef t)
> +{
> +   if (t == ctx->i8)
> +   return ctx->i8_1;
> +   else if (t == ctx->i16)
> +   return ctx->i16_1;
> +   else if (t == ctx->i32)
> +   return ctx->i32_1;
> +   else if (t == ctx->i64)
> +   return ctx->i64_1;
> +   else
> +   unreachable("Unhandled bit size");
> +}
>

You don't need these helpers. You can just use LLVMConstInt and
LLVMConstReal.


> +
> +LLVMTypeRef ac_float_of_size(struct ac_llvm_context *ctx, unsigned
> bit_size)
> +{
> +   switch (bit_size) {
> +   case 16:
> +   return ctx->f16;
> +   case 32:
> +   return ctx->f32;
> +   case 64:
> +   return ctx->f64;
> +   default:
> +   unreachable("Unhandled bit size");
> +   }
> +}
> +
> +LLVMTypeRef ac_int_of_size(struct ac_llvm_context *ctx, unsigned bit_size)
> +{
> +   switch (bit_size) {
> +   case 8:
> +   return ctx->i8;
> +   case 16:
> +   return ctx->i16;
> +   case 32:
> +   return ctx->i32;
> +   case 64:
> +   return ctx->i64;
> +   default:
> +   unreachable("Unhandled bit size");
> +   }
> +}
>

This is the same as LLVMIntTypeInContext.

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

[Mesa-dev] [Bug 109082] meson lmsensors check fails but always returns true

[bugzilla-daemon]

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

Bug ID: 109082
   Summary: meson lmsensors check fails but always returns true
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: v...@freedesktop.org
QA Contact: mesa-dev@lists.freedesktop.org
CC: baker.dyla...@gmail.com

meson -Dlmsensors=true

This is returned even though libsensors is not found.
Library libsensors found: YES

meson-log.txt
[...]
Working directory:  /tmp/tmp6w0ai2pa
Command line:  cc /tmp/tmp6w0ai2pa/testfile.c -pipe -D_FILE_OFFSET_BITS=64 -o
/tmp/tmp6w0ai2pa/output.exe -O0 -Wl,--start-group -llibsensors -Wl,--end-gr
oup -Wl,--allow-shlib-undefined 

Code:
 int main(int argc, char **argv) { return 0; }
Compiler stdout:

Compiler stderr:
 /usr/bin/ld: cannot find -llibsensors
collect2: error: ld returned 1 exit status

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

[Mesa-dev] [PATCH] meson: Fix typo.

[Vinson Lee]

Fixes: 6b4c7047d571 ("meson: build gallium nine state_tracker")
Signed-off-by: Vinson Lee 
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index fe647f682c1c..d0f4b7e51f44 100644
--- a/meson.build
+++ b/meson.build
@@ -619,7 +619,7 @@ if with_gallium_st_nine
 error('The nine state tracker requires gallium softpipe/llvmpipe.')
   elif not (with_gallium_radeonsi or with_gallium_nouveau or with_gallium_r600
 or with_gallium_r300 or with_gallium_svga or with_gallium_i915)
-error('The nine state tracker requires at least on non-swrast gallium 
driver.')
+error('The nine state tracker requires at least one non-swrast gallium 
driver.')
   endif
   if not with_dri3
 error('Using nine with wine requires dri3')
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 12/28] util: add fp64 -> fp32 conversion support for RTNE and RTZ rounding modes

[Matt Turner]

On Mon, Dec 10, 2018 at 11:25 AM Samuel Iglesias Gonsálvez
 wrote:
>
> On 07/12/2018 03:03, Matt Turner wrote:
> > On Wed, Dec 5, 2018 at 7:56 AM Samuel Iglesias Gonsálvez
> >  wrote:
> >>
> >> Signed-off-by: Samuel Iglesias Gonsálvez 
> >> ---
> >>  src/util/Makefile.sources |   2 +
> >>  src/util/double.c | 197 ++
> >>  src/util/double.h |  46 +
> >>  src/util/meson.build  |   2 +
> >>  4 files changed, 247 insertions(+)
> >>  create mode 100644 src/util/double.c
> >>  create mode 100644 src/util/double.h
> >
> > Why do we need software routines for this? Couldn't we set/reset the
> > rounding mode (fegetround/fegetround) around a double -> float
> > conversion?
> >
>
> Yes, that was my first idea. However, I found an issue with GCC that
> forces me to do these software routines instead.
>
> I implemented _mesa_double_to_float_rtz() as:
>
> float
> _mesa_double_to_float_rtz(double val)
> {
>int curr_method = fegetround();
>float result;
>fesetround(FE_TOWARDZERO);
>result = val;
>fesetround(curr_method);
>return result;
> }
>
> If I add a printf, I got the proper value. However if I remove it, the
> result value is using the default's rounding mode (FE_TONEAREST). I
> think it is reordering instructions or optimizing something. I have set
> #pragma STDC FENV_ACCESS ON but it doesn't work either.
>
> Updated news: I give it another spin. I defined result as volatile
> variable and that seems to work :) My GCC knowledge is limited, so if
> someone brings a better idea to fix this, I will be delighted to test
> it. If not, I will send a v2 version with the volatile and
> fesetround()/fegetround() functions.

Dang, I had no idea it wasn't really possible to safely set the
rounding mode for conversions like this. I see lots of articles saying
"#pragma STDC FENV_ACCESS ON" isn't supported. I think your original
code might be the best thing to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

[bugzilla-daemon]

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

--- Comment #12 from MGG  ---
Hey, the new beta version has dramatically reduced the memory usage! Nice work
there!

Please, don't forget to give us the extra info about the problem/bug you found
in order to close this ticket (in case there it isn't a problem on Mesa side).

Regards.

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

[Mesa-dev] [PATCH 2/3] ac/nir_to_llvm: add ac_are_tessfactors_def_in_all_invocs()

[Timothy Arceri]

The following patch will use this with the radeonsi NIR backend
but I've added it to ac so we can use it with RADV in future.

This is a NIR implementation of the tgsi function
tgsi_scan_tess_ctrl().
---
 src/amd/common/ac_nir_to_llvm.c | 161 
 src/amd/common/ac_nir_to_llvm.h |   2 +
 2 files changed, 163 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 4294956de1..055940b75f 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -4063,3 +4063,164 @@ ac_lower_indirect_derefs(struct nir_shader *nir, enum 
chip_class chip_class)
 
nir_lower_indirect_derefs(nir, indirect_mask);
 }
+
+static unsigned
+get_inst_tessfactor_writemask(nir_intrinsic_instr *intrin)
+{
+   if (intrin->intrinsic != nir_intrinsic_store_deref)
+   return 0;
+
+   nir_variable *var =
+   nir_deref_instr_get_variable(nir_src_as_deref(intrin->src[0]));
+
+   if (var->data.mode != nir_var_shader_out)
+   return 0;
+
+   unsigned writemask = 0;
+   const int location = var->data.location;
+   unsigned first_component = var->data.location_frac;
+   unsigned num_comps = intrin->dest.ssa.num_components;
+
+   if (location == VARYING_SLOT_TESS_LEVEL_INNER)
+   writemask = ((1 << num_comps + 1) - 1) << first_component;
+   else if (location == VARYING_SLOT_TESS_LEVEL_OUTER)
+   writemask = (((1 << num_comps + 1) - 1) << first_component) << 
4;
+
+   return writemask;
+}
+
+static void
+scan_tess_ctrl(nir_cf_node *cf_node, unsigned *upper_block_tf_writemask,
+  unsigned *cond_block_tf_writemask,
+  bool *tessfactors_are_def_in_all_invocs, bool is_nested_cf)
+{
+   switch (cf_node->type) {
+   case nir_cf_node_block: {
+   nir_block *block = nir_cf_node_as_block(cf_node);
+   nir_foreach_instr(instr, block) {
+   if (instr->type != nir_instr_type_intrinsic)
+   continue;
+
+   nir_intrinsic_instr *intrin = 
nir_instr_as_intrinsic(instr);
+   if (intrin->intrinsic == nir_intrinsic_barrier) {
+
+   /* If we find a barrier in nested control flow 
put this in the
+* too hard basket. In GLSL this is not 
possible but it is in
+* SPIR-V.
+*/
+   if (is_nested_cf) {
+   *tessfactors_are_def_in_all_invocs = 
false;
+   return;
+   }
+
+   /* The following case must be prevented:
+*gl_TessLevelInner = ...;
+*barrier();
+*if (gl_InvocationID == 1)
+*   gl_TessLevelInner = ...;
+*
+* If you consider disjoint code segments 
separated by barriers, each
+* such segment that writes tess factor 
channels should write the same
+* channels in all codepaths within that 
segment.
+*/
+   if (upper_block_tf_writemask || 
cond_block_tf_writemask) {
+   /* Accumulate the result: */
+   *tessfactors_are_def_in_all_invocs &=
+   !(*cond_block_tf_writemask & 
~(*upper_block_tf_writemask));
+
+   /* Analyze the next code segment from 
scratch. */
+   *upper_block_tf_writemask = 0;
+   *cond_block_tf_writemask = 0;
+   }
+   } else
+   *upper_block_tf_writemask |= 
get_inst_tessfactor_writemask(intrin);
+   }
+
+   break;
+   }
+   case nir_cf_node_if: {
+   unsigned then_tessfactor_writemask = 0;
+   unsigned else_tessfactor_writemask = 0;
+
+   nir_if *if_stmt = nir_cf_node_as_if(cf_node);
+   foreach_list_typed(nir_cf_node, nested_node, node, 
_stmt->then_list) {
+   scan_tess_ctrl(nested_node, _tessfactor_writemask,
+  cond_block_tf_writemask,
+  tessfactors_are_def_in_all_invocs, true);
+   }
+
+   foreach_list_typed(nir_cf_node, nested_node, node, 
_stmt->else_list) {
+   scan_tess_ctrl(nested_node, _tessfactor_writemask,
+  cond_block_tf_writemask,
+   

[Mesa-dev] [PATCH 3/3] radeonsi: make use of ac_are_tessfactors_def_in_all_invocs()

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader_nir.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index b81bea00b8..931d41245d 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -285,14 +285,8 @@ void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
if (nir->info.stage != MESA_SHADER_TESS_CTRL)
return;
 
-   /* Initial value = true. Here the pass will accumulate results from
-* multiple segments surrounded by barriers. If tess factors aren't
-* written at all, it's a shader bug and we don't care if this will be
-* true.
-*/
-   out->tessfactors_are_def_in_all_invocs = true;
-
-   /* TODO: Implement scanning of tess factors, see tgsi backend. */
+   out->tessfactors_are_def_in_all_invocs =
+   ac_are_tessfactors_def_in_all_invocs(nir);
 }
 
 void si_nir_scan_shader(const struct nir_shader *nir,
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/3] radeonsi: remove unrequired param in si_nir_scan_tess_ctrl()

[Timothy Arceri]

---
 src/gallium/drivers/radeonsi/si_shader.h| 1 -
 src/gallium/drivers/radeonsi/si_shader_nir.c| 1 -
 src/gallium/drivers/radeonsi/si_state_shaders.c | 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/si_shader.h 
b/src/gallium/drivers/radeonsi/si_shader.h
index f71e601574..cdb57958dd 100644
--- a/src/gallium/drivers/radeonsi/si_shader.h
+++ b/src/gallium/drivers/radeonsi/si_shader.h
@@ -708,7 +708,6 @@ const char *si_get_shader_name(const struct si_shader 
*shader, unsigned processo
 void si_nir_scan_shader(const struct nir_shader *nir,
struct tgsi_shader_info *info);
 void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
-  const struct tgsi_shader_info *info,
   struct tgsi_tessctrl_info *out);
 void si_lower_nir(struct si_shader_selector *sel);
 
diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
b/src/gallium/drivers/radeonsi/si_shader_nir.c
index 660b5bc356..b81bea00b8 100644
--- a/src/gallium/drivers/radeonsi/si_shader_nir.c
+++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
@@ -278,7 +278,6 @@ static void scan_instruction(struct tgsi_shader_info *info,
 }
 
 void si_nir_scan_tess_ctrl(const struct nir_shader *nir,
-  const struct tgsi_shader_info *info,
   struct tgsi_tessctrl_info *out)
 {
memset(out, 0, sizeof(*out));
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c 
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index de00df60ae..2d5d163247 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -2238,7 +2238,7 @@ static void *si_create_shader_selector(struct 
pipe_context *ctx,
sel->nir = state->ir.nir;
 
si_nir_scan_shader(sel->nir, >info);
-   si_nir_scan_tess_ctrl(sel->nir, >info, >tcs_info);
+   si_nir_scan_tess_ctrl(sel->nir, >tcs_info);
 
si_lower_nir(sel);
}
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 10/12] virgl: modify how we handle GL_MAP_FLUSH_EXPLICIT_BIT

[Gurchetan Singh]

On Tue, Dec 11, 2018 at 2:49 PM Elie Tournier 
wrote:

> On Mon, Dec 10, 2018 at 10:20:36AM -0800, Gurchetan Singh wrote:
> > Previously, we ignored the the glUnmap(..) operation and
> > flushed before we flush the cbuf.  Now, let's just flush
> > the data when we unmap.
> >
> > Neither method is optimal, for example:
> >
> > glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
> > glFlushMappedBufferRange(.., 25, 30)
> > glFlushMappedBufferRange(.., 65, 70)
> >
> > We'll end up flushing 25 --> 70.  Maybe we can fix this later.
> >
> > v2: Add fixme comment in the code (Elie)
> Thanks.
> I still have to run some regressions tests. They are a bit slow on my
> system.
> So for now, the series is:
> Acked-by: Elie Tournier 
>

Thanks!  When your tests are complete, I posted a slightly updated series
on Gitlab:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/25


> > ---
> >  src/gallium/drivers/virgl/virgl_buffer.c   | 46 +++---
> >  src/gallium/drivers/virgl/virgl_context.c  | 34 +---
> >  src/gallium/drivers/virgl/virgl_context.h  |  1 -
> >  src/gallium/drivers/virgl/virgl_resource.h | 13 --
> >  4 files changed, 25 insertions(+), 69 deletions(-)
> >
> > diff --git a/src/gallium/drivers/virgl/virgl_buffer.c
> b/src/gallium/drivers/virgl/virgl_buffer.c
> > index d5d728735e..a20deab549 100644
> > --- a/src/gallium/drivers/virgl/virgl_buffer.c
> > +++ b/src/gallium/drivers/virgl/virgl_buffer.c
> > @@ -33,7 +33,6 @@ static void virgl_buffer_destroy(struct pipe_screen
> *screen,
> > struct virgl_screen *vs = virgl_screen(screen);
> > struct virgl_buffer *vbuf = virgl_buffer(buf);
> >
> > -   util_range_destroy(>valid_buffer_range);
> > vs->vws->resource_unref(vs->vws, vbuf->base.hw_res);
> > FREE(vbuf);
> >  }
> > @@ -53,7 +52,7 @@ static void *virgl_buffer_transfer_map(struct
> pipe_context *ctx,
> > bool readback;
> > bool doflushwait = false;
> >
> > -   if ((usage & PIPE_TRANSFER_READ) && (vbuf->on_list == TRUE))
> > +   if (usage & PIPE_TRANSFER_READ)
> >doflushwait = true;
> > else
> >doflushwait = virgl_res_needs_flush_wait(vctx, >base,
> usage);
> > @@ -92,13 +91,19 @@ static void virgl_buffer_transfer_unmap(struct
> pipe_context *ctx,
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> >
> > if (trans->base.usage & PIPE_TRANSFER_WRITE) {
> > -  if (!(transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT)) {
> > - struct virgl_screen *vs = virgl_screen(ctx->screen);
> > - vctx->num_transfers++;
> > - vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > -   >box, trans->base.stride,
> trans->base.layer_stride, trans->offset, transfer->level);
> > -
> > +  struct virgl_screen *vs = virgl_screen(ctx->screen);
> > +  if (transfer->usage & PIPE_TRANSFER_FLUSH_EXPLICIT) {
> > + transfer->box.x += trans->range.start;
> > + transfer->box.width = trans->range.end - trans->range.start;
> > + trans->offset = transfer->box.x;
> >}
> > +
> > +  vctx->num_transfers++;
> > +  vs->vws->transfer_put(vs->vws, vbuf->base.hw_res,
> > +>box, trans->base.stride,
> > +trans->base.layer_stride, trans->offset,
> > +transfer->level);
> > +
> > }
> >
> > virgl_resource_destroy_transfer(vctx, trans);
> > @@ -108,20 +113,19 @@ static void
> virgl_buffer_transfer_flush_region(struct pipe_context *ctx,
> > struct pipe_transfer
> *transfer,
> > const struct pipe_box
> *box)
> >  {
> > -   struct virgl_context *vctx = virgl_context(ctx);
> > struct virgl_buffer *vbuf = virgl_buffer(transfer->resource);
> > +   struct virgl_transfer *trans = virgl_transfer(transfer);
> >
> > -   if (!vbuf->on_list) {
> > -   struct pipe_resource *res = NULL;
> > -
> > -   list_addtail(>flush_list, >to_flush_bufs);
> > -   vbuf->on_list = TRUE;
> > -   pipe_resource_reference(, >base.u.b);
> > -   }
> > -
> > -   util_range_add(>valid_buffer_range, transfer->box.x + box->x,
> > -  transfer->box.x + box->x + box->width);
> > -
> > +   /*
> > +* FIXME: This is not optimal.  For example,
> > +*
> > +* glMapBufferRange(.., 0, 100, GL_MAP_FLUSH_EXPLICIT_BIT)
> > +* glFlushMappedBufferRange(.., 25, 30)
> > +* glFlushMappedBufferRange(.., 65, 70)
> > +*
> > +* We'll end up flushing 25 --> 70.
> > +*/
> > +   util_range_add(>range, box->x, box->x + box->width);
> > vbuf->base.clean = FALSE;
> >  }
> >
> > @@ -145,7 +149,6 @@ struct pipe_resource *virgl_buffer_create(struct
> virgl_screen *vs,
> > buf->base.u.b.screen = >base;
> > buf->base.u.vtbl = _buffer_vtbl;
> > pipe_reference_init(>base.u.b.reference, 1);
> > -   util_range_init(>valid_buffer_range);
> > 

Re: [Mesa-dev] [PATCH mesa] drop autotools

[Andres Gomez]

On Mon, 2018-12-17 at 19:51 +0100, Bas Nieuwenhuizen wrote:
> On Mon, Dec 17, 2018 at 6:33 PM Juan A. Suarez Romero
>  wrote:
> > 
> > On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> > > Cc: Emil Velikov 
> > > Cc: Andres Gomez 
> > > Cc: Juan A. Suarez Romero 
> > > Cc: Dylan Baker 
> > > Signed-off-by: Eric Engestrom 
> > > ---
> > > This patch depends on the releasing procedure in docs/releasing.html to
> > > be updated to not rely on autotools anymore.
> > > 
> > > I think our release managers (cc'ed) should work together and figure out
> > > the procedure they want to go by; only once that's done can we delete
> > > these 200+ files and 14k+ lines :)
> > 
> > 
> > I'll let others to talk. But my preference would be to land this for next 
> > 19.0
> > branchpoint, just a couple of days before the branchpoint, so 19.0.x 
> > releases
> > get rid of autotools.
> > 
> > This way we have time to fix any remaining issue, and make like easier for 
> > those
> > in charge of 18.3.x releases, which I think should support autotools until 
> > the
> > end of its life.
> 
> Can I suggest the inverse, pushing this long before any branchpoint?
> 
> As with any migration, users only start using when you force them too,
> and that means a bunch of non-working usecases are going to be
> detected once this patch is pushed and some more people are forced to
> it. Sure, the last call discussion served to tease some of these out,
> but I expect even more will turn up if you submit this.
> 
> Doing this far before the branchpoint gives more time to fix them.

FWIW, I agree with Bas here. Better to push this long before any
branchpoint.

I don't foresee many (if any) backports would be needed during a stable
cycle because of problems in the removed autotools files and, if fixes
are needed for meson, they are welcome.

-- 
Br,

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

[Mesa-dev] Two MRs related to NIR copy_prop_vars

[Caio Marcelo de Oliveira Filho]

Hi,

nir: properly find the entry to keep in copy_prop_vars
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/23

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


nir: properly clear the entry sources in copy_prop_vars
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/24

  Ensure that we will never use invalid data in the copy entries.
  Found while debugging the issue above.


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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Tobias Klausmann]

On 17.12.18 23:16, Dylan Baker wrote:

Quoting Tobias Klausmann (2018-12-17 14:05:13)

On 17.12.18 20:33, Dylan Baker wrote:

Quoting Emil Velikov (2018-12-17 11:10:00)

On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:

Quoting Emil Velikov (2018-12-13 08:15:57)

From: Emil Velikov 

Reasonably often people will want to build the loader w/o any drivers.
Be that debugging an issue in the former, distribution bundle or other.

Currently there is an artificial restriction preventing people to build
a config like the following:

   meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=

Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
This is a WIP, since it's obviously incomplete/wrong. Input or fix
would be appreciated.

Thanks
Emil
---
   meson.build | 12 +---
   1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/meson.build b/meson.build
index 2aa2794f971..e1d6561c1a3 100644
--- a/meson.build
+++ b/meson.build
@@ -285,14 +285,6 @@ if with_glx == 'dri'
  endif
   endif

-if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
'gallium-xlib')
-  with_gles1 = false
-  with_gles2 = false
-  with_opengl = false
-  with_any_opengl = false
-  with_shared_glapi = false
-endif
-
   _gbm = get_option('gbm')
   if _gbm == 'auto'
 with_gbm = system_has_kms_drm and with_dri
@@ -352,9 +344,7 @@ if with_glx != 'disabled'
 error('xlib conflicts with any dri driver')
   endif
 elif with_glx == 'dri'
-if not with_dri
-  error('dri based GLX requires at least one DRI driver')
-elif not with_shared_glapi
+if not with_shared_glapi
 error('dri based GLX requires shared-glapi')
   endif
 endif
--
2.19.2


I'll have to think about this some more, I'm still not exactly sure why you'd
want to build the loader without a driver (although I could see why you might
want the driver without the loader).


Building both separate breaks away the dependency for llvm/clang while
building the loader package (mesa), thus eliminating the bottleneck, the
long build time of llvm/clang, in a complete build cycle of a whole
distribution rebuild for the packages "waiting" on mesa to complete. The
mesa-drivers package can wait for llvm/clang in the meantime. Right now
i have solved this by building the classic swrast with mesa and
instantly throwing it away after the build is finished.

Btw: Building the drivers without a windowing system would be nice as
well, this applies to the above use case where the -drivers package does
not need a windowing system, as it is contained in the other package.

Greetings

Tobias

This sounds like asking mesa to carry a lot of complexity so that distros can
build mesa as three separate packages. I'm really not thrilled about adding
such a feature unless someone wants to step up and be the maintainer of that
build mode and ensure it works. All of this complexity is technical debt that
the project is assuming, it makes the build definitions harder to read and
modify, and unless there's someone who actually uses such a mode (ie, not a core
developer, since no one has asked for this), it's just going to get broken. We
already have the most complicated build system I have ever seen (excluding Linux
and the core OS of FreeBSD) with more knobs and switches for micro tuning, let
alone all of the different combinations of drivers, platforms, window systems,
and APIs.


Actually splitting it even further is maybe a bit too much, yes, yet the 
usecase of splitting into two worked with autotools, may it be by design 
decision of by chance! I was just noting the second messy bit in such a 
usecase (with beeing a bit off topic: sorry for that!), as on of the 
messy bits are going to be fixed by Emils patch (or a following version)!



So, thumbs up from me building the loaders without drivers!

Greetings

Tobias





Dylan

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

[Mesa-dev] [PATCH] docs: update 18.3 and add 19.x cycles for the release calendar

[Andres Gomez]

Cc: Dylan Baker 
Cc: Juan A. Suarez 
Cc: Emil Velikov 
Signed-off-by: Andres Gomez 
---
 docs/release-calendar.html | 118 -
 1 file changed, 116 insertions(+), 2 deletions(-)

diff --git a/docs/release-calendar.html b/docs/release-calendar.html
index 924995c2698..0fbaa22d106 100644
--- a/docs/release-calendar.html
+++ b/docs/release-calendar.html
@@ -45,11 +45,12 @@ if you'd like to nominate a patch in the next stable 
release.
 Juan A. Suarez
 Last planned 18.2.x release
 
-18.3
+
+18.3
 2018-12-19
 18.3.2
 Emil Velikov
-
+
 
 
 2019-01-09
@@ -67,6 +68,119 @@ if you'd like to nominate a patch in the next stable 
release.
 2019-02-06
 18.3.5
 Emil Velikov
+
+
+
+2019-02-20
+18.3.6
+Emil Velikov
+
+
+
+2019-03-06
+18.3.7
+Emil Velikov
+Last planned 18.3.x release
+
+
+19.0
+2019-01-29
+19.0.0-rc1
+Dylan Baker
+
+
+
+2019-02-05
+19.0.0-rc2
+Dylan Baker
+
+
+
+2019-02-12
+19.0.0-rc3
+Dylan Baker
+
+
+
+2019-02-19
+19.0.0-rc4
+Dylan Baker
+Last planned RC/Final release
+
+
+19.1
+2019-04-30
+19.1.0-rc1
+Andres Gomez
+
+
+
+2019-05-07
+19.1.0-rc2
+Andres Gomez
+
+
+
+2019-05-14
+19.1.0-rc3
+Andres Gomez
+
+
+
+2019-05-21
+19.1.0-rc4
+Andres Gomez
+Last planned RC/Final release
+
+
+19.2
+2019-08-06
+19.2.0-rc1
+Emil Velikov
+
+
+
+2019-08-13
+19.2.0-rc2
+Emil Velikov
+
+
+
+2019-08-20
+19.2.0-rc3
+Emil Velikov
+
+
+
+2019-08-27
+19.2.0-rc4
+Emil Velikov
+Last planned RC/Final release
+
+
+19.3
+2019-10-15
+19.3.0-rc1
+Juan A. Suarez
+
+
+
+2019-10-22
+19.3.0-rc2
+Juan A. Suarez
+
+
+
+2019-10-29
+19.3.0-rc3
+Juan A. Suarez
+
+
+
+2019-11-05
+19.3.0-rc4
+Juan A. Suarez
+Last planned RC/Final release
 
 
 
-- 
2.18.0

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

[Mesa-dev] [PATCH] radv: Work around non-renderable 128bpp compressed 3d textures on GFX9.

[Bas Nieuwenhuizen]

Exactly what title says, the new addrlib does not allow the above with
certain dimensions that the CTS seems to hit. Work around it by not
allowing the app to render to it via compat with  other 128bpp formats
and do not render to it ourselves during copies.

Fixes: 776b9113656 "amd/addrlib: update Mesa's copy of addrlib"
---
 src/amd/common/ac_surface.c | 12 
 src/amd/common/ac_surface.h |  1 +
 src/amd/vulkan/radv_formats.c   | 12 
 src/amd/vulkan/radv_image.c |  6 ++
 src/amd/vulkan/radv_meta_copy.c | 24 ++--
 5 files changed, 45 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index d8d927ee1c5..80f5d642771 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -709,7 +709,9 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
else
AddrSurfInfoIn.tileType = ADDR_NON_DISPLAYABLE;
 
-   AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   AddrSurfInfoIn.flags.color = is_color_surface &&
+!(surf->flags & 
RADEON_SURF_NO_RENDER_TARGET);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
AddrSurfInfoIn.flags.cube = config->is_cube;
AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
@@ -923,7 +925,7 @@ static int gfx6_compute_surface(ADDR_HANDLE addrlib,
}
 
/* Compute FMASK. */
-   if (config->info.samples >= 2 && AddrSurfInfoIn.flags.color) {
+   if (config->info.samples >= 2 && is_color_surface) {
ADDR_COMPUTE_FMASK_INFO_INPUT fin = {0};
ADDR_COMPUTE_FMASK_INFO_OUTPUT fout = {0};
ADDR_TILEINFO fmask_tile_info = {};
@@ -1412,11 +1414,13 @@ static int gfx9_compute_surface(ADDR_HANDLE addrlib,
AddrSurfInfoIn.bpp = surf->bpe * 8;
}
 
-   AddrSurfInfoIn.flags.color = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   bool is_color_surface = !(surf->flags & RADEON_SURF_Z_OR_SBUFFER);
+   AddrSurfInfoIn.flags.color = is_color_surface &&
+!(surf->flags & 
RADEON_SURF_NO_RENDER_TARGET);
AddrSurfInfoIn.flags.depth = (surf->flags & RADEON_SURF_ZBUFFER) != 0;
AddrSurfInfoIn.flags.display = get_display_flag(config, surf);
/* flags.texture currently refers to TC-compatible HTILE */
-   AddrSurfInfoIn.flags.texture = AddrSurfInfoIn.flags.color ||
+   AddrSurfInfoIn.flags.texture = is_color_surface ||
   surf->flags & 
RADEON_SURF_TC_COMPATIBLE_HTILE;
AddrSurfInfoIn.flags.opt4space = 1;
 
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 8ba964e64ec..7ae166c70a3 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -68,6 +68,7 @@ enum radeon_micro_mode {
 #define RADEON_SURF_IMPORTED(1 << 24)
 #define RADEON_SURF_OPTIMIZE_FOR_SPACE  (1 << 25)
 #define RADEON_SURF_SHAREABLE   (1 << 26)
+#define RADEON_SURF_NO_RENDER_TARGET(1 << 27)
 
 struct legacy_surf_level {
 uint64_toffset;
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 59bc46d2fc8..48727817d32 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -1112,6 +1112,18 @@ static VkResult radv_get_image_format_properties(struct 
radv_physical_device *ph
maxMipLevels = 1;
}
 
+
+   /* We can't create 3d compressed 128bpp images that can be rendered to 
on GFX9 */
+   if (physical_device->rad_info.chip_class >= GFX9 &&
+   info->type == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(info->format) == 128 &&
+   vk_format_is_compressed(info->format) &&
+   (info->flags & VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT) &&
+   ((info->flags &  VK_IMAGE_CREATE_EXTENDED_USAGE_BIT) ||
+(info->usage & VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT))) {
+   goto unsupported;
+   }
+
if (info->usage & VK_IMAGE_USAGE_SAMPLED_BIT) {
if (!(format_feature_flags & 
VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT)) {
goto unsupported;
diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 2bd74e202fe..69bbcdcf645 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -249,6 +249,12 @@ radv_init_surface(struct radv_device *device,
if (is_stencil)
surface->flags |= RADEON_SURF_SBUFFER;
 
+   if (device->physical_device->rad_info.chip_class >= GFX9 &&
+   pCreateInfo->imageType == VK_IMAGE_TYPE_3D &&
+   vk_format_get_blocksizebits(pCreateInfo->format) == 128 &&
+   vk_format_is_compressed(pCreateInfo->format))

Re: [Mesa-dev] MR: NIR: Partial redundancy elimination for compares

[Ian Romanick]

I was really hoping to avoid having review discussion for a patch series
on both the mailing list and the MR, but I guess that ship has sailed.

On 12/17/18 2:39 PM, Roland Scheidegger wrote:
> Am 17.12.18 um 23:27 schrieb Roland Scheidegger:
>> Am 17.12.18 um 23:07 schrieb Ilia Mirkin:
>>> On Mon, Dec 17, 2018 at 5:05 PM Ian Romanick  wrote:

 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F22data=02%7C01%7Csroland%40vmware.com%7C5773f37aa397417e6beb08d6646c24c6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636806812986635916sdata=z2ev4sVJEW8Kw2hsoNWfYHh6FkSwSy%2B5CdTItxoh%2FPE%3Dreserved=0

 This series adds a new optimization pass that tries to replace code
 sequences like

 if (x < y) {
 z = y - x;
 ...
 }

 with a sequence like

 t = x - y;
 if (t < 0) {
 z = -t;
 ...
 }
>>>
>>> Is it worth worrying about infinities? e.g. if x = -Infinity, y =
>>> Infinity, "x < y" will be true, but "x - y < 0" will not be (pretty
>>> sure it'll be a NaN, which is not < 0).
>>
>> I was wondering the same, but I think this should still work.
>> -Inf - Inf = -Inf, so no problem there.
> 
> Although it looks like the optimization might be a bit problematic? For
> it to work you really need not just be able to use flags generated by
> sub, but also you need to be able to eliminate the negation one way or
> another (e.g. free input negate going into another operation, turning
> subsequent adds into subs, ...). But well maybe that's often possible.

The optimization handles various combinations of 'x < y', 'x > y', 'x <=
y', and 'x >= y' combined with various combinations of 'x - y' and 'y -
x'.  Not all of the cases require a negation in the replacement.

Right now this is only enabled in the i965 driver, and negation is free
on that architecture.  If this is enabled on other architectures,
someone might want to add a flag that limits the kind of replacements to
avoid the negation... even that may be overly conservative.  In the
example case, it's possible that the only use of z is in an expression
like 'w - z'.

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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Marek Olšák (2018-12-17 12:25:29)
> On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:
> 
> Eero Tamminen  writes:
> 
> > Hi,
> >
> > On 17.12.2018 8.08, Marek Olšák wrote:
> > [...]
> >> I think one of the serious usability issues is that environment
> >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are 
> not
> >> saved by meson for future reconfigures.
> >
> > I don't know what Meson is supposed to do, but to me that would be
> > a bug in a build tool.
> >
> > Re-configure is supposed to adapt SW to the changes in the build
> > environment, and environment variables are part of that (along with
> > command line options and SW installed to to the system).  Build
> > configure tool deciding to "remember" some of those things instead
> > of checking the new situation, seems like a great opportunity for
> > confusion.
> 
> A user-triggered reconfigure, sure.  Recapture env vars then.  But "git
> pull; ninja -C build" losing track of the configuration state is broken.
> We don't have to specify all of your meson -Doption=state configuration
> on every build, why should you need to specify your PKG_CONFIG_PATH
> configure options on every build?
> 
> 
> Thanks, Eric.
> 
> Yes, meson behaves such that users have to set all environment variables for
> every "ninja" command that might reconfigure.
> 
> I see 2 solutions:
> 1) meson needs to remember the relevant env vars
> 2) meson should FAIL to configure if any of the env vars are set (if it wants
> to ignore them)
> 
> Marek

Meson does remember the *_FLAGS variables. Those are translated on configure
into meson's internal ${lang}_args and ${lang}_link args. It does look like
those aren't remembered when --wipe is called though, I filed a bug for that:
https://github.com/mesonbuild/meson/issues/4650

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] MR: NIR: Partial redundancy elimination for compares

[Roland Scheidegger]

Am 17.12.18 um 23:27 schrieb Roland Scheidegger:
> Am 17.12.18 um 23:07 schrieb Ilia Mirkin:
>> On Mon, Dec 17, 2018 at 5:05 PM Ian Romanick  wrote:
>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F22data=02%7C01%7Csroland%40vmware.com%7C5773f37aa397417e6beb08d6646c24c6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636806812986635916sdata=z2ev4sVJEW8Kw2hsoNWfYHh6FkSwSy%2B5CdTItxoh%2FPE%3Dreserved=0
>>>
>>> This series adds a new optimization pass that tries to replace code
>>> sequences like
>>>
>>> if (x < y) {
>>> z = y - x;
>>> ...
>>> }
>>>
>>> with a sequence like
>>>
>>> t = x - y;
>>> if (t < 0) {
>>> z = -t;
>>> ...
>>> }
>>
>> Is it worth worrying about infinities? e.g. if x = -Infinity, y =
>> Infinity, "x < y" will be true, but "x - y < 0" will not be (pretty
>> sure it'll be a NaN, which is not < 0).
> 
> I was wondering the same, but I think this should still work.
> -Inf - Inf = -Inf, so no problem there.
> 

Although it looks like the optimization might be a bit problematic? For
it to work you really need not just be able to use flags generated by
sub, but also you need to be able to eliminate the negation one way or
another (e.g. free input negate going into another operation, turning
subsequent adds into subs, ...). But well maybe that's often possible.

Roland


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

Re: [Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Andres Gomez]

On Mon, 2018-12-17 at 18:36 +, Emil Velikov wrote:
> On Mon, 17 Dec 2018 at 18:14, Andres Gomez  wrote:
> > 
> > On Mon, 2018-12-17 at 16:43 +, Emil Velikov wrote:
> > > Currently our is_sha_nomination does:
> > >  - folds any whitespace, attempting to extract sha-like information
> > >  - checks that at least one of the shas has landed
> > > 
> > > Split it in two and do sha-like validation first.
> > > 
> > > This way, commits with mesa-stable and sha nominations will feature the
> > > fixes/revert/etc instead of stable (a) or will be omitted if not
> > > applicable for the respective branch (b).
> > > 
> > > Misc examples from 18.3
> > > 
> > > (a)
> > > -[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > rendering
> > > +[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > > rendering
> > > 
> > > (b)
> > > -[   stable ] 9a7b3199037 anv/query: flush render target before copying 
> > > results
> > > 
> > > CC: Andres Gomez 
> > > CC: Juan A. Suarez 
> > > CC: Dylan Baker 
> > > CC: mesa-sta...@lists.freedesktop.org
> > > Signed-off-by: Emil Velikov 
> > > ---
> > > Juan I've noticed that you've been experiencing the above annoyance for
> > > a while. Having less false-positives should ease things up a bit :-)
> > > ---
> > >  bin/get-pick-list.sh | 46 +---
> > >  1 file changed, 30 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > > index 9f9cbc44026..08a783f35a8 100755
> > > --- a/bin/get-pick-list.sh
> > > +++ b/bin/get-pick-list.sh
> > > @@ -21,32 +21,36 @@ is_typod_nomination()
> > >   git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
> > >  }
> > > 
> > > +fixes=
> > > +
> > 
> > Splitting in 2 functions for which we need now a global variable is not
> > very nice. Anyway, let's not make this more complicated than needed.
> > 
> 
> Wasn't too happy about it either. As you said - I've decided to go
> with the simpler solution.
> 
> > >  # Helper to handle various mistypos of the fixes tag.
> > >  # The tag string itself is passed as argument and normalised within.
> > > +#
> > > +# Resulting string in the global variable "fixes" and contains entries
> > > +# in the form "fixes:$sha"
> > >  is_sha_nomination()
> > >  {
> > >   fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
> > >   sed -e 's/'"$2"'/\nfixes:/Ig' | \
> > >   grep -Eo 'fixes:[a-f0-9]{8,40}'`
> > > 
> > > - fixes_count=`echo "$fixes" | wc -l`
> > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > 
> > Why is the extra "grep" needed here?
> > 
> 
> Commits that include "fixes $some_test" will result in fixes="".
> Thus wc -l will return 1

Argh!

Well, this is more a consequence of wc counting newline characters and
echo adding a new one at the end, even when not printing anything.
Let's grep again, then ☹

> > >   if test $fixes_count -eq 0; then
> > > - return 0
> > > + return 1
> > 
> > Ugh! Right.
> > 
> > >   fi
> > > + return 0
> > > +}
> > > +
> > > +# Checks if at least one of offending commits, listed in the global
> > > +# "fixes", is in branch.
> > > +sha_in_range()
> > > +{
> > > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
> > 
> > Ditto.
> > 
> > >   while test $fixes_count -gt 0; do
> > >   # Treat only the current line
> > >   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut 
> > > -d : -f 2`
> > >   fixes_count=$(($fixes_count-1))
> > > 
> > > - # Bail out if we cannot find suitable id.
> > > - # Any specific validation the $id is valid and not some 
> > > junk, is
> > > - # implied with the follow up code
> > > - if test "x$id" = x; then
> > > - continue
> > > - fi
> > > -
> > > - #Check if the offending commit is in branch.
> > > -
> > 
> > Was this never needed in the first place? Feels right to remove it
> > since $fixes should have some content by now, but I wonder how this got
> > here in the first place.
> > 
> 
> Left-over from the old standalone script. Copied a bit too much :-(
> 
> > >   # Be that cherry-picked ...
> > >   # ... or landed before the branchpoint.
> > >   if grep -q ^$id already_picked ||
> > > @@ -103,20 +107,30 @@ do
> > >   continue
> > >   fi
> > > 
> > > - if is_stable_nomination "$sha"; then
> > > - tag=stable
> > > - elif is_typod_nomination "$sha"; then
> > > - tag=typod
> > > - elif is_fixes_nomination "$sha"; then
> > > + if is_fixes_nomination "$sha"; then
> > >   tag=fixes
> > >   elif is_brokenby_nomination "$sha"; then
> > >   tag=brokenby
> > >   elif is_revert_nomination "$sha"; then
> > >   tag=revert
> > > + elif is_stable_nomination "$sha"; then
> 

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Matt Turner]

On Mon, Dec 17, 2018 at 2:12 PM Emil Velikov  wrote:
> Additionally, distributions build latest loader and use it with DRI1
> era drivers.

I'm curious if there are distributions that still ships the DRI1
drivers. Do you know which, if any, do?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] MR: NIR: Partial redundancy elimination for compares

[Roland Scheidegger]

Am 17.12.18 um 23:07 schrieb Ilia Mirkin:
> On Mon, Dec 17, 2018 at 5:05 PM Ian Romanick  wrote:
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2Fmerge_requests%2F22data=02%7C01%7Csroland%40vmware.com%7C5773f37aa397417e6beb08d6646c24c6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636806812986635916sdata=z2ev4sVJEW8Kw2hsoNWfYHh6FkSwSy%2B5CdTItxoh%2FPE%3Dreserved=0
>>
>> This series adds a new optimization pass that tries to replace code
>> sequences like
>>
>> if (x < y) {
>> z = y - x;
>> ...
>> }
>>
>> with a sequence like
>>
>> t = x - y;
>> if (t < 0) {
>> z = -t;
>> ...
>> }
> 
> Is it worth worrying about infinities? e.g. if x = -Infinity, y =
> Infinity, "x < y" will be true, but "x - y < 0" will not be (pretty
> sure it'll be a NaN, which is not < 0).

I was wondering the same, but I think this should still work.
-Inf - Inf = -Inf, so no problem there.

Roland


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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Dylan Baker]

Quoting Tobias Klausmann (2018-12-17 14:05:13)
> 
> On 17.12.18 20:33, Dylan Baker wrote:
> > Quoting Emil Velikov (2018-12-17 11:10:00)
> >> On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:
> >>> Quoting Emil Velikov (2018-12-13 08:15:57)
>  From: Emil Velikov 
> 
>  Reasonably often people will want to build the loader w/o any drivers.
>  Be that debugging an issue in the former, distribution bundle or other.
> 
>  Currently there is an artificial restriction preventing people to build
>  a config like the following:
> 
>    meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= 
>  -Dgallium-drivers=
> 
>  Cc: Dylan Baker 
>  Signed-off-by: Emil Velikov 
>  ---
>  This is a WIP, since it's obviously incomplete/wrong. Input or fix
>  would be appreciated.
> 
>  Thanks
>  Emil
>  ---
>    meson.build | 12 +---
>    1 file changed, 1 insertion(+), 11 deletions(-)
> 
>  diff --git a/meson.build b/meson.build
>  index 2aa2794f971..e1d6561c1a3 100644
>  --- a/meson.build
>  +++ b/meson.build
>  @@ -285,14 +285,6 @@ if with_glx == 'dri'
>   endif
>    endif
> 
>  -if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
>  'gallium-xlib')
>  -  with_gles1 = false
>  -  with_gles2 = false
>  -  with_opengl = false
>  -  with_any_opengl = false
>  -  with_shared_glapi = false
>  -endif
>  -
>    _gbm = get_option('gbm')
>    if _gbm == 'auto'
>  with_gbm = system_has_kms_drm and with_dri
>  @@ -352,9 +344,7 @@ if with_glx != 'disabled'
>  error('xlib conflicts with any dri driver')
>    endif
>  elif with_glx == 'dri'
>  -if not with_dri
>  -  error('dri based GLX requires at least one DRI driver')
>  -elif not with_shared_glapi
>  +if not with_shared_glapi
>  error('dri based GLX requires shared-glapi')
>    endif
>  endif
>  --
>  2.19.2
> 
> >>> I'll have to think about this some more, I'm still not exactly sure why 
> >>> you'd
> >>> want to build the loader without a driver (although I could see why you 
> >>> might
> >>> want the driver without the loader).
> >>>
> Building both separate breaks away the dependency for llvm/clang while 
> building the loader package (mesa), thus eliminating the bottleneck, the 
> long build time of llvm/clang, in a complete build cycle of a whole 
> distribution rebuild for the packages "waiting" on mesa to complete. The 
> mesa-drivers package can wait for llvm/clang in the meantime. Right now 
> i have solved this by building the classic swrast with mesa and 
> instantly throwing it away after the build is finished.
> 
> Btw: Building the drivers without a windowing system would be nice as 
> well, this applies to the above use case where the -drivers package does 
> not need a windowing system, as it is contained in the other package.
> 
> Greetings
> 
> Tobias

This sounds like asking mesa to carry a lot of complexity so that distros can
build mesa as three separate packages. I'm really not thrilled about adding
such a feature unless someone wants to step up and be the maintainer of that
build mode and ensure it works. All of this complexity is technical debt that
the project is assuming, it makes the build definitions harder to read and
modify, and unless there's someone who actually uses such a mode (ie, not a core
developer, since no one has asked for this), it's just going to get broken. We
already have the most complicated build system I have ever seen (excluding Linux
and the core OS of FreeBSD) with more knobs and switches for micro tuning, let
alone all of the different combinations of drivers, platforms, window systems,
and APIs.

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] PSA: Please send MRs to the mailing list

[Jason Ekstrand]

On Mon, Dec 17, 2018 at 2:13 PM Jason Ekstrand  wrote:

> On Mon, Dec 17, 2018 at 1:53 PM Eric Anholt  wrote:
>
>> Jason Ekstrand  writes:
>>
>> > I don't know if it was actually in the doc that Jordan wrote up but it's
>> > courteous of you to send a quick e-mail to the mailing list when you
>> create
>> > a new MR so that people who aren't regularly trolling the list of MRs
>> are
>> > at least aware that it exists.  Of the 20 MRs that have been posted so
>> far,
>> > I think I'm the only one doing this.  I'm a big fan of MRs but I also
>> don't
>> > want us MR fans to anger the list. :-)
>>
>> The conclusion of the MR discussion was that notifying the list was
>> optional, I thought.
>>
>> +
>> +  If the MR may have interest for most of the Mesa community, you can
>> +  send an email to the mesa-dev email list including a link to the MR.
>> +  Don't send the patch to mesa-dev, just the MR link.
>> +
>>
>
> Yeah, I think the problem is that "interest for most of the Mesa
> community" is very vague.  What it really should mean is "unless you're
> very sure that everyone who cares is skimming through MRs".  I've seen
> multiple MRs which touch on st/mesa stuff in reasonably generic ways and
> I'm pretty sure the radeon devs and other gallium types were some of the
> less excited about MRs.
>
>
>> The MR process is heavier-weight than I hoped for, given that we're
>> currently requiring rebasing tags into commit messages.  I don't want to
>> add more overhead to it if we don't have to.
>>
>
> I agree.  I think the real solution here is that we just need a bot.
>

I took a swing at this.  This python script will do the trick if we can
find somewhere to host it and harden it a bit against being a spam-magnet:

https://paste.fedoraproject.org/paste/EGGpnxNNWEmadt0fWJEfGg

It's really not all that hard, it's just a bit annoying that GitLab
requires you to run server-side scripting in a web server in order to
implement a simple hook.

Unfortunately, Ilia's request for a diffstat is easier said than done.  In
order to do that, the script would have to actually pull the repo and run
git commands.  It could be done but would be a *lot* more work.  I'm not
going to attempt that today nor do I really want to get stuck maintaining a
python git hook library. :-P

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

Re: [Mesa-dev] MR: NIR: Partial redundancy elimination for compares

[Ilia Mirkin]

On Mon, Dec 17, 2018 at 5:05 PM Ian Romanick  wrote:
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/22
>
> This series adds a new optimization pass that tries to replace code
> sequences like
>
> if (x < y) {
> z = y - x;
> ...
> }
>
> with a sequence like
>
> t = x - y;
> if (t < 0) {
> z = -t;
> ...
> }

Is it worth worrying about infinities? e.g. if x = -Infinity, y =
Infinity, "x < y" will be true, but "x - y < 0" will not be (pretty
sure it'll be a NaN, which is not < 0).

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

Re: [Mesa-dev] PSA: Please send MRs to the mailing list

[Ian Romanick]

On 12/16/18 4:54 PM, Ilia Mirkin wrote:
> A diffstat would also be nice as it would better inform people reading
> emails whether they need to care or not.

That's a good idea.  I tagged the message that I just sent with MR: to
make it more obvious that it's for a merge request.  I saw Jason's
messages, but I didn't realize they were merge request notices until
after he started this thread. :)

> On Sun, Dec 16, 2018 at 7:53 PM Jason Ekstrand  wrote:
>>
>> One of these days, we will hopefully have a script to just do this for us.  
>> In the mean-time, manual isn't too bad.
>>
>> On Sun, Dec 16, 2018 at 6:52 PM Jason Ekstrand  wrote:
>>>
>>> I don't know if it was actually in the doc that Jordan wrote up but it's 
>>> courteous of you to send a quick e-mail to the mailing list when you create 
>>> a new MR so that people who aren't regularly trolling the list of MRs are 
>>> at least aware that it exists.  Of the 20 MRs that have been posted so far, 
>>> I think I'm the only one doing this.  I'm a big fan of MRs but I also don't 
>>> want us MR fans to anger the list. :-)
>>>
>>> --Jason
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Tobias Klausmann]

On 17.12.18 20:33, Dylan Baker wrote:

Quoting Emil Velikov (2018-12-17 11:10:00)

On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:

Quoting Emil Velikov (2018-12-13 08:15:57)

From: Emil Velikov 

Reasonably often people will want to build the loader w/o any drivers.
Be that debugging an issue in the former, distribution bundle or other.

Currently there is an artificial restriction preventing people to build
a config like the following:

  meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=

Cc: Dylan Baker 
Signed-off-by: Emil Velikov 
---
This is a WIP, since it's obviously incomplete/wrong. Input or fix
would be appreciated.

Thanks
Emil
---
  meson.build | 12 +---
  1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/meson.build b/meson.build
index 2aa2794f971..e1d6561c1a3 100644
--- a/meson.build
+++ b/meson.build
@@ -285,14 +285,6 @@ if with_glx == 'dri'
 endif
  endif

-if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
'gallium-xlib')
-  with_gles1 = false
-  with_gles2 = false
-  with_opengl = false
-  with_any_opengl = false
-  with_shared_glapi = false
-endif
-
  _gbm = get_option('gbm')
  if _gbm == 'auto'
with_gbm = system_has_kms_drm and with_dri
@@ -352,9 +344,7 @@ if with_glx != 'disabled'
error('xlib conflicts with any dri driver')
  endif
elif with_glx == 'dri'
-if not with_dri
-  error('dri based GLX requires at least one DRI driver')
-elif not with_shared_glapi
+if not with_shared_glapi
error('dri based GLX requires shared-glapi')
  endif
endif
--
2.19.2


I'll have to think about this some more, I'm still not exactly sure why you'd
want to build the loader without a driver (although I could see why you might
want the driver without the loader).

Building both separate breaks away the dependency for llvm/clang while 
building the loader package (mesa), thus eliminating the bottleneck, the 
long build time of llvm/clang, in a complete build cycle of a whole 
distribution rebuild for the packages "waiting" on mesa to complete. The 
mesa-drivers package can wait for llvm/clang in the meantime. Right now 
i have solved this by building the classic swrast with mesa and 
instantly throwing it away after the build is finished.


Btw: Building the drivers without a windowing system would be nice as 
well, this applies to the above use case where the -drivers package does 
not need a windowing system, as it is contained in the other package.


Greetings

Tobias



Usually both should work - loader w/o driver and driver w/o loader.

Imagine you're debugging some issues in libEGL - you don't want to
build driver X/Y/Z.
Additionally, distributions build latest loader and use it with DRI1
era drivers.

Ah, okay, building a new loader to test with dri1 drivers is a reasonable use
for this.


Having them build a driver, without an obvious reason is quite strange.

-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

[Mesa-dev] MR: NIR: Partial redundancy elimination for compares

[Ian Romanick]

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/22

This series adds a new optimization pass that tries to replace code
sequences like

if (x < y) {
z = y - x;
...
}

with a sequence like

t = x - y;
if (t < 0) {
z = -t;
...
}

On architectures where the subtract can generate the flags used by the
if-statement, this saves an instruction. It's also possible that moving
an instruction out of the if-statement will allow
nir_opt_peephole_select to convert the whole thing to a bcsel.

Currently only floating point compares and adds are supported. Adding
support for integer will be a challenge due to integer overflow. There
are a couple possible solutions, but they may not apply to all
architectures.

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

[Mesa-dev] [Bug 109075] radv: New D3D boolean optimizations cause GPU hang in Witcher 3

[bugzilla-daemon]

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

--- Comment #1 from var...@protonmail.com ---
Polaris 30 (RX 590, 4.20 and latest firmware), DXVK 0.94
Latest mesa-git built against llvm 7.0.1

This line also seems to break Overwatch, resulting in a black login screen.

Commenting out the line Philip mentioned fixed it.

-- 
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] freedreno/ir3: Make imageStore use num components from image format

[Ilia Mirkin]

Note that the format may not be known. I suspect that falls into your
"default" case.
On Mon, Dec 17, 2018 at 3:41 PM Eduardo Lima Mitev  wrote:
>
> emit_intrinsic_store_image() is always using 4 components when
> collecting registers for the value. When image has less than
> 4 components (e.g, r32f, r32i, r32ui) this results in extra mov
> instructions.
>
> This patch uses the actual number of components from the image format.
>
> For example, in a shader like:
>
> layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
> ...
> void main(void) {
>...
>imageStore (u_image, some_offset, vec4(1.0));
>...
> }
>
> instruction count is reduced in at least 3 instructions (note image
> format is r32f, 1 component only).
>
> This obviously reduces register pressure as well.
> ---
>  src/freedreno/ir3/ir3_compiler_nir.c | 34 ++--
>  1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
> b/src/freedreno/ir3/ir3_compiler_nir.c
> index 85f14f354d2..cc00602c249 100644
> --- a/src/freedreno/ir3/ir3_compiler_nir.c
> +++ b/src/freedreno/ir3/ir3_compiler_nir.c
> @@ -1251,6 +1251,35 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr,
> ir3_split_dest(b, dst, sam, 0, 4);
>  }
>
> +/* Get the number of components of the different image formats supported
> + * by the GLES 3.1 spec.
> + */
> +static unsigned
> +get_num_components_for_glformat(GLuint format)
> +{
> +   switch (format) {
> +   case GL_R32F:
> +   case GL_R32I:
> +   case GL_R32UI:
> +   return 1;
> +
> +   case GL_RGBA32F:
> +   case GL_RGBA16F:
> +   case GL_RGBA8:
> +   case GL_RGBA8_SNORM:
> +   case GL_RGBA32I:
> +   case GL_RGBA16I:
> +   case GL_RGBA8I:
> +   case GL_RGBA32UI:
> +   case GL_RGBA16UI:
> +   case GL_RGBA8UI:
> +   return 4;
> +
> +   default:
> +   assert(!"Unsupported GL format for image");
> +   }
> +}
> +
>  /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
>  static void
>  emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr 
> *intr)
> @@ -1262,6 +1291,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
> struct ir3_instruction * const *coords = ir3_get_src(ctx, 
> >src[1]);
> unsigned ncoords = get_image_coords(var, NULL);
> unsigned tex_idx = get_image_slot(ctx, 
> nir_src_as_deref(intr->src[0]));
> +   unsigned ncomp = 
> get_num_components_for_glformat(var->data.image.format);
>
> /* src0 is value
>  * src1 is coords
> @@ -1276,10 +1306,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
> nir_intrinsic_instr *intr)
>  */
>
> stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
> -   ir3_create_collect(ctx, value, 4), 0,
> +   ir3_create_collect(ctx, value, ncomp), 0,
> ir3_create_collect(ctx, coords, ncoords), 0,
> offset, 0);
> -   stib->cat6.iim_val = 4;
> +   stib->cat6.iim_val = ncomp;
> stib->cat6.d = ncoords;
> stib->cat6.type = get_image_type(var);
> stib->cat6.typed = true;
> --
> 2.19.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] freedreno/ir3: Make imageStore use num components from image format

[Eduardo Lima Mitev]

emit_intrinsic_store_image() is always using 4 components when
collecting registers for the value. When image has less than
4 components (e.g, r32f, r32i, r32ui) this results in extra mov
instructions.

This patch uses the actual number of components from the image format.

For example, in a shader like:

layout (r32f, binding=0) writeonly uniform imageBuffer u_image;
...
void main(void) {
   ...
   imageStore (u_image, some_offset, vec4(1.0));
   ...
}

instruction count is reduced in at least 3 instructions (note image
format is r32f, 1 component only).

This obviously reduces register pressure as well.
---
 src/freedreno/ir3/ir3_compiler_nir.c | 34 ++--
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/src/freedreno/ir3/ir3_compiler_nir.c 
b/src/freedreno/ir3/ir3_compiler_nir.c
index 85f14f354d2..cc00602c249 100644
--- a/src/freedreno/ir3/ir3_compiler_nir.c
+++ b/src/freedreno/ir3/ir3_compiler_nir.c
@@ -1251,6 +1251,35 @@ emit_intrinsic_load_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr,
ir3_split_dest(b, dst, sam, 0, 4);
 }
 
+/* Get the number of components of the different image formats supported
+ * by the GLES 3.1 spec.
+ */
+static unsigned
+get_num_components_for_glformat(GLuint format)
+{
+   switch (format) {
+   case GL_R32F:
+   case GL_R32I:
+   case GL_R32UI:
+   return 1;
+
+   case GL_RGBA32F:
+   case GL_RGBA16F:
+   case GL_RGBA8:
+   case GL_RGBA8_SNORM:
+   case GL_RGBA32I:
+   case GL_RGBA16I:
+   case GL_RGBA8I:
+   case GL_RGBA32UI:
+   case GL_RGBA16UI:
+   case GL_RGBA8UI:
+   return 4;
+
+   default:
+   assert(!"Unsupported GL format for image");
+   }
+}
+
 /* src[] = { deref, coord, sample_index, value }. const_index[] = {} */
 static void
 emit_intrinsic_store_image(struct ir3_context *ctx, nir_intrinsic_instr *intr)
@@ -1262,6 +1291,7 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
struct ir3_instruction * const *coords = ir3_get_src(ctx, 
>src[1]);
unsigned ncoords = get_image_coords(var, NULL);
unsigned tex_idx = get_image_slot(ctx, nir_src_as_deref(intr->src[0]));
+   unsigned ncomp = 
get_num_components_for_glformat(var->data.image.format);
 
/* src0 is value
 * src1 is coords
@@ -1276,10 +1306,10 @@ emit_intrinsic_store_image(struct ir3_context *ctx, 
nir_intrinsic_instr *intr)
 */
 
stib = ir3_STIB(b, create_immed(b, tex_idx), 0,
-   ir3_create_collect(ctx, value, 4), 0,
+   ir3_create_collect(ctx, value, ncomp), 0,
ir3_create_collect(ctx, coords, ncoords), 0,
offset, 0);
-   stib->cat6.iim_val = 4;
+   stib->cat6.iim_val = ncomp;
stib->cat6.d = ncoords;
stib->cat6.type = get_image_type(var);
stib->cat6.typed = true;
-- 
2.19.2

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

Re: [Mesa-dev] last call for autotools

[Marek Olšák]

On Mon, Dec 17, 2018 at 1:18 PM Eric Anholt  wrote:

> Eero Tamminen  writes:
>
> > Hi,
> >
> > On 17.12.2018 8.08, Marek Olšák wrote:
> > [...]
> >> I think one of the serious usability issues is that environment
> >> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are
> not
> >> saved by meson for future reconfigures.
> >
> > I don't know what Meson is supposed to do, but to me that would be
> > a bug in a build tool.
> >
> > Re-configure is supposed to adapt SW to the changes in the build
> > environment, and environment variables are part of that (along with
> > command line options and SW installed to to the system).  Build
> > configure tool deciding to "remember" some of those things instead
> > of checking the new situation, seems like a great opportunity for
> > confusion.
>
> A user-triggered reconfigure, sure.  Recapture env vars then.  But "git
> pull; ninja -C build" losing track of the configuration state is broken.
> We don't have to specify all of your meson -Doption=state configuration
> on every build, why should you need to specify your PKG_CONFIG_PATH
> configure options on every build?
>

Thanks, Eric.

Yes, meson behaves such that users have to set all environment variables
for every "ninja" command that might reconfigure.

I see 2 solutions:
1) meson needs to remember the relevant env vars
2) meson should FAIL to configure if any of the env vars are set (if it
wants to ignore them)

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

Re: [Mesa-dev] PSA: Please send MRs to the mailing list

[Jason Ekstrand]

On Mon, Dec 17, 2018 at 1:53 PM Eric Anholt  wrote:

> Jason Ekstrand  writes:
>
> > I don't know if it was actually in the doc that Jordan wrote up but it's
> > courteous of you to send a quick e-mail to the mailing list when you
> create
> > a new MR so that people who aren't regularly trolling the list of MRs are
> > at least aware that it exists.  Of the 20 MRs that have been posted so
> far,
> > I think I'm the only one doing this.  I'm a big fan of MRs but I also
> don't
> > want us MR fans to anger the list. :-)
>
> The conclusion of the MR discussion was that notifying the list was
> optional, I thought.
>
> +
> +  If the MR may have interest for most of the Mesa community, you can
> +  send an email to the mesa-dev email list including a link to the MR.
> +  Don't send the patch to mesa-dev, just the MR link.
> +
>

Yeah, I think the problem is that "interest for most of the Mesa community"
is very vague.  What it really should mean is "unless you're very sure that
everyone who cares is skimming through MRs".  I've seen multiple MRs which
touch on st/mesa stuff in reasonably generic ways and I'm pretty sure the
radeon devs and other gallium types were some of the less excited about MRs.


> The MR process is heavier-weight than I hoped for, given that we're
> currently requiring rebasing tags into commit messages.  I don't want to
> add more overhead to it if we don't have to.
>

I agree.  I think the real solution here is that we just need a bot.

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

Re: [Mesa-dev] PSA: Please send MRs to the mailing list

[Eric Anholt]

Jason Ekstrand  writes:

> I don't know if it was actually in the doc that Jordan wrote up but it's
> courteous of you to send a quick e-mail to the mailing list when you create
> a new MR so that people who aren't regularly trolling the list of MRs are
> at least aware that it exists.  Of the 20 MRs that have been posted so far,
> I think I'm the only one doing this.  I'm a big fan of MRs but I also don't
> want us MR fans to anger the list. :-)

The conclusion of the MR discussion was that notifying the list was
optional, I thought.

+
+  If the MR may have interest for most of the Mesa community, you can
+  send an email to the mesa-dev email list including a link to the MR.
+  Don't send the patch to mesa-dev, just the MR link.
+

The MR process is heavier-weight than I hoped for, given that we're
currently requiring rebasing tags into commit messages.  I don't want to
add more overhead to it if we don't have to.


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

Re: [Mesa-dev] [PATCH 03/18] glx: meson: build src/glx only with -Dglx=dri

[Dylan Baker]

Quoting Emil Velikov (2018-12-17 10:58:11)
> On Fri, 14 Dec 2018 at 17:13, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-13 08:05:52)
> > > From: Emil Velikov 
> > >
> > > The library is the dri capable one, push the check src/meson.build,
> > > instead of the current partial handling in src/glx/meson.build.
> > >
> > > Fixes: a47c525f328 ("meson: build glx")
> >
> > This is just a refactor, the Fixes: is unnecessary. More on that below
> >
> If I'm reading things correctly, building with -Dglx=xlib/gallium-xlib
> -Dshared-glapi -Denable-tests - will attempt to build the tests in
> src/glx/tests/.
> Which is something that shouldn't happen IMHO.

Wait, why shouldn't they run? The tests pass (at least with the gallium-xlib
glx), and running tests seems useful.

> With this in mind, do you think we should drop the fixes tag?
> 
> > > Signed-off-by: Emil Velikov 
> > > ---
> > >  src/glx/meson.build | 32 +++-
> > >  src/meson.build |  2 +-
> > >  2 files changed, 16 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > > index 3fd74439b11..898ed1f5826 100644
> > > --- a/src/glx/meson.build
> > > +++ b/src/glx/meson.build
> > > @@ -152,23 +152,21 @@ libglx = static_library(
> > >build_by_default : false,
> > >  )
> > >
> > > -if with_glx == 'dri'
> > > -  libgl = shared_library(
> > > -gl_lib_name,
> > > -[],
> > > -include_directories : [inc_common, inc_glapi, inc_loader, 
> > > inc_gl_internal],
> > > -link_with : [libglapi_static, libglapi],
> > > -link_whole : libglx,
> > > -link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> > > extra_ld_args_libgl],
> > > -dependencies : [
> > > -  dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, 
> > > dep_xcb,
> > > -  dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> > > dep_xxf86vm,
> > > -  extra_deps_libgl,
> > > -],
> > > -version : gl_lib_version,
> > > -install : true,
> > > -  )
> > > -endif
> > > +libgl = shared_library(
> > > +  gl_lib_name,
> > > +  [],
> > > +  include_directories : [inc_common, inc_glapi, inc_loader, 
> > > inc_gl_internal],
> > > +  link_with : [libglapi_static, libglapi],
> > > +  link_whole : libglx,
> > > +  link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> > > extra_ld_args_libgl],
> > > +  dependencies : [
> > > +dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> > > +dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> > > dep_xxf86vm,
> > > +extra_deps_libgl,
> > > +  ],
> > > +  version : gl_lib_version,
> > > +  install : true,
> > > +)
> >
> > All you're doing is refactoring out the build_by_default into an if 
> > statement.
> > If you're going to do this, please remove `build_by_default : false` from 
> > the
> > libglx in src/glx.
> >
> Sure thing.
> 
> > With those changes:
> > Reviewed-by: Dylan Baker 
> >
> 
> Thanks.
> Emil


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

Re: [Mesa-dev] [PATCH 18/18] travis: meson: port gallium build combinations over

[Dylan Baker]

Quoting Emil Velikov (2018-12-17 11:03:32)
> On Fri, 14 Dec 2018 at 17:53, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-13 08:06:07)
> > > From: Emil Velikov 
> > >
> > > This commit adds a number of build combos:
> > >
> > >  - Gallium Drivers {SWR, RadeonSI, Others)
> > > Each one has different LLVM requirements. Building SWR alone is twice
> > > as slow as all other drivers combined.
> > >
> > >  - Gallium ST Clover LLVM {5,6,7}
> > > Because C++ API changes all the time. Analogous to above building
> > > Clover takes as much time as building all other ST combined.
> > >
> > >  - Gallium ST Others
> > > Nouveau is used, instead of i915g since meson has explicit target
> > > tracking. Meaning that a configure error is throws if we use i915g
> > > with say va, vdpau or others.
> > >
> > > Note: LLVM prior to 5.0 is intentionally dropped. If needed we can add
> > > that later.
> > >
> > > Signed-off-by: Emil Velikov 
> > > ---
> > >  .travis.yml | 187 
> > >  1 file changed, 187 insertions(+)
> > >
> > > diff --git a/.travis.yml b/.travis.yml
> > > index 125d6ce3c68..b70df99d67e 100644
> > > --- a/.travis.yml
> > > +++ b/.travis.yml
> > > @@ -98,6 +98,193 @@ matrix:
> > >  - libxfixes-dev
> > >  - python3-pip
> > >  - python3-setuptools
> > > +- env:
> > > +# NOTE: Building SWR is 2x (yes two) times slower than all the 
> > > other
> > > +# gallium drivers combined.
> > > +# Start this early so that it doesn't hunder the run time.
> > > +- LABEL="meson Gallium Drivers SWR"
> > > +- BUILD=meson
> > > +- UNWIND="true"
> > > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > > +- GALLIUM_DRIVERS="swr"
> > > +- LLVM_VERSION=6.0
> > > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > > +  addons:
> > > +apt:
> > > +  packages:
> > > +- llvm-6.0-dev
> > > +# Common
> > > +- xz-utils
> > > +- libexpat1-dev
> > > +- libx11-xcb-dev
> > > +- libelf-dev
> > > +- libunwind8-dev
> > > +- python3.5
> > > +- python3-pip
> > > +- python3-setuptools
> > > +- env:
> > > +- LABEL="meson Gallium Drivers RadeonSI"
> > > +- BUILD=meson
> > > +- UNWIND="true"
> > > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > > +- GALLIUM_DRIVERS="radeonsi"
> > > +- LLVM_VERSION=7
> > > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > > +  addons:
> > > +apt:
> > > +  sources:
> > > +- sourceline: 'deb http://apt.llvm.org/xenial/ 
> > > llvm-toolchain-xenial-7 main'
> > > +  key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
> > > +  packages:
> > > +# From sources above
> > > +- llvm-7-dev
> > > +# Common
> > > +- xz-utils
> > > +- libexpat1-dev
> > > +- libx11-xcb-dev
> > > +- libelf-dev
> > > +- libunwind8-dev
> > > +- python3.5
> > > +- python3-pip
> > > +- python3-setuptools
> > > +- env:
> > > +- LABEL="meson Gallium Drivers Other"
> > > +- BUILD=meson
> > > +- UNWIND="true"
> > > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > > +- 
> > > GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,v3d,vc4,virgl,etnaviv,imx"
> > > +- LLVM_VERSION=5.0
> > > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > > +  addons:
> > > +apt:
> > > +  packages:
> > > +# LLVM packaging is broken and misses these dependencies
> > > +- libedit-dev
> > > +- llvm-5.0-dev
> > > +# Common
> > > +- xz-utils
> > > +- libexpat1-dev
> > > +- libx11-xcb-dev
> > > +- libelf-dev
> > > +- libunwind8-dev
> > > +- python3.5
> > > +- python3-pip
> > > +- python3-setuptools
> > > +- env:
> > > +- LABEL="meson Gallium ST Clover LLVM-5.0"
> > > +- BUILD=meson
> > > +- UNWIND="true"
> > > +- 

Re: [Mesa-dev] [PATCH] WIP: meson: allow building DRI loaders without a DRI driver

[Dylan Baker]

Quoting Emil Velikov (2018-12-17 11:10:00)
> On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-13 08:15:57)
> > > From: Emil Velikov 
> > >
> > > Reasonably often people will want to build the loader w/o any drivers.
> > > Be that debugging an issue in the former, distribution bundle or other.
> > >
> > > Currently there is an artificial restriction preventing people to build
> > > a config like the following:
> > >
> > >  meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= 
> > > -Dgallium-drivers=
> > >
> > > Cc: Dylan Baker 
> > > Signed-off-by: Emil Velikov 
> > > ---
> > > This is a WIP, since it's obviously incomplete/wrong. Input or fix
> > > would be appreciated.
> > >
> > > Thanks
> > > Emil
> > > ---
> > >  meson.build | 12 +---
> > >  1 file changed, 1 insertion(+), 11 deletions(-)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index 2aa2794f971..e1d6561c1a3 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -285,14 +285,6 @@ if with_glx == 'dri'
> > > endif
> > >  endif
> > >
> > > -if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
> > > 'gallium-xlib')
> > > -  with_gles1 = false
> > > -  with_gles2 = false
> > > -  with_opengl = false
> > > -  with_any_opengl = false
> > > -  with_shared_glapi = false
> > > -endif
> > > -
> > >  _gbm = get_option('gbm')
> > >  if _gbm == 'auto'
> > >with_gbm = system_has_kms_drm and with_dri
> > > @@ -352,9 +344,7 @@ if with_glx != 'disabled'
> > >error('xlib conflicts with any dri driver')
> > >  endif
> > >elif with_glx == 'dri'
> > > -if not with_dri
> > > -  error('dri based GLX requires at least one DRI driver')
> > > -elif not with_shared_glapi
> > > +if not with_shared_glapi
> > >error('dri based GLX requires shared-glapi')
> > >  endif
> > >endif
> > > --
> > > 2.19.2
> > >
> >
> > I'll have to think about this some more, I'm still not exactly sure why 
> > you'd
> > want to build the loader without a driver (although I could see why you 
> > might
> > want the driver without the loader).
> >
> Usually both should work - loader w/o driver and driver w/o loader.
> 
> Imagine you're debugging some issues in libEGL - you don't want to
> build driver X/Y/Z.
> Additionally, distributions build latest loader and use it with DRI1
> era drivers.

Ah, okay, building a new loader to test with dri1 drivers is a reasonable use
for this.

> 
> Having them build a driver, without an obvious reason is quite strange.
> 
> -Emil


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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #7 from Dylan Baker  ---
but if the time difference is negligible then thats a fair trade for a better
error message :)

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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #6 from Dylan Baker  ---
that's not the right comparison though. Meson doesn't support querying two
dependencies at the same time, that's something that only pkg-config can do
(you can't do that with windows find-a-dll, mac's frameworks, cmake searching,
or the wrappers for the various *-config tools. So what you're actually doing
is:

pkg-config --libs "libdrm_nouveau >= 2.4.20"

vs

pkg-config --libs "libdrm >= 2.4.20"
pkg-config --libs "libdrm_nouveau >= 2.4.20"

that will take more time, I think it's worth while to figure out how much time.
I fell like spending less time configuring is more important than getting a
slightly better error message.

-- 
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] WIP: meson: allow building DRI loaders without a DRI driver

[Emil Velikov]

On Fri, 14 Dec 2018 at 17:57, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-13 08:15:57)
> > From: Emil Velikov 
> >
> > Reasonably often people will want to build the loader w/o any drivers.
> > Be that debugging an issue in the former, distribution bundle or other.
> >
> > Currently there is an artificial restriction preventing people to build
> > a config like the following:
> >
> >  meson build/ -Dglx=dri -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=
> >
> > Cc: Dylan Baker 
> > Signed-off-by: Emil Velikov 
> > ---
> > This is a WIP, since it's obviously incomplete/wrong. Input or fix
> > would be appreciated.
> >
> > Thanks
> > Emil
> > ---
> >  meson.build | 12 +---
> >  1 file changed, 1 insertion(+), 11 deletions(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 2aa2794f971..e1d6561c1a3 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -285,14 +285,6 @@ if with_glx == 'dri'
> > endif
> >  endif
> >
> > -if not (with_dri or with_gallium or with_glx == 'xlib' or with_glx == 
> > 'gallium-xlib')
> > -  with_gles1 = false
> > -  with_gles2 = false
> > -  with_opengl = false
> > -  with_any_opengl = false
> > -  with_shared_glapi = false
> > -endif
> > -
> >  _gbm = get_option('gbm')
> >  if _gbm == 'auto'
> >with_gbm = system_has_kms_drm and with_dri
> > @@ -352,9 +344,7 @@ if with_glx != 'disabled'
> >error('xlib conflicts with any dri driver')
> >  endif
> >elif with_glx == 'dri'
> > -if not with_dri
> > -  error('dri based GLX requires at least one DRI driver')
> > -elif not with_shared_glapi
> > +if not with_shared_glapi
> >error('dri based GLX requires shared-glapi')
> >  endif
> >endif
> > --
> > 2.19.2
> >
>
> I'll have to think about this some more, I'm still not exactly sure why you'd
> want to build the loader without a driver (although I could see why you might
> want the driver without the loader).
>
Usually both should work - loader w/o driver and driver w/o loader.

Imagine you're debugging some issues in libEGL - you don't want to
build driver X/Y/Z.
Additionally, distributions build latest loader and use it with DRI1
era drivers.

Having them build a driver, without an obvious reason is quite strange.

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

Re: [Mesa-dev] [PATCH 1/6] st/mesa: Drop dead 'passthrough_fs' field.

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 
On Mon, Dec 17, 2018 at 1:37 PM Kenneth Graunke  wrote:
>
> Dead since 2015 (commit 5142564734bd68f165b02e29e384ebbcf91cce38).
> ---
>  src/mesa/state_tracker/st_context.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_context.h 
> b/src/mesa/state_tracker/st_context.h
> index 95133c7020f..78e962dec00 100644
> --- a/src/mesa/state_tracker/st_context.h
> +++ b/src/mesa/state_tracker/st_context.h
> @@ -278,8 +278,6 @@ struct st_context
> /** for drawing with st_util_vertex */
> struct pipe_vertex_element util_velems[3];
>
> -   void *passthrough_fs;  /**< simple pass-through frag shader */
> -
> enum pipe_texture_target internal_target;
>
> struct cso_context *cso_context;
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 18/18] travis: meson: port gallium build combinations over

[Emil Velikov]

On Fri, 14 Dec 2018 at 17:53, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-13 08:06:07)
> > From: Emil Velikov 
> >
> > This commit adds a number of build combos:
> >
> >  - Gallium Drivers {SWR, RadeonSI, Others)
> > Each one has different LLVM requirements. Building SWR alone is twice
> > as slow as all other drivers combined.
> >
> >  - Gallium ST Clover LLVM {5,6,7}
> > Because C++ API changes all the time. Analogous to above building
> > Clover takes as much time as building all other ST combined.
> >
> >  - Gallium ST Others
> > Nouveau is used, instead of i915g since meson has explicit target
> > tracking. Meaning that a configure error is throws if we use i915g
> > with say va, vdpau or others.
> >
> > Note: LLVM prior to 5.0 is intentionally dropped. If needed we can add
> > that later.
> >
> > Signed-off-by: Emil Velikov 
> > ---
> >  .travis.yml | 187 
> >  1 file changed, 187 insertions(+)
> >
> > diff --git a/.travis.yml b/.travis.yml
> > index 125d6ce3c68..b70df99d67e 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -98,6 +98,193 @@ matrix:
> >  - libxfixes-dev
> >  - python3-pip
> >  - python3-setuptools
> > +- env:
> > +# NOTE: Building SWR is 2x (yes two) times slower than all the 
> > other
> > +# gallium drivers combined.
> > +# Start this early so that it doesn't hunder the run time.
> > +- LABEL="meson Gallium Drivers SWR"
> > +- BUILD=meson
> > +- UNWIND="true"
> > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > +- GALLIUM_DRIVERS="swr"
> > +- LLVM_VERSION=6.0
> > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > +  addons:
> > +apt:
> > +  packages:
> > +- llvm-6.0-dev
> > +# Common
> > +- xz-utils
> > +- libexpat1-dev
> > +- libx11-xcb-dev
> > +- libelf-dev
> > +- libunwind8-dev
> > +- python3.5
> > +- python3-pip
> > +- python3-setuptools
> > +- env:
> > +- LABEL="meson Gallium Drivers RadeonSI"
> > +- BUILD=meson
> > +- UNWIND="true"
> > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > +- GALLIUM_DRIVERS="radeonsi"
> > +- LLVM_VERSION=7
> > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > +  addons:
> > +apt:
> > +  sources:
> > +- sourceline: 'deb http://apt.llvm.org/xenial/ 
> > llvm-toolchain-xenial-7 main'
> > +  key_url: https://apt.llvm.org/llvm-snapshot.gpg.key
> > +  packages:
> > +# From sources above
> > +- llvm-7-dev
> > +# Common
> > +- xz-utils
> > +- libexpat1-dev
> > +- libx11-xcb-dev
> > +- libelf-dev
> > +- libunwind8-dev
> > +- python3.5
> > +- python3-pip
> > +- python3-setuptools
> > +- env:
> > +- LABEL="meson Gallium Drivers Other"
> > +- BUILD=meson
> > +- UNWIND="true"
> > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=disabled"
> > +- 
> > GALLIUM_DRIVERS="i915,nouveau,pl111,r300,r600,freedreno,svga,swrast,v3d,vc4,virgl,etnaviv,imx"
> > +- LLVM_VERSION=5.0
> > +- LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> > +  addons:
> > +apt:
> > +  packages:
> > +# LLVM packaging is broken and misses these dependencies
> > +- libedit-dev
> > +- llvm-5.0-dev
> > +# Common
> > +- xz-utils
> > +- libexpat1-dev
> > +- libx11-xcb-dev
> > +- libelf-dev
> > +- libunwind8-dev
> > +- python3.5
> > +- python3-pip
> > +- python3-setuptools
> > +- env:
> > +- LABEL="meson Gallium ST Clover LLVM-5.0"
> > +- BUILD=meson
> > +- UNWIND="true"
> > +- DRI_LOADERS="-Dglx=disabled -Degl=false -Dgbm=false"
> > +- GALLIUM_ST="-Ddri3=false -Dgallium-vdpau=false 
> > -Dgallium-xvmc=false -Dgallium-omx=disabled -Dgallium-va=false 
> > -Dgallium-xa=false -Dgallium-nine=false -Dgallium-opencl=icd"
> > +- GALLIUM_DRIVERS="r600"
> > +- 

Re: [Mesa-dev] [PATCH 03/18] glx: meson: build src/glx only with -Dglx=dri

[Emil Velikov]

On Fri, 14 Dec 2018 at 17:13, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-13 08:05:52)
> > From: Emil Velikov 
> >
> > The library is the dri capable one, push the check src/meson.build,
> > instead of the current partial handling in src/glx/meson.build.
> >
> > Fixes: a47c525f328 ("meson: build glx")
>
> This is just a refactor, the Fixes: is unnecessary. More on that below
>
If I'm reading things correctly, building with -Dglx=xlib/gallium-xlib
-Dshared-glapi -Denable-tests - will attempt to build the tests in
src/glx/tests/.
Which is something that shouldn't happen IMHO.

With this in mind, do you think we should drop the fixes tag?

> > Signed-off-by: Emil Velikov 
> > ---
> >  src/glx/meson.build | 32 +++-
> >  src/meson.build |  2 +-
> >  2 files changed, 16 insertions(+), 18 deletions(-)
> >
> > diff --git a/src/glx/meson.build b/src/glx/meson.build
> > index 3fd74439b11..898ed1f5826 100644
> > --- a/src/glx/meson.build
> > +++ b/src/glx/meson.build
> > @@ -152,23 +152,21 @@ libglx = static_library(
> >build_by_default : false,
> >  )
> >
> > -if with_glx == 'dri'
> > -  libgl = shared_library(
> > -gl_lib_name,
> > -[],
> > -include_directories : [inc_common, inc_glapi, inc_loader, 
> > inc_gl_internal],
> > -link_with : [libglapi_static, libglapi],
> > -link_whole : libglx,
> > -link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> > extra_ld_args_libgl],
> > -dependencies : [
> > -  dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> > -  dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> > dep_xxf86vm,
> > -  extra_deps_libgl,
> > -],
> > -version : gl_lib_version,
> > -install : true,
> > -  )
> > -endif
> > +libgl = shared_library(
> > +  gl_lib_name,
> > +  [],
> > +  include_directories : [inc_common, inc_glapi, inc_loader, 
> > inc_gl_internal],
> > +  link_with : [libglapi_static, libglapi],
> > +  link_whole : libglx,
> > +  link_args : [ld_args_bsymbolic, ld_args_gc_sections, 
> > extra_ld_args_libgl],
> > +  dependencies : [
> > +dep_libdrm, dep_dl, dep_m, dep_thread, dep_x11, dep_xcb_glx, dep_xcb,
> > +dep_x11_xcb, dep_xcb_dri2, dep_xext, dep_xfixes, dep_xdamage, 
> > dep_xxf86vm,
> > +extra_deps_libgl,
> > +  ],
> > +  version : gl_lib_version,
> > +  install : true,
> > +)
>
> All you're doing is refactoring out the build_by_default into an if statement.
> If you're going to do this, please remove `build_by_default : false` from the
> libglx in src/glx.
>
Sure thing.

> With those changes:
> Reviewed-by: Dylan Baker 
>

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

Re: [Mesa-dev] [PATCH mesa] drop autotools

[Bas Nieuwenhuizen]

On Mon, Dec 17, 2018 at 6:33 PM Juan A. Suarez Romero
 wrote:
>
> On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> > Cc: Emil Velikov 
> > Cc: Andres Gomez 
> > Cc: Juan A. Suarez Romero 
> > Cc: Dylan Baker 
> > Signed-off-by: Eric Engestrom 
> > ---
> > This patch depends on the releasing procedure in docs/releasing.html to
> > be updated to not rely on autotools anymore.
> >
> > I think our release managers (cc'ed) should work together and figure out
> > the procedure they want to go by; only once that's done can we delete
> > these 200+ files and 14k+ lines :)
>
>
> I'll let others to talk. But my preference would be to land this for next 19.0
> branchpoint, just a couple of days before the branchpoint, so 19.0.x releases
> get rid of autotools.
>
> This way we have time to fix any remaining issue, and make like easier for 
> those
> in charge of 18.3.x releases, which I think should support autotools until the
> end of its life.

Can I suggest the inverse, pushing this long before any branchpoint?

As with any migration, users only start using when you force them too,
and that means a bunch of non-working usecases are going to be
detected once this patch is pushed and some more people are forced to
it. Sure, the last call discussion served to tease some of these out,
but I expect even more will turn up if you submit this.

Doing this far before the branchpoint gives more time to fix them.

>
>
> J.A.
>
> > ---
> >  .gitignore|   54 -
> >  Makefile.am   |   92 -
> >  REVIEWERS |9 -
> >  autogen.sh|   14 -
> >  bin/.gitignore|9 -
> >  configure.ac  | 3375 -
> >  docs/autoconf.html|  264 --
> >  docs/contents.html|1 -
> >  docs/download.html|1 -
> >  docs/install.html |   21 +-
> >  docs/llvmpipe.html|8 -
> >  docs/mangling.html|2 +-
> >  docs/meson.html   |2 +-
> >  docs/relnotes/19.0.0.html |7 +-
> >  doxygen/.gitignore|   19 -
> >  m4/.gitignore |5 -
> >  m4/ax_check_compile_flag.m4   |   79 -
> >  m4/ax_check_gnu_make.m4   |   78 -
> >  m4/ax_check_python_mako_module.m4 |   64 -
> >  m4/ax_gcc_builtin.m4  |  168 -
> >  m4/ax_gcc_func_attribute.m4   |  230 --
> >  m4/ax_prog_bison.m4   |   71 -
> >  m4/ax_prog_flex.m4|   63 -
> >  m4/ax_pthread.m4  |  309 --
> >  src/Makefile.am   |  138 -
> >  src/amd/Makefile.addrlib.am   |   40 -
> >  src/amd/Makefile.am   |   35 -
> >  src/amd/Makefile.common.am|   71 -
> >  src/amd/common/.gitignore |1 -
> >  src/amd/vulkan/.gitignore |9 -
> >  src/amd/vulkan/Makefile.am|  200 -
> >  src/broadcom/.gitignore   |3 -
> >  src/broadcom/Makefile.am  |   65 -
> >  src/broadcom/Makefile.cle.am  |6 -
> >  src/broadcom/Makefile.genxml.am   |   54 -
> >  src/broadcom/Makefile.v3d.am  |   32 -
> >  src/broadcom/qpu/tests/.gitignore |1 -
> >  src/compiler/.gitignore   |6 -
> >  src/compiler/Makefile.am  |   77 -
> >  src/compiler/Makefile.glsl.am |  264 --
> >  src/compiler/Makefile.nir.am  |  116 -
> >  src/compiler/Makefile.spirv.am|   59 -
> >  src/compiler/glsl/.gitignore  |   12 -
> >  src/compiler/glsl/glcpp/.gitignore|6 -
> >  src/compiler/glsl/glcpp/tests/.gitignore  |4 -
> >  src/compiler/glsl/tests/.gitignore|6 -
> >  src/compiler/glsl/tests/warnings/.gitignore   |1 -
> >  src/compiler/nir/.gitignore   |7 -
> >  src/compiler/nir/tests/.gitignore |1 -
> >  src/compiler/spirv/.gitignore |2 -
> >  src/egl/.gitignore|2 -
> >  src/egl/Makefile.am   |  235 --
> >  src/egl/drivers/dri2/.gitignore   |2 -
> >  src/egl/wayland/wayland-drm/.gitignore|3 -
> >  src/egl/wayland/wayland-drm/Makefile.am   |   37 -
> >  src/freedreno/Makefile.am |   76 -
> >  src/gallium/Automake.inc  |   90 -
> >  src/gallium/Makefile.am   |  211 --
> >  

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #5 from Emil Velikov  ---
On my 3+ y/o laptop shows virtually no difference in runtime between the
following two commands.

pkg-config --libs "libdrm >= 2.4.20" "libdrm_nouveau >= 2.4.20"
pkg-config --libs "libdrm_nouveau >= 2.4.20"

So in all fairness, I'm not sure if the micro optimisations are worth the
effort or code complexity.

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

Re: [Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Emil Velikov]

On Mon, 17 Dec 2018 at 18:14, Andres Gomez  wrote:
>
> On Mon, 2018-12-17 at 16:43 +, Emil Velikov wrote:
> > Currently our is_sha_nomination does:
> >  - folds any whitespace, attempting to extract sha-like information
> >  - checks that at least one of the shas has landed
> >
> > Split it in two and do sha-like validation first.
> >
> > This way, commits with mesa-stable and sha nominations will feature the
> > fixes/revert/etc instead of stable (a) or will be omitted if not
> > applicable for the respective branch (b).
> >
> > Misc examples from 18.3
> >
> > (a)
> > -[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > rendering
> > +[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct 
> > rendering
> >
> > (b)
> > -[   stable ] 9a7b3199037 anv/query: flush render target before copying 
> > results
> >
> > CC: Andres Gomez 
> > CC: Juan A. Suarez 
> > CC: Dylan Baker 
> > CC: mesa-sta...@lists.freedesktop.org
> > Signed-off-by: Emil Velikov 
> > ---
> > Juan I've noticed that you've been experiencing the above annoyance for
> > a while. Having less false-positives should ease things up a bit :-)
> > ---
> >  bin/get-pick-list.sh | 46 +---
> >  1 file changed, 30 insertions(+), 16 deletions(-)
> >
> > diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> > index 9f9cbc44026..08a783f35a8 100755
> > --- a/bin/get-pick-list.sh
> > +++ b/bin/get-pick-list.sh
> > @@ -21,32 +21,36 @@ is_typod_nomination()
> >   git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
> >  }
> >
> > +fixes=
> > +
>
> Splitting in 2 functions for which we need now a global variable is not
> very nice. Anyway, let's not make this more complicated than needed.
>
Wasn't too happy about it either. As you said - I've decided to go
with the simpler solution.

> >  # Helper to handle various mistypos of the fixes tag.
> >  # The tag string itself is passed as argument and normalised within.
> > +#
> > +# Resulting string in the global variable "fixes" and contains entries
> > +# in the form "fixes:$sha"
> >  is_sha_nomination()
> >  {
> >   fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
> >   sed -e 's/'"$2"'/\nfixes:/Ig' | \
> >   grep -Eo 'fixes:[a-f0-9]{8,40}'`
> >
> > - fixes_count=`echo "$fixes" | wc -l`
> > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
>
> Why is the extra "grep" needed here?
>
Commits that include "fixes $some_test" will result in fixes="".
Thus wc -l will return 1

> >   if test $fixes_count -eq 0; then
> > - return 0
> > + return 1
>
> Ugh! Right.
>
> >   fi
> > + return 0
> > +}
> > +
> > +# Checks if at least one of offending commits, listed in the global
> > +# "fixes", is in branch.
> > +sha_in_range()
> > +{
> > + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
>
> Ditto.
>
> >   while test $fixes_count -gt 0; do
> >   # Treat only the current line
> >   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut -d 
> > : -f 2`
> >   fixes_count=$(($fixes_count-1))
> >
> > - # Bail out if we cannot find suitable id.
> > - # Any specific validation the $id is valid and not some junk, 
> > is
> > - # implied with the follow up code
> > - if test "x$id" = x; then
> > - continue
> > - fi
> > -
> > - #Check if the offending commit is in branch.
> > -
>
> Was this never needed in the first place? Feels right to remove it
> since $fixes should have some content by now, but I wonder how this got
> here in the first place.
>
Left-over from the old standalone script. Copied a bit too much :-(

> >   # Be that cherry-picked ...
> >   # ... or landed before the branchpoint.
> >   if grep -q ^$id already_picked ||
> > @@ -103,20 +107,30 @@ do
> >   continue
> >   fi
> >
> > - if is_stable_nomination "$sha"; then
> > - tag=stable
> > - elif is_typod_nomination "$sha"; then
> > - tag=typod
> > - elif is_fixes_nomination "$sha"; then
> > + if is_fixes_nomination "$sha"; then
> >   tag=fixes
> >   elif is_brokenby_nomination "$sha"; then
> >   tag=brokenby
> >   elif is_revert_nomination "$sha"; then
> >   tag=revert
> > + elif is_stable_nomination "$sha"; then
> > + tag=stable
> > + elif is_typod_nomination "$sha"; then
> > + tag=typod
> >   else
> >   continue
> >   fi
> >
> > + case "$tag" in
> > + fixes | brokenby | revert )
> > + if ! sha_in_range; then
> > + continue
> > + fi
> > + ;;
> > + * )
> > + ;;
> > + esac
> > +
> >   printf "[ %8s ] " "$tag"
> >   git --no-pager show --summary --oneline $sha
> >  done
>
> I'm not sure we 

[Mesa-dev] [PATCH 6/6] st/nir: Drop unused gl_program parameter in VS input handling helper.

[Kenneth Graunke]

Nobody uses this, so let's drop it.  This makes the helper callable
from places without a gl_program.
---
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index 7406e26e2f8..5263edc5a6d 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -81,7 +81,7 @@ st_nir_fixup_varying_slots(struct st_context *st, struct 
exec_list *var_list)
  * on varying-slot w/ the VS outputs)
  */
 static void
-st_nir_assign_vs_in_locations(struct gl_program *prog, nir_shader *nir)
+st_nir_assign_vs_in_locations(nir_shader *nir)
 {
nir->num_inputs = 0;
nir_foreach_variable_safe(var, >inputs) {
@@ -810,7 +810,7 @@ st_finalize_nir(struct st_context *st, struct gl_program 
*prog,
 
if (nir->info.stage == MESA_SHADER_VERTEX) {
   /* Needs special handling so drvloc matches the vbo state: */
-  st_nir_assign_vs_in_locations(prog, nir);
+  st_nir_assign_vs_in_locations(nir);
   /* Re-lower global vars, to deal with any dead VS inputs. */
   NIR_PASS_V(nir, nir_lower_global_vars_to_local);
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 3/6] st/mesa: Don't open code the drawpixels vertex shader.

[Kenneth Graunke]

Now that we always copy color, we can just use the util function.
---
 src/mesa/state_tracker/st_cb_drawpixels.c | 38 +++
 1 file changed, 11 insertions(+), 27 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 0bb2caf5edc..120b5c48339 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -72,6 +72,7 @@
 #include "util/u_format.h"
 #include "util/u_inlines.h"
 #include "util/u_math.h"
+#include "util/u_simple_shaders.h"
 #include "util/u_tile.h"
 #include "cso_cache/cso_context.h"
 
@@ -196,35 +197,18 @@ get_drawpix_z_stencil_program(struct st_context *st,
 static void
 make_passthrough_vertex_shader(struct st_context *st)
 {
-   const enum tgsi_semantic texcoord_semantic = st->needs_texcoord_semantic ?
-  TGSI_SEMANTIC_TEXCOORD : TGSI_SEMANTIC_GENERIC;
+   if (st->drawpix.vert_shader)
+  return;
 
-   if (!st->drawpix.vert_shader) {
-  struct ureg_program *ureg = ureg_create( PIPE_SHADER_VERTEX );
+   const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
+   TGSI_SEMANTIC_COLOR,
+ st->needs_texcoord_semantic ? TGSI_SEMANTIC_TEXCOORD :
+   TGSI_SEMANTIC_GENERIC };
+   const uint semantic_indexes[] = { 0, 0, 0 };
 
-  if (ureg == NULL)
- return;
-
-  /* MOV result.pos, vertex.pos; */
-  ureg_MOV(ureg,
-   ureg_DECL_output( ureg, TGSI_SEMANTIC_POSITION, 0 ),
-   ureg_DECL_vs_input( ureg, 0 ));
-
-  /* MOV result.color0, vertex.attr[1]; */
-  ureg_MOV(ureg,
-   ureg_DECL_output( ureg, TGSI_SEMANTIC_COLOR, 0 ),
-   ureg_DECL_vs_input( ureg, 1 ));
-
-  /* MOV result.texcoord0, vertex.attr[2]; */
-  ureg_MOV(ureg,
-   ureg_DECL_output( ureg, texcoord_semantic, 0 ),
-   ureg_DECL_vs_input( ureg, 2 ));
-
-  ureg_END( ureg );
-  
-  st->drawpix.vert_shader =
- ureg_create_shader_and_destroy( ureg, st->pipe );
-   }
+   st->drawpix.vert_shader =
+  util_make_vertex_passthrough_shader(st->pipe, 3, semantic_names,
+  semantic_indexes, false);
 }
 
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 5/6] st/nir: Gather info after applying lowering FS variant features

[Kenneth Graunke]

DrawPixels lowering, for example, adds new varyings that need to be
accounted for in inputs_read.  The earlier info gathering at link time
cannot account for this.
---
 src/mesa/state_tracker/st_program.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/mesa/state_tracker/st_program.c 
b/src/mesa/state_tracker/st_program.c
index 3bc7b0649c4..422b7b2a593 100644
--- a/src/mesa/state_tracker/st_program.c
+++ b/src/mesa/state_tracker/st_program.c
@@ -1103,6 +1103,10 @@ st_create_fp_variant(struct st_context *st,
 key->external.lower_iyuv);
   }
 
+  /* Some of the lowering above may have introduced new varyings */
+  nir_shader_gather_info(tgsi.ir.nir,
+ nir_shader_get_entrypoint(tgsi.ir.nir));
+
   variant->driver_shader = pipe->create_fs_state(pipe, );
   variant->key = *key;
 
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/6] st/mesa: Drop !passColor optimization in drawpixels shaders.

[Kenneth Graunke]

The glDrawPixels passthrough vertex shader copies position and texcoord
vertex attributes to varying outputs.  It also optionally copies a third
gl_Color attribute, which sometimes is unnecessary.  Until now, we've
compiled separate variants of the shader, one of which does this extra
copy, and the other of which doesn't.  We have done this since 2007.

But, the vertex shader runs for a whopping four vertices, and so the
cost of a copying a single input to output is likely inconsequential.
In theory, we could bind one fewer vertex element - but we always bind
all three regardless.  So, we don't even get that savings.

This patch unifies the two, so we always copy the optional color,
and save having to compile the variant.  It also makes the VS input
interface match up with the vertex element state without any dead
(unused) input attributes.
---
 src/mesa/state_tracker/st_cb_drawpixels.c | 46 ++-
 src/mesa/state_tracker/st_context.h   |  2 +-
 2 files changed, 20 insertions(+), 28 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 4f08e751393..0bb2caf5edc 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -191,32 +191,29 @@ get_drawpix_z_stencil_program(struct st_context *st,
 
 /**
  * Create a simple vertex shader that just passes through the
- * vertex position and texcoord (and optionally, color).
+ * vertex position, texcoord, and color.
  */
-static void *
-make_passthrough_vertex_shader(struct st_context *st, 
-   GLboolean passColor)
+static void
+make_passthrough_vertex_shader(struct st_context *st)
 {
const enum tgsi_semantic texcoord_semantic = st->needs_texcoord_semantic ?
   TGSI_SEMANTIC_TEXCOORD : TGSI_SEMANTIC_GENERIC;
 
-   if (!st->drawpix.vert_shaders[passColor]) {
+   if (!st->drawpix.vert_shader) {
   struct ureg_program *ureg = ureg_create( PIPE_SHADER_VERTEX );
 
   if (ureg == NULL)
- return NULL;
+ return;
 
   /* MOV result.pos, vertex.pos; */
   ureg_MOV(ureg,
ureg_DECL_output( ureg, TGSI_SEMANTIC_POSITION, 0 ),
ureg_DECL_vs_input( ureg, 0 ));
 
-  if (passColor) {
- /* MOV result.color0, vertex.attr[1]; */
- ureg_MOV(ureg,
-  ureg_DECL_output( ureg, TGSI_SEMANTIC_COLOR, 0 ),
-  ureg_DECL_vs_input( ureg, 1 ));
-  }
+  /* MOV result.color0, vertex.attr[1]; */
+  ureg_MOV(ureg,
+   ureg_DECL_output( ureg, TGSI_SEMANTIC_COLOR, 0 ),
+   ureg_DECL_vs_input( ureg, 1 ));
 
   /* MOV result.texcoord0, vertex.attr[2]; */
   ureg_MOV(ureg,
@@ -225,11 +222,9 @@ make_passthrough_vertex_shader(struct st_context *st,
 
   ureg_END( ureg );
   
-  st->drawpix.vert_shaders[passColor] = 
+  st->drawpix.vert_shader =
  ureg_create_shader_and_destroy( ureg, st->pipe );
}
-
-   return st->drawpix.vert_shaders[passColor];
 }
 
 
@@ -1135,7 +1130,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   GLenum format, GLenum type,
   const struct gl_pixelstore_attrib *unpack, const void *pixels)
 {
-   void *driver_vp, *driver_fp;
+   void *driver_fp;
struct st_context *st = st_context(ctx);
struct pipe_context *pipe = st->pipe;
GLboolean write_stencil = GL_FALSE, write_depth = GL_FALSE;
@@ -1185,19 +1180,19 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   return;
}
 
+   make_passthrough_vertex_shader(st);
+
/*
 * Get vertex/fragment shaders
 */
if (write_depth || write_stencil) {
   driver_fp = get_drawpix_z_stencil_program(st, write_depth,
 write_stencil);
-  driver_vp = make_passthrough_vertex_shader(st, GL_TRUE);
}
else {
   fpv = get_color_fp_variant(st);
 
   driver_fp = fpv->driver_shader;
-  driver_vp = make_passthrough_vertex_shader(st, GL_FALSE);
 
   if (ctx->Pixel.MapColorFlag) {
  pipe_sampler_view_reference([1],
@@ -1246,7 +1241,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   ctx->Pixel.ZoomX, ctx->Pixel.ZoomY,
   sv,
   num_sampler_view,
-  driver_vp,
+  st->drawpix.vert_shader,
   driver_fp, fpv,
   ctx->Current.RasterColor,
   GL_FALSE, write_depth, write_stencil);
@@ -1506,7 +1501,7 @@ st_CopyPixels(struct gl_context *ctx, GLint srcx, GLint 
srcy,
struct pipe_context *pipe = st->pipe;
struct pipe_screen *screen = pipe->screen;
struct st_renderbuffer *rbRead;
-   void *driver_vp, *driver_fp;
+   void *driver_fp;
struct pipe_resource *pt;
struct pipe_sampler_view *sv[2] = { NULL };
struct st_fp_variant *fpv = NULL;
@@ -1547,6 +1542,7 @@ st_CopyPixels(struct 

[Mesa-dev] [PATCH 4/6] st/mesa: Combine the DrawPixels and Bitmap passthrough VS programs.

[Kenneth Graunke]

They're now identical, so we can just compile it once.
---
 src/mesa/state_tracker/st_cb_bitmap.c | 27 +--
 src/mesa/state_tracker/st_cb_drawpixels.c | 20 -
 src/mesa/state_tracker/st_cb_drawpixels.h |  3 +++
 src/mesa/state_tracker/st_context.h   |  5 +++--
 4 files changed, 22 insertions(+), 33 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_bitmap.c 
b/src/mesa/state_tracker/st_cb_bitmap.c
index a73d6c7e062..7ef0d7ea5c6 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -46,6 +46,7 @@
 #include "st_draw.h"
 #include "st_program.h"
 #include "st_cb_bitmap.h"
+#include "st_cb_drawpixels.h"
 #include "st_sampler_view.h"
 #include "st_texture.h"
 
@@ -53,7 +54,6 @@
 #include "pipe/p_defines.h"
 #include "pipe/p_shader_tokens.h"
 #include "util/u_inlines.h"
-#include "util/u_simple_shaders.h"
 #include "util/u_upload_mgr.h"
 #include "program/prog_instruction.h"
 #include "cso_cache/cso_context.h"
@@ -214,7 +214,7 @@ setup_render_state(struct gl_context *ctx,
cso_set_fragment_shader_handle(cso, fpv->driver_shader);
 
/* vertex shader state: position + texcoord pass-through */
-   cso_set_vertex_shader_handle(cso, st->bitmap.vs);
+   cso_set_vertex_shader_handle(cso, st->passthrough_vs);
 
/* disable other shaders */
cso_set_tessctrl_shader_handle(cso, NULL);
@@ -538,7 +538,7 @@ init_bitmap_state(struct st_context *st)
struct pipe_screen *screen = pipe->screen;
 
/* This function should only be called once */
-   assert(st->bitmap.vs == NULL);
+   assert(!st->bitmap.tex_format);
 
assert(st->internal_target == PIPE_TEXTURE_2D ||
   st->internal_target == PIPE_TEXTURE_RECT);
@@ -585,17 +585,7 @@ init_bitmap_state(struct st_context *st)
}
 
/* Create the vertex shader */
-   {
-  const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
-  TGSI_SEMANTIC_COLOR,
-st->needs_texcoord_semantic ? TGSI_SEMANTIC_TEXCOORD :
-  TGSI_SEMANTIC_GENERIC };
-  const uint semantic_indexes[] = { 0, 0, 0 };
-  st->bitmap.vs = util_make_vertex_passthrough_shader(st->pipe, 3,
-  semantic_names,
-  semantic_indexes,
-  FALSE);
-   }
+   st_make_passthrough_vertex_shader(st);
 
reset_cache(st);
 }
@@ -617,7 +607,7 @@ st_Bitmap(struct gl_context *ctx, GLint x, GLint y,
 
st_invalidate_readpix_cache(st);
 
-   if (!st->bitmap.vs) {
+   if (!st->bitmap.tex_format) {
   init_bitmap_state(st);
}
 
@@ -677,7 +667,7 @@ st_DrawAtlasBitmaps(struct gl_context *ctx,
struct pipe_vertex_buffer vb = {0};
unsigned i;
 
-   if (!st->bitmap.vs) {
+   if (!st->bitmap.tex_format) {
   init_bitmap_state(st);
}
 
@@ -807,11 +797,6 @@ st_destroy_bitmap(struct st_context *st)
struct pipe_context *pipe = st->pipe;
struct st_bitmap_cache *cache = >bitmap.cache;
 
-   if (st->bitmap.vs) {
-  cso_delete_vertex_shader(st->cso_context, st->bitmap.vs);
-  st->bitmap.vs = NULL;
-   }
-
if (cache->trans && cache->buffer) {
   pipe_transfer_unmap(pipe, cache->trans);
}
diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index 120b5c48339..672b665310b 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -194,10 +194,10 @@ get_drawpix_z_stencil_program(struct st_context *st,
  * Create a simple vertex shader that just passes through the
  * vertex position, texcoord, and color.
  */
-static void
-make_passthrough_vertex_shader(struct st_context *st)
+void
+st_make_passthrough_vertex_shader(struct st_context *st)
 {
-   if (st->drawpix.vert_shader)
+   if (st->passthrough_vs)
   return;
 
const uint semantic_names[] = { TGSI_SEMANTIC_POSITION,
@@ -206,7 +206,7 @@ make_passthrough_vertex_shader(struct st_context *st)
TGSI_SEMANTIC_GENERIC };
const uint semantic_indexes[] = { 0, 0, 0 };
 
-   st->drawpix.vert_shader =
+   st->passthrough_vs =
   util_make_vertex_passthrough_shader(st->pipe, 3, semantic_names,
   semantic_indexes, false);
 }
@@ -1164,7 +1164,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   return;
}
 
-   make_passthrough_vertex_shader(st);
+   st_make_passthrough_vertex_shader(st);
 
/*
 * Get vertex/fragment shaders
@@ -1225,7 +1225,7 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   ctx->Pixel.ZoomX, ctx->Pixel.ZoomY,
   sv,
   num_sampler_view,
-  st->drawpix.vert_shader,
+  st->passthrough_vs,
   driver_fp, fpv,
   

[Mesa-dev] [PATCH 1/6] st/mesa: Drop dead 'passthrough_fs' field.

[Kenneth Graunke]

Dead since 2015 (commit 5142564734bd68f165b02e29e384ebbcf91cce38).
---
 src/mesa/state_tracker/st_context.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_context.h 
b/src/mesa/state_tracker/st_context.h
index 95133c7020f..78e962dec00 100644
--- a/src/mesa/state_tracker/st_context.h
+++ b/src/mesa/state_tracker/st_context.h
@@ -278,8 +278,6 @@ struct st_context
/** for drawing with st_util_vertex */
struct pipe_vertex_element util_velems[3];
 
-   void *passthrough_fs;  /**< simple pass-through frag shader */
-
enum pipe_texture_target internal_target;
 
struct cso_context *cso_context;
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH v3] anv: support VkExternalFormatANDROID in vkCreateSamplerYcbcrConversion

[Lionel Landwerlin]

On 14/12/2018 12:05, Tapani Pälli wrote:

+
+   /* The Vulkan 1.1.95 spec says "When creating an external format conversion,
+* the value of components if ignored."
+*/
+   if (ext_format) {
+  conversion->mapping[0] = pCreateInfo->components.r;
+  conversion->mapping[1] = pCreateInfo->components.g;
+  conversion->mapping[2] = pCreateInfo->components.b;
+  conversion->mapping[3] = pCreateInfo->components.a;
+   }
+


if (!ext_format)

With that fixed:

Reviewed-by: Lionel Landwerlin 

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

Re: [Mesa-dev] [PATCH] i965: Don't override subslice count to 4 on Gen11.

[Anuj Phogat]

On Fri, Dec 14, 2018 at 3:59 PM Kenneth Graunke  wrote:
>
> Gen9-10 have fewer than 4 subslices per slice, so they need this to be
> rounded up.  Gen11 isn't documented as needing this hack, and it can
> also have more than 4 subslices, so the hack actually can break things.
> ---
>  src/mesa/drivers/dri/i965/brw_program.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> I have not tested this patch.  I made the equivalent change to iris and
> it fixed some geometry shader tests that were spilling (but don't spill
> on i965 - that's a compiler quality regression I have yet to fix)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_program.c 
> b/src/mesa/drivers/dri/i965/brw_program.c
> index 96247f32f0f..730d6dc0d5a 100644
> --- a/src/mesa/drivers/dri/i965/brw_program.c
> +++ b/src/mesa/drivers/dri/i965/brw_program.c
> @@ -407,7 +407,7 @@ brw_alloc_stage_scratch(struct brw_context *brw,
> * and we wish to view that there are 4 subslices per slice
> * instead of the actual number of subslices per slice.
> */
> -  if (devinfo->gen >= 9)
> +  if (devinfo->gen >= 9 && devinfo->gen < 11)
>   subslices = 4 * brw->screen->devinfo.num_slices;
>
>unsigned scratch_ids_per_subslice;
> --
> 2.19.1
>

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

Re: [Mesa-dev] [PATCH v5] anv/android: add GetAndroidHardwareBufferPropertiesANDROID

[Lionel Landwerlin]

On 14/12/2018 11:53, Tapani Pälli wrote:

+   if (desc.usage & AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER)
+  tiling = VK_IMAGE_TILING_LINEAR;
+
+   p->formatFeatures =
+  anv_get_image_format_features(>info, p->format,
+anv_format, VK_IMAGE_TILING_OPTIMAL);
+


I think you want to give tiling as a parameter, with that fixed :


Reviewed-by: Lionel Landwerlin 

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

Re: [Mesa-dev] last call for autotools

[Eric Anholt]

Eero Tamminen  writes:

> Hi,
>
> On 17.12.2018 8.08, Marek Olšák wrote:
> [...]
>> I think one of the serious usability issues is that environment 
>> variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not 
>> saved by meson for future reconfigures.
>
> I don't know what Meson is supposed to do, but to me that would be
> a bug in a build tool.
>
> Re-configure is supposed to adapt SW to the changes in the build
> environment, and environment variables are part of that (along with
> command line options and SW installed to to the system).  Build
> configure tool deciding to "remember" some of those things instead
> of checking the new situation, seems like a great opportunity for
> confusion.

A user-triggered reconfigure, sure.  Recapture env vars then.  But "git
pull; ninja -C build" losing track of the configuration state is broken.
We don't have to specify all of your meson -Doption=state configuration
on every build, why should you need to specify your PKG_CONFIG_PATH
configure options on every build?


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

Re: [Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Andres Gomez]

On Mon, 2018-12-17 at 16:43 +, Emil Velikov wrote:
> Currently our is_sha_nomination does:
>  - folds any whitespace, attempting to extract sha-like information
>  - checks that at least one of the shas has landed
> 
> Split it in two and do sha-like validation first.
> 
> This way, commits with mesa-stable and sha nominations will feature the
> fixes/revert/etc instead of stable (a) or will be omitted if not
> applicable for the respective branch (b).
> 
> Misc examples from 18.3
> 
> (a)
> -[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct rendering
> +[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct rendering
> 
> (b)
> -[   stable ] 9a7b3199037 anv/query: flush render target before copying 
> results
> 
> CC: Andres Gomez 
> CC: Juan A. Suarez 
> CC: Dylan Baker 
> CC: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Emil Velikov 
> ---
> Juan I've noticed that you've been experiencing the above annoyance for
> a while. Having less false-positives should ease things up a bit :-)
> ---
>  bin/get-pick-list.sh | 46 +---
>  1 file changed, 30 insertions(+), 16 deletions(-)
> 
> diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
> index 9f9cbc44026..08a783f35a8 100755
> --- a/bin/get-pick-list.sh
> +++ b/bin/get-pick-list.sh
> @@ -21,32 +21,36 @@ is_typod_nomination()
>   git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
>  }
>  
> +fixes=
> +

Splitting in 2 functions for which we need now a global variable is not
very nice. Anyway, let's not make this more complicated than needed.

>  # Helper to handle various mistypos of the fixes tag.
>  # The tag string itself is passed as argument and normalised within.
> +#
> +# Resulting string in the global variable "fixes" and contains entries
> +# in the form "fixes:$sha"
>  is_sha_nomination()
>  {
>   fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
>   sed -e 's/'"$2"'/\nfixes:/Ig' | \
>   grep -Eo 'fixes:[a-f0-9]{8,40}'`
>  
> - fixes_count=`echo "$fixes" | wc -l`
> + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`

Why is the extra "grep" needed here?

>   if test $fixes_count -eq 0; then
> - return 0
> + return 1

Ugh! Right.

>   fi
> + return 0
> +}
> +
> +# Checks if at least one of offending commits, listed in the global
> +# "fixes", is in branch.
> +sha_in_range()
> +{
> + fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`

Ditto.

>   while test $fixes_count -gt 0; do
>   # Treat only the current line
>   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut -d : 
> -f 2`
>   fixes_count=$(($fixes_count-1))
>  
> - # Bail out if we cannot find suitable id.
> - # Any specific validation the $id is valid and not some junk, is
> - # implied with the follow up code
> - if test "x$id" = x; then
> - continue
> - fi
> -
> - #Check if the offending commit is in branch.
> -

Was this never needed in the first place? Feels right to remove it
since $fixes should have some content by now, but I wonder how this got
here in the first place.

>   # Be that cherry-picked ...
>   # ... or landed before the branchpoint.
>   if grep -q ^$id already_picked ||
> @@ -103,20 +107,30 @@ do
>   continue
>   fi
>  
> - if is_stable_nomination "$sha"; then
> - tag=stable
> - elif is_typod_nomination "$sha"; then
> - tag=typod
> - elif is_fixes_nomination "$sha"; then
> + if is_fixes_nomination "$sha"; then
>   tag=fixes
>   elif is_brokenby_nomination "$sha"; then
>   tag=brokenby
>   elif is_revert_nomination "$sha"; then
>   tag=revert
> + elif is_stable_nomination "$sha"; then
> + tag=stable
> + elif is_typod_nomination "$sha"; then
> + tag=typod
>   else
>   continue
>   fi
>  
> + case "$tag" in
> + fixes | brokenby | revert )
> + if ! sha_in_range; then
> + continue
> + fi
> + ;;
> + * )
> + ;;
> + esac
> +
>   printf "[ %8s ] " "$tag"
>   git --no-pager show --summary --oneline $sha
>  done

I'm not sure we are gaining something with the splitting.

Maybe I'm not understanding correctly the patch but it seems to me that
every successful "is_sha_nomination" is followed by a "sha_in_range"
call. Hence, we are only trading splitting into 2 functions by having a
global variable (!)

Additionally, in the second patch of the series we are adding a warning
that, in case of having a single function, could be placed in the same
while loop, instead of having now 2 loops (?)

-- 
Br,

Andres
___
mesa-dev mailing list

Re: [Mesa-dev] Suggestions for improving meson-based builds

[Dylan Baker]

Quoting Ilia Mirkin (2018-12-16 11:48:52)
> Hello all,
> 
> There has been some discussion of late about dropping autotools or
> making it a second-class citizen. I firmly believe such discussions
> are premature.
> 
> I've had a chance to try meson recently. First off, I'd like to
> commend the meson team (both the core project as well as the mesa
> developers who have been pushing it) for being responsive to
> build-prevention concerns (e.g. "the build doesn't work"). It does now
> build successfully for me, which it did not when these efforts were
> starting out.
> 
> In those tests, however, I noticed some shortcomings, which I believe
> require being addressed before meson can be used in a major project
> such as mesa. I'd like to outline some bits that any autotools
> replacement needs to have (be it meson or anything else), in order to
> be viable. This is all obviously on top of "produce correct build
> results", which I take as a given. These are mostly in order that they
> happened to occur to me rather than  prioritized by importance.
> 
> 1. Build creation command recovery. With autotools, "head config.log"
> will tell you how you configured it. This is important when things get
> screwed up, and so has to be available in plain text somewhere. There
> are a variety of other occasions where this can be useful -- debugging
> someone else's build, creating a second build for yourself with a few
> options changed, etc.

There is (as of 0.49.0) a file called $builddir/meson-private/cmd_line.txt, it's
an ini file, but it does contain each option in a key value format. After dave
asked for a way to get the command line back, we've discussed replacing this
with having meson generate a native file that could be read in using the normal
--native-file option (which would make it super trivial to reuse)

> 2. Summary at the end. This is not strictly an autotools-specific
> issue, but rather how mesa has used it. That summary at the end is
> very useful to make sure you (or someone you're helping) hasn't
> screwed something up.

I personally really don't like this, I never want to read it, but a lot of
people have asked for it. Gstreamer apparently wants this as well, and there's
an opened issue I'll assign to myself:

https://github.com/mesonbuild/meson/issues/757

> 3. Have a configure helper which makes it look like autotools.
> Everyone knows how to use autotools, in part because it's so very easy
> to use. No one wants to figure out how to operate some random
> project's build system (and while meson may have world-dominating
> aspirations, it's certainly not there yet). This is one of the reasons
> I avoid doing anything of substance with cmake-based projects. A few
> bits which ought to work: "./configure --help", "./configure
> --with-gallium-drivers=..." and so on, similar to the existing logic,
> "./configure CFLAGS=-O0" and so on. Those environment variables need
> to be baked into the build, and it should be able to bake in things
> like PKG_CONFIG_PATH in a way that affects meson's operations, not
> just the build-time bits. This should default to a particular build
> directory (perhaps creatively called "build"), with some way to
> specify an alternate (e.g. add a --builddir=...). I think it's fine to
> have a dummy Makefile generated in this case which just says "run
> ninja" without actually running it.
> 
> 4. No matter what happens to the system, re-running "ninja" or
> "configure" should not cause failures. This can't always be prevented
> (bugs happen, I get it), but you get like one screwup every 5 years --
> it should be avoided as much as possible. If the solution is that the
> tool re-runs itself using the old configuration, that's fine -- but it
> can't just die saying "oh no, you're screwed", which it currently does
> when updating meson on the system.

As of 0.49 this should be *much* better. We now officially support upgrading to
the next version, meson will simply wipe the directory and start over with the
same options. It's certainly not optimal, especially if you're not using ccache,
but it will update.

> 5. Cross-files are a clever way of solving the issue by offloading it
> as "not-my-problem". And the configuration for cross-compiling project
> A is going to be identical to project B. I understand all this.
> However in declaring it as "not-my-problem", meson makes it the user's
> problem. These files are currently not shipped as part of
> cross-compiling setups, and asking each user to figure out how to set
> them up is excessive -- cross builds are complex enough, and this is
> yet-another thing in the path to success. The configure wrapper should
> be able to take the standard parameters (--build, --host, etc) and
> have it work (e.g. by generating a cross-file on the fly).
> 
> Some of you reading who have made it this far (congratulations!) might
> be thinking that all this "make meson look like autoconf" is just
> silliness from someone who doesn't want to adapt to 

Re: [Mesa-dev] [PATCH mesa] drop autotools

[Juan A. Suarez Romero]

On Mon, 2018-12-03 at 10:21 +, Eric Engestrom wrote:
> Cc: Emil Velikov 
> Cc: Andres Gomez 
> Cc: Juan A. Suarez Romero 
> Cc: Dylan Baker 
> Signed-off-by: Eric Engestrom 
> ---
> This patch depends on the releasing procedure in docs/releasing.html to
> be updated to not rely on autotools anymore.
> 
> I think our release managers (cc'ed) should work together and figure out
> the procedure they want to go by; only once that's done can we delete
> these 200+ files and 14k+ lines :)


I'll let others to talk. But my preference would be to land this for next 19.0
branchpoint, just a couple of days before the branchpoint, so 19.0.x releases
get rid of autotools.

This way we have time to fix any remaining issue, and make like easier for those
in charge of 18.3.x releases, which I think should support autotools until the
end of its life.


J.A.

> ---
>  .gitignore|   54 -
>  Makefile.am   |   92 -
>  REVIEWERS |9 -
>  autogen.sh|   14 -
>  bin/.gitignore|9 -
>  configure.ac  | 3375 -
>  docs/autoconf.html|  264 --
>  docs/contents.html|1 -
>  docs/download.html|1 -
>  docs/install.html |   21 +-
>  docs/llvmpipe.html|8 -
>  docs/mangling.html|2 +-
>  docs/meson.html   |2 +-
>  docs/relnotes/19.0.0.html |7 +-
>  doxygen/.gitignore|   19 -
>  m4/.gitignore |5 -
>  m4/ax_check_compile_flag.m4   |   79 -
>  m4/ax_check_gnu_make.m4   |   78 -
>  m4/ax_check_python_mako_module.m4 |   64 -
>  m4/ax_gcc_builtin.m4  |  168 -
>  m4/ax_gcc_func_attribute.m4   |  230 --
>  m4/ax_prog_bison.m4   |   71 -
>  m4/ax_prog_flex.m4|   63 -
>  m4/ax_pthread.m4  |  309 --
>  src/Makefile.am   |  138 -
>  src/amd/Makefile.addrlib.am   |   40 -
>  src/amd/Makefile.am   |   35 -
>  src/amd/Makefile.common.am|   71 -
>  src/amd/common/.gitignore |1 -
>  src/amd/vulkan/.gitignore |9 -
>  src/amd/vulkan/Makefile.am|  200 -
>  src/broadcom/.gitignore   |3 -
>  src/broadcom/Makefile.am  |   65 -
>  src/broadcom/Makefile.cle.am  |6 -
>  src/broadcom/Makefile.genxml.am   |   54 -
>  src/broadcom/Makefile.v3d.am  |   32 -
>  src/broadcom/qpu/tests/.gitignore |1 -
>  src/compiler/.gitignore   |6 -
>  src/compiler/Makefile.am  |   77 -
>  src/compiler/Makefile.glsl.am |  264 --
>  src/compiler/Makefile.nir.am  |  116 -
>  src/compiler/Makefile.spirv.am|   59 -
>  src/compiler/glsl/.gitignore  |   12 -
>  src/compiler/glsl/glcpp/.gitignore|6 -
>  src/compiler/glsl/glcpp/tests/.gitignore  |4 -
>  src/compiler/glsl/tests/.gitignore|6 -
>  src/compiler/glsl/tests/warnings/.gitignore   |1 -
>  src/compiler/nir/.gitignore   |7 -
>  src/compiler/nir/tests/.gitignore |1 -
>  src/compiler/spirv/.gitignore |2 -
>  src/egl/.gitignore|2 -
>  src/egl/Makefile.am   |  235 --
>  src/egl/drivers/dri2/.gitignore   |2 -
>  src/egl/wayland/wayland-drm/.gitignore|3 -
>  src/egl/wayland/wayland-drm/Makefile.am   |   37 -
>  src/freedreno/Makefile.am |   76 -
>  src/gallium/Automake.inc  |   90 -
>  src/gallium/Makefile.am   |  211 --
>  src/gallium/auxiliary/Makefile.am |  134 -
>  src/gallium/auxiliary/indices/.gitignore  |2 -
>  src/gallium/auxiliary/pipe-loader/Makefile.am |   51 -
>  src/gallium/auxiliary/util/.gitignore |2 -
>  src/gallium/drivers/etnaviv/.gitignore|1 -
>  src/gallium/drivers/etnaviv/Automake.inc  |   11 -
>  src/gallium/drivers/etnaviv/Makefile.am   |   46 -
>  src/gallium/drivers/freedreno/.gitignore  |2 -
>  src/gallium/drivers/freedreno/Automake.inc|   13 -
>  src/gallium/drivers/freedreno/Makefile.am |   23 -
>  src/gallium/drivers/i915/Automake.inc |   11 -
>  src/gallium/drivers/i915/Makefile.am  |   33 -
>  src/gallium/drivers/imx/Automake.inc 

[Mesa-dev] [Bug 108946] High memory usage in Black Mesa

[bugzilla-daemon]

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

--- Comment #11 from void...@gmail.com ---
On December 17, we pushed new beta into public-beta branch. That's major ToGL
layer rework, which should address memory issues with open-source Mesa drivers.
The actual issue is much deeper than one might thought, but suggestions from
some advanced forum users been helpful indeed.

>From internal testing on development branch where we took some of the biggest
uncut shader we have, following results were achieved on NVIDIA hardware on
Windows with OpenGL as main renderer:
* Main Menu (before) - using compiled binaries as intermediate data for shaders
that goes into actual programs: 1.5 GiB of RAM used
* Main Menu (after) - using text representation of GLSL as intermediate data
for shaders that would go into actual programs on request: 450 MiB of RAM used
* Main Menu (after, reworked) - using compressed text representation of GLSL as
intermediate data for shaders that would go into actual programs on request:
360 MiB of RAM used

After patch has been applied on current public-beta branch on Steam with NVIDIA
hardware on Linux we got around 200-300 MiB less of RAM usage in game. If that
was actually it, as was suggested on Mesa's bug tracker, AMD users should
experience similar results (even more prominent ones) which should address out
of memory issue.

P.S. I may add additional information later, would be great if any of you could
try new public-beta out.

-- 
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] last call for autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-12-17 07:48:38)
> Hey Dylan,
> Dylan Baker wrote on 11.12.18 00:10:
> > Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> > final call for autotools. My patch is so massive that it's a huge pain to 
> > send
> > to the list, the latest versions is here:
> > https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools
> 
> I've switched to building with meson now and everything seems to work for my
> environment, including the usage of a particular LLVM version.
> 
> I've noticed, that Debian carries the changes from
>  as local patches. It would
> probably be good, if those patches land before autotools support is nuked.
> 
> Also: meson complains that deprecated features are used:
>  - DEPRECATION: Project targetting '>= 0.45' but tried to use feature 
> deprecated
> since '0.48.0': python3 module
>  - DEPRECATION: build_always is deprecated. Combine build_by_default and
> build_always_stale instead.
> 
> Can these be fixed before making meson mandatory? Or are they completely
> harmless and won't break builds?

These are both cases of overly aggressive error messages. build_aways was
deprecated in 0.47 which is newer than 0.45 (which is our current oldest
supported version of meson). There is an issue filed against meson about not
printing the deprecated message in these cases, it looks like there's just a
couple of issues to iron out:

https://github.com/mesonbuild/meson/pull/4362

> 
> This leaves me with a feature request: the autotools build generated a
> configuration summary at the end, which is helpful in checking if changes to 
> the
> configuration in my debian/rules file are actually propagated to the build or 
> if
> something went wrong. Could the meson build provide such a summary as well?
> 
> Cheers,
> Kai
> 


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

Re: [Mesa-dev] last call for autotools

[Dylan Baker]

Quoting Gert Wollny (2018-12-16 03:57:48)
> Am Freitag, den 14.12.2018, 13:11 +0100 schrieb Gert Wollny:
> > Am Freitag, den 14.12.2018, 01:19 -0500 schrieb Ilia Mirkin:
> > > I have to say that the user experience for autotools is WAY better
> > > than for meson. As a concrete example, I had a meson build. Then I
> > > updated meson (0.48.1 to 0.48.2). Now ninja -C foo doesn't work.
> > > meson
> > > --reconfigure (which presumably is what ninja would end up running)
> > > doesn't work. http://paste.debian.net/hidden/cf777f3e/
> > 
> > I think that was fixed with this PR (although I so far I didn't try
> > to use this new feature, so I don't know how well it works):
> >   https://github.com/mesonbuild/meson/pull/4356
> > The error message should probably be updated accordingly. 
> 
> Today I updated to 0.49 (from 0.47) and there it didn't work (the file
> meson-private/cmd_line.txt was missing), so my guess this is only
> availabe for builds that were already created with 0.49.

Yes, the build has to be configured with 0.49 to have a cmd_line.txt

> 
> However, there it doesn't work for me: 
> https://bugs.freedesktop.org/show_bug.cgi?id=109071

I'll look at that, it doesn't look good

Dylan

> 
> Best,
> Gert
> 


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

[Mesa-dev] [Bug 109071] meson --wipe results in Exception: "FileNotFoundError: [Errno 2] No such file or directory"

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |baker.dyla...@gmail.com
   |org |

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

Re: [Mesa-dev] [PATCH 0/5] Fixueps for ppc64 and gnu hurd

[Dylan Baker]

Quoting Timo Aaltonen (2018-12-05 03:56:54)
> On 4.12.2018 23.52, Dylan Baker wrote:
> > This little series is aimed at fixing problems reported by fedora and debian
> > when using meson, there's a couple of patches in here for fixing ppc64 
> > detection
> > (tested without llvm), and a couple for gnu hurd (not tested).
> > 
> > Dylan Baker (5):
> >   meson: remove duplicate definition
> >   meson: Fix ppc64 little endian detection
> >   meson: Override C++ standard to gnu++11 when building with altivec on
> > ppc64le
> >   meson: Add support for gnu hurd
> >   meson: Add toggle for glx-direct
> > 
> >  meson.build   | 33 ---
> >  meson_options.txt |  6 
> >  src/gallium/state_trackers/clover/meson.build |  3 ++
> >  3 files changed, 31 insertions(+), 11 deletions(-)
> > 
> 
> Thanks, I'll give these a try soon.
> 
> -- 
> t

Ping


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

[Mesa-dev] [Bug 109062] meson incorrectly handles/reports libdrm_$foo

[bugzilla-daemon]

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

--- Comment #4 from Dylan Baker  ---
That's going to increase the number of calls to pkg-config considerably. If we
take this approach please check the changes in the time it takes to run an
initial meson; I have a feeling it could be bad.

The other option I guess would be to just pass all of the versions at once,
meson does support `version : ['>= 1.0', '>= 1.3']`

-- 
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] last call for autotools

[Jason Ekstrand]

On Mon, Dec 17, 2018 at 8:54 AM Eero Tamminen 
wrote:

> Hi,
>
> On 17.12.2018 8.08, Marek Olšák wrote:
> [...]
> > I think one of the serious usability issues is that environment
> > variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not
> > saved by meson for future reconfigures.
>
> I don't know what Meson is supposed to do, but to me that would be
> a bug in a build tool.
>
> Re-configure is supposed to adapt SW to the changes in the build
> environment, and environment variables are part of that (along with
> command line options and SW installed to to the system).  Build
> configure tool deciding to "remember" some of those things instead
> of checking the new situation, seems like a great opportunity for
> confusion.
>

I think both ways of looking at this particular issue are at least
partially valid and this is exactly why meson recommends you don't set
those options via environment variables.  Even with autotools provides a
mechanism to set those things as part of the command (by putting CFLAGS= as
a parameter) rather than the environment.  If you pay attention to the
command in config.log (and the one you use for reconfigure), it moves them
to the explicit argument format.  I think the real answer here is to tell
people to stop using CFLAGS in the environment.

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

Re: [Mesa-dev] [PATCH] anv: Bump the patch version to 96

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 17/12/2018 16:49, Jason Ekstrand wrote:

---
  src/intel/vulkan/anv_extensions.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index b6269d0047a..a0bf4127002 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -47,7 +47,7 @@ class ApiVersion:
  self.version = version
  self.enable = _bool_to_c_expr(enable)
  
-API_PATCH_VERSION = 90

+API_PATCH_VERSION = 96
  
  # Supported API versions.  Each one is the maximum patch version for the given

  # version.  Version come in increasing order and each version is available if



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

[Mesa-dev] [PATCH] anv: Bump the patch version to 96

[Jason Ekstrand]

---
 src/intel/vulkan/anv_extensions.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index b6269d0047a..a0bf4127002 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -47,7 +47,7 @@ class ApiVersion:
 self.version = version
 self.enable = _bool_to_c_expr(enable)
 
-API_PATCH_VERSION = 90
+API_PATCH_VERSION = 96
 
 # Supported API versions.  Each one is the maximum patch version for the given
 # version.  Version come in increasing order and each version is available if
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/2] bin/get-pick-list.sh: rework handing of sha nominations

[Emil Velikov]

Currently our is_sha_nomination does:
 - folds any whitespace, attempting to extract sha-like information
 - checks that at least one of the shas has landed

Split it in two and do sha-like validation first.

This way, commits with mesa-stable and sha nominations will feature the
fixes/revert/etc instead of stable (a) or will be omitted if not
applicable for the respective branch (b).

Misc examples from 18.3

(a)
-[   stable ] 5bc509363b6 glx: make xf86vidmode mandatory for direct rendering
+[fixes ] 5bc509363b6 glx: make xf86vidmode mandatory for direct rendering

(b)
-[   stable ] 9a7b3199037 anv/query: flush render target before copying results

CC: Andres Gomez 
CC: Juan A. Suarez 
CC: Dylan Baker 
CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
Juan I've noticed that you've been experiencing the above annoyance for
a while. Having less false-positives should ease things up a bit :-)
---
 bin/get-pick-list.sh | 46 +---
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
index 9f9cbc44026..08a783f35a8 100755
--- a/bin/get-pick-list.sh
+++ b/bin/get-pick-list.sh
@@ -21,32 +21,36 @@ is_typod_nomination()
git show --summary "$1" | grep -q -i -o "CC:.*mesa-dev"
 }
 
+fixes=
+
 # Helper to handle various mistypos of the fixes tag.
 # The tag string itself is passed as argument and normalised within.
+#
+# Resulting string in the global variable "fixes" and contains entries
+# in the form "fixes:$sha"
 is_sha_nomination()
 {
fixes=`git show --pretty=medium -s $1 | tr -d "\n" | \
sed -e 's/'"$2"'/\nfixes:/Ig' | \
grep -Eo 'fixes:[a-f0-9]{8,40}'`
 
-   fixes_count=`echo "$fixes" | wc -l`
+   fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
if test $fixes_count -eq 0; then
-   return 0
+   return 1
fi
+   return 0
+}
+
+# Checks if at least one of offending commits, listed in the global
+# "fixes", is in branch.
+sha_in_range()
+{
+   fixes_count=`echo "$fixes" | grep "fixes:" | wc -l`
while test $fixes_count -gt 0; do
# Treat only the current line
id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut -d : 
-f 2`
fixes_count=$(($fixes_count-1))
 
-   # Bail out if we cannot find suitable id.
-   # Any specific validation the $id is valid and not some junk, is
-   # implied with the follow up code
-   if test "x$id" = x; then
-   continue
-   fi
-
-   #Check if the offending commit is in branch.
-
# Be that cherry-picked ...
# ... or landed before the branchpoint.
if grep -q ^$id already_picked ||
@@ -103,20 +107,30 @@ do
continue
fi
 
-   if is_stable_nomination "$sha"; then
-   tag=stable
-   elif is_typod_nomination "$sha"; then
-   tag=typod
-   elif is_fixes_nomination "$sha"; then
+   if is_fixes_nomination "$sha"; then
tag=fixes
elif is_brokenby_nomination "$sha"; then
tag=brokenby
elif is_revert_nomination "$sha"; then
tag=revert
+   elif is_stable_nomination "$sha"; then
+   tag=stable
+   elif is_typod_nomination "$sha"; then
+   tag=typod
else
continue
fi
 
+   case "$tag" in
+   fixes | brokenby | revert )
+   if ! sha_in_range; then
+   continue
+   fi
+   ;;
+   * )
+   ;;
+   esac
+
printf "[ %8s ] " "$tag"
git --no-pager show --summary --oneline $sha
 done
-- 
2.19.2

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

[Mesa-dev] [PATCH 2/2] bin/get-pick-list.sh: warn when commit lists invalid sha

[Emil Velikov]

From: Emil Velikov 

We had cases where people would list old/invalid sha in the commit.
Add a trivial checker to catch those and throw a warning.

CC: Andres Gomez 
CC: Juan A. Suarez 
CC: Dylan Baker 
CC: mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov 
---
 bin/get-pick-list.sh | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/bin/get-pick-list.sh b/bin/get-pick-list.sh
index 08a783f35a8..79b7a295ea6 100755
--- a/bin/get-pick-list.sh
+++ b/bin/get-pick-list.sh
@@ -38,6 +38,17 @@ is_sha_nomination()
if test $fixes_count -eq 0; then
return 1
fi
+
+   # Throw a warning for each invalid sha
+   while test $fixes_count -gt 0; do
+   # Treat only the current line
+   id=`echo "$fixes" | tail -n $fixes_count | head -n 1 | cut -d : 
-f 2`
+   fixes_count=$(($fixes_count-1))
+   if ! git show $id &>/dev/null; then
+   echo WARNING: Commit $1 lists invalid sha $id
+   fi
+   done
+
return 0
 }
 
-- 
2.19.2

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

Re: [Mesa-dev] [PATCH 1/2] vulkan: Update the XML and headers to 1.1.96

[Jason Ekstrand]

Thanks!  Both pushed.

On Mon, Dec 17, 2018 at 9:45 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Reviewed-by: Lionel Landwerlin 
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nir: create 32-bit bcsel for 32-bit conditions

[Rhys Perry]

Signed-off-by: Rhys Perry 
---
 src/compiler/nir/nir_opt_peephole_select.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_peephole_select.c 
b/src/compiler/nir/nir_opt_peephole_select.c
index ad9d0abec0..241627ed99 100644
--- a/src/compiler/nir/nir_opt_peephole_select.c
+++ b/src/compiler/nir/nir_opt_peephole_select.c
@@ -205,7 +205,9 @@ nir_opt_peephole_select_block(nir_block *block, nir_shader 
*shader,
  break;
 
   nir_phi_instr *phi = nir_instr_as_phi(instr);
-  nir_alu_instr *sel = nir_alu_instr_create(shader, nir_op_bcsel);
+  nir_op sel_op = nir_src_bit_size(if_stmt->condition) == 1 ?
+  nir_op_bcsel : nir_op_b32csel;
+  nir_alu_instr *sel = nir_alu_instr_create(shader, sel_op);
   nir_src_copy(>src[0].src, _stmt->condition, sel);
   /* Splat the condition to all channels */
   memset(sel->src[0].swizzle, 0, sizeof sel->src[0].swizzle);
-- 
2.19.2

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

Re: [Mesa-dev] last call for autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 11.12.18 00:10:
> Meson 0.49.0 has been out for a couple of days now, and I'd like to make the
> final call for autotools. My patch is so massive that it's a huge pain to send
> to the list, the latest versions is here:
> https://gitlab.freedesktop.org/dbaker/mesa/commits/delete-autotools

I've switched to building with meson now and everything seems to work for my
environment, including the usage of a particular LLVM version.

I've noticed, that Debian carries the changes from
 as local patches. It would
probably be good, if those patches land before autotools support is nuked.

Also: meson complains that deprecated features are used:
 - DEPRECATION: Project targetting '>= 0.45' but tried to use feature deprecated
since '0.48.0': python3 module
 - DEPRECATION: build_always is deprecated. Combine build_by_default and
build_always_stale instead.

Can these be fixed before making meson mandatory? Or are they completely
harmless and won't break builds?

This leaves me with a feature request: the autotools build generated a
configuration summary at the end, which is helpful in checking if changes to the
configuration in my debian/rules file are actually propagated to the build or if
something went wrong. Could the meson build provide such a summary as well?

Cheers,
Kai



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

Re: [Mesa-dev] [PATCH 1/2] vulkan: Update the XML and headers to 1.1.96

[Lionel Landwerlin]

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

Re: [Mesa-dev] [PATCH 1/2] vulkan: Update the XML and headers to 1.1.96

[Samuel Iglesias Gonsálvez]

Patch series is,

Reviewed-by: Samuel Iglesias Gonsálvez 

Sam

On 17/12/2018 16:39, Jason Ekstrand wrote:
> ---
>  include/vulkan/vulkan_core.h | 16 
>  src/vulkan/registry/vk.xml   | 22 +++---
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
> index 50064109ef3..72542c72ec8 100644
> --- a/include/vulkan/vulkan_core.h
> +++ b/include/vulkan/vulkan_core.h
> @@ -43,7 +43,7 @@ extern "C" {
>  #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
>  #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
>  // Version of this file
> -#define VK_HEADER_VERSION 95
> +#define VK_HEADER_VERSION 96
>  
>  
>  #define VK_NULL_HANDLE 0
> @@ -8862,16 +8862,16 @@ VKAPI_ATTR void VKAPI_CALL vkGetQueueCheckpointDataNV(
>  #endif
>  
>  #define VK_EXT_pci_bus_info 1
> -#define VK_EXT_PCI_BUS_INFO_SPEC_VERSION  1
> +#define VK_EXT_PCI_BUS_INFO_SPEC_VERSION  2
>  #define VK_EXT_PCI_BUS_INFO_EXTENSION_NAME "VK_EXT_pci_bus_info"
>  
>  typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT {
>  VkStructureTypesType;
>  void*  pNext;
> -uint16_t   pciDomain;
> -uint8_tpciBus;
> -uint8_tpciDevice;
> -uint8_tpciFunction;
> +uint32_t   pciDomain;
> +uint32_t   pciBus;
> +uint32_t   pciDevice;
> +uint32_t   pciFunction;
>  } VkPhysicalDevicePCIBusInfoPropertiesEXT;
>  
>  
> @@ -8917,12 +8917,12 @@ typedef struct 
> VkPhysicalDeviceScalarBlockLayoutFeaturesEXT {
>  
>  
>  #define VK_GOOGLE_hlsl_functionality1 1
> -#define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 0
> +#define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 1
>  #define VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME 
> "VK_GOOGLE_hlsl_functionality1"
>  
>  
>  #define VK_GOOGLE_decorate_string 1
> -#define VK_GOOGLE_DECORATE_STRING_SPEC_VERSION 0
> +#define VK_GOOGLE_DECORATE_STRING_SPEC_VERSION 1
>  #define VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME "VK_GOOGLE_decorate_string"
>  
>  
> diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
> index 2c9b79976bc..d60f41187fe 100644
> --- a/src/vulkan/registry/vk.xml
> +++ b/src/vulkan/registry/vk.xml
> @@ -146,7 +146,7 @@ server.
>  // Vulkan 1.1 version number
>  #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 
> 0)// Patch version should always be set to 0
>  // Version of this file
> -#define VK_HEADER_VERSION 95
> +#define VK_HEADER_VERSION 96
>  
>  
>  #define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
> object;
> @@ -2513,7 +2513,7 @@ server.
>  const void*  
> pNext
>  VkBool32   
> viewportWScalingEnable
>  uint32_t   
> viewportCount
> -const 
> VkViewportWScalingNV*  
> pViewportWScalings
> +const 
> VkViewportWScalingNV*  
> pViewportWScalings
>  
>  
>  VkViewportCoordinateSwizzleNV  
> x
> @@ -2526,7 +2526,7 @@ server.
>  const void*
> pNext
>   optional="true">VkPipelineViewportSwizzleStateCreateFlagsNV
> flags
>  uint32_t   
> viewportCount
> - len="viewportCount">const VkViewportSwizzleNV*  
> pViewportSwizzles
> +const 
> VkViewportSwizzleNV*  pViewportSwizzles
>  
>   name="VkPhysicalDeviceDiscardRectanglePropertiesEXT" 
> structextends="VkPhysicalDeviceProperties2">
>   values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DISCARD_RECTANGLE_PROPERTIES_EXT">VkStructureType
>  sType
> @@ -3235,10 +3235,10 @@ server.
>   name="VkPhysicalDevicePCIBusInfoPropertiesEXT" 
> structextends="VkPhysicalDeviceProperties2" returnedonly="true">
>   values="VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PCI_BUS_INFO_PROPERTIES_EXT">VkStructureType
>  sType
>  void*  
> pNext
> -uint16_t   
> pciDomain
> -uint8_t
> pciBus
> -uint8_t
> pciDevice
> -uint8_t
> pciFunction
> +uint32_t   
> pciDomain
> +uint32_t   
> pciBus
> +uint32_t   
> pciDevice
> +uint32_t   
> pciFunction
>  
>   name="VkImportAndroidHardwareBufferInfoANDROID" 
> structextends="VkMemoryAllocateInfo">
>   values="VK_STRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROID">VkStructureType
>  sType
> @@ -3420,7 +3420,7 @@ server.
>  VkBool32
> shadingRateImage
>  VkBool32
> shadingRateCoarseSampleOrder
>  
> - name="VkPhysicalDeviceShadingRateImagePropertiesNV" 
> structextends="VkPhysicalDeviceProperties" 

[Mesa-dev] [PATCH 2/2] anv,radv: Re-enable VK_EXT_pci_bus_info

[Jason Ekstrand]

Now at version 2 with the fixed header.
---
 src/amd/vulkan/radv_extensions.py  | 2 +-
 src/intel/vulkan/anv_extensions.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index ae5e6950f1e..8ac8ae6698c 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -105,7 +105,7 @@ EXTENSIONS = [
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_external_memory_host',  1, 
'device->rad_info.has_userptr'),
 Extension('VK_EXT_global_priority',   1, 
'device->rad_info.has_ctx_priority'),
-Extension('VK_EXT_pci_bus_info',  1, False),
+Extension('VK_EXT_pci_bus_info',  2, True),
 Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->rad_info.chip_class >= CIK'),
 Extension('VK_EXT_scalar_block_layout',   1, 
'device->rad_info.chip_class >= CIK'),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index 1c0b71a7c46..b6269d0047a 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -121,7 +121,7 @@ EXTENSIONS = [
 Extension('VK_EXT_external_memory_dma_buf',   1, True),
 Extension('VK_EXT_global_priority',   1,
   'device->has_context_priority'),
-Extension('VK_EXT_pci_bus_info',  1, False),
+Extension('VK_EXT_pci_bus_info',  2, True),
 Extension('VK_EXT_scalar_block_layout',   1, True),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),
-- 
2.19.2

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

[Mesa-dev] [PATCH 1/2] vulkan: Update the XML and headers to 1.1.96

[Jason Ekstrand]

---
 include/vulkan/vulkan_core.h | 16 
 src/vulkan/registry/vk.xml   | 22 +++---
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 50064109ef3..72542c72ec8 100644
--- a/include/vulkan/vulkan_core.h
+++ b/include/vulkan/vulkan_core.h
@@ -43,7 +43,7 @@ extern "C" {
 #define VK_VERSION_MINOR(version) (((uint32_t)(version) >> 12) & 0x3ff)
 #define VK_VERSION_PATCH(version) ((uint32_t)(version) & 0xfff)
 // Version of this file
-#define VK_HEADER_VERSION 95
+#define VK_HEADER_VERSION 96
 
 
 #define VK_NULL_HANDLE 0
@@ -8862,16 +8862,16 @@ VKAPI_ATTR void VKAPI_CALL vkGetQueueCheckpointDataNV(
 #endif
 
 #define VK_EXT_pci_bus_info 1
-#define VK_EXT_PCI_BUS_INFO_SPEC_VERSION  1
+#define VK_EXT_PCI_BUS_INFO_SPEC_VERSION  2
 #define VK_EXT_PCI_BUS_INFO_EXTENSION_NAME "VK_EXT_pci_bus_info"
 
 typedef struct VkPhysicalDevicePCIBusInfoPropertiesEXT {
 VkStructureTypesType;
 void*  pNext;
-uint16_t   pciDomain;
-uint8_tpciBus;
-uint8_tpciDevice;
-uint8_tpciFunction;
+uint32_t   pciDomain;
+uint32_t   pciBus;
+uint32_t   pciDevice;
+uint32_t   pciFunction;
 } VkPhysicalDevicePCIBusInfoPropertiesEXT;
 
 
@@ -8917,12 +8917,12 @@ typedef struct 
VkPhysicalDeviceScalarBlockLayoutFeaturesEXT {
 
 
 #define VK_GOOGLE_hlsl_functionality1 1
-#define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 0
+#define VK_GOOGLE_HLSL_FUNCTIONALITY1_SPEC_VERSION 1
 #define VK_GOOGLE_HLSL_FUNCTIONALITY1_EXTENSION_NAME 
"VK_GOOGLE_hlsl_functionality1"
 
 
 #define VK_GOOGLE_decorate_string 1
-#define VK_GOOGLE_DECORATE_STRING_SPEC_VERSION 0
+#define VK_GOOGLE_DECORATE_STRING_SPEC_VERSION 1
 #define VK_GOOGLE_DECORATE_STRING_EXTENSION_NAME "VK_GOOGLE_decorate_string"
 
 
diff --git a/src/vulkan/registry/vk.xml b/src/vulkan/registry/vk.xml
index 2c9b79976bc..d60f41187fe 100644
--- a/src/vulkan/registry/vk.xml
+++ b/src/vulkan/registry/vk.xml
@@ -146,7 +146,7 @@ server.
 // Vulkan 1.1 version number
 #define VK_API_VERSION_1_1 VK_MAKE_VERSION(1, 1, 
0)// Patch version should always be set to 0
 // Version of this file
-#define VK_HEADER_VERSION 95
+#define VK_HEADER_VERSION 96
 
 
 #define VK_DEFINE_HANDLE(object) typedef struct object##_T* 
object;
@@ -2513,7 +2513,7 @@ server.
 const void*  
pNext
 VkBool32   
viewportWScalingEnable
 uint32_t   
viewportCount
-const 
VkViewportWScalingNV*  pViewportWScalings
+const 
VkViewportWScalingNV*  pViewportWScalings
 
 
 VkViewportCoordinateSwizzleNV  
x
@@ -2526,7 +2526,7 @@ server.
 const void*
pNext
 VkPipelineViewportSwizzleStateCreateFlagsNV
flags
 uint32_t   
viewportCount
-const VkViewportSwizzleNV*  
pViewportSwizzles
+const 
VkViewportSwizzleNV*  pViewportSwizzles
 
 
 VkStructureType
 sType
@@ -3235,10 +3235,10 @@ server.
 
 VkStructureType
 sType
 void*  
pNext
-uint16_t   
pciDomain
-uint8_t
pciBus
-uint8_t
pciDevice
-uint8_t
pciFunction
+uint32_t   
pciDomain
+uint32_t   
pciBus
+uint32_t   
pciDevice
+uint32_t   
pciFunction
 
 
 VkStructureType
 sType
@@ -3420,7 +3420,7 @@ server.
 VkBool32
shadingRateImage
 VkBool32
shadingRateCoarseSampleOrder
 
-
+
 VkStructureType
 sType
 void*   
pNext
 VkExtent2D  
shadingRateTexelSize
@@ -10001,7 +10001,7 @@ server.
 
 
 
-
+
 
 
 
@@ -10091,13 +10091,13 @@ server.
 
 
 
-
+
 
 
 
 
 
-
+
 
 
 
-- 
2.19.2

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

[Mesa-dev] [Bug 108116] [vulkancts] stencil partial clear tests fail.

[bugzilla-daemon]

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

Rhys Perry  changed:

   What|Removed |Added

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

--- Comment #3 from Rhys Perry  ---
Fixed-by:

commit bba94a3d85c8799b2441a5d41015091e8903738f
Author: Rhys Perry 
Date:   Fri Dec 14 16:47:09 2018 +

radv: don't set surf_index for stencil-only images

Fixes: f8d5b377c8b ('radv: set cb base tile swizzles for MRT speedups
(v4)')
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108116
Signed-off-by: Rhys Perry 
Reviewed-by: Bas Nieuwenhuizen 
Reviewed-by: Samuel Pitoiset 

-- 
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] last call for autotools

[Eero Tamminen]

Hi,

On 17.12.2018 8.08, Marek Olšák wrote:
[...]
I think one of the serious usability issues is that environment 
variables such as CFLAGS, CXXFLAGS, LDFLAGS, and PKG_CONFIG_PATH are not 
saved by meson for future reconfigures.


I don't know what Meson is supposed to do, but to me that would be
a bug in a build tool.

Re-configure is supposed to adapt SW to the changes in the build
environment, and environment variables are part of that (along with
command line options and SW installed to to the system).  Build
configure tool deciding to "remember" some of those things instead
of checking the new situation, seems like a great opportunity for
confusion.


- Eero


I think meson should ignore the 
variables completely, or the Mesa documentation should discourage users 
from the setting the variables. The current situation would be 
acceptable to me if users were warned that setting environment variables 
is a trap.

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

Re: [Mesa-dev] Suggestions for improving meson-based builds

[Eero Tamminen]

Hi,

On 17.12.2018 2.33, Jason Ekstrand wrote:
On Sun, Dec 16, 2018 at 1:49 PM Ilia Mirkin > wrote:

[...]> 2. Summary at the end. This is not strictly an autotools-specific

issue, but rather how mesa has used it. That summary at the end is
very useful to make sure you (or someone you're helping) hasn't
screwed something up.

Run "meson configure" with no options.  It will dump out a full 
configuration.  Sure, it's not the same format but, unless I'm 
misunderstanding something, all of the information from the old summary 
and more is available there.  Or are you concerned with various derived 
or auto-configured values?  Or is it your concern that it get dumped out 
at the end of a configure rather than having to ask for it?  It'd be 
helpful if you'd be more specific about what you want than "the 
autotools thing".


Having build itself output (by default) the configured settings is
useful when going through build logs and looking for errors, and
build env & configuration differences.

It's run-time generated documentation about how the software decided
to configure itself to its build environment.  Personally I'd rather
read well formatted and concise documentation.

Nice (default) output of how the software configured itself to given
environment makes project somehow IMHO much more user-friendly, and
it's first impression of the project for a new developer.


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

[Mesa-dev] [PATCH 7/7] swr/rast: Store cached files in multiple subdirs

[Alok Hota]

This improves cache filesystem performance, especially during CI tests
Also updated jitcache magic number due to codegen parameter changes
Removed 2 `if constexpr` to prevent C++17 requirement
---
 .../swr/rasterizer/jitter/JitManager.cpp  | 51 ---
 .../swr/rasterizer/jitter/JitManager.h|  6 +++
 .../swr/rasterizer/jitter/builder_misc.cpp| 33 +---
 3 files changed, 52 insertions(+), 38 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index 1b2b570318c..a549721f147 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -582,7 +582,7 @@ struct JitCacheFileHeader
 uint64_t GetObjectCRC() const { return m_objCRC; }
 
 private:
-static const uint64_t JC_MAGIC_NUMBER = 0xfedcba9876543211ULL + 4;
+static const uint64_t JC_MAGIC_NUMBER = 0xfedcba9876543210ULL + 6;
 static const size_t   JC_STR_MAX_LEN  = 32;
 static const uint32_t JC_PLATFORM_KEY = (LLVM_VERSION_MAJOR << 24) |
 (LLVM_VERSION_MINOR << 16) | 
(LLVM_VERSION_PATCH << 8) |
@@ -634,6 +634,15 @@ JitCache::JitCache()
 {
 mCacheDir = KNOB_JIT_CACHE_DIR;
 }
+
+// Create cache dir at startup to allow jitter to write debug.ll files
+// to that directory.
+if (!llvm::sys::fs::exists(mCacheDir.str()) &&
+llvm::sys::fs::create_directories(mCacheDir.str()))
+{
+SWR_INVALID("Unable to create directory: %s", mCacheDir.c_str());
+}
+
 }
 
 int ExecUnhookedProcess(const std::string& CmdLine, std::string* pStdOut, 
std::string* pStdErr)
@@ -641,6 +650,26 @@ int ExecUnhookedProcess(const std::string& CmdLine, 
std::string* pStdOut, std::s
 return ExecCmd(CmdLine, "", pStdOut, pStdErr);
 }
 
+/// Calculate actual directory where module will be cached.
+/// This is always a subdirectory of mCacheDir.  Full absolute
+/// path name will be stored in mCurrentModuleCacheDir
+void JitCache::CalcModuleCacheDir()
+{
+mModuleCacheDir.clear();
+
+llvm::SmallString moduleDir = mCacheDir;
+
+// Create 4 levels of directory hierarchy based on CRC, 256 entries each
+uint8_t* pCRC = (uint8_t*)
+for (uint32_t i = 0; i < 4; ++i)
+{
+llvm::sys::path::append(moduleDir, std::to_string((int)pCRC[i]));
+}
+
+mModuleCacheDir = moduleDir;
+}
+
+
 /// notifyObjectCompiled - Provides a pointer to compiled code for Module M.
 void JitCache::notifyObjectCompiled(const llvm::Module* M, 
llvm::MemoryBufferRef Obj)
 {
@@ -650,16 +679,22 @@ void JitCache::notifyObjectCompiled(const llvm::Module* 
M, llvm::MemoryBufferRef
 return;
 }
 
-if (!llvm::sys::fs::exists(mCacheDir.str()) &&
-llvm::sys::fs::create_directories(mCacheDir.str()))
+if (!mModuleCacheDir.size())
 {
-SWR_INVALID("Unable to create directory: %s", mCacheDir.c_str());
+SWR_INVALID("Unset module cache directory");
+return;
+}
+
+if (!llvm::sys::fs::exists(mModuleCacheDir.str()) &&
+llvm::sys::fs::create_directories(mModuleCacheDir.str()))
+{
+SWR_INVALID("Unable to create directory: %s", mModuleCacheDir.c_str());
 return;
 }
 
 JitCacheFileHeader header;
 
-llvm::SmallString filePath = mCacheDir;
+llvm::SmallString filePath = mModuleCacheDir;
 llvm::sys::path::append(filePath, moduleID);
 
 llvm::SmallString objPath = filePath;
@@ -699,12 +734,14 @@ std::unique_ptr 
JitCache::getObject(const llvm::Module* M)
 return nullptr;
 }
 
-if (!llvm::sys::fs::exists(mCacheDir))
+CalcModuleCacheDir();
+
+if (!llvm::sys::fs::exists(mModuleCacheDir))
 {
 return nullptr;
 }
 
-llvm::SmallString filePath = mCacheDir;
+llvm::SmallString filePath = mModuleCacheDir;
 llvm::sys::path::append(filePath, moduleID);
 
 llvm::SmallString objFilePath = filePath;
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
index 5659191525d..bb7ca8b4a3e 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.h
@@ -113,9 +113,15 @@ public:
 private:
 std::string mCpu;
 llvm::SmallString mCacheDir;
+llvm::SmallString mModuleCacheDir;
 uint32_tmCurrentModuleCRC = 0;
 JitManager* mpJitMgr  = nullptr;
 llvm::CodeGenOpt::Level mOptLevel = llvm::CodeGenOpt::None;
+
+/// Calculate actual directory where module will be cached.
+/// This is always a subdirectory of mCacheDir.  Full absolute
+/// path name will be stored in mCurrentModuleCacheDir
+void CalcModuleCacheDir();
 };
 
 //
diff --git 

[Mesa-dev] [PATCH 4/7] swr/rast: Unaligned and translations in gathers

[Alok Hota]

- added graphics address translation in odd gathers
- added support for unaligned gathers in fetch shader
- changed how 2+ GB offsets are handled to make them compatible with
unaligned offsets
---
 .../swr/rasterizer/jitter/fetch_jit.cpp   | 56 ---
 1 file changed, 35 insertions(+), 21 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
index d294a67050c..6feb1a76e63 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
@@ -368,7 +368,7 @@ void FetchJit::UnpackComponents(SWR_FORMAT format, Value* 
vInput, Value* result[
 // gather SIMD full pixels per lane then shift/mask to move each component to 
their
 // own vector
 void FetchJit::CreateGatherOddFormats(
-SWR_FORMAT format, Value* pMask, Value* pBase, Value* pOffsets, Value* 
pResult[4])
+SWR_FORMAT format, Value* pMask, Value* xpBase, Value* pOffsets, Value* 
pResult[4])
 {
 const SWR_FORMAT_INFO& info = GetFormatInfo(format);
 
@@ -378,7 +378,7 @@ void FetchJit::CreateGatherOddFormats(
 Value* pGather;
 if (info.bpp == 32)
 {
-pGather = GATHERDD(VIMMED1(0), pBase, pOffsets, pMask);
+pGather = GATHERDD(VIMMED1(0), xpBase, pOffsets, pMask);
 }
 else
 {
@@ -386,29 +386,40 @@ void FetchJit::CreateGatherOddFormats(
 Value* pMem = ALLOCA(mSimdInt32Ty);
 STORE(VIMMED1(0u), pMem);
 
-pBase  = BITCAST(pBase, PointerType::get(mInt8Ty, 0));
-Value* pDstMem = BITCAST(pMem, mInt32PtrTy);
+Value* pDstMem = POINTER_CAST(pMem, mInt32PtrTy);
 
 for (uint32_t lane = 0; lane < mVWidth; ++lane)
 {
 // Get index
 Value* index = VEXTRACT(pOffsets, C(lane));
 Value* mask  = VEXTRACT(pMask, C(lane));
+
+// use branch around load based on mask
+// Needed to avoid page-faults on unmasked lanes
+BasicBlock* pCurrentBB = IRB()->GetInsertBlock();
+BasicBlock* pMaskedLoadBlock =
+BasicBlock::Create(JM()->mContext, "MaskedLaneLoad", 
pCurrentBB->getParent());
+BasicBlock* pEndLoadBB = BasicBlock::Create(JM()->mContext, 
"AfterMaskedLoad", pCurrentBB->getParent());
+
+COND_BR(mask, pMaskedLoadBlock, pEndLoadBB);
+
+JM()->mBuilder.SetInsertPoint(pMaskedLoadBlock);
+
 switch (info.bpp)
 {
 case 8:
 {
 Value* pDst = BITCAST(GEP(pDstMem, C(lane)), 
PointerType::get(mInt8Ty, 0));
-Value* pSrc = BITCAST(GEP(pBase, index), 
PointerType::get(mInt8Ty, 0));
-STORE(LOAD(SELECT(mask, pSrc, pDst)), pDst);
+Value* xpSrc = ADD(xpBase, Z_EXT(index, xpBase->getType()));
+STORE(LOAD(xpSrc, "", mInt8PtrTy, GFX_MEM_CLIENT_FETCH), pDst);
 break;
 }
 
 case 16:
 {
 Value* pDst = BITCAST(GEP(pDstMem, C(lane)), 
PointerType::get(mInt16Ty, 0));
-Value* pSrc = BITCAST(GEP(pBase, index), 
PointerType::get(mInt16Ty, 0));
-STORE(LOAD(SELECT(mask, pSrc, pDst)), pDst);
+Value* xpSrc = ADD(xpBase, Z_EXT(index, xpBase->getType()));
+STORE(LOAD(xpSrc, "", mInt16PtrTy, GFX_MEM_CLIENT_FETCH), 
pDst);
 break;
 }
 break;
@@ -417,13 +428,13 @@ void FetchJit::CreateGatherOddFormats(
 {
 // First 16-bits of data
 Value* pDst = BITCAST(GEP(pDstMem, C(lane)), 
PointerType::get(mInt16Ty, 0));
-Value* pSrc = BITCAST(GEP(pBase, index), 
PointerType::get(mInt16Ty, 0));
-STORE(LOAD(SELECT(mask, pSrc, pDst)), pDst);
+Value* xpSrc = ADD(xpBase, Z_EXT(index, xpBase->getType()));
+STORE(LOAD(xpSrc, "", mInt16PtrTy, GFX_MEM_CLIENT_FETCH), 
pDst);
 
 // Last 8-bits of data
 pDst = BITCAST(GEP(pDst, C(1)), PointerType::get(mInt8Ty, 0));
-pSrc = BITCAST(GEP(pSrc, C(1)), PointerType::get(mInt8Ty, 0));
-STORE(LOAD(SELECT(mask, pSrc, pDst)), pDst);
+xpSrc = ADD(xpSrc, C(2));
+STORE(LOAD(xpSrc, "", mInt8PtrTy, GFX_MEM_CLIENT_FETCH), pDst);
 break;
 }
 
@@ -431,6 +442,9 @@ void FetchJit::CreateGatherOddFormats(
 SWR_INVALID("Shouldn't have BPP = %d now", info.bpp);
 break;
 }
+
+BR(pEndLoadBB);
+JM()->mBuilder.SetInsertPoint(pEndLoadBB);
 }
 
 pGather = LOAD(pMem);
@@ -616,7 +630,7 @@ void FetchJit::JitGatherVertices(const FETCH_COMPILE_STATE& 
fetchState,
 // do 64bit address offset calculations.
 
 // calculate byte offset to the start of the VB
-Value* baseOffset = 

[Mesa-dev] [PATCH 6/7] swr/rast: New execution engine per JIT

[Alok Hota]

Fixes relocation errors with LLVM 7.0.0
---
 .../swr/rasterizer/jitter/JitManager.cpp  | 79 +++
 .../swr/rasterizer/jitter/JitManager.h| 28 +--
 2 files changed, 65 insertions(+), 42 deletions(-)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp 
b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
index 58d30d4e119..1b2b570318c 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
@@ -63,39 +63,29 @@ JitManager::JitManager(uint32_t simdWidth, const char* 
arch, const char* core) :
 mContext(), mBuilder(mContext), mIsModuleFinalized(true), mJitNumber(0), 
mVWidth(simdWidth),
 mArch(arch)
 {
+mpCurrentModule = nullptr;
+mpExec = nullptr;
+
 InitializeNativeTarget();
 InitializeNativeTargetAsmPrinter();
 InitializeNativeTargetDisassembler();
 
 
-TargetOptions tOpts;
-tOpts.AllowFPOpFusion = FPOpFusion::Fast;
-tOpts.NoInfsFPMath= false;
-tOpts.NoNaNsFPMath= false;
-tOpts.UnsafeFPMath = false;
-
-// tOpts.PrintMachineCode= true;
-
-std::unique_ptr newModule(new Module("", mContext));
-mpCurrentModule = newModule.get();
-
-StringRef hostCPUName;
-
 // force JIT to use the same CPU arch as the rest of swr
 if (mArch.AVX512F())
 {
 #if USE_SIMD16_SHADERS
 if (mArch.AVX512ER())
 {
-hostCPUName = StringRef("knl");
+mHostCpuName = StringRef("knl");
 }
 else
 {
-hostCPUName = StringRef("skylake-avx512");
+mHostCpuName = StringRef("skylake-avx512");
 }
 mUsingAVX512 = true;
 #else
-hostCPUName = StringRef("core-avx2");
+mHostCpuName = StringRef("core-avx2");
 #endif
 if (mVWidth == 0)
 {
@@ -104,7 +94,7 @@ JitManager::JitManager(uint32_t simdWidth, const char* arch, 
const char* core) :
 }
 else if (mArch.AVX2())
 {
-hostCPUName = StringRef("core-avx2");
+mHostCpuName = StringRef("core-avx2");
 if (mVWidth == 0)
 {
 mVWidth = 8;
@@ -114,11 +104,11 @@ JitManager::JitManager(uint32_t simdWidth, const char* 
arch, const char* core) :
 {
 if (mArch.F16C())
 {
-hostCPUName = StringRef("core-avx-i");
+mHostCpuName = StringRef("core-avx-i");
 }
 else
 {
-hostCPUName = StringRef("corei7-avx");
+mHostCpuName = StringRef("corei7-avx");
 }
 if (mVWidth == 0)
 {
@@ -131,31 +121,21 @@ JitManager::JitManager(uint32_t simdWidth, const char* 
arch, const char* core) :
 }
 
 
-auto optLevel = CodeGenOpt::Aggressive;
+mOptLevel = CodeGenOpt::Aggressive;
 
 if (KNOB_JIT_OPTIMIZATION_LEVEL >= CodeGenOpt::None &&
 KNOB_JIT_OPTIMIZATION_LEVEL <= CodeGenOpt::Aggressive)
 {
-optLevel = CodeGenOpt::Level(KNOB_JIT_OPTIMIZATION_LEVEL);
+mOptLevel = CodeGenOpt::Level(KNOB_JIT_OPTIMIZATION_LEVEL);
 }
 
-mpCurrentModule->setTargetTriple(sys::getProcessTriple());
-mpExec = EngineBuilder(std::move(newModule))
- .setTargetOptions(tOpts)
- .setOptLevel(optLevel)
- .setMCPU(hostCPUName)
- .create();
-
 if (KNOB_JIT_ENABLE_CACHE)
 {
-mCache.Init(this, hostCPUName, optLevel);
-mpExec->setObjectCache();
+mCache.Init(this, mHostCpuName, mOptLevel);
 }
 
-#if LLVM_USE_INTEL_JITEVENTS
-JITEventListener* vTune = JITEventListener::createIntelJITEventListener();
-mpExec->RegisterJITEventListener(vTune);
-#endif
+SetupNewModule();
+mIsModuleFinalized = true;
 
 // fetch function signature
 #if USE_SIMD16_SHADERS
@@ -198,6 +178,35 @@ JitManager::JitManager(uint32_t simdWidth, const char* 
arch, const char* core) :
 #endif
 }
 
+void JitManager::CreateExecEngine(std::unique_ptr pModule)
+{
+TargetOptions tOpts;
+tOpts.AllowFPOpFusion = FPOpFusion::Fast;
+tOpts.NoInfsFPMath= false;
+tOpts.NoNaNsFPMath= false;
+tOpts.UnsafeFPMath = false;
+
+// tOpts.PrintMachineCode= true;
+
+mpExec = EngineBuilder(std::move(pModule))
+ .setTargetOptions(tOpts)
+ .setOptLevel(mOptLevel)
+ .setMCPU(mHostCpuName)
+ .create();
+
+if (KNOB_JIT_ENABLE_CACHE)
+{
+mpExec->setObjectCache();
+}
+
+#if LLVM_USE_INTEL_JITEVENTS
+JITEventListener* vTune = JITEventListener::createIntelJITEventListener();
+mpExec->RegisterJITEventListener(vTune);
+#endif
+
+mvExecEngines.push_back(mpExec);
+}
+
 //
 /// @brief Create new LLVM module.
 void JitManager::SetupNewModule()
@@ -207,7 +216,7 @@ void JitManager::SetupNewModule()
 std::unique_ptr newModule(new Module("", mContext));
 

[Mesa-dev] [PATCH 0/7] swr/rast: jitter updates

[Alok Hota]

These patches contain a series of updates to the jitter

Alok Hota (7):
  swr/rast: Use gfxptr_t value in JitGatherVertices
  swr/rast: Add annotator to interleave isa text
  swr/rast: partial support for Tiled Resources
  swr/rast: Unaligned and translations in gathers
  swr/rast: Scope MEM_CLIENT enum for mem usages
  swr/rast: New execution engine per JIT
  swr/rast: Store cached files in multiple subdirs

 .../swr/rasterizer/jitter/JitManager.cpp  | 157 +-
 .../swr/rasterizer/jitter/JitManager.h|  42 -
 .../drivers/swr/rasterizer/jitter/builder.h   |   1 -
 .../swr/rasterizer/jitter/builder_gfx_mem.cpp |   2 +-
 .../swr/rasterizer/jitter/builder_gfx_mem.h   |  20 +--
 .../swr/rasterizer/jitter/builder_mem.cpp |   1 -
 .../swr/rasterizer/jitter/builder_mem.h   |  28 ++--
 .../swr/rasterizer/jitter/builder_misc.cpp| 113 +
 .../swr/rasterizer/jitter/builder_misc.h  |  22 +++
 .../swr/rasterizer/jitter/fetch_jit.cpp   |  98 ++-
 10 files changed, 364 insertions(+), 120 deletions(-)

-- 
2.17.1

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