So the shuffleup tests did a shuffle up with const 5,
we'd use invocation id (0..8) shuffle it down by 5,
get (-5..3), then call llvmshufflevector with that
which is totally illegal.
There might be a nicer way to fix this, but I can't see
it straight away, just bail on the fast path.
Fixes:
dEQP-VK.subgroups.shuffle.compute.subgroupshuffleup*
Cc: mesa-stable
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23484>
this avoids doing any llvm work during lavapipe enumeration which
might otherwise explode if lavapipe is not the actual driver that
gets used
cc: mesa-stable
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22600>
I'm not planning to stand mesa-swrast back up until we get Kata set up, so
turn the testing back on at a reduced fraction on so that
venus/llvmpipe/etc. dev can still get some coverage.
I haven't turned lavapipe back on, because it is now unstable in memory
model / atomics tests.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21880>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21390>
These two dEQP tests:
* dEQP-VK.api.object_management.max_concurrent.graphics_pipeline
* dEQP-VK.api.object_management.max_concurrent.compute_pipeline
Require a lot of memory and might kill crosvm or the renderer server because of EOM
issues. Skip them for now.
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21306>
It has been fixed either in the CTS or in llvmpipe itself but this now passes when running
in CI.
We haven't seen it in CI yet as we are only running a subset of the Vulkan CTS.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20743>
The current implementation is getting its clock value from the host
and this value is not guaranteed to be the same as the VM guest.
This commit implements the CLOCK_MONOTONIC[_RAW] natively.
Signed-off-by: Igor Torrente <igor.torrente@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18281>
