[Intel-gfx] [PATCH i-g-t 03/21] trace.pl: Virtual engine support

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-05-08 13:10:40)
> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> 
> Add virtual/queue timelines to both stdout and HTML output.
> 
> A new timeline is created for each queue/virtual engine to display
> associated requests in queued and runnable states. Once requests are
> submitted to a real engine for executing they show up on the physical
> engine timeline.

How does it cope with preemption events that shift the request onto
another engine?

Queues. So why are virtual engines treated differently, from my pov it's
just a timeline like any other, the only difference is that it my
execute on a different engine? My expectation would have been that
tracking would have been timeline centric.

However, I think I am confusing my perspective of timelines in the
kernel with the visualisation timelines.


> +sub is_veng
> +{
> +       my ($class, $instance) = split ':', shift;
> +
> +       return $instance eq '254';

Ok. I thought I might have caught you out.


> +               unless (exists $queue{$key}) {
> +                       # Virtual engine
> +                       my $vkey = db_key(VENG, $ctx, $seqno);
> +                       my %req;
> +
> +                       die unless exists $queues{$ctx};
> +                       die unless exists $queue{$vkey};
> +                       die unless exists $submit{$vkey};
> +
> +                       # Create separate request record on the queue timeline
> +                       $q = $queue{$vkey};
> +                       $s = $submit{$vkey};
> +                       $req{'queue'} = $q;
> +                       $req{'submit'} = $s;
> +                       $req{'start'} = $time;
> +                       $req{'end'} = $time;
> +                       $req{'ring'} = VENG;
> +                       $req{'seqno'} = $seqno;
> +                       $req{'ctx'} = $ctx;
> +                       $req{'name'} = $ctx . '/' . $seqno;
> +                       $req{'global'} = $tp{'global'};
> +                       $req{'port'} = $tp{'port'};

Just quietly thinking why not adopt this for each timeline; create a
on-engine event box for all.

> +
> +                       $vdb{$vkey} = \%req;
> +               } else {
> +                       $q = $queue{$key};
> +                       $s = $submit{$key};
> +               }
>  
>                 $req{'start'} = $time;
>                 $req{'ring'} = $ring;


>  sub stdio_stats
>  {
>         my ($stats, $group, $id) = @_;
> +       my $veng = exists $stats->{'virtual'} ? 1 : 0;
>         my $str;
>  
> -       $str = 'Ring' . $group . ': ';
> +       $str = $veng ? 'Virtual' : 'Ring';
> +       $str .= $group . ': ';
>         $str .= $stats->{'count'} . ' batches, ';
> -       $str .= sprintf('%.2f (%.2f) avg batch us, ', $stats->{'avg'}, $stats->{'total-avg'});
> -       $str .= sprintf('%.2f', $stats->{'idle'}) . '% idle, ';
> -       $str .= sprintf('%.2f', $stats->{'busy'}) . '% busy, ';
> +       unless ($veng) {
> +               $str .= sprintf('%.2f (%.2f) avg batch us, ',
> +                               $stats->{'avg'}, $stats->{'total-avg'});
> +               $str .= sprintf('%.2f', $stats->{'idle'}) . '% idle, ';
> +               $str .= sprintf('%.2f', $stats->{'busy'}) . '% busy, ';
> +       }
> +
>         $str .= sprintf('%.2f', $stats->{'runnable'}) . '% runnable, ';
>         $str .= sprintf('%.2f', $stats->{'queued'}) . '% queued, ';
>         $str .= sprintf('%.2f', $stats->{'wait'}) . '% wait';

So I'm looking that the utilisation, trying to figure out why veng
matters? Do we not breakdown utilisation for the real engines, plus
utilisation on each client timeline?
-Chris