intel/vec4: Allow late copy propagation on vec4
This change incurs a small amount of hurt now, but it enables a lot of benefit on vec4 shaders on the next commit. nir_opt_algebraic_late converts dph, dot3, etc. to dhp_replicated, dot_replicated3, etc. In the process, it introduces extra moves. If the original NIR contained vec1 32 ssa_45 = fdot4 ssa_51, ssa_44 vec1 32 ssa_46 = fneg ssa_45 nir_opt_algebraic_late will produce vec4 32 ssa_18 = fdot_replicated4 ssa_1, ssa_15 vec1 32 ssa_19 = mov ssa_18.x vec1 32 ssa_17 = fneg ssa_19 The algebraic pass added in the next commit can't see through the move to know that the fneg applies to a fdot_replicated4. Haswell, Ivy Bridge, and Sandybridge had similar results. (Haswell shown) total cycles in shared programs: 187077604 -> 187079858 (<.01%) cycles in affected programs: 350132 -> 352386 (0.64%) helped: 174 HURT: 194 helped stats (abs) min: 2 max: 124 x̄: 23.60 x̃: 16 helped stats (rel) min: 0.12% max: 15.88% x̄: 4.98% x̃: 3.86% HURT stats (abs) min: 2 max: 164 x̄: 32.78 x̃: 16 HURT stats (rel) min: 0.17% max: 22.82% x̄: 6.46% x̃: 0.86% 95% mean confidence interval for cycles value: 2.04 10.21 95% mean confidence interval for cycles %-change: 0.17% 1.93% Cycles are HURT. No shader-db changes on any other Intel platform. Reviewed-by: Matt Turner <mattst88@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1359>
This commit is contained in:
parent
0f4a81430e
commit
d2b4f3f137
|
@ -907,10 +907,10 @@ brw_postprocess_nir(nir_shader *nir, const struct brw_compiler *compiler,
|
|||
* havok on the vec4 backend. The handling of constants in the vec4
|
||||
* backend is not good.
|
||||
*/
|
||||
if (is_scalar) {
|
||||
if (is_scalar)
|
||||
OPT(nir_opt_constant_folding);
|
||||
OPT(nir_copy_prop);
|
||||
}
|
||||
|
||||
OPT(nir_copy_prop);
|
||||
OPT(nir_opt_dce);
|
||||
OPT(nir_opt_cse);
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue