[Mesa-dev] A few NIR compile time optimisations
maraeo at gmail.com
Wed Feb 20 15:32:46 UTC 2019
On Wed, Feb 20, 2019 at 2:31 AM Connor Abbott <cwabbott0 at gmail.com> wrote:
> On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák <maraeo at gmail.com> wrote:
>> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark <robdclark at gmail.com> wrote:
>>> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák <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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev