[Mesa-dev] [PATCH v3 002/104] nir: Add a deref instruction type

[Rob Clark]

On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> Rather lively discussion we've got going here...
>
> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark <robdclark at gmail.com> wrote:
>>
>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen
>> <bas at basnieuwenhuizen.nl> wrote:
>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark <robdclark at gmail.com> wrote:
>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen
>> >> <bas at basnieuwenhuizen.nl> wrote:
>> >>>
>> >>> You mean insert it into the fatptr every time deref_cast is called?
>> >>>
>> >>> Wouldn't that blow up the IR size significantly for very little
>> >>> benefit?
>> >>
>> >> in an easy to clean up way, so meh?
>> >
>> > We can't clean it up if we want to keep the information. Also nir is
>> > pretty slow to compile already, so I'd like not to add a significant
>> > number of instruction for very little benefit.
>
>
> Really?  I mean, I can believe it, but do you have any actual numbers to
> back this up?  It's considerably faster than some other IRs we have in mesa
> though they are known to be pretty big pigs if we're honest.  I'm very open
> to any suggestions on how to improve compile times.  If NIR is fundamentally
> a pig, we should fix that.
>

just a side-note, I guess mostly obvious but just pointing it out
because it has caught others by surprise.  Debug mesa builds by
default run nir_validate after every pass (unless you NIR_VALIDATE=0).
And this adds a *lot* of overhead (for a *lot* of debugging benefit)..

But if nir seems slow when running shader-db/etc, if you are using a
debug build at least make sure to NIR_VALIDATE=0 (or better yet use a
release build) when measuring performance

BR,
-R