On Mon, Apr 9, 2018 at 4:41 PM, Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl> wrote:
> On Tue, Apr 10, 2018 at 12:37 AM, Rob Clark <robdcl...@gmail.com> wrote: > > On Mon, Apr 9, 2018 at 1:35 AM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > >> Rather lively discussion we've got going here... > >> > >> On Sun, Apr 8, 2018 at 3:23 PM, Rob Clark <robdcl...@gmail.com> wrote: > >>> > >>> On Sun, Apr 8, 2018 at 5:54 PM, Bas Nieuwenhuizen > >>> <b...@basnieuwenhuizen.nl> wrote: > >>> > On Sun, Apr 8, 2018 at 11:40 PM, Rob Clark <robdcl...@gmail.com> > wrote: > >>> >> On Sun, Apr 8, 2018 at 5:20 PM, Bas Nieuwenhuizen > >>> >> <b...@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...
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
