Split anv_xe_wait_exec_queue_idle() into 2 functions, the first
function creates the syncobj and prepares it to be signaled when the
last workload in queue is completed.
And the second one that calls the first function, then waits for the
syncobj to be signaled and destroy the syncobj.
The main reason for that is that the first function can be reused in
Iris and a future patch will add another user, so lets share it.
No changes in behavior are expected here.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30958>
Next patch will need to frequently get the count of supported engine
for compute and copy engines, so to reduce the overhead of doing
KMD queries at every call here caching this information into
intel_device_info struct.
With that ANV and Iris would need to set this information as intel/dev
can't depend on intel/common, so here adding a single function
to update intel_device_info with all fields filled by intel/common
functions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29899>
This functions were inlined in a header and duplicated between brw and
elk.
That would be enough reasons to move to a C file but next patches
will add more code to support Xe2 platforms, what would cause more
code to be inlined, duplicating even more code and increasing lib
size.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28910>
The debug identifier is put into the captured buffers for error
capture. This helps us figure out what version of the driver people
are running when encountering a GPU hang. This identifier has the
git-sha1 + driver name.
libintel_dev is also a dependency of the compiler so any change to the
git-sha1 also triggers recompile which we want to avoid.
This changes moves the debug identifier to src/intel/common which
drivers already depend on, so the compiler is not affected anymore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11136
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29128>
A "dance" is required with this uAPI, first we need to ask KMD what is
the size of the giving query id, then memory needs to be allocated to
match that size and then query again with the memory address set and
at this time Xe KMD will copy the query data to memory.
This dance was being duplicated in xe_engine_get_info() and
anv_xe_physical_device_get_parameters() and the next patch will also
use it in Iris, so here adding it common/xe and re-using as much
as possible.
There is one more implementation of this function in intel/dev but
due to how libs are linked intel/dev can't depend on to intel/common.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26325>
This implements a minimalistic algorithm that can be used to obtain an
approximate solution for the integer programming problem of finding
the optimal tile dimensions based on an estimate of the tile cache
consumption per pixel of the current graphics pipeline -- Including
the TC footprint of render targets, depth and stencil buffers and
their auxiliary surfaces. Considering other (less local) memory
accesses performed by the pipeline (like texturing and shader storage)
would be useful (and could be considered by this algorithm with little
modification), but it would be pretty difficult to estimate the L3
cache consumption per pixel of such accesses based on static analysis
of the pipeline state alone without some sort of dynamic feedback.
The present algorithm returns a config with tile area large enough to
utilize a target fraction of the L3, which can be adjusted to obtain
greater/lower utilization of the L3 at the cost of higher/lower risk
of L3 cache thrashing respectively. The aspect ratio of the tile
layout returned attempts to minimize the number of poorly utilized
tiles around the boundaries of the framebuffer (due to partial
coverage), since having the tile sequencer process additional tiles
comes at a cost due to the latency of the additional passes, even if
they're mostly empty. Finally, among the solutions with satisfactory
cache footprint and tile count, the tile aspect ratio closest to 1 is
returned where possible, since tiles with very high aspect ratios can
have a negative impact on cache locality.
The algorithm is primarily intended for TBIMR, but it could be used
for PTBR as well with little modifications, since the TBIMR-specific
assumptions are few and noted in comments below.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25493>
Instead of on Android. Which allows an end user to turn off expat
without breaking or disabling Intel support. I've additionally
refactored to separate expat and xmlconfig a bit more in the root
meson.build
This does make expat a hard dependency for building Intel tools, despite
the fact that only aubinator actually requires it. This simplifies the
build for the common case, and in the event that someone wants to build
the Intel tools and doesn't have libexpat, they can fall back to the
meson wrap for expat instead.
fixes: 75276deebc
closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8791
Reviewed-by: Mark Janes <markjanes@swizzler.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23605>
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>
I'm bringing up freedreno Vulkan on an Android phone, and my pains are
exactly what Chad said when working on Intel's vulkan for Android in
aa716db0f6 ("intel: Add simple logging façade for Android (v2)"):
On Android, stdio goes to /dev/null. On Android, remote gdb is even
more painful than the usual remote gdb. On Android, nothing works like
you expect and debugging is hell. I need logging.
This patch introduces a small, simple logging API that can easily wrap
Android's API. On non-Android platforms, this logger does nothing
fancy. It follows the time-honored Unix tradition of spewing
everything to stderr with minimal fuss.
My goal here is not perfection. My goal is to make a minimal, clean API,
that people hate merely a little instead of a lot, and that's good
enough to let me bring up Android Vulkan. And it needs to be fast,
which means it must be small. No one wants to their game to miss frames
while aiming a flaming bow into the jaws of an angry robot t-rex, and
thus become t-rex breakfast, because some fool had too much fun desiging
a bloated, ideal logging API.
Compared to trusty fprintf, _mesa_log[ewi]() is actually usable on
Android. Compared to os_log_message(), this has different error levels
and supports format arguments.
The only code change in the move is wrapping flockfile/funlockfile in
!DETECT_OS_WINDOWS, since mingw32 doesn't have it. Windows likely wants
different logging code, anyway.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6806>
