<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 12:59 AM Mark Janes <<a href="mailto:mark.a.janes@intel.com">mark.a.janes@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I pushed the patches that got review (1-3). I haven't prompted anyone<br>
for more review, because FrameRetrace is the only app that will<br>
immediately benefit from the patches. Eventually, the existing<br>
mechanism will break, and someone that needs to debug their shader<br>
assemblies will have a reason to review.<br>
<br>
I can make a MR in gitlab if you think it would help.<br></blockquote><div><br></div><div>That seems like a good way to hang on to it.</div><div><br></div><div>--Jason</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> writes:<br>
<br>
> Did this get dropped on the ground?<br>
><br>
> On Fri, Dec 7, 2018 at 12:07 PM Mark Janes <<a href="mailto:mark.a.janes@intel.com" target="_blank">mark.a.janes@intel.com</a>> wrote:<br>
><br>
>> Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>> writes:<br>
>><br>
>> > 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>><br>
>> wrote:<br>
>> >><br>
>> >> This series provides Intel shader compilation debug information via<br>
>> >> KHR_debug. Previously, shader assembly and related compilation<br>
>> >> artifacts were dumped to stderr. Tools associating compilation<br>
>> >> artifacts with programs (e.g. FrameRetrace*) parsed stderr, which was<br>
>> >> error prone. Changes to the shader debug formats and the addition of<br>
>> >> shader cache assembly dumps further complicate the task of parsing<br>
>> >> stderr.<br>
>> >><br>
>> >> KHR_debug provides synchronous callbacks with stable identifiers,<br>
>> >> simplifying the task of matching debug artifacts with the originating<br>
>> >> GLSL.<br>
>> ><br>
>> > One observation is that while the identifiers may be stable within a<br>
>> > single execution, they will not be stable across different<br>
>> > applications / traces. id's are set on a first-come first-serve basis,<br>
>> > so depending on the exact order, the id's will end up different.<br>
>> ><br>
>> > Is that OK for frameretrace? Another approach would be to create<br>
>> > globally-hardcoded id's for these, and start the auto-allocation in a<br>
>> > higher range.<br>
>><br>
>> I did take a few steps down the path of globally hard-coded id's. I<br>
>> agree with Eric's assessment in debug_output.c that a giant enum list of<br>
>> all debug message id's is unworkable.<br>
>><br>
>> We could divide id's into regions based on the high bits, and allocate<br>
>> the lower bits to components to declare and manage. This would break up<br>
>> the monolithic declaration of id's, but you still have the issue of id<br>
>> stability as the driver changes over time. Refactoring functionality to<br>
>> a location where it can be shared would involve changing the id's of<br>
>> emitted debug messages. Also, any taxonomy used to split up the id's<br>
>> will probably look shortsighted in 5 years time.<br>
>><br>
>> I personally haven't seen a great solution for sharing a 32 debug id<br>
>> within a large project. The idea of exporting the id's to external<br>
>> tools is even more problematic.<br>
>><br>
>> Rather than try to solve that problem, I decided to associate unknown<br>
>> id's with the semantic meaning by parsing the first few words in<br>
>> frameretrace. A stable id means subsequent messages can be handled<br>
>> without parsing. Unknown messages are turned of via KHR_debug. This is<br>
>> a much better parsing stderr, where it is difficult to determine message<br>
>> boundaries.<br>
>> _______________________________________________<br>
>> mesa-dev mailing list<br>
>> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
>> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
>><br>
</blockquote></div></div>