[Intel-gfx] [igt-dev] [PATCH i-g-t 02/27] trace.pl: Ignore signaling on non i915 fences
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Tue May 21 13:22:18 UTC 2019
On 21/05/2019 08:57, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>
>> gem_wsim uses the sw_fence timeline and confuses the script.
>>
>> v2:
>> * Check the correct timeline as well. (Chris)
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>> ---
>> scripts/trace.pl | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/scripts/trace.pl b/scripts/trace.pl
>> index 8c896cfde6b0..ac141a514055 100755
>> --- a/scripts/trace.pl
>> +++ b/scripts/trace.pl
>> @@ -443,6 +443,9 @@ while (<>) {
>> } elsif ($tp_name eq 'dma_fence:dma_fence_signaled:') {
>> my $nkey;
>>
>> + next unless $tp{'driver'} eq 'i915' and
>> + $tp{'timeline'} eq 'signaled';
>
> Hopefully that remains unique...
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
>
> I do recall wanting to remove the strings from all the tracepoints :-p
Eeek.. let's try and not make the request tracing ability even more useless.
Because for trace.pl the decoupled from actual request completion nature
of dma_fence_signaled is depressing enough. I wonder how better tracing
tools view/cope with this.
And I'd also write to Santa to wire me up a real request start, to
distinguish semaphores vs batch execution. In the realm of impossible
wishes yeah.
Persistent breadcrumbs while tracing is another one for which even there
was a patch some time back.
Regards,
Tvrtko
More information about the Intel-gfx
mailing list