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 BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
