On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <[email protected]> wrote:

> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark <[email protected]> wrote:
>
>> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák <[email protected]> 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...).


>
> Marek
>
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to