Block all YCbCr formats from getting blit feature flags by using
vk_format_ycbcr_info.
Fixes dEQP-VK.api.info.format_properties.g10x6_b10x6r10x6_2plane_420_unorm_3pack16
and dEQP-VK.api.info.format_properties.g12x4_b12x4r12x4_2plane_420_unorm_3pack16.
Fixes: ab298b9c3a ("lavapipe: Remap 10 and 12 bit formats to 16 bit formats")
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31863>
Also change ifdef's from just `HAVE_LIBDRM` to check for both LIBDRM
and for UDMABUF HEADER. preventing unbalanced guards preventing part of
the code from being included if you just have LIBDRM or just have the
udmabuf headers.
Fixes: 4cfaf10c ("llvmpipe: Only use udmabuf with libdrm")
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31877>
Previously this bit was not clearly documented in PRMs, but gfx12 PRMs
finally list all the instructions where it is present.
Although it's unclear if it's functional for anything other than "if",
"else", and "goto", we probably still should acknowledge its existence
in other instructions.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
Previously this bit was not clearly documented in PRMs, but gfx12 PRMs
finally list all the instructions where it is present.
Although it's unclear if it's functional for anything other than "if",
"else", and "goto", we probably still should acknowledge its existence
in other instructions.
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31747>
The gallium interface always expected the driver to support multiple
in-flight feedbacks, so this shouldn't have been needed in the first
place.
Even if the driver wouldn't support it, we still can't force
applications to sync after each frame. In fact, the old VCE dual
instance feature relied on the vaSyncSurface not being called every
frame.
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This was added for the VCE dual instance feature and it tries
to delay flush such as the flush is done only every second frame.
For this it requires applications not to call vaSyncSurface after
each vaEndPicture, otherwise every frame will be flushed.
When this was implemented in 2016, libva and applications were
different. Now applications will always sync surface after each
end frame, making this feature completely non-functional.
Another issue is that this is incorrect, the flush cannot be delayed
and every vaEndPicture needs to flush. This is needed to ensure
interop with other APIs (eg. sharing dmabufs with GL) works correctly.
Delaying the flush would also mean submitting the same surface
every frame for encoding (and changing the surface contents before
encoding each frame) will not work.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This feature requires only flushing every second frame (submit two
encode jobs together), but that's not possible with VAAPI where
vaEndPicture is required to flush.
Current implementation in va frontend needs application to not call
vaSyncSurface after each vaEndPicture, but all applications actually
sync surface after each end picture so it will always flush after each
frame.
Remove this feature as the frontend implementation is wrong and it's not
even used currently because applications don't behave the way this expects.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31933>
This change fixes the calculation of the number of cubemap
images which requires a 6x multiplier.
This commit is inspired from nir_lower_robust_access and fixes
at least the following tests on cayman:
spec/arb_shader_image_load_store/layer/imagecubearray/layered binding test: fail pass
spec/arb_shader_image_load_store/max-size/imagecubearray max size test/8x8x2046x1: fail pass
Fixes: 27f5157777 ("r600/sfn: Add lowering pass to legalize image access")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31626>
This is a generic tool to convert OpenCL C to SPIR-V.
In the future, this will be replaced by `clang` directly using the LLVM SPIR-V
backend, but for now we need a tool in Mesa to provide this functionality with
older LLVM versions.
The important parts are that:
1. It does not depend on NIR or any real platform details. An older mesa_clc
from a previous Mesa version can generally be used to build a newer Mesa to
ease cross-OS builds.
2. Its output can be consumed without any LLVM dependence, which will untangle
the LLVM mess we have now.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31923>
Reduced the looping copy structure of a 2D array down to a single malloc
& memcpy operation to copy the entirety of the image buffer to a local
1D array copy.
With this setup, we can write the image row by row using the associated
libpng API call.
Local testing with vkcube showed ths as a large perf gain, reducing the
time it took to copy images by more than half:
Previous method:
mesa-screenshot: DEBUG: Time to copy: 251907 nanoseconds
Current method:
mesa-screenshot: DEBUG: Time to copy: 112904 nanoseconds
Also reduced swapchain image list malloc operations to one use. This
doesn't have much perf impact, but it's good to reduce the number of malloc
operations overall.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
This frees a fairly large amount of memory from the 2D matrix by
iterating over the rows to free them individually.
Liuqiang spotted some areas that we return early in the threaded
function and don't free some pointers.
To remedy this, we'll reorder the checks so that we don't have to
return early and can instead use an if/else flow to take care of
these problematic areas in a more elegant way.
Co-authored-by: Casey Bowman <casey.g.bowman@intel.com>
Co-authored-by: liuqiang <liuqiang@kylinos.cn>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
This allows larger buffer sizes when using the env config as well
as filepath for the output directory.
This will allow, for example, using a large number of singular frames:
frames=1/2/3/4/5/6/7/8/.../300
Also fixed an issue with filepaths sometimes being appended with garbage
characters due to not being initialized.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
Previously, only the first image in the swapchain was chosen at all times
to be copied to a file.
This meant that if a list of consecutive images were selected, multiple
duplicate images would be saved, instead of the proper frames actually
used in the workload.
Now, the index is properly obtained from AcquireNextImageKHR(), leading
to the same image being used for the workload to be copied and saved to
a file.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
Reviewed-by: Felix DeGrood <felix.j.degrood@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31793>
This is a workaround that is still in progress, see HSD 22020521218.
If we don't have these NOPs we may see rendering corruption or even
GPU hangs.
While we still don't fully understand the issue from the hardware
point of view, let's have this workaround so we can pass CTS and move
things forward. If we need to change this later, we can. Besides, the
impact is minimal. Shaderdb/fossilize report no changes for this
patch.
On our Blackops trace, the lack of this patch causes corruption in fog
rendering (rectangles where fog was supposed to be shown don't show
the fog).
On dEQP-VK.graphicsfuzz.cov-array-copies-loops-with-limiters, without
this patch we get a GPU hang.
Backport-to: 24.2
Testcase: dEQP-VK.graphicsfuzz.cov-array-copies-loops-with-limiters
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11813
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31331>
When running deqp-runner with a toml suite, the skip files can be
specified in the toml configuration or on the command line. The names of
most skip files are generated in `deqp-runner.sh` and passed through on
the command line so it’s not necessary to specify them again in the toml
suite. It doesn’t hurt, but it can be confusing.
Simplify the toml files by removing the duplicate skip files.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31912>
python-fire auto-converts `item1,item2` into a tuple, but if there is a
dash `-` inside the argument, it treats it as a string.
Let's validate the data, when it comes as a `str` or `tuple`.
For more details, here are the tested scenarios:
| --lava-tags= | Type | Value |
|--------------|-------|---------------------|
| None | bool | True |
| '' | str | '' |
| tag1 | str | "tag1" |
| tag1, | tuple | ("tag1",) |
| tag-1,tag-2 | str | 'tag-1,tag-2' |
| tag1,tag2 | tuple | ("tag1", "tag2") |
| ',' | str | ',' |
| ',,' | str | ',,' |
| 'tag1,,' | str | 'tag1,,' |
See also:
https://google.github.io/python-fire/guide/#argument-parsing
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
We compose the rootfs from a mixture of the base rootfs (exported from
the container build stage, currently lava_build.sh, which can be reused
as long as the container isn't rebuilt), the Mesa build overlay
(exported from the debian-* build job, which can be reused for every job
in that pipeline), and the per-job rootfs (containing job-specific
variables which cannot be reused).
Instead of having LAVA pull the base rootfs and separately downloading
the build/per-job parts on the DUT, get LAVA to compose the whole thing
by using overlays.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31882>
