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