This reveals that we've got really bogus times from these events. I
think there are two things here: the begin is the submit time, not the
submit-to-hardware time. And the end time is retire, which is too
delayed to be really useful. We need to move i915 over to the
low-level tracepoints.
However, this code proved to be useful for vc4, where I have good
timings.
Max uint was more than we allow, since we steal the top 8 bits for some
other data. This instead checks for 24-bit and warns if the user tries to
store a counter value that was not registered.
We have an annoying issue where we look at all fiends of a counter values
chunk in the counter set frame. So we need those values set to zero. If
we are passed fewer counter values than can fit in the frame, we leave
some of that data uninitialized. This ensures that it is cleared.
This will help make sense of vblank events in a multi-screen
environment (where there are two streams of vblanks), and hopefully
also useful for correlating to compositor events.
The goal here is to avoid having to hard code what visualizers are shown
from the .ui files. We just should add things that we find are supported.
Long term, I think we'll add a concept of an "instrument" which is the
combination of a data source (SpSource) and a visualizer (SpVisualizerRow).
The other goal here is to enable the future support for discovering marks
and adding rows for each of those threads.
This should be useful to visualize system-wide events in the CPU
timeline, especially once we add some more events.
We may want to define some modes eventually, as not all captures will
care about GPU visualization. However, it's pretty low overhead (60Hz
* number of monitors), so maybe we can just filter it out at
visualization time.
We do a bit more setup work than necessary here (looking up the config
number for the tracepoint per CPU, rather than looking it up once at
startup), but I suspect I'll want to refactor the init anyway once we
add more tracepoint markers.
If we want to start watching other perf events, we need a way to look
up what perf event we got when a PERF_RECORD_SAMPLE comes in. The
sample identifier is what does that.
This allows grouping marks together so that the UI can present marks within
the same group in the same visualizer row.
The goal here is that our perf stream with drm data will have "drm" or some
similar group name (resulting in one row). mutter/cogl/gnome-shell will
use the thread-id as the group name (or something else that is useful) so
their events are grouped together. gdk-wayland might have it's own group
name as well.
The end result is that we can get a mark row for each series of related
data.
The goal here is to have an API that allows us to record things like
frame timing data. We might iterate on this API a bit, but this gets us
started.
A SpCaptureMark with a zero duration should be treated like an epoch mark
once a visualizer is created. SpCaptureMark with a non-zero duration should
be treated like a begin/end of operation. This may be useful in generating
something like a flame graph.
We don't want to avoid adding the symbols to the index table, or we will
get the wrong addresses.
So instead, add them, and then ignore the symbols upon lookup.
This allows us to pass in the file to read from, and adds a quick test
case to view the parsed output. It also fixes a base-10 vs base-16
mistake in parsing addresses.
