At first, no behavior change in this CL.
The instance level helper for normal command submission is left to work
with the current venus protocol. Meanwhile, we leave the helper to
submit recorded command buffer inside instance to it can later redirect
to the primary ring.
We've internalized a few ring helpers that no longer need to be exposed.
Besides, indirect submission decision is on per-ring basis since the
ring buffer can vary later.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
This change only moves the fields without changing the accessors. It's
better to let ring own its own upload cs encoder (which is backed by
shmem array) to avoid lock contention between indirect submissions
across rings.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
Now we are able to break up the original lock to allow shmem alloc to be
outside the ring mutex, as long as the reply shmem set is still coupled
with ring submission.
Add and expose vn_instance_reply_shmem_alloc helper which will be used
by rings separately later.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
The encoder must not be empty by then so switch to an assert. Failing to
get a reply shmem would end up with VK_ERROR_OUT_OF_HOST_MEMORY, thus
there's no need to track either.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
This can be thread-safe only because we have dropped seeking command
stream offset, which requires comparing pool shmem to decide conditional
set stream.
This is to prepare for later sharing reply shmem pool across rings.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
More considerations and details here:
- The seek is a bit lighter than set, since it assumes renderer side
resource being immutable. It does affect perf when Venus is still
making verbose synchronous calls at runtime (e.g. descriptor set,
buffer, device memory, etc).
- Seek still requires lock protection as the reply shmem must be
immutable before the seek and the followed cmd are committed to the
ring.
- Removing seek without doing set requires renderer change to always
bump the encoder end position according to what the original request
is instead of being ad-hoc upon what the host driver tells to write.
The overhead and extra complexity there isn't negligible.
- Further, removing seek requires each ring to track the prior reply
pool shmem in the multi-ring scenario. While the additional host side
resource lookup isn't costy as the number of resources is must less
than the vk object table.
- The nice thing is that we can make shmem pool thead safe to be more
easily shared across rings.
So we just drop it.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
The ring wake up is no longer costy as the other notifies followed by
the initial call won't be blocked by ring cmd execution anymore
(without vkr side big context lock). Reducing the timeout can help cpu
bound scenarios.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
This avoids a potential race condition if two threads are competing for
the monitor with the initial states, and the losing one may run into
alive status being false and abort.
Fixes: 4a4b05869a ("venus: check and configure new ringMonitoring feature")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reported-by: Lina Versace <lina@kiwitree.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
All these jobs are redundant and a waste of resources:
- the containers have already been built & pushed in the merge pipeline
- the mesa build variants have already all passed
- the driver tests have already all passed
None of these jobs are doing anything useful in this pipeline, but it
costs a factor of 2x to our infrastructure, so let's remove them.
In other words, the only job left in the post-merge pipeline is the
`pages` job that deploys the update to the website.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26451>
Adds a venus dri option to advertise support for multi-plane format
modifiers to Vulkan's common WSI. Otherwise, Venus will only support
modifiers with planeCount == 1 to ensure compatibility with Xwayland's
virgl-backed Glamor backend.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
Force the use of single-plane modifiers for tiled wsi images as long as
Venus is integrated with Virgl, which does not support non-format
compression metadata planes (e.g. Intel's CCS or AMD's DCC modifiers).
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
For compositors that advertise modifier support, Vulkan common WSI
modifier support queries still fail in Venus on the Intel ANV driver.
This is due to the presence of VK_CREATE_IMAGE_ALIAS_BIT, without
accompanying wsi_image_create_info struct, which is implicitly excluded
from serialized messages over the venus-protocol.
By removing ALIAS_BIT, modifier queries begin to pass when the host
supports them.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26240>
These were left unimplemented despite sparse support being added back to
venus in a55d26b5 ("venus: add back sparse binding support")
Same as vn_GetPhysicalDeviceSparseImageFormatProperties2, venus sparse
support requires queues that also support transfer so any sparse-only
queues are filtered out. If a device only supports sparse with
sparse-only queues, sparse features are disabled and these functions
return count of 0.
Fixes: a55d26b566 ("venus: add back sparse binding support")
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26297>
This fixes hangs with Zink on piglit spec@arb_sparse_buffer tests caused by the double submission.
Fixes: a55d26b566 ("venus: add back sparse binding support")
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26375>
For guest-based blob allocations from hostmem (Host visible memory),
to make sure that virtio-gpu driver will send to the host the address
(offset in the region) of the allocated blob using RESOURCE_MAP_BLOB
command a flag VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT must be set.
Otherwise, if the upper layers didn't set it, host can't import memory
and guest allocation from Host visible memory region makes no sense.
Signed-off-by: Andrew D. Gazizov <andrew.gazizov@opensynergy.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26130>
In addition to the platform requirement (use_guest_vram), device memory
allocations from dedicated heap (guest_vram) are necessary only when:
1. VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT is set and it indicates that
memory is host visible and assumed to be accessed by CPU (vkMapMemory).
2. One of external memory handle types is set, that indicates memory
can be exported with external handle.
In other cases it's not necessary to create virtgpu_bo object in the
guest and enough just perform vkAllocateMemory on host side without
memory import from dedicated heap.
Reported-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Andrew D. Gazizov <andrew.gazizov@opensynergy.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26130>
blob_id == 0 does not refer to an existing VkDeviceMemory and implies
a shmem allocation. So for guest_vram device memory allocations, 0 is
not a valid blob id and must be greater than 0.
Therefore, set vk_object_id as blob_id for guest_vram device memory
allocations. Considering that vk_object_id made from valid pointer, it
will be always greater than 0.
Signed-off-by: Andrew D. Gazizov <andrew.gazizov@opensynergy.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26130>
- pMultisampleState->pSampleMask should be ignored when
VK_DYNAMIC_STATE_SAMPLE_MASK_EXT is used.
- pRasterizationState can be null now
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25921>
For hypervisors that do not support host memory injection into the
guest address space, it's necessary to have guest-based blob alloc.
Therefore, use a new 'use_guest_vram' virgl capset to decide on
performing guest blob allocations from dedicated heap (Host visible
memory).
Signed-off-by: Andrew D. Gazizov <andrew.gazizov@opensynergy.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25889>
Fix an assertion when using vkQueueBindSparse.
Fixes: 7fbf608f2d ("venus: append query feedback at submission time")
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26027>
Add a helper to de-duplicate some of the virtgpu native-context support
between turnip and freedreno. This should make things easier for other
drivers adding virtgpu support.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # virtio-intel
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24733>
Since these all ended up the same with (not yet merged) intel and amd
implementation of drm native context, split these out so they can be
shared. This will also make it easier to extract out a shared helper
that can be re-used across native-context drivers.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # virtio-intel
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24733>
Currently the run takes ~ 35 minutes, which is too much.
Reported-by: default avatarDaniel Stone <daniels@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25843>
All commands that make queries available have feedback cmds batched
and stored during recording. At submission time, for each batch
(SubmitInfo) these feedback cmds are recorded in a cmd buffer that is
appended after the last original cmd buffer (but before
semaphore/fence feedback).
Query reset cmds are deferred as well and also remove any prior feedback
cmds for queries its resetting within the batch.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
