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>
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>
From the Vulkan 1.3.204 spec:
VUID-VkSubmitInfo-pNext-03240
"If the pNext chain of this structure includes a
VkTimelineSemaphoreSubmitInfo structure and any element of
pSignalSemaphores was created with a VkSemaphoreType of
VK_SEMAPHORE_TYPE_TIMELINE, then its signalSemaphoreValueCount
member must equal signalSemaphoreCount"
Internally, Mesa WSI creates placeholder semaphores/fences (see
transformVkSemaphore functions in in gfxstream_vk_private.cpp).
We don't want to forward that to the host, since there is no host
side Vulkan object associated with the placeholder sync objects.
The way to test this behavior is Zink + glxgears, on Linux hosts.
It should fail without this check.
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>
Removes dependency on gfxstream::guest's AEMU lock classes.
Mostly consists on Autolock<RecursiveMutex> to
std::lock_guard<std::recursive_mutex>.
There are some cases where the code does:
Autolock<RecursiveMutex> lock(mLock)
..
lock.unlock()
[ do something ]
lock.lock().
..
Those cases were replaced with std::unique_lock.
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>
