[Mesa-dev] [PATCH 00/11] i965 shader debug through KHR_debug

[Mark Janes]

Ilia Mirkin <imirkin at alum.mit.edu> writes:

> On Thu, Dec 6, 2018 at 7:36 PM Mark Janes <mark.a.janes at intel.com> wrote:
>>
>> This series provides Intel shader compilation debug information via
>> KHR_debug.  Previously, shader assembly and related compilation
>> artifacts were dumped to stderr.  Tools associating compilation
>> artifacts with programs (e.g. FrameRetrace*) parsed stderr, which was
>> error prone.  Changes to the shader debug formats and the addition of
>> shader cache assembly dumps further complicate the task of parsing
>> stderr.
>>
>> KHR_debug provides synchronous callbacks with stable identifiers,
>> simplifying the task of matching debug artifacts with the originating
>> GLSL.
>
> One observation is that while the identifiers may be stable within a
> single execution, they will not be stable across different
> applications / traces. id's are set on a first-come first-serve basis,
> so depending on the exact order, the id's will end up different.
>
> Is that OK for frameretrace? Another approach would be to create
> globally-hardcoded id's for these, and start the auto-allocation in a
> higher range.

I did take a few steps down the path of globally hard-coded id's.  I
agree with Eric's assessment in debug_output.c that a giant enum list of
all debug message id's is unworkable.

We could divide id's into regions based on the high bits, and allocate
the lower bits to components to declare and manage.  This would break up
the monolithic declaration of id's, but you still have the issue of id
stability as the driver changes over time.  Refactoring functionality to
a location where it can be shared would involve changing the id's of
emitted debug messages.  Also, any taxonomy used to split up the id's
will probably look shortsighted in 5 years time.

I personally haven't seen a great solution for sharing a 32 debug id
within a large project.  The idea of exporting the id's to external
tools is even more problematic.

Rather than try to solve that problem, I decided to associate unknown
id's with the semantic meaning by parsing the first few words in
frameretrace.  A stable id means subsequent messages can be handled
without parsing.  Unknown messages are turned of via KHR_debug.  This is
a much better parsing stderr, where it is difficult to determine message
boundaries.