These will be especially useful when we start keeping track of
liveness information for each subregister.
Reviewed-by: Matt Turner <mattst88@gmail.com>
And set it in the MOV instructions that copy the temporary to the
original destination if the generator instruction had it set.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Fix typo and punctuation in a comment, break long line and add space
before curly bracket.
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
try_copy_propagate() was checking the bit of the saturate mask for the
arg-th component of the source to decide whether the whole source
should be saturated (WTF?). We need to swizzle the original saturate
mask and check that for all enabled channels the saturate flag is
either set or unset, as we cannot saturate a subset of destination
components only.
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
This reverts commit 0dfec59a27. The
change prevented propagation of copies with the saturate flag set,
making the whole saturate mask tracking completely useless. A proper
fix follows.
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
This simplifies the src_reg/dst_reg conversion constructors using the
swizzle utils introduced in a previous patch. It also makes them more
useful by changing their semantics slightly: dst_reg(src_reg) used to
set the writemask to XYZW if the src_reg swizzle was anything other
than XXXX, which was almost certainly not what the caller intended if
the swizzle was non-trivial. After this patch the same components
that are present in the swizzle will be enabled in the resulting
writemask.
src_reg(dst_reg) used to set the first components of the swizzle to
the enabled components of the writemask and then replicate the last
enabled component to fill the swizzle, which, in cases where the
writemask didn't have exactly the first n components set, would in
general not be compatible with the original dst_reg. E.g.:
| ADD(tmp, src_reg(tmp), src_reg(1));
would *not* do what one would expect (add one to each of the enabled
components of tmp) if tmp didn't have a writemask of the described
form (e.g. YZ, YW, XZW would all fail). This pattern actually occurs
in many different places in the VEC4 back-end, it's a wonder that it
hasn't caused piglit failures until now. After this patch
src_reg(dst_reg) will construct a swizzle with each enabled component
at its natural position (e.g. Y at the second position, Z at the
third, and so on). The resulting swizzle will behave like the
identity when used in any instruction with the original writemask.
I've manually verified that *none* of the callers of both conversion
constructors were relying on the previous broken semantics. There are
no piglit regressions on any generation.
Reviewed-by: Matt Turner <mattst88@gmail.com>
It could be objected that swizzle_for_size() is "faster" than
brw_swizzle_for_size(). It's not measurably better in any reasonable
CPU-bound benchmark on VLV according to the Finnish benchmarking
system (including the SynMark2 DrvShComp shader compilation
benchmark).
Reviewed-by: Matt Turner <mattst88@gmail.com>
This seemed to be trying to deduce the number of uniform vector
components from the parameter swizzle, but the algorithm would always
give 4 as result. Instead grab the correct number of components from
the GLSL type.
Reviewed-by: Matt Turner <mattst88@gmail.com>
This defines helper functions implementing some common swizzle
transformations that are usually open-coded in the compiler back-end,
causing a lot of clutter. Some optimization passes will become almost
trivial implemented in terms of these functions (e.g.
vec4_visitor::opt_reduce_swizzle()).
Reviewed-by: Matt Turner <mattst88@gmail.com>
Patch changes lowering pass to use unique name for each uniform
so that arrays from different stages cannot end up having same
name.
v2: instead of global counter, use pointer to achieve
unique name (Kenneth Graunke)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89590
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: 10.5 10.4 <mesa-stable@lists.freedesktop.org>
FS instructions with NIR on i965:
total instructions in shared programs: 2663561 -> 2619051 (-1.67%)
instructions in affected programs: 1612965 -> 1568455 (-2.76%)
helped: 5455
HURT: 12
FS instructions with NIR on g4x:
total instructions in shared programs: 2352633 -> 2307908 (-1.90%)
instructions in affected programs: 1441842 -> 1397117 (-3.10%)
helped: 5463
HURT: 11
FS instructions with NIR on ilk:
total instructions in shared programs: 3997305 -> 3934278 (-1.58%)
instructions in affected programs: 2189409 -> 2126382 (-2.88%)
helped: 8969
HURT: 22
FS instructions with NIR on hsw (snb and ivb were similar):
total instructions in shared programs: 4109389 -> 4109242 (-0.00%)
instructions in affected programs: 109869 -> 109722 (-0.13%)
helped: 339
HURT: 190
No SIMD16 programs were gained or lost on any platform
Reviewed-by: Matt Turner <mattst88@gmail.com>
v2: Fix the spelling of analyze and re-arrange code for better readability
as per Connor's comments.
v3: Make the naming of things more consistent and add a pile of comments
v4: Stop trying to avoid vectors
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Most cases seem harmless, though that might not always be the case. Maybe
one day we can get gcc to complain about these and fix them throughout
the code, but until then let's silence them.
Reviewed-by: Brian Paul <brianp@vmware.com>
It's a bit hackish couldn't find another solution. See code comment
for details. The warning is useful, so universally disabling doesn't
sound a good idea.
Fixes
warning C4005: 'xxx' : macro redefinition
Reviewed-by: Brian Paul <brianp@vmware.com>
It warns about change in MSVC behavior -- array initialisation used to
be non-standard, but is standard now, assuming I understand correctly
http://en.cppreference.com/w/cpp/language/zero_initialization .
Reviewed-by: Brian Paul <brianp@vmware.com>
