| Age | Commit message (Collapse) | Author |
|---|
|
Timeline id allocation order is not tied with engine ids any more.
Remove the option which assumed that was the case in attempt to provide
more readable timeline.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Add the command line switch which uses different colours for different
context execution boxes.
v2:
* Use HSL to simplify color generation. (Lionel)
* Colour other boxes in the same colour but different shade so it is
easier to follow the timeline.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> # v1
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
It makes sense to fetch the min and max timestamp only after the
last sort of the array.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Just to clear up some space for incoming code refactoring.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Delay the auto-generation of end/notify values until the point where
everything is known. As opposed to potentially generating them
multiple times with differing values (in the case of 'incomplete'
entries).
v2: More complete description. [Tvrtko]
Signed-off-by: John Harrison <John.C.Harrison@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
There are various statistics being calculated multiple times in
multiple places while the log file is being read in. Some of these are
then re-calculated when the database is munged to correct various
issues with the logs. This patch consolidates the calculations into a
separate pass after all the reading and munging has been done.
Note that this actually produces a different final output as the
'execute-delay' values were not previously being re-calculated after
all the fixups. Thus were based on an incorrect calculation.
v2: Reduce scope of some local variables [Tvrtko]
Signed-off-by: John Harrison <John.C.Harrison@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Add an extra level to the databse key sort so that the ordering is
deterministic. If the time stamp matches, it now compares the key
itself as well (context/seqno). This makes it much easier to determine
if a change has actually broken anything. Previously back to back runs
with no changes could still produce different output, especially when
adding extra debug output during the calculations.
As the comparison test is now more than a single equation, moved it
out into a separate sort function.
v2: Re-work sort func for readability/performance [Tvrtko]
Signed-off-by: John Harrison <John.C.Harrison@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Cache the key count value rather than querying the hash every time.
Also assert that the database does not magically change size after the
fixups.
v2: Rename variable according to style guide [Tvrtko]
v3: Reverted accidental style change and added a blank line. [Tvrtko]
Signed-off-by: John Harrison <John.C.Harrison@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
i915 renamed the request related tracepoints so catch up with that.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # irc
|
|
A couple of small optimizations which altogether bring around 30%
improvement in my testing.
1. Do less string processing on tracepoints names and push more of the
check into the if-ladder.
2. Pull out common db key and ctx processing and cache common values in
local vars.
3. Key value pair parsing is faster with a regexp.
4. Avoid sorting the db hash multiple times if possible.
v2:
* Use faster key-value splitting method. (John Harrison)
v3:
* Fix floating-point to int time conversion.
v4:
* Fix refactoring and logic fails. (John Harrison)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Last refactoring introduced a copy and paste error, fix it.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: John Harrison <John.C.Harrison@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
|
|
Breakage from previous refactoring.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: John Harrison <John.C.Harrison@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
|
|
Remove some inactive code which was only uised to support the old execlists
implementation. It is hidden behind a toggle which is not user accesible
anyway.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
|
|
Instead of hard-coding the order of key-value pairs into regular
expressions, auto-detect them as we go.
At the same time re-factor the code so it is smaller and even
slightly faster (10-15% by a quick measurement).
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: John Harrison <John.C.Harrison@intel.com>
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
|
|
Handle multi-day uptime when parsing tracepoint timestamps.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Merge and flatten all the engine timelines to produce an
aggregate stat.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
We are not interested in knowing the amount of perf data
captures so less noise is better.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
|
Given a log file created via perf with some interesting trace
events enabled, this tool can generate the timeline graph of
requests getting queued, their dependencies resolved, sent to
the GPU for executing and finally completed.
This can be useful when analyzing certain classes of performance
issues. More help is available in the tool itself.
The tool will also calculate some overall per engine statistics,
like total time engine was idle and similar.
v2:
* Address missing git add.
* Make html output optional (--html switch) and by default
just output aggregated per engine stats to stdout.
v3:
* Added --trace option which invokes perf with the correct
options automatically.
* Added --avg-delay-stats which prints averages for things
like waiting on ready, waiting on GPU and context save
duration.
* Fix warnings when no waits on an engine.
* Correct help text.
v4:
* Add --squash-ctx-id to substract engine id from ctx id
when parsing to make it easier to identify which context
is which with new i915 ctx id allocation scheme.
* Reconstruct request_out events where they are missing.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Harri Syrja <harri.syrja@intel.com>
Cc: Krzysztof E Olinski <krzysztof.e.olinski@intel.com>
|
