[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