[Mesa-dev] [PATCH 09/10] intel/genxml: Make "Predication enable" a boolean

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen8.xml | 2 +-
 src/intel/genxml/gen9.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 07fe014..971c997 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2698,7 +2698,7 @@
   
 
 
-
+
 
 
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index fe59ee9..b23c59d 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -2932,7 +2932,7 @@
   
 
 
-
+
 
 
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 07/10] intel/genxml; Make "Tiled Surface" a boolean

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen6.xml  | 4 ++--
 src/intel/genxml/gen7.xml  | 2 +-
 src/intel/genxml/gen75.xml | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index 3b7685b..b7bbd80 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -349,7 +349,7 @@
 
 
 
-
+
 
   
   
@@ -929,7 +929,7 @@
   
   
 
-
+
 
   
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 6d88f4a..a4a96e2 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -354,7 +354,7 @@
   
   
 
-
+
 
   
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 87f3143..52d0e95 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -364,7 +364,7 @@
   
   
 
-
+
 
   
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 04/10] intel/genxml: Make a couple of STREAMOUT fields booleans

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen7.xml  | 4 ++--
 src/intel/genxml/gen75.xml | 4 ++--
 src/intel/genxml/gen8.xml  | 4 ++--
 src/intel/genxml/gen9.xml  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index e476aa9..7d09835 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1704,8 +1704,8 @@
 
 
 
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 8d8df36..8c90f22 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1952,8 +1952,8 @@
 
 
 
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 6c54b68..7b8d572 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2039,8 +2039,8 @@
 
 
 
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 73b6fa5..69db6b6 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -2213,8 +2213,8 @@
 
 
 
-
-
+
+
 
 
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 01/10] intel/genxml: Make "Single Program Flow" a boolean

2016-10-14 Thread Jason Ekstrand 
We also get rid of the "(SPF)" a few places.

Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen6.xml  | 6 +++---
 src/intel/genxml/gen7.xml  | 8 
 src/intel/genxml/gen75.xml | 8 
 src/intel/genxml/gen8.xml  | 6 +++---
 src/intel/genxml/gen9.xml  | 6 +++---
 5 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index 5be4626..8a57e67 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -265,7 +265,7 @@
 
   
 
-
+
 
   
   
@@ -990,7 +990,7 @@
 
 
 
-
+
 
 
   
@@ -1407,7 +1407,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index ad866c1..c349c6c 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -288,7 +288,7 @@
 
   
 
-
+
 
   
   
@@ -1141,7 +1141,7 @@
 
 
 
-
+
 
 
   
@@ -1232,7 +1232,7 @@
 
 
 
-
+
 
 
 
@@ -1343,7 +1343,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index ab320fc..625e24c 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -298,7 +298,7 @@
 
   
 
-
+
 
   
   
@@ -1349,7 +1349,7 @@
 
 
 
-
+
 
 
   
@@ -1447,7 +1447,7 @@
 
 
 
-
+
 
 
 
@@ -1559,7 +1559,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 0dbcbcd..24b24a9 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -192,7 +192,7 @@
   
   
 
-
+
 
   
   
@@ -1386,7 +1386,7 @@
 
 
 
-
+
 
 
   
@@ -1581,7 +1581,7 @@
 
 
 
-
+
 
 
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index be5cc01f..ec0d0dc 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -181,7 +181,7 @@
   
   
 
-
+
 
   
   
@@ -1488,7 +1488,7 @@
 
 
 
-
+
 
 
   
@@ -1691,7 +1691,7 @@
 
 
 
-
+
 
 
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 05/10] intel/genxml: Make "Stencil Buffer Enable" a boolean

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen75.xml | 2 +-
 src/intel/genxml/gen8.xml  | 2 +-
 src/intel/genxml/gen9.xml  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 8c90f22..67762c6 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1939,7 +1939,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 7b8d572..9258b71 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2025,7 +2025,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 69db6b6..a82d1e0 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -2199,7 +2199,7 @@
 
 
 
-
+
 
 
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 02/10] intel/genxml: Make "Vector Mask Enable" a boolean

2016-10-14 Thread Jason Ekstrand 
We also get rid of the "(VME)" a few places

Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen6.xml  | 6 +++---
 src/intel/genxml/gen7.xml  | 6 +++---
 src/intel/genxml/gen75.xml | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index 8a57e67..3b7685b 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -991,7 +991,7 @@
 
 
 
-
+
 
   
   
@@ -1374,7 +1374,7 @@
 
 
 
-
+
 
   
   
@@ -1408,7 +1408,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index c349c6c..018b2ff 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1142,7 +1142,7 @@
 
 
 
-
+
 
   
   
@@ -1344,7 +1344,7 @@
 
 
 
-
+
 
 
   
@@ -1857,7 +1857,7 @@
 
 
 
-
+
 
   
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 625e24c..06fc7e3 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1350,7 +1350,7 @@
 
 
 
-
+
 
   
   
@@ -1560,7 +1560,7 @@
 
 
 
-
+
 
 
   
@@ -2115,7 +2115,7 @@
 
 
 
-
+
 
   
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 03/10] intel/genxml: Make "Include Vertex Handles" and "Include Primitive ID" booleans

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen7.xml  | 6 +++---
 src/intel/genxml/gen75.xml | 6 +++---
 src/intel/genxml/gen8.xml  | 6 +++---
 src/intel/genxml/gen9.xml  | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 018b2ff..e476aa9 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1167,7 +1167,7 @@
 
 
 
-
+
 
 
 
@@ -1185,7 +1185,7 @@
 
 
 
-
+
 
 
 
@@ -1234,7 +1234,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 06fc7e3..8d8df36 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1376,7 +1376,7 @@
 
 
 
-
+
 
 
 
@@ -1390,7 +1390,7 @@
 
 
 
-
+
 
 
   
@@ -1450,7 +1450,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 24b24a9..6c54b68 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -1413,7 +1413,7 @@
 
 
 
-
+
 
 
 
@@ -1427,7 +1427,7 @@
 
 
 
-
+
 
 
   
@@ -1493,7 +1493,7 @@
 
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index ec0d0dc..73b6fa5 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -1516,7 +1516,7 @@
 
 
 
-
+
 
 
 
@@ -1529,7 +1529,7 @@
 
 
 
-
+
 
 
   
@@ -1597,7 +1597,7 @@
 
 
 
-
+
 
 
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 10/10] intel/genxml: Make some PIPE_CONTROL fields booleans

2016-10-14 Thread Jason Ekstrand 
---
 src/intel/genxml/gen6.xml  | 9 +++--
 src/intel/genxml/gen7.xml  | 7 ++-
 src/intel/genxml/gen75.xml | 7 ++-
 src/intel/genxml/gen8.xml  | 7 ++-
 src/intel/genxml/gen9.xml  | 7 ++-
 5 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index 57e6d45..211716b 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -1877,12 +1877,9 @@
 
 
 
-
-  
-  
-
-
-
+
+
+
 
 
   
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 0105b42..eabb244 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -2428,11 +2428,8 @@
 
 
 
-
-  
-  
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 5022d8f..27a12cb 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -2827,11 +2827,8 @@
 
 
 
-
-  
-  
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 971c997..ee62614 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -3068,11 +3068,8 @@
 
 
 
-
-  
-  
-
-
+
+
 
 
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index b23c59d..9c81c5a 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -3348,11 +3348,8 @@
 
 
 
-
-  
-  
-
-
+
+
 
 
   
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 08/10] intel/genxml; Make "Use Global GTT a boolean

2016-10-14 Thread Jason Ekstrand 
We also remove the redundant zero defaults since everything without an
explicit default gets zeroed automatically.

Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen6.xml  | 11 ---
 src/intel/genxml/gen7.xml  | 15 ++-
 src/intel/genxml/gen75.xml | 15 ++-
 src/intel/genxml/gen8.xml  | 25 -
 src/intel/genxml/gen9.xml  | 25 -
 5 files changed, 32 insertions(+), 59 deletions(-)

diff --git a/src/intel/genxml/gen6.xml b/src/intel/genxml/gen6.xml
index b7bbd80..57e6d45 100644
--- a/src/intel/genxml/gen6.xml
+++ b/src/intel/genxml/gen6.xml
@@ -1695,10 +1695,7 @@
   
 
 
-
-  
-  
-
+
 
 
 
@@ -1710,7 +1707,7 @@
   
 
 
-
+
 
 
 
@@ -1798,7 +1795,7 @@
   
 
 
-
+
 
 
 
@@ -1818,7 +1815,7 @@
   
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index a4a96e2..0105b42 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -2200,10 +2200,7 @@
   
 
 
-
-  
-  
-
+
 
 
 
@@ -2216,7 +2213,7 @@
   
 
 
-
+
 
 
 
@@ -2254,7 +2251,7 @@
   
 
 
-
+
 
 
 
@@ -2298,7 +2295,7 @@
 
 
 
-
+
 
   
 
@@ -2329,7 +2326,7 @@
   
 
 
-
+
 
 
 
@@ -2349,7 +2346,7 @@
   
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 52d0e95..5022d8f 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -2493,10 +2493,7 @@
   
 
 
-
-  
-  
-
+
 
 
 
@@ -2509,7 +2506,7 @@
   
 
 
-
+
 
 
 
@@ -2547,7 +2544,7 @@
   
 
 
-
+
 
 
 
@@ -2645,7 +2642,7 @@
 
 
 
-
+
 
   
 
@@ -2712,7 +2709,7 @@
   
 
 
-
+
 
 
 
@@ -2732,7 +2729,7 @@
   
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 9258b71..07fe014 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -2711,10 +2711,7 @@
   
 
 
-
-  
-  
-
+
 
 
 
@@ -2726,7 +2723,7 @@
   
 
 
-
+
 
 
 
@@ -2736,14 +2733,8 @@
   
 
 
-
-  
-  
-
-
-  
-  
-
+
+
 
 
 
@@ -2761,7 +2752,7 @@
   
 
 
-
+
 
 
 
@@ -2860,7 +2851,7 @@
 
 
 
-
+
 
   
 
@@ -2963,7 +2954,7 @@
   
 
 
-
+
 
 
 
@@ -2985,7 +2976,7 @@
   
 
 
-
+
 
 
 
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index a82d1e0..fe59ee9 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -2945,10 +2945,7 @@
   
 
 
-
-  
-  
-
+
 
 
 
@@ -2960,7 +2957,7 @@
   
 
 
-
+
 
 
   
@@ -2974,14 +2971,8 @@
   
 
 
-
-  
-  
-
-
-  
-  
-
+
+
 
 
 
@@ -3039,7 +3030,7 @@
   
 
 
-
+
 
 
 
@@ -3138,7 +3129,7 @@
 
 
 
-
+
 
   
 
@@ -3241,7 +3232,7 @@
   
 
 
-
+
 
 
 
@@ -3263,7 +3254,7 @@
   
 
 
-
+
 
 
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 06/10] intel/genxml: Make "SO Buffer Enable" fields boolean

2016-10-14 Thread Jason Ekstrand 
Signed-off-by: Jason Ekstrand 
---
 src/intel/genxml/gen7.xml  | 8 
 src/intel/genxml/gen75.xml | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 7d09835..6d88f4a 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1712,10 +1712,10 @@
   
 
 
-
-
-
-
+
+
+
+
 
 
 
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index 67762c6..87f3143 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1960,10 +1960,10 @@
   
 
 
-
-
-
-
+
+
+
+
 
 
 
-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [PATCH 00/10] intel/genxml: Make more stuff booleans

2016-10-14 Thread Jason Ekstrand 
This is a fairly trivial little cleanup that makes a bunch of 1-bit fields
that used to have the "uint" type have the "bool" type instead.  Ideally, a
field should have the "bool" type if and only if, given the name of the
field and a true/false value, it's obvious what that value means.  I think
this little series gets us most of the way there.  The only 1-bit fields
left are either media things or things that don't have an obvious
true/false meaning to me.

Jason Ekstrand (10):
  intel/genxml: Make "Single Program Flow" a boolean
  intel/genxml: Make "Vector Mask Enable" a boolean
  intel/genxml: Make "Include Vertex Handles" and "Include Primitive ID"
booleans
  intel/genxml: Make a couple of STREAMOUT fields booleans
  intel/genxml: Make "Stencil Buffer Enable" a boolean
  intel/genxml: Make "SO Buffer Enable" fields boolean
  intel/genxml; Make "Tiled Surface" a boolean
  intel/genxml; Make "Use Global GTT a boolean
  intel/genxml: Make "Predication enable" a boolean
  intel/genxml: Make some PIPE_CONTROL fields booleans

 src/intel/genxml/gen6.xml  | 36 
 src/intel/genxml/gen7.xml  | 56 
 src/intel/genxml/gen75.xml | 58 +-
 src/intel/genxml/gen8.xml  | 52 -
 src/intel/genxml/gen9.xml  | 52 -
 5 files changed, 106 insertions(+), 148 deletions(-)

-- 
2.5.0.400.gff86faf

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #16 from shinji.suz...@gmail.com ---
Created attachment 127317
  --> https://bugs.freedesktop.org/attachment.cgi?id=127317&action=edit
Arbitration on so->fence through per sync-object mutex.

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #15 from shinji.suz...@gmail.com ---
Created attachment 127316
  --> https://bugs.freedesktop.org/attachment.cgi?id=127316&action=edit
Arbitration on so->fence based on Michel-san's patch

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

[Mesa-dev] [Bug 98172] Concurrent call to glClientWaitSync results in segfault in one of the waiters.

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98172

--- Comment #14 from shinji.suz...@gmail.com ---
I've ben running tests with changes derived from your patch, with and without
random sleeps to give some shake-ups to execution order with, and have seen no
crashes so far. The differences from yours are;
* No mutual exclusions in ctor/dtor functions. (I see no chance of race in ctor
and dtor should be called only by the thread that eliminated the last
reference.)
* Locking duration is made slightly shorter.

Now I feel sufficiently convinced about the correctness of the fix and at the
same time feels that alternative implementation may better be given
consideration. As I wrote previously locking on so->Shared.Mutex introduces
contention that is not essential. Allowing concurrent calls, in relative to the
sync object at hand, to fence_finish() will require more careful implementation
from underlining gpu specific drivers, though r600 implementation seems good,
and running the same check by multiple threads seems inefficient. I'll attach
patch for an alternative implementation as well.

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

[Mesa-dev] [PATCH] i965: Fix gl_InvocationID in dual object GS where invocations == 1.

2016-10-14 Thread Kenneth Graunke 
dEQP-GLES31.functional.geometry_shading.instanced.geometry_1_invocations
draws using a geometry shader that specifies

   layout(points, invocations = 1) in;

and then uses gl_InvocationID.  According to the Haswell PRM, the
"GS Instance ID 0" (and 1) thread payload fields are undefined in
dual object mode:

   "If 'dispatch mode' is DUAL_OBJECT this field is not valid."

But there's no point in using them - if there's only one invocation,
the ID will be 0.  So just load a constant.

Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke 
---
 src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
index c5886d4..59c7d21 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp
@@ -59,7 +59,10 @@ vec4_gs_visitor::make_reg_for_system_value(int location)
switch (location) {
case SYSTEM_VALUE_INVOCATION_ID:
   this->current_annotation = "initialize gl_InvocationID";
-  emit(GS_OPCODE_GET_INSTANCE_ID, *reg);
+  if (gs_prog_data->invocations > 1)
+ emit(GS_OPCODE_GET_INSTANCE_ID, *reg);
+  else
+ emit(MOV(*reg, brw_imm_ud(0)));
   break;
default:
   unreachable("not reached");
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH 4/4] i965: Silence unused parameter warnings

2016-10-14 Thread Ian Romanick 
On 10/14/2016 05:44 PM, Eric Engestrom wrote:
>> Subject: [PATCH 4/4] i965: Silence unused parameter warnings
> 
> How about "remove unused parameters" instead?
> Silencing the warnings is nothing more than a side effect of this
> change, albeit the reason you realised it was needed.

There are already quite a few commits in Mesa with subjects that match
this pattern.  I've generally used this when the purpose of the change
is to make the compiler complain less.

Also... not all of the changes in this commit remove the unused
parameter. :)

> (Sorry, I've seen so many "silence warning" commits at $DAYJOB that
> this has become a pet peeve of mine)
> 
> One suggestion below, but the series looks good:
> Reviewed-by: Eric Engestrom 
> 
> 
> On Fri, Oct 14, 2016 at 11:59:47AM -0700, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> brw_link.cpp:76:44: warning: unused parameter ‘shader_type’ 
>> [-Wunused-parameter]
>> gl_shader_stage shader_type,
>> ^
>> brw_nir.c: In function ‘brw_nir_lower_vs_inputs’:
>> brw_nir.c:194:55: warning: unused parameter ‘devinfo’ [-Wunused-parameter]
>>  const struct gen_device_info *devinfo,
>>^
>> brw_vec4_visitor.cpp:914:37: warning: unused parameter ‘sampler’ 
>> [-Wunused-parameter]
>> uint32_t sampler,
>>  ^
>> brw_vec4_visitor.cpp:1146:34: warning: unused parameter ‘stream_id’ 
>> [-Wunused-parameter]
>>  vec4_visitor::gs_emit_vertex(int stream_id)
>>   ^
>>
>> Signed-off-by: Ian Romanick 
>> ---
>>  src/mesa/drivers/dri/i965/brw_link.cpp | 3 +--
>>  src/mesa/drivers/dri/i965/brw_nir.c| 1 -
>>  src/mesa/drivers/dri/i965/brw_nir.h| 1 -
>>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
>>  src/mesa/drivers/dri/i965/brw_vec4.h   | 2 +-
>>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 +-
>>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 3 +--
>>  7 files changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
>> b/src/mesa/drivers/dri/i965/brw_link.cpp
>> index 02151d6..5ea9773 100644
>> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
>> @@ -73,7 +73,6 @@ brw_shader_precompile(struct gl_context *ctx,
>>  
>>  static void
>>  brw_lower_packing_builtins(struct brw_context *brw,
>> -   gl_shader_stage shader_type,
>> exec_list *ir)
>>  {
>> /* Gens < 7 don't have instructions to convert to or from half-precision,
>> @@ -105,7 +104,7 @@ process_glsl_ir(struct brw_context *brw,
>> /* lower_packing_builtins() inserts arithmetic instructions, so it
>>  * must precede lower_instructions().
>>  */
>> -   brw_lower_packing_builtins(brw, shader->Stage, shader->ir);
>> +   brw_lower_packing_builtins(brw, shader->ir);
>> do_mat_op_to_vec(shader->ir);
>>  
>> unsigned instructions_to_lower = (DIV_TO_MUL_RCP |
>> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
>> b/src/mesa/drivers/dri/i965/brw_nir.c
>> index 744865b..a935f42 100644
>> --- a/src/mesa/drivers/dri/i965/brw_nir.c
>> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
>> @@ -191,7 +191,6 @@ remap_patch_urb_offsets(nir_block *block, nir_builder *b,
>>  
>>  void
>>  brw_nir_lower_vs_inputs(nir_shader *nir,
>> -const struct gen_device_info *devinfo,
>>  bool is_scalar,
>>  bool use_legacy_snorm_formula,
>>  const uint8_t *vs_attrib_wa_flags)
>> diff --git a/src/mesa/drivers/dri/i965/brw_nir.h 
>> b/src/mesa/drivers/dri/i965/brw_nir.h
>> index 425d6ce..aef5c53 100644
>> --- a/src/mesa/drivers/dri/i965/brw_nir.h
>> +++ b/src/mesa/drivers/dri/i965/brw_nir.h
>> @@ -99,7 +99,6 @@ nir_shader *brw_preprocess_nir(const struct brw_compiler 
>> *compiler,
>>  bool brw_nir_lower_intrinsics(nir_shader *nir,
>>struct brw_stage_prog_data *prog_data);
>>  void brw_nir_lower_vs_inputs(nir_shader *nir,
>> - const struct gen_device_info *devinfo,
>>   bool is_scalar,
>>   bool use_legacy_snorm_formula,
>>   const uint8_t *vs_attrib_wa_flags);
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> index 6aa9102..362f32b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> @@ -2114,7 +2114,7 @@ brw_compile_vs(const struct brw_compiler *compiler, 
>> void *log_data,
>> nir_shader *shader = nir_shader_clone(mem_ctx, src_shader);
>> shader = brw_nir_apply_sampler_key(shader, compiler->devinfo, &key->tex,
>>is_scalar);
>

Re: [Mesa-dev] [PATCH 02/16] loader: slim down loader_get_pci_id_for_fd implementation(s)

2016-10-14 Thread Jonathan Gray 
On Tue, Oct 11, 2016 at 07:31:46PM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Currently mesa has three code paths in the loader - libudev, manual
> sysfs and drm ioctl one.
> 
> Considering the issues we had with libudev - strip those down in favour
> of the libdrm drm device API. The latter can be implemented in any way
> depending on the platform and can be reused by others.
> 
> Cc: Jonathan Gray 
> Cc: Jean-S??bastien P??dron 
> Signed-off-by: Emil Velikov 
> ---
> Jonathan, Jean-S??bastien I believe I've prodded you guys for a *BSD
> implementation of the drm*Device API a while back. With this commit
> you'll be 'forced' to prep some ;-)

It has been a while since I looked into that.  The design seemed to
assume that the user running code that called into libdrm had the
ability to enumerate pci busses.

On OpenBSD /dev/pci* is only read/writable by root.  /dev/drm* is
chowned after a user logs into a console.

We don't use filesystems for communicating with the kernel like linux
does so ioctls are really the best fit.  The loader parts used at the
moment use drm driver specific ioctls, hopefully a generic version of
those that can return the vid/pid, subids and function id numbers would
cover most of it.

> 
> About the implementation itself feel free to use libudev/equivalent (we
> cannot do so on Linux, since due to fun interactions with Steam's one)
> or any other means available on your platform. Fwiw I would strongly
> suggest _against_ adding DRM specific ioctls just for this purpose but
> at the end of the day it's your code/userbase.
> 
> On the FreeBSD/DragonFly side this means that you no londer require a
> handful of patches for mesa, which is always a plus.
> ---
>  src/loader/loader.c | 172 
> +---
>  1 file changed, 16 insertions(+), 156 deletions(-)
> 
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 3e60e4c..41ea016 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -204,57 +204,6 @@ udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
>  }
>  
> -static int
> -libudev_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> -   struct udev *udev = NULL;
> -   struct udev_device *device = NULL, *parent;
> -   const char *pci_id;
> -   UDEV_SYMBOL(struct udev *, udev_new, (void));
> -   UDEV_SYMBOL(struct udev_device *, udev_device_get_parent,
> -   (struct udev_device *));
> -   UDEV_SYMBOL(const char *, udev_device_get_property_value,
> -   (struct udev_device *, const char *));
> -   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
> -   (struct udev_device *));
> -   UDEV_SYMBOL(struct udev *, udev_unref, (struct udev *));
> -
> -   *chip_id = -1;
> -
> -   if (dlsym_failed)
> -  return 0;
> -
> -   udev = udev_new();
> -   device = udev_device_new_from_fd(udev, fd);
> -   if (!device)
> -  goto out;
> -
> -   parent = udev_device_get_parent(device);
> -   if (parent == NULL) {
> -  log_(_LOADER_WARNING, "MESA-LOADER: could not get parent device\n");
> -  goto out;
> -   }
> -
> -   pci_id = udev_device_get_property_value(parent, "PCI_ID");
> -   if (pci_id == NULL) {
> -  log_(_LOADER_INFO, "MESA-LOADER: no PCI ID\n");
> -  *chip_id = -1;
> -  goto out;
> -   } else if (sscanf(pci_id, "%x:%x", vendor_id, chip_id) != 2) {
> -  log_(_LOADER_WARNING, "MESA-LOADER: malformed PCI ID\n");
> -  *chip_id = -1;
> -  goto out;
> -   }
> -
> -out:
> -   if (device)
> -  udev_device_unref(device);
> -   if (udev)
> -  udev_unref(udev);
> -
> -   return (*chip_id >= 0);
> -}
> -
>  static char *
>  get_render_node_from_id_path_tag(struct udev *udev,
>   char *id_path_tag,
> @@ -471,113 +420,32 @@ dev_node_from_fd(int fd, unsigned int *maj, unsigned 
> int *min)
>  }
>  #endif
>  
> -#if defined(HAVE_SYSFS)
> -static int
> -sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
> -{
> -   unsigned int maj, min;
> -   FILE *f;
> -   char buf[0x40];
> -
> -   if (dev_node_from_fd(fd, &maj, &min) < 0) {
> -  *chip_id = -1;
> -  return 0;
> -   }
> -
> -   snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/vendor", maj, min);
> -   if (!(f = fopen(buf, "r"))) {
> -  *chip_id = -1;
> -  return 0;
> -   }
> -   if (fscanf(f, "%x", vendor_id) != 1) {
> -  *chip_id = -1;
> -  fclose(f);
> -  return 0;
> -   }
> -   fclose(f);
> -   snprintf(buf, sizeof(buf), "/sys/dev/char/%d:%d/device/device", maj, min);
> -   if (!(f = fopen(buf, "r"))) {
> -  *chip_id = -1;
> -  return 0;
> -   }
> -   if (fscanf(f, "%x", chip_id) != 1) {
> -  *chip_id = -1;
> -  fclose(f);
> -  return 0;
> -   }
> -   fclose(f);
> -   return 1;
> -}
> -#endif
> -
>  #if defined(HAVE_LIBDRM)
> -/* for i915 */
> -#include 
> -/* for radeon */
> -#include 
>  
>  static int
>  drm_get_pci_id_for_fd(int fd, int *vendor_id, int *chip_id)
>  {
> -

[Mesa-dev] [PATCH] draw: improve vertex fetch (v2)

2016-10-14 Thread sroland 
From: Roland Scheidegger 

The per-element fetch has quite some calculations which are constant,
these can be moved outside both the per-element as well as the main
shader loop (llvm can figure out it's constant mostly on its own, however
this can have a significant compile time cost).
Similarly, it looks easier swapping the fetch loops (outer loop per attrib,
inner loop filling up the per vertex elements - this way the aos->soa
conversion also can be done per attrib and not just at the end though again
this doesn't really make much of a difference in the generated code). (This
would also make it possible to vectorize the calculations leading to the
fetches.)
There's also some minimal change simplifying the overflow math slightly.
All in all, the generated code seems to look slightly simpler (depending
on the actual vs), but more importantly I've seen a significant reduction
in compile times for some vs (albeit with old (3.3) llvm version, and the
time reduction is only really for the optimizations run on the IR).
v2: adapt to other draw change.

No changes with piglit.
---
 src/gallium/auxiliary/draw/draw_llvm.c | 190 +++--
 .../auxiliary/gallivm/lp_bld_arit_overflow.c   |  24 +++
 .../auxiliary/gallivm/lp_bld_arit_overflow.h   |   6 +
 3 files changed, 134 insertions(+), 86 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c
index 3b56856..2f82d9d 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -659,85 +659,42 @@ generate_vs(struct draw_llvm_variant *variant,
 static void
 generate_fetch(struct gallivm_state *gallivm,
struct draw_context *draw,
-   LLVMValueRef vbuffers_ptr,
+   const struct util_format_description *format_desc,
+   LLVMValueRef vb_stride,
+   LLVMValueRef stride_fixed,
+   LLVMValueRef map_ptr,
+   LLVMValueRef buffer_size_adj,
+   LLVMValueRef ofbit,
LLVMValueRef *res,
-   struct pipe_vertex_element *velem,
-   LLVMValueRef vbuf,
-   LLVMValueRef index,
-   LLVMValueRef instance_id,
-   LLVMValueRef start_instance)
+   LLVMValueRef index)
 {
-   const struct util_format_description *format_desc =
-  util_format_description(velem->src_format);
LLVMValueRef zero = LLVMConstNull(LLVMInt32TypeInContext(gallivm->context));
LLVMBuilderRef builder = gallivm->builder;
-   LLVMValueRef indices =
-  LLVMConstInt(LLVMInt64TypeInContext(gallivm->context),
-   velem->vertex_buffer_index, 0);
-   LLVMValueRef vbuffer_ptr = LLVMBuildGEP(builder, vbuffers_ptr,
-   &indices, 1, "");
-   LLVMValueRef vb_stride = draw_jit_vbuffer_stride(gallivm, vbuf);
-   LLVMValueRef vb_buffer_offset = draw_jit_vbuffer_offset(gallivm, vbuf);
-   LLVMValueRef map_ptr = draw_jit_dvbuffer_map(gallivm, vbuffer_ptr);
-   LLVMValueRef buffer_size = draw_jit_dvbuffer_size(gallivm, vbuffer_ptr);
LLVMValueRef stride;
LLVMValueRef buffer_overflowed;
-   LLVMValueRef needed_buffer_size;
LLVMValueRef temp_ptr =
   lp_build_alloca(gallivm,
   lp_build_vec_type(gallivm, lp_float32_vec4_type()), "");
-   LLVMValueRef ofbit = NULL;
struct lp_build_if_state if_ctx;
 
-   if (velem->src_format == PIPE_FORMAT_NONE) {
+   if (format_desc->format == PIPE_FORMAT_NONE) {
   *res = lp_build_const_vec(gallivm, lp_float32_vec4_type(), 0);
   return;
}
 
-   if (velem->instance_divisor) {
-  /* Index is equal to the start instance plus the number of current 
-   * instance divided by the divisor. In this case we compute it as:
-   * index = start_instance + (instance_id  / divisor)
-   */
-  LLVMValueRef current_instance;
-  current_instance = LLVMBuildUDiv(builder, instance_id,
-   lp_build_const_int32(gallivm, 
velem->instance_divisor),
-   "instance_divisor");
-  index = lp_build_uadd_overflow(gallivm, start_instance,
- current_instance, &ofbit);
-   }
-
stride = lp_build_umul_overflow(gallivm, vb_stride, index, &ofbit);
-   stride = lp_build_uadd_overflow(gallivm, stride, vb_buffer_offset, &ofbit);
-   stride = lp_build_uadd_overflow(
-  gallivm, stride,
-  lp_build_const_int32(gallivm, velem->src_offset), &ofbit);
-   needed_buffer_size = lp_build_uadd_overflow(
-  gallivm, stride,
-  lp_build_const_int32(gallivm,
-   util_format_get_blocksize(velem->src_format)),
-  &ofbit);
+   stride = lp_build_uadd_overflow(gallivm, stride, stride_fixed, &ofbit);
 
buffer_overflowed = LLVMBuildICmp(builder, LLVMIntUGT,
- needed_buffer_size, buffer_size,
+

Re: [Mesa-dev] [PATCH] state_tracker: Fix check for scissor enabled when < 0.

2016-10-14 Thread Kenneth Graunke 
On Friday, October 14, 2016 4:37:38 PM PDT Eric Anholt wrote:
> DEQP's clear tests like to give us x + w < 0 or y + h < 0.  Since we
> were comparing to an unsigned, it would get promoted to unsigned and come
> out as bignum >= width or height and we would clear the whole fb instead
> of none of the fb.
> 
> Fixes 10 tests under deqp-gles2/functional/color_clear.
> ---
>  src/mesa/state_tracker/st_cb_clear.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_cb_clear.c 
> b/src/mesa/state_tracker/st_cb_clear.c
> index 813ba9b10ffa..158efc186c05 100644
> --- a/src/mesa/state_tracker/st_cb_clear.c
> +++ b/src/mesa/state_tracker/st_cb_clear.c
> @@ -318,8 +318,8 @@ is_scissor_enabled(struct gl_context *ctx, struct 
> gl_renderbuffer *rb)
> return (ctx->Scissor.EnableFlags & 1) &&
>(scissor->X > 0 ||
> scissor->Y > 0 ||
> -   scissor->X + scissor->Width < rb->Width ||
> -   scissor->Y + scissor->Height < rb->Height);
> +   scissor->X + scissor->Width < (int)rb->Width ||
> +   scissor->Y + scissor->Height < (int)rb->Height);
>  }
>  
>  /**
> 

Reviewed-by: Kenneth Graunke 


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

Re: [Mesa-dev] [PATCH v2] egl/wayland: Avoid race conditions when on non-main thread

2016-10-14 Thread Emil Velikov 
[Cc-ing Daniel/Pekka]

Hi all,

On 24 June 2016 at 03:46, Jonas Ådahl  wrote:
> When EGL is used on some other thread than the thread that drives the
> main wl_display queue, the Wayland EGL dri2 implementation is
> vulnerable to a race condition related to display round trips and global
> object advertisements.
>
> The race that may happen is that after after a proxy is created, but
> before the queue is set, events meant to be emitted via the yet to be
> set queue may already have been queued on the wrong queue.
>
> In order to make it possible to avoid this race, wayland 1.11
> introduced new API that allows creating a proxy wrapper that may be used
> as the factory proxy when creating new proxies via Wayland requests. The
> queue of a proxy wrapper can be changed without effecting what queue
> events emitted by the actual proxy will be queued on, while still
> effecting what default queue proxies created from it will have.
>
> By introducing a wl_display proxy wrapper and using this when performing
> round trips (via wl_display_sync()) and retrieving the global objects (via
> wl_display_get_registry()), the mentioned race condition is avoided.
>
> Signed-off-by: Jonas Ådahl 
> ---
>
> Changes since v1:
>
>  - Added proxy clean up on tear down
>  - Changed required version to the stable wayland release (1.11)
>
>
>  configure.ac|  2 +-
>  src/egl/drivers/dri2/egl_dri2.c |  1 +
>  src/egl/drivers/dri2/egl_dri2.h |  1 +
>  src/egl/drivers/dri2/platform_wayland.c | 30 --
>  4 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 023110e..d73af83 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -83,7 +83,7 @@ GLPROTO_REQUIRED=1.4.14
>  LIBOMXIL_BELLAGIO_REQUIRED=0.0
>  LIBVA_REQUIRED=0.38.0
>  VDPAU_REQUIRED=1.1
> -WAYLAND_REQUIRED=1.2.0
> +WAYLAND_REQUIRED=1.11
>  XCB_REQUIRED=1.9.3
>  XCBDRI2_REQUIRED=1.8
>  XCBGLX_REQUIRED=1.8.1
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index d8448f4..88191b4 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -849,6 +849,7 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp)
>wl_shm_destroy(dri2_dpy->wl_shm);
>wl_registry_destroy(dri2_dpy->wl_registry);
>wl_event_queue_destroy(dri2_dpy->wl_queue);
> +  wl_proxy_wrapper_destroy(dri2_dpy->wl_dpy_wrapper);
>if (dri2_dpy->own_device) {
>   wl_display_disconnect(dri2_dpy->wl_dpy);
>}
> diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
> index ddb5f39..075c2a4 100644
> --- a/src/egl/drivers/dri2/egl_dri2.h
> +++ b/src/egl/drivers/dri2/egl_dri2.h
> @@ -205,6 +205,7 @@ struct dri2_egl_display
>
>  #ifdef HAVE_WAYLAND_PLATFORM
> struct wl_display*wl_dpy;
> +   struct wl_display*wl_dpy_wrapper;
> struct wl_registry   *wl_registry;
> struct wl_drm*wl_server_drm;
> struct wl_drm*wl_drm;
> diff --git a/src/egl/drivers/dri2/platform_wayland.c 
> b/src/egl/drivers/dri2/platform_wayland.c
> index ff0d5c8..519469e 100644
> --- a/src/egl/drivers/dri2/platform_wayland.c
> +++ b/src/egl/drivers/dri2/platform_wayland.c
> @@ -74,9 +74,8 @@ roundtrip(struct dri2_egl_display *dri2_dpy)
> struct wl_callback *callback;
> int done = 0, ret = 0;
>
> -   callback = wl_display_sync(dri2_dpy->wl_dpy);
> +   callback = wl_display_sync(dri2_dpy->wl_dpy_wrapper);
> wl_callback_add_listener(callback, &sync_listener, &done);
> -   wl_proxy_set_queue((struct wl_proxy *) callback, dri2_dpy->wl_queue);
> while (ret != -1 && !done)
>ret = wl_display_dispatch_queue(dri2_dpy->wl_dpy, dri2_dpy->wl_queue);
>
> @@ -765,11 +764,9 @@ dri2_wl_swap_buffers_with_damage(_EGLDriver *drv,
>  * handle the commit and send a release event before checking for a free
>  * buffer */
> if (dri2_surf->throttle_callback == NULL) {
> -  dri2_surf->throttle_callback = wl_display_sync(dri2_dpy->wl_dpy);
> +  dri2_surf->throttle_callback = 
> wl_display_sync(dri2_dpy->wl_dpy_wrapper);
>wl_callback_add_listener(dri2_surf->throttle_callback,
> &throttle_listener, dri2_surf);
> -  wl_proxy_set_queue((struct wl_proxy *) dri2_surf->throttle_callback,
> - dri2_dpy->wl_queue);
> }
>
> wl_display_flush(dri2_dpy->wl_dpy);
> @@ -1093,12 +1090,17 @@ dri2_initialize_wayland_drm(_EGLDriver *drv, 
> _EGLDisplay *disp)
>
> dri2_dpy->wl_queue = wl_display_create_queue(dri2_dpy->wl_dpy);
>
> +   dri2_dpy->wl_dpy_wrapper = wl_proxy_create_wrapper(dri2_dpy->wl_dpy);
> +   if (dri2_dpy->wl_dpy_wrapper == NULL)
> +  goto cleanup_dpy_wrapper;
> +
> +   wl_proxy_set_queue((struct wl_proxy *) dri2_dpy->wl_dpy_wrapper,
> +  dri2_dpy->wl_queue);
> +
> if (dri2_dpy->own_device)
>wl_display_dispatch_pending(dr

Re: [Mesa-dev] [PATCH 4/4] i965: Silence unused parameter warnings

2016-10-14 Thread Eric Engestrom 
> Subject: [PATCH 4/4] i965: Silence unused parameter warnings

How about "remove unused parameters" instead?
Silencing the warnings is nothing more than a side effect of this
change, albeit the reason you realised it was needed.

(Sorry, I've seen so many "silence warning" commits at $DAYJOB that
this has become a pet peeve of mine)

One suggestion below, but the series looks good:
Reviewed-by: Eric Engestrom 


On Fri, Oct 14, 2016 at 11:59:47AM -0700, Ian Romanick wrote:
> From: Ian Romanick 
> 
> brw_link.cpp:76:44: warning: unused parameter ‘shader_type’ 
> [-Wunused-parameter]
> gl_shader_stage shader_type,
> ^
> brw_nir.c: In function ‘brw_nir_lower_vs_inputs’:
> brw_nir.c:194:55: warning: unused parameter ‘devinfo’ [-Wunused-parameter]
>  const struct gen_device_info *devinfo,
>^
> brw_vec4_visitor.cpp:914:37: warning: unused parameter ‘sampler’ 
> [-Wunused-parameter]
> uint32_t sampler,
>  ^
> brw_vec4_visitor.cpp:1146:34: warning: unused parameter ‘stream_id’ 
> [-Wunused-parameter]
>  vec4_visitor::gs_emit_vertex(int stream_id)
>   ^
> 
> Signed-off-by: Ian Romanick 
> ---
>  src/mesa/drivers/dri/i965/brw_link.cpp | 3 +--
>  src/mesa/drivers/dri/i965/brw_nir.c| 1 -
>  src/mesa/drivers/dri/i965/brw_nir.h| 1 -
>  src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
>  src/mesa/drivers/dri/i965/brw_vec4.h   | 2 +-
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 +-
>  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 3 +--
>  7 files changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
> b/src/mesa/drivers/dri/i965/brw_link.cpp
> index 02151d6..5ea9773 100644
> --- a/src/mesa/drivers/dri/i965/brw_link.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_link.cpp
> @@ -73,7 +73,6 @@ brw_shader_precompile(struct gl_context *ctx,
>  
>  static void
>  brw_lower_packing_builtins(struct brw_context *brw,
> -   gl_shader_stage shader_type,
> exec_list *ir)
>  {
> /* Gens < 7 don't have instructions to convert to or from half-precision,
> @@ -105,7 +104,7 @@ process_glsl_ir(struct brw_context *brw,
> /* lower_packing_builtins() inserts arithmetic instructions, so it
>  * must precede lower_instructions().
>  */
> -   brw_lower_packing_builtins(brw, shader->Stage, shader->ir);
> +   brw_lower_packing_builtins(brw, shader->ir);
> do_mat_op_to_vec(shader->ir);
>  
> unsigned instructions_to_lower = (DIV_TO_MUL_RCP |
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
> b/src/mesa/drivers/dri/i965/brw_nir.c
> index 744865b..a935f42 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.c
> +++ b/src/mesa/drivers/dri/i965/brw_nir.c
> @@ -191,7 +191,6 @@ remap_patch_urb_offsets(nir_block *block, nir_builder *b,
>  
>  void
>  brw_nir_lower_vs_inputs(nir_shader *nir,
> -const struct gen_device_info *devinfo,
>  bool is_scalar,
>  bool use_legacy_snorm_formula,
>  const uint8_t *vs_attrib_wa_flags)
> diff --git a/src/mesa/drivers/dri/i965/brw_nir.h 
> b/src/mesa/drivers/dri/i965/brw_nir.h
> index 425d6ce..aef5c53 100644
> --- a/src/mesa/drivers/dri/i965/brw_nir.h
> +++ b/src/mesa/drivers/dri/i965/brw_nir.h
> @@ -99,7 +99,6 @@ nir_shader *brw_preprocess_nir(const struct brw_compiler 
> *compiler,
>  bool brw_nir_lower_intrinsics(nir_shader *nir,
>struct brw_stage_prog_data *prog_data);
>  void brw_nir_lower_vs_inputs(nir_shader *nir,
> - const struct gen_device_info *devinfo,
>   bool is_scalar,
>   bool use_legacy_snorm_formula,
>   const uint8_t *vs_attrib_wa_flags);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 6aa9102..362f32b 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -2114,7 +2114,7 @@ brw_compile_vs(const struct brw_compiler *compiler, 
> void *log_data,
> nir_shader *shader = nir_shader_clone(mem_ctx, src_shader);
> shader = brw_nir_apply_sampler_key(shader, compiler->devinfo, &key->tex,
>is_scalar);
> -   brw_nir_lower_vs_inputs(shader, compiler->devinfo, is_scalar,
> +   brw_nir_lower_vs_inputs(shader, is_scalar,
> use_legacy_snorm_formula, 
> key->gl_attrib_wa_flags);
> brw_nir_lower_vue_outputs(shader, is_scalar);
> shader = brw_postprocess_nir(shader, compiler->devinfo, is_scalar);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
> b/src/mesa/drivers/dri/i965/brw_vec4

Re: [Mesa-dev] [PATCH] egl/surfaceless: use correct index when accesing the visual

2016-10-14 Thread Eric Engestrom 
On Fri, Oct 14, 2016 at 09:42:00PM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> i is used for the driver_configs, while j is for the visuals.
> 
> Fixes: 4b8a55809eb ("egl/surfaceless: tweak 
> surfaceless_add_configs_for_visuals()")
> Reported-by: Chad Versace 
> Cc: Chad Versace 
> Signed-off-by: Emil Velikov 

Reviewed-by: Eric Engestrom 

> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index 3fc1a68..f891d91 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -198,7 +198,7 @@ surfaceless_add_configs_for_visuals(_EGLDriver *drv, 
> _EGLDisplay *dpy)
>   struct dri2_egl_config *dri2_conf;
>  
>   dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[i],
> -   count + 1, EGL_PBUFFER_BIT, NULL, visuals[i].rgba_masks);
> +   count + 1, EGL_PBUFFER_BIT, NULL, visuals[j].rgba_masks);
>  
>   if (dri2_conf) {
>  count++;
> -- 
> 2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] glsl: Remove unused function import_prototypes

2016-10-14 Thread Timothy Arceri 


On 15 October 2016 10:11:17 am AEDT, Kenneth Graunke  
wrote:
>On Friday, October 14, 2016 11:59:46 AM PDT Ian Romanick wrote:
>> From: Ian Romanick 
>> 
>> Once upon a time, this was used to extract prototypes from the shader
>> containing GLSL built-in functions.  This was removed by f5692f45 in
>> November 2010 for Mesa 7.10.
>> 
>> Signed-off-by: Ian Romanick 
>> Cc: Kenneth Graunke 
>
>Dead for 6 years, and we only now noticed...derp. :)  I wish there were
>better compiler warnings for things like this...

LibreOffice uses this [1]. Note the todo to make it a gcc plugin but I don't 
think there has been any progress towards that.

[1] http://www.skynet.ie/~caolan/Packages/callcatcher.html

>
>Series is:
>Reviewed-by: Kenneth Graunke 
>
>
>
>
>
>
>___
>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] i965: Fix typo in nir_op_pack_double_2x32_split handling

2016-10-14 Thread Jason Ekstrand 
On Fri, Oct 14, 2016 at 10:23 AM, Ian Romanick  wrote:

> On 10/08/2016 09:33 AM, Eduardo Lima Mitev wrote:
> > On 10/08/2016 02:12 AM, Ian Romanick wrote:
> >> From: Ian Romanick 
> >>
> >> This was found partially by inspection and partially by hitting a
> >> problem while working on nir_op_pack_int64_2x32_split.  The code
> >> previously would 'continue' if (instr->src[i].src.is_ssa), but the code
> >> immediately following in the loop treats instr->src[i] as an SSA value.
> >>
> >> Signed-off-by: Ian Romanick 
> >> Cc: mesa-sta...@lists.freedesktop.org
> >> Cc: Iago Toral Quiroga 
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> index 4e68ffb..2cbcab1 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> >> @@ -1208,7 +1208,7 @@ fs_visitor::nir_emit_alu(const fs_builder &bld,
> nir_alu_instr *instr)
> >> * the unpack operation.
> >> */
> >>for (int i = 0; i < 2; i++) {
> >> - if (instr->src[i].src.is_ssa)
> >> + if (!instr->src[i].src.is_ssa)
> >>  continue;
> >>
> >
> > Good catch!
>
> But maybe not.  Re-running this through the CI shows about 1,000 test
> regressions due to assertion failures.  I looked at the rest of the
> loop, and I'm really not sure how this works:
>
>   for (int i = 0; i < 2; i++) {
>  if (instr->src[i].src.is_ssa)
> continue;
>

Yeah, this should be !


>
>  const nir_instr *parent_instr = instr->src[i].src.ssa->parent_
> instr;
>
> We skip this if the source is SSA, but then we use it as SSA.
>
>  if (parent_instr->type == nir_instr_type_alu)
>

and this should be !=

if it works at all...


> continue;
>
>  const nir_alu_instr *alu_parent = nir_instr_as_alu(parent_instr);
>
> We skip this if the parent is ALU, but then we use it as ALU.  The
> assertion failure occurs inside nir_instr_as_alu.
>
>  if (alu_parent->op == nir_op_unpack_double_2x32_split_x ||
>  alu_parent->op == nir_op_unpack_double_2x32_split_y)
> continue;
>
>  if (!alu_parent->src[0].src.is_ssa)
> continue;
>
>  op[i] = get_nir_src(alu_parent->src[0].src);
>  op[i] = offset(retype(op[i], BRW_REGISTER_TYPE_DF), bld,
> alu_parent->src[0].swizzle[channel]);
>  if (alu_parent->op == nir_op_unpack_double_2x32_split_y)
> op[i] = subscript(op[i], BRW_REGISTER_TYPE_UD, 1);
>  else
> op[i] = subscript(op[i], BRW_REGISTER_TYPE_UD, 0);
>   }
>
> Were you guys ever able to make this optimization trigger?  I suspect
> that the very first continue always occurs, so none of this actually
> happens.  Either way, it seems like this optimization should happen in
> nir_opt_algebraic instead.
>

I've never been a huge fan of this optimization.  My brain's too dead on a
Friday to think about all of the implications, but it's obviously not
working as-is.


> This has come up because I need to do something similar for int64.  All
> of the lowering passes for int64 will generate a lot of
> unpack(pack(...)) type sequences.  I'm doing the lowering in GLSL IR,
> so I've also done the algebraic optimization in GLSL IR.
>
> > Both patches are:
> >
> > Reviewed-by: Eduardo Lima Mitev 
> >
> >>   const nir_instr *parent_instr = instr->src[i].src.ssa->parent_
> instr;
> >>
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] state_tracker: Fix check for scissor enabled when < 0.

2016-10-14 Thread Eric Anholt 
DEQP's clear tests like to give us x + w < 0 or y + h < 0.  Since we
were comparing to an unsigned, it would get promoted to unsigned and come
out as bignum >= width or height and we would clear the whole fb instead
of none of the fb.

Fixes 10 tests under deqp-gles2/functional/color_clear.
---
 src/mesa/state_tracker/st_cb_clear.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_clear.c 
b/src/mesa/state_tracker/st_cb_clear.c
index 813ba9b10ffa..158efc186c05 100644
--- a/src/mesa/state_tracker/st_cb_clear.c
+++ b/src/mesa/state_tracker/st_cb_clear.c
@@ -318,8 +318,8 @@ is_scissor_enabled(struct gl_context *ctx, struct 
gl_renderbuffer *rb)
return (ctx->Scissor.EnableFlags & 1) &&
   (scissor->X > 0 ||
scissor->Y > 0 ||
-   scissor->X + scissor->Width < rb->Width ||
-   scissor->Y + scissor->Height < rb->Height);
+   scissor->X + scissor->Width < (int)rb->Width ||
+   scissor->Y + scissor->Height < (int)rb->Height);
 }
 
 /**
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH] egl/surfaceless: Fix comparison between pointer and integer

2016-10-14 Thread Emil Velikov 
On Friday, 14 October 2016, Chad Versace  wrote:

> Fixes GCC warning:
>   drivers/dri2/platform_surfaceless.c:196:18: warning: comparison
>   between pointer and integer
>
> Fixes: 4b8a55809eb ("egl/surfaceless: tweak surfaceless_add_configs_for_
> visuals()")
> Cc: Emil Velikov >

Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH 3/4] glsl: Remove unused function import_prototypes

2016-10-14 Thread Kenneth Graunke 
On Friday, October 14, 2016 11:59:46 AM PDT Ian Romanick wrote:
> From: Ian Romanick 
> 
> Once upon a time, this was used to extract prototypes from the shader
> containing GLSL built-in functions.  This was removed by f5692f45 in
> November 2010 for Mesa 7.10.
> 
> Signed-off-by: Ian Romanick 
> Cc: Kenneth Graunke 

Dead for 6 years, and we only now noticed...derp. :)  I wish there were
better compiler warnings for things like this...

Series is:
Reviewed-by: Kenneth Graunke 




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

[Mesa-dev] [PATCH] egl/surfaceless: Fix comparison between pointer and integer

2016-10-14 Thread Chad Versace 
Fixes GCC warning:
  drivers/dri2/platform_surfaceless.c:196:18: warning: comparison
  between pointer and integer

Fixes: 4b8a55809eb ("egl/surfaceless: tweak 
surfaceless_add_configs_for_visuals()")
Cc: Emil Velikov 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index f891d91..fcf7d69 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -193,7 +193,7 @@ surfaceless_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *dpy)
unsigned int count, i, j;
 
count = 0;
-   for (i = 0; i < dri2_dpy->driver_configs[i]; i++) {
+   for (i = 0; dri2_dpy->driver_configs[i] != NULL; i++) {
   for (j = 0; j < ARRAY_SIZE(visuals); j++) {
  struct dri2_egl_config *dri2_conf;
 
-- 
2.10.0

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

Re: [Mesa-dev] [PATCH] egl/surfaceless: use correct index when accesing the visual

2016-10-14 Thread Chad Versace 
On Fri 14 Oct 2016, Emil Velikov wrote:
> From: Emil Velikov 
> 
> i is used for the driver_configs, while j is for the visuals.
> 
> Fixes: 4b8a55809eb ("egl/surfaceless: tweak 
> surfaceless_add_configs_for_visuals()")
> Reported-by: Chad Versace 
> Cc: Chad Versace 
> Signed-off-by: Emil Velikov 

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

[Mesa-dev] [PATCH] egl/surfaceless: use correct index when accesing the visual

2016-10-14 Thread Emil Velikov 
From: Emil Velikov 

i is used for the driver_configs, while j is for the visuals.

Fixes: 4b8a55809eb ("egl/surfaceless: tweak 
surfaceless_add_configs_for_visuals()")
Reported-by: Chad Versace 
Cc: Chad Versace 
Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index 3fc1a68..f891d91 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -198,7 +198,7 @@ surfaceless_add_configs_for_visuals(_EGLDriver *drv, 
_EGLDisplay *dpy)
  struct dri2_egl_config *dri2_conf;
 
  dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[i],
-   count + 1, EGL_PBUFFER_BIT, NULL, visuals[i].rgba_masks);
+   count + 1, EGL_PBUFFER_BIT, NULL, visuals[j].rgba_masks);
 
  if (dri2_conf) {
 count++;
-- 
2.9.3

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

Re: [Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

2016-10-14 Thread Emil Velikov 
On 14 October 2016 at 20:21, Axel Davy  wrote:
> On 14/10/2016 20:21, Emil Velikov wrote:
>>
>> From: Emil Velikov 
>>
>> Currently not everyone has libudev and with follow-up patches we'll
>> completely remove the divergent codepaths.
>>
>> Use the libdrm drm device API to construct the required ID_PATH_TAG-like
>> string, to preserve the current functionality for libudev users and
>> allow others to benefit from it as well.
>>
>> v2: Drop ranty comments, pick the correct device
>>
>> Cc: Axel Davy 
>> Signed-off-by: Emil Velikov 
>> ---
>>   src/loader/loader.c | 247
>> ++--
>>   1 file changed, 106 insertions(+), 141 deletions(-)
>>
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index ad4f946..06df05b 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>> @@ -69,16 +69,11 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #ifdef HAVE_LIBUDEV
>>   #include 
>>   #include 
>> -#include 
>> -#include 
>> -#ifdef USE_DRICONF
>> -#include "xmlconfig.h"
>> -#include "xmlpool.h"
>> -#endif
>>   #endif
>>   #ifdef MAJOR_IN_MKDEV
>>   #include 
>> @@ -89,7 +84,13 @@
>>   #include "loader.h"
>> #ifdef HAVE_LIBDRM
>> +#include 
>> +#include 
>>   #include 
>> +#ifdef USE_DRICONF
>> +#include "xmlconfig.h"
>> +#include "xmlpool.h"
>> +#endif
>>   #endif
>> #define __IS_LOADER
>> @@ -203,99 +204,9 @@ udev_device_new_from_fd(struct udev *udev, int fd)
>>return device;
>>   }
>> +#endif
>>   -static char *
>> -get_render_node_from_id_path_tag(struct udev *udev,
>> - char *id_path_tag,
>> - char another_tag)
>> -{
>> -   struct udev_device *device;
>> -   struct udev_enumerate *e;
>> -   struct udev_list_entry *entry;
>> -   const char *path, *id_path_tag_tmp;
>> -   char *path_res;
>> -   char found = 0;
>> -   UDEV_SYMBOL(struct udev_enumerate *, udev_enumerate_new,
>> -   (struct udev *));
>> -   UDEV_SYMBOL(int, udev_enumerate_add_match_subsystem,
>> -   (struct udev_enumerate *, const char *));
>> -   UDEV_SYMBOL(int, udev_enumerate_add_match_sysname,
>> -   (struct udev_enumerate *, const char *));
>> -   UDEV_SYMBOL(int, udev_enumerate_scan_devices,
>> -   (struct udev_enumerate *));
>> -   UDEV_SYMBOL(struct udev_list_entry *, udev_enumerate_get_list_entry,
>> -   (struct udev_enumerate *));
>> -   UDEV_SYMBOL(void, udev_enumerate_unref,
>> -   (struct udev_enumerate *));
>> -   UDEV_SYMBOL(struct udev_list_entry *, udev_list_entry_get_next,
>> -   (struct udev_list_entry *));
>> -   UDEV_SYMBOL(const char *, udev_list_entry_get_name,
>> -   (struct udev_list_entry *));
>> -   UDEV_SYMBOL(struct udev_device *, udev_device_new_from_syspath,
>> -   (struct udev *, const char *));
>> -   UDEV_SYMBOL(const char *, udev_device_get_property_value,
>> -   (struct udev_device *, const char *));
>> -   UDEV_SYMBOL(const char *, udev_device_get_devnode,
>> -   (struct udev_device *));
>> -   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
>> -   (struct udev_device *));
>> -
>> -   e = udev_enumerate_new(udev);
>> -   udev_enumerate_add_match_subsystem(e, "drm");
>> -   udev_enumerate_add_match_sysname(e, "render*");
>> -
>> -   udev_enumerate_scan_devices(e);
>> -   udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) {
>> -  path = udev_list_entry_get_name(entry);
>> -  device = udev_device_new_from_syspath(udev, path);
>> -  if (!device)
>> - continue;
>> -  id_path_tag_tmp = udev_device_get_property_value(device,
>> "ID_PATH_TAG");
>> -  if (id_path_tag_tmp) {
>> - if ((!another_tag && !strcmp(id_path_tag, id_path_tag_tmp)) ||
>> - (another_tag && strcmp(id_path_tag, id_path_tag_tmp))) {
>> -found = 1;
>> -break;
>> - }
>> -  }
>> -  udev_device_unref(device);
>> -   }
>> -
>> -   udev_enumerate_unref(e);
>> -
>> -   if (found) {
>> -  path_res = strdup(udev_device_get_devnode(device));
>> -  udev_device_unref(device);
>> -  return path_res;
>> -   }
>> -   return NULL;
>> -}
>> -
>> -static char *
>> -get_id_path_tag_from_fd(struct udev *udev, int fd)
>> -{
>> -   struct udev_device *device;
>> -   const char *id_path_tag_tmp;
>> -   char *id_path_tag;
>> -   UDEV_SYMBOL(const char *, udev_device_get_property_value,
>> -   (struct udev_device *, const char *));
>> -   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
>> -   (struct udev_device *));
>> -
>> -   device = udev_device_new_from_fd(udev, fd);
>> -   if (!device)
>> -  return NULL;
>> -
>> -   id_path_tag_tmp = udev_device_get_property_value(device,
>> "ID_PATH_TAG");
>> -   if (!id_path_tag_tmp)
>> -  return NULL;
>> -
>> -   id_path_tag = strdup(id_path_tag_tmp);
>> -
>> -   udev_d

Re: [Mesa-dev] [PATCH] gallivm: print out time for jitting functions with GALLIVM_DEBUG=perf

2016-10-14 Thread Roland Scheidegger 
Am 14.10.2016 um 18:05 schrieb Jose Fonseca:
> On 14/10/16 15:36, Brian Paul wrote:
>> On 10/13/2016 09:38 PM, srol...@vmware.com wrote:
>>> From: Roland Scheidegger 
>>>
>>> Compilation to actual machine code can easily take as much time as the
>>> optimization passes on the IR if not more, so print this out too.
>>> ---
>>>   src/gallium/auxiliary/gallivm/lp_bld_init.c | 11 +++
>>>   1 file changed, 11 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
>>> b/src/gallium/auxiliary/gallivm/lp_bld_init.c
>>> index 7114cde..d1b2369 100644
>>> --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
>>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
>>> @@ -659,13 +659,24 @@ gallivm_jit_function(struct gallivm_state
>>> *gallivm,
>>>   {
>>>  void *code;
>>>  func_pointer jit_func;
>>> +   int64_t time_begin = 0;
>>
>> I think we might want to put MAYBE_UNUSED on that decl so there's not an
>> unused var warning in a non-debug build.
> 
> I think it might be OK because Roland's using `if` isntead of `#if`.
> That said, some compilers are too smart for their own good.
I think it would be really surprising if compilers would warn about that
indeed. That it can be optimized out might be obvious here, nevertheless
the variable is used as far as the c code is concerned (you also get
compile errors if the syntax is wrong somewhere in a "if (0)" clause).
At least I've never seen a warning, though I'm usually not using
bleeding edge compilers... (the code here is a near exact copy of the
one in gallivm_compile_module() in any case).

Roland

> 
>>
>>>
>>>  assert(gallivm->compiled);
>>>  assert(gallivm->engine);
>>>
>>> +   if (gallivm_debug & GALLIVM_DEBUG_PERF)
>>> +  time_begin = os_time_get();
>>> +
>>>  code = LLVMGetPointerToGlobal(gallivm->engine, func);
>>>  assert(code);
>>>  jit_func = pointer_to_func(code);
>>>
>>> +   if (gallivm_debug & GALLIVM_DEBUG_PERF) {
>>> +  int64_t time_end = os_time_get();
>>> +  int time_msec = (int)(time_end - time_begin) / 1000;
>>> +  debug_printf("   jitting func %s took %d msec\n",
>>> +   LLVMGetValueName(func), time_msec);
>>> +   }
>>> +
>>>  return jit_func;
>>>   }
>>>
>>
>> Looks OK otherwise.
>>
>> Reviewed-by: Brian Paul 
> 
> Reviewed-by: Jose Fonseca 
> 
> Jose
> 

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

Re: [Mesa-dev] [PATCH 17/22] anv: Use blorp for ClearAttachments

2016-10-14 Thread Jason Ekstrand 
On Wed, Oct 12, 2016 at 2:26 AM, Pohjolainen, Topi <
topi.pohjolai...@gmail.com> wrote:

> On Fri, Oct 07, 2016 at 09:41:15PM -0700, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand 
> > ---
> >  src/intel/vulkan/anv_blorp.c  | 113 ++
> 
> >  src/intel/vulkan/anv_meta_clear.c |  24 
> >  2 files changed, 113 insertions(+), 24 deletions(-)
> >
> > diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
> > index 546737b..4279f62 100644
> > --- a/src/intel/vulkan/anv_blorp.c
> > +++ b/src/intel/vulkan/anv_blorp.c
> > @@ -870,6 +870,119 @@ void anv_CmdClearDepthStencilImage(
> >  }
> >
> >  static void
> > +clear_color_attachment(struct anv_cmd_buffer *cmd_buffer,
> > +   struct blorp_batch *batch,
> > +   const VkClearAttachment *attachment,
> > +   uint32_t rectCount, const VkClearRect *pRects)
> > +{
> > +   const struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > +   const struct anv_subpass *subpass = cmd_buffer->state.subpass;
> > +   const uint32_t att = attachment->colorAttachment;
> > +   const struct anv_image_view *iview =
> > +  fb->attachments[subpass->color_attachments[att]];
> > +   const struct anv_image *image = iview->image;
> > +
> > +   struct blorp_surf surf;
> > +   get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_COLOR_BIT,
> &surf);
> > +
> > +   union isl_color_value clear_color;
> > +   memcpy(clear_color.u32, attachment->clearValue.color.uint32,
> > +  sizeof(clear_color.u32));
> > +
> > +   static const bool color_write_disable[4] = { false, false, false,
> false };
> > +
> > +   for (uint32_t r = 0; r < rectCount; ++r) {
> > +  const VkOffset2D offset = pRects[r].rect.offset;
> > +  const VkExtent2D extent = pRects[r].rect.extent;
> > +  blorp_clear(batch, &surf, iview->isl.format, iview->isl.swizzle,
> > +  iview->isl.base_level,
> > +  iview->isl.base_array_layer +
> pRects[r].baseArrayLayer,
>
> I'm not that familiar with vulkan yet and looking emit_color_clear() does
> not
> directly tell me if "pRects[r].baseArrayLayer" is relative to the view base
> layer. If that is the case then this patch looks good to me:
>

It is.  Took me by surprise too.


> Reviewed-by: Topi Pohjolainen 
>

Thanks!


>
> > +  pRects[r].layerCount,
> > +  offset.x, offset.y,
> > +  offset.x + extent.width, offset.y + extent.height,
> > +  clear_color, color_write_disable);
> > +   }
> > +}
> > +
> > +static void
> > +clear_depth_stencil_attachment(struct anv_cmd_buffer *cmd_buffer,
> > +   struct blorp_batch *batch,
> > +   const VkClearAttachment *attachment,
> > +   uint32_t rectCount, const VkClearRect
> *pRects)
> > +{
> > +   const struct anv_framebuffer *fb = cmd_buffer->state.framebuffer;
> > +   const struct anv_subpass *subpass = cmd_buffer->state.subpass;
> > +   const struct anv_image_view *iview =
> > +  fb->attachments[subpass->depth_stencil_attachment];
> > +   const struct anv_image *image = iview->image;
> > +
> > +   bool clear_depth = attachment->aspectMask &
> VK_IMAGE_ASPECT_DEPTH_BIT;
> > +   bool clear_stencil = attachment->aspectMask &
> VK_IMAGE_ASPECT_STENCIL_BIT;
>
> These two could be const.
>
> > +
> > +   struct blorp_surf depth, stencil;
> > +   if (clear_depth) {
> > +  get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_DEPTH_BIT,
> > +   &depth);
> > +   } else {
> > +  memset(&depth, 0, sizeof(depth));
> > +   }
> > +
> > +   if (clear_stencil) {
> > +  get_blorp_surf_for_anv_image(image, VK_IMAGE_ASPECT_STENCIL_BIT,
> > +   &stencil);
> > +   } else {
> > +  memset(&stencil, 0, sizeof(stencil));
> > +   }
> > +
> > +   for (uint32_t r = 0; r < rectCount; ++r) {
> > +  const VkOffset2D offset = pRects[r].rect.offset;
> > +  const VkExtent2D extent = pRects[r].rect.extent;
> > +  VkClearDepthStencilValue value = attachment->clearValue.
> depthStencil;
> > +  blorp_clear_depth_stencil(batch, &depth, &stencil,
> > +iview->isl.base_level,
> > +iview->isl.base_array_layer +
> > +   pRects[r].baseArrayLayer,
> > +pRects[r].layerCount,
> > +offset.x, offset.y,
> > +offset.x + extent.width,
> > +offset.y + extent.height,
> > +clear_depth, value.depth,
> > +clear_stencil, value.stencil);
> > +   }
> > +}
> > +
> > +void anv_CmdClearAttachments(
> > +VkCommandBuffer commandBuffer,
> > +uint32_t

Re: [Mesa-dev] [PATCH 16/22] anv/hiz: Perform HiZ resolves for all partial renders

2016-10-14 Thread Jason Ekstrand 
On Wed, Oct 12, 2016 at 9:01 AM, Nanley Chery  wrote:

> On Tue, Oct 11, 2016 at 06:55:53PM -0700, Jason Ekstrand wrote:
> > On Tue, Oct 11, 2016 at 6:16 PM, Nanley Chery 
> wrote:
> >
> > > On Mon, Oct 10, 2016 at 06:00:49PM -0700, Jason Ekstrand wrote:
> > > > On Mon, Oct 10, 2016 at 2:23 PM, Nanley Chery  >
> > > wrote:
> > > >
> > > > > On Fri, Oct 07, 2016 at 09:41:14PM -0700, Jason Ekstrand wrote:
> > > > > > If we don't, we can end up with corruption in the portion of the
> > > depth
> > > > > > buffer that lies outside the render area when we do a HiZ
> resolve at
> > > the
> > > > > > end.  The only reason we weren't seeing this before was that all
> of
> > > the
> > > > > > meta-based clears such as VkCmdClearDepthStencilImage were
> internally
> > > > > using
> > > > > > HiZ so the HiZ buffer never truly got out-of-sync.  If the CTS
> ever
> > > > > tested
> > > > > > a depth upload (which doesn't care about HiZ) and then a partial
> > > render
> > > > > we
> > > > > > would have seen problems.  Soon, we will be using blorp to do
> depth
> > > > > clears
> > > > > > and it won't bother with HiZ so we would get CTS regressions
> without
> > > > > this.
> > > > > >
> > > > >
> > > > > I understand the problem, but I think this solution unnecessarily
> > > > > penalizes the user's renderpass.
> > > > >
> > > > > Since depth buffer updates via vkCopy*ToImage and
> > > > > vkCmdClearDepthStencilImage cause the HiZ buffer to become stale,
> > > > > calling
> > > > >
> > > > > genX(cmd_buffer_emit_hz_op)(cmd_buffer, BLORP_HIZ_OP_HIZ_RESOLVE);
> > > > >
> > > > > at the bottom of those commands should fix the issue without the
> extra
> > > > > penalty. I'd imagine that as a prequisite, blorp would have to
> learn to
> > > > > emit enough depth stencil state for this command.
> > > > >
> > > >
> > > > I think that's dangerously mixing HiZ data validity models.  There
> are 3
> > > > basic aux data validity models that we've thrown around:
> > > >
> > > >  1) AUX is always correct.
> > > >  2) AUX is correct within a render pass and invalid outside.
> > > >  3) Track whether or not AUX is valid and resolve only as needed.
> > > >
> > >
> > > What is the definition of correct here? I'd assume you mean that the
> > > data matches what's in the depth buffer, but that sometimes may not be
> > > the case (STORE_OP_DONTCARE) yet the program behavior is correct
> > > nonetheless.
> > >
> >
> > By "correct" I mean "consistent with the depth buffer" or, more
> precicely,
> > "all well-defined pixels of the depth buffer are consistent with the HiZ
> > buffer".  We *may* be able to avoid the depth resolve at the end if you
> > have STORE_OP_DONT_CARE.  However, we would probably not do anything
> > interesting with LOAD_OP_DONT_CARE.
> >
>
>
> With this definition of correct (accessing either buffer will give you
> the correct value due to their being consistent with each other), the
> current implementation is arguably a course-grained version of (3) (no
> tracking, let's call this 4) than it is (2). The HiZ buffer is only
> consistent with the depth buffer when a user performs an operation that
> likely requires it to be so. For example:
>
> * LOAD_OP_LOAD -> HiZ Resolve (consistent)
> * LOAD_OP_CLEAR -> No resolve, Fast Depth Clear (inconsistent)
> * vkCmdDraw* -> No resolve (inconsistent)
> * STORE_OP_STORE -> Depth Resolve (consistent)
>
> >
> > > Also, could you please explain where the danger comes into play?
> > >
> >
> > We need to have a solid mental model of when HiZ and depth are
> consistent.
> > Otherwise, we'll make mistakes, things will get inconsistent, and we'll
>
> Agreed.
>
> > have weird bugs.  This bug is a good example of this.  Our mental model
> (2)
> > works fine except that we were leaking garbage depth from DONT_CARE when
> we
> > have a partial areat.  Just doing a HiZ resolve after a blorp clear
> "fixes"
> > the bug by making things always consistent (mental model 1).  But then it
>
> As mentioned above, I'm not advocating mixing 1 and 2, but covering a
> missed case in 4. Whether or not that mental model is solid seems like
> a subjective claim.
>
> > means that we have LOAD_OP_LOAD, we're doing two HiZ resolves which we
> > don't want either.
> >
>
> I wouldn't expect Vulkan apps to submit image copies as frequently as
> render passes, so my thinking is that an extra HiZ resolve at the end of
> an Image copy should have less of an impact on FPS than performing the
> resolve on every clearing RP that doesn't use a full render area. I
> did not write the patch to test my suggestion, but I was able to get a
> measurable difference by forcing HiZ resolves on the triangle demo. I
> won't post the numbers I obtained from the questionable method of
> eye-balling the FPS counter (especially with the amount of variance
> involved), so feel free to take a look at it yourself.
>

I wouldn't expect copies to happen particularly frequently either and I
certainly don't think we should optimize fo

Re: [Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

2016-10-14 Thread Axel Davy 

On 14/10/2016 20:21, Emil Velikov wrote:

From: Emil Velikov 

Currently not everyone has libudev and with follow-up patches we'll
completely remove the divergent codepaths.

Use the libdrm drm device API to construct the required ID_PATH_TAG-like
string, to preserve the current functionality for libudev users and
allow others to benefit from it as well.

v2: Drop ranty comments, pick the correct device

Cc: Axel Davy 
Signed-off-by: Emil Velikov 
---
  src/loader/loader.c | 247 ++--
  1 file changed, 106 insertions(+), 141 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index ad4f946..06df05b 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -69,16 +69,11 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #ifdef HAVE_LIBUDEV
  #include 
  #include 
-#include 
-#include 
-#ifdef USE_DRICONF
-#include "xmlconfig.h"
-#include "xmlpool.h"
-#endif
  #endif
  #ifdef MAJOR_IN_MKDEV
  #include 
@@ -89,7 +84,13 @@
  #include "loader.h"
  
  #ifdef HAVE_LIBDRM

+#include 
+#include 
  #include 
+#ifdef USE_DRICONF
+#include "xmlconfig.h"
+#include "xmlpool.h"
+#endif
  #endif
  
  #define __IS_LOADER

@@ -203,99 +204,9 @@ udev_device_new_from_fd(struct udev *udev, int fd)
  
 return device;

  }
+#endif
  
-static char *

-get_render_node_from_id_path_tag(struct udev *udev,
- char *id_path_tag,
- char another_tag)
-{
-   struct udev_device *device;
-   struct udev_enumerate *e;
-   struct udev_list_entry *entry;
-   const char *path, *id_path_tag_tmp;
-   char *path_res;
-   char found = 0;
-   UDEV_SYMBOL(struct udev_enumerate *, udev_enumerate_new,
-   (struct udev *));
-   UDEV_SYMBOL(int, udev_enumerate_add_match_subsystem,
-   (struct udev_enumerate *, const char *));
-   UDEV_SYMBOL(int, udev_enumerate_add_match_sysname,
-   (struct udev_enumerate *, const char *));
-   UDEV_SYMBOL(int, udev_enumerate_scan_devices,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(struct udev_list_entry *, udev_enumerate_get_list_entry,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(void, udev_enumerate_unref,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(struct udev_list_entry *, udev_list_entry_get_next,
-   (struct udev_list_entry *));
-   UDEV_SYMBOL(const char *, udev_list_entry_get_name,
-   (struct udev_list_entry *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_new_from_syspath,
-   (struct udev *, const char *));
-   UDEV_SYMBOL(const char *, udev_device_get_property_value,
-   (struct udev_device *, const char *));
-   UDEV_SYMBOL(const char *, udev_device_get_devnode,
-   (struct udev_device *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
-   (struct udev_device *));
-
-   e = udev_enumerate_new(udev);
-   udev_enumerate_add_match_subsystem(e, "drm");
-   udev_enumerate_add_match_sysname(e, "render*");
-
-   udev_enumerate_scan_devices(e);
-   udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) {
-  path = udev_list_entry_get_name(entry);
-  device = udev_device_new_from_syspath(udev, path);
-  if (!device)
- continue;
-  id_path_tag_tmp = udev_device_get_property_value(device, "ID_PATH_TAG");
-  if (id_path_tag_tmp) {
- if ((!another_tag && !strcmp(id_path_tag, id_path_tag_tmp)) ||
- (another_tag && strcmp(id_path_tag, id_path_tag_tmp))) {
-found = 1;
-break;
- }
-  }
-  udev_device_unref(device);
-   }
-
-   udev_enumerate_unref(e);
-
-   if (found) {
-  path_res = strdup(udev_device_get_devnode(device));
-  udev_device_unref(device);
-  return path_res;
-   }
-   return NULL;
-}
-
-static char *
-get_id_path_tag_from_fd(struct udev *udev, int fd)
-{
-   struct udev_device *device;
-   const char *id_path_tag_tmp;
-   char *id_path_tag;
-   UDEV_SYMBOL(const char *, udev_device_get_property_value,
-   (struct udev_device *, const char *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
-   (struct udev_device *));
-
-   device = udev_device_new_from_fd(udev, fd);
-   if (!device)
-  return NULL;
-
-   id_path_tag_tmp = udev_device_get_property_value(device, "ID_PATH_TAG");
-   if (!id_path_tag_tmp)
-  return NULL;
-
-   id_path_tag = strdup(id_path_tag_tmp);
-
-   udev_device_unref(device);
-   return id_path_tag;
-}
-
+#if defined(HAVE_LIBDRM)
  #ifdef USE_DRICONF
  static const char __driConfigOptionsLoader[] =
  DRI_CONF_BEGIN
@@ -321,17 +232,60 @@ static char *loader_get_dri_config_device_id(void)
  }
  #endif
  
+static char *drm_construct_id_path_tag(drmDevicePtr device)

+{
+/* Length of "pci-_xx_xx_x\n" */

I assume you want to say:

"pci-_xx_xx_x" + terminal byte

Thus it should be

"pci-_xx_xx_x\0"


+#define PCI_ID_P

Re: [Mesa-dev] [PATCH] vulkan: Initial partial documentation for Vulkan internals.

2016-10-14 Thread Rhys Kidd 
On 14 October 2016 at 10:36,  wrote:

> From: Kevin Rogovin 
>
> A main page ala Doxygen together with a Doxygen file added.
> In addition, documentation for portions of anv_private.h:
>  - placing portions into doxygen groups
>  - some cross linking doxygen style to other files
>

Hello Kevin,

Thanks for the initial steps to document anv.

Can I make two suggestions:
1. Split out into two patches: (a) adding of inline comments to .c/.h
files; and (b) the doxygen plumbing.
2. In relation to the doxygen plumbing you can leverage the existing
($top_dir)/doxygen/ to reduce your patch size.

Suggest that you look at how i965.doxy and common.doxy interact.


>
> Signed-off-by: Kevin Rogovin 
> ---
>  src/intel/genxml/gen_macros.h   |4 +-
>  src/intel/vulkan/anv_allocator.c|5 +-
>  src/intel/vulkan/anv_private.h  |  287 +++-
>  src/intel/vulkan/docs/.gitignore|1 +
>  src/intel/vulkan/docs/Doxyfile  | 2483
> +++
>  src/intel/vulkan/docs/intel_vulkan.doxy |   86 ++
>  6 files changed, 2845 insertions(+), 21 deletions(-)
>  create mode 100644 src/intel/vulkan/docs/.gitignore
>  create mode 100644 src/intel/vulkan/docs/Doxyfile
>  create mode 100644 src/intel/vulkan/docs/intel_vulkan.doxy
>




>
> ___
> 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 1/4] glsl: Replace assert with unreachable

2016-10-14 Thread Ian Romanick 
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/glsl/ir_print_visitor.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/glsl/ir_print_visitor.cpp 
b/src/compiler/glsl/ir_print_visitor.cpp
index c238c16..1299bfb 100644
--- a/src/compiler/glsl/ir_print_visitor.cpp
+++ b/src/compiler/glsl/ir_print_visitor.cpp
@@ -474,7 +474,8 @@ void ir_print_visitor::visit(ir_constant *ir)
 else
fprintf(f, "%f", ir->value.d[i]);
 break;
-default: assert(0);
+default:
+unreachable("Invalid constant type");
 }
   }
}
-- 
2.5.5

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

[Mesa-dev] [PATCH 3/4] glsl: Remove unused function import_prototypes

2016-10-14 Thread Ian Romanick 
From: Ian Romanick 

Once upon a time, this was used to extract prototypes from the shader
containing GLSL built-in functions.  This was removed by f5692f45 in
November 2010 for Mesa 7.10.

Signed-off-by: Ian Romanick 
Cc: Kenneth Graunke 
---
 src/compiler/Makefile.sources  |   1 -
 src/compiler/glsl/ir.h |   6 --
 src/compiler/glsl/ir_import_prototypes.cpp | 125 -
 3 files changed, 132 deletions(-)
 delete mode 100644 src/compiler/glsl/ir_import_prototypes.cpp

diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
index 712b33a..a30443d 100644
--- a/src/compiler/Makefile.sources
+++ b/src/compiler/Makefile.sources
@@ -46,7 +46,6 @@ LIBGLSL_FILES = \
glsl/ir_hierarchical_visitor.cpp \
glsl/ir_hierarchical_visitor.h \
glsl/ir_hv_accept.cpp \
-   glsl/ir_import_prototypes.cpp \
glsl/ir_optimization.h \
glsl/ir_print_visitor.cpp \
glsl/ir_print_visitor.h \
diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index 7e06d42..3d28dd5 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -2378,12 +2378,6 @@ _mesa_glsl_release_builtin_functions(void);
 extern void
 reparent_ir(exec_list *list, void *mem_ctx);
 
-struct glsl_symbol_table;
-
-extern void
-import_prototypes(const exec_list *source, exec_list *dest,
- struct glsl_symbol_table *symbols, void *mem_ctx);
-
 extern void
 do_set_program_inouts(exec_list *instructions, struct gl_program *prog,
   gl_shader_stage shader_stage);
diff --git a/src/compiler/glsl/ir_import_prototypes.cpp 
b/src/compiler/glsl/ir_import_prototypes.cpp
deleted file mode 100644
index b0429fb..000
--- a/src/compiler/glsl/ir_import_prototypes.cpp
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * Copyright © 2010 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- */
-
-/**
- * \file ir_import_prototypes.cpp
- * Import function prototypes from one IR tree into another.
- *
- * \author Ian Romanick
- */
-#include "ir.h"
-#include "glsl_symbol_table.h"
-
-namespace {
-
-/**
- * Visitor used to import function prototypes
- *
- * Normally the \c clone method of either \c ir_function or
- * \c ir_function_signature could be used.  However, we don't want a complete
- * clone of the \c ir_function_signature.  We want everything \b except the
- * body of the function.
- */
-class import_prototype_visitor : public ir_hierarchical_visitor {
-public:
-   /**
-*/
-   import_prototype_visitor(exec_list *list, glsl_symbol_table *symbols,
-   void *mem_ctx)
-   {
-  this->mem_ctx = mem_ctx;
-  this->list = list;
-  this->symbols = symbols;
-  this->function = NULL;
-   }
-
-   virtual ir_visitor_status visit_enter(ir_function *ir)
-   {
-  assert(this->function == NULL);
-
-  this->function = this->symbols->get_function(ir->name);
-  if (!this->function) {
-this->function = new(this->mem_ctx) ir_function(ir->name);
-
-list->push_tail(this->function);
-
-/* Add the new function to the symbol table.
- */
-this->symbols->add_function(this->function);
-  }
-  return visit_continue;
-   }
-
-   virtual ir_visitor_status visit_leave(ir_function *ir)
-   {
-  (void) ir;
-  assert(this->function != NULL);
-
-  this->function = NULL;
-  return visit_continue;
-   }
-
-   ir_visitor_status visit_enter(ir_function_signature *ir)
-   {
-  assert(this->function != NULL);
-
-  ir_function_signature *copy = ir->clone_prototype(mem_ctx, NULL);
-
-  this->function->add_signature(copy);
-
-  /* Do not process child nodes of the ir_function_signature.  There can
-   * never be any nodes inside the ir_function_signature that we care
-   * about.  Instead continue with the next sibling.
-   */
-  return visit_conti

[Mesa-dev] [PATCH 4/4] i965: Silence unused parameter warnings

2016-10-14 Thread Ian Romanick 
From: Ian Romanick 

brw_link.cpp:76:44: warning: unused parameter ‘shader_type’ [-Wunused-parameter]
gl_shader_stage shader_type,
^
brw_nir.c: In function ‘brw_nir_lower_vs_inputs’:
brw_nir.c:194:55: warning: unused parameter ‘devinfo’ [-Wunused-parameter]
 const struct gen_device_info *devinfo,
   ^
brw_vec4_visitor.cpp:914:37: warning: unused parameter ‘sampler’ 
[-Wunused-parameter]
uint32_t sampler,
 ^
brw_vec4_visitor.cpp:1146:34: warning: unused parameter ‘stream_id’ 
[-Wunused-parameter]
 vec4_visitor::gs_emit_vertex(int stream_id)
  ^

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_link.cpp | 3 +--
 src/mesa/drivers/dri/i965/brw_nir.c| 1 -
 src/mesa/drivers/dri/i965/brw_nir.h| 1 -
 src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4.h   | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 2 +-
 src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 3 +--
 7 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp 
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 02151d6..5ea9773 100644
--- a/src/mesa/drivers/dri/i965/brw_link.cpp
+++ b/src/mesa/drivers/dri/i965/brw_link.cpp
@@ -73,7 +73,6 @@ brw_shader_precompile(struct gl_context *ctx,
 
 static void
 brw_lower_packing_builtins(struct brw_context *brw,
-   gl_shader_stage shader_type,
exec_list *ir)
 {
/* Gens < 7 don't have instructions to convert to or from half-precision,
@@ -105,7 +104,7 @@ process_glsl_ir(struct brw_context *brw,
/* lower_packing_builtins() inserts arithmetic instructions, so it
 * must precede lower_instructions().
 */
-   brw_lower_packing_builtins(brw, shader->Stage, shader->ir);
+   brw_lower_packing_builtins(brw, shader->ir);
do_mat_op_to_vec(shader->ir);
 
unsigned instructions_to_lower = (DIV_TO_MUL_RCP |
diff --git a/src/mesa/drivers/dri/i965/brw_nir.c 
b/src/mesa/drivers/dri/i965/brw_nir.c
index 744865b..a935f42 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.c
+++ b/src/mesa/drivers/dri/i965/brw_nir.c
@@ -191,7 +191,6 @@ remap_patch_urb_offsets(nir_block *block, nir_builder *b,
 
 void
 brw_nir_lower_vs_inputs(nir_shader *nir,
-const struct gen_device_info *devinfo,
 bool is_scalar,
 bool use_legacy_snorm_formula,
 const uint8_t *vs_attrib_wa_flags)
diff --git a/src/mesa/drivers/dri/i965/brw_nir.h 
b/src/mesa/drivers/dri/i965/brw_nir.h
index 425d6ce..aef5c53 100644
--- a/src/mesa/drivers/dri/i965/brw_nir.h
+++ b/src/mesa/drivers/dri/i965/brw_nir.h
@@ -99,7 +99,6 @@ nir_shader *brw_preprocess_nir(const struct brw_compiler 
*compiler,
 bool brw_nir_lower_intrinsics(nir_shader *nir,
   struct brw_stage_prog_data *prog_data);
 void brw_nir_lower_vs_inputs(nir_shader *nir,
- const struct gen_device_info *devinfo,
  bool is_scalar,
  bool use_legacy_snorm_formula,
  const uint8_t *vs_attrib_wa_flags);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 6aa9102..362f32b 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -2114,7 +2114,7 @@ brw_compile_vs(const struct brw_compiler *compiler, void 
*log_data,
nir_shader *shader = nir_shader_clone(mem_ctx, src_shader);
shader = brw_nir_apply_sampler_key(shader, compiler->devinfo, &key->tex,
   is_scalar);
-   brw_nir_lower_vs_inputs(shader, compiler->devinfo, is_scalar,
+   brw_nir_lower_vs_inputs(shader, is_scalar,
use_legacy_snorm_formula, key->gl_attrib_wa_flags);
brw_nir_lower_vue_outputs(shader, is_scalar);
shader = brw_postprocess_nir(shader, compiler->devinfo, is_scalar);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h 
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 1505ba6..62c6007 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -262,7 +262,7 @@ public:
  src_reg offset_value,
  src_reg mcs,
  uint32_t surface, src_reg surface_reg,
- uint32_t sampler, src_reg sampler_reg);
+ src_reg sampler_reg);
 
src_reg emit_mcs_fetch(const glsl_type *coordinate_type, src_reg coordinate,
   src_reg surface);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 1d834a4..7b36fca 100644
--- a/src/mesa/drivers

[Mesa-dev] [PATCH 2/4] glsl: Remove prototypes for nonexistent functions

2016-10-14 Thread Ian Romanick 
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/compiler/glsl/ir.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/src/compiler/glsl/ir.h b/src/compiler/glsl/ir.h
index 83b810b..7e06d42 100644
--- a/src/compiler/glsl/ir.h
+++ b/src/compiler/glsl/ir.h
@@ -2357,9 +2357,6 @@ _mesa_glsl_initialize_derived_variables(struct gl_context 
*ctx,
 gl_shader *shader);
 
 extern void
-_mesa_glsl_initialize_functions(_mesa_glsl_parse_state *state);
-
-extern void
 _mesa_glsl_initialize_builtin_functions();
 
 extern ir_function_signature *
@@ -2376,9 +2373,6 @@ extern ir_function_signature *
 _mesa_get_main_function_signature(glsl_symbol_table *symbols);
 
 extern void
-_mesa_glsl_release_functions(void);
-
-extern void
 _mesa_glsl_release_builtin_functions(void);
 
 extern void
@@ -2390,9 +2384,6 @@ extern void
 import_prototypes(const exec_list *source, exec_list *dest,
  struct glsl_symbol_table *symbols, void *mem_ctx);
 
-extern bool
-ir_has_call(ir_instruction *ir);
-
 extern void
 do_set_program_inouts(exec_list *instructions, struct gl_program *prog,
   gl_shader_stage shader_stage);
-- 
2.5.5

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

Re: [Mesa-dev] [PATCH v2 4/7] egl/surfaceless: tweak surfaceless_add_configs_for_visuals()

2016-10-14 Thread Chad Versace 
On Fri 16 Sep 2016, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Analogous to previous commit.
> 
> v2: Use correct comparison in loop conditional (Eric)
> Use valid C initializer (Gurchetan)
> 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Gurchetan Singh 
> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)

This commit breaks the platform. eglCreatePbuffer no longer works.

I locally reverted the patch, and eglCreatePbuffer begins working again.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2 05/16] loader: reimplement loader_get_user_preferred_fd via libdrm

2016-10-14 Thread Emil Velikov 
From: Emil Velikov 

Currently not everyone has libudev and with follow-up patches we'll
completely remove the divergent codepaths.

Use the libdrm drm device API to construct the required ID_PATH_TAG-like
string, to preserve the current functionality for libudev users and
allow others to benefit from it as well.

v2: Drop ranty comments, pick the correct device

Cc: Axel Davy 
Signed-off-by: Emil Velikov 
---
 src/loader/loader.c | 247 ++--
 1 file changed, 106 insertions(+), 141 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index ad4f946..06df05b 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -69,16 +69,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef HAVE_LIBUDEV
 #include 
 #include 
-#include 
-#include 
-#ifdef USE_DRICONF
-#include "xmlconfig.h"
-#include "xmlpool.h"
-#endif
 #endif
 #ifdef MAJOR_IN_MKDEV
 #include 
@@ -89,7 +84,13 @@
 #include "loader.h"
 
 #ifdef HAVE_LIBDRM
+#include 
+#include 
 #include 
+#ifdef USE_DRICONF
+#include "xmlconfig.h"
+#include "xmlpool.h"
+#endif
 #endif
 
 #define __IS_LOADER
@@ -203,99 +204,9 @@ udev_device_new_from_fd(struct udev *udev, int fd)
 
return device;
 }
+#endif
 
-static char *
-get_render_node_from_id_path_tag(struct udev *udev,
- char *id_path_tag,
- char another_tag)
-{
-   struct udev_device *device;
-   struct udev_enumerate *e;
-   struct udev_list_entry *entry;
-   const char *path, *id_path_tag_tmp;
-   char *path_res;
-   char found = 0;
-   UDEV_SYMBOL(struct udev_enumerate *, udev_enumerate_new,
-   (struct udev *));
-   UDEV_SYMBOL(int, udev_enumerate_add_match_subsystem,
-   (struct udev_enumerate *, const char *));
-   UDEV_SYMBOL(int, udev_enumerate_add_match_sysname,
-   (struct udev_enumerate *, const char *));
-   UDEV_SYMBOL(int, udev_enumerate_scan_devices,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(struct udev_list_entry *, udev_enumerate_get_list_entry,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(void, udev_enumerate_unref,
-   (struct udev_enumerate *));
-   UDEV_SYMBOL(struct udev_list_entry *, udev_list_entry_get_next,
-   (struct udev_list_entry *));
-   UDEV_SYMBOL(const char *, udev_list_entry_get_name,
-   (struct udev_list_entry *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_new_from_syspath,
-   (struct udev *, const char *));
-   UDEV_SYMBOL(const char *, udev_device_get_property_value,
-   (struct udev_device *, const char *));
-   UDEV_SYMBOL(const char *, udev_device_get_devnode,
-   (struct udev_device *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
-   (struct udev_device *));
-
-   e = udev_enumerate_new(udev);
-   udev_enumerate_add_match_subsystem(e, "drm");
-   udev_enumerate_add_match_sysname(e, "render*");
-
-   udev_enumerate_scan_devices(e);
-   udev_list_entry_foreach(entry, udev_enumerate_get_list_entry(e)) {
-  path = udev_list_entry_get_name(entry);
-  device = udev_device_new_from_syspath(udev, path);
-  if (!device)
- continue;
-  id_path_tag_tmp = udev_device_get_property_value(device, "ID_PATH_TAG");
-  if (id_path_tag_tmp) {
- if ((!another_tag && !strcmp(id_path_tag, id_path_tag_tmp)) ||
- (another_tag && strcmp(id_path_tag, id_path_tag_tmp))) {
-found = 1;
-break;
- }
-  }
-  udev_device_unref(device);
-   }
-
-   udev_enumerate_unref(e);
-
-   if (found) {
-  path_res = strdup(udev_device_get_devnode(device));
-  udev_device_unref(device);
-  return path_res;
-   }
-   return NULL;
-}
-
-static char *
-get_id_path_tag_from_fd(struct udev *udev, int fd)
-{
-   struct udev_device *device;
-   const char *id_path_tag_tmp;
-   char *id_path_tag;
-   UDEV_SYMBOL(const char *, udev_device_get_property_value,
-   (struct udev_device *, const char *));
-   UDEV_SYMBOL(struct udev_device *, udev_device_unref,
-   (struct udev_device *));
-
-   device = udev_device_new_from_fd(udev, fd);
-   if (!device)
-  return NULL;
-
-   id_path_tag_tmp = udev_device_get_property_value(device, "ID_PATH_TAG");
-   if (!id_path_tag_tmp)
-  return NULL;
-
-   id_path_tag = strdup(id_path_tag_tmp);
-
-   udev_device_unref(device);
-   return id_path_tag;
-}
-
+#if defined(HAVE_LIBDRM)
 #ifdef USE_DRICONF
 static const char __driConfigOptionsLoader[] =
 DRI_CONF_BEGIN
@@ -321,17 +232,60 @@ static char *loader_get_dri_config_device_id(void)
 }
 #endif
 
+static char *drm_construct_id_path_tag(drmDevicePtr device)
+{
+/* Length of "pci-_xx_xx_x\n" */
+#define PCI_ID_PATH_TAG_LENGTH 17
+   char *tag = NULL;
+
+   if (device->bustype == DRM_BUS_PCI) {
+tag = calloc(PCI_ID_PATH_TAG_LENGTH, sizeof(char));
+if (tag == NULL)
+

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Perform check for valid fbconfig against proper X-Screen.

2016-10-14 Thread Emil Velikov 
On 14 October 2016 at 18:14, Mario Kleiner  wrote:
>
> They've been all merged, so you can close them.
>
Done and thanks again!

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

Re: [Mesa-dev] [PATCH 0/6] EGL_MESA_platform_surfaceless (v2)

2016-10-14 Thread Chad Versace 
Some people privately asked why we need to create this EGL platform.
I want to respond publicly.

Mesa *already* *has* this EGL platform. In my view, the issue at hand
isn't whether to create or to not create the platform. It's whether to
specify its behavior (formally in an extension spec) or not.

My motivation in writing the EGL_MESA_platform_surfaceless spec was not
to introduce any new features or behavior.  My motivation was to
document longstanding existing behavior in Chrome OS, that upstream Mesa
eventually subsumed.

During XDC, some people outside of the Chrome OS community complained to
me that the behavior of platform_surfaceless was ill-defined and
unstable, and they wanted the situation fixed. So I wrote a spec.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Fix typo in nir_op_pack_double_2x32_split handling

2016-10-14 Thread Ian Romanick 
On 10/08/2016 09:33 AM, Eduardo Lima Mitev wrote:
> On 10/08/2016 02:12 AM, Ian Romanick wrote:
>> From: Ian Romanick 
>>
>> This was found partially by inspection and partially by hitting a
>> problem while working on nir_op_pack_int64_2x32_split.  The code
>> previously would 'continue' if (instr->src[i].src.is_ssa), but the code
>> immediately following in the loop treats instr->src[i] as an SSA value.
>>
>> Signed-off-by: Ian Romanick 
>> Cc: mesa-sta...@lists.freedesktop.org
>> Cc: Iago Toral Quiroga 
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
>> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> index 4e68ffb..2cbcab1 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
>> @@ -1208,7 +1208,7 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
>> nir_alu_instr *instr)
>> * the unpack operation.
>> */
>>for (int i = 0; i < 2; i++) {
>> - if (instr->src[i].src.is_ssa)
>> + if (!instr->src[i].src.is_ssa)
>>  continue;
>>  
> 
> Good catch!

But maybe not.  Re-running this through the CI shows about 1,000 test
regressions due to assertion failures.  I looked at the rest of the
loop, and I'm really not sure how this works:

  for (int i = 0; i < 2; i++) {
 if (instr->src[i].src.is_ssa)
continue;

 const nir_instr *parent_instr = instr->src[i].src.ssa->parent_instr;

We skip this if the source is SSA, but then we use it as SSA.

 if (parent_instr->type == nir_instr_type_alu)
continue;

 const nir_alu_instr *alu_parent = nir_instr_as_alu(parent_instr);

We skip this if the parent is ALU, but then we use it as ALU.  The
assertion failure occurs inside nir_instr_as_alu.

 if (alu_parent->op == nir_op_unpack_double_2x32_split_x ||
 alu_parent->op == nir_op_unpack_double_2x32_split_y)
continue;

 if (!alu_parent->src[0].src.is_ssa)
continue;

 op[i] = get_nir_src(alu_parent->src[0].src);
 op[i] = offset(retype(op[i], BRW_REGISTER_TYPE_DF), bld,
alu_parent->src[0].swizzle[channel]);
 if (alu_parent->op == nir_op_unpack_double_2x32_split_y)
op[i] = subscript(op[i], BRW_REGISTER_TYPE_UD, 1);
 else
op[i] = subscript(op[i], BRW_REGISTER_TYPE_UD, 0);
  }

Were you guys ever able to make this optimization trigger?  I suspect
that the very first continue always occurs, so none of this actually
happens.  Either way, it seems like this optimization should happen in
nir_opt_algebraic instead.

This has come up because I need to do something similar for int64.  All
of the lowering passes for int64 will generate a lot of
unpack(pack(...)) type sequences.  I'm doing the lowering in GLSL IR,
so I've also done the algebraic optimization in GLSL IR.

> Both patches are:
> 
> Reviewed-by: Eduardo Lima Mitev 
> 
>>   const nir_instr *parent_instr = 
>> instr->src[i].src.ssa->parent_instr;
>>




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

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Perform check for valid fbconfig against proper X-Screen.

2016-10-14 Thread Mario Kleiner 



On 10/14/2016 11:14 AM, Emil Velikov wrote:

On 12 October 2016 at 18:40, Emil Velikov  wrote:

On 11 October 2016 at 19:42, Mario Kleiner  wrote:



Tested to fix context creation failure on a dual-x-screen setup.

Signed-off-by: Mario Kleiner 
Cc: "11.2 12.0" 

Reviewed-by: Emil Velikov 


... and pushed to master.

Mario, can you skim through this list [1] and let me know if any the
patches is outstanding or I can "close" them.



They've been all merged, so you can close them.

thanks,
-mario


Thanks
Emil
[1] 
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956&state=&q=&archive=&delegate=


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

[Mesa-dev] [Bug 98263] [radv] The Talos Principle fails to launch with "Fatal error: Cannot set display mode."

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98263

--- Comment #1 from Kai  ---
Created attachment 127306
  --> https://bugs.freedesktop.org/attachment.cgi?id=127306&action=edit
output of vulkaninfo

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

[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=77449

Kai  changed:

   What|Removed |Added

 Depends on||98263


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=98263
[Bug 98263] [radv] The Talos Principle fails to launch with "Fatal error:
Cannot set display mode."
-- 
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

[Mesa-dev] [Bug 98263] [radv] The Talos Principle fails to launch with "Fatal error: Cannot set display mode."

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98263

Bug ID: 98263
   Summary: [radv] The Talos Principle fails to launch with "Fatal
error: Cannot set display mode."
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: k...@dev.carbon-project.org
QA Contact: mesa-dev@lists.freedesktop.org
Blocks: 77449

Created attachment 127305
  --> https://bugs.freedesktop.org/attachment.cgi?id=127305&action=edit
Error log of "The Talos Principle" when launched with Vulkan

I wanted to test The Talos Principle with my Hawaii GPU (for the full stack see
below). But whenever I launch the game I get the error "Fatal error: Cannot set
display mode." and the attached info is logged to the console.

To launch the game with Vulkan I opted into the Beta (as recommended by
CroTeam) and set »+gfx_strAPI "VLK"« as a command line option (Steam Library →
The Talos Principle → Properties → Set Launch Options → »%command% +gfx_strAPI
"VLK"«), like it was recommended for Linux users by CroTeam in multiple
threads, see eg.
.
Afterwards I tried to launch the 64-bit version of The Talos Principle.
In case this makes a difference: I've the Road to Gehenna DLC installed.

With OpenGL the game works as expected.

When I run vulkaninfo (from the Debian package vulkan-utils) everything looks
ok/like Vulkan is working.


The stack showing this issue is (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/7dddf0b7ab
libdrm: 2.4.71-1
LLVM: SVN:trunk/r284109 (4.0 devel)
X.Org: 2:1.18.4-2
Linux: 4.8.1
Firmware (firmware-amd-graphics): 20160824-1
libclc: Git:master/520743b0b7
DDX (xserver-xorg-video-amdgpu): 1.1.2-1

Let me know, if you need anything else.


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=77449
[Bug 77449] Tracker bug for all bugs related to Steam titles
-- 
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] draw: improved handling of undefined inputs

2016-10-14 Thread Jose Fonseca 
Looks great to me!

Reviewed-by: José Fonseca 



From: Roland Scheidegger
Sent: Friday, 14 October, 02:21
Subject: [PATCH] draw: improved handling of undefined inputs
To: Jose Fonseca, ML mesa-dev
Cc: Roland Scheidegger

From: Roland Scheidegger Previous attempts to zero initialize all inputs were 
not really optimal (though no performance impact was measurable). In fact this 
is not really necessary, since we know the max number of inputs used. Instead, 
just generate fetch for up to max inputs used by the shader, directly replacing 
inputs for which there was no vertex element by zero. This also cleans up key 
generation, which previously would have stored some garbage for these elements. 
And also drop the assertion which indicates such bogus usage by a debug_printf 
(the whole point of initializing the undefined inputs was to make this case 
safe to handle). --- src/gallium/auxiliary/draw/draw_llvm.c | 53 
-- 1 file changed, 32 insertions(+), 21 
deletions(-) diff --git a/src/gallium/auxiliary/draw/draw_llvm.c 
b/src/gallium/auxiliary/draw/draw_llvm.c index 4270a8f..3b56856 100644 --- 
a/src/gallium/auxiliary/draw/draw_llvm.c +++ 
b/src/gallium/auxiliary/draw/draw_llvm.c @@ -689,6 +689,11 @@ 
generate_fetch(struct gallivm_state *gallivm, LLVMValueRef ofbit = NULL; struct 
lp_build_if_state if_ctx; + if (velem->src_format == PIPE_FORMAT_NONE) { + *res 
= lp_build_const_vec(gallivm, lp_float32_vec4_type(), 0); + return; + } + if 
(velem->instance_divisor) { /* Index is equal to the start instance plus the 
number of current * instance divided by the divisor. In this case we compute it 
as: @@ -1706,12 +1711,6 @@ draw_llvm_generate(struct draw_llvm *llvm, struct 
draw_llvm_variant *variant, io_itr, io, lp_loop.counter); #endif - for (j = 
draw->pt.nr_vertex_elements; j < PIPE_MAX_SHADER_INPUTS; j++) { - for (i = 0; i 
< TGSI_NUM_CHANNELS; i++) { - inputs[j][i] = lp_build_zero(gallivm, vs_type); - 
} - } - for (i = 0; i < vector_length; ++i) { LLVMValueRef vert_index = 
LLVMBuildAdd(builder, @@ -1765,7 +1764,7 @@ draw_llvm_generate(struct draw_llvm 
*llvm, struct draw_llvm_variant *variant, gallivm->builder, true_index_array, 
true_index, lp_build_const_int32(gallivm, i), ""); - for (j = 0; j < 
draw->pt.nr_vertex_elements; ++j) { + for (j = 0; j < key->nr_vertex_elements; 
++j) { struct pipe_vertex_element *velem = &draw->pt.vertex_element[j]; 
LLVMValueRef vb_index = lp_build_const_int32(gallivm, 
velem->vertex_buffer_index); @@ -1776,7 +1775,7 @@ draw_llvm_generate(struct 
draw_llvm *llvm, struct draw_llvm_variant *variant, } } convert_to_soa(gallivm, 
aos_attribs, inputs, - draw->pt.nr_vertex_elements, vs_type); + 
key->nr_vertex_elements, vs_type); /* In the paths with elts vertex id has to 
be unaffected by the * index bias and because indices inside our elements array 
have @@ -1873,15 +1872,6 @@ draw_llvm_make_variant_key(struct draw_llvm *llvm, 
char *store) key->clamp_vertex_color = 
llvm->draw->rasterizer->clamp_vertex_color; /**/ - /* Presumably all variants 
of the shader should have the same - * number of vertex elements - ie the 
number of shader inputs. - * NOTE: we NEED to store the needed number of needed 
inputs - * here, not the number of provided elements to match keysize - * (and 
the offset of sampler state in the key). - */ - key->nr_vertex_elements = 
llvm->draw->vs.vertex_shader->info.file_max[TGSI_FILE_INPUT] + 1; - 
assert(key->nr_vertex_elements draw->pt.nr_vertex_elements); - /* will have to 
rig this up properly later */ key->clip_xy = llvm->draw->clip_xy; key->clip_z = 
llvm->draw->clip_z; @@ -1907,13 +1897,34 @@ draw_llvm_make_variant_key(struct 
draw_llvm *llvm, char *store) key->nr_sampler_views = key->nr_samplers; } - 
draw_sampler = draw_llvm_variant_key_samplers(key); - + /* Presumably all 
variants of the shader should have the same + * number of vertex elements - ie 
the number of shader inputs. + * NOTE: we NEED to store the needed number of 
needed inputs + * here, not the number of provided elements to match keysize + 
* (and the offset of sampler state in the key). + * If we have excess number of 
vertex elements, this is valid, + * but the excess ones don't matter. + * If we 
don't have enough vertex elements (which looks not really + * valid but we'll 
handle it gracefully) fill out missing ones with + * zero (we'll recognize 
these later by PIPE_FORMAT_NONE). + */ + key->nr_vertex_elements = + 
llvm->draw->vs.vertex_shader->info.file_max[TGSI_FILE_INPUT] + 1; + + if 
(llvm->draw->pt.nr_vertex_elements < key->nr_vertex_elements) { + 
debug_printf("draw: vs with %d inputs but only have %d vertex elements\n", + 
key->nr_vertex_elements, llvm->draw->pt.nr_vertex_elements); + 
memset(key->vertex_element, 0, + sizeof(struct pipe_vertex_element) * 
key->nr_vertex_elements); + } memcpy(key->vertex_element, 
llvm->draw->pt.vertex_element, - sizeof(struct pipe_vertex_element) * 
key->nr_vertex_elements); + sizeof(struct pipe_vertex_eleme

[Mesa-dev] [PATCH] Initial Intel Vulkan internals documentation

2016-10-14 Thread kevin . rogovin 
From: Kevin Rogovin 

This is an RFC for documentation I am making for the Intel OTC
Vulkan driver. The eventual goal for the documentation is to
help new developers understand the code base more quickly so
that they can contribute more easily.


Kevin Rogovin (1):
  vulkan: Initial partial documentation for Vulkan internals.

 src/intel/genxml/gen_macros.h   |4 +-
 src/intel/vulkan/anv_allocator.c|5 +-
 src/intel/vulkan/anv_private.h  |  287 +++-
 src/intel/vulkan/docs/.gitignore|1 +
 src/intel/vulkan/docs/Doxyfile  | 2483 +++
 src/intel/vulkan/docs/intel_vulkan.doxy |   86 ++
 6 files changed, 2845 insertions(+), 21 deletions(-)
 create mode 100644 src/intel/vulkan/docs/.gitignore
 create mode 100644 src/intel/vulkan/docs/Doxyfile
 create mode 100644 src/intel/vulkan/docs/intel_vulkan.doxy

-- 
2.7.4

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

Re: [Mesa-dev] [PATCH] gallivm: print out time for jitting functions with GALLIVM_DEBUG=perf

2016-10-14 Thread Jose Fonseca 

On 14/10/16 15:36, Brian Paul wrote:

On 10/13/2016 09:38 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

Compilation to actual machine code can easily take as much time as the
optimization passes on the IR if not more, so print this out too.
---
  src/gallium/auxiliary/gallivm/lp_bld_init.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7114cde..d1b2369 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -659,13 +659,24 @@ gallivm_jit_function(struct gallivm_state *gallivm,
  {
 void *code;
 func_pointer jit_func;
+   int64_t time_begin = 0;


I think we might want to put MAYBE_UNUSED on that decl so there's not an
unused var warning in a non-debug build.


I think it might be OK because Roland's using `if` isntead of `#if`. 
That said, some compilers are too smart for their own good.






 assert(gallivm->compiled);
 assert(gallivm->engine);

+   if (gallivm_debug & GALLIVM_DEBUG_PERF)
+  time_begin = os_time_get();
+
 code = LLVMGetPointerToGlobal(gallivm->engine, func);
 assert(code);
 jit_func = pointer_to_func(code);

+   if (gallivm_debug & GALLIVM_DEBUG_PERF) {
+  int64_t time_end = os_time_get();
+  int time_msec = (int)(time_end - time_begin) / 1000;
+  debug_printf("   jitting func %s took %d msec\n",
+   LLVMGetValueName(func), time_msec);
+   }
+
 return jit_func;
  }



Looks OK otherwise.

Reviewed-by: Brian Paul 


Reviewed-by: Jose Fonseca 

Jose

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

[Mesa-dev] [Bug 98168] [vulkan, radv] Talos rendering glitches on Ultra settings on Tonga

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98168

--- Comment #6 from Christoph Haag  ---
Created attachment 127304
  --> https://bugs.freedesktop.org/attachment.cgi?id=127304&action=edit
water with 8xaa

(In reply to Vedran Miletić from comment #5)

> https://youtu.be/dS2HLt5BjFY

I believe I recorded this on medium. But I can't remember seeing it when I
played again just now. This may already be fixed.


Back to topic: I decided to try some settings and the first one I tried already
was the cause: Anti Aliasing.

2x Anti Aliasing looks fine
4x Anti Aliasing causes some of these light blobs to appear, mostly on water
8x Anti Aliasing causes *a lot* of these light blobs to appear, see screenshot

-- 
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] anv: fix enumeration of properties

2016-10-14 Thread Eric Engestrom 
On Thursday, 2016-10-06 14:12:27 +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Driver should enumerate only up-to min2(num_available, num_requested)
> properties and return VK_INCOMPLETE if the # of requested props is
> smaller than the ones available.
> 
> Presently we assert out in such cases.
> 
> Inspired by a similar fix for RADV.
> 
> Should fix: dEQP-VK.api.info.device.extensions
> Signed-off-by: Emil Velikov 

Matches the spec[1] :)
Reviewed-by: Eric Engestrom 

[1] 
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#extended-functionality-extensions

> ---
>  src/intel/vulkan/anv_device.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index c7b9979..497bf9f 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -1003,15 +1003,19 @@ VkResult anv_EnumerateInstanceExtensionProperties(
>  uint32_t*   pPropertyCount,
>  VkExtensionProperties*  pProperties)
>  {
> +   unsigned i;
> +
> if (pProperties == NULL) {
>*pPropertyCount = ARRAY_SIZE(global_extensions);
>return VK_SUCCESS;
> }
>  
> -   assert(*pPropertyCount >= ARRAY_SIZE(global_extensions));
> +   for (i = 0; i < MIN2(*pPropertyCount, ARRAY_SIZE(global_extensions)); i++)
> +  memcpy(&pProperties[i], &global_extensions[i], 
> sizeof(VkExtensionProperties));
>  
> -   *pPropertyCount = ARRAY_SIZE(global_extensions);
> -   memcpy(pProperties, global_extensions, sizeof(global_extensions));
> +   *pPropertyCount = i;
> +   if (i < ARRAY_SIZE(global_extensions))
> +  return VK_INCOMPLETE;
>  
> return VK_SUCCESS;
>  }
> @@ -1022,15 +1026,19 @@ VkResult anv_EnumerateDeviceExtensionProperties(
>  uint32_t*   pPropertyCount,
>  VkExtensionProperties*  pProperties)
>  {
> +   unsigned i;
> +
> if (pProperties == NULL) {
>*pPropertyCount = ARRAY_SIZE(device_extensions);
>return VK_SUCCESS;
> }
>  
> -   assert(*pPropertyCount >= ARRAY_SIZE(device_extensions));
> +   for (i = 0; i < MIN2(*pPropertyCount, ARRAY_SIZE(device_extensions)); i++)
> +  memcpy(&pProperties[i], &device_extensions[i], 
> sizeof(VkExtensionProperties));
>  
> -   *pPropertyCount = ARRAY_SIZE(device_extensions);
> -   memcpy(pProperties, device_extensions, sizeof(device_extensions));
> +   *pPropertyCount = i;
> +   if (i < ARRAY_SIZE(device_extensions))
> +  return VK_INCOMPLETE;
>  
> return VK_SUCCESS;
>  }
> -- 
> 2.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/15] ralloc: don't memset ralloc_header, clear it manually

2016-10-14 Thread Emil Velikov 
On 8 October 2016 at 11:58, Marek Olšák  wrote:
> From: Marek Olšák 
>
> time GALLIUM_NOOP=1 ./run shaders/private/alien_isolation/ >/dev/null
>
> Before (2 takes):
>
> real0m8.734s0m8.773s
> user0m34.232s   0m34.348s
> sys 0m0.084s0m0.056s
>
> After (2 takes):
>
> real0m8.448s0m8.463s
> user0m33.104s   0m33.160s
> sys 0m0.088s0m0.076s
>
> Average change in "real" time spent: -3.4%
>
> calloc should only do 2 things compared to malloc:
> - check for overflow of "n * size"
> - call memset
>
> I'm not sure if that explains the difference.
The difference is quite interesting indeed.

One small suggestion below.

> ---
>  src/util/ralloc.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/ralloc.c b/src/util/ralloc.c
> index 9526011..23c89e5 100644
> --- a/src/util/ralloc.c
> +++ b/src/util/ralloc.c
> @@ -91,20 +91,23 @@ get_header(const void *ptr)
>  static void
>  add_child(ralloc_header *parent, ralloc_header *info)
>  {
> if (parent != NULL) {
>info->parent = parent;
>info->next = parent->child;
>parent->child = info;
>
>if (info->next != NULL)
>  info->next->prev = info;
> +   } else {
> +  info->parent = NULL;
> +  info->next = NULL;
add_child is used on two occasions - rzalloc_size after memset* and
ralloc_steal after unlink_block. The latter of which already clears
the parent and siblings pointers.
Thus we can move the above two lines...

> }
>  }
>
>  void *
>  ralloc_context(const void *ctx)
>  {
> return ralloc_size(ctx, 0);
>  }
>
>  void *
> @@ -115,27 +118,39 @@ ralloc_size(const void *ctx, size_t size)
>  *
>  * TODO: Make ralloc_size not zero fill memory, and cleanup any code that
>  * should instead be using rzalloc.
>  */
> return rzalloc_size(ctx, size);
>  }
>
>  void *
>  rzalloc_size(const void *ctx, size_t size)
>  {
> -   void *block = calloc(1, size + sizeof(ralloc_header));
> +   void *block = malloc(size + sizeof(ralloc_header));
> ralloc_header *info;
> ralloc_header *parent;
>
> if (unlikely(block == NULL))
>return NULL;
> +
> info = (ralloc_header *) block;
> +   /* measurements have shown that calloc is slower, so clear things
> +* manually
> +*/
> +   info->child = NULL;
> +   info->prev = NULL;
> +   info->destructor = NULL;
> +   /* add_child() clears other members */
> +
... here and drop the comment.

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

Re: [Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow

2016-10-14 Thread Lionel Landwerlin 
Yeah, looking at it a bit longer, it seems that the unbind behavior 
broke (again like Eric suggested).


When you replaced that condition :

unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);

if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {

By this :

if (cctx || ddraw || rdraw) {


The bindContext() used to get executed when unbinding a context, now it 
reports a BAD_MATCH error.


-
Lionel

On 14/10/16 16:13, Lionel Landwerlin wrote:

Thanks a lot,

The diff is a bit too complicated for me to tell how it's different.

-
Lionel

On 14/10/16 16:11, Emil Velikov wrote:

On 14 October 2016 at 15:58, Lionel Landwerlin
 wrote:

Hi Emil,

I've not been able to run the deqp gles31 test suite after this commit.
Like Eric suggested I think this is introducing a behavior change.


v2 should not do that, yet it might be missing something. I've
reverted it and will give it another try after checking with deqp.

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



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



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

Re: [Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow

2016-10-14 Thread Lionel Landwerlin 

Thanks a lot,

The diff is a bit too complicated for me to tell how it's different.

-
Lionel

On 14/10/16 16:11, Emil Velikov wrote:

On 14 October 2016 at 15:58, Lionel Landwerlin
 wrote:

Hi Emil,

I've not been able to run the deqp gles31 test suite after this commit.
Like Eric suggested I think this is introducing a behavior change.


v2 should not do that, yet it might be missing something. I've
reverted it and will give it another try after checking with deqp.

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



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

Re: [Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow

2016-10-14 Thread Emil Velikov 
On 14 October 2016 at 15:58, Lionel Landwerlin
 wrote:
> Hi Emil,
>
> I've not been able to run the deqp gles31 test suite after this commit.
> Like Eric suggested I think this is introducing a behavior change.
>
v2 should not do that, yet it might be missing something. I've
reverted it and will give it another try after checking with deqp.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH 3/3] i915: store reference to the context within struct intel_fence

2016-10-14 Thread Emil Velikov 
On 27 July 2016 at 15:30, Emil Velikov  wrote:
> On 16 July 2016 at 01:02, Mauro Rossi  wrote:
>> Hi,
>>
>> I'm sending the v2 re-spin of patch as per i965, rechecked twice
>> line-by-line with Tomasz's one.
>>
>> Building ok, marshmallow-x86 booting ok and here are the results of Android
>> CTS egl and gles2 x86 target tests
>>
>> Android CTS 6.0_r7 build:2906653
>> 07-16 00:52:42 I/DeviceManager: Detected new device 192.168.1.7:
>> cts-tf > list r
>> Session Pass   Fail Not Executed  Start time   Plan name
>> Device serial(s)
>> 0(EGL)  1410   24   0 2016.07.16_00.21.30  NA
>> unknown
>> 1(GLES2)  13832 82   0 2016.07.16_00.24.23  NA
>> unknown
>> cts-tf >
>>
>> I get the same results as per i965GM
>>
> Thanks Mauro.
>
> Can we get an ack/nack/r-b from any of the Intel devs ? How do you
> feel on getting this in -stable ?
> FTR the series is identical to the i965 patches by Chad/me/Tomasz
> barring a few s/i915/i965/ style changes.
>
I've dropped the stable tag, added the above test results and fixed a
few missing 'intel_sync' -> 'intel_gl_sync'.

Thanks Mauro ! Can you please check through the list [1] and let me
know if anything else is outstanding ?
Emil

[1] 
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=15603&state=&q=&archive=&delegate=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 10/30] egl/dri2: rework dri2_make_current code flow

2016-10-14 Thread Lionel Landwerlin 

Hi Emil,

I've not been able to run the deqp gles31 test suite after this commit.
Like Eric suggested I think this is introducing a behavior change.

Thanks,

-
Lionel

On 03/10/16 19:28, Emil Velikov wrote:

From: Emil Velikov 

Fold duplicate conditional blocks and add a few extra comments ;-)

v2: Bring back the explicit "unbind" logic (Eric), remove NULL derefs.

Signed-off-by: Emil Velikov 
---
  src/egl/drivers/dri2/egl_dri2.c | 72 -
  1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 96fef52..378ee5c 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1260,11 +1260,11 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
 struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
 struct dri2_egl_context *dri2_ctx = dri2_egl_context(ctx);
 _EGLContext *old_ctx;
+   _EGLDisplay *old_disp = NULL;
 _EGLSurface *old_dsurf, *old_rsurf;
 _EGLSurface *tmp_dsurf, *tmp_rsurf;
 __DRIdrawable *ddraw, *rdraw;
 __DRIcontext *cctx;
-   EGLBoolean unbind;
  
 if (!dri2_dpy)

return _eglError(EGL_NOT_INITIALIZED, "eglMakeCurrent");
@@ -1275,55 +1275,55 @@ dri2_make_current(_EGLDriver *drv, _EGLDisplay *disp, 
_EGLSurface *dsurf,
return EGL_FALSE;
 }
  
-   /* flush before context switch */

-   if (old_ctx)
-  dri2_drv->glFlush();
-
 ddraw = (dsurf) ? dri2_dpy->vtbl->get_dri_drawable(dsurf) : NULL;
 rdraw = (rsurf) ? dri2_dpy->vtbl->get_dri_drawable(rsurf) : NULL;
 cctx = (dri2_ctx) ? dri2_ctx->dri_context : NULL;
  
 if (old_ctx) {

__DRIcontext *old_cctx = dri2_egl_context(old_ctx)->dri_context;
+
+  /* flush before context switch */
+  dri2_drv->glFlush();
dri2_dpy->core->unbindContext(old_cctx);
+
+  /* Keep track of the old dpy as we'll need it for resource cleanup */
+  old_disp = old_ctx->Resource.Display;
 }
  
-   unbind = (cctx == NULL && ddraw == NULL && rdraw == NULL);

+   /* Bind if at least one of the primitives is valid ... */
+   if (cctx || ddraw || rdraw) {
+  if (dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {
+ /* undo the previous _eglBindContext */
+ _eglBindContext(old_ctx, old_dsurf, old_rsurf, &ctx, &tmp_dsurf, 
&tmp_rsurf);
+ assert(&dri2_ctx->base == ctx &&
+tmp_dsurf == dsurf &&
+tmp_rsurf == rsurf);
+
+ _eglPutSurface(dsurf);
+ _eglPutSurface(rsurf);
+ _eglPutContext(ctx);
  
-   if (unbind || dri2_dpy->core->bindContext(cctx, ddraw, rdraw)) {

-  dri2_destroy_surface(drv, disp, old_dsurf);
-  dri2_destroy_surface(drv, disp, old_rsurf);
+ _eglPutSurface(old_dsurf);
+ _eglPutSurface(old_rsurf);
+ _eglPutContext(old_ctx);
  
-  if (!unbind)

- dri2_dpy->ref_count++;
-  if (old_ctx) {
- EGLDisplay old_disp = _eglGetDisplayHandle(old_ctx->Resource.Display);
- dri2_destroy_context(drv, disp, old_ctx);
- dri2_display_release(old_disp);
+ /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, 
but
+  * setting the error to EGL_BAD_MATCH is surely better than leaving it
+  * as EGL_SUCCESS.
+  */
+ return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
}
  
-  return EGL_TRUE;

-   } else {
-  /* undo the previous _eglBindContext */
-  _eglBindContext(old_ctx, old_dsurf, old_rsurf, &ctx, &tmp_dsurf, 
&tmp_rsurf);
-  assert(&dri2_ctx->base == ctx &&
- tmp_dsurf == dsurf &&
- tmp_rsurf == rsurf);
-
-  _eglPutSurface(dsurf);
-  _eglPutSurface(rsurf);
-  _eglPutContext(ctx);
-
-  _eglPutSurface(old_dsurf);
-  _eglPutSurface(old_rsurf);
-  _eglPutContext(old_ctx);
-
-  /* dri2_dpy->core->bindContext failed. We cannot tell for sure why, but
-   * setting the error to EGL_BAD_MATCH is surely better than leaving it
-   * as EGL_SUCCESS.
-   */
-  return _eglError(EGL_BAD_MATCH, "eglMakeCurrent");
+  /* ... and refcount the dpy when successful. */
+  dri2_dpy->ref_count++;
 }
+
+   dri2_destroy_surface(drv, disp, old_dsurf);
+   dri2_destroy_surface(drv, disp, old_rsurf);
+   dri2_destroy_context(drv, disp, old_ctx);
+   dri2_display_release(old_disp);
+
+   return EGL_TRUE;
  }
  
  __DRIdrawable *



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

Re: [Mesa-dev] [PATCH] gallivm: print out time for jitting functions with GALLIVM_DEBUG=perf

2016-10-14 Thread Brian Paul 

On 10/13/2016 09:38 PM, srol...@vmware.com wrote:

From: Roland Scheidegger 

Compilation to actual machine code can easily take as much time as the
optimization passes on the IR if not more, so print this out too.
---
  src/gallium/auxiliary/gallivm/lp_bld_init.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 7114cde..d1b2369 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -659,13 +659,24 @@ gallivm_jit_function(struct gallivm_state *gallivm,
  {
 void *code;
 func_pointer jit_func;
+   int64_t time_begin = 0;


I think we might want to put MAYBE_UNUSED on that decl so there's not an 
unused var warning in a non-debug build.





 assert(gallivm->compiled);
 assert(gallivm->engine);

+   if (gallivm_debug & GALLIVM_DEBUG_PERF)
+  time_begin = os_time_get();
+
 code = LLVMGetPointerToGlobal(gallivm->engine, func);
 assert(code);
 jit_func = pointer_to_func(code);

+   if (gallivm_debug & GALLIVM_DEBUG_PERF) {
+  int64_t time_end = os_time_get();
+  int time_msec = (int)(time_end - time_begin) / 1000;
+  debug_printf("   jitting func %s took %d msec\n",
+   LLVMGetValueName(func), time_msec);
+   }
+
 return jit_func;
  }



Looks OK otherwise.

Reviewed-by: Brian Paul 

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

[Mesa-dev] [Bug 98132] #version 300 es compute shaders should not be possible

2016-10-14 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=98132

Iago Toral  changed:

   What|Removed |Added

 CC||ito...@igalia.com

--- Comment #2 from Iago Toral  ---
I have sent a couple of patches for review that fix these tests:

https://lists.freedesktop.org/archives/mesa-dev/2016-October/131942.html
https://lists.freedesktop.org/archives/mesa-dev/2016-October/131943.html

-- 
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

[Mesa-dev] [PACH v2] glsl: SSBO unsized array declarations, if present, must be declared last

2016-10-14 Thread Iago Toral Quiroga 
From the ARB_shader_storage_buffer_object spec:

"In a shader storage block, the last member may be declared without an explicit
 size.  In this case, the effective array size is inferred at run-time from
 the size of the data store backing the interface block.  Such unsized
 arrays may be indexed with general integer expressions, but may not be
 passed as an argument to a function or indexed with a negative constant
 expression."

dEQP tests that SSBOs that declare field members after an unsized array
declaration fail to compile.

Fixes the remaining subcase of the following dEQP tests:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader

v2: only update has_unsized_array while we have not found a previous unsized
array declaration.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98132
---
 src/compiler/glsl/ast_to_hir.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index c3c8cef..462838a 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -6645,6 +6645,7 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
 
bool first_member = true;
bool first_member_has_explicit_location = false;
+   bool has_unsized_array = false;
 
unsigned i = 0;
foreach_list_typed (ast_declarator_list, decl_list, link, declarations) {
@@ -6840,6 +6841,13 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
 
  const struct glsl_type *field_type =
 process_array_type(&loc, decl_type, decl->array_specifier, state);
+
+ if (has_unsized_array && var_mode == ir_var_shader_storage)
+_mesa_glsl_error(&loc, state, "SSBO member declared "
+ "after unsized array.");
+ else if (!has_unsized_array)
+has_unsized_array = field_type->is_unsized_array();
+
  validate_array_dimensions(field_type, state, &loc);
  fields[i].type = field_type;
  fields[i].name = decl->identifier;
-- 
2.7.4

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

[Mesa-dev] [PATCH 2/2] glsl: SSBO unsized array declarations, if present, must be declared last

2016-10-14 Thread Iago Toral Quiroga 
From the ARB_shader_storage_buffer_object spec:

"In a shader storage block, the last member may be declared without an explicit
 size.  In this case, the effective array size is inferred at run-time from
 the size of the data store backing the interface block.  Such unsized
 arrays may be indexed with general integer expressions, but may not be
 passed as an argument to a function or indexed with a negative constant
 expression."

dEQP tests that shaders with SSBOs that declare field members after an
unsized array declaration fail to compile.

Fixes the remaining subcase of the following dEQP tests:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98132
---
 src/compiler/glsl/ast_to_hir.cpp | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index c3c8cef..2d9d92d 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -6645,6 +6645,7 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
 
bool first_member = true;
bool first_member_has_explicit_location = false;
+   bool has_unsized_array = false;
 
unsigned i = 0;
foreach_list_typed (ast_declarator_list, decl_list, link, declarations) {
@@ -6840,6 +6841,13 @@ ast_process_struct_or_iface_block_members(exec_list 
*instructions,
 
  const struct glsl_type *field_type =
 process_array_type(&loc, decl_type, decl->array_specifier, state);
+
+ if (has_unsized_array && var_mode == ir_var_shader_storage)
+_mesa_glsl_error(&loc, state, "SSBO member declared "
+ "after unsized array.");
+ else
+has_unsized_array = field_type->is_unsized_array();
+
  validate_array_dimensions(field_type, state, &loc);
  fields[i].type = field_type;
  fields[i].name = decl->identifier;
-- 
2.7.4

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

[Mesa-dev] [PATCH 1/2] glsl: fail compilation of compute shaders when unsupported

2016-10-14 Thread Iago Toral Quiroga 
Generally, we only check for the presence of compute shaders during
parsing when we find any language (like layout qualifiers) that are
specific to compute shaders, however, it is possible to define an
empty compute shader does not use any language specific to compute
shaders at all and we should fail the compilation anyway. dEQP checks
this.

This patch adds a check for compute shader availability after we have
parsed the source code. At this point we know the effective GLSL version
and also extensions enabled in the shader.

Fixes a subcase of the following dEQP tests:
dEQP-GLES31.functional.debug.negative_coverage.callbacks.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.get_error.shader.compile_compute_shader
dEQP-GLES31.functional.debug.negative_coverage.log.shader.compile_compute_shader

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98132
---
 src/compiler/glsl/glsl_parser_extras.cpp | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/compiler/glsl/glsl_parser_extras.cpp 
b/src/compiler/glsl/glsl_parser_extras.cpp
index 6270e8e..b351180 100644
--- a/src/compiler/glsl/glsl_parser_extras.cpp
+++ b/src/compiler/glsl/glsl_parser_extras.cpp
@@ -1877,6 +1877,18 @@ add_builtin_defines(struct _mesa_glsl_parse_state *state,
}
 }
 
+/* Implements parsing checks that we can't do during parsing */
+static void
+do_late_parsing_checks(struct _mesa_glsl_parse_state *state)
+{
+   if (state->stage == MESA_SHADER_COMPUTE && !state->has_compute_shader()) {
+  YYLTYPE loc;
+  memset(&loc, 0, sizeof(loc));
+  _mesa_glsl_error(&loc, state, "Compute shaders require "
+   "GLSL 4.30 or GLSL ES 3.10");
+   }
+}
+
 void
 _mesa_glsl_compile_shader(struct gl_context *ctx, struct gl_shader *shader,
   bool dump_ast, bool dump_hir)
@@ -1896,6 +1908,7 @@ _mesa_glsl_compile_shader(struct gl_context *ctx, struct 
gl_shader *shader,
  _mesa_glsl_lexer_ctor(state, source);
  _mesa_glsl_parse(state);
  _mesa_glsl_lexer_dtor(state);
+ do_late_parsing_checks(state);
}
 
if (dump_ast) {
-- 
2.7.4

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

Re: [Mesa-dev] [PATCH 1/6] util: add vector util code.

2016-10-14 Thread Marek Olšák 
The beginning of the header file should describe what it is.

Marek

On Oct 14, 2016 6:45 AM, "Edward O'Callaghan" 
wrote:

> Too easy, one trivial comment below but either way:
> Reviewed-by: Edward O'Callaghan 
>
> P.S. thanks for getting on top of this kind of maintainability stuff so
> fast !
>
> On 10/14/2016 02:16 PM, Dave Airlie wrote:
> > From: Dave Airlie 
> >
> > This is ported from anv, both anv and radv can share this.
> >
> > Signed-off-by: Dave Airlie 
> > ---
> >  src/util/Makefile.sources |  4 +-
> >  src/util/u_vector.c   | 98 ++
> +
> >  src/util/u_vector.h   | 85 
> >  3 files changed, 186 insertions(+), 1 deletion(-)
> >  create mode 100644 src/util/u_vector.c
> >  create mode 100644 src/util/u_vector.h
> >
> > diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
> > index 8b17bcf..b7b1e91 100644
> > --- a/src/util/Makefile.sources
> > +++ b/src/util/Makefile.sources
> > @@ -35,7 +35,9 @@ MESA_UTIL_FILES :=  \
> >   strtod.h \
> >   texcompress_rgtc_tmp.h \
> >   u_atomic.h \
> > - u_endian.h
> > + u_endian.h \
> > + u_vector.c \
> > + u_vector.h
> >
> >  MESA_UTIL_GENERATED_FILES = \
> >   format_srgb.c
> > diff --git a/src/util/u_vector.c b/src/util/u_vector.c
> > new file mode 100644
> > index 000..37c4245
> > --- /dev/null
> > +++ b/src/util/u_vector.c
> > @@ -0,0 +1,98 @@
> > +/*
> > + * Copyright © 2015 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> obtaining a
> > + * copy of this software and associated documentation files (the
> "Software"),
> > + * to deal in the Software without restriction, including without
> limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the
> next
> > + * paragraph) shall be included in all copies or substantial portions
> of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +#include "util/u_vector.h"
> > +
> > +int
> > +u_vector_init(struct u_vector *vector, uint32_t element_size, uint32_t
> size)
> > +{
> > +   assert(util_is_power_of_two(size));
> > +   assert(element_size < size && util_is_power_of_two(element_size));
> > +
> > +   vector->head = 0;
> > +   vector->tail = 0;
> > +   vector->element_size = element_size;
> > +   vector->size = size;
> > +   vector->data = malloc(size);
> > +
> > +   return vector->data != NULL;
> > +}
> > +
> > +void *
> > +u_vector_add(struct u_vector *vector)
> > +{
> > +   uint32_t offset, size, split, src_tail, dst_tail;
> > +   void *data;
> > +
> > +   if (vector->head - vector->tail == vector->size) {
> > +  size = vector->size * 2;
> > +  data = malloc(size);
> > +  if (data == NULL)
>
> simplify to (!data)
>
> > + return NULL;
> > +  src_tail = vector->tail & (vector->size - 1);
> > +  dst_tail = vector->tail & (size - 1);
> > +  if (src_tail == 0) {
> > + /* Since we know that the vector is full, this means that it's
> > +  * linear from start to end so we can do one copy.
> > +  */
> > + memcpy((char *)data + dst_tail, vector->data, vector->size);
> > +  } else {
> > + /* In this case, the vector is split into two pieces and we
> have
> > +  * to do two copies.  We have to be careful to make sure each
> > +  * piece goes to the right locations.  Thanks to the change in
> > +  * size, it may or may not still wrap around.
> > +  */
> > + split = u_align_u32(vector->tail, vector->size);
> > + assert(vector->tail <= split && split < vector->head);
> > + memcpy((char *)data + dst_tail, (char *)vector->data +
> src_tail,
> > +split - vector->tail);
> > + memcpy((char *)data + (split & (size - 1)), vector->data,
> > +vector->head - split);
> > +  }
> > +  free(vector->data);
> > +  vector->data = data;
> > +  vector->size = size;
> > +   }
> > +
> > +   assert(vector->head - vector->tail < vector->size);
> > +
> > +   offset = vector->head & (vector->size - 1);
> > +   vector->head += vector->element_size;
> > +
> > +   return (char *)vector->data + off

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

2016-10-14 Thread Andy Furniss 

Andy Furniss wrote:

Mark Thompson wrote:

On 13/10/16 08:20, Christian König wrote:

Am 13.10.2016 um 00:52 schrieb Mark Thompson:

The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.


Reviewed-by: Christian König  for the whole
series.

Do you have commit access?


I do not.  Please do push this for me once all appropriate people are
happy with it.


Seems not to regress anything, but there are still differences vs
gstreamer.

I guess the poc fix now allows JM decoder not to bail, but that allows
me to see some other issue around I frames. I haven't had time too look
properly why, but guessing it could be that avconv sends
desc.h264enc.gop_size
every I frame, but gst just once.


Looking more it seems to be because avconv is using pic number 0 to 30
gst 0 to 29 and libx264 0 to 15 then 0 to 13 so avconv doesn't reset to
0 on an IDR frame for gop 30.




I don't know if you'll even see this on bonaire as my tonga possibly
hits different code - I mean in src/gallium/drivers/radeon/ there is
radeon_vce_40_2_2.c
radeon_vce_50.c
radeon_vce_52.c
and maybe these are used depending on vce firmware version and do
different things for different h/w.

The issue I see with JM is shown below - the file seems to play OK.
There may be another (I guess pre-existing) issue around 1080/1088
affecting transcoding with both avconv and gst, but one thing at a
time.

This is with -g 30 and doesn't happen with gstreamer.

--
   Frame  POC  Pic#   QPSnrY SnrU SnrV   Y:U:V Time(ms)
--
0(IDR)0 033 4:2:0  90
0( P )1 129 4:2:0  57
1( P )2 229 4:2:0  55
1( P )3 328 4:2:0  57
2( P )4 428 4:2:0  59
2( P )5 528 4:2:0  57

snip

00014( P )   292923 4:2:0  70
00015( P )   303024 4:2:0  66
0(IDR)   -1 023 4:2:0 129
0( P )0 124 4:2:0  59
0( P )1 225 4:2:0  56
1( P )2 325 4:2:0  58
1( P )3 425 4:2:0  57

snip
00014( P )   282926 4:2:0  59
00014( P )   293024 4:2:0  65
-0001(IDR)   -2 024 4:2:0 129
0( P )   -1 125 4:2:0  59
0( P )0 225 4:2:0  58
0( P )1 325 4:2:0  59

snip
00013( P )   272924 4:2:0  65
00014( P )   283024 4:2:0  67
-0001(IDR)   -3 024 4:2:0 130
-0001( P )   -2 125 4:2:0  59
0( P )   -1 225 4:2:0  58
0( P )0 325 4:2:0  58
0( P )1 425 4:2:0  57






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

Re: [Mesa-dev] [PATCH] anv: fix enumeration of properties

2016-10-14 Thread Emil Velikov 
On 6 October 2016 at 14:12, Emil Velikov  wrote:
> From: Emil Velikov 
>
> Driver should enumerate only up-to min2(num_available, num_requested)
> properties and return VK_INCOMPLETE if the # of requested props is
> smaller than the ones available.
>
> Presently we assert out in such cases.
>
> Inspired by a similar fix for RADV.
>
> Should fix: dEQP-VK.api.info.device.extensions
> Signed-off-by: Emil Velikov 
> ---
>  src/intel/vulkan/anv_device.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
> index c7b9979..497bf9f 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -1003,15 +1003,19 @@ VkResult anv_EnumerateInstanceExtensionProperties(
>  uint32_t*   pPropertyCount,
>  VkExtensionProperties*  pProperties)
>  {
> +   unsigned i;
> +
> if (pProperties == NULL) {
>*pPropertyCount = ARRAY_SIZE(global_extensions);
>return VK_SUCCESS;
> }
>
> -   assert(*pPropertyCount >= ARRAY_SIZE(global_extensions));
> +   for (i = 0; i < MIN2(*pPropertyCount, ARRAY_SIZE(global_extensions)); i++)
> +  memcpy(&pProperties[i], &global_extensions[i], 
> sizeof(VkExtensionProperties));
>
> -   *pPropertyCount = ARRAY_SIZE(global_extensions);
> -   memcpy(pProperties, global_extensions, sizeof(global_extensions));
> +   *pPropertyCount = i;
> +   if (i < ARRAY_SIZE(global_extensions))
> +  return VK_INCOMPLETE;
>
> return VK_SUCCESS;
>  }
> @@ -1022,15 +1026,19 @@ VkResult anv_EnumerateDeviceExtensionProperties(
>  uint32_t*   pPropertyCount,
>  VkExtensionProperties*  pProperties)
>  {
> +   unsigned i;
> +
> if (pProperties == NULL) {
>*pPropertyCount = ARRAY_SIZE(device_extensions);
>return VK_SUCCESS;
> }
>
> -   assert(*pPropertyCount >= ARRAY_SIZE(device_extensions));
> +   for (i = 0; i < MIN2(*pPropertyCount, ARRAY_SIZE(device_extensions)); i++)
> +  memcpy(&pProperties[i], &device_extensions[i], 
> sizeof(VkExtensionProperties));
>
> -   *pPropertyCount = ARRAY_SIZE(device_extensions);
> -   memcpy(pProperties, device_extensions, sizeof(device_extensions));
> +   *pPropertyCount = i;
> +   if (i < ARRAY_SIZE(device_extensions))
> +  return VK_INCOMPLETE;
>
> return VK_SUCCESS;
>  }
> --
Humble ping anyone ?

Note: the equivalent RADV patch does not use MIN2, thus it can cause
information leak when pPropertyCount > ARRAY_SIZE(device_extensions).

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

Re: [Mesa-dev] [PATCH] mesa_glinterop: allow building without X and related headers

2016-10-14 Thread Emil Velikov 
On 12 October 2016 at 22:19, Vinson Lee  wrote:

> Builds okay with this patch for me.
>
Smashing. Thanks for the testing gents !

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

Re: [Mesa-dev] [PATCH 1/5] st/va: Return more useful config attributes

2016-10-14 Thread Christian König 

Am 13.10.2016 um 11:06 schrieb Mark Thompson:

On 13/10/16 08:20, Christian König wrote:

Am 13.10.2016 um 00:52 schrieb Mark Thompson:

The encoder attributes are needed for a user of the encoder to be
able to configure it sensibly without internal knowledge.

Reviewed-by: Christian König  for the whole series.

Do you have commit access?

I do not.  Please do push this for me once all appropriate people are happy 
with it.


I'm happy with it, so that should be enough. I've just pushed the 
patches upstream.


Thanks for the help,
Christian.



Thanks,

- Mark



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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-14 Thread Emil Velikov 
On 14 October 2016 at 09:45, Michel Dänzer  wrote:
> On 14/10/16 05:14 PM, Emil Velikov wrote:
>> On 14 October 2016 at 01:45, Michel Dänzer  wrote:
>>> On 13/10/16 07:14 PM, Emil Velikov wrote:
 On 13 October 2016 at 04:07, Michel Dänzer  wrote:
> On 13/10/16 03:37 AM, Tobias Droste wrote:
>> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:

 +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
 +LLVM_VERSION_REQUIRED_R600=3.6.0
 +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>>>
>>> There's a small related gotcha: as-is at build time we get the
>>> different codepaths thus, as people build against shared LLVM (hello
>>> Archlinux, I'm looking at you) and update their LLVM without
>>> rebuilding mesa (Arch I'm looking at you again) things go funny.
>
> What exactly happened there? LLVM upstream generates shared libraries
> named libLLVM-..so*, so it shouldn't be possible for a
> simple LLVM package update to break Mesa, unless Arch did something
> really stupid.
>
 The issue is not specific to Arch, but anyone who links against shared 
 LLVM.

 Here is another take on it:
 At least swr and r600/radeonsi depend at _build_ time on the _patch_
 version of LLVM. The latter of which is not part of the DSO name. Thus
 at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
 "3.9.x" codepath even though you are be using "3.9.y" LLVM.
>>>
>>> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>>>
>>> Debian doesn't automatically recompile Mesa in such cases either, and I
>>> haven't seen any problems there because of that.
>>>
>>> So, what exactly was the problem?
>>>
>> Just grep through for LLVM_.*PATCH and you'll see it. Portable code
>> should not check that at compile time.
>
> This is getting a bit annoying... Please explicitly say what you think
> is a problem, especially after being asked to do so multiple times.
>
AFAICT picking on like an old bat can be annoying, so I've tried to avoid it.
Regardless, as per your request:

* src/gallium/drivers/radeon/r600_pipe_common.c
No actual bug, yet misleading.

* src/gallium/drivers/radeonsi/si_pipe.c
Update to 3.6.2+, still missing tessellation unless you rebuild mesa.
The latter bug in itself.
Downgrade - TBD, depending on the (fixed) LLVM bugs.

* src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
Analogous to above - s/missing tessellation/VI+ chips not working/.

Reading back the wrong version (as per r600_pipe_common.c) combined
with tess bugs/missing VI+ support leads to some wtf moments, since
the rebuild requirement isn't obvious.

src/gallium/drivers/swr/rasterizer/jitter/scripts/gen_llvm_ir_macros.py
Reversed argument order. No issues if the whole things gets inlined
into mesa, fun experience otherwise.

Using a runtime check for shared libs and compile/run-time one for
static ones the "better" choice, imho. That or just bump the
requirement ?

Just pointing out what seems odd/wrong, if I'm the only one so be it :-\

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

Re: [Mesa-dev] [PATCH v3] doc/features.txt: factor out i965/hsw+ & radeonsi as GL45 complete

2016-10-14 Thread Eero Tamminen 

Hi,

On 14.10.2016 07:35, Edward O'Callaghan wrote:

V2. add i965/hsw+ to list
V3. rebased on master.

Signed-off-by: Edward O'Callaghan 
---
 docs/features.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/features.txt b/docs/features.txt
index 0d6c16a..acea0cf 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -206,19 +206,19 @@ GL 4.4, GLSL 4.40 -- all DONE: i965/gen8+, nvc0, radeonsi
   GL_ARB_texture_stencil8   DONE (i965/hsw+, nv50, 
r600, llvmpipe, softpipe, swr)
   GL_ARB_vertex_type_10f_11f_11f_revDONE (i965, nv50, 
r600, llvmpipe, softpipe, swr)

-GL 4.5, GLSL 4.50 -- all DONE: nvc0
+GL 4.5, GLSL 4.50 -- all DONE: i965/hsw+, nvc0, radeonsi


Earlier GL versions are still listed as gen8+ (until HSW fp64
support goes in), so GL 4.5 is also.


-  GL_ARB_ES3_1_compatibilityDONE (i965/hsw+, 
radeonsi)
-  GL_ARB_clip_control   DONE (i965, nv50, 
r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_conditional_render_invertedDONE (i965, nv50, 
r600, radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_cull_distance  DONE (i965, nv50, 
radeonsi, llvmpipe, softpipe, swr)
-  GL_ARB_derivative_control DONE (i965, nv50, 
r600, radeonsi)
+  GL_ARB_ES3_1_compatibilityDONE
+  GL_ARB_clip_control   DONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_conditional_render_invertedDONE (nv50, r600, 
llvmpipe, softpipe, swr)
+  GL_ARB_cull_distance  DONE (nv50, llvmpipe, 
softpipe, swr)
+  GL_ARB_derivative_control DONE (nv50, r600)


I think that for now, only relevant change is just adding i965/gen8+
to the GL version line, as information about extensions working with
earlier Intel versions is still relevant.


- Eero


   GL_ARB_direct_state_accessDONE (all drivers)
   GL_ARB_get_texture_sub_image  DONE (all drivers)
-  GL_ARB_shader_texture_image_samples   DONE (i965, nv50, 
r600, radeonsi)
-  GL_ARB_texture_barrierDONE (i965, nv50, 
r600, radeonsi)
+  GL_ARB_shader_texture_image_samples   DONE (nv50, r600)
+  GL_ARB_texture_barrierDONE (nv50, r600)
   GL_KHR_context_flush_control  DONE (all - but needs 
GLX/EGL extension to be useful)
-  GL_KHR_robustness DONE (i965, radeonsi)
+  GL_KHR_robustness DONE
   GL_EXT_shader_integer_mix DONE (all drivers that 
support GLSL)

 These are the extensions cherry-picked to make GLES 3.1



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

Re: [Mesa-dev] [Mesa-stable] [PATCH] glx: Perform check for valid fbconfig against proper X-Screen.

2016-10-14 Thread Emil Velikov 
On 12 October 2016 at 18:40, Emil Velikov  wrote:
> On 11 October 2016 at 19:42, Mario Kleiner  wrote:

>> Tested to fix context creation failure on a dual-x-screen setup.
>>
>> Signed-off-by: Mario Kleiner 
>> Cc: "11.2 12.0" 
> Reviewed-by: Emil Velikov 
>
... and pushed to master.

Mario, can you skim through this list [1] and let me know if any the
patches is outstanding or I can "close" them.

Thanks
Emil
[1] 
https://patchwork.freedesktop.org/project/mesa/patches/?submitter=14956&state=&q=&archive=&delegate=
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/6] EGL_MESA_platform_surfaceless (v2)

2016-10-14 Thread Emil Velikov 
On 13 October 2016 at 23:06, Chad Versace  wrote:
> Mesa's EGL has supported Chrome OS's "surfaceless" platform for many
> months, but the behavior of that platform has never been documented.
> Here's my attempt to fix that.
>
> I've already committed the draft extension spec into the private Khronos
> registry. After these patches land in master, I plan to publish the spec
> in the *public* Khronos registry then delete Mesa's copy.
>
Smashing, thanks for expanding the cope to cover EGL 1.4/EGL_EXT_platform_base.

> See the piglit list for tests.
>
> Branches:
> - mesa: 
> http://git.kiwitree.net/cgit/~chadv/mesa/log/?h=review/EGL_MESA_platform_surfaceless-v02
> - piglit: 
> http://git.kiwitree.net/cgit/~chadv/piglit/log/?h=review/EGL_MESA_platform_surfaceless-v01
>
> Chad Versace (6):
>   docs: Add EGL_MESA_platform_surfaceless.txt (v2)
>   egl: Don't advertise unsupported platform extensions
Cc: mesa-sta...@lists.freedesktop.org on this one ?

The lot looks great!
Reviewed-by: Emil Velikov 

Planned branch point is late tonight so, barring any fundamental
issues I would suggest pushing the lot beforehand.

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

Re: [Mesa-dev] [PATCH v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-14 Thread Michel Dänzer 
On 14/10/16 05:14 PM, Emil Velikov wrote:
> On 14 October 2016 at 01:45, Michel Dänzer  wrote:
>> On 13/10/16 07:14 PM, Emil Velikov wrote:
>>> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
 On 13/10/16 03:37 AM, Tobias Droste wrote:
> Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>>>
>>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>>> +LLVM_VERSION_REQUIRED_R600=3.6.0
>>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>>
>> There's a small related gotcha: as-is at build time we get the
>> different codepaths thus, as people build against shared LLVM (hello
>> Archlinux, I'm looking at you) and update their LLVM without
>> rebuilding mesa (Arch I'm looking at you again) things go funny.

 What exactly happened there? LLVM upstream generates shared libraries
 named libLLVM-..so*, so it shouldn't be possible for a
 simple LLVM package update to break Mesa, unless Arch did something
 really stupid.

>>> The issue is not specific to Arch, but anyone who links against shared LLVM.
>>>
>>> Here is another take on it:
>>> At least swr and r600/radeonsi depend at _build_ time on the _patch_
>>> version of LLVM. The latter of which is not part of the DSO name. Thus
>>> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
>>> "3.9.x" codepath even though you are be using "3.9.y" LLVM.
>>
>> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>>
>> Debian doesn't automatically recompile Mesa in such cases either, and I
>> haven't seen any problems there because of that.
>>
>> So, what exactly was the problem?
>>
> Just grep through for LLVM_.*PATCH and you'll see it. Portable code
> should not check that at compile time.

This is getting a bit annoying... Please explicitly say what you think
is a problem, especially after being asked to do so multiple times.

I'm not sure about the swr instance, but the radeonsi instances are
fine. The worst that can happen is that the code uses the path for an
older patchlevel, even though the LLVM shared library used at runtime
actually has a newer patchlevel. I.e. the worst case is non-optimal
behaviour, not buggy behaviour.


>> Tl;Dr; We really want to enable static linking by default and prod
>> distros to use it.
>
> I'm all in favor of statically linking LLVM (that's the way I'm doing 
> this on
> my pc).
> I think the only reason this is not done is because people (also here on 
> the
> list) don't want any static linkg of external libraries because of size or
> whatever.
> So changing the default to static is easy, but I doubt it will make 
> everyone
> happy ;-)

 Indeed, it'd probably make many distro packagers unhappy, because
 they'll just have to re-enable shared linking, because packaging
 policies generally strongly discourage if not outright forbid static
 linking.

>>> The toggle is there and is not going away, afaict. If people are going
>>> to get upset that the default does not meet their policy... just
>>> toggle and get on with other things ;-)
>>
>> The question is if it makes sense for the default to be different from
>> what the majority of users end up using. It doesn't to me.
>>
> This might be better answered once you see what I mean above ;-)

I'm afraid you lost me here.


-- 
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 v3 25/25] configure.ac: Add required LLVM versions to the top

2016-10-14 Thread Emil Velikov 
On 14 October 2016 at 01:45, Michel Dänzer  wrote:
> On 13/10/16 07:14 PM, Emil Velikov wrote:
>> On 13 October 2016 at 04:07, Michel Dänzer  wrote:
>>> On 13/10/16 03:37 AM, Tobias Droste wrote:
 Am Mittwoch, 12. Oktober 2016, 11:53:50 CEST schrieb Emil Velikov:
>>
>> +LLVM_VERSION_REQUIRED_OPENCL=3.6.0
>> +LLVM_VERSION_REQUIRED_R600=3.6.0
>> +LLVM_VERSION_REQUIRED_RADEONSI=3.6.0
>
> There's a small related gotcha: as-is at build time we get the
> different codepaths thus, as people build against shared LLVM (hello
> Archlinux, I'm looking at you) and update their LLVM without
> rebuilding mesa (Arch I'm looking at you again) things go funny.
>>>
>>> What exactly happened there? LLVM upstream generates shared libraries
>>> named libLLVM-..so*, so it shouldn't be possible for a
>>> simple LLVM package update to break Mesa, unless Arch did something
>>> really stupid.
>>>
>> The issue is not specific to Arch, but anyone who links against shared LLVM.
>>
>> Here is another take on it:
>> At least swr and r600/radeonsi depend at _build_ time on the _patch_
>> version of LLVM. The latter of which is not part of the DSO name. Thus
>> at runtime as you change your LLVM (3.9.x>3.9.y) you'll execute the
>> "3.9.x" codepath even though you are be using "3.9.y" LLVM.
>
> That should be fine, since 3.9.y is backwards compatible with 3.9.x.
>
> Debian doesn't automatically recompile Mesa in such cases either, and I
> haven't seen any problems there because of that.
>
> So, what exactly was the problem?
>
Just grep through for LLVM_.*PATCH and you'll see it. Portable code
should not check that at compile time.

> Tl;Dr; We really want to enable static linking by default and prod
> distros to use it.

 I'm all in favor of statically linking LLVM (that's the way I'm doing this 
 on
 my pc).
 I think the only reason this is not done is because people (also here on 
 the
 list) don't want any static linkg of external libraries because of size or
 whatever.
 So changing the default to static is easy, but I doubt it will make 
 everyone
 happy ;-)
>>>
>>> Indeed, it'd probably make many distro packagers unhappy, because
>>> they'll just have to re-enable shared linking, because packaging
>>> policies generally strongly discourage if not outright forbid static
>>> linking.
>>>
>> The toggle is there and is not going away, afaict. If people are going
>> to get upset that the default does not meet their policy... just
>> toggle and get on with other things ;-)
>
> The question is if it makes sense for the default to be different from
> what the majority of users end up using. It doesn't to me.
>
This might be better answered once you see what I mean above ;-)

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