[Mesa-dev] [PATCH 1/1] i965: Do not overwrite optimizer dumps

[Jason Ekstrand]

On Wed, Nov 25, 2015 at 10:49 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On Wednesday, November 25, 2015 10:31:24 AM Matt Turner wrote:
>> On Wed, Nov 25, 2015 at 4:15 AM, Juan A. Suarez Romero
>> <jasuarez at igalia.com> wrote:
>> > When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
>> > in a separate file.
>> >
>> > But as fs_visitor::optimize() and vec4_visitor::run() are called more
>> > than once, it ends up overwriting the files already on disk, loosing
>> > then previous optimizer steps.
>>
>> Huh. I guess this happens when non-orthogonal state changes and we
>> recompile the program?
>>
>> If so, yeah, that would lead to some confusing results.
>>
>> > To avoid this, add a new static variable that tracks the global
>> > iteration across the entire life of the program running.
>> > ---
>> >  src/mesa/drivers/dri/i965/brw_fs.cpp   | 13 +++++++++----
>> >  src/mesa/drivers/dri/i965/brw_vec4.cpp | 11 +++++++----
>> >  2 files changed, 16 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > index 29f19cc..9520a62 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> > @@ -4947,6 +4947,8 @@ fs_visitor::calculate_register_pressure()
>> >  void
>> >  fs_visitor::optimize()
>> >  {
>> > +   static int global_iteration = 0;
>>
>> I don't know that adding a static variable is the way to solve this. I
>> know this is debugging code, but using a static variable will make
>> this thread-unsafe, and I *really* don't want to end up in a situation
>> where I can't figure out what the optimizer is doing because we were
>> compiling shaders in parallel...
>>
>> Ken, any ideas?
>
> It almost seems like you want a hash of the program key - and maybe a
> file containing a printed copy of the key so you can identify which
> program is which.
>
> Alternatively, one could use the address of the key with %p to obtain
> a unique identifier.  That's easy and should solve the problem.

Unfortunately, the pointer is non-deterministic so comparing from one
run to another is going to be hard.  A quick-and-dirty hash of the key
might work though.