Did this get dropped on the ground? On Fri, Dec 7, 2018 at 12:07 PM Mark Janes <mark.a.ja...@intel.com> wrote:
> Ilia Mirkin <imir...@alum.mit.edu> writes: > > > On Thu, Dec 6, 2018 at 7:36 PM Mark Janes <mark.a.ja...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev