KonstantinSeurer
/
mesa
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
mesa/src/intel/compiler/brw_vec4_copy_propagation.cpp

557 lines
17 KiB
C++
Raw Normal View History

i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
/*
* Copyright © 2011 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 brw_vec4_copy_propagation.cpp
*
* Implements tracking of values copied between registers, and
* optimizations based on that: copy propagation and constant
* propagation.
*/
#include "brw_vec4.h"
i965/vec4: Don't use instruction list after calculating the cfg. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-09-01 21:42:51 +01:00
#include "brw_cfg.h"
i965: Clean up #includes in the compiler. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2015-11-23 02:27:42 +00:00
#include "brw_eu.h"
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
namespace brw {
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
struct copy_entry {
src_reg *value[4];
int saturatemask;
};
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
static bool
is_direct_copy(vec4_instruction *inst)
{
return (inst->opcode == BRW_OPCODE_MOV &&
!inst->predicate &&
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
inst->dst.file == VGRF &&
i965/vec4: Fix copy propagation for non-register-aligned regions. This prevents it from trying to propagate a copy through a register-misaligned region. MOV instructions with a misaligned destination shouldn't be treated as a direct GRF copy, because they only define the destination GRFs partially. Also fix the interference check implemented with is_channel_updated() to consider overlapping regions with different register offset to interfere, since the writemask check implemented in the function is only valid under the assumption that the source and destination regions are aligned component by component. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-02 06:31:43 +01:00
inst->dst.offset % REG_SIZE == 0 &&
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
!inst->dst.reladdr &&
!inst->src[0].reladdr &&
i965/vec4: Allow constant propagation of VF immediates. total instructions in shared programs: 5877951 -> 5877012 (-0.02%) instructions in affected programs: 155923 -> 154984 (-0.60%) Helps 1233, hurts 156 shaders. The hurt shaders are addressed in the next commit. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-12-21 01:42:52 +00:00
(inst->dst.type == inst->src[0].type ||
(inst->dst.type == BRW_REGISTER_TYPE_F &&
inst->src[0].type == BRW_REGISTER_TYPE_VF)));
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
}
static bool
is_dominated_by_previous_instruction(vec4_instruction *inst)
{
return (inst->opcode != BRW_OPCODE_DO &&
inst->opcode != BRW_OPCODE_WHILE &&
inst->opcode != BRW_OPCODE_ELSE &&
inst->opcode != BRW_OPCODE_ENDIF);
}
i965/vec4: fix record clearing in copy propagation Given mov vgrf7, vgrf9.xyxz add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw add vgrf10.x, vgrf6.xyzw, vgrf7.wwww the last instruction would be wrongly changed to add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz during copy propagation. The issue is that when deciding if a record should be cleared, the old code checked for inst->dst.writemask & (1 << ch) instead of inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749 Signed-off-by: Chia-I Wu <olv@lunarg.com> Cc: Jordan Justen <jljusten@gmail.com> Cc: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romainck <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: "10.1" <mesa-stable@freedesktop.org>
2014-04-07 05:31:14 +01:00
static bool
is_channel_updated(vec4_instruction *inst, src_reg *values[4], int ch)
{
const src_reg *src = values[ch];
/* consider GRF only */
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
assert(inst->dst.file == VGRF);
if (!src || src->file != VGRF)
i965/vec4: fix record clearing in copy propagation Given mov vgrf7, vgrf9.xyxz add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw add vgrf10.x, vgrf6.xyzw, vgrf7.wwww the last instruction would be wrongly changed to add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz during copy propagation. The issue is that when deciding if a record should be cleared, the old code checked for inst->dst.writemask & (1 << ch) instead of inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749 Signed-off-by: Chia-I Wu <olv@lunarg.com> Cc: Jordan Justen <jljusten@gmail.com> Cc: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romainck <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: "10.1" <mesa-stable@freedesktop.org>
2014-04-07 05:31:14 +01:00
return false;
i965/vec4: Drop backend_reg::in_range() in favor of regions_overlap(). This makes sure that overlap checks are done correctly throughout the back-end when the '*this' register starts before the register/size pair provided as argument, and is actually less annoying to use than in_range() at this point since regions_overlap() takes its size arguments in bytes. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-02 03:42:40 +01:00
return regions_overlap(*src, REG_SIZE, inst->dst, inst->size_written) &&
i965/vec4: Fix copy propagation for non-register-aligned regions. This prevents it from trying to propagate a copy through a register-misaligned region. MOV instructions with a misaligned destination shouldn't be treated as a direct GRF copy, because they only define the destination GRFs partially. Also fix the interference check implemented with is_channel_updated() to consider overlapping regions with different register offset to interfere, since the writemask check implemented in the function is only valid under the assumption that the source and destination regions are aligned component by component. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-02 06:31:43 +01:00
(inst->dst.offset != src->offset ||
inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)));
i965/vec4: fix record clearing in copy propagation Given mov vgrf7, vgrf9.xyxz add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw add vgrf10.x, vgrf6.xyzw, vgrf7.wwww the last instruction would be wrongly changed to add vgrf10.x, vgrf6.xyzw, vgrf9.zzzz during copy propagation. The issue is that when deciding if a record should be cleared, the old code checked for inst->dst.writemask & (1 << ch) instead of inst->dst.writemask & (1 << BRW_GET_SWZ(src->swizzle, ch)) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76749 Signed-off-by: Chia-I Wu <olv@lunarg.com> Cc: Jordan Justen <jljusten@gmail.com> Cc: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romainck <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Cc: "10.1" <mesa-stable@freedesktop.org>
2014-04-07 05:31:14 +01:00
}
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
/**
* Get the origin of a copy as a single register if all components present in
* the given readmask originate from the same register and have compatible
* regions, otherwise return a BAD_FILE register.
*/
static src_reg
get_copy_value(const copy_entry &entry, unsigned readmask)
{
unsigned swz[4] = {};
src_reg value;
for (unsigned i = 0; i < 4; i++) {
if (readmask & (1 << i)) {
if (entry.value[i]) {
src_reg src = *entry.value[i];
if (src.file == IMM) {
swz[i] = i;
} else {
swz[i] = BRW_GET_SWZ(src.swizzle, i);
/* Overwrite the original swizzle so the src_reg::equals call
* below doesn't care about it, the correct swizzle will be
* calculated once the swizzles of all components are known.
*/
src.swizzle = BRW_SWIZZLE_XYZW;
}
if (value.file == BAD_FILE) {
value = src;
} else if (!value.equals(src)) {
return src_reg();
}
} else {
return src_reg();
}
}
}
return swizzle(value,
brw_compose_swizzle(brw_swizzle_for_mask(readmask),
BRW_SWIZZLE4(swz[0], swz[1],
swz[2], swz[3])));
}
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
static bool
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
try_constant_propagate(vec4_instruction *inst,
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
int arg, const copy_entry *entry)
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
{
/* For constant propagation, we only handle the same constant
* across all 4 channels. Some day, we should handle the 8-bit
* float vector format, which would let us constant propagate
* vectors better.
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
* We could be more aggressive here -- some channels might not get used
* based on the destination writemask.
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
*/
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
src_reg value =
get_copy_value(*entry,
brw_apply_inv_swizzle_to_mask(inst->src[arg].swizzle,
WRITEMASK_XYZW));
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
if (value.file != IMM)
return false;
i965/vec4: don't constant propagate 64-bit immediates v2: Also check if the instruction source target is 64-bit. (Samuel) Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-08-13 23:44:14 +01:00
/* 64-bit types can't be used except for one-source instructions, which
* higher levels should have constant folded away, so there's no point in
* propagating immediates here.
*/
if (type_sz(value.type) == 8 || type_sz(inst->src[arg].type) == 8)
return false;
i965/vec4: Fix constant propagation across different types. If the source type differs from the original type of the constant we need to bit-cast it before propagating, otherwise the original type information will be lost. If the constant was a vector float there isn't much we can do, because the result of bit-casting the component values of a vector float cannot itself be represented as an immediate. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-03 20:48:27 +00:00
if (value.type == BRW_REGISTER_TYPE_VF) {
/* The result of bit-casting the component values of a vector float
* cannot in general be represented as an immediate.
*/
if (inst->src[arg].type != BRW_REGISTER_TYPE_F)
return false;
} else {
value.type = inst->src[arg].type;
}
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
if (inst->src[arg].abs) {
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
if (!brw_abs_immediate(value.type, &value.as_brw_reg()))
i965/vec4: Use abs/negate functions in const propagation. No changes in shader-db. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2015-01-30 23:13:48 +00:00
return false;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
}
if (inst->src[arg].negate) {
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
if (!brw_negate_immediate(value.type, &value.as_brw_reg()))
i965/vec4: Use abs/negate functions in const propagation. No changes in shader-db. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2015-01-30 23:13:48 +00:00
return false;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
}
i965/vec4: Use swizzle() to swizzle immediates during constant propagation. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-02-27 01:20:19 +00:00
value = swizzle(value, inst->src[arg].swizzle);
i965/vec4: Allow constant propagation of VF immediates. total instructions in shared programs: 5877951 -> 5877012 (-0.02%) instructions in affected programs: 155923 -> 154984 (-0.60%) Helps 1233, hurts 156 shaders. The hurt shaders are addressed in the next commit. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-12-21 01:42:52 +00:00
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
switch (inst->opcode) {
case BRW_OPCODE_MOV:
i965: Perform basic optimizations on the BROADCAST opcode. v2: Style fixes. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-19 12:52:24 +00:00
case SHADER_OPCODE_BROADCAST:
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
inst->src[arg] = value;
return true;
intel/compiler: Re-prefix non-logical surface opcodes with VEC4 The scalar back-end uses SHADER_OPCODE_SEND for all surface messages so we no longer need the non-logical opcodes there. Prefix them VEC4 so it's clear that they're only used by the vec4 back-end. Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
2019-02-21 16:41:59 +00:00
case VEC4_OPCODE_UNTYPED_ATOMIC:
i965: Support copy propagating of untyped atomic surface indexes. In the vec4 backend, SHADER_OPCODE_UNTYPED_ATOMIC's src[1] is the surface index. We want to copy propagate so we can use an immediate message descriptor, rather than an indirect send. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2017-09-24 20:42:52 +01:00
if (arg == 1) {
inst->src[arg] = value;
return true;
}
break;
i965/vec4: Constant propagate into 2-src math instructions on Gen8. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-24 06:07:38 +01:00
case SHADER_OPCODE_POW:
case SHADER_OPCODE_INT_QUOTIENT:
case SHADER_OPCODE_INT_REMAINDER:
break;
i965/vec4: Allow constant propagation into dot product. total instructions in shared programs: 1667088 -> 1667055 (-0.00%) instructions in affected programs: 3362 -> 3329 (-0.98%) Reviewed-by: Eric Anholt <eric@anholt.net>
2014-03-02 17:02:17 +00:00
case BRW_OPCODE_DP2:
case BRW_OPCODE_DP3:
case BRW_OPCODE_DP4:
case BRW_OPCODE_DPH:
i965: Allow constant propagation into ASR and BFI1. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-11-26 21:49:31 +00:00
case BRW_OPCODE_BFI1:
case BRW_OPCODE_ASR:
i965: Allow immediates to be folded into logical and shift instructions. These instructions will be used with immediate arguments in the upcoming ldexp lowering pass and frexp implementation. v2: Add vec4 support as well. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-05 23:17:04 +01:00
case BRW_OPCODE_SHL:
case BRW_OPCODE_SHR:
i965: Generate code for ir_binop_carry and ir_binop_borrow. Using the ADDC and SUBB instructions on Gen7. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2013-09-19 21:01:08 +01:00
case BRW_OPCODE_SUBB:
i965: Allow immediates to be folded into logical and shift instructions. These instructions will be used with immediate arguments in the upcoming ldexp lowering pass and frexp implementation. v2: Add vec4 support as well. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-05 23:17:04 +01:00
if (arg == 1) {
inst->src[arg] = value;
return true;
}
break;
i965/vs: Allow copy propagation into MUL/MACH. This is a trivial port of 1d6ead38042cc0d1e667d8ff55937c1e32d108b1 from the FS. No significant performance difference on trex (misplaced the data, but it was about n=20). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-06-08 01:58:18 +01:00
case BRW_OPCODE_MACH:
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
case BRW_OPCODE_MUL:
i965: Define virtual instruction to calculate the high 32 bits of a multiply. This instruction will translate to the MUL/MACH sequence that computes the high 32-bits of the result of a 64-bit multiply. Before Gen8 integer operations that used the accumulator were limited to 8-wide, but the SIMD lowering pass can easily be hooked up to sidestep this limitation, we just need a virtual opcode to represent the MUL/MACH sequence in the IR. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-08-04 17:04:55 +01:00
case SHADER_OPCODE_MULH:
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
case BRW_OPCODE_ADD:
i965: Allow immediates to be folded into logical and shift instructions. These instructions will be used with immediate arguments in the upcoming ldexp lowering pass and frexp implementation. v2: Add vec4 support as well. Reviewed-by: Paul Berry <stereotype441@gmail.com>
2013-08-05 23:17:04 +01:00
case BRW_OPCODE_OR:
case BRW_OPCODE_AND:
case BRW_OPCODE_XOR:
i965: Allow commuting the operands of ADDC for const propagation. Reviewed-by: Eric Anholt <eric@anholt.net>
2013-11-28 00:14:14 +00:00
case BRW_OPCODE_ADDC:
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
if (arg == 1) {
inst->src[arg] = value;
return true;
} else if (arg == 0 && inst->src[1].file != IMM) {
i965: Fix constant propagation into 32-bit integer MUL. i965's MUL instruction can't take an immediate value as its first argument. So normally, if constant propagation wants to propagate a constant into the first argument of a MUL instruction, it swaps the order of the two arguments. This doesn't work for 32-bit integer (and unsigned integer) multiplies, because the MUL operation is asymmetric in that case (it multiplies 16 bits of one operand by 32 bits of the other). Fixes piglit tests {vs,fs}-multiply-const-{ivec4,uvec4}. Reviewed-by: Eric Anholt <eric@anholt.net>
2011-11-02 03:35:23 +00:00
/* Fit this constant in by commuting the operands. Exception: we
i965/vs: Allow copy propagation into MUL/MACH. This is a trivial port of 1d6ead38042cc0d1e667d8ff55937c1e32d108b1 from the FS. No significant performance difference on trex (misplaced the data, but it was about n=20). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-06-08 01:58:18 +01:00
* can't do this for 32-bit integer MUL/MACH because it's asymmetric.
i965: Fix constant propagation into 32-bit integer MUL. i965's MUL instruction can't take an immediate value as its first argument. So normally, if constant propagation wants to propagate a constant into the first argument of a MUL instruction, it swaps the order of the two arguments. This doesn't work for 32-bit integer (and unsigned integer) multiplies, because the MUL operation is asymmetric in that case (it multiplies 16 bits of one operand by 32 bits of the other). Fixes piglit tests {vs,fs}-multiply-const-{ivec4,uvec4}. Reviewed-by: Eric Anholt <eric@anholt.net>
2011-11-02 03:35:23 +00:00
*/
i965/vs: Allow copy propagation into MUL/MACH. This is a trivial port of 1d6ead38042cc0d1e667d8ff55937c1e32d108b1 from the FS. No significant performance difference on trex (misplaced the data, but it was about n=20). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2013-06-08 01:58:18 +01:00
if ((inst->opcode == BRW_OPCODE_MUL ||
inst->opcode == BRW_OPCODE_MACH) &&
i965: Fix constant propagation into 32-bit integer MUL. i965's MUL instruction can't take an immediate value as its first argument. So normally, if constant propagation wants to propagate a constant into the first argument of a MUL instruction, it swaps the order of the two arguments. This doesn't work for 32-bit integer (and unsigned integer) multiplies, because the MUL operation is asymmetric in that case (it multiplies 16 bits of one operand by 32 bits of the other). Fixes piglit tests {vs,fs}-multiply-const-{ivec4,uvec4}. Reviewed-by: Eric Anholt <eric@anholt.net>
2011-11-02 03:35:23 +00:00
(inst->src[1].type == BRW_REGISTER_TYPE_D ||
inst->src[1].type == BRW_REGISTER_TYPE_UD))
break;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
inst->src[0] = inst->src[1];
inst->src[1] = value;
return true;
}
break;
i965/gs: Allow src0 immediates in GS_OPCODE_SET_WRITE_OFFSET. GS_OPCODE_SET_WRITE_OFFSET is a MUL with a constant src[1] and special strides. We can easily make the generator handle constant src[0] arguments by instead generating a MOV with the product of both operands. This isn't necessarily a win in and of itself - instead of a MUL, we generate a MOV, which should be basically the same cost. However, we can probably avoid the earlier MOV to put src[0] into a register. shader-db statistics for geometry shaders only: total instructions in shared programs: 3207 -> 3173 (-1.06%) instructions in affected programs: 3207 -> 3173 (-1.06%) helped: 11 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-25 07:47:29 +01:00
case GS_OPCODE_SET_WRITE_OFFSET:
/* This is just a multiply by a constant with special strides.
* The generator will handle immediates in both arguments (generating
* a single MOV of the product). So feel free to propagate in src0.
*/
inst->src[arg] = value;
return true;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
case BRW_OPCODE_CMP:
if (arg == 1) {
inst->src[arg] = value;
return true;
} else if (arg == 0 && inst->src[1].file != IMM) {
i965: Make a brw_conditional_mod enum. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-06-30 01:50:20 +01:00
enum brw_conditional_mod new_cmod;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
new_cmod = brw_swap_cmod(inst->conditional_mod);
i965: Return NONE from brw_swap_cmod on unknown input. Comparing ~0u with a packed enum (i.e., 1 byte) always evaluates to false. Shouldn't gcc warn about this? Reported-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-08-11 19:12:43 +01:00
if (new_cmod != BRW_CONDITIONAL_NONE) {
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
/* Fit this constant in by swapping the operands and
* flipping the test.
*/
inst->src[0] = inst->src[1];
inst->src[1] = value;
inst->conditional_mod = new_cmod;
return true;
}
}
break;
case BRW_OPCODE_SEL:
if (arg == 1) {
inst->src[arg] = value;
return true;
} else if (arg == 0 && inst->src[1].file != IMM) {
inst->src[0] = inst->src[1];
inst->src[1] = value;
/* If this was predicated, flipping operands means
* we also need to flip the predicate.
*/
if (inst->conditional_mod == BRW_CONDITIONAL_NONE) {
inst->predicate_inverse = !inst->predicate_inverse;
}
return true;
}
break;
default:
break;
}
return false;
}
i965/vec4: don't copy propagate vector opcodes that operate in align1 mode Basically, ALIGN1 mode will ignore swizzles on the input vectors so we don't want the copy propagation pass to mess with them. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-02-11 13:19:58 +00:00
static bool
is_align1_opcode(unsigned opcode)
{
switch (opcode) {
i965/vec4: split VEC4_OPCODE_FROM_DOUBLE into one opcode per destination's type This way we can set the destination type as double to all these new opcodes, avoiding any optimizer's confusion that was happening before. Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> [ Francisco Jerez: Drop no_spill workaround originally needed due to the bogus destination type of VEC4_OPCODE_FROM_DOUBLE. ] Reviewed-by: Francisco Jerez <currojerez@riseup.net>
2017-03-24 07:46:13 +00:00
case VEC4_OPCODE_DOUBLE_TO_F32:
case VEC4_OPCODE_DOUBLE_TO_D32:
case VEC4_OPCODE_DOUBLE_TO_U32:
i965/vec4: Rename DF to/from F generator opcodes The opcodes are not specific for conversions to/from float since we need the same for conversions to/from other 32-bit types. Rename the opcodes accordingly and change the asserts to check the size of the types involved instead. v2: - Rename to VEC4_OPCODE_TO_DOUBLE and VEC4_OPCODE_FROM_DOUBLE (Matt) Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-02-17 09:32:05 +00:00
case VEC4_OPCODE_TO_DOUBLE:
i965/vec4: don't copy propagate vector opcodes that operate in align1 mode Basically, ALIGN1 mode will ignore swizzles on the input vectors so we don't want the copy propagation pass to mess with them. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-02-11 13:19:58 +00:00
case VEC4_OPCODE_PICK_LOW_32BIT:
case VEC4_OPCODE_PICK_HIGH_32BIT:
case VEC4_OPCODE_SET_LOW_32BIT:
case VEC4_OPCODE_SET_HIGH_32BIT:
return true;
default:
return false;
}
}
i965/vec4: Make try_copy_propagate() static. Now that can_do_source_mods() isn't part of the visitor, this doesn't need to be either. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-24 06:16:02 +01:00
static bool
intel/compiler: Introduce a new brw_isa_info structure This structure will contain the opcode mapping tables in the next commit. For now, this is the mechanical change to plumb it into all the necessary places, and it continues simply holding devinfo. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17309>
2022-06-29 22:13:31 +01:00
try_copy_propagate(const struct brw_compiler *compiler,
i965/vec4: don't copy ATTR into 3src instructions with complex swizzles The vec4 backend, at the end, does this: if (inst->is_3src()) { for (int i = 0; i < 3; i++) { if (inst->src[i].vstride == BRW_VERTICAL_STRIDE_0) assert(brw_is_single_value_swizzle(inst->src[i].swizzle)); So make sure that we use the same conditions when trying to copy-propagate. UNIFORMs will be converted to vstride 0 in convert_to_hw_regs, but so will ATTRs when interleaved (as will happen in a GS with multiple attributes). Since the vstride is not set at copy-prop time, infer it by inspecting dispatch_mode and reject ATTRs if they have non-scalar swizzles and are interleaved. Fixes assertion errors in dolphin-generated geometry shaders (or misrendering on opt builds) on Sandybridge or on IVB/HSW with INTEL_DEBUG=nodualobj. Co-authored-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93418 Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
2016-01-18 01:30:14 +00:00
vec4_instruction *inst, int arg,
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
const copy_entry *entry, int attributes_per_reg)
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
{
intel/compiler: Introduce a new brw_isa_info structure This structure will contain the opcode mapping tables in the next commit. For now, this is the mechanical change to plumb it into all the necessary places, and it continues simply holding devinfo. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17309>
2022-06-29 22:13:31 +01:00
const struct intel_device_info *devinfo = compiler->devinfo;
i965/vec4: refactor brw_vec4_copy_propagation. Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the implementation on some specific cases, like knowing if you can propagate from a previous instruction even with type mismatches, even messier (for example, with the need of maintaining more of one has_source_modifiers). The refactoring clears stuff, and gives support to this mentioned use case without doing anything extra (for example, only one has_source_modifiers is used). Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1683842 -> 1669037 (-0.88%) instructions in affected programs: 739837 -> 725032 (-2.00%) helped: 6237 HURT: 0 v2: using 'arg' index to get the from inst was wrong v3: rebased against last change on the previous patch of the series v4: don't need to track instructions on struct copy_entry, as we only set the source on a direct copy v5: change the approach for a refactoring v6: tweaked comments Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 16:19:50 +01:00
/* Build up the value we are propagating as if it were the source of a
* single MOV
*/
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
src_reg value =
get_copy_value(*entry,
brw_apply_inv_swizzle_to_mask(inst->src[arg].swizzle,
WRITEMASK_XYZW));
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
i965/vec4: refactor brw_vec4_copy_propagation. Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the implementation on some specific cases, like knowing if you can propagate from a previous instruction even with type mismatches, even messier (for example, with the need of maintaining more of one has_source_modifiers). The refactoring clears stuff, and gives support to this mentioned use case without doing anything extra (for example, only one has_source_modifiers is used). Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1683842 -> 1669037 (-0.88%) instructions in affected programs: 739837 -> 725032 (-2.00%) helped: 6237 HURT: 0 v2: using 'arg' index to get the from inst was wrong v3: rebased against last change on the previous patch of the series v4: don't need to track instructions on struct copy_entry, as we only set the source on a direct copy v5: change the approach for a refactoring v6: tweaked comments Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 16:19:50 +01:00
/* Check that we can propagate that value */
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
if (value.file != UNIFORM &&
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
value.file != VGRF &&
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
value.file != ATTR)
return false;
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
/* Instructions that write 2 registers also need to read 2 registers. Make
* sure we don't break that restriction by copy propagating from a uniform.
i965/vec4: Prevent copy propagation from violating pre-gen8 restrictions In gen < 8 instructions that write more than one register need to read more than one register too. Make sure we don't break that restriction by copy propagating from a uniform. Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-06-23 07:34:53 +01:00
*/
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
if (inst->size_written > REG_SIZE && is_uniform(value))
i965/vec4: Prevent copy propagation from violating pre-gen8 restrictions In gen < 8 instructions that write more than one register need to read more than one register too. Make sure we don't break that restriction by copy propagating from a uniform. Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-06-23 07:34:53 +01:00
return false;
i965/vec4: don't propagate single-precision uniforms into 4-wide instructions Otherwise we end up producing code that violates the register region restriction that says that when execsize == width and hstride != 0 the vstride can't be 0. Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-07-13 08:11:35 +01:00
/* There is a regioning restriction such that if execsize == width
* and hstride != 0 then the vstride can't be 0. When we split instrutions
* that take a single-precision source (like F->DF conversions) we end up
* with a 4-wide source on an instruction with an execution size of 4.
* If we then copy-propagate the source from a uniform we also end up with a
* vstride of 0 and we violate the restriction.
*/
if (inst->exec_size == 4 && value.file == UNIFORM &&
type_sz(value.type) == 4)
return false;
i965/vec4: prevent copy-propagation from values with a different type size Because the meaning of the swizzles and writemasks involved is different, so replacing the source would lead to different semantics. Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-06-16 12:41:48 +01:00
/* If the type of the copy value is different from the type of the
* instruction then the swizzles and writemasks involved don't have the same
* meaning and simply replacing the source would produce different semantics.
*/
if (type_sz(value.type) != type_sz(inst->src[arg].type))
return false;
i965/vec4: don't copy propagate misaligned registers This means we would copy propagate partial reads or writes and that can affect the result. Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-06-22 14:13:45 +01:00
if (inst->src[arg].offset % REG_SIZE || value.offset % REG_SIZE)
return false;
i965: Don't copy propagate bitcasts with source modifiers. Previously, copy propagation would cause bitcast_f2u(abs(float)) to be performed in a single step, but the application of source modifiers (abs, neg) happens after type conversion, leading to incorrect results. That is, for bitcast_f2u(abs(float)) we would in fact generate code to do abs(bitcast_f2u(float)). For example, whereas bitcast_f2u(abs(float)) might result in a register argument such as (abs)g2.2<0,1,0>UD v2: Set interfered = true and break in register_coalesce instead of returning false. Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
2013-08-09 00:41:48 +01:00
bool has_source_modifiers = value.negate || value.abs;
i965/vs: Teach copy propagation about sends from GRFs. This incidentally also teaches it a bit about gen6 math -- we now allow unswizzled, unmodified GRF temps as the sources for math. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-18 01:03:02 +00:00
intel: Rename genx keyword to gfxx in source files Commands used to do the changes: export SEARCH_PATH="src/intel src/gallium/drivers/iris src/mesa/drivers/dri/i965" grep -E "gen[[:digit:]]+" -rIl $SEARCH_PATH | xargs sed -ie "s/gen\([[:digit:]]\+\)/gfx\1/g" Exclude pack.h and xml changes in this patch: grep -E "gfx[[:digit:]]+_pack\.h" -rIl $SEARCH_PATH | xargs sed -ie "s/gfx\([[:digit:]]\+_pack\.h\)/gen\1/g" grep -E "gfx[[:digit:]]+\.xml" -rIl $SEARCH_PATH | xargs sed -ie "s/gfx\([[:digit:]]\+\.xml\)/gen\1/g" Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9936>
2021-03-29 23:40:04 +01:00
/* gfx6 math and gfx7+ SENDs from GRFs ignore source modifiers on
i965/vs: Teach copy propagation about sends from GRFs. This incidentally also teaches it a bit about gen6 math -- we now allow unswizzled, unmodified GRF temps as the sources for math. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2012-12-18 01:03:02 +00:00
* instructions.
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
*/
intel/compiler: Relax some conditions in try_copy_propagate Previously can_do_source_mods was used to determine whether a value with a source modifier or a value from a scalar source (e.g., a uniform) could be copy propagated. The former is a superset of the latter, so this always produces correct results, but it is overly restrictive. For example, a BFI instruction can't have source modifiers, but it can have scalar sources. This was originally authored to prevent a small number of shader-db regressions in a commit that marked SHR has not being able to have source modifiers. That commit has since been dropped in favor of a different method. v2: Refactor register region restriction detection to a helper function. Suggested by Jason. No fossil-db changes on any Intel platform. All Gen7+ platforms had similar results. (Ice Lake shown) total instructions in shared programs: 20039111 -> 20038943 (<.01%) instructions in affected programs: 31736 -> 31568 (-0.53%) helped: 104 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.62 x̃: 1 helped stats (rel) min: 0.30% max: 0.88% x̄: 0.45% x̃: 0.42% 95% mean confidence interval for instructions value: -2.03 -1.20 95% mean confidence interval for instructions %-change: -0.47% -0.42% Instructions are helped. total cycles in shared programs: 980309750 -> 980308897 (<.01%) cycles in affected programs: 591078 -> 590225 (-0.14%) helped: 70 HURT: 26 helped stats (abs) min: 2 max: 622 x̄: 23.94 x̃: 4 helped stats (rel) min: <.01% max: 2.85% x̄: 0.33% x̃: 0.12% HURT stats (abs) min: 2 max: 520 x̄: 31.65 x̃: 6 HURT stats (rel) min: 0.02% max: 2.45% x̄: 0.34% x̃: 0.15% 95% mean confidence interval for cycles value: -26.41 8.64 95% mean confidence interval for cycles %-change: -0.27% -0.03% Inconclusive result (value mean confidence interval includes 0). No shader-db changes on earlier Intel platforms. Reviewed-by: Anuj Phogat anuj.phogat@gmail.com [v1] Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9237>
2020-12-07 00:26:04 +00:00
if (has_source_modifiers && !inst->can_do_source_mods(devinfo))
i965: Don't copy propagate bitcasts with source modifiers. Previously, copy propagation would cause bitcast_f2u(abs(float)) to be performed in a single step, but the application of source modifiers (abs, neg) happens after type conversion, leading to incorrect results. That is, for bitcast_f2u(abs(float)) we would in fact generate code to do abs(bitcast_f2u(float)). For example, whereas bitcast_f2u(abs(float)) might result in a register argument such as (abs)g2.2<0,1,0>UD v2: Set interfered = true and break in register_coalesce instead of returning false. Reviewed-by: Paul Berry <stereoytpe441@gmail.com>
2013-08-09 00:41:48 +01:00
return false;
intel/compiler: Relax some conditions in try_copy_propagate Previously can_do_source_mods was used to determine whether a value with a source modifier or a value from a scalar source (e.g., a uniform) could be copy propagated. The former is a superset of the latter, so this always produces correct results, but it is overly restrictive. For example, a BFI instruction can't have source modifiers, but it can have scalar sources. This was originally authored to prevent a small number of shader-db regressions in a commit that marked SHR has not being able to have source modifiers. That commit has since been dropped in favor of a different method. v2: Refactor register region restriction detection to a helper function. Suggested by Jason. No fossil-db changes on any Intel platform. All Gen7+ platforms had similar results. (Ice Lake shown) total instructions in shared programs: 20039111 -> 20038943 (<.01%) instructions in affected programs: 31736 -> 31568 (-0.53%) helped: 104 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.62 x̃: 1 helped stats (rel) min: 0.30% max: 0.88% x̄: 0.45% x̃: 0.42% 95% mean confidence interval for instructions value: -2.03 -1.20 95% mean confidence interval for instructions %-change: -0.47% -0.42% Instructions are helped. total cycles in shared programs: 980309750 -> 980308897 (<.01%) cycles in affected programs: 591078 -> 590225 (-0.14%) helped: 70 HURT: 26 helped stats (abs) min: 2 max: 622 x̄: 23.94 x̃: 4 helped stats (rel) min: <.01% max: 2.85% x̄: 0.33% x̃: 0.12% HURT stats (abs) min: 2 max: 520 x̄: 31.65 x̃: 6 HURT stats (rel) min: 0.02% max: 2.45% x̄: 0.34% x̃: 0.15% 95% mean confidence interval for cycles value: -26.41 8.64 95% mean confidence interval for cycles %-change: -0.27% -0.03% Inconclusive result (value mean confidence interval includes 0). No shader-db changes on earlier Intel platforms. Reviewed-by: Anuj Phogat anuj.phogat@gmail.com [v1] Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9237>
2020-12-07 00:26:04 +00:00
/* Reject cases that would violate register regioning restrictions. */
if ((value.file == UNIFORM || value.swizzle != BRW_SWIZZLE_XYZW) &&
intel: Rename gen field in gen_device_info struct to ver Commands used to do the changes: export SEARCH_PATH="src/intel src/gallium/drivers/iris src/mesa/drivers/dri/i965" grep -E "info\)*(.|->)gen" -rIl $SEARCH_PATH | xargs sed -ie "s/info\()*\)\(\.\|->\)gen/info\1\2ver/g" Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9936>
2021-03-29 22:41:58 +01:00
((devinfo->ver == 6 && inst->is_math()) ||
intel/compiler: Relax some conditions in try_copy_propagate Previously can_do_source_mods was used to determine whether a value with a source modifier or a value from a scalar source (e.g., a uniform) could be copy propagated. The former is a superset of the latter, so this always produces correct results, but it is overly restrictive. For example, a BFI instruction can't have source modifiers, but it can have scalar sources. This was originally authored to prevent a small number of shader-db regressions in a commit that marked SHR has not being able to have source modifiers. That commit has since been dropped in favor of a different method. v2: Refactor register region restriction detection to a helper function. Suggested by Jason. No fossil-db changes on any Intel platform. All Gen7+ platforms had similar results. (Ice Lake shown) total instructions in shared programs: 20039111 -> 20038943 (<.01%) instructions in affected programs: 31736 -> 31568 (-0.53%) helped: 104 HURT: 0 helped stats (abs) min: 1 max: 9 x̄: 1.62 x̃: 1 helped stats (rel) min: 0.30% max: 0.88% x̄: 0.45% x̃: 0.42% 95% mean confidence interval for instructions value: -2.03 -1.20 95% mean confidence interval for instructions %-change: -0.47% -0.42% Instructions are helped. total cycles in shared programs: 980309750 -> 980308897 (<.01%) cycles in affected programs: 591078 -> 590225 (-0.14%) helped: 70 HURT: 26 helped stats (abs) min: 2 max: 622 x̄: 23.94 x̃: 4 helped stats (rel) min: <.01% max: 2.85% x̄: 0.33% x̃: 0.12% HURT stats (abs) min: 2 max: 520 x̄: 31.65 x̃: 6 HURT stats (rel) min: 0.02% max: 2.45% x̄: 0.34% x̃: 0.15% 95% mean confidence interval for cycles value: -26.41 8.64 95% mean confidence interval for cycles %-change: -0.27% -0.03% Inconclusive result (value mean confidence interval includes 0). No shader-db changes on earlier Intel platforms. Reviewed-by: Anuj Phogat anuj.phogat@gmail.com [v1] Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9237>
2020-12-07 00:26:04 +00:00
inst->is_send_from_grf() ||
inst->uses_indirect_addressing())) {
return false;
}
i965/vec4: Change types as needed to propagate source modifiers using current instruction SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to generate. This commit adds support for copy propagation using current instruction as reference. Equivalent to commit 472ef9 but for vec4. v2: include check for saturate, as Jason Ekstrand suggested v3: check that the dst.type and the src type are the same, in order to solve (among others) the following deqp regression with v2: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uint_vertex Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 09:26:55 +01:00
if (has_source_modifiers &&
value.type != inst->src[arg].type &&
i965: Extract can_change_source_types() functions. Make them members of fs_inst/vec4_instruction for use elsewhere. Also fix the fs version to check that dst.type == src[1].type and for !saturate. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-10-14 10:12:09 +01:00
!inst->can_change_types())
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
return false;
i965: Bail on vec4 copy propagation for scratch writes with source modifiers Fixes Khronos GLES3 CTS test: dynamic_expression_array_access_vertex Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2014-07-28 23:41:55 +01:00
if (has_source_modifiers &&
intel: Rename GENx keyword to GFXx Commands used to do the changes: export SEARCH_PATH="src/intel src/gallium/drivers/iris src/mesa/drivers/dri/i965" grep -E "GEN[[:digit:]]+" -rIl $SEARCH_PATH | xargs sed -ie "s/GEN\([[:digit:]]\+\)/GFX\1/g" Exclude the changes to modifiers: grep -E "I915_.*GFX" -rIl $SEARCH_PATH | xargs sed -ie "s/\(I915_.*\)GFX/\1GEN/g" Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9936>
2021-03-30 00:02:30 +01:00
(inst->opcode == SHADER_OPCODE_GFX4_SCRATCH_WRITE ||
intel/compiler: Don't copy prop source mods into PICK_HIGH_32BIT VEC4_OPCODE_PICK_HIGH_32BIT performs 32-bit UD access on a 64-bit DF value. abs and negate make sense on DF, but break entirely when trying to access pieces of the value as unsigned integer dwords. Fixes an fsign Piglit test on Ivybridge: tests/spec/arb_gpu_shader_fp64/execution/built-in-functions/vs-sign-neg-abs It had regressed when I removed nir_lower_to_source_modifiers, as that caused us to start generating different code which provoked this bug. Fixes: b7c47c4f7cf ("intel/compiler: Drop nir_lower_to_source_mods() and related handling.") Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2817 Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4691>
2020-04-22 23:03:03 +01:00
inst->opcode == VEC4_OPCODE_PICK_HIGH_32BIT))
i965: Bail on vec4 copy propagation for scratch writes with source modifiers Fixes Khronos GLES3 CTS test: dynamic_expression_array_access_vertex Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2014-07-28 23:41:55 +01:00
return false;
i965/vec4: check swizzle before discarding a uniform on a 3src operand Without this commit, copy propagation is discarded if it involves a uniform with an instruction that has 3 sources. But 3 sourced instructions can access scalar values. For example, this is what vec4_visitor::fix_3src_operand() is already doing: if (src.file == UNIFORM && brw_is_single_value_swizzle(src.swizzle)) return src; Shader-db results (unfiltered) on NIR: total instructions in shared programs: 6259650 -> 6241985 (-0.28%) instructions in affected programs: 812755 -> 795090 (-2.17%) helped: 7930 HURT: 0 Shader-db results (unfiltered) on IR: total instructions in shared programs: 6445822 -> 6441788 (-0.06%) instructions in affected programs: 296630 -> 292596 (-1.36%) helped: 2533 HURT: 0 v2: - Updated commit message, using Matt Turner suggestions - Move the check after we've created the final value, as Jason Ekstrand suggested - Clean up the condition v3: - Move the check back to the original place, to keep things tidy, as suggested by Jason Ekstrand v4: - Fixed missing is_single_value_swizzle() as pointed by Jason Ekstrand Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-23 18:22:17 +01:00
unsigned composed_swizzle = brw_compose_swizzle(inst->src[arg].swizzle,
value.swizzle);
i965/vec4: don't copy propagate vector opcodes that operate in align1 mode Basically, ALIGN1 mode will ignore swizzles on the input vectors so we don't want the copy propagation pass to mess with them. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2016-02-11 13:19:58 +00:00
/* Instructions that operate on vectors in ALIGN1 mode will ignore swizzles
* so copy-propagation won't be safe if the composed swizzle is anything
* other than the identity.
*/
if (is_align1_opcode(inst->opcode) && composed_swizzle != BRW_SWIZZLE_XYZW)
return false;
intel/compiler: Introduce a new brw_isa_info structure This structure will contain the opcode mapping tables in the next commit. For now, this is the mechanical change to plumb it into all the necessary places, and it continues simply holding devinfo. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17309>
2022-06-29 22:13:31 +01:00
if (inst->is_3src(compiler) &&
i965/vec4: don't copy ATTR into 3src instructions with complex swizzles The vec4 backend, at the end, does this: if (inst->is_3src()) { for (int i = 0; i < 3; i++) { if (inst->src[i].vstride == BRW_VERTICAL_STRIDE_0) assert(brw_is_single_value_swizzle(inst->src[i].swizzle)); So make sure that we use the same conditions when trying to copy-propagate. UNIFORMs will be converted to vstride 0 in convert_to_hw_regs, but so will ATTRs when interleaved (as will happen in a GS with multiple attributes). Since the vstride is not set at copy-prop time, infer it by inspecting dispatch_mode and reject ATTRs if they have non-scalar swizzles and are interleaved. Fixes assertion errors in dolphin-generated geometry shaders (or misrendering on opt builds) on Sandybridge or on IVB/HSW with INTEL_DEBUG=nodualobj. Co-authored-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93418 Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
2016-01-18 01:30:14 +00:00
(value.file == UNIFORM ||
(value.file == ATTR && attributes_per_reg != 1)) &&
i965/vec4: check swizzle before discarding a uniform on a 3src operand Without this commit, copy propagation is discarded if it involves a uniform with an instruction that has 3 sources. But 3 sourced instructions can access scalar values. For example, this is what vec4_visitor::fix_3src_operand() is already doing: if (src.file == UNIFORM && brw_is_single_value_swizzle(src.swizzle)) return src; Shader-db results (unfiltered) on NIR: total instructions in shared programs: 6259650 -> 6241985 (-0.28%) instructions in affected programs: 812755 -> 795090 (-2.17%) helped: 7930 HURT: 0 Shader-db results (unfiltered) on IR: total instructions in shared programs: 6445822 -> 6441788 (-0.06%) instructions in affected programs: 296630 -> 292596 (-1.36%) helped: 2533 HURT: 0 v2: - Updated commit message, using Matt Turner suggestions - Move the check after we've created the final value, as Jason Ekstrand suggested - Clean up the condition v3: - Move the check back to the original place, to keep things tidy, as suggested by Jason Ekstrand v4: - Fixed missing is_single_value_swizzle() as pointed by Jason Ekstrand Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-23 18:22:17 +01:00
!brw_is_single_value_swizzle(composed_swizzle))
i965/vs: Add support for LRP instruction. Only 13 affected programs in shader-db, but they were all helped. total instructions in shared programs: 368877 -> 368851 (-0.01%) instructions in affected programs: 1576 -> 1550 (-1.65%) Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Eric Anholt <eric@anholt.net>
2013-04-25 19:03:38 +01:00
return false;
i965/vs: Don't copy propagate into SEND-from-GRF messages. SEND can't deal with swizzles, source modifiers, and so on. This should avoid problems with VS pull constant loads on Broadwell. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-12-16 08:40:30 +00:00
if (inst->is_send_from_grf())
return false;
intel: fix typos found by codespell Acked-by: David Heidelberg <david.heidelberg@collabora.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17191>
2022-06-22 17:31:08 +01:00
/* we can't generally copy-propagate UD negations because we
i965: Fix negate with unsigned integers For code such as: uint tmp1 = uint(in0); uint tmp2 = -tmp1; float out0 = float(tmp2); We produce code like: mov(8) g5<1>.xF -g9<4,4,1>.xUD which does not produce correct results. This code produces the results we would expect if tmp1 and tmp2 were signed integers instead. It seems that a similar problem was detected and addressed when using negations with unsigned integers as part of condionals, but it looks like the problem has a wider impact than that. This patch fixes the problem by preventing copy-propagation of negated UD registers in all scenarios, not only in conditionals. Fixes the following 24 dEQP tests: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uint_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec2_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec3_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec4_* Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2015-01-19 11:32:09 +00:00
* end up accessing the resulting values as signed integers
* instead. See also resolve_ud_negate().
i965/vs: Fix comparisons with uint negation. The condmod instruction ends up generating garbage condition codes, because apparently the comparison happens on the accumulator value (33 bits for UD), not the truncated value that would be written. Fixes vs-op-neg-* Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-03 23:31:52 +01:00
*/
i965: Fix negate with unsigned integers For code such as: uint tmp1 = uint(in0); uint tmp2 = -tmp1; float out0 = float(tmp2); We produce code like: mov(8) g5<1>.xF -g9<4,4,1>.xUD which does not produce correct results. This code produces the results we would expect if tmp1 and tmp2 were signed integers instead. It seems that a similar problem was detected and addressed when using negations with unsigned integers as part of condionals, but it looks like the problem has a wider impact than that. This patch fixes the problem by preventing copy-propagation of negated UD registers in all scenarios, not only in conditionals. Fixes the following 24 dEQP tests: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uint_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec2_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec3_* dEQP-GLES3.functional.shaders.operator.unary_operator.minus.*_uvec4_* Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
2015-01-19 11:32:09 +00:00
if (value.negate &&
i965/vs: Fix comparisons with uint negation. The condmod instruction ends up generating garbage condition codes, because apparently the comparison happens on the accumulator value (33 bits for UD), not the truncated value that would be written. Fixes vs-op-neg-* Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2011-10-03 23:31:52 +01:00
value.type == BRW_REGISTER_TYPE_UD)
return false;
i965/vs: Allow copy propagation on GRFs. Further reduces instruction count by 4.0% in 40.7% of the vertex shaders.
2011-09-02 00:43:38 +01:00
/* Don't report progress if this is a noop. */
i965: Make src_reg::equals() take a constant reference, not a pointer. This is more typical C++ style. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2013-03-06 16:51:44 +00:00
if (value.equals(inst->src[arg]))
i965/vs: Allow copy propagation on GRFs. Further reduces instruction count by 4.0% in 40.7% of the vertex shaders.
2011-09-02 00:43:38 +01:00
return false;
i965/vec4: Fix broken saturate mask check in copy propagation. 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>
2015-03-19 16:25:30 +00:00
const unsigned dst_saturate_mask = inst->dst.writemask &
brw_apply_swizzle_to_mask(inst->src[arg].swizzle, entry->saturatemask);
if (dst_saturate_mask) {
/* We either saturate all or nothing. */
if (dst_saturate_mask != inst->dst.writemask)
return false;
i965/vec4: Trivial copy propagate clean-up. 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>
2015-03-19 13:30:06 +00:00
/* Limit saturate propagation only to SEL with src1 bounded within 0.0
* and 1.0, otherwise skip copy propagate altogether.
i965/vec4: Fix broken saturate mask check in copy propagation. 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>
2015-03-19 16:25:30 +00:00
*/
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
switch(inst->opcode) {
case BRW_OPCODE_SEL:
i965/vec4: Add argument index and type checks to SEL saturate propagation. SEL saturate propagation already implicitly relies on these assumptions. Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2015-03-18 13:51:45 +00:00
if (arg != 0 ||
inst->src[0].type != BRW_REGISTER_TYPE_F ||
inst->src[1].file != IMM ||
inst->src[1].type != BRW_REGISTER_TYPE_F ||
i965: Use immediate storage in inherited brw_reg. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-24 22:55:57 +01:00
inst->src[1].f < 0.0 ||
inst->src[1].f > 1.0) {
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
return false;
}
if (!inst->saturate)
inst->saturate = true;
break;
default:
return false;
}
}
i965/vec4: refactor brw_vec4_copy_propagation. Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the implementation on some specific cases, like knowing if you can propagate from a previous instruction even with type mismatches, even messier (for example, with the need of maintaining more of one has_source_modifiers). The refactoring clears stuff, and gives support to this mentioned use case without doing anything extra (for example, only one has_source_modifiers is used). Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1683842 -> 1669037 (-0.88%) instructions in affected programs: 739837 -> 725032 (-2.00%) helped: 6237 HURT: 0 v2: using 'arg' index to get the from inst was wrong v3: rebased against last change on the previous patch of the series v4: don't need to track instructions on struct copy_entry, as we only set the source on a direct copy v5: change the approach for a refactoring v6: tweaked comments Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 16:19:50 +01:00
/* Build the final value */
if (inst->src[arg].abs) {
value.negate = false;
value.abs = true;
}
if (inst->src[arg].negate)
value.negate = !value.negate;
i965/vec4: check swizzle before discarding a uniform on a 3src operand Without this commit, copy propagation is discarded if it involves a uniform with an instruction that has 3 sources. But 3 sourced instructions can access scalar values. For example, this is what vec4_visitor::fix_3src_operand() is already doing: if (src.file == UNIFORM && brw_is_single_value_swizzle(src.swizzle)) return src; Shader-db results (unfiltered) on NIR: total instructions in shared programs: 6259650 -> 6241985 (-0.28%) instructions in affected programs: 812755 -> 795090 (-2.17%) helped: 7930 HURT: 0 Shader-db results (unfiltered) on IR: total instructions in shared programs: 6445822 -> 6441788 (-0.06%) instructions in affected programs: 296630 -> 292596 (-1.36%) helped: 2533 HURT: 0 v2: - Updated commit message, using Matt Turner suggestions - Move the check after we've created the final value, as Jason Ekstrand suggested - Clean up the condition v3: - Move the check back to the original place, to keep things tidy, as suggested by Jason Ekstrand v4: - Fixed missing is_single_value_swizzle() as pointed by Jason Ekstrand Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-09-23 18:22:17 +01:00
value.swizzle = composed_swizzle;
i965/vec4: Change types as needed to propagate source modifiers using current instruction SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to generate. This commit adds support for copy propagation using current instruction as reference. Equivalent to commit 472ef9 but for vec4. v2: include check for saturate, as Jason Ekstrand suggested v3: check that the dst.type and the src type are the same, in order to solve (among others) the following deqp regression with v2: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uint_vertex Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 09:26:55 +01:00
if (has_source_modifiers &&
value.type != inst->src[arg].type) {
i965: Extract can_change_source_types() functions. Make them members of fs_inst/vec4_instruction for use elsewhere. Also fix the fs version to check that dst.type == src[1].type and for !saturate. Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-10-14 10:12:09 +01:00
assert(inst->can_change_types());
i965/vec4: Change types as needed to propagate source modifiers using current instruction SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to generate. This commit adds support for copy propagation using current instruction as reference. Equivalent to commit 472ef9 but for vec4. v2: include check for saturate, as Jason Ekstrand suggested v3: check that the dst.type and the src type are the same, in order to solve (among others) the following deqp regression with v2: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uint_vertex Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 09:26:55 +01:00
for (int i = 0; i < 3; i++) {
inst->src[i].type = value.type;
}
inst->dst.type = value.type;
i965/vec4: refactor brw_vec4_copy_propagation. Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the implementation on some specific cases, like knowing if you can propagate from a previous instruction even with type mismatches, even messier (for example, with the need of maintaining more of one has_source_modifiers). The refactoring clears stuff, and gives support to this mentioned use case without doing anything extra (for example, only one has_source_modifiers is used). Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1683842 -> 1669037 (-0.88%) instructions in affected programs: 739837 -> 725032 (-2.00%) helped: 6237 HURT: 0 v2: using 'arg' index to get the from inst was wrong v3: rebased against last change on the previous patch of the series v4: don't need to track instructions on struct copy_entry, as we only set the source on a direct copy v5: change the approach for a refactoring v6: tweaked comments Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 16:19:50 +01:00
} else {
i965/vec4: Change types as needed to propagate source modifiers using current instruction SEL and MOV instructions, as long as they don't have source modifiers, are just copying bits around. So those kind of instruction could be propagated even if there are type mismatches. This is needed because NIR generates integer SEL and MOV instructions whenever it doesn't know what else to generate. This commit adds support for copy propagation using current instruction as reference. Equivalent to commit 472ef9 but for vec4. v2: include check for saturate, as Jason Ekstrand suggested v3: check that the dst.type and the src type are the same, in order to solve (among others) the following deqp regression with v2: dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uint_vertex Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 09:26:55 +01:00
value.type = inst->src[arg].type;
i965/vec4: refactor brw_vec4_copy_propagation. Now it is more similar to brw_fs_copy_propagation, with three clear stages: 1) Build up the value we are propagating as if it were the source of a single MOV: 2) Check that we can propagate that value 3) Build the final value Previously everything was somewhat messed up, making the implementation on some specific cases, like knowing if you can propagate from a previous instruction even with type mismatches, even messier (for example, with the need of maintaining more of one has_source_modifiers). The refactoring clears stuff, and gives support to this mentioned use case without doing anything extra (for example, only one has_source_modifiers is used). Shader-db results for vec4 programs on Haswell: total instructions in shared programs: 1683842 -> 1669037 (-0.88%) instructions in affected programs: 739837 -> 725032 (-2.00%) helped: 6237 HURT: 0 v2: using 'arg' index to get the from inst was wrong v3: rebased against last change on the previous patch of the series v4: don't need to track instructions on struct copy_entry, as we only set the source on a direct copy v5: change the approach for a refactoring v6: tweaked comments Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
2015-09-16 16:19:50 +01:00
}
i965/vs: Add support for copy propagation of the UNIFORM and ATTR files. Removes 2.0% of the instructions from 35.7% of vertex shaders in shader-db.
2011-09-02 00:21:14 +01:00
inst->src[arg] = value;
return true;
}
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
bool
i965/vec4: Add parameter to skip doing constant propagation. After CSEing some MOV ..., VF instructions we have code like mov tmp, [1F, 2F, 3F, 4F]VF mov r10, tmp mov r11, tmp ... use r10 use r11 We want to copy propagate tmp into the uses of r10 and r11, but *not* constant propagate the VF immediate into the uses of tmp. Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2014-12-21 01:37:09 +00:00
vec4_visitor::opt_copy_propagation(bool do_constant_prop)
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
{
i965/vec4: don't copy ATTR into 3src instructions with complex swizzles The vec4 backend, at the end, does this: if (inst->is_3src()) { for (int i = 0; i < 3; i++) { if (inst->src[i].vstride == BRW_VERTICAL_STRIDE_0) assert(brw_is_single_value_swizzle(inst->src[i].swizzle)); So make sure that we use the same conditions when trying to copy-propagate. UNIFORMs will be converted to vstride 0 in convert_to_hw_regs, but so will ATTRs when interleaved (as will happen in a GS with multiple attributes). Since the vstride is not set at copy-prop time, infer it by inspecting dispatch_mode and reject ATTRs if they have non-scalar swizzles and are interleaved. Fixes assertion errors in dolphin-generated geometry shaders (or misrendering on opt builds) on Sandybridge or on IVB/HSW with INTEL_DEBUG=nodualobj. Co-authored-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93418 Cc: "11.0 11.1" <mesa-stable@lists.freedesktop.org>
2016-01-18 01:30:14 +00:00
/* If we are in dual instanced or single mode, then attributes are going
* to be interleaved, so one register contains two attribute slots.
*/
const int attributes_per_reg =
prog_data->dispatch_mode == DISPATCH_MODE_4X2_DUAL_OBJECT ? 1 : 2;
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
bool progress = false;
i965: Factor out virtual GRF allocation to a separate object. Right now virtual GRF book-keeping and allocation is performed in each visitor class separately (among other hundred different things), leading to duplicated logic in each visitor and preventing layering as it forces any code that manipulates i965 IR and needs to allocate virtual registers to depend on the specific visitor that happens to be used to translate from GLSL IR. v2: Use realloc()/free() to allocate VGRF book-keeping arrays (Connor). Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-10 13:51:34 +00:00
struct copy_entry entries[alloc.total_size];
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
memset(&entries, 0, sizeof(entries));
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
i965/vec4: Don't use instruction list after calculating the cfg. Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
2014-09-01 21:42:51 +01:00
foreach_block_and_inst(block, vec4_instruction, inst, cfg) {
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
/* This pass only works on basic blocks. If there's flow
* control, throw out all our information and start from
* scratch.
*
* This should really be fixed by using a structure like in
* src/glsl/opt_copy_propagation.cpp to track available copies.
*/
if (!is_dominated_by_previous_instruction(inst)) {
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
memset(&entries, 0, sizeof(entries));
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
continue;
}
/* For each source arg, see if each component comes from a copy
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
* from the same type file (IMM, VGRF, UNIFORM), and try
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
* optimizing out access to the copy result
*/
for (int i = 2; i >= 0; i--) {
/* Copied values end up in GRFs, and we don't track reladdr
* accesses.
*/
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
if (inst->src[i].file != VGRF ||
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
inst->src[i].reladdr)
continue;
i965/vec4: Fix copy propagation for non-register-aligned regions. This prevents it from trying to propagate a copy through a register-misaligned region. MOV instructions with a misaligned destination shouldn't be treated as a direct GRF copy, because they only define the destination GRFs partially. Also fix the interference check implemented with is_channel_updated() to consider overlapping regions with different register offset to interfere, since the writemask check implemented in the function is only valid under the assumption that the source and destination regions are aligned component by component. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-02 06:31:43 +01:00
/* We only handle register-aligned single GRF copies. */
if (inst->size_read(i) != REG_SIZE ||
inst->src[i].offset % REG_SIZE)
i965/vec4: Fix handling of multiple register reads and writes during copy propagation. Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-03-18 17:46:54 +00:00
continue;
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
const unsigned reg = (alloc.offsets[inst->src[i].nr] +
i965/vec4: Replace dst/src_reg::reg_offset with dst/src_reg::offset expressed in bytes. The dst/src_reg::offset field in byte units introduced in the previous patch is a more straightforward alternative to an offset representation split between ::reg_offset and ::subreg_offset fields. The split representation makes it too easy to forget about one of the offsets while dealing with the other, which has led to multiple FS back-end bugs in the past. To make the matter worse the unit reg_offset was expressed in was rather inconsistent, for uniforms it would be expressed in either 4B or 16B units depending on the back-end, and for most other things it would be expressed in 32B units. This encodes reg_offset as a new offset field expressed consistently in byte units. Each rvalue reference of reg_offset in existing code like 'x = r.reg_offset' is rewritten to 'x = r.offset / reg_unit', and each lvalue reference like 'r.reg_offset = x' is rewritten to 'r.offset = r.offset % reg_unit + x * reg_unit'. Because the change affects a lot of places and is rather non-trivial to verify due to the inconsistent value of reg_unit, I've tried to avoid making any additional changes other than applying the rewrite rule above in order to keep the patch as simple as possible, sometimes at the cost of introducing obvious stupidity (e.g. algebraic expressions that could be simplified given some knowledge of the context) -- I'll clean those up later on in a second pass. v2: Fix division by the wrong reg_unit in the UNIFORM case of convert_to_hw_regs(). (Iago) Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-01 21:10:36 +01:00
inst->src[i].offset / REG_SIZE);
i965/vec4: Propagate swizzles correctly during copy propagation. This simplifies the code that iterates over the per-component values found in the matching copy_entry struct and checks whether the register regions that were copied to each component are similar enough to be treated as a single (reswizzled) value which can be propagated into the current instruction. Aside from being scattered between opt_copy_propagation(), try_copy_propagate(), and try_constant_propagate(), what I found terribly confusing about the preexisting logic was that opt_copy_propagation() tried to reorder the array of values according to the swizzle of the instruction source, which meant one would have had to invert the reordering applied at the top level in order to find out which component to take from each value (we were just taking the i-th component from the i-th value, which is not correct in general). The saturate mask was also being swizzled incorrectly. This consolidates the logic for matching multiple components of a copy_entry into a single function which returns the result as a regular src_reg on success, as if the copy had been performed with a single MOV instruction copying all components of the src_reg into the destination. Fixes several ARB_vertex_program MOV test-cases from: https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program Acked-by: Matt Turner <mattst88@gmail.com>
2016-02-27 01:42:27 +00:00
const copy_entry &entry = entries[reg];
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
intel/vec4: Remove all support for Gen8+ [v2] v2: Restore the gen == 10 hunk in brw_compile_vs (around line 2940). This function is also used for scalar VS compiles. Squash in: intel/vec4: Reindent after removing Gen8+ support intel/vec4: Silence unused parameter warning in try_immediate_source Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> [v1] Reviewed-by: Matt Turner <mattst88@gmail.com> [v1] Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6826>
2020-09-22 21:09:56 +01:00
if (do_constant_prop && try_constant_propagate(inst, i, &entry))
i965/vec4: Try constant propagate after copy propagate made progress. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2014-06-24 06:29:57 +01:00
progress = true;
intel/compiler: Introduce a new brw_isa_info structure This structure will contain the opcode mapping tables in the next commit. For now, this is the mechanical change to plumb it into all the necessary places, and it continues simply holding devinfo. Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17309>
2022-06-29 22:13:31 +01:00
else if (try_copy_propagate(compiler, inst, i, &entry, attributes_per_reg))
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
progress = true;
}
/* Track available source registers. */
i965: Rename GRF to VGRF. The 2-bit hardware register file field is ARF, GRF, MRF, IMM. Rename GRF to VGRF (virtual GRF) so that we can reuse the GRF name to mean an assigned general purpose register. Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2015-10-27 00:09:25 +00:00
if (inst->dst.file == VGRF) {
i965/vs: Fix invalid array access in copy propagation. Accessing virtual_grf_reg_map[inst->dst.reg] is invalid if inst->dst.file != GRF. Since is_direct_copy already implies a GRF destination, we can just move the check earlier. Fixes a regression in commit 07ee9f374f2946f852896e9264c7fa83eafc3f16. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44302 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-01-05 21:54:41 +00:00
const int reg =
i965/vec4: Replace dst/src_reg::reg_offset with dst/src_reg::offset expressed in bytes. The dst/src_reg::offset field in byte units introduced in the previous patch is a more straightforward alternative to an offset representation split between ::reg_offset and ::subreg_offset fields. The split representation makes it too easy to forget about one of the offsets while dealing with the other, which has led to multiple FS back-end bugs in the past. To make the matter worse the unit reg_offset was expressed in was rather inconsistent, for uniforms it would be expressed in either 4B or 16B units depending on the back-end, and for most other things it would be expressed in 32B units. This encodes reg_offset as a new offset field expressed consistently in byte units. Each rvalue reference of reg_offset in existing code like 'x = r.reg_offset' is rewritten to 'x = r.offset / reg_unit', and each lvalue reference like 'r.reg_offset = x' is rewritten to 'r.offset = r.offset % reg_unit + x * reg_unit'. Because the change affects a lot of places and is rather non-trivial to verify due to the inconsistent value of reg_unit, I've tried to avoid making any additional changes other than applying the rewrite rule above in order to keep the patch as simple as possible, sometimes at the cost of introducing obvious stupidity (e.g. algebraic expressions that could be simplified given some knowledge of the context) -- I'll clean those up later on in a second pass. v2: Fix division by the wrong reg_unit in the UNIFORM case of convert_to_hw_regs(). (Iago) Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
2016-09-01 21:10:36 +01:00
alloc.offsets[inst->dst.nr] + inst->dst.offset / REG_SIZE;
i965/vs: Properly clear cur_value when propagating direct copies. Consider the following code: MOV A.x, B.x MOV B.x, C.x After the first line, cur_value[A][0] == B, indicating that A.x's current value came from register B. When processing the second line, we update cur_value[B][0] to C. However, for drect copies, we fail to reset cur_value[A][0] to NULL. This is necessary because the value of A is no longer the value of B. Fixes Counter-Strike: Source in Wine (where the menu rendered completely black in DX9 mode), completely white textures in Civilization V, and the new Piglit test glsl-vs-copy-propagation-1.shader_test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42032 Tested-by: Matt Turner <mattst88@gmail.com> Tested-by: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
2011-12-24 04:24:46 +00:00
i965/vs: Fix invalid array access in copy propagation. Accessing virtual_grf_reg_map[inst->dst.reg] is invalid if inst->dst.file != GRF. Since is_direct_copy already implies a GRF destination, we can just move the check earlier. Fixes a regression in commit 07ee9f374f2946f852896e9264c7fa83eafc3f16. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44302 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-01-05 21:54:41 +00:00
/* Update our destination's current channel values. For a direct copy,
* the value is the newly propagated source. Otherwise, we don't know
* the new value, so clear it.
*/
bool direct_copy = is_direct_copy(inst);
i965/vec4: Don't lose copy propagation saturate bits for not written components. Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2015-03-18 13:45:16 +00:00
entries[reg].saturatemask &= ~inst->dst.writemask;
i965/vs: Fix invalid array access in copy propagation. Accessing virtual_grf_reg_map[inst->dst.reg] is invalid if inst->dst.file != GRF. Since is_direct_copy already implies a GRF destination, we can just move the check earlier. Fixes a regression in commit 07ee9f374f2946f852896e9264c7fa83eafc3f16. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44302 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-01-05 21:54:41 +00:00
for (int i = 0; i < 4; i++) {
if (inst->dst.writemask & (1 << i)) {
Revert "i965/vec4: Don't lose the saturate modifier in copy propagation." This reverts commit 0dfec59a2785cf7a87ee5128889ecebe810b611b. 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>
2015-03-18 13:39:03 +00:00
entries[reg].value[i] = direct_copy ? &inst->src[0] : NULL;
i965/vec4: Trivial copy propagate clean-up. 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>
2015-03-19 13:30:06 +00:00
entries[reg].saturatemask |=
inst->saturate && direct_copy ? 1 << i : 0;
}
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
}
i965/vs: Fix invalid array access in copy propagation. Accessing virtual_grf_reg_map[inst->dst.reg] is invalid if inst->dst.file != GRF. Since is_direct_copy already implies a GRF destination, we can just move the check earlier. Fixes a regression in commit 07ee9f374f2946f852896e9264c7fa83eafc3f16. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44302 Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
2012-01-05 21:54:41 +00:00
/* Clear the records for any registers whose current value came from
* our destination's updated channels, as the two are no longer equal.
*/
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
if (inst->dst.reladdr)
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
memset(&entries, 0, sizeof(entries));
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
else {
i965: Factor out virtual GRF allocation to a separate object. Right now virtual GRF book-keeping and allocation is performed in each visitor class separately (among other hundred different things), leading to duplicated logic in each visitor and preventing layering as it forces any code that manipulates i965 IR and needs to allocate virtual registers to depend on the specific visitor that happens to be used to translate from GLSL IR. v2: Use realloc()/free() to allocate VGRF book-keeping arrays (Connor). Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-02-10 13:51:34 +00:00
for (unsigned i = 0; i < alloc.total_size; i++) {
i965/vs: Clear tracked copy propagation values whose source gets overwritten. This only occurs for GRFs, and hasn't mattered until now because we only copy propagated non-GRFs.
2011-09-02 00:40:07 +01:00
for (int j = 0; j < 4; j++) {
i965/vec4: Trivial copy propagate clean-up. 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>
2015-03-19 13:30:06 +00:00
if (is_channel_updated(inst, entries[i].value, j)) {
i965/vec4: Allow propagation of instructions with saturate flag to sel When sel conditon is bounded within 0 and 1.0. This allows code as: mov.sat a b sel.ge dst a 0.25F To be propagated as: sel.ge.sat dst b 0.25F v3: - Syntax clarifications in inst->saturate assignment - Remove extra parenthesis when assigning src_reg value from copy_entry (Matt Turner) v4: - Take channels into consideration when propagating saturated instructions. Reviewed-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
2014-07-04 12:52:36 +01:00
entries[i].value[j] = NULL;
entries[i].saturatemask &= ~(1 << j);
}
i965/vs: Clear tracked copy propagation values whose source gets overwritten. This only occurs for GRFs, and hasn't mattered until now because we only copy propagated non-GRFs.
2011-09-02 00:40:07 +01:00
}
}
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
}
}
}
if (progress)
intel/compiler: Pass detailed dependency classes to invalidate_analysis() Have fun reading through the whole back-end optimizer to verify whether I've missed any dependency flags -- Or alternatively, just trust that any mistake here will trigger an assertion failure during analysis pass validation if it ever poses a problem for the consistency of any of the analysis passes managed by the framework. Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4012>
2016-03-14 02:26:37 +00:00
invalidate_analysis(DEPENDENCY_INSTRUCTION_DATA_FLOW |
DEPENDENCY_INSTRUCTION_DETAIL);
i965/vs: Add constant propagation to a few opcodes. This differs from the FS in that we track constants in each destination channel, and we we have to look at all the swizzled source channels. Also, the instruction stream walk is done in an O(n) manner instead of O(n^2). Across shader-db, this reduces 8.0% of the instructions from 60.0% of the vertex shaders, leaving us now behind the old backend by 11.1% overall.
2011-08-30 21:25:15 +01:00
return progress;
}
} /* namespace brw */