<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott <<a href="mailto:cwabbott0@gmail.com">cwabbott0@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 7:57 PM Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
><br>
> st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.<br>
><br>
> nir_validate_shader 49%<br>
><br>
> nir_validate_shader is overused. It doesn't make sense even in debug builds.<br>
<br>
tbh, I like nir_validate enabled when I do piglit/deqp runs.. and I<br>
already do separate release vs debug builds (which meson kinda<br>
encourages by disallowing in-tree builds in the first place, but is<br>
totally possible with autotools builds).. I kinda think benchmarking<br>
debug build in the first place is a flawed process.<br>
<br>
So I wouldn't profile/benchmark nir vs tgsi (or really anything) with<br>
debug builds.. I could get behind a separate compiler-debug option<br>
that changed the default NIR_VALIDATE setting and maybe some other nir<br>
debug features to get some features of debug builds without enabling<br>
the heavier nir debug features.  But other than making debug options a<br>
bit more fine grained, I wouldn't change things in response to a<br>
flawed benchmarking process..<br></blockquote><div><br></div><div>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.<br></div></div></div></blockquote><div><br></div><div>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...).<br></div></div></div></blockquote><div><br></div><div>Assertions and other debug code really don't cost much, so I don't see a reason to undef DEBUG.</div><div><br></div><div>Marek</div></div></div>