Track pipeline layout creation and destroy calls
to cleanup them correctly on device teardown.
Pipeline layouts require delayed delete operations for
VulkanQueueSubmitWithCommands feature which modifies order
of commands and they need to stay valid during recording.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34418>
- Fix the checks for emulation (based on presence of the extension
on the host)
- Add flag in gfxstream_vk_physical_device, otherwise the real device
extensions are not properly filtered when communicating with the host.
- The "function" version of the check in ResourceTracker can eventually
just check the flag once mesa and gfxstream objects are combined
- Remove the duplicate getPhysicalDeviceFormatProperties2 impl, this is
covered by the ResourceTracker impl
- Add ResourceTracker impl for getImageDrmFormatModifierPropertiesEXT
- Remove isDmaBufImage flag from VkImage_info, and clean up all the code
associated with this flag. In on_vkCreateImage, all required info is
avaialble from the extMemImageCi::handleType. In on_vkAllocateMemory,
this is all associated with the tiling of the dedicatedImage for the
allocation
Reviewed-By: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33944>
... and the linearPeerImage that was backing emulated drmFmtMod images.
With proper drmFmtMod emulation, the VkImage itself will be
linear-tiled.
Reviewed-By: Gurchetan Singh <gurchetansingh@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33944>
... since `BoxedHandleManager` should, well, manager the handles.
This simplifies `VkDecoderGlobalState` a little bit and should also
allow us to remove a bunch of functions that no longer need to
depend on `VkDecoderGlobalState`.
Test: cvd create --gpu_mode=gfxstream_guest_angle_host_swiftshader
Test: cvd snapshot_take --force \
--auto_suspend \
--snapshot_path=/tmp/snapshot1
Test: cvd reset -y
Test: cvd create --snapshot_path=/tmp/snapshot1
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
Add vkGetFenceStatus and vkWaitForFences functions to the
global state tracking list for the host.
This will allow adding more functionality to the fences
and perform additional operations before waiting for and
signaling them.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
Enables software rendering via swiftshader on host side and angle
on guest when using DMABUF based framebuffers.
TEST=Run internal application successfully
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
... to break the recursive behavior of the replay calling into
VkDecoderSnapshot so that locking and thread safety annotations can be
preserved in VkDecoderSnapshot.
Follow up to aosp/3412302.
Test: cvd create --gpu_mode=gfxstream_guest_angle_host_swiftshader
Test: cvd snapshot_take --snapshot_path=<>
Test: cvd create --snapshot_path=<>
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33740>
It's unclear to me whether this is dead code that should be removed or
dead code that should be used, so I just marked it as unused to remove
a few thousand warnings when compiling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33384>
Initial "compilable" version of mesa/gfxstream on Windows. For now it is
achieved through "#if !DETECT_OS_WINDOWS" directives hence it is NOT
functional. The compilation works with mingw only and the compilation is
tested in a windows host. This commit is intended to only pass the
compilation process without errors.
Also created stub code for a future windows implementation.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32795>
During loading of snapshot, there will be a single-threaded
decoder that aquires the same mReconstructionMutex, repeatedly.
Since the mReconstructionMutex is intentionally changed to
be non-recursive, we should not aquire it at the beginning of
load call; otherwise, we will be deadlock the decoder thread.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Replace tryLock / unlock with regular scoped lock now that the
"extra handles" have been moved out of VkReconstruction and into
the VkSnapshotApiCallInfo.
Switch to regular std::mutex and std::lock_guard.
Annotate mReconstruction with GUARDED_BY to start to get more
thread safety analysis.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
... so that `VkDecoderGlobalState` can append additional information
needed for snapshotting. Specifically, `VkDecoderGlobalState` may create
additional boxed handles that are not visible directly in the API surface.
For example, `vkCreateDevice()` creates boxed handles for the `VkQueue`-s
and `vkCreateDescriptorPool()` creates boxed handles for pre-allocated
`VkDescriptorSets`. These boxed handles are not recoverable from the API
for `vkCreateDevice()` nor `vkCreateDescriptorPool()` directly. This was
previously worked around by just sticking the extra boxed handles in
`VkReconstruction::mExtraHandlesForNextApi` but this is not thread safe.
Instead, let's give `VkDecoderGlobalState` and `VkDecoderSnapshot` exclusive
access to individual `VkSnapshotApiCallInfo` objects.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Removes the additional saving of opcode and packet len as this is
all available from within the packet itself.
Removes the "trace" position from `VulkanMemReadingStream` as these
seemed to only be used for getting the packet start and packet size
but these are already available.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
Original change from: kyoungwon.kim@bytedance.com at aosp/3310239
Moving the change into gfxstream and codegen.
The issue was found by pengzejie@bytedance.com.
Note that vkReadStream's BumpPool is effectively `freeAll`'ed by
`clearPool` calls. The same call for vkStream is not being called
while alloc is called here and there.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
For multiple queue emulation, we need to change how queue related
functions are working on the host side and do custom unboxing
before submitting the commands to the underlying driver.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33018>
When batched descriptorset udpate optimization is turned
off, the descriptorset is not handled in snapshot.
This cl handles this situation.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32148>
For dispatchable handle, such as commandBuffer, it is always
left as boxed by decoder; consequently snapshoter should not
box it again.
Reviewed-by: Marcin Radomski <dextero@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32148>
This removes the dependency of libaemu-v0.1.2 on
gfxstream guest vulkan.
ALSO:
find ./ -type f -exec sed -i -e 's/android::base/gfxstream::aemu/g' {} \;
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32062>
Codegen does not automatically generate code for promoted
extensions, so we need to explicitly define support for
VK_EXT_line_rasterization to generate necessary code.
Reviewed-by: Aaron Ruby <aruby@blackberry.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31929>
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>
Partial update to vulkan headers and auto generated code to
include the new extension. It will be used to fix issues on
external memory implementation with MoltenVK later on.
References:
Khronos MR 6800
MoltenVK PR 2314
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 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>
While cereal implements an API provided by Khronos Apache 2.0
files, the files were started in AOSP, and can be relicensed to
MIT.
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>
When invoking the build in the guest, we don't need
to define this.
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 dd5c7b6aeb41270f0b457c18a2a31cf136562bf0.
Reason for revert: b/366153044
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 move the fence signaling to after color buffer copying. This is done
by reusing the existing CPU CV object and wait on it before triggering
the GPU vkWaitForFences.
Also rewrite fenceInfo.status with std::future to simplify the code.
Design: go/emu-async-cb-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>