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

[Mark Janes]

I pushed the patches that got review (1-3).  I haven't prompted anyone
for more review, because FrameRetrace is the only app that will
immediately benefit from the patches.  Eventually, the existing
mechanism will break, and someone that needs to debug their shader
assemblies will have a reason to review.

I can make a MR in gitlab if you think it would help.

Jason Ekstrand <jason at jlekstrand.net> writes:

> Did this get dropped on the ground?
>
> On Fri, Dec 7, 2018 at 12:07 PM Mark Janes <mark.a.janes at intel.com> wrote:
>
>> 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.
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>