[Mesa-dev] [PATCH 5/5] i965/fs: Debug the optimization passes by dumping instr to file.

Matt Turner mattst88 at gmail.com
Sun Apr 13 00:59:24 PDT 2014


On Sun, Apr 13, 2014 at 12:16 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> On 04/11/2014 10:29 PM, Matt Turner wrote:
>> With INTEL_DEBUG=optimizer, write the output of dump_instructions() to a
>> file each time an optimization pass makes progress. This lets you easily
>> diff successive files to see what an optimization pass did.
>>
>> Example filenames written when running glxgears:
>>    fs8-00-00-start
>>    fs8-00-01-04-opt_copy_propagate
>>    fs8-00-01-06-dead_code_eliminate
>>    fs8-00-01-12-compute_to_mrf
>>    fs8-00-02-06-dead_code_eliminate
>>        |   |  |   |
>>        |   |  |   `-- optimization pass name
>>        |   |  |
>>        |   |  `-- optimization pass number in the loop
>>        |   |
>>        |   `-- optimization loop interation
>>        |
>>        `-- shader program number
>>
>> Note that with INTEL_DEBUG=optimizer, we disable compact_virtual_grfs,
>> so that we can diff instruction lists across loop interations without
>> the register numbers being changes.
>> ---
>>  src/mesa/drivers/dri/i965/brw_fs.cpp | 56 +++++++++++++++++++++++++++---------
>>  1 file changed, 43 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index c1d79e1..666cfa5b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -1704,6 +1704,9 @@ fs_visitor::split_virtual_grfs()
>>  void
>>  fs_visitor::compact_virtual_grfs()
>>  {
>> +   if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER))
>> +      return;
>> +
>>     /* Mark which virtual GRFs are used, and count how many. */
>>     int remap_table[this->virtual_grf_count];
>>     memset(remap_table, -1, sizeof(remap_table));
>> @@ -3258,25 +3261,52 @@ fs_visitor::run()
>>
>>        opt_drop_redundant_mov_to_flags();
>>
>> +#define OPT(pass, args...)                                                 \
>> +   ({                                                                      \
>> +      pass_num++;                                                          \
>> +      bool progress = pass(args);                                          \
>> +                                                                           \
>> +      if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && progress) {           \
>> +         char filename[64];                                                \
>> +         snprintf(filename, 64, "fs%d-%02d-%02d-%02d-" #pass,              \
>> +                  dispatch_width, shader_prog->Name, iteration, pass_num); \
>> +                                                                           \
>> +         backend_visitor::dump_instructions(filename);                                      \
>> +      }                                                                    \
>> +                                                                           \
>> +      progress;                                                            \
>> +   })
>
> I like the use of the macro.  But...folding in the "progress = ... ||
> progress" might be nice too.  It would also let us stick to standard C
> here, rather than GNU extensions.

I don't see a problem with using extensions, especially when we
already use them. But decluttering the loop seems like a good idea.

>> +
>> +      if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
>> +         char filename[64];
>> +         snprintf(filename, 64, "fs%d-%02d-00-start",
>> +                  dispatch_width, shader_prog->Name);
>
> I am really unexcited about fixed length buffers, although you did do
> snprintf, and it'll probably not be a problem in practice.  Why not just
> asprintf or ralloc_asprintf it and then free it?  It's no more code and
> will just work.

Given the lengths of our optimization pass names, 64 seems like
plenty, and if it's not that worst that happens is we lose a few
characters from our optimization pass's name. My compiler complains
about not checking the return type of asprintf, and adding a memory
allocation failure check in the macro felt really stupid.


More information about the mesa-dev mailing list