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>
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>
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>
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>
Link the query feedback cmd lifecycle to a cmd in the batch so that when
that last cmd gets reset/freed, we assert its safe to reset the query
feedback cmd. The cmd is then placed on the free list for reuse.
Some edge cases if the the last cmd is simultaneous or gets resubmitted.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
Test case 'dEQP-VK.pipeline.monolithic.timestamp.misc_tests.consistent_results'..
Fail (Results are inconsistent: B32=0xffffffff B64=0x10103ba2cdd4e G32=0xba2cdd4e G64=0x10103ba2cdd4e)
Fixes: e6cffa1f0e ("venus: use feedback for vkGetQueryPoolResults")
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25820>
src/virtio/vulkan/vn_ring.c: In function ‘vn_ring_submit’:
src/virtio/vulkan/vn_ring.c:259:4: warning: ‘cur_seqno’ may be used uninitialized [-Wmaybe-uninitialized]
259 | vn_ring_retire_submits(ring, cur_seqno);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lina Versace <linyaa@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25797>
Function vn_fix_graphics_pipeline_create_infos() had two interleaved
phases: discovery of needed fixes, and application of those fixes.
Move the discovery phase into new function
vn_find_graphics_pipeline_create_info_fixes(). The two-phase approach
will be simplify the implementation of VK_EXT_graphics_pipeline_library.
No intended change in behavior.
Signed-off-by: Lina Versace <linyaa@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22419>
