This could realistically happen if the compositor doesn't support parametric image
descriptions at all, in which case we'd get a protocol error for trying to use it.
Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33804>
After nir_lower_io we need to gather the info about 64 bit usage
to be up-to-date when deciding whether the remaining 64 bit IO ops
be lowered.
Before 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
the info was eventually updated to include the use of 64 bit values
also if only some IO was using this so that SFN was handling the code
correctly. As it seems with above patch this is not always the case
anymore, and we have to take care of it.
Fixes: 89dad5618d ("gallium: add PIPE_CAP_CALL_FINALIZE_NIR_IN_LINKER")
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32774>
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33843>
This is a constraint that apply on Valhall and later, instructions
should not use FAU special page 3 or WARP_ID if running
on the message unit.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: fd1906afea ("pan/va: Add FAU validation")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33843>
For instance, this issue is triggered with "piglit/bin/cl-custom-buffer-flags":
Segmentation fault
Fixes: 81889f4d5c ("r600: ensure that the last vertex is always processed on evergreen")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33351>
Turnip's current VK_KHR_performance_query implementation only exposed raw
perfcounters. These aren't exactly trivial to evaluate on their own.
This mode can still be used with the new TU_DEBUG_PERFCRAW flag. Existing
TU_DEBUG_PERFC now enables performance query mode where Freedreno's derived
counters are exposed instead. These default to using the command scope,
making them usable with RenderDoc's performance counter capture.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
Freedreno's derived counters combine multiple perfcntrs into a more
sensible, human-friendly metric. This change picks up the counters
currently used in Freedreno's Perfetto producer and rolls them into a
more genericallly usable form.
First place of their use will be through VK_KHR_performance_query, but
the Perfetto producer should also be able to use this interface instead
of having the logic duplicated. For now the counters are available only
for a7xx devices.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
Use CP_SCOPE_CNTL to disable preemption when beginning performance query
and enable it back when that performance query is ended. This way the
collected perfcounter measurements will only cover work that's encompassed
by the query.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
When using vkGetQueryPoolResults for performance queries, the result of
each query is the VkPerformanceCounterResultKHR union, and the result of
each query should be written into that union according to the storage type
of the corresponding counter.
This fixes current behavior of using the generic write procedure, where
either 32-bit or 64-bit value is written depending on the specified query
result flags.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
Query index should be used to calculate the correct iova for various
performance query fields used to store counter values at the beginning
and ending of performance queries.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33208>
This avoids reading past the buffer’s end in the client afterward, because the
drmFormatModifierCount hasn’t been changed from what the client passed, if it
wasn’t zero at first.
GTK triggers that bug by setting it to the length of the static array (see this
bug[0] though), but other Vulkan programs might have the same issue if they
don’t first query the count before allocating the array.
This has been tested on a Radxa ROCK 5B board running a Mali-G610 GPU.
[0] https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8222
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: 252ddaf51b ("panvk: fix VkDrmFormatModifierPropertiesListEXT query")
Fixes: https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/127
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33657>
We currently keep a0.x/a1.x unnecessarily blocked until we have to spill
it, even if all its uses have been scheduled already. This causes
unnecessary spills and potentially schedules address writes later than
we'd like.
Fix this by keeping track of the number of uses that are still
unscheduled, unblocking address writes when it drops to zero.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33816>
The current requirement for sync is only to support WSI, and it is not
necessarily needed at all per the comment added. Will drop it later.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33829>
This step is needed to support the same GPU model, but with a
different revision. A good example is the gc7000.
- imx8mp: model gc7000 with revision 6204 (uses RS)
- imx8mq: model gc7000 with revision 6214 (uses BLT)
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33811>
every vk driver wants these macros for executable statistics, so make them
common. there are two variants floating in-tree, a pure copy (radv) and a
formatted print (everyone else). we add both variants and then convert most
prints to copies where formatting isn't actually used. that has the benefit of
cleaning up trivial "%s" format strings in a bunch of places.
I didn't bother cleaning up the formatting in non-automatic-formatted drivers
because it's tedious and I'm planning to delete a lot of this driver code with
upcoming runtime work anyway. This is a step towards those runtime improvements.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33826>
Arm and NVIDIA hardware both have this as a bit you can set on the
texture instruction so we may as well have a shared pass for it.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33402>
Previously, the caps were not queried until after the first DPB buffer
was created. That causes the AOT path to be triggered even when the
device does report a requirement for texture array.
Tested-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33824>
