On Fri, 2025-01-31 at 10:55 -0800, Teres Alexis, Alan Previn wrote: > On Thu, 2025-01-30 at 17:42 -0500, Vivi, Rodrigo wrote: > > On Tue, Jan 28, 2025 at 10:36:49AM -0800, Alan Previn wrote: > > > > > alan:snip > > > - if (!snapshot->matched_node) > > > + gt = guc_to_gt(guc); > > > + if (!node) { > > > + xe_gt_warn(gt, "GuC Capture printing without node!\n"); > > > return; > > > + } > > > + if (!p) { > > > + xe_gt_warn(gt, "GuC Capture printing without printer!\n"); > > > + return; > > > + } > > > > > > - xe_gt_assert(gt, snapshot->hwe); > > > - > > > - capture_class = xe_engine_class_to_guc_capture_class(snapshot->hwe->class); > > > - > > > - drm_printf(p, "%s (physical), logical instance=%d\n", > > > - snapshot->name ? snapshot->name : "", > > > - snapshot->logical_instance); > > > drm_printf(p, "\tCapture_source: %s\n", > > > - snapshot->matched_node->source == XE_ENGINE_CAPTURE_SOURCE_GUC ? > > > + node->source == XE_ENGINE_CAPTURE_SOURCE_GUC ? > > > "GuC" : "Manual"); > > > > This looks like it is changing the order of the prints. So, please ensure that this > > is not breaking the decode user space tools. > alan: good catch Rodrigo, let me double check this against the mesa tool. Although I am wondering > why the MESA tool would have ever expected non-engine-specific registers (forcewake) to be slotted > after a couple of GuCFW specific tags (like "Capture source" and "Coverage") followed by > engine-register dumps. I suspect the location of the GuC-tags could move around. > Will double check with them. just a quick update - finally with Jose's + John's help, manage to get the mesa aubinator tool built and Jose confirmed that the minor change above was didn't break the decoding. Jose did point out we had an extra newline so I'll have to fix that. Above hunk doesn't show it, but I think the new line is on caller of this function. Will fix this along with everything else and push a new rev shortly.