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>
This reverts commit 9eef6d0aefcf0aa1c07d42d9b307b1092a6deec9.
... as this does not yet have a way to generically convert Mesa
handles into Gfxstream handles in extension structs which causes
breakage in dEQP VK for many tests.
Moves the mesa based codegen to a separate `mesa_func_table`.
Reland fixes the end2end test guest vulkan ICD.
cts -m CtsDeqpTestCases
--module-arg CtsDeqpTestCases:include-filter:dEQP-VK.*
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 have a situation that if an image memory is created with
VkMemoryDedicatedAllocateInfo, the following commands that refer to the
same image must happen in this exact order:
vkCreateImage
vkAllocateMemory (with dedicated image memory)
vkBindImageMemory
vkCreateImageView
Our previous dependency graph implementation uses Vulkan objects as
nodes and does not haven enough granularity to handle this situation.
vkCreateImageView can only be executed after an image is created and
bound to memory. Our previous dependency graph does not have the
notion of "bound to memory". We worked around it by adding
vkBindImageMemory as part of the image initialization steps.
To make sure we can bind image at initialization, we marked image to be
dependent on the memory it bounds to. When adding the new
vkAllocateMemory with dedicated image memory extension into the mix, it
introduced a circular dependency. vkAllocateMemory will say the memory
has dependency on the image. vkBindImageMemory will say the image has
dependency on the memory.
To properly resolve the issue, we will need to record the state of an
Vulkan object, and declare that vkCreateImageView not only depends on an
image, but also requires the image to be bound to memory. We do so by
introducing a "State" enum and use the pair <VkObjectHandle, State> as
the vertex in the deppendency graph. Currently State is an enum with 2
values: CREATED and BOUND_MEMORY. By default, after a VkCreate* command,
an object will be in CREATED state. When calling vkBindImageMemory or
vkBindBufferMemory it will transform the image or buffer into
BOUND_MEMORY state. Then vkCreateImageView will have dependency with
{VkImage, BOUND_MEMORY}.
Then we can create a dependency graph that looks like this:
VkImageView --> {VkImage,BOUND_MEMORY} --> VkMemory
| |
| ┌-------------------⅃
v v
VkImage
No more circular dependency.
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 does not yet have a way to generically convert Mesa
handles into Gfxstream handles in extension structs which causes
breakage in dEQP VK for many tests.
Moves the mesa based codegen to a separate `mesa_func_table`.
cts -m CtsDeqpTestCases
--module-arg CtsDeqpTestCases:include-filter:dEQP-VK.*
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 is more generic and "VirglBlob" is not actually a blob.
find . -type f -name "*.cpp" -print0 | \
xargs -0 sed -i '' -e 's/VirtGpuBlob/VirtGpuResource/g'
find . -type f -name "*.h" -print0 | \
xargs -0 sed -i '' -e 's/VirtGpuBlob/VirtGpuResource/g'
find . -type f -name "*.cpp" -print0 | \
xargs -0 sed -i '' -e 's/createVirglBlob/createResource/g'
find . -type f -name "*.h" -print0 | \
xargs -0 sed -i '' -e 's/createVirglBlob/createResource/g'
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>
Gurchetan Singh