Commit graph

23 commits

Author SHA1 Message Date
Jason Ekstrand
80e8dfe9de nir: Rename Boolean-related opcodes to include 32 in the name
This is a squash of a bunch of individual changes:

    nir/builder: Generate 32-bit bool opcodes transparently

    nir/algebraic: Remap Boolean opcodes to the 32-bit variant

    Use 32-bit opcodes in the NIR producers and optimizations

        Generated with a little hand-editing and the following sed commands:

        sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c
        sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c
        sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c
        sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c
        sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c
        sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c

     Use 32-bit opcodes in the NIR back-ends

        Generated with a little hand-editing and the following sed commands:

        sed -i 's/nir_op_ball_fequal/nir_op_b32all_fequal/g' **/*.c
        sed -i 's/nir_op_bany_fnequal/nir_op_b32any_fnequal/g' **/*.c
        sed -i 's/nir_op_ball_iequal/nir_op_b32all_iequal/g' **/*.c
        sed -i 's/nir_op_bany_inequal/nir_op_b32any_inequal/g' **/*.c
        sed -i 's/nir_op_\([fiu]lt\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]ge\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]ne\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fiu]eq\)/nir_op_\132/g' **/*.c
        sed -i 's/nir_op_\([fi]\)ne32g/nir_op_\1neg/g' **/*.c
        sed -i 's/nir_op_bcsel/nir_op_b32csel/g' **/*.c

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
2018-12-16 21:03:02 +00:00
Timothy Arceri
a2ec78883f nir: fix opt_if_loop_last_continue()
The pass did not correctly handle loops ending in:

	if ssa_7 {
		block block_8:
		/* preds: block_7 */
		continue
		/* succs: block_1 */
	} else {
		block block_9:
		/* preds: block_7 */
		break
		/* succs: block_11 */
	}

The break will get eliminated by another opt but if this pass gets
called first (as it does on RADV) we ended up inserting
instructions after the break.

Fixes: 5921a19d4b ("nir: add if opt opt_if_loop_last_continue()")
Reviewed-by: Dave Airlie <airlied@redhat.com>
2018-12-14 17:21:35 +11:00
Danylo Piliaiev
5921a19d4b nir: add if opt opt_if_loop_last_continue()
Removing the last continue can allow more loops to unroll. Also
inserting code into the if branch can allow the various if opts
to progress further.

The insertion of some loops into the if branch also reduces VGPR
use in some shaders.

vkpipeline-db results (VEGA):

Totals from affected shaders:
SGPRS: 6552 -> 6576 (0.37 %)
VGPRS: 6544 -> 6532 (-0.18 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 481952 -> 478032 (-0.81 %) bytes
LDS: 13 -> 13 (0.00 %) blocks
Max Waves: 241 -> 242 (0.41 %)
Wait states: 0 -> 0 (0.00 %)

Shader-db results radeonsi (VEGA):

Totals from affected shaders:
SGPRS: 168 -> 168 (0.00 %)
VGPRS: 144 -> 140 (-2.78 %)
Spilled SGPRs: 157 -> 157 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Private memory VGPRs: 0 -> 0 (0.00 %)
Scratch size: 0 -> 0 (0.00 %) dwords per thread
Code Size: 8524 -> 8488 (-0.42 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 7 -> 7 (0.00 %)
Wait states: 0 -> 0 (0.00 %)

v2: (Timothy Arceri):
- allow for continues in either branch
- move any trailing loops inside the if as well as blocks.
- leave nir_opt_trivial_continues() to actually remove the
  continue.

Reviewed-by: Thomas Helland <thomashelland90@gmail.com>
Signed-off-by: Timothy Arceri <tarceri@itsqueeze.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32211
2018-12-13 10:58:35 +11:00
Jason Ekstrand
dca6cd9ce6 nir: Make boolean conversions sized just like the others
Instead of a single i2b and b2i, we now have i2b32 and b2iN where N is
one if 8, 16, 32, or 64.  This leads to having a few more opcodes but
now everything is consistent and booleans aren't a weird special case
anymore.

Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
2018-12-05 15:03:07 -06:00
Timothy Arceri
769ae9fb7f nir: fix condition propagation when src has a swizzle
We cannot use nir_build_alu() to create the new alu as it has no
way to know how many components of the src we will use. This
results in it guessing the max number of components from one of
its inputs.

Fixes the following CTS tests:

dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_frag
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_geom
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_tessc
dEQP-VK.spirv_assembly.instruction.graphics.selection_block_order.out_of_order_vert

Fixes: 2975422ceb ("nir: propagates if condition evaluation down some alu chains")

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-11-03 00:44:01 +11:00
Timothy Arceri
c7bdda8aa5 nir: allow propagation of if evaluation for bcsel
Shader-db results Skylake:

total instructions in shared programs: 13109035 -> 13109024 (<.01%)
instructions in affected programs: 4777 -> 4766 (-0.23%)
helped: 11
HURT: 0

total cycles in shared programs: 332090418 -> 332090443 (<.01%)
cycles in affected programs: 19474 -> 19499 (0.13%)
helped: 6
HURT: 4

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-11-02 15:56:34 +11:00
Timothy Arceri
5b757b4097 nir: fix if condition propagation for alu use
We need to update the cursor before we check if the alu use is
dominated by the if condition. Previously we were checking if
the current location of the alu instruction was dominated by
the if condition which would miss some optimisation opportunities.

Fixes: a3b4cb3458 ("nir/opt_if: Rework condition propagation")

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-11-01 09:22:55 +11:00
Brian Paul
7e64e39f8b nir: Fix array initializer
Empty initializer is not standard C.  This fixes MSVC build.

Trivial.
2018-10-26 12:35:48 -06:00
Jason Ekstrand
a3b4cb3458 nir/opt_if: Rework condition propagation
Instead of doing our own constant folding, we just emit instructions and
let constant folding happen.  This is substantially simpler and lets us
use the nir_imm_bool helper instead of dealing with the const_value's
ourselves.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
2018-10-26 11:45:29 -05:00
Eric Engestrom
e27902a261 util: use C99 declaration in the for-loop set_foreach() macro
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
2018-10-25 12:43:18 +01:00
Jason Ekstrand
864c780566 nir/opt_if: Re-materialize derefs in use blocks before peeling loops
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107879
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
2018-09-19 02:00:49 -05:00
Timothy Arceri
2975422ceb nir: propagates if condition evaluation down some alu chains
v2:
 - only allow nir_op_inot or nir_op_b2i when alu input is 1.
 - use some helpers as suggested by Jason.

v3:
 - evaluate alu op for single input alu ops
 - add helper function to decide if to propagate through alu
 - make use of nir_before_src in another spot

shader-db IVB results:

total instructions in shared programs: 9993483 -> 9993472 (-0.00%)
instructions in affected programs: 1300 -> 1289 (-0.85%)
helped: 11
HURT: 0

total cycles in shared programs: 219476091 -> 219476059 (-0.00%)
cycles in affected programs: 7675 -> 7643 (-0.42%)
helped: 10
HURT: 1

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-09-14 16:07:36 +10:00
Timothy Arceri
ef4ad7baf1 nir: evaluate if condition uses inside the if branches
Since we know what side of the branch we ended up on we can just
replace the use with a constant.

All the spill changes in shader-db are from Dolphin uber shaders,
despite some small regressions the change is clearly positive.

V2: insert new constant after any phis in the
    use->parent_instr->type == nir_instr_type_phi path.

v3:
 - use nir_after_block_before_jump() for inserting const
 - check dominance of phi uses correctly

v4:
 - create some helpers as suggested by Jason.

v5 (Jason Ekstrand):
 - Use LIST_ENTRY to get the phi src

shader-db results IVB:

total instructions in shared programs: 9999201 -> 9993483 (-0.06%)
instructions in affected programs: 163235 -> 157517 (-3.50%)
helped: 132
HURT: 2

total cycles in shared programs: 231670754 -> 219476091 (-5.26%)
cycles in affected programs: 143424120 -> 131229457 (-8.50%)
helped: 115
HURT: 24

total spills in shared programs: 4383 -> 4370 (-0.30%)
spills in affected programs: 1656 -> 1643 (-0.79%)
helped: 9
HURT: 18

total fills in shared programs: 4610 -> 4581 (-0.63%)
fills in affected programs: 374 -> 345 (-7.75%)
helped: 6
HURT: 0

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-09-14 16:07:36 +10:00
Kai Wasserbäch
6f0647c0b2 nir: mark *prev_block as MAYBE_UNUSED in opt_peel_loop_initial_if
Only used, when asserts are enabled.

Fixes an unused-variable warning with gcc-8:
 ../../../src/compiler/nir/nir_opt_if.c: In function 'opt_peel_loop_initial_if':
 ../../../src/compiler/nir/nir_opt_if.c:109:15: warning: unused variable 'prev_block' [-Wunused-variable]
     nir_block *prev_block =
                ^~~~~~~~~~

Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
2018-08-18 10:34:15 +10:00
Bas Nieuwenhuizen
e1febbefe8 nir: Fix end of function without return warning/error.
There always is a continue block, so let us just do unreachable.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 8cacf38f52 "nir: Do not use continue block after removing it."
CC: 18.1 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107312
2018-07-20 22:27:39 +02:00
Bas Nieuwenhuizen
8cacf38f52 nir: Do not use continue block after removing it.
Reinserting code directly before a jump means the block gets split
and merged, removing the original block and replacing it in the
process.

Hence keeping a pointer to the continue block over a reinsert
causes issues.

This code changes nir_opt_if to simply look for the new continue
block.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107275
CC: 18.1 <mesa-stable@lists.freedesktop.org>
2018-07-20 12:09:19 +02:00
Caio Marcelo de Oliveira Filho
1f6ce1973a nir: delete not needed for reinserted nir_cf_list
It wasn't causing problems since there's nothing to delete, but better
be consistent with the rest of existing codebase.

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2018-07-12 14:03:51 -07:00
Jason Ekstrand
ff6db94c18 nir/opt_if: Remove unneeded phis if we make progress
Now that SSA values can be derefs and they have special rules, we have
to be a bit more careful about our LCSSA phis.  In particular, we need
to clean up in case LCSSA ended up creating a phi node for a deref.
This fixes validation issues with some Vulkan CTS tests with the new
deref instructions.

Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
2018-06-26 10:47:26 -07:00
Timothy Arceri
2a74296f24 nir: add opt_if_loop_terminator()
This pass detects potential loop terminators and moves intructions
from the non breaking branch after the if-statement.

This enables both the new opt_if_simplification() pass and loop
unrolling to potentially progress further.

Unexpectedly this change speed up shader-db run times by ~3%

Ivy Bridge shader-db results (all changes in dolphin/ubershaders):

total instructions in shared programs: 9995662 -> 9995338 (-0.00%)
instructions in affected programs: 87845 -> 87521 (-0.37%)
helped: 27
HURT: 0

total cycles in shared programs: 230931495 -> 230925015 (-0.00%)
cycles in affected programs: 56391385 -> 56384905 (-0.01%)
helped: 27
HURT: 0

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2018-06-07 11:33:04 +10:00
Samuel Pitoiset
e3e929f8c3 nir: implement the GLSL equivalent of if simplication in nir_opt_if
This pass turns:

   if (cond) {
   } else {
      do_work();
   }

into:

   if (!cond) {
      do_work();
   } else {
   }

Here's the vkpipeline-db stats (from affected shaders) on Polaris10:

Totals from affected shaders:
SGPRS: 17272 -> 17296 (0.14 %)
VGPRS: 18712 -> 18740 (0.15 %)
Spilled SGPRs: 1179 -> 1142 (-3.14 %)
Code Size: 1503364 -> 1515176 (0.79 %) bytes
Max Waves: 916 -> 911 (-0.55 %)

This pass only affects Serious Sam 2017 (Vulkan) on my side. The
stats are not really good for now. Some shaders look quite dumb
but this will be improved with further NIR passes, like ifs
combination.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
2018-06-04 12:41:10 +02:00
Jason Ekstrand
fb181196de nir: Rename convert_to_ssa lower_regs_to_ssa
This matches the naming of nir_lower_vars_to_ssa, the other to-SSA pass.
2016-12-29 16:02:44 -08:00
Timothy Arceri
5f323198ea nir: stop gcc warning about uninitialised variables
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
2016-12-29 13:47:11 +11:00
Jason Ekstrand
6d9f576b56 nir: Add a pass for moving SPIR-V continue blocks to the ends of loops
When shaders come in from SPIR-V, we handle continue blocks by placing
the contents of the continue inside of a "if (!first_iteration)".  We do
this so that we can properly handle the fact that continues in SPIR-V
jump to the continue block at the end of the loop rather than jumping
directly to the top of the loop like they do in NIR.  In particular, the
increment step of a simple for loop ends up in the continue block.  This
pass looks for this case in loops that don't actually have any continues
and moves the continue contents to the end of the loop instead.  We need
this because loop unrolling doesn't work if the increment is inside of a
condition.

Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
2016-12-22 16:27:19 -08:00