[Mesa-dev] [PATCH 0/7] GLSL: Lowering small conditional branches

[Ian Romanick]

On 10/28/2016 04:13 PM, Marek Olšák wrote:
> Hi,
> 
> this series enables lowering small branches for radeonsi, but other
> drivers can enable it too. The GLSL compiler computes a cost per
> branch and then either lowers the branch if the cost is low enough,
> or keeps it.

As an aside...

When GLSL IR was first developed, we added support to ir_assignment so
that any assignment could be conditional.  We did this for a couple
reasons.  We know that many GPUs didn't have flow-control or only had
limited flow control.  We also believed that a conditional assignment
would be better for i965 due to its predicated architecture.  I don't
think this latter element has proven to be true... perhaps Matt or Ken
will have other data.

Conditional assignments have always been kind of a pain.  Several
optimization passes just bail if they see a conditional assignment.
Other passes have special code to handle conditional assignments.  All
the code generators do extra work to handle conditional assignments.

Quite some time later support was added for ir_triop_csel.  One project
that I've had on the back burner for literally years is to replace all
uses of conditional assignment with conditional selects.  Since
everything already supports conditional selects, this would let us
delete all the code for handling conditional assignments.  It would also
let us delete a pointer field from a common structure that is almost
always NULL.

To make this work, I think we'd need a fairly aggressive csel-merge
optimization pass.  NIR might already have something, but I'm pretty
sure GLSL IR does not.  We'd want to merge things like

   x = condition ? b : x;
   ...
   x = !condition ? c : x;

into

   x = condition ? b : c;

Maybe existing passes would merge the first two conditional selects to

   x = !condition ? c : (condition ? b : x);

and some simple optimization could do the rest.  It seems plausible.

We'd also have to make sure the code generators for architectures that
have conditional assignments are smart enough to generate a conditional
move for 'x = condition ? b : x'.  As far as I'm aware, the i965 code
generator is not smart enough.

> It will take some time before LLVM learns to do this too and that
> seems to be more involved, and we need a solution for Mesa now.
> 
> There are 4 piglit regressions, which could be an uncovered radeonsi
> bug. Softpipe is unaffected. We might hold off pushing the last patch
> depending on how serious the regressions are.
> 
> The reason why this is so important to us is that it reduces VGPR
> spilling:
>     Spilled VGPRs: 368 -> 96 (-73.91 %)
>     Scratch VGPRs: 1344 -> 1060 (-21.13 %) dwords per thread
> 
> Please review.
> 
> Marek
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev