[Mesa-dev] [Bug 107890] [bisected] Android build test fails "use of undeclared identifier 'cpu_set_t'/'cpuset'"

[bugzilla-daemon]

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

Tapani Pälli  changed:

   What|Removed |Added

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

--- Comment #2 from Tapani Pälli  ---
commit 9f1bbbdbbd77d346c74c7abbb31f399151a85713
Author: Marek Olšák 
Date:   Sat Sep 8 21:02:18 2018 -0400

util: try to fix the Android and MacOS build

Bionic does not have pthread_setaffinity_np.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107869
Reviewed-by: Jose Fonseca 
Reviewed-by: Tapani Pälli 

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

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_vertex_program in core profile

[Timothy Arceri]

On 11/9/18 9:40 am, Ian Romanick wrote:

Rather than adding a bunch of this nonsense extension to the core
profile list, we should probably add a driconf option to advertise any
GLL extension in GLC.  There can't be very many apps check for weird
stuff like this.


I was thinking of a driconf option to force a compat profile, its 
probably easier than messing with these tables and the game seems to run 
fine when forced to use compat.




On 09/09/2018 03:52 PM, Ian Romanick wrote:

No.  This is one is definitely out.  ARB_vertex_program *require* all of
the legacy stuff that core profile removes.  There is no way this one is
valid.

On 09/07/2018 09:20 PM, Timothy Arceri wrote:

This extension is required by "Wolfenstein: The Old Blood". Without
it the app causes wine to crash on startup.
---
  src/mesa/main/extensions_table.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 09bf923bd0e..7144ce75bbc 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -183,7 +183,7 @@ EXT(ARB_vertex_array_object , dummy_true
  EXT(ARB_vertex_attrib_64bit , ARB_vertex_attrib_64bit 
   ,  32, GLC,  x ,  x , 2010)
  EXT(ARB_vertex_attrib_binding   , dummy_true  
   , GLL, GLC,  x ,  x , 2012)
  EXT(ARB_vertex_buffer_object, dummy_true  
   , GLL, GLC,  x ,  x , 2003)
-EXT(ARB_vertex_program  , ARB_vertex_program   
  , GLL,  x ,  x ,  x , 2002)
+EXT(ARB_vertex_program  , ARB_vertex_program   
  , GLL, GLC,  x ,  x , 2002)
  EXT(ARB_vertex_shader   , ARB_vertex_shader   
   , GLL, GLC,  x ,  x , 2002)
  EXT(ARB_vertex_type_10f_11f_11f_rev , ARB_vertex_type_10f_11f_11f_rev 
   , GLL, GLC,  x ,  x , 2013)
  EXT(ARB_vertex_type_2_10_10_10_rev  , ARB_vertex_type_2_10_10_10_rev  
   , GLL, GLC,  x ,  x , 2009)



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



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

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 CC|ja...@jlekstrand.net|

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

Re: [Mesa-dev] [PATCH 2/2] mesa: enable ARB_vertex_program in core profile

[Ian Romanick]

Rather than adding a bunch of this nonsense extension to the core
profile list, we should probably add a driconf option to advertise any
GLL extension in GLC.  There can't be very many apps check for weird
stuff like this.

On 09/09/2018 03:52 PM, Ian Romanick wrote:
> No.  This is one is definitely out.  ARB_vertex_program *require* all of
> the legacy stuff that core profile removes.  There is no way this one is
> valid.
> 
> On 09/07/2018 09:20 PM, Timothy Arceri wrote:
>> This extension is required by "Wolfenstein: The Old Blood". Without
>> it the app causes wine to crash on startup.
>> ---
>>  src/mesa/main/extensions_table.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/extensions_table.h 
>> b/src/mesa/main/extensions_table.h
>> index 09bf923bd0e..7144ce75bbc 100644
>> --- a/src/mesa/main/extensions_table.h
>> +++ b/src/mesa/main/extensions_table.h
>> @@ -183,7 +183,7 @@ EXT(ARB_vertex_array_object , dummy_true
>>  EXT(ARB_vertex_attrib_64bit , ARB_vertex_attrib_64bit   
>>  ,  32, GLC,  x ,  x , 2010)
>>  EXT(ARB_vertex_attrib_binding   , dummy_true
>>  , GLL, GLC,  x ,  x , 2012)
>>  EXT(ARB_vertex_buffer_object, dummy_true
>>  , GLL, GLC,  x ,  x , 2003)
>> -EXT(ARB_vertex_program  , ARB_vertex_program
>>  , GLL,  x ,  x ,  x , 2002)
>> +EXT(ARB_vertex_program  , ARB_vertex_program
>>  , GLL, GLC,  x ,  x , 2002)
>>  EXT(ARB_vertex_shader   , ARB_vertex_shader 
>>  , GLL, GLC,  x ,  x , 2002)
>>  EXT(ARB_vertex_type_10f_11f_11f_rev , 
>> ARB_vertex_type_10f_11f_11f_rev, GLL, GLC,  x ,  x , 2013)
>>  EXT(ARB_vertex_type_2_10_10_10_rev  , 
>> ARB_vertex_type_2_10_10_10_rev , GLL, GLC,  x ,  x , 2009)
>>
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

Re: [Mesa-dev] [RFC 6/7] HACK: Disable the instruction scheduler

[Jason Ekstrand]

On Mon, Sep 10, 2018 at 5:38 PM Ian Romanick  wrote:

> On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> > The instruction scheduler is re-ordering loads which is causing fence
> > values to be loaded after the value they're fencing.  In particular,
> > consider the following pseudocode:
> >
> > void try_use_a_thing(int idx)
> > {
> > bool ready = ssbo.arr[idx].ready;
> > vec4 data = ssbo.arr[idx].data;
> > if (ready)
> > use(data);
> > }
> >
> > void write_a_thing(int idx, vec4 data)
> > {
> > ssbo.arr[idx].data = data;
> > ssbo.arr[idx].ready = true;
> > }
> >
> > Our current instruction scheduling scheme doesn't see any problem with
> > re-ordering the load of "ready" with respect to the load of "data".
> > However, if try_use_a_thing is called in one thread and write_a_thing is
> > called in another thread, such re-ordering could cause invalid data to
> > be used.  Normally, some re-ordering of loads is fine; however, with the
> > Vulkan memory model, there are some additional guarantees that are
> > provided particularly in the case of atomic loads which we currently
> > don't differentiate in any way in the back-end.
>
> I have encountered similar problems with reordering in OpenGL land
> reading a value that is also accessed using atomics.  SPIR-V has an
> atomic load instruction.  I haven't looked at how we handle that in
> spv_to_nir, but could we use something like that in these cases?
>

OpenGL only has load/store and no concept of an atomic load or store.  I
think the theory is that loads/stores of a 32-bit integer should already be
atomic, right?  Unfortunately, that leaves the ordering rules ambiguous.
SPIR-V has AtomicLoad and AtomicStore opcodes which could imply the
appropreate ordering constraings more-or-less.  With the memory model,
however, things get a lot more granular and you can start specifying very
fine-grained ordering constraints on loads, stores, and atomics.  The
primary difference, in this brave new world, between atomic and not is that
atomics get some of those constraints by default whereas you have to ask
for it on a regular load/store.

Currently SPIR-V's OpAtomicLoad is just translated to a regular load in NIR.

--Jason


> > Obviously, we need to come up with something better for this than just
> > shutting off the scheduler but I wanted to send this out earlier rather
> > than later and provide the opportunity for a discussion.
> > ---
> >  src/intel/compiler/brw_fs.cpp | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> > index 3f7f2b4c984..9df238a6f6a 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -6427,7 +6427,7 @@ fs_visitor::allocate_registers(unsigned
> min_dispatch_width, bool allow_spilling)
> >  * performance but increasing likelihood of allocating.
> >  */
> > for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
> > -  schedule_instructions(pre_modes[i]);
> > +  //schedule_instructions(pre_modes[i]);
> >
> >if (0) {
> >   assign_regs_trivial();
> > @@ -6478,7 +6478,7 @@ fs_visitor::allocate_registers(unsigned
> min_dispatch_width, bool allow_spilling)
> >
> > opt_bank_conflicts();
> >
> > -   schedule_instructions(SCHEDULE_POST);
> > +   //schedule_instructions(SCHEDULE_POST);
> >
> > if (last_scratch > 0) {
> >MAYBE_UNUSED unsigned max_scratch_size = 2 * 1024 * 1024;
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RESEND PATCH 0/5] i965: More cmod propagation

[Ian Romanick]

Bump

On 08/29/2018 11:40 AM, Ian Romanick wrote:
> This is mostly a resend of a series that I originally sent out around
> the end of June.  I updated some of the shader-db results, and I dropped
> one patch (i965/fs: Allow Boolean conditions in CSEL generation).  I
> decided that I want to try to acomplish that with a different method.
> That's going to take a bit more work, and I didn't want to hold up the
> rest of the series.
> 
> ___
> 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] [RESEND PATCH 0/9] Partial redundancy elimination for compares

[Ian Romanick]

Bump

On 08/29/2018 10:35 PM, Ian Romanick wrote:
> This is mostly a resend of this series.  Several patches, noted with
> "v#", have been updated.
> 
> Patches 3 and 4 are new.  Right before sending the series, I decided to
> update the shader-db results AND update shader-db.  The update to
> shader-db added a bunch of new shaders hurt by patch 4.  It may be
> reasonable to drop 3 and 4 for now.
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [RFC 6/7] HACK: Disable the instruction scheduler

[Jason Ekstrand]

On Mon, Sep 10, 2018 at 5:33 PM Bas Nieuwenhuizen 
wrote:

> On Mon, Sep 10, 2018 at 8:05 PM Jason Ekstrand 
> wrote:
> >
> > The instruction scheduler is re-ordering loads which is causing fence
> > values to be loaded after the value they're fencing.  In particular,
> > consider the following pseudocode:
> >
> > void try_use_a_thing(int idx)
> > {
> > bool ready = ssbo.arr[idx].ready;
> > vec4 data = ssbo.arr[idx].data;
> > if (ready)
> > use(data);
> > }
> >
> > void write_a_thing(int idx, vec4 data)
> > {
> > ssbo.arr[idx].data = data;
> > ssbo.arr[idx].ready = true;
> > }
> >
> > Our current instruction scheduling scheme doesn't see any problem with
> > re-ordering the load of "ready" with respect to the load of "data".
> > However, if try_use_a_thing is called in one thread and write_a_thing is
> > called in another thread, such re-ordering could cause invalid data to
> > be used.  Normally, some re-ordering of loads is fine; however, with the
> > Vulkan memory model, there are some additional guarantees that are
> > provided particularly in the case of atomic loads which we currently
> > don't differentiate in any way in the back-end.
> >
> > Obviously, we need to come up with something better for this than just
> > shutting off the scheduler but I wanted to send this out earlier rather
> > than later and provide the opportunity for a discussion.
>
> so how about adding a bitmask with flags for these to load/store
> intrinsics? I remember we still need a coherent bit to implement
> coherent loads and stores for AMD. We could easily have a mask with
> coherent+atomic+whatever and then pass that to the backend?
>

I think that's where we're going to end up.  The current model you just
have load/store ops and then barriers to block around them.  However, I
suspect that the long-term direction is going to be something more like
SPIR-V's access flags on each load/store that provides some sort of partial
barrier and re-ordering restriction information.

> ---
> >  src/intel/compiler/brw_fs.cpp | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/compiler/brw_fs.cpp
> b/src/intel/compiler/brw_fs.cpp
> > index 3f7f2b4c984..9df238a6f6a 100644
> > --- a/src/intel/compiler/brw_fs.cpp
> > +++ b/src/intel/compiler/brw_fs.cpp
> > @@ -6427,7 +6427,7 @@ fs_visitor::allocate_registers(unsigned
> min_dispatch_width, bool allow_spilling)
> >  * performance but increasing likelihood of allocating.
> >  */
> > for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
> > -  schedule_instructions(pre_modes[i]);
> > +  //schedule_instructions(pre_modes[i]);
> >
> >if (0) {
> >   assign_regs_trivial();
> > @@ -6478,7 +6478,7 @@ fs_visitor::allocate_registers(unsigned
> min_dispatch_width, bool allow_spilling)
> >
> > opt_bank_conflicts();
> >
> > -   schedule_instructions(SCHEDULE_POST);
> > +   //schedule_instructions(SCHEDULE_POST);
> >
> > if (last_scratch > 0) {
> >MAYBE_UNUSED unsigned max_scratch_size = 2 * 1024 * 1024;
> > --
> > 2.17.1
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 02/11] nir/algebraic: sign(x)*x*x is abs(x)*x

[Ian Romanick]

From: Ian Romanick 

shader-db results:

All Gen7+ platforms had similar results. (Skylake shown)
total instructions in shared programs: 15106023 -> 15105981 (<.01%)
instructions in affected programs: 300 -> 258 (-14.00%)
helped: 6
HURT: 0
helped stats (abs) min: 7 max: 7 x̄: 7.00 x̃: 7
helped stats (rel) min: 14.00% max: 14.00% x̄: 14.00% x̃: 14.00%
95% mean confidence interval for instructions value: -7.00 -7.00
95% mean confidence interval for instructions %-change: -14.00% -14.00%
Instructions are helped.

total cycles in shared programs: 566050327 -> 566050075 (<.01%)
cycles in affected programs: 2826 -> 2574 (-8.92%)
helped: 6
HURT: 0
helped stats (abs) min: 40 max: 44 x̄: 42.00 x̃: 42
helped stats (rel) min: 8.89% max: 8.94% x̄: 8.92% x̃: 8.92%
95% mean confidence interval for cycles value: -44.30 -39.70
95% mean confidence interval for cycles %-change: -8.95% -8.88%
Cycles are helped.

No changes on Gen6 or earlier.

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

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index ae1261f8744..3267e93a583 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -105,6 +105,11 @@ optimizations = [
(('imul', a, 1), a),
(('fmul', a, -1.0), ('fneg', a)),
(('imul', a, -1), ('ineg', a)),
+   # If a < 0: fsign(a)*a*a => -1*a*a => -a*a => abs(a)*a
+   # If a > 0: fsign(a)*a*a => 1*a*a => a*a => abs(a)*a
+   # If a == 0: fsign(a)*a*a => 0*0*0 => abs(0)*0
+   (('fmul', ('fsign', a), ('fmul', a, a)), ('fmul', ('fabs', a), a)),
+   (('fmul', ('fmul', ('fsign', a), a), a), ('fmul', ('fabs', a), a)),
(('~ffma', 0.0, a, b), b),
(('~ffma', a, 0.0, b), b),
(('~ffma', a, b, 0.0), ('fmul', a, b)),
-- 
2.14.4

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

[Mesa-dev] [PATCH 05/11] i965/fs: Eliminate dead code first

[Ian Romanick]

From: Ian Romanick 

This simplifies the later patch "i965/fs: Generate better code for fsign
multiplied by a value".

shader-db results:

Broadwell and Skylake had similar results. (Skylake shown)
total cycles in shared programs: 566050075 -> 566053975 (<.01%)
cycles in affected programs: 1342167 -> 1346067 (0.29%)
helped: 231
HURT: 266
helped stats (abs) min: 1 max: 204 x̄: 13.30 x̃: 4
helped stats (rel) min: 0.01% max: 5.61% x̄: 0.45% x̃: 0.21%
HURT stats (abs)   min: 1 max: 623 x̄: 26.21 x̃: 5
HURT stats (rel)   min: 0.02% max: 15.20% x̄: 1.00% x̃: 0.28%
95% mean confidence interval for cycles value: 3.34 12.35
95% mean confidence interval for cycles %-change: 0.18% 0.47%
Cycles are HURT.

Sandy Bridge, Ivy Bridge, and Haswell had similar results. (Haswell shown)
total cycles in shared programs: 449617838 -> 449616551 (<.01%)
cycles in affected programs: 419356 -> 418069 (-0.31%)
helped: 44
HURT: 44
helped stats (abs) min: 1 max: 317 x̄: 86.75 x̃: 54
helped stats (rel) min: 0.03% max: 6.53% x̄: 1.56% x̃: 1.01%
HURT stats (abs)   min: 2 max: 221 x̄: 57.50 x̃: 19
HURT stats (rel)   min: 0.03% max: 9.46% x̄: 1.77% x̃: 0.54%
95% mean confidence interval for cycles value: -37.19 7.94
95% mean confidence interval for cycles %-change: -0.46% 0.67%
Inconclusive result (value mean confidence interval includes 0).

GM45 and Iron Lake had similar results. (Iron Lake shown)
total cycles in shared programs: 187478814 -> 187478820 (<.01%)
cycles in affected programs: 102438 -> 102444 (<.01%)
helped: 2
HURT: 3
helped stats (abs) min: 2 max: 4 x̄: 3.00 x̃: 3
helped stats (rel) min: <.01% max: 0.03% x̄: 0.02% x̃: 0.02%
HURT stats (abs)   min: 4 max: 4 x̄: 4.00 x̃: 4
HURT stats (rel)   min: 0.03% max: 0.03% x̄: 0.03% x̃: 0.03%
95% mean confidence interval for cycles value: -3.64 6.04
95% mean confidence interval for cycles %-change: -0.02% 0.04%
Inconclusive result (value mean confidence interval includes 0).

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index f19fa783a96..722c36a4e20 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6299,6 +6299,14 @@ fs_visitor::optimize()
int iteration = 0;
int pass_num = 0;
 
+   /* Before anything else, eliminate dead code.  The results of some NIR
+* instructions may effectively be calculated twice.  Once when the
+* instruction is encountered, and again when the user of that result is
+* encountered.  Wipe those away before algebraic optimizations and
+* especially copy propagation can mix things up.
+*/
+   OPT(dead_code_eliminate);
+
OPT(remove_extra_rounding_modes);
 
do {
-- 
2.14.4

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

[Mesa-dev] [PATCH 04/11] intel/compiler: Don't handle fsign.sat

[Ian Romanick]

From: Ian Romanick 

No shader-db or CI changes on any Intel platform.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs_nir.cpp   | 14 +-
 src/intel/compiler/brw_vec4_nir.cpp | 12 ++--
 2 files changed, 3 insertions(+), 23 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 7f453d75b64..12b087a5ec0 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -842,6 +842,7 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
   break;
 
case nir_op_fsign: {
+  assert(!instr->dest.saturate);
   if (op[0].abs) {
  /* Straightforward since the source can be assumed to be either
   * strictly >= 0 or strictly <= 0 depending on the setting of the
@@ -854,10 +855,6 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
 : bld.MOV(result, brw_imm_f(1.0f));
 
  set_predicate(BRW_PREDICATE_NORMAL, inst);
-
- if (instr->dest.saturate)
-inst->saturate = true;
-
   } else if (type_sz(op[0].type) < 8) {
  /* AND(val, 0x8000) gives the sign bit.
   *
@@ -873,10 +870,6 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
 
  inst = bld.OR(result_int, result_int, brw_imm_ud(0x3f80u));
  inst->predicate = BRW_PREDICATE_NORMAL;
- if (instr->dest.saturate) {
-inst = bld.MOV(result, result);
-inst->saturate = true;
- }
   } else {
  /* For doubles we do the same but we need to consider:
   *
@@ -897,11 +890,6 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
 
  set_predicate(BRW_PREDICATE_NORMAL,
bld.OR(r, r, brw_imm_ud(0x3ff0u)));
-
- if (instr->dest.saturate) {
-inst = bld.MOV(result, result);
-inst->saturate = true;
- }
   }
   break;
}
diff --git a/src/intel/compiler/brw_vec4_nir.cpp 
b/src/intel/compiler/brw_vec4_nir.cpp
index 124714b59de..eaf1754b006 100644
--- a/src/intel/compiler/brw_vec4_nir.cpp
+++ b/src/intel/compiler/brw_vec4_nir.cpp
@@ -1818,6 +1818,7 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
   unreachable("not reached: should have been lowered");
 
case nir_op_fsign:
+  assert(!instr->dest.saturate);
   if (op[0].abs) {
  /* Straightforward since the source can be assumed to be either
   * strictly >= 0 or strictly <= 0 depending on the setting of the
@@ -1830,10 +1831,6 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
 ? emit(MOV(dst, brw_imm_f(-1.0f)))
 : emit(MOV(dst, brw_imm_f(1.0f)));
  inst->predicate = BRW_PREDICATE_NORMAL;
-
- if (instr->dest.saturate)
-inst->saturate = true;
-
} else if (type_sz(op[0].type) < 8) {
  /* AND(val, 0x8000) gives the sign bit.
   *
@@ -1849,11 +1846,6 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
  inst = emit(OR(dst, src_reg(dst), brw_imm_ud(0x3f80u)));
  inst->predicate = BRW_PREDICATE_NORMAL;
  dst.type = BRW_REGISTER_TYPE_F;
-
- if (instr->dest.saturate) {
-inst = emit(MOV(dst, src_reg(dst)));
-inst->saturate = true;
- }
   } else {
  /* For doubles we do the same but we need to consider:
   *
@@ -1886,7 +1878,7 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
  /* Now convert the result from float to double */
  emit_conversion_to_double(dst, retype(src_reg(tmp),
BRW_REGISTER_TYPE_F),
-   instr->dest.saturate);
+   false);
   }
   break;
 
-- 
2.14.4

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

[Mesa-dev] [PATCH 10/11] nir/algebraic: Replace a pattern where iand with a Boolean is used as a bcsel

[Ian Romanick]

From: Ian Romanick 

All of the affected shaders are in Mad Max.  I noticed this while
looking at some other things.  I tried a couple similar patterns, but
the affect on cycles was general negative.  It may be worth revisiting
this later.

All Gen7+ platforms had similar results. (Skylake shown)
total instructions in shared programs: 15090929 -> 15090909 (<.01%)
instructions in affected programs: 1192 -> 1172 (-1.68%)
helped: 14
HURT: 0
helped stats (abs) min: 1 max: 2 x̄: 1.43 x̃: 1
helped stats (rel) min: 1.16% max: 2.17% x̄: 1.65% x̃: 1.39%
95% mean confidence interval for instructions value: -1.73 -1.13
95% mean confidence interval for instructions %-change: -1.91% -1.38%
Instructions are helped.

total cycles in shared programs: 565826044 -> 565824622 (<.01%)
cycles in affected programs: 11477 -> 10055 (-12.39%)
helped: 14
HURT: 0
helped stats (abs) min: 76 max: 122 x̄: 101.57 x̃: 104
helped stats (rel) min: 7.76% max: 15.62% x̄: 12.94% x̃: 14.78%
95% mean confidence interval for cycles value: -111.05 -92.09
95% mean confidence interval for cycles %-change: -14.90% -10.98%
Cycles are helped.

No changes on any Gen6 or earlier platforms.

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

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 6d963cede93..cada08d274d 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -34,6 +34,7 @@ a = 'a'
 b = 'b'
 c = 'c'
 d = 'd'
+e = 'e'
 
 # Written in the form (, ) where  is an expression
 # and  is either an expression or a value.  An expression is
@@ -133,6 +134,9 @@ optimizations = [
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
 
+   (('~fmul', ('fadd', ('iand', 'a@bool', ('fmul', b, c)), '#d'), '#e'),
+('bcsel', a, ('fmul', ('fadd', ('fmul', b, c), d), e), ('fmul', d, e))),
+
(('fdot4', ('vec4', a, b,   c,   1.0), d), ('fdph',  ('vec3', a, b, c), d)),
(('fdot4', ('vec4', a, 0.0, 0.0, 0.0), b), ('fmul', a, b)),
(('fdot4', ('vec4', a, b,   0.0, 0.0), c), ('fdot2', ('vec2', a, b), c)),
-- 
2.14.4

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

[Mesa-dev] [PATCH 11/11] nir/algebraic: Recognize open-coded fsign

[Ian Romanick]

From: Ian Romanick 

I don't intend to push this.  The results are pretty horrifying.

Broadwell
total instructions in shared programs: 15387998 -> 15383192 (-0.03%)
instructions in affected programs: 1223940 -> 1219134 (-0.39%)
helped: 700
HURT: 63
helped stats (abs) min: 1 max: 81 x̄: 7.68 x̃: 5
helped stats (rel) min: 0.14% max: 4.76% x̄: 0.77% x̃: 0.45%
HURT stats (abs)   min: 4 max: 83 x̄: 9.03 x̃: 6
HURT stats (rel)   min: 0.13% max: 4.02% x̄: 0.34% x̃: 0.20%
95% mean confidence interval for instructions value: -6.95 -5.64
95% mean confidence interval for instructions %-change: -0.72% -0.63%
Instructions are helped.

total cycles in shared programs: 600707435 -> 601996933 (0.21%)
cycles in affected programs: 137816437 -> 139105935 (0.94%)
helped: 195
HURT: 529
helped stats (abs) min: 1 max: 3666 x̄: 159.20 x̃: 18
helped stats (rel) min: 0.01% max: 32.80% x̄: 1.53% x̃: 0.46%
HURT stats (abs)   min: 1 max: 6711 x̄: 2496.30 x̃: 2865
HURT stats (rel)   min: <.01% max: 7.48% x̄: 1.15% x̃: 1.03%
95% mean confidence interval for cycles value: 1622.18 1939.97
95% mean confidence interval for cycles %-change: 0.26% 0.60%
Cycles are HURT.

total spills in shared programs: 80928 -> 81130 (0.25%)
spills in affected programs: 15915 -> 16117 (1.27%)
helped: 18
HURT: 63

total fills in shared programs: 93056 -> 93069 (0.01%)
fills in affected programs: 16050 -> 16063 (0.08%)
helped: 18
HURT: 63

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

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index cada08d274d..984aa0ee35d 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -381,6 +381,10 @@ optimizations = [
# so emit an open-coded version of that.
(('bcsel@32', ('feq', a, 0.0), 1.0, ('i2f32', ('iadd', ('ineg', ('flt', 
0.0, 'a@32')), ('flt', 'a@32', 0.0,
 ('ior', 0x3f80, ('iand', a, 0x8000))),
+   (('bcsel@32', ('feq', a, 0.0), 1.0, ('fsign', a)),
+('ior', 0x3f80, ('iand', a, 0x8000))),
+
+   (('i2f32', ('iadd', ('ineg', ('flt', 0.0, 'a@32')), ('flt', 'a@32', 0.0))), 
('fsign', a)),
 
(('ior', 'a@bool', ('ieq', a, False)), True),
(('ior', 'a@bool', ('inot', a)), True),
-- 
2.14.4

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

[Mesa-dev] [PATCH 08/11] i965/fs: Generate better code for fsign multiplied by a value

[Ian Romanick]

From: Ian Romanick 

shader-db results:

Broadwell and Skylake had similar results. (Skylake shown)
total instructions in shared programs: 15105981 -> 15090997 (-0.10%)
instructions in affected programs: 977852 -> 962868 (-1.53%)
helped: 4531
HURT: 0
helped stats (abs) min: 1 max: 221 x̄: 3.31 x̃: 2
helped stats (rel) min: 0.07% max: 10.00% x̄: 1.83% x̃: 1.33%
95% mean confidence interval for instructions value: -3.49 -3.13
95% mean confidence interval for instructions %-change: -1.86% -1.79%
Instructions are helped.

total cycles in shared programs: 566053975 -> 565827580 (-0.04%)
cycles in affected programs: 14922172 -> 14695777 (-1.52%)
helped: 4373
HURT: 125
helped stats (abs) min: 1 max: 6190 x̄: 54.16 x̃: 28
helped stats (rel) min: 0.01% max: 29.14% x̄: 2.74% x̃: 2.31%
HURT stats (abs)   min: 1 max: 1836 x̄: 83.53 x̃: 44
HURT stats (rel)   min: 0.01% max: 34.36% x̄: 2.85% x̃: 1.64%
95% mean confidence interval for cycles value: -55.94 -44.73
95% mean confidence interval for cycles %-change: -2.64% -2.52%
Cycles are helped.

total spills in shared programs: 11085 -> 11084 (<.01%)
spills in affected programs: 49 -> 48 (-2.04%)
helped: 1
HURT: 0

total fills in shared programs: 23143 -> 23142 (<.01%)
fills in affected programs: 92 -> 91 (-1.09%)
helped: 1
HURT: 0

Haswell
total instructions in shared programs: 13682846 -> 13671160 (-0.09%)
instructions in affected programs: 726095 -> 714409 (-1.61%)
helped: 3478
HURT: 0
helped stats (abs) min: 1 max: 221 x̄: 3.36 x̃: 2
helped stats (rel) min: 0.07% max: 10.64% x̄: 1.94% x̃: 1.47%
95% mean confidence interval for instructions value: -3.58 -3.14
95% mean confidence interval for instructions %-change: -1.99% -1.89%
Instructions are helped.

total cycles in shared programs: 449604795 -> 449445686 (-0.04%)
cycles in affected programs: 11722803 -> 11563694 (-1.36%)
helped: 3310
HURT: 138
helped stats (abs) min: 1 max: 1780 x̄: 49.75 x̃: 18
helped stats (rel) min: <.01% max: 29.13% x̄: 2.21% x̃: 1.72%
HURT stats (abs)   min: 1 max: 258 x̄: 40.31 x̃: 18
HURT stats (rel)   min: <.01% max: 15.30% x̄: 1.79% x̃: 0.79%
95% mean confidence interval for cycles value: -50.65 -41.64
95% mean confidence interval for cycles %-change: -2.12% -1.98%
Cycles are helped.

LOST:   1
GAINED: 0

Ivy Bridge
total instructions in shared programs: 12030700 -> 12023562 (-0.06%)
instructions in affected programs: 638233 -> 631095 (-1.12%)
helped: 2498
HURT: 0
helped stats (abs) min: 1 max: 39 x̄: 2.86 x̃: 2
helped stats (rel) min: 0.05% max: 10.00% x̄: 1.28% x̃: 1.02%
95% mean confidence interval for instructions value: -2.96 -2.75
95% mean confidence interval for instructions %-change: -1.32% -1.24%
Instructions are helped.

total cycles in shared programs: 256243891 -> 256115699 (-0.05%)
cycles in affected programs: 11801287 -> 11673095 (-1.09%)
helped: 2433
HURT: 53
helped stats (abs) min: 1 max: 1348 x̄: 56.44 x̃: 26
helped stats (rel) min: 0.01% max: 24.56% x̄: 1.90% x̃: 1.53%
HURT stats (abs)   min: 1 max: 5364 x̄: 172.36 x̃: 39
HURT stats (rel)   min: 0.03% max: 51.96% x̄: 3.57% x̃: 1.18%
95% mean confidence interval for cycles value: -58.76 -44.38
95% mean confidence interval for cycles %-change: -1.86% -1.70%
Cycles are helped.

Sandy Bridge
total instructions in shared programs: 10831556 -> 10831527 (<.01%)
instructions in affected programs: 3777 -> 3748 (-0.77%)
helped: 17
HURT: 0
helped stats (abs) min: 1 max: 4 x̄: 1.71 x̃: 1
helped stats (rel) min: 0.13% max: 9.52% x̄: 3.58% x̃: 2.73%
95% mean confidence interval for instructions value: -2.27 -1.14
95% mean confidence interval for instructions %-change: -5.14% -2.03%
Instructions are helped.

total cycles in shared programs: 154504015 -> 154503922 (<.01%)
cycles in affected programs: 47336 -> 47243 (-0.20%)
helped: 15
HURT: 8
helped stats (abs) min: 1 max: 81 x̄: 16.13 x̃: 4
helped stats (rel) min: 0.01% max: 10.59% x̄: 1.54% x̃: 0.73%
HURT stats (abs)   min: 14 max: 33 x̄: 18.62 x̃: 17
HURT stats (rel)   min: 0.33% max: 2.78% x̄: 2.42% x̃: 2.71%
95% mean confidence interval for cycles value: -15.10 7.01
95% mean confidence interval for cycles %-change: -1.41% 1.08%
Inconclusive result (value mean confidence interval includes 0).

Iron Lake
total instructions in shared programs: 8207937 -> 8207823 (<.01%)
instructions in affected programs: 9392 -> 9278 (-1.21%)
helped: 48
HURT: 0
helped stats (abs) min: 1 max: 11 x̄: 2.38 x̃: 2
helped stats (rel) min: 0.15% max: 7.02% x̄: 2.02% x̃: 1.46%
95% mean confidence interval for instructions value: -3.05 -1.70
95% mean confidence interval for instructions %-change: -2.47% -1.57%
Instructions are helped.

total cycles in shared programs: 187478820 -> 187478330 (<.01%)
cycles in affected programs: 260626 -> 260136 (-0.19%)
helped: 34
HURT: 11
helped stats (abs) min: 2 max: 134 x̄: 15.41 x̃: 7
helped stats (rel) min: 0.03% max: 5.62% x̄: 0.75% x̃: 0.14%
HURT stats (abs)   min: 2 max: 8 x̄: 3.09 x̃: 2
HURT stats (rel)   min: 0.12% max: 0.86% x̄: 0.32% x̃: 0.28%
95% mean confidence 

[Mesa-dev] [PATCH 07/11] i965/fs: Add a scale factor to emit_fsign

[Ian Romanick]

From: Ian Romanick 

Normally fsign generates -1, 0, or +1.  The new scale factor, S, causes
fsign to generate -S, 0, or +S.

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs.h   |  3 +-
 src/intel/compiler/brw_fs_nir.cpp | 61 +++
 2 files changed, 51 insertions(+), 13 deletions(-)

diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index c45f0f608fc..8169498bf5e 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -186,7 +186,8 @@ public:
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg resolve_source_modifiers(const fs_reg );
void emit_discard_jump();
-   void emit_fsign(const class brw::fs_builder &, const nir_alu_instr *instr);
+   void emit_fsign(const class brw::fs_builder &, const nir_alu_instr *instr,
+   unsigned fsign_src);
bool opt_peephole_sel();
bool opt_peephole_csel();
bool opt_peephole_predicated_break();
diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index d0f25e96c3e..ef4c41da132 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -670,14 +670,19 @@ brw_rnd_mode_from_nir_op (const nir_op op) {
 }
 
 /**
- * Emit code for nir_op_fsign
+ * Emit code for nir_op_fsign possibly fused with a nir_op_fmul
+ *
+ * If \c instr is not the \c nir_op_fsign, then \c fsign_src is the index of
+ * the source of \c instr that is a \c nir_op_fsign.
  */
 void
-fs_visitor::emit_fsign(const fs_builder , const nir_alu_instr *instr)
+fs_visitor::emit_fsign(const fs_builder , const nir_alu_instr *instr,
+   unsigned fsign_src)
 {
fs_inst *inst;
 
-   assert(instr->op == nir_op_fsign);
+   assert(instr->op == nir_op_fsign || instr->op == nir_op_fmul);
+   assert(fsign_src < nir_op_infos[instr->op].num_inputs);
 
fs_reg result = get_nir_dest(instr->dest.dest);
result.type = brw_type_for_nir_type(devinfo,
@@ -685,9 +690,18 @@ fs_visitor::emit_fsign(const fs_builder , const 
nir_alu_instr *instr)
  nir_dest_bit_size(instr->dest.dest)));
 
const nir_alu_src *sources[2] = { >src[0], NULL };
-   const unsigned num_sources = 1;
+   const unsigned num_sources = instr->op == nir_op_fsign ? 1 : 2;
fs_reg op[2];
 
+   if (instr->op != nir_op_fsign) {
+  const nir_alu_instr *const fsign_instr =
+ nir_src_as_alu_instr((nir_src *) >src[fsign_src].src);
+
+  assert(!fsign_instr->dest.saturate);
+  sources[0] = _instr->src[0];
+  sources[1] = >src[1 - fsign_src];
+   }
+
for (unsigned i = 0; i < num_sources; i++) {
   op[i] = get_nir_src(sources[i]->src);
 
@@ -714,16 +728,20 @@ fs_visitor::emit_fsign(const fs_builder , const 
nir_alu_instr *instr)
for (unsigned i = 0; i < num_sources; i++)
   op[i] = offset(op[i], bld, sources[i]->swizzle[channel]);
 
-   assert(!instr->dest.saturate);
if (op[0].abs) {
   /* Straightforward since the source can be assumed to be either strictly
* >= 0 or strictly <= 0 depending on the setting of the negate flag.
*/
   set_condmod(BRW_CONDITIONAL_NZ, bld.MOV(result, op[0]));
 
-  inst = (op[0].negate)
- ? bld.MOV(result, brw_imm_f(-1.0f))
- : bld.MOV(result, brw_imm_f(1.0f));
+  if (sources[1] == NULL) {
+ inst = (op[0].negate)
+? bld.MOV(result, brw_imm_f(-1.0f))
+: bld.MOV(result, brw_imm_f(1.0f));
+  } else {
+ op[1].negate = (op[0].negate != op[1].negate);
+ inst = bld.MOV(result, op[1]);
+  }
 
   set_predicate(BRW_PREDICATE_NORMAL, inst);
} else if (type_sz(op[0].type) < 8) {
@@ -739,7 +757,14 @@ fs_visitor::emit_fsign(const fs_builder , const 
nir_alu_instr *instr)
   result.type = BRW_REGISTER_TYPE_UD;
   bld.AND(result_int, op[0], brw_imm_ud(0x8000u));
 
-  inst = bld.OR(result_int, result_int, brw_imm_ud(0x3f80u));
+  if (sources[1] == NULL)
+ inst = bld.OR(result_int, result_int, brw_imm_ud(0x3f80u));
+  else {
+ /* Use XOR here to get the result sign correct. */
+ inst = bld.XOR(result_int, result_int,
+retype(op[1], BRW_REGISTER_TYPE_UD));
+  }
+
   inst->predicate = BRW_PREDICATE_NORMAL;
} else {
   /* For doubles we do the same but we need to consider:
@@ -759,8 +784,20 @@ fs_visitor::emit_fsign(const fs_builder , const 
nir_alu_instr *instr)
   bld.AND(r, subscript(op[0], BRW_REGISTER_TYPE_UD, 1),
   brw_imm_ud(0x8000u));
 
-  set_predicate(BRW_PREDICATE_NORMAL,
-bld.OR(r, r, brw_imm_ud(0x3ff0u)));
+  if (sources[1] == NULL) {
+ set_predicate(BRW_PREDICATE_NORMAL,
+   bld.OR(r, r, brw_imm_ud(0x3ff0u)));
+  } else {
+ /* This could be done better in some cases.  If the scale is an
+  * immediate with the low 32-bits all 0, emitting a separate XOR and
+  

[Mesa-dev] [PATCH 00/11] intel/compiler: Optimize sign(x)*y

[Ian Romanick]

This series implements a code-generation optimization for sign(x)*y.  In
GLSL, sign(x) is defined as:

Returns 1.0 if x > 0, 0.0 if x = 0, or -1.0 if x < 0.

It is silent on the NaN behavior, so I have taken it as "undefined."  I
don't think the new implementation will produce different results from
the old.

The optimization is only applied to the scalar backend.  On Skylake,
there are ~1,000 shaders in VS, TCS, and TES stages helped.  It may be
worth applying this to the vector backend for Haswell.  I have a couple
long flights in my near future, so I might work on it then.  We'll see.
This might also be a good newbie projet for someone wanting to get into
the i965 compiler backend.

There are actually two versions of this series.  The series that I am
sending to the list includes "i965/fs: Eliminate dead code first".  The
results of that patch is not good.  The other version of the series
omits that patch, but it adds a bunch of horror to "i965/fs: Add a scale
factor to emit_fsign".  Basically, if both the fused and non-fused
version of the nir_op_fsign are emitted, copy propagation will propagate
part of the common expressions, but, due to the predicated OR or XOR,
one extra MOV will be left around.  That single instruction ruins the
whole optimization.

Both versions are available in my cgit.  List version:

https://cgit.freedesktop.org/~idr/mesa/log/?h=fsign-optimization

That branch includes a few things that I tried, but they did not pan
out.

Alternate version:


https://cgit.freedesktop.org/~idr/mesa/log/?h=fsign-optimization-emit-no-dead-code

I think the version sent to the list is cleaner, but it's shader-db
results are not as good.  The difference between the list version and
the other version on Skylake is shown below.  Other platforms had
similar shaped results.

total instructions in shared programs: 15090997 -> 15091028 (<.01%)
instructions in affected programs: 10251 -> 10282 (0.30%)
helped: 0
HURT: 26
HURT stats (abs)   min: 1 max: 4 x̄: 1.19 x̃: 1
HURT stats (rel)   min: 0.14% max: 1.96% x̄: 0.49% x̃: 0.24%
95% mean confidence interval for instructions value: 0.94 1.45
95% mean confidence interval for instructions %-change: 0.28% 0.71%
Instructions are HURT.

total cycles in shared programs: 565827580 -> 565824007 (<.01%)
cycles in affected programs: 1995745 -> 1992172 (-0.18%)
helped: 271
HURT: 248
helped stats (abs) min: 1 max: 623 x̄: 25.79 x̃: 5
helped stats (rel) min: 0.02% max: 13.19% x̄: 0.94% x̃: 0.28%
HURT stats (abs)   min: 1 max: 204 x̄: 13.78 x̃: 4
HURT stats (rel)   min: 0.01% max: 6.57% x̄: 0.52% x̃: 0.21%
95% mean confidence interval for cycles value: -11.25 -2.52
95% mean confidence interval for cycles %-change: -0.38% -0.11%
Cycles are helped.

The version sent to the list saves a couple instructions in 26 shaders,
but cycles are hurt.  The list version also avoids ~65 lines of ugly
code.

I also sent a couple tests to the piglit list that exersice a bug that I
had during development.

https://patchwork.freedesktop.org/patch/247911/

In the alternate version, for an expression like sign(a)*sign(b),
sign(b) would never get emitted.  When the fused sign(a)*x was emitted,
it would explode.  The solution was to just bail on the optimization
when sign(a)*sign(b) is encountered.  I suspect that's the source of the
32 shaders with instructions hurt in the alternate version, but I have
not verified that.

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

[Mesa-dev] [PATCH 03/11] nir/algebraic: Simplify fsat of fsign

[Ian Romanick]

From: Ian Romanick 

These allows us to not support fsign.sat in the Intel compiler backend,
and that will simplify some later changes.

No shader-db changes on any Intel platform.

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

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 3267e93a583..422a8794d38 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -329,6 +329,7 @@ optimizations = [
(('imax', a, ('ineg', a)), ('iabs', a)),
(('~fmin', ('fmax', a, 0.0), 1.0), ('fsat', a), '!options->lower_fsat'),
(('~fmax', ('fmin', a, 1.0), 0.0), ('fsat', a), '!options->lower_fsat'),
+   (('fsat', ('fsign', a)), ('b2f', ('flt', 0.0, a))),
(('fsat', a), ('fmin', ('fmax', a, 0.0), 1.0), 'options->lower_fsat'),
(('fsat', ('fsat', a)), ('fsat', a)),
(('fmin', ('fmax', ('fmin', ('fmax', a, b), c), b), c), ('fmin', ('fmax', 
a, b), c)),
-- 
2.14.4

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

[Mesa-dev] [PATCH 06/11] i965/fs: Refactor code generation for nir_op_fsign to its own function

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/intel/compiler/brw_fs.h   |   1 +
 src/intel/compiler/brw_fs_nir.cpp | 154 +-
 2 files changed, 103 insertions(+), 52 deletions(-)

diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index aba19d5ab2c..c45f0f608fc 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -186,6 +186,7 @@ public:
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg resolve_source_modifiers(const fs_reg );
void emit_discard_jump();
+   void emit_fsign(const class brw::fs_builder &, const nir_alu_instr *instr);
bool opt_peephole_sel();
bool opt_peephole_csel();
bool opt_peephole_predicated_break();
diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index 12b087a5ec0..d0f25e96c3e 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -669,9 +669,109 @@ brw_rnd_mode_from_nir_op (const nir_op op) {
}
 }
 
+/**
+ * Emit code for nir_op_fsign
+ */
+void
+fs_visitor::emit_fsign(const fs_builder , const nir_alu_instr *instr)
+{
+   fs_inst *inst;
+
+   assert(instr->op == nir_op_fsign);
+
+   fs_reg result = get_nir_dest(instr->dest.dest);
+   result.type = brw_type_for_nir_type(devinfo,
+  (nir_alu_type)(nir_op_infos[instr->op].output_type |
+ nir_dest_bit_size(instr->dest.dest)));
+
+   const nir_alu_src *sources[2] = { >src[0], NULL };
+   const unsigned num_sources = 1;
+   fs_reg op[2];
+
+   for (unsigned i = 0; i < num_sources; i++) {
+  op[i] = get_nir_src(sources[i]->src);
+
+  const nir_alu_type t =
+ (nir_alu_type)(nir_op_infos[instr->op].input_types[i] |
+nir_src_bit_size(sources[i]->src));
+
+  op[i].type = brw_type_for_nir_type(devinfo, t);
+  op[i].abs = sources[i]->abs;
+  op[i].negate = sources[i]->negate;
+   }
+
+   unsigned channel = 0;
+   if (nir_op_infos[instr->op].output_size == 0) {
+  /* Since NIR is doing the scalarizing for us, we should only ever see
+   * vectorized operations with a single channel.
+   */
+  assert(util_bitcount(instr->dest.write_mask) == 1);
+  channel = ffs(instr->dest.write_mask) - 1;
+
+  result = offset(result, bld, channel);
+   }
+
+   for (unsigned i = 0; i < num_sources; i++)
+  op[i] = offset(op[i], bld, sources[i]->swizzle[channel]);
+
+   assert(!instr->dest.saturate);
+   if (op[0].abs) {
+  /* Straightforward since the source can be assumed to be either strictly
+   * >= 0 or strictly <= 0 depending on the setting of the negate flag.
+   */
+  set_condmod(BRW_CONDITIONAL_NZ, bld.MOV(result, op[0]));
+
+  inst = (op[0].negate)
+ ? bld.MOV(result, brw_imm_f(-1.0f))
+ : bld.MOV(result, brw_imm_f(1.0f));
+
+  set_predicate(BRW_PREDICATE_NORMAL, inst);
+   } else if (type_sz(op[0].type) < 8) {
+  /* AND(val, 0x8000) gives the sign bit.
+   *
+   * Predicated OR ORs 1.0 (0x3f80) with the sign bit if val is not
+   * zero.
+   */
+  bld.CMP(bld.null_reg_f(), op[0], brw_imm_f(0.0f), BRW_CONDITIONAL_NZ);
+
+  fs_reg result_int = retype(result, BRW_REGISTER_TYPE_UD);
+  op[0].type = BRW_REGISTER_TYPE_UD;
+  result.type = BRW_REGISTER_TYPE_UD;
+  bld.AND(result_int, op[0], brw_imm_ud(0x8000u));
+
+  inst = bld.OR(result_int, result_int, brw_imm_ud(0x3f80u));
+  inst->predicate = BRW_PREDICATE_NORMAL;
+   } else {
+  /* For doubles we do the same but we need to consider:
+   *
+   * - 2-src instructions can't operate with 64-bit immediates
+   * - The sign is encoded in the high 32-bit of each DF
+   * - We need to produce a DF result.
+   */
+
+  fs_reg zero = vgrf(glsl_type::double_type);
+  bld.MOV(zero, setup_imm_df(bld, 0.0));
+  bld.CMP(bld.null_reg_df(), op[0], zero, BRW_CONDITIONAL_NZ);
+
+  bld.MOV(result, zero);
+
+  fs_reg r = subscript(result, BRW_REGISTER_TYPE_UD, 1);
+  bld.AND(r, subscript(op[0], BRW_REGISTER_TYPE_UD, 1),
+  brw_imm_ud(0x8000u));
+
+  set_predicate(BRW_PREDICATE_NORMAL,
+bld.OR(r, r, brw_imm_ud(0x3ff0u)));
+   }
+}
+
 void
 fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr)
 {
+   if (instr->op == nir_op_fsign) {
+  emit_fsign(bld, instr);
+  return;
+   }
+
struct brw_wm_prog_key *fs_key = (struct brw_wm_prog_key *) this->key;
fs_inst *inst;
 
@@ -841,58 +941,8 @@ fs_visitor::nir_emit_alu(const fs_builder , 
nir_alu_instr *instr)
   inst->saturate = instr->dest.saturate;
   break;
 
-   case nir_op_fsign: {
-  assert(!instr->dest.saturate);
-  if (op[0].abs) {
- /* Straightforward since the source can be assumed to be either
-  * strictly >= 0 or strictly <= 0 depending on the setting of the
-  * negate flag.
-  */
- 

[Mesa-dev] [PATCH 09/11] nir/algebraic: Recognize open-coded copysign(a, 1.0)

[Ian Romanick]

From: Ian Romanick 

All of the affected shaders are in Mad Max.  The inner part of the
pattern is itself an open-coded sign(a).  I tried using that as a
pattern, but the results were not good.  A bunch of shaders were helped
for instructions, but overall cycles, spill, and fills were hurt.

All Gen7+ platforms had similar results. (Skylake shown)
total instructions in shared programs: 15090997 -> 15090929 (<.01%)
instructions in affected programs: 6157 -> 6089 (-1.10%)
helped: 17
HURT: 0
helped stats (abs) min: 4 max: 4 x̄: 4.00 x̃: 4
helped stats (rel) min: 1.01% max: 2.16% x̄: 1.14% x̃: 1.06%
95% mean confidence interval for instructions value: -4.00 -4.00
95% mean confidence interval for instructions %-change: -1.29% -1.00%
Instructions are helped.

total cycles in shared programs: 565827580 -> 565826044 (<.01%)
cycles in affected programs: 32387 -> 30851 (-4.74%)
helped: 17
HURT: 0
helped stats (abs) min: 21 max: 213 x̄: 90.35 x̃: 50
helped stats (rel) min: 1.37% max: 21.69% x̄: 5.10% x̃: 2.60%
95% mean confidence interval for cycles value: -127.73 -52.97
95% mean confidence interval for cycles %-change: -7.78% -2.41%
Cycles are helped.

No changes on any Gen6 or earlier platforms.

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

diff --git a/src/compiler/nir/nir_opt_algebraic.py 
b/src/compiler/nir/nir_opt_algebraic.py
index 422a8794d38..6d963cede93 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -372,6 +372,12 @@ optimizations = [
(('iand', ('uge(is_used_once)', a, b), ('uge', a, c)), ('uge', a, ('umax', 
b, c))),
(('iand', ('uge(is_used_once)', a, c), ('uge', b, c)), ('uge', ('umin', a, 
b), c)),
 
+   # The (i2f32, ...) part is an open-coded fsign.  When that is combined with
+   # the bcsel, it's basically copysign(a, 1.0).  There is no copysign in NIR,
+   # so emit an open-coded version of that.
+   (('bcsel@32', ('feq', a, 0.0), 1.0, ('i2f32', ('iadd', ('ineg', ('flt', 
0.0, 'a@32')), ('flt', 'a@32', 0.0,
+('ior', 0x3f80, ('iand', a, 0x8000))),
+
(('ior', 'a@bool', ('ieq', a, False)), True),
(('ior', 'a@bool', ('inot', a)), True),
 
-- 
2.14.4

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

[Mesa-dev] [PATCH 01/11] nir: Add helper functions to get the instruction that generated a nir_src

[Ian Romanick]

From: Ian Romanick 

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

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index bf4bd916d27..69ca1215644 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -2490,6 +2490,29 @@ bool nir_foreach_dest(nir_instr *instr, 
nir_foreach_dest_cb cb, void *state);
 bool nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state);
 
 nir_const_value *nir_src_as_const_value(nir_src src);
+
+static inline struct nir_instr *
+nir_src_instr(const struct nir_src *src)
+{
+   return src->is_ssa ? src->ssa->parent_instr : NULL;
+}
+
+#define NIR_SRC_AS_(name, c_type, type_enum, cast_macro)\
+static inline c_type *  \
+nir_src_as_ ## name (struct nir_src *src)   \
+{   \
+return src->is_ssa && src->ssa->parent_instr->type == type_enum \
+   ? cast_macro(src->ssa->parent_instr) : NULL; \
+}   \
+static inline const c_type *\
+nir_src_as_ ## name ## _const(const struct nir_src *src)\
+{   \
+return src->is_ssa && src->ssa->parent_instr->type == type_enum \
+   ? cast_macro(src->ssa->parent_instr) : NULL; \
+}
+
+NIR_SRC_AS_(alu_instr, nir_alu_instr, nir_instr_type_alu, nir_instr_as_alu)
+
 bool nir_src_is_dynamically_uniform(nir_src src);
 bool nir_srcs_equal(nir_src src1, nir_src src2);
 void nir_instr_rewrite_src(nir_instr *instr, nir_src *src, nir_src new_src);
-- 
2.14.4

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

[Mesa-dev] [PATCH] intel/icl: Fix URB size for different SKUs

[Anuj Phogat]

Different ICL SKUs have different URB sizes.

Signed-off-by: Anuj Phogat 
---
 src/intel/dev/gen_device_info.c | 43 ++---
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 3cece52a041..e2c6cbc7101 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -872,20 +872,7 @@ static const struct gen_device_info 
gen_device_info_cnl_5x8 = {
.max_gs_threads = 224,   \
.max_tcs_threads = 224,  \
.max_tes_threads = 364,  \
-   .max_cs_threads = 56,\
-   .urb = { \
-  .size = 1024, \
-  .min_entries = {  \
- [MESA_SHADER_VERTEX]= 64,  \
- [MESA_SHADER_TESS_EVAL] = 34,  \
-  },\
-  .max_entries = {  \
- [MESA_SHADER_VERTEX]= 2384,\
- [MESA_SHADER_TESS_CTRL] = 1032,\
- [MESA_SHADER_TESS_EVAL] = 2384,\
- [MESA_SHADER_GEOMETRY]  = 1032,\
-  },\
-   }
+   .max_cs_threads = 56
 
 #define GEN11_FEATURES(_gt, _slices, _subslices, _l3) \
GEN8_FEATURES, \
@@ -897,23 +884,51 @@ static const struct gen_device_info 
gen_device_info_cnl_5x8 = {
.num_subslices = _subslices,   \
.num_eu_per_subslice = 8
 
+#define GEN11_URB_MIN_MAX_ENTRIES \
+   .min_entries = {   \
+  [MESA_SHADER_VERTEX]= 64,   \
+  [MESA_SHADER_TESS_EVAL] = 34,   \
+   }, \
+   .max_entries = {   \
+  [MESA_SHADER_VERTEX]= 2384, \
+  [MESA_SHADER_TESS_CTRL] = 1032, \
+  [MESA_SHADER_TESS_EVAL] = 2384, \
+  [MESA_SHADER_GEOMETRY]  = 1032, \
+   }
+
 static const struct gen_device_info gen_device_info_icl_8x8 = {
GEN11_FEATURES(2, 1, subslices(8), 8),
+   .urb = {
+  .size = 1024,
+  GEN11_URB_MIN_MAX_ENTRIES,
+   },
.simulator_id = 19,
 };
 
 static const struct gen_device_info gen_device_info_icl_6x8 = {
GEN11_FEATURES(1, 1, subslices(6), 6),
+   .urb = {
+  .size = 768,
+  GEN11_URB_MIN_MAX_ENTRIES,
+   },
.simulator_id = 19,
 };
 
 static const struct gen_device_info gen_device_info_icl_4x8 = {
GEN11_FEATURES(1, 1, subslices(4), 6),
+   .urb = {
+  .size = 768,
+  GEN11_URB_MIN_MAX_ENTRIES,
+   },
.simulator_id = 19,
 };
 
 static const struct gen_device_info gen_device_info_icl_1x8 = {
GEN11_FEATURES(1, 1, subslices(1), 6),
+   .urb = {
+  .size = 768,
+  GEN11_URB_MIN_MAX_ENTRIES,
+   },
.simulator_id = 19,
 };
 
-- 
2.17.1

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

[Mesa-dev] [Bug 107873] Doom 2016 - Rendering issues

[bugzilla-daemon]

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

--- Comment #4 from Ahmed Elsayed  ---
I tried also Mesa 18.3 and I have the same problem.

-- 
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] [RFC 6/7] HACK: Disable the instruction scheduler

[Ian Romanick]

On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> The instruction scheduler is re-ordering loads which is causing fence
> values to be loaded after the value they're fencing.  In particular,
> consider the following pseudocode:
> 
> void try_use_a_thing(int idx)
> {
> bool ready = ssbo.arr[idx].ready;
> vec4 data = ssbo.arr[idx].data;
> if (ready)
> use(data);
> }
> 
> void write_a_thing(int idx, vec4 data)
> {
> ssbo.arr[idx].data = data;
> ssbo.arr[idx].ready = true;
> }
> 
> Our current instruction scheduling scheme doesn't see any problem with
> re-ordering the load of "ready" with respect to the load of "data".
> However, if try_use_a_thing is called in one thread and write_a_thing is
> called in another thread, such re-ordering could cause invalid data to
> be used.  Normally, some re-ordering of loads is fine; however, with the
> Vulkan memory model, there are some additional guarantees that are
> provided particularly in the case of atomic loads which we currently
> don't differentiate in any way in the back-end.

I have encountered similar problems with reordering in OpenGL land
reading a value that is also accessed using atomics.  SPIR-V has an
atomic load instruction.  I haven't looked at how we handle that in
spv_to_nir, but could we use something like that in these cases?

> Obviously, we need to come up with something better for this than just
> shutting off the scheduler but I wanted to send this out earlier rather
> than later and provide the opportunity for a discussion.
> ---
>  src/intel/compiler/brw_fs.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 3f7f2b4c984..9df238a6f6a 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -6427,7 +6427,7 @@ fs_visitor::allocate_registers(unsigned 
> min_dispatch_width, bool allow_spilling)
>  * performance but increasing likelihood of allocating.
>  */
> for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
> -  schedule_instructions(pre_modes[i]);
> +  //schedule_instructions(pre_modes[i]);
>  
>if (0) {
>   assign_regs_trivial();
> @@ -6478,7 +6478,7 @@ fs_visitor::allocate_registers(unsigned 
> min_dispatch_width, bool allow_spilling)
>  
> opt_bank_conflicts();
>  
> -   schedule_instructions(SCHEDULE_POST);
> +   //schedule_instructions(SCHEDULE_POST);
>  
> if (last_scratch > 0) {
>MAYBE_UNUSED unsigned max_scratch_size = 2 * 1024 * 1024;
> 

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

Re: [Mesa-dev] [RFC 5/7] spirv: Add support for the Vulkan memory model

[Ian Romanick]

This patch looks like what I would expect.  Contingent on the previous
patch, this patch is

Reviewed-by: Ian Romanick 

On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> ---
>  src/compiler/shader_info.h|  1 +
>  src/compiler/spirv/spirv_to_nir.c | 20 ++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
> index 65bc0588d67..a19840666ac 100644
> --- a/src/compiler/shader_info.h
> +++ b/src/compiler/shader_info.h
> @@ -62,6 +62,7 @@ struct spirv_supported_capabilities {
> bool post_depth_coverage;
> bool transform_feedback;
> bool geometry_streams;
> +   bool vk_memory_model;
>  };
>  
>  typedef struct shader_info {
> diff --git a/src/compiler/spirv/spirv_to_nir.c 
> b/src/compiler/spirv/spirv_to_nir.c
> index 3378641513c..dcce05ce83b 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -3600,6 +3600,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
> SpvOp opcode,
>   spv_check_supported(post_depth_coverage, cap);
>   break;
>  
> +  case SpvCapabilityVulkanMemoryModelKHR:
> + spv_check_supported(vk_memory_model, cap);
> + break;
> +
>default:
>   vtn_fail("Unhandled capability");
>}
> @@ -3612,8 +3616,20 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
> SpvOp opcode,
>  
> case SpvOpMemoryModel:
>vtn_assert(w[1] == SpvAddressingModelLogical);
> -  vtn_assert(w[2] == SpvMemoryModelSimple ||
> - w[2] == SpvMemoryModelGLSL450);
> +  switch (w[2]) {
> +  case SpvMemoryModelSimple:
> +  case SpvMemoryModelGLSL450:
> + break;
> +
> +  case SpvMemoryModelVulkanKHR:
> + vtn_fail_if(!b->options->caps.vk_memory_model,
> + "Vulkan memory model is unsupported by this driver");
> + break;
> +
> +  default:
> + vtn_fail("Unsupported memory model: %s",
> +  spirv_memorymodel_to_string(w[2]));
> +  }
>break;
>  
> case SpvOpEntryPoint:
> 

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

Re: [Mesa-dev] [RFC 6/7] HACK: Disable the instruction scheduler

[Bas Nieuwenhuizen]

On Mon, Sep 10, 2018 at 8:05 PM Jason Ekstrand  wrote:
>
> The instruction scheduler is re-ordering loads which is causing fence
> values to be loaded after the value they're fencing.  In particular,
> consider the following pseudocode:
>
> void try_use_a_thing(int idx)
> {
> bool ready = ssbo.arr[idx].ready;
> vec4 data = ssbo.arr[idx].data;
> if (ready)
> use(data);
> }
>
> void write_a_thing(int idx, vec4 data)
> {
> ssbo.arr[idx].data = data;
> ssbo.arr[idx].ready = true;
> }
>
> Our current instruction scheduling scheme doesn't see any problem with
> re-ordering the load of "ready" with respect to the load of "data".
> However, if try_use_a_thing is called in one thread and write_a_thing is
> called in another thread, such re-ordering could cause invalid data to
> be used.  Normally, some re-ordering of loads is fine; however, with the
> Vulkan memory model, there are some additional guarantees that are
> provided particularly in the case of atomic loads which we currently
> don't differentiate in any way in the back-end.
>
> Obviously, we need to come up with something better for this than just
> shutting off the scheduler but I wanted to send this out earlier rather
> than later and provide the opportunity for a discussion.

so how about adding a bitmask with flags for these to load/store
intrinsics? I remember we still need a coherent bit to implement
coherent loads and stores for AMD. We could easily have a mask with
coherent+atomic+whatever and then pass that to the backend?

> ---
>  src/intel/compiler/brw_fs.cpp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 3f7f2b4c984..9df238a6f6a 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -6427,7 +6427,7 @@ fs_visitor::allocate_registers(unsigned 
> min_dispatch_width, bool allow_spilling)
>  * performance but increasing likelihood of allocating.
>  */
> for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
> -  schedule_instructions(pre_modes[i]);
> +  //schedule_instructions(pre_modes[i]);
>
>if (0) {
>   assign_regs_trivial();
> @@ -6478,7 +6478,7 @@ fs_visitor::allocate_registers(unsigned 
> min_dispatch_width, bool allow_spilling)
>
> opt_bank_conflicts();
>
> -   schedule_instructions(SCHEDULE_POST);
> +   //schedule_instructions(SCHEDULE_POST);
>
> if (last_scratch > 0) {
>MAYBE_UNUSED unsigned max_scratch_size = 2 * 1024 * 1024;
> --
> 2.17.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/7] anv: Support VK_KHR_vulkan_memory_model

[Ian Romanick]

On 09/10/2018 03:16 PM, Jason Ekstrand wrote:
> On Mon, Sep 10, 2018 at 5:08 PM Ian Romanick  > wrote:
> 
> The first 3 patches and "anv: Bump the advertised patch version to 84"
> should be safe to land at any time, right?
> 
> 
> Yup.  I meant to not make those RFC but failed at editing all of the
> required patch files.

Ok. :)  Those 4 are

Reviewed-by: Ian Romanick 

> --Jason
> 
>  
> 
> On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> > This patch series adds support to the Intel Vulkan driver for the
> > (currently provisional) VK_KHR_vulkan_memory_model extension.  The
> > extension provides a few extra SPIR-V decorations along with some
> > additional guarantees about memory transaction ordering that aim
> to make
> > better analysis and use of concurrency possible in Vulkan.  In
> particular,
> > it provides sufficient guarantees to allow for the creation and use of
> > basic lock-free data structures in Vulkan shaders.
> >
> > The current implementation does little more than rework the
> barrier code in
> > the SPIR-V to NIR pass.  This is mostly because NIR currently does
> little
> > to no optimization on external memory access.  As we begin to add more
> > optimizations in this area, we will need to be careful to think
> about the
> > Vulkan memory model to ensure that we continue to provide the right
> > guarantees.  It also points out just how awkward our current
> handling of
> > barriers is in NIR.
> >
> > This series is sent out as an RFC at this point to make people
> aware of the
> > extension and to get the discussion going on how we want to do
> things "for
> > real".  Also, as can be seen from patch 6, there's still a little work
> > needed in the Intel back-end compiler to properly support this. :-)
> >
> > The series can be found on my gitlab:
> >
> >
> 
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/VK_KHR_vulkan_memory_model
> >
> > Cc: Kenneth Graunke  >
> > Cc: Matt Turner mailto:matts...@gmail.com>>
> > Cc: Francisco Jerez  >
> > Cc: Timothy Arceri  >
> > Cc: Caio Marcelo de Oliveira Filho  >
> > Cc: Bas Nieuwenhuizen  >
> >
> > Jason Ekstrand (7):
> >   vulkan: Update the XML and headers to 1.1.84
> >   spirv: Update Json and headers from Khronos GitHub master
> >   spirv/info: Add a memorymodel_to_string helper
> >   spirv: Insert barriers to follow the Vulkan memory model
> >   spirv: Add support for the Vulkan memory model
> >   HACK: Disable the instruction scheduler
> >   anv: Advertise support for VK_KHR_vulkan_memory_model
> >
> >  include/vulkan/vulkan_core.h               | 139 +-
> >  src/compiler/shader_info.h                 |   1 +
> >  src/compiler/spirv/spirv.core.grammar.json |  95 ++-
> >  src/compiler/spirv/spirv.h                 |  24 ++
> >  src/compiler/spirv/spirv_info.h            |   1 +
> >  src/compiler/spirv/spirv_info_c.py         |   1 +
> >  src/compiler/spirv/spirv_to_nir.c          | 190 +-
> >  src/intel/compiler/brw_fs.cpp              |   4 +-
> >  src/intel/vulkan/anv_device.c              |   7 +
> >  src/intel/vulkan/anv_extensions.py         |   1 +
> >  src/intel/vulkan/anv_pipeline.c            |   1 +
> >  src/vulkan/registry/vk.xml                 | 280
> -
> >  12 files changed, 594 insertions(+), 150 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 4/7] spirv: Insert barriers to follow the Vulkan memory model

[Bas Nieuwenhuizen]

On Mon, Sep 10, 2018 at 8:05 PM Jason Ekstrand  wrote:
>
> ---
>  src/compiler/spirv/spirv_to_nir.c | 170 ++
>  1 file changed, 103 insertions(+), 67 deletions(-)
>
> diff --git a/src/compiler/spirv/spirv_to_nir.c 
> b/src/compiler/spirv/spirv_to_nir.c
> index 96224354057..3378641513c 100644
> --- a/src/compiler/spirv/spirv_to_nir.c
> +++ b/src/compiler/spirv/spirv_to_nir.c
> @@ -2314,6 +2314,79 @@ fill_common_atomic_sources(struct vtn_builder *b, 
> SpvOp opcode,
> }
>  }
>
> +static void
> +vtn_emit_barrier(struct vtn_builder *b, nir_intrinsic_op op)
> +{
> +   nir_intrinsic_instr *intrin = nir_intrinsic_instr_create(b->shader, op);
> +   nir_builder_instr_insert(>nb, >instr);
> +}
> +
> +static void
> +vtn_emit_memory_barrier(struct vtn_builder *b, SpvScope scope,
> +SpvMemorySemanticsMask semantics)
> +{
> +   static const SpvMemorySemanticsMask all_memory_semantics =
> +  SpvMemorySemanticsUniformMemoryMask |
> +  SpvMemorySemanticsWorkgroupMemoryMask |
> +  SpvMemorySemanticsAtomicCounterMemoryMask |
> +  SpvMemorySemanticsImageMemoryMask |
> +  SpvMemorySemanticsOutputMemoryKHRMask |
> +  SpvMemorySemanticsMakeAvailableKHRMask |
> +  SpvMemorySemanticsMakeVisibleKHRMask;
> +
> +   /* If we're not actually doing a memory barrier, bail */
> +   if (!(semantics & all_memory_semantics))
> +  return;
> +
> +   /* GL and Vulkan don't have these */
> +   vtn_assert(scope != SpvScopeCrossDevice);
> +
> +   if (scope == SpvScopeSubgroup)
> +  return; /* Nothing to do here */

I don't think doing nothing here works for AMD, I think in some cases
we can have some hardware reordering.

+cc Marek to confirm.

> +
> +   if (scope == SpvScopeWorkgroup) {
> +  vtn_emit_barrier(b, nir_intrinsic_group_memory_barrier);
> +  return;
> +   }
> +
> +   /* There's only three scopes left */
> +   vtn_assert(scope == SpvScopeInvocation ||
> +  scope == SpvScopeDevice ||
> +  scope == SpvScopeQueueFamilyKHR);
> +
> +   if ((semantics & all_memory_semantics) == all_memory_semantics) {
> +  vtn_emit_barrier(b, nir_intrinsic_memory_barrier);
> +  return;
> +   }
> +
> +   /* Issue a bunch of more specific barriers */
> +   uint32_t bits = semantics;
> +   while (bits) {
> +  SpvMemorySemanticsMask semantic = 1 << u_bit_scan();
> +  switch (semantic) {
> +  case SpvMemorySemanticsUniformMemoryMask:
> + vtn_emit_barrier(b, nir_intrinsic_memory_barrier_buffer);
> + break;
> +  case SpvMemorySemanticsWorkgroupMemoryMask:
> + vtn_emit_barrier(b, nir_intrinsic_memory_barrier_shared);
> + break;
> +  case SpvMemorySemanticsAtomicCounterMemoryMask:
> + vtn_emit_barrier(b, nir_intrinsic_memory_barrier_atomic_counter);
> + break;
> +  case SpvMemorySemanticsImageMemoryMask:
> + vtn_emit_barrier(b, nir_intrinsic_memory_barrier_image);
> + break;
> +  case SpvMemorySemanticsOutputMemoryKHRMask:
> +  case SpvMemorySemanticsMakeAvailableKHRMask:
> +  case SpvMemorySemanticsMakeVisibleKHRMask:
> + vtn_emit_barrier(b, nir_intrinsic_memory_barrier);
> + return;
> +  default:
> + break;;
> +  }
> +   }
> +}
> +
>  static nir_ssa_def *
>  get_image_coord(struct vtn_builder *b, uint32_t value)
>  {
> @@ -2357,6 +2430,8 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
> }
>
> struct vtn_image_pointer image;
> +   SpvScope scope = SpvScopeInvocation;
> +   SpvMemorySemanticsMask semantics = 0;
>
> switch (opcode) {
> case SpvOpAtomicExchange:
> @@ -2375,10 +2450,14 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
> case SpvOpAtomicOr:
> case SpvOpAtomicXor:
>image = *vtn_value(b, w[3], vtn_value_type_image_pointer)->image;
> +  scope = vtn_constant_value(b, w[4])->values[0].u32[0];
> +  semantics = vtn_constant_value(b, w[5])->values[0].u32[0];
>break;
>
> case SpvOpAtomicStore:
>image = *vtn_value(b, w[1], vtn_value_type_image_pointer)->image;
> +  scope = vtn_constant_value(b, w[2])->values[0].u32[0];
> +  semantics = vtn_constant_value(b, w[3])->values[0].u32[0];
>break;
>
> case SpvOpImageQuerySize:
> @@ -2417,6 +2496,8 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
>vtn_fail("Invalid image opcode");
> }
>
> +   semantics |= SpvMemorySemanticsImageMemoryMask;
> +
> nir_intrinsic_op op;
> switch (opcode) {
>  #define OP(S, N) case SpvOp##S: op = nir_intrinsic_image_deref_##N; break;
> @@ -2493,6 +2574,9 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
>vtn_fail("Invalid image opcode");
> }
>
> +   if (opcode == SpvOpAtomicLoad)
> +  vtn_emit_memory_barrier(b, scope, semantics);
> +
> if (opcode != SpvOpImageWrite && opcode != SpvOpAtomicStore) {
>struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_ssa);
>

Re: [Mesa-dev] [RFC 0/7] anv: Support VK_KHR_vulkan_memory_model

[Jason Ekstrand]

On Mon, Sep 10, 2018 at 5:08 PM Ian Romanick  wrote:

> The first 3 patches and "anv: Bump the advertised patch version to 84"
> should be safe to land at any time, right?
>

Yup.  I meant to not make those RFC but failed at editing all of the
required patch files.

--Jason



> On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> > This patch series adds support to the Intel Vulkan driver for the
> > (currently provisional) VK_KHR_vulkan_memory_model extension.  The
> > extension provides a few extra SPIR-V decorations along with some
> > additional guarantees about memory transaction ordering that aim to make
> > better analysis and use of concurrency possible in Vulkan.  In
> particular,
> > it provides sufficient guarantees to allow for the creation and use of
> > basic lock-free data structures in Vulkan shaders.
> >
> > The current implementation does little more than rework the barrier code
> in
> > the SPIR-V to NIR pass.  This is mostly because NIR currently does little
> > to no optimization on external memory access.  As we begin to add more
> > optimizations in this area, we will need to be careful to think about the
> > Vulkan memory model to ensure that we continue to provide the right
> > guarantees.  It also points out just how awkward our current handling of
> > barriers is in NIR.
> >
> > This series is sent out as an RFC at this point to make people aware of
> the
> > extension and to get the discussion going on how we want to do things
> "for
> > real".  Also, as can be seen from patch 6, there's still a little work
> > needed in the Intel back-end compiler to properly support this. :-)
> >
> > The series can be found on my gitlab:
> >
> >
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/VK_KHR_vulkan_memory_model
> >
> > Cc: Kenneth Graunke 
> > Cc: Matt Turner 
> > Cc: Francisco Jerez 
> > Cc: Timothy Arceri 
> > Cc: Caio Marcelo de Oliveira Filho 
> > Cc: Bas Nieuwenhuizen 
> >
> > Jason Ekstrand (7):
> >   vulkan: Update the XML and headers to 1.1.84
> >   spirv: Update Json and headers from Khronos GitHub master
> >   spirv/info: Add a memorymodel_to_string helper
> >   spirv: Insert barriers to follow the Vulkan memory model
> >   spirv: Add support for the Vulkan memory model
> >   HACK: Disable the instruction scheduler
> >   anv: Advertise support for VK_KHR_vulkan_memory_model
> >
> >  include/vulkan/vulkan_core.h   | 139 +-
> >  src/compiler/shader_info.h |   1 +
> >  src/compiler/spirv/spirv.core.grammar.json |  95 ++-
> >  src/compiler/spirv/spirv.h |  24 ++
> >  src/compiler/spirv/spirv_info.h|   1 +
> >  src/compiler/spirv/spirv_info_c.py |   1 +
> >  src/compiler/spirv/spirv_to_nir.c  | 190 +-
> >  src/intel/compiler/brw_fs.cpp  |   4 +-
> >  src/intel/vulkan/anv_device.c  |   7 +
> >  src/intel/vulkan/anv_extensions.py |   1 +
> >  src/intel/vulkan/anv_pipeline.c|   1 +
> >  src/vulkan/registry/vk.xml | 280 -
> >  12 files changed, 594 insertions(+), 150 deletions(-)
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC 0/7] anv: Support VK_KHR_vulkan_memory_model

[Ian Romanick]

The first 3 patches and "anv: Bump the advertised patch version to 84"
should be safe to land at any time, right?

On 09/10/2018 11:04 AM, Jason Ekstrand wrote:
> This patch series adds support to the Intel Vulkan driver for the
> (currently provisional) VK_KHR_vulkan_memory_model extension.  The
> extension provides a few extra SPIR-V decorations along with some
> additional guarantees about memory transaction ordering that aim to make
> better analysis and use of concurrency possible in Vulkan.  In particular,
> it provides sufficient guarantees to allow for the creation and use of
> basic lock-free data structures in Vulkan shaders.
> 
> The current implementation does little more than rework the barrier code in
> the SPIR-V to NIR pass.  This is mostly because NIR currently does little
> to no optimization on external memory access.  As we begin to add more
> optimizations in this area, we will need to be careful to think about the
> Vulkan memory model to ensure that we continue to provide the right
> guarantees.  It also points out just how awkward our current handling of
> barriers is in NIR.
> 
> This series is sent out as an RFC at this point to make people aware of the
> extension and to get the discussion going on how we want to do things "for
> real".  Also, as can be seen from patch 6, there's still a little work
> needed in the Intel back-end compiler to properly support this. :-)
> 
> The series can be found on my gitlab:
> 
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/VK_KHR_vulkan_memory_model
> 
> Cc: Kenneth Graunke 
> Cc: Matt Turner 
> Cc: Francisco Jerez 
> Cc: Timothy Arceri 
> Cc: Caio Marcelo de Oliveira Filho 
> Cc: Bas Nieuwenhuizen 
> 
> Jason Ekstrand (7):
>   vulkan: Update the XML and headers to 1.1.84
>   spirv: Update Json and headers from Khronos GitHub master
>   spirv/info: Add a memorymodel_to_string helper
>   spirv: Insert barriers to follow the Vulkan memory model
>   spirv: Add support for the Vulkan memory model
>   HACK: Disable the instruction scheduler
>   anv: Advertise support for VK_KHR_vulkan_memory_model
> 
>  include/vulkan/vulkan_core.h   | 139 +-
>  src/compiler/shader_info.h |   1 +
>  src/compiler/spirv/spirv.core.grammar.json |  95 ++-
>  src/compiler/spirv/spirv.h |  24 ++
>  src/compiler/spirv/spirv_info.h|   1 +
>  src/compiler/spirv/spirv_info_c.py |   1 +
>  src/compiler/spirv/spirv_to_nir.c  | 190 +-
>  src/intel/compiler/brw_fs.cpp  |   4 +-
>  src/intel/vulkan/anv_device.c  |   7 +
>  src/intel/vulkan/anv_extensions.py |   1 +
>  src/intel/vulkan/anv_pipeline.c|   1 +
>  src/vulkan/registry/vk.xml | 280 -
>  12 files changed, 594 insertions(+), 150 deletions(-)
> 

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

Re: [Mesa-dev] [PATCH] nir: do not remove varyings used for transform feedback

[Timothy Arceri]

For GLSL IR we set data.always_active_io = 1 this should skip this pass 
the array/component splitting/packing passes etc.


On 11/9/18 4:52 am, Samuel Pitoiset wrote:

When a xfb buffer is explicitely declared on a varying
variable, we shouldn't remove it at link time.

Signed-off-by: Samuel Pitoiset 
---
  src/compiler/nir/nir_linking_helpers.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index 85712a7cb1c..a710ba3da25 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -112,6 +112,9 @@ remove_unused_io_vars(nir_shader *shader, struct exec_list 
*var_list,
if (var->data.always_active_io)
   continue;
  
+  if (var->data.explicit_xfb_buffer)

+ continue;
+
uint64_t other_stage = used[var->data.location_frac];
  
if (!(other_stage & get_variable_io_mask(var, shader->info.stage))) {



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

Re: [Mesa-dev] [PATCH v3] egl/android: rework device probing

[Mauro Rossi]

Hi Emil,
Il giorno lun 3 set 2018 alle ore 14:42 Emil Velikov
 ha scritto:
>
> From: Emil Velikov 
>
> Unlike the other platforms, here we aim do guess if the device that we
> somewhat arbitrarily picked, is supported or not.
>
> In particular: when a vendor is _not_ requested we loop through all
> devices, picking the first one which can create a DRI screen.
>
> When a vendor is requested - we use that and do _not_ fall-back to any
> other device.
>
> The former seems a bit fiddly, but considering EGL_EXT_explicit_device and
> EGL_MESA_query_renderer are MIA, this is the best we can do for the
> moment.
>
> With those (proposed) extensions userspace will be able to create a
> separate EGL display for each device, query device details and make the
> conscious decision which one to use.
>
> v2:
>  - update droid_open_device_drm_gralloc()
>  - set the dri2_dpy->fd before using it
>  - return a EGLBoolean for droid_{probe,open}_device*
>  - do not warn on droid_load_driver failure (Tomasz)
>  - plug mem leak on dri2_create_screen failure (Tomasz)
>  - fixup function name typo (Tomasz, Rob)
>
> v3:
>  - add forward declaration for droid_load_driver()
> Fixes the HAVE_DRM_GRALLOC build (Mauro)
>  - split dup() assignment and check in separate lines (Tomasz, Eric)
>  - make droid_load_driver() static (Tomasz)
>  - drop unused prop_set variable (Tomasz)
>
> Cc: Robert Foss 
> Cc: Tomasz Figa 
> Cc: Mauro Rossi 
> Signed-off-by: Emil Velikov 
> Tested-by: Tomasz Figa 
> Tested-by: Tapani Pälli 
> ---
> Thanks for the feedback everyone.
>
> Mauro, this includes a forward declaration which should fix things for
> you.
> ---
>  src/egl/drivers/dri2/platform_android.c | 124 +++-
>  1 file changed, 79 insertions(+), 45 deletions(-)
>
> diff --git a/src/egl/drivers/dri2/platform_android.c 
> b/src/egl/drivers/dri2/platform_android.c
> index ecc0245c9a2..5a73d9e7ea9 100644
> --- a/src/egl/drivers/dri2/platform_android.c
> +++ b/src/egl/drivers/dri2/platform_android.c
> @@ -1202,10 +1202,14 @@ droid_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *dpy)
> return (config_count != 0);
>  }
>
> +static EGLBoolean
> +droid_load_driver(_EGLDisplay *disp);

droid_probe_device(_EGLDisplay *disp);

is required here, as it is invoked in droid_open_device_drm_gralloc()
With this change there is no regression in the drivers I've tested
(Intel and AMD)

nouveau has some other problem, manifesting as drm driver errors and
freezes, happening also with drm_gralloc,
but it is not due to this patch, the problem was alreaday present w/o
this patch.

Mauro

> +
>  #ifdef HAVE_DRM_GRALLOC
> -static int
> -droid_open_device_drm_gralloc(struct dri2_egl_display *dri2_dpy)
> +static EGLBoolean
> +droid_open_device_drm_gralloc(_EGLDisplay *disp)
>  {
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> int fd = -1, err = -EINVAL;
>
> if (dri2_dpy->gralloc->perform)
> @@ -1214,10 +1218,14 @@ droid_open_device_drm_gralloc(struct dri2_egl_display 
> *dri2_dpy)
>);
> if (err || fd < 0) {
>_eglLog(_EGL_WARNING, "fail to get drm fd");
> -  fd = -1;
> +  return EGL_FALSE;
> }
>
> -   return (fd >= 0) ? fcntl(fd, F_DUPFD_CLOEXEC, 3) : -1;
> +   dri2_dpy->fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
> +   if (dri2_dpy->fd < 0)
> + return EGL_FALSE;
> +
> +   return droid_probe_device(disp);
>  }
>  #endif /* HAVE_DRM_GRALLOC */
>
> @@ -1362,10 +1370,10 @@ static const __DRIextension 
> *droid_image_loader_extensions[] = {
> NULL,
>  };
>
> -EGLBoolean
> +static EGLBoolean
>  droid_load_driver(_EGLDisplay *disp)
>  {
> -   struct dri2_egl_display *dri2_dpy = disp->DriverData;
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> const char *err;
>
> dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> @@ -1404,6 +1412,17 @@ error:
> return false;
>  }
>
> +static void
> +droid_unload_driver(_EGLDisplay *disp)
> +{
> +   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> +
> +   dlclose(dri2_dpy->driver);
> +   dri2_dpy->driver = NULL;
> +   free(dri2_dpy->driver_name);
> +   dri2_dpy->driver_name = NULL;
> +}
> +
>  static int
>  droid_filter_device(_EGLDisplay *disp, int fd, const char *vendor)
>  {
> @@ -1420,13 +1439,31 @@ droid_filter_device(_EGLDisplay *disp, int fd, const 
> char *vendor)
> return 0;
>  }
>
> -static int
> +static EGLBoolean
> +droid_probe_device(_EGLDisplay *disp)
> +{
> +  /* Check that the device is supported, by attempting to:
> +   * - load the dri module
> +   * - and, create a screen
> +   */
> +   if (!droid_load_driver(disp))
> +  return EGL_FALSE;
> +
> +   if (!dri2_create_screen(disp)) {
> +  _eglLog(_EGL_WARNING, "DRI2: failed to create screen");
> +  droid_unload_driver(disp);
> +  return EGL_FALSE;
> +   }
> +   return EGL_TRUE;
> +}
> +
> +static EGLBoolean
>  droid_open_device(_EGLDisplay *disp)
>  {
>  #define MAX_DRM_DEVICES 

Re: [Mesa-dev] [PATCH] mesa: remove duplicate dispatch sanity tests

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Fri, Sep 7, 2018 at 6:21 PM, Timothy Arceri  wrote:
> This removes duplicate tests from gl_core_functions_possible
> that are already covered by common_desktop_functions_possible.
> ---
>  src/mesa/main/tests/dispatch_sanity.cpp | 265 
>  1 file changed, 265 deletions(-)
>
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 449dd3652cc..63c687c46fc 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -1681,271 +1681,6 @@ const struct function 
> gl_compatibility_functions_possible[] = {
>  };
>
>  const struct function gl_core_functions_possible[] = {
> -   /* GL 3.2 */
> -   { "glFramebufferTexture", 32, -1 },
> -
> -   /* GL 4.3 */
> -   { "glIsRenderbuffer", 43, -1 },
> -   { "glBindRenderbuffer", 43, -1 },
> -   { "glDeleteRenderbuffers", 43, -1 },
> -   { "glGenRenderbuffers", 43, -1 },
> -   { "glRenderbufferStorage", 43, -1 },
> -   { "glGetRenderbufferParameteriv", 43, -1 },
> -   { "glIsFramebuffer", 43, -1 },
> -   { "glBindFramebuffer", 43, -1 },
> -   { "glDeleteFramebuffers", 43, -1 },
> -   { "glGenFramebuffers", 43, -1 },
> -   { "glCheckFramebufferStatus", 43, -1 },
> -   { "glFramebufferTexture1D", 43, -1 },
> -   { "glFramebufferTexture2D", 43, -1 },
> -   { "glFramebufferTexture3D", 43, -1 },
> -   { "glFramebufferRenderbuffer", 43, -1 },
> -   { "glGetFramebufferAttachmentParameteriv", 43, -1 },
> -   { "glGenerateMipmap", 43, -1 },
> -   { "glBlitFramebuffer", 43, -1 },
> -   { "glRenderbufferStorageMultisample", 43, -1 },
> -   { "glFramebufferTextureLayer", 43, -1 },
> -   { "glMapBufferRange", 43, -1 },
> -   { "glFlushMappedBufferRange", 43, -1 },
> -   { "glBindVertexArray", 43, -1 },
> -   { "glDeleteVertexArrays", 43, -1 },
> -   { "glGenVertexArrays", 43, -1 },
> -   { "glIsVertexArray", 43, -1 },
> -   { "glGetUniformIndices", 43, -1 },
> -   { "glGetActiveUniformsiv", 43, -1 },
> -   { "glGetActiveUniformName", 43, -1 },
> -   { "glGetUniformBlockIndex", 43, -1 },
> -   { "glGetActiveUniformBlockiv", 43, -1 },
> -   { "glGetActiveUniformBlockName", 43, -1 },
> -   { "glUniformBlockBinding", 43, -1 },
> -   { "glCopyBufferSubData", 43, -1 },
> -   { "glDrawElementsBaseVertex", 43, -1 },
> -   { "glDrawRangeElementsBaseVertex", 43, -1 },
> -   { "glDrawElementsInstancedBaseVertex", 43, -1 },
> -   { "glMultiDrawElementsBaseVertex", 43, -1 },
> -   { "glProvokingVertex", 43, -1 },
> -   { "glFenceSync", 43, -1 },
> -   { "glIsSync", 43, -1 },
> -   { "glDeleteSync", 43, -1 },
> -   { "glClientWaitSync", 43, -1 },
> -   { "glWaitSync", 43, -1 },
> -   { "glGetInteger64v", 43, -1 },
> -   { "glGetSynciv", 43, -1 },
> -   { "glTexImage2DMultisample", 43, -1 },
> -   { "glTexImage3DMultisample", 43, -1 },
> -   { "glGetMultisamplefv", 43, -1 },
> -   { "glSampleMaski", 43, -1 },
> -   { "glBlendEquationiARB", 43, -1 },
> -   { "glBlendEquationSeparateiARB", 43, -1 },
> -   { "glBlendFunciARB", 43, -1 },
> -   { "glBlendFuncSeparateiARB", 43, -1 },
> -   { "glMinSampleShadingARB", 43, -1 }, // XXX: Add to xml
> -// { "glNamedStringARB", 43, -1 },  // XXX: Add to xml
> -// { "glDeleteNamedStringARB", 43, -1 },// XXX: Add to xml
> -// { "glCompileShaderIncludeARB", 43, -1 }, // XXX: Add to xml
> -// { "glIsNamedStringARB", 43, -1 },// XXX: Add to xml
> -// { "glGetNamedStringARB", 43, -1 },   // XXX: Add to xml
> -// { "glGetNamedStringivARB", 43, -1 }, // XXX: Add to xml
> -   { "glBindFragDataLocationIndexed", 43, -1 },
> -   { "glGetFragDataIndex", 43, -1 },
> -   { "glGenSamplers", 43, -1 },
> -   { "glDeleteSamplers", 43, -1 },
> -   { "glIsSampler", 43, -1 },
> -   { "glBindSampler", 43, -1 },
> -   { "glSamplerParameteri", 43, -1 },
> -   { "glSamplerParameteriv", 43, -1 },
> -   { "glSamplerParameterf", 43, -1 },
> -   { "glSamplerParameterfv", 43, -1 },
> -   { "glSamplerParameterIiv", 43, -1 },
> -   { "glSamplerParameterIuiv", 43, -1 },
> -   { "glGetSamplerParameteriv", 43, -1 },
> -   { "glGetSamplerParameterIiv", 43, -1 },
> -   { "glGetSamplerParameterfv", 43, -1 },
> -   { "glGetSamplerParameterIuiv", 43, -1 },
> -   { "glQueryCounter", 43, -1 },
> -   { "glGetQueryObjecti64v", 43, -1 },
> -   { "glGetQueryObjectui64v", 43, -1 },
> -   { "glVertexP2ui", 43, -1 },
> -   { "glVertexP2uiv", 43, -1 },
> -   { "glVertexP3ui", 43, -1 },
> -   { "glVertexP3uiv", 43, -1 },
> -   { "glVertexP4ui", 43, -1 },
> -   { "glVertexP4uiv", 43, -1 },
> -   { "glTexCoordP1ui", 43, -1 },
> -   { "glTexCoordP1uiv", 43, -1 },
> -   { "glTexCoordP2ui", 43, -1 },
> -   { "glTexCoordP2uiv", 43, -1 },
> -   { "glTexCoordP3ui", 43, -1 },
> -   { "glTexCoordP3uiv", 43, -1 },
> -   { "glTexCoordP4ui", 43, -1 },
> -   { "glTexCoordP4uiv", 43, -1 },
> -   { "glMultiTexCoordP1ui", 43, -1 },
> -   { 

Re: [Mesa-dev] [PATCH] radeon: fix ColorMask

[Marek Olšák]

Pushed, thanks!

Marek

On Fri, Sep 7, 2018 at 8:16 PM, Christopher Egert  wrote:
> Since commit af3685d14936844f79e6f372b4b258e29375f21b various OpenGL 
> applications regressed
> on the classic mesa radeon driver.
>
> Signed-off-by: Christopher Egert 
> CC: 
> ---
>  src/mesa/drivers/dri/r200/r200_state.c | 8 
>  src/mesa/drivers/dri/radeon/radeon_state.c | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/r200/r200_state.c 
> b/src/mesa/drivers/dri/r200/r200_state.c
> index d53225d63a..b4cff8c259 100644
> --- a/src/mesa/drivers/dri/r200/r200_state.c
> +++ b/src/mesa/drivers/dri/r200/r200_state.c
> @@ -688,10 +688,10 @@ static void r200ColorMask( struct gl_context *ctx,
> if (!rrb)
>   return;
> mask = radeonPackColor( rrb->cpp,
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 0),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 1),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 2),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 3) );
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 0)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 1)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 2)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 3)*0xFF 
> );
>
>
> if (!(r && g && b && a))
> diff --git a/src/mesa/drivers/dri/radeon/radeon_state.c 
> b/src/mesa/drivers/dri/radeon/radeon_state.c
> index 8b72c98a3b..410a78fc08 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_state.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_state.c
> @@ -503,10 +503,10 @@ static void radeonColorMask( struct gl_context *ctx,
>   return;
>
> mask = radeonPackColor( rrb->cpp,
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 0),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 1),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 2),
> -  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 3) );
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 0)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 1)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 2)*0xFF,
> +  GET_COLORMASK_BIT(ctx->Color.ColorMask, 0, 3)*0xFF 
> );
>
> if ( rmesa->hw.msk.cmd[MSK_RB3D_PLANEMASK] != mask ) {
>RADEON_STATECHANGE( rmesa, msk );
> --
> 2.19.0.rc2
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/4] vl/dri: add 10 bits format supports

[Leo Liu]

On 09/10/2018 04:49 PM, Ilia Mirkin wrote:

On Mon, Sep 10, 2018 at 4:27 PM, Leo Liu  wrote:

v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.

Signed-off-by: Leo Liu 
---
  src/gallium/auxiliary/vl/vl_winsys.h |  5 ++
  src/gallium/auxiliary/vl/vl_winsys_dri.c | 69 
  2 files changed, 64 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 77277cefe8b..bfb60180079 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -68,9 +68,14 @@ struct vl_screen

 struct pipe_screen *pscreen;
 struct pipe_loader_device *dev;
+
+   void *xcb_screen;
  };

  #ifdef HAVE_X11_PLATFORM
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth);
+
  struct vl_screen *
  vl_dri2_screen_create(Display *display, int screen);
  #else
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index bb1ff504886..49c8325866f 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -186,6 +186,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
 xcb_dri2_get_buffers_reply_t *reply;
 xcb_dri2_dri2_buffer_t *buffers, *back_left;

+   unsigned depth = ((xcb_screen_t *)(vscreen->xcb_screen))->root_depth;
 unsigned i;

 assert(scrn);
@@ -237,7 +238,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)

 memset(, 0, sizeof(templ));
 templ.target = PIPE_TEXTURE_2D;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(vscreen, depth);
 templ.last_level = 0;
 templ.width0 = reply->width;
 templ.height0 = reply->height;
@@ -314,6 +315,57 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
  return NULL;
  }

+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = vscreen->xcb_screen;
+   xcb_depth_iterator_t depth_iter;
+
+   if (!screen)
+  return NULL;
+
+   depth_iter = xcb_screen_allowed_depths_iterator(screen);
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+static uint32_t
+get_red_mask_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(vscreen, depth);
+
+   if (visual) {
+  return visual->red_mask;
+   }
+
+   return 0;
+}
+
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
+{
+   switch (depth) {
+   case 24:

Probably do a "return PIPE_FORMAT_B8G8R8X8_UNORM" here?


Yeah. Already re-sent. Thanks

Leo




+   case 30:
+  /* Different preferred formats for different hw */
+  if (get_red_mask_for_depth(vscreen, 30) == 0x3ff)
+ return PIPE_FORMAT_R10G10B10X2_UNORM;
+  else
+ return PIPE_FORMAT_B10G10R10X2_UNORM;
+   default:
+  return PIPE_FORMAT_NONE;
+   }
+}
+
  struct vl_screen *
  vl_dri2_screen_create(Display *display, int screen)
  {
@@ -326,7 +378,6 @@ vl_dri2_screen_create(Display *display, int screen)
 xcb_dri2_authenticate_cookie_t authenticate_cookie;
 xcb_dri2_authenticate_reply_t *authenticate = NULL;
 xcb_screen_iterator_t s;
-   xcb_screen_t *xcb_screen;
 xcb_generic_error_t *error = NULL;
 char *device_name;
 int fd, device_name_length;
@@ -358,8 +409,8 @@ vl_dri2_screen_create(Display *display, int screen)
goto free_query;

 s = xcb_setup_roots_iterator(xcb_get_setup(scrn->conn));
-   xcb_screen = get_xcb_screen(s, screen);
-   if (!xcb_screen)
+   scrn->base.xcb_screen = get_xcb_screen(s, screen);
+   if (!scrn->base.xcb_screen)
goto free_query;

 driverType = XCB_DRI2_DRIVER_TYPE_DRI;
@@ -375,9 +426,8 @@ vl_dri2_screen_create(Display *display, int screen)
}
 }

-   connect_cookie = xcb_dri2_connect_unchecked(scrn->conn,
-   xcb_screen->root,
-   driverType);
+   connect_cookie = xcb_dri2_connect_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, driverType);
 connect = xcb_dri2_connect_reply(scrn->conn, connect_cookie, NULL);
 if (connect == NULL ||
 connect->driver_name_length + connect->device_name_length == 0)
@@ -397,9 +447,8 @@ vl_dri2_screen_create(Display *display, int screen)
 if (drmGetMagic(fd, ))
goto close_fd;

-   authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn->conn,
- xcb_screen->root,
- magic);
+   

Re: [Mesa-dev] [PATCH 1/4] vl/dri: add 10 bits format supports

[Ilia Mirkin]

On Mon, Sep 10, 2018 at 4:27 PM, Leo Liu  wrote:
> v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.
>
> Signed-off-by: Leo Liu 
> ---
>  src/gallium/auxiliary/vl/vl_winsys.h |  5 ++
>  src/gallium/auxiliary/vl/vl_winsys_dri.c | 69 
>  2 files changed, 64 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
> b/src/gallium/auxiliary/vl/vl_winsys.h
> index 77277cefe8b..bfb60180079 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys.h
> +++ b/src/gallium/auxiliary/vl/vl_winsys.h
> @@ -68,9 +68,14 @@ struct vl_screen
>
> struct pipe_screen *pscreen;
> struct pipe_loader_device *dev;
> +
> +   void *xcb_screen;
>  };
>
>  #ifdef HAVE_X11_PLATFORM
> +uint32_t
> +vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth);
> +
>  struct vl_screen *
>  vl_dri2_screen_create(Display *display, int screen);
>  #else
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
> b/src/gallium/auxiliary/vl/vl_winsys_dri.c
> index bb1ff504886..49c8325866f 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
> @@ -186,6 +186,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
> *vscreen, void *drawable)
> xcb_dri2_get_buffers_reply_t *reply;
> xcb_dri2_dri2_buffer_t *buffers, *back_left;
>
> +   unsigned depth = ((xcb_screen_t *)(vscreen->xcb_screen))->root_depth;
> unsigned i;
>
> assert(scrn);
> @@ -237,7 +238,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
> *vscreen, void *drawable)
>
> memset(, 0, sizeof(templ));
> templ.target = PIPE_TEXTURE_2D;
> -   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
> +   templ.format = vl_dri2_format_for_depth(vscreen, depth);
> templ.last_level = 0;
> templ.width0 = reply->width;
> templ.height0 = reply->height;
> @@ -314,6 +315,57 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
>  return NULL;
>  }
>
> +static xcb_visualtype_t *
> +get_xcb_visualtype_for_depth(struct vl_screen *vscreen, int depth)
> +{
> +   xcb_visualtype_iterator_t visual_iter;
> +   xcb_screen_t *screen = vscreen->xcb_screen;
> +   xcb_depth_iterator_t depth_iter;
> +
> +   if (!screen)
> +  return NULL;
> +
> +   depth_iter = xcb_screen_allowed_depths_iterator(screen);
> +   for (; depth_iter.rem; xcb_depth_next(_iter)) {
> +  if (depth_iter.data->depth != depth)
> + continue;
> +
> +  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
> +  if (visual_iter.rem)
> + return visual_iter.data;
> +   }
> +
> +   return NULL;
> +}
> +
> +static uint32_t
> +get_red_mask_for_depth(struct vl_screen *vscreen, int depth)
> +{
> +   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(vscreen, depth);
> +
> +   if (visual) {
> +  return visual->red_mask;
> +   }
> +
> +   return 0;
> +}
> +
> +uint32_t
> +vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
> +{
> +   switch (depth) {
> +   case 24:

Probably do a "return PIPE_FORMAT_B8G8R8X8_UNORM" here?

> +   case 30:
> +  /* Different preferred formats for different hw */
> +  if (get_red_mask_for_depth(vscreen, 30) == 0x3ff)
> + return PIPE_FORMAT_R10G10B10X2_UNORM;
> +  else
> + return PIPE_FORMAT_B10G10R10X2_UNORM;
> +   default:
> +  return PIPE_FORMAT_NONE;
> +   }
> +}
> +
>  struct vl_screen *
>  vl_dri2_screen_create(Display *display, int screen)
>  {
> @@ -326,7 +378,6 @@ vl_dri2_screen_create(Display *display, int screen)
> xcb_dri2_authenticate_cookie_t authenticate_cookie;
> xcb_dri2_authenticate_reply_t *authenticate = NULL;
> xcb_screen_iterator_t s;
> -   xcb_screen_t *xcb_screen;
> xcb_generic_error_t *error = NULL;
> char *device_name;
> int fd, device_name_length;
> @@ -358,8 +409,8 @@ vl_dri2_screen_create(Display *display, int screen)
>goto free_query;
>
> s = xcb_setup_roots_iterator(xcb_get_setup(scrn->conn));
> -   xcb_screen = get_xcb_screen(s, screen);
> -   if (!xcb_screen)
> +   scrn->base.xcb_screen = get_xcb_screen(s, screen);
> +   if (!scrn->base.xcb_screen)
>goto free_query;
>
> driverType = XCB_DRI2_DRIVER_TYPE_DRI;
> @@ -375,9 +426,8 @@ vl_dri2_screen_create(Display *display, int screen)
>}
> }
>
> -   connect_cookie = xcb_dri2_connect_unchecked(scrn->conn,
> -   xcb_screen->root,
> -   driverType);
> +   connect_cookie = xcb_dri2_connect_unchecked(
> +  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, 
> driverType);
> connect = xcb_dri2_connect_reply(scrn->conn, connect_cookie, NULL);
> if (connect == NULL ||
> connect->driver_name_length + connect->device_name_length == 0)
> @@ -397,9 +447,8 @@ vl_dri2_screen_create(Display *display, int screen)
> if (drmGetMagic(fd, ))
>goto close_fd;
>
> -   authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn->conn,
> 

[Mesa-dev] [PATCH 1/4] vl/dri: add 10 bits format supports

[Leo Liu]

v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_winsys.h |  5 ++
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 70 
 2 files changed, 65 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 77277cefe8b..bfb60180079 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -68,9 +68,14 @@ struct vl_screen
 
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
+
+   void *xcb_screen;
 };
 
 #ifdef HAVE_X11_PLATFORM
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth);
+
 struct vl_screen *
 vl_dri2_screen_create(Display *display, int screen);
 #else
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index bb1ff504886..cb779010a9c 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -186,6 +186,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
xcb_dri2_get_buffers_reply_t *reply;
xcb_dri2_dri2_buffer_t *buffers, *back_left;
 
+   unsigned depth = ((xcb_screen_t *)(vscreen->xcb_screen))->root_depth;
unsigned i;
 
assert(scrn);
@@ -237,7 +238,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
 
memset(, 0, sizeof(templ));
templ.target = PIPE_TEXTURE_2D;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(vscreen, depth);
templ.last_level = 0;
templ.width0 = reply->width;
templ.height0 = reply->height;
@@ -314,6 +315,58 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = vscreen->xcb_screen;
+   xcb_depth_iterator_t depth_iter;
+
+   if (!screen)
+  return NULL;
+
+   depth_iter = xcb_screen_allowed_depths_iterator(screen);
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+static uint32_t
+get_red_mask_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(vscreen, depth);
+
+   if (visual) {
+  return visual->red_mask;
+   }
+
+   return 0;
+}
+
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
+{
+   switch (depth) {
+   case 24:
+  return PIPE_FORMAT_B8G8R8X8_UNORM;
+   case 30:
+  /* Different preferred formats for different hw */
+  if (get_red_mask_for_depth(vscreen, 30) == 0x3ff)
+ return PIPE_FORMAT_R10G10B10X2_UNORM;
+  else
+ return PIPE_FORMAT_B10G10R10X2_UNORM;
+   default:
+  return PIPE_FORMAT_NONE;
+   }
+}
+
 struct vl_screen *
 vl_dri2_screen_create(Display *display, int screen)
 {
@@ -326,7 +379,6 @@ vl_dri2_screen_create(Display *display, int screen)
xcb_dri2_authenticate_cookie_t authenticate_cookie;
xcb_dri2_authenticate_reply_t *authenticate = NULL;
xcb_screen_iterator_t s;
-   xcb_screen_t *xcb_screen;
xcb_generic_error_t *error = NULL;
char *device_name;
int fd, device_name_length;
@@ -358,8 +410,8 @@ vl_dri2_screen_create(Display *display, int screen)
   goto free_query;
 
s = xcb_setup_roots_iterator(xcb_get_setup(scrn->conn));
-   xcb_screen = get_xcb_screen(s, screen);
-   if (!xcb_screen)
+   scrn->base.xcb_screen = get_xcb_screen(s, screen);
+   if (!scrn->base.xcb_screen)
   goto free_query;
 
driverType = XCB_DRI2_DRIVER_TYPE_DRI;
@@ -375,9 +427,8 @@ vl_dri2_screen_create(Display *display, int screen)
   }
}
 
-   connect_cookie = xcb_dri2_connect_unchecked(scrn->conn,
-   xcb_screen->root,
-   driverType);
+   connect_cookie = xcb_dri2_connect_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, driverType);
connect = xcb_dri2_connect_reply(scrn->conn, connect_cookie, NULL);
if (connect == NULL ||
connect->driver_name_length + connect->device_name_length == 0)
@@ -397,9 +448,8 @@ vl_dri2_screen_create(Display *display, int screen)
if (drmGetMagic(fd, ))
   goto close_fd;
 
-   authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn->conn,
- xcb_screen->root,
- magic);
+   authenticate_cookie = xcb_dri2_authenticate_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, magic);
authenticate = xcb_dri2_authenticate_reply(scrn->conn, 

Re: [Mesa-dev] [PATCH 1/4] vl/dri: add 10 bits format supports

[Leo Liu]

Forget the Patch 1, will re-send shortly.

It's ming case 24:

+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
+{
+   switch (depth) {
+   case 24:
+   case 30:


Leo

On 09/10/2018 04:27 PM, Leo Liu wrote:

v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.

Signed-off-by: Leo Liu 
---
  src/gallium/auxiliary/vl/vl_winsys.h |  5 ++
  src/gallium/auxiliary/vl/vl_winsys_dri.c | 69 
  2 files changed, 64 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 77277cefe8b..bfb60180079 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -68,9 +68,14 @@ struct vl_screen
  
 struct pipe_screen *pscreen;

 struct pipe_loader_device *dev;
+
+   void *xcb_screen;
  };
  
  #ifdef HAVE_X11_PLATFORM

+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth);
+
  struct vl_screen *
  vl_dri2_screen_create(Display *display, int screen);
  #else
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index bb1ff504886..49c8325866f 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -186,6 +186,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
 xcb_dri2_get_buffers_reply_t *reply;
 xcb_dri2_dri2_buffer_t *buffers, *back_left;
  
+   unsigned depth = ((xcb_screen_t *)(vscreen->xcb_screen))->root_depth;

 unsigned i;
  
 assert(scrn);

@@ -237,7 +238,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
  
 memset(, 0, sizeof(templ));

 templ.target = PIPE_TEXTURE_2D;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(vscreen, depth);
 templ.last_level = 0;
 templ.width0 = reply->width;
 templ.height0 = reply->height;
@@ -314,6 +315,57 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
  return NULL;
  }
  
+static xcb_visualtype_t *

+get_xcb_visualtype_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = vscreen->xcb_screen;
+   xcb_depth_iterator_t depth_iter;
+
+   if (!screen)
+  return NULL;
+
+   depth_iter = xcb_screen_allowed_depths_iterator(screen);
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+static uint32_t
+get_red_mask_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(vscreen, depth);
+
+   if (visual) {
+  return visual->red_mask;
+   }
+
+   return 0;
+}
+
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
+{
+   switch (depth) {
+   case 24:
+   case 30:
+  /* Different preferred formats for different hw */
+  if (get_red_mask_for_depth(vscreen, 30) == 0x3ff)
+ return PIPE_FORMAT_R10G10B10X2_UNORM;
+  else
+ return PIPE_FORMAT_B10G10R10X2_UNORM;
+   default:
+  return PIPE_FORMAT_NONE;
+   }
+}
+
  struct vl_screen *
  vl_dri2_screen_create(Display *display, int screen)
  {
@@ -326,7 +378,6 @@ vl_dri2_screen_create(Display *display, int screen)
 xcb_dri2_authenticate_cookie_t authenticate_cookie;
 xcb_dri2_authenticate_reply_t *authenticate = NULL;
 xcb_screen_iterator_t s;
-   xcb_screen_t *xcb_screen;
 xcb_generic_error_t *error = NULL;
 char *device_name;
 int fd, device_name_length;
@@ -358,8 +409,8 @@ vl_dri2_screen_create(Display *display, int screen)
goto free_query;
  
 s = xcb_setup_roots_iterator(xcb_get_setup(scrn->conn));

-   xcb_screen = get_xcb_screen(s, screen);
-   if (!xcb_screen)
+   scrn->base.xcb_screen = get_xcb_screen(s, screen);
+   if (!scrn->base.xcb_screen)
goto free_query;
  
 driverType = XCB_DRI2_DRIVER_TYPE_DRI;

@@ -375,9 +426,8 @@ vl_dri2_screen_create(Display *display, int screen)
}
 }
  
-   connect_cookie = xcb_dri2_connect_unchecked(scrn->conn,

-   xcb_screen->root,
-   driverType);
+   connect_cookie = xcb_dri2_connect_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, driverType);
 connect = xcb_dri2_connect_reply(scrn->conn, connect_cookie, NULL);
 if (connect == NULL ||
 connect->driver_name_length + connect->device_name_length == 0)
@@ -397,9 +447,8 @@ vl_dri2_screen_create(Display *display, int screen)
 if (drmGetMagic(fd, ))
goto close_fd;
  
-   authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn->conn,

- xcb_screen->root,
-

Re: [Mesa-dev] [PATCH] mesa/texture: Also check for LA texture when querying intensity component size

[Marek Olšák]

I think you don't have to check luminance. Returning just the alpha
bits should be fine.

Marek

On Mon, Sep 10, 2018 at 4:33 PM, Marek Olšák  wrote:
> Reviewed-by: Marek Olšák 
>
> Marek
>
> On Mon, Sep 10, 2018 at 6:39 AM, Gert Wollny  wrote:
>> From: Gert Wollny 
>>
>> Gallium may pick L16A16_FLOAT to represent GL_INTENSITY16F if no intensity
>> format is provided by the driver. However, when calling
>>
>>glGetTexLevelParameteriv(..., GL_TEXTURE_INTENSITY_SIZE, ...)
>>
>> mesa will return a zero size because the actually used format has no
>> intensity channel and as a fallback only the sizes of the red/green
>> channels are checked.
>>
>> Also checking for LA sizes in the allocated texture resolves this problem.
>>
>> Fixes (on virgl):
>>   ext_framebuffer_multisample-fast-clear GL_ARB_texture_float *
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107832
>>
>> Signed-off-by: Gert Wollny 
>> ---
>>  src/mesa/main/texparam.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
>> index b5d86d64d5..643a349328 100644
>> --- a/src/mesa/main/texparam.c
>> +++ b/src/mesa/main/texparam.c
>> @@ -1426,6 +1426,13 @@ get_tex_level_parameter_image(struct gl_context *ctx,
>>_mesa_get_format_bits(texFormat,
>>  GL_TEXTURE_GREEN_SIZE));
>>  }
>> +if (*params == 0 && pname == GL_TEXTURE_INTENSITY_SIZE) {
>> +   /* Gallium may store intensity as LA */
>> +   *params = MIN2(_mesa_get_format_bits(texFormat,
>> +
>> GL_TEXTURE_LUMINANCE_SIZE),
>> +  _mesa_get_format_bits(texFormat,
>> +GL_TEXTURE_ALPHA_SIZE));
>> +}
>>   }
>>   else {
>>  *params = 0;
>> --
>> 2.16.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa/texture: Also check for LA texture when querying intensity component size

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Sep 10, 2018 at 6:39 AM, Gert Wollny  wrote:
> From: Gert Wollny 
>
> Gallium may pick L16A16_FLOAT to represent GL_INTENSITY16F if no intensity
> format is provided by the driver. However, when calling
>
>glGetTexLevelParameteriv(..., GL_TEXTURE_INTENSITY_SIZE, ...)
>
> mesa will return a zero size because the actually used format has no
> intensity channel and as a fallback only the sizes of the red/green
> channels are checked.
>
> Also checking for LA sizes in the allocated texture resolves this problem.
>
> Fixes (on virgl):
>   ext_framebuffer_multisample-fast-clear GL_ARB_texture_float *
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107832
>
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/main/texparam.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
> index b5d86d64d5..643a349328 100644
> --- a/src/mesa/main/texparam.c
> +++ b/src/mesa/main/texparam.c
> @@ -1426,6 +1426,13 @@ get_tex_level_parameter_image(struct gl_context *ctx,
>_mesa_get_format_bits(texFormat,
>  GL_TEXTURE_GREEN_SIZE));
>  }
> +if (*params == 0 && pname == GL_TEXTURE_INTENSITY_SIZE) {
> +   /* Gallium may store intensity as LA */
> +   *params = MIN2(_mesa_get_format_bits(texFormat,
> +
> GL_TEXTURE_LUMINANCE_SIZE),
> +  _mesa_get_format_bits(texFormat,
> +GL_TEXTURE_ALPHA_SIZE));
> +}
>   }
>   else {
>  *params = 0;
> --
> 2.16.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4] vl/dri: add color depth to vl winsys

[Leo Liu]

For VDPAU use later

Signed-off-by: Leo Liu 
Reviewed-by: Michel Dänzer 
---
 src/gallium/auxiliary/vl/vl_winsys.h  | 1 +
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index bfb60180079..3a35cb6a859 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -70,6 +70,7 @@ struct vl_screen
struct pipe_loader_device *dev;
 
void *xcb_screen;
+   uint32_t color_depth;
 };
 
 #ifdef HAVE_X11_PLATFORM
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 30e732e38eb..82b6445a767 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -835,6 +835,7 @@ vl_dri3_screen_create(Display *display, int screen)
   free(geom_reply);
   goto close_fd;
}
+   scrn->base.color_depth = geom_reply->depth;
free(geom_reply);
 
if (pipe_loader_drm_probe_fd(>base.dev, fd))
-- 
2.17.1

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

[Mesa-dev] [PATCH 4/4] st/vdpau: Use output buffer as back buffer with 24-bit color only

[Leo Liu]

Using output buffer with 8 bits video RGB as back buffer
certainly is not working for 30 bits color depth visual.

Signed-off-by: Leo Liu 
Reviewed-by: Michel Dänzer 
---
 src/gallium/state_trackers/vdpau/output.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/state_trackers/vdpau/output.c 
b/src/gallium/state_trackers/vdpau/output.c
index 6ef7a404474..878a3546727 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -80,7 +80,8 @@ vlVdpOutputSurfaceCreate(VdpDevice device,
 * if the VDPAU RGB component order doesn't match the X11 one so
 * we only allow the X11 format
 */
-   vlsurface->send_to_X = rgba_format == VDP_RGBA_FORMAT_B8G8R8A8;
+   vlsurface->send_to_X = dev->vscreen->color_depth == 24 &&
+  rgba_format == VDP_RGBA_FORMAT_B8G8R8A8;
 
res_tmpl.target = PIPE_TEXTURE_2D;
res_tmpl.format = VdpFormatRGBAToPipe(rgba_format);
-- 
2.17.1

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

[Mesa-dev] [PATCH 2/4] vl/dri3: add support for 10 bits format

[Leo Liu]

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_winsys_dri3.c | 29 +++
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
index 8e3c4a0e04d..30e732e38eb 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
@@ -238,7 +238,7 @@ dri3_alloc_back_buffer(struct vl_dri3_screen *scrn)
 
memset(, 0, sizeof(templ));
templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(>base, scrn->depth);
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
templ.width0 = (scrn->output_texture) ?
@@ -497,7 +497,7 @@ dri3_get_front_buffer(struct vl_dri3_screen *scrn)
whandle.stride = bp_reply->stride;
memset(, 0, sizeof(templ));
templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(>base, bp_reply->depth);
templ.target = PIPE_TEXTURE_2D;
templ.last_level = 0;
templ.width0 = bp_reply->width;
@@ -539,6 +539,20 @@ free_buffer:
return NULL;
 }
 
+static xcb_screen_t *
+dri3_get_screen_for_root(xcb_connection_t *conn, xcb_window_t root)
+{
+   xcb_screen_iterator_t screen_iter =
+   xcb_setup_roots_iterator(xcb_get_setup(conn));
+
+   for (; screen_iter.rem; xcb_screen_next (_iter)) {
+  if (screen_iter.data->root == root)
+ return screen_iter.data;
+   }
+
+   return NULL;
+}
+
 static void
 vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
   struct pipe_resource *resource,
@@ -809,8 +823,15 @@ vl_dri3_screen_create(Display *display, int screen)
geom_reply = xcb_get_geometry_reply(scrn->conn, geom_cookie, NULL);
if (!geom_reply)
   goto close_fd;
-   /* TODO support depth other than 24 */
-   if (geom_reply->depth != 24) {
+
+   scrn->base.xcb_screen = dri3_get_screen_for_root(scrn->conn, 
geom_reply->root);
+   if (!scrn->base.xcb_screen) {
+  free(geom_reply);
+  goto close_fd;
+   }
+
+   /* TODO support depth other than 24 or 30 */
+   if (geom_reply->depth != 24 && geom_reply->depth != 30) {
   free(geom_reply);
   goto close_fd;
}
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/4] vl/dri: add 10 bits format supports

[Leo Liu]

v2: Tell B10G10R10X2 and R10G10B10X2 formats for different HW.

Signed-off-by: Leo Liu 
---
 src/gallium/auxiliary/vl/vl_winsys.h |  5 ++
 src/gallium/auxiliary/vl/vl_winsys_dri.c | 69 
 2 files changed, 64 insertions(+), 10 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_winsys.h 
b/src/gallium/auxiliary/vl/vl_winsys.h
index 77277cefe8b..bfb60180079 100644
--- a/src/gallium/auxiliary/vl/vl_winsys.h
+++ b/src/gallium/auxiliary/vl/vl_winsys.h
@@ -68,9 +68,14 @@ struct vl_screen
 
struct pipe_screen *pscreen;
struct pipe_loader_device *dev;
+
+   void *xcb_screen;
 };
 
 #ifdef HAVE_X11_PLATFORM
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth);
+
 struct vl_screen *
 vl_dri2_screen_create(Display *display, int screen);
 #else
diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri.c 
b/src/gallium/auxiliary/vl/vl_winsys_dri.c
index bb1ff504886..49c8325866f 100644
--- a/src/gallium/auxiliary/vl/vl_winsys_dri.c
+++ b/src/gallium/auxiliary/vl/vl_winsys_dri.c
@@ -186,6 +186,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
xcb_dri2_get_buffers_reply_t *reply;
xcb_dri2_dri2_buffer_t *buffers, *back_left;
 
+   unsigned depth = ((xcb_screen_t *)(vscreen->xcb_screen))->root_depth;
unsigned i;
 
assert(scrn);
@@ -237,7 +238,7 @@ vl_dri2_screen_texture_from_drawable(struct vl_screen 
*vscreen, void *drawable)
 
memset(, 0, sizeof(templ));
templ.target = PIPE_TEXTURE_2D;
-   templ.format = PIPE_FORMAT_B8G8R8X8_UNORM;
+   templ.format = vl_dri2_format_for_depth(vscreen, depth);
templ.last_level = 0;
templ.width0 = reply->width;
templ.height0 = reply->height;
@@ -314,6 +315,57 @@ get_xcb_screen(xcb_screen_iterator_t iter, int screen)
 return NULL;
 }
 
+static xcb_visualtype_t *
+get_xcb_visualtype_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_iterator_t visual_iter;
+   xcb_screen_t *screen = vscreen->xcb_screen;
+   xcb_depth_iterator_t depth_iter;
+
+   if (!screen)
+  return NULL;
+
+   depth_iter = xcb_screen_allowed_depths_iterator(screen);
+   for (; depth_iter.rem; xcb_depth_next(_iter)) {
+  if (depth_iter.data->depth != depth)
+ continue;
+
+  visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+  if (visual_iter.rem)
+ return visual_iter.data;
+   }
+
+   return NULL;
+}
+
+static uint32_t
+get_red_mask_for_depth(struct vl_screen *vscreen, int depth)
+{
+   xcb_visualtype_t *visual = get_xcb_visualtype_for_depth(vscreen, depth);
+
+   if (visual) {
+  return visual->red_mask;
+   }
+
+   return 0;
+}
+
+uint32_t
+vl_dri2_format_for_depth(struct vl_screen *vscreen, int depth)
+{
+   switch (depth) {
+   case 24:
+   case 30:
+  /* Different preferred formats for different hw */
+  if (get_red_mask_for_depth(vscreen, 30) == 0x3ff)
+ return PIPE_FORMAT_R10G10B10X2_UNORM;
+  else
+ return PIPE_FORMAT_B10G10R10X2_UNORM;
+   default:
+  return PIPE_FORMAT_NONE;
+   }
+}
+
 struct vl_screen *
 vl_dri2_screen_create(Display *display, int screen)
 {
@@ -326,7 +378,6 @@ vl_dri2_screen_create(Display *display, int screen)
xcb_dri2_authenticate_cookie_t authenticate_cookie;
xcb_dri2_authenticate_reply_t *authenticate = NULL;
xcb_screen_iterator_t s;
-   xcb_screen_t *xcb_screen;
xcb_generic_error_t *error = NULL;
char *device_name;
int fd, device_name_length;
@@ -358,8 +409,8 @@ vl_dri2_screen_create(Display *display, int screen)
   goto free_query;
 
s = xcb_setup_roots_iterator(xcb_get_setup(scrn->conn));
-   xcb_screen = get_xcb_screen(s, screen);
-   if (!xcb_screen)
+   scrn->base.xcb_screen = get_xcb_screen(s, screen);
+   if (!scrn->base.xcb_screen)
   goto free_query;
 
driverType = XCB_DRI2_DRIVER_TYPE_DRI;
@@ -375,9 +426,8 @@ vl_dri2_screen_create(Display *display, int screen)
   }
}
 
-   connect_cookie = xcb_dri2_connect_unchecked(scrn->conn,
-   xcb_screen->root,
-   driverType);
+   connect_cookie = xcb_dri2_connect_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, driverType);
connect = xcb_dri2_connect_reply(scrn->conn, connect_cookie, NULL);
if (connect == NULL ||
connect->driver_name_length + connect->device_name_length == 0)
@@ -397,9 +447,8 @@ vl_dri2_screen_create(Display *display, int screen)
if (drmGetMagic(fd, ))
   goto close_fd;
 
-   authenticate_cookie = xcb_dri2_authenticate_unchecked(scrn->conn,
- xcb_screen->root,
- magic);
+   authenticate_cookie = xcb_dri2_authenticate_unchecked(
+  scrn->conn, ((xcb_screen_t *)(scrn->base.xcb_screen))->root, magic);
authenticate = xcb_dri2_authenticate_reply(scrn->conn, authenticate_cookie, 
NULL);
 
if 

Re: [Mesa-dev] [PATCH] radv: Support v3 of VK_EXT_vertex_attribute_divisor.

[Jason Ekstrand]

On Mon, Sep 10, 2018 at 2:53 PM Bas Nieuwenhuizen 
wrote:

> On Mon, Sep 10, 2018 at 8:59 PM Jason Ekstrand 
> wrote:
> >
> > I recommend CCing stable (I just did on mine) so that it goes into 18.2.
>
> You're right, added the CC in the commit when pushing. This has a
> dependency on 34a17a48d440add1da619efd054b50b210cd869b, which hasn't
> been marked though.
>

I forgot the CC when I pushed mine so I sent a manual e-mail to mesa-stable
asking them to back-port it and the XML/header update.

--Jason


> >
> > On Mon, Sep 10, 2018 at 1:35 PM Bas Nieuwenhuizen <
> b...@basnieuwenhuizen.nl> wrote:
> >>
> >> ---
> >>  src/amd/vulkan/radv_device.c  | 7 +++
> >>  src/amd/vulkan/radv_extensions.py | 2 +-
> >>  2 files changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> >> index 53f99a8cecd..7917ed7ffe5 100644
> >> --- a/src/amd/vulkan/radv_device.c
> >> +++ b/src/amd/vulkan/radv_device.c
> >> @@ -821,6 +821,13 @@ void radv_GetPhysicalDeviceFeatures2(
> >> features->inheritedConditionalRendering = false;
> >> break;
> >> }
> >> +   case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
> >> +
>  VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features =
> >> +
>  (VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
> >> +   features->vertexAttributeInstanceRateDivisor =
> VK_TRUE;
> >> +
>  features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
> >> +   break;
> >> +   }
> >> default:
> >> break;
> >> }
> >> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> >> index b5b9c137927..fa35aabd3ba 100644
> >> --- a/src/amd/vulkan/radv_extensions.py
> >> +++ b/src/amd/vulkan/radv_extensions.py
> >> @@ -105,7 +105,7 @@ EXTENSIONS = [
> >>  Extension('VK_EXT_sampler_filter_minmax', 1,
> 'device->rad_info.chip_class >= CIK'),
> >>  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
> >>  Extension('VK_EXT_shader_stencil_export', 1, True),
> >> -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
> >> +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
> >>  Extension('VK_AMD_draw_indirect_count',   1, True),
> >>  Extension('VK_AMD_gcn_shader',1, True),
> >>  Extension('VK_AMD_rasterization_order',   1,
> 'device->has_out_of_order_rast'),
> >> --
> >> 2.18.0
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture

[Marek Olšák]

Hi, thanks for the patch.

I've sent version 2 of the patch with additional fixes to this list.

Marek

On Sun, Sep 9, 2018 at 10:08 PM, Josh Pieper  wrote:
> And apparently I am incapable of operating git send-email, so it
> failed to include my context:
>
> When using Freecad, I was getting intermittent segfaults inside of
> mesa.  I traced it down to this path in st_cb_drawpixels.c where the
> result of pipe_transfer_map wasn't being checked.  In my case, it was
> returning NULL because nouveau_bo_new returned ENOENT.  I'm by no
> means a mesa developer, but this patch solves the problem for me and
> seems reasonable enough.
>
> Thanks!
> -Josh
>
> Josh Pieper wrote:
>> ---
>>  src/mesa/state_tracker/st_cb_drawpixels.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
>> b/src/mesa/state_tracker/st_cb_drawpixels.c
>> index cb50b7104a..8d39b8a01b 100644
>> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
>> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
>> @@ -566,6 +566,9 @@ make_texture(struct st_context *st,
>>dest = pipe_transfer_map(pipe, pt, 0, 0,
>> PIPE_TRANSFER_WRITE, 0, 0,
>> width, height, );
>> +  if (!dest) {
>> + return NULL;
>> +  }
>>
>>
>>/* Put image into texture transfer.
>> --
>> 2.17.1
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Validate the result of pipe_transfer_map in make_texture (v2)

[Marek Olšák]

From: Josh Pieper 

When using Freecad, I was getting intermittent segfaults inside of
mesa.  I traced it down to this path in st_cb_drawpixels.c where the
result of pipe_transfer_map wasn't being checked.  In my case, it was
returning NULL because nouveau_bo_new returned ENOENT.  I'm by no
means a mesa developer, but this patch solves the problem for me and
seems reasonable enough.

v2: Marek - also unmap the PBO and release the texture, and call
the make_texture function sooner for less cleanup

Cc: 18.1 18.2 
---
 src/mesa/state_tracker/st_cb_drawpixels.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c 
b/src/mesa/state_tracker/st_cb_drawpixels.c
index cb50b7104a0..4f08e751393 100644
--- a/src/mesa/state_tracker/st_cb_drawpixels.c
+++ b/src/mesa/state_tracker/st_cb_drawpixels.c
@@ -559,21 +559,25 @@ make_texture(struct st_context *st,
   GLubyte *dest;
   const GLbitfield imageTransferStateSave = ctx->_ImageTransferState;
 
   /* we'll do pixel transfer in a fragment shader */
   ctx->_ImageTransferState = 0x0;
 
   /* map texture transfer */
   dest = pipe_transfer_map(pipe, pt, 0, 0,
PIPE_TRANSFER_WRITE, 0, 0,
width, height, );
-
+  if (!dest) {
+ pipe_resource_reference(, NULL);
+ _mesa_unmap_pbo_source(ctx, unpack);
+ return NULL;
+  }
 
   /* Put image into texture transfer.
* Note that the image is actually going to be upside down in
* the texture.  We deal with that with texcoords.
*/
   if ((format == GL_RGBA || format == GL_BGRA)
   && type == GL_UNSIGNED_BYTE) {
  /* Use a memcpy-based texstore to avoid software pixel swizzling.
   * We'll do the necessary swizzling with the pipe_sampler_view to
   * give much better performance.
@@ -1167,20 +1171,27 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
   write_depth = GL_TRUE;
 
if (write_stencil &&
!pipe->screen->get_param(pipe->screen, PIPE_CAP_SHADER_STENCIL_EXPORT)) 
{
   /* software fallback */
   draw_stencil_pixels(ctx, x, y, width, height, format, type,
   unpack, pixels);
   return;
}
 
+   /* Put glDrawPixels image into a texture */
+   pt = make_texture(st, width, height, format, type, unpack, pixels);
+   if (!pt) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glDrawPixels");
+  return;
+   }
+
/*
 * 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);
@@ -1193,27 +1204,20 @@ st_DrawPixels(struct gl_context *ctx, GLint x, GLint y,
  st->pixel_xfer.pixelmap_sampler_view);
  num_sampler_view++;
   }
 
   /* compiling a new fragment shader variant added new state constants
* into the constant buffer, we need to update them
*/
   st_upload_constants(st, >fp->Base);
}
 
-   /* Put glDrawPixels image into a texture */
-   pt = make_texture(st, width, height, format, type, unpack, pixels);
-   if (!pt) {
-  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glDrawPixels");
-  return;
-   }
-
/* create sampler view for the image */
sv[0] = st_create_texture_sampler_view(st->pipe, pt);
if (!sv[0]) {
   _mesa_error(ctx, GL_OUT_OF_MEMORY, "glDrawPixels");
   pipe_resource_reference(, NULL);
   return;
}
 
/* Set up the sampler view's swizzle */
setup_sampler_swizzle(sv[0], format, type);
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] radv: Support v3 of VK_EXT_vertex_attribute_divisor.

[Bas Nieuwenhuizen]

On Mon, Sep 10, 2018 at 8:59 PM Jason Ekstrand  wrote:
>
> I recommend CCing stable (I just did on mine) so that it goes into 18.2.

You're right, added the CC in the commit when pushing. This has a
dependency on 34a17a48d440add1da619efd054b50b210cd869b, which hasn't
been marked though.

>
> On Mon, Sep 10, 2018 at 1:35 PM Bas Nieuwenhuizen  
> wrote:
>>
>> ---
>>  src/amd/vulkan/radv_device.c  | 7 +++
>>  src/amd/vulkan/radv_extensions.py | 2 +-
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
>> index 53f99a8cecd..7917ed7ffe5 100644
>> --- a/src/amd/vulkan/radv_device.c
>> +++ b/src/amd/vulkan/radv_device.c
>> @@ -821,6 +821,13 @@ void radv_GetPhysicalDeviceFeatures2(
>> features->inheritedConditionalRendering = false;
>> break;
>> }
>> +   case 
>> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
>> +   VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT 
>> *features =
>> +   
>> (VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
>> +   features->vertexAttributeInstanceRateDivisor = 
>> VK_TRUE;
>> +   features->vertexAttributeInstanceRateZeroDivisor = 
>> VK_TRUE;
>> +   break;
>> +   }
>> default:
>> break;
>> }
>> diff --git a/src/amd/vulkan/radv_extensions.py 
>> b/src/amd/vulkan/radv_extensions.py
>> index b5b9c137927..fa35aabd3ba 100644
>> --- a/src/amd/vulkan/radv_extensions.py
>> +++ b/src/amd/vulkan/radv_extensions.py
>> @@ -105,7 +105,7 @@ EXTENSIONS = [
>>  Extension('VK_EXT_sampler_filter_minmax', 1, 
>> 'device->rad_info.chip_class >= CIK'),
>>  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>>  Extension('VK_EXT_shader_stencil_export', 1, True),
>> -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
>> +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>>  Extension('VK_AMD_draw_indirect_count',   1, True),
>>  Extension('VK_AMD_gcn_shader',1, True),
>>  Extension('VK_AMD_rasterization_order',   1, 
>> 'device->has_out_of_order_rast'),
>> --
>> 2.18.0
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107869] u_thread.h:87:4: error: use of undeclared identifier 'cpu_set_t'

[bugzilla-daemon]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Olšák  ---
Fixed by 9f1bbbdbbd7.

-- 
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 v2] gallium: Correctly handle no config context creation

[Marek Olšák]

Pushed, thanks for the patch!

Marek

On Sat, Sep 8, 2018 at 11:57 PM, Elie Tournier  wrote:
> If you don't mind, can you please push this patch for me?
> I don't have git access.
>
> Thanks a lot,
> Elie
> On Fri, 7 Sep 2018 at 22:49, Marek Olšák  wrote:
>>
>> Reviewed-by: Marek Olšák 
>>
>> Marek
>>
>> On Thu, Sep 6, 2018 at 5:46 AM, Elie Tournier  
>> wrote:
>> > This patch fixes the following Piglit test:
>> > spec@egl_mesa_configless_context@basic
>> > It also fixes few test in a virgl guest.
>> >
>> > v2: Evaluate the value of no_config (Ilia)
>> >
>> > Suggested-by: Emil Velikov 
>> > Signed-off-by: Elie Tournier 
>> > ---
>> >  src/gallium/include/state_tracker/st_api.h  | 2 ++
>> >  src/gallium/state_trackers/dri/dri_screen.c | 4 +++-
>> >  src/mesa/state_tracker/st_manager.c | 9 -
>> >  3 files changed, 13 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/gallium/include/state_tracker/st_api.h 
>> > b/src/gallium/include/state_tracker/st_api.h
>> > index 61152e3546..2b63b8a3d2 100644
>> > --- a/src/gallium/include/state_tracker/st_api.h
>> > +++ b/src/gallium/include/state_tracker/st_api.h
>> > @@ -190,6 +190,8 @@ struct st_egl_image
>> >   */
>> >  struct st_visual
>> >  {
>> > +   bool no_config;
>> > +
>> > /**
>> >  * Available buffers.  Bitfield of ST_ATTACHMENT_*_MASK bits.
>> >  */
>> > diff --git a/src/gallium/state_trackers/dri/dri_screen.c 
>> > b/src/gallium/state_trackers/dri/dri_screen.c
>> > index 027e85024f..308e23685e 100644
>> > --- a/src/gallium/state_trackers/dri/dri_screen.c
>> > +++ b/src/gallium/state_trackers/dri/dri_screen.c
>> > @@ -308,8 +308,10 @@ dri_fill_st_visual(struct st_visual *stvis,
>> >  {
>> > memset(stvis, 0, sizeof(*stvis));
>> >
>> > -   if (!mode)
>> > +   if (!mode) {
>> > +  stvis->no_config = true;
>> >return;
>> > +   }
>> >
>> > /* Deduce the color format. */
>> > switch (mode->redMask) {
>> > diff --git a/src/mesa/state_tracker/st_manager.c 
>> > b/src/mesa/state_tracker/st_manager.c
>> > index 69286b5791..9ed316b0f7 100644
>> > --- a/src/mesa/state_tracker/st_manager.c
>> > +++ b/src/mesa/state_tracker/st_manager.c
>> > @@ -834,6 +834,7 @@ st_api_create_context(struct st_api *stapi, struct 
>> > st_manager *smapi,
>> > struct st_context *shared_ctx = (struct st_context *) shared_stctxi;
>> > struct st_context *st;
>> > struct pipe_context *pipe;
>> > +   struct gl_config* mode_ptr;
>> > struct gl_config mode;
>> > gl_api api;
>> > bool no_error = false;
>> > @@ -893,7 +894,13 @@ st_api_create_context(struct st_api *stapi, struct 
>> > st_manager *smapi,
>> > }
>> >
>> > st_visual_to_context_mode(>visual, );
>> > -   st = st_create_context(api, pipe, , shared_ctx,
>> > +
>> > +   if (attribs->visual.no_config)
>> > +  mode_ptr = NULL;
>> > +   else
>> > +  mode_ptr = 
>> > +
>> > +   st = st_create_context(api, pipe, mode_ptr, shared_ctx,
>> >>options, no_error);
>> > if (!st) {
>> >*error = ST_CONTEXT_ERROR_NO_MEMORY;
>> > --
>> > 2.18.0
>> >
>> > ___
>> > mesa-dev mailing list
>> > mesa-dev@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] VMware driver updates

[Brian Paul]

I've pushed a series of patches to update the VMware gallium driver.
This adds support for MSAA and a few new extensions.  See the 
docs/vmware-guest.html file for details.


These features depend on the upcoming releases of VMware Workstation 15 
and Fusion 11.


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

Re: [Mesa-dev] [PATCH] android: util/u_thread: fix building error with bionic pthread

[Marek Olšák]

On Mon, Sep 10, 2018 at 4:07 AM, Mauro Rossi  wrote:
> Hi,
>
> Il giorno lun 10 set 2018 alle ore 09:58 Tapani Pälli
>  ha scritto:
>>
>> Marek sent a similar fix here:
>> https://lists.freedesktop.org/archives/mesa-dev/2018-September/204797.html
>
> Thanks a lot!
> So the APU L3 cache optimization will be lost for Android

Hopefully Android won't be used on Ryzens with multiple CCXs. CPUs
without graphics have at least 2 CCXs. APUs have only 1.

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

Re: [Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

[Marek Olšák]

On Mon, Sep 10, 2018 at 12:11 PM, Dylan Baker  wrote:
> I agree that using code from mesa in util is gross, I'm not planning to leave 
> it
> like this. I'm in the middle of cleaning up duplication between util and mesa,
> and I'll plan on pulling u_cpu_detection down into src/util in that series.
>
> In this case while gross there shouldn't be any compilation issues,
> common_x86_features.h is a pure header implementation with no #include's if 
> any
> kind, so while a bit ugly this should be safe.

Yeah. If there is no compilation issue, it's probably fine.

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

Re: [Mesa-dev] [PATCH 0/8] Gallium & RadeonSI optimization for Ryzen CPUs

[Marek Olšák]

On Mon, Sep 10, 2018 at 10:45 AM, Michel Dänzer  wrote:
> On 2018-09-07 9:01 p.m., Marek Olšák wrote:
>> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer  wrote:
>>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
 On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer  wrote:
> On 2018-09-06 10:56 p.m., Axel Davy wrote:
>
>> I fear if we begin to do the work manually, there won't be interest to
>> do that in the kernel,
>> and thus all applications will need to include such core pinning code to
>> have good performance when
>> multithreaded.
>
> I'm also a bit worried that this solution could result in multiple
> processes contending for the same set of CPU cores, while other cores
> might be underused, which could result in worse overall system 
> performance.

 Any suggestion how to choose the ccx such that processes end up on a
 different one?
>>>
>>> One thing you could do is use a random initial offset. That should at
>>> least avoid e.g. most applications using the same toolkit (which may do
>>> OpenGL calls, even if the application itself doesn't) choosing the same one.
>>
>> I'll update the helper function to choose the initial CCX with
>> (os_time_get_nano() % num_L3_caches). That should be random.
>
> Why not use an RNG API for getting a random number?

It depends on apps calling srand.

>
>
>>> In the worst case, all processes using OpenGL (or at least their OpenGL
>>> related threads, but that usually includes the main thread) could end up
>>> restricted to the same 4 cores, leaving up to 28 cores underused.
>>
>> 4C/4T used to be a standard and certainly enough for gaming. 4C/8T
>> used to be luxury before Ryzen, which is now the CCX. We should be
>> fine with 4 cores.
>
> Sounds like "640K of memory ought to be enough for anybody"...
>
>
> Anyway, per reports on IRC, the core pinning can hurt even individual
> applications, e.g. blender. I like your idea of a driconf option, but it
> should be disabled by default, and only enabled for apps where it's
> known safe and beneficial in practice.

Before we do anything, we can be discuss it with Blender developers or
we can add drirc entry for Blender.

I don't think we have any other option. Disabling the optimization
would make Mesa multithreading slower than singlethreading.

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

Re: [Mesa-dev] [PATCH] radv: Support v3 of VK_EXT_vertex_attribute_divisor.

[Jason Ekstrand]

I recommend CCing stable (I just did on mine) so that it goes into 18.2.

On Mon, Sep 10, 2018 at 1:35 PM Bas Nieuwenhuizen 
wrote:

> ---
>  src/amd/vulkan/radv_device.c  | 7 +++
>  src/amd/vulkan/radv_extensions.py | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 53f99a8cecd..7917ed7ffe5 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -821,6 +821,13 @@ void radv_GetPhysicalDeviceFeatures2(
> features->inheritedConditionalRendering = false;
> break;
> }
> +   case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
> +   VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT
> *features =
> +
>  (VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
> +   features->vertexAttributeInstanceRateDivisor =
> VK_TRUE;
> +   features->vertexAttributeInstanceRateZeroDivisor =
> VK_TRUE;
> +   break;
> +   }
> default:
> break;
> }
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index b5b9c137927..fa35aabd3ba 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -105,7 +105,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_sampler_filter_minmax', 1,
> 'device->rad_info.chip_class >= CIK'),
>  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>  Extension('VK_EXT_shader_stencil_export', 1, True),
> -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
> +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>  Extension('VK_AMD_draw_indirect_count',   1, True),
>  Extension('VK_AMD_gcn_shader',1, True),
>  Extension('VK_AMD_rasterization_order',   1,
> 'device->has_out_of_order_rast'),
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: Support v3 of VK_EXT_vertex_attribute_divisor

[Jason Ekstrand]

This should go into 18.2 which means also back-porting the header update
which shouldn't be a big deal.  I have a feeling DXVK will add a hard
requirement on v3 fairly shortly so it would be good if it works in
released mesa.

On Mon, Sep 10, 2018 at 1:44 PM Jason Ekstrand  wrote:

> On Mon, Sep 10, 2018 at 1:43 PM Bas Nieuwenhuizen 
> wrote:
>
>> I tried, but I can't find from your driver what the HW does, so for
>> this review the same assumption that the CTS tests pass for you.
>>
>
> Our hardware does the DX thing which is also what the spec says.  Yes, we
> pass the tests.
>
> Reviewed-by: Bas Nieuwenhuizen 
>>
>
> Thanks!
>
>
>> On Mon, Sep 10, 2018 at 7:08 PM Jason Ekstrand 
>> wrote:
>> >
>> > Cc: Bas Nieuwenhuizen 
>> > ---
>> >  src/intel/vulkan/anv_device.c  | 8 
>> >  src/intel/vulkan/anv_extensions.py | 2 +-
>> >  2 files changed, 9 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/intel/vulkan/anv_device.c
>> b/src/intel/vulkan/anv_device.c
>> > index 7ab8543300b..44855dae128 100644
>> > --- a/src/intel/vulkan/anv_device.c
>> > +++ b/src/intel/vulkan/anv_device.c
>> > @@ -934,6 +934,14 @@ void anv_GetPhysicalDeviceFeatures2(
>> >   break;
>> >}
>> >
>> > +  case
>> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
>> > + VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features =
>> > +(VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
>> > + features->vertexAttributeInstanceRateDivisor = VK_TRUE;
>> > + features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
>> > + break;
>> > +  }
>> > +
>> >default:
>> >   anv_debug_ignored_stype(ext->sType);
>> >   break;
>> > diff --git a/src/intel/vulkan/anv_extensions.py
>> b/src/intel/vulkan/anv_extensions.py
>> > index a21aee5a001..951505a854e 100644
>> > --- a/src/intel/vulkan/anv_extensions.py
>> > +++ b/src/intel/vulkan/anv_extensions.py
>> > @@ -122,7 +122,7 @@ EXTENSIONS = [
>> >'device->has_context_priority'),
>> >  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>> >  Extension('VK_EXT_shader_stencil_export', 1,
>> 'device->info.gen >= 9'),
>> > -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
>> > +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>> >  Extension('VK_EXT_post_depth_coverage',   1,
>> 'device->info.gen >= 9'),
>> >  Extension('VK_EXT_sampler_filter_minmax', 1,
>> 'device->info.gen >= 9'),
>> >  ]
>> > --
>> > 2.17.1
>> >
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] gallium/auxiliary: don't dereference counters twice needlessly

[Marek Olšák]

On Mon, Sep 10, 2018 at 11:41 AM, Michel Dänzer  wrote:
> On 2018-09-07 11:35 p.m., Marek Olšák wrote:
>> From: Marek Olšák 
>>
>> +1.2% performance with:
>> piglit/drawoverhead - DrawElements (no state changes) on radeonsi
>
> No meaningless number (which is most likely the same order of magnitude,
> maybe even smaller than the deviation between test runs) in the commit
> log please.

I think you are bikeshedding a little too much. The improvement was
reproducible with many runs. It was before the optimization for Ryzen
though.

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

[Mesa-dev] [PATCH] nir: do not remove varyings used for transform feedback

[Samuel Pitoiset]

When a xfb buffer is explicitely declared on a varying
variable, we shouldn't remove it at link time.

Signed-off-by: Samuel Pitoiset 
---
 src/compiler/nir/nir_linking_helpers.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/compiler/nir/nir_linking_helpers.c 
b/src/compiler/nir/nir_linking_helpers.c
index 85712a7cb1c..a710ba3da25 100644
--- a/src/compiler/nir/nir_linking_helpers.c
+++ b/src/compiler/nir/nir_linking_helpers.c
@@ -112,6 +112,9 @@ remove_unused_io_vars(nir_shader *shader, struct exec_list 
*var_list,
   if (var->data.always_active_io)
  continue;
 
+  if (var->data.explicit_xfb_buffer)
+ continue;
+
   uint64_t other_stage = used[var->data.location_frac];
 
   if (!(other_stage & get_variable_io_mask(var, shader->info.stage))) {
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH 2/2] anv: Support v3 of VK_EXT_vertex_attribute_divisor

[Jason Ekstrand]

On Mon, Sep 10, 2018 at 1:43 PM Bas Nieuwenhuizen 
wrote:

> I tried, but I can't find from your driver what the HW does, so for
> this review the same assumption that the CTS tests pass for you.
>

Our hardware does the DX thing which is also what the spec says.  Yes, we
pass the tests.

Reviewed-by: Bas Nieuwenhuizen 
>

Thanks!


> On Mon, Sep 10, 2018 at 7:08 PM Jason Ekstrand 
> wrote:
> >
> > Cc: Bas Nieuwenhuizen 
> > ---
> >  src/intel/vulkan/anv_device.c  | 8 
> >  src/intel/vulkan/anv_extensions.py | 2 +-
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index 7ab8543300b..44855dae128 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -934,6 +934,14 @@ void anv_GetPhysicalDeviceFeatures2(
> >   break;
> >}
> >
> > +  case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
> > + VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features =
> > +(VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
> > + features->vertexAttributeInstanceRateDivisor = VK_TRUE;
> > + features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
> > + break;
> > +  }
> > +
> >default:
> >   anv_debug_ignored_stype(ext->sType);
> >   break;
> > diff --git a/src/intel/vulkan/anv_extensions.py
> b/src/intel/vulkan/anv_extensions.py
> > index a21aee5a001..951505a854e 100644
> > --- a/src/intel/vulkan/anv_extensions.py
> > +++ b/src/intel/vulkan/anv_extensions.py
> > @@ -122,7 +122,7 @@ EXTENSIONS = [
> >'device->has_context_priority'),
> >  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
> >  Extension('VK_EXT_shader_stencil_export', 1,
> 'device->info.gen >= 9'),
> > -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
> > +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
> >  Extension('VK_EXT_post_depth_coverage',   1,
> 'device->info.gen >= 9'),
> >  Extension('VK_EXT_sampler_filter_minmax', 1,
> 'device->info.gen >= 9'),
> >  ]
> > --
> > 2.17.1
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] anv: Support v3 of VK_EXT_vertex_attribute_divisor

[Bas Nieuwenhuizen]

I tried, but I can't find from your driver what the HW does, so for
this review the same assumption that the CTS tests pass for you.

Reviewed-by: Bas Nieuwenhuizen 
On Mon, Sep 10, 2018 at 7:08 PM Jason Ekstrand  wrote:
>
> Cc: Bas Nieuwenhuizen 
> ---
>  src/intel/vulkan/anv_device.c  | 8 
>  src/intel/vulkan/anv_extensions.py | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index 7ab8543300b..44855dae128 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -934,6 +934,14 @@ void anv_GetPhysicalDeviceFeatures2(
>   break;
>}
>
> +  case 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
> + VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features =
> +(VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
> + features->vertexAttributeInstanceRateDivisor = VK_TRUE;
> + features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
> + break;
> +  }
> +
>default:
>   anv_debug_ignored_stype(ext->sType);
>   break;
> diff --git a/src/intel/vulkan/anv_extensions.py 
> b/src/intel/vulkan/anv_extensions.py
> index a21aee5a001..951505a854e 100644
> --- a/src/intel/vulkan/anv_extensions.py
> +++ b/src/intel/vulkan/anv_extensions.py
> @@ -122,7 +122,7 @@ EXTENSIONS = [
>'device->has_context_priority'),
>  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>  Extension('VK_EXT_shader_stencil_export', 1, 
> 'device->info.gen >= 9'),
> -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
> +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>  Extension('VK_EXT_post_depth_coverage',   1, 
> 'device->info.gen >= 9'),
>  Extension('VK_EXT_sampler_filter_minmax', 1, 
> 'device->info.gen >= 9'),
>  ]
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107890] [bisected] Android build test fails "use of undeclared identifier 'cpu_set_t'/'cpuset'"

[bugzilla-daemon]

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

--- Comment #1 from Tapani Pälli  ---
Fix here:
https://lists.freedesktop.org/archives/mesa-dev/2018-September/204797.html

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

Re: [Mesa-dev] [PATCH] radv: Support v3 of VK_EXT_vertex_attribute_divisor.

[Jason Ekstrand]

Assuming you pass the CTS tests (which I'm pretty sure you do),

Reviewed-by: Jason Ekstrand 

Mind reviewing mine?

On Mon, Sep 10, 2018 at 1:35 PM Bas Nieuwenhuizen 
wrote:

> ---
>  src/amd/vulkan/radv_device.c  | 7 +++
>  src/amd/vulkan/radv_extensions.py | 2 +-
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 53f99a8cecd..7917ed7ffe5 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -821,6 +821,13 @@ void radv_GetPhysicalDeviceFeatures2(
> features->inheritedConditionalRendering = false;
> break;
> }
> +   case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
> +   VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT
> *features =
> +
>  (VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
> +   features->vertexAttributeInstanceRateDivisor =
> VK_TRUE;
> +   features->vertexAttributeInstanceRateZeroDivisor =
> VK_TRUE;
> +   break;
> +   }
> default:
> break;
> }
> diff --git a/src/amd/vulkan/radv_extensions.py
> b/src/amd/vulkan/radv_extensions.py
> index b5b9c137927..fa35aabd3ba 100644
> --- a/src/amd/vulkan/radv_extensions.py
> +++ b/src/amd/vulkan/radv_extensions.py
> @@ -105,7 +105,7 @@ EXTENSIONS = [
>  Extension('VK_EXT_sampler_filter_minmax', 1,
> 'device->rad_info.chip_class >= CIK'),
>  Extension('VK_EXT_shader_viewport_index_layer',   1, True),
>  Extension('VK_EXT_shader_stencil_export', 1, True),
> -Extension('VK_EXT_vertex_attribute_divisor',  2, True),
> +Extension('VK_EXT_vertex_attribute_divisor',  3, True),
>  Extension('VK_AMD_draw_indirect_count',   1, True),
>  Extension('VK_AMD_gcn_shader',1, True),
>  Extension('VK_AMD_rasterization_order',   1,
> 'device->has_out_of_order_rast'),
> --
> 2.18.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] radv: Support v3 of VK_EXT_vertex_attribute_divisor.

[Bas Nieuwenhuizen]

---
 src/amd/vulkan/radv_device.c  | 7 +++
 src/amd/vulkan/radv_extensions.py | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 53f99a8cecd..7917ed7ffe5 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -821,6 +821,13 @@ void radv_GetPhysicalDeviceFeatures2(
features->inheritedConditionalRendering = false;
break;
}
+   case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
+   VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT 
*features =
+   
(VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
+   features->vertexAttributeInstanceRateDivisor = VK_TRUE;
+   features->vertexAttributeInstanceRateZeroDivisor = 
VK_TRUE;
+   break;
+   }
default:
break;
}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index b5b9c137927..fa35aabd3ba 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -105,7 +105,7 @@ EXTENSIONS = [
 Extension('VK_EXT_sampler_filter_minmax', 1, 
'device->rad_info.chip_class >= CIK'),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_EXT_shader_stencil_export', 1, True),
-Extension('VK_EXT_vertex_attribute_divisor',  2, True),
+Extension('VK_EXT_vertex_attribute_divisor',  3, True),
 Extension('VK_AMD_draw_indirect_count',   1, True),
 Extension('VK_AMD_gcn_shader',1, True),
 Extension('VK_AMD_rasterization_order',   1, 
'device->has_out_of_order_rast'),
-- 
2.18.0

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

[Mesa-dev] [RFC 6/7] HACK: Disable the instruction scheduler

[Jason Ekstrand]

The instruction scheduler is re-ordering loads which is causing fence
values to be loaded after the value they're fencing.  In particular,
consider the following pseudocode:

void try_use_a_thing(int idx)
{
bool ready = ssbo.arr[idx].ready;
vec4 data = ssbo.arr[idx].data;
if (ready)
use(data);
}

void write_a_thing(int idx, vec4 data)
{
ssbo.arr[idx].data = data;
ssbo.arr[idx].ready = true;
}

Our current instruction scheduling scheme doesn't see any problem with
re-ordering the load of "ready" with respect to the load of "data".
However, if try_use_a_thing is called in one thread and write_a_thing is
called in another thread, such re-ordering could cause invalid data to
be used.  Normally, some re-ordering of loads is fine; however, with the
Vulkan memory model, there are some additional guarantees that are
provided particularly in the case of atomic loads which we currently
don't differentiate in any way in the back-end.

Obviously, we need to come up with something better for this than just
shutting off the scheduler but I wanted to send this out earlier rather
than later and provide the opportunity for a discussion.
---
 src/intel/compiler/brw_fs.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 3f7f2b4c984..9df238a6f6a 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -6427,7 +6427,7 @@ fs_visitor::allocate_registers(unsigned 
min_dispatch_width, bool allow_spilling)
 * performance but increasing likelihood of allocating.
 */
for (unsigned i = 0; i < ARRAY_SIZE(pre_modes); i++) {
-  schedule_instructions(pre_modes[i]);
+  //schedule_instructions(pre_modes[i]);
 
   if (0) {
  assign_regs_trivial();
@@ -6478,7 +6478,7 @@ fs_visitor::allocate_registers(unsigned 
min_dispatch_width, bool allow_spilling)
 
opt_bank_conflicts();
 
-   schedule_instructions(SCHEDULE_POST);
+   //schedule_instructions(SCHEDULE_POST);
 
if (last_scratch > 0) {
   MAYBE_UNUSED unsigned max_scratch_size = 2 * 1024 * 1024;
-- 
2.17.1

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

[Mesa-dev] [RFC 7/7] anv: Advertise support for VK_KHR_vulkan_memory_model

[Jason Ekstrand]

---
 src/intel/vulkan/anv_device.c  | 7 +++
 src/intel/vulkan/anv_extensions.py | 1 +
 src/intel/vulkan/anv_pipeline.c| 1 +
 3 files changed, 9 insertions(+)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 47c6c6e93b4..9b15fc0648b 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -898,6 +898,13 @@ void anv_GetPhysicalDeviceFeatures2(
  break;
   }
 
+  case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR: 
{
+ VkPhysicalDeviceVulkanMemoryModelFeaturesKHR *features =
+(VkPhysicalDeviceVulkanMemoryModelFeaturesKHR *)ext;
+ features->vulkanMemoryModel = VK_TRUE;
+ break;
+  }
+
   case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_YCBCR_CONVERSION_FEATURES: {
  VkPhysicalDeviceSamplerYcbcrConversionFeatures *features =
 (VkPhysicalDeviceSamplerYcbcrConversionFeatures *) ext;
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index a21aee5a001..53759b6dc49 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -107,6 +107,7 @@ EXTENSIONS = [
 Extension('VK_KHR_surface',  25, 
'ANV_HAS_SURFACE'),
 Extension('VK_KHR_swapchain',68, 
'ANV_HAS_SURFACE'),
 Extension('VK_KHR_variable_pointers', 1, True),
+Extension('VK_KHR_vulkan_memory_model',   1, True),
 Extension('VK_KHR_wayland_surface',   6, 
'VK_USE_PLATFORM_WAYLAND_KHR'),
 Extension('VK_KHR_xcb_surface',   6, 
'VK_USE_PLATFORM_XCB_KHR'),
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index be05c11f45d..1a8dfda5096 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -156,6 +156,7 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline,
  .stencil_export = device->instance->physicalDevice.info.gen >= 9,
  .storage_8bit = device->instance->physicalDevice.info.gen >= 8,
  .post_depth_coverage = device->instance->physicalDevice.info.gen >= 9,
+ .vk_memory_model = true,
   },
};
 
-- 
2.17.1

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

[Mesa-dev] [RFC 5/7] spirv: Add support for the Vulkan memory model

[Jason Ekstrand]

---
 src/compiler/shader_info.h|  1 +
 src/compiler/spirv/spirv_to_nir.c | 20 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 65bc0588d67..a19840666ac 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -62,6 +62,7 @@ struct spirv_supported_capabilities {
bool post_depth_coverage;
bool transform_feedback;
bool geometry_streams;
+   bool vk_memory_model;
 };
 
 typedef struct shader_info {
diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 3378641513c..dcce05ce83b 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3600,6 +3600,10 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
  spv_check_supported(post_depth_coverage, cap);
  break;
 
+  case SpvCapabilityVulkanMemoryModelKHR:
+ spv_check_supported(vk_memory_model, cap);
+ break;
+
   default:
  vtn_fail("Unhandled capability");
   }
@@ -3612,8 +3616,20 @@ vtn_handle_preamble_instruction(struct vtn_builder *b, 
SpvOp opcode,
 
case SpvOpMemoryModel:
   vtn_assert(w[1] == SpvAddressingModelLogical);
-  vtn_assert(w[2] == SpvMemoryModelSimple ||
- w[2] == SpvMemoryModelGLSL450);
+  switch (w[2]) {
+  case SpvMemoryModelSimple:
+  case SpvMemoryModelGLSL450:
+ break;
+
+  case SpvMemoryModelVulkanKHR:
+ vtn_fail_if(!b->options->caps.vk_memory_model,
+ "Vulkan memory model is unsupported by this driver");
+ break;
+
+  default:
+ vtn_fail("Unsupported memory model: %s",
+  spirv_memorymodel_to_string(w[2]));
+  }
   break;
 
case SpvOpEntryPoint:
-- 
2.17.1

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

[Mesa-dev] [RFC 4/7] spirv: Insert barriers to follow the Vulkan memory model

[Jason Ekstrand]

---
 src/compiler/spirv/spirv_to_nir.c | 170 ++
 1 file changed, 103 insertions(+), 67 deletions(-)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 96224354057..3378641513c 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -2314,6 +2314,79 @@ fill_common_atomic_sources(struct vtn_builder *b, SpvOp 
opcode,
}
 }
 
+static void
+vtn_emit_barrier(struct vtn_builder *b, nir_intrinsic_op op)
+{
+   nir_intrinsic_instr *intrin = nir_intrinsic_instr_create(b->shader, op);
+   nir_builder_instr_insert(>nb, >instr);
+}
+
+static void
+vtn_emit_memory_barrier(struct vtn_builder *b, SpvScope scope,
+SpvMemorySemanticsMask semantics)
+{
+   static const SpvMemorySemanticsMask all_memory_semantics =
+  SpvMemorySemanticsUniformMemoryMask |
+  SpvMemorySemanticsWorkgroupMemoryMask |
+  SpvMemorySemanticsAtomicCounterMemoryMask |
+  SpvMemorySemanticsImageMemoryMask |
+  SpvMemorySemanticsOutputMemoryKHRMask |
+  SpvMemorySemanticsMakeAvailableKHRMask |
+  SpvMemorySemanticsMakeVisibleKHRMask;
+
+   /* If we're not actually doing a memory barrier, bail */
+   if (!(semantics & all_memory_semantics))
+  return;
+
+   /* GL and Vulkan don't have these */
+   vtn_assert(scope != SpvScopeCrossDevice);
+
+   if (scope == SpvScopeSubgroup)
+  return; /* Nothing to do here */
+
+   if (scope == SpvScopeWorkgroup) {
+  vtn_emit_barrier(b, nir_intrinsic_group_memory_barrier);
+  return;
+   }
+
+   /* There's only three scopes left */
+   vtn_assert(scope == SpvScopeInvocation ||
+  scope == SpvScopeDevice ||
+  scope == SpvScopeQueueFamilyKHR);
+
+   if ((semantics & all_memory_semantics) == all_memory_semantics) {
+  vtn_emit_barrier(b, nir_intrinsic_memory_barrier);
+  return;
+   }
+
+   /* Issue a bunch of more specific barriers */
+   uint32_t bits = semantics;
+   while (bits) {
+  SpvMemorySemanticsMask semantic = 1 << u_bit_scan();
+  switch (semantic) {
+  case SpvMemorySemanticsUniformMemoryMask:
+ vtn_emit_barrier(b, nir_intrinsic_memory_barrier_buffer);
+ break;
+  case SpvMemorySemanticsWorkgroupMemoryMask:
+ vtn_emit_barrier(b, nir_intrinsic_memory_barrier_shared);
+ break;
+  case SpvMemorySemanticsAtomicCounterMemoryMask:
+ vtn_emit_barrier(b, nir_intrinsic_memory_barrier_atomic_counter);
+ break;
+  case SpvMemorySemanticsImageMemoryMask:
+ vtn_emit_barrier(b, nir_intrinsic_memory_barrier_image);
+ break;
+  case SpvMemorySemanticsOutputMemoryKHRMask:
+  case SpvMemorySemanticsMakeAvailableKHRMask:
+  case SpvMemorySemanticsMakeVisibleKHRMask:
+ vtn_emit_barrier(b, nir_intrinsic_memory_barrier);
+ return;
+  default:
+ break;;
+  }
+   }
+}
+
 static nir_ssa_def *
 get_image_coord(struct vtn_builder *b, uint32_t value)
 {
@@ -2357,6 +2430,8 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
}
 
struct vtn_image_pointer image;
+   SpvScope scope = SpvScopeInvocation;
+   SpvMemorySemanticsMask semantics = 0;
 
switch (opcode) {
case SpvOpAtomicExchange:
@@ -2375,10 +2450,14 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
case SpvOpAtomicOr:
case SpvOpAtomicXor:
   image = *vtn_value(b, w[3], vtn_value_type_image_pointer)->image;
+  scope = vtn_constant_value(b, w[4])->values[0].u32[0];
+  semantics = vtn_constant_value(b, w[5])->values[0].u32[0];
   break;
 
case SpvOpAtomicStore:
   image = *vtn_value(b, w[1], vtn_value_type_image_pointer)->image;
+  scope = vtn_constant_value(b, w[2])->values[0].u32[0];
+  semantics = vtn_constant_value(b, w[3])->values[0].u32[0];
   break;
 
case SpvOpImageQuerySize:
@@ -2417,6 +2496,8 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
   vtn_fail("Invalid image opcode");
}
 
+   semantics |= SpvMemorySemanticsImageMemoryMask;
+
nir_intrinsic_op op;
switch (opcode) {
 #define OP(S, N) case SpvOp##S: op = nir_intrinsic_image_deref_##N; break;
@@ -2493,6 +2574,9 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
   vtn_fail("Invalid image opcode");
}
 
+   if (opcode == SpvOpAtomicLoad)
+  vtn_emit_memory_barrier(b, scope, semantics);
+
if (opcode != SpvOpImageWrite && opcode != SpvOpAtomicStore) {
   struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_ssa);
   struct vtn_type *type = vtn_value(b, w[1], vtn_value_type_type)->type;
@@ -2516,6 +2600,9 @@ vtn_handle_image(struct vtn_builder *b, SpvOp opcode,
} else {
   nir_builder_instr_insert(>nb, >instr);
}
+
+   if (opcode == SpvOpAtomicStore)
+  vtn_emit_memory_barrier(b, scope, semantics);
 }
 
 static nir_intrinsic_op
@@ -2634,6 +2721,8 @@ vtn_handle_atomics(struct vtn_builder *b, SpvOp opcode,
 {
struct vtn_pointer *ptr;
   

[Mesa-dev] [RFC 3/7] spirv/info: Add a memorymodel_to_string helper

[Jason Ekstrand]

---
 src/compiler/spirv/spirv_info.h| 1 +
 src/compiler/spirv/spirv_info_c.py | 1 +
 2 files changed, 2 insertions(+)

diff --git a/src/compiler/spirv/spirv_info.h b/src/compiler/spirv/spirv_info.h
index 121ffd2febb..9813035e60f 100644
--- a/src/compiler/spirv/spirv_info.h
+++ b/src/compiler/spirv/spirv_info.h
@@ -28,6 +28,7 @@
 
 const char *spirv_capability_to_string(SpvCapability cap);
 const char *spirv_decoration_to_string(SpvDecoration dec);
+const char *spirv_memorymodel_to_string(SpvMemoryModel cap);
 const char *spirv_op_to_string(SpvOp op);
 
 #endif /* SPIRV_INFO_H */
diff --git a/src/compiler/spirv/spirv_info_c.py 
b/src/compiler/spirv/spirv_info_c.py
index ff7942bcd3a..f5ed040008e 100644
--- a/src/compiler/spirv/spirv_info_c.py
+++ b/src/compiler/spirv/spirv_info_c.py
@@ -90,6 +90,7 @@ if __name__ == "__main__":
 info = [
 collect_data(spirv_info, "Capability"),
 collect_data(spirv_info, "Decoration"),
+collect_data(spirv_info, "MemoryModel"),
 collect_opcodes(spirv_info),
 ]
 
-- 
2.17.1

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

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

[Jason Ekstrand]

---
 include/vulkan/vulkan_core.h | 139 +++--
 src/vulkan/registry/vk.xml   | 280 +++
 2 files changed, 345 insertions(+), 74 deletions(-)

diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 06c860707b8..fe450142503 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 80
+#define VK_HEADER_VERSION 84
 
 
 #define VK_NULL_HANDLE 0
@@ -305,6 +305,8 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV = 158000,
 VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT = 161000,
 VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN = 162000,
+VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT = 167000,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT = 167001,
 VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173000,
 VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173001,
 VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR = 173002,
@@ -380,6 +382,10 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID = 1000129005,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT = 
100013,
 VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT = 1000130001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT = 
1000138000,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT = 
1000138001,
+VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT = 
1000138002,
+VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT = 
1000138003,
 VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT = 1000143000,
 VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT = 1000143001,
 VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT = 
1000143002,
@@ -406,6 +412,11 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD = 1000185000,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT 
= 100019,
 VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT = 
1000190001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT = 
1000190002,
+VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV = 1000206000,
+VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV = 1000206001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 
1000211000,
+VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = 
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
 VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES,
@@ -440,6 +451,7 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES,
 VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO,
+VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT = 
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO,
 VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR = 
VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES,
 VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO,
@@ -1118,6 +1130,7 @@ typedef enum VkDescriptorType {
 VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC = 8,
 VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC = 9,
 VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT = 10,
+VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT = 1000138000,
 VK_DESCRIPTOR_TYPE_BEGIN_RANGE = VK_DESCRIPTOR_TYPE_SAMPLER,
 VK_DESCRIPTOR_TYPE_END_RANGE = VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
 VK_DESCRIPTOR_TYPE_RANGE_SIZE = (VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT - 
VK_DESCRIPTOR_TYPE_SAMPLER + 1),
@@ -4573,7 +4586,6 @@ VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSurfaceKHR)
 
 #define VK_KHR_SURFACE_SPEC_VERSION   25
 #define VK_KHR_SURFACE_EXTENSION_NAME "VK_KHR_surface"
-#define VK_COLORSPACE_SRGB_NONLINEAR_KHR  VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
 
 
 typedef enum VkColorSpaceKHR {
@@ -4592,6 +4604,7 @@ typedef enum VkColorSpaceKHR {
 VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT = 1000104012,
 

[Mesa-dev] [RFC 0/7] anv: Support VK_KHR_vulkan_memory_model

[Jason Ekstrand]

This patch series adds support to the Intel Vulkan driver for the
(currently provisional) VK_KHR_vulkan_memory_model extension.  The
extension provides a few extra SPIR-V decorations along with some
additional guarantees about memory transaction ordering that aim to make
better analysis and use of concurrency possible in Vulkan.  In particular,
it provides sufficient guarantees to allow for the creation and use of
basic lock-free data structures in Vulkan shaders.

The current implementation does little more than rework the barrier code in
the SPIR-V to NIR pass.  This is mostly because NIR currently does little
to no optimization on external memory access.  As we begin to add more
optimizations in this area, we will need to be careful to think about the
Vulkan memory model to ensure that we continue to provide the right
guarantees.  It also points out just how awkward our current handling of
barriers is in NIR.

This series is sent out as an RFC at this point to make people aware of the
extension and to get the discussion going on how we want to do things "for
real".  Also, as can be seen from patch 6, there's still a little work
needed in the Intel back-end compiler to properly support this. :-)

The series can be found on my gitlab:

https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/VK_KHR_vulkan_memory_model

Cc: Kenneth Graunke 
Cc: Matt Turner 
Cc: Francisco Jerez 
Cc: Timothy Arceri 
Cc: Caio Marcelo de Oliveira Filho 
Cc: Bas Nieuwenhuizen 

Jason Ekstrand (7):
  vulkan: Update the XML and headers to 1.1.84
  spirv: Update Json and headers from Khronos GitHub master
  spirv/info: Add a memorymodel_to_string helper
  spirv: Insert barriers to follow the Vulkan memory model
  spirv: Add support for the Vulkan memory model
  HACK: Disable the instruction scheduler
  anv: Advertise support for VK_KHR_vulkan_memory_model

 include/vulkan/vulkan_core.h   | 139 +-
 src/compiler/shader_info.h |   1 +
 src/compiler/spirv/spirv.core.grammar.json |  95 ++-
 src/compiler/spirv/spirv.h |  24 ++
 src/compiler/spirv/spirv_info.h|   1 +
 src/compiler/spirv/spirv_info_c.py |   1 +
 src/compiler/spirv/spirv_to_nir.c  | 190 +-
 src/intel/compiler/brw_fs.cpp  |   4 +-
 src/intel/vulkan/anv_device.c  |   7 +
 src/intel/vulkan/anv_extensions.py |   1 +
 src/intel/vulkan/anv_pipeline.c|   1 +
 src/vulkan/registry/vk.xml | 280 -
 12 files changed, 594 insertions(+), 150 deletions(-)

-- 
2.17.1

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

[Mesa-dev] [RFC 2/7] spirv: Update Json and headers from Khronos GitHub master

[Jason Ekstrand]

---
 src/compiler/spirv/spirv.core.grammar.json | 95 --
 src/compiler/spirv/spirv.h | 24 ++
 2 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/src/compiler/spirv/spirv.core.grammar.json 
b/src/compiler/spirv/spirv.core.grammar.json
index cb641420d07..978353ae97c 100644
--- a/src/compiler/spirv/spirv.core.grammar.json
+++ b/src/compiler/spirv/spirv.core.grammar.json
@@ -4010,6 +4010,32 @@
   "parameters" : [
 { "kind" : "IdRef" }
   ]
+},
+{
+  "enumerant" : "MakeTexelAvailableKHR",
+  "value" : "0x0100",
+  "capabilities" : [ "VulkanMemoryModelKHR" ],
+  "parameters" : [
+{ "kind" : "IdScope" }
+  ]
+},
+{
+  "enumerant" : "MakeTexelVisibleKHR",
+  "value" : "0x0200",
+  "capabilities" : [ "VulkanMemoryModelKHR" ],
+  "parameters" : [
+{ "kind" : "IdScope" }
+  ]
+},
+{
+  "enumerant" : "NonPrivateTexelKHR",
+  "value" : "0x0400",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
+},
+{
+  "enumerant" : "VolatileTexelKHR",
+  "value" : "0x0800",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
 }
   ]
 },
@@ -4176,6 +4202,21 @@
 {
   "enumerant" : "ImageMemory",
   "value" : "0x0800"
+},
+{
+  "enumerant" : "OutputMemoryKHR",
+  "value" : "0x1000",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
+},
+{
+  "enumerant" : "MakeAvailableKHR",
+  "value" : "0x2000",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
+},
+{
+  "enumerant" : "MakeVisibleKHR",
+  "value" : "0x4000",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
 }
   ]
 },
@@ -4201,6 +4242,27 @@
 {
   "enumerant" : "Nontemporal",
   "value" : "0x0004"
+},
+{
+  "enumerant" : "MakePointerAvailableKHR",
+  "value" : "0x0008",
+  "parameters" : [
+{ "kind" : "IdScope" }
+  ],
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
+},
+{
+  "enumerant" : "MakePointerVisibleKHR",
+  "value" : "0x0010",
+  "parameters" : [
+{ "kind" : "IdScope" }
+  ],
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
+},
+{
+  "enumerant" : "NonPrivatePointerKHR",
+  "value" : "0x0020",
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
 }
   ]
 },
@@ -4328,6 +4390,11 @@
   "enumerant" : "OpenCL",
   "value" : 2,
   "capabilities" : [ "Kernel" ]
+},
+{
+  "enumerant" : "VulkanKHR",
+  "value" : 3,
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
 }
   ]
 },
@@ -4659,11 +4726,12 @@
 {
   "enumerant" : "1D",
   "value" : 0,
-  "capabilities" : [ "Sampled1D" ]
+  "capabilities" : [ "Sampled1D", "Image1D" ]
 },
 {
   "enumerant" : "2D",
-  "value" : 1
+  "value" : 1,
+  "capabilities" : [ "Shader", "Kernel", "ImageMSArray" ]
 },
 {
   "enumerant" : "3D",
@@ -4672,17 +4740,17 @@
 {
   "enumerant" : "Cube",
   "value" : 3,
-  "capabilities" : [ "Shader" ]
+  "capabilities" : [ "Shader", "ImageCubeArray" ]
 },
 {
   "enumerant" : "Rect",
   "value" : 4,
-  "capabilities" : [ "SampledRect" ]
+  "capabilities" : [ "SampledRect", "ImageRect" ]
 },
 {
   "enumerant" : "Buffer",
   "value" : 5,
-  "capabilities" : [ "SampledBuffer" ]
+  "capabilities" : [ "SampledBuffer", "ImageBuffer" ]
 },
 {
   "enumerant" : "SubpassData",
@@ -6018,6 +6086,11 @@
 {
   "enumerant" : "Invocation",
   "value" : 4
+},
+{
+  "enumerant" : "QueueFamilyKHR",
+  "value" : 5,
+  "capabilities" : [ "VulkanMemoryModelKHR" ]
 }
   ]
 },
@@ -6746,6 +6819,18 @@
   "value" : 5297,
   "extensions" : [ "SPV_NV_shader_subgroup_partitioned" ],
   "version" : "None"
+},
+{
+  "enumerant" : "VulkanMemoryModelKHR",
+  "value" : 5345,
+  "extensions" : [ "SPV_KHR_vulkan_memory_model" ],
+  "version" : "None"
+},
+{
+  "enumerant" : "VulkanMemoryModelDeviceScopeKHR",
+  "value" : 5346,
+  "extensions" : [ "SPV_KHR_vulkan_memory_model" ],
+  "version" : "None"
 }
   ]
 },
diff --git a/src/compiler/spirv/spirv.h b/src/compiler/spirv/spirv.h
index 4c90c936ce0..314c5f97cff 100644
--- a/src/compiler/spirv/spirv.h

[Mesa-dev] [Bug 107890] [bisected] Android build test fails "use of undeclared identifier 'cpu_set_t'/'cpuset'"

[bugzilla-daemon]

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

Bug ID: 107890
   Summary: [bisected] Android build test fails "use of undeclared
identifier 'cpu_set_t'/'cpuset'"
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mar...@gmail.com
  Reporter: clayton.a.cr...@intel.com
QA Contact: mesa-dev@lists.freedesktop.org
CC: lem...@gmail.com

This has been bisected to the following commit:

commit 8d473f555a0c3c94cffd18e68a13274488dcfb17
Author: Marek Olšák 
Date:   Wed Sep 5 23:10:57 2018 -0400

st/mesa: pin driver threads to a specific L3 cache on AMD Zen (v2)

v2: use set_context_param

Reviewed-by: Brian Paul 



Output of error from build:

FAILED:
out/target/product/androidia_64/obj_x86/STATIC_LIBRARIES/libmesa_dricore_intermediates/main/context.o
 
/bin/bash -c "PWD=/proc/self/cwd 
prebuilts/clang/host/linux-x86/clang-3859424/bin/clang-I
vendor/intel/external/android_ia/mesa/src/mapi -I
vendor/intel/external/android_ia/mesa/src/mesa/main -I
vendor/intel/external/android_ia/mesa/src/compiler/nir -I
vendor/intel/external/android_ia/mesa/src/gallium/include -I
vendor/intel/external/android_ia/mesa/src/gallium/auxiliary -I
out/target/product/androidia_64/gen/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/
-I
out/target/product/androidia_64/gen/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/
-I
out/target/product/androidia_64/gen/STATIC_LIBRARIES/libmesa_glsl_intermediates/glsl/
-I
out/target/product/androidia_64/gen/STATIC_LIBRARIES/libmesa_dricore_intermediates/main
-I vendor/intel/external/android_ia/mesa/src -I
vendor/intel/external/android_ia/mesa/include -I
vendor/intel/external/android_ia/mesa/src/mesa -I
out/target/product/androidia_64/obj_x86/STATIC_LIBRARIES/libmesa_dricore_intermediates
-I
out/target/product/androidia_64/gen/STATIC_LIBRARIES/libmesa_dricore_intermediates
-I libnativehelper/include/nativehelper \$(cat
out/target/product/androidia_64/obj_x86/STATIC_LIBRARIES/libmesa_dricore_intermediates/import_includes)
 -I system/core/include -I system/media/audio/include -I
hardware/libhardware/include -I hardware/libhardware_legacy/include -I
hardware/ril/include -I libnativehelper/include -I frameworks/native/include -I
frameworks/native/opengl/include -isystem frameworks/av/include -isystem
out/target/product/androidia_64/obj/include -isystem
bionic/libc/arch-x86/include -isystem bionic/libc/include -isystem
bionic/libc/kernel/uapi -isystem bionic/libc/kernel/uapi/asm-x86 -isystem
bionic/libc/kernel/android/uapi -c  -fno-exceptions -Wno-multichar -O2
-Wa,--noexecstack -Werror=format-security -D_FORTIFY_SOURCE=2
-Wstrict-aliasing=2 -ffunction-sections -fno-short-enums -fstrict-aliasing
-funwind-tables -fstack-protector-strong -no-canonical-prefixes -O2 -g
-fno-strict-aliasing -msse3 -mstackrealign -DANDROID -fmessage-length=0 -W
-Wall -Wno-unused -Winit-self -Wpointer-arith -DNDEBUG -UDEBUG
-fdebug-prefix-map=/proc/self/cwd= -D__compiler_offsetof=__builtin_offsetof
-Werror=int-conversion -Wno-reserved-id-macro -Wno-format-pedantic
-Wno-unused-command-line-argument -fcolor-diagnostics -Wno-expansion-to-defined
-fdebug-prefix-map=\$PWD/= -Werror=return-type -Werror=non-virtual-dtor
-Werror=address -Werror=sequence-point -Werror=date-time -nostdlibinc -m32
-march=prescott -target i686-linux-android
-Bprebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/x86_64-linux-android/bin
  -std=gnu99-msse4.1 -mstackrealign -DUSE_SSE41 -Wno-error
-Wno-unused-parameter -Wno-pointer-arith -Wno-missing-field-initializers
-Wno-initializer-overrides -Wno-mismatched-tags -DVERSION=\\\"18.3.0-devel\\\"
-DPACKAGE_VERSION=\\\"18.3.0-devel\\\"
-DPACKAGE_BUGREPORT=\\\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\\\;
-DANDROID_API_LEVEL=26 -DENABLE_SHADER_CACHE -D__STDC_CONSTANT_MACROS
-D__STDC_LIMIT_MACROS -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS
-DHAVE___BUILTIN_FFSLL -DHAVE_DLFCN_H -DHAVE_FUNC_ATTRIBUTE_FLATTEN
-DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE___BUILTIN_CTZ
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE_PTHREAD=1
-DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_LINUX_FUTEX_H -DHAVE_ENDIAN_H
-DHAVE_ZLIB -DMAJOR_IN_SYSMACROS -DVK_USE_PLATFORM_ANDROID_KHR
-fvisibility=hidden -fno-math-errno -fno-trapping-math -Wno-sign-compare
-DHAVE_LIBDRM -fPIC -DDEFAULT_DRIVER_DIR=\\\"/vendor/lib/dri\\\"
-D_USING_LIBCXX -DANDROID_STRICT -std=c99  -Werror=int-to-pointer-cast
-Werror=pointer-to-int-cast -Werror=address-of-temporary -Werror=return-type
-MD -MF

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

[Bas Nieuwenhuizen]

Acked-by: Bas Nieuwenhuizen 
On Mon, Sep 10, 2018 at 7:09 PM Jason Ekstrand  wrote:
>
> ---
>  include/vulkan/vulkan_core.h | 139 +++--
>  src/vulkan/registry/vk.xml   | 280 +++
>  2 files changed, 345 insertions(+), 74 deletions(-)
>
> diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
> index 06c860707b8..fe450142503 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 80
> +#define VK_HEADER_VERSION 84
>
>
>  #define VK_NULL_HANDLE 0
> @@ -305,6 +305,8 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV = 158000,
>  VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT = 161000,
>  VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN = 162000,
> +VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT = 167000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT = 167001,
>  VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173000,
>  VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173001,
>  VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR = 173002,
> @@ -380,6 +382,10 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID = 1000129005,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT = 
> 100013,
>  VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT = 1000130001,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT = 
> 1000138000,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT = 
> 1000138001,
> +VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT = 
> 1000138002,
> +VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT = 
> 1000138003,
>  VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT = 1000143000,
>  VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT = 
> 1000143001,
>  VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT = 
> 1000143002,
> @@ -406,6 +412,11 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD = 
> 1000185000,
>  
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT = 
> 100019,
>  VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT = 
> 1000190001,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT 
> = 1000190002,
> +VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV = 1000206000,
> +VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV = 1000206001,
> +VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 
> 1000211000,
> +VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = 
> VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
>  VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = 
> VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR = 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES,
> @@ -440,6 +451,7 @@ typedef enum VkStructureType {
>  VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR = 
> VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR = 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES,
>  VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR = 
> VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO,
> +VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT = 
> VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT,
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR = 
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO,
>  VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR = 
> VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES,
>  VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR = 
> VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO,
> @@ -1118,6 +1130,7 @@ typedef enum VkDescriptorType {
>  VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC = 8,
>  VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC = 9,
>  VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT = 10,
> +VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT = 1000138000,
>  VK_DESCRIPTOR_TYPE_BEGIN_RANGE = VK_DESCRIPTOR_TYPE_SAMPLER,
>  VK_DESCRIPTOR_TYPE_END_RANGE = VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
>  VK_DESCRIPTOR_TYPE_RANGE_SIZE = (VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT - 
> VK_DESCRIPTOR_TYPE_SAMPLER + 1),
> @@ -4573,7 +4586,6 @@ VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSurfaceKHR)
>
>  #define VK_KHR_SURFACE_SPEC_VERSION   25
>  #define 

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

[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 951505a854e..ea090dc3e5c 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 = 80
+API_PATCH_VERSION = 84
 
 # 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.17.1

___
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.84

[Jason Ekstrand]

---
 include/vulkan/vulkan_core.h | 139 +++--
 src/vulkan/registry/vk.xml   | 280 +++
 2 files changed, 345 insertions(+), 74 deletions(-)

diff --git a/include/vulkan/vulkan_core.h b/include/vulkan/vulkan_core.h
index 06c860707b8..fe450142503 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 80
+#define VK_HEADER_VERSION 84
 
 
 #define VK_NULL_HANDLE 0
@@ -305,6 +305,8 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_WIN32_KEYED_MUTEX_ACQUIRE_RELEASE_INFO_NV = 158000,
 VK_STRUCTURE_TYPE_VALIDATION_FLAGS_EXT = 161000,
 VK_STRUCTURE_TYPE_VI_SURFACE_CREATE_INFO_NN = 162000,
+VK_STRUCTURE_TYPE_IMAGE_VIEW_ASTC_DECODE_MODE_EXT = 167000,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ASTC_DECODE_FEATURES_EXT = 167001,
 VK_STRUCTURE_TYPE_IMPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173000,
 VK_STRUCTURE_TYPE_EXPORT_MEMORY_WIN32_HANDLE_INFO_KHR = 173001,
 VK_STRUCTURE_TYPE_MEMORY_WIN32_HANDLE_PROPERTIES_KHR = 173002,
@@ -380,6 +382,10 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROID = 1000129005,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SAMPLER_FILTER_MINMAX_PROPERTIES_EXT = 
100013,
 VK_STRUCTURE_TYPE_SAMPLER_REDUCTION_MODE_CREATE_INFO_EXT = 1000130001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_FEATURES_EXT = 
1000138000,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_INLINE_UNIFORM_BLOCK_PROPERTIES_EXT = 
1000138001,
+VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT = 
1000138002,
+VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_INLINE_UNIFORM_BLOCK_CREATE_INFO_EXT = 
1000138003,
 VK_STRUCTURE_TYPE_SAMPLE_LOCATIONS_INFO_EXT = 1000143000,
 VK_STRUCTURE_TYPE_RENDER_PASS_SAMPLE_LOCATIONS_BEGIN_INFO_EXT = 1000143001,
 VK_STRUCTURE_TYPE_PIPELINE_SAMPLE_LOCATIONS_STATE_CREATE_INFO_EXT = 
1000143002,
@@ -406,6 +412,11 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_CORE_PROPERTIES_AMD = 1000185000,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT 
= 100019,
 VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_DIVISOR_STATE_CREATE_INFO_EXT = 
1000190001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT = 
1000190002,
+VK_STRUCTURE_TYPE_CHECKPOINT_DATA_NV = 1000206000,
+VK_STRUCTURE_TYPE_QUEUE_FAMILY_CHECKPOINT_PROPERTIES_NV = 1000206001,
+VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VULKAN_MEMORY_MODEL_FEATURES_KHR = 
1000211000,
+VK_STRUCTURE_TYPE_DEBUG_REPORT_CREATE_INFO_EXT = 
VK_STRUCTURE_TYPE_DEBUG_REPORT_CALLBACK_CREATE_INFO_EXT,
 VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_RENDER_PASS_MULTIVIEW_CREATE_INFO,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_FEATURES,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_MULTIVIEW_PROPERTIES,
@@ -440,6 +451,7 @@ typedef enum VkStructureType {
 VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_EXPORT_SEMAPHORE_CREATE_INFO,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_16BIT_STORAGE_FEATURES,
 VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_DESCRIPTOR_UPDATE_TEMPLATE_CREATE_INFO,
+VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES2_EXT = 
VK_STRUCTURE_TYPE_SURFACE_CAPABILITIES_2_EXT,
 VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO_KHR = 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_EXTERNAL_FENCE_INFO,
 VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES_KHR = 
VK_STRUCTURE_TYPE_EXTERNAL_FENCE_PROPERTIES,
 VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO_KHR = 
VK_STRUCTURE_TYPE_EXPORT_FENCE_CREATE_INFO,
@@ -1118,6 +1130,7 @@ typedef enum VkDescriptorType {
 VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER_DYNAMIC = 8,
 VK_DESCRIPTOR_TYPE_STORAGE_BUFFER_DYNAMIC = 9,
 VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT = 10,
+VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT = 1000138000,
 VK_DESCRIPTOR_TYPE_BEGIN_RANGE = VK_DESCRIPTOR_TYPE_SAMPLER,
 VK_DESCRIPTOR_TYPE_END_RANGE = VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT,
 VK_DESCRIPTOR_TYPE_RANGE_SIZE = (VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT - 
VK_DESCRIPTOR_TYPE_SAMPLER + 1),
@@ -4573,7 +4586,6 @@ VK_DEFINE_NON_DISPATCHABLE_HANDLE(VkSurfaceKHR)
 
 #define VK_KHR_SURFACE_SPEC_VERSION   25
 #define VK_KHR_SURFACE_EXTENSION_NAME "VK_KHR_surface"
-#define VK_COLORSPACE_SRGB_NONLINEAR_KHR  VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
 
 
 typedef enum VkColorSpaceKHR {
@@ -4592,6 +4604,7 @@ typedef enum VkColorSpaceKHR {
 VK_COLOR_SPACE_ADOBERGB_NONLINEAR_EXT = 1000104012,
 

[Mesa-dev] [PATCH 2/2] anv: Support v3 of VK_EXT_vertex_attribute_divisor

[Jason Ekstrand]

Cc: Bas Nieuwenhuizen 
---
 src/intel/vulkan/anv_device.c  | 8 
 src/intel/vulkan/anv_extensions.py | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 7ab8543300b..44855dae128 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -934,6 +934,14 @@ void anv_GetPhysicalDeviceFeatures2(
  break;
   }
 
+  case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_EXT: {
+ VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features =
+(VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *)ext;
+ features->vertexAttributeInstanceRateDivisor = VK_TRUE;
+ features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
+ break;
+  }
+
   default:
  anv_debug_ignored_stype(ext->sType);
  break;
diff --git a/src/intel/vulkan/anv_extensions.py 
b/src/intel/vulkan/anv_extensions.py
index a21aee5a001..951505a854e 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -122,7 +122,7 @@ EXTENSIONS = [
   'device->has_context_priority'),
 Extension('VK_EXT_shader_viewport_index_layer',   1, True),
 Extension('VK_EXT_shader_stencil_export', 1, 'device->info.gen 
>= 9'),
-Extension('VK_EXT_vertex_attribute_divisor',  2, True),
+Extension('VK_EXT_vertex_attribute_divisor',  3, True),
 Extension('VK_EXT_post_depth_coverage',   1, 'device->info.gen 
>= 9'),
 Extension('VK_EXT_sampler_filter_minmax', 1, 'device->info.gen 
>= 9'),
 ]
-- 
2.17.1

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

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 07:00 PM, Timothy Arceri wrote:
> On 10/09/18 11:01, Matt Turner wrote:
>> I think it's evident that we can find a way forward based on past
>> experiences (compatibility profile is supported in Mesa!).
> 
> I don't really know what you are trying to say here. I continued what
> Marek's started while implemented a bunch of compat tests, just like
> every other feature we add. You guys just decided not to follow I'm I
> missing something?

I think he's just pointing out that I was at least as aggressive in my
disapproval of compatibility profile, yet it has landed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Get Wolfenstein: The Old Blood running (Part 2)

[Ian Romanick]

On 09/09/2018 06:00 PM, Timothy Arceri wrote:
> On 10/09/18 10:40, Ian Romanick wrote:
>> On 09/09/2018 05:00 PM, Timothy Arceri wrote:
>>> Ian made it pretty clear he didn't want a debate and had already made up
>>> his mind.
>>>
>>> "We decided years ago that we were not going to support this horrible,
>>> underspecified steaming pile of an extension in Mesa.  I am not
>>> interested in going back on that decision now or, frankly, ever."
>>>
>>> All I'm saying is I'm willing to write tests but I get the feeling
>>> nothing will be good enough when I'm greeted with statements like the
>>> one above.
>>
>> That's fair.  I have pretty well made up my mind about EXT_dsa.  I also
>> had my mind pretty well made up about compatibility profile and
>> EXT_gpu_shader4.  While I may have my own entrenched opinion, I'm not
>> the only decision maker.
>>
>> That said, quality of implementation and quality of testing cannot be
>> debatable points.
>>
>> When we started seriously working on getting modern OpenGL support for
>> Mesa back in 2009-2010, we made a key decision really early on.  When I
>> say "we" here, I mean the team of open-source junkies who happened to
>> work at Intel.  The only way we were going to be better than certain
>> closed-source drivers was to be slow and methodical.  In the intervening
>> 8 years, we implemented dozens of extensions that eventually helped get
>> Mesa to OpenGL 4.5.  We also helped make Mesa one of the first
>> implementations of OpenGL ES 3.0.  I think we even beat Qualcomm.  All
>> the while we wrote literally tens of thousands of piglit tests and
>> submitted dozens of spec bugs.
>>
>> It's tempting to say, "You have such a big team, you can afford that
>> luxury."  We made the decision to take this path when the OpenGL team at
>> Intel was 3 people: Eric, Ken, and myself.  I don't think I need to
>> quote any software engineering books about the cost of finding defects
>> early, but it's all true.  The only way we could keep from drowning in
>> bug reports was to get things right the first time.
>>
>> It wasn't just the team at Intel who went this way.  We "compelled"
>> various contractors that we worked with to do the same, and I thought
>> the drive for quality rubbed off on other people in the community.  I
>> think the commit statistics in piglit and Mesa support that, too.
>> Although, part of me does miss the days when a full piglit run took less
>> than 10 minutes on a slow machine.
>>
>> Along the way, we caught a lot of flak inside the company for things
>> taking so long and for being so far behind the rest of the industry.
>> The payoff came when I would go to GDC or SIGGRAPH, and game developers
>> would thank me because things just worked, the first time, on Mesa.  We
>> caught up with the rest of the industry as quickly as we did because we
>> went as slowly as we did.
>>
>> It's also tempting to say, "If a feature isn't implemented with high
>> enough quality, you don't have to enable it."  That is technically true,
>> but it's also disingenuous.  The only reason these particular features
>> are being implemented at all is market forces.  If any driver in the
>> code base supports a particular feature, the ability for other drivers
>> to resist market forces diminishes to near zero.  Allowing an
>> inadequately tested feature into core Mesa just pushes the
>> responsibility for writing tests on to the next person that wants to (or
>> is compelled to) support the feature.  I hope we can agree that's not
>> okay.
> 
> I agree testing is key to Mesa's success. I've even taken that to the
> point where I once went over the entire patchworks outstanding piglit
> tests. Fixing and committing dozens of forgotten about tests, including
> a number from yourself where the extension had been pushed to Mesa and
> the tests had never been pushed to piglit. To be fair you were not the
> only one to do this but it was quite alarming to discover this had been
> happening at the time.

Mistakes happen. :(  The piglit list is often ignored.  Tests that go
unreviewed are often forgotten by the test authors.  It sucks. :(

> The term quality is somewhat arbitrary. My comment that you could
> disable the extension if the testing was not up to your standards wasn't
> meant to imply I intended to write poor quality test more that I
> believed you were using quality as an easy out given you had already
> made up your mind on the extension in you previous reply.

The problem usually is not that the tests are not good enough.  The
problem usually is that there are not enough tests.  Recent problems
with ARB_fragment_shader_interlock highlight this.  If I remember
correctly, EXT_dsa adds over 100 new entry points, and it has
interactions with over a dozen other EXT, NV, and ARB extensions.  I
can't think of any extension, other than perhaps ARB_dsa, that had such
a massive surface area.  ARB_dsa took months to develop tests for, and I
feel like it only got the bare minimum 

Re: [Mesa-dev] [PATCH] radv: adjust ESGS ring buffer size computation on VI+

[Samuel Pitoiset]

On 9/10/18 6:12 PM, Ilia Mirkin wrote:

On Mon, Sep 10, 2018 at 12:03 PM, Samuel Pitoiset
 wrote:

Noticed while working in this area. Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_pipeline.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 1741d5e9047..e362c380453 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1575,7 +1575,11 @@ calculate_gs_ring_sizes(struct radv_pipeline *pipeline, 
const struct radv_gs_sta
 unsigned num_se = device->physical_device->rad_info.max_se;
 unsigned wave_size = 64;
 unsigned max_gs_waves = 32 * num_se; /* max 32 per SE on GCN */
-   unsigned gs_vertex_reuse = 16 * num_se; /* GS_VERTEX_REUSE register 
(per SE) */
+   /* On SI-CI, the value comes from VGT_GS_VERTEX_REUSE = 16.
+* On VI+, the value comes from VGT_VERTEX_REUSE_BLOCK_CNTL = 30 (+2).
+*/
+   unsigned gs_vertex_reuse =
+   device->physical_device->rad_info.chip_class >= VI ? 32 : 16;


I have no idea what any of these things are, but just would like to
observe that previously it was scaled by num_se, while now it is no
longer.


'* num_se' decided to disappear, thanks for catching this :)



   -ilia


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

[Mesa-dev] [PATCH v2] radv: adjust ESGS ring buffer size computation on VI+

[Samuel Pitoiset]

Noticed while working in this area. Ported from RadeonSI.

v2: fix missing * num_se

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 1741d5e9047..ae269c32c49 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1575,7 +1575,11 @@ calculate_gs_ring_sizes(struct radv_pipeline *pipeline, 
const struct radv_gs_sta
unsigned num_se = device->physical_device->rad_info.max_se;
unsigned wave_size = 64;
unsigned max_gs_waves = 32 * num_se; /* max 32 per SE on GCN */
-   unsigned gs_vertex_reuse = 16 * num_se; /* GS_VERTEX_REUSE register 
(per SE) */
+   /* On SI-CI, the value comes from VGT_GS_VERTEX_REUSE = 16.
+* On VI+, the value comes from VGT_VERTEX_REUSE_BLOCK_CNTL = 30 (+2).
+*/
+   unsigned gs_vertex_reuse =
+   (device->physical_device->rad_info.chip_class >= VI ? 32 : 16) 
* num_se;
unsigned alignment = 256 * num_se;
/* The maximum size is 63.999 MB per SE. */
unsigned max_size = ((unsigned)(63.999 * 1024 * 1024) & ~255) * num_se;
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH] radv: adjust ESGS ring buffer size computation on VI+

[Ilia Mirkin]

On Mon, Sep 10, 2018 at 12:03 PM, Samuel Pitoiset
 wrote:
> Noticed while working in this area. Ported from RadeonSI.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 1741d5e9047..e362c380453 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -1575,7 +1575,11 @@ calculate_gs_ring_sizes(struct radv_pipeline 
> *pipeline, const struct radv_gs_sta
> unsigned num_se = device->physical_device->rad_info.max_se;
> unsigned wave_size = 64;
> unsigned max_gs_waves = 32 * num_se; /* max 32 per SE on GCN */
> -   unsigned gs_vertex_reuse = 16 * num_se; /* GS_VERTEX_REUSE register 
> (per SE) */
> +   /* On SI-CI, the value comes from VGT_GS_VERTEX_REUSE = 16.
> +* On VI+, the value comes from VGT_VERTEX_REUSE_BLOCK_CNTL = 30 (+2).
> +*/
> +   unsigned gs_vertex_reuse =
> +   device->physical_device->rad_info.chip_class >= VI ? 32 : 16;

I have no idea what any of these things are, but just would like to
observe that previously it was scaled by num_se, while now it is no
longer.

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

Re: [Mesa-dev] [PATCH] utils/u_math: break dependency on gallium/utils

[Dylan Baker]

I agree that using code from mesa in util is gross, I'm not planning to leave it
like this. I'm in the middle of cleaning up duplication between util and mesa,
and I'll plan on pulling u_cpu_detection down into src/util in that series.

In this case while gross there shouldn't be any compilation issues,
common_x86_features.h is a pure header implementation with no #include's if any
kind, so while a bit ugly this should be safe.

Dylan

Quoting Marek Olšák (2018-09-09 00:28:25)
> I think this will break non-GL gallium state trackers. src/mesa is
> only for GL, which is why common gallium code and gallium drivers
> can't use code from src/mesa.
> 
> Marek
> 
> On Sun, Sep 9, 2018 at 2:39 AM, Dylan Baker  wrote:
> > Currently u_math needs gallium utils for cpu detection.  Most of what
> > u_math uses out of u_cpu_detection is duplicated in src/mesa/x86
> > (surprise!), so I've just reworked it as much as possible to use the
> > x86/common_x86_features macros instead of the gallium ones. There is
> > one small function that was copied over, as promoting u_cpu_detection is
> > itself a fairly hefty undertaking, as it depends on u_debug, and this
> > fixes the bug for now.
> >
> > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107870
> > cc: v...@freedesktop.org
> > ---
> >
> > I have no idea if this fixes the build on mac, I had this in a branch where 
> > I
> > started replacing more of imports.{h,c} with utils stuff, and this fixes 
> > some
> > build problems on Linux. I don't have a mac to test on and I wont until 
> > Monday.
> > If this works let me know.
> >
> >  src/util/u_math.c | 43 ++-
> >  1 file changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/util/u_math.c b/src/util/u_math.c
> > index c58af911be7..bf0c398eeec 100644
> > --- a/src/util/u_math.c
> > +++ b/src/util/u_math.c
> > @@ -29,7 +29,7 @@
> >
> >  #include "pipe/p_config.h"
> >  #include "util/u_math.h"
> > -#include "util/u_cpu_detect.h"
> > +#include "x86/common_x86_features.h"
> >
> >  #if defined(PIPE_ARCH_SSE)
> >  #include 
> > @@ -90,7 +90,7 @@ util_fpstate_get(void)
> > unsigned mxcsr = 0;
> >
> >  #if defined(PIPE_ARCH_SSE)
> > -   if (util_cpu_caps.has_sse) {
> > +   if (cpu_has_xmm) {
> >mxcsr = _mm_getcsr();
> > }
> >  #endif
> > @@ -98,6 +98,31 @@ util_fpstate_get(void)
> > return mxcsr;
> >  }
> >
> > +/* TODO: this was copied from u_cpu_detection. It's another case of 
> > duplication
> > + * between gallium and core mesa, and it would be nice to get rid of that
> > + * duplication as well.
> > + */
> > +#if defined(PIPE_ARCH_X86)
> > +PIPE_ALIGN_STACK static inline bool sse2_has_daz(void)
> > +{
> > +   struct {
> > +  uint32_t pad1[7];
> > +  uint32_t mxcsr_mask;
> > +  uint32_t pad2[128-8];
> > +   } PIPE_ALIGN_VAR(16) fxarea;
> > +
> > +   fxarea.mxcsr_mask = 0;
> > +#if defined(PIPE_CC_GCC)
> > +   __asm __volatile ("fxsave %0" : "+m" (fxarea));
> > +#elif defined(PIPE_CC_MSVC) || defined(PIPE_CC_ICL)
> > +   _fxsave();
> > +#else
> > +   fxarea.mxcsr_mask = 0;
> > +#endif
> > +   return !!(fxarea.mxcsr_mask & (1 << 6));
> > +}
> > +#endif
> > +
> >  /**
> >   * Make sure that the fp treats the denormalized floating
> >   * point numbers as zero.
> > @@ -108,13 +133,21 @@ unsigned
> >  util_fpstate_set_denorms_to_zero(unsigned current_mxcsr)
> >  {
> >  #if defined(PIPE_ARCH_SSE)
> > -   if (util_cpu_caps.has_sse) {
> > +   if (cpu_has_xmm) {
> >/* Enable flush to zero mode */
> >current_mxcsr |= _MM_FLUSH_ZERO_MASK;
> > -  if (util_cpu_caps.has_daz) {
> > +  /* x86_64 cpus always have daz, as do cpus with sse3 in fact, there's
> > +   * basically only a handful of very early pentium 4's that have sse2 
> > but
> > +   * not daz.
> > +   */
> > +# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
> > +  if (sse2_has_daz()) {
> > +# endif
> >   /* Enable denormals are zero mode */
> >   current_mxcsr |= _MM_DENORMALS_ZERO_MASK;
> > +# if !defined(PIPE_ARCH_x86_64) && !defined(PIPE_ARCH_SSSE3)
> >}
> > +#endif
> >util_fpstate_set(current_mxcsr);
> > }
> >  #endif
> > @@ -130,7 +163,7 @@ void
> >  util_fpstate_set(unsigned mxcsr)
> >  {
> >  #if defined(PIPE_ARCH_SSE)
> > -   if (util_cpu_caps.has_sse) {
> > +   if (cpu_has_xmm) {
> >_mm_setcsr(mxcsr);
> > }
> >  #endif
> > --
> > 2.18.0
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/3] android: broadcom/genxml: fix collision with intel/genxml header-gen macro

[Dylan Baker]

Quoting Mauro Rossi (2018-09-09 01:56:20)
> Hi,
> 
> Il giorno gio 6 set 2018 alle ore 18:20 Dylan Baker
>  ha scritto:
> >
> > Quoting Rob Herring (2018-09-06 07:16:07)
> > > On Mon, Sep 3, 2018 at 4:27 PM Eric Anholt  wrote:
> > > >
> > > > Mauro Rossi  writes:
> > > >
> > > > > Fixes the following building error, happening when building both 
> > > > > intel and broadcom:
> > > >
> > > > I wish someone maintaining android Mesa would work on making the meson
> > > > build work for them instead of just continuing to maintain the
> > > > Android.mk mess.
> > >
> > > Trust me, no one likes this thankless job.
> > >
> > > How do you envision that would work without meson support in the
> > > Android build system? I went down the path of defining a "prebuilt"
> > > Android.mk target which calls meson to do a build. This was a dead end
> > > because the Android.mk gets none of the build environment. It's
> > > possible to dump all that out and re-construct those settings. That
> > > seems horribly fragile, and I'd guess we'd just be switching from mesa
> > > to AOSP breaking the build. Of course the latter already happens too.
> > > Finally, I'm pretty sure this would not be accepted for the AOSP copy
> > > of mesa (which is trying to track mainline).
> > >
> > > The other route would be some sort automatic meson to Android BP build
> > > file translation. Such a thing exists for autotools, but I've never
> > > seen it in actual use anywhere.
> > >
> > > Either way, this seems like a unicorn to me until AOSP provides some
> > > support to support meson. If you really want to force the issue, strip
> > > all the Android.mk files out of mesa. Though that will mainly put the
> > > pain on downstream device trees, not AOSP.
> > >
> > > Rob
> >
> > With my meson hat on,
> >
> > I've been looking at blueprint recently, trying to decide if we could 
> > implement
> > a meson-for-android on top of blueprint. While I know a lot about meson 
> > (I've
> > written a bunch of the meson implementation), I don't know a lot about 
> > blueprint
> > and their documentation is basically aimed at explaining how soong works. I
> > certainly can't commit to full time development on a meson-on-blueprint
> > implementation, but I certainly could help write one if there was someone
> > interested in working on it as well. It would also be helpful if there was
> > someone in the blueprint camp who could tell me whether such a thing is even
> > feasible or not.
> >
> > Dylan
> 
> I can comment that when talking about the patching process in Mesa,
> it is very much clear when Android.mk changes are needed
> and there are many people currently supporting Android.mk and in the
> last three years
> there was much attention to keep Android.mk in good shape.
> That's why it is in good shape.
> 
> In my understanding kati for building with Android.mk will be dropped
> at some point,
> Android.bp will be the only building script language supported by AOSP.
> 
> Android.bp will be easier to mantain than Android.mk, because Android.bp
> is intentionally very similar to Bazel build script language,
> which should have corresponding objects and grammar/syntax rules than
> can be translated or visually inspected, if people will continue to
> care.
> 
> IMHO .go language scripts should not be used when unnecessary, for
> architecture conditionals and genrules that may be supported in
> Android.bp
> but environement variables, if I understood correctly, will require
> .go script because of how Blueprint is inspired to Bazel but not
> identical.
> I'm still wondering if a .go-less Android.bp may be feasible
> 
> So options are:
> 
> 1. Use the androidmk parser / blueprint_tools to perform the draft
> translation, then huge work to fix the Android.bp build through all
> the tree.
> 2. meson to Android.bp parser/translator - this would be interesting,
> if we could find a way to generate the .go which is not tackled with
> in 1.,or surrogate rules in bp
> 3. Go to Google  ninja-build forums if they have plans to perform
> feasibility analysis and develop soong to accept meson directly (In
> the long term it is a Win for them)
> 4. Go to Google Build forum and propose a meson-to-bp added to
> blueprint_tools (and have part of this task driven by them  - A
> clearly mesa is not the only project using meson)
> 5. Propose Google to setup one/two projects for next GSoC in area 3. and 4.
> 6. Wait for Google be at the milestone of kati/Android.mk demise and
> see how they will build mesa.
> 
> I am interested in contributing in part of my spare time.
> 
> Mauro

I think those are basically the options we have, along with my suggestion to
write a go module that can parse meson at build time, which blueprint supports.
For us it would be a huge win if Google would support meson in some form, since
that would allow us to get down to just one build system for the graphics (minus
kernel which Google has to figure out anyway) ecosystem. That's a huge win for
mesa, 

[Mesa-dev] [PATCH] radv: adjust ESGS ring buffer size computation on VI+

[Samuel Pitoiset]

Noticed while working in this area. Ported from RadeonSI.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_pipeline.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
index 1741d5e9047..e362c380453 100644
--- a/src/amd/vulkan/radv_pipeline.c
+++ b/src/amd/vulkan/radv_pipeline.c
@@ -1575,7 +1575,11 @@ calculate_gs_ring_sizes(struct radv_pipeline *pipeline, 
const struct radv_gs_sta
unsigned num_se = device->physical_device->rad_info.max_se;
unsigned wave_size = 64;
unsigned max_gs_waves = 32 * num_se; /* max 32 per SE on GCN */
-   unsigned gs_vertex_reuse = 16 * num_se; /* GS_VERTEX_REUSE register 
(per SE) */
+   /* On SI-CI, the value comes from VGT_GS_VERTEX_REUSE = 16.
+* On VI+, the value comes from VGT_VERTEX_REUSE_BLOCK_CNTL = 30 (+2).
+*/
+   unsigned gs_vertex_reuse =
+   device->physical_device->rad_info.chip_class >= VI ? 32 : 16;
unsigned alignment = 256 * num_se;
/* The maximum size is 63.999 MB per SE. */
unsigned max_size = ((unsigned)(63.999 * 1024 * 1024) & ~255) * num_se;
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH v3] mesa/meson: 32bit xmlconfig linkage

[Dylan Baker]

Quoting Sergii Romantsov (2018-09-09 23:52:04)
> Hello,
> just reminder for case: don't have push-rights...
> 
> On Fri, Sep 7, 2018 at 8:05 PM, Dylan Baker  wrote:
> 
> Quoting Sergii Romantsov (2018-09-07 02:43:41)
> > Building of 32bit mesa with meson causes linkage issue:
> > "undefined reference to `util_get_process_name'"
> > Fixed by adding link-with mesa_util for xmlconfig primary.
> >
> > v2: Removed '[]', commit message corrected.
> >
> > v3: Reverted changes in gbm and glx libraries.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
> > Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from
> xmlconfig.c"
> > Cc: Marek Ol\u0161ák 
> > Cc: Dylan Baker 
> > Signed-off-by: Sergii Romantsov 
> > Reviewed-by: Eric Engestrom 
> > ---
> >  src/util/meson.build | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/src/util/meson.build b/src/util/meson.build
> > index a4ff0b9..e3d96b6 100644
> > --- a/src/util/meson.build
> > +++ b/src/util/meson.build
> > @@ -117,6 +117,7 @@ libxmlconfig = static_library(
> >    'xmlconfig',
> >    files_xmlconfig,
> >    include_directories : inc_common,
> > +  link_with : libmesa_util,
> >    dependencies : [dep_expat, dep_m],
> >    c_args : [
> >      c_msvc_compat_args, c_vis_args,
> > --
> > 2.7.4
> >
> 
> Reviewed-by: Dylan Baker 
> 

Sorry about that, I'm running a quick build test than I'll push.

Dylan


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

Re: [Mesa-dev] [PATCH 2/4] gallium/auxiliary: don't dereference counters twice needlessly

[Michel Dänzer]

On 2018-09-07 11:35 p.m., Marek Olšák wrote:
> From: Marek Olšák 
> 
> +1.2% performance with:
> piglit/drawoverhead - DrawElements (no state changes) on radeonsi

No meaningless number (which is most likely the same order of magnitude,
maybe even smaller than the deviation between test runs) in the commit
log please.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] gallium/u_inlines: improve pipe_reference_described perf for debug builds

[Michel Dänzer]

On 2018-09-07 11:35 p.m., Marek Olšák wrote:
> From: Marek Olšák 
> 
> Tested-by: Dieter Nützel 
> ---
>  src/gallium/auxiliary/util/u_inlines.h | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_inlines.h 
> b/src/gallium/auxiliary/util/u_inlines.h
> index 83013df53f1..820d3080a5c 100644
> --- a/src/gallium/auxiliary/util/u_inlines.h
> +++ b/src/gallium/auxiliary/util/u_inlines.h
> @@ -72,28 +72,29 @@ pipe_is_referenced(struct pipe_reference *src)
>  static inline boolean
>  pipe_reference_described(struct pipe_reference *dst,
>   struct pipe_reference *src,
>   debug_reference_descriptor get_desc)
>  {
> boolean destroy = FALSE;
>  
> if (dst != src) {
>/* bump the src.count first */
>if (src) {
> - assert(pipe_is_referenced(src));
> - p_atomic_inc(>count);
> + MAYBE_UNUSED int count = p_atomic_inc_return(>count);
> + assert(count != 1); /* src had to be referenced */
>   debug_reference(src, get_desc, 1);
>}
>  
>if (dst) {
> - assert(pipe_is_referenced(dst));
> - if (p_atomic_dec_zero(>count))
> + int count = p_atomic_dec_return(>count);
> + assert(count != -1); /* dst had to be referenced */
> + if (!count)
>  destroy = TRUE;
>  
>   debug_reference(dst, get_desc, -1);
>}
> }
>  
> return destroy;
>  }
>  
>  static inline boolean
> 

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] i965: Fix calculation of layers array length for isl_view

[Danylo Piliaiev]

Handle all cases in calculation of layers count for isl_view
taking into account texture view and image unit.
st_convert_image was taken as a reference.

When u->Layered is true the whole level is taken with respect to
image view. In other case only one layer is taken.

v3: (Józef Kucia and Ilia Mirkin)
- Rewrote patch by taking st_convert_image as a reference
- Removed now unused get_image_num_layers function
- Changed commit message

Fixes: 5a8c8903
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107856

Signed-off-by: Danylo Piliaiev 
---
 .../drivers/dri/i965/brw_wm_surface_state.c   | 32 ++-
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c 
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 944762ec46..9bfe6e2037 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -1499,18 +1499,6 @@ update_buffer_image_param(struct brw_context *brw,
param->stride[0] = _mesa_get_format_bytes(u->_ActualFormat);
 }
 
-static unsigned
-get_image_num_layers(const struct intel_mipmap_tree *mt, GLenum target,
- unsigned level)
-{
-   if (target == GL_TEXTURE_CUBE_MAP)
-  return 6;
-
-   return target == GL_TEXTURE_3D ?
-  minify(mt->surf.logical_level0_px.depth, level) :
-  mt->surf.logical_level0_px.array_len;
-}
-
 static void
 update_image_surface(struct brw_context *brw,
  struct gl_image_unit *u,
@@ -1541,14 +1529,28 @@ update_image_surface(struct brw_context *brw,
   } else {
  struct intel_texture_object *intel_obj = intel_texture_object(obj);
  struct intel_mipmap_tree *mt = intel_obj->mt;
- const unsigned num_layers = u->Layered ?
-get_image_num_layers(mt, obj->Target, u->Level) : 1;
+
+ unsigned base_layer, num_layers;
+ if (u->Layered) {
+if (obj->Target == GL_TEXTURE_3D) {
+   base_layer = 0;
+   num_layers = minify(mt->surf.logical_level0_px.depth, u->Level);
+} else {
+   base_layer = obj->MinLayer;
+   num_layers = obj->Immutable ?
+obj->NumLayers :
+mt->surf.logical_level0_px.array_len;
+}
+ } else {
+base_layer = obj->MinLayer + u->_Layer;
+num_layers = 1;
+ }
 
  struct isl_view view = {
 .format = format,
 .base_level = obj->MinLevel + u->Level,
 .levels = 1,
-.base_array_layer = obj->MinLayer + u->_Layer,
+.base_array_layer = base_layer,
 .array_len = num_layers,
 .swizzle = ISL_SWIZZLE_IDENTITY,
 .usage = ISL_SURF_USAGE_STORAGE_BIT,
-- 
2.18.0

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

Re: [Mesa-dev] [PATCH 0/8] Gallium & RadeonSI optimization for Ryzen CPUs

[Michel Dänzer]

On 2018-09-07 9:01 p.m., Marek Olšák wrote:
> On Fri, Sep 7, 2018 at 11:04 AM, Michel Dänzer  wrote:
>> On 2018-09-07 4:31 p.m., Marek Olšák wrote:
>>> On Fri, Sep 7, 2018, 4:34 AM Michel Dänzer  wrote:
 On 2018-09-06 10:56 p.m., Axel Davy wrote:

> I fear if we begin to do the work manually, there won't be interest to
> do that in the kernel,
> and thus all applications will need to include such core pinning code to
> have good performance when
> multithreaded.

 I'm also a bit worried that this solution could result in multiple
 processes contending for the same set of CPU cores, while other cores
 might be underused, which could result in worse overall system performance.
>>>
>>> Any suggestion how to choose the ccx such that processes end up on a
>>> different one?
>>
>> One thing you could do is use a random initial offset. That should at
>> least avoid e.g. most applications using the same toolkit (which may do
>> OpenGL calls, even if the application itself doesn't) choosing the same one.
> 
> I'll update the helper function to choose the initial CCX with
> (os_time_get_nano() % num_L3_caches). That should be random.

Why not use an RNG API for getting a random number?


>> In the worst case, all processes using OpenGL (or at least their OpenGL
>> related threads, but that usually includes the main thread) could end up
>> restricted to the same 4 cores, leaving up to 28 cores underused.
> 
> 4C/4T used to be a standard and certainly enough for gaming. 4C/8T
> used to be luxury before Ryzen, which is now the CCX. We should be
> fine with 4 cores.

Sounds like "640K of memory ought to be enough for anybody"...


Anyway, per reports on IRC, the core pinning can hurt even individual
applications, e.g. blender. I like your idea of a driconf option, but it
should be disabled by default, and only enabled for apps where it's
known safe and beneficial in practice.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[andrey simiklit]

Hello,

Thanks for your reply.
Please find my comments below:

On Mon, Sep 10, 2018 at 2:45 PM Chris Wilson 
wrote:

> Quoting andrey simiklit (2018-08-21 13:00:57)
> > Hi all,
> >
> > The bug for this issue was created:
> > https://bugs.freedesktop.org/show_bug.cgi?id=107626
>
> What about something like
>

Yes I think it is good idea.
One more point, there are multiple places where 'saving/restoring' api is
used and
I guess that each should be fixed.
That is why I added my solution into location where it could fix each of
them.
But your solution will be better for performance I think.
Is it acceptable for you to merge our solutions to:

---
 src/mesa/drivers/dri/i965/brw_compute.c   |  3 ++-
 src/mesa/drivers/dri/i965/brw_draw.c  |  3 ++-
 src/mesa/drivers/dri/i965/genX_blorp_exec.c   |  3 ++-
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 
 src/mesa/drivers/dri/i965/intel_batchbuffer.h |  1 +
 5 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_compute.c
b/src/mesa/drivers/dri/i965/brw_compute.c
index de08fc3..5c8e3a5 100644
--- a/src/mesa/drivers/dri/i965/brw_compute.c
+++ b/src/mesa/drivers/dri/i965/brw_compute.c
@@ -167,7 +167,7 @@ static void
 brw_dispatch_compute_common(struct gl_context *ctx)
 {
struct brw_context *brw = brw_context(ctx);
-   bool fail_next = false;
+   bool fail_next;

if (!_mesa_check_conditional_render(ctx))
   return;
@@ -185,6 +185,7 @@ brw_dispatch_compute_common(struct gl_context *ctx)
intel_batchbuffer_require_space(brw, 600);
brw_require_statebuffer_space(brw, 2500);
intel_batchbuffer_save_state(brw);
+   fail_next = intel_batchbuffer_saved_state_is_empty(brw);

  retry:
brw->batch.no_wrap = true;
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8536c04..19ee396 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
 {
struct brw_context *brw = brw_context(ctx);
const struct gen_device_info *devinfo = >screen->devinfo;
-   bool fail_next = false;
+   bool fail_next;

/* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
 * atoms that happen on every draw call.
@@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
intel_batchbuffer_require_space(brw, 1500);
brw_require_statebuffer_space(brw, 2400);
intel_batchbuffer_save_state(brw);
+   fail_next = intel_batchbuffer_saved_state_is_empty(brw);

if (brw->num_instances != prim->num_instances ||
brw->basevertex != prim->basevertex ||
diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
index 34bfcad..fd9ce93 100644
--- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
+++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
@@ -268,7 +268,7 @@ genX(blorp_exec)(struct blorp_batch *batch,
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
struct gl_context *ctx = >ctx;
-   bool check_aperture_failed_once = false;
+   bool check_aperture_failed_once;

 #if GEN_GEN >= 11
/* The PIPE_CONTROL command description says:
@@ -309,6 +309,7 @@ retry:
intel_batchbuffer_require_space(brw, 1400);
brw_require_statebuffer_space(brw, 600);
intel_batchbuffer_save_state(brw);
+   check_aperture_failed_once =
intel_batchbuffer_saved_state_is_empty(brw);
brw->batch.no_wrap = true;

 #if GEN_GEN == 6
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 4363b14..e0b7c94 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -57,6 +57,9 @@ static void
 intel_batchbuffer_reset(struct brw_context *brw);

 static void
+brw_new_batch(struct brw_context *brw);
+
+static void
 dump_validation_list(struct intel_batchbuffer *batch)
 {
fprintf(stderr, "Validation list (length %d):\n", batch->exec_count);
@@ -299,6 +302,13 @@ intel_batchbuffer_save_state(struct brw_context *brw)
brw->batch.saved.exec_count = brw->batch.exec_count;
 }

+bool
+intel_batchbuffer_saved_state_is_empty(struct brw_context *brw)
+{
+   struct intel_batchbuffer *batch = >batch;
+   return (batch->saved.map_next == batch->batch.map);
+}
+
 void
 intel_batchbuffer_reset_to_saved(struct brw_context *brw)
 {
@@ -311,6 +321,8 @@ intel_batchbuffer_reset_to_saved(struct brw_context
*brw)
brw->batch.exec_count = brw->batch.saved.exec_count;

brw->batch.map_next = brw->batch.saved.map_next;
+   if (USED_BATCH(brw->batch) == 0)
+brw_new_batch(brw);
 }

 void
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index 0632142..91720da 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -24,6 +24,7 @@ struct 

Re: [Mesa-dev] [PATCH] travis: use python3.5 for meson

[Eric Engestrom]

On Monday, 2018-09-10 14:15:33 +0200, Juan A. Suarez Romero wrote:
> Newer Meson versions require python >=3.5. But in Trusty default python3
> version is 3.4.x.
> 
> Install python3.5 and makes it the default version for Meson using
> update-alternatives method.
> 
> CC: Jan Vesely 
> CC: Andres Gomez 
> CC: Emil Velikov 
> CC: Jon Turney 
> CC: Eric Engestrom 
> CC: Dylan Baker 

Thanks!
Sorry I didn't notice that I broke travis right away, but thank you for
fixing it!

This is definitely a less heavy change than Emil's suggestion, so I'd
prefer this one:
Reviewed-by: Eric Engestrom 
Fixes: 3824c8e7cda97c3bf856 "meson: disable asserts by default on release 
builds"

> ---
> 
>  This is an alternative to avoid changing the distribution flavour in
>  https://patchwork.freedesktop.org/series/49349/
> 
>  .travis.yml | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 079f145a7e4..895030cc1bc 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -53,6 +53,7 @@ matrix:
>  - xz-utils
>  - libexpat1-dev
>  - libelf-dev
> +- python3.5
>  - python3-pip
>  - env:
>  - LABEL="meson loaders/classic DRI"
> @@ -69,6 +70,7 @@ matrix:
>  - libx11-xcb-dev
>  - libxdamage-dev
>  - libxfixes-dev
> +- python3.5
>  - python3-pip
>  - env:
>  - LABEL="make loaders/classic DRI"
> @@ -490,8 +492,10 @@ before_install:
>  
>  install:
># Install a more modern meson from pip, since the version in the
> -  # ubuntu repos is often quite old.
> +  # ubuntu repos is often quite old. This requires python>=3.5, so
> +  # let's make it default
>- if test "x$BUILD" = xmeson; then
> +  sudo update-alternatives --install /usr/bin/python3 python3 
> /usr/bin/python3.5 10;
>pip3 install --user meson;
>pip3 install --user mako;
>  fi
> -- 
> 2.17.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled

[bugzilla-daemon]

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

--- Comment #7 from ilia  ---
Created attachment 141506
  --> https://bugs.freedesktop.org/attachment.cgi?id=141506=edit
Fullscreen

Pressing alt+tab I eventually got able to see game menu. But it was not
interactable - even mouse hover. Screenshot seems to be broken, really it must
be 1680x1050. I have no idea why it cropped.

-- 
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 107777] No 3D in "Vampire: The Masquerade - Bloodlines" when d3d-nine enabled

[bugzilla-daemon]

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

--- Comment #6 from ilia  ---
Yes, results are the same. Moreover, I attached screenshots specifically for
this case:
1. wine in desktop mode + fullscreen game
https://bugs.freedesktop.org/attachment.cgi?id=141398
2. wine in desktop mode + windowed game
https://bugs.freedesktop.org/attachment.cgi?id=141403

so, same when wine not in desktop mode.

-- 
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] travis: pull xenial for python3.5 (and friends) on meson

[Juan A. Suarez Romero]

On Fri, 2018-09-07 at 14:58 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> The meson requirement was bumped recently to 0.45, which requires
> python 3.5
> 
> On travis that is only available on xenial. Additionally we need to pull
> setuptools package otherwise pip fails to install meson.
> 

Trusty on Travis provides python 3.5, though it is not the default python3
version.


In https://patchwork.freedesktop.org/series/49428/ I provide an alternative to
keep using Trusty, by installing python 3.5 and making it the default python3
version in Meson targets.


J.A.

> Pulling setuptools via pip, attempts to recursively attepmting to
> install pip, which ends miserably. To top of up, the setuptools package
> is missing an optional dependency (recommends) of python3-wheel.
> 
> So add that one as well to the list.
> 
> Fixes: 3824c8e7cda ("meson: disable asserts by default on release
> builds")
> Cc: Eric Engestrom 
> Signed-off-by: Emil Velikov 
> ---
>  .travis.yml | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 079f145a7e4..88f849be136 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -40,6 +40,7 @@ matrix:
>  - VULKAN_DRIVERS="intel,amd"
>  - LLVM_VERSION=6.0
>  - LLVM_CONFIG="llvm-config-${LLVM_VERSION}"
> +  dist: xenial # required for python 3.5, which is needed by meson
>addons:
>  apt:
>sources:
> @@ -54,12 +55,16 @@ matrix:
>  - libexpat1-dev
>  - libelf-dev
>  - python3-pip
> +# Meson
> +- python3-setuptools
> +- python3-wheel # required by setuptools, yet packaging does not 
> pull it
>  - env:
>  - LABEL="meson loaders/classic DRI"
>  - BUILD=meson
>  - DRI_DRIVERS="i915,i965,r100,r200,swrast,nouveau"
>  - GALLIUM_DRIVERS=""
>  - VULKAN_DRIVERS=""
> +  dist: xenial # required for python 3.5, which is needed by meson
>addons:
>  apt:
>packages:
> @@ -70,6 +75,9 @@ matrix:
>  - libxdamage-dev
>  - libxfixes-dev
>  - python3-pip
> +# Meson
> +- python3-setuptools
> +- python3-wheel # required by setuptools, yet packaging does not 
> pull it
>  - env:
>  - LABEL="make loaders/classic DRI"
>  - BUILD=make

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

[Mesa-dev] [PATCH] travis: use python3.5 for meson

[Juan A. Suarez Romero]

Newer Meson versions require python >=3.5. But in Trusty default python3
version is 3.4.x.

Install python3.5 and makes it the default version for Meson using
update-alternatives method.

CC: Jan Vesely 
CC: Andres Gomez 
CC: Emil Velikov 
CC: Jon Turney 
CC: Eric Engestrom 
CC: Dylan Baker 
---

 This is an alternative to avoid changing the distribution flavour in
 https://patchwork.freedesktop.org/series/49349/

 .travis.yml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 079f145a7e4..895030cc1bc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -53,6 +53,7 @@ matrix:
 - xz-utils
 - libexpat1-dev
 - libelf-dev
+- python3.5
 - python3-pip
 - env:
 - LABEL="meson loaders/classic DRI"
@@ -69,6 +70,7 @@ matrix:
 - libx11-xcb-dev
 - libxdamage-dev
 - libxfixes-dev
+- python3.5
 - python3-pip
 - env:
 - LABEL="make loaders/classic DRI"
@@ -490,8 +492,10 @@ before_install:
 
 install:
   # Install a more modern meson from pip, since the version in the
-  # ubuntu repos is often quite old.
+  # ubuntu repos is often quite old. This requires python>=3.5, so
+  # let's make it default
   - if test "x$BUILD" = xmeson; then
+  sudo update-alternatives --install /usr/bin/python3 python3 
/usr/bin/python3.5 10;
   pip3 install --user meson;
   pip3 install --user mako;
 fi
-- 
2.17.1

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

[Mesa-dev] [Bug 107878] Artifacting Hair on Overwatch vega56

[bugzilla-daemon]

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

--- Comment #2 from coolo...@gmail.com ---
to clarify, this also occurs on mesa 18.1.6 and llvm6

-- 
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 107878] Artifacting Hair on Overwatch vega56

[bugzilla-daemon]

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

--- Comment #1 from coolo...@gmail.com ---
Created attachment 141504
  --> https://bugs.freedesktop.org/attachment.cgi?id=141504=edit
screenshot example

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

Re: [Mesa-dev] [PATCH] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[Chris Wilson]

Quoting andrey simiklit (2018-08-21 13:00:57)
> Hi all,
> 
> The bug for this issue was created:
> https://bugs.freedesktop.org/show_bug.cgi?id=107626

What about something like

diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
b/src/mesa/drivers/dri/i965/brw_draw.c
index 8536c040109..babb8d4676d 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -885,7 +885,7 @@ brw_draw_single_prim(struct gl_context *ctx,
 {
struct brw_context *brw = brw_context(ctx);
const struct gen_device_info *devinfo = >screen->devinfo;
-   bool fail_next = false;
+   bool fail_next;
 
/* Flag BRW_NEW_DRAW_CALL on every draw.  This allows us to have
 * atoms that happen on every draw call.
@@ -898,6 +898,7 @@ brw_draw_single_prim(struct gl_context *ctx,
intel_batchbuffer_require_space(brw, 1500);
brw_require_statebuffer_space(brw, 2400);
intel_batchbuffer_save_state(brw);
+   fail_next = brw->batch.saved.map_next == 0;
 
if (brw->num_instances != prim->num_instances ||
brw->basevertex != prim->basevertex ||

There's no point reverting to the last saved point if that save point is
the empty batch, we will just repeat ourselves.
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] i965/batch: don't ignore the 'brw_new_batch' call for a 'new batch'

[asimiklit . work]

From: Andrii Simiklit 

If we restore the 'new batch' using 'intel_batchbuffer_reset_to_saved'
function we must restore the default state of the batch using
'brw_new_batch' function because the 'intel_batchbuffer_flush'
function will not do it for the 'new batch' again.
At least the following fields of the batch
'state_base_address_emitted','aperture_space', 'state_used'
should be restored to default values to avoid:
1. the aperture_space overflow
2. the missed STATE_BASE_ADDRESS commad in the batch
3. the memory overconsumption of the 'statebuffer'
   due to uncleared 'state_used' field.
etc.

v2: merge with new commits, changes was minimized, added the 'fixes' tag

Fixes: 3faf56ffbdeb "intel: Add an interface for saving/restoring
 the batchbuffer state."

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107626
Signed-off-by: Andrii Simiklit 

---
 src/mesa/drivers/dri/i965/intel_batchbuffer.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c 
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 4363b14..45eedab 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -57,6 +57,9 @@ static void
 intel_batchbuffer_reset(struct brw_context *brw);
 
 static void
+brw_new_batch(struct brw_context *brw);
+
+static void
 dump_validation_list(struct intel_batchbuffer *batch)
 {
fprintf(stderr, "Validation list (length %d):\n", batch->exec_count);
@@ -311,6 +314,8 @@ intel_batchbuffer_reset_to_saved(struct brw_context *brw)
brw->batch.exec_count = brw->batch.saved.exec_count;
 
brw->batch.map_next = brw->batch.saved.map_next;
+   if (USED_BATCH(brw->batch) == 0)
+brw_new_batch(brw);
 }
 
 void
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] mesa: tidy up init_matrix_stack()

[Alejandro Piñeiro]

Reviewed-by: Alejandro Piñeiro 


On 10/09/18 12:41, Timothy Arceri wrote:
> ---
>  src/mesa/main/matrix.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
> index 83f081e88e5..8065a83705c 100644
> --- a/src/mesa/main/matrix.c
> +++ b/src/mesa/main/matrix.c
> @@ -657,20 +657,16 @@ void _mesa_update_modelview_project( struct gl_context 
> *ctx, GLuint new_state )
>   * _math_matrix_ctr() for each element to initialize it.
>   */
>  static void
> -init_matrix_stack( struct gl_matrix_stack *stack,
> -   GLuint maxDepth, GLuint dirtyFlag )
> +init_matrix_stack(struct gl_matrix_stack *stack,
> +  GLuint maxDepth, GLuint dirtyFlag)
>  {
> -   GLuint i;
> -
> stack->Depth = 0;
> stack->MaxDepth = maxDepth;
> stack->DirtyFlag = dirtyFlag;
> /* The stack will be dynamically resized at glPushMatrix() time */
> stack->Stack = calloc(1, sizeof(GLmatrix));
> stack->StackSize = 1;
> -   for (i = 0; i < stack->StackSize; i++) {
> -  _math_matrix_ctr(>Stack[i]);
> -   }
> +   _math_matrix_ctr(>Stack[0]);
> stack->Top = stack->Stack;
>  }
>  

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

[Mesa-dev] [PATCH] mesa: tidy up init_matrix_stack()

[Timothy Arceri]

---
 src/mesa/main/matrix.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/mesa/main/matrix.c b/src/mesa/main/matrix.c
index 83f081e88e5..8065a83705c 100644
--- a/src/mesa/main/matrix.c
+++ b/src/mesa/main/matrix.c
@@ -657,20 +657,16 @@ void _mesa_update_modelview_project( struct gl_context 
*ctx, GLuint new_state )
  * _math_matrix_ctr() for each element to initialize it.
  */
 static void
-init_matrix_stack( struct gl_matrix_stack *stack,
-   GLuint maxDepth, GLuint dirtyFlag )
+init_matrix_stack(struct gl_matrix_stack *stack,
+  GLuint maxDepth, GLuint dirtyFlag)
 {
-   GLuint i;
-
stack->Depth = 0;
stack->MaxDepth = maxDepth;
stack->DirtyFlag = dirtyFlag;
/* The stack will be dynamically resized at glPushMatrix() time */
stack->Stack = calloc(1, sizeof(GLmatrix));
stack->StackSize = 1;
-   for (i = 0; i < stack->StackSize; i++) {
-  _math_matrix_ctr(>Stack[i]);
-   }
+   _math_matrix_ctr(>Stack[0]);
stack->Top = stack->Stack;
 }
 
-- 
2.17.1

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