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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
