For years, I've maintained that I like to bump this number manually
because it gives me a point at which to say, "I've looked at most of the
issues and I think we're up to date." The reality, however, is that I
just bump it every few months and don't really do any thorough checking.
We may as well just bump it on header updates.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8792>
Apart from the single additional marker field, these queries will now
use the same layout as all other drivers.
This should allow us to modify a single component to add an additional
register for new metrics.
v2: Capture the query beging registers in reverse order to ensure
timestamp is as close as possible from measured draw call.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
This unifies performance data gathering between the GL & Vulkan
drivers.
v2: Also move all NOOPs to before the query, leaving none inside
v3: Capture the query beging registers in reverse order to ensure
timestamp is as close as possible from measured draw call.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
When transitioning the oa-*.xml files from Gputop to IGT, we also had
to deal with a python2->3 transition. Unfortunately the implementation
dependent hash table ordering leaked into the XML files and so things
changed quite a bit.
This script reorders things from the old to the new order in the
existing files.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
For all generations supported we had a layout describing what register
to store to implement a MI_RPC replacement.
This is because, on Gen12 we need to snapshot OAG registers to get
correct values for the perf equations. There, the MI_RPC instruction
captures OAR register which do not have all the information we need.
v2: Fix commented code for debug (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
This will be useful when we implement queries using a series of MI_SRM
instead of MI_RPC.
Unfortunately on Gen12, the MI_RPC command sources values from the OAR
unit which has a similar series of register as the OAG unit but some
of the configuration of HW doesn't reach OAR so we have to snapshot
OAG manually instead.
v2: Fix comments
Use const
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
Those are not part of the OA reports and need some additional
scaffolding. Those counters are only available when doing queries as
we need to emit MI_SRMs to record them.
Equations making use of those counters are not there yet, they will
come in a follow up commit updating a bunch of oa-*.xml files.
v2: Fix typo
v3: Use PERF_CNT_VALUE_MASK (Marcin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6518>
When a secondary command buffer is encountered, insert an event that
links to the new batch.
This commit leaves intel_measure timestamp buffer objects mmapped,
which is more efficient than mapping/unmapping several times. With
the BOs mapped at all times, timestamp buffers can be managed directly
by intel_measure, where it will iterate over timestamps of linked
secondary buffers.
With timestamp buffers managed by intel_measure, a more efficient and
accurate check for render completion can be moved into intel_measure
from anv/iris.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7354>
This infrastructure collects GPU timestamps over common intervals, and
generates a CSV report to show how long rendering took. The overhead
of collection is limited to the flushing that is required at the
interval boundaries for accurate timestamps.
By default, timing data is sent to stderr. To direct output to a
file:
INTEL_MEASURE=file=/tmp/measure.csv {workload}
To begin capturing timestamps at a particular frame:
INTEL_MEASURE=file=/tmp/measure.csv,start=15 {workload}
To capture only 23 frames:
INTEL_MEASURE=count=23 {workload}
To capture frames 15-37, stopping before frame 38:
INTEL_MEASURE=start=15,count=23 {workload}
Designate an asynchronous control file with:
INTEL_MEASURE=control=path/to/control.fifo {workload}
As the workload runs, enable capture for 5 frames with:
$ echo 5 > path/to/control.fifo
Enable unbounded capture:
$ echo -1 > path/to/control.fifo
and disable with:
$ echo 0 > path/to/control.fifo
Select the boundaries of each snapshot with:
INTEL_MEASURE=draw : DEFAULT - Collects timings for every render
INTEL_MEASURE=rt : Collects timings when the render target changes
INTEL_MEASURE=batch : Collects timings when batches are submitted
INTEL_MEASURE=frame : Collects timings at frame boundaries
With INTEL_MEASURE=interval=5, the duration of 5 events will be
combined into a single record in the output. When possible, a single
start and end event will be submitted to the GPU to minimize
stalling. Combined events will not span batches, except in
the case of INTEL_MEASURE=frame.
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7354>
Now that all drivers are converted over, we can make a few changes.
First off, vk_device_init no longer takes two separate allocators
because we can assume that the parent instance is non-null and it can
pull the instance allocator from that. Second, dispatch tables and the
instance extension table are no longer optional. We leave the device
extension table optional for now because we don't do any verification at
vk_init_physical_device time and some drivers find it more convenient to
set the extensions later in their own physical_device_init for various
reasons.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8676>
Jason Ekstrand