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

[Jason Ekstrand]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190424/1af91ae5/attachment.html>