| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
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
|
|
We'll need this for the scheduler too, since it wants to know when the
live ranges of payload registers end in order to model them in our
register pressure calculations.
|
|
The heuristic we're using is rather lame, since it assumes everything is
non-uniform and loops execute 10 times, but it should be enough for
measuring improvements in the scheduler that don't result in a change in
the number of instructions.
v2:
- Switch loops and cycle counts to be compatible with older shader-db.
- Make loop heuristic 10x to match with spilling code.
|
|
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
|
|
Although write-after-write dependencies have the same latency as
read-after-write dependencies due to how the register scoreboard works,
write-after-read dependencies aren't checked by the EU at all, so
they're purely a constraint on how the scheduler can order the
instructions.
|
|
The issue time for an instruction is how many cycles it takes to
actually put it into the pipeline. If there's a pipeline stall that
causes the instruction to be delayed, we should first take that into
account to figure out when the instruction would start executing and
*then* add the issue time. The old code had it backwards, and so we
would underestimate the total time whenever we thought there would be a
pipeline stall by up to the issue time of the instruction.
|
|
This has the better name to use. Aparently, sh->Name is usually 0.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
|
|
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
For glBlendFunc and glBlendFuncSeparate(), the _UsesDualSrc flag
will be the same for all buffers, so no need to compute it N times.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
A redundant call to glBlendFuncSeparateiARB() is more likely than getting
invalid values, so do the no-op check first.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Same story as preceeding change to _mesa_BlendFuncSeparate().
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Streamline the checking for no state change in _mesa_BlendFuncSeparate()
(and _mesa_BlendFunc()). If _BlendFuncPerBuffer is false, we only need
to check the 0th buffer state. Move argument validation after the no-op
check.
I'm looking at an app that issues about 1000 redundant glBlendFunc()
calls per frame!
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
We can skip to the end of _mesa_update_state_locked() if only the
_NEW_LINE flag is set since none of the derived state depends on it
(just like _NEW_CURRENT_ATTRIB). Note that we still call the
ctx->Driver.UpdateState() function, of course.
v2: use bitmask-based test, per Eric.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Changing the matrix mode alone has no effect on rendering and does
not need to trigger a flush or state validation.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Fixes: 669cfc267a1 (android: mesa: fix the path of the SSE4_1
optimisations)
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
i965_compile_FILES are needed otherwise we'll error out as below:
target SharedLib: i915_dri (out/target/product/x86/obj/SHARED_LIBRARIES/i915_dri_intermediates/LINKED/i915_dri.so)
external/mesa/src/mesa/drivers/dri/i965/brw_ir_fs.h:181: error: undefined reference to 'fs_inst::~fs_inst()'
...
...
external/mesa/src/mesa/drivers/dri/i965/intel_screen.c:1484: error: undefined reference to 'brw_compiler_create'
collect2: error: ld returned 1 exit status
build/core/shared_library.mk:81: recipe for target 'out/target/product/x86/obj/SHARED_LIBRARIES/i965_dri_intermediates/LINKED/i965_dri.so' failed
make: *** [out/target/product/x86/obj/SHARED_LIBRARIES/i965_dri_intermediates/LINKED/i965_dri.so] Error 1
[Emil Velikov: tweak commit message]
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Rather than accepting a void pointer, only to down and up cast around
it, convert the function to take the base (struct gl_program) pointer.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
|
|
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
|
|
V3: use a check_*_allowed style function for requirements checking
rather than has_* which doesn't encapsulate the error message
V2: add missing 's' to the extension name in error messages
and add decimal place in version string
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>
|
|
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
V2: split out unrelated change as suggested by Samuel
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
This adds support for setting up the UniformBlock structures for AoA
and also adds support for resizing AoA blocks with a packed layout.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
When checking for non-const indexing of interfaces
take into account arrays of arrays
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
V2: make array processing functions static
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
Add support for setting the max access of an unsized member
of an interface array of arrays.
For example ifc[j][k].foo[i] where foo is unsized.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Also add TODO comment about adding proper support
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
This marks all counters in an AoA as active.
For AoA all but the innermost array are treated as separate
counters/uniforms. The Nvidia binary also goes further and
finds inactive counters in the AoA, in future we should do
this too, however this gets things working for the time being.
This change also removes the use of UniformHash for atomic counters,
this avoids having to generate name strings used as hash keys.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
V2: get the correct vector elements value for outputs
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
This allows the correct offset to be calculated for use in indirect
indexing of samplers.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
Currently only one ir assignment is removed for each var in a single
dead code optimisation pass. This means if a var has more than one
assignment, then it requires all the glsl optimisations to be run again
for each additional assignment to be removed.
Another pass is also required to remove the variable itself.
With this change all assignments and the variable are removed in a single
pass.
Some of the arrays of arrays conformance tests that were looping
through 8 dimensions ended up with a var with hundreds of assignments.
This change helps ES31-CTS.arrays_of_arrays.InteractionFunctionCalls1
go from around 3 min 20 sec -> 2 min
ES31-CTS.arrays_of_arrays.InteractionFunctionCalls2 went from
around 9 min 20 sec to 7 min 30 sec
I had difficulty getting the public shader-db to give a consistent result
with or without this change but the results seemed unchanged at between
15-20 seconds.
Thomas Helland measured change with shader-db on his machine from
approx 117 secs to 112 secs.
V3: Simplify freeing of list as suggested by Ian, and spelling fixes.
V2: Add assert to be sure references are counted before assignments.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-By: Thomas Helland <thomashelland90@gmail.com>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
V3: move patch after fixes to ast for AoA and add const to helper
as suggested by Ian
V2: move single dimensional array detection into a helper
Signed-off-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
V2: Split out unsized array validation to its own patch as
suggested by Samuel.
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
|
|
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
V3: Fix setting of data.location for struct AoA UBO members
V2: Handle arrays of arrays in the same way structures are handled
The ARB_arrays_of_arrays spec doesn't give very many details on how
AoA uniforms are intended to be implemented. However in the
ARB_program_interface_query spec there are details that show AoA are
intended to be handled in a similar way to structs.
Issues 7 from the ARB_program_interface_query spec:
We define rules consistent with our enumeration rules for
other complex types. For existing one-dimensional arrays, we enumerate
a single entry if the array is an array of basic types, or separate
entries for each array element if the array is an array of structures.
We follow similar rules here. For a uniform array such as:
uniform vec4 a[5][4][3];
we enumerate twenty different entries ("a[0][0][0]" through
"a[4][3][0]"), each of which is treated as an array with three elements.
This is morally equivalent to what you'd get if you worked around the
limitation in current GLSL via:
struct ArrayBottom { vec4 c[3]; };
struct ArrayMid { ArrayBottom b[3]; };
uniform ArrayMid a[5];
which would enumerate "a[0].b[0].c[0]" through "a[4].b[3].c[0]".
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Instead, print "Scalar VS" or "Scalar FS". Otherwise it's really
confusing which stage is broken.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
The ES31-CTS.compute_shader.pipeline-compute-chain test case generates
an unsigned index by using gl_LocalInvocationID.x and
gl_LocalInvocationID.y as array indices.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
|
|
The ES31-CTS.compute_shader.pipeline-compute-chain test case generates
an unsigned index by using gl_LocalInvocationID.x and
gl_LocalInvocationID.y as array indices.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
|
|
The commit shown below caused compute shaders to hit the unreachable
in the default of the switch block. Since compute shaders don't have
any inputs, we can make brw_nir_lower_inputs a no-op for CS.
commit 2953c3d76178d7589947e6ea1dbd902b7b02b3d4
Author: Kenneth Graunke <kenneth@whitecape.org>
Date: Fri Aug 14 15:15:11 2015 -0700
i965/vs: Map scalar VS input locations properly; avoid tons of MOVs.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
replace_registers() and adjust_param_indexes() were unused.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
The texture unit is error-checked before this and the texUnit var
is unused, so remove it.
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
|
