This uses libvirtgpu_kumquat_ffi.so to send commands to the
Kumquat Media Server. The implementation of Kumquat is found
at crrev.com/c/5645904.
This is a more complex, but more fully featured end-to-end testing
framework. This biggest benefit it is can run complex apps (vkcube,
gfxbench + ANGLE/Zink) on Linux, without a VM or a full Android tree.
The rutabaga FFI path -- which relied on a nested Vulkan loader -- didn't
work for complex apps and funkiness was observed with the nested
Vulkan loader.
Plus, app 1 + app 2 could connect Kumquat at the same time.
This may also benefit snapshot tests, particular since end to end
flow relies on external blob. For example, a snapshot save command
could actually call stream_renderer_teardown(..) on the host-side,
while the guest retains it's state (ASG mappings + vulkano mappings).
A snapshot restore would actually call stream_renderer_init(..)
+ stream_renderer_restore(..), which an actual upstream VMM would
do.
Another additional benefit is multi-context testing. Since
libvirtgpu_kumquat_ffi.so is portable, other libraries (minigbm)
can also call it. We can mimic the cross-domain context allocating
via libminigbm.so, while context libgfxstream_vulkan.so imports the
file descriptor.
This change only transitions the meson build since the main goal
is once again is Linux on Linux testing w/o an Android tree.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
We did a few things here.
1. Update VkBindImageMemoryInfo in vkBindImageMemory2 for snapshot. In
its implementation, vkBindImageMemory2 sometimes replaces an unboxed
VkImage handle with a new one, which breaks snapshot. We update its
value so that it can map to the proper one when calling snapshot
functions. Note that there is a const cast which we might want to fix
later.
2. Lock it properly when calling createExtraHandlesForNextApi.
3. Add support for more VkImage format. Fix mipmap extend calculation.
Now it works with -guest-angle but fails with VVL, not sure why.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
The pattern of vkBindImageMemory2 doesn't really fit with what we have
in the auto-code generator. Thus we need to implement a special entry
for it in the code generator. In future we might want to split the code
and directly write c++ code for similar APIs.
Note that due to complexity we only support vkBindImageMemory2 with
bindInfoCount == 1, for now.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
These APIs and the related extension are deprecated in favor of the new
metal_objects extension to make sure the loader can intercept them, so that the layers, such as VVL, would work fine.
Removes necessity to load functions directly from a separate dylib.
VK_MVK_moltenvk extension support is still passed to the guest side
due to the existing checks for enabling the AHB extension.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
This extension is enabled from the platform side via the Android
loader and the applications using the functions or structures of
it would crash even if they check the support of the extension.
Guest callback addresses within the structures of this extension
cannot be used and are already being removed when creating the
instances.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
In our implementation, VkQueue is created in vkCreateDevice instead of
vkGetDeviceQueue. We will need to track their creation API properly,
otherwise there will be a name mismatch on snapshot load. This will
result in a crash during snapshot load with -guest-angle.
This commit marks their creation API properly.
Same thing applies for VkDescriptorSet.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
Original approach was to translate all possible handle types for complete
Mesa object equivalence. Practically, only a subset of these objects
actually need to be real Mesa objects for use with WSI. This simplifies
the translation and handwritten entries substantially, which is somewhat
brittle and bug-prone.
Clean up parts of functable.py that we don't need.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
memory report extension is present. It's is filtered out when
sent host side, since for a virtual GPU this is quite difficult
to implement.
Mesa runtime is picky about physical device features. So if
the test tries to enable device level extension without it
definitely existing, the test will fail.
The test can also be modified to check
VkPhysicalDeviceDeviceMemoryReportFeaturesEXT, but that's more
involved. Work around this by always advertising the extension.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
... as this can lead to a deadlock with the following sequence:
Time1: guest-thread-1: vkDestroyBuffer() called
Time2: VkEncoder grabs seqno 1
Time3: guest-thread-2: vkMapMemory() called
Time4: ResourceTracker::on_vkMapMemory() locks mLock
for using `info_VkDeviceMemory`
Time5: ResourceTracker::on_vkMapMemory() calls
enc->vkGetBlobGOOGLE()
Time6: VkEncoder grabs seqno 2
Time7: VkEncoder sends the vkGetBlobGOOGLE with seqno
2 via ASG to host
Time8: VkEncoder waits for the `VkResult` from the
host via `stream->read()`
Time9: guest-thread-1: VkEncoder calls sResourceTracker->destroyMapping()
->mapHandles_VkBuffer((VkBuffer*)&buffer);
which calls ResourceTracker::unregister_VkBuffer()
ResourceTracker::unregister_VkBuffer() tries to
locks mLock to erase the buffer's info struct
from `info_VkBuffer`
!!! DEADLOCKED HERE !!!
guest-thread-1 is stuck waiting on mLock (currently locked by
guest-thread-2) before it would `stream->flush();` to finishing
sending the vkDestroyBuffer() command to the host and potentially
ping its corresponding host-render-thread-1.
guest-thread-2 stuck waiting on the result from host-render-thread-2
but host-render-thread-2 won't progress until host-render-thread-1
finishes seqno 1 which needs guest-thread-1 to finish sending/pinging.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27246>
