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>
Multi-platform support (Linux, Fuchsia) for gfxstream-vk
has been built by providing a compatibility layer
with Android stubs.
We should get away from this model and isolate platform
specific dependencies to their own files.
With the mesa-ification, a lot of this has been done,
but a few Androidisms remain. Remove them and don't
assume Android.
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 the Fuchsia and meson builds, we can remove
dependencies on RenderControl and just replace
it with a stub. That's because only Goldfish
needs RenderControl's "process pipe" logic to
initialize the VkDecoders.
The Fuchsia build may be migrated to Bazel over
GN, so that's why it's left unmodified.
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>
The HostConnection class pulls in:
- GLES_v1 encoder
- GLES_v2 encoder
- renderControl encoder
- vulkan encoder
Since HostConnection is required to talk the host, that
means the libgfxstream_vulkan.so has a GLES dependency.
This is unnecessary. Ideally, libgfxstream_vulkan.so
only needs the Vulkan encoder dependency, and that is
the case for virtgpu.
For Goldfish, since it uses the "process pipe"
initialization logic is used, for Android builds
a renderControl encoder dependency is still required.
To increase the separation of these encoders, this
change adds a GfxStreamConnectionManager class. It
has no explicit dependency on any API encoder, but
can store thread-local instances of them.
The HostConnection class may be implemented in terms
of the GfxStreamConnectionManager API. For now, the
plan is just to convert libgfxstream_vulkan to use
the ConnectionManager.
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 logic sequentially waits for each sync file
descriptor, followed by a vkWaitForFences, but keeps
track of total aggregate time spent inside the
function.
Previously, external fences were waited on for 3000ms
somewhat arbitrarily, while the timeout was respected
for non external fences. Also multiple threads were
used, which is a more complex way.
One can also use sync_accumulate(..) for the external
fences, but that isn't done since an equivalent does
not yet exist for the Kumquat layer. Proper solution
would be the new virtio-gpu fence passing protocol.
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>
EmulatorFeatureInfo likes to bundle all the features
into one giant struct. Newer variants like virtio-gpu
tend to separate feature versioning into separate
capabilites.
This provides a compat layer for the older style,
as we move towards the newer style of versioning.
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 plan for Fuchsia emulators is Lavapipe and
virtio-gpu/gfxstream for acceleration. Currently,
Fuchsia guest side is frozen in place for Goldfish,
so this has no effect.
This in contrast to Android, where Goldfish Address
Space is still projected to be used for another year.
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>
