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>
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>
Add function to alloc a cmd buffer and record all the deferred query
feedback cmds into it at submission time.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
defered query feedback cmds have similaries with timeline semaphore
feedback so refactor out some common functions for reuse
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
Meanwhile, we merge the export and non-external allocate paths since
export alloc will be rejected by vn_device_memory_should_suballocate.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25184>
vk_device_memory_create handles AHB export alloc and import tracking.
Also use common GetMemoryAndroidHardwareBufferANDROID impl.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25184>
This change only switches the object base, and is to prepare for using
vk_alloc_ahardware_buffer. Large refactor via leveraging existing common
vk_image state tracking will be followed.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25184>
AHB prop query would check the memory plane count match instead. This
reduces vn_android_get_image_builder overhead and simplifies the AHB
import api to prepare for later common vk ahb adoption.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25184>
Pass type and handle directly instead of vn_object_base to prepare for
device level objects using corresponding common vk objects.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25184>
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>
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>
This enables some extensions and a bunch of formats for ycbcr
support.
dEQP-VK.api.info.format_properties.g8_b8_r8_3plane_420_unorm,Fail
dEQP-VK.api.info.format_properties.g8_b8r8_2plane_420_unorm,Fail
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25609>
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>
This got the bits the wrong way,
dEQP-VK.rasterization.frag_side_effects.color_at_beginning.sample_mask_after
Fixes: a63c2daf7a ("llvmpipe/fs: start using nir info in some places.")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25396>
The new host version checks the support of these features better,
so report here accordingly. This fixes a number of texwrap piglit
tests on Intel.
v2: Stick to old test for PIPE_CAP_TEXTURE_MIRROR_CLAMP because
host has to be backward compatible.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25343>
