Make sure we reject perfcnt users when the kernel driver is not panfrost.
We might decide to abstract perf counters at the kmod level at some
point, but we're not there yet.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Some GPU gens have variants impacting the GPU capabilities. Let the
kmod backend report a variant ID through a new
pan_kmod_dev_props::gpu_variant field, and patch the panfrost_model
logic to match both the gpu_id and the gpu_variant.
All existing entries are assumed to have no variant, hence the
gpu_variant field assigned to zero.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Move the functions that are dealing with panfrost_device initialization
to a new panfrost_device.c file, and make the remaining ones
panfrost_device agnostic.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Constantine Shablya <constantine.shablya@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26698>
We are about to delegate some device-related operations to the pan_kmod
layer, but before we can do that, we need to hide panfrost_device
internals so we can redirect such accesses to pan_kmod.
Provide a few panfrost_device_xxx() accessors and start using them.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26357>
This switches us over to Mesa's code style [1], normalizing us within the tree.
The results aren't perfect, but they bring us a hell of a lot closer to the rest
of the tree. Panfrost doesn't feel so foreign relative to Mesa with this, which
I think (in retrospect after a bunch of years of being "different") is the right
call.
I skipped PanVK because that's paused right now.
find panfrost/ -type f -name '*.h' | grep -v vulkan | xargs clang-format -i;
find panfrost/ -type f -name '*.c' | grep -v vulkan | xargs clang-format -i;
clang-format -i gallium/drivers/panfrost/*.c gallium/drivers/panfrost/*.h ; find
panfrost/ -type f -name '*.cpp' | grep -v vulkan | xargs clang-format -i
[1] https://docs.mesa3d.org/codingstyle.html
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20425>
To query the core count, the hardware has a SHADERS_PRESENT register containing
a mask of shader cores connected. The core count equals the number of 1-bits,
regardless of placement. This value is useful for public consumption (like
in clinfo).
However, internally we are interested in the range of core IDs.
We usually query core count to determine how many cores to allocate various
per-core buffers for (performance counters, occlusion queries, and the stack).
In each case, the hardware writes at the index of its core ID, so we have to
allocate enough for entire range of core IDs. If the core mask is
discontiguous, this necessarily overallocates.
Rename the existing core_count to core_id_range, better reflecting its
definition and purpose, and repurpose core_count for the actual core count.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17265>
The performance counter layout depends on the number of L2 blocks and the number
of shader cores. It doesn't make a ton of sense to hardcode these into the XML
files. Instead, let's make the coutner offsets in the XML files relative to the
categories (blocks), so we can calculate the offsets of the categories
themselves at runtime based on the computed layout. This fixes performance
counters on Mali-G57 as implemented on MT8192.
There is little code change here, mainly churn from changing the XML definition.
Postprocessing for the XML to make it suitable for Mesa uses Antonio Caggiano's
https://gitlab.freedesktop.org/panfrost/hwc-helper tool.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16803>
This uses Antonio's src/panfrost/perf for all the heavylifting, just
like the Perfetto producer. Unlike the Perfetto producer, it has no
dependencies and is a lot less useful. But it's a good smoke test.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11733>
Configure a panfrost performance structure with tables of categories and
counters for the current product id. An array for storing counter values
read from the GPU is also managed by this structure. A generic read
function can be used to retrieve the value of a counter from the conter
values array.
v2: Generate tables instead of calling register functions.
v3: Simplify counter read function and `pan_gen_perf.py` write method.
v4: Accumulate counter values from all cores.
v5: Wrap `STATIC_ASSERT`s within unused functions.
Signed-off-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10844>
