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.
