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

[Bas Nieuwenhuizen]

On Tue, Apr 10, 2018 at 12:37 AM, Rob Clark <robdclark at gmail.com> wrote:
> 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

Yeah I was aware of that. Given this discussions I've actually run
some numbers for radv with a cold shader cache:

time total: 76.507337 sec
spirv 1.625971 sec
nir_to_llvm 10.146195 sec
llvm 46.058714 sec

hence total - spirv - nir_to_llvm - llvm = ~18.7 sec which is mostly due to nir.

Honestly a lot less than I expected, looks like the LLVM stuff is
spread over more functions and hence the nir stuff is higher in my
profiles.
>
> BR,
> -R