Vulkan headers are exposing KHR version of the extension. Without this
change, codegen won't generate the necessary guest code, and the calls
with the extension structures will be skipped, causing dEQP failures.
Test: dEQP-VK.api.info.vulkan1p2_limits_validation*
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31650>
This simplifies the amount of code imported from Vulkan
docs. It vendors the code to just a subset needed by
the cerealgenerator. The files that are kept are:
- generator.py
- cgenerator.py
- reg.py
- genvk.py
Since these files originate with Khronos, they are
Apache licensed.
Long-term, there are various ideas on how to proceed
with codegen. Probably the above files can be nuked
in the event some of those ideas come to pass.
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>
genvk.py itself includes different types of generators:
spirvgenerator.py, rubygenerator.py, etc. cerealgenerator.py
is an additional one. A strategy to pare down the size of
the code would be modify genvk.py to remove unneeded generators,
and just import the cerealgenerator: i.e, importing the subset
of scripts useful to gfxstream.
The removes the notion of upstreaming to vulkan-docs, but does
imply more dedicated codegen strategy long-term.
About 300kLoC can be removed, since previously we just a blanket
copy.
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 vkGetFenceStatus() call can not be sent to the host for fences
that have imported an external payload (sync fd) because the sync
fd does not exist on the host. A fence used as part of a swapchain
present may be created in the unsignaled state. Then, during
vkQueuePresentKHR() on Android, vkQueueSignalReleaseImage() is used
to import a sync fd payload into the present fence. Prior to this
change, if the user (ANGLE) does vkGetFenceStatus() on this fence,
it would never appear as signaled because the sync fd fence is not
actuallly connected to the fence on the host and the host would just
always return the VK_NOT_READY from the fence's initial unsignaled
state.
This change also updates VkFence_Info to use a std::optional<int>
to make it possible to distinguish if a fence has an imported
already-signaled payload vs not having an imported payload.
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 adds the GfxStreamVulkanConnection, and makes
libgfxstream_vulkan.so use it. All dependencies
to HostConnection are removed.
For Android builds, dependencies to renderControl
and libOpenGlCodecCommon remain. In the future,
these will be isolated to Goldfish-based system
images.
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 acquire the lock when createExtraHandlecsForNextApi is called. But
depending on config, vkCreateDescriptorPool may or may not call
createExtraHandlesForNextApi, which results in inconsistency of the lock
state when calling snapshot()->vkCreateDescriptorPool.
We add a tryLock so that it always acquires the lock before modifying
mReconstruction.
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 HealthMonitor is hang detection at the API Vulkan
encoder level.
It's actually not used in CF/AAOS/Emualtor. The
plan for AOSP is actually to increase the amount
of Android CTS that are run against gfxstream to
increase health/stability, for example (b/347288539).
So if we consistently pass CTS on main with gfxstream
(as is the plan), HealthMonitoring would be somewhat
redundant.
Also, AndroidHealthMonitor is somewhat duplicated with
libaemu's HealthMonitor as well.
Also, nuke EncoderAutoLock while we're at it. It also
is unused code.
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>
Unboxing fails if a NULL handle is passed in, triggering an abort.
However for vkCmdBeginTransformFeedbackEXT, this is perfectly
valid:
"For each element of pCounterBuffers that is VK_NULL_HANDLE,
transform feedback will start capturing vertex data to byte zero
in the corresponding bound transform feedback buffer."
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>
pCounterBuffers can be NULL, which crashes on the autogen path:
"For each element of pCounterBuffers that is VK_NULL_HANDLE,
transform feedback will start capturing vertex data to byte zero
in the corresponding bound transform feedback buffer."
Need to special case.
Intel
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>
With newer versions of libstdc++, debug builds of gfxstream
hit this assert:
0x00007ffff6ed2d60 in std::__glibcxx_assert_fail
(file=<optimized out>, line=<optimized out>, function=<optimized out>,
condition=<optimized out>)
at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
std::allocator<VkDescriptorBufferInfo> >::operator[]
(this=0x555555609380, __n=0)
at /usr/include/c++/14.1.1/bits/stl_vector.h:1130
(pDescriptorSets=0x7fffffffcc30, descriptorSetCount=2,
bufferInfos=std::vector of length 1, capacity 1 = {...})
at ../guest/vulkan/gfxstream_vk_device.cpp:718
(device=0x55555562f400, descriptorWriteCount=2,
pDescriptorWrites=0x7fffffffcc30, descriptorCopyCount=0,
pDescriptorCopies=0x0)
at ../guest/vulkan/gfxstream_vk_device.cpp:746
Use resize instead of reserve + memset.
"That way the vector size would be initialized, bounds checks would
be happy, and default-init would automatically zero out POD structs
for us." -- dextero@
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>