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

[Ilia Mirkin]

On Mon, Aug 11, 2014 at 1:31 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Sat, Aug 9, 2014 at 5:24 AM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>> 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'm not sure how predication in Gallium works - if it's old and crufty
>> compared to how drivers do things, then that's OK but I still think
>> it's useful to do some things with predication outside the driver.
>
> Let's be realistic here. There is not enough manpower to support new
> shader features like predicates in old radeon hardware drivers. The
> drivers have their own IR and optimization passes, which would need to
> be taught about predicates and that would a lot of (useless) work for
> uncertain gain. The current radeon hardware uses LLVM and the shader
> backend lives in the LLVM tree, not Mesa, so any low-level information
> like predicates will be destroyed during translation to the LLVM IR.
>
> If there is a gallium driver maintainer that would like to use
> predicates generated by Mesa core, please let me know. Right now I
> don't know of anybody.

Not to muddy the waters too much, but the nv50 ir supports predicates
and it would be very easy to support anything that TGSI supports in
there (in fact, I believe it already supports the ones that exist in
TGSI right now, although it's entirely untested).

At the same time, it will happily convert if/else's into predicated
logic if the blocks are short enough (and I saw a clever little trick
in nvidia-generated shaders that puts a vote/bra pair to jump to the
else block if the predicate is false for all invocations).

Not sure off-hand if nv30/nv40 has support for predicates, but it
doesn't have a compiler that can make any sort of clever
transformations like that, and nv30 (geforce fx) branches iirc. Could
be useful there, but... I doubt anyone can be bothered to care. The
driver only advertises GL 1.5 on nv3x.

I guess if the predicates are there, nv50 ir would be happy to use
them, but it's not a big deal either way since it'll generate them
anyways on its own.

  -ilia