[Mesa-dev] [PATCH 4/6] i965/fs: Optimize IF/MOV/ELSE/MOV/ENDIF to SEL when possible.

Rob Clark robdclark at gmail.com
Tue Sep 3 07:25:52 PDT 2013


On Tue, Aug 6, 2013 at 3:24 PM, Christoph Bumiller
<e0425955 at student.tuwien.ac.at> wrote:
> On 06.08.2013 19:19, Matt Turner wrote:
>> On Tue, Aug 6, 2013 at 4:14 AM, Christoph Bumiller
>> <e0425955 at student.tuwien.ac.at> wrote:
>>> On 06.08.2013 03:28, Kenneth Graunke wrote:
>>>> Many GLSL shaders contain code of the form:
>>>>
>>>>    x = condition ? foo : bar
>>>>
>>>> The compiler emits an ir_if tree for this, since each subexpression
>>>> might be a complex tree that could have side-effects and short-circuit
>>>> logic operations.
>>>>
>>>> However, the common case is to simply pick one of two constants or
>>>> variable's values---which is exactly what SEL is for.  Replacing IF/ELSE
>>>> with SEL also simplifies the control flow graph, making optimization
>>>> passes which work on basic blocks more effective.
>>>>
>>> Don't you think something like that should be implemented in common code
>>> so that all drivers can profit ?
>> We would love that. As part of an work in progress, I'm adding
>> conditional-select to the GLSL IR. We planned a few months ago to do
>> this as a step toward SSA at the IR level, but have only laid a little
>> bit of groundwork in that direction (Ian's vector insert/extract
>> series).
>>
>> Looks like your backend already does SSA. Shouldn't that be
>> implemented in common code? :)
>
> Then the code would have to run on GLSL IR as well as my internal IR
> because the intermediate one, TGSI, shouldn't be in SSA form, and
> abstracting an IR doesn't sound particularly fun.

btw, I'd *love* an option to get TGSI in SSA form (or at least a form
easier to turn back into SSA)..  it is starting to look like doing
anything vaguely clever w/ freedreno compiler will require essentially
turning TGSI into SSA, and I guess other drivers will need the same.
(Tegra will for sure, for if/else/endif in frag shader.  But I guess
it would be useful to others.)

I guess add TGSI_OPCODE_PHI plus maybe some hint or instruction to
indicate when a register is no longer used (maybe not needed, but
otherwise maybe for large programs tgsi_{src,dst}_register.Index might
overflow?).

BR,
-R

> Also I don't have to handle vectors so it's a bit simpler, actually
> pretty straightforward if you implement an existing algorithm.
> As for some other passes that could be shared, I still need them in the
> backend to be applied to device-specifc code sequences, you probably
> have a similar situation.
>
>>> It would be really nice to have more, useful device-independent
>>> optimizations or simplifications like this already done instead of
>>> requiring each driver to re-implement them (or use llvm).
>> Yes, it definitely would.
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list