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.
If we have a system where we can read kallsyms without elevated
privilledges do that. Otherwise, query the sysprod daemon to get the
available kernel symbols.
This allows external tooling to write capture files that Sysprof can open.
Ideally, this will get used by GJS in the near future to implement profiler
output for Sysprof.
We've had a number of errors reported from our previous
model filter implementation. This simplifies the impliementation
using a simple cross-reference structure with GSequenceIter in
both sequences.
We try extra hard to not emit signals when doing invalidation.
The lib/ directory was getting a bit out of hand, so this tries
to organize things a bit so it is easier going forward to locate
the code people want to patch.
We don't expose this via API yet, but it's handy to have it here so we can
build upon it for doing stacked drawings (as useful for things like memory
usage graphs by type).
Now that we are post-3.26, we are removing the legacy autotools
build system in favor of meson.
Please report any errors you have so that we can ensure this is
ready for GNOME 3.28.
