make it easier to re-use the hidden jobs by other project (e.g. linux)
without enabling the executable jobs.
Inspired on 9442571664 ("ci: separate hiden jobs to -inc.yml files").
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29084>
Cross-device is a virtio-gpu feature that enables sharing host blob
dma-bufs with other virtio devices, like virtio-wl or virtio-video.
This feature is mainly used by ChromeOS and not required if there is
no dma-buf sharing. Venus has a hard requirement for the cross-device
feature.
Qemu doesn't support cross-device. Relax cross-device feature requirement
by making it optional, allowing Venus to work on Qemu.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29040>
For early error returns, all pipeline handles have to be destroyed.
Otherwise the caller will treat those valid handles as successfully
created pipeline objects.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28944>
Pending feedback resources (cmds, buffers, slots) for timeline semaphores are
generally reclaimed for re-use during subsequent semaphore waits/queries or any
queue submission containing at least one "wait" semaphore.
They are never reclaimed in the unexpected case when all submissions only
contain "signal" timeline semaphores, which consume such resources but
are never subsequently queried or waited upon.
This strange behavior is observed in several Valve games (Portal 2,
L4D2, CS2), which all run natively on linux with their own internal
distributions of DXVK v2.0 (at time of this MR submission). A Cursory
analysis of recent DXVK history indicates that it may be gone by v2.1.
The consequence is rapid guest memory leak and host Vk resource leak,
resulting in a crash within 1-2 minutes.
Fix that leak by running the reclaimation procedure for submissions with
_any_ accompanying semaphores.
Fixes: d63432012d ("venus: refactor semaphore feedback")
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28915>
Workaround dEQP-VK.wsi.android.swapchain.simulate_oom.* test failures on
turnip where excessive imports can fail, and venus has to propagate oom.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28941>
There're many cases in which the ring submissions must succeed. We don't
worry about real oom since things would fail earlier. For simulated oom
from random intentional allocs, there isn't robust way to fail those
must succeeds. e.g. the commands that don't have return codes or valid
error return struct defaults. So real oom propagation is still at best
effort.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28914>
Test Zink on Venus on Lavapipe.
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27790>
No need to track is_push_descriptor in templ. No need to conditionally
decide to use set or NULL handle since we pass NULL handle from the cmd
side. Also fixed the arg type mismatch in the template helper.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28686>
The check won't reduce much of the overhead but also adds more when
something is to be fixed (mostly the case for push descriptor).
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
Summary:
1. skip zero count
2. no need to check last binding count on the restore path
3. flatten the helper to avoid a 2nd pass in free_descriptors
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
This is to balance with other checks against it, and meanwhile making it
explicit that real descriptor free shouldn't call the free helper.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
The ring cs shmem cache is already there. The external fence/sempahore
support will be eventually via adopting mesa common drm syncobj support.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
The two extensions are implemented natively but allow to leak structs to
renderer side to avoid deep copying huge driver side pNext chain. It
doesn't make things more robust if we hide the two behind core 1.3 and
drop the two from the protocol so that venus-protocol filters out the
leaked structs. e.g. we'd still have to flip some bits in the core
feature structs.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
The default vn_relax is mainly targeting Vulkan commands expecting a
rely like object creation and property queries. The defined relax reason
here is VN_RELAX_REASON_RING_SPACE. The polling strategy involves more
busy waits to overcome sleep penalty affecting cpu utilization, as well
as an edge case for Android system server which forces to sleep longer
even with trivial hrtimer interval.
However, for the below relax reasons:
- VN_RELAX_REASON_RING_SPACE
- VN_RELAX_REASON_FENCE
- VN_RELAX_REASON_SEMAPHORE
- VN_RELAX_REASON_QUERY
It's a waste of cpu cycles if we do more busy waits if the initial
polled signals are not "ready". Having less busy waits there allows to
jump to higher order of sleeps sooner to disturb the scheduler less
until signaled.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Up to this commit in this MR, the gfxbench manhattan scores have been
improved by 10~15% with ANGLE-on-Venus on some AMD platforms.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Better distinguish different client waiting and prepare for applying
different waiting profile for different reasons.
Default case is avoided in reason string mapping so that below can be
hit upon compilation:
- error: enumeration value ‘XXX’ not handled in switch [-Werror=switch]
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Similar to the rationale for the 50ms -> 5ms adjustment before. When
there's enough cpu cycles, doing so would only help reduce cpu
utilization. When cpu is mostly drained, less host side unnecessary
polling is favored by the scheduler. Also in the latter case, it'd be
the non-primary ring, so it doesn't hurt to idle out faster.
Besides the theory, there's no regression in popular benchmarks, but
only power wins. Making the idle timeout too small will lead to overhead
built up. e.g. From the initial notify to ring being waken up, it's
about 200us. The notify op is more expensive than ring thread doing a
few more polls. However, we normally would save many more polls by idle
out earlier. From my local testing, reducing down to 500us won't incur
and real perf regressions either.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
The ring notification can be blocked on renderer main thread if a vq cmd
is waiting for a ring cmd (via a different non-idle ring). This change
optimizes to only try waking up the ring on the idle timeout period.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Extend the vkGetPhysicalDeviceFormatProperties2 cache to include
VkFormatProperties3 from the pNext chain. VkFormatProperties3 was
observed being always attached for DXVK and thus skipping the cache
if not handled.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28194>
