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).
|
|
|
|
|
*/
|
|
|
|
|
|
2019-05-04 22:47:59 -05:00
|
|
|
#define ACP_HASH_SIZE 64
|
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
|
|
|
|
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"
|
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 */
|
|
|
|
|
struct acp_entry : public exec_node {
|
|
|
|
|
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;
|
2014-07-03 04:14:39 -07:00
|
|
|
bool 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
|
|
|
bool is_partial_write;
|
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
|
|
|
|
|
|
|
|
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;
|
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:
|
|
|
|
|
fs_copy_prop_dataflow(void *mem_ctx, cfg_t *cfg,
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live,
|
2013-01-08 12:46:05 -08:00
|
|
|
exec_list *out_acp[ACP_HASH_SIZE]);
|
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
|
|
|
void *mem_ctx;
|
|
|
|
|
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 */
|
|
|
|
|
|
|
|
|
|
fs_copy_prop_dataflow::fs_copy_prop_dataflow(void *mem_ctx, cfg_t *cfg,
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live,
|
2013-01-08 12:46:05 -08:00
|
|
|
exec_list *out_acp[ACP_HASH_SIZE])
|
2017-10-23 13:47:10 -07:00
|
|
|
: mem_ctx(mem_ctx), 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
|
|
|
{
|
|
|
|
|
bd = rzalloc_array(mem_ctx, struct block_data, cfg->num_blocks);
|
|
|
|
|
|
|
|
|
|
num_acp = 0;
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
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 < ACP_HASH_SIZE; i++) {
|
2014-07-11 22:31:39 -07:00
|
|
|
num_acp += out_acp[block->num][i].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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
acp = rzalloc_array(mem_ctx, struct acp_entry *, num_acp);
|
|
|
|
|
|
2013-04-04 09:47:03 -07:00
|
|
|
bitset_words = BITSET_WORDS(num_acp);
|
2013-03-22 14:11:25 -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
|
|
|
int next_acp = 0;
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
bd[block->num].livein = rzalloc_array(bd, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].liveout = rzalloc_array(bd, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].copy = rzalloc_array(bd, BITSET_WORD, bitset_words);
|
|
|
|
|
bd[block->num].kill = rzalloc_array(bd, BITSET_WORD, bitset_words);
|
2017-10-23 13:47:10 -07:00
|
|
|
bd[block->num].undef = rzalloc_array(bd, 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
|
|
|
|
|
|
|
|
for (int i = 0; i < ACP_HASH_SIZE; i++) {
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_in_list(acp_entry, entry, &out_acp[block->num][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
|
|
|
acp[next_acp] = entry;
|
2013-08-08 23:29:56 -07:00
|
|
|
|
2019-05-05 00:13:20 -05:00
|
|
|
entry->global_idx = next_acp;
|
|
|
|
|
|
2016-11-28 10:45:08 -08:00
|
|
|
/* opt_copy_propagation_local populates out_acp with copies created
|
2013-08-08 23:29:56 -07:00
|
|
|
* in a block which are still live at the end of the block. This
|
|
|
|
|
* is exactly what we want in the COPY set.
|
|
|
|
|
*/
|
2014-07-11 22:31:39 -07:00
|
|
|
BITSET_SET(bd[block->num].copy, next_acp);
|
2013-08-08 23:29:56 -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
|
|
|
next_acp++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
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
|
|
|
{
|
|
|
|
|
/* Create a temporary table of ACP entries which we'll use for efficient
|
|
|
|
|
* look-up. Unfortunately, we have to do this in two steps because we
|
|
|
|
|
* have to match both sources and destinations and an ACP entry can only
|
|
|
|
|
* be in one list at a time.
|
|
|
|
|
*
|
|
|
|
|
* We choose to make the table size between num_acp/2 and num_acp/4 to
|
|
|
|
|
* try and trade off between the time it takes to initialize the table
|
|
|
|
|
* via exec_list constructors or make_empty() and the cost of
|
|
|
|
|
* collisions. In practice, it doesn't appear to matter too much what
|
|
|
|
|
* size we make the table as long as it's roughly the same order of
|
|
|
|
|
* magnitude as num_acp. We get most of the benefit of the table
|
|
|
|
|
* approach even if we use a table of size ACP_HASH_SIZE though a
|
|
|
|
|
* full-sized table is 1-2% faster in practice.
|
|
|
|
|
*/
|
|
|
|
|
unsigned acp_table_size = util_next_power_of_two(num_acp) / 4;
|
|
|
|
|
acp_table_size = MAX2(acp_table_size, ACP_HASH_SIZE);
|
|
|
|
|
exec_list *acp_table = new exec_list[acp_table_size];
|
|
|
|
|
|
|
|
|
|
/* First, get all the KILLs for instructions which overwrite ACP
|
|
|
|
|
* destinations.
|
|
|
|
|
*/
|
|
|
|
|
for (int i = 0; i < num_acp; i++) {
|
2020-01-02 18:54:13 -08:00
|
|
|
unsigned idx = reg_space(acp[i]->dst) & (acp_table_size - 1);
|
2019-05-05 00:13:20 -05:00
|
|
|
acp_table[idx].push_tail(acp[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
foreach_inst_in_block(fs_inst, inst, block) {
|
|
|
|
|
if (inst->dst.file != VGRF)
|
|
|
|
|
continue;
|
|
|
|
|
|
2020-01-02 18:54:13 -08:00
|
|
|
unsigned idx = reg_space(inst->dst) & (acp_table_size - 1);
|
2019-05-05 00:13:20 -05:00
|
|
|
foreach_in_list(acp_entry, entry, &acp_table[idx]) {
|
|
|
|
|
if (regions_overlap(inst->dst, inst->size_written,
|
|
|
|
|
entry->dst, entry->size_written))
|
|
|
|
|
BITSET_SET(bd[block->num].kill, entry->global_idx);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Clear the table for the second pass */
|
|
|
|
|
for (unsigned i = 0; i < acp_table_size; i++)
|
|
|
|
|
acp_table[i].make_empty();
|
|
|
|
|
|
|
|
|
|
/* Next, get all the KILLs for instructions which overwrite ACP
|
|
|
|
|
* sources.
|
|
|
|
|
*/
|
|
|
|
|
for (int i = 0; i < num_acp; i++) {
|
2020-01-02 18:54:13 -08:00
|
|
|
unsigned idx = reg_space(acp[i]->src) & (acp_table_size - 1);
|
2019-05-05 00:13:20 -05:00
|
|
|
acp_table[idx].push_tail(acp[i]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach_block (block, cfg) {
|
|
|
|
|
foreach_inst_in_block(fs_inst, inst, block) {
|
2020-01-02 18:54:13 -08:00
|
|
|
if (inst->dst.file != VGRF &&
|
|
|
|
|
inst->dst.file != FIXED_GRF)
|
2019-05-05 00:13:20 -05:00
|
|
|
continue;
|
|
|
|
|
|
2020-01-02 18:54:13 -08:00
|
|
|
unsigned idx = reg_space(inst->dst) & (acp_table_size - 1);
|
2019-05-05 00:13:20 -05:00
|
|
|
foreach_in_list(acp_entry, entry, &acp_table[idx]) {
|
|
|
|
|
if (regions_overlap(inst->dst, inst->size_written,
|
|
|
|
|
entry->src, entry->size_read))
|
|
|
|
|
BITSET_SET(bd[block->num].kill, entry->global_idx);
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-05-05 00:13:20 -05:00
|
|
|
|
|
|
|
|
delete [] acp_table;
|
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];
|
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];
|
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]);
|
|
|
|
|
|
|
|
|
|
if (old_liveout != bd[block->num].liveout[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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* 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.
|
|
|
|
|
*
|
|
|
|
|
* From the Haswell PRM Volume 2b "Command Reference - Instructions", page
|
|
|
|
|
* 134 ("Extended Math Function"):
|
|
|
|
|
*
|
|
|
|
|
* Scalar source is supported. Source and destination horizontal stride
|
|
|
|
|
* must be 1.
|
|
|
|
|
*
|
|
|
|
|
* and similar language exists for IVB and SNB. Pre-SNB, math instructions
|
|
|
|
|
* are sends, so the sources are moved to MRF's and there are no
|
|
|
|
|
* restrictions.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->is_math()) {
|
2021-03-29 14:41:58 -07:00
|
|
|
if (devinfo->ver == 6 || devinfo->ver == 7) {
|
2015-08-14 12:00:13 -07:00
|
|
|
assert(inst->dst.stride == 1);
|
|
|
|
|
return stride == 1 || stride == 0;
|
2021-03-29 14:41:58 -07:00
|
|
|
} else if (devinfo->ver >= 8) {
|
2015-08-14 12:00:13 -07:00
|
|
|
return stride == inst->dst.stride || stride == 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-06 10:57:54 -07:00
|
|
|
bool
|
|
|
|
|
fs_visitor::try_copy_propagate(fs_inst *inst, int arg, acp_entry *entry)
|
|
|
|
|
{
|
2015-10-26 17:09:25 -07:00
|
|
|
if (inst->src[arg].file != VGRF)
|
2014-09-23 17:22:09 -07:00
|
|
|
return false;
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
if (entry->src.file == IMM)
|
|
|
|
|
return false;
|
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) {
|
|
|
|
|
/* Avoid propagating a FIXED_GRF register, as that's already pinned. */
|
|
|
|
|
if (entry->src.file == FIXED_GRF)
|
|
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->opcode == SHADER_OPCODE_SEND && entry->src.file == VGRF) {
|
|
|
|
|
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
|
|
|
|
|
|
|
|
/* Avoid propagating odd-numbered FIXED_GRF registers into the first source
|
|
|
|
|
* of a LINTERP instruction on platforms where the PLN instruction has
|
|
|
|
|
* register alignment restrictions.
|
|
|
|
|
*/
|
2021-03-29 14:41:58 -07:00
|
|
|
if (devinfo->has_pln && devinfo->ver <= 6 &&
|
2019-12-30 00:38:08 -08:00
|
|
|
entry->src.file == FIXED_GRF && (entry->src.nr & 1) &&
|
|
|
|
|
inst->opcode == FS_OPCODE_LINTERP && arg == 0)
|
|
|
|
|
return false;
|
|
|
|
|
|
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()) &&
|
2021-03-29 14:41:58 -07:00
|
|
|
((devinfo->ver == 6 && inst->is_math()) ||
|
2020-12-06 16:26:04 -08:00
|
|
|
inst->is_send_from_grf() ||
|
|
|
|
|
inst->uses_indirect_addressing())) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-28 19:27:59 -07:00
|
|
|
if (has_source_modifiers &&
|
2021-03-29 16:02:30 -07:00
|
|
|
inst->opcode == SHADER_OPCODE_GFX4_SCRATCH_WRITE)
|
2014-07-28 19:27:59 -07:00
|
|
|
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 &&
|
|
|
|
|
(reg_offset(inst->dst) % REG_SIZE) != (reg_offset(entry->src) % REG_SIZE))
|
|
|
|
|
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;
|
|
|
|
|
|
2021-03-29 14:41:58 -07:00
|
|
|
if (devinfo->ver >= 8 && (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
|
|
|
}
|
|
|
|
|
|
2014-07-03 04:14:39 -07:00
|
|
|
if (entry->saturate) {
|
|
|
|
|
switch(inst->opcode) {
|
|
|
|
|
case BRW_OPCODE_SEL:
|
2016-11-28 15:21:51 -08:00
|
|
|
if ((inst->conditional_mod != BRW_CONDITIONAL_GE &&
|
|
|
|
|
inst->conditional_mod != BRW_CONDITIONAL_L) ||
|
|
|
|
|
inst->src[1].file != IMM ||
|
2015-10-24 14:55:57 -07:00
|
|
|
inst->src[1].f < 0.0 ||
|
|
|
|
|
inst->src[1].f > 1.0) {
|
2014-07-03 04:14:39 -07:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Compose any saturate modifiers. */
|
|
|
|
|
inst->saturate = inst->saturate || entry->saturate;
|
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/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
|
|
|
assert((entry->dst.offset % REG_SIZE == 0 || inst->opcode == BRW_OPCODE_MOV) &&
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2015-10-14 02:12:09 -07:00
|
|
|
assert(inst->can_change_types());
|
2015-04-03 11:07:47 -07:00
|
|
|
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
|
|
|
|
2014-09-23 17:22:09 -07:00
|
|
|
bool
|
|
|
|
|
fs_visitor::try_constant_propagate(fs_inst *inst, acp_entry *entry)
|
2012-09-21 13:11:54 +02:00
|
|
|
{
|
|
|
|
|
bool progress = false;
|
|
|
|
|
|
|
|
|
|
if (entry->src.file != IMM)
|
|
|
|
|
return false;
|
2015-08-03 14:53:05 -07:00
|
|
|
if (type_sz(entry->src.type) > 4)
|
|
|
|
|
return false;
|
2014-10-27 23:42:41 -07:00
|
|
|
if (entry->saturate)
|
|
|
|
|
return false;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
2014-03-17 10:39:43 -07:00
|
|
|
for (int i = inst->sources - 1; i >= 0; i--) {
|
2015-10-26 17:09:25 -07:00
|
|
|
if (inst->src[i].file != VGRF)
|
2014-09-23 17:22:09 -07:00
|
|
|
continue;
|
|
|
|
|
|
2015-10-26 17:09:25 -07:00
|
|
|
assert(entry->dst.file == VGRF);
|
2015-10-26 04:35:14 -07:00
|
|
|
if (inst->src[i].nr != entry->dst.nr)
|
2014-09-23 17:22:09 -07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* 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[i], inst->size_read(i),
|
|
|
|
|
entry->dst, entry->size_written))
|
2012-09-21 13:11:54 +02:00
|
|
|
continue;
|
|
|
|
|
|
2022-02-03 10:45:58 -08: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.
|
2016-05-19 21:32:14 -07:00
|
|
|
*/
|
2022-02-03 10:45:58 -08:00
|
|
|
if (type_sz(inst->src[i].type) > type_sz(entry->dst.type))
|
2016-05-19 21:32:14 -07:00
|
|
|
continue;
|
|
|
|
|
|
2014-09-19 20:36:52 -07:00
|
|
|
fs_reg val = entry->src;
|
2022-02-03 10:45:58 -08: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[i].type) < type_sz(entry->dst.type)) {
|
|
|
|
|
if (type_sz(inst->src[i].type) != 2 || type_sz(entry->dst.type) != 4)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
assert(inst->src[i].subnr == 0 || inst->src[i].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.
|
|
|
|
|
*/
|
|
|
|
|
const uint16_t v = inst->src[i].subnr == 2 ? val.ud >> 16 : val.ud;
|
|
|
|
|
|
|
|
|
|
val.ud = v | (uint32_t(v) << 16);
|
|
|
|
|
}
|
|
|
|
|
|
2014-10-16 11:45:44 -07:00
|
|
|
val.type = inst->src[i].type;
|
2014-09-19 20:36:52 -07:00
|
|
|
|
2015-01-28 18:37:32 -08:00
|
|
|
if (inst->src[i].abs) {
|
2021-03-29 14:41:58 -07:00
|
|
|
if ((devinfo->ver >= 8 && is_logic_op(inst->opcode)) ||
|
2015-11-19 21:51:37 -08:00
|
|
|
!brw_abs_immediate(val.type, &val.as_brw_reg())) {
|
2015-01-28 18:37:32 -08:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (inst->src[i].negate) {
|
2021-03-29 14:41:58 -07:00
|
|
|
if ((devinfo->ver >= 8 && is_logic_op(inst->opcode)) ||
|
2015-11-19 21:51:37 -08:00
|
|
|
!brw_negate_immediate(val.type, &val.as_brw_reg())) {
|
2015-01-28 18:37:32 -08:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
switch (inst->opcode) {
|
|
|
|
|
case BRW_OPCODE_MOV:
|
2014-09-24 14:51:22 -07:00
|
|
|
case SHADER_OPCODE_LOAD_PAYLOAD:
|
2016-05-05 11:40:41 +02:00
|
|
|
case FS_OPCODE_PACK:
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
2014-06-23 22:07:20 -07:00
|
|
|
case SHADER_OPCODE_INT_QUOTIENT:
|
|
|
|
|
case SHADER_OPCODE_INT_REMAINDER:
|
2015-04-24 13:14:56 -07:00
|
|
|
/* FINISHME: Promote non-float constants and remove this. */
|
2021-03-29 14:41:58 -07:00
|
|
|
if (devinfo->ver < 8)
|
2015-04-24 13:14:56 -07:00
|
|
|
break;
|
2021-04-10 17:11:58 +02:00
|
|
|
FALLTHROUGH;
|
2015-04-24 13:14:56 -07:00
|
|
|
case SHADER_OPCODE_POW:
|
2016-06-03 12:32:15 -07:00
|
|
|
/* Allow constant propagation into src1 (except on Gen 6 which
|
|
|
|
|
* doesn't support scalar source math), and let constant combining
|
2016-05-27 23:29:14 -07:00
|
|
|
* promote the constant on Gen < 8.
|
2015-03-16 17:53:34 -07:00
|
|
|
*/
|
2021-03-29 14:41:58 -07:00
|
|
|
if (devinfo->ver == 6)
|
2016-06-03 12:32:15 -07:00
|
|
|
break;
|
2021-04-10 17:11:58 +02:00
|
|
|
FALLTHROUGH;
|
2013-11-26 13:49:31 -08:00
|
|
|
case BRW_OPCODE_BFI1:
|
|
|
|
|
case BRW_OPCODE_ASR:
|
2013-08-05 15:17:04 -07:00
|
|
|
case BRW_OPCODE_SHL:
|
|
|
|
|
case BRW_OPCODE_SHR:
|
2013-09-19 13:01:08 -07:00
|
|
|
case BRW_OPCODE_SUBB:
|
2013-08-05 15:17:04 -07:00
|
|
|
if (i == 1) {
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2013-08-05 15:17:04 -07:00
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2013-03-15 14:21:30 -07:00
|
|
|
case BRW_OPCODE_MACH:
|
2012-09-21 13:11:54 +02:00
|
|
|
case BRW_OPCODE_MUL:
|
2015-08-04 19:04:55 +03:00
|
|
|
case SHADER_OPCODE_MULH:
|
2012-09-21 13:11:54 +02:00
|
|
|
case BRW_OPCODE_ADD:
|
2013-08-05 15:17:04 -07:00
|
|
|
case BRW_OPCODE_OR:
|
|
|
|
|
case BRW_OPCODE_AND:
|
|
|
|
|
case BRW_OPCODE_XOR:
|
2013-11-27 16:14:14 -08:00
|
|
|
case BRW_OPCODE_ADDC:
|
2012-09-21 13:11:54 +02:00
|
|
|
if (i == 1) {
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
} else if (i == 0 && inst->src[1].file != IMM) {
|
intel/fs: Fix constant propagation into 32x16 integer multiplication
Don't copy propagate the constant in situations like
mov(8) g8<1>D 0x7fffffffD
mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
On platforms that only have a 32x16 multiplier, this will 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 results in
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.
See also https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/104.
Previous to INTEL_shader_integer_functions2 (in Vulkan or OpenGL), I
don't think it would be possible to create a situation where this could
occur. I discovered this via some optimizations that can determine that
the non-constant source must be able to fit in 16-bits. The case listed
above came from piglit's "ext_transform_feedback-order arrays points"
with those optimizations in place.
No shader-db or fossil-db changes on any Intel platform.
Fixes: de6c0f84879 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
2022-02-08 13:26:13 -08:00
|
|
|
/* Don't copy propagate the constant in situations like
|
|
|
|
|
*
|
|
|
|
|
* mov(8) g8<1>D 0x7fffffffD
|
|
|
|
|
* mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
|
|
|
|
|
*
|
|
|
|
|
* On platforms that only have a 32x16 multiplier, this will
|
|
|
|
|
* 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
|
|
|
|
|
* results in
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
if (inst->opcode == BRW_OPCODE_MUL &&
|
|
|
|
|
type_sz(inst->src[1].type) < 4 &&
|
|
|
|
|
type_sz(val.type) == 4)
|
|
|
|
|
break;
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
/* Fit this constant in by commuting the operands.
|
2013-03-15 14:21:30 -07:00
|
|
|
* Exception: we can't do this for 32-bit integer MUL/MACH
|
2012-09-21 13:11:54 +02:00
|
|
|
* because it's asymmetric.
|
2015-05-14 22:23:22 -07:00
|
|
|
*
|
|
|
|
|
* 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.
|
2012-09-21 13:11:54 +02:00
|
|
|
*/
|
2015-05-14 22:23:22 -07:00
|
|
|
if (((inst->opcode == BRW_OPCODE_MUL &&
|
|
|
|
|
inst->dst.is_accumulator()) ||
|
2013-03-15 14:21:30 -07:00
|
|
|
inst->opcode == BRW_OPCODE_MACH) &&
|
2012-09-21 13:11:54 +02:00
|
|
|
(inst->src[1].type == BRW_REGISTER_TYPE_D ||
|
|
|
|
|
inst->src[1].type == BRW_REGISTER_TYPE_UD))
|
|
|
|
|
break;
|
|
|
|
|
inst->src[0] = inst->src[1];
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[1] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case BRW_OPCODE_CMP:
|
|
|
|
|
case BRW_OPCODE_IF:
|
|
|
|
|
if (i == 1) {
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
} else if (i == 0 && inst->src[1].file != IMM) {
|
2014-06-29 17:50:20 -07:00
|
|
|
enum brw_conditional_mod new_cmod;
|
2012-09-21 13:11:54 +02:00
|
|
|
|
|
|
|
|
new_cmod = brw_swap_cmod(inst->conditional_mod);
|
2014-08-11 11:12:43 -07:00
|
|
|
if (new_cmod != BRW_CONDITIONAL_NONE) {
|
2012-09-21 13:11:54 +02:00
|
|
|
/* Fit this constant in by swapping the operands and
|
|
|
|
|
* flipping the test
|
|
|
|
|
*/
|
|
|
|
|
inst->src[0] = inst->src[1];
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[1] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
inst->conditional_mod = new_cmod;
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case BRW_OPCODE_SEL:
|
|
|
|
|
if (i == 1) {
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
2019-10-29 17:02:46 -07:00
|
|
|
} else if (i == 0 && 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)) {
|
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;
|
2012-09-21 13:11:54 +02: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;
|
|
|
|
|
}
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2016-04-29 23:36:59 -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 (i != FB_WRITE_LOGICAL_SRC_SRC_STENCIL &&
|
|
|
|
|
i != FB_WRITE_LOGICAL_SRC_OMASK) {
|
|
|
|
|
inst->src[i] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
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_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_CMS_W_LOGICAL:
|
2020-07-07 23:54:00 -07:00
|
|
|
case SHADER_OPCODE_TXF_CMS_W_GFX12_LOGICAL:
|
2016-04-29 23:36:59 -07:00
|
|
|
case SHADER_OPCODE_TXF_UMS_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TXF_MCS_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_LOD_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_TG4_OFFSET_LOGICAL:
|
2020-09-02 15:24:01 -05:00
|
|
|
case SHADER_OPCODE_SAMPLEINFO_LOGICAL:
|
|
|
|
|
case SHADER_OPCODE_IMAGE_SIZE_LOGICAL:
|
2016-04-29 23:36:59 -07:00
|
|
|
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:
|
2017-07-01 08:16:01 +02:00
|
|
|
case SHADER_OPCODE_BYTE_SCATTERED_WRITE_LOGICAL:
|
2017-07-01 08:19:17 +02:00
|
|
|
case SHADER_OPCODE_BYTE_SCATTERED_READ_LOGICAL:
|
2016-04-29 23:36:59 -07:00
|
|
|
inst->src[i] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
2012-11-07 10:42:34 -08:00
|
|
|
case FS_OPCODE_UNIFORM_PULL_CONSTANT_LOAD:
|
2015-02-19 14:52:24 +02:00
|
|
|
case SHADER_OPCODE_BROADCAST:
|
2014-09-19 20:36:52 -07:00
|
|
|
inst->src[i] = val;
|
2012-09-21 13:11:54 +02:00
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
2014-10-26 22:07:06 -07:00
|
|
|
case BRW_OPCODE_MAD:
|
|
|
|
|
case BRW_OPCODE_LRP:
|
|
|
|
|
inst->src[i] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
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
|
|
|
case FS_OPCODE_PACK_HALF_2x16_SPLIT:
|
|
|
|
|
inst->src[i] = val;
|
|
|
|
|
progress = true;
|
|
|
|
|
break;
|
|
|
|
|
|
2012-09-21 13:11:54 +02:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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 &&
|
2016-09-01 21:20:18 -07:00
|
|
|
!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 &&
|
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. */
|
|
|
|
|
!((inst->predicate && inst->opcode != BRW_OPCODE_SEL) ||
|
|
|
|
|
!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.
|
|
|
|
|
*/
|
|
|
|
|
bool
|
2016-11-28 10:45:08 -08:00
|
|
|
fs_visitor::opt_copy_propagation_local(void *copy_prop_ctx, bblock_t *block,
|
|
|
|
|
exec_list *acp)
|
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. */
|
2014-03-17 10:39:43 -07:00
|
|
|
for (int i = 0; i < inst->sources; 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
|
|
|
|
2015-10-26 04:35:14 -07:00
|
|
|
foreach_in_list(acp_entry, entry, &acp[inst->src[i].nr % ACP_HASH_SIZE]) {
|
2014-09-23 17:22:09 -07:00
|
|
|
if (try_constant_propagate(inst, entry))
|
2012-09-21 16:06:17 +02:00
|
|
|
progress = true;
|
2016-02-26 17:28:03 -08:00
|
|
|
else if (try_copy_propagate(inst, i, entry))
|
2012-09-21 16:06:17 +02:00
|
|
|
progress = true;
|
|
|
|
|
}
|
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) {
|
2015-10-26 04:35:14 -07:00
|
|
|
foreach_in_list_safe(acp_entry, entry, &acp[inst->dst.nr % ACP_HASH_SIZE]) {
|
2016-09-07 13:38:20 -07:00
|
|
|
if (regions_overlap(entry->dst, entry->size_written,
|
|
|
|
|
inst->dst, inst->size_written))
|
2016-03-11 14:35:07 +01:00
|
|
|
entry->remove();
|
|
|
|
|
}
|
2012-09-21 16:06:17 +02:00
|
|
|
|
|
|
|
|
/* Oops, we only have the chaining hash based on the destination, not
|
|
|
|
|
* the source, so walk across the entire table.
|
|
|
|
|
*/
|
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 < ACP_HASH_SIZE; i++) {
|
2014-06-24 16:31:38 -07:00
|
|
|
foreach_in_list_safe(acp_entry, entry, &acp[i]) {
|
2016-03-11 14:35:07 +01:00
|
|
|
/* Make sure we kill the entry if this instruction overwrites
|
|
|
|
|
* _any_ of the registers that it reads
|
|
|
|
|
*/
|
2016-09-07 17:00:07 -07:00
|
|
|
if (regions_overlap(entry->src, entry->size_read,
|
2016-09-07 13:38:20 -07:00
|
|
|
inst->dst, inst->size_written))
|
2012-09-21 16:06:17 +02:00
|
|
|
entry->remove();
|
|
|
|
|
}
|
|
|
|
|
}
|
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)) {
|
2019-12-30 00:36:48 -08:00
|
|
|
acp_entry *entry = rzalloc(copy_prop_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;
|
2014-07-03 04:14:39 -07:00
|
|
|
entry->saturate = 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
|
|
|
entry->is_partial_write = inst->is_partial_write();
|
2015-10-26 04:35:14 -07:00
|
|
|
acp[entry->dst.nr % ACP_HASH_SIZE].push_tail(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;
|
2016-10-11 13:48:16 +03:00
|
|
|
acp_entry *entry = rzalloc(copy_prop_ctx, acp_entry);
|
2022-09-27 15:28:48 -07:00
|
|
|
entry->dst = byte_offset(retype(inst->dst, t), offset);
|
|
|
|
|
entry->src = retype(inst->src[i], t);
|
2016-09-07 13:38:20 -07:00
|
|
|
entry->size_written = size_written;
|
2016-09-07 17:00:07 -07:00
|
|
|
entry->size_read = inst->size_read(i);
|
2014-04-17 15:13:00 -07:00
|
|
|
entry->opcode = inst->opcode;
|
|
|
|
|
if (!entry->dst.equals(inst->src[i])) {
|
2015-10-26 04:35:14 -07:00
|
|
|
acp[entry->dst.nr % ACP_HASH_SIZE].push_tail(entry);
|
2014-04-17 15:13:00 -07:00
|
|
|
} else {
|
|
|
|
|
ralloc_free(entry);
|
|
|
|
|
}
|
|
|
|
|
}
|
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
|
2016-11-28 10:45:08 -08:00
|
|
|
fs_visitor::opt_copy_propagation()
|
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);
|
2014-07-11 21:24:02 -07:00
|
|
|
exec_list *out_acp[cfg->num_blocks];
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < cfg->num_blocks; i++)
|
2013-01-08 12:46:05 -08:00
|
|
|
out_acp[i] = new exec_list [ACP_HASH_SIZE];
|
2012-05-08 13:01:52 -07:00
|
|
|
|
2016-03-13 16:25:57 -07:00
|
|
|
const fs_live_variables &live = 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.
|
|
|
|
|
*/
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
2016-11-28 10:45:08 -08:00
|
|
|
progress = opt_copy_propagation_local(copy_prop_ctx, block,
|
|
|
|
|
out_acp[block->num]) || 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.
|
|
|
|
|
*/
|
|
|
|
|
for (unsigned a = 0; a < ACP_HASH_SIZE; a++) {
|
|
|
|
|
foreach_in_list_safe(acp_entry, entry, &out_acp[block->num][a]) {
|
|
|
|
|
assert(entry->dst.file == VGRF);
|
2016-03-13 16:25:57 -07:00
|
|
|
if (block->start_ip <= live.vgrf_start[entry->dst.nr] &&
|
|
|
|
|
live.vgrf_end[entry->dst.nr] <= block->end_ip)
|
2019-05-04 23:51:23 -05:00
|
|
|
entry->remove();
|
|
|
|
|
}
|
|
|
|
|
}
|
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. */
|
2016-03-13 16:25:57 -07:00
|
|
|
fs_copy_prop_dataflow dataflow(copy_prop_ctx, 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.
|
|
|
|
|
*/
|
2014-07-11 22:31:39 -07:00
|
|
|
foreach_block (block, cfg) {
|
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
|
|
|
exec_list in_acp[ACP_HASH_SIZE];
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < dataflow.num_acp; i++) {
|
2014-07-11 22:31:39 -07:00
|
|
|
if (BITSET_TEST(dataflow.bd[block->num].livein, 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];
|
2015-10-26 04:35:14 -07:00
|
|
|
in_acp[entry->dst.nr % ACP_HASH_SIZE].push_tail(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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-11-28 10:45:08 -08:00
|
|
|
progress = opt_copy_propagation_local(copy_prop_ctx, block, in_acp) ||
|
|
|
|
|
progress;
|
2012-05-08 13:01:52 -07:00
|
|
|
}
|
|
|
|
|
|
2014-07-11 21:24:02 -07:00
|
|
|
for (int i = 0; i < cfg->num_blocks; i++)
|
2013-01-08 12:46:05 -08:00
|
|
|
delete [] out_acp[i];
|
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)
|
2016-03-13 19:26:37 -07:00
|
|
|
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;
|
|
|
|
|
}
|