[Mesa-dev] [RFCv0 0/8] gallium: add support for NIR as alternate IR

[Rob Clark]

On Tue, Oct 20, 2015 at 11:21 AM, Marek Olšák <maraeo at gmail.com> wrote:
> On Tue, Oct 20, 2015 at 5:17 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Tue, Oct 20, 2015 at 9:10 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Tue, Oct 20, 2015 at 2:37 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>> On Tue, Oct 20, 2015 at 6:49 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>> On Tue, Oct 20, 2015 at 3:51 AM, Rob Clark <robdclark at gmail.com> wrote:
>>>>>> On Mon, Oct 19, 2015 at 8:53 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>>>>> Yes, drivers need to "dup" tokens if they want to keep them. Their
>>>>>>> lifetime is the create function and that's it. st/mesa only keeps the
>>>>>>> tokens for vertex shaders, because it needs for emulating some
>>>>>>> features with the Draw module.
>>>>>>
>>>>>> It is something that I think would be worth revisiting, since the
>>>>>> common case is that drivers have to dup the tokens to do their own
>>>>>> variant mgmt.. so that seems like the better case to optimize for.  I
>>>>>> think the only one that isn't doing it's own variant mgmt is nouveau,
>>>>>> but Ilia mentioned at some point that there where some edge cases
>>>>>> where they really do need a variant.
>>>>>
>>>>> This would add more cruft into state trackers and modules. Doing "dup"
>>>>> in the driver is the easiest way to handle this.
>>>>>
>>>>> Also, drivers should be able to release any incoming IR if they don't
>>>>> need it. Including NIR. Having a requirement that some IR must be in
>>>>> memory for the lifetime of shaders is just overall a bad idea.
>>>>
>>>> If you need to create variants, you need to hang on to the IR until
>>>> all possible variants are created (ie. forever)
>>>
>>> Not true. You can convert to another IR, run lowering passes, and keep
>>> the result of that.
>>
>> On nvc0, I'm just patching up the binary code directly. I may or may
>> not be able to get away with doing that on nv50... my latest thinking
>> is that I can, but haven't implemented yet. Which will mean no
>> variants for nouveau *and* fully working logic for flat shading :)
>
> Yes, patching shader bytecode is the best way to deal with variants.
> I'd strongly recommend all drivers to do that, but it's not easy if
> the modifications are non-trivial.
>


and not easy if your isa requires instruction scheduling :-(

BR,
-R