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>
This change does two things:
- Makes sure the descriptor is passed through to
EmulatedGralloc, where it makes a difference
- Makes sure descriptor is always used when creating
a VirtioGpuPipeStream. The VirtioGpuPipeStream
API where the descriptor is not passed in has
been nuked.
GLES, VK, Gralloc, and RenderControl can all pass in
a descriptor via their APIs with this change.
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>
It can be set to "none" to enable a "linux-like" build of gfxstream
guest code with Soong, providing support for DMA-BUF import extensions.
With the flag turned on, Android window system integration is disabled.
Tested with:
Comment out "FINISHME: support
VK_EXTERNAL_MEMORY_FEATURE_DEDICATED_ONLY_BIT" check on vk_glow
Run vk_glow on a lunch target with the entire CL chain, and the
mesa3d_platforms Soong flag set to "none", see output
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>
Do not force linear tiling for WSI in vkCreateImage. Allow creating WSI
images from DMABUFs with DRM format modifiers.
If the extension is supported by host, forward
VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT to
vkGetPhysicalDeviceImageFormatProperties2 and vkCreateImage.
If it's not supported, attempt to support DRM_FORMAT_MOD_LINEAR by
mapping it to VK_TILING_LINEAR.
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>
