Re: [Mesa-dev] [PATCH 3/3] intel/compiler: implement more algebraic optimizations

2019-03-03 Thread Iago Toral
On Thu, 2019-02-28 at 16:20 -0800, Ian Romanick wrote:
> On 2/28/19 4:47 AM, Iago Toral wrote:
> > On Wed, 2019-02-27 at 17:04 -0800, Ian Romanick wrote:
> > > On 2/27/19 4:45 AM, Iago Toral Quiroga wrote:
> > > > Now that we propagate constants to the first source of 2src
> > > > instructions we
> > > > see more opportunities of constant folding in the backend.
> > > > 
> > > > Shader-db results on KBL:
> > > > 
> > > > total instructions in shared programs: 14965607 -> 14855983 (-
> > > > 0.73%)
> > > > instructions in affected programs: 3988102 -> 3878478 (-2.75%)
> > > > helped: 14292
> > > > HURT: 59
> > > > 
> > > > total cycles in shared programs: 344324295 -> 340656008 (-
> > > > 1.07%)
> > > > cycles in affected programs: 247527740 -> 243859453 (-1.48%)
> > > > helped: 14056
> > > > HURT: 3314
> > > > 
> > > > total loops in shared programs: 4283 -> 4283 (0.00%)
> > > > loops in affected programs: 0 -> 0
> > > > helped: 0
> > > > HURT: 0
> > > > 
> > > > total spills in shared programs: 27812 -> 24350 (-12.45%)
> > > > spills in affected programs: 24921 -> 21459 (-13.89%)
> > > > helped: 345
> > > > HURT: 19
> > > > 
> > > > total fills in shared programs: 24173 -> 22032 (-8.86%)
> > > > fills in affected programs: 21124 -> 18983 (-10.14%)
> > > > helped: 355
> > > > HURT: 25
> > > 
> > > Ignore my previous questions about nir_opt_constant_folding after
> > > nir_opt_algebraic_late.  I had done that because I added a bunch
> > > of
> > > things to nir_opt_algebraic_late that created my constant folding
> > > opportunities.
> > > 
> > > This is the combined changes for this patch and the previous
> > > patch.  For
> > > this patch alone, I got:
> > > 
> > > total instructions in shared programs: 15306213 -> 15221518 (-
> > > 0.55%)
> > > instructions in affected programs: 2911451 -> 2826756 (-2.91%)
> > > helped: 13121
> > > HURT: 44
> > > helped stats (abs) min: 1 max: 51 x̄: 6.66 x̃: 6
> > > helped stats (rel) min: <.01% max: 16.67% x̄: 4.27% x̃: 3.30%
> > > HURT stats (abs)   min: 3 max: 453 x̄: 61.16 x̃: 5
> > > HURT stats (rel)   min: 0.20% max: 151.00% x̄: 31.57% x̃: 19.23%
> > > 95% mean confidence interval for instructions value: -6.61 -6.26
> > > 95% mean confidence interval for instructions %-change: -4.23%
> > > -4.07%
> > > Instructions are helped.
> > > 
> > > total cycles in shared programs: 375419164 -> 372829148 (-0.69%)
> > > cycles in affected programs: 146769299 -> 144179283 (-1.76%)
> > > helped: 10992
> > > HURT: 1833
> > > helped stats (abs) min: 1 max: 56127 x̄: 250.29 x̃: 18
> > > helped stats (rel) min: <.01% max: 40.52% x̄: 3.11% x̃: 2.58%
> > > HURT stats (abs)   min: 1 max: 1718 x̄: 87.93 x̃: 42
> > > HURT stats (rel)   min: <.01% max: 139.33% x̄: 7.74% x̃: 3.08%
> > > 95% mean confidence interval for cycles value: -248.21 -155.69
> > > 95% mean confidence interval for cycles %-change: -1.67% -1.44%
> > > Cycles are helped.
> > > 
> > > total spills in shared programs: 28828 -> 2 (0.21%)
> > > spills in affected programs: 2037 -> 2097 (2.95%)
> > > helped: 0
> > > HURT: 24
> > > 
> > > total fills in shared programs: 35542 -> 35639 (0.27%)
> > > fills in affected programs: 3078 -> 3175 (3.15%)
> > > helped: 2
> > > HURT: 26
> > > 
> > > I decided to look at some of the hurt shaders... it looks like
> > > some
> > > of
> > > the Unigine geometry shaders really took a beating (+150%
> > > instructions).
> > > Note the "max" in the "instructions in affected programs" above.
> > 
> > I am seeing quite different results on my KBL laptop:
> > 
> > total instructions in shared programs: 14945933 -> 14858158 (-
> > 0.59%)
> > instructions in affected programs: 2842901 -> 2755126 (-3.09%)
> > helped: 13196
> > HURT: 5
> > 
> > instructions HURT:   shaders/closed/steam/deus-ex-mankind-
> > divided/274.shader_test CS SIMD8: 1535 -> 1538 (0.20%)
> > instructions HURT:   shaders/closed/steam/deus-ex-mankind-
> > divided/184.shader_test CS SIMD8: 1535 -> 1538 (0.20%)
> > instructions HURT:   shaders/dolphin/ubershaders/147.shader_test FS
> > SIMD8: 3481 -> 3491 (0.29%)
> > instructions HURT:   shaders/dolphin/ubershaders/156.shader_test FS
> > SIMD8: 3465 -> 3475 (0.29%)
> > instructions HURT:   shaders/dolphin/ubershaders/138.shader_test FS
> > SIMD8: 3465 -> 3475 (0.29%)
> > 
> > Did you test on a different gen? Can you paste here the paths of
> > some
> > of the GS shaders where you see the big regressions so I can verify
> > I
> > have them in my shader-db?
> > 
> > Also, how did you test this patch exactly? When I was going to
> > capture
> > the reference shader-db results for patch 2 in this series so I
> > could
> > extract the results for patch 3 by comparing against it, I noticed
> > that
> > patch 2 would create constant folding scenarios (for example for
> > ADD
> > and MUL) that, before this patch, would hit an assertion in the
> > driver
> > since the algebraic pass only expects to find these opportunities
> > for F
> > types and will assert on that, so I guess you 

Re: [Mesa-dev] [PATCH v4 34/40] intel/compiler: validate region restrictions for half-float conversions

2019-03-03 Thread Iago Toral
On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> Iago Toral  writes:
> 
> > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > > Iago Toral  writes:
> > > 
> > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
> > > > > Iago Toral  writes:
> > > > > 
> > > > > > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez wrote:
> > > > > > > Iago Toral Quiroga  writes:
> > > > > > > 
> > > > > > > > ---
> > > > > > > >  src/intel/compiler/brw_eu_validate.c|  64
> > > > > > > > -
> > > > > > > >  src/intel/compiler/test_eu_validate.cpp | 122
> > > > > > > > 
> > > > > > > >  2 files changed, 185 insertions(+), 1 deletion(-)
> > > > > > > > 
> > > > > > > > diff --git a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > index 000a05cb6ac..203641fecb9 100644
> > > > > > > > --- a/src/intel/compiler/brw_eu_validate.c
> > > > > > > > +++ b/src/intel/compiler/brw_eu_validate.c
> > > > > > > > @@ -531,7 +531,69 @@
> > > > > > > > general_restrictions_based_on_operand_types(const
> > > > > > > > struct
> > > > > > > > gen_device_info *devinf
> > > > > > > > exec_type_size == 8 && dst_type_size == 4)
> > > > > > > >dst_type_size = 8;
> > > > > > > >  
> > > > > > > > -   if (exec_type_size > dst_type_size) {
> > > > > > > > +   /* From the BDW+ PRM:
> > > > > > > > +*
> > > > > > > > +*"There is no direct conversion from HF to DF
> > > > > > > > or
> > > > > > > > DF to
> > > > > > > > HF.
> > > > > > > > +* There is no direct conversion from HF to
> > > > > > > > Q/UQ or
> > > > > > > > Q/UQ to
> > > > > > > > HF."
> > > > > > > > +*/
> > > > > > > > +   enum brw_reg_type src0_type =
> > > > > > > > brw_inst_src0_type(devinfo,
> > > > > > > > inst);
> > > > > > > > +   ERROR_IF(brw_inst_opcode(devinfo, inst) ==
> > > > > > > > BRW_OPCODE_MOV
> > > > > > > > &&
> > > > > > > 
> > > > > > > Why is only the MOV instruction handled here and
> > > > > > > below?  Aren't
> > > > > > > other
> > > > > > > instructions able to do implicit conversions?  Probably
> > > > > > > means
> > > > > > > you
> > > > > > > need
> > > > > > > to deal with two sources rather than one.
> > > > > > 
> > > > > > This comes from the programming notes of the MOV
> > > > > > instruction
> > > > > > (Volume
> > > > > > 2a, Command Reference - Instructions - MOV), so it is
> > > > > > described
> > > > > > specifically for the MOV instruction. I should probably
> > > > > > have
> > > > > > made
> > > > > > this
> > > > > > clear in the comment.
> > > > > > 
> > > > > 
> > > > > Maybe the one above is specified in the MOV page only,
> > > > > probably
> > > > > due
> > > > > to
> > > > > an oversight (If these restrictions were really specific to
> > > > > the
> > > > > MOV
> > > > > instruction, what would prevent you from implementing such
> > > > > conversions
> > > > > through a different instruction?  E.g. "ADD dst:df, src:hf,
> > > > > 0"
> > > > > which
> > > > > would be substantially more efficient than what you're doing
> > > > > in
> > > > > PATCH
> > > > > 02)
> > > > 
> > > > Instructions that take HF can only be strictly HF or mix F and
> > > > HF
> > > > (mixed mode float), with MOV being the only exception. That
> > > > means
> > > > that
> > > > any instruction like the one you use above are invalid. Maybe
> > > > we
> > > > should
> > > > validate explicitly that instructions that use HF are strictly
> > > > HF
> > > > or
> > > > mixed-float mode only?
> > > > 
> > > 
> > > So you're acknowledging that the conversions checked above are
> > > illegal
> > > whether the instruction is a MOV or something else.  Where are we
> > > preventing instructions other than MOV with such conversions from
> > > being
> > > accepted by the validator?
> > 
> > We aren't, because the validator is not checking, in general, for
> > accepted type combinations for specific instructions anywhere as
> > far as
> > I can see.
> 
> Luckily these type conversion restrictions aren't really specific to
> any
> instruction AFAICT, even though they only seem to be mentioned
> explicitly for the MOV instruction...
> 
> > If we want to start doing this with HF conversions specifically, I
> > guess it is fine, but in case it is not clear, I think it won't
> > bring
> > any immediate benefits with the VK_KHR_shader_float16_int8
> > implementation since this series only ever emits conversions
> > involving
> > HF operands via MOV instructions,
> 
> Yes, I can see that's the intention of this series, but how can you
> make
> sure that nothing in the optimizer is breaking your assumption if you
> don't add some validator code to verify the claim of your last
> paragraph?
> 
> > which is why I thought that validating that no direct MOV
> > conversions
> > from DF/Q types ever happen was useful, since we have code in the
> > driver to handle this scenario.
> > 
> > [...]
> > > 
> > > I still don't 

Re: [Mesa-dev] [PATCH 2/2] android: anv: fix libexpat shared dependency

2019-03-03 Thread Tapani Pälli

Never saw this error but change looks correct,

Reviewed-by: Tapani Pälli 

On 3/3/19 9:57 PM, Mauro Rossi wrote:

Fixes undefined reference building errors for XML_* functions

Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 2e99ac6294..c9bce50c78 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -318,7 +318,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler \
libmesa_anv_entrypoints
  
-LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libz libsync liblog

+LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libexpat libz libsync liblog
  
  include $(MESA_COMMON_MK)

  include $(BUILD_SHARED_LIBRARY)


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

Re: [Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

2019-03-03 Thread Tapani Pälli



On 3/3/19 9:57 PM, Mauro Rossi wrote:

Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies


rebuils -> rebuilds


Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
  src/intel/Android.vulkan.mk | 38 +++--
  1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
  include $(LOCAL_PATH)/Makefile.sources
  
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py

-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
  
  VULKAN_COMMON_INCLUDES := \

$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
  
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c

-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)
  
  LOCAL_EXPORT_C_INCLUDE_DIRS := \

  $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
  LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
  
-$(intermediates)/vulkan/anv_entrypoints.c:

+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--xml $(MESA_TOP)/src/vulkan/registry/vk.xml \


This one should be $(VULKAN_API_XML) as well


--outdir $(dir $@)
  
-$(intermediates)/vulkan/anv_extensions.c:

+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-c $@
  
-$(intermediates)/vulkan/anv_extensions.h:

+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-h $@
  
  LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)



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

Re: [Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h

2019-03-03 Thread Tapani Pälli

Hi;

On 3/3/19 10:10 PM, Mauro Rossi wrote:

Necessary to avoid building error in Android,
due to 'compiler/glsl/float64_glsl.h' file not found

Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir drivers")
Signed-off-by: Mauro Rossi 
---
  src/mesa/Android.libmesa_st_mesa.mk   | 1 +
  src/mesa/Makefile.sources | 1 +
  src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
  3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/Android.libmesa_st_mesa.mk 
b/src/mesa/Android.libmesa_st_mesa.mk
index ddfd03059c..c5b16cad34 100644
--- a/src/mesa/Android.libmesa_st_mesa.mk
+++ b/src/mesa/Android.libmesa_st_mesa.mk
@@ -58,6 +58,7 @@ endif
  LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/mesa/main \
+   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
$(MESA_TOP)/src/compiler/nir \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 1e25f47e50..69f32c6adf 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -689,6 +689,7 @@ INCLUDE_DIRS = \
-I$(top_srcdir)/include \
-I$(top_builddir)/src \
-I$(top_srcdir)/src \
+   -I$(top_builddir)/src/compiler \
-I$(top_builddir)/src/compiler/glsl \
-I$(top_builddir)/src/compiler/nir \
-I$(top_builddir)/src/mesa \
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index a1e3b6233c..ad77b746ab 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -48,7 +48,7 @@
  #include "compiler/glsl/ir.h"
  #include "compiler/glsl/ir_optimization.h"
  #include "compiler/glsl/string_to_uint_map.h"
-#include "compiler/glsl/float64_glsl.h"
+#include "glsl/float64_glsl.h"


Looks familiar :)

https://github.com/tpalli/external-mesa/commit/ebd8581ad133206ec2b1b818e98dc4f8401af8de

Before going further though, I'd like to understand why do we have both 
'compiler/glsl/' and 'glsl/' going on. Should we rather put the 
'compiler' back in the header generation? I can't remember the full 
story behind commit c812c740e60 but that one changed this .. perhaps we 
should pull it back and have the 'compiler/', any objections to that?


Thanks;

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

[Mesa-dev] [Bug 108457] [OpenGL CTS] KHR-GL46.tessellation_shader.single.xfb_captures_data_from_correct_stage fails

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108457

Chema Casanova  changed:

   What|Removed |Added

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

--- Comment #2 from Chema Casanova  ---
Fix landed in Mesa master.

commit 4eec3a2a3652317f8e0fa97e0730c297bde8241a 
Author: Ilia Mirkin 
Date:   Fri Feb 22 01:13:39 2019 -0500

glsl: fix recording of variables for XFB in TCS shaders

This is purely for conformance, since it's not actually possible to do
XFB on TCS output varyings. However we do have to make sure we record
the names correctly, and this removes an extra level of array-ness from
the names in question.

Fixes
KHR-GL45.tessellation_shader.single.xfb_captures_data_from_correct_stage

v2: Add comment to the new program_resource_visitor::process function.
(Ilia Mirkin)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108457
Signed-off-by: Ilia Mirkin 
Cc: 19.0 
Reviewed-by: Timothy Arceri 

-- 
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 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109805

--- Comment #6 from rainbowsforthe...@gmail.com  
---
Created attachment 143517
  --> https://bugs.freedesktop.org/attachment.cgi?id=143517=edit
The Witcher 3 errors with RADV_DEBUG=zerovram,nodcc,nohiz,nofastclears

-- 
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 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109805

--- Comment #5 from rainbowsforthe...@gmail.com  
---
The Witcher 3 threw the error for me with
RADV_DEBUG=zerovram,nodcc,nohiz,nofastclears after less than five minutes.

I will attach a text file with the amdgpu errors from dmesg.

-- 
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 109822] Texture holes in simple vulkan examples.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109822

Mike Mestnik  changed:

   What|Removed |Added

 Resolution|NOTABUG |---
 Status|RESOLVED|REOPENED

--- Comment #3 from Mike Mestnik  
---
I fixed the validation warnings and the bug remains.

Here is the corrected source.
https://github.com/cheako/cheako-vulkan/blob/16b794089cbffc63e81af66ae8fcb1cd118e607c/0005texture/vulkan.c

Changes are:
sampler_info.anisotropyEnable = VK_FALSE;

image_create_info.initialLayout = VK_IMAGE_LAYOUT_PREINITIALIZED;

Applied an image memor barrier to the first run.
barriers[0].sType = VK_STRUCTURE_TYPE_IMAGE_MEMORY_BARRIER;
barriers[0].dstAccessMask = VK_ACCESS_SHADER_READ_BIT;
barriers[0].oldLayout = VK_IMAGE_LAYOUT_PREINITIALIZED;
barriers[0].newLayout = VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL;
barriers[0].image = texture_images[0];
barriers[0].subresourceRange =
(VkImageSubresourceRange){VK_IMAGE_ASPECT_COLOR_BIT, 0, 1, 0, 1};

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

[Mesa-dev] [Bug 109805] GPU hangs with error VM_CONTEXT1_PROTECTION_FAULT_STATUS

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109805

--- Comment #4 from rainbowsforthe...@gmail.com  
---
(In reply to Michel Dänzer from comment #2)
> Reassigning assuming it's using Vulkan via DXVK.

I have been able to produce the error in the past with OpenGL apps, but very
inconsistently. The only games that I know are guaranteed to cause me issues
are GTA V (specifically Online), and The Witcher 3 (specifically at 1440p).

(In reply to Samuel Pitoiset from comment #3)
> Random GPU hangs are really hard to fix.
> 
> Can you reproduce the problem with
> export RADV_DEBUG=zerovram,nodcc,nohiz,nofastclears ?
> 
> Also, LLVM 7 is quite old, I would recommend to upgrade, although VM faults
> are probably unrelated to LLVM.

I was unable to reproduce the issue in GTA Online with that. I played for
several hours and the game itself crashed, without any errors appearing in
dmesg, or any graphical corruption observed. The game did, however run poorly
and render particle effects very strangely right from the beginning, but I
assume this is expected.

I am going to try RADV_DEBUG=zerovram,nodcc,nohiz,nofastclears with The Witcher
3 at 1440p to see if I can reproduce the issue there.

-- 
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] android, autotools: st/mesa: fix location of float64_glsl.h

2019-03-03 Thread Eric Engestrom
On Sunday, 2019-03-03 21:10:50 +0100, Mauro Rossi wrote:
> Necessary to avoid building error in Android,
> due to 'compiler/glsl/float64_glsl.h' file not found
> 
> Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir 
> drivers")
> Signed-off-by: Mauro Rossi 
> ---
>  src/mesa/Android.libmesa_st_mesa.mk   | 1 +
>  src/mesa/Makefile.sources | 1 +
>  src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/Android.libmesa_st_mesa.mk 
> b/src/mesa/Android.libmesa_st_mesa.mk
> index ddfd03059c..c5b16cad34 100644
> --- a/src/mesa/Android.libmesa_st_mesa.mk
> +++ b/src/mesa/Android.libmesa_st_mesa.mk
> @@ -58,6 +58,7 @@ endif
>  LOCAL_C_INCLUDES := \
>   $(MESA_TOP)/src/mapi \
>   $(MESA_TOP)/src/mesa/main \
> + $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
>   $(MESA_TOP)/src/compiler/nir \
>   $(MESA_TOP)/src/gallium/auxiliary \
>   $(MESA_TOP)/src/gallium/include
> diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
> index 1e25f47e50..69f32c6adf 100644
> --- a/src/mesa/Makefile.sources
> +++ b/src/mesa/Makefile.sources
> @@ -689,6 +689,7 @@ INCLUDE_DIRS = \
>   -I$(top_srcdir)/include \
>   -I$(top_builddir)/src \
>   -I$(top_srcdir)/src \
> + -I$(top_builddir)/src/compiler \
>   -I$(top_builddir)/src/compiler/glsl \
>   -I$(top_builddir)/src/compiler/nir \
>   -I$(top_builddir)/src/mesa \
> diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
> b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> index a1e3b6233c..ad77b746ab 100644
> --- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> +++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
> @@ -48,7 +48,7 @@
>  #include "compiler/glsl/ir.h"
>  #include "compiler/glsl/ir_optimization.h"
>  #include "compiler/glsl/string_to_uint_map.h"
> -#include "compiler/glsl/float64_glsl.h"
> +#include "glsl/float64_glsl.h"
>  
>  static int
>  type_size(const struct glsl_type *type)
> -- 
> 2.19.1
> 

I think you'll need this to avoid breaking meson:

---8<---
diff --git a/src/mesa/meson.build b/src/mesa/meson.build
index d8a5682f6a0b84134ae7..d0edd71df09c8d23b4e3 100644
--- a/src/mesa/meson.build
+++ b/src/mesa/meson.build
@@ -736,7 +736,7 @@ libmesa_gallium = static_library(
   [files_libmesa_common, files_libmesa_gallium],
   c_args : [c_vis_args, c_msvc_compat_args],
   cpp_args : [cpp_vis_args, cpp_msvc_compat_args],
-  include_directories : [inc_common, inc_libmesa_asm, 
include_directories('main')],
+  include_directories : [inc_common, inc_compiler, inc_libmesa_asm, 
include_directories('main')],
   link_with : [libglsl, libmesa_sse41],
   dependencies : [idep_nir_headers, dep_vdpau],
   build_by_default : false,
--->8---
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109822] Texture holes in simple vulkan examples.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109822

Mike Mestnik  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

--- Comment #2 from Mike Mestnik  
---
Validation layers reported Anisotropic was true but not enabled.  Also image
layout is wrong.

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

[Mesa-dev] [PATCH] android, autotools: st/mesa: fix location of float64_glsl.h

2019-03-03 Thread Mauro Rossi
Necessary to avoid building error in Android,
due to 'compiler/glsl/float64_glsl.h' file not found

Fixes: cb4e3e3 ("st/mesa: add support for lowering fp64/int64 for nir drivers")
Signed-off-by: Mauro Rossi 
---
 src/mesa/Android.libmesa_st_mesa.mk   | 1 +
 src/mesa/Makefile.sources | 1 +
 src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/Android.libmesa_st_mesa.mk 
b/src/mesa/Android.libmesa_st_mesa.mk
index ddfd03059c..c5b16cad34 100644
--- a/src/mesa/Android.libmesa_st_mesa.mk
+++ b/src/mesa/Android.libmesa_st_mesa.mk
@@ -58,6 +58,7 @@ endif
 LOCAL_C_INCLUDES := \
$(MESA_TOP)/src/mapi \
$(MESA_TOP)/src/mesa/main \
+   $(call generated-sources-dir-for,STATIC_LIBRARIES,libmesa_glsl,,) \
$(MESA_TOP)/src/compiler/nir \
$(MESA_TOP)/src/gallium/auxiliary \
$(MESA_TOP)/src/gallium/include
diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index 1e25f47e50..69f32c6adf 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -689,6 +689,7 @@ INCLUDE_DIRS = \
-I$(top_srcdir)/include \
-I$(top_builddir)/src \
-I$(top_srcdir)/src \
+   -I$(top_builddir)/src/compiler \
-I$(top_builddir)/src/compiler/glsl \
-I$(top_builddir)/src/compiler/nir \
-I$(top_builddir)/src/mesa \
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp 
b/src/mesa/state_tracker/st_glsl_to_nir.cpp
index a1e3b6233c..ad77b746ab 100644
--- a/src/mesa/state_tracker/st_glsl_to_nir.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_nir.cpp
@@ -48,7 +48,7 @@
 #include "compiler/glsl/ir.h"
 #include "compiler/glsl/ir_optimization.h"
 #include "compiler/glsl/string_to_uint_map.h"
-#include "compiler/glsl/float64_glsl.h"
+#include "glsl/float64_glsl.h"
 
 static int
 type_size(const struct glsl_type *type)
-- 
2.19.1

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

[Mesa-dev] [PATCH 1/2] android: anv: fix generated files depedencies

2019-03-03 Thread Mauro Rossi
Fix anv_extrypoints.{c,h} and anv_extensions.{c,h} missing dependencies
Rename the variable labels according to targets and python scripts
Align the building rules as per Automake for simplification

Fixes building errors during rebuils due to missing dependencies

Fixes: 9a508b7 ("android: anv/extensions: fix generated sources build")
Fixes: dd088d4bec7 ("anv/extensions: Generate a header file with extension 
tables")
Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
 src/intel/Android.vulkan.mk | 38 +++--
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 04c9d5b3e4..2e99ac6294 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -23,9 +23,10 @@ LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 include $(LOCAL_PATH)/Makefile.sources
 
-VK_ENTRYPOINTS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
-
-VK_EXTENSIONS_SCRIPT := $(MESA_PYTHON2) 
$(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_ENTRYPOINTS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_entrypoints_gen.py
+ANV_EXTENSIONS_GEN_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions_gen.py
+ANV_EXTENSIONS_SCRIPT := $(LOCAL_PATH)/vulkan/anv_extensions.py
+VULKAN_API_XML := $(MESA_TOP)/src/vulkan/registry/vk.xml
 
 VULKAN_COMMON_INCLUDES := \
$(MESA_TOP)/include \
@@ -64,10 +65,13 @@ $(intermediates)/vulkan/dummy.c:
@echo "Gen Dummy: $(PRIVATE_MODULE) <= $(notdir $(@))"
$(hide) touch $@
 
-$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c
-   $(VK_ENTRYPOINTS_SCRIPT) \
+$(intermediates)/vulkan/anv_entrypoints.h: $(intermediates)/vulkan/dummy.c \
+  $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--outdir $(dir $@) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml
+   --xml $(VULKAN_API_XML)
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := \
 $(intermediates)
@@ -241,22 +245,28 @@ LOCAL_GENERATED_SOURCES += 
$(intermediates)/vulkan/anv_entrypoints.c
 LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.c
 LOCAL_GENERATED_SOURCES += $(intermediates)/vulkan/anv_extensions.h
 
-$(intermediates)/vulkan/anv_entrypoints.c:
+$(intermediates)/vulkan/anv_entrypoints.c: $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_ENTRYPOINTS_SCRIPT) \
+   $(MESA_PYTHON2) $(ANV_ENTRYPOINTS_GEN_SCRIPT) \
--xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
--outdir $(dir $@)
 
-$(intermediates)/vulkan/anv_extensions.c:
+$(intermediates)/vulkan/anv_extensions.c: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+ $(ANV_EXTENSIONS_SCRIPT) \
+ $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-c $@
 
-$(intermediates)/vulkan/anv_extensions.h:
+$(intermediates)/vulkan/anv_extensions.h: $(ANV_EXTENSIONS_GEN_SCRIPT) \
+  $(ANV_EXTENSIONS_SCRIPT) \
+  $(VULKAN_API_XML)
@mkdir -p $(dir $@)
-   $(VK_EXTENSIONS_SCRIPT) \
-   --xml $(MESA_TOP)/src/vulkan/registry/vk.xml \
+   $(MESA_PYTHON2) $(ANV_EXTENSIONS_GEN_SCRIPT) \
+   --xml $(VULKAN_API_XML) \
--out-h $@
 
 LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES)
-- 
2.19.1

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

[Mesa-dev] [PATCH 2/2] android: anv: fix libexpat shared dependency

2019-03-03 Thread Mauro Rossi
Fixes undefined reference building errors for XML_* functions

Signed-off-by: Mauro Rossi 
Cc: "19.0" 
---
 src/intel/Android.vulkan.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/Android.vulkan.mk b/src/intel/Android.vulkan.mk
index 2e99ac6294..c9bce50c78 100644
--- a/src/intel/Android.vulkan.mk
+++ b/src/intel/Android.vulkan.mk
@@ -318,7 +318,7 @@ LOCAL_WHOLE_STATIC_LIBRARIES := \
libmesa_intel_compiler \
libmesa_anv_entrypoints
 
-LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libz libsync liblog
+LOCAL_SHARED_LIBRARIES := $(ANV_SHARED_LIBRARIES) libexpat libz libsync liblog
 
 include $(MESA_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
2.19.1

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

[Mesa-dev] [Bug 109821] Simple triangle Vulkan example gives pipeline->layout failed.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109821

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #1 from Bas Nieuwenhuizen  ---
The pipeline_layout variable in the example is VK_NULL_HANDLE because it does
not call create_pipeline_layout.

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

[Mesa-dev] [Bug 109822] Texture holes in simple vulkan examples.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109822

Bug ID: 109822
   Summary: Texture holes in simple vulkan examples.
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: cheako+bugs_freedesktop_...@mikemestnik.net
QA Contact: mesa-dev@lists.freedesktop.org

System specs:
https://bugs.freedesktop.org/show_bug.cgi?id=109445

Plus zram-tools, giving a slight boost/addition to swap space.

https://github.com/cheako/cheako-vulkan/blob/v0.1/0005texture/vulkan.c

Got:
https://ibb.co/173StH6

Expected:
https://ibb.co/Ltz5vDh

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

[Mesa-dev] [Bug 109822] Texture holes in simple vulkan examples.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109822

--- Comment #1 from Mike Mestnik  
---
All the examples with texture data are effected.

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

[Mesa-dev] [Bug 109821] Simple triangle Vulkan example gives pipeline->layout failed.

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109821

Bug ID: 109821
   Summary: Simple triangle Vulkan example gives pipeline->layout
failed.
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: cheako+bugs_freedesktop_...@mikemestnik.net
QA Contact: mesa-dev@lists.freedesktop.org

System specs:
https://bugs.freedesktop.org/show_bug.cgi?id=109445

Plus zram-tools, giving a slight boost/addition to swap space.

cheako@nysa:~/src/github/cheako-vulkan$ tri/vulkan 
Xlib:  extension "NV-GLX" missing on display ":0".
vulkan: ../src/amd/vulkan/radv_pipeline.c:3548: radv_pipeline_init: Assertion
`pipeline->layout' failed.
Aborted (core dumped)
cheako@nysa:~/src/github/cheako-vulkan$ 

https://github.com/cheako/cheako-vulkan/blob/v0.1/tri/vulkan.c

Note: the rest of the examples work to varying extents.

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

[Mesa-dev] [Bug 109818] wrong color rendering in SOULCALIBUR 6 using dxvk

2019-03-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109818

Bug ID: 109818
   Summary: wrong color rendering in SOULCALIBUR 6 using dxvk
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: farmboy0+freedesk...@googlemail.com
QA Contact: mesa-dev@lists.freedesktop.org

When running SOULCALIBUR 6 in steam using dxvk and mesa 19.0 rc6 the 3D
elements (characters, world) are rendered with the wrong colors.

Switching to 19.0rc5 will fix this.

Software:
Mesa 19.0rc6
LLVM 7.0.1
Proton 3.16-7Beta with DXVK 0.94(Default)
Kernel 4.20.8

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