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>
We have a limited number of bytes we can output (500 KiB) and still have
the job log visible in the web UI, so let's avoid a very spammy output
(vkd3d outputs a ton of information about each test in stderr) that
can't even be correlated with the regular output, and instead store it
together with the test results.
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>
Some recurrent messages are only cluttering the ci_run_n_monitor's logs,
so let's use the easily provided @cache decorator to print stuff that
the user will only needs to see once.
Also removes some junk that can happen during the pipeline monitoring
loop, like the "----" line break, and newlines.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30361>
We stop monitoring pipeline changes when we find out that the target job
is already running, or is in a complete state.
But when we `--force-manual` we should consider that the job is not
complete and we should iterate a little more in the monitor pipeline
stage until it gets ready for trace following.
Closes: #11552
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30361>
Jobs that we want to run can get the `created` status when its
dependencies are still running.
So let's gather this information and ensure that we will wait these jobs
to reach the `manual` or `running` status before jumping to monitor
target jobs trace.
Closes: #11517
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30361>
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>
