2012-05-08 13:01:52 -07:00
|
|
|
/*
|
|
|
|
|
* Copyright © 2012 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.
|
|
|
|
|
*/
|
|
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
/** @file brw_fs_copy_propagation.cpp
|
|
|
|
|
*
|
|
|
|
|
* Support for global copy propagation in two passes: A local pass that does
|
|
|
|
|
* intra-block copy (and constant) propagation, and a global pass that uses
|
|
|
|
|
* dataflow analysis on the copies available at the end of each block to re-do
|
|
|
|
|
* local copy propagation with more copies available.
|
|
|
|
|
*
|
2013-10-19 16:40:19 -07:00
|
|
|
* See Muchnick's Advanced Compiler Design and Implementation, section
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
* 12.5 (p356).
|
|
|
|
|
*/
|
|
|
|
|
|
2015-02-11 15:05:06 -08:00
|
|
|
#include "util/bitset.h"
|
2019-05-05 00:13:20 -05:00
|
|
|
#include "util/u_math.h"
|
2023-08-18 19:11:58 -07:00
|
|
|
#include "util/rb_tree.h"
|
2012-05-08 13:01:52 -07:00
|
|
|
#include "brw_fs.h"
|
2017-10-23 13:47:10 -07:00
|
|
|
#include "brw_fs_live_variables.h"
|
2012-10-03 13:03:12 -07:00
|
|
|
#include "brw_cfg.h"
|
2015-11-22 18:27:42 -08:00
|
|
|
#include "brw_eu.h"
|
2012-05-08 13:01:52 -07:00
|
|
|
|
2017-10-23 13:47:10 -07:00
|
|
|
using namespace brw;
|
|
|
|
|
|
2012-05-08 13:01:52 -07:00
|
|
|
namespace { /* avoid conflict with opt_copy_propagation_elements */
|
2023-08-30 13:20:35 -07:00
|
|
|
struct acp_entry {
|
2023-08-28 15:46:53 -07:00
|
|
|
struct rb_node by_dst;
|
2023-08-18 19:11:58 -07:00
|
|
|
struct rb_node by_src;
|
2012-05-08 13:01:52 -07:00
|
|
|
fs_reg dst;
|
|
|
|
|
fs_reg src;
|
2019-05-05 00:13:20 -05:00
|
|
|
unsigned global_idx;
|
2019-12-30 00:36:48 -08:00
|
|
|
unsigned size_written;
|
|
|
|
|
unsigned size_read;
|
2014-04-17 15:13:00 -07:00
|
|
|
enum opcode opcode;
|
intel/fs: Allow copy propagation between MOVs of mixed sizes
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
Unfortunately, this doesn't clean everything up. Here's a subset of the
"before" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
mov(8) g12<1>UB g7<32,8,4>UB { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g12<8,8,1>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g14<1>UB g8<32,8,4>UB { align1 1Q };
mov(8) g16<1>UW g14<8,8,1>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
And here's the same subset of the "after" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g7<32,8,4>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g16<1>UW g8<32,8,4>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
There are a lot of regioning and type restrictions in
fs_visitor::try_copy_propagate, and I'm a little nervious about messing
with them too much.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
2021-04-13 14:07:19 -07:00
|
|
|
bool is_partial_write;
|
2023-02-10 19:29:20 -08:00
|
|
|
bool force_writemask_all;
|
2012-05-08 13:01:52 -07:00
|
|
|
};
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2023-08-18 19:11:58 -07:00
|
|
|
/**
|
|
|
|
|
* Compare two acp_entry::src.nr
|
|
|
|
|
*
|
|
|
|
|
* This is intended to be used as the comparison function for rb_tree.
|
|
|
|
|
*/
|
2023-08-28 15:46:53 -07:00
|
|
|
static int
|
|
|
|
|
cmp_entry_dst_entry_dst(const struct rb_node *a_node, const struct rb_node *b_node)
|
|
|
|
|
{
|
|
|
|
|
const struct acp_entry *a_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, a_node, by_dst);
|
|
|
|
|
|
|
|
|
|
const struct acp_entry *b_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, b_node, by_dst);
|
|
|
|
|
|
|
|
|
|
return a_entry->dst.nr - b_entry->dst.nr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
cmp_entry_dst_nr(const struct rb_node *a_node, const void *b_key)
|
|
|
|
|
{
|
|
|
|
|
const struct acp_entry *a_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, a_node, by_dst);
|
|
|
|
|
|
|
|
|
|
return a_entry->dst.nr - (uintptr_t) b_key;
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-18 19:11:58 -07:00
|
|
|
static int
|
|
|
|
|
cmp_entry_src_entry_src(const struct rb_node *a_node, const struct rb_node *b_node)
|
|
|
|
|
{
|
|
|
|
|
const struct acp_entry *a_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, a_node, by_src);
|
|
|
|
|
|
|
|
|
|
const struct acp_entry *b_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, b_node, by_src);
|
|
|
|
|
|
|
|
|
|
return a_entry->src.nr - b_entry->src.nr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Compare an acp_entry::src.nr with a raw nr.
|
|
|
|
|
*
|
|
|
|
|
* This is intended to be used as the comparison function for rb_tree.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
cmp_entry_src_nr(const struct rb_node *a_node, const void *b_key)
|
|
|
|
|
{
|
|
|
|
|
const struct acp_entry *a_entry =
|
|
|
|
|
rb_node_data(struct acp_entry, a_node, by_src);
|
|
|
|
|
|
|
|
|
|
return a_entry->src.nr - (uintptr_t) b_key;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
class acp_forward_iterator {
|
|
|
|
|
public:
|
|
|
|
|
acp_forward_iterator(struct rb_node *n, unsigned offset)
|
|
|
|
|
: curr(n), next(nullptr), offset(offset)
|
|
|
|
|
{
|
|
|
|
|
next = rb_node_next_or_null(curr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
acp_forward_iterator &operator++()
|
|
|
|
|
{
|
|
|
|
|
curr = next;
|
|
|
|
|
next = rb_node_next_or_null(curr);
|
|
|
|
|
|
|
|
|
|
return *this;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool operator!=(const acp_forward_iterator &other) const
|
|
|
|
|
{
|
|
|
|
|
return curr != other.curr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct acp_entry *operator*() const
|
|
|
|
|
{
|
|
|
|
|
/* This open-codes part of rb_node_data. */
|
|
|
|
|
return curr != NULL ? (struct acp_entry *)(((char *)curr) - offset)
|
|
|
|
|
: NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
struct rb_node *curr;
|
|
|
|
|
struct rb_node *next;
|
|
|
|
|
unsigned offset;
|
|
|
|
|
};
|
|
|
|
|
|
2023-08-18 17:37:02 -07:00
|
|
|
struct acp {
|
2023-08-28 15:46:53 -07:00
|
|
|
struct rb_tree by_dst;
|
2023-08-18 19:11:58 -07:00
|
|
|
struct rb_tree by_src;
|
|
|
|
|
|
|
|
|
|
acp()
|
|
|
|
|
{
|
2023-08-28 15:46:53 -07:00
|
|
|
rb_tree_init(&by_dst);
|
2023-08-18 19:11:58 -07:00
|
|
|
rb_tree_init(&by_src);
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
acp_forward_iterator begin()
|
|
|
|
|
{
|
|
|
|
|
return acp_forward_iterator(rb_tree_first(&by_src),
|
|
|
|
|
rb_tree_offsetof(struct acp_entry, by_src, 0));
|
|
|
|
|
}
|
|
|
|
|
|
2023-08-18 19:11:58 -07:00
|
|
|
const acp_forward_iterator end() const
|
|
|
|
|
{
|
|
|
|
|
return acp_forward_iterator(nullptr, 0);
|
|
|
|
|
}
|
2023-08-18 17:37:02 -07:00
|
|
|
|
|
|
|
|
unsigned length()
|
|
|
|
|
{
|
|
|
|
|
unsigned l = 0;
|
|
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
for (rb_node *iter = rb_tree_first(&by_src);
|
|
|
|
|
iter != NULL; iter = rb_node_next(iter))
|
|
|
|
|
l++;
|
2023-08-18 17:37:02 -07:00
|
|
|
|
|
|
|
|
return l;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void add(acp_entry *entry)
|
|
|
|
|
{
|
2023-08-28 15:46:53 -07:00
|
|
|
rb_tree_insert(&by_dst, &entry->by_dst, cmp_entry_dst_entry_dst);
|
2023-08-18 19:11:58 -07:00
|
|
|
rb_tree_insert(&by_src, &entry->by_src, cmp_entry_src_entry_src);
|
2023-08-18 17:37:02 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void remove(acp_entry *entry)
|
|
|
|
|
{
|
2023-08-28 15:46:53 -07:00
|
|
|
rb_tree_remove(&by_dst, &entry->by_dst);
|
2023-08-18 19:11:58 -07:00
|
|
|
rb_tree_remove(&by_src, &entry->by_src);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
acp_forward_iterator find_by_src(unsigned nr)
|
|
|
|
|
{
|
|
|
|
|
struct rb_node *rbn = rb_tree_search(&by_src,
|
|
|
|
|
(void *)(uintptr_t) nr,
|
|
|
|
|
cmp_entry_src_nr);
|
|
|
|
|
|
|
|
|
|
return acp_forward_iterator(rbn, rb_tree_offsetof(struct acp_entry,
|
|
|
|
|
by_src, rbn));
|
2023-08-18 17:37:02 -07:00
|
|
|
}
|
2023-08-28 15:46:53 -07:00
|
|
|
|
|
|
|
|
acp_forward_iterator find_by_dst(unsigned nr)
|
|
|
|
|
{
|
|
|
|
|
struct rb_node *rbn = rb_tree_search(&by_dst,
|
|
|
|
|
(void *)(uintptr_t) nr,
|
|
|
|
|
cmp_entry_dst_nr);
|
|
|
|
|
|
|
|
|
|
return acp_forward_iterator(rbn, rb_tree_offsetof(struct acp_entry,
|
|
|
|
|
by_dst, rbn));
|
|
|
|
|
}
|
2023-08-18 17:37:02 -07:00
|
|
|
};
|
|
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
struct block_data {
|
|
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are live at the
|
|
|
|
|
* start of this block. This is the useful output of the analysis, since
|
|
|
|
|
* it lets us plug those into the local copy propagation on the second
|
|
|
|
|
* pass.
|
|
|
|
|
*/
|
2013-03-22 14:11:25 -07:00
|
|
|
BITSET_WORD *livein;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are live at the end
|
|
|
|
|
* of this block. This is done in initial setup from the per-block acps
|
|
|
|
|
* returned by the first local copy prop pass.
|
|
|
|
|
*/
|
2013-03-22 14:11:25 -07:00
|
|
|
BITSET_WORD *liveout;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2013-08-08 23:29:56 -07:00
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are generated by
|
|
|
|
|
* instructions in this block which reach the end of the block without
|
|
|
|
|
* being killed.
|
|
|
|
|
*/
|
|
|
|
|
BITSET_WORD *copy;
|
|
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are killed over the
|
|
|
|
|
* course of this block.
|
|
|
|
|
*/
|
2013-03-22 14:11:25 -07:00
|
|
|
BITSET_WORD *kill;
|
2017-10-23 13:47:10 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are guaranteed to
|
|
|
|
|
* have a fully uninitialized destination at the end of this block.
|
|
|
|
|
*/
|
|
|
|
|
BITSET_WORD *undef;
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table can the
|
|
|
|
|
* start of this block be reached from. Note that this is a weaker
|
|
|
|
|
* condition than livein.
|
|
|
|
|
*/
|
|
|
|
|
BITSET_WORD *reachin;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Which entries in the fs_copy_prop_dataflow acp table are
|
|
|
|
|
* overwritten by an instruction with channel masks inconsistent
|
|
|
|
|
* with the copy instruction (e.g. due to force_writemask_all).
|
|
|
|
|
* Such an overwrite can cause the copy entry to become invalid
|
|
|
|
|
* even if the copy instruction is subsequently re-executed for any
|
|
|
|
|
* given channel i, since the execution of the overwrite for
|
|
|
|
|
* channel i may corrupt other channels j!=i inactive for the
|
|
|
|
|
* subsequent copy.
|
|
|
|
|
*/
|
|
|
|
|
BITSET_WORD *exec_mismatch;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class fs_copy_prop_dataflow
|
|
|
|
|
{
|
|
|
|
|
public:
|
2023-10-02 10:39:09 -07:00
|
|
|
fs_copy_prop_dataflow(linear_ctx *lin_ctx, cfg_t *cfg,
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live,
|
2023-08-18 17:37:02 -07:00
|
|
|
struct acp *out_acp);
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2013-08-09 18:07:45 -07:00
|
|
|
void setup_initial_values();
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
void run();
|
|
|
|
|
|
2016-02-16 13:18:44 -05:00
|
|
|
void dump_block_data() const UNUSED;
|
2013-08-18 18:06:13 -07:00
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
cfg_t *cfg;
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
acp_entry **acp;
|
|
|
|
|
int num_acp;
|
2013-03-22 14:11:25 -07:00
|
|
|
int bitset_words;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
struct block_data *bd;
|
|
|
|
|
};
|
|
|
|
|
} /* anonymous namespace */
|
|
|
|
|
|
2023-10-02 10:39:09 -07:00
|
|
|
fs_copy_prop_dataflow::fs_copy_prop_dataflow(linear_ctx *lin_ctx, cfg_t *cfg,
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live,
|
2023-08-18 17:37:02 -07:00
|
|
|
struct acp *out_acp)
|
2023-10-02 10:39:09 -07:00
|
|
|
: cfg(cfg), live(live)
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
{
|
2023-10-02 10:39:09 -07:00
|
|
|
bd = linear_zalloc_array(lin_ctx, struct block_data, cfg->num_blocks);
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
num_acp = 0;
|
2023-08-18 17:37:02 -07:00
|
|
|
foreach_block (block, cfg)
|
|
|
|
|
num_acp += out_acp[block->num].length();
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2013-04-04 09:47:03 -07:00
|
|
|
bitset_words = BITSET_WORDS(num_acp);
|
2013-03-22 14:11:25 -07:00
|
|
|
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
2023-10-02 10:39:09 -07:00
|
|
|
bd[block->num].livein = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].liveout = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].copy = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].kill = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].undef = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].reachin = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].exec_mismatch = linear_zalloc_array(lin_ctx, BITSET_WORD, bitset_words);
|
|
|
|
|
}
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2023-10-02 10:39:09 -07:00
|
|
|
acp = linear_zalloc_array(lin_ctx, struct acp_entry *, num_acp);
|
|
|
|
|
|
|
|
|
|
int next_acp = 0;
|
|
|
|
|
foreach_block (block, cfg) {
|
2023-08-28 15:46:53 -07:00
|
|
|
for (auto iter = out_acp[block->num].begin();
|
|
|
|
|
iter != out_acp[block->num].end(); ++iter) {
|
|
|
|
|
acp[next_acp] = *iter;
|
2013-08-08 23:29:56 -07:00
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
(*iter)->global_idx = next_acp;
|
2019-05-05 00:13:20 -05:00
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
/* opt_copy_propagation_local populates out_acp with copies created
|
|
|
|
|
* in a block which are still live at the end of the block. This
|
|
|
|
|
* is exactly what we want in the COPY set.
|
|
|
|
|
*/
|
|
|
|
|
BITSET_SET(bd[block->num].copy, next_acp);
|
2013-08-08 23:29:56 -07:00
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
next_acp++;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
assert(next_acp == num_acp);
|
|
|
|
|
|
2013-08-09 18:07:45 -07:00
|
|
|
setup_initial_values();
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
run();
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-23 16:20:38 -07:00
|
|
|
/**
|
|
|
|
|
* Like reg_offset, but register must be VGRF or FIXED_GRF.
|
|
|
|
|
*/
|
|
|
|
|
static inline unsigned
|
|
|
|
|
grf_reg_offset(const fs_reg &r)
|
|
|
|
|
{
|
|
|
|
|
return (r.file == VGRF ? 0 : r.nr) * REG_SIZE +
|
|
|
|
|
r.offset +
|
|
|
|
|
(r.file == FIXED_GRF ? r.subnr : 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Like regions_overlap, but register must be VGRF or FIXED_GRF.
|
|
|
|
|
*/
|
|
|
|
|
static inline bool
|
|
|
|
|
grf_regions_overlap(const fs_reg &r, unsigned dr, const fs_reg &s, unsigned ds)
|
|
|
|
|
{
|
|
|
|
|
return reg_space(r) == reg_space(s) &&
|
|
|
|
|
!(grf_reg_offset(r) + dr <= grf_reg_offset(s) ||
|
|
|
|
|
grf_reg_offset(s) + ds <= grf_reg_offset(r));
|
|
|
|
|
}
|
|
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
/**
|
2013-08-09 18:07:45 -07:00
|
|
|
* Set up initial values for each of the data flow sets, prior to running
|
|
|
|
|
* the fixed-point algorithm.
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
*/
|
|
|
|
|
void
|
2013-08-09 18:07:45 -07:00
|
|
|
fs_copy_prop_dataflow::setup_initial_values()
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
{
|
2013-08-09 18:34:11 -07:00
|
|
|
/* Initialize the COPY and KILL sets. */
|
2019-05-05 00:13:20 -05:00
|
|
|
{
|
2023-08-30 13:20:35 -07:00
|
|
|
struct acp acp_table;
|
2019-05-05 00:13:20 -05:00
|
|
|
|
|
|
|
|
/* First, get all the KILLs for instructions which overwrite ACP
|
|
|
|
|
* destinations.
|
|
|
|
|
*/
|
2023-08-30 13:20:35 -07:00
|
|
|
for (int i = 0; i < num_acp; i++)
|
|
|
|
|
acp_table.add(acp[i]);
|
2019-05-05 00:13:20 -05:00
|
|
|
|
|
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
foreach_inst_in_block(fs_inst, inst, block) {
|
2023-09-13 17:52:29 -07:00
|
|
|
if (inst->dst.file != VGRF &&
|
|
|
|
|
inst->dst.file != FIXED_GRF)
|
2019-05-05 00:13:20 -05:00
|
|
|
continue;
|
|
|
|
|
|
2023-09-13 17:52:29 -07:00
|
|
|
for (auto iter = acp_table.find_by_src(inst->dst.nr);
|
|
|
|
|
iter != acp_table.end() && (*iter)->src.nr == inst->dst.nr;
|
2023-08-30 13:20:35 -07:00
|
|
|
++iter) {
|
2023-03-23 16:20:38 -07:00
|
|
|
if (grf_regions_overlap(inst->dst, inst->size_written,
|
2023-09-13 17:52:29 -07:00
|
|
|
(*iter)->src, (*iter)->size_read)) {
|
2023-08-30 13:20:35 -07:00
|
|
|
BITSET_SET(bd[block->num].kill, (*iter)->global_idx);
|
|
|
|
|
if (inst->force_writemask_all && !(*iter)->force_writemask_all)
|
|
|
|
|
BITSET_SET(bd[block->num].exec_mismatch, (*iter)->global_idx);
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
}
|
2019-05-05 00:13:20 -05:00
|
|
|
}
|
|
|
|
|
|
2023-09-13 17:52:29 -07:00
|
|
|
if (inst->dst.file != VGRF)
|
2019-05-05 00:13:20 -05:00
|
|
|
continue;
|
|
|
|
|
|
2023-09-13 17:52:29 -07:00
|
|
|
for (auto iter = acp_table.find_by_dst(inst->dst.nr);
|
|
|
|
|
iter != acp_table.end() && (*iter)->dst.nr == inst->dst.nr;
|
2023-08-30 13:20:35 -07:00
|
|
|
++iter) {
|
2023-03-23 16:20:38 -07:00
|
|
|
if (grf_regions_overlap(inst->dst, inst->size_written,
|
2023-09-13 17:52:29 -07:00
|
|
|
(*iter)->dst, (*iter)->size_written)) {
|
2023-08-30 13:20:35 -07:00
|
|
|
BITSET_SET(bd[block->num].kill, (*iter)->global_idx);
|
|
|
|
|
if (inst->force_writemask_all && !(*iter)->force_writemask_all)
|
|
|
|
|
BITSET_SET(bd[block->num].exec_mismatch, (*iter)->global_idx);
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
}
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2013-08-09 18:34:11 -07:00
|
|
|
|
|
|
|
|
/* Populate the initial values for the livein and liveout sets. For the
|
|
|
|
|
* block at the start of the program, livein = 0 and liveout = copy.
|
2017-12-18 15:22:04 -08:00
|
|
|
* For the others, set liveout and livein to ~0 (the universal set).
|
2013-08-09 18:34:11 -07:00
|
|
|
*/
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
2013-08-09 18:34:11 -07:00
|
|
|
if (block->parents.is_empty()) {
|
|
|
|
|
for (int i = 0; i < bitset_words; i++) {
|
2014-07-11 22:31:39 -07:00
|
|
|
bd[block->num].livein[i] = 0u;
|
|
|
|
|
bd[block->num].liveout[i] = bd[block->num].copy[i];
|
2013-08-09 18:34:11 -07:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
for (int i = 0; i < bitset_words; i++) {
|
2017-12-18 15:22:04 -08:00
|
|
|
bd[block->num].liveout[i] = ~0u;
|
2014-07-11 22:31:39 -07:00
|
|
|
bd[block->num].livein[i] = ~0u;
|
2013-08-09 18:34:11 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-10-23 13:47:10 -07:00
|
|
|
|
|
|
|
|
/* Initialize the undef set. */
|
|
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
for (int i = 0; i < num_acp; i++) {
|
|
|
|
|
BITSET_SET(bd[block->num].undef, i);
|
|
|
|
|
for (unsigned off = 0; off < acp[i]->size_written; off += REG_SIZE) {
|
2016-03-13 16:25:57 -07:00
|
|
|
if (BITSET_TEST(live.block_data[block->num].defout,
|
|
|
|
|
live.var_from_reg(byte_offset(acp[i]->dst, off))))
|
2017-10-23 13:47:10 -07:00
|
|
|
BITSET_CLEAR(bd[block->num].undef, i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Walk the set of instructions in the block, marking which entries in the acp
|
|
|
|
|
* are killed by the block.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
fs_copy_prop_dataflow::run()
|
|
|
|
|
{
|
2013-08-09 18:25:36 -07:00
|
|
|
bool progress;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2013-08-09 17:50:03 -07:00
|
|
|
do {
|
2013-08-09 18:25:36 -07:00
|
|
|
progress = false;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
if (block->parents.is_empty())
|
2013-08-09 18:47:19 -07:00
|
|
|
continue;
|
|
|
|
|
|
2013-03-22 14:11:25 -07:00
|
|
|
for (int i = 0; i < bitset_words; i++) {
|
2014-07-11 22:31:39 -07:00
|
|
|
const BITSET_WORD old_liveout = bd[block->num].liveout[i];
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
const BITSET_WORD old_reachin = bd[block->num].reachin[i];
|
2017-10-23 13:47:10 -07:00
|
|
|
BITSET_WORD livein_from_any_block = 0;
|
2013-08-09 18:44:25 -07:00
|
|
|
|
2017-12-18 15:22:04 -08:00
|
|
|
/* Update livein for this block. If a copy is live out of all
|
|
|
|
|
* parent blocks, it's live coming in to this block.
|
|
|
|
|
*/
|
2014-07-11 22:31:39 -07:00
|
|
|
bd[block->num].livein[i] = ~0u;
|
|
|
|
|
foreach_list_typed(bblock_link, parent_link, link, &block->parents) {
|
|
|
|
|
bblock_t *parent = parent_link->block;
|
2017-10-23 13:47:10 -07:00
|
|
|
/* Consider ACP entries with a known-undefined destination to
|
|
|
|
|
* be available from the parent. This is valid because we're
|
|
|
|
|
* free to set the undefined variable equal to the source of
|
|
|
|
|
* the ACP entry without breaking the application's
|
|
|
|
|
* expectations, since the variable is undefined.
|
|
|
|
|
*/
|
|
|
|
|
bd[block->num].livein[i] &= (bd[parent->num].liveout[i] |
|
|
|
|
|
bd[parent->num].undef[i]);
|
|
|
|
|
livein_from_any_block |= bd[parent->num].liveout[i];
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
|
|
|
|
|
/* Update reachin for this block. If the end of any
|
|
|
|
|
* parent block is reachable from the copy, the start
|
|
|
|
|
* of this block is reachable from it as well.
|
|
|
|
|
*/
|
|
|
|
|
bd[block->num].reachin[i] |= (bd[parent->num].reachin[i] |
|
|
|
|
|
bd[parent->num].copy[i]);
|
2013-03-22 14:11:25 -07:00
|
|
|
}
|
2013-08-09 18:44:25 -07:00
|
|
|
|
2017-10-23 13:47:10 -07:00
|
|
|
/* Limit to the set of ACP entries that can possibly be available
|
|
|
|
|
* at the start of the block, since propagating from a variable
|
|
|
|
|
* which is guaranteed to be undefined (rather than potentially
|
|
|
|
|
* undefined for some dynamic control-flow paths) doesn't seem
|
|
|
|
|
* particularly useful.
|
|
|
|
|
*/
|
|
|
|
|
bd[block->num].livein[i] &= livein_from_any_block;
|
|
|
|
|
|
2017-12-18 15:22:04 -08:00
|
|
|
/* Update liveout for this block. */
|
|
|
|
|
bd[block->num].liveout[i] =
|
|
|
|
|
bd[block->num].copy[i] | (bd[block->num].livein[i] &
|
|
|
|
|
~bd[block->num].kill[i]);
|
|
|
|
|
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
if (old_liveout != bd[block->num].liveout[i] ||
|
|
|
|
|
old_reachin != bd[block->num].reachin[i])
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} while (progress);
|
|
|
|
|
|
|
|
|
|
/* Perform a second fixed-point pass in order to propagate the
|
|
|
|
|
* exec_mismatch bitsets. Note that this requires an accurate
|
|
|
|
|
* value of the reachin bitsets as input, which isn't available
|
|
|
|
|
* until the end of the first propagation pass, so this loop cannot
|
|
|
|
|
* be folded into the previous one.
|
|
|
|
|
*/
|
|
|
|
|
do {
|
|
|
|
|
progress = false;
|
|
|
|
|
|
|
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
for (int i = 0; i < bitset_words; i++) {
|
|
|
|
|
const BITSET_WORD old_exec_mismatch = bd[block->num].exec_mismatch[i];
|
|
|
|
|
|
|
|
|
|
/* Update exec_mismatch for this block. If the end of a
|
|
|
|
|
* parent block is reachable by an overwrite with
|
|
|
|
|
* inconsistent execution masking, the start of this block
|
|
|
|
|
* is reachable by such an overwrite as well.
|
|
|
|
|
*/
|
|
|
|
|
foreach_list_typed(bblock_link, parent_link, link, &block->parents) {
|
|
|
|
|
bblock_t *parent = parent_link->block;
|
|
|
|
|
bd[block->num].exec_mismatch[i] |= (bd[parent->num].exec_mismatch[i] &
|
|
|
|
|
bd[parent->num].reachin[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Only consider overwrites with inconsistent execution
|
|
|
|
|
* masking if they are reachable from the copy, since
|
|
|
|
|
* overwrites unreachable from a copy are harmless to that
|
|
|
|
|
* copy.
|
|
|
|
|
*/
|
|
|
|
|
bd[block->num].exec_mismatch[i] &= bd[block->num].reachin[i];
|
|
|
|
|
if (old_exec_mismatch != bd[block->num].exec_mismatch[i])
|
2013-08-09 18:25:36 -07:00
|
|
|
progress = true;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
}
|
2013-08-09 18:25:36 -07:00
|
|
|
} while (progress);
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
2013-08-18 18:06:13 -07:00
|
|
|
void
|
|
|
|
|
fs_copy_prop_dataflow::dump_block_data() const
|
|
|
|
|
{
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
fprintf(stderr, "Block %d [%d, %d] (parents ", block->num,
|
2013-08-18 18:06:13 -07:00
|
|
|
block->start_ip, block->end_ip);
|
2014-05-12 14:40:40 -07:00
|
|
|
foreach_list_typed(bblock_link, link, link, &block->parents) {
|
|
|
|
|
bblock_t *parent = link->block;
|
2014-07-11 22:31:39 -07:00
|
|
|
fprintf(stderr, "%d ", parent->num);
|
2013-08-18 18:06:13 -07:00
|
|
|
}
|
2013-12-22 23:29:31 -08:00
|
|
|
fprintf(stderr, "):\n");
|
|
|
|
|
fprintf(stderr, " livein = 0x");
|
2013-08-18 18:06:13 -07:00
|
|
|
for (int i = 0; i < bitset_words; i++)
|
2014-07-11 22:31:39 -07:00
|
|
|
fprintf(stderr, "%08x", bd[block->num].livein[i]);
|
2013-12-22 23:29:31 -08:00
|
|
|
fprintf(stderr, ", liveout = 0x");
|
2013-08-18 18:06:13 -07:00
|
|
|
for (int i = 0; i < bitset_words; i++)
|
2014-07-11 22:31:39 -07:00
|
|
|
fprintf(stderr, "%08x", bd[block->num].liveout[i]);
|
2013-12-22 23:29:31 -08:00
|
|
|
fprintf(stderr, ",\n copy = 0x");
|
2013-08-18 18:06:13 -07:00
|
|
|
for (int i = 0; i < bitset_words; i++)
|
2014-07-11 22:31:39 -07:00
|
|
|
fprintf(stderr, "%08x", bd[block->num].copy[i]);
|
2013-12-22 23:29:31 -08:00
|
|
|
fprintf(stderr, ", kill = 0x");
|
2013-08-18 18:06:13 -07:00
|
|
|
for (int i = 0; i < bitset_words; i++)
|
2014-07-11 22:31:39 -07:00
|
|
|
fprintf(stderr, "%08x", bd[block->num].kill[i]);
|
2013-12-22 23:29:31 -08:00
|
|
|
fprintf(stderr, "\n");
|
2013-08-18 18:06:13 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-06-05 11:05:29 -07:00
|
|
|
static bool
|
|
|
|
|
is_logic_op(enum opcode opcode)
|
|
|
|
|
{
|
|
|
|
|
return (opcode == BRW_OPCODE_AND ||
|
|
|
|
|
opcode == BRW_OPCODE_OR ||
|
|
|
|
|
opcode == BRW_OPCODE_XOR ||
|
|
|
|
|
opcode == BRW_OPCODE_NOT);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-14 12:00:13 -07:00
|
|
|
static bool
|
intel/fs/copy_prop: check stride constraints with actual final type
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
2021-03-24 09:56:42 +02:00
|
|
|
can_take_stride(fs_inst *inst, brw_reg_type dst_type,
|
|
|
|
|
unsigned arg, unsigned stride,
|
2022-06-29 14:13:31 -07:00
|
|
|
const struct brw_compiler *compiler)
|
2015-08-14 12:00:13 -07:00
|
|
|
{
|
2022-06-29 14:13:31 -07:00
|
|
|
const struct intel_device_info *devinfo = compiler->devinfo;
|
|
|
|
|
|
2015-08-14 12:00:13 -07:00
|
|
|
if (stride > 4)
|
|
|
|
|
return false;
|
|
|
|
|
|
2018-12-07 14:26:23 -08:00
|
|
|
/* Bail if the channels of the source need to be aligned to the byte offset
|
|
|
|
|
* of the corresponding channel of the destination, and the provided stride
|
|
|
|
|
* would break this restriction.
|
|
|
|
|
*/
|
intel/fs/copy_prop: check stride constraints with actual final type
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
2021-03-24 09:56:42 +02:00
|
|
|
if (has_dst_aligned_region_restriction(devinfo, inst, dst_type) &&
|
2018-12-07 14:26:23 -08:00
|
|
|
!(type_sz(inst->src[arg].type) * stride ==
|
intel/fs/copy_prop: check stride constraints with actual final type
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
2021-03-24 09:56:42 +02:00
|
|
|
type_sz(dst_type) * inst->dst.stride ||
|
2018-12-07 14:26:23 -08:00
|
|
|
stride == 0))
|
|
|
|
|
return false;
|
|
|
|
|
|
2015-08-14 12:00:13 -07:00
|
|
|
/* 3-source instructions can only be Align16, which restricts what strides
|
|
|
|
|
* they can take. They can only take a stride of 1 (the usual case), or 0
|
|
|
|
|
* with a special "repctrl" bit. But the repctrl bit doesn't work for
|
|
|
|
|
* 64-bit datatypes, so if the source type is 64-bit then only a stride of
|
|
|
|
|
* 1 is allowed. From the Broadwell PRM, Volume 7 "3D Media GPGPU", page
|
|
|
|
|
* 944:
|
|
|
|
|
*
|
|
|
|
|
* This is applicable to 32b datatypes and 16b datatype. 64b datatypes
|
|
|
|
|
* cannot use the replicate control.
|
|
|
|
|
*/
|
2022-06-29 14:13:31 -07:00
|
|
|
if (inst->is_3src(compiler)) {
|
2015-08-14 12:00:13 -07:00
|
|
|
if (type_sz(inst->src[arg].type) > 4)
|
|
|
|
|
return stride == 1;
|
|
|
|
|
else
|
|
|
|
|
return stride == 1 || stride == 0;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-28 09:54:20 -07:00
|
|
|
if (inst->is_math()) {
|
|
|
|
|
/* Wa_22016140776:
|
|
|
|
|
*
|
|
|
|
|
* Scalar broadcast on HF math (packed or unpacked) must not be used.
|
|
|
|
|
* Compiler must use a mov instruction to expand the scalar value to
|
|
|
|
|
* a vector before using in a HF (packed or unpacked) math operation.
|
|
|
|
|
*
|
|
|
|
|
* Prevent copy propagating a scalar value into a math instruction.
|
|
|
|
|
*/
|
|
|
|
|
if (intel_needs_workaround(devinfo, 22016140776) &&
|
|
|
|
|
stride == 0 && inst->src[arg].type == BRW_REGISTER_TYPE_HF) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* From the Broadwell PRM, Volume 2a "Command Reference - Instructions",
|
|
|
|
|
* page 391 ("Extended Math Function"):
|
|
|
|
|
*
|
|
|
|
|
* The following restrictions apply for align1 mode: Scalar source
|
|
|
|
|
* is supported. Source and destination horizontal stride must be
|
|
|
|
|
* the same.
|
|
|
|
|
*/
|
2024-02-15 13:19:08 -08:00
|
|
|
return stride == inst->dst.stride || stride == 0;
|
2024-03-28 09:54:20 -07:00
|
|
|
}
|
2015-08-14 12:00:13 -07:00
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-28 13:03:24 +02:00
|
|
|
static bool
|
|
|
|
|
instruction_requires_packed_data(fs_inst *inst)
|
|
|
|
|
{
|
|
|
|
|
switch (inst->opcode) {
|
|
|
|
|
case FS_OPCODE_DDX_FINE:
|
|
|
|
|
case FS_OPCODE_DDX_COARSE:
|
|
|
|
|
case FS_OPCODE_DDY_FINE:
|
|
|
|
|
case FS_OPCODE_DDY_COARSE:
|
2020-10-27 00:36:53 -05:00
|
|
|
case SHADER_OPCODE_QUAD_SWIZZLE:
|
2018-05-28 13:03:24 +02:00
|
|
|
return true;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-15 09:27:36 -07:00
|
|
|
static bool
|
|
|
|
|
try_copy_propagate(const brw_compiler *compiler, fs_inst *inst,
|
|
|
|
|
acp_entry *entry, int arg,
|
2023-09-21 13:55:41 -07:00
|
|
|
const brw::simple_allocator &alloc,
|
|
|
|
|
uint8_t max_polygons)
|
2012-06-06 10:57:54 -07:00
|
|
|
{
|
2015-10-26 17:09:25 -07:00
|
|
|
if (inst->src[arg].file != VGRF)
|
2014-09-23 17:22:09 -07:00
|
|
|
return false;
|
|
|
|
|
|
2023-03-15 09:27:36 -07:00
|
|
|
const struct intel_device_info *devinfo = compiler->devinfo;
|
|
|
|
|
|
2015-10-26 17:09:25 -07:00
|
|
|
assert(entry->src.file == VGRF || entry->src.file == UNIFORM ||
|
2019-12-30 00:38:08 -08:00
|
|
|
entry->src.file == ATTR || entry->src.file == FIXED_GRF);
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2019-12-30 00:37:35 -08:00
|
|
|
/* Avoid propagating a LOAD_PAYLOAD instruction into another if there is a
|
|
|
|
|
* good chance that we'll be able to eliminate the latter through register
|
|
|
|
|
* coalescing. If only part of the sources of the second LOAD_PAYLOAD can
|
|
|
|
|
* be simplified through copy propagation we would be making register
|
|
|
|
|
* coalescing impossible, ending up with unnecessary copies in the program.
|
|
|
|
|
* This is also the case for is_multi_copy_payload() copies that can only
|
|
|
|
|
* be coalesced when the instruction is lowered into a sequence of MOVs.
|
|
|
|
|
*
|
|
|
|
|
* Worse -- In cases where the ACP entry was the result of CSE combining
|
|
|
|
|
* multiple LOAD_PAYLOAD subexpressions, propagating the first LOAD_PAYLOAD
|
|
|
|
|
* into the second would undo the work of CSE, leading to an infinite
|
|
|
|
|
* optimization loop. Avoid this by detecting LOAD_PAYLOAD copies from CSE
|
|
|
|
|
* temporaries which should match is_coalescing_payload().
|
|
|
|
|
*/
|
2014-04-17 15:13:00 -07:00
|
|
|
if (entry->opcode == SHADER_OPCODE_LOAD_PAYLOAD &&
|
2019-12-30 00:37:35 -08:00
|
|
|
(is_coalescing_payload(alloc, inst) || is_multi_copy_payload(inst)))
|
2014-04-17 15:13:00 -07:00
|
|
|
return false;
|
|
|
|
|
|
2015-10-26 17:09:25 -07:00
|
|
|
assert(entry->dst.file == VGRF);
|
2015-10-26 04:35:14 -07:00
|
|
|
if (inst->src[arg].nr != entry->dst.nr)
|
i965/fs: Convert gen7 to using GRFs for texture messages.
Looking at Lightsmark's shaders, the way we used MRFs (or in gen7's
case, GRFs) was bad in a couple of ways. One was that it prevented
compute-to-MRF for the common case of a texcoord that gets used
exactly once, but where the texcoord setup all gets emitted before the
texture calls (such as when it's a bare fragment shader input, which
gets interpolated before processing main()). Another was that it
introduced a bunch of dependencies that constrained scheduling, and
forced waits for texture operations to be done before they are
required. For example, we can now move the compute-to-MRF
interpolation for the second texture send down after the first send.
The downside is that this generally prevents
remove_duplicate_mrf_writes() from doing anything, whereas previously
it avoided work for the case of sampling from the same texcoord twice.
However, I suspect that most of the win that originally justified that
code was in avoiding the WAR stall on the first send, which this patch
also avoids, rather than the small cost of the extra instruction. We
see instruction count regressions in shaders in unigine, yofrankie,
savage2, hon, and gstreamer.
Improves GLB2.7 performance by 0.633628% +/- 0.491809% (n=121/125, avg of
~66fps, outliers below 61 dropped).
Improves openarena performance by 1.01092% +/- 0.66897% (n=425).
No significant difference on Lightsmark (n=44).
v2: Squash in the fix for register unspilling for send-from-GRF, fixing a
segfault in lightsmark.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Matt Turner <mattst88@gmail.com>
2013-10-09 17:17:59 -07:00
|
|
|
return false;
|
|
|
|
|
|
2014-09-23 17:22:09 -07:00
|
|
|
/* Bail if inst is reading a range that isn't contained in the range
|
|
|
|
|
* that entry is writing.
|
|
|
|
|
*/
|
2016-09-01 19:47:56 -07:00
|
|
|
if (!region_contained_in(inst->src[arg], inst->size_read(arg),
|
|
|
|
|
entry->dst, entry->size_written))
|
2012-06-06 10:57:54 -07:00
|
|
|
return false;
|
|
|
|
|
|
2022-07-06 20:29:02 -07:00
|
|
|
/* Send messages with EOT set are restricted to use g112-g127 (and we
|
|
|
|
|
* sometimes need g127 for other purposes), so avoid copy propagating
|
|
|
|
|
* anything that would make it impossible to satisfy that restriction.
|
2019-12-30 00:38:08 -08:00
|
|
|
*/
|
2022-07-06 20:29:02 -07:00
|
|
|
if (inst->eot) {
|
2024-01-03 02:58:54 -08:00
|
|
|
/* Don't propagate things that are already pinned. */
|
|
|
|
|
if (entry->src.file != VGRF)
|
2022-07-06 20:29:02 -07:00
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
/* We might be propagating from a large register, while the SEND only
|
|
|
|
|
* is reading a portion of it (say the .A channel in an RGBA value).
|
|
|
|
|
* We need to pin both split SEND sources in g112-g126/127, so only
|
|
|
|
|
* allow this if the registers aren't too large.
|
|
|
|
|
*/
|
2024-01-08 20:58:20 -08:00
|
|
|
if (inst->opcode == SHADER_OPCODE_SEND && inst->sources >= 4 &&
|
|
|
|
|
entry->src.file == VGRF) {
|
2022-07-06 20:29:02 -07:00
|
|
|
int other_src = arg == 2 ? 3 : 2;
|
|
|
|
|
unsigned other_size = inst->src[other_src].file == VGRF ?
|
|
|
|
|
alloc.sizes[inst->src[other_src].nr] :
|
|
|
|
|
inst->size_read(other_src);
|
|
|
|
|
unsigned prop_src_size = alloc.sizes[entry->src.nr];
|
|
|
|
|
if (other_size + prop_src_size > 15)
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-12-30 00:38:08 -08:00
|
|
|
|
2015-01-19 12:32:09 +01:00
|
|
|
/* we can't generally copy-propagate UD negations because we
|
|
|
|
|
* can end up accessing the resulting values as signed integers
|
|
|
|
|
* instead. See also resolve_ud_negate() and comment in
|
|
|
|
|
* fs_generator::generate_code.
|
|
|
|
|
*/
|
2015-04-03 12:15:48 -07:00
|
|
|
if (entry->src.type == BRW_REGISTER_TYPE_UD &&
|
2012-06-06 11:06:51 -07:00
|
|
|
entry->src.negate)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
bool has_source_modifiers = entry->src.abs || entry->src.negate;
|
|
|
|
|
|
2020-12-06 16:26:04 -08:00
|
|
|
if (has_source_modifiers && !inst->can_do_source_mods(devinfo))
|
2013-12-08 04:57:35 +01:00
|
|
|
return false;
|
|
|
|
|
|
2020-12-06 16:26:04 -08:00
|
|
|
/* Reject cases that would violate register regioning restrictions. */
|
|
|
|
|
if ((entry->src.file == UNIFORM || !entry->src.is_contiguous()) &&
|
2024-02-15 13:19:08 -08:00
|
|
|
(inst->is_send_from_grf() ||
|
2020-12-06 16:26:04 -08:00
|
|
|
inst->uses_indirect_addressing())) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-28 13:03:24 +02:00
|
|
|
/* Some instructions implemented in the generator backend, such as
|
|
|
|
|
* derivatives, assume that their operands are packed so we can't
|
|
|
|
|
* generally propagate strided regions to them.
|
|
|
|
|
*/
|
2019-12-30 00:38:08 -08:00
|
|
|
const unsigned entry_stride = (entry->src.file == FIXED_GRF ? 1 :
|
|
|
|
|
entry->src.stride);
|
2020-09-02 10:13:16 -05:00
|
|
|
if (instruction_requires_packed_data(inst) && entry_stride != 1)
|
2018-05-28 13:03:24 +02:00
|
|
|
return false;
|
|
|
|
|
|
intel/fs/copy_prop: check stride constraints with actual final type
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
2021-03-24 09:56:42 +02:00
|
|
|
const brw_reg_type dst_type = (has_source_modifiers &&
|
|
|
|
|
entry->dst.type != inst->src[arg].type) ?
|
|
|
|
|
entry->dst.type : inst->dst.type;
|
|
|
|
|
|
2013-12-08 04:57:35 +01:00
|
|
|
/* Bail if the result of composing both strides would exceed the
|
|
|
|
|
* hardware limit.
|
|
|
|
|
*/
|
intel/fs/copy_prop: check stride constraints with actual final type
In some cases we will change the type of the destination register of
an instruction. This is the type we should use to verify that we're
allow to do the replacement.
Otherwise we can hit restrictions on CHV and upcoming Xe-Hp for
instance where the copy propagation transforms this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(16) vgrf11:UW, vgrf10<2>:UW
mov(16) vgrf12:UW, vgrf10+0.2<2>:UW
mov(16) vgrf15:HF, |vgrf11|:HF
mov(16) vgrf16:HF, |vgrf12|:HF
mov(8) vgrf41<2>:UW, vgrf15+0.0:UW group0
mov(8) vgrf42<2>:UW, vgrf15+0.16:UW group8
mov(8) vgrf45<2>:UW, vgrf16+0.0:UW group0
mov(8) vgrf46<2>:UW, vgrf16+0.16:UW group8
into this :
send(16) (mlen: 2) vgrf10:UD, 0u, 0u, vgrf35:D, null:UD
mov(8) vgrf41<2>:HF, |vgrf10+0.0|<2>:HF group0
mov(8) vgrf42<2>:HF, |vgrf10+1.0|<2>:HF group8
mov(8) vgrf45<2>:HF, |vgrf10+0.2|<2>:HF group0
mov(8) vgrf46<2>:HF, |vgrf10+1.2|<2>:HF group8
Because of the floating point use, stride and offets should be the
same.
v2: Fix final destination type selection (Curro)
v3: constify (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9832>
2021-03-24 09:56:42 +02:00
|
|
|
if (!can_take_stride(inst, dst_type, arg,
|
|
|
|
|
entry_stride * inst->src[arg].stride,
|
2022-06-29 14:13:31 -07:00
|
|
|
compiler))
|
2013-12-08 04:57:35 +01:00
|
|
|
return false;
|
|
|
|
|
|
2021-03-23 16:37:40 +02:00
|
|
|
/* From the Cherry Trail/Braswell PRMs, Volume 7: 3D Media GPGPU:
|
|
|
|
|
* EU Overview
|
|
|
|
|
* Register Region Restrictions
|
|
|
|
|
* Special Requirements for Handling Double Precision Data Types :
|
|
|
|
|
*
|
|
|
|
|
* "When source or destination datatype is 64b or operation is integer
|
|
|
|
|
* DWord multiply, regioning in Align1 must follow these rules:
|
|
|
|
|
*
|
|
|
|
|
* 1. Source and Destination horizontal stride must be aligned to the
|
|
|
|
|
* same qword.
|
|
|
|
|
* 2. Regioning must ensure Src.Vstride = Src.Width * Src.Hstride.
|
|
|
|
|
* 3. Source and Destination offset must be the same, except the case
|
|
|
|
|
* of scalar source."
|
|
|
|
|
*
|
|
|
|
|
* Most of this is already checked in can_take_stride(), we're only left
|
|
|
|
|
* with checking 3.
|
|
|
|
|
*/
|
|
|
|
|
if (has_dst_aligned_region_restriction(devinfo, inst, dst_type) &&
|
|
|
|
|
entry_stride != 0 &&
|
2024-02-15 20:23:18 +01:00
|
|
|
(reg_offset(inst->dst) % (REG_SIZE * reg_unit(devinfo))) != (reg_offset(entry->src) % (REG_SIZE * reg_unit(devinfo))))
|
2021-03-23 16:37:40 +02:00
|
|
|
return false;
|
|
|
|
|
|
2024-04-10 15:23:45 -07:00
|
|
|
/*
|
|
|
|
|
* Bail if the composition of both regions would be affected by the Xe2+
|
|
|
|
|
* regioning restrictions that apply to integer types smaller than a dword.
|
|
|
|
|
* See BSpec #56640 for details.
|
|
|
|
|
*/
|
|
|
|
|
const fs_reg tmp = horiz_stride(entry->src, inst->src[arg].stride);
|
|
|
|
|
if (has_subdword_integer_region_restriction(devinfo, inst, &tmp, 1))
|
|
|
|
|
return false;
|
|
|
|
|
|
2022-06-22 16:35:59 -07:00
|
|
|
/* The <8;8,0> regions used for FS attributes in multipolygon
|
|
|
|
|
* dispatch mode could violate regioning restrictions, don't copy
|
|
|
|
|
* propagate them in such cases.
|
|
|
|
|
*/
|
|
|
|
|
if (entry->src.file == ATTR && max_polygons > 1 &&
|
|
|
|
|
(has_dst_aligned_region_restriction(devinfo, inst, dst_type) ||
|
|
|
|
|
instruction_requires_packed_data(inst) ||
|
|
|
|
|
(inst->is_3src(compiler) && arg == 2) ||
|
|
|
|
|
entry->dst.type != inst->src[arg].type))
|
|
|
|
|
return false;
|
|
|
|
|
|
2019-12-30 00:38:08 -08:00
|
|
|
/* Bail if the source FIXED_GRF region of the copy cannot be trivially
|
|
|
|
|
* composed with the source region of the instruction -- E.g. because the
|
|
|
|
|
* copy uses some extended stride greater than 4 not supported natively by
|
|
|
|
|
* the hardware as a horizontal stride, or because instruction compression
|
|
|
|
|
* could require us to use a vertical stride shorter than a GRF.
|
|
|
|
|
*/
|
|
|
|
|
if (entry->src.file == FIXED_GRF &&
|
|
|
|
|
(inst->src[arg].stride > 4 ||
|
|
|
|
|
inst->dst.component_size(inst->exec_size) >
|
|
|
|
|
inst->src[arg].component_size(inst->exec_size)))
|
|
|
|
|
return false;
|
|
|
|
|
|
2015-07-13 15:40:18 +03:00
|
|
|
/* Bail if the instruction type is larger than the execution type of the
|
|
|
|
|
* copy, what implies that each channel is reading multiple channels of the
|
|
|
|
|
* destination of the copy, and simply replacing the sources would give a
|
|
|
|
|
* program with different semantics.
|
|
|
|
|
*/
|
intel/fs: Allow copy propagation between MOVs of mixed sizes
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
Unfortunately, this doesn't clean everything up. Here's a subset of the
"before" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
mov(8) g12<1>UB g7<32,8,4>UB { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g12<8,8,1>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g14<1>UB g8<32,8,4>UB { align1 1Q };
mov(8) g16<1>UW g14<8,8,1>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
And here's the same subset of the "after" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g7<32,8,4>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g16<1>UW g8<32,8,4>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
There are a lot of regioning and type restrictions in
fs_visitor::try_copy_propagate, and I'm a little nervious about messing
with them too much.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
2021-04-13 14:07:19 -07:00
|
|
|
if ((type_sz(entry->dst.type) < type_sz(inst->src[arg].type) ||
|
|
|
|
|
entry->is_partial_write) &&
|
|
|
|
|
inst->opcode != BRW_OPCODE_MOV) {
|
2015-07-13 15:40:18 +03:00
|
|
|
return false;
|
intel/fs: Allow copy propagation between MOVs of mixed sizes
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
Unfortunately, this doesn't clean everything up. Here's a subset of the
"before" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
mov(8) g12<1>UB g7<32,8,4>UB { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g12<8,8,1>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g14<1>UB g8<32,8,4>UB { align1 1Q };
mov(8) g16<1>UW g14<8,8,1>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
And here's the same subset of the "after" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g7<32,8,4>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g16<1>UW g8<32,8,4>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
There are a lot of regioning and type restrictions in
fs_visitor::try_copy_propagate, and I'm a little nervious about messing
with them too much.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
2021-04-13 14:07:19 -07:00
|
|
|
}
|
2015-07-13 15:40:18 +03:00
|
|
|
|
2013-12-08 04:57:35 +01:00
|
|
|
/* Bail if the result of composing both strides cannot be expressed
|
|
|
|
|
* as another stride. This avoids, for example, trying to transform
|
|
|
|
|
* this:
|
|
|
|
|
*
|
|
|
|
|
* MOV (8) rX<1>UD rY<0;1,0>UD
|
|
|
|
|
* FOO (8) ... rX<8;8,1>UW
|
|
|
|
|
*
|
|
|
|
|
* into this:
|
|
|
|
|
*
|
|
|
|
|
* FOO (8) ... rY<0;1,0>UW
|
|
|
|
|
*
|
|
|
|
|
* Which would have different semantics.
|
|
|
|
|
*/
|
2019-12-30 00:38:08 -08:00
|
|
|
if (entry_stride != 1 &&
|
2013-12-08 04:57:35 +01:00
|
|
|
(inst->src[arg].stride *
|
|
|
|
|
type_sz(inst->src[arg].type)) % type_sz(entry->src.type) != 0)
|
2012-06-06 11:06:51 -07:00
|
|
|
return false;
|
|
|
|
|
|
i965/fs: disallow type change in copy-propagation if types have different sizes
Because the semantics of source modifiers are type-dependent, the type of the
original source of the copy must be kept unmodified while propagating it into
some instruction, which implies that we need to have the guarantee that the
meaning of the instruction is going to remain the same after we have changed
the types. Whenthe size of the new type is different from the size of the old
type the new and old instructions cannot possibly be equivalent because the new
instruction will be reading more data than the old one was.
Prevents that we turn this:
load_payload(8) vgrf17:DF, |vgrf4+0.0|:DF 1sthalf
mov(8) vgrf18:DF, vgrf17:DF 1sthalf
load_payload(8) vgrf5:DF, vgrf18:DF, vgrf20:DF NoMask 1sthalf WE_all
load_payload(8) vgrf21:UD, vgrf5+0.4<2>:UD 1sthalf
mov(8) vgrf22:UD, vgrf21:UD 1sthalf
into:
load_payload(8) vgrf17:DF, |vgrf4+0.0|:DF 1sthalf
mov(8) vgrf18:DF, |vgrf4+0.0|:DF 1sthalf
load_payload(8) vgrf5:DF, |vgrf4+0.0|:DF, |vgrf4+2.0|:DF NoMask 1sthalf WE_all
load_payload(8) vgrf21:UD, vgrf5+0.4<2>:UD 1sthalf
mov(8) vgrf22:DF, |vgrf4+0.4|<2>:DF 1sthalf
where the semantics of the last instruccion have changed.
v2 (Curro):
- Update commit log and add comment to explain the problem better.
- Simplify the condition.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2016-03-23 12:02:21 +01:00
|
|
|
/* Since semantics of source modifiers are type-dependent we need to
|
|
|
|
|
* ensure that the meaning of the instruction remains the same if we
|
|
|
|
|
* change the type. If the sizes of the types are different the new
|
|
|
|
|
* instruction will read a different amount of data than the original
|
|
|
|
|
* and the semantics will always be different.
|
|
|
|
|
*/
|
2015-04-03 11:07:47 -07:00
|
|
|
if (has_source_modifiers &&
|
|
|
|
|
entry->dst.type != inst->src[arg].type &&
|
i965/fs: disallow type change in copy-propagation if types have different sizes
Because the semantics of source modifiers are type-dependent, the type of the
original source of the copy must be kept unmodified while propagating it into
some instruction, which implies that we need to have the guarantee that the
meaning of the instruction is going to remain the same after we have changed
the types. Whenthe size of the new type is different from the size of the old
type the new and old instructions cannot possibly be equivalent because the new
instruction will be reading more data than the old one was.
Prevents that we turn this:
load_payload(8) vgrf17:DF, |vgrf4+0.0|:DF 1sthalf
mov(8) vgrf18:DF, vgrf17:DF 1sthalf
load_payload(8) vgrf5:DF, vgrf18:DF, vgrf20:DF NoMask 1sthalf WE_all
load_payload(8) vgrf21:UD, vgrf5+0.4<2>:UD 1sthalf
mov(8) vgrf22:UD, vgrf21:UD 1sthalf
into:
load_payload(8) vgrf17:DF, |vgrf4+0.0|:DF 1sthalf
mov(8) vgrf18:DF, |vgrf4+0.0|:DF 1sthalf
load_payload(8) vgrf5:DF, |vgrf4+0.0|:DF, |vgrf4+2.0|:DF NoMask 1sthalf WE_all
load_payload(8) vgrf21:UD, vgrf5+0.4<2>:UD 1sthalf
mov(8) vgrf22:DF, |vgrf4+0.4|<2>:DF 1sthalf
where the semantics of the last instruccion have changed.
v2 (Curro):
- Update commit log and add comment to explain the problem better.
- Simplify the condition.
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
2016-03-23 12:02:21 +01:00
|
|
|
(!inst->can_change_types() ||
|
|
|
|
|
type_sz(entry->dst.type) != type_sz(inst->src[arg].type)))
|
2013-08-08 16:41:48 -07:00
|
|
|
return false;
|
|
|
|
|
|
2024-02-15 13:19:08 -08:00
|
|
|
if ((entry->src.negate || entry->src.abs) &&
|
2014-07-15 21:27:08 -07:00
|
|
|
is_logic_op(inst->opcode)) {
|
|
|
|
|
return false;
|
2014-06-05 11:05:29 -07:00
|
|
|
}
|
|
|
|
|
|
2019-12-30 00:38:08 -08:00
|
|
|
/* Save the offset of inst->src[arg] relative to entry->dst for it to be
|
|
|
|
|
* applied later.
|
|
|
|
|
*/
|
|
|
|
|
const unsigned rel_offset = inst->src[arg].offset - entry->dst.offset;
|
|
|
|
|
|
|
|
|
|
/* Fold the copy into the instruction consuming it. */
|
2012-06-07 08:48:50 -07:00
|
|
|
inst->src[arg].file = entry->src.file;
|
2015-10-26 04:35:14 -07:00
|
|
|
inst->src[arg].nr = entry->src.nr;
|
2019-12-30 00:38:08 -08:00
|
|
|
inst->src[arg].subnr = entry->src.subnr;
|
|
|
|
|
inst->src[arg].offset = entry->src.offset;
|
|
|
|
|
|
|
|
|
|
/* Compose the strides of both regions. */
|
|
|
|
|
if (entry->src.file == FIXED_GRF) {
|
|
|
|
|
if (inst->src[arg].stride) {
|
|
|
|
|
const unsigned orig_width = 1 << entry->src.width;
|
|
|
|
|
const unsigned reg_width = REG_SIZE / (type_sz(inst->src[arg].type) *
|
|
|
|
|
inst->src[arg].stride);
|
|
|
|
|
inst->src[arg].width = cvt(MIN2(orig_width, reg_width)) - 1;
|
|
|
|
|
inst->src[arg].hstride = cvt(inst->src[arg].stride);
|
|
|
|
|
inst->src[arg].vstride = inst->src[arg].hstride + inst->src[arg].width;
|
|
|
|
|
} else {
|
|
|
|
|
inst->src[arg].vstride = inst->src[arg].hstride =
|
|
|
|
|
inst->src[arg].width = 0;
|
|
|
|
|
}
|
2012-06-06 10:57:54 -07:00
|
|
|
|
2019-12-30 00:38:08 -08:00
|
|
|
inst->src[arg].stride = 1;
|
|
|
|
|
|
|
|
|
|
/* Hopefully no Align16 around here... */
|
|
|
|
|
assert(entry->src.swizzle == BRW_SWIZZLE_XYZW);
|
|
|
|
|
inst->src[arg].swizzle = entry->src.swizzle;
|
|
|
|
|
} else {
|
|
|
|
|
inst->src[arg].stride *= entry->src.stride;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-10 16:03:36 -07:00
|
|
|
/* Compute the first component of the copy that the instruction is
|
|
|
|
|
* reading, and the base byte offset within that component.
|
|
|
|
|
*/
|
intel/brw: Fix destination stride assertion in copy propagation
We were asserting that entry->dst.offset % REG_SIZE == 0, which is
easily tripped by a simple LOAD_PAYLOAD that writes a 16-bit vec2:
load_payload(8) vgrf1:UW, vgrf2+0.0:UW, vgrf3+0.0:UW
We create separate ACP entries corresponding to the values coming from
vgrf2 and vgrf3, with entry->dst set to the location within vgrf1 where
those sources get written to. So the second entry will have offset 16,
which is not REG_SIZE aligned.
It looks like this assert was originally added back in 2014 (see commit
1728e74957a62b1b4b9fbb62a7de2c12b77c8a75) and adjusted through the ages,
including at a point when we combined reg and subreg offsets into a
single byte offset, and over time also extended copy propagation.
Here the destination offset is already accounted for via rel_offset,
at the byte offset level, so things ought to work and there is no need
to assert that this is the case. Ian had already noted that the assert
tripped in commit e3f502e0074cc0b9d5a6807fa900b240cf7e0fc6, but checking
for inst->opcode == MOV here doesn't really make sense - it's just the
case that he found that broke.
Remove the erroneous assertion.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28067>
2024-03-07 14:57:10 -08:00
|
|
|
assert(entry->dst.stride == 1);
|
2016-05-10 16:03:36 -07:00
|
|
|
const unsigned component = rel_offset / type_sz(entry->dst.type);
|
|
|
|
|
const unsigned suboffset = rel_offset % type_sz(entry->dst.type);
|
|
|
|
|
|
|
|
|
|
/* Calculate the byte offset at the origin of the copy of the given
|
|
|
|
|
* component and suboffset.
|
|
|
|
|
*/
|
2019-12-30 00:38:08 -08:00
|
|
|
inst->src[arg] = byte_offset(inst->src[arg],
|
|
|
|
|
component * entry_stride * type_sz(entry->src.type) + suboffset);
|
2014-09-23 17:22:09 -07:00
|
|
|
|
2015-04-03 11:07:47 -07:00
|
|
|
if (has_source_modifiers) {
|
|
|
|
|
if (entry->dst.type != inst->src[arg].type) {
|
|
|
|
|
/* We are propagating source modifiers from a MOV with a different
|
|
|
|
|
* type. If we got here, then we can just change the source and
|
|
|
|
|
* destination types of the instruction and keep going.
|
|
|
|
|
*/
|
|
|
|
|
for (int i = 0; i < inst->sources; i++) {
|
|
|
|
|
inst->src[i].type = entry->dst.type;
|
|
|
|
|
}
|
|
|
|
|
inst->dst.type = entry->dst.type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!inst->src[arg].abs) {
|
|
|
|
|
inst->src[arg].abs = entry->src.abs;
|
|
|
|
|
inst->src[arg].negate ^= entry->src.negate;
|
|
|
|
|
}
|
2012-06-06 11:06:51 -07:00
|
|
|
}
|
|
|
|
|
|
2012-06-06 10:57:54 -07:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 09:27:36 -07:00
|
|
|
static bool
|
|
|
|
|
try_constant_propagate(const brw_compiler *compiler, fs_inst *inst,
|
2023-03-15 12:01:35 -07:00
|
|
|
acp_entry *entry, int arg)
|
2012-09-21 13:11:54 +02:00
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
|
2015-08-03 14:53:05 -07:00
|
|
|
if (type_sz(entry->src.type) > 4)
|
|
|
|
|
return false;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
if (inst->src[arg].file != VGRF)
|
|
|
|
|
return false;
|
2014-09-23 17:22:09 -07:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
assert(entry->dst.file == VGRF);
|
|
|
|
|
if (inst->src[arg].nr != entry->dst.nr)
|
|
|
|
|
return false;
|
2014-09-23 17:22:09 -07:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
/* Bail if inst is reading a range that isn't contained in the range
|
|
|
|
|
* that entry is writing.
|
|
|
|
|
*/
|
|
|
|
|
if (!region_contained_in(inst->src[arg], inst->size_read(arg),
|
|
|
|
|
entry->dst, entry->size_written))
|
|
|
|
|
return false;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
/* If the size of the use type is larger than the size of the entry
|
|
|
|
|
* type, the entry doesn't contain all of the data that the user is
|
|
|
|
|
* trying to use.
|
|
|
|
|
*/
|
|
|
|
|
if (type_sz(inst->src[arg].type) > type_sz(entry->dst.type))
|
|
|
|
|
return false;
|
2016-05-19 21:32:14 -07:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
fs_reg val = entry->src;
|
2022-02-03 10:45:58 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
/* If the size of the use type is smaller than the size of the entry,
|
|
|
|
|
* clamp the value to the range of the use type. This enables constant
|
|
|
|
|
* copy propagation in cases like
|
|
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* mov(8) g12<1>UD 0x0000000cUD
|
|
|
|
|
* ...
|
|
|
|
|
* mul(8) g47<1>D g86<8,8,1>D g12<16,8,2>W
|
|
|
|
|
*/
|
|
|
|
|
if (type_sz(inst->src[arg].type) < type_sz(entry->dst.type)) {
|
|
|
|
|
if (type_sz(inst->src[arg].type) != 2 || type_sz(entry->dst.type) != 4)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
assert(inst->src[arg].subnr == 0 || inst->src[arg].subnr == 2);
|
|
|
|
|
|
|
|
|
|
/* When subnr is 0, we want the lower 16-bits, and when it's 2, we
|
|
|
|
|
* want the upper 16-bits. No other values of subnr are valid for a
|
|
|
|
|
* UD source.
|
2022-02-03 10:45:58 -08:00
|
|
|
*/
|
2023-03-15 12:01:35 -07:00
|
|
|
const uint16_t v = inst->src[arg].subnr == 2 ? val.ud >> 16 : val.ud;
|
2022-02-03 10:45:58 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
val.ud = v | (uint32_t(v) << 16);
|
|
|
|
|
}
|
2022-02-03 10:45:58 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
val.type = inst->src[arg].type;
|
2022-02-03 10:45:58 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
if (inst->src[arg].abs) {
|
2024-02-15 13:19:08 -08:00
|
|
|
if (is_logic_op(inst->opcode) ||
|
2024-02-28 22:10:17 -08:00
|
|
|
!fs_reg_abs_immediate(&val)) {
|
2023-03-15 12:01:35 -07:00
|
|
|
return false;
|
2022-02-03 10:45:58 -08:00
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
}
|
2022-02-03 10:45:58 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
if (inst->src[arg].negate) {
|
2024-02-15 13:19:08 -08:00
|
|
|
if (is_logic_op(inst->opcode) ||
|
2024-02-28 22:10:17 -08:00
|
|
|
!fs_reg_negate_immediate(&val)) {
|
2023-03-15 12:01:35 -07:00
|
|
|
return false;
|
2015-01-28 18:37:32 -08:00
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
}
|
2015-01-28 18:37:32 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
switch (inst->opcode) {
|
|
|
|
|
case BRW_OPCODE_MOV:
|
|
|
|
|
case SHADER_OPCODE_LOAD_PAYLOAD:
|
2020-08-04 17:34:21 -07:00
|
|
|
case SHADER_OPCODE_POW:
|
2023-03-15 12:01:35 -07:00
|
|
|
case FS_OPCODE_PACK:
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case BRW_OPCODE_SUBB:
|
|
|
|
|
if (arg == 1) {
|
|
|
|
|
inst->src[arg] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
2023-03-15 12:01:35 -07:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case BRW_OPCODE_MACH:
|
|
|
|
|
case BRW_OPCODE_MUL:
|
|
|
|
|
case SHADER_OPCODE_MULH:
|
|
|
|
|
case BRW_OPCODE_ADD:
|
|
|
|
|
case BRW_OPCODE_XOR:
|
|
|
|
|
case BRW_OPCODE_ADDC:
|
|
|
|
|
if (arg == 1) {
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
} else if (arg == 0 && inst->src[1].file != IMM) {
|
2024-01-16 17:25:39 -08:00
|
|
|
/* We used to not copy propagate the constant in situations like
|
2023-03-15 12:01:35 -07:00
|
|
|
*
|
|
|
|
|
* mov(8) g8<1>D 0x7fffffffD
|
|
|
|
|
* mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
|
|
|
|
|
*
|
2024-01-16 17:25:39 -08:00
|
|
|
* On platforms that only have a 32x16 multiplier, this would
|
2023-03-15 12:01:35 -07:00
|
|
|
* result in lowering the multiply to
|
|
|
|
|
*
|
|
|
|
|
* mul(8) g15<1>D g14<8,8,1>D 0xffffUW
|
|
|
|
|
* mul(8) g16<1>D g14<8,8,1>D 0x7fffUW
|
|
|
|
|
* add(8) g15.1<2>UW g15.1<16,8,2>UW g16<16,8,2>UW
|
|
|
|
|
*
|
|
|
|
|
* On Gfx8 and Gfx9, which have the full 32x32 multiplier, it
|
2024-01-16 17:25:39 -08:00
|
|
|
* would results in
|
2023-03-15 12:01:35 -07:00
|
|
|
*
|
|
|
|
|
* mul(8) g16<1>D g15<16,8,2>W 0x7fffffffD
|
|
|
|
|
*
|
|
|
|
|
* Volume 2a of the Skylake PRM says:
|
|
|
|
|
*
|
|
|
|
|
* When multiplying a DW and any lower precision integer, the
|
|
|
|
|
* DW operand must on src0.
|
2024-01-16 17:25:39 -08:00
|
|
|
*
|
|
|
|
|
* So it would have been invalid. However, brw_fs_combine_constants
|
|
|
|
|
* will now "fix" the constant.
|
2023-03-15 12:01:35 -07:00
|
|
|
*/
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_MUL &&
|
|
|
|
|
type_sz(inst->src[1].type) < 4 &&
|
2024-01-16 17:25:39 -08:00
|
|
|
(inst->src[0].type == BRW_REGISTER_TYPE_D ||
|
|
|
|
|
inst->src[0].type == BRW_REGISTER_TYPE_UD)) {
|
|
|
|
|
inst->src[0] = val;
|
|
|
|
|
inst->src[0].type = BRW_REGISTER_TYPE_D;
|
|
|
|
|
progress = true;
|
2023-03-15 12:01:35 -07:00
|
|
|
break;
|
2024-01-16 17:25:39 -08:00
|
|
|
}
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
/* Fit this constant in by commuting the operands.
|
|
|
|
|
* Exception: we can't do this for 32-bit integer MUL/MACH
|
|
|
|
|
* because it's asymmetric.
|
|
|
|
|
*
|
|
|
|
|
* The BSpec says for Broadwell that
|
|
|
|
|
*
|
|
|
|
|
* "When multiplying DW x DW, the dst cannot be accumulator."
|
|
|
|
|
*
|
|
|
|
|
* Integer MUL with a non-accumulator destination will be lowered
|
|
|
|
|
* by lower_integer_multiplication(), so don't restrict it.
|
2015-03-16 17:53:34 -07:00
|
|
|
*/
|
2023-03-15 12:01:35 -07:00
|
|
|
if (((inst->opcode == BRW_OPCODE_MUL &&
|
|
|
|
|
inst->dst.is_accumulator()) ||
|
|
|
|
|
inst->opcode == BRW_OPCODE_MACH) &&
|
|
|
|
|
(inst->src[1].type == BRW_REGISTER_TYPE_D ||
|
|
|
|
|
inst->src[1].type == BRW_REGISTER_TYPE_UD))
|
2016-06-03 12:32:15 -07:00
|
|
|
break;
|
2023-03-15 12:01:35 -07:00
|
|
|
inst->src[0] = inst->src[1];
|
|
|
|
|
inst->src[1] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
2020-11-12 14:50:23 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
case BRW_OPCODE_ADD3:
|
|
|
|
|
/* add3 can have a single imm16 source. Proceed if the source type is
|
|
|
|
|
* already W or UW or the value can be coerced to one of those types.
|
|
|
|
|
*/
|
|
|
|
|
if (val.type == BRW_REGISTER_TYPE_W || val.type == BRW_REGISTER_TYPE_UW)
|
|
|
|
|
; /* Nothing to do. */
|
|
|
|
|
else if (val.ud <= 0xffff)
|
|
|
|
|
val = brw_imm_uw(val.ud);
|
|
|
|
|
else if (val.d >= -0x8000 && val.d <= 0x7fff)
|
|
|
|
|
val = brw_imm_w(val.d);
|
|
|
|
|
else
|
2013-08-05 15:17:04 -07:00
|
|
|
break;
|
|
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
if (arg == 2) {
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
} else if (inst->src[2].file != IMM) {
|
|
|
|
|
inst->src[arg] = inst->src[2];
|
|
|
|
|
inst->src[2] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
intel/fs: Constant fold SHL
This is a modified version of a commit originally in !7698. This version
add the changes to brw_fs_copy_propagation. If the address passed to
fs_visitor::swizzle_nir_scratch_addr is a constant, that function will
generate SHL with two constant sources.
DG2 uses a different path to generate those addresses, so the constant
folding can't occur there yet. That will be addressed in the next
commit.
What follows is the commit change history from that older MR.
v2: Previously this commit was after `intel/fs: Combine constants for
integer instructions too`. However, this commit can create invalid
instructions that are only cleaned up by `intel/fs: Combine constants
for integer instructions too`. That would potentially affect the
shader-db results of each commit, but I did not collect new data for
the reordering.
v3: Fix masking for W/UW and for Q/UQ types. Add an assertion for
!saturate. Both suggested by Ken. Also add an assertion that B/UB types
don't matically come back.
v4: Fix sources count. See also ed3c2f73dbb ("intel/fs: fixup sources
number from opt_algebraic").
v5: Fix typo in comment added in v3. Noticed by Marcin. Fix a typo in a
comment added when pulling this commit out of !7698. Noticed by Ken.
shader-db results:
DG2
No changes.
Tiger Lake, Ice Lake, and Skylake had similar results (Ice Lake shown)
total instructions in shared programs: 20655696 -> 20651648 (-0.02%)
instructions in affected programs: 23125 -> 19077 (-17.50%)
helped: 7 / HURT: 0
total cycles in shared programs: 858436639 -> 858407749 (<.01%)
cycles in affected programs: 8990532 -> 8961642 (-0.32%)
helped: 7 / HURT: 0
Broadwell and Haswell had similar results. (Broadwell shown)
total instructions in shared programs: 18500780 -> 18496630 (-0.02%)
instructions in affected programs: 24715 -> 20565 (-16.79%)
helped: 7 / HURT: 0
total cycles in shared programs: 946100660 -> 946087688 (<.01%)
cycles in affected programs: 5838252 -> 5825280 (-0.22%)
helped: 7 / HURT: 0
total spills in shared programs: 17588 -> 17572 (-0.09%)
spills in affected programs: 1206 -> 1190 (-1.33%)
helped: 2 / HURT: 0
total fills in shared programs: 25192 -> 25156 (-0.14%)
fills in affected programs: 156 -> 120 (-23.08%)
helped: 2 / HURT: 0
No shader-db changes on any older Intel platforms.
fossil-db results:
DG2
Totals:
Instrs: 197780415 -> 197780372 (-0.00%); split: -0.00%, +0.00%
Cycles: 14066412266 -> 14066410782 (-0.00%); split: -0.00%, +0.00%
Totals from 16 (0.00% of 668055) affected shaders:
Instrs: 16420 -> 16377 (-0.26%); split: -0.43%, +0.17%
Cycles: 220133 -> 218649 (-0.67%); split: -0.69%, +0.01%
Tiger Lake, Ice Lake and Skylake had similar results. (Ice Lake shown)
Totals:
Instrs: 153425977 -> 153423678 (-0.00%)
Cycles: 14747928947 -> 14747929547 (+0.00%); split: -0.00%, +0.00%
Subgroup size: 8535968 -> 8535976 (+0.00%)
Send messages: 7697606 -> 7697607 (+0.00%)
Scratch Memory Size: 4380672 -> 4381696 (+0.02%)
Totals from 6 (0.00% of 662749) affected shaders:
Instrs: 13893 -> 11594 (-16.55%)
Cycles: 5386074 -> 5386674 (+0.01%); split: -0.42%, +0.43%
Subgroup size: 80 -> 88 (+10.00%)
Send messages: 675 -> 676 (+0.15%)
Scratch Memory Size: 91136 -> 92160 (+1.12%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23884>
2020-11-13 19:11:56 -08:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case BRW_OPCODE_CMP:
|
|
|
|
|
case BRW_OPCODE_IF:
|
|
|
|
|
if (arg == 1) {
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
} else if (arg == 0 && inst->src[1].file != IMM) {
|
|
|
|
|
enum brw_conditional_mod new_cmod;
|
|
|
|
|
|
|
|
|
|
new_cmod = brw_swap_cmod(inst->conditional_mod);
|
|
|
|
|
if (new_cmod != BRW_CONDITIONAL_NONE) {
|
|
|
|
|
/* Fit this constant in by swapping the operands and
|
|
|
|
|
* flipping the test
|
2012-09-21 13:11:54 +02:00
|
|
|
*/
|
|
|
|
|
inst->src[0] = inst->src[1];
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[1] = val;
|
2023-03-15 12:01:35 -07:00
|
|
|
inst->conditional_mod = new_cmod;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
}
|
|
|
|
|
break;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
case BRW_OPCODE_SEL:
|
|
|
|
|
if (arg == 1) {
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
} else if (arg == 0) {
|
|
|
|
|
if (inst->src[1].file != IMM &&
|
|
|
|
|
(inst->conditional_mod == BRW_CONDITIONAL_NONE ||
|
|
|
|
|
/* Only GE and L are commutative. */
|
|
|
|
|
inst->conditional_mod == BRW_CONDITIONAL_GE ||
|
|
|
|
|
inst->conditional_mod == BRW_CONDITIONAL_L)) {
|
|
|
|
|
inst->src[0] = inst->src[1];
|
|
|
|
|
inst->src[1] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
/* 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;
|
2012-09-21 13:11:54 +02:00
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
} else {
|
|
|
|
|
inst->src[0] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
}
|
2016-04-29 23:36:59 -07:00
|
|
|
|
intel/fs: Better handle constant sources of FS_OPCODE_PACK_HALF_2x16_SPLIT
I noticed that a *LOT* of fragment shaders in Shadow of the Tomb Raider,
for instance, end up with a sequence of NIR like:
vec1 32 ssa_2 = load_const (0x00000000 = 0.000000)
...
vec1 32 ssa_191 = pack_half_2x16_split ssa_188, ssa_2
vec1 32 ssa_192 = pack_half_2x16_split ssa_189, ssa_2
vec1 32 ssa_193 = pack_half_2x16_split ssa_190, ssa_2
This results in an assembly sequence like:
mov(8) g28<1>UD 0x00000000UD
mov(8) g21<2>HF g28<8,8,1>F
shl(8) g21<1>UD g21<8,8,1>UD 0x00000010UD
mov(8) g21<2>HF g25<8,8,1>F
mov(8) g19<2>HF g28<8,8,1>F
shl(8) g19<1>UD g19<8,8,1>UD 0x00000010UD
mov(8) g19<2>HF g23<8,8,1>F
mov(8) g20<2>HF g28<8,8,1>F
shl(8) g20<1>UD g20<8,8,1>UD 0x00000010UD
mov(8) g20<2>HF g24<8,8,1>F
After this commit, the generated assembly is:
mov(8) g21<1>UD 0x00000000UD
mov(8) g21<2>HF g23<8,8,1>F
mov(8) g19<1>UD 0x00000000UD
mov(8) g19<2>HF g17<8,8,1>F
mov(8) g20<1>UD 0x00000000UD
mov(8) g20<2>HF g18<8,8,1>F
Tiger Lake, Ice Lake, Skylake, and Haswell had similar results. (Ice Lake shown)
total instructions in shared programs: 20119086 -> 20119034 (<.01%)
instructions in affected programs: 9056 -> 9004 (-0.57%)
helped: 8
HURT: 0
helped stats (abs) min: 2 max: 16 x̄: 6.50 x̃: 4
helped stats (rel) min: 0.29% max: 1.75% x̄: 1.00% x̃: 0.98%
95% mean confidence interval for instructions value: -11.01 -1.99
95% mean confidence interval for instructions %-change: -1.56% -0.44%
Instructions are helped.
total cycles in shared programs: 861019414 -> 861021044 (<.01%)
cycles in affected programs: 279862 -> 281492 (0.58%)
helped: 4
HURT: 2
helped stats (abs) min: 6 max: 936 x̄: 239.00 x̃: 7
helped stats (rel) min: 0.03% max: 8.13% x̄: 2.09% x̃: 0.09%
HURT stats (abs) min: 18 max: 2568 x̄: 1293.00 x̃: 1293
HURT stats (rel) min: 0.36% max: 1.14% x̄: 0.75% x̃: 0.75%
95% mean confidence interval for cycles value: -972.56 1515.89
95% mean confidence interval for cycles %-change: -4.77% 2.49%
Inconclusive result (value mean confidence interval includes 0).
Broadwell
total instructions in shared programs: 17812327 -> 17812263 (<.01%)
instructions in affected programs: 9867 -> 9803 (-0.65%)
helped: 8
HURT: 0
helped stats (abs) min: 2 max: 28 x̄: 8.00 x̃: 4
helped stats (rel) min: 0.32% max: 1.80% x̄: 1.00% x̃: 0.95%
95% mean confidence interval for instructions value: -15.46 -0.54
95% mean confidence interval for instructions %-change: -1.54% -0.47%
Instructions are helped.
total cycles in shared programs: 904768620 -> 904773291 (<.01%)
cycles in affected programs: 454799 -> 459470 (1.03%)
helped: 4
HURT: 4
helped stats (abs) min: 36 max: 586 x̄: 344.50 x̃: 378
helped stats (rel) min: 0.47% max: 4.04% x̄: 2.01% x̃: 1.77%
HURT stats (abs) min: 1 max: 5572 x̄: 1512.25 x̃: 238
HURT stats (rel) min: <.01% max: 2.77% x̄: 1.46% x̃: 1.53%
95% mean confidence interval for cycles value: -1122.40 2290.15
95% mean confidence interval for cycles %-change: -2.26% 1.71%
Inconclusive result (value mean confidence interval includes 0).
total spills in shared programs: 18581 -> 18579 (-0.01%)
spills in affected programs: 323 -> 321 (-0.62%)
helped: 1
HURT: 0
total fills in shared programs: 24985 -> 24981 (-0.02%)
fills in affected programs: 1348 -> 1344 (-0.30%)
helped: 1
HURT: 0
Tiger Lake, Ice Lake, and Skylake had similar results. (Ice Lake shown)
Instructions in all programs: 143585431 -> 143513657 (-0.0%)
Instructions helped: 14403
Cycles in all programs: 8439312778 -> 8439371578 (+0.0%)
Cycles helped: 10570
Cycles hurt: 3290
Gained: 146
Lost: 74
All of the lost and gained fossil-db shaders are SIMD32 fragment
shaders. 14,247 of the affected shaders are from Shadow of the Tomb
Raider. 154 are from Batman Arkham Origins, and the remaining two are
from Octopath Traveler.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15089>
2022-02-14 14:07:18 -08:00
|
|
|
progress = true;
|
2012-09-21 13:11:54 +02:00
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
break;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
case FS_OPCODE_FB_WRITE_LOGICAL:
|
|
|
|
|
/* The stencil and omask sources of FS_OPCODE_FB_WRITE_LOGICAL are
|
|
|
|
|
* bit-cast using a strided region so they cannot be immediates.
|
|
|
|
|
*/
|
|
|
|
|
if (arg != FB_WRITE_LOGICAL_SRC_SRC_STENCIL &&
|
|
|
|
|
arg != FB_WRITE_LOGICAL_SRC_OMASK) {
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
2023-05-19 09:56:42 -07:00
|
|
|
}
|
2023-03-15 12:01:35 -07:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case SHADER_OPCODE_INT_QUOTIENT:
|
|
|
|
|
case SHADER_OPCODE_INT_REMAINDER:
|
|
|
|
|
case BRW_OPCODE_AND:
|
|
|
|
|
case BRW_OPCODE_ASR:
|
|
|
|
|
case BRW_OPCODE_BFE:
|
|
|
|
|
case BRW_OPCODE_BFI1:
|
|
|
|
|
case BRW_OPCODE_BFI2:
|
|
|
|
|
case BRW_OPCODE_ROL:
|
|
|
|
|
case BRW_OPCODE_ROR:
|
|
|
|
|
case BRW_OPCODE_SHL:
|
|
|
|
|
case BRW_OPCODE_SHR:
|
|
|
|
|
case BRW_OPCODE_OR:
|
|
|
|
|
case SHADER_OPCODE_TEX_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXD_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXL_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXS_LOGICAL:
|
|
|
|
|
case FS_OPCODE_TXB_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_CMS_W_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_CMS_W_GFX12_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_MCS_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_LOD_LOGICAL:
|
2023-02-16 20:30:30 -08:00
|
|
|
case SHADER_OPCODE_TG4_BIAS_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_EXPLICIT_LOD_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_IMPLICIT_LOD_LOGICAL:
|
2023-03-15 12:01:35 -07:00
|
|
|
case SHADER_OPCODE_TG4_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_OFFSET_LOGICAL:
|
2023-03-05 15:27:08 -08:00
|
|
|
case SHADER_OPCODE_TG4_OFFSET_LOD_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_OFFSET_BIAS_LOGICAL:
|
2023-03-15 12:01:35 -07:00
|
|
|
case SHADER_OPCODE_SAMPLEINFO_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_UNTYPED_ATOMIC_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_UNTYPED_SURFACE_READ_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_UNTYPED_SURFACE_WRITE_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TYPED_ATOMIC_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TYPED_SURFACE_READ_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TYPED_SURFACE_WRITE_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL:
|
|
|
|
|
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
|
|
|
|
|
case SHADER_OPCODE_BROADCAST:
|
|
|
|
|
case BRW_OPCODE_MAD:
|
|
|
|
|
case BRW_OPCODE_LRP:
|
|
|
|
|
case FS_OPCODE_PACK_HALF_2x16_SPLIT:
|
|
|
|
|
case SHADER_OPCODE_SHUFFLE:
|
|
|
|
|
inst->src[arg] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
break;
|
2023-06-22 19:03:25 -07:00
|
|
|
}
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
return progress;
|
|
|
|
|
}
|
2014-06-05 11:05:28 -07:00
|
|
|
|
|
|
|
|
static bool
|
2019-04-24 12:38:28 +02:00
|
|
|
can_propagate_from(fs_inst *inst)
|
2014-06-05 11:05:28 -07:00
|
|
|
{
|
|
|
|
|
return (inst->opcode == BRW_OPCODE_MOV &&
|
2015-10-26 17:09:25 -07:00
|
|
|
inst->dst.file == VGRF &&
|
|
|
|
|
((inst->src[0].file == VGRF &&
|
2023-03-23 16:20:38 -07:00
|
|
|
!grf_regions_overlap(inst->dst, inst->size_written,
|
|
|
|
|
inst->src[0], inst->size_read(0))) ||
|
2015-03-10 04:18:06 -07:00
|
|
|
inst->src[0].file == ATTR ||
|
2014-06-05 11:05:28 -07:00
|
|
|
inst->src[0].file == UNIFORM ||
|
2019-12-30 00:38:08 -08:00
|
|
|
inst->src[0].file == IMM ||
|
|
|
|
|
(inst->src[0].file == FIXED_GRF &&
|
|
|
|
|
inst->src[0].is_contiguous())) &&
|
2014-06-05 11:05:28 -07:00
|
|
|
inst->src[0].type == inst->dst.type &&
|
2023-03-23 14:19:29 -07:00
|
|
|
!inst->saturate &&
|
intel/fs: Allow copy propagation between MOVs of mixed sizes
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
Unfortunately, this doesn't clean everything up. Here's a subset of the
"before" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
mov(8) g12<1>UB g7<32,8,4>UB { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g12<8,8,1>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g14<1>UB g8<32,8,4>UB { align1 1Q };
mov(8) g16<1>UW g14<8,8,1>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
And here's the same subset of the "after" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g7<32,8,4>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g16<1>UW g8<32,8,4>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
There are a lot of regioning and type restrictions in
fs_visitor::try_copy_propagate, and I'm a little nervious about messing
with them too much.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
2021-04-13 14:07:19 -07:00
|
|
|
/* Subset of !is_partial_write() conditions. */
|
2023-08-18 16:12:47 -07:00
|
|
|
!inst->predicate && inst->dst.is_contiguous()) ||
|
2019-12-30 00:36:48 -08:00
|
|
|
is_identity_payload(FIXED_GRF, inst);
|
2014-06-05 11:05:28 -07:00
|
|
|
}
|
|
|
|
|
|
2012-05-08 13:01:52 -07:00
|
|
|
/* Walks a basic block and does copy propagation on it using the acp
|
|
|
|
|
* list.
|
|
|
|
|
*/
|
2023-08-18 17:31:12 -07:00
|
|
|
static bool
|
2023-10-02 10:39:09 -07:00
|
|
|
opt_copy_propagation_local(const brw_compiler *compiler, linear_ctx *lin_ctx,
|
2023-08-18 17:37:02 -07:00
|
|
|
bblock_t *block, struct acp &acp,
|
2023-09-21 13:55:41 -07:00
|
|
|
const brw::simple_allocator &alloc,
|
|
|
|
|
uint8_t max_polygons)
|
2012-05-08 13:01:52 -07:00
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
|
2014-06-24 12:42:00 -07:00
|
|
|
foreach_inst_in_block(fs_inst, inst, block) {
|
2012-05-08 13:01:52 -07:00
|
|
|
/* Try propagating into this instruction. */
|
2023-03-15 12:01:35 -07:00
|
|
|
bool instruction_progress = false;
|
|
|
|
|
for (int i = inst->sources - 1; i >= 0; i--) {
|
2015-10-26 17:09:25 -07:00
|
|
|
if (inst->src[i].file != VGRF)
|
2012-09-21 16:06:17 +02:00
|
|
|
continue;
|
2012-05-08 13:01:52 -07:00
|
|
|
|
2023-08-28 15:46:53 -07:00
|
|
|
for (auto iter = acp.find_by_dst(inst->src[i].nr);
|
|
|
|
|
iter != acp.end() && (*iter)->dst.nr == inst->src[i].nr;
|
|
|
|
|
++iter) {
|
|
|
|
|
if ((*iter)->src.file == IMM) {
|
|
|
|
|
if (try_constant_propagate(compiler, inst, *iter, i)) {
|
2023-03-15 12:01:35 -07:00
|
|
|
instruction_progress = true;
|
2023-03-14 17:13:37 -07:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2023-09-21 13:55:41 -07:00
|
|
|
if (try_copy_propagate(compiler, inst, *iter, i, alloc,
|
|
|
|
|
max_polygons)) {
|
2023-03-15 12:01:35 -07:00
|
|
|
instruction_progress = true;
|
2023-03-14 17:13:37 -07:00
|
|
|
break;
|
|
|
|
|
}
|
2023-08-18 09:34:35 -07:00
|
|
|
}
|
2012-09-21 16:06:17 +02:00
|
|
|
}
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
2023-03-15 12:01:35 -07:00
|
|
|
if (instruction_progress) {
|
|
|
|
|
progress = true;
|
|
|
|
|
|
|
|
|
|
/* ADD3 can only have the immediate as src0. */
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_ADD3) {
|
|
|
|
|
if (inst->src[2].file == IMM) {
|
|
|
|
|
const auto src0 = inst->src[0];
|
|
|
|
|
inst->src[0] = inst->src[2];
|
|
|
|
|
inst->src[2] = src0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If only one of the sources of a 2-source, commutative instruction (e.g.,
|
|
|
|
|
* AND) is immediate, it must be src1. If both are immediate, opt_algebraic
|
|
|
|
|
* should fold it away.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->sources == 2 && inst->is_commutative() &&
|
|
|
|
|
inst->src[0].file == IMM && inst->src[1].file != IMM) {
|
|
|
|
|
const auto src1 = inst->src[1];
|
|
|
|
|
inst->src[1] = inst->src[0];
|
|
|
|
|
inst->src[0] = src1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-08 13:01:52 -07:00
|
|
|
/* kill the destination from the ACP */
|
2019-12-30 00:38:08 -08:00
|
|
|
if (inst->dst.file == VGRF || inst->dst.file == FIXED_GRF) {
|
2023-08-28 15:46:53 -07:00
|
|
|
for (auto iter = acp.find_by_dst(inst->dst.nr);
|
|
|
|
|
iter != acp.end() && (*iter)->dst.nr == inst->dst.nr;
|
|
|
|
|
++iter) {
|
|
|
|
|
if (grf_regions_overlap((*iter)->dst, (*iter)->size_written,
|
2023-03-23 16:20:38 -07:00
|
|
|
inst->dst, inst->size_written))
|
2023-08-28 15:46:53 -07:00
|
|
|
acp.remove(*iter);
|
2016-03-11 14:35:07 +01:00
|
|
|
}
|
2012-09-21 16:06:17 +02:00
|
|
|
|
2023-08-18 19:11:58 -07:00
|
|
|
for (auto iter = acp.find_by_src(inst->dst.nr);
|
|
|
|
|
iter != acp.end() && (*iter)->src.nr == inst->dst.nr;
|
|
|
|
|
++iter) {
|
|
|
|
|
/* Make sure we kill the entry if this instruction overwrites
|
|
|
|
|
* _any_ of the registers that it reads
|
|
|
|
|
*/
|
|
|
|
|
if (grf_regions_overlap((*iter)->src, (*iter)->size_read,
|
|
|
|
|
inst->dst, inst->size_written))
|
|
|
|
|
acp.remove(*iter);
|
|
|
|
|
}
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
2012-10-30 15:02:23 -07:00
|
|
|
/* If this instruction's source could potentially be folded into the
|
|
|
|
|
* operand of another instruction, add it to the ACP.
|
|
|
|
|
*/
|
2019-04-24 12:38:28 +02:00
|
|
|
if (can_propagate_from(inst)) {
|
2023-10-02 10:39:09 -07:00
|
|
|
acp_entry *entry = linear_zalloc(lin_ctx, acp_entry);
|
2016-03-11 14:35:07 +01:00
|
|
|
entry->dst = inst->dst;
|
|
|
|
|
entry->src = inst->src[0];
|
2016-09-07 13:38:20 -07:00
|
|
|
entry->size_written = inst->size_written;
|
2019-12-30 00:36:48 -08:00
|
|
|
for (unsigned i = 0; i < inst->sources; i++)
|
|
|
|
|
entry->size_read += inst->size_read(i);
|
2014-04-17 15:13:00 -07:00
|
|
|
entry->opcode = inst->opcode;
|
intel/fs: Allow copy propagation between MOVs of mixed sizes
This eliminates some spurious, size-converting moves. For example, on
Ice Lake this helps dEQP-VK.spirv_assembly.type.vec3.i8.bitwise_xor_frag:
SIMD8 shader: 52 instructions. 1 loops. 4164 cycles. 0:0 spills:fills, 5 sends
SIMD8 shader: 49 instructions. 1 loops. 4044 cycles. 0:0 spills:fills, 5 sends
Unfortunately, this doesn't clean everything up. Here's a subset of the
"before" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
mov(8) g12<1>UB g7<32,8,4>UB { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g12<8,8,1>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g14<1>UB g8<32,8,4>UB { align1 1Q };
mov(8) g16<1>UW g14<8,8,1>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
And here's the same subset of the "after" assembly:
send(8) g11<1>UW g2<0,1,0>UD 0x02106e02
dp data 1 MsgDesc: ( untyped surface read, Surface = 2, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g7<4>UB g11<8,8,1>UD { align1 1Q };
send(8) g13<1>UW g2<0,1,0>UD 0x02106e03
dp data 1 MsgDesc: ( untyped surface read, Surface = 3, SIMD8, Mask = 0xe) mlen 1 rlen 1 { align1 1Q };
mov(8) g15<1>UW g7<32,8,4>UB { align1 1Q };
mov(8) g8<4>UB g13<8,8,1>UD { align1 1Q };
mov(8) g16<1>UW g8<32,8,4>UB { align1 1Q };
xor(8) g17<1>UW g15<8,8,1>UW g16<8,8,1>UW { align1 1Q };
There are a lot of regioning and type restrictions in
fs_visitor::try_copy_propagate, and I'm a little nervious about messing
with them too much.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Suggested-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9025>
2021-04-13 14:07:19 -07:00
|
|
|
entry->is_partial_write = inst->is_partial_write();
|
2023-02-10 19:29:20 -08:00
|
|
|
entry->force_writemask_all = inst->force_writemask_all;
|
2023-08-18 17:37:02 -07:00
|
|
|
acp.add(entry);
|
2014-04-17 15:13:00 -07:00
|
|
|
} else if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD &&
|
2015-10-26 17:09:25 -07:00
|
|
|
inst->dst.file == VGRF) {
|
2014-08-18 14:27:55 -07:00
|
|
|
int offset = 0;
|
2014-04-17 15:13:00 -07:00
|
|
|
for (int i = 0; i < inst->sources; i++) {
|
2015-04-01 18:15:42 -07:00
|
|
|
int effective_width = i < inst->header_size ? 8 : inst->exec_size;
|
2016-09-07 13:38:20 -07:00
|
|
|
const unsigned size_written = effective_width *
|
|
|
|
|
type_sz(inst->src[i].type);
|
2019-12-30 00:38:08 -08:00
|
|
|
if (inst->src[i].file == VGRF ||
|
|
|
|
|
(inst->src[i].file == FIXED_GRF &&
|
|
|
|
|
inst->src[i].is_contiguous())) {
|
2022-09-27 15:28:48 -07:00
|
|
|
const brw_reg_type t = i < inst->header_size ?
|
|
|
|
|
BRW_REGISTER_TYPE_UD : inst->src[i].type;
|
2023-10-10 17:47:39 -07:00
|
|
|
fs_reg dst = byte_offset(retype(inst->dst, t), offset);
|
|
|
|
|
if (!dst.equals(inst->src[i])) {
|
2023-10-02 10:39:09 -07:00
|
|
|
acp_entry *entry = linear_zalloc(lin_ctx, acp_entry);
|
2023-10-10 17:47:39 -07:00
|
|
|
entry->dst = dst;
|
|
|
|
|
entry->src = retype(inst->src[i], t);
|
|
|
|
|
entry->size_written = size_written;
|
|
|
|
|
entry->size_read = inst->size_read(i);
|
|
|
|
|
entry->opcode = inst->opcode;
|
|
|
|
|
entry->force_writemask_all = inst->force_writemask_all;
|
2023-08-18 17:37:02 -07:00
|
|
|
acp.add(entry);
|
2014-04-17 15:13:00 -07:00
|
|
|
}
|
|
|
|
|
}
|
2016-09-01 21:22:03 -07:00
|
|
|
offset += size_written;
|
2014-04-17 15:13:00 -07:00
|
|
|
}
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return progress;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool
|
2024-01-03 10:57:23 -08:00
|
|
|
brw_fs_opt_copy_propagation(fs_visitor &s)
|
2012-05-08 13:01:52 -07:00
|
|
|
{
|
|
|
|
|
bool progress = false;
|
2014-03-26 15:58:12 -07:00
|
|
|
void *copy_prop_ctx = ralloc_context(NULL);
|
2023-10-02 10:39:09 -07:00
|
|
|
linear_ctx *lin_ctx = linear_context(copy_prop_ctx);
|
2024-01-03 10:57:23 -08:00
|
|
|
struct acp out_acp[s.cfg->num_blocks];
|
2012-05-08 13:01:52 -07:00
|
|
|
|
2024-01-03 10:57:23 -08:00
|
|
|
const fs_live_variables &live = s.live_analysis.require();
|
2017-10-23 13:47:10 -07:00
|
|
|
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
/* First, walk through each block doing local copy propagation and getting
|
|
|
|
|
* the set of copies available at the end of the block.
|
|
|
|
|
*/
|
2024-01-03 10:57:23 -08:00
|
|
|
foreach_block (block, s.cfg) {
|
|
|
|
|
progress = opt_copy_propagation_local(s.compiler, lin_ctx, block,
|
|
|
|
|
out_acp[block->num], s.alloc,
|
|
|
|
|
s.max_polygons) || progress;
|
2019-05-04 23:51:23 -05:00
|
|
|
|
|
|
|
|
/* If the destination of an ACP entry exists only within this block,
|
|
|
|
|
* then there's no need to keep it for dataflow analysis. We can delete
|
|
|
|
|
* it from the out_acp table and avoid growing the bitsets any bigger
|
|
|
|
|
* than we absolutely have to.
|
|
|
|
|
*
|
|
|
|
|
* Because nothing in opt_copy_propagation_local touches the block
|
|
|
|
|
* start/end IPs and opt_copy_propagation_local is incapable of
|
|
|
|
|
* extending the live range of an ACP destination beyond the block,
|
|
|
|
|
* it's safe to use the liveness information in this way.
|
|
|
|
|
*/
|
2023-08-28 15:46:53 -07:00
|
|
|
for (auto iter = out_acp[block->num].begin();
|
|
|
|
|
iter != out_acp[block->num].end(); ++iter) {
|
|
|
|
|
assert((*iter)->dst.file == VGRF);
|
|
|
|
|
if (block->start_ip <= live.vgrf_start[(*iter)->dst.nr] &&
|
|
|
|
|
live.vgrf_end[(*iter)->dst.nr] <= block->end_ip) {
|
|
|
|
|
out_acp[block->num].remove(*iter);
|
2019-05-04 23:51:23 -05:00
|
|
|
}
|
|
|
|
|
}
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Do dataflow analysis for those available copies. */
|
2024-01-03 10:57:23 -08:00
|
|
|
fs_copy_prop_dataflow dataflow(lin_ctx, s.cfg, live, out_acp);
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
/* Next, re-run local copy propagation, this time with the set of copies
|
|
|
|
|
* provided by the dataflow analysis available at the start of a block.
|
|
|
|
|
*/
|
2024-01-03 10:57:23 -08:00
|
|
|
foreach_block (block, s.cfg) {
|
2023-08-18 17:37:02 -07:00
|
|
|
struct acp in_acp;
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
|
|
|
|
|
for (int i = 0; i < dataflow.num_acp; i++) {
|
intel/fs: Fix copy propagation dataflow analysis in presence of force_writemask_all ACP overwrites.
This fixes the behavior of copy propagation in cases where either the
source or destination of an ACP is overwritten elsewhere in the
program by a force_writemask_all instruction, which could cause the
overwrite to be executed for an inactive channel under non-uniform
control flow, causing the current per-channel dataflow propagation to
give incorrect results. This has been reported in cases like:
> while (true) {
> x = imageSize(img);
> if (non_uniform_condition()) {
> y = x;
> break;
> }
> }
> use(y);
Currently the copy propagation pass would propagate copy 'y = x' into
'use(y)', which is invalid since in the example above imageSize() is
implemented as a force_writemask_all SEND message, whose result is
broadcast to all channels, so when a given channel executes 'y = x'
and breaks out of the loop, another divergent channel can execute a
subsequent iteration of the loop overwriting 'x' with a different
value, hence replacing 'y' with 'x' at 'use(y)' changes the behavior
of the program.
This patch extends the global dataflow analysis algorithm to determine
whether there is any control flow path from a given copy to an
overwrite of its source or destination which has force_writemask_all
behavior inconsistent with the copy, and in such case prevents copy
propagation for that ACP entry at any point of the program which can
be reached from the overwrite, even if the copy is statically
re-executed along all such control flow paths (as in the example
above), since the execution of the overwrite for a given channel i may
corrupt other channels j!=i inactive for the subsequently re-executed
copy.
Note that a simpler solution has been attempted which fully shuts down
copy propagation if such a force_writemask_all ACP overwrite is
present /anywhere/ in the program regardless of its location in the
control flow graph, however that led to large shader-db regressions in
some programs from shader-db (like a CS from Car Chase which would
emit 53% more instructions). With this solution the only handful of
shaders that suffer instruction count regressions seem to be getting
misoptimized right now (e.g. some compute shaders from Deus Ex
Mankind). This solution doesn't seem to affect the run-time of
shader-db significantly, it's less than 1% higher with the fix
applied.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21351>
2023-02-10 19:33:50 -08:00
|
|
|
if (BITSET_TEST(dataflow.bd[block->num].livein, i) &&
|
|
|
|
|
!BITSET_TEST(dataflow.bd[block->num].exec_mismatch, i)) {
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
struct acp_entry *entry = dataflow.acp[i];
|
2023-08-18 17:37:02 -07:00
|
|
|
in_acp.add(entry);
|
i965/fs: Add support for global copy propagation.
It is common for complicated shaders, particularly code-generated ones, to
have a big array of uniforms or attributes, and a prologue in the shader that
dereferences from the big array to more informatively-named local variables.
Then there will be some small control flow operation (like a ? : statement),
and then use of those informatively-named variables. We were emitting extra
MOVs in these cases, because copy propagation couldn't reach across control
flow.
Instead, implement dataflow analysis on the output of the first copy
propagation pass and re-run it to propagate those extra MOVs out.
On one future Steam release, reduces VS+FS instruction count from 42837 to
41437. No statistically significant performance difference (n=48), though, at
least at the low resolution I'm running it at.
shader-db results:
total instructions in shared programs: 722170 -> 702545 (-2.72%)
instructions in affected programs: 260618 -> 240993 (-7.53%)
Some shaders do get hurt by up to 2 instructions, because a choice to copy
propagate instead of coalesce or something like that results in a dead write
sticking around. Given that we already have instances of those instructions
in the affected programs (particularly unigine), we should just improve dead
code elimination to fix the problem.
2012-10-30 11:09:59 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-01-03 10:57:23 -08:00
|
|
|
progress = opt_copy_propagation_local(s.compiler, lin_ctx, block,
|
|
|
|
|
in_acp, s.alloc, s.max_polygons) ||
|
2016-11-28 10:45:08 -08:00
|
|
|
progress;
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
2014-03-26 15:58:12 -07:00
|
|
|
ralloc_free(copy_prop_ctx);
|
2012-05-08 13:01:52 -07:00
|
|
|
|
2012-06-05 13:14:38 -07:00
|
|
|
if (progress)
|
2024-01-03 10:57:23 -08:00
|
|
|
s.invalidate_analysis(DEPENDENCY_INSTRUCTION_DATA_FLOW |
|
|
|
|
|
DEPENDENCY_INSTRUCTION_DETAIL);
|
2012-06-05 13:14:38 -07:00
|
|
|
|
2012-05-08 13:01:52 -07:00
|
|
|
return progress;
|
|
|
|
|
}
|