Mesa (master): 22 new commits
Paul Berry
stereotype441 at kemper.freedesktop.org
Mon Dec 9 19:21:45 UTC 2013
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=088494aa032bf32db8b67f1fb07e5797603a473d
Author: Paul Berry <stereotype441 at gmail.com>
Date: Fri Nov 29 00:52:11 2013 -0800
glsl/loops: Get rid of lower_bounded_loops and ir_loop::normative_bound.
Now that loop_controls no longer creates normatively bound loops,
there is no need for ir_loop::normative_bound or the
lower_bounded_loops pass.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7ea3baa64da061f86a50c41081a26e0c2859e99c
Author: Paul Berry <stereotype441 at gmail.com>
Date: Fri Nov 29 00:16:43 2013 -0800
glsl/loops: Stop creating normatively bound loops in loop_controls.
Previously, when loop_controls analyzed a loop and found that it had a
fixed bound (known at compile time), it would remove all of the loop
terminators and instead set the loop's normative_bound field to force
the loop to execute the correct number of times.
This made loop unrolling easy, but it had a serious disadvantage.
Since most GPU's don't have a native mechanism for executing a loop a
fixed number of times, in order to implement the normative bound, the
back-ends would have to synthesize a new loop induction variable. As
a result, many loops wound up having two induction variables instead
of one. This caused extra register pressure and unnecessary
instructions.
This patch modifies loop_controls so that it doesn't set the loop's
normative_bound anymore. Instead it leaves one of the terminators in
the loop (the limiting terminator), so the back-end doesn't have to go
to any extra work to ensure the loop terminates at the right time.
This complicates loop unrolling slightly: when deciding whether a loop
can be unrolled, we have to account for the presence of the limiting
terminator. And when we do unroll the loop, we have to remove the
limiting terminator first.
For an example of how this results in more efficient back end code,
consider the loop:
for (int i = 0; i < 100; i++) {
total += i;
}
Previous to this patch, on i965, this loop would compile down to this
(vec4) native code:
mov(8) g4<1>.xD 0D
mov(8) g8<1>.xD 0D
loop:
cmp.ge.f0(8) null g8<4;4,1>.xD 100D
(+f0) if(8)
break(8)
endif(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g8<1>.xD g8<4;4,1>.xD 1D
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
(notice that both g8 and g4 are loop induction variables; one is used
to terminate the loop, and the other is used to accumulate the total).
After this patch, the same loop compiles to:
mov(8) g4<1>.xD 0D
loop:
cmp.ge.f0(8) null g4<4;4,1>.xD 100D
(+f0) if(8)
break(8)
endif(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4d844cfa56220b7de8ca676ad222d89f81c60c09
Author: Paul Berry <stereotype441 at gmail.com>
Date: Fri Nov 29 00:11:12 2013 -0800
glsl/loops: Get rid of loop_variable_state::max_iterations.
This value is now redundant with
loop_variable_state::limiting_terminator->iterations and
ir_loop::normative_bound.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e734c9f677ef3e9e2e4f207e4e794651ea6643b4
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 22:12:08 2013 -0800
glsl/loops: Simplify loop unrolling logic by breaking into functions.
The old logic of loop_unroll_visitor::visit_leave(ir_loop *) was:
heuristics to skip unrolling in various circumstances;
if (loop contains more than one jump)
return;
else if (loop contains one jump) {
if (the jump is an unconditional "break" at the end of the loop) {
remove the break and set iteration count to 1;
fall through to simple loop unrolling code;
} else {
for (each "if" statement in the loop body)
see if the jump is a "break" at the end of one of its forks;
if (the "break" wasn't found)
return;
splice the remainder of the loop into the other fork of the "if";
remove the "break";
complex loop unrolling code;
return;
}
}
simple loop unrolling code;
return;
These tasks have been moved to their own functions:
- splice the remainder of the loop into the other fork of the "if"
- simple loop unrolling code
- complex loop unrolling code
And the logic has been flattened to:
heuristics to skip unrolling in various circumstances;
if (loop contains more than one jump)
return;
if (loop contains no jumps) {
simple loop unroll;
return;
}
if (the jump is an unconditional "break" at the end of the loop) {
remove the break;
simple loop unroll with iteration count of 1;
return;
}
for (each "if" statement in the loop body) {
if (the jump is a "break" at the end of one of its forks) {
splice the remainder of the loop into the other fork of the "if";
remove the "break";
complex loop unroll;
return;
}
}
This will make it easier to modify the loop unrolling algorithm in a
future patch.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ffc29120c402551fe9a7fa36e8ee5476bad27738
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 14:40:19 2013 -0800
glsl/loops: Move some analysis from loop_controls to loop_analysis.
Previously, the sole responsibility of loop_analysis was to find all
the variables referenced in the loop that are either loop constant or
induction variables, and find all of the simple if statements that
might terminate the loop. The remainder of the analysis necessary to
determine how many times a loop executed was performed by
loop_controls.
This patch makes loop_analysis also responsible for determining the
number of iterations after which each loop terminator will terminate
the loop, and for figuring out which terminator will terminate the
loop first (I'm calling this the "limiting terminator").
This will allow loop unrolling to make use of information that was
previously only visible from loop_controls, namely the identity of the
limiting terminator.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4bbf6d1d2b20bccd784a326f33bdb860032db361
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 14:46:38 2013 -0800
glsl/loops: Allocate loop_terminator using new(mem_ctx) syntax.
Patches to follow will introduce code into the loop_terminator
constructor. Allocating loop_terminator using new(mem_ctx) syntax
will ensure that the constructor runs.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=714e1b331ed1b2dfffac4accb4ebf5a01d3f961f
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 12:44:53 2013 -0800
glsl/loops: Remove unnecessary list walk from loop_control_visitor.
When loop_control_visitor::visit_leave(ir_loop *) is analyzing a loop
terminator that acts on a certain ir_variable, it doesn't need to walk
the list of induction variables to find the loop_variable entry
corresponding to the variable. It can just look it up in the
loop_variable_state hashtable and verify that the loop_variable entry
represents an induction variable.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=115fd75ab06b858b83173f7d76eada8ea417fc86
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 12:17:54 2013 -0800
glsl/loops: Remove unused fields iv_scale and biv from loop_variable class.
These fields were part of some planned optimizations that never
materialized. Remove them for now to simplify things; if we ever get
round to adding the optimizations that would require them, we can
always re-introduce them.
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e00b93a1f7b4bc7f5e887591c000524e13f80826
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 08:13:41 2013 -0800
glsl/loops: replace loop controls with a normative bound.
This patch replaces the ir_loop fields "from", "to", "increment",
"counter", and "cmp" with a single integer ("normative_bound") that
serves the same purpose.
I've used the name "normative_bound" to emphasize the fact that the
back-end is required to emit code to prevent the loop from running
more than normative_bound times. (By contrast, an "informative" bound
would be a bound that is informational only).
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2c17f97fe6a40e4a963fb4eec0ea0555f562b1be
Author: Paul Berry <stereotype441 at gmail.com>
Date: Wed Nov 27 17:57:19 2013 -0800
glsl/loops: consolidate bounded loop handling into a lowering pass.
Previously, all of the back-ends (ir_to_mesa, st_glsl_to_tgsi, and the
i965 fs and vec4 visitors) had nearly identical logic for handling
bounded loops. This replaces the duplicate logic with an equivalent
lowering pass that is used by all the back-ends.
Note: on i965, there is a slight increase in instruction count. For
example, a loop like this:
for (int i = 0; i < 100; i++) {
total += i;
}
would previously compile down to this (vec4) native code:
mov(8) g4<1>.xD 0D
mov(8) g8<1>.xD 0D
loop:
cmp.ge.f0(8) null g8<4;4,1>.xD 100D
(+f0) break(8)
add(8) g5<1>.xD g5<4;4,1>.xD g4<4;4,1>.xD
add(8) g8<1>.xD g8<4;4,1>.xD 1D
add(8) g4<1>.xD g4<4;4,1>.xD 1D
while(8) loop
After this patch, the "(+f0) break(8)" turns into:
(+f0) if(8)
break(8)
endif(8)
because the back-end isn't smart enough to recognize that "if
(condition) break;" can be done using a conditional break instruction.
However, it should be relatively easy for a future peephole
optimization to properly optimize this.
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=97d8b770549584a2cd6b14956f15beeef0d83cad
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 11:11:17 2013 -0800
glsl: In loop analysis, handle unconditional second assignment.
Previously, loop analysis would set
this->conditional_or_nested_assignment based on the most recently
visited assignment to the variable. As a result, if a vaiable was
assigned to more than once in a loop, the flag might be set
incorrectly. For example, in a loop like this:
int x;
for (int i = 0; i < 3; i++) {
if (i == 0)
x = 10;
...
x = 20;
...
}
loop analysis would have incorrectly concluded that all assignments to
x were unconditional.
In practice this was a benign bug, because
conditional_or_nested_assignment is only used to disqualify variables
from being considered as loop induction variables or loop constant
variables, and having multiple assignments also disqualifies a
variable from being considered as either of those things.
Still, we should get the analysis correct to avoid future confusion.
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cb38a0dc0aaa0a5cbc2a5345ecee3c17d9d46987
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 11:06:43 2013 -0800
glsl: Fix handling of function calls inside nested loops.
Previously, when visiting an ir_call, loop analysis would only mark
the innermost enclosing loop as containing a call. As a result, when
encountering a loop like this:
for (i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
foo();
}
}
it would incorrectly conclude that the outer loop ran three times.
(This is not certain; if foo() modifies i, then the outer loop might
run more or fewer times).
Fixes piglit test "vs-call-in-nested-loop.shader_test".
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=877db5a792df7f5971c1906a3677b066926b9832
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 10:48:37 2013 -0800
glsl: Fix loop analysis of nested loops.
Previously, when visiting a variable dereference, loop analysis would
only consider its effect on the innermost enclosing loop. As a
result, when encountering a loop like this:
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
...
i = 2;
}
}
it would incorrectly conclude that the outer loop ran three times.
Fixes piglit test "vs-inner-loop-modifies-outer-loop-var.shader_test".
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2e060551bdfb3f5019f64696f268675a3550927c
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Nov 28 10:42:01 2013 -0800
glsl: Extract functions from loop_analysis::visit(ir_dereference_variable *).
This function is about to get more complex.
Reviewed-by: Jordan Justen <jordan.l.justen at intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick at intel.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=69c44d65c8f2846ede6733765508c2b4702173de
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 12:00:49 2013 -0800
i965/gen7+: Implement fast color clears for MSAA buffers.
Fast color clears of MSAA buffers work just like fast color clears
with non-MSAA buffers, except that the alignment and scaledown
requirements are different.
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=0ac622accf9ed9457e3d8a81fa8e6e3ef0a4befc
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 11:40:23 2013 -0800
i965/blorp: Refactor code for computing fast clear align/scaledown factors.
This will make it easier to add fast color clear support to MSAA
buffers, since they have different alignment and scaling requirements.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=da08ee8e3b81f1a11050dc7b280c07cef4c2c653
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 08:48:41 2013 -0800
i965/blorp: allow multisample blorp clears
Previously, we didn't do multisample blorp clears because we couldn't
figure out how to get them to work. The reason for this was because
we weren't setting the brw_blorp_params num_samples field consistently
with dst.num_samples. Now that those two fields have been collapsed
down into one, we can do multisample blorp clears.
However, we need to do a few other pieces of bookkeeping to make them
work correctly in all circumstances:
- Since blorp clears may now operate on multisampled window system
framebuffers, they need to call
intel_renderbuffer_set_needs_downsample() to ensure that a
downsample happens before buffer swap (or glReadPixels()).
- When clearing a layered multisample buffer attachment using UMS or
CMS layout, we need to advance layer by multiples of num_samples
(since each logical layer is associated with num_samples physical
layers).
Note: we still don't do multisample fast color clears; more work needs
to be done to enable those.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=73e8bd9f5c7cc026dc1e7c5b030f8949a1805d6b
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 09:44:46 2013 -0800
i965/blorp: Get rid of redundant num_samples blorp param.
Previously, brw_blorp_params contained two fields for determining
sample count: num_samples (which determined the multisample
configuration of the rendering pipeline) and dst.num_samples (which
determined the multisample configuration of the render target
surface). This was redundant, since both fields had to be set to the
same value to avoid rendering errors.
This patch eliminates num_samples to avoid future confusion.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=25195b004176ba8681500c5dbcc446ad68705163
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 08:33:41 2013 -0800
i965/gen7+: Disentangle MSAA layout from fast clear state.
This patch renames the enum that's used to keep track of fast clear
state from "mcs_state" to "fast_clear_state", and it removes the enum
value INTEL_MCS_STATE_MSAA (which previously meant, "this is an MSAA
buffer, so we're not keeping track of fast clear state"). The only
real purpose that enum value was serving was to prevent us from trying
to do fast clear resolves on MSAA buffers, and it's just as easy to
prevent that by checking the buffer's msaa_layout.
This paves the way for implementing fast clears of MSAA buffers.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=f416a15096c0984dce689681a004554ecb2ea728
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 15:41:14 2013 -0800
i965: Don't try to use HW blitter for glCopyPixels() when multisampled.
The hardware blitter doesn't understand multisampled layouts, so
there's no way this could possibly succeed.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b5fe413b4d665cdb7a9be6ebae23a6c5f3ec393d
Author: Paul Berry <stereotype441 at gmail.com>
Date: Tue Dec 3 21:15:47 2013 -0800
i965: Document conventions for counting layers in 2D multisample buffers.
The "layer" parameters used in blorp, and the
intel_renderbuffer::mt_layer field, represent a physical layer rather
than a logical layer. This is important for 2D multisample arrays on
Gen7+ because the UMS and CMS multisample layouts use N physical
layers to represent each logical layer, where N is the number of
samples.
Also add an assertion to blorp to help catch bugs if we fail to follow
these conventions.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat at gmail.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=3a2925bfa9537c202574eba0e2537b08939081ac
Author: Paul Berry <stereotype441 at gmail.com>
Date: Thu Dec 5 04:34:42 2013 -0800
i965/blorp: Improve fast color clear comment.
Clarify the fact that we only optimize full buffer clears using fast
color clear, and why.
Reviewed-by: Chad Versace <chad.versace at linux.intel.com>
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
More information about the mesa-commit
mailing list