[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1
https://bugs.freedesktop.org/show_bug.cgi?id=92265 Michel Dänzer changed: What|Removed |Added CC||custos.men...@gmail.com --- Comment #4 from Michel Dänzer --- *** Bug 92242 has been marked as a duplicate of this bug. *** -- 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 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 11:13 AM, Jason Ekstrand wrote: > On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: >> Before, we would only do scheduling after register allocation if we >> spilled, despite the fact that the pre-RA scheduler was only supposed to >> be for register pressure and set the latencies of every instruction to >> 1. This meant that unless we spilled, which we rarely do, then we never >> considered instruction latencies at all, and we usually never bothered >> to try and hide texture fetch latency. Although a later commit removes >> the setting the latency to 1 part, we still want to always run the >> post-RA scheduler since it's able to take the false dependencies that >> the register allocator creates into account, and it can be more >> aggressive than the pre-RA scheduler since it doesn't have to worry >> about register pressure at all. >> >> XXX perf data > > Test master post-ra-sched diff %diff bench_heaven 25.179 25.2540.074 +0.200% > bench_OglPSBump2 396.730 402.386 5.656 +1.400% > bench_OglPSBump8 244.370 247.591 3.221 +1.300% > bench_OglPSPhong 241.117 242.002 0.885 +0.300% > bench_OglPSPom 59.555 59.7250.170 +0.200% > bench_OglShMapPcf 86.149 102.346 16.197 +18.800% > bench_OglVSTangent 388.849 395.489 6.640 +1.700% > bench_trex 65.471 65.8620.390 +0.500% > bench_trexoff 69.562 70.1500.588 +0.800% > > Unfortunately, neither of the unigin benchmarks (heaven or vally) > seemed to render correctly. I just got white on both master and your > branch. Not sure if we have a bug or if they just weren't running > right. In any case, ministat didn't notice any difference in them. > >> Signed-off-by: Connor Abbott >> --- >> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp >> b/src/mesa/drivers/dri/i965/brw_fs.cpp >> index b269ade..14a9fdf 100644 >> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp >> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp >> @@ -4981,8 +4981,7 @@ fs_visitor::allocate_registers() >> if (failed) >>return; >> >> - if (!allocated_without_spills) >> - schedule_instructions(SCHEDULE_POST); >> + schedule_instructions(SCHEDULE_POST); >> >> if (last_scratch > 0) >>prog_data->total_scratch = brw_get_scratch_size(last_scratch); >> -- >> 2.1.0 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: Mark GL_ARB_enhanced_layouts as in progress
--- docs/GL3.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index e020deb..09c711f 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -178,7 +178,13 @@ GL 4.4, GLSL 4.40: GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers) GL_ARB_buffer_storageDONE (i965, nv50, nvc0, r600, radeonsi) GL_ARB_clear_texture DONE (i965) (gallium - in progress, VMware) - GL_ARB_enhanced_layouts not started + GL_ARB_enhanced_layouts in progress (Timothy) + - compile-time constant expressions in progress + - explicit byte offsets for blocks in progress + - forced alignment within blocks in progress + - specify vec4-slot component numbersin progress + - specify transform/feedback layout in progress + - input/output block locations in progress GL_ARB_multi_bindDONE (all drivers) GL_ARB_query_buffer_object not started GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe) -- 2.4.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] c11/threads: initialize timeout structure
Signed-off-by: Jan Vesely
---
include/c11/threads_posix.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/c11/threads_posix.h b/include/c11/threads_posix.h
index 3def6c4..ce9853b 100644
--- a/include/c11/threads_posix.h
+++ b/include/c11/threads_posix.h
@@ -136,8 +136,14 @@ cnd_timedwait(cnd_t *cond, mtx_t *mtx, const xtime *xt)
{
struct timespec abs_time;
int rt;
+
assert(mtx != NULL);
assert(cond != NULL);
+assert(xt != NULL);
+
+abs_time.tv_sec = xt->sec;
+abs_time.tv_nsec = xt->nsec;
+
rt = pthread_cond_timedwait(cond, mtx, &abs_time);
if (rt == ETIMEDOUT)
return thrd_busy;
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/vec4: Remove more dead visitor/vertex program code.
On Saturday, October 03, 2015 10:57:28 AM Matt Turner wrote: > --- > src/mesa/drivers/dri/i965/brw_vec4.h | 8 > src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 10 -- > src/mesa/drivers/dri/i965/brw_vs.h | 5 - > 3 files changed, 23 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h > b/src/mesa/drivers/dri/i965/brw_vec4.h > index 51b3161..d1fa095 100644 > --- a/src/mesa/drivers/dri/i965/brw_vec4.h > +++ b/src/mesa/drivers/dri/i965/brw_vec4.h > @@ -223,9 +223,6 @@ public: > > int implied_mrf_writes(vec4_instruction *inst); > > - void emit_vp_sop(enum brw_conditional_mod condmod, dst_reg dst, > -src_reg src0, src_reg src1, src_reg one); > - > vec4_instruction *emit_minmax(enum brw_conditional_mod conditionalmod, > dst_reg dst, > src_reg src0, src_reg src1); > Reviewed-by: Kenneth Graunke signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 79783] Distorted output in obs-studio where other vendors "work"
https://bugs.freedesktop.org/show_bug.cgi?id=79783 gregory.hain...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |gregory.hain...@gmail.com |org | -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 89599] symbol 'x86_64_entry_start' is already defined when building with LLVM/clang
https://bugs.freedesktop.org/show_bug.cgi?id=89599 --- Comment #5 from Marek Olšák --- The patch should be sent to the mailing list. -- 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 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Remove CSE pass.
On Sat, Oct 3, 2015 at 2:50 PM, Matt Turner wrote: > On Sat, Oct 3, 2015 at 11:31 AM, Ilia Mirkin wrote: >> On Sat, Oct 3, 2015 at 1:57 PM, Matt Turner wrote: >>> With NIR, it actually hurts things. >> >> Buuutt not everything uses NIR. > > Well... > >> Of course I'm sure it has a >> similarly negative effect with nouveau/codegen, but I'm not so sure >> about things like nv30 which don't have an optimizing compiler >> backend. IMHO there should be a bit somewhere in the compiler options >> that indicates whether the driver implements an optimizing compiler, >> and if so, then all these idiotic optimizations should be removed. [I >> realize some are needed for correctness, obviously keep those.] > > They're not idiotic. They all serve(d) some useful purpose. To say > they're idiotic is insulting to the authors. Poor word choice, didn't mean to belittle the original, rather useful purpose of these passes. How about "superseded". > Anyway, the GLSL IR CSE pass was added (commit fd05ede0d0) for a > single purpose: to fix a performance regression in a broken benchmark > on i965 after some changes to i965's instruction scheduler. It no > longer serves that purpose. > > If anything else accidentally benefited from it, they'll simply go > back to the [acceptable] way they were. The commit was pushed more than 2 years ago. I think you overestimate how much testing drivers like nv30 & co get on HEAD. At the same time, I don't want to create a situation where you guys can't change anything at the higher levels due to fears of the gathering darkness. Mostly just wanted to point it out. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Remove CSE pass.
On Sat, Oct 3, 2015 at 11:31 AM, Ilia Mirkin wrote: > On Sat, Oct 3, 2015 at 1:57 PM, Matt Turner wrote: >> With NIR, it actually hurts things. > > Buuutt not everything uses NIR. Well... > Of course I'm sure it has a > similarly negative effect with nouveau/codegen, but I'm not so sure > about things like nv30 which don't have an optimizing compiler > backend. IMHO there should be a bit somewhere in the compiler options > that indicates whether the driver implements an optimizing compiler, > and if so, then all these idiotic optimizations should be removed. [I > realize some are needed for correctness, obviously keep those.] They're not idiotic. They all serve(d) some useful purpose. To say they're idiotic is insulting to the authors. Anyway, the GLSL IR CSE pass was added (commit fd05ede0d0) for a single purpose: to fix a performance regression in a broken benchmark on i965 after some changes to i965's instruction scheduler. It no longer serves that purpose. If anything else accidentally benefited from it, they'll simply go back to the [acceptable] way they were. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 2:38 PM, Jason Ekstrand wrote: > On Sat, Oct 3, 2015 at 11:32 AM, Ilia Mirkin wrote: >> On Sat, Oct 3, 2015 at 2:28 PM, Jason Ekstrand wrote: >>> On Sat, Oct 3, 2015 at 11:26 AM, Ilia Mirkin wrote: On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand wrote: > On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: >> Before, we would only do scheduling after register allocation if we >> spilled, despite the fact that the pre-RA scheduler was only supposed to >> be for register pressure and set the latencies of every instruction to >> 1. This meant that unless we spilled, which we rarely do, then we never >> considered instruction latencies at all, and we usually never bothered >> to try and hide texture fetch latency. Although a later commit removes >> the setting the latency to 1 part, we still want to always run the >> post-RA scheduler since it's able to take the false dependencies that >> the register allocator creates into account, and it can be more >> aggressive than the pre-RA scheduler since it doesn't have to worry >> about register pressure at all. >> >> XXX perf data > > Test master post-ra-sched diff %diff > bench_OglPSBump2 396.730 402.386 5.656 +1.400% > bench_OglPSBump8 244.370 247.591 3.221 +1.300% > bench_OglPSPhong 241.117 242.002 0.885 +0.300% > bench_OglPSPom 59.555 59.7250.170 +0.200% > bench_OglShMapPcf 86.149 102.346 16.197 +18.800% > bench_OglVSTangent 388.849 395.489 6.640 +1.700% > bench_trex 65.471 65.8620.390 +0.500% > bench_trexoff 69.562 70.1500.588 +0.800% > > Unfortunately, neither of the unigin benchmarks (heaven or vally) > seemed to render correctly. I just got white on both master and your > branch. Not sure if we have a bug or if they just weren't running > right. In any case, ministat didn't notice any difference in them. I believe they're called "features" :) Try with disable_blend_func_extended=true >>> >>> I pulled in a more recent drirc and am re-running those two. >> >> They're not in the latest drirc... probably should be added back in. > > I used the drirc corresponding to the mesa commits I was testing. > Given that it's actually rendering stuff, I'm going to say it's > probably ok. Ah neat. I guess something to fixed then. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 11:32 AM, Ilia Mirkin wrote: > On Sat, Oct 3, 2015 at 2:28 PM, Jason Ekstrand wrote: >> On Sat, Oct 3, 2015 at 11:26 AM, Ilia Mirkin wrote: >>> On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand wrote: On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: > Before, we would only do scheduling after register allocation if we > spilled, despite the fact that the pre-RA scheduler was only supposed to > be for register pressure and set the latencies of every instruction to > 1. This meant that unless we spilled, which we rarely do, then we never > considered instruction latencies at all, and we usually never bothered > to try and hide texture fetch latency. Although a later commit removes > the setting the latency to 1 part, we still want to always run the > post-RA scheduler since it's able to take the false dependencies that > the register allocator creates into account, and it can be more > aggressive than the pre-RA scheduler since it doesn't have to worry > about register pressure at all. > > XXX perf data Test master post-ra-sched diff %diff bench_OglPSBump2 396.730 402.386 5.656 +1.400% bench_OglPSBump8 244.370 247.591 3.221 +1.300% bench_OglPSPhong 241.117 242.002 0.885 +0.300% bench_OglPSPom 59.555 59.7250.170 +0.200% bench_OglShMapPcf 86.149 102.346 16.197 +18.800% bench_OglVSTangent 388.849 395.489 6.640 +1.700% bench_trex 65.471 65.8620.390 +0.500% bench_trexoff 69.562 70.1500.588 +0.800% Unfortunately, neither of the unigin benchmarks (heaven or vally) seemed to render correctly. I just got white on both master and your branch. Not sure if we have a bug or if they just weren't running right. In any case, ministat didn't notice any difference in them. >>> >>> I believe they're called "features" :) Try with >>> disable_blend_func_extended=true >> >> I pulled in a more recent drirc and am re-running those two. > > They're not in the latest drirc... probably should be added back in. I used the drirc corresponding to the mesa commits I was testing. Given that it's actually rendering stuff, I'm going to say it's probably ok. --Jason ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 2:28 PM, Jason Ekstrand wrote: > On Sat, Oct 3, 2015 at 11:26 AM, Ilia Mirkin wrote: >> On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand wrote: >>> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: Before, we would only do scheduling after register allocation if we spilled, despite the fact that the pre-RA scheduler was only supposed to be for register pressure and set the latencies of every instruction to 1. This meant that unless we spilled, which we rarely do, then we never considered instruction latencies at all, and we usually never bothered to try and hide texture fetch latency. Although a later commit removes the setting the latency to 1 part, we still want to always run the post-RA scheduler since it's able to take the false dependencies that the register allocator creates into account, and it can be more aggressive than the pre-RA scheduler since it doesn't have to worry about register pressure at all. XXX perf data >>> >>> Test master post-ra-sched diff %diff >>> bench_OglPSBump2 396.730 402.386 5.656 +1.400% >>> bench_OglPSBump8 244.370 247.591 3.221 +1.300% >>> bench_OglPSPhong 241.117 242.002 0.885 +0.300% >>> bench_OglPSPom 59.555 59.7250.170 +0.200% >>> bench_OglShMapPcf 86.149 102.346 16.197 +18.800% >>> bench_OglVSTangent 388.849 395.489 6.640 +1.700% >>> bench_trex 65.471 65.8620.390 +0.500% >>> bench_trexoff 69.562 70.1500.588 +0.800% >>> >>> Unfortunately, neither of the unigin benchmarks (heaven or vally) >>> seemed to render correctly. I just got white on both master and your >>> branch. Not sure if we have a bug or if they just weren't running >>> right. In any case, ministat didn't notice any difference in them. >> >> I believe they're called "features" :) Try with >> disable_blend_func_extended=true > > I pulled in a more recent drirc and am re-running those two. They're not in the latest drirc... probably should be added back in. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: Remove CSE pass.
On Sat, Oct 3, 2015 at 1:57 PM, Matt Turner wrote: > With NIR, it actually hurts things. Buuutt not everything uses NIR. Of course I'm sure it has a similarly negative effect with nouveau/codegen, but I'm not so sure about things like nv30 which don't have an optimizing compiler backend. IMHO there should be a bit somewhere in the compiler options that indicates whether the driver implements an optimizing compiler, and if so, then all these idiotic optimizations should be removed. [I realize some are needed for correctness, obviously keep those.] -ilia > > total instructions in shared programs: 6529329 -> 652 (-0.01%) > instructions in affected programs: 14833 -> 14392 (-2.97%) > helped:299 > HURT: 1 > > In all affected programs I inspected (including the single hurt one) the > pass CSE'd some multiplies and caused some reassociation (e.g., caused > (A * B) * C to be A * (B * C)) when the original intermediate result was > reused elsewhere. > --- > src/glsl/Makefile.sources | 1 - > src/glsl/glsl_parser_extras.cpp | 1 - > src/glsl/ir_optimization.h | 1 - > src/glsl/opt_cse.cpp| 472 > > 4 files changed, 475 deletions(-) > delete mode 100644 src/glsl/opt_cse.cpp > > diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources > index 32b6dba..7083246 100644 > --- a/src/glsl/Makefile.sources > +++ b/src/glsl/Makefile.sources > @@ -184,7 +184,6 @@ LIBGLSL_FILES = \ > opt_constant_variable.cpp \ > opt_copy_propagation.cpp \ > opt_copy_propagation_elements.cpp \ > - opt_cse.cpp \ > opt_dead_builtin_variables.cpp \ > opt_dead_builtin_varyings.cpp \ > opt_dead_code.cpp \ > diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp > index f554241..b521c5f 100644 > --- a/src/glsl/glsl_parser_extras.cpp > +++ b/src/glsl/glsl_parser_extras.cpp > @@ -1899,7 +1899,6 @@ do_common_optimization(exec_list *ir, bool linked, >progress = do_constant_variable_unlinked(ir) || progress; > progress = do_constant_folding(ir) || progress; > progress = do_minmax_prune(ir) || progress; > - progress = do_cse(ir) || progress; > progress = do_rebalance_tree(ir) || progress; > progress = do_algebraic(ir, native_integers, options) || progress; > progress = do_lower_jumps(ir) || progress; > diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h > index 265b223..ce5c492 100644 > --- a/src/glsl/ir_optimization.h > +++ b/src/glsl/ir_optimization.h > @@ -87,7 +87,6 @@ bool do_constant_variable_unlinked(exec_list *instructions); > bool do_copy_propagation(exec_list *instructions); > bool do_copy_propagation_elements(exec_list *instructions); > bool do_constant_propagation(exec_list *instructions); > -bool do_cse(exec_list *instructions); > void do_dead_builtin_varyings(struct gl_context *ctx, >gl_shader *producer, gl_shader *consumer, >unsigned num_tfeedback_decls, > diff --git a/src/glsl/opt_cse.cpp b/src/glsl/opt_cse.cpp > deleted file mode 100644 > index 4b8e9a0..000 > --- a/src/glsl/opt_cse.cpp > +++ /dev/null > @@ -1,472 +0,0 @@ > -/* > - * Copyright © 2013 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 opt_cse.cpp > - * > - * constant subexpression elimination at the GLSL IR level. > - * > - * Compare to brw_fs_cse.cpp for a more complete CSE implementation. This > one > - * is generic and handles texture operations, but it's rather simple > currently > - * and doesn't support modification of variables in the available expressions > - * list, so it can't do variables other than uniforms or shader inputs. > - */ > - > -#include "ir.h" > -#incl
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 11:26 AM, Ilia Mirkin wrote: > On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand wrote: >> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: >>> Before, we would only do scheduling after register allocation if we >>> spilled, despite the fact that the pre-RA scheduler was only supposed to >>> be for register pressure and set the latencies of every instruction to >>> 1. This meant that unless we spilled, which we rarely do, then we never >>> considered instruction latencies at all, and we usually never bothered >>> to try and hide texture fetch latency. Although a later commit removes >>> the setting the latency to 1 part, we still want to always run the >>> post-RA scheduler since it's able to take the false dependencies that >>> the register allocator creates into account, and it can be more >>> aggressive than the pre-RA scheduler since it doesn't have to worry >>> about register pressure at all. >>> >>> XXX perf data >> >> Test master post-ra-sched diff %diff >> bench_OglPSBump2 396.730 402.386 5.656 +1.400% >> bench_OglPSBump8 244.370 247.591 3.221 +1.300% >> bench_OglPSPhong 241.117 242.002 0.885 +0.300% >> bench_OglPSPom 59.555 59.7250.170 +0.200% >> bench_OglShMapPcf 86.149 102.346 16.197 +18.800% >> bench_OglVSTangent 388.849 395.489 6.640 +1.700% >> bench_trex 65.471 65.8620.390 +0.500% >> bench_trexoff 69.562 70.1500.588 +0.800% >> >> Unfortunately, neither of the unigin benchmarks (heaven or vally) >> seemed to render correctly. I just got white on both master and your >> branch. Not sure if we have a bug or if they just weren't running >> right. In any case, ministat didn't notice any difference in them. > > I believe they're called "features" :) Try with > disable_blend_func_extended=true I pulled in a more recent drirc and am re-running those two. >> >>> Signed-off-by: Connor Abbott >>> --- >>> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp >>> b/src/mesa/drivers/dri/i965/brw_fs.cpp >>> index b269ade..14a9fdf 100644 >>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp >>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp >>> @@ -4981,8 +4981,7 @@ fs_visitor::allocate_registers() >>> if (failed) >>>return; >>> >>> - if (!allocated_without_spills) >>> - schedule_instructions(SCHEDULE_POST); >>> + schedule_instructions(SCHEDULE_POST); >>> >>> if (last_scratch > 0) >>>prog_data->total_scratch = brw_get_scratch_size(last_scratch); >>> -- >>> 2.1.0 >>> >>> ___ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand wrote: > On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: >> Before, we would only do scheduling after register allocation if we >> spilled, despite the fact that the pre-RA scheduler was only supposed to >> be for register pressure and set the latencies of every instruction to >> 1. This meant that unless we spilled, which we rarely do, then we never >> considered instruction latencies at all, and we usually never bothered >> to try and hide texture fetch latency. Although a later commit removes >> the setting the latency to 1 part, we still want to always run the >> post-RA scheduler since it's able to take the false dependencies that >> the register allocator creates into account, and it can be more >> aggressive than the pre-RA scheduler since it doesn't have to worry >> about register pressure at all. >> >> XXX perf data > > Test master post-ra-sched diff %diff > bench_OglPSBump2 396.730 402.386 5.656 +1.400% > bench_OglPSBump8 244.370 247.591 3.221 +1.300% > bench_OglPSPhong 241.117 242.002 0.885 +0.300% > bench_OglPSPom 59.555 59.7250.170 +0.200% > bench_OglShMapPcf 86.149 102.346 16.197 +18.800% > bench_OglVSTangent 388.849 395.489 6.640 +1.700% > bench_trex 65.471 65.8620.390 +0.500% > bench_trexoff 69.562 70.1500.588 +0.800% > > Unfortunately, neither of the unigin benchmarks (heaven or vally) > seemed to render correctly. I just got white on both master and your > branch. Not sure if we have a bug or if they just weren't running > right. In any case, ministat didn't notice any difference in them. I believe they're called "features" :) Try with disable_blend_func_extended=true > >> Signed-off-by: Connor Abbott >> --- >> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp >> b/src/mesa/drivers/dri/i965/brw_fs.cpp >> index b269ade..14a9fdf 100644 >> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp >> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp >> @@ -4981,8 +4981,7 @@ fs_visitor::allocate_registers() >> if (failed) >>return; >> >> - if (!allocated_without_spills) >> - schedule_instructions(SCHEDULE_POST); >> + schedule_instructions(SCHEDULE_POST); >> >> if (last_scratch > 0) >>prog_data->total_scratch = brw_get_scratch_size(last_scratch); >> -- >> 2.1.0 >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/6] i965/sched: use liveness analysis for computing register pressure
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote:
> Previously, we were using some heuristics to try and detect when a write
> was about to begin a live range, or when a read was about to end a live
> range. We never used the liveness analysis information used by the
> register allocator, though, which meant that the scheduler's and the
> allocator's ideas of when a live range began and ended were different.
> Not only did this make our estimate of the register pressure benefit of
> scheduling an instruction wrong in some cases, but it was preventing us
> from knowing the actual register pressure when scheduling each
> instruction, which we want to have in order to switch to register
> pressure scheduling only when the register pressure is too high.
>
> This commit rewrites the register pressure tracking code to use the same
> model as our register allocator currently uses. We use the results of
> liveness analysis, as well as the compute_payload_ranges() function that
> we split out in the last commit. This means that we compute live ranges
> twice on each round through the register allocator, although we could
> speed it up by only recomputing the ranges and not the live in/live out
> sets after scheduling, since we only shuffle around instructions within
> a single basic block when we schedule.
>
> Shader-db results on bdw:
>
> total instructions in shared programs: 7130187 -> 7129880 (-0.00%)
> instructions in affected programs: 1744 -> 1437 (-17.60%)
> helped: 1
> HURT: 1
What are the two affected programs? Obviously, something stopped
spilling and something else started.
> total cycles in shared programs: 172535126 -> 172473226 (-0.04%)
> cycles in affected programs: 11338636 -> 11276736 (-0.55%)
> helped: 876
> HURT: 873
>
> LOST: 8
> GAINED: 0
> Signed-off-by: Connor Abbott
> ---
> The results are a wash, but this is needed for a lot of the more
> experimental things I want to do. I can drop this if there are any
> objections.
>
> .../drivers/dri/i965/brw_schedule_instructions.cpp | 300
> +
> 1 file changed, 244 insertions(+), 56 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> index 22a493f..6b8792b 100644
> --- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp
> @@ -26,6 +26,7 @@
> */
>
> #include "brw_fs.h"
> +#include "brw_fs_live_variables.h"
> #include "brw_vec4.h"
> #include "brw_cfg.h"
> #include "brw_shader.h"
> @@ -400,22 +401,49 @@ schedule_node::set_latency_gen7(bool is_haswell)
> class instruction_scheduler {
> public:
> instruction_scheduler(backend_shader *s, int grf_count,
> + int hw_reg_count, int block_count,
> instruction_scheduler_mode mode)
> {
>this->bs = s;
>this->mem_ctx = ralloc_context(NULL);
>this->grf_count = grf_count;
> + this->hw_reg_count = hw_reg_count;
>this->instructions.make_empty();
>this->instructions_to_schedule = 0;
>this->post_reg_alloc = (mode == SCHEDULE_POST);
>this->mode = mode;
>this->time = 0;
>if (!post_reg_alloc) {
> - this->remaining_grf_uses = rzalloc_array(mem_ctx, int, grf_count);
> - this->grf_active = rzalloc_array(mem_ctx, bool, grf_count);
> + this->reg_pressure_in = rzalloc_array(mem_ctx, int, block_count);
> +
> + this->livein = ralloc_array(mem_ctx, BITSET_WORD *, block_count);
> + for (int i = 0; i < block_count; i++)
> +this->livein[i] = rzalloc_array(mem_ctx, BITSET_WORD,
> +BITSET_WORDS(grf_count));
> +
> + this->liveout = ralloc_array(mem_ctx, BITSET_WORD *, block_count);
> + for (int i = 0; i < block_count; i++)
> +this->liveout[i] = rzalloc_array(mem_ctx, BITSET_WORD,
> + BITSET_WORDS(grf_count));
> +
> + this->hw_liveout = ralloc_array(mem_ctx, BITSET_WORD *,
> block_count);
> + for (int i = 0; i < block_count; i++)
> +this->hw_liveout[i] = rzalloc_array(mem_ctx, BITSET_WORD,
> +BITSET_WORDS(hw_reg_count));
> +
> + this->written = rzalloc_array(mem_ctx, bool, grf_count);
> +
> + this->reads_remaining = rzalloc_array(mem_ctx, int, grf_count);
> +
> + this->hw_reads_remaining = rzalloc_array(mem_ctx, int,
> hw_reg_count);
>} else {
> - this->remaining_grf_uses = NULL;
> - this->grf_active = NULL;
> + this->reg_pressure_in = NULL;
> + this->livein = NULL;
> + this->liveout = NULL;
> + this->hw_liveout = NULL;
> + this->written = NULL;
> + this->reads_remaining = NULL;
> + this->hw_reads_remaining = NULL;
>}
> }
>
> @@ -442,7 +470,8 @@ pu
Re: [Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott wrote: > Before, we would only do scheduling after register allocation if we > spilled, despite the fact that the pre-RA scheduler was only supposed to > be for register pressure and set the latencies of every instruction to > 1. This meant that unless we spilled, which we rarely do, then we never > considered instruction latencies at all, and we usually never bothered > to try and hide texture fetch latency. Although a later commit removes > the setting the latency to 1 part, we still want to always run the > post-RA scheduler since it's able to take the false dependencies that > the register allocator creates into account, and it can be more > aggressive than the pre-RA scheduler since it doesn't have to worry > about register pressure at all. > > XXX perf data Test master post-ra-sched diff %diff bench_OglPSBump2 396.730 402.386 5.656 +1.400% bench_OglPSBump8 244.370 247.591 3.221 +1.300% bench_OglPSPhong 241.117 242.002 0.885 +0.300% bench_OglPSPom 59.555 59.7250.170 +0.200% bench_OglShMapPcf 86.149 102.346 16.197 +18.800% bench_OglVSTangent 388.849 395.489 6.640 +1.700% bench_trex 65.471 65.8620.390 +0.500% bench_trexoff 69.562 70.1500.588 +0.800% Unfortunately, neither of the unigin benchmarks (heaven or vally) seemed to render correctly. I just got white on both master and your branch. Not sure if we have a bug or if they just weren't running right. In any case, ministat didn't notice any difference in them. > Signed-off-by: Connor Abbott > --- > src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp > b/src/mesa/drivers/dri/i965/brw_fs.cpp > index b269ade..14a9fdf 100644 > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp > @@ -4981,8 +4981,7 @@ fs_visitor::allocate_registers() > if (failed) >return; > > - if (!allocated_without_spills) > - schedule_instructions(SCHEDULE_POST); > + schedule_instructions(SCHEDULE_POST); > > if (last_scratch > 0) >prog_data->total_scratch = brw_get_scratch_size(last_scratch); > -- > 2.1.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] i965: Generalize predicated break pass for use in vec4 backend.
instructions in affected programs: 44204 -> 43762 (-1.00%)
helped:221
---
src/mesa/drivers/dri/i965/Makefile.sources | 2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
.../dri/i965/brw_fs_peephole_predicated_break.cpp | 149 -
src/mesa/drivers/dri/i965/brw_predicated_break.cpp | 148
src/mesa/drivers/dri/i965/brw_shader.h | 6 +-
src/mesa/drivers/dri/i965/brw_vec4.cpp | 1 +
6 files changed, 156 insertions(+), 152 deletions(-)
delete mode 100644
src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
create mode 100644 src/mesa/drivers/dri/i965/brw_predicated_break.cpp
diff --git a/src/mesa/drivers/dri/i965/Makefile.sources
b/src/mesa/drivers/dri/i965/Makefile.sources
index eb8196d..6f97f73 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -55,7 +55,6 @@ i965_FILES = \
brw_fs_live_variables.cpp \
brw_fs_live_variables.h \
brw_fs_nir.cpp \
- brw_fs_peephole_predicated_break.cpp \
brw_fs_reg_allocate.cpp \
brw_fs_register_coalesce.cpp \
brw_fs_saturate_propagation.cpp \
@@ -91,6 +90,7 @@ i965_FILES = \
brw_packed_float.c \
brw_performance_monitor.c \
brw_pipe_control.c \
+ brw_predicated_break.cpp \
brw_primitive_restart.c \
brw_program.c \
brw_program.h \
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 0320688..1187c67 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -4823,7 +4823,7 @@ fs_visitor::optimize()
OPT(opt_algebraic);
OPT(opt_cse);
OPT(opt_copy_propagate);
- OPT(opt_peephole_predicated_break);
+ OPT(opt_predicated_break, this);
OPT(opt_cmod_propagation);
OPT(dead_code_eliminate);
OPT(opt_peephole_sel);
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
deleted file mode 100644
index 29f2168..000
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ /dev/null
@@ -1,149 +0,0 @@
-/*
- * Copyright © 2013 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 "brw_fs.h"
-#include "brw_cfg.h"
-
-using namespace brw;
-
-/** @file brw_fs_peephole_predicated_break.cpp
- *
- * Loops are often structured as
- *
- * loop:
- *CMP.f0
- *(+f0) IF
- *BREAK
- *ENDIF
- *...
- *WHILE loop
- *
- * This peephole pass removes the IF and ENDIF instructions and predicates the
- * BREAK, dropping two instructions from the loop body.
- *
- * If the loop was a DO { ... } WHILE loop, it looks like
- *
- * loop:
- *...
- *CMP.f0
- *(+f0) IF
- *BREAK
- *ENDIF
- *WHILE loop
- *
- * and we can remove the BREAK instruction and predicate the WHILE.
- */
-
-bool
-fs_visitor::opt_peephole_predicated_break()
-{
- bool progress = false;
-
- foreach_block (block, cfg) {
- if (block->start_ip != block->end_ip)
- continue;
-
- /* BREAK and CONTINUE instructions, by definition, can only be found at
- * the ends of basic blocks.
- */
- backend_instruction *jump_inst = block->end();
- if (jump_inst->opcode != BRW_OPCODE_BREAK &&
- jump_inst->opcode != BRW_OPCODE_CONTINUE)
- continue;
-
- backend_instruction *if_inst = block->prev()->end();
- if (if_inst->opcode != BRW_OPCODE_IF)
- continue;
-
- backend_instruction *endif_inst = block->next()->start();
- if (endif_inst->opcode != BRW_OPCODE_ENDIF)
- continue;
-
- bblock_t *jump_block = block;
- bblock_t *if_block = jump_block->prev();
- bblock_t *endif_block = jump_block->next();
-
-
[Mesa-dev] [PATCH] i965/vec4: Remove more dead visitor/vertex program code.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 8
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 10 --
src/mesa/drivers/dri/i965/brw_vs.h | 5 -
3 files changed, 23 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 51b3161..d1fa095 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.h
+++ b/src/mesa/drivers/dri/i965/brw_vec4.h
@@ -223,9 +223,6 @@ public:
int implied_mrf_writes(vec4_instruction *inst);
- void emit_vp_sop(enum brw_conditional_mod condmod, dst_reg dst,
-src_reg src0, src_reg src1, src_reg one);
-
vec4_instruction *emit_minmax(enum brw_conditional_mod conditionalmod,
dst_reg dst,
src_reg src0, src_reg src1);
@@ -238,11 +235,6 @@ public:
*/
src_reg emit_uniformize(const src_reg &src);
- /**
-* Emit the correct dot-product instruction for the type of arguments
-*/
- void emit_dp(dst_reg dst, src_reg src0, src_reg src1, unsigned elements);
-
src_reg fix_3src_operand(const src_reg &src);
src_reg resolve_source_modifiers(const src_reg &src);
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
index 3e44036..ca7c018 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
@@ -278,16 +278,6 @@ vec4_visitor::SCRATCH_WRITE(const dst_reg &dst, const
src_reg &src,
return inst;
}
-void
-vec4_visitor::emit_dp(dst_reg dst, src_reg src0, src_reg src1, unsigned
elements)
-{
- static enum opcode dot_opcodes[] = {
- BRW_OPCODE_DP2, BRW_OPCODE_DP3, BRW_OPCODE_DP4
- };
-
- emit(dot_opcodes[elements - 2], dst, src0, src1);
-}
-
src_reg
vec4_visitor::fix_3src_operand(const src_reg &src)
{
diff --git a/src/mesa/drivers/dri/i965/brw_vs.h
b/src/mesa/drivers/dri/i965/brw_vs.h
index 96d2435..19551c9 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.h
+++ b/src/mesa/drivers/dri/i965/brw_vs.h
@@ -105,16 +105,11 @@ protected:
private:
int setup_attributes(int payload_reg);
- void setup_vp_regs();
void setup_uniform_clipplane_values();
void emit_clip_distances(dst_reg reg, int offset);
- dst_reg get_vp_dst_reg(const prog_dst_register &dst);
- src_reg get_vp_src_reg(const prog_src_register &src);
const struct brw_vs_prog_key *const key;
struct brw_vs_prog_data * const vs_prog_data;
- src_reg *vp_temp_regs;
- src_reg vp_addr_reg;
gl_clip_plane *clip_planes;
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] i965/fs: Use backend_instruction in predicated break peephole.
We're not using any fs_inst fields, and the next commit will make the peephole used by the vec4 backend. --- src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp index 8f7bd83..29f2168 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp @@ -66,16 +66,16 @@ fs_visitor::opt_peephole_predicated_break() /* BREAK and CONTINUE instructions, by definition, can only be found at * the ends of basic blocks. */ - fs_inst *jump_inst = (fs_inst *)block->end(); + backend_instruction *jump_inst = block->end(); if (jump_inst->opcode != BRW_OPCODE_BREAK && jump_inst->opcode != BRW_OPCODE_CONTINUE) continue; - fs_inst *if_inst = (fs_inst *)block->prev()->end(); + backend_instruction *if_inst = block->prev()->end(); if (if_inst->opcode != BRW_OPCODE_IF) continue; - fs_inst *endif_inst = (fs_inst *)block->next()->start(); + backend_instruction *endif_inst = block->next()->start(); if (endif_inst->opcode != BRW_OPCODE_ENDIF) continue; @@ -120,7 +120,7 @@ fs_visitor::opt_peephole_predicated_break() * the two basic blocks. */ bblock_t *while_block = earlier_block->next(); - fs_inst *while_inst = (fs_inst *)while_block->start(); + backend_instruction *while_inst = while_block->start(); if (jump_inst->opcode == BRW_OPCODE_BREAK && while_inst->opcode == BRW_OPCODE_WHILE && -- 2.4.9 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl: Remove CSE pass.
With NIR, it actually hurts things.
total instructions in shared programs: 6529329 -> 652 (-0.01%)
instructions in affected programs: 14833 -> 14392 (-2.97%)
helped:299
HURT: 1
In all affected programs I inspected (including the single hurt one) the
pass CSE'd some multiplies and caused some reassociation (e.g., caused
(A * B) * C to be A * (B * C)) when the original intermediate result was
reused elsewhere.
---
src/glsl/Makefile.sources | 1 -
src/glsl/glsl_parser_extras.cpp | 1 -
src/glsl/ir_optimization.h | 1 -
src/glsl/opt_cse.cpp| 472
4 files changed, 475 deletions(-)
delete mode 100644 src/glsl/opt_cse.cpp
diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index 32b6dba..7083246 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -184,7 +184,6 @@ LIBGLSL_FILES = \
opt_constant_variable.cpp \
opt_copy_propagation.cpp \
opt_copy_propagation_elements.cpp \
- opt_cse.cpp \
opt_dead_builtin_variables.cpp \
opt_dead_builtin_varyings.cpp \
opt_dead_code.cpp \
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index f554241..b521c5f 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -1899,7 +1899,6 @@ do_common_optimization(exec_list *ir, bool linked,
progress = do_constant_variable_unlinked(ir) || progress;
progress = do_constant_folding(ir) || progress;
progress = do_minmax_prune(ir) || progress;
- progress = do_cse(ir) || progress;
progress = do_rebalance_tree(ir) || progress;
progress = do_algebraic(ir, native_integers, options) || progress;
progress = do_lower_jumps(ir) || progress;
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 265b223..ce5c492 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -87,7 +87,6 @@ bool do_constant_variable_unlinked(exec_list *instructions);
bool do_copy_propagation(exec_list *instructions);
bool do_copy_propagation_elements(exec_list *instructions);
bool do_constant_propagation(exec_list *instructions);
-bool do_cse(exec_list *instructions);
void do_dead_builtin_varyings(struct gl_context *ctx,
gl_shader *producer, gl_shader *consumer,
unsigned num_tfeedback_decls,
diff --git a/src/glsl/opt_cse.cpp b/src/glsl/opt_cse.cpp
deleted file mode 100644
index 4b8e9a0..000
--- a/src/glsl/opt_cse.cpp
+++ /dev/null
@@ -1,472 +0,0 @@
-/*
- * Copyright © 2013 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 opt_cse.cpp
- *
- * constant subexpression elimination at the GLSL IR level.
- *
- * Compare to brw_fs_cse.cpp for a more complete CSE implementation. This one
- * is generic and handles texture operations, but it's rather simple currently
- * and doesn't support modification of variables in the available expressions
- * list, so it can't do variables other than uniforms or shader inputs.
- */
-
-#include "ir.h"
-#include "ir_visitor.h"
-#include "ir_rvalue_visitor.h"
-#include "ir_basic_block.h"
-#include "ir_optimization.h"
-#include "ir_builder.h"
-#include "glsl_types.h"
-
-using namespace ir_builder;
-
-static bool debug = false;
-
-namespace {
-
-/**
- * This is the record of an available expression for common subexpression
- * elimination.
- */
-class ae_entry : public exec_node
-{
-public:
- ae_entry(ir_instruction *base_ir, ir_rvalue **val)
- : val(val), base_ir(base_ir)
- {
- assert(val);
- assert(*val);
- assert(base_ir);
-
- var = NULL;
- }
-
- void init(ir_instruction *base_ir, ir_rvalue **val)
- {
- this->val = val;
- this->base_ir = base_ir;
- this->var = NULL;
-
- a
[Mesa-dev] [PATCH 1/3] i965/fs: Remove SNB embedded-comparison support from optimizations.
We never emit IF instructions with an embedded comparison (lost in the
switch to NIR), so this code is not used. If we want to readd support,
we should have a pass that merges a CMP instruction with an IF or a
WHILE instruction after other optimizations have run.
---
.../dri/i965/brw_fs_peephole_predicated_break.cpp | 14 ++
src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp | 21 +
2 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
index b75f40b..8f7bd83 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_peephole_predicated_break.cpp
@@ -83,18 +83,8 @@ fs_visitor::opt_peephole_predicated_break()
bblock_t *if_block = jump_block->prev();
bblock_t *endif_block = jump_block->next();
- /* For Sandybridge with IF with embedded comparison we need to emit an
- * instruction to set the flag register.
- */
- if (devinfo->gen == 6 && if_inst->conditional_mod) {
- const fs_builder ibld(this, if_block, if_inst);
- ibld.CMP(ibld.null_reg_d(), if_inst->src[0], if_inst->src[1],
- if_inst->conditional_mod);
- jump_inst->predicate = BRW_PREDICATE_NORMAL;
- } else {
- jump_inst->predicate = if_inst->predicate;
- jump_inst->predicate_inverse = if_inst->predicate_inverse;
- }
+ jump_inst->predicate = if_inst->predicate;
+ jump_inst->predicate_inverse = if_inst->predicate_inverse;
bblock_t *earlier_block = if_block;
if (if_block->start_ip == if_block->end_ip) {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
index d190d8e..8613725 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_sel_peephole.cpp
@@ -155,18 +155,6 @@ fs_visitor::opt_peephole_sel()
if (movs == 0)
continue;
- enum brw_predicate predicate;
- bool predicate_inverse;
- if (devinfo->gen == 6 && if_inst->conditional_mod) {
- /* For Sandybridge with IF with embedded comparison */
- predicate = BRW_PREDICATE_NORMAL;
- predicate_inverse = false;
- } else {
- /* Separate CMP and IF instructions */
- predicate = if_inst->predicate;
- predicate_inverse = if_inst->predicate_inverse;
- }
-
/* Generate SEL instructions for pairs of MOVs to a common destination.
*/
for (int i = 0; i < movs; i++) {
if (!then_mov[i] || !else_mov[i])
@@ -195,13 +183,6 @@ fs_visitor::opt_peephole_sel()
if (movs == 0)
continue;
- /* Emit a CMP if our IF used the embedded comparison */
- if (devinfo->gen == 6 && if_inst->conditional_mod) {
- const fs_builder ibld(this, block, if_inst);
- ibld.CMP(ibld.null_reg_d(), if_inst->src[0], if_inst->src[1],
- if_inst->conditional_mod);
- }
-
for (int i = 0; i < movs; i++) {
const fs_builder ibld = fs_builder(this, then_block, then_mov[i])
.at(block, if_inst);
@@ -220,7 +201,7 @@ fs_visitor::opt_peephole_sel()
ibld.MOV(src0, then_mov[i]->src[0]);
}
-set_predicate_inv(predicate, predicate_inverse,
+set_predicate_inv(if_inst->predicate, if_inst->predicate_inverse,
ibld.SEL(then_mov[i]->dst, src0,
else_mov[i]->src[0]));
}
--
2.4.9
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: remove TC L2 cache flush for index buffers on VI
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_draw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 43170ec..5face42 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -813,9 +813,9 @@ void si_draw_vbo(struct pipe_context *ctx, const struct
pipe_draw_info *info)
}
}
- /* TODO: VI should read index buffers through TC, so this shouldn't be
-* needed on VI. */
- if (info->indexed && r600_resource(ib.buffer)->TC_L2_dirty) {
+ /* VI reads index buffers through TC L2. */
+ if (info->indexed && sctx->b.chip_class <= CIK &&
+ r600_resource(ib.buffer)->TC_L2_dirty) {
sctx->b.flags |= SI_CONTEXT_INV_TC_L2;
r600_resource(ib.buffer)->TC_L2_dirty = false;
}
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radeonsi: fix a GS hang on VI
From: Marek Olšák
Broken by one of the cleanups: 0d46c3bc9d09b376d74f7399e1a2d1b0a923640b
Not applicable to stable.
---
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si_state_shaders.c | 18 ++
2 files changed, 19 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
b/src/gallium/drivers/radeonsi/si_pipe.h
index 3ff4b46..2abd5b5 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.h
+++ b/src/gallium/drivers/radeonsi/si_pipe.h
@@ -192,6 +192,7 @@ struct si_context {
/* Precomputed states. */
struct si_pm4_state *init_config;
+ boolinit_config_has_vgt_flush;
struct si_pm4_state *vgt_shader_config[4];
/* With rasterizer discard, there doesn't have to be a pixel shader.
* In that case, we bind this one: */
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index 77c585f..f673388 100644
--- a/src/gallium/drivers/radeonsi/si_state_shaders.c
+++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
@@ -1136,6 +1136,20 @@ static void si_emit_spi_ps_input(struct si_context
*sctx, struct r600_atom *atom
sctx->force_persample_interp);
}
+/**
+ * Writing CONFIG or UCONFIG VGT registers requires VGT_FLUSH before that.
+ */
+static void si_init_config_add_vgt_flush(struct si_context *sctx)
+{
+ if (sctx->init_config_has_vgt_flush)
+ return;
+
+ si_pm4_cmd_begin(sctx->init_config, PKT3_EVENT_WRITE);
+ si_pm4_cmd_add(sctx->init_config, EVENT_TYPE(V_028A90_VGT_FLUSH) |
EVENT_INDEX(0));
+ si_pm4_cmd_end(sctx->init_config, false);
+ sctx->init_config_has_vgt_flush = true;
+}
+
/* Initialize state related to ESGS / GSVS ring buffers */
static void si_init_gs_rings(struct si_context *sctx)
{
@@ -1156,6 +1170,8 @@ static void si_init_gs_rings(struct si_context *sctx)
return;
}
+ si_init_config_add_vgt_flush(sctx);
+
/* Append these registers to the init config state. */
if (sctx->b.chip_class >= CIK) {
if (sctx->b.chip_class >= VI) {
@@ -1402,6 +1418,8 @@ static void si_init_tess_factor_ring(struct si_context
*sctx)
assert(((sctx->tf_ring->width0 / 4) & C_030938_SIZE) == 0);
+ si_init_config_add_vgt_flush(sctx);
+
/* Append these registers to the init config state. */
if (sctx->b.chip_class >= CIK) {
si_pm4_set_reg(sctx->init_config, R_030938_VGT_TF_RING_SIZE,
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i915: Fix texcoord vs. varying collision in fragment programs
On Wed, Aug 13, 2014 at 10:07 AM, wrote:
> From: Ville Syrjälä
>
> i915 fragment programs utilize the texture coordinate registers
> for both texture coordinates and varyings. Unfortunately the
> code doesn't check if the same index might be in use for both.
> It just naively uses the index to pick a texture unit, which
> could lead to collisions.
>
> Add an extra mapping step to allocate non conflicting texture
> units for both uses.
>
> The issue can be reproduced with a pair of simple shaders like
> these:
> attribute vec4 in_mod;
> varying vec4 mod;
> void main() {
>mod = in_mod;
>gl_TexCoord[0] = gl_MultiTexCoord0;
>gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
> }
>
> varying vec4 mod;
> uniform sampler2D tex;
> void main() {
>gl_FragColor = texture2D(tex, vec2(gl_TexCoord[0])) * mod;
> }
>
> This was tested on a PNV.
>
> Signed-off-by: Ville Syrjälä
> ---
> src/mesa/drivers/dri/i915/i915_context.h | 14 ++---
> src/mesa/drivers/dri/i915/i915_fragprog.c | 86
> +--
> 2 files changed, 74 insertions(+), 26 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i915/i915_context.h
> b/src/mesa/drivers/dri/i915/i915_context.h
> index 34af202..2615bd6 100644
> --- a/src/mesa/drivers/dri/i915/i915_context.h
> +++ b/src/mesa/drivers/dri/i915/i915_context.h
> @@ -115,6 +115,8 @@ enum {
> I915_RASTER_RULES_SETUP_SIZE,
> };
>
> +#define I915_TEX_UNITS 8
> +
> #define I915_MAX_CONSTANT 32
> #define I915_CONSTANT_SIZE (2+(4*I915_MAX_CONSTANT))
>
> @@ -194,7 +196,8 @@ struct i915_fragment_program
>
> /* Helpers for i915_fragprog.c:
> */
> - GLuint wpos_tex;
> + uint8_t texcoord_mapping[I915_TEX_UNITS];
> + uint8_t wpos_tex;
I see idr committed this. Coverity is warning about "p->wpos_tex !=
-1" always being true, but I'm not sure why it wouldn't have
recognized that before -- wpos_tex was still unsigned.
It dates back to commit fceda4342cad.
Not sure if it's worth fixing.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1
https://bugs.freedesktop.org/show_bug.cgi?id=92265 --- Comment #3 from Emil Velikov --- (In reply to Jason Ekstrand from comment #2) > I'm going to hazard a guess and say that mesa is probably the only ES driver > to support GL_EXT_abgr. > Sounds about right according to ilia's glxinfo list http://people.freedesktop.org/~imirkin/glxinfo/ -- 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 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1
https://bugs.freedesktop.org/show_bug.cgi?id=92265 Jason Ekstrand changed: What|Removed |Added CC||i...@freedesktop.org, ||ja...@jlekstrand.net, ||k...@bitplanet.net --- Comment #2 from Jason Ekstrand --- There appear to be two potential problems here. One is that Weston tries to use GL_EXT_abgr in ES even though it is not an ES extension. The second is that mesa advertises it and then falls over when you try to use it. If we weren't advertising it, Weston would fall back to other paths and be OK. I see two options: 1) Actually support the extension even though it isn't technically an ES extension. 2) Stop advertising it. I'm going to hazard a guess and say that mesa is probably the only ES driver to support GL_EXT_abgr. Thoughts? -- 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 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] i965: Resolve color for all active shader images in intel_update_state().
Jordan Justen writes:
> From: Francisco Jerez
>
> Fixes
> arb_shader_image_load_store/execution/load-from-cleared-image.shader_test
>
> Cc: Chris Wilson
> Cc: Jason Ekstrand
> Tested-by: Jordan Justen
> ---
> RE: i965: Perform an explicit flush after doing _mesa_meta_pbo_TexSubImage
>
> curro has some concerns about potential perf impact by this and
> wanted it to be checked on small-core w/CPU bound apps.
> Unfortunately, he is on vacation now.
I've benchmarked this on VLV and none of the CPU-bound tests in the
Finnish benchmarking system regress significantly, with n=6 and 95%
confidence level, so s/RFC/PATCH/. I'll CC mesa-stable so it probably
makes sense to keep this independent from Chris' VBO resolve series.
>
> src/mesa/drivers/dri/i965/brw_context.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index f0ed891..a274a43 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -189,6 +189,24 @@ intel_update_state(struct gl_context * ctx, GLuint
> new_state)
>brw_render_cache_set_check_flush(brw, tex_obj->mt->bo);
> }
>
> + /* Resolve color for each active shader image. */
> + for (unsigned i = 0; i < MESA_SHADER_STAGES; i++) {
> + const struct gl_shader *shader = ctx->_Shader->CurrentProgram[i] ?
> + ctx->_Shader->CurrentProgram[i]->_LinkedShaders[i] : NULL;
> +
> + if (unlikely(shader && shader->NumImages)) {
> + for (unsigned j = 0; j < shader->NumImages; j++) {
> +struct gl_image_unit *u =
> &ctx->ImageUnits[shader->ImageUnits[j]];
> +tex_obj = intel_texture_object(u->TexObj);
> +
> +if (tex_obj && tex_obj->mt) {
> + intel_miptree_resolve_color(brw, tex_obj->mt);
> + brw_render_cache_set_check_flush(brw, tex_obj->mt->bo);
> +}
> + }
> + }
> + }
> +
> _mesa_lock_context_textures(ctx);
> }
>
> --
> 2.5.0
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1
https://bugs.freedesktop.org/show_bug.cgi?id=92265 Boyan Ding changed: What|Removed |Added Component|EGL/Wayland |Mesa core Assignee|wayland-bugs@lists.freedesk |mesa-dev@lists.freedesktop. |top.org |org -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 10.6.9
Mesa 10.6.9 is now available. This release covers KDE crashes with i965, regression in Unreal Tournament with gallium drivers, fixes for Redway3D Flat (Demo) and Astromenace. The mangled GL build has also been fixed. NOTE: It is anticipated that 10.6.9 will be the final release in the 10.6 series. Users of 10.6 are encouraged to migrate to the 11.0 series in order to obtain future fixes. Brian Paul (1): st/mesa: try PIPE_BIND_RENDER_TARGET when choosing float texture formats Chris Wilson (1): i965: Remove early release of DRI2 miptree Emil Velikov (5): docs: add sha256 checksums for 10.6.8 cherry-ignore: add commit non applicable for 10.6 cherry-ignore: add commit non applicable for 10.6 Update version to 10.6.9 docs: add release notes for 10.6.9 Iago Toral Quiroga (1): mesa: Fix GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for default framebuffer. Ian Romanick (5): t_dd_dmatmp: Make "count" actually be the count t_dd_dmatmp: Clean up improper code formatting from previous patch t_dd_dmatmp: Use '& 3' instead of '% 4' everywhere t_dd_dmatmp: Pull out common 'count -= count & 3' code t_dd_dmatmp: Use addition instead of subtraction in loop bounds Jeremy Huddleston (1): configure.ac: Add support to enable read-only text segment on x86. Kristian Høgsberg Kristensen (1): i965: Respect stride and subreg_offset for ATTR registers Kyle Brenneman (3): glx: Fix build errors with --enable-mangling (v2) mapi: Make _glapi_get_stub work with "gl" or "mgl" prefix. glx: Don't hard-code the name "libGL.so.1" in driOpenDriver (v3) Leo Liu (1): radeon/vce: fix vui time_scale zero error Marek Olšák (1): st/mesa: fix front buffer regression after dropping st_validate_state in Blit Roland Scheidegger (1): mesa: fix mipmap generation for immutable, compressed textures git tag: mesa-10.6.9 ftp://ftp.freedesktop.org/pub/mesa/10.6.9/mesa-10.6.9.tar.gz MD5: a4ab6a78515ef20152aa35cb2383882f mesa-10.6.9.tar.gz SHA1: 656c2ce8779ad84b310937e539dc3cc4bb4587d9 mesa-10.6.9.tar.gz SHA256: 3406876aac67546d0c3e2cb97da330b62644c313e7992b95618662e13c54296a mesa-10.6.9.tar.gz PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.9/mesa-10.6.9.tar.gz.sig ftp://ftp.freedesktop.org/pub/mesa/10.6.9/mesa-10.6.9.tar.xz MD5: cdefe2c5715a7931dece84dfd7f641d3 mesa-10.6.9.tar.xz SHA1: 6f2a8bffcb37f233998dcda84ca8adce3563f9a0 mesa-10.6.9.tar.xz SHA256: b04c4de6280b863babc2929573da17218d92e9e4ba6272d548d135415723e8c3 mesa-10.6.9.tar.xz PGP: ftp://ftp.freedesktop.org/pub/mesa/10.6.9/mesa-10.6.9.tar.xz.sig -- -Emil signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 92265] Black windows in weston after update mesa to 11.0.2-1
https://bugs.freedesktop.org/show_bug.cgi?id=92265 Boyan Ding changed: What|Removed |Added CC||el...@igalia.com --- Comment #1 from Boyan Ding --- My mesa snapshot happened to have the commit mentioned above, but weston was okay. Updated mesa to current HEAD, and the problem described happened. Reverting 5edd996 (mesa: Use the effective internal format instead for validation) helps, so it should be the problematic commit. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] main/get: make KHR_debug enums available everywhere
On 24 September 2015 at 13:20, Emil Velikov wrote: > Hi all, > > On 16 September 2015 at 16:38, Emil Velikov wrote: >> From: Matthew Waters >> >> Move all the enums but CONTEXT_FLAGS. The spec seems quite explicit >> about the latter (wrt OpenGL ES) >> >> "In OpenGL ES versions prior to and including ES 3.1 there is no >> CONTEXT_FLAGS state and therefore the CONTEXT_FLAG_DEBUG_BIT cannot >> be queried." >> >> v2 [Emil Velikov] Rebase. >> v3 [Emil Veliokv] Drop the CONTEXT_FLAGS hunk - not applicable for GLES >> >> Signed-off-by: Matthew Waters >> Signed-off-by: Emil Velikov > > With the only (?) controversial piece of the series gone, are people > happy with the patches ? > If you think something is fishy and/or you'd like to take a look but > you're short on time atm, please let me know. > Humble ping. I am planning to push this series late Monday/Tuesday. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 91044] piglit spec/egl_khr_create_context/valid debug flag gles* fail
https://bugs.freedesktop.org/show_bug.cgi?id=91044 Emil Velikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Emil Velikov --- Fixed with commit 11cabc45b7124e51d5ead42db6dceb5a3755266b Author: Matthew Waters Date: Mon Sep 14 18:35:45 2015 +0100 egl: rework handling EGL_CONTEXT_FLAGS As of version 15 of the EGL_KHR_create_context spec, debug contexts are allowed for ES contexts. We should allow creation instead of erroring. While we're here provide a more comprehensive checking for the other two flags - ROBUST_ACCESS_BIT_KHR and FORWARD_COMPATIBLE_BIT_KHR -- 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 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl/dri2: expose srgb configs when KHR_gl_colorspace is available
On 3 October 2015 at 02:12, Marek Olšák wrote: > I'm not sure if this is correct or if we should just return NULL in > this case like the "case" statement above that does. > Actually I was thinking about bailing out when the requested attribute is set. I.e. diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 1740ee3..0450269 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -237,6 +237,8 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig *dri_config, int id, case __DRI_ATTRIB_FRAMEBUFFER_SRGB_CAPABLE: srgb = value != 0; + if (!dpy->Extensions.KHR_gl_colorspace && srgb) +return NULL; break; default: -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] i965: Don't print line numbers with INTEL_DEBUG=optimizer.
Not sure if this series in general was discarded after Matt's second
email on "Add a pass to predicate short blocks", but in any case, I find
this specific patch useful and LGTM. Just in case you were expecting for
someone taking a look to it:
Reviewed-by: Alejandro Piñeiro
On 29/09/15 00:26, Matt Turner wrote:
> The thing you want to do with the output files is diff them, which is
> made more difficult by line numbers changing.
> ---
> src/mesa/drivers/dri/i965/brw_shader.cpp | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 785cb27..15e340d 100644
> --- a/src/mesa/drivers/dri/i965/brw_shader.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
> @@ -1331,13 +1331,15 @@ backend_shader::dump_instructions(const char *name)
> if (cfg) {
>int ip = 0;
>foreach_block_and_inst(block, backend_instruction, inst, cfg) {
> - fprintf(file, "%4d: ", ip++);
> + if (!unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER))
> +fprintf(file, "%4d: ", ip++);
> dump_instruction(inst, file);
>}
> } else {
>int ip = 0;
>foreach_in_list(backend_instruction, inst, &instructions) {
> - fprintf(file, "%4d: ", ip++);
> + if (!unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER))
> +fprintf(file, "%4d: ", ip++);
> dump_instruction(inst, file);
>}
> }
--
Alejandro Piñeiro (apinhe...@igalia.com)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles
https://bugs.freedesktop.org/show_bug.cgi?id=77449 Bug 77449 depends on bug 91342, which changed state. Bug 91342 Summary: Very dark textures on some objects in indoors environments in Postal 2 https://bugs.freedesktop.org/show_bug.cgi?id=91342 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/3] V2: Improve GLSL support of GL_ARB_separate_shader_objects
On Sat, 03 Oct 2015 09:35:49 + Mike Lothian wrote: > Would it be better to have is_interstage=0 rather than a double negative? > Yes. I think it just need to set 1 in the constructor (forget to update it by the way...) as default value. Otherwise it can be renamed to is_unlinked_io (or something similar). > > > > In short, SSO allow to match by name but you can't make any hypothesis > > on the > > > previous/next stage. Therefore you must consider all inputs and output as > > > actives. > > > > New version based on Ian's feedbacks. > > * Real interstage variables of the program are still optimized > > * Both output and input of the program remains active > > * An old bug still remains if name and explicit location rendezvous are > > mixed > > > > Commits decription: > > 1/ add a not_interstage parameter that will be 1 when variable is either an > >input of output of the program. I didn't know where to put the > > ir_set_not_interstage_io > >function. Maybe it can be moved in linker.cpp. > > 2/ Set the interstage parameter based on the shader position in the > > pipeline > >program. Potentially can be squased with the previous one. > > 3/ Don't do deadcode removal of not_interstage variable with the exception > >of the built-in varyings because they don't impact location of others > > variables > > > > Gregory Hainaut (4): > > glsl IR: add not_interstage attribute to ir_variable > > glsl link: annotate not_interstage attribute of the ir_var after link > > phase > > glsl IR: only allow optimization of interstage variable > > allow compilation on my system > > > > configure.ac | 6 -- > > src/glsl/ir.h | 6 ++ > > src/glsl/ir_optimization.h | 2 ++ > > src/glsl/linker.cpp| 47 > > ++ > > src/glsl/opt_dead_code.cpp | 37 > > 5 files changed, 96 insertions(+), 2 deletions(-) > > > > -- > > 2.1.4 > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/3] V2: Improve GLSL support of GL_ARB_separate_shader_objects
Would it be better to have is_interstage=0 rather than a double negative? On Sat, 3 Oct 2015 10:32 am Gregory Hainaut wrote: > > In short, SSO allow to match by name but you can't make any hypothesis > on the > > previous/next stage. Therefore you must consider all inputs and output as > > actives. > > New version based on Ian's feedbacks. > * Real interstage variables of the program are still optimized > * Both output and input of the program remains active > * An old bug still remains if name and explicit location rendezvous are > mixed > > Commits decription: > 1/ add a not_interstage parameter that will be 1 when variable is either an >input of output of the program. I didn't know where to put the > ir_set_not_interstage_io >function. Maybe it can be moved in linker.cpp. > 2/ Set the interstage parameter based on the shader position in the > pipeline >program. Potentially can be squased with the previous one. > 3/ Don't do deadcode removal of not_interstage variable with the exception >of the built-in varyings because they don't impact location of others > variables > > Gregory Hainaut (4): > glsl IR: add not_interstage attribute to ir_variable > glsl link: annotate not_interstage attribute of the ir_var after link > phase > glsl IR: only allow optimization of interstage variable > allow compilation on my system > > configure.ac | 6 -- > src/glsl/ir.h | 6 ++ > src/glsl/ir_optimization.h | 2 ++ > src/glsl/linker.cpp| 47 > ++ > src/glsl/opt_dead_code.cpp | 37 > 5 files changed, 96 insertions(+), 2 deletions(-) > > -- > 2.1.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 0/3] V2: Improve GLSL support of GL_ARB_separate_shader_objects
> In short, SSO allow to match by name but you can't make any hypothesis on the > previous/next stage. Therefore you must consider all inputs and output as > actives. New version based on Ian's feedbacks. * Real interstage variables of the program are still optimized * Both output and input of the program remains active * An old bug still remains if name and explicit location rendezvous are mixed Commits decription: 1/ add a not_interstage parameter that will be 1 when variable is either an input of output of the program. I didn't know where to put the ir_set_not_interstage_io function. Maybe it can be moved in linker.cpp. 2/ Set the interstage parameter based on the shader position in the pipeline program. Potentially can be squased with the previous one. 3/ Don't do deadcode removal of not_interstage variable with the exception of the built-in varyings because they don't impact location of others variables Gregory Hainaut (4): glsl IR: add not_interstage attribute to ir_variable glsl link: annotate not_interstage attribute of the ir_var after link phase glsl IR: only allow optimization of interstage variable allow compilation on my system configure.ac | 6 -- src/glsl/ir.h | 6 ++ src/glsl/ir_optimization.h | 2 ++ src/glsl/linker.cpp| 47 ++ src/glsl/opt_dead_code.cpp | 37 5 files changed, 96 insertions(+), 2 deletions(-) -- 2.1.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 3/3] glsl IR: only allow optimization of interstage variable
GL_ARB_separate_shader_objects allow to match by name variable or block
interface. Input varying can't be removed as it is will impact the location
assignment.
It fixes the bug 79783 and likely any application that uses
GL_ARB_separate_shader_objects extension.
Signed-off-by: Gregory Hainaut
---
src/glsl/opt_dead_code.cpp | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index d70c855..9ddee4d 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -94,6 +94,24 @@ do_dead_code(exec_list *instructions, bool
uniform_locations_assigned)
|| !entry->declaration)
continue;
+ /* Section 7.4.1 (Shader Interface Matching) of the OpenGL 4.5
+ * (Core Profile) spec says:
+ *
+ *"With separable program objects, interfaces between shader
+ *stages may involve the outputs from one program object and the
+ *inputs from a second program object. For such interfaces, it is
+ *not possible to detect mismatches at link time, because the
+ *programs are linked separately. When each such program is
+ *linked, all inputs or outputs interfacing with another program
+ *stage are treated as active."
+ */
+ if (entry->var->data.not_interstage &&
+(!entry->var->data.explicit_location ||
+ entry->var->data.location >= VARYING_SLOT_VAR0) &&
+(entry->var->data.mode == ir_var_shader_in ||
+ entry->var->data.mode == ir_var_shader_out))
+ continue;
+
if (entry->assign) {
/* Remove a single dead assignment to the variable we found.
* Don't do so if it's a shader or function output or a shader
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 2/3] glsl link: annotate not_interstage attribute of the ir_var after link phase
Signed-off-by: Gregory Hainaut
---
src/glsl/linker.cpp | 47 +++
1 file changed, 47 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index fd69dbc..a4a8ab4 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -3378,6 +3378,51 @@ link_assign_subroutine_types(struct gl_shader_program
*prog)
}
}
+static void
+set_interstage_io(struct gl_shader_program *prog)
+{
+ unsigned first, last;
+
+ /* In monolithic build, IO can be freely optimized */
+ if (!prog->SeparateShader)
+ return;
+
+ first = MESA_SHADER_STAGES;
+ last = 0;
+
+ /* Determine first and last stage. Excluding the compute stage */
+ for (unsigned i = 0; i < MESA_SHADER_COMPUTE; i++) {
+ if (!prog->_LinkedShaders[i])
+ continue;
+ if (first == MESA_SHADER_STAGES)
+ first = i;
+ last = i;
+ }
+
+ if (first == MESA_SHADER_STAGES)
+ return;
+
+ for (unsigned stage = 0; stage < MESA_SHADER_STAGES; stage++) {
+ gl_shader *sh = prog->_LinkedShaders[stage];
+ if (!sh)
+ continue;
+
+ if (first == last) {
+ /* Single shader program */
+ if (first != MESA_SHADER_VERTEX)
+ir_set_not_interstage_io(sh->ir, ir_var_shader_in);
+ if (first != MESA_SHADER_FRAGMENT)
+ir_set_not_interstage_io(sh->ir, ir_var_shader_out);
+ } else {
+ /* Multiple shaders program */
+ if (stage == first && stage != MESA_SHADER_VERTEX)
+ir_set_not_interstage_io(sh->ir, ir_var_shader_in);
+ else if (stage == last && stage != MESA_SHADER_FRAGMENT)
+ir_set_not_interstage_io(sh->ir, ir_var_shader_out);
+ }
+ }
+}
+
void
link_shaders(struct gl_context *ctx, struct gl_shader_program *prog)
{
@@ -3637,6 +3682,8 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
}
}
+ set_interstage_io(prog);
+
if (!interstage_cross_validate_uniform_blocks(prog))
goto done;
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC 1/3] glsl IR: add not_interstage attribute to ir_variable
The negative form was used to keep interstage as the default value
Note: I put the ir_set_not_interstage_io function in opt_dead_code
because it will be used to disable deadcode optimization. Feel free
to point me a better place if it exists.
Signed-off-by: Gregory Hainaut
---
src/glsl/ir.h | 6 ++
src/glsl/ir_optimization.h | 2 ++
src/glsl/opt_dead_code.cpp | 19 +++
3 files changed, 27 insertions(+)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index f9ddf74..b4c4ace 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -649,6 +649,12 @@ public:
unsigned assigned:1;
/**
+ * When separate shader programs are enabled, only interstage
+ * variables can be safely removed of the shader interface.
+ */
+ unsigned not_interstage:1;
+
+ /**
* Enum indicating how the variable was declared. See
* ir_var_declaration_type.
*
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 265b223..bdd6ccc 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -72,6 +72,8 @@ enum lower_packing_builtins_op {
LOWER_PACK_USE_BFE = 0x2000,
};
+void ir_set_not_interstage_io(exec_list *instructions, ir_variable_mode mode);
+
bool do_common_optimization(exec_list *ir, bool linked,
bool uniform_locations_assigned,
const struct gl_shader_compiler_options *options,
diff --git a/src/glsl/opt_dead_code.cpp b/src/glsl/opt_dead_code.cpp
index e4bf874..d70c855 100644
--- a/src/glsl/opt_dead_code.cpp
+++ b/src/glsl/opt_dead_code.cpp
@@ -35,6 +35,25 @@
static bool debug = false;
+void
+ir_set_not_interstage_io(exec_list *instructions, ir_variable_mode mode)
+{
+ ir_variable_refcount_visitor v;
+
+ assert(mode == ir_var_shader_in || mode == ir_var_shader_out);
+
+ v.run(instructions);
+
+ struct hash_entry *e;
+ hash_table_foreach(v.ht, e) {
+ ir_variable_refcount_entry *entry = (ir_variable_refcount_entry
*)e->data;
+
+ if (entry->var->data.mode == mode)
+ entry->var->data.not_interstage = 1;
+ }
+}
+
+
/**
* Do a dead code pass over instructions and everything that instructions
* references.
--
2.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glx-tls: Visibility hidden attribute and fix x86/x86_64tls/tdsentry points
Hi Emil, Am Freitag, 2. Oktober 2015, 18:55:47 schrieb Emil Velikov: > Hi Marc, > > On 29 September 2015 at 10:31, Marc Dietrich wrote: > > As expressed before, using hidden attribute only hides some hack on how to > > find the head of the dispatch entry table afaict. > > > > I just replaced it with shared_dispatch_stub_0() and this works for > > shared- > > glapi case, but not without shared-api (the first function is named > > differently). IMHO, a better fix would be to mark the head of the dispatch > > table for all cases and use this mark instead of the asm hack. > > Can you please prepare a patch for this and send it over ? unfotunately no - my python knowlege is too poor to understand how all the tables are generated. I'm even not sure if this is the right solution. Marc signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
