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>
Certain libraries (libEGL_emulation, GLESv1/GLESv2, and
vulkan.ranchu) have duplicated variants due to two issues:
- whether to use the Kumquat and Linux VirtGpu backends
is a build time decision. This leads to "libplatform" and
"libplatform_kumquat".
- virtgpu_kumquat_ffi pulls in librutabaga_gfx_gfxstream,
which pulls in libgfxstream_backend -- which does not compile
for glibc_x86 or android32. This means "compile_multilib: 64"
is needed for glibc_x86_64 and android64 builds. The
non-kumquat dependent Android build actually needs 32-bit
libraries, while the kumquat dependent Android built does not.
This leads to different libraries.
The follow changes are made:
- Kumquat and Linux backends are both built for
host-builds. An environment variable controls
selection ("VIRTGPU_KUMQUAT").
- For Android builds, a stub Kumquat is built. We can
build a real Kumquat, but the use case does not exist.
These changes allow for a much simpler build.
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 change nukes the RutabagaLayer and makes the
end2end testing layer use Kumquat.
The benefit is not having two different testing
frameworks. Compared to the RutabagaLayer, Kumquat
is more complex, but potentially has more features
in the long run. Some advanatages:
- virtgpu_kumquat_ffi is portable enough that
non-gfxstream libraries (minigbm, others) can
depend on it. This would enable more accurate
gralloc testing long-term.
- multiple different context types can connect to
Kumquat at the same time, rather than just one with
the RutabagaLayer.
- If anyone is bored, it should be pretty easy add
v4l2 apis via an virtio-media like interface.
- The kumquat server can actually call
stream_renderer_teardown(..) when performing
snapshot tests.
- Kumquat relies on EventFd + VkExternalSync:
this can eliminate the need to export the
libplatform sync API outside VK, EGL over the
long-term.
A point of complexity was Gralloc. We have an external
Gralloc instance, but HostConnection also maintains a
thread-local Gralloc instances. The thread-local gralloc
instances can potentially step on the kumquat connection
of the pipe or ASG stream. The solution was for
GrallocEmulated to maintain it's own virtgpu_kumquat
instance.
The proper long-term solution is move gralloc out of
HostConnection entirely.
A prior version of this change relied on:
- vkInitializeKumquat,
- rcCreateDeviceKumquat
- eglInitializeKumquat
since I read somewhere GoogleTest is necessarily
multi-threaded. That turned out to be fake news, so nuke
those functions as well.
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>
