On 21/2/19 2:32 am, Marek Olšák wrote:
On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott <cwabbo...@gmail.com
<mailto:cwabbo...@gmail.com>> wrote:
On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> wrote:
On Tue, Feb 19, 2019 at 7:57 PM Rob Clark <robdcl...@gmail.com
<mailto:robdcl...@gmail.com>> wrote:
On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák
<mar...@gmail.com <mailto:mar...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
