Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass
On Sat, Mar 31, 2018 at 5:08 PM, Mike Lothian wrote: > On 1 April 2018 at 00:03, Vinson Lee wrote: >> >> A similar change is needed in >> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp. >> >> Vinson > > Hi > > I'm not convinced that it does > > Utils.h defines two functions LLVMAddLowerSwitchPass & > LLVMAddPromoteMemoryToRegisterPass. Whilst jit_pch.hpp does use > Scalar.h, it doesn't use either of the two functions in Utils.h so it > doesn't need to be included > > Cheers > > Mike I see this build errors with llvm 7.0.0svn. These errors are fixed if Utils.h is added to the list of includes. CXX rasterizer/jitter/libmesaswr_la-blend_jit.lo rasterizer/jitter/blend_jit.cpp:796:20: error: use of undeclared identifier 'createBreakCriticalEdgesPass' passes.add(createBreakCriticalEdgesPass()); ^ rasterizer/jitter/blend_jit.cpp:799:20: error: use of undeclared identifier 'createPromoteMemoryToRegisterPass' passes.add(createPromoteMemoryToRegisterPass()); ^ rasterizer/jitter/blend_jit.cpp:803:20: error: use of undeclared identifier 'createInstructionSimplifierPass'; did you mean 'createInstructionCombiningPass'? passes.add(createInstructionSimplifierPass()); ^~~ createInstructionCombiningPass Vinson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 103852] Rendering errors when running dolphin-emu with Vulkan backend, radv (Super Smash Bros. Melee)
https://bugs.freedesktop.org/show_bug.cgi?id=103852
--- Comment #8 from Ben Clapp ---
Today I spent a number of hours looking at the background rendering errors in
RenderDoc.
The vertex shader outputs some vertices that have two vertex colors, colors_0
and colors_1. (Only colors_0 is relevant here)
The fragment shader does a bunch of fiddling around with colors_0, a lot of
unnecessary conversions and re-assignments that effectively do nothing, and
ultimately the colors_0 value is passed to rastemp and tevin_d.
Some more fiddling around and, in the case of the areas of the screen where
there are rendering errors, the value of colors_0/rastemp/tevin_d ("tevin"
means "TEV input", referring to the Gamecube/Wii's Texture EnVironment
hardware) becomes the color value written to the framebuffer.
The problem is not in the vertex shader, nor is it in the fragment shader.
For some reason, the value of colors_0 coming out of the vertex shader is
correct, but the value of colors_0 in the fragment shader is inverted! So blue
will appear yellow, black while appear white, etc...
This seems to be a driver bug after all, and so I did try to spend some time
looking into radv's code to try and see if I could figure out a fix.
The issue might lie in radv_pipeline.c, I would think it probably has something
to do with the inter-stage varying colors_0 not getting filled or interpreted
correctly.
I've done lots of OpenGL and Vulkan programming, but I have little experience
with the driver side of things, so while it might be interesting to talk a bit
with the radv devs and learn a thing or two, I'm not sure how much further I
can go in terms of looking into this on my own without assistance.
Sven: I'll work on making some separate issues on another occasion for the
radeonsi freeze for Melee and the system freezes/GPU hangs for other games.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
Jean, I've taken at look at your sphinx-docs branch (https://github.com/jlHertel/mesa). Oh my you have a lot of commits there! It would be simpler for me to review if you could squash some of them together. I am thinking a series on the order of 30 patches to start - just the pretty CSS stuff in Sphinx. Once we get the page to look nicer, then we can start editing the content for readability!!! Thanks. Laura On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand wrote: > Hello Jean, > > Has anyone reviewed your patch series yet? I would like to get these > website updates moving. > > Thanks. > > Laura > > On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel > wrote: > >> Hello Emil, >> >> I've updated the website with the new release notes template. >> >> Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html >> >> >> What about rebasing my current work on top of mesa-master? >> (Remembering that github comments referencing directly the commit will be >> loss) >> >> >> The repository: https://github.com/jlHertel/mesa >> Demo site: http://mesa2.jeanhertel.com.br/ >> >> Best regards, >> Jean Hertel >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx
Hello Jean, Has anyone reviewed your patch series yet? I would like to get these website updates moving. Thanks. Laura On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel wrote: > Hello Emil, > > I've updated the website with the new release notes template. > > Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html > > > What about rebasing my current work on top of mesa-master? > (Remembering that github comments referencing directly the commit will be > loss) > > > The repository: https://github.com/jlHertel/mesa > Demo site: http://mesa2.jeanhertel.com.br/ > > Best regards, > Jean Hertel > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105832] radeonsi NIR missing bindless textures support
https://bugs.freedesktop.org/show_bug.cgi?id=105832 Timothy Arceri changed: What|Removed |Added Summary|With a debug build of mesa |radeonsi NIR missing |radeonsi NIR only compiles |bindless textures support |about 12% of the shaders in | |shader-db | --- Comment #6 from Timothy Arceri --- It's crashing because there is no bindless textures support. This is still outstanding as the core NIR bindless textures support is still being worked on. -- 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 3/3] gallivm: Fix include for LLVMAddPromoteMemoryToRegisterPass
Include llvm-c/Transforms/Utils.h with the newest LLVM 7 Signed-of-by: Mike Lothian Reviewed-by: Samuel Pitoiset Tested-by: Dieter Nützel --- src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c b/src/gallium/auxiliary/gallivm/lp_bld_init.c index 6ddc509a81..dae9d01552 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c @@ -40,6 +40,9 @@ #include #include +#if HAVE_LLVM >= 0x0700 +#include +#endif #include -- 2.16.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] radeonsi: Fix include for LLVMAddPromoteMemoryToRegisterPass
Include llvm-c/Transforms/Utils.h with the newest LLVM 7
Signed-of-by: Mike Lothian
Reviewed-by: Samuel Pitoiset
Tested-by: Dieter Nützel
---
src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 79fdebe838..622fd26950 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,9 @@
#include
#include
#include
+#if HAVE_LLVM >= 0x0700
+#include
+#endif
enum si_llvm_calling_convention {
RADEON_LLVM_AMDGPU_VS = 87,
--
2.16.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass
Include llvm-c/Transforms/Utils.h with the newest LLVM 7 Signed-of-by: Mike Lothian Reviewed-by: Samuel Pitoiset Tested-by: Dieter Nützel --- src/amd/vulkan/radv_nir_to_llvm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/amd/vulkan/radv_nir_to_llvm.c b/src/amd/vulkan/radv_nir_to_llvm.c index c6b4e8b532..2f0864da46 100644 --- a/src/amd/vulkan/radv_nir_to_llvm.c +++ b/src/amd/vulkan/radv_nir_to_llvm.c @@ -32,6 +32,9 @@ #include #include #include +#if HAVE_LLVM >= 0x0700 +#include +#endif #include "sid.h" #include "gfx9d.h" -- 2.16.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/3] Fix include for LLVMAddPromoteMemoryToRegisterPass
Hi I've split this into three patches, one for each area affected I think I've got the right prefixes now I've also removed the fixes line and included the testing and reviewed by tags Hope that's OK and again if you're happy with this please can you commit as I don't have git rights Thanks Mike ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass
On 1 April 2018 at 00:03, Vinson Lee wrote: > > A similar change is needed in > src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp. > > Vinson Hi I'm not convinced that it does Utils.h defines two functions LLVMAddLowerSwitchPass & LLVMAddPromoteMemoryToRegisterPass. Whilst jit_pch.hpp does use Scalar.h, it doesn't use either of the two functions in Utils.h so it doesn't need to be included Cheers Mike ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/pipebuffer: fix bracket location
Without this the return value will never get set to -1. This was first added in 49866c8f3457 and copied in 2b396eeed983. Fixes: 2b396eeed983 "gallium/pb_cache: add a copy of cache bufmgr independent of pb_manager" Cc: Marek Olšák Cc: Dave Airlie Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102342 --- src/gallium/auxiliary/pipebuffer/pb_cache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/pipebuffer/pb_cache.c b/src/gallium/auxiliary/pipebuffer/pb_cache.c index 0aaedbfae4c..2b9ad498045 100644 --- a/src/gallium/auxiliary/pipebuffer/pb_cache.c +++ b/src/gallium/auxiliary/pipebuffer/pb_cache.c @@ -169,7 +169,7 @@ pb_cache_reclaim_buffer(struct pb_cache *mgr, pb_size size, cur_entry = LIST_ENTRY(struct pb_cache_entry, cur, head); if (!entry && (ret = pb_cache_is_buffer_compat(cur_entry, size, - alignment, usage) > 0)) + alignment, usage)) > 0) entry = cur_entry; else if (os_time_timeout(cur_entry->start, cur_entry->end, now)) destroy_buffer_locked(cur_entry); -- 2.14.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass
On Thu, Mar 29, 2018 at 4:56 PM, Mike Lothian wrote:
> Include llvm-c/Transforms/Utils.h with the newest LLVM 7
>
> Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
> Signed-of-by: Mike Lothian
>
> ---
>
> I don't have git commit rights
>
> If you're happy with this patch please can you commit it
>
> Cheers
>
> Mike
> ---
> src/amd/vulkan/radv_nir_to_llvm.c | 3 +++
> src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
> src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index c6b4e8b532..2f0864da46 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -32,6 +32,9 @@
> #include
> #include
> #include
> +#if HAVE_LLVM >= 0x0700
> +#include
> +#endif
>
> #include "sid.h"
> #include "gfx9d.h"
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> index 6ddc509a81..dae9d01552 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
> @@ -40,6 +40,9 @@
>
> #include
> #include
> +#if HAVE_LLVM >= 0x0700
> +#include
> +#endif
> #include
>
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
> b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
> index 79fdebe838..622fd26950 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
> @@ -40,6 +40,9 @@
> #include
> #include
> #include
> +#if HAVE_LLVM >= 0x0700
> +#include
> +#endif
>
> enum si_llvm_calling_convention {
> RADEON_LLVM_AMDGPU_VS = 87,
> --
> 2.16.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
A similar change is needed in
src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp.
Vinson
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass
On Sat, 31 Mar 2018 at 00:54 Dylan Baker wrote:
>
> Quoting Mike Lothian (2018-03-29 17:49:30)
> >
> >
> > On Fri, 30 Mar 2018, 01:42 Dylan Baker, wrote:
> >
> > Quoting Mike Lothian (2018-03-29 16:56:28)
> > > Include llvm-c/Transforms/Utils.h with the newest LLVM 7
> > >
> > > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
> >
> > I have no comment on the patch itself.
> >
> > JFYI, this tag ("Fixes") has specific meaning in mesa and should only
> > refer
> > to
> > mesa commits (we have scripts for stable releases that parse that
> > information).
> >
> > Dylan
> >
> >
> > Ah sorry about that
>
> No worries, these are mesa specific so a lot people don't know what they're
> for.
>
> Dylan
Hi
Would you like me to make a v2 with another prefix and with the fixes
line removed? Or would you prefer I split it into 3 patches with the
correct prefix for each one?
Equally if you're happy as is could someone commit this to master? I
don't have git commit rights
Thanks
Mike
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] RFC: Externd IMG_context_priority with NV_context_priority_realtime
Quoting Kenneth Graunke (2018-03-31 20:29:28) > On Saturday, March 31, 2018 5:56:57 AM PDT Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-31 12:00:16) > > > Quoting Kenneth Graunke (2018-03-30 19:20:57) > > > > On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote: > > > > > For i915, we are proposing to use a quality-of-service parameter in > > > > > addition to that of just a priority that usurps everyone. Due to our > > > > > HW, > > > > > preemption may not be immediate and will be forced to wait until an > > > > > uncooperative process hits an arbitration point. To prevent that > > > > > unduly > > > > > impacting the privileged RealTime context, we back up the preemption > > > > > request with a timeout to reset the GPU and forcibly evict the GPU hog > > > > > in order to execute the new context. > > > > > > > > I am strongly against exposing this in general. Performing a GPU reset > > > > in the middle of a batch can completely screw up whatever application > > > > was running. If the application is using robustness extensions, we may > > > > be forced to return GL_DEVICE_LOST, causing the application to have to > > > > recreate their entire GL context and start over. If not, we may try to > > > > let them limp on(*) - and hope they didn't get too badly damaged by some > > > > of their commands not executing, or executing twice (if the kernel tries > > > > to resubmit it). But it may very well cause the app to misrender, or > > > > even crash. > > > > > > Yes, I think the revulsion has been universal. However, as a > > > quality-of-service guarantee, I can understand the appeal. The > > > difference is that instead of allowing a DoS for 6s or so as we > > > currently allow, we allow that to be specified by the context. As it > > > does allow one context to impact another, I want it locked down to > > > privileged processes. I have been using CAP_SYS_ADMIN as the potential > > > to do harm is even greater than exploiting the weak scheduler by > > > changing priority. > > Right...I was thinking perhaps a tunable to reduce the 6s would do the > trick, and be much less complicated...but perhaps you want to let it go > longer when there isn't super-critical work to do. If (mid-object) preemption worked properly, we wouldn't see many GPU hangs at all, depending on free the compositor is to inject work. Oh boy, that suggests we need to rethink the current hangcheck. Bring on timeslicing. > > Also to add further insult to injury, we might want to force GPU clocks > > to max for the RT context (so that the context starts executing at max > > rather than wait for the system to upclock on load). Something like, > > That makes some sense - but I wonder if it wouldn't cause more battery > burn than is necessary. The super-critical workload may also be > relatively simple (redrawing a clock), and so up-clocking and > down-clocking again might hurt us...it's hard to say. :( > > I also don't know what I think of this plan to let userspace control > (restrict) the frequency. That's been restricted to root (via sysfs) > in the past. But I think you're allowing it more generally now, without > CAP_SYS_ADMIN? It seems like there's a lot of potential for abuse. > (Hello, benchmark mode! Zm!) I know it solves a problem, but it > seems like there's got to be a better way... It's restricting the range the system can choose, but only within the range the sysadmin defines. The expected use case for me is actually HTPC more than benchmark mode (what benchmark that doesn't run at max clocks that needs to?). Where you have a workload you know needs a narrow band of frequencies and want to conserve energy by not overclocking, and also have a good idea of the minimum required to avoid frame drops. Tricking the system to run at high clocks isn't that hard today. It just happens that historically RT processes force max CPU clocks, and for something that demands a low latency QoS I expect to also have low latency tolerance throughout the pipeline. -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] RFC: Externd IMG_context_priority with NV_context_priority_realtime
On Saturday, March 31, 2018 5:56:57 AM PDT Chris Wilson wrote: > Quoting Chris Wilson (2018-03-31 12:00:16) > > Quoting Kenneth Graunke (2018-03-30 19:20:57) > > > On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote: > > > > For i915, we are proposing to use a quality-of-service parameter in > > > > addition to that of just a priority that usurps everyone. Due to our HW, > > > > preemption may not be immediate and will be forced to wait until an > > > > uncooperative process hits an arbitration point. To prevent that unduly > > > > impacting the privileged RealTime context, we back up the preemption > > > > request with a timeout to reset the GPU and forcibly evict the GPU hog > > > > in order to execute the new context. > > > > > > I am strongly against exposing this in general. Performing a GPU reset > > > in the middle of a batch can completely screw up whatever application > > > was running. If the application is using robustness extensions, we may > > > be forced to return GL_DEVICE_LOST, causing the application to have to > > > recreate their entire GL context and start over. If not, we may try to > > > let them limp on(*) - and hope they didn't get too badly damaged by some > > > of their commands not executing, or executing twice (if the kernel tries > > > to resubmit it). But it may very well cause the app to misrender, or > > > even crash. > > > > Yes, I think the revulsion has been universal. However, as a > > quality-of-service guarantee, I can understand the appeal. The > > difference is that instead of allowing a DoS for 6s or so as we > > currently allow, we allow that to be specified by the context. As it > > does allow one context to impact another, I want it locked down to > > privileged processes. I have been using CAP_SYS_ADMIN as the potential > > to do harm is even greater than exploiting the weak scheduler by > > changing priority. Right...I was thinking perhaps a tunable to reduce the 6s would do the trick, and be much less complicated...but perhaps you want to let it go longer when there isn't super-critical work to do. > Also to add further insult to injury, we might want to force GPU clocks > to max for the RT context (so that the context starts executing at max > rather than wait for the system to upclock on load). Something like, That makes some sense - but I wonder if it wouldn't cause more battery burn than is necessary. The super-critical workload may also be relatively simple (redrawing a clock), and so up-clocking and down-clocking again might hurt us...it's hard to say. :( I also don't know what I think of this plan to let userspace control (restrict) the frequency. That's been restricted to root (via sysfs) in the past. But I think you're allowing it more generally now, without CAP_SYS_ADMIN? It seems like there's a lot of potential for abuse. (Hello, benchmark mode! Zm!) I know it solves a problem, but it seems like there's got to be a better way... --Ken 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] [AppVeyor] mesa 17.3 #7346 completed
Build mesa 7346 completed Commit a516b047db by Juan A. Suarez Romero on 3/29/2018 9:26 AM: cherry-ignore: docs: fix 18.0 release note version\n\nstable: Explicit 18.0 only nominations.\n\nSigned-off-by: Juan A. Suarez Romero Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: mark function end of brw_regs_negative_equal() unreachable
Ian sent a patch for this already (that fixes it without unreachable) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: mark function end of brw_regs_negative_equal() unreachable
This shuts the compiler up about reaching the end of a non-void function:
In file included from compiler/brw_shader.h:28:0,
from compiler/brw_cfg.h:31,
from compiler/brw_shader.cpp:24:
compiler/brw_reg.h: In function 'bool brw_regs_negative_equal(const brw_reg*,
const brw_reg*)':
compiler/brw_reg.h:305:1: warning: control reaches end of non-void function
[-Wreturn-type]
Signed-off-by: Tobias Klausmann
---
src/intel/compiler/brw_reg.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_reg.h b/src/intel/compiler/brw_reg.h
index 68158cc0cc..6b10d05e12 100644
--- a/src/intel/compiler/brw_reg.h
+++ b/src/intel/compiler/brw_reg.h
@@ -302,6 +302,7 @@ brw_regs_negative_equal(const struct brw_reg *a, const
struct brw_reg *b)
return brw_regs_equal(&tmp, b);
}
+ unreachable("not reached");
}
struct brw_indirect {
--
2.16.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 102204] GL_ARB_buffer_storage crippled extension on r600, radeonsi and amdgpu Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=102204 H4nN1baL changed: What|Removed |Added Summary|GL_ARB_buffer_storage |GL_ARB_buffer_storage |crippled extension on r600, |crippled extension on r600, |radeonsi, amdgpu and Mesa |radeonsi and amdgpu Mesa |drivers |drivers -- 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 102204] GL_ARB_buffer_storage crippled extension on r600, radeonsi, amdgpu and Mesa drivers
https://bugs.freedesktop.org/show_bug.cgi?id=102204 H4nN1baL changed: What|Removed |Added Summary|GLideN64 very slow on |GL_ARB_buffer_storage |r600/radeonsi - |crippled extension on r600, |GL_ARB_buffer_storage bug |radeonsi, amdgpu and Mesa ||drivers -- 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 102204] GLideN64 very slow on r600/radeonsi - GL_ARB_buffer_storage bug
https://bugs.freedesktop.org/show_bug.cgi?id=102204 H4nN1baL changed: What|Removed |Added QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core Severity|enhancement |normal Priority|high|medium Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 102204] GLideN64 very slow on r600/radeonsi - GL_ARB_buffer_storage bug
https://bugs.freedesktop.org/show_bug.cgi?id=102204 H4nN1baL changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- -- 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] VC4 not working for me with mesa 17.3.7
On Fri, Mar 30, 2018 at 4:41 PM, Daniel Stone wrote: > Hi Andreas, > > On 30 March 2018 at 15:18, Andreas Müller wrote: >> What happened: I build all images cross with Openembedded/Yocto. To >> prepare next release there I updated my builds and that moved mesa >> 17.1.7 -> 17.3.7. Since then all applications using GL/GLES (e.g >> glmark2-es - tried others - same) complain with >> >> | Modifier 0x0 vs. tiling (0x701) mismatch >> >> and drawable region remains black. >> There was some discussion on meta-raspberrypi mailing list and it >> seems to happen to others too [1]. >> >> I've attached a patch. That fixes glmark2-es and many others but e.g >> on KDE desktop mouse pointer is just pixel dust so I think that my >> (naive) approach only works around an issue caused somewhere else. To >> ne honest my background understanding is poor but it seems that >> modifier gets not properly for all cases. > > Odd. That happens when something has already allocated the buffer as a > tiled buffer, but Mesa is being told that the buffer is linear. Are > you able to get a backtrace from when this error happens? (Either set > a breakpoint by hand, or just add 'uint32_t *crash = NULL; *crash = > 1;' to force a segfault.) > > I could only find one place where this would happen, which is when > using the old DRI2 interface with Gallium, but it really should be > using DRI3 ... nonetheless, does the attached patch help at all? > > Cheers, > Daniel Hi Daniel, Thanks for prompt an VERY helpful support. I did: * Check my configure and found: --disable-dri3! * Tested your patch (with --disable-dri3) and as expected it fixes the issue * Found what causes --disable-dri3 - it came in by the Openembedded update mentioned in first email. FWIW: I use a fork for meta-raspberrypi - the original is not affected so I am the only one with this issue... I have two questions related to dri2/your patch (sorry asking for more :) 1. Your patch fixes improper initialized variable. Do you think it is worth being applied? 2. In the thread I mentioned in my first email Trevor mentioned that he has seen error message 'Modifier 0x0 vs. tiling(0x7001) mismatch' when trying to get chromium GLES accelerated. Maybe a stupid question but is it possible that applications running at X can ask for dri2 explicitly? Cheers Andreas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 --- Comment #5 from b...@besd.de --- I've added two more testruns one with one without debug build including the output of stderr. NIR seems to crash at the exact same point in the debug build regardless of llvm backend. -- 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] RFC: Externd IMG_context_priority with NV_context_priority_realtime
Quoting Chris Wilson (2018-03-31 12:00:16)
> Quoting Kenneth Graunke (2018-03-30 19:20:57)
> > On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote:
> > > For i915, we are proposing to use a quality-of-service parameter in
> > > addition to that of just a priority that usurps everyone. Due to our HW,
> > > preemption may not be immediate and will be forced to wait until an
> > > uncooperative process hits an arbitration point. To prevent that unduly
> > > impacting the privileged RealTime context, we back up the preemption
> > > request with a timeout to reset the GPU and forcibly evict the GPU hog
> > > in order to execute the new context.
> >
> > I am strongly against exposing this in general. Performing a GPU reset
> > in the middle of a batch can completely screw up whatever application
> > was running. If the application is using robustness extensions, we may
> > be forced to return GL_DEVICE_LOST, causing the application to have to
> > recreate their entire GL context and start over. If not, we may try to
> > let them limp on(*) - and hope they didn't get too badly damaged by some
> > of their commands not executing, or executing twice (if the kernel tries
> > to resubmit it). But it may very well cause the app to misrender, or
> > even crash.
>
> Yes, I think the revulsion has been universal. However, as a
> quality-of-service guarantee, I can understand the appeal. The
> difference is that instead of allowing a DoS for 6s or so as we
> currently allow, we allow that to be specified by the context. As it
> does allow one context to impact another, I want it locked down to
> privileged processes. I have been using CAP_SYS_ADMIN as the potential
> to do harm is even greater than exploiting the weak scheduler by
> changing priority.
Also to add further insult to injury, we might want to force GPU clocks
to max for the RT context (so that the context starts executing at max
rather than wait for the system to upclock on load). Something like,
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index b080c4c58f1..461b76b64c9 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -1370,6 +1370,36 @@ brw_hw_context_set_preempt_timeout(struct brw_bufmgr
*bufmgr,
return err;
}
+int
+brw_hw_context_force_maximum_frequency(struct brw_bufmgr *bufmgr,
+ uint32_t ctx_id)
+{
+#define I915_CONTEXT_PARAM_FREQUENCY0x8
+#define I915_CONTEXT_MIN_FREQUENCY(x) ((x) & 0x)
+#define I915_CONTEXT_MAX_FREQUENCY(x) ((x) >> 32)
+#define I915_CONTEXT_SET_FREQUENCY(min, max) ((uint64_t)(max) << 32 | (min))
+
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = ctx_id,
+ .param =I915_CONTEXT_PARAM_FREQUENCY,
+ };
+
+ /* First find the HW limits */
+ if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, &p))
+ return -errno;
+
+ /* Then specify that the context's minimum frequency is the HW max,
+* forcing the context to only run at the maximum frequency, as
+* restricted by the global user limits.
+*/
+ p.value = I915_CONTEXT_SET_FREQUENCY(I915_CONTEXT_MAX_FREQUENCY(p.value),
+ I915_CONTEXT_MAX_FREQUENCY(p.value));
+ if (drmIoctl(bufmgr->fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &p))
+ return -errno;
+
+ return 0;
+}
+
void
brw_destroy_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id)
{
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.h
b/src/mesa/drivers/dri/i965/brw_bufmgr.h
index a493b7018af..07dc9ced57a 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.h
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.h
@@ -320,6 +320,9 @@ int brw_hw_context_set_preempt_timeout(struct brw_bufmgr
*bufmgr,
uint32_t ctx_id,
uint64_t timeout_ns);
+int brw_hw_context_force_maximum_frequency(struct brw_bufmgr *bufmgr,
+ uint32_t ctx_id);
+
void brw_destroy_hw_context(struct brw_bufmgr *bufmgr, uint32_t ctx_id);
int brw_bo_gem_export_to_prime(struct brw_bo *bo, int *prime_fd);
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 9b84a29d4a2..0bd965043c5 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1026,13 +1026,17 @@ brwCreateContext(gl_api api,
intelDestroyContext(driContextPriv);
return false;
}
- if (hw_priority >= GEN_CONTEXT_REALTIME_PRIORITY &&
- brw_hw_context_set_preempt_timeout(brw->bufmgr, brw->hw_ctx,
-8 * 1000 * 1000 /* 8ms */)) {
- fprintf(stderr,
-"Failed to set preempt timeout for RT hardware context.\n");
- intelDestroyContext(driContextPriv);
- return false;
+
+ if (hw_priority >= GEN_CONTEXT_REALTIME_PRIORITY) {
+
[Mesa-dev] [AppVeyor] mesa master #7345 failed
Build mesa 7345 failed Commit e8e3aa68d6 by Wladimir J. van der Laan on 8/8/2017 3:06 PM: freedreno: a2xx: Implement DP2 instruction\n\nUse DOT2ADDv instruction with 0.0f constant add.\n\nSigned-off-by: Wladimir J. van der Laan \nReviewed-by: Ilia Mirkin \nReviewed-by: Rob Clark Configure your notification preferences ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 --- Comment #4 from b...@besd.de --- However TGSI from the same run (debug, llvm 4) has significantly more errors: ATTENTION: default value of option allow_glsl_extension_directive_midshader overridden by environment. Mesa: User error: GL_INVALID_OPERATION in glProgramStringARB(syntax error, unexpected $undefined, expecting $end) ERROR: shaders/csgo/fp-1.shader_test failed to compile ERROR: shaders/w40kdawn2/1054.shader_test failed to compile: 0:65(2): error: `gl_TexCoord' undeclared 0:65(2): error: type mismatch 0:65(2): error: value of type float cannot be assigned to variable of type error 0:70(2): error: `gl_TexCoord' undeclared 0:70(2): error: type mismatch 0:70(2): error: value of type float cannot be assigned to variable of type error 0:164(2): error: `gl_TexCoord' undeclared 0:164(2): error: type mismatch 0:164(2): error: value of type vec3 cannot be assigned to variable of type error 0:175(2): error: `gl_TexCoord' undeclared 0:175(2): error: type mismatch 0:175(2): error: value of type vec3 cannot be assigned to variable of type error 0:179(2): error: `gl_TexCoord' undeclared 0:179(2): error: type mismatch 0:179(2): error: value of type vec3 cannot be assigned to variable of type error 0:180(2): error: `gl_TexCoord' undeclared 0:180(2): error: type mismatch 0:180(2): error: value of type vec3 cannot be assigned to variable of type error 0:184(2): error: `gl_TexCoord' undeclared 0:184(2): error: type mismatch 0:184(2): error: value of type vec2 cannot be assigned to variable of type error 0:193(2): error: `gl_TexCoord' undeclared 0:193(2): error: type mismatch 0:193(2): error: value of type float cannot be assigned to variable of type error 0:209(2): error: `gl_TexCoord' undeclared 0:209(2): error: value of type vec4 cannot be assigned to variable of type error 0:210(2): error: `gl_TexCoord' undeclared 0:210(2): error: type mismatch 0:210(2): error: value of type float cannot be assigned to variable of type error 0:211(2): error: `gl_TexCoord' undeclared 0:211(2): error: type mismatch 0:211(2): error: value of type vec3 cannot be assigned to variable of type error 0:212(2): error: `gl_TexCoord' undeclared 0:212(2): error: type mismatch 0:212(2): error: value of type float cannot be assigned to variable of type error 0:213(2): error: `gl_TexCoord' undeclared 0:213(2): error: type mismatch 0:213(2): error: value of type vec2 cannot be assigned to variable of type error 0:214(2): error: `gl_TexCoord' undeclared 0:214(2): error: type mismatch 0:214(2): error: value of type float cannot be assigned to variable of type error 0:215(2): error: `gl_TexCoord' undeclared 0:215(2): error: type mismatch 0:215(2): error: value of type float cannot be assigned to variable of type error ERROR: shaders/w40kdawn2/1054.shader_test failed to compile: 0:108(11): error: `gl_TexCoord' undeclared 0:108(11): error: type mismatch 0:108(11): error: operands to arithmetic operators must be numeric 0:108(11): error: operands to arithmetic operators must be numeric 0:113(18): error: `gl_TexCoord' undeclared 0:113(18): error: type mismatch 0:113(10): error: operands to arithmetic operators must be numeric 0:116(19): error: `gl_TexCoord' undeclared 0:116(19): error: type mismatch 0:116(18): error: operands to arithmetic operators must be numeric 0:116(10): error: operands to arithmetic operators must be numeric 0:117(16): error: `gl_TexCoord' undeclared 0:117(16): error: type mismatch 0:117(9): error: operands to arithmetic operators must be numeric 0:125(16): error: `gl_TexCoord' undeclared 0:125(16): error: type mismatch 0:125(9): error: operands to arithmetic operators must be numeric 0:129(16): error: `gl_TexCoord' undeclared 0:129(16): error: type mismatch 0:129(9): error: operands to arithmetic operators must be numeric 0:133(16): error: `gl_TexCoord' undeclared 0:133(16): error: type mismatch 0:133(9): error: operands to arithmetic operators must be numeric 0:139(16): error: `gl_TexCoord' undeclared 0:139(16): error: type mismatch 0:139(9): error: operands to arithmetic operators must be numeric 0:151(16): error: `gl_TexCoord' undeclared 0:151(16): error: type mismatch 0:151(9): error: operands to arithmetic operators must be numeric 0:163(16): error: `gl_TexCoord' undeclared 0:163(16): error: type mismatch 0:163(9): error: operands to arithmetic operators must be numeric 0:175(16): error: `gl_TexCoord' undeclared 0:175(16): error: type mismatch 0:175(9): error: operands to arithmetic operators must be numeric 0:188(37): error: `gl_TexCoord' undeclared 0:188(32): error: cannot construct `vec3' from a non-numeric data type 0:188(17): error: no matching function for call to `texture(sampler2DShadow, error)'; candidates are: 0:188(17): error:vec4 texture(sampler1D, float) 0:188(17): error:ivec4 texture(isampler1D, float) 0:188(17): error:uvec4 texture(usampler1D, float) 0:188(17): error:vec4 texture(sampler2D, vec2) 0:188(17): error:ivec4 texture(isa
[Mesa-dev] [Bug 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 --- Comment #3 from b...@besd.de --- from stderr: ATTENTION: default value of option allow_glsl_extension_directive_midshader overridden by environment. Mesa: User error: GL_INVALID_OPERATION in glProgramStringARB(syntax error, unexpected $undefined, expecting $end) ERROR: shaders/csgo/fp-1.shader_test failed to compile run: ../../../../src/util/bitscan.h:263: u_bit_consecutive: Assertion `start + count <= 32' failed. => CRASHED <= while processing these shaders: shaders/w40kdawn3/980.shader_test shaders/w40kdawn3/1102.shader_test shaders/w40kdawn3/1068.shader_test shaders/w40kdawn3/1088.shader_test shaders/w40kdawn3/958.shader_test shaders/w40kdawn3/1968.shader_test shaders/w40kdawn3/1504.shader_test shaders/w40kdawn3/950.shader_test -- 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] RFC: Externd IMG_context_priority with NV_context_priority_realtime
Quoting Kenneth Graunke (2018-03-30 19:20:57) > On Friday, March 30, 2018 7:40:13 AM PDT Chris Wilson wrote: > > For i915, we are proposing to use a quality-of-service parameter in > > addition to that of just a priority that usurps everyone. Due to our HW, > > preemption may not be immediate and will be forced to wait until an > > uncooperative process hits an arbitration point. To prevent that unduly > > impacting the privileged RealTime context, we back up the preemption > > request with a timeout to reset the GPU and forcibly evict the GPU hog > > in order to execute the new context. > > I am strongly against exposing this in general. Performing a GPU reset > in the middle of a batch can completely screw up whatever application > was running. If the application is using robustness extensions, we may > be forced to return GL_DEVICE_LOST, causing the application to have to > recreate their entire GL context and start over. If not, we may try to > let them limp on(*) - and hope they didn't get too badly damaged by some > of their commands not executing, or executing twice (if the kernel tries > to resubmit it). But it may very well cause the app to misrender, or > even crash. Yes, I think the revulsion has been universal. However, as a quality-of-service guarantee, I can understand the appeal. The difference is that instead of allowing a DoS for 6s or so as we currently allow, we allow that to be specified by the context. As it does allow one context to impact another, I want it locked down to privileged processes. I have been using CAP_SYS_ADMIN as the potential to do harm is even greater than exploiting the weak scheduler by changing priority. > This seems like a crazy plan to me. Scheduling has never been allowed > to just kill random processes. That's not strictly true, as processes have their limits which if they exceed they will be killed. On the CPU preemption is much better, the issue of unyielding processes is pretty much limited to the kernel, where we can run the NMI watchdog to kill broken code. > If you ever hit that case, then your > customers will see random application crashes, glitches, GPU hangs, > and be pretty unhappy with the result. And not because something was > broken, but because somebody was impatient and an app was a bit slow. Yes, that is their decision. Kill random apps so that their uber-critical interface updates the clock. > If you have work that is so mission critical, maybe you shouldn't run it > on the same machine as one that runs applications which you care so > little about that you're willing to watch them crash and burn. Don't > run the entertainment system on the flight computer, so to speak. You are not the first to say that ;) -Chris ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 --- Comment #2 from b...@besd.de --- no crashes, nothing visible, except that the run files are are ~1.7MB instead of ~14.1MB and shaders are missing that were run before. Looking at the files again it seems that it indeed crashes because the files end prematurely. And they all seem to end on the same shader as well so its probably the one after that ;) Per instructions I route the stderr of shader-db's run to dev/null Would that be helpful? -- 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 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 --- Comment #1 from Timothy Arceri --- What exactly are you seeing? Crashes? Can you give an example? -- 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 105832] With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db
https://bugs.freedesktop.org/show_bug.cgi?id=105832 Bug ID: 105832 Summary: With a debug build of mesa radeonsi NIR only compiles about 12% of the shaders in shader-db Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: b...@besd.de QA Contact: mesa-dev@lists.freedesktop.org CC: t_arc...@yahoo.com.au Hi Timothy, With a debug build of mesa (-O0 and --enable-debug instead of release with -O3) only a small part of the available shaders is compiled (~12%) when using shader-db. https://github.com/bendat78/mymesa/tree/mymesa2/testresults/run_2018-03-31_11:12:58_debug Also see the nir test file in https://github.com/bendat78/mymesa/tree/mymesa2/testresults where I try to keep track of the things I have done and the results gathered Cheers, Benedikt -- 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
