We still print them in the job log to not completely ignore them, but
they don't break the jobs anymore.
Additionally, we use the same format as deqp-runner for reporting
flakes, so that existing tools can pick up this new information without
requiring any change.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30413>
Because of Fermi's extremely tight register file and the fact that we
have to modify x and y as we multiply, the only form of these we can
support as builder helpers is one which implicitly frees its sources.
Also, because we can't afford to just allocate extra stuff, we add
32x32_32, 32x32_64, and 32x64_64 forms.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25167>
Instead of returning a single offset, return a struct with three ranges,
one for X, Y, and Z. This also communicates the sizes of each of the
fields to the driver in case that's relevant.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25167>
COARSE clocks add a worst-case jitter of 10ms to the timing, as they
degrade the timing to Linux jiffy accuracy. However, they allow to skip
a syscall on platforms where the accurate version of the clock can not
be accelerated through the VDSO.
Switch to using the COARSE version of the clock when the timeout is
larger than 200ms, i.e. the accuracy of the timeout is degraded less
than 5% by the added worst-case jitter.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27079>
By using the the COARSE variant of the clock we can avoid a syscall
to fetch the current time on platforms where the more accurate
version of the clock can not be accelerated through the VDSO. The
most relevant platform with this restriction is ARM32 without the
architected timer extension, e.g. the NXP i.MX6.
The COARSE clock degrades the accuracy of the timing to Linux
jiffies, which means it adds a worst-case jitter of 10ms, which is
basically noise in relation to the 1sec holding time of the cache
and the irregular call pattern of etna_bo_cache_cleanup().
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27079>
Looking at recent jobs, the runtime has increased to ~40min, but since
it runs on a shared runner with other jobs at the same time, it can
randomly take much longer, and it has reached 45 minutes several times,
so bump up the timeout to leave enough margin.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30424>
We only support equal MB/CTB per slice (with last slice possibly
smaller) and this is not possible to fully describe with libva slice
structure constraints.
Report that we support arbitrary macroblocks per slice, verify if the
slice structure requested by application can be used, otherwise
divide the slices equally to achieve the requested number of slices.
Also stop reporting power of two structure support, as that implies
different size for each slice which cannot be supported.
This fixes issue where slice encoding is not available at all with some
applications (only supporting arbitrary macroblocks) or the number of slices
being different from the requested number.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30363>
During development of the freedreno's Perfetto producer for a7xx platforms
it was found that the lists of perfcntr countables that were initially
imported were not correct.
The lists are now updated, with the updated countables matching the
countables used in the official profiler tool's counters. While the
Perfetto producer work is still ongoing the fixed lists should already be
useful through fdperf.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30406>
A750+ added a special flag that allows HW to correctly interpret UBWC, including
UBWC fast-clear when casting image to a different format permitted by Vulkan.
So it's possible to have UBWC enabled for image that has e.g. R32_UINT and
R8G8B8A8_UNORM in the mutable formats list.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30370>
Our current TLB path would case a job writing to the blit source
to be flushed, causing the TLB store which we would then reload
from memory to do the blit, which is not optimal. With this path,
if the job that writes the blit source has not been flushed, we
will configure it to also do the blit to the destination. This will
avoid the expensive TLB load for the blit and, if glInvalidateFramebuffer
has been used on the blit source, possibly the TLB store as well for
the job writing the blit source.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30322>
The condition of flat ccs and vram_only checker causes different
aux usage at binding stage. The current design is reusing CCS_E
on Xe2, so we want both Xe2 integrated and discreted GPUs behave
the same way.
Xe2 shouldn't need any special setup of CCS in the loop.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
On pre-Xe2 platforms, the compression on these modifiers that
don't support compression are enabled. The compressed will be
resolved when needed. On Xe2+ we haven't support explicit
resolve, so all the paths to resolves are prohibited now. But
the code is still doing it, causing an assertion failure:
Fixes: vkcube
src/intel/vulkan/anv_private.h:5467:
anv_image_get_fast_clear_type_addr: Assertion
`device->info->ver < 20' failed.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
Dave Airlie