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

[Jason Ekstrand]

On Wed, Apr 24, 2019 at 12:59 AM Mark Janes <mark.a.janes at intel.com> wrote:

> 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.
>

That seems like a good way to hang on to it.

--Jason



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