<div dir="ltr">Did this get dropped on the ground? </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 7, 2018 at 12:07 PM Mark Janes <<a href="mailto:mark.a.janes@intel.com">mark.a.janes@intel.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> writes: > On Thu, Dec 6, 2018 at 7:36 PM Mark Janes <<a href="mailto:mark.a.janes@intel.com" target="_blank">mark.a.janes@intel.com</a>> 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 <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div>