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>
Until the performance issues get resolved, enable the extension
if `VN_DEBUG=gpl`.
Also enable the required (and trivial) VK_KHR_pipeline_library.
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>
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>
Use a more consistent naming scheme for everything. Follow-up patches
will implement VK_EXT_graphics_pipeline_library, which will make the
code significantly more complex, in which better names will make the
code more readable.
Except for replacing `any_fix` with `erase.mask`, this patch does modify
any procedural code. It merely renames structs and fields.
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>
No change in behavior. Prepares for storing more state in graphics
libraries for VK_EXT_graphics_pipeline_library.
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>
No intended change in behavior. This little improvement will help
vn_pipeline track its graphics state more accurately.
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>
When writing vn_fix_graphics_pipeline_create_info() long ago, I defined
some always-true dummy vars that represented some
VkGraphicsPipelineLibraryFlagsEXT. In the conditions that decide which
state to fixup, I used the dummy vars.
My intent was that this would ease the implementation of
VK_EXT_graphics_pipeline_library, because some of the GPL fixup logic
would already be present. I was wrong. After I studied GPL more,
I discovered that the conditions were using the dummy vars incorrectly.
The incorrect usage produced no bugs, because the vars are always true.
Delete the dummy vars.
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>
With VK_EXT_graphics_pipeline_library, the layout may be omitted or
ignored in incomplete pipelines.
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>
We should avoid erasing VkGraphicsPipelineCreateInfo when possible
because the erasure add cpu overhead. Do not erase pViewports if
viewportCount is 0. Do not erase pScissors if scissorCount is 0.
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>
Summary:
1. hide those extensions for vtest since there's no export support
2. do block waiting upon export without implicit fencing support
Fixes: 68a478870d ("venus: expose KHR_external_fence/sempahore_fd extensions")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25633>
Add a new perf option NO_ASYNC_MEM_ALLOC. Track the ring seqno of the
memory alloc command, and do async ring wait to ensure:
- memory allocation is before resource creation
- memory import is before resource destroy
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25611>
When the guest driver is Virgl while Xwayland is on Zink, Virgl can
request virtgpu classic 3d resource allocations for swapchain images.
Zink will import when the image is shared with xserver and will export
for fd info of all 2d images later to be forwarded.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25579>
Re-purpose renderer has_external_sync to cover explicit sync emulation
in venus, so that we don't have to add a new flag to distinguish the
emulation path enablement for virtgpu and vtest.
This is to unblock zink implicit sync hanlding against venus for now,
and soon we should migrate to virtgpu fence passing.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25127>
Add a driconf to force the swapchain size to match
`VkSurfaceCapabilities2KHR::currentExtent` as a workaround for
misbehaved games
Fixes: 6139493ae3 ("vulkan/wsi: return VK_SUBOPTIMAL_KHR for sw/x11 on window resize")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24818>
Kernel makes every mapping coherent. If a memory type is truly
incoherent, it's better to remove the host-visible flag than silently
making it coherent. However, for app compatibility purpose, when
coherent-cached memory type is unavailable, we emulate the first cached
memory type with the first coherent memory type.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24875>
VK_EXT_device_memory_report is implemented in venus driver side, which
has a feature struct. So we must enable it after setting features for
renderer extensions. This change also includes tiny format fixes.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24881>
Should only log when there's batched query feedbacks in the suspended
render pass instance. Additionally gate behind debug option.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24379>
For secondary command buffers, vn_cmd_begin_render_pass was only used to
track inherited render pass previously. So we clean it up.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24103>
Reset cmd states during vkBeginCommandBuffer regardless of the
VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT for simplicity.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24103>
The 1st sync scope of vkCmdCopyQueryPoolResults is not sufficient to
cover transfer writes against query feedback buffer. We must ensure
ordering against prior query reset cmd where the feedback buffer fill
gets injected.
Fixes: de4593faa1 ("venus: add query pool feedback cmds")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24130>
