[Mesa-dev] A few NIR compile time optimisations

[Timothy Arceri]

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
>             benchmarking
>             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
>             option
>             that changed the default NIR_VALIDATE setting and maybe some
>             other nir
>             debug features to get some features of debug builds without
>             enabling
>             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.

> 
> Marek