[Mesa-dev] A few NIR compile time optimisations
tarceri at itsqueeze.com
Wed Feb 20 22:42:57 UTC 2019
On 21/2/19 2:32 am, Marek Olšák wrote:
> On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott <cwabbott0 at gmail.com
> <mailto:cwabbott0 at gmail.com>> wrote:
> On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <maraeo at gmail.com
> <mailto:maraeo at gmail.com>> wrote:
> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark <robdclark at gmail.com
> <mailto:robdclark at gmail.com>> wrote:
> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák
> <maraeo at gmail.com <mailto:maraeo at gmail.com>> wrote:
> > st_link_shader takes 55% of CPU time with NIR, and 9%
> with TGSI.
> > nir_validate_shader 49%
> > nir_validate_shader is overused. It doesn't make sense
> even in debug builds.
> tbh, I like nir_validate enabled when I do piglit/deqp
> runs.. and I
> already do separate release vs debug builds (which meson kinda
> encourages by disallowing in-tree builds in the first place,
> but is
> totally possible with autotools builds).. I kinda think
> debug build in the first place is a flawed process.
> So I wouldn't profile/benchmark nir vs tgsi (or really
> anything) with
> debug builds.. I could get behind a separate compiler-debug
> that changed the default NIR_VALIDATE setting and maybe some
> other nir
> debug features to get some features of debug builds without
> the heavier nir debug features. But other than making debug
> options a
> bit more fine grained, I wouldn't change things in response to a
> flawed benchmarking process..
> That's a harsh reaction to a relatively good benchmarking setup.
> I use debugoptimized with -DDEBUG. My performance is probably
> more affected by -fno-omit-frame-pointer than -DDEBUG.
> Why would you enable DEBUG in a profiling build? AFAIK it's supposed
> to enable validation more expensive than simple asserts, which you
> probably don't want in a benchmarking setup, although from grepping
> the source it's not used much. It might be a good idea to move
> running NIR validation behind DEBUG instead of !NDEBUG. In the
> meantime, unless you really want to benchmark things with assertions
> enabled in which case NIR_VALIDATE=0 works (but why would you?), you
> can set -Db_ndebug=false in Meson. I just saw today that they're
> enabled by default in debugoptimized builds (whoops, better go fix
> that and re-profile...).
> Assertions and other debug code really don't cost much, so I don't see a
> reason to undef DEBUG.
Besides what Eero already mentioned I'm not sure that is always a safe
assumption. This series itself moved some expensive checks (a bunch of
recursive loops) into an assert, and there are other examples of this
elsewhere in the compiler.
More information about the mesa-dev