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

[Jason Ekstrand]

On Mon, Apr 9, 2018 at 4:41 PM, Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
wrote:

> 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
>

Ok, that's more-or-less what I would have expected.  I'm a bit surprised
that spirv_to_nir is so expensive but there's some crazy juggling we have
to do in there.  We could probably improve it.


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

Which is only 40% of the time you spend in LLVM. :-)  If you're letting NIR
optimize, I expect it to take some real time but it doesn't look too bad.

I'm a bit surprised how long nir_to_llvm takes though...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180409/0d7ae3ea/attachment.html>