[Mesa-dev] [PATCH] gallium: remove support for predicates from TGSI

[Marek Olšák]

On Tue, Aug 12, 2014 at 4:22 AM, Connor Abbott <cwabbott0 at gmail.com> wrote:
> On Mon, Aug 11, 2014 at 4:32 PM, Eric Anholt <eric at anholt.net> wrote:
>> Connor Abbott <cwabbott0 at gmail.com> writes:
>>
>>> On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else?
>>>
>>> It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL
>>> IR-like stuff to get existing things working now and enable us to
>>> eventually do linking in it (so we can use the same optimizations
>>> before linking and after). I was hoping to get a patch series out soon
>>> for discussion, and I've got an experimental i965 fs backend to try it
>>> out. It should be able to replace Mesa IR too, but that's not the
>>> primary goal - it's mostly to be able to do SSA-based optimizations in
>>> a backend-independent way. You can find a branch here:
>>>
>>> https://github.com/cwabbott0/mesa/tree/nir
>>>
>>> but I'd like to wait on discussing it until I put out some patches.
>>>
>>>>
>>>> It's more of a question of which gallium hardware drivers are going to
>>>> support it. I don't think there will be any eager candidates.
>>>
>>> AFAIK almost every HW out there supports predication in one form or
>>> another - why wouldn't it make sense for a higher level part of the
>>> compiler to do e.g. if-conversion based on cost estimates provided by
>>> the driver, similar to how LLVM handles vectorization? That way, it
>>> can take advantage of the fact that things are predicated by being
>>> more aggressive with optimizations like code motion, CSE, etc. -
>>> that's why I originally added support for predication to NIR. Also,
>>> I'm sure that drivers that don't support control flow (i.e. vc4) will
>>> like having the frontend do if-conversion for them and pass along the
>>> predicated code - Eric?
>>
>> I'd be much more likely to eat whatever TGSI is generated, generate NIR,
>> and then do lowering to predicated moves in NIR.
>
> Well at that point, assuming NIR is turned on in the frontend, you'd
> be going GLSL IR -> NIR -> TGSI -> NIR -> your backend... might be
> easier to just rip out TGSI altogether. This would also benefit other
> drivers that already use SSA, since we can avoid the round-trip of
> going out of and back into SSA since TGSI doesn't support SSA.

It's nearly impossible to get rid of TGSI now. Too many things depend
on it. It's the most used IR in Mesa. If somebody is planning to do
optimizations in the backend, I recommend this:

GLSL IR (no optimizations) -> TGSI -> NIR -> your backend

Marek